Re: [libvirt] [PATCH v1 2/3] qemu: Implement extended loader and nvram

On 08/08/14 14:08, Paolo Bonzini wrote: > Il 08/08/2014 12:17, Michal Privoznik ha scritto: >> +if (loader->nvram) { >> +virBufferFreeAndReset(&buf); >> +virBufferAsprintf(&buf, >> + "file=%s,if=pflash,format=raw,unit=1", >> +

Re: [libvirt] [PATCH v1 3/3] qemu: Automatically create NVRAM store

On 08/08/14 14:05, Paolo Bonzini wrote: > Il 08/08/2014 12:17, Michal Privoznik ha scritto: >> When using split UEFI image, it may come handy if libvirt manages per >> domain _VARS file automatically. While the _CODE file is RO and can >> be shared among multiple domains, you certainly don't want

Re: [libvirt] [PATCH v2 1/3] conf: Extend and introduce

that's really worth its face value, so I'll just ack. Acked-by: Laszlo Ersek In addition, is there an easy way for me to test this patchset? I can pluck the series from the list, apply it manually to my upstream clone, build etc. My main question is if there's going to be some interfe

Re: [libvirt] [PATCH v2 2/3] qemu: Implement extended loader and nvram

ndAddArg(cmd, "-bios"); > +virCommandAddArg(cmd, loader->path); > + break; > + > +case VIR_DOMAIN_LOADER_TYPE_PFLASH: > +/* UEFI is supported inly for x86_64 currently */ harmless typo in new check: "inly" [...] Seems good to me. Acked-by: Laszlo Ersek Thanks! Laszlo -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v2 3/3] qemu: Automatically create NVRAM store

comments below On 08/15/14 15:43, Michal Privoznik wrote: > When using split UEFI image, it may come handy if libvirt manages per > domain _VARS file automatically. While the _CODE file is RO and can be > shared among multiple domains, you certainly don't want to do that on > the _VARS file. This

Re: [libvirt] [PATCH v3 0/3] OVMF exposure

On 08/18/14 17:12, Michal Privoznik wrote: > diff to v2: > -Adapted to Laszlo's review on v2 This series doesn't apply to current master (cf389258ae32069c98eee37ca2341e640a6c3d77) any longer: Applying: conf: Extend and introduce error: src/xenxs/xen_sxpr.c: does not exist in index error:

Re: [libvirt] [PATCH v4 1/3] conf: Extend and introduce

virt-usbtablet.xml | 2 +- > tests/xmconfigdata/test-fullvirt-utc.xml | 2 +- > tests/xmconfigdata/test-no-source-cdrom.xml| 2 +- > tests/xmconfigdata/test-pci-devs.xml | 2 +- > 69 files changed, 269 insertions(+), 79 deletions(-) > create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-bios-nvram.xml Acked-by: Laszlo Ersek (Please append this line to the commit message in any further reposts.) -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v4 2/3] qemu: Implement extended loader and nvram

