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