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

["Jan Beulich" <jbeulich@novell.com>]

>>> Keir Fraser <Keir.Fraser@cl.cam.ac.uk> 11.09.06 18:19 >>>
>On 11/9/06 5:12 pm, "Jan Beulich" <jbeulich@novell.com> 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.

That is because of the self modifying code that needs proper MP
synchronization. I know it's looking ugly, but I considered this the most
reasonable approach.
I'm not sure I understand what ugliness you find in the special/normal
distinction logic; one thing I'm thinking of is the additional meaning
added to the hypercall interface - I simply didn't want to introduce a
new sub-function there, especially since the existing one provided
ample room for the needed addition. But certainly, if you want that
changed, should be easily doable (even without significantly affecting
HP's code already utilizing the interface as we added it to our 3.0.2).

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

I considered that too, but rejected it because of opening these ports to
vm86 mode then, too (as I/O instructions are *not* susceptible to iopl there,
they only depend on the bitmap).

Jan