WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: "Stephen C. Tweedie" <sct@xxxxxxxxxx>
Subject: Re: [Xen-devel] [patch 1/2] HV: allow HVM virtual PICs to have their interrupt vector reprogrammed
From: Keir Fraser <keir@xxxxxxxxxxxxx>
Date: Fri, 25 May 2007 11:51:09 +0100
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Fri, 25 May 2007 03:49:35 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <1180089697.9977.8.camel@xxxxxxxxxxxxxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Aceeupoc2M1WkAqtEdy0gAAX8io7RQ==
Thread-topic: [Xen-devel] [patch 1/2] HV: allow HVM virtual PICs to have their interrupt vector reprogrammed
User-agent: Microsoft-Entourage/11.3.3.061214
On 25/5/07 11:41, "Stephen C. Tweedie" <sct@xxxxxxxxxx> wrote:

>> 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.

Gack! :-)

I'm not actually a fan of the shareing of structures between public
interfaces and internal implementations because of precisely this kind of
issue. You end up with either implementation details getting made visible to
external entities, or you end up putting private state in inappropriate
locations to avoid scuzzing the public interfaces. The save/restore
interfaces are something I need to look into a bit more thoroughly.

 -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel