[Qemu-devel] [Bug 544367] Re: pci_del fails to remove PCI virtio storage device
This bug is still present on latest git. It seems, please double check this, that the commit you tested is related to a different issue. The steps to reproduce the bug are attached on the case. Usually, when there is support for ACPI operations on the guest OS, the pci_del command triggers a general purpose event indicating to the OS ACPI event handlers that the device is going to be removed. The handlers are then in charge of trigger an eject operation (EJx) on the hw device, which causes the removal of the device. The EJx operation is handled on qemu by pciej_write() and ends by calling qdev_free(), which removes the device in question from the system. When there is no support for ACPI (either because the ACPI related drivers are not loaded on the guest OS or the VM is stopped using -s -S), there is no way to remove a previously added PCI device. I've just send a patch that adds the -f (force) option to pci_del in order to be able to remove a PCI device when the ACPI support is not present. Regards, Marcos -- pci_del fails to remove PCI virtio storage device https://bugs.launchpad.net/bugs/544367 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: Fix Released Bug description: In qemu monitor, command pci_del silently fails to remove a virtio storage device previously added with pci_add. It doesn't matter whether the guest actually makes use of the virtio device for this failure to happen. = QEMU command line = /usr/local/bin/qemu-system-x86_64 -S -snapshot -enable-kvm -smp 1 -cdrom /pub/gentoo/releases/x86/10.1/livedvd-x86-amd64-32ul-10.1.iso -boot order=d -m 512 -usb -name gentoo_livedvd -ctrl-grab -vga cirrus -chardev pty,id=serial0 -device isa-serial,chardev=serial0 -chardev socket,id=monitor,path=/tmp/gentoo_livedvd.monitor,server,nowait -mon chardev=monitor,mode=readline = Host information = Distribution: Gentoo Linux Portage 2.1.7.16 (default/linux/x86/10.0, gcc-4.3.4, glibc-2.10.1-r1, 2.6.31-gentoo-r6 i686) System uname: linux-2.6.31-gentoo-r6-i686-genuine_intel-r-_cpu_t13...@_1.66ghz-with-gentoo-1.12.13 = Guest information = Gentoo Linux 10.1 x86 LiveDVD
Re: [Qemu-devel] [PATCH] monitor: Add force option support to pci_del command
Marcos Oviedo moviedo.maill...@gmail.com writes: This adds a way to force the removal/unplug of previously added pci devices when ACPI-based hotplug mechanism is not present. Signed-off-by: Marcos Oviedo movi...@gmail.com If this makes sense for pci_del (I'm not passing judgement), then we need it for device_del as well.
Re: [Qemu-devel] [PATCH v2] net: Fix hotplug with pci_add
Amit Shah amit.s...@redhat.com writes: On (Tue) Jun 08 2010 [18:33:00], Markus Armbruster wrote: Amit Shah amit.s...@redhat.com writes: The correct model type wasn't getting added when hotplugging nics with pci_add. Testcase: start VM with default nic type. In the qemu_monitor: (qemu) pci_add auto nic model=virtio This results in a nic hot-plug of the same nic type as the default. Works fine for me on master, fd1dc858370d9a9ac7ea2512812c3a152ee6484b. What am I doing wrong? Did you start with a virtio nic added? The 'default' here is the nic type that's added as the first nic. Try this: start a VM with model e1000 and use pci_add to add a nic type of virtio. I do. Nevertheless, pci_add auto nic model=e1000 adds an e1000. Also works if I start without a NIC. Ah, if I start with a -net nic, then pci_add breaks as described! Now my next question is *how* your patch fixes this. It's not at all obvious to me. This was broken in 5294e2c774f120e10b44652ac143abda356f44eb Also changes the behaviour where no .init is defined for a net_client_type. Previously, 0 was returned, which indicated the init was successful and that 0 was the index into the nd_tables[] array. Return -1, indicating unsuccessful init, in such a case. The only element of net_client_types[] without an init() method is type none, index 0. So, doesn't this break -net none? And what does it fix? The net_client_types[] index isn't relevant here. -net none works fine, no problem. Let me rephrase: Behavior changes for -net types without an init() method. The only one without an init() method is none. Before, net_client_init() succeeded for it. Now it fails. What's the impact of that change? And why does it make sense?
Re: [Qemu-devel] [PATCH 00/16] clean up vl.c code
Jes Sorensen jes.soren...@redhat.com writes: On 06/04/10 13:54, Markus Armbruster wrote: Jes Sorensen jes.soren...@redhat.com writes: On 06/04/10 10:21, Markus Armbruster wrote: I like moving stuff out of vl.c in general. Your moves of entire functions look like a win to me. I have doubts about spreading the option switch over three files, though. The problem is right now there are too many OS specific options, but having the #ifdefs plastered all over to enable/disable them accordingly is just a nightmare and is prone to leave in inconsistent behavior for various OSes. See the set_proc_name() stuff for an example. I doubt spreading option code over separate files will help consistency. I suspect the true root of the problem is having (too many) OS-specific options in the first place. What about parsing options the same everywhere, calling out to OS-specific functions to do the actual work? Let them fail with can't do this on this OS. That is a possibility which I did consider, but it would end up in far more os specific functions for simple assignments etc. Far more? option condition what's needed to make it uncond. QEMU_OPTION_smb !_WIN32 net_slirp_smb() dummy. QEMU_OPTION_fsdev CONFIG_LINUXfsdev_init_func() dummy QEMU_OPTION_virtfs CONFIG_LINUXnothing, it's just short for -fsdev -device QEMU_OPTION_daemonize !_WIN32 move the big #ifndef _WIN32 chunk at the end of main() into a helper, + dummy QEMU_OPTION_chroot !_WIN32 ditto QEMU_OPTION_runas !_WIN32 ditto I modeled it the way I did similar to how we handle ioctl calls in the kernel. If there is strong feeling we should do it this way instead, I can change the code to do it this way instead. I am not married to the current approach, I just find it the lesser evil. I'm making suggestions, not demands. If you still prefer your way after considering my suggestions, go with it. For what it's worth, pushing OS-dependent bits out of the option parsing allows for: qemu: --frobnicate: Can't frobnicate under Windows instead of qemu: --frobnicate: invalid option
Re: [Qemu-devel] [RFC PATCH 3/6] RAMBlock: Add a name field
On 06/09/10 04:40, Anthony Liguori wrote: On 06/08/2010 09:30 PM, Paul Brook wrote: The offset given to a block created via qemu_ram_alloc/map() is arbitrary, let the caller specify a name so we can make a positive match. @@ -1924,7 +1925,9 @@ static int pci_add_option_rom(PCIDevice *pdev) + snprintf(name, sizeof(name), pci:%02x.%x.rom, + PCI_SLOT(pdev-devfn), PCI_FUNC(pdev-devfn)); + pdev-rom_offset = qemu_ram_alloc(name, size); This looks pretty bogus. It should be associated with the device, rather than incorrectly trying to generate a globally unique name. Not all ram is associated with a device. Nevertheless qdev could carry a list of any device specific ram, so qdev_free() could automagically cleanup for you on unplug. You could also reuse DeviceState-info-vmsd-name for the ram section naming. cheers, Gerd
Re: [Qemu-devel] [PATCH] monitor: Add force option support to pci_del command
On 06/09/10 07:37, Marcos Oviedo wrote: This adds a way to force the removal/unplug of previously added pci devices when ACPI-based hotplug mechanism is not present. Point being? If your guest can't handle pci hotplug it is pretty useless to plug in hardware in the first place. If your guest supports pci hotplug it will be quite upset if you zap the hardware without asking via ACPI. cheers, Gerd
Re: [Qemu-devel] [PATCH 15/22] machine: make max_cpus a -machine option
On 06/08/10 03:56, Anthony Liguori wrote:
On 06/07/2010 08:01 PM, Paul Brook wrote:
diff --git a/hw/realview.c b/hw/realview.c
index a36bdbe..8dcef80 100644
--- a/hw/realview.c
+++ b/hw/realview.c
@@ -444,9 +444,9 @@ static QEMUMachine realview_eb_mpcore_machine = {
.init = realview_eb_mpcore_init,
.opts_default = (QemuOptValue[]) {
QOPT_VALUE(default_drive, scsi),
+QOPT_VALUE(max_cpus, 4),
{ /* end of list */ }
},
-.max_cpus = 4,
};
By my reading this allows the user to modify this value. If so it is
wrong.
max_cpus is complicated because it was used for multiple purposes.
I think max_cpus ought to be configurable. The reason it's useful to
configure it that it lets a downstream specify a recommended max cpu
that's mostly relevant from a scalability perspective. For instance,
you may want to set the pc max_cpus to 64 since this is the highest that
KVM supports today.
max_cpus was designed to set the upper limit of allowable cpus on a
system. The main intention for it was to offer limits to things like
SeaBIOS to tell it how many entries to put into the BIOS tables for
systems where we allow hotplug etc. It was not meant to be used to set
limits higher than what the system is able to support, like on with the
current ACPI implementation in SeaBIOS we cannot go above 255 on PC
hardware.
However I don't really see the point in allowing max_cpus to be
configurable on a system like this where 4 is the possible max, per what
Paul is saying. If the user wants to run 4 cpus, he/she should specify
-smp X with 1 = X = 4.
Cheers,
Jes
Re: [Qemu-devel] [PATCH 15/22] machine: make max_cpus a -machine option
On 06/08/10 01:52, Anthony Liguori wrote:
max_cpus is a weird property today. On the one hand, it represents the
maximum
CPUs a board can support and is used to validate the number of vcpus requested
by the user.
On the other hand, max_cpus can be set by the user in which case it is taken
to mean the number of physical sockets that should be advertised by the
firmware. Furthermore, if max_cpus isn't explicitly set by the user, it's
defaulted to the number of smp_cpus. But there's actually a second copy of
max_cpus that still represents the maximum cpus spported by the platform.
Sorry this is wrong, max_cpus never meant to advertise the number of
sockets, it means the number of cores (ie. cpus) as the limit advertised
by firmware.
Yes, it's confusing. So let's be a bit more obvious. This patch introduces
a sockets parameter that allows a user to explicitly set the number of
advertised sockets apart from the number of maximum cpus.
This is something of a stop gap. We really ought to specify a more rich
NUMA topology as machine options but that will come later.
Signed-off-by: Anthony Liguori aligu...@us.ibm.com
[snip]
diff --git a/hw/fw_cfg.c b/hw/fw_cfg.c
index 22ebb50..de4454f 100644
--- a/hw/fw_cfg.c
+++ b/hw/fw_cfg.c
@@ -321,7 +321,8 @@ int fw_cfg_add_file(FWCfgState *s, const char *dir,
const char *filename,
}
FWCfgState *fw_cfg_init(uint32_t ctl_port, uint32_t data_port,
-target_phys_addr_t ctl_addr, target_phys_addr_t
data_addr)
+target_phys_addr_t ctl_addr, target_phys_addr_t
data_addr,
+QemuOpts *opts)
{
FWCfgState *s;
int io_ctl_memory, io_data_memory;
@@ -349,7 +350,8 @@ FWCfgState *fw_cfg_init(uint32_t ctl_port, uint32_t
data_port,
fw_cfg_add_bytes(s, FW_CFG_UUID, qemu_uuid, 16);
fw_cfg_add_i16(s, FW_CFG_NOGRAPHIC, (uint16_t)(display_type ==
DT_NOGRAPHIC));
fw_cfg_add_i16(s, FW_CFG_NB_CPUS, (uint16_t)smp_cpus);
-fw_cfg_add_i16(s, FW_CFG_MAX_CPUS, (uint16_t)max_cpus);
+fw_cfg_add_i16(s, FW_CFG_MAX_CPUS,
+ (uint16_t)qemu_opt_get_number(opts, sockets, smp_cpus));
fw_cfg_add_i16(s, FW_CFG_BOOT_MENU, (uint16_t)boot_menu);
NACK this is just plain wrong!
Sorry Anthony, but max_cpus never meant number of sockets. It is used by
the BIOS to calculate table sizes for CPU entries, and that number is
based on cores, not sockets.
If you want to pass a number of sockets onto the BIOS, I will totally
support that, but you need to introduce FW_CFG_MAX_SOCKETS for that
instead, and tell the BIOS to use that for the SRAT.
Cheers,
Jes
Re: [Qemu-devel] [PATCH 21/22] machine: convert pc machines to split core vs machine API
On 06/08/10 01:52, Anthony Liguori wrote:
+static QemuOptValue pc_machine_v0_11[] = {
+QOPT_VALUE(name, pc-0.11),
+QOPT_VALUE(desc, Standard PC, qemu 0.11),
+QOPT_VALUE(acpi, on),
+QOPT_VALUE(pci, on),
+QOPT_VALUE(cpu, PC_DEFAULT_CPU_MODEL),
+QOPT_VALUE(max_cpus, 255),
+QOPT_COMPAT_INT(virtio-blk-pci, vectors, 0),
+QOPT_COMPAT_INT(virtio-serial-pci, max_nr_ports, 1),
+QOPT_COMPAT_INT(virtio-serial-pci, vectors, 0),
+QOPT_COMPAT(ide-drive, ver, 0.11),
+QOPT_COMPAT(scsi-disk, ver, 0.11),
+QOPT_COMPAT_INT(PCI, rombar, 0),
+{ /* end of list */ }
};
For v11 and older, you might want to change max_cpus to what the BIOS we
supported back then actually was able to run with, ie. 15.
Cheers,
Jes
Re: [Qemu-devel] [PATCH] un-register kbd driver in case of USB kbd unplug.
jes.soren...@redhat.com writes: From: Jes Sorensen jes.soren...@redhat.com If a USB keyboard is unplugged, the keyboard eventhandler is never removed, and events will continue to be passed through to the device, causing crashes or memory corruption. Looks good. I wonder how many more unplug surprises to expect.
Re: [Qemu-devel] Disable PS/2 mouse
Peter Lieven p...@dlh.net writes: Hi, is there any way to disable the PS/2 mouse emulation from command line? Judging from pc_basic_device_init() and i8042_initfn(): I don't think so, sorry.
[Qemu-devel] Re: [PATCH v2] net: Fix hotplug with pci_add
Markus Armbruster arm...@redhat.com wrote:
Amit Shah amit.s...@redhat.com writes:
On (Tue) Jun 08 2010 [18:33:00], Markus Armbruster wrote:
Amit Shah amit.s...@redhat.com writes:
The correct model type wasn't getting added when hotplugging nics with
pci_add.
Testcase: start VM with default nic type. In the qemu_monitor:
(qemu) pci_add auto nic model=virtio
This results in a nic hot-plug of the same nic type as the default.
Works fine for me on master, fd1dc858370d9a9ac7ea2512812c3a152ee6484b.
What am I doing wrong?
Did you start with a virtio nic added? The 'default' here is the nic
type that's added as the first nic. Try this: start a VM with model
e1000 and use pci_add to add a nic type of virtio.
I do. Nevertheless, pci_add auto nic model=e1000 adds an e1000.
Also works if I start without a NIC.
Ah, if I start with a -net nic, then pci_add breaks as described!
Now my next question is *how* your patch fixes this. It's not at all
obvious to me.
Far away form the patch file. Look at:
hw/pci-hotplug.c
static PCIDevice *qemu_pci_hot_add_nic(Monitor *mon,
const char *devaddr,
const char *opts_str)
{
.
ret = net_client_init(mon, opts, 0);
.
return pci_nic_init(nd_table[ret], rtl8139, devaddr);
}
You can see that accessing nd_table with value 1 as before was wrong.
BTW, once here, didn't default nic should be e1000? not rtl8139?
This was broken in 5294e2c774f120e10b44652ac143abda356f44eb
Also changes the behaviour where no .init is defined for a
net_client_type. Previously, 0 was returned, which indicated the init
was successful and that 0 was the index into the nd_tables[] array.
Return -1, indicating unsuccessful init, in such a case.
The only element of net_client_types[] without an init() method is type
none, index 0. So, doesn't this break -net none? And what does it
fix?
The net_client_types[] index isn't relevant here. -net none works fine,
no problem.
Let me rephrase: Behavior changes for -net types without an init()
method. The only one without an init() method is none. Before,
net_client_init() succeeded for it. Now it fails. What's the impact of
that change? And why does it make sense?
Here, I don't know.
Later, Juan.
[Qemu-devel] [Bug 586420] Re: WinXP install cd hangs at boot time if machine started with floppy
If you built your own qemu it may try to look for the BIOS in /usr/local/share/qemu and not where it was originally installed on your system. Could you please try to specify it with the -L option and see. You don't mention what system you are running on, it would likely be -L /usr/share/qemu-kvm or -L /usr/share/qemu but it depends on the system. Jes -- WinXP install cd hangs at boot time if machine started with floppy https://bugs.launchpad.net/bugs/586420 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: Incomplete Bug description: I have a second problem: I wanted to install Windows Server 2003 on a virtio drive, so I tried to start the machine with the install cd as the boot drive and a floppy image with the viostor drivers. The problem is, the install cd hangs at boot time. If I start VNC I just see a black ground with 640x480. I've also tried this with the install cd of Windows Server 2008 R2 and it works! Could it be that the BIOS screws up because the older install cds are using the floppy emulation to boot the setup?
[Qemu-devel] Re: [RFC PATCH 2/6] ram_blocks: Convert to a QLIST
Alex Williamson alex.william...@redhat.com wrote:
On Tue, 2010-06-08 at 14:26 -0700, Chris Wright wrote:
* Alex Williamson (alex.william...@redhat.com) wrote:
extern int phys_ram_fd;
-extern uint8_t *phys_ram_dirty;
extern ram_addr_t ram_size;
-extern ram_addr_t last_ram_offset;
+
+typedef struct RAMBlock {
+uint8_t *host;
+ram_addr_t offset;
+ram_addr_t length;
+QLIST_ENTRY(RAMBlock) next;
+} RAMBlock;
+
+typedef struct RAMList {
+uint8_t *phys_dirty;
+ram_addr_t last_offset;
+QLIST_HEAD(ram, RAMBlock) blocks;
+} RAMList;
+extern RAMList ram;
such a generic name for global namespace
Well it is _the_ ram, but yea... ;) Suggestions?
ram_block_list?
Later, Juan.
Re: [Qemu-devel] [PATCH 00/16] clean up vl.c code
On 06/09/10 09:07, Markus Armbruster wrote: Jes Sorensen jes.soren...@redhat.com writes: On 06/04/10 13:54, Markus Armbruster wrote: If there is strong feeling we should do it this way instead, I can change the code to do it this way instead. I am not married to the current approach, I just find it the lesser evil. I'm making suggestions, not demands. If you still prefer your way after considering my suggestions, go with it. For what it's worth, pushing OS-dependent bits out of the option parsing allows for: qemu: --frobnicate: Can't frobnicate under Windows instead of qemu: --frobnicate: invalid option That is true, on the other hand I think it would be cleaner to not advertise options on an OS where it is not supported. Ideally I would like them to not show up in qemu --help at all. Cheers, Jes
[Qemu-devel] Re: [RFC PATCH 00/23] Kemari for KVM v0.1.1
Hi, I rebased the patch series to the head of both qemu.git (26ebe46848ecb2462cc53d4de20ac6590709643b) and qemu-kvm.git (3f505ec990599aeb960ed7031a2bb7b233ea4927). The repository contains branches for both tree. git://kemari.git.sourceforge.net/gitroot/kemari/kemari Patches for qemu.git are in master branch, and patches for qemu-kvm.git are in kemari-v0.1.1-kvm. I would split 23 patches into small chunks and send it separately to make reviewing easier, and hopefully have feedbacks. Thanks, Yoshi Yoshiaki Tamura wrote: Hi, This patch series is a revised version of Kemari for KVM, which applied comments for the previous post. The current code is based on qemu-kvm.git 2b644fd0e737407133c88054ba498e772ce01f27. On the contrary to the previous version, this series doesn't require any modifications to KVM. The I/O events are caputured in net/block layer instead of device emulation layer. The transmission/transaction protocol, and most of the control logic is implemented in QEMU. We prepared a demonstration video again. This time the guest is Windows XP without virtio drivers. The demonstration scenario is, 1. Play with a guest VM (This guest has e1000 and ide) # The guest image should be a NFS/SAN. 2. Start incoming side with, -incomingprotocol:address:port,ft_mode 3. Start Kemari to synchronize the VM by running the following command in QEMU. Just add -k option to usual migrate command. migrate -d -k tcp:192.168.0.20: 3. Check the status by calling info migrate. 4. Go back to the VM to play the pinball. 5. Kill the the VM. (VNC client also disappears) 6. Press c to continue the VM on the other host. 7. Bring up the VNC client (Sorry, it pops outside of video capture.) 8. Confirm that the pinball works, then shutdown. http://www.osrg.net/kemari/download/kemari-kvm-winxp.mov The repository contains all patches we're sending with this message. For those who want to try, please pull the following repository. git://kemari.git.sourceforge.net/gitroot/kemari/kemari The changes from v0.1 - v0.1.1 are: - events are tapped in net/block layer instead of device emulation layer. - Introduce a new option for -incoming to accept FT transaction. - Removed writev() support to QEMUFile and FdMigrationState for now. I would post this work in a different series. - Modified virtio-blk save/load handler to send inuse variable to correctly replay. - Removed configure --enable-ft-mode. - Removed unnecessary check for qemu_realloc(). I hope people like this approach, and looking forward to suggestions/comments. Thanks, Yoshi Yoshiaki Tamura (23): Modify DIRTY_FLAG value and introduce DIRTY_IDX to use as indexes of bit-based phys_ram_dirty. Introduce cpu_physical_memory_get_dirty_range(). Use cpu_physical_memory_set_dirty_range() to update phys_ram_dirty. Use cpu_physical_memory_get_dirty_range() to check multiple dirty pages. Make QEMUFile buf expandable, and introduce qemu_realloc_buffer() and qemu_clear_buffer(). Introduce read() to FdMigrationState. Introduce skip_header parameter to qemu_loadvm_state(). Introduce some socket util functions. Introduce fault tolerant VM transaction QEMUFile and ft_mode. Introduce util functions to control ft_transaction from savevm layer. Introduce qemu_savevm_state_all(). Insent event-tap callbacks to net/block layer. Introduce event-tap. Call init handler of event-tap at main(). Insert event_tap_ioport() to ioport_write(). Insert event_tap_mmio() to cpu_physical_memory_rw(). Skip assert() when event_tap_state weren't EVENT_TAP_OFF. Call event_tap_replay() at vm_start(). Introduce ft_tranx_ready(), and modify migrate_fd_put_ready() when ft_mode is on. Modify tcp_accept_incoming_migration() to handle ft_mode, and add a hack not to close fd when ft_mode is enabled. virtio-blk: Modify save/load handler to handle inuse varialble. Introduce -k option to enable FT migration mode (Kemari). Add a parser to accept FT migration incoming mode. Makefile.objs|1 + Makefile.target |1 + block.c | 22 +++ block.h |4 + cpu-all.h| 134 - event-tap.c | 184 event-tap.h | 32 exec.c | 131 + ft_transaction.c | 418 ++ ft_transaction.h | 54 +++ hw/hw.h |7 + hw/virtio.c |8 +- ioport.c |2 + migration-exec.c |2 +- migration-fd.c |2 +- migration-tcp.c | 52 +++- migration-unix.c |2 +- migration.c | 110 ++- migration.h |3 + net/queue.c | 18 +++ net/queue.h |3 + osdep.c | 13 ++ qemu-char.c | 25 +++- qemu-kvm.c | 23 ++--
[Qemu-devel] Re: Live Migration of 32-bit Linux guest broken since 2.6.35-rc2
Avi Kivity wrote: On 06/08/2010 04:44 PM, Peter Lieven wrote: -cpu host is good if you have identical machines and don't plan to add new ones. i will likely add new ones, but my plan would be to use qemu64 and then add all flags manually that are common to all cpus in the pool. would that be safe? Yes. 2 last questions: a) i remember that there (have been) are instructions that have a high virtualization penalty. are there flags that should better not be offered to a VM? b) you told you fixed another bug in 2.6.35. is the nx virtualization not working in guests before 2.6.35 and therefore my case worked with 2.6.34? thanks peter
Re: [Qemu-devel] Disable PS/2 mouse
Markus Armbruster wrote: Peter Lieven p...@dlh.net writes: Hi, is there any way to disable the PS/2 mouse emulation from command line? Judging from pc_basic_device_init() and i8042_initfn(): I don't think so, sorry. would it be difficult to implement?
Re: [Qemu-devel] Disable PS/2 mouse
Markus Armbruster wrote: Peter Lieven p...@dlh.net writes: Hi, is there any way to disable the PS/2 mouse emulation from command line? Judging from pc_basic_device_init() and i8042_initfn(): I don't think so, sorry. background: with the ps/2 mouse there are always problems with pointer synchronization. so i generally use usb tablet device emulation. BUT. usb emulation is resource intensive. i have a testcase with 64 VMs on a dual quadcore xeon and usb alone almost uses the resources of 2 cpus. so i decided to introduce an option for 'console-only' vms. but in that case i would like to have ps/2 mouse also disabled in case someone has the wrong option and complains than that his mouse is unsynchronized. so 'console-only' should be no mouse at all.
[Qemu-devel] [PATCH] Add optional dump of default config file paths..
This patch adds the ability to determine the build-configured
runtime config file paths from the command line. After
support for cpu model definitions were added to the default
runtime target- config file, testing of this feature has
tripped over an unintentionally mis-installed config file
enough to indicate some help is needed resolving such issues.
As no general verbose flag is currently available, specifying
-readconfig ? on the command line will maintain the default
(config file) disposition but additionally emit diagnostic info.
This mode is optional, otherwise the existing startup behavior
is identical.
Signed-off-by: john cooper john.coo...@redhat.com
---
diff --git a/qemu-config.c b/qemu-config.c
index 5a4e61b..a490603 100644
--- a/qemu-config.c
+++ b/qemu-config.c
@@ -518,21 +518,29 @@ out:
return res;
}
-int qemu_read_config_file(const char *filename)
+/* attempt to open and parse config file, report problems if vflag
+ */
+int qemu_read_config_file(const char *filename, int vflag)
{
FILE *f = fopen(filename, r);
-int ret;
+int rv = 0;
if (f == NULL) {
-return -errno;
+rv = -errno;
}
-
-ret = qemu_config_parse(f, vm_config_groups, filename);
-fclose(f);
-
-if (ret == 0) {
-return 0;
-} else {
-return -EINVAL;
+else if (qemu_config_parse(f, vm_config_groups, filename) != 0) {
+rv = -EINVAL;
+}
+else if (vflag) {
+fprintf(stderr, read config file %s\n, filename);
}
+if (f) {
+fclose(f);
+}
+if (rv vflag) {
+fprintf(stderr, can't read config file %s: %s\n,
+filename, strerror(-rv));
+}
+return rv;
}
+
diff --git a/qemu-config.h b/qemu-config.h
index dca69d4..2e15556 100644
--- a/qemu-config.h
+++ b/qemu-config.h
@@ -23,6 +23,6 @@ void qemu_add_globals(void);
void qemu_config_write(FILE *fp);
int qemu_config_parse(FILE *fp, QemuOptsList **lists, const char *fname);
-int qemu_read_config_file(const char *filename);
+int qemu_read_config_file(const char *filename, int vflag);
#endif /* QEMU_CONFIG_H */
diff --git a/vl.c b/vl.c
index 7121cd0..23c7276 100644
--- a/vl.c
+++ b/vl.c
@@ -2582,6 +2582,7 @@ int main(int argc, char **argv, char **envp)
#endif
int show_vnc_port = 0;
int defconfig = 1;
+int defconfig_verbose = 0;
error_set_progname(argv[0]);
@@ -2657,6 +2658,10 @@ int main(int argc, char **argv, char **envp)
case QEMU_OPTION_nodefconfig:
defconfig=0;
break;
+case QEMU_OPTION_readconfig:
+if (!strcmp(optarg, ?))
+defconfig_verbose = 1;
+break;
}
}
}
@@ -2664,12 +2669,14 @@ int main(int argc, char **argv, char **envp)
if (defconfig) {
int ret;
-ret = qemu_read_config_file(CONFIG_QEMU_CONFDIR /qemu.conf);
+ret = qemu_read_config_file(CONFIG_QEMU_CONFDIR /qemu.conf,
+defconfig_verbose);
if (ret 0 ret != -ENOENT) {
exit(1);
}
-ret = qemu_read_config_file(arch_config_name);
+ret = qemu_read_config_file(arch_config_name,
+defconfig_verbose);
if (ret 0 ret != -ENOENT) {
exit(1);
}
@@ -3386,15 +3393,9 @@ int main(int argc, char **argv, char **envp)
xen_mode = XEN_ATTACH;
break;
case QEMU_OPTION_readconfig:
-{
-int ret = qemu_read_config_file(optarg);
-if (ret 0) {
-fprintf(stderr, read config %s: %s\n, optarg,
-strerror(-ret));
-exit(1);
-}
-break;
-}
+if (!defconfig_verbose qemu_read_config_file(optarg, 1) 0)
+exit(1);
+break;
case QEMU_OPTION_writeconfig:
{
FILE *fp;
--
john.coo...@redhat.com
Re: [Qemu-devel] Disable PS/2 mouse
Peter Lieven wrote: background: with the ps/2 mouse there are always problems with pointer synchronization. Yeah, we have that here on one of our WinNT VMs. The quick solution we found was to install VNC Server on NT and set up everyone to connect to that rather than to the physical Qemu/KVM VNC framebuffer. It may not be completely optimal, but it at least solves the synchronised mouse pointer issue which was the major complaint we were getting from our users. HTH, 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
[Qemu-devel] [Bug 591320] Re: [ARM]: SIMD add/sub instructions are incorrect
The first one results from wrong saturation judgment.
The original form is :
uint8_t sub8_usat(uint8_t a, uint8_t b) {
if (a b)
return a - b;
else
return 0;
}
it should be a b
The second problem is using op2 as op1 to tell among signed, unsigned, and half
group
** Patch added: For case 2
http://launchpadlibrarian.net/5603/0001-target-arm-fix-thumb2-parallel-add-sub-opcode-decodi.patch
--
[ARM]: SIMD add/sub instructions are incorrect
https://bugs.launchpad.net/bugs/591320
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
Status in QEMU: New
Bug description:
The thumb2 and unsigned arm state SIMD add/sub instructions are implemented
incorrectly, for example:
UQSUB8 r0, r1, r0
gives r0 as 0, where r0 is 0x12345678 and r1 is 0x23456789 in ARM state, and:
UHSUB8 r0, r1, r0
gives r0 as 0xbe01, where r0 is 0x12345678 and r1 is 0x23456789 in thumb2
state.
This problem is present in git HEAD, (at time of writing,
fd1dc858370d9a9ac7ea2512812c3a152ee6484b).
[Qemu-devel] [Bug 591320] Re: [ARM]: SIMD add/sub instructions are incorrect
One attachment is allowed in each comment : for case 1 ** Patch added: for case 1 problem http://launchpadlibrarian.net/5666/0002-target-arm-fix-parallel-saturated-subtraction-error.patch -- [ARM]: SIMD add/sub instructions are incorrect https://bugs.launchpad.net/bugs/591320 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: New Bug description: The thumb2 and unsigned arm state SIMD add/sub instructions are implemented incorrectly, for example: UQSUB8 r0, r1, r0 gives r0 as 0, where r0 is 0x12345678 and r1 is 0x23456789 in ARM state, and: UHSUB8 r0, r1, r0 gives r0 as 0xbe01, where r0 is 0x12345678 and r1 is 0x23456789 in thumb2 state. This problem is present in git HEAD, (at time of writing, fd1dc858370d9a9ac7ea2512812c3a152ee6484b).
[Qemu-devel] [Bug 513273] Re: kvm with -vga std is broken since karmic
Still getting BUG: kvm_dirty_pages_log_enable_slot: invalid parameters with -vga std-parameter on lucid. I would suggest to set the bug-status to confirmed instead of fix-released. --- dpkg -l |egrep -e kvm|vgabios ii kvm 1:84+dfsg-0ubuntu16+0.12.3+noroms+0ubuntu9 dummy transitional pacakge from kvm to qemu- ii kvm-pxe 5.4.4-1ubuntu1 PXE ROM's for KVM ii qemu-kvm 0.12.3+noroms-0ubuntu9 Full virtualization on i386 and amd64 hardwa ii vgabios 0.6c-2ubuntu1 VGA BIOS software for the Bochs and Qemu emu -- kvm with -vga std is broken since karmic https://bugs.launchpad.net/bugs/513273 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: Invalid Status in “qemu-kvm” package in Ubuntu: Invalid Status in “seabios” package in Ubuntu: Invalid Status in “vgabios” package in Ubuntu: Fix Released Status in “qemu-kvm” source package in Lucid: Invalid Status in “seabios” source package in Lucid: Invalid Status in “vgabios” source package in Lucid: Fix Released Bug description: Binary package hint: qemu-kvm it works with -vga cirrus, with -vga std I got: BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters And driver do not work properly (I can not set screen resolution) ...
[Qemu-devel] Migration Support in QEMU
Hi, I've read in a Reservoir paper[1] the following passage: 2.2.8 VEE-MIG: Migration of VMs between hosts that do not share storage This code supports migraton of VMs between hosts that do not share storage. Modifications have been made to QEMU-kvm and libvirt. This code was developed by IBM Haifa Research Lab. But we are in the process of submitting it for open source distribution. The QEMU-kvm is scheduled to be incorporated in the QEMU release 0.12.0. The libvirt patch will be submitted once all changes are offically accept to the QEMU release. This feature sounds really interesting to me but in the change log[2] I couldn't find something about it. Can you tell me something about this? When will it be incorporated? Best Regards, Stefan [1] http://62.149.240.97/uploads/Training/RESERVOIR_Framework_Guide_Website.pdf [2] http://wiki.qemu.org/ChangeLog smime.p7s Description: S/MIME cryptographic signature
Re: [Qemu-devel] [PATCH 0/2] tcg cleanups, part 4
On Wed, Jun 02, 2010 at 05:26:54PM -0700, Richard Henderson wrote: The tcg_out_mov patch you've seen before, but now contains a TCG_TYPE_REG that should address the concerns you had with the changes to the sparc port. It's also been updated to HEAD to reflect the changes in tcg/i386. The second patch is new. r~ Richard Henderson (2): tcg: Add TYPE parameter to tcg_out_mov. tcg: Make some tcg-target.c routines static. tcg/arm/tcg-target.c|6 ++-- tcg/hppa/tcg-target.c | 42 +++--- tcg/i386/tcg-target.c | 40 ++-- tcg/ia64/tcg-target.c |7 +++-- tcg/mips/tcg-target.c | 32 ++-- tcg/ppc/tcg-target.c| 52 +++--- tcg/ppc64/tcg-target.c | 14 ++-- tcg/s390/tcg-target.c |6 ++-- tcg/sparc/tcg-target.c | 14 ++-- tcg/tcg.c | 14 +++- tcg/tcg.h | 14 tcg/x86_64/tcg-target.c | 49 ++-- 12 files changed, 144 insertions(+), 146 deletions(-) Thanks, applied. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net
[Qemu-devel] Re: [PATCH v2] net: Fix hotplug with pci_add
On (Wed) Jun 09 2010 [09:59:50], Juan Quintela wrote: BTW, once here, didn't default nic should be e1000? not rtl8139? Are you looking at qemu-kvm sources? ;-) Amit
[Qemu-devel] Re: [PATCH] megasas: Update to version 1.01
Nicholas A. Bellinger wrote:
On Tue, 2010-06-08 at 16:15 +0200, Hannes Reinecke wrote:
This patch updates the megasas HBA emulation to version 1.01.
It fixes the following issues:
- Remove hand-crafted inquiry command
- Remove bounce-buffer for direct commands
- Implements qdev properties to set 'max_sge', 'max_cmds'.
- Implement JBOD mode
- Improve direct command handling
- Minor cleanups
Signed-off-by: Hannes Reinecke h...@suse.de
Hi Hannes,
I applied your changes and everything looks good with the exception of
the new MEGASAS_DEFAULT_SGE=80 setting..
diff --git a/hw/megasas.c b/hw/megasas.c
index 250c3fb..19569a8 100644
--- a/hw/megasas.c
+++ b/hw/megasas.c
@@ -40,38 +40,17 @@ do { fprintf(stderr, megasas: error: fmt , ##
__VA_ARGS__);} while (0)
#endif
/* Static definitions */
-#define MEGASAS_MAX_FRAMES 1000
-#define MEGASAS_MAX_SGE 8
snip
+#define MEGASAS_VERSION 1.01
+#define MEGASAS_MAX_FRAMES 2048 /* Firmware limit at 65535 */
+#define MEGASAS_DEFAULT_FRAMES 1000 /* Windows requires this */
+#define MEGASAS_MAX_SGE 255 /* Firmware limit */
+#define MEGASAS_DEFAULT_SGE 80
Ok, I have been running some LTP disktest raw bandwith benchmarks with a
256K blocksize with megasas - TCM_Loop - TCM/RAMDISK_DR LUNs into a
v2.6.26 x86_64 Linux guest (4 VCPUs and 2048 memory) and I noticed
something interesting..
With the new MEGASAS_DEFAULT_SGE 80 setting for fw_sge, read/write tests
have dropped from the original ~1050 MB/sec to roughly ~400 MB/sec.
Passing in the new qdev option using the old default of max_sge=8 the
speed jumps back up to the range that where previously observed w/o this
patch. Going a bit further, using max_sge=16 jumps up bandwith up to
~1600 MB/sec, and max_sge=24 takes it up to ~2200 MB/sec..! Using
max_sge=32 then sharply drops back to ~800 MB/sec, and increasing to
larger values brings bandwith down lower and lower..
Taking a look at the megaraid_sas LLD in the KVM guest, the struct
scsi_host is being registered with sg_tablesize=28 which appears to be
where the sharp dropoff for max_sge 28 begins to occur. I see that
MFI_DCMD_CTRL_GET_INFO is returning the configured fw_sge to the guest,
but AFAICT megaraid_sas does not adjust itself to use the larger value
reported by GET_INFO.
Thanks for confirmation. You just confirmed _why_ I made
the SGE setting configurable.
The SGE default setting as found on 'real' HBAs is in fact 80,
hence this value.
However, I always suspected that we will have problems with
direct SGL mapping if the settings from the underlying hardware
and the emulation don't match.
Which was the reason for the LSF discussion topic, if you remember :-)
So thanks for the confirmation here.
Hence I made the SGE setting configurable, so that it can be
adjusted (manually for starters) to the underlying hardware.
If you do a:
-device megasas,id=megasas,max_sge=28,mode=jbod
you have the desired behaviour.
Currently we cannot do this tuning automatically; we just have
_one_ setting for the entire HBA emulation whereas the underlying
disks connected to the megasas might have different settings.
Again, the proper handling here should be discussed on the LSF.
So that said, I think we want to use MEGASAS_DEFAULT_SGE 28 to match
what the Linux driver is using. I have not checked what the equivlient
sg_tablesize for the MSFT LLD is doing, but it appears we need to error
on the conserative side here. What do you think..?
As said, this is _not_ what linux is using. This is what you particular
HBA is using. On one of my machines I have:
cat /sys/class/scsi_host/host?/sg_tablesize
128
128
128
64
64
128
128
So maybe you should consider updating your HBA ...
I would advocate setting it to the real HBA setting of
80 (which works just find for file-based backends)
and have it adjusted manually if an sg-based backend
is used.
Proper handling here will be discussed at LSF.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries Storage
h...@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg)
Re: [Qemu-devel] [PATCH] Fix multiboot compilation
On Wed, Jun 02, 2010 at 01:56:50AM +0200, Alexander Graf wrote: Commit dd4239d6574ca41c94fc0d0f77ddc728510ffc57 broke multiboot. It replaced the instruction rep insb (%dx), %es:(%edi) by the binary output of addr32 rep insb (%dx), %es:(%di). Linuxboot calls the respective helper function in a code16 section. So the original instruction was automatically translated to its addr32 equivalent. For multiboot, we're running in code32 so gcc didn't add the addr32 which breaks the instruction. This patch splits that helper function in one which uses addr32 and one which does not, so everyone's happy. The good news is that nobody probably cared so far. The bundled multiboot.bin binary was built before the change and is thus correct. Please also put this patch into -stable. Signed-off-by: Alexander Graf ag...@suse.de --- pc-bios/optionrom/linuxboot.S |8 pc-bios/optionrom/optionrom.h | 32 2 files changed, 28 insertions(+), 12 deletions(-) Thanks, applied. diff --git a/pc-bios/optionrom/linuxboot.S b/pc-bios/optionrom/linuxboot.S index 8aebe51..c109363 100644 --- a/pc-bios/optionrom/linuxboot.S +++ b/pc-bios/optionrom/linuxboot.S @@ -106,10 +106,10 @@ copy_kernel: /* We're now running in 16-bit CS, but 32-bit ES! */ /* Load kernel and initrd */ - read_fw_blob(FW_CFG_KERNEL) - read_fw_blob(FW_CFG_INITRD) - read_fw_blob(FW_CFG_CMDLINE) - read_fw_blob(FW_CFG_SETUP) + read_fw_blob_addr32(FW_CFG_KERNEL) + read_fw_blob_addr32(FW_CFG_INITRD) + read_fw_blob_addr32(FW_CFG_CMDLINE) + read_fw_blob_addr32(FW_CFG_SETUP) /* And now jump into Linux! */ mov $0, %eax diff --git a/pc-bios/optionrom/optionrom.h b/pc-bios/optionrom/optionrom.h index 4dcb906..fbdd48a 100644 --- a/pc-bios/optionrom/optionrom.h +++ b/pc-bios/optionrom/optionrom.h @@ -50,13 +50,7 @@ bswap %eax .endm -/* - * Read a blob from the fw_cfg device. - * Requires _ADDR, _SIZE and _DATA values for the parameter. - * - * Clobbers: %eax, %edx, %es, %ecx, %edi - */ -#define read_fw_blob(var)\ +#define read_fw_blob_pre(var)\ read_fw var ## _ADDR; \ mov %eax, %edi; \ read_fw var ## _SIZE; \ @@ -65,10 +59,32 @@ mov $BIOS_CFG_IOPORT_CFG, %edx; \ outw%ax, (%dx); \ mov $BIOS_CFG_IOPORT_DATA, %dx; \ - cld;\ + cld + +/* + * Read a blob from the fw_cfg device. + * Requires _ADDR, _SIZE and _DATA values for the parameter. + * + * Clobbers: %eax, %edx, %es, %ecx, %edi + */ +#define read_fw_blob(var)\ + read_fw_blob_pre(var); \ /* old as(1) doesn't like this insn so emit the bytes instead: \ rep insb(%dx), %es:(%edi); \ */ \ + .dc.b 0xf3,0x6c + +/* + * Read a blob from the fw_cfg device in forced addr32 mode. + * Requires _ADDR, _SIZE and _DATA values for the parameter. + * + * Clobbers: %eax, %edx, %es, %ecx, %edi + */ +#define read_fw_blob_addr32(var) \ + read_fw_blob_pre(var); \ + /* old as(1) doesn't like this insn so emit the bytes instead: \ + addr32 rep insb (%dx), %es:(%edi); \ + */ \ .dc.b 0x67,0xf3,0x6c #define OPTION_ROM_START \ -- 1.6.0.2 -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net
[Qemu-devel] Re: [PATCH] megasas: Update to version 1.01
On Wed, 2010-06-09 at 03:14 -0700, Nicholas A. Bellinger wrote:
On Tue, 2010-06-08 at 16:15 +0200, Hannes Reinecke wrote:
This patch updates the megasas HBA emulation to version 1.01.
It fixes the following issues:
- Remove hand-crafted inquiry command
- Remove bounce-buffer for direct commands
- Implements qdev properties to set 'max_sge', 'max_cmds'.
- Implement JBOD mode
- Improve direct command handling
- Minor cleanups
Signed-off-by: Hannes Reinecke h...@suse.de
Hi Hannes,
I applied your changes and everything looks good with the exception of
the new MEGASAS_DEFAULT_SGE=80 setting..
diff --git a/hw/megasas.c b/hw/megasas.c
index 250c3fb..19569a8 100644
--- a/hw/megasas.c
+++ b/hw/megasas.c
@@ -40,38 +40,17 @@ do { fprintf(stderr, megasas: error: fmt , ##
__VA_ARGS__);} while (0)
#endif
/* Static definitions */
-#define MEGASAS_MAX_FRAMES 1000
-#define MEGASAS_MAX_SGE 8
snip
+#define MEGASAS_VERSION 1.01
+#define MEGASAS_MAX_FRAMES 2048/* Firmware limit at 65535 */
+#define MEGASAS_DEFAULT_FRAMES 1000/* Windows requires this */
+#define MEGASAS_MAX_SGE 255/* Firmware limit */
+#define MEGASAS_DEFAULT_SGE 80
Ok, I have been running some LTP disktest raw bandwith benchmarks with a
256K blocksize with megasas - TCM_Loop - TCM/RAMDISK_DR LUNs into a
v2.6.26 x86_64 Linux guest (4 VCPUs and 2048 memory) and I noticed
something interesting..
With the new MEGASAS_DEFAULT_SGE 80 setting for fw_sge, read/write tests
have dropped from the original ~1050 MB/sec to roughly ~400 MB/sec.
Passing in the new qdev option using the old default of max_sge=8 the
speed jumps back up to the range that where previously observed w/o this
patch. Going a bit further, using max_sge=16 jumps up bandwith up to
~1600 MB/sec, and max_sge=24 takes it up to ~2200 MB/sec..! Using
max_sge=32 then sharply drops back to ~800 MB/sec, and increasing to
larger values brings bandwith down lower and lower..
Taking a look at the megaraid_sas LLD in the KVM guest, the struct
scsi_host is being registered with sg_tablesize=28 which appears to be
where the sharp dropoff for max_sge 28 begins to occur. I see that
MFI_DCMD_CTRL_GET_INFO is returning the configured fw_sge to the guest,
but AFAICT megaraid_sas does not adjust itself to use the larger value
reported by GET_INFO.
Actually scratch that last part about the megaraid_sas LLD..
drivers/scsi/megaraid/megaraid_sas.c:megasas_io_attach() is setting the
MFI GET_INFO returned fw_sge value to struct scsi_host-sg_tablesize
before calling scsi_add_host(), but there still appears to be an
performance issue somewhere when using max_sge 28..
Note for TCM_Loop LLD running on KVM host we are currently using a
default of sg_tablesize=256. Running the same LTP disktest benchmark
with TCM/RAMDISK LUNs as above for a Linux guest on a baremetal KVM host
(5500 series Nehalem) with v2.6.34 I am now seeing ~12900 MB/sec (yes,
100 Gbit/sec) of sustained read/write bandwith into the same single
Linux/SCSI LUN. So AFAICT the limiting factor with the larger megasas
max_sge mentioned above appears to be outside of any bottlenecks that
may exist in Linux/SCSI or TCM_Loop+SG_IO backstore used with megasas.
Best,
--nab
Re: [Qemu-devel] Disable PS/2 mouse
Hi, BUT. usb emulation is resource intensive. Update qemu. Fixed in 0.12.4 and unstable. cheers, Gerd
Re: [Qemu-devel] [STABLE 0/3] Fix -usbdevice crash
On Wed, Jun 02, 2010 at 05:19:53PM -0300, Luiz Capitulino wrote: This series fixes bug 573827, which is a segfault when you do: $ qemu -usbdevice serial All commits backported from current master, just minimally tested. Thanks, applied. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net
Re: [Qemu-devel] Disable PS/2 mouse
Gerd Hoffmann wrote: Hi, BUT. usb emulation is resource intensive. Update qemu. Fixed in 0.12.4 and unstable. thanks for this update. i think my experience came from 0.12.3 i will verify this cheers, Gerd
[Qemu-devel] Re: [PATCH] megasas: Update to version 1.01
On Wed, 2010-06-09 at 12:32 +0200, Hannes Reinecke wrote:
Nicholas A. Bellinger wrote:
Hi Hannes,
I applied your changes and everything looks good with the exception of
the new MEGASAS_DEFAULT_SGE=80 setting..
diff --git a/hw/megasas.c b/hw/megasas.c
index 250c3fb..19569a8 100644
--- a/hw/megasas.c
+++ b/hw/megasas.c
@@ -40,38 +40,17 @@ do { fprintf(stderr, megasas: error: fmt , ##
__VA_ARGS__);} while (0)
#endif
/* Static definitions */
-#define MEGASAS_MAX_FRAMES 1000
-#define MEGASAS_MAX_SGE 8
snip
+#define MEGASAS_VERSION 1.01
+#define MEGASAS_MAX_FRAMES 2048 /* Firmware limit at 65535 */
+#define MEGASAS_DEFAULT_FRAMES 1000 /* Windows requires this */
+#define MEGASAS_MAX_SGE 255 /* Firmware limit */
+#define MEGASAS_DEFAULT_SGE 80
Ok, I have been running some LTP disktest raw bandwith benchmarks with a
256K blocksize with megasas - TCM_Loop - TCM/RAMDISK_DR LUNs into a
v2.6.26 x86_64 Linux guest (4 VCPUs and 2048 memory) and I noticed
something interesting..
With the new MEGASAS_DEFAULT_SGE 80 setting for fw_sge, read/write tests
have dropped from the original ~1050 MB/sec to roughly ~400 MB/sec.
Passing in the new qdev option using the old default of max_sge=8 the
speed jumps back up to the range that where previously observed w/o this
patch. Going a bit further, using max_sge=16 jumps up bandwith up to
~1600 MB/sec, and max_sge=24 takes it up to ~2200 MB/sec..! Using
max_sge=32 then sharply drops back to ~800 MB/sec, and increasing to
larger values brings bandwith down lower and lower..
Taking a look at the megaraid_sas LLD in the KVM guest, the struct
scsi_host is being registered with sg_tablesize=28 which appears to be
where the sharp dropoff for max_sge 28 begins to occur. I see that
MFI_DCMD_CTRL_GET_INFO is returning the configured fw_sge to the guest,
but AFAICT megaraid_sas does not adjust itself to use the larger value
reported by GET_INFO.
Thanks for confirmation. You just confirmed _why_ I made
the SGE setting configurable.
The SGE default setting as found on 'real' HBAs is in fact 80,
hence this value.
However, I always suspected that we will have problems with
direct SGL mapping if the settings from the underlying hardware
and the emulation don't match.
Which was the reason for the LSF discussion topic, if you remember :-)
So thanks for the confirmation here.
Indeed, I was looking at best case large block bandwith with
TCM/RAMDISK_DR and zero-copy struct scatterlist mapping with the
can_queue and max_sectors using 1024. Having a TCM IBLOCK/FILEIO/pSCSI
backstore for a real backend struct block_device is going to have a
certain overhead compared to raw struct page ramdisk, but I think the
RAMDISK_DR subsystem plugin gives us a good idea of where we are at with
TCM_Loop struct scsi_devices.. ;)
Hence I made the SGE setting configurable, so that it can be
adjusted (manually for starters) to the underlying hardware.
If you do a:
-device megasas,id=megasas,max_sge=28,mode=jbod
you have the desired behaviour.
Perfect.. I will check out mode=jbod as well..
Currently we cannot do this tuning automatically; we just have
_one_ setting for the entire HBA emulation whereas the underlying
disks connected to the megasas might have different settings.
Again, the proper handling here should be discussed on the LSF.
nod
So that said, I think we want to use MEGASAS_DEFAULT_SGE 28 to match
what the Linux driver is using. I have not checked what the equivlient
sg_tablesize for the MSFT LLD is doing, but it appears we need to error
on the conserative side here. What do you think..?
As said, this is _not_ what linux is using. This is what you particular
HBA is using. On one of my machines I have:
cat /sys/class/scsi_host/host?/sg_tablesize
128
128
128
64
64
128
128
So maybe you should consider updating your HBA ...
Yes, my mistake. megaraid_sas is actually querying for it's struct
scsi_host-sg_tablesize..
I would advocate setting it to the real HBA setting of
80 (which works just find for file-based backends)
and have it adjusted manually if an sg-based backend
is used.
Hmm, then it appears that there is a known bottleneck somewhere in the
v2.6.26 Linux guest stack or perhaps somewhere else or something with
SG_IO..?
I am still using include/scsi/sg.h:SG_MAX_QUEUE 128, but I am not sure
if this would be effectted by the larger max_sge too..? I am also
wondering if the conversion to use BSG here will have an effect with the
larger max_sge values..?
Best,
--nab
Re: [Qemu-devel] Disable PS/2 mouse
Peter Lieven p...@dlh.net writes: Markus Armbruster wrote: Peter Lieven p...@dlh.net writes: Hi, is there any way to disable the PS/2 mouse emulation from command line? Judging from pc_basic_device_init() and i8042_initfn(): I don't think so, sorry. would it be difficult to implement? I don't know.
Re: [Qemu-devel] [PATCH v2] net: Fix hotplug with pci_add
Amit Shah amit.s...@redhat.com writes:
On (Wed) Jun 09 2010 [08:37:26], Markus Armbruster wrote:
Amit Shah amit.s...@redhat.com writes:
On (Tue) Jun 08 2010 [18:33:00], Markus Armbruster wrote:
Amit Shah amit.s...@redhat.com writes:
The correct model type wasn't getting added when hotplugging nics with
pci_add.
Testcase: start VM with default nic type. In the qemu_monitor:
(qemu) pci_add auto nic model=virtio
This results in a nic hot-plug of the same nic type as the default.
Works fine for me on master, fd1dc858370d9a9ac7ea2512812c3a152ee6484b.
What am I doing wrong?
Did you start with a virtio nic added? The 'default' here is the nic
type that's added as the first nic. Try this: start a VM with model
e1000 and use pci_add to add a nic type of virtio.
I do. Nevertheless, pci_add auto nic model=e1000 adds an e1000.
Also works if I start without a NIC.
Ah, if I start with a -net nic, then pci_add breaks as described!
Now my next question is *how* your patch fixes this. It's not at all
obvious to me.
The callers of net_client_init() expect a positive return value that
means an index into the nd_table[] array, where the options just parsed
are placed.
Let's look at 5294e2c774f120e10b44652ac143abda356f44eb, which broke this
thing:
if (net_client_types[i].init) {
-return net_client_types[i].init(opts, mon, name, vlan);
-} else {
-return 0;
+if (net_client_types[i].init(opts, mon, name, vlan) 0) {
+/* TODO push error reporting into init() methods */
+qerror_report(QERR_DEVICE_INIT_FAILED, type);
+return -1;
+}
}
+return 0;
See it yet? instead of returning the value returned by
net_client_types[i].init(), we're now just returning either 0 or -1. The
return value is now by default '0' for successful init(), which causes
the calling functions to just end up using the same parameters that were
passed for the first nic type.
Ah! Could a brief version of this be added to the commit message?
This was broken in 5294e2c774f120e10b44652ac143abda356f44eb
Also changes the behaviour where no .init is defined for a
net_client_type. Previously, 0 was returned, which indicated the init
was successful and that 0 was the index into the nd_tables[] array.
Return -1, indicating unsuccessful init, in such a case.
The only element of net_client_types[] without an init() method is type
none, index 0. So, doesn't this break -net none? And what does it
fix?
The net_client_types[] index isn't relevant here. -net none works fine,
no problem.
Let me rephrase: Behavior changes for -net types without an init()
method. The only one without an init() method is none. Before,
net_client_init() succeeded for it. Now it fails. What's the impact of
that change? And why does it make sense?
It makes sense because we don't actually initialise anything. We don't
place anything in the nd_table[] array. That means callers shouldn't
poke in the array for any values. Returning -1 makes sense for that
reason. If we continued to return 0, callers might just assume that init
was successful and that nd_table[0] was set up for use appropriately.
The thing is that the code doesn't go this far in case of '-net none'
anyway. This was just a potential bug lurking around for any new -net
method which didn't have an init.
Okay.
Thanks for your patience.
Re: [Qemu-devel] [RFC PATCH 3/6] RAMBlock: Add a name field
On 06/09/2010 05:54 AM, Paul Brook wrote: On 06/08/2010 09:30 PM, Paul Brook wrote: The offset given to a block created via qemu_ram_alloc/map() is arbitrary, let the caller specify a name so we can make a positive match. @@ -1924,7 +1925,9 @@ static int pci_add_option_rom(PCIDevice *pdev) +snprintf(name, sizeof(name), pci:%02x.%x.rom, + PCI_SLOT(pdev-devfn), PCI_FUNC(pdev-devfn)); +pdev-rom_offset = qemu_ram_alloc(name, size); This looks pretty bogus. It should be associated with the device, rather than incorrectly trying to generate a globally unique name. Not all ram is associated with a device. Maybe not, but where it is we should be using that information. Absolute minimum we should be using the existing qdev address rather than inventing a new one. Duplicating this logic inside every device seems like a bad idea so I suggest identifying ram blocks by a (name, device) pair. For now we can allow a NULL device for system memory. I agree, this is duplicating the qdev tree in a string. Devices/BARs should have ram qdev fields and so ram can be enumerated completely via qdev. System memory can be part of a system device. -- error compiling committee.c: too many arguments to function
[Qemu-devel] Re: [RFC PATCH 3/6] RAMBlock: Add a name field
On 06/09/2010 12:41 AM, Chris Wright wrote: pci. D.F. (B:D.F?) D:B:D.F bar rom bar.n -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] Migration Support in QEMU
On Jun 9, 2010, at 5:39 AM, Harder, Stefan wrote: Hi, I've read in a Reservoir paper[1] the following passage: 2.2.8 VEE-MIG: Migration of VMs between hosts that do not share storage This code supports migraton of VMs between hosts that do not share storage. Modifications have been made to QEMU-kvm and libvirt. This code was developed by IBM Haifa Research Lab. But we are in the process of submitting it for open source distribution. The QEMU-kvm is scheduled to be incorporated in the QEMU release 0.12.0. The libvirt patch will be submitted once all changes are offically accept to the QEMU release. This feature sounds really interesting to me but in the change log[2] I couldn't find something about it. Can you tell me something about this? When will it be incorporated? Best Regards, Stefan [1] http://62.149.240.97/uploads/Training/RESERVOIR_Framework_Guide_Website.pdf [2] http://wiki.qemu.org/ChangeLog It has been integrated in QEMU 0.12, back in December IIRC. -- Pierre Riteau -- PhD student, Myriads team, IRISA, Rennes, France http://perso.univ-rennes1.fr/pierre.riteau/
[Qemu-devel] [PATCH v3 0/5] Add QMP migration events
This is a resent with what we agreed on yesterday call. Migration events would be there for 0.13 until we get proper async command support. Later, Juan. v3: - Add comment that MIGRATION_FAILURE will add a QError for 0.14 (when we get internal support for that) rebase against today tree v2: - Address pbonzini and mst changes (error messages and doc fixes) v1: This series does: - exit incoming migration on failure. For exec/fd migrations, once there was a failure, there was nothing useful to do. And for tcp migration, not exiting created interesting bugs when trying to migrate again to a process with a faild migration. - Factorize common migration code, no more duplication, makes easier to do global migration things, like QMP events. - Introduce QMP events, both for incoming and outgoing migration. Now, the million dollar question: Why I didn't refactorize outgoing migration? I tried, and have it partially done on my local tree. But it depends (too much) of current_migration global variable - Libvirt folks will also want info migrate to work on the incoming side, i.e. current_migraition has to also be updated on incoming side. Done until here, but then I hit the wall incoming migration is synchronous. To make the monitor work on incoming migration, we need to change buffered_file.c abstraction to also work for incoming fd's, or another similar solution. I am open to suggestions about what to do here. This series are quite simple (the unfinished part is more complex), will send the other part as an RFC later. Please review and consider to apply it. Later, Juan. Juan Quintela (5): Exit if incoming migration fails Factorize common migration incoming code QMP: Introduce MIGRATION events QMP: Emit migration events on incoming migration QMP: Emit migration events on outgoing migration QMP/qmp-events.txt | 52 migration-exec.c | 17 +++-- migration-fd.c | 15 ++- migration-tcp.c| 17 - migration-unix.c | 17 - migration.c| 37 +++-- migration.h|4 +++- monitor.c | 12 monitor.h |4 vl.c |7 ++- 10 files changed, 121 insertions(+), 61 deletions(-)
[Qemu-devel] [PATCH v3 1/5] Exit if incoming migration fails
Signed-off-by: Juan Quintela quint...@redhat.com
---
migration.c | 16 ++--
migration.h |2 +-
vl.c|7 ++-
3 files changed, 17 insertions(+), 8 deletions(-)
diff --git a/migration.c b/migration.c
index fbf2339..ecc67f1 100644
--- a/migration.c
+++ b/migration.c
@@ -36,22 +36,26 @@ static uint32_t max_throttle = (32 20);
static MigrationState *current_migration;
-void qemu_start_incoming_migration(const char *uri)
+int qemu_start_incoming_migration(const char *uri)
{
const char *p;
+int ret;
if (strstart(uri, tcp:, p))
-tcp_start_incoming_migration(p);
+ret = tcp_start_incoming_migration(p);
#if !defined(WIN32)
else if (strstart(uri, exec:, p))
-exec_start_incoming_migration(p);
+ret = exec_start_incoming_migration(p);
else if (strstart(uri, unix:, p))
-unix_start_incoming_migration(p);
+ret = unix_start_incoming_migration(p);
else if (strstart(uri, fd:, p))
-fd_start_incoming_migration(p);
+ret = fd_start_incoming_migration(p);
#endif
-else
+else {
fprintf(stderr, unknown migration protocol: %s\n, uri);
+ret = -EPROTONOSUPPORT;
+}
+return ret;
}
int do_migrate(Monitor *mon, const QDict *qdict, QObject **ret_data)
diff --git a/migration.h b/migration.h
index 97eef4a..e048bb2 100644
--- a/migration.h
+++ b/migration.h
@@ -50,7 +50,7 @@ struct FdMigrationState
void *opaque;
};
-void qemu_start_incoming_migration(const char *uri);
+int qemu_start_incoming_migration(const char *uri);
int do_migrate(Monitor *mon, const QDict *qdict, QObject **ret_data);
diff --git a/vl.c b/vl.c
index 7121cd0..c35b46e 100644
--- a/vl.c
+++ b/vl.c
@@ -3826,7 +3826,12 @@ int main(int argc, char **argv, char **envp)
}
if (incoming) {
-qemu_start_incoming_migration(incoming);
+int ret = qemu_start_incoming_migration(incoming);
+if (ret 0) {
+fprintf(stderr, Migration failed. Exit code %s(%d), exiting.\n,
+incoming, ret);
+exit(ret);
+}
} else if (autostart) {
vm_start();
}
--
1.6.6.1
[Qemu-devel] [PATCH v3 4/5] QMP: Emit migration events on incoming migration
Signed-off-by: Juan Quintela quint...@redhat.com
---
migration.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/migration.c b/migration.c
index 4ce19ff..2a44b46 100644
--- a/migration.c
+++ b/migration.c
@@ -60,10 +60,13 @@ int qemu_start_incoming_migration(const char *uri)
void process_incoming_migration(QEMUFile *f)
{
+monitor_protocol_event(QEVENT_MIGRATION_STARTED, NULL);
if (qemu_loadvm_state(f) 0) {
+monitor_protocol_event(QEVENT_MIGRATION_FAILED, NULL);
fprintf(stderr, load of migration failed\n);
exit(0);
}
+monitor_protocol_event(QEVENT_MIGRATION_ENDED, NULL);
qemu_announce_self();
DPRINTF(successfully loaded vm state\n);
--
1.6.6.1
[Qemu-devel] [PATCH v3 3/5] QMP: Introduce MIGRATION events
They are emitted when migration starts, ends, has a failure or is canceled.
Signed-off-by: Juan Quintela quint...@redhat.com
---
QMP/qmp-events.txt | 52
monitor.c | 12
monitor.h |4
3 files changed, 68 insertions(+), 0 deletions(-)
diff --git a/QMP/qmp-events.txt b/QMP/qmp-events.txt
index 01ec85f..cafc4e6 100644
--- a/QMP/qmp-events.txt
+++ b/QMP/qmp-events.txt
@@ -26,6 +26,58 @@ Example:
Note: If action is stop, a STOP event will eventually follow the
BLOCK_IO_ERROR event.
+MIGRATION_CANCELED
+--
+
+Emitted when migration is canceled. This is emitted in the source.
+Target will emit MIGRATION_FAILED (no way to differentiate a FAILED
+and CANCELED migration for target).
+
+Data: None
+
+Example:
+
+{ event: MIGRATION_CANCELED,
+timestamp: {seconds: 1274687575, microseconds: 592483} }
+
+MIGRATION_ENDED
+---
+
+Emitted when migration ends (both in source and target)
+
+Data: None
+
+Example:
+
+{ event: MIGRATION_ENDED,
+timestamp: {seconds: 1274687575, microseconds: 592483} }
+
+MIGRATION_FAILED
+
+
+Emitted when migration fails (both is source and target). Notice
+that this event will be changed for 0.14 when we have infrastructure
+to emit a QError when things fail.
+
+Data: None
+
+Example:
+
+{ event: MIGRATION_FAILED,
+timestamp: {seconds: 1274687575, microseconds: 592483} }
+
+MIGRATION_STARTED
+-
+
+Emitted when migration starts (both in source and target).
+
+Data: None
+
+Example:
+
+{ event: MIGRATION_STARTED,
+timestamp: {seconds: 1274687575, microseconds: 592483} }
+
RESET
-
diff --git a/monitor.c b/monitor.c
index 15b53b9..a5c5388 100644
--- a/monitor.c
+++ b/monitor.c
@@ -444,6 +444,18 @@ void monitor_protocol_event(MonitorEvent event, QObject
*data)
case QEVENT_WATCHDOG:
event_name = WATCHDOG;
break;
+case QEVENT_MIGRATION_STARTED:
+event_name = MIGRATION_STARTED;
+break;
+case QEVENT_MIGRATION_ENDED:
+event_name = MIGRATION_ENDED;
+break;
+case QEVENT_MIGRATION_FAILED:
+event_name = MIGRATION_FAILED;
+break;
+case QEVENT_MIGRATION_CANCELED:
+event_name = MIGRATION_CANCELED;
+break;
default:
abort();
break;
diff --git a/monitor.h b/monitor.h
index ea15469..34bcd38 100644
--- a/monitor.h
+++ b/monitor.h
@@ -28,6 +28,10 @@ typedef enum MonitorEvent {
QEVENT_BLOCK_IO_ERROR,
QEVENT_RTC_CHANGE,
QEVENT_WATCHDOG,
+QEVENT_MIGRATION_STARTED,
+QEVENT_MIGRATION_ENDED,
+QEVENT_MIGRATION_FAILED,
+QEVENT_MIGRATION_CANCELED,
QEVENT_MAX,
} MonitorEvent;
--
1.6.6.1
[Qemu-devel] [PATCH v3 2/5] Factorize common migration incoming code
Signed-off-by: Juan Quintela quint...@redhat.com
---
migration-exec.c | 14 +-
migration-fd.c | 14 +-
migration-tcp.c | 15 ++-
migration-unix.c | 15 ++-
migration.c | 13 +
migration.h |2 ++
6 files changed, 21 insertions(+), 52 deletions(-)
diff --git a/migration-exec.c b/migration-exec.c
index a8813b4..14718dd 100644
--- a/migration-exec.c
+++ b/migration-exec.c
@@ -121,20 +121,8 @@ err_after_alloc:
static void exec_accept_incoming_migration(void *opaque)
{
QEMUFile *f = opaque;
-int ret;
-ret = qemu_loadvm_state(f);
-if (ret 0) {
-fprintf(stderr, load of migration failed\n);
-goto err;
-}
-qemu_announce_self();
-DPRINTF(successfully loaded vm state\n);
-
-if (autostart)
-vm_start();
-
-err:
+process_incoming_migration(f);
qemu_set_fd_handler2(qemu_stdio_fd(f), NULL, NULL, NULL, NULL);
qemu_fclose(f);
}
diff --git a/migration-fd.c b/migration-fd.c
index 0abd372..6d14505 100644
--- a/migration-fd.c
+++ b/migration-fd.c
@@ -104,20 +104,8 @@ err_after_alloc:
static void fd_accept_incoming_migration(void *opaque)
{
QEMUFile *f = opaque;
-int ret;
-ret = qemu_loadvm_state(f);
-if (ret 0) {
-fprintf(stderr, load of migration failed\n);
-goto err;
-}
-qemu_announce_self();
-DPRINTF(successfully loaded vm state\n);
-
-if (autostart)
-vm_start();
-
-err:
+process_incoming_migration(f);
qemu_set_fd_handler2(qemu_stdio_fd(f), NULL, NULL, NULL, NULL);
qemu_fclose(f);
}
diff --git a/migration-tcp.c b/migration-tcp.c
index 95ce722..20f2e37 100644
--- a/migration-tcp.c
+++ b/migration-tcp.c
@@ -143,7 +143,7 @@ static void tcp_accept_incoming_migration(void *opaque)
socklen_t addrlen = sizeof(addr);
int s = (unsigned long)opaque;
QEMUFile *f;
-int c, ret;
+int c;
do {
c = qemu_accept(s, (struct sockaddr *)addr, addrlen);
@@ -162,18 +162,7 @@ static void tcp_accept_incoming_migration(void *opaque)
goto out;
}
-ret = qemu_loadvm_state(f);
-if (ret 0) {
-fprintf(stderr, load of migration failed\n);
-goto out_fopen;
-}
-qemu_announce_self();
-DPRINTF(successfully loaded vm state\n);
-
-if (autostart)
-vm_start();
-
-out_fopen:
+process_incoming_migration(f);
qemu_fclose(f);
out:
qemu_set_fd_handler2(s, NULL, NULL, NULL, NULL);
diff --git a/migration-unix.c b/migration-unix.c
index 49de1b9..57232c0 100644
--- a/migration-unix.c
+++ b/migration-unix.c
@@ -149,7 +149,7 @@ static void unix_accept_incoming_migration(void *opaque)
socklen_t addrlen = sizeof(addr);
int s = (unsigned long)opaque;
QEMUFile *f;
-int c, ret;
+int c;
do {
c = qemu_accept(s, (struct sockaddr *)addr, addrlen);
@@ -168,18 +168,7 @@ static void unix_accept_incoming_migration(void *opaque)
goto out;
}
-ret = qemu_loadvm_state(f);
-if (ret 0) {
-fprintf(stderr, load of migration failed\n);
-goto out_fopen;
-}
-qemu_announce_self();
-DPRINTF(successfully loaded vm state\n);
-
-if (autostart)
-vm_start();
-
-out_fopen:
+process_incoming_migration(f);
qemu_fclose(f);
out:
qemu_set_fd_handler2(s, NULL, NULL, NULL, NULL);
diff --git a/migration.c b/migration.c
index ecc67f1..4ce19ff 100644
--- a/migration.c
+++ b/migration.c
@@ -58,6 +58,19 @@ int qemu_start_incoming_migration(const char *uri)
return ret;
}
+void process_incoming_migration(QEMUFile *f)
+{
+if (qemu_loadvm_state(f) 0) {
+fprintf(stderr, load of migration failed\n);
+exit(0);
+}
+qemu_announce_self();
+DPRINTF(successfully loaded vm state\n);
+
+if (autostart)
+vm_start();
+}
+
int do_migrate(Monitor *mon, const QDict *qdict, QObject **ret_data)
{
MigrationState *s = NULL;
diff --git a/migration.h b/migration.h
index e048bb2..d13ed4f 100644
--- a/migration.h
+++ b/migration.h
@@ -50,6 +50,8 @@ struct FdMigrationState
void *opaque;
};
+void process_incoming_migration(QEMUFile *f);
+
int qemu_start_incoming_migration(const char *uri);
int do_migrate(Monitor *mon, const QDict *qdict, QObject **ret_data);
--
1.6.6.1
[Qemu-devel] [PATCH v3 5/5] QMP: Emit migration events on outgoing migration
Signed-off-by: Juan Quintela quint...@redhat.com
---
migration-exec.c |3 ++-
migration-fd.c |1 +
migration-tcp.c |2 ++
migration-unix.c |2 ++
migration.c |5 +
5 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/migration-exec.c b/migration-exec.c
index 14718dd..9052cd2 100644
--- a/migration-exec.c
+++ b/migration-exec.c
@@ -22,6 +22,7 @@
#include block.h
#include sys/types.h
#include sys/wait.h
+#include monitor.h
//#define DEBUG_MIGRATION_EXEC
@@ -101,9 +102,9 @@ MigrationState *exec_start_outgoing_migration(Monitor *mon,
s-mig_state.shared = inc;
s-state = MIG_STATE_ACTIVE;
+monitor_protocol_event(QEVENT_MIGRATION_STARTED, NULL);
s-mon = NULL;
s-bandwidth_limit = bandwidth_limit;
-
if (!detach) {
migrate_fd_monitor_suspend(s, mon);
}
diff --git a/migration-fd.c b/migration-fd.c
index 6d14505..9c4c7ae 100644
--- a/migration-fd.c
+++ b/migration-fd.c
@@ -83,6 +83,7 @@ MigrationState *fd_start_outgoing_migration(Monitor *mon,
s-mig_state.blk = blk;
s-mig_state.shared = inc;
+monitor_protocol_event(QEVENT_MIGRATION_STARTED, NULL);
s-state = MIG_STATE_ACTIVE;
s-mon = NULL;
s-bandwidth_limit = bandwidth_limit;
diff --git a/migration-tcp.c b/migration-tcp.c
index 20f2e37..11a1203 100644
--- a/migration-tcp.c
+++ b/migration-tcp.c
@@ -18,6 +18,7 @@
#include sysemu.h
#include buffered_file.h
#include block.h
+#include monitor.h
//#define DEBUG_MIGRATION_TCP
@@ -102,6 +103,7 @@ MigrationState *tcp_start_outgoing_migration(Monitor *mon,
s-mig_state.blk = blk;
s-mig_state.shared = inc;
+monitor_protocol_event(QEVENT_MIGRATION_STARTED, NULL);
s-state = MIG_STATE_ACTIVE;
s-mon = NULL;
s-bandwidth_limit = bandwidth_limit;
diff --git a/migration-unix.c b/migration-unix.c
index 57232c0..08f29a3 100644
--- a/migration-unix.c
+++ b/migration-unix.c
@@ -18,6 +18,7 @@
#include sysemu.h
#include buffered_file.h
#include block.h
+#include monitor.h
//#define DEBUG_MIGRATION_UNIX
@@ -101,6 +102,7 @@ MigrationState *unix_start_outgoing_migration(Monitor *mon,
s-mig_state.blk = blk;
s-mig_state.shared = inc;
+monitor_protocol_event(QEVENT_MIGRATION_STARTED, NULL);
s-state = MIG_STATE_ACTIVE;
s-mon = NULL;
s-bandwidth_limit = bandwidth_limit;
diff --git a/migration.c b/migration.c
index 2a44b46..256a679 100644
--- a/migration.c
+++ b/migration.c
@@ -268,6 +268,7 @@ void migrate_fd_monitor_suspend(FdMigrationState *s,
Monitor *mon)
void migrate_fd_error(FdMigrationState *s)
{
DPRINTF(setting error state\n);
+monitor_protocol_event(QEVENT_MIGRATION_FAILED, NULL);
s-state = MIG_STATE_ERROR;
migrate_fd_cleanup(s);
}
@@ -371,8 +372,10 @@ void migrate_fd_put_ready(void *opaque)
if (old_vm_running) {
vm_start();
}
+monitor_protocol_event(QEVENT_MIGRATION_FAILED, NULL);
state = MIG_STATE_ERROR;
} else {
+monitor_protocol_event(QEVENT_MIGRATION_ENDED, NULL);
state = MIG_STATE_COMPLETED;
}
if (migrate_fd_cleanup(s) 0) {
@@ -400,6 +403,7 @@ void migrate_fd_cancel(MigrationState *mig_state)
DPRINTF(cancelling migration\n);
+monitor_protocol_event(QEVENT_MIGRATION_CANCELED, NULL);
s-state = MIG_STATE_CANCELLED;
qemu_savevm_state_cancel(s-mon, s-file);
@@ -413,6 +417,7 @@ void migrate_fd_release(MigrationState *mig_state)
DPRINTF(releasing state\n);
if (s-state == MIG_STATE_ACTIVE) {
+monitor_protocol_event(QEVENT_MIGRATION_CANCELED, NULL);
s-state = MIG_STATE_CANCELLED;
migrate_fd_cleanup(s);
}
--
1.6.6.1
Re: [Qemu-devel] [RFC PATCH 3/6] RAMBlock: Add a name field
Not all ram is associated with a device. Maybe not, but where it is we should be using that information. Absolute minimum we should be using the existing qdev address rather than inventing a new one. Duplicating this logic inside every device seems like a bad idea so I suggest identifying ram blocks by a (name, device) pair. For now we can allow a NULL device for system memory. I'm not sure if this is what you're after, but what if we change it to something like: +snprintf(name, sizeof(name), %s.%02x.%x.rom-%s, + pdev-bus-qbus.name, PCI_SLOT(pdev-devfn), + PCI_FUNC(pdev-devfn), pdev-qdev.info-name); This gives us things like pci.0.03.0.rom-rtl8139. For pci-assign, we can expand on the host details, such as: .. Giving us pci.0.04.0.bar0-pci-assign(:01:10.0). Anywhere closer? Not really. This identifier is device and bus independent, which is why I suggested passing the device to qemu_ram_alloc. This can then figure out how to the identify the device. It should probably do this the same way that we identify the saved state for the device. Currently I think this is an arbitrary vmstate name/id, but I expect this to change to a qdev address (e.g. /i440FX-pcihost/pci.0/_addr_04.0). Paul
Re: [Qemu-devel] Re: [RFC PATCH 3/6] RAMBlock: Add a name field
* Alex Williamson (alex.william...@redhat.com) wrote: +// XXX check duplicates Yes, definitely. You created a notion of a hierarchical namespace, can this be formalized any more? We already have one: The qdev tree. Paul
Re: [Qemu-devel] Disable PS/2 mouse
Gerd Hoffmann wrote: Hi, BUT. usb emulation is resource intensive. Update qemu. Fixed in 0.12.4 and unstable. hi gerd, with 0.12.4 it is still the case that a total idle vm takes about 6-8% of a 2.4GHz Xeon Core. see: http://dev.cs1.dlh.net/usb-on-off.png until approx 13.00 cet its with -usb -usbdevice tablet and after the reboot only with the ps/2 mouse. i'm fine generally not using the usb emulation for console only guest systems, but in that case I would like to disable ps/2 mouse as well. br, peter cheers, Gerd -- Mit freundlichen Grüßen/Kind Regards Peter Lieven .. KAMP Netzwerkdienste GmbH Vestische Str. 89-91 | 46117 Oberhausen Tel: +49 (0) 208.89 402-50 | Fax: +49 (0) 208.89 402-40 mailto:p...@kamp.de | http://www.kamp.de Geschäftsführer: Heiner Lante | Michael Lante Amtsgericht Duisburg | HRB Nr. 12154 USt-Id-Nr.: DE 120607556 .
Re: [Qemu-devel] Re: [PATCH 0/22] Refactor machine support
On 06/08/2010 09:11 PM, Paul Brook wrote: Because at some point the base tree will have to be written in C. No. You can start with a completely empty machine. We don't/shouldn't need any machine specific C code. I think you're missing the argument. I should be possible to create a machine entirely from a FDT or via -device options. However, to continue to support the interfaces that we support today, it will be necessary to have C code that manipulates a base device tree. When a user specifies '-M pc -hda foo.img' verses '-M versatilepb -hda foo.img', the equivalent are two very different operations on a device tree. The former adds an ide disk to the default controller and the later potentially creates a new scsi bus and then adds a disk to a specific bus. We could force users to these explicit operations instead of the generic options we provide today but we would certain end up having our users hate us as a result. When I submitted the original qdev code I also posted a proof-of-concept patch that built the whole machine based on a config file with no hardcoded knowledge of the machine structure. And in your proof-of-concept patches, you couldn't use -hda or any of the other command line options that are currently used. To support those things, something would have to understand the device tree well enough to know what -hda is supposed to mean. That's the point of MachineCore. Of course you have to decide where to stop allowing customization, but anyway it will be significantly more complex than a QemuOpts config file. QemuOpts obviously doesn't have the flexibility to create an entire device tree. Why not? The current -device option already provides the majority of the functionality required. Most of the missing bits are incomplete qdev conversion. I'm not saying that creating a whole machine via -device options is an elegant solution (hence the interest in things like FDT) but in I see no reason why it shouldn't work. IMO all uses of the no_user flag are bugs resulting from incomplete/incorrect qdev conversions. I don't disagree. Regards, Anthony Liguori
Re: [Qemu-devel] [RFC PATCH 3/6] RAMBlock: Add a name field
On 06/09/2010 06:58 AM, Avi Kivity wrote: On 06/09/2010 05:54 AM, Paul Brook wrote: On 06/08/2010 09:30 PM, Paul Brook wrote: The offset given to a block created via qemu_ram_alloc/map() is arbitrary, let the caller specify a name so we can make a positive match. @@ -1924,7 +1925,9 @@ static int pci_add_option_rom(PCIDevice *pdev) +snprintf(name, sizeof(name), pci:%02x.%x.rom, + PCI_SLOT(pdev-devfn), PCI_FUNC(pdev-devfn)); +pdev-rom_offset = qemu_ram_alloc(name, size); This looks pretty bogus. It should be associated with the device, rather than incorrectly trying to generate a globally unique name. Not all ram is associated with a device. Maybe not, but where it is we should be using that information. Absolute minimum we should be using the existing qdev address rather than inventing a new one. Duplicating this logic inside every device seems like a bad idea so I suggest identifying ram blocks by a (name, device) pair. For now we can allow a NULL device for system memory. I agree, this is duplicating the qdev tree in a string. Devices/BARs should have ram qdev fields and so ram can be enumerated completely via qdev. Keep in mind, this has to be a stable string across versions of qemu since this is savevm/migration. Are we absolutely confident that the full qdev path isn't going to change? I'm more confident that a unique device name is going to be static across qemu versions. Regards, Anthony Liguori System memory can be part of a system device.
Re: [Qemu-devel] [PATCH 4/8] target-mips: microMIPS ASE support
On Tue, Jun 08, 2010 at 01:29:59PM -0700, Nathan Froyd wrote:
Add instruction decoding for the microMIPS ASE. All we do is decode and
then forward to the existing gen_* routines.
Signed-off-by: Nathan Froyd froy...@codesourcery.com
---
target-mips/helper.h|9 +
target-mips/mips-defs.h |1 +
target-mips/op_helper.c | 136 +++
target-mips/translate.c | 2390
++-
4 files changed, 2531 insertions(+), 5 deletions(-)
diff --git a/target-mips/helper.h b/target-mips/helper.h
index ab47b1a..a6ba75d 100644
--- a/target-mips/helper.h
+++ b/target-mips/helper.h
@@ -160,6 +160,15 @@ DEF_HELPER_1(emt, tl, tl)
DEF_HELPER_1(dvpe, tl, tl)
DEF_HELPER_1(evpe, tl, tl)
#endif /* !CONFIG_USER_ONLY */
+
+/* microMIPS functions */
+DEF_HELPER_3(lwm, void, tl, tl, i32);
+DEF_HELPER_3(swm, void, tl, tl, i32);
+#ifdef TARGET_MIPS64
+DEF_HELPER_3(ldm, void, tl, tl, i32);
+DEF_HELPER_3(sdm, void, tl, tl, i32);
+#endif
+
DEF_HELPER_2(fork, void, tl, tl)
DEF_HELPER_1(yield, tl, tl)
diff --git a/target-mips/mips-defs.h b/target-mips/mips-defs.h
index c57de02..a7f4697 100644
--- a/target-mips/mips-defs.h
+++ b/target-mips/mips-defs.h
@@ -38,6 +38,7 @@
#define ASE_DSPR2 0x0001
#define ASE_MT 0x0002
#define ASE_SMARTMIPS 0x0004
+#define ASE_MICROMIPS 0x0008
/* Chip specific instructions. */
#define INSN_VR54XX 0x8000
diff --git a/target-mips/op_helper.c b/target-mips/op_helper.c
index 2bfdd50..56c5e59 100644
--- a/target-mips/op_helper.c
+++ b/target-mips/op_helper.c
@@ -565,6 +565,142 @@ void helper_sdr(target_ulong arg1, target_ulong arg2,
int mem_idx)
}
#endif /* TARGET_MIPS64 */
+static const int multiple_regs[] = { 16, 17, 18, 19, 20, 21, 22, 23, 30 };
+
+void helper_lwm (target_ulong addr, target_ulong reglist, uint32_t mem_idx)
+{
+target_ulong base_reglist = reglist 0xf;
+target_ulong do_r31 = reglist 0x10;
+#ifdef CONFIG_USER_ONLY
+#undef ldfun
+#define ldfun ldl_raw
+#else
+uint32_t (*ldfun)(target_ulong);
+
+switch (mem_idx)
+{
+case 0: ldfun = ldl_kernel; break;
+case 1: ldfun = ldl_super; break;
+default:
+case 2: ldfun = ldl_user; break;
+}
+#endif
+
+if (base_reglist 0 base_reglist = ARRAY_SIZE (multiple_regs)) {
+target_ulong i;
+
+for (i = 0; i base_reglist; i++) {
+env-active_tc.gpr[multiple_regs[i]] = (target_long) ldfun(addr);
+addr += 4;
+}
+}
+
+if (do_r31) {
+env-active_tc.gpr[31] = (target_long) ldfun(addr);
+}
+}
+
+void helper_swm (target_ulong addr, target_ulong reglist, uint32_t mem_idx)
+{
+target_ulong base_reglist = reglist 0xf;
+target_ulong do_r31 = reglist 0x10;
+#ifdef CONFIG_USER_ONLY
+#undef stfun
+#define stfun stl_raw
+#else
+void (*stfun)(target_ulong, uint32_t);
+
+switch (mem_idx)
+{
+case 0: stfun = stl_kernel; break;
+case 1: stfun = stl_super; break;
+ default:
+case 2: stfun = stl_user; break;
+}
+#endif
+
+if (base_reglist 0 base_reglist = ARRAY_SIZE (multiple_regs)) {
+target_ulong i;
+
+for (i = 0; i base_reglist; i++) {
+stfun(addr, env-active_tc.gpr[multiple_regs[i]]);
+addr += 4;
+}
+}
+
+if (do_r31) {
+stfun(addr, env-active_tc.gpr[31]);
+}
+}
+
+#if defined(TARGET_MIPS64)
+void helper_ldm (target_ulong addr, target_ulong reglist, uint32_t mem_idx)
+{
+target_ulong base_reglist = reglist 0xf;
+target_ulong do_r31 = reglist 0x10;
+#ifdef CONFIG_USER_ONLY
+#undef ldfun
+#define ldfun ldq_raw
+#else
+uint64_t (*ldfun)(target_ulong);
+
+switch (mem_idx)
+{
+case 0: ldfun = ldq_kernel; break;
+case 1: ldfun = ldq_super; break;
+default:
+case 2: ldfun = ldq_user; break;
+}
+#endif
+
+if (base_reglist 0 base_reglist = ARRAY_SIZE (multiple_regs)) {
+target_ulong i;
+
+for (i = 0; i base_reglist; i++) {
+env-active_tc.gpr[multiple_regs[i]] = ldfun(addr);
+addr += 8;
+}
+}
+
+if (do_r31) {
+env-active_tc.gpr[31] = ldfun(addr);
+}
+}
+
+void helper_sdm (target_ulong addr, target_ulong reglist, uint32_t mem_idx)
+{
+target_ulong base_reglist = reglist 0xf;
+target_ulong do_r31 = reglist 0x10;
+#ifdef CONFIG_USER_ONLY
+#undef stfun
+#define stfun stq_raw
+#else
+void (*stfun)(target_ulong, uint64_t);
+
+switch (mem_idx)
+{
+case 0: stfun = stq_kernel; break;
+case 1: stfun = stq_super; break;
+ default:
+case 2: stfun = stq_user; break;
+}
+#endif
+
+if (base_reglist 0 base_reglist = ARRAY_SIZE (multiple_regs)) {
+target_ulong i;
+
+for (i
Re: [Qemu-devel] [RFC PATCH 3/6] RAMBlock: Add a name field
Keep in mind, this has to be a stable string across versions of qemu since this is savevm/migration. Are we absolutely confident that the full qdev path isn't going to change? I'm more confident that a unique device name is going to be static across qemu versions. The actual representation of the device address is a secondary issue. The important point is that ram blocks should be associated with devices[*], and matched in exactly the same way. Devices should not be duplicating this on an ad-hoc basis. Paul [*] Ignore that we don't currently have a root system device node. A null device will suffice for now.
Re: [Qemu-devel] [PATCH] monitor: Add force option support to pci_del command
On Wed, Jun 9, 2010 at 4:38 AM, Gerd Hoffmann kra...@redhat.com wrote: On 06/09/10 07:37, Marcos Oviedo wrote: This adds a way to force the removal/unplug of previously added pci devices when ACPI-based hotplug mechanism is not present. Point being? If your guest can't handle pci hotplug it is pretty useless to plug in hardware in the first place. If your guest supports pci hotplug it will be quite upset if you zap the hardware without asking via ACPI. This make sense when you mistakenly add a pci device on a -s -S scenario, like the scenario described on the following bug: https://bugs.launchpad.net/qemu/+bug/544367. When ACPI-based hotplug support is present on the guest and we run pci_del with the force option, the hotplug events will still be generated to the guest and the guest still will trigger the EJx event, which will end by calling pciej_write() on qemu side. This function will do nothing on a -f and pci hotplug support scenario, as the pci device was previously removed by pci_del. Thanks! Marcos cheers, Gerd
Re: [Qemu-devel] [PATCH 0/8] target-mips: add microMIPS ASE support, v3
On Tue, Jun 08, 2010 at 01:29:55PM -0700, Nathan Froyd wrote:
This patch series adds support for the microMIPS ASE. microMIPS is a
new ASE similar to MIPS16, but re-encodes the entire instruction set
into 16-bit and 32-bit instructions--in contrast to MIPS16, which
re-encodes only integer instructions. The mechanisms for going in and
out of microMIPS mode are identical to those for MIPS16; a given chip
cannot support both ASEs simultaneously.
changes from v2:
give actual name to FOP constants; assign names to FOPs for c{,abs}
fix up coding style violations
fix helpers for recent ldl_*/stl_* prototype changes
split out mips16-related changes into separate patch
group patches more logically
changes from v1:
fix re-introduction of previously deleted code noted by rth
Nathan Froyd (8):
target-mips: define constants for magic numbers
target-mips: refactor c{,abs}.cond.fmt insns
target-mips: mips16 cleanups
target-mips: microMIPS ASE support
target-mips: add microMIPS CPUs
target-mips: add microMIPS exception handler support
linux-user: honor low bit of entry PC for MIPS
hw: honor low bit in mipssim machine
hw/mips_mipssim.c|5 +-
linux-user/main.c|5 +-
target-mips/cpu.h|1 +
target-mips/helper.c | 21 +-
target-mips/helper.h |9 +
target-mips/mips-defs.h |1 +
target-mips/op_helper.c | 136 ++
target-mips/translate.c | 3015
++
target-mips/translate_init.c | 61 +
9 files changed, 3009 insertions(+), 245 deletions(-)
I have applied all patches except the 5th one, see my comments about it.
I also have applied a complementary patch to the first one, that moves
FP FMT comments to a more appropriate place. It doesn't change any code.
Finally, I have made some comments about the 4th patch, that may be a
basis for future improvements.
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net
Re: [Qemu-devel] [PATCH 5/8] target-mips: add microMIPS CPUs
On Tue, Jun 08, 2010 at 01:30:00PM -0700, Nathan Froyd wrote:
Signed-off-by: Nathan Froyd froy...@codesourcery.com
---
target-mips/translate_init.c | 61
++
1 files changed, 61 insertions(+), 0 deletions(-)
diff --git a/target-mips/translate_init.c b/target-mips/translate_init.c
index b79ed56..8e17f4b 100644
--- a/target-mips/translate_init.c
+++ b/target-mips/translate_init.c
@@ -141,6 +141,25 @@ static const mips_def_t mips_defs[] =
.mmu_type = MMU_TYPE_FMT,
},
{
+.name = 4Km-micromips,
+.CP0_PRid = 0x00018300,
+/* Config1 implemented, fixed mapping MMU,
+ no virtual icache, uncached coherency. */
+.CP0_Config0 = MIPS_CONFIG0 | (MMU_TYPE_FMT CP0C0_MT),
+.CP0_Config1 = MIPS_CONFIG1 |
+ (0 CP0C1_IS) | (3 CP0C1_IL) | (1 CP0C1_IA) |
+ (0 CP0C1_DS) | (3 CP0C1_DL) | (1 CP0C1_DA),
+.CP0_Config2 = MIPS_CONFIG2,
+.CP0_Config3 = MIPS_CONFIG3,
+.SYNCI_Step = 32,
+.CCRes = 2,
+.CP0_Status_rw_bitmask = 0x1258FF17,
+.SEGBITS = 32,
+.PABITS = 32,
+.insn_flags = CPU_MIPS32R2 | ASE_MICROMIPS,
+.mmu_type = MMU_TYPE_FMT,
+},
+{
.name = 4KEcR1,
.CP0_PRid = 0x00018400,
.CP0_Config0 = MIPS_CONFIG0 | (MMU_TYPE_R4000 CP0C0_MT),
@@ -245,6 +264,25 @@ static const mips_def_t mips_defs[] =
.mmu_type = MMU_TYPE_R4000,
},
{
+.name = 24Kc-micromips,
+.CP0_PRid = 0x00019300,
+.CP0_Config0 = MIPS_CONFIG0 | (0x1 CP0C0_AR) |
+(MMU_TYPE_R4000 CP0C0_MT),
+.CP0_Config1 = MIPS_CONFIG1 | (15 CP0C1_MMU) |
+ (0 CP0C1_IS) | (3 CP0C1_IL) | (1 CP0C1_IA) |
+ (0 CP0C1_DS) | (3 CP0C1_DL) | (1 CP0C1_DA),
+.CP0_Config2 = MIPS_CONFIG2,
+.CP0_Config3 = MIPS_CONFIG3 | (0 CP0C3_VInt),
+.SYNCI_Step = 32,
+.CCRes = 2,
+/* No DSP implemented. */
+.CP0_Status_rw_bitmask = 0x1278FF1F,
+.SEGBITS = 32,
+.PABITS = 32,
+.insn_flags = CPU_MIPS32R2 | ASE_MICROMIPS,
+.mmu_type = MMU_TYPE_R4000,
+},
+{
.name = 24Kf,
.CP0_PRid = 0x00019300,
.CP0_Config0 = MIPS_CONFIG0 | (0x1 CP0C0_AR) |
@@ -269,6 +307,29 @@ static const mips_def_t mips_defs[] =
.mmu_type = MMU_TYPE_R4000,
},
{
+.name = 24Kf-micromips,
+.CP0_PRid = 0x00019300,
+.CP0_Config0 = MIPS_CONFIG0 | (0x1 CP0C0_AR) |
+(MMU_TYPE_R4000 CP0C0_MT),
+.CP0_Config1 = MIPS_CONFIG1 | (1 CP0C1_FP) | (15 CP0C1_MMU) |
+ (0 CP0C1_IS) | (3 CP0C1_IL) | (1 CP0C1_IA) |
+ (0 CP0C1_DS) | (3 CP0C1_DL) | (1 CP0C1_DA),
+.CP0_Config2 = MIPS_CONFIG2,
+.CP0_Config3 = MIPS_CONFIG3 | (0 CP0C3_VInt),
+.CP0_LLAddr_rw_bitmask = 0,
+.CP0_LLAddr_shift = 4,
+.SYNCI_Step = 32,
+.CCRes = 2,
+/* No DSP implemented. */
+.CP0_Status_rw_bitmask = 0x3678FF1F,
+.CP1_fcr0 = (1 FCR0_F64) | (1 FCR0_L) | (1 FCR0_W) |
+(1 FCR0_D) | (1 FCR0_S) | (0x93 FCR0_PRID),
+.SEGBITS = 32,
+.PABITS = 32,
+.insn_flags = CPU_MIPS32R2 | ASE_MICROMIPS,
+.mmu_type = MMU_TYPE_R4000,
+},
+{
.name = 34Kf,
.CP0_PRid = 0x00019500,
.CP0_Config0 = MIPS_CONFIG0 | (0x1 CP0C0_AR) |
None of those CPU seems to be real CPU. According to the MIPS website
(which BTW has very few details about microMIPS), the microMIPS ASE is
implemented in the M14K core, which seems to be a 4K core with R2 and
microMIPS support. Wouldn't it be better to add this one instead?
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net
Re: [Qemu-devel] [PATCH] monitor: Add force option support to pci_del command
Hi, This make sense when you mistakenly add a pci device on a -s -S scenario, like the scenario described on the following bug: https://bugs.launchpad.net/qemu/+bug/544367. It doesn't IMHO. When ACPI-based hotplug support is present on the guest and we run pci_del with the force option, the hotplug events will still be generated to the guest and the guest still will trigger the EJx event, which will end by calling pciej_write() on qemu side. This function will do nothing on a -f and pci hotplug support scenario, as the pci device was previously removed by pci_del. And in case the guest wants to do anything (like flushing dirty buffers) before triggering the EJx event it will horribly fail. If the guest is stopped while unplugging the device the unplug should happen as soon as the guest is unpaused. cheers, Gerd
Re: [Qemu-devel] Disable PS/2 mouse
Hi, with 0.12.4 it is still the case that a total idle vm takes about 6-8% of a 2.4GHz Xeon Core. I see that order of magitude too, no matter whenever usb is on or off. With older qemu and usbtablet it used to be up to 25%. cheers, Gerd
Re: [Qemu-devel] Re: [PATCH 0/22] Refactor machine support
Because at some point the base tree will have to be written in C. No. You can start with a completely empty machine. We don't/shouldn't need any machine specific C code. I think you're missing the argument. I should be possible to create a machine entirely from a FDT or via -device options. However, to continue to support the interfaces that we support today, it will be necessary to have C code that manipulates a base device tree. When a user specifies '-M pc -hda foo.img' verses '-M versatilepb -hda foo.img', the equivalent are two very different operations on a device tree. The former adds an ide disk to the default controller and the later potentially creates a new scsi bus and then adds a disk to a specific bus. AFAICS the current commandline options only result in simple addition of devices. They might add slightly different devices in slightly different places, but that's easy to accommodate by having the machine define a few standard device/bus IDs. IMO it's even more lame if -hda shops working when you supply a device tree. Paul
Re: [Qemu-devel] [PATCH v3 0/5] Add QMP migration events
Hi Juan, 2010/6/9 Juan Quintela quint...@redhat.com: This is a resent with what we agreed on yesterday call. Migration events would be there for 0.13 until we get proper async command support. Later, Juan. v3: - Add comment that MIGRATION_FAILURE will add a QError for 0.14 (when we get internal support for that) rebase against today tree v2: - Address pbonzini and mst changes (error messages and doc fixes) v1: This series does: - exit incoming migration on failure. For exec/fd migrations, once there was a failure, there was nothing useful to do. And for tcp migration, not exiting created interesting bugs when trying to migrate again to a process with a faild migration. - Factorize common migration code, no more duplication, makes easier to do global migration things, like QMP events. - Introduce QMP events, both for incoming and outgoing migration. Now, the million dollar question: Why I didn't refactorize outgoing migration? I tried, and have it partially done on my local tree. But it depends (too much) of current_migration global variable - Libvirt folks will also want info migrate to work on the incoming side, i.e. current_migraition has to also be updated on incoming side. Done until here, but then I hit the wall incoming migration is synchronous. To make the monitor work on incoming migration, we need to change buffered_file.c abstraction to also work for incoming fd's, or another similar solution. I am open to suggestions about what to do here. I don't know I have addressed the problem correctly, but here is my try to get info migrate on incoming side. http://lists.gnu.org/archive/html/qemu-devel/2010-06/msg00417.html Apart from that I have a concern on relation between newly introduced QMP Migration events and existing MIG_STATE_*. Are they supposed to be 1 to 1 mapping? If so, instead of calling monitor_protocol_event() everywhere, how about introducing a common function in migration that sets s-mig_state and emits QMP Migration events at once? Thanks, Yoshi This series are quite simple (the unfinished part is more complex), will send the other part as an RFC later. Please review and consider to apply it. Later, Juan. Juan Quintela (5): Exit if incoming migration fails Factorize common migration incoming code QMP: Introduce MIGRATION events QMP: Emit migration events on incoming migration QMP: Emit migration events on outgoing migration QMP/qmp-events.txt | 52 migration-exec.c | 17 +++-- migration-fd.c | 15 ++- migration-tcp.c | 17 - migration-unix.c | 17 - migration.c | 37 +++-- migration.h | 4 +++- monitor.c | 12 monitor.h | 4 vl.c | 7 ++- 10 files changed, 121 insertions(+), 61 deletions(-)
[Qemu-devel] Re: Live Migration of 32-bit Linux guest broken since 2.6.35-rc2
On 06/09/2010 11:29 AM, Peter Lieven wrote: Avi Kivity wrote: On 06/08/2010 04:44 PM, Peter Lieven wrote: -cpu host is good if you have identical machines and don't plan to add new ones. i will likely add new ones, but my plan would be to use qemu64 and then add all flags manually that are common to all cpus in the pool. would that be safe? Yes. 2 last questions: a) i remember that there (have been) are instructions that have a high virtualization penalty. are there flags that should better not be offered to a VM? Not that I know of. b) you told you fixed another bug in 2.6.35. is the nx virtualization not working in guests before 2.6.35 and therefore my case worked with 2.6.34? On 2.6.34, your guest lost nx protection after migration. On 2.6.35, it died. -- error compiling committee.c: too many arguments to function
[Qemu-devel] Re: Live Migration of 32-bit Linux guest broken since 2.6.35-rc2
On Wed, Jun 09, 2010 at 06:08:23PM +0300, Avi Kivity wrote: On 06/09/2010 11:29 AM, Peter Lieven wrote: Avi Kivity wrote: On 06/08/2010 04:44 PM, Peter Lieven wrote: -cpu host is good if you have identical machines and don't plan to add new ones. i will likely add new ones, but my plan would be to use qemu64 and then add all flags manually that are common to all cpus in the pool. would that be safe? Yes. 2 last questions: a) i remember that there (have been) are instructions that have a high virtualization penalty. are there flags that should better not be offered to a VM? Not that I know of. rdtscp? I think it's always emulated. -- Gleb.
[Qemu-devel] Re: Live Migration of 32-bit Linux guest broken since 2.6.35-rc2
On 06/09/2010 06:12 PM, Gleb Natapov wrote: a) i remember that there (have been) are instructions that have a high virtualization penalty. are there flags that should better not be offered to a VM? Not that I know of. rdtscp? I think it's always emulated. No, it executes natively. It does increase the msr switching cost since we need to switch MSR_TSC_AUX in addition. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] Re: KVM call minutes for June 8
On Tue, 08 Jun 2010 16:13:37 -0500 Anthony Liguori anth...@codemonkey.ws wrote: On 06/08/2010 03:59 PM, Luiz Capitulino wrote: Now, QError. This is something I think we should fix for 0.13. However, I still don't know how to get it right: most of what you say in the wiki page has already been discussed before. For example, you suggest the error object should be returned, this is probably a requirement to have async commands working, but this thread explains the problems we had with that: http://lists.gnu.org/archive/html/qemu-devel/2010-02/msg00818.html Sometimes we have to make difficult changes and touch a lot of code. There's really no other way and we're just going to have to grit our teeth and do it. Honestly, it's not that bad though having gone through much of the code at this point. Let's see, we should start working on this as soon as 0.13 is out. Another issue is that QErrors are getting too specific. I see two problems here, first how errors should be done and how to map errno properly, also already discussed: http://lists.gnu.org/archive/html/qemu-devel/2010-05/msg00314.html We're going to have to basically drop most of the QErrors we have today for 0.14 after we straighten out the error mess. Errors are pretty easy to deprecate and replace. All clients have to handle new types of errors so the worst thing that will happen is that they have less specific errors. Another problem is that a client might be waiting for a specific error that would never arrive. For example, say you wrote a shell and the CommandNotFound error is something expected to happen, this will break. Yes, well written clients should check the 'error' key first and won't panic if what they expect is not there. Even then, it's an annoying issue. What we can do to minimize the damage is: 1. Clearly state somewhere that errors are going to be removed 2. Keep errors undocumented (this turned out to be a feature!) The big problem is things like the block io error events. I don't see how we can support that given what we have in 0.13. Putting errno on the wire is a bad idea. We need to marshal a QError object using the __class__ memory to identify it as QError and pass that with the event. It could potentially be made to work for 0.13 but it'll be ugly. Yes, that's the main problem of the whole thing I think. From QEMU pov, the best thing to do would be to let this event as it's today and wait for the new QError (it's a compatible change, anyway). However, libvirt was counting on this feature and on the snapshot commands to switch from the text Monitor. We have two options: 1. Ask them to wait one more release (not so good for us) 2. Try to find a way to have those features in for 0.13 Daniel has commented to me that making the snapshot commands synchronous for 0.13 wouldn't be that bad, what do you think?
Re: [Qemu-devel] Re: KVM call minutes for June 8
On Wed, Jun 09, 2010 at 12:18:20PM -0300, Luiz Capitulino wrote: On Tue, 08 Jun 2010 16:13:37 -0500 Anthony Liguori anth...@codemonkey.ws wrote: On 06/08/2010 03:59 PM, Luiz Capitulino wrote: Now, QError. This is something I think we should fix for 0.13. However, I still don't know how to get it right: most of what you say in the wiki page has already been discussed before. For example, you suggest the error object should be returned, this is probably a requirement to have async commands working, but this thread explains the problems we had with that: http://lists.gnu.org/archive/html/qemu-devel/2010-02/msg00818.html Sometimes we have to make difficult changes and touch a lot of code. There's really no other way and we're just going to have to grit our teeth and do it. Honestly, it's not that bad though having gone through much of the code at this point. Let's see, we should start working on this as soon as 0.13 is out. Another issue is that QErrors are getting too specific. I see two problems here, first how errors should be done and how to map errno properly, also already discussed: http://lists.gnu.org/archive/html/qemu-devel/2010-05/msg00314.html We're going to have to basically drop most of the QErrors we have today for 0.14 after we straighten out the error mess. Errors are pretty easy to deprecate and replace. All clients have to handle new types of errors so the worst thing that will happen is that they have less specific errors. Another problem is that a client might be waiting for a specific error that would never arrive. For example, say you wrote a shell and the CommandNotFound error is something expected to happen, this will break. Yes, well written clients should check the 'error' key first and won't panic if what they expect is not there. Even then, it's an annoying issue. libvirt is even more paranoid than this. It checks for 'error' key being present, and if that's not present, it then also for the 'return' key not being present. What we can do to minimize the damage is: 1. Clearly state somewhere that errors are going to be removed 2. Keep errors undocumented (this turned out to be a feature!) The big problem is things like the block io error events. I don't see how we can support that given what we have in 0.13. Putting errno on the wire is a bad idea. We need to marshal a QError object using the __class__ memory to identify it as QError and pass that with the event. It could potentially be made to work for 0.13 but it'll be ugly. Yes, that's the main problem of the whole thing I think. From QEMU pov, the best thing to do would be to let this event as it's today and wait for the new QError (it's a compatible change, anyway). FYI, in terms of errors, libvirt currently relies on very little. When dealing with 'balloon' and 'query-balloon' we check for two explicit errors: class=DeviceNotActive class=KVMMissingCap in order to detect whether ballooning is supported in this guest. In all other cases, we simply pass the 'class' and 'desc' field back up to the libvirt error reporting code, and don't care what strings are in those fields. So if we add a whole lot more QErrors, or deprecate error codes the impact won't be serious apart from those two cases I mention. However, libvirt was counting on this feature and on the snapshot commands to switch from the text Monitor. We have two options: 1. Ask them to wait one more release (not so good for us) 2. Try to find a way to have those features in for 0.13 Daniel has commented to me that making the snapshot commands synchronous for 0.13 wouldn't be that bad, what do you think? The thought is that changing a command from synchronous to asynchronous is not an ABI incompatible change. An existing app simply won't know to take advantage of the new possibilities that async commands offer. Regards, Daniel -- |: Red Hat, Engineering, London-o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org-o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
Re: [Qemu-devel] [PATCH 0/8] target-mips: add microMIPS ASE support, v3
On Wed, Jun 09, 2010 at 04:10:25PM +0200, Aurelien Jarno wrote: On Tue, Jun 08, 2010 at 01:29:55PM -0700, Nathan Froyd wrote: This patch series adds support for the microMIPS ASE. microMIPS is a new ASE similar to MIPS16, but re-encodes the entire instruction set into 16-bit and 32-bit instructions--in contrast to MIPS16, which re-encodes only integer instructions. The mechanisms for going in and out of microMIPS mode are identical to those for MIPS16; a given chip cannot support both ASEs simultaneously. I have applied all patches except the 5th one, see my comments about it. Thanks for applying these. I agree with you about the 5th one and will submit a M14K patch in the next week. Finally, I have made some comments about the 4th patch, that may be a basis for future improvements. Indeed. I will work on that one. -Nathan
[Qemu-devel] Re: [RFC] Moving the kvm ioapic, pic, and pit back to userspace
On 06/09/2010 06:59 PM, Dong, Eddie wrote: Besides VF IO interrupt and timer interrupt introduced performance overhead risk, VF usually uses MSI EOI message deliver from lapic to ioapic, Only for non-MSI which becomes in user land now, may have potential scalability issue. For example, if we have a 64 VCPU guest, if each vcpu has 1khz interrupt (or ipi), the EOI from guest will normally have to involve ioapic module for clearance in 64khz which may have long lock contentio. No, EOI for IPI or for local APIC timer does not involve the IOAPIC. you may reduce the involvement of ioapic eoi by tracking ioapic pin- vector map in kernel, but not sure if it is clean enough. It's sufficient to look at TMR, no? For edge triggered I don't think we need the EOI. But, the amount of churn and risk worries me, so I don't think the move is worthwhile. -- error compiling committee.c: too many arguments to function
[Qemu-devel] Re: [PATCH v3 0/5] Add QMP migration events
Yoshiaki Tamura tamura.yoshi...@lab.ntt.co.jp wrote: Hi Juan, I don't know I have addressed the problem correctly, but here is my try to get info migrate on incoming side. http://lists.gnu.org/archive/html/qemu-devel/2010-06/msg00417.html I saw it, haven't had the time to look at it yet. Apart from that I have a concern on relation between newly introduced QMP Migration events and existing MIG_STATE_*. Are they supposed to be 1 to 1 mapping? Good question. In my tree I had info migrate being the same on source and destination, but I didn't have async migration. I have to check with yours. If so, instead of calling monitor_protocol_event() everywhere, how about introducing a common function in migration that sets s-mig_state and emits QMP Migration events at once? I did that locally, just that this is in the middle of a big cleanup. I am not sure that is still enough. We have: - qemu status: running/stopped - we have another state incoming migration that needs to be same level than running/stopped - I think MIG_STATE_* should also be promotted to this level, but haven't fully thought how to do it. Later, Juan.
[Qemu-devel] RE: [RFC] Moving the kvm ioapic, pic, and pit back to userspace
Avi Kivity wrote: I am currently investigating a problem with the a guest running Linux malfunctioning in the NMI watchdog code. The problem is that we don't handle NMI delivery mode for the local APIC LINT0 pin; instead we expect ExtInt deliver mode or that the line is disabled completely. In addition the i8254 timer is tied to the BSP, while in this case the timer can broadcast to all vcpus. There is some code that tries to second-guess the guest and provide it the inputs it sees, but this is fragile. The only way to get reliable operation is to emulate the hardware fully. Now I'd much rather do that in userspace, since it's a lot of sensitive work. I'll enumerate below the general motivation, advantages and disadvantages, and a plan for moving forward. Motivation == The original motivation for moving the PIC and IOAPIC into the kernel was performance, especially for assigned devices. Both devices are high interaction since they deal with interrupts; practically after every interrupt there is either a PIC ioport write, or an APIC bus message, both signalling an EOI operation. Moving the PIT into the kernel allowed us to catch up with missed timer interrupt injections, and speeded up guests which read the PIT counters (e.g. tickless guests). However, modern guests running on modern qemu use MSI extensively; both virtio and assigned devices now have MSI support; and the planned VFIO only supports kernel delivery via MSI anyway; line based interrupts will need to be mediated by userspace. The only high frequency non-MSI interrupt sources remaining are the various timers; and the default one, HPET, is in userspace (and having its own scaling problems as a result). So in theory we can move PIC, IOAPIC, and PIT support to userspace and not lose much performance. Moving the implementation to userspace allows us more flexibility, and more consistency in the implementation of timekeeping for the various clock chips; it becomes easier to follow the nuances of real hardware in this area. Interestingly, while the IOAPIC/PIC code was written we proposed making it independent of the local APIC; had we done so, the move would have been much easier (simply dropping the existing code). Advantages of a move 1. Reduced kernel footprint Good for security, and allows fixing bugs without reboots. 2. Centralized timekeeping Instead of having one solution for PIT timekeeping, and another for RTC and HPET timekeeping, we can have all timer chips in userspace. The local APIC timer still needs to be in the kernel - it is much too high bandwidth to be in userspace; but on the other hand it is very different from the other timer chips. 3. Flexibility Easier to have wierd board layouts (multiple IOAPICs, etc.). Not a very strong advantage. Disadvantages = 1. Still need to keep the old code around for a long while We can't just rip it out - old userspace depends on it. So the security advantages are only with cooperating userspace, and the other advantages only show up. 2. Need to bring the qemu code up to date The current qemu ioapic code lags some way behind the kernel; also need PIT timekeeping 3. May need kernel support for interval-timer-follows-thread Currently the timekeeping code has an optimization which causes the hrtimer that models the PIT to follow the BSP (which is most likely to receive the interrupt); this reduces cpu cross-talk. I don't think the kernel interval timer code has such an optimization; we may need to implement it. 4. Much churn This is a lot of work. 5. Risk We may find out after all this is implemented that performance is not acceptable and all the work will have to be dropped. Besides VF IO interrupt and timer interrupt introduced performance overhead risk, EOI message deliver from lapic to ioapic, which becomes in user land now, may have potential scalability issue. For example, if we have a 64 VCPU guest, if each vcpu has 1khz interrupt (or ipi), the EOI from guest will normally have to involve ioapic module for clearance in 64khz which may have long lock contentio. you may reduce the involvement of ioapic eoi by tracking ioapic pin - vector map in kernel, but not sure if it is clean enough.
Re: [Qemu-devel] Re: KVM call minutes for June 8
On 06/09/2010 10:31 AM, Daniel P. Berrange wrote: However, libvirt was counting on this feature and on the snapshot commands to switch from the text Monitor. We have two options: 1. Ask them to wait one more release (not so good for us) 2. Try to find a way to have those features in for 0.13 Daniel has commented to me that making the snapshot commands synchronous for 0.13 wouldn't be that bad, what do you think? The thought is that changing a command from synchronous to asynchronous is not an ABI incompatible change. An existing app simply won't know to take advantage of the new possibilities that async commands offer. It's not QMP that's the major issue with savevm. The major issue is actually the way snapshots are saved in qcow2. You need to know the size of the snapshot prior to creating the snapshot which is not possible if you want to make snapshots live. In order to support this functionality, we'll probably have to introduce a new snapshot format in qcow2. Honestly, I would recommend not supporting snapshots in libvirt until we did the work to make snapshots live. Snapshots can cause guests to generate errors as it stands today and fixing that will almost certainly result in backwards compatibility considerations. If we did put savevm in QMP today, we would need to provide an interface that let applications detect when we eventually fix this. Regards, Anthony Liguori Regards, Daniel
Re: [Qemu-devel] Re: KVM call minutes for June 8
On 06/09/2010 10:18 AM, Luiz Capitulino wrote: The big problem is things like the block io error events. I don't see how we can support that given what we have in 0.13. Putting errno on the wire is a bad idea. We need to marshal a QError object using the __class__ memory to identify it as QError and pass that with the event. It could potentially be made to work for 0.13 but it'll be ugly. Yes, that's the main problem of the whole thing I think. From QEMU pov, the best thing to do would be to let this event as it's today and wait for the new QError (it's a compatible change, anyway). I'd prefer that we just send the event with an embedded qerror (using __class__). We can generate it directly instead of using qerror_report/qerror_new. It's ugly but it'll work and be future compatible. For now, let's just support a few types of qerror to basically distinguish between an unknown io error and ENOSPC. However, libvirt was counting on this feature and on the snapshot commands to switch from the text Monitor. We have two options: I don't think snapshots are actually usable by libvirt in the current form. Regards, Anthony LIguori 1. Ask them to wait one more release (not so good for us) 2. Try to find a way to have those features in for 0.13 Daniel has commented to me that making the snapshot commands synchronous for 0.13 wouldn't be that bad, what do you think?
Re: [Qemu-devel] [STABLE PULL 0/6] Block patches for 0.12.x
On Fri, May 28, 2010 at 08:01:26PM +0200, Kevin Wolf wrote: The following changes since commit 0c459361a1117a6c434c7b2b008a4c6c035eb4bf: Rabin Vincent (1): arm_timer: fix oneshot mode are available in the git repository at: git://repo.or.cz/qemu/kevin.git for-stable-0.12 Kevin Wolf (6): ide: Fix ide_dma_cancel qcow2: Clear L2 table cache after write error qcow2: Fix error handling in l2_allocate block: Fix multiwrite with overlapping requests qcow2: Fix corruption after refblock allocation qcow2: Fix corruption after error in update_refcount block.c|2 +- block/qcow2-cluster.c | 26 +++--- block/qcow2-refcount.c | 15 +-- hw/ide/core.c |8 4 files changed, 33 insertions(+), 18 deletions(-) Thanks, all applied. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net
Re: [Qemu-devel] [Bug 589315] [NEW] qemu: Improve error reporting when migration can't connect
On 06/03/2010 05:41 PM, Yoshiaki Tamura wrote:
Hi,
Does the following patch fix the problem?
Thanks,
Yoshi
[PATCH] migration-tcp: call migrate_fd_error() instead of close() and free().
This patch fixes the following error report. When changing
migration-tcp.c to call migrate_fd_error() instead of close() and
free() by itself, monitor is resumed, and returns allocated mig_state
is set to current_migration in migration.c allows us to print info
migrate.
Reported-by: Cole Robinson crobi...@redhat.com
Signed-off-by: Yoshiaki Tamura tamura.yoshi...@lab.ntt.co.jp
--
qemu: Improve error reporting when migration can't connect
https://bugs.launchpad.net/bugs/589315
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
Status in QEMU: New
Bug description:
Tested with upstream qemu as of Jun 3 2010
If the source qemu instance can't connect to the migration destination (say
there is no listening QEMU instance, or port is blocked by a firewall), all we
get is info migrate - Migration status: failed. This is all we have to report
back to libvirt users if their firewall is misconfigured, which is crappy.
Ideally, if we can't connect, migration would fail immediately with a relevant
message and strerror(). More info from 'info migrate' would be nice too, no
idea how this will play with QMP though.
As a slightly related issue, try entering
migrate tcp:127.0.0.0:6000
We get a 'migration failed' error, and then the monitor hangs!
--
---
migration-tcp.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/migration-tcp.c b/migration-tcp.c
index 95ce722..43af2e0 100644
--- a/migration-tcp.c
+++ b/migration-tcp.c
@@ -128,9 +128,7 @@ MigrationState *tcp_start_outgoing_migration(Monitor *mon,
if (ret 0 ret != -EINPROGRESS ret != -EWOULDBLOCK) {
DPRINTF(connect failed\n);
-close(s-fd);
-qemu_free(s);
-return NULL;
+migrate_fd_error(s);
} else if (ret = 0)
migrate_fd_connect(s);
Yes, this fixes the monitor hang. Thanks!
- Cole
Re: [Qemu-devel] Re: KVM call minutes for June 8
On Wed, Jun 09, 2010 at 11:22:55AM -0500, Anthony Liguori wrote: On 06/09/2010 10:31 AM, Daniel P. Berrange wrote: However, libvirt was counting on this feature and on the snapshot commands to switch from the text Monitor. We have two options: 1. Ask them to wait one more release (not so good for us) 2. Try to find a way to have those features in for 0.13 Daniel has commented to me that making the snapshot commands synchronous for 0.13 wouldn't be that bad, what do you think? The thought is that changing a command from synchronous to asynchronous is not an ABI incompatible change. An existing app simply won't know to take advantage of the new possibilities that async commands offer. It's not QMP that's the major issue with savevm. The major issue is actually the way snapshots are saved in qcow2. You need to know the size of the snapshot prior to creating the snapshot which is not possible if you want to make snapshots live. In order to support this functionality, we'll probably have to introduce a new snapshot format in qcow2. Honestly, I would recommend not supporting snapshots in libvirt until we did the work to make snapshots live. Snapshots can cause guests to generate errors as it stands today and fixing that will almost certainly result in backwards compatibility considerations. Libvirt already supports savevm in the text mode monitor, hence the desire to have it work in QMP too. If we did put savevm in QMP today, we would need to provide an interface that let applications detect when we eventually fix this. The problem you describe sounds like an internal qcow2 implementation detail. The savevm related commands their parameters don't have anything that's inherantly tied to qcow2, so why would it affect QMP if qcow2 format changed internally ? Regards, Daniel -- |: Red Hat, Engineering, London-o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org-o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
Re: [Qemu-devel] [RFC PATCH 3/6] RAMBlock: Add a name field
On Wed, 2010-06-09 at 13:18 +0100, Paul Brook wrote: Not all ram is associated with a device. Maybe not, but where it is we should be using that information. Absolute minimum we should be using the existing qdev address rather than inventing a new one. Duplicating this logic inside every device seems like a bad idea so I suggest identifying ram blocks by a (name, device) pair. For now we can allow a NULL device for system memory. I'm not sure if this is what you're after, but what if we change it to something like: +snprintf(name, sizeof(name), %s.%02x.%x.rom-%s, + pdev-bus-qbus.name, PCI_SLOT(pdev-devfn), + PCI_FUNC(pdev-devfn), pdev-qdev.info-name); This gives us things like pci.0.03.0.rom-rtl8139. For pci-assign, we can expand on the host details, such as: .. Giving us pci.0.04.0.bar0-pci-assign(:01:10.0). Anywhere closer? Not really. This identifier is device and bus independent, which is why I suggested passing the device to qemu_ram_alloc. This can then figure out how to the identify the device. It should probably do this the same way that we identify the saved state for the device. Currently I think this is an arbitrary vmstate name/id, but I expect this to change to a qdev address (e.g. /i440FX-pcihost/pci.0/_addr_04.0). Ok, that seems fairly reasonable, so from a device pointer we can get something like /i440FX-pcihost/pci.0/_addr_04.0, then we can add something like :rom or :bar.0 to it via an extra string. qemu_ram_alloc(DeviceState *dev, const char *info, size) Does a function already exist to print out a qdev address path? I don't want to guess at something based on only this example. Is there a reserved/unused character we can use to separate the qdev device string from the supplied name? Thanks, Alex
[Qemu-devel] [Bug 586420] Re: WinXP install cd hangs at boot time if machine started with floppy
I wrote already which system I use (see the third reply). It's Gentoo on AMD64 with the hardened no-multilib profile with qemu-kvm 0.12.4 and SeaBIOS 0.5.1. It isn't really my own build. Since I use Gentoo, it was compiled on my own computer and it's installed in /usr, not in /usr/local. Qemu only gives an error if I use the -L parameter. Still, I can't boot any Windows XP and 2003 install CD. It definitely hangs at boot time, it happens anything in the cpu registers, only EIP and EFL are changing between these values: Command line : qemu-kvm -L /usr/share/qemu/ -cdrom /srv/vm/win2k3srv.iso -fda /srv/vm/virtio.img -boot d -enable-kvm -monitor stdio (qemu) info kvm kvm support: enabled (qemu) info registers EAX= EBX=02fe ECX=0002 EDX=0040 ESI= EDI=0004 EBP=0010 ESP=02e4 EIP=e919 EFL=00033246 [---Z-P-] CPL=3 II=0 A20=1 SMM=0 HLT=0 ES =0040 0400 f300 CS =f000 000f f300 SS =9f40 0009f400 f300 DS =9f40 0009f400 f300 FS =230c 000230c0 f300 GS =230c 000230c0 f300 LDT= TR =0028 feffd000 2088 8b00 GDT= 0003f000 03ff IDT= CR0=0010 CR2= CR3=00039000 CR4= DR0= DR1= DR2= DR3= DR6=0ff0 DR7=0400 FCW=037f FSW= [ST=0] FTW=00 MXCSR= FPR0= FPR1= FPR2= FPR3= FPR4= FPR5= FPR6= FPR7= XMM00= XMM01= XMM02= XMM03= XMM04= XMM05= XMM06= XMM07= (qemu) info registers EAX= EBX=02fe ECX=0002 EDX=0040 ESI= EDI=0004 EBP=0010 ESP=02e4 EIP=e91a EFL=00023046 [---Z-P-] CPL=3 II=0 A20=1 SMM=0 HLT=0 ES =0040 0400 f300 CS =f000 000f f300 SS =9f40 0009f400 f300 DS =9f40 0009f400 f300 FS =230c 000230c0 f300 GS =230c 000230c0 f300 LDT= TR =0028 feffd000 2088 8b00 GDT= 0003f000 03ff IDT= CR0=0010 CR2= CR3=00039000 CR4= DR0= DR1= DR2= DR3= DR6=0ff0 DR7=0400 FCW=037f FSW= [ST=0] FTW=00 MXCSR= FPR0= FPR1= FPR2= FPR3= FPR4= FPR5= FPR6= FPR7= XMM00= XMM01= XMM02= XMM03= XMM04= XMM05= XMM06= XMM07= By the way, I have trouble to compile the newest code of qemu.git, but that could be more a bug related to Portage's tree. The used make scripts are from the qemu.git source though. -- WinXP install cd hangs at boot time if machine started with floppy https://bugs.launchpad.net/bugs/586420 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: Incomplete Bug description: I have a second problem: I wanted to install Windows Server 2003 on a virtio drive, so I tried to start the machine with the install cd as the boot drive and a floppy image with the viostor drivers. The problem is, the install cd hangs at boot time. If I start VNC I just see a black ground with 640x480. I've also tried this with the install cd of Windows Server 2008 R2 and it works! Could it be that the BIOS screws up because the older install cds are using the floppy emulation to boot the setup?
[Qemu-devel] [Bug 586175] Re: Windows XP/2003 doesn't boot
Do you mean, I should try to install and boot Win2k3 without libvirt? If I install Windows through libvirt and boot it with a simple command line like qemu-kvm -hda /someimage.img -enable-kvm it doesn't boot. It's in fact this bug, just like Cole meant: https://bugzilla.redhat.com/show_bug.cgi?id=579348 Also interesting, if I use a raw image instead of a vdi image, the workaround (booting the install cd and let it hand over to the installed windows) doesn't work anymore. Now I'll set up another machine with gentoo and try all combinations of image file types, Windozes ( NT 6.0) and qemu options and I'll report the results. -- Windows XP/2003 doesn't boot https://bugs.launchpad.net/bugs/586175 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: Incomplete Status in Fedora: Unknown Bug description: Hello everyone, my qemu doesn't boot any Windows XP/2003 installations if I try to boot the image. If I boot the install cd first, it's boot manager counts down and triggers the boot on it's own. That's kinda stupid. I'm using libvirt, but even by a simple qemu-kvm -drive file=image.img,media=disk,if=ide,boot=on it won't boot. Qemu hangs at the message Booting from Hard Disk... I'm using qemu-kvm-0.12.4 with SeaBIOS 0.5.1 on Gentoo (No-Multilib and AMD64). It's a server, that means I'm using VNC as the primary graphic output but i don't think it should be an issue.
[Qemu-devel] [PATCH] Add an error_report when failing to open due to block-drv-whitelist
When configure qemu with --block-drv-whitelist we don't report when we are
blocked by the white list and the resulting error message is misleading:
./configure --target-list=x86_64-softmmu \
--block-drv-whitelist=qcow2,raw,host_device,host_cdrom
x86_64-softmmu/qemu-system-x86_64 -L pc-bios -m 512 -drive \
file=fedora9_32_20G.qcow2,if=ide -monitor stdio
qemu: could not open disk image fedora9_32_20G.qcow2: Inappropriate ioctl for
device
Which might lead one to look at the bdrv probe functions for floppy/cdrom
because we indeed will get an ioctl failure stored in errno and we report this
in vl.c when we get a non-zero return value from bdrv_open().
This patch adds an error report when we fail the whitelist and changes the errno
value to ENOPROTOOPT which was the closest thing I could think of that matched
the actual error.
Now we get the following output on whitelist failure:
x86_64-softmmu/qemu-system-x86_64 -L pc-bios -m 512 -drive \
file=fedora9_32_20G.qcow2,if=ide -monitor stdio
qemu-system-x86_64: -drive file=fedora9_32_20G.qcow2,if=ide:
block-drv-whitelist prevents using format 'file'
qemu: could not open disk image fedora9_32_20G.qcow2: Protocol not supported
Signed-off-by: Ryan Harper ry...@us.ibm.com
---
block.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/block.c b/block.c
index 39724c1..ffcf7f2 100644
--- a/block.c
+++ b/block.c
@@ -403,6 +403,9 @@ static int bdrv_open_common(BlockDriverState *bs, const
char *filename,
pstrcpy(bs-filename, sizeof(bs-filename), filename);
if (use_bdrv_whitelist !bdrv_is_whitelisted(drv)) {
+error_report(block-drv-whitelist prevents using format '%s',
drv-format_name);
+/* reset errno since we're failing because of whitelist restrictions */
+errno = EPROTONOSUPPORT;
return -ENOTSUP;
}
--
1.6.3.3
--
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
ry...@us.ibm.com
Re: [Qemu-devel] [PATCH] Add an error_report when failing to open due to block-drv-whitelist
On 06/09/2010 02:28 PM, Ryan Harper wrote:
When configure qemu with --block-drv-whitelist we don't report when we are
blocked by the white list and the resulting error message is misleading:
./configure --target-list=x86_64-softmmu \
--block-drv-whitelist=qcow2,raw,host_device,host_cdrom
x86_64-softmmu/qemu-system-x86_64 -L pc-bios -m 512 -drive \
file=fedora9_32_20G.qcow2,if=ide -monitor stdio
qemu: could not open disk image fedora9_32_20G.qcow2: Inappropriate ioctl for
device
Which might lead one to look at the bdrv probe functions for floppy/cdrom
because we indeed will get an ioctl failure stored in errno and we report this
in vl.c when we get a non-zero return value from bdrv_open().
This patch adds an error report when we fail the whitelist and changes the errno
value to ENOPROTOOPT which was the closest thing I could think of that matched
the actual error.
Now we get the following output on whitelist failure:
x86_64-softmmu/qemu-system-x86_64 -L pc-bios -m 512 -drive \
file=fedora9_32_20G.qcow2,if=ide -monitor stdio
qemu-system-x86_64: -drive file=fedora9_32_20G.qcow2,if=ide:
block-drv-whitelist prevents using format 'file'
qemu: could not open disk image fedora9_32_20G.qcow2: Protocol not supported
Do you really have to say raw and file in the whitelist? Is that what
the source of the problem is?
Regards,
Anthony Liguori
Signed-off-by: Ryan Harperry...@us.ibm.com
---
block.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/block.c b/block.c
index 39724c1..ffcf7f2 100644
--- a/block.c
+++ b/block.c
@@ -403,6 +403,9 @@ static int bdrv_open_common(BlockDriverState *bs, const
char *filename,
pstrcpy(bs-filename, sizeof(bs-filename), filename);
if (use_bdrv_whitelist !bdrv_is_whitelisted(drv)) {
+error_report(block-drv-whitelist prevents using format '%s',
drv-format_name);
+/* reset errno since we're failing because of whitelist restrictions */
+errno = EPROTONOSUPPORT;
return -ENOTSUP;
}
Re: [Qemu-devel] [PATCH] Add an error_report when failing to open due to block-drv-whitelist
* Anthony Liguori anth...@codemonkey.ws [2010-06-09 14:36]:
On 06/09/2010 02:28 PM, Ryan Harper wrote:
When configure qemu with --block-drv-whitelist we don't report when we are
blocked by the white list and the resulting error message is misleading:
./configure --target-list=x86_64-softmmu \
--block-drv-whitelist=qcow2,raw,host_device,host_cdrom
x86_64-softmmu/qemu-system-x86_64 -L pc-bios -m 512 -drive \
file=fedora9_32_20G.qcow2,if=ide -monitor stdio
qemu: could not open disk image fedora9_32_20G.qcow2: Inappropriate ioctl
for device
Which might lead one to look at the bdrv probe functions for floppy/cdrom
because we indeed will get an ioctl failure stored in errno and we report
this
in vl.c when we get a non-zero return value from bdrv_open().
This patch adds an error report when we fail the whitelist and changes the
errno
value to ENOPROTOOPT which was the closest thing I could think of that
matched
the actual error.
Now we get the following output on whitelist failure:
x86_64-softmmu/qemu-system-x86_64 -L pc-bios -m 512 -drive \
file=fedora9_32_20G.qcow2,if=ide -monitor stdio
qemu-system-x86_64: -drive file=fedora9_32_20G.qcow2,if=ide:
block-drv-whitelist prevents using format 'file'
qemu: could not open disk image fedora9_32_20G.qcow2: Protocol not
supported
Do you really have to say raw and file in the whitelist? Is that what
the source of the problem is?
I have to add 'file' to the whitelist string to get the above command
line to work.
Regards,
Anthony Liguori
Signed-off-by: Ryan Harperry...@us.ibm.com
---
block.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/block.c b/block.c
index 39724c1..ffcf7f2 100644
--- a/block.c
+++ b/block.c
@@ -403,6 +403,9 @@ static int bdrv_open_common(BlockDriverState *bs,
const char *filename,
pstrcpy(bs-filename, sizeof(bs-filename), filename);
if (use_bdrv_whitelist !bdrv_is_whitelisted(drv)) {
+error_report(block-drv-whitelist prevents using format '%s',
drv-format_name);
+/* reset errno since we're failing because of whitelist
restrictions */
+errno = EPROTONOSUPPORT;
return -ENOTSUP;
}
--
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
ry...@us.ibm.com
[Qemu-devel] [Bug 521994] Re: Windows 98 doesn't detect mouse on qemu and SeaBIOS.
I did find a workaround - I removed the BOCH BIOS package and QEMU package from my Lucid Install, and instead used the respective QEMU packages from 8.04 - this worked for me. I don't know if the most recent updates to the BIOS and QEMU packages will fix this or not - I might not try until I get confirmation that the new 10.04 packages are working. -- Windows 98 doesn't detect mouse on qemu and SeaBIOS. https://bugs.launchpad.net/bugs/521994 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: Confirmed Bug description: A windows 98 guest doesn't detect mouse on recent qemu. I bisected and the result is fd646122418ecefcde228d43821d07da79dd99bb is the first bad commit commit fd646122418ecefcde228d43821d07da79dd99bb Author: Anthony Liguori aligu...@us.ibm.com Date: Fri Oct 30 09:06:09 2009 -0500 Switch pc bios from pc-bios to seabios SeaBIOS is a port of pc-bios to GCC. Besides using a more modern tool chain, SeaBIOS introduces a number of new features including PMM support, better BEV and BCV support, and better PnP support. Signed-off-by: Anthony Liguori aligu...@us.ibm.com I got following messages with DEBUG_BIOS Start bios (version 0.5.1-20100111_132716-squirrel.codemonkey.ws) Ram Size=0x0800 (0x high) CPU Mhz=2271 Found 1 cpu(s) max supported 1 cpu(s) PIIX3/PIIX4 init: elcr=00 0c PCI: bus=0 devfn=0x00: vendor_id=0x8086 device_id=0x1237 PCI: bus=0 devfn=0x08: vendor_id=0x8086 device_id=0x7000 PCI: bus=0 devfn=0x09: vendor_id=0x8086 device_id=0x7010 region 4: 0xc000 PCI: bus=0 devfn=0x0b: vendor_id=0x8086 device_id=0x7113 PCI: bus=0 devfn=0x10: vendor_id=0x1013 device_id=0x00b8 region 0: 0xe000 region 1: 0xe200 region 6: 0xe201 MP table addr=0x000f89b0 MPC table addr=0x000f89c0 size=224 SMBIOS ptr=0x000f8990 table=0x07fffef0 ACPI tables: RSDP=0x000f8960 RSDT=0x07ffde30 Scan for VGA option rom Running option rom at c000:0003 VGABios $Id$ Turning on vga console Starting SeaBIOS (version 0.5.1-20100111_132716-squirrel.codemonkey.ws) Found 0 lpt ports Found 0 serial ports ATA controller 0 at 1f0/3f4/c000 (irq 14 dev 9) ATA controller 1 at 170/374/c008 (irq 15 dev 9) ps2 irq but no data. ata0-0: PCHS=812/16/63 translation=none LCHS=812/16/63 ata0-1: PCHS=1152/16/56 translation=none LCHS=1024/16/56 ps2_recvbyte timeout keyboard initialized Scan for option roms Returned 53248 bytes of ZoneHigh e820 map has 6 items: 0: - 0009f400 = 1 1: 0009f400 - 000a = 2 2: 000f - 0010 = 2 3: 0010 - 07ffd000 = 1 4: 07ffd000 - 0800 = 2 5: fffc - 0001 = 2 enter handle_19: NULL Booting from Hard Disk... Booting from :7c00 pnp call arg1=5 pnp call arg1=0 ps2_recvbyte timeout ps2_recvbyte timeout ps2_recvbyte timeout ps2_recvbyte timeout
[Qemu-devel] Re: sun framebuffer selection (was option-rom)
On Sun, Jun 6, 2010 at 4:28 PM, Artyom Tarasenko atar4q...@googlemail.com wrote: 2010/6/6 Blue Swirl blauwir...@gmail.com: On Sat, Jun 5, 2010 at 11:10 PM, Bob Breuer breu...@mc.net wrote: Blue Swirl wrote: but again: should we have a new machine with cg14 or some switch to select TCX vs. cg14? Why not just probe for both devices? OpenBIOS has the intention to run one day on a real hardware, doesn't it? I don't think it's very interesting for old hardware. Also coreboot may be a better platform (with OpenBIOS as a payload). Maybe the recently proposed machine subtype patches could help here. How is the graphic card different from cpu or a disk drive? It isn't. Well, let's try to figure out a method of selecting the framebuffer type. I'll try to list some of the options, even if they might be ridiculous. 1) Use the -vga option. I know TCX and cg14 are not vga, but I think it's the closest existing command line option available. 2) Switch based on the -g WxH option. At the moment, the TCX emulation doesn't really handle anything other than 1024x768, so switch to cg14 for other resolutions if supported. 3) Use some other existing command line option, -device, -set or -global? Might work, but the syntax may not be easy to remember. We don't have an equivalent of -chardev, -netdev and -drive for displays. I guess only cause the other emulated platforms don't have that much of choice (yet). Why not use just the generic -device option? Then there would be two graphics devices. There should be something like -displaydev SDL,id=1 -displaydev SDL,id=2 -device cg14,display=1 -device TCX,display=2. 4) Machine subtype. 5) New command line option. Anything above might be better. 6) New machine type. Is it a big enough feature to demand it's own machine type? Maybe, but see next option. 7) Select as default video for SS-20. The SS-10 and SS-600MP are already very similar. This would allow for some differentiation between the machines, but there could still be an option to switch back to TCX. Note that TCX was really only available for the SS-4 and SS-5. They are similar in qemu. But it's rather a bug than a feature. The real SS-600 is much more complex VME-bus machine. Is there anything else that I missed? Combined 7 6: make cg14 default for SS-20, add a deprecated compatibility machine for SS-20 with TCX. I'm going to go ahead with option 2 in the short term. I'm inclined to narrow it down to options 1, 4, and 7. I know that 7 would have backwards compatibility concerns. The cg14 seems to have at least the same capabilities as TCX so there shouldn't be any loss of functionality. Even though SS-20 is not the default machine, do you know of any OS that works with the sun4m implementation today but doesn't have a cg14 driver? Possible downside to cg14 for video is that any acceleration is handled by the SX pixel processor which has no available documentation. TCX also has some amount of unimplemented acceleration. It would be nice to use some basic device with well defined acceleration or just a frame buffer as default. AFAIK the open source OSes don't use the cg14 acceleration anyway. So we'll only have potential problems with Solaris and NeXTStep here. -- Regards, Artyom Tarasenko solaris/sparc under qemu blog: http://tyom.blogspot.com/
Re: [Qemu-devel] [PATCH 01/19] Add support for JSON pretty printing
On Mon, 7 Jun 2010 15:42:14 +0100
Daniel P. Berrange berra...@redhat.com wrote:
The monitor does not pretty-print JSON output, so that everything
will be on a single line reply. When JSON docs get large this is
quite unpleasant to read. For the future command line capabilities
query ability, huge JSON docs will be available. This needs the
ability to pretty-print.
This introduces a new API qobject_to_json_pretty() that does
a minimal indentation of list and dict members. As an example,
this makes
{QMP: {version: {micro: 50, minor: 12, package: , major: 0},
capabilities: []}}
Output as
{
QMP: {
version: {
micro: 50,
minor: 12,
package: ,
major: 0
},
capabilities: [
]
}
}
NB: this is not turned on for the QMP monitor.
Signed-off-by: Daniel P. Berrange berra...@redhat.com
---
qjson.c | 55 +++
qjson.h |1 +
2 files changed, 48 insertions(+), 8 deletions(-)
diff --git a/qjson.c b/qjson.c
index 483c667..f402103 100644
--- a/qjson.c
+++ b/qjson.c
@@ -72,43 +72,57 @@ QObject *qobject_from_jsonf(const char *string, ...)
typedef struct ToJsonIterState
{
+int indent;
+int pretty;
int count;
QString *str;
} ToJsonIterState;
-static void to_json(const QObject *obj, QString *str);
+static void to_json(const QObject *obj, QString *str, int pretty, int
indent);
static void to_json_dict_iter(const char *key, QObject *obj, void *opaque)
{
ToJsonIterState *s = opaque;
QString *qkey;
+int j;
-if (s-count) {
+if (s-count)
qstring_append(s-str, , );
+
+if (s-pretty) {
+qstring_append(s-str, \n);
+for (j = 0 ; j s-indent ; j++)
+qstring_append(s-str, );
}
qkey = qstring_from_str(key);
-to_json(QOBJECT(qkey), s-str);
+to_json(QOBJECT(qkey), s-str, s-pretty, s-indent);
QDECREF(qkey);
qstring_append(s-str, : );
-to_json(obj, s-str);
+to_json(obj, s-str, s-pretty, s-indent);
s-count++;
}
static void to_json_list_iter(QObject *obj, void *opaque)
{
ToJsonIterState *s = opaque;
+int j;
-if (s-count) {
+if (s-count)
qstring_append(s-str, , );
+
+if (s-pretty) {
+qstring_append(s-str, \n);
Nitpick: we also have qstring_append_chr()
+for (j = 0 ; j s-indent ; j++)
+qstring_append(s-str, );
}
-to_json(obj, s-str);
+to_json(obj, s-str, s-pretty, s-indent);
s-count++;
}
-static void to_json(const QObject *obj, QString *str)
+static void to_json(const QObject *obj, QString *str, int pretty, int indent)
{
switch (qobject_type(obj)) {
case QTYPE_QINT: {
@@ -190,8 +204,16 @@ static void to_json(const QObject *obj, QString *str)
s.count = 0;
s.str = str;
+s.indent = indent + 1;
+s.pretty = pretty;
qstring_append(str, {);
qdict_iter(val, to_json_dict_iter, s);
+if (pretty) {
+int j;
+qstring_append(str, \n);
+for (j = 0 ; j indent ; j++)
+qstring_append(str, );
+}
qstring_append(str, });
break;
}
@@ -201,8 +223,16 @@ static void to_json(const QObject *obj, QString *str)
s.count = 0;
s.str = str;
+s.indent = indent + 1;
+s.pretty = pretty;
qstring_append(str, [);
qlist_iter(val, (void *)to_json_list_iter, s);
+if (pretty) {
+int j;
+qstring_append(str, \n);
+for (j = 0 ; j indent ; j++)
+qstring_append(str, );
+}
qstring_append(str, ]);
break;
}
@@ -246,7 +276,16 @@ QString *qobject_to_json(const QObject *obj)
{
QString *str = qstring_new();
-to_json(obj, str);
+to_json(obj, str, 0, 0);
+
+return str;
+}
+
+QString *qobject_to_json_pretty(const QObject *obj)
+{
+QString *str = qstring_new();
+
+to_json(obj, str, 1, 0);
return str;
}
diff --git a/qjson.h b/qjson.h
index 7afec2e..cd60e0b 100644
--- a/qjson.h
+++ b/qjson.h
@@ -24,5 +24,6 @@ QObject *qobject_from_jsonf(const char *string, ...)
QObject *qobject_from_jsonv(const char *string, va_list *ap);
QString *qobject_to_json(const QObject *obj);
+QString *qobject_to_json_pretty(const QObject *obj);
#endif /* QJSON_H */
Re: [Qemu-devel] [PATCH 03/19] Add enum handlers for easy efficient string - int conversion
On Mon, 7 Jun 2010 15:42:16 +0100
Daniel P. Berrange berra...@redhat.com wrote:
There is quite alot of code using an enumeration of possible
values, which also needs todo conversions to/from a string
representation of enum values. These string - int conversions
have been repeated in an adhoc manner throughout the code.
This makes it hard to report on the list of valid strings,
eg in help output, or todo proper validation in the qemu
config/option parsing routines.
This addresses the first problem by introducing a standard
set of routines for performing string - int conversions
for enums. There are two restrictions on using these helpers,
the first enum value must be 0, and there must be a sentinal
in the enum to provide the max value.
For each enumeration, three functions will be made available
- string to int convertor:
int _from_string(const char *value);
Returns -1 if the value was not an allowed string for the
enumeration. Returns = 0 for a valid value
- int to string convertor
const char * _to_string(int value);
Returns NULL if the value was not a member of the
enumeration. Returns a non-NULL sstring for valid value
- string list generator
char * _to_string_list(void);
Returns a malloc'd string containing all valid values,
separated by commas. Caller must free the string.
The general usage pattern is as follows.
In the header file (eg qemu-option.h):
enum QemuOptType {
QEMU_OPT_STRING = 0, /* no parsing (use string as-is)
*/
QEMU_OPT_BOOL,/* on/off
*/
QEMU_OPT_NUMBER, /* simple number
*/
QEMU_OPT_SIZE,/* size, accepts (K)ilo, (M)ega, (G)iga, (T)era
postfix */
QEMU_OPT_LAST
};
QEMU_ENUM_DECL(qemu_opt_type);
This declares the function prototypes for the 3 methods
outlined above.
In the corresponding source file (eg qemu-option.c):
QEMU_ENUM_IMPL(qemu_opt_type,
QEMU_OPT_LAST,
string, bool, number, size);
This provides the implementation of the 3 methods. If there
are greater/fewer strings provided than the number of values
in the enumeration, this generates a compile time assertion
failure that looks like
qemu-option.c:35: error: negative width in bit-field
‘verify_error_if_negative_size__’
Signed-off-by: Daniel P. Berrange berra...@redhat.com
---
Makefile.objs |2 +-
qemu-enum.c | 44
qemu-enum.h | 45 +
3 files changed, 90 insertions(+), 1 deletions(-)
create mode 100644 qemu-enum.c
create mode 100644 qemu-enum.h
diff --git a/Makefile.objs b/Makefile.objs
index 9796dcb..0ba9966 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -8,7 +8,7 @@ qobject-obj-y += qerror.o
# block-obj-y is code used by both qemu system emulation and qemu-img
block-obj-y = cutils.o cache-utils.o qemu-malloc.o qemu-option.o module.o
-block-obj-y += nbd.o block.o aio.o aes.o osdep.o qemu-config.o
+block-obj-y += nbd.o block.o aio.o aes.o osdep.o qemu-config.o qemu-enum.o
block-obj-$(CONFIG_POSIX) += posix-aio-compat.o
block-obj-$(CONFIG_LINUX_AIO) += linux-aio.o
diff --git a/qemu-enum.c b/qemu-enum.c
new file mode 100644
index 000..9bb33ac
--- /dev/null
+++ b/qemu-enum.c
@@ -0,0 +1,44 @@
+#include qemu-enum.h
Missing license text.
+
+int qemu_enum_from_string(const char *const*types,
+ unsigned int ntypes,
+ const char *type)
+{
+unsigned int i;
+if (!type)
+return -1;
+
+for (i = 0 ; i ntypes ; i++)
+if (strcmp(types[i], type) == 0)
+return i;
+
+return -1;
+}
+
+const char *qemu_enum_to_string(const char *const*types,
+ unsigned int ntypes,
+ int type)
+{
+if (type 0 || type = ntypes)
+return NULL;
+
+return types[type];
+}
+
+char *qemu_enum_to_string_list(const char *const*types,
+unsigned int ntypes)
+{
+size_t len = 0;
+char *ret;
+int i;
+for (i = 0 ; i ntypes ; i++)
+ len += strlen(types[i]) + 2;
+ret = qemu_malloc(len);
+*ret = '\0';
+for (i = 0 ; i ntypes ; i++) {
+ if (i 0)
+ strcat(ret, , );
+ strcat(ret, types[i]);
+}
+return ret;
+}
diff --git a/qemu-enum.h b/qemu-enum.h
new file mode 100644
index 000..ff47798
--- /dev/null
+++ b/qemu-enum.h
@@ -0,0 +1,45 @@
+#ifndef QEMU_ENUM_H
+#define QEMU_ENUM_H
+
+#include qemu-common.h
+#include verify.h
+
+
+int qemu_enum_from_string(const char *const*types,
+ unsigned int ntypes,
+ const char *type);
+
+const char *qemu_enum_to_string(const
Re: [Qemu-devel] [PATCH 06/19] Convert drive options to use enumeration data type
On Mon, 7 Jun 2010 15:42:19 +0100
Daniel P. Berrange berra...@redhat.com wrote:
This converts the drive options if, trans, media, cache, aio,
rerror and werror to use the QEMU_OPT_ENUM datatype. This
standardizes the string parsing and error reporting
$ qemu -drive file=foo,werror=stop3
qemu: -drive file=foo,if=mtd,werror=stop3: Parameter 'werror' expects
report, ignore, enospc, stop
$ qemu -readconfig bar.cfg
qemu:bar.cfg:6: Parameter 'werror' expects report, ignore, enospc, stop
read config bar.cfg: Invalid argument
* block.c: Implementations for all enumerations
* block.h, sysemu.h: Declare enumerations
* qemu-config.c: Convert if, trans, media, cache, aio,
rerror and werror to use the QEMU_OPT_ENUM
* vl.c: Remove handcrafted string - int conversions in drive_init
Signed-off-by: Daniel P. Berrange berra...@redhat.com
---
block.c | 32 +++-
block.h | 55 +---
hw/qdev.c |2 +-
qemu-config.c | 73 +++---
sysemu.h | 23 +++--
vl.c | 162
-
6 files changed, 197 insertions(+), 150 deletions(-)
diff --git a/block.c b/block.c
index 39724c1..7ca55e2 100644
--- a/block.c
+++ b/block.c
@@ -27,6 +27,7 @@
#include block_int.h
#include module.h
#include qemu-objects.h
+#include sysemu.h
#ifdef CONFIG_BSD
#include sys/types.h
@@ -42,6 +43,22 @@
#include windows.h
#endif
+QEMU_ENUM_IMPL(bdrv_type, BDRV_TYPE_LAST,
+ hd, cdrom, floppy);
+QEMU_ENUM_IMPL(bdrv_bios_ata_translation, BIOS_ATA_TRANSLATION_LAST,
+ auto, none, lba, large, rechs);
+QEMU_ENUM_IMPL(bdrv_cache, BDRV_CACHE_LAST,
+ none, off, writeback, writethrough, unsafe);
+QEMU_ENUM_IMPL(bdrv_if_type, IF_LAST,
+ none, ide, scsi, floppy, pflash,
+ mtd, sd, virtio, xen);
+QEMU_ENUM_IMPL(bdrv_if_error_action, BLOCK_ERR_LAST,
+ report, ignore, enospc, stop);
+QEMU_ENUM_IMPL(bdrv_media, BDRV_MEDIA_LAST,
+ disk, cdrom);
+QEMU_ENUM_IMPL(bdrv_aio, BDRV_AIO_LAST,
+ native, threads);
+
static BlockDriverAIOCB *bdrv_aio_readv_em(BlockDriverState *bs,
int64_t sector_num, QEMUIOVector *qiov, int nb_sectors,
BlockDriverCompletionFunc *cb, void *opaque);
@@ -1454,19 +1471,8 @@ void bdrv_info(Monitor *mon, QObject **ret_data)
QTAILQ_FOREACH(bs, bdrv_states, list) {
QObject *bs_obj;
-const char *type = unknown;
-
-switch(bs-type) {
-case BDRV_TYPE_HD:
-type = hd;
-break;
-case BDRV_TYPE_CDROM:
-type = cdrom;
-break;
-case BDRV_TYPE_FLOPPY:
-type = floppy;
-break;
-}
+const char *type = bdrv_type_to_string(bs-type);
+assert(type != NULL);
'unknown' has to be dropped from query-block's documentation in
qemu-monitor.hx too.
bs_obj = qobject_from_jsonf({ 'device': %s, 'type': %s,
'removable': %i, 'locked': %i },
diff --git a/block.h b/block.h
index 756670d..11a029b 100644
--- a/block.h
+++ b/block.h
@@ -4,6 +4,7 @@
#include qemu-aio.h
#include qemu-common.h
#include qemu-option.h
+#include qemu-enum.h
#include qobject.h
/* block.c */
@@ -128,14 +129,52 @@ int bdrv_has_zero_init(BlockDriverState *bs);
int bdrv_is_allocated(BlockDriverState *bs, int64_t sector_num, int
nb_sectors,
int *pnum);
-#define BDRV_TYPE_HD 0
-#define BDRV_TYPE_CDROM 1
-#define BDRV_TYPE_FLOPPY 2
-#define BIOS_ATA_TRANSLATION_AUTO 0
-#define BIOS_ATA_TRANSLATION_NONE 1
-#define BIOS_ATA_TRANSLATION_LBA2
-#define BIOS_ATA_TRANSLATION_LARGE 3
-#define BIOS_ATA_TRANSLATION_RECHS 4
+enum {
+BDRV_TYPE_HD,
+BDRV_TYPE_CDROM,
+BDRV_TYPE_FLOPPY,
+
+BDRV_TYPE_LAST
+};
+QEMU_ENUM_DECL(bdrv_type);
+
+enum {
+BIOS_ATA_TRANSLATION_AUTO,
+BIOS_ATA_TRANSLATION_NONE,
+BIOS_ATA_TRANSLATION_LBA,
+BIOS_ATA_TRANSLATION_LARGE,
+BIOS_ATA_TRANSLATION_RECHS,
+
+BIOS_ATA_TRANSLATION_LAST
+};
+QEMU_ENUM_DECL(bdrv_bios_ata_translation);
+
+enum {
+BDRV_CACHE_NONE,
+BDRV_CACHE_OFF,
+BDRV_CACHE_WRITEBACK,
+BDRV_CACHE_WRITETHROUGH,
+BDRV_CACHE_UNSAFE,
+
+BDRV_CACHE_LAST
+};
+QEMU_ENUM_DECL(bdrv_cache);
+
+enum {
+BDRV_MEDIA_DISK,
+BDRV_MEDIA_CDROM,
+
+BDRV_MEDIA_LAST
+};
+QEMU_ENUM_DECL(bdrv_media);
+
+enum {
+BDRV_AIO_NATIVE,
+BDRV_AIO_THREADS,
+
+BDRV_AIO_LAST
+};
+QEMU_ENUM_DECL(bdrv_aio);
void bdrv_set_geometry_hint(BlockDriverState *bs,
int cyls, int heads, int secs);
diff --git a/hw/qdev.c b/hw/qdev.c
index aa2ce01..1186dfa 100644
--- a/hw/qdev.c
+++ b/hw/qdev.c
@@ -414,7 +414,7 @@ void
Re: [Qemu-devel] [PATCH 08/19] Convert RTC to use enumerations for configuration parameters
On Mon, 7 Jun 2010 15:42:21 +0100
Daniel P. Berrange berra...@redhat.com wrote:
Convert the rtc clock and driftfix parameters to use enums for
configuration. This ensures strict validation at time of config
parsing.
Also fixes a bug in qemu-config.c where 'driftfix' was never
enabled because this is a target independant compliation unit,
thus cannot include config-target.h and thus never has the
TARGET_I386 symbol defined.
Ideally the 'base' parameter would be an enum too, but this
value is overloaded to also accept a pretty-printed start
date.
Signed-off-by: Daniel P. Berrange berra...@redhat.com
---
hw/mc146818rtc.c |8
qemu-config.c| 27 +++
sysemu.h | 20 +++-
vl.c | 34 ++
4 files changed, 56 insertions(+), 33 deletions(-)
diff --git a/hw/mc146818rtc.c b/hw/mc146818rtc.c
index c3e6a70..cbb072c 100644
--- a/hw/mc146818rtc.c
+++ b/hw/mc146818rtc.c
@@ -202,7 +202,7 @@ static void rtc_periodic_timer(void *opaque)
if (s-cmos_data[RTC_REG_B] REG_B_PIE) {
s-cmos_data[RTC_REG_C] |= 0xc0;
#ifdef TARGET_I386
-if(rtc_td_hack) {
+if(rtc_driftfix == QEMU_RTC_DRIFTFIX_SLEW) {
if (s-irq_reinject_on_ack_count = RTC_REINJECT_ON_ACK_COUNT)
s-irq_reinject_on_ack_count = 0;
apic_reset_irq_delivered();
@@ -552,7 +552,7 @@ static int rtc_post_load(void *opaque, int version_id)
RTCState *s = opaque;
if (version_id = 2) {
-if (rtc_td_hack) {
+if (rtc_driftfix == QEMU_RTC_DRIFTFIX_SLEW) {
rtc_coalesced_timer_update(s);
}
}
@@ -597,7 +597,7 @@ static void rtc_reset(void *opaque)
qemu_irq_lower(s-irq);
#ifdef TARGET_I386
-if (rtc_td_hack)
+if (rtc_driftfix == QEMU_RTC_DRIFTFIX_SLEW)
s-irq_coalesced = 0;
#endif
}
@@ -619,7 +619,7 @@ static int rtc_initfn(ISADevice *dev)
s-periodic_timer = qemu_new_timer(rtc_clock, rtc_periodic_timer, s);
#ifdef TARGET_I386
-if (rtc_td_hack)
+if (rtc_driftfix == QEMU_RTC_DRIFTFIX_SLEW)
s-coalesced_timer =
qemu_new_timer(rtc_clock, rtc_coalesced_timer, s);
#endif
diff --git a/qemu-config.c b/qemu-config.c
index f656e6b..75cddc1 100644
--- a/qemu-config.c
+++ b/qemu-config.c
@@ -288,6 +288,11 @@ QemuOptsList qemu_net_opts = {
},
};
+QEMU_ENUM_IMPL(qemu_rtc_clock, QEMU_RTC_CLOCK_LAST,
+host, guest);
+QEMU_ENUM_IMPL(qemu_rtc_driftfix, QEMU_RTC_DRIFTFIX_LAST,
+none, slew);
+
QemuOptsList qemu_rtc_opts = {
.name = rtc,
.head = QTAILQ_HEAD_INITIALIZER(qemu_rtc_opts.head),
@@ -297,12 +302,26 @@ QemuOptsList qemu_rtc_opts = {
.type = QEMU_OPT_STRING,
},{
.name = clock,
-.type = QEMU_OPT_STRING,
-#ifdef TARGET_I386
+.type = QEMU_OPT_ENUM,
+.validate = {
+.optEnum = {
+.to_string = qemu_rtc_clock_to_string,
+.to_string_list = qemu_rtc_clock_to_string_list,
+.from_string = qemu_rtc_clock_from_string,
+.last = QEMU_RTC_CLOCK_LAST,
+},
+},
},{
.name = driftfix,
-.type = QEMU_OPT_STRING,
-#endif
+.type = QEMU_OPT_ENUM,
+.validate = {
+.optEnum = {
+.to_string = qemu_rtc_driftfix_to_string,
+.to_string_list = qemu_rtc_driftfix_to_string_list,
+.from_string = qemu_rtc_driftfix_from_string,
+.last = QEMU_RTC_DRIFTFIX_LAST,
+},
+},
},
{ /* end if list */ }
},
diff --git a/sysemu.h b/sysemu.h
index f0c5eb8..4d39566 100644
--- a/sysemu.h
+++ b/sysemu.h
@@ -120,7 +120,6 @@ extern uint8_t irq0override;
extern DisplayType display_type;
extern const char *keyboard_layout;
extern int win2k_install_hack;
-extern int rtc_td_hack;
extern int alt_grab;
extern int ctrl_grab;
extern int usb_enabled;
@@ -133,7 +132,26 @@ extern int no_shutdown;
extern int semihosting_enabled;
extern int old_param;
extern int boot_menu;
+
extern QEMUClock *rtc_clock;
+extern int rtc_driftfix;
+
+enum {
+QEMU_RTC_CLOCK_HOST,
+QEMU_RTC_CLOCK_GUEST,
+
+QEMU_RTC_CLOCK_LAST
+};
+QEMU_ENUM_DECL(qemu_rtc_clock);
+
+enum {
+QEMU_RTC_DRIFTFIX_NONE,
+QEMU_RTC_DRIFTFIX_SLEW,
+
+QEMU_RTC_DRIFTFIX_LAST
+};
+QEMU_ENUM_DECL(qemu_rtc_driftfix);
+
#define MAX_NODES 64
extern int nb_numa_nodes;
diff --git a/vl.c b/vl.c
index 16491c4..0b38d62 100644
--- a/vl.c
+++ b/vl.c
@@ -201,7 +201,7 @@ CharDriverState *serial_hds[MAX_SERIAL_PORTS];
CharDriverState *parallel_hds[MAX_PARALLEL_PORTS];
CharDriverState
[Qemu-devel] Re: [PATCH 6/6] apic: avoid using CPUState internals
On Sun, Jun 6, 2010 at 5:39 PM, Paolo Bonzini pbonz...@redhat.com wrote:
On 06/05/2010 11:31 PM, Blue Swirl wrote:
Use only an opaque CPUState pointer and move the actual CPUState
contents handling to cpu.h and cpuid.c.
Set env-halted in pc.c and add a function to get the local APIC state
of the current CPU for the MMIO.
Signed-off-by: Blue Swirlblauwir...@gmail.com
---
hw/apic.c | 40 +++-
hw/apic.h | 9 -
hw/pc.c | 12 +++-
target-i386/cpu.h | 27 ---
target-i386/cpuid.c | 6 ++
5 files changed, 56 insertions(+), 38 deletions(-)
diff --git a/hw/apic.c b/hw/apic.c
index 91c8d93..332c66e 100644
--- a/hw/apic.c
+++ b/hw/apic.c
@@ -95,7 +95,7 @@
#define MSI_ADDR_SIZE 0x10
struct APICState {
- CPUState *cpu_env;
+ void *cpu_env;
I proposed having an opaque CPUState type in hw/ but it was rejected. But I
don't think using a void pointer is any better.
It's not necessary for the patch. Maybe it's possible to avoid all
CPUState references in apic.c by pushing the dependencies to pc.c. It
could affect performance though.
Re: [Qemu-devel] [PATCH 09/19] Change 'query-version' to output broken down version string
On Mon, 07 Jun 2010 10:11:28 -0500
Anthony Liguori anth...@codemonkey.ws wrote:
On 06/07/2010 09:42 AM, Daniel P. Berrange wrote:
A previous discussion brought up the fact that clients should
not have to parse version string from QMP, it should be given
to them pre-split.
Change query-version output format from:
{ qemu: 0.11.50, package: }
to:
{ qemu: { major: 0, minor: 11, micro: 5 }, package: }
We need to drop package entirely.
Why? It's something that shouldn't be in the greeting message, but it's
a component of the version, so the only way to query it from QMP is by
using query-version.
Instead vendors should use the vendor specific namespace to extend the
version.
IMHO, vendor in QMP's terminology is someone adding extensions to
the protocol. Most distros won't do that, but they may carry not
upstream merged patches.
I'd suggest changing the version output to:
{ 'major': 0, 'minor': 11, 'micro': 5 }
For something like kvm, it can introduce a '__org.linux-kvm.release', 2
to that main dictionary.
I think we need both, 'vendor' and 'package' keys and maybe 'vendor'
should be part of the greeting message so that clients can identify they
are talking to a non standard version.
Regards,
Anthony Liguori
The major, minor micro keys are all integer values. package is
an arbitrary string whose format is defined by the OS package
maintainer.
There is no need to preserve the existing string format of the 'qemu'
key, since QMP is not yet declared stable.
Signed-off-by: Daniel P. Berrangeberra...@redhat.com
---
monitor.c | 47 +++
1 files changed, 43 insertions(+), 4 deletions(-)
diff --git a/monitor.c b/monitor.c
index 15b53b9..f0406e8 100644
--- a/monitor.c
+++ b/monitor.c
@@ -670,17 +670,56 @@ help:
static void do_info_version_print(Monitor *mon, const QObject *data)
{
QDict *qdict;
+QDict *qemu;
qdict = qobject_to_qdict(data);
+qemu = qdict_get_qdict(qdict, qemu);
-monitor_printf(mon, %s%s\n, qdict_get_str(qdict, qemu),
- qdict_get_str(qdict, package));
+monitor_printf(mon, % PRId64 .% PRId64 .% PRId64 %s\n,
+ qdict_get_int(qemu, major),
+ qdict_get_int(qemu, minor),
+ qdict_get_int(qemu, micro),
+ qdict_get_str(qdict, package));
}
+
+/**
+ * do_info_version(): Show QEMU version
+ *
+ * Return a QDict with the following information:
+ *
+ * - qemu: QEMU upstream version
+ * - package: QEMU packager's version
+ *
+ * The 'qemu' key value is a QDict containing three
+ * integer values
+ *
+ * - major: QEMU's major version
+ * - minor: QEMU's minor version
+ * - micro: QEMU's micro version
+ *
+ * The 'package' key value is a string in an format
+ * defined by the OS distributor to reflect their
+ * packaging of QEMU.
+ *
+ * Example:
+ *
+ * { qemu: { major: 0, minor: 11, micro: 5 }, package: }
+ */
static void do_info_version(Monitor *mon, QObject **ret_data)
{
-*ret_data = qobject_from_jsonf({ 'qemu': %s, 'package': %s },
- QEMU_VERSION, QEMU_PKGVERSION);
+const char *version = QEMU_VERSION;
+int major = 0, minor = 0, micro = 0;
+char *tmp;
+
+major = strtol(version,tmp, 10);
+tmp++;
+minor = strtol(tmp,tmp, 10);
+tmp++;
+micro = strtol(tmp,tmp, 10);
+
+*ret_data = qobject_from_jsonf({ 'qemu': { 'major': %d, 'minor': %d,
'micro': %d }, 'package': %s },
+ major, minor, micro, QEMU_PKGVERSION);
}
static void do_info_name_print(Monitor *mon, const QObject *data)
[Qemu-devel] [PATCH] target-mips: Fix compilation
TCGv t1 needs tcg_temp_free instead of tcg_temp_free_i32. Cc: Nathan Froyd froy...@codesourcery.com Cc: Aurelien Jarno aurel...@aurel32.net Signed-off-by: Stefan Weil w...@mail.berlios.de --- target-mips/translate.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/target-mips/translate.c b/target-mips/translate.c index 3473281..940f57c 100644 --- a/target-mips/translate.c +++ b/target-mips/translate.c @@ -9478,7 +9478,7 @@ static void gen_ldst_multiple (DisasContext *ctx, uint32_t opc, int reglist, } MIPS_DEBUG(%s, %x, %d(%s), opn, reglist, offset, regnames[base]); tcg_temp_free(t0); -tcg_temp_free_i32(t1); +tcg_temp_free(t1); tcg_temp_free_i32(t2); } -- 1.7.1
[Qemu-devel] Re: [PATCH] acpi_piix4: save gpe and pci hotplug slot status
nudge. Any comments here?
On Wed, Jun 2, 2010 at 10:58 AM, Alex Williamson
alex.william...@redhat.com wrote:
PCI hotplug currently doesn't work after a migration because
we don't migrate the enable bits of the GPE state. Pull hotplug
structs into vmstate.
Signed-off-by: Alex Williamson alex.william...@redhat.com
---
hw/acpi_piix4.c | 29 -
1 files changed, 28 insertions(+), 1 deletions(-)
diff --git a/hw/acpi_piix4.c b/hw/acpi_piix4.c
index 0fce958..091cdcd 100644
--- a/hw/acpi_piix4.c
+++ b/hw/acpi_piix4.c
@@ -282,9 +282,33 @@ static int vmstate_acpi_post_load(void *opaque, int
version_id)
return 0;
}
+static const VMStateDescription vmstate_gpe = {
+ .name = gpe,
+ .version_id = 1,
+ .minimum_version_id = 1,
+ .minimum_version_id_old = 1,
+ .fields = (VMStateField []) {
+ VMSTATE_UINT16(sts, struct gpe_regs),
+ VMSTATE_UINT16(en, struct gpe_regs),
+ VMSTATE_END_OF_LIST()
+ }
+};
+
+static const VMStateDescription vmstate_pci_status = {
+ .name = pci_status,
+ .version_id = 1,
+ .minimum_version_id = 1,
+ .minimum_version_id_old = 1,
+ .fields = (VMStateField []) {
+ VMSTATE_UINT32(up, struct pci_status),
+ VMSTATE_UINT32(down, struct pci_status),
+ VMSTATE_END_OF_LIST()
+ }
+};
+
static const VMStateDescription vmstate_acpi = {
.name = piix4_pm,
- .version_id = 1,
+ .version_id = 2,
.minimum_version_id = 1,
.minimum_version_id_old = 1,
.post_load = vmstate_acpi_post_load,
@@ -296,6 +320,9 @@ static const VMStateDescription vmstate_acpi = {
VMSTATE_STRUCT(apm, PIIX4PMState, 0, vmstate_apm, APMState),
VMSTATE_TIMER(tmr_timer, PIIX4PMState),
VMSTATE_INT64(tmr_overflow_time, PIIX4PMState),
+ VMSTATE_STRUCT(gpe, PIIX4PMState, 2, vmstate_gpe, struct gpe_regs),
+ VMSTATE_STRUCT(pci0_status, PIIX4PMState, 2, vmstate_pci_status,
+ struct pci_status),
VMSTATE_END_OF_LIST()
}
};
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH v6 5/6] Inter-VM shared memory PCI device
On Mon, Jun 7, 2010 at 4:41 PM, Cam Macdonell c...@cs.ualberta.ca wrote:
On Sat, Jun 5, 2010 at 3:44 AM, Blue Swirl blauwir...@gmail.com wrote:
On Fri, Jun 4, 2010 at 9:45 PM, Cam Macdonell c...@cs.ualberta.ca wrote:
Support an inter-vm shared memory device that maps a shared-memory object
as a
PCI device in the guest. This patch also supports interrupts between guest
by
communicating over a unix domain socket. This patch applies to the qemu-kvm
repository.
-device ivshmem,size=size in format accepted by -m[,shm=shm name]
Interrupts are supported between multiple VMs by using a shared memory
server
by using a chardev socket.
-device ivshmem,size=size in format accepted by -m[,shm=shm name]
[,chardev=id][,msi=on][,irqfd=on][,vectors=n][,role=peer|master]
-chardev socket,path=path,id=id
(shared memory server is qemu.git/contrib/ivshmem-server)
Sample programs and init scripts are in a git repo here:
www.gitorious.org/nahanni
---
Makefile.target | 3 +
hw/ivshmem.c | 852
+++
qemu-char.c | 6 +
qemu-char.h | 3 +
qemu-doc.texi | 43 +++
5 files changed, 907 insertions(+), 0 deletions(-)
create mode 100644 hw/ivshmem.c
diff --git a/Makefile.target b/Makefile.target
index c4ba592..4888308 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -202,6 +202,9 @@ obj-$(CONFIG_USB_OHCI) += usb-ohci.o
obj-y += rtl8139.o
obj-y += e1000.o
+# Inter-VM PCI shared memory
+obj-y += ivshmem.o
+
Can this be compiled once, simply by moving this to Makefile.objs
instead of Makefile.target? Also, because the code seems to be KVM
specific, it can't be compiled unconditionally but depending on at
least CONFIG_KVM and maybe CONFIG_EVENTFD.
The device uses eventfds for signalling, but never creates the
eventfds itself as they are passed from a server using SCM_RIGHTS.
So, it does not depend on the eventfd API. Its dependence on
irqfd/ioeventfd (the only KVM specific bits) are optional via the
command-line.
A runtime check for KVM is done for the reasons Avi mentioned.
Why is this KVM specific BTW, Posix SHM is available on many
platforms? What would happen if kvm_set_foobar functions were not
called when KVM is not being used? Is host eventfd support essential?
# Hardware support
obj-i386-y += vga.o
obj-i386-y += mc146818rtc.o i8259.o pc.o
diff --git a/hw/ivshmem.c b/hw/ivshmem.c
new file mode 100644
index 000..9057612
--- /dev/null
+++ b/hw/ivshmem.c
@@ -0,0 +1,852 @@
+/*
+ * Inter-VM Shared Memory PCI device.
+ *
+ * Author:
+ * Cam Macdonell c...@cs.ualberta.ca
+ *
+ * Based On: cirrus_vga.c
+ * Copyright (c) 2004 Fabrice Bellard
+ * Copyright (c) 2004 Makoto Suzuki (suzu)
+ *
+ * and rtl8139.c
+ * Copyright (c) 2006 Igor Kovalenko
+ *
+ * This code is licensed under the GNU GPL v2.
+ */
+#include sys/mman.h
+#include sys/types.h
+#include sys/socket.h
+#include sys/io.h
+#include sys/ioctl.h
+#include hw.h
+#include console.h
+#include pc.h
+#include pci.h
+#include sysemu.h
+
+#include msix.h
+#include qemu-kvm.h
+#include libkvm.h
+
+#include sys/eventfd.h
+#include sys/mman.h
+#include sys/socket.h
+#include sys/ioctl.h
+
+#define IVSHMEM_IRQFD 0
+#define IVSHMEM_MSI 1
+
+//#define DEBUG_IVSHMEM
+#ifdef DEBUG_IVSHMEM
+#define IVSHMEM_DPRINTF(fmt, args...) \
+ do {printf(IVSHMEM: fmt, ##args); } while (0)
Please use __VA_ARGS__.
+#else
+#define IVSHMEM_DPRINTF(fmt, args...)
+#endif
+
+typedef struct Peer {
+ int nb_eventfds;
+ int *eventfds;
+} Peer;
+
+typedef struct EventfdEntry {
+ PCIDevice *pdev;
+ int vector;
+} EventfdEntry;
+
+typedef struct IVShmemState {
+ PCIDevice dev;
+ uint32_t intrmask;
+ uint32_t intrstatus;
+ uint32_t doorbell;
+
+ CharDriverState ** eventfd_chr;
I'd remove the space between '**' and 'eventfd_chr', it's used
inconsistently.
+ CharDriverState * server_chr;
+ int ivshmem_mmio_io_addr;
+
+ pcibus_t mmio_addr;
+ pcibus_t shm_pci_addr;
+ uint64_t ivshmem_offset;
+ uint64_t ivshmem_size; /* size of shared memory region */
+ int shm_fd; /* shared memory file descriptor */
+
+ Peer *peers;
+ int nb_peers; /* how many guests we have space for */
+ int max_peer; /* maximum numbered peer */
+
+ int vm_id;
+ uint32_t vectors;
+ uint32_t features;
+ EventfdEntry *eventfd_table;
+
+ char * shmobj;
+ char * sizearg;
+ char * role;
+} IVShmemState;
+
+/* registers for the Inter-VM shared memory device */
+enum ivshmem_registers {
+ IntrMask = 0,
+ IntrStatus = 4,
+ IVPosition = 8,
+ Doorbell = 12,
+};
IIRC these should be uppercase.
I worked from rtl8139 which doesn't have them uppercase. But doing a
quick search, I can see most devices do, I'll fix that.
+
+static inline
Re: [Qemu-devel] [PATCH 00/19] RFC: Reporting QEMU binary capabilities
On Mon, 07 Jun 2010 11:07:14 -0500 Anthony Liguori anth...@codemonkey.ws wrote: Hi Daniel, On 06/07/2010 09:42 AM, Daniel P. Berrange wrote: As everyone here agrees, having management apps parse -help output to determine the QEMU capabilities is not at all nice, because it is an ill-defined fragile data format. Looking more broadly these same issues apply to all the other command line options that accept a '?' flag for querying capabilities. We have a very nice structured data format we could be using for this: JSON. What's lacking is code to output all this information in the JSON format. This patch series can thus be summarized as 'JSON for everything' For the most part, this series looks pretty nice. For me too, some comments though: - All protocol visible changes must be documented in qemu-monitor.hx and as there's a lot of stuff being exposed, would be good to get more ACKs on them (maybe from Avi, Markus etc) - This series overlaps a bit with self-description support, specially if you're willing to work on a really useful version of query-commands. It's worth reading the following thread: http://lists.gnu.org/archive/html/qemu-devel/2010-01/msg00852.html - As the series is going to change, I've skipped some implementation details while reviewing. Will do a deeper review in the non-rfc version I think my only real objection is the query-argv bits. The enums are a bit awkward to define but I understand the value of it and I can't think of a better way to do it. Regards, Anthony Liguori For reference, here is the full list of information libvirt currently queries from QEMU: * Detection of command line flags (-help parsing) -no-kqemu, -no-kvm, -enable-kvm, -no-reboot -name, -uuid, -xen-domid, -domid, -drive -vga, -std-vga, -pcidevice, -mem-path -chardev, -balloon, -device, -rtc, -rtc-td-hack -no-hpet, -no-kvm-pit-reinjection, -tdf -fsdev -sdl * Detection of parameters (-help parsing) -drive format= -drive boot= -drive serial= -drive cache= -cpu cores=, threads=, sockets= -netdev vhost= * Detection of parameter values (-help parsing) -drive cache=writethrough|writeback|none vs -drive cache=default|on|off * Version number (-help parsing) -netdev + 0.13.0 0.9.0 for VNC syntax 0.10.0 for vnet hdr * Parse -M ? output to get list of machine types + aliases * Parse -device pci-assign,? to check for 'configfd' parameter * Parse -cpu ? to get list of named CPU types * Parse binary name (qemu-system-) to guess arch of target This isn't an 100% exhaustive list of things that we would like to be able to get access to though. It can likely cover all of the following: * Version QEMU major, minor, micro numbers. KVM version. Package version * Devices List of device names. Parameter names. Parameter value data types. Allowed strings for enums * Arguments List of command line arguments. Parameter names. Parameter value data types. Allowed strings for enums * Machine types List of names + aliases List of default devices in machine * CPU types List of names, associated feature flags, all allowed feature flags * Target info Arch name, wordsize * Monitor commands List of all monitor commands. Parameter names. Parameter value data types. Allowed strings for enums * Block device backends List of all block device backends. Parameter names. Parameter value data types. Allowed strings for enums * Netdev device backends List of all netdev device backends. Parameter names. Parameter value data types. Allowed strings for enums * Chardev device backends List of all chardev device backends. Parameter names. Parameter value data types. Allowed strings for enums This patch series attempts to satisfy as much of this as is feasible with the current QEMU codebase structure. The series comprises four stages * Some basic infrastructure. Support for JSON pretty printing. Introduction of standardized helpers for converting enums to/from strings. Introduction of an 'enum' data type for QemuOpt to expose a formal list of valid values simplify config handling / parsing. Compile time assertion checking * Convert driver, netdev rtc config options to use the new enum data type for all appropriate args * Add new QMP monitor commands exposing data for machine types, devices, cpu types, arch target, argv, config params, and netdev backends. * Add a new '-capabilities' command line arg as syntactic sugar for the
Re: [Qemu-devel] [PATCH 1/3] export tdb_hash()
On Tue, 8 Jun 2010 12:31:38 +0530
Prerna Saxena pre...@linux.vnet.ibm.com wrote:
This exports tdb_hash() for use by tracing framework.
Suggest to rename it (eg. qemu_hash()) and move it to a better location, qdict
is not the best module to export such service.
Signed-off-by: Prerna Saxena pre...@linux.vnet.ibm.com
---
qdict.c |2 +-
qdict.h |2 ++
2 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/qdict.c b/qdict.c
index 175bc17..5261872 100644
--- a/qdict.c
+++ b/qdict.c
@@ -56,7 +56,7 @@ QDict *qobject_to_qdict(const QObject *obj)
* tdb_hash(): based on the hash agorithm from gdbm, via tdb
* (from module-init-tools)
*/
-static unsigned int tdb_hash(const char *name)
+unsigned int tdb_hash(const char *name)
{
unsigned value; /* Used to compute the hash value. */
unsigned i;/* Used to cycle through random values. */
diff --git a/qdict.h b/qdict.h
index 5e5902c..d221c18 100644
--- a/qdict.h
+++ b/qdict.h
@@ -59,4 +59,6 @@ int64_t qdict_get_try_int(const QDict *qdict, const char
*key,
int64_t err_value);
const char *qdict_get_try_str(const QDict *qdict, const char *key);
+/* Export tdb_hash() for use by trace framework */
+unsigned int tdb_hash(const char *name);
#endif /* QDICT_H */
[Qemu-devel] Re: [PATCH] sparc32 esp fix spurious interrupts in chip reset
On Fri, Jun 4, 2010 at 8:30 PM, Artyom Tarasenko
atar4q...@googlemail.com wrote:
2010/6/4 Blue Swirl blauwir...@gmail.com:
On Tue, Jun 1, 2010 at 8:16 PM, Artyom Tarasenko
atar4q...@googlemail.com wrote:
2010/6/1 Blue Swirl blauwir...@gmail.com:
On Tue, Jun 1, 2010 at 7:56 PM, Artyom Tarasenko
atar4q...@googlemail.com wrote:
2010/6/1 Blue Swirl blauwir...@gmail.com:
On Sun, May 30, 2010 at 10:35 PM, Artyom Tarasenko
atar4q...@googlemail.com wrote:
lower interrupt during chip reset. Otherwise the ESP_RSTAT register
may get out of sync with the IRQ line status. This effect became
visible after commit 65899fe3
Hard reset handlers should not touch qemu_irqs, because on cold start,
the receiving end may be unprepared to handle the signal.
Wouldn't the real hardware lower irq on the hardware reset?
Yes, but since qemu_irqs have no state, and on a cold start or system
reset all other devices are guaranteed to be reset, the callback would
be useless.
And if it would not, would it still clear the corresponding bit in
the ESP_RSTAT register?
All registers are set to zero in the lines below.
See
0d0a7e69e853639b123798877e019c3c7ee6634a,
bc26e55a6615dc594be425d293db40d5cdcdb84b and
42f1ced228c9b616cfa2b69846025271618e4ef5.
For ESP there are two other sources of reset: signal from DMA and chip
reset command. On those cases, lowering IRQ makes sense.
So the correct fix is to refactor the reset handling a bit. Does this
patch also fix your test case?
It does, but
+static void esp_soft_reset(DeviceState *d)
+{
+ ESPState *s = container_of(d, ESPState, busdev.qdev);
+
+ qemu_irq_lower(s-irq);
Shouldn't it be esp_lower_irq(s)? What's going to happen to the
DMA_INTR bit if dma was the source of the irq?
Again, the registers are zeroed in esp_hard_reset().
How does it zero the _DMA_ registers? And sparc32_dma does share the
IRQ line with ESP, doesn't it?
I'd suppose DMA registers are separate and they would not be cleared
by for example ESP chip reset command. The IRQ goes from ESP to DMA,
DMA has another line going to interrupt controller.
But do we have separate DMA lines in qemu? If we do, I'm absolutely fine with
qemu_irq_lower(s-irq) . If we don't, imagine the following scenario: DMA
rises an IRQ, then esp chip reset happens, and then... DMA can't rise
the IRQ anymore.
What ESP does with its IRQ line does not stop DMA from using its line.
Re: [Qemu-devel] [RFC PATCH 3/6] RAMBlock: Add a name field
Not really. This identifier is device and bus independent, which is why I suggested passing the device to qemu_ram_alloc. This can then figure out how to the identify the device. It should probably do this the same way that we identify the saved state for the device. Currently I think this is an arbitrary vmstate name/id, but I expect this to change to a qdev address (e.g. /i440FX-pcihost/pci.0/_addr_04.0). Ok, that seems fairly reasonable, so from a device pointer we can get something like /i440FX-pcihost/pci.0/_addr_04.0, then we can add something like :rom or :bar.0 to it via an extra string. qemu_ram_alloc(DeviceState *dev, const char *info, size) Exactly - though personally I wouldn't call the second argument info. Does a function already exist to print out a qdev address path? No. I may have been a bit misleading here. What we really want to do is use the same matching algorithm as is used by the rest of the device state. Currently this is a vmstate name and [arbitrary] numeric id. I don't remember whether there's a convenient link from a device to its associated vmstate - if there isn't there probably should be. Paul
Re: [Qemu-devel] [PATCH 2/3] Monitor command 'trace'
On Tue, 8 Jun 2010 12:34:37 +0530
Prerna Saxena pre...@linux.vnet.ibm.com wrote:
This introduces the monitor command 'trace' to read current contents of
trace buffer.
Signed-off-by: Prerna Saxena pre...@linux.vnet.ibm.com
---
configure |3 +++
monitor.c |3 +++
qemu-monitor.hx | 16
simpletrace.c | 15 +++
tracetool |4
5 files changed, 41 insertions(+), 0 deletions(-)
diff --git a/configure b/configure
index 675d0fc..56af8dd 100755
--- a/configure
+++ b/configure
@@ -2302,6 +2302,9 @@ bsd)
esac
echo TRACE_BACKEND=$trace_backend $config_host_mak
+if test $trace_backend = simple; then
+ echo CONFIG_SIMPLE_TRACE=y $config_host_mak
+fi
if test $trace_backend = ust; then
LIBS=-lust $LIBS
fi
diff --git a/monitor.c b/monitor.c
index ad50f12..fda29aa 100644
--- a/monitor.c
+++ b/monitor.c
@@ -55,6 +55,9 @@
#include json-streamer.h
#include json-parser.h
#include osdep.h
+#ifdef CONFIG_SIMPLE_TRACE
+#include trace.h
+#endif
//#define DEBUG
//#define DEBUG_COMPLETION
diff --git a/qemu-monitor.hx b/qemu-monitor.hx
index b6e3467..c604aec 100644
--- a/qemu-monitor.hx
+++ b/qemu-monitor.hx
@@ -221,6 +221,22 @@ STEXI
@item logfile @var{filename}
@findex logfile
Output logs to @var{filename}.
+#ifdef CONFIG_SIMPLE_TRACE
+ETEXI
+
+{
+.name = trace,
+.args_type = ,
+.params = ,
+.help = shows contents of trace buffer,
+.mhandler.cmd = do_info_trace,
+},
+
+STEXI
+...@item trace
+...@findex trace
+show contents of trace buffer
+#endif
ETEXI
{
diff --git a/simpletrace.c b/simpletrace.c
index 2fec4d3..8f33a81 100644
--- a/simpletrace.c
+++ b/simpletrace.c
@@ -62,3 +62,18 @@ void trace4(TraceEvent event, unsigned long x1, unsigned
long x2, unsigned long
void trace5(TraceEvent event, unsigned long x1, unsigned long x2, unsigned
long x3, unsigned long x4, unsigned long x5) {
trace(event, x1, x2, x3, x4, x5);
}
+
+void do_info_trace(Monitor *mon) {
You sure this shouldn't be 'info trace'?
+static unsigned int i, max_idx;
Why static?
+
+if (trace_idx)
+max_idx = trace_idx;
+else
+max_idx = TRACE_BUF_LEN;
max_idx = trace_idx ? trace_idx : TRACE_BUF_LEN;
+
+for (i=0; imax_idx ;i++)
+monitor_printf(mon, Event %ld : %ld %ld %ld %ld %ld\n,
+ trace_buf[i].event, trace_buf[i].x1, trace_buf[i].x2,
+ trace_buf[i].x3, trace_buf[i].x4, trace_buf[i].x5);
Style indentation.
+return;
Not needed.
+}
diff --git a/tracetool b/tracetool
index 9ea9c08..6c15154 100755
--- a/tracetool
+++ b/tracetool
@@ -130,6 +130,7 @@ void trace2(TraceEvent event, unsigned long x1, unsigned
long x2);
void trace3(TraceEvent event, unsigned long x1, unsigned long x2, unsigned
long x3);
void trace4(TraceEvent event, unsigned long x1, unsigned long x2, unsigned
long x3, unsigned long x4);
void trace5(TraceEvent event, unsigned long x1, unsigned long x2, unsigned
long x3, unsigned long x4, unsigned long x5);
+void do_info_trace(Monitor *mon);
EOF
simple_event_num=0
@@ -289,6 +290,9 @@ tracetoh()
#define TRACE_H
#include qemu-common.h
+
+extern void monitor_printf(Monitor *mon, const char *fmt, ...)
+__attribute__ ((__format__ (__printf__, 2, 3)));
EOF
convert h
echo #endif /* TRACE_H */
Re: [Qemu-devel] [PATCH 3/3] Toggle tracepoint state
On Tue, 8 Jun 2010 12:38:58 +0530
Prerna Saxena pre...@linux.vnet.ibm.com wrote:
This patch adds support for dynamically enabling/disabling of tracepoints.
Monitor commands added :
1) info tracepoints : to view all available tracepoints and
their state.
2) tracepoint NAME on|off : to enable/disable data logging from a
given tracepoint.
Eg, tracepoint paio_submit off
disables logging of data when
paio_submit is hit.
At present this is done with a simple comparison -- there is scope
for optimizations that can be employed here to speed this up.
Signed-off-by: Prerna Saxena pre...@linux.vnet.ibm.com
---
monitor.c | 21 +
qemu-monitor.hx | 16
simpletrace.c | 55
++-
tracetool | 30 ++
vl.c|6 ++
5 files changed, 123 insertions(+), 5 deletions(-)
diff --git a/monitor.c b/monitor.c
index fda29aa..1e05b38 100644
--- a/monitor.c
+++ b/monitor.c
@@ -547,7 +547,19 @@ static void do_commit(Monitor *mon, const QDict *qdict)
bdrv_commit(dinfo-bdrv);
}
}
+#ifdef CONFIG_SIMPLE_TRACE
+static void do_change_tracepoint_state(Monitor *mon, const QDict *qdict)
+{
+const char *tp_name = qdict_get_str(qdict, name);
+const char *tp_state = qdict_get_str(qdict, option);
+if (!strncmp(tp_state, on, 2))
+ change_tracepoint_state(tp_name, 1);
+if (!strncmp(tp_state, off, 3))
+ change_tracepoint_state(tp_name, 0);
Monitor has a bool type, please take a look in do_set_link().
+return;
Not needed, also true for other functions in this patch, suggest reading
CODING_STYLE for other style related issues in this series.
+}
+#endif
static void user_monitor_complete(void *opaque, QObject *ret_data)
{
MonitorCompletionData *data = (MonitorCompletionData *)opaque;
@@ -2783,6 +2795,15 @@ static const mon_cmd_t info_cmds[] = {
.help = show roms,
.mhandler.info = do_info_roms,
},
+#ifdef CONFIG_SIMPLE_TRACE
+{
+.name = tracepoints,
+.args_type = ,
+.params = ,
+.help = show available tracepoints their state,
+.mhandler.info = do_info_all_tracepoints,
+},
+#endif
{
.name = NULL,
},
diff --git a/qemu-monitor.hx b/qemu-monitor.hx
index c604aec..36481ea 100644
--- a/qemu-monitor.hx
+++ b/qemu-monitor.hx
@@ -114,6 +114,8 @@ show migration status
show balloon information
@item info qtree
show device tree
+...@item info tracepoints
+show available tracepoints and their state
@end table
ETEXI
@@ -236,6 +238,20 @@ STEXI
@item trace
@findex trace
show contents of trace buffer
+ETEXI
+
+{
+.name = tracepoint,
+.args_type = name:s,option:s,
+.params = name on|off,
+.help = changes status of a specific tracepoint,
+.mhandler.cmd = do_change_tracepoint_state,
+},
+
+STEXI
+...@item tracepoint
+...@findex tracepoint
+changes status of a tracepoint
#endif
ETEXI
diff --git a/simpletrace.c b/simpletrace.c
index 8f33a81..75d2fca 100644
--- a/simpletrace.c
+++ b/simpletrace.c
@@ -3,6 +3,12 @@
#include trace.h
typedef struct {
+char *tp_name;
+bool state;
+unsigned int hash;
+} Tracepoint;
+
+typedef struct {
unsigned long event;
unsigned long x1;
unsigned long x2;
@@ -18,10 +24,24 @@ enum {
static TraceRecord trace_buf[TRACE_BUF_LEN];
static unsigned int trace_idx;
static FILE *trace_fp;
+static Tracepoint trace_list[NR_TRACEPOINTS];
+
+void init_tracepoint(const char *tname, TraceEvent tevent) {
+if (!tname || tevent NR_TRACEPOINTS)
+ return;
+
+trace_list[tevent].tp_name = (char*)qemu_malloc(strlen(tname)+1);
+strncpy(trace_list[tevent].tp_name, tname, strlen(tname));
+trace_list[tevent].hash = tdb_hash(tname);
+trace_list[tevent].state = 1; /* Enable all by default */
+return;
+}
static void trace(TraceEvent event, unsigned long x1,
unsigned long x2, unsigned long x3,
unsigned long x4, unsigned long x5) {
+if (!trace_list[event].state)
+ return;
TraceRecord *rec = trace_buf[trace_idx];
rec-event = event;
rec-x1 = x1;
@@ -64,7 +84,7 @@ void trace5(TraceEvent event, unsigned long x1, unsigned
long x2, unsigned long
}
void do_info_trace(Monitor *mon) {
-static unsigned int i, max_idx;
+unsigned int i, max_idx;
if (trace_idx)
max_idx = trace_idx;
@@ -77,3 +97,36 @@ void do_info_trace(Monitor *mon) {
trace_buf[i].x3, trace_buf[i].x4, trace_buf[i].x5);
[Qemu-devel] [Bug 586175] Re: Windows XP/2003 doesn't boot
It sounds like this is an existing image that you can't boot from. I can create a new 2k3 VM with upstream qemu and boot it again after install with no issues. So I'm wondering if you can also do this. If so, then something happened to your existing image (maybe some sort of corruption of the boot sector ?). -- Windows XP/2003 doesn't boot https://bugs.launchpad.net/bugs/586175 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: Incomplete Status in Fedora: Unknown Bug description: Hello everyone, my qemu doesn't boot any Windows XP/2003 installations if I try to boot the image. If I boot the install cd first, it's boot manager counts down and triggers the boot on it's own. That's kinda stupid. I'm using libvirt, but even by a simple qemu-kvm -drive file=image.img,media=disk,if=ide,boot=on it won't boot. Qemu hangs at the message Booting from Hard Disk... I'm using qemu-kvm-0.12.4 with SeaBIOS 0.5.1 on Gentoo (No-Multilib and AMD64). It's a server, that means I'm using VNC as the primary graphic output but i don't think it should be an issue.
Re: [Qemu-devel] Re: [PATCH 0/22] Refactor machine support
On Wed, Jun 9, 2010 at 2:30 PM, Paul Brook p...@codesourcery.com wrote: Because at some point the base tree will have to be written in C. No. You can start with a completely empty machine. We don't/shouldn't need any machine specific C code. I think you're missing the argument. I should be possible to create a machine entirely from a FDT or via -device options. However, to continue to support the interfaces that we support today, it will be necessary to have C code that manipulates a base device tree. When a user specifies '-M pc -hda foo.img' verses '-M versatilepb -hda foo.img', the equivalent are two very different operations on a device tree. The former adds an ide disk to the default controller and the later potentially creates a new scsi bus and then adds a disk to a specific bus. AFAICS the current commandline options only result in simple addition of devices. They might add slightly different devices in slightly different places, but that's easy to accommodate by having the machine define a few standard device/bus IDs. IMO it's even more lame if -hda shops working when you supply a device tree. The tree supplied by the user should label a bus node with a property 'QEMU,hda'. The C version (called by the board) would be something like setprop(/i440fx/pci.0/ide.0, QEMU,hda). QEMU should search the device tree for such labels at startup.
Re: [Qemu-devel] [PATCH v3 0/5] Add QMP migration events
On Wed, 9 Jun 2010 14:10:53 +0200 Juan Quintela quint...@redhat.com wrote: This is a resent with what we agreed on yesterday call. Migration events would be there for 0.13 until we get proper async command support. Something which is not clear to me is the set of events we'd have if migrate was an async command. Ie, do we really need MIGRATION_FAILED in this case? Don't we expect to get this information from the async response? Later, Juan. v3: - Add comment that MIGRATION_FAILURE will add a QError for 0.14 (when we get internal support for that) rebase against today tree v2: - Address pbonzini and mst changes (error messages and doc fixes) v1: This series does: - exit incoming migration on failure. For exec/fd migrations, once there was a failure, there was nothing useful to do. And for tcp migration, not exiting created interesting bugs when trying to migrate again to a process with a faild migration. - Factorize common migration code, no more duplication, makes easier to do global migration things, like QMP events. - Introduce QMP events, both for incoming and outgoing migration. Now, the million dollar question: Why I didn't refactorize outgoing migration? I tried, and have it partially done on my local tree. But it depends (too much) of current_migration global variable - Libvirt folks will also want info migrate to work on the incoming side, i.e. current_migraition has to also be updated on incoming side. Done until here, but then I hit the wall incoming migration is synchronous. To make the monitor work on incoming migration, we need to change buffered_file.c abstraction to also work for incoming fd's, or another similar solution. I am open to suggestions about what to do here. This series are quite simple (the unfinished part is more complex), will send the other part as an RFC later. Please review and consider to apply it. Later, Juan. Juan Quintela (5): Exit if incoming migration fails Factorize common migration incoming code QMP: Introduce MIGRATION events QMP: Emit migration events on incoming migration QMP: Emit migration events on outgoing migration QMP/qmp-events.txt | 52 migration-exec.c | 17 +++-- migration-fd.c | 15 ++- migration-tcp.c| 17 - migration-unix.c | 17 - migration.c| 37 +++-- migration.h|4 +++- monitor.c | 12 monitor.h |4 vl.c |7 ++- 10 files changed, 121 insertions(+), 61 deletions(-)
Re: [Qemu-devel] Re: [PATCH 0/22] Refactor machine support
On 06/09/2010 03:47 PM, Blue Swirl wrote: On Wed, Jun 9, 2010 at 2:30 PM, Paul Brookp...@codesourcery.com wrote: Because at some point the base tree will have to be written in C. No. You can start with a completely empty machine. We don't/shouldn't need any machine specific C code. I think you're missing the argument. I should be possible to create a machine entirely from a FDT or via -device options. However, to continue to support the interfaces that we support today, it will be necessary to have C code that manipulates a base device tree. When a user specifies '-M pc -hda foo.img' verses '-M versatilepb -hda foo.img', the equivalent are two very different operations on a device tree. The former adds an ide disk to the default controller and the later potentially creates a new scsi bus and then adds a disk to a specific bus. AFAICS the current commandline options only result in simple addition of devices. They might add slightly different devices in slightly different places, but that's easy to accommodate by having the machine define a few standard device/bus IDs. IMO it's even more lame if -hda shops working when you supply a device tree. The tree supplied by the user should label a bus node with a property 'QEMU,hda'. The C version (called by the board) would be something like setprop(/i440fx/pci.0/ide.0, QEMU,hda). QEMU should search the device tree for such labels at startup. That works for the very simple case of -hda, but what do you do for: -drive file=foo.img,bus=0,index=2 I think it's possible to come up with some form of solution once you start adding synthetic properties or dummy devices but ultimately I think it pollutes the device tree. I think the easiest way to support the interfaces we provide now is to just code the device tree manipulation in C. Regards, Anthony Liguori
