This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: Keir Fraser <keir@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [patch 1/2] HV: allow HVM virtual PICs to have their interrupt vector reprogrammed
From: "Stephen C. Tweedie" <sct@xxxxxxxxxx>
Date: Fri, 25 May 2007 11:41:37 +0100
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Fri, 25 May 2007 03:40:03 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C27C6C7C.F7F9%keir@xxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903
References: <C27C6C7C.F7F9%keir@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx

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