gt; .../qemuxml2argvdata/qemuxml2argv-bios-nvram.args | 10 +++ > tests/qemuxml2argvtest.c | 2 + > 5 files changed, 118 insertions(+), 4 deletions(-) > create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-bios-nvram.args Acked-by: Laszlo Ersek (Please append

Re: [libvirt] [PATCH v4 3/3] qemu: Automatically create NVRAM store

comments below On 08/21/14 10:50, Michal Privoznik wrote: > When using split UEFI image, it may come handy if libvirt manages per > domain _VARS file automatically. While the _CODE file is RO and can be > shared among multiple domains, you certainly don't want to do that on > the _VARS file. This

Re: [libvirt] [PATCH v4 3/3] qemu: Automatically create NVRAM store

On 08/21/14 11:05, Daniel P. Berrange wrote: > On Thu, Aug 21, 2014 at 10:50:24AM +0200, Michal Privoznik wrote: >> diff --git a/src/qemu/qemu.conf b/src/qemu/qemu.conf >> index 7bbbe09..79bba36 100644 >> --- a/src/qemu/qemu.conf >> +++ b/src/qemu/qemu.conf >> @@ -487,3 +487,17 @@ >> # Defaults to

Re: [libvirt] [PATCH v4 3/3] qemu: Automatically create NVRAM store

On 08/22/14 10:54, Daniel P. Berrange wrote: > On Fri, Aug 22, 2014 at 10:27:29AM +0200, Laszlo Ersek wrote: >> On 08/21/14 11:05, Daniel P. Berrange wrote: >>> On Thu, Aug 21, 2014 at 10:50:24AM +0200, Michal Privoznik wrote: >>>> diff --git a/src/qemu/qemu.conf b

Re: [libvirt] [PATCH v4 3/3] qemu: Automatically create NVRAM store

On 08/22/14 11:56, Daniel P. Berrange wrote: > On Fri, Aug 22, 2014 at 11:38:06AM +0200, Laszlo Ersek wrote: >> On 08/22/14 10:54, Daniel P. Berrange wrote: >>> On Fri, Aug 22, 2014 at 10:27:29AM +0200, Laszlo Ersek wrote: >>>> On 08/21/14 11:05, Daniel P. Berrange wr

Re: [libvirt] [PATCH v4 3/3] qemu: Automatically create NVRAM store

On 08/22/14 12:24, Daniel P. Berrange wrote: > On Fri, Aug 22, 2014 at 12:12:52PM +0200, Laszlo Ersek wrote: >> On 08/22/14 11:56, Daniel P. Berrange wrote: >>> On Fri, Aug 22, 2014 at 11:38:06AM +0200, Laszlo Ersek wrote: >>>> On 08/22/14 10:54, Daniel P. Berran

Re: [libvirt] [PATCH v5 3/3] qemu: Automatically create NVRAM store

one question On 08/22/14 14:08, Michal Privoznik wrote: > When using split UEFI image, it may come handy if libvirt manages per > domain _VARS file automatically. While the _CODE file is RO and can be > shared among multiple domains, you certainly don't want to do that on > the _VARS file. This la

Re: [libvirt] [PATCH v5 3/3] qemu: Automatically create NVRAM store

On 08/22/14 14:43, Michal Privoznik wrote: > On 22.08.2014 14:26, Laszlo Ersek wrote: >> one question >> >> On 08/22/14 14:08, Michal Privoznik wrote: >>> When using split UEFI image, it may come handy if libvirt manages per >>> domain _VARS file automatica

Re: [libvirt] [PATCH 1/2] nvram: Fix permissions

ser with search permission. So that looks like a must. Regarding the seclabel / context, I agree that it should have a label consistent with other disk image files; for qemu it's just a -drive after all. The hunk in question looks consistent with the rest of "src/security/security_selinux.c". Acked-by: Laszlo Ersek -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 2/2] virDomainUndefineFlags: Allow NVRAM unlinking

some comments below On 09/11/14 14:09, Michal Privoznik wrote: > When a domain is undefined, there are options to remove it's > managed save state or snapshots. However, there's another file > that libvirt creates per domain: the NVRAM variable store file. > Make sure that the file is not left beh

Re: [libvirt] [PATCH 1/2] nvram: Fix permissions

On 09/11/14 16:25, Michal Privoznik wrote: > On 11.09.2014 16:07, Laszlo Ersek wrote: >> On 09/11/14 14:09, Michal Privoznik wrote: >>> I've noticed two problem with the automatically created NVRAM varstore >>> file. The first, even though I run qemu as roo

Re: [libvirt] [PATCHv2 2/2] formatdomain: Update example to match the rest

as changed to 'yes' and 'no', but the example > XML snippet wasn't updated, so while the description is correct, the > example isn't. > > Reported-by: Laszlo Ersek > Signed-off-by: Michal Privoznik > --- > docs/formatdomain.html.in | 2 +- > 1 fil

Re: [libvirt] [PATCHv2 1/2] virDomainUndefineFlags: Allow NVRAM unlinking

lt;--storage> B | I<--remove-all-storage>} > I<--wipe-storage>] > > Undefine a domain. If the domain is running, this converts it to a > transient domain, without stopping it. If the domain is inactive, > @@ -2099,6 +2099,10 @@ domain. Without the flag, attempts to undefine an > inactive domain with > snapshot metadata will fail. If the domain is active, this flag is > ignored. > > +The I<--nvram> flag ensures no nvram (/domain/os/nvram/) file is > +left behind. If the domain has an nvram file and the flag is > +omitted, the undefine will fail. > + > The I<--storage> flag takes a parameter B, which is a comma > separated > list of volume target names or source paths of storage volumes to be removed > along with the undefined domain. Volumes can be undefined and thus removed > only > Acked-by: Laszlo Ersek Thanks! Laszlo -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH] domaincaps: Expose UEFI binary path, if it exists

Hi Cole, I'm not subscribed to the list; please CC me on UEFI-related patches. Michal pinged me to review this one. Some comments: On 09/17/14 01:52, Cole Robinson wrote: > Check to see if the UEFI binary mentioned in qemu.conf actually > exists, and if so expose it in domcapabilities like > >

Re: [libvirt] [PATCH v2 1/2] qemu_capabilities: Change virQEMUCapsFillDomainCaps signature

u_capabilities.c | 25 - > src/qemu/qemu_capabilities.h | 4 ++-- > src/qemu/qemu_driver.c | 3 ++- > tests/domaincapstest.c | 19 --- > 4 files changed, 32 insertions(+), 19 deletions(-) Seems reasonable. Acked-by: Laszlo Ersek -- libvir-list ma

Re: [libvirt] [PATCH v2 2/2] domaincaps: Expose UEFI binary path, if it exists

+} > +values->nvalues++; > +} > +va_end(list); > + > +return ret; > +} Okay, you increment "values->nvalues" only after. The rest too looks good to me. Acked-by: Laszlo Ersek Thanks Laszlo -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH virt-manager] details: Add UI for enabling UEFI via 'customize before install'

s best looked at with "git diff -b" (or "git show -b").) (3) I just realized that a domain's name can change during its lifetime. Renaming a domain becomes a problem when the varstore's pathname is deduced from the domain's name. For this reason, the auto-generat

Re: [libvirt] [PATCH virt-manager] details: Add UI for enabling UEFI via 'customize before install'

On 09/22/14 18:37, Cole Robinson wrote: > On 09/21/2014 10:58 AM, Laszlo Ersek wrote: >> (2) Unfortunately, even libvirtd needs to be modified, in addition. >> >> My patch for (1) *does* pass VIR_DOMAIN_UNDEFINE_NVRAM to libvirtd (I >> verified that with gdb), but l

[libvirt] "migration_address must not be the address of the local machine: 127.0.0.1"

I recently upgraded my laptop from RHEL-7.1 to RHEL-7.2. I always pay attention to *.rpmnew config files, and I manually diff and merge them with the ones I have in place. I did the same with "/etc/libvirt/qemu.conf" this time. Now libvirtd doesn't start for me. Systemd doesn't actually notice t

Re: [libvirt] "migration_address must not be the address of the local machine: 127.0.0.1"

On 11/25/15 12:00, Daniel P. Berrange wrote: > On Wed, Nov 25, 2015 at 11:52:21AM +0100, Laszlo Ersek wrote: >> I recently upgraded my laptop from RHEL-7.1 to RHEL-7.2. >> >> I always pay attention to *.rpmnew config files, and I manually diff and >> merge them wi

Re: [libvirt] "migration_address must not be the address of the local machine: 127.0.0.1"

On 11/25/15 12:10, Daniel P. Berrange wrote: > On Wed, Nov 25, 2015 at 12:07:00PM +0100, Laszlo Ersek wrote: >> On 11/25/15 12:00, Daniel P. Berrange wrote: >>> On Wed, Nov 25, 2015 at 11:52:21AM +0100, Laszlo Ersek wrote: >>>> I recently upgraded my laptop from RHE

Re: [libvirt] [Qemu-devel] ARM KVM GICv3 Support

On 01/19/16 17:53, Peter Maydell wrote: > On 19 January 2016 at 16:46, Andrew Jones wrote: >> On Tue, Jan 12, 2016 at 04:48:27PM +0100, Andrea Bolognani wrote: >>> Would providing a QMP command that returns the list of GIC versions >>> available on the current host for the current machine type be

Re: [libvirt] [PATCH] docs: Document some -boot option limitations on UEFI

On 01/06/15 13:08, Michal Privoznik wrote: > It was brought to my attention that some -boot options may not > work with UEFI. For instance, rebootTimeout is very SeaBIOS > specific,splash logo is not implemented yet on OVMF, and so on. > We should document this limitation at least. > > Signed-off-

Re: [libvirt] [PATCH v2] docs: Document some -boot option limitations on UEFI

lock 0 and Block 1, except for the UUID, from the host's > - SMBIOS values; > - the > - virConnectGetSysinfo call can be > - used to see what values are copied), or "sysinfo" (use the values in > - the sysinfo element). If not > -

Re: [libvirt] [PATCH 1/4] formatdomaincaps: Correctly format API reference

The root element that emulator capability XML document starts with has > If it renders okay, I don't mind! :) Acked-by: Laszlo Ersek -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 2/4] conf: Allow UEFI NVRAM format selection

comments below On 01/13/15 14:41, Michal Privoznik wrote: > https://bugzilla.redhat.com/show_bug.cgi?id=1180955 > > Up till now, there was only one format for NVRAM store file. > However, it's possible to convert the file to qcow2 (which > supports interesting features, like snapshotting, for ins

Re: [libvirt] [PATCH 3/4] qemu: Adapt to NVRAM store file format change

comments below On 01/13/15 14:41, Michal Privoznik wrote: > This basically implements the availability of > choosing NVRAM store file format in the qemu driver. > > Signed-off-by: Michal Privoznik > --- > src/qemu/qemu_command.c| 6 ++-- > .../qemuxml2argv-bios-nvra

Re: [libvirt] [PATCH 4/4] domaincaps: Expose NVRAM store file format capabilities

comments below On 01/13/15 14:41, Michal Privoznik wrote: > It would be nice if we expose the capability of choosing the NVRAM > store file format among with all the possibilities. > > Signed-off-by: Michal Privoznik > --- > docs/formatdomaincaps.html.in | 16 +

Re: [libvirt] [PATCH v2 1/4] conf: Make virDomainLoaderDefParseXML parse too

On 01/13/15 18:20, Michal Privoznik wrote: > This is pure code movement without any functional change. > The code simply reads better this way, that's all. > > Signed-off-by: Michal Privoznik > --- > src/conf/domain_conf.c | 23 ++- > 1 file changed, 14 insertions(+), 9 delet

Re: [libvirt] [PATCH v2 1/4] conf: Make virDomainLoaderDefParseXML parse too

On 01/13/15 19:47, Laszlo Ersek wrote: > On 01/13/15 18:20, Michal Privoznik wrote: >> This is pure code movement without any functional change. >> The code simply reads better this way, that's all. >> >> Signed-off-by: Michal Privoznik >&g

Re: [libvirt] [PATCH v2 2/4] conf: Allow UEFI and NVRAM format selection

eate mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-bios-nvram.xml Looks good to me. Acked-by: Laszlo Ersek -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v2 3/4] qemu: Adapt to UEFI and NVRAM store file format change

e=%s,if=pflash,format=raw,unit=%d", > - loader->nvram, unit); > + "file=%s,if=pflash,format=%s,unit=%d", > + loader->nvram, > + > virDomainLoaderFormatTypeToString(

Re: [libvirt] [PATCH v2 0/4] UEFI and NVRAM store file format

On 01/13/15 18:20, Michal Privoznik wrote: > diff to v1: > -Laszlo's review worked in (notably, even UEFI can have a different format > than raw) > > Michal Privoznik (4): > conf: Make virDomainLoaderDefParseXML parse too > conf: Allow UEFI and NVRAM format selection > qemu: Adapt to UEFI

[libvirt] OVMF whitepaper released

http://people.redhat.com/~lersek/ovmf-whitepaper-c770f8c.txt (An official Red Hat whitepaper PDF edition, for graphical displays, is in the works. As time and technical hurdles allow, both the plain text and the PDF editions shall appear under too, replacing th

[libvirt] qemu commit 65207c59 broke libvirt's capability retrieval (apparently)

Hi All, after pulling QEMU master today, my existent libvirt guests that have the following element: started to barf the following message at me: -- Error starting domain: unsupported configuration: setting ACPI S3 not supported Traceback (most recent call last): Fil

Re: [libvirt] [Qemu-devel] qemu commit 65207c59 broke libvirt's capability retrieval (apparently)

On 06/05/15 23:47, Eric Blake wrote: > On 06/05/2015 03:42 PM, Laszlo Ersek wrote: > >> I found this qemu commit, ie. >> >> commit 65207c59d99f2260c5f1d3b9c491146616a522aa >> Author: Markus Armbruster >> Date: Thu Mar 5 14:35:26 2015 +0100 >> >&g

Re: [libvirt] [PATCH virt-manager] details: Add UI for enabling UEFI via 'customize before install'

On 09/25/14 14:59, Michal Privoznik wrote: > On 21.09.2014 16:58, Laszlo Ersek wrote: >> Hi Cole and Michal, >> >> I'm attaching three patches: >> >> >> >> (2) Unfortunately, even libvirtd needs to be modified, in addition. >> >> My p

Re: [libvirt] [PATCH] qemuPrepareNVRAM: Save domain after NVRAM path generation

with VM startup. It "just" saves the generated pathname for everything later, including a later startup as well. (5) As Michal explained to me, renames are not supported generally anyway, so that's fine. I hope we're not missing anything. I should really test this, but I&#x

Re: [libvirt] [PATCH] qemu: command: Allow UEFI for non-x86

On 10/15/14 15:55, Michal Privoznik wrote: > On 14.10.2014 09:42, Cole Robinson wrote: >> It's supported on aarch64 and armv7l as well, so just drop the >> restriction >> entirely since it doesn't add much. >> --- >> src/qemu/qemu_command.c | 8 >> 1 file changed, 8 deletions(-) >> >> d

Re: [libvirt] [PATCH] qemu: Support OVMF on aarch64 guests

On 11/19/14 17:42, Michal Privoznik wrote: > On 19.11.2014 17:28, Cole Robinson wrote: >> On 11/19/2014 11:22 AM, Daniel P. Berrange wrote: >>> On Wed, Nov 19, 2014 at 11:17:30AM -0500, Cole Robinson wrote: On 11/19/2014 11:13 AM, Daniel P. Berrange wrote: > On Wed, Nov 19, 2014 at 10:40:0

Re: [libvirt] [PATCH] qemu: Support OVMF on aarch64 guests

On 11/19/14 17:46, Daniel P. Berrange wrote: > On Wed, Nov 19, 2014 at 05:42:35PM +0100, Michal Privoznik wrote: >> On 19.11.2014 17:28, Cole Robinson wrote: >>> On 11/19/2014 11:22 AM, Daniel P. Berrange wrote: On Wed, Nov 19, 2014 at 11:17:30AM -0500, Cole Robinson wrote: > On 11/19/2014

Re: [libvirt] [PATCH] qemu: Support OVMF on aarch64 guests

On 11/19/14 18:02, Daniel P. Berrange wrote: > On Wed, Nov 19, 2014 at 05:57:24PM +0100, Laszlo Ersek wrote: >> On 11/19/14 17:46, Daniel P. Berrange wrote: >>> This arch check for OVMF is an arbitrary check placed in libvirt >>> code which is not related to the cur

Re: [libvirt] [PATCH v2] qemu: Allow UEFI paths to be specified at compile time

On 12/02/14 20:57, Cole Robinson wrote: > On 12/02/2014 07:51 AM, Michal Privoznik wrote: >> Up until now there are just two ways how to specify UEFI paths to >> libvirt. The first one is editing qemu.conf, the other is editing >> qemu_conf.c and recompile. Therefore, two new configure options >> a

Re: [libvirt] [PATCH] qga: ignore non present cpus when handling qmp_guest_get_vcpus()

On 08/31/18 10:00, Igor Mammedov wrote: > On Thu, 30 Aug 2018 17:51:13 +0200 > Laszlo Ersek wrote: > >> +Drew >> >> On 08/30/18 14:08, Igor Mammedov wrote: >>> If VM has VCPUs plugged sparselly (for example a VM started with >>> 3 VCPUs (cpu0, cpu

[libvirt] [qemu PATCH] docs/interop: add "firmware.json"

c: David Gibson Cc: Eric Blake Cc: Gerd Hoffmann Cc: Kashyap Chamarthy Cc: Markus Armbruster Cc: Paolo Bonzini Cc: Thomas Huth Signed-off-by: Laszlo Ersek --- Notes: PATCH: - previous version (RFCv3) was posted at: <20180420231246.23130-4-lersek@redhat.com">h

Re: [libvirt] [Qemu-devel] [qemu PATCH] docs/interop: add "firmware.json"

On 05/09/18 17:04, Laszlo Ersek wrote: > Add a schema that describes the different uses and properties of virtual > machine firmware. > > Each firmware executable installed on a host system should come with at > least one JSON file that conforms to this schema. Each file informs t

[libvirt] [qemu PATCH v2] docs/interop: add "firmware.json"

c: David Gibson Cc: Eric Blake Cc: Gerd Hoffmann Cc: Kashyap Chamarthy Cc: Markus Armbruster Cc: Paolo Bonzini Cc: Thomas Huth Signed-off-by: Laszlo Ersek --- Notes: PATCHv2: - previous version (PATCHv1) was posted at: <20180509150431.4979-1-lersek@redhat.com">h

Re: [libvirt] [Qemu-devel] [qemu PATCH v2] docs/interop: add "firmware.json"

On 05/15/18 11:49, Gerd Hoffmann wrote: > On Wed, May 09, 2018 at 05:26:08PM +0200, Laszlo Ersek wrote: >> Add a schema that describes the different uses and properties of virtual >> machine firmware. >> >> Each firmware executable installed on a host system should com

Re: [libvirt] [Qemu-devel] [qemu PATCH v2] docs/interop: add "firmware.json"

On 05/24/18 18:23, Paolo Bonzini wrote: > On 24/05/2018 18:21, Laszlo Ersek wrote: >> On 05/15/18 11:49, Gerd Hoffmann wrote: >>> On Wed, May 09, 2018 at 05:26:08PM +0200, Laszlo Ersek wrote: >>>> Add a schema that describes the different uses and properties of

Re: [libvirt] [PATCH 2/5] qemu: Move checks for SMM from command-line creation into validation phase

adding qemu-devel, Paolo and Gerd; comments below: On 05/30/18 23:08, Martin Kletzander wrote: > On Wed, May 30, 2018 at 11:02:59AM -0400, John Ferlan wrote: >> >> >> On 05/21/2018 11:00 AM, Martin Kletzander wrote: >>> We are still hoping all of such checks will be moved there and this >>> is one

Re: [libvirt] [PATCH 2/4] conf, schema, docs: Add support for TSEG size setting

h > +++ b/src/conf/domain_conf.h > @@ -2421,6 +2421,9 @@ struct _virDomainDef { > char *hyperv_vendor_id; > int apic_eoi; > > +bool tseg_specified; > +unsigned long long tseg_size; > + > virDomainClockDef clock; > > size_t ngraphics; > diff --git a/tests/genericxml2xmlindata/tseg.xml > b/tests/genericxml2xmlindata/tseg.xml > new file mode 100644 > index ..49483f874cd4 > --- /dev/null > +++ b/tests/genericxml2xmlindata/tseg.xml > @@ -0,0 +1,23 @@ > + > + QEMUGuest1 > + c7a5fdbd-edaf-9455-926a-d65c16db1809 > + 219100 > + 219100 > + 1 > + > +hvm > + > + > + > + > + 48 > + > + > + > + destroy > + restart > + destroy > + > +/usr/bin/qemu-system-x86_64 > + > + > diff --git a/tests/genericxml2xmltest.c b/tests/genericxml2xmltest.c > index d8270a6cae82..daad6e0f78d8 100644 > --- a/tests/genericxml2xmltest.c > +++ b/tests/genericxml2xmltest.c > @@ -141,6 +141,8 @@ mymain(void) > DO_TEST_FULL("cachetune-colliding-types", false, true, > TEST_COMPARE_DOM_XML2XML_RESULT_FAIL_PARSE); > > +DO_TEST("tseg"); > + > virObjectUnref(caps); > virObjectUnref(xmlopt); > > I checked the commit message and the docs; they look OK to me. Acked-by: Laszlo Ersek Thanks, Laszlo -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 4/4] qemu: Add support for setting the TSEG size

On 06/07/18 21:58, Ján Tomko wrote: > Does a size of 0 MiB make sense? It's divisible by 1 MiB. "-global mch.extended-tseg-mbytes=0" makes QEMU behave as if it lacked the extended TSEG feature; the guest will believe that only the standard 1 / 2 / 8 MB TSEG sizes are available, and pick one of th

Re: [libvirt] [PATCH 4/4] qemu: Add support for setting the TSEG size

On 06/07/18 23:14, Martin Kletzander wrote: > @Laszlo: When thinking about it, even though it is a very stupid idea, > technically there isn't really a difference between > 'extended-tseg-mbytes=0' and > 'extended-tseg-mbytes=8' that's correct > (of course the second option will still provide a

Re: [libvirt] [PATCH v4 3/3] hw/vfio/display: add ramfb support

On 06/14/18 00:36, Gerd Hoffmann wrote: > On Wed, Jun 13, 2018 at 01:50:47PM -0600, Alex Williamson wrote: >> I suppose in the UEFI case runtime services can be used to continue >> writing this display, > > Yes. Small clarification for the wording -- "UEFI runtime services" do not include anythi

Re: [libvirt] Configuring pflash devices for OVMF firmware

Hi Markus, On 02/07/19 10:30, Markus Armbruster wrote: > The thread got long, let me try to summarize, and elaborate a few > points. > > * The problem at hand is configuring firmware residing in flash memory > (OVMF requires this) without legacy -drive. > > * The wider problem is configuring o

Re: [libvirt] [PATCH v1 02/15] qemu_domain: Separate NVRAM VAR store file name generation

efPtr def); > + > #endif /* LIBVIRT_QEMU_DOMAIN_H */ > I'm not familiar with restrictions on helper functions (e.g. if they are supposed to sanity check input params for null pointers etc), but as a normal code extraction patch, this looks OK to me. Also presumably the other call will arrive from a different C file, hence the external linkage and header file change. Reviewed-by: Laszlo Ersek Thanks Laszlo -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v1 03/15] qemu_capabilities: Expose qemu <-> libvirt arch translators

chFromString(const char *arch); > +const char *virQEMUCapsArchToString(virArch arch); > + > #endif /* LIBVIRT_QEMU_CAPABILITIES_H */ > Reviewed-by: Laszlo Ersek -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v1 04/15] virDomainLoaderDefParseXML: Allow loader path to be NULL

;>%s\n", loader->path); > +else > +virBufferAddLit(buf, "/>\n"); > if (loader->nvram || loader->templt) { > virBufferAddLit(buf, " virBufferEscapeString(buf, " template='%s'", loader->templt); > I think this patch does what it says on the tin, but I'm not sure myself if "what it says on the tin" is the right thing to do. (In other words, whether the syntax proposed in the blurb is indeed our end-goal.) I don't doubt it, I just don't have an opinion. So I'll defer to Dan on this patch. Technically, it looks OK to me. With the commit message update: Reviewed-by: Laszlo Ersek Thanks Laszlo -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v1 05/15] conf: Introduce VIR_DOMAIN_LOADER_TYPE_NONE

ary? Hm... I assume, due to the enum auto-generation in libvirt, the introduction of "none" will automatically cause virDomainLoaderTypeFromString() to recognize "none" as value 0. But we want to act like "none" isn't a valid value (it's internal use only). Henc

