Update: I've figured it out.
The bug here was that, even running as root, I was getting errors like:
error : virQEMUCapsNewForBinaryInternal:4687 : internal error: Failed to
probe QEMU binary with
QMP: libvirt: error : prctl failed to enable 'dac_override' in the
AMBIENT set:
Operation not
Daniel P. Berrangé wrote:
> On Thu, Jan 31, 2019 at 04:41:23PM +0400, Roman Bogorodskiy wrote:
> > Roman Bogorodskiy (3):
> > bhyve: bhyveDomainDefNamespaceFormatXML cleanup
> > bhyve: emit warning when using bhyve:commandline
> > docs: bhyve: warn about bhyve:commandline risks
> >
> >
On 1/25/19 5:48 PM, Eric Blake wrote:
> The existing qemu-nbd --partition code claims to handle logical
> partitions up to 8, since its introduction in 2008 (commit 7a5ca86).
> However, the implementation is bogus (actual MBR logical partitions
> form a sort of linked list, with one partition per
Hi,
I'm facing a strange behavior when running Libvirt from source code,
latest upstream, on an Ubuntu 18.04.1 LTS Power 9 server. My QEMU
guest - which is using VFIO and GPU passthrough - breaks on boot when
trying to allocate a DMA window inside KVM.
Debugging the code, I've found out that
On Fri, Feb 01, 2019 at 06:00:37PM +0100, Peter Krempa wrote:
> In commit f80eae8c2ae I was too agresive in removing properties of
> -drive for empty drives. It turns out that qemu actually persists the
> state of 'readonly' and the throttling information even for the empty
> drive.
>
> Removing
Signed-off-by: John Ferlan
---
pushed as build breaker ...
src/util/virstoragefile.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/util/virstoragefile.c b/src/util/virstoragefile.c
index d83d84fcf5..6df0885669 100644
--- a/src/util/virstoragefile.c
+++
In commit f80eae8c2ae I was too agresive in removing properties of
-drive for empty drives. It turns out that qemu actually persists the
state of 'readonly' and the throttling information even for the empty
drive.
Removing 'readonly' thus made qemu open any subsequent images added via
the
On 1/31/19 8:42 AM, Peter Krempa wrote:
Subject: s/neiter/neither/
Long line; maybe:
qemu: domain: Use 'raw' for 'volume' disks without format
> Storage pools might want to specify format of the image when translating
> the volume thus we can't add any default format when parsing the XML.
>
>
are available in the git repository at:
>
> git://git.kraxel.org/qemu tags/ui-20190201-pull-request
>
> for you to fetch changes up to 0015ca5cbabe0b31d31610ddfaafd90a9e5911a4:
>
> ui: remove support for SDL1.2 in
On Fri, Feb 01, 2019 at 01:53:47PM +0100, Andrea Bolognani wrote:
> On Fri, 2019-02-01 at 13:07 +0100, Erik Skultety wrote:
> [...]
> > + By default, libvirt runs the QEMU process as qemu:qemu which
> > could
> > + cause issues during probing as some features (like AMD SEV)
> >
On 2/1/19 8:49 AM, Laine Stump wrote:
On 2/1/19 8:28 AM, Eric Garver wrote:
On Thu, Jan 31, 2019 at 10:10:43PM -0500, Laine Stump wrote:
On 1/31/19 8:24 PM, Laine Stump wrote:
Changes from V1:
[...]
* make the rule's priority 32767 instead of 127.
[...]
+
+
+
+
I found out after sending
On Thu, Jan 31, 2019 at 03:42:53PM +0100, Peter Krempa wrote:
Peter Krempa (3):
tests: qemu: Test network disks without format specified explicitly
qemu: domain: Assume 'raw' default storage format also for network
storage
qemu: domain: Treat 'volume' disks as 'raw' if neiter user nor pool
On Fri, Feb 01, 2019 at 10:10:21AM -0500, Laine Stump wrote:
> On 2/1/19 8:24 AM, Daniel P. Berrangé wrote:
> > On Thu, Jan 31, 2019 at 08:24:56PM -0500, Laine Stump wrote:
> > > From: Laine Stump
> > >
> > > This patch restores broken guest network connectivity after a host
> > > firewalld is
On Fri, Jan 18, 2019 at 09:42:37AM -0500, John Ferlan wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=1657468
Commit be1bb6c95 changed the way volumes were stored from a forward
linked list to a hash table. In doing so, it required that each vol
object would have 3 unique values as keys into
On Fri, Feb 01, 2019 at 10:06:44AM -0500, Laine Stump wrote:
> On 2/1/19 8:17 AM, Daniel P. Berrangé wrote:
> > On Thu, Jan 31, 2019 at 08:24:54PM -0500, Laine Stump wrote:
> > > +int
> > > +virFirewallDGetBackend(void)
> > > +{
> > > +DBusConnection *sysbus = virDBusGetSystemBus();
> > > +
On 2/1/19 8:24 AM, Daniel P. Berrangé wrote:
On Thu, Jan 31, 2019 at 08:24:56PM -0500, Laine Stump wrote:
From: Laine Stump
This patch restores broken guest network connectivity after a host
firewalld is switched to using an nftables backend. It does this by
adding libvirt networks' bridge
On 2/1/19 8:17 AM, Daniel P. Berrangé wrote:
On Thu, Jan 31, 2019 at 08:24:54PM -0500, Laine Stump wrote:
+int
+virFirewallDGetBackend(void)
+{
+DBusConnection *sysbus = virDBusGetSystemBus();
+DBusMessage *reply = NULL;
+virError error;
+VIR_AUTOFREE(char *) backendStr = NULL;
On Tue, Jan 29, 2019 at 03:54:42PM +0100, Michal Privoznik wrote:
On 1/18/19 3:42 PM, John Ferlan wrote:
The vHBA/NPIV LUNs created via the udev processing of the
VPORT_CREATE command end up using the same serial value
as seen/generated by the /lib/udev/scsi_id as returned
during
On Wed, Jan 30, 2019 at 11:55:10AM -0500, John Ferlan wrote:
On 1/29/19 10:14 AM, Ján Tomko wrote:
On Fri, Jan 18, 2019 at 09:42:35AM -0500, John Ferlan wrote:
Alter the code to use the virStorageFileGetSCSIKey helper
to fetch the unique key for the SCSI disk. Alter the logic
to follow the
On Fri, Jan 18, 2019 at 09:42:34AM -0500, John Ferlan wrote:
Alter the "real" code to return -2 on virCommandRun failure.
Alter the comments and function header to describe the function
and it's returns.
*its
Signed-off-by: John Ferlan
---
src/util/virstoragefile.c | 21
On 2/1/19 8:28 AM, Eric Garver wrote:
On Thu, Jan 31, 2019 at 10:10:43PM -0500, Laine Stump wrote:
On 1/31/19 8:24 PM, Laine Stump wrote:
Changes from V1:
[...]
* make the rule's priority 32767 instead of 127.
[...]
+
+
+
+
I found out after sending this that when I make the priority of
On Thu, Jan 31, 2019 at 08:24:57PM -0500, Laine Stump wrote:
> Since we're setting the zone anyway, it will be useful to allow
> setting a different (custom) zone for each network. This will be done
> by adding a "zone" attribute to the "bridge" element, e.g.:
>
>...
>
>...
>
> If a
On Thu, Jan 31, 2019 at 08:24:58PM -0500, Laine Stump wrote:
> Signed-off-by: Laine Stump
> ---
>
> New in V2. Split off from previous patch.
>
> docs/news.xml | 40
> 1 file changed, 40 insertions(+)
Reviewed-by: Daniel P. Berrangé
Regards,
Daniel
On Thu, Jan 31, 2019 at 10:10:43PM -0500, Laine Stump wrote:
> On 1/31/19 8:24 PM, Laine Stump wrote:
> > Changes from V1:
> > [...]
>
> > * make the rule's priority 32767 instead of 127.
> > [...]
>
> > +
> > +
> > +
> > +
>
>
> I found out after sending this that when I make the priority
On Thu, Jan 31, 2019 at 10:10:43PM -0500, Laine Stump wrote:
> On 1/31/19 8:24 PM, Laine Stump wrote:
> > Changes from V1:
> > [...]
>
> > * make the rule's priority 32767 instead of 127.
> > [...]
>
> > +
> > +
> > +
> > +
>
>
> I found out after sending this that when I make the priority
On Thu, Jan 31, 2019 at 08:24:56PM -0500, Laine Stump wrote:
> From: Laine Stump
>
> This patch restores broken guest network connectivity after a host
> firewalld is switched to using an nftables backend. It does this by
> adding libvirt networks' bridge interfaces to the new "libvirt" zone
>
On Thu, Jan 31, 2019 at 08:24:55PM -0500, Laine Stump wrote:
> In the past (when both libvirt and firewalld used iptables), if either
> libvirt's rules *OR* firewalld's rules accepted a packet, it would
> be accepted. This was because libvirt and firewalld rules were
> processed during the same
On Thu, Jan 31, 2019 at 08:24:54PM -0500, Laine Stump wrote:
> virFirewallDGetBackend() reports whether firewalld is currently using
> an iptables or an nftables backend.
>
> virFirewallDGetVersion() learns the version of the firewalld running
> on this system and returns it as 100*major +
On Thu, Jan 31, 2019 at 08:24:53PM -0500, Laine Stump wrote:
> In preparation for adding several other firewalld-specific functions,
> separate the code that's unique to firewalld from the more-generic
> "firewall" file.
>
> Signed-off-by: Laine Stump
> ---
>
> Change from V1: define
On Thu, Jan 31, 2019 at 08:24:52PM -0500, Laine Stump wrote:
> Support for firewalld is a feature that can be selectively enabled or
> disabled (using --with-firewalld/--without-firewalld), not merely
> something that must be accounted for in the code if it is present with
> no exceptions. It is
>> This is all greek to me. I take it there's something wrong with these
>> accelerators that makes (read-only?) flash memory not work, even
>> though the read-only mapping we now create for traditional BIOS works.
>> Weird, but I'm of course willing to take your word for it.
> Yes, as I
> -Original Message-
> From: Paolo Bonzini [mailto:pbonz...@redhat.com]
> Sent: Friday, February 1, 2019 7:55
> To: Alexandro Sanchez Bach ; 'Markus Armbruster'
>
> Cc: 'Peter Maydell' ; 'Peter Krempa'
> ; 'Qemu-block' ; 'Libvirt'
> ; 'QEMU Developers' ;
> 'László Érsek' ; 'Justin Terry
On Fri, 2019-02-01 at 13:07 +0100, Erik Skultety wrote:
[...]
> + By default, libvirt runs the QEMU process as qemu:qemu which could
> + cause issues during probing as some features (like AMD SEV) might
> be
> + inaccesible to QEMU because of file system permissions.
Am 25.01.2019 um 18:46 hat Kevin Wolf geschrieben:
> The vendor specific designator in the Device Identification VPD page has
> two problems:
>
> 1. It defaults to the BlockBackend name (-drive id=...), which everyone
>expected to be a host detail that the guest never sees
>
> 2. With
From: Daniel P. Berrangé
SDL1.2 was deprecated in the 2.12.0 release with:
commit e52c6ba34149b4f39c3fd60e59ee32b809db2bfa
Author: Daniel P. Berrange
Date: Mon Jan 15 14:25:33 2018 +
ui: deprecate use of SDL 1.2 in favour of 2.0 series
The SDL 2.0 release was made in Aug,
From: Philippe Mathieu-Daudé
Commit 5f9b1e35060b8 remove the dependency between OpenGL and X11.
However the milkymist-tmu2 device do require X11.
When using SDL, the configure script sets need_x11=yes, so the X11
flags are populated to the makefiles.
When building without SDL, X11 is not pulled
From: Philippe Mathieu-Daudé
Move the complexity of milkymist_tmu2_create() into the
source file. Doing so we avoid to include the X11/OpenGL
headers in all LM32 devices, and we also avoid the duplicate
declaration of glx_fbconfig_attr[] (it is already declared
in hw/display/milkymist-tmu2.c).
From: Philippe Mathieu-Daudé
The Milkymist specific hardware is only used by the LM32 target,
it is pointless to compile those objects in other targets.
Signed-off-by: Philippe Mathieu-Daudé
Message-id: 20190130120005.23123-2-phi...@redhat.com
Signed-off-by: Gerd Hoffmann
---
From: Philippe Mathieu-Daudé
The TMU device requires both X11 and OpenGL.
Signed-off-by: Philippe Mathieu-Daudé
Message-id: 20190130120005.23123-4-phi...@redhat.com
Signed-off-by: Gerd Hoffmann
---
hw/lm32/milkymist-hw.h | 4 ++--
default-configs/lm32-softmmu.mak | 2 +-
The following changes since commit e8977901b79fb678f288dd372261b640bbeccd0d:
Merge remote-tracking branch
'remotes/vivier2/tags/trivial-branch-pull-request' into staging (2019-01-31
15:40:39 +)
are available in the git repository at:
git://git.kraxel.org/qemu tags/ui-20190201-pull
On Fri, 2019-02-01 at 12:14 +0100, Ján Tomko wrote:
> On Thu, Jan 31, 2019 at 02:22:48PM +0100, Andrea Bolognani wrote:
> > Commit fb0d0d6c5492 added capabilities data and updated
> > qemucapabilitiestest but forgot to update qemucaps2xmltest
> > at the same time.
> >
> > Signed-off-by: Andrea
Turns out different versions of QEMU on the same architecture
produce the same output, so we can have a single output file
per architecture instead of duplicating the same data over and
over again.
Spotted-by: Ján Tomko
Signed-off-by: Andrea Bolognani
---
...ps_2.10.0.aarch64.xml =>
Signed-off-by: Erik Skultety
---
docs/news.xml | 12
1 file changed, 12 insertions(+)
diff --git a/docs/news.xml b/docs/news.xml
index 55d6a3926b..fcc42698b3 100644
--- a/docs/news.xml
+++ b/docs/news.xml
@@ -50,6 +50,18 @@
+
+
+ qemu: Use
On Fri, Feb 01, 2019 at 12:33:19PM +0100, Erik Skultety wrote:
> On Fri, Feb 01, 2019 at 10:31:52AM +, Daniel P. Berrangé wrote:
> > On Thu, Jan 31, 2019 at 04:26:18PM +0100, Erik Skultety wrote:
> > > This is mainly about /dev/sev and its default permissions 0600. Of
> > > course, rule of
On Fri, Feb 01, 2019 at 10:31:52AM +, Daniel P. Berrangé wrote:
> On Thu, Jan 31, 2019 at 04:26:18PM +0100, Erik Skultety wrote:
> > This is mainly about /dev/sev and its default permissions 0600. Of
> > course, rule of 'tinfoil' would be that we can't trust anything, but the
> > probing code
On Thu, Jan 31, 2019 at 02:22:48PM +0100, Andrea Bolognani wrote:
Commit fb0d0d6c5492 added capabilities data and updated
qemucapabilitiestest but forgot to update qemucaps2xmltest
at the same time.
Signed-off-by: Andrea Bolognani
---
*cough* and of course the reviewer didn't notice *cough*
On Thu, Jan 31, 2019 at 04:26:18PM +0100, Erik Skultety wrote:
> This is mainly about /dev/sev and its default permissions 0600. Of
> course, rule of 'tinfoil' would be that we can't trust anything, but the
> probing code in QEMU is considered safe from security's perspective + we
> can't create
On Thu, Jan 31, 2019 at 04:26:17PM +0100, Erik Skultety wrote:
> The default permissions (0600 root:root) are of no use to the qemu
> process so we need to change the owner to qemu iff running with
> namespaces.
>
> Signed-off-by: Erik Skultety
> ---
> src/security/security_dac.c | 51
On Thu, Jan 31, 2019 at 04:26:16PM +0100, Erik Skultety wrote:
> Instead of exposing /dev/sev to every domain, do it selectively.
>
> Signed-off-by: Erik Skultety
> ---
> src/qemu/qemu_domain.c | 24
> 1 file changed, 24 insertions(+)
Reviewed-by: Daniel P. Berrangé
On Thu, Jan 31, 2019 at 04:26:14PM +0100, Erik Skultety wrote:
> We should not give domains access to something they don't necessarily
> need by default. Remove it from the qemu driver docs too.
>
> Signed-off-by: Erik Skultety
> ---
> docs/drvqemu.html.in | 2 +-
>
On Thu, Jan 31, 2019 at 04:26:15PM +0100, Erik Skultety wrote:
> SEV has a limit on number of concurrent guests. From security POV we
> should only expose resources (any resources for that matter) to domains
> that truly need them.
>
> Signed-off-by: Erik Skultety
> ---
> src/qemu/qemu_cgroup.c
On Thu, Jan 31, 2019 at 10:34:17AM +0100, Michal Privoznik wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=1503284
>
> The way we currently start qemu from CPU affinity POV is as
> follows:
>
> 1) the child process is set affinity to all online CPUs (unless
> some vcpu pinning was given
On Thu, 2019-01-31 at 17:32 +0100, Ján Tomko wrote:
> On Thu, Jan 31, 2019 at 03:34:20PM +0100, Andrea Bolognani wrote:
> > +++ b/tests/qemuxml2argvtest.c
> > @@ -3072,6 +3072,8 @@ mymain(void)
> >
> > DO_TEST("riscv64-virt",
> > QEMU_CAPS_DEVICE_VIRTIO_MMIO);
> > +
Paolo Bonzini writes:
> On 31/01/19 13:12, Markus Armbruster wrote:
>> Paolo Bonzini writes:
>>
>>> On 31/01/19 10:41, Markus Armbruster wrote:
Paolo Bonzini writes:
> On 31/01/19 09:40, Markus Armbruster wrote:
>>> Maybe we should just add pflash block properties to the
[Please use git send-email or a normal client, this attachment is difficult to
go through, not to mention that the diff is completely broken]
On Fri, Feb 01, 2019 at 08:16:20AM +, 吴 雨霖 wrote:
[Problem Description]
I read qemu-doc.texi in qemu-mster source code, which have a explain of
[Problem Description]
I read qemu-doc.texi in qemu-mster source code, which have a explain of
migrating ivshmem below
“With device property @option{master=on}, the guest will copy the shared.memory
on migration to the destination host. With @option{master=off}, the guest will
not be able
On 1/31/19 2:13 PM, Daniel P. Berrangé wrote:
> Newest GCC warns that the string copying is potentially truncated and
> thus not nul terminated.
>
> In file included from /usr/include/string.h:494,
> from ../../src/Virt_HostSystem.c:23:
> In function ‘strncpy’,
> inlined from
On 1/31/19 1:51 PM, Daniel P. Berrangé wrote:
> The schema files that we actually download & bundle in the tar.gz dist
> have removed the clause "for uses consistent with this purpose" which
> is good because that clause might be considered a distribution
> restriction which could make it a
[Problem Description]
I read qemu-doc.texi in qemu-mster source code, which have a explain of
migrating ivshmem below
“With device property @option{master=on}, the guest will copy the shared.memory
on migration to the destination host. With @option{master=off}, the guest will
not be able
59 matches
Mail list logo
