RE: Selective Passthrough Virtualization

["Petersson, Mats" <Mats.Petersson@amd.com>]

 

> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com 
> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of 
> Keir Fraser
> Sent: 22 January 2007 08:49
> To: Kaushik Barde; xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] Selective Passthrough Virtualization
> 
> On 22/1/07 6:13 am, "Kaushik Barde" <Kaushik_Barde@Phoenix.com> wrote:
> 
> > I was trying to get Xen-FC5 DOM0 to allow Windows-XP to 
> have 100% control of
> > the sound device on the VT enabled HW platform.  After 
> poking at this for a
> > bit we ended up in a place where we though the current Xen 
> didn't support this
> > without having custom drivers that understood it was being 
> virtualized.   Have
> > you found a way around this?
> 
> It's unlikely to be possible because the device's DMA engine 
> will expect to
> be programmed with physical memory addresses, but the Windows 
> guest only
> sees virtualised physical addresses so it will program 
> incorrect values and
> DMA to random places. Extra chipset support (which isn't yet 
> available) is
> required to support real device drivers in fully virtualised guests.

Indeed. The only way to support this would be by using a IOMMU. The
problem is the same for any device that uses direct memory accessing
(bus mastering), which is all PCI/AGP devices [there may be SOME PCI
devices that don't do this, but they are very rare for sure - a port-80
card is one of the examples that DOESN'T, but then that's a very special
piece of hardware in the first place. Simple serial port cards may also
not require bus mastering to operate correctly, and it is technically
possible to run an IDE controller without DMA - but I very much doubt
that there are any sound-cards that don't need DMA, nor any advanced
graphics cards...]. 

The reason for this is that the OS expects to be loaded in memory around
address zero and upwards for as much memory as there is. In a virtual
machine, this can only happen to ONE of the OS's loaded, at very best.
Because of this, Xen fakes the memory address that the OS "thinks" it's
at to be zero to whatever size memory it's given, but in reality, the OS
is loaded at some other place. The "difference" is fixed up in the
Shadow Page Table, which is maintained by Xen, but the OS is completely
unaware of this. 

So, as a very simple example, Xen+Dom0 takes up 0..256M, we then start a
Windows domain, and give it 256M..512M. But Windows THINKS it's address
is 0..256M, because that's how a normal PC would appear if it had 256M
of memory. 

A sampled sound is loaded into memory (within Widnows) at 100M, which is
ACTUALLY 100M+256M, and it's sent to the sound-card. The sound-card
receives the address 100M - but it's 256M wrong, so you get "rubbish"
sent to the sound card. 

An IOMMU could be programmed to understand the same difference of where
memory is ACTUALLY in the physical machine sense. 

Note that the above example is simplified, in actual world, the memory
may be scattered about in any which way, so it's not just an added
offset, but the each 4K of guest memory may very well be completely
different to the next 4K (which in itself causes a problem for PCI
devices, as the card may not allow for "scatter/gather", so you'd have
to make sure that all packets sent to the card are contiguous pages,
which there's absolutely no guarantee of in a HVM domain). Normally,
when the OS runs on "real hardware" it can allocate either physically
contiguous or "don't care" sections of memory (in a driver-mode, if it's
a "regular application", it's not allowed to ask for contiguous memory,
as that's a "scarce resource"), but because Xen is laying underneath and
"changing". 

--
Mats
> 
>  -- Keir
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 
> 
>