Re: [libvirt] [qemu RFC] qapi: add "firmware.json"

On 04/10/18 09:33, Thomas Huth wrote: > On 09.04.2018 18:50, Laszlo Ersek wrote: >> On 04/09/18 10:19, Gerd Hoffmann wrote: > +{ 'enum' : 'SystemFirmwareType', > + 'data' : [ 'bios', 'slof', 'uboot', 'uefi' ] } The naming here is quite a bad mixture between firmware interface

Re: [libvirt] [Qemu-devel] [qemu RFC] qapi: add "firmware.json"

On 04/10/18 12:09, Paolo Bonzini wrote: > On 10/04/2018 11:23, Daniel P. Berrangé wrote: >>> And, really, this seems to reinforce my point that the schema should >>> live in the libvirtd tree, not in the QEMU tree. In that case, perhaps >>> it would be a better fit to work with an XSD, and

Re: [libvirt] [qemu RFC] qapi: add "firmware.json"

On 04/10/18 08:18, Gerd Hoffmann wrote: > Hi, > >>> uboot for example implements uefi unterfaces too (dunno how complete, >>> but reportly recent versions can run uefi shell and grub just fine). >> >> Indeed: when I was struggling with this enum type and tried to look for >> more firmware types

Re: [libvirt] [qemu RFC] qapi: add "firmware.json"

On Tue, Apr 10, 2018 at 11:16:01AM +0200, Laszlo Ersek wrote: > On 04/10/18 08:27, Gerd Hoffmann wrote: > > Hi, > > > >> - I considered adding wildcards (say, blacklist "all" i440fx machtypes, > >> present and future, for SMM-requiring OVMF builds), but then you get > >> into version sorting

Re: [libvirt] [qemu RFC] qapi: add "firmware.json"

On Sat, Apr 07, 2018 at 02:01:17AM +0200, Laszlo Ersek wrote: > Add a schema that describes the properties of virtual machine firmware. > > Each firmware executable installed on a host system should come with a > JSON file that conforms to this schema, and informs the management > applications

Re: [libvirt] [qemu RFC] qapi: add "firmware.json"

