On 15.08.21 19:30, Philippe Mathieu-Daudé wrote:
+Peter/David
On 8/12/21 11:33 AM, Peter Maydell wrote:
Currently we implement the RAS register block within the NVIC device.
It isn't really very tightly coupled with the NVIC proper, so instead
move it out into a sysbus device of its own and hav
> On 2021/8/14 0:30, Pankaj Gupta wrote:
> >> In the real SMP hardware topology world, it's much more likely that
> >> we have high cores-per-socket counts and few sockets totally. While
> >> the current preference of sockets over cores in smp parsing results
> >> in a virtual cpu topology with low
> In the real SMP hardware topology world, it's much more likely that
> we have high cores-per-socket counts and few sockets totally. While
> the current preference of sockets over cores in smp parsing results
> in a virtual cpu topology with low cores-per-sockets counts and a
> large number of soc
Now that we have "acpi-pci-hotplug-with-bridge-support" PIIX4 PM property being
used for both q35 and i440fx machine types, it is better that we defined this
property string at a single place within a header file like other PIIX4
properties. We can then use this single definition at all the places
On Sat, 14 Aug 2021 at 07:10, Thomas Huth wrote:
>
> Hi Peter,
>
> in case we're going to have an -rc4, here's a pull request that contains
> the fixes for getting the gitlab-CI green again. I also added some doc
> updates since they should be completely riskless. But if we won't have an
> rc4 du
On Sun, 15 Aug 2021 at 21:10, Richard Henderson
wrote:
>
> On 8/13/21 3:18 AM, Peter Maydell wrote:
> > +void force_sig_fault(int sig, int code, abi_ulong addr)
>
> Better as abi_ptr?
I followed the same type used for 'addr' in the target_siginfo_t
struct definition.
-- PMM
On Sun, 15 Aug 2021 at 17:32, Philippe Mathieu-Daudé wrote:
>
> On 8/12/21 11:33 AM, Peter Maydell wrote:
> > It is quite common for a clock tree to involve possibly programmable
> > clock multipliers or dividers, where the frequency of a clock is for
> > instance divided by 8 to produce a slower
On Mon, 16 Aug 2021 at 06:41, David Gibson wrote:
>
> Indeed. Revised version below. I'll only attempt to push this to 6.1
> if we're going to rc4 for other reasons though.
We are doing an rc4, but I don't think we really need this in 6.1,
given that the original leak only happens on a very rar
On 2021/8/16 16:02, Pankaj Gupta wrote:
In the real SMP hardware topology world, it's much more likely that
we have high cores-per-socket counts and few sockets totally. While
the current preference of sockets over cores in smp parsing results
in a virtual cpu topology with low cores-per-sockets
On Sun, 15 Aug 2021 at 18:30, Philippe Mathieu-Daudé wrote:
>
> +Peter/David
>
> On 8/12/21 11:33 AM, Peter Maydell wrote:
> > Currently we implement the RAS register block within the NVIC device.
> > It isn't really very tightly coupled with the NVIC proper, so instead
> > move it out into a sysb
Hi Jianxian,
On 8/16/21 8:46 AM, Wen, Jianxian wrote:
> L330 needs a memory region which can connect with SMMU IOMMU region to
> support SMMU translate.
>
> Signed-off-by: Jianxian Wen
> ---
> Changes v1 -> v2 (after review of Peter Maydell):
> - Use the dma_memory_read/dma_memory_write functi
On 8/16/21 10:32 AM, Ani Sinha wrote:
> Now that we have "acpi-pci-hotplug-with-bridge-support" PIIX4 PM property
> being
> used for both q35 and i440fx machine types, it is better that we defined this
> property string at a single place within a header file like other PIIX4
> properties. We can t
On 8/16/21 11:05 AM, Peter Maydell wrote:
> On Sun, 15 Aug 2021 at 17:32, Philippe Mathieu-Daudé wrote:
>>
>> On 8/12/21 11:33 AM, Peter Maydell wrote:
>>> It is quite common for a clock tree to involve possibly programmable
>>> clock multipliers or dividers, where the frequency of a clock is for
On Mon, 16 Aug 2021 at 10:32, Philippe Mathieu-Daudé wrote:
>
> On 8/16/21 11:05 AM, Peter Maydell wrote:
> > On Sun, 15 Aug 2021 at 17:32, Philippe Mathieu-Daudé
> > wrote:
> >> I only wonder if we shouldn't check clock_is_enabled() here.
> >> Maybe not assert, but at least report a GUEST_ERROR
Let's sense support and use it for preallocation. MADV_POPULATE_WRITE
does not require a SIGBUS handler, doesn't actually touch page content,
and avoids context switches; it is, therefore, faster and easier to handle
than our current approach.
While MADV_POPULATE_WRITE is, in general, faster than
#1 is a preparation for improved error reporting, #2 adds support for
MADV_POPULATE_WRITE, #3 cleans up the code to avoid global variables and
prepare for concurrency, #4 and #5 optimize thread handling, #6 makes
os_mem_prealloc() safe to be called from multiple threads concurrently and
#7 makes th
Let's prepare touch_all_pages() for returning differing errors. Return
an error from the thread and report the last processed error.
Translate SIGBUS to -EFAULT, as a SIGBUS can mean all different kind of
things (memory error, read error, out of memory). When allocating memory
fails via the curren
Let's limit the number of threads to something sane, especially that
- We don't have more threads than the number of pages we have
- We don't have threads that initialize small (< 64 MiB) memory
Reviewed-by: Pankaj Gupta
Reviewed-by: Dr. David Alan Gilbert
Signed-off-by: David Hildenbrand
---
Let's minimize the number of global variables to prepare for
os_mem_prealloc() getting called concurrently and make the code a bit
easier to read.
The only consumer that really needs a global variable is the sigbus
handler, which will require protection via a mutex in the future either way
as we c
Let's simplify the case when we only want a single thread and don't have
to mess with signal handlers.
Reviewed-by: Pankaj Gupta
Signed-off-by: David Hildenbrand
---
util/oslib-posix.c | 8
1 file changed, 8 insertions(+)
diff --git a/util/oslib-posix.c b/util/oslib-posix.c
index 67c0
Add a mutex to protect the SIGBUS case, as we cannot mess concurrently
with the sigbus handler and we have to manage the global variable
sigbus_memset_context. The MADV_POPULATE_WRITE path can run
concurrently.
Note that page_mutex and page_cond are shared between concurrent
invocations, which sho
Temporarily modifying the SIGBUS handler is really nasty, as we might be
unlucky and receive an MCE SIGBUS while having our handler registered.
Unfortunately, there is no way around messing with SIGBUS when
MADV_POPULATE_WRITE is not applicable or not around.
Let's forward SIGBUS that don't belong
On 8/16/21 11:36 AM, Peter Maydell wrote:
> On Mon, 16 Aug 2021 at 10:32, Philippe Mathieu-Daudé wrote:
>>
>> On 8/16/21 11:05 AM, Peter Maydell wrote:
>>> On Sun, 15 Aug 2021 at 17:32, Philippe Mathieu-Daudé
>>> wrote:
I only wonder if we shouldn't check clock_is_enabled() here.
Maybe
On 8/6/21 5:19 AM, Jingqi Liu wrote:
Maybe prepend with:
Since commits aa57020774b ("numa: move numa global variable
nb_numa_nodes into MachineState") and 7e721e7b10e ("numa: move
numa global variable numa_info into MachineState"), we can ...
> We can get NUMA information completely from Machine
On 8/16/21 7:41 AM, David Gibson wrote:
> On Sun, Aug 15, 2021 at 07:59:15PM -0700, Guenter Roeck wrote:
>> IBM EMAC Ethernet controllers are not emulated by qemu. If they are
>> enabled in devicetree files, they are instantiated in Linux but
>> obviously won't work. Disable associated devicetree n
On Mon, 16 Aug 2021, David Gibson wrote:
On Sun, Aug 15, 2021 at 07:59:15PM -0700, Guenter Roeck wrote:
IBM EMAC Ethernet controllers are not emulated by qemu. If they are
enabled in devicetree files, they are instantiated in Linux but
obviously won't work. Disable associated devicetree nodes to
On 210816 1001, Peter Maydell wrote:
> On Sat, 14 Aug 2021 at 07:10, Thomas Huth wrote:
> >
> > Hi Peter,
> >
> > in case we're going to have an -rc4, here's a pull request that contains
> > the fixes for getting the gitlab-CI green again. I also added some doc
> > updates since they should be co
PL330 needs a memory region which can connect with SMMU IOMMU region to support
SMMU translate.
Signed-off-by: Jianxian Wen
---
Changes v1 -> v2 (after review of Peter Maydell):
- Use the dma_memory_read/dma_memory_write functions, update function
AddressSpace* parameter.
Changes v2 -> v3 (aft
On Mon, 16 Aug 2021 at 06:46, David Gibson wrote:
>
> On Sun, Aug 15, 2021 at 07:59:15PM -0700, Guenter Roeck wrote:
> > IBM EMAC Ethernet controllers are not emulated by qemu. If they are
> > enabled in devicetree files, they are instantiated in Linux but
> > obviously won't work. Disable associa
On 8/16/21 12:24 PM, Wen, Jianxian wrote:
> PL330 needs a memory region which can connect with SMMU IOMMU region to
> support SMMU translate.
>
> Signed-off-by: Jianxian Wen
> ---
> Changes v1 -> v2 (after review of Peter Maydell):
> - Use the dma_memory_read/dma_memory_write functions, update
On Thu, Aug 12 2021, Daniel P. Berrangé wrote:
> Currently pushes to user forks run the same set of build / test jobs as
> pushes to the main repo. This results in creation of 120+ individual
> jobs. While it is useful for subsystem maintainers, and even regular
> contributors to be able to run t
On Mon, 16 Aug 2021 at 11:41, Philippe Mathieu-Daudé wrote:
> So when multiple controllers are created, this makes the 'info mtree'
> output longer, all AS named similarly:
I think this is a problem with 'info mtree' to some extent -- it
was designed on the assumption that there's really only on
On 8/16/21 12:26 PM, Peter Maydell wrote:
> On Mon, 16 Aug 2021 at 06:46, David Gibson
> wrote:
>>
>> On Sun, Aug 15, 2021 at 07:59:15PM -0700, Guenter Roeck wrote:
>>> IBM EMAC Ethernet controllers are not emulated by qemu. If they are
>>> enabled in devicetree files, they are instantiated in Li
On 8/12/21 8:04 PM, Daniel P. Berrangé wrote:
> This splits the CI docs into one file talking about job setup and usage
> and another file describing provisioning of custom runners.
Thanks.
Reviewed-by: Philippe Mathieu-Daudé
> Signed-off-by: Daniel P. Berrangé
> ---
> docs/devel/ci-jobs.rst
On Mon, Aug 16, 2021 at 12:44:02PM +0200, Cornelia Huck wrote:
> On Thu, Aug 12 2021, Daniel P. Berrangé wrote:
>
> > Currently pushes to user forks run the same set of build / test jobs as
> > pushes to the main repo. This results in creation of 120+ individual
> > jobs. While it is useful for s
On Mon, Aug 16, 2021 at 06:22:46AM -0400, Alexander Bulekov wrote:
> On 210816 1001, Peter Maydell wrote:
> > On Sat, 14 Aug 2021 at 07:10, Thomas Huth wrote:
> > >
> > > Hi Peter,
> > >
> > > in case we're going to have an -rc4, here's a pull request that contains
> > > the fixes for getting the
On 8/16/21 1:03 PM, Daniel P. Berrangé wrote:
> On Mon, Aug 16, 2021 at 12:44:02PM +0200, Cornelia Huck wrote:
>> On Thu, Aug 12 2021, Daniel P. Berrangé wrote:
>>> The minimal job set covers:
>>>
>>> * Fedora, CentOS, Ubuntu & Debian system emulator builds
>>> to cover all arch targets.
>>>
On 210816 1211, Daniel P. Berrangé wrote:
> On Mon, Aug 16, 2021 at 06:22:46AM -0400, Alexander Bulekov wrote:
> > On 210816 1001, Peter Maydell wrote:
> > > On Sat, 14 Aug 2021 at 07:10, Thomas Huth wrote:
> > > >
> > > > Hi Peter,
> > > >
> > > > in case we're going to have an -rc4, here's a pu
On Mon, Aug 16, 2021 at 01:20:14PM +0200, Philippe Mathieu-Daudé wrote:
> On 8/16/21 1:03 PM, Daniel P. Berrangé wrote:
> >> (c) a subsystem maintainer is preparing a pull request
> >>
> >> Ideally, that should run the 'gating' set, to eliminate needless bounces
> >> of the pull request; plus some
On 8/16/21 1:30 PM, Alexander Bulekov wrote:
> On 210816 1211, Daniel P. Berrangé wrote:
>> On Mon, Aug 16, 2021 at 06:22:46AM -0400, Alexander Bulekov wrote:
>>> https://gitlab.com/qemu-project/qemu/-/jobs/1505950978
>>> Looks like build-oss-fuzz is still timing out, even without the issue
>>> in
On Mon, Aug 16, 2021 at 07:30:59AM -0400, Alexander Bulekov wrote:
> On 210816 1211, Daniel P. Berrangé wrote:
> > On Mon, Aug 16, 2021 at 06:22:46AM -0400, Alexander Bulekov wrote:
> > > On 210816 1001, Peter Maydell wrote:
> > > > On Sat, 14 Aug 2021 at 07:10, Thomas Huth wrote:
> > > > >
> > >
On 8/16/21 1:35 PM, Daniel P. Berrangé wrote:
> On Mon, Aug 16, 2021 at 01:20:14PM +0200, Philippe Mathieu-Daudé wrote:
>> On 8/16/21 1:03 PM, Daniel P. Berrangé wrote:
(c) a subsystem maintainer is preparing a pull request
Ideally, that should run the 'gating' set, to eliminate need
On Mon, Aug 16 2021, Daniel P. Berrangé wrote:
> On Mon, Aug 16, 2021 at 12:44:02PM +0200, Cornelia Huck wrote:
>> On Thu, Aug 12 2021, Daniel P. Berrangé wrote:
>>
>> > Currently pushes to user forks run the same set of build / test jobs as
>> > pushes to the main repo. This results in creatio
On Mon, Aug 16, 2021 at 09:53:27AM +0300, Denis Plotnikov wrote:
>
> On 12.08.2021 11:04, Denis Plotnikov wrote:
> >
> > On 09.08.2021 13:48, Denis Plotnikov wrote:
> > > On vhost-user-blk migration, qemu normally sends a number of commands
> > > to enable logging if VHOST_USER_PROTOCOL_F_LOG_SHM
On Mon, 16 Aug 2021, Philippe Mathieu-Daudé wrote:
On 8/16/21 12:26 PM, Peter Maydell wrote:
On Mon, 16 Aug 2021 at 06:46, David Gibson wrote:
On Sun, Aug 15, 2021 at 07:59:15PM -0700, Guenter Roeck wrote:
IBM EMAC Ethernet controllers are not emulated by qemu. If they are
enabled in devicet
Jason,
Can you please review the series?
Thanks,
Yuri
On Thu, Jul 22, 2021 at 11:38 AM Andrew Melnichenko wrote:
>
> ping
>
> On Tue, Jul 13, 2021 at 6:38 PM Andrew Melnychenko wrote:
>>
>> Libvirt usually launches qemu with strict permissions.
>> To enable eBPF RSS steering, qemu-ebpf-rss-help
On 210816 1340, Philippe Mathieu-Daudé wrote:
> On 8/16/21 1:30 PM, Alexander Bulekov wrote:
> > On 210816 1211, Daniel P. Berrangé wrote:
> >> On Mon, Aug 16, 2021 at 06:22:46AM -0400, Alexander Bulekov wrote:
>
> >>> https://gitlab.com/qemu-project/qemu/-/jobs/1505950978
> >>> Looks like build-o
On Mon, Aug 16, 2021 at 01:47:08PM +0200, Cornelia Huck wrote:
> On Mon, Aug 16 2021, Daniel P. Berrangé wrote:
>
> > On Mon, Aug 16, 2021 at 12:44:02PM +0200, Cornelia Huck wrote:
> >> On Thu, Aug 12 2021, Daniel P. Berrangé wrote:
> >> > The minimal job set covers:
> >> >
> >> > * Fedora, Ce
On 13/08/2021 06:17, Peter Maydell wrote:
[E-MAIL EXTERNO] Não clique em links ou abra anexos, a menos que você possa
confirmar o remetente e saber que o conteúdo é seguro. Em caso de e-mail
suspeito entre imediatamente em contato com o DTI.
On Thu, 12 Aug 2021 at 21:07, Richard Henderson
wro
Hi All,
I tested the RC6 of kernel 5.14 today and unfortunately the issue still
exists. We have figured out that only P5040 SoCs are affected. [1]
P5020 SoCs display the correct values.
Please check the CPU changes in the PowerPC updates 5.13-1 and 5.13-2.
Thanks,
Christian
[1] https://forum.
Hello Thomas and Gerd,
Thank you for reviewing it. Sending a v2 soon.
Thank you very much!
On 16/08/2021 02:05, Gerd Hoffmann wrote:
Hi,
+if (qemu_ram_block_by_name("vga.vram")) {
+error_report("vga.vram is already registered, ignoring this device");
+return;
+}
I
If users try to add an isa-vga device that was already registered,
still in command line, qemu will crash:
$ qemu-system-mips64el -M pica61 -device isa-vga
RAMBlock "vga.vram" already registered, abort!
Aborted (core dumped)
That particular board registers the device automaticaly, so it's
not obv
On Fri, Aug 13, 2021 at 02:51:53PM +, Jag Raman wrote:
> Thanks for the information about the Blocking and Non-Blocking mode.
>
> I’d like to explain why we are using a separate thread presently and
> check with you if it’s possible to poll on multiple vfu contexts at the
> same time (similar
On 8/16/21 2:36 PM, Jose R. Ziviani wrote:
> If users try to add an isa-vga device that was already registered,
> still in command line, qemu will crash:
>
> $ qemu-system-mips64el -M pica61 -device isa-vga
> RAMBlock "vga.vram" already registered, abort!
> Aborted (core dumped)
>
> That particul
On Mon, Aug 16 2021, Daniel P. Berrangé wrote:
> On Mon, Aug 16, 2021 at 01:47:08PM +0200, Cornelia Huck wrote:
>> On Mon, Aug 16 2021, Daniel P. Berrangé wrote:
>>
>> > When I'm working on changing gitlab CI rules, then I burn loads of
>> > minutes which is especially troubling - limited CI mi
On Mon, Aug 16, 2021 at 03:19:31PM +0200, Cornelia Huck wrote:
> On Mon, Aug 16 2021, Daniel P. Berrangé wrote:
>
> > On Mon, Aug 16, 2021 at 01:47:08PM +0200, Cornelia Huck wrote:
> >> On Mon, Aug 16 2021, Daniel P. Berrangé wrote:
> >>
> >> > When I'm working on changing gitlab CI rules, then
From: Dov Murik
Add a notion of mirror vcpus to CpuTopology, which will allow to
designate a few vcpus (normally 1) for running the guest
migration handler (MH).
Example usage for starting a 4-vcpu guest, of which 1 vcpu is marked as
mirror vcpu.
qemu-system-x86_64 -smp 4,mirrorvcpus=1 ...
From: Dov Murik
Mark the last mirror_vcpus vcpus in the machine state's possible_cpus as
mirror.
Signed-off-by: Dov Murik
Co-developed-by: Ashish Kalra
Signed-off-by: Ashish Kalra
---
hw/i386/x86.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/hw/i386/x86.c b/hw/i386/x86.c
index 0044
From: Dov Murik
The mirror field indicates mirror VCPUs. This will allow QEMU to act
differently on mirror VCPUs.
Signed-off-by: Dov Murik
Co-developed-by: Ashish Kalra
Signed-off-by: Ashish Kalra
---
hw/core/cpu-common.c | 1 +
include/hw/core/cpu.h | 3 +++
2 files changed, 4 insertions(
From: Dov Murik
The mirror_vcpu flag indicates whether a vcpu is a mirror.
Signed-off-by: Dov Murik
Co-developed-by: Ashish Kalra
Signed-off-by: Ashish Kalra
---
include/hw/boards.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/hw/boards.h b/include/hw/boards.h
index b0e59909
From: Ashish Kalra
Add VM ioctl and enable cap support for Mirror VM's and
a new VM file descriptor for Mirror VM's in KVMState.
The VCPU ioctl interface for Mirror VM works as it is,
as it uses a CPUState and VCPU file descriptor allocated
and setup for mirror vcpus.
Signed-off-by: Ashish Kalr
From: Tobin Feldman-Fitzthum
By excluding mirror vcpus from the ACPI tables, we hide them from the
guest OS.
Signed-off-by: Tobin Feldman-Fitzthum
Signed-off-by: Dov Murik
Co-developed-by: Ashish Kalra
Signed-off-by: Ashish Kalra
---
hw/acpi/cpu.c | 10 ++
hw/i386/acpi-build
From: Ashish Kalra
Mirror VM does not support any interrupt controller and this
requires disabling the in-kernel APIC support on mirror vcpu's.
Signed-off-by: Ashish Kalra
---
hw/i386/kvm/apic.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/hw/i386/kvm/apic.c b/hw/i386/k
From: Dov Murik
On x86 machines, when initializing the CPUState structs, set the
mirror_vcpu flag to true for mirror vcpus.
Signed-off-by: Dov Murik
Co-developed-by: Ashish Kalra
Signed-off-by: Ashish Kalra
---
hw/i386/x86.c | 9 +++--
include/hw/i386/x86.h | 3 ++-
2 files chang
From: Ashish Kalra
Create the Mirror VM and share the primary VM's encryption context
with it using the KVM_CAP_VM_COPY_ENC_CONTEXT_FROM capability.
Signed-off-by: Ashish Kalra
---
accel/kvm/kvm-all.c | 30 ++
1 file changed, 30 insertions(+)
diff --git a/accel/kvm
From: Ashish Kalra
Add a new kvm_mirror_vcpu_thread_fn() which is qemu's mirror vcpu
thread and the corresponding kvm_init_mirror_vcpu() which creates
the vcpu's for the mirror VM and a different KVM run loop
kvm_mirror_cpu_exec() which differs from the main KVM run loop as
it currently mainly ha
From: Ashish Kalra
This is an RFC series for Mirror VM support that are
essentially secondary VMs sharing the encryption context
(ASID) with a primary VM. The patch-set creates a new
VM and shares the primary VM's encryption context
with it using the KVM_CAP_VM_COPY_ENC_CONTEXT_FROM capability
From: Ashish Kalra
Skip mirror vcpus's for vcpu pause, resume and synchronization
operations.
Signed-off-by: Ashish Kalra
---
softmmu/cpus.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/softmmu/cpus.c b/softmmu/cpus.c
index 071085f840..caed382669 100644
---
From: Ashish Kalra
OVMF expects both fw_cfg and the modern CPU hotplug interface to
return the same boot CPU count. We reduce the fw_cfg boot cpu count
with number of mirror vcpus's. This fails the OVMF sanity check
as fw_cfg boot cpu count and modern CPU hotplug interface boot
count don't match,
From: Ashish Kalra
Signed-off-by: Ashish Kalra
---
hw/i386/pc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 3856a47390..2c353becb7 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -962,6 +962,9 @@ void pc_memory_init(PCMachineState *pcms,
Hello Philippe!
On 16/08/2021 10:01, Philippe Mathieu-Daudé wrote:
On 8/16/21 2:36 PM, Jose R. Ziviani wrote:
If users try to add an isa-vga device that was already registered,
still in command line, qemu will crash:
$ qemu-system-mips64el -M pica61 -device isa-vga
RAMBlock "vga.vram" already
If users try to add an isa-vga device that was already registered,
still in command line, qemu will crash:
$ qemu-system-mips64el -M pica61 -device isa-vga
RAMBlock "vga.vram" already registered, abort!
Aborted (core dumped)
That particular board registers the device automaticaly, so it's
not obv
The SoC realize can fail for legitimate reasons, because it propagates
errors up from CPU realize, which in turn can be provoked by user
error in setting commandline options. Use error_fatal so we report
the error message to the user and exit, rather than asserting
via error_abort.
Signed-off-by:
KVM can't support more than one address space per CPU; if you try to
create more than one then cpu_address_space_init() will assert.
The Arm CPU realize function wasn't checking for the combination of
KVM and various features that might need multiple address spaces, so
it would just blunder on and
KVM cannot support multiple address spaces per CPU; if you try to
create more than one then cpu_address_space_init() will assert.
In the Arm CPU realize function, detect the configurations which
would cause us to need more than one AS, and cleanly fail the
realize rather than blundering on into th
On 8/16/21 3:26 AM, Peter Maydell wrote:
On Mon, 16 Aug 2021 at 06:46, David Gibson wrote:
On Sun, Aug 15, 2021 at 07:59:15PM -0700, Guenter Roeck wrote:
IBM EMAC Ethernet controllers are not emulated by qemu. If they are
enabled in devicetree files, they are instantiated in Linux but
obvious
Now that the CPU realize function will fail cleanly if we ask for EL3
when KVM is enabled, we don't need to check for errors explicitly in
the virt board code. The reported message is slightly different;
it is now:
qemu-system-aarch64: Cannot enable KVM when guest CPU has EL3 enabled
instead of:
On 8/16/21 3:25 PM, Ashish Kalra wrote:
> From: Ashish Kalra
>
> This is an RFC series for Mirror VM support that are
> essentially secondary VMs sharing the encryption context
> (ASID) with a primary VM. The patch-set creates a new
> VM and shares the primary VM's encryption context
> with
On Mon, 16 Aug 2021 at 15:00, Guenter Roeck wrote:
> The controllers are instantiated (it looks like the Linux driver doesn't
> really check during probe if the hardware is present but relies on DT),
> but when trying to access them there is a PHY error. If a different Ethernet
> device is explici
> On Aug 16, 2021, at 8:52 AM, John Levon wrote:
>
> On Fri, Aug 13, 2021 at 02:51:53PM +, Jag Raman wrote:
>
>> Thanks for the information about the Blocking and Non-Blocking mode.
>>
>> I’d like to explain why we are using a separate thread presently and
>> check with you if it’s possib
On 8/16/21 7:03 AM, Peter Maydell wrote:
On Mon, 16 Aug 2021 at 15:00, Guenter Roeck wrote:
The controllers are instantiated (it looks like the Linux driver doesn't
really check during probe if the hardware is present but relies on DT),
but when trying to access them there is a PHY error. If a
On 16/08/21 15:25, Ashish Kalra wrote:
From: Ashish Kalra
This is an RFC series for Mirror VM support that are
essentially secondary VMs sharing the encryption context
(ASID) with a primary VM. The patch-set creates a new
VM and shares the primary VM's encryption context
with it using the KVM_CA
On Mon, 16 Aug 2021 at 15:11, Guenter Roeck wrote:
>
> On 8/16/21 7:03 AM, Peter Maydell wrote:
> > On Mon, 16 Aug 2021 at 15:00, Guenter Roeck wrote:
> >> The controllers are instantiated (it looks like the Linux driver doesn't
> >> really check during probe if the hardware is present but relies
On Mon, Aug 16, 2021 at 04:15:46PM +0200, Paolo Bonzini wrote:
> On 16/08/21 15:25, Ashish Kalra wrote:
> > From: Ashish Kalra
> >
> > This is an RFC series for Mirror VM support that are
> > essentially secondary VMs sharing the encryption context
> > (ASID) with a primary VM. The patch-set creat
Since commit 1c2adb958fc0 ("tcg: Initialize cpu_env generically"),
these tcg_global_reg_new_ macros are not used anywhere.
Signed-off-by: Bin Meng
---
include/tcg/tcg-op.h| 2 --
target/hppa/translate.c | 3 ---
2 files changed, 5 deletions(-)
diff --git a/include/tcg/tcg-op.h b/include/tc
Hello Paolo,
On Mon, Aug 16, 2021 at 04:15:46PM +0200, Paolo Bonzini wrote:
> On 16/08/21 15:25, Ashish Kalra wrote:
> > From: Ashish Kalra
> >
> > This is an RFC series for Mirror VM support that are
> > essentially secondary VMs sharing the encryption context
> > (ASID) with a primary VM. The p
From: Valeriy Vdovin
Introducing new QMP command 'query-x86-cpuid'. This command can be used to
get virtualized cpu model info generated by QEMU during VM initialization in
the form of cpuid representation.
Diving into more details about virtual CPU generation: QEMU first parses '-cpu'
command l
On 8/16/21 7:19 AM, Peter Maydell wrote:
On Mon, 16 Aug 2021 at 15:11, Guenter Roeck wrote:
On 8/16/21 7:03 AM, Peter Maydell wrote:
On Mon, 16 Aug 2021 at 15:00, Guenter Roeck wrote:
The controllers are instantiated (it looks like the Linux driver doesn't
really check during probe if the h
On 16/08/21 16:44, Ashish Kalra wrote:
I think that once the mirror VM starts booting and running the UEFI
code, it might be only during the PEI or DXE phase where it will
start actually running the MH code, so mirror VM probably still need
to handles KVM_EXIT_IO when SEC phase does I/O, I can se
We dont't need a flag to know if the primary device must be hidden, we
can rely on the machine state:
Device is hidden if the machine is in prelaunch state (src) or
in inmigrate state with migration status set to none (dst).
We don't need to check the flag in virtio_net_handle_migration_primary()
b
This allows an error to be reported to the caller of qdev_device_add()
Signed-off-by: Laurent Vivier
---
include/hw/qdev-core.h | 6 --
hw/core/qdev.c | 4 ++--
hw/net/virtio-net.c| 2 +-
softmmu/qdev-monitor.c | 4 ++--
4 files changed, 9 insertions(+), 7 deletions(-)
diff --gi
This series moves the code used by virtio-net failover from the
virtio-net device to the PCI subsystem.
Doing that, we can use failover with a regular QEMU PCI device
(we can add the function call to unregister the ROM vmstate) and we
can also use this code to unplug a PCI card before migration
an
Commit f3a850565693 ("qdev/qbus: add hidden device support") has
introduced a generic way to hide a device but it has modified
qdev_device_add() to check a specific option of the failover device,
"failover_pair_id", before calling the generic mechanism.
It's not needed (and not generic) to do that
failover allows a VFIO device to be unplugged on migration to switch
to the standby device, a virtio-net device.
Failover relies on PCI ability to hotplug/unplug a card (the VFIO
one) but all the code is implemented in virtio-net device that
is not a PCI device (even not in virtio-net-pci that is
The intend of failover is to allow a VM with a VFIO networking card to
be migrated without disrupting the network operation by switching
to a virtio-net device during the migration.
This simple change allows a simulated device like e1000e to be tested
rather than a vfio device, even if it's useles
We have moved all the functions needed by failover to unplug a card to the
PCI subsystem.
A side effect of this change is we can implement automatic hotplug/unplug
of any PCI card during migration without using a failover virtio-net card.
For that, we need to introduce a new PCI device property,
"
On 16/08/21 16:23, Daniel P. Berrangé wrote:
snip
With this implementation, the number of mirror vCPUs does not even have to
be indicated on the command line. The VM and its vCPUs can simply be
created when migration starts. In the SEV-ES case, the guest can even
provide the VMSA that starts
On Mon, Aug 16 at 10:44 AM Ashish Kalra wrote:
> I am not sure if we really don't need QEMU's MMIO logic, I think that
once the>
> mirror VM starts booting and running the UEFI code, it might be only
during
> the PEI or DXE phase where it will start actually running the MH code,
> so mirror VM
On 8/16/21 4:35 PM, Bin Meng wrote:
> Since commit 1c2adb958fc0 ("tcg: Initialize cpu_env generically"),
> these tcg_global_reg_new_ macros are not used anywhere.
>
> Signed-off-by: Bin Meng
> ---
>
> include/tcg/tcg-op.h| 2 --
> target/hppa/translate.c | 3 ---
> 2 files changed, 5 deleti
On 8/16/21 3:58 PM, Peter Maydell wrote:
> The SoC realize can fail for legitimate reasons, because it propagates
> errors up from CPU realize, which in turn can be provoked by user
> error in setting commandline options. Use error_fatal so we report
> the error message to the user and exit, rather
1 - 100 of 218 matches
Mail list logo
