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

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

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!
> 
> > On Nov 13, 10:02am, Ian Campbell wrote:
> > } Subject: Re: [Xen-devel] Does xen-4.2.0 support VGA passthrough with the v
> > 
> > Good afternoon, hope the week is going well for everyone.
> > 
> > > On Tue, 2012-11-13 at 06:30 +0000, Qian Hu wrote:
> > > 
> > > > With spice tool, I have to create a VM by xl command, and now I am
> > > > wondering if it supports VGA passghrouth?
> > 
> > > This list is for the development of Xen. You';d probably have more
> > > luck with these sorts of support requests on the xen-users list.
> > 
> > That would normally be the case but I'm suspicious there are issues
> > with VGA passthrough in 4.2.0.
> 
> I just wanted to follow up to the list on the status of passthrough
> issues.
> 
> We reverted our test machine back to the 2.6.32.45 kernel which we had
> been using in production.  That kernel was based on Jeremy's GIT
> tree.  Using xm and the updated ATI patches which I referenced in my
> original mail passthrough works as it should.
> 
> Passthrough does not work with xl.  Windows started but fell into its
> text mode rescue screen and registered a crash dump.  It flashed the
> screen back and forth between a stipled blue/grey and totally black
> screen a few times and then locked the physical machine up solidly.
> 
> On the next boot I thought about it but declined to register the crash
> dump with Microsoft.... :-)

Ha!
> 
> 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.

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?
 
