|
|
|
|
|
|
|
|
|
|
xen-devel
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 |
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
|
|
|
|
|