Xen users - Jan 2012 - VGA passthough still not working

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


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

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

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

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

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

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-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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

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

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.

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/

I also have problems using passthrough. I have two graphics cards in my machine 
and I want to pass one (the secondary) of them to the Windows 7 VM. My system 
has VT-d, which is enabled, and Windows sees the device and nVidia driver 
installer works, but that's about it. In the device manager I see two
devices
with errors. One 'other device' named 'Xen pci device #0'
(hardware ID:
'xen\pci') with the message 'The drivers for this device are not
installed.
(Code 28)' and a 'display adapter' named 'NVIDIA NVS 4200M'
(that is correct)
with the message 'Windows has stopped this device because it has reported 
problems. (Code 43)'. Does anyone have any idea what causes these problems
and
whether this is supposed to work?

Jethro

On 20-01-12 12:32, Pasi Kärkkäinen 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/
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users
>
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

I manually set for all devices except the desired - disable
You can send a screenshot of the Device Manager tab with extensive graphics 
cards?

 JB> I also have problems using passthrough. I have two graphics cards in my
 JB> machine and I want to pass one (the secondary) of them to the Windows 7
 JB> VM. My system has VT-d, which is enabled, and Windows sees the device
 JB> and nVidia driver installer works, but that''s about it. In the
device
 JB> manager I see two devices with errors. One ''other
device'' named ''Xen
 JB> pci device #0'' (hardware ID: ''xen\pci'') with
the message ''The drivers
for
 JB> this device are not installed. (Code 28)'' and a
''display adapter'' named
 JB> ''NVIDIA NVS 4200M'' (that is correct) with the message
''Windows has
 JB> stopped this device because it has reported problems. (Code
43)''. Does
 JB> anyone have any idea what causes these problems and whether this is
 JB> supposed to work?

I''m not sure what you mean. Here is the screenshot:
http://jbeekman.nl/xen_devmgmt.png

Attached also are the xm.cfg and some xenstore-ls output.

Jethro

On 20-01-12 14:39, Likarpenkov Alexander wrote:
> I manually set for all devices except the desired - disable
> You can send a screenshot of the Device Manager tab with extensive graphics
cards?
>
> JB> I also have problems using passthrough. I have two graphics cards in
my
> JB> machine and I want to pass one (the secondary) of them to the
Windows 7
> JB> VM. My system has VT-d, which is enabled, and Windows sees the
device
> JB> and nVidia driver installer works, but that''s about it. In
the device
> JB> manager I see two devices with errors. One ''other
device'' named ''Xen
> JB> pci device #0'' (hardware ID: ''xen\pci'')
with the message ''The drivers for
> JB> this device are not installed. (Code 28)'' and a
''display adapter'' named
> JB> ''NVIDIA NVS 4200M'' (that is correct) with the
message ''Windows has
> JB> stopped this device because it has reported problems. (Code
43)''. Does
> JB> anyone have any idea what causes these problems and whether this is
> JB> supposed to work?
>
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users
>


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

mmm, I''ve opted for a video card for xen - put the geforce 6600 - the
result
was the same. After that put the Ati and I have no error. I otkloyuchil 
cirrus logic - and working pci passthrought.
I suspect that it xenbug.

 JB> I''m not sure what you mean. Here is the screenshot:
 JB> http://jbeekman.nl/xen_devmgmt.png

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

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

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

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

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

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.

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.

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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?

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? 



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

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

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

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?

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

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

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

Во вторник, двадцать четвертого января 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

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

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

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

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

Hi,
> 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.
I can''t blame you, this seems like a good choice. But do vifnames
already work with xl? Support for vifnames is the one thing that''s
preventing me from migrating entirely.

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

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

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

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

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

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

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

> 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

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

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 ;-)

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

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.

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

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]

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

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

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

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


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

> 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 ;-)
I looked at this page and
http://xenbits.xen.org/docs/unstable/misc/xl-network-configuration.html

