Hi Daniel,
> -Original Message-
> From: Daniel P. Berrangé [mailto:berra...@redhat.com]
> Sent: Friday, June 7, 2024 5:04 PM
> To: Gonglei (Arei)
> Cc: qemu-devel@nongnu.org; pet...@redhat.com; yu.zh...@ionos.com;
> mgal...@akamai.com; elmar.ger...@ionos.com;
Hi,
> -Original Message-
> From: Peter Xu [mailto:pet...@redhat.com]
> Sent: Thursday, June 6, 2024 5:19 AM
> To: Dr. David Alan Gilbert
> Cc: Michael Galaxy ; zhengchuan
> ; Gonglei (Arei) ;
> Daniel P. Berrangé ; Markus Armbruster
> ; Yu Zhang ; Zhijian Li
> -Original Message-
> From: Peter Xu [mailto:pet...@redhat.com]
> Sent: Wednesday, June 5, 2024 10:19 PM
> To: Gonglei (Arei)
> Cc: qemu-devel@nongnu.org; yu.zh...@ionos.com; mgal...@akamai.com;
> elmar.ger...@ionos.com; zhengchuan ;
> berra...@redhat.com; arm.
> -Original Message-
> From: Haris Iqbal [mailto:haris.iq...@ionos.com]
> Sent: Thursday, June 6, 2024 9:35 PM
> To: Gonglei (Arei)
> Cc: qemu-devel@nongnu.org; pet...@redhat.com; yu.zh...@ionos.com;
> mgal...@akamai.com; elmar.ger...@ionos.com; zhengchuan
> ; ber
> -Original Message-
> From: Jinpu Wang [mailto:jinpu.w...@ionos.com]
> Sent: Friday, June 7, 2024 1:54 PM
> To: Gonglei (Arei)
> Cc: qemu-devel@nongnu.org; pet...@redhat.com; yu.zh...@ionos.com;
> mgal...@akamai.com; elmar.ger...@ionos.com; zhengchuan
> ; ber
Hi Peter,
> -Original Message-
> From: Peter Xu [mailto:pet...@redhat.com]
> Sent: Wednesday, June 5, 2024 3:32 AM
> To: Gonglei (Arei)
> Cc: qemu-devel@nongnu.org; yu.zh...@ionos.com; mgal...@akamai.com;
> elmar.ger...@ionos.com; zhengchuan ;
> berra...@redhat.c
> -Original Message-
> From: David Hildenbrand [mailto:da...@redhat.com]
> Sent: Tuesday, June 4, 2024 10:02 PM
> To: Gonglei (Arei) ; qemu-devel@nongnu.org
> Cc: pet...@redhat.com; yu.zh...@ionos.com; mgal...@akamai.com;
> elmar.ger...@ionos.com; zhengchuan ;
> ber
> -Original Message-
> From: Michael S. Tsirkin [mailto:m...@redhat.com]
> Sent: Wednesday, June 5, 2024 3:57 PM
> To: Gonglei (Arei)
> Cc: qemu-devel@nongnu.org; pet...@redhat.com; yu.zh...@ionos.com;
> mgal...@akamai.com; elmar.ger...@ionos.com; zhengchuan
>
From: Jialin Wang
Hi,
This patch series attempts to refactor RDMA live migration by
introducing a new QIOChannelRDMA class based on the rsocket API.
The /usr/include/rdma/rsocket.h provides a higher level rsocket API
that is a 1-1 match of the normal kernel 'sockets' API, which hides the
From: Jialin Wang
Signed-off-by: Jialin Wang
Signed-off-by: Gonglei
---
migration/multifd.c | 10 ++
migration/rdma.c| 27 +++
migration/rdma.h| 6 ++
3 files changed, 43 insertions(+)
diff --git a/migration/multifd.c b/migration/multifd.c
index
always, potentially leave the qemu hanging. So we need be cautious
to avoid hanging when using io_create_watch .
Luckily, channel-rdma works well in coroutines :)
Signed-off-by: Jialin Wang
Signed-off-by: Gonglei
---
include/io/channel-rdma.h | 15 +-
io/channel-rdma.c | 363
From: Jialin Wang
Implement a QIOChannelRDMA subclass that is based on the rsocket
API (similar to socket API).
Signed-off-by: Jialin Wang
Signed-off-by: Gonglei
---
include/io/channel-rdma.h | 152 +
io/channel-rdma.c | 437 ++
io
From: Jialin Wang
Signed-off-by: Jialin Wang
Signed-off-by: Gonglei
---
migration/meson.build | 2 +
migration/migration.c | 11 +-
migration/rdma.c | 88 +++
migration/rdma.h | 24
4 files changed, 124 insertions(+), 1
From: Jialin Wang
Signed-off-by: Jialin Wang
Signed-off-by: Gonglei
---
tests/unit/meson.build| 1 +
tests/unit/test-io-channel-rdma.c | 276 ++
2 files changed, 277 insertions(+)
create mode 100644 tests/unit/test-io-channel-rdma.c
diff --git
tion, and then use verbs to transmit data.
> > > > >
> > > > > rdma_cm and ibverbs create two FDs respectively. The two FDs
> > > > > have different responsibilities. rdma_cm fd is used to notify
> > > > > connection establishment events, and verbs fd is used to notify
> > > > > new CQEs. When
> > > poll/epoll monitoring is directly performed on the rdma_cm fd, only
> > > a pollin event can be monitored, which means that an rdma_cm event
> > > occurs. When the verbs fd is directly polled/epolled, only the
> > > pollin event can be listened, which indicates that a new CQE is generated.
> > > > >
> > > > > Rsocket is a sub-module attached to the rdma_cm library and
> > > > > provides rdma calls that are completely similar to socket interfaces.
> > > > > However, this library returns only the rdma_cm fd for listening
> > > > > to link
> > > setup-related events and does not expose the verbs fd (readable and
> > > writable events for listening to data). Only the rpoll interface
> > > provided by the RSocket can be used to listen to related events.
> > > However, QEMU uses the ppoll interface to listen to the rdma_cm fd
> (gotten by raccept API).
> > > > > And cannot listen to the verbs fd event.
> I'm confused, the rs_poll_arm
> :https://github.com/linux-rdma/rdma-core/blob/master/librdmacm/rsocket.c#
> L3290
> For STREAM, rpoll setup fd for both cq fd and cm fd.
>
Right. But the question is QEMU do not use rpoll but gilb's ppoll. :(
Regards,
-Gonglei
> -Original Message-
> From: Jinpu Wang [mailto:jinpu.w...@ionos.com]
> Sent: Wednesday, May 29, 2024 5:18 PM
> To: Gonglei (Arei)
> Cc: Greg Sword ; Peter Xu ;
> Yu Zhang ; Michael Galaxy ;
> Elmar Gerdes ; zhengchuan
> ; Daniel P. Berrangé ;
> Markus Armbr
:
> >
> > On Wed, May 29, 2024 at 4:43 AM Gonglei (Arei)
> wrote:
> > >
> > > Hi,
> > >
> > > > -Original Message-
> > > > From: Peter Xu [mailto:pet...@redhat.com]
> > > > Sent: Tuesday, May 28, 2024 11:55 PM
cket interfaces. However, this library returns
only the rdma_cm fd for listening to link setup-related events and does not
expose the verbs fd (readable and writable events for listening to data). Only
the rpoll
interface provided by the RSocket can be used to listen to related events.
However, QEMU uses the ppoll interface to listen to the rdma_cm fd (gotten by
raccept API).
And cannot listen to the verbs fd event. Only some hacking methods can be used
to address this problem.
Do you guys have any ideas? Thanks.
Regards,
-Gonglei
Hi Peter,
> -Original Message-
> From: Peter Xu [mailto:pet...@redhat.com]
> Sent: Wednesday, May 22, 2024 6:15 AM
> To: Yu Zhang
> Cc: Michael Galaxy ; Jinpu Wang
> ; Elmar Gerdes ;
> zhengchuan ; Gonglei (Arei)
> ; Daniel P. Berrangé ;
> Markus Armbr
Hello,
> -Original Message-
> From: Peter Xu [mailto:pet...@redhat.com]
> Sent: Monday, May 6, 2024 11:18 PM
> To: Gonglei (Arei)
> Cc: Daniel P. Berrangé ; Markus Armbruster
> ; Michael Galaxy ; Yu Zhang
> ; Zhijian Li (Fujitsu) ; Jinpu Wang
> ; Elmar Gerdes ;
.
In some scenarios where fast live migration is needed (extremely short
interruption duration and migration
duration) is very useful. To this end, we have also developed RDMA support for
multifd.
Regards,
-Gonglei
> -Original Message-
> From: Peter Xu [mailto:pet...@redhat.com]
> -Original Message-
> From: Philippe Mathieu-Daudé [mailto:phi...@linaro.org]
> Sent: Monday, November 20, 2023 11:04 PM
> To: qemu-devel@nongnu.org
> Cc: Zhenwei Pi ; Gonglei (Arei)
> ; Markus Armbruster ;
> Daniel P . Berrangé ; Philippe Mathieu-Daudé
>
> -Original Message-
> From: Mauro Matteo Cascella [mailto:mcasc...@redhat.com]
> Sent: Tuesday, May 9, 2023 3:53 PM
> To: qemu-devel@nongnu.org
> Cc: m...@redhat.com; Gonglei (Arei) ;
> pizhen...@bytedance.com; ta...@zju.edu.cn; mcasc...@redhat.com
> Subject: [PA
> -Original Message-
> From: Mauro Matteo Cascella [mailto:mcasc...@redhat.com]
> Sent: Monday, May 8, 2023 11:02 PM
> To: qemu-devel@nongnu.org
> Cc: m...@redhat.com; Gonglei (Arei) ;
> pizhen...@bytedance.com; ta...@zju.edu.cn; mcasc...@redhat.com
> Subject: [PATC
> -Original Message-
> From: zhenwei pi [mailto:pizhen...@bytedance.com]
> Sent: Tuesday, May 31, 2022 9:48 AM
> To: Gonglei (Arei)
> Cc: qemu-devel@nongnu.org; m...@redhat.com;
> virtualizat...@lists.linux-foundation.org; helei.si...@bytedance.com;
> berra...@red
> -Original Message-
> From: zhenwei pi [mailto:pizhen...@bytedance.com]
> Sent: Friday, May 27, 2022 4:48 PM
> To: m...@redhat.com; Gonglei (Arei)
> Cc: qemu-devel@nongnu.org; virtualizat...@lists.linux-foundation.org;
> helei.si...@bytedance.com; berra...@redh
> -Original Message-
> From: Lei He [mailto:helei.si...@bytedance.com]
> Sent: Wednesday, May 25, 2022 5:01 PM
> To: m...@redhat.com; Gonglei (Arei) ;
> berra...@redhat.com
> Cc: qemu-devel@nongnu.org; virtualizat...@lists.linux-foundation.org;
> linux-cry...@v
> -Original Message-
> From: Daniel P. Berrangé [mailto:berra...@redhat.com]
> Sent: Thursday, May 26, 2022 6:48 PM
> To: Lei He
> Cc: m...@redhat.com; Gonglei (Arei) ;
> qemu-devel@nongnu.org; virtualizat...@lists.linux-foundation.org;
> linux-cry...@v
> -Original Message-
> From: zhenwei pi [mailto:pizhen...@bytedance.com]
> Sent: Friday, February 11, 2022 4:44 PM
> To: Gonglei (Arei) ; m...@redhat.com
> Cc: jasow...@redhat.com; virtualizat...@lists.linux-foundation.org;
> linux-cry...@vger.kernel.org; qem
> -Original Message-
> From: Daniel P. Berrangé [mailto:berra...@redhat.com]
> Sent: Tuesday, December 14, 2021 5:22 PM
> To: Philippe Mathieu-Daudé
> Cc: Hailiang Zhang ;
> qemu-devel@nongnu.org; Gonglei (Arei) ;
> Wencongyang (HongMeng) ;
> dgilb...@redhat.
> -Original Message-
> From: Eduardo Habkost [mailto:ehabk...@redhat.com]
> Sent: Tuesday, September 22, 2020 6:10 AM
> To: qemu-devel@nongnu.org
> Cc: Paolo Bonzini ; Daniel P. Berrange
> ; John Snow ; Gonglei (Arei)
>
> Subject: [PATCH 01/24] cryptodev-vhost
> -Original Message-
> From: Eduardo Habkost [mailto:ehabk...@redhat.com]
> Sent: Tuesday, September 22, 2020 6:10 AM
> To: qemu-devel@nongnu.org
> Cc: Paolo Bonzini ; Daniel P. Berrange
> ; John Snow ; Gonglei (Arei)
>
> Subject: [PATCH 02/24] cryptodev-ba
aro.org;
> vsement...@virtuozzo.com; Gonglei (Arei) ;
> Michael S . Tsirkin
> Subject: [PATCH 05/46] virtio-crypto-pci: Tidy up virtio_crypto_pci_realize()
>
> virtio_crypto_pci_realize() continues after realization of its
> "virtio-crypto-device"
> fails. Only an object_
> -Original Message-
> From: Daniel Henrique Barboza [mailto:danielhb...@gmail.com]
> Sent: Tuesday, January 7, 2020 2:24 AM
> To: qemu-devel@nongnu.org
> Cc: qemu-triv...@nongnu.org; Daniel Henrique Barboza
> ; Gonglei (Arei)
> Subject: [PATCH v1 29/59] cryp
CCing qemu-triv...@nongnu.org
Reviewed-by: Gonglei
Regards,
-Gonglei
> -Original Message-
> From: Vladimir Sementsov-Ogievskiy [mailto:vsement...@virtuozzo.com]
> Sent: Thursday, November 28, 2019 3:46 AM
> To: qemu-devel@nongnu.org
> Cc: Gonglei (Arei) ; marcandre.l
Hi Michael,
Could you pls apply this patch in your tree?
Thanks,
-Gonglei
> -Original Message-
> From: Li Qiang [mailto:liq...@163.com]
> Sent: Monday, March 18, 2019 9:12 AM
> To: Gonglei (Arei)
> Cc: qemu-devel@nongnu.org; Li Qiang
> Subject: [PATCH] backends:
Hi,
> -Original Message-
> From: Li Qiang [mailto:liq...@163.com]
> Sent: Sunday, March 17, 2019 5:10 PM
> To: Gonglei (Arei)
> Cc: qemu-devel@nongnu.org; Li Qiang
> Subject: [PATCH] cryptodev-vhost-user: fix a oob access
>
> The 'queue_index' of create/close_se
> >
> > > -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
> -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;
>
> -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
> -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;
&g
> -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
> -Original Message-
> From: Cornelia Huck [mailto:coh...@redhat.com]
> Sent: Wednesday, February 20, 2019 7:43 PM
> To: Gonglei (Arei)
> Cc: Dr. David Alan Gilbert ; Zhao Yan
> ; c...@nvidia.com; k...@vger.kernel.org;
> a...@ozlabs.ru; zhengxiao...@aliba
) We'd better support live migration rollback since have many failure
scenarios,
register a migration notifier is a good choice.
4) Four memory region for live migration is too complicated IMHO.
5) About log sync, why not register log_global_start/stop in
vfio_memory_listener?
Regards,
-Gonglei
.com;
> qemu-devel@nongnu.org; kwankh...@nvidia.com; eau...@redhat.com;
> yi.l@intel.com; eskul...@redhat.com; ziye.y...@intel.com;
> mlevi...@redhat.com; pa...@linux.ibm.com; Gonglei (Arei)
> ; fel...@nutanix.com; ken@amd.com;
> kevin.t...@intel.com; alex.william...@redhat.com;
>
region_init_ram_ptr(MemoryRegion *mr,
> > > uint64_t size,
> > > void *ptr)
> > > {
> > > +DeviceState *owner_dev;
> > > memory_region_init(mr, owner, name, size);
> > > mr->ram = true;
> > > mr->terminates = true;
> > > @@ -1597,6 +1598,9 @@ void
> memory_region_init_ram_ptr(MemoryRegion *mr,
> > > /* qemu_ram_alloc_from_ptr cannot fail with ptr != NULL. */
> > > assert(ptr != NULL);
> > > mr->ram_block = qemu_ram_alloc_from_ptr(size, ptr, mr,
> _fatal);
> > > +
> > > +owner_dev = DEVICE(owner);
> > > +vmstate_register_ram(mr, owner_dev);
> >
> > Where does the corresponding vmstate_unregister_ram() call occur when
> > unplugged? Thanks,
> >
> sorry, I just updated my qemu code base and found that in migration/ram.c
> now it will not save/restore ramblocks who do not call
> vmstate_regitser_ram().
> therefore, the vmstate_register_ram() may not be necessary for memory
> region mapped to device resources, as it's better to save/restore that part
> of memory from vendor driver side.
> So, do you think it's ok to just call qemu_ram_set_idstr() to set idstr for
> ramblocks of mmaped region?
>
> Thanks
> Yan
>
Why not invoking vmstate_register_ram() in vfio_region_mmap and
Invoking vmstate_unregister_ram() in vfio_region_exit?
Regards,
-Gonglei
Hi,
>
> * Gonglei (Arei) (arei.gong...@huawei.com) wrote:
> > Hi Dave,
> >
> > We discussed some live migration fallback scenarios in this year's KVM
> > forum,
> > and now I can provide another scenario, perhaps the upstream should
> consi
ration if kvm_arch_put_registers returns error.
Thanks,
-Gonglei
the capability list of KVM
module, can we?
Regards,
-Gonglei
> -Original Message-
> From: Qemu-devel
> [mailto:qemu-devel-bounces+arei.gonglei=huawei@nongnu.org] On
> Behalf Of Kirti Wankhede
> Sent: Wednesday, November 21, 2018 4:40 AM
> To: alex.william...@redhat.com; c.
> -Original Message-
> From: Michael S. Tsirkin [mailto:m...@redhat.com]
> Sent: Friday, December 14, 2018 8:53 PM
> To: Gonglei (Arei)
> Cc: Juan Quintela ; qemu-devel@nongnu.org; Thomas
> Huth ; Gerd Hoffmann
> Subject: Re: [PATCH v3 00/16] Virtio devices
> -Original Message-
> From: Juan Quintela [mailto:quint...@redhat.com]
> Sent: Friday, December 14, 2018 5:01 AM
> To: qemu-devel@nongnu.org
> Cc: Michael S. Tsirkin ; Thomas Huth ;
> Gerd Hoffmann ; Gonglei (Arei)
> ; Juan Quintela
> Subject: [PATCH v3 00/16] V
UFFER
> > in a given state until the associated pending field reaches zero?
> > Jumping between the region and ioctl is rather awkward.
> >
>
> User gets pending_precopy_only data when device is in PRECOPY_ACTIVE
> state, but each time when user calls GET_BUFFER, pending bytes might
> change.
> VFIO device's driver is producer of data and user/QEMU is consumer of
> data. In pre-copy phase, when vCPUs are still running, driver will try
> to accumulate as much data as possible in this phase, but vCPUs are
> running and user of that device/application in guest is actively using
> that device, then there are chances that during next iteration of
> GET_BUFFER, driver might have more data.
> Even in case of STOPNCOPY_ACTIVE state of device, driver can start
> sending data in parts while a thread in vendor driver can still generate
> data after device has halted, producer and consumer can run in parallel.
> So User has to call GET_BUFFER until pending bytes are returned 0.
>
How to understand "the driver still generate data after device has halted"?
Do interrupts still be generated after device halted? If so, it will lost
interrupt
information in pi_desc.pir .
Thanks,
-Gonglei
>
> On Tue, Aug 28, 2018 at 03:31:02AM +, Gonglei (Arei) wrote:
> >
> > > -Original Message-
> > > From: Michael S. Tsirkin [mailto:m...@redhat.com]
> > > Sent: Friday, August 24, 2018 8:54 PM
> > >
> > > On Fri, Aug 24, 2
> -Original Message-
> From: Michael S. Tsirkin [mailto:m...@redhat.com]
> Sent: Friday, August 24, 2018 8:54 PM
>
> On Fri, Aug 24, 2018 at 12:07:44PM +, Gonglei (Arei) wrote:
> > Hi Michael,
> >
> > > -Original Message-
> &g
Hi Michael,
> -Original Message-
> From: virtio-...@lists.oasis-open.org [mailto:virtio-...@lists.oasis-open.org]
> On Behalf Of Michael S. Tsirkin
> Sent: Friday, August 24, 2018 7:23 PM
> To: longpeng
> Cc: xin.z...@intel.com; Gonglei (Arei) ;
> pa...@linux.vne
> -Original Message-
> From: Peter Maydell [mailto:peter.mayd...@linaro.org]
> Sent: Monday, July 30, 2018 6:49 PM
> To: Paolo Bonzini
> Cc: QEMU Developers ; Gonglei (Arei)
>
> Subject: Re: [Qemu-devel] [PATCH] cryptodev: remove dead code
>
> On 30 July 2
reak;
> }
> -
> -if (err) {
> - error_report_err(err);
> -}
> }
>
> static void cryptodev_vhost_user_init(
> --
> 2.17.1
>
Reviewed-by: Gonglei
Thanks,
-Gonglei
look if we have a simple method to resolve the problem. :)
PS: the below link is zhanghailiang's scheme based on userfaultfd.
https://lists.gnu.org/archive/html/qemu-devel/2016-01/msg00664.html
Thanks,
-Gonglei
> -Original Message-
> From: Daniel P. Berrangé [mailto:berra...@redhat.com]
> Sent: Thursday, June 14, 2018 11:11 PM
> To: Farhan Ali
> Cc: Halil Pasic ; qemu-devel@nongnu.org;
> fran...@linux.ibm.com; m...@redhat.com; borntrae...@de.ibm.com; Gonglei
> (Arei)
> -Original Message-
> From: Farhan Ali [mailto:al...@linux.ibm.com]
> Sent: Wednesday, June 13, 2018 3:49 AM
> To: qemu-devel@nongnu.org
> Cc: m...@redhat.com; Gonglei (Arei) ; longpeng
> ; pa...@linux.ibm.com; borntrae...@de.ibm.com;
> fran...@linux.ibm.com
> -Original Message-
> From: Farhan Ali [mailto:al...@linux.ibm.com]
> Sent: Wednesday, June 13, 2018 1:08 AM
> To: Gonglei (Arei) ; linux-ker...@vger.kernel.org;
> k...@vger.kernel.org
> Cc: m...@redhat.com; qemu-devel@nongnu.org; longpeng
> ; pa...@linux.ibm.com;
> -Original Message-
> From: Farhan Ali [mailto:al...@linux.ibm.com]
> Sent: Wednesday, June 13, 2018 1:07 AM
> To: Gonglei (Arei) ; linux-ker...@vger.kernel.org;
> k...@vger.kernel.org
> Cc: m...@redhat.com; qemu-devel@nongnu.org; longpeng
> ; pa...@linux.ibm.com;
> -Original Message-
> From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On
> Behalf Of David Hildenbrand
> Sent: Monday, June 11, 2018 8:36 PM
> To: Gonglei (Arei) ; 浙大邮箱
> Subject: Re: An emulation failure occurs,if I hotplug vcpus immediately after
Hi David and Paolo,
> -Original Message-
> From: David Hildenbrand [mailto:da...@redhat.com]
> Sent: Monday, June 11, 2018 6:44 PM
> To: 浙大邮箱
> Cc: Paolo Bonzini ; Gonglei (Arei)
> ; Igor Mammedov ;
> xuyandong ; Zhanghailiang
> ; wangxin (U)
> ; lidonglin ;
&
> -Original Message-
> From: Farhan Ali [mailto:al...@linux.ibm.com]
> Sent: Saturday, June 09, 2018 3:09 AM
> To: linux-ker...@vger.kernel.org; k...@vger.kernel.org
> Cc: m...@redhat.com; qemu-devel@nongnu.org; Gonglei (Arei)
> ; longpeng ;
> pa...@linux.ibm.com;
> -Original Message-
> From: Farhan Ali [mailto:al...@linux.ibm.com]
> Sent: Saturday, June 09, 2018 3:09 AM
> To: linux-ker...@vger.kernel.org; k...@vger.kernel.org
> Cc: m...@redhat.com; qemu-devel@nongnu.org; Gonglei (Arei)
> ; longpeng ;
> pa...@linux.ibm.com;
> > On 06/06/2018 15:28, Gonglei (Arei) wrote:
> >> gonglei: mem.slot: 3, mem.guest_phys_addr=0xc,
> >> mem.userspace_addr=0x7fc343ec, mem.flags=0, memory_size=0x0
> >> gonglei: mem.slot: 3, mem.guest_phys_addr=0xc,
> >> me
> -Original Message-
> From: liujunjie (A)
> Sent: Thursday, June 07, 2018 4:03 PM
> To: kra...@redhat.com; berra...@redhat.com
> Cc: Gonglei (Arei) ; wangxin (U)
> ; Huangweidong (C)
> ; fangying ;
> qemu-devel@nongnu.org; liujunjie (A)
> Subject: [PATC
n better would be to debug Seabios and find out what exactly
> goes wrong if you could do it.
This issue can't be reproduced when we opened Seabios debug log or KVM trace. :(
After a few days of debugging, we found that this problem occurs every time
when
the memory region is cleared (memory_
> -Original Message-
> From: Eric Blake [mailto:ebl...@redhat.com]
> Sent: Wednesday, May 30, 2018 3:33 AM
> To: linzhecheng ; Marc-André Lureau
>
> Cc: QEMU ; Paolo Bonzini ;
> wangxin (U) ; Gonglei (Arei)
> ; pet...@redhat.com; berra...@redhat.com
> Subje
qio_channel_socket_writev ==> 1)
returns QIO_CHANNEL_ERR_BLOCK when ret <0 && errno == EAGAIN
Then at the above step 4) may cause undefined behaviors on the vhost-user
server side because null control message is sent.
So, we submit a patch to fix it. What's your opinio
performace in latency-sensitive scenario.
Is there any plan for this patch?
Or May I send a updated version based on yours? @Alex?
Thanks,
-Gonglei
> -Original Message-
> From: Qemu-devel
> [mailto:qemu-devel-bounces+arei.gonglei=huawei@nongnu.org] On
> Behalf Of Alexander
Ping...
Regards,
-Gonglei
> -Original Message-
> From: Gonglei (Arei)
> Sent: Monday, February 12, 2018 4:58 PM
> To: qemu-devel@nongnu.org
> Cc: pbonz...@redhat.com; Huangweidong (C); peter.mayd...@linaro.org;
> Gonglei (Arei)
> Subject: [PATCH v3] rtc: plac
32min 5s
Test results show that optimization is effective under
stressful situations.
Signed-off-by: Gonglei <arei.gong...@huawei.com>
---
v3->v2:
a) fix a typo, 's/rasie/raise/' [Peter]
b) change commit message [Peter]
v2->v1:
a)Adding a new lock to avoid different vCPUs
ac
In function
> 'cryptodev_vhost_user_init':
> /home/peter.maydell/qemu/backends/cryptodev-vhost-user.c:205:40:
> error: format '%lu' expects argument of type 'long unsigned int', but
> argument 2 has type 'size_t {aka unsigned int}' [-Werror=format=]
> cc->info_str = g_strdup_printf("cryptodev-vhost-user%lu to %s ",
> ^
>
Using %zu instead of %lu will be correct. Michael, could you pls fix it
directly?
Very sorry for the inconvenience. :(
Thanks,
-Gonglei
layback 1 v2 22.8 fps
Video Chat v2/Video Chat encoding v2 307.0 ms
Benchmark duration1h 35min 46s
After applying v2:
Your Work 2.0 score: 2040
Web Browsing - JunglePin0.345s
Web Browsing - Amazonia0.132s
Writing3.56s
Spreadsheet67.83s
Video Chat v2/Video Chat playback 1 v2 28.7 fps
Video Chat v2/Video Chat encoding v2 324.7 ms
Benchmark duration1h 32min 5s
Test results show that optimization is very effective in stressful situations.
Thanks,
-Gonglei
> -Original Message-
> From: Paolo Bonzini [mailto:pbonz...@redhat.com]
> Sent: Tuesday, February 06, 2018 11:52 PM
> To: Gonglei (Arei); qemu-devel@nongnu.org
> Cc: shenghualong
> Subject: Re: [PATCH] vl: fix possible int overflow for qemu_timedate_diff()
>
> On 0
> -Original Message-
> From: Peter Maydell [mailto:peter.mayd...@linaro.org]
> Sent: Tuesday, February 06, 2018 10:36 PM
> To: Gonglei (Arei)
> Cc: QEMU Developers; Paolo Bonzini; Huangweidong (C)
> Subject: Re: [PATCH v2] rtc: placing RTC memory region outside BQL
>
gned-off-by: Gonglei <arei.gong...@huawei.com>
---
v2->v1:
a)Adding a new lock to avoid different vCPUs
access the RTC together. [Paolo]
b)Taking the BQL before raising the outbound IRQ line. [Peter]
c)Don't hold BQL if it was holden. [Peter]
hw/timer/mc146
> -Original Message-
> From: Peter Maydell [mailto:peter.mayd...@linaro.org]
> Sent: Tuesday, February 06, 2018 5:49 PM
> To: Gonglei (Arei)
> Cc: Paolo Bonzini; QEMU Developers; Huangweidong (C)
> Subject: Re: [Qemu-devel] [PATCH] rtc: placing RTC memory region out
> -Original Message-
> From: Paolo Bonzini [mailto:pbonz...@redhat.com]
> Sent: Monday, February 05, 2018 10:04 PM
> To: Peter Maydell
> Cc: Gonglei (Arei); QEMU Developers; Huangweidong (C)
> Subject: Re: [Qemu-devel] [PATCH] rtc: placing RTC memory region outside BQL
> -Original Message-
> From: Paolo Bonzini [mailto:pbonz...@redhat.com]
> Sent: Thursday, February 01, 2018 10:24 PM
> To: Gonglei (Arei); qemu-devel@nongnu.org
> Cc: Huangweidong (C)
> Subject: Re: [PATCH] rtc: placing RTC memory region outside BQL
>
> On 01/02/2
130 poll
-- --- --- - -
100.000.072624 6853 total
The futex call number decreases ~90.6% on an idle windows 7 guest.
Signed-off-by: Gonglei <arei.gong...@huawei.com>
---
hw/timer/mc146818rtc.
poll
-- --- --- - -
100.000.072624 6853 total
The futex call number decreases ~90.6% on an idle windows 7 guest.
Signed-off-by: Gonglei <arei.gong...@huawei.com>
---
hw/timer/mc146818rtc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/hw/timer/mc146
ssible overflow problem.
Signed-off-by: shenghualong <shenghual...@huawei.com>
Signed-off-by: Gonglei <arei.gong...@huawei.com>
---
include/qemu-common.h | 2 +-
vl.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/qemu-common.h b/inc
> -Original Message-
> From: Zhoujian (jay)
> Sent: Wednesday, January 17, 2018 1:01 PM
> To: Michael S. Tsirkin
> Cc: pa...@linux.vnet.ibm.com; Huangweidong (C); xin.z...@intel.com;
> qemu-devel@nongnu.org; Gonglei (Arei); roy.fan.zh...@intel.com;
> stefa
> -Original Message-
> From: Eduardo Habkost [mailto:ehabk...@redhat.com]
> Sent: Monday, January 15, 2018 8:23 PM
> To: Gonglei (Arei)
> Cc: qemu-devel@nongnu.org; Paolo Bonzini
> Subject: Re: [Qemu-devel] [PATCH 3/7] i386: Add spec-ctrl CPUID bit
>
> On Sat, Ja
; .cpuid_eax = 7,
> --
> 2.14.3
>
Don't we need to pass-through cupid_7_edx to guest when configuring '-cpu host'?
Otherwise how guests use IBPB/IBRS/STIPB capabilities?
Thanks,
-Gonglei
> -Original Message-
> From: Michael S. Tsirkin [mailto:m...@redhat.com]
> Sent: Thursday, December 21, 2017 10:25 PM
> To: Gonglei (Arei)
> Cc: qemu-devel@nongnu.org; pbonz...@redhat.com; Huangweidong (C);
> stefa...@redhat.com; Zhoujian (jay); pa...@linux.vnet.ibm.com;
> -Original Message-
> From: Michael S. Tsirkin [mailto:m...@redhat.com]
> Sent: Thursday, December 21, 2017 1:39 AM
> To: Gonglei (Arei)
> Cc: qemu-devel@nongnu.org; pbonz...@redhat.com; Huangweidong (C);
> stefa...@redhat.com; Zhoujian (jay); pa...@linux.vnet.ibm.com;
Ping...
Fan (working for DPDK parts) is waiting for those patches upstreamed. :)
Thanks,
-Gonglei
> -Original Message-
> From: Gonglei (Arei)
> Sent: Tuesday, November 28, 2017 5:03 PM
> To: qemu-devel@nongnu.org
> Cc: m...@redhat.com; pbonz...@redhat.com; Huangweido
destroy_session_input {
> > +le32 status;
> > +le32 padding;
> > +};
>
> If we aren't consistent about it the dividing into parts (like op specific
> fixed and variable length (output) fields, operation outcome (input))
> isn't really helpful.
>
It's ok to us, we can do it. Any other comments?
Thanks,
-Gonglei
> -Original Message-
> From: Stefan Hajnoczi [mailto:stefa...@redhat.com]
> Sent: Wednesday, December 06, 2017 11:10 PM
> To: Gonglei (Arei)
> Cc: Paolo Bonzini; Yang Zhong; Stefan Hajnoczi; qemu-devel
> Subject: Re: [Qemu-devel] About the light VM solution!
>
> On
gt; > I thought that wasn't the "conventional" SeaBIOS, but rather one with
> > reduced configuration options, but I may be remembering wrong.
>
> Marc didn't spend much time on optimizing SeaBIOS, he used the build
> options that were suggested. An extra flag can be added in
> qemu_preinit() to skip slow init that's unnecessary on optimized
> machines. That would allow a single SeaBIOS binary to run both full and
> lite systems.
>
What's options do you remember? Stefan. Or any links about that
thread? I'm Interesting with this topic.
Thanks,
-Gonglei
I also think it's windows bug, the problem is that it doesn't occur on xen
platform. And there are some other works need to be done while reading REG_C.
So I wrote that patch.
Thanks,
Gonglei
发件人：Paolo Bonzini
收件人：龚磊,张海亮,qemu-devel,Michael S. Tsirkin
抄送：黄伟栋,王欣,谢祥有
时间：2017-12-02 01:10:08
主题:Re
1 val 0x80
Regards,
-Gonglei
From: Zhanghailiang
Sent: Friday, December 01, 2017 3:03 AM
To: qemu-devel@nongnu.org; m...@redhat.com; Paolo Bonzini
Cc: Huangweidong (C); Gonglei (Arei); wangxin (U); Xiexiangyou
Subject: [BUG] Windows 7 got stuck easily while run PCMark10 application
Hi，
We hit a b
ill miss
calling qemu_irq_lower(s->irq) to clear the irq. After this, kvm will never
inject RTC irq,
and Windows VM will hang.
Let's add a global variable to record the status of accessing RTC_REG_C to
avoid the issue.
Tested by Windows guests with PCMark benchmark.
Signed-off-by: Gongle
> -Original Message-
> From: Paolo Bonzini [mailto:pbonz...@redhat.com]
> Sent: Thursday, November 30, 2017 12:39 AM
> To: Gonglei (Arei); Eric Blake; linzhecheng; qemu-devel@nongnu.org
> Cc: f...@redhat.com; wangxin (U)
> Subject: Re: [Qemu-devel] [PATCH v4] thread:
> -Original Message-
> From: Eric Blake [mailto:ebl...@redhat.com]
> Sent: Thursday, November 30, 2017 12:19 AM
> To: linzhecheng; qemu-devel@nongnu.org
> Cc: aligu...@us.ibm.com; f...@redhat.com; wangxin (U); Gonglei (Arei);
> pbonz...@redhat.com
> Subject: Re: [
> -Original Message-
> From: rka...@virtuozzo.com [mailto:rka...@virtuozzo.com]
> Sent: Wednesday, November 29, 2017 1:56 PM
> To: Gonglei (Arei)
> Cc: Eduardo Habkost; Denis V. Lunev; longpeng; Michael S. Tsirkin; Denis
> Plotnikov; pbonz...@redhat.com; r...@twidd
1 - 100 of 1658 matches
Mail list logo
