Re: [Qemu-devel] [RFC PATCH v4 2/5] ramlist mutex
On 08/17/2011 02:28 AM, Paolo Bonzini wrote:
On 08/16/2011 08:56 PM, Umesh Deshpande wrote:
@@ -3001,8 +3016,10 @@ void qemu_ram_free_from_ptr(ram_addr_t addr)
QLIST_FOREACH(block,ram_list.blocks, next) {
if (addr == block-offset) {
+qemu_mutex_lock_ramlist();
QLIST_REMOVE(block, next);
QLIST_REMOVE(block, next_mru);
+qemu_mutex_unlock_ramlist();
qemu_free(block);
return;
}
@@ -3015,8 +3032,10 @@ void qemu_ram_free(ram_addr_t addr)
QLIST_FOREACH(block,ram_list.blocks, next) {
if (addr == block-offset) {
+qemu_mutex_lock_ramlist();
QLIST_REMOVE(block, next);
QLIST_REMOVE(block, next_mru);
+qemu_mutex_unlock_ramlist();
if (block-flags RAM_PREALLOC_MASK) {
;
} else if (mem_path) {
You must protect the whole QLIST_FOREACH. Otherwise looks good.
Or, is it okay to convert all the ramblock list traversals in exec.c
(under iothread) to mru traversals, and probably it makes sense as the
original list was also maintained in the mru order, whereas the sequence
of blocks doesn't matter for the migration code. This way we don't have
to acquire the mutex for block list traversals.
- Umesh
Re: [Qemu-devel] [RFC][PATCH 000/111] QEMU m68k core additions
Le 19/08/2011 04:14, Natalia Portillo a écrit : Hi, [...] (no need to quote the full thread!) He worked on emulating an abandoned, strange, difficult to get, and undocumented hardware, using your 111 patches, and finished it before the wholy more experienced MESS team. The next-cube emulation is really working ? Yes, it is, absolutely. Cool I need to add this target to my Haiku port... where are the docs for the boot process ? Why are you planning to port a hack instead of making a full machine emulation? Because I'm lazy and dumb: the work is already done, I like cut'n'paste. Yeah, you said it! The work is already done, we have all the hardware emulation that Basilisk substitutes for hacks. I'm not sure of that... no MMU emulation, no Nubus, no ethernet card, no video card, no SWIM, no SCSI, ... useless with a patched ROM. Macs do not have videocards :p, only the Mac II and we're not forced to emulate that one. SWIM is a piece of cake that can be even implemented without ICs, just some logical arrays. NuBus is not required for almost anything, only the video card uses it, and it's present only on the Mac II, a stub will suffice to make Toolbox be happy. Most m68k didn't include a network card, third party ones are stock chips (probably almost all are NE2000, 3COM and PCNET), and Apple integrated ones are also stock, easy to do :p NIC isn't really necessary at first, those things don't netboot anyway, do they ? The MMU is your part I won't discuss on it. There is 040 mmu support in ARAnyM (Atari Running on Any Machine), enough to run Linux, that has been backported to UAE (ARAnyM is based on the UAE core), that should give some hints: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=201442 http://www.amigaemulator.org/patches http://www.amigaemulator.org/bin/patches/mmu/uae-0.8.20.2-mmu.diff.gz (though I fixed a bug in handling TTR1 in ARAnyM) It's why I chose to go Falcon first and use ARAnyM for the 68k Haiku port. The 030 or 68551 ones are much more complex though (the 040 one has a fixed table layout, others have fully configurable table size for all the 4 levels). The 060 one is just the 040 with some cache restrictions. I know it's not perfect, but right now, it's better than nothing. There is no 68k cpu emulation complete afaik, I discussed with Ray Arachelian a lot on that when he was working on LisaEm. However emulators are live, Aranym, UAE, LisaEm, BasiliskII. qemu-m68k is quite complete to go live (when it does not break mcoldfire) right now. Bugs are easy to be corrected by more people when they are in main than in a developer's own clone. Leave your little kid go wild, it's old and big enough :p Release early, release often :p François.
[Qemu-devel] [PATCH] fix code format
Fix code format to make checkpatch.pl happy.
Signed-off-by: Robert Wang wdon...@linux.vnet.ibm.com
---
block.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/block.c b/block.c
index 26910ca..87e83bc 100644
--- a/block.c
+++ b/block.c
@@ -2251,9 +2251,9 @@ BlockDriverAIOCB *bdrv_aio_readv(BlockDriverState *bs,
int64_t sector_num,
cb, opaque);
if (ret) {
- /* Update stats even though technically transfer has not happened. */
- bs-rd_bytes += (unsigned) nb_sectors * BDRV_SECTOR_SIZE;
- bs-rd_ops ++;
+/* Update stats even though technically transfer has not happened. */
+bs-rd_bytes += (unsigned) nb_sectors * BDRV_SECTOR_SIZE;
+bs-rd_ops++;
}
return ret;
--
1.7.4.1
[Qemu-devel] Now, what's left to non-developers? (Qemu forum down again, No such list qemu-users)
Hello developers, users and other lurkers. For the last 5 years Pablo Virolainen has done a great job of hosting the qemu forum. I confess I don't use the forum every day, but every now and again the forum seems to be down. I have Pablo's personal email and whenever a problem arises I contact him and pretty soon the problem is fixed. I think that lately Pablo hasn't got much time or maybe he's on holidays. I wonder what the point is to have a fully functioning and well alive developers mailing list if common users like me, with little or no programming skills, have no place to exchange our ides. So, to summarise, at the moment of writing: 1) The qemu forum is down: http://qemu-forum.ipi.fi/ 2) The qemu-user mailing list is not active: http://lists.nongnu.org/mailman/listinfo/qemu-users Is anybody here interested in having an official place for qemu users? I would like to have a qemu-user list, as an official replacement for the qemu forum and I hope you want this too. Thank you for your attention and have a nice day -- Ottavio A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail?
[Qemu-devel] [Help]: How to setup a VM based on kernel source code.
HI, I have met one scenario; currently i want to set up a VM based on latest kernel tree; but i only have latest kernel source code and compiled it on one fedora 15 workstation. To achieve the objective, what actions should i take next step? use -kernel -initrd options? other ways? If you have this experience, pls give me one hand. thanks. -- Regards, Zhi Yong Wu
Re: [Qemu-devel] [PATCH -V4 01/26] coroutine: add gthread dependency
On Tue, Aug 9, 2011 at 01:03, Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com wrote: From: Stefan Hajnoczi stefa...@linux.vnet.ibm.com Commit 1fc7bd4a86a2bfeafcec29445871eb97469a2699 removed the gthread and gio dependency since qemu-ga did not require it. Coroutines require gthread, so add it back in. Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com --- configure | 18 -- 1 files changed, 8 insertions(+), 10 deletions(-) diff --git a/configure b/configure index 0c67a4a..a6687f7 100755 --- a/configure +++ b/configure @@ -1844,16 +1844,14 @@ fi ## # glib support probe -if test $guest_agent != no ; then Why did you remove this line? - if $pkg_config --modversion glib-2.0 /dev/null 21 ; then - glib_cflags=`$pkg_config --cflags glib-2.0 2/dev/null` - glib_libs=`$pkg_config --libs glib-2.0 2/dev/null` - libs_softmmu=$glib_libs $libs_softmmu - libs_tools=$glib_libs $libs_tools - else - echo glib-2.0 required to compile QEMU - exit 1 - fi +if $pkg_config --modversion gthread-2.0 /dev/null 21 ; then + glib_cflags=`$pkg_config --cflags gthread-2.0 2/dev/null` + glib_libs=`$pkg_config --libs gthread-2.0 2/dev/null` + libs_softmmu=$glib_libs $libs_softmmu + libs_tools=$glib_libs $libs_tools +else + echo glib-2.0 required to compile QEMU + exit 1 fi ## -- 1.7.4.1
Re: [Qemu-devel] [Help]: How to setup a VM based on kernel source code.
On Fri, Aug 19, 2011 at 10:58 AM, Zhi Yong Wu zwu.ker...@gmail.com wrote: I have met one scenario; currently i want to set up a VM based on latest kernel tree; but i only have latest kernel source code and compiled it on one fedora 15 workstation. To achieve the objective, what actions should i take next step? use -kernel -initrd options? other ways? You can build a kernel with all drivers (e.g. virtio-net, virtio-blk) compiled in and then boot using -kernel and -append. I find that simplest. Stefan
Re: [Qemu-devel] [PATCH 0/8] *** SUBJECT HERE ***
Bryce, please, run scripts/checkpatch.pl before submitting them to check the style. Then, IMHO, you can put all next-cube stuff in one patch (hw/next-* + Makefile.target), then make one patch by m68k feature/instruction added or m68k default corrected. And remember, to be able to bisect, each patch must be able to be compiled and run. Good Luck, Laurent Le 18 août 2011 à 00:09, Bryce Lanham blan...@gmail.com a écrit : *** BLURB HERE *** Bryce Lanham (8): added next source files to Makefile.target main next driver, needs a bit of cleanup next framebuffer driver, very basic, only supports running under 32 bit color at the moment next keyboard driver, only supports a subset of modifier keys partially working network driver, needs more comparison with real hardware before it can be made fully working adds SFC, DFC, MMU TC, access control register, and user stack pointer acces to movec_to/from added move16, cinva, pflush instructions, and disabled abort on execution of frestore/fsave added mmu tc, sfc, dfc, and access control registers to the cpu header Makefile.target | 2 + hw/next-cube.c | 471 +++ hw/next-fb.c | 102 ++ hw/next-fb.h | 14 ++ hw/next-kbd.c | 243 ++ hw/next-kbd.h | 2 + hw/next-net.c | 513 +++ hw/next-net.h | 2 + target-m68k/cpu.h | 12 +- target-m68k/helper.c | 44 - target-m68k/translate.c | 108 +- 11 files changed, 1491 insertions(+), 22 deletions(-) create mode 100644 hw/next-cube.c create mode 100644 hw/next-fb.c create mode 100644 hw/next-fb.h create mode 100644 hw/next-kbd.c create mode 100644 hw/next-kbd.h create mode 100644 hw/next-net.c create mode 100644 hw/next-net.h -- 1.7.2.3
Re: [Qemu-devel] Now, what's left to non-developers? (Qemu forum down again, No such list qemu-users)
On 19 August 2011 11:08, 陳韋任 che...@iis.sinica.edu.tw wrote: Hi, Ottavio 2) The qemu-user mailing list is not active: http://lists.nongnu.org/mailman/listinfo/qemu-users +1. Maybe you can ask Pablo's opinion, too. I don't understand. Do you mean Pablo's opinion about the mailing list or about the forum? About the forum, I have contacted him a few days ago reporting the incident and he answered that he would give it a look once he was in front of a computer (he was using a blackberry or a mobile phone to email, I think). I have sent him a couple of emails but no answer yet. And plus, I am quite sure he's subscribed to this list. I think that, regardless of the qemu forum, there is a base of qemu users which are not subscribed to this mailing list that would like to exchange ideas and ask for mutual support and for which the medium of a web forum is not stimulating enough. If anybody with admin rights could activate the qemu-users list this would be very beneficial to this project. I, for instance, have a lot of questions to ask but I wouldn't dare on this mailing list because my post wouldn't be interesting enough to developers. -- Ottavio A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail?
[Qemu-devel] [Bug 829455] [NEW] user mode network stack - hostfwd not working with restrict=y
Public bug reported: I find that explicit hostfwd commands do not seem to work with restrict=yes option, even if the docs clearly state that hostfwd should override restrict setting. I am using this config: -net user,name=test,net=192.168.100.0/24,host=192.168.100.44,restrict=y,hostfwd=tcp:127.0.0.1:3389-192.168.100.1:3389 (my guest has static IP address configured as 192.168.100.1/24) and I cannot log into my guest via rdp. the client hanging indefinitely. by just changing to restrict=no I can log in. maybe I am doing something wrong, but I cannot figure out what. running QEMU emulator version 0.14.0 (qemu-kvm-0.14.0) ** Affects: qemu Importance: Undecided Status: New ** Tags: hostfwd restrict -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/829455 Title: user mode network stack - hostfwd not working with restrict=y Status in QEMU: New Bug description: I find that explicit hostfwd commands do not seem to work with restrict=yes option, even if the docs clearly state that hostfwd should override restrict setting. I am using this config: -net user,name=test,net=192.168.100.0/24,host=192.168.100.44,restrict=y,hostfwd=tcp:127.0.0.1:3389-192.168.100.1:3389 (my guest has static IP address configured as 192.168.100.1/24) and I cannot log into my guest via rdp. the client hanging indefinitely. by just changing to restrict=no I can log in. maybe I am doing something wrong, but I cannot figure out what. running QEMU emulator version 0.14.0 (qemu-kvm-0.14.0) To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/829455/+subscriptions
Re: [Qemu-devel] [PATCH v2 5/6] vga: Use linear mapping + dirty logging in chain 4 memory access mode
On 08/18/2011 03:26 PM, Jan Kiszka wrote: On 2011-08-17 16:48, Avi Kivity wrote: On 08/17/2011 04:38 PM, Avi Kivity wrote: The mmio code has s-plane_updated |= mask; /* only used to detect font change */ aren't we losing it? we could easily recover it via dirty logging. Yes, I forgot to forward-port plane_updated = 0xf from v1 of the patch. We can't really recover it. I don't see yet why we should not if we simply enforce a full update. Can you elaborate? If we go for a full update we might as well disable dirty logging entirely. So I think we need to restrict the optimization to graphic mode. Is grub using text mode or graphic mode? If it's using text mode, it may be faster to compare the font plane to a snapshot from the last redraw than to take an exit. I wasn't optimizing for text mode here, it's just a side effect if it happens to benefit from it as well. I could exclude it, but only if really needed. Ok, so grub is using graphic mode? We'll need to force full updates in text mode then. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.
Re: [Qemu-devel] [PATCH] Wire g_new() and friends to the qemu_malloc() family
On 08/18/2011 09:54 PM, Peter Maydell wrote:
On 18 August 2011 18:48, Avi Kivitya...@redhat.com wrote:
+static GMemVTable gmemvtable = {
+.malloc = qemu_malloc,
+.realloc = qemu_realloc,
+.free = qemu_free,
+};
+
+/**
+ * qemu_malloc_init: initialize memory management
+ */
+void qemu_malloc_init(void)
+{
+g_mem_set_vtable(gmemvtable);
+}
Does this mean you can now safely allocate with g_malloc
and free with qemu_free, or is mixing the two APIs like that
still a no-no ?
You can, but I'd forbid it. Mixing layers can only lead to tears later on.
Best would be to convert qemu_malloc()s to g_new()s and g_malloc()s to
reduce confusion.
(I'm thinking about a situation where you might use a glib utility
function that returned g_malloc'd memory and want to pass that back
to your caller without having to either copy to qemu_malloc'd memory
or require your caller to care about the distinction.)
Changing ownership of memory is rare, I hope.
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
Re: [Qemu-devel] [PATCH] pci: add standard bridge device
On 08/18/2011 10:12 PM, Wen Congyang wrote: The following patch can fix this problem, but I'm not sure whether it is right. It's correct but insufficient, the filtering code (pci_bridge_filter) needs to be updated to use the memory API. I read the function pci_bridge_filter(), and the function only read PCI bridge's config space(command, base and limit). If base limit, it will set addr to PCI_BAR_UNMAPPED. I do not find anything that needs to updated to use the memory API. Currently it doesn't do any filtering at all. Bridges need to create a new address space, then attach aliases of this region (corresponding to the filtered area and to the legacy vga space) to the parent bus' address space. I add a scsi controller on pci bus1, and a scsi disk on this controller. I can read and write this disk, and I do not meet any problem. However, filtering doesn't work. You could put a BAR outside the filtered area and it would be visible to the guest. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.
Re: [Qemu-devel] [RFC][PATCH 000/111] QEMU m68k core additions
El 19/08/2011, a las 09:55, François Revol escribió: Le 19/08/2011 04:14, Natalia Portillo a écrit : Hi, [...] (no need to quote the full thread!) He worked on emulating an abandoned, strange, difficult to get, and undocumented hardware, using your 111 patches, and finished it before the wholy more experienced MESS team. The next-cube emulation is really working ? Yes, it is, absolutely. Cool I need to add this target to my Haiku port... where are the docs for the boot process ? NetBSD sources :D Why are you planning to port a hack instead of making a full machine emulation? Because I'm lazy and dumb: the work is already done, I like cut'n'paste. Yeah, you said it! The work is already done, we have all the hardware emulation that Basilisk substitutes for hacks. I'm not sure of that... no MMU emulation, no Nubus, no ethernet card, no video card, no SWIM, no SCSI, ... useless with a patched ROM. Macs do not have videocards :p, only the Mac II and we're not forced to emulate that one. SWIM is a piece of cake that can be even implemented without ICs, just some logical arrays. NuBus is not required for almost anything, only the video card uses it, and it's present only on the Mac II, a stub will suffice to make Toolbox be happy. Most m68k didn't include a network card, third party ones are stock chips (probably almost all are NE2000, 3COM and PCNET), and Apple integrated ones are also stock, easy to do :p NIC isn't really necessary at first, those things don't netboot anyway, do they ? AFAIK, none of them did until PowerPC, and that was OpenFirmware. The MMU is your part I won't discuss on it. There is 040 mmu support in ARAnyM (Atari Running on Any Machine), enough to run Linux, that has been backported to UAE (ARAnyM is based on the UAE core), that should give some hints: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=201442 http://www.amigaemulator.org/patches http://www.amigaemulator.org/bin/patches/mmu/uae-0.8.20.2-mmu.diff.gz (though I fixed a bug in handling TTR1 in ARAnyM) It's why I chose to go Falcon first and use ARAnyM for the 68k Haiku port. The 030 or 68551 ones are much more complex though (the 040 one has a fixed table layout, others have fully configurable table size for all the 4 levels). The 060 one is just the 040 with some cache restrictions. I know it's not perfect, but right now, it's better than nothing. There is no 68k cpu emulation complete afaik, I discussed with Ray Arachelian a lot on that when he was working on LisaEm. However emulators are live, Aranym, UAE, LisaEm, BasiliskII. qemu-m68k is quite complete to go live (when it does not break mcoldfire) right now. Bugs are easy to be corrected by more people when they are in main than in a developer's own clone. Leave your little kid go wild, it's old and big enough :p Release early, release often :p +1 François.
Re: [Qemu-devel] [RFC][PATCH 000/111] QEMU m68k core additions
Le 19 août 2011 à 17:52, Natalia Portillo clau...@claunia.com a écrit : El 19/08/2011, a las 09:55, François Revol escribió: [snip] Release early, release often :p +1Ok, Ok, I think all m68k core can be submitted except some bitfield operations and fpu instructions. Just need to know how Anthony and Paul want I proceed... Regards, Laurent
Re: [Qemu-devel] Multi-threaded user program support?
On 08/18/2011 08:13 PM, Peter Maydell wrote: On 19 August 2011 03:59, 陳韋任 che...@iis.sinica.edu.tw wrote: More generally and not x86-specific, there are problems with the multithreaded user-mode support which I suspect exist because nobody has ever sat down and worked out a coherent design for it, including what might need to be thread-local and what locking is required. So the result is that it mostly works but if you You mean some QEMU data structures need to be thread-local or lock protected in order to emulate guest multi-threaded program correctly? Approximately, yes (the third option being redesign the data structure so it can be sensibly protected). See https://bugs.launchpad.net/qemu/+bug/668799 for discussion of one example. I suspect that to make things tractable for i386, which has so many LOCKable instructions, that we'll also have to implement at least a compare-and-swap primitive in TCG. r~
Re: [Qemu-devel] Now, what's left to non-developers? (Qemu forum down again, No such list qemu-users)
On Fri, Aug 19, 2011 at 2:26 PM, Ottavio pr0f3ss0r1...@yahoo.com wrote: On 19 August 2011 11:08, 陳韋任 che...@iis.sinica.edu.tw wrote: Hi, Ottavio 2) The qemu-user mailing list is not active: http://lists.nongnu.org/mailman/listinfo/qemu-users +1. Maybe you can ask Pablo's opinion, too. I don't understand. Do you mean Pablo's opinion about the mailing list or about the forum? About the forum, I have contacted him a few days ago reporting the incident and he answered that he would give it a look once he was in front of a computer (he was using a blackberry or a mobile phone to email, I think). I have sent him a couple of emails but no answer yet. And plus, I am quite sure he's subscribed to this list. I think that, regardless of the qemu forum, there is a base of qemu users which are not subscribed to this mailing list that would like to exchange ideas and ask for mutual support and for which the medium of a web forum is not stimulating enough. If anybody with admin rights could activate the qemu-users list this would be very beneficial to this project. I, for instance, have a lot of questions to ask but I wouldn't dare on this mailing list because my post wouldn't be interesting enough to developers. Ottavio, User questions on this mailing list are not uncommon. I think your questions and discussions are welcome. However, I understand that following a mailing list that has high traffic and mostly contains patches is not ideal. It does make sense to bring the qemu users list back to life. Anthony may have mailing list admin access, he is CCed. Stefan
[Qemu-devel] [PATCH 2/3] spice-core: client_migrate_info: add optional auto_switch parameter (RHBZ 725009)
Add an extra optional boolean parameter defaulting to true called auto_switch,
if auto_switch is true the client is requested to switch to the target qemu
upon migration completion. Only implemented for spice, ignored for vnc.
Signed-off-by: Alon Levy al...@redhat.com
---
hmp-commands.hx |6 +++---
monitor.c |4 +++-
qmp-commands.hx |5 +++--
ui/qemu-spice.h |2 +-
ui/spice-core.c | 14 --
5 files changed, 22 insertions(+), 9 deletions(-)
diff --git a/hmp-commands.hx b/hmp-commands.hx
index 0ccfb28..fc2bf99 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -823,15 +823,15 @@ ETEXI
{
.name = client_migrate_info,
-.args_type =
protocol:s,hostname:s,port:i?,tls-port:i?,cert-subject:s?,
-.params = protocol hostname port tls-port cert-subject,
+.args_type =
protocol:s,hostname:s,port:i?,tls-port:i?,cert-subject:s?,auto-switch:b?,
+.params = protocol hostname port tls-port cert-subject
auto-switch,
.help = send migration info to spice/vnc client,
.user_print = monitor_user_noop,
.mhandler.cmd_new = client_migrate_info,
},
STEXI
-@item client_migrate_info @var{protocol} @var{hostname} @var{port}
@var{tls-port} @var{cert-subject}
+@item client_migrate_info @var{protocol} @var{hostname} @var{port}
@var{tls-port} @var{cert-subject} @var{auto-switch}
@findex client_migrate_info
Set the spice/vnc connection info for the migration target. The spice/vnc
server will ask the spice/vnc client to automatically reconnect using the
diff --git a/monitor.c b/monitor.c
index baf46ba..1daa283 100644
--- a/monitor.c
+++ b/monitor.c
@@ -1226,6 +1226,7 @@ static int client_migrate_info(Monitor *mon, const QDict
*qdict, QObject **ret_d
const char *subject = qdict_get_try_str(qdict, cert-subject);
int port = qdict_get_try_int(qdict, port, -1);
int tls_port = qdict_get_try_int(qdict, tls-port, -1);
+int auto_switch = qdict_get_try_bool(qdict, auto-switch, 1);
int ret;
if (strcmp(protocol, spice) == 0) {
@@ -1234,7 +1235,8 @@ static int client_migrate_info(Monitor *mon, const QDict
*qdict, QObject **ret_d
return -1;
}
-ret = qemu_spice_migrate_info(hostname, port, tls_port, subject);
+ret = qemu_spice_migrate_info(hostname, port, tls_port,
+ subject, auto_switch);
if (ret != 0) {
qerror_report(QERR_UNDEFINED_ERROR);
return -1;
diff --git a/qmp-commands.hx b/qmp-commands.hx
index 03f67da..13b2bc6 100644
--- a/qmp-commands.hx
+++ b/qmp-commands.hx
@@ -574,8 +574,8 @@ EQMP
{
.name = client_migrate_info,
-.args_type =
protocol:s,hostname:s,port:i?,tls-port:i?,cert-subject:s?,
-.params = protocol hostname port tls-port cert-subject,
+.args_type =
protocol:s,hostname:s,port:i?,tls-port:i?,cert-subject:s?,auto-switch:b?,
+.params = protocol hostname port tls-port cert-subject
auto-switch,
.help = send migration info to spice/vnc client,
.user_print = monitor_user_noop,
.mhandler.cmd_new = client_migrate_info,
@@ -596,6 +596,7 @@ Arguments:
- port: spice/vnc tcp port for plaintext channels (json-int,
optional)
- tls-port: spice tcp port for tls-secured channels (json-int, optional)
- cert-subject: server certificate subject (json-string, optional)
+- auto-switch: automatically switch when migration is done (json-bool,
optional)
Example:
diff --git a/ui/qemu-spice.h b/ui/qemu-spice.h
index f34be69..e54f16e 100644
--- a/ui/qemu-spice.h
+++ b/ui/qemu-spice.h
@@ -37,7 +37,7 @@ int qemu_spice_set_passwd(const char *passwd,
bool fail_if_connected, bool
disconnect_if_connected);
int qemu_spice_set_pw_expire(time_t expires);
int qemu_spice_migrate_info(const char *hostname, int port, int tls_port,
-const char *subject);
+const char *subject, int auto_switch);
void do_info_spice_print(Monitor *mon, const QObject *data);
void do_info_spice(Monitor *mon, QObject **ret_data);
diff --git a/ui/spice-core.c b/ui/spice-core.c
index 8bb62ea..3a1d851 100644
--- a/ui/spice-core.c
+++ b/ui/spice-core.c
@@ -42,6 +42,14 @@ static Notifier migration_state;
static const char *auth = spice;
static char *auth_passwd;
static time_t auth_expires = TIME_MAX;
+
+/* automatically switch host when migration is complete.
+ * This is on by default but we turn it off to address RHBZ #725009
+ * The longer term solution should be seamless migration by reconnecting
+ * on migration start instead of end, but that requires a harder change to
+ * all spice clients. */
+static int g_auto_switch = 1;
+
int using_spice = 0;
struct SpiceTimer {
@@ -428,7 +436,7 @@ static void migration_state_notifier(Notifier *notifier,
void *data)
{
int
[Qemu-devel] [PATCH 1/3] monitor: refactor whitespace and optional argument parsing
Takes out the optional ('?') message parsing from the main switch loop
in monitor_parse_command. Adds optional argument option for boolean parameters.
Signed-off-by: Alon Levy al...@redhat.com
---
monitor.c | 79 +++-
1 files changed, 30 insertions(+), 49 deletions(-)
diff --git a/monitor.c b/monitor.c
index 6e3d970..baf46ba 100644
--- a/monitor.c
+++ b/monitor.c
@@ -4122,6 +4122,29 @@ static const mon_cmd_t *monitor_parse_command(Monitor
*mon,
break;
c = *typestr;
typestr++;
+while (qemu_isspace(*p)) {
+p++;
+}
+/* take care of optional arguments */
+switch (c) {
+case 's':
+case 'i':
+case 'l':
+case 'M':
+case 'o':
+case 'T':
+case 'b':
+if (*typestr == '?') {
+typestr++;
+if (*p == '\0') {
+/* missing optional argument: NULL argument */
+qemu_free(key);
+key = NULL;
+continue;
+}
+}
+break;
+}
switch(c) {
case 'F':
case 'B':
@@ -4129,15 +4152,6 @@ static const mon_cmd_t *monitor_parse_command(Monitor
*mon,
{
int ret;
-while (qemu_isspace(*p))
-p++;
-if (*typestr == '?') {
-typestr++;
-if (*p == '\0') {
-/* no optional string: NULL argument */
-break;
-}
-}
ret = get_str(buf, sizeof(buf), p);
if (ret 0) {
switch(c) {
@@ -4167,9 +4181,6 @@ static const mon_cmd_t *monitor_parse_command(Monitor
*mon,
if (!opts_list || opts_list-desc-name) {
goto bad_type;
}
-while (qemu_isspace(*p)) {
-p++;
-}
if (!*p)
break;
if (get_str(buf, sizeof(buf), p) 0) {
@@ -4187,8 +4198,6 @@ static const mon_cmd_t *monitor_parse_command(Monitor
*mon,
{
int count, format, size;
-while (qemu_isspace(*p))
-p++;
if (*p == '/') {
/* format found */
p++;
@@ -4268,23 +4277,15 @@ static const mon_cmd_t *monitor_parse_command(Monitor
*mon,
{
int64_t val;
-while (qemu_isspace(*p))
-p++;
-if (*typestr == '?' || *typestr == '.') {
-if (*typestr == '?') {
-if (*p == '\0') {
-typestr++;
-break;
-}
-} else {
-if (*p == '.') {
+if (*typestr == '.') {
+if (*p == '.') {
+p++;
+while (qemu_isspace(*p)) {
p++;
-while (qemu_isspace(*p))
-p++;
-} else {
-typestr++;
-break;
}
+} else {
+typestr++;
+break;
}
typestr++;
}
@@ -4306,15 +4307,6 @@ static const mon_cmd_t *monitor_parse_command(Monitor
*mon,
int64_t val;
char *end;
-while (qemu_isspace(*p)) {
-p++;
-}
-if (*typestr == '?') {
-typestr++;
-if (*p == '\0') {
-break;
-}
-}
val = strtosz(p, end);
if (val 0) {
monitor_printf(mon, invalid size\n);
@@ -4328,14 +4320,6 @@ static const mon_cmd_t *monitor_parse_command(Monitor
*mon,
{
double val;
-while (qemu_isspace(*p))
-p++;
-if (*typestr == '?') {
-typestr++;
-if (*p == '\0') {
-break;
-}
-}
if (get_double(mon, val, p) 0) {
goto fail;
}
@@ -4361,9 +4345,6 @@ static const mon_cmd_t *monitor_parse_command(Monitor
*mon,
const char *beg;
int val;
-while (qemu_isspace(*p)) {
-p++;
-}
beg = p;
while (qemu_isgraph(*p)) {
p++;
--
1.7.6
[Qemu-devel] [PATCH 3/3] monitor: add client_migrate_switch command (RHBZ 725009)
Complementary to the auto_switch parameter of client_migrate_info, if that is
set to false the new command client_migrate_switch can be used to complete
the switch to the new client. This allows the vm manager (i.e. libvirt) to
first ensure the ticketing information in the target vm is valid before issuing
the switch.
Signed-off-by: Alon Levy al...@redhat.com
---
hmp-commands.hx | 15 +++
monitor.c | 23 +++
qmp-commands.hx | 27 +++
ui/qemu-spice.h |5 +
ui/spice-core.c |4
5 files changed, 74 insertions(+), 0 deletions(-)
diff --git a/hmp-commands.hx b/hmp-commands.hx
index fc2bf99..7979529 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -839,6 +839,21 @@ new parameters (if specified) once the vm migration
finished successfully.
ETEXI
{
+.name = client_migrate_switch,
+.args_type = protocol:s,
+.params = protocol,
+.help = tell client to disconnect and reconnect to
client_migrate_info set destination,
+.user_print = monitor_user_noop,
+.mhandler.cmd_new = client_migrate_switch,
+},
+
+STEXI
+@item client_migrate_switch @var{protocol}
+@findex client_migrate_switch
+Tell the spice/vnc client to switch to the target set previously with
client_migrate_info. Only has an effect if the last client_migrate_info used
auto_switch=false.
+ETEXI
+
+{
.name = snapshot_blkdev,
.args_type = device:B,snapshot-file:s?,format:s?,
.params = device [new-image-file] [format],
diff --git a/monitor.c b/monitor.c
index 1daa283..ae6f4ad 100644
--- a/monitor.c
+++ b/monitor.c
@@ -1248,6 +1248,29 @@ static int client_migrate_info(Monitor *mon, const QDict
*qdict, QObject **ret_d
return -1;
}
+static int client_migrate_switch(Monitor *mon, const QDict *qdict,
+ QObject **ret_data)
+{
+const char *protocol = qdict_get_str(qdict, protocol);
+int ret;
+
+if (strcmp(protocol, spice) == 0) {
+if (!using_spice) {
+qerror_report(QERR_DEVICE_NOT_ACTIVE, spice);
+return -1;
+}
+ret = qemu_spice_migrate_switch();
+if (ret != 0) {
+qerror_report(QERR_UNDEFINED_ERROR);
+return -1;
+}
+return 0;
+}
+
+qerror_report(QERR_INVALID_PARAMETER, protocol);
+return -1;
+}
+
static int do_screen_dump(Monitor *mon, const QDict *qdict, QObject **ret_data)
{
vga_hw_screen_dump(qdict_get_str(qdict, filename));
diff --git a/qmp-commands.hx b/qmp-commands.hx
index 13b2bc6..9e0fecf 100644
--- a/qmp-commands.hx
+++ b/qmp-commands.hx
@@ -609,6 +609,33 @@ Example:
EQMP
{
+.name = client_migrate_switch,
+.args_type = protocol:s,
+.params = protocol,
+.help = tell client to disconnect and reconnect to
client_migrate_info set destination,
+.user_print = monitor_user_noop,
+.mhandler.cmd_new = client_migrate_switch,
+},
+
+SQMP
+client_migrate_switch
+-
+
+Tell the spice/vnc client to switch to the target set previously with
client_migrate_info. Only has an effect if the last client_migrate_info used
auto_switch=false.
+
+Arguments:
+
+- protocol: protocol: spice or vnc (json-string)
+
+Example:
+
+- { execute: client_migrate_switch,
+ arguments: { protocol: spice } }
+- { return: {} }
+
+EQMP
+
+{
.name = netdev_add,
.args_type = netdev:O,
.params = [user|tap|socket],id=str[,prop=value][,...],
diff --git a/ui/qemu-spice.h b/ui/qemu-spice.h
index e54f16e..113bd2f 100644
--- a/ui/qemu-spice.h
+++ b/ui/qemu-spice.h
@@ -38,6 +38,7 @@ int qemu_spice_set_passwd(const char *passwd,
int qemu_spice_set_pw_expire(time_t expires);
int qemu_spice_migrate_info(const char *hostname, int port, int tls_port,
const char *subject, int auto_switch);
+int qemu_spice_migrate_switch(void);
void do_info_spice_print(Monitor *mon, const QObject *data);
void do_info_spice(Monitor *mon, QObject **ret_data);
@@ -60,6 +61,10 @@ static inline int qemu_spice_set_pw_expire(time_t expires)
static inline int qemu_spice_migrate_info(const char *h, int p, int t, const
char *s)
{ return -1; }
+static inline int qemu_spice_migrate_switch(void)
+{ return -1; }
+
+
#endif /* CONFIG_SPICE */
#endif /* QEMU_SPICE_H */
diff --git a/ui/spice-core.c b/ui/spice-core.c
index 3a1d851..83362c2 100644
--- a/ui/spice-core.c
+++ b/ui/spice-core.c
@@ -451,6 +451,10 @@ int qemu_spice_migrate_info(const char *hostname, int
port, int tls_port,
port, tls_port, subject);
}
+int qemu_spice_migrate_switch(void)
+{
+return spice_server_migrate_switch(spice_server);
+}
static int add_channel(const char *name, const char *value, void *opaque)
{
--
1.7.6
Re: [Qemu-devel] [SeaBIOS] [PATCH V6 1/9] Add an implementation of a TPM TIS driver
On Wed, Aug 10, 2011 at 10:51 AM, Stefan Berger stef...@linux.vnet.ibm.com wrote: This patch adds an implementation of a TPM TIS driver for the TPM TIS emulation supported by Qemu (patches posted, not in git yet). Usage of the driver is broken up into several functions. The driver is cleanly separated from the rest of the code through an interface holding pointers to the driver's functions. A client using this driver first probes whether the TPM TIS interface is available (probe function) and then invokes the interface function to initialze the interface and send requests and receive responses. Possible future extensions *could* include a virtio interface for the TPM with a corresponding driver here. v6: - reworked timeouts; not hardcoded anymore v5: - introducing a configurable threashold as part of the driver interface structure below which the TPM is used for calculating the sha1 v2: - adapted tpm_drivers.c to be under LGPLv3 Signed-off-by: Stefan Berger stef...@linux.vnet.ibm.com Hi Stefan, Please excuse my TPM ignorance, but is the emulation of a specific hardware device or has the TCG defined the registers etc for TPM hardware? Marc -- http://se-eng.com
Re: [Qemu-devel] [SeaBIOS] [PATCH V6 1/9] Add an implementation of a TPM TIS driver
On 08/19/2011 01:33 PM, Marc Jones wrote: On Wed, Aug 10, 2011 at 10:51 AM, Stefan Berger stef...@linux.vnet.ibm.com wrote: This patch adds an implementation of a TPM TIS driver for the TPM TIS emulation supported by Qemu (patches posted, not in git yet). Usage of the driver is broken up into several functions. The driver is cleanly separated from the rest of the code through an interface holding pointers to the driver's functions. A client using this driver first probes whether the TPM TIS interface is available (probe function) and then invokes the interface function to initialze the interface and send requests and receive responses. Possible future extensions *could* include a virtio interface for the TPM with a corresponding driver here. v6: - reworked timeouts; not hardcoded anymore v5: - introducing a configurable threashold as part of the driver interface structure below which the TPM is used for calculating the sha1 v2: - adapted tpm_drivers.c to be under LGPLv3 Signed-off-by: Stefan Bergerstef...@linux.vnet.ibm.com Hi Stefan, Please excuse my TPM ignorance, but is the emulation of a specific hardware device or has the TCG defined the registers etc for TPM hardware? Qemu patches provide the emulation of the specific hardware device that TCG (trusted comp. group) has defined the registers for. SeaBIOS implements a driver for it. Stefan
[Qemu-devel] [Bug 826363] Re: qemu-img convert does not work with vdi files
Sorry to be a pain, but now I get $ configure --disable-guest-agent Error: zlib check failed Make sure to have the zlib libs and headers installed. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/826363 Title: qemu-img convert does not work with vdi files Status in QEMU: New Bug description: qemu-img.exe convert -O raw myfile.vdi zz.raw reports 'error while writing' both in 0.15.0 and Beta rc2 v0.11.1 works fine on same file. myfile.vdi is 3.9GB made by VirtualBox. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/826363/+subscriptions
Re: [Qemu-devel] Now, what's left to non-developers? (Qemu forum down again, No such list qemu-users)
On 08/19/2011 11:28 AM, Stefan Hajnoczi wrote: On Fri, Aug 19, 2011 at 2:26 PM, Ottaviopr0f3ss0r1...@yahoo.com wrote: On 19 August 2011 11:08, 陳韋任che...@iis.sinica.edu.tw wrote: Hi, Ottavio 2) The qemu-user mailing list is not active: http://lists.nongnu.org/mailman/listinfo/qemu-users +1. Maybe you can ask Pablo's opinion, too. I don't understand. Do you mean Pablo's opinion about the mailing list or about the forum? About the forum, I have contacted him a few days ago reporting the incident and he answered that he would give it a look once he was in front of a computer (he was using a blackberry or a mobile phone to email, I think). I have sent him a couple of emails but no answer yet. And plus, I am quite sure he's subscribed to this list. I think that, regardless of the qemu forum, there is a base of qemu users which are not subscribed to this mailing list that would like to exchange ideas and ask for mutual support and for which the medium of a web forum is not stimulating enough. If anybody with admin rights could activate the qemu-users list this would be very beneficial to this project. I, for instance, have a lot of questions to ask but I wouldn't dare on this mailing list because my post wouldn't be interesting enough to developers. Ottavio, User questions on this mailing list are not uncommon. I think your questions and discussions are welcome. However, I understand that following a mailing list that has high traffic and mostly contains patches is not ideal. It does make sense to bring the qemu users list back to life. Anthony may have mailing list admin access, he is CCed. I do, but qemu-users was created ages ago before I was an admin on the Savannah project. I suspect I'll need to submit a ticket to reset the list. I'll do that once I get back to the States. Regards, Anthony Liguori Stefan
Re: [Qemu-devel] Now, what's left to non-developers? (Qemu forum down again, No such list qemu-users)
On 19 August 2011 20:49, Anthony Liguori anth...@codemonkey.ws wrote: On 08/19/2011 11:28 AM, Stefan Hajnoczi wrote: On Fri, Aug 19, 2011 at 2:26 PM, Ottaviopr0f3ss0r1...@yahoo.com wrote: On 19 August 2011 11:08, 陳韋任che...@iis.sinica.edu.tw wrote: Hi, Ottavio 2) The qemu-user mailing list is not active: http://lists.nongnu.org/mailman/listinfo/qemu-users +1. Maybe you can ask Pablo's opinion, too. I don't understand. Do you mean Pablo's opinion about the mailing list or about the forum? About the forum, I have contacted him a few days ago reporting the incident and he answered that he would give it a look once he was in front of a computer (he was using a blackberry or a mobile phone to email, I think). I have sent him a couple of emails but no answer yet. And plus, I am quite sure he's subscribed to this list. I think that, regardless of the qemu forum, there is a base of qemu users which are not subscribed to this mailing list that would like to exchange ideas and ask for mutual support and for which the medium of a web forum is not stimulating enough. If anybody with admin rights could activate the qemu-users list this would be very beneficial to this project. I, for instance, have a lot of questions to ask but I wouldn't dare on this mailing list because my post wouldn't be interesting enough to developers. Ottavio, User questions on this mailing list are not uncommon. I think your questions and discussions are welcome. However, I understand that following a mailing list that has high traffic and mostly contains patches is not ideal. It does make sense to bring the qemu users list back to life. Anthony may have mailing list admin access, he is CCed. I do, but qemu-users was created ages ago before I was an admin on the Savannah project. I suspect I'll need to submit a ticket to reset the list. I'll do that once I get back to the States. Regards, Anthony Liguori Stefan Thanks Anthony and Stefan. -- Ottavio A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail?
Re: [Qemu-devel] Now, what's left to non-developers?
On Friday, August 19, 2011, 11:27:04, Ottavio wrote: Is anybody here interested in having an official place for qemu users? Neozeed (who provides Windows builds of Qemu) has stated that he's ready to host the Qemu forum on his domain: http://virtuallyfun.superglobalmegacorp.com/?p=1252 -- Jernej Simončič http://eternallybored.org/ A coup that is known in advance is a coup that does not take place. -- Camp's Law
Re: [Qemu-devel] sparc32_dma: correctly initialize ledma base address
On 15/08/11 16:38, Bob Breuer wrote: Depends on the rom. The SS-5 rom always sets it correctly, whereas the SS-20 rom only sets it when you do boot net. Also, this is just the top 8 bits of the address. The DMA2 documentation[1] for E_BASE_ADDR states that these upper address bits default to 0xff, even though it seems to incorrectly define it as bits 7:0 in the register instead of 31:24. Nice one - looks like I missed this when reading the documentation. At least the choice of default address now makes sense. If you follow Artyom's blog, at [2] it was assumed that the bogus dbri device was the culprit (which is also why I went down the path of implementing the dbri device), when in reality, the selftest failure was preventing boot net from running and fixing the ledma register settings. Okay - I think I see ;) In that case, I'd say this patch should be applied if Blue hasn't already done it (*sigh* I really miss the git web interface on qemu.org). ATB, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs
Re: [Qemu-devel] [PATCH v2 5/6] vga: Use linear mapping + dirty logging in chain 4 memory access mode
On 2011-08-19 08:19, Avi Kivity wrote: On 08/18/2011 03:26 PM, Jan Kiszka wrote: On 2011-08-17 16:48, Avi Kivity wrote: On 08/17/2011 04:38 PM, Avi Kivity wrote: The mmio code has s-plane_updated |= mask; /* only used to detect font change */ aren't we losing it? we could easily recover it via dirty logging. Yes, I forgot to forward-port plane_updated = 0xf from v1 of the patch. We can't really recover it. I don't see yet why we should not if we simply enforce a full update. Can you elaborate? If we go for a full update we might as well disable dirty logging entirely. Full update only affects text screen refreshes. The guest access to the VRAM will still benefit from the much faster mmio. So I think we need to restrict the optimization to graphic mode. Is grub using text mode or graphic mode? If it's using text mode, it may be faster to compare the font plane to a snapshot from the last redraw than to take an exit. I wasn't optimizing for text mode here, it's just a side effect if it happens to benefit from it as well. I could exclude it, but only if really needed. Ok, so grub is using graphic mode? Yep. We'll need to force full updates in text mode then. Right. I'll sent an update doing that. There are some other quirks of the series remaining I'm addressing ATM. Jan signature.asc Description: OpenPGP digital signature
[Qemu-devel] [PATCH] target-cris/opcode-cris.h: rename REG_PC/SP to CRIS_REG_PC/SP
The REG_PC constant used in opcode-cris.h can clash with a similar define in system include files. In particular the Ubuntu Lucid SPARC signal.h will define REG_PC, and since qemu-common.h now includes signal.h this was causing compile failures. Rename the constants to avoid this issue. (NB that REG_SP is not actually used within QEMU.) Signed-off-by: Peter Maydell peter.mayd...@linaro.org --- You might recall that we had to make a similar renaming in the linux-user code back in April for the same reason. target-cris/opcode-cris.h | 12 ++-- 1 files changed, 6 insertions(+), 6 deletions(-) diff --git a/target-cris/opcode-cris.h b/target-cris/opcode-cris.h index 8d4749d..779d4aa 100644 --- a/target-cris/opcode-cris.h +++ b/target-cris/opcode-cris.h @@ -29,8 +29,8 @@ along with this program; if not, see http://www.gnu.org/licenses/. */ /* Registers. */ #define MAX_REG (15) -#define REG_SP (14) -#define REG_PC (15) +#define CRIS_REG_SP (14) +#define CRIS_REG_PC (15) /* CPU version control of disassembly and assembly of instructions. May affect how the instruction is assembled, at least the size of @@ -138,7 +138,7 @@ extern const struct cris_cond15 cris_conds15[]; #define BDAP_INDIR_OPCODE (BDAP_INDIR_HIGH * 0x0100 + BDAP_INDIR_LOW) #define BDAP_INDIR_Z_BITS (BDAP_INDIR_HIGH_Z * 0x100 + BDAP_INDIR_LOW_Z) -#define BDAP_PC_LOW (BDAP_INDIR_LOW + REG_PC) +#define BDAP_PC_LOW (BDAP_INDIR_LOW + CRIS_REG_PC) #define BDAP_INCR_HIGH (BDAP_INDIR_HIGH + AUTOINCR_BIT) /* No prefix must have this code for its match bits in the @@ -192,16 +192,16 @@ extern const char *const cris_cc_strings[]; #define JUMP_INDIR_OPCODE (0x0930) #define JUMP_INDIR_Z_BITS (0xf2c0) #define JUMP_PC_INCR_OPCODE \ - (JUMP_INDIR_OPCODE + AUTOINCR_BIT * 0x0100 + REG_PC) + (JUMP_INDIR_OPCODE + AUTOINCR_BIT * 0x0100 + CRIS_REG_PC) #define MOVE_M_TO_PREG_OPCODE 0x0a30 #define MOVE_M_TO_PREG_ZBITS 0x01c0 /* BDAP.D N,PC. */ #define MOVE_PC_INCR_OPCODE_PREFIX \ - (((BDAP_INCR_HIGH | (REG_PC 4)) 8) | BDAP_PC_LOW | (2 4)) + (((BDAP_INCR_HIGH | (CRIS_REG_PC 4)) 8) | BDAP_PC_LOW | (2 4)) #define MOVE_PC_INCR_OPCODE_SUFFIX \ - (MOVE_M_TO_PREG_OPCODE | REG_PC | (AUTOINCR_BIT 8)) + (MOVE_M_TO_PREG_OPCODE | CRIS_REG_PC | (AUTOINCR_BIT 8)) #define JUMP_PC_INCR_OPCODE_V32 (0x0DBF) -- 1.7.4.1
Re: [Qemu-devel] [PATCH] target-cris/opcode-cris.h: rename REG_PC/SP to CRIS_REG_PC/SP
On Sat, Aug 20, 2011 at 12:27:04AM +0100, Peter Maydell wrote: The REG_PC constant used in opcode-cris.h can clash with a similar define in system include files. In particular the Ubuntu Lucid SPARC signal.h will define REG_PC, and since qemu-common.h now includes signal.h this was causing compile failures. Rename the constants to avoid this issue. (NB that REG_SP is not actually used within QEMU.) Signed-off-by: Peter Maydell peter.mayd...@linaro.org Applied, thanks Peter. Cheers
Re: [Qemu-devel] [PATCH 6/6] tcg-arm: Make tcg_out_addi inline
On 17 August 2011 22:11, Richard Henderson r...@twiddle.net wrote: As it's not used, fixes a compilation error. Signed-off-by: Richard Henderson r...@twiddle.net Reviewed-by: Peter Maydell peter.mayd...@linaro.org (We just hit this with the Ubuntu package builds of qemu-linaro for ARM host...) -- PMM
Re: [Qemu-devel] [PATCH 6/6] tcg-arm: Make tcg_out_addi inline
On 20 August 2011 01:51, Peter Maydell peter.mayd...@linaro.org wrote: On 17 August 2011 22:11, Richard Henderson r...@twiddle.net wrote: As it's not used, fixes a compilation error. Stefan Weil submitted an identical patch a couple of weeks ago, but I can't see the rationale for inlining. It seems like working around the warning is the only reason for this patch (?), so let's either remove/#if0 out the function or fix the compilation options to not error out on something that's not an error. (I'd prefer the latter but others may object) Cheers
Re: [Qemu-devel] unable to use device_add command to hot plug storage volumes to an instance.
Hi all, I'm still encountering this issue that I've described below. I think prior to qemu 0.12 qemu used to support the pci_add pci_addr=auto storage file=filename interface to hot plug/ hot add storage volumes to a running instance. However, the pci_add command is not supported in 0.12 at all. When did this happen? Secondly, now how can I achieve this for qemu 0.12? I've tried using the device_add interface and the documentation says that it should be very similar to the -device options on the command line when launching new instances. However, this just is not the case. I've been trying all sorts of experiments to no avail. I have a few related questions: 1. I connect to my instance using socat on the unix socket/monitor interface. i try passing commands like: (qemu) device_add driver=virtio-blk-pci,drive=/root/test_file etc and this fails. I've tried a number of other options as well and none of them seem to work. Secondly, do the inputs to device_add need to be in a JSON dictionary format? Thirdly, what is the expected input for the drive parameter? There seems to be no documentation describing exactly how this needs to be handled at all. Any help would be greatly appreciated. (qemu) device_add driver=virtio-blk-pci,bus=pci.0,addr=0x6,? device_add driver=virtio-blk-pci,bus=pci.0,addr=0x6,? virtio-blk-pci.class=hex32 virtio-blk-pci.drive=drive virtio-blk-pci.logical_block_size=uint16 virtio-blk-pci.physical_block_size=uint16 virtio-blk-pci.min_io_size=uint16 virtio-blk-pci.opt_io_size=uint32 virtio-blk-pci.vectors=uint32 virtio-blk-pci.indirect_desc=on/off virtio-blk-pci.scsi=on/off So it has all these options but what are the valid values for the drive parameter? Thanks, - Vinay - Original Message - From: Markus Armbruster arm...@redhat.com To: Vinay Venkataraghavan raghavanvi...@yahoo.com Cc: qemu-devel@nongnu.org qemu-devel@nongnu.org Sent: Monday, July 25, 2011 8:41 AM Subject: Re: [Qemu-devel] qemu 0.12 monitor command syntax and interface Vinay Venkataraghavan raghavanvi...@yahoo.com writes: Hi all, I am implementing a generic interface that supports qemu versions 0.9 to 0.12. As a result I have been trying to get the syntax for the monitor commands for various qemu versions. I have scrounged all over but have not been able to find the syntax for the device_add interface which is supported in qemu 0.12. I would really appreciate it if someone could point me to the syntax for these commands. The help text does not provide sufficient information about the argument list either: I tried many versions of this command but to no avail: device_add driver=virtio-blk-pci,bus=pci.0,addr=0x6,drive=/tmp/ec6f5d90-e734-4539-bd05-d7545e0f8323.img Not what you're asking for, but better than nothing: docs/qdev-device-use.txt Lastly does the device_add commands deprecate the pci_add commands or generically do the device_* commands deprecate the pci_* commands? In my opinion, yes.
Re: [Qemu-devel] Multi-threaded user program support?
So there are a number of issues here. Firstly, x86 targets in particular are worse than others for multi-threaded user mode: the patch you note is almost certainly not the only area that needs addressing. (Properly handling the x86 LOCK prefix by making sure we take a host mutex is very likely broken, for instance.) If you look in MAINTAINERS you'll see Just to be curious. *If* QEMU support multithreaded user program, would the different memory (coherence/consistency) model between guest and host architecture become a problem? Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667
Re: [Qemu-devel] [PATCH 6/6] tcg-arm: Make tcg_out_addi inline
On 20 August 2011 01:10, andrzej zaborowski balr...@gmail.com wrote: On 20 August 2011 01:51, Peter Maydell peter.mayd...@linaro.org wrote: On 17 August 2011 22:11, Richard Henderson r...@twiddle.net wrote: As it's not used, fixes a compilation error. Stefan Weil submitted an identical patch a couple of weeks ago, but I can't see the rationale for inlining. It seems like working around the warning is the only reason for this patch (?), so let's either remove/#if0 out the function or fix the compilation options to not error out on something that's not an error. (I'd prefer the latter but others may object) Yeah, we could remove the function (I'd prefer that to ifdeffery). I see malc did this for ppc/ppc64 in commits 1a2eb162414 and c24a9c6ef94. If we do this, for consistency we should also remove the unused implementations in tcg/ia64 and tcg/s390. -- PMM
Re: [Qemu-devel] sparc32_dma: correctly initialize ledma base address
Mark Cave-Ayland wrote: On 15/08/11 16:38, Bob Breuer wrote: Depends on the rom. The SS-5 rom always sets it correctly, whereas the SS-20 rom only sets it when you do boot net. Also, this is just the top 8 bits of the address. The DMA2 documentation[1] for E_BASE_ADDR states that these upper address bits default to 0xff, even though it seems to incorrectly define it as bits 7:0 in the register instead of 31:24. Nice one - looks like I missed this when reading the documentation. At least the choice of default address now makes sense. It might also make sense to modify the dma address calculations to use only the top 8 bits from ledma. Not sure if anything will care about that though. If you follow Artyom's blog, at [2] it was assumed that the bogus dbri device was the culprit (which is also why I went down the path of implementing the dbri device), when in reality, the selftest failure was preventing boot net from running and fixing the ledma register settings. Okay - I think I see ;) In that case, I'd say this patch should be applied if Blue hasn't already done it (*sigh* I really miss the git web interface on qemu.org). http://repo.or.cz/w/qemu.git might be the next best thing, not sure if there is a mirroring delay with it or not. Bob
[Qemu-devel] an excellent printer you need
Hi Sir, Have a nice day! Glad to hear that you're on the market of printing. We specialize in this field for several years and we are quite experienced in printing work. Products vary from books, folds, catalogs, brochures, to magazines, envelopes etc. The advantages of our company are obvious: HIGH QUALITY; LOW PRICE; CONSIDERATE SERVICES; QUICK LOGISTICS. If you want to do some printing, please do not hesitate to contact me. FREE SAMPLES will be sent for your evaluation if you like our prices! Thanks for reading my email. Any enquiries, feel free to contact me by ad...@hcurmate.com . Kind regards, Yuliya ad...@hcurmate.com attachment: HC.jpg