Re: [libvirt] [PATCH v1 06/15] conf: Introduce firmware attribute to

On 02/27/19 11:04, Michal Privoznik wrote: > The idea is that using this attribute users enable libvirt to > automagically select firmware image for their domain. For > instance: > > > hvm > > > > > hvm > > > (The automagic of selecting firmware image will be described i

Re: [libvirt] [PATCH v1 07/15] qemu: Introduce basic skeleton for parsing firmware description

On 02/27/19 11:04, Michal Privoznik wrote: > The firmware description is a JSON file which follows > specification from qemu.git/docs/interop/firmware.json. The > description file basically says: Firmware file X is {bios|uefi}, > supports these targets and machine types, requires these features > t

Re: [libvirt] [PATCH v1 08/15] test: Introduce qemufirmwaretest

On 02/27/19 11:04, Michal Privoznik wrote: > Test firmware description parsing so far. > > Signed-off-by: Michal Privoznik > --- > tests/Makefile.am | 9 > tests/qemufirmwaredata/40-bios.json| 35 + > tests/qemufirmwaredata/50-ovmf-sb.json | 36

Re: [libvirt] [PATCH v1 09/15] qemu_firmware: Introduce qemuFirmwareFetchConfigs

On 02/27/19 11:04, Michal Privoznik wrote: > Implementation for yet another part of firmware description > specification. This one covers selecting which files to parse. > > There are three locations from which description files can be > loaded. In order of preference, from most generic to most >

Re: [libvirt] [PATCH v1 10/15] qemufirmwaretest: Test qemuFirmwareFetchConfigs()

On 02/27/19 11:04, Michal Privoznik wrote: > Signed-off-by: Michal Privoznik > --- > tests/Makefile.am | 1 + > .../etc/qemu/firmware/40-ovmf-sb.json | 1 + > .../etc/qemu/firmware/60-ovmf.json| 0 > .../user/.config/qemu/firmware/10-bios.json

Re: [libvirt] [PATCH v1 11/15] qemu_firmware: Introduce qemuFirmwareFillDomain()

On 02/27/19 11:04, Michal Privoznik wrote: > And finally the last missing piece. This is what puts it all > together. > > At the beginning, qemuFirmwareFillDomain() loads all possible > firmware description files based on algorithm described earlier. > Then it tries to find description which match

Re: [libvirt] [PATCH v1 13/15] qemuDomainDefValidate: Don't require SMM if automatic firmware selection enabled

On 02/27/19 11:04, Michal Privoznik wrote: > The firmware selection code will enable the feature if needed. > There's no need to require SMM to be enabled in that case. > > Signed-off-by: Michal Privoznik > --- > src/qemu/qemu_domain.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) >

Re: [libvirt] [PATCH v1 11/15] qemu_firmware: Introduce qemuFirmwareFillDomain()

On 03/05/19 15:38, Michal Privoznik wrote: > On 2/28/19 12:15 PM, Laszlo Ersek wrote: >> On 02/27/19 11:04, Michal Privoznik wrote: >>> And finally the last missing piece. This is what puts it all >>> together. >>> >>> At the beginning, qemuFirmwar

Re: [libvirt] [PATCH v1 08/15] test: Introduce qemufirmwaretest

On 03/05/19 15:38, Michal Privoznik wrote: > On 2/28/19 10:42 AM, Laszlo Ersek wrote: >> On 02/27/19 11:04, Michal Privoznik wrote: >>> Test firmware description parsing so far. >>> >>> Signed-off-by: Michal Privoznik >>> --- >>>   tests/

Re: [libvirt] [PATCH v1 07/15] qemu: Introduce basic skeleton for parsing firmware description

On 03/05/19 15:38, Michal Privoznik wrote: > On 2/28/19 10:31 AM, Laszlo Ersek wrote: >> On 02/27/19 11:04, Michal Privoznik wrote: >>> The firmware description is a JSON file which follows >>> specification from qemu.git/docs/interop/firmware.json. The >>

Re: [libvirt] [PATCH v2 04/15] virDomainLoaderDefParseXML: Allow loader path to be NULL

implemented do not really allow the path to be NULL. Only move > code around to prepare it for further expansion. > > Signed-off-by: Michal Privoznik > Reviewed-by: Laszlo Ersek > --- > docs/schemas/domaincommon.rng | 4 +++- > src/conf/domain_conf.c| 29 +

Re: [libvirt] [PATCH v2 08/15] test: Introduce qemufirmwaretest

VMF_VARS.fd", > +"format": "raw" > + } > +}, > +"targets": [ > +{ > +"architecture": "x86_64", > +"machines": [ > +"pc-q35-*" &

Re: [libvirt] [PATCH v2 09/15] qemu_firmware: Introduce qemuFirmwareFetchConfigs

ize of '%s'"), > + path); > +return -1; > +} > + > +VIR_DEBUG("firmware description path '%s' len=%jd", > + path, (intmax_t) len); > + > +if (len == 0) { &g

Re: [libvirt] [PATCH v2 09/15] qemu_firmware: Introduce qemuFirmwareFetchConfigs

On 03/07/19 13:46, Michal Privoznik wrote: > On 3/7/19 12:55 PM, Daniel P. Berrangé wrote: >> On Thu, Mar 07, 2019 at 10:29:19AM +0100, Michal Privoznik wrote: >>> Implementation for yet another part of firmware description >>> specification. This one covers selecting which files to parse. >>> >>>

Re: [libvirt] [PATCH v2 10/15] qemufirmwaretest: Test qemuFirmwareFetchConfigs()

(adding Dan) On 03/07/19 10:29, Michal Privoznik wrote: > Signed-off-by: Michal Privoznik > --- > tests/Makefile.am | 1 + > .../etc/qemu/firmware/40-ovmf-sb-keys.json| 1 + > .../etc/qemu/firmware/60-ovmf-sb.json | 0 > .../user/.config/qemu/firmware/1

Re: [libvirt] [PATCH v2 11/15] qemu_firmware: Introduce qemuFirmwareFillDomain()

U_FIRMWARE_FEATURE_VERBOSE_STATIC: > +case QEMU_FIRMWARE_FEATURE_LAST: > +break; > +} > +} > + > +return 0; > +} > + > + > +static void > +qemuFirmwareSanityCheck(const qemuFirmware *fw, > +

Re: [libvirt] [PATCH v2 13/15] qemuDomainDefValidate: Don't require SMM if automatic firmware selection enabled

This makes sense. It restricts the check to the case when the new feature is not active. And the new feature does take care of it, in qemuFirmwareFillDomain() -> qemuFirmwareEnableFeatures(). Reviewed-by: Laszlo Ersek Thanks Laszlo -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v2 10/15] qemufirmwaretest: Test qemuFirmwareFetchConfigs()

