All of lore.kernel.org
 help / color / mirror / Atom feed
From: Henning Schild <henning.schild@siemens.com>
To: "Daniel P. Berrange" <berrange@redhat.com>
Cc: libvir-list@redhat.com, libvirt-users@redhat.com,
	qemu-devel@nongnu.org, qemu-discuss@nongnu.org
Subject: Re: [Qemu-devel] pci-assign fails with read error on config-space file
Date: Wed, 2 Nov 2016 12:45:17 +0100	[thread overview]
Message-ID: <20161102124517.2673fb35@md1em3qc> (raw)
In-Reply-To: <20161102095416.GA2573@redhat.com>

Am Wed, 2 Nov 2016 09:54:16 +0000
schrieb "Daniel P. Berrange" <berrange@redhat.com>:

> On Fri, Oct 28, 2016 at 01:28:19PM +0200, Henning Schild wrote:
> > Hey,
> > 
> > i am running an unusual setup where i assign pci devices behind the
> > back of libvirt. I have two options to do that:
> > 1. a wrapper script for qemu that takes care of suid-root and
> > appends arguments for pci-assign
> > 2. virsh qemu-monitor-command ... 'device_add pci-assign...'
> > 
> > I know i should probably not be doing this, it is a workaround to
> > introduce fine-grained pci-assignment in an openstack setup, where
> > vendor and device id are not enough to pick the right device for a
> > vm.
> > 
> > In both cases qemu will crash with the following output:
> >   
> > > qemu: hardware error: pci read failed, ret = 0 errno = 22  
> > 
> > followed by the usual machine state dump. With strace i found it to
> > be a failing read on the config space file of my device.
> > /sys/bus/pci/devices/0000:xx:xx.x/config
> > A few reads out of that file succeeded, as well as accesses on
> > vendor etc.  
> 
> errno == 22, means EINVAL, so it feels unlikely to be a permissions
> problem unless the kernel or QEMU is reporting the wrong errno.
> 
> > Manually launching a qemu with the pci-assign works without a
> > problem, so i "blame" libvirt and the cgroup environment the qemu
> > ends up in.  
> 
> The 'config' file is a plain file, so not affected by cgroups - that
> only affects block devices.
> 
> When libvirt runs QEMU, it runs unprivileged qemu:qemu user/group,
> so perhaps it is a permissions thing, despite the fact that you're
> getting EINVAL, not EACCESS.

If the wrapper qemu decides to assign a PCI device it will use a
suid-root qemu to do so. So it is no EACCESS, as i said other reads
worked fine.

> It would be interesting to know just what part of the config space
> QEMU was trying to read I guess, to better understand why it might
> be failing

I should have said that before, it is a one byte read on offest 64. So
just behind the regular cfg-space.

regards,
Henning

      reply	other threads:[~2016-11-02 11:44 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-28 11:28 [Qemu-devel] pci-assign fails with read error on config-space file Henning Schild
2016-10-28 15:22 ` Laszlo Ersek
2016-11-02  9:40   ` Henning Schild
2016-10-28 15:25 ` [Qemu-devel] [libvirt-users] " Laine Stump
2016-10-28 17:08   ` Alex Williamson
2016-11-02 10:34   ` Henning Schild
2016-11-02  9:54 ` [Qemu-devel] " Daniel P. Berrange
2016-11-02 11:45   ` Henning Schild [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20161102124517.2673fb35@md1em3qc \
    --to=henning.schild@siemens.com \
    --cc=berrange@redhat.com \
    --cc=libvir-list@redhat.com \
    --cc=libvirt-users@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-discuss@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.