Aravindh Puthiyaparambil (aravindp)
2013-Apr-25 01:02 UTC
Implementing mem-access for PV guests
> > 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, soGetting 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
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.
> 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.
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.
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. >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
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. > >
Aravindh Puthiyaparambil (aravindp)
2013-Apr-25 17:57 UTC
Re: Implementing mem-access for PV guests
> -----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
Aravindh Puthiyaparambil (aravindp)
2013-May-15 19:44 UTC
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?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
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_*_accessIf 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.