On 04/09/18 17:11, Juergen Gross wrote: > On 16/08/18 13:27, Jan Beulich wrote: >>>>> On 16.08.18 at 12:56, <andrew.coop...@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.
Such reads should be non-existent. One way or another, there's still a bug to fix in the kernel, because it isn't keeping suitable track of the pfns. As for how Xen could do things better... We could map a page of all-ones (all zeroes would definitely be wrong), but you've still got the problem of what happens if a write occurs. We absolutely can't sacrifice enough RAM to fill in the ballooned-out frames with read/write frames. I'd prefer not to see any emulation here, but that is more for an attack surface limitation point of view. x86 still offers us the option to not tolerate misaligned accesses and terminate early write-discard when hitting one of these pages. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
