Re: [Xen-devel] [PATCH v7 02/12] x86/mm: add HYPERVISOR_memory_op to acquire guest resources

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 26.09.17 at 14:20, <Paul.Durrant@xxxxxxxxxx> wrote:
>>  -----Original Message-----
>> From: Xen-devel [mailto:xen-devel-bounces@xxxxxxxxxxxxx] On Behalf Of
>> Paul Durrant
>> Sent: 25 September 2017 16:00
>> To: 'Jan Beulich' <JBeulich@xxxxxxxx>
>> Cc: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>; xen-
>> devel@xxxxxxxxxxxxxxxxxxxx 
>> Subject: Re: [Xen-devel] [PATCH v7 02/12] x86/mm: add
>> HYPERVISOR_memory_op to acquire guest resources
>> 
>> > -----Original Message-----
>> > From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>> > Sent: 25 September 2017 15:23
>> > To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
>> > Cc: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>; xen-
>> > devel@xxxxxxxxxxxxxxxxxxxx 
>> > Subject: Re: [PATCH v7 02/12] x86/mm: add HYPERVISOR_memory_op to
>> > acquire guest resources
>> >
>> > >>> On 18.09.17 at 17:31, <paul.durrant@xxxxxxxxxx> wrote:
>> > > Certain memory resources associated with a guest are not necessarily
>> > > present in the guest P2M and so are not necessarily available to be
>> > > foreign-mapped by a tools domain unless they are inserted, which risks
>> > > shattering a super-page mapping.
>> >
>> > Btw., I'm additionally having trouble seeing this shattering of a
>> > superpage: For one, xc_core_arch_get_scratch_gpfn() could be
>> > a little less simplistic. And then even with the currently chosen
>> > value (outside of the range of valid GFNs at that point in time)
>> > there shouldn't be a larger page to be shattered, as there should
>> > be no mapping at all at that index. But perhaps I'm just blind and
>> > don't see the obvious ...
>> 
>> The shattering was Andrew's observation. Andrew, can you comment?
>> 
> 
> Andrew commented verbally on this. It's not actually a shattering as such... 
> The issue, apparently, is that adding the 4k grant table frame into the guest 
> p2m will potentially cause creation of all layers of page table but removing 
> it again will only remove the L1 entry. Thus it is no longer possible to use 
> a superpage for that mapping at any point subsequently.

First of all - what would cause a mapping to appear at that slot (or in
a range covering that slot). And then, while re-combining contiguous
mappings indeed doesn't exist right now, replacing a non-leaf entry
(page table) with a large page is very well supported (see e.g.
ept_set_entry(), which even has a comment to that effect). Hence
I continue to be confused why we need a new mechanism for
seeding the grant tables.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel