On 10/2/19 11:34 PM, Alistair Francis wrote:
Coverity (CID 1405786) thinks that there is a possible memory leak as
we don't guarentee that the memory allocatd from riscv_find_firmware()
typos: 'guarantee', 'allocated'
is freed. This is a false positive, but let's tidy up the code to fix
the w
Hi, Laurent
On 10/1/19 11:46 PM, Laurent Vivier wrote:
Le 11/09/2019 à 05:31, Mao Zhongyi a écrit :
if stress function always return 0, the path
'if (stress(ramsizeGB, ncpus) < 0)' is nerver unreachable,
so fix it to allow the test failed.
Cc: arm...@redhat.com
Cc: laur...@vivier.eu
Cc: tony.
Public bug reported:
I use Logitech K800 keyboard which is connected to a PC through Logitech
unifying receiver. In order to control my windows VM i attach unifying
receiver USB device to a VM using "virsh attach-device VM-Name
./device.xml". Device ID as seen in lsusb is 046d:c52b.
As of v4.1.0
Hi Matthew,
On 10/3/19 2:18 AM, Matthew Kilgore wrote:
The current code uses getcchar() and setcchar() to handle the cchar_t
values, which is correct, however it incorrectly deconstructs the chtype
value that it then passes to setcchar():
1. The bit mask 0xff against the chtype is not guar
On 03/10/2019 00:37, David Gibson wrote:
> On Wed, Oct 02, 2019 at 04:47:56PM +0200, Cédric Le Goater wrote:
>> On 02/10/2019 16:21, Greg Kurz wrote:
>>> On Wed, 2 Oct 2019 11:02:45 +1000
>>> David Gibson wrote:
>>>
On Tue, Oct 01, 2019 at 06:56:28PM +0200, Greg Kurz wrote:
> On Tue, 1 Oc
On 03/10/2019 04:41, David Gibson wrote:
> On Wed, Sep 18, 2019 at 06:06:44PM +0200, Cédric Le Goater wrote:
>> The trigger definition is used for triggers both for HW source
>> interrupts, PHB, PSI, as well as for rerouting interrupts between
>> Interrupt Controller.
>>
>> HW source controllers se
On 03/10/2019 04:34, David Gibson wrote:
> On Wed, Sep 18, 2019 at 06:06:42PM +0200, Cédric Le Goater wrote:
>> The OS CAM line has a special encoding exploited by the HW. Provide a
>> helper routine to hide the details to the TIMA command handlers. This
>> also clarifies the endian ness of differe
On 03/10/2019 04:22, David Gibson wrote:
> On Wed, Sep 18, 2019 at 06:06:38PM +0200, Cédric Le Goater wrote:
>> We try to loop on the full table skipping empty indirect pages which
>> are not necessarily allocated. This is useful to dump the contexts of
>> the KVM vCPUs.
>
> I think this patch can
On 03/10/2019 04:20, David Gibson wrote:
> On Wed, Sep 18, 2019 at 06:06:36PM +0200, Cédric Le Goater wrote:
>> pnv_xive_vst_size() tries to compute the size of a VSD table from the
>> information given by FW. The number of entries of the table are
>> deduced from the result and the MMIO regions of
On Wed, Oct 02, 2019 at 01:08:40PM +0200, Paolo Bonzini wrote:
> On 02/10/19 12:22, Alex Bennée wrote:
> > Some of the cross compilers rightly complain there are cases where ret
> > may not be set. 0 seems to be the reasonable default unless particular
> > slot explicitly returns -1.
> >
Even Cov
On 03/10/2019 04:12, David Gibson wrote:
> On Wed, Sep 18, 2019 at 06:06:34PM +0200, Cédric Le Goater wrote:
>> The NVT space is 19 bits wide, giving a maximum of 512K per chip. When
>> dispatched on a HW thread, the NVT identifier of a vCPU is pushed/stored
>> in the CAM line (word2) of the thread
Le 03/10/2019 à 09:17, maozy a écrit :
> Hi, Laurent
>
> On 10/1/19 11:46 PM, Laurent Vivier wrote:
>> Le 11/09/2019 à 05:31, Mao Zhongyi a écrit :
>>> if stress function always return 0, the path
>>> 'if (stress(ramsizeGB, ncpus) < 0)' is nerver unreachable,
>>> so fix it to allow the test faile
On 03/10/2019 04:11, David Gibson wrote:
> On Wed, Sep 18, 2019 at 06:06:33PM +0200, Cédric Le Goater wrote:
>> We will use it to resend missed interrupts when a vCPU context is
>> pushed a HW thread.
>>
>> Signed-off-by: Cédric Le Goater
>> ---
>> include/hw/ppc/xive.h | 1 +
>> hw/intc/xive.c
Sergio Lopez writes:
> Kevin Wolf writes:
>
>> Am 13.09.2019 um 21:54 hat John Snow geschrieben:
>>>
>>>
>>> On 9/13/19 11:25 AM, Sergio Lopez wrote:
>>> > do_drive_backup() already acquires the AioContext, so release it
>>> > before the call.
>>> >
>>> > Signed-off-by: Sergio Lopez
>>> > -
02.10.2019 18:52, Max Reitz wrote:
> On 02.10.19 17:06, Vladimir Sementsov-Ogievskiy wrote:
>> 02.10.2019 18:03, Vladimir Sementsov-Ogievskiy wrote:
>>> 02.10.2019 17:57, Max Reitz wrote:
On 12.09.19 17:13, Vladimir Sementsov-Ogievskiy wrote:
> Prior 9adc1cb49af8d do_sync_target_write had
On 03/10/2019 03:50, David Gibson wrote:
> On Wed, Sep 18, 2019 at 06:06:23PM +0200, Cédric Le Goater wrote:
>> As there is now easy way to loop on the CPUs belonging to a chip, add
>> a helper to filter out external CPUs.
>
> This seems a somewhat odd way to go about it, given that the chip does
On 03/10/2019 03:54, David Gibson wrote:
> On Wed, Sep 18, 2019 at 06:06:25PM +0200, Cédric Le Goater wrote:
>> The XiveFabric QOM interface should be implemented by the machine. It
>> acts as the PowerBUS interface between the interrupt controller and
>> the system. On HW, the XIVE sub-engine is r
On 03/10/2019 03:55, David Gibson wrote:
> On Wed, Sep 18, 2019 at 06:06:26PM +0200, Cédric Le Goater wrote:
>> The CAM line matching on the PowerNV machine now scans all chips of
>> the system and all CPUs of a chip to find a dispatched NVT in the
>> thread contexts.
>>
>> Signed-off-by: Cédric Le
On Thu, 3 Oct 2019 at 01:53, Bin Meng wrote:
>
> On Thu, Oct 3, 2019 at 5:38 AM Alistair Francis
> wrote:
> >
> > Coverity (CID 1405786) thinks that there is a possible memory leak as
> > we don't guarentee that the memory allocatd from riscv_find_firmware()
> > is freed. This is a false positive
On 03/10/2019 03:58, David Gibson wrote:
> On Wed, Sep 18, 2019 at 06:06:27PM +0200, Cédric Le Goater wrote:
>> The CAM line matching sequence in the pseries machine does not change
>> much apart from the use of the new QOM interfaces. There is an extra
>> indirection because of the sPAPR IRQ backe
tests/test-bdrv-drain can hang in tests/iothread.c:iothread_run():
while (!atomic_read(&iothread->stopping)) {
aio_poll(iothread->ctx, true);
}
The iothread_join() function works as follows:
void iothread_join(IOThread *iothread)
{
iothread->stopping = true;
aio_notify(
Philippe Mathieu-Daudé writes:
> Hi Sergio,
>
> Depending of the IDE developers use, the patch subject is not always
> prepended to the patch description.
>
> You can add: "The following functions are named *pc* but are not
> PC-machine specific but generic to the X86 architecture, rename them:"
Sergio Lopez writes:
> qboot is a minimalist x86 firmware for booting Linux kernels. It does
> the mininum amount of work required for the task, and it's able to
> boot both PVH images and bzImages without relying on option roms.
I've just noticed all other submodules refer to mirrors hosted in
On 03/10/19 12:01, Stefan Hajnoczi wrote:
> tests/test-bdrv-drain can hang in tests/iothread.c:iothread_run():
>
> while (!atomic_read(&iothread->stopping)) {
> aio_poll(iothread->ctx, true);
> }
>
> The iothread_join() function works as follows:
>
> void iothread_join(IOThread *ioth
On 10/2/19 1:30 PM, Sergio Lopez wrote:
Put QOM and main struct definition in a separate header file, so it
can be accessed from other components.
Signed-off-by: Sergio Lopez
---
hw/virtio/virtio-mmio.c | 48 +-
include/hw/virtio/virtio-mmio.h | 73 +++
03.10.2019 0:35, John Snow wrote:
> On 10/2/19 6:46 AM, Peter Krempa wrote:
>
> [ * poof * ]
>
>>
>> I'd like to re-iterate that the necessity to keep node names same on
>> both sides of migration is unexpected, undocumented and in some cases
>> impossible.
>>
>> If you want to mandate that they
Closing this bug with Won't fix as this kernel / release is no longer supported.
Please feel free to open a new bug report if you're still experiencing this on
a newer release (Bionic 18.04.3 / Disco 19.04)
Thanks!
** Changed in: linux (Ubuntu)
Status: Triaged => Won't Fix
--
You receive
On 10/3/19 11:22 AM, Stefano Garzarella wrote:
On Wed, Oct 02, 2019 at 01:08:40PM +0200, Paolo Bonzini wrote:
On 02/10/19 12:22, Alex Bennée wrote:
Some of the cross compilers rightly complain there are cases where ret
may not be set. 0 seems to be the reasonable default unless particular
slot
On 03/10/19 12:07, Sergio Lopez wrote:
>
>> qboot is a minimalist x86 firmware for booting Linux kernels. It does
>> the mininum amount of work required for the task, and it's able to
>> boot both PVH images and bzImages without relying on option roms.
> I've just noticed all other submodules refe
cc'd in kwolf since he signed off on that change.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1846427
Title:
4.1.0: qcow2 corruption on savevm/quit/loadvm cycle
Status in QEMU:
New
Bug descri
Hi Sergio,
On 10/2/19 1:30 PM, Sergio Lopez wrote:
Split up PCMachineState and PCMachineClass and derive X86MachineState
and X86MachineClass from them. This allows sharing code with non-PC
x86 machine types.
Signed-off-by: Sergio Lopez
---
hw/acpi/cpu_hotplug.c | 10 +--
hw/i386/acpi-build
On 10/2/19 1:30 PM, Sergio Lopez wrote:
Move x86 functions that will be shared between PC and non-PC machine
types to x86.c, along with their helpers.
Signed-off-by: Sergio Lopez
---
hw/i386/Makefile.objs | 1 +
hw/i386/pc.c | 582 +--
hw/i386/pc_p
Hi,
I've been following Alexander's fuzzing changes from the GSoC
project, and it's looking like an excellent start on the
introduction of fuzzing into the world of Qemu/KVM.
I had a couple of off-list e-mails with Stefan and Alexander, to get
some idea of what the intent was going forward, and
On 9/16/19 7:21 PM, Cédric Le Goater wrote:
On 16/09/2019 17:48, Philippe Mathieu-Daudé wrote:
Move RTC devices under the hw/rtc/ subdirectory.
Signed-off-by: Philippe Mathieu-Daudé
I suppose the removal of the header files in "aspeed_rtc.h" is OK.
They are not used. It is probably cleaner
On 03/10/2019 04:08, David Gibson wrote:
> On Wed, Sep 18, 2019 at 06:06:31PM +0200, Cédric Le Goater wrote:
>> This also removes the need of the get_tctx() XiveRouter handler in the
>> core XIVE framework.
>
> In general these commit messages could really do with more context.
> What exactly is t
The following changes since commit 7f21573c822805a8e6be379d9bcf3ad9effef3dc:
Merge remote-tracking branch
'remotes/huth-gitlab/tags/pull-request-2019-10-01' into staging (2019-10-01
13:13:38 +0100)
are available in the git repository at:
git://github.com/bonzini/qemu.git tags/for-upstream
The following changes since commit 7f21573c822805a8e6be379d9bcf3ad9effef3dc:
Merge remote-tracking branch
'remotes/huth-gitlab/tags/pull-request-2019-10-01' into staging (2019-10-01
13:13:38 +0100)
are available in the git repository at:
git://github.com/bonzini/qemu.git tags/for-upstream
On Thu, 3 Oct 2019 at 11:50, Darren Kenny wrote:
> How would you like to move forward? Is there an ordered list of
> device or machines that we'd like to focus on anywhere? If not,
> could we create one?
Roughly, "anything that can be used with KVM" is our
security boundary, so we should start wi
The following changes since commit 7f21573c822805a8e6be379d9bcf3ad9effef3dc:
Merge remote-tracking branch
'remotes/huth-gitlab/tags/pull-request-2019-10-01' into staging (2019-10-01
13:13:38 +0100)
are available in the git repository at:
git://github.com/bonzini/qemu.git tags/for-upstream
On Thu, Oct 03, 2019 at 11:58:23AM +0100, Peter Maydell wrote:
> On Thu, 3 Oct 2019 at 11:50, Darren Kenny wrote:
> > How would you like to move forward? Is there an ordered list of
> > device or machines that we'd like to focus on anywhere? If not,
> > could we create one?
>
> Roughly, "anything
Please take a look at the following patch
https://lists.nongnu.org/archive/html/qemu-ppc/2019-10/msg00133.html and
let me know if problem is solved.
On 2.10.19. 16:08, Stefan Brankovic wrote:
Hi Mark,
Thank you for reporting this bug. I was away from office for couple of
days, so that's why
Philippe Mathieu-Daudé writes:
> On 10/2/19 1:30 PM, Sergio Lopez wrote:
>> Move x86 functions that will be shared between PC and non-PC machine
>> types to x86.c, along with their helpers.
>>
>> Signed-off-by: Sergio Lopez
>> ---
>> hw/i386/Makefile.objs | 1 +
>> hw/i386/pc.c |
Paolo Bonzini writes:
> On 03/10/19 12:07, Sergio Lopez wrote:
>>
>>> qboot is a minimalist x86 firmware for booting Linux kernels. It does
>>> the mininum amount of work required for the task, and it's able to
>>> boot both PVH images and bzImages without relying on option roms.
>> I've just n
Philippe Mathieu-Daudé writes:
> Hi Sergio,
>
> On 10/2/19 1:30 PM, Sergio Lopez wrote:
>> Split up PCMachineState and PCMachineClass and derive X86MachineState
>> and X86MachineClass from them. This allows sharing code with non-PC
>> x86 machine types.
>>
>> Signed-off-by: Sergio Lopez
>> ---
On Fri, 20 Sep 2019 15:43:45 +0800
Tao Xu wrote:
> From: Liu Jingqi
>
> Add -numa hmat-cache option to provide Memory Side Cache Information.
> These memory attributes help to build Memory Side Cache Information
> Structure(s) in ACPI Heterogeneous Memory Attribute Table (HMAT).
>
> Reviewed-b
Philippe Mathieu-Daudé writes:
> On 10/2/19 1:30 PM, Sergio Lopez wrote:
>> Put QOM and main struct definition in a separate header file, so it
>> can be accessed from other components.
>>
>> Signed-off-by: Sergio Lopez
>> ---
>> hw/virtio/virtio-mmio.c | 48 +-
>>
If there is no slot in the section ret is not initialized. This triggers
a compilation error at caller site.
error: ‘ret’ may be used uninitialized in this function
[-Werror=maybe-uninitialized]
if (r < 0) {
Fixes: 84516e5b8d ("kvm: clear dirty bitmaps from all overlapping memslots")
Signed-
Introduce support for GTree migration. A custom save/restore
is implemented. Each item is made of a key and a data. For that
reason, 2 VMSD objects are passed into the GTree VMStateField.
When putting the items, the tree is traversed in sorted order by
g_tree_foreach.
On the get() path, gtrees mu
+QEMU developers ML
On Thu, Oct 3, 2019 at 7:37 PM Waseem ALKurdi
wrote:
>
> Dear all,
>
> I'm trying to get mainline U-Boot to boot on mainline QEMU 4.1.0 for the
> 'sabrelite' board, using the configuration 'mx6qsabrelite_defconfig'.
>
> It's not booting at all. Actually, not a single U-Boot b
On POWER9 systems, the XICS-on-XIVE and XIVE KVM devices currently
allocate a bunch of VPs in the XIVE HW to accomodate the highest
VCPU id that may be possibly used in a VM. This limits the number
of VMs that can run with an in-kernel interrupt controller to 63
per POWER9 chip, irrespectively of i
Both XICS and XIVE backends can access nr_servers by other means. No
need to pass it around anymore.
Signed-off-by: Greg Kurz
---
hw/intc/spapr_xive.c|3 +--
hw/intc/xics_spapr.c|3 +--
hw/ppc/spapr.c |3 +--
hw/ppc/spapr_irq.c |5 ++---
incl
The number of servers, ie. upper bound of the highest VCPU id, is
currently only needed to generate the "interrupt-controller" node
in the DT. Soon it will be needed to inform the XICS-on-XIVE KVM
device that it can allocates less resources in the XIVE HW.
Add a method to XICSFabricClass for this
In order to get some new KVM definitions:
#define KVM_DEV_XICS_GRP_CTRL 2
#define KVM_DEV_XICS_NR_SERVERS 1
#define KVM_DEV_XIVE_NR_SERVERS 3
Signed-off-by: Greg Kurz
---
This is tagged as RFC since these KVM definitions aren't upstream yet.
---
include/standard-heade
Support for setting VSMT is available in KVM since linux-4.13. Most distros
that support KVM on POWER already have it. It thus seem reasonable enough
to have the default machine to set VSMT to smp_threads.
This brings contiguous VCPU ids and thus brings their upper bound down to
the machine's max_
The XIVE KVM devices now has an attribute to configure the number of
interrupt servers. This allows to greatly optimize the usage of the VP
space in the XIVE HW, and thus to start a lot more VMs.
Only set this attribute if available in order to support older POWER9
KVM.
The XIVE KVM device now re
The sPAPR XIVE object has an nr_ends field which happens to be a
multiple of spapr_max_server_number(). It is currently set with
the help of "nr-ends" property. This is a bit unfortunate since
it exposes to the sPAPR irq frontend what should remain an
implemantation detail within the XIVE backend.
The XICS-on-XIVE KVM devices now has an attribute to configure the number
of interrupt servers. This allows to greatly optimize the usage of the VP
space in the XIVE HW, and thus to start a lot more VMs.
Only set this attribute if available in order to support older POWER9 KVM
and pre-POWER9 XICS
Philippe Mathieu-Daudé writes:
> On 10/3/19 11:22 AM, Stefano Garzarella wrote:
>> On Wed, Oct 02, 2019 at 01:08:40PM +0200, Paolo Bonzini wrote:
>>> On 02/10/19 12:22, Alex Bennée wrote:
Some of the cross compilers rightly complain there are cases where ret
may not be set. 0 seems to
On 03/10/2019 14:01, Greg Kurz wrote:
> The sPAPR XIVE object has an nr_ends field which happens to be a
> multiple of spapr_max_server_number(). It is currently set with
> the help of "nr-ends" property. This is a bit unfortunate since
> it exposes to the sPAPR irq frontend what should remain an
>
On 03/10/2019 14:00, Greg Kurz wrote:
> The number of servers, ie. upper bound of the highest VCPU id, is
> currently only needed to generate the "interrupt-controller" node
> in the DT. Soon it will be needed to inform the XICS-on-XIVE KVM
> device that it can allocates less resources in the XIVE
On 03/10/2019 14:01, Greg Kurz wrote:
> Both XICS and XIVE backends can access nr_servers by other means. No
> need to pass it around anymore.
OK. You are doing the clean up in this patch.
> Signed-off-by: Greg Kurz
even if spapr_irq removal is programmed,
Reviewed-by: Cédric Le Goater
> --
On 03/10/2019 14:01, Greg Kurz wrote:
> The XICS-on-XIVE KVM devices now has an attribute to configure the number
> of interrupt servers. This allows to greatly optimize the usage of the VP
> space in the XIVE HW, and thus to start a lot more VMs.
>
> Only set this attribute if available in order
On 03/10/2019 14:01, Greg Kurz wrote:
> The XIVE KVM devices now has an attribute to configure the number of
> interrupt servers. This allows to greatly optimize the usage of the VP
> space in the XIVE HW, and thus to start a lot more VMs.
>
> Only set this attribute if available in order to suppo
Patchew URL:
https://patchew.org/QEMU/20191003114144.30129-1-eric.au...@redhat.com/
Hi,
This series failed the docker-quick@centos7 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
Documenting this here as bug# was dropped from the mail thread:
On 02/10/19 13:05, Jan Glauber wrote:
> The arm64 code generated for the
> atomic_[add|sub] accesses of ctx->notify_me doesn't contain any
> memory barriers. It is just plain ldaxr/stlxr.
>
> From my understanding this is not sufficie
On Wed, 2019-10-02 at 15:20 +0200, Paolo Bonzini wrote:
> On 02/10/19 13:05, Jan Glauber wrote:
>> The arm64 code generated for the
>> atomic_[add|sub] accesses of ctx->notify_me doesn't contain any
>> memory barriers. It is just plain ldaxr/stlxr.
>>
>> From my understanding this is not sufficient
On 02/10/19 16:58, Torvald Riegel wrote:
> This example looks like Dekker synchronization (if I get the intent right).
It is the same pattern. However, one of the two synchronized variables
is a counter rather than just a flag.
> Two possible implementations of this are either (1) with all memor
On Tue, 1 Oct 2019 at 16:15, Aleksandar Markovic
wrote:
>
> From: Aleksandar Markovic
>
> The following changes since commit 95e9d74fe4281f7ad79a5a7511400541729aa44a:
>
> Merge remote-tracking branch 'remotes/borntraeger/tags/s390x-20190930' into
> staging (2019-09-30 14:21:56 +0100)
>
> are a
On Thu, 3 Oct 2019 14:21:59 +0200
Cédric Le Goater wrote:
> On 03/10/2019 14:01, Greg Kurz wrote:
> > The sPAPR XIVE object has an nr_ends field which happens to be a
> > multiple of spapr_max_server_number(). It is currently set with
> > the help of "nr-ends" property. This is a bit unfortunate
Patchew URL:
https://patchew.org/QEMU/20191003114144.30129-1-eric.au...@redhat.com/
Hi,
This series failed the docker-mingw@fedora 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 =
On Thu, 3 Oct 2019 14:24:06 +0200
Cédric Le Goater wrote:
> On 03/10/2019 14:00, Greg Kurz wrote:
> > The number of servers, ie. upper bound of the highest VCPU id, is
> > currently only needed to generate the "interrupt-controller" node
> > in the DT. Soon it will be needed to inform the XICS-on
On Thu, 3 Oct 2019 14:25:58 +0200
Cédric Le Goater wrote:
> On 03/10/2019 14:01, Greg Kurz wrote:
> > Both XICS and XIVE backends can access nr_servers by other means. No
> > need to pass it around anymore.
>
> OK. You are doing the clean up in this patch.
>
> > Signed-off-by: Greg Kurz
>
> e
On Thu, 3 Oct 2019 14:29:46 +0200
Cédric Le Goater wrote:
> On 03/10/2019 14:01, Greg Kurz wrote:
> > The XICS-on-XIVE KVM devices now has an attribute to configure the number
> > of interrupt servers. This allows to greatly optimize the usage of the VP
> > space in the XIVE HW, and thus to start
On 03/10/2019 14:49, Greg Kurz wrote:
> On Thu, 3 Oct 2019 14:24:06 +0200
> Cédric Le Goater wrote:
>
>> On 03/10/2019 14:00, Greg Kurz wrote:
>>> The number of servers, ie. upper bound of the highest VCPU id, is
>>> currently only needed to generate the "interrupt-controller" node
>>> in the DT.
On Thu, 3 Oct 2019 14:58:45 +0200
Cédric Le Goater wrote:
> On 03/10/2019 14:49, Greg Kurz wrote:
> > On Thu, 3 Oct 2019 14:24:06 +0200
> > Cédric Le Goater wrote:
> >
> >> On 03/10/2019 14:00, Greg Kurz wrote:
> >>> The number of servers, ie. upper bound of the highest VCPU id, is
> >>> curren
Ping for code review, please?
thanks
-- PMM
On Mon, 16 Sep 2019 at 15:15, Peter Maydell wrote:
>
> This patchset implements support in QEMU for v2.0 of the
> Arm semihosting specification:
> https://developer.arm.com/docs/100863/latest/preface
>
> Specifically, v2.0 has:
> * a mechanism for de
On 10/3/19 6:26 AM, Sergio Lopez wrote:
Philippe Mathieu-Daudé writes:
On 10/2/19 1:30 PM, Sergio Lopez wrote:
Put QOM and main struct definition in a separate header file, so it
can be accessed from other components.
Signed-off-by: Sergio Lopez
+
+#ifndef QEMU_VIRTIO_MMIO_H
+#define QE
On 03/10/2019 15:02, Greg Kurz wrote:
> On Thu, 3 Oct 2019 14:58:45 +0200
> Cédric Le Goater wrote:
>
>> On 03/10/2019 14:49, Greg Kurz wrote:
>>> On Thu, 3 Oct 2019 14:24:06 +0200
>>> Cédric Le Goater wrote:
>>>
On 03/10/2019 14:00, Greg Kurz wrote:
> The number of servers, ie. upper b
On Thu, 3 Oct 2019 15:19:22 +0200
Cédric Le Goater wrote:
> On 03/10/2019 15:02, Greg Kurz wrote:
> > On Thu, 3 Oct 2019 14:58:45 +0200
> > Cédric Le Goater wrote:
> >
> >> On 03/10/2019 14:49, Greg Kurz wrote:
> >>> On Thu, 3 Oct 2019 14:24:06 +0200
> >>> Cédric Le Goater wrote:
> >>>
>
On Fri, 20 Sep 2019 15:43:46 +0800
Tao Xu wrote:
> From: Liu Jingqi
>
> HMAT is defined in ACPI 6.3: 5.2.27 Heterogeneous Memory Attribute Table
> (HMAT). The specification references below link:
> http://www.uefi.org/sites/default/files/resources/ACPI_6_3_final_Jan30.pdf
>
> It describes the
On 10/3/19 3:11 PM, Eric Blake wrote:
On 10/3/19 6:26 AM, Sergio Lopez wrote:
Philippe Mathieu-Daudé writes:
On 10/2/19 1:30 PM, Sergio Lopez wrote:
Put QOM and main struct definition in a separate header file, so it
can be accessed from other components.
Signed-off-by: Sergio Lopez
+
+#
On 03/10/2019 15:41, Greg Kurz wrote:
> On Thu, 3 Oct 2019 15:19:22 +0200
> Cédric Le Goater wrote:
>
>> On 03/10/2019 15:02, Greg Kurz wrote:
>>> On Thu, 3 Oct 2019 14:58:45 +0200
>>> Cédric Le Goater wrote:
>>>
On 03/10/2019 14:49, Greg Kurz wrote:
> On Thu, 3 Oct 2019 14:24:06 +0200
02.10.2019 17:22, Andrey Shinkevich wrote:
> QEMU currently supports writing compressed data of size less than or
> equal to one cluster. This patch allows writing QCOW2 compressed data
> that exceed one cluster. The implementation is simple, we split buffered
> data into separate clusters and writ
02.10.2019 17:22, Andrey Shinkevich wrote:
> Add the test case to the iotest #214 that checks possibility of writing
> compressed data to more than one cluster.
>
> Signed-off-by: Andrey Shinkevich
> ---
> tests/qemu-iotests/214 | 9 +
> tests/qemu-iotests/214.out | 6 ++
> 2
On Tue, Oct 01, 2019 at 11:20:42 +0200, Paolo Bonzini wrote:
> On 30/09/19 18:16, Jiri Denemark wrote:
> > On Mon, Sep 30, 2019 at 17:16:27 +0200, Paolo Bonzini wrote:
> >> On 30/09/19 16:31, Hu, Robert wrote:
> This might be a problem if there are plans to eventually make KVM support
> p
02.10.2019 17:22, Andrey Shinkevich wrote:
> Added possibility to write compressed data by using the
> blk_write_compressed. This action has the limitations of the format
> driver. For example we can't write compressed data over other.
>
> $ ./qemu-img create -f qcow2 -o size=10G ./image.qcow2
> $
The POWER8 PowerNV machine needs to implement a XICSFabric interface
as this is the POWER8 interrupt controller model. But the POWER9
machine uselessly inherits of XICSFabric from the common PowerNV
machine definition.
Open code machine definitions to have a better control on the
different interfa
02.10.2019 17:22, Andrey Shinkevich wrote:
> Support the data compression during block-stream job over a backup
> backing chain implemented in the following patch 'block-stream:
> add compress option'.
>
> Signed-off-by: Anton Nefedov
> Signed-off-by: Denis V. Lunev
> Signed-off-by: Andrey Shink
On Fri, 20 Sep 2019 15:43:47 +0800
Tao Xu wrote:
> From: Liu Jingqi
>
> This structure describes the memory access latency and bandwidth
> information from various memory access initiator proximity domains.
> The latency and bandwidth numbers represented in this structure
> correspond to rated
02.10.2019 17:22, Andrey Shinkevich wrote:
> Allow data compression during block-stream job for backup backing chain.
>
> Signed-off-by: Anton Nefedov
> Signed-off-by: Vladimir Sementsov-Ogievskiy
> Signed-off-by: Denis V. Lunev
> Signed-off-by: Andrey Shinkevich
> ---
> block/stream.c
Introduce support for GTree migration. A custom save/restore
is implemented. Each item is made of a key and a data. For that
reason, 2 VMSD objects are passed into the GTree VMStateField.
When putting the items, the tree is traversed in sorted order by
g_tree_foreach.
On the get() path, gtrees mu
02.10.2019 17:22, Andrey Shinkevich wrote:
> Add a test case to the iotest #030 that checks 'compress' option for a
> block-stream job.
>
> Signed-off-by: Andrey Shinkevich
> ---
> tests/qemu-iotests/030 | 49
> +-
> tests/qemu-iotests/030.out |
On Thu, Oct 03, 2019 at 04:54:31PM +0200, Eric Auger wrote:
> Introduce support for GTree migration. A custom save/restore
> is implemented. Each item is made of a key and a data. For that
> reason, 2 VMSD objects are passed into the GTree VMStateField.
>
> When putting the items, the tree is trav
On Thu, 3 Oct 2019 15:59:29 +0200
Cédric Le Goater wrote:
> On 03/10/2019 15:41, Greg Kurz wrote:
> > On Thu, 3 Oct 2019 15:19:22 +0200
> > Cédric Le Goater wrote:
> >
> >> On 03/10/2019 15:02, Greg Kurz wrote:
> >>> On Thu, 3 Oct 2019 14:58:45 +0200
> >>> Cédric Le Goater wrote:
> >>>
>
02.10.2019 1:16, John Snow wrote:
>
>
> On 10/1/19 3:46 PM, Max Reitz wrote:
>> We do not do anything with yet, but this is the first step.
>>
>> Signed-off-by: Max Reitz
>> ---
>> tests/qemu-iotests/iotests.py | 6 ++
>> 1 file changed, 6 insertions(+)
>>
>> diff --git a/tests/qemu-iotes
01.10.2019 22:46, Max Reitz wrote:
> We do not do anything with yet, but this is the first step.
>
> Signed-off-by: Max Reitz
> ---
> tests/qemu-iotests/iotests.py | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/tests/qemu-iotests/iotests.py b/tests/qemu-iotests/iotests.py
> in
01.10.2019 22:46, Max Reitz wrote:
> Signed-off-by: Max Reitz
> ---
> tests/qemu-iotests/iotests.py | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/tests/qemu-iotests/iotests.py b/tests/qemu-iotests/iotests.py
> index cdcb62c4ac..b5ea424de4 100644
> --- a/tests/q
01.10.2019 22:46, Max Reitz wrote:
> Signed-off-by: Max Reitz
> ---
> tests/qemu-iotests/iotests.py | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/tests/qemu-iotests/iotests.py b/tests/qemu-iotests/iotests.py
> index 7030900807..cdcb62c4ac 100644
> --- a/tests/qemu-iot
On Wed, 2 Oct 2019 at 00:56, John Snow wrote:
>
> The following changes since commit 7f21573c822805a8e6be379d9bcf3ad9effef3dc:
>
> Merge remote-tracking branch
> 'remotes/huth-gitlab/tags/pull-request-2019-10-01' into staging (2019-10-01
> 13:13:38 +0100)
>
> are available in the Git repositor
Since 4.18, KVM/ARM exposes a KVM_MAX_VCPUS equal to 512. However it was
reported [1] that a VM with more than 256 vcpus cannot be launched. 5.4
fixes the situation with 2 patches:
- one upgrade of the KVM_IRQ_LINE API [2] supporting a vcpu id encoded
on 12 bits,
- the reduction of KVM IO devices
1 - 100 of 191 matches
Mail list logo
