Thank you for your reply.
My patches say that some devices which require that emulated BAR
address is equal to actual BAR address. 
I don't have internal design specification of FC-HBA. But I presume
FC-HBA's device driver and firmware communicate via its internal memory.
And they use the same address to access internal memory.
On non-virtualized environment, device driver and firmware use the
same physical address. So they can communicate each other. On
virtualized environment, device driver use guest physical address,
while firmware use machine address. So they can't communicate.
My patches are not good solution to fix the issue. Hot-added device will
not work, because Guest OS configures BARs. And other changes will be
needed. For example, we need to change guest memory map to avoid
conflict between MMIO resource and memory. Additionally guest physical
address should be independent of machine address.
I don't have a good idea to solve the issue, currently.
If VT-d provides some method to solve the issue, it is nice.
--
Yuji Shimada
On 2008年9月02日 08:38:55 +0100
Keir Fraser <keir.fraser@xxxxxxxxxxxxx> wrote:
> The hvmloader side is perhaps plausible, since it only changes its behaviour
> if qemu exposes an already-configured BAR. Fair enough. I don't think that
> blanket always-use-physical-BAR-address is a great idea in qemu -- perhaps
> if it could be configurable that would be okay.
>
> -- Keir
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel