On 24.09.2021 09:30, Julien Grall wrote: > On Fri, 24 Sep 2021, 11:21 Jan Beulich, <jbeul...@suse.com> wrote: >> On 24.09.2021 04:30, Julien Grall wrote: >>> On Thu, 23 Sep 2021, 16:20 Roger Pau Monné, <roger....@citrix.com> >> wrote: >>>> On Thu, Sep 23, 2021 at 01:47:37PM +0500, Julien Grall wrote: >>>>> On 22/09/2021 14:39, Roger Pau Monné wrote: >>>>>> On Wed, Sep 22, 2021 at 01:57:02PM +0500, Julien Grall wrote: >>>>>>> On 22/09/2021 13:21, Roger Pau Monne wrote: >>>>>> But it's also arguable that a guest not having a grant table should >>>>>> also likely prevent foreign mapping attempts. Plus such foreign >>>>>> mapping won't work from stubdomains. >>>>> >>>>> There is another option: extend the acquire hypercall to allow >> xenstored >>>>> domain to map the xenstore interface. This would require more work, but >>>> at >>>>> least it would avoid the interesting dependency on the grant table. >>>> >>>> Xen isn't aware of the shared xenstore ring page currently, so that >>>> would mean introducing more knowledge to the hypervisor that what's >>>> strictly required IMO, as Xen has no business in knowing such details. >>>> >>> >>> Well Xen already knows the page for HVM/PVH because the guest retrieve it >>> through an HMV param. >> >> To be honest using this in such a way would feel like an abuse / layering >> violation to me. >> > > I can see how it can be seen like this. Do you have a better suggestion to > be able to map mapping without the foreign mapping interface and the grant > table?
Well, as was mentioned, PV would need covering anyway. And I think just like with grants the guest should consent with such foreign mappings outside of the "can map everything anyway" category. Hence I think if such a capability is indeed needed/wanted, it ought to be the guest to announce this page to Xen. Jan
