[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>
  • 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
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: Aceeupoc2M1WkAqtEdy0gAAX8io7RQ==
  • Thread-topic: [Xen-devel] [patch 1/2] HV: allow HVM virtual PICs to have their interrupt vector reprogrammed

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


 


Rackspace

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