> 
> Let me know if I can forward any additional information or run any
> additional tests.
> 
> Have a good weekend.
> 
> Greg
> 
> qemu-dm log diff: ---------------------------------------------------------
> 1c1
> < domid: 3
> ---
> > domid: 1
> 3,5c3,5
> < Watching /local/domain/0/device-model/3/logdirty/cmd
> < Watching /local/domain/0/device-model/3/command
> < Watching /local/domain/3/cpu
> ---
> > Watching /local/domain/0/device-model/1/logdirty/cmd
> > Watching /local/domain/0/device-model/1/command
> > Watching /local/domain/1/cpu
> 9c9
> < Guest uuid = 7fcefb13-d1ef-105b-e38c-1e1454411e80
> ---
> > Guest uuid = eab6bbbb-4819-b970-a83c-03288a1541ad
> 14c14
> < xs_read(/local/domain/0/device-model/3/xen_extended_power_mgmt): read error
> ---
> > xs_read(/local/domain/0/device-model/1/xen_extended_power_mgmt): read error
> 18,20c18,20
> < xs_read(/local/domain/3/log-throttling): read error
> < qemu: ignoring not-understood drive `/local/domain/3/log-throttling'
> < medium change watch on `/local/domain/3/log-throttling' - unknown device, 
> ignored
> ---
> > xs_read(/local/domain/1/log-throttling): read error
> > qemu: ignoring not-understood drive `/local/domain/1/log-throttling'
> > medium change watch on `/local/domain/1/log-throttling' - unknown device, 
> > ignored
> 69,106c69,77
> < pt_iomem_map: e_phys=f1020000 maddr=c1a00000 type=0 len=131072 index=2 
> first_map=1
> < pt_iomem_map: e_phys=f1060000 maddr=c1b22000 type=0 len=4096 index=0 
> first_map=1
> < pt_ioport_map: e_phys=c600 pio_base=3000 len=256 index=4 first_map=1
> < pt_ioport_map: e_phys=c600 pio_base=3000 len=256 index=4 first_map=0
> < ati_gfx_init: guest_pio_bar = 0xc600, host_pio_bar = 0x3000, pio_size=0x100 
> guest_mmio_bar1=0xe0000000, guest_mmio_bar2=0x0
> < platform_fixed_ioport: changed ro/rw state of ROM memory area. now is rw 
> state.
> < platform_fixed_ioport: changed ro/rw state of ROM memory area. now is ro 
> state.
> < pt_pci_read_config: [00:06:0] Error: Failed to read register with invalid 
> access size alignment. [Offset:0eh][Length:4]
> < pt_pci_read_config: [00:06:0] Error: Failed to read register with invalid 
> access size alignment. [Offset:0eh][Length:4]
> < pt_pci_read_config: [00:06:0] Error: Failed to read register with invalid 
> access size alignment. [Offset:0eh][Length:4]
> < pt_pci_read_config: [00:06:0] Error: Failed to read register with invalid 
> access size alignment. [Offset:0eh][Length:4]
> < pt_pci_read_config: [00:06:0] Error: Failed to read register with invalid 
> access size alignment. [Offset:0eh][Length:4]
> < pt_pci_read_config: [00:06:0] Error: Failed to read register with invalid 
> access size alignment. [Offset:0eh][Length:4]
> < pt_pci_read_config: [00:06:0] Error: Failed to read register with invalid 
> access size alignment. [Offset:0eh][Length:4]
> < pt_iomem_map: e_phys=ffffffff maddr=b0000000 type=8 len=268435456 index=0 
> first_map=0
> < pt_iomem_map: e_phys=ffffffff maddr=c1a00000 type=0 len=131072 index=2 
> first_map=0
> < pt_iomem_map: e_phys=e0000000 maddr=b0000000 type=8 len=268435456 index=0 
> first_map=0
> < pt_iomem_map: e_phys=f1020000 maddr=c1a00000 type=0 len=131072 index=2 
> first_map=0
> < pt_ioport_map: e_phys=c600 pio_base=3000 len=256 index=4 first_map=0
> < pt_iomem_map: e_phys=ffffffff maddr=c1b22000 type=0 len=4096 index=0 
> first_map=0
> < pt_iomem_map: e_phys=f1060000 maddr=c1b22000 type=0 len=4096 index=0 
> first_map=0
> < pt_iomem_map: e_phys=ffffffff maddr=b0000000 type=8 len=268435456 index=0 
> first_map=0
> < pt_iomem_map: e_phys=ffffffff maddr=c1a00000 type=0 len=131072 index=2 
> first_map=0
> < pt_iomem_map: e_phys=e0000000 maddr=b0000000 type=8 len=268435456 index=0 
> first_map=0
> < pt_iomem_map: e_phys=f1020000 maddr=c1a00000 type=0 len=131072 index=2 
> first_map=0
> < pt_ioport_map: e_phys=c600 pio_base=3000 len=256 index=4 first_map=0
> < pt_ioport_map: e_phys=c600 pio_base=3000 len=256 index=4 first_map=0
> < pt_msgctrl_reg_write: guest enabling MSI, disable MSI-INTx translation
> < pci_intx: intx=1
> < pt_msi_disable: Unmap msi with pirq 37
> < pt_msgctrl_reg_write: setup msi for dev 30
> < pt_msi_setup: msi mapped with pirq 37
> < pt_msi_update: Update msi with pirq 37 gvec b0 gflags 0
> < pt_iomem_map: e_phys=ffffffff maddr=c1b22000 type=0 len=4096 index=0 
> first_map=0
> < pt_iomem_map: e_phys=f1060000 maddr=c1b22000 type=0 len=4096 index=0 
> first_map=0
> < pt_iomem_map: e_phys=ffffffff maddr=c1b22000 type=0 len=4096 index=0 
> first_map=0
> < shutdown requested in cpu_handle_ioreq
> < Issued domain 3 poweroff
> ---
> > pt_iomem_map: e_phys=f1000000 maddr=c1a00000 type=0 len=131072 index=2 
> > first_map=1
> > pt_iomem_map: e_phys=f1040000 maddr=c1b22000 type=0 len=4096 index=0 
> > first_map=1
> > pt_ioport_map: e_phys=c700 pio_base=3000 len=256 index=4 first_map=1
> > pt_ioport_map: e_phys=c700 pio_base=3000 len=256 index=4 first_map=0
> > ati_gfx_init: guest_pio_bar = 0xc700, host_pio_bar = 0x3000, pio_size=0x100 
> > guest_mmio_bar1=0xe0000000, guest_mmio_bar2=0x0
> > ati_io_regs_read: Requested read of c74c/51020, mapped: 304c/12364
> > ati_hw_in: port I/O: 304c, base: 3000, size: 100
> > ati_hw_in: ioperm successful
> > ati_hw_in: Read: 0
> ---------------------------------------------------------------------------
> 
> }-- End of excerpt from "Dr. Greg Wettstein"
> 
> 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
> ------------------------------------------------------------------------------
> "Boy, it must not take much to make a phone work.  Looking at
>  everthing else here it must be the same way with the INTERNET."
>                                 -- Francis 'Fritz' Wettstein

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