ssmates and
> friends, but there is no answer.
> so I'm hoping to get important information from you. Is my way of reading
> code right? Is there any tools for development(finding the function
> body)？How can I accomplish this quickly？
> thank you very very much！
> best wishes！
> Xiang Chen Dong
>
Everything here maybe have some mistakes.
Hope it is useful for you.
--
best wishes！
Wei Li
Ping..
And the title is target/i386: Some mmx/sse instructions don't require
CR0.TS=0
On Fri, Mar 25, 2022 at 10:55 PM Wei Li wrote:
> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/427
>
> All instructions decoded by 'gen_see' is assumed to require CRO.
Some instructions in 'gen_sse' don't require CRO.TS=0 and the opcode of them are
0F38F[0-F], 0F3AF[0-F].
Signed-off-by: Wei Li
---
target/i386/tcg/translate.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/target/i386/tcg/translate.c b/
This patch fixes a bug reported on issues #508.
The problem is cmpxchg and lock cmpxchg would touch accumulator when
the comparison is equal.
Signed-off-by: Wei Li
---
target/i386/tcg/translate.c | 41 +
1 file changed, 19 insertions(+), 22 deletions(-)
diff
Give a better code struture to reduce more code duplication according
to the discuss in patch v2.
Signed-off-by: Wei Li
---
target/i386/tcg/translate.c | 41 +
1 file changed, 19 insertions(+), 22 deletions(-)
diff --git a/target/i386/tcg/translate.c b
ctness.
Signed-off-by: Wei Li
---
target/i386/tcg/translate.c | 44 +++--
1 file changed, 23 insertions(+), 21 deletions(-)
diff --git a/target/i386/tcg/translate.c b/target/i386/tcg/translate.c
index 2a94d33742..6633d8ece6 100644
--- a/target/i386/tcg/translate.c
+++ b/
.
* lock cmpxchg uses movcond to replace branch.
* Combine the two patches into one patch because cmpxchg uses the lock
cmpxchg path.
v1 link:
https://lists.gnu.org/archive/html/qemu-devel/2022-03/msg05023.html
Wei Li (1):
fix cmpxchg and lock cmpxchg instruction
target/i386/tcg/translate.c
Hi Paolo,
That will be great, I would like to hear more details about the design and
implementation once you get those ready.
Thanks a lot,
Wei
On 5/3/19, 11:05 AM, "Paolo Bonzini" wrote:
On 03/05/19 10:21, Wei Li wrote:
> Got it, thanks Stefan for your clarification
Got it, thanks Stefan for your clarification!
Wei
On 5/1/19, 9:36 AM, "Stefan Hajnoczi" wrote:
On Mon, Apr 29, 2019 at 10:56:31AM -0700, Wei Li wrote:
>Does this mean the performance could be improved via adding Batch I/O
submission support in Guest driver side which wi
Thanks Stefan!
Does this mean the performance could be improved via adding Batch I/O
submission support in Guest driver side which will be able to reduce the number
of virtqueue kicks?
Thanks,
Wei
On 4/29/19, 6:40 AM, "Stefan Hajnoczi" wrote:
On Fri, Apr 26, 2019 at 10:14:16AM +0200, Pa
Thanks Paolo for your clarification!
Just wanted to double confirm, does this mean batch I/O submission won't apply
to aio=threads (which is the default mode)?
Thanks,
Wei
On 4/26/19, 9:25 PM, "Paolo Bonzini" wrote:
> Thanks Stefan and Paolo for your response and advice!
>
Thanks Stefan and Paolo for your response and advice!
Hi Paolo,
As to the virtio-scsi batch I/O submission feature in QEMU which you mentioned,
is this feature turned on by default in QEMU 2.9 or there is a tunable
parameters to turn on/off the feature?
Thanks,
Wei
On 4/26/19, 1:14 AM, "Paol
system calls?
Thanks,
Wei
On 4/16/19, 6:42 PM, "Wei Li" wrote:
Thanks Stefan and Dongli for your feedback and advices!
I will do the further investigation per your advices and get back to you
later on.
Thanks,
-Wei
On 4/16/19, 2:20 AM, "Stef
Sounds good, let's keep in touch. __
Thanks,
Wei
On 4/17/19, 5:17 AM, "Paolo Bonzini" wrote:
On 17/04/19 03:38, Wei Li wrote:
> Thanks Paolo for your response and clarification.
>
> Btw, is there any rough schedule about when are you planning to st
>
> On 4/16/19 1:34 AM, Wei Li wrote:
> > Hi @Paolo Bonzini & @Stefan Hajnoczi,
> >
> > Would you please help confirm whether @Paolo Bonzini's multiqueue
feature change will benefit virtio-scsi or not? Thanks!
> >
> > @Stefan
benefit the performance of virtio-scsi.
Thanks again,
Wei
On 4/16/19, 7:01 AM, "Paolo Bonzini" wrote:
On 05/04/19 23:09, Wei Li wrote:
> Thanks Stefan for your quick response!
>
> Hi Paolo, Could you please send us a link related to the multiqueue
>
es | 4 Queues | 2 Queues| Single Queue
IOPS| +29% | 27% |11% |
Baseline
Thanks,
Wei
On 4/5/19, 2:09 PM, "Wei Li" wrote:
Thanks Stefan for your quick response!
Hi Paolo,
Could you please send u
r 29, 2019 at 08:16:36AM -0700, Wei Li wrote:
> Thanks Stefan for your reply and guidance!
>
> We spent some time on exploring the multiple I/O Threads approach per
your feedback. Based on the perf measurement data, we did see some IOPS
improvement for multiple volu
doing some
exploration?
Thanks a lot!
Wei
On 3/5/19, 9:29 AM, "Stefan Hajnoczi" wrote:
On Mon, Mar 04, 2019 at 09:33:26AM -0800, Wei Li wrote:
> While @Stefan mentioned about additional iothread object support of
virtio-blk, Is the feature also supported by virtio-scsi? I
://marc.info/?l=linux-virtualization&m=135583400026151&w=2, but it only
measure the bandwidth, do we have any perf result about IOPS improvement of
Multi-Queue approach?
Thanks again,
Wei
On 2/18/19, 2:24 AM, "Stefan Hajnoczi" wrote:
On Thu, Feb 14, 2019 at 08:
20 matches
Mail list logo
