[Qemu-devel] TCG problem with cpu_{st,ld}x_data ?
Hi !
I need help from TCG experts here. I was chasing down a bug causing
some stuff to crash when using vector ops with a ppc32 guest on x86,
but pulling that string led to a whole mess that *may* be affecting a
pile of architetures unless I'm misunderstanding something...
So basically what happens is that some instruction emulation helpers,
like in my case stvebx (target-ppc/mem_helper.c) are doing calls to
cpu_{st,ld}x_data. Let's say cpu_stb_data() for the sake of the
argument.
That is equivalent to calling cpu_stb_data_ra() with a "0" retaddr.
However, if that faults, when tlb_fill() gets eventually called, what I
observe is not 0 in "retaddr" but ... -2.
The reason, as far as I understand, is that cpu_stb_data_ra() calls
helper_ret_stb_mmu() which does:
retaddr -= GETPC_ADJ;
(which is -2)
Now a whole pile of tlb_fill() implementations (in fact all of them one
way or another) do:
if (likely(retaddr)) {
/* now we have a real cpu fault */
cpu_restore_state(cs, retaddr);
}
So that test is missed. The result that I obseve is that the fault gets
reported for the wrong instruction (the wrong PC).
Now I did try changing the above test out of curiosity to also check
against -2, but the end result still mis-reported the fault. So
something's going deeper than that I figured out so far...
What *did* work was to copy what x86 does, which is to change my
helper_stvebx() to not use cpu_stb_data at all, but instead use
cpu_stb_data_ra(, GETPC()), which mimmics what x86 does for some of
it's helpers.
That fixed the specific problem I was chasing.
However, there are a ton of other helpers, in powerpc, s390 and other
archs, doing that cpu_stb_data() the same way we do, so I really wonder
what's going on here.
Some advice would be very much appreciated ;-)
Cheers,
Ben.
Re: [Qemu-devel] TCG problem with cpu_{st,ld}x_data ?
On Sun, 2016-07-24 at 22:42 +1000, Benjamin Herrenschmidt wrote: > > What *did* work was to copy what x86 does, which is to change my > helper_stvebx() to not use cpu_stb_data at all, but instead use > cpu_stb_data_ra(, GETPC()), which mimmics what x86 does for some > of > it's helpers. > > That fixed the specific problem I was chasing. > > However, there are a ton of other helpers, in powerpc, s390 and other > archs, doing that cpu_stb_data() the same way we do, so I really > wonder > what's going on here. > > Some advice would be very much appreciated ;-) FYI: This probably completely wrong patch (but it was easier than hacking all the helpers) fixed the problem for me. With this (and the video driver I wrote that I will publish asap), I can now reliably boot various versions of MacOS X in qemu ppc using a 7400 CPU. Cheers, Ben.
Re: [Qemu-devel] TCG problem with cpu_{st,ld}x_data ?
On Sun, 2016-07-24 at 22:51 +1000, Benjamin Herrenschmidt wrote:
>
> FYI: This probably completely wrong patch (but it was easier than
> hacking all the helpers) fixed the problem for me. With this (and the
> video driver I wrote that I will publish asap), I can now reliably
> boot
> various versions of MacOS X in qemu ppc using a 7400 CPU.
And here's the patch:
diff --git a/include/exec/cpu_ldst_template.h b/include/exec/cpu_ldst_template.h
index eaf69a1..13e8881 100644
--- a/include/exec/cpu_ldst_template.h
+++ b/include/exec/cpu_ldst_template.h
@@ -111,7 +111,7 @@ glue(glue(glue(cpu_ld, USUFFIX), MEMSUFFIX),
_ra)(CPUArchState *env,
static inline RES_TYPE
glue(glue(cpu_ld, USUFFIX), MEMSUFFIX)(CPUArchState *env, target_ulong ptr)
{
-return glue(glue(glue(cpu_ld, USUFFIX), MEMSUFFIX), _ra)(env, ptr, 0);
+return glue(glue(glue(cpu_ld, USUFFIX), MEMSUFFIX), _ra)(env, ptr,
GETPC());
}
#if DATA_SIZE <= 2
@@ -149,7 +149,7 @@ glue(glue(glue(cpu_lds, SUFFIX), MEMSUFFIX),
_ra)(CPUArchState *env,
static inline int
glue(glue(cpu_lds, SUFFIX), MEMSUFFIX)(CPUArchState *env, target_ulong ptr)
{
-return glue(glue(glue(cpu_lds, SUFFIX), MEMSUFFIX), _ra)(env, ptr, 0);
+return glue(glue(glue(cpu_lds, SUFFIX), MEMSUFFIX), _ra)(env, ptr,
GETPC());
}
#endif
@@ -191,7 +191,7 @@ static inline void
glue(glue(cpu_st, SUFFIX), MEMSUFFIX)(CPUArchState *env, target_ulong ptr,
RES_TYPE v)
{
-glue(glue(glue(cpu_st, SUFFIX), MEMSUFFIX), _ra)(env, ptr, v, 0);
+glue(glue(glue(cpu_st, SUFFIX), MEMSUFFIX), _ra)(env, ptr, v, GETPC());
}
#endif /* !SOFTMMU_CODE_ACCESS */
[Qemu-devel] [Bug 1603636] Re: Guest has not initialized the display yet on ubuntu 16.10 PPC
Hi T, i just make a test on My Quad G5 and Mate 15.10 and here i have the same issue ... no video on last 2.6. I think this issue is present on all ppc world -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1603636 Title: Guest has not initialized the display yet on ubuntu 16.10 PPC Status in QEMU: New Bug description: Hi tested with all kind of configure, with all kind of machine types but i have the same issue ... on lastest quemo 2.6 "Guest has not initialized the display yet" note with lastest git repository the situation become worst because on i386-softmmu i have the message but qemu exit alone because looklike there is not a bios this is gdb of i386-softmmu (gdb) run Starting program: /home/amigaone/src/qemu/i386-softmmu/qemu-system-i386 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/powerpc-linux-gnu/libthread_db.so.1". [New Thread 0xf7f78b70 (LWP 25074)] [New Thread 0xf770bb70 (LWP 25075)] [New Thread 0xf6dfdb70 (LWP 25076)] [New Thread 0xf65fdb70 (LWP 25077)] [New Thread 0xf3337b70 (LWP 25078)] [New Thread 0xe4146b70 (LWP 25087)] qemu-system-i386: Trying to execute code outside RAM or ROM at 0x000a This usually means one of the following happened: (1) You told QEMU to execute a kernel for the wrong machine type, and it crashed on startup (eg trying to run a raspberry pi kernel on a versatilepb QEMU machine) (2) You didn't give QEMU a kernel or BIOS filename at all, and QEMU executed a ROM full of no-op instructions until it fell off the end (3) Your guest kernel has a bug and crashed by jumping off into nowhere This is almost always one of the first two, so check your command line and that you are using the right type of kernel for this machine. If you think option (3) is likely then you can try debugging your guest with the -d debug options; in particular -d guest_errors will cause the log to include a dump of the guest register state at this point. Execution cannot continue; stopping here. [Thread 0xe4146b70 (LWP 25087) exited] [Thread 0xf65fdb70 (LWP 25077) exited] [Thread 0xf6dfdb70 (LWP 25076) exited] [Thread 0xf770bb70 (LWP 25075) exited] [Thread 0xf7f78b70 (LWP 25074) exited] [Thread 0xf7f7c000 (LWP 25070) exited] [Inferior 1 (process 25070) exited with code 01] this is my ldd ldd ./qemu-system-i386 linux-vdso32.so.1 => (0x0010) libvirglrenderer.so.0 => /usr/local/lib/libvirglrenderer.so.0 (0x0ff8a000) libepoxy.so.0 => /usr/lib/powerpc-linux-gnu/libepoxy.so.0 (0x0fe86000) libgbm.so.1 => /usr/local/lib/libgbm.so.1 (0x0fe55000) libX11.so.6 => /usr/lib/powerpc-linux-gnu/libX11.so.6 (0x0fcf2000) libz.so.1 => /lib/powerpc-linux-gnu/libz.so.1 (0x0fcb1000) libcurl-gnutls.so.4 => /usr/lib/powerpc-linux-gnu/libcurl-gnutls.so.4 (0x0fc1) libssh2.so.1 => /usr/lib/powerpc-linux-gnu/libssh2.so.1 (0x0fbbf000) libbz2.so.1.0 => /lib/powerpc-linux-gnu/libbz2.so.1.0 (0x0fb7e000) libpixman-1.so.0 => /usr/lib/powerpc-linux-gnu/libpixman-1.so.0 (0x0fadd000) libutil.so.1 => /lib/powerpc-linux-gnu/libutil.so.1 (0x0faac000) libnuma.so.1 => /usr/lib/powerpc-linux-gnu/libnuma.so.1 (0x0fa79000) libncurses.so.5 => /lib/powerpc-linux-gnu/libncurses.so.5 (0x0fa28000) libtinfo.so.5 => /lib/powerpc-linux-gnu/libtinfo.so.5 (0x0f9d7000) libuuid.so.1 => /lib/powerpc-linux-gnu/libuuid.so.1 (0x0f9a6000) libpng16.so.16 => /usr/lib/powerpc-linux-gnu/libpng16.so.16 (0x0f945000) libjpeg.so.8 => /usr/lib/powerpc-linux-gnu/libjpeg.so.8 (0x0f8d4000) libSDL2-2.0.so.0 => /usr/local/lib/libSDL2-2.0.so.0 (0x0f77d000) libnettle.so.6 => /usr/lib/powerpc-linux-gnu/libnettle.so.6 (0x0f71c000) libgnutls.so.30 => /usr/lib/powerpc-linux-gnu/libgnutls.so.30 (0x0f5ca000) libgtk-x11-2.0.so.0 => /usr/lib/powerpc-linux-gnu/libgtk-x11-2.0.so.0 (0x0f0e6000) libgdk-x11-2.0.so.0 => /usr/lib/powerpc-linux-gnu/libgdk-x11-2.0.so.0 (0x0f005000) libcairo.so.2 => /usr/lib/powerpc-linux-gnu/libcairo.so.2 (0x0eec3000) libgdk_pixbuf-2.0.so.0 => /usr/lib/powerpc-linux-gnu/libgdk_pixbuf-2.0.so.0 (0x0ee72000) libgobject-2.0.so.0 => /usr/lib/powerpc-linux-gnu/libgobject-2.0.so.0 (0x0edf1000) libglib-2.0.so.0 => /lib/powerpc-linux-gnu/libglib-2.0.so.0 (0x0eca) libsnappy.so.1 => /usr/lib/powerpc-linux-gnu/libsnappy.so.1 (0x0ec6f000) libusb-1.0.so.0 => /lib/powerpc-linux-gnu/libusb-1.0.so.0 (0x0ec2e000) librt.so.1 => /lib/powerpc-linux-gnu/librt.so.1 (0x0ebfd000) libm.so.6 => /lib/powerpc-linux-gnu/libm.so.6 (0x0eb0c000) libgcc_s.so.1 => /lib/powerpc-linux-gnu/libgcc_s.so.1 (0x0eacb000) libpthread.so.0 => /lib/powerpc-linux-gnu/libpthread.so.0 (0x0ea88000) libc
Re: [Qemu-devel] TCG problem with cpu_{st,ld}x_data ?
On 07/24/2016 06:12 PM, Benjamin Herrenschmidt wrote:
Hi !
I need help from TCG experts here. I was chasing down a bug causing
some stuff to crash when using vector ops with a ppc32 guest on x86,
but pulling that string led to a whole mess that *may* be affecting a
pile of architetures unless I'm misunderstanding something...
So basically what happens is that some instruction emulation helpers,
like in my case stvebx (target-ppc/mem_helper.c) are doing calls to
cpu_{st,ld}x_data. Let's say cpu_stb_data() for the sake of the
argument.
That is equivalent to calling cpu_stb_data_ra() with a "0" retaddr.
However, if that faults, when tlb_fill() gets eventually called, what I
observe is not 0 in "retaddr" but ... -2.
The reason, as far as I understand, is that cpu_stb_data_ra() calls
helper_ret_stb_mmu() which does:
retaddr -= GETPC_ADJ;
(which is -2)
Ouch, yes.
I noticed a related problem recently, while working on the cmpxchg patch set.
In my opinion, we should (1) merge GETRA and GETPC so there's no confusion
between the two, (2) push all adjustment down to the final moment before use,
perhaps in cpu_restore_state.
Thus a null value would be properly retained until checked, and one can easily
call the memory helper functions without confusion.
r~
Re: [Qemu-devel] TCG problem with cpu_{st,ld}x_data ?
On 07/24/2016 06:22 PM, Benjamin Herrenschmidt wrote:
On Sun, 2016-07-24 at 22:51 +1000, Benjamin Herrenschmidt wrote:
>
> FYI: This probably completely wrong patch (but it was easier than
> hacking all the helpers) fixed the problem for me. With this (and the
> video driver I wrote that I will publish asap), I can now reliably
> boot
> various versions of MacOS X in qemu ppc using a 7400 CPU.
And here's the patch:
diff --git a/include/exec/cpu_ldst_template.h b/include/exec/cpu_ldst_template.h
index eaf69a1..13e8881 100644
--- a/include/exec/cpu_ldst_template.h
+++ b/include/exec/cpu_ldst_template.h
@@ -111,7 +111,7 @@ glue(glue(glue(cpu_ld, USUFFIX), MEMSUFFIX),
_ra)(CPUArchState *env,
static inline RES_TYPE
glue(glue(cpu_ld, USUFFIX), MEMSUFFIX)(CPUArchState *env, target_ulong ptr)
{
-return glue(glue(glue(cpu_ld, USUFFIX), MEMSUFFIX), _ra)(env, ptr, 0);
+return glue(glue(glue(cpu_ld, USUFFIX), MEMSUFFIX), _ra)(env, ptr,
GETPC());
}
These functions would have to be always_inline for this to work. Otherwise you
could get the helper's PC, not the TCG caller's PC.
But let's try to fix this the other way.
r~
Re: [Qemu-devel] TCG problem with cpu_{st,ld}x_data ?
On Mon, 2016-07-25 at 06:06 +0530, Richard Henderson wrote: > These functions would have to be always_inline for this to work. > Otherwise you > could get the helper's PC, not the TCG caller's PC. > > But let's try to fix this the other way. I could use some help there as I don't really understand the PC fixup / adjustment mechanism in qemu... Cheers, Ben.
Re: [Qemu-devel] TCG problem with cpu_{st,ld}x_data ?
On Mon, 2016-07-25 at 10:46 +1000, Benjamin Herrenschmidt wrote: > On Mon, 2016-07-25 at 06:06 +0530, Richard Henderson wrote: > > > > These functions would have to be always_inline for this to work. > > Otherwise you > > could get the helper's PC, not the TCG caller's PC. > > > > But let's try to fix this the other way. > > I could use some help there as I don't really understand the PC fixup > adjustment mechanism in qemu... One thing I can do, but I don't know whether that's worthwhile (you tell me), is change all translation helpers in powerpc to do like x86, which is to pass the RA along and never use the non_ra() variants. But that's quite a bit of churn, so let me know if your plan is better. Are those functions always meant to be called within translation helpers ? IE, the fault can safely longjmp out and it's just a matter of finding the proper instruction PC to report ? Or can they also be called outside of that context ? Cheers, Ben.
Re: [Qemu-devel] [RFC v4] virtio-crypto specification
Hi Xin,
> -Original Message-
> From: Zeng, Xin [mailto:xin.z...@intel.com]
> Sent: Friday, July 22, 2016 1:31 PM
> To: Gonglei (Arei); virtio-...@lists.oasis-open.org; qemu-devel@nongnu.org
> Cc: Hanweidong (Randy); Stefan Hajnoczi; Cornelia Huck; m...@redhat.com;
> Lingli Deng; Jani Kokkonen; Luonengjun; Huangpeng (Peter); Zhoujian (jay,
> Euler); chenshanxi 00222737; 'Ola liljed...@arm.com'; Varun Sethi
> Subject: RE: [RFC v4] virtio-crypto specification
>
> On Friday, July 22, 2016 10:53 AM Gonglei (Arei) wrote:
> >
> > Hi Xin,
> >
> > Thank you so much for your great comments.
> > I agree with you almostly except some trivial detals.
> > Please see my below replies.
> >
> > And I'll submit V5 next week, and you can finish the asym algos parts if you
> > like.
> > Let's co-work to finish the virtio-crypto spec, shall we?
> >
>
> That's great.
>
> > Regards,
> > -Gonglei
> >
> >
> > > -Original Message-
> > > From: Zeng, Xin [mailto:xin.z...@intel.com]
> > > Sent: Friday, July 22, 2016 8:48 AM
> > > To: Gonglei (Arei); virtio-...@lists.oasis-open.org; qemu-
> > de...@nongnu.org
> > > Cc: Hanweidong (Randy); Stefan Hajnoczi; Cornelia Huck; m...@redhat.com;
> > > Lingli Deng; Jani Kokkonen; Luonengjun; Huangpeng (Peter); Zhoujian (jay,
> > > Euler); chenshanxi 00222737; 'Ola liljed...@arm.com'; Varun Sethi
> > > Subject: RE: [RFC v4] virtio-crypto specification
> > >
> > > On Sunday, June 26, 2016 5:35 PM, Gonglei (Arei) Wrote:
> > > > Hi all,
> > > >
> > > > This is the specification (version 4) about a new virtio crypto device.
> > > >
> > >
> > > In general, our comments around this proposal are listed below:
> > > 1. Suggest to introduce crypto services into virtio crypto device. The
> > services
> > > currently defined are CIPHER, MAC, HASH, AEAD, KDF, ASYM, PRIMITIVE.
> >
> > Yes, I agree, whether DRBG/NDRBG are included in PRIMITIVE service or
> > not?
> > If not, we'd better add another separate service.
>
> Yes, I think we can add these two into PRIMITIVE services.
>
> >
> > > 2. Suggest to define a unified crypto request format that is consisted of
> > > general header + service specific request, Where 'general header' is for
> > > all
> > > crypto request, 'service specific request' is composed of
> > > operation parameter + input data + output data in generally.
> > > operation parameter is algorithm-specific parameters,
> > > input data is the data should be operated ,
> > > output data is the "operation result + result buffer".
> > >
> > It makes sense. Good.
> >
> > > #define VIRTIO_CRYPTO_OPCODE(service, op) (((service)<<8) | (op))
> > > struct virtio_crypto_op_header {
> > > #define VIRTIO_CRYPTO_CIPHER_ENCRYPT
> > > VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_S_CIPHER, 0x00)
> > > #define VIRTIO_CRYPTO_CIPHER_DECRYPT
> > > VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_S_CIPHER, 0x01)
> > > #define VIRTIO_CRYPTO_HASH
> > > VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_S_HASH, 0x00)
> > > #define VIRTIO_CRYPTO_MAC
> > > VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_S_MAC, 0x00)
> > > #define VIRTIO_CRYPTO_KDF
> > > VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_S_KDF, 0x00)
> > > #define VIRTIO_CRYPTO_ASYM_KEY_GEN
> > > VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_S_ASYM, 0x00)
> > > #define VIRTIO_CRYPTO_ASYM_KEY_EXCHG
> > > VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_S_ASYM, 0x01)
> > > #define VIRTIO_CRYPTO_ASYM_SIGN
> > > VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_S_ASYM, 0x02)
> > > #define VIRTIO_CRYPTO_ASYM_VERIFY
> > > VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_S_ASYM, 0x03)
> > > #define VIRTIO_CRYPTO_ASYM_ENCRYPT
> > > VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_S_ASYM, 0x04)
> > > #define VIRTIO_CRYPTO_ASYM_DECRYPT
> > > VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_S_ASYM, 0x05)
> > > #define VIRTIO_CRYPTO_AEAD_ENCRYPT
> > > VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_S_AEAD, 0x00)
> > > #define VIRTIO_CRYPTO_AEAD_DECRYPT
> > > VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_S_AEAD, 0x01)
> > > #define VIRTIO_CRYPTO_PRIMITIVE
> > > VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_S_PRIMITIVE, 0x00)
> > > u32 opcode;
> > > u8 algo; /*service-specific algorithms*/
> > > u8 flag; /*control flag*/
> >
> > We'd better add a U64 session_id property here for service-specific
> > algorithms.
> >
>
> Can we put session_id into parameter filed inside service-specific request?
> For ASYM service, it doesn't need session_id.
> And for HASH service, it might not need a session_id as well.
>
I don't think so, the function of session_id property is the same with algo
property here,
It's also service-specific algorithms. We don't know which session_id we could
use
if we put the field inside request for chain-algorithms (chain cipher and mac).
For HASH service, I think we'd better keep corresponding with the mac hand
cipher,
using session for operation, which have the same functions and APIs too.
> > > };
> > >
> > > Take rsa_sign_request as example,
> > > A rsa sign service specific request is defined as:
> > > struct virtio_crypto_asym_rsa_sign_req{
> > > stru
[Qemu-devel] [Bug 1605506] Re: qemu driver_mirror error "Operation not permitted"
** Tags added: qemu
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1605506
Title:
qemu driver_mirror error "Operation not permitted"
Status in QEMU:
New
Bug description:
I use libvirtd to call qemu drive_mirror return error message "Operation not
permitted", But directly run qemu and call drive_mirror is OK;
when drive_mirror target is logic device return error message "Operation not
permitted",But the file is OK;
Operating Environment：
OS:ubuntu 14.04
kernel:3.16.0-28-generic
libvirt-bin version: 1.2.2-0ubuntu13.1.17
qemu:2.5.0 or 2.6.0
run vm user: root
（retry in redhat7.2 have the same problem！）
Here is my running process:
libvirtd call
prepare libvirt xml libvirt.xml
i-745F35DC
65536
1
hvm
destroy
restart
destroy
/usr/local/qemu-2.5.0-20160720/bin/qemu-system-x86_64
bc-system
virsh create libvirt.xml
root@test:/opt/run/instance/i-745F35DC# virsh list
IdName State
2 i-745F35DC running
call drive_mirror:
virsh qemu-monitor-command --hmp i-745F35DC 'drive_mirror -n -f
drive-ide0-0-0 /dev/vg_bc_local/test raw'
Could not open '/dev/vg_bc_local/test': Operation not permitted
directly run qemu and call drive_mirror:
/usr/local/qemu-2.5.0-20160720/bin/qemu-system-x86_64 -hda /tmp/image.raw -m
64 --enable-kvm -vnc :51 -monitor stdio
QEMU 2.5.0 monitor - type 'help' for more information
(qemu) info block
ide0-hd0 (#block135): /tmp/image.raw (raw)
Cache mode: writeback
(qemu) drive_mirror -n -f ide0-hd0 /dev/vg_bc_local/test raw
(qemu) info block-jobs
Type mirror, device ide0-hd0: Completed 41126400 of 41126400 bytes, speed
limit 0 bytes/s
(qemu) block_job_cancel ide0-hd0
(qemu) info block-jobs
No active jobs
It is OK!!!
Here is my debugging process:
Recompile qemu-2.5.0 to enable debug
../configure --prefix=/usr/local/qemu-2.5.0-20160720
--enable-trace-backend=simple --enable-werror --disable-xen --disable-virtfs
--enable-kvm --enable-seccomp --enable-docs --enable-debug-tcg
--enable-vnc-sasl --enable-linux-aio --enable-lzo --enable-snappy
--enable-usb-redir --enable-vnc-png --disable-vnc-jpeg --enable-uuid
--disable-vhost-scsi --enable-rbd
--block-drv-rw-whitelist=qcow2,raw,file,host_device,blkdebug,nbd,iscsi,rbd,cdp
--block-drv-ro-whitelist=vmdk,vhdx,vpc --target-list=x86_64-softmmu CFLAGS=-O0
Use libvirtd to Re-run VM and debug by gdb
VM process info:
root 7804 1 0 10:45 ?00:00:10
/usr/local/qemu-2.5.0-20160720/bin/qemu-system-x86_64 -name i-745F35DC -S
-machine pc-i440fx-2.5,accel=kvm,usb=off -cpu
Westmere,+invpcid,+erms,+bmi2,+smep,+avx2,+bmi1,+fsgsbase,+abm,+rdtscp,+pdpe1gb,+rdrand,+f16c,+avx,+osxsave,+xsave,+tsc-deadline,+movbe,+pcid,+pdcm,+xtpr,+fma,+tm2,+est,+vmx,+ds_cpl,+monitor,+dtes64,+pclmuldq,+pbe,+tm,+ht,+ss,+acpi,+ds,+vme
-m 64 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid
ef55dfa6-b82e-488d-a7fc-4c882f8091ab -no-user-config -nodefaults -chardev
socket,id=charmonitor,path=/var/lib/libvirt/qemu/i-745F35DC.monitor,server,nowait
-mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime
-no-shutdown -boot strict=on -device
piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive
file=/tmp/image.raw,if=none,id=drive-ide0-0-0,format=raw,serial=bc-system,cache=none
-device ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=2
-vnc 0.0.0.0:0,password -k en-us -device
cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device
virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3
gdb -p 7804
set breakpoint
(gdb) i b
Num Type Disp Enb AddressWhat
1 breakpoint keep y 0x7f51d9e92cb1 in qmp_drive_mirror at
/opt/qemu/qemu-2.5.0/blockdev.c:3310
2 breakpoint keep y 0x7f51da1252f2 in raw_open_common at
/opt/qemu/qemu-2.5.0/block/raw-posix.c:457
3 breakpoint keep y 0x7f51da12500f in raw_parse_flags at
/opt/qemu/qemu-2.5.0/block/raw-posix.c:358
(gdb)
call drive_mirror and debug:
(gdb)
raw_open_common (bs=0x7f4b27259ab0, options=0x7f4b27480290, bdrv_flags=24674,
open_flags=0, errp=0x7fff4a19f548)
at /opt/qemu/qemu-2.5.0/block/raw-posix.c:484
484s->fd = -1;
(gdb) n
485fd = qemu_open(filename, s->open_flags, 0644);
(gdb) s
qemu_open (name=0x7f4b2642b5c0 "/dev/vg_bc_local/test", flags=2) at
/opt/qemu/qemu-2.5.0/util/osdep.c:177
177int mode = 0;
(gdb) n
183if (strstart(name, "/dev/fdset/", &fdset_id_str)) {
(gdb)
214if (flags & O_CREAT) {
(gdb)
223char arg[1000] = {0};
(gdb)
227
Re: [Qemu-devel] [PATCH v2] target-ppc: add PPC_MFTB flag to e500mc and e5500
On Fri, Jul 22, 2016 at 06:53:51PM +0200, Michael Walle wrote: > According to the e500mc and e5500 core reference manual they have support > for the mftb instruction. > > Signed-off-by: Michael Walle Applied to ppc-for-2.7, thanks. > --- > changes v2: > - add the flag to e500mc, too > > target-ppc/translate_init.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c > index 5ecafc7..5f28a36 100644 > --- a/target-ppc/translate_init.c > +++ b/target-ppc/translate_init.c > @@ -5133,7 +5133,7 @@ POWERPC_FAMILY(e500mc)(ObjectClass *oc, void *data) > dc->desc = "e500mc core"; > pcc->init_proc = init_proc_e500mc; > pcc->check_pow = check_pow_none; > -pcc->insns_flags = PPC_INSNS_BASE | PPC_ISEL | > +pcc->insns_flags = PPC_INSNS_BASE | PPC_ISEL | PPC_MFTB | > PPC_WRTEE | PPC_RFDI | PPC_RFMCI | > PPC_CACHE | PPC_CACHE_LOCK | PPC_CACHE_ICBI | > PPC_CACHE_DCBZ | PPC_CACHE_DCBA | > @@ -5179,7 +5179,7 @@ POWERPC_FAMILY(e5500)(ObjectClass *oc, void *data) > dc->desc = "e5500 core"; > pcc->init_proc = init_proc_e5500; > pcc->check_pow = check_pow_none; > -pcc->insns_flags = PPC_INSNS_BASE | PPC_ISEL | > +pcc->insns_flags = PPC_INSNS_BASE | PPC_ISEL | PPC_MFTB | > PPC_WRTEE | PPC_RFDI | PPC_RFMCI | > PPC_CACHE | PPC_CACHE_LOCK | PPC_CACHE_ICBI | > PPC_CACHE_DCBZ | PPC_CACHE_DCBA | -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson signature.asc Description: PGP signature
Re: [Qemu-devel] [RFC v2 01/13] target-ppc: Introduce Power9 family
On Sat, Jul 23, 2016 at 02:14:38PM +0530, Nikunj A Dadhania wrote:
> From: "Aneesh Kumar K.V"
>
> Signed-off-by: Aneesh Kumar K.V
> [ rebased and added POWER9 alias and POWER9 SPAPR core ]
> Signed-off-by: Nikunj A Dadhania
I can't really review this until the series is a bit more polished and
we have a better idea how the handling of the POWER9 MMU is going to
work. As it stands, this sets the P9 MMU type to something that only
makes sense in guest context, not host context.
> ---
> hw/ppc/spapr_cpu_core.c | 5 +++
> target-ppc/cpu-models.c | 5 +++
> target-ppc/cpu-models.h | 1 +
> target-ppc/cpu-qom.h| 7
> target-ppc/mmu_helper.c | 3 +-
> target-ppc/translate_init.c | 85
> -
> 6 files changed, 104 insertions(+), 2 deletions(-)
>
> diff --git a/hw/ppc/spapr_cpu_core.c b/hw/ppc/spapr_cpu_core.c
> index 9347f07..766c515 100644
> --- a/hw/ppc/spapr_cpu_core.c
> +++ b/hw/ppc/spapr_cpu_core.c
> @@ -351,6 +351,7 @@ SPAPR_CPU_CORE_INITFN(POWER7+_v2.1, POWER7plus);
> SPAPR_CPU_CORE_INITFN(POWER8_v2.0, POWER8);
> SPAPR_CPU_CORE_INITFN(POWER8E_v2.1, POWER8E);
> SPAPR_CPU_CORE_INITFN(POWER8NVL_v1.0, POWER8NVL);
> +SPAPR_CPU_CORE_INITFN(POWER9_v1.0, POWER9);
>
> typedef struct SPAPRCoreInfo {
> const char *name;
> @@ -394,6 +395,10 @@ static const SPAPRCoreInfo spapr_cores[] = {
> { .name = "POWER8NVL_v1.0", .initfn = spapr_cpu_core_POWER8NVL_initfn },
> { .name = "POWER8NVL", .initfn = spapr_cpu_core_POWER8NVL_initfn },
>
> +/* POWER9 and aliases */
> +{ .name = "POWER9_v1.0", .initfn = spapr_cpu_core_POWER9_initfn },
> +{ .name = "POWER9", .initfn = spapr_cpu_core_POWER9_initfn },
> +
> { .name = NULL }
> };
>
> diff --git a/target-ppc/cpu-models.c b/target-ppc/cpu-models.c
> index 5209e63..901cf40 100644
> --- a/target-ppc/cpu-models.c
> +++ b/target-ppc/cpu-models.c
> @@ -1147,6 +1147,10 @@
> "POWER8NVL v1.0")
> POWERPC_DEF("970_v2.2", CPU_POWERPC_970_v22,970,
> "PowerPC 970 v2.2")
> +
> +POWERPC_DEF("POWER9_v1.0", CPU_POWERPC_POWER9_BASE,POWER9,
> +"POWER9 v1.0")
> +
> POWERPC_DEF("970fx_v1.0",CPU_POWERPC_970FX_v10, 970,
> "PowerPC 970FX v1.0 (G5)")
> POWERPC_DEF("970fx_v2.0",CPU_POWERPC_970FX_v20, 970,
> @@ -1395,6 +1399,7 @@ PowerPCCPUAlias ppc_cpu_aliases[] = {
> { "POWER8E", "POWER8E_v2.1" },
> { "POWER8", "POWER8_v2.0" },
> { "POWER8NVL", "POWER8NVL_v1.0" },
> +{ "POWER9", "POWER9_v1.0" },
> { "970", "970_v2.2" },
> { "970fx", "970fx_v3.1" },
> { "970mp", "970mp_v1.1" },
> diff --git a/target-ppc/cpu-models.h b/target-ppc/cpu-models.h
> index f21a44c..7d9e6a2 100644
> --- a/target-ppc/cpu-models.h
> +++ b/target-ppc/cpu-models.h
> @@ -562,6 +562,7 @@ enum {
> CPU_POWERPC_POWER8_v20 = 0x004D0200,
> CPU_POWERPC_POWER8NVL_BASE = 0x004C,
> CPU_POWERPC_POWER8NVL_v10 = 0x004C0100,
> +CPU_POWERPC_POWER9_BASE= 0x004E,
> CPU_POWERPC_970_v22= 0x00390202,
> CPU_POWERPC_970FX_v10 = 0x00391100,
> CPU_POWERPC_970FX_v20 = 0x003C0200,
> diff --git a/target-ppc/cpu-qom.h b/target-ppc/cpu-qom.h
> index 2864105..df2fb65 100644
> --- a/target-ppc/cpu-qom.h
> +++ b/target-ppc/cpu-qom.h
> @@ -86,6 +86,13 @@ enum powerpc_mmu_t {
> POWERPC_MMU_2_07 = POWERPC_MMU_64 | POWERPC_MMU_1TSEG
> | POWERPC_MMU_64K
> | POWERPC_MMU_AMR | 0x0004,
> +/* for now , We can add radix later if needed */
> +/* POWERPC_MMU_3_00 = POWERPC_MMU_64 | POWERPC_MMU_1TSEG
> + * | POWERPC_MMU_AMR | 0x0005,
> + */
> +
> +POWERPC_MMU_3_00 = POWERPC_MMU_64 | POWERPC_MMU_AMR | 0x0005,
> +
> /* Architecture 2.07 "degraded" (no 1T segments) */
> POWERPC_MMU_2_07a = POWERPC_MMU_64 | POWERPC_MMU_AMR
> | 0x0004,
> diff --git a/target-ppc/mmu_helper.c b/target-ppc/mmu_helper.c
> index 3eb3cd7..dd0cf33 100644
> --- a/target-ppc/mmu_helper.c
> +++ b/target-ppc/mmu_helper.c
> @@ -1935,13 +1935,14 @@ void ppc_tlb_invalidate_all(CPUPPCState *env)
> case POWERPC_MMU_2_06a:
> case POWERPC_MMU_2_07:
> case POWERPC_MMU_2_07a:
> +case POWERPC_MMU_3_00:
> #endif /* defined(TARGET_PPC64) */
> env->tlb_need_flush = 0;
> tlb_flush(CPU(cpu), 1);
> break;
> default:
> /* XXX: TODO */
> -cpu_abort(CPU(cpu), "Unknown MMU model\n");
> +cpu_abort(CPU(cpu), "Unknown MMU model %d\n", env->mmu_model);
> break;
> }
> }
> diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c
> index 7cb7842..5b100d0 100644
> --- a/target-ppc/translate_init.c
> +++ b/target-ppc/translate_init.c
> @@ -7459,7 +7459,8 @@ en
Re: [Qemu-devel] [PATCH v3 1/2] qdev: ignore GlobalProperty.errp for hotplugged devices
On Fri, Jul 22, 2016 at 10:56:31AM -0300, Eduardo Habkost wrote: > On Fri, Jul 22, 2016 at 11:28:48AM +1000, David Gibson wrote: > > On Fri, Jul 22, 2016 at 01:01:26AM +0200, Greg Kurz wrote: > > > This patch ensures QEMU won't terminate while hotplugging a device if the > > > global property cannot be set and errp points to error_fatal or > > > error_abort. > > > > > > While here, it also fixes indentation of the typename argument. > > > > > > Suggested-by: Eduardo Habkost > > > Signed-off-by: Greg Kurz > > > > This seems kind of bogus to me - we have this whole infrastructure for > > handling errors, and here we throw it away. > > What is this patch throwing away? We have never been able to use > the error infrastructure properly while applying global > properties. "throwing away" was a bit too strong. But, it seems a shame that we have this error infrastructure which supposedly let's you report errors in a consistent way whether they be fatal or non-fatal, but here we're not able to use it to report a non-fatal error. > > It seems like the right solution would be to make the caller in the > > hotplug case *not* use error_abort or error_fatal, and instead get the > > error propagated back to the monitor which will display it. > > GlobalProperty::errp is a workaround to the fact that > ObjectClass::instance_post_init() can't report errors at all (and > that's because object_new() and object_initialize_with_type() > can't report errors. Do you have any suggestions to fix it? Is there an inherent reason object_initialize() and object_new() can't report errors? Or just that it hasn't been implemented yet? > I have suggested saving global property errors in a DeviceState > field and reporting then later on device_realize(). Maybe I > should implement it and send as RFC. Maybe. In any case my initial objection was because I hadn't realized the difficulty of implementing this in the error API, so I withdraw it. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson signature.asc Description: PGP signature
Re: [Qemu-devel] [PULL v3 00/55] pc, pci, virtio: new features, cleanups, fixes
On Fri, 07/22 10:46, Peter Maydell wrote: > On 22 July 2016 at 02:13, Fam Zheng wrote: > > On Thu, 07/21 11:45, Peter Maydell wrote: > >> It failed on several of my test builds, not just one, but these > >> things are tricky to avoid if they don't happen on all compilers. > >> In this case I think it is a compiler bug: > >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53119 > >> so you'll only see it with an older compiler. > > > > Could you name the distro and gcc version? If it's worth to keep the buggy > > compiler happy, it probably can be added as a docker test. :) > > I think ubuntu trusty stock gcc and the clang on OSX, probably > others too. We do have ubuntu trusty docker image, but I don't see the failure with this pull req. Adding an OSX image to docker is much trickier, so I've not really looked into that, yet. Could you give me an exact gcc version number that triggers the thing, to test again? Thanks, Fam
Re: [Qemu-devel] Fw:qemu driver_mirror error "Operation not permitted"
On Fri, 07/22 15:41, lisiheng wrote: > Hi All, > I use libvirtd to call qemu drive_mirror return error message "Operation not > permitted", Butdirectlyrunqemu and call drive_mirror is OK; > when drive_mirror target is logic device return error message "Operation not > permitted",But the file is OK; This may be better asked on libvirt list, but my first reaction would be checking the file permission bits and SELinux permissions. Fam
Re: [Qemu-devel] [PATCH v22 00/10] Block replication for continuous checkpoints
Hi all block maintainers Sorry to bother. COLO block is the necessary prerequisite of COLO framework and COLO network, what are blocked by these patchsets now. Since v19, Stefan said he had reviewed most part of this patchsets. So, this series *REALLY* need more comments from all of you. I've ping so many times, but no response until now. All i have to do is rebase them to the lastest code. Do you have time to review this? Any response would be appreciate. Thanks -Xie On 07/22/2016 06:15 PM, Wang WeiWei wrote: Block replication is a very important feature which is used for continuous checkpoints(for example: COLO). You can get the detailed information about block replication from here: http://wiki.qemu.org/Features/BlockReplication Usage: Please refer to docs/block-replication.txt You can get the patch here: https://github.com/wangww-fnst/qemu/tree/block-replication-v22 You can get the patch with framework here: https://github.com/wangww-fnst/qemu/tree/colo_framework_v21 TODO: 1. Continuous block replication. It will be started after basic functions are accepted. Changs Log: V22: 1. Rebase to the lastest code 2. modify code adapt to the modification of backup_start & commit_active_start 3. rewrite io_read & io_write for interface changes V21: 1. Rebase to the lastest code 2. use bdrv_pwrite_zeroes() and BDRV_SECTOR_BITS for p9 V20 Resend: 1. Resend to avoid bothering qemu-trivial maintainers 2. Address comments from Eric, fix header file issue and add a brief commit message for p7 V20: 1. Rebase to the lastest code 2. Address comments from stefan p8: 1. error_setg() with an error message when check_top_bs() fails. 2. remove bdrv_ref(s->hidden_disk->bs) since commit 5c438bc6 3. use bloc_job_cancel_sync() before active commit p9: 1. fix uninitialized 'pattern_buf' 2. introduce mkstemp(3) to fix unique filenames 3. use qemu_vfree() for qemu_blockalign() memory 4. add missing replication_start_all() 5. remove useless pattern for io_write() V19: 1. Rebase to v2.6.0 2. Address comments from stefan p3: a new patch that export interfaces for extra serialization p8: 1. call replication_stop() before freeing s->top_id 2. check top_bs 3. reopen file readonly in error return paths 4. enable extra serialization between read and COW p9: try to hanlde SIGABRT V18: p6: add local_err in all replication callbacks to prevent "errp == NULL" p7: add missing qemu_iovec_destroy(xxx) V17: 1. Rebase to the lastest codes p2: refactor backup_do_checkpoint addressed comments from Jeff Cody p4: fix bugs in "drive_add buddy xxx" hmp commands p6: add "since: 2.7" p7: fix bug in replication_close(), add missing "qapi/error.h", add test-replication p8: add "since: 2.7" V16: 1. Rebase to the newest codes 2. Address comments from Stefan & hailiang p3: we don't need this patch now p4: add "top-id" parameters for secondary p6: fix NULL pointer in replication callbacks, remove unnecessary typedefs, add doc comments that explain the semantics of Replication p7: Refactor AioContext for thread-safe, remove unnecessary get_top_bs() *Note*: I'm working on replication testcase now, will send out in V17 V15: 1. Rebase to the newest codes 2. Fix typos and coding style addresed Eric's comments 3. Address Stefan's comments 1) Make backup_do_checkpoint public, drop the changes on BlockJobDriver 2) Update the message and description for [PATCH 4/9] 3) Make replication_(start/stop/do_checkpoint)_all as global interfaces 4) Introduce AioContext lock to protect start/stop/do_checkpoint callbacks 5) Use BdrvChild instead of holding on to BlockDriverState * pointers 4. Clear BDRV_O_INACTIVE for hidden disk's open_flags since commit 09e0c771 5. Introduce replication_get_error_all to check replication status 6. Remove useless discard interface V14: 1. Implement auto complete active commit 2. Implement active commit block job for replication.c 3. Address the comments from Stefan, add replication-specific API and data structure, also remove old block layer APIs V13: 1. Rebase to the newest codes 2. Remove redundant marcos and semicolon in replication.c 3. Fix typos in block-replication.txt V12: 1. Rebase to the newest codes 2. Use backing reference to replcace 'allow-write-backing-file' V11: 1. Reopen the backing file when starting blcok replication if it is not opened in R/W mode 2. Unblock BLOCK_OP_TYPE_BACKUP_SOURCE and BLOCK_OP_TYPE_BACKUP_TARGET when opening backing file 3. Block the top BDS so there is only one block job for the top BDS and its backing chain. V10: 1. Use blockdev-remove-medium and blockdev-insert-medium to replace backing reference. 2. Address the comments from Eric Blake V9: 1. Update the error messages 2. Rebase to the newest qemu 3. Split child add/delete support. These patches are sent in another patchset. V8: 1. Address Alberto Garcia's comments V7: 1. Implement adding/removing quorum child. Remove the option non-connect. 2. Simplify the backing refrence optio
[Qemu-devel] [PATCH] hw/net/e1000: Fix compiler warning
slave:~/.xie/qemu-colo # gcc --version gcc (SUSE Linux) 4.3.4 [gcc-4_3-branch revision 152973] slave:~/.xie/qemu-colo # make -j8 CChw/net/e1000e_core.o hw/net/e1000e_core.c:56: warning: ‘e1000e_set_interrupt_cause’ declared inline after being called hw/net/e1000e_core.c:56: warning: previous declaration of ‘e1000e_set_interrupt_cause’ was here LINK x86_64-softmmu/qemu-system-x86_64 Signed-off-by: Changlong Xie --- hw/net/e1000e_core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hw/net/e1000e_core.c b/hw/net/e1000e_core.c index badb1fe..e0bd31c 100644 --- a/hw/net/e1000e_core.c +++ b/hw/net/e1000e_core.c @@ -52,7 +52,7 @@ second according to spec 10.2.4.2 */ #define E1000E_MAX_TX_FRAGS (64) -static void +static inline void e1000e_set_interrupt_cause(E1000ECore *core, uint32_t val); static inline void -- 1.9.3
Re: [Qemu-devel] [PATCH] hw/net/e1000: Fix compiler warning
Hi, s/e1000/e1000e/ in commit message subject, except this looks ok. Thanks for the patch, Dmitry Reviewed-by: Dmitry Fleytman > On 25 Jul 2016, at 06:48 AM, Changlong Xie wrote: > > slave:~/.xie/qemu-colo # gcc --version > gcc (SUSE Linux) 4.3.4 [gcc-4_3-branch revision 152973] > > slave:~/.xie/qemu-colo # make -j8 > CChw/net/e1000e_core.o > hw/net/e1000e_core.c:56: warning: ‘e1000e_set_interrupt_cause’ declared > inline after being called > hw/net/e1000e_core.c:56: warning: previous declaration of > ‘e1000e_set_interrupt_cause’ was here > LINK x86_64-softmmu/qemu-system-x86_64 > > Signed-off-by: Changlong Xie > --- > hw/net/e1000e_core.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/hw/net/e1000e_core.c b/hw/net/e1000e_core.c > index badb1fe..e0bd31c 100644 > --- a/hw/net/e1000e_core.c > +++ b/hw/net/e1000e_core.c > @@ -52,7 +52,7 @@ > second according to spec 10.2.4.2 */ > #define E1000E_MAX_TX_FRAGS (64) > > -static void > +static inline void > e1000e_set_interrupt_cause(E1000ECore *core, uint32_t val); > > static inline void > -- > 1.9.3 > > >
Re: [Qemu-devel] TCG problem with cpu_{st,ld}x_data ?
On Mon, 2016-07-25 at 06:04 +0530, Richard Henderson wrote:
> I noticed a related problem recently, while working on the cmpxchg patch set.
>
> In my opinion, we should (1) merge GETRA and GETPC so there's no confusion
> between the two, (2) push all adjustment down to the final moment before use,
> perhaps in cpu_restore_state.
>
> Thus a null value would be properly retained until checked, and one can
> easily
> call the memory helper functions without confusion.
Ok, after a bit more scrubbing of the code I think I understand what you
mean.
Now assuming we fix that, there is still a problem if the target code, such
as the PPC code, calls a helper that might cause a fault without first
updating the PC in the env, right ? IE. On powerpc for example, that means
that any instruction using a helper that might potentially do loads or stores
needs to first call gen_update_nip().
(The same way we seem to do before generating other exceptions such as traps,
well provided we do it correctly everywhere, I need to double check).
Either that, or change the helpers to capture the PC using GETPC/GETRA from
the first level of helper function (so as to ensure the return address is
correct).
Am I right ?
IE. Even if we fix the 0 vs. -2 problem, I still need this patch:
--- a/target-ppc/translate.c
+++ b/target-ppc/translate.c
@@ -6916,6 +6916,7 @@ static void gen_lve##name(DisasContext *ctx)
\
if (size > 1) { \
tcg_gen_andi_tl(EA, EA, ~(size - 1)); \
} \
+gen_update_nip(ctx, ctx->nip - 4); \
rs = gen_avr_ptr(rS(ctx->opcode)); \
gen_helper_lve##name(cpu_env, rs, EA); \
tcg_temp_free(EA); \
@@ -6937,6 +6938,7 @@ static void gen_stve##name(DisasContext *ctx)
\
if (size > 1) { \
tcg_gen_andi_tl(EA, EA, ~(size - 1)); \
} \
+gen_update_nip(ctx, ctx->nip - 4); \
rs = gen_avr_ptr(rS(ctx->opcode)); \
gen_helper_stve##name(cpu_env, rs, EA); \
tcg_temp_free(EA); \
(And possibly others I haven't yet audited)
Cheers,
Ben.
Re: [Qemu-devel] [RFC v2 05/13] target-ppc: add modulo word operations
Richard Henderson writes:
> On 07/23/2016 02:14 PM, Nikunj A Dadhania wrote:
>> Adding following instructions:
>>
>> moduw: Modulo Unsigned Word
>> modsw: Modulo Signed Word
>>
>> Signed-off-by: Nikunj A Dadhania
>> ---
>> target-ppc/helper.h | 2 ++
>> target-ppc/int_helper.c | 15 +++
>> target-ppc/translate.c | 19 +++
>> 3 files changed, 36 insertions(+)
>>
>> diff --git a/target-ppc/helper.h b/target-ppc/helper.h
>> index 1f5cfd0..76072fd 100644
>> --- a/target-ppc/helper.h
>> +++ b/target-ppc/helper.h
>> @@ -41,6 +41,8 @@ DEF_HELPER_FLAGS_1(cntlzw, TCG_CALL_NO_RWG_SE, tl, tl)
>> DEF_HELPER_FLAGS_1(popcntb, TCG_CALL_NO_RWG_SE, tl, tl)
>> DEF_HELPER_FLAGS_1(popcntw, TCG_CALL_NO_RWG_SE, tl, tl)
>> DEF_HELPER_FLAGS_2(cmpb, TCG_CALL_NO_RWG_SE, tl, tl, tl)
>> +DEF_HELPER_FLAGS_2(modsw, TCG_CALL_NO_RWG_SE, i32, i32, i32)
>> +DEF_HELPER_FLAGS_2(moduw, TCG_CALL_NO_RWG_SE, i32, i32, i32)
>> DEF_HELPER_3(sraw, tl, env, tl, tl)
>> #if defined(TARGET_PPC64)
>> DEF_HELPER_FLAGS_1(cntlzd, TCG_CALL_NO_RWG_SE, tl, tl)
>> diff --git a/target-ppc/int_helper.c b/target-ppc/int_helper.c
>> index 7445376..631e0b4 100644
>> --- a/target-ppc/int_helper.c
>> +++ b/target-ppc/int_helper.c
>> @@ -139,6 +139,21 @@ uint64_t helper_divde(CPUPPCState *env, uint64_t rau,
>> uint64_t rbu, uint32_t oe)
>>
>> #endif
>>
>> +uint32_t helper_modsw(uint32_t rau, uint32_t rbu)
>> +{
>> +int32_t ra = (int32_t) rau;
>> +int32_t rb = (int32_t) rbu;
>> +
>> +if ((rb == 0) || (ra == INT32_MIN && rb == -1)) {
>> +return 0;
>> +}
>> +return ra % rb;
>> +}
>> +
>> +uint32_t helper_moduw(uint32_t ra, uint32_t rb)
>> +{
>> +return rb ? ra % rb : 0;
>> +}
>
> I think, like you, I got distracted by the current div implementation in ppc.
> I've just re-read the spec and seen the "undefined" language. Which of
> course
> gives us much more freedom.
Right, I too thought of the same but didn't do it in this series.
Current div implementation is pretty complicated.
> With this freedom, we can do the division inline, without branches. Please
> see
> target-mips/translate.c, gen_r6_muldiv.
>
> Basically, we check for the offending cases and modify the divisor prior to
> the
> division. For unsigned:
>
> a / (b == 0 ? 1 : b)
>
> For signed:
>
> a / ((a == INT_MAX & b == -1) | (b == 0) ? : b)
Sure, will add it in this series.
Regards
Nikunj
[Qemu-devel] [PATCH v2] hw/net/e1000e: Fix compiler warning
slave:~/.xie/qemu-colo # gcc --version gcc (SUSE Linux) 4.3.4 [gcc-4_3-branch revision 152973] slave:~/.xie/qemu-colo # make -j8 CChw/net/e1000e_core.o hw/net/e1000e_core.c:56: warning: ‘e1000e_set_interrupt_cause’ declared inline after being called hw/net/e1000e_core.c:56: warning: previous declaration of ‘e1000e_set_interrupt_cause’ was here LINK x86_64-softmmu/qemu-system-x86_64 Reviewed-by: Dmitry Fleytman Signed-off-by: Changlong Xie --- hw/net/e1000e_core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hw/net/e1000e_core.c b/hw/net/e1000e_core.c index badb1fe..e0bd31c 100644 --- a/hw/net/e1000e_core.c +++ b/hw/net/e1000e_core.c @@ -52,7 +52,7 @@ second according to spec 10.2.4.2 */ #define E1000E_MAX_TX_FRAGS (64) -static void +static inline void e1000e_set_interrupt_cause(E1000ECore *core, uint32_t val); static inline void -- 1.9.3
[Qemu-devel] [PATCH v6] qemu-img: add the 'dd' subcommand
This patch adds a basic dd subcommand analogous to dd(1) to qemu-img.
For the start, this implements the bs, if, of and count options and requires
both if and of to be specified (no stdin/stdout if not specified) and doesn't
support tty, pipes, etc.
The image format must be specified with -O for the output if the raw format
is not the intended one.
Two tests are added to test qemu-img dd.
Signed-off-by: Reda Sallahi
---
Changes from v5:
* Add dd sections on qemu-img.texi.
Changes from v4:
* Fix the exit status.
Changes from v3:
* Delete an unused (so far) field in DdIo.
Changes from v2:
* Add copyright headers to new files.
Changes from v1:
* Removal of dead code.
* Fix a memory leak.
* Complete the cleanup function in the test cases.
qemu-img-cmds.hx | 6 +
qemu-img.c | 363 ++-
qemu-img.texi| 25 +++
tests/qemu-iotests/158 | 68
tests/qemu-iotests/158.out | 15 ++
tests/qemu-iotests/159 | 70
tests/qemu-iotests/159.out | 87 ++
tests/qemu-iotests/common.filter | 9 +
tests/qemu-iotests/group | 2 +
9 files changed, 644 insertions(+), 1 deletion(-)
create mode 100755 tests/qemu-iotests/158
create mode 100644 tests/qemu-iotests/158.out
create mode 100755 tests/qemu-iotests/159
create mode 100644 tests/qemu-iotests/159.out
diff --git a/qemu-img-cmds.hx b/qemu-img-cmds.hx
index 7e95b2d..03bdd7a 100644
--- a/qemu-img-cmds.hx
+++ b/qemu-img-cmds.hx
@@ -45,6 +45,12 @@ STEXI
@item convert [--object @var{objectdef}] [--image-opts] [-c] [-p] [-q] [-n]
[-f @var{fmt}] [-t @var{cache}] [-T @var{src_cache}] [-O @var{output_fmt}] [-o
@var{options}] [-s @var{snapshot_id_or_name}] [-l @var{snapshot_param}] [-S
@var{sparse_size}] @var{filename} [@var{filename2} [...]] @var{output_filename}
ETEXI
+DEF("dd", img_dd,
+"dd [--image-opts] [-f fmt] [-O output_fmt] [bs=block_size] [count=blocks]
if=input of=output")
+STEXI
+@item dd [--image-opts] [-f @var{fmt}] [-O @var{output_fmt}]
[bs=@var{block_size}] [count=@var{blocks}] if=@var{input} of=@var{output}
+ETEXI
+
DEF("info", img_info,
"info [--object objectdef] [--image-opts] [-f fmt] [--output=ofmt]
[--backing-chain] filename")
STEXI
diff --git a/qemu-img.c b/qemu-img.c
index 2e40e1f..498626b 100644
--- a/qemu-img.c
+++ b/qemu-img.c
@@ -166,7 +166,14 @@ static void QEMU_NORETURN help(void)
"Parameters to compare subcommand:\n"
" '-f' first image format\n"
" '-F' second image format\n"
- " '-s' run in Strict mode - fail on different image size or sector
allocation\n";
+ " '-s' run in Strict mode - fail on different image size or sector
allocation\n"
+ "\n"
+ "Parameters to dd subcommand:\n"
+ " 'bs=BYTES' read and write up to BYTES bytes at a time "
+ "(default: 512)\n"
+ " 'count=N' copy only N input blocks\n"
+ " 'if=FILE' read from FILE\n"
+ " 'of=FILE' write to FILE\n";
printf("%s\nSupported formats:", help_msg);
bdrv_iterate_format(format_print, NULL);
@@ -3794,6 +3801,360 @@ out:
return 0;
}
+#define C_BS 01
+#define C_COUNT 02
+#define C_IF 04
+#define C_OF 010
+
+struct DdInfo {
+unsigned int flags;
+size_t count;
+};
+
+struct DdIo {
+size_t bsz;/* Block size */
+char *filename;
+uint8_t *buf;
+};
+
+struct DdOpts {
+const char *name;
+int (*f)(const char *, struct DdIo *, struct DdIo *, struct DdInfo *);
+unsigned int flag;
+};
+
+/*
+ * get_size() was needed for the size syntax dd(1) supports which is
+ * different from qemu_strtosz_suffix()
+ *
+ */
+static size_t get_size(const char *str)
+{
+/* XXX: handle {k,m,g}B notations */
+unsigned long num;
+size_t res = 0;
+const char *buf;
+int ret;
+
+errno = 0;
+if (strchr(str, '-')) {
+error_report("invalid number: '%s'", str);
+errno = EINVAL;
+return res;
+}
+ret = qemu_strtoul(str, &buf, 0, &num);
+
+if (ret < 0) {
+error_report("invalid number: '%s'", str);
+return res;
+}
+
+switch (*buf) {
+case '\0':
+case 'c':
+res = num;
+break;
+case 'w':
+res = num * 2;
+break;
+case 'b':
+res = num * 512;
+break;
+case 'K':
+res = num * 1024;
+break;
+case 'M':
+res = num * 1024 * 1024;
+break;
+case 'G':
+res = num * 1024 * 1024 * 1024;
+break;
+case 'T':
+res = num * 1024 * 1024 * 1024 * 1024;
+break;
+case 'P':
+res = num * 1024 * 1024 * 1024 * 1024 * 1024;
+break;
+case 'E':
+res = num * 1024 * 1024 * 1024 * 1024 * 1024 * 1024;
+break;
+case 'Z':
+res = num * 1024 * 1024 * 1024 * 1024 * 1024 * 1024 * 1024;
+break;
+case 'Y'
Re: [Qemu-devel] [Qemu-ppc] [RFC v2 05/13] target-ppc: add modulo word operations
Nikunj A Dadhania writes:
> Richard Henderson writes:
>
>> On 07/23/2016 02:14 PM, Nikunj A Dadhania wrote:
>> +uint32_t helper_modsw(uint32_t rau, uint32_t rbu)
>>> +{
>>> +int32_t ra = (int32_t) rau;
>>> +int32_t rb = (int32_t) rbu;
>>> +
>>> +if ((rb == 0) || (ra == INT32_MIN && rb == -1)) {
>>> +return 0;
>>> +}
>>> +return ra % rb;
>>> +}
>>> +
>>> +uint32_t helper_moduw(uint32_t ra, uint32_t rb)
>>> +{
>>> +return rb ? ra % rb : 0;
>>> +}
>>
>> I think, like you, I got distracted by the current div implementation in
>> ppc.
>> I've just re-read the spec and seen the "undefined" language. Which of
>> course
>> gives us much more freedom.
>
> Right, I too thought of the same but didn't do it in this series.
> Current div implementation is pretty complicated.
To be precise gen_op_arith_div[d,w]() implementation.
>> With this freedom, we can do the division inline, without branches. Please
>> see
>> target-mips/translate.c, gen_r6_muldiv.
>>
>> Basically, we check for the offending cases and modify the divisor prior to
>> the
>> division. For unsigned:
>>
>> a / (b == 0 ? 1 : b)
>>
>> For signed:
>>
>> a / ((a == INT_MAX & b == -1) | (b == 0) ? : b)
>
> Sure, will add it in this series.
>
> Regards
> Nikunj
Re: [Qemu-devel] [RFC v4] virtio-crypto specification
On Monday, July 25, 2016 9:38 AM Gonglei (Arei) wrote:
>
> Hi Xin,
>
>
> > -Original Message-
> > From: Zeng, Xin [mailto:xin.z...@intel.com]
> > Sent: Friday, July 22, 2016 1:31 PM
> > To: Gonglei (Arei); virtio-...@lists.oasis-open.org;
> > qemu-devel@nongnu.org
> > Cc: Hanweidong (Randy); Stefan Hajnoczi; Cornelia Huck;
> > m...@redhat.com; Lingli Deng; Jani Kokkonen; Luonengjun; Huangpeng
> > (Peter); Zhoujian (jay, Euler); chenshanxi 00222737; 'Ola
> > liljed...@arm.com'; Varun Sethi
> > Subject: RE: [RFC v4] virtio-crypto specification
> >
> > On Friday, July 22, 2016 10:53 AM Gonglei (Arei) wrote:
> > >
> > > Hi Xin,
> > >
> > > Thank you so much for your great comments.
> > > I agree with you almostly except some trivial detals.
> > > Please see my below replies.
> > >
> > > And I'll submit V5 next week, and you can finish the asym algos
> > > parts if you like.
> > > Let's co-work to finish the virtio-crypto spec, shall we?
> > >
> >
> > That's great.
> >
> > > Regards,
> > > -Gonglei
> > >
> > >
> > > > -Original Message-
> > > > From: Zeng, Xin [mailto:xin.z...@intel.com]
> > > > Sent: Friday, July 22, 2016 8:48 AM
> > > > To: Gonglei (Arei); virtio-...@lists.oasis-open.org; qemu-
> > > de...@nongnu.org
> > > > Cc: Hanweidong (Randy); Stefan Hajnoczi; Cornelia Huck;
> > > > m...@redhat.com; Lingli Deng; Jani Kokkonen; Luonengjun; Huangpeng
> > > > (Peter); Zhoujian (jay, Euler); chenshanxi 00222737; 'Ola
> > > > liljed...@arm.com'; Varun Sethi
> > > > Subject: RE: [RFC v4] virtio-crypto specification
> > > >
> > > > On Sunday, June 26, 2016 5:35 PM, Gonglei (Arei) Wrote:
> > > > > Hi all,
> > > > >
> > > > > This is the specification (version 4) about a new virtio crypto
> > > > > device.
> > > > >
> > > >
> > > > In general, our comments around this proposal are listed below:
> > > > 1. Suggest to introduce crypto services into virtio crypto device.
> > > > The
> > > services
> > > > currently defined are CIPHER, MAC, HASH, AEAD, KDF, ASYM,
> PRIMITIVE.
> > >
> > > Yes, I agree, whether DRBG/NDRBG are included in PRIMITIVE service
> > > or not?
> > > If not, we'd better add another separate service.
> >
> > Yes, I think we can add these two into PRIMITIVE services.
> >
> > >
> > > > 2. Suggest to define a unified crypto request format that is
> > > > consisted of general header + service specific request, Where
> > > > 'general header' is for all crypto request, 'service specific
> > > > request' is composed of operation parameter + input data + output
> data in generally.
> > > > operation parameter is algorithm-specific parameters, input data
> > > > is the data should be operated , output data is the "operation
> > > > result + result buffer".
> > > >
> > > It makes sense. Good.
> > >
> > > > #define VIRTIO_CRYPTO_OPCODE(service, op) (((service)<<8) | (op))
> > > > struct virtio_crypto_op_header {
> > > > #define VIRTIO_CRYPTO_CIPHER_ENCRYPT
> > > > VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_S_CIPHER, 0x00) #define
> > > > VIRTIO_CRYPTO_CIPHER_DECRYPT
> > > > VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_S_CIPHER, 0x01) #define
> > > > VIRTIO_CRYPTO_HASH
> > > > VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_S_HASH, 0x00) #define
> > > > VIRTIO_CRYPTO_MAC
> VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_S_MAC, 0x00)
> > > > #define VIRTIO_CRYPTO_KDF
> > > > VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_S_KDF, 0x00)
> #define
> > > > VIRTIO_CRYPTO_ASYM_KEY_GEN
> > > > VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_S_ASYM, 0x00) #define
> > > > VIRTIO_CRYPTO_ASYM_KEY_EXCHG
> > > > VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_S_ASYM, 0x01) #define
> > > > VIRTIO_CRYPTO_ASYM_SIGN
> > > > VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_S_ASYM, 0x02) #define
> > > > VIRTIO_CRYPTO_ASYM_VERIFY
> > > > VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_S_ASYM, 0x03) #define
> > > > VIRTIO_CRYPTO_ASYM_ENCRYPT
> > > > VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_S_ASYM, 0x04) #define
> > > > VIRTIO_CRYPTO_ASYM_DECRYPT
> > > > VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_S_ASYM, 0x05) #define
> > > > VIRTIO_CRYPTO_AEAD_ENCRYPT
> > > > VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_S_AEAD, 0x00) #define
> > > > VIRTIO_CRYPTO_AEAD_DECRYPT
> > > > VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_S_AEAD, 0x01) #define
> > > > VIRTIO_CRYPTO_PRIMITIVE
> > > > VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_S_PRIMITIVE, 0x00)
> > > > u32 opcode;
> > > > u8 algo; /*service-specific algorithms*/
> > > > u8 flag; /*control flag*/
> > >
> > > We'd better add a U64 session_id property here for service-specific
> > > algorithms.
> > >
> >
> > Can we put session_id into parameter filed inside service-specific request?
> > For ASYM service, it doesn't need session_id.
> > And for HASH service, it might not need a session_id as well.
> >
> I don't think so, the function of session_id property is the same with algo
> property here, It's also service-specific algorithms. We don't know which
> session_id we could use if we
Re: [Qemu-devel] [PATCH v3 0/2] vhost-user: Extend protocol to receive replies on any command.
On Thu, Jul 7, 2016 at 12:04 PM, Prerna Saxena wrote: > From: Prerna Saxena > > The current vhost-user protocol requires the client to send responses to > only a > few commands. For the remaining commands, it is impossible for QEMU to > know the > status of the requested operation -- ie, did it succeed? If so, by what > time? > > This is inconvenient, and can also lead to races. As an example: > [..snip..] > > References: > v1 : https://lists.gnu.org/archive/html/qemu-devel/2016-06/msg07152.html > v2 : https://lists.gnu.org/archive/html/qemu-devel/2016-07/msg00048.html > > > Prerna Saxena (2): > vhost-user: Introduce a new protocol feature REPLY_ACK. > vhost-user: Attempt to fix a race with set_mem_table. > > docs/specs/vhost-user.txt | 44 +++ > hw/virtio/vhost-user.c| 133 > ++ > 2 files changed, 130 insertions(+), 47 deletions(-) > > Ping ! Michael, MarcAndre, Did you have a chance to look at this patch series? Regards, Prerna