On 03/12/19 12:20, Daniel P. Berrangé wrote: > On Tue, Mar 12, 2019 at 12:13:46PM +0100, Laszlo Ersek wrote: >> (adding Dan) >> >> On 03/07/19 10:29, Michal Privoznik wrote: >>> Signed-off-by: Michal Privoznik >>> --- >>> tests/Makefile.am

Re: [libvirt] [PATCH v2 15/15] qemuxml2argvtest: Test os.firmware autoselection

On 03/12/19 16:15, Michal Privoznik wrote: > On 3/11/19 4:27 PM, Daniel P. Berrangé wrote: >> On Thu, Mar 07, 2019 at 10:29:25AM +0100, Michal Privoznik wrote: >>> Signed-off-by: Michal Privoznik >>> --- >>>   tests/Makefile.am |  4 +- >>>   ...arch64-os-firmware-efi.aa

Re: [libvirt] [Qemu-devel] [PULL v3 00/54] Kconfig conversion, excluding ARM and MIPS

Hi Paolo, (+libvir-list) I'd like to report a regression introduced by this patch set: On 03/07/19 21:58, Paolo Bonzini wrote: > The following changes since commit > 6cb4f6db4f4367faa33da85b15f75bbbd2bed2a6: > > Merge remote-tracking branch > 'remotes/cleber/tags/python-next-pull-request' in

Re: [libvirt] [Qemu-devel] [PULL v3 00/54] Kconfig conversion, excluding ARM and MIPS

On 03/21/19 01:53, Laszlo Ersek wrote: > Hi Paolo, > > (+libvir-list) > > I'd like to report a regression introduced by this patch set: > > On 03/07/19 21:58, Paolo Bonzini wrote: >> The following changes since commit >> 6cb4f6db4f4367faa33da85b15f75bbbd

