VGA passthough still not working

VGA passthough still not working

[Sandi Romih]

[-- Attachment #1.1: Type: text/plain, Size: 6412 bytes --]

Hello,

I have spent a lot of time trying to get gfx passthru working on my system
without success.

I looked onto my hardware capabilities again to make sure that it does
support VT-d and I am not too sure that it does fully.

My hardware is as follows:
- Supermicro X8DTH-6F motherboard (5520 chipset which supports VT-d)
- single Xeon X5650 CPU (which is listed as supporting VT-x, no mention of
VT-d at ark.intel.com)

Now, according to the VTdHowTo <http://wiki.xen.org/wiki/VTdHowTo>, the
motherboard BIOS, chipset AND CPU need to support VT-d.
What confuses me is, why is the 55x0 chipset listed there if none of the
CPU's supported, that I know of, dont have the VT-d feature option, only
VT-x.

Browsing around a bit, I read that the VT-d is a memory related feature
which was included in the chipsets because memory was interfaced via the
chipset, but now-a-days when the memory controller is in the CPU, VT-d
should be in the CPU. Why does the 5520 chipset support VT-d and the X5650
not?

Could anyone who has experience with a similar platform to mine (5520
chipset and Xeon CPU) please share their experiences with PCI passthu and
gfx passthru.

My setup quickly:
- onboard VGA (primary) used by dom0 (Debian with the 3.1.9 kernel)
- EVGA GTX 480 (secondary) passed thru to domU (Windows)

The only errors that I see are:

cat /var/log/xen/qemu-dm-winxp.log |grep -i er
xs_read(/local/domain/0/device-model/2/xen_extended_power_mgmt): read error
xs_read(): vncpasswd get error.
/vm/d04a58cf-037a-4219-80a1-73abe49b81ab/vncpasswd.
vcpu-set: watch node error.
xs_read(/local/domain/2/log-throttling): read error
pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: No
such file or directory: 0x3:0x0.0x0
pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: No
such file or directory: 0x3:0x0.0x1

I cant find much info about this error...

cat /var/log/xen/xl-winxp.log
Waiting for domain winxp (domid 1) to die [pid 3038]
Domain 1 is dead
Action for shutdown reason code 3 is restart
Domain 1 needs to be cleaned up: destroying the domain
libxl: error: libxl_pci.c:776:libxl__device_pci_reset: The kernel doesn't
support reset from sysfs for PCI device 0000:03:00.0
libxl: error: libxl_pci.c:776:libxl__device_pci_reset: The kernel doesn't
support reset from sysfs for PCI device 0000:03:00.1
Done. Rebooting now
xc: info: VIRTUAL MEMORY ARRANGEMENT:
  Loader:        0000000000100000->0000000000182bb4
  TOTAL:         0000000000000000->000000003f800000
  ENTRY ADDRESS: 0000000000100000
xc: info: PHYSICAL MEMORY ALLOCATION:
  4KB PAGES: 0x0000000000000200
  2MB PAGES: 0x00000000000001fb
  1GB PAGES: 0x0000000000000000
libxl: error: libxl_pci.c:776:libxl__device_pci_reset: The kernel doesn't
support reset from sysfs for PCI device 0000:03:00.0
libxl: error: libxl_pci.c:776:libxl__device_pci_reset: The kernel doesn't
support reset from sysfs for PCI device 0000:03:00.1
Waiting for domain winxp (domid 2) to die [pid 3038]

dmesg |grep 03:00
[    0.000000] Command line: placeholder
root=UUID=d5f5207b-d2aa-4f19-b51d-bc2c727b9e8f ro nomodeset
xen-pciback.passthrough=1 xen-pciback.permissive
xen-pciback.hide=(03:00.0)(03:00.1) quiet
[    5.948984] Kernel command line: placeholder
root=UUID=d5f5207b-d2aa-4f19-b51d-bc2c727b9e8f ro nomodeset
xen-pciback.passthrough=1 xen-pciback.permissive
xen-pciback.hide=(03:00.0)(03:00.1) quiet
[    6.152642] pci 0000:03:00.0: [10de:06c0] type 0 class 0x000300
[    6.152663] pci 0000:03:00.0: reg 10: [mem 0xf8000000-0xf9ffffff]
[    6.152685] pci 0000:03:00.0: reg 14: [mem 0xd8000000-0xdfffffff 64bit
pref]
[    6.152707] pci 0000:03:00.0: reg 1c: [mem 0xd4000000-0xd7ffffff 64bit
pref]
[    6.152723] pci 0000:03:00.0: reg 24: [io  0xdc00-0xdc7f]
[    6.152738] pci 0000:03:00.0: reg 30: [mem 0xfae80000-0xfaefffff pref]
[    6.152831] pci 0000:03:00.1: [10de:0be5] type 0 class 0x000403
[    6.152851] pci 0000:03:00.1: reg 10: [mem 0xfae7c000-0xfae7ffff]
[    6.222176] vgaarb: device added:
PCI:0000:03:00.0,decodes=io+mem,owns=none,locks=none
[    6.222205] vgaarb: bridge control possible 0000:03:00.0
[    6.276478] pciback 0000:03:00.0: seizing device
[    6.276483] pciback 0000:03:00.1: seizing device
[    6.549901] pciback 0000:03:00.0: Signaling PME through PCIe PME
interrupt
[    6.549903] pciback 0000:03:00.1: Signaling PME through PCIe PME
interrupt
[    6.550408] pciback 0000:03:00.1: PCI INT B -> GSI 25 (level, low) ->
IRQ 25
[    6.550417] pciback 0000:03:00.1: PCI INT B disabled
[    6.550454] pciback 0000:03:00.0: enabling device (0146 -> 0147)
[    6.550470] pciback 0000:03:00.0: PCI INT A -> GSI 26 (level, low) ->
IRQ 26
[    6.550477] pciback 0000:03:00.0: PCI INT A disabled
[12048.241890] pciback 0000:03:00.0: device has been assigned to another
domain! Over-writting the ownership, but beware.
[12048.243009] pciback 0000:03:00.1: device has been assigned to another
domain! Over-writting the ownership, but beware.

PCI device 03:00.x is the GTX 480.

xl list
Name                                        ID   Mem VCPUs State Time(s)
Domain-0                                     0  1024    12     r-----
 1507.2
winxp                                        2  1015     1     r-----
212.2


When I create the winxp domain, my primary graphics goes blank...
(This confuses me the most).


And lastly, my xen cfg file...

cat /xen-vms/xenwinxp.cfg
kernel = "/usr/lib/xen/boot/hvmloader"
builder='hvm'
memory =1024
# shadow_memory = 1024
name = "winxp"
vcpus='1'
# vif = [ 'bridge=eth0,mac=00:14:3e:00:8f:c2' ]
# disk =
['file:/xen-vms/winxp/xenwinxp.img,hda,w','file:/xen-vms/isos/winxp.iso,hdc:cdrom,r']
disk = ['file:/xen-vms/winxp/xenwinxp.img,hda,w','phy:/dev/sr0,hdc:cdrom,r']
boot="cd"
sdl=0
# vnc=1
# vnclisten="0.0.0.0"
# vncconsole=1
# vncpasswd=''
acpi=1
apic=1
xen_extended_power_mgmt=1
pae=1
arch='x86_64'
hpet = 1
hap = 1
viridian = 1
monitor=1
serial='pty'
# keymap='fr'
# soundhw = "all"
# audio="on"
ne2000=0
on_poweroff = 'destroy'
on_reboot   = 'restart'
on_crash    = 'restart'
xen_platform_pci=1
gfx_passthru=1
pci  = [ '03:00.0','03:00.1' ]
pci_msitranslate=0
pci_power_mgmt=0
acpi_s3 = 1
acpi_s4 = 1


If anyone has any ideas, or things I should check or try, please let me
know. Also, if there is a way for me to get more debug info from xen that
might help me figure out what I am doing wrong in my configuration, I
would appreciate that info too.

Sandi

[-- Attachment #1.2: Type: text/html, Size: 8660 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: VGA passthough still not working

[Pasi Kärkkäinen]

On Fri, Jan 20, 2012 at 02:05:43PM +0100, Sandi Romih wrote:
>    Hello,
>    I have spent a lot of time trying to get gfx passthru working on my system
>    without success.
>    I looked onto my hardware capabilities again to make sure that it does
>    support VT-d and I am not too sure that it does fully.
>    My hardware is as follows:
>    - Supermicro X8DTH-6F motherboard (5520 chipset which supports VT-d)
>    - single Xeon X5650 CPU (which is listed as supporting VT-x, no mention of
>    VT-d at [1]ark.intel.com)
>    Now, according to the [2]VTdHowTo, the motherboard BIOS, chipset AND CPU
>    need to support VT-d.
>    What confuses me is, why is the 55x0 chipset listed there if none of the
>    CPU's supported, that I know of, dont have the VT-d feature option, only
>    VT-x.
>

I've been using VT-d with Xen with Intel 5500 series chipset, and Xeon 5600 series CPU.
VT-d needs to be enabled in the BIOS.

-- Pasi

Re: VGA passthough still not working

[Sandi Romih]

[-- Attachment #1.1: Type: text/plain, Size: 1254 bytes --]

Pasi,

I have that enabled in my BIOS, VT-d for the chipset and VT-x for the CPU.

Have you managed to pass your gpu through to the domU?

Regards

Sandi
On Jan 20, 2012 4:47 PM, "Pasi Kärkkäinen" <pasik@iki.fi> wrote:

> On Fri, Jan 20, 2012 at 02:05:43PM +0100, Sandi Romih wrote:
> >    Hello,
> >    I have spent a lot of time trying to get gfx passthru working on my
> system
> >    without success.
> >    I looked onto my hardware capabilities again to make sure that it does
> >    support VT-d and I am not too sure that it does fully.
> >    My hardware is as follows:
> >    - Supermicro X8DTH-6F motherboard (5520 chipset which supports VT-d)
> >    - single Xeon X5650 CPU (which is listed as supporting VT-x, no
> mention of
> >    VT-d at [1]ark.intel.com)
> >    Now, according to the [2]VTdHowTo, the motherboard BIOS, chipset AND
> CPU
> >    need to support VT-d.
> >    What confuses me is, why is the 55x0 chipset listed there if none of
> the
> >    CPU's supported, that I know of, dont have the VT-d feature option,
> only
> >    VT-x.
> >
>
> I've been using VT-d with Xen with Intel 5500 series chipset, and Xeon
> 5600 series CPU.
> VT-d needs to be enabled in the BIOS.
>
> -- Pasi
>
>

[-- Attachment #1.2: Type: text/html, Size: 1630 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: [Xen-devel] VGA passthough still not working

[Likarpenkov Alexander]

Please make a manual
or let's together make

В пятницу, двадцатого января 2012 года, в 18:49:20 Вы писали:

 SR> Pasi,

 SR> I have that enabled in my BIOS, VT-d for the chipset and VT-x for the
 SR> CPU.

 SR> Have you managed to pass your gpu through to the domU?

 SR> Regards

 SR> Sandi
 SR> On Jan 20, 2012 4:47 PM, "Pasi Kärkkäinen" <pasik@iki.fi> wrote:

 ??>> On Fri, Jan 20, 2012 at 02:05:43PM +0100, Sandi Romih wrote:
 ??>>>    Hello,
 ??>>>    I have spent a lot of time trying to get gfx passthru working on
 ??>>> my
 ??>> system
 ??>>>    without success.
 ??>>>    I looked onto my hardware capabilities again to make sure that it
 ??>>> does   support VT-d and I am not too sure that it does fully.   My
 ??>>> hardware is as follows:   - Supermicro X8DTH-6F motherboard (5520 
chipset
 ??>>> which supports VT-d)   - single Xeon X5650 CPU (which is listed as
 ??>>> supporting VT-x, no
 ??>> mention of
 ??>>>    VT-d at [1]ark.intel.com)
 ??>>>    Now, according to the [2]VTdHowTo, the motherboard BIOS, chipset
 ??>>> AND
 ??>> CPU
 ??>>>    need to support VT-d.
 ??>>>    What confuses me is, why is the 55x0 chipset listed there if none
 ??>>> of
 ??>> the
 ??>>>    CPU's supported, that I know of, dont have the VT-d feature
 ??>>> option,
 ??>> only
 ??>>>    VT-x.
 ??>>>
 


_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Re: [Xen-users] VGA passthough still not working

[chris]

[-- Attachment #1.1: Type: text/plain, Size: 2080 bytes --]

I'm really surprised this doesnt get more attention. For as long as I've
been on this list, this feature has been mentioned so many times I would
think that getting this working would be a huge feature that would make the
product even better. I have only seen the occasional success with
experimental patches etc, despite this being talked about for years.

On Fri, Jan 20, 2012 at 1:53 PM, Likarpenkov Alexander
<al@ohosting.org.ua>wrote:

> Please make a manual
> or let's together make
>
> В пятницу, двадцатого января 2012 года, в 18:49:20 Вы писали:
>
> SR> Pasi,
>
> SR> I have that enabled in my BIOS, VT-d for the chipset and VT-x for the
> SR> CPU.
>
> SR> Have you managed to pass your gpu through to the domU?
>
> SR> Regards
>
> SR> Sandi
> SR> On Jan 20, 2012 4:47 PM, "Pasi Kärkkäinen" <pasik@iki.fi> wrote:
>
> ??>> On Fri, Jan 20, 2012 at 02:05:43PM +0100, Sandi Romih wrote:
> ??>>>    Hello,
> ??>>>    I have spent a lot of time trying to get gfx passthru working on
> ??>>> my
> ??>> system
> ??>>>    without success.
> ??>>>    I looked onto my hardware capabilities again to make sure that it
> ??>>> does   support VT-d and I am not too sure that it does fully.   My
> ??>>> hardware is as follows:   - Supermicro X8DTH-6F motherboard (5520
> chipset
> ??>>> which supports VT-d)   - single Xeon X5650 CPU (which is listed as
> ??>>> supporting VT-x, no
> ??>> mention of
> ??>>>    VT-d at [1]ark.intel.com)
> ??>>>    Now, according to the [2]VTdHowTo, the motherboard BIOS, chipset
> ??>>> AND
> ??>> CPU
> ??>>>    need to support VT-d.
> ??>>>    What confuses me is, why is the 55x0 chipset listed there if none
> ??>>> of
> ??>> the
> ??>>>    CPU's supported, that I know of, dont have the VT-d feature
> ??>>> option,
> ??>> only
> ??>>>    VT-x.
> ??>>>
>
>
>
> ______________________________**_________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/**xen-users<http://lists.xensource.com/xen-users>

[-- Attachment #1.2: Type: text/html, Size: 2895 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: [Xen-devel] VGA passthough still not working

[John Sherwood]

[-- Attachment #1.1: Type: text/plain, Size: 4151 bytes --]

Most people run Xen for headless virtual machines, and VGA passthrough
requires VT-d support in both the CPU and motherboard.  VGA passthrough is
also somewhat dependent on the card you're using it with, so it's a hard
thing to test.  If you want it to get more love, then you're the best
situated person to do it :)

However, on the topic of Sandi's issue:
If your monitor goes black, that's a GOOD sign - it's indicative that the
dom0 is relinquishing control of the graphics card, so at least that's
working.  In my experience using graphics passthrough, this problem is
related to your card not being fully supported; essentially, Xen can't pass
your card through to the VM during boot.  If you leave the `gfx_passthru`
option *disabled*, you'll have the emulated cirrus card (by default) and it
will at least boot successfully.  Here's some step by step
suggestions/instructions:


   - disable gfx_passthru in config (delete the option or set it to 0)
   - enable VNC, listening on all interfaces
   - start the VM - your screen should still go black
   - From another machine (what with your screen being black), connect in
   via VNC and fire up the device manager in XP.  I don't have any XP boxes
   left, but in Windows 7, you should see a device in an error state under
   'Display adapters'.
   - Check its PCI slot under 'details' - "Location Paths" should help.
   Compare that to `xm pci-list [domain name]` to see if it matches up with
   the graphics card.
   - Install the driver for that device
   - Reboot.  You won't see the BIOS on the monitor, but it should use it
   once Windows takes over.

If something in there doesn't work, hopefully I can help you debug - I went
through a lot of this a while back.

On Fri, Jan 20, 2012 at 2:24 PM, chris <tknchris@gmail.com> wrote:

> I'm really surprised this doesnt get more attention. For as long as I've
> been on this list, this feature has been mentioned so many times I would
> think that getting this working would be a huge feature that would make the
> product even better. I have only seen the occasional success with
> experimental patches etc, despite this being talked about for years.
>
>
> On Fri, Jan 20, 2012 at 1:53 PM, Likarpenkov Alexander <al@ohosting.org.ua
> > wrote:
>
>> Please make a manual
>> or let's together make
>>
>> В пятницу, двадцатого января 2012 года, в 18:49:20 Вы писали:
>>
>> SR> Pasi,
>>
>> SR> I have that enabled in my BIOS, VT-d for the chipset and VT-x for the
>> SR> CPU.
>>
>> SR> Have you managed to pass your gpu through to the domU?
>>
>> SR> Regards
>>
>> SR> Sandi
>> SR> On Jan 20, 2012 4:47 PM, "Pasi Kärkkäinen" <pasik@iki.fi> wrote:
>>
>> ??>> On Fri, Jan 20, 2012 at 02:05:43PM +0100, Sandi Romih wrote:
>> ??>>>    Hello,
>> ??>>>    I have spent a lot of time trying to get gfx passthru working on
>> ??>>> my
>> ??>> system
>> ??>>>    without success.
>> ??>>>    I looked onto my hardware capabilities again to make sure that it
>> ??>>> does   support VT-d and I am not too sure that it does fully.   My
>> ??>>> hardware is as follows:   - Supermicro X8DTH-6F motherboard (5520
>> chipset
>> ??>>> which supports VT-d)   - single Xeon X5650 CPU (which is listed as
>> ??>>> supporting VT-x, no
>> ??>> mention of
>> ??>>>    VT-d at [1]ark.intel.com)
>> ??>>>    Now, according to the [2]VTdHowTo, the motherboard BIOS, chipset
>> ??>>> AND
>> ??>> CPU
>> ??>>>    need to support VT-d.
>> ??>>>    What confuses me is, why is the 55x0 chipset listed there if none
>> ??>>> of
>> ??>> the
>> ??>>>    CPU's supported, that I know of, dont have the VT-d feature
>> ??>>> option,
>> ??>> only
>> ??>>>    VT-x.
>> ??>>>
>>
>>
>>
>> ______________________________**_________________
>> Xen-users mailing list
>> Xen-users@lists.xensource.com
>> http://lists.xensource.com/**xen-users<http://lists.xensource.com/xen-users>
>
>
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users
>
>

[-- Attachment #1.2: Type: text/html, Size: 5410 bytes --]

[-- Attachment #2: Type: text/plain, Size: 137 bytes --]

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Re: [Xen-devel] VGA passthough still not working

[Likarpenkov Alexander]

I will start it only pci video card (not PCIe) and hangs. Although I do 
periodically attempts throughout the year. I also have 2 more cards in the 
same system (ati hd 2600), but can not run any vga pass under fedora, under 
any debain or ubuntu.

I have a motherboard ASUS M4A89TD, which can IOMMU

 c> I'm really surprised this doesnt get more attention. For as long as I've
 c> been on this list, this feature has been mentioned so many times I would
 c> think that getting this working would be a huge feature that would make
 c> the product even better. I have only seen the occasional success with
 c> experimental patches etc, despite this being talked about for years.

Re: [Xen-devel] VGA passthough still not working

[Likarpenkov Alexander]

[-- Attachment #1: Type: text/plain, Size: 4423 bytes --]

This whole garbage works for me. I have 9 months of sitting in windows mode 
pci passthru (see attach). Also on the past 15 virtual machines that are 
involved in hosting this system, two PCIe graphics card, 2 mice and 2 
keyboards, which are divided between two different autonomous operating mode 
HVM. I'd like to see the login screen from the start, but you can not run on 
gfx_passthru different operating systems and versions of xen

 JS> Most people run Xen for headless virtual machines, and VGA passthrough
 JS> requires VT-d support in both the CPU and motherboard.  VGA passthrough
 JS> is also somewhat dependent on the card you're using it with, so it's a
 JS> hard thing to test.  If you want it to get more love, then you're the
 JS> best situated person to do it :)

 JS> However, on the topic of Sandi's issue:
 JS> If your monitor goes black, that's a GOOD sign - it's indicative that
 JS> the dom0 is relinquishing control of the graphics card, so at least
 JS> that's working.  In my experience using graphics passthrough, this
 JS> problem is related to your card not being fully supported; essentially,
 JS> Xen can't pass your card through to the VM during boot.  If you leave
 JS> the `gfx_passthru` option *disabled*, you'll have the emulated cirrus
 JS> card (by default) and it will at least boot successfully.  Here's some
 JS> step by step suggestions/instructions:

 JS>    - disable gfx_passthru in config (delete the option or set it to 0)
 JS>    - enable VNC, listening on all interfaces
 JS>    - start the VM - your screen should still go black
 JS>    - From another machine (what with your screen being black), connect
 JS> in
 JS>    via VNC and fire up the device manager in XP.  I don't have any XP
 JS> boxes
 JS>    left, but in Windows 7, you should see a device in an error state
 JS> under
 JS>    'Display adapters'.
 JS>    - Check its PCI slot under 'details' - "Location Paths" should help.
 JS>    Compare that to `xm pci-list [domain name]` to see if it matches up
 JS> with
 JS>    the graphics card.
 JS>    - Install the driver for that device
 JS>    - Reboot.  You won't see the BIOS on the monitor, but it should use
 JS> it
 JS>    once Windows takes over.

 JS> If something in there doesn't work, hopefully I can help you debug - I
 JS> went through a lot of this a while back.

 JS> On Fri, Jan 20, 2012 at 2:24 PM, chris <tknchris@gmail.com> wrote:

 ??>> I'm really surprised this doesnt get more attention. For as long as
 ??>> I've been on this list, this feature has been mentioned so many times
 ??>> I would think that getting this working would be a huge feature that
 ??>> would make the product even better. I have only seen the occasional
 ??>> success with experimental patches etc, despite this being talked about
 ??>> for years.
 ??>>
 ??>> On Fri, Jan 20, 2012 at 1:53 PM, Likarpenkov Alexander
 ??>> <al@ohosting.org.ua
 ??>>> wrote:
 ??>>
 ??>>> Please make a manual
 ??>>> or let's together make
 ??>>>
 ??>>> В пятницу, двадцатого января 2012 года, в 18:49:20 Вы писали:
 ??>>>
 SR>>>> Pasi,
 ??>>>
 SR>>>> I have that enabled in my BIOS, VT-d for the chipset and VT-x for
 SR>>>> the CPU.
 ??>>>
 SR>>>> Have you managed to pass your gpu through to the domU?
 ??>>>
 SR>>>> Regards
 ??>>>
 SR>>>> Sandi
 SR>>>> On Jan 20, 2012 4:47 PM, "Pasi Kärkkäinen" <pasik@iki.fi> wrote:
 ??>>>
 ??>>>>> On Fri, Jan 20, 2012 at 02:05:43PM +0100, Sandi Romih wrote:
 ??>>>>>>    Hello,
 ??>>>>>>    I have spent a lot of time trying to get gfx passthru working
 ??>>>>>> on my
 ??>>>>> system
 ??>>>>>>    without success.
 ??>>>>>>    I looked onto my hardware capabilities again to make sure that
 ??>>>>>> it does   support VT-d and I am not too sure that it does fully.
 ??>>>>>> My hardware is as follows:   - Supermicro X8DTH-6F motherboard 
(5520
 ??>>> chipset
 ??>>>>>> which supports VT-d)   - single Xeon X5650 CPU (which is listed as
 ??>>>>>> supporting VT-x, no
 ??>>>>> mention of
 ??>>>>>>    VT-d at [1]ark.intel.com)
 ??>>>>>>    Now, according to the [2]VTdHowTo, the motherboard BIOS,
 ??>>>>>> chipset AND
 ??>>>>> CPU
 ??>>>>>>    need to support VT-d.
 ??>>>>>>    What confuses me is, why is the 55x0 chipset listed there if
 ??>>>>>> none of
 ??>>>>> the
 ??>>>>>>    CPU's supported, that I know of, dont have the VT-d feature
 ??>>>>>> option,
 ??>>>>> only
 ??>>>>>>    VT-x.
 ??>>>>>>

[-- Attachment #2: 01.jpg --]
[-- Type: image/jpeg, Size: 181205 bytes --]

[-- Attachment #3: Type: text/plain, Size: 137 bytes --]

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Re: VGA passthough still not working

[Pasi Kärkkäinen]

On Fri, Jan 20, 2012 at 05:49:20PM +0100, Sandi Romih wrote:
>    Pasi,
> 
>    I have that enabled in my BIOS, VT-d for the chipset and VT-x for the CPU.
>

Ok. And Xen enables IOMMU? Did you verify from Xen's dmesg ? 

http://wiki.xen.org/xenwiki/XenCommonProblems.html#head-2f76ed2d3c282003418d37fbbcda510cac266f89


 
>    Have you managed to pass your gpu through to the domU?
> 

No, I haven't tried that yet. I've been planning to, but I haven't had time for it yet.

There are many people who are using Xen VGA passthru with Intel, AMD/ATI and Nvidia graphics cards.
Currently it needs a lot of understanding and some custom patching, but you can make it work.

There are even businesses using Xen VGA passthru in production :)

-- Pasi

> 
>    Sandi
> 
>    On Jan 20, 2012 4:47 PM, "Pasi Kärkkäinen" <[1]pasik@iki.fi> wrote:
> 
>      On Fri, Jan 20, 2012 at 02:05:43PM +0100, Sandi Romih wrote:
>      >    Hello,
>      >    I have spent a lot of time trying to get gfx passthru working on my
>      system
>      >    without success.
>      >    I looked onto my hardware capabilities again to make sure that it
>      does
>      >    support VT-d and I am not too sure that it does fully.
>      >    My hardware is as follows:
>      >    - Supermicro X8DTH-6F motherboard (5520 chipset which supports
>      VT-d)
>      >    - single Xeon X5650 CPU (which is listed as supporting VT-x, no
>      mention of
>      >    VT-d at [1][2]ark.intel.com)
>      >    Now, according to the [2]VTdHowTo, the motherboard BIOS, chipset
>      AND CPU
>      >    need to support VT-d.
>      >    What confuses me is, why is the 55x0 chipset listed there if none
>      of the
>      >    CPU's supported, that I know of, dont have the VT-d feature option,
>      only
>      >    VT-x.
>      >
> 
>      I've been using VT-d with Xen with Intel 5500 series chipset, and Xeon
>      5600 series CPU.
>      VT-d needs to be enabled in the BIOS.
> 
>      -- Pasi
> 
> References
> 
>    Visible links
>    1. mailto:pasik@iki.fi
>    2. http://ark.intel.com/

Re: [Xen-users] VGA passthough still not working

[Sandi Romih]

[-- Attachment #1.1: Type: text/plain, Size: 2103 bytes --]

Alexander,

I agree, a manual would be great.

It would make newcomers, like myself, a little bit more comfortable with
Xen.

I think that the first step would be that everyone who has had success with
VGA passthru should add their hardware setup and xen/kernel versions to
the  http://wiki.xen.org/wiki/Xen_VGA_Passthrough_Tested_Adapters wiki
page, or perhaps we start a new page in the wiki with information on how to
use particular graphics cards (i.e. how to patch xen to get them working),
and this page can list success stories.


Regards

Sandi




On Fri, Jan 20, 2012 at 7:53 PM, Likarpenkov Alexander
<al@ohosting.org.ua>wrote:

> Please make a manual
> or let's together make
>
> В пятницу, двадцатого января 2012 года, в 18:49:20 Вы писали:
>
> SR> Pasi,
>
> SR> I have that enabled in my BIOS, VT-d for the chipset and VT-x for the
> SR> CPU.
>
> SR> Have you managed to pass your gpu through to the domU?
>
> SR> Regards
>
> SR> Sandi
> SR> On Jan 20, 2012 4:47 PM, "Pasi Kärkkäinen" <pasik@iki.fi> wrote:
>
> ??>> On Fri, Jan 20, 2012 at 02:05:43PM +0100, Sandi Romih wrote:
> ??>>>    Hello,
> ??>>>    I have spent a lot of time trying to get gfx passthru working on
> ??>>> my
> ??>> system
> ??>>>    without success.
> ??>>>    I looked onto my hardware capabilities again to make sure that it
> ??>>> does   support VT-d and I am not too sure that it does fully.   My
> ??>>> hardware is as follows:   - Supermicro X8DTH-6F motherboard (5520
> chipset
> ??>>> which supports VT-d)   - single Xeon X5650 CPU (which is listed as
> ??>>> supporting VT-x, no
> ??>> mention of
> ??>>>    VT-d at [1]ark.intel.com)
> ??>>>    Now, according to the [2]VTdHowTo, the motherboard BIOS, chipset
> ??>>> AND
> ??>> CPU
> ??>>>    need to support VT-d.
> ??>>>    What confuses me is, why is the 55x0 chipset listed there if none
> ??>>> of
> ??>> the
> ??>>>    CPU's supported, that I know of, dont have the VT-d feature
> ??>>> option,
> ??>> only
> ??>>>    VT-x.
> ??>>>
>
>
>

[-- Attachment #1.2: Type: text/html, Size: 3032 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: [Xen-users] VGA passthough still not working

[Sandi Romih]

[-- Attachment #1.1: Type: text/plain, Size: 2589 bytes --]

Chris,

Yeah, I guess xen has generally been focused on the server end.

But I see some good uses for desktop virtualization too. I personally want
this so that I can have a file server (zfs based) and a Windows desktop (as
all the tools I use in my job are mostly only supported in MS OS) in one
machine. Saves me money and space.

Regards

Sandi

On Fri, Jan 20, 2012 at 8:24 PM, chris <tknchris@gmail.com> wrote:

> I'm really surprised this doesnt get more attention. For as long as I've
> been on this list, this feature has been mentioned so many times I would
> think that getting this working would be a huge feature that would make the
> product even better. I have only seen the occasional success with
> experimental patches etc, despite this being talked about for years.
>
> On Fri, Jan 20, 2012 at 1:53 PM, Likarpenkov Alexander <al@ohosting.org.ua
> > wrote:
>
>> Please make a manual
>> or let's together make
>>
>> В пятницу, двадцатого января 2012 года, в 18:49:20 Вы писали:
>>
>> SR> Pasi,
>>
>> SR> I have that enabled in my BIOS, VT-d for the chipset and VT-x for the
>> SR> CPU.
>>
>> SR> Have you managed to pass your gpu through to the domU?
>>
>> SR> Regards
>>
>> SR> Sandi
>> SR> On Jan 20, 2012 4:47 PM, "Pasi Kärkkäinen" <pasik@iki.fi> wrote:
>>
>> ??>> On Fri, Jan 20, 2012 at 02:05:43PM +0100, Sandi Romih wrote:
>> ??>>>    Hello,
>> ??>>>    I have spent a lot of time trying to get gfx passthru working on
>> ??>>> my
>> ??>> system
>> ??>>>    without success.
>> ??>>>    I looked onto my hardware capabilities again to make sure that it
>> ??>>> does   support VT-d and I am not too sure that it does fully.   My
>> ??>>> hardware is as follows:   - Supermicro X8DTH-6F motherboard (5520
>> chipset
>> ??>>> which supports VT-d)   - single Xeon X5650 CPU (which is listed as
>> ??>>> supporting VT-x, no
>> ??>> mention of
>> ??>>>    VT-d at [1]ark.intel.com)
>> ??>>>    Now, according to the [2]VTdHowTo, the motherboard BIOS, chipset
>> ??>>> AND
>> ??>> CPU
>> ??>>>    need to support VT-d.
>> ??>>>    What confuses me is, why is the 55x0 chipset listed there if none
>> ??>>> of
>> ??>> the
>> ??>>>    CPU's supported, that I know of, dont have the VT-d feature
>> ??>>> option,
>> ??>> only
>> ??>>>    VT-x.
>> ??>>>
>>
>>
>>
>> ______________________________**_________________
>> Xen-users mailing list
>> Xen-users@lists.xensource.com
>> http://lists.xensource.com/**xen-users<http://lists.xensource.com/xen-users>
>
>
>

[-- Attachment #1.2: Type: text/html, Size: 3709 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: [Xen-devel] VGA passthough still not working

[Likarpenkov Alexander]

I propose to begin drafting a joint manual. Training system for forwarding 
to be divided into two stages:
- Set the system up to the moment when the device can not be forwarding (xm 
pci-list-assignable-devices is empty)
- Set up DomU vga_passthru = 1 after xm pci-list-assignable-devices gives a 
list of devices
Example:
# Xm pci-list-assignable-devices
0000:03:00.0
0000:00:14.0
0000:00:14.5

 SR> I agree, a manual would be great.

 SR> It would make newcomers, like myself, a little bit more comfortable
 SR> with Xen.

 SR> I think that the first step would be that everyone who has had success
 SR> with VGA passthru should add their hardware setup and xen/kernel
 SR> versions to the 
http://wiki.xen.org/wiki/Xen_VGA_Passthrough_Tested_Adapters wiki
 SR> page, or perhaps we start a new page in the wiki with information on
 SR> how to use particular graphics cards (i.e. how to patch xen to get them
 SR> working), and this page can list success stories.

 SR> Regards

 SR> Sandi

 SR> On Fri, Jan 20, 2012 at 7:53 PM, Likarpenkov Alexander
 SR> <al@ohosting.org.ua>wrote:

 ??>> Please make a manual
 ??>> or let's together make
 ??>>
 ??>> В пятницу, двадцатого января 2012 года, в 18:49:20 Вы писали:
 ??>>
 SR>>> Pasi,
 ??>>
 SR>>> I have that enabled in my BIOS, VT-d for the chipset and VT-x for the
 SR>>> CPU.
 ??>>
 SR>>> Have you managed to pass your gpu through to the domU?
 ??>>
 SR>>> Regards
 ??>>
 SR>>> Sandi
 SR>>> On Jan 20, 2012 4:47 PM, "Pasi Kärkkäinen" <pasik@iki.fi> wrote:
 ??>>
 ??>>>> On Fri, Jan 20, 2012 at 02:05:43PM +0100, Sandi Romih wrote:
 ??>>>>>    Hello,
 ??>>>>>    I have spent a lot of time trying to get gfx passthru working on
 ??>>>>> my
 ??>>>> system
 ??>>>>>    without success.
 ??>>>>>    I looked onto my hardware capabilities again to make sure that
 ??>>>>> it does   support VT-d and I am not too sure that it does fully.
 ??>>>>> My hardware is as follows:   - Supermicro X8DTH-6F motherboard 
(5520
 ??>> chipset
 ??>>>>> which supports VT-d)   - single Xeon X5650 CPU (which is listed as
 ??>>>>> supporting VT-x, no
 ??>>>> mention of
 ??>>>>>    VT-d at [1]ark.intel.com)
 ??>>>>>    Now, according to the [2]VTdHowTo, the motherboard BIOS, chipset
 ??>>>>> AND
 ??>>>> CPU
 ??>>>>>    need to support VT-d.
 ??>>>>>    What confuses me is, why is the 55x0 chipset listed there if
 ??>>>>> none of
 ??>>>> the
 ??>>>>>    CPU's supported, that I know of, dont have the VT-d feature
 ??>>>>> option,
 ??>>>> only
 ??>>>>>    VT-x.
 ??>>>>> 


_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Re: [Xen-users] VGA passthough still not working

[Ian Campbell]

Please do not a) top-post or b) cross-post. The latter being aimed at
whoever started this thread.

On Mon, 2012-01-23 at 11:25 +0000, Sandi Romih wrote:

> Yeah, I guess xen has generally been focused on the server end.

Xen is focused on whatever people submit patches to do. Many of the core
developers are not currently looking at VGA passthrough, we have plenty
of stuff on our plates, but we are more than happy to review and accept
patches to implement/improve/fix this feature if only those people who
are interested in it would take the time to submit them per
http://wiki.xen.org/wiki/SubmittingXenPatches . I'm afraid we are not
going to go out hunting for patches on the Internet.

David Techer recently offered to do this but perhaps he would be
interested in some help from you?

Ian.

Re: [Xen-devel] VGA passthough still not working

[Likarpenkov Alexander]

 SR> Yeah, I guess xen has generally been focused on the server end.

I do not agree. If you think so then, too, Unix only for server.

 SR> But I see some good uses for desktop virtualization too. I personally
 SR> want this so that I can have a file server (zfs based) and a Windows
 SR> desktop (as all the tools I use in my job are mostly only supported in
 SR> MS OS) in one machine. Saves me money and space.

I also combined the two workstations in one system unit: 2 keyboards, 2 
mice, 2 graphics cards, 4 monitors + 15-20 DomU guest for other tasks. This 
is a working office or server room in a box.

Re: [Xen-users] VGA passthough still not working

[Sandi Romih]

[-- Attachment #1.1: Type: text/plain, Size: 3044 bytes --]

Hi John,

I am trying to pass my secondary graphics card through to the VM. My dom0
runs with the primary card (an onboard GPU).

What happens with me is that the secondary card (GTX480) is relinquished to
pciback and according to the logs, it looks like the card is passed through
successfully to the domU.
What happens though is a bit puzzling (with gfx_passthru=1):
1) When I start the domU, my dom0 screen goes blank (which is using a
different graphics card than is assigned to the domU)
2) The domain does not boot; i.e. the CDROM does not spin up.
3) If I connect to the domain via vnc, I see only the qemu console.

With gfx_passthru=0, the following happens:
a) The domain boots fine (the CDROM spins up).
b) I can connect to the OS in the domain via vnc.
c) The Windows OS installs fine and functions fine afterwards too.
d) I can see the GFX480 card in the device manager, but I can not use the
device (even if I install the correct drivers for it)

Check out the details of my problem
here<http://lists.xen.org/archives/html/xen-devel/2012-01/msg01626.html>.
I have marked the things that concern me in red. I am obviously missing
something...

Regards

Sandi






On Fri, Jan 20, 2012 at 8:46 PM, John Sherwood <jrs@vt.edu> wrote:

> Most people run Xen for headless virtual machines, and VGA passthrough
> requires VT-d support in both the CPU and motherboard.  VGA passthrough is
> also somewhat dependent on the card you're using it with, so it's a hard
> thing to test.  If you want it to get more love, then you're the best
> situated person to do it :)
>
> However, on the topic of Sandi's issue:
> If your monitor goes black, that's a GOOD sign - it's indicative that the
> dom0 is relinquishing control of the graphics card, so at least that's
> working.  In my experience using graphics passthrough, this problem is
> related to your card not being fully supported; essentially, Xen can't pass
> your card through to the VM during boot.  If you leave the `gfx_passthru`
> option *disabled*, you'll have the emulated cirrus card (by default) and it
> will at least boot successfully.  Here's some step by step
> suggestions/instructions:
>
>
>    - disable gfx_passthru in config (delete the option or set it to 0)
>    - enable VNC, listening on all interfaces
>    - start the VM - your screen should still go black
>    - From another machine (what with your screen being black), connect in
>    via VNC and fire up the device manager in XP.  I don't have any XP boxes
>    left, but in Windows 7, you should see a device in an error state under
>    'Display adapters'.
>    - Check its PCI slot under 'details' - "Location Paths" should help.
>    Compare that to `xm pci-list [domain name]` to see if it matches up with
>    the graphics card.
>    - Install the driver for that device
>    - Reboot.  You won't see the BIOS on the monitor, but it should use it
>    once Windows takes over.
>
> If something in there doesn't work, hopefully I can help you debug - I
> went through a lot of this a while back.
>
>
>

[-- Attachment #1.2: Type: text/html, Size: 3733 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: [Xen-devel] VGA passthough still not working

[Likarpenkov Alexander]

 IC> Xen is focused on whatever people submit patches to do. Many of the
 IC> core developers are not currently looking at VGA passthrough, we have
 IC> plenty of stuff on our plates, but we are more than happy to review and
 IC> accept patches to implement/improve/fix this feature if only those
 IC> people who are interested in it would take the time to submit them per
 IC> http://wiki.xen.org/wiki/SubmittingXenPatches . I'm afraid we are not
 IC> going to go out hunting for patches on the Internet.

 IC> David Techer recently offered to do this but perhaps he would be
 IC> interested in some help from you?

As far as I understand it, the current set of fluders in this thread is 
ready to provide any assistance.
If we are compiling the kernel team will be in series with the new patch, we 
can make available a service to the masses

Re: [Xen-devel] VGA passthough still not working

[Likarpenkov Alexander]

 SR> I am trying to pass my secondary graphics card through to the VM. My
 SR> dom0 runs with the primary card (an onboard GPU).

 SR> What happens with me is that the secondary card (GTX480) is
 SR> relinquished to pciback and according to the logs, it looks like the
 SR> card is passed through successfully to the domU.
 SR> What happens though is a bit puzzling (with gfx_passthru=1):
 SR> 1) When I start the domU, my dom0 screen goes blank (which is using a
 SR> different graphics card than is assigned to the domU)
 SR> 2) The domain does not boot; i.e. the CDROM does not spin up.
 SR> 3) If I connect to the domain via vnc, I see only the qemu console.

The same nonsense. But my video is ATI

Re: VGA passthough still not working

[Sandi Romih]

[-- Attachment #1.1: Type: text/plain, Size: 3169 bytes --]

Pasi,

Yes, I did verify that IOMMU is enabled. I get this in my xm dmesg:

(XEN) I/O virtualisation enabled

(XEN) Intel VT-d Snoop Control supported.(XEN) Intel VT-d DMA
Passthrough not supported.(XEN) Intel VT-d Queued Invalidation
supported.(XEN) Intel VT-d Interrupt Remapping not supported.

But I dont think I have this message (I am not near my system now, so I can
not confirm)

(XEN) I/O virtualisation for PV guests enabled


I believe that many have managed to get VGA passthru working, but they
generally dont post their stories. one only finds the problems they are
encountering when searching about this. That is why it would be nice to put
together a kind of manual in the wiki which would have all this info
together in one location.

Thanks for the help

Regards

Sandi


On Fri, Jan 20, 2012 at 9:32 PM, Pasi Kärkkäinen <pasik@iki.fi> wrote:

> On Fri, Jan 20, 2012 at 05:49:20PM +0100, Sandi Romih wrote:
> >    Pasi,
> >
> >    I have that enabled in my BIOS, VT-d for the chipset and VT-x for the
> CPU.
> >
>
> Ok. And Xen enables IOMMU? Did you verify from Xen's dmesg ?
>
>
> http://wiki.xen.org/xenwiki/XenCommonProblems.html#head-2f76ed2d3c282003418d37fbbcda510cac266f89
>
>
>
> >    Have you managed to pass your gpu through to the domU?
> >
>
> No, I haven't tried that yet. I've been planning to, but I haven't had
> time for it yet.
>
> There are many people who are using Xen VGA passthru with Intel, AMD/ATI
> and Nvidia graphics cards.
> Currently it needs a lot of understanding and some custom patching, but
> you can make it work.
>
> There are even businesses using Xen VGA passthru in production :)
>
> -- Pasi
>
> >
> >    Sandi
> >
> >    On Jan 20, 2012 4:47 PM, "Pasi Kärkkäinen" <[1]pasik@iki.fi> wrote:
> >
> >      On Fri, Jan 20, 2012 at 02:05:43PM +0100, Sandi Romih wrote:
> >      >    Hello,
> >      >    I have spent a lot of time trying to get gfx passthru working
> on my
> >      system
> >      >    without success.
> >      >    I looked onto my hardware capabilities again to make sure that
> it
> >      does
> >      >    support VT-d and I am not too sure that it does fully.
> >      >    My hardware is as follows:
> >      >    - Supermicro X8DTH-6F motherboard (5520 chipset which supports
> >      VT-d)
> >      >    - single Xeon X5650 CPU (which is listed as supporting VT-x, no
> >      mention of
> >      >    VT-d at [1][2]ark.intel.com)
> >      >    Now, according to the [2]VTdHowTo, the motherboard BIOS,
> chipset
> >      AND CPU
> >      >    need to support VT-d.
> >      >    What confuses me is, why is the 55x0 chipset listed there if
> none
> >      of the
> >      >    CPU's supported, that I know of, dont have the VT-d feature
> option,
> >      only
> >      >    VT-x.
> >      >
> >
> >      I've been using VT-d with Xen with Intel 5500 series chipset, and
> Xeon
> >      5600 series CPU.
> >      VT-d needs to be enabled in the BIOS.
> >
> >      -- Pasi
> >
> > References
> >
> >    Visible links
> >    1. mailto:pasik@iki.fi
> >    2. http://ark.intel.com/
>

[-- Attachment #1.2: Type: text/html, Size: 7176 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: [Xen-devel] VGA passthough still not working

[Likarpenkov Alexander]

 SR>> I am trying to pass my secondary graphics card through to the VM. My
 SR>> dom0 runs with the primary card (an onboard GPU).

 SR>> What happens with me is that the secondary card (GTX480) is
 SR>> relinquished to pciback and according to the logs, it looks like the
 SR>> card is passed through successfully to the domU.
 SR>> What happens though is a bit puzzling (with gfx_passthru=1):
 SR>> 1) When I start the domU, my dom0 screen goes blank (which is using a
 SR>> different graphics card than is assigned to the domU)
 SR>> 2) The domain does not boot; i.e. the CDROM does not spin up.
 SR>> 3) If I connect to the domain via vnc, I see only the qemu console.

 LA> The same nonsense. But my video is ATI
I mean I have a similar result

Re: [Xen-users] VGA passthough still not working

[Tobias Geiger]

Hello!

The thing is, you either dont need patches at all to get it to work (ATI), or 
you need to customize patches reflecting your individual setup (NVIDIA);

To be more specific:
I can confirm that passing through a ATI Card works "out of the box" - either 
to Windows 7 or Windows XP;
In the past i had a setup running with a NVIDIA card, it only worked with 
special patches (the ones David packed together and offers as tarball) and - as 
far as i can tell - are not generaly working for all NVIDIA Cards, i.e. you 
have to adjust Memory-Adresses in the acpi.dst (iirc). - and even then the 
passed through Card worked only with Windows XP - NOT with Windows 7;

Both setup have the "flaw" that they only work once - meaning you can't reboot 
your DomU , cause after the reboot the passed-through Card doesnt have correct 
3D-Accelleration any more (was/is the case with NVIDIA and ATI, Windows XP and 
Windows7 )

So - to summarize: It works easiest and most featureful with a ATI Card; 
                            It may work with patches and only with WindowsXP 
with an NVIDIA card

To me it seems that unless someone finds an general approach to runtime-detect 
the NVIDIA-Secific stuff , submitting any patches may be to early, as it arouses 
expectations which only in some cases will be met.

That said - i gladly can forward-port these old patches, if you think they are 
helping in any way.

Greetings!
Tobias

Am Montag, 23. Januar 2012, 12:39:38 schrieb Ian Campbell:
> Please do not a) top-post or b) cross-post. The latter being aimed at
> whoever started this thread.
> 
> On Mon, 2012-01-23 at 11:25 +0000, Sandi Romih wrote:
> > Yeah, I guess xen has generally been focused on the server end.
> 
> Xen is focused on whatever people submit patches to do. Many of the core
> developers are not currently looking at VGA passthrough, we have plenty
> of stuff on our plates, but we are more than happy to review and accept
> patches to implement/improve/fix this feature if only those people who
> are interested in it would take the time to submit them per
> http://wiki.xen.org/wiki/SubmittingXenPatches . I'm afraid we are not
> going to go out hunting for patches on the Internet.
> 
> David Techer recently offered to do this but perhaps he would be
> interested in some help from you?
> 
> Ian.
> 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

Re: [Xen-devel] VGA passthough still not working

[Likarpenkov Alexander]

As has already been written before - does not work. This water in the 
internet a lot. If you work - help with a manual. I am from April 2011, each 
month make a new entry. In January, compiled nine different versions of the 
kernel for Xena. 3 different versions of Xena: 4.0.2rc3, 4.1.2,4.2 unstable 
/ test them on debian and Ubuntu - not worked

 TG> The thing is, you either dont need patches at all to get it to work
 TG> (ATI), or you need to customize patches reflecting your individual
 TG> setup (NVIDIA);

 TG> To be more specific:
 TG> I can confirm that passing through a ATI Card works "out of the box" -
 TG> either to Windows 7 or Windows XP;
 TG> In the past i had a setup running with a NVIDIA card, it only worked
 TG> with special patches (the ones David packed together and offers as
 TG> tarball) and - as far as i can tell - are not generaly working for all
 TG> NVIDIA Cards, i.e. you have to adjust Memory-Adresses in the acpi.dst
 TG> (iirc). - and even then the passed through Card worked only with
 TG> Windows XP - NOT with Windows 7;

 TG> Both setup have the "flaw" that they only work once - meaning you can't
 TG> reboot your DomU , cause after the reboot the passed-through Card
 TG> doesnt have correct 3D-Accelleration any more (was/is the case with
 TG> NVIDIA and ATI, Windows XP and Windows7 )

 TG> So - to summarize: It works easiest and most featureful with a ATI 
Card;
 TG>                        It may work with patches and only with WindowsXP
 TG> with an NVIDIA card

 TG> To me it seems that unless someone finds an general approach to
 TG> runtime-detect the NVIDIA-Secific stuff , submitting any patches may be
 TG> to early, as it arouses expectations which only in some cases will be
 TG> met.

 TG> That said - i gladly can forward-port these old patches, if you think
 TG> they are helping in any way.

 TG> Greetings!
 TG> Tobias

 TG> Am Montag, 23. Januar 2012, 12:39:38 schrieb Ian Campbell:
 ??>> Please do not a) top-post or b) cross-post. The latter being aimed at
 ??>> whoever started this thread.
 ??>>
 ??>> On Mon, 2012-01-23 at 11:25 +0000, Sandi Romih wrote:
 ??>>> Yeah, I guess xen has generally been focused on the server end.
 ??>>
 ??>> Xen is focused on whatever people submit patches to do. Many of the
 ??>> core developers are not currently looking at VGA passthrough, we have
 ??>> plenty of stuff on our plates, but we are more than happy to review
 ??>> and accept patches to implement/improve/fix this feature if only those
 ??>> people who are interested in it would take the time to submit them per
 ??>> http://wiki.xen.org/wiki/SubmittingXenPatches . I'm afraid we are not
 ??>> going to go out hunting for patches on the Internet.
 ??>>
 ??>> David Techer recently offered to do this but perhaps he would be
 ??>> interested in some help from you?
 ??>>

Re : [Xen-users] VGA passthough still not working

[David TECHER]

[-- Attachment #1.1: Type: text/plain, Size: 3614 bytes --]

To be more precised

- Using ATI is much easier...........................................I agree even if I haven't yet tested it. My new ATI card is sleeping in my room


- NVIDIA + domU HVM Windows XP don't reboot...I agree except that  restarting will work only once if - for the first shutdown - you use 'shutdown -s -t 00'.


- NVIDIA + domU HVM Linux + PVHVMonLinux drivers can be rebooted several times  but this domU has to be the first domU rebooted since the start of the dom0.












________________________________
 De : Tobias Geiger <tobias.geiger@vido.info>
À : xen-devel@lists.xensource.com 
Cc : Sandi Romih <romihs.forums@gmail.com>; "xen-users@lists.xensource.com" <xen-users@lists.xensource.com>; Ian Campbell <Ian.Campbell@citrix.com>; chris <tknchris@gmail.com> 
Envoyé le : Lundi 23 janvier 2012 14h17
Objet : Re: [Xen-devel] [Xen-users]  VGA passthough still not working
 
Hello!

The thing is, you either dont need patches at all to get it to work (ATI), or 
you need to customize patches reflecting your individual setup (NVIDIA);

To be more specific:
I can confirm that passing through a ATI Card works "out of the box" - either 
to Windows 7 or Windows XP;
In the past i had a setup running with a NVIDIA card, it only worked with 
special patches (the ones David packed together and offers as tarball) and - as 
far as i can tell - are not generaly working for all NVIDIA Cards, i.e. you 
have to adjust Memory-Adresses in the acpi.dst (iirc). - and even then the 
passed through Card worked only with Windows XP - NOT with Windows 7;

Both setup have the "flaw" that they only work once - meaning you can't reboot 
your DomU , cause after the reboot the passed-through Card doesnt have correct 
3D-Accelleration any more (was/is the case with NVIDIA and ATI, Windows XP and 
Windows7 )

So - to summarize: It works easiest and most featureful with a ATI Card; 
                            It may work with patches and only with WindowsXP 
with an NVIDIA card

To me it seems that unless someone finds an general approach to runtime-detect 
the NVIDIA-Secific stuff , submitting any patches may be to early, as it arouses 
expectations which only in some cases will be met.

That said - i gladly can forward-port these old patches, if you think they are 
helping in any way.

Greetings!
Tobias

Am Montag, 23. Januar 2012, 12:39:38 schrieb Ian Campbell:
> Please do not a) top-post or b) cross-post. The latter being aimed at
> whoever started this thread.
> 
> On Mon, 2012-01-23 at 11:25 +0000, Sandi Romih wrote:
> > Yeah, I guess xen has generally been focused on the server end.
> 
> Xen is focused on whatever people submit patches to do. Many of the core
> developers are not currently looking at VGA passthrough, we have plenty
> of stuff on our plates, but we are more than happy to review and accept
> patches to implement/improve/fix this feature if only those people who
> are interested in it would take the time to submit them per
> http://wiki.xen.org/wiki/SubmittingXenPatches . I'm afraid we are not
> going to go out hunting for patches on the Internet.
> 
> David Techer recently offered to do this but perhaps he would be
> interested in some help from you?
> 
> Ian.
> 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


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

[-- Attachment #1.2: Type: text/html, Size: 5461 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: [Xen-users] VGA passthough still not working

[Konrad Rzeszutek Wilk]

On Mon, Jan 23, 2012 at 02:17:42PM +0100, Tobias Geiger wrote:
> Hello!
> 
> The thing is, you either dont need patches at all to get it to work (ATI), or 
> you need to customize patches reflecting your individual setup (NVIDIA);
> 
> To be more specific:
> I can confirm that passing through a ATI Card works "out of the box" - either 
> to Windows 7 or Windows XP;
> In the past i had a setup running with a NVIDIA card, it only worked with 
> special patches (the ones David packed together and offers as tarball) and - as 
> far as i can tell - are not generaly working for all NVIDIA Cards, i.e. you 
> have to adjust Memory-Adresses in the acpi.dst (iirc). - and even then the 
> passed through Card worked only with Windows XP - NOT with Windows 7;
> 
> Both setup have the "flaw" that they only work once - meaning you can't reboot 
> your DomU , cause after the reboot the passed-through Card doesnt have correct 
> 3D-Accelleration any more (was/is the case with NVIDIA and ATI, Windows XP and 
> Windows7 )

For me it was with ATI with Windows7. Hadn't tried other OSes.

Anybody had luck with passing the card more than once to a guest? With
any random set of patches?
> 
> So - to summarize: It works easiest and most featureful with a ATI Card; 
>                             It may work with patches and only with WindowsXP 
> with an NVIDIA card
> 
> To me it seems that unless someone finds an general approach to runtime-detect 
> the NVIDIA-Secific stuff , submitting any patches may be to early, as it arouses 
> expectations which only in some cases will be met.

> 
> That said - i gladly can forward-port these old patches, if you think they are 
> helping in any way.
> 
> Greetings!
> Tobias
> 
> Am Montag, 23. Januar 2012, 12:39:38 schrieb Ian Campbell:
> > Please do not a) top-post or b) cross-post. The latter being aimed at
> > whoever started this thread.
> > 
> > On Mon, 2012-01-23 at 11:25 +0000, Sandi Romih wrote:
> > > Yeah, I guess xen has generally been focused on the server end.
> > 
> > Xen is focused on whatever people submit patches to do. Many of the core
> > developers are not currently looking at VGA passthrough, we have plenty
> > of stuff on our plates, but we are more than happy to review and accept
> > patches to implement/improve/fix this feature if only those people who
> > are interested in it would take the time to submit them per
> > http://wiki.xen.org/wiki/SubmittingXenPatches . I'm afraid we are not
> > going to go out hunting for patches on the Internet.
> > 
> > David Techer recently offered to do this but perhaps he would be
> > interested in some help from you?
> > 
> > Ian.
> > 
> > 
> > 
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

Re: [Xen-users] VGA passthough still not working

[Konrad Rzeszutek Wilk]

On Mon, Jan 23, 2012 at 12:45:05PM +0100, Sandi Romih wrote:
> Hi John,
> 
> I am trying to pass my secondary graphics card through to the VM. My dom0
> runs with the primary card (an onboard GPU).
> 
> What happens with me is that the secondary card (GTX480) is relinquished to
> pciback and according to the logs, it looks like the card is passed through
> successfully to the domU.
> What happens though is a bit puzzling (with gfx_passthru=1):
> 1) When I start the domU, my dom0 screen goes blank (which is using a
> different graphics card than is assigned to the domU)
> 2) The domain does not boot; i.e. the CDROM does not spin up.
> 3) If I connect to the domain via vnc, I see only the qemu console.
> 
> With gfx_passthru=0, the following happens:
> a) The domain boots fine (the CDROM spins up).
> b) I can connect to the OS in the domain via vnc.
> c) The Windows OS installs fine and functions fine afterwards too.
> d) I can see the GFX480 card in the device manager, but I can not use the
> device (even if I install the correct drivers for it)

So you are using Nvidia. And those seem to require some extra patches.
Look for the vBar=pBar or so.

> 
> Check out the details of my problem
> here<http://lists.xen.org/archives/html/xen-devel/2012-01/msg01626.html>.
> I have marked the things that concern me in red. I am obviously missing
> something...

Did you look at David Techer postings? He has been doing extensive work
in this area.

Re: VGA passthough still not working

[Konrad Rzeszutek Wilk]

On Mon, Jan 23, 2012 at 12:53:50PM +0100, Sandi Romih wrote:
> Pasi,
> 
> Yes, I did verify that IOMMU is enabled. I get this in my xm dmesg:
> 
> (XEN) I/O virtualisation enabled
> 
> (XEN) Intel VT-d Snoop Control supported.(XEN) Intel VT-d DMA
> Passthrough not supported.(XEN) Intel VT-d Queued Invalidation
> supported.(XEN) Intel VT-d Interrupt Remapping not supported.
> 
> But I dont think I have this message (I am not near my system now, so I can
> not confirm)
> 
> (XEN) I/O virtualisation for PV guests enabled
> 
> 
> I believe that many have managed to get VGA passthru working, but they
> generally dont post their stories. one only finds the problems they are
> encountering when searching about this. That is why it would be nice to put
> together a kind of manual in the wiki which would have all this info
> together in one location.

http://lmgtfy.com/?q=Xen+VGA+passthrough

Re: [Xen-devel] VGA passthough still not working

[Likarpenkov Alexander]

 TG> That said - i gladly can forward-port these old patches, if you think
 TG> they are helping in any way.

I propose to begin the creation of the manual.
Specifically for this purpose I created a blog and an article on this topic.
According to the information came to the mailing list or in blog comments 
will summarize and publish
See link:
http://lixen.ua-ohosting.com/archives/31 

Re: [Xen-users] VGA passthough still not working

[djmagee]

> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-
> bounces@lists.xensource.com] On Behalf Of Konrad Rzeszutek Wilk
> Sent: Monday, January 23, 2012 8:50 PM
> To: Tobias Geiger
> Cc: Sandi Romih; chris; xen-devel@lists.xensource.com; xen-
> users@lists.xensource.com; Ian Campbell
> Subject: Re: [Xen-devel] [Xen-users] VGA passthough still not working
> 
> On Mon, Jan 23, 2012 at 02:17:42PM +0100, Tobias Geiger wrote:
> > Hello!
> >
> > The thing is, you either dont need patches at all to get it to work
> (ATI), or
> > you need to customize patches reflecting your individual setup
> (NVIDIA);
> >
> > To be more specific:
> > I can confirm that passing through a ATI Card works "out of the box"
> - either
> > to Windows 7 or Windows XP;
> > In the past i had a setup running with a NVIDIA card, it only worked
> with
> > special patches (the ones David packed together and offers as
> tarball) and - as
> > far as i can tell - are not generaly working for all NVIDIA Cards,
> i.e. you
> > have to adjust Memory-Adresses in the acpi.dst (iirc). - and even
> then the
> > passed through Card worked only with Windows XP - NOT with Windows
7;
> >
> > Both setup have the "flaw" that they only work once - meaning you
> can't reboot
> > your DomU , cause after the reboot the passed-through Card doesnt
> have correct
> > 3D-Accelleration any more (was/is the case with NVIDIA and ATI,
> Windows XP and
> > Windows7 )
> 
> For me it was with ATI with Windows7. Hadn't tried other OSes.
> 
> Anybody had luck with passing the card more than once to a guest? With
> any random set of patches?

Yes, I've had a machine running for a couple of weeks, hosting a Windows
7 domu with a passed-through Radeon 4770.  I've rebooted the virtual
machine multiple times, as well as gone through a couple of xl
destroy/create cycles.

I only pass it through as a secondary card, as I have the IGD as the
primary on the host.  The machine is a DQ67SW with a Core i5.  This is
running xen-unstable (c/s 24465) on a 3.2.1 dom0, with no extra patches.

I haven't, however, had any luck passing through the IGD to anything
other than a Windows XP, and that includes running the latest qemu-xen
with Jean's patches (opregion, host bridge config space mapping).  I've
been intending to start a separate thread for that...

Re: [Xen-devel] VGA passthough still not working

[Likarpenkov Alexander]

 ??>>> Hello!
 ??>>>
 ??>>> The thing is, you either dont need patches at all to get it to work
 ??>> (ATI), or
 ??>>> you need to customize patches reflecting your individual setup
 ??>> (NVIDIA);
 ??>>>
 ??>>> To be more specific:
 ??>>> I can confirm that passing through a ATI Card works "out of the box"
 ??>> - either
 ??>>> to Windows 7 or Windows XP;
 ??>>> In the past i had a setup running with a NVIDIA card, it only worked
 ??>> with
 ??>>> special patches (the ones David packed together and offers as
 ??>> tarball) and - as
 ??>>> far as i can tell - are not generaly working for all NVIDIA Cards,
 ??>> i.e. you
 ??>>> have to adjust Memory-Adresses in the acpi.dst (iirc). - and even
 ??>> then the
 ??>>> passed through Card worked only with Windows XP - NOT with Windows
 d> 7;
 ??>>>
 ??>>> Both setup have the "flaw" that they only work once - meaning you
 ??>> can't reboot
 ??>>> your DomU , cause after the reboot the passed-through Card doesnt
 ??>> have correct
 ??>>> 3D-Accelleration any more (was/is the case with NVIDIA and ATI,
 ??>> Windows XP and
 ??>>> Windows7 )
 ??>>
 ??>> For me it was with ATI with Windows7. Hadn't tried other OSes.
 ??>>
 ??>> Anybody had luck with passing the card more than once to a guest? With
 ??>> any random set of patches?
^^^^^^^^^^^^^^^^^^^^^^^^
Better not to quote, than to do wrong quoting!!!
Also see the question below/

 d> Yes, I've had a machine running for a couple of weeks, hosting a Windows
 d> 7 domu with a passed-through Radeon 4770.  I've rebooted the virtual
 d> machine multiple times, as well as gone through a couple of xl
 d> destroy/create cycles.

 d> I only pass it through as a secondary card, as I have the IGD as the
 d> primary on the host.  The machine is a DQ67SW with a Core i5.  This is
 d> running xen-unstable (c/s 24465) on a 3.2.1 dom0, with no extra patches.

 d> I haven't, however, had any luck passing through the IGD to anything
 d> other than a Windows XP, and that includes running the latest qemu-xen
 d> with Jean's patches (opregion, host bridge config space mapping).  I've
 d> been intending to start a separate thread for that...

Can you put a youtube video start DomU after
# Xm create
??? 

Re: [Xen-users] VGA passthough still not working

[Tobias Geiger]

Am Dienstag, 24. Januar 2012, 15:12:40 schrieb djmagee@mageenet.net:
> > -----Original Message-----
> > From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-
> > bounces@lists.xensource.com] On Behalf Of Konrad Rzeszutek Wilk
> > Sent: Monday, January 23, 2012 8:50 PM
> > To: Tobias Geiger
> > Cc: Sandi Romih; chris; xen-devel@lists.xensource.com; xen-
> > users@lists.xensource.com; Ian Campbell
> > Subject: Re: [Xen-devel] [Xen-users] VGA passthough still not working
> > 
> > On Mon, Jan 23, 2012 at 02:17:42PM +0100, Tobias Geiger wrote:
> > > Hello!
> > > 
> > > The thing is, you either dont need patches at all to get it to work
> > 
> > (ATI), or
> > 
> > > you need to customize patches reflecting your individual setup
> > 
> > (NVIDIA);
> > 
> > > To be more specific:
> > > I can confirm that passing through a ATI Card works "out of the box"
> > 
> > - either
> > 
> > > to Windows 7 or Windows XP;
> > > In the past i had a setup running with a NVIDIA card, it only worked
> > 
> > with
> > 
> > > special patches (the ones David packed together and offers as
> > 
> > tarball) and - as
> > 
> > > far as i can tell - are not generaly working for all NVIDIA Cards,
> > 
> > i.e. you
> > 
> > > have to adjust Memory-Adresses in the acpi.dst (iirc). - and even
> > 
> > then the
> > 
> > > passed through Card worked only with Windows XP - NOT with Windows
> 
> 7;
> 
> > > Both setup have the "flaw" that they only work once - meaning you
> > 
> > can't reboot
> > 
> > > your DomU , cause after the reboot the passed-through Card doesnt
> > 
> > have correct
> > 
> > > 3D-Accelleration any more (was/is the case with NVIDIA and ATI,
> > 
> > Windows XP and
> > 
> > > Windows7 )
> > 
> > For me it was with ATI with Windows7. Hadn't tried other OSes.
> > 
> > Anybody had luck with passing the card more than once to a guest? With
> > any random set of patches?
> 

I was a bit un-percice regarding the "reboot" issue:

The passing-through itself works even after a reboot of DomU - the rebooted 
System spits out its Graphics normaly through the passed-through Card (NVIDA 
or ATI doesnt matter here) ; BUT:
After a reboot it doesn't work properly. Meaning: Slow 3d Performance, i.e. 
unsable for real 3d apps, even a 3d Desktop;
For example, when the Card gives you 70fps in a Benchmark after a fresh Cold 
Boot, it only gives you 5-10fps after a reboot, this will be that low until 
you reboot Dom0 also, not only DomU;

hopefully i described the scenario better now...


> Yes, I've had a machine running for a couple of weeks, hosting a Windows
> 7 domu with a passed-through Radeon 4770.  I've rebooted the virtual
> machine multiple times, as well as gone through a couple of xl
> destroy/create cycles.
> 
> I only pass it through as a secondary card, as I have the IGD as the
> primary on the host.  The machine is a DQ67SW with a Core i5.  This is
> running xen-unstable (c/s 24465) on a 3.2.1 dom0, with no extra patches.
> 
> I haven't, however, had any luck passing through the IGD to anything
> other than a Windows XP, and that includes running the latest qemu-xen
> with Jean's patches (opregion, host bridge config space mapping).  I've
> been intending to start a separate thread for that...

Re: [Xen-devel] VGA passthough still not working

[Likarpenkov Alexander]

 TG> I was a bit un-percice regarding the "reboot" issue:

 TG> The passing-through itself works even after a reboot of DomU - the
 TG> rebooted System spits out its Graphics normaly through the
 TG> passed-through Card (NVIDA or ATI doesnt matter here) ; BUT:
 TG> After a reboot it doesn't work properly. Meaning: Slow 3d Performance, 
i.e.
 TG> unsable for real 3d apps, even a 3d Desktop;
 TG> For example, when the Card gives you 70fps in a Benchmark after a fresh
 TG> Cold Boot, it only gives you 5-10fps after a reboot, this will be that
 TG> low until you reboot Dom0 also, not only DomU;

 TG> hopefully i described the scenario better now...

 That is, situations as follows:
- There is a certain group who are trying to make a vga pass, but success
- In the second group turned out, the performance on the second restart the 
deplorable

I belong to the first group, but I use a pci pass and after 10-20 reboots 
the system does not lose the 3D performance.

Question for Tobias Geiger:
You do not deign to describe the process step by step is the setup and 
configuration xen-linux-syste to a successful vga pass? 

Re: [Xen-devel] VGA passthough still not working

[Likarpenkov Alexander]

[-- Attachment #1.1: Type: text/plain, Size: 1226 bytes --]

TG> I was a bit un-percice regarding the "reboot" issue:

 TG> The passing-through itself works even after a reboot of DomU - the
 TG> rebooted System spits out its Graphics normaly through the
 TG> passed-through Card (NVIDA or ATI doesnt matter here) ; BUT:
 TG> After a reboot it doesn't work properly. Meaning: 
 TG> Slow 3d Performance, i.e.
 TG> unsable for real 3d apps, even a 3d Desktop;
 TG> For example, when the Card gives you 70fps in a Benchmark after a fresh
 TG> Cold Boot, it only gives you 5-10fps after a reboot, this will be that
 TG> low until you reboot Dom0 also, not only DomU;
 TG> hopefully i described the scenario better now...

I'm sorry. Errors are highlighted in red.

 That is, situations as follows:
- There is a certain group who are trying to make a vga pass, but not successed (unsuccessfully)
- In the second group turned out, the performance on the second restart the 
deplorable

I belong to the first group, but I use a pci pass and after 10-20 reboots 
the system does not lose the 3D performance.

Question for Tobias Geiger:
You do not deign to describe the process step by step is the setup and 
configuration xen-linux-systeM to a successful vga pass? 


[-- Attachment #1.2: Type: text/html, Size: 2194 bytes --]

[-- Attachment #2: Type: text/plain, Size: 137 bytes --]

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Re: [Xen-users] VGA passthough still not working

[Tobias Geiger]

Am Dienstag, 24. Januar 2012, 16:15:29 schrieb Likarpenkov Alexander:
> TG> I was a bit un-percice regarding the "reboot" issue:
> 
>  TG> The passing-through itself works even after a reboot of DomU - the
>  TG> rebooted System spits out its Graphics normaly through the
>  TG> passed-through Card (NVIDA or ATI doesnt matter here) ; BUT:
>  TG> After a reboot it doesn't work properly. Meaning:
>  TG> Slow 3d Performance, i.e.
>  TG> unsable for real 3d apps, even a 3d Desktop;
>  TG> For example, when the Card gives you 70fps in a Benchmark after a
> fresh TG> Cold Boot, it only gives you 5-10fps after a reboot, this will
> be that TG> low until you reboot Dom0 also, not only DomU;
>  TG> hopefully i described the scenario better now...
> 
> I'm sorry. Errors are highlighted in red.
> 
>  That is, situations as follows:
> - There is a certain group who are trying to make a vga pass, but not
> successed (unsuccessfully) - In the second group turned out, the
> performance on the second restart the deplorable
> 
> I belong to the first group, but I use a pci pass and after 10-20 reboots
> the system does not lose the 3D performance.
> 
> Question for Tobias Geiger:
> You do not deign to describe the process step by step is the setup and
> configuration xen-linux-systeM to a successful vga pass?

I'm of course deigning an answer (what a nice english word - didn't know that 
before!) - here it is:

My Hardware:

Motherboard: DX58SO
CPU: Intel(R) Core(TM) i7 CPU         920  @ 2.67GHz

Dom0 kernel: 3.3.0-rc1
Dom0 gfx: 02:00.0 VGA compatible controller: nVidia Corporation G96 [GeForce 
9500 GT] (rev a1)

DomU OS: Windows 7 64bit
DomU gfx: 03:00.0 VGA compatible controller: ATI Technologies Inc Cayman XT 
[Radeon HD 6970]


Step one: get xen working 
i'm using the current unstable, but 4.1.X was also working;

hg clone http://xenbits.xensource.com/xen-unstable.hg
make
make install 
...

Step two: Prepare your Dom0 kernel - my .config for 3.3.0-rc1 is here: 
http://pastebin.com/T74n3KVg

You need to find out your PCI-Ids to pass through - lspci does the job here;
my personal cmdline is:

ro root=/dev/sda1 ro selinux=0 xen-pciback.hide=(03:00.0)(03:00.1)(00:1d.0)
(00:1d.1)(00:1d.2)(00:1d.7) noirqdebug nouveau.modeset=1 security=apparmor

It passes through the ATI Card (3.00) and its HDMI controller (3.00.1) and one 
USB Controller (1.0 and 2.0/ EHCI and OHCI)


Step three: Configure xen DomU config: - mine is here: 
http://pastebin.com/4BJcfpw9 
(CAUTION: insert valid uuid and mac!)


Step four: Fire it up and dont be irritated by the fact that you need to do 
the initial windows setup within the VNC Screen - as soon as you install the 
Catalyst Driver and reboot you should get output on your Physical Screen 
attached to the passed through gfx card


IIRC thats it. 

Dont fiddle with GPLPV Drivers - i dont know why but the performance is worse 
with GPLPV drivers compared to "vanilla" windows drivers...

And dont try to install any soundcard (except a USB attached one) - the ac97 
device emulated by the current qemu version has no valid driver for win7-64 - 
we have to wait until upstream qemu is working with current xen, it brings a 
emulated intel-hda card.

Step five may be important, otherwise you go crazy with the emulated mouse 
within the vnc-screen: Install Synergy on domU and Dom0 ;)


Greetings and good luck!
Tobias

Re: [Xen-users] VGA passthough still not working

[Tobias Geiger]

Am Dienstag, 24. Januar 2012, 16:15:29 schrieb Likarpenkov Alexander:
> TG> I was a bit un-percice regarding the "reboot" issue:
> 
>  TG> The passing-through itself works even after a reboot of DomU - the
>  TG> rebooted System spits out its Graphics normaly through the
>  TG> passed-through Card (NVIDA or ATI doesnt matter here) ; BUT:
>  TG> After a reboot it doesn't work properly. Meaning:
>  TG> Slow 3d Performance, i.e.
>  TG> unsable for real 3d apps, even a 3d Desktop;
>  TG> For example, when the Card gives you 70fps in a Benchmark after a
> fresh TG> Cold Boot, it only gives you 5-10fps after a reboot, this will
> be that TG> low until you reboot Dom0 also, not only DomU;
>  TG> hopefully i described the scenario better now...
> 
> I'm sorry. Errors are highlighted in red.
> 
>  That is, situations as follows:
> - There is a certain group who are trying to make a vga pass, but not
> successed (unsuccessfully) - In the second group turned out, the
> performance on the second restart the deplorable
> 
> I belong to the first group, but I use a pci pass and after 10-20 reboots
> the system does not lose the 3D performance.
> 
> Question for Tobias Geiger:
> You do not deign to describe the process step by step is the setup and
> configuration xen-linux-systeM to a successful vga pass?


What i forgot was the cmdline for the xen hypervisor (not that important 
though):

watchdog dom0_mem=4096M dom0_max_vcpus=4 dom0_vcpus_pin 
cpufreq=xen:performance


it turned out to be a good idea to pin the vcpus not while running (with xl 
vcpu-pin) but as early as possible -  that way even a "make -j99 bzImage" 
within Dom0 doesnt really affect the DomU Performance (yes, otherwise i had the 
impression it was noticable)

Greetings again!
Tobias

Re: [Xen-users] VGA passthough still not working

[Tobias Geiger]

The more i think about it, the more i remember:

After installing Windows within DomU and after installing the Catalyst Driver, 
i remember disabling the Emulated Cirrus VGA Card within the Device-Manager in 
Windows; don't know exactly anymore, but this could be an important step so 
that the Catalyst Driver "takes over" correctly;

Another hint: To acces the VNC console:

xvncviewer localhost:5910
(if you use the DomU Config pasted)

and of course you need to adapt the DomU Config especially for the first boot - 
to include an ISO Image of the Windows-Install-CD , e.g.:

disk = [ 'phy:/dev/vg_ssd/win7system,hda,w' , 
'file:/path/to/windows.iso,ioemu:hdb,r' ]

also 
boot="dc"

would be better while installing Windows

Greetings!
Tobias




Am Dienstag, 24. Januar 2012, 16:15:29 schrieb Likarpenkov Alexander:
> TG> I was a bit un-percice regarding the "reboot" issue:
> 
>  TG> The passing-through itself works even after a reboot of DomU - the
>  TG> rebooted System spits out its Graphics normaly through the
>  TG> passed-through Card (NVIDA or ATI doesnt matter here) ; BUT:
>  TG> After a reboot it doesn't work properly. Meaning:
>  TG> Slow 3d Performance, i.e.
>  TG> unsable for real 3d apps, even a 3d Desktop;
>  TG> For example, when the Card gives you 70fps in a Benchmark after a
> fresh TG> Cold Boot, it only gives you 5-10fps after a reboot, this will
> be that TG> low until you reboot Dom0 also, not only DomU;
>  TG> hopefully i described the scenario better now...
> 
> I'm sorry. Errors are highlighted in red.
> 
>  That is, situations as follows:
> - There is a certain group who are trying to make a vga pass, but not
> successed (unsuccessfully) - In the second group turned out, the
> performance on the second restart the deplorable
> 
> I belong to the first group, but I use a pci pass and after 10-20 reboots
> the system does not lose the 3D performance.
> 
> Question for Tobias Geiger:
> You do not deign to describe the process step by step is the setup and
> configuration xen-linux-systeM to a successful vga pass?

Re: [Xen-users] VGA passthough still not working

[Doug Magee]

On Tue, 2012-01-24 at 09:37 -0500, Tobias Geiger wrote:
> > > > Both setup have the "flaw" that they only work once - meaning
> you
> > >
> > > can't reboot
> > >
> > > > your DomU , cause after the reboot the passed-through Card
> doesnt
> > >
> > > have correct
> > >
> > > > 3D-Accelleration any more (was/is the case with NVIDIA and ATI,
> > >
> > > Windows XP and
> > >
> > > > Windows7 )
> > >
> > > For me it was with ATI with Windows7. Hadn't tried other OSes.
> > >
> > > Anybody had luck with passing the card more than once to a guest?
> With
> > > any random set of patches?
> >
> 
> I was a bit un-percice regarding the "reboot" issue:
> 
> The passing-through itself works even after a reboot of DomU - the
> rebooted
> System spits out its Graphics normaly through the passed-through Card
> (NVIDA
> or ATI doesnt matter here) ; BUT:
> After a reboot it doesn't work properly. Meaning: Slow 3d Performance,
> i.e.
> unsable for real 3d apps, even a 3d Desktop;
> For example, when the Card gives you 70fps in a Benchmark after a
> fresh Cold
> Boot, it only gives you 5-10fps after a reboot, this will be that low
> until
> you reboot Dom0 also, not only DomU;
> 
> hopefully i described the scenario better now...
> 

Ah, got it.  I hadn't been doing anything 3D intensive, only running the
Aero desktop.  I installed 3DMark Vantage and ran a couple of tests.  I
get the same results (within a fraction of a %) after a cold boot as i
do after rebooting multiple times, and always very close to native.  It
seems i don't have the problem you're having.

Do you get any different log messages after a reboot (xl dmesg, dom0
dmesg, qemu log)?  Have you tried with iommu=verbose to see if there's
any more useful information there?

> 
> > Yes, I've had a machine running for a couple of weeks, hosting a
> Windows
> > 7 domu with a passed-through Radeon 4770.  I've rebooted the virtual
> > machine multiple times, as well as gone through a couple of xl
> > destroy/create cycles.
> >
> > I only pass it through as a secondary card, as I have the IGD as the
> > primary on the host.  The machine is a DQ67SW with a Core i5.  This
> is
> > running xen-unstable (c/s 24465) on a 3.2.1 dom0, with no extra
> patches.
> >
> > I haven't, however, had any luck passing through the IGD to anything
> > other than a Windows XP, and that includes running the latest
> qemu-xen
> > with Jean's patches (opregion, host bridge config space mapping).
> I've
> > been intending to start a separate thread for that...
> 
> 
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users
> 
> 

Re: [Xen-users] VGA passthough still not working

[Doug Magee]

On Tue, 2012-01-24 at 09:33 -0500, Likarpenkov Alexander wrote:

>  ??>> Anybody had luck with passing the card more than once to a
> guest? With
>  ??>> any random set of patches?
> ^^^^^^^^^^^^^^^^^^^^^^^^
> Better not to quote, than to do wrong quoting!!!
> Also see the question below/
> 
>  d> Yes, I've had a machine running for a couple of weeks, hosting a
> Windows
>  d> 7 domu with a passed-through Radeon 4770.  I've rebooted the
> virtual
>  d> machine multiple times, as well as gone through a couple of xl
>  d> destroy/create cycles.
> 
>  d> I only pass it through as a secondary card, as I have the IGD as
> the
>  d> primary on the host.  The machine is a DQ67SW with a Core i5.
> This is
>  d> running xen-unstable (c/s 24465) on a 3.2.1 dom0, with no extra
> patches.
> 
>  d> I haven't, however, had any luck passing through the IGD to
> anything
>  d> other than a Windows XP, and that includes running the latest
> qemu-xen
>  d> with Jean's patches (opregion, host bridge config space mapping).
> I've
>  d> been intending to start a separate thread for that...
> 
> Can you put a youtube video start DomU after
> # Xm create
> ???

I use the xl toolstack, not xm.  I don't think xm is being actively
maintained, at least not for current releases.

I don't know what a video could show you.  In the ATI case, there's no
signal until Windows loads the drivers.  It automatically disables the
emulated adapter, so i can watch the BIOS and Windows loading screens
via VNC, then my desktop appears on the monitor and the VNC console goes
black.

In the IGD case, i can see the output from ROMBIOS and the windows
loader (or grub2) on the monitor.  If i'm booting a XP domU, the windows
login screen then appears.  If i'm booting a Win7 domU, the screen goes
black.  If i'm booting a fedora16 domu, the signal vanishes entirely.
In the Win7 case, the domU seems to be stuck in a loop.  In the Fedora
case, i can ssh to the machine and see various WARN_ON dumps in dmesg
related to the i915 driver, and eventually, a message saying it failed
to reset the adapter.

I think that gives you more detail than any video i could post.

> 
> 
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users
> 
> 

Re: [Xen-devel] VGA passthough still not working

[Likarpenkov Alexander]

Здравствуйте!

Во вторник, двадцать четвертого января 2012 года, в 20:41:38 Вы писали:
 DM> I use the xl toolstack, not xm.  I don't think xm is being actively
 DM> maintained, at least not for current releases.

You can in a nutshell what better xl xm?

 DM> I don't know what a video could show you.  In the ATI case, there's no
 DM> signal until Windows loads the drivers.  It automatically disables the
 DM> emulated adapter, so i can watch the BIOS and Windows loading screens
 DM> via VNC, then my desktop appears on the monitor and the VNC console
 DM> goes black.

I say that ATI produces the same effect. I do not see anything until the 
welcome screen and only when gfx_passthru = 0. If gfx_passthru = 1 - qemu 
shell on vnc console and freezed domU :(

 DM> In the IGD case, i can see the output from ROMBIOS and the windows
 DM> loader (or grub2) on the monitor.  If i'm booting a XP domU, the
 DM> windows login screen then appears.  If i'm booting a Win7 domU, the
 DM> screen goes black.  If i'm booting a fedora16 domu, the signal vanishes
 DM> entirely. In the Win7 case, the domU seems to be stuck in a loop.  In
 DM> the Fedora case, i can ssh to the machine and see various WARN_ON dumps
 DM> in dmesg related to the i915 driver, and eventually, a message saying
 DM> it failed to reset the adapter.

 DM> I think that gives you more detail than any video i could post.

Yes, your post is really better video


_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Re: [Xen-users] VGA passthough still not working

[Tobias Geiger]

Hello Doug!

see below ....


Am Dienstag, 24. Januar 2012, 19:31:45 schrieb Doug Magee:
> On Tue, 2012-01-24 at 09:37 -0500, Tobias Geiger wrote:
> > > > > Both setup have the "flaw" that they only work once - meaning
> > 
> > you
> > 
> > > > can't reboot
> > > > 
> > > > > your DomU , cause after the reboot the passed-through Card
> > 
> > doesnt
> > 
> > > > have correct
> > > > 
> > > > > 3D-Accelleration any more (was/is the case with NVIDIA and ATI,
> > > > 
> > > > Windows XP and
> > > > 
> > > > > Windows7 )
> > > > 
> > > > For me it was with ATI with Windows7. Hadn't tried other OSes.
> > > > 
> > > > Anybody had luck with passing the card more than once to a guest?
> > 
> > With
> > 
> > > > any random set of patches?
> > 
> > I was a bit un-percice regarding the "reboot" issue:
> > 
> > The passing-through itself works even after a reboot of DomU - the
> > rebooted
> > System spits out its Graphics normaly through the passed-through Card
> > (NVIDA
> > or ATI doesnt matter here) ; BUT:
> > After a reboot it doesn't work properly. Meaning: Slow 3d Performance,
> > i.e.
> > unsable for real 3d apps, even a 3d Desktop;
> > For example, when the Card gives you 70fps in a Benchmark after a
> > fresh Cold
> > Boot, it only gives you 5-10fps after a reboot, this will be that low
> > until
> > you reboot Dom0 also, not only DomU;
> > 
> > hopefully i described the scenario better now...
> 
> Ah, got it.  I hadn't been doing anything 3D intensive, only running the
> Aero desktop.  I installed 3DMark Vantage and ran a couple of tests.  I
> get the same results (within a fraction of a %) after a cold boot as i
> do after rebooting multiple times, and always very close to native.  It
> seems i don't have the problem you're having.
> 
> Do you get any different log messages after a reboot (xl dmesg, dom0
> dmesg, qemu log)?  Have you tried with iommu=verbose to see if there's
> any more useful information there?
> 

Cool. Finally someone NOT suffering the reboot-performance-regression-Problem 
:)

I searched back and forth, rebooted DomU like crazy, diff'ed the 
dmesg/xldmesg/qemu-dm - but no difference :(

What kind of ATI Card are you passing through? 


Would be nice to find out whats causing this...

Greetings!
Tobias


> > > Yes, I've had a machine running for a couple of weeks, hosting a
> > 
> > Windows
> > 
> > > 7 domu with a passed-through Radeon 4770.  I've rebooted the virtual
> > > machine multiple times, as well as gone through a couple of xl
> > > destroy/create cycles.
> > > 
> > > I only pass it through as a secondary card, as I have the IGD as the
> > > primary on the host.  The machine is a DQ67SW with a Core i5.  This
> > 
> > is
> > 
> > > running xen-unstable (c/s 24465) on a 3.2.1 dom0, with no extra
> > 
> > patches.
> > 
> > > I haven't, however, had any luck passing through the IGD to anything
> > > other than a Windows XP, and that includes running the latest
> > 
> > qemu-xen
> > 
> > > with Jean's patches (opregion, host bridge config space mapping).
> > 
> > I've
> > 
> > > been intending to start a separate thread for that...
> > 
> > _______________________________________________
> > Xen-users mailing list
> > Xen-users@lists.xensource.com
> > http://lists.xensource.com/xen-users

Re: [Xen-users] VGA passthough still not working

[Doug Magee]

On Wed, 2012-01-25 at 03:26 -0500, Likarpenkov Alexander wrote:
> Здравствуйте!
> 
> Во вторник, двадцать четвертого января 2012 года, в 20:41:38 Вы
> писали:
>  DM> I use the xl toolstack, not xm.  I don't think xm is being
> actively
>  DM> maintained, at least not for current releases.
> 
> You can in a nutshell what better xl xm?

I'm not the person who can give you the most thorough response, however,
I can tell you what i know.  Xl is lighter-weight (C vs python, among
other structural differences).  Xl is the only 'suuported' toolstack
going forward, and xend/xm is no longer being maintained.  AFAICT, xl is
near feature parity with xend/xm in the current unstable.

Xl is the way to go if you're working on xen-unstable.

I imagine users on 4.1.x are encouraged to use it, but certain features
(such as recognizing and passing gfx_passthru flag to qemu) may or may
not be implemented in older versions, so for your testing, you may have
to use xm for some commands if you're building an older Xen.

If anyone can clear that up/correct any innacuracies, please jump in.
There should probably be a wiki page on this if there isn't already one.
Looked just now, and the only relevant info seems to be here:
http://wiki.xen.org/wiki/Migration_Guide_To_Xen4.1%2B

> 
>  DM> I don't know what a video could show you.  In the ATI case,
> there's no
>  DM> signal until Windows loads the drivers.  It automatically
> disables the
>  DM> emulated adapter, so i can watch the BIOS and Windows loading
> screens
>  DM> via VNC, then my desktop appears on the monitor and the VNC
> console
>  DM> goes black.
> 
> I say that ATI produces the same effect. I do not see anything until
> the
> welcome screen and only when gfx_passthru = 0. If gfx_passthru = 1 -
> qemu
> shell on vnc console and freezed domU :(

You won't be able to passthrough an ATI card with the BIOS for multiple
reasons.  First, the ati bios keeps a copy of the pci config space, so
certain values need to be modified for it to work properly with the
guest addresses.  The most recent experimental patch for this was from
december 2010:
http://lists.xen.org/archives/html/xen-devel/2010-12/msg00705.html
I can confirmm i had limited success with this.

However, this patch was based on xen-unstable before the 4.1-rc's came
out.  You can try building an older version of xen (in that thread, i
mentioned the specific C/S i used in testing) and applying the patch or
forward porting the patch to the current xen/qemu-xen.

Also, i believe you said the card you're trying to pass through is not
the primary card in your host system.  If that's the case, don't use
gfx_passthru or expect to get the video bios working.  The 'primary'
video adapter owns certain io ports and memory areas that are consitent
from machine to machine.  Also, the system will copy the vbios from the
card to a location in memory (0xc0000) so it can execute at boot time. 

Xen's gfx_passthru code depends on all of these factors.  As the code
stands, if you use gfx_passthru on a secondary card, it will still copy
the vbios from the primary card (as it simply reads memory from
0xc0000), and directly map io ports and low memory areas to those used
by the primary card in the host system.  In this case the guest will
almost certainly never get past executing ROMBIOS, and the host may or
may not lock up or experience 'issues'.

> 
>  DM> In the IGD case, i can see the output from ROMBIOS and the
> windows
>  DM> loader (or grub2) on the monitor.  If i'm booting a XP domU, the
>  DM> windows login screen then appears.  If i'm booting a Win7 domU,
> the
>  DM> screen goes black.  If i'm booting a fedora16 domu, the signal
> vanishes
>  DM> entirely. In the Win7 case, the domU seems to be stuck in a loop.
> In
>  DM> the Fedora case, i can ssh to the machine and see various WARN_ON
> dumps
>  DM> in dmesg related to the i915 driver, and eventually, a message
> saying
>  DM> it failed to reset the adapter.
> 
>  DM> I think that gives you more detail than any video i could post.
> 
> Yes, your post is really better video
> 
> 
> 



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

Future of xend and xl (Was: Re: [Xen-users] VGA passthough still not working)

[Ian Campbell]

On Wed, 2012-01-25 at 08:26 +0000, Likarpenkov Alexander wrote:
> Здравствуйте!
> 
> Во вторник, двадцать четвертого января 2012 года, в 20:41:38 Вы писали:
>  DM> I use the xl toolstack, not xm.  I don't think xm is being actively
>  DM> maintained, at least not for current releases.
> 
> You can in a nutshell what better xl xm?

xm (and the underlying xend daemon) have been effectively unmaintained
since Xen 3.4 or perhaps even earlier (we take band-aids and obvious
fixups but no proper maintenance has been occurring).

In the opinion of the core developers xend is unmaintainable and so we
have chosen to focus our efforts on libxl (a library designed to provide
a common "bottom third" for any Xen toolstack) and the xl toolstack that
is built using it. libxl is also supported by libvirt and there are
plans for xapi (the XCP toolstack) to use it as well.

This was announced in the Xen 4.1 release notes[1] and the upgrade
guide[2]. In Xen 4.2 we have ended up formally deprecating xend rather
than removing it but you should expect that xend will be removed in a
future release of Xen and begin planning your transition to xl (or one
of the other alternative toolstacks), testing the features which matter
to you and reporting bugs/submitting patches as appropriate.

However if someone (or a team of someones) were to step up and begin to
properly maintain xend we would have no objections and would be
supportive of that effort. We would strongly recommend that anyone who
wants to do this considers porting xend to libxl as one of their first
activities. Initial Python bindings for libxl do exist, but in the
absence of a xend port they have not seen significant use.

Ian.

[1] http://wiki.xen.org/xenwiki/Xen4.1
[2] http://wiki.xen.org/wiki/Migration_Guide_To_Xen4.1+


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

Re: [Xen-users] VGA passthough still not working

[Doug Magee]

On Wed, 2012-01-25 at 04:39 -0500, Tobias Geiger wrote:
> Hello Doug!
> 
> see below ....
> 
> 
> Am Dienstag, 24. Januar 2012, 19:31:45 schrieb Doug Magee:
> > On Tue, 2012-01-24 at 09:37 -0500, Tobias Geiger wrote:
> > > > > > Both setup have the "flaw" that they only work once -
> meaning
> > >
> > > you
> > >
> > > > > can't reboot
> > > > >
> > > > > > your DomU , cause after the reboot the passed-through Card
> > >
> > > doesnt
> > >
> > > > > have correct
> > > > >
> > > > > > 3D-Accelleration any more (was/is the case with NVIDIA and
> ATI,
> > > > >
> > > > > Windows XP and
> > > > >
> > > > > > Windows7 )
> > > > >
> > > > > For me it was with ATI with Windows7. Hadn't tried other OSes.
> > > > >
> > > > > Anybody had luck with passing the card more than once to a
> guest?
> > >
> > > With
> > >
> > > > > any random set of patches?
> > >
> > > I was a bit un-percice regarding the "reboot" issue:
> > >
> > > The passing-through itself works even after a reboot of DomU - the
> > > rebooted
> > > System spits out its Graphics normaly through the passed-through
> Card
> > > (NVIDA
> > > or ATI doesnt matter here) ; BUT:
> > > After a reboot it doesn't work properly. Meaning: Slow 3d
> Performance,
> > > i.e.
> > > unsable for real 3d apps, even a 3d Desktop;
> > > For example, when the Card gives you 70fps in a Benchmark after a
> > > fresh Cold
> > > Boot, it only gives you 5-10fps after a reboot, this will be that
> low
> > > until
> > > you reboot Dom0 also, not only DomU;
> > >
> > > hopefully i described the scenario better now...
> >
> > Ah, got it.  I hadn't been doing anything 3D intensive, only running
> the
> > Aero desktop.  I installed 3DMark Vantage and ran a couple of tests.
> I
> > get the same results (within a fraction of a %) after a cold boot as
> i
> > do after rebooting multiple times, and always very close to native.
> It
> > seems i don't have the problem you're having.
> >
> > Do you get any different log messages after a reboot (xl dmesg, dom0
> > dmesg, qemu log)?  Have you tried with iommu=verbose to see if
> there's
> > any more useful information there?
> >
> 
> Cool. Finally someone NOT suffering the
> reboot-performance-regression-Problem
> :)
> 
> I searched back and forth, rebooted DomU like crazy, diff'ed the
> dmesg/xldmesg/qemu-dm - but no difference :(
> 
> What kind of ATI Card are you passing through?

It's an HIS incarnation of the Radeon 4770. lspci -vvv output at the
bottom of the message.

> 
> 
> Would be nice to find out whats causing this...

Does your device/bus support FLR?  Do you get any messages like the
following when you use xl create/xl pci-attach?

libxl: error: libxl_pci.c:... The kernel doesn't support reset from
sysfs for PCI device ...

> 
> Greetings!
> Tobias

01:00.0 VGA compatible controller: ATI Technologies Inc Radeon HD 4770
[RV740] (prog-if 00 [VGA controller])
	Subsystem: ATI Technologies Inc Device 0d00
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 16
	Region 0: Memory at d0000000 (64-bit, prefetchable) [size=256M]
	Region 2: Memory at fbb20000 (64-bit, non-prefetchable) [size=64K]
	Region 4: I/O ports at e000 [size=256]
	Expansion ROM at fbb00000 [disabled] [size=128K]
	Capabilities: [50] Power Management version 3
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [58] Express (v2) Legacy Endpoint, MSI 00
		DevCap:	MaxPayload 128 bytes, PhantFunc 0, Latency L0s <4us, L1
unlimited
			ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd- ExtTag+ PhantFunc- AuxPwr- NoSnoop+
			MaxPayload 128 bytes, MaxReadReq 128 bytes
		DevSta:	CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
		LnkCap:	Port #0, Speed 5GT/s, Width x16, ASPM L0s L1, Latency L0
<64ns, L1 <1us
			ClockPM- Surprise- LLActRep- BwNot-
		LnkCtl:	ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 5GT/s, Width x16, TrErr- Train- SlotClk+ DLActive-
BWMgmt- ABWMgmt-
		DevCap2: Completion Timeout: Not Supported, TimeoutDis-
		DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-
		LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-,
Selectable De-emphasis: -6dB
			 Transmit Margin: Normal Operating Range, EnterModifiedCompliance-
ComplianceSOS-
			 Compliance De-emphasis: -6dB
		LnkSta2: Current De-emphasis Level: -6dB
	Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
		Address: 00000000fee00438  Data: 0000
	Capabilities: [100 v1] Vendor Specific Information: ID=0001 Rev=1
Len=010 <?>
	Kernel driver in use: pciback
	Kernel modules: radeon

Re: [Xen-users] VGA passthough still not working

[Pavel Matěja]

On Wed 25. of January 2012 17:52:11 Doug Magee wrote:
> Also, i believe you said the card you're trying to pass through is not
> the primary card in your host system.  If that's the case, don't use
> gfx_passthru or expect to get the video bios working.  The 'primary'
> video adapter owns certain io ports and memory areas that are consitent
> from machine to machine.  Also, the system will copy the vbios from the
> card to a location in memory (0xc0000) so it can execute at boot time.
> 
> Xen's gfx_passthru code depends on all of these factors.  As the code
> stands, if you use gfx_passthru on a secondary card, it will still copy
> the vbios from the primary card (as it simply reads memory from
> 0xc0000), and directly map io ports and low memory areas to those used
> by the primary card in the host system.  In this case the guest will
> almost certainly never get past executing ROMBIOS, and the host may or
> may not lock up or experience 'issues'.

This will do the trick with secondary card (replace path to VGA BIOS):

--- xen-unstable.hg.working/tools/ioemu-remote/hw/pt-graphics.c 2012-01-25 
20:26:37.927654890 +0100
+++ xen-unstable.hg.working.generic/tools/ioemu-remote/hw/pt-graphics.c 
2011-07-30 13:57:57.347396095 +0200
@@ -487,10 +487,10 @@
 {
     int fd;
     uint32_t bios_size = 0;
-    uint32_t start = 0;
+    uint32_t start = 0xC0000;
     uint16_t magic = 0;
 
-    if ( (fd = open("/lib/firmware/ASUS.HD6850.1024.101007.bin", O_RDONLY)) < 
0 )
+    if ( (fd = open("/dev/mem", O_RDONLY)) < 0 )
     {
         PT_LOG("Error: Can't open /dev/mem: %s\n", strerror(errno));
         return 0;
-- 
Pavel Mateja

Re: [Xen-users] Future of xend and xl (Was: Re: VGA passthough still not working)

[Florian Heigl]

Hi Ian and all,

2012/1/25 Ian Campbell <Ian.Campbell@citrix.com>:
> On Wed, 2012-01-25 at 08:26 +0000, Likarpenkov Alexander wrote:
>> Здравствуйте!
>>
>> Во вторник, двадцать четвертого января 2012 года, в 20:41:38 Вы писали:
>>  DM> I use the xl toolstack, not xm.  I don't think xm is being actively
>>  DM> maintained, at least not for current releases.
>>
>> You can in a nutshell what better xl xm?
>
> xm (and the underlying xend daemon) have been effectively unmaintained
> since Xen 3.4 or perhaps even earlier (we take band-aids and obvious
> fixups but no proper maintenance has been occurring).

thats not an advantage of xl imho.
xm / xend being an unstable mess and xl being blazingly fast is one.

> In the opinion of the core developers xend is unmaintainable and so we
> have chosen to focus our efforts on libxl (a library designed to provide
> a common "bottom third" for any Xen toolstack) and the xl toolstack that
> is built using it. libxl is also supported by libvirt and there are
> plans for xapi (the XCP toolstack) to use it as well.

this is another piece of un-maintained-ness?
libvirt + xend just went away because nobody even complained when
libvirt suddenly defaulted to not build xen support. Ok, probably
because most Xen users don't need a gui tool to start their VMs :)

> This was announced in the Xen 4.1 release notes[1] and the upgrade
> guide[2]. In Xen 4.2 we have ended up formally deprecating xend rather
> than removing it but you should expect that xend will be removed in a
> future release of Xen and begin planning your transition to xl (or one
> of the other alternative toolstacks), testing the features which matter
> to you and reporting bugs/submitting patches as appropriate.

I think it would be a nice move if this wasn't just left to us users,
especially since it is a process of suddenly finding missing parts or
large changes in functionality in something like an easter egg hunt.

How about if we assemble a list of Xen features in xm/xend and those
that you have implemented in xl. Right now it's just guesswork and a
lot double effort since one doesn't just have to track which parts are
gone, but we even have to constantly read all threads on the lists to
find out if a feature is suddenly coming back or being deprecated.

i.e. take something like Remus that had officially become a part of
Xen some time back but isn't possible to use with PV domUs with any
reasonable amount of effort. And not by formal decision, after a
"heads up" mail, but just by chance. A few months I was still thinking
I would be able to use it in a hosting product but "whoops" not
working anymore.

Back to xl:
Probably noone really objects removing xm by now since it's not really
working anymore once the system has xl support and the two are not
compatible. It has to be in everyones interest that there is no
unneeded code to maintain and that the core devs LIKE that code and
that people can rely on it being maintained for the years to come.
It doesn't matter if we type 'xl' or 'xm', it has to *work* :)

But maybe we can have a somewhat reliable roadmap where one can see xm
will be kicked in 4.4 *and* we're planning to have the following 1234
features supported by then.
That way interested parties have a chance to put ressources into
getting missing features "back in" and other projects know how much
time they have to clean up their code. I.e. cobbler/koan is suddenly
broken after 4 years and people can't install domUs anymore. :)

Greetings,
Florian

p.s.: I am aware I will have to make up for this mail in beer once
there is an opportunity.

-- 
the purpose of libvirt is to provide an abstraction layer hiding all
xen features added since 2006 until they were finally understood and
copied by the kvm devs.

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

Re: [Xen-users] VGA passthough still not working

[Pavel Matěja]

On Wed 25. of January 2012 20:29:12 Pavel Matěja wrote:
> On Wed 25. of January 2012 17:52:11 Doug Magee wrote:
> > Also, i believe you said the card you're trying to pass through is not
> > the primary card in your host system.  If that's the case, don't use
> > gfx_passthru or expect to get the video bios working.  The 'primary'
> > video adapter owns certain io ports and memory areas that are consitent
> > from machine to machine.  Also, the system will copy the vbios from the
> > card to a location in memory (0xc0000) so it can execute at boot time.
> > 
> > Xen's gfx_passthru code depends on all of these factors.  As the code
> > stands, if you use gfx_passthru on a secondary card, it will still copy
> > the vbios from the primary card (as it simply reads memory from
> > 0xc0000), and directly map io ports and low memory areas to those used
> > by the primary card in the host system.  In this case the guest will
> > almost certainly never get past executing ROMBIOS, and the host may or
> > may not lock up or experience 'issues'.
> 
> This will do the trick with secondary card (replace path to VGA BIOS):
> 
> --- xen-unstable.hg.working/tools/ioemu-remote/hw/pt-graphics.c 2012-01-25
> 20:26:37.927654890 +0100
> +++ xen-unstable.hg.working.generic/tools/ioemu-remote/hw/pt-graphics.c
> 2011-07-30 13:57:57.347396095 +0200
> @@ -487,10 +487,10 @@
>  {
>      int fd;
>      uint32_t bios_size = 0;
> -    uint32_t start = 0;
> +    uint32_t start = 0xC0000;
>      uint16_t magic = 0;
> 
> -    if ( (fd = open("/lib/firmware/ASUS.HD6850.1024.101007.bin",
> O_RDONLY)) < 0 )
> +    if ( (fd = open("/dev/mem", O_RDONLY)) < 0 )
>      {
>          PT_LOG("Error: Can't open /dev/mem: %s\n", strerror(errno));
>          return 0;

Sorry, switch the + and -.
-- 
Pavel Mateja

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

Re: [Xen-users] VGA passthough still not working

[Doug Magee]

On Wed, 2012-01-25 at 20:52 +0100, Pavel Matěja wrote:
> On Wed 25. of January 2012 20:29:12 Pavel Matěja wrote:
> > On Wed 25. of January 2012 17:52:11 Doug Magee wrote:
> > > Also, i believe you said the card you're trying to pass through is not
> > > the primary card in your host system.  If that's the case, don't use
> > > gfx_passthru or expect to get the video bios working.  The 'primary'
> > > video adapter owns certain io ports and memory areas that are consitent
> > > from machine to machine.  Also, the system will copy the vbios from the
> > > card to a location in memory (0xc0000) so it can execute at boot time.
> > > 
> > > Xen's gfx_passthru code depends on all of these factors.  As the code
> > > stands, if you use gfx_passthru on a secondary card, it will still copy
> > > the vbios from the primary card (as it simply reads memory from
> > > 0xc0000), and directly map io ports and low memory areas to those used
> > > by the primary card in the host system.  In this case the guest will
> > > almost certainly never get past executing ROMBIOS, and the host may or
> > > may not lock up or experience 'issues'.
> > 
> > This will do the trick with secondary card (replace path to VGA BIOS):
> > 
> > --- xen-unstable.hg.working/tools/ioemu-remote/hw/pt-graphics.c 2012-01-25
> > 20:26:37.927654890 +0100
> > +++ xen-unstable.hg.working.generic/tools/ioemu-remote/hw/pt-graphics.c
> > 2011-07-30 13:57:57.347396095 +0200
> > @@ -487,10 +487,10 @@
> >  {
> >      int fd;
> >      uint32_t bios_size = 0;
> > -    uint32_t start = 0;
> > +    uint32_t start = 0xC0000;
> >      uint16_t magic = 0;
> > 
> > -    if ( (fd = open("/lib/firmware/ASUS.HD6850.1024.101007.bin",
> > O_RDONLY)) < 0 )
> > +    if ( (fd = open("/dev/mem", O_RDONLY)) < 0 )
> >      {
> >          PT_LOG("Error: Can't open /dev/mem: %s\n", strerror(errno));
> >          return 0;
> 
> Sorry, switch the + and -.

This will load the proper BIOS, but it seems this wouldn't be enough.
In hw/pt-graphics.c:register_vga_regions(), we map 1:1 ioports
0x3b0-0x3bb, 0x3c0-0x3df, and memory at 0xa0000-0xbffff.

If i understand this correctly, these ioports and memory areas are bound
to the primary video adapter in the host on boot by the BIOS, depending
on what device you've selected in the BIOS setup screen to be your
primary adapter.  Therefore, you could load the proper bios, but it
would still write to memory and io ports that are bound to the primary
card in the host, not the card being passed through to the guest.

Does this make sense? (Or, am i nuts?)



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

Re: [Xen-users] VGA passthough still not working

[Pavel Matěja]

On Wed 25. of January 2012 21:29:13 you wrote:
> On Wed, 2012-01-25 at 20:52 +0100, Pavel Matěja wrote:
> > On Wed 25. of January 2012 20:29:12 Pavel Matěja wrote:
> > > On Wed 25. of January 2012 17:52:11 Doug Magee wrote:
> > > > Also, i believe you said the card you're trying to pass through is
> > > > not the primary card in your host system.  If that's the case, don't
> > > > use gfx_passthru or expect to get the video bios working.  The
> > > > 'primary' video adapter owns certain io ports and memory areas that
> > > > are consitent from machine to machine.  Also, the system will copy
> > > > the vbios from the card to a location in memory (0xc0000) so it can
> > > > execute at boot time.
> > > > 
> > > > Xen's gfx_passthru code depends on all of these factors.  As the code
> > > > stands, if you use gfx_passthru on a secondary card, it will still
> > > > copy the vbios from the primary card (as it simply reads memory from
> > > > 0xc0000), and directly map io ports and low memory areas to those
> > > > used by the primary card in the host system.  In this case the guest
> > > > will almost certainly never get past executing ROMBIOS, and the host
> > > > may or may not lock up or experience 'issues'.
> > > 
> > > This will do the trick with secondary card (replace path to VGA BIOS):
> > > 
> > > --- xen-unstable.hg.working/tools/ioemu-remote/hw/pt-graphics.c
> > > 2012-01-25 20:26:37.927654890 +0100
> > > +++ xen-unstable.hg.working.generic/tools/ioemu-remote/hw/pt-graphics.c
> > > 2011-07-30 13:57:57.347396095 +0200
> > > @@ -487,10 +487,10 @@
> > > 
> > >  {
> > >  
> > >      int fd;
> > >      uint32_t bios_size = 0;
> > > 
> > > -    uint32_t start = 0;
> > > +    uint32_t start = 0xC0000;
> > > 
> > >      uint16_t magic = 0;
> > > 
> > > -    if ( (fd = open("/lib/firmware/ASUS.HD6850.1024.101007.bin",
> > > O_RDONLY)) < 0 )
> > > +    if ( (fd = open("/dev/mem", O_RDONLY)) < 0 )
> > > 
> > >      {
> > >      
> > >          PT_LOG("Error: Can't open /dev/mem: %s\n", strerror(errno));
> > >          return 0;
> > 
> > Sorry, switch the + and -.
> 
> This will load the proper BIOS, but it seems this wouldn't be enough.
> In hw/pt-graphics.c:register_vga_regions(), we map 1:1 ioports
> 0x3b0-0x3bb, 0x3c0-0x3df, and memory at 0xa0000-0xbffff.
> 
> If i understand this correctly, these ioports and memory areas are bound
> to the primary video adapter in the host on boot by the BIOS, depending
> on what device you've selected in the BIOS setup screen to be your
> primary adapter.  Therefore, you could load the proper bios, but it
> would still write to memory and io ports that are bound to the primary
> card in the host, not the card being passed through to the guest.
> 
> Does this make sense? (Or, am i nuts?)

It makes sense and it's quite complicated.
Primary card is "bound" to those ports by PCI bridge. When you access legacy 
IO port the PCI will examine all bridges looking for VGA Enable bit in the 
Bridge Control register and pass the call to such such bridge. So there should 
be linux syscall to vgaarb before and after each ioport access which will set 
and unset the bit for right card's bridge.
But this setup works anyway! Windows driver doesn't access ioports. Just VGA 
BIOS does. It means loading the BIOS will mess image on primary card.
In the end I'm able to boot three virtual machines all with passed (AMD) VGA.
-- 
Pavel Mateja

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

Re: [Xen-users] VGA passthough still not working

[Pavel Matěja]

On Wed 25. of January 2012 21:29:13 Doug Magee wrote:
> On Wed, 2012-01-25 at 20:52 +0100, Pavel Matěja wrote:
> > On Wed 25. of January 2012 20:29:12 Pavel Matěja wrote:
> > > On Wed 25. of January 2012 17:52:11 Doug Magee wrote:
> > > > Also, i believe you said the card you're trying to pass through is
> > > > not the primary card in your host system.  If that's the case, don't
> > > > use gfx_passthru or expect to get the video bios working.  The
> > > > 'primary' video adapter owns certain io ports and memory areas that
> > > > are consitent from machine to machine.  Also, the system will copy
> > > > the vbios from the card to a location in memory (0xc0000) so it can
> > > > execute at boot time.
> > > > 
> > > > Xen's gfx_passthru code depends on all of these factors.  As the code
> > > > stands, if you use gfx_passthru on a secondary card, it will still
> > > > copy the vbios from the primary card (as it simply reads memory from
> > > > 0xc0000), and directly map io ports and low memory areas to those
> > > > used by the primary card in the host system.  In this case the guest
> > > > will almost certainly never get past executing ROMBIOS, and the host
> > > > may or may not lock up or experience 'issues'.
> > > 
> > > This will do the trick with secondary card (replace path to VGA BIOS):
> > > 
> > > --- xen-unstable.hg.working/tools/ioemu-remote/hw/pt-graphics.c
> > > 2012-01-25 20:26:37.927654890 +0100
> > > +++ xen-unstable.hg.working.generic/tools/ioemu-remote/hw/pt-graphics.c
> > > 2011-07-30 13:57:57.347396095 +0200
> > > @@ -487,10 +487,10 @@
> > > 
> > >  {
> > >  
> > >      int fd;
> > >      uint32_t bios_size = 0;
> > > 
> > > -    uint32_t start = 0;
> > > +    uint32_t start = 0xC0000;
> > > 
> > >      uint16_t magic = 0;
> > > 
> > > -    if ( (fd = open("/lib/firmware/ASUS.HD6850.1024.101007.bin",
> > > O_RDONLY)) < 0 )
> > > +    if ( (fd = open("/dev/mem", O_RDONLY)) < 0 )
> > > 
> > >      {
> > >      
> > >          PT_LOG("Error: Can't open /dev/mem: %s\n", strerror(errno));
> > >          return 0;
> > 
> > Sorry, switch the + and -.
> 
> This will load the proper BIOS, but it seems this wouldn't be enough.
> In hw/pt-graphics.c:register_vga_regions(), we map 1:1 ioports
> 0x3b0-0x3bb, 0x3c0-0x3df, and memory at 0xa0000-0xbffff.
> 
> If i understand this correctly, these ioports and memory areas are bound
> to the primary video adapter in the host on boot by the BIOS, depending
> on what device you've selected in the BIOS setup screen to be your
> primary adapter.  Therefore, you could load the proper bios, but it
> would still write to memory and io ports that are bound to the primary
> card in the host, not the card being passed through to the guest.
> 
> Does this make sense? (Or, am i nuts?)

To save you some time:

Linux VGA arbiter:
http://lwn.net/Articles/346404/

PCI specification:
4.5.1. VGA Compatible Addressing
The VGA Enable bit in the Bridge Control register is used to control response 
by the bridge to both the VGA frame buffer addresses and to the VGA register 
addresses. If a VGA compatible device is located downstream of a bridge, the 
VGA Enable bit must be set. If the VGA Enable bit is set, the bridge will 
positively decode and forward memory accesses to VGA frame buffer
addresses and I/O accesses to VGA registers from the primary interface to the 
secondary interface (and block forwarding from the secondary to primary 
interface of these same accesses). A bridge never forwards transactions that 
access VGA BIOS memory addresses (regardless of the setting of the VGA Enable 
bit). ROM code provided by PCI compatible devices must be copied to system 
memory before execution and may be mapped to any address in PCI memory
address space via the Expansion ROM Base Address register in the device’s 
configuration header.
VGA memory addresses
•
0A 0000h through 0B FFFFh
VGA I/O addresses (including ISA aliases - AD[15::10] are not decoded)
•
AD[9::0] = 3B0h through 3BBh, and 3C0h through 3DFh
-- 
Pavel Mateja

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

Re: [Xen-users] VGA passthough still not working

[Doug Magee]

On Wed, 2012-01-25 at 21:48 +0100, Pavel Matěja wrote:
> On Wed 25. of January 2012 21:29:13 you wrote:
> > On Wed, 2012-01-25 at 20:52 +0100, Pavel Matěja wrote:
> > > On Wed 25. of January 2012 20:29:12 Pavel Matěja wrote:
> > > > On Wed 25. of January 2012 17:52:11 Doug Magee wrote:
> > > > > Also, i believe you said the card you're trying to pass through is
> > > > > not the primary card in your host system.  If that's the case, don't
> > > > > use gfx_passthru or expect to get the video bios working.  The
> > > > > 'primary' video adapter owns certain io ports and memory areas that
> > > > > are consitent from machine to machine.  Also, the system will copy
> > > > > the vbios from the card to a location in memory (0xc0000) so it can
> > > > > execute at boot time.
> > > > > 
> > > > > Xen's gfx_passthru code depends on all of these factors.  As the code
> > > > > stands, if you use gfx_passthru on a secondary card, it will still
> > > > > copy the vbios from the primary card (as it simply reads memory from
> > > > > 0xc0000), and directly map io ports and low memory areas to those
> > > > > used by the primary card in the host system.  In this case the guest
> > > > > will almost certainly never get past executing ROMBIOS, and the host
> > > > > may or may not lock up or experience 'issues'.
> > > > 
> > > > This will do the trick with secondary card (replace path to VGA BIOS):
> > > > 
> > > > --- xen-unstable.hg.working/tools/ioemu-remote/hw/pt-graphics.c
> > > > 2012-01-25 20:26:37.927654890 +0100
> > > > +++ xen-unstable.hg.working.generic/tools/ioemu-remote/hw/pt-graphics.c
> > > > 2011-07-30 13:57:57.347396095 +0200
> > > > @@ -487,10 +487,10 @@
> > > > 
> > > >  {
> > > >  
> > > >      int fd;
> > > >      uint32_t bios_size = 0;
> > > > 
> > > > -    uint32_t start = 0;
> > > > +    uint32_t start = 0xC0000;
> > > > 
> > > >      uint16_t magic = 0;
> > > > 
> > > > -    if ( (fd = open("/lib/firmware/ASUS.HD6850.1024.101007.bin",
> > > > O_RDONLY)) < 0 )
> > > > +    if ( (fd = open("/dev/mem", O_RDONLY)) < 0 )
> > > > 
> > > >      {
> > > >      
> > > >          PT_LOG("Error: Can't open /dev/mem: %s\n", strerror(errno));
> > > >          return 0;
> > > 
> > > Sorry, switch the + and -.
> > 
> > This will load the proper BIOS, but it seems this wouldn't be enough.
> > In hw/pt-graphics.c:register_vga_regions(), we map 1:1 ioports
> > 0x3b0-0x3bb, 0x3c0-0x3df, and memory at 0xa0000-0xbffff.
> > 
> > If i understand this correctly, these ioports and memory areas are bound
> > to the primary video adapter in the host on boot by the BIOS, depending
> > on what device you've selected in the BIOS setup screen to be your
> > primary adapter.  Therefore, you could load the proper bios, but it
> > would still write to memory and io ports that are bound to the primary
> > card in the host, not the card being passed through to the guest.
> > 
> > Does this make sense? (Or, am i nuts?)
> 
> It makes sense and it's quite complicated.
> Primary card is "bound" to those ports by PCI bridge. When you access legacy 
> IO port the PCI will examine all bridges looking for VGA Enable bit in the 
> Bridge Control register and pass the call to such such bridge. So there should 
> be linux syscall to vgaarb before and after each ioport access which will set 
> and unset the bit for right card's bridge.
> But this setup works anyway! Windows driver doesn't access ioports. Just VGA 
> BIOS does. It means loading the BIOS will mess image on primary card.
> In the end I'm able to boot three virtual machines all with passed (AMD) VGA.

Ah, ok, so in your case, the vBIOS doesn't actually work, and you don't
get any output until the OS drivers load?  But you need to load the
proper bios to guest memory anyway because the drivers depend on it?



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

Re: [Xen-users] VGA passthough still not working

[Pavel Mateja]

> On Wed, 2012-01-25 at 21:48 +0100, Pavel Matěja wrote:
> Ah, ok, so in your case, the vBIOS doesn't actually work, and you don't
> get any output until the OS drivers load?  But you need to load the
> proper bios to guest memory anyway because the drivers depend on it?

I do get the BIOS output. Just on wrong card.
;)

BTW: There is qemu-claim-vga-cycle-for-secondary-gfx-passthrough.patch:
http://lists.xensource.com/archives/html/xen-devel/2009-08/binfGEJAiR8ZA.bin
which does the VGA Enable bit things not using Linux vgaarb.
But I think the part with PCI_HOST_BRIDGE_IGD_VGA_DISABLE is for Intel 
chipset.
-- 
Pavel Mateja

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

Re: [Xen-devel] VGA passthough still not working

[Likarpenkov Alexander]

 ??>> I say that ATI produces the same effect. I do not see anything until
 ??>> the
 ??>> welcome screen and only when gfx_passthru = 0. If gfx_passthru = 1 -
 ??>> qemu
 ??>> shell on vnc console and freezed domU :(

 DM> You won't be able to passthrough an ATI card with the BIOS for multiple
 DM> reasons.  First, the ati bios keeps a copy of the pci config space, so
 DM> certain values need to be modified for it to work properly with the
 DM> guest addresses.  The most recent experimental patch for this was from
 DM> december 2010:
 DM> http://lists.xen.org/archives/html/xen-devel/2010-12/msg00705.html
 DM> I can confirmm i had limited success with this.


 DM> However, this patch was based on xen-unstable before the 4.1-rc's came
 DM> out.  You can try building an older version of xen (in that thread, i
 DM> mentioned the specific C/S i used in testing) and applying the patch or
 DM> forward porting the patch to the current xen/qemu-xen.

In fact of the matter is that it tested an older version of Xen, and I read 
about this in the beginning of its work with Xen (although there was a 
version 4.0.1rc3.) Out of my last comment^ 4.1.2 works more stable than 
4.0.2 4.0.1rc3
And how to roll the old patch to newer versions of xen?

 DM> Also, i believe you said the card you're trying to pass through is not
 DM> the primary card in your host system.  If that's the case, don't use
 DM> gfx_passthru or expect to get the video bios working.  The 'primary'
 DM> video adapter owns certain io ports and memory areas that are consitent
 DM> from machine to machine.  Also, the system will copy the vbios from the
 DM> card to a location in memory (0xc0000) so it can execute at boot time.

 DM> Xen's gfx_passthru code depends on all of these factors.  As the code
 DM> stands, if you use gfx_passthru on a secondary card, it will still copy
 DM> the vbios from the primary card (as it simply reads memory from
 DM> 0xc0000), and directly map io ports and low memory areas to those used
 DM> by the primary card in the host system.  In this case the guest will
 DM> almost certainly never get past executing ROMBIOS, and the host may or
 DM> may not lock up or experience 'issues'.

I use both. When the primary adapter is the one on which you want to run 
gfx_passthru - there remains the possibility to control the system through 
the console, not ssh. There is the following question: if I have a primary 
device that the video card, you want to passing, I need to do it pciback and 
add config DomU pci = ['02: 00.0 '], where '02: 00.0' - is the primary 
graphics card or no???

Re: [Xen-users] Future of xend and xl (Was: Re: VGA passthough still not working)

[Ian Campbell]

On Wed, 2012-01-25 at 19:43 +0000, Florian Heigl wrote:
> How about if we assemble a list of Xen features in xm/xend and those
> that you have implemented in xl. Right now it's just guesswork and a
> lot double effort since one doesn't just have to track which parts are
> gone, but we even have to constantly read all threads on the lists to
> find out if a feature is suddenly coming back or being deprecated.

I agree that a list of features which xl supports would be a useful
thing to have. I have just made a start on updating
http://wiki.xen.org/wiki/XL with such a list (as well as some more
highlevel blurb). Further contributions welcomed ;-)

However I don't think it will be feasible or useful to construct a list
of all the features of xm/xend, since there is no one around who knows
what they all are. Even if we did we would have to know which of them
were actually useful to users (some are obvious) and which would be a
wasted effort (which could be better spent elsewhere) to reimplement.

Therefore we chose to go straight to the horses mouth and ask users to
try xl and report which features that they actually use and require are
missing. IIRC we have been doing this since the early 4.1 rc's, have
continued to do so throughout the 4.2 development cycle and will no
doubt continue to to do so through the 4.3 release cycle, if not beyond.

Perhaps we need to be a bit more vocal to our users about the "report
missing features which you require" part of this.

I should note that we are not aiming for 100% feature parity between xl
and xend. As I discussed above some features of xend are unused and
there are others (the main one being managed domains) which we have
explicitly decided that xl will not support.

As with all Open Source software there is also an element of scratching
one's own itch here. We are trying to respond to user requests and as
the xl feature-set rounds out we will no doubt be considering more and
more "minority" features but there are only so many of us and only so
many hours in the day. So ultimately if you need or want a feature then
we are more than happy to accept new features which people feel are
valuable and to help with the work that might be necessary.

[...]

> But maybe we can have a somewhat reliable roadmap where one can see xm
> will be kicked in 4.4 *and* we're planning to have the following 1234
> features supported by then.
> That way interested parties have a chance to put ressources into
> getting missing features "back in" 

>From this point of view you should assume that xend has already gone and
put resources into this _now_, there is no reason to wait for some
arbitrary deadline.

Once we are satisfied that we have covered the necessary and desirable
use cases will we actually remove xend. It is very likely that this will
happen soon.

Even though xend is still in tree it is unmaintained and deprecated and
we strongly recommend that users switch to xl and give us feedback where
features are found to be lacking.

In contrast xl was production ready in 4.1 and will continue to gain
features in 4.2 and beyond.

[...]

> p.s.: I am aware I will have to make up for this mail in beer once
> there is an opportunity.

I will certainly take you up on that ;-)

Re: [Xen-users] VGA passthough still not working

[Tobias Geiger]

Hi,

yes, my Motherboard (DX58SO) announces "FLR Capability" - at least it's active 
in BIOS:

BIOS:
XD Technology <Enable>
Intel VT           <Enable>
Intel VT for Direct I/O (VT-d) <Enable>
Interrupt Remapping <Enable>
FLR Capability <Enable>

But lspci -vv shows for the ATI Card:
                        ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset-


OTOH your lspci also shows "FLReset-" - but DomU Reboots work for you, so this 
might not be the cause of my problem....


Until now (as you said its working in your setup) i thought it has something 
to do with the " FLR complication" , mainly "– Need to save/restore certain 
MMIO registers across FLR’s" -  Allen M. Kay mentions on Page 11 of this Slide 
here:
http://www.linux-kvm.org/wiki/images/b/be/2011-forum-%24graphics-direct-
assignment.pdf

But thats just a wild guess by me ...

Any other hints/thoughts on this?

Greetings!
Tobias


Am Mittwoch, 25. Januar 2012, 18:23:07 schrieb Doug Magee:
> On Wed, 2012-01-25 at 04:39 -0500, Tobias Geiger wrote:
> > Hello Doug!
> > 
> > see below ....
> > 
> > Am Dienstag, 24. Januar 2012, 19:31:45 schrieb Doug Magee:
> > > On Tue, 2012-01-24 at 09:37 -0500, Tobias Geiger wrote:
> > > > > > > Both setup have the "flaw" that they only work once -
> > 
> > meaning
> > 
> > > > you
> > > > 
> > > > > > can't reboot
> > > > > > 
> > > > > > > your DomU , cause after the reboot the passed-through Card
> > > > 
> > > > doesnt
> > > > 
> > > > > > have correct
> > > > > > 
> > > > > > > 3D-Accelleration any more (was/is the case with NVIDIA and
> > 
> > ATI,
> > 
> > > > > > Windows XP and
> > > > > > 
> > > > > > > Windows7 )
> > > > > > 
> > > > > > For me it was with ATI with Windows7. Hadn't tried other OSes.
> > > > > > 
> > > > > > Anybody had luck with passing the card more than once to a
> > 
> > guest?
> > 
> > > > With
> > > > 
> > > > > > any random set of patches?
> > > > 
> > > > I was a bit un-percice regarding the "reboot" issue:
> > > > 
> > > > The passing-through itself works even after a reboot of DomU - the
> > > > rebooted
> > > > System spits out its Graphics normaly through the passed-through
> > 
> > Card
> > 
> > > > (NVIDA
> > > > or ATI doesnt matter here) ; BUT:
> > > > After a reboot it doesn't work properly. Meaning: Slow 3d
> > 
> > Performance,
> > 
> > > > i.e.
> > > > unsable for real 3d apps, even a 3d Desktop;
> > > > For example, when the Card gives you 70fps in a Benchmark after a
> > > > fresh Cold
> > > > Boot, it only gives you 5-10fps after a reboot, this will be that
> > 
> > low
> > 
> > > > until
> > > > you reboot Dom0 also, not only DomU;
> > > > 
> > > > hopefully i described the scenario better now...
> > > 
> > > Ah, got it.  I hadn't been doing anything 3D intensive, only running
> > 
> > the
> > 
> > > Aero desktop.  I installed 3DMark Vantage and ran a couple of tests.
> > 
> > I
> > 
> > > get the same results (within a fraction of a %) after a cold boot as
> > 
> > i
> > 
> > > do after rebooting multiple times, and always very close to native.
> > 
> > It
> > 
> > > seems i don't have the problem you're having.
> > > 
> > > Do you get any different log messages after a reboot (xl dmesg, dom0
> > > dmesg, qemu log)?  Have you tried with iommu=verbose to see if
> > 
> > there's
> > 
> > > any more useful information there?
> > 
> > Cool. Finally someone NOT suffering the
> > reboot-performance-regression-Problem
> > 
> > :)
> > 
> > I searched back and forth, rebooted DomU like crazy, diff'ed the
> > dmesg/xldmesg/qemu-dm - but no difference :(
> > 
> > What kind of ATI Card are you passing through?
> 
> It's an HIS incarnation of the Radeon 4770. lspci -vvv output at the
> bottom of the message.
> 
> > Would be nice to find out whats causing this...
> 
> Does your device/bus support FLR?  Do you get any messages like the
> following when you use xl create/xl pci-attach?
> 
> libxl: error: libxl_pci.c:... The kernel doesn't support reset from
> sysfs for PCI device ...
> 
> > Greetings!
> > Tobias
> 
> 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon HD 4770
> [RV740] (prog-if 00 [VGA controller])
> 	Subsystem: ATI Technologies Inc Device 0d00
> 	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
> Stepping- SERR- FastB2B- DisINTx-
> 	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
> <MAbort- >SERR- <PERR- INTx-
> 	Latency: 0, Cache Line Size: 64 bytes
> 	Interrupt: pin A routed to IRQ 16
> 	Region 0: Memory at d0000000 (64-bit, prefetchable) [size=256M]
> 	Region 2: Memory at fbb20000 (64-bit, non-prefetchable) [size=64K]
> 	Region 4: I/O ports at e000 [size=256]
> 	Expansion ROM at fbb00000 [disabled] [size=128K]
> 	Capabilities: [50] Power Management version 3
> 		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
> PME(D0-,D1-,D2-,D3hot-,D3cold-)
> 		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
> 	Capabilities: [58] Express (v2) Legacy Endpoint, MSI 00
> 		DevCap:	MaxPayload 128 bytes, PhantFunc 0, Latency L0s <4us, L1
> unlimited
> 			ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
> 		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- 
Unsupported-
> 			RlxdOrd- ExtTag+ PhantFunc- AuxPwr- NoSnoop+
> 			MaxPayload 128 bytes, MaxReadReq 128 bytes
> 		DevSta:	CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- 
TransPend-
> 		LnkCap:	Port #0, Speed 5GT/s, Width x16, ASPM L0s L1, Latency L0
> <64ns, L1 <1us
> 			ClockPM- Surprise- LLActRep- BwNot-
> 		LnkCtl:	ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
> 			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
> 		LnkSta:	Speed 5GT/s, Width x16, TrErr- Train- SlotClk+ DLActive-
> BWMgmt- ABWMgmt-
> 		DevCap2: Completion Timeout: Not Supported, TimeoutDis-
> 		DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-
> 		LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-,
> Selectable De-emphasis: -6dB
> 			 Transmit Margin: Normal Operating Range, 
EnterModifiedCompliance-
> ComplianceSOS-
> 			 Compliance De-emphasis: -6dB
> 		LnkSta2: Current De-emphasis Level: -6dB
> 	Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
> 		Address: 00000000fee00438  Data: 0000
> 	Capabilities: [100 v1] Vendor Specific Information: ID=0001 Rev=1
> Len=010 <?>
> 	Kernel driver in use: pciback
> 	Kernel modules: radeon


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

Re: [Xen-users] Future of xend and xl (Was: Re: VGA passthough still not working)

[Stefano Stabellini]

On Wed, 25 Jan 2012, Florian Heigl wrote:
> > This was announced in the Xen 4.1 release notes[1] and the upgrade
> > guide[2]. In Xen 4.2 we have ended up formally deprecating xend rather
> > than removing it but you should expect that xend will be removed in a
> > future release of Xen and begin planning your transition to xl (or one
> > of the other alternative toolstacks), testing the features which matter
> > to you and reporting bugs/submitting patches as appropriate.
> 
> I think it would be a nice move if this wasn't just left to us users,
> especially since it is a process of suddenly finding missing parts or
> large changes in functionality in something like an easter egg hunt.
> 
> How about if we assemble a list of Xen features in xm/xend and those
> that you have implemented in xl. Right now it's just guesswork and a
> lot double effort since one doesn't just have to track which parts are
> gone, but we even have to constantly read all threads on the lists to
> find out if a feature is suddenly coming back or being deprecated.

The only features that we know are missing in Xl, and we have no current
plan of implementing them, are in the list below.
Please do tell if you find any other features that you need, currently
in xend, but missing in Xl.


> i.e. take something like Remus that had officially become a part of
> Xen some time back but isn't possible to use with PV domUs with any
> reasonable amount of effort. And not by formal decision, after a
> "heads up" mail, but just by chance. A few months I was still thinking
> I would be able to use it in a hosting product but "whoops" not
> working anymore.

Now we are more agressive at deprecating components that haven't been
properly maintained.
In the case of Remus, fortunately Shriram stepped up to the task.


> Back to xl:
> Probably noone really objects removing xm by now since it's not really
> working anymore once the system has xl support and the two are not
> compatible. It has to be in everyones interest that there is no
> unneeded code to maintain and that the core devs LIKE that code and
> that people can rely on it being maintained for the years to come.
> It doesn't matter if we type 'xl' or 'xm', it has to *work* :)
> 
> But maybe we can have a somewhat reliable roadmap where one can see xm
> will be kicked in 4.4 *and* we're planning to have the following 1234
> features supported by then.
> That way interested parties have a chance to put ressources into
> getting missing features "back in" and other projects know how much
> time they have to clean up their code. I.e. cobbler/koan is suddenly
> broken after 4 years and people can't install domUs anymore. :)

This is a reasonable request.
I would also like to mention that we have a wiki page regarding
migration to 4.1 with a few notes about Xl:
http://wiki.xen.org/xenwiki/MigrationGuideToXen4.1%2B
Also Ian just wrote an Xl feature list:
http://wiki.xen.org/wiki/XL


Features missing in Xl, with no current plan to introduce them (as usual
contributions are welcome and encouraged):

- python support in VM config files;
- an RPC interface;
- managed domain;
- pv-usb;
- netchannel2;
- pv-scsi;


Features missing in Xl, work in progress:

- Remus;
- machine parsable output from xl create.



Considering that pv-usb, pv-scsi and netchannel2 are not upstream in
Linux, the only feature that I believe people might miss is managed
domains. However it should be pretty easy to script that feature on top
of Xl and I believe that Debian might even be already doing something
like that with xend.

Re: [Xen-devel] VGA passthough still not working

[Likarpenkov Alexander]

I propose the following innovations in xl. Namely domu and dom0 to equate 
the rights of control xen
Example in grub.cfg:
multiboot       /boot/xen-4.1.2.gz placeholder iommu=1 msi=1 dom0_mem=512M 
xl_ip=10.0.0.1 xl_port=8888 xl_access=10.0.0.0/8,190.12.12.231 

Re: [Xen-devel] Future of xend and xl (Was: Re: VGA passthough still not working)

[Likarpenkov Alexander]

[-- Attachment #1.1: Type: text/plain, Size: 321 bytes --]

I propose the following innovations in xl (or xen). Namely domu and dom0 to equate the rights of control xen
Example in grub.cfg on debian:
multiboot       /boot/xen-4.1.2.gz placeholder iommu=1 msi=1 dom0_mem=512M xl_ip=10.0.0.1 xl_port=8888 xl_access=10.0.0.0/8,190.12.12.231(external ip )[any list ip coma separated]

[-- Attachment #1.2: Type: text/html, Size: 807 bytes --]

[-- Attachment #2: Type: text/plain, Size: 137 bytes --]

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Re: [Xen-users] Future of xend and xl (Was: Re: VGA passthough still not working)

[Jim Fehlig]

Stefano Stabellini wrote:
> Considering that pv-usb, pv-scsi and netchannel2 are not upstream in
> Linux, the only feature that I believe people might miss is managed
> domains. However it should be pretty easy to script that feature on top
> of Xl and I believe that Debian might even be already doing something
> like that with xend.
>   

The libvirt libxl driver also provides managed domains, but it does not
yet have feature parity with the legacy xen driver.  Oh, and with all
the changes to the libxl public interface, it wont work with
xen-unstable.  I hope to spend some time on the driver soon, and always
looking for some help :-).

Regards,
Jim

Re: xl vs xm - hernya (bad results)

[Likarpenkov Alexander]

Compare the two results on the same system.
xl - not sorted alphabetically and by memory shows the nonsense


# xl list
Name                                        ID   Mem VCPUs      State 
Time(s)
Domain-0                                     0   512     6        r--  
313260.0
c2                                           1  4096     5        r--  
111502.1
c3                                           4   512     5        r--  
6419.4
s1                                       6  1027     2        r--  19593.0
d70                                          7  1003     1        r--  
77161.6
d73                                          8   515     1        r--  
237146.7
v01                                         10    93     1        r--  
48162.9
t2                                          12   515     5        r--  
38607.5
a1                                       13  2050     4        r-- 160406.0
g4                                          15    99     1        r--  
15616.6
g3                                          18   131     1        r--  
43006.0
b1                                        20   512     5        r--   4133.2
t1                                          21   259     1        r--  
140468.7
d80                                         22   515     5        r--  
50262.9
g2                                          38    83     1        r--  
34071.0
d82                                         40   771     5        r--  
17699.5
j2                                          41  1027     5        r--  
68179.1
d75                                         43    99     1        r--  
13325.7
d74                                         52   771     1        r--  
9707.6
t3                                          53   515     5        r--  
7913.0


#xm list
Name                                        ID   Mem VCPUs      State 
Time(s)
Domain-0                                     0   512     6     r-----  
313274.1
a1                                       13  2048     4     -b---- 160412.8
b1                                        20   512     5     ------   4133.4
c2                                           1  4096     5     -b----  
111508.6
c3                                           4   512     5     -b----  
6419.5
d70                                          7  1000     1     -b----  
77163.8
d73                                          8   512     1     -b----  
237155.4
d74                                         52   768     1     -b----  
9709.6
d75                                         43    96     1     -b----  
13327.6
d80                                         22   512     5     -b----  
50266.4
d82                                         40   768     5     -b----  
17700.9
g2                                          38    80     1     -b----  
34073.4
g3                                          18   128     1     -b----  
43008.1
g4                                          15    96     1     -b----  
15617.3
j2                                          41  1024     5     -b----  
68192.6
s1                                       6  1024     2     -b----  19594.0
t1                                          21   256     1     r-----  
140478.2
t2                                          12   512     5     -b----  
38609.1
t3                                          53   512     5     -b----  
7914.8
v01                                         10    90     1     -b----  
48164.8

xl vs xm - hernya (bad results)

[Likarpenkov Alexander]

[-- Attachment #1.1: Type: text/plain, Size: 3530 bytes --]

Sorry, quoting lines cut, and I repeat the message

Compare the two results on the same system.
xl - not sorted alphabetically and by memory shows the nonsense
# xl list
Name                                        ID   Mem VCPUs      State   Time(s)
Domain-0                                     0   512     6        r-- 313260.0
c2                                           1  4096     5        r-- 111502.1
c3                                           4   512     5        r--   6419.4
s1                                       6  1027     2        r--  19593.0
d70                                          7  1003     1        r--  77161.6
d73                                          8   515     1        r-- 237146.7
v01                                         10    93     1        r--  48162.9
t2                                          12   515     5        r--  38607.5
a1                                       13  2050     4        r-- 160406.0
g4                                          15    99     1        r--  15616.6
g3                                          18   131     1        r--  43006.0
b1                                        20   512     5        r--   4133.2
t1                                          21   259     1        r-- 140468.7
d80                                         22   515     5        r--  50262.9
g2                                          38    83     1        r--  34071.0
d82                                         40   771     5        r--  17699.5
j2                                          41  1027     5        r--  68179.1
d75                                         43    99     1        r--  13325.7
d74                                         52   771     1        r--   9707.6
t3                                          53   515     5        r--   7913.0
# xm list
Name                                        ID   Mem VCPUs      State   Time(s)
Domain-0                                     0   512     6     r----- 313274.1
a1                                       13  2048     4     -b---- 160412.8
b1                                        20   512     5     ------   4133.4
c2                                           1  4096     5     -b---- 111508.6
c3                                           4   512     5     -b----   6419.5
d70                                          7  1000     1     -b----  77163.8
d73                                          8   512     1     -b---- 237155.4
d74                                         52   768     1     -b----   9709.6
d75                                         43    96     1     -b----  13327.6
d80                                         22   512     5     -b----  50266.4
d82                                         40   768     5     -b----  17700.9
g2                                          38    80     1     -b----  34073.4
g3                                          18   128     1     -b----  43008.1
g4                                          15    96     1     -b----  15617.3
j2                                          41  1024     5     -b----  68192.6
s1                                       6  1024     2     -b----  19594.0
t1                                          21   256     1     r----- 140478.2
t2                                          12   512     5     -b----  38609.1
t3                                          53   512     5     -b----   7914.8
v01                                         10    90     1     -b----  48164.8

[-- Attachment #1.2: Type: text/html, Size: 16269 bytes --]

[-- Attachment #2: Type: text/plain, Size: 137 bytes --]

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Re: [Xen-users] VGA passthough still not working

[Konrad Rzeszutek Wilk]

On Wed, Jan 25, 2012 at 08:52:17PM +0100, Pavel Mat??ja wrote:
> On Wed 25. of January 2012 20:29:12 Pavel Mat??ja wrote:
> > On Wed 25. of January 2012 17:52:11 Doug Magee wrote:
> > > Also, i believe you said the card you're trying to pass through is not
> > > the primary card in your host system.  If that's the case, don't use
> > > gfx_passthru or expect to get the video bios working.  The 'primary'
> > > video adapter owns certain io ports and memory areas that are consitent
> > > from machine to machine.  Also, the system will copy the vbios from the
> > > card to a location in memory (0xc0000) so it can execute at boot time.
> > > 
> > > Xen's gfx_passthru code depends on all of these factors.  As the code
> > > stands, if you use gfx_passthru on a secondary card, it will still copy
> > > the vbios from the primary card (as it simply reads memory from
> > > 0xc0000), and directly map io ports and low memory areas to those used
> > > by the primary card in the host system.  In this case the guest will
> > > almost certainly never get past executing ROMBIOS, and the host may or
> > > may not lock up or experience 'issues'.
> > 
> > This will do the trick with secondary card (replace path to VGA BIOS):
> > 
> > --- xen-unstable.hg.working/tools/ioemu-remote/hw/pt-graphics.c 2012-01-25
> > 20:26:37.927654890 +0100
> > +++ xen-unstable.hg.working.generic/tools/ioemu-remote/hw/pt-graphics.c
> > 2011-07-30 13:57:57.347396095 +0200
> > @@ -487,10 +487,10 @@
> >  {
> >      int fd;
> >      uint32_t bios_size = 0;
> > -    uint32_t start = 0;
> > +    uint32_t start = 0xC0000;
> >      uint16_t magic = 0;
> > 
> > -    if ( (fd = open("/lib/firmware/ASUS.HD6850.1024.101007.bin",
> > O_RDONLY)) < 0 )

How does one "extract" the bios from the ATI cards? With NVidia I
noticed could do it via /sys/kernel/debug/dri/0/vbios.rom.

But that is not present on ATI cards. Did you instrument the radeon
driver to dump it somewhere?

Re: [Xen-users] VGA passthough still not working

[Pavel Mateja]

> On Wed, Jan 25, 2012 at 08:52:17PM +0100, Pavel Mat??ja wrote:
> How does one "extract" the bios from the ATI cards? With NVidia I
> noticed could do it via /sys/kernel/debug/dri/0/vbios.rom.
> 
> But that is not present on ATI cards. Did you instrument the radeon
> driver to dump it somewhere?

Hi,
I don't know, I got it from http://www.techpowerup.com/vgabios/
But copy from c000 should be just fine, should it not?
-- 
Pavel Mateja

Re: [Xen-devel] VGA passthough still not working

[Likarpenkov Alexander]

You yourself do something you can do, or is your only one link to the 
internet? You are able to answer questions or do not have enough of the 
cerebellum? Or config files provided or not flood.

 KRW> On Mon, Jan 23, 2012 at 12:53:50PM +0100, Sandi Romih wrote:
 ??>> Pasi,
 ??>>
 ??>> Yes, I did verify that IOMMU is enabled. I get this in my xm dmesg:
 ??>>
 ??>> (XEN) I/O virtualisation enabled
 ??>>
 ??>> (XEN) Intel VT-d Snoop Control supported.(XEN) Intel VT-d DMA
 ??>> Passthrough not supported.(XEN) Intel VT-d Queued Invalidation
 ??>> supported.(XEN) Intel VT-d Interrupt Remapping not supported.
 ??>>
 ??>> But I dont think I have this message (I am not near my system now, so
 ??>> I can not confirm)
 ??>>
 ??>> (XEN) I/O virtualisation for PV guests enabled
 ??>>
 ??>> I believe that many have managed to get VGA passthru working, but they
 ??>> generally dont post their stories. one only finds the problems they
 ??>> are encountering when searching about this. That is why it would be
 ??>> nice to put together a kind of manual in the wiki which would have all
 ??>> this info together in one location.

 KRW> http://lmgtfy.com/?q=Xen+VGA+passthrough

Re: [Xen-devel] VGA passthough still not working

[Likarpenkov Alexander]

I'm really sorry. something I do not understand true

 LA> You yourself do something you can do, or is your only one link to the
 LA> internet? You are able to answer questions or do not have enough of the
 LA> cerebellum? Or config files provided or not flood.

 KRW>> On Mon, Jan 23, 2012 at 12:53:50PM +0100, Sandi Romih wrote:
 ??>>> Pasi,
 ??>>>
 ??>>> Yes, I did verify that IOMMU is enabled. I get this in my xm dmesg:
 ??>>>
 ??>>> (XEN) I/O virtualisation enabled
 ??>>>
 ??>>> (XEN) Intel VT-d Snoop Control supported.(XEN) Intel VT-d DMA
 ??>>> Passthrough not supported.(XEN) Intel VT-d Queued Invalidation
 ??>>> supported.(XEN) Intel VT-d Interrupt Remapping not supported.
 ??>>>
 ??>>> But I dont think I have this message (I am not near my system now, so
 ??>>> I can not confirm)
 ??>>>
 ??>>> (XEN) I/O virtualisation for PV guests enabled
 ??>>>
 ??>>> I believe that many have managed to get VGA passthru working, but
 ??>>> they generally dont post their stories. one only finds the problems
 ??>>> they are encountering when searching about this. That is why it would
 ??>>> be nice to put together a kind of manual in the wiki which would have
 ??>>> all this info together in one location.

 KRW>> http://lmgtfy.com/?q=Xen+VGA+passthrough


--
? ?????????, ??????????? ?????????
??????? ???????-???????????
???????? IT, ???????????????????? ?????? VEGA
E-mail: al@ohosting.org.ua
???:  +380 63 617-18-62 

Re: [Xen-users] xl vs xm - hernya (bad results)

[Stefano Stabellini]

[-- Attachment #1: Type: text/plain, Size: 6302 bytes --]

On Fri, 27 Jan 2012, Likarpenkov Alexander wrote:
> Sorry, quoting lines cut, and I repeat the message
>  
> Compare the two results on the same system.
> xl - not sorted alphabetically and by memory shows the nonsense
> # xl list
> Name                                        ID   Mem VCPUs      State   Time(s)
> Domain-0                                     0   512     6        r-- 313260.0
> c2                                           1  4096     5        r-- 111502.1
> c3                                           4   512     5        r--   6419.4
> s1                                       6  1027     2        r--  19593.0
> d70                                          7  1003     1        r--  77161.6
> d73                                          8   515     1        r-- 237146.7
> v01                                         10    93     1        r--  48162.9
> t2                                          12   515     5        r--  38607.5
> a1                                       13  2050     4        r-- 160406.0
> g4                                          15    99     1        r--  15616.6
> g3                                          18   131     1        r--  43006.0
> b1                                        20   512     5        r--   4133.2
> t1                                          21   259     1        r-- 140468.7
> d80                                         22   515     5        r--  50262.9
> g2                                          38    83     1        r--  34071.0
> d82                                         40   771     5        r--  17699.5
> j2                                          41  1027     5        r--  68179.1
> d75                                         43    99     1        r--  13325.7
> d74                                         52   771     1        r--   9707.6
> t3                                          53   515     5        r--   7913.0
> # xm list
> Name                                        ID   Mem VCPUs      State   Time(s)
> Domain-0                                     0   512     6     r----- 313274.1
> a1                                       13  2048     4     -b---- 160412.8
> b1                                        20   512     5     ------   4133.4
> c2                                           1  4096     5     -b---- 111508.6
> c3                                           4   512     5     -b----   6419.5
> d70                                          7  1000     1     -b----  77163.8
> d73                                          8   512     1     -b---- 237155.4
> d74                                         52   768     1     -b----   9709.6
> d75                                         43    96     1     -b----  13327.6
> d80                                         22   512     5     -b----  50266.4
> d82                                         40   768     5     -b----  17700.9
> g2                                          38    80     1     -b----  34073.4
> g3                                          18   128     1     -b----  43008.1
> g4                                          15    96     1     -b----  15617.3
> j2                                          41  1024     5     -b----  68192.6
> s1                                       6  1024     2     -b----  19594.0
> t1                                          21   256     1     r----- 140478.2
> t2                                          12   512     5     -b----  38609.1
> t3                                          53   512     5     -b----   7914.8
> v01                                         10    90     1     -b----  48164.8

xl and xm compute the amount of memory used by VMs differently, in
particular xl returns the current amount of memory used by the VM, as
reported by the hypervisor.

What Xen version are you using? Could you please post the xl and the xm
config files of one of the VMs that show up differently?

If you are creating the VMs using xm and then executing "xl list", you
should know that this is not a supported configuration: either you use
xm or xl, you shouldn't mix them.

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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