On 24/11/2021 22:00, Fabiano Rosas wrote:
Fabiano Rosas writes:
Hi all,
We have this bug in QEMU which indicates that we haven't been able to
run openbios on a 7450 cpu for quite a long time:
https://gitlab.com/qemu-project/qemu/-/issues/86
OK:
$ ./qemu-system-ppc -serial mon:stdio -nog
On 11/25/2021 9:53 PM, Hanna Reitz wrote:
> After migration, the permissions the guest device wants to impose on its
> BlockBackend are stored in blk->perm and blk->shared_perm. In
> blk_root_activate(), we take our permissions, but keep all shared
> permissions open by calling `blk_set_perm(blk->
On 25/11/2021 08:20, yangxiaojuan wrote:
Hi Mark,
On 11/11/2021 10:49 PM, Mark Cave-Ayland wrote:
On 11/11/2021 01:35, Xiaojuan Yang wrote:
This patch realize the EIOINTC interrupt controller.
Signed-off-by: Xiaojuan Yang
Signed-off-by: Song Gao
---
hw/intc/Kconfig|
Hello,
On 11/25/21 10:38, Segher Boessenkool wrote:
Hi!
On Thu, Nov 25, 2021 at 01:45:00AM +0100, BALATON Zoltan wrote:
As for guests, those running on the said PowerMac G4 should have support
for these CPUs so maybe you can try some Mac OS X versions (or maybe
OSX uses hardware pagetables.
On 11/26/21 09:01, Mark Cave-Ayland wrote:
On 24/11/2021 22:00, Fabiano Rosas wrote:
Fabiano Rosas writes:
Hi all,
We have this bug in QEMU which indicates that we haven't been able to
run openbios on a 7450 cpu for quite a long time:
https://gitlab.com/qemu-project/qemu/-/issues/86
OK:
On 26/11/2021 08:40, Cédric Le Goater wrote:
On 11/26/21 09:01, Mark Cave-Ayland wrote:
On 24/11/2021 22:00, Fabiano Rosas wrote:
Fabiano Rosas writes:
Hi all,
We have this bug in QEMU which indicates that we haven't been able to
run openbios on a 7450 cpu for quite a long time:
https://
On 11/16/21 18:01, Frederic Barrat wrote:
The PHB v4 found on POWER9 doesn't request any LSI, so let's clear the
Interrupt Pin register in the config space so that the model matches
the hardware.
If we don't, then we inherit from the default pcie root bridge, which
requests a LSI. And because we
Hello,
Curiously, I didn't get the v2 email.
On 11/26/21 02:13, David Gibson wrote:
On Thu, Nov 25, 2021 at 03:33:22PM -0300, Leandro Lupori wrote:
When updating the R bit of a PTE, the Hash64 MMU was using a wrong byte
offset, causing the first byte of the adjacent PTE to be corrupted.
This c
"Dr. David Alan Gilbert" wrote:
> * Juan Quintela (quint...@redhat.com) wrote:
>> Signed-off-by: Juan Quintela
>
> Pretty obvious, but I guess to have the complete set of comments:
Yeap. When I was removing the used parameter, I found that we have this
function without the comment. If we have
"Dr. David Alan Gilbert" wrote:
> * Juan Quintela (quint...@redhat.com) wrote:
>> "Dr. David Alan Gilbert" wrote:
>> > * Juan Quintela (quint...@redhat.com) wrote:
>> >> We are divining by page_size to multiply again in the only use.
>> > ^--- typo
>> >> Once there, impreve the comme
On 11/25/21 4:41 PM, Alex Bennée wrote:
Here we introduce a new compiler flag to disable the checking of exit
request (icount_decr.u32). This is useful when we want to ensure the
next block cannot be preempted by an asynchronous event.
Suggested-by: Richard Henderson
Signed-off-by: Alex Bennée
My borntrae...@de.ibm.com email is just a forwarder to the
linux.ibm.com address. Let us remove the extra hop to avoid
a potential source of errors.
While at it, add the relevant email addresses to mailmap.
Signed-off-by: Christian Borntraeger
---
.mailmap| 1 +
MAINTAINERS | 6 +++---
2 fi
On 11/25/21 4:41 PM, Alex Bennée wrote:
@@ -1738,7 +1738,7 @@ tb_invalidate_phys_page_range__locked(struct
page_collection *pages,
if (current_tb_modified) {
page_collection_unlock(pages);
/* Force execution of one insn next time. */
-cpu->cflags_next_tb = 1 |
Hi!
On Fri, Nov 26, 2021 at 09:34:44AM +0100, Cédric Le Goater wrote:
> On 11/25/21 10:38, Segher Boessenkool wrote:
> >On Thu, Nov 25, 2021 at 01:45:00AM +0100, BALATON Zoltan wrote:
> >>As for guests, those running on the said PowerMac G4 should have support
> >>for these CPUs so maybe you can t
On 11/26/21 3:23 AM, Song Gao wrote:
No code change
Suggested-by: Richard Henderson
Signed-off-by: Song Gao
Reviewed-by: Laurent Vivier
---
linux-user/aarch64/target_signal.h| 18 --
linux-user/arm/target_signal.h| 18 --
linux-user/cris/target_sig
On 11/26/21 3:23 AM, Song Gao wrote:
TARGET_MINSIGSTKSZ has been defined in generic/signal.h
or target_signal.h, We don't need to define it again.
Signed-off-by: Song Gao
Reviewed-by: Laurent Vivier
Reviewed-by: Philippe Mathieu-Daudé
---
linux-user/aarch64/target_syscall.h| 1 -
linux-us
On 11/26/21 3:23 AM, Song Gao wrote:
TARGET_SIGSTKSZ is not used, we should remove it.
Signed-off-by: Song Gao
---
linux-user/alpha/target_signal.h | 1 -
linux-user/generic/signal.h | 1 -
linux-user/hppa/target_signal.h | 1 -
linux-user/mips/target_signal.h | 1 -
linux-user/
On Fri, 19 Nov 2021 18:53:43 +
Jonathan Cameron wrote:
> On Thu, 18 Nov 2021 17:52:07 -0800
> Ben Widawsky wrote:
>
> > On 21-11-18 15:20:34, Saransh Gupta1 wrote:
> > > Hi Ben and Jonathan,
> > >
> > > Thanks for your replies. I'm looking forward to the patches.
> > >
> > > For QEMU, I
On Thu, Nov 25, 2021 at 12:08:11PM -0300, Daniel Henrique Barboza wrote:
> MMCR1 determines the events to be sampled by the PMU. Updating the
> counters at every MMCR1 write ensures that we're not sampling more
> or less events by looking only at MMCR0 and the PMCs.
>
> It is worth noticing that b
On Thu, Nov 25, 2021 at 12:08:09PM -0300, Daniel Henrique Barboza wrote:
> This patch adds the barebones of the PMU logic by enabling cycle
> counting. The overall logic goes as follows:
>
> - MMCR0 reg initial value is set to 0x8000 (MMCR0_FC set) to avoid
> having to spin the PMU right at sy
On Thu, Nov 25, 2021 at 12:08:10PM -0300, Daniel Henrique Barboza wrote:
> Calling pmu_update_cycles() on every PMC read/write operation ensures
> that the values being fetched are up to date with the current PMU state.
>
> In theory we can get away by just trapping PMCs reads, but we're going
> t
On 11/25/21 8:39 AM, LIU Zhiwei wrote:
+static bool check_pmp_reg_index(CPURISCVState *env, uint32_t reg_index)
+{
+if ((reg_index & 1) && (riscv_cpu_mxl(env) == MXL_RV64)) {
Let's make this != MXL_RV32. I suppose real RV128 will extend this restriction to mod 4,
but that is not yet docum
Hi
On Fri, Nov 26, 2021 at 10:49 AM Priyankar Jain
wrote:
> The purpose of dbus_get_proxies to construct the proxies corresponding to
> the
> IDs registered to dbus-vmstate.
>
> Currenty, this function returns an error in case there is any failure
> while instantiating proxy for "all" the names
On 11/25/21 8:39 AM, LIU Zhiwei wrote:
Signed-off-by: LIU Zhiwei
---
target/riscv/cpu.c| 1 +
target/riscv/cpu.h| 3 +++
target/riscv/cpu_helper.c | 3 ++-
target/riscv/csr.c| 2 ++
target/riscv/machine.c| 5 +++--
5 files changed, 11 insertions(+), 3 deletions
On 11/25/21 8:39 AM, LIU Zhiwei wrote:
Signed-off-by: LIU Zhiwei
Reviewed-by: Alistair Francis
---
target/riscv/cpu.c| 1 +
target/riscv/cpu.h| 4
target/riscv/cpu_helper.c | 43 +++
target/riscv/csr.c| 19 +
On 11/25/21 8:39 AM, LIU Zhiwei wrote:
The mask comes from the pointer masking extension, or the max value
corresponding to XLEN bits.
Signed-off-by: LIU Zhiwei
Acked-by: Alistair Francis
---
target/riscv/vector_helper.c | 23 ++-
1 file changed, 14 insertions(+), 9 deleti
The following changes since commit 67f9968ce3f0847ffddb6ee2837a3641acd92abf:
Update version for v6.2.0-rc1 release (2021-11-16 21:07:31 +0100)
are available in the Git repository at:
https://github.com/legoater/qemu/ tags/pull-ppc-2029
for you to fetch changes up to a443d55c3f7cafa3d5df
From: Richard Henderson
With a host compiler new enough to recognize power10 insns,
CROSS_CC_HAS_POWER10 is true, but we do not supply the -cpu
option to the compiler, resulting in
/tmp/ccAVdYJd.s: Assembler messages:
/tmp/ccAVdYJd.s:49: Error: unrecognized opcode: `brh'
/tmp/ccAVdYJd.s:78: Erro
The VP space is larger in XIVE2 (P10), 24 bits instead of 19bits on
XIVE (P9), and the CAM line can use a 7bits or 8bits thread id.
For now, we only use 7bits thread ids, same as P9, but because of the
change of the size of the VP space, the CAM matching routine is
different between P9 and P10. It
The XIVE2 interrupt controller of the POWER10 processor as the same
logic as on POWER9 but its SW interface has been largely reworked. The
interrupt controller has a new register interface, different BARs,
extra VSDs. These will be described when we add the device model for
the baremetal machine.
and use a pnv_chip_power10_quad_realize() helper to avoid code
duplication with P9. This still needs some refinements on the XSCOM
registers handling in PnvQuad.
Signed-off-by: Cédric Le Goater
---
include/hw/ppc/pnv.h | 3 +++
hw/ppc/pnv.c | 50 +++--
The XIVE2 interrupt controller of the POWER10 processor follows the
same logic than on POWER9 but the HW interface has been largely
reviewed. It has a new register interface, different BARs, extra
VSDs, new layout for the XIVE2 structures, and a set of new features
which are described below.
This
From: Laurent Vivier
The subsection is not closed by a NULL marker so this can trigger
a segfault when the pmu vmstate is saved.
This can be easily shown with:
$ ./qemu-system-ppc64 -dump-vmstate vmstate.json
Segmentation fault (core dumped)
Fixes: d811d61fbc6c ("mac_newworld: add PMU dev
Reviewed-by: David Gibson
Signed-off-by: Cédric Le Goater
---
include/hw/ppc/pnv.h | 10 ++
include/hw/ppc/pnv_homer.h | 3 ++
include/hw/ppc/pnv_xscom.h | 3 ++
hw/ppc/pnv.c | 20
hw/ppc/pnv_homer.c | 64 ++
5 fi
The trigger message coming from a HW source contains a special bit
informing the XIVE interrupt controller that the PQ bits have been
checked at the source or not. Depending on the value, the IC can
perform the check and the state transition locally using its own PQ
state bits.
The following chang
POWER10 adds support for StoreEOI operation and 64K ESB pages on PSIHB
to be consistent with the other interrupt sources of the system.
Signed-off-by: Cédric Le Goater
---
hw/ppc/pnv.c | 6 ++
hw/ppc/pnv_psi.c | 30 --
2 files changed, 30 insertions(+), 6 del
PHB4 and PHB5 are very similar. Use the PHB4 models with some minor
adjustements in a subclass for P10.
Signed-off-by: Cédric Le Goater
---
include/hw/pci-host/pnv_phb4.h | 11
include/hw/ppc/pnv.h | 3 ++
include/hw/ppc/pnv_xscom.h | 6 +++
hw/pci-host/pnv_phb4_pec.c |
Oops forget this email. I got the directory wrong on my command line.
Sorry for the noise.
C.
On 11/26/21 12:51, Cédric Le Goater wrote:
The following changes since commit 67f9968ce3f0847ffddb6ee2837a3641acd92abf:
Update version for v6.2.0-rc1 release (2021-11-16 21:07:31 +0100)
are avail
This is an internal offset used to inject triggers when the PQ state
bits are not controlled locally. Such as for LSIs when the PHB5 are
using the Address-Based Interrupt Trigger mode and on the END.
Signed-off-by: Cédric Le Goater
---
include/hw/ppc/xive.h | 1 +
hw/intc/xive.c| 9 +++
The PQ_disable configuration bit disables the check done on the PQ
state bits when processing new MSI interrupts. When bit 9 is enabled,
the PHB forwards any MSI trigger to the XIVE interrupt controller
without checking the PQ state bits. The XIVE IC knows from the trigger
message that the PQ bits
Hi,
The skiboot merged in QEMU already has POWER10 support. This series
adds a minimum set of models (XIVE2, PHB5) to boot a baremetal POWER10
machine using the OpenPOWER firmware images.
The major change is the support for the interrupt controller of the
POWER10 processor. XIVE2 is very much lik
Signed-off-by: Cédric Le Goater
---
include/hw/ppc/xive2.h | 1 +
hw/intc/pnv_xive2.c| 5 +
hw/intc/xive2.c| 3 ++-
3 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/include/hw/ppc/xive2.h b/include/hw/ppc/xive2.h
index 88c3e393162d..001388ccea7a 100644
--- a/include/h
Our OCC model is very mininal and POWER10 can simply reuse the OCC
model we introduced for POWER9.
Reviewed-by: David Gibson
Signed-off-by: Cédric Le Goater
---
include/hw/ppc/pnv.h | 1 +
include/hw/ppc/pnv_occ.h | 2 ++
include/hw/ppc/pnv_xscom.h | 3 +++
hw/ppc/pnv.c
The thread interrupt management area (TIMA) is a set of pages mapped
in the Hypervisor and in the guest OS address space giving access to
the interrupt thread context registers for interrupt management, ACK,
EOI, CPPR, etc.
XIVE2 changes slightly the TIMA layout with extra bits for the new
feature
Add GEN1 config even if we don't use it yet in the core framework.
Signed-off-by: Cédric Le Goater
---
include/hw/ppc/xive2.h | 8
hw/intc/pnv_xive2.c| 13 +
hw/intc/xive2.c| 7 +++
3 files changed, 28 insertions(+)
diff --git a/include/hw/ppc/xive2.h b/in
These bits control the availability of interrupt features : StoreEOI,
PHB PQ_disable, PHB Address-Based Trigger and the overall XIVE
exploitation mode. These bits can be set at early boot time of the
system to activate/deactivate a feature for testing purposes. The
default value should be '1'.
The
When the Address-Based Interrupt Trigger mode is activated, the PHB
maps the interrupt source number into the interrupt command address.
The PHB directly triggers the IC ESB page of the interrupt number and
not the notify page of the IC anymore.
Signed-off-by: Cédric Le Goater
---
include/hw/pci
On 26/11/2021 06:18, Cédric Le Goater wrote:
Hello,
Curiously, I didn't get the v2 email.
I've received an e-mail from postmaster, saying that delivery to
recipients @kaod.org have been delayed, but I don't know why.
The XIVE interrupt controller on P10 can automatically save and
restore the state of the interrupt registers under the internal NVP
structure representing the VCPU. This saves a costly store/load in
guest entries and exits.
Signed-off-by: Cédric Le Goater
---
hw/intc/pnv_xive2_regs.h| 3 +
Only the CAM line updates done by the hypervisor are specific to
POWER10. Instead of duplicating the TM ops table, we handle these
commands locally under the PowerNV XIVE2 model.
Signed-off-by: Cédric Le Goater
---
include/hw/ppc/xive2.h | 8
hw/intc/pnv_xive2.c| 27 +++-
hw/in
Peter Maydell writes:
> The logic of gicv3_redist_update() is as follows:
> * it must be called in any code path that changes the state of
>(only) redistributor interrupts
> * if it finds a redistributor interrupt that is (now) higher
>priority than the previous highest-priority pendi
Segher Boessenkool writes:
> Hi!
>
> On Fri, Nov 26, 2021 at 09:34:44AM +0100, Cédric Le Goater wrote:
>> On 11/25/21 10:38, Segher Boessenkool wrote:
>> >On Thu, Nov 25, 2021 at 01:45:00AM +0100, BALATON Zoltan wrote:
>> >>As for guests, those running on the said PowerMac G4 should have support
Ben Widawsky writes:
> On 21-11-19 02:29:51, Shreyas Shah wrote:
>> Hi Ben
>>
>> Are you planning to add the CXL2.0 switch inside QEMU or already added in
>> one of the version?
>>
>
> From me, there are no plans for QEMU anything until/unless upstream thinks it
> will merge the existing p
Mark Cave-Ayland writes:
> On 26/11/2021 08:40, Cédric Le Goater wrote:
>
>> On 11/26/21 09:01, Mark Cave-Ayland wrote:
>>> On 24/11/2021 22:00, Fabiano Rosas wrote:
>>>
Fabiano Rosas writes:
> Hi all,
>
> We have this bug in QEMU which indicates that we haven't been able t
BALATON Zoltan writes:
> On Wed, 24 Nov 2021, Fabiano Rosas wrote:
>> Fabiano Rosas writes:
>>
>>> Hi all,
>>>
>>> We have this bug in QEMU which indicates that we haven't been able to
>>> run openbios on a 7450 cpu for quite a long time:
>>>
>>> https://gitlab.com/qemu-project/qemu/-/issues/86
On 11/26/21 13:13, Fabiano Rosas wrote:
Segher Boessenkool writes:
Hi!
On Fri, Nov 26, 2021 at 09:34:44AM +0100, Cédric Le Goater wrote:
On 11/25/21 10:38, Segher Boessenkool wrote:
On Thu, Nov 25, 2021 at 01:45:00AM +0100, BALATON Zoltan wrote:
As for guests, those running on the said Pow
Cédric Le Goater writes:
> On 11/26/21 13:13, Fabiano Rosas wrote:
>> Segher Boessenkool writes:
>>
>>> Hi!
>>>
>>> On Fri, Nov 26, 2021 at 09:34:44AM +0100, Cédric Le Goater wrote:
On 11/25/21 10:38, Segher Boessenkool wrote:
> On Thu, Nov 25, 2021 at 01:45:00AM +0100, BALATON Zoltan
The purpose of dbus_get_proxies to construct the proxies corresponding to the
IDs registered to dbus-vmstate.
Currenty, this function returns an error in case there is any failure
while instantiating proxy for "all" the names on dbus.
Ideally this function should error out only if it is not able
On Fri, Nov 26, 2021 at 5:40 PM Priyankar Jain
wrote:
> The purpose of dbus_get_proxies to construct the proxies corresponding to
> the
> IDs registered to dbus-vmstate.
>
> Currenty, this function returns an error in case there is any failure
> while instantiating proxy for "all" the names on db
Right. If we're doing this to say "I can boot a kernel with a 7450 cpu in QEMU"
but
the implementation is different from real hardware, then I'm not sure what the
real
value is. That effectively leaves option b) if someone is willing to do the
work, or
as you say to simply remove the code from
** Also affects: qemu
Importance: Undecided
Status: New
** No longer affects: qemu
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1952448
Title:
qemu 1:6.0+dfsg-2expubuntu2: Fail to build
The purpose of dbus_get_proxies to construct the proxies corresponding to the
IDs registered to dbus-vmstate.
Currenty, this function returns an error in case there is any failure
while instantiating proxy for "all" the names on dbus.
Ideally this function should error out only if it is not able
On Fri, 26 Nov 2021, Fabiano Rosas wrote:
BALATON Zoltan writes:
On Wed, 24 Nov 2021, Fabiano Rosas wrote:
Fabiano Rosas writes:
Hi all,
We have this bug in QEMU which indicates that we haven't been able to
run openbios on a 7450 cpu for quite a long time:
https://gitlab.com/qemu-project
On Fri, 26 Nov 2021, Cédric Le Goater wrote:
Right. If we're doing this to say "I can boot a kernel with a 7450 cpu in
QEMU" but
the implementation is different from real hardware, then I'm not sure what
the real
value is. That effectively leaves option b) if someone is willing to do
the work,
When doing live migration with multifd channels 8, 16 or larger number,
the guest hangs in the presence of the network errors such as missing TCP ACKs.
At sender's side:
The main thread is blocked on qemu_thread_join, migration_fd_cleanup
is called because one thread fails on qio_channel_write_all
When testing live migration with multifd channels (8, 16, or a bigger number)
and using qemu -incoming (without "defer"), if a network error occurs
(for example, triggering the kernel SYN flooding detection),
the migration fails and the guest hangs forever.
The test environment and the command lin
When creating the guest on destination with -incoming ip:port in QEMU command
line,
the source code that sets the backlog number as the same as multifd channels
doesn't
get called. So the number of backlog is always 1. It's very easy to cause live
migration
failure, so a bigger number is preferr
Simply set the respective bits and update the descriptor accordingly.
Signed-off-by: Noah Bergbauer
---
hw/input/hid.c | 2 ++
hw/usb/dev-hid.c | 6 +++---
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/hw/input/hid.c b/hw/input/hid.c
index 8aab0521f4..e7ecebdf8f 100644
--- a/h
On Fri, Nov 26, 2021 at 04:31:53PM +0100, Li Zhang wrote:
> When doing live migration with multifd channels 8, 16 or larger number,
> the guest hangs in the presence of the network errors such as missing TCP
> ACKs.
>
> At sender's side:
> The main thread is blocked on qemu_thread_join, migration
在 2021/11/26 15:03, Markus Armbruster 写道:
huang...@chinatelecom.cn writes:
From: Hyman Huang(黄勇)
Implement dirtyrate calculation periodically basing on
dirty-ring and throttle vCPU until it reachs the quota
dirty page rate given by user.
Introduce qmp commands set-dirty-limit/cancel-dirty
The device-crash-test script has been quite neglected in the past,
so that it bit-rot quite often. Let's add CI jobs that run this
script for at least some targets, so that this script does not
regress that easily anymore.
Signed-off-by: Thomas Huth
---
.gitlab-ci.d/buildtest.yml | 23 ++
Li Zhang wrote:
> When creating the guest on destination with -incoming ip:port in QEMU command
> line,
> the source code that sets the backlog number as the same as multifd channels
> doesn't
> get called. So the number of backlog is always 1. It's very easy to cause
> live migration
> failure
Li Zhang wrote:
> When doing live migration with multifd channels 8, 16 or larger number,
> the guest hangs in the presence of the network errors such as missing TCP
> ACKs.
>
> At sender's side:
> The main thread is blocked on qemu_thread_join, migration_fd_cleanup
> is called because one thread
(Marc: cc'd you on this one in case you're still using QEMU
to test KVM stuff with, in which case you might have run into
the bug this is fixing.)
It is valid for an OS to put virtual interrupt ID values into the
list registers ICH_LR which are greater than 1023. This
corresponds to (for example)
The GICv3/v4 pseudocode has a function IsSpecial() which returns true
if passed a "special" interrupt ID number (anything between 1020 and
1023 inclusive). We open-code this condition in a couple of places,
so abstract it out into a new function gicv3_intid_is_special().
Signed-off-by: Peter Mayd
It is valid for an OS to put virtual interrupt ID values into the
list registers ICH_LR which are greater than 1023. This
corresponds to (for example) KVM using the in-kernel emulated ITS to
give a (nested) guest an ITS. LPIs are delivered by the L1 kernel to
the L2 guest via the list registers i
On 11/26/21 4:49 PM, Daniel P. Berrangé wrote:
On Fri, Nov 26, 2021 at 04:31:53PM +0100, Li Zhang wrote:
When doing live migration with multifd channels 8, 16 or larger number,
the guest hangs in the presence of the network errors such as missing TCP ACKs.
At sender's side:
The main thread is
On 11/26/21 5:32 PM, Juan Quintela wrote:
Li Zhang wrote:
When creating the guest on destination with -incoming ip:port in QEMU command
line,
the source code that sets the backlog number as the same as multifd channels
doesn't
get called. So the number of backlog is always 1. It's very easy
On Fri, Nov 26, 2021 at 05:44:04PM +0100, Li Zhang wrote:
>
> On 11/26/21 4:49 PM, Daniel P. Berrangé wrote:
> > On Fri, Nov 26, 2021 at 04:31:53PM +0100, Li Zhang wrote:
> > > When doing live migration with multifd channels 8, 16 or larger number,
> > > the guest hangs in the presence of the netw
On Tue, 23 Nov 2021 at 14:00, Alexander Graf wrote:
>
>
> On 23.11.21 13:34, Peter Maydell wrote:
> > On Tue, 23 Nov 2021 at 12:29, Alexander Graf wrote:
> >> The virt machine has properties to enable MTE and Nested Virtualization
> >> support. However, its check to ensure the backing accel imple
On Thu, 25 Nov 2021 at 15:47, Peter Maydell wrote:
>
> On Wed, 24 Nov 2021 at 18:22, Shashi Mallela
> wrote:
> >
> > When Enabled bit is cleared in GITS_CTLR,ITS feature continues
> > to be enabled.This patch fixes the issue.
> >
> > Signed-off-by: Shashi Mallela
> > ---
> > hw/intc/arm_gicv3_
On 11/26/21 5:33 PM, Juan Quintela wrote:
Li Zhang wrote:
When doing live migration with multifd channels 8, 16 or larger number,
the guest hangs in the presence of the network errors such as missing TCP ACKs.
At sender's side:
The main thread is blocked on qemu_thread_join, migration_fd_cle
On 11/26/21 5:51 PM, Daniel P. Berrangé wrote:
On Fri, Nov 26, 2021 at 05:44:04PM +0100, Li Zhang wrote:
On 11/26/21 4:49 PM, Daniel P. Berrangé wrote:
On Fri, Nov 26, 2021 at 04:31:53PM +0100, Li Zhang wrote:
When doing live migration with multifd channels 8, 16 or larger number,
the guest
[ Adding Alfredo the thread ]
On 11/26/21 10:09, Cédric Le Goater wrote:
On 11/16/21 18:01, Frederic Barrat wrote:
The PHB v4 found on POWER9 doesn't request any LSI, so let's clear the
Interrupt Pin register in the config space so that the model matches
the hardware.
If we don't, then we inhe
On 26/11/2021 11.24, Christian Borntraeger wrote:
My borntrae...@de.ibm.com email is just a forwarder to the
linux.ibm.com address. Let us remove the extra hop to avoid
a potential source of errors.
While at it, add the relevant email addresses to mailmap.
Signed-off-by: Christian Borntraeger
On Fri, Nov 26, 2021 at 06:00:24PM +0100, Li Zhang wrote:
>
> On 11/26/21 5:51 PM, Daniel P. Berrangé wrote:
> > On Fri, Nov 26, 2021 at 05:44:04PM +0100, Li Zhang wrote:
> > > On 11/26/21 4:49 PM, Daniel P. Berrangé wrote:
> > > > On Fri, Nov 26, 2021 at 04:31:53PM +0100, Li Zhang wrote:
> > > >
On 11/26/21 6:13 PM, Daniel P. Berrangé wrote:
On Fri, Nov 26, 2021 at 06:00:24PM +0100, Li Zhang wrote:
On 11/26/21 5:51 PM, Daniel P. Berrangé wrote:
On Fri, Nov 26, 2021 at 05:44:04PM +0100, Li Zhang wrote:
On 11/26/21 4:49 PM, Daniel P. Berrangé wrote:
On Fri, Nov 26, 2021 at 04:31:53PM
On 11/26/21 02:11, David Gibson wrote:
On Thu, Nov 25, 2021 at 07:42:02PM -0300, Daniel Henrique Barboza wrote:
If one tries to use -machine powernv9,accel=kvm in a Power9 host, a
cryptic error will be shown:
qemu-system-ppc64: Register sync failed... If you're using kvm-hv.ko, only "-cpu
host
It's hardly 6.2 material
On Fri, 26 Nov 2021 11:12:55 +0530 (IST)
Ani Sinha wrote:
> On Thu, 25 Nov 2021, Michael S. Tsirkin wrote:
>
> > On Thu, Nov 25, 2021 at 05:36:29PM +0530, Ani Sinha wrote:
> > > x-native-hotplug property, when used in order to disable HPC bit on the
> > > PCIE
> > >
When updating the R bit of a PTE, the Hash64 MMU was using a wrong byte
offset, causing the first byte of the adjacent PTE to be corrupted.
This caused a panic when booting FreeBSD, using the Hash MMU.
Fixes: a2dd4e83e76b ("ppc/hash64: Rework R and C bit updates")
Signed-off-by: Leandro Lupori
--
Experience has shown that getting new functionality up-streamed can be
a somewhat painful process. Lets see if we can collect some of our
community knowledge into a blog post describing some best practices
for getting code accepted.
[AJB: obviously RFC for now, need material for the end]
Signed-o
On 11/26/21 17:27, Thomas Huth wrote:
> The device-crash-test script has been quite neglected in the past,
> so that it bit-rot quite often. Let's add CI jobs that run this
> script for at least some targets, so that this script does not
> regress that easily anymore.
>
> Signed-off-by: Thomas Hut
On Fri, Nov 26, 2021 at 04:39:40PM -0300, Leandro Lupori wrote:
> When updating the R bit of a PTE, the Hash64 MMU was using a wrong byte
> offset, causing the first byte of the adjacent PTE to be corrupted.
> This caused a panic when booting FreeBSD, using the Hash MMU.
>
> Fixes: a2dd4e83e76b ("
Is this series now acceptable for 'after 6.2'?
On 11/10/21 08:35, Stefan Berger wrote:
This series of patches adds missing ACPI device identification objects _STR
and _UID to TPM 1.2 and TPM 2 ACPI tables.
Stefan
v3:
- Dropped replacement of ACPI tables with empty files in 1/3.
- Redu
On Fri, Nov 26, 2021 at 06:51:38PM +0100, Cédric le Goater wrote:
> On 11/26/21 02:11, David Gibson wrote:
> > On Thu, Nov 25, 2021 at 07:42:02PM -0300, Daniel Henrique Barboza wrote:
> > > If one tries to use -machine powernv9,accel=kvm in a Power9 host, a
> > > cryptic error will be shown:
> > >
Introduce a qtest for the virtio-iommu device. The test
allowed to identify an endianess bug in the get_config().
We also remove the unneeded set_config() and fix the value
for domain_range.end field.
Best Regards
Eric
This series can be found at:
https://github.com/eauger/qemu/tree/virtio-iommu
The spec says "the driver must not write to device configuration
fields". So remove the set_config() callback which anyway did
not do anything.
Signed-off-by: Eric Auger
---
hw/virtio/trace-events | 1 -
hw/virtio/virtio-iommu.c | 14 --
2 files changed, 15 deletions(-)
diff --gi
Add the framework to test the virtio-iommu-pci device
and tests exercising the attach/detach, map/unmap API.
Signed-off-by: Eric Auger
Tested-by: Jean-Philippe Brucker
Reviewed-by: Jean-Philippe Brucker
---
v5 -> v6:
- changed the expected value for domain.end (32 -> MAX_UINT32)
---
tests/qt
Endianess is not properly handled when populating
the returned config. Use the cpu_to_le* primitives
for each separate field. Also, while at it, trace
the domain range start.
Signed-off-by: Eric Auger
Reported-by: Thomas Huth
---
hw/virtio/trace-events | 2 +-
hw/virtio/virtio-iommu.c | 22 +
in old times the domain range was defined by a domain_bits le32.
This was then converted into a domain_range struct. During the
upgrade the original value of '32' (bits) has been kept while
the end field now is the max value of the domain id (UINT32_MAX).
Fix that and also use UINT64_MAX for the in
1 - 100 of 101 matches
Mail list logo
