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

> 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.... :-)

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.

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