[Qemu-devel] a user here - pci-assign

[Qemu-devel] a user here - pci-assign

[lejeczek]

hi everybody,

I've decided to bother you guys for user list seems.. quiet, 
no, really.

so, novice type of question, where/how do I get hold of the 
values for below options?
I don't read the code, ain't no programmer, I can't figure 
out how to get hold of the values for

pci-assign.host=pci-hostaddr
pci-assign.iommu=uint32
pci-assign.bootindex=int32
pci-assign.configfd=string
pci-assign.addr=pci-devfn
pci-assign.romfile=string
pci-assign.rombar=uint32
pci-assign.multifunction=on/off

and, would this be complete list (I saw a bug report online) 
for qemu-kvm-0.12.1.2-2.295.el6_3.2.x86_64 ?
any user-friendly docs on it? I am tampering with VGAs but 
cannot get it to work, some partial success though.


many thanks

Re: [Qemu-devel] a user here - pci-assign

[Alex Williamson]

On Fri, 2012-09-28 at 10:54 +0100, lejeczek wrote:
> hi everybody,
> 
> I've decided to bother you guys for user list seems.. quiet, 
> no, really.
> 
> so, novice type of question, where/how do I get hold of the 
> values for below options?
> I don't read the code, ain't no programmer, I can't figure 
> out how to get hold of the values for
> 
> pci-assign.host=pci-hostaddr
> pci-assign.iommu=uint32
> pci-assign.bootindex=int32
> pci-assign.configfd=string
> pci-assign.addr=pci-devfn
> pci-assign.romfile=string
> pci-assign.rombar=uint32
> pci-assign.multifunction=on/off
> 
> and, would this be complete list (I saw a bug report online) 
> for qemu-kvm-0.12.1.2-2.295.el6_3.2.x86_64 ?
> any user-friendly docs on it? I am tampering with VGAs but 
> cannot get it to work, some partial success though.

These aren't the droids you're looking for to get assignment of VGA
devices to work.  romfile is maybe the only interesting one, but only if
qemu can't read it directly.

All of these are options that get specified after:

-device pci-assign

> pci-assign.host=pci-hostaddr

host=2:00.0 (specifies assigning host PCI device 2:00.0)

> pci-assign.iommu=uint32

deprecated, don't bother with this

> pci-assign.bootindex=int32

boot ordering, not useful for VGA

> pci-assign.configfd=string

pass an already open file descriptor for config space access, for
libvirt managed guests only

> pci-assign.addr=pci-devfn

addr=3.0 (specifies the guest PCI address where the device is exposed)

> pci-assign.romfile=string

specifies a file to use as the PCI option ROM, unless you see a warning
about not being able to read the ROM, this probably isn't going to help
you.

> pci-assign.rombar=uint32

rombar=0 disables the PCI option ROM, for cases where it doesn't work or
you don't want it.

> pci-assign.multifunction=on/off

for specifying multifunction devices, ex:

-device pci-assign,host=2:00.0,addr=3.0,multifunction=on \
-device pci-assign,host=2:00.1,addr=3.1

Thanks,

Alex

Re: [Qemu-devel] a user here - pci-assign

[lejeczek]

thanks Alex for your patience, appreciate it I do

what would be the droids I need?
I'm experiencing guests' "puzzling" behavior and was 
suggested that command line arguments were wrong/incomplete.

same box/hardware and radeon 5450 and ...
- winXP-32bit -> OK - I assumed getting the guest on a 
external computer monitor was an ultimate test
- win7-64bit -> OS reports device as disabled cause the 
device reported an error

same box as above and geforce gt640 and ..
for both XP and 7 report device with exclamation marks (thus 
did not even bother to connect any screens like in working 
case with XP & radeon)

I'll try to get hold of ROMs of the cards, meanwhile, how 
can I troubleshoot it? how to get more verbose feedback and 
what to specifically look for?

many thanks




On 28/09/12 17:05, Alex Williamson wrote:
> On Fri, 2012-09-28 at 10:54 +0100, lejeczek wrote:
>> hi everybody,
>>
>> I've decided to bother you guys for user list seems.. quiet,
>> no, really.
>>
>> so, novice type of question, where/how do I get hold of the
>> values for below options?
>> I don't read the code, ain't no programmer, I can't figure
>> out how to get hold of the values for
>>
>> pci-assign.host=pci-hostaddr
>> pci-assign.iommu=uint32
>> pci-assign.bootindex=int32
>> pci-assign.configfd=string
>> pci-assign.addr=pci-devfn
>> pci-assign.romfile=string
>> pci-assign.rombar=uint32
>> pci-assign.multifunction=on/off
>>
>> and, would this be complete list (I saw a bug report online)
>> for qemu-kvm-0.12.1.2-2.295.el6_3.2.x86_64 ?
>> any user-friendly docs on it? I am tampering with VGAs but
>> cannot get it to work, some partial success though.
> These aren't the droids you're looking for to get assignment of VGA
> devices to work.  romfile is maybe the only interesting one, but only if
> qemu can't read it directly.
>
> All of these are options that get specified after:
>
> -device pci-assign
>
>> pci-assign.host=pci-hostaddr
> host=2:00.0 (specifies assigning host PCI device 2:00.0)
>
>> pci-assign.iommu=uint32
> deprecated, don't bother with this
>
>> pci-assign.bootindex=int32
> boot ordering, not useful for VGA
>
>> pci-assign.configfd=string
> pass an already open file descriptor for config space access, for
> libvirt managed guests only
>
>> pci-assign.addr=pci-devfn
> addr=3.0 (specifies the guest PCI address where the device is exposed)
>
>> pci-assign.romfile=string
> specifies a file to use as the PCI option ROM, unless you see a warning
> about not being able to read the ROM, this probably isn't going to help
> you.
>
>> pci-assign.rombar=uint32
> rombar=0 disables the PCI option ROM, for cases where it doesn't work or
> you don't want it.
>
>> pci-assign.multifunction=on/off
> for specifying multifunction devices, ex:
>
> -device pci-assign,host=2:00.0,addr=3.0,multifunction=on \
> -device pci-assign,host=2:00.1,addr=3.1
>
> Thanks,
>
> Alex
>
>
>

Re: [Qemu-devel] a user here - pci-assign

[Alex Williamson]

On Fri, 2012-09-28 at 19:46 +0100, lejeczek wrote:
> thanks Alex for your patience, appreciate it I do
> 
> what would be the droids I need?
> I'm experiencing guests' "puzzling" behavior and was 
> suggested that command line arguments were wrong/incomplete.
> 
> same box/hardware and radeon 5450 and ...
> - winXP-32bit -> OK - I assumed getting the guest on a 
> external computer monitor was an ultimate test
> - win7-64bit -> OS reports device as disabled cause the 
> device reported an error

I've had this same card working with both of these guests.  I believe
one trick on win7 was to use -cpu host.  Also, don't try to disable the
emulated vga device, just set it up like a dual-head system.  Once you
load the catalyst driver windows will switch to use the assigned device
exclusively.  I was using the new vfio assignment driver, but someone
else recently report it working with the existing driver as well.  The
5450 should be a secondary graphics card on the host system, trying to
assign the primary graphics is going to cause more problems.  Also
blacklist the radeon driver on the host, we don't need any leftover
state from the Linux driver causing problems since most of these
graphics cards don't support a reset mechanism.

> same box as above and geforce gt640 and ..
> for both XP and 7 report device with exclamation marks (thus 
> did not even bother to connect any screens like in working 
> case with XP & radeon)

I don't think we've seen any reports yet of Nvidia cards working,
there's another thread on the kvm list speculating at some of the
problems.

> I'll try to get hold of ROMs of the cards, meanwhile, how 
> can I troubleshoot it? how to get more verbose feedback and 
> what to specifically look for?

ROMs are only going to help if you're getting errors trying to read the
ROM.  Nvidia seems to have this problem, but I don't think radeons
typical do.  There's a #define in the code that can be enabled to get
more logging, but it's not terribly useful unless you know what you're
looking at.  VGA has plenty of issues with legacy PC address ranges that
are known problems, but there are also plenty of unknown problems that
make it a pretty difficult black box debugging project.  Thanks,

Alex

Re: [Qemu-devel] a user here - pci-assign

[lejeczek]

hmm, still cannot get readon 5450 to work on win7-64, have 
changed -cpu to host but no fix
no vfio in qemu-kvm-0.12.1.2-2.295.el6_3.2.x86_64
yes, I do blacklist modules at grub level and later in 
modprobe also

is primary/secondary VGA setup somehow helped by 
qemu/components? in guest I can do anything since device is 
disabled.

pci-assign.multifunction=on/off - that would be the case 
with VGAs like radeon and nvidia - audio part - is it 
optional or always has to be ON for such devices?

