Implementing mem-access for PV guests

Implementing mem-access for PV guests

[Aravindh Puthiyaparambil (aravindp)]

> > I'm finally to a point where I can start looking at this more closely.
> > I'm trying to wrap my head around the shadow code to figure out the
> > right course of action.
> >
> > I'd want HVMOP_set_mem_access to work with both shadow and EPT, so

Getting this to work with shadow would allow non-NPT HVM guests to have mem_access support or will this also extend to PV guests? I am interested in getting this to work for PV guests so I was wondering how much extra work that would be. I can definitely help out with this effort.

Thanks,
Aravindh

Re: Implementing mem-access for PV guests

[Tim Deegan]

At 01:02 +0000 on 25 Apr (1366851740), Aravindh Puthiyaparambil (aravindp) wrote:
> > > I'm finally to a point where I can start looking at this more closely.
> > > I'm trying to wrap my head around the shadow code to figure out the
> > > right course of action.
> > >
> > > I'd want HVMOP_set_mem_access to work with both shadow and EPT, so
> 
> Getting this to work with shadow would allow non-NPT HVM guests to
> have mem_access support or will this also extend to PV guests?

It could extend to PV guests as long as you're willing to run them on
shadow pagetables (i.e. with a significant performance hit).

> I am interested in getting this to work for PV guests so I was
> wondering how much extra work that would be. I can definitely help out
> with this effort.

I think you'd have to take a good look at the hypercall interface -- PV
guests have more ways of causing the hypervisor to read and write memory
for them (e.g. the MMU ops) which wouldn't be intercepted by shadow PTs.
It certainly ought to be possible, though.

Tim.

Re: Implementing mem-access for PV guests

[Andres Lagar-Cavilla]

> At 01:02 +0000 on 25 Apr (1366851740), Aravindh Puthiyaparambil (aravindp) wrote:
>>>> I'm finally to a point where I can start looking at this more closely.
>>>> I'm trying to wrap my head around the shadow code to figure out the
>>>> right course of action.
>>>> 
>>>> I'd want HVMOP_set_mem_access to work with both shadow and EPT, so
>> 
>> Getting this to work with shadow would allow non-NPT HVM guests to
>> have mem_access support or will this also extend to PV guests?
> 
> It could extend to PV guests as long as you're willing to run them on
> shadow pagetables (i.e. with a significant performance hit).
> 
>> I am interested in getting this to work for PV guests so I was
>> wondering how much extra work that would be. I can definitely help out
>> with this effort.
> 
> I think you'd have to take a good look at the hypercall interface -- PV
> guests have more ways of causing the hypervisor to read and write memory
> for them (e.g. the MMU ops) which wouldn't be intercepted by shadow PTs.
> It certainly ought to be possible, though.

Tim,
wouldn't intercepting all calls to get_page_from_gfn ought to cover it? It would also take care of men access not being able to keep track of foreign maps.

Andres

> 
> Tim.

Re: Implementing mem-access for PV guests

[Tim Deegan]

At 10:48 -0400 on 25 Apr (1366886887), Andres Lagar-Cavilla wrote:
> > At 01:02 +0000 on 25 Apr (1366851740), Aravindh Puthiyaparambil (aravindp) wrote:
> >>>> I'm finally to a point where I can start looking at this more closely.
> >>>> I'm trying to wrap my head around the shadow code to figure out the
> >>>> right course of action.
> >>>> 
> >>>> I'd want HVMOP_set_mem_access to work with both shadow and EPT, so
> >> 
> >> Getting this to work with shadow would allow non-NPT HVM guests to
> >> have mem_access support or will this also extend to PV guests?
> > 
> > It could extend to PV guests as long as you're willing to run them on
> > shadow pagetables (i.e. with a significant performance hit).
> > 
> >> I am interested in getting this to work for PV guests so I was
> >> wondering how much extra work that would be. I can definitely help out
> >> with this effort.
> > 
> > I think you'd have to take a good look at the hypercall interface -- PV
> > guests have more ways of causing the hypervisor to read and write memory
> > for them (e.g. the MMU ops) which wouldn't be intercepted by shadow PTs.
> > It certainly ought to be possible, though.
> 
> Tim,
> wouldn't intercepting all calls to get_page_from_gfn ought to cover
> it?

I doubt it -- in the PV code, an MFN is and MFN and needs no
translation; get_page_from_gfn() &c are only called from code that's
common to both PV and HVM.

Tim.

Re: Implementing mem-access for PV guests

[Andres Lagar-Cavilla]