Quote:
> vifname
> This keyword is valid for HVM guest devices with type=ioemu only.
> Specifies the backend device name for an emulated device. The default
> is tapDOMID.DEVID where DOMID is the guest domain ID and DEVID is the
> device number.
Why can''t this be extended to all domains?

It''s important for me to properly have vifnames because if you have a
large number of hosts then arbitrary vif names are much harder to read
than custom vifnames. I know, I''ve been nagging about it but
that''s
only because I haven''t seen any real response to it... other than other
users who seem to support the idea.

So can this please be added, Ian?

I was completely satisfied with the current situation. I picked an arbitrary 
DomU
And how many would not have virtual systems - quickly found their interfaces
Nothing needs to be changed
Embracing reason:

# xm list | grep g3
g3                                          18   128     1     -b----  
43466.0
# ifconfig | grep -A6 vif18
vif18.0   Link encap:Ethernet  HWaddr fe:ff:ff:ff:ff:ff
          inet6 addr: fe80::fcff:ffff:feff:ffff/64 Scope:Link
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:5364587 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5145284 errors:0 dropped:22 overruns:0 carrier:0
          collisions:0 txqueuelen:32
          RX bytes:1034242595 (1.0 GB)  TX bytes:602515830 (602.5 MB)
--
vif18.1   Link encap:Ethernet  HWaddr fe:ff:ff:ff:ff:ff
          inet6 addr: fe80::fcff:ffff:feff:ffff/64 Scope:Link
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:4935521 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5255805 errors:0 dropped:38 overruns:0 carrier:0
          collisions:0 txqueuelen:32
          RX bytes:876714763 (876.7 MB)  TX bytes:1111388104 (1.1 GB)
--
vif18.2   Link encap:Ethernet  HWaddr fe:ff:ff:ff:ff:ff
          inet6 addr: fe80::fcff:ffff:feff:ffff/64 Scope:Link
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:1498125 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1950646 errors:0 dropped:11 overruns:0 carrier:0
          collisions:0 txqueuelen:32
          RX bytes:526095465 (526.0 MB)  TX bytes:223020577 (223.0 MB)
--
vif18.3   Link encap:Ethernet  HWaddr fe:ff:ff:ff:ff:ff
          inet6 addr: fe80::fcff:ffff:feff:ffff/64 Scope:Link
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:1 errors:0 dropped:0 overruns:0 frame:0
          TX packets:373779 errors:0 dropped:21 overruns:0 carrier:0
          collisions:0 txqueuelen:32
          RX bytes:28 (28.0 B)  TX bytes:19436508 (19.4 MB)


? ???????, ???????? ???????? ?????? 2012 ????, ? 14:21:26 ?? ??????:

 ??>> 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 ;-)

 MvD> I looked at this page and
 MvD> 
http://xenbits.xen.org/docs/unstable/misc/xl-network-configuration.html

 MvD> Quote:

 ??>> vifname
 ??>> This keyword is valid for HVM guest devices with type=ioemu only.
 ??>> Specifies the backend device name for an emulated device. The
default
 ??>> is tapDOMID.DEVID where DOMID is the guest domain ID and DEVID is
the
 ??>> device number.

 MvD> Why can''t this be extended to all domains?

 MvD> It''s important for me to properly have vifnames because if you
have a
 MvD> large number of hosts then arbitrary vif names are much harder to read
 MvD> than custom vifnames. I know, I''ve been nagging about it but
that''s
 MvD> only because I haven''t seen any real response to it... other
than
 MvD> other users who seem to support the idea.

 MvD> So can this please be added, Ian?

--
I try to select the top of the correspondence
and collected  in one location.
Come and help comments
http://lixen.ua-ohosting.com/

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?

> 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

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

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

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.
--8323329-1178924071-1328119544=:3196
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--8323329-1178924071-1328119544=:3196--