Hi Everyone,
We see few features like movdiri, movdiri64b, cldemote are present on
SapphireRapid nodes and are also mentioned as supported in intel manual. But
these are missing from the QEMU definition of SapphireRapid CPUs
https://github.com/qemu/qemu/commit/7eb061b06e97af9a8da7f31b839d78997
On Mon, Apr 22, 2024 at 9:25 PM wrote:
> From: aidaleuc
>
> Signed-off-by: aidaleuc
> ---
> qga/commands-windows-ssh.c | 712 +
> qga/commands-windows-ssh.h | 26 ++
> qga/meson.build| 7 +-
> qga/qapi-schema.json | 17 +-
> 4 files cha
+ Nick
Hi Salil,
I have posted a patch [1] for ppc which based on this refactoring patch.
I see there were some comments from Vishnu on this patch.
Are we expecting any further updates on this patch before merge?
Thanks
Harsh
[1]
https://lore.kernel.org/qemu-devel/a0f9b2fc-4c8a-4c37-bc36-26bba
Moving the below instructions to decodetree specification :
neg[o][.] : XO-form
mod{sw, uw}, darn : X-form
The changes were verified by validating that the tcg ops generated by those
instructions remain the same, which were captured with the '-d in_asm,op' flag
Moving the following instructions to decodetree specification :
divw[u, e, eu][o][.] : XO-form
The changes were verified by validating that the tcg ops generated by those
instructions remain the same, which were captured with the '-d in_asm,op' flag.
Signed-off-by: Chinmay Rath
Review
Moving all fixed-point instructions of the following type to decodetree
specification : arithmetic, compare, trap, select and logical.
Change log :
v2 : Implemented code clean-ups as per comments by Richard in
patches 1/8, 5/8 and 7/8 of v1.
v1 :
https://lore.kernel.org/qemu-devel/202404160
Moving the below instructions to decodetree specification :
andi[s]., {ori, xori}[s]: D-form
{and, andc, nand, or, orc, nor, xor, eqv}[.],
exts{b, h, w}[.], cnt{l, t}z{w, d}[.],
popcnt{b, w, d}, prty{w, d}, cmp, bpermd : X-form
With
Moving the below instructions to decodetree specification :
divd[u, e, eu][o][.]: XO-form
mod{sd, ud} : X-form
With this patch, all the fixed-point arithmetic instructions have been
moved to decodetree.
The changes were verified by validating that the tcg ops gener
Moving the following instructions to decodetree specification :
cmp{rb, eqb}, t{w, d} : X-form
t{w, d}i: D-form
isel: A-form
The changes were verified by validating that the tcg ops generated by those
instructions remain the same, whic
Moving the following instructions to decodetree specification :
mulli : D-form
mul{lw, lwo, hw, hwu}[.]: XO-form
The changes were verified by validating that the tcg ops generated by those
instructions remain the same, which were captured with the
Moving the following instructions to decodetree :
mul{ld, ldo, hd, hdu}[.]: XO-form
madd{hd, hdu, ld} : VA-form
The changes were verified by validating that the tcg ops generated by those
instructions remain the same, which were captured with the '-d in_asm,o
The handler methods for divw[u] instructions internally use Rc(ctx->opcode),
for extraction of Rc field of instructions, which poses a problem if we move
the above said instructions to decodetree, as the ctx->opcode field is not
popluated in decodetree. Hence, making it decodetree compatible, so th
+ qemu-devel
On 4/23/24 11:40, Harsh Prateek Bora wrote:
On ppc64, the PowerVM hypervisor runs with limited memory and a VCPU
creation during hotplug may fail during kvm_ioctl for KVM_CREATE_VCPU,
leading to termination of guest since errp is set to &error_fatal while
calling kvm_init_vcpu. This
On Tue, Apr 9, 2024 at 11:46 AM yang.zhang wrote:
>
> From: "yang.zhang"
>
> Since only root APLICs can have hw IRQ lines, aplic->parent should
> be initialized first.
>
> Fixes: e8f79343cf ("hw/intc: Add RISC-V AIA APLIC device emulation")
> Reviewed-by: Daniel Henrique Barboza
> Signed-off-by:
On 22/04/2024 18:59, Philippe Mathieu-Daudé wrote:
> On 22/4/24 17:52, CLEMENT MATHIEU--DRIF wrote:
>> This piece of code can be shared by both IOTLB invalidation and
>> PASID-based IOTLB invalidation
>>
>> Signed-off-by: Clément Mathieu--Drif
>> ---
>> hw/i386/intel_iommu.c | 57 ++
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
>> ---
>> hw/i386/intel_iommu.c | 2 +
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/spice-display.c
v7: removed prefix, "dpy_gl_" from all helpers
v8: Introduction of h
From: Dongwon Kim
This commit introduces utility functions for the creation and deallocation
of QemuDmaBuf instances. Additionally, it updates all relevant sections
of the codebase to utilize these new utility functions.
v7: remove prefix, "dpy_gl_" from all helpers
qemu_dmabuf_free() return
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 type for both dmabuf.h and dmabuf.c from MIT to
GPL to be in line with QEMU's defa
From: Dongwon Kim
This commit updates all occurrences where these fields were
set directly have been updated to utilize helper functions.
v7: removed prefix, "dpy_gl_" from all helpers
v8: Introduction of helpers was removed as those were already added
by the previous commit
Suggested-by:
From: Dongwon Kim
This series introduces privacy enhancements to the QemuDmaBuf struct
and its contained data to bolster security. it accomplishes this by
introducing of helper functions for allocating, deallocating, and
accessing individual fields within the struct and replacing all direct
refer
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
Cc: Philippe Mathieu-Daudé
Cc: Daniel P. Berrangé
Cc: Vivek Kasireddy
Signed-off-by
From: Dongwon Kim
To complete privatizing process of QemuDmaBuf, QemuDmaBuf struct def
is moved to dmabuf.c
Suggested-by: Marc-André Lureau
Cc: Philippe Mathieu-Daudé
Cc: Daniel P. Berrangé
Cc: Vivek Kasireddy
Signed-off-by: Dongwon Kim
---
include/ui/dmabuf.h | 19 +--
ui/
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 series adds a new qapi-domain ex
Ping.
I would appreciate comments on this series. Thanks,
Yong
On Mon, Apr 8, 2024 at 8:08 PM Hyman Huang wrote:
> This patchset fixes the crash of VMs configured with the CDROM device
> on the destination during live migration. See the commit message for
> details.
>
> The previous patchset do
From: Breno Leitao
commit 059a49aa2e25c58f90b50151f109dd3c4cdb3a47 upstream.
There is a bug when setting the RSS options in virtio_net that can break
the whole machine, getting the kernel into an infinite loop.
Running the following command in any QEMU virtual machine with virtionet
will reprod
The VIRTIO Sound Device conforms with the Virtio spec v1.2,
thus only use little endianness.
Remove the suspicious target_words_bigendian() noticed during
code review.
Cc: qemu-sta...@nongnu.org
Fixes: eb9ad377bb ("virtio-sound: handle control messages and streams")
Signed-off-by: Philippe Mathie
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 endianness at runtime,
> > > we need to use the device endianness,
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 endianness at runtime,
we need to use the device endianness, not the target
one.
Cc: qemu-sta...@nongnu.org
Fixes: eb9ad377bb ("virtio-sound: handl
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 ("target/arm: Do memory type alignment check when
translation disabled")
Reported-by: Clémen
On Mon, Apr 22, 2024 at 04:20:56PM +0200, Philippe Mathieu-Daudé wrote:
> Since VirtIO devices can change endianness at runtime,
> we need to use the device endianness, not the target
> one.
>
> Cc: qemu-sta...@nongnu.org
> Fixes: eb9ad377bb ("virtio-sound: handle control messages and streams")
>
On Mon, 22 Apr 2024 17:20, Philippe Mathieu-Daudé
wrote:
Since VirtIO devices can change endianness at runtime,
we need to use the device endianness, not the target
one.
Cc: qemu-sta...@nongnu.org
Fixes: eb9ad377bb ("virtio-sound: handle control messages and streams")
Signed-off-by: Philippe Ma
Given that memory_region_set_readonly() is a no-op when the readonlyness is
already as requested it is possible to simplify the pattern
if (condition) {
foo(true);
}
to
foo(condition);
which is shorter and allows to see the invariant of the code more easily.
Signed-off-by: Bernhard B
This series changes the "isa-bios" MemoryRegion to be an alias rather than a
copy in the pflash case. This fixes issuing pflash commands in the isa-bios
region which matches real hardware and which some real-world legacy bioses I'm
running rely on. Furthermore, aliasing in the isa-bios area is alre
Now that the -bios and -pflash code paths work the same it is possible to have a
common implementation.
While at it convert the magic number 0x10 (== 1MiB) to increase readability.
Signed-off-by: Bernhard Beschow
---
include/hw/i386/x86.h | 2 ++
hw/i386/pc_sysfw.c| 28
In the -bios case the "isa-bios" memory region is an alias to the BIOS mapped
to the top of the 4G memory boundary. Do the same in the -pflash case to have
common behavior. This also makes pflash commands work in the "isa-bios" region
which some real-world legacy bioses rely on.
Note that in the s
Signed-off-by: Bernhard Beschow
---
hw/i386/pc_sysfw.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/hw/i386/pc_sysfw.c b/hw/i386/pc_sysfw.c
index 3efabbbab2..87b5bf59d6 100644
--- a/hw/i386/pc_sysfw.c
+++ b/hw/i386/pc_sysfw.c
@@ -41,8 +41,7 @@
#define FLASH_SECTOR_SIZ
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
[16-17]). The upcoming double trap specification uses that number for
the d
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
[16-17]). The upcoming double trap specification uses that number for
the double trap exception. Since the privileged spec
On Wed, Apr 17, 2024 at 09:33:33PM +0300, Vladimir Sementsov-Ogievskiy wrote:
> We leak global_filename, and do not close global_file. Let's fix that.
What is the goal?
Leaking global_filename does not cause unbounded memory consumption. I
guess the goal in freeing global_filename is to keep leak
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 size, but this is incorrect
From: aidaleuc
Signed-off-by: aidaleuc
---
qga/commands-windows-ssh.c | 712 +
qga/commands-windows-ssh.h | 26 ++
qga/meson.build| 7 +-
qga/qapi-schema.json | 17 +-
4 files changed, 750 insertions(+), 12 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
Changes since v6
* Fixed issue with file permissions causing public keys to be rejected by the
SSH server. credit (kkostiuk)
Older versions of OpenSSH such as the one shipped with Windows Server 2022 are
more stringent on
file permissions.
* Removed everyone group from create_ac
Hi Konstantin,
Thank you for taking the time to look over the patch and test it. I do expect
this to work when installing OpenSSH by Windows features. I have been testing
my implementation on Windows 11 which uses a newer version of OpenSSH server
than the one shipped with Windows Server 2022.
On 4/22/24 10:46, Andrew Jones wrote:
The Zkr extension may only be exposed to KVM guests if the VMM
implements the SEED CSR. Use the same implementation as TCG.
Without this patch, running with a KVM which does not forward the
SEED CSR access to QEMU will result in an ILL exception being
inj
Palmer, Anup,
On 4/22/24 10:58, Clément Léger wrote:
The current semihost exception number (16) is a reserved number (range
[16-17]). The upcoming double trap specification uses that number for
the double trap exception. Since the privileged spec (Table 22) defines
ranges for custom uses change
Running a KVM guest using a 6.9-rc3 kernel, in a 6.8 host that has zkr
enabled, will fail with a kernel oops SIGILL right at the start. The
reason is that we can't expose zkr without implementing the SEED CSR.
Disabling zkr in the guest would be a workaround, but if the KVM doesn't
allow it we'll e
Hi,
In this new version we changed the commit message a bit and we're now
only handling the case for EINVAL. Both were suggested by Drew in v1.
Changes from v1:
- added an extra paragraph explaining why we're throwing an warning
- changed the warning string
- warning is now being thrown only if E
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 ("target/arm: Do memory type alignment check when translation
disabled")
Reported-by: Clément Chigot
Signed-off-by: Richard Henderson
-
For cpus using PMSA, when the MPU is disabled, the default memory
type is Normal, Non-cachable.
Fixes: 59754f85ed3 ("target/arm: Do memory type alignment check when
translation disabled")
Reported-by: Clément Chigot
Signed-off-by: Richard Henderson
---
Since v9 will likely be tagged tomorrow w
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
---
hw/i386/intel_iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/i3
On 22/4/24 17:52, CLEMENT MATHIEU--DRIF wrote:
This piece of code can be shared by both IOTLB invalidation and
PASID-based IOTLB invalidation
Signed-off-by: Clément Mathieu--Drif
---
hw/i386/intel_iommu.c | 57 +--
1 file changed, 33 insertions(+), 24
Richard Henderson writes:
> Based-on: 20240404230611.21231-1-richard.hender...@linaro.org
> ("[PATCH v2 00/21] Rewrite plugin code generation")
I'm getting code conflicts w.r.t to the above (which is already merged?)
so it would be helpful to get a re-base.
>
> This is an attempt to fix
> https
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 patchset introduces a new device, ivshmem-flat, which
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 of custom directives for docume
On Mon, 22 Apr 2024 at 16:48, Richard Henderson
wrote:
>
> On 4/22/24 08:26, Clément Chigot wrote:
> > Hi Richard,
> >
> > While testing the future V9, I've some regressions on a custom board
> > using cortex-R5 CPUs.
> > Unaligned data accesses are no longer allowed because of that patch.
> >
> >
On Mon, 22 Apr 2024 at 15:18, Peter Maydell wrote:
> I imagine that value gets written into CNTFRQ by TF-A somewhere
> along the line (and then read by EDK2 later), though I haven't
> quite found where. Plus I notice that the TF-A sbsa-watchdog-timer
> assumes that the generic-timer frequency and
This translation mode will only be made available in scalable mode
Signed-off-by: Clément Mathieu--Drif
---
hw/i386/intel_iommu.c | 364 -
hw/i386/intel_iommu_internal.h | 51 -
2 files changed, 362 insertions(+), 53 deletions(-)
diff --git a/hw/i38
Signed-off-by: Clément Mathieu--Drif
---
hw/i386/intel_iommu.c | 6 ++
include/hw/i386/intel_iommu.h | 1 +
2 files changed, 7 insertions(+)
diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c
index 4b54a45107..c35ccc3a98 100644
--- a/hw/i386/intel_iommu.c
+++ b/hw/i386/intel_
Some variables struct fields and functions can be used for both
slpte and flpte. We can modify certain identifiers to make them
more generic.
- slpte in IOMMUTLBEntry becomes pte and will be used for both FL and SL
- VTD_SL_PT_LEVEL, VTD_SL_PT_PAGE_SIZE_MASK and VTD_SL_LEVEL_BITS can be
renamed
This series is the first of a list that add support for SVM in the Intel IOMMU.
Here, we implement support for first-stage translation in VT-d.
The PASID-based IOTLB invalidation is also added in this series as it is a
requirement of FLTS.
The last patch introduces the 'flts' option to enable the
Signed-off-by: Clément Mathieu--Drif
---
hw/i386/intel_iommu.c | 130 ++---
hw/i386/intel_iommu_internal.h | 51 +++--
2 files changed, 150 insertions(+), 31 deletions(-)
diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c
index aaac61bf6a..4b
This piece of code can be shared by both IOTLB invalidation and
PASID-based IOTLB invalidation
Signed-off-by: Clément Mathieu--Drif
---
hw/i386/intel_iommu.c | 57 +--
1 file changed, 33 insertions(+), 24 deletions(-)
diff --git a/hw/i386/intel_iommu.c b/
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
---
hw/i386/intel_iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c
index 6f13
The constant must be unsigned, otherwise the two's complement
overrides the other fields when a PASID is present
Signed-off-by: Clément Mathieu--Drif
---
hw/i386/intel_iommu_internal.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/i386/intel_iommu_internal.h b/hw/i386/in
On 4/22/24 08:26, Clément Chigot wrote:
Hi Richard,
While testing the future V9, I've some regressions on a custom board
using cortex-R5 CPUs.
Unaligned data accesses are no longer allowed because of that patch.
I've dug into the various documentation and it seems that R-profile
CPUs don't have
On Mon, Apr 22, 2024 at 01:04:48PM +0100, Jonathan Cameron wrote:
> On Sat, 20 Apr 2024 16:35:46 -0400
> Gregory Price wrote:
>
> > On Fri, Apr 19, 2024 at 11:43:14AM -0700, fan wrote:
> > > On Fri, Apr 19, 2024 at 02:24:36PM -0400, Gregory Price wrote:
> > > >
> > > > added review to all patc
W dniu 22.04.2024 o 16:18, Peter Maydell pisze:
On Mon, 22 Apr 2024 at 14:38, Marcin Juszkiewicz
From what I see in EDK2 code we read CNTFREQ_EL0:
GetPlatformTimerFreq() checks for PcdArmArchTimerFreqInHz variable which
sbsa-ref has set to 0. So it calls ArmGenericTimerGetTimerFreq() ->
Arm
On Mon, Apr 22, 2024 at 01:22:46PM +0200, Philippe Mathieu-Daudé wrote:
> We have been running this test for almost a year; it
> is safe to remove its debug statements, which clutter
> CI jobs output:
>
> ▶ 88/100 /nested-aio-poll OK
> io_read 0x16bb26158
> io_poll_true
Hi Richard,
While testing the future V9, I've some regressions on a custom board
using cortex-R5 CPUs.
Unaligned data accesses are no longer allowed because of that patch.
I've dug into the various documentation and it seems that R-profile
CPUs don't have the same default memory type as A-profile
On 4/22/24 08:21, Richard Henderson wrote:
For Arm's CPUs they fall into two categories:
* older ones don't set MT in their MPIDR, and the Aff0
field is effectively the CPU number
* newer ones do set MT in their MPIDR, but don't have
SMT, so their Aff0 is always 0 and their Aff1
i
On 4/22/24 04:26, Peter Maydell wrote:
On Mon, 22 Apr 2024 at 11:46, Peter Maydell wrote:
On Sun, 21 Apr 2024 at 06:40, Richard Henderson
wrote:
--- a/target/arm/cpu.c
+++ b/target/arm/cpu.c
@@ -1314,8 +1314,18 @@ static void arm_cpu_dump_state(CPUState *cs, FILE *f,
int flags)
}
On Mon, 22 Apr 2024 15:23:16 +0100
Jonathan Cameron wrote:
> On Mon, 22 Apr 2024 13:04:48 +0100
> Jonathan Cameron wrote:
>
> > On Sat, 20 Apr 2024 16:35:46 -0400
> > Gregory Price wrote:
> >
> > > On Fri, Apr 19, 2024 at 11:43:14AM -0700, fan wrote:
> > > > On Fri, Apr 19, 2024 at 02:2
On 4/9/24 19:56, Chalapathi V wrote:
In this commit
Creates SPI controller on p10 chip.
Create the keystore seeprom of type "seeprom-25csm04"
Connect the cs of seeprom to PIB_SPIC[2] cs irq.
The QOM tree of spi controller and seeprom are.
/machine (powernv10-machine)
/chip[0] (power10_v2.0-pn
Daniel P. Berrangé writes:
> On Wed, Mar 20, 2024 at 03:39:39AM -0500, Michael Roth wrote:
>> From: Dov Murik
>>
>> In order to enable kernel-hashes for SNP, pull it from
>> SevGuestProperties to its parent SevCommonProperties so
>> it will be available for both SEV and SNP.
>>
>> Signed-off-b
Michael Roth writes:
> The GHCB specification[1] defines a VMGEXIT-based Guest Request
> hypercall to allow an SNP guest to issue encrypted requests directly to
> SNP firmware to do things like query the attestation report for the
> guest. These are generally handled purely in the kernel.
>
> In
Michael Roth writes:
> Most of the current 'query-sev' command is relevant to both legacy
> SEV/SEV-ES guests and SEV-SNP guests, with 2 exceptions:
>
> - 'policy' is a 64-bit field for SEV-SNP, not 32-bit, and
> the meaning of the bit positions has changed
> - 'handle' is not relevant to
As it had never been used since the first commit a1477da3ddeb ("hvf: Add
Apple Silicon support").
Signed-off-by: Zenghui Yu
---
target/arm/hvf/hvf.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/target/arm/hvf/hvf.c b/target/arm/hvf/hvf.c
index 65a5601804..015e96a6d3 100644
--- a/target/arm
Hello Chalapathi
On 4/9/24 19:56, Chalapathi V wrote:
This commit implements a Serial EEPROM utilizing the Serial Peripheral
Interface (SPI) compatible bus.
Currently implemented SEEPROM is Microchip's 25CSM04 which provides 4 Mbits
of Serial EEPROM utilizing the Serial Peripheral Interface (SPI
On Mon, Apr 22, 2024 at 11:08:31AM -0300, Daniel Henrique Barboza wrote:
>
>
> On 4/22/24 10:43, Andrew Jones wrote:
> > On Mon, Apr 22, 2024 at 10:12:53AM -0300, Daniel Henrique Barboza wrote:
> > > Running a KVM guest using a 6.9-rc3 kernel, in a 6.8 host that has zkr
> > > enabled, will fail w
On 22/4/24 15:45, Manos Pitsidianakis wrote:
On Mon, 22 Apr 2024 16:13, Philippe Mathieu-Daudé
wrote:
Since VirtIO devices can change endianness at runtime,
we need to use the device endianness, not the target
one.
Hey Philippe, can you clarify what do you mean by they can change
endianness
On Mon, 22 Apr 2024 13:04:48 +0100
Jonathan Cameron wrote:
> On Sat, 20 Apr 2024 16:35:46 -0400
> Gregory Price wrote:
>
> > On Fri, Apr 19, 2024 at 11:43:14AM -0700, fan wrote:
> > > On Fri, Apr 19, 2024 at 02:24:36PM -0400, Gregory Price wrote:
> > > >
> > > > added review to all patch
Since VirtIO devices can change endianness at runtime,
we need to use the device endianness, not the target
one.
Cc: qemu-sta...@nongnu.org
Fixes: eb9ad377bb ("virtio-sound: handle control messages and streams")
Signed-off-by: Philippe Mathieu-Daudé
---
v2: Use virtio_is_big_endian()
v3: Remove "
Hello, everyone.
Was added missed "trace.h"
Best regards.
On Mon, Apr 22, 2024 at 5:17 PM Andrew Melnychenko wrote:
>
> There was an issue with Qemu build with "--disable-system".
> The traces could be generated and the build fails.
> The traces were 'cut out' for previous patches, and overall,
On Mon, 22 Apr 2024 at 14:38, Marcin Juszkiewicz
wrote:
>
> W dniu 22.04.2024 o 14:56, Peter Maydell pisze:
> > On Fri, 19 Apr 2024 at 19:46, Peter Maydell
> > wrote:
>
> >> The upshot is that the only CPU type that changes is 'max'; but any
> >> new type we add in future (whether v8.6 or not) w
There was an issue with Qemu build with "--disable-system".
The traces could be generated and the build fails.
The traces were 'cut out' for previous patches, and overall,
the 'system' source set should be used like in pre-'eBPF blob' patches.
Signed-off-by: Andrew Melnychenko
---
ebpf/ebpf_rss.
On 4/22/24 10:43, Andrew Jones wrote:
On Mon, Apr 22, 2024 at 10:12:53AM -0300, Daniel Henrique Barboza wrote:
Running a KVM guest using a 6.9-rc3 kernel, in a 6.8 host that has zkr
enabled, will fail with a kernel oops SIGILL right at the start. The
reason is that we can't expose zkr without
On 4/16/24 19:02, Chalapathi V wrote:
On 15-04-2024 20:44, Cédric Le Goater wrote:
Hello Chalapathi
The subject could be rephrased to : "ppc/pnv: Add SPI controller model".
On 4/9/24 19:56, Chalapathi V wrote:
SPI controller device model supports a connection to a single SPI responder.
This
The current semihost exception number (16) is a reserved number (range
[16-17]). The upcoming double trap specification uses that number for
the double trap exception. Since the privileged spec (Table 22) defines
ranges for custom uses change the semihosting exception number to 63
which belongs to
Michael Roth writes:
> From: Brijesh Singh
>
> SEV-SNP support relies on a different set of properties/state than the
> existing 'sev-guest' object. This patch introduces the 'sev-snp-guest'
> object, which can be used to configure an SEV-SNP guest. For example,
> a default-configured SEV-SNP gu
On Mon, 22 Apr 2024 16:13, Philippe Mathieu-Daudé wrote:
Since VirtIO devices can change endianness at runtime,
we need to use the device endianness, not the target
one.
Hey Philippe, can you clarify what do you mean by they can change
endianness at runtime?
The target's one is used because
The Zkr extension may only be exposed to KVM guests if the VMM
implements the SEED CSR. Use the same implementation as TCG.
Without this patch, running with a KVM which does not forward the
SEED CSR access to QEMU will result in an ILL exception being
injected into the guest (this results in Linux
On Mon, Apr 22, 2024 at 10:12:53AM -0300, Daniel Henrique Barboza wrote:
> Running a KVM guest using a 6.9-rc3 kernel, in a 6.8 host that has zkr
> enabled, will fail with a kernel oops SIGILL right at the start. The
> reason is that we can't expose zkr without implementing the SEED CSR.
> Disablin
W dniu 22.04.2024 o 14:56, Peter Maydell pisze:
On Fri, 19 Apr 2024 at 19:46, Peter Maydell wrote:
The upshot is that the only CPU type that changes is 'max'; but any
new type we add in future (whether v8.6 or not) will also get the new
1GHz default (assuming we spot in code review any attemp
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 ++--
1 file changed, 14 insertions(+), 6 delet
On 22/4/24 14:52, Manos Pitsidianakis wrote:
Extract audio card setup logic out of the device realize callback so
that it can be re-used in follow up commits.
Signed-off-by: Manos Pitsidianakis
---
hw/audio/virtio-snd.c | 72 ---
1 file changed, 41 ins
Hi Manos,
On 22/4/24 14:52, Manos Pitsidianakis wrote:
Factor out virtio_snd_config value validation in a separate function, in
order to re-use it in follow up commits.
Signed-off-by: Manos Pitsidianakis
---
hw/audio/virtio-snd.c | 47 ++-
1 file chan
Since VirtIO devices can change endianness at runtime,
we need to use the device endianness, not the target
one.
Cc: qemu-sta...@nongnu.org
Fixes: eb9ad377bb ("virtio-sound: handle control messages and streams")
Signed-off-by: Philippe Mathieu-Daudé
---
hw/audio/virtio-snd.c | 8 +---
1 file
Running a KVM guest using a 6.9-rc3 kernel, in a 6.8 host that has zkr
enabled, will fail with a kernel oops SIGILL right at the start. The
reason is that we can't expose zkr without implementing the SEED CSR.
Disabling zkr in the guest would be a workaround, but if the KVM doesn't
allow it we'll e
1 - 100 of 143 matches
Mail list logo