[-- Attachment #1.1: Type: text/plain, Size: 1732 bytes --]

Not disputing you need shadows.

My point is that, for both PV and HVM, get page from gfn would be the way
to catch grant and foreign mappings. Which mem access currently can't. IIRC.

Andres
On Apr 25, 2013 11:40 AM, "Tim Deegan" <tim@xen.org> wrote:

> At 10:48 -0400 on 25 Apr (1366886887), Andres Lagar-Cavilla wrote:
> > > At 01:02 +0000 on 25 Apr (1366851740), Aravindh Puthiyaparambil
> (aravindp) wrote:
> > >>>> I'm finally to a point where I can start looking at this more
> closely.
> > >>>> I'm trying to wrap my head around the shadow code to figure out the
> > >>>> right course of action.
> > >>>>
> > >>>> I'd want HVMOP_set_mem_access to work with both shadow and EPT, so
> > >>
> > >> Getting this to work with shadow would allow non-NPT HVM guests to
> > >> have mem_access support or will this also extend to PV guests?
> > >
> > > It could extend to PV guests as long as you're willing to run them on
> > > shadow pagetables (i.e. with a significant performance hit).
> > >
> > >> I am interested in getting this to work for PV guests so I was
> > >> wondering how much extra work that would be. I can definitely help out
> > >> with this effort.
> > >
> > > I think you'd have to take a good look at the hypercall interface -- PV
> > > guests have more ways of causing the hypervisor to read and write
> memory
> > > for them (e.g. the MMU ops) which wouldn't be intercepted by shadow
> PTs.
> > > It certainly ought to be possible, though.
> >
> > Tim,
> > wouldn't intercepting all calls to get_page_from_gfn ought to cover
> > it?
>
> I doubt it -- in the PV code, an MFN is and MFN and needs no
> translation; get_page_from_gfn() &c are only called from code that's
> common to both PV and HVM.
>
> Tim.
>

[-- Attachment #1.2: Type: text/html, Size: 2333 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: Implementing mem-access for PV guests

[Tim Deegan]

Please don't top-post.

At 12:31 -0400 on 25 Apr (1366893074), Andres Lagar-Cavilla wrote:
> Not disputing you need shadows.

What I was trying to say is, there are probably PV-only paths that don't
use get_page_from_gfn().  Or at least you'd have to audit the code
looking for them if you wanted to hook for mem-access there. 

Tim.

> Andres
> On Apr 25, 2013 11:40 AM, "Tim Deegan" <tim@xen.org> wrote:
> 
> > At 10:48 -0400 on 25 Apr (1366886887), Andres Lagar-Cavilla wrote:
> > > > At 01:02 +0000 on 25 Apr (1366851740), Aravindh Puthiyaparambil
> > (aravindp) wrote:
> > > >>>> I'm finally to a point where I can start looking at this more
> > closely.
> > > >>>> I'm trying to wrap my head around the shadow code to figure out the
> > > >>>> right course of action.
> > > >>>>
> > > >>>> I'd want HVMOP_set_mem_access to work with both shadow and EPT, so
> > > >>
> > > >> Getting this to work with shadow would allow non-NPT HVM guests to
> > > >> have mem_access support or will this also extend to PV guests?
> > > >
> > > > It could extend to PV guests as long as you're willing to run them on
> > > > shadow pagetables (i.e. with a significant performance hit).
> > > >
> > > >> I am interested in getting this to work for PV guests so I was
> > > >> wondering how much extra work that would be. I can definitely help out
> > > >> with this effort.
> > > >
> > > > I think you'd have to take a good look at the hypercall interface -- PV
> > > > guests have more ways of causing the hypervisor to read and write
> > memory
> > > > for them (e.g. the MMU ops) which wouldn't be intercepted by shadow
> > PTs.
> > > > It certainly ought to be possible, though.
> > >
> > > Tim,
> > > wouldn't intercepting all calls to get_page_from_gfn ought to cover
> > > it?
> >
> > I doubt it -- in the PV code, an MFN is and MFN and needs no
> > translation; get_page_from_gfn() &c are only called from code that's
> > common to both PV and HVM.
> >
> > Tim.
> >

Re: Implementing mem-access for PV guests

[Aravindh Puthiyaparambil (aravindp)]

> -----Original Message-----
> From: Tim Deegan [mailto:tim@xen.org]
> Sent: Thursday, April 25, 2013 2:55 AM
> To: Aravindh Puthiyaparambil (aravindp)
> Cc: Cutter 409; xen-devel@lists.xensource.com
> Subject: Re: Implementing mem-access for PV guests
> 
> At 01:02 +0000 on 25 Apr (1366851740), Aravindh Puthiyaparambil (aravindp)
> wrote:
> > > > I'm finally to a point where I can start looking at this more closely.
> > > > I'm trying to wrap my head around the shadow code to figure out
> > > > the right course of action.
> > > >
> > > > I'd want HVMOP_set_mem_access to work with both shadow and EPT,
> so
> >
> > Getting this to work with shadow would allow non-NPT HVM guests to
> > have mem_access support or will this also extend to PV guests?
> 
> It could extend to PV guests as long as you're willing to run them on shadow
> pagetables (i.e. with a significant performance hit).

Given that  64-bit PV already takes a performance hit from syscalls, I would rather not taken the added hit with shadow PTs.
 
> > I am interested in getting this to work for PV guests so I was
> > wondering how much extra work that would be. I can definitely help out
> > with this effort.
> 
> I think you'd have to take a good look at the hypercall interface -- PV guests
> have more ways of causing the hypervisor to read and write memory for
> them (e.g. the MMU ops) which wouldn't be intercepted by shadow PTs.
> It certainly ought to be possible, though.

OK, I will take a look at the hypercall interface. Does any shadowing come in to the picture with a PV guest when using a modern pv_ops? 

Thanks,
Aravindh

Re: Implementing mem-access for PV guests

[Aravindh Puthiyaparambil (aravindp)]

> > At 01:02 +0000 on 25 Apr (1366851740), Aravindh Puthiyaparambil
> > (aravindp)
> > wrote:
> > > > > I'm finally to a point where I can start looking at this more closely.
> > > > > I'm trying to wrap my head around the shadow code to figure out
> > > > > the right course of action.
> > > > >
> > > > > I'd want HVMOP_set_mem_access to work with both shadow and
> EPT,
> > so
> > >
> > > Getting this to work with shadow would allow non-NPT HVM guests to
> > > have mem_access support or will this also extend to PV guests?
> >
> > It could extend to PV guests as long as you're willing to run them on
> > shadow pagetables (i.e. with a significant performance hit).
> 
> Given that  64-bit PV already takes a performance hit from syscalls, I would
> rather not taken the added hit with shadow PTs.
> 
> > > I am interested in getting this to work for PV guests so I was
> > > wondering how much extra work that would be. I can definitely help
> > > out with this effort.
> >
> > I think you'd have to take a good look at the hypercall interface --
> > PV guests have more ways of causing the hypervisor to read and write
> > memory for them (e.g. the MMU ops) which wouldn't be intercepted by
> shadow PTs.
> > It certainly ought to be possible, though.
> 
> OK, I will take a look at the hypercall interface. Does any shadowing come in
> to the picture with a PV guest when using a modern pv_ops?

Tim,

As I am looking at code, I see most of the mem_event / mem_access naming is HVM specific. Given that I am enabling it for PV, shouldn't the names be changed to something more generic? 

On the tools side, I was thinking of renaming:
HVMMEM_access* to XENMEM_*
HVMOP_*_access to XENMEM_*_access

Create xc_domain_*_access() or xc_*_access() and make them wrappers that call xc_hvm_*_access() or vice-versa. Then move the functions to xc_domain.c or xc_mem_access.c. This way I am hoping the exisiting APIs will still work.

Something similar would have to be done in the hypervisor side as most of the mem_access hypercalls falls under HVM ops and do_hvm_op(). What should I do there? Fold everything in to memory ops? Please advise.

Thanks,
Aravindh

Re: Implementing mem-access for PV guests

[Tim Deegan]

Hi,

At 19:44 +0000 on 15 May (1368647046), Aravindh Puthiyaparambil (aravindp) wrote:
> As I am looking at code, I see most of the mem_event / mem_access
> naming is HVM specific. Given that I am enabling it for PV, shouldn't
> the names be changed to something more generic?
> 
> On the tools side, I was thinking of renaming:
> HVMMEM_access* to XENMEM_*
> HVMOP_*_access to XENMEM_*_access

If you like -- presumably you'll be adding a new hypercall interface
for the PV guests; we can use that for both and keep the old hvm_op
hypercall interface as an alias.

> Create xc_domain_*_access() or xc_*_access() and make them wrappers
> that call xc_hvm_*_access() or vice-versa. Then move the functions to
> xc_domain.c or xc_mem_access.c. This way I am hoping the exisiting
> APIs will still work.

Sounds about right, though I'd want a toolstack maintainer's opinion.

> Something similar would have to be done in the hypervisor side as most
> of the mem_access hypercalls falls under HVM ops and do_hvm_op(). What
> should I do there? Fold everything in to memory ops? Please advise.

Yes, I think a memory op would be OK, or a domctl. 

Tim.