[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Source of guest-physical address in PCI BAR for HVM domain?


  • To: "Samuel Thibault" <samuel.thibault@xxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
  • From: "David Stone" <unclestoner@xxxxxxxxx>
  • Date: Fri, 4 Jan 2008 17:30:33 -0500
  • Delivery-date: Fri, 04 Jan 2008 14:30:55 -0800
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=kGu9FTDnqb9IyBy0zLJyWReOy/P4E4c4iIzCWxoIxHKXrmqPvXFGk4GlWjF5fWvipsZen2umxqGGVoJfYZYBj0PQdylkmypmmBdkCNM3qnPnH46vlzrUlm2ceQ5h6hA8gT/OGmxxadI07MdS0gsrvkVBqebUfKnRFwT07UMC8zw=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.