Re: [RFC PATCH 0/3] generic hypercall support

Gregory Haskins
2009-05-07T19:30:31Z

[-- Attachment #1: Type: text/plain, Size: 1913 bytes --]

Chris Wright wrote:
> * Gregory Haskins (ghaskins@novell.com) wrote:
>
>> Chris Wright wrote:
>>
>>> * Avi Kivity (avi@redhat.com) wrote:
>>>
>>>> Gregory Haskins wrote:
>>>>
>>>>> Cool, I will code this up and submit it. While Im at it, Ill run it
>>>>> through the "nullio" ringer, too. ;) It would be cool to see the
>>>>> pv-mmio hit that 2.07us number. I can't think of any reason why this
>>>>> will not be the case.
>>>>>
>>>>>
>>>> Don't - it's broken. It will also catch device assignment mmio and
>>>> hypercall them.
>>>>
>>> Not necessarily. It just needs to be creative w/ IO_COND
>>>
>> Hi Chris,
>> Could you elaborate? How would you know which pages to hypercall and
>> which to let PF?
>>
>
> Was just thinking of some ugly mangling of the addr (I'm not entirely
> sure what would work best).
>
Right, I get the part about flagging the address and then keying off
that flag in IO_COND (like we do for PIO vs MMIO).

What I am not clear on is how you would know to flag the address to
begin with.

Here's a thought: "PV" drivers can flag the IO (e.g. virtio-pci knows it
would never be a real device). This means we route any io requests from
virtio-pci though pv_io_ops->mmio(), but not unflagged addresses. This
is not as slick as boosting *everyones* mmio speed as Avi's original
idea would have, but it is perhaps a good tradeoff between the entirely
new namespace created by my original dynhc() proposal and leaving them
all PF based.

This way, its just like using my dynhc() proposal except the mmio-addr
is the substitute address-token (instead of the dynhc-vector).
Additionally, if you do not PV the kernel the IO_COND/pv_io_op is
ignored and it just slow-paths through the PF as it does today. Dynhc()
would be dependent on pv_ops.

Thoughts?

-Greg

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 266 bytes --]