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

["Petersson, Mats" <Mats.Petersson@xxxxxxx>]

> -----Original Message-----
> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Andrew D. Ball
> Sent: 16 November 2006 15:44
> To: xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: [Fwd: RE: [Xen-devel] Fwd: Need help - Assigning PCI 
> device to HVM Windows domain]
> 
> -------- Forwarded Message --------
> From: Andrew D. Ball <aball@xxxxxxxxxxxxxxxxxx>
> Reply-To: aball@xxxxxxxxxxxxxxxxxx
> To: Petersson, Mats <Mats.Petersson@xxxxxxx>
> Subject: RE: [Xen-devel] Fwd: Need help - Assigning PCI device to HVM
> Windows domain
> Date: Thu, 16 Nov 2006 10:43:48 -0500
> 
> For the IOMMU stuff, I wonder how far along the Calgary support is in
> Xen.  Granted, the Intel and AMD versions will become ubiquitous and
> Calgary almost certainly will not ...  Also tricks available 
> with stuff
> like AGP apertures, right?

Sure, there is some work ongoing for Calgary (according to Muli), but
that is primarily targetted towards PV domains rather than HVM domains. 

I think Mark Langsdorf has been owkring on GART-based IOMMU, but I don't
know what the status is on this...

I don't know when ours or Intels hardware will be available (I hope
sooner rather than later, because it will solve a whole bunch of peoples
problems...)

--
Mats
> 
> Peace.
> Andrew
> 
> On Thu, 2006-11-16 at 11:50 +0100, Petersson, Mats 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> 
> > > 
> > > 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
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel