在 2022/4/7 15:35, Jason Wang 写道:
在 2022/4/2 下午1:14, Michael Qiu 写道:
On 2022/4/2 10:38, Jason Wang wrote:
在 2022/4/1 下午7:06, Michael Qiu 写道:
Currently in vhost framwork, vhost_reset_device() is misnamed.
Actually, it should be vhost_reset_owner().
In vhost user, it make compatible with
On 2022/4/2 10:38, Jason Wang wrote:
在 2022/4/1 下午7:06, Michael Qiu 写道:
Currently in vhost framwork, vhost_reset_device() is misnamed.
Actually, it should be vhost_reset_owner().
In vhost user, it make compatible with reset device ops, but
vhost kernel does not compatible with it, for
On 2022/4/2 10:20, Jason Wang wrote:
Adding Michael.
On Sat, Apr 2, 2022 at 7:08 AM Si-Wei Liu wrote:
On 3/31/2022 7:53 PM, Jason Wang wrote:
On Fri, Apr 1, 2022 at 9:31 AM Michael Qiu wrote:
Currently, when VM poweroff, it will trigger vdpa
device(such as mlx bluefield2 VF) reset
On 2022/4/2 9:48, Jason Wang wrote:
On Fri, Apr 1, 2022 at 11:22 AM Michael Qiu wrote:
On 2022/4/1 10:53, Jason Wang wrote:
On Fri, Apr 1, 2022 at 9:31 AM Michael Qiu wrote:
Currently, when VM poweroff, it will trigger vdpa
device(such as mlx bluefield2 VF) reset many times(with 1
On 2022/4/2 8:44, Si-Wei Liu wrote:
On 4/1/2022 4:06 AM, Michael Qiu wrote:
Currently in vhost framwork, vhost_reset_device() is misnamed.
Actually, it should be vhost_reset_owner().
In vhost user, it make compatible with reset device ops, but
vhost kernel does not compatible with it, for
.
Test with kernel vhost, vhost-vdpa, DPDK vhost-user(vdpa), with shutdown
,reboot, and load/unload virtio_net driver in guest.
Michael Qiu (3):
vhost: Refactor vhost_reset_device() in VhostOps
vhost: add vhost_dev_reset()
vdpa: reset the backend device in the end of vhost_net_stop()
hw/net
backend
device after all vhost(per-queue) stopped.
Signed-off-by: Michael Qiu
Acked-by: Jason Wang
---
v5 --> v4:
move vhost_dev_reset() call after set_guest_notifiers
remove implementation of vhost_dev_reset()
remove backend check for VHOST_BACKEND_TYPE_VDPA
v4 --> v3:
N
Not all vhost-user backends support ops->vhost_reset_device(). Instead
of adding backend check and call backend ops directly, it's better to
implement a function in vhost framework, so that it could hide vhost_ops
details.
SIgned-off-by: Michael Qiu
---
hw/virtio/vhost.c
function into vhost_reset_owner() and
vhost_reset_device(). So that different backend could use the
correct function.
Signde-off-by: Michael Qiu
---
hw/scsi/vhost-user-scsi.c | 6 +-
hw/virtio/vhost-backend.c | 4 ++--
hw/virtio/vhost-user.c| 22
On 2022/4/1 10:53, Jason Wang wrote:
On Fri, Apr 1, 2022 at 9:31 AM Michael Qiu wrote:
Currently, when VM poweroff, it will trigger vdpa
device(such as mlx bluefield2 VF) reset many times(with 1 datapath
queue pair and one control queue, triggered 3 times), this
leads to below issue
On 2022/4/1 9:12, Si-Wei Liu worte:
On 3/31/2022 2:25 AM, qiud...@archeros.com wrote:
From: Michael Qiu
Currently, when VM poweroff, it will trigger vdpa
device(such as mlx bluefield2 VF) reset many times(with 1 datapath
queue pair and one control queue, triggered 3 times), this
leads to
backend
device after all vhost(per-queue) stoped.
Signed-off-by: Michael Qiu
Acked-by: Jason Wang
---
v4 --> v3
Nothing changed, becasue of issue with mimecast,
when the From: tag is different from the sender,
the some mail client will take the patch as an
attachment, RESEND v3 does
Hi, Jason
Does it work this time?
On 2022/3/31 17:25, qiud...@archeros.com wrote:
From: Michael Qiu
Currently, when VM poweroff, it will trigger vdpa
device(such as mlx bluefield2 VF) reset many times(with 1 datapath
queue pair and one control queue, triggered 3 times), this
leads to below
Hi, all
To avoid tigger the issue of mimecast, I will re-post the V3 patch use
the mail address "Michael Qiu " as a workaround.
Thanks,
Michael
On 2022/3/31 17:12, Maxime Coquelin wrote:
Hi,
On 3/31/22 10:55, Jason Wang wrote:
On Thu, Mar 31, 2022 at 1:20 PM <08005...@163.co
On 2022/3/31 8:15, Si-Wei Liu wrote:
On 3/30/2022 3:02 AM, 08005...@163.com wrote:
From: Michael Qiu
Currently, when VM poweroff, it will trigger vdpa
device(such as mlx bluefield2 VF) reset many times(with 1 datapath
queue pair and one control queue, triggered 3 times), this
leads to
On 2022/3/31 8:15, Si-Wei Liu wrote:
On 3/30/2022 3:02 AM, 08005...@163.com wrote:
From: Michael Qiu
Currently, when VM poweroff, it will trigger vdpa
device(such as mlx bluefield2 VF) reset many times(with 1 datapath
queue pair and one control queue, triggered 3 times), this
leads to
Michael,
Others has already received the patch, don't know why. Anyway, I will
repost another version(V3).
Here is the V2 patch, see below:
From: Michael Qiu
Currently, when VM poweroff, it will trigger vdpa
device(such as mlx bluefield2 VF) reset many times(with 1 datapath
queue pai
On 2022/3/30 16:52, Jason Wang wrote:
On Sat, Mar 26, 2022 at 3:59 AM Si-Wei Liu wrote:
On 3/25/2022 12:18 AM, Michael Qiu wrote:
On 2022/3/25 14:32, Si-Wei Liu Wrote:
On 3/23/2022 2:20 AM, Jason Wang wrote:
Adding Eugenio, and Ling Shan.
On Wed, Mar 23, 2022 at 4:58 PM <08
dimir Sementsov-Ogievskiy"
wrote:
>subject should start with [PATCH v5]
>
>03.02.2021 05:40, 08005...@163.com wrote:
>> From: Michael Qiu
>>
>> v5: reformat the commit log with backtrace of main thread
>> Add a boolean variable to make main thread
Peng,
In my analysis, the root casue should be the lock: aio_context, qemu main
thread do an unnecessary release/aquire action,
That's why IO thread could get the lock it shouldn't hold at this stage.
Thanks,
Michael
At 2021-02-01 20:44:00, "Vladimir Sementsov-Ogievskiy"
wrote:
Hi guys,
Seems there is no r3000 support since qemu use tcg. Unfortunately, I want to
build a vm for a r3000 based soc these days, and I don't want to use older
qemu versions which depends on a certain gcc version. Can anyone tell me how
to port r3000 support back to new qemu versions? Or there is
Hi guys,
I'm going to emulate a display controller with these features:
1. Multiple display layer, such as OSD/video/still picture/background.
2. Alpha blending
By now, I think I should create SDL surface for osd, and yuv surface for
video & other, then I should blit them together. please correct
I'm using qemu to boot a mips kernel.
But it seems always hung like this:
"Calibrating delay loop..."
Actually, it is caused by following code in
int c0_compare_int_usable(void)
> {
> unsigned int delta;
> unsigned int cnt;
>
> /*
> * IP7 already pending? Try to clear it by ackin
Hi all,
I'm really confused by the code in this function.
Can anyone tell me the exact meaning for the arguments used for this function?
target_phys_addr_t start_addr
ram_addr_t size
ram_addr_t phys_offset
ram_addr_t region_offset
Best regards
Hi,
Can anyone tell me what subpage for in exec.c?
Best regards
Thanks for your reply. I'm reading hw/mips_r4k.c. But I found I should dive
into the source code.
I'm looking for some big picture level document for add a new machine using
a supported core.
It seems qemu consists 3 parts of code
1. The core dynamic translate engineer to support several archs, jus
I'm going to add a new mips machine with a mips core. But I can not find a
proper document for me to do so. Can anyone give a link? Or any suggestion
for this?
Thanks in advance.
27 matches
Mail list logo
