Re: [Xen-devel] Does xen-4.2.0 support VGA passthrough with the virtual machine created by xl command?

["Dr. Greg Wettstein" <greg@xxxxxxxxxxxxxxxxx>]

On Nov 28,  4:04pm, Konrad Rzeszutek Wilk wrote:
} Subject: Re: [Xen-devel] Does xen-4.2.0 support VGA passthrough with the v

> On Sat, Nov 17, 2012 at 09:17:36AM -0600, Dr. Greg Wettstein wrote:
> > On Nov 14,  3:40pm, "Dr. Greg Wettstein" wrote:
> > } Subject: Re: [Xen-devel] Does xen-4.2.0 support VGA passthrough with the v
> > 
> > Good morning, hope the day is going well for everyone.

> Heya!

Good evening, thanks for taking the time to respond.

> > We then went back and tested the 3.4.18 kernel and with both xm and xl
> > the guest faults on the first attempt to do an I/O port access.  All
> > factors (windows image, hardware, xen guest config) are held identical
> > so the difference would seem to be linked to the PCI passthrough
> > implementation between the two kernels.  I've copied Konrad on the
> > note since he would seem to be the person most familiar with this
> > area.
> > 
> > I'm including below a diff between a successful qemu-dm passthrough
> > session (2.6.32.45) and an unsuccessful session (3.4.18).  It would
> > appear 3.4.18 is getting the both the I/O port and memory ranges
> > wrong.

I was going to get an update back to everyone but got swamped by the
holiday weekend and a series of hardware failures I had to chase
after.

I took advantage of some time over the holiday weekend to chase down
the passthrough problems and now have it working well on 4.2.0 on all
kernels up to 3.4.19 using XM.  The original ATI patches have a bug in
them which causes qemu-dm to core dump on kernels somewhere after
2.6.32.x.

The original patches were bracketing the inb/outb instructions used in
ati_hw_read()/ati_hw_write with an ioperm() call.  The fix was a
straight forward replacement of the ioperm() call with a call to
iopl(3).

I seem to vaguely remember something about the kernel not properly
enforcing access controlls on in/out instructions but don't remember
if that was with a pvops or standard kernel.  In any event the kernel
behavior changed after 2.6.32.x which triggered the breakage.

I will post an updated version of the ATI patches under separate cover
in case anytone else is using them.

> Hm, can you also provide the 'lspci -vvv' with the 2.6.32.45 and
> 3.4.18 kernel?
>
> I am specifically looking to see if there are any:
> 
> [from git commit c341ca45ce56143804ef5a8f4db753e554e640b4]
> Author: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
> Date:   Tue Sep 25 16:48:24 2012 -0400
> 
>    
>       .. snip.. 
>     -       Region 0: [virtual] Memory at fe8c0000 (32-bit, non-prefetchable) 
> [size=128K]
>     -       Region 1: [virtual] Memory at fe800000 (32-bit, non-prefetchable) 
> [size=512K]
>     +       Region 0: Memory at fe8c0000 (32-bit, non-prefetchable) 
> [size=128K]
>     +       Region 1: Memory at fe800000 (32-bit, non-prefetchable) 
> [size=512K]
>             Region 2: I/O ports at c000 [size=32]
>     -       Region 3: [virtual] Memory at fe8e0000 (32-bit, non-prefetchable) 
> [size=16K]
>     +       Region 3: Memory at fe8e0000 (32-bit, non-prefetchable) [size=16K]

>     The [virtual] means that lspci read those entries from SysFS but when
>     it read them from the device it got a different value (0xfffffff).
>
> Any of those '[virtual]' ones? And how are you reserving the PCI devices?
> Are you using xen-pciback.hide on the Linux command line?
> 
> Does 'xm dmesg' give you an logs? Do the logs have any warnings?

We were under some time constraints to get Windows access back working
with a 'modern' kernel so once things were working reliably with xm I
didn't get a chance to fiddle with xl.  Given the behavior I saw on
2.6.32.x with xl I'm suspicious it may not work.  I'm hoping to get
back and do some testing early next week.

I just checked the machine (which is running a Windows session as I
write this) and dont see any [virtual] references.  This is on 3.4.18
but I also haven't had the chance to check xl on that kernel.  At
least a couple of hundred Windows 7 boots have been done with xm so
4.2.0 seems solid with that control plane.

With respect to reservation of the PCI device we have a script which
unplugs the device and re-plugs it after the Window session
completes.  The machines are Linux/Windows dual-use so the cards need
to be active for the Linux sessions.

The script can be picked up at the following location:

        ftp://ftp.enjellic.com/pub/xen/run-passthrough

I will give xl a try later in the weekend with the updated qemu-dm and
I will report back the results from a more throroughly controlled test
environment.

Thanks for the input, have a good weekend.

Greg

}-- End of excerpt from Konrad Rzeszutek Wilk

As always,
Dr. G.W. Wettstein, Ph.D.   Enjellic Systems Development, LLC.
4206 N. 19th Ave.           Specializing in information infra-structure
Fargo, ND  58102            development.
PH: 701-281-1686
FAX: 701-281-3949           EMAIL: greg@xxxxxxxxxxxx
------------------------------------------------------------------------------
"Not only is this incomprehensible, but the ink is ugly and the paper
 is from the wrong kind of tree."
                                -- Professor W.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel