On Thu, Mar 12, 2020 at 12:14:20PM +1100, David Gibson wrote:
> On Wed, Mar 11, 2020 at 03:11:16AM -0400, Michael S. Tsirkin wrote:
> > On Wed, Mar 11, 2020 at 11:58:57AM +1100, David Gibson wrote:
> > > Note that several things that I believe are now in the PCIe spec, but
> > > really derive more
On Thu, Mar 12, 2020 at 12:10:49PM +1100, David Gibson wrote:
> On Wed, Mar 11, 2020 at 03:33:59AM -0400, Michael S. Tsirkin wrote:
> > On Wed, Mar 11, 2020 at 12:12:47PM +1100, David Gibson wrote:
> > > I am wondering if we have to introduce an "svm=on" flag anyway. It's
> > > pretty ugly, since
On Wed, Mar 11, 2020 at 07:23:42PM -0400, Eduardo Habkost wrote:
> The CONFIG_LINUX check at the top of mmap-alloc.c never worked
> because it was done before including osdep.h.
>
> This means MAP_SYNC and MAP_SHARED_VALIDATE would always be set
> to 0 at the beginning of the file. Luckily, this
On Wed, Mar 11, 2020 at 07:23:41PM -0400, Eduardo Habkost wrote:
> glibc and Linux-provided headers are known to generate macro
> redefinition warnings when used together. For example:
> and duplicate some macro definitions.
>
> We normally never see those warnings because GCC suppresses
> warn
On Thu, Mar 12, 2020 at 03:31:49AM +0200, Liran Alon wrote:
>
> On 11/03/2020 22:24, Michael S. Tsirkin wrote:
> > Notice the process as documented in ./tests/qtest/bios-tables-test.c
> >
> Thanks for explicitly pointing me to that process.
>
> I have followed the process described there (Both s
On Thu, Mar 12, 2020 at 01:20:02AM +0200, Liran Alon wrote:
>
> On 11/03/2020 22:36, Michael S. Tsirkin wrote:
> > Thanks for the patch! Some questions/comments:
> >
> > On Wed, Mar 11, 2020 at 07:08:26PM +0200, Liran Alon wrote:
> > > From: Elad Gabay
> > >
> > > Microsoft introduced this ACPI
On Mar 11 15:54, Andrzej Jakowski wrote:
> On 3/11/20 2:20 AM, Stefan Hajnoczi wrote:
> > Please try:
> >
> > $ git grep pmem
> >
> > backends/hostmem-file.c is the backend that can be used and the
> > pmem_persist() API can be used to flush writes.
>
> I've reworked this patch into hostmem-fi
Peter Maydell writes:
> On Wed, 11 Mar 2020 at 14:53, Markus Armbruster wrote:
>> This appears to lose plain text, PDF and info output. Any chance to get
>> plain text back?
>
> This is deliberate. Consensus when we decided on the docs
> transition plan was that plain text was not a useful outp
11.03.2020 20:03, John Snow wrote:
On 3/11/20 9:58 AM, Vladimir Sementsov-Ogievskiy wrote:
11.03.2020 12:55, Max Reitz wrote:
On 11.03.20 07:17, Vladimir Sementsov-Ogievskiy wrote:
10.03.2020 20:17, Max Reitz wrote:
On 06.03.20 08:45, Vladimir Sementsov-Ogievskiy wrote:
26.02.2020 16:13, M
Alex Williamson writes:
> On Wed, 11 Mar 2020 08:04:28 +0100
> Markus Armbruster wrote:
>
>> Alex Williamson writes:
>>
>> > On Mon, 24 Feb 2020 14:42:17 +0800
>> > "Longpeng(Mike)" wrote:
>> >
>> >> From: Longpeng
>> >>
>> >> vfio_pci_load_rom() maybe failed and then the vdev->rom is NUL
When I try run master qemu I am hitting a divide by zero error. It seems
to be coming from util/oslib-posix.c in touch_all_pages(). see line 477:
numpages_per_thread = numpages / memset_num_threads;
Poking around the crash dumps, I can see that the smp_cpus parameter
passed in to touch_all_pages(
On Wed, Mar 11, 2020 at 07:08:06PM -0400, Eduardo Habkost wrote:
> On Wed, Mar 11, 2020 at 07:05:45PM -0400, Michael S. Tsirkin wrote:
> > On Wed, Mar 11, 2020 at 06:51:29PM -0400, Eduardo Habkost wrote:
> > > glibc and Linux-provided headers are known to generate macro
> > > redefinition warnings
As it happens, I posted some cleanups for this last week:
https://patchew.org/QEMU/20200302175829.2183-1-richard.hender...@linaro.org/
Some of them have been queued to Peter's target-arm.next branch,
but that hasn't made it to master yet.
** Changed in: qemu
Status: New => In Progress
**
Actually, I take that back: Peter has merged my TBI patch set,
and is included in 6e8a73e911f066.
Do you have a test case?
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1867072
Title:
ARM: tag bit
ok ,thanks Paolo
bauer
From: Paolo Bonzini
Date: 2020-03-12 02:34
To: bauerchen(陈蒙蒙); Igor Mammedov
CC: borntraeger; qemu-devel; qemu-s390x; mhartmay
Subject: Re: [PATCH] mem-prealloc: initialize cond and mutex(Internet mail)
On 10/03/20 08:06, bauerchen(陈蒙蒙) wrote:
> oh ,yes.Thanks
> I want to
On 3/10/20 11:44 PM, Richard Henderson wrote:
> +int probe_access_flags(CPUArchState *env, target_ulong addr,
> + MMUAccessType access_type, int mmu_idx,
> + bool nonfault, void **phost, uintptr_t retaddr)
> +{
> +void *host;
> +int flags;
> +
> +
This new interface will allow targets to probe for a page
and then handle watchpoints themselves. This will be most
useful for vector predicated memory operations, where one
page lookup can be used for many operations, and one test
can avoid many watchpoint checks.
Signed-off-by: Richard Henderso
[Expired for QEMU because there has been no activity for 60 days.]
** Changed in: qemu
Status: Incomplete => Expired
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1653577
Title:
Ability to
On 10/03/2020 21:43, Greg Kurz wrote:
> On Thu, 5 Mar 2020 12:59:03 +0100
> Greg Kurz wrote:
>
>> On Thu, 5 Mar 2020 15:30:09 +1100
>> David Gibson wrote:
>>
>>> Traditionally, virtio devices don't do DMA by the usual path on the
>>> guest platform. In particular they usually bypass any vir
The following changes since commit 0ba04f78e7c37748db89885249a653b28c962bd9:
ppc/spapr: Move GPRs setup to one place (2020-03-12 10:21:16 +1100)
are available in the Git repository at:
g...@github.com:aik/qemu.git tags/qemu-slof-20200312
for you to fetch changes up to 8b1987b232d0da2df1f33b
On 11/03/2020 22:24, Michael S. Tsirkin wrote:
Notice the process as documented in ./tests/qtest/bios-tables-test.c
Thanks for explicitly pointing me to that process.
I have followed the process described there (Both steps 1-3 and steps 4-7).
On step (6), I have noted that many existing ACP
On 11/03/2020 20:43, Paolo Bonzini wrote:
> On 10/03/20 06:07, Alexey Kardashevskiy wrote:
>> The PAPR platform which describes an OS environment that's presented by
>> a combination of a hypervisor and firmware. The features it specifies
>> require collaboration between the firmware and the hyp
On Wed, Mar 11, 2020 at 03:11:16AM -0400, Michael S. Tsirkin wrote:
> On Wed, Mar 11, 2020 at 11:58:57AM +1100, David Gibson wrote:
> > Note that several things that I believe are now in the PCIe spec, but
> > really derive more from PC legacy considerations, don't apply at all
> > for PAPR. e.g.
On Wed, Mar 11, 2020 at 03:33:59AM -0400, Michael S. Tsirkin wrote:
> On Wed, Mar 11, 2020 at 12:12:47PM +1100, David Gibson wrote:
> > I am wondering if we have to introduce an "svm=on" flag anyway. It's
> > pretty ugly, since all it would be doing is changing defaults here and
> > there for comp
On Wed, Mar 11, 2020 at 07:48:26AM -0400, Michael S. Tsirkin wrote:
> On Wed, Mar 11, 2020 at 10:01:27AM +, Daniel P. Berrangé wrote:
> > On Wed, Mar 11, 2020 at 12:12:47PM +1100, David Gibson wrote:
> > > On Tue, Mar 10, 2020 at 11:43:43AM +, Daniel P. Berrangé wrote:
> > > > On Thu, Mar 0
On Wed, Mar 11, 2020 at 10:01:27AM +, Daniel P. Berrangé wrote:
65;5803;1c> On Wed, Mar 11, 2020 at 12:12:47PM +1100, David Gibson wrote:
> > On Tue, Mar 10, 2020 at 11:43:43AM +, Daniel P. Berrangé wrote:
> > > On Thu, Mar 05, 2020 at 03:30:07PM +1100, David Gibson wrote:
> > > > Upcoming
Public bug reported:
The ARM Architecture Reference Manual provides the following for
FAR_EL1:
"For a Data Abort or Watchpoint exception, if address tagging is enabled
for the address accessed by the data access that caused the exception,
then this field includes the tag."
However, I have found
On ARMv7 & ARMv8 some load/store instructions might trigger a data abort
exception with no valid ISS info to be decoded. The lack of decode info
makes it at least tricky to emulate those instruction which is one of the
(many) reasons why KVM will not even try to do so.
Add support for handling tho
KVM_SET_VCPU_EVENTS might actually lead to vcpu registers being modified.
As such this should be the last step of sync to avoid potential overwriting
of whatever changes KVM might have done.
Signed-off-by: Beata Michalska
---
target/arm/kvm32.c | 15 ++-
target/arm/kvm64.c | 15 +
Some of the ARMv7 & ARMv8 load/store instructions might trigger a data abort
exception with no valid ISS info to be decoded. The lack of decode info
makes it at least tricky to emulate the instruction which is one of the
(many) reasons why KVM will not even try to do so.
So far, if a guest made an
Patchew URL:
https://patchew.org/QEMU/20200311232342.1614944-1-ehabk...@redhat.com/
Hi,
This series failed the asan build test. Please find the testing commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST SCRIPT BEGIN ===
#!/bin/bash
e
Patchew URL:
https://patchew.org/QEMU/20200311225130.1599619-1-ehabk...@redhat.com/
Hi,
This series failed the asan build test. Please find the testing commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST SCRIPT BEGIN ===
#!/bin/bash
e
glibc and Linux-provided headers are known to generate macro
redefinition warnings when used together. For example:
and duplicate some macro definitions.
We normally never see those warnings because GCC suppresses
warnings generated by system headers. We carry our own copy of
Linux header file
The CONFIG_LINUX check at the top of mmap-alloc.c never worked
because it was done before including osdep.h.
This means MAP_SYNC and MAP_SHARED_VALIDATE would always be set
to 0 at the beginning of the file. Luckily, this didn't break
when using recent glibc versions (2.28+), because those macros
Changes v1 -> v2:
* Use -isystem for $PWD/linux-headers too
Reported-by: "Michael S. Tsirkin"
This is an alternative to the patch submitted at:
From: Jingqi Liu
Subject: [PATCH] util: fix to get configuration macros in util/mmap-alloc.c
Date: Thu, 5 Mar 2020 23:41:42 +0800
Message-Id
On 11/03/2020 22:36, Michael S. Tsirkin wrote:
Thanks for the patch! Some questions/comments:
On Wed, Mar 11, 2020 at 07:08:26PM +0200, Liran Alon wrote:
From: Elad Gabay
Microsoft introduced this ACPI table to avoid Windows guests performing
various workarounds for device erratas. As the v
On Wed, Mar 11, 2020 at 07:08:06PM -0400, Eduardo Habkost wrote:
> On Wed, Mar 11, 2020 at 07:05:45PM -0400, Michael S. Tsirkin wrote:
> > On Wed, Mar 11, 2020 at 06:51:29PM -0400, Eduardo Habkost wrote:
> > > glibc and Linux-provided headers are known to generate macro
> > > redefinition warnings
On Wed, Mar 11, 2020 at 07:05:45PM -0400, Michael S. Tsirkin wrote:
> On Wed, Mar 11, 2020 at 06:51:29PM -0400, Eduardo Habkost wrote:
> > glibc and Linux-provided headers are known to generate macro
> > redefinition warnings when used together. For example:
> > and duplicate some macro definiti
On Wed, Mar 11, 2020 at 06:51:30PM -0400, Eduardo Habkost wrote:
> The CONFIG_LINUX check at the top of mmap-alloc.c never worked
> because it was done before including osdep.h.
>
> This means MAP_SYNC and MAP_SHARED_VALIDATE would always be set
> to 0 at the beginning of the file. Luckily, this
On Wed, Mar 11, 2020 at 06:51:29PM -0400, Eduardo Habkost wrote:
> glibc and Linux-provided headers are known to generate macro
> redefinition warnings when used together. For example:
> and duplicate some macro definitions.
>
> We normally never see those warnings because GCC suppresses
> warn
Patchew URL:
https://patchew.org/QEMU/20200311221854.30370-1-nieklinnenb...@gmail.com/
Hi,
This series failed the asan build test. Please find the testing commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST SCRIPT BEGIN ===
#!/bin/bas
Introduce model specific apicid functions inside X86MachineState.
These functions will be loaded from X86CPUDefinition.
Signed-off-by: Babu Moger
Reviewed-by: Igor Mammedov
Acked-by: Michael S. Tsirkin
---
hw/i386/x86.c |5 +
include/hw/i386/x86.h |9 +
2 files chan
These functions add support for building EPYC mode topology given the smp
details like numa nodes, cores, threads and sockets.
The new apic id decoding is mostly similar to current apic id decoding
except that it adds a new field node_id when numa configured. Removes all
the hardcoded values. Subs
Add a boolean variable use_epyc_apic_id_encoding in X86CPUDefinition.
This will be set if this cpu model needs to use new EPYC based
apic id encoding.
Override the handlers with EPYC based handlers if use_epyc_apic_id_encoding
is set. This will be done in x86_cpus_init.
Signed-off-by: Babu Moger
On 3/11/20 2:20 AM, Stefan Hajnoczi wrote:
> Please try:
>
> $ git grep pmem
>
> backends/hostmem-file.c is the backend that can be used and the
> pmem_persist() API can be used to flush writes.
I've reworked this patch into hostmem-file type of backend.
>From simple tests in virtual machine:
The function pc_cpu_pre_plug takes care of initialization of CPUX86State.
So, remove the initialization here.
Suggested-by: Igor Mammedov
Signed-off-by: Babu Moger
Reviewed-by: Igor Mammedov
Acked-by: Michael S. Tsirkin
---
hw/i386/x86.c |4
1 file changed, 4 deletions(-)
diff --git
If the system is numa configured the pkg_offset needs
to be adjusted for EPYC cpu models. Fix it calling the
model specific handler.
Signed-off-by: Babu Moger
Reviewed-by: Igor Mammedov
Acked-by: Michael S. Tsirkin
---
hw/i386/pc.c |1 +
target/i386/cpu.c |4 ++--
target/i386/cpu.
Use the new functions from topology.h and delete the unused code. Given the
sockets, nodes, cores and threads, the new functions generate apic id for EPYC
mode. Removes all the hardcoded values.
Signed-off-by: Babu Moger
Acked-by: Michael S. Tsirkin
Acked-by: Igor Mammedov
---
target/i386/cpu.
Store the smp sockets in CpuTopology. The socket information required to
build the apic id in EPYC mode. Right now socket information is not passed
to down when decoding the apic id. Add the socket information here.
Signed-off-by: Babu Moger
Reviewed-by: Eduardo Habkost
Reviewed-by: Igor Mammed
The APIC ID is decoded based on the sequence sockets->dies->cores->threads.
This works fine for most standard AMD and other vendors' configurations,
but this decoding sequence does not follow that of AMD's APIC ID enumeration
strictly. In some cases this can cause CPU topology inconsistency.
When
Apicid calculation depends on knowing the total number of numa nodes
for EPYC cpu models. Right now, we are calculating the arch_id while
parsing the numa(parse_numa). At this time, it is not known how many
total numa nodes are configured in the system.
Move the arch_id calculation inside x86_cpus
Now that we have all the parameters in X86CPUTopoInfo, we can just
pass the structure to calculate the offsets and width.
Signed-off-by: Babu Moger
Reviewed-by: Igor Mammedov
Acked-by: Michael S. Tsirkin
---
include/hw/i386/topology.h | 68 +--
target/
Update structures X86CPUTopoIDs and CPUX86State to hold the number of
nodes per package. This is required to build EPYC mode topology.
Signed-off-by: Babu Moger
Reviewed-by: Igor Mammedov
Acked-by: Michael S. Tsirkin
---
hw/i386/pc.c |1 +
hw/i386/x86.c |1 +
For consistency rename apicid_from_topo_ids to x86_apicid_from_topo_ids.
No functional change.
Signed-off-by: Babu Moger
Reviewed-by: Igor Mammedov
Acked-by: Michael S. Tsirkin
---
hw/i386/pc.c |2 +-
include/hw/i386/topology.h |6 +++---
2 files changed, 4 insertions(+),
This series fixes APIC ID encoding problem reported on AMD EPYC cpu models.
https://bugzilla.redhat.com/show_bug.cgi?id=1728166
Currently, the APIC ID is decoded based on the sequence
sockets->dies->cores->threads. This works for most standard AMD and other
vendors' configurations, but this decodi
The CONFIG_LINUX check at the top of mmap-alloc.c never worked
because it was done before including osdep.h.
This means MAP_SYNC and MAP_SHARED_VALIDATE would always be set
to 0 at the beginning of the file. Luckily, this didn't break
when using recent glibc versions (2.28+), because those macros
This is an effort to re-arrange few data structure for better readability.
1. Add X86CPUTopoInfo which will have all the topology informations
required to build the cpu topology. There is no functional changes.
2. Introduce init_topo_info to initialize X86CPUTopoInfo members from
X86Machine
This is an alternative to the patch submitted at:
From: Jingqi Liu
Subject: [PATCH] util: fix to get configuration macros in util/mmap-alloc.c
Date: Thu, 5 Mar 2020 23:41:42 +0800
Message-Id: <20200305154142.63070-1-jingqi@intel.com>
Before moving the osdep.h include to the top of t
glibc and Linux-provided headers are known to generate macro
redefinition warnings when used together. For example:
and duplicate some macro definitions.
We normally never see those warnings because GCC suppresses
warnings generated by system headers. We carry our own copy of
Linux header file
Allwinner System-on-Chips usually contain a Real Time Clock (RTC)
for non-volatile system date and time keeping. This commit adds a generic
Allwinner RTC device that supports the RTC devices found in Allwinner SoC
family sun4i (A10), sun7i (A20) and sun6i and newer (A31, H2+, H3, etc).
The followin
The Xunlong Orange Pi PC machine is a functional ARM machine
based on the Allwinner H3 System-on-Chip. It supports mainline
Linux, U-Boot, NetBSD and is covered by acceptance tests.
This commit adds a documentation text file with a description
of the machine and instructions for the user.
Signed-
From: Philippe Mathieu-Daudé
This test boots U-Boot then NetBSD (stored on a SD card) on
a OrangePi PC board.
As it requires ~1.3GB of storage, it is disabled by default.
U-Boot is built by the Debian project [1], and the SD card image
is provided by the NetBSD organization [2].
Once the compr
From: Philippe Mathieu-Daudé
The kernel image and DeviceTree blob are built by the Armbian
project (based on Debian):
https://www.armbian.com/orange-pi-pc/
The SD image is from the kernelci.org project:
https://kernelci.org/faq/#the-code
If ARM is a target being built, "make check-acceptance" w
The Allwinner Sun8i System on Chip family includes an Ethernet MAC (EMAC)
which provides 10M/100M/1000M Ethernet connectivity. This commit
adds support for the Allwinner EMAC from the Sun8i family (H2+, H3, A33, etc),
including emulation for the following functionality:
* DMA transfers
* MII int
From: Philippe Mathieu-Daudé
This test boots a Linux kernel on a OrangePi PC board and verify
the serial output is working.
The kernel image and DeviceTree blob are built by the Armbian
project (based on Debian):
https://www.armbian.com/orange-pi-pc/
The cpio image used comes from the linux-bui
In the Allwinner H3 SoC the SDRAM controller is responsible
for interfacing with the external Synchronous Dynamic Random
Access Memory (SDRAM). Types of memory that the SDRAM controller
supports are DDR2/DDR3 and capacities of up to 2GiB. This commit
adds emulation support of the Allwinner H3 SDRAM
From: Philippe Mathieu-Daudé
This test boots Ubuntu Bionic on a OrangePi PC board.
As it requires 1GB of storage, and is slow, this test is disabled
on automatic CI testing.
It is useful for workstation testing. Currently Avocado timeouts too
quickly, so we can't run userland commands.
The ker
Various Allwinner System on Chip designs contain multiple processors
that can be configured and reset using the generic CPU Configuration
module interface. This commit adds support for the Allwinner CPU
configuration interface which emulates the following features:
* CPU reset
* CPU status
Sign
From: Philippe Mathieu-Daudé
This test boots a Linux kernel on a OrangePi PC board and verify
the serial output is working.
The kernel image and DeviceTree blob are built by the Armbian
project (based on Debian):
https://www.armbian.com/orange-pi-pc/
If ARM is a target being built, "make check-
The Allwinner System on Chip families sun4i and above contain
an integrated storage controller for Secure Digital (SD) and
Multi Media Card (MMC) interfaces. This commit adds support
for the Allwinner SD/MMC storage controller with the following
emulated features:
* DMA transfers
* Direct FIFO I
The Clock Control Unit is responsible for clock signal generation,
configuration and distribution in the Allwinner H3 System on Chip.
This commit adds support for the Clock Control Unit which emulates
a simple read/write register interface.
Signed-off-by: Niek Linnenbank
Reviewed-by: Philippe Mat
A real Allwinner H3 SoC contains a Boot ROM which is the
first code that runs right after the SoC is powered on.
The Boot ROM is responsible for loading user code (e.g. a bootloader)
from any of the supported external devices and writing the downloaded
code to internal SRAM. After loading the SoC b
The Allwinner H3 is a System on Chip containing four ARM Cortex A7
processor cores. Features and specifications include DDR2/DDR3 memory,
SD/MMC storage cards, 10/100/1000Mbit Ethernet, USB 2.0, HDMI and
various I/O modules. This commit adds support for the Allwinner H3
System on Chip.
Signed-off-
The Xunlong Orange Pi PC is an Allwinner H3 System on Chip
based embedded computer with mainline support in both U-Boot
and Linux. The board comes with a Quad Core Cortex A7 @ 1.3GHz,
1GiB RAM, 100Mbit ethernet, USB, SD/MMC, USB, HDMI and
various other I/O. This commit add support for the Xunlong
O
The Allwinner H3 System on Chip has an System Control
module that provides system wide generic controls and
device information. This commit adds support for the
Allwinner H3 System Control module.
Signed-off-by: Niek Linnenbank
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Alex Bennée
Tested
Dear QEMU developers,
Hereby I would like to contribute the following set of patches to QEMU
which add support for the Allwinner H3 System on Chip and the
Orange Pi PC machine. The following features and devices are supported:
* SMP (Quad Core Cortex A7)
* Generic Interrupt Controller configura
The Allwinner H3 System on Chip contains multiple USB 2.0 bus
connections which provide software access using the Enhanced
Host Controller Interface (EHCI) and Open Host Controller
Interface (OHCI) interfaces. This commit adds support for
both interfaces in the Allwinner H3 System on Chip.
Signed-
The Security Identifier device found in various Allwinner System on Chip
designs gives applications a per-board unique identifier. This commit
adds support for the Allwinner Security Identifier using a 128-bit
UUID value as input.
Signed-off-by: Niek Linnenbank
Reviewed-by: Alex Bennée
---
incl
On Wed, 11 Mar 2020, Mark Cave-Ayland wrote:
On 10/03/2020 19:06, BALATON Zoltan wrote:
Some machines operate in "non 100% native mode" where interrupts are
fixed at legacy IDE interrupts and some guests expect this behaviour
without checking based on knowledge about hardware. Even Linux has
arc
On 11/03/20 22:21, Maxime Villard wrote:
>> Yes, you don't know how long that run would take. I don't know about
>> NVMM but for KVM it may even never leave if the guest is in HLT state.
> Ok, I see, thanks.
>
> In NVMM the runs are short
How do you ensure that a guest with interrupts off exits
On 11.03.2020 22:21, Maxime Villard wrote:
> Le 11/03/2020 à 21:42, Paolo Bonzini a écrit :
>> On 11/03/20 21:14, Maxime Villard wrote:
The problem is that qcpu->stop is checked _before_ entering the
hypervisor and not after, so there is a small race window.
>>> Ok. I don't understand wha
Le 11/03/2020 à 21:42, Paolo Bonzini a écrit :
> On 11/03/20 21:14, Maxime Villard wrote:
>>> The problem is that qcpu->stop is checked _before_ entering the
>>> hypervisor and not after, so there is a small race window.
>> Ok. I don't understand what's supposed to be the race here. If we get an
>>
On 10/03/2020 19:06, BALATON Zoltan wrote:
> Some machines operate in "non 100% native mode" where interrupts are
> fixed at legacy IDE interrupts and some guests expect this behaviour
> without checking based on knowledge about hardware. Even Linux has
> arch specific workarounds for this that ar
On Wed, Mar 11, 2020 at 05:20:06PM +, Shameer Kolothum wrote:
> Any sub-page size update to ACPI table MRs will be lost during
> migration, as we use aligned size in ram_load_precopy() ->
> qemu_ram_resize() path. This will result in inconsistency in sizes
> between source and destination. In o
On 10/03/2020 19:06, BALATON Zoltan wrote:
> Follow example of CMD646 and remove via_init_ide function and do it
> directly in board code instead.
>
> Signed-off-by: BALATON Zoltan
> ---
> hw/ide/via.c| 8
> hw/mips/mips_fulong2e.c | 5 -
> include/hw/ide.h| 1 -
On 10/03/2020 19:06, BALATON Zoltan wrote:
> The pci_do_device_reset() function (called from pci_device_reset)
> clears the PCI_INTERRUPT_LINE config reg of devices on the bus but did
> this without taking wmask into account. We'll have a device model now
> that needs to set a constant value for t
On Wed, Mar 11, 2020 at 12:37:17PM +, Peter Maydell wrote:
> On Wed, 11 Mar 2020 at 00:43, Liu, Jingqi wrote:
> > 1) If '#include ' first then '#include qemu/osdep.h', it
> > should be fine.
> >
> > 2) Peter mentioned osdep.h should go first.
> >
> > It will cause redefinitions of other MAP_*
On Wed, Mar 11, 2020 at 05:20:06PM +, Shameer Kolothum wrote:
> Any sub-page size update to ACPI table MRs will be lost during
> migration, as we use aligned size in ram_load_precopy() ->
> qemu_ram_resize() path. This will result in inconsistency in sizes
> between source and destination. In o
On 11/03/20 21:14, Maxime Villard wrote:
>> The problem is that qcpu->stop is checked _before_ entering the
>> hypervisor and not after, so there is a small race window.
> Ok. I don't understand what's supposed to be the race here. If we get an
> IPI between the check and the call to nvmm_vcpu_run(
Thanks for the patch! Some questions/comments:
On Wed, Mar 11, 2020 at 07:08:26PM +0200, Liran Alon wrote:
> From: Elad Gabay
>
> Microsoft introduced this ACPI table to avoid Windows guests performing
> various workarounds for device erratas. As the virtual device emulated
> by VMM may not have
On Wed, Mar 11, 2020 at 09:08:56PM +0200, Liran Alon wrote:
>
> On 11/03/2020 20:59, no-re...@patchew.org wrote:
> > Patchew URL:
> > https://urldefense.com/v3/__https://patchew.org/QEMU/20200311170826.79419-1-liran.a...@oracle.com/__;!!GqivPVa7Brio!L4XXKjkDknE86ihbnytm45vsQI41J-QWVCZRoXEXtPKIAsM
On Wed, Mar 11, 2020 at 04:00:44PM +0200, Yuri Benditovich wrote:
>
>
> On Wed, Mar 11, 2020 at 3:48 PM Michael S. Tsirkin wrote:
>
> On Wed, Mar 11, 2020 at 02:35:17PM +0200, Yuri Benditovich wrote:
> > Save and restore RSS/hash report configuration.
> >
> > Signed-off-by: Yuri
On Wed, Mar 11, 2020 at 03:57:58PM +0200, Yuri Benditovich wrote:
>
>
> On Wed, Mar 11, 2020 at 3:47 PM Michael S. Tsirkin wrote:
>
> On Wed, Mar 11, 2020 at 02:35:13PM +0200, Yuri Benditovich wrote:
> > Signed-off-by: Yuri Benditovich
> > ---
> > hw/net/virtio-net.c | 95
Le 11/03/2020 à 19:03, Paolo Bonzini a écrit :
> On 10/03/20 20:14, Maxime Villard wrote:
>> Maybe, whpx_vcpu_kick() causes a WHvRunVpExitReasonCanceled in the
>> WHvRunVirtualProcessor() call that follows, which in turn causes "ret=1"
>> to leave the loop. That is, maybe the next WHvRunVirtualProc
On Wed, Mar 11, 2020 at 9:04 PM Alex Bennée wrote:
>
> Niek Linnenbank writes:
>
> > On Wed, Mar 11, 2020 at 2:53 PM Alex Bennée
> wrote:
> >
> >>
> >> Niek Linnenbank writes:
> >>
> >> > The Security Identifier device found in various Allwinner System on
> Chip
> >> > designs gives applicatio
On Wed, Mar 11, 2020 at 3:04 PM Alex Bennée wrote:
>
> Niek Linnenbank writes:
>
> > Dear QEMU developers,
> >
> > Hereby I would like to contribute the following set of patches to QEMU
> > which add support for the Allwinner H3 System on Chip and the
> > Orange Pi PC machine. The following feat
Niek Linnenbank writes:
> On Wed, Mar 11, 2020 at 2:53 PM Alex Bennée wrote:
>
>>
>> Niek Linnenbank writes:
>>
>> > The Security Identifier device found in various Allwinner System on Chip
>> > designs gives applications a per-board unique identifier. This commit
>> > adds support for the Al
On Wed, Mar 11, 2020 at 3:00 PM Alex Bennée wrote:
>
> Niek Linnenbank writes:
>
> > The Xunlong Orange Pi PC machine is a functional ARM machine
> > based on the Allwinner H3 System-on-Chip. It supports mainline
> > Linux, U-Boot, NetBSD and is covered by acceptance tests.
> >
> > This commit a
On Mittwoch, 11. März 2020 17:14:08 CET Greg Kurz wrote:
> On Wed, 11 Mar 2020 02:18:04 +0100
>
> Christian Schoenebeck wrote:
> > On Dienstag, 10. März 2020 19:33:36 CET Greg Kurz wrote:
> > > > This patch is also too big for my preference, but I don't see a viable
> > > > way
> > > > to split i
On Wed, Mar 11, 2020 at 2:58 PM Alex Bennée wrote:
>
> Niek Linnenbank writes:
>
> > A real Allwinner H3 SoC contains a Boot ROM which is the
> > first code that runs right after the SoC is powered on.
> > The Boot ROM is responsible for loading user code (e.g. a bootloader)
> > from any of the
1 - 100 of 399 matches
Mail list logo