where one gets hold of information like: addr= ?
I understand these are needed only! if pci-assign.host is 
not enough and qemu has no way of knowing/finding it, when 
may this happen?

many thanks


On 28/09/12 20:48, Alex Williamson wrote:
> On Fri, 2012-09-28 at 19:46 +0100, lejeczek wrote:
>> thanks Alex for your patience, appreciate it I do
>>
>> what would be the droids I need?
>> I'm experiencing guests' "puzzling" behavior and was
>> suggested that command line arguments were wrong/incomplete.
>>
>> same box/hardware and radeon 5450 and ...
>> - winXP-32bit -> OK - I assumed getting the guest on a
>> external computer monitor was an ultimate test
>> - win7-64bit -> OS reports device as disabled cause the
>> device reported an error
> I've had this same card working with both of these guests.  I believe
> one trick on win7 was to use -cpu host.  Also, don't try to disable the
> emulated vga device, just set it up like a dual-head system.  Once you
> load the catalyst driver windows will switch to use the assigned device
> exclusively.  I was using the new vfio assignment driver, but someone
> else recently report it working with the existing driver as well.  The
> 5450 should be a secondary graphics card on the host system, trying to
> assign the primary graphics is going to cause more problems.  Also
> blacklist the radeon driver on the host, we don't need any leftover
> state from the Linux driver causing problems since most of these
> graphics cards don't support a reset mechanism.
>
>> same box as above and geforce gt640 and ..
>> for both XP and 7 report device with exclamation marks (thus
>> did not even bother to connect any screens like in working
>> case with XP & radeon)
> I don't think we've seen any reports yet of Nvidia cards working,
> there's another thread on the kvm list speculating at some of the
> problems.
>
>> I'll try to get hold of ROMs of the cards, meanwhile, how
>> can I troubleshoot it? how to get more verbose feedback and
>> what to specifically look for?
> ROMs are only going to help if you're getting errors trying to read the
> ROM.  Nvidia seems to have this problem, but I don't think radeons
> typical do.  There's a #define in the code that can be enabled to get
> more logging, but it's not terribly useful unless you know what you're
> looking at.  VGA has plenty of issues with legacy PC address ranges that
> are known problems, but there are also plenty of unknown problems that
> make it a pretty difficult black box debugging project.  Thanks,
>
> Alex
>
>
>

Re: [Qemu-devel] a user here - pci-assign

[Alex Williamson]

On Mon, 2012-10-01 at 12:10 +0100, lejeczek wrote:
> hmm, still cannot get readon 5450 to work on win7-64, have 
> changed -cpu to host but no fix
> no vfio in qemu-kvm-0.12.1.2-2.295.el6_3.2.x86_64
> yes, I do blacklist modules at grub level and later in 
> modprobe also

You probably want to try newer upstream code.  RHEL does not currently
support assignment of VGA.

> is primary/secondary VGA setup somehow helped by 
> qemu/components? in guest I can do anything since device is 
> disabled.
> 
> pci-assign.multifunction=on/off - that would be the case 
> with VGAs like radeon and nvidia - audio part - is it 
> optional or always has to be ON for such devices?

Optional

> where one gets hold of information like: addr= ?
> I understand these are needed only! if pci-assign.host is 
> not enough and qemu has no way of knowing/finding it, when 
> may this happen?

This is not going to help you.  It's a matter of finding a free slot,
which qemu can do fine on it's own if you don't want to specify.
Thanks,

Alex