On Tue, Apr 10, 2018 at 01:27:18PM +0200, Laszlo Ersek wrote: > Please go through the rest of the emails in this thread, and advise: > - if the firmware descriptor schema may perhaps live in the libvirt tree, > - accordingly, if the schema could be expressed as an XSD (and firmware > packages

Re: [libvirt] [qemu RFC] qapi: add "firmware.json"

On 10 April 2018 at 12:34, Daniel P. Berrangé wrote: > On Tue, Apr 10, 2018 at 01:27:18PM +0200, Laszlo Ersek wrote: > >> Please go through the rest of the emails in this thread, and advise: >> - if the firmware descriptor schema may perhaps live in the libvirt tree, >> -

Re: [libvirt] [qemu RFC] qapi: add "firmware.json"

On 04/10/18 07:59, Gerd Hoffmann wrote: > Hi, > >> I threw in "-kernel" because, although it also (usually?) means >> "memory", I expected people would want it separate. >> >> Regarding memory vs. pflash, I thought that these two, combined with the >> access permissions, could cover all of RAM,

Re: [libvirt] [qemu RFC] qapi: add "firmware.json"

On 04/10/18 13:34, Daniel P. Berrangé wrote: > On Tue, Apr 10, 2018 at 01:27:18PM +0200, Laszlo Ersek wrote: > >> Please go through the rest of the emails in this thread, and advise: >> - if the firmware descriptor schema may perhaps live in the libvirt tree, >> - accordingly, if the schema could

Re: [libvirt] [PATCH v2 0/9] Be consistent with vir*Obj*Remove* APIs

On 04/10/2018 04:47 AM, Marc Hartmayer wrote: > On Wed, Mar 28, 2018 at 11:19 PM +0200, John Ferlan > wrote: >> v1: https://www.redhat.com/archives/libvir-list/2018-March/msg01295.html >> >> NB: This can wait until 4.2.0 is release, but I figured I'd post this >> now

Re: [libvirt] [qemu RFC] qapi: add "firmware.json"

On Mon, Apr 09, 2018 at 06:50:12PM +0200, Laszlo Ersek wrote: > On 04/09/18 10:19, Gerd Hoffmann wrote: > >>> +{ 'enum' : 'SystemFirmwareType', > >>> + 'data' : [ 'bios', 'slof', 'uboot', 'uefi' ] } > >> > >> The naming here is quite a bad mixture between firmware interface > >> ('bios', 'uefi')

Re: [libvirt] [qemu RFC] qapi: add "firmware.json"

On 04/10/18 08:27, Gerd Hoffmann wrote: > Hi, > >> - I considered adding wildcards (say, blacklist "all" i440fx machtypes, >> present and future, for SMM-requiring OVMF builds), but then you get >> into version sorting and similar mess. I considered fnmatch() -- >> basically simple ? and *

Re: [libvirt] [qemu RFC] qapi: add "firmware.json"

On Tue, Apr 10, 2018 at 11:51:31AM +0200, Gerd Hoffmann wrote: > > > Hmm, I'm wondering whenever it is useful to model things this way. It's > > > not like you can actually configure things for -bios seabios.rom or > > > -kernel uboot.elf. Only pflash allows to actually configure things, and > >

Re: [libvirt] [qemu RFC] qapi: add "firmware.json"

On 04/10/18 11:34, Daniel P. Berrangé wrote: > On Tue, Apr 10, 2018 at 11:16:01AM +0200, Laszlo Ersek wrote: >> On 04/10/18 08:27, Gerd Hoffmann wrote: >>> Hi, >>> - I considered adding wildcards (say, blacklist "all" i440fx machtypes, present and future, for SMM-requiring OVMF

Re: [libvirt] [dbus PATCH v2 00/11] Some code move to have functions sorted

On Mon, Apr 09, 2018 at 07:05:32PM +0200, Katerina Koukiou wrote: > Better do it now before the projects grows more. > > Katerina Koukiou (11): > APIs should appear in alphabetical order: Move Active property > APIs should appear in alphabetical order: Move Autostart property > APIs should

Re: [libvirt] [PATCH v2 0/9] Be consistent with vir*Obj*Remove* APIs

On Wed, Mar 28, 2018 at 11:19 PM +0200, John Ferlan wrote: > v1: https://www.redhat.com/archives/libvir-list/2018-March/msg01295.html > > NB: This can wait until 4.2.0 is release, but I figured I'd post this > now just to put it on the radar and of course in hopes that

Re: [libvirt] [qemu RFC] qapi: add "firmware.json"

On Mon, Apr 09, 2018 at 06:34:41PM +0200, Laszlo Ersek wrote: > On 04/09/18 09:26, Thomas Huth wrote: > > Hi Laszlo, > > > > On 07.04.2018 02:01, Laszlo Ersek wrote: > >> Add a schema that describes the properties of virtual machine firmware. > >> > >> Each firmware executable installed on a

Re: [libvirt] [qemu RFC] qapi: add "firmware.json"

> > Hmm, I'm wondering whenever it is useful to model things this way. It's > > not like you can actually configure things for -bios seabios.rom or > > -kernel uboot.elf. Only pflash allows to actually configure things, and > > there are not that many useful combinations. The code needs > >

Re: [libvirt] [Qemu-devel] [qemu RFC] qapi: add "firmware.json"

On 10/04/2018 11:23, Daniel P. Berrangé wrote: >> And, really, this seems to reinforce my point that the schema should >> live in the libvirtd tree, not in the QEMU tree. In that case, perhaps >> it would be a better fit to work with an XSD, and firmware packages >> should install XML files?

Re: [libvirt] [Qemu-devel] [qemu RFC] qapi: add "firmware.json"

Hi, > It occurs to me that we are actually over-thinking things, by making it > possible to list a choice of vars files per firmware. We could remove this > special case by just having separate tpo level firmware entries and a main > feature flag to say if it is enrolled or not - see below

Re: [libvirt] [qemu RFC] qapi: add "firmware.json"

On Tue, Apr 10, 2018 at 12:48:28PM +0100, Peter Maydell wrote: > On 10 April 2018 at 12:34, Daniel P. Berrangé wrote: > > On Tue, Apr 10, 2018 at 01:27:18PM +0200, Laszlo Ersek wrote: > > > >> Please go through the rest of the emails in this thread, and advise: > >> - if the

Re: [libvirt] [qemu RFC] qapi: add "firmware.json"

On 04/10/18 12:20, Daniel P. Berrangé wrote: > On Sat, Apr 07, 2018 at 02:01:17AM +0200, Laszlo Ersek wrote: >> +{ 'struct' : 'SystemFirmware', >> + 'data' : { 'executable' : 'FirmwareFile', >> + 'type' : 'SystemFirmwareType', >> +

Re: [libvirt] [PATCH] qemuDomainNamespaceSetupDisk: Fix const correctness

On Tue, Apr 10, 2018 at 08:58 AM +0200, Michal Privoznik wrote: > The array of strings we are building is indeed array of const > strings. We are not STRDUP()-ing them nor FREE()-ing them. > > Signed-off-by: Michal Privoznik > --- >

Re: [libvirt] [qemu RFC] qapi: add "firmware.json"

On 04/10/18 09:44, Thomas Huth wrote: > On 09.04.2018 18:34, Laszlo Ersek wrote: >> On 04/09/18 09:26, Thomas Huth wrote: >>> Hi Laszlo, >>> >>> On 07.04.2018 02:01, Laszlo Ersek wrote: Add a schema that describes the properties of virtual machine firmware. Each firmware executable

Re: [libvirt] [qemu RFC] qapi: add "firmware.json"

On Mon, Apr 09, 2018 at 07:57:54PM +0200, Laszlo Ersek wrote: > On 04/09/18 10:49, Daniel P. Berrangé wrote: > > On Sat, Apr 07, 2018 at 02:01:17AM +0200, Laszlo Ersek wrote: > >> Add a schema that describes the properties of virtual machine firmware. > >> > >> Each firmware executable installed

Re: [libvirt] [qemu RFC] qapi: add "firmware.json"

On 10.04.2018 11:05, Daniel P. Berrangé wrote: > On Mon, Apr 09, 2018 at 06:34:41PM +0200, Laszlo Ersek wrote: >> On 04/09/18 09:26, Thomas Huth wrote: >>> Hi Laszlo, >>> >>> On 07.04.2018 02:01, Laszlo Ersek wrote: Add a schema that describes the properties of virtual machine firmware.

Re: [libvirt] [qemu RFC] qapi: add "firmware.json"

On 10.04.2018 11:22, Laszlo Ersek wrote: > On 04/10/18 09:33, Thomas Huth wrote: [...] >> Alternatively, what about providing some kind of "alias" or "nickname" >> setting here, too? So the EDK2 builds would get >> SystemFirmwareType="edk2" and "SystemFirmwareAlias="uefi" for example. > > I hope

Re: [libvirt] [qemu RFC] qapi: add "firmware.json"

On 04/10/18 11:05, Daniel P. Berrangé wrote: > On Mon, Apr 09, 2018 at 06:34:41PM +0200, Laszlo Ersek wrote: >> On 04/09/18 09:26, Thomas Huth wrote: >>> Hi Laszlo, >>> >>> On 07.04.2018 02:01, Laszlo Ersek wrote: Add a schema that describes the properties of virtual machine firmware.

Re: [libvirt] [Qemu-devel] [qemu RFC] qapi: add "firmware.json"

On Tue, Apr 10, 2018 at 11:20:33AM +0100, Daniel P. Berrangé wrote: > On Sat, Apr 07, 2018 at 02:01:17AM +0200, Laszlo Ersek wrote: > > Add a schema that describes the properties of virtual machine firmware. > > > > Each firmware executable installed on a host system should come with a > > JSON

Re: [libvirt] [qemu RFC] qapi: add "firmware.json"

On 04/10/18 11:18, Daniel P. Berrangé wrote: > On Mon, Apr 09, 2018 at 07:57:54PM +0200, Laszlo Ersek wrote: >> On 04/09/18 10:49, Daniel P. Berrangé wrote: >>> On Sat, Apr 07, 2018 at 02:01:17AM +0200, Laszlo Ersek wrote: Add a schema that describes the properties of virtual machine

Re: [libvirt] [qemu RFC] qapi: add "firmware.json"

On 04/10/18 11:26, Thomas Huth wrote: > On 10.04.2018 11:16, Laszlo Ersek wrote: >> On 04/10/18 08:27, Gerd Hoffmann wrote: >>> Hi, >>> - I considered adding wildcards (say, blacklist "all" i440fx machtypes, present and future, for SMM-requiring OVMF builds), but then you get into

Re: [libvirt] [qemu RFC] qapi: add "firmware.json"

On 04/10/18 11:32, Thomas Huth wrote: > On 10.04.2018 11:22, Laszlo Ersek wrote: >> On 04/10/18 09:33, Thomas Huth wrote: > [...] >>> Alternatively, what about providing some kind of "alias" or "nickname" >>> setting here, too? So the EDK2 builds would get >>> SystemFirmwareType="edk2" and

Re: [libvirt] [libvirt PATCH v2 03/44] Force QMP capability probing

On Mon, 2018-04-09 at 16:42 +0100, Daniel P. Berrangé wrote: > > @@ -5114,7 +4261,7 @@ virQEMUCapsNewForBinaryInternal(virArch hostArch, > > goto error; > > } > > > > -if (qmpOnly && !qemuCaps->usedQMP) { > > +if (!qemuCaps->usedQMP) { > >

Re: [libvirt] [qemu RFC] qapi: add "firmware.json"

On 10.04.2018 11:16, Laszlo Ersek wrote: > On 04/10/18 08:27, Gerd Hoffmann wrote: >> Hi, >> >>> - I considered adding wildcards (say, blacklist "all" i440fx machtypes, >>> present and future, for SMM-requiring OVMF builds), but then you get >>> into version sorting and similar mess. I

Re: [libvirt] [qemu RFC] qapi: add "firmware.json"

On Tue, Apr 10, 2018 at 11:16:01AM +0200, Laszlo Ersek wrote: > On 04/10/18 08:27, Gerd Hoffmann wrote: > > Hi, > > > >> - I considered adding wildcards (say, blacklist "all" i440fx machtypes, > >> present and future, for SMM-requiring OVMF builds), but then you get > >> into version sorting

Re: [libvirt] [qemu RFC] qapi: add "firmware.json"

On 04/10/18 11:55, Daniel P. Berrangé wrote: > On Tue, Apr 10, 2018 at 11:51:31AM +0200, Gerd Hoffmann wrote: Hmm, I'm wondering whenever it is useful to model things this way. It's not like you can actually configure things for -bios seabios.rom or -kernel uboot.elf. Only pflash

Re: [libvirt] [qemu RFC] qapi: add "firmware.json"

On Tue, Apr 10, 2018 at 01:44:13PM +0200, Laszlo Ersek wrote: > On 04/10/18 13:34, Daniel P. Berrangé wrote: > > On Tue, Apr 10, 2018 at 01:27:18PM +0200, Laszlo Ersek wrote: > > > >> Please go through the rest of the emails in this thread, and advise: > >> - if the firmware descriptor schema may

[libvirt] [PATCHv2 4/4] qemu: deny privilege elevation and spawn in seccomp

If QEMU uses a seccomp blacklist (since 2.11), -sandbox on no longer tries to whitelist all the calls, but uses sets of blacklists: default (always blacklisted with -sandbox on) obsolete (defaults to deny) elevateprivileges (setuid & co, default: allow) spawn (fork & execve, default: allow)

[libvirt] [PATCHv2 2/4] Introduce qemuBuildSeccompSandboxCommandLine

Move the building of -sandbox command line into a separate function. Signed-off-by: Ján Tomko --- src/qemu/qemu_command.c | 30 +- 1 file changed, 21 insertions(+), 9 deletions(-) diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c

[libvirt] [PATCHv2 3/4] Refactor qemuBuildSeccompSandboxCommandLine

Exit early if possible to simplify the logic. Signed-off-by: Ján Tomko --- src/qemu/qemu_command.c | 18 -- 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c index dfeba54ee..ba279e640 100644 ---

[libvirt] [PATCHv2 0/4] qemu: enable sandbox whitelist by default

v1: https://www.redhat.com/archives/libvir-list/2018-March/msg01965.html https://bugzilla.redhat.com/show_bug.cgi?id=1492597 v2: * also deny resource control * split out and refactor the command line building * be explicit about denying the obsolete syscalls Ján Tomko (4): Introduce

Re: [libvirt] [libvirt PATCH v2 04/44] Require QEMU 1.5.0

On Mon, Apr 09, 2018 at 05:54:17PM +0200, Andrea Bolognani wrote: On Thu, 2018-04-05 at 14:22 +0200, Ján Tomko wrote: According to the policy described on https://libvirt.org/platforms.html the QEMU versions in the oldest relevant releses are: Empty line here. Possibly indent the distros with

[libvirt] [PATCH v4 08/14] qemu: Generate cmd line at startup

This is the easier part. All we need to do here is put -object pr-manager-helper,id=$alias,path=$socketPath and then just reference the object in -drive file.pr-manager=$alias. Signed-off-by: Michal Privoznik --- src/qemu/qemu_command.c| 94

[libvirt] [PATCH v4 04/14] qemu: Generate alias and socket path for pr-helper

While we're not generating the command line just yet (look for the next commits), we can generate the alias for pr-manager. A domain can have up to one managed pr-manager (in which case socket path is decided by libvirt and pr-helper is spawned by libvirt too), but up to ndisks of unmanaged ones

[libvirt] [PATCH v4 10/14] qemu: Start PR daemon on domain startup

Before we exec() qemu we have to spawn pr-helper processes for all managed reservations (well, technically there can only one). The only caveat there is that we should place the process into the same namespace and cgroup as qemu (so that it shares the same view of the system). But we can do that

[libvirt] [PATCH v4 03/14] qemu: Introduce pr-manager-helper capability

The capability tracks if qemu has pr-manager-helper object. At this time don't actually detect if qemu has the capability. Not just yet. Only after the code is written the feature will be enabled. Signed-off-by: Michal Privoznik --- src/qemu/qemu_capabilities.c | 1 +

[libvirt] [PATCH v4 01/14] virstoragefile: Introduce virStoragePRDef

This is a definition that holds information on SCSI persistent reservation settings. The XML part looks like this: If @managed is set to 'yes' then the is not parsed. This design was agreed on here: https://www.redhat.com/archives/libvir-list/2017-November/msg01005.html

[libvirt] [PATCH v4 00/14] Basic implementation of persistent reservations

v4 of: https://www.redhat.com/archives/libvir-list/2018-March/msg00745.html diff to v3: - Peter's review worked in Michal Privoznik (14): virstoragefile: Introduce virStoragePRDef qemuDomainDiskChangeSupported: Deny changing reservations qemu: Introduce pr-manager-helper capability

[libvirt] [PATCH v4 14/14] qemu: Detect pr-manager-helper capability

Signed-off-by: Michal Privoznik --- src/qemu/qemu_capabilities.c | 1 + tests/qemucapabilitiesdata/caps_2.11.0.s390x.xml | 1 + tests/qemucapabilitiesdata/caps_2.12.0.aarch64.xml | 1 + tests/qemucapabilitiesdata/caps_2.12.0.ppc64.xml | 1 +

[libvirt] [PATCHv2 1/4] Introduce QEMU_CAPS_SECCOMP_BLACKLIST

QEMU commit 1bd6152 changed the default behavior from whitelist to blacklist and introduced a few sets of system calls. Use the 'elevateprivileges' parameter of -sandbox as a witness of this change. https://bugzilla.redhat.com/show_bug.cgi?id=1492597 Signed-off-by: Ján Tomko

[libvirt] [PATCH v4 07/14] qemu_cgroup: Allow /dev/mapper/control for PR

Just like in previous commit, qemu-pr-helper might want to open /dev/mapper/control under certain circumstances. Therefore we have to allow it in cgroups. Signed-off-by: Michal Privoznik --- src/qemu/qemu_cgroup.c | 33 ++---

[libvirt] [PATCH v4 06/14] qemu_ns: Allow /dev/mapper/control for PR

If qemu-pr-helper is compiled with multipath support the first thing it does is opening /dev/mapper/control. Since we're going to be running it inside qemu namespace we need to create it there. Unfortunately, we don't know if it was compiled with or without multipath so we have to create it

[libvirt] [PATCH v4 02/14] qemuDomainDiskChangeSupported: Deny changing reservations

Couple of reasons for that: a) there's no monitor command to change path where the pr-helper connects to, or b) there's no monitor command to introduce a new pr-helper for a disk that already exists. Signed-off-by: Michal Privoznik --- src/libvirt_private.syms | 1 +

[libvirt] [PATCH v4 11/14] qemu: Start PR daemon on disk hotplug

When plugging a disk into domain we need to start qemu-pr-helper process iff this is the first disk with PR enabled for the domain. Otherwise the helper is already running (or not needed). Signed-off-by: Michal Privoznik --- src/qemu/qemu_hotplug.c | 51

[libvirt] [PATCH v4 13/14] qemu_hotplug: Hotunplug of reservations

If we are the last one to use pr-manager object we need to remove it and also kill the qemu-pr-helper process. Signed-off-by: Michal Privoznik --- src/qemu/qemu_hotplug.c | 38 ++ 1 file changed, 38 insertions(+) diff --git

[libvirt] [PATCH v4 12/14] qemu_hotplug: Hotplug of reservations

When attaching a disk that requires pr-manager we might need to plug the pr-manager object too. Signed-off-by: Michal Privoznik --- src/qemu/qemu_hotplug.c | 41 + 1 file changed, 41 insertions(+) diff --git a/src/qemu/qemu_hotplug.c

[libvirt] [PATCH v4 09/14] qemu: Introduce pr_helper to qemu.conf

Just like we allow users overriding path to bridge-helper detected at compile time we can allow them to override path to qemu-pr-helper. Signed-off-by: Michal Privoznik --- m4/virt-driver-qemu.m4 | 5 + src/qemu/libvirtd_qemu.aug | 1 +

[libvirt] [PATCH v4 05/14] qemu: Store pr runtime data in status XML

Now that we generate pr-manager alias and socket path store them in status XML so that they are preserved across daemon restarts. Signed-off-by: Michal Privoznik --- src/qemu/qemu_domain.c | 64 ++ 1 file changed, 64

[libvirt] [PATCH jenkins-ci] Run "make check" for osinfo-db

Signed-off-by: Daniel P. Berrangé --- projects/osinfo-db.yaml | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/projects/osinfo-db.yaml b/projects/osinfo-db.yaml index 0dd73b5..7f83722 100644 --- a/projects/osinfo-db.yaml +++ b/projects/osinfo-db.yaml

Re: [libvirt] [PATCH v3] qemu: add virQEMUBuildBufferEscapeComma in qemu_command.c

On 04/02/2018 04:17 PM, Sukrit Bhatnagar wrote: > This patch adds virQEMUBuildBufferEscapeComma to properly > escape commas in user provided data fields for qemu command > line processing. > > Signed-off-by: Sukrit Bhatnagar > --- > > Thank you for the helpful feedback

Re: [libvirt] [PATCH v6.1 2/9] libxl: pass driver config to libxlMakeDomBuildInfo

On 04/06/2018 06:54 PM, Marek Marczykowski-Górecki wrote: On Wed, Mar 28, 2018 at 01:42:47PM -0600, Jim Fehlig wrote: On 03/27/2018 05:55 PM, Marek Marczykowski-Górecki wrote: diff --git a/tests/virmocklibxl.c b/tests/virmocklibxl.c index 747f9f8..28281b6 100644 --- a/tests/virmocklibxl.c +++

Re: [libvirt] [PATCH V2 2/8] tests: move sexpr2xml tests to WITH_LIBXL

On 04/09/2018 03:10 PM, Jim Fehlig wrote: On 04/09/2018 08:32 AM, Daniel P. Berrangé wrote: On Fri, Apr 06, 2018 at 02:44:54PM -0600, Jim Fehlig wrote: In preparation of removing the legacy Xen driver, move the sexpr2xml tests from WITH_XEN to WITH_LIBXL. Even though the legacy driver will be

[libvirt] [PATCH] libxl: add support for memballoon device

All Xen PV and HVM with PV driver support a memory balloon device, which cannot be disabled through the toolstack. Model the device in the libxl driver, similar to the recently removed xend-based driver. Signed-off-by: Jim Fehlig --- Apologies for the large amount of test file

Re: [libvirt] [PATCH] news: announce dropping of legacy Xen driver

On Mon, 2018-04-09 at 15:00 -0600, Jim Fehlig wrote: > Signed-off-by: Jim Fehlig > --- > > Not sure if removal of a feature is a feature, but this seems better > placed under "New features" than "Improvements" or "Bug fixes". It definitely counts as an improvement for those of

Re: [libvirt] [qemu RFC] qapi: add "firmware.json"

On 09.04.2018 18:50, Laszlo Ersek wrote: > On 04/09/18 10:19, Gerd Hoffmann wrote: +{ 'enum' : 'SystemFirmwareType', + 'data' : [ 'bios', 'slof', 'uboot', 'uefi' ] } >>> >>> The naming here is quite a bad mixture between firmware interface >>> ('bios', 'uefi') and firmware

Re: [libvirt] [qemu RFC] qapi: add "firmware.json"

On 09.04.2018 18:34, Laszlo Ersek wrote: > On 04/09/18 09:26, Thomas Huth wrote: >> Hi Laszlo, >> >> On 07.04.2018 02:01, Laszlo Ersek wrote: >>> Add a schema that describes the properties of virtual machine firmware. >>> >>> Each firmware executable installed on a host system should come with a

Re: [libvirt] [jenkins-ci PATCH 0/2] Add libvirt-dbus project

On Thu, Apr 05, 2018 at 04:10:15PM +0200, Andrea Bolognani wrote: > Andrea Bolognani (2): > guests: Add libvirt-dbus project > projects: Add libvirt-dbus project Thanks for adding libvirt-dbus. Reviewed-by: Pavel Hrdina signature.asc Description: PGP signature --

Re: [libvirt] [jenkins-ci PATCH 0/2] jobs: Simplify Python jobs

On Thu, Apr 05, 2018 at 05:23:58PM +0200, Andrea Bolognani wrote: > By reverting a bunch of semi-recent changes. > > Requires > > https://www.redhat.com/archives/libvir-list/2018-April/msg00356.html > > Andrea Bolognani (2): > jobs: Don't set $PYTHONPATH for python-distutil jobs > jobs:

Re: [libvirt] [qemu RFC] qapi: add "firmware.json"

Hi, > - I considered adding wildcards (say, blacklist "all" i440fx machtypes, > present and future, for SMM-requiring OVMF builds), but then you get > into version sorting and similar mess. I considered fnmatch() -- > basically simple ? and * wildcards -- but that's not expressive enough. I'd

Re: [libvirt] [PATCH] util: don't check for parallel iteration in hash-related functions

❦ 6 avril 2018 12:01 +0200, Michal Privoznik  : > So I went through all callbacks (even transitive ones) and I've found > two problems: > > umlProcessAutoDestroyRun -> umlProcessAutoDestroyDom -> virHashRemoveEntry > > qemuDomainSnapshotDiscardAllMetadata ->

[libvirt] [PATCH] qemuDomainNamespaceSetupDisk: Fix const correctness

The array of strings we are building is indeed array of const strings. We are not STRDUP()-ing them nor FREE()-ing them. Signed-off-by: Michal Privoznik --- src/qemu/qemu_domain.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/qemu/qemu_domain.c

Re: [libvirt] [qemu RFC] qapi: add "firmware.json"

Hi, > > uboot for example implements uefi unterfaces too (dunno how complete, > > but reportly recent versions can run uefi shell and grub just fine). > > Indeed: when I was struggling with this enum type and tried to look for > more firmware types to add, my googling turned up the "UEFI on

[libvirt] [PATCH v2] util: don't check for parallel iteration in hash-related functions

This is the responsability of the caller to apply the correct lock before using these functions. Moreover, the use of a simple boolean was still racy: two threads may check the boolean and "lock" it simultaneously. Users of functions from src/util/virhash.c have to be checked for correctness.

[libvirt] [PATCH v2 4/6] tpm: Label the external swtpm with SELinux labels

In this patch we label the swtpm process with SELinux labels. We give it the same label as the QEMU process has. We label its state directory and files as well. The file and process labels now look as follows: Directory: /var/lib/libvirt/swtpm [root@localhost swtpm]# ls -lZ total 4 rwx--. 2

[libvirt] [PATCH v2 2/6] tpm: Add support for external swtpm TPM emulator

This patch adds support for an external swtpm TPM emulator. The XML for this type of TPM looks as follows: The XML will currently only start a TPM 1.2. Upon first start, libvirt will run `swtpm_setup`, which will simulate the manufacturing of a TPM and create certificates for it and

[libvirt] [PATCH v2 0/6] Add support for TPM emulator and CRB interface

This series of patches add support for the new TPM CRB interface in QEMU that will become available with QEMU 2.12. The rest of the patches add support for the TPM emulator backend that is available in QEMU and based on swtpm + libtpms. It allows to attach a TPM 1.2 or 2 to a QEMU VM. sVirt

[libvirt] [PATCH v2 3/6] tpm: Add test cases for external swtpm TPM emulator

This patch adds extensions to existing test cases and specific test cases for the tpm-emulator. Signed-off-by: Stefan Berger --- tests/qemucapabilitiesdata/caps_2.11.0.s390x.xml | 1 + tests/qemucapabilitiesdata/caps_2.12.0.aarch64.xml | 1 +

[libvirt] [PATCH v2 6/6] tpm: Add swtpm to emulator cgroup

Add the external swtpm to the emulator cgroup so that upper limits of CPU usage can be enforced on the emulated TPM. To enable this we need to have the swtpm write its process id (pid) into a file. We then read it from the file to configure the emulator cgroup. The PID file is created in

[libvirt] [PATCH v2 5/6] tpm: Add support for choosing emulation of a TPM 2

This patch extends the TPM's device XML with TPM 2 support. This only works for the emulator type backend and looks as follows: Once the version of a TPM has been chosen it cannot be changed anymore unless one removes the TPM device first and then reads it. However, one looses

[libvirt] [PATCH v2 1/6] tpm: Enable TPM CRB interface

Enable the TPM CRB interface added in QEMU 2.12. the TPM CRB interface is a simpler interface than the TPM TIS and is only available for TPM 2. Signed-off-by: Stefan Berger --- docs/formatdomain.html.in | 2 ++ docs/schemas/domaincommon.rng