On 3/22/23 1:00 PM, Tim Wiederhake wrote:
On Wed, 2023-03-22 at 11:39 -0400, Collin Walling wrote:
Allows for the query of hypervisor-known CPU models via the simple
command: virsh hypervisor-cpu-models. For the QEMU driver, the models
are queried via the capabilities file. Each model is
On Wed, 2023-03-22 at 11:39 -0400, Collin Walling wrote:
> Allows for the query of hypervisor-known CPU models via the simple
> command: virsh hypervisor-cpu-models. For the QEMU driver, the models
> are queried via the capabilities file. Each model is printed to the
> terminal on its own line
On Wed, Mar 22, 2023 at 11:37:10AM -0500, Andrea Bolognani wrote:
> On Wed, Mar 22, 2023 at 10:36:20AM -0300, Daniel Henrique Barboza wrote:
> > I'm not sure if the OS overwrites the firmware when running bare metal.
> > Usually
> > they provide different OS images for QEMU/libvirt and bare metal
On Wed, Mar 22, 2023 at 10:36:20AM -0300, Daniel Henrique Barboza wrote:
> I'm not sure if the OS overwrites the firmware when running bare metal.
> Usually
> they provide different OS images for QEMU/libvirt and bare metal systems,
> probably
> to account for these differences. Baking the
On Wed, Mar 22, 2023 at 05:13:06PM +0100, Boris Fiuczynski wrote:
> On 3/22/23 4:53 PM, Daniel P. Berrangé wrote:
> > On Wed, Mar 22, 2023 at 11:39:17AM -0400, Collin Walling wrote:
> > > This command is a virsh wrapper for virConnectGetHypervisorCPUNames.
> > >
> > > Signed-off-by: Collin
On Wed, Mar 22, 2023 at 10:40:33AM -0300, Daniel Henrique Barboza wrote:
> On 3/22/23 10:02, Andrea Bolognani wrote:
> > On Wed, Mar 22, 2023 at 09:32:21AM -0300, Daniel Henrique Barboza wrote:
> > > VIR_DOMAIN_LOADER_TYPE_OTHER seems more appropriate to indicate that the
> > > firmware
> > >
On 3/22/23 4:53 PM, Daniel P. Berrangé wrote:
On Wed, Mar 22, 2023 at 11:39:17AM -0400, Collin Walling wrote:
This command is a virsh wrapper for virConnectGetHypervisorCPUNames.
Signed-off-by: Collin Walling
Reviewed-by: Boris Fiuczynski
---
docs/manpages/virsh.rst | 20
On Wed, Mar 22, 2023 at 11:39:17AM -0400, Collin Walling wrote:
> This command is a virsh wrapper for virConnectGetHypervisorCPUNames.
>
> Signed-off-by: Collin Walling
> Reviewed-by: Boris Fiuczynski
> ---
> docs/manpages/virsh.rst | 20
> tools/virsh-host.c | 70
On Wed, Mar 22, 2023 at 11:39:15AM -0400, Collin Walling wrote:
> The new API collects a list of CPU model names supported by the
> specified hypervisor. This is a more useful version of
> virConnectGetCPUNames, which does not consider any hypervisor
> capabilities when querying model names.
>
>
In vir-host-validate we do two checks related to IOMMU:
1) hardware support, and
2) kernel support.
While users are usually interested in the latter, the former also
makes sense. And for the former (hardware support) we have this
huge if-else block for nearly every architecture, except ARM.
Signed-off-by: Collin Walling
Reviewed-by: Boris Fiuczynski
---
src/remote/remote_driver.c | 1 +
src/remote/remote_protocol.x | 20 +++-
src/remote_protocol-structs | 11 +++
3 files changed, 31 insertions(+), 1 deletion(-)
diff --git a/src/remote/remote_driver.c
This command is a virsh wrapper for virConnectGetHypervisorCPUNames.
Signed-off-by: Collin Walling
Reviewed-by: Boris Fiuczynski
---
docs/manpages/virsh.rst | 20
tools/virsh-host.c | 70 +
2 files changed, 90 insertions(+)
diff --git
This function is hooked into the virsh hypervisor-cpu-models command.
The CPU models are read directly from the QEMU capabilities file,
which contains a list of all models queried from the hypervisor.
Signed-off-by: Collin Walling
Reviewed-by: Boris Fiuczynski
---
src/qemu/qemu_driver.c | 62
Allows for the query of hypervisor-known CPU models via the simple
command: virsh hypervisor-cpu-models. For the QEMU driver, the models
are queried via the capabilities file. Each model is printed to the
terminal on its own line similar to the cpu-models command, and there
is no order to the
The new API collects a list of CPU model names supported by the
specified hypervisor. This is a more useful version of
virConnectGetCPUNames, which does not consider any hypervisor
capabilities when querying model names.
Signed-off-by: Collin Walling
Reviewed-by: Boris Fiuczynski
---
On Wed, Mar 22, 2023 at 2:59 PM Michal Privoznik
wrote:
> After cleanup done in v8.2.0-rc1~47 the
> qemuDomainObjExitMonitor() and after v8.7.0-rc1~176 the
> qemuDomainObjEnterMonitor() lost the @driver argument. But
> corresponding ATTRIBUTE_NONNULL() annotation was not removed and
> both
On Wed, Mar 22, 2023 at 2:30 PM Michal Privoznik
wrote:
> The virConnectOpen(), well virConnectOpenInternal() reports an
> error if embed root is not an absolute path. This is a fair
> requirement, but our qemu_shim doesn't check this requirement and
> instead mkdir()-s passed path only to fail
After cleanup done in v8.2.0-rc1~47 the
qemuDomainObjExitMonitor() and after v8.7.0-rc1~176 the
qemuDomainObjEnterMonitor() lost the @driver argument. But
corresponding ATTRIBUTE_NONNULL() annotation was not removed and
both functions are still annotated as ATTRIBUTE_NONNULL(2) even
though they
On 3/22/23 10:05, Daniel P. Berrangé wrote:
On Wed, Mar 22, 2023 at 06:10:18AM -0300, Daniel Henrique Barboza wrote:
Today, trying to boot a RISC-V Fedora Rawhide image in a RISC-V QEMU domain
results in the following error:
error: Failed to start domain 'riscv-fedora'
error: internal
On 3/22/23 10:02, Andrea Bolognani wrote:
On Wed, Mar 22, 2023 at 09:32:21AM -0300, Daniel Henrique Barboza wrote:
On 3/22/23 06:42, Daniel Henrique Barboza wrote:
On 3/22/23 06:25, Daniel P. Berrangé wrote:
On Wed, Mar 22, 2023 at 06:10:18AM -0300, Daniel Henrique Barboza wrote:
+ if
The virConnectOpen(), well virConnectOpenInternal() reports an
error if embed root is not an absolute path. This is a fair
requirement, but our qemu_shim doesn't check this requirement and
instead mkdir()-s passed path only to fail later on, leaving the
empty directory behind:
$ ls -d asd
ls:
On Wed, Mar 22, 2023 at 09:32:21AM -0300, Daniel Henrique Barboza wrote:
> On 3/22/23 06:42, Daniel Henrique Barboza wrote:
> > On 3/22/23 06:25, Daniel P. Berrangé wrote:
> > > On Wed, Mar 22, 2023 at 06:10:18AM -0300, Daniel Henrique Barboza wrote:
> > > > + if (loader->type !=
On Wed, Mar 22, 2023 at 06:10:18AM -0300, Daniel Henrique Barboza wrote:
> Today, trying to boot a RISC-V Fedora Rawhide image in a RISC-V QEMU domain
> results in the following error:
>
>
> error: Failed to start domain 'riscv-fedora'
> error: internal error: process exited while connecting
On 3/22/23 06:42, Daniel Henrique Barboza wrote:
On 3/22/23 06:25, Daniel P. Berrangé wrote:
On Wed, Mar 22, 2023 at 06:10:18AM -0300, Daniel Henrique Barboza wrote:
Today, trying to boot a RISC-V Fedora Rawhide image in a RISC-V QEMU domain
results in the following error:
error:
On 3/15/23 17:02, Ján Tomko wrote:
> Otherwise looking up a secret fails when we try to elevate the identity
> in qemuDomainSecretInfoSetupFromSecret.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=2000410
>
> Signed-off-by: Ján Tomko
> ---
> src/qemu/qemu_shim.c | 5 +
> 1 file changed,
On 3/17/23 15:59, Peter Krempa wrote:
> On Thu, Mar 16, 2023 at 14:21:27 +0100, Ján Tomko wrote:
>> If we don't have dnsmasq, it's pointless to try to find
>> its pidfile.
>>
>> Also, dnsmasqCapsGetBinaryPath would access a NULL pointer.
>>
>> Fixes: 4b68c982e283471575bacbf87302495864da46fe
>>
Hi Alex
Could you please refer to my previous message?
Thank you in advance,
Grzegorz
czw., 9 mar 2023 o 14:41 Grzegorz Jaszczyk napisał(a):
>
> czw., 9 mar 2023 o 00:38 Alex Williamson
> napisał(a):
> >
> > On Wed, 8 Mar 2023 14:44:28 -0800
> > Dominik Behr wrote:
> >
> > > On Wed, Mar 8,
Hi Peter,
I'm missing some clarifications here:
https://listman.redhat.com/archives/libvir-list/2023-March/238546.html
https://listman.redhat.com/archives/libvir-list/2023-March/238548.html
Could you please have a look?
Thanks,
Or
> -Original Message-
> From: Peter Krempa
> Sent:
On 3/22/23 06:25, Daniel P. Berrangé wrote:
On Wed, Mar 22, 2023 at 06:10:18AM -0300, Daniel Henrique Barboza wrote:
Today, trying to boot a RISC-V Fedora Rawhide image in a RISC-V QEMU domain
results in the following error:
error: Failed to start domain 'riscv-fedora'
error: internal
On Wed, Mar 22, 2023 at 06:10:18AM -0300, Daniel Henrique Barboza wrote:
> Today, trying to boot a RISC-V Fedora Rawhide image in a RISC-V QEMU domain
> results in the following error:
>
>
> error: Failed to start domain 'riscv-fedora'
> error: internal error: process exited while connecting
All the code present in qemuFirmwareFillDomain() assumes that
loader->path is always filled if using manual firmware selection.
In the newly added "" case, i.e. without using
firmware autoselection, qemuFirmwareFillDomain() will call
qemuFirmwareFillDomainModern(), which in turn will fetch the
Today, trying to boot a RISC-V Fedora Rawhide image in a RISC-V QEMU domain
results in the following error:
error: Failed to start domain 'riscv-fedora'
error: internal error: process exited while connecting to monitor:
2023-03-20T17:31:02.650862Z qemu-system-riscv64: Some ROM regions are
Signed-off-by: Daniel Henrique Barboza
---
docs/formatdomain.rst | 7 +++
1 file changed, 7 insertions(+)
diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst
index 27f83e254d..3529c7a9c5 100644
--- a/docs/formatdomain.rst
+++ b/docs/formatdomain.rst
@@ -263,6 +263,13 @@ harddisk,
Also add a qemuxml2argvtest to ensure that we're good.
Signed-off-by: Daniel Henrique Barboza
---
src/qemu/qemu_command.c | 6
.../firmware-bios-none.riscv64-latest.args| 31 +++
tests/qemuxml2argvdata/firmware-bios-none.xml | 18 +++
Hi,
Fedora Rawhide for RISC-V requires '-bios none' to properly boot
because its kernel is overwriting the default OpenSBI binary QEMU uses,
causing the following error:
$ sudo ./run tools/virsh start --console riscv-fedora
error: Failed to start domain 'riscv-fedora'
error: internal error:
35 matches
Mail list logo