Re: [Xen-devel] [PATCH v2 2/2] x86/HVM: split page straddling emulated accesses in more cases

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 04.09.18 at 10:15, <Paul.Durrant@xxxxxxxxxx> wrote:
>> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>> Sent: 04 September 2018 08:44
>> 
>> >>> On 03.09.18 at 18:15, <Paul.Durrant@xxxxxxxxxx> wrote:
>> >> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>> >> Sent: 03 September 2018 16:45
>> >>[...]
>> >> The extra call to known_glfn() from hvmemul_write() is just to preserve
>> >> original behavior; we should consider dropping this (also to make sure
>> >> the intended effect of 8cbd4fb0b7 ["x86/hvm: implement
>> hvmemul_write()
>> >> using real mappings"] is achieved in all cases where it can be achieved
>> >> without further rework), or alternatively we perhaps ought to mirror
>> >> this in hvmemul_rmw().
>> 
>> If you really want me to do the change below, could I have an
>> opinion on the above as well, as this may imply further re-work
>> of the patch?
> 
> It seems to me that the behaviour should be mirrored in hvmemul_rmw() to be 
> correct.

Interesting. As said in the patch description, the presence of the extra
conditional looks to be preventing what 8cbd4fb0b7 wanted to achieve.
The present (prior to this patch) short circuiting to call
hvmemul_linear_mmio_write() when the GFN is known is one of the
things getting in the way of split accesses. When the first part of the
access is what we know the GFN for, but the second part is in RAM,
things won't work. Furthermore I think this is also an issue for non-split
accesses - the second call to handle_mmio_with_translation() from
hvm_hap_nested_page_fault() is not limited to MMIO ranges.

So I think the question is the other way around: Is there anything that
would break if the conditional was removed (making it match the rmw
case)?

Jan



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