[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] 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: 26 September 2017 13:35 > To: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>; Paul Durrant > <Paul.Durrant@xxxxxxxxxx> > Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx > Subject: RE: [PATCH v7 02/12] x86/mm: add HYPERVISOR_memory_op to > acquire guest resources > > >>> 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. I'll have to defer to Andrew to answer at this point. Paul > > Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |