[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] enable port accesses with (almost) full register context


  • To: Jan Beulich <jbeulich@xxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
  • Date: Mon, 11 Sep 2006 17:19:16 +0100
  • Delivery-date: Mon, 11 Sep 2006 09:29:01 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcbVvga6RRR6PkGxEduR3QANk04WTA==
  • Thread-topic: [Xen-devel] [PATCH] enable port accesses with (almost) full register context

On 11/9/06 5:12 pm, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:

> This helped HP getting certain system management software going (in
> dom0) that triggers SMIs and depends upon other than port number
> and data register values being visible to the SMI handler.

That's quite rough. The 'special' handlers do more than just register
restore/save: what's all the locking and other assorted bits and pieces
doing in there? The 'special/normal' distinction at the interface is (I
suppose to some extent unavoidably) ugly and non-obvious.

Would it be cleaner to allow dom0 to have really direct access to some I/O
ports by allowing it to set a real I/O bitmap? I implemented I/O bitmaps via
emulation mainly because it makes context switching faster and it is less of
a pain to keep admin and guest bitmasks in sync if they are checked
synchronously. But a direct dom0-only bitmap would be a bit easier: quick to
turn on/off and no need to sync with admin bitmaps. Main downside is that
it'll slow down context-switch paths a little bit.

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