* [Qemu-devel] a user here - pci-assign @ 2012-09-28 9:54 lejeczek 2012-09-28 16:05 ` Alex Williamson 0 siblings, 1 reply; 12+ messages in thread From: lejeczek @ 2012-09-28 9:54 UTC (permalink / raw) To: qemu-devel 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Qemu-devel] a user here - pci-assign 2012-09-28 9:54 [Qemu-devel] a user here - pci-assign lejeczek @ 2012-09-28 16:05 ` Alex Williamson 2012-09-28 18:46 ` lejeczek 0 siblings, 1 reply; 12+ messages in thread From: Alex Williamson @ 2012-09-28 16:05 UTC (permalink / raw) To: lejeczek; +Cc: qemu-devel 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Qemu-devel] a user here - pci-assign 2012-09-28 16:05 ` Alex Williamson @ 2012-09-28 18:46 ` lejeczek 2012-09-28 19:48 ` Alex Williamson 0 siblings, 1 reply; 12+ messages in thread From: lejeczek @ 2012-09-28 18:46 UTC (permalink / raw) To: qemu-devel 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 > > > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Qemu-devel] a user here - pci-assign 2012-09-28 18:46 ` lejeczek @ 2012-09-28 19:48 ` Alex Williamson 2012-10-01 11:10 ` lejeczek 0 siblings, 1 reply; 12+ messages in thread From: Alex Williamson @ 2012-09-28 19:48 UTC (permalink / raw) To: lejeczek; +Cc: qemu-devel 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Qemu-devel] a user here - pci-assign 2012-09-28 19:48 ` Alex Williamson @ 2012-10-01 11:10 ` lejeczek 2012-10-01 13:51 ` Alex Williamson 2012-10-01 14:04 ` [Qemu-devel] a user here - pci-assign lejeczek 0 siblings, 2 replies; 12+ messages in thread From: lejeczek @ 2012-10-01 11:10 UTC (permalink / raw) To: qemu-devel 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 > > > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Qemu-devel] a user here - pci-assign 2012-10-01 11:10 ` lejeczek @ 2012-10-01 13:51 ` Alex Williamson 2012-10-02 7:46 ` lejeczek 2012-10-01 14:04 ` [Qemu-devel] a user here - pci-assign lejeczek 1 sibling, 1 reply; 12+ messages in thread From: Alex Williamson @ 2012-10-01 13:51 UTC (permalink / raw) To: lejeczek; +Cc: qemu-devel 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 > > > > > > > > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Qemu-devel] a user here - pci-assign 2012-10-01 13:51 ` Alex Williamson @ 2012-10-02 7:46 ` lejeczek 2012-10-02 15:33 ` Michael Roth 0 siblings, 1 reply; 12+ messages in thread From: lejeczek @ 2012-10-02 7:46 UTC (permalink / raw) To: qemu-devel 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 >>> >>> >>> >> > > > > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Qemu-devel] a user here - pci-assign 2012-10-02 7:46 ` lejeczek @ 2012-10-02 15:33 ` Michael Roth 2012-10-03 14:30 ` lejeczek 0 siblings, 1 reply; 12+ messages in thread From: Michael Roth @ 2012-10-02 15:33 UTC (permalink / raw) To: lejeczek; +Cc: qemu-devel 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 > >>> > >>> > >>> > >> > > > > > > > > > > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Qemu-devel] a user here - pci-assign 2012-10-02 15:33 ` Michael Roth @ 2012-10-03 14:30 ` lejeczek 2012-10-03 14:46 ` Alex Williamson 0 siblings, 1 reply; 12+ messages in thread From: lejeczek @ 2012-10-03 14:30 UTC (permalink / raw) To: qemu-devel 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 >>>>> >>>>> >>>>> >>> >>> >>> >> > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Qemu-devel] a user here - pci-assign 2012-10-03 14:30 ` lejeczek @ 2012-10-03 14:46 ` Alex Williamson 2012-11-06 13:17 ` [Qemu-devel] a user here - pci-assign VGA lejeczek 0 siblings, 1 reply; 12+ messages in thread From: Alex Williamson @ 2012-10-03 14:46 UTC (permalink / raw) To: lejeczek; +Cc: qemu-devel 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* [Qemu-devel] a user here - pci-assign VGA 2012-10-03 14:46 ` Alex Williamson @ 2012-11-06 13:17 ` lejeczek 0 siblings, 0 replies; 12+ messages in thread From: lejeczek @ 2012-11-06 13:17 UTC (permalink / raw) To: qemu-devel 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 > > > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Qemu-devel] a user here - pci-assign 2012-10-01 11:10 ` lejeczek 2012-10-01 13:51 ` Alex Williamson @ 2012-10-01 14:04 ` lejeczek 1 sibling, 0 replies; 12+ messages in thread From: lejeczek @ 2012-10-01 14:04 UTC (permalink / raw) To: qemu-devel 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 >> >> >> > > > ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2012-11-06 13:17 UTC | newest] Thread overview: 12+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-09-28 9:54 [Qemu-devel] a user here - pci-assign lejeczek 2012-09-28 16:05 ` Alex Williamson 2012-09-28 18:46 ` lejeczek 2012-09-28 19:48 ` Alex Williamson 2012-10-01 11:10 ` lejeczek 2012-10-01 13:51 ` Alex Williamson 2012-10-02 7:46 ` lejeczek 2012-10-02 15:33 ` Michael Roth 2012-10-03 14:30 ` lejeczek 2012-10-03 14:46 ` Alex Williamson 2012-11-06 13:17 ` [Qemu-devel] a user here - pci-assign VGA lejeczek 2012-10-01 14:04 ` [Qemu-devel] a user here - pci-assign lejeczek
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).