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

Re: [PATCH] x86/altp2m: p2m_altp2m_get_or_propagate() should honor ap2m->default_access


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Tamas K Lengyel <tamas@xxxxxxxxxxxxx>
  • Date: Thu, 8 Feb 2024 08:45:01 -0500
  • Arc-authentication-results: i=1; mx.zohomail.com; dkim=pass header.i=tklengyel.com; spf=pass smtp.mailfrom=tamas@xxxxxxxxxxxxx; dmarc=pass header.from=<tamas@xxxxxxxxxxxxx>
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1707399938; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; bh=tjXjQaxzEOyNGIfNc6u0nIFLCWtCu/UY1BqT0L8u9LE=; b=XaVQKg4QQfJ9VBUaiZef3qgDpC6xubuXCldl4keDdybC4UGdT5ZUoGUoiAwH5x99ugxPetT1ub6vhGoXLY55f2+r/YKYsJy2Jx9H+xJPFcoWHztUbXIqiLl9TJf6y7IFMad/gs/WFH7zR1NMqxP7xMTbIU8CQEABmiH0SnUzcBY=
  • Arc-seal: i=1; a=rsa-sha256; t=1707399938; cv=none; d=zohomail.com; s=zohoarc; b=MZNOKKcfMuEihrKl9ms5pooZutHgMwlw6Tm5BWMknV2HSqL/Rr6g6TtekqFTHcPNo89kyStwYcPLvTK2/+474fkVZyqnfS+pFcJFqlxO6t+oTmecp68FXR/uGOvRWWxzPepb0YygPKI8ryzmZH8Ntu7h6LVgG0BOUbyNF+/HZsY=
  • Cc: George Dunlap <george.dunlap@xxxxxxxxx>, Petr Beneš <w1benny@xxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx, Alexandru Isaila <aisaila@xxxxxxxxxxxxxxx>, Petre Pircalabu <ppircalabu@xxxxxxxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Delivery-date: Thu, 08 Feb 2024 13:45:46 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Thu, Feb 8, 2024 at 2:46 AM Jan Beulich <jbeulich@xxxxxxxx> wrote:
>
> On 08.02.2024 05:32, George Dunlap wrote:
> > Er, ok, just one more comment: this could allow an altp2m to have more
> > permissions than the host; for example, the host p2m entry could be
> > p2m_access_r, but if the altp2m's default_access were p2m_access_rw,
> > it would override that.  Is that the behavior we want?  Or do we want
> > to do some sort of intersection of permissions?
> >
> > If the former, I'd propose the comment be adjusted thus:

No intersection of permissions please, that needlessly complicates
things and makes it hard to reason about the state of a view where
default permissions are used. No need to force a specific type of
usecase here where the hostp2m's permissions are special just cause we
say so. No, the permissions in the hostp2m should not have more weight
then the specifically requested default permission.

> >
> >  * If the entry is invalid, and the host entry was valid, propagate
> >  * the host's entry to the altp2m, retaining page order but using the
> >  * altp2m's default_access, and indicate that the caller should re-try
> >  * the faulting instruction.
>
> I find it highly questionable that such blind overriding should be taking
> place.

It's not blind overriding, it's the requested default permission set
for a view where no entry was present before. It is the expected
behavior. It would be way harder to design applications with this
feature if it was special cased and it would take different
permissions based on what permission is set in another view.

Tamas



 


Rackspace

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