[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

  • To: "Stephen C. Tweedie" <sct@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Keir Fraser <keir@xxxxxxxxxxxxx>
  • Date: Fri, 25 May 2007 10:35:40 +0100
  • Delivery-date: Fri, 25 May 2007 02:34:08 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AceesA6dTW0A5gqjEdy0gAAX8io7RQ==
  • Thread-topic: [Xen-devel] [patch 1/2] HV: allow HVM virtual PICs to have their interrupt vector reprogrammed

On 22/5/07 16:42, "Stephen C. Tweedie" <sct@xxxxxxxxxx> wrote:

>> So the fix here is to first of all extend the virtual PIC provided by
>> the hypervisor, supporting a new 2-byte control sequence which lets the
>> guests change the interrupt vectors _without_ fully reinitialising the
>> PIC
> 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!

Would it be possible to hack this PIC transition code into
vmx_world_{save,restore}? 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?

If not, at least the patch to Xen itself needs to be fixed for correctness
and code style, and preferably enclosed in ifdef or given a big comment so
that it's clear that the hack's lifetime is limited to vmxassist's lifetime.


Xen-devel mailing list



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