Re: [libvirt] [Qemu-devel] [PULL v3 00/54] Kconfig conversion, excluding ARM and MIPS

On 03/21/19 14:04, Peter Maydell wrote: > On Thu, 21 Mar 2019 at 12:40, Laszlo Ersek wrote: >> In brief, the regression is that the aarch64 system emulator now lists >> the "virtio-vga" device for the "virt" machine type: >> >> $ qemu-system-aarch

Re: [libvirt] [Qemu-devel] [PULL v3 00/54] Kconfig conversion, excluding ARM and MIPS

On 03/21/19 15:21, Philippe Mathieu-Daudé wrote: > Le jeu. 21 mars 2019 13:39, Laszlo Ersek a écrit : > >> On 03/21/19 01:53, Laszlo Ersek wrote: >>> Hi Paolo, >>> >>> (+libvir-list) >>> >>> I'd like to report a regression introduc

Re: [libvirt] [Qemu-devel] [PULL v3 00/54] Kconfig conversion, excluding ARM and MIPS

On 03/21/19 18:58, Peter Maydell wrote: > On Thu, 21 Mar 2019 at 17:35, Laszlo Ersek wrote: >> It simply keeps the status quo from before the patchset. >> >> The specific emulation targets that virtio-vga should not be enabled for >> (regardless of other targets / mac

Re: [libvirt] Configuring pflash devices for OVMF firmware

(+Peter, keeping the context) On 01/25/19 16:03, Markus Armbruster wrote: > We configure OVMF firmware for PC machine types with -drive if=pflash. > This is pretty much the last remaining use of -drive in libvirt we can't > yet replace by -blockdev. Such a replacement is desirable, because > -blo

Re: [libvirt] [Qemu-devel] Configuring pflash devices for OVMF firmware

On 01/28/19 14:06, Peter Maydell wrote: > On Mon, 28 Jan 2019 at 12:40, Gerd Hoffmann wrote: >> The tricky part is the access control here. On physical hardware you >> typically have one flash rom, say 16M below 4G (on x86). >> >> Our pflash device doesn't allow to define multiple regions, so we

Re: [libvirt] [Qemu-devel] Configuring pflash devices for OVMF firmware

On 01/28/19 15:58, Peter Maydell wrote: > On Mon, 28 Jan 2019 at 14:56, Laszlo Ersek wrote: >> Regarding OVMF, I kept the flash driver intentionally in the dark about >> split vs. unified pflash, so OVMF will not care, as long as the same >> GPAs behave the same as be

Re: [libvirt] [Qemu-devel] Configuring pflash devices for OVMF firmware

On 01/30/19 15:33, Paolo Bonzini wrote: > On 30/01/19 15:13, Markus Armbruster wrote: >> -global driver=cfi.pflash01,property=secure,value=on >> >> Affects *all* such devices, but fortunately we have at most two, and >> the one we don't want to affect happens to ignore the property value. > > I

Re: [libvirt] [Qemu-devel] Configuring pflash devices for OVMF firmware

On 01/30/19 16:24, Peter Maydell wrote: > Well, nobody who does anything with x86 has cared enough to > make the pflash implementation actually correct. I feel sort of included under this umbrella, so: I haven't been aware of any particular pflash implementation errors. I "didn't care" because i

Re: [libvirt] [Qemu-devel] Configuring pflash devices for OVMF firmware

On 01/31/19 10:19, Paolo Bonzini wrote: > On 31/01/19 09:40, Markus Armbruster wrote: >>> Maybe we should just add pflash block properties to the machine? And >>> then it can create the devices if the properties are set to a non-empty >>> value. >> What exactly do you have in mind? Something like

Re: [libvirt] [Qemu-devel] Configuring pflash devices for OVMF firmware

On 01/31/19 10:37, Markus Armbruster wrote: > Paolo Bonzini writes: > >> On 31/01/19 09:33, Markus Armbruster wrote: >>> I thought secure=on affected only writes (and so wouldn't matter with >>> readonly=on), but I was wrong: >>> >>> static MemTxResult pflash_mem_read_with_attrs(void *opaque,

Re: [libvirt] [RFC] Defining firmware (OVMF, et al) metadata format & file

On 03/08/18 11:17, Daniel P. Berrangé wrote: > On Thu, Mar 08, 2018 at 08:52:45AM +0100, Gerd Hoffmann wrote: >> Hi, >> [*] Open question: Who, between QEMU and libvirt, should define the said firmware metadata format and file? >>> >>> IMHO QEMU should be defining the format, because th

Re: [libvirt] [RFC] Defining firmware (OVMF, et al) metadata format & file

On 04/06/18 20:10, Eric Blake wrote: > On 04/06/2018 12:28 PM, Laszlo Ersek wrote: > >> I've created an RFC-level "qapi/firmware.json" schema file, based on >> this discussion. It "builds", and the generated documentation looks >> acceptable,

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

oth Cc: Michal Privoznik Cc: Peter Krempa Cc: Peter Maydell Cc: Thomas Huth Signed-off-by: Laszlo Ersek --- Notes: Folks on the CC list, please try to see if the suggested schema is flexible enough to describe the virtual firmware(s) that you are familiar with. Tha

  1   2   3   >