| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] Source of guest-physical address in PCI BAR for HVM doma
> > Why would the hypervisor be doing the initial PCI BAR setup?
>
> The hypervisor does nothing but retransmit what the HVM domain performs.
> Remember that instructions of the qemu BIOS are run in the HVM domain,
> not in qemu, which only gets triggered when the BIOS actually I/O ports
> or memory.
OK now I understand, thanks.
> > Yes, I didn't mention the most important part: the device in question
> > is a physical PCI device (a PCI Express graphics card) that I am
> > passing through to the Windows 2003 guest domain via VT-d. (The VT-d
> > support generally works for me because I can pass a PCI NIC through no
> > problem.) (I realize VT-d'ing a PCI-XP graphics card is
> > experimental...but that's what I'm doing, experimenting...).
>
> Then maybe the qemu BIOS has troubles with that device?
Maybe, I guess the next step is to start troubleshooting/debugging the
qemu BIOS to see what it is doing. BTW, the specific thing that the
qemu BIOS is doing that I think is wrong and may be causing a
subsequent machine check (?) is that it is assigning a guest-physical
address of 0x10000000 to one of the device's BARs. The problem with
this is that I am assigning 1GB of memory to this domain, which means
that the addresses 0x00000000-0x40000000 should be assigned to the
domain's system memory...and indeed that is what the domain's MTRRs
seem to show. I know that some low physical addresses correspond to
system resources but doesn't assigning to a device's BAR an address
that is right in the middle of system memory seem wrong? I don't see
this ever happen for any other device.
One more question: I actually tried using a PCI graphics card to pass
through via VT-d instead of a PCI-XP graphics card and it
worked...sort of. The domain doesn't cause a machine check (which is
always nice). When I look at Device Manager in Windows I see both the
emulated Cirrus card and the passed-through physical PCI graphics card
as hoped for. However, the driver for the Cirrus card isn't
loaded...it says there is a resource conflict. I haven't been able to
figure out what resource is being contended for. But anyway, from the
guest Windows OS perspective card, the Cirrus card is _not_ in use,
but the physical card is. What surprises me is that I still can
interact with the guest OS through a loopback VNC session to qemu-dm
as normal. I thought qemu exposed the framebuffer by acting as the
Cirrus card...but in this case it seems to be working even when the
physical card is being used?
Thanks,
Dave
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home