[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
Hi, 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. Cheers, Stephen _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |