Xen project Mailing List

Dan,

Replies are inline:

On Sat, Aug 31, 2013 at 4:43 PM, Dan Schmitt <dan.schmitt@xxxxxxxxx> wrote:

Hardware:
16gb Ram
AMD FX-8320
MSI 970A-G43
Primary GPU Radeon HD6570 01:00.0,01:00.1
Secondary GPU Radeon HD7950 02:00.0,02:00.1

Your hardware specs are similar to mine - I have 24Gb of Ram, AMD FX-8350, ASUS Sabertooth 990FX, Radeon 6770 and Radeon 7750.

Dom0 Ubuntu 12.04
Kernel 3.5.0-39
xen 4.3
xl toolset
DomU Win7 64bit

It took some shuffling to hide the HD7950 from
Ubuntu, it's boot process, and X, but pciback seems
to own it now (xl pci-assingable-list shows the 02:00.0
and 02:00.1 when the Win7 DomU isn't running.)

Win7 runs/installs with the emulated video card, and
networking works.
With the drivers installed Win7 seems to see the 7950,
the hardware manager shows it with a yellow warning
triangle/excalmation point. I'm seeing

This device cannot find enough free resources that it can
use (Code 12)

I saw this error whenever I was using the default qemu-xen model. To get this working, try adding the following line to your VM's config:

device_model_version = "qemu-xen-traditional"

If you want to use this device, you will need to disable
one of the other devices on this system.

In the /var/log/xen/xen-hotplug.log I'm seeing lots of

RTNETLINK answers: Operation not supported
RTNETLINK answers: Operation not supported

but I think they are harmless.
In /var/log/xen/qemu-dm-Win7.hvm.log I'm seeing:

xen_ram_alloc: do not alloc 10f800000 bytes of ram at 0 when runstate
is INMIGRATE
xen_ram_alloc: do not alloc 800000 bytes of ram at 10f800000 when
runstate is INMIGRATE
xen_ram_alloc: do not alloc 10000 bytes of ram at 110000000 when
runstate is INMIGRATE
xen_ram_alloc: do not alloc 10000 bytes of ram at 110010000 when
runstate is INMIGRATE

in snippets of dmesg from boot that may be of interest:

Grub command line (I think I have all the magic to hide 02:00.0):

[ 0.000000] Command line: placeholder
root=UUID=14de2da2-d40b-48b8-a0ce-a43f71ddd612 ro apparmor=0 quiet
splash blacklist.nouveau=1 xen-pciback.permissive
xen-pciback.hide=(02:00.0)(02:00.2)
pci=resource_alignment=02:00.0,02.00.2

We can see it on the PCI bus:

[ 3.793517] pci 0000:02:00.0: [1002:679a] type 00 class 0x030000
[ 3.793539] pci 0000:02:00.0: reg 10: [mem 0xc0000000-0xcfffffff 64bit pref]
[ 3.793557] pci 0000:02:00.0: reg 18: [mem 0xfe900000-0xfe93ffff 64bit]
[ 3.793569] pci 0000:02:00.0: reg 20: [io 0xd000-0xd0ff]
[ 3.793592] pci 0000:02:00.0: reg 30: [mem 0xfe940000-0xfe95ffff pref]
[ 3.793598] pci 0000:02:00.0: Disabling memory decoding and
releasing memory resources.
[ 3.793668] pci 0000:02:00.0: supports D1 D2
[ 3.793670] pci 0000:02:00.0: PME# supported from D1 D2 D3hot
[ 3.793718] pci 0000:02:00.1: [1002:aaa0] type 00 class 0x040300
[ 3.793740] pci 0000:02:00.1: reg 10: [mem 0xfe9

I don't know why vgaarb grabs it (or if this is ok):

[ 3.835681] xen-balloon: Initialising balloon driver.
[ 3.835716] xen/balloon: Xen selfballooning driver disabled for domain0.
[ 3.835820] vgaarb: device added:
PCI:0000:01:00.0,decodes=io+mem,owns=io+mem,locks=none
[ 3.835826] vgaarb: device added:
PCI:0000:02:00.0,decodes=io+mem,owns=none,locks=none
[ 3.835830] vgaarb: loaded
[ 3.835831] vgaarb: bridge control possible 0000:02:00.0
[ 3.835832] vgaarb: bridge control possible 0000:01:00.0

[ 3.884755] pci 0000:02:00.0: BAR 0: assigned [mem
0xc0000000-0xcfffffff 64bit pref]
[ 3.884764] pci 0000:02:00.0: BAR 2: assigned [mem
0xfe900000-0xfe93ffff 64bit]
[ 3.884772] pci 0000:02:00.0: BAR 6: assigned [mem
0xfe940000-0xfe95ffff pref]

The kernel grabs the 6570:
The kernel grabs the 6570:

[ 4.680418] [drm] initializing kernel modesetting (TURKS
0x1002:0x6759 0x1462:0x2502).
[ 4.680483] [drm] register mmio base: 0xFEA20000
[ 4.680485] [drm] register mmio size: 131072
[ 4.680692] ATOM BIOS: 113
[ 4.680727] radeon 0000:01:00.0: VRAM: 1024M 0x0000000000000000 -
0x000000003FFFFFFF (1024M used)
[ 4.680730] radeon 0000:01:00.0: GTT: 512M 0x0000000040000000 -
0x000000005FFFFFFF
[ 4.680732] [drm] Detected VRAM RAM=1024M, BAR=256M
[ 4.680734] [drm] RAM width 128bits DDR
[ 4.681001] [TTM] Zone kernel: Available graphics memory: 7982182 kiB
[ 4.681007] [TTM] Zone dma32: Available graphics memory: 2097152 kiB
[ 4.681009] [TTM] Initializing pool allocator
[ 4.681018] [TTM] Initializing DMA pool allocator
[ 4.681044] [drm] radeon: 1024M of VRAM memory ready
[ 4.681046] [drm] radeon: 512M of GTT memory ready.
[ 4.681077] [drm] GART: num cpu pages 131072, num gpu pages 131072
[ 4.681670] [drm] Loading TURKS Microcode

I don't know why it goes after the 7950 here (or how to stop it):

[ 5.034399] Console: switching to colour frame buffer device 240x67
[ 5.051586] fb0: radeondrmfb frame buffer device
[ 5.051587] drm: registered panic notifier
[ 5.051592] [drm] Initialized radeon 2.18.0 20080528 for
0000:01:00.0 on minor 0
[ 5.051622] radeon 0000:02:00.0: enabling device (0000 -> 0003)
[ 5.300587] sd 2:0:0:0: [sdb] Write cache: enabled, read cache:
enabled, doesn't support DPO or FUA
[ 5.317630] radeon 0000:02:00.0: VRAM: 3072M 0x0000000000000000 -
0x00000000BFFFFFFF (3072M used)
[ 5.317633] radeon 0000:02:00.0: GTT: 512M 0x00000000C0000000 -
0x00000000DFFFFFFF
[ 5.317635] [drm] Detected VRAM RAM=3072M, BAR=256M
[ 5.317637] [drm] RAM width 384bits DDR
[ 5.317645] [drm] radeon: 3072M of VRAM memory ready
[ 5.317647] [drm] radeon: 512M of GTT memory ready.
[ 5.317661] [drm] GART: num cpu pages 131072, num gpu pages 131072
[ 5.318173] [drm] Loading TAHITI Microcode
[ 5.696909] radeon 0000:02:00.0: WB enabled
[ 5.696912] radeon 0000:02:00.0: fence driver on ring 0 use gpu
addr 0x00000000c0000c00 and cpu addr 0xffff880407f99c00
[ 5.696915] radeon 0000:02:00.0: fence driver on ring 1 use gpu
addr 0x00000000c0000c04 and cpu addr 0xffff880407f99c04
[ 5.696917] radeon 0000:02:00.0: fence driver on ring 2 use gpu
addr 0x00000000c0000c08 and cpu addr 0xffff880407f99c08
[ 5.696919] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[ 5.696920] [drm] Driver supports precise vblank timestamp query.
[ 5.697011] radeon 0000:02:00.0: radeon: using MSI.
[ 5.697081] [drm] radeon: irq initialized.
[ 5.716856] [drm] ring test on 0 succeeded in 1 usecs
[ 5.716861] [drm] ring test on 1 succeeded in 1 usecs
[ 5.716866] [drm] ring test on 2 succeeded in 1 usecs
[ 5.717408] [drm] ib test on ring 0 succeeded in 0 usecs
[ 5.717443] [drm] ib test on ring 1 succeeded in 0 usecs
[ 5.717472] [drm] ib test on ring 2 succeeded in 0 usecs
[ 5.770027] [drm] Radeon Display Connectors

[ 5.837219] fb1: radeondrmfb frame buffer device
[ 5.837224] [drm] Initialized radeon 2.18.0 20080528 for
0000:02:00.0 on minor 1

It seems like the drm stuff lets go of it and picback gets
it:

[ 12.475932] [drm] radeon: finishing device.
[ 12.481586] radeon 0000:02:00.0: ffff880409aa7800 unpin not necessary
[ 12.481858] [drm] radeon: ttm finalized
[ 12.482371] pciback 0000:02:00.0: seizing device
[ 12.584854] pciback 0000:02:00.1: seizing device

I don't know if this is good:

[ 12.603755] vgaarb: device changed decodes:
PCI:0000:01:00.0,olddecodes=io+mem,decodes=none:owns=io+mem
[ 12.603758] vgaarb: transferring owner from PCI:0000:01:00.0 to
PCI:0000:02:00.0

This seems like what I want to happen when the Win7 hvm starts up:

[ 40.821498] xen-pciback: vpci: 0000:02:00.0: assign to virtual slot 0
[ 40.822125] xen-pciback: vpci: 0000:02:00.1: assign to virtual slot 0 func 1

My xorg is set up to only look at the 6750
with BusId "PCI:1:0:0"

So, qeustions.

Do I have hardware that will work for hvm
Win7 (HD6570 for Dom0, and HD7950 for DomU,
970 bridge chip Mobo and VT-d enabled?)

Specs are similar to mine, so unless there was a buggy bios implementation, I don't see any obvious issue

Do I have the right software to "work out
of the box"? (4.3 xen release and 12.04
ubuntu)

I'm personally using 4.3 under ArchLinux, but again don't see any reason why this shouldn't work, especially if you switch to using the device_model_version of "qemu-xen-traditional"

Am I doint something silly or are there more things
I should look for?

My next explorations will be trying to pass the 7950 to
an ubuntu HVM to see what happens, and see if booting
in text mode (and keeping the kernel/frame buffer out
of it) does anything.

Thanks for your time.

Dan S

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

Regards,

David

Re: [Xen-users] HVM VGA Passthrough to Win7 64 with Xen 4.3