Re: [PATCH 0/2] MMIO emulation fixes

[Juergen Gross <jgross@suse.com>]

On 16/08/18 13:27, Jan Beulich wrote:
>>>> On 16.08.18 at 12:56, <andrew.cooper3@citrix.com> wrote:
>> On 16/08/18 11:29, Jan Beulich wrote:
>>> Following some further discussion with Andrew, he looks to be
>>> convinced that the issue is to be fixed in the balloon driver,
>>> which so far (intentionally afaict) does not remove the direct
>>> map entries for ballooned out pages in the HVM case. I'm not
>>> convinced of this, but I'd nevertheless like to inquire whether
>>> such a change (resulting in shattered super page mappings)
>>> would be acceptable in the first place.
>>
>> We don't tolerate anything else in the directmap pointing to
>> invalid/unimplemented frames.  Why should ballooning be any different?
> 
> Because ballooning is something virtualization specific, which
> doesn't have any equivalent on bare hardware (memory hot
> unplug doesn't come quite close enough imo, not the least
> because that doesn't work on a page granular basis). Hence
> we're to define the exact behavior here, and hence such a
> definition could as well include special behavior of accesses
> to the involved guest-physical addresses.

After discussing the issue with some KVM guys I still think it would be
better to leave the ballooned pages mapped in the direct map. KVM does
it the same way. They return "something" in case the guest tries to
read from such a page (might be the real data, 0's or all 1's).

So we should either map an all 0's or 1's page via EPT, or we should
return 0's or 1's via emulation of the read instruction.

Performance shouldn't be a major issue, as such reads should be really
rare.


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel