On Wed, Feb 20, 2019 at 05:06:24PM +0100, Marc-André Lureau wrote:
> Hi,
Hi,
>
> The chardev context switching code is a bit fragile, as it works as if
> the current context is properly synchronized with the new context. It
> isn't so obvious to me that concurrent usage of chardev can't
Hi,
> > +DEFINE_PROP_UINT32("xres", VFIOPCIDevice, display_xres, 0),
> > +DEFINE_PROP_UINT32("yres", VFIOPCIDevice, display_yres, 0),
>
> This is actually quite fun, I started my VM with arbitrary numbers and
> the Windows GUI honored it every time. Probably very useful for
> playing
Hi Thomas,
> did you ever sent the patch? I can't find it on the mailing list, and I think
>this bug is still pending?Yes, I have patches but was waiting for my first one
>to be successful in order to make sure I got the process down. I will finish
>that shortly.
CheersLuc
On 24/01/2019
On Wed, Feb 20, 2019 at 02:54:35PM -0700, Alex Williamson wrote:
> On Wed, 20 Feb 2019 09:47:51 +0100
> Gerd Hoffmann wrote:
>
> > This patch adds EDID support to the vfio display (aka vgpu) code.
> > When supported by the mdev driver qemu will generate a EDID blob
> > and pass it on using the
On Thu, Feb 21, 2019 at 05:52:53AM +, Tian, Kevin wrote:
> > From: Kirti Wankhede [mailto:kwankh...@nvidia.com]
> > Sent: Thursday, February 21, 2019 1:25 PM
> >
> > On 2/20/2019 3:52 PM, Dr. David Alan Gilbert wrote:
> > > * Kirti Wankhede (kwankh...@nvidia.com) wrote:
> > >> Add migration
The license information in this file is very messy. A short note at
the beginning says GPL first, but the long boilerplate code then
talks about "GNU Lesser General Public License version 2.0". First,
there is no such version of the "GNU Lesser GPL", it only started with
version 2.1. In version
On 2019/2/21 下午2:00, Yuri Benditovich wrote:
On Tue, Feb 19, 2019 at 8:27 AM Jason Wang wrote:
On 2019/2/19 上午7:34, Michael S. Tsirkin wrote:
On Mon, Feb 18, 2019 at 10:49:08PM +0200, Yuri Benditovich wrote:
On Mon, Feb 18, 2019 at 6:39 PM Michael S. Tsirkin wrote:
On Mon, Feb 18, 2019
On 15/02/2019 03:36, Peter Maydell wrote:
> On Tue, 5 Feb 2019 at 17:33, Eric Auger wrote:
>>
>> From: Alexey Kardashevskiy
>>
>> Since Linux'es ab66dcc76d "powerpc: generate uapi header and system call
>> table files" there are 2 new files: unistd_32.h and unistd_64.h. These
>> files content
On Thu, Feb 21, 2019 at 02:03:19PM +0800, Xiao Guangrong wrote:
>
>
>On 2/20/19 8:51 AM, Wei Yang wrote:
>> Three trivial cleanup for pc-dimm.
>>
>> Patch [1] remove the check on class->hotpluggable since pc-dimm is always
>> hotpluggable.
>> Patch [2] remove nvdimm_realize
>> Patch [2] remove
On 2/20/19 8:51 AM, Wei Yang wrote:
Three trivial cleanup for pc-dimm.
Patch [1] remove the check on class->hotpluggable since pc-dimm is always
hotpluggable.
Patch [2] remove nvdimm_realize
Patch [2] remove pcdimm realize-callback
v2:
* fix warning in Patch 1
* split Patch 2 into two
On Tue, Feb 19, 2019 at 8:27 AM Jason Wang wrote:
>
>
> On 2019/2/19 上午7:34, Michael S. Tsirkin wrote:
> > On Mon, Feb 18, 2019 at 10:49:08PM +0200, Yuri Benditovich wrote:
> >> On Mon, Feb 18, 2019 at 6:39 PM Michael S. Tsirkin wrote:
> >>> On Mon, Feb 18, 2019 at 11:58:51AM +0200, Yuri
> >
> > > -Original Message-
> > > From: Zhao Yan [mailto:yan.y.z...@intel.com]
> > > Sent: Thursday, February 21, 2019 10:05 AM
> > > To: Gonglei (Arei)
> > > Cc: alex.william...@redhat.com; qemu-devel@nongnu.org;
> > > intel-gvt-...@lists.freedesktop.org; zhengxiao...@alibaba-inc.com;
>
> From: Kirti Wankhede [mailto:kwankh...@nvidia.com]
> Sent: Thursday, February 21, 2019 1:25 PM
>
> On 2/20/2019 3:52 PM, Dr. David Alan Gilbert wrote:
> > * Kirti Wankhede (kwankh...@nvidia.com) wrote:
> >> Add migration support for VFIO device
> >
> > Hi Kirti,
> > Can you explain how this
> -Original Message-
> From: Zhao Yan [mailto:yan.y.z...@intel.com]
> Sent: Thursday, February 21, 2019 12:08 PM
> To: Gonglei (Arei)
> Cc: c...@nvidia.com; k...@vger.kernel.org; a...@ozlabs.ru;
> zhengxiao...@alibaba-inc.com; shuangtai@alibaba-inc.com;
> qemu-devel@nongnu.org;
On 2/20/2019 3:52 PM, Dr. David Alan Gilbert wrote:
> * Kirti Wankhede (kwankh...@nvidia.com) wrote:
>> Add migration support for VFIO device
>
> Hi Kirti,
> Can you explain how this compares and works with Yan Zhao's
> set?
This patch set is incremental version of my previous patch set:
On Thu, Feb 21, 2019 at 03:16:45AM +, Gonglei (Arei) wrote:
>
>
>
> > -Original Message-
> > From: Zhao Yan [mailto:yan.y.z...@intel.com]
> > Sent: Thursday, February 21, 2019 10:05 AM
> > To: Gonglei (Arei)
> > Cc: alex.william...@redhat.com; qemu-devel@nongnu.org;
> >
On Thu, Feb 21, 2019 at 03:33:24AM +, Gonglei (Arei) wrote:
>
> > -Original Message-
> > From: Zhao Yan [mailto:yan.y.z...@intel.com]
> > Sent: Thursday, February 21, 2019 9:59 AM
> > To: Gonglei (Arei)
> > Cc: alex.william...@redhat.com; qemu-devel@nongnu.org;
> >
> -Original Message-
> From: Zhao Yan [mailto:yan.y.z...@intel.com]
> Sent: Thursday, February 21, 2019 9:59 AM
> To: Gonglei (Arei)
> Cc: alex.william...@redhat.com; qemu-devel@nongnu.org;
> intel-gvt-...@lists.freedesktop.org; zhengxiao...@alibaba-inc.com;
> yi.l@intel.com;
> -Original Message-
> From: Zhao Yan [mailto:yan.y.z...@intel.com]
> Sent: Thursday, February 21, 2019 10:05 AM
> To: Gonglei (Arei)
> Cc: alex.william...@redhat.com; qemu-devel@nongnu.org;
> intel-gvt-...@lists.freedesktop.org; zhengxiao...@alibaba-inc.com;
> yi.l@intel.com;
On Tue, Feb 19, 2019 at 08:31:25AM +0100, Cédric Le Goater wrote:
> On 2/12/19 6:40 AM, David Gibson wrote:
> > On Mon, Jan 28, 2019 at 10:46:11AM +0100, Cédric Le Goater wrote:
[snip]
> >> #endif /* _PPC_PNV_H */
> >> diff --git a/include/hw/ppc/pnv_core.h b/include/hw/ppc/pnv_core.h
> >> index
On 01/29/2019 08:29 AM, Jason J. Herne wrote:
Allows guest to boot from a vfio configured real dasd device.
Signed-off-by: Jason J. Herne
---
docs/devel/s390-dasd-ipl.txt | 132 +++
pc-bios/s390-ccw/Makefile| 2 +-
pc-bios/s390-ccw/dasd-ipl.c | 249
On Wed, Feb 20, 2019 at 05:54:25PM +0100, Greg Kurz wrote:
> On Wed, 20 Feb 2019 15:49:41 +
> Peter Maydell wrote:
>
> > On Wed, 20 Feb 2019 at 15:43, Greg Kurz wrote:
> > > I have an account. I'll start updating the wiki according to what was
> > > actually merged up to this pull request.
On 20.02.2019 18:29, Paolo Bonzini wrote:
> On 20/02/19 12:59, Kamil Rytarowski wrote:
>> Ping, still valid.
>
> Sorry, I missed your email.
>
>> On 15.02.2019 00:38, Kamil Rytarowski wrote:
>>> I consider it as fragile hack and certainly not something to depend on.
>>> Also in some
> >
> > > 5) About log sync, why not register log_global_start/stop in
> > vfio_memory_listener?
> > >
> > >
> > seems log_global_start/stop cannot be iterately called in pre-copy phase?
> > for dirty pages in system memory, it's better to transfer dirty data
> > iteratively to reduce down time,
On Thu, Feb 21, 2019 at 01:35:43AM +, Gonglei (Arei) wrote:
>
>
> > -Original Message-
> > From: Zhao Yan [mailto:yan.y.z...@intel.com]
> > Sent: Thursday, February 21, 2019 8:25 AM
> > To: Gonglei (Arei)
> > Cc: alex.william...@redhat.com; qemu-devel@nongnu.org;
> >
On Wed, Feb 20, 2019 at 06:08:13PM +0100, Cornelia Huck wrote:
> On Wed, 20 Feb 2019 02:36:36 -0500
> Zhao Yan wrote:
>
> > On Tue, Feb 19, 2019 at 02:09:18PM +0100, Cornelia Huck wrote:
> > > On Tue, 19 Feb 2019 16:52:14 +0800
> > > Yan Zhao wrote:
> (...)
> > > > + * Size of device
On 02/20/2019 09:12 PM, Dr. David Alan Gilbert wrote:
* Wang, Wei W (wei.w.w...@intel.com) wrote:
On Friday, December 14, 2018 7:17 PM, Dr. David Alan Gilbert wrote:
On 12/14/2018 05:56 PM, Dr. David Alan Gilbert wrote:
* Wei Wang (wei.w.w...@intel.com) wrote:
On 12/13/2018 11:45 PM, Dr.
> -Original Message-
> From: Zhao Yan [mailto:yan.y.z...@intel.com]
> Sent: Thursday, February 21, 2019 8:25 AM
> To: Gonglei (Arei)
> Cc: alex.william...@redhat.com; qemu-devel@nongnu.org;
> intel-gvt-...@lists.freedesktop.org; zhengxiao...@alibaba-inc.com;
> yi.l@intel.com;
On Thu, 21 Feb 2019 at 04:00, Michael S. Tsirkin wrote:
>
> On Mon, Feb 18, 2019 at 06:27:41PM +0800, elohi...@gmail.com wrote:
> > From: Xie Yongji
> >
> > This patchset is aimed at supporting qemu to reconnect
> > vhost-user-blk backend after vhost-user-blk backend crash or
> > restart.
> >
>
Similar to the x86_64 + pc test, it boots a Linux kernel on a Malta
board and verify the serial is working. One extra command added to
the QEMU command line is '-vga std', because the kernel used is
known to crash without it.
If alpha is a target being built, "make check-acceptance" will
The 'printk.time=0' option makes it easier to parse the console
output. Let's set it as a default, and reusable, kernel command line
options for this and future similar tests.
Signed-off-by: Cleber Rosa
Reviewed-by: Philippe Mathieu-Daudé
---
tests/acceptance/boot_linux_console.py | 4 +++-
1
Just like the previous tests, boots a Linux kernel on an arm target
using the virt machine.
Signed-off-by: Cleber Rosa
Reviewed-by: Caio Carrara
---
.travis.yml| 2 +-
tests/acceptance/boot_linux_console.py | 20
2 files changed, 21
Just like the previous tests, boots a Linux kernel on a s390x target
using the s390-ccw-virtio machine.
Because it's not possible to have multiple VT220 consoles,
'-nodefaults' is used, so that the one set with set_console() works
correctly.
Signed-off-by: Cleber Rosa
Reviewed-by: Cornelia Huck
Just like the previous tests, boots a Linux kernel on a aarch64 target
using the virt machine.
One special option added is the CPU type, given that the kernel
selected fails to boot on the virt machine's default CPU (cortex-a15).
Signed-off-by: Cleber Rosa
Reviewed-by: Caio Carrara
---
Just like the previous tests, boots a Linux kernel on a ppc64 target
using the pseries machine.
Signed-off-by: Cleber Rosa
Reviewed-by: Caio Carrara
---
.travis.yml| 2 +-
tests/acceptance/boot_linux_console.py | 19 +++
2 files changed, 20
The set_console() utility function traditionally adds a device either
based on the explicitly given device type, or based on the machine type,
a known good type of device.
But, for a number of machine types, it may be impossible or
inconvenient to add the devices my means of "-device" command
When running on very low powered environments, some tests may time out
causing false negatives. As a conservative change, and for
considering that human time (investigating false negatives) is worth
more than some extra machine cycles (and time), let's increase the
overall timeout.
CC: Alex
To the stock Fedora 29 kernel, from the Fedora 28. New tests will be
added using the 29 kernel, so for consistency, let's also update it
here.
Signed-off-by: Cleber Rosa
Reviewed-by: Caio Carrara
---
tests/acceptance/boot_linux_console.py | 4 ++--
1 file changed, 2 insertions(+), 2
This introduces a utility method that monitors the console device and
looks for either a message that signals the test success or failure.
Signed-off-by: Cleber Rosa
Reviewed-by: Caio Carrara
Reviewed-by: Philippe Mathieu-Daudé
---
tests/acceptance/boot_linux_console.py | 30
Given that the test is specific to x86_64 and pc, and new tests are
going to be added to the same class, let's rename it accordingly.
Also, let's make the class documentation not architecture specific.
Signed-off-by: Cleber Rosa
Reviewed-by: Caio Carrara
Reviewed-by: Philippe Mathieu-Daudé
---
Currently, the only test that contains some target architecture
information is "boot_linux_console.py" which test contains a "x86_64"
tag. But that tag is not respected in the default execution, that is,
"make check-acceptance" doesn't do anything with it.
That said, even the target architecture
A test can, optionally, be tagged for one or many architectures. If a
test has been tagged for a single architecture, there's a high chance
that the test won't run on other architectures. This changes the
default order of choosing a default target architecture to use based
on the 'arch' tag
From: Philippe Mathieu-Daudé
Similar to the x86_64 + pc test, it boots a Linux kernel on a Malta
board and verify the serial is working. Also, it relies on the serial
device set by the machine itself.
If mips is a target being built, "make check-acceptance" will
automatically include this test
Making it clear what is returned by this utility function.
Signed-off-by: Cleber Rosa
Reviewed-by: Caio Carrara
Reviewed-by: Philippe Mathieu-Daudé
---
tests/acceptance/avocado_qemu/__init__.py | 4
1 file changed, 4 insertions(+)
diff --git a/tests/acceptance/avocado_qemu/__init__.py
The "this directory" reference is misleading and confusing, it's a
leftover from when this text was proposed in a README file inside
the "tests/acceptance/avocado_qemu" directory.
When that text was moved to the top level docs directory, the
reference was not updated.
Signed-off-by: Cleber Rosa
It's useful to define the architecture that should be used in
situations such as:
* the intended target of the QEMU binary to be used on tests
* the architecture of code to be run within the QEMU binary, such
as a kernel image or a full blown guest OS image
This commit introduces both a test
Similar to the x86_64 + pc test, it boots a Linux kernel on a Malta
board and verify the serial is working.
If mips64el is a target being built, "make check-acceptance" will
automatically include this test by the use of the "arch:mips64el"
tags.
Alternatively, this test can be run using:
$
The current version of the "check-acceptance" target will only show
one line for execution of all tests. That's probably OK if the tests
to be run are quick enough and they're always the same.
But, there's already one test alone that takes on average ~5 seconds
to run, we intend to adapt the
Even when the launch of QEMU succeeds, it's useful to have the command
line recorded.
Signed-off-by: Cleber Rosa
Reviewed-by: Caio Carrara
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Alex Bennée
---
scripts/qemu.py | 1 +
1 file changed, 1 insertion(+)
diff --git a/scripts/qemu.py
The current acceptance tests don't provide any type of architecture
information that can be used to influence the selection of the QEMU
binary used on them[1]. If one is running tests on a x86_64 host, the
default QEMU binary will be "x86_64-softmmu/qemu-system-x86_64".
Given the nature of QEMU,
Signed-off-by: Alistair Francis
---
hw/riscv/sifive_u.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/hw/riscv/sifive_u.c b/hw/riscv/sifive_u.c
index 7bc25820fe..3199238ba0 100644
--- a/hw/riscv/sifive_u.c
+++ b/hw/riscv/sifive_u.c
@@ -398,7 +398,10 @@ static void
On Thu, 21 Feb 2019, BALATON Zoltan wrote:
On Tue, 19 Feb 2019, Peter Maydell wrote:
On Tue, 12 Feb 2019 at 23:59, BALATON Zoltan wrote:
On Tue, 12 Feb 2019, Philippe Mathieu-Daudé wrote:
I'd have use a pair of extract32/deposit32 but this is probably easier
By the way, should these lines
From: Michael Clark
Cc: Palmer Dabbelt
Cc: Alistair Francis
Signed-off-by: Michael Clark
Signed-off-by: Alistair Francis
---
Makefile.objs | 1 +
target/riscv/cpu_helper.c | 12 +++-
target/riscv/trace-events | 2 ++
3 files changed, 6 insertions(+), 9 deletions(-)
From: Michael Clark
Refer to the RISC-V PSABI specification for details:
- https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md
Cc: Michael Tokarev
Cc: Richard Henderson
Cc: Alistair Francis
Reviewed-by: Laurent Vivier
Signed-off-by: Michael Clark
Signed-off-by: Alistair
From: Michael Clark
If vectored interrupts are enabled (bits[1:0]
of mtvec/stvec == 1) then use the following
logic for trap entry address calculation:
pc = mtvec + cause * 4
In addition to adding support for vectored interrupts
this patch simplifies the interrupt delivery logic
by making
From: Michael Clark
This effectively changes riscv_cpu_update_mip
from edge to level. i.e. cpu_interrupt or
cpu_reset_interrupt are called regardless of
the current interrupt level.
Fixes WFI doesn't return when a IPI is issued:
- https://github.com/riscv/riscv-qemu/issues/132
To test:
1)
From: Michael Clark
We can't allow the supervisor to control SEIP as this would allow the
supervisor to clear a pending external interrupt which will result in
lost a interrupt in the case a PLIC is attached. The SEIP bit must be
hardware controlled when a PLIC is attached.
This logic was
From: Michael Clark
Cc: Palmer Dabbelt
Cc: Alistair Francis
Signed-off-by: Michael Clark
Signed-off-by: Alistair Francis
---
target/riscv/cpu_helper.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/target/riscv/cpu_helper.c b/target/riscv/cpu_helper.c
index
Signed-off-by: Alistair Francis
---
target/riscv/pmp.c | 20 +---
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/target/riscv/pmp.c b/target/riscv/pmp.c
index 15a5366616..b11c4ae22f 100644
--- a/target/riscv/pmp.c
+++ b/target/riscv/pmp.c
@@ -113,10 +113,11 @@
From: Kito Cheng
This change checks elf_flags for EF_RISCV_RVE and if
present uses the RVE linux syscall ABI which uses t0
for the syscall number instead of a7.
Warn and exit if a non-RVE ABI binary is run on a
cpu with the RVE extension as it is incompatible.
Cc: Palmer Dabbelt
Cc: Sagar
From: Michael Clark
Remove machine generated constraints that are not
referenced by the pseudo-instruction constraints.
Cc: Palmer Dabbelt
Cc: Sagar Karandikar
Cc: Bastian Koppelmann
Cc: Alistair Francis
Signed-off-by: Michael Clark
Signed-off-by: Alistair Francis
---
disas/riscv.c | 138
From: Michael Clark
The mode variable only uses the lower 4-bits (M,H,S,U) so
replace the GCC specific __builtin_popcount with ctpop8.
Cc: Palmer Dabbelt
Cc: Sagar Karandikar
Cc: Bastian Koppelmann
Cc: Alistair Francis
Signed-off-by: Michael Clark
Signed-off-by: Alistair Francis
---
v2:
- Add a patch for SiFive U SMP support
- Rebase on master
Alistair Francis (2):
riscv: pmp: Log pmp access errors as guest errors
riscv: sifive_u: Allow up to 4 CPUs to be created
Kito Cheng (1):
RISC-V: linux-user support for RVE ABI
Michael Clark (8):
RISC-V: Replace
On Wed, Feb 20, 2019 at 11:01:43AM +, Dr. David Alan Gilbert wrote:
> * Zhao Yan (yan.y.z...@intel.com) wrote:
> > On Tue, Feb 19, 2019 at 11:32:13AM +, Dr. David Alan Gilbert wrote:
> > > * Yan Zhao (yan.y.z...@intel.com) wrote:
> > > > This patchset enables VFIO devices to have live
On Wed, Feb 20, 2019 at 11:56:01AM +, Gonglei (Arei) wrote:
> Hi yan,
>
> Thanks for your work.
>
> I have some suggestions or questions:
>
> 1) Would you add msix mode support,? if not, pls add a check in
> vfio_pci_save_config(), likes Nvidia's solution.
ok.
> 2) We should start vfio
On Wed, Feb 20, 2019 at 11:14:24AM +0100, Christophe de Dinechin wrote:
>
>
> > On 20 Feb 2019, at 08:58, Zhao Yan wrote:
> >
> > On Tue, Feb 19, 2019 at 03:42:36PM +0100, Christophe de Dinechin wrote:
> >>
> >>
> >>> On 19 Feb 2019, at 09:53, Yan Zhao wrote:
> >>>
> >>> If a device has
Signed-off-by: Richard Henderson
---
target/arm/cpu.h | 10 ++
linux-user/elfload.c | 1 +
target/arm/cpu.c | 1 +
target/arm/cpu64.c | 2 ++
target/arm/translate-a64.c | 14 ++
target/arm/translate.c | 22 ++
6
Both of these are defined by the ARMv8.5 spec, but back-defined
as v8.0 extensions.
All of the relevant instructions are nops within QEMU. Tested by
locally setting SCTLR_EL1.EnRCTX for aarch64-linux-user and then
executing each of the insns to see that they decode properly.
The SB extension is
This is named "Execution and Data prediction restriction instructions"
within the ARMv8.5 manual, and given the name "PredRes" by binutils.
Signed-off-by: Richard Henderson
---
target/arm/cpu.h| 11 ++
target/arm/cpu.c| 1 +
target/arm/cpu64.c | 2 ++
target/arm/helper.c | 49
On Tue, 19 Feb 2019, Peter Maydell wrote:
On Tue, 12 Feb 2019 at 23:59, BALATON Zoltan wrote:
On Tue, 12 Feb 2019, Philippe Mathieu-Daudé wrote:
On 2/11/19 4:19 AM, BALATON Zoltan wrote:
This is where my question about valid/impl on mem ops started but I asked
separately again after not
On Tue, Feb 19, 2019 at 03:37:24PM +0100, Cornelia Huck wrote:
> On Tue, 19 Feb 2019 16:52:27 +0800
> Yan Zhao wrote:
>
> > Device config is the default data that every device should have. so
> > device config capability is by default on, no need to set.
> >
> > - Currently two type of
From: Kwangwoo Lee
This patch uses configurable IO base and size to create NPIO AML for
ACPI NFIT. Since a different architecture like AArch64 does not use
port-mapped IO, a configurable IO base is required to create correct
mapping of ACPI IO address and size.
Signed-off-by: Kwangwoo Lee
On Wed, Feb 20, 2019 at 09:27:06 -0800, Richard Henderson wrote:
> Thanks for the patience. Both Alex and I have now completed review, and I
> think this is ready for merge.
>
> There are some patch conflicts with master, so if you can fix those and post a
> v7, we'll get it merged right away.
From: Shameer Kolothum
This patch adds memory nodes corresponding to PC-DIMM regions.
NV_DIMM and ACPI_NVDIMM configs are not yet set for ARM so we
don't need to care about NV-DIMM at this stage.
Signed-off-by: Shameer Kolothum
Signed-off-by: Eric Auger
---
v6 -> v7:
- rework the error
From: Shameer Kolothum
Generate Memory Affinity Structures for PC-DIMM ranges.
Signed-off-by: Shameer Kolothum
Signed-off-by: Eric Auger
Reviewed-by: Igor Mammedov
---
v6 -> v7:
- add Igor's R-b
v5 -> v6:
- fix mingw compil issue
v4 -> v5:
- Align to x86 code and especially
"pc: acpi:
Machine option nvdimm allows to turn NVDIMM support on.
Signed-off-by: Eric Auger
---
hw/arm/virt.c | 59 +--
1 file changed, 57 insertions(+), 2 deletions(-)
diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index 1896920570..c7e68e2428 100644
---
The device memory region is located after the initial RAM.
its start/size are 1GB aligned.
Signed-off-by: Eric Auger
Signed-off-by: Kwangwoo Lee
---
v6 -> v7:
- check the device memory top does not wrap
- check the device memory can fit the slots
v4 -> v5:
- device memory set after the
This patch implements the machine class kvm_type() callback.
It returns the number of bits requested to implement the whole GPA
range including the RAM and IO regions located beyond.
The returned value in passed though the KVM_CREATE_VM ioctl and
this allows KVM to set the stage2 tables
The machine RAM attributes will need to be analyzed during the
configure_accelerator() process. especially kvm_type() arm64
machine callback will use them to know how many IPA/GPA bits are
needed to model the whole RAM range. So let's assign those machine
state fields before calling
Up to now the memory map has been static and the high IO region
base has always been 256GiB.
This patch modifies the virt_set_memmap() function, which freezes
the memory map, so that the high IO range base becomes floating,
located after the initial RAM and the device memory.
The function
Add the kvm_arm_get_max_vm_ipa_size() helper that returns the
number of bits in the IPA address space supported by KVM.
This capability needs to be known to create the VM with a
specific IPA max size (kvm_type passed along KVM_CREATE_VM ioctl.
Signed-off-by: Eric Auger
---
v6 -> v7:
-
Hi Peter,
On 2/20/19 11:39 PM, Eric Auger wrote:
> This series aims to bump the 255GB RAM limit in machvirt and to
> support device memory in general, and especially PCDIMM/NVDIMM.
>
> In machvirt versions < 4.0, the initial RAM starts at 1GB and can
> grow up to 255GB. From 256GB onwards we
In the prospect to introduce an extended memory map supporting more
RAM, let's split the memory map array into two parts:
- the former a15memmap contains regions below and including the RAM
- extended_memmap, only initialized with entries located after the RAM.
Only the size of the region is
On ARM, the kvm_type will be resolved by querying the KVMState.
Let's add the MachineState handle to the callback so that we
can retrieve the KVMState handle. in kvm_init, when the callback
is called, the kvm_state variable is not yet set.
Signed-off-by: Eric Auger
Acked-by: David Gibson
[ppc
From: Kwangwoo Lee
Pre-plug and plug handlers are prepared for NVDIMM support.
Signed-off-by: Eric Auger
Signed-off-by: Kwangwoo Lee
---
default-configs/arm-softmmu.mak | 2 ++
hw/arm/virt-acpi-build.c| 6 ++
hw/arm/virt.c | 22 ++
In case of NV-DIMM slots, let's add /pmem DT nodes.
Signed-off-by: Eric Auger
---
v6 -> v7
- does the same rework as for fdt_add_memory_node
---
hw/arm/boot.c | 40
1 file changed, 40 insertions(+)
diff --git a/hw/arm/boot.c b/hw/arm/boot.c
index
From: Shameer Kolothum
We introduce an helper to create a memory node.
Signed-off-by: Eric Auger
Signed-off-by: Shameer Kolothum
---
v6 -> v7:
- msg error in the caller
- add comment about NUMA ID
---
hw/arm/boot.c | 54 ---
1 file changed,
Now we have the extended memory map (high IO regions beyond the
scalable RAM) and dynamic IPA range support at KVM/ARM level
we can bump the legacy 255GB initial RAM limit. The actual maximum
RAM size now depends on the physical CPU and host kernel.
Signed-off-by: Eric Auger
---
v6 -> v7
-
This patch adds the the memory hot-plug/hot-unplug infrastructure
in machvirt. It is still not enabled as no device memory is allocated.
Signed-off-by: Eric Auger
Signed-off-by: Shameer Kolothum
Signed-off-by: Kwangwoo Lee
---
v4 -> v5:
- change in pc_dimm_pre_plug signature
-
In preparation for a split of the memory map into a static
part and a dynamic part floating after the RAM, let's rename the
regions located after the RAM
Signed-off-by: Eric Auger
Reviewed-by: Peter Maydell
---
v7: added Peter's R-b
v6: creation
---
hw/arm/virt-acpi-build.c | 8
This series aims to bump the 255GB RAM limit in machvirt and to
support device memory in general, and especially PCDIMM/NVDIMM.
In machvirt versions < 4.0, the initial RAM starts at 1GB and can
grow up to 255GB. From 256GB onwards we find IO regions such as the
additional GICv3 RDIST region, high
On Wed, 20 Feb 2019 09:47:53 +0100
Gerd Hoffmann wrote:
> Kick the display link up event with a 0.1 sec delay,
> so the guest has a chance to notice the link down first.
>
> Signed-off-by: Gerd Hoffmann
> ---
> include/hw/vfio/vfio-common.h | 1 +
> hw/vfio/display.c | 26
On Wed, 20 Feb 2019 09:47:52 +0100
Gerd Hoffmann wrote:
> This allows configure the display resolution which the vgpu should use.
> The information will be passed to the guest using EDID, so the mdev
> driver must support the vfio edid region for this to work.
>
> Signed-off-by: Gerd Hoffmann
On Wed, 20 Feb 2019 09:47:51 +0100
Gerd Hoffmann wrote:
> This patch adds EDID support to the vfio display (aka vgpu) code.
> When supported by the mdev driver qemu will generate a EDID blob
> and pass it on using the new vfio edid region. The EDID blob will
> be updated on UI changes (i.e.
Signed-off-by: Kővágó, Zoltán
---
audio/dsound_template.h | 6 ++---
audio/audio_legacy.c| 41
audio/dsoundaudio.c | 59 -
3 files changed, 61 insertions(+), 45 deletions(-)
diff --git a/audio/dsound_template.h
I had to include an enum for audio sampling formats into qapi, but that
meant duplicating the audfmt_e enum. This patch replaces audfmt_e and
associated values with the qapi generated AudioFormat enum.
This patch is mostly a search-and-replace, except for switches where the
qapi generated
Signed-off-by: Kővágó, Zoltán
---
audio/alsaaudio.c| 330 +--
audio/audio_legacy.c | 84 ++-
2 files changed, 182 insertions(+), 232 deletions(-)
diff --git a/audio/alsaaudio.c b/audio/alsaaudio.c
index 8302f3e882..ecd0474310 100644
---
This patch adds structures into qapi to replace the existing
configuration structures used by audio backends currently. This qapi
will be the base of the -audiodev command line parameter (that replaces
the old environment variables based config).
This is not a 1:1 translation of the old options,
Signed-off-by: Kővágó, Zoltán
---
audio/audio_legacy.c | 32 +
audio/ossaudio.c | 161 ++-
2 files changed, 83 insertions(+), 110 deletions(-)
diff --git a/audio/audio_legacy.c b/audio/audio_legacy.c
index 17105e7239..bfba41fefe 100644
---
This patch adds documentation of an -audiodev command line option, that
deprecates the old QEMU_* environment variables for audio backend
configuration. It's syntax is similar to existing options (-netdev,
-device, etc):
-audiodev driver_name,property=value,...
Although now it's possible to
1 - 100 of 394 matches
Mail list logo
