I don't think direct mapping is important. Today every i/o port access in a
PV driver domain traps to the hypervisor, and we don't see a significant
overhead for doing this with any non-ancient hardware, because i/o ports are
not used on data paths much these days. Of course a VMEXIT is rather more
expensive than a #GP, but still I think this is an optimisation that can
wait. At the moment most people are unable to make Xen + VT-d work with
their devices at all, let alone with 99.999% of fully native performance.
;-)
-- Keir
On 7/1/08 15:52, "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx> wrote:
> Yes, the guest OS should be allowed to remap BAR.
> But I don't know are there any OS will try to remap BAR, except Vista.
> And even in Vista, we can still try to disable BAR remapping through
> bcdedit.
> The benifit to set guest IO port address same as physical one is, if
> guest didn't try to remap, then it can access IO port directly without
> cause VMExit. That may help performance. Although IO port is not so
> important for PCI device now, but that may still be helpful on some
> situation, considering USB 1.1 device.
> Of course,we need still support the BAR remapping, what we can do is,
> our guest BIOS (hvmloader in fact) will set the initial value same to
> physical one.
>
>
> -- Yunhong Jiang
>
> xen-devel-bounces@xxxxxxxxxxxxxxxxxxx <> wrote:
>> Why not keep the level of indirection? After all, the guest OS should
> be
>> allowed to remap any BAR and we should support that.
>>
>> -- Keir
>>
>> On 7/1/08 11:47, "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx> wrote:
>>
>>> I'm considering to make guest IO port address same as physical one
> for
>>> passthrough hvm domain. However, in hvmloader.c's pci_setup(), the
>>> io_base is hardcoded as 0xc000, are there any special reason for this
>>> value? (I checked and seems it comes from original qemu's code)
>>>
>>> Can anyone give me some hints on it?
>>>
>>> Thanks
>>> -- Yunhong Jiang
>>>
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@xxxxxxxxxxxxxxxxxxx
>>> http://lists.xensource.com/xen-devel
>>
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@xxxxxxxxxxxxxxxxxxx
>> http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|