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

Re: [Xen-devel] [PATCH 1/3] xen: Add instruction length parameter in function hvm_inject_exception



> -----Original Message-----
> From: Keir Fraser [mailto:keir.xen@xxxxxxxxx] On Behalf Of Keir Fraser
> Sent: Saturday, May 26, 2012 4:42 AM
> To: Aravindh Puthiyaparambil
> Cc: Hao, Xudong; JBeulich@xxxxxxxx; xen-devel@xxxxxxxxxxxxx; Dong, Eddie;
> Ian Jackson; Zhang, Xiantao
> Subject: Re: [PATCH 1/3] xen: Add instruction length parameter in function
> hvm_inject_exception
> 
> On 25/05/2012 20:17, "Aravindh Puthiyaparambil" <aravindh@xxxxxxxxxxxx>
> wrote:
> 
> >> I don't like adding yet another parameter for all callers, especially as we
> >> should also be passing down the event type (sw interrupt, hw exception, 
> >> ...)
> >> and that would bloat the parameter list further.
> >>
> >> I attach a cleanup patch which packs everything into a new struct and
> >> renames hvm_inject_exception to hvm_inject_trap. I then define a couple of
> >> wrappers around that function for existing callers, so that their parameter
> >> lists actually *shrink*.
> >>
> >> Let me know what you think. If it looks acceptable I can check it in and we
> >> can build on top of this restructuring. The aim being to keep
> >> hvm/vmx_inject_trap dumb, and push down the knowledge from the callers
> into
> >> it.
> >
> > So I take it that with just this patch injecting of software
> > interrupts will not work and I should hold off on testing that out.
> > What is the plan for injecting software interrupts? Add another libxc
> > API for that?
> 

I'll write libxc API and correct the new function vmx_inject_trap() based on 
Keir's restructuring.

> Yes, everything represented in my 'struct hvm_trap', plus instruction
> length, which my patch doesn't add, should be part of the trap injection API
> through hvm_op hypercall and libxc. 

I can add instruction length in hvm_trap.

> So the toolstack can inject an arbitrary
> trap type, on an arbitrary vector, specify an error code (and cr2 for page
> fault), and specify an increment for rIP when the trap is successfully
> injected. All through one API function.
> 
> But as you say, my patch is just a proposed refactoring basis for Xudong's
> patches. It actually almost certainly reverts some behaviour that you guys
> actually want, which then gets added back in more sanely in patches that go
> on top.
> 

Sure, I'll finish our things.


>  -- Keir
> 


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


 


Rackspace

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