> On 28/09/12 20:48, Alex Williamson wrote:
> > On Fri, 2012-09-28 at 19:46 +0100, lejeczek wrote:
> >> thanks Alex for your patience, appreciate it I do
> >>
> >> what would be the droids I need?
> >> I'm experiencing guests' "puzzling" behavior and was
> >> suggested that command line arguments were wrong/incomplete.
> >>
> >> same box/hardware and radeon 5450 and ...
> >> - winXP-32bit -> OK - I assumed getting the guest on a
> >> external computer monitor was an ultimate test
> >> - win7-64bit -> OS reports device as disabled cause the
> >> device reported an error
> > I've had this same card working with both of these guests.  I believe
> > one trick on win7 was to use -cpu host.  Also, don't try to disable the
> > emulated vga device, just set it up like a dual-head system.  Once you
> > load the catalyst driver windows will switch to use the assigned device
> > exclusively.  I was using the new vfio assignment driver, but someone
> > else recently report it working with the existing driver as well.  The
> > 5450 should be a secondary graphics card on the host system, trying to
> > assign the primary graphics is going to cause more problems.  Also
> > blacklist the radeon driver on the host, we don't need any leftover
> > state from the Linux driver causing problems since most of these
> > graphics cards don't support a reset mechanism.
> >
> >> same box as above and geforce gt640 and ..
> >> for both XP and 7 report device with exclamation marks (thus
> >> did not even bother to connect any screens like in working
> >> case with XP & radeon)
> > I don't think we've seen any reports yet of Nvidia cards working,
> > there's another thread on the kvm list speculating at some of the
> > problems.
> >
> >> I'll try to get hold of ROMs of the cards, meanwhile, how
> >> can I troubleshoot it? how to get more verbose feedback and
> >> what to specifically look for?
> > ROMs are only going to help if you're getting errors trying to read the
> > ROM.  Nvidia seems to have this problem, but I don't think radeons
> > typical do.  There's a #define in the code that can be enabled to get
> > more logging, but it's not terribly useful unless you know what you're
> > looking at.  VGA has plenty of issues with legacy PC address ranges that
> > are known problems, but there are also plenty of unknown problems that
> > make it a pretty difficult black box debugging project.  Thanks,
> >
> > Alex
> >
> >
> >
> 
> 

Re: [Qemu-devel] a user here - pci-assign

[lejeczek]

all these attempts and tests I've been doing in 
2.6.39-200.32.1.el6uek.x86_64(oracle)

now when I try rhel 2.6.32-279.5.1.el6.x86_64(everything 
else, hw&soft stay the same) I get:
,for win7-64 guest:

pci-stub 0000:26:00.0: irq 104 for MSI/MSI-X
pci-stub 0000:26:00.0: restoring config space at offset 0x1 
(was 0x100400, writing 0x100407)
pci-stub 0000:26:00.0: irq 104 for MSI/MSI-X
pci-stub 0000:26:00.0: irq 104 for MSI/MSI-X
pci-stub 0000:26:00.0: irq 104 for MSI/MSI-X
pci-stub 0000:26:00.0: irq 104 for MSI/MSI-X
do_IRQ: 12.146 No irq handler for vector (irq -1)

and the guest(win7-64) hans/freezes on boot, no devices 
passed/assigned - guest boots up fine
whereas XP-32-bit stays OK for both with device passed and 
without

can this be helped?



On 01/10/12 12:10, lejeczek wrote:
> hmm, still cannot get readon 5450 to work on win7-64, have 
> changed -cpu to host but no fix
> no vfio in qemu-kvm-0.12.1.2-2.295.el6_3.2.x86_64
> yes, I do blacklist modules at grub level and later in 
> modprobe also
>
> is primary/secondary VGA setup somehow helped by 
> qemu/components? in guest I can do anything since device 
> is disabled.
>
> pci-assign.multifunction=on/off - that would be the case 
> with VGAs like radeon and nvidia - audio part - is it 
> optional or always has to be ON for such devices?
>
> where one gets hold of information like: addr= ?
> I understand these are needed only! if pci-assign.host is 
> not enough and qemu has no way of knowing/finding it, when 
> may this happen?
>
> many thanks
>
>
> On 28/09/12 20:48, Alex Williamson wrote:
>> On Fri, 2012-09-28 at 19:46 +0100, lejeczek wrote:
>>> thanks Alex for your patience, appreciate it I do
>>>
>>> what would be the droids I need?
>>> I'm experiencing guests' "puzzling" behavior and was
>>> suggested that command line arguments were 
>>> wrong/incomplete.
>>>
>>> same box/hardware and radeon 5450 and ...
>>> - winXP-32bit -> OK - I assumed getting the guest on a
>>> external computer monitor was an ultimate test
>>> - win7-64bit -> OS reports device as disabled cause the
>>> device reported an error
>> I've had this same card working with both of these 
>> guests.  I believe
>> one trick on win7 was to use -cpu host.  Also, don't try 
>> to disable the
>> emulated vga device, just set it up like a dual-head 
>> system. Once you
>> load the catalyst driver windows will switch to use the 
>> assigned device
>> exclusively.  I was using the new vfio assignment driver, 
>> but someone
>> else recently report it working with the existing driver 
>> as well.  The
>> 5450 should be a secondary graphics card on the host 
>> system, trying to
>> assign the primary graphics is going to cause more 
>> problems. Also
>> blacklist the radeon driver on the host, we don't need 
>> any leftover
>> state from the Linux driver causing problems since most 
>> of these
>> graphics cards don't support a reset mechanism.
>>
>>> same box as above and geforce gt640 and ..
>>> for both XP and 7 report device with exclamation marks 
>>> (thus
>>> did not even bother to connect any screens like in working
>>> case with XP & radeon)
>> I don't think we've seen any reports yet of Nvidia cards 
>> working,
>> there's another thread on the kvm list speculating at 
>> some of the
>> problems.
>>
>>> I'll try to get hold of ROMs of the cards, meanwhile, how
>>> can I troubleshoot it? how to get more verbose feedback and
>>> what to specifically look for?
>> ROMs are only going to help if you're getting errors 
>> trying to read the
>> ROM.  Nvidia seems to have this problem, but I don't 
>> think radeons
>> typical do.  There's a #define in the code that can be 
>> enabled to get
>> more logging, but it's not terribly useful unless you 
>> know what you're
>> looking at.  VGA has plenty of issues with legacy PC 
>> address ranges that
>> are known problems, but there are also plenty of unknown 
>> problems that
>> make it a pretty difficult black box debugging project.  
>> Thanks,
>>
>> Alex
>>
>>
>>
>
>
>

Re: [Qemu-devel] a user here - pci-assign

[lejeczek]

rhel in general seem reluctant, I filed a bug a few days ago 
and although I believe there is problem with repo's version 
of seabios as soon as I mentioned VGA report was closed as 
'wontfix'
and I would still prefer them over Oracle, sometimes I 
wonder why..

On 01/10/12 14:51, Alex Williamson wrote:
> On Mon, 2012-10-01 at 12:10 +0100, lejeczek wrote:
>> hmm, still cannot get readon 5450 to work on win7-64, have
>> changed -cpu to host but no fix
>> no vfio in qemu-kvm-0.12.1.2-2.295.el6_3.2.x86_64
>> yes, I do blacklist modules at grub level and later in
>> modprobe also
> You probably want to try newer upstream code.  RHEL does not currently
> support assignment of VGA.
>
>> is primary/secondary VGA setup somehow helped by
>> qemu/components? in guest I can do anything since device is
>> disabled.
>>
>> pci-assign.multifunction=on/off - that would be the case
>> with VGAs like radeon and nvidia - audio part - is it
>> optional or always has to be ON for such devices?
> Optional
>
>> where one gets hold of information like: addr= ?
>> I understand these are needed only! if pci-assign.host is
>> not enough and qemu has no way of knowing/finding it, when
>> may this happen?
> This is not going to help you.  It's a matter of finding a free slot,
> which qemu can do fine on it's own if you don't want to specify.
> Thanks,
>
> Alex
>
>> On 28/09/12 20:48, Alex Williamson wrote:
>>> On Fri, 2012-09-28 at 19:46 +0100, lejeczek wrote:
>>>> thanks Alex for your patience, appreciate it I do
>>>>
>>>> what would be the droids I need?
>>>> I'm experiencing guests' "puzzling" behavior and was
>>>> suggested that command line arguments were wrong/incomplete.
>>>>
>>>> same box/hardware and radeon 5450 and ...
>>>> - winXP-32bit -> OK - I assumed getting the guest on a
>>>> external computer monitor was an ultimate test
>>>> - win7-64bit -> OS reports device as disabled cause the
>>>> device reported an error
>>> I've had this same card working with both of these guests.  I believe
>>> one trick on win7 was to use -cpu host.  Also, don't try to disable the
>>> emulated vga device, just set it up like a dual-head system.  Once you
>>> load the catalyst driver windows will switch to use the assigned device
>>> exclusively.  I was using the new vfio assignment driver, but someone
>>> else recently report it working with the existing driver as well.  The
>>> 5450 should be a secondary graphics card on the host system, trying to
>>> assign the primary graphics is going to cause more problems.  Also
>>> blacklist the radeon driver on the host, we don't need any leftover
>>> state from the Linux driver causing problems since most of these
>>> graphics cards don't support a reset mechanism.
>>>
>>>> same box as above and geforce gt640 and ..
>>>> for both XP and 7 report device with exclamation marks (thus
>>>> did not even bother to connect any screens like in working
>>>> case with XP & radeon)
>>> I don't think we've seen any reports yet of Nvidia cards working,
>>> there's another thread on the kvm list speculating at some of the
>>> problems.
>>>
>>>> I'll try to get hold of ROMs of the cards, meanwhile, how
>>>> can I troubleshoot it? how to get more verbose feedback and
>>>> what to specifically look for?
>>> ROMs are only going to help if you're getting errors trying to read the
>>> ROM.  Nvidia seems to have this problem, but I don't think radeons
>>> typical do.  There's a #define in the code that can be enabled to get
>>> more logging, but it's not terribly useful unless you know what you're
>>> looking at.  VGA has plenty of issues with legacy PC address ranges that
>>> are known problems, but there are also plenty of unknown problems that
>>> make it a pretty difficult black box debugging project.  Thanks,
>>>
>>> Alex
>>>
>>>
>>>
>>
>
>
>
>

Re: [Qemu-devel] a user here - pci-assign

[Michael Roth]

On Tue, Oct 02, 2012 at 08:46:32AM +0100, lejeczek wrote:
> rhel in general seem reluctant, I filed a bug a few days ago and
> although I believe there is problem with repo's version of seabios
> as soon as I mentioned VGA report was closed as 'wontfix'
> and I would still prefer them over Oracle, sometimes I wonder why..

If we can get it fixed upstream they'll pick it up eventually. Can you
confirm the problem exists with the latest upstream qemu code?

> 
> On 01/10/12 14:51, Alex Williamson wrote:
> >On Mon, 2012-10-01 at 12:10 +0100, lejeczek wrote:
> >>hmm, still cannot get readon 5450 to work on win7-64, have
> >>changed -cpu to host but no fix
> >>no vfio in qemu-kvm-0.12.1.2-2.295.el6_3.2.x86_64
> >>yes, I do blacklist modules at grub level and later in
> >>modprobe also
> >You probably want to try newer upstream code.  RHEL does not currently
> >support assignment of VGA.
> >
> >>is primary/secondary VGA setup somehow helped by
> >>qemu/components? in guest I can do anything since device is
> >>disabled.
> >>
> >>pci-assign.multifunction=on/off - that would be the case
> >>with VGAs like radeon and nvidia - audio part - is it
> >>optional or always has to be ON for such devices?
> >Optional
> >
> >>where one gets hold of information like: addr= ?
> >>I understand these are needed only! if pci-assign.host is
> >>not enough and qemu has no way of knowing/finding it, when
> >>may this happen?
> >This is not going to help you.  It's a matter of finding a free slot,
> >which qemu can do fine on it's own if you don't want to specify.
> >Thanks,
> >
> >Alex
> >
> >>On 28/09/12 20:48, Alex Williamson wrote:
> >>>On Fri, 2012-09-28 at 19:46 +0100, lejeczek wrote:
> >>>>thanks Alex for your patience, appreciate it I do
> >>>>
> >>>>what would be the droids I need?
> >>>>I'm experiencing guests' "puzzling" behavior and was
> >>>>suggested that command line arguments were wrong/incomplete.
> >>>>
> >>>>same box/hardware and radeon 5450 and ...
> >>>>- winXP-32bit -> OK - I assumed getting the guest on a
> >>>>external computer monitor was an ultimate test
> >>>>- win7-64bit -> OS reports device as disabled cause the
> >>>>device reported an error
> >>>I've had this same card working with both of these guests.  I believe
> >>>one trick on win7 was to use -cpu host.  Also, don't try to disable the
> >>>emulated vga device, just set it up like a dual-head system.  Once you
> >>>load the catalyst driver windows will switch to use the assigned device
> >>>exclusively.  I was using the new vfio assignment driver, but someone
> >>>else recently report it working with the existing driver as well.  The
> >>>5450 should be a secondary graphics card on the host system, trying to
> >>>assign the primary graphics is going to cause more problems.  Also
> >>>blacklist the radeon driver on the host, we don't need any leftover
> >>>state from the Linux driver causing problems since most of these
> >>>graphics cards don't support a reset mechanism.
> >>>
> >>>>same box as above and geforce gt640 and ..
> >>>>for both XP and 7 report device with exclamation marks (thus
> >>>>did not even bother to connect any screens like in working
> >>>>case with XP & radeon)
> >>>I don't think we've seen any reports yet of Nvidia cards working,
> >>>there's another thread on the kvm list speculating at some of the
> >>>problems.
> >>>
> >>>>I'll try to get hold of ROMs of the cards, meanwhile, how
> >>>>can I troubleshoot it? how to get more verbose feedback and
> >>>>what to specifically look for?
> >>>ROMs are only going to help if you're getting errors trying to read the
> >>>ROM.  Nvidia seems to have this problem, but I don't think radeons
> >>>typical do.  There's a #define in the code that can be enabled to get
> >>>more logging, but it's not terribly useful unless you know what you're
> >>>looking at.  VGA has plenty of issues with legacy PC address ranges that
> >>>are known problems, but there are also plenty of unknown problems that
> >>>make it a pretty difficult black box debugging project.  Thanks,
> >>>
> >>>Alex
> >>>
> >>>
> >>>
> >>
> >
> >
> >
> >
> 
> 

Re: [Qemu-devel] a user here - pci-assign

[lejeczek]

I cannot tell anything about upsteam, I'm going to try it 
out now, but in general I tend to stay as close to 
distro/yum version as possible,
so for 6.3 rhel it is tedious way of grabbing and compiling 
everything that is needed
where it seems RHEL stands it the reservation that VGA 
pass-though is not supported full stop
all I was saying was that their seabios might be worth 
looking into/updating as slightly higher rev of it solved my 
problem as described in
https://bugzilla.redhat.com/show_bug.cgi?id=860418


On 02/10/12 16:33, Michael Roth wrote:
> On Tue, Oct 02, 2012 at 08:46:32AM +0100, lejeczek wrote:
>> rhel in general seem reluctant, I filed a bug a few days ago and
>> although I believe there is problem with repo's version of seabios
>> as soon as I mentioned VGA report was closed as 'wontfix'
>> and I would still prefer them over Oracle, sometimes I wonder why..
> If we can get it fixed upstream they'll pick it up eventually. Can you
> confirm the problem exists with the latest upstream qemu code?
>
>> On 01/10/12 14:51, Alex Williamson wrote:
>>> On Mon, 2012-10-01 at 12:10 +0100, lejeczek wrote:
>>>> hmm, still cannot get readon 5450 to work on win7-64, have
>>>> changed -cpu to host but no fix
>>>> no vfio in qemu-kvm-0.12.1.2-2.295.el6_3.2.x86_64
>>>> yes, I do blacklist modules at grub level and later in
>>>> modprobe also
>>> You probably want to try newer upstream code.  RHEL does not currently
>>> support assignment of VGA.
>>>
>>>> is primary/secondary VGA setup somehow helped by
>>>> qemu/components? in guest I can do anything since device is
>>>> disabled.
>>>>
>>>> pci-assign.multifunction=on/off - that would be the case
>>>> with VGAs like radeon and nvidia - audio part - is it
>>>> optional or always has to be ON for such devices?
>>> Optional
>>>
>>>> where one gets hold of information like: addr= ?
>>>> I understand these are needed only! if pci-assign.host is
>>>> not enough and qemu has no way of knowing/finding it, when
>>>> may this happen?
>>> This is not going to help you.  It's a matter of finding a free slot,
>>> which qemu can do fine on it's own if you don't want to specify.
>>> Thanks,
>>>
>>> Alex
>>>
>>>> On 28/09/12 20:48, Alex Williamson wrote:
>>>>> On Fri, 2012-09-28 at 19:46 +0100, lejeczek wrote:
>>>>>> thanks Alex for your patience, appreciate it I do
>>>>>>
>>>>>> what would be the droids I need?
>>>>>> I'm experiencing guests' "puzzling" behavior and was
>>>>>> suggested that command line arguments were wrong/incomplete.
>>>>>>
>>>>>> same box/hardware and radeon 5450 and ...
>>>>>> - winXP-32bit -> OK - I assumed getting the guest on a
>>>>>> external computer monitor was an ultimate test
>>>>>> - win7-64bit -> OS reports device as disabled cause the
>>>>>> device reported an error
>>>>> I've had this same card working with both of these guests.  I believe
>>>>> one trick on win7 was to use -cpu host.  Also, don't try to disable the
>>>>> emulated vga device, just set it up like a dual-head system.  Once you
>>>>> load the catalyst driver windows will switch to use the assigned device
>>>>> exclusively.  I was using the new vfio assignment driver, but someone
>>>>> else recently report it working with the existing driver as well.  The
>>>>> 5450 should be a secondary graphics card on the host system, trying to
>>>>> assign the primary graphics is going to cause more problems.  Also
>>>>> blacklist the radeon driver on the host, we don't need any leftover
>>>>> state from the Linux driver causing problems since most of these
>>>>> graphics cards don't support a reset mechanism.
>>>>>
>>>>>> same box as above and geforce gt640 and ..
>>>>>> for both XP and 7 report device with exclamation marks (thus
>>>>>> did not even bother to connect any screens like in working
>>>>>> case with XP & radeon)
>>>>> I don't think we've seen any reports yet of Nvidia cards working,
>>>>> there's another thread on the kvm list speculating at some of the
>>>>> problems.
>>>>>
>>>>>> I'll try to get hold of ROMs of the cards, meanwhile, how
>>>>>> can I troubleshoot it? how to get more verbose feedback and
>>>>>> what to specifically look for?
>>>>> ROMs are only going to help if you're getting errors trying to read the
>>>>> ROM.  Nvidia seems to have this problem, but I don't think radeons
>>>>> typical do.  There's a #define in the code that can be enabled to get
>>>>> more logging, but it's not terribly useful unless you know what you're
>>>>> looking at.  VGA has plenty of issues with legacy PC address ranges that
>>>>> are known problems, but there are also plenty of unknown problems that
>>>>> make it a pretty difficult black box debugging project.  Thanks,
>>>>>
>>>>> Alex
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>>
>

