On 26/09/17 13:49, Paul Durrant wrote: >> -----Original Message----- >> From: Jan Beulich [mailto:jbeul...@suse.com] >> Sent: 26 September 2017 13:35 >> To: Andrew Cooper <andrew.coop...@citrix.com>; Paul Durrant >> <paul.durr...@citrix.com> >> Cc: xen-de...@lists.xenproject.org >> Subject: RE: [PATCH v7 02/12] x86/mm: add HYPERVISOR_memory_op to >> acquire guest resources >> >>>>> On 26.09.17 at 14:20, <paul.durr...@citrix.com> wrote: >>>> -----Original Message----- >>>> From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of >>>> Paul Durrant >>>> Sent: 25 September 2017 16:00 >>>> To: 'Jan Beulich' <jbeul...@suse.com> >>>> Cc: Andrew Cooper <andrew.coop...@citrix.com>; xen- >>>> de...@lists.xenproject.org >>>> Subject: Re: [Xen-devel] [PATCH v7 02/12] x86/mm: add >>>> HYPERVISOR_memory_op to acquire guest resources >>>> >>>>> -----Original Message----- >>>>> From: Jan Beulich [mailto:jbeul...@suse.com] >>>>> Sent: 25 September 2017 15:23 >>>>> To: Paul Durrant <paul.durr...@citrix.com> >>>>> Cc: Andrew Cooper <andrew.coop...@citrix.com>; xen- >>>>> de...@lists.xenproject.org >>>>> Subject: Re: [PATCH v7 02/12] x86/mm: add HYPERVISOR_memory_op >> to >>>>> acquire guest resources >>>>> >>>>>>>> On 18.09.17 at 17:31, <paul.durr...@citrix.com> 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).
??? At the moment, the toolstack's *only* way of editing the grant table of an HVM guest is to add it into the p2m, map the gfn, write two values, and unmap it. That is how a 4k mapping gets added, which forces an allocation or shattering to cause a L1 table to exist. This is a kludge and is architecturally unclean. >> 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). I don't see anything equivalent in the NPT or IOMMU logic. >> 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. Joao's improvements for network transmit require a trusted backend to be able to map the full grant table. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
