[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2 0/6] gnttab: add per-domain controls

  • To: Julien Grall <julien.grall.oss@xxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Fri, 24 Sep 2021 09:49:20 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=T07ergxdZj5ReZ6Vn90qMN6EcVeBJ/TX1/I/NHLmnFc=; b=aZnl/eY094kJuPsrwvW9MJwc5cgGxhC97WPsDkLQUUa4tFHejJcPkILmeaX6moJnjM9YGy4EDuD3TsqtIhO5Ar5KPwUjnj3R28gWlaslmLRY9YTKRklMC5X3JKHStT0cmHtGjXS+bJlvxkhWPdQh2wQmw1Z5MIJBUqMl3pEAP5ZbmJFYhwOHnQQJH0fxDsc6c8oo8PxxgEuRVQu/ZFazGeebnhPHgorPO3cuOet+4iq/V8n9VAOIEqJqUwOgNHVPpjgvyQV2Cu9swaZCK6vAZVXwMeUQUh8DgDp9TRvl2GOfCRHfWSDIy91T5tTifpJ0o/jebWQ2V7xuE39H4Zitmg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DMoLHdhLLsuO/VvRCaUelXIBTTWXIerob24J3+9es9I85Vnu76j13M8fTvtpKbzoS9ut6onhwzRhJq52JQN9hlpVbogOSTh+p+Y2InrbCICy0mGQl3l+bshpGUHAzm6yJimkPh+mxi2xu4bDuQTsg3tN+Wy3Jxqb39DsAPVTMzV/4sClltDhWXsnjDb5M8SeezFjnqu6h31b47WdDti8nbnTUqaz1VxPY960tN8ieCDwcEKWDMbrX6bJq//8CkjYsCl+nqoCmff5WjtUM0XXlSpwv/M/dJA2ya6pE3A0Ku3gU9TljBoXu/U2PHgUFlyo6gY9y5d/i052KOjTc5mbEw==
  • Authentication-results: citrix.com; dkim=none (message not signed) header.d=none;citrix.com; dmarc=none action=none header.from=suse.com;
  • Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Ian Jackson <iwj@xxxxxxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>, Juergen Gross <jgross@xxxxxxxx>, Christian Lindig <christian.lindig@xxxxxxxxxx>, David Scott <dave@xxxxxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Delivery-date: Fri, 24 Sep 2021 07:49:30 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 24.09.2021 09:30, Julien Grall wrote:
> On Fri, 24 Sep 2021, 11:21 Jan Beulich, <jbeulich@xxxxxxxx> wrote:
>> On 24.09.2021 04:30, Julien Grall wrote:
>>> 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:
>>>>> 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.




Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.