On Tue, Apr 23, 2024 at 2:19 PM Masato Imai wrote:
> When the KVM acceleration parameter is not set, executing calc_dirty_rate
> with the -r option results in a segmentation fault due to accessing a
> null kvm_state pointer in the kvm_dirty_rate_enabled function.
>
s/kvm_dirty_rate_enabled/kvm_d
On Mon, Apr 22, 2024 at 11:02 PM Philippe Mathieu-Daudé
wrote:
>
> On 22/4/24 19:09, Richard Henderson wrote:
> > On 4/22/24 10:07, Richard Henderson wrote:
> >> For cpus using PMSA, when the MPU is disabled, the default memory
> >> type is Normal, Non-cachable.
> >>
> >> Fixes: 59754f85ed3 ("targ
John Snow writes:
> On Mon, Apr 22, 2024 at 5:20 AM Markus Armbruster wrote:
>>
>> John Snow writes:
>>
>> > On Fri, Apr 19, 2024, 10:45 AM Markus Armbruster wrote:
>> >
>> >> John Snow writes:
>> >>
>> >> > This series adds a new qapi-domain extension for Sphinx, which adds a
>> >> > series
Hi Manish,
Thanks for the information. It seems those 3 features are missing in the SPR CPU
Model definition, we are currently polishing our new SPR CPU Model version, you
can launch the SPR CPU Model using:
-cpu SapphireRapids,+cldemote,+movdiri,+movdir64b
as a workaround and sorry for
Thanks Wang Lie. Yes sure will do same until we have new version.
Thanks
Manish Mishra
From: Wang, Lei
Date: Tuesday, 23 April 2024 at 12:50 PM
To: Manish Mishra , qemu-devel@nongnu.org
Cc: christopher.r.blev...@intel.com ,
robert...@linux.intel.com
Subject: Re: Missing features in QEMU Sapp
W dniu 22.04.2024 o 17:37, Marcin Juszkiewicz pisze:
It also seems to be hardcoded in TF-A's support for the virt
board too, annoyingly.
I looked at it and it seems that TF-A can just read what is in
CNTFRQ_EL0 instead of hardcoding the value.
Submitted patch:
https://review.trustedfirmware
John Snow writes:
> On Mon, Apr 22, 2024 at 12:38 PM John Snow wrote:
>>
>> On Mon, Apr 22, 2024 at 5:20 AM Markus Armbruster wrote:
>> >
>> > John Snow writes:
>> >
>> > > On Fri, Apr 19, 2024, 10:45 AM Markus Armbruster
>> > > wrote:
>> > >
>> > >> John Snow writes:
>> > >>
>> > >> > This
On 22/4/24 21:03, Volker Rümelin wrote:
Am 20.04.24 um 07:40 schrieb Mark Cave-Ayland:
On 20/04/2024 02:21, Richard Henderson wrote:
On 4/19/24 12:51, Mark Cave-Ayland wrote:
The various Intel CPU manuals claim that SGDT and SIDT can write
either 24-bits
or 32-bits depending upon the operand
On 22/4/24 15:27, Philippe Mathieu-Daudé wrote:
On 22/4/24 14:52, Manos Pitsidianakis wrote:
Extract audio card removal logic out of the device unrealize callback so
that it can be re-used in follow up commits.
Signed-off-by: Manos Pitsidianakis
---
hw/audio/virtio-snd.c | 20 ++-
On 23/4/24 07:05, CLEMENT MATHIEU--DRIF wrote:
On 22/04/2024 19:03, Philippe Mathieu-Daudé wrote:
On 22/4/24 17:52, CLEMENT MATHIEU--DRIF wrote:
The 'level' field in vtd_iotlb_key is an uint8_t.
We don't need to store level as an int in vtd_lookup_iotlb
Signed-off-by: Clément Mathieu--Drif
-
On Tue, Apr 23, 2024 at 10:15:57AM +0200, Philippe Mathieu-Daudé wrote:
> On 22/4/24 21:03, Volker Rümelin wrote:
> > Am 20.04.24 um 07:40 schrieb Mark Cave-Ayland:
> > > On 20/04/2024 02:21, Richard Henderson wrote:
> > >
> > > > On 4/19/24 12:51, Mark Cave-Ayland wrote:
> > > > > The various Int
Dmitry Osipenko writes:
> Hello,
>
> This series enables Vulkan Venus context support on virtio-gpu.
>
> All virglrender and almost all Linux kernel prerequisite changes
> needed by Venus are already in upstream. For kernel there is a pending
> KVM patchset that fixes mapping of compound pages ne
On Tue, 23 Apr 2024 at 00:11, Michael S. Tsirkin wrote:
>
> On Mon, Apr 22, 2024 at 11:07:21PM +0200, Philippe Mathieu-Daudé wrote:
> > On 22/4/24 23:02, Michael S. Tsirkin wrote:
> > > On Mon, Apr 22, 2024 at 04:20:56PM +0200, Philippe Mathieu-Daudé wrote:
> > > > Since VirtIO devices can change
On Mon, Apr 22, 2024 at 9:10 PM Volker Rümelin wrote:
>
> Am 20.04.24 um 07:40 schrieb Mark Cave-Ayland:
> >> Current documentation agrees that all 32 bits are written, so I don't
> >> think you need this comment:
> >
> > Ah that's good to know the docs are now correct. I added the comment
> > as
On Tue, 23 Apr 2024 at 11:47, Manos Pitsidianakis
wrote:
>
> On Tue, 23 Apr 2024 at 00:11, Michael S. Tsirkin wrote:
> >
> > On Mon, Apr 22, 2024 at 11:07:21PM +0200, Philippe Mathieu-Daudé wrote:
> > > On 22/4/24 23:02, Michael S. Tsirkin wrote:
> > > > On Mon, Apr 22, 2024 at 04:20:56PM +0200,
On Fri, Apr 19, 2024 at 05:25:12PM +0100, Daniel P. Berrangé wrote:
> On Fri, Apr 19, 2024 at 04:56:50PM +0100, Jean-Philippe Brucker wrote:
> > Add a new RmeGuest object, inheriting from ConfidentialGuestSupport, to
> > support the Arm Realm Management Extension (RME). It is instantiated by
> > pa
On Tue, Apr 23, 2024 at 10:44:56AM +0100, Jean-Philippe Brucker wrote:
> On Fri, Apr 19, 2024 at 05:25:12PM +0100, Daniel P. Berrangé wrote:
> > On Fri, Apr 19, 2024 at 04:56:50PM +0100, Jean-Philippe Brucker wrote:
> > > Add a new RmeGuest object, inheriting from ConfidentialGuestSupport, to
> > >
17/04/24 13:05, Konrad, Frederic пишет:
Hi,
-Original Message-
From: qemu-devel-bounces+fkonrad=amd@nongnu.org
On Behalf Of
Peter Maydell
Sent: Friday, April 12, 2024 12:07 PM
To: Alexandra Diupina
Cc: Alistair Francis ; Edgar E. Iglesias
; qemu-...@nongnu.org; qemu-
de...@n
Gustavo Romero writes:
> Hi Markus,
>
> Thanks for interesting in the ivshmem-flat device.
>
> Bill Mills (cc:ed) is the best person to answer your question,
> so please find his answer below.
>
> On 2/28/24 3:29 AM, Markus Armbruster wrote:
>> Gustavo Romero writes:
>>
>> [...]
>>
>>> This pa
On Tue, 23 Apr 2024 at 11:23, Alexandra Diupina wrote:
> 17/04/24 13:05, Konrad, Frederic пишет:
> > Peter Maydell wrote:
> >> Also, this device looks like it has a host-endianness bug: the
> >> DPDMADescriptor struct is read directly from guest memory in
> >> dma_memory_read(), but the device nev
Jonathan Cameron writes:
> These are very similar to the recently added Generic Initiators
> but instead of representing an initiator of memory traffic they
> represent an edge point beyond which may lie either targets or
> initiators. Here we add these ports such that they may
> be targets of h
On 23/4/24 11:18, Manos Pitsidianakis wrote:
On Tue, 23 Apr 2024 at 11:47, Manos Pitsidianakis
wrote:
On Tue, 23 Apr 2024 at 00:11, Michael S. Tsirkin wrote:
On Mon, Apr 22, 2024 at 11:07:21PM +0200, Philippe Mathieu-Daudé wrote:
On 22/4/24 23:02, Michael S. Tsirkin wrote:
On Mon, Apr 22,
On 19/4/24 20:46, Peter Maydell wrote:
The generic timer frequency is settable by board code via a QOM
property "cntfrq", but otherwise defaults to 62.5MHz. The way this
is done includes some complication resulting from how this was
originally a fixed value with no QOM property. Clean it up:
Daniel P. Berrangé writes:
> On Fri, Apr 19, 2024 at 04:56:50PM +0100, Jean-Philippe Brucker wrote:
>> Add a new RmeGuest object, inheriting from ConfidentialGuestSupport, to
>> support the Arm Realm Management Extension (RME). It is instantiated by
>> passing on the command-line:
>>
>> -M vir
Jean-Philippe Brucker writes:
> The Realm Personalization Value (RPV) is provided by the user to
> distinguish Realms that have the same initial measurement.
>
> The user provides up to 64 hexadecimal bytes. They are stored into the
> RPV in the same order, zero-padded on the right.
>
> Cc: Eric
On Fri, 19 Apr 2024 at 16:59, Jean-Philippe Brucker
wrote:
>
> The Realm Personalization Value (RPV) is provided by the user to
> distinguish Realms that have the same initial measurement.
>
> The user provides up to 64 hexadecimal bytes. They are stored into the
> RPV in the same order, zero-padd
Jean-Philippe Brucker writes:
> This option selects which measurement algorithm to use for attestation.
> Supported values are SHA256 and SHA512. Default to SHA512 arbitrarily.
>
> SHA512 is generally faster on 64-bit architectures. On a few arm64 CPUs
> I tested SHA256 is much faster, but that's
On Tue, Apr 23, 2024 at 01:20:20PM +0100, Peter Maydell wrote:
> On Fri, 19 Apr 2024 at 16:59, Jean-Philippe Brucker
> wrote:
> >
> > The Realm Personalization Value (RPV) is provided by the user to
> > distinguish Realms that have the same initial measurement.
> >
> > The user provides up to 64 h
Peter Maydell writes:
> On Fri, 19 Apr 2024 at 16:59, Jean-Philippe Brucker
> wrote:
>>
>> The Realm Personalization Value (RPV) is provided by the user to
>> distinguish Realms that have the same initial measurement.
>>
>> The user provides up to 64 hexadecimal bytes. They are stored into the
>
On 22/04/2024 21:58, Daniel Henrique Barboza wrote:
>
>
> On 4/22/24 16:44, Richard Henderson wrote:
>> On 4/22/24 10:45, Daniel Henrique Barboza wrote:
>>> Palmer, Anup,
>>>
>>> On 4/22/24 10:58, Clément Léger wrote:
The current semihost exception number (16) is a reserved number (range
When the KVM acceleration parameter is not set, executing calc_dirty_rate
with the -r or -b option results in a segmentation fault due to accessing
a null kvm_state pointer in the kvm_dirty_ring_enabled function.
This commit adds a check for kvm_enabled to prevent segmentation faults.
Signed-off-b
When the KVM acceleration parameter is not set, executing calc_dirty_rate
with the -r option results in a segmentation fault due to accessing a
null kvm_state pointer in the kvm_dirty_rate_enabled function.
This commit adds a check for kvm_enabled to prevent segmentation faults.
Signed-off-by: Mas
Changes from v1:
- fix typo in commit message
- added an extra check for dirty bitmap mode
Masato Imai (1):
migration/dirtyrate: Fix segmentation fault
migration/dirtyrate.c | 7 +++
1 file changed, 7 insertions(+)
--
2.34.1
For ARM targets, boards that require TCG are already using "default y".
Switch ARM_VIRT to the same selection mechanism.
No changes to generated config-devices.mak file.
Signed-off-by: Paolo Bonzini
---
configs/devices/arm-softmmu/default.mak | 3 ++-
hw/arm/Kconfig | 2
Some boards, notably ARM boards that use TCG, are already using
"default y". This was done to remove TCG-only boards from
a KVM-only build in commit 29d9efca16 (2023-04-26).
This series converts all other boards to that, so that the requirements
of each board are clearer in the Kconfig files.
Fo
Some targets use "default y" for boards to filter out those that require
TCG. For consistency we are switching all other targets to do the same.
Continue with PARISC.
No changes to generated config-devices.mak file.
Signed-off-by: Paolo Bonzini
---
configs/devices/hppa-softmmu/default.mak | 5
Some targets use "default y" for boards to filter out those that require
TCG. For consistency we are switching all other targets to do the same.
Start with Alpha.
No changes to generated config-devices.mak file.
Signed-off-by: Paolo Bonzini
---
configs/devices/alpha-softmmu/default.mak | 5 ++-
Match the optional device groups to what is actually included in
the config-devices.mak files.
Signed-off-by: Paolo Bonzini
---
configs/devices/arm-softmmu/default.mak | 2 ++
configs/devices/loongarch64-softmmu/default.mak | 3 +++
configs/devices/or1k-softmmu/default.mak| 4 +++
Some targets use "default y" for boards to filter out those that require
TCG. For consistency we are switching all other targets to do the same.
Continue with RX.
No changes to generated config-devices.mak file.
Signed-off-by: Paolo Bonzini
---
configs/devices/rx-softmmu/default.mak | 3 ++-
h
Some targets use "default y" for boards to filter out those that require
TCG. For consistency we are switching all other targets to do the same.
Continue with MIPS.
No changes to generated config-devices.mak file.
Signed-off-by: Paolo Bonzini
---
configs/devices/mips-softmmu/common.mak |
Some targets use "default y" for boards to filter out those that require
TCG. For consistency we are switching all other targets to do the same.
Continue with Loongarch.
No changes to generated config-devices.mak file.
Signed-off-by: Paolo Bonzini
---
configs/devices/loongarch64-softmmu/defaul
Some targets use "default y" for boards to filter out those that require
TCG. For consistency we are switching all other targets to do the same.
Continue with SPARC and SPARC64.
No changes to generated config-devices.mak file.
Signed-off-by: Paolo Bonzini
---
configs/devices/sparc-softmmu/defa
Some targets use "default y" for boards to filter out those that require
TCG. For consistency we are switching all other targets to do the same.
Continue with Nios2.
No changes to generated config-devices.mak file.
Signed-off-by: Paolo Bonzini
---
configs/devices/nios2-softmmu/default.mak | 7
Some targets use "default y" for boards to filter out those that require
TCG. For consistency we are switching all other targets to do the same.
Continue with RISC-V.
No changes to generated config-devices.mak file.
Signed-off-by: Paolo Bonzini
---
configs/devices/riscv32-softmmu/default.mak |
Some targets use "default y" for boards to filter out those that require
TCG. For consistency we are switching all other targets to do the same.
Continue with Xtensa.
No changes to generated config-devices.mak file.
Signed-off-by: Paolo Bonzini
---
configs/devices/xtensa-softmmu/default.mak |
Some targets use "default y" for boards to filter out those that require
TCG. For consistency we are switching all other targets to do the same.
Continue with i386.
No changes to generated config-devices.mak files, other than
adding CONFIG_I386 to the x86_64-softmmu target.
Signed-off-by: Paolo
Some targets use "default y" for boards to filter out those that require
TCG. For consistency we are switching all other targets to do the same.
Continue with PowerPC/POWER.
No changes to generated config-devices.mak files, other than
adding CONFIG_PPC to the ppc64-softmmu target.
Signed-off-by:
Some targets use "default y" for boards to filter out those that require
TCG. For consistency we are switching all other targets to do the same.
Continue with TriCore.
No changes to generated config-devices.mak file.
Signed-off-by: Paolo Bonzini
---
configs/devices/tricore-softmmu/default.mak
Some targets use "default y" for boards to filter out those that require
TCG. For consistency we are switching all other targets to do the same.
Continue with s390.
No changes to generated config-devices.mak file.
Signed-off-by: Paolo Bonzini
---
configs/devices/s390x-softmmu/default.mak | 5 +
Some targets use "default y" for boards to filter out those that require
TCG. For consistency we are switching all other targets to do the same.
Continue with m68k.
No changes to generated config-devices.mak file.
Signed-off-by: Paolo Bonzini
---
configs/devices/m68k-softmmu/default.mak | 13 +
Some targets use "default y" for boards to filter out those that require
TCG. For consistency we are switching all other targets to do the same.
Continue with Microblaze.
No changes to generated config-devices.mak file.
Signed-off-by: Paolo Bonzini
---
configs/devices/microblaze-softmmu/defaul
Some targets use "default y" for boards to filter out those that require
TCG. For consistency we are switching all other targets to do the same.
Continue with AVR.
No changes to generated config-devices.mak file.
Signed-off-by: Paolo Bonzini
---
configs/devices/avr-softmmu/default.mak | 5 ++--
Some targets use "default y" for boards to filter out those that require
TCG. For consistency we are switching all other targets to do the same.
MIPS boards may only be available for big-endian or only for
little-endian emulators, add a symbol so that this can be described
with a "depends on" clau
Some targets use "default y" for boards to filter out those that require
TCG. For consistency we are switching all other targets to do the same.
Continue with CRIS.
No changes to generated config-devices.mak file.
Signed-off-by: Paolo Bonzini
---
configs/devices/cris-softmmu/default.mak | 5 ++
Some targets use "default y" for boards to filter out those that require
TCG. For consistency we are switching all other targets to do the same.
Continue with SH.
No changes to generated config-devices.mak file.
Signed-off-by: Paolo Bonzini
---
configs/devices/sh4-softmmu/default.mak | 7 +++--
Some targets use "default y" for boards to filter out those that require
TCG. For consistency we are switching all other targets to do the same.
Continue with OpenRISC.
No changes to generated config-devices.mak file.
Signed-off-by: Paolo Bonzini
---
configs/devices/or1k-softmmu/default.mak |
On 23/4/24 15:15, Paolo Bonzini wrote:
Some targets use "default y" for boards to filter out those that require
TCG. For consistency we are switching all other targets to do the same.
Continue with AVR.
No changes to generated config-devices.mak file.
Signed-off-by: Paolo Bonzini
---
config
On 23/4/24 15:16, Paolo Bonzini wrote:
Some targets use "default y" for boards to filter out those that require
TCG. For consistency we are switching all other targets to do the same.
Continue with RX.
No changes to generated config-devices.mak file.
Signed-off-by: Paolo Bonzini
---
configs
On 23/4/24 15:16, Paolo Bonzini wrote:
Some targets use "default y" for boards to filter out those that require
TCG. For consistency we are switching all other targets to do the same.
Continue with SH.
No changes to generated config-devices.mak file.
Signed-off-by: Paolo Bonzini
---
configs
On 23/4/24 15:16, Paolo Bonzini wrote:
Some targets use "default y" for boards to filter out those that require
TCG. For consistency we are switching all other targets to do the same.
Continue with TriCore.
No changes to generated config-devices.mak file.
Signed-off-by: Paolo Bonzini
---
co
On Tue, Apr 23, 2024 at 09:13:08AM +, Masato Imai wrote:
> When the KVM acceleration parameter is not set, executing calc_dirty_rate
> with the -r or -b option results in a segmentation fault due to accessing
> a null kvm_state pointer in the kvm_dirty_ring_enabled function.
> This commit adds
On 23/4/24 15:16, Paolo Bonzini wrote:
Some targets use "default y" for boards to filter out those that require
TCG. For consistency we are switching all other targets to do the same.
Continue with Xtensa.
No changes to generated config-devices.mak file.
Signed-off-by: Paolo Bonzini
---
con
On 23/4/24 15:16, Paolo Bonzini wrote:
Some targets use "default y" for boards to filter out those that require
TCG. For consistency we are switching all other targets to do the same.
Continue with Microblaze.
No changes to generated config-devices.mak file.
Signed-off-by: Paolo Bonzini
---
On 23/4/24 15:15, Paolo Bonzini wrote:
Some targets use "default y" for boards to filter out those that require
TCG. For consistency we are switching all other targets to do the same.
Continue with m68k.
No changes to generated config-devices.mak file.
Signed-off-by: Paolo Bonzini
---
confi
On 23/4/24 15:15, Paolo Bonzini wrote:
Some targets use "default y" for boards to filter out those that require
TCG. For consistency we are switching all other targets to do the same.
Continue with PARISC.
No changes to generated config-devices.mak file.
Signed-off-by: Paolo Bonzini
---
con
On 23/4/24 15:15, Paolo Bonzini wrote:
Some targets use "default y" for boards to filter out those that require
TCG. For consistency we are switching all other targets to do the same.
Continue with CRIS.
No changes to generated config-devices.mak file.
Signed-off-by: Paolo Bonzini
---
confi
On 23/4/24 15:15, Paolo Bonzini wrote:
Some targets use "default y" for boards to filter out those that require
TCG. For consistency we are switching all other targets to do the same.
Start with Alpha.
No changes to generated config-devices.mak file.
Signed-off-by: Paolo Bonzini
---
configs
On 23/4/24 15:15, Paolo Bonzini wrote:
Some targets use "default y" for boards to filter out those that require
TCG. For consistency we are switching all other targets to do the same.
Continue with Loongarch.
No changes to generated config-devices.mak file.
Signed-off-by: Paolo Bonzini
---
On 23/4/24 15:16, Paolo Bonzini wrote:
Some targets use "default y" for boards to filter out those that require
TCG. For consistency we are switching all other targets to do the same.
Continue with OpenRISC.
No changes to generated config-devices.mak file.
Signed-off-by: Paolo Bonzini
---
c
On 23/4/24 15:16, Paolo Bonzini wrote:
Some targets use "default y" for boards to filter out those that require
TCG. For consistency we are switching all other targets to do the same.
Continue with Nios2.
No changes to generated config-devices.mak file.
Signed-off-by: Paolo Bonzini
---
conf
On Mon, Apr 22, 2024 at 07:22:48PM -0700, dongwon@intel.com wrote:
> From: Dongwon Kim
>
> 'fence_fd' needs to be validated always before being referenced
> And the passing condition should include '== 0' as 0 is a valid
> value for the file descriptor.
>
> Suggested-by: Marc-André Lureau
>
On 21/3/24 18:05, Richard Henderson wrote:
On 3/21/24 05:48, Philippe Mathieu-Daudé wrote:
qatomic_cmpxchg__nocheck(), qatomic_read__nocheck(),
qatomic_set__nocheck() are defined in "qemu/atomic.h".
Include it in order to avoid:
In file included from include/exec/helper-proto.h:10:
In fil
On Mon, Apr 22, 2024 at 07:22:49PM -0700, dongwon@intel.com wrote:
> From: Dongwon Kim
>
> New header and source files are added for containing QemuDmaBuf struct
> definition and newly introduced helpers for creating/freeing the struct
> and accessing its data.
>
> v10: Change the license ty
On Mon, Apr 22, 2024 at 07:22:49PM -0700, dongwon@intel.com wrote:
> From: Dongwon Kim
>
> New header and source files are added for containing QemuDmaBuf struct
> definition and newly introduced helpers for creating/freeing the struct
> and accessing its data.
>
> v10: Change the license ty
Hi,
hppa-firmware.img and hppa-firmware64.img in qemu.git are missing ELF
build-id annotations. rpm builds on Fedora will error if an ELF binary
doesn't have build-id:
RPM build errors:
Missing build-id in
/tmp/rpmbuild/BUILDROOT/qemu-9.0.0-1.rc2.fc41.x86_64/usr/share/qemu/hppa-firmware.img
On Mon, Apr 22, 2024 at 07:22:50PM -0700, dongwon@intel.com wrote:
> From: Dongwon Kim
>
> This commit updates all instances where fields within the QemuDmaBuf
> struct are directly accessed, replacing them with calls to these new
> helper functions.
>
> v6: fix typos in helper names in ui/s
On 4/23/24 10:11 AM, Cole Robinson wrote:
> Hi,
>
> hppa-firmware.img and hppa-firmware64.img in qemu.git are missing ELF
> build-id annotations. rpm builds on Fedora will error if an ELF binary
> doesn't have build-id:
>
> RPM build errors:
> Missing build-id in
> /tmp/rpmbuild/BUILDROOT/qem
From: aidaleuc
Signed-off-by: aidaleuc
---
qga/commands-windows-ssh.c | 712 +
qga/commands-windows-ssh.h | 26 ++
qga/meson.build| 5 +-
qga/qapi-schema.json | 17 +-
4 files changed, 749 insertions(+), 11 deletions(-)
create mode 1006
From: aidaleuc
Signed-off-by: aidaleuc
---
qga/commands-common-ssh.c | 50 +++
qga/commands-common-ssh.h | 10
qga/commands-posix-ssh.c | 47 +---
qga/meson.build | 1 +
4 files changed, 62 insertions(+), 4
From: aidaleuc
This patch aims to implement guest-ssh-add-authorized-keys,
guest-ssh-remove-authorized-keys, and guest-ssh-get-authorized-keys
for Windows. This PR is based on Microsoft's OpenSSH implementation
https://github.com/PowerShell/Win32-OpenSSH. The guest agents
will support Kubevirt
On Tue, Apr 23, 2024 at 10:11:50AM -0400, Cole Robinson wrote:
> Hi,
>
> hppa-firmware.img and hppa-firmware64.img in qemu.git are missing ELF
> build-id annotations. rpm builds on Fedora will error if an ELF binary
> doesn't have build-id:
>
> RPM build errors:
> Missing build-id in
> /tmp/r
On 4/23/24 16:58, Cole Robinson wrote:
On 4/23/24 10:11 AM, Cole Robinson wrote:
Hi,
hppa-firmware.img and hppa-firmware64.img in qemu.git are missing ELF
build-id annotations. rpm builds on Fedora will error if an ELF binary
doesn't have build-id:
RPM build errors:
Missing build-id in
/t
The following changes since commit 62dbe54c24dbf77051bafe1039c31ddc8f37602d:
Update version for v9.0.0-rc4 release (2024-04-16 18:06:15 +0100)
are available in the Git repository at:
https://gitlab.com/bonzini/qemu.git tags/for-upstream
for you to fetch changes up to 254fade7854a6b3d5b7c54a
There is no way to use them for testing, if all the available
accelerators use hardware virtualization.
Signed-off-by: Paolo Bonzini
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Richard Henderson
Message-ID: <20240408155330.522792-3-pbonz...@redhat.com>
Signed-off-by: Paolo Bonzini
---
te
The dependency on pixman is listed manually in all sourcesets that need it.
There is no need to bring into libqemuutil, since there is nothing in
util/ that needs pixman either.
Reported-by: Michael Tokarev
Signed-off-by: Paolo Bonzini
Reviewed-by: Richard Henderson
Message-ID: <20240408155330.
Since the USB stubs are needed exactly when the Kconfig symbols are not
enabled, they can be placed in hw/usb/ and conditionalized on CONFIG_USB.
Signed-off-by: Paolo Bonzini
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Richard Henderson
Message-ID: <20240408155330.522792-11-pbonz...@redhat
Currently it is not documented anywhere why some functions need to
be stubbed.
Group the files in stubs/meson.build according to who needs them, both
to reduce the size of the compilation and to clarify the use of stubs.
Signed-off-by: Paolo Bonzini
Message-ID: <20240408155330.522792-18-pbonz...
Try not to test code that is not used by user mode emulation, or by the
block layer, unless they are being compiled; and fix test-timed-average
which was not compiled with --disable-system --enable-tools.
This is by no means complete, it only touches the more blatantly
wrong cases.
Signed-off-by:
If an architecture adds support for KVM_CAP_SET_GUEST_DEBUG but QEMU does not
have the necessary code, QEMU will fail to build after updating kernel headers.
Avoid this by using a #define in config-target.h instead of
KVM_CAP_SET_GUEST_DEBUG.
Signed-off-by: Paolo Bonzini
---
configs/targets/aar
From: Chao Peng
Switch to KVM_SET_USER_MEMORY_REGION2 when supported by KVM.
With KVM_SET_USER_MEMORY_REGION2, QEMU can set up memory region that
backend'ed both by hva-based shared memory and guest memfd based private
memory.
Signed-off-by: Chao Peng
Co-developed-by: Xiaoyao Li
Signed-off-by
From: Isaku Yamahata
Add a q35 property to check whether or not SMM ranges, e.g. SMRAM, TSEG,
etc... exist for the target platform. TDX doesn't support SMM and doesn't
play nice with QEMU modifying related guest memory ranges.
Signed-off-by: Isaku Yamahata
Co-developed-by: Sean Christopherson
From: Isaku Yamahata
Because vMMIO region needs to be shared region, guest TD may explicitly
convert such region from private to shared. Don't complain such
conversion.
Signed-off-by: Isaku Yamahata
Signed-off-by: Xiaoyao Li
Message-ID: <20240229063726.610065-34-xiaoyao...@intel.com>
Signed-o
From: Isaku Yamahata
TDX requires vMMIO region to be shared. For KVM, MMIO region is the region
which kvm memslot isn't assigned to (except in-kernel emulation).
qemu has the memory region for vMMIO at each device level.
While OVMF issues MapGPA(to-shared) conservatively on 32bit PCI MMIO
regio
From: Xiaoyao Li
Use the unified interface to call confidential guest related kvm_init()
and kvm_reset(), to avoid exposing pef specific functions.
As a bonus, pef.h goes away since there is no direct call from sPAPR
board code to PEF code anymore.
Signed-off-by: Xiaoyao Li
Signed-off-by: Paol
From: Philippe Mathieu-Daudé
Only the files in hwcore_ss[] are required to link a user emulation
binary.
Have meson process the hw/ sub-directories if system emulation is
selected, otherwise directly process hw/core/ to get hwcore_ss[], which
is the only set required by user emulation.
This rem
From: Xiaoyao Li
KVM side leaves the memory to shared by default, which may incur the
overhead of paging conversion on the first visit of each page. Because
the expectation is that page is likely to private for the VMs that
require private memory (has guest memfd).
Explicitly set the memory to p
Some subsystems like VFIO might disable ram block discard, but guest_memfd
uses discard operations to implement conversions between private and
shared memory. Because of this, sequences like the following can result
in stale IOMMU mappings:
1. allocate shared page
2. convert page shared->private
From: Xiaoyao Li
Introduce the helper functions to set the attributes of a range of
memory to private or shared.
This is necessary to notify KVM the private/shared attribute of each gpa
range. KVM needs the information to decide the GPA needs to be mapped at
hva-based shared memory or guest_memf
Since the semihosting stubs are needed exactly when the Kconfig symbols
are not needed, move them to semihosting/ and conditionalize them
on CONFIG_SEMIHOSTING and/or CONFIG_SYSTEM_ONLY.
Signed-off-by: Paolo Bonzini
Message-ID: <20240408155330.522792-13-pbonz...@redhat.com>
Signed-off-by: Paolo B
Signed-off-by: Paolo Bonzini
---
include/standard-headers/asm-x86/bootparam.h | 17 +-
include/standard-headers/asm-x86/kvm_para.h | 3 +-
include/standard-headers/asm-x86/setup_data.h | 83 +++
include/standard-headers/linux/ethtool.h | 48 ++
include/standard-headers/linux/fuse.h
1 - 100 of 266 matches
Mail list logo
