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

Re: [Xen-devel] [patch 1/2] HV: allow HVM virtual PICs to have their interrupt vector reprogrammed


On Fri, 2007-05-25 at 10:35 +0100, Keir Fraser wrote:

> > And this is the patch for that.  The new control sequence is:
> Yeees. I have no problem with this hack in principle (in fact we definitely
> want to take it), but this implementation is not good. The
> custom_revector_flag cannot be a static variable: it needs to be per-domain!

Right, of course.  An alternative is to add a field to the vpic struct,
but that struct is a public one (used for domain save/restore I think)
so there are more dependencies involved in doing it that way.  That
would also cover the (hopefully rare) case when we get a save/restore
during the bootloader.

> Would it be possible to hack this PIC transition code into
> vmx_world_{save,restore}? 

Hmm.  That should be possible --- we know when we're entering vmxassist
at that point, and it's precisely when that happens that we want to have
the translated PIC in place.

> This would restrict the changes to code that will
> obviously be killed off when vmxassist is removed, and might perhaps be
> simpler and faster than making the changes via specialised pokes of the PIC
> device from vmxassist itself?

Faster, yes, but speed was not an issue for the patch --- this is
something only ever expected to happen during boot-loading, which is
usually not performance-critical.  It's not greatly simpler --- it still
relies on poking at the vPIC from a vmxassist transition --- but at
least the two parts of the layering violation sit together in the
hypervisor in this case, which is an advantage.

I'll try putting a patch like this together.


Xen-devel mailing list



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