Re: [PATCH 0/2] MMIO emulation fixes

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 13/08/18 07:50, Jan Beulich wrote:
>>>> On 10.08.18 at 18:37, <andrew.cooper3@citrix.com> wrote:
>> On 10/08/18 17:30, George Dunlap wrote:
>>> Sorry, what exactly is the issue here?  Linux has a function called
>>> load_unaligned_zeropad() which is reading into a ballooned region?
> Yes.
>
>>> Fundamentally, a ballooned page is one which has been allocated to a
>>> device driver.  I'm having a hard time coming up with a justification
>>> for having code which reads memory owned by B in the process of reading
>>> memory owned by A.  Or is there some weird architectural reason that I'm
>>> not aware of?
> Well, they do this no matter who owns the successive page (or
> perhaps at a smaller granularity also the successive allocation).
> I guess their goal is to have just a single MOV in the common
> case (with the caller ignoring the uninteresting to it high bytes),
> while recovering gracefully from #PF should one occur.
>
>> The underlying issue is that the emulator can't cope with a single
>> misaligned access which crosses RAM and MMIO.  It gives up and
>> presumably throws #UD back.
> We wouldn't have observed any problem if there was #UD in
> such a case, as Linux'es fault recovery code doesn't care what
> kind of fault has occurred. We're getting back a result of all
> ones, even for the part of the read that has actually hit the
> last few bytes of the present page.
>
>> One longstanding Xen bug is that simply ballooning a page out shouldn't
>> be able to trigger MMIO emulation to begin with.  It is a side effect of
>> mixed p2m types, and the fix for this to have Xen understand the guest
>> physmap layout.
> And hence the consideration of mapping in an all zeros page
> instead. This is because of the way __hvmemul_read() /
> __hvm_copy() work: The latter doesn't tell its caller how many
> bytes it was able to read, and hence the former considers the
> entire range MMIO (and forwards the request for emulation).
> Of course all of this is an issue only because
> hvmemul_virtual_to_linear() sees no need to split the request
> at the page boundary, due to the balloon driver having left in
> place the mapping of the ballooned out page.

Actually, the more I think about this, the more of a bad idea emulating
a zero page is.

It gives the illusion of a working piece of zeroed ram, except that
writes definitely can't take effect.  Its going to make bugs even more
subtle.

~Andrew

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