On Sat, Jan 25, 2020 at 1:37 AM Paolo Bonzini pbonzini@redhat.com wrote:
On 24/01/20 19:41, Ben Gardon wrote:
On Fri, Jan 24, 2020 at 12:58 AM Paolo Bonzini pbonzini@redhat.com wrote:
On 23/01/20 19:04, Ben Gardon wrote:
KVM creates internal memslots covering the region between 3G and 4G in the guest physical address space, when the first vCPU is created. Mapping this region before creation of the first vCPU causes vCPU creation to fail. Prohibit tests from creating such a memslot and fail with a helpful warning when they try to.
Signed-off-by: Ben Gardon bgardon@google.com
The internal memslots are much higher than this (0xfffbc000 and 0xfee00000). I'm changing the patch to block 0xfe0000000 and above, otherwise it breaks vmx_dirty_log_test.
Perhaps we're working in different units, but I believe paddrs 0xfffbc000 and 0xfee00000 are between 3GiB and 4GiB. "Proof by Python":
I invoke the "not a native speaker" card. Rephrasing: there is a large part at the beginning of the area between 3GiB and 4GiB that isn't used by internal memslot (but is used by vmx_dirty_log_test).
Ah, that makes perfect sense, thank you for clarifying. I think the 3G-4G in my head may have come from the x86 PCI hole or similar. In any case, reducing the prohibited range to just the range covered by internal memslots feels like a good change.
Though I have no excuse for the extra zero, the range to block is 0xfe000000 to 0x100000000.
Paolo
B=1 KB=1024*B MB=1024*KB GB=1024*MB hex(3*GB)
'0xc0000000'
hex(4*GB)
'0x100000000'
3*GB == 3<<30
True
0xfffbc000 > 3*GB
True
0xfffbc000 < 4*GB
True
0xfee00000 > 3*GB
True
0xfee00000 < 4*GB
True
Am I missing something?
I don't think blocking 0xfe0000000 and above is useful, as there's nothing mapped in that region and AFAIK it's perfectly valid to create memslots there.
Paolo