Re: [Qemu-devel] virsh dump (qemu guest memory dump?): KASLR enabled linux guest support
On 11/09/16 at 03:42pm, Wen Congyang wrote: > On 11/09/2016 01:02 PM, Dave Young wrote: > > On 11/09/16 at 11:58am, Wen Congyang wrote: > >> On 11/09/2016 11:17 AM, Dave Young wrote: > >>> Drop qiaonuohan, seems the mail address is wrong.. > >>> > >>> On 11/09/16 at 11:01am, Dave Young wrote: > Hi, > > Latest linux kernel enabled kaslr to randomiz phys/virt memory > addresses, we had some effort to support kexec/kdump so that crash > utility can still works in case crashed kernel has kaslr enabled. > > But according to Dave Anderson virsh dump does not work, quoted messages > from Dave below: > > """ > with virsh dump, there's no way of even knowing that KASLR > has randomized the kernel __START_KERNEL_map region, because there is no > virtual address information -- e.g., like "SYMBOL(_stext)" in the kdump > vmcoreinfo data to compare against the vmlinux file symbol value. > Unless virsh dump can export some basic virtual memory data, which > they say it can't, I don't see how KASLR can ever be supported. > """ > > I assume virsh dump is using qemu guest memory dump facility so it > should be first addressed in qemu. Thus post this query to qemu devel > list. If this is not correct please let me know. > >> > >> IIRC, 'virsh dump --memory-only' uses dump-guest-memory, and 'virsh dump' > >> uses migration to dump. > > > > Do they need different fixes? Dave, I guess you mean --memory-only, but > > could you clarify and confirm it? > > > >> > >> I think I should study kaslr first... > > > > Thanks for taking care of it. > > Can you give me the patch for kexec/kdump. I want to know what I need to do > for dump-guest-memory. AFAIK, there are below patches for kexec/kdump userspace: kexec-tools, git commit: commit 9f62cbfc93d78d9aafbddf3e1208cb242f7b Author: Thomas Garnier Date: Tue Sep 13 15:10:05 2016 +0800 kexec/arch/i386: Add support for KASLR memory randomization Originally Baoquan He posted below patches to export vmcoreinfo for some kernel fields: http://lists.infradead.org/pipermail/kexec/2016-September/017191.html But later it was dropped, we finally do it in userspace with several makedumpfile patches: http://lists.infradead.org/pipermail/kexec/2016-October/017540.html http://lists.infradead.org/pipermail/kexec/2016-October/017539.html http://lists.infradead.org/pipermail/kexec/2016-October/017541.html For virsh dumped vmcore it should manage to export some infomation so that crash utility can use. I would leave Dave to provide more information what he needs because the goal is userspace utility like crash can correctly analysis the vmcore. > > Thanks > Wen Congyang > > > > >> > >> Thanks > >> Wen Congyang > >> > > Could you qemu dump people make it work? Or we can not support virt dump > as long as KASLR being enabled. Latest Fedora kernel has enabled it in > x86_64. > > Thanks > Dave > >>> > >>> > >>> > >> > >> > >> > > > > > > . > > > > >
Re: [Qemu-devel] [virtio-comment] Re: [PATCH v1] docs/vhost-user: extend the vhost-user protocol to support the vhost-pci based inter-vm communication
On 11/08/2016 08:17 PM, Marc-André Lureau wrote: > > Message Specification > - > > Note that all numbers are in the machine native byte order. A > vhost-user message > -consists of 3 header fields and a payload: > +consists of 4 header fields and a payload: > > - > -| request | flags | size | payload | > - > +-- > +| request | flags | conn_id | size | payload | > +-- > > * Request: 32-bit type of the request > * Flags: 32-bit bit field: > - Lower 2 bits are the version (currently 0x01) > - - Bit 2 is the reply flag - needs to be sent on each reply > from the slave > + - Bit 2 is the reply flag - needs to be sent on each reply > - Bit 3 is the need_reply flag - see > VHOST_USER_PROTOCOL_F_REPLY_ACK for > details. > + * Conn_id: 64-bit connection id to indentify a client socket > connection. It is > +introduced in version 0x02 to support the > "1-server-N-client" model > +and an asynchronous client read implementation. The > connection id, > +0x, is used by an anonymous client > (e.g. a client who > +has not got its connection id from the server in the > initial talk) > > > I don't understand why you need a connection id, on each message. > What's the purpose? Since the communication is unicast, a single > message should be enough. Sure, please let me explain more: The QEMU socket is going to be upgraded to support 1 server socket being connected by multiple client sockets (I've made patches to achieve this). In other words, here, multiple masters will connect to one slave, and the slave creates a vhost-pci device for each master after receiving the necessary message info. The slave needs to know which master it is talking to when receiving a message, as it maintains multiple connections at the same time. You should be able to identify each connection in the slave (as a socket server), without a need for connection id: connected sockets are independent from each others. Yes, that's doable. But why couldn't we do it from the protocol layer? I think it will be easier. Please check below my thoughts about the implementation if we do it in the slave: The interface for receiving a msg is - tcp_chr_read(QIOChannel *chan, GIOCondition cond, void *opaque) QIOChannel is the one that we can use to identify the master connection who sends this msg (the socket server now has an array of QIOChannel, ioc[MAX_CLIENTS]). Everytime a msg is received, the tcp_chr_read() needs to compare *chan and the ioc[] array, to find out the id (indexed into the ioc[]), and passes the id to qemu_chr_be_write(), and all the way down to the final slave handler where the msg is parsed and handled. This needs modifications to the existing APIs, for example, the mentioned qemu_chr_be_write() will need one more parameter, "id". This will not be compatible with the existing implementation, because all other implementations which invoke qemu_chr_be_write() will need to be patched to use the new qemu_chr_be_write(,"id",). > * Size - 32-bit size of the payload > > > @@ -97,6 +106,13 @@ Depending on the request type, payload can be: > log offset: offset from start of supplied file descriptor > where logging starts (i.e. where guest address 0 would be > logged) > > +* Device info > + > + | virito id | uuid | > + > + Virtio id: 16-bit virtio id of the device > + UUID: 128-bit UUID to identify the QEMU instance that creates > the device > + > > > I wonder if UUID should be a different message. > We can make uuid another message if it has other usages. Do you see any other usages of uuid? Allows to associate data/configuration with a particular VM, in a multi-master/single-slave scenario. But tbh, I don't see how this is necessary, I can imagine solving this differently (having different connection address per vm for ex). Using connection addresses, how could you know if the two connections are from the same VM? I would like to understand your use case. Here is an example of the use case: VM1 has two master connections (connection X and Y) and VM2 has 1 master connection (Z). X,Y,Z - each has a connection id. But X and Y send the same uuid, uuid1, to the slave, and Z sends uuid2 to the slave. In this w
Re: [Qemu-devel] [kvm-unit-tests PATCH v4 10/11] arm/arm64: gicv3: add an IPI test
Argh. I forgot to compile/test arm32/gicv3... Just did now and found
a copy+paste error.
On Tue, Nov 08, 2016 at 09:21:38PM +0100, Andrew Jones wrote:
[...]
> diff --git a/lib/arm/asm/arch_gicv3.h b/lib/arm/asm/arch_gicv3.h
> index 81a1e5f6c29c..cbcec024a2a6 100644
> --- a/lib/arm/asm/arch_gicv3.h
> +++ b/lib/arm/asm/arch_gicv3.h
> @@ -16,10 +16,28 @@
> #define __stringify xstr
>
> #define __ACCESS_CP15(CRn, Op1, CRm, Op2)p15, Op1, %0, CRn, CRm, Op2
> +#define __ACCESS_CP15_64(Op1, CRm) p15, Op1, %Q0, %R0, CRm
>
> +#define ICC_EOIR1__ACCESS_CP15(c12, 0, c12, 1)
> +#define ICC_IAR1 __ACCESS_CP15(c12, 0, c12, 0)
> +#define ICC_SGI1R__ACCESS_CP15_64(0, c12)
> #define ICC_PMR __ACCESS_CP15(c4, 0, c6, 0)
> #define ICC_IGRPEN1 __ACCESS_CP15(c12, 0, c12, 7)
>
> +static inline void gicv3_write_eoir(u32 irq)
> +{
> + asm volatile("mcr " __stringify(ICC_EOIR1) : : "r" (val));
should be irq ^^
> + isb();
> +}
> +
[...]
I've pushed an arm/gic-v5 branch[*] to github, and removed the broken
arm/gic-v4 branch.
[*] https://github.com/rhdrjones/kvm-unit-tests/commits/arm/gic-v5
drew
Re: [Qemu-devel] [PATCH] Fix legacy ncurses detection.
On Tue, 8 Nov 2016 21:10:19 +0100 Samuel Thibault wrote: > Cornelia Huck, on Tue 08 Nov 2016 12:34:49 +0100, wrote: > > > diff --git a/configure b/configure > > > index fd6f898..e200aa8 100755 > > > --- a/configure > > > +++ b/configure > > > @@ -2926,7 +2926,7 @@ if test "$curses" != "no" ; then > > > curses_inc_list="$($pkg_config --cflags ncurses 2>/dev/null):" > > > curses_lib_list="$($pkg_config --libs ncurses > > > 2>/dev/null):-lpdcurses" > > >else > > > -curses_inc_list="$($pkg_config --cflags ncursesw 2>/dev/null):" > > > +curses_inc_list="$($pkg_config --cflags ncursesw > > > 2>/dev/null):-I/usr/include/ncursesw:" > > > > This arrives at > > > > curses_inc_list=":-I/usr/include/ncursesw:" > > > > which causes the parser below to start with an empty curses_inc (with : > > as separator). > > Yes, this is expected. > > > configure fails as before (with -Werror; passes without). > > Ah! > So are you getting the following message? > > “ > configure test passed without -Werror but failed with -Werror. > This is probably a bug in the configure script. The failing command > will be at the bottom of config.log. > You can run configure with --disable-werror to bypass this check. > ” > > If so, you should really have said it, I was really wondering how > configure could just stopping in your case. That does explain things > indeed. I said so in my very first mail for the issue... appears I was unclear. > > Could you try the attached patch? It should be able to really fail > without Werror too. With your patch, configure runs through and detects curses=no. Not sure that's correct, though: SLES12SP1 _does_ have curses, but not a .pc file for ncursesw. I don't know enough about curses to say whether it should be that way...
Re: [Qemu-devel] [PATCH] Fix legacy ncurses detection.
Hello, Cornelia Huck, on Wed 09 Nov 2016 09:58:59 +0100, wrote: > On Tue, 8 Nov 2016 21:10:19 +0100 > Samuel Thibault wrote: > > Cornelia Huck, on Tue 08 Nov 2016 12:34:49 +0100, wrote: > > “ > > configure test passed without -Werror but failed with -Werror. > > This is probably a bug in the configure script. The failing command > > will be at the bottom of config.log. > > You can run configure with --disable-werror to bypass this check. > > ” > > > > If so, you should really have said it, I was really wondering how > > configure could just stopping in your case. That does explain things > > indeed. > > I said so in my very first mail for the issue... appears I was unclear. Do you mean "configure barfs about -Werror."? Yes it was unclear to me :) > > Could you try the attached patch? It should be able to really fail > > without Werror too. > > With your patch, configure runs through and detects curses=no. Not sure > that's correct, though: SLES12SP1 _does_ have curses, but not a .pc > file for ncursesw. I don't know enough about curses to say whether it > should be that way... Please post config.log so we can have a clue about what is going wrong. All these error messages are meant to be reported verbatim, not reinterpreted :) Samuel
Re: [Qemu-devel] [PATCH] Fix legacy ncurses detection.
On Wed, 9 Nov 2016 10:04:02 +0100 Samuel Thibault wrote: > Please post config.log so we can have a clue about what is going > wrong. All these error messages are meant to be reported verbatim, not > reinterpreted :) Well, no error here - just curses=no. config.log attached. The difference seems to be that the statement you added in the sample program causes a real error instead of a warning. Is the SLES12SP1 version of curses supposed to do that? (Maybe Michal knows.) # QEMU configure log Wed Nov 9 09:53:34 CET 2016 # Configured with: '/home/cohuck/git/qemu/build/../configure' '--target-list=s390x-softmmu s390x-linux-user' '--enable-kvm' '--enable-vhost-net' '--enable-linux-aio' # cc -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -c -o config-temp/qemu-conf.o config-temp/qemu-conf.c cc -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -c -o config-temp/qemu-conf.o config-temp/qemu-conf.c config-temp/qemu-conf.c:2:2: error: #error __i386__ not defined #error __i386__ not defined ^ cc -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -c -o config-temp/qemu-conf.o config-temp/qemu-conf.c config-temp/qemu-conf.c:2:2: error: #error __x86_64__ not defined #error __x86_64__ not defined ^ cc -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -c -o config-temp/qemu-conf.o config-temp/qemu-conf.c config-temp/qemu-conf.c:2:2: error: #error __sparc__ not defined #error __sparc__ not defined ^ cc -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -c -o config-temp/qemu-conf.o config-temp/qemu-conf.c config-temp/qemu-conf.c:2:2: error: #error _ARCH_PPC not defined #error _ARCH_PPC not defined ^ cc -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -c -o config-temp/qemu-conf.o config-temp/qemu-conf.c config-temp/qemu-conf.c:2:2: error: #error __mips__ not defined #error __mips__ not defined ^ cc -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -c -o config-temp/qemu-conf.o config-temp/qemu-conf.c config-temp/qemu-conf.c:2:2: error: #error __ia64__ not defined #error __ia64__ not defined ^ cc -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -c -o config-temp/qemu-conf.o config-temp/qemu-conf.c cc -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -c -o config-temp/qemu-conf.o config-temp/qemu-conf.c cc -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -c -o config-temp/qemu-conf.o config-temp/qemu-conf.c cc -Werror -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -c -o config-temp/qemu-conf.o config-temp/qemu-conf.c cc -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -o config-temp/qemu-conf.exe config-temp/qemu-conf.c -m64 -g cc -Werror -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -o config-temp/qemu-conf.exe config-temp/qemu-conf.c -m64 -g cc -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -c -o config-temp/qemu-conf.o config-temp/qemu-conf.c cc -Werror -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -c -o config-temp/qemu-conf.o config-te
Re: [Qemu-devel] [PATCH] Fix legacy ncurses detection.
Hello,
Cornelia Huck, on Wed 09 Nov 2016 10:12:36 +0100, wrote:
> On Wed, 9 Nov 2016 10:04:02 +0100
> Samuel Thibault wrote:
> > Please post config.log so we can have a clue about what is going
> > wrong. All these error messages are meant to be reported verbatim, not
> > reinterpreted :)
>
> Well, no error here - just curses=no.
The errors are in config.log, that's what one is supposed to look at
when there are configure issues.
> config.log attached. The difference seems to be that the statement you
> added in the sample program causes a real error instead of a warning.
Yes, that was on purpose, to avoid the -Werror issue. It's expected to
happen because /usr/include/curses.h doesn't seem to have the wide
support. But -I/usr/include/ncursesw/curses.h is supposed to have. But:
> cc -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
> -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings
> -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -Wendif-labels
> -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security
> -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration
> -Wold-style-definition -Wtype-limits -fstack-protector-all
> -I/usr/include/libpng16 -I/usr/include/ncursesw -o config-temp/qemu-conf.exe
> config-temp/qemu-conf.c -m64 -g :-lncursesw:-lcursesw
> cc: error: :-lncursesw:-lcursesw: No such file or directory
That's what the real issue is in your case. I now see why, could you
try the attached patch instead?
Samuel
commit ea32127ca780b0945827776bf27f99383529621c
Author: Samuel Thibault
Date: Tue Nov 8 20:57:27 2016 +0100
Fix cursesw detection
On systems which do not provide ncursesw.pc and whose /usr/include/curses.h
does not include wide support, we should not only try with no -I, i.e.
/usr/include, but also with -I/usr/include/ncursesw.
To properly detect for wide support with and without -Werror, we need to
check for the presence of e.g. the WACS_DEGREE macro.
We also want to stop at the first curses_inc_list configuration which works,
and make sure to set IFS to : at each new loop.
Signed-off-by: Samuel Thibault
diff --git a/configure b/configure
index fd6f898..bac7bcc 100755
--- a/configure
+++ b/configure
@@ -2926,7 +2926,7 @@ if test "$curses" != "no" ; then
curses_inc_list="$($pkg_config --cflags ncurses 2>/dev/null):"
curses_lib_list="$($pkg_config --libs ncurses 2>/dev/null):-lpdcurses"
else
-curses_inc_list="$($pkg_config --cflags ncursesw 2>/dev/null):"
+curses_inc_list="$($pkg_config --cflags ncursesw
2>/dev/null):-I/usr/include/ncursesw:"
curses_lib_list="$($pkg_config --libs ncursesw
2>/dev/null):-lncursesw:-lcursesw"
fi
curses_found=no
@@ -2941,6 +2941,7 @@ int main(void) {
resize_term(0, 0);
addwstr(L"wide chars\n");
addnwstr(&wch, 1);
+ add_wch(WACS_DEGREE);
return s != 0;
}
EOF
@@ -2954,7 +2955,11 @@ EOF
libs_softmmu="$curses_lib $libs_softmmu"
break
fi
+ IFS=:
done
+if test "$curses_found" = yes ; then
+ break
+fi
done
unset IFS
if test "$curses_found" = "yes" ; then
Re: [Qemu-devel] [PATCH] Fix legacy ncurses detection.
On Wed, 9 Nov 2016 10:28:35 +0100 Samuel Thibault wrote: > > cc -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE > > -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings > > -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv > > -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs > > -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers > > -Wold-style-declaration -Wold-style-definition -Wtype-limits > > -fstack-protector-all -I/usr/include/libpng16 -I/usr/include/ncursesw -o > > config-temp/qemu-conf.exe config-temp/qemu-conf.c -m64 -g > > :-lncursesw:-lcursesw > > cc: error: :-lncursesw:-lcursesw: No such file or directory > > That's what the real issue is in your case. I now see why, could you > try the attached patch instead? Still curses=no... log attached. # QEMU configure log Wed Nov 9 10:37:26 CET 2016 # Configured with: '/home/cohuck/git/qemu/build/../configure' '--target-list=s390x-softmmu s390x-linux-user' '--enable-kvm' '--enable-vhost-net' '--enable-linux-aio' # cc -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -c -o config-temp/qemu-conf.o config-temp/qemu-conf.c cc -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -c -o config-temp/qemu-conf.o config-temp/qemu-conf.c config-temp/qemu-conf.c:2:2: error: #error __i386__ not defined #error __i386__ not defined ^ cc -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -c -o config-temp/qemu-conf.o config-temp/qemu-conf.c config-temp/qemu-conf.c:2:2: error: #error __x86_64__ not defined #error __x86_64__ not defined ^ cc -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -c -o config-temp/qemu-conf.o config-temp/qemu-conf.c config-temp/qemu-conf.c:2:2: error: #error __sparc__ not defined #error __sparc__ not defined ^ cc -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -c -o config-temp/qemu-conf.o config-temp/qemu-conf.c config-temp/qemu-conf.c:2:2: error: #error _ARCH_PPC not defined #error _ARCH_PPC not defined ^ cc -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -c -o config-temp/qemu-conf.o config-temp/qemu-conf.c config-temp/qemu-conf.c:2:2: error: #error __mips__ not defined #error __mips__ not defined ^ cc -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -c -o config-temp/qemu-conf.o config-temp/qemu-conf.c config-temp/qemu-conf.c:2:2: error: #error __ia64__ not defined #error __ia64__ not defined ^ cc -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -c -o config-temp/qemu-conf.o config-temp/qemu-conf.c cc -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -c -o config-temp/qemu-conf.o config-temp/qemu-conf.c cc -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -c -o config-temp/qemu-conf.o config-temp/qemu-conf.c cc -Werror -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -c -o config-temp/qemu-conf.o config-temp/qemu-conf.c cc -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -o config-temp/qemu-conf.exe config-temp/qemu-conf.c -m64 -g cc -Werror -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -o config-temp/qemu-conf.exe config-temp/qemu-conf.c -m64 -g cc -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -
[Qemu-devel] [PATCH V10] fsdev: add IO throttle support to fsdev devices
Uses throttling APIs to limit I/O bandwidth and number of operations on the
devices which use 9p-local driver.
Signed-off-by: Pradeep Jagadeesh
---
fsdev/Makefile.objs | 2 +-
fsdev/file-op-9p.h | 3 ++
fsdev/qemu-fsdev-opts.c | 77 -
fsdev/qemu-fsdev-throttle.c | 117
fsdev/qemu-fsdev-throttle.h | 39 +++
hw/9pfs/9p-local.c | 8 +++
hw/9pfs/9p.c| 5 ++
hw/9pfs/cofile.c| 2 +
8 files changed, 251 insertions(+), 2 deletions(-)
create mode 100644 fsdev/qemu-fsdev-throttle.c
create mode 100644 fsdev/qemu-fsdev-throttle.h
This adds the support for the 9p-local driver.
For now this functionality can be enabled only through qemu cli options.
QMP interface and support to other drivers need further extensions.
To make it simple for other drivers, the throttle code has been put in
separate files.
v1 -> v2:
-Fixed FsContext redeclaration issue
-Removed couple of function declarations from 9p-throttle.h
-Fixed some of the .help messages
v2 -> v3:
-Addressed follwing comments by Claudio Fontana
-Removed redundant memset calls in fsdev_throttle_configure_iolimits function
-Checking throttle structure validity before initializing other structures
in fsdev_throttle_configure_iolimits
-Addressed following comments by Greg Kurz
-Moved the code from 9pfs directory to fsdev directory, because the throttling
is for the fsdev devices.Renamed the files and functions to fsdev_ from 9pfs_
-Renamed throttling cli options to throttling.*, as in QMP cli options
-Removed some of the unwanted .h files from qemu-fsdev-throttle.[ch]
-Using throttle_enabled() function to set the thottle enabled flag for fsdev.
v3 -> v4:
-Addressed following comments by Alberto Garcia
-Removed the unwanted locking and other data structures in
qemu-fsdev-throttle.[ch]
-Addressed following comments by Greg Kurz
-Removed fsdev_iolimitsenable/disable functions, instead using
throttle_enabled function
v4 -> V5:
-Fixed the issue with the larger block size accounting.
(i.e, when the 9pfs mounted using msize=xxx option)
V5 -> V6:
-Addressed the comments by Alberto Garcia
-Removed the fsdev_throttle_timer_cb()
-Simplified the fsdev_throttle_schedule_next_request() as suggested
V6 -> V7:
-Addressed the comments by Alberto Garcia
-changed the fsdev_throttle_schedule_next_request() as suggested
v7 -> v8:
-Addressed comments by Alberto Garcia
-Fixed some indentation issues and split the configure_io_limit function
-Inlined throttle_timer_check code
V8 -> v9:
-Addressed the comments by Greg Kurz
-Inlined the fsdev_throttle_schedule_next_request() code into
fsdev_co_throttle_request ()
V9 -> V10:
-Addressed the comments by Alberto Garcia
-Fixed the indentation issues and minor issues
diff --git a/fsdev/Makefile.objs b/fsdev/Makefile.objs
index 1b120a4..659df6e 100644
--- a/fsdev/Makefile.objs
+++ b/fsdev/Makefile.objs
@@ -5,7 +5,7 @@ common-obj-y = qemu-fsdev.o 9p-marshal.o 9p-iov-marshal.o
else
common-obj-y = qemu-fsdev-dummy.o
endif
-common-obj-y += qemu-fsdev-opts.o
+common-obj-y += qemu-fsdev-opts.o qemu-fsdev-throttle.o
# Toplevel always builds this; targets without virtio will put it in
# common-obj-y
diff --git a/fsdev/file-op-9p.h b/fsdev/file-op-9p.h
index 6db9fea..33fe822 100644
--- a/fsdev/file-op-9p.h
+++ b/fsdev/file-op-9p.h
@@ -17,6 +17,7 @@
#include
#include
#include
+#include "qemu-fsdev-throttle.h"
#define SM_LOCAL_MODE_BITS0600
#define SM_LOCAL_DIR_MODE_BITS0700
@@ -74,6 +75,7 @@ typedef struct FsDriverEntry {
char *path;
int export_flags;
FileOperations *ops;
+FsThrottle fst;
} FsDriverEntry;
typedef struct FsContext
@@ -83,6 +85,7 @@ typedef struct FsContext
int export_flags;
struct xattr_operations **xops;
struct extended_ops exops;
+FsThrottle *fst;
/* fs driver specific data */
void *private;
} FsContext;
diff --git a/fsdev/qemu-fsdev-opts.c b/fsdev/qemu-fsdev-opts.c
index 1dd8c7a..385423f0 100644
--- a/fsdev/qemu-fsdev-opts.c
+++ b/fsdev/qemu-fsdev-opts.c
@@ -37,8 +37,83 @@ static QemuOptsList qemu_fsdev_opts = {
}, {
.name = "sock_fd",
.type = QEMU_OPT_NUMBER,
+}, {
+.name = "throttling.iops-total",
+.type = QEMU_OPT_NUMBER,
+.help = "limit total I/O operations per second",
+}, {
+.name = "throttling.iops-read",
+.type = QEMU_OPT_NUMBER,
+.help = "limit read operations per second",
+}, {
+.name = "throttling.iops-write",
+.type = QEMU_OPT_NUMBER,
+.help = "limit write operations per second",
+}, {
+.name = "throttling.bps-total",
+.type = QEMU_OPT_NUMBER,
+.help = "limit total bytes per second",
+}, {
+.name = "throttling.bps-read",
+
Re: [Qemu-devel] BdrvDirtyBitmap and bdrv_snapshot_goto
Am 08.11.2016 um 17:48 hat Vladimir Sementsov-Ogievskiy geschrieben: > 08.11.2016 15:18, Kevin Wolf wrote: > >Am 08.11.2016 um 12:08 hat Vladimir Sementsov-Ogievskiy geschrieben: > >>08.11.2016 14:05, Kevin Wolf wrote: > >>>Am 07.11.2016 um 17:10 hat Max Reitz geschrieben: > On 07.11.2016 16:24, Vladimir Sementsov-Ogievskiy wrote: > >Hi all! > > > >As I can see, in bdrv_snapshot_goto, existing dirty bitmaps are not > >handled.. Is it ok? Should not they be filled with ones or something > >like this? > Filling them with ones makes sense to me. I guess nobody noticed because > nobody was crazy enough to use block jobs alongside loadvm... > >>>What's the use case in which ones make sense? > >>> > >>>It rather seems to me that an active dirty bitmap and snapshot switching > >>>should exclude each other because the bitmap becomes meaningless by the > >>>switch. And chances are that after switching a snapshot you don't want > >>>to "incrementally" backup everything, but that you should access a > >>>different backup. > >>In other words, dirty bitmaps should be deleted on snapshot switch? > >>All? Or only named? > >As Max said, we should probably integrate bitmaps with snapshots. After > >reloading the old state, the bitmap becomes valid again, so throwing it > >away in the active state seems only right if we included it in the > >snapshot and can bring it back. > > If we choose this way, it should be firstly done for > BdrvDirtyBitmap's without any persistance. And it is not as simple > as just drop dirty bitmaps or fill them with ones. Current behavior > is definitely wrong: if user create incremental backup after > snapshot switch this incremental backup will be incorrect. I think > it should be fixed now simpler way (actually this fix means "for now > incremental backup is incompatible with snapshot switch"), and in > future, if we really need this, make them work together. > > Also, I think that filling with ones is safer and more native. It > really describes, what happens (with some overhead of dirty bits). No, it doesn't. Loading a snapshot really means accessing a different image, even if that different image is stored in the same file. So if you load a snapshot and keep using the same bitmap, you're now using a bitmap that describes a different image, and of course that's wrong. But writing ones there is just as wrong. You're treating a changed image the same way as if the same original image had been completely overwritten. But that's not what happened. We just need to take care that every bitmap is always used with the image that it really describes. And if we can't get this right yet across snapshot loads, we have to forbid using both together. I suspect we also have a similar problem with removable media. Which probably means that you can't use removable media and bitmaps together. > Simple improvement: instead of filling with ones, > new_dirty_bitmap_state = old_dirty_bitmap_state | > old_allocated_mask | new_allocated_mask, where allocated mask is > bitmap with same granularity, showing which ranges are allocated in > the image. Optimising an approach that doesn't make sense is a waste of time. Kevin
Re: [Qemu-devel] [PATCH] Fix legacy ncurses detection.
Hello,
Cornelia Huck, on Wed 09 Nov 2016 10:40:28 +0100, wrote:
> Still curses=no... log attached.
Oops, sorry, I misplaced my code, and it somehow worked in my case.
Could you give a try at the attached patch instead?
Thanks,
Samuel
commit cc8965eb848f53599895a650a6e062319189be1f
Author: Samuel Thibault
Date: Tue Nov 8 20:57:27 2016 +0100
Fix cursesw detection
On systems which do not provide ncursesw.pc and whose /usr/include/curses.h
does not include wide support, we should not only try with no -I, i.e.
/usr/include, but also with -I/usr/include/ncursesw.
To properly detect for wide support with and without -Werror, we need to
check for the presence of e.g. the WACS_DEGREE macro.
We also want to stop at the first curses_inc_list configuration which works,
and make sure to set IFS to : at each new loop.
Signed-off-by: Samuel Thibault
diff --git a/configure b/configure
index fd6f898..7d2a34e 100755
--- a/configure
+++ b/configure
@@ -2926,7 +2926,7 @@ if test "$curses" != "no" ; then
curses_inc_list="$($pkg_config --cflags ncurses 2>/dev/null):"
curses_lib_list="$($pkg_config --libs ncurses 2>/dev/null):-lpdcurses"
else
-curses_inc_list="$($pkg_config --cflags ncursesw 2>/dev/null):"
+curses_inc_list="$($pkg_config --cflags ncursesw
2>/dev/null):-I/usr/include/ncursesw:"
curses_lib_list="$($pkg_config --libs ncursesw
2>/dev/null):-lncursesw:-lcursesw"
fi
curses_found=no
@@ -2941,11 +2941,13 @@ int main(void) {
resize_term(0, 0);
addwstr(L"wide chars\n");
addnwstr(&wch, 1);
+ add_wch(WACS_DEGREE);
return s != 0;
}
EOF
IFS=:
for curses_inc in $curses_inc_list; do
+IFS=:
for curses_lib in $curses_lib_list; do
unset IFS
if compile_prog "$curses_inc" "$curses_lib" ; then
@@ -2955,6 +2957,9 @@ EOF
break
fi
done
+if test "$curses_found" = yes ; then
+ break
+fi
done
unset IFS
if test "$curses_found" = "yes" ; then
Re: [Qemu-devel] [Qemu-block] [PATCH] Added iopmem device emulation
On Tue, Nov 08, 2016 at 09:46:47AM -0700, Logan Gunthorpe wrote: > On 08/11/16 08:58 AM, Stefan Hajnoczi wrote: > > My concern with the current implementation is that a PCI MMIO access > > invokes a synchronous blk_*() call. That can pause vcpu execution while > > I/O is happening and therefore leads to unresponsive guests. QEMU's > > monitor interface is also blocked during blk_*() making it impossible to > > troubleshoot QEMU if it gets stuck due to a slow/hung I/O operation. > > > > Device models need to use blk_aio_*() so that control is returned while > > I/O is running. There are a few legacy devices left that use > > synchronous I/O but new devices should not use this approach. > > That's fair. I wasn't aware of this and I must have copied a legacy > device. We can certainly make the change in our patch. > > > Regarding the hardware design, I think the PCI BAR approach to nvdimm is > > inefficient for virtualization because each memory load/store requires a > > guest<->host transition (vmexit + vmenter). A DMA approach (i.e. > > message passing or descriptor rings) is more efficient because it > > requires fewer vmexits. > > > > On real hardware the performance characteristics are different so it > > depends what your target market is. > > The performance of the virtual device is completely unimportant. This > isn't something I'd expect anyone to use except to test drivers. On real > hardware, with real applications, DMA would almost certainly be used -- > but it would be the DMA engine in another device. eg. an IB NIC would > DMA from the PCI BAR of the iopmem device. This completely bypasses the > CPU so there would be no load/stores to be concerned about. Okay, sounds good. Is there a reason to use the block layer in QEMU? Perhaps it's better to do the same as the nvdimm device in QEMU and use a memory backend instead. The memory backend can be MAP_PRIVATE or MAP_SHARED. It can be anonymous memory or it can be backed by a real file. This gives you options can avoids using the QEMU block layer in a way it wasn't designed. Doing this would forgo QEMU block layer features like image file formats (qcow2), block jobs (storage migration), etc. But those probably aren't necessary for this device. Stefan signature.asc Description: PGP signature
Re: [Qemu-devel] [PATCH] Fix legacy ncurses detection.
On Wed, 9 Nov 2016 10:52:38 +0100
Samuel Thibault wrote:
> Hello,
>
> Cornelia Huck, on Wed 09 Nov 2016 10:40:28 +0100, wrote:
> > Still curses=no... log attached.
>
> Oops, sorry, I misplaced my code, and it somehow worked in my case.
> Could you give a try at the attached patch instead?
Works for me on SLES, Fedora, Ubuntu.
Tested-by: Cornelia Huck
Sergey, could you test whether the patch works for you as well?
(Inserted for convenience.)
commit cc8965eb848f53599895a650a6e062319189be1f
Author: Samuel Thibault
Date: Tue Nov 8 20:57:27 2016 +0100
Fix cursesw detection
On systems which do not provide ncursesw.pc and whose /usr/include/curses.h
does not include wide support, we should not only try with no -I, i.e.
/usr/include, but also with -I/usr/include/ncursesw.
To properly detect for wide support with and without -Werror, we need to
check for the presence of e.g. the WACS_DEGREE macro.
We also want to stop at the first curses_inc_list configuration which works,
and make sure to set IFS to : at each new loop.
Signed-off-by: Samuel Thibault
diff --git a/configure b/configure
index fd6f898..7d2a34e 100755
--- a/configure
+++ b/configure
@@ -2926,7 +2926,7 @@ if test "$curses" != "no" ; then
curses_inc_list="$($pkg_config --cflags ncurses 2>/dev/null):"
curses_lib_list="$($pkg_config --libs ncurses 2>/dev/null):-lpdcurses"
else
-curses_inc_list="$($pkg_config --cflags ncursesw 2>/dev/null):"
+curses_inc_list="$($pkg_config --cflags ncursesw
2>/dev/null):-I/usr/include/ncursesw:"
curses_lib_list="$($pkg_config --libs ncursesw
2>/dev/null):-lncursesw:-lcursesw"
fi
curses_found=no
@@ -2941,11 +2941,13 @@ int main(void) {
resize_term(0, 0);
addwstr(L"wide chars\n");
addnwstr(&wch, 1);
+ add_wch(WACS_DEGREE);
return s != 0;
}
EOF
IFS=:
for curses_inc in $curses_inc_list; do
+IFS=:
for curses_lib in $curses_lib_list; do
unset IFS
if compile_prog "$curses_inc" "$curses_lib" ; then
@@ -2955,6 +2957,9 @@ EOF
break
fi
done
+if test "$curses_found" = yes ; then
+ break
+fi
done
unset IFS
if test "$curses_found" = "yes" ; then
Re: [Qemu-devel] [Bug 1639394] Re: Unable to boot Solaris 8/9 x86 under Fedora 24
yes, 10/11/12 beta work without a problem(and really fast), 8/9 have been reported to work at least since 0.6.0. with the "ide" fix committed to that version. The problem seems related with "ide" emulation and real mode drivers, so I don't think an older BSD can reproduce. I will test if an older BSD is also affected by this, I can also provide you a place for you to get the versions 8/9 x86 iso, if that is ok in any way. Many thanks for the time on checking this one. On Tue, Nov 8, 2016 at 11:13 PM, John Snow <1639...@bugs.launchpad.net> wrote: > So, if I'm reading you right, Solaris10/11 work just fine, but 8/9 don't > -- and have not since qemu version 0.6.0!? From 2004? > > I don't have a copy of Solaris9 to test with, so I doubt I can work on > trying to reproduce this. Is there any possibility to reproduce a > problem on an older, freely available BSD? > > -- > You received this bug notification because you are subscribed to the bug > report. > https://bugs.launchpad.net/bugs/1639394 > > Title: > Unable to boot Solaris 8/9 x86 under Fedora 24 > > To manage notifications about this bug go to: > https://bugs.launchpad.net/qemu/+bug/1639394/+subscriptions > -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1639394 Title: Unable to boot Solaris 8/9 x86 under Fedora 24 Status in QEMU: New Bug description: qemu-system-x86_64 -version QEMU emulator version 2.6.2 (qemu-2.6.2-4.fc24), Copyright (c) 2003-2008 Fabrice Bellard Try several ways without success, I think it was a regression because problem seems to be related with ide fixed on 0.6.0: - int13 CDROM BIOS fix (aka Solaris x86 install CD fix) - int15, ah=86 BIOS fix (aka Solaris x86 hardware probe hang up fix) Solaris 10/11 works without a problem, also booting with "scsi" will circumvent initial problem, but later found problems related with "scsi" cdrom boot and also will not found the "ide" disk device. qemu-system-i386 -m 712 -drive file=/dev/Virtual_hdd/beryllium0,format=raw -cdrom /repo/Isos/sol-9_905_x86.iso SunOS Secondary Boot version 3.00 prom_panic: Could not mount filesystem. Entering boot debugger: [136419] Regards, \\CA, To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1639394/+subscriptions
Re: [Qemu-devel] [PATCH] Fix legacy ncurses detection.
On 09.11.2016 13:04, Cornelia Huck wrote:
On Wed, 9 Nov 2016 10:52:38 +0100
Samuel Thibault wrote:
Hello,
Cornelia Huck, on Wed 09 Nov 2016 10:40:28 +0100, wrote:
Still curses=no... log attached.
Oops, sorry, I misplaced my code, and it somehow worked in my case.
Could you give a try at the attached patch instead?
Works for me on SLES, Fedora, Ubuntu.
Tested-by: Cornelia Huck
Sergey, could you test whether the patch works for you as well?
(Inserted for convenience.)
commit cc8965eb848f53599895a650a6e062319189be1f
Author: Samuel Thibault
Date: Tue Nov 8 20:57:27 2016 +0100
Fix cursesw detection
On systems which do not provide ncursesw.pc and whose /usr/include/curses.h
does not include wide support, we should not only try with no -I, i.e.
/usr/include, but also with -I/usr/include/ncursesw.
To properly detect for wide support with and without -Werror, we need to
check for the presence of e.g. the WACS_DEGREE macro.
We also want to stop at the first curses_inc_list configuration which works,
and make sure to set IFS to : at each new loop.
Signed-off-by: Samuel Thibault
diff --git a/configure b/configure
index fd6f898..7d2a34e 100755
--- a/configure
+++ b/configure
@@ -2926,7 +2926,7 @@ if test "$curses" != "no" ; then
curses_inc_list="$($pkg_config --cflags ncurses 2>/dev/null):"
curses_lib_list="$($pkg_config --libs ncurses 2>/dev/null):-lpdcurses"
else
-curses_inc_list="$($pkg_config --cflags ncursesw 2>/dev/null):"
+curses_inc_list="$($pkg_config --cflags ncursesw
2>/dev/null):-I/usr/include/ncursesw:"
curses_lib_list="$($pkg_config --libs ncursesw
2>/dev/null):-lncursesw:-lcursesw"
fi
curses_found=no
@@ -2941,11 +2941,13 @@ int main(void) {
resize_term(0, 0);
addwstr(L"wide chars\n");
addnwstr(&wch, 1);
+ add_wch(WACS_DEGREE);
return s != 0;
}
EOF
IFS=:
for curses_inc in $curses_inc_list; do
+IFS=:
for curses_lib in $curses_lib_list; do
unset IFS
if compile_prog "$curses_inc" "$curses_lib" ; then
@@ -2955,6 +2957,9 @@ EOF
break
fi
done
+if test "$curses_found" = yes ; then
+ break
+fi
done
unset IFS
if test "$curses_found" = "yes" ; then
It works, thank you!
Is it planned to publish this patch into master?
--
Thanks,
Sergey Smolov
[Qemu-devel] [PATCH] cipher: fix leak on initialization error
If ctx->blocksize != XTS_BLOCK_SIZE, ctx will be leaked.
Assign ctx earler, and call qcrypto_cipher_free() on error.
Spotted thanks to ASAN.
Signed-off-by: Marc-André Lureau
---
crypto/cipher-nettle.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/crypto/cipher-nettle.c b/crypto/cipher-nettle.c
index cd094cd..593962c 100644
--- a/crypto/cipher-nettle.c
+++ b/crypto/cipher-nettle.c
@@ -376,6 +376,7 @@ QCryptoCipher *qcrypto_cipher_new(QCryptoCipherAlgorithm
alg,
goto error;
}
+cipher->opaque = ctx;
if (mode == QCRYPTO_CIPHER_MODE_XTS &&
ctx->blocksize != XTS_BLOCK_SIZE) {
error_setg(errp, "Cipher block size %zu must equal XTS block size %d",
@@ -384,13 +385,11 @@ QCryptoCipher *qcrypto_cipher_new(QCryptoCipherAlgorithm
alg,
}
ctx->iv = g_new0(uint8_t, ctx->blocksize);
-cipher->opaque = ctx;
return cipher;
error:
-g_free(cipher);
-g_free(ctx);
+qcrypto_cipher_free(cipher);
return NULL;
}
@@ -404,10 +403,12 @@ void qcrypto_cipher_free(QCryptoCipher *cipher)
}
ctx = cipher->opaque;
-g_free(ctx->iv);
-g_free(ctx->ctx);
-g_free(ctx->ctx_tweak);
-g_free(ctx);
+if (ctx) {
+g_free(ctx->iv);
+g_free(ctx->ctx);
+g_free(ctx->ctx_tweak);
+g_free(ctx);
+}
g_free(cipher);
}
--
2.10.0
Re: [Qemu-devel] [PATCH] cipher: fix leak on initialization error
On Wed, Nov 09, 2016 at 02:18:15PM +0400, Marc-André Lureau wrote:
> If ctx->blocksize != XTS_BLOCK_SIZE, ctx will be leaked.
> Assign ctx earler, and call qcrypto_cipher_free() on error.
>
> Spotted thanks to ASAN.
>
> Signed-off-by: Marc-André Lureau
> ---
> crypto/cipher-nettle.c | 15 ---
> 1 file changed, 8 insertions(+), 7 deletions(-)
>
> diff --git a/crypto/cipher-nettle.c b/crypto/cipher-nettle.c
> index cd094cd..593962c 100644
> --- a/crypto/cipher-nettle.c
> +++ b/crypto/cipher-nettle.c
> @@ -376,6 +376,7 @@ QCryptoCipher *qcrypto_cipher_new(QCryptoCipherAlgorithm
> alg,
> goto error;
> }
'ctx' is non-NULL at this point and there's a 'goto error' just
above here
>
> +cipher->opaque = ctx;
> if (mode == QCRYPTO_CIPHER_MODE_XTS &&
> ctx->blocksize != XTS_BLOCK_SIZE) {
> error_setg(errp, "Cipher block size %zu must equal XTS block size
> %d",
> @@ -384,13 +385,11 @@ QCryptoCipher
> *qcrypto_cipher_new(QCryptoCipherAlgorithm alg,
> }
>
> ctx->iv = g_new0(uint8_t, ctx->blocksize);
> -cipher->opaque = ctx;
>
> return cipher;
>
> error:
> -g_free(cipher);
> -g_free(ctx);
> +qcrypto_cipher_free(cipher);
> return NULL;
> }
...so you're leaking 'ctx' now, since it hasn't been assigned
to cipher->ctx.
You need to move 'cipher->opque = ctx' to the place where we
initially allocate 'ctx', before any gotos at which point
>
> @@ -404,10 +403,12 @@ void qcrypto_cipher_free(QCryptoCipher *cipher)
> }
>
> ctx = cipher->opaque;
> -g_free(ctx->iv);
> -g_free(ctx->ctx);
> -g_free(ctx->ctx_tweak);
> -g_free(ctx);
> +if (ctx) {
> +g_free(ctx->iv);
> +g_free(ctx->ctx);
> +g_free(ctx->ctx_tweak);
> +g_free(ctx);
> +}
> g_free(cipher);
> }
...this change is not needed
Regards,
Daniel
--
|: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://entangle-photo.org -o-http://search.cpan.org/~danberr/ :|
Re: [Qemu-devel] [PATCH V10] fsdev: add IO throttle support to fsdev devices
On Wed 09 Nov 2016 10:50:40 AM CET, Pradeep Jagadeesh wrote:
> Uses throttling APIs to limit I/O bandwidth and number of operations
> on the devices which use 9p-local driver.
>
> Signed-off-by: Pradeep Jagadeesh
It looks good now, thanks!
> +void fsdev_throttle_parse_opts(QemuOpts *opts, FsThrottle *fst, Error **err)
> +{
[...]
> +throttle_is_valid(&fst->cfg, err);
> +}
Following the QEMU conventions, I would still rename 'err' to 'errp' in
this function (since it's an Error **).
Otherwise,
Reviewed-by: Alberto Garcia
Berto
Re: [Qemu-devel] [PATCH] cipher: fix leak on initialization error
Hi
- Original Message -
> On Wed, Nov 09, 2016 at 02:18:15PM +0400, Marc-André Lureau wrote:
> > If ctx->blocksize != XTS_BLOCK_SIZE, ctx will be leaked.
> > Assign ctx earler, and call qcrypto_cipher_free() on error.
> >
> > Spotted thanks to ASAN.
> >
> > Signed-off-by: Marc-André Lureau
> > ---
> > crypto/cipher-nettle.c | 15 ---
> > 1 file changed, 8 insertions(+), 7 deletions(-)
> >
> > diff --git a/crypto/cipher-nettle.c b/crypto/cipher-nettle.c
> > index cd094cd..593962c 100644
> > --- a/crypto/cipher-nettle.c
> > +++ b/crypto/cipher-nettle.c
> > @@ -376,6 +376,7 @@ QCryptoCipher
> > *qcrypto_cipher_new(QCryptoCipherAlgorithm alg,
> > goto error;
> > }
>
> 'ctx' is non-NULL at this point and there's a 'goto error' just
> above here
>
Right, fixing it sending v2
> >
> > +cipher->opaque = ctx;
> > if (mode == QCRYPTO_CIPHER_MODE_XTS &&
> > ctx->blocksize != XTS_BLOCK_SIZE) {
> > error_setg(errp, "Cipher block size %zu must equal XTS block size
> > %d",
> > @@ -384,13 +385,11 @@ QCryptoCipher
> > *qcrypto_cipher_new(QCryptoCipherAlgorithm alg,
> > }
> >
> > ctx->iv = g_new0(uint8_t, ctx->blocksize);
> > -cipher->opaque = ctx;
> >
> > return cipher;
> >
> > error:
> > -g_free(cipher);
> > -g_free(ctx);
> > +qcrypto_cipher_free(cipher);
> > return NULL;
> > }
>
>
> ...so you're leaking 'ctx' now, since it hasn't been assigned
> to cipher->ctx.
>
> You need to move 'cipher->opque = ctx' to the place where we
> initially allocate 'ctx', before any gotos at which point
>
> >
> > @@ -404,10 +403,12 @@ void qcrypto_cipher_free(QCryptoCipher *cipher)
> > }
> >
> > ctx = cipher->opaque;
> > -g_free(ctx->iv);
> > -g_free(ctx->ctx);
> > -g_free(ctx->ctx_tweak);
> > -g_free(ctx);
> > +if (ctx) {
> > +g_free(ctx->iv);
> > +g_free(ctx->ctx);
> > +g_free(ctx->ctx_tweak);
> > +g_free(ctx);
> > +}
> > g_free(cipher);
> > }
>
> ...this change is not needed
>
> Regards,
> Daniel
> --
> |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :|
> |: http://libvirt.org -o- http://virt-manager.org :|
> |: http://entangle-photo.org -o-http://search.cpan.org/~danberr/ :|
>
Re: [Qemu-devel] [PATCH] Fix legacy ncurses detection.
Sergey Smolov, on Wed 09 Nov 2016 13:15:18 +0300, wrote: > Is it planned to publish this patch into master? Yes. Samuel
[Qemu-devel] [PATCHv2] cipher: fix leak on initialization error
On error path, ctx may be leaked. Assign ctx earlier, and call
qcrypto_cipher_free() on error.
Spotted thanks to ASAN.
Signed-off-by: Marc-André Lureau
---
crypto/cipher-nettle.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/crypto/cipher-nettle.c b/crypto/cipher-nettle.c
index cd094cd..5798910 100644
--- a/crypto/cipher-nettle.c
+++ b/crypto/cipher-nettle.c
@@ -254,6 +254,7 @@ QCryptoCipher *qcrypto_cipher_new(QCryptoCipherAlgorithm
alg,
cipher->mode = mode;
ctx = g_new0(QCryptoCipherNettle, 1);
+cipher->opaque = ctx;
switch (alg) {
case QCRYPTO_CIPHER_ALG_DES_RFB:
@@ -384,13 +385,11 @@ QCryptoCipher *qcrypto_cipher_new(QCryptoCipherAlgorithm
alg,
}
ctx->iv = g_new0(uint8_t, ctx->blocksize);
-cipher->opaque = ctx;
return cipher;
error:
-g_free(cipher);
-g_free(ctx);
+qcrypto_cipher_free(cipher);
return NULL;
}
--
2.10.0
[Qemu-devel] [PATCH] Fix cursesw detection
On systems which do not provide ncursesw.pc and whose /usr/include/curses.h
does not include wide support, we should not only try with no -I, i.e.
/usr/include, but also with -I/usr/include/ncursesw.
To properly detect for wide support with and without -Werror, we need to
check for the presence of e.g. the WACS_DEGREE macro.
We also want to stop at the first curses_inc_list configuration which works,
and make sure to set IFS to : at each new loop.
Signed-off-by: Samuel Thibault
Tested-by: Cornelia Huck
---
configure | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/configure b/configure
index fd6f898..7d2a34e 100755
--- a/configure
+++ b/configure
@@ -2926,7 +2926,7 @@ if test "$curses" != "no" ; then
curses_inc_list="$($pkg_config --cflags ncurses 2>/dev/null):"
curses_lib_list="$($pkg_config --libs ncurses 2>/dev/null):-lpdcurses"
else
-curses_inc_list="$($pkg_config --cflags ncursesw 2>/dev/null):"
+curses_inc_list="$($pkg_config --cflags ncursesw
2>/dev/null):-I/usr/include/ncursesw:"
curses_lib_list="$($pkg_config --libs ncursesw
2>/dev/null):-lncursesw:-lcursesw"
fi
curses_found=no
@@ -2941,11 +2941,13 @@ int main(void) {
resize_term(0, 0);
addwstr(L"wide chars\n");
addnwstr(&wch, 1);
+ add_wch(WACS_DEGREE);
return s != 0;
}
EOF
IFS=:
for curses_inc in $curses_inc_list; do
+IFS=:
for curses_lib in $curses_lib_list; do
unset IFS
if compile_prog "$curses_inc" "$curses_lib" ; then
@@ -2955,6 +2957,9 @@ EOF
break
fi
done
+if test "$curses_found" = yes ; then
+ break
+fi
done
unset IFS
if test "$curses_found" = "yes" ; then
--
2.10.2
Re: [Qemu-devel] [PATCHv2] cipher: fix leak on initialization error
On Wed, Nov 09, 2016 at 02:28:18PM +0400, Marc-André Lureau wrote: > On error path, ctx may be leaked. Assign ctx earlier, and call > qcrypto_cipher_free() on error. > > Spotted thanks to ASAN. > > Signed-off-by: Marc-André Lureau > --- > crypto/cipher-nettle.c | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) Thanks, queued on my crypto-next branch Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o-http://search.cpan.org/~danberr/ :|
Re: [Qemu-devel] virsh dump (qemu guest memory dump?): KASLR enabled linux guest support
On Wed, Nov 09, 2016 at 11:01:46AM +0800, Dave Young wrote: > Hi, > > Latest linux kernel enabled kaslr to randomiz phys/virt memory > addresses, we had some effort to support kexec/kdump so that crash > utility can still works in case crashed kernel has kaslr enabled. > > But according to Dave Anderson virsh dump does not work, quoted messages > from Dave below: > > """ > with virsh dump, there's no way of even knowing that KASLR > has randomized the kernel __START_KERNEL_map region, because there is no > virtual address information -- e.g., like "SYMBOL(_stext)" in the kdump > vmcoreinfo data to compare against the vmlinux file symbol value. > Unless virsh dump can export some basic virtual memory data, which > they say it can't, I don't see how KASLR can ever be supported. > """ > > I assume virsh dump is using qemu guest memory dump facility so it > should be first addressed in qemu. Thus post this query to qemu devel > list. If this is not correct please let me know. > > Could you qemu dump people make it work? Or we can not support virt dump > as long as KASLR being enabled. Latest Fedora kernel has enabled it in x86_64. > When the -kernel command line option is used, then it may be possible to extract some information that could be used to supplement the memory dump that dump-guest-memory provides. However, that would be a specific use. In general, QEMU knows nothing about the guest kernel. It doesn't know where it is in the disk image, and it doesn't even know if it's Linux. Is there anything a guest userspace application could probe from e.g. /proc that would work? If so, then the guest agent could gain a new feature providing that. Thanks, drew
[Qemu-devel] [PATCH] test-replication: fix leaks
ASAN spotted: SUMMARY: AddressSanitizer: 301990288 byte(s) leaked in 33 allocation(s). Signed-off-by: Marc-André Lureau --- tests/test-replication.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/tests/test-replication.c b/tests/test-replication.c index 0997bd8..fac2da3 100644 --- a/tests/test-replication.c +++ b/tests/test-replication.c @@ -85,6 +85,8 @@ static void test_blk_read(BlockBackend *blk, long pattern, } g_free(pattern_buf); +g_free(cmp_buf); +qemu_iovec_destroy(&qiov); } static void test_blk_write(BlockBackend *blk, long pattern, int64_t offset, @@ -116,6 +118,7 @@ static void test_blk_write(BlockBackend *blk, long pattern, int64_t offset, } g_free(pattern_buf); +qemu_iovec_destroy(&qiov); } /* -- 2.10.0
Re: [Qemu-devel] virtIO question
I want to ask a another question,why a virt_queue in virtio include in_sgs and out_sgs,for example,send_queue of virtIO net driver have in_sgs and out_sgs，when transmit data,It add buffer to out_sgs of send_queue,but how it to use in_sgs?? zhun...@gmail.com From: jitendra kumar khasdev Date: 2016-11-05 23:41 To: Peter Maydell CC: zhun...@gmail.com; qemu-devel Subject: Re: [Qemu-devel] virtIO question Have you looked at the virtio specification? No. This describes the overall structure and communication mechanism, which QEMU and Linux each only implement one half of: http://docs.oasis-open.org/virtio/virtio/v1.0/virtio-v1.0.html Thanks Peter. This doc looks me interesting. --- Jitendra
[Qemu-devel] [PATCH] test-uuid: fix leak
ASAN spotted: SUMMARY: AddressSanitizer: 74 byte(s) leaked in 2 allocation(s). Signed-off-by: Marc-André Lureau --- tests/test-uuid.c | 1 + 1 file changed, 1 insertion(+) diff --git a/tests/test-uuid.c b/tests/test-uuid.c index 77dcdc4..d3a2791 100644 --- a/tests/test-uuid.c +++ b/tests/test-uuid.c @@ -161,6 +161,7 @@ static void test_uuid_unparse_strdup(void) } out = qemu_uuid_unparse_strdup(&uuid_test_data[i].uuid); g_assert_cmpstr(uuid_test_data[i].uuidstr, ==, out); +g_free(out); } } -- 2.10.0
[Qemu-devel] [Bug 474968] Re: kvm smb server hogs cpu guest freeze
Triaging old bug tickets... Can you still reproduce this behavior with the latest version, or has the problem been fixed now? ** Changed in: qemu Status: Confirmed => Incomplete -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/474968 Title: kvm smb server hogs cpu guest freeze Status in QEMU: Incomplete Status in qemu-kvm package in Ubuntu: Confirmed Bug description: Binary package hint: qemu-kvm kvm hogs the CPU reproducibly. I installed an Ubuntu using KVM. I run the machine with -net nic,model=rtl8139,macaddr=f0:00:BA:12:34:56 -net user,hostfwd=tcp::2223-:22,smb=/tmp/share, sshed into the machine and typed "telnet 10.0.2.4 139" to try whether the SMB server works. KVM then hogs the CPU. ProblemType: Bug Architecture: amd64 Date: Thu Nov 5 01:23:09 2009 DistroRelease: Ubuntu 9.10 KvmCmdLine: Error: command ['ps', '-C', 'kvm', '-F'] failed with exit code 1: UIDPID PPID CSZ RSS PSR STIME TTY TIME CMD MachineType: LENOVO 766636G Package: kvm 1:84+dfsg-0ubuntu16+0.11.0+0ubuntu6.3 PccardctlIdent: Socket 0: no product info available PccardctlStatus: Socket 0: no card ProcCmdLine: root=/dev/mapper/cryptroot source=UUID=9c3d5596-27c6-4fd5-bfcd-fa8eef6f1230 ro quiet splash crashkernel=384M-2G:64M,2G-:128M SourcePackage: qemu-kvm Uname: Linux 2.6.32-999-generic x86_64 dmi.bios.date: 07/01/2008 dmi.bios.vendor: LENOVO dmi.bios.version: 7NETB6WW (2.16 ) dmi.board.name: 766636G dmi.board.vendor: LENOVO dmi.board.version: Not Available dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: Not Available dmi.modalias: dmi:bvnLENOVO:bvr7NETB6WW(2.16):bd07/01/2008:svnLENOVO:pn766636G:pvrThinkPadX61s:rvnLENOVO:rn766636G:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable: dmi.product.name: 766636G dmi.product.version: ThinkPad X61s dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/474968/+subscriptions
Re: [Qemu-devel] [kvm-unit-tests PATCH v4 03/11] arm/arm64: smp: support more than 8 cpus
Hi,
On 08/11/16 20:21, Andrew Jones wrote:
> By adding support for launching with gicv3 we can break the 8 vcpu
> limit. This patch adds support to smp code and also selects the
> vgic model corresponding to the host. The vgic model may also be
> manually selected by adding e.g. -machine gic-version=3 to
> extra_params.
>
> Reviewed-by: Alex Bennée
> Signed-off-by: Andrew Jones
>
> ---
> v4: improved commit message
> ---
> arm/run | 19 ---
> arm/selftest.c| 5 -
> lib/arm/asm/processor.h | 9 +++--
> lib/arm/asm/setup.h | 4 ++--
> lib/arm/setup.c | 12 +++-
> lib/arm64/asm/processor.h | 9 +++--
> 6 files changed, 43 insertions(+), 15 deletions(-)
>
> diff --git a/arm/run b/arm/run
> index a2f35ef6a7e6..2d0698619606 100755
> --- a/arm/run
> +++ b/arm/run
> @@ -31,13 +31,6 @@ if [ -z "$ACCEL" ]; then
> fi
> fi
>
> -if [ "$HOST" = "aarch64" ] && [ "$ACCEL" = "kvm" ]; then
> - processor="host"
> - if [ "$ARCH" = "arm" ]; then
> - processor+=",aarch64=off"
> - fi
> -fi
> -
> qemu="${QEMU:-qemu-system-$ARCH_NAME}"
> qpath=$(which $qemu 2>/dev/null)
>
> @@ -53,6 +46,18 @@ fi
>
> M='-machine virt'
>
> +if [ "$ACCEL" = "kvm" ]; then
> + if $qemu $M,\? 2>&1 | grep gic-version > /dev/null; then
> + M+=',gic-version=host'
> + fi
> + if [ "$HOST" = "aarch64" ]; then
> + processor="host"
> + if [ "$ARCH" = "arm" ]; then
> + processor+=",aarch64=off"
> + fi
> + fi
> +fi
> +
> if ! $qemu $M -device '?' 2>&1 | grep virtconsole > /dev/null; then
> echo "$qpath doesn't support virtio-console for chr-testdev. Exiting."
> exit 2
> diff --git a/arm/selftest.c b/arm/selftest.c
> index 196164f5313d..2f117f795d2d 100644
> --- a/arm/selftest.c
> +++ b/arm/selftest.c
> @@ -312,9 +312,10 @@ static bool psci_check(void)
> static cpumask_t smp_reported;
> static void cpu_report(void)
> {
> + unsigned long mpidr = get_mpidr();
> int cpu = smp_processor_id();
>
> - report("CPU%d online", true, cpu);
> + report("CPU(%3d) mpidr=%lx", mpidr_to_cpu(mpidr) == cpu, cpu, mpidr);
> cpumask_set_cpu(cpu, &smp_reported);
> halt();
> }
> @@ -343,6 +344,7 @@ int main(int argc, char **argv)
>
> } else if (strcmp(argv[1], "smp") == 0) {
>
> + unsigned long mpidr = get_mpidr();
> int cpu;
>
> report("PSCI version", psci_check());
> @@ -353,6 +355,7 @@ int main(int argc, char **argv)
> smp_boot_secondary(cpu, cpu_report);
> }
>
> + report("CPU(%3d) mpidr=%lx", mpidr_to_cpu(mpidr) == 0, 0,
> mpidr);
> cpumask_set_cpu(0, &smp_reported);
> while (!cpumask_full(&smp_reported))
> cpu_relax();
> diff --git a/lib/arm/asm/processor.h b/lib/arm/asm/processor.h
> index f25e7eee3666..d2048f5f5f7e 100644
> --- a/lib/arm/asm/processor.h
> +++ b/lib/arm/asm/processor.h
> @@ -40,8 +40,13 @@ static inline unsigned int get_mpidr(void)
> return mpidr;
> }
>
> -/* Only support Aff0 for now, up to 4 cpus */
> -#define mpidr_to_cpu(mpidr) ((int)((mpidr) & 0xff))
> +#define MPIDR_HWID_BITMASK 0xff
> +extern int mpidr_to_cpu(unsigned long mpidr);
> +
> +#define MPIDR_LEVEL_SHIFT(level) \
> + (((1 << level) >> 1) << 3)
> +#define MPIDR_AFFINITY_LEVEL(mpidr, level) \
> + ((mpidr >> MPIDR_LEVEL_SHIFT(level)) & 0xff)
>
> extern void start_usr(void (*func)(void *arg), void *arg, unsigned long
> sp_usr);
> extern bool is_user(void);
> diff --git a/lib/arm/asm/setup.h b/lib/arm/asm/setup.h
> index cb8fdbd38dd5..b0d51f5f0721 100644
> --- a/lib/arm/asm/setup.h
> +++ b/lib/arm/asm/setup.h
> @@ -10,8 +10,8 @@
> #include
> #include
>
> -#define NR_CPUS 8
> -extern u32 cpus[NR_CPUS];
> +#define NR_CPUS 255
> +extern u64 cpus[NR_CPUS];/* per-cpu IDs (MPIDRs) */
> extern int nr_cpus;
>
> #define NR_MEM_REGIONS 8
> diff --git a/lib/arm/setup.c b/lib/arm/setup.c
> index 7e7b39f11dde..b6e2d5815e72 100644
> --- a/lib/arm/setup.c
> +++ b/lib/arm/setup.c
> @@ -24,12 +24,22 @@ extern unsigned long stacktop;
> extern void io_init(void);
> extern void setup_args_progname(const char *args);
>
> -u32 cpus[NR_CPUS] = { [0 ... NR_CPUS-1] = (~0U) };
> +u64 cpus[NR_CPUS] = { [0 ... NR_CPUS-1] = (~0U) };
This should be ~0UL.
Also I think the type should be unsigned long to match the types used
everywhere else.
> int nr_cpus;
>
> struct mem_region mem_regions[NR_MEM_REGIONS];
> phys_addr_t __phys_offset, __phys_end;
>
> +int mpidr_to_cpu(unsigned long mpidr)
> +{
> + int i;
> +
> + for (i = 0; i < nr_cpus; ++i)
> + if (cpus[i] == (mpidr & MPIDR_HWID_BITMASK))
> + return i;
> + return -1;
> +}
> +
> static void cpu_set(int fdtnode __unused,
[Qemu-devel] [Bug 899961] Re: qemu/kvm locks up when run 32bit userspace with 64bit kernel
The bug in Debian has been marked as "Fix released", so I assume this has been fixed in upstream QEMU, too? Or is there still anything left to do here? ** Changed in: qemu Status: New => Incomplete -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/899961 Title: qemu/kvm locks up when run 32bit userspace with 64bit kernel Status in QEMU: Incomplete Status in qemu-kvm package in Debian: Fix Released Bug description: Only applies to qemu-kvm 1.0, and only when kernel is 64bit and userspace is 32bit, on x86. Did not happen with previous released versions, such as 0.15. Not all guests triggers this issue - so far, only (32bit) windows 7 guest shows it, but does that quite reliable: first boot of an old guest with new qemu-kvm, windows finds a new CPU and suggests rebooting - hit "Reboot" and in a few seconds it will be locked up (including the monitor), with no CPU usage whatsoever. Killable only with -9. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/899961/+subscriptions
Re: [Qemu-devel] [RFC PATCH v5 2/2] hw/intc/arm_gicv3_kvm: Implement get/put functions
On Fri, Oct 7, 2016 at 9:00 PM, Peter Maydell wrote:
> On 20 September 2016 at 07:55, wrote:
>> From: Vijaya Kumar K
>>
>> This actually implements pre_save and post_load methods for in-kernel
>> vGICv3.
>>
>> Signed-off-by: Pavel Fedin
>> Signed-off-by: Peter Maydell
>> Signed-off-by: Vijaya Kumamr K
>> [PMM:
>> * use decimal, not 0bnnn
>> * fixed typo in names of ICC_APR0R_EL1 and ICC_AP1R_EL1
>> * completely rearranged the get and put functions to read and write
>>the state in a natural order, rather than mixing distributor and
>>redistributor state together]
>> [Vijay:
>> * Update macro KVM_VGIC_ATTR
>> * Use 32 bit access for gicd and gicr
>> * GICD_IROUTER, GICD_TYPER, GICR_PROPBASER and GICR_PENDBASER reg
>>access are changed from 64-bit to 32-bit access
>> * s->edge_trigger stores only even bits value of an irq config.
>>Update translate_edge_trigger() accordingly.
>> * Add ICC_SRE_EL1 save and restore
>> * Initialized ICC registers during reset
>
> These sorts of [] changes should go above the sign-off
> of the person who did them, to indicate where in the
> chain they happened. Also, yours is missing the closing ].
>
>> ---
>> ---
>
>> +/* Translate from the in-kernel field for an IRQ value to/from the qemu
>> + * representation. Note that these are only expected to be used for
>> + * SPIs (that is, for interrupts whose state is in the distributor
>> + * rather than the redistributor).
>> + */
>> +typedef void (*vgic_translate_fn)(GICv3State *s, int irq,
>> + uint32_t *field, bool to_kernel);
>> +
>> +static void translate_edge_trigger(GICv3State *s, int irq,
>> +uint32_t *field, bool to_kernel)
>> +{
>> +/*
>> + * s->edge_trigger stores only even bits value of an irq config.
>> + * Consider only even bits and translate accordingly.
>> + */
>> +if (to_kernel) {
>> +*field = gicv3_gicd_edge_trigger_test(s, irq);
>> +*field = (*field << 1) & 3;
>> +} else {
>> +*field = (*field >> 1) & 1;
>> +gicv3_gicd_edge_trigger_replace(s, irq, *field);
>> +}
>> +}
>
> I would prefer that we just open-coded a for-loop for these,
> as then you can use half_shuffle32 and half_unshuffle32 to
> deal with the bits 32 at a time.
You mean to completely drop this translate_fn which is called from
kvm_dist_put/get() and have a direct function to handle edge_trigger?
>
>> +
>> +static void translate_priority(GICv3State *s, int irq,
>> + uint32_t *field, bool to_kernel)
>> +{
>> +if (to_kernel) {
>> +*field = s->gicd_ipriority[irq];
>> +} else {
>> +s->gicd_ipriority[irq] = *field;
>> +}
>> +}
>
> Similarly, this would be better with open-coded for loops.
> Then we can dump the translate_fn machinery entirely.
>
>> +
>> +static void kvm_arm_gicv3_reset_reg(GICv3State *s)
>> +{
>> +int ncpu;
>> +
>> +for (ncpu = 0; ncpu < s->num_cpu; ncpu++) {
>> +GICv3CPUState *c = &s->cpu[ncpu];
>> +
>> +/* Initialize to actual HW supported configuration */
>> +kvm_gicc_access(s, ICC_CTLR_EL1, ncpu,
>> +&c->icc_ctlr_el1[GICV3_NS], false);
>> +
>> +c->icc_ctlr_el1[GICV3_S] = c->icc_ctlr_el1[GICV3_NS];
>> +c->icc_pmr_el1 = 0;
>> +c->icc_bpr[GICV3_G0] = GIC_MIN_BPR;
>> +c->icc_bpr[GICV3_G1] = GIC_MIN_BPR;
>> +c->icc_bpr[GICV3_G1NS] = GIC_MIN_BPR;
>> +
>> +c->icc_sre_el1 = 0x7;
>> +memset(c->icc_apr, 0, sizeof(c->icc_apr));
>> +memset(c->icc_igrpen, 0, sizeof(c->icc_igrpen));
>> +}
>
> This shouldn't be in this patch. If we need to fix reset we
> should do it as a separate patch.
>
> Also this isn't the right place, really, because the CPU interface
> registers need to be reset when the CPU is reset, not when
> the GIC device is reset.
To make GIC cpuif registers to reset upon cpu reset,
I propose to add Interface for gicv3_common class and
call this interface from arm_cpu_reset() similar to
ARMLinuxBootIf. This will be more generic way rather
than searching for gicv3 object and reset the registers
>
>> }
>
>> static void kvm_arm_gicv3_class_init(ObjectClass *klass, void *data)
>> diff --git a/include/hw/intc/arm_gicv3_common.h
>> b/include/hw/intc/arm_gicv3_common.h
>> index 341a311..183c7f8 100644
>> --- a/include/hw/intc/arm_gicv3_common.h
>> +++ b/include/hw/intc/arm_gicv3_common.h
>> @@ -166,6 +166,7 @@ struct GICv3CPUState {
>> uint8_t gicr_ipriorityr[GIC_INTERNAL];
>>
>> /* CPU interface */
>> +uint64_t icc_sre_el1;
>
> Where has this come from? If we need to add a new field then it
This was part of review comment from Christoffer to add icc_sre_el1
save and restore
> needs to be in a different patch (and we need to make sure we
OK. I will spin a new patch
> add it to the VMState struct as well). But neither the emulated
> GIC nor the kernel will support writing any bits in this
> register as far as I'm a
Re: [Qemu-devel] virsh dump (qemu guest memory dump?): KASLR enabled linux guest support
On 11/09/16 11:40, Andrew Jones wrote: > On Wed, Nov 09, 2016 at 11:01:46AM +0800, Dave Young wrote: >> Hi, >> >> Latest linux kernel enabled kaslr to randomiz phys/virt memory >> addresses, we had some effort to support kexec/kdump so that crash >> utility can still works in case crashed kernel has kaslr enabled. >> >> But according to Dave Anderson virsh dump does not work, quoted messages >> from Dave below: >> >> """ >> with virsh dump, there's no way of even knowing that KASLR >> has randomized the kernel __START_KERNEL_map region, because there is no >> virtual address information -- e.g., like "SYMBOL(_stext)" in the kdump >> vmcoreinfo data to compare against the vmlinux file symbol value. >> Unless virsh dump can export some basic virtual memory data, which >> they say it can't, I don't see how KASLR can ever be supported. >> """ >> >> I assume virsh dump is using qemu guest memory dump facility so it >> should be first addressed in qemu. Thus post this query to qemu devel >> list. If this is not correct please let me know. >> >> Could you qemu dump people make it work? Or we can not support virt dump >> as long as KASLR being enabled. Latest Fedora kernel has enabled it in >> x86_64. >> > > When the -kernel command line option is used, then it may be possible > to extract some information that could be used to supplement the memory > dump that dump-guest-memory provides. However, that would be a specific > use. In general, QEMU knows nothing about the guest kernel. It doesn't > know where it is in the disk image, and it doesn't even know if it's > Linux. > > Is there anything a guest userspace application could probe from e.g. > /proc that would work? If so, then the guest agent could gain a new > feature providing that. I fully agree. This is exactly what I suggested too, independently, in the downstream thread, before arriving at this upstream thread. Let me quote that email: On 11/09/16 12:09, Laszlo Ersek wrote: > [...] the dump-guest-memory QEMU command supports an option called > "paging". Here's its documentation, from the "qapi-schema.json" source > file: > >> # @paging: if true, do paging to get guest's memory mapping. This allows >> # using gdb to process the core file. >> # >> # IMPORTANT: this option can make QEMU allocate several gigabytes >> # of RAM. This can happen for a large guest, or a >> # malicious guest pretending to be large. >> # >> # Also, paging=true has the following limitations: >> # >> # 1. The guest may be in a catastrophic state or can have >> corrupted >> #memory, which cannot be trusted >> # 2. The guest can be in real-mode even if paging is enabled. For >> #example, the guest uses ACPI to sleep, and ACPI sleep state >> #goes in real-mode >> # 3. Currently only supported on i386 and x86_64. >> # > > "virsh dump --memory-only" sets paging=false, for obvious reasons. > > [...] the dump-guest-memory command provides a raw snapshot of the > virtual machine's memory (and of the registers of the VCPUs); it is > not enlightened about the guest. > > If the additional information you are looking for can be retrieved > within the running Linux guest, using an appropriately privieleged > userspace process, then I would recommend considering an extension to > the qemu guest agent. The management layer (libvirt, [...]) could > first invoke the guest agent (a process with root privileges running > in the guest) from the host side, through virtio-serial. The new guest > agent command would return the information necessary to deal with > KASLR. Then the management layer would initiate the dump like always. > Finally, the extra information would be combined with (or placed > beside) the dump file in some way. > > So, this proposal would affect the guest agent and the management > layer (= libvirt). Given that we already dislike "paging=true", enlightening dump-guest-memory with even more guest-specific insight is the wrong approach, IMO. That kind of knowledge belongs to the guest agent. Thanks Laszlo
Re: [Qemu-devel] Crashing in tcp_close
On Tue, Nov 08, 2016 at 09:22:25PM +, Brian Candler wrote: > On 07/11/2016 10:42, Stefan Hajnoczi wrote: > > On Mon, Nov 07, 2016 at 08:42:17AM +, Brian Candler wrote: > > > >On 06/11/2016 18:04, Samuel Thibault wrote: > > > > > >Brian, could you run it with > > > > > > > > > > > >export MALLOC_CHECK_=2 > > > > > > > > > > > >and also this could be useful: > > > > > > > > > > > >export MALLOC_PERTURB_=1234 > > > > > > > > > > > >Also, to rule out the double-free scenario, and try to catch a buffer > > > > > >overflow coming from the socket structure itself, I have attached a > > > > > >patch which adds some debugging. > > > > > > > >Thanks. I've added the patch, and re-run the stress test. > > Back to the original setup, I can still get dumps. I notice I'm now getting > "malloc_printerr" in the backtrace, but unfortunately I don't get to see the > actual error message. It would seem that the malloc_check is being done and > finding an issue. I haven't been able to get one in tcp_close again though > :-( Heap corruption. Valgrind's memcheck tool could be fruitful here: http://valgrind.org/docs/manual/quick-start.html#quick-start.mcrun Stefan > Regards, > > Brian. > > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". > Core was generated by `/usr/local/bin/qemu-system-x86_64 -m 4G -machine > type=pc,accel=kvm -device virt'. > Program terminated with signal SIGABRT, Aborted. > #0 0x7eff4f3df428 in __GI_raise (sig=sig@entry=6) at > ../sysdeps/unix/sysv/linux/raise.c:54 > 54../sysdeps/unix/sysv/linux/raise.c: No such file or directory. > [Current thread is 1 (Thread 0x7eff50dffa80 (LWP 13616))] > (gdb) bt > #0 0x7eff4f3df428 in __GI_raise (sig=sig@entry=6) at > ../sysdeps/unix/sysv/linux/raise.c:54 > #1 0x7eff4f3e102a in __GI_abort () at abort.c:89 > #2 0x7eff4f42bc1f in malloc_printerr (ar_ptr=, > ptr=, str=, > action=) at malloc.c:5008 > #3 _int_malloc (av=av@entry=0x7eff4f76db20 , > bytes=bytes@entry=89) at malloc.c:3384 > #4 0x7eff4f42c409 in malloc_check (sz=88, caller=) at > hooks.c:295 > #5 0x7eff50106729 in g_malloc () from > /lib/x86_64-linux-gnu/libglib-2.0.so.0 > #6 0x563ca16930cf in qemu_aio_get > (aiocb_info=aiocb_info@entry=0x563ca1841190 , > bs=0x563ca4132f40, cb=cb@entry=0x563ca14d85e0 , > opaque=opaque@entry=0x563ca5b78910) > at /home/nsrc/qemu-2.7.0/block/io.c:2231 > #7 0x563ca1687aa8 in blk_aio_get (opaque=0x563ca5b78910, > cb=0x563ca14d85e0 , blk=0x563ca4132d70, > aiocb_info=0x563ca1841190 ) at > /home/nsrc/qemu-2.7.0/block/block-backend.c:1477 > #8 blk_aio_prwv (blk=0x563ca4132d70, offset=5278244864, bytes=4096, > qiov=0x563ca5b78968, > co_entry=co_entry@entry=0x563ca16872b0 , flags=0, > cb=0x563ca14d85e0 , > opaque=0x563ca5b78910) at > /home/nsrc/qemu-2.7.0/block/block-backend.c:941 > #9 0x563ca1687bc0 in blk_aio_pwritev (blk=, > offset=, qiov=, > flags=, cb=, opaque=) > at /home/nsrc/qemu-2.7.0/block/block-backend.c:1054 > #10 0x563ca14d8718 in dma_blk_cb (opaque=0x563ca5b78910, ret= out>) > at /home/nsrc/qemu-2.7.0/dma-helpers.c:167 > #11 0x563ca14d8bf8 in dma_blk_io (ctx=0x563ca41184a0, > sg=sg@entry=0x563ca59a08f0, > offset=offset@entry=5278244864, io_func=io_func@entry=0x563ca15a58e0 > , > io_func_opaque=io_func_opaque@entry=0x563ca5c8a350, > cb=cb@entry=0x563ca15a7250 , > opaque=0x563ca5c8a350, dir=DMA_DIRECTION_TO_DEVICE) at > /home/nsrc/qemu-2.7.0/dma-helpers.c:222 > #12 0x563ca15a764e in scsi_write_data (req=0x563ca5c8a350) at > /home/nsrc/qemu-2.7.0/hw/scsi/scsi-disk.c:540 > #13 0x563ca15ac743 in scsi_req_continue (req=req@entry=0x563ca5c8a350) > at /home/nsrc/qemu-2.7.0/hw/scsi/scsi-bus.c:1680 > #14 0x563ca14381a2 in virtio_scsi_handle_cmd_req_submit > (s=0x563ca5abc1d0, req=) > at /home/nsrc/qemu-2.7.0/hw/scsi/virtio-scsi.c:565 > #15 virtio_scsi_handle_cmd_vq (s=0x563ca5abc1d0, vq=0x7eff4963f110) > at /home/nsrc/qemu-2.7.0/hw/scsi/virtio-scsi.c:583 > #16 0x563ca144a0d6 in virtio_queue_notify_vq (vq=0x7eff4963f110) > ---Type to continue, or q to quit--- > at /home/nsrc/qemu-2.7.0/hw/virtio/virtio.c:1113 > #17 0x563ca1654965 in aio_dispatch (ctx=0x563ca41184a0) at > /home/nsrc/qemu-2.7.0/aio-posix.c:330 > #18 0x563ca164a3ae in aio_ctx_dispatch (source=, > callback=, > user_data=) at /home/nsrc/qemu-2.7.0/async.c:234 > #19 0x7eff501011a7 in g_main_context_dispatch () from > /lib/x86_64-linux-gnu/libglib-2.0.so.0 > #20 0x563ca16531db in glib_pollfds_poll () at > /home/nsrc/qemu-2.7.0/main-loop.c:213 > #21 os_host_main_loop_wait (timeout=) at > /home/nsrc/qemu-2.7.0/main-loop.c:258 > #22 main_loop_wait (nonblocking=) at > /home/nsrc/qemu-2.7.0/main-loop.c:506 > #23 0x563ca13be431 in main_loop () at /home/nsrc/qemu-2.7.0/vl.c:1908 > #24 main (argc=, argv=, envp=) > at /home/nsrc/qemu-2.7.0/vl.c:4604 > (gdb) > signature.asc Descrip
Re: [Qemu-devel] Sphinx for QEMU docs? (and a doc-comment format question)
On Tue, Nov 08, 2016 at 11:24:21AM -0500, John Snow wrote: > > > On 11/08/2016 11:20 AM, Stefan Hajnoczi wrote: > > On Mon, Nov 07, 2016 at 05:52:37PM -0500, John Snow wrote: > > > On 11/07/2016 08:30 AM, Stefan Hajnoczi wrote: > > > > On Sat, Nov 05, 2016 at 06:42:23PM +, Peter Maydell wrote: > > > > > In particular I think we could: > > > > > * set up a framework for our in-tree docs/ which gives us a > > > > >place to put new docs (both for-users and for-developers) -- > > > > >I think having someplace to put things will reduce the barrier > > > > >to people writing useful new docs > > > > > * gradually convert the existing docs to rst > > > > > * use the sphinx extension features to pull in the doc-comments > > > > >we have been fairly consistently writing over the last few years > > > > >(for instance a converted version of docs/memory.txt could pull > > > > >in doc comments from memory.h; or we can just write simple > > > > >wrapper files like a "Bitmap operations" document that > > > > >displays the doc comments from bitops.h) > > > > > > > > You are suggesting Sphinx for two different purposes: > > > > > > > > 1. Formatting docs/ in HTML, PDF, etc. > > > > > > > > 2. API documentation from doc comments. > > > > > > > > It's a good idea for #1 since we can then publish automated builds of > > > > the docs. They will be easy to view and link to in a web browser. > > > > > > > > I'm not a fan of #2. QEMU is not a C library that people develop > > > > against and our APIs are not stable. There is no incentive for pretty > > > > doc comments. It might be cool to set it up once but things will > > > > deterioate again quickly because we don't actually need external API > > > > docs. > > > > > > > > Instead of #2 we should focus on generating nice external QMP docs for > > > > libvirt and other clients. That has a clear benefit. > > > > > > > > Stefan > > > > > > > > > > I think that designating certain interfaces within QEMU as "Internal API" > > > has some merit and are worth documenting for the sake of device/format > > > authors like Peter suggests. > > > > To be clear, I'm not saying QEMU doesn't need doc comments. Every new > > function in include/*.h must have doc comments and many .c internal > > functions should too. > > > > I'm just not enthusiastic about an effort to reformat doc comments and > > make them render to HTML, PDF, etc in a nice way because I don't think > > there's much payoff from doing that or maintaining it. > > > > OK, understood -- but if we are using a tool to syntax check the comment > formats, which helps us keep consistency and our docs up to date, we get the > PDF/html outputs "for free." > > I agree they're not particularly useful, but I consider them a harmless side > effect. They might also help prove to new contributors that we're serious > about making QEMU easier to contribute to. > > > > I think at a minimum, having _A_ standard approach cannot possibly be > > > *any* > > > worse than _NO_ standard approach. > > > > People don't follow the standard format and markup syntax since that > > requires rendering and checking that the HTML, PDF, etc output looks > > correct before submitting patches. > > > > My only experience is with Doxygen, but that at least does have warnings for > a great number of things. As long as you're passing the generation checks, I > think there's not much need to actually check the html/pdf outputs except > periodically. > > > I guess one solution is to extend checkpatch.pl to enforce that all doc > > comments follow a standard format. It still cannot check that @, #, etc > > are used in the right places but at least it can make sure that some > > standard layout is followed. > > > > This is the part that I'm hoping the generation tool can fulfill, assuming > it has generation warnings like Doxygen does. If we can check that new functions have doc comments and the comments follow the right format, then I'm happy. No doc comments -> error. Comments but not in doc format -> error. The check needs to be run before submitting patches and also by patchew. Otherwise those people who don't run the doc generator can fly under the radar ;-). Stefan signature.asc Description: PGP signature
Re: [Qemu-devel] virsh dump (qemu guest memory dump?): KASLR enabled linux guest support
On Wed, Nov 09, 2016 at 12:26:17PM +0100, Laszlo Ersek wrote: > On 11/09/16 11:40, Andrew Jones wrote: > > On Wed, Nov 09, 2016 at 11:01:46AM +0800, Dave Young wrote: > >> Hi, > >> > >> Latest linux kernel enabled kaslr to randomiz phys/virt memory > >> addresses, we had some effort to support kexec/kdump so that crash > >> utility can still works in case crashed kernel has kaslr enabled. > >> > >> But according to Dave Anderson virsh dump does not work, quoted messages > >> from Dave below: > >> > >> """ > >> with virsh dump, there's no way of even knowing that KASLR > >> has randomized the kernel __START_KERNEL_map region, because there is no > >> virtual address information -- e.g., like "SYMBOL(_stext)" in the kdump > >> vmcoreinfo data to compare against the vmlinux file symbol value. > >> Unless virsh dump can export some basic virtual memory data, which > >> they say it can't, I don't see how KASLR can ever be supported. > >> """ > >> > >> I assume virsh dump is using qemu guest memory dump facility so it > >> should be first addressed in qemu. Thus post this query to qemu devel > >> list. If this is not correct please let me know. > >> > >> Could you qemu dump people make it work? Or we can not support virt dump > >> as long as KASLR being enabled. Latest Fedora kernel has enabled it in > >> x86_64. > >> > > > > When the -kernel command line option is used, then it may be possible > > to extract some information that could be used to supplement the memory > > dump that dump-guest-memory provides. However, that would be a specific > > use. In general, QEMU knows nothing about the guest kernel. It doesn't > > know where it is in the disk image, and it doesn't even know if it's > > Linux. > > > > Is there anything a guest userspace application could probe from e.g. > > /proc that would work? If so, then the guest agent could gain a new > > feature providing that. > > I fully agree. This is exactly what I suggested too, independently, in > the downstream thread, before arriving at this upstream thread. Let me > quote that email: > > On 11/09/16 12:09, Laszlo Ersek wrote: > > [...] the dump-guest-memory QEMU command supports an option called > > "paging". Here's its documentation, from the "qapi-schema.json" source > > file: > > > >> # @paging: if true, do paging to get guest's memory mapping. This allows > >> # using gdb to process the core file. > >> # > >> # IMPORTANT: this option can make QEMU allocate several gigabytes > >> # of RAM. This can happen for a large guest, or a > >> # malicious guest pretending to be large. > >> # > >> # Also, paging=true has the following limitations: > >> # > >> # 1. The guest may be in a catastrophic state or can have > >> corrupted > >> #memory, which cannot be trusted > >> # 2. The guest can be in real-mode even if paging is enabled. > >> For > >> #example, the guest uses ACPI to sleep, and ACPI sleep > >> state > >> #goes in real-mode > >> # 3. Currently only supported on i386 and x86_64. > >> # > > > > "virsh dump --memory-only" sets paging=false, for obvious reasons. > > > > [...] the dump-guest-memory command provides a raw snapshot of the > > virtual machine's memory (and of the registers of the VCPUs); it is > > not enlightened about the guest. > > > > If the additional information you are looking for can be retrieved > > within the running Linux guest, using an appropriately privieleged > > userspace process, then I would recommend considering an extension to > > the qemu guest agent. The management layer (libvirt, [...]) could > > first invoke the guest agent (a process with root privileges running > > in the guest) from the host side, through virtio-serial. The new guest > > agent command would return the information necessary to deal with > > KASLR. Then the management layer would initiate the dump like always. > > Finally, the extra information would be combined with (or placed > > beside) the dump file in some way. > > > > So, this proposal would affect the guest agent and the management > > layer (= libvirt). > > Given that we already dislike "paging=true", enlightening > dump-guest-memory with even more guest-specific insight is the wrong > approach, IMO. That kind of knowledge belongs to the guest agent. If you're trying to debug a hung/panicked guest, then using a guest agent to fetch info is a complete non-starter as it'll be dead. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o-http://search.cpan.org/~danberr/ :|
Re: [Qemu-devel] virsh dump (qemu guest memory dump?): KASLR enabled linux guest support
On Wed, Nov 09, 2016 at 11:37:35AM +, Daniel P. Berrange wrote: > On Wed, Nov 09, 2016 at 12:26:17PM +0100, Laszlo Ersek wrote: > > On 11/09/16 11:40, Andrew Jones wrote: > > > On Wed, Nov 09, 2016 at 11:01:46AM +0800, Dave Young wrote: > > >> Hi, > > >> > > >> Latest linux kernel enabled kaslr to randomiz phys/virt memory > > >> addresses, we had some effort to support kexec/kdump so that crash > > >> utility can still works in case crashed kernel has kaslr enabled. > > >> > > >> But according to Dave Anderson virsh dump does not work, quoted messages > > >> from Dave below: > > >> > > >> """ > > >> with virsh dump, there's no way of even knowing that KASLR > > >> has randomized the kernel __START_KERNEL_map region, because there is no > > >> virtual address information -- e.g., like "SYMBOL(_stext)" in the kdump > > >> vmcoreinfo data to compare against the vmlinux file symbol value. > > >> Unless virsh dump can export some basic virtual memory data, which > > >> they say it can't, I don't see how KASLR can ever be supported. > > >> """ > > >> > > >> I assume virsh dump is using qemu guest memory dump facility so it > > >> should be first addressed in qemu. Thus post this query to qemu devel > > >> list. If this is not correct please let me know. > > >> > > >> Could you qemu dump people make it work? Or we can not support virt dump > > >> as long as KASLR being enabled. Latest Fedora kernel has enabled it in > > >> x86_64. > > >> > > > > > > When the -kernel command line option is used, then it may be possible > > > to extract some information that could be used to supplement the memory > > > dump that dump-guest-memory provides. However, that would be a specific > > > use. In general, QEMU knows nothing about the guest kernel. It doesn't > > > know where it is in the disk image, and it doesn't even know if it's > > > Linux. > > > > > > Is there anything a guest userspace application could probe from e.g. > > > /proc that would work? If so, then the guest agent could gain a new > > > feature providing that. > > > > I fully agree. This is exactly what I suggested too, independently, in > > the downstream thread, before arriving at this upstream thread. Let me > > quote that email: > > > > On 11/09/16 12:09, Laszlo Ersek wrote: > > > [...] the dump-guest-memory QEMU command supports an option called > > > "paging". Here's its documentation, from the "qapi-schema.json" source > > > file: > > > > > >> # @paging: if true, do paging to get guest's memory mapping. This allows > > >> # using gdb to process the core file. > > >> # > > >> # IMPORTANT: this option can make QEMU allocate several > > >> gigabytes > > >> # of RAM. This can happen for a large guest, or a > > >> # malicious guest pretending to be large. > > >> # > > >> # Also, paging=true has the following limitations: > > >> # > > >> # 1. The guest may be in a catastrophic state or can have > > >> corrupted > > >> #memory, which cannot be trusted > > >> # 2. The guest can be in real-mode even if paging is > > >> enabled. For > > >> #example, the guest uses ACPI to sleep, and ACPI sleep > > >> state > > >> #goes in real-mode > > >> # 3. Currently only supported on i386 and x86_64. > > >> # > > > > > > "virsh dump --memory-only" sets paging=false, for obvious reasons. > > > > > > [...] the dump-guest-memory command provides a raw snapshot of the > > > virtual machine's memory (and of the registers of the VCPUs); it is > > > not enlightened about the guest. > > > > > > If the additional information you are looking for can be retrieved > > > within the running Linux guest, using an appropriately privieleged > > > userspace process, then I would recommend considering an extension to > > > the qemu guest agent. The management layer (libvirt, [...]) could > > > first invoke the guest agent (a process with root privileges running > > > in the guest) from the host side, through virtio-serial. The new guest > > > agent command would return the information necessary to deal with > > > KASLR. Then the management layer would initiate the dump like always. > > > Finally, the extra information would be combined with (or placed > > > beside) the dump file in some way. > > > > > > So, this proposal would affect the guest agent and the management > > > layer (= libvirt). > > > > Given that we already dislike "paging=true", enlightening > > dump-guest-memory with even more guest-specific insight is the wrong > > approach, IMO. That kind of knowledge belongs to the guest agent. > > If you're trying to debug a hung/panicked guest, then using a guest > agent to fetch info is a complete non-starter as it'll be dead. So don't wait. Management software can make this query immediately after the guest agent goes live. The information needed won't change. drew
Re: [Qemu-devel] [kvm-unit-tests PATCH v4 06/11] arm/arm64: add initial gicv2 support
Hi,
On 08/11/16 20:21, Andrew Jones wrote:
> Add some gicv2 support. This just adds init and enable
> functions, allowing unit tests to start messing with it.
>
> Signed-off-by: Andrew Jones
>
> ---
> v4:
> - only take defines from kernel we need now [Andre]
> - moved defines to asm/gic.h so they'll be shared with v3 [drew]
> - simplify enable by not caring if we reinit the distributor [drew]
> - init all GICD_INT_DEF_PRI_X4 registers [Eric]
> ---
> arm/Makefile.common| 1 +
> lib/arm/asm/gic-v2.h | 28 +++
> lib/arm/asm/gic.h | 44 +
> lib/arm/gic.c | 75
> ++
> lib/arm64/asm/gic-v2.h | 1 +
> lib/arm64/asm/gic.h| 1 +
> 6 files changed, 150 insertions(+)
> create mode 100644 lib/arm/asm/gic-v2.h
> create mode 100644 lib/arm/asm/gic.h
> create mode 100644 lib/arm/gic.c
> create mode 100644 lib/arm64/asm/gic-v2.h
> create mode 100644 lib/arm64/asm/gic.h
>
> diff --git a/arm/Makefile.common b/arm/Makefile.common
> index ccb554d9251a..41239c37e092 100644
> --- a/arm/Makefile.common
> +++ b/arm/Makefile.common
> @@ -42,6 +42,7 @@ cflatobjs += lib/arm/mmu.o
> cflatobjs += lib/arm/bitops.o
> cflatobjs += lib/arm/psci.o
> cflatobjs += lib/arm/smp.o
> +cflatobjs += lib/arm/gic.o
>
> libeabi = lib/arm/libeabi.a
> eabiobjs = lib/arm/eabi_compat.o
> diff --git a/lib/arm/asm/gic-v2.h b/lib/arm/asm/gic-v2.h
> new file mode 100644
> index ..f91530f88355
> --- /dev/null
> +++ b/lib/arm/asm/gic-v2.h
> @@ -0,0 +1,28 @@
> +/*
> + * All GIC* defines are lifted from include/linux/irqchip/arm-gic.h
> + *
> + * Copyright (C) 2016, Red Hat Inc, Andrew Jones
> + *
> + * This work is licensed under the terms of the GNU LGPL, version 2.
> + */
> +#ifndef _ASMARM_GIC_V2_H_
> +#define _ASMARM_GIC_V2_H_
> +
> +#ifndef _ASMARM_GIC_H_
> +#error Do not directly include . Include
> +#endif
> +
> +struct gicv2_data {
> + void *dist_base;
> + void *cpu_base;
> + unsigned int irq_nr;
> +};
> +extern struct gicv2_data gicv2_data;
> +
> +#define gicv2_dist_base()(gicv2_data.dist_base)
> +#define gicv2_cpu_base() (gicv2_data.cpu_base)
> +
> +extern int gicv2_init(void);
> +extern void gicv2_enable_defaults(void);
> +
> +#endif /* _ASMARM_GIC_V2_H_ */
> diff --git a/lib/arm/asm/gic.h b/lib/arm/asm/gic.h
> new file mode 100644
> index ..ec92f1064dc0
> --- /dev/null
> +++ b/lib/arm/asm/gic.h
> @@ -0,0 +1,44 @@
> +/*
> + * Copyright (C) 2016, Red Hat Inc, Andrew Jones
> + *
> + * This work is licensed under the terms of the GNU LGPL, version 2.
> + */
> +#ifndef _ASMARM_GIC_H_
> +#define _ASMARM_GIC_H_
> +
> +#include
> +
> +#define GIC_CPU_CTRL 0x00
> +#define GIC_CPU_PRIMASK 0x04
> +
> +#define GICC_ENABLE 0x1
> +#define GICC_INT_PRI_THRESHOLD 0xf0
> +
> +#define GIC_DIST_CTRL0x000
> +#define GIC_DIST_CTR 0x004
I think we shouldn't copy this old name here, which stems from pre-GICv2
times (PL390?), IIUC. Both GIC specs talk of TYPER here.
Also if we now use the same defines for both the GICv2 and GICv3
distributor, we should really stick with the (modern) spec naming, which
is GICD_CTRL, GICD_TYPER and so on. Same for the CPU interface (GICC_CTRL).
In the kernel these names are used for GICv3, but we didn't bother to
adjust the existing GICv2 names to avoid pointless churn.
Also that would line up with the bit field defines below.
Cheers,
Andre.
> +#define GIC_DIST_ENABLE_SET 0x100
> +#define GIC_DIST_PRI 0x400
> +
> +#define GICD_ENABLE 0x1
> +#define GICD_INT_EN_SET_SGI 0x
> +#define GICD_INT_DEF_PRI 0xa0
> +#define GICD_INT_DEF_PRI_X4 ((GICD_INT_DEF_PRI << 24) |\
> + (GICD_INT_DEF_PRI << 16) |\
> + (GICD_INT_DEF_PRI << 8) |\
> + GICD_INT_DEF_PRI)
> +
> +#define GICD_TYPER_IRQS(typer) typer) & 0x1f) + 1) * 32)
> +
> +#ifndef __ASSEMBLY__
> +
> +/*
> + * gic_init will try to find all known gics, and then
> + * initialize the gic data for the one found.
> + * returns
> + * 0 : no gic was found
> + * > 0 : the gic version of the gic found
> + */
> +extern int gic_init(void);
> +
> +#endif /* !__ASSEMBLY__ */
> +#endif /* _ASMARM_GIC_H_ */
> diff --git a/lib/arm/gic.c b/lib/arm/gic.c
> new file mode 100644
> index ..91d78c9a0cc2
> --- /dev/null
> +++ b/lib/arm/gic.c
> @@ -0,0 +1,75 @@
> +/*
> + * Copyright (C) 2016, Red Hat Inc, Andrew Jones
> + *
> + * This work is licensed under the terms of the GNU LGPL, version 2.
> + */
> +#include
> +#include
> +#include
> +
> +struct gicv2_data gicv2_data;
> +
> +/*
> + * Documentation/devicetree/bindings/interrupt-controller/arm,gic.txt
> + */
> +static bool
> +gic_get_dt_
Re: [Qemu-devel] [kvm-unit-tests PATCH v4 03/11] arm/arm64: smp: support more than 8 cpus
On Wed, Nov 09, 2016 at 11:12:03AM +, Andre Przywara wrote:
[...]
> > diff --git a/lib/arm/setup.c b/lib/arm/setup.c
> > index 7e7b39f11dde..b6e2d5815e72 100644
> > --- a/lib/arm/setup.c
> > +++ b/lib/arm/setup.c
> > @@ -24,12 +24,22 @@ extern unsigned long stacktop;
> > extern void io_init(void);
> > extern void setup_args_progname(const char *args);
> >
> > -u32 cpus[NR_CPUS] = { [0 ... NR_CPUS-1] = (~0U) };
> > +u64 cpus[NR_CPUS] = { [0 ... NR_CPUS-1] = (~0U) };
>
> This should be ~0UL.
Indeed. Thanks.
> Also I think the type should be unsigned long to match the types used
> everywhere else.
I'll change mpidr_to_cpu to return u64 instead of unsigned long.
Actually I think Alex suggested that. I'm not sure why I haven't
done it...
>
> > int nr_cpus;
> >
> > struct mem_region mem_regions[NR_MEM_REGIONS];
> > phys_addr_t __phys_offset, __phys_end;
> >
> > +int mpidr_to_cpu(unsigned long mpidr)
> > +{
> > + int i;
> > +
> > + for (i = 0; i < nr_cpus; ++i)
> > + if (cpus[i] == (mpidr & MPIDR_HWID_BITMASK))
> > + return i;
> > + return -1;
> > +}
> > +
> > static void cpu_set(int fdtnode __unused, u32 regval, void *info __unused)
>
> I guess this needs to be extended as well, including
> dt_for_each_cpu_node() to cope with 64-bit reg properties in the CPU
> node (where the upper word is not 0).
> But this is not really crucial atm, so can be fixed in a follow-up patch.
Yeah, I'll do it as a followup series, because it'll affect powerpc too.
drew
Re: [Qemu-devel] virsh dump (qemu guest memory dump?): KASLR enabled linux guest support
On Wed, Nov 09, 2016 at 12:48:09PM +0100, Andrew Jones wrote: > On Wed, Nov 09, 2016 at 11:37:35AM +, Daniel P. Berrange wrote: > > On Wed, Nov 09, 2016 at 12:26:17PM +0100, Laszlo Ersek wrote: > > > On 11/09/16 11:40, Andrew Jones wrote: > > > > On Wed, Nov 09, 2016 at 11:01:46AM +0800, Dave Young wrote: > > > >> Hi, > > > >> > > > >> Latest linux kernel enabled kaslr to randomiz phys/virt memory > > > >> addresses, we had some effort to support kexec/kdump so that crash > > > >> utility can still works in case crashed kernel has kaslr enabled. > > > >> > > > >> But according to Dave Anderson virsh dump does not work, quoted > > > >> messages > > > >> from Dave below: > > > >> > > > >> """ > > > >> with virsh dump, there's no way of even knowing that KASLR > > > >> has randomized the kernel __START_KERNEL_map region, because there is > > > >> no > > > >> virtual address information -- e.g., like "SYMBOL(_stext)" in the kdump > > > >> vmcoreinfo data to compare against the vmlinux file symbol value. > > > >> Unless virsh dump can export some basic virtual memory data, which > > > >> they say it can't, I don't see how KASLR can ever be supported. > > > >> """ > > > >> > > > >> I assume virsh dump is using qemu guest memory dump facility so it > > > >> should be first addressed in qemu. Thus post this query to qemu devel > > > >> list. If this is not correct please let me know. > > > >> > > > >> Could you qemu dump people make it work? Or we can not support virt > > > >> dump > > > >> as long as KASLR being enabled. Latest Fedora kernel has enabled it in > > > >> x86_64. > > > >> > > > > > > > > When the -kernel command line option is used, then it may be possible > > > > to extract some information that could be used to supplement the memory > > > > dump that dump-guest-memory provides. However, that would be a specific > > > > use. In general, QEMU knows nothing about the guest kernel. It doesn't > > > > know where it is in the disk image, and it doesn't even know if it's > > > > Linux. > > > > > > > > Is there anything a guest userspace application could probe from e.g. > > > > /proc that would work? If so, then the guest agent could gain a new > > > > feature providing that. > > > > > > I fully agree. This is exactly what I suggested too, independently, in > > > the downstream thread, before arriving at this upstream thread. Let me > > > quote that email: > > > > > > On 11/09/16 12:09, Laszlo Ersek wrote: > > > > [...] the dump-guest-memory QEMU command supports an option called > > > > "paging". Here's its documentation, from the "qapi-schema.json" source > > > > file: > > > > > > > >> # @paging: if true, do paging to get guest's memory mapping. This > > > >> allows > > > >> # using gdb to process the core file. > > > >> # > > > >> # IMPORTANT: this option can make QEMU allocate several > > > >> gigabytes > > > >> # of RAM. This can happen for a large guest, or a > > > >> # malicious guest pretending to be large. > > > >> # > > > >> # Also, paging=true has the following limitations: > > > >> # > > > >> # 1. The guest may be in a catastrophic state or can have > > > >> corrupted > > > >> #memory, which cannot be trusted > > > >> # 2. The guest can be in real-mode even if paging is > > > >> enabled. For > > > >> #example, the guest uses ACPI to sleep, and ACPI sleep > > > >> state > > > >> #goes in real-mode > > > >> # 3. Currently only supported on i386 and x86_64. > > > >> # > > > > > > > > "virsh dump --memory-only" sets paging=false, for obvious reasons. > > > > > > > > [...] the dump-guest-memory command provides a raw snapshot of the > > > > virtual machine's memory (and of the registers of the VCPUs); it is > > > > not enlightened about the guest. > > > > > > > > If the additional information you are looking for can be retrieved > > > > within the running Linux guest, using an appropriately privieleged > > > > userspace process, then I would recommend considering an extension to > > > > the qemu guest agent. The management layer (libvirt, [...]) could > > > > first invoke the guest agent (a process with root privileges running > > > > in the guest) from the host side, through virtio-serial. The new guest > > > > agent command would return the information necessary to deal with > > > > KASLR. Then the management layer would initiate the dump like always. > > > > Finally, the extra information would be combined with (or placed > > > > beside) the dump file in some way. > > > > > > > > So, this proposal would affect the guest agent and the management > > > > layer (= libvirt). > > > > > > Given that we already dislike "paging=true", enlightening > > > dump-guest-memory with even more guest-specific insight is the wrong > > > approach, IMO. That kind of knowledge belongs to the guest agent. > > > > If you're trying to debug a hung/pani
Re: [Qemu-devel] [kvm-unit-tests PATCH v4 03/11] arm/arm64: smp: support more than 8 cpus
Hi,
On 09/11/16 11:57, Andrew Jones wrote:
> On Wed, Nov 09, 2016 at 11:12:03AM +, Andre Przywara wrote:
> [...]
>>> diff --git a/lib/arm/setup.c b/lib/arm/setup.c
>>> index 7e7b39f11dde..b6e2d5815e72 100644
>>> --- a/lib/arm/setup.c
>>> +++ b/lib/arm/setup.c
>>> @@ -24,12 +24,22 @@ extern unsigned long stacktop;
>>> extern void io_init(void);
>>> extern void setup_args_progname(const char *args);
>>>
>>> -u32 cpus[NR_CPUS] = { [0 ... NR_CPUS-1] = (~0U) };
>>> +u64 cpus[NR_CPUS] = { [0 ... NR_CPUS-1] = (~0U) };
>>
>> This should be ~0UL.
>
> Indeed. Thanks.
>
>> Also I think the type should be unsigned long to match the types used
>> everywhere else.
>
> I'll change mpidr_to_cpu to return u64 instead of unsigned long.
I am not sure this is the right direction. unsigned long is really the
natural type for MPIDR, since this is a system register with exactly the
native register size.
I think we use it this way in the kernel.
Cheers,
Andre
> Actually I think Alex suggested that. I'm not sure why I haven't
> done it...
>
>>
>>> int nr_cpus;
>>>
>>> struct mem_region mem_regions[NR_MEM_REGIONS];
>>> phys_addr_t __phys_offset, __phys_end;
>>>
>>> +int mpidr_to_cpu(unsigned long mpidr)
>>> +{
>>> + int i;
>>> +
>>> + for (i = 0; i < nr_cpus; ++i)
>>> + if (cpus[i] == (mpidr & MPIDR_HWID_BITMASK))
>>> + return i;
>>> + return -1;
>>> +}
>>> +
>>> static void cpu_set(int fdtnode __unused, u32 regval, void *info __unused)
>>
>> I guess this needs to be extended as well, including
>> dt_for_each_cpu_node() to cope with 64-bit reg properties in the CPU
>> node (where the upper word is not 0).
>> But this is not really crucial atm, so can be fixed in a follow-up patch.
>
> Yeah, I'll do it as a followup series, because it'll affect powerpc too.
>
> drew
>
Re: [Qemu-devel] [RFC 15/17] ppc: Check that CPU model stays consistent across migration
On Wed, Nov 09, 2016 at 05:06:23PM +1100, Alexey Kardashevskiy wrote:
> On 09/11/16 15:24, David Gibson wrote:
> > On Tue, Nov 08, 2016 at 05:03:49PM +1100, Alexey Kardashevskiy wrote:
> >> On 08/11/16 16:29, David Gibson wrote:
> >>> On Fri, Nov 04, 2016 at 06:54:48PM +1100, Alexey Kardashevskiy wrote:
> On 30/10/16 22:12, David Gibson wrote:
> > When a vmstate for the ppc cpu was first introduced (a90db15
> > "target-ppc:
> > Convert ppc cpu savevm to VMStateDescription"), a VMSTATE_EQUAL was used
> > to ensure that identical CPU models were used at source and destination
> > as based on the PVR (Processor Version Register).
> >
> > However this was a problem for HV KVM, where due to hardware limitations
> > we always need to use the real PVR of the host CPU. So, to allow
> > migration between hosts with "similar enough" CPUs, the PVR check was
> > removed in 569be9f0 "target-ppc: Remove PVR check from migration". This
> > left the onus on user / management to only attempt migration between
> > compatible CPUs.
> >
> > Now that we've reworked the handling of compatiblity modes, we have the
> > information to actually determine if we're making a compatible
> > migration.
> > So this patch partially restores the PVR check. If the source was
> > running
> > in a compatibility mode, we just make sure that the destination cpu can
> > also run in that compatibility mode. However, if the source was running
> > in "raw" mode, we verify that the destination has the same PVR value.
> >
> > Signed-off-by: David Gibson
> > ---
> > target-ppc/machine.c | 15 +++
> > 1 file changed, 11 insertions(+), 4 deletions(-)
> >
> > diff --git a/target-ppc/machine.c b/target-ppc/machine.c
> > index 5d87ff6..62b9e94 100644
> > --- a/target-ppc/machine.c
> > +++ b/target-ppc/machine.c
> > @@ -173,10 +173,12 @@ static int cpu_post_load(void *opaque, int
> > version_id)
> > target_ulong msr;
> >
> > /*
> > - * We always ignore the source PVR. The user or management
> > - * software has to take care of running QEMU in a compatible mode.
> > + * If we're operating in compat mode, we should be ok as long as
> > + * the destination supports the same compatiblity mode.
> > + *
> > + * Otherwise, however, we require that the destination has exactly
> > + * the same CPU model as the source.
> > */
> > -env->spr[SPR_PVR] = env->spr_cb[SPR_PVR].default_value;
> >
> > #if defined(TARGET_PPC64)
> > if (cpu->compat_pvr) {
> > @@ -188,8 +190,13 @@ static int cpu_post_load(void *opaque, int
> > version_id)
> > error_free(local_err);
> > return -1;
> > }
> > -}
> > +} else
> > #endif
> > +{
> > +if (env->spr[SPR_PVR] != env->spr_cb[SPR_PVR].default_value) {
> > +return -1;
> > +}
> > +}
>
> This should break migration from host with PVR=004d0200 to host with
> PVR=004d0201, what is the benefit of such limitation?
> >>>
> >>> There probably isn't one. But the point is it also blocks migration
> >>> from a host with PVR=004B0201 (POWER8) to one with PVR=00201400
> >>> (403GCX) and *that* has a clear benefit. I don't see a way to block
> >>> the second without the first, except by creating a huge compatibility
> >>> matrix table, which would require inordinate amounts of time to
> >>> research carefully.
> >>
> >>
> >> This is pcc->pvr_match() for this purpose.
> >
> > Hmm.. thinking about this. Obviously requiring an exactly matching
> > PVR is the architecturally "safest" approach. For TCG and PR KVM, it
> > really should be sufficient - if you can select "close" PVRs at each
> > end, you should be able to select exactly matching ones just as well.
> >
> > For HV KVM, we should generally be using compatibility modes to allow
> > migration between a relatively wide range of CPUs. My intention was
> > basically to require moving to that model, rather than "approximate
> > matching" real PVRs.
>
> So the management stack (libvirt) will need to know that if it is HV KVM,
> then -cpu host,compat=; if it is PR KVM, then -cpu and no compat.
> That was really annoying when we had exact PVR matching.
>
>
> > I'm still convinced using compat modes is the right way to go medium
> > to long term. However, allowing the approximate matches could make
> > for a more forgiving transition, if people have existing hosts in
> > "raw" mode.
>
> Within the family, CPUs behave exactly (not slightly but exactly) the same
> even though 3 of 4 bytes of the PVR value are different so enforcing PVR to
> match or enforcing compatibility (which as a feature was not a great idea
> from the day one) does not sound compelling.
Ah, ok. pvr_
Re: [Qemu-devel] [kvm-unit-tests PATCH v4 06/11] arm/arm64: add initial gicv2 support
On Wed, Nov 09, 2016 at 11:53:39AM +, Andre Przywara wrote: [...] > > diff --git a/lib/arm/asm/gic.h b/lib/arm/asm/gic.h > > new file mode 100644 > > index ..ec92f1064dc0 > > --- /dev/null > > +++ b/lib/arm/asm/gic.h > > @@ -0,0 +1,44 @@ > > +/* > > + * Copyright (C) 2016, Red Hat Inc, Andrew Jones > > + * > > + * This work is licensed under the terms of the GNU LGPL, version 2. > > + */ > > +#ifndef _ASMARM_GIC_H_ > > +#define _ASMARM_GIC_H_ > > + > > +#include > > + > > +#define GIC_CPU_CTRL 0x00 > > +#define GIC_CPU_PRIMASK0x04 > > + > > +#define GICC_ENABLE0x1 > > +#define GICC_INT_PRI_THRESHOLD 0xf0 > > + > > +#define GIC_DIST_CTRL 0x000 > > +#define GIC_DIST_CTR 0x004 > > I think we shouldn't copy this old name here, which stems from pre-GICv2 > times (PL390?), IIUC. Both GIC specs talk of TYPER here. > > Also if we now use the same defines for both the GICv2 and GICv3 > distributor, we should really stick with the (modern) spec naming, which > is GICD_CTRL, GICD_TYPER and so on. Same for the CPU interface (GICC_CTRL). > In the kernel these names are used for GICv3, but we didn't bother to > adjust the existing GICv2 names to avoid pointless churn. > Also that would line up with the bit field defines below. > Yeah, I noticed the CTR vs. TYPER naming weirdness. I considered exclusively defining the gicv3/modern/better name, but wasn't sure I should deviate from the kernel names. Keeping the names consistent is nice for grepping kernel sources, which needs to be done when a test fails and we want to find the bug. I'd personally prefer "pointless" churn in the kernel to get it straightened out there. If it ever is, then I'd obviously update this code too. Until then, I think maintaining easy greppability is the better choice. Thanks, drew
[Qemu-devel] [PATCH 1/2] travis: trim out most clang builds
From: "Daniel P. Berrange"
We test with both gcc and clang in order to detect cases
where clang issues warnings that gcc misses. To achieve
this though we don't need to build QEMU in multiple
different configurations. Just a single clang-on-linux
build will be sufficient, if we have an "all enabled"
config.
This cuts the number of build jobs from 21 to 16,
reducing the load imposed on shared Travis CI infra.
This will make it practical to enable jobs for other
interesting & useful configurations without DOS'ing
Travis to much.
Signed-off-by: Daniel P. Berrange
Reviewed-by: Stefan Hajnoczi
Signed-off-by: Alex Bennée
---
.travis.yml | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/.travis.yml b/.travis.yml
index 9916178..0706b9a 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -4,7 +4,6 @@ python:
- "2.4"
compiler:
- gcc
- - clang
cache: ccache
addons:
apt:
@@ -68,6 +67,9 @@ script:
- make -j3 && ${TEST_CMD}
matrix:
include:
+# Test with CLang for compile portability
+- env: CONFIG=""
+ compiler: clang
# gprof/gcov are GCC features
- env: CONFIG="--enable-gprof --enable-gcov --disable-pie"
compiler: gcc
--
2.10.1
[Qemu-devel] [PATCH 2/2] travis: add Trusty with clang stable build
Although we've reduced the matrix to avoid repeating clang builds we can
still add an additional clang build to use the latest stable version of
clang which will typically be available on current distros.
Signed-off-by: Alex Bennée
---
.travis.yml | 20
1 file changed, 20 insertions(+)
diff --git a/.travis.yml b/.travis.yml
index 0706b9a..d83e2d4 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -103,6 +103,26 @@ matrix:
- sudo apt-get build-dep -qq qemu
- wget -O -
http://people.linaro.org/~alex.bennee/qemu-submodule-git-seed.tar.xz | tar -xvJ
- git submodule update --init --recursive
+# Trusty build with latest stable clang
+- env: CONFIG=""
+ sudo: required
+ addons:
+ dist: trusty
+ language: generic
+ compiler: none
+ env:
+- COMPILER_NAME=clang CXX=clang++-3.9 CC=clang-3.9
+- CONFIG="--cc=clang-3.9 --cxx=clang++-3.9"
+ before_install:
+- wget -nv -O - http://llvm.org/apt/llvm-snapshot.gpg.key | sudo
apt-key add -
+- sudo apt-add-repository -y 'deb http://llvm.org/apt/trusty
llvm-toolchain-trusty-3.9 main'
+- sudo apt-get update -qq
+- sudo apt-get install -qq -y clang-3.9
+- sudo apt-get build-dep -qq qemu
+- wget -O -
http://people.linaro.org/~alex.bennee/qemu-submodule-git-seed.tar.xz | tar -xvJ
+- git submodule update --init --recursive
+ before_script:
+- ./configure ${CONFIG} || cat config.log
# Using newer GCC with sanitizers
- addons:
apt:
--
2.10.1
Re: [Qemu-devel] [kvm-unit-tests PATCH v4 03/11] arm/arm64: smp: support more than 8 cpus
On Wed, Nov 09, 2016 at 12:01:42PM +, Andre Przywara wrote:
> Hi,
>
> On 09/11/16 11:57, Andrew Jones wrote:
> > On Wed, Nov 09, 2016 at 11:12:03AM +, Andre Przywara wrote:
> > [...]
> >>> diff --git a/lib/arm/setup.c b/lib/arm/setup.c
> >>> index 7e7b39f11dde..b6e2d5815e72 100644
> >>> --- a/lib/arm/setup.c
> >>> +++ b/lib/arm/setup.c
> >>> @@ -24,12 +24,22 @@ extern unsigned long stacktop;
> >>> extern void io_init(void);
> >>> extern void setup_args_progname(const char *args);
> >>>
> >>> -u32 cpus[NR_CPUS] = { [0 ... NR_CPUS-1] = (~0U) };
> >>> +u64 cpus[NR_CPUS] = { [0 ... NR_CPUS-1] = (~0U) };
> >>
> >> This should be ~0UL.
> >
> > Indeed. Thanks.
> >
> >> Also I think the type should be unsigned long to match the types used
> >> everywhere else.
> >
> > I'll change mpidr_to_cpu to return u64 instead of unsigned long.
>
> I am not sure this is the right direction. unsigned long is really the
> natural type for MPIDR, since this is a system register with exactly the
> native register size.
> I think we use it this way in the kernel.
OK, actually, considering arm32 and arm64 should both implement
mpidr_to_cpu, and the interface should be consistent, then unsigned
long is the only way.
Thanks,
drew
[Qemu-devel] [PATCH 0/2] Current Travis patches
Hi, Not much here but since Daniel sped up the build by trimming out most of the clang mirrors of gcc I added one additional clang build which uses the current stable branch. Hopefully this still gives us enough coverage. As this speeds up testing on merges and doesn't affect QEMU code itself I'll ask if we can merge this in the 2.8 cycle? If so I'll send a pull request in a few days assuming no objection to the patches themselves. Alex Bennée (1): travis: add Trusty with clang stable build Daniel P. Berrange (1): travis: trim out most clang builds .travis.yml | 24 +++- 1 file changed, 23 insertions(+), 1 deletion(-) -- 2.10.1
Re: [Qemu-devel] [PULL v3 00/30] Misc patches for 2016-10-31
> but then fails the assertion, which means read_sync() is returning 0 in > our particular test (which sort of makes sense: the test is purposefully > truncating the server stream at various points to see how the client > reacts). I'm trying to figure out if always treating early EOF as a > read error would be sufficient to make things work the way we want in > the client. Yeah, early EOF should become ESHUTDOWN, ECONNRESET or similar. Paolo
Re: [Qemu-devel] [PATCH V10] fsdev: add IO throttle support to fsdev devices
On 11/9/2016 11:23 AM, Alberto Garcia wrote:
On Wed 09 Nov 2016 10:50:40 AM CET, Pradeep Jagadeesh wrote:
Uses throttling APIs to limit I/O bandwidth and number of operations
on the devices which use 9p-local driver.
Signed-off-by: Pradeep Jagadeesh
It looks good now, thanks!
+void fsdev_throttle_parse_opts(QemuOpts *opts, FsThrottle *fst, Error **err)
+{
[...]
+throttle_is_valid(&fst->cfg, err);
+}
Following the QEMU conventions, I would still rename 'err' to 'errp' in
this function (since it's an Error **).
Otherwise,
Thanks, I will change it.
-Pradeep
Reviewed-by: Alberto Garcia
Berto
Re: [Qemu-devel] virsh dump (qemu guest memory dump?): KASLR enabled linux guest support
On Wed, Nov 09, 2016 at 11:58:19AM +, Daniel P. Berrange wrote: > On Wed, Nov 09, 2016 at 12:48:09PM +0100, Andrew Jones wrote: > > On Wed, Nov 09, 2016 at 11:37:35AM +, Daniel P. Berrange wrote: > > > On Wed, Nov 09, 2016 at 12:26:17PM +0100, Laszlo Ersek wrote: > > > > On 11/09/16 11:40, Andrew Jones wrote: > > > > > On Wed, Nov 09, 2016 at 11:01:46AM +0800, Dave Young wrote: > > > > >> Hi, > > > > >> > > > > >> Latest linux kernel enabled kaslr to randomiz phys/virt memory > > > > >> addresses, we had some effort to support kexec/kdump so that crash > > > > >> utility can still works in case crashed kernel has kaslr enabled. > > > > >> > > > > >> But according to Dave Anderson virsh dump does not work, quoted > > > > >> messages > > > > >> from Dave below: > > > > >> > > > > >> """ > > > > >> with virsh dump, there's no way of even knowing that KASLR > > > > >> has randomized the kernel __START_KERNEL_map region, because there > > > > >> is no > > > > >> virtual address information -- e.g., like "SYMBOL(_stext)" in the > > > > >> kdump > > > > >> vmcoreinfo data to compare against the vmlinux file symbol value. > > > > >> Unless virsh dump can export some basic virtual memory data, which > > > > >> they say it can't, I don't see how KASLR can ever be supported. > > > > >> """ > > > > >> > > > > >> I assume virsh dump is using qemu guest memory dump facility so it > > > > >> should be first addressed in qemu. Thus post this query to qemu devel > > > > >> list. If this is not correct please let me know. > > > > >> > > > > >> Could you qemu dump people make it work? Or we can not support virt > > > > >> dump > > > > >> as long as KASLR being enabled. Latest Fedora kernel has enabled it > > > > >> in x86_64. > > > > >> > > > > > > > > > > When the -kernel command line option is used, then it may be possible > > > > > to extract some information that could be used to supplement the > > > > > memory > > > > > dump that dump-guest-memory provides. However, that would be a > > > > > specific > > > > > use. In general, QEMU knows nothing about the guest kernel. It doesn't > > > > > know where it is in the disk image, and it doesn't even know if it's > > > > > Linux. > > > > > > > > > > Is there anything a guest userspace application could probe from e.g. > > > > > /proc that would work? If so, then the guest agent could gain a new > > > > > feature providing that. > > > > > > > > I fully agree. This is exactly what I suggested too, independently, in > > > > the downstream thread, before arriving at this upstream thread. Let me > > > > quote that email: > > > > > > > > On 11/09/16 12:09, Laszlo Ersek wrote: > > > > > [...] the dump-guest-memory QEMU command supports an option called > > > > > "paging". Here's its documentation, from the "qapi-schema.json" source > > > > > file: > > > > > > > > > >> # @paging: if true, do paging to get guest's memory mapping. This > > > > >> allows > > > > >> # using gdb to process the core file. > > > > >> # > > > > >> # IMPORTANT: this option can make QEMU allocate several > > > > >> gigabytes > > > > >> # of RAM. This can happen for a large guest, or a > > > > >> # malicious guest pretending to be large. > > > > >> # > > > > >> # Also, paging=true has the following limitations: > > > > >> # > > > > >> # 1. The guest may be in a catastrophic state or can > > > > >> have corrupted > > > > >> #memory, which cannot be trusted > > > > >> # 2. The guest can be in real-mode even if paging is > > > > >> enabled. For > > > > >> #example, the guest uses ACPI to sleep, and ACPI > > > > >> sleep state > > > > >> #goes in real-mode > > > > >> # 3. Currently only supported on i386 and x86_64. > > > > >> # > > > > > > > > > > "virsh dump --memory-only" sets paging=false, for obvious reasons. > > > > > > > > > > [...] the dump-guest-memory command provides a raw snapshot of the > > > > > virtual machine's memory (and of the registers of the VCPUs); it is > > > > > not enlightened about the guest. > > > > > > > > > > If the additional information you are looking for can be retrieved > > > > > within the running Linux guest, using an appropriately privieleged > > > > > userspace process, then I would recommend considering an extension to > > > > > the qemu guest agent. The management layer (libvirt, [...]) could > > > > > first invoke the guest agent (a process with root privileges running > > > > > in the guest) from the host side, through virtio-serial. The new guest > > > > > agent command would return the information necessary to deal with > > > > > KASLR. Then the management layer would initiate the dump like always. > > > > > Finally, the extra information would be combined with (or placed > > > > > beside) the dump file in some way. > > > > > > > > > > So, this proposal would affect the guest agent and the management
Re: [Qemu-devel] [PATCH] spapr: Fix migration of PCI host bridges from qemu-2.7
On Wed, Nov 09, 2016 at 04:14:25PM +1100, Alexey Kardashevskiy wrote:
> On 09/11/16 14:45, David Gibson wrote:
> > daa2369 "spapr_pci: Add a 64-bit MMIO window" subtly broke migration from
> > qemu-2.7 to the current version. It split the device's MMIO window into
> > two pieces for 32-bit and 64-bit MMIO.
> >
> > The patch included backwards compatibility code to convert the old property
> > into the new format. However, the property value was also transferred in
> > the migration stream and compared with a (probably unwise) VMSTATE_EQUAL.
> > So, the "raw" value from 2.7 is compared to the new style converted value
> > from (pre-)2.8 giving a mismatch and migration failure.
> >
> > Although it would be technically possible to fix this in a way allowing
> > backwards migration, that would leave an ugly legacy around indefinitely.
> > This patch takes the simpler approach of bumping the migration version,
> > dropping the unwise VMSTATE_EQUAL (and some equally unwise ones around it)
> > and ignoring them on an incoming migration.
> >
> > Signed-off-by: David Gibson
> > ---
> > hw/ppc/spapr_pci.c | 17 +++--
> > 1 file changed, 11 insertions(+), 6 deletions(-)
> >
> > diff --git a/hw/ppc/spapr_pci.c b/hw/ppc/spapr_pci.c
> > index 7cde30e..7f1cc29 100644
> > --- a/hw/ppc/spapr_pci.c
> > +++ b/hw/ppc/spapr_pci.c
> > @@ -1658,19 +1658,24 @@ static int spapr_pci_post_load(void *opaque, int
> > version_id)
> > return 0;
> > }
> >
> > +static bool version_before_3(void *opaque, int version_id)
> > +{
> > +return version_id < 3;
> > +}
> > +
> > static const VMStateDescription vmstate_spapr_pci = {
> > .name = "spapr_pci",
> > -.version_id = 2,
> > +.version_id = 3,
> > .minimum_version_id = 2,
> > .pre_save = spapr_pci_pre_save,
> > .post_load = spapr_pci_post_load,
> > .fields = (VMStateField[]) {
> > VMSTATE_UINT64_EQUAL(buid, sPAPRPHBState),
>
>
> You could probably go one step further and get rid of @buid as well.
I thought about it. buid at least is specified state that's
vanishingly unlikely to change or disappear from the device. It also
does serve to make sure that QOM instance matching - which is always a
bit black magicy to me - is lining things up correctly.
>
> Nevertheless, this works,
>
> Reviewed-by: Alexey Kardashevskiy
>
>
>
>
> > -VMSTATE_UINT32_EQUAL(dma_liobn[0], sPAPRPHBState),
> > -VMSTATE_UINT64_EQUAL(mem_win_addr, sPAPRPHBState),
> > -VMSTATE_UINT64_EQUAL(mem_win_size, sPAPRPHBState),
> > -VMSTATE_UINT64_EQUAL(io_win_addr, sPAPRPHBState),
> > -VMSTATE_UINT64_EQUAL(io_win_size, sPAPRPHBState),
> > +VMSTATE_UNUSED_TEST(version_before_3, sizeof(uint32_t) /*
> > dma_liobn[0] */
> > ++ sizeof(uint64_t) /* mem_win_addr */
> > ++ sizeof(uint64_t) /* mem_win_size */
> > ++ sizeof(uint64_t) /* io_win_addr */
> > ++ sizeof(uint64_t) /* io_win_size */),
> > VMSTATE_STRUCT_ARRAY(lsi_table, sPAPRPHBState, PCI_NUM_PINS, 0,
> > vmstate_spapr_pci_lsi, struct spapr_pci_lsi),
> > VMSTATE_INT32(msi_devs_num, sPAPRPHBState),
> >
>
>
--
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
[Qemu-devel] [PATCHv2 3/3] Split ISA and sysbus versions of m48t59 device
The m48t59 device supports both ISA and direct sysbus attached versions of
the device in the one .c file. This can be awkward for some embedded
machine types which need the sysbus M48T59, but don't want to pull in the
ISA bus code and its other dependencies.
Therefore, this patch splits out the code for the ISA attached M48T59 into
its own C file. It will be built when both CONFIG_M48T59 and
CONFIG_ISA_BUS are enabled.
Signed-off-by: David Gibson
---
hw/timer/Makefile.objs | 3 +
hw/timer/m48t59-internal.h | 82
hw/timer/m48t59-isa.c | 181 +++
hw/timer/m48t59.c | 228 -
4 files changed, 284 insertions(+), 210 deletions(-)
create mode 100644 hw/timer/m48t59-internal.h
create mode 100644 hw/timer/m48t59-isa.c
diff --git a/hw/timer/Makefile.objs b/hw/timer/Makefile.objs
index 7ba8c23..bf3ea3c 100644
--- a/hw/timer/Makefile.objs
+++ b/hw/timer/Makefile.objs
@@ -6,6 +6,9 @@ common-obj-$(CONFIG_DS1338) += ds1338.o
common-obj-$(CONFIG_HPET) += hpet.o
common-obj-$(CONFIG_I8254) += i8254_common.o i8254.o
common-obj-$(CONFIG_M48T59) += m48t59.o
+ifeq ($(CONFIG_ISA_BUS),y)
+common-obj-$(CONFIG_M48T59) += m48t59-isa.o
+endif
common-obj-$(CONFIG_PL031) += pl031.o
common-obj-$(CONFIG_PUV3) += puv3_ost.o
common-obj-$(CONFIG_TWL92230) += twl92230.o
diff --git a/hw/timer/m48t59-internal.h b/hw/timer/m48t59-internal.h
new file mode 100644
index 000..32ae957
--- /dev/null
+++ b/hw/timer/m48t59-internal.h
@@ -0,0 +1,82 @@
+/*
+ * QEMU M48T59 and M48T08 NVRAM emulation (common header)
+ *
+ * Copyright (c) 2003-2005, 2007 Jocelyn Mayer
+ * Copyright (c) 2013 Hervé Poussineau
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+#ifndef HW_M48T59_INTERNAL_H
+#define HW_M48T59_INTERNAL_H 1
+
+//#define DEBUG_NVRAM
+
+#if defined(DEBUG_NVRAM)
+#define NVRAM_PRINTF(fmt, ...) do { printf(fmt , ## __VA_ARGS__); } while (0)
+#else
+#define NVRAM_PRINTF(fmt, ...) do { } while (0)
+#endif
+
+/*
+ * The M48T02, M48T08 and M48T59 chips are very similar. The newer '59 has
+ * alarm and a watchdog timer and related control registers. In the
+ * PPC platform there is also a nvram lock function.
+ */
+
+typedef struct M48txxInfo {
+const char *bus_name;
+uint32_t model; /* 2 = m48t02, 8 = m48t08, 59 = m48t59 */
+uint32_t size;
+} M48txxInfo;
+
+typedef struct M48t59State {
+/* Hardware parameters */
+qemu_irq IRQ;
+MemoryRegion iomem;
+uint32_t size;
+int32_t base_year;
+/* RTC management */
+time_t time_offset;
+time_t stop_time;
+/* Alarm & watchdog */
+struct tm alarm;
+QEMUTimer *alrm_timer;
+QEMUTimer *wd_timer;
+/* NVRAM storage */
+uint8_t *buffer;
+/* Model parameters */
+uint32_t model; /* 2 = m48t02, 8 = m48t08, 59 = m48t59 */
+/* NVRAM storage */
+uint16_t addr;
+uint8_t lock;
+} M48t59State;
+
+uint32_t m48t59_read(M48t59State *NVRAM, uint32_t addr);
+void m48t59_write(M48t59State *NVRAM, uint32_t addr, uint32_t val);
+void m48t59_reset_common(M48t59State *NVRAM);
+void m48t59_realize_common(M48t59State *s, Error **errp);
+
+static inline void m48t59_toggle_lock(M48t59State *NVRAM, int lock)
+{
+NVRAM->lock ^= 1 << lock;
+}
+
+extern const MemoryRegionOps m48t59_io_ops;
+
+#endif /* HW_M48T59_INTERNAL_H */
diff --git a/hw/timer/m48t59-isa.c b/hw/timer/m48t59-isa.c
new file mode 100644
index 000..ea1ba70
--- /dev/null
+++ b/hw/timer/m48t59-isa.c
@@ -0,0 +1,181 @@
+/*
+ * QEMU M48T59 and M48T08 NVRAM emulation (ISA bus interface
+ *
+ * Copyright (c) 2003-2005, 2007 Jocelyn Mayer
+ * Copyright (c) 2013 Hervé Poussineau
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use,
[Qemu-devel] [PATCHv2 2/3] Allow ISA bus to be configured out
Currently, the code to handle the legacy ISA bus is always included in qemu. However there are lots of platforms that don't include ISA legacy devies, and quite a few that have never used ISA legacy devices at all. This patch allows the ISA bus code to be disabled in the configuration for platforms where it doesn't make sense. For now, the default configs are adjusted to include ISA on all platforms including PCI: anything with PCI can at least in principle add an i82378 PCI->ISA bridge. Also, CONFIG_IDE_CORE which is already in pci.mak requires ISA support. We also explicitly enable ISA on some other non-PCI platforms which include ISA devices: moxie, sparc and unicore32. We may want to pare this down in future. The platforms that will lose ISA by default are: cris, lm32, microblazeel, microblaze, openrisc, s390x, tricore, xtensaeb, xtensa. As far as I can tell none of these ever used ISA. Signed-off-by: David Gibson Acked-by: Michael S. Tsirkin --- default-configs/moxie-softmmu.mak | 1 + default-configs/pci.mak | 2 ++ default-configs/sparc-softmmu.mak | 1 + default-configs/unicore32-softmmu.mak | 1 + hw/isa/Makefile.objs | 2 +- 5 files changed, 6 insertions(+), 1 deletion(-) diff --git a/default-configs/moxie-softmmu.mak b/default-configs/moxie-softmmu.mak index 7e22863..e00d099 100644 --- a/default-configs/moxie-softmmu.mak +++ b/default-configs/moxie-softmmu.mak @@ -1,5 +1,6 @@ # Default configuration for moxie-softmmu +CONFIG_ISA_BUS=y CONFIG_MC146818RTC=y CONFIG_SERIAL=y CONFIG_SERIAL_ISA=y diff --git a/default-configs/pci.mak b/default-configs/pci.mak index d8d6548..60dc651 100644 --- a/default-configs/pci.mak +++ b/default-configs/pci.mak @@ -1,4 +1,6 @@ CONFIG_PCI=y +# For now, CONFIG_IDE_CORE requires ISA, so we enable it here +CONFIG_ISA_BUS=y CONFIG_VIRTIO_PCI=y CONFIG_VIRTIO=y CONFIG_USB_UHCI=y diff --git a/default-configs/sparc-softmmu.mak b/default-configs/sparc-softmmu.mak index ab796b3..004b0f4 100644 --- a/default-configs/sparc-softmmu.mak +++ b/default-configs/sparc-softmmu.mak @@ -1,5 +1,6 @@ # Default configuration for sparc-softmmu +CONFIG_ISA_BUS=y CONFIG_ECC=y CONFIG_ESP=y CONFIG_ESCC=y diff --git a/default-configs/unicore32-softmmu.mak b/default-configs/unicore32-softmmu.mak index de38577..5f6c4a8 100644 --- a/default-configs/unicore32-softmmu.mak +++ b/default-configs/unicore32-softmmu.mak @@ -1,4 +1,5 @@ # Default configuration for unicore32-softmmu +CONFIG_ISA_BUS=y CONFIG_PUV3=y CONFIG_PTIMER=y CONFIG_PCKBD=y diff --git a/hw/isa/Makefile.objs b/hw/isa/Makefile.objs index 9164556..fb37c55 100644 --- a/hw/isa/Makefile.objs +++ b/hw/isa/Makefile.objs @@ -1,4 +1,4 @@ -common-obj-y += isa-bus.o +common-obj-$(CONFIG_ISA_BUS) += isa-bus.o common-obj-$(CONFIG_APM) += apm.o common-obj-$(CONFIG_I82378) += i82378.o common-obj-$(CONFIG_PC87312) += pc87312.o -- 2.7.4
[Qemu-devel] [PATCHv2 1/3] Split serial-isa into its own config option
At present, the core device model code for 8250-like serial ports (serial.c) and the code for serial ports attached to ISA-style legacy IO (serial-isa.c) are both controlled by the CONFIG_SERIAL variable. There are lots and lots of embedded platforms that have 8250-like serial ports but have never had anything resembling ISA legacy IO. Therefore, split serial-isa into its own CONFIG_SERIAL_ISA option so it can be disabled for platforms where it's not appropriate. For now, I enabled CONFIG_SERIAL_ISA in every default-config where CONFIG_SERIAL is enabled, excepting microblaze, or32, and xtensa. As best as I can tell, those platforms never used legacy ISA, and also don't include PCI support (which would allow connection of a PCI->ISA bridge and/or a southbridge including legacy ISA serial ports). Signed-off-by: David Gibson Reviewed-by: Thomas Huth --- default-configs/alpha-softmmu.mak | 1 + default-configs/arm-softmmu.mak | 1 + default-configs/i386-softmmu.mak| 1 + default-configs/mips-softmmu-common.mak | 1 + default-configs/moxie-softmmu.mak | 1 + default-configs/pci.mak | 1 + default-configs/ppc-softmmu.mak | 1 + default-configs/ppc64-softmmu.mak | 1 + default-configs/ppcemb-softmmu.mak | 1 + default-configs/sh4-softmmu.mak | 1 + default-configs/sh4eb-softmmu.mak | 1 + default-configs/sparc64-softmmu.mak | 1 + default-configs/x86_64-softmmu.mak | 1 + hw/char/Makefile.objs | 3 ++- 14 files changed, 15 insertions(+), 1 deletion(-) diff --git a/default-configs/alpha-softmmu.mak b/default-configs/alpha-softmmu.mak index 7f6161e..e0d75e3 100644 --- a/default-configs/alpha-softmmu.mak +++ b/default-configs/alpha-softmmu.mak @@ -3,6 +3,7 @@ include pci.mak include usb.mak CONFIG_SERIAL=y +CONFIG_SERIAL_ISA=y CONFIG_I8254=y CONFIG_PCKBD=y CONFIG_VGA_CIRRUS=y diff --git a/default-configs/arm-softmmu.mak b/default-configs/arm-softmmu.mak index 6de3e16..dcbcea7 100644 --- a/default-configs/arm-softmmu.mak +++ b/default-configs/arm-softmmu.mak @@ -6,6 +6,7 @@ CONFIG_VGA=y CONFIG_NAND=y CONFIG_ECC=y CONFIG_SERIAL=y +CONFIG_SERIAL_ISA=y CONFIG_PTIMER=y CONFIG_SD=y CONFIG_MAX7310=y diff --git a/default-configs/i386-softmmu.mak b/default-configs/i386-softmmu.mak index 0b51360..3f2e820 100644 --- a/default-configs/i386-softmmu.mak +++ b/default-configs/i386-softmmu.mak @@ -15,6 +15,7 @@ CONFIG_IPMI_EXTERN=y CONFIG_ISA_IPMI_KCS=y CONFIG_ISA_IPMI_BT=y CONFIG_SERIAL=y +CONFIG_SERIAL_ISA=y CONFIG_PARALLEL=y CONFIG_I8254=y CONFIG_PCSPK=y diff --git a/default-configs/mips-softmmu-common.mak b/default-configs/mips-softmmu-common.mak index 0394514..5b8b0c9 100644 --- a/default-configs/mips-softmmu-common.mak +++ b/default-configs/mips-softmmu-common.mak @@ -9,6 +9,7 @@ CONFIG_VGA_ISA_MM=y CONFIG_VGA_CIRRUS=y CONFIG_VMWARE_VGA=y CONFIG_SERIAL=y +CONFIG_SERIAL_ISA=y CONFIG_PARALLEL=y CONFIG_I8254=y CONFIG_PCSPK=y diff --git a/default-configs/moxie-softmmu.mak b/default-configs/moxie-softmmu.mak index 1a95476..7e22863 100644 --- a/default-configs/moxie-softmmu.mak +++ b/default-configs/moxie-softmmu.mak @@ -2,4 +2,5 @@ CONFIG_MC146818RTC=y CONFIG_SERIAL=y +CONFIG_SERIAL_ISA=y CONFIG_VGA=y diff --git a/default-configs/pci.mak b/default-configs/pci.mak index fff7ce3..d8d6548 100644 --- a/default-configs/pci.mak +++ b/default-configs/pci.mak @@ -27,6 +27,7 @@ CONFIG_AHCI=y CONFIG_ESP=y CONFIG_ESP_PCI=y CONFIG_SERIAL=y +CONFIG_SERIAL_ISA=y CONFIG_SERIAL_PCI=y CONFIG_IPACK=y CONFIG_WDT_IB6300ESB=y diff --git a/default-configs/ppc-softmmu.mak b/default-configs/ppc-softmmu.mak index d4d0f9b..13eb94f 100644 --- a/default-configs/ppc-softmmu.mak +++ b/default-configs/ppc-softmmu.mak @@ -45,5 +45,6 @@ CONFIG_PLATFORM_BUS=y CONFIG_ETSEC=y CONFIG_LIBDECNUMBER=y # For PReP +CONFIG_SERIAL_ISA=y CONFIG_MC146818RTC=y CONFIG_ISA_TESTDEV=y diff --git a/default-configs/ppc64-softmmu.mak b/default-configs/ppc64-softmmu.mak index 67a9bca..f607125 100644 --- a/default-configs/ppc64-softmmu.mak +++ b/default-configs/ppc64-softmmu.mak @@ -52,6 +52,7 @@ CONFIG_XICS=$(CONFIG_PSERIES) CONFIG_XICS_SPAPR=$(CONFIG_PSERIES) CONFIG_XICS_KVM=$(and $(CONFIG_PSERIES),$(CONFIG_KVM)) # For PReP +CONFIG_SERIAL_ISA=y CONFIG_MC146818RTC=y CONFIG_ISA_TESTDEV=y CONFIG_MEM_HOTPLUG=y diff --git a/default-configs/ppcemb-softmmu.mak b/default-configs/ppcemb-softmmu.mak index 54acc4d..7f56004 100644 --- a/default-configs/ppcemb-softmmu.mak +++ b/default-configs/ppcemb-softmmu.mak @@ -5,6 +5,7 @@ include sound.mak include usb.mak CONFIG_M48T59=y CONFIG_SERIAL=y +CONFIG_SERIAL_ISA=y CONFIG_I8257=y CONFIG_OPENPIC=y CONFIG_PFLASH_CFI01=y diff --git a/default-configs/sh4-softmmu.mak b/default-configs/sh4-softmmu.mak index 8e00390..546d855 100644 --- a/default-configs/sh4-softmmu.mak +++ b/default-configs/sh4-softmmu.mak @@ -3,6 +3,7 @@ include pci.mak include usb.mak CONFIG_SERIAL=y +CONFIG_SERIAL_I
[Qemu-devel] [PATCHv2 0/3] Allow ISA to be disabled on some platforms
This is a rebase and revision of a series I wrote quite some time ago. This makes some cleanups that are a start on allowing ISA to be compiled out for platforms which don't use it. Unfortunately, a lot of the pieces here don't have a clear maintainer. So, I'm hoping to get some Acked-bys from the maintainers of the affected targets, then I intend to send a pull request direct to Peter. Notes: * Patch 3/3 triggers a style warning, but that's just because I'm moving a C++ // comment verbatim from one file to another Changes since v1: * Fixed some silly compile errors in 3/3 exposed by some changes in other headers David Gibson (3): Split serial-isa into its own config option Allow ISA bus to be configured out Split ISA and sysbus versions of m48t59 device default-configs/alpha-softmmu.mak | 1 + default-configs/arm-softmmu.mak | 1 + default-configs/i386-softmmu.mak| 1 + default-configs/mips-softmmu-common.mak | 1 + default-configs/moxie-softmmu.mak | 2 + default-configs/pci.mak | 3 + default-configs/ppc-softmmu.mak | 1 + default-configs/ppc64-softmmu.mak | 1 + default-configs/ppcemb-softmmu.mak | 1 + default-configs/sh4-softmmu.mak | 1 + default-configs/sh4eb-softmmu.mak | 1 + default-configs/sparc-softmmu.mak | 1 + default-configs/sparc64-softmmu.mak | 1 + default-configs/unicore32-softmmu.mak | 1 + default-configs/x86_64-softmmu.mak | 1 + hw/char/Makefile.objs | 3 +- hw/isa/Makefile.objs| 2 +- hw/timer/Makefile.objs | 3 + hw/timer/m48t59-internal.h | 82 hw/timer/m48t59-isa.c | 181 + hw/timer/m48t59.c | 228 +++- 21 files changed, 305 insertions(+), 212 deletions(-) create mode 100644 hw/timer/m48t59-internal.h create mode 100644 hw/timer/m48t59-isa.c -- 2.7.4
Re: [Qemu-devel] [PATCH 2/3] target-i386: Add Intel HAX files
On Tue, Nov 08, 2016 at 04:39:28PM +0100, Vincent Palatin wrote:
Please run scripts/checkpatch.pl to verify that the code follows the
QEMU coding style.
> +hax_fd hax_host_open_vcpu(int vmid, int vcpuid)
> +{
> +char *devfs_path = NULL;
> +hax_fd fd;
> +
> +devfs_path = hax_vcpu_devfs_string(vmid, vcpuid);
> +if (!devfs_path) {
> +fprintf(stderr, "Failed to get the devfs\n");
> +return -EINVAL;
> +}
> +
> +fd = open(devfs_path, O_RDWR);
> +qemu_vfree(devfs_path);
g_malloc(), g_new(), g_strdup(), etc must be matched with g_free(), not
qemu_vfree(). There are probably other instances of this issue in the
patches.
> +//#define DEBUG_HAX_SLOT
> +
> +#ifdef DEBUG_HAX_SLOT
> +#define DPRINTF(fmt, ...) \
> +do { fprintf(stdout, fmt, ## __VA_ARGS__); } while (0)
> +#else
> +#define DPRINTF(fmt, ...) \
> +do { } while (0)
> +#endif
Please consider using tracing instead of debug printfs. See docs/tracing.txt.
If you really want to keep macros, please use:
#define DEBUG_HAX_SLOT 0
#define DPRINTF(fmt, ...) \
do { \
if (DEBUG_HAX_SLOT) { \
fprintf(stdout, fmt, ## __VA_ARGS__); \
} \
} while (0)
This approach prevents bitrot because it allows the compiler to syntax
check the format string and arguments even when the printf is compiled
out.
signature.asc
Description: PGP signature
Re: [Qemu-devel] [PATCH v2] docs: add document to explain the usage of vNVDIMM
On Wed, Nov 09, 2016 at 09:04:48AM +0800, Haozhong Zhang wrote: > Signed-off-by: Haozhong Zhang > Reviewed-by: Xiao Guangrong > Reviewed-by: Stefan Hajnoczi > --- > Changes since v1: > * explicitly state the block window mode is not supported (Stefan Hajnoczi) > * typo fix: label_size ==> label-size (David Alan Gilbert) > --- > docs/nvdimm.txt | 124 > > 1 file changed, 124 insertions(+) > create mode 100644 docs/nvdimm.txt Great. This patch can go through Michael Tsirkin's tree alongside the other current nvdimm patches. signature.asc Description: PGP signature
Re: [Qemu-devel] [kvm-unit-tests PATCH v4 09/11] arm/arm64: add initial gicv3 support
Hi,
On 08/11/16 20:21, Andrew Jones wrote:
> Signed-off-by: Andrew Jones
>
> ---
> v4:
> - only take defines from kernel we need now [Andre]
> - simplify enable by not caring if we reinit the distributor [drew]
> v2:
> - configure irqs as NS GRP1
> ---
> lib/arm/asm/arch_gicv3.h | 42 +
> lib/arm/asm/gic-v3.h | 92
> ++
> lib/arm/asm/gic.h | 1 +
> lib/arm/gic.c | 56
> lib/arm64/asm/arch_gicv3.h | 44 ++
> lib/arm64/asm/gic-v3.h | 1 +
> lib/arm64/asm/sysreg.h | 44 ++
> 7 files changed, 280 insertions(+)
> create mode 100644 lib/arm/asm/arch_gicv3.h
> create mode 100644 lib/arm/asm/gic-v3.h
> create mode 100644 lib/arm64/asm/arch_gicv3.h
> create mode 100644 lib/arm64/asm/gic-v3.h
> create mode 100644 lib/arm64/asm/sysreg.h
>
> diff --git a/lib/arm/asm/arch_gicv3.h b/lib/arm/asm/arch_gicv3.h
> new file mode 100644
> index ..81a1e5f6c29c
> --- /dev/null
> +++ b/lib/arm/asm/arch_gicv3.h
> @@ -0,0 +1,42 @@
> +/*
> + * All ripped off from arch/arm/include/asm/arch_gicv3.h
> + *
> + * Copyright (C) 2016, Red Hat Inc, Andrew Jones
> + *
> + * This work is licensed under the terms of the GNU LGPL, version 2.
> + */
> +#ifndef _ASMARM_ARCH_GICV3_H_
> +#define _ASMARM_ARCH_GICV3_H_
> +
> +#ifndef __ASSEMBLY__
> +#include
> +#include
> +#include
> +
> +#define __stringify xstr
> +
> +#define __ACCESS_CP15(CRn, Op1, CRm, Op2)p15, Op1, %0, CRn, CRm, Op2
> +
> +#define ICC_PMR __ACCESS_CP15(c4, 0, c6, 0)
> +#define ICC_IGRPEN1 __ACCESS_CP15(c12, 0, c12, 7)
> +
> +static inline void gicv3_write_pmr(u32 val)
> +{
> + asm volatile("mcr " __stringify(ICC_PMR) : : "r" (val));
> +}
> +
> +static inline void gicv3_write_grpen1(u32 val)
> +{
> + asm volatile("mcr " __stringify(ICC_IGRPEN1) : : "r" (val));
> + isb();
> +}
> +
> +static inline u64 gicv3_read_typer(const volatile void __iomem *addr)
> +{
> + u64 val = readl(addr);
> + val |= (u64)readl(addr + 4) << 32;
> + return val;
> +}
> +
> +#endif /* !__ASSEMBLY__ */
> +#endif /* _ASMARM_ARCH_GICV3_H_ */
> diff --git a/lib/arm/asm/gic-v3.h b/lib/arm/asm/gic-v3.h
> new file mode 100644
> index ..03321f8c860f
> --- /dev/null
> +++ b/lib/arm/asm/gic-v3.h
> @@ -0,0 +1,92 @@
> +/*
> + * All GIC* defines are lifted from include/linux/irqchip/arm-gic-v3.h
> + *
> + * Copyright (C) 2016, Red Hat Inc, Andrew Jones
> + *
> + * This work is licensed under the terms of the GNU LGPL, version 2.
> + */
> +#ifndef _ASMARM_GIC_V3_H_
> +#define _ASMARM_GIC_V3_H_
> +
> +#ifndef _ASMARM_GIC_H_
> +#error Do not directly include . Include
> +#endif
> +
> +#define GICD_CTLR0x
> +#define GICD_TYPER 0x0004
So if we share the distributor register definition with GICv2, these
shouldn't be here, but in gic.h.
But this is the right naming scheme we should use (instead of GIC_DIST_xxx).
Now this gets interesting with your wish to both share the definitions
for the GICv2 and GICv3 distributors, but also stick to the names the
kernel uses (because they differ between the two) ;-)
So now you loose the greppability for either GIC_DIST_CTR or GICD_TYPER,
for instance.
> +#define GICD_IGROUPR 0x0080
> +
> +#define GICD_CTLR_RWP(1U << 31)
> +#define GICD_CTLR_ARE_NS (1U << 4)
> +#define GICD_CTLR_ENABLE_G1A (1U << 1)
> +#define GICD_CTLR_ENABLE_G1 (1U << 0)
> +
> +#define GICR_TYPER 0x0008
> +#define GICR_IGROUPR0GICD_IGROUPR
> +#define GICR_TYPER_LAST (1U << 4)
> +
> +
> +#include
> +
> +#ifndef __ASSEMBLY__
> +#include
> +#include
> +#include
> +#include
> +
> +struct gicv3_data {
> + void *dist_base;
> + void *redist_base[NR_CPUS];
> + unsigned int irq_nr;
> +};
> +extern struct gicv3_data gicv3_data;
> +
> +#define gicv3_dist_base()(gicv3_data.dist_base)
> +#define gicv3_redist_base()
> (gicv3_data.redist_base[smp_processor_id()])
> +#define gicv3_sgi_base()
> (gicv3_data.redist_base[smp_processor_id()] + SZ_64K)
> +
> +extern int gicv3_init(void);
> +extern void gicv3_enable_defaults(void);
> +
> +static inline void gicv3_do_wait_for_rwp(void *base)
> +{
> + int count = 10; /* 1s */
> +
> + while (readl(base + GICD_CTLR) & GICD_CTLR_RWP) {
> + if (!--count) {
> + printf("GICv3: RWP timeout!\n");
> + abort();
> + }
> + cpu_relax();
> + udelay(10);
> + };
> +}
> +
> +static inline void gicv3_dist_wait_for_rwp(void)
> +{
> + gicv3_do_wait_for_rwp(gicv3_dist_base());
> +}
> +
> +static inline void gicv3_redist_wait_for_rwp(void)
> +{
> + gicv3_do_wait_for_rwp(gicv3_redist_base());
>
[Qemu-devel] [Bug 1546445] Re: support vhost user without specifying vhostforce
** Tags removed: sts-sru -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1546445 Title: support vhost user without specifying vhostforce Status in Ubuntu Cloud Archive: Fix Released Status in Ubuntu Cloud Archive kilo series: Fix Released Status in QEMU: Fix Released Status in qemu package in Ubuntu: Fix Released Status in qemu source package in Wily: Fix Released Bug description: [Impact] * vhost-user falls back to virtio-net which causes performance lose without specifying the vhostforce option. But it should be the default behavior for vhost-user, since guests using PMD doesn't support msi-x. [Test Case] create a vhost-user virtio backend without specifying the vhostforce option, i.e. -netdev type=vhost-user,id=mynet1,chardev= start the VM vhost-user is not enabled [Regression Potential] * none vhost user nic doesn't support non msi guests(like pxe stage) by default. Vhost user nic can't fall back to qemu like normal vhost net nic does. So we should enable it for non msi guests. The problem has been fix in qemu upstream - http://git.qemu.org/?p=qemu.git;a=commitdiff;h=24f938a682d934b133863eb421aac33592f7a09e. And the patch needs to be backported to 1:2.2+dfsg-5expubuntu9.8 . To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1546445/+subscriptions
Re: [Qemu-devel] [PATCH] spapr: Fix migration of PCI host bridges from qemu-2.7
On 09/11/16 23:19, David Gibson wrote:
> On Wed, Nov 09, 2016 at 04:14:25PM +1100, Alexey Kardashevskiy wrote:
>> On 09/11/16 14:45, David Gibson wrote:
>>> daa2369 "spapr_pci: Add a 64-bit MMIO window" subtly broke migration from
>>> qemu-2.7 to the current version. It split the device's MMIO window into
>>> two pieces for 32-bit and 64-bit MMIO.
>>>
>>> The patch included backwards compatibility code to convert the old property
>>> into the new format. However, the property value was also transferred in
>>> the migration stream and compared with a (probably unwise) VMSTATE_EQUAL.
>>> So, the "raw" value from 2.7 is compared to the new style converted value
>>> from (pre-)2.8 giving a mismatch and migration failure.
>>>
>>> Although it would be technically possible to fix this in a way allowing
>>> backwards migration, that would leave an ugly legacy around indefinitely.
>>> This patch takes the simpler approach of bumping the migration version,
>>> dropping the unwise VMSTATE_EQUAL (and some equally unwise ones around it)
>>> and ignoring them on an incoming migration.
>>>
>>> Signed-off-by: David Gibson
>>> ---
>>> hw/ppc/spapr_pci.c | 17 +++--
>>> 1 file changed, 11 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/hw/ppc/spapr_pci.c b/hw/ppc/spapr_pci.c
>>> index 7cde30e..7f1cc29 100644
>>> --- a/hw/ppc/spapr_pci.c
>>> +++ b/hw/ppc/spapr_pci.c
>>> @@ -1658,19 +1658,24 @@ static int spapr_pci_post_load(void *opaque, int
>>> version_id)
>>> return 0;
>>> }
>>>
>>> +static bool version_before_3(void *opaque, int version_id)
>>> +{
>>> +return version_id < 3;
>>> +}
>>> +
>>> static const VMStateDescription vmstate_spapr_pci = {
>>> .name = "spapr_pci",
>>> -.version_id = 2,
>>> +.version_id = 3,
>>> .minimum_version_id = 2,
>>> .pre_save = spapr_pci_pre_save,
>>> .post_load = spapr_pci_post_load,
>>> .fields = (VMStateField[]) {
>>> VMSTATE_UINT64_EQUAL(buid, sPAPRPHBState),
>>
>>
>> You could probably go one step further and get rid of @buid as well.
>
> I thought about it. buid at least is specified state that's
> vanishingly unlikely to change or disappear from the device. It also
> does serve to make sure that QOM instance matching - which is always a
> bit black magicy to me - is lining things up correctly.
afaict to fix matching properly, TYPE_SYS_BUS_DEVICE needs get_dev_path()
hook, just like spapr_vio_get_dev_name; otherwise SPAPR PHB in migration
always named as "spapr_pci" but yes, this would be much outside of the
scope of this patch :-/
>
>>
>> Nevertheless, this works,
>>
>> Reviewed-by: Alexey Kardashevskiy
>>
>>
>>
>>
>>> -VMSTATE_UINT32_EQUAL(dma_liobn[0], sPAPRPHBState),
>>> -VMSTATE_UINT64_EQUAL(mem_win_addr, sPAPRPHBState),
>>> -VMSTATE_UINT64_EQUAL(mem_win_size, sPAPRPHBState),
>>> -VMSTATE_UINT64_EQUAL(io_win_addr, sPAPRPHBState),
>>> -VMSTATE_UINT64_EQUAL(io_win_size, sPAPRPHBState),
>>> +VMSTATE_UNUSED_TEST(version_before_3, sizeof(uint32_t) /*
>>> dma_liobn[0] */
>>> ++ sizeof(uint64_t) /* mem_win_addr */
>>> ++ sizeof(uint64_t) /* mem_win_size */
>>> ++ sizeof(uint64_t) /* io_win_addr */
>>> ++ sizeof(uint64_t) /* io_win_size */),
>>> VMSTATE_STRUCT_ARRAY(lsi_table, sPAPRPHBState, PCI_NUM_PINS, 0,
>>> vmstate_spapr_pci_lsi, struct spapr_pci_lsi),
>>> VMSTATE_INT32(msi_devs_num, sPAPRPHBState),
>>>
>>
>>
>
--
Alexey
signature.asc
Description: OpenPGP digital signature
Re: [Qemu-devel] [PULL 0/3] Block patches
On Tue, Nov 08, 2016 at 06:12:39PM +, Stefan Hajnoczi wrote: > The following changes since commit 207faf24c58859f5240f66bf6decc33b87a1776e: > > Merge remote-tracking branch 'pm215/tags/pull-target-arm-20161107' into > staging (2016-11-07 14:02:15 +) > > are available in the git repository at: > > git://github.com/stefanha/qemu.git tags/block-pull-request > > for you to fetch changes up to 35dd66e23ce96283723de58e10d2877ae2be4a1b: > > aio-posix: simplify aio_epoll_update (2016-11-08 17:09:14 +) > > > > > > Kevin Wolf (1): > block: Don't mark node clean after failed flush > > Paolo Bonzini (2): > aio-posix: avoid NULL pointer dereference in aio_epoll_update > aio-posix: simplify aio_epoll_update > > aio-posix.c| 53 > +- > block/io.c | 4 ++- > tests/qemu-iotests/026.out | 22 > tests/qemu-iotests/026.out.nocache | 22 > tests/qemu-iotests/071.out | 2 ++ > 5 files changed, 73 insertions(+), 30 deletions(-) > > -- > 2.7.4 > > Thanks, applied to my staging tree: https://github.com/stefanha/qemu/commits/staging Stefan signature.asc Description: PGP signature
Re: [Qemu-devel] [PULL 0/1] Tracing patches
On Tue, Nov 08, 2016 at 06:17:32PM +, Stefan Hajnoczi wrote: > The following changes since commit 207faf24c58859f5240f66bf6decc33b87a1776e: > > Merge remote-tracking branch 'pm215/tags/pull-target-arm-20161107' into > staging (2016-11-07 14:02:15 +) > > are available in the git repository at: > > git://github.com/stefanha/qemu.git tags/tracing-pull-request > > for you to fetch changes up to 3b0fc80dd8ed9bd1ac738898e4fbd70c4a618925: > > docs/tracing.txt: Update documentation of default backend (2016-11-08 > 18:16:48 +) > > > > > > Peter Maydell (1): > docs/tracing.txt: Update documentation of default backend > > docs/tracing.txt | 7 +-- > 1 file changed, 5 insertions(+), 2 deletions(-) > > -- > 2.7.4 > > Thanks, applied to my staging tree: https://github.com/stefanha/qemu/commits/staging Stefan signature.asc Description: PGP signature
[Qemu-devel] [Bug 680758] Re: balloon only resizes by 2M
Triaging old bug tickets ... can you still reproduce this issue with the latest version of QEMU / the latest version of the balloon driver in the guest? ** Changed in: qemu Status: New => Incomplete -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/680758 Title: balloon only resizes by 2M Status in QEMU: Incomplete Bug description: when in monitor and running balloon 512 from a 1024M VM, the vm dropped the size to 1020 (this value changes), then every subsequent request to balloon 512 will drop it by another 2M. The system was running at above 60% RAM free when these requests were made. also requesting to up the ram results in no change above 1024 (I'm guessing this is intentional, but was unable to find any documentation) Versions: qemu-kvm 0.13.0 qemu-kvm.git b377474e589e5a1fe2abc7b13fafa8bad802637a Qemu Command Line: ./x86_64-softmmu/qemu-system-x86_64 -drive file=/var/machines/seven.base,if=virtio -net nic,model=virtio,macaddr=02:00:00:00:00:01 -net tap,script=/etc/qemu /qemu-ifup,downscript=/etc/qemu/qemu-ifdown -vga std -usb -usbdevice tablet -rtc base=localtime,clock=host -watchdog i6300esb -balloon virtio -m 1024 -no-quit -smp 2 -monitor stdio Monitor Session: QEMU 0.13.50 monitor - type 'help' for more information (qemu) info balloon balloon: actual=1024 (qemu) balloon 1536 (qemu) info balloon balloon: actual=1024 (qemu) balloon 512 (qemu) info balloon balloon: actual=1020 (qemu) info balloon balloon: actual=1020 (qemu) balloon 512 (qemu) info balloon balloon: actual=1018 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/680758/+subscriptions
Re: [Qemu-devel] [PATCH v7 RFC] block/vxhs: Initial commit to add Veritas HyperScale VxHS block device support
On 08/11/2016 16:39, Stefan Hajnoczi wrote: > The current status is: > > 1. virtio-blk and virtio-scsi support multiple queues but these queues >are processed from a single thread today. > > 2. MemoryRegions can be marked with !global_locking so its handler >functions are dispatched without taking the QEMU global mutex. This >allows device emulation to run in multiple threads. Alternatively, virtio-blk and virtio-scsi can already use ioeventfd and "-object iothread,id=FOO -device virtio-blk-pci,iothread=FOO" to let device emulation run in a separate thread that doesn't take the QEMU global mutex. > 3. Paolo Bonzini (CCed) is currently working on make the block layer >(BlockDriverState and co) support access from multiple threads and >multiqueue. This is work in progress. > > If you are interested in this work keep an eye out for patch series from > Paolo Bonzini and Fam Zheng. The first part (drop RFifoLock) was committed for 2.8. It's a relatively long road, but these are the currently ready parts of the work: - take AioContext acquire/release in small critical sections - push AioContext down to individual callbacks - make BlockDriverState thread-safe The latter needs rebasing after the last changes to dirty bitmaps, but I think these patches should be ready for 2.9. These are the planned bits: - replace AioContext with fine-grained mutex in bdrv_aio_* - protect everything with CoMutex in bdrv_co_* - remove aio_context_acquire/release For now I was not planning to make network backends support multiqueue, only files. Paolo
[Qemu-devel] [PATCH v2] vhost: Update 'ioeventfd_started' with host notifiers
Following the recent refactor of virtio notfiers [1], more specifically the patch that uses virtio_bus_set_host_notifier [2] by default, core virtio code requires 'ioeventfd_started' to be set to true/false when the host notifiers are configured. Because not all vhost devices were update (eg. vhost-scsi) to use the new interface, this value is always set to false. When booting a guest with a vhost-scsi backend controller, SeaBIOS will initially configure the device which sets all notifiers. The guest will continue to boot fine until the kernel virtio-scsi driver reinitialises the device causing a stop followed by another start. Since ioeventfd_started was never set to true, the 'stop' operation triggered by virtio_bus_set_host_notifier() will not result in a call to virtio_pci_ioeventfd_assign(assign=false). This leaves the memory regions with stale notifiers and results on the next start triggering the following assertion: kvm_mem_ioeventfd_add: error adding ioeventfd: File exists Aborted This patch updates ioeventfd_started whenever the notifiers are set or cleared, fixing this issue. Signed-off-by: Felipe Franciosi [1] http://lists.nongnu.org/archive/html/qemu-devel/2016-10/msg07748.html [2] http://lists.nongnu.org/archive/html/qemu-devel/2016-10/msg07760.html --- v1->v2: - Update ioeventfd_started in vhost_dev_enable/disable_notifiers() instead of vhost_scsi_start/stop(). - Reword the commit message accordingly. --- hw/virtio/vhost.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/hw/virtio/vhost.c b/hw/virtio/vhost.c index 131f164..1290963 100644 --- a/hw/virtio/vhost.c +++ b/hw/virtio/vhost.c @@ -1205,6 +1205,7 @@ int vhost_dev_enable_notifiers(struct vhost_dev *hdev, VirtIODevice *vdev) goto fail_vq; } } +VIRTIO_BUS(qbus)->ioeventfd_started = true; return 0; fail_vq: @@ -1239,6 +1240,7 @@ void vhost_dev_disable_notifiers(struct vhost_dev *hdev, VirtIODevice *vdev) } assert (r >= 0); } +VIRTIO_BUS(qbus)->ioeventfd_started = false; virtio_device_start_ioeventfd(vdev); } -- 1.9.4
[Qemu-devel] [PULL for-2.8 0/1] ipxe: update to 20161108 snapshot.
Hi, This rebases ipxe to latest master. ipxe qemu builds will not use fxsave/fxrestore any more, which caused problems on older intel cpus due to kvm not emulating these instructions. Special thanks to Laszlo for pushing these patches to ipxe upstream, they finally landed in ipxe master yesterday. please pull, Gerd The following changes since commit 207faf24c58859f5240f66bf6decc33b87a1776e: Merge remote-tracking branch 'pm215/tags/pull-target-arm-20161107' into staging (2016-11-07 14:02:15 +) are available in the git repository at: git://git.kraxel.org/qemu tags/pull-ipxe-20161109-1 for you to fetch changes up to 129fa54c734f4dbaf8d3bb9ca47283a2add2e4dc: ipxe: update to 20161108 snapshot (2016-11-09 09:49:33 +0100) ipxe: update to 20161108 snapshot. Gerd Hoffmann (1): ipxe: update to 20161108 snapshot pc-bios/efi-e1000.rom| Bin 209408 -> 209920 bytes pc-bios/efi-e1000e.rom | Bin 209408 -> 209920 bytes pc-bios/efi-eepro100.rom | Bin 209920 -> 209920 bytes pc-bios/efi-ne2k_pci.rom | Bin 208384 -> 208896 bytes pc-bios/efi-pcnet.rom| Bin 208384 -> 208896 bytes pc-bios/efi-rtl8139.rom | Bin 211456 -> 212480 bytes pc-bios/efi-virtio.rom | Bin 211456 -> 212480 bytes pc-bios/efi-vmxnet3.rom | Bin 205312 -> 206848 bytes roms/ipxe| 2 +- 9 files changed, 1 insertion(+), 1 deletion(-)
[Qemu-devel] [Bug 721793] Re: QEMU freezes on startup (100% CPU utilization)
Closing as "Fix released" according to comment #3 ** Changed in: qemu Status: New => Fix Released -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/721793 Title: QEMU freezes on startup (100% CPU utilization) Status in QEMU: Fix Released Bug description: 0.12.5 was the last version of QEMU that runs ok and boots any os image. 0.13.0-0.14.0 just freeze, and the only thing I see is a black screen and both of them make it use 100% of CPU also. Both kernels 2.6.35.11 and 2.6.37.1 with and without PAE support. tested commands: W2000: $ qemu -m 256 -localtime -net nic,model=rtl8139 -net tap -usbdevice host:0e21:0750 /var/opt/vm/w2000.img W2000: $ qemu /var/opt/vm/w2000.img OpenBSD 4.8: $ qemu -cdrom ~/cd48.iso -boot d empty-qcow2.img tried to use `-M pc-0.12` selector, different audio cards (I've found it caused infinite loop on startup once) -- no luck. tried to use recent seabios from git -- still no luck. attached strace log of 0.14.0. everything was tested on HP mini 311C with Intel Atom N270. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/721793/+subscriptions
[Qemu-devel] [PULL 1/1] ipxe: update to 20161108 snapshot
git shortlog 04186319..b991c67c === Laszlo Ersek (3): [efi] Install the HII config access protocol on a child of the SNP handle [librm] Conditionalize the workaround for the Tivoli VMM's SSE garbling [build] Disable TIVOLI_VMM_WORKAROUND in the qemu configuration Lukas Grossar (1): [intel] Add PCI device ID for I219-V/LM Michael Brown (57): [efi] Fix uninitialised data in HII IFR structures [bios] Do not enable interrupts when printing to the console [pxe] Disable interrupts on the PIC before starting NBP [dhcp] Allow for variable encapsulation of architecture-specific options [dhcpv6] Include RFC5970 client architecture options in DHCPv6 requests [dhcpv6] Include vendor class identifier option in DHCPv6 requests [dhcp] Automatically generate vendor class identifier string [xfer] Send intf_close() if redirection fails [downloader] Treat redirection failures as fatal [iscsi] Treat redirection failures as fatal [debug] Allow per-object runtime enabling/disabling of debug messages [debug] Allow debug messages to be initially disabled at runtime [libc] Allow assertions to be globally enabled or disabled [profile] Allow profiling to be globally enabled or disabled [rng] Check for functioning RTC interrupt [acpi] Add support for ACPI power off [acpi] Allow time for ACPI power off to take effect [ipv4] Send gratuitous ARPs whenever a new IPv4 address is applied [intel] Strip spurious VLAN tags received by virtual function NICs [intel] Remove duplicate intelvf_mbox_queues() function [ipv6] Perform SLAAC only during autoconfiguration [settings] Create space for IPv6 in settings display order [ipv6] Rename ipv6_scope to dhcpv6_scope [settings] Correctly mortalise autovivified child settings blocks [ipv6] Allow settings to comprise arbitrary subsets of NDP options [ipv6] Expose IPv6 settings acquired through NDP [dhcpv6] Expose IPv6 address setting acquired through DHCPv6 [ipv6] Expose IPv6 link-local address settings [settings] Allow settings blocks to specify a sibling ordering [ipv6] Match user expectations for IPv6 settings priorities [ipv6] Create routing table based on IPv6 settings [ipv6] Rename ipv6_scope to ipv6_settings_scope [test] Update IPv6 tests to use okx() [ipv6] Allow for multiple routers [hyperv] Use instance UUID in device name [crypto] Remove obsolete extern declaration for asn1_invalidate_cursor() [crypto] Allow for parsing of partial ASN.1 cursors [image] Add image_asn1() to extract ASN.1 objects from image [crypto] Add DER image format [crypto] Add PEM image format [image] Use image_asn1() to extract data from CMS signature images [build] Remove obsolete explicit object requirements [crypto] Enable both DER and PEM formats by default [build] Remove more obsolete explicit object requirements [pixbuf] Enable PNG format by default [crypto] Add image_x509() to extract X.509 certificates from image [crypto] Generalise X.509 "valid" field to a "flags" field [list] Add list_next_entry() and list_prev_entry() [crypto] Expose certstore_del() to explicitly remove stored certificates [crypto] Allow certificates to be marked as having been added explicitly [crypto] Add certstat() to display basic certificate information [cmdline] Add certificate management commands [crypto] Mark permanent certificates as permanent [efi] Mark AppleNetBoot.h as a native iPXE header [efi] Update to current EDK2 headers [efi] Add EFI_BLOCK_IO2_PROTOCOL header and GUID definition [bzimage] Fix page alignment of initrd images Signed-off-by: Gerd Hoffmann --- pc-bios/efi-e1000.rom| Bin 209408 -> 209920 bytes pc-bios/efi-e1000e.rom | Bin 209408 -> 209920 bytes pc-bios/efi-eepro100.rom | Bin 209920 -> 209920 bytes pc-bios/efi-ne2k_pci.rom | Bin 208384 -> 208896 bytes pc-bios/efi-pcnet.rom| Bin 208384 -> 208896 bytes pc-bios/efi-rtl8139.rom | Bin 211456 -> 212480 bytes pc-bios/efi-virtio.rom | Bin 211456 -> 212480 bytes pc-bios/efi-vmxnet3.rom | Bin 205312 -> 206848 bytes roms/ipxe| 2 +- 9 files changed, 1 insertion(+), 1 deletion(-) diff --git a/pc-bios/efi-e1000.rom b/pc-bios/efi-e1000.rom index 4e61f9b..6759924 100644 Binary files a/pc-bios/efi-e1000.rom and b/pc-bios/efi-e1000.rom differ diff --git a/pc-bios/efi-e1000e.rom b/pc-bios/efi-e1000e.rom index 192a437..145896c 100644 Binary files a/pc-bios/efi-e1000e.rom and b/pc-bios/efi-e1000e.rom differ diff --git a/pc-bios/efi-eepro100.rom b/pc-bios/efi-eepro100.rom index 66c5226..ff2793f 100644 Binary files a/pc-bios/efi-eepro100.rom and b/pc-bios/efi-eepro100.rom differ diff --git a/pc-bios/efi-ne2k_pci.rom b/pc-bios/efi-ne2k_pci.rom index 8c3e5
[Qemu-devel] [Bug 772275] Re: qemu-kvm-0.14.0 + kernel 2.6.35 : win2008r2 virtio nic hanging
Triaging old bug tickets ... can you still reproduce this problem with the latest version of QEMU and the latest version of the virtio-net drivers? ** Changed in: qemu Status: New => Incomplete -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/772275 Title: qemu-kvm-0.14.0 + kernel 2.6.35 : win2008r2 virtio nic hanging Status in QEMU: Incomplete Bug description: Hi, I'm a proxmox distrib user, I have network error with virtio nic cards in win2008r2sp1 server, only with qemu 0.14 and 2.6.35 kernel combination. after some network transferts (can be 2mb or 500mb), nic doesn't respond anymore. only way is to reboot. e1000 driver working fine. revert back to qemu 0.13+ 2.6.35 kernel works fine or qemu 0.14 + 2.6.32 kernel is working fine too. i'm using virtio nic drivers 1.1.16 from http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/ i had also tried the virtio-win-prewhql-0.1-7-nic.tar.gz from https://bugzilla.redhat.com/show_bug.cgi?id=630830#c26 i'm not the only proxmox user ,more users reports here : http://forum.proxmox.com/threads/6194-Troubles-with-latest-virtio- drivers-for-Windows-and-latest-PVE-1.8 i've also see that a slackware user with winxp guest has the same problem http://www.spinics.net/lists/kvm/msg51089.html I can help to debug if it's possible to have logs somewhere . To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/772275/+subscriptions
[Qemu-devel] [Bug 881637] Re: QEMU fails to build on OpenBSD/hppa
Do you still have this problem with the latest version of QEMU and a more recent version of GCC? ** Changed in: qemu Status: New => Incomplete -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/881637 Title: QEMU fails to build on OpenBSD/hppa Status in QEMU: Incomplete Bug description: Trying to build previous QEMU releases as well as git code fails on OpenBSD/hppa... cc -I/home/hack/jasper/qemu/slirp -I. -I/home/hack/jasper/qemu -I/home/hack/jasper/qemu/fpu -I/home/hack/jasper/qemu/tcg -I/home/hack/jasper/qemu/tcg/hppa -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -Wno-redundant-decls -I/usr/local/include -I/usr/X11R6/include -Wendif-labels -Wmissing-include-dirs -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wold-style-definition -I/usr/local/include/libpng -DHAS_AUDIO -DHAS_AUDIO_CHOICE -DTARGET_PHYS_ADDR_BITS=64 -I.. -I/home/hack/jasper/qemu/target-i386 -DNEED_CPU_H -pthread -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include-I/usr/local/include/libpng -pthread -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -MMD -MP -MT translate.o -MF ./translate.d -O2 -g -c -o translate.o /home/hack/jasper/qemu/target-i386/translate.c /tmp//ccvNbj1U.s: Assembler messages: /tmp//ccvNbj1U.s:258792: Error: Field out of range [-262144..262143] (-262776). /tmp//ccvNbj1U.s:261989: Error: Field out of range [-262144..262143] (-267096). /tmp//ccvNbj1U.s:262006: Error: Field out of range [-262144..262143] (-267136). /tmp//ccvNbj1U.s:264184: Error: Field out of range [-262144..262143] (-270612). /tmp//ccvNbj1U.s:271893: Error: Field out of range [-262144..262143] (-281260). /tmp//ccvNbj1U.s:276623: Error: Field out of range [-262144..262143] (-288784). /tmp//ccvNbj1U.s:276906: Error: Field out of range [-262144..262143] (-289636). /tmp//ccvNbj1U.s:277122: Error: Field out of range [-262144..262143] (-290280). To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/881637/+subscriptions
Re: [Qemu-devel] [PATCH] nbd: Don't inf-loop on early EOF
On 07/11/2016 23:45, Eric Blake wrote: > On 11/07/2016 04:22 PM, Max Reitz wrote: >> On 07.11.2016 21:38, Eric Blake wrote: >>> Commit 7d3123e converted a single read_sync() into a while loop >>> that assumed that read_sync() would either make progress or give >>> an error. But when the server hangs up early, the client sees >>> EOF (a read_sync() of 0) and never makes progress, which in turn >>> caused qemu-iotest './check -nbd 83' to go into an infinite loop. >>> >>> Rework the loop to accomodate reads cut short by EOF. >>> >>> Reported-by: Max Reitz >>> Signed-off-by: Eric Blake >>> --- >>> nbd/client.c | 13 +++-- >>> 1 file changed, 7 insertions(+), 6 deletions(-) >> >> Reviewed-by: Max Reitz >> >> But what about the server's nbd_negotiate_drop_sync()? It uses pretty >> much the same code, so it seems susceptible to the same issue (only that >> we don't have a test for that side). > > If so, that's an older bug (pre-existing back to at least 2.6?), so it > should be a separate fix, if anything. > > I guess it's time to figure out how to test the server against > ill-behaved clients... Using afl perhaps? Paolo
Re: [Qemu-devel] [kvm-unit-tests PATCH v4 09/11] arm/arm64: add initial gicv3 support
On Wed, Nov 09, 2016 at 12:35:48PM +, Andre Przywara wrote:
[...]
> > diff --git a/lib/arm/asm/gic-v3.h b/lib/arm/asm/gic-v3.h
> > new file mode 100644
> > index ..03321f8c860f
> > --- /dev/null
> > +++ b/lib/arm/asm/gic-v3.h
> > @@ -0,0 +1,92 @@
> > +/*
> > + * All GIC* defines are lifted from include/linux/irqchip/arm-gic-v3.h
> > + *
> > + * Copyright (C) 2016, Red Hat Inc, Andrew Jones
> > + *
> > + * This work is licensed under the terms of the GNU LGPL, version 2.
> > + */
> > +#ifndef _ASMARM_GIC_V3_H_
> > +#define _ASMARM_GIC_V3_H_
> > +
> > +#ifndef _ASMARM_GIC_H_
> > +#error Do not directly include . Include
> > +#endif
> > +
> > +#define GICD_CTLR 0x
> > +#define GICD_TYPER 0x0004
>
> So if we share the distributor register definition with GICv2, these
> shouldn't be here, but in gic.h.
> But this is the right naming scheme we should use (instead of GIC_DIST_xxx).
>
> Now this gets interesting with your wish to both share the definitions
> for the GICv2 and GICv3 distributors, but also stick to the names the
> kernel uses (because they differ between the two) ;-)
> So now you loose the greppability for either GIC_DIST_CTR or GICD_TYPER,
> for instance.
Well, we just have the same offset with two names (giving us two
symbols to grep). I put them here, vs. asm/gic.h, because the kernel
only uses theses symbols for gicv3. Now, nothing stops a unit test
from using them with gicv2 tests, though, because unit tests include
gic.h, which includes both gic-v2.h and gic-v3.h, and thus it gets
both. I know, it's sounding messy... Shouldn't we post some churn to
the kernel? :-)
Note, I tried to only add defines to asm/gic.h that are actually
shared in the kernel between v2 and v3, e.g. GIC_DIST_ENABLE_SET.
Actually, GIC_DIST_CTRL and GIC_DIST_CTR may be the only exceptions
we have so far.
>
> > +#define GICD_IGROUPR 0x0080
> > +
> > +#define GICD_CTLR_RWP (1U << 31)
> > +#define GICD_CTLR_ARE_NS (1U << 4)
> > +#define GICD_CTLR_ENABLE_G1A (1U << 1)
> > +#define GICD_CTLR_ENABLE_G1(1U << 0)
> > +
> > +#define GICR_TYPER 0x0008
> > +#define GICR_IGROUPR0 GICD_IGROUPR
> > +#define GICR_TYPER_LAST(1U << 4)
> > +
> > +
> > +#include
> > +
> > +#ifndef __ASSEMBLY__
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +struct gicv3_data {
> > + void *dist_base;
> > + void *redist_base[NR_CPUS];
> > + unsigned int irq_nr;
> > +};
> > +extern struct gicv3_data gicv3_data;
> > +
> > +#define gicv3_dist_base() (gicv3_data.dist_base)
> > +#define gicv3_redist_base()
> > (gicv3_data.redist_base[smp_processor_id()])
> > +#define gicv3_sgi_base()
> > (gicv3_data.redist_base[smp_processor_id()] + SZ_64K)
> > +
> > +extern int gicv3_init(void);
> > +extern void gicv3_enable_defaults(void);
> > +
> > +static inline void gicv3_do_wait_for_rwp(void *base)
> > +{
> > + int count = 10; /* 1s */
> > +
> > + while (readl(base + GICD_CTLR) & GICD_CTLR_RWP) {
> > + if (!--count) {
> > + printf("GICv3: RWP timeout!\n");
> > + abort();
> > + }
> > + cpu_relax();
> > + udelay(10);
> > + };
> > +}
> > +
> > +static inline void gicv3_dist_wait_for_rwp(void)
> > +{
> > + gicv3_do_wait_for_rwp(gicv3_dist_base());
> > +}
> > +
> > +static inline void gicv3_redist_wait_for_rwp(void)
> > +{
> > + gicv3_do_wait_for_rwp(gicv3_redist_base());
> > +}
> > +
> > +static inline u32 mpidr_compress(u64 mpidr)
> > +{
> > + u64 compressed = mpidr & MPIDR_HWID_BITMASK;
> > +
> > + compressed = (((compressed >> 32) & 0xff) << 24) | compressed;
> > + return compressed;
> > +}
> > +
> > +static inline u64 mpidr_uncompress(u32 compressed)
> > +{
> > + u64 mpidr = ((u64)compressed >> 24) << 32;
> > +
> > + mpidr |= compressed & MPIDR_HWID_BITMASK;
> > + return mpidr;
> > +}
> > +
> > +#endif /* !__ASSEMBLY__ */
> > +#endif /* _ASMARM_GIC_V3_H_ */
> > diff --git a/lib/arm/asm/gic.h b/lib/arm/asm/gic.h
> > index 328e078a9ae1..4897bc592cdd 100644
> > --- a/lib/arm/asm/gic.h
> > +++ b/lib/arm/asm/gic.h
> > @@ -7,6 +7,7 @@
> > #define _ASMARM_GIC_H_
> >
> > #include
> > +#include
> >
> > #define GIC_CPU_CTRL 0x00
> > #define GIC_CPU_PRIMASK0x04
> > diff --git a/lib/arm/gic.c b/lib/arm/gic.c
> > index 91d78c9a0cc2..af58a11ea13e 100644
> > --- a/lib/arm/gic.c
> > +++ b/lib/arm/gic.c
> > @@ -8,9 +8,11 @@
> > #include
> >
> > struct gicv2_data gicv2_data;
> > +struct gicv3_data gicv3_data;
> >
> > /*
> > * Documentation/devicetree/bindings/interrupt-controller/arm,gic.txt
> > + * Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt
> > */
> > static bool
> > gic_get_dt_bases(const char *compatible, void **base1, void **base2)
[Qemu-devel] [PATCH] vhost: Use vbus var instead of VIRTIO_BUS() macro
Recent changes on vhost_dev_enable/disable_notifiers() produced a
VirtioBusState vbus variable which can be used instead of the
VIRTIO_BUS() macro. This commit just makes the code a little bit cleaner
and more consistent.
Signed-off-by: Felipe Franciosi
---
hw/virtio/vhost.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/hw/virtio/vhost.c b/hw/virtio/vhost.c
index 1290963..7d29dad 100644
--- a/hw/virtio/vhost.c
+++ b/hw/virtio/vhost.c
@@ -1198,20 +1198,18 @@ int vhost_dev_enable_notifiers(struct vhost_dev *hdev,
VirtIODevice *vdev)
virtio_device_stop_ioeventfd(vdev);
for (i = 0; i < hdev->nvqs; ++i) {
-r = virtio_bus_set_host_notifier(VIRTIO_BUS(qbus), hdev->vq_index + i,
- true);
+r = virtio_bus_set_host_notifier(vbus, hdev->vq_index + i, true);
if (r < 0) {
error_report("vhost VQ %d notifier binding failed: %d", i, -r);
goto fail_vq;
}
}
-VIRTIO_BUS(qbus)->ioeventfd_started = true;
+vbus->ioeventfd_started = true;
return 0;
fail_vq:
while (--i >= 0) {
-e = virtio_bus_set_host_notifier(VIRTIO_BUS(qbus), hdev->vq_index + i,
- false);
+e = virtio_bus_set_host_notifier(vbus, hdev->vq_index + i, false);
if (e < 0) {
error_report("vhost VQ %d notifier cleanup error: %d", i, -r);
}
@@ -1230,17 +1228,17 @@ fail:
void vhost_dev_disable_notifiers(struct vhost_dev *hdev, VirtIODevice *vdev)
{
BusState *qbus = BUS(qdev_get_parent_bus(DEVICE(vdev)));
+VirtioBusState *vbus = VIRTIO_BUS(qbus);
int i, r;
for (i = 0; i < hdev->nvqs; ++i) {
-r = virtio_bus_set_host_notifier(VIRTIO_BUS(qbus), hdev->vq_index + i,
- false);
+r = virtio_bus_set_host_notifier(vbus, hdev->vq_index + i, false);
if (r < 0) {
error_report("vhost VQ %d notifier cleanup failed: %d", i, -r);
}
assert (r >= 0);
}
-VIRTIO_BUS(qbus)->ioeventfd_started = false;
+vbus->ioeventfd_started = false;
virtio_device_start_ioeventfd(vdev);
}
--
1.9.4
Re: [Qemu-devel] [PATCH] vhost: Use vbus var instead of VIRTIO_BUS() macro
On 09/11/2016 14:18, Felipe Franciosi wrote:
> Recent changes on vhost_dev_enable/disable_notifiers() produced a
> VirtioBusState vbus variable which can be used instead of the
> VIRTIO_BUS() macro. This commit just makes the code a little bit cleaner
> and more consistent.
>
> Signed-off-by: Felipe Franciosi
Michael, what do you think? Perhaps it's simplest to just squash the
two patches (v2 of "vhost: Update 'ioeventfd_started' with host
notifiers" and this one).
Paolo
> ---
> hw/virtio/vhost.c | 14 ++
> 1 file changed, 6 insertions(+), 8 deletions(-)
>
> diff --git a/hw/virtio/vhost.c b/hw/virtio/vhost.c
> index 1290963..7d29dad 100644
> --- a/hw/virtio/vhost.c
> +++ b/hw/virtio/vhost.c
> @@ -1198,20 +1198,18 @@ int vhost_dev_enable_notifiers(struct vhost_dev
> *hdev, VirtIODevice *vdev)
>
> virtio_device_stop_ioeventfd(vdev);
> for (i = 0; i < hdev->nvqs; ++i) {
> -r = virtio_bus_set_host_notifier(VIRTIO_BUS(qbus), hdev->vq_index +
> i,
> - true);
> +r = virtio_bus_set_host_notifier(vbus, hdev->vq_index + i, true);
> if (r < 0) {
> error_report("vhost VQ %d notifier binding failed: %d", i, -r);
> goto fail_vq;
> }
> }
> -VIRTIO_BUS(qbus)->ioeventfd_started = true;
> +vbus->ioeventfd_started = true;
>
> return 0;
> fail_vq:
> while (--i >= 0) {
> -e = virtio_bus_set_host_notifier(VIRTIO_BUS(qbus), hdev->vq_index +
> i,
> - false);
> +e = virtio_bus_set_host_notifier(vbus, hdev->vq_index + i, false);
> if (e < 0) {
> error_report("vhost VQ %d notifier cleanup error: %d", i, -r);
> }
> @@ -1230,17 +1228,17 @@ fail:
> void vhost_dev_disable_notifiers(struct vhost_dev *hdev, VirtIODevice *vdev)
> {
> BusState *qbus = BUS(qdev_get_parent_bus(DEVICE(vdev)));
> +VirtioBusState *vbus = VIRTIO_BUS(qbus);
> int i, r;
>
> for (i = 0; i < hdev->nvqs; ++i) {
> -r = virtio_bus_set_host_notifier(VIRTIO_BUS(qbus), hdev->vq_index +
> i,
> - false);
> +r = virtio_bus_set_host_notifier(vbus, hdev->vq_index + i, false);
> if (r < 0) {
> error_report("vhost VQ %d notifier cleanup failed: %d", i, -r);
> }
> assert (r >= 0);
> }
> -VIRTIO_BUS(qbus)->ioeventfd_started = false;
> +vbus->ioeventfd_started = false;
> virtio_device_start_ioeventfd(vdev);
> }
>
>
Re: [Qemu-devel] [PATCH] vhost: Use vbus var instead of VIRTIO_BUS() macro
> On 9 Nov 2016, at 14:22, Paolo Bonzini wrote:
>
>
>
> On 09/11/2016 14:18, Felipe Franciosi wrote:
>> Recent changes on vhost_dev_enable/disable_notifiers() produced a
>> VirtioBusState vbus variable which can be used instead of the
>> VIRTIO_BUS() macro. This commit just makes the code a little bit cleaner
>> and more consistent.
>>
>> Signed-off-by: Felipe Franciosi
>
> Michael, what do you think? Perhaps it's simplest to just squash the
> two patches (v2 of "vhost: Update 'ioeventfd_started' with host
> notifiers" and this one).
>
> Paolo
Please, do. I just realised the repeated use of VIRTIO_BUS() after sending the
first patch (Update 'ioeventfd_started' with host notifiers) and decided to
ship this one too to get them both in if possible.
Thanks,
Felipe
>
>> ---
>> hw/virtio/vhost.c | 14 ++
>> 1 file changed, 6 insertions(+), 8 deletions(-)
>>
>> diff --git a/hw/virtio/vhost.c b/hw/virtio/vhost.c
>> index 1290963..7d29dad 100644
>> --- a/hw/virtio/vhost.c
>> +++ b/hw/virtio/vhost.c
>> @@ -1198,20 +1198,18 @@ int vhost_dev_enable_notifiers(struct vhost_dev
>> *hdev, VirtIODevice *vdev)
>>
>> virtio_device_stop_ioeventfd(vdev);
>> for (i = 0; i < hdev->nvqs; ++i) {
>> -r = virtio_bus_set_host_notifier(VIRTIO_BUS(qbus), hdev->vq_index +
>> i,
>> - true);
>> +r = virtio_bus_set_host_notifier(vbus, hdev->vq_index + i, true);
>> if (r < 0) {
>> error_report("vhost VQ %d notifier binding failed: %d", i, -r);
>> goto fail_vq;
>> }
>> }
>> -VIRTIO_BUS(qbus)->ioeventfd_started = true;
>> +vbus->ioeventfd_started = true;
>>
>> return 0;
>> fail_vq:
>> while (--i >= 0) {
>> -e = virtio_bus_set_host_notifier(VIRTIO_BUS(qbus), hdev->vq_index +
>> i,
>> - false);
>> +e = virtio_bus_set_host_notifier(vbus, hdev->vq_index + i, false);
>> if (e < 0) {
>> error_report("vhost VQ %d notifier cleanup error: %d", i, -r);
>> }
>> @@ -1230,17 +1228,17 @@ fail:
>> void vhost_dev_disable_notifiers(struct vhost_dev *hdev, VirtIODevice *vdev)
>> {
>> BusState *qbus = BUS(qdev_get_parent_bus(DEVICE(vdev)));
>> +VirtioBusState *vbus = VIRTIO_BUS(qbus);
>> int i, r;
>>
>> for (i = 0; i < hdev->nvqs; ++i) {
>> -r = virtio_bus_set_host_notifier(VIRTIO_BUS(qbus), hdev->vq_index +
>> i,
>> - false);
>> +r = virtio_bus_set_host_notifier(vbus, hdev->vq_index + i, false);
>> if (r < 0) {
>> error_report("vhost VQ %d notifier cleanup failed: %d", i, -r);
>> }
>> assert (r >= 0);
>> }
>> -VIRTIO_BUS(qbus)->ioeventfd_started = false;
>> +vbus->ioeventfd_started = false;
>> virtio_device_start_ioeventfd(vdev);
>> }
>>
>>
[Qemu-devel] [PATCH v2 2/5] target-m68k: Do not cpu_abort on undefined insns
Report this properly via exception and, importantly, allow
the disassembler the chance to tell us what insn is not handled.
Reviewed-by: Laurent Vivier
Signed-off-by: Richard Henderson
---
target-m68k/translate.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/target-m68k/translate.c b/target-m68k/translate.c
index ca99072..4f224d7 100644
--- a/target-m68k/translate.c
+++ b/target-m68k/translate.c
@@ -1577,10 +1577,12 @@ DISAS_INSN(undef_fpu)
DISAS_INSN(undef)
{
-M68kCPU *cpu = m68k_env_get_cpu(env);
-
+/* ??? This is both instructions that are as yet unimplemented
+ for the 680x0 series, as well as those that are implemented
+ but actually illegal for CPU32 or pre-68020. */
+qemu_log_mask(LOG_UNIMP, "Illegal instruction: %04x @ %08x",
+ insn, s->pc - 2);
gen_exception(s, s->pc - 2, EXCP_UNSUPPORTED);
-cpu_abort(CPU(cpu), "Illegal instruction: %04x @ %08x", insn, s->pc - 2);
}
DISAS_INSN(mulw)
--
2.7.4
[Qemu-devel] [PATCH v2 0/5] target-m68k-patches
Changes since v1: * Tweaked local variable decls for movem. * Fixed the bitfield patches such that they work with linux-user-test-0.3. (Along with the whole passle of extra patches required to make that work.) The register bitfield patch still depends on the patches posted here in another thread implementing extract and sextract. r~ Laurent Vivier (1): target-m68k: Implement 680x0 movem Richard Henderson (4): target-m68k: Do not cpu_abort on undefined insns target-m68k: Inline shifts target-m68k: Implement bitfield ops for registers target-m68k: Implement bitfield ops for memory target-m68k/cpu.h | 1 + target-m68k/helper.c| 52 target-m68k/helper.h| 10 +- target-m68k/op_helper.c | 185 + target-m68k/translate.c | 702 5 files changed, 843 insertions(+), 107 deletions(-) -- 2.7.4
[Qemu-devel] [PATCH v2 3/5] target-m68k: Inline shifts
Also manage word and byte operands and fix the computation of
overflow in the case of M68000 arithmetic shifts.
Signed-off-by: Laurent Vivier
Signed-off-by: Richard Henderson
---
target-m68k/helper.c| 52
target-m68k/helper.h| 3 -
target-m68k/translate.c | 214 ++--
3 files changed, 189 insertions(+), 80 deletions(-)
diff --git a/target-m68k/helper.c b/target-m68k/helper.c
index 60fe997..25d5dc1 100644
--- a/target-m68k/helper.c
+++ b/target-m68k/helper.c
@@ -320,58 +320,6 @@ void HELPER(set_sr)(CPUM68KState *env, uint32_t val)
m68k_switch_sp(env);
}
-uint32_t HELPER(shl_cc)(CPUM68KState *env, uint32_t val, uint32_t shift)
-{
-uint64_t result;
-
-shift &= 63;
-result = (uint64_t)val << shift;
-
-env->cc_c = (result >> 32) & 1;
-env->cc_n = result;
-env->cc_z = result;
-env->cc_v = 0;
-env->cc_x = shift ? env->cc_c : env->cc_x;
-
-return result;
-}
-
-uint32_t HELPER(shr_cc)(CPUM68KState *env, uint32_t val, uint32_t shift)
-{
-uint64_t temp;
-uint32_t result;
-
-shift &= 63;
-temp = (uint64_t)val << 32 >> shift;
-result = temp >> 32;
-
-env->cc_c = (temp >> 31) & 1;
-env->cc_n = result;
-env->cc_z = result;
-env->cc_v = 0;
-env->cc_x = shift ? env->cc_c : env->cc_x;
-
-return result;
-}
-
-uint32_t HELPER(sar_cc)(CPUM68KState *env, uint32_t val, uint32_t shift)
-{
-uint64_t temp;
-uint32_t result;
-
-shift &= 63;
-temp = (int64_t)val << 32 >> shift;
-result = temp >> 32;
-
-env->cc_c = (temp >> 31) & 1;
-env->cc_n = result;
-env->cc_z = result;
-env->cc_v = result ^ val;
-env->cc_x = shift ? env->cc_c : env->cc_x;
-
-return result;
-}
-
/* MAC unit. */
/* FIXME: The MAC unit implementation is a bit of a mess. Some helpers
take values, others take register numbers and manipulate the contents
diff --git a/target-m68k/helper.h b/target-m68k/helper.h
index 226ef5f..cae5bcb 100644
--- a/target-m68k/helper.h
+++ b/target-m68k/helper.h
@@ -7,9 +7,6 @@ DEF_HELPER_4(divul, void, env, int, int, i32)
DEF_HELPER_4(divsl, void, env, int, int, s32)
DEF_HELPER_4(divull, void, env, int, int, i32)
DEF_HELPER_4(divsll, void, env, int, int, s32)
-DEF_HELPER_3(shl_cc, i32, env, i32, i32)
-DEF_HELPER_3(shr_cc, i32, env, i32, i32)
-DEF_HELPER_3(sar_cc, i32, env, i32, i32)
DEF_HELPER_2(set_sr, void, env, i32)
DEF_HELPER_3(movec, void, env, i32, i32)
diff --git a/target-m68k/translate.c b/target-m68k/translate.c
index 4f224d7..1b3765f 100644
--- a/target-m68k/translate.c
+++ b/target-m68k/translate.c
@@ -2883,48 +2883,205 @@ DISAS_INSN(addx_mem)
gen_store(s, opsize, addr_dest, QREG_CC_N);
}
-/* TODO: This could be implemented without helper functions. */
-DISAS_INSN(shift_im)
+static inline void shift_im(DisasContext *s, uint16_t insn, int opsize)
{
-TCGv reg;
-int tmp;
-TCGv shift;
+int count = (insn >> 9) & 7;
+int logical = insn & 8;
+int left = insn & 0x100;
+int bits = opsize_bytes(opsize) * 8;
+TCGv reg = gen_extend(DREG(insn, 0), opsize, !logical);
+
+if (count == 0) {
+count = 8;
+}
+
+tcg_gen_movi_i32(QREG_CC_V, 0);
+if (left) {
+tcg_gen_shri_i32(QREG_CC_C, reg, bits - count);
+tcg_gen_shli_i32(QREG_CC_N, reg, count);
+
+/* Note that ColdFire always clears V (done above),
+ while M68000 sets if the most significant bit is changed at
+ any time during the shift operation */
+if (!logical && m68k_feature(s->env, M68K_FEATURE_M68000)) {
+/* if shift count >= bits, V is (reg != 0) */
+if (count >= bits) {
+tcg_gen_setcond_i32(TCG_COND_NE, QREG_CC_V, reg, QREG_CC_V);
+} else {
+TCGv t0 = tcg_temp_new();
+tcg_gen_sari_i32(QREG_CC_V, reg, bits - 1);
+tcg_gen_sari_i32(t0, t0, bits - count);
+tcg_gen_setcond_i32(TCG_COND_NE, QREG_CC_V, QREG_CC_V, t0);
+tcg_temp_free(t0);
+}
+tcg_gen_neg_i32(QREG_CC_V, QREG_CC_V);
+}
+} else {
+tcg_gen_shri_i32(QREG_CC_C, reg, count - 1);
+if (logical) {
+tcg_gen_shri_i32(QREG_CC_N, reg, count);
+} else {
+tcg_gen_sari_i32(QREG_CC_N, reg, count);
+}
+}
+
+gen_ext(QREG_CC_N, QREG_CC_N, opsize, 1);
+tcg_gen_andi_i32(QREG_CC_C, QREG_CC_C, 1);
+tcg_gen_mov_i32(QREG_CC_Z, QREG_CC_N);
+tcg_gen_mov_i32(QREG_CC_X, QREG_CC_C);
+gen_partset_reg(opsize, DREG(insn, 0), QREG_CC_N);
set_cc_op(s, CC_OP_FLAGS);
+}
-reg = DREG(insn, 0);
-tmp = (insn >> 9) & 7;
-if (tmp == 0)
-tmp = 8;
-shift = tcg_const_i32(tmp);
-/* No need to flush flags becuse we know we will set C flag. */
-if (insn & 0x100) {
-gen_helper_shl_cc(reg, cpu_env, reg, shift);
+static inline void shift_reg(DisasContext *s,
Re: [Qemu-devel] [PATCH] hw/input/hid: support alternative sysrq/break scancodes for gtk-vnc
Hi, > Now, it isn't obvious to me which sequence is really "right", but as the > 0x54/0xc6 keycodes are currently unused in hid.c, supporting both seems like > the pragmatic solution to me. The USB HID keyboard boot protocol used by > hid.c doesn't have any other mapping applicable to these keys. > > The other guest keyboard interfaces (ps/2, virtio, ..) are not affected, > because they handle these keys differently. A better fix would be to switch hid.c to use Q_KEY_CODE_* too. Patches doing that are welcome. It's a big change though and not reasonable to do during the freeze, so I'll go pick up this two-line fix for 2.8 nevertheless. thanks, Gerd
[Qemu-devel] [PATCH v2 1/5] target-m68k: Implement 680x0 movem
From: Laurent Vivier
680x0 movem can load/store words and long words and can use more
addressing modes. Coldfire can only use long words with (Ax) and
(d16,Ax) addressing modes.
Signed-off-by: Laurent Vivier
Signed-off-by: Richard Henderson
---
target-m68k/translate.c | 130 +++-
1 file changed, 107 insertions(+), 23 deletions(-)
diff --git a/target-m68k/translate.c b/target-m68k/translate.c
index 5d91e4e..ca99072 100644
--- a/target-m68k/translate.c
+++ b/target-m68k/translate.c
@@ -1793,40 +1793,122 @@ static void gen_push(DisasContext *s, TCGv val)
tcg_gen_mov_i32(QREG_SP, tmp);
}
+static TCGv mreg(int reg)
+{
+if (reg < 8) {
+/* Dx */
+return cpu_dregs[reg];
+}
+/* Ax */
+return cpu_aregs[reg & 7];
+}
+
DISAS_INSN(movem)
{
-TCGv addr;
+TCGv addr, incr, tmp, r[16];
+int is_load = (insn & 0x0400) != 0;
+int opsize = (insn & 0x40) != 0 ? OS_LONG : OS_WORD;
+uint16_t mask = read_im16(env, s);
+int mode = extract32(insn, 3, 3);
+int reg0 = REG(insn, 0);
int i;
-uint16_t mask;
-TCGv reg;
-TCGv tmp;
-int is_load;
-mask = read_im16(env, s);
-tmp = gen_lea(env, s, insn, OS_LONG);
-if (IS_NULL_QREG(tmp)) {
+tmp = cpu_aregs[reg0];
+
+switch (mode) {
+case 0: /* data register direct */
+case 1: /* addr register direct */
+do_addr_fault:
gen_addr_fault(s);
return;
+
+case 2: /* indirect */
+break;
+
+case 3: /* indirect post-increment */
+if (!is_load) {
+/* post-increment is not allowed */
+goto do_addr_fault;
+}
+break;
+
+case 4: /* indirect pre-decrement */
+if (is_load) {
+/* pre-decrement is not allowed */
+goto do_addr_fault;
+}
+/* We want a bare copy of the address reg, without any pre-decrement
+ adjustment, as gen_lea would provide. */
+break;
+
+default:
+tmp = gen_lea_mode(env, s, mode, reg0, opsize);
+if (IS_NULL_QREG(tmp)) {
+goto do_addr_fault;
+}
+break;
}
+
addr = tcg_temp_new();
tcg_gen_mov_i32(addr, tmp);
-is_load = ((insn & 0x0400) != 0);
-for (i = 0; i < 16; i++, mask >>= 1) {
-if (mask & 1) {
-if (i < 8)
-reg = DREG(i, 0);
-else
-reg = AREG(i, 0);
-if (is_load) {
-tmp = gen_load(s, OS_LONG, addr, 0);
-tcg_gen_mov_i32(reg, tmp);
-} else {
-gen_store(s, OS_LONG, addr, reg);
+incr = tcg_const_i32(opsize_bytes(opsize));
+
+if (is_load) {
+/* memory to register */
+for (i = 0; i < 16; i++) {
+if (mask & (1 << i)) {
+r[i] = gen_load(s, opsize, addr, 1);
+tcg_gen_add_i32(addr, addr, incr);
+}
+}
+for (i = 0; i < 16; i++) {
+if (mask & (1 << i)) {
+tcg_gen_mov_i32(mreg(i), r[i]);
+tcg_temp_free(r[i]);
+}
+}
+if (mode == 3) {
+/* post-increment: movem (An)+,X */
+tcg_gen_mov_i32(cpu_aregs[reg0], addr);
+}
+} else {
+/* register to memory */
+if (mode == 4) {
+/* pre-decrement: movem X,-(An) */
+for (i = 15; i >= 0; i--) {
+if ((mask << i) & 0x8000) {
+tcg_gen_sub_i32(addr, addr, incr);
+if (reg0 + 8 == i &&
+m68k_feature(s->env, M68K_FEATURE_EXT_FULL)) {
+/* M68020+: if the addressing register is the
+ * register moved to memory, the value written
+ * is the initial value decremented by the size of
+ * the operation, regardless of how many actual
+ * stores have been performed until this point.
+ * M68000/M68010: the value is the initial value.
+ */
+tmp = tcg_temp_new();
+tcg_gen_sub_i32(tmp, cpu_aregs[reg0], incr);
+gen_store(s, opsize, addr, tmp);
+tcg_temp_free(tmp);
+} else {
+gen_store(s, opsize, addr, mreg(i));
+}
+}
+}
+tcg_gen_mov_i32(cpu_aregs[reg0], addr);
+} else {
+for (i = 0; i < 16; i++) {
+if (mask & (1 << i)) {
+gen_store(s, opsize, addr, mreg(i));
+tcg_gen_add_i32(addr, addr, incr);
+}
}
-if (mask != 1)
-tcg_gen_addi_i32(addr, addr, 4);
}
}
+
+tcg_temp_free(incr);
+tcg_temp_free(addr);
}
DISAS_INSN(bitop_im)
@@ -4029,7 +41
[Qemu-devel] [PATCH v2 4/5] target-m68k: Implement bitfield ops for registers
Signed-off-by: Richard Henderson
---
target-m68k/translate.c | 210
1 file changed, 210 insertions(+)
diff --git a/target-m68k/translate.c b/target-m68k/translate.c
index 1b3765f..be59c37 100644
--- a/target-m68k/translate.c
+++ b/target-m68k/translate.c
@@ -3085,6 +3085,210 @@ DISAS_INSN(shift_mem)
set_cc_op(s, CC_OP_FLAGS);
}
+DISAS_INSN(bfext_reg)
+{
+int ext = read_im16(env, s);
+int is_sign = insn & 0x200;
+TCGv src = DREG(insn, 0);
+TCGv dst = DREG(ext, 12);
+int len = ((extract32(ext, 0, 5) - 1) & 31) + 1;
+int ofs = extract32(ext, 6, 5); /* big bit-endian */
+int pos = 32 - ofs - len;/* little bit-endian */
+TCGv tmp = tcg_temp_new();
+TCGv shift;
+
+/* In general, we're going to rotate the field so that it's at the
+ top of the word and then right-shift by the compliment of the
+ width to extend the field. */
+if (ext & 0x20) {
+/* Variable width. */
+if (ext & 0x800) {
+/* Variable offset. */
+tcg_gen_andi_i32(tmp, DREG(ext, 6), 31);
+tcg_gen_rotl_i32(tmp, src, tmp);
+} else {
+tcg_gen_rotli_i32(tmp, src, ofs);
+}
+
+shift = tcg_temp_new();
+tcg_gen_neg_i32(shift, DREG(ext, 0));
+tcg_gen_andi_i32(shift, shift, 31);
+tcg_gen_sar_i32(QREG_CC_N, tmp, shift);
+if (is_sign) {
+tcg_gen_mov_i32(dst, QREG_CC_N);
+} else {
+tcg_gen_shr_i32(dst, tmp, shift);
+}
+tcg_temp_free(shift);
+} else {
+/* Immediate width. */
+if (ext & 0x800) {
+/* Variable offset */
+tcg_gen_andi_i32(tmp, DREG(ext, 6), 31);
+tcg_gen_rotl_i32(tmp, src, tmp);
+src = tmp;
+pos = 32 - len;
+} else {
+/* Immediate offset. If the field doesn't wrap around the
+ end of the word, rely on (s)extract completely. */
+if (pos < 0) {
+tcg_gen_rotli_i32(tmp, src, ofs);
+src = tmp;
+pos = 32 - len;
+}
+}
+
+tcg_gen_sextract_i32(QREG_CC_N, src, pos, len);
+if (is_sign) {
+tcg_gen_mov_i32(dst, QREG_CC_N);
+} else {
+tcg_gen_extract_i32(dst, src, pos, len);
+}
+}
+
+tcg_temp_free(tmp);
+set_cc_op(s, CC_OP_LOGIC);
+}
+
+DISAS_INSN(bfop_reg)
+{
+int ext = read_im16(env, s);
+TCGv src = DREG(insn, 0);
+int len = ((extract32(ext, 0, 5) - 1) & 31) + 1;
+int ofs = extract32(ext, 6, 5); /* big bit-endian */
+TCGv mask;
+
+if ((ext & 0x820) == 0) {
+/* Immediate width and offset. */
+uint32_t maski = 0x7fffu >> (len - 1);
+if (ofs + len <= 32) {
+tcg_gen_shli_i32(QREG_CC_N, src, ofs);
+} else {
+tcg_gen_rotli_i32(QREG_CC_N, src, ofs);
+}
+tcg_gen_andi_i32(QREG_CC_N, QREG_CC_N, ~maski);
+mask = tcg_const_i32(ror32(maski, ofs));
+} else {
+TCGv tmp = tcg_temp_new();
+if (ext & 0x20) {
+/* Variable width */
+tcg_gen_subi_i32(tmp, DREG(ext, 0), 1);
+tcg_gen_andi_i32(tmp, tmp, 31);
+mask = tcg_const_i32(0x7fffu);
+tcg_gen_shr_i32(mask, mask, tmp);
+} else {
+/* Immediate width */
+mask = tcg_const_i32(0x7fffu >> (len - 1));
+}
+if (ext & 0x800) {
+/* Variable offset */
+tcg_gen_andi_i32(tmp, DREG(ext, 6), 31);
+tcg_gen_rotl_i32(QREG_CC_N, src, tmp);
+tcg_gen_andc_i32(QREG_CC_N, QREG_CC_N, mask);
+tcg_gen_rotr_i32(mask, mask, tmp);
+} else {
+/* Immediate offset (and variable width) */
+tcg_gen_rotli_i32(QREG_CC_N, src, ofs);
+tcg_gen_andc_i32(QREG_CC_N, QREG_CC_N, mask);
+tcg_gen_rotri_i32(mask, mask, ofs);
+}
+tcg_temp_free(tmp);
+}
+set_cc_op(s, CC_OP_LOGIC);
+
+switch (insn & 0x0f00) {
+case 0x0a00: /* bfchg */
+tcg_gen_eqv_i32(src, src, mask);
+break;
+case 0x0c00: /* bfclr */
+tcg_gen_and_i32(src, src, mask);
+break;
+case 0x0e00: /* bfset */
+tcg_gen_orc_i32(src, src, mask);
+break;
+case 0x0800: /* bftst */
+/* flags already set; no other work to do. */
+break;
+default:
+g_assert_not_reached();
+}
+tcg_temp_free(mask);
+}
+
+DISAS_INSN(bfins_reg)
+{
+int ext = read_im16(env, s);
+TCGv dst = DREG(insn, 0);
+TCGv src = DREG(ext, 12);
+int len = ((extract32(ext, 0, 5) - 1) & 31) + 1;
+int ofs = extract32(ext, 6, 5); /* big bit-endian */
+int pos = 32 - ofs - len;/* little bit-endian */
+TCGv tmp;
+
+tmp = tcg_temp_new();
+
+if (ext & 0x20) {
+/* Variable width */
+
[Qemu-devel] [PULL for-2.8 0/2] usb: two memory leak fixes.
Hi, Here is the usb patch queue, fixing two memory leaks. please pull, Gerd The following changes since commit 207faf24c58859f5240f66bf6decc33b87a1776e: Merge remote-tracking branch 'pm215/tags/pull-target-arm-20161107' into staging (2016-11-07 14:02:15 +) are available in the git repository at: git://git.kraxel.org/qemu tags/pull-usb-20161109-1 for you to fetch changes up to f0bf4999eae156142a86290fda45de4094e3e8b4: usbredir: free vm_change_state_handler in usbredir destroy dispatch (2016-11-08 15:01:23 +0100) usb: two memory leak fixes. Li Qiang (2): usb: ehci: fix memory leak in ehci_init_transfer usbredir: free vm_change_state_handler in usbredir destroy dispatch hw/usb/hcd-ehci.c | 1 + hw/usb/redirect.c | 5 - 2 files changed, 5 insertions(+), 1 deletion(-)
Re: [Qemu-devel] [Qemu-block] [PATCH for-2.8] block: Let write zeroes fallback work even with small max_transfer
On Tue, Nov 08, 2016 at 04:52:15PM -0600, Eric Blake wrote: > Commit 443668ca rewrote the write_zeroes logic to guarantee that > an unaligned request never crosses a cluster boundary. But > in the rewrite, the new code assumed that at most one iteration > would be needed to get to an alignment boundary. > > However, it is easy to trigger an assertion failure: the Linux > kernel limits loopback devices to advertise a max_transfer of > only 64k. Any operation that requires falling back to writes > rather than more efficient zeroing must obey max_transfer during > that fallback, which means an unaligned head may require multiple > iterations of the write fallbacks before reaching the aligned > boundaries, when layering a format with clusters larger than 64k > atop the protocol of file access to a loopback device. > > Test case: > > $ qemu-img create -f qcow2 -o cluster_size=1M file 10M > $ losetup /dev/loop2 /path/to/file > $ qemu-io -f qcow2 /dev/loop2 > qemu-io> w 7m 1k > qemu-io> w -z 8003584 2093056 Please include a qemu-iotests test case to protect against regressions. Thanks, Stefan signature.asc Description: PGP signature
[Qemu-devel] [PATCH v2 5/5] target-m68k: Implement bitfield ops for memory
Signed-off-by: Richard Henderson
---
target-m68k/cpu.h | 1 +
target-m68k/helper.h| 7 ++
target-m68k/op_helper.c | 185
target-m68k/translate.c | 142 -
4 files changed, 333 insertions(+), 2 deletions(-)
diff --git a/target-m68k/cpu.h b/target-m68k/cpu.h
index 7c119ba..0b63c0a 100644
--- a/target-m68k/cpu.h
+++ b/target-m68k/cpu.h
@@ -37,6 +37,7 @@
#define OS_DOUBLE 4
#define OS_EXTENDED 5
#define OS_PACKED 6
+#define OS_UNSIZED 7
#define MAX_QREGS 32
diff --git a/target-m68k/helper.h b/target-m68k/helper.h
index cae5bcb..301b7d1 100644
--- a/target-m68k/helper.h
+++ b/target-m68k/helper.h
@@ -77,3 +77,10 @@ DEF_HELPER_2(flush_flags, void, env, i32)
DEF_HELPER_2(set_ccr, void, env, i32)
DEF_HELPER_FLAGS_1(get_ccr, TCG_CALL_NO_WG_SE, i32, env)
DEF_HELPER_2(raise_exception, void, env, i32)
+
+DEF_HELPER_FLAGS_4(bfexts_mem, TCG_CALL_NO_WG, i32, env, i32, s32, i32)
+DEF_HELPER_FLAGS_4(bfextu_mem, TCG_CALL_NO_WG, i64, env, i32, s32, i32)
+DEF_HELPER_FLAGS_5(bfins_mem, TCG_CALL_NO_WG, i32, env, i32, i32, s32, i32)
+DEF_HELPER_FLAGS_4(bfchg_mem, TCG_CALL_NO_WG, i32, env, i32, s32, i32)
+DEF_HELPER_FLAGS_4(bfclr_mem, TCG_CALL_NO_WG, i32, env, i32, s32, i32)
+DEF_HELPER_FLAGS_4(bfset_mem, TCG_CALL_NO_WG, i32, env, i32, s32, i32)
diff --git a/target-m68k/op_helper.c b/target-m68k/op_helper.c
index a4bfa4e..77d1f58 100644
--- a/target-m68k/op_helper.c
+++ b/target-m68k/op_helper.c
@@ -359,3 +359,188 @@ void HELPER(divsll)(CPUM68KState *env, int numr, int
regr, int32_t den)
env->dregs[regr] = rem;
env->dregs[numr] = quot;
}
+
+struct bf_data {
+uint32_t addr;
+uint32_t bofs;
+uint32_t blen;
+uint32_t len;
+};
+
+static struct bf_data bf_prep(uint32_t addr, int32_t ofs, uint32_t len)
+{
+int bofs, blen;
+
+/* Bound length; map 0 to 32. */
+len = ((len - 1) & 31) + 1;
+
+/* Note that ofs is signed. */
+addr += ofs / 8;
+bofs = ofs % 8;
+if (bofs < 0) {
+bofs += 8;
+addr -= 1;
+}
+
+/* Compute the number of bytes required (minus one) to
+ satisfy the bitfield. */
+blen = (bofs + len - 1) / 8;
+
+/* Canonicalize the bit offset for data loaded into a 64-bit big-endian
+ word. For the cases where BLEN is not a power of 2, adjust ADDR so
+ that we can use the next power of two sized load without crossing a
+ page boundary, unless the field itself crosses the boundary. */
+switch (blen) {
+case 0:
+bofs += 56;
+break;
+case 1:
+bofs += 48;
+break;
+case 2:
+if (addr & 1) {
+bofs += 8;
+addr -= 1;
+}
+/* fallthru */
+case 3:
+bofs += 32;
+break;
+case 4:
+if (addr & 3) {
+bofs += 8 * (addr & 3);
+addr &= -4;
+}
+break;
+default:
+g_assert_not_reached();
+}
+
+return (struct bf_data){
+.addr = addr,
+.bofs = bofs,
+.blen = blen,
+.len = len,
+};
+}
+
+static uint64_t bf_load(CPUM68KState *env, uint32_t addr, int blen,
+uintptr_t ra)
+{
+switch (blen) {
+case 0:
+return cpu_ldub_data_ra(env, addr, ra);
+case 1:
+return cpu_lduw_data_ra(env, addr, ra);
+case 2:
+case 3:
+return cpu_ldl_data_ra(env, addr, ra);
+case 4:
+return cpu_ldq_data_ra(env, addr, ra);
+default:
+g_assert_not_reached();
+}
+}
+
+static void bf_store(CPUM68KState *env, uint32_t addr, int blen,
+ uint64_t data, uintptr_t ra)
+{
+switch (blen) {
+case 0:
+cpu_stb_data_ra(env, addr, data, ra);
+break;
+case 1:
+cpu_stw_data_ra(env, addr, data, ra);
+break;
+case 2:
+case 3:
+cpu_stl_data_ra(env, addr, data, ra);
+break;
+case 4:
+cpu_stq_data_ra(env, addr, data, ra);
+break;
+default:
+g_assert_not_reached();
+}
+}
+
+uint32_t HELPER(bfexts_mem)(CPUM68KState *env, uint32_t addr,
+int32_t ofs, uint32_t len)
+{
+uintptr_t ra = GETPC();
+struct bf_data d = bf_prep(addr, ofs, len);
+uint64_t data = bf_load(env, d.addr, d.blen, ra);
+
+return (int64_t)(data << d.bofs) >> (64 - len);
+}
+
+uint64_t HELPER(bfextu_mem)(CPUM68KState *env, uint32_t addr,
+int32_t ofs, uint32_t len)
+{
+uintptr_t ra = GETPC();
+struct bf_data d = bf_prep(addr, ofs, len);
+uint64_t data = bf_load(env, d.addr, d.blen, ra);
+
+/* Put CC_N at the top of the high word; put the zero-extended value
+ at the bottom of the low word. */
+data <<= d.bofs;
+data >>= 64 - d.len;
+data |= data << (64 - d.len);
+
+return data;
+}
+
+uint32_t HELPER(bfins_mem)(CPUM68KState *env, uint32_t addr, uint32_t val,
+
[Qemu-devel] [PULL 1/2] usb: ehci: fix memory leak in ehci_init_transfer
From: Li Qiang
In ehci_init_transfer function, if the 'cpage' is bigger than 4,
it doesn't free the 'p->sgl' once allocated previously thus leading
a memory leak issue. This patch avoid this.
Signed-off-by: Li Qiang
Message-id: 5821c0f4.091c6b0a.e0c92.e...@mx.google.com
Signed-off-by: Gerd Hoffmann
---
hw/usb/hcd-ehci.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/hw/usb/hcd-ehci.c b/hw/usb/hcd-ehci.c
index f4ece9a..7622a3a 100644
--- a/hw/usb/hcd-ehci.c
+++ b/hw/usb/hcd-ehci.c
@@ -1190,6 +1190,7 @@ static int ehci_init_transfer(EHCIPacket *p)
while (bytes > 0) {
if (cpage > 4) {
fprintf(stderr, "cpage out of range (%d)\n", cpage);
+qemu_sglist_destroy(&p->sgl);
return -1;
}
--
1.8.3.1
[Qemu-devel] [PULL 2/2] usbredir: free vm_change_state_handler in usbredir destroy dispatch
From: Li Qiang
In usbredir destroy dispatch function, it doesn't free the vm change
state handler once registered in usbredir_realize function. This will
lead a memory leak issue. This patch avoid this.
Signed-off-by: Li Qiang
Reviewed-by: Marc-André Lureau
Message-id: 58216976.d0236b0a.77b99.b...@mx.google.com
Signed-off-by: Gerd Hoffmann
---
hw/usb/redirect.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/hw/usb/redirect.c b/hw/usb/redirect.c
index 528081e..a657237 100644
--- a/hw/usb/redirect.c
+++ b/hw/usb/redirect.c
@@ -132,6 +132,7 @@ struct USBRedirDevice {
struct usbredirfilter_rule *filter_rules;
int filter_rules_count;
int compatible_speedmask;
+VMChangeStateEntry *vmstate;
};
#define TYPE_USB_REDIR "usb-redir"
@@ -1411,7 +1412,8 @@ static void usbredir_realize(USBDevice *udev, Error
**errp)
usbredir_chardev_read, usbredir_chardev_event,
dev, NULL, true);
-qemu_add_vm_change_state_handler(usbredir_vm_state_change, dev);
+dev->vmstate =
+qemu_add_vm_change_state_handler(usbredir_vm_state_change, dev);
}
static void usbredir_cleanup_device_queues(USBRedirDevice *dev)
@@ -1450,6 +1452,7 @@ static void usbredir_handle_destroy(USBDevice *udev)
}
free(dev->filter_rules);
+qemu_del_vm_change_state_handler(dev->vmstate);
}
static int usbredir_check_filter(USBRedirDevice *dev)
--
1.8.3.1
Re: [Qemu-devel] [PATCH] test-replication: fix leaks
On Wed, Nov 09, 2016 at 02:45:47PM +0400, Marc-André Lureau wrote: > ASAN spotted: > SUMMARY: AddressSanitizer: 301990288 byte(s) leaked in 33 allocation(s). > > Signed-off-by: Marc-André Lureau > --- > tests/test-replication.c | 3 +++ > 1 file changed, 3 insertions(+) Thanks, applied to my block tree: https://github.com/stefanha/qemu/commits/block Stefan signature.asc Description: PGP signature
Re: [Qemu-devel] [PATCH v6 00/10] Convert msix_init() to error
On 11/05/2016 04:07 AM, Cao jin wrote: v6 changelog: 1. re-spin vfio-pci related code on patch 3: for -ENOTSUP, report & free Error, for other error, propagate the Error. (Marcel) CC: Jiri Pirko CC: Gerd Hoffmann CC: Dmitry Fleytman CC: Jason Wang CC: Michael S. Tsirkin CC: Hannes Reinecke CC: Paolo Bonzini CC: Alex Williamson CC: Markus Armbruster CC: Marcel Apfelbaum Cao jin (10): msix: Follow CODING_STYLE hcd-xhci: check & correct param before using it pci: Convert msix_init() to Error and fix callers to check it megasas: change behaviour of msix switch hcd-xhci: change behaviour of msix switch megasas: remove unnecessary megasas_use_msix() megasas: undo the overwrites of msi user configuration vmxnet3: fix reference leak issue vmxnet3: remove unnecessary internal msix flag msi_init: convert assert to return -errno hw/block/nvme.c| 5 +++- hw/misc/ivshmem.c | 8 +++--- hw/net/e1000e.c| 6 - hw/net/rocker/rocker.c | 7 - hw/net/vmxnet3.c | 46 ++-- hw/pci/msi.c | 9 --- hw/pci/msix.c | 42 - hw/scsi/megasas.c | 49 +++--- hw/usb/hcd-xhci.c | 71 ++ hw/vfio/pci.c | 8 -- hw/virtio/virtio-pci.c | 11 include/hw/pci/msix.h | 5 ++-- 12 files changed, 165 insertions(+), 102 deletions(-) Acked-by: Marcel Apfelbaum Thanks, Marcel
Re: [Qemu-devel] [PATCH 0/2] Current Travis patches
On Wed, Nov 09, 2016 at 12:11:55PM +, Alex Bennée wrote: > Hi, > > Not much here but since Daniel sped up the build by trimming out most > of the clang mirrors of gcc I added one additional clang build which > uses the current stable branch. Hopefully this still gives us enough > coverage. > > As this speeds up testing on merges and doesn't affect QEMU code > itself I'll ask if we can merge this in the 2.8 cycle? If so I'll send > a pull request in a few days assuming no objection to the patches > themselves. > > Alex Bennée (1): > travis: add Trusty with clang stable build > > Daniel P. Berrange (1): > travis: trim out most clang builds > > .travis.yml | 24 +++- > 1 file changed, 23 insertions(+), 1 deletion(-) Despite .travis.yml not affecting the QEMU binary I want to stick to the "bug fixes only" soft freeze policy for the 2.8 release. Please queue it for 2.9. Stefan signature.asc Description: PGP signature
Re: [Qemu-devel] [PATCH V5] docs: add PCIe devices placement guidelines
On 11/01/2016 03:39 PM, Marcel Apfelbaum wrote: Proposes best practices on how to use PCI Express/PCI device in PCI Express based machines and explain the reasoning behind them. Hi Michael, Can you please apply this doc for 2.8 ? Thanks, Marcel Reviewed-by: Laszlo Ersek Signed-off-by: Marcel Apfelbaum --- Hi, v4->v5: - Addressed Laine's comments: - Advertize (slot,chassis) parameters as mandatory - Stated the Downstream ports are not hot-pluggable - Other minor typos v3->v4: - Addressed minor typos spotted by Laszlo, thanks! v2->v3: - Addressed the comments from Andrea Bolognani and Laszlo Ersek, which are much appreciated! - Added links to presentations that may help the understanding of the document. RFC->v2: - Addressed a lot of comments from the reviewers (many thanks to all, especially to Laszlo) Thanks, Marcel docs/pcie.txt | 311 ++ 1 file changed, 311 insertions(+) create mode 100644 docs/pcie.txt diff --git a/docs/pcie.txt b/docs/pcie.txt new file mode 100644 index 000..1d9bd18 --- /dev/null +++ b/docs/pcie.txt @@ -0,0 +1,311 @@ +PCI EXPRESS GUIDELINES +== + +1. Introduction + +The doc proposes best practices on how to use PCI Express/PCI device +in PCI Express based machines and explains the reasoning behind them. + +The following presentations accompany this document: + (1) Q35 overview. + http://wiki.qemu.org/images/4/4e/Q35.pdf + (2) A comparison between PCI and PCI Express technologies. + http://wiki.qemu.org/images/f/f6/PCIvsPCIe.pdf + +Note: The usage examples are not intended to replace the full +documentation, please use QEMU help to retrieve all options. + +2. Device placement strategy + +QEMU does not have a clear socket-device matching mechanism +and allows any PCI/PCI Express device to be plugged into any +PCI/PCI Express slot. +Plugging a PCI device into a PCI Express slot might not always work and +is weird anyway since it cannot be done for "bare metal". +Plugging a PCI Express device into a PCI slot will hide the Extended +Configuration Space thus is also not recommended. + +The recommendation is to separate the PCI Express and PCI hierarchies. +PCI Express devices should be plugged only into PCI Express Root Ports and +PCI Express Downstream ports. + +2.1 Root Bus (pcie.0) += +Place only the following kinds of devices directly on the Root Complex: +(1) PCI Devices (e.g. network card, graphics card, IDE controller), +not controllers. Place only legacy PCI devices on +the Root Complex. These will be considered Integrated Endpoints. +Note: Integrated Endpoints are not hot-pluggable. + +Although the PCI Express spec does not forbid PCI Express devices as +Integrated Endpoints, existing hardware mostly integrates legacy PCI +devices with the Root Complex. Guest OSes are suspected to behave +strangely when PCI Express devices are integrated +with the Root Complex. + +(2) PCI Express Root Ports (ioh3420), for starting exclusively PCI Express +hierarchies. + +(3) DMI-PCI Bridges (i82801b11-bridge), for starting legacy PCI +hierarchies. + +(4) Extra Root Complexes (pxb-pcie), if multiple PCI Express Root Buses +are needed. + + pcie.0 bus + +||| | + --- -- -- -- + | PCI Dev | | PCIe Root Port | | DMI-PCI Bridge | | pxb-pcie | + --- -- -- -- + +2.1.1 To plug a device into pcie.0 as a Root Complex Integrated Endpoint use: + -device [,bus=pcie.0] +2.1.2 To expose a new PCI Express Root Bus use: + -device pxb-pcie,id=pcie.1,bus_nr=x[,numa_node=y][,addr=z] + Only PCI Express Root Ports and DMI-PCI bridges can be connected + to the pcie.1 bus: + -device ioh3420,id=root_port1[,bus=pcie.1][,chassis=x][,slot=y][,addr=z] \ + -device i82801b11-bridge,id=dmi_pci_bridge1,bus=pcie.1 + + +2.2 PCI Express only hierarchy +== +Always use PCI Express Root Ports to start PCI Express hierarchies. + +A PCI Express Root bus supports up to 32 devices. Since each +PCI Express Root Port is a function and a multi-function +device may support up to 8 functions, the maximum possible +number of PCI Express Root Ports per PCI Express Root Bus is 256. + +Prefer grouping PCI Express Root Ports into multi-function devices +to keep a simple flat hierarchy that is enough for most scenarios. +Only use PCI Express Switches (x3130-upstream, xio3130-downstream) +if there is no more room for PCI Express Root Ports. +Please see section 4. for further justificati
Re: [Qemu-devel] virsh dump (qemu guest memory dump?): KASLR enabled linux guest support
- Original Message - > Hi, > > Latest linux kernel enabled kaslr to randomiz phys/virt memory > addresses, we had some effort to support kexec/kdump so that crash > utility can still works in case crashed kernel has kaslr enabled. > > But according to Dave Anderson virsh dump does not work, quoted messages > from Dave below: > > """ > with virsh dump, there's no way of even knowing that KASLR > has randomized the kernel __START_KERNEL_map region, because there is no > virtual address information -- e.g., like "SYMBOL(_stext)" in the kdump > vmcoreinfo data to compare against the vmlinux file symbol value. > Unless virsh dump can export some basic virtual memory data, which > they say it can't, I don't see how KASLR can ever be supported. > """ We also need the x86_64 phys_base value. As it is right now, virsh dump vmcores work by luck. It is presumed that the __START_KERNEL_map region is unmodified (i.e., what's in the vmlinux file), and the phys_base value is guessed by checking phys_base values from -16MB to +16MB in 1MB chunks. If the phys_base value is not one of those 32 possible values, the crash session will fail. Dave > > I assume virsh dump is using qemu guest memory dump facility so it > should be first addressed in qemu. Thus post this query to qemu devel > list. If this is not correct please let me know. > > Could you qemu dump people make it work? Or we can not support virt dump > as long as KASLR being enabled. Latest Fedora kernel has enabled it in > x86_64. > > Thanks > Dave >
Re: [Qemu-devel] [PATCH v2 0/5] target-m68k-patches
Le 09/11/2016 à 14:46, Richard Henderson a écrit : > Changes since v1: > * Tweaked local variable decls for movem. > * Fixed the bitfield patches such that they work with linux-user-test-0.3. > (Along with the whole passle of extra patches required to make that work.) > > The register bitfield patch still depends on the patches posted > here in another thread implementing extract and sextract. > > > r~ > > > Laurent Vivier (1): > target-m68k: Implement 680x0 movem > > Richard Henderson (4): > target-m68k: Do not cpu_abort on undefined insns > target-m68k: Inline shifts > target-m68k: Implement bitfield ops for registers > target-m68k: Implement bitfield ops for memory > > target-m68k/cpu.h | 1 + > target-m68k/helper.c| 52 > target-m68k/helper.h| 10 +- > target-m68k/op_helper.c | 185 + > target-m68k/translate.c | 702 > > 5 files changed, 843 insertions(+), 107 deletions(-) > It seems I have always a segfault when I start a container. I'm going to try to understand what happens. Thanks, Laurent
Re: [Qemu-devel] virsh dump (qemu guest memory dump?): KASLR enabled linux guest support
- Original Message - > On 11/09/16 at 11:58am, Wen Congyang wrote: > > On 11/09/2016 11:17 AM, Dave Young wrote: > > > Drop qiaonuohan, seems the mail address is wrong.. > > > > > > On 11/09/16 at 11:01am, Dave Young wrote: > > >> Hi, > > >> > > >> Latest linux kernel enabled kaslr to randomiz phys/virt memory > > >> addresses, we had some effort to support kexec/kdump so that crash > > >> utility can still works in case crashed kernel has kaslr enabled. > > >> > > >> But according to Dave Anderson virsh dump does not work, quoted messages > > >> from Dave below: > > >> > > >> """ > > >> with virsh dump, there's no way of even knowing that KASLR > > >> has randomized the kernel __START_KERNEL_map region, because there is no > > >> virtual address information -- e.g., like "SYMBOL(_stext)" in the kdump > > >> vmcoreinfo data to compare against the vmlinux file symbol value. > > >> Unless virsh dump can export some basic virtual memory data, which > > >> they say it can't, I don't see how KASLR can ever be supported. > > >> """ > > >> > > >> I assume virsh dump is using qemu guest memory dump facility so it > > >> should be first addressed in qemu. Thus post this query to qemu devel > > >> list. If this is not correct please let me know. > > > > IIRC, 'virsh dump --memory-only' uses dump-guest-memory, and 'virsh dump' > > uses migration to dump. > > Do they need different fixes? Dave, I guess you mean --memory-only, but > could you clarify and confirm it? As I understand it, the "--memory-only" option uses a new "dump-guest-memory" QEMU monitor command that creates an ELF kdump vmcore clone. Dave > > > > > I think I should study kaslr first... > > Thanks for taking care of it. > > > > > Thanks > > Wen Congyang > > > > >> > > >> Could you qemu dump people make it work? Or we can not support virt dump > > >> as long as KASLR being enabled. Latest Fedora kernel has enabled it in > > >> x86_64. > > >> > > >> Thanks > > >> Dave > > > > > > > > > > > > > > > >
[Qemu-devel] [PULL 2/3] hw/input/hid: support alternative sysrq/break scancodes for gtk-vnc
From: Peter Korsgaard
The printscreen/sysrq and pause/break keys currently don't work for guests
using -usbdevice keyboard when accessed through vnc with a gtk-vnc based
client.
The reason for this is a mismatch between gtk-vnc and qemu in how these keys
should be mapped to XT keycodes.
On the original IBM XT these keys behaved differently than other keys.
Quoting from https://www.win.tue.nl/~aeb/linux/kbd/scancodes-1.html:
The keys PrtSc/SysRq and Pause/Break are special. The former produces
scancode e0 2a e0 37 when no modifier key is pressed simultaneously, e0 37
together with Shift or Ctrl, but 54 together with (left or right) Alt. (And
one gets the expected sequences upon release. But see below.) The latter
produces scancode sequence e1 1d 45 e1 9d c5 when pressed (without modifier)
and nothing at all upon release. However, together with (left or right)
Ctrl, one gets e0 46 e0 c6, and again nothing at release. It does not
repeat.
Gtk-vnc supports the 'QEMU Extended Key Event Message' RFB extension to send
raw XT keycodes directly to qemu, but the specification doesn't explicitly
specify how to map such long/complicated keycode sequences. From the spec
(https://github.com/rfbproto/rfbproto/blob/master/rfbproto.rst#qemu-extended-key-event-message)
The keycode is the XT keycode that produced the keysym. An XT keycode is an
XT make scancode sequence encoded to fit in a single U32 quantity. Single
byte XT scancodes with a byte value less than 0x7f are encoded as is.
2-byte XT scancodes whose first byte is 0xe0 and second byte is less than
0x7f are encoded with the high bit of the first byte set
hid.c currently expects the keycode sequence with shift/ctl for sysrq (e0 37
-> 0xb7 in RFB), whereas gtk-vnc uses the sequence with alt (0x54).
Likewise, hid.c expects the code without modifiers (e1 1d 45 -> 0xc5 in
RFB), whereas gtk-vnc sends the keycode sequence with ctrl for pause (e0 46
-> 0xc6 in RFB).
See keymaps.cvs in gtk-vnc for the mapping used:
https://git.gnome.org/browse/gtk-vnc/tree/src/keymaps.csv#n150
Now, it isn't obvious to me which sequence is really "right", but as the
0x54/0xc6 keycodes are currently unused in hid.c, supporting both seems like
the pragmatic solution to me. The USB HID keyboard boot protocol used by
hid.c doesn't have any other mapping applicable to these keys.
The other guest keyboard interfaces (ps/2, virtio, ..) are not affected,
because they handle these keys differently.
Signed-off-by: Peter Korsgaard
Message-id: 20161028145132.1702-1-pe...@korsgaard.com
Signed-off-by: Gerd Hoffmann
---
hw/input/hid.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/input/hid.c b/hw/input/hid.c
index 5e2850e..fa9cc4c 100644
--- a/hw/input/hid.c
+++ b/hw/input/hid.c
@@ -46,7 +46,7 @@ static const uint8_t hid_usage_keys[0x100] = {
0xe2, 0x2c, 0x39, 0x3a, 0x3b, 0x3c, 0x3d, 0x3e,
0x3f, 0x40, 0x41, 0x42, 0x43, 0x53, 0x47, 0x5f,
0x60, 0x61, 0x56, 0x5c, 0x5d, 0x5e, 0x57, 0x59,
-0x5a, 0x5b, 0x62, 0x63, 0x00, 0x00, 0x64, 0x44,
+0x5a, 0x5b, 0x62, 0x63, 0x46, 0x00, 0x64, 0x44,
0x45, 0x68, 0x69, 0x6a, 0x6b, 0x6c, 0x6d, 0x6e,
0xe8, 0xe9, 0x71, 0x72, 0x73, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x85, 0x00, 0x00, 0x00, 0x00,
@@ -61,7 +61,7 @@ static const uint8_t hid_usage_keys[0x100] = {
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x54, 0x00, 0x46,
0xe6, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
-0x00, 0x00, 0x00, 0x00, 0x00, 0x48, 0x00, 0x4a,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x48, 0x48, 0x4a,
0x52, 0x4b, 0x00, 0x50, 0x00, 0x4f, 0x00, 0x4d,
0x51, 0x4e, 0x49, 0x4c, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0xe3, 0xe7, 0x65, 0x00, 0x00,
--
1.8.3.1
[Qemu-devel] [PULL 3/3] Fix cursesw detection
From: Samuel Thibault
On systems which do not provide ncursesw.pc and whose /usr/include/curses.h
does not include wide support, we should not only try with no -I, i.e.
/usr/include, but also with -I/usr/include/ncursesw.
To properly detect for wide support with and without -Werror, we need to
check for the presence of e.g. the WACS_DEGREE macro.
We also want to stop at the first curses_inc_list configuration which works,
and make sure to set IFS to : at each new loop.
Signed-off-by: Samuel Thibault
Tested-by: Cornelia Huck
Message-id: 20161109102752.13255-1-samuel.thiba...@ens-lyon.org
Signed-off-by: Gerd Hoffmann
---
configure | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/configure b/configure
index fd6f898..7d2a34e 100755
--- a/configure
+++ b/configure
@@ -2926,7 +2926,7 @@ if test "$curses" != "no" ; then
curses_inc_list="$($pkg_config --cflags ncurses 2>/dev/null):"
curses_lib_list="$($pkg_config --libs ncurses 2>/dev/null):-lpdcurses"
else
-curses_inc_list="$($pkg_config --cflags ncursesw 2>/dev/null):"
+curses_inc_list="$($pkg_config --cflags ncursesw
2>/dev/null):-I/usr/include/ncursesw:"
curses_lib_list="$($pkg_config --libs ncursesw
2>/dev/null):-lncursesw:-lcursesw"
fi
curses_found=no
@@ -2941,11 +2941,13 @@ int main(void) {
resize_term(0, 0);
addwstr(L"wide chars\n");
addnwstr(&wch, 1);
+ add_wch(WACS_DEGREE);
return s != 0;
}
EOF
IFS=:
for curses_inc in $curses_inc_list; do
+IFS=:
for curses_lib in $curses_lib_list; do
unset IFS
if compile_prog "$curses_inc" "$curses_lib" ; then
@@ -2955,6 +2957,9 @@ EOF
break
fi
done
+if test "$curses_found" = yes ; then
+ break
+fi
done
unset IFS
if test "$curses_found" = "yes" ; then
--
1.8.3.1
[Qemu-devel] [PULL for-2.8 0/3] ui: bugfixes for gtk, curses and hid emulation.
Hi, Here is the UI patch queue with three bugfixes, most importantly the cursesw configure fix. please pull, Gerd The following changes since commit 207faf24c58859f5240f66bf6decc33b87a1776e: Merge remote-tracking branch 'pm215/tags/pull-target-arm-20161107' into staging (2016-11-07 14:02:15 +) are available in the git repository at: git://git.kraxel.org/qemu tags/pull-ui-20161109-1 for you to fetch changes up to ba60f2d18e976ef99238ebce019e26719f2b597c: Fix cursesw detection (2016-11-09 14:35:47 +0100) ui: bugfixes for gtk, curses and hid emulation. Peter Korsgaard (1): hw/input/hid: support alternative sysrq/break scancodes for gtk-vnc Samuel Thibault (1): Fix cursesw detection Thomas Huth (1): ui/gtk: Fix build with older versions of gtk configure | 7 ++- hw/input/hid.c | 4 ++-- ui/gtk.c | 3 ++- 3 files changed, 10 insertions(+), 4 deletions(-)
[Qemu-devel] [PATCH v6 04/19] tcg: rename tcg_current_cpu to tcg_current_rr_cpu
..and make the definition local to cpus. In preparation for MTTCG the
concept of a global tcg_current_cpu will no longer make sense. However
we still need to keep track of it in the single-threaded case to be able
to exit quickly when required.
qemu_cpu_kick_no_halt() moves and becomes qemu_cpu_kick_rr_cpu() to
emphasise its use-case. qemu_cpu_kick now kicks the relevant cpu as
well as qemu_kick_rr_cpu() which will become a no-op in MTTCG.
For the time being the setting of the global exit_request remains.
Signed-off-by: Alex Bennée
Reviewed-by: Richard Henderson
---
v4:
- keep global exit_request setting for now
- fix merge conflicts
v5:
- merge conflicts with kick changes
---
cpu-exec-common.c | 1 -
cpu-exec.c | 3 ---
cpus.c | 41 ++---
include/exec/exec-all.h | 1 -
4 files changed, 22 insertions(+), 24 deletions(-)
diff --git a/cpu-exec-common.c b/cpu-exec-common.c
index 767d9c6..e2bc053 100644
--- a/cpu-exec-common.c
+++ b/cpu-exec-common.c
@@ -24,7 +24,6 @@
#include "exec/memory-internal.h"
bool exit_request;
-CPUState *tcg_current_cpu;
/* exit the current TB, but without causing any exception to be raised */
void cpu_loop_exit_noexc(CPUState *cpu)
diff --git a/cpu-exec.c b/cpu-exec.c
index 4188fed..49191b5 100644
--- a/cpu-exec.c
+++ b/cpu-exec.c
@@ -605,7 +605,6 @@ int cpu_exec(CPUState *cpu)
return EXCP_HALTED;
}
-atomic_mb_set(&tcg_current_cpu, cpu);
rcu_read_lock();
if (unlikely(atomic_mb_read(&exit_request))) {
@@ -664,7 +663,5 @@ int cpu_exec(CPUState *cpu)
/* fail safe : never use current_cpu outside cpu_exec() */
current_cpu = NULL;
-/* Does not need atomic_mb_set because a spurious wakeup is okay. */
-atomic_set(&tcg_current_cpu, NULL);
return ret;
}
diff --git a/cpus.c b/cpus.c
index b3bf7b8..485c2e7 100644
--- a/cpus.c
+++ b/cpus.c
@@ -748,8 +748,7 @@ void configure_icount(QemuOpts *opts, Error **errp)
*/
static QEMUTimer *tcg_kick_vcpu_timer;
-
-static void qemu_cpu_kick_no_halt(void);
+static CPUState *tcg_current_rr_cpu;
#define TCG_KICK_PERIOD (NANOSECONDS_PER_SECOND / 10)
@@ -758,10 +757,23 @@ static inline int64_t qemu_tcg_next_kick(void)
return qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) + TCG_KICK_PERIOD;
}
+/* Kick the currently round-robin scheduled vCPU */
+static void qemu_cpu_kick_rr_cpu(void)
+{
+CPUState *cpu;
+atomic_mb_set(&exit_request, 1);
+do {
+cpu = atomic_mb_read(&tcg_current_rr_cpu);
+if (cpu) {
+cpu_exit(cpu);
+}
+} while (cpu != atomic_mb_read(&tcg_current_rr_cpu));
+}
+
static void kick_tcg_thread(void *opaque)
{
timer_mod(tcg_kick_vcpu_timer, qemu_tcg_next_kick());
-qemu_cpu_kick_no_halt();
+qemu_cpu_kick_rr_cpu();
}
static void start_tcg_kick_timer(void)
@@ -780,7 +792,6 @@ static void stop_tcg_kick_timer(void)
}
}
-
/***/
void hw_error(const char *fmt, ...)
{
@@ -1291,6 +1302,7 @@ static void *qemu_tcg_cpu_thread_fn(void *arg)
}
for (; cpu != NULL && !exit_request; cpu = CPU_NEXT(cpu)) {
+atomic_mb_set(&tcg_current_rr_cpu, cpu);
qemu_clock_enable(QEMU_CLOCK_VIRTUAL,
(cpu->singlestep_enabled & SSTEP_NOTIMER) == 0);
@@ -1310,6 +1322,8 @@ static void *qemu_tcg_cpu_thread_fn(void *arg)
}
} /* for cpu.. */
+/* Does not need atomic_mb_set because a spurious wakeup is okay. */
+atomic_set(&tcg_current_rr_cpu, NULL);
/* Pairs with smp_wmb in qemu_cpu_kick. */
atomic_mb_set(&exit_request, 0);
@@ -1342,24 +1356,13 @@ static void qemu_cpu_kick_thread(CPUState *cpu)
#endif
}
-static void qemu_cpu_kick_no_halt(void)
-{
-CPUState *cpu;
-/* Ensure whatever caused the exit has reached the CPU threads before
- * writing exit_request.
- */
-atomic_mb_set(&exit_request, 1);
-cpu = atomic_mb_read(&tcg_current_cpu);
-if (cpu) {
-cpu_exit(cpu);
-}
-}
-
void qemu_cpu_kick(CPUState *cpu)
{
qemu_cond_broadcast(cpu->halt_cond);
if (tcg_enabled()) {
-qemu_cpu_kick_no_halt();
+cpu_exit(cpu);
+/* Also ensure current RR cpu is kicked */
+qemu_cpu_kick_rr_cpu();
} else {
qemu_cpu_kick_thread(cpu);
}
@@ -1400,7 +1403,7 @@ void qemu_mutex_lock_iothread(void)
atomic_dec(&iothread_requesting_mutex);
} else {
if (qemu_mutex_trylock(&qemu_global_mutex)) {
-qemu_cpu_kick_no_halt();
+qemu_cpu_kick_rr_cpu();
qemu_mutex_lock(&qemu_global_mutex);
}
atomic_dec(&iothread_requesting_mutex);
diff --git a/include/exec/exec-all.h b/include/exec/exec-all.h
index a8c13ce..5a1b3a3 100644
--- a/include/exec/exec-all.h
+++ b/include/exec/exec-all.h
@@ -406,7 +406,6 @@ bool memory_region_is_un
[Qemu-devel] [PULL 1/3] ui/gtk: Fix build with older versions of gtk
From: Thomas Huth GDK_KEY_Delete is only defined with gtk version 2.22 and newer, on older versions this key was called GDK_Delete instead. Since this is the case for all GDK_KEY_* defines, change the already existing preprocessor check there to test for version 2.22, so we know that we can remove this code block in case we require that version as a minimum one day. Signed-off-by: Thomas Huth Reviewed-by: Daniel P. Berrange Message-id: 1478081328-25515-1-git-send-email-th...@redhat.com Signed-off-by: Gerd Hoffmann --- ui/gtk.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/ui/gtk.c b/ui/gtk.c index ca737c4..e816428 100644 --- a/ui/gtk.c +++ b/ui/gtk.c @@ -94,7 +94,7 @@ #define GDK_IS_WIN32_DISPLAY(dpy) (dpy == dpy) #endif -#ifndef GDK_KEY_0 +#if !GTK_CHECK_VERSION(2, 22, 0) #define GDK_KEY_0 GDK_0 #define GDK_KEY_1 GDK_1 #define GDK_KEY_2 GDK_2 @@ -104,6 +104,7 @@ #define GDK_KEY_plus GDK_plus #define GDK_KEY_minus GDK_minus #define GDK_KEY_Pause GDK_Pause +#define GDK_KEY_Delete GDK_Delete #endif /* Some older mingw versions lack this constant or have -- 1.8.3.1
Re: [Qemu-devel] virsh dump (qemu guest memory dump?): KASLR enabled linux guest support
On Wed, Nov 09, 2016 at 09:36:08AM -0500, Dave Anderson wrote: > > > - Original Message - > > On 11/09/16 at 11:58am, Wen Congyang wrote: > > > On 11/09/2016 11:17 AM, Dave Young wrote: > > > > Drop qiaonuohan, seems the mail address is wrong.. > > > > > > > > On 11/09/16 at 11:01am, Dave Young wrote: > > > >> Hi, > > > >> > > > >> Latest linux kernel enabled kaslr to randomiz phys/virt memory > > > >> addresses, we had some effort to support kexec/kdump so that crash > > > >> utility can still works in case crashed kernel has kaslr enabled. > > > >> > > > >> But according to Dave Anderson virsh dump does not work, quoted > > > >> messages > > > >> from Dave below: > > > >> > > > >> """ > > > >> with virsh dump, there's no way of even knowing that KASLR > > > >> has randomized the kernel __START_KERNEL_map region, because there is > > > >> no > > > >> virtual address information -- e.g., like "SYMBOL(_stext)" in the kdump > > > >> vmcoreinfo data to compare against the vmlinux file symbol value. > > > >> Unless virsh dump can export some basic virtual memory data, which > > > >> they say it can't, I don't see how KASLR can ever be supported. > > > >> """ > > > >> > > > >> I assume virsh dump is using qemu guest memory dump facility so it > > > >> should be first addressed in qemu. Thus post this query to qemu devel > > > >> list. If this is not correct please let me know. > > > > > > IIRC, 'virsh dump --memory-only' uses dump-guest-memory, and 'virsh dump' > > > uses migration to dump. > > > > Do they need different fixes? Dave, I guess you mean --memory-only, but > > could you clarify and confirm it? > > As I understand it, the "--memory-only" option uses a new "dump-guest-memory" > QEMU monitor command that creates an ELF kdump vmcore clone. IIRC, the use of the traditional 'virsh dump' (which just splats out the QEMU migration data stream) is no longer supported with crash and everyone should be using the --memory-only flag to ensure the ELF format core. IOW, I think we can just ignore the historical migration based dump and focus exclusively on the dump-guest-memory based impl. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o-http://search.cpan.org/~danberr/ :|
[Qemu-devel] [PATCH v6 09/19] tcg: handle EXCP_ATOMIC exception for system emulation
From: Pranith Kumar
The patch enables handling atomic code in the guest. This should be
preferably done in cpu_handle_exception(), but the current assumptions
regarding when we can execute atomic sections cause a deadlock.
Signed-off-by: Pranith Kumar
[AJB: tweak title]
Signed-off-by: Alex Bennée
---
cpus.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/cpus.c b/cpus.c
index b8d8b87..1ebe518 100644
--- a/cpus.c
+++ b/cpus.c
@@ -1315,6 +1315,11 @@ static void *qemu_tcg_rr_cpu_thread_fn(void *arg)
if (r == EXCP_DEBUG) {
cpu_handle_guest_debug(cpu);
break;
+} else if (r == EXCP_ATOMIC) {
+qemu_mutex_unlock_iothread();
+cpu_exec_step_atomic(cpu);
+qemu_mutex_lock_iothread();
+break;
}
} else if (cpu->stop) {
if (cpu->unplug) {
@@ -1385,6 +1390,10 @@ static void *qemu_tcg_cpu_thread_fn(void *arg)
*/
g_assert(cpu->halted);
break;
+case EXCP_ATOMIC:
+qemu_mutex_unlock_iothread();
+cpu_exec_step_atomic(cpu);
+qemu_mutex_lock_iothread();
default:
/* Ignore everything else? */
break;
--
2.10.1
[Qemu-devel] [PATCH v6 00/19] Remaining MTTCG Base patches and ARM enablement
Hi, A chunk of the MTTCG work was merged for 2.8 so this constitutes what is left for the next cycle. The changes are minor except for a new patch to reduce BQL contention on ARM during yield/wfi instructions. I've also taken the time to update the design document which now covers all the solutions for the various design requirements in the document. The one outstanding question is how to deal with the TLB flush semantics of the various guest architectures. Currently flushes to other vCPUs will happen at the end of their currently executing Translation Block which could mean the originating vCPU makes assumptions about flushes having been completed when they haven't. In practice this hasn't been a problem and I haven't been able to construct a test case so far that would fail in such a case. This is probably because most tear downs of the other vCPU TLBs tend to be done while the other vCPUs are not doing much. If anyone can come up with a test case that would fail if this assumption isn't met then please let me know. We already have all the tools to meet these requirements if we want by scheduling safe async work however this might slow things down if these sort of flushes are frequent. These patches apply cleanly on top of the current master. Please review the code and I look forward to seeing other architectures enable MTTCG on top of this series. Alex Bennée (15): docs: new design document multi-thread-tcg.txt tcg: add kick timer for single-threaded vCPU emulation tcg: rename tcg_current_cpu to tcg_current_rr_cpu tcg: remove global exit_request tcg: enable tb_lock() for SoftMMU tcg: enable thread-per-vCPU cputlb: add assert_cpu_is_self checks cputlb: tweak qemu_ram_addr_from_host_nofail reporting cputlb: atomically update tlb fields used by tlb_reset_dirty target-arm/powerctl: defer cpu reset work to CPU context target-arm/cpu: don't reset TLB structures, use cputlb to do it target-arm: ensure BQL taken for ARM_CP_IO register access target-arm: helpers which may affect global state need the BQL target-arm: don't generate WFE/YIELD calls for MTTCG tcg: enable MTTCG by default for ARM on x86 hosts Jan Kiszka (1): tcg: drop global lock during TCG code execution KONRAD Frederic (2): tcg: add options for enabling MTTCG cputlb: introduce tlb_flush_* async work. Pranith Kumar (1): tcg: handle EXCP_ATOMIC exception for system emulation configure | 12 ++ cpu-exec-common.c | 3 - cpu-exec.c | 37 ++-- cpus.c | 314 cputlb.c| 386 +++- default-configs/arm-softmmu.mak | 2 + docs/multi-thread-tcg.txt | 343 +++ exec.c | 12 +- hw/core/irq.c | 1 + hw/i386/kvmvapic.c | 4 +- hw/intc/arm_gicv3_cpuif.c | 3 + hw/ppc/spapr.c | 3 + include/exec/cputlb.h | 2 - include/exec/exec-all.h | 5 +- include/qom/cpu.h | 16 ++ include/sysemu/cpus.h | 2 + memory.c| 2 + qemu-options.hx | 20 +++ qom/cpu.c | 10 ++ target-arm/arm-powerctl.c | 144 +-- target-arm/cpu.c| 6 + target-arm/helper.c | 6 + target-arm/op_helper.c | 50 +- target-arm/translate-a64.c | 8 +- target-arm/translate.c | 20 ++- target-i386/smm_helper.c| 7 + target-s390x/misc_helper.c | 5 +- translate-all.c | 27 ++- translate-common.c | 21 +-- vl.c| 49 - 30 files changed, 1241 insertions(+), 279 deletions(-) create mode 100644 docs/multi-thread-tcg.txt -- 2.10.1
