All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexandru Stefan ISAILA <aisaila@bitdefender.com>
To: "rcojocaru@bitdefender.com" <rcojocaru@bitdefender.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>
Cc: "George.Dunlap@eu.citrix.com" <George.Dunlap@eu.citrix.com>,
	"andrew.cooper3@citrix.com" <andrew.cooper3@citrix.com>,
	"tamas@tklengyel.com" <tamas@tklengyel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [PATCH v1 1/2] x86/mm: Add mem access rights to NPT
Date: Tue, 22 May 2018 13:35:05 +0000	[thread overview]
Message-ID: <1526996127.25123.3.camel@bitdefender.com> (raw)
In-Reply-To: <5B03E7A702000078001C48B4@prv1-mh.provo.novell.com>

On Ma, 2018-05-22 at 03:49 -0600, Jan Beulich wrote:
> >
> > >
> > > >
> > > > On 18.05.18 at 20:30, <rcojocaru@bitdefender.com> wrote:
> > On 05/18/2018 06:30 PM, Jan Beulich wrote:
> > >
> > > >
> > > > >
> > > > > >
> > > > > > On 11.05.18 at 13:11, <aisaila@bitdefender.com> wrote:
> > > > This patch adds access rights for the NPT pages. The access
> > > > rights are
> > > > saved in bits 59:56 of pte that are manipulated through
> > > > p2m_set_access()
> > > > and p2m_get_access() functions.
> > > You don't give any rationale for the choice of bits. Right now
> > > p2m-pt.c still
> > > assumes that CPU and IOMMU page tables might be shared, despite
> > > amd_iommu_init() unconditionally turning this functionality off.
> > > As long as the
> > > option for that mode hasn't been removed from p2m-pt.c, I think
> > > bits used
> > > by the IOMMU (here: bit 59) should not be used for software
> > > purposes. The
> > > alternative therefore is for you to supply a prereq patch purging
> > > the sharing
> > > functionality from p2m-pt.c and preferably also from the AMD
> > > IOMMU code.
> > > That's of course only an option if we don't foresee any means by
> > > which this
> > > mode may become usable again.
> > The choice of bits was our interpretation of Andrew's reply here:
> >
> > https://lists.xenproject.org/archives/html/xen-devel/2018-05/msg005
> > 73.html
> >
> > Have we misread it?
> I don't think you have, but what Andrew has described was only the
> CPU side
> of considerations to make. Plus of course the patch description
> should explain
> whatever choice you make.
>
> >
> > We've also thought about putting the information in a new field of
> > struct page_info. Would that perhaps be preferable?
> I don't view this as a page property, but a mapping property. As such
> it can't validly go into struct page_info.

I will add the information in the patch description. Can you tell us
what structure is best to use for the access rights?

Thanks,
Alex

________________________
This email was scanned by Bitdefender
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

  reply	other threads:[~2018-05-22 13:35 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-11 11:11 [PATCH v1 1/2] x86/mm: Add mem access rights to NPT Alexandru Isaila
2018-05-11 11:11 ` [PATCH v1 2/2] hvm/svm: Enable EMUL_UNIMPLEMENTED events on svm Alexandru Isaila
2018-05-14 17:56   ` Tamas K Lengyel
2018-05-18 15:32   ` Jan Beulich
2018-05-18 16:00     ` Tamas K Lengyel
2018-05-18 18:22       ` Razvan Cojocaru
2018-07-02 10:59   ` Jan Beulich
2018-07-02 11:29     ` Alexandru Stefan ISAILA
2018-07-05 13:35   ` Jan Beulich
2018-05-18 15:30 ` [PATCH v1 1/2] x86/mm: Add mem access rights to NPT Jan Beulich
2018-05-18 18:30   ` Razvan Cojocaru
2018-05-22  9:49     ` Jan Beulich
2018-05-22 13:35       ` Alexandru Stefan ISAILA [this message]
2018-05-22 13:44         ` Jan Beulich
2018-05-30  9:04           ` Alexandru Stefan ISAILA
2018-05-30  9:52             ` Jan Beulich
2018-05-30 11:20               ` Alexandru Stefan ISAILA
2018-05-30 11:29                 ` Jan Beulich
2018-05-30 13:56                   ` Andrew Cooper
2018-06-05 14:45                     ` Alexandru Stefan ISAILA
2018-06-05 15:38                       ` Jan Beulich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1526996127.25123.3.camel@bitdefender.com \
    --to=aisaila@bitdefender.com \
    --cc=George.Dunlap@eu.citrix.com \
    --cc=JBeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=rcojocaru@bitdefender.com \
    --cc=tamas@tklengyel.com \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.