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

Re: [Xen-devel] Fwd: Need help - Assigning PCI device to HVM Windows domain


  • To: "Petersson, Mats" <Mats.Petersson@xxxxxxx>
  • From: GT <gtcharny@xxxxxxxxx>
  • Date: Thu, 16 Nov 2006 18:00:32 +0200
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Fri, 17 Nov 2006 01:35:24 -0800
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=sQEm3aKFD5bQ44WJmXo0W3UGSafDgdD3PDSRNf8/GWqKEd1lTA2zD4RvMTpLoqquKCR/we4MbPn8HbQ5WxN1vO5wSaw3CHeMeBe5bwuqoKxVyRKi7Pl/o+Wf372r+W0Xv232/GV4IaoDh+vagE2z1zsFzzyJSo/dXAXAR99ZelU=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

I found the issue. My NIC physically resides on bus 1 which is what I was telling Windows, but in qemu model there is no such creature, neither PCI-to-PCI bridge. I tricked Windows to think that it resides on bus 0 (using free device id), and it started to install the driver. The installation crashed the domain though ;)

Thanks a lot,

GT

On 11/16/06, Petersson, Mats <Mats.Petersson@xxxxxxx> wrote:
Assumning you have a native driver and the reads of the PCI
configuration is correct, then I don't see a reason why windows wouldn't
load the driver for it... However, if it loads the driver and the driver
says "I don't know about this hardware" for some reason (for example, it
maps the MMIO addresses for the device and tries to access it in some
way that doesn't actually yield the result you expected, the driver
would probably bail out saying "This is something wrong, not my
device"). This is done at driver load time, and the failure may not show
up the way you expect in the device manager.

I would start by checking that your MMIO mapping is actually mapping to
the device itself, rather than mapping to some different address in the
guest memory for DomU...

Also, I would expect it to be a lot easier to just adopt the PV
xen-network driver and leave the hardware on Dom0. It will be a little
bit slower, but much faster than doing the qemu-dm model of device
emulation.

--
Mats

> -----Original Message-----
> From: GT [mailto:gtcharny@xxxxxxxxx]
> Sent: 16 November 2006 11:57
> To: Petersson, Mats
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxx; gtcharny@xxxxxxxxx
> Subject: Re: [Xen-devel] Fwd: Need help - Assigning PCI
> device to HVM Windows domain
>
> Mats,
>
> Thank you very much for detailed explanation. I understand
> that I won't be able to get networking to work with native driver.
> If I am able to produce a PV driver as you suggested in (1) I
> need to get Windows to load it. PV driver would have the same
> vendor/device ids as native driver. My original assumption
> was that during device initialization only MMIO/IO ports are
> accessed, which I trap, and no DMA is performed. Even if some
> DMA configuration is done during initialization, I would
> expect to see a yellow bang or some other kind of error
> message, but in my case Windows doesn't seem to even try and
> load the driver.
>
> Is it possible to make Windows to load native driver (even
> not working), or do I need PV driver from the very beginning?
>
> Thanks a lot,
>
> GT
>
>
> On 11/16/06, Petersson, Mats <Mats.Petersson@xxxxxxx > wrote:
>
>       This will not work!
>
>       The reason is that we tell Windows that it's got X MB of memory,
>       starting at address 0, like it does in a standalone
> system. But in
>       reality, the memory actually given to the virtual
> machine could be ANY
>       location in memory (including a completely scattered
> selection of memory
>       blocks).
>
>       Since Windows is COMPLETELY unaware of this fact, your
> driver will give
>       what it believes is the physical address, in the range
> of 0..X MB to the
>       network card when it wants to send a packet of data.
> This is of course
>       not going to work if the packet to send isn't at the
> physical address
>       Windows thinks it is.
>
>       Let's take a trivial example: We give Windows a memory
> size of 256MB,
>       located in the contiguous section 256..512MB. The OS
> then wants to send
>       a packet on the network card that has the virtual
> address of 0x40867456
>       and the physical address of 0x123456 (just over 1MB),
> so the driver gets
>       the address for the packet (0x40867456). It calls the Win32 call
>       GetPhysicalAddress(), it will get back the address that
> Windows thinks
>       is the physical address, because it doesn't know that
> we've lied about
>       where the memory is. This means that it will get the
> address 0x123456.
>       This address should be in the 256MB..512MB range, but
> it isn't, it's
>       just over 1MB. So the packet sent will be wrong (if the
> network card
>       just grabs the data and there's no need for some extra
> "stuff" around
>       the data-packet, in which case the card will just plain
> refuse to
>       work!).
>
>       There are two solutions:
>       1. Implement within the driver for the network card an
> understanding of
>       the fact that guest-physical memory ( i.e. what your
> Windows OS thinks is
>       physical addresses) and machine physical addresses
> (those that are
>       ACTUALLY in the machine), by adding an extra layer of
> translation from
>       guest-physical to machine-physical where the driver is
> asking for a
>       physical address. Xen nows how to do this, so you
> should be able to use
>       the para-virtual driver calling mechanism to achieve
> this, but it does
>       assume that A) You are familiar with windows driver
> programming, B) that
>       you have source code for the driver(s) involved with
> your network card
>       and C) that you have a driver development kit (DDK)
> from MS installed on
>       some machine.
>
>       2. Wait for IOMMU hardware to be available (and
> relevant code in Xen) to
>       allow the hypervisor to map the guest-physical memory to
>       machine-physical address translation so that the guest
> doesn't need to
>       know the difference.
>
>       --
>       Mats
>
>       > -----Original Message-----
>       > From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>       > [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On
> Behalf Of GT
>       > Sent: 16 November 2006 08:30
>       > To: xen-devel@xxxxxxxxxxxxxxxxxxx
>       > Cc: gtcharny@xxxxxxxxx
>       > Subject: [Xen-devel] Fwd: Need help - Assigning PCI device to
>       > HVM Windows domain
>       >
>       > I forgot to mention that I allowed MMIO/IO ports access to
>       > WinXP according
>       > to NIC's PCI BARs.
>       >
>       > Thanks,
>       >
>       > GT
>       >
>       > ---------- Forwarded message ----------
>       > From: GT <gtcharny@xxxxxxxxx >
>       > Date: Nov 16, 2006 10:21 AM
>       > Subject: Need help - Assigning PCI device to HVM
> Windows domain
>       > To: xen-devel@xxxxxxxxxxxxxxxxxxx
> <mailto:xen-devel@xxxxxxxxxxxxxxxxxxx>
>       > <mailto:xen-devel@xxxxxxxxxxxxxxxxxxx>
>       >
>       > Hi,
>       >
>       > I am a newbie to Xen and I am trying to assign PCI NIC to
>       > Windows domain. I performed below steps, with no luck.
>       > It would be great if someone could point me to the
> right direction.
>       >
>       > I did as follows:
>       >
>       > 1) I've got WinXP installed over Xen, and got network working
>       > with pcnet model
>       > 2) I've hidden NIC from dom0 and verified that it does not
>       > appear with lspci
>       > 3) I've added interception of PCI scan from HVM domain (using
>       > 0xcf8/0xcfc ports interception),
>       > and when the PCI bud/dev/fun matched my physical NIC, I
>       > returned physical vendor/device id.
>       > 4) I've rebuilt/reinstalled all images, but WinXP didn't
>       > recognize any NIC device.
>       >
>       > Thanks ahead,
>       >
>       > GT
>       >
>       >
>       >
>
>
>
>
>
>



_______________________________________________
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®.