WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: "Samuel Thibault" <samuel.thibault@xxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-devel] Source of guest-physical address in PCI BAR for HVM domain?
From: "David Stone" <unclestoner@xxxxxxxxx>
Date: Fri, 4 Jan 2008 17:30:33 -0500
Delivery-date: Fri, 04 Jan 2008 14:30:55 -0800
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=xBdVYHvTRPae4P/0cwpWM9p87kDTzztEWluQwjWn4Zw=; b=gADqO7xi89VB5Umh69WJOcnNVT+f0yCraBbWcqG3SF+pYPdGmMFtS1EEiFGpFdbI3GoJF4iTQy0LZS460wzO1JolZzKlAjzyvOGV2g0JJD5b0nPPycpfmDT/aRCOB7OANHajhQV/7dnBChNhGs1HEDHdueO3ezhoryqS/y+ZEFA=
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=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20080104183149.GM5666@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <1a74a8410801040835t5bb40477u128d310f9d1ed201@xxxxxxxxxxxxxx> <20080104164712.GK5666@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <1a74a8410801041025t66557b3bxd596689e902d4c97@xxxxxxxxxxxxxx> <20080104183149.GM5666@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> > 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