I understand and thank you very much for your meticulous explanation.
> -Original Message-
> From: Michal Prívozník
> Sent: Wednesday, February 23, 2022 8:16 PM
> To: Huang, Haibin ; libvir-list@redhat.com;
> berra...@redhat.com; Ding, Jian-feng ; Yang, Lin
> A ; Lu, Lianhao
> Subject:
Extending management apps using libvirt to support measured launch of
QEMU guests with SEV/SEV-ES is unreasonably complicated today, both for
the guest owner and for the cloud management apps. We have APIs for
exposing info about the SEV host, the SEV guest, guest measurements
and secret
On 2/22/22 17:04, Erik Skultety wrote:
> So, we're offloading as much CI configuration/workflow stuff to lcitool
> as possible. We can generate config files, install/update machines
> (local or remote), dump Dockerfiles...we can't build and run those containers
> locally. Instead, we have a CI
On 2/23/22 14:03, Daniel P. Berrangé wrote:
> By using the auto-generated NVRAM path in test data files, we won't see
> bugs where a user specified path gets accidentally overwritten by a
> post-parse callback, or VM startup. For example, this caused us to miss
> the bug fixed by:
>
> commit
On 2/17/22 12:54, Daniel P. Berrangé wrote:
> Currently the 'nvram_template' entry is mandatory when parsing the
> firmware descriptor based on flash. QEMU is extending the firmware
> descriptor spec to make the 'nvram_template' optional, depending
> on the value of a new 'mode' field:
>
> -
On 2/23/22 14:01, Daniel P. Berrangé wrote:
> When undefining a VM, we must optionally delete any NVRAM that might
> exist. When using firmware auto-select we always check the generated
> path, ignoring any user specified path.
>
> Signed-off-by: Daniel P. Berrangé
> ---
>
I have just tagged v8.1.0-rc1 in the repository and pushed signed
tarballs and source RPMs to https://libvirt.org/sources/
Please give the release candidate some testing and in case you find a
serious issue which should have a fix in the upcoming release, feel
free to reply to this thread to make
On a Wednesday in 2022, Peter Krempa wrote:
'qemuDomainPrepareDiskSourceData' propagates 'detect_zeroes' only for
the disk source image, but the mirror destination has the ambition to
replace the disk source when the job is finished, so we need to
propagate the 'detect_zeroes' setting also in
On Wed, Feb 23, 2022 at 02:33:04PM +0100, Peter Krempa wrote:
> On Wed, Feb 23, 2022 at 14:17:40 +0100, Kashyap Chamarthy wrote:
> > On Tue, Feb 22, 2022 at 05:55:38PM +0100, Peter Krempa wrote:
[...]
> > Now to construct a reproducer with `virsh`. Peter, tell me what I got
> > wrong :-)
> >
On Wed, Feb 23, 2022 at 14:17:40 +0100, Kashyap Chamarthy wrote:
> On Tue, Feb 22, 2022 at 05:55:38PM +0100, Peter Krempa wrote:
> > In case when a user starts a block copy operation with
> > VIR_DOMAIN_BLOCK_COPY_SHALLOW and VIR_DOMAIN_BLOCK_COPY_REUSE_EXT and
> > both the reused image and the
On 2/16/22, 2:25 AM, "Michal Prívozník" wrote:
> > @@ -7920,7 +7925,9 @@ Example: usage of the memory devices
> > 1.2.14` Provide ``nvdimm`` model that adds a Non-Volatile DIMM module.
> > :since:`Since 3.2.0` Provide ``virtio-pmem`` model to add a
> > paravirtualized
> > persistent
This device is an implementation of pcie-root-port, similar to its
sibling pnv-phb3-root-port. Since it's a new model name that Libvirt
automatically sets, we refrain from documenting it to users.
Reviewed-by: Ján Tomko
Signed-off-by: Daniel Henrique Barboza
---
docs/schemas/domaincommon.rng
Reviewed-by: Ján Tomko
Signed-off-by: Daniel Henrique Barboza
---
.../powernv8-root-port.ppc64-latest.args | 35 +
tests/qemuxml2argvdata/powernv8-root-port.xml | 17
tests/qemuxml2argvtest.c | 1 +
.../powernv8-root-port.ppc64-latest.xml
pnv-phb3-root-ports can use an all zeroed address (:00:0.0) as a way
of connecting to a PHB3 bus that has index 0. Today, these addresses
aren't being displayed in the domain XML due to the use of
virPCIDeviceAddressIsEmpty() inside virDomainDeviceInfoFormat(), where
:00:0.0 is considered
If ommited from the controller definition, chip-id defaults to zero.
Reviewed-by: Ján Tomko
Signed-off-by: Daniel Henrique Barboza
---
src/qemu/qemu_domain_address.c | 16 +++-
src/qemu/qemu_validate.c | 5 +
We're going to use the 'targetIndex' element for PowerNV PHBs. Clarify
that the same attribute will have a different meaning in this context.
Signed-off-by: Daniel Henrique Barboza
---
docs/formatdomain.rst | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git
The 'chip-id' attribute indicates which chip/socket that owns the
PowerNV pcie-root controller.
Reviewed-by: Ján Tomko
Reviewed-by: Peter Krempa
Signed-off-by: Daniel Henrique Barboza
---
docs/formatdomain.rst | 6 ++
docs/schemas/domaincommon.rng | 5 +
Reviewed-by: Ján Tomko
Signed-off-by: Daniel Henrique Barboza
---
src/conf/domain_conf.c | 19 +++
src/conf/domain_conf.h | 1 +
src/libvirt_private.syms | 1 +
3 files changed, 21 insertions(+)
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index
Apart from being usable only with pnv-phb3 PCIE host bridges (to be
added soon), this device acts as a regular pcie-root-port but with a
specific model name.
No doc changes in formatdomain.rst were made because the PCI model name
isn't something that users are supposed to be setting or changing.
The identation of VIR_DOMAIN_CONTROLLER_TYPE_PCI elements are in the
same level as the parent 'if (def->type == ...TYPE_PCI)' clause,
and the closing bracket of this 'if' looks like a misplaced bracket
of the 'targetIndex' clause that comes right before it.
Reviewed-by: Peter Krempa
Reviewed-by:
Similar to the existing pnv-phb3 device, pnv-phb4 is also an
implementation of pcie-root. No user doc is needed in this case since
the user doesn't ideally set PCI model names manually.
Reviewed-by: Ján Tomko
Signed-off-by: Daniel Henrique Barboza
---
docs/schemas/domaincommon.rng | 1 +
Add support for the pcie-root implementation that PowerNV8 domains uses,
pnv-phb3.
It consists of a PCI model name that isn't supposed to be changed by
users, so no doc changes in formatdomain.rst were made.
Reviewed-by: Ján Tomko
Signed-off-by: Daniel Henrique Barboza
---
Both PowerNV and pSeries machines don't support parallel ports.
Reviewed-by: Ján Tomko
Reviewed-by: Peter Krempa
Signed-off-by: Daniel Henrique Barboza
---
src/qemu/qemu_validate.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/qemu/qemu_validate.c
Update the virDomainControllerIsPowerNVPHB() helper to make the pnv-phb4
device receive the same handling as the existing pnv-phb3.
Reviewed-by: Ján Tomko
Signed-off-by: Daniel Henrique Barboza
---
src/conf/domain_conf.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
Since the nuances of PowerNV PHBs and root ports were already handled
when adding support for pnv-phb3* devices, we're already set to support
PowerNV9 PHBs and root ports as well.
Reviewed-by: Ján Tomko
Signed-off-by: Daniel Henrique Barboza
---
.../powernv9-dupPHBs.ppc64-latest.err |
Make the virDomainControllerIsPowerNVRootPort() helper recognize
pnv-phb4-root-port as a PowerNV root port. This will spare us from
duplicating checks where the constraints of pnv-phb3-root-port also
applies for the pnv-phb4-root-port device.
Reviewed-by: Ján Tomko
Signed-off-by: Daniel Henrique
Add 'virt type' to allow for an easier time debugging.
Reviewed-by: Ján Tomko
Reviewed-by: Peter Krempa
Signed-off-by: Daniel Henrique Barboza
---
src/qemu/qemu_validate.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/qemu/qemu_validate.c
PowerNV domains will support pcie-root devices as PHBs, in a similar
fashion as pSeries domains supports the spapr-pci-host-bridge as a
pci-root model.
Set 'addPCIRoot' to false since we'll not be using this buses in this
machine. 'addDefaultMemballoon' is also set to false since the balloon
The PowerNV machines uses ISA as the default serial type.
Reviewed-by: Ján Tomko
Reviewed-by: Peter Krempa
Signed-off-by: Daniel Henrique Barboza
---
src/qemu/qemu_domain.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
index
These devices must have unique targetIndex/chip-id pairs.
Signed-off-by: Daniel Henrique Barboza
---
src/conf/domain_conf.c| 35 +++
tests/qemuxml2argvdata/powernv8-dupPHBs.err | 1 +
.../powernv8-dupPHBs.ppc64-latest.err | 1 +
The PowerNV PHB3 bus has minimal slot zero. In fact, at this moment, the
root complex accepts only a single device, at slot 0x0, due to firmware
limitations. The single device restriction is subject to change in
upstream QEMU and it's not worth adding this limitation to Libvirt.
However, the
Hi,
This new version contains changes proposed by Jano. The most notable
change is on patch 9, where pnv_pnv3/pnv_phb4 capabilities are now being
probed and, if the QEMU version isn't high enough, they are cleared from
qemuCaps.
For convenience, the patches that are pending review/acks are
This capability enables two devices:
- pnv-phb4 device, the pcie-root controller for PowerNV9 domains
- pnv-phb4-root-port, the pcie-root-port model that is used with the
pnv-phb4 device.
As with the pnv-phb3 devices, these are also user creatable only after
QEMU 6.2.0 but the capability is
PowerNV PHBs uses the 'targetIndex' attribute in a different manner than
pSeries PHBs, having no restiction of targetIndex = 0 in controllers
with non-zero indexes.
This can happen when the domain has 2 or more sockets and the pnv-phb3
controller can have targetIndex=0 in a different chip-id.
The command line for the pnv-phb3 device is similar to the
spapr-pci-host-bridge command line but adding the extra 'chip-id'
attribute.
Reviewed-by: Ján Tomko
Signed-off-by: Daniel Henrique Barboza
---
src/qemu/qemu_command.c | 21 +--
As done with the 'chip-id' attribute, use zero as a default
targetIndex value for pnv-phb3 devices in case it's absent
from the controller definition.
Signed-off-by: Daniel Henrique Barboza
---
src/qemu/qemu_domain_address.c| 2 ++
src/qemu/qemu_validate.c
QEMU_CAPS_DEVICE_PNV_PHB3 indicates binary support for the pnv-phb3
device, the pcie-root controller for PowerNV8 domains, and also
the pnv-phb3-root-port device, its pcie-root-port device.
This capability is present in QEMU since 5.0.0 but these devices are
user-creatable only after QEMU 6.2.0.
The function is now unused outside of qemu_domain.c.
Reviewed-by: Ján Tomko
Reviewed-by: Peter Krempa
Signed-off-by: Daniel Henrique Barboza
---
src/qemu/qemu_domain.c | 2 +-
src/qemu/qemu_domain.h | 2 --
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/src/qemu/qemu_domain.c
Both pSeries and PowerNV machines don't have floppy device support.
Reviewed-by: Ján Tomko
Reviewed-by: Peter Krempa
Signed-off-by: Daniel Henrique Barboza
---
src/qemu/qemu_capabilities.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/qemu/qemu_capabilities.c
The PowerNV (Power Non-Virtualized) QEMU ppc64 machine is the emulation
of a bare-metal IBM Power host. It follows the OPAL (OpenPower
Abstration Layer) API/ABI, most specifically Skiboot [1]. For now,
libvirt has support for the pSeries QEMU machine, which is the emulation
of a logical partition
We're now able to boot a simple PowerNV8 domain in libvirt.
Reviewed-by: Ján Tomko
Signed-off-by: Daniel Henrique Barboza
---
.../powernv8-basic.ppc64-latest.args | 33 +++
tests/qemuxml2argvdata/powernv8-basic.xml | 16 +
tests/qemuxml2argvtest.c
On Tue, Feb 22, 2022 at 05:55:38PM +0100, Peter Krempa wrote:
> In case when a user starts a block copy operation with
> VIR_DOMAIN_BLOCK_COPY_SHALLOW and VIR_DOMAIN_BLOCK_COPY_REUSE_EXT and
> both the reused image and the original disk have a backing image libvirt
> specifically does not insert
'qemuDomainPrepareDiskSourceData' propagates 'detect_zeroes' only for
the disk source image, but the mirror destination has the ambition to
replace the disk source when the job is finished, so we need to
propagate the 'detect_zeroes' setting also in that case.
Unfortunately it would become very
When undefining a VM, we must optionally delete any NVRAM that might
exist. When using firmware auto-select we always check the generated
path, ignoring any user specified path.
Signed-off-by: Daniel P. Berrangé
---
src/qemu/qemu_driver.c | 7 +++
1 file changed, 3 insertions(+), 4
By using the auto-generated NVRAM path in test data files, we won't see
bugs where a user specified path gets accidentally overwritten by a
post-parse callback, or VM startup. For example, this caused us to miss
the bug fixed by:
commit 24adb6c7a6cbd8ce5f9de67e6af5d89e0e57c270
Author: Michal
On Wed, Feb 23, 2022 at 12:47:29PM +0100, Michal Prívozník wrote:
> On 2/23/22 11:01, Daniel P. Berrangé wrote:
> > On Wed, Feb 23, 2022 at 10:47:20AM +0100, Michal Prívozník wrote:
> >> On 2/23/22 10:33, Daniel P. Berrangé wrote:
> >>> On Wed, Feb 23, 2022 at 10:16:57AM +0100, Michal Privoznik
Ping.
On Thu, Feb 17, 2022 at 11:54:07AM +, Daniel P. Berrangé wrote:
> Currently the 'nvram_template' entry is mandatory when parsing the
> firmware descriptor based on flash. QEMU is extending the firmware
> descriptor spec to make the 'nvram_template' optional, depending
> on the value of
On Wed, Feb 23, 2022 at 10:56:11AM +0100, Martin Kletzander wrote:
> Commit 4e42686adef8 wrongly assumed how g_variant_new_parsed() works and broke
> starting of domains on systems with systemd (machined).
so IIUC, it isn't a arbitrary printf format, but rather the format
substitutions only get
On Wed, Feb 23, 2022 at 12:25:38PM +, Daniel P. Berrangé wrote:
On Wed, Feb 23, 2022 at 10:56:11AM +0100, Martin Kletzander wrote:
Commit 4e42686adef8 wrongly assumed how g_variant_new_parsed() works and broke
starting of domains on systems with systemd (machined).
so IIUC, it isn't a
On 2/23/22 04:41, Huang, Haibin wrote:
> I accept all comments. But I didn't your point for this comment .
>>> +static void
>>> +virQEMUCapsFormatSGXInfo(virQEMUCaps *qemuCaps, virBuffer *buf) {
>>> +virSGXCapabilityPtr sgx =
>>> +virQEMUCapsGetSGXCapabilities(qemuCaps);
>>> +
>>> +
On Wed, Feb 23, 2022 at 10:56:11 +0100, Martin Kletzander wrote:
> Commit 4e42686adef8 wrongly assumed how g_variant_new_parsed() works and broke
> starting of domains on systems with systemd (machined).
>
> Signed-off-by: Martin Kletzander
> ---
> src/util/virsystemd.c | 12 ++--
> 1
On 2/23/22 11:01, Daniel P. Berrangé wrote:
> On Wed, Feb 23, 2022 at 10:47:20AM +0100, Michal Prívozník wrote:
>> On 2/23/22 10:33, Daniel P. Berrangé wrote:
>>> On Wed, Feb 23, 2022 at 10:16:57AM +0100, Michal Privoznik wrote:
After v8.0.0-466-g08101bde5d we unconditionally regenerate per
On Wed, Feb 23, 2022 at 10:47:20AM +0100, Michal Prívozník wrote:
> On 2/23/22 10:33, Daniel P. Berrangé wrote:
> > On Wed, Feb 23, 2022 at 10:16:57AM +0100, Michal Privoznik wrote:
> >> After v8.0.0-466-g08101bde5d we unconditionally regenerate per
> >> domain NVRAM path even though it might have
Commit 4e42686adef8 wrongly assumed how g_variant_new_parsed() works and broke
starting of domains on systems with systemd (machined).
Signed-off-by: Martin Kletzander
---
src/util/virsystemd.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git
On 2/23/22 10:33, Daniel P. Berrangé wrote:
> On Wed, Feb 23, 2022 at 10:16:57AM +0100, Michal Privoznik wrote:
>> After v8.0.0-466-g08101bde5d we unconditionally regenerate per
>> domain NVRAM path even though it might have been parsed earlier
>> from domain XML. The way we do that leads to a
On Wed, Feb 23, 2022 at 10:16:57AM +0100, Michal Privoznik wrote:
> After v8.0.0-466-g08101bde5d we unconditionally regenerate per
> domain NVRAM path even though it might have been parsed earlier
> from domain XML. The way we do that leads to a memleak:
>
> 43 bytes in 1 blocks are definitely
On Wed, Feb 23, 2022 at 10:16:57 +0100, Michal Privoznik wrote:
> After v8.0.0-466-g08101bde5d we unconditionally regenerate per
> domain NVRAM path even though it might have been parsed earlier
> from domain XML. The way we do that leads to a memleak:
>
> 43 bytes in 1 blocks are definitely
After v8.0.0-466-g08101bde5d we unconditionally regenerate per
domain NVRAM path even though it might have been parsed earlier
from domain XML. The way we do that leads to a memleak:
43 bytes in 1 blocks are definitely lost in loss record 330 of 682
at 0x483F7E5: malloc
58 matches
Mail list logo
