07.06.2021 09:17, Klaus Jensen wrote:
Hi Vladimir,
Thanks for taking the time to look through this!
I'll try to comment on all your observations below.
On Jun 7 08:14, Vladimir Sementsov-Ogievskiy wrote:
04.06.2021 09:52, Klaus Jensen wrote:
From: Klaus Jensen
This series reimplements flu
On 05/06/2021 18.01, Maciej S. Szmigiero wrote:
Hi Thomas,
On 03.06.2021 12:41, Thomas Huth wrote:
I accidentally came accross vmstate_vmbus_dev and noticed that
it is currently not used at all ... wire it up and make it
static, since it is only used in one file.
Thomas Huth (2):
hw/hyperv/
03.06.2021 16:37, Paolo Bonzini wrote:
Even though it was only called for devices that have bs->sg set (which
must be character devices),
sg_get_max_segments looked at /sys/dev/block which only works for
block devices.
I assume, you keep /sys/dev/block code branch here only for following
conve
Le 02/06/2021 à 12:49, Philippe Mathieu-Daudé a écrit :
> Cc'ing qemu-trivial@
>
> On 3/18/21 4:39 PM, Philippe Mathieu-Daudé wrote:
>> ping?
>>
>> On 3/7/21 8:48 AM, Philippe Mathieu-Daudé wrote:
>>> MemoryRegion names is cached on first call to memory_region_name(),
It is cached on first call b
On 17.05.21 16:27, David Hildenbrand wrote:
Reviewed-by: Richard Henderson
Signed-off-by: David Hildenbrand
---
target/s390x/gen-features.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/target/s390x/gen-features.c b/target/s390x/gen-features.c
index a6ec918e90..219b1f9420 100644
--- a/
On 02.06.21 11:50, David Hildenbrand wrote:
On 01.06.21 23:27, Richard Henderson wrote:
On 5/17/21 7:27 AM, David Hildenbrand wrote:
@@ -634,6 +664,9 @@ uint64_t HELPER(clfxb)(CPUS390XState *env, uint64_t h,
uint64_t l, uint32_t m34)
s390_restore_bfp_rounding_mode(env, old_mode);
On 02.06.21 14:50, Cornelia Huck wrote:
With commit 0280b3eb7c05 ("s390x/kvm: use cpu model for gscb on
compat machines"), we removed any calls to kvm_s390_get_gs()
in favour of a different mechanism.
Let's remove the unused kvm_s390_get_gs(), and with it the now
unneeded cap_gs as well.
Sig
On 6/7/21 9:33 AM, Laurent Vivier wrote:
> Le 02/06/2021 à 12:49, Philippe Mathieu-Daudé a écrit :
>> Cc'ing qemu-trivial@
>>
>> On 3/18/21 4:39 PM, Philippe Mathieu-Daudé wrote:
>>> ping?
>>>
>>> On 3/7/21 8:48 AM, Philippe Mathieu-Daudé wrote:
MemoryRegion names is cached on first call to me
Hi philmd (and others),
So I just noticed your commit of requiring the size of an emulated SD
card to be a power of 2, when I was trying to emulate one for an
actual one (well, it's a microSD, but still), as it errored out.
You claim that the kernel will consider it to be a firmware bug and
"corr
Eduardo Habkost writes:
> On Fri, Jun 04, 2021 at 09:28:15AM +0200, Vitaly Kuznetsov wrote:
>> Eduardo Habkost writes:
>>
>> > On Thu, Jun 03, 2021 at 01:48:29PM +0200, Vitaly Kuznetsov wrote:
>> >> Currently, the only eVMCS version, supported by KVM (and described in
>> >> TLFS)
>> >> is '1'.
On 03.06.21 20:13, Richard Henderson wrote:
On 5/17/21 7:27 AM, David Hildenbrand wrote:
+if (unlikely(nan_a || nan_b)) {
Perhaps better as (dcmask_a | dcmask_b) & DCMASK_NAN ?
+if (sig_a || sig_b) {
Similarly.
Will do, thanks.
+} else if (unlikely(inf_a && inf_b)) {
+
Hi,
On 6/5/21 1:16 AM, Nicolin Chen wrote:
> (Resending as my previous mail didn't go through mailing lists)
>
> Hello Eric, Yubo, and other QEMU developers,
>
> I am having a problem with links between vSMMU and PCI Host Bridge,
> using ARM-VIRT (64-bit; ACPI) + SMMUv3 (nested translation) setup.
On 6/7/21 2:22 PM, Alistair Francis wrote:
On Mon, Jun 7, 2021 at 1:09 PM LIU Zhiwei wrote:
Hi Alistair,
As I see, we are moving on to remove TARGET_RISCV64 macro.
I have some questions:
1) Which tcg op should use when translate an instruction for 32bit cpu.
The tcg_*_i64, tcg_*_i32 or t
On 04/06/21 18:16, Eric Blake wrote:
On Fri, Jun 04, 2021 at 12:07:36PM +0200, Emanuele Giuseppe Esposito wrote:
Extract to a separate function. Do not rely on FOREACH_SAFE, which is
only "safe" if the *current* node is removed---not if another node is
removed. Instead, just walk the entire li
On 04/06/21 12:07, Emanuele Giuseppe Esposito wrote:
+WITH_QEMU_LOCK_GUARD(&s->lock) {
+new_state = s->state;
+QLIST_FOREACH_SAFE(rule, &s->rules[event], next, next) {
+process_rule(bs, rule, actions_count, &new_state);
+}
+s->state = new_state;
From: Klaus Jensen
Qiang Liu reported that an access on an unknown address is triggered in
memory_region_set_enabled because a check on CAP.PMRS is missing for the
PMRCTL register write when no PMR is configured.
Cc: qemu-sta...@nongnu.org
Fixes: 75c3c9de961d ("hw/block/nvme: disable PMR at boot
On Jun 1 07:30, Niklas Cassel wrote:
On Mon, May 31, 2021 at 09:39:20PM +0200, Klaus Jensen wrote:
On May 31 15:42, Niklas Cassel wrote:
> On Fri, May 28, 2021 at 01:22:38PM +0200, Klaus Jensen wrote:
> > On May 28 11:05, Niklas Cassel wrote:
> > > From: Niklas Cassel
> > >
> > > In the Zoned
On Mon, Jun 07, 2021 at 11:54:02AM +0200, Klaus Jensen wrote:
> On Jun 1 07:30, Niklas Cassel wrote:
> > On Mon, May 31, 2021 at 09:39:20PM +0200, Klaus Jensen wrote:
> > > On May 31 15:42, Niklas Cassel wrote:
> > > > On Fri, May 28, 2021 at 01:22:38PM +0200, Klaus Jensen wrote:
> > > > > On May
On Jun 7 10:11, Vladimir Sementsov-Ogievskiy wrote:
07.06.2021 09:17, Klaus Jensen wrote:
On Jun 7 08:14, Vladimir Sementsov-Ogievskiy wrote:
04.06.2021 09:52, Klaus Jensen wrote:
I've kept the RFC since I'm still new to using the block layer like
this. I was hoping that Stefan could find s
On Jun 7 09:58, Niklas Cassel wrote:
On Mon, Jun 07, 2021 at 11:54:02AM +0200, Klaus Jensen wrote:
On Jun 1 07:30, Niklas Cassel wrote:
> On Mon, May 31, 2021 at 09:39:20PM +0200, Klaus Jensen wrote:
> > On May 31 15:42, Niklas Cassel wrote:
> > > On Fri, May 28, 2021 at 01:22:38PM +0200, Klau
On May 31 21:39, Klaus Jensen wrote:
On May 31 15:42, Niklas Cassel wrote:
On Fri, May 28, 2021 at 01:22:38PM +0200, Klaus Jensen wrote:
On May 28 11:05, Niklas Cassel wrote:
From: Niklas Cassel
In the Zoned Namespace Command Set Specification, chapter
2.5.1 Managing resources
"The controll
Peter Maydell writes:
> On Fri, 4 Jun 2021 at 09:29, ishii.shuuic...@fujitsu.com
> wrote:
>>
>> Hi, Richard.
>>
>> > Well, Peter disagreed with having them enabled by default in -cpu max, so
>> > we
>> > might need at least one extra property. I see no reason to have three
>> > properties --
Jean-Philippe Brucker writes:
> Commit 382c7160d1cd ("hw/intc/arm_gicv3_cpuif: Fix EOIR write access
> check logic") added an assert_not_reached() if the guest writes the EOIR
> register while no interrupt is active.
>
> It turns out some software does this: EDK2, in
> GicV3ExitBootServicesEven
07.06.2021 13:00, Klaus Jensen wrote:
On Jun 7 10:11, Vladimir Sementsov-Ogievskiy wrote:
07.06.2021 09:17, Klaus Jensen wrote:
On Jun 7 08:14, Vladimir Sementsov-Ogievskiy wrote:
04.06.2021 09:52, Klaus Jensen wrote:
I've kept the RFC since I'm still new to using the block layer like
this
On 28/05/2021 08:07, Mark Cave-Ayland wrote:
On 18/05/2021 22:25, Mark Cave-Ayland wrote:
Following on from the ESP changes in QEMU 6.0 someone pointed out that the old
Linux 2.6 ESP driver as used in Aurelian's SPARC image at
https://people.debian.org/~aurel32/qemu/sparc/ emits a constant str
On 28/05/2021 08:11, Mark Cave-Ayland wrote:
On 19/05/2021 11:07, Mark Cave-Ayland wrote:
This patchset contains more ESP fixes from my attempts to boot MacOS under
the QEMU q800 machine (along with a related NetBSD fix).
With these patches it is possible for the MacOS toolbox ROM and MacOS d
This series adds support for the "Vector enhancements facility" and bumps
the qemu CPU model to a stripped-down z14.
I tested most vector FP instructions by generating random instructions
and vectors, comparing the result with results on actual hardware. I did
not test instructions/instruction var
Let's use the correct name.
Reviewed-by: Richard Henderson
Signed-off-by: David Hildenbrand
---
target/s390x/insn-data.def | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/target/s390x/insn-data.def b/target/s390x/insn-data.def
index 0bb1886a2e..35a0086a85 100644
--- a/ta
On Jun 7 13:24, Vladimir Sementsov-Ogievskiy wrote:
07.06.2021 13:00, Klaus Jensen wrote:
On Jun 7 10:11, Vladimir Sementsov-Ogievskiy wrote:
07.06.2021 09:17, Klaus Jensen wrote:
On Jun 7 08:14, Vladimir Sementsov-Ogievskiy wrote:
04.06.2021 09:52, Klaus Jensen wrote:
I've kept the RFC
Let's rework our macros and simplify. We still need helper functions in
most cases due to the different parameters types.
Next, we'll only have 32/128bit variants for vfi and vfsq, so special
case the others.
Note that for vfsq, the XxC and erm passed in the simd_data() will never be
set, resulti
In case we encounter a NaN, we have to return the smallest possible
number, corresponding to either 0 or the maximum negative number. This
seems to differ from IEEE handling as implemented in softfloat, whereby
we return the biggest possible number.
While at it, use float32_to_uint64() in the CLGE
Reviewed-by: Richard Henderson
Signed-off-by: David Hildenbrand
---
target/s390x/helper.h | 1 -
target/s390x/translate_vx.c.inc | 6 +-
target/s390x/vec_fpu_helper.c | 21 +
3 files changed, 6 insertions(+), 22 deletions(-)
diff --git a/target/s390x/helper
Reviewed-by: Richard Henderson
Signed-off-by: David Hildenbrand
---
target/s390x/helper.h | 2 --
target/s390x/translate_vx.c.inc | 8 +++
target/s390x/vec_fpu_helper.c | 42 +
3 files changed, 20 insertions(+), 32 deletions(-)
diff --git a/targ
Let's simplify, reworking our handler generation, passing the whole "m5"
register content and not providing specialized handlers for "se", and
reading/writing proper float64 values using new helpers.
Suggested-by: Richard Henderson
Reviewed-by: Richard Henderson
Signed-off-by: David Hildenbrand
Reviewed-by: Richard Henderson
Signed-off-by: David Hildenbrand
---
target/s390x/helper.h | 4 +++
target/s390x/translate_vx.c.inc | 38 ++--
target/s390x/vec_fpu_helper.c | 44 -
3 files changed, 77 insertions(+), 9 deletions(
... and prepare for 32/128 bit support.
Reviewed-by: Richard Henderson
Signed-off-by: David Hildenbrand
---
target/s390x/vec_fpu_helper.c | 23 ---
1 file changed, 12 insertions(+), 11 deletions(-)
diff --git a/target/s390x/vec_fpu_helper.c b/target/s390x/vec_fpu_helper.c
i
Reviewed-by: Richard Henderson
Signed-off-by: David Hildenbrand
---
target/s390x/helper.h | 1 -
target/s390x/translate_vx.c.inc | 7 ++-
target/s390x/vec_fpu_helper.c | 29 +++--
3 files changed, 13 insertions(+), 24 deletions(-)
diff --git a/target/s3
In addition to 32/128bit variants, we also have to support the
"Signal-on-QNaN (SQ)" bit.
Reviewed-by: Richard Henderson
Signed-off-by: David Hildenbrand
---
target/s390x/helper.h | 12 +++
target/s390x/translate_vx.c.inc | 57 -
target/s390x/vec_fpu_he
Fortunately, we only need the Doubleword implementation.
Reviewed-by: Richard Henderson
Signed-off-by: David Hildenbrand
---
target/s390x/insn-data.def | 2 ++
target/s390x/translate_vx.c.inc | 50 +
2 files changed, 52 insertions(+)
diff --git a/target/s3
Pass the m5 field via simd_data() and don't provide specialized handlers
for single-element variants.
Reviewed-by: Richard Henderson
Signed-off-by: David Hildenbrand
---
target/s390x/helper.h | 6 ---
target/s390x/translate_vx.c.inc | 45 +---
target/s390x/vec_fpu_helper.
Reviewed-by: Richard Henderson
Signed-off-by: David Hildenbrand
---
target/s390x/helper.h | 1 -
target/s390x/translate_vx.c.inc | 3 +--
target/s390x/vec_fpu_helper.c | 29 +++--
3 files changed, 8 insertions(+), 25 deletions(-)
diff --git a/target/s390x/h
64 bit -> 128 bit, there is only a single final element.
Reviewed-by: Richard Henderson
Signed-off-by: David Hildenbrand
---
target/s390x/helper.h | 1 +
target/s390x/translate_vx.c.inc | 19 ---
target/s390x/vec_fpu_helper.c | 13 +
3 files changed, 30
128 bit -> 64 bit, there is only a single element to process.
Reviewed-by: Richard Henderson
Signed-off-by: David Hildenbrand
---
target/s390x/helper.h | 1 +
target/s390x/translate_vx.c.inc | 11 ++-
target/s390x/vec_fpu_helper.c | 19 +++
3 files changed,
In case of 128bit, we always have a single element. Add new helpers for
reading/writing 32/128 bit floats.
Reviewed-by: Richard Henderson
Signed-off-by: David Hildenbrand
---
target/s390x/helper.h | 8
target/s390x/translate_vx.c.inc | 85 +
targe
Reviewed-by: Richard Henderson
Signed-off-by: David Hildenbrand
---
target/s390x/helper.h | 1 +
target/s390x/insn-data.def | 2 ++
target/s390x/translate_vx.c.inc | 8
target/s390x/vec_helper.c | 22 ++
4 files changed, 33 insertions(+)
diff
Reviewed-by: Richard Henderson
Signed-off-by: David Hildenbrand
---
target/s390x/translate_vx.c.inc | 106 ++--
1 file changed, 73 insertions(+), 33 deletions(-)
diff --git a/target/s390x/translate_vx.c.inc b/target/s390x/translate_vx.c.inc
index e94c9f9d86..4d1ccb41
Define the new system registers that MTE introduces and context switch
them. The MTE feature is still hidden from the ID register as it isn't
supported in a VM yet.
Reviewed-by: Catalin Marinas
Signed-off-by: Steven Price
---
arch/arm64/include/asm/kvm_arm.h | 3 +-
arch/arm64/includ
Reviewed-by: Richard Henderson
Signed-off-by: David Hildenbrand
---
target/s390x/helper.h | 4 ++
target/s390x/translate_vx.c.inc | 74 ++---
target/s390x/vec_fpu_helper.c | 46 +++-
3 files changed, 109 insertions(+), 15 deletions(-)
dif
Let's check for S390_FEAT_VECTOR_ENH and set HWCAP_S390_VXRS_EXT
accordingly.
Cc: Laurent Vivier
Signed-off-by: David Hildenbrand
---
include/elf.h| 1 +
linux-user/elfload.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/include/elf.h b/include/elf.h
index 033bcc9576..0049d5a318
Reviewed-by: Richard Henderson
Signed-off-by: David Hildenbrand
---
target/s390x/helper.h | 2 ++
target/s390x/translate_vx.c.inc | 23 ++--
target/s390x/vec_fpu_helper.c | 47 +
3 files changed, 70 insertions(+), 2 deletions(-)
diff --gi
It's now safe for the VMM to enable MTE in a guest, so expose the
capability to user space.
Reviewed-by: Catalin Marinas
Signed-off-by: Steven Price
---
arch/arm64/kvm/arm.c | 9 +
arch/arm64/kvm/reset.c| 3 ++-
arch/arm64/kvm/sys_regs.c | 3 +++
3 files changed, 14 insertions(
Reviewed-by: Richard Henderson
Signed-off-by: David Hildenbrand
---
target/s390x/helper.h | 4 +++
target/s390x/translate_vx.c.inc | 47 -
target/s390x/vec_fpu_helper.c | 44 +-
3 files changed, 87 insertions(+), 8 deletion
A new capability (KVM_CAP_ARM_MTE) identifies that the kernel supports
granting a guest access to the tags, and provides a mechanism for the
VMM to enable it.
A new ioctl (KVM_ARM_MTE_COPY_TAGS) provides a simple way for a VMM to
access the tags of a guest without having to maintain a PROT_MTE map
Add a new VM feature 'KVM_ARM_CAP_MTE' which enables memory tagging
for a VM. This will expose the feature to the guest and automatically
tag memory pages touched by the VM as PG_mte_tagged (and clear the tag
storage) to ensure that the guest cannot see stale tags, and so that
the tags are correctl
Reviewed-by: Richard Henderson
Signed-off-by: David Hildenbrand
---
target/s390x/helper.h | 6 +
target/s390x/insn-data.def | 4
target/s390x/translate_vx.c.inc | 39 +++--
target/s390x/vec_fpu_helper.c | 2 ++
4 files changed, 49 insertio
The VMM may not wish to have it's own mapping of guest memory mapped
with PROT_MTE because this causes problems if the VMM has tag checking
enabled (the guest controls the tags in physical RAM and it's unlikely
the tags are correct for the VMM).
Instead add a new ioctl which allows the VMM to easi
Everything is wired up and all new instructions are implemented.
Reviewed-by: Richard Henderson
Signed-off-by: David Hildenbrand
---
target/s390x/gen-features.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/target/s390x/gen-features.c b/target/s390x/gen-features.c
index a6ec918e90..219b1f
For IEEE functions, we can reuse the softfloat implementations. For the
other functions, implement it generically for 32bit/64bit/128bit -
carefully taking care of all weird special cases according to the tables
defined in the PoP.
Signed-off-by: David Hildenbrand
---
target/s390x/helper.h
From: Catalin Marinas
Currently, on an anonymous page fault, the kernel allocates a zeroed
page and maps it in user space. If the mapping is tagged (PROT_MTE),
set_pte_at() additionally clears the tags under a spinlock to avoid a
race on the page->flags. In order to optimise the lock, clear the p
Le 07/06/2021 à 10:28, Philippe Mathieu-Daudé a écrit :
> On 6/7/21 9:33 AM, Laurent Vivier wrote:
>> Le 02/06/2021 à 12:49, Philippe Mathieu-Daudé a écrit :
>>> Cc'ing qemu-trivial@
>>>
>>> On 3/18/21 4:39 PM, Philippe Mathieu-Daudé wrote:
ping?
On 3/7/21 8:48 AM, Philippe Mathieu-D
TCG implements everything we need to run basic z14 OS+software.
Reviewed-by: Richard Henderson
Signed-off-by: David Hildenbrand
---
hw/s390x/s390-virtio-ccw.c | 3 +++
target/s390x/cpu_models.c | 4 ++--
target/s390x/gen-features.c | 15 +--
3 files changed, 14 insertions(+), 8
This series adds support for using the Arm Memory Tagging Extensions
(MTE) in a KVM guest.
Changes since v13[1]:
* Add Reviewed-by tags from Catalin - thanks!
* Introduce a new function mte_prepare_page_tags() for handling the
initialisation of pages ready for a KVM guest. This takes the bi
mte_sync_tags() used test_and_set_bit() to set the PG_mte_tagged flag
before restoring/zeroing the MTE tags. However if another thread were to
race and attempt to sync the tags on the same page before the first
thread had completed restoring/zeroing then it would see the flag is
already set and con
A KVM guest could store tags in a page even if the VMM hasn't mapped
the page with PROT_MTE. So when restoring pages from swap we will
need to check to see if there are any saved tags even if !pte_tagged().
However don't check pages for which pte_access_permitted() returns false
as these will not
Philippe Mathieu-Daudé writes:
> This job is hitting the 70min limit, so split it in 2 tasks.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> .gitlab-ci.d/buildtest.yml | 17 ++---
> 1 file changed, 14 insertions(+), 3 deletions(-)
I've grabbed this for the PR I'm rolling now..
From: Marc-André Lureau
libslirp is known to have several security flaws, we should make it
explicit by warning the users and in the documentation.
Signed-off-by: Marc-André Lureau
---
docs/system/net.rst | 9 +
net/slirp.c | 2 ++
qemu-options.hx | 4 +++-
3 files changed,
On Fri, 28 May 2021 14:14:15 -0400
Eric DeVolder wrote:
> This change implements the support for the ACPI ERST feature[1,2].
>
> The size of the ACPI ERST storage is declared via the QEMU
> global parameter acpi-erst.size. The size can range from 64KiB
> to to 64MiB. The default is 64KiB.
>
> T
On Mon, 7 Jun 2021 at 12:50, wrote:
>
> From: Marc-André Lureau
>
> libslirp is known to have several security flaws, we should make it
> explicit by warning the users and in the documentation.
>
> Signed-off-by: Marc-André Lureau
> --- a/net/slirp.c
> +++ b/net/slirp.c
> @@ -388,6 +388,8 @@ st
On Tue, 1 Jun 2021 at 12:01, Marc-André Lureau
wrote:
>
> Hi Peter
>
> On Tue, Jun 1, 2021 at 1:17 PM Peter Maydell wrote:
>>
>> On Sat, 29 May 2021 at 19:55, wrote:
>> >
>> > From: Marc-André Lureau
>> >
>> > The following changes since commit
>> > 62c0ac5041e9130b041adfa13a41583d3c3ddd24:
>>
On 20/05/2021 16:51, matheus.fe...@eldorado.org.br wrote:
From: Matheus Ferst
Change the regex used to determine whether a file should be processed as
C source to include .c.inc and .h.inc extensions.
Signed-off-by: Matheus Ferst
---
scripts/checkpatch.pl | 4 ++--
1 file changed, 2 insert
On Fri, 28 May 2021 14:14:17 -0400
Eric DeVolder wrote:
> This change enables ERST support for x86 guests.
>
> ERST can be disabled at run-time, for example, with:
>
> -machine q35,erst=off
1st: not everyone needs this feature so I'd turn it off by default
2nd: it looks to me that patch break
On Fri, 28 May 2021 14:14:16 -0400
Eric DeVolder wrote:
> This change includes ERST in the build of ACPI.
>
> Signed-off-by: Eric DeVolder
> ---
> hw/acpi/meson.build | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/hw/acpi/meson.build b/hw/acpi/meson.build
> index dd69577..262a8ee 10
On Fri, 28 May 2021 14:14:12 -0400
Eric DeVolder wrote:
> NOTE: Also, I wanted to push this v3 for review while alerting
> that I will be on holiday through June 8 (possibly a few days
> later).
this version addressed only the way the host storage is accessed
(and even that is only partially and
On 06/06/21 20:13, Stefan Weil wrote:
> Am 02.06.17 um 16:35 schrieb Peter Maydell:
>
>> We want the wide character functions from the ncurses header.
>> Unfortunately it doesn't provide them by default, but only
>> if either:
>> * NCURSES_WIDECHAR is defined (for ncurses 20111030 and up)
>> *
The highest VBE_DISPI_INDEX_ID version supported by QEMU is
VBE_DISPI_ID5. But currently QEMU only allows writing values up to
VBE_DISPI_ID4 to the VBE_DISPI_INDEX_ID register.
As a result of this when a lower version is written to this register and
later VBE_DISPI_ID5 is written back, reads from
> If somebody has access to A64 hardware they could write a minor kernel
> patch to just print the values...
Yes, it's an ARM standard system register, so it's information that
users can find by checking. As you said, it is possible to check it that way,
and we would like to consider implementing
On Mon, Jun 07, 2021 at 02:57:41PM +0200, Laszlo Ersek wrote:
> On 06/06/21 20:13, Stefan Weil wrote:
> > Am 02.06.17 um 16:35 schrieb Peter Maydell:
> >
> >> We want the wide character functions from the ncurses header.
> >> Unfortunately it doesn't provide them by default, but only
> >> if eithe
On 04/06/2021 17.51, Alex Bennée wrote:
From: Philippe Mathieu-Daudé
Introduce the 'query-accels' QMP command which returns a list
of built-in accelerator names.
- Accelerator is a QAPI enum of all existing accelerators,
- AcceleratorInfo is a QAPI structure providing accelerator
specific
On 04/06/2021 17.51, Alex Bennée wrote:
From: Philippe Mathieu-Daudé
Introduce the qtest_has_accel() method which allows a runtime
query on whether a QEMU instance has an accelerator built-in.
Reviewed-by: Eric Blake
Reviewed-by: Alex Bennée
Signed-off-by: Philippe Mathieu-Daudé
Signed-off-
On 04/06/2021 17.51, Alex Bennée wrote:
From: Philippe Mathieu-Daudé
Use the recently added generic qtest_has_accel() method to
check if KVM is available.
Suggested-by: Claudio Fontana
Reviewed-by: Andrew Jones
Reviewed-by: Alex Bennée
Signed-off-by: Philippe Mathieu-Daudé
Signed-off-by: A
On 04/06/2021 17.51, Alex Bennée wrote:
From: Philippe Mathieu-Daudé
sve_tests_sve_off_kvm() and test_query_cpu_model_expansion_kvm()
tests are now only being run if KVM is available. Drop the TCG
fallback.
Suggested-by: Andrew Jones
Reviewed-by: Andrew Jones
Reviewed-by: Alex Bennée
Signed
On 04/06/2021 17.51, Alex Bennée wrote:
From: Philippe Mathieu-Daudé
Now than we can probe if the TCG accelerator is available
at runtime with a QMP command, only run these tests if TCG
is built into the QEMU binary.
Suggested-by: Andrew Jones
Reviewed-by: Andrew Jones
Reviewed-by: Alex Benn
On 04/06/2021 17.51, Alex Bennée wrote:
From: Philippe Mathieu-Daudé
We might have a s390x/ppc64 QEMU binary built without the KVM
accelerator (configured with --disable-kvm).
Checking for /dev/kvm accessibility isn't enough, also check for the
accelerator in the binary.
Reviewed-by: David Gib
On 04/06/2021 17.51, Alex Bennée wrote:
From: Philippe Mathieu-Daudé
Various tests don't require TCG, but have '_tcg' in their name.
As this is misleading, remove 'tcg' from their name.
Reported-by: Igor Mammedov
Reviewed-by: Igor Mammedov
Signed-off-by: Philippe Mathieu-Daudé
Signed-off-by
On 04/06/2021 17.51, Alex Bennée wrote:
From: Philippe Mathieu-Daudé
Some tests require TCG, but don't have '_tcg' in their name,
while others do. Unify the test names by adding 'tcg' to the
TCG specific tests.
Reported-by: Igor Mammedov
Reviewed-by: Igor Mammedov
Signed-off-by: Philippe Mat
On 04/06/2021 17.51, Alex Bennée wrote:
From: Philippe Mathieu-Daudé
Now that we can probe if the TCG accelerator is available
at runtime with a QMP command, do it once at the beginning
and only register the tests we can run.
We can then replace the #ifdef'ry by an assertion.
Reviewed-by: Eric
On 04/06/2021 17.51, Alex Bennée wrote:
From: Philippe Mathieu-Daudé
Since commit 82bf7ae84ce ("target/arm: Remove KVM support for
32-bit Arm hosts") we can remove the comment / check added in
commit ab6b6a4 and directly run the bios-tables-test.
Reviewed-by: Eric Blake
Reviewed-by: Alex
"Matheus K. Ferst" writes:
> On 20/05/2021 16:51, matheus.fe...@eldorado.org.br wrote:
>> From: Matheus Ferst
>> Change the regex used to determine whether a file should be
>> processed as
>> C source to include .c.inc and .h.inc extensions.
>> Signed-off-by: Matheus Ferst
>> ---
>> scripts
On Fri, 4 Jun 2021 at 22:27, Richard Henderson
wrote:
>
> Introduce a function to remove everything emitted
> since a given point.
>
> Cc: Peter Maydell
> Signed-off-by: Richard Henderson
> ---
> include/tcg/tcg.h | 1 +
> tcg/tcg.c | 13 +
> 2 files changed, 14 insertions(
On Thu, 2021-06-03 at 15:37 +0200, Paolo Bonzini wrote:
> Hi Kevin,
>
> this is a combination of two series that both affect host block device
> support in block/file-posix.c. Joelle's series is unchanged, while
> mine was adjusted according to your review of v2.
>
> v1->v2: add missing patch
>
It is useful to know which CPUs satisfy each x86-64 ABI
compatibility level, when dealing with guest OS that require
something newer than the baseline ABI.
These ABI levels are defined in:
https://gitlab.com/x86-psABIs/x86-64-ABI/
and supported by GCC, Clang, glibc and more.
Signed-off-by: Da
This series is motivated by this blog that describes how RHEL-9
will recommend use of the x86-64-v2 microarchitectural ABI level:
https://developers.redhat.com/blog/2021/01/05/building-red-hat-enterprise-linux-9-for-the-x86-64-v2-microarchitecture-level/
The implication of compiling code with
This script is what is used to generate the docs data table in:
docs/system/cpu-models-x86-abi.csv
It can be useful to run if adding new CPU models / versions and
the csv needs updating.
Signed-off-by: Daniel P. Berrangé
---
scripts/cpu-x86-uarch-abi.py | 194
To paraphrase:
https://developers.redhat.com/blog/2021/01/05/building-red-hat-enterprise-linux-9-for-the-x86-64-v2-microarchitecture-level/
In 2020, AMD, Intel, Red Hat, and SUSE worked together to define
three microarchitecture levels on top of the historical x86-64
baseline:
* x86-64:
The only differences between x86-64-abi1 and qemu64 is that the former
does not have the 'vme' or 'svm' flags.
In practice I don't think we should make this change, because it doesn't
especially add any value as-is. The only possible case is around 'svm'
because KVM already masks that feature, but
When using libvirt for RDMA live migration, if the VM memory is too large,
it will take a lot of time to deregister the VM at the source side, resulting
in a long downtime (VM 64G, deregister vm time is about 400ms).
Although the VM's memory uses 2M huge pages, the MLNX driver still uses 4K
pa
On 11/05/21 17:39, Paolo Bonzini wrote:
Creating and destroying network backend does not require a fully
constructed machine. Allow the related monitor commands to run before
machine initialization has concluded.
Signed-off-by: Paolo Bonzini
---
hmp-commands.hx | 2 ++
qapi/net.json | 6 +
On 11/05/21 17:39, Paolo Bonzini wrote:
Most block device commands do not require a fully constructed machine.
Allow running them before machine initialization has concluded.
Signed-off-by: Paolo Bonzini
---
hmp-commands.hx| 14 +
qapi/block-core.json | 117 +++
On Mon, Jun 07, 2021 at 01:57:02PM +, LIZHAOXIN1 [李照鑫] wrote:
> When using libvirt for RDMA live migration, if the VM memory is too large,
> it will take a lot of time to deregister the VM at the source side, resulting
> in a long downtime (VM 64G, deregister vm time is about 400ms).
>
> A
On Mon, May 17, 2021 at 08:30:32PM +0400, marcandre.lur...@redhat.com wrote:
> From: Marc-André Lureau
>
> Wrap the 'if' condition in a higher-level object. Not only this allows
> more type safety but also further refactoring without too much churn.
Grammar suggestion:
Not only does this provid
1 - 100 of 374 matches
Mail list logo
