[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v2 0/6] gnttab: add per-domain controls
On 24.09.2021 04:30, Julien Grall wrote: > Hi Roger, > > On Thu, 23 Sep 2021, 16:20 Roger Pau Monné, <roger.pau@xxxxxxxxxx> wrote: > >> On Thu, Sep 23, 2021 at 01:47:37PM +0500, Julien Grall wrote: >>> Hi Roger, >>> >>> 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: >>>>>> Hello, >>>>> >>>>> Hi Roger, >>>>> >>>>>> First patch on the series is a trivial change to xenconsoled in >> order to >>>>>> use xenforeignmemory stable library in order to map the shared >> console >>>>>> ring instead of the unstable libxc interface. It's reviewed and >> ready to >>>>>> go in. >>>>>> >>>>>> Patches 2 and 3 allow setting the host wide command line `gnttab` >> option >>>>>> on a per domain basis. That means selecting the max allowed grant >> table >>>>>> version and whether transitive grants are allowed. >>>>>> >>>>>> The last 3 patches attempt to implement support for creating guests >>>>>> without a grant table. This requires some changes to xenstored in >> order >>>>>> to partially support guests without a valid ring interface, as the >> lack >>>>>> of grant table will prevent C xenstored from mapping the shared >> ring. >>>>>> Note this is not an issue for Ocaml xenstored, as it still uses the >>>>>> foreign memory interface to map the shared ring, and thus won't >> notice >>>>>> the lack of grant table support on the domain. >>>>> >>>>> I find a bit odd that the Xenstore support is conditional to whether >> grant >>>>> table is available. Are you expecting domains with no grant table to >> have no >>>>> PV drivers (including PV shutdown)? >>>> >>>> I don't really expect much, as having guests without grant table is a >>>> developer option right now, if someone wants to make use of them for >>>> any reason it would need some thought. >>>> >>>> The other option would be my first proposal to restore foreign mapping >>>> of the xenstore ring on that case: >>>> >>>> >> https://lore.kernel.org/xen-devel/20210917154625.89315-6-roger.pau@xxxxxxxxxx/ >>>> >>>> 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. Jan
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |