qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Michael Roth
Subject: Re: [Qemu-devel] a user here - pci-assign
Date: Tue, 2 Oct 2012 10:33:14 -0500
User-agent: Mutt/1.5.21 (2010-09-15)

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]