Hi,
> -Original Message-
> From: Paolo Bonzini [mailto:pbonz...@redhat.com]
> Sent: Friday, May 09, 2014 5:54 PM
> To: Gonglei (Arei); qemu-devel@nongnu.org
> Cc: m...@redhat.com; Herongguang (Stephen); Huangweidong (C)
> Subject: Re: [RFC] vhost: Can we change synchroni
Hi,
> -Original Message-
> From: Andreas Färber [mailto:afaer...@suse.de]
> Sent: Monday, May 12, 2014 3:09 PM
> To: Gonglei (Arei)
> Cc: qemu-devel@nongnu.org
> Subject: Re: [Qemu-devel] [Crucial bug] Qemu-2.0.0 do not support virtio-net
> hot plug/unplug exc
Hi,
> > diff --git a/hw/display/cirrus_vga.c b/hw/display/cirrus_vga.c
> > index d1afc76..399a2ef 100644
> > --- a/hw/display/cirrus_vga.c
> > +++ b/hw/display/cirrus_vga.c
> > @@ -2959,6 +2959,14 @@ static int pci_cirrus_vga_initfn(PCIDevice *dev)
> > PCIDeviceClass *pc = PCI_DEVICE_GET_CLA
Hi,
> > diff --git a/hw/display/cirrus_vga.c b/hw/display/cirrus_vga.c
> > index d1afc76..399a2ef 100644
> > --- a/hw/display/cirrus_vga.c
> > +++ b/hw/display/cirrus_vga.c
> > @@ -2959,6 +2959,14 @@ static int pci_cirrus_vga_initfn(PCIDevice *dev)
> > PCIDeviceClass *pc = PCI_DEVICE_GET_CLA
> -Original Message-
> From: Gerd Hoffmann [mailto:kra...@redhat.com]
> Sent: Friday, May 09, 2014 6:55 PM
> To: Gonglei (Arei)
> Cc: qemu-devel@nongnu.org; afaer...@suse.de; m...@redhat.com;
> pbonz...@redhat.com; Huangweidong (C); Blue Swirl
> Subject: Re: [PATC
Hi,
> -Original Message-
> From: Gerd Hoffmann [mailto:kra...@redhat.com]
> Sent: Friday, May 09, 2014 6:31 PM
> To: Gonglei (Arei)
> Cc: qemu-devel@nongnu.org; afaer...@suse.de; m...@redhat.com;
> pbonz...@redhat.com; Huangweidong (C); Blue Swirl
> Subject: Re: [PATC
Hi,
First, please forgive me for my bad English.
It's so sad.
> -Original Message-
> From: Ian Campbell [mailto:ian.campb...@citrix.com]
> Sent: Friday, May 09, 2014 5:57 PM
> To: Gonglei (Arei)
> Cc: Jan Beulich; xen-de...@lists.xen.org; anthony.per...@citrix.co
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Friday, May 09, 2014 5:36 PM
> To: Gonglei (Arei)
> Cc: anthony.per...@citrix.com; ian.campb...@citrix.com;
> stefano.stabell...@eu.citrix.com; johannes.kra...@googlemail.com; Gaowei
> (UV
Hi, Ian
> -Original Message-
> From: Ian Campbell [mailto:ian.campb...@citrix.com]
> Sent: Friday, May 09, 2014 5:05 PM
> To: Gonglei (Arei)
> Cc: qemu-devel@nongnu.org; xen-de...@lists.xen.org; jbeul...@suse.com;
> stefano.stabell...@eu.citrix.com; fabio.fant...@m2r.
Hi,
> -Original Message-
> From: Paolo Bonzini [mailto:pbonz...@redhat.com]
> Sent: Friday, May 09, 2014 4:15 PM
> To: Gonglei (Arei); qemu-devel@nongnu.org
> Cc: m...@redhat.com; Herongguang (Stephen); Huangweidong (C)
> Subject: Re: [RFC] vhost: Can we change synchroni
Hi,
> -Original Message-
> From: Ian Campbell [mailto:ian.campb...@citrix.com]
> Sent: Thursday, May 08, 2014 7:22 PM
> To: Gonglei (Arei)
> Cc: qemu-devel@nongnu.org; xen-de...@lists.xen.org; jbeul...@suse.com;
> stefano.stabell...@eu.citrix.com; fabio.fant...@m2r.
Hi,
> -Original Message-
> From: Gerd Hoffmann [mailto:kra...@redhat.com]
> Sent: Friday, May 09, 2014 2:49 PM
> To: Gonglei (Arei)
> Cc: qemu-devel@nongnu.org
> Subject: Re: [Bug] cirrus_vga: qemu abort at booting when configure
> vgamem_mb <= 2
>
> On
Hi,
> -Original Message-
> From: Michael R. Hines [mailto:mrhi...@linux.vnet.ibm.com]
> Sent: Tuesday, April 01, 2014 8:42 AM
> To: Gonglei (Arei); qemu-devel@nongnu.org
> Cc: Huangweidong (C); quint...@redhat.com; dgilb...@redhat.com;
> owass...@redhat.com; mrhi...@us.
Hi, Gerd
The issue consequentially occur, I have tested various qemu versions,
including the current qemu.git.
Any ideas? Thanks.
The command line:
./x86_64-softmmu/qemu-system-x86_64 -enable-kvm -m 4096 -smp 4 -name sles \
-boot c -drive file=/mnt/sdb/gonglei/image/sles.img -vnc 0.0.0.0:10
Hi,
Vhost devices need to do VHOST_SET_MEM_TABLE ioctl in vhost_dev_start()
to tell vhost kernel modules GPA to HVA memory mappings, which consume is
expensively.
The reason is same as KVM_SET_GSI_ROUTING ioctl. That is, in ioctl processing,
kmod and vhost calls synchronize_rcu() to wait for gr
Hi,
> -Original Message-
> From: Paolo Bonzini [mailto:pbonz...@redhat.com]
> Sent: Thursday, May 08, 2014 8:49 PM
> To: Gonglei (Arei); qemu-devel@nongnu.org
> Cc: r...@twiddle.net; peter.mayd...@linaro.org; m...@redhat.com;
> chris.frie...@windriver.com; Huangweidon
Hi,
> -Original Message-
> From: Fabio Fantoni [mailto:fabio.fant...@m2r.biz]
> Sent: Thursday, May 08, 2014 4:17 PM
> To: Gonglei (Arei); qemu-devel@nongnu.org; xen-de...@lists.xen.org
> Cc: ian.campb...@citrix.com; jbeul...@suse.com;
> stefano.stabell...@eu.citri
Hi, all
> -Original Message-
> From: Michael S. Tsirkin [mailto:m...@redhat.com]
> Sent: Thursday, May 08, 2014 4:15 AM
> To: Konrad Rzeszutek Wilk
> Cc: Gonglei (Arei); qemu-devel@nongnu.org; xen-de...@lists.xen.org;
> Huangweidong (C); ian.campb...@citrix.co
Hi,
> >> In Xen platform, after using upstream qemu, the all of pci devices will
> >> show
> >> hotplug in the windows guest. In this situation, the windows guest may
> occur
> >> blue screen when VM' user click the icon of VGA card for trying unplug VGA
> >> card.
> >> However, we don't hope VM'
Hi,
> Subject: Re: [Qemu-devel] virtio-serial-pci very expensive during live
> migration
>
> Il 06/05/2014 22:01, Chris Friesen ha scritto:
> >
> > It seems like the main problem is that we loop over all the queues,
> > calling virtio_pci_set_host_notifier_internal() on each of them. That
> >
Hi, all
Ping...anyone? Thanks!
Best regards,
-Gonglei
> -Original Message-
> From: Gonglei (Arei)
> Sent: Sunday, May 04, 2014 5:25 PM
> To: qemu-devel@nongnu.org; xen-de...@lists.xen.org
> Cc: ian.campb...@citrix.com; jbeul...@suse.com;
> stefano.stabell...@eu.citr
Hi,
> -Original Message-
> From: Andreas Färber [mailto:afaer...@suse.de]
> Sent: Tuesday, May 06, 2014 9:58 PM
> To: Gonglei (Arei)
> Cc: Markus Armbruster; Hani Benhabiles; Peter Maydell; Paolo Bonzini;
> Michael S. Tsirkin; qemu-devel@nongnu.org
> Subject: Re:
>
> Am 06.05.2014 14:52, schrieb Gonglei (Arei):
> > Step 1: I executed "device_add virtio-net-pci,id=net1"
> > with "info pci", I found the net1, showing as below:
> > Bus 0, device 4, function 0:
> > Ethernet controller: PCI device
> >> > > Il 26/04/2014 10:56, Gonglei (Arei) ha scritto:
> >> > > > Public bug reported:
> >> > > >
> >> > > > I want to repeated hot-plug/unplug the virtio-net in the latest qemu
> >> > > upstream
> >> &g
Hi,
> > > Il 26/04/2014 10:56, Gonglei (Arei) ha scritto:
> > > > Public bug reported:
> > > >
> > > > I want to repeated hot-plug/unplug the virtio-net in the latest qemu
> > > upstream
> > > > (commit 839a5547574e57cce62f49bfc50
Hi, all
Cc'ing Michael S. Tsirkin for adding his two files: acpi_extract.py/
acpi_extract_preprocess.py.
Best regards,
-Gonglei
> -Original Message-
> From: Gonglei (Arei)
> Sent: Sunday, May 04, 2014 5:25 PM
> To: qemu-devel@nongnu.org; xen-de...@lists.xen.or
Hi,
Ping, what's the patch sets status? Thanks.
Best regards,
-Gonglei
> -Original Message-
> From: Dr. David Alan Gilbert [mailto:dgilb...@redhat.com]
> Sent: Saturday, April 05, 2014 1:41 AM
> To: Eric Blake
> Cc: Gonglei (Arei); qemu-devel@nongnu.org; quint...
14 15:32, Fabio Fantoni ha scritto:
> >>>> Il 28/10/2013 10:38, Jan Beulich ha scritto:
> >>>>>>>> On 24.10.13 at 14:17, "Gonglei (Arei)"
> >>>>>>>> wrote:
> >>>>>> Now I test the patch based on the cod
Hi,
> -Original Message-
> From: Gerd Hoffmann [mailto:kra...@redhat.com]
> Sent: Monday, April 28, 2014 9:35 PM
> To: Gonglei (Arei)
> Cc: qemu-devel@nongnu.org; Huangweidong (C)
> Subject: Re: [PATCH] uhci: Lower uhci timer freq when guest is idle
>
> On Mo, 2
Hi, Gerd.
What's your opinion about this issue? Thanks!
Best regards,
-Gonglei
> -Original Message-
> From: Gonglei (Arei)
> Sent: Wednesday, March 26, 2014 4:15 PM
> To: 'Gerd Hoffmann'
> Cc: qemu-devel@nongnu.org; Huangweidong (C)
> Subject: RE: [P
t; Il 28/10/2013 10:38, Jan Beulich ha scritto:
> > >>>>> On 24.10.13 at 14:17, "Gonglei (Arei)"
> > >>>>> wrote:
> > >>> Now I test the patch based on the codes of trunk, which works well.
> > >>> The patch has be
Hi,
> Il 26/04/2014 10:56, Gonglei (Arei) ha scritto:
> > Public bug reported:
> >
> > I want to repeated hot-plug/unplug the virtio-net in the latest qemu
> upstream
> > (commit 839a5547574e57cce62f49bfc50fe1f04b00589a), but I am failed at
> the
> > secon
Hi,
> > >
> > > Why we can't break keyboard by flooding input after boot up?
> > >
> > Actually, I have pointed the root reason about this issue in other email.
> >
> > When the linux kernel booting, will init the i8042 controller
> (drivers/input/serio/i8042.c), and
> > check the i8042 controller
Hi,
Public bug reported:
I want to repeated hot-plug/unplug the virtio-net in the latest qemu upstream
(commit 839a5547574e57cce62f49bfc50fe1f04b00589a), but I am failed at the
second time hot plug the virtio-net to guest.
Then I tried to use Qemu-2.0.0 release version, but I got the error too.
Hi,
> On Thu, Apr 24, 2014 at 08:06:19PM +0800, arei.gong...@huawei.com wrote:
> > From: Gonglei
> >
> > According to the PS/2 Mouse/Keyboard Protocol, the keyboard outupt buffer
> size
> > is 16 bytes. And the PS2_QUEUE_SIZE 256 was introduced in Qemu from the
> very
> > beginning.
> >
> > When
Hi,
> On Do, 2014-04-24 at 20:06 +0800, arei.gong...@huawei.com wrote:
> > From: Gonglei
> >
> > According to the PS/2 Mouse/Keyboard Protocol, the keyboard outupt buffer
> size
> > is 16 bytes. And the PS2_QUEUE_SIZE 256 was introduced in Qemu from the
> very
> > beginning.
>
> Hmm, seems there
Hi, Gerd.
>
> > if (!(s->mouse_status & MOUSE_STATUS_REMOTE) &&
> > -(s->common.queue.count < (PS2_QUEUE_SIZE - 16))) {
> > +(s->common.queue.count < PS2_QUEUE_SIZE - 4)) {
> > for(;;) {
>
> Almost there.
>
> The check for enougth space in the queue should be for ev
Hi, Gerd.
> > if (!(s->mouse_status & MOUSE_STATUS_REMOTE) &&
> > -(s->common.queue.count < (PS2_QUEUE_SIZE - 16))) {
> > +(s->common.queue.count < PS2_QUEUE_SIZE)) {
>
> To me this looks like an attempt to make sure the queue has enough space
> for the whole mouse message.
> Hi,
>
> > Move the check into ps2_mouse_send_packet() is not a good idea.
> > In that case, we cannot break the for loop except we change the return value
> > of ps2_mouse_send_packet().
>
> Changing the return value is fine IMO.
>
OK. Change it in v3. Could you review the v2 about other cod
> Subject: Re: [PATCH] ps2: set ps/2 output buffer size as the same as kernel
>
> > @@ -137,7 +139,7 @@ void ps2_queue(void *opaque, int b)
> > PS2State *s = (PS2State *)opaque;
> > PS2Queue *q = &s->queue;
> >
> > -if (q->count >= PS2_QUEUE_SIZE)
> > +if (q->count >= PS2_QUEUE_S
Hi,
> Subject: Re: [PATCH RFC] ps2: set the keybord output buffer size as the same
> as
>
> > So do you agree with my method to address the issue?
>
> Using a temporary buffer is fine, simple and save choice. For the
> second copy you can use a simple memcpy instead of the loop.
>
Okay, I wil
>
> Hi,
>
> > > Completely separate question: Have you figured what the root cause for
> > > the bug is?
> >
> > > While wading through the code I've figured the queue size
> > > isn't (directly) exposed to the guest.
>
> > The process correspond with the above linux kernel code, i8042_flush(
>
> Hi,
>
> > > > if (++q->rptr == 256) {
> > > > q->rptr = 0;
> > > > }
> > > > }
> > >
> > > That fails for the wraparound (rptr > wptr) case.
> > >
> > Yep, it should use a temporary data array to transfer, which I have written
> > in the previous email.
>
>
>
> Hi,
>
> > /* the new version id for this patch */
> > if (version_id == 4) {
> > return 0;
> > }
>
> I don't think we need a new version.
>
OK.
> > /* set the useful data buffer queue size, < PS2_QUEUE_SIZE */
> > size = MIN(q->count, PS2_QUEUE_SIZE);
>
> I'd
>
> "Gonglei (Arei)" wrote:
> >> Hi,
> >>
> >> > Anything bigger than 16bytes, no? And that is the whole point that we
> >> > are talking about? Or the 16bytes that we are using can be at any place
> >> > on the buffer?
&g
> Hi,
>
> > Anything bigger than 16bytes, no? And that is the whole point that we
> > are talking about? Or the 16bytes that we are using can be at any place
> > on the buffer?
>
> Yes. It's a ring buffer, with rptr pointing to the first used element
> and wptr pointing to the first free ele
> Gerd Hoffmann wrote:
> > On Mi, 2014-04-23 at 09:32 +, Gonglei (Arei) wrote:
> >> >
> >> > Hi, Gerd and Juan.
> >> >
> >> > Thanks for your guides about the confuse live migration about changing
> the
> >> > keyboa
> On Mi, 2014-04-23 at 08:06 +0000, Gonglei (Arei) wrote:
> > Hi, Gerd and Juan.
> >
> > Thanks for your guides about the confuse live migration about changing the
> keyboard buffer size.
> > According your suggestion, I got two solutions to address the issue:
>
>
> Hi, Gerd and Juan.
>
> Thanks for your guides about the confuse live migration about changing the
> keyboard buffer size.
> According your suggestion, I got two solutions to address the issue:
>
> - Keep the data array 256 bytes long, change the rptr/wptr/count/data array at
> post_load(),
nglei
> -Original Message-
> From: Juan Quintela [mailto:quint...@redhat.com]
> Sent: Tuesday, April 22, 2014 8:05 PM
> To: Gerd Hoffmann
> Cc: Gonglei (Arei); qemu-devel@nongnu.org; aligu...@amazon.com;
> Huangweidong (C)
> Subject: Re: [PATCH RFC] ps2: set the keybord output buf
>
> > diff --git a/hw/input/ps2.c b/hw/input/ps2.c
> > index 3412079..a754fef 100644
> > --- a/hw/input/ps2.c
> > +++ b/hw/input/ps2.c
> > @@ -71,7 +71,7 @@
> > #define MOUSE_STATUS_ENABLED0x20
> > #define MOUSE_STATUS_SCALE210x10
> >
> > -#define PS2_QUEUE_SIZE 256
> > +#define PS2_QUEU
Hi,
> -Original Message-
> From: Gonglei (Arei)
> Sent: Thursday, April 17, 2014 9:16 PM
> To: qemu-devel@nongnu.org
> Cc: kra...@redhat.com; aligu...@amazon.com; Huangweidong (C); Gonglei
> (Arei)
> Subject: [PATCH RFC] ps2: set the keybord output buffer size as
Hi, Gerd.
IMHO, the usb-ehci controller as a common PCI device, likes NIC.
If we don't use the multifunction capability of EHCI, we should support to hot
plug / unplug
Usb-ehci controller. And I think the Bug 879096 is just a bug. Am I right?
Thanks.
The patch:
http://lists.gnu.org/arch
Hi,
I'm using qemu-ga.exe in windows server 2008 R2 64.
I want to use it without libraries such as iconv.dll, libglib-2.0-0.dll,
libintl-8.dll and libssp-0.dll
So I use static compilation on fedora 18.
build qemu-1.7.0:
# for Windows using MinGW on linux (Fedora 18)
./configure --enable-gues
> On Wed, Apr 09, 2014 at 10:56:57AM +0000, Gonglei (Arei) wrote:
> > Hi,
> >
> > > > QEMU only mmap MSIX_PAGE_SIZE memory for all pci devices in
> > > > assigned_dev_register_msix_mmio(), meanwhile the set the one
> > > > page memmo
> On 04/03/14 07:18, arei.gong...@huawei.com wrote:
> > From: Gonglei
> >
> > QEMU only mmap MSIX_PAGE_SIZE memory for all pci devices in
> > assigned_dev_register_msix_mmio(), meanwhile the set the one
> > page memmory to zero, so the rest memory will be random value
> > (maybe etnry.data is not
Hi,
> > QEMU only mmap MSIX_PAGE_SIZE memory for all pci devices in
> > assigned_dev_register_msix_mmio(), meanwhile the set the one
> > page memmory to zero, so the rest memory will be random value
> > (maybe etnry.data is not 0). In the assigned_dev_update_msix_mmio()
> > maybe occur the issue o
Hi, mst and alex.
Ping... These two bug fix can be accepted for KVM pci-assign ? Thanks.
BTW, I have finished the testing work of the Emulex Corporation
OneConnect NIC (Lancer) Nic by vfio-pci, and the pass-troughed VF works well.
My environment of testing as follows:
Host: 3.12.16-0.6.6-defa
> Subject: Re: [Qemu-devel] [PATCH v4 5/8] XBZRLE: optimize XBZRLE to
> decrease the cache misses
>
> I've got a world with just patches 1..5 on that's seeing corruptions, but
> I've not seen where the problem is. So far the world with 1..4 on hasn't
> hit those corruption, but maybe I need to te
Hi,
> > >
> > Actually I move the judge in function assigned_dev_register_msix_mmio.
> > Because assigned_dev_register_msix_mmio do not address the return value,
> > if dev->msix_table is null, this will result a segfault. Right?
>
> I see the confusion, there is a bug there but I think it should
> > Hi,
> >
> > I have a problem about SR-IOV pass-through.
> >
> > The PF is Emulex Corporation OneConnect NIC (Lancer)(rev 10),
> > and the VF pci config is as follow:
> >
> > LINUX:/sys/bus/pci/devices/:04:00.6 # hexdump config
> > 000 0010 0010 0200 0080
> > 010
> > Hi,
> >
> > I have a problem about SR-IOV pass-through.
> >
> > The PF is Emulex Corporation OneConnect NIC (Lancer)(rev 10),
> > and the VF pci config is as follow:
> >
> > LINUX:/sys/bus/pci/devices/:04:00.6 # hexdump config
> > 000 0010 0010 0200 0080
> > 010
Hi,
I have a problem about SR-IOV pass-through.
The PF is Emulex Corporation OneConnect NIC (Lancer)(rev 10),
and the VF pci config is as follow:
LINUX:/sys/bus/pci/devices/:04:00.6 # hexdump config
000 0010 0010 0200 0080
010 0
Hi,
I'm learning qemu ga from wiki
http://wiki.qemu.org/Features/QAPI/GuestAgent
qemu-ga.exe is running in my windows VM now, and I want to debug it step by
step.
Could anyone specify how to debug in windows ? Thanks.
Best regards,
-Gonglei
> > If the networking break or there's something wrong with rdma
> > device(ib0 with no IP) during rdma migration, the main_loop of
> > qemu will be blocked in rdma_destroy_id. I add rdma_ack_cm_event
> > to fix this bug.
> >
> > Signed-off-by: Mo Yuxiang
> > Signed-off-by: Gonglei
> > ---
> >
Hi,
My patch
http://git.qemu.org/?p=qemu.git;a=commitdiff;h=e3c1adf16e38714ebd761dd02517dd07760ba6d2
had been fixed this issue.
Best regards,
-Gonglei
From: qemu-devel-bounces+arei.gonglei=huawei@nongnu.org
[mailto:qemu-devel-bounces+arei.gonglei=huawei@nongnu.org] On Behalf Of
Caizhi
>
> Hi Gonglei,
>
> I've got a world which has this patch series on, and it's producing some
> XBZRLE
> errors,
> and I suspect that it's down to my original worries of running
> xbzrle_encode_buffer
> on changing data.
>
> My setup is a pair of machines, with a guest with 4GB RAM running SPECj
> > >> Return error for migrate cancel, when migration status is not
> > >> MIG_STATE_SETUP or MIG_STATE_ACTIVE. Thus, libvirt can can
> > >> perceive the operation fails.
> > >>
> > >> Signed-off-by: zengjunliang
> > >> Signed-off-by: Gonglei
> > >
> > > I think this is done on purpose, because
> > arch_init.c | 25 +
> > 1 file changed, 13 insertions(+), 12 deletions(-)
>
> Should this patch be included in 2.0 as a bug fix? The rest of the
> series is probably better off in 2.1.
>
Yes, it should be, but I am not so clear how to do it.
Eric, Could you give me
> On my system I have HZ=100 and lots of CPUs. So RCUs "every cpu has
> scheduled"
> is certainly slower than SRCUs algorithm
> (/*
> * We use an adaptive strategy for synchronize_srcu() and especially for
> * synchronize_srcu_expedited(). We spin for a fixed time period
> * (defined below) to
> > Based on discussions in:
> > http://lists.gnu.org/archive/html/qemu-devel/2013-11/threads.html#03322
> >
> > About KVM_SET_GSI_ROUTING ioctl, I tested changing RCU to SRCU, but
> unfortunately
> > it looks like SRCU's grace period is no better than RCU.
>
> Really? This is not what Christian
> -Original Message-
> From: Gerd Hoffmann [mailto:kra...@redhat.com]
> Sent: Wednesday, March 26, 2014 3:59 PM
> To: Gonglei (Arei)
> Cc: qemu-devel@nongnu.org; Huangweidong (C)
> Subject: Re: [PATCH] uhci: Lower uhci timer freq when guest is idle
>
> On Mi, 2
Hi,
I also encounter the same problem. When I use the Qemu mainline and with
-machine pc-i440fx-2.0, the win7 guest will show blue screen, and give me
"The BIOS in this system is not fully ACPI compliant. Please contact your system
Vendor for an updated BIOS.
Technical information:
*** STOP: 0x
Hi,
I also encounter the same problem. When I use the Qemu mainline and with
-machine pc-i440fx-2.0, the win7 guest will show blue screen, and give me
"The BIOS in this system is not fully ACPI compliant. Please contact your system
Vendor for an updated BIOS.
Technical information:
*** STOP: 0x
> -Original Message-
> From: Eric Blake [mailto:ebl...@redhat.com]
> Sent: Tuesday, March 25, 2014 12:01 AM
> To: Paolo Bonzini; Gonglei (Arei); qemu-devel@nongnu.org
> Cc: quint...@redhat.com; owass...@redhat.com; Yanqiangjun; Zhaoyanbin
> (A); Zengjunliang; libv
Hi,
Based on discussions in:
http://lists.gnu.org/archive/html/qemu-devel/2013-11/threads.html#03322
About KVM_SET_GSI_ROUTING ioctl, I tested changing RCU to SRCU, but
unfortunately
it looks like SRCU's grace period is no better than RCU. I haven't got any idea
why this, but I suppose the te
> Subject: [PATCH v2 2/2] Init the XBZRLE.lock in ram_mig_init
>
> From: "Dr. David Alan Gilbert"
>
> Initialising the XBZRLE.lock earlier simplifies the lock use.
>
> Based on Markus's patch in:
> http://lists.gnu.org/archive/html/qemu-devel/2014-03/msg03879.html
>
> Signed-off-by: Dr. David
> Subject: [PATCH v2 1/2] Provide init function for ram migration
>
> From: "Dr. David Alan Gilbert"
>
> Provide ram_mig_init (like blk_mig_init) for vl.c to initialise stuff
> to do with ram migration (currently in arch_init.c).
>
> Signed-off-by: Dr. David Alan Gilbert
> ---
> arch_init.c
> < 'already got some feedback earlier on this and had this task in the
> list of things
> to work on... :) >
>
> Having the throttling start with some per-defined "degree" and then have
> that "degree" gradually increase ...either
>
> a) automatically as shown in Juan's example above (or
Sorry for late.
>
> > @@ -161,6 +171,11 @@ int cache_insert(PageCache *cache, uint64_t addr,
> const uint8_t *pdata)
> > /* actual update of entry */
> > it = cache_get_by_addr(cache, addr);
> >
> > +if ((it->it_data != NULL) && (it->it_age +
> > +CACHED_PAGE_LIFETIME > cur
> On 03/11/2014 06:53 AM, arei.gong...@huawei.com wrote:
> > From: ChenLiang
> >
> > Add counters to log the times of updating the dirty bitmap.
> >
> > Signed-off-by: ChenLiang
> > Signed-off-by: Gonglei
> > Reviewed-by: Dr. David Alan Gilbert
> > Reviewed-by: Eric Blake
>
> Wait - how did m
Hi,
Recently I found that when doing migration on a VM with many Virtio NICs,
a lot down time was consuming in vm_state_notify(). Further investigation
shows major consumption is in function memory_region_del_eventfd(). When
deletes an
ioeventfd, in address space transactions commit, it begin
> -Original Message-
> From: qemu-devel-bounces+arei.gonglei=huawei@nongnu.org
> [mailto:qemu-devel-bounces+arei.gonglei=huawei@nongnu.org] On
> Behalf Of Jason Wang
> Sent: Friday, February 21, 2014 5:05 PM
> To: aligu...@amazon.com; m...@redhat.com; qemu-devel@nongnu.org
> Cc: Pao
a. Optimization the xbzrle remarkable decrease the cache misses.
The efficiency of compress increases more than fifty times.
Before the patch set, the cache almost totally miss when the
number of cache item less than the dirty page number. Now the
hot pages in the cache will not be
Reducing data copy can reduce cpu overheah.
Signed-off-by: ChenLiang
Signed-off-by: Gonglei
---
arch_init.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/arch_init.c b/arch_init.c
index 2211e0b..cc88875 100644
--- a/arch_init.c
+++ b/arch_init.c
@@ -344,11 +344,8 @
delete death code.
Signed-off-by: ChenLiang
Signed-off-by: Gonglei
---
arch_init.c | 13 -
1 file changed, 13 deletions(-)
diff --git a/arch_init.c b/arch_init.c
index cc88875..12fbcea 100644
--- a/arch_init.c
+++ b/arch_init.c
@@ -178,13 +178,10 @@ static inline bool is_zero_range
Rebuild the cache_is_cached function.
Signed-off-by: ChenLiang
Signed-off-by: Gonglei
---
page_cache.c | 33 +++--
1 file changed, 15 insertions(+), 18 deletions(-)
diff --git a/page_cache.c b/page_cache.c
index fa58ab2..34ec933 100644
--- a/page_cache.c
+++ b/page_
It is inaccuracy and complex that using the transfer speed of
migration thread to determine whether the convergence migration.
The dirty page may be compressed by XBZRLE or ZERO_PAGE.The counter
of updating dirty bitmap will be increasing continuously if the
migration can't convergence.
Signed-off
The page may not be inserted into cache after executing save_xbzrle_page.
In case of failure to insert, the original page should be sent rather
than the page in the cache.
Signed-off-by: ChenLiang
Signed-off-by: Gonglei
---
arch_init.c | 25 +
1 file changed, 13 insertio
Avoid the hot pages cache replacing by others to remarkable decrease cache
missing. The counter of updating dirty bitmap is used to indicate the cached
page age.
Signed-off-by: ChenLiang
Signed-off-by: Gonglei
---
arch_init.c| 8 +---
include/migration/page_cache.h | 8
Add counters to log the times of updating the dirty bitmap.
Signed-off-by: ChenLiang
Signed-off-by: Gonglei
---
arch_init.c | 20
1 file changed, 20 insertions(+)
diff --git a/arch_init.c b/arch_init.c
index bc8d0eb..6823c5a 100644
--- a/arch_init.c
+++ b/arch_init.c
@@ -1
Hi, Juan. Thanks for your review.
> -Original Message-
> From: Juan Quintela [mailto:quint...@redhat.com]
> Sent: Tuesday, February 25, 2014 11:25 PM
> To: Gonglei (Arei)
> Cc: qemu-devel@nongnu.org; Dr. David Alan Gilbert; owass...@redhat.com;
> chenliang (T); Huangwei
Resizing the xbzrle cache during migration causes qemu-crash,
because the main-thread and migration-thread modify the xbzrle
cache size concurrently without lock-protection.
Signed-off-by: ChenLiang
Signed-off-by: Gonglei
Reviewed-by: Dr. David Alan Gilbert
---
Changes against the previous vers
> -Original Message-
> From: Dr. David Alan Gilbert [mailto:dgilb...@redhat.com]
> Sent: Friday, February 21, 2014 8:10 PM
> To: Gonglei (Arei)
> Cc: qemu-devel@nongnu.org; Juan Quintela; owass...@redhat.com;
> chenliang (T)
> Subject: Re: [PATCH v2] XBZRLE: Fix qemu
Hi,
> -Original Message-
> From: Dr. David Alan Gilbert [mailto:dgilb...@redhat.com]
> Sent: Friday, February 21, 2014 7:04 PM
> To: Gonglei (Arei)
> Cc: qemu-devel@nongnu.org; Juan Quintela; owass...@redhat.com;
> chenliang (T)
> Subject: Re: [PATCH v2] XBZRLE: Fix q
Resizing the xbzrle cache during migration causes qemu-crash,
because the main-thread and migration-thread modify the xbzrle
cache size concurrently without lock-protection.
Signed-off-by: ChenLiang
Signed-off-by: Gonglei
---
Changes against the previous version:
*Remove function cache_max_num_
> -Original Message-
> From: Dr. David Alan Gilbert [mailto:dgilb...@redhat.com]
> Sent: Wednesday, February 19, 2014 6:54 PM
> To: Gonglei (Arei)
> Cc: qemu-devel@nongnu.org; Peter Maydell; chenliang (T); Juan Quintela;
> Luonengjun; owass...@redhat.com; Huangweidong (H
It is likely to crash qemu when resize the xbzrle cache
during migration. Because the xbzrle cache will be modified
by migration thread and resize thread.
Test scene
step one: set the size of xbzrle cache 1GB.
step two: migrate vm which dirty memory continuously.
step three: set the size of xbzrle
> -Original Message-
> From: Dr. David Alan Gilbert [mailto:dgilb...@redhat.com]
> Sent: Friday, February 14, 2014 5:35 PM
> To: Gonglei (Arei)
> Cc: qemu-devel@nongnu.org; owass...@redhat.com; quint...@redhat.com
> Subject: Re: [Qemu-devel] [PATCH] Fix two XBZRLE
Best regards,
-Gonglei
> -Original Message-
> From: qemu-devel-bounces+arei.gonglei=huawei@nongnu.org
> [mailto:qemu-devel-bounces+arei.gonglei=huawei@nongnu.org] On
> Behalf Of Dr. David Alan Gilbert (git)
> Sent: Friday, February 14, 2014 3:45 AM
> To: qemu-devel@nongnu.org
801 - 900 of 954 matches
Mail list logo
