qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
* [Qemu-devel] seccomp raises on mesa pthread_setaffinity_np()
@ 2019-02-22  8:04 Marc-André Lureau
  2019-02-27 11:45 ` Daniel P. Berrangé
  0 siblings, 1 reply; 2+ messages in thread
From: Marc-André Lureau @ 2019-02-22  8:04 UTC (permalink / raw)
  To: QEMU, Gerd Hoffmann, Eduardo Otubo

Hi,

We have another seccomp issue with mesa, leading to SIGSYS bad system
call (when running a virgl VM with libvirt for example)

Since commit :
https://gitlab.freedesktop.org/mesa/mesa/commit/d877451b48a59ab0f9a4210fc736f51da5851c9a
(unfortunately, already in f29)

mesa wants to set its thread affinity on all CPU, but I am not sure
how we can limit the rule to the mesa threads yet... any ideas?

Another reason to consider vhost-user-gpu, to simplify the seccomp rules!

-- 
Marc-André Lureau

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [Qemu-devel] seccomp raises on mesa pthread_setaffinity_np()
  2019-02-22  8:04 [Qemu-devel] seccomp raises on mesa pthread_setaffinity_np() Marc-André Lureau
@ 2019-02-27 11:45 ` Daniel P. Berrangé
  0 siblings, 0 replies; 2+ messages in thread
From: Daniel P. Berrangé @ 2019-02-27 11:45 UTC (permalink / raw)
  To: Marc-André Lureau; +Cc: QEMU, Gerd Hoffmann, Eduardo Otubo

On Fri, Feb 22, 2019 at 09:04:53AM +0100, Marc-André Lureau wrote:
> Hi,
> 
> We have another seccomp issue with mesa, leading to SIGSYS bad system
> call (when running a virgl VM with libvirt for example)

To close the circle, this is now also reported on launchpad

https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1815889

> Since commit :
> https://gitlab.freedesktop.org/mesa/mesa/commit/d877451b48a59ab0f9a4210fc736f51da5851c9a
> (unfortunately, already in f29)
> 
> mesa wants to set its thread affinity on all CPU, but I am not sure
> how we can limit the rule to the mesa threads yet... any ideas?

Per my comment on the bug, I think this is not a good default behaviour
for Mesa. It should honour the affinity of the process that is running,
because if that has been given restrictive CPU affinity it is precisely
because the admin or mgmt app doesn't want it to use all CPUs. Mesa
shouldn't unconditionally undo that decision.

> Another reason to consider vhost-user-gpu, to simplify the seccomp rules!

I don't think that's going to help because if anything I expect seccomp
rules to be more restrictive for the vhost processes as they are tailored
to specific functional niches. Even if in a separate process libvirt will
still not want mesa to violate the CPU affinity it has configured. It must
honour what the process was given.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2019-02-27 11:45 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-02-22  8:04 [Qemu-devel] seccomp raises on mesa pthread_setaffinity_np() Marc-André Lureau
2019-02-27 11:45 ` Daniel P. Berrangé

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