Re: [Qemu-devel] a user here - pci-assign

[Alex Williamson]

On Wed, 2012-10-03 at 15:30 +0100, lejeczek wrote:
> I cannot tell anything about upsteam, I'm going to try it 
> out now, but in general I tend to stay as close to 
> distro/yum version as possible,
> so for 6.3 rhel it is tedious way of grabbing and compiling 
> everything that is needed
> where it seems RHEL stands it the reservation that VGA 
> pass-though is not supported full stop
> all I was saying was that their seabios might be worth 
> looking into/updating as slightly higher rev of it solved my 
> problem as described in
> https://bugzilla.redhat.com/show_bug.cgi?id=860418

I do apologize if I was abrupt in closing that bug, but it needs to work
upstream first.  We've had a couple reports of some cards working, but
nothing worth declaring success, backporting and trying to call it
supported.  If a seabios update improves things for you, please report
it and maybe there are changes we can backport.  Personally I'd prefer
to see it working reliably upstream first and incorporate a full
solution rather than hearsay that card A worked on system B at least
once.  Thanks,

Alex

[Qemu-devel] a user here - pci-assign VGA

[lejeczek]

hi there, I wanted to share some fairly good news
a while ago when as was battling the problem - pci-assign a 
vga - I got it to work
I realized that it might have worked from the beginning, anyhow,
for me it works now with qemu-kvm 1.2 (which is fedora alpha 
rpm-rebuilt on SL 6.3) with various AMD vgas
but! (there is always a but, isn't there :) )
guest loses vnc?? meaning that VNC gets only blank(black 
screen (this was what deceived me earlier))
whereas guest seems to fine itself, I can rdp to it (it's 
win7), I can get it on a directly attached monitor via 
keyboard + mouse attached in the same fashion
only win device manager shows "Standard VGA Graphic Adapter" 
exclamation marked. (I tied both -vga cirrus and -vga std)

would anybody know how to fix/troubleshoot it?
many thanks

On 03/10/12 15:46, Alex Williamson wrote:
> On Wed, 2012-10-03 at 15:30 +0100, lejeczek wrote:
>> I cannot tell anything about upsteam, I'm going to try it
>> out now, but in general I tend to stay as close to
>> distro/yum version as possible,
>> so for 6.3 rhel it is tedious way of grabbing and compiling
>> everything that is needed
>> where it seems RHEL stands it the reservation that VGA
>> pass-though is not supported full stop
>> all I was saying was that their seabios might be worth
>> looking into/updating as slightly higher rev of it solved my
>> problem as described in
>> https://bugzilla.redhat.com/show_bug.cgi?id=860418
> I do apologize if I was abrupt in closing that bug, but it needs to work
> upstream first.  We've had a couple reports of some cards working, but
> nothing worth declaring success, backporting and trying to call it
> supported.  If a seabios update improves things for you, please report
> it and maybe there are changes we can backport.  Personally I'd prefer
> to see it working reliably upstream first and incorporate a full
> solution rather than hearsay that card A worked on system B at least
> once.  Thanks,
>
> Alex
>
>
>