Re: [Qemu-devel] [PATCH] fixup e432cef9 (aio help text): end sentences with periods
Patch looks good, cc'ing qemu-trivial. Laszlo Ersek ler...@redhat.com writes: (Please keep me CC'd on any followup; I'm not subscribed. Thanks.) Best to put such notes below the --- line, so they don't get immortalized in the commit log. Signed-off-by: Laszlo Ersek ler...@redhat.com --- qemu-io.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/qemu-io.c b/qemu-io.c index ffa62fb..938b20c 100644 --- a/qemu-io.c +++ b/qemu-io.c @@ -1118,7 +1118,7 @@ static void aio_read_help(void) Reads a segment of the currently open file, optionally dumping it to the\n standard output stream (with -v option) for subsequent inspection.\n The read is performed asynchronously and the aio_flush command must be\n - used to ensure all outstanding aio requests have been completed\n + used to ensure all outstanding aio requests have been completed.\n -C, -- report statistics in a machine parsable format\n -P, -- use a pattern to verify read data\n -v, -- dump buffer to standard output\n @@ -1214,7 +1214,7 @@ static void aio_write_help(void) Writes into a segment of the currently open file, using a buffer\n filled with a set pattern (0xcdcdcdcd).\n The write is performed asynchronously and the aio_flush command must be\n - used to ensure all outstanding aio requests have been completed\n + used to ensure all outstanding aio requests have been completed.\n -P, -- use different pattern to fill file\n -C, -- report statistics in a machine parsable format\n -q, -- quiet mode, do not show I/O statistics\n
Re: [Qemu-devel] [PATCH 27/28] sysbus: apic: ioapic: convert to QEMU Object Model
Am 25.01.2012 00:03, schrieb Anthony Liguori: On 01/24/2012 04:06 PM, Jan Kiszka wrote: On 2012-01-24 22:53, Anthony Liguori wrote: But I don't like this. The problem is that the declarative syntax we have doesn't distinguish between not-specified and zero-initialized. That's surely solvable. Please try :-) I've spent a good chunk of time mulling this over and could not find an acceptable solution. I think the same is true for the GObject folks. There is a declarative solution for this that I know of, a C++ class definition ;-) So what's the reason not to go with one of the object-oriented, C-compatible languages GCC supports, like C++ or Objective-C/C++? (Objective-C has native reflection capabilities fwiw.) Personally I disliked those trivial mini init functions in the initial 2/4 series, too, but I don't really mind an imperative approach either. Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [PATCH 27/28] sysbus: apic: ioapic: convert to QEMU Object Model
On 2012-01-25 00:03, Anthony Liguori wrote:
They're exactly the same size (16 lines). If you embed TypeInfo into
DeviceTypeInfo, and introduce a Device specific type registration
function, then you could do:
static DeviceTypeInfo my_device_type_info = {
.type.name = TYPE_MY_DEVICE,
.type.parent = TYPE_PARENT_DEVICE,
.reset = my_device_reset,
And if you introduce some
#define TYPE_UNIMPLEMENTED (void *)dummy_variable
you can easily express
[.field = NULL] = use parent
.field = UNIMPLEMENTED = don't run any handler
};
static void register_devices(void)
{
device_type_register_static(my_device_type_info);
}
Which admittedly saves 6 lines, but also is a big step backwards IMHO.
Now you've got a lot of one-off functions which means you loose the
advantage of having everything work through the same infrastructure.
Can't follow. Four lines
[static inline] void device_type_register_static(DeviceTypeInfo *dt)
{
type_register_static(dt-type);
}
are neither ugly nor complex. Rather, this helps concentrating effort at
_central_ places instead of decentralizing and duplicating lines like in
your imperative approach. That's the whole point: keep the common case
(derived classes) compact.
Jan
signature.asc
Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH] qmp: add BLOCK_MEDIUM_EJECT event
Am 24.01.2012 21:03, schrieb Eric Blake: On 01/24/2012 11:16 AM, Luiz Capitulino wrote: Libvirt wants to be notified when the guest ejects a medium, so that it can update its view of the guest. This code has been originally written by Daniel Berrange. It adds the event to IDE and SCSI emulation. Please, note that this only covers guest initiated ejects, that's, the QMP/HMP commands 'eject' and 'change' are not covered. What's the reason for this behaviour? It feels inconsistent. Also, I seem to remember that once we had discussed some kind of a tray status (open/closed) changed event, which would be more generic. Signed-off-by: Luiz Capitulino lcapitul...@redhat.com Reviewed-by: Eric Blake ebl...@redhat.com +BLOCK_MEDIUM_EJECT +-- + +Emitted when the guest succeeds ejecting a medium. If the device has a tray, s/succeeds ejecting/succeeds at ejecting/ Since libvirt is also tracking whether it makes 'eject' and 'change' monitor commands, and can also do a query when reconnecting to the monitor after a libvirtd restart to see if state changed in the meantime (when an event was lost), this should be sufficient for libvirt to have an accurate picture of the device state. I do have to wonder, however, if we also need an event for when the guest initiates a tray lock or tray unlock event, in order to track whether plain eject will work or whether a forced eject to override the tray lock would be required. The tray is usually locked for a reason, so I would vote against libvirt automagically overriding it. Note that you don't really need a lock/unlock event for implementing it, you could just always pass force=true (or do it after you got QERR_DEVICE_LOCKED). The only reasonable thing for a management tool to do with a lock/unlock event would be updating some icon in a GUI or something like that. Kevin
Re: [Qemu-devel] [PATCH] usb-redir: Add the posibility to filter out certain devices from redirecion
Hi, On 01/23/2012 03:51 PM, Gerd Hoffmann wrote: On 01/13/12 08:43, Gerd Hoffmann wrote: On 01/12/12 17:31, Hans de Goede wrote: This patch adds the posibility to filter out certain devices from redirecion. To use this pass the filter property to -device usb-redir. The filter property takes a string consisting of filter rules, the format for a rule is: class:vendor:product:version:allow Hmm, what is the point of having this filter in qemu? I'd expect the other end of the network connection which talks to the actual usb device (i.e. the tcp standalone server or spice client) doing the filtering ... The admin of the vm may want to allow only certain devices to be redirected to the vm. And while he has administrative control over the vm, he does not necessarily have administrative control over the client. Also fails checkpatch: WARNING: line over 80 characters #75: FILE: usb-redir.c:898: +qerror_report(QERR_INVALID_PARAMETER_VALUE, filter, a usb device filter string); Oops, I'll send a new version. Regards, Hans
[Qemu-devel] [PATCH] usb-redir: Add the posibility to filter out certain devices from redirecion
This patch adds the posibility to filter out certain devices from redirecion.
To use this pass the filter property to -device usb-redir. The filter
property takes a string consisting of filter rules, the format for a rule is:
class:vendor:product:version:allow
-1 can be used to allow any value for a field.
Muliple rules can be concatonated using | as a separator. Note that if
a device matches none of the passed in rules, redirecting it will not be
allowed!
Example:
-device usb-redir,filter='-1:0x0781:0x5567:-1:0|0x08:-1:-1:-1:1'
This example will deny the Sandisk Cruzer Blade being redirected, as it
has a usb id of 0781:5567, it will allow any other usb mass storage devices,
and it will deny any other devices (the default for devices not matching any
of the rules.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
configure |2 +-
usb-redir.c | 115 +-
2 files changed, 106 insertions(+), 11 deletions(-)
diff --git a/configure b/configure
index 7ecf44e..c7e37df 100755
--- a/configure
+++ b/configure
@@ -2541,7 +2541,7 @@ fi
# check for usbredirparser for usb network redirection support
if test $usb_redir != no ; then
-if $pkg_config libusbredirparser /dev/null 21 ; then
+if $pkg_config --atleast-version=0.3.3 libusbredirparser /dev/null 21 ;
then
usb_redir=yes
usb_redir_cflags=$($pkg_config --cflags libusbredirparser 2/dev/null)
usb_redir_libs=$($pkg_config --libs libusbredirparser 2/dev/null)
diff --git a/usb-redir.c b/usb-redir.c
index 6e92f14..85f40d6 100644
--- a/usb-redir.c
+++ b/usb-redir.c
@@ -34,6 +34,7 @@
#include sys/ioctl.h
#include signal.h
#include usbredirparser.h
+#include usbredirfilter.h
#include hw/usb.h
@@ -72,6 +73,7 @@ struct USBRedirDevice {
/* Properties */
CharDriverState *cs;
uint8_t debug;
+char *filter_str;
/* Data passed from chardev the fd_read cb to the usbredirparser read cb */
const uint8_t *read_buf;
int read_buf_size;
@@ -84,6 +86,11 @@ struct USBRedirDevice {
struct endp_data endpoint[MAX_ENDPOINTS];
uint32_t packet_id;
QTAILQ_HEAD(, AsyncURB) asyncq;
+/* Data for device filtering */
+struct usb_redir_device_connect_header device_info;
+struct usb_redir_interface_info_header interface_info;
+struct usbredirfilter_rule *filter_rules;
+int filter_rules_count;
};
struct AsyncURB {
@@ -790,6 +797,7 @@ static int usbredir_handle_control(USBDevice *udev,
USBPacket *p,
static void usbredir_open_close_bh(void *opaque)
{
USBRedirDevice *dev = opaque;
+uint32_t caps[USB_REDIR_CAPS_SIZE] = { 0, };
usbredir_device_disconnect(dev);
@@ -820,7 +828,9 @@ static void usbredir_open_close_bh(void *opaque)
dev-parser-interrupt_packet_func = usbredir_interrupt_packet;
dev-read_buf = NULL;
dev-read_buf_size = 0;
-usbredirparser_init(dev-parser, VERSION, NULL, 0, 0);
+
+usbredirparser_caps_set_cap(caps,
usb_redir_cap_connect_device_version);
+usbredirparser_init(dev-parser, VERSION, caps, USB_REDIR_CAPS_SIZE,
0);
usbredirparser_do_write(dev-parser);
}
}
@@ -908,6 +918,17 @@ static int usbredir_initfn(USBDevice *udev)
return -1;
}
+if (dev-filter_str) {
+i = usbredirfilter_string_to_rules(dev-filter_str, :, |,
+ dev-filter_rules,
+ dev-filter_rules_count);
+if (i) {
+qerror_report(QERR_INVALID_PARAMETER_VALUE, filter,
+ a usb device filter string);
+return -1;
+}
+}
+
dev-open_close_bh = qemu_bh_new(usbredir_open_close_bh, dev);
dev-attach_timer = qemu_new_timer_ms(vm_clock, usbredir_do_attach, dev);
@@ -956,6 +977,44 @@ static void usbredir_handle_destroy(USBDevice *udev)
if (dev-parser) {
usbredirparser_destroy(dev-parser);
}
+
+free(dev-filter_rules);
+}
+
+static int usbredir_check_filter(USBRedirDevice *dev)
+{
+if (dev-interface_info.interface_count == 0) {
+ERROR(No interface info for device\n);
+return -1;
+}
+
+if (dev-filter_rules) {
+if (!usbredirparser_peer_has_cap(dev-parser,
+usb_redir_cap_connect_device_version)) {
+ERROR(Device filter specified and peer does not have the
+ connect_device_version capability\n);
+return -1;
+}
+
+if (usbredirfilter_check(
+dev-filter_rules,
+dev-filter_rules_count,
+dev-device_info.device_class,
+dev-device_info.device_subclass,
+dev-device_info.device_protocol,
+dev-interface_info.interface_class,
+dev-interface_info.interface_subclass,
+dev-interface_info.interface_protocol,
+
Re: [Qemu-devel] [PATCH 27/28] sysbus: apic: ioapic: convert to QEMU Object Model
On 01/25/2012 09:37 AM, Jan Kiszka wrote:
They're exactly the same size (16 lines). If you embed TypeInfo into
DeviceTypeInfo, and introduce a Device specific type registration
function, then you could do:
static DeviceTypeInfo my_device_type_info = {
.type.name = TYPE_MY_DEVICE,
.type.parent = TYPE_PARENT_DEVICE,
.reset = my_device_reset,
And if you introduce some
#define TYPE_UNIMPLEMENTED (void *)dummy_variable
you can easily express
[.field = NULL] = use parent
.field = UNIMPLEMENTED = don't run any handler
I agree with Anthony, this would get really ugly where you are calling
the functions and doing the class initialization. It's a different
style from what we're used to, granted, but the difference in code size
is not relevant (not enough to introduce a level of macro magic, at
least) and the diffstat in this series is misleading because qdev is
left with temporary duplication for now.
(I also complained with him about this a month ago or so).
Paolo
Re: [Qemu-devel] [PATCH] qmp: add BLOCK_MEDIUM_EJECT event
Luiz Capitulino lcapitul...@redhat.com writes:
Libvirt wants to be notified when the guest ejects a medium, so that
it can update its view of the guest.
This code has been originally written by Daniel Berrange. It adds
the event to IDE and SCSI emulation.
Please, note that this only covers guest initiated ejects, that's,
the QMP/HMP commands 'eject' and 'change' are not covered.
Signed-off-by: Luiz Capitulino lcapitul...@redhat.com
---
PS: Bugs are mine.
QMP/qmp-events.txt | 18 ++
block.c| 12
block.h|5 +
block_int.h|3 +++
blockdev.c | 13 +
hw/ide/atapi.c |1 +
hw/scsi-disk.c |1 +
monitor.c |3 +++
monitor.h |1 +
9 files changed, 57 insertions(+), 0 deletions(-)
diff --git a/QMP/qmp-events.txt b/QMP/qmp-events.txt
index af586ec..e414128 100644
--- a/QMP/qmp-events.txt
+++ b/QMP/qmp-events.txt
@@ -26,6 +26,24 @@ Example:
Note: If action is stop, a STOP event will eventually follow the
BLOCK_IO_ERROR event.
+BLOCK_MEDIUM_EJECT
+--
+
+Emitted when the guest succeeds ejecting a medium. If the device has a tray,
+then this event is emitted whenever the guest opens or closes the tray.
This wording could be a bit confusing for devices where the physical
device doesn't have a tray. Our CD-ROMs have a tray. Our floppy
doesn't. Our floppy device model doesn't let the guest eject, so it
doesn't matter right now. But trayless physical devices with removable
media exist.
Suggest to say something like Emitted whenever the guest successfully
ejects or loads a medium, or opens or closes the tray.
+
+Data:
+
+- device: device name (json-string)
This is the backend name, i.e. the name that's shown in info block.
It's not the qdev ID. Consistent with BLOCK_IO_ERROR. Good.
We call too many things device...
+- ejected: true if the tray has been opened or false if it has been closed
+
+Example:
+
+{ event: BLOCK_MEDIUM_EJECT,
+data: { device: ide1-cd1,
+ ejected: true },
+timestamp: { seconds: 1265044230, microseconds: 450486 } }
+
RESET
-
diff --git a/block.c b/block.c
index 3f072f6..b25932b 100644
--- a/block.c
+++ b/block.c
@@ -1998,6 +1998,18 @@ BlockErrorAction bdrv_get_on_error(BlockDriverState
*bs, int is_read)
return is_read ? bs-on_read_error : bs-on_write_error;
}
+void bdrv_dev_set_medium_eject_notify(BlockDriverState *bs,
+ bdrv_dev_medium_eject_notify_cb cb)
+{
+bs-dev_medium_eject_notify_cb = cb;
+}
+
+void bdrv_dev_medium_eject_notify(BlockDriverState *bs, int is_ejected)
+{
+assert(bs-dev_medium_eject_notify_cb);
+bs-dev_medium_eject_notify_cb(bs, is_ejected);
+}
+
int bdrv_is_read_only(BlockDriverState *bs)
{
return bs-read_only;
diff --git a/block.h b/block.h
index 3bd4398..344ca0d 100644
--- a/block.h
+++ b/block.h
@@ -247,6 +247,11 @@ int bdrv_get_translation_hint(BlockDriverState *bs);
void bdrv_set_on_error(BlockDriverState *bs, BlockErrorAction on_read_error,
BlockErrorAction on_write_error);
BlockErrorAction bdrv_get_on_error(BlockDriverState *bs, int is_read);
+typedef void (*bdrv_dev_medium_eject_notify_cb)(BlockDriverState *bs,
+int is_ejected);
+void bdrv_dev_set_medium_eject_notify(BlockDriverState *bs,
+ bdrv_dev_medium_eject_notify_cb cb);
+void bdrv_dev_medium_eject_notify(BlockDriverState *bs, int is_ejected);
int bdrv_is_read_only(BlockDriverState *bs);
int bdrv_is_sg(BlockDriverState *bs);
int bdrv_enable_write_cache(BlockDriverState *bs);
diff --git a/block_int.h b/block_int.h
index 311bd2a..50c34f6 100644
--- a/block_int.h
+++ b/block_int.h
@@ -260,6 +260,9 @@ struct BlockDriverState {
QTAILQ_ENTRY(BlockDriverState) list;
void *private;
+/* Callback for medium eject */
+bdrv_dev_medium_eject_notify_cb dev_medium_eject_notify_cb;
+
QLIST_HEAD(, BdrvTrackedRequest) tracked_requests;
};
Why the indirection? Isn't this always on_medium_eject()?
bdrv_dev_medium_eject_notify_cb() asserts it's not null, and it's never
set to anything else.
If the indirection is justified, why is it per object (in
BlockDriverState) and not per driver (in BlockDriver)?
Update: I found a possible reason, see drive_init() below.
block.h and block_int.h don't typedef their methods, suggest to stick to
that.
diff --git a/blockdev.c b/blockdev.c
index 1f83c88..71b50fa 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -11,6 +11,7 @@
#include blockdev.h
#include monitor.h
#include qerror.h
+#include qjson.h
#include qemu-option.h
#include qemu-config.h
#include sysemu.h
@@ -237,6 +238,17 @@ static bool do_check_io_limits(BlockIOLimit *io_limits)
return true;
}
+static void
[Qemu-devel] [Bug 921208] Re: win7/x64 installer hangs on startup with 0x0000005d.
Please try -cpu kvm64 (yes, even if you are using TCG). -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/921208 Title: win7/x64 installer hangs on startup with 0x005d. Status in QEMU: New Bug description: hi, during booting win7/x64 installer i'm observing a bsod with 0x005d ( msdn: unsupported_processor ). used command line: qemu-system-x86_64 -m 2048 -hda w7-system.img -cdrom win7_x64.iso -boot d adding '-machine accel=kvm' instead of default tcg accel helps to boot. installed software: qemu-1.0 linux-3.2.1 glibc-2.14.1 gcc-4.6.2 hw cpu: processor : 0..7 vendor_id : GenuineIntel cpu family : 6 model : 42 model name : Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz stepping: 7 microcode : 0x14 cpu MHz : 1995.739 cache size : 6144 KB physical id : 0 siblings: 8 core id : 3 cpu cores : 4 apicid : 7 initial apicid : 7 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer xsave avx lahf_lm ida arat epb xsaveopt pln pts dts tpr_shadow vnmi flexpriority ept vpid bogomips: 3992.23 clflush size: 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/921208/+subscriptions
Re: [Qemu-devel] [PATCH 27/28] sysbus: apic: ioapic: convert to QEMU Object Model
On 2012-01-25 11:15, Paolo Bonzini wrote:
On 01/25/2012 09:37 AM, Jan Kiszka wrote:
They're exactly the same size (16 lines). If you embed TypeInfo into
DeviceTypeInfo, and introduce a Device specific type registration
function, then you could do:
static DeviceTypeInfo my_device_type_info = {
.type.name = TYPE_MY_DEVICE,
.type.parent = TYPE_PARENT_DEVICE,
.reset = my_device_reset,
And if you introduce some
#define TYPE_UNIMPLEMENTED (void *)dummy_variable
you can easily express
[.field = NULL] = use parent
.field = UNIMPLEMENTED = don't run any handler
I agree with Anthony, this would get really ugly where you are calling
the functions and doing the class initialization.
I think we need to try it first.
There is a lot of repetition, and that gets boring at beat and ugly at
worst when doing it for hundreds of devices - compared to the number of
base classes we will have.
It's a different
style from what we're used to, granted, but the difference in code size
is not relevant (not enough to introduce a level of macro magic, at
least) and the diffstat in this series is misleading because qdev is
left with temporary duplication for now.
I was looking at the final version Anthony pointed at.
Jan
signature.asc
Description: OpenPGP digital signature
[Qemu-devel] [PATCH v4 0/4] Improve SD controllers emulation
Changelog v3-v4 - PATCH 1/3 rebased to current master; - Fixed .start field use during vmstate save/load; - added get_bufsize() NULL pointer check; - patches 2-4 merged into patches 2-3 v2-v3: - PATCH 2/3 splitted into smaller patches 2-4/5. - SDState structure rearrengment dropped. v1-v2: PATCH 1/3: - .calc_size field replaced with .get_bufsize field in VMStateField; - .size_offset removed completely, macros based on it rewritten to use new .get_bufsize field. PATCH 2/3: - all binary variables in SDState now have bool type; - SDState structure rearranged to ensure alignement; - sd_init(), sd_enable() now receive bool; - new version of PATCH 1/3 now used to save wp_groups array; PATCH 3/3: - DMA transfers modified and now operate with data blocks of BLKSIZE only, like real hardware does; - reset procedure optimized; - new version of PATCH 1/3 now used to save fifo_buffer. First patch of this patch set modifies existing VMStateField interface to ease save/restore functionality implementation for device's dynamically allocated buffers. This modification is used later in second patch to implement SD card's VMStateDescription structure. Fourth patch adds imlementation of new device: SD host controller fully compliant with SD host controller specification version 2.00. It also uses vmstate field modification introduced in first patch. Mitsyanko Igor (4): vmstate: introduce get_bufsize entry in VMStateField hw/sd.c: add SD card save/load support hw/sd.c: convert SD state binary variables to bool hw: Introduce spec. ver. 2.00 compliant SD host controller Makefile.target |1 + hw/g364fb.c |7 +- hw/m48t59.c |7 +- hw/mac_nvram.c |8 +- hw/onenand.c|7 +- hw/sd.c | 126 +++-- hw/sd.h |4 +- hw/sdhc.c | 1570 +++ hw/sdhc.h | 327 savevm.c| 18 +- vmstate.h | 43 +-- 11 files changed, 2030 insertions(+), 88 deletions(-) create mode 100644 hw/sdhc.c create mode 100644 hw/sdhc.h -- 1.7.4.1
[Qemu-devel] [PATCH v4 1/4] vmstate: introduce get_bufsize entry in VMStateField
New get_bufsize field in VMStateField is supposed to help us easily add
save/restore
support of dynamically allocated buffers in device's states.
There are some cases when information about size of dynamically allocated
buffer is
already presented in specific device's state structure, but in such a form that
can not be used with existing VMStateField interface. Currently, we either can
get size from
another variable in device's state as it is with VMSTATE_VBUFFER_* macros, or
we can
also multiply value kept in a variable by a constant with
VMSTATE_BUFFER_MULTIPLY
macro. If we need to perform any other action, we're forced to add additional
variable with size information to device state structure with the only intention
to use it in VMStateDescription. This approach is not very pretty. Adding extra
flags to VMStateFlags enum for every other possible operation with size field
seems redundant, and still it would't cover cases when we need to perform a set
of
operations to get size value.
With get_bufsize callback we can calculate size of dynamic array in whichever
way we need. We don't need .size_offset field anymore, so we can remove it from
VMState Field structure to compensate for extra memory consuption because of
get_bufsize addition. Macros VMSTATE_VBUFFER* are modified to use new callback
instead of .size_offset. Macro VMSTATE_BUFFER_MULTIPLY and VMFlag VMS_MULTIPLY
are removed completely as they are now redundant.
Signed-off-by: Mitsyanko Igor i.mitsya...@samsung.com
---
hw/g364fb.c|7 ++-
hw/m48t59.c|7 ++-
hw/mac_nvram.c |8 +++-
hw/onenand.c |7 ++-
savevm.c | 18 --
vmstate.h | 43 ---
6 files changed, 45 insertions(+), 45 deletions(-)
diff --git a/hw/g364fb.c b/hw/g364fb.c
index 33ec149..9a780a6 100644
--- a/hw/g364fb.c
+++ b/hw/g364fb.c
@@ -495,6 +495,11 @@ static int g364fb_post_load(void *opaque, int version_id)
return 0;
}
+static size_t g364fb_get_vramsize(void *opaque, int version_id)
+{
+return ((G364State *)opaque)-vram_size;
+}
+
static const VMStateDescription vmstate_g364fb = {
.name = g364fb,
.version_id = 1,
@@ -502,7 +507,7 @@ static const VMStateDescription vmstate_g364fb = {
.minimum_version_id_old = 1,
.post_load = g364fb_post_load,
.fields = (VMStateField[]) {
-VMSTATE_VBUFFER_UINT32(vram, G364State, 1, NULL, 0, vram_size),
+VMSTATE_VBUFFER(vram, G364State, 1, NULL, 0, g364fb_get_vramsize),
VMSTATE_BUFFER_UNSAFE(color_palette, G364State, 0, 256 * 3),
VMSTATE_BUFFER_UNSAFE(cursor_palette, G364State, 0, 9),
VMSTATE_UINT16_ARRAY(cursor, G364State, 512),
diff --git a/hw/m48t59.c b/hw/m48t59.c
index c043996..ea824ff 100644
--- a/hw/m48t59.c
+++ b/hw/m48t59.c
@@ -582,6 +582,11 @@ static const MemoryRegionOps nvram_ops = {
.endianness = DEVICE_NATIVE_ENDIAN,
};
+static size_t m48t59_get_bufsize(void *opaque, int version_id)
+{
+return ((M48t59State *)opaque)-size;
+}
+
static const VMStateDescription vmstate_m48t59 = {
.name = m48t59,
.version_id = 1,
@@ -590,7 +595,7 @@ static const VMStateDescription vmstate_m48t59 = {
.fields = (VMStateField[]) {
VMSTATE_UINT8(lock, M48t59State),
VMSTATE_UINT16(addr, M48t59State),
-VMSTATE_VBUFFER_UINT32(buffer, M48t59State, 0, NULL, 0, size),
+VMSTATE_VBUFFER(buffer, M48t59State, 0, NULL, 0, m48t59_get_bufsize),
VMSTATE_END_OF_LIST()
}
};
diff --git a/hw/mac_nvram.c b/hw/mac_nvram.c
index ed0a2b7..220e745 100644
--- a/hw/mac_nvram.c
+++ b/hw/mac_nvram.c
@@ -100,13 +100,19 @@ static const MemoryRegionOps macio_nvram_ops = {
.endianness = DEVICE_NATIVE_ENDIAN,
};
+static size_t macio_nvram_get_datasize(void *opaque, int version_id)
+{
+return ((MacIONVRAMState *)opaque)-size;
+}
+
static const VMStateDescription vmstate_macio_nvram = {
.name = macio_nvram,
.version_id = 1,
.minimum_version_id = 1,
.minimum_version_id_old = 1,
.fields = (VMStateField[]) {
-VMSTATE_VBUFFER_UINT32(data, MacIONVRAMState, 0, NULL, 0, size),
+VMSTATE_VBUFFER(data, MacIONVRAMState, 0, NULL, 0,
+macio_nvram_get_datasize),
VMSTATE_END_OF_LIST()
}
};
diff --git a/hw/onenand.c b/hw/onenand.c
index 33c9718..2543b33 100644
--- a/hw/onenand.c
+++ b/hw/onenand.c
@@ -160,6 +160,11 @@ static int onenand_post_load(void *opaque, int version_id)
return 0;
}
+static size_t onenand_get_blockwpsize(void *opaque, int version_id)
+{
+return ((OneNANDState *)opaque)-blocks;
+}
+
static const VMStateDescription vmstate_onenand = {
.name = onenand,
.version_id = 1,
@@ -181,7 +186,7 @@ static const VMStateDescription vmstate_onenand = {
VMSTATE_UINT16(intstatus, OneNANDState),
VMSTATE_UINT16(wpstatus, OneNANDState),
VMSTATE_INT32(secs_cur, OneNANDState),
-
Re: [Qemu-devel] [PATCH 27/28] sysbus: apic: ioapic: convert to QEMU Object Model
On 01/25/2012 11:27 AM, Jan Kiszka wrote: I agree with Anthony, this would get really ugly where you are calling the functions and doing the class initialization. I think we need to try it first. There is a lot of repetition, and that gets boring at beat and ugly at worst when doing it for hundreds of devices - compared to the number of base classes we will have. I think we have to trust Anthony's judgement that he tried it and didn't like it. Perhaps he didn't try _exactly_ the version that you gave, but I think it's not fair to say please try redoing it this way---maybe a month after the first version has been posted. So far, we were always able to reach a compromise between Anthony's taste and others', and also on the order with which to do things. I understand this is a pretty major issue, but it's going to be one more such compromise (and one that I thought had already been settled). Note that it's not impossible to change directions! QOM started with the idea of converting devices _last_. We are converting them _first_. That was a very early change in plans, and very much against Anthony. It's fair and natural that the balance swings in the other direction now. As a reviewer, the later you join the party, the harder it will be to swallow the pill. It's a different style from what we're used to, granted, but the difference in code size is not relevant (not enough to introduce a level of macro magic, at least) and the diffstat in this series is misleading because qdev is left with temporary duplication for now. I was looking at the final version Anthony pointed at. There _are_ things that leave something to be desired in there. For example I don't like accessing the base class with a different name, as in: DeviceClass *dc = DEVICE_CLASS(klass); PCIDeviceClass *k = PCI_DEVICE_CLASS(klass); dc-props = e100_properties; dc-desc = info-desc; k-vendor_id = PCI_VENDOR_ID_INTEL; k-class_id = PCI_CLASS_NETWORK_ETHERNET; k-romfile = pxe-eepro100.rom; ... and a few more things that we'll discuss as soon as he posts the third instalment. I know we're all busy, but the only way to solve these problems is prompt review. Paolo
[Qemu-devel] [PATCH v4 3/4] hw/sd.c: convert SD state binary variables to bool
SDstate members wp_switch, wp_groups, spi, expecting_acmd and enable are in
fact binary variables s converting them to type bool makes code a little
bit more clear.
API modified to reflect new variables types.
Signed-off-by: Mitsyanko Igor i.mitsya...@samsung.com
---
hw/sd.c | 42 +-
hw/sd.h |4 ++--
2 files changed, 23 insertions(+), 23 deletions(-)
diff --git a/hw/sd.c b/hw/sd.c
index bfe7f58..3c954fd 100644
--- a/hw/sd.c
+++ b/hw/sd.c
@@ -84,8 +84,8 @@ struct SDState {
uint32_t card_status;
uint8_t sd_status[64];
uint32_t vhs;
-uint32_t wp_switch;
-uint32_t *wp_groups;
+bool wp_switch;
+bool *wp_groups;
uint64_t size;
uint32_t blk_len;
uint32_t erase_start;
@@ -94,12 +94,12 @@ struct SDState {
uint32_t pwd_len;
uint8_t function_group[6];
-int spi;
+bool spi;
uint8_t current_cmd;
/* True if we will handle the next command as an ACMD. Note that this does
* *not* track the APP_CMD status bit!
*/
-uint32_t expecting_acmd;
+bool expecting_acmd;
uint32_t blk_written;
uint64_t data_start;
uint32_t data_offset;
@@ -109,7 +109,7 @@ struct SDState {
BlockDriverState *bdrv;
uint8_t *buf;
-uint32_t enable;
+bool enable;
};
static void sd_set_mode(SDState *sd)
@@ -418,15 +418,15 @@ static void sd_reset(SDState *sd, BlockDriverState *bdrv)
if (sd-wp_groups)
g_free(sd-wp_groups);
-sd-wp_switch = bdrv ? bdrv_is_read_only(bdrv) : 0;
-sd-wp_groups = g_new0(uint32_t, sect);
+sd-wp_switch = bdrv ? bdrv_is_read_only(bdrv) : false;
+sd-wp_groups = g_new0(bool, sect);
memset(sd-function_group, 0, sizeof(sd-function_group));
sd-erase_start = 0;
sd-erase_end = 0;
sd-size = size;
sd-blk_len = 0x200;
sd-pwd_len = 0;
-sd-expecting_acmd = 0;
+sd-expecting_acmd = false;
}
static void sd_cardchange(void *opaque, bool load)
@@ -447,7 +447,7 @@ static const BlockDevOps sd_block_ops = {
static size_t sd_get_wpgroups_size(void *opaque, int version_id)
{
SDState *sd = (SDState *)opaque;
-return sizeof(uint32_t) * (sd-size (HWBLOCK_SHIFT + SECTOR_SHIFT +
+return sizeof(bool) * (sd-size (HWBLOCK_SHIFT + SECTOR_SHIFT +
WPGROUP_SHIFT));
}
@@ -472,13 +472,13 @@ static const VMStateDescription sd_vmstate = {
VMSTATE_UINT32(pwd_len, SDState),
VMSTATE_UINT8_ARRAY(function_group, SDState, 6),
VMSTATE_UINT8(current_cmd, SDState),
-VMSTATE_UINT32(expecting_acmd, SDState),
+VMSTATE_BOOL(expecting_acmd, SDState),
VMSTATE_UINT32(blk_written, SDState),
VMSTATE_UINT64(data_start, SDState),
VMSTATE_UINT32(data_offset, SDState),
VMSTATE_UINT8_ARRAY(data, SDState, 512),
VMSTATE_BUFFER_UNSAFE(buf, SDState, 1, 512),
-VMSTATE_UINT32(enable, SDState),
+VMSTATE_BOOL(enable, SDState),
VMSTATE_END_OF_LIST()
}
};
@@ -487,14 +487,14 @@ static const VMStateDescription sd_vmstate = {
whether card should be in SSI or MMC/SD mode. It is also up to the
board to ensure that ssi transfers only occur when the chip select
is asserted. */
-SDState *sd_init(BlockDriverState *bs, int is_spi)
+SDState *sd_init(BlockDriverState *bs, bool is_spi)
{
SDState *sd;
sd = (SDState *) g_malloc0(sizeof(SDState));
sd-buf = qemu_blockalign(bs, 512);
sd-spi = is_spi;
-sd-enable = 1;
+sd-enable = true;
sd_reset(sd, bs);
if (sd-bdrv) {
bdrv_attach_dev_nofail(sd-bdrv, sd);
@@ -578,7 +578,7 @@ static void sd_function_switch(SDState *sd, uint32_t arg)
sd-data[66] = crc 0xff;
}
-static inline int sd_wp_addr(SDState *sd, uint32_t addr)
+static inline bool sd_wp_addr(SDState *sd, uint32_t addr)
{
return sd-wp_groups[addr
(HWBLOCK_SHIFT + SECTOR_SHIFT + WPGROUP_SHIFT)];
@@ -604,7 +604,7 @@ static void sd_lock_command(SDState *sd)
sd-card_status |= LOCK_UNLOCK_FAILED;
return;
}
-memset(sd-wp_groups, 0, sizeof(uint32_t) * (sd-size
+memset(sd-wp_groups, 0, sizeof(bool) * (sd-size
(HWBLOCK_SHIFT + SECTOR_SHIFT + WPGROUP_SHIFT)));
sd-csd[14] = ~0x10;
sd-card_status = ~CARD_IS_LOCKED;
@@ -1052,7 +1052,7 @@ static sd_rsp_type_t sd_normal_command(SDState *sd,
sd-state = sd_programming_state;
sd-wp_groups[addr (HWBLOCK_SHIFT +
-SECTOR_SHIFT + WPGROUP_SHIFT)] = 1;
+SECTOR_SHIFT + WPGROUP_SHIFT)] = true;
/* Bzzztt Operation complete. */
sd-state = sd_transfer_state;
return sd_r1b;
@@ -1072,7 +1072,7 @@ static sd_rsp_type_t sd_normal_command(SDState *sd,
sd-state = sd_programming_state;
sd-wp_groups[addr (HWBLOCK_SHIFT +
-SECTOR_SHIFT +
[Qemu-devel] [PATCH v4 2/4] hw/sd.c: add SD card save/load support
This patch updates SD card emulation to support save/load of card's state.
Signed-off-by: Mitsyanko Igor i.mitsya...@samsung.com
---
hw/sd.c | 102 +--
1 files changed, 73 insertions(+), 29 deletions(-)
diff --git a/hw/sd.c b/hw/sd.c
index 07eb263..bfe7f58 100644
--- a/hw/sd.c
+++ b/hw/sd.c
@@ -54,24 +54,28 @@ typedef enum {
sd_illegal = -2,
} sd_rsp_type_t;
+enum {
+sd_inactive,
+sd_card_identification_mode,
+sd_data_transfer_mode,
+};
+
+enum {
+sd_inactive_state = -1,
+sd_idle_state = 0,
+sd_ready_state,
+sd_identification_state,
+sd_standby_state,
+sd_transfer_state,
+sd_sendingdata_state,
+sd_receivingdata_state,
+sd_programming_state,
+sd_disconnect_state,
+};
+
struct SDState {
-enum {
-sd_inactive,
-sd_card_identification_mode,
-sd_data_transfer_mode,
-} mode;
-enum {
-sd_inactive_state = -1,
-sd_idle_state = 0,
-sd_ready_state,
-sd_identification_state,
-sd_standby_state,
-sd_transfer_state,
-sd_sendingdata_state,
-sd_receivingdata_state,
-sd_programming_state,
-sd_disconnect_state,
-} state;
+uint32_t mode;
+int32_t state;
uint32_t ocr;
uint8_t scr[8];
uint8_t cid[16];
@@ -80,23 +84,23 @@ struct SDState {
uint32_t card_status;
uint8_t sd_status[64];
uint32_t vhs;
-int wp_switch;
-int *wp_groups;
+uint32_t wp_switch;
+uint32_t *wp_groups;
uint64_t size;
-int blk_len;
+uint32_t blk_len;
uint32_t erase_start;
uint32_t erase_end;
uint8_t pwd[16];
-int pwd_len;
-int function_group[6];
+uint32_t pwd_len;
+uint8_t function_group[6];
int spi;
-int current_cmd;
+uint8_t current_cmd;
/* True if we will handle the next command as an ACMD. Note that this does
* *not* track the APP_CMD status bit!
*/
-int expecting_acmd;
-int blk_written;
+uint32_t expecting_acmd;
+uint32_t blk_written;
uint64_t data_start;
uint32_t data_offset;
uint8_t data[512];
@@ -105,7 +109,7 @@ struct SDState {
BlockDriverState *bdrv;
uint8_t *buf;
-int enable;
+uint32_t enable;
};
static void sd_set_mode(SDState *sd)
@@ -415,8 +419,8 @@ static void sd_reset(SDState *sd, BlockDriverState *bdrv)
if (sd-wp_groups)
g_free(sd-wp_groups);
sd-wp_switch = bdrv ? bdrv_is_read_only(bdrv) : 0;
-sd-wp_groups = (int *) g_malloc0(sizeof(int) * sect);
-memset(sd-function_group, 0, sizeof(int) * 6);
+sd-wp_groups = g_new0(uint32_t, sect);
+memset(sd-function_group, 0, sizeof(sd-function_group));
sd-erase_start = 0;
sd-erase_end = 0;
sd-size = size;
@@ -440,6 +444,45 @@ static const BlockDevOps sd_block_ops = {
.change_media_cb = sd_cardchange,
};
+static size_t sd_get_wpgroups_size(void *opaque, int version_id)
+{
+SDState *sd = (SDState *)opaque;
+return sizeof(uint32_t) * (sd-size (HWBLOCK_SHIFT + SECTOR_SHIFT +
+WPGROUP_SHIFT));
+}
+
+static const VMStateDescription sd_vmstate = {
+.name = sd_card,
+.version_id = 1,
+.minimum_version_id = 1,
+.fields = (VMStateField[]) {
+VMSTATE_UINT32(mode, SDState),
+VMSTATE_INT32(state, SDState),
+VMSTATE_UINT8_ARRAY(cid, SDState, 16),
+VMSTATE_UINT8_ARRAY(csd, SDState, 16),
+VMSTATE_UINT16(rca, SDState),
+VMSTATE_UINT32(card_status, SDState),
+VMSTATE_PARTIAL_BUFFER(sd_status, SDState, 1),
+VMSTATE_UINT32(vhs, SDState),
+VMSTATE_VBUFFER(wp_groups, SDState, 1, NULL, 0, sd_get_wpgroups_size),
+VMSTATE_UINT32(blk_len, SDState),
+VMSTATE_UINT32(erase_start, SDState),
+VMSTATE_UINT32(erase_end, SDState),
+VMSTATE_UINT8_ARRAY(pwd, SDState, 16),
+VMSTATE_UINT32(pwd_len, SDState),
+VMSTATE_UINT8_ARRAY(function_group, SDState, 6),
+VMSTATE_UINT8(current_cmd, SDState),
+VMSTATE_UINT32(expecting_acmd, SDState),
+VMSTATE_UINT32(blk_written, SDState),
+VMSTATE_UINT64(data_start, SDState),
+VMSTATE_UINT32(data_offset, SDState),
+VMSTATE_UINT8_ARRAY(data, SDState, 512),
+VMSTATE_BUFFER_UNSAFE(buf, SDState, 1, 512),
+VMSTATE_UINT32(enable, SDState),
+VMSTATE_END_OF_LIST()
+}
+};
+
/* We do not model the chip select pin, so allow the board to select
whether card should be in SSI or MMC/SD mode. It is also up to the
board to ensure that ssi transfers only occur when the chip select
@@ -457,6 +500,7 @@ SDState *sd_init(BlockDriverState *bs, int is_spi)
bdrv_attach_dev_nofail(sd-bdrv, sd);
bdrv_set_dev_ops(sd-bdrv, sd_block_ops, sd);
}
+vmstate_register(NULL, -1, sd_vmstate, sd);
return sd;
}
@@ -560,7 +604,7 @@ static void sd_lock_command(SDState *sd)
[Qemu-devel] commit 67feec6ed854b3618b37ccf050b90192cbb96e0f breaks compilation of hw/pci.c
Hi all,
from the qemu-kvm master I did some bisectioning because I cannot compile it.
My error is:
In file included from /home/erik/qemu-kvm/hw/pci.c:36:
/qmp-commands.h:3: error: expected identifier or '(' before '{' token
/qmp-commands.h:10: error: expected identifier or '(' before ',' token
/qmp-commands.h:20: error: expected identifier or '(' before ',' token
/qmp-commands.h:30: error: expected identifier or '(' before ',' token
/qmp-commands.h:40: error: expected identifier or '(' before ',' token
/qmp-commands.h:50: error: expected identifier or '(' before ',' token
/qmp-commands.h:60: error: expected identifier or '(' before ',' token
/qmp-commands.h:70: error: expected identifier or '(' before ',' token
/qmp-commands.h:80: error: expected identifier or '(' before ',' token
/qmp-commands.h:90: error: expected identifier or '(' before ',' token
/qmp-commands.h:100: error: expected identifier or '(' before ',' token
/qmp-commands.h:110: error: expected identifier or '(' before ',' token
/qmp-commands.h:120: error: expected identifier or '(' before ',' token
/qmp-commands.h:130: error: expected identifier or '(' before ',' token
/qmp-commands.h:140: error: expected identifier or '(' before ',' token
/qmp-commands.h:154: error: expected identifier or '(' before ',' token
/qmp-commands.h:164: error: expected identifier or '(' before ',' token
/qmp-commands.h:174: error: expected identifier or '(' before ',' token
/qmp-commands.h:184: error: expected identifier or '(' before ',' token
/qmp-commands.h:194: error: expected identifier or '(' before ',' token
/qmp-commands.h:204: error: expected identifier or '(' before ',' token
/qmp-commands.h:214: error: expected identifier or '(' before ',' token
/qmp-commands.h:224: error: expected identifier or '(' before ',' token
/qmp-commands.h:233: error: expected identifier or '(' before ',' token
/qmp-commands.h:244: error: expected identifier or '(' before ',' token
/qmp-commands.h:254: error: expected identifier or '(' before ',' token
/qmp-commands.h:264: error: expected identifier or '(' before ',' token
/qmp-commands.h:274: error: expected identifier or '(' before ',' token
/qmp-commands.h:284: error: expected identifier or '(' before ',' token
/qmp-commands.h:294: error: expected identifier or '(' before ',' token
/qmp-commands.h:304: error: expected identifier or '(' before ',' token
/qmp-commands.h:314: error: expected identifier or '(' before ',' token
/qmp-commands.h:323: error: expected identifier or '(' before ',' token
/qmp-commands.h:333: error: expected identifier or '(' before ',' token
/home/erik/qemu-kvm/hw/pci.c:1432: warning: no previous prototype for
'qmp_query_pci'
Here the results of the bisectioning (master against qemu-kvm-1.0)
git bisect start
# bad: [07e1e20b47d3e7841dc63a843502600d0a16542f] qemu-kvm: Resolve
unneeded diffs to upstream in pc-bios
git bisect bad 07e1e20b47d3e7841dc63a843502600d0a16542f
# good: [30c044521889195f54a9f2c21310894f545994e8] Merge commit 'v1.0' into
next
git bisect good 30c044521889195f54a9f2c21310894f545994e8
# good: [b9b2008bbff49e2714491a95109e1189e54a6491] block: dma_bdrv_* does
not return NULL
git bisect good b9b2008bbff49e2714491a95109e1189e54a6491
# good: [05c194384f836240ea4c2da5fa3be43a54bff021] pseries: Emit device
tree nodes in reg order
git bisect good 05c194384f836240ea4c2da5fa3be43a54bff021
# bad: [372951014b5008ca047e4dfbfaf4003bc27a2f6b] qemu-kvm: Fix
save/restore of in-kernel i8259
git bisect bad 372951014b5008ca047e4dfbfaf4003bc27a2f6b
# bad: [682a3c07f0e28d2532c911a44a9b6142d6299cc2] Merge commit
'c5705a7728b4a6bc9e4f2d35911adbaf28042b25' into upstream-merge
git bisect bad 682a3c07f0e28d2532c911a44a9b6142d6299cc2
# good: [2817b260e3ca57ee091fc56403bfafdcc18b6a96] vhost: avoid
cpu_get_physical_page_desc()
git bisect good 2817b260e3ca57ee091fc56403bfafdcc18b6a96
# bad: [ce00ce6a909bc9b1ecc697d826d71b2c7ab07994] Merge commit
'48a18b3c698295e4d891f34e919615e84e20f027' into upstream-merge
git bisect bad ce00ce6a909bc9b1ecc697d826d71b2c7ab07994
# bad: [90695ad2ede04a7ce6a86e8283e82f8bdbe8a54a] Merge commit
'217bfb445b54db618a30f3a39170bebd9fd9dbf2' into upstream-merge
git bisect bad 90695ad2ede04a7ce6a86e8283e82f8bdbe8a54a
# bad: [e021b07bd795c76035c48c158943dd8ee47e9c27] qemu-kvm: Move
make-release to scripts/qemu-kvm
git bisect bad e021b07bd795c76035c48c158943dd8ee47e9c27
# bad: [67feec6ed854b3618b37ccf050b90192cbb96e0f] qemu-kvm: fix improper
nmi emulation
git bisect bad 67feec6ed854b3618b37ccf050b90192cbb96e0f
final git bisect result:
67feec6ed854b3618b37ccf050b90192cbb96e0f is the first bad commit
commit 67feec6ed854b3618b37ccf050b90192cbb96e0f
Author: Lai Jiangshan la...@cn.fujitsu.com
Date: Tue Oct 18 00:00:06 2011 +0800
qemu-kvm: fix improper nmi emulation
Currently, NMI interrupt is blindly sent to all the vCPUs when NMI
button event happens. This doesn't properly emulate real hardware on
which NMI button event triggers LINT1. Because of this, NMI is sent to
Re: [Qemu-devel] commit 67feec6ed854b3618b37ccf050b90192cbb96e0f breaks compilation of hw/pci.c
On Wed, Jan 25, 2012 at 12:22:51PM +0100, erik.r...@rdsoftware.de wrote:
Hi all,
from the qemu-kvm master I did some bisectioning because I cannot compile it.
I got the same error because of some stale .h file. Removing it resolved
the problem, but I do not remember what was the file exactly. Try git
status
My error is:
In file included from /home/erik/qemu-kvm/hw/pci.c:36:
/qmp-commands.h:3: error: expected identifier or '(' before '{' token
/qmp-commands.h:10: error: expected identifier or '(' before ',' token
/qmp-commands.h:20: error: expected identifier or '(' before ',' token
/qmp-commands.h:30: error: expected identifier or '(' before ',' token
/qmp-commands.h:40: error: expected identifier or '(' before ',' token
/qmp-commands.h:50: error: expected identifier or '(' before ',' token
/qmp-commands.h:60: error: expected identifier or '(' before ',' token
/qmp-commands.h:70: error: expected identifier or '(' before ',' token
/qmp-commands.h:80: error: expected identifier or '(' before ',' token
/qmp-commands.h:90: error: expected identifier or '(' before ',' token
/qmp-commands.h:100: error: expected identifier or '(' before ',' token
/qmp-commands.h:110: error: expected identifier or '(' before ',' token
/qmp-commands.h:120: error: expected identifier or '(' before ',' token
/qmp-commands.h:130: error: expected identifier or '(' before ',' token
/qmp-commands.h:140: error: expected identifier or '(' before ',' token
/qmp-commands.h:154: error: expected identifier or '(' before ',' token
/qmp-commands.h:164: error: expected identifier or '(' before ',' token
/qmp-commands.h:174: error: expected identifier or '(' before ',' token
/qmp-commands.h:184: error: expected identifier or '(' before ',' token
/qmp-commands.h:194: error: expected identifier or '(' before ',' token
/qmp-commands.h:204: error: expected identifier or '(' before ',' token
/qmp-commands.h:214: error: expected identifier or '(' before ',' token
/qmp-commands.h:224: error: expected identifier or '(' before ',' token
/qmp-commands.h:233: error: expected identifier or '(' before ',' token
/qmp-commands.h:244: error: expected identifier or '(' before ',' token
/qmp-commands.h:254: error: expected identifier or '(' before ',' token
/qmp-commands.h:264: error: expected identifier or '(' before ',' token
/qmp-commands.h:274: error: expected identifier or '(' before ',' token
/qmp-commands.h:284: error: expected identifier or '(' before ',' token
/qmp-commands.h:294: error: expected identifier or '(' before ',' token
/qmp-commands.h:304: error: expected identifier or '(' before ',' token
/qmp-commands.h:314: error: expected identifier or '(' before ',' token
/qmp-commands.h:323: error: expected identifier or '(' before ',' token
/qmp-commands.h:333: error: expected identifier or '(' before ',' token
/home/erik/qemu-kvm/hw/pci.c:1432: warning: no previous prototype for
'qmp_query_pci'
Here the results of the bisectioning (master against qemu-kvm-1.0)
git bisect start
# bad: [07e1e20b47d3e7841dc63a843502600d0a16542f] qemu-kvm: Resolve
unneeded diffs to upstream in pc-bios
git bisect bad 07e1e20b47d3e7841dc63a843502600d0a16542f
# good: [30c044521889195f54a9f2c21310894f545994e8] Merge commit 'v1.0' into
next
git bisect good 30c044521889195f54a9f2c21310894f545994e8
# good: [b9b2008bbff49e2714491a95109e1189e54a6491] block: dma_bdrv_* does
not return NULL
git bisect good b9b2008bbff49e2714491a95109e1189e54a6491
# good: [05c194384f836240ea4c2da5fa3be43a54bff021] pseries: Emit device
tree nodes in reg order
git bisect good 05c194384f836240ea4c2da5fa3be43a54bff021
# bad: [372951014b5008ca047e4dfbfaf4003bc27a2f6b] qemu-kvm: Fix
save/restore of in-kernel i8259
git bisect bad 372951014b5008ca047e4dfbfaf4003bc27a2f6b
# bad: [682a3c07f0e28d2532c911a44a9b6142d6299cc2] Merge commit
'c5705a7728b4a6bc9e4f2d35911adbaf28042b25' into upstream-merge
git bisect bad 682a3c07f0e28d2532c911a44a9b6142d6299cc2
# good: [2817b260e3ca57ee091fc56403bfafdcc18b6a96] vhost: avoid
cpu_get_physical_page_desc()
git bisect good 2817b260e3ca57ee091fc56403bfafdcc18b6a96
# bad: [ce00ce6a909bc9b1ecc697d826d71b2c7ab07994] Merge commit
'48a18b3c698295e4d891f34e919615e84e20f027' into upstream-merge
git bisect bad ce00ce6a909bc9b1ecc697d826d71b2c7ab07994
# bad: [90695ad2ede04a7ce6a86e8283e82f8bdbe8a54a] Merge commit
'217bfb445b54db618a30f3a39170bebd9fd9dbf2' into upstream-merge
git bisect bad 90695ad2ede04a7ce6a86e8283e82f8bdbe8a54a
# bad: [e021b07bd795c76035c48c158943dd8ee47e9c27] qemu-kvm: Move
make-release to scripts/qemu-kvm
git bisect bad e021b07bd795c76035c48c158943dd8ee47e9c27
# bad: [67feec6ed854b3618b37ccf050b90192cbb96e0f] qemu-kvm: fix improper
nmi emulation
git bisect bad 67feec6ed854b3618b37ccf050b90192cbb96e0f
final git bisect result:
67feec6ed854b3618b37ccf050b90192cbb96e0f is the first bad commit
commit 67feec6ed854b3618b37ccf050b90192cbb96e0f
Author: Lai Jiangshan
Re: [Qemu-devel] qemu-kvm upstreaming: Do we want -kvm-shadow-memory semantics?
On 01/19/2012 07:39 PM, Jan Kiszka wrote: On 2012-01-19 18:28, Marcelo Tosatti wrote: On Thu, Jan 19, 2012 at 01:46:39PM +0100, Jan Kiszka wrote: Hi again, do we need some KVM knob comparable to qemu-kvm's -kvm-shadow-memory in upstream? If yes: The underlying IOCTL is x86-only. Are other archs interested in this long-term as well, ie. should the control become arch-independent? Jan Last time i asked about removal, Avi wished for it to remain. Then I guess he should comment on this after returning to work. :) -kvm-shadow-memory is becoming less meaningful for ordinary workloads since everything uses TDP these days. It's still meaningful for testing (forcing aggressive cache replacement), or perhaps nested virtualization. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [Xen-devel] [PATCH v3 5/6] xen: record physmap changes to xenstore
On 01/19/2012 04:16 PM, Stefano Stabellini wrote: If you are migrating to a newer qemu then the original-addr could in principal change, I think. Not unless the implementation of qemu_ram_alloc_from_ptr or find_ram_offset change, but these are core qemu functions. Both of these functions will be removed. There will no longer be a qemu-internal address space for physical memory; instead memory will be addressed using a (MemoryRegion, offset) pair. We can/will hook memory_region_init_ram() to call xen_ram_alloc() which can then generate those old addresses, but those (like qemu_ram_alloc()) are dependent on allocation order and you shouldn't depend on them returning stable values. Or the device starts allocating more memory of course, but it wouldn't be the same device anymore. In any case, if we also match on the MemoryRegion name we cannot go wrong. Match on just the MemoryRegion (and match on the object itself, not the name; see xen_register_framebuffer()). We could add some additional info to better identify the physmap entry, probably the best we could use is the memory_region name. And/Or the PCI BDF + BAR? I don't think we can get the PCI BDF from the Xen MemoryListener, but we can get the MemoryRegion. The most identifying info in it I think is the name, for example for vga would be vga.vram. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] git bisect results
Hi Jan,
This little change fixes my problem with the usb-tablet update rate.
Can you please verify if this has some side effects?
If not, can you post a real patch?
I don't know how to handle the whole patching and committing stuff exactly.
Thanks.
Erik
--
diff --git a/ui/sdl.c b/ui/sdl.c
index 8cafc44..ecd70db 100644
--- a/ui/sdl.c
+++ b/ui/sdl.c
@@ -769,7 +769,7 @@ static void handle_mousemotion(DisplayState *ds,
SDL_Event *ev)
{
int max_x, max_y;
-if (is_graphic_console()
+/*if (is_graphic_console()
(kbd_mouse_is_absolute() || absolute_enabled)) {
max_x = real_screen-w - 1;
max_y = real_screen-h - 1;
@@ -782,7 +782,7 @@ static void handle_mousemotion(DisplayState *ds,
SDL_Event *ev)
ev-motion.y 0 ev-motion.y max_y)) {
sdl_grab_start();
}
-}
+}*/
if (gui_grab || kbd_mouse_is_absolute() || absolute_enabled) {
sdl_send_mouse_event(ev-motion.xrel, ev-motion.yrel, 0,
ev-motion.x, ev-motion.y, ev-motion.state);
Re: [Qemu-devel] [PATCH v6 02/11] Add uleb encoding/decoding functions
On 01/25/2012 01:26 PM, Orit Wasserman wrote:
Implement Unsigned Little Endian Base 128.
+/* ULEB128 */
+int uleb128_encode_small(uint8_t *out, uint32_t n);
+int uleb128_decode_small(const uint8 *in, uint32_t *n);
+
#endif
diff --git a/savevm.c b/savevm.c
index 80be1ff..304db31 100644
--- a/savevm.c
+++ b/savevm.c
@@ -2297,3 +2297,29 @@ void vmstate_register_ram_global(MemoryRegion *mr)
{
vmstate_register_ram(mr, NULL);
}
+
+/* ULEB128 */
+int uleb128_encode_small(uint8_t *out, uint32_t n)
+{
assert(n = 0x3fff);
+if (n 0x80) {
+*out++ = n;
+return 1;
+} else {
+*out++ = (n 0x7f) | 0x80;
+*out++ = n 7;
return 2?
+}
+return 0;
+}
+
+int uleb128_decode_small(const uint8 *in, uint32_t *n)
+{
+if (!(*in 0x80)) {
+*n = *in++;
+return 1;
+} else {
+*n = *in++ 0x7f;
assert(!(*in 0x80));
+*n |= *in++ 7;
+return 0;
return 2?
+}
+}
+
--
error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [PATCH v6 00/11] XBRLE delta for live migration of large memory app
On 01/25/2012 01:26 PM, Orit Wasserman wrote:
The run length is encoded using ULEB128 (http://en.wikipedia.org/wiki/LEB128)
page = zrun
| zrun nzrun
| zrun nzrun page
zrun = length
nzrun = length byte...
length = uleb128 encoded integer
We can improve this by a further 2 bytes per page by not encoding the
trailing zero run:
page = zrun nzrun
| zrun nzrun page
so, a page containing
{ 10*0, 7, 4085*0 }
would be encoded as
0x10 0x01 0x07
without the trailing 4085 zrun. This works because you no longer send
unchanged pages.
--
error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [Xen-devel] [PATCH v3 5/6] xen: record physmap changes to xenstore
On Wed, 25 Jan 2012, Avi Kivity wrote: On 01/19/2012 04:16 PM, Stefano Stabellini wrote: If you are migrating to a newer qemu then the original-addr could in principal change, I think. Not unless the implementation of qemu_ram_alloc_from_ptr or find_ram_offset change, but these are core qemu functions. Both of these functions will be removed. There will no longer be a qemu-internal address space for physical memory; instead memory will be addressed using a (MemoryRegion, offset) pair. We can/will hook memory_region_init_ram() to call xen_ram_alloc() which can then generate those old addresses, but those (like qemu_ram_alloc()) are dependent on allocation order and you shouldn't depend on them returning stable values. Or the device starts allocating more memory of course, but it wouldn't be the same device anymore. In any case, if we also match on the MemoryRegion name we cannot go wrong. Match on just the MemoryRegion (and match on the object itself, not the name; see xen_register_framebuffer()). I agree that would be ideal, but how can that work across save/restore? Unless we introduce some other kind of identifier for MemoryRegion, the best we have is the name right now, correct?
Re: [Qemu-devel] qemu-kvm upstreaming: Do we want -kvm-shadow-memory semantics?
On 2012-01-25 12:38, Avi Kivity wrote: On 01/19/2012 07:39 PM, Jan Kiszka wrote: On 2012-01-19 18:28, Marcelo Tosatti wrote: On Thu, Jan 19, 2012 at 01:46:39PM +0100, Jan Kiszka wrote: Hi again, do we need some KVM knob comparable to qemu-kvm's -kvm-shadow-memory in upstream? If yes: The underlying IOCTL is x86-only. Are other archs interested in this long-term as well, ie. should the control become arch-independent? Jan Last time i asked about removal, Avi wished for it to remain. Then I guess he should comment on this after returning to work. :) -kvm-shadow-memory is becoming less meaningful for ordinary workloads since everything uses TDP these days. It's still meaningful for testing (forcing aggressive cache replacement), or perhaps nested virtualization. So, is it used for testing in fact? Would a machine option kvm_shadow_memory=n be desirable? Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
Re: [Qemu-devel] [Xen-devel] [PATCH v3 5/6] xen: record physmap changes to xenstore
On 01/25/2012 01:55 PM, Stefano Stabellini wrote: Match on just the MemoryRegion (and match on the object itself, not the name; see xen_register_framebuffer()). I agree that would be ideal, but how can that work across save/restore? Unless we introduce some other kind of identifier for MemoryRegion, the best we have is the name right now, correct? Right, you can't put the pointer in save/restore, the name is the only option (and that's what qemu uses in its native save format). I thought you were talking about internal matching, like in a previous version of the patch/discussion. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] qemu-kvm upstreaming: Do we want -kvm-shadow-memory semantics?
On 01/25/2012 01:57 PM, Jan Kiszka wrote: -kvm-shadow-memory is becoming less meaningful for ordinary workloads since everything uses TDP these days. It's still meaningful for testing (forcing aggressive cache replacement), or perhaps nested virtualization. So, is it used for testing in fact? It is not, but it should be. There's an extra_params option in autotest, I'll start using it to stress the mmu some more, even though it's going to slow things down for me. Would a machine option kvm_shadow_memory=n be desirable? Not sure, this is a host option, not a guest option. Machine options should be guest-visible. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [PATCH 27/28] sysbus: apic: ioapic: convert to QEMU Object Model
On 01/25/2012 10:33 AM, Andreas Färber wrote: There is a declarative solution for this that I know of, a C++ class definition ;-) So what's the reason not to go with one of the object-oriented, C-compatible languages GCC supports, like C++ or Objective-C/C++? (Objective-C has native reflection capabilities fwiw.) I believe everyone except Anthony and myself is against it. But now we are three. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] qemu-kvm upstreaming: Do we want -kvm-shadow-memory semantics?
On 2012-01-25 13:04, Avi Kivity wrote: On 01/25/2012 01:57 PM, Jan Kiszka wrote: -kvm-shadow-memory is becoming less meaningful for ordinary workloads since everything uses TDP these days. It's still meaningful for testing (forcing aggressive cache replacement), or perhaps nested virtualization. So, is it used for testing in fact? It is not, but it should be. There's an extra_params option in autotest, I'll start using it to stress the mmu some more, even though it's going to slow things down for me. OK. Would a machine option kvm_shadow_memory=n be desirable? Not sure, this is a host option, not a guest option. Machine options should be guest-visible. machine options are not guest visible. Basically, this options falls into the same category as kernel_irqchip. Do we have alternatives? A top-level command line options is surely none. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
Re: [Qemu-devel] qemu-kvm upstreaming: Do we want -kvm-shadow-memory semantics?
On 01/25/2012 02:10 PM, Jan Kiszka wrote: Would a machine option kvm_shadow_memory=n be desirable? Not sure, this is a host option, not a guest option. Machine options should be guest-visible. machine options are not guest visible. Basically, this options falls into the same category as kernel_irqchip. They should be. We should work hard to separate the guest ABI from everything else. Same as kvm-apic appearing in the qdev name. Do we have alternatives? A top-level command line options is surely none. -kvm shadow-memory=n,... -accel kvm,shadow-memory=n,... -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] qemu-kvm upstreaming: Do we want -kvm-shadow-memory semantics?
On 2012-01-25 13:15, Avi Kivity wrote: On 01/25/2012 02:10 PM, Jan Kiszka wrote: Would a machine option kvm_shadow_memory=n be desirable? Not sure, this is a host option, not a guest option. Machine options should be guest-visible. machine options are not guest visible. Basically, this options falls into the same category as kernel_irqchip. They should be. We should work hard to separate the guest ABI from everything else. Same as kvm-apic appearing in the qdev name. Which is NOT guest visible. Do we have alternatives? A top-level command line options is surely none. -kvm shadow-memory=n,... -accel kvm,shadow-memory=n,... Both are unneeded additional options. We already have -machine option=value. We just need to enable machines like KVM-based ones to append their private ones to the common set. That way you will get a proper error report when specifying a meaningless combination like accel=tcg,kernel_irqchip=on. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
Re: [Qemu-devel] [PATCH v2 2/9] Add Cortex-A15 CPU definition
Am 24.01.2012 13:39, schrieb Peter Maydell: Add a definition of a Cortex-A15 CPU. Note that for the moment we do not implement any of: * Large Physical Address Extensions (LPAE) * Virtualization Extensions * Generic Timer * TrustZone (this is also true of our existing Cortex-A9 model, etc) This CPU model is sufficient to boot a Linux kernel which has been compiled for an A15 without LPAE enabled. Signed-off-by: Peter Maydell peter.mayd...@linaro.org Reviewed-by: Andreas Färber afaer...@suse.de Thanks, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] qemu-kvm upstreaming: Do we want -kvm-shadow-memory semantics?
On 01/25/2012 02:26 PM, Jan Kiszka wrote: On 2012-01-25 13:15, Avi Kivity wrote: On 01/25/2012 02:10 PM, Jan Kiszka wrote: Would a machine option kvm_shadow_memory=n be desirable? Not sure, this is a host option, not a guest option. Machine options should be guest-visible. machine options are not guest visible. Basically, this options falls into the same category as kernel_irqchip. They should be. We should work hard to separate the guest ABI from everything else. Same as kvm-apic appearing in the qdev name. Which is NOT guest visible. Right. I'm worried about some tool comparing the qdev/qom trees and concluding two machines are different even though they are identical wrt the guest. Too be fair, that applies to attributes as well. Do we have alternatives? A top-level command line options is surely none. -kvm shadow-memory=n,... -accel kvm,shadow-memory=n,... Both are unneeded additional options. We already have -machine option=value. We just need to enable machines like KVM-based ones to append their private ones to the common set. That way you will get a proper error report when specifying a meaningless combination like accel=tcg,kernel_irqchip=on. Okay. I have an uneasy feeling about machine options for this, but nothing more. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [PATCH 26/28] pci: convert to QEMU Object Model
On Tue, Jan 24, 2012 at 01:33:18PM -0600, Anthony Liguori wrote:
diff --git a/hw/ac97.c b/hw/ac97.c
index 03be99b..33b85f5 100644
--- a/hw/ac97.c
+++ b/hw/ac97.c
@@ -1344,21 +1344,30 @@ int ac97_init (PCIBus *bus)
return 0;
}
-static PCIDeviceInfo ac97_info = {
-.qdev.name= AC97,
-.qdev.desc= Intel 82801AA AC97 Audio,
-.qdev.size= sizeof (AC97LinkState),
-.qdev.vmsd= vmstate_ac97,
-.init = ac97_initfn,
-.exit = ac97_exitfn,
-.vendor_id= PCI_VENDOR_ID_INTEL,
-.device_id= PCI_DEVICE_ID_INTEL_82801AA_5,
-.revision = 0x01,
-.class_id = PCI_CLASS_MULTIMEDIA_AUDIO,
-.qdev.props = (Property[]) {
-DEFINE_PROP_UINT32(use_broken_id, AC97LinkState, use_broken_id, 0),
-DEFINE_PROP_END_OF_LIST(),
-}
+static Property ac97_properties[] = {
+DEFINE_PROP_UINT32(use_broken_id, AC97LinkState, use_broken_id, 0),
+DEFINE_PROP_END_OF_LIST(),
+};
+
+static void ac97_class_init(ObjectClass *klass, void *data)
+{
+PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+k-init = ac97_initfn;
+k-exit = ac97_exitfn;
+k-vendor_id = PCI_VENDOR_ID_INTEL;
+k-device_id = PCI_DEVICE_ID_INTEL_82801AA_5;
+k-revision = 0x01;
+k-class_id = PCI_CLASS_MULTIMEDIA_AUDIO;
+}
+
+static DeviceInfo ac97_info = {
+.name = AC97,
+.desc = Intel 82801AA AC97 Audio,
+.size = sizeof (AC97LinkState),
+.vmsd = vmstate_ac97,
+.props = ac97_properties,
+.class_init = ac97_class_init,
};
static void ac97_register (void)
So I have a question on this: the whole reason
we moved class, vendor id etc away from device init
functions to a table was to make it possible
to perform queries, like list all available sound device
types, or sort devices based on type, based on these tables.
Another purpose was to remove the manually written description/name,
embedding pci id database in qemu instead, and performing
lookups based on device/vendor id.
We never got these patches but it sounds like a genuinely useful
functionality.
Is this no longer possible?
--
MST
Re: [Qemu-devel] [PATCH 03/28] pci: call reset unconditionally
On Tue, Jan 24, 2012 at 01:32:55PM -0600, Anthony Liguori wrote:
Because now all PCI devices are converted to qdev.
Signed-off-by: Anthony Liguori aligu...@us.ibm.com
Finally!
---
hw/pci.c |7 ++-
1 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/hw/pci.c b/hw/pci.c
index 54400ac..ab3b53d 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -159,11 +159,8 @@ void pci_device_deassert_intx(PCIDevice *dev)
void pci_device_reset(PCIDevice *dev)
{
int r;
-/* TODO: call the below unconditionally once all pci devices
- * are qdevified */
-if (dev-qdev.info) {
-qdev_reset_all(dev-qdev);
-}
+
+qdev_reset_all(dev-qdev);
dev-irq_state = 0;
pci_update_irq_status(dev);
--
1.7.4.1
Re: [Qemu-devel] [PATCH v2 1/9] Add dummy implementation of generic timer cp15 registers
Am 24.01.2012 13:39, schrieb Peter Maydell:
Add a dummy implementation of the cp15 registers for the generic
timer (found in the Cortex-A15), just sufficient for Linux to
decide that it can't use it. This requires at least CNTP_CTL and
CNTFRQ to be implemented as RAZ/WI; we RAZ/WI all of c14.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
target-arm/cpu.h|1 +
target-arm/helper.c | 12 ++--
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/target-arm/cpu.h b/target-arm/cpu.h
index 42c53a7..d71d310 100644
--- a/target-arm/cpu.h
+++ b/target-arm/cpu.h
@@ -382,6 +382,7 @@ enum arm_features {
ARM_FEATURE_VAPA, /* cp15 VA to PA lookups */
ARM_FEATURE_ARM_DIV, /* divide supported in ARM encoding */
ARM_FEATURE_VFP4, /* VFPv4 (implies that NEON is v2) */
+ARM_FEATURE_GENERICTIMER,
Personally I would've preferred GENERIC_TIMER (we have ARM_DIV,
THUMB_DIV as counterexamples), but no strong objection here.
Andreas
};
static inline int arm_feature(CPUARMState *env, int feature)
diff --git a/target-arm/helper.c b/target-arm/helper.c
index 00458fc..ecba0c6 100644
--- a/target-arm/helper.c
+++ b/target-arm/helper.c
@@ -1762,7 +1762,11 @@ void HELPER(set_cp15)(CPUState *env, uint32_t insn,
uint32_t val)
goto bad_reg;
}
break;
-case 14: /* Reserved. */
+case 14: /* Generic timer */
+if (arm_feature(env, ARM_FEATURE_GENERICTIMER)) {
+/* Dummy implementation: RAZ/WI for all */
+break;
+}
goto bad_reg;
case 15: /* Implementation specific. */
if (arm_feature(env, ARM_FEATURE_XSCALE)) {
@@ -2132,7 +2136,11 @@ uint32_t HELPER(get_cp15)(CPUState *env, uint32_t insn)
default:
goto bad_reg;
}
-case 14: /* Reserved. */
+case 14: /* Generic timer */
+if (arm_feature(env, ARM_FEATURE_GENERICTIMER)) {
+/* Dummy implementation: RAZ/WI for all */
+return 0;
+}
goto bad_reg;
case 15: /* Implementation specific. */
if (arm_feature(env, ARM_FEATURE_XSCALE)) {
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [PATCH] qmp: add BLOCK_MEDIUM_EJECT event
On Wed, 25 Jan 2012 09:41:20 +0100 Kevin Wolf kw...@redhat.com wrote: Am 24.01.2012 21:03, schrieb Eric Blake: On 01/24/2012 11:16 AM, Luiz Capitulino wrote: Libvirt wants to be notified when the guest ejects a medium, so that it can update its view of the guest. This code has been originally written by Daniel Berrange. It adds the event to IDE and SCSI emulation. Please, note that this only covers guest initiated ejects, that's, the QMP/HMP commands 'eject' and 'change' are not covered. What's the reason for this behaviour? It feels inconsistent. I don't think it's inconsistent because we're limiting it to guest initiated actions. Also, the mngt app knows when it sends a 'eject' or 'change' command. The exception is if it allows HMP to run in parallel with QMP, but I don't think this is recommended (at least not for commands that change any VM state). That said, I'm not necessarily against covering all cases. It just doesn't seem necessary to me. Also, I seem to remember that once we had discussed some kind of a tray status (open/closed) changed event, which would be more generic. Yes, but my old series got complex and way beyond the original event. If we decide to cover all eject scenarios, I'd like to do it w/o adding new commands. Signed-off-by: Luiz Capitulino lcapitul...@redhat.com Reviewed-by: Eric Blake ebl...@redhat.com +BLOCK_MEDIUM_EJECT +-- + +Emitted when the guest succeeds ejecting a medium. If the device has a tray, s/succeeds ejecting/succeeds at ejecting/ Since libvirt is also tracking whether it makes 'eject' and 'change' monitor commands, and can also do a query when reconnecting to the monitor after a libvirtd restart to see if state changed in the meantime (when an event was lost), this should be sufficient for libvirt to have an accurate picture of the device state. I do have to wonder, however, if we also need an event for when the guest initiates a tray lock or tray unlock event, in order to track whether plain eject will work or whether a forced eject to override the tray lock would be required. The tray is usually locked for a reason, so I would vote against libvirt automagically overriding it. Note that you don't really need a lock/unlock event for implementing it, you could just always pass force=true (or do it after you got QERR_DEVICE_LOCKED). Yes, libvirt will get the device locked error and can just retry. The only reasonable thing for a management tool to do with a lock/unlock event would be updating some icon in a GUI or something like that. Kevin
Re: [Qemu-devel] [RFC/PATCH] Fix guest OS panic when 64bit BAR is present
On Wed, Jan 25, 2012 at 06:46:03PM +1300, Alexey Korolev wrote: Hi, In this post http://lists.gnu.org/archive/html/qemu-devel/2011-12/msg03171.html I've mentioned about the issues when 64Bit PCI BAR is present and 32bit address range is selected for it. The issue affects all recent qemu releases and all old and recent guest Linux kernel versions. We've done some investigations. Let me explain what happens. Assume we have 64bit BAR with size 32MB mapped at [0xF000 - 0xF200] When Linux guest starts it does PCI bus enumeration. The OS enumerates 64BIT bars using the following procedure. 1. Write all FF's to lower half of 64bit BAR 2. Write address back to lower half of 64bit BAR 3. Write all FF's to higher half of 64bit BAR 4. Write address back to higher half of 64bit BAR Linux code is here: http://lxr.linux.no/#linux+v3.2.1/drivers/pci/probe.c#L149 What does it mean for qemu? At step 1. qemu pci_default_write_config() recevies all FFs for lower part of the 64bit BAR. Then it applies the mask and converts the value to All FF's - size + 1 (FE00 if size is 32MB). Then pci_bar_address() checks if BAR address is valid. Since it is a 64bit bar it reads 0xFE00 - this address is valid. So qemu updates topology and sends request to update mappings in KVM with new range for the 64bit BAR FE00 - 0x. This usually means kernel panic on boot, if there is another mapping in the FE00 - 0x range, which is quite common. The following patch fixes the issue. It affects 64bit PCI BAR's only. The idea of the patch is: we introduce the states for low and high BARs whose can have 3 possible values: BAR_VALID, PCIBAR64_PARTIAL_SIZE_QUERY - someone has requested size of one half of the 64bit PCI BAR, PCIBAR64_PARTIAL_ADDR_PROGRAM - someone has sent a request to update the address of one half of the 64bit PCI BAR. The state becomes BAR_VALID when both halfs are in the same state. We ignore BAR value until both states become BAR_VALID Note: Please use the latest Seabios version (commit 139d5ac037de828f89c36e39c6dd15610650cede and later), as older versions didn't initialize high part of 64bit BAR. The patch is tested on Linux 2.6.18 - 3.1.0 and Windows 2008 Server Signed-off-by: Alexey Korolev alexey.koro...@endace.com Interesting. However, looking at guest code, I note that memory and io are disabled during BAR sizing unless mmio always on is set. pci_bar_address should return PCI_BAR_UNMAPPED in this case, and we should never map this BAR until it's enabled. What's going on?
Re: [Qemu-devel] [PATCH v2 1/9] Add dummy implementation of generic timer cp15 registers
On 25 January 2012 12:37, Andreas Färber afaer...@suse.de wrote: Am 24.01.2012 13:39, schrieb Peter Maydell: + ARM_FEATURE_GENERICTIMER, Personally I would've preferred GENERIC_TIMER (we have ARM_DIV, THUMB_DIV as counterexamples), but no strong objection here. I think I agree. -- PMM
[Qemu-devel] [PATCH v4 0/6] save/restore on Xen
Hi all, this is the fourth version of the Xen save/restore patch series. We have been discussing this issue for quite a while on #qemu and qemu-devel: http://marc.info/?l=qemu-develm=132346828427314w=2 http://marc.info/?l=qemu-develm=132377734605464w=2 The principal changes in the this version are: - Following Anthony's suggestion I have introduced a new monitor command to save the non-ram device state to file. - I have also removed the hack not to reset the cirrus videoram on restore, because it turns out that the videoram doesn't need to be reset in the reset handler at all (tested on Win2K, where the problem was found in the first place). This is the list of patches with a diffstat: Anthony PERARD (2): xen mapcache: check if memory region has moved. xen: do not allocate RAM during INMIGRATE runstate Stefano Stabellini (4): cirrus_vga: do not reset videoram Introduce save_devices xen: record physmap changes to xenstore Set runstate to INMIGRATE earlier block-migration.c |2 +- hmp-commands.hx | 14 +++ hw/cirrus_vga.c |4 -- hw/hw.h |1 + qmp-commands.hx | 17 + savevm.c | 72 - sysemu.h |1 + vl.c |4 +- xen-all.c | 104 +++- xen-mapcache.c| 22 ++-- xen-mapcache.h|9 - 11 files changed, 235 insertions(+), 15 deletions(-) git://xenbits.xen.org/people/sstabellini/qemu-dm.git saverestore-4 Cheers, Stefano
[Qemu-devel] [PATCH v4 1/6] cirrus_vga: do not reset videoram
There is no need to set the videoram to 0xff in cirrus_reset, because it is the BIOS' job. Signed-off-by: Stefano Stabellini stefano.stabell...@eu.citrix.com --- hw/cirrus_vga.c |4 1 files changed, 0 insertions(+), 4 deletions(-) diff --git a/hw/cirrus_vga.c b/hw/cirrus_vga.c index f7b1d3d..5564478 100644 --- a/hw/cirrus_vga.c +++ b/hw/cirrus_vga.c @@ -2760,10 +2760,6 @@ static void cirrus_reset(void *opaque) } s-vga.cr[0x27] = s-device_id; -/* Win2K seems to assume that the pattern buffer is at 0xff - initially ! */ -memset(s-vga.vram_ptr, 0xff, s-real_vram_size); - s-cirrus_hidden_dac_lockindex = 5; s-cirrus_hidden_dac_data = 0; } -- 1.7.2.5
[Qemu-devel] [PATCH v4 5/6] Set runstate to INMIGRATE earlier
Set runstate to RUN_STATE_INMIGRATE as soon as we can on resume.
Signed-off-by: Stefano Stabellini stefano.stabell...@eu.citrix.com
---
vl.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/vl.c b/vl.c
index c3a155f..9b9a4fb 100644
--- a/vl.c
+++ b/vl.c
@@ -2972,6 +2972,7 @@ int main(int argc, char **argv, char **envp)
break;
case QEMU_OPTION_incoming:
incoming = optarg;
+runstate_set(RUN_STATE_INMIGRATE);
break;
case QEMU_OPTION_nodefaults:
default_serial = 0;
@@ -3466,7 +3467,6 @@ int main(int argc, char **argv, char **envp)
}
if (incoming) {
-runstate_set(RUN_STATE_INMIGRATE);
int ret = qemu_start_incoming_migration(incoming);
if (ret 0) {
fprintf(stderr, Migration failed. Exit code %s(%d), exiting.\n,
--
1.7.2.5
Re: [Qemu-devel] [PATCH] qmp: add BLOCK_MEDIUM_EJECT event
Am 25.01.2012 13:42, schrieb Luiz Capitulino: On Wed, 25 Jan 2012 09:41:20 +0100 Kevin Wolf kw...@redhat.com wrote: Am 24.01.2012 21:03, schrieb Eric Blake: On 01/24/2012 11:16 AM, Luiz Capitulino wrote: Libvirt wants to be notified when the guest ejects a medium, so that it can update its view of the guest. This code has been originally written by Daniel Berrange. It adds the event to IDE and SCSI emulation. Please, note that this only covers guest initiated ejects, that's, the QMP/HMP commands 'eject' and 'change' are not covered. What's the reason for this behaviour? It feels inconsistent. I don't think it's inconsistent because we're limiting it to guest initiated actions. Also, the mngt app knows when it sends a 'eject' or 'change' command. Yes, management shouldn't need an event in order to see what it just did itself. I haven't really looked at the code yet, but what I want to avoid is that we have to pass a flag all the way through qemu just so we don't send an event in the end. This might not be the case today, but after some more cleanup of the code it might just turn out like this. The exception is if it allows HMP to run in parallel with QMP, but I don't think this is recommended (at least not for commands that change any VM state). Or QMP passthrough. It would be very nice to support these scenarios one day. Probably not top priority, but we don't need to actively prevent such events from being generated. That said, I'm not necessarily against covering all cases. It just doesn't seem necessary to me. Also, I seem to remember that once we had discussed some kind of a tray status (open/closed) changed event, which would be more generic. Yes, but my old series got complex and way beyond the original event. If we decide to cover all eject scenarios, I'd like to do it w/o adding new commands. I don't really remember. Were it problems with the design of a tray status event or were you sidetracked by other problems? Kevin
[Qemu-devel] [PATCH v4 4/6] xen mapcache: check if memory region has moved.
From: Anthony PERARD anthony.per...@citrix.com
This patch changes the xen_map_cache behavior. Before trying to map a guest
addr, mapcache will look into the list of range of address that have been moved
(physmap/set_memory). There is currently one memory space like this, the vram,
moved from were it's allocated to were the guest will look into.
This help to have a succefull migration.
Signed-off-by: Anthony PERARD anthony.per...@citrix.com
Signed-off-by: Stefano Stabellini stefano.stabell...@eu.citrix.com
---
xen-all.c | 18 +-
xen-mapcache.c | 22 +++---
xen-mapcache.h |9 +++--
3 files changed, 43 insertions(+), 6 deletions(-)
diff --git a/xen-all.c b/xen-all.c
index 4b00a6c..bb66c82 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -225,6 +225,22 @@ static XenPhysmap *get_physmapping(XenIOState *state,
return NULL;
}
+static target_phys_addr_t xen_phys_offset_to_gaddr(target_phys_addr_t
start_addr,
+ ram_addr_t size, void
*opaque)
+{
+target_phys_addr_t addr = start_addr TARGET_PAGE_MASK;
+XenIOState *xen_io_state = opaque;
+XenPhysmap *physmap = NULL;
+
+QLIST_FOREACH(physmap, xen_io_state-physmap, list) {
+if (range_covers_byte(physmap-phys_offset, physmap-size, addr)) {
+return physmap-start_addr;
+}
+}
+
+return start_addr;
+}
+
#if CONFIG_XEN_CTRL_INTERFACE_VERSION = 340
static int xen_add_to_physmap(XenIOState *state,
target_phys_addr_t start_addr,
@@ -1039,7 +1055,7 @@ int xen_hvm_init(void)
}
/* Init RAM management */
-xen_map_cache_init();
+xen_map_cache_init(xen_phys_offset_to_gaddr, state);
xen_ram_init(ram_size);
qemu_add_vm_change_state_handler(xen_hvm_change_state_handler, state);
diff --git a/xen-mapcache.c b/xen-mapcache.c
index 9fecc64..d9c995b 100644
--- a/xen-mapcache.c
+++ b/xen-mapcache.c
@@ -76,6 +76,9 @@ typedef struct MapCache {
uint8_t *last_address_vaddr;
unsigned long max_mcache_size;
unsigned int mcache_bucket_shift;
+
+phys_offset_to_gaddr_t phys_offset_to_gaddr;
+void *opaque;
} MapCache;
static MapCache *mapcache;
@@ -89,13 +92,16 @@ static inline int test_bits(int nr, int size, const
unsigned long *addr)
return 0;
}
-void xen_map_cache_init(void)
+void xen_map_cache_init(phys_offset_to_gaddr_t f, void *opaque)
{
unsigned long size;
struct rlimit rlimit_as;
mapcache = g_malloc0(sizeof (MapCache));
+mapcache-phys_offset_to_gaddr = f;
+mapcache-opaque = opaque;
+
QTAILQ_INIT(mapcache-locked_entries);
mapcache-last_address_index = -1;
@@ -191,9 +197,14 @@ uint8_t *xen_map_cache(target_phys_addr_t phys_addr,
target_phys_addr_t size,
uint8_t lock)
{
MapCacheEntry *entry, *pentry = NULL;
-target_phys_addr_t address_index = phys_addr MCACHE_BUCKET_SHIFT;
-target_phys_addr_t address_offset = phys_addr (MCACHE_BUCKET_SIZE - 1);
+target_phys_addr_t address_index;
+target_phys_addr_t address_offset;
target_phys_addr_t __size = size;
+bool translated = false;
+
+tryagain:
+address_index = phys_addr MCACHE_BUCKET_SHIFT;
+address_offset = phys_addr (MCACHE_BUCKET_SIZE - 1);
trace_xen_map_cache(phys_addr);
@@ -235,6 +246,11 @@ uint8_t *xen_map_cache(target_phys_addr_t phys_addr,
target_phys_addr_t size,
if(!test_bits(address_offset XC_PAGE_SHIFT, size XC_PAGE_SHIFT,
entry-valid_mapping)) {
mapcache-last_address_index = -1;
+if (!translated mapcache-phys_offset_to_gaddr) {
+phys_addr = mapcache-phys_offset_to_gaddr(phys_addr, size,
mapcache-opaque);
+translated = true;
+goto tryagain;
+}
trace_xen_map_cache_return(NULL);
return NULL;
}
diff --git a/xen-mapcache.h b/xen-mapcache.h
index da874ca..70301a5 100644
--- a/xen-mapcache.h
+++ b/xen-mapcache.h
@@ -11,9 +11,13 @@
#include stdlib.h
+typedef target_phys_addr_t (*phys_offset_to_gaddr_t)(target_phys_addr_t
start_addr,
+ ram_addr_t size,
+ void *opaque);
#ifdef CONFIG_XEN
-void xen_map_cache_init(void);
+void xen_map_cache_init(phys_offset_to_gaddr_t f,
+void *opaque);
uint8_t *xen_map_cache(target_phys_addr_t phys_addr, target_phys_addr_t size,
uint8_t lock);
ram_addr_t xen_ram_addr_from_mapcache(void *ptr);
@@ -22,7 +26,8 @@ void xen_invalidate_map_cache(void);
#else
-static inline void xen_map_cache_init(void)
+static inline void xen_map_cache_init(phys_offset_to_gaddr_t f,
+ void *opaque)
{
}
--
1.7.2.5
[Qemu-devel] [PATCH v4 2/6] Introduce save_devices
- add an is_ram flag to SaveStateEntry;
- add an is_ram parameter to register_savevm_live;
- introduce a save_devices monitor command that can be used to save
the state of non-ram devices.
Signed-off-by: Stefano Stabellini stefano.stabell...@eu.citrix.com
---
block-migration.c |2 +-
hmp-commands.hx | 14 ++
hw/hw.h |1 +
qmp-commands.hx | 17
savevm.c | 72 -
sysemu.h |1 +
vl.c |2 +-
7 files changed, 106 insertions(+), 3 deletions(-)
diff --git a/block-migration.c b/block-migration.c
index 2b7edbc..424a87d 100644
--- a/block-migration.c
+++ b/block-migration.c
@@ -720,6 +720,6 @@ void blk_mig_init(void)
QSIMPLEQ_INIT(block_mig_state.bmds_list);
QSIMPLEQ_INIT(block_mig_state.blk_list);
-register_savevm_live(NULL, block, 0, 1, block_set_params,
+register_savevm_live(NULL, block, 0, 1, 0, block_set_params,
block_save_live, NULL, block_load, block_mig_state);
}
diff --git a/hmp-commands.hx b/hmp-commands.hx
index a586498..ba4c9d5 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -241,6 +241,20 @@ a snapshot with the same tag or ID, it is replaced. More
info at
ETEXI
{
+.name = save_devices,
+.args_type = filename:F,
+.params = filename,
+.help = save the state of non-ram devices.,
+.mhandler.cmd_new = do_save_device_state,
+},
+
+STEXI
+@item save_devices @var{filename}
+@findex save_devices
+Save the state of non-ram devices.
+ETEXI
+
+{
.name = loadvm,
.args_type = name:s,
.params = tag|id,
diff --git a/hw/hw.h b/hw/hw.h
index 932014a..9d3d76d 100644
--- a/hw/hw.h
+++ b/hw/hw.h
@@ -263,6 +263,7 @@ int register_savevm_live(DeviceState *dev,
const char *idstr,
int instance_id,
int version_id,
+ int is_ram,
SaveSetParamsHandler *set_params,
SaveLiveStateHandler *save_live_state,
SaveStateHandler *save_state,
diff --git a/qmp-commands.hx b/qmp-commands.hx
index 7e3f4b9..51f4436 100644
--- a/qmp-commands.hx
+++ b/qmp-commands.hx
@@ -429,6 +429,23 @@ Note: inject-nmi is only supported for x86 guest
currently, it will
EQMP
{
+.name = save_devices,
+.args_type = filename:F,
+.params = filename,
+.help = save the state of non-ram devices.,
+.user_print = monitor_user_noop,
+.mhandler.cmd_new = do_save_device_state,
+},
+
+SQMP
+save_devices
+---
+
+Save the state of non-ram devices.
+
+EQMP
+
+{
.name = migrate,
.args_type = detach:-d,blk:-b,inc:-i,uri:s,
.params = [-d] [-b] [-i] uri,
diff --git a/savevm.c b/savevm.c
index 80be1ff..d0e62bb 100644
--- a/savevm.c
+++ b/savevm.c
@@ -1177,6 +1177,7 @@ typedef struct SaveStateEntry {
void *opaque;
CompatEntry *compat;
int no_migrate;
+int is_ram;
} SaveStateEntry;
@@ -1223,6 +1224,7 @@ int register_savevm_live(DeviceState *dev,
const char *idstr,
int instance_id,
int version_id,
+ int is_ram,
SaveSetParamsHandler *set_params,
SaveLiveStateHandler *save_live_state,
SaveStateHandler *save_state,
@@ -1241,6 +1243,7 @@ int register_savevm_live(DeviceState *dev,
se-opaque = opaque;
se-vmsd = NULL;
se-no_migrate = 0;
+se-is_ram = is_ram;
if (dev dev-parent_bus dev-parent_bus-info-get_dev_path) {
char *id = dev-parent_bus-info-get_dev_path(dev);
@@ -1277,7 +1280,7 @@ int register_savevm(DeviceState *dev,
LoadStateHandler *load_state,
void *opaque)
{
-return register_savevm_live(dev, idstr, instance_id, version_id,
+return register_savevm_live(dev, idstr, instance_id, version_id, 0,
NULL, NULL, save_state, load_state, opaque);
}
@@ -1728,6 +1731,43 @@ out:
return ret;
}
+static int qemu_save_device_state(Monitor *mon, QEMUFile *f)
+{
+SaveStateEntry *se;
+
+qemu_put_be32(f, QEMU_VM_FILE_MAGIC);
+qemu_put_be32(f, QEMU_VM_FILE_VERSION);
+
+cpu_synchronize_all_states();
+
+QTAILQ_FOREACH(se, savevm_handlers, entry) {
+int len;
+
+if (se-is_ram)
+continue;
+if (se-save_state == NULL se-vmsd == NULL)
+continue;
+
+/* Section type */
+qemu_put_byte(f, QEMU_VM_SECTION_FULL);
+qemu_put_be32(f, se-section_id);
+
+/* ID string */
+len = strlen(se-idstr);
+qemu_put_byte(f, len);
+qemu_put_buffer(f, (uint8_t *)se-idstr, len);
+
+
Re: [Qemu-devel] [PATCH 03/28] pci: call reset unconditionally
On 01/25/2012 06:42 AM, Michael S. Tsirkin wrote:
On Tue, Jan 24, 2012 at 01:32:55PM -0600, Anthony Liguori wrote:
Because now all PCI devices are converted to qdev.
Signed-off-by: Anthony Liguorialigu...@us.ibm.com
Finally!
Yeah, I hope there's more cleanup that can come out of this.
Regards,
Anthony Liguori
---
hw/pci.c |7 ++-
1 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/hw/pci.c b/hw/pci.c
index 54400ac..ab3b53d 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -159,11 +159,8 @@ void pci_device_deassert_intx(PCIDevice *dev)
void pci_device_reset(PCIDevice *dev)
{
int r;
-/* TODO: call the below unconditionally once all pci devices
- * are qdevified */
-if (dev-qdev.info) {
-qdev_reset_all(dev-qdev);
-}
+
+qdev_reset_all(dev-qdev);
dev-irq_state = 0;
pci_update_irq_status(dev);
--
1.7.4.1
Re: [Qemu-devel] [PATCH] qmp: add BLOCK_MEDIUM_EJECT event
On Wed, 25 Jan 2012 11:19:59 +0100
Markus Armbruster arm...@redhat.com wrote:
Luiz Capitulino lcapitul...@redhat.com writes:
Libvirt wants to be notified when the guest ejects a medium, so that
it can update its view of the guest.
This code has been originally written by Daniel Berrange. It adds
the event to IDE and SCSI emulation.
Please, note that this only covers guest initiated ejects, that's,
the QMP/HMP commands 'eject' and 'change' are not covered.
Signed-off-by: Luiz Capitulino lcapitul...@redhat.com
---
PS: Bugs are mine.
QMP/qmp-events.txt | 18 ++
block.c| 12
block.h|5 +
block_int.h|3 +++
blockdev.c | 13 +
hw/ide/atapi.c |1 +
hw/scsi-disk.c |1 +
monitor.c |3 +++
monitor.h |1 +
9 files changed, 57 insertions(+), 0 deletions(-)
diff --git a/QMP/qmp-events.txt b/QMP/qmp-events.txt
index af586ec..e414128 100644
--- a/QMP/qmp-events.txt
+++ b/QMP/qmp-events.txt
@@ -26,6 +26,24 @@ Example:
Note: If action is stop, a STOP event will eventually follow the
BLOCK_IO_ERROR event.
+BLOCK_MEDIUM_EJECT
+--
+
+Emitted when the guest succeeds ejecting a medium. If the device has a
tray,
+then this event is emitted whenever the guest opens or closes the tray.
This wording could be a bit confusing for devices where the physical
device doesn't have a tray. Our CD-ROMs have a tray. Our floppy
doesn't. Our floppy device model doesn't let the guest eject, so it
doesn't matter right now. But trayless physical devices with removable
media exist.
Suggest to say something like Emitted whenever the guest successfully
ejects or loads a medium, or opens or closes the tray.
Ok.
+
+Data:
+
+- device: device name (json-string)
This is the backend name, i.e. the name that's shown in info block.
It's not the qdev ID. Consistent with BLOCK_IO_ERROR. Good.
We call too many things device...
+- ejected: true if the tray has been opened or false if it has been
closed
+
+Example:
+
+{ event: BLOCK_MEDIUM_EJECT,
+data: { device: ide1-cd1,
+ ejected: true },
+timestamp: { seconds: 1265044230, microseconds: 450486 } }
+
RESET
-
diff --git a/block.c b/block.c
index 3f072f6..b25932b 100644
--- a/block.c
+++ b/block.c
@@ -1998,6 +1998,18 @@ BlockErrorAction bdrv_get_on_error(BlockDriverState
*bs, int is_read)
return is_read ? bs-on_read_error : bs-on_write_error;
}
+void bdrv_dev_set_medium_eject_notify(BlockDriverState *bs,
+ bdrv_dev_medium_eject_notify_cb cb)
+{
+bs-dev_medium_eject_notify_cb = cb;
+}
+
+void bdrv_dev_medium_eject_notify(BlockDriverState *bs, int is_ejected)
+{
+assert(bs-dev_medium_eject_notify_cb);
+bs-dev_medium_eject_notify_cb(bs, is_ejected);
+}
+
int bdrv_is_read_only(BlockDriverState *bs)
{
return bs-read_only;
diff --git a/block.h b/block.h
index 3bd4398..344ca0d 100644
--- a/block.h
+++ b/block.h
@@ -247,6 +247,11 @@ int bdrv_get_translation_hint(BlockDriverState *bs);
void bdrv_set_on_error(BlockDriverState *bs, BlockErrorAction
on_read_error,
BlockErrorAction on_write_error);
BlockErrorAction bdrv_get_on_error(BlockDriverState *bs, int is_read);
+typedef void (*bdrv_dev_medium_eject_notify_cb)(BlockDriverState *bs,
+int is_ejected);
+void bdrv_dev_set_medium_eject_notify(BlockDriverState *bs,
+ bdrv_dev_medium_eject_notify_cb cb);
+void bdrv_dev_medium_eject_notify(BlockDriverState *bs, int is_ejected);
int bdrv_is_read_only(BlockDriverState *bs);
int bdrv_is_sg(BlockDriverState *bs);
int bdrv_enable_write_cache(BlockDriverState *bs);
diff --git a/block_int.h b/block_int.h
index 311bd2a..50c34f6 100644
--- a/block_int.h
+++ b/block_int.h
@@ -260,6 +260,9 @@ struct BlockDriverState {
QTAILQ_ENTRY(BlockDriverState) list;
void *private;
+/* Callback for medium eject */
+bdrv_dev_medium_eject_notify_cb dev_medium_eject_notify_cb;
+
QLIST_HEAD(, BdrvTrackedRequest) tracked_requests;
};
Why the indirection? Isn't this always on_medium_eject()?
bdrv_dev_medium_eject_notify_cb() asserts it's not null, and it's never
set to anything else.
If the indirection is justified, why is it per object (in
BlockDriverState) and not per driver (in BlockDriver)?
Update: I found a possible reason, see drive_init() below.
Let's discuss it below.
block.h and block_int.h don't typedef their methods, suggest to stick to
that.
Ok.
diff --git a/blockdev.c b/blockdev.c
index 1f83c88..71b50fa 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -11,6 +11,7 @@
[Qemu-devel] [PATCH v4 6/6] xen: do not allocate RAM during INMIGRATE runstate
From: Anthony PERARD anthony.per...@citrix.com
Signed-off-by: Anthony PERARD anthony.per...@citrix.com
Signed-off-by: Stefano Stabellini stefano.stabell...@eu.citrix.com
---
xen-all.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/xen-all.c b/xen-all.c
index bb66c82..5b10d0c 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -190,6 +190,14 @@ void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size,
MemoryRegion *mr)
xen_pfn_t *pfn_list;
int i;
+if (runstate_check(RUN_STATE_INMIGRATE)) {
+/* RAM already populated in Xen */
+fprintf(stderr, %s: do not alloc RAM_ADDR_FMT
+ bytes of ram at RAM_ADDR_FMT when runstate is INMIGRATE\n,
+__func__, size, ram_addr);
+return;
+}
+
if (mr == ram_memory) {
return;
}
--
1.7.2.5
Re: [Qemu-devel] [PATCH] qmp: add BLOCK_MEDIUM_EJECT event
On 01/25/2012 02:23 PM, Kevin Wolf wrote: Please, note that this only covers guest initiated ejects, that's, the QMP/HMP commands 'eject' and 'change' are not covered. What's the reason for this behaviour? It feels inconsistent. I don't think it's inconsistent because we're limiting it to guest initiated actions. Also, the mngt app knows when it sends a 'eject' or 'change' command. Yes, management shouldn't need an event in order to see what it just did itself. I haven't really looked at the code yet, but what I want to avoid is that we have to pass a flag all the way through qemu just so we don't send an event in the end. This might not be the case today, but after some more cleanup of the code it might just turn out like this. Management must be ready anyway to receive an event in response to eject/change actions that it started, because the guest might be trapping the host's eject requests (press the button) and turning them into guest-initiated ejects. This is what recent udev does. Thus, a reliable eject procedure must be as follows: 1) Eject the disc 2) query the state of the tray. If it is open, poll for eject events and consume them. If it is closed, either exit or wait for an eject event to arrive. We can document that the event MAY NOT be reported for host-initiated ejects. It is future-proof and actually closer to what happens in practice if you consider a wide range of guests. Paolo
[Qemu-devel] [PATCH 0/2] Cortex-A15 support: target-arm patches
Just a retransmit of the target-arm parts of the Cortex-A15 series, with the tiny change of s/ARM_FEATURE_GENERICTIMER/ARM_FEATURE_GENERIC_TIMER/ and no other changes from the versions in v2 of the vexpress-a15 patchset. Peter Maydell (2): Add dummy implementation of generic timer cp15 registers Add Cortex-A15 CPU definition target-arm/cpu.h|2 + target-arm/helper.c | 68 +- 2 files changed, 63 insertions(+), 7 deletions(-)
Re: [Qemu-devel] [PATCH 26/28] pci: convert to QEMU Object Model
On 01/25/2012 06:41 AM, Michael S. Tsirkin wrote:
On Tue, Jan 24, 2012 at 01:33:18PM -0600, Anthony Liguori wrote:
diff --git a/hw/ac97.c b/hw/ac97.c
index 03be99b..33b85f5 100644
--- a/hw/ac97.c
+++ b/hw/ac97.c
@@ -1344,21 +1344,30 @@ int ac97_init (PCIBus *bus)
return 0;
}
-static PCIDeviceInfo ac97_info = {
-.qdev.name= AC97,
-.qdev.desc= Intel 82801AA AC97 Audio,
-.qdev.size= sizeof (AC97LinkState),
-.qdev.vmsd=vmstate_ac97,
-.init = ac97_initfn,
-.exit = ac97_exitfn,
-.vendor_id= PCI_VENDOR_ID_INTEL,
-.device_id= PCI_DEVICE_ID_INTEL_82801AA_5,
-.revision = 0x01,
-.class_id = PCI_CLASS_MULTIMEDIA_AUDIO,
-.qdev.props = (Property[]) {
-DEFINE_PROP_UINT32(use_broken_id, AC97LinkState, use_broken_id, 0),
-DEFINE_PROP_END_OF_LIST(),
-}
+static Property ac97_properties[] = {
+DEFINE_PROP_UINT32(use_broken_id, AC97LinkState, use_broken_id, 0),
+DEFINE_PROP_END_OF_LIST(),
+};
+
+static void ac97_class_init(ObjectClass *klass, void *data)
+{
+PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+k-init = ac97_initfn;
+k-exit = ac97_exitfn;
+k-vendor_id = PCI_VENDOR_ID_INTEL;
+k-device_id = PCI_DEVICE_ID_INTEL_82801AA_5;
+k-revision = 0x01;
+k-class_id = PCI_CLASS_MULTIMEDIA_AUDIO;
+}
+
+static DeviceInfo ac97_info = {
+.name = AC97,
+.desc = Intel 82801AA AC97 Audio,
+.size = sizeof (AC97LinkState),
+.vmsd =vmstate_ac97,
+.props = ac97_properties,
+.class_init = ac97_class_init,
};
static void ac97_register (void)
So I have a question on this: the whole reason
we moved class, vendor id etc away from device init
functions to a table was to make it possible
to perform queries, like list all available sound device
types, or sort devices based on type, based on these tables.
Another purpose was to remove the manually written description/name,
embedding pci id database in qemu instead, and performing
lookups based on device/vendor id.
We never got these patches but it sounds like a genuinely useful
functionality.
Is this no longer possible?
There is one class instance per type. It's initialized lazily but the types are
always known. IOW, ac97_class_init() is called once on the global
PCIDeviceClass object, most likely very early during init.
These class objects can be searched and interacted with independently of any
existing object. What you're after is:
static void show_pci_device(ObjectClass *klass, void *opaque)
{
PCIDeviceClass *pc = PCI_DEVICE_CLASS(klass);
printf(Device %s is %02x:%02x\n,
object_class_get_name(klass), pc-vendor_id, pc-device_id);
}
{
...
object_class_foreach(show_pci_device, TYPE_PCI_DEVICE, false, NULL);
}
Regards,
Anthony Liguori
[Qemu-devel] [PATCH v4 3/6] xen: record physmap changes to xenstore
Write to xenstore any physmap changes so that the hypervisor can be
aware of them.
Read physmap changes from xenstore on boot.
Signed-off-by: Stefano Stabellini stefano.stabell...@eu.citrix.com
---
xen-all.c | 78 -
1 files changed, 77 insertions(+), 1 deletions(-)
diff --git a/xen-all.c b/xen-all.c
index c86ebf4..4b00a6c 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -63,7 +63,7 @@ static inline ioreq_t *xen_vcpu_ioreq(shared_iopage_t
*shared_page, int vcpu)
typedef struct XenPhysmap {
target_phys_addr_t start_addr;
ram_addr_t size;
-MemoryRegion *mr;
+char *name;
target_phys_addr_t phys_offset;
QLIST_ENTRY(XenPhysmap) list;
@@ -237,6 +237,7 @@ static int xen_add_to_physmap(XenIOState *state,
XenPhysmap *physmap = NULL;
target_phys_addr_t pfn, start_gpfn;
target_phys_addr_t phys_offset = memory_region_get_ram_addr(mr);
+char path[80], value[17];
if (get_physmapping(state, start_addr, size)) {
return 0;
@@ -275,6 +276,7 @@ go_physmap:
physmap-start_addr = start_addr;
physmap-size = size;
+physmap-name = (char *)mr-name;
physmap-phys_offset = phys_offset;
QLIST_INSERT_HEAD(state-physmap, physmap, list);
@@ -283,6 +285,30 @@ go_physmap:
start_addr TARGET_PAGE_BITS,
(start_addr + size) TARGET_PAGE_BITS,
XEN_DOMCTL_MEM_CACHEATTR_WB);
+
+snprintf(path, sizeof(path),
+/local/domain/0/device-model/%d/physmap/%PRIx64/start_addr,
+xen_domid, (uint64_t)phys_offset);
+snprintf(value, sizeof(value), %PRIx64, (uint64_t)start_addr);
+if (!xs_write(state-xenstore, 0, path, value, strlen(value))) {
+return -1;
+}
+snprintf(path, sizeof(path),
+/local/domain/0/device-model/%d/physmap/%PRIx64/size,
+xen_domid, (uint64_t)phys_offset);
+snprintf(value, sizeof(value), %PRIx64, (uint64_t)size);
+if (!xs_write(state-xenstore, 0, path, value, strlen(value))) {
+return -1;
+}
+if (mr-name) {
+snprintf(path, sizeof(path),
+/local/domain/0/device-model/%d/physmap/%PRIx64/name,
+xen_domid, (uint64_t)phys_offset);
+if (!xs_write(state-xenstore, 0, path, mr-name, strlen(mr-name))) {
+return -1;
+}
+}
+
return 0;
}
@@ -910,6 +936,55 @@ int xen_init(void)
return 0;
}
+static void xen_read_physmap(XenIOState *state)
+{
+XenPhysmap *physmap = NULL;
+unsigned int len, num, i;
+char path[80], *value = NULL;
+char **entries = NULL;
+
+snprintf(path, sizeof(path),
+/local/domain/0/device-model/%d/physmap, xen_domid);
+entries = xs_directory(state-xenstore, 0, path, num);
+if (entries == NULL)
+return;
+
+for (i = 0; i num; i++) {
+physmap = g_malloc(sizeof (XenPhysmap));
+physmap-phys_offset = strtoull(entries[i], NULL, 16);
+snprintf(path, sizeof(path),
+/local/domain/0/device-model/%d/physmap/%s/start_addr,
+xen_domid, entries[i]);
+value = xs_read(state-xenstore, 0, path, len);
+if (value == NULL) {
+free(physmap);
+continue;
+}
+physmap-start_addr = strtoull(value, NULL, 16);
+free(value);
+
+snprintf(path, sizeof(path),
+/local/domain/0/device-model/%d/physmap/%s/size,
+xen_domid, entries[i]);
+value = xs_read(state-xenstore, 0, path, len);
+if (value == NULL) {
+free(physmap);
+continue;
+}
+physmap-size = strtoull(value, NULL, 16);
+free(value);
+
+snprintf(path, sizeof(path),
+/local/domain/0/device-model/%d/physmap/%s/name,
+xen_domid, entries[i]);
+physmap-name = xs_read(state-xenstore, 0, path, len);
+
+QLIST_INSERT_HEAD(state-physmap, physmap, list);
+}
+free(entries);
+return;
+}
+
int xen_hvm_init(void)
{
int i, rc;
@@ -982,6 +1057,7 @@ int xen_hvm_init(void)
xen_be_register(console, xen_console_ops);
xen_be_register(vkbd, xen_kbdmouse_ops);
xen_be_register(qdisk, xen_blkdev_ops);
+xen_read_physmap(state);
return 0;
}
--
1.7.2.5
Re: [Qemu-devel] [PATCH] qmp: add BLOCK_MEDIUM_EJECT event
Am 25.01.2012 14:32, schrieb Paolo Bonzini: On 01/25/2012 02:23 PM, Kevin Wolf wrote: Please, note that this only covers guest initiated ejects, that's, the QMP/HMP commands 'eject' and 'change' are not covered. What's the reason for this behaviour? It feels inconsistent. I don't think it's inconsistent because we're limiting it to guest initiated actions. Also, the mngt app knows when it sends a 'eject' or 'change' command. Yes, management shouldn't need an event in order to see what it just did itself. I haven't really looked at the code yet, but what I want to avoid is that we have to pass a flag all the way through qemu just so we don't send an event in the end. This might not be the case today, but after some more cleanup of the code it might just turn out like this. Management must be ready anyway to receive an event in response to eject/change actions that it started, because the guest might be trapping the host's eject requests (press the button) and turning them into guest-initiated ejects. This is what recent udev does. Good point. The QMP client would still get an error that the device is locked, and only later receive the event that the guest ejected the medium, right? Thus, a reliable eject procedure must be as follows: 1) Eject the disc 2) query the state of the tray. If it is open, poll for eject events and consume them. If it is closed, either exit or wait for an eject event to arrive. We can document that the event MAY NOT be reported for host-initiated ejects. It is future-proof and actually closer to what happens in practice if you consider a wide range of guests. In which case we did have an eject request, but we didn't actually eject. So I think defining it as being emitted whenever something is ejected/the tray is opened makes sense. Kevin
[Qemu-devel] [PATCH 2/2] Add Cortex-A15 CPU definition
Add a definition of a Cortex-A15 CPU. Note that for the moment we do
not implement any of:
* Large Physical Address Extensions (LPAE)
* Virtualization Extensions
* Generic Timer
* TrustZone (this is also true of our existing Cortex-A9 model, etc)
This CPU model is sufficient to boot a Linux kernel which has been
compiled for an A15 without LPAE enabled.
Reviewed-by: Andreas Färber afaer...@suse.de
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
target-arm/cpu.h|1 +
target-arm/helper.c | 56 ++
2 files changed, 52 insertions(+), 5 deletions(-)
diff --git a/target-arm/cpu.h b/target-arm/cpu.h
index 7442c99..0d9b39c 100644
--- a/target-arm/cpu.h
+++ b/target-arm/cpu.h
@@ -433,6 +433,7 @@ void cpu_arm_set_cp_io(CPUARMState *env, int cpnum,
#define ARM_CPUID_ARM11MPCORE 0x410fb022
#define ARM_CPUID_CORTEXA80x410fc080
#define ARM_CPUID_CORTEXA90x410fc090
+#define ARM_CPUID_CORTEXA15 0x412fc0f1
#define ARM_CPUID_CORTEXM30x410fc231
#define ARM_CPUID_ANY 0x
diff --git a/target-arm/helper.c b/target-arm/helper.c
index 5e7205a..ea4f35f 100644
--- a/target-arm/helper.c
+++ b/target-arm/helper.c
@@ -10,6 +10,16 @@
#if !defined(CONFIG_USER_ONLY)
#include hw/loader.h
#endif
+#include sysemu.h
+
+static uint32_t cortexa15_cp15_c0_c1[8] = {
+0x1131, 0x00011011, 0x02010555, 0x,
+0x10201105, 0x2000, 0x0124, 0x02102211
+};
+
+static uint32_t cortexa15_cp15_c0_c2[8] = {
+0x02101110, 0x13112111, 0x21232041, 0x2131, 0x10011142, 0, 0, 0
+};
static uint32_t cortexa9_cp15_c0_c1[8] =
{ 0x1031, 0x11, 0x000, 0, 0x00100103, 0x2000, 0x0123, 0x2111 };
@@ -158,6 +168,27 @@ static void cpu_reset_model_id(CPUARMState *env, uint32_t
id)
env-cp15.c0_ccsid[1] = 0x200fe015; /* 16k L1 icache. */
env-cp15.c1_sys = 0x00c50078;
break;
+case ARM_CPUID_CORTEXA15:
+set_feature(env, ARM_FEATURE_V7);
+set_feature(env, ARM_FEATURE_VFP4);
+set_feature(env, ARM_FEATURE_VFP_FP16);
+set_feature(env, ARM_FEATURE_NEON);
+set_feature(env, ARM_FEATURE_THUMB2EE);
+set_feature(env, ARM_FEATURE_ARM_DIV);
+set_feature(env, ARM_FEATURE_V7MP);
+set_feature(env, ARM_FEATURE_GENERIC_TIMER);
+env-vfp.xregs[ARM_VFP_FPSID] = 0x410430f0;
+env-vfp.xregs[ARM_VFP_MVFR0] = 0x10110222;
+env-vfp.xregs[ARM_VFP_MVFR1] = 0x;
+memcpy(env-cp15.c0_c1, cortexa15_cp15_c0_c1, 8 * sizeof(uint32_t));
+memcpy(env-cp15.c0_c2, cortexa15_cp15_c0_c2, 8 * sizeof(uint32_t));
+env-cp15.c0_cachetype = 0x8444c004;
+env-cp15.c0_clid = 0x0a200023;
+env-cp15.c0_ccsid[0] = 0x701fe00a; /* 32K L1 dcache */
+env-cp15.c0_ccsid[1] = 0x201fe00a; /* 32K L1 icache */
+env-cp15.c0_ccsid[2] = 0x711fe07a; /* 4096K L2 unified cache */
+env-cp15.c1_sys = 0x00c50078;
+break;
case ARM_CPUID_CORTEXM3:
set_feature(env, ARM_FEATURE_V7);
set_feature(env, ARM_FEATURE_M);
@@ -416,6 +447,7 @@ static const struct arm_cpu_t arm_cpu_names[] = {
{ ARM_CPUID_CORTEXM3, cortex-m3},
{ ARM_CPUID_CORTEXA8, cortex-a8},
{ ARM_CPUID_CORTEXA9, cortex-a9},
+{ ARM_CPUID_CORTEXA15, cortex-a15 },
{ ARM_CPUID_TI925T, ti925t },
{ ARM_CPUID_PXA250, pxa250 },
{ ARM_CPUID_SA1100,sa1100 },
@@ -670,8 +702,6 @@ uint32_t HELPER(get_r13_banked)(CPUState *env, uint32_t
mode)
#else
-extern int semihosting_enabled;
-
/* Map CPU modes onto saved register banks. */
static inline int bank_number(CPUState *env, int mode)
{
@@ -1945,6 +1975,7 @@ uint32_t HELPER(get_cp15)(CPUState *env, uint32_t insn)
case ARM_CPUID_CORTEXA8:
return 2;
case ARM_CPUID_CORTEXA9:
+case ARM_CPUID_CORTEXA15:
return 0;
default:
goto bad_reg;
@@ -2065,11 +2096,26 @@ uint32_t HELPER(get_cp15)(CPUState *env, uint32_t insn)
goto bad_reg;
}
case 1: /* L2 cache */
-if (crm != 0) {
+/* L2 Lockdown and Auxiliary control. */
+switch (op2) {
+case 0:
+/* L2 cache lockdown (A8 only) */
+return 0;
+case 2:
+/* L2 cache auxiliary control (A8) or control (A15) */
+if (ARM_CPUID(env) == ARM_CPUID_CORTEXA15) {
+/* Linux wants the number of processors from here.
+ * Might as well set the interrupt-controller bit too.
+ */
+return ((smp_cpus - 1) 24) | (1 23);
+}
+return 0;
+case 3:
+/* L2 cache extended control (A15) */
+return 0;
+default:
Re: [Qemu-devel] [PATCH] qmp: add BLOCK_MEDIUM_EJECT event
On Wed, 25 Jan 2012 14:23:55 +0100 Kevin Wolf kw...@redhat.com wrote: Also, I seem to remember that once we had discussed some kind of a tray status (open/closed) changed event, which would be more generic. Yes, but my old series got complex and way beyond the original event. If we decide to cover all eject scenarios, I'd like to do it w/o adding new commands. I don't really remember. Were it problems with the design of a tray status event or were you sidetracked by other problems? I was also trying to fix the 'change' command. So I added new commands to open, close and insert a medium in the tray. Then we had TRAY_OPEN TRAY_CLOSE events... It was a 10 patch series iirc.
Re: [Qemu-devel] [PATCH] qmp: add BLOCK_MEDIUM_EJECT event
Paolo Bonzini pbonz...@redhat.com writes: On 01/25/2012 02:23 PM, Kevin Wolf wrote: Please, note that this only covers guest initiated ejects, that's, the QMP/HMP commands 'eject' and 'change' are not covered. What's the reason for this behaviour? It feels inconsistent. I don't think it's inconsistent because we're limiting it to guest initiated actions. Also, the mngt app knows when it sends a 'eject' or 'change' command. Yes, management shouldn't need an event in order to see what it just did itself. I haven't really looked at the code yet, but what I want to avoid is that we have to pass a flag all the way through qemu just so we don't send an event in the end. This might not be the case today, but after some more cleanup of the code it might just turn out like this. Management must be ready anyway to receive an event in response to eject/change actions that it started, because the guest might be trapping the host's eject requests (press the button) and turning them into guest-initiated ejects. This is what recent udev does. Thus, a reliable eject procedure must be as follows: 1) Eject the disc 2) query the state of the tray. If it is open, poll for eject events and consume them. If it is closed, either exit or wait for an eject event to arrive. We can document that the event MAY NOT be reported for host-initiated ejects. It is future-proof and actually closer to what happens in practice if you consider a wide range of guests. This is getting complicated... Feels like reporting tray open/close changes regardless of who triggered them could be simpler.
[Qemu-devel] [PATCH 1/2] Add dummy implementation of generic timer cp15 registers
Add a dummy implementation of the cp15 registers for the generic
timer (found in the Cortex-A15), just sufficient for Linux to
decide that it can't use it. This requires at least CNTP_CTL and
CNTFRQ to be implemented as RAZ/WI; we RAZ/WI all of c14.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
target-arm/cpu.h|1 +
target-arm/helper.c | 12 ++--
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/target-arm/cpu.h b/target-arm/cpu.h
index 42c53a7..7442c99 100644
--- a/target-arm/cpu.h
+++ b/target-arm/cpu.h
@@ -382,6 +382,7 @@ enum arm_features {
ARM_FEATURE_VAPA, /* cp15 VA to PA lookups */
ARM_FEATURE_ARM_DIV, /* divide supported in ARM encoding */
ARM_FEATURE_VFP4, /* VFPv4 (implies that NEON is v2) */
+ARM_FEATURE_GENERIC_TIMER,
};
static inline int arm_feature(CPUARMState *env, int feature)
diff --git a/target-arm/helper.c b/target-arm/helper.c
index 22e40fc..5e7205a 100644
--- a/target-arm/helper.c
+++ b/target-arm/helper.c
@@ -1764,7 +1764,11 @@ void HELPER(set_cp15)(CPUState *env, uint32_t insn,
uint32_t val)
goto bad_reg;
}
break;
-case 14: /* Reserved. */
+case 14: /* Generic timer */
+if (arm_feature(env, ARM_FEATURE_GENERIC_TIMER)) {
+/* Dummy implementation: RAZ/WI for all */
+break;
+}
goto bad_reg;
case 15: /* Implementation specific. */
if (arm_feature(env, ARM_FEATURE_XSCALE)) {
@@ -2134,7 +2138,11 @@ uint32_t HELPER(get_cp15)(CPUState *env, uint32_t insn)
default:
goto bad_reg;
}
-case 14: /* Reserved. */
+case 14: /* Generic timer */
+if (arm_feature(env, ARM_FEATURE_GENERIC_TIMER)) {
+/* Dummy implementation: RAZ/WI for all */
+return 0;
+}
goto bad_reg;
case 15: /* Implementation specific. */
if (arm_feature(env, ARM_FEATURE_XSCALE)) {
--
1.7.1
Re: [Qemu-devel] [PATCH 27/28] sysbus: apic: ioapic: convert to QEMU Object Model
On 01/25/2012 02:37 AM, Jan Kiszka wrote:
On 2012-01-25 00:03, Anthony Liguori wrote:
They're exactly the same size (16 lines). If you embed TypeInfo into
DeviceTypeInfo, and introduce a Device specific type registration
function, then you could do:
static DeviceTypeInfo my_device_type_info = {
.type.name = TYPE_MY_DEVICE,
.type.parent = TYPE_PARENT_DEVICE,
.reset = my_device_reset,
And if you introduce some
#define TYPE_UNIMPLEMENTED (void *)dummy_variable
(void *) isn't compatible with integers or function pointers (at least not in a
portable way).
You would need to use type specific unimplemented mechanisms.
you can easily express
[.field = NULL] = use parent
.field = UNIMPLEMENTED = don't run any handler
};
static void register_devices(void)
{
device_type_register_static(my_device_type_info);
}
Which admittedly saves 6 lines, but also is a big step backwards IMHO.
Now you've got a lot of one-off functions which means you loose the
advantage of having everything work through the same infrastructure.
Can't follow. Four lines
[static inline] void device_type_register_static(DeviceTypeInfo *dt)
{
type_register_static(dt-type);
}
are neither ugly nor complex. Rather, this helps concentrating effort at
_central_ places instead of decentralizing and duplicating lines like in
your imperative approach. That's the whole point: keep the common case
(derived classes) compact.
Send a patch. The infrastructure available should be enough to do whatever you
need to.
I'm not being dismissive, I've already spent a lot of time trying to make it
work and have convinced myself that it isn't workable.
If you can show a mechanism that works, I don't mind scripting a mass
conversion. I'm also fairly confident that a workable solution is going to be
better than what we have.
Regards,
Anthony Liguori
Jan
Re: [Qemu-devel] [PATCH 1/2] Add dummy implementation of generic timer cp15 registers
Am 25.01.2012 14:32, schrieb Peter Maydell:
Add a dummy implementation of the cp15 registers for the generic
timer (found in the Cortex-A15), just sufficient for Linux to
decide that it can't use it. This requires at least CNTP_CTL and
CNTFRQ to be implemented as RAZ/WI; we RAZ/WI all of c14.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
Reviewed-by: Andreas Färber afaer...@suse.de
Took me a bit to figure out RAZ/WI. ;)
Andreas
---
target-arm/cpu.h|1 +
target-arm/helper.c | 12 ++--
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/target-arm/cpu.h b/target-arm/cpu.h
index 42c53a7..7442c99 100644
--- a/target-arm/cpu.h
+++ b/target-arm/cpu.h
@@ -382,6 +382,7 @@ enum arm_features {
ARM_FEATURE_VAPA, /* cp15 VA to PA lookups */
ARM_FEATURE_ARM_DIV, /* divide supported in ARM encoding */
ARM_FEATURE_VFP4, /* VFPv4 (implies that NEON is v2) */
+ARM_FEATURE_GENERIC_TIMER,
};
static inline int arm_feature(CPUARMState *env, int feature)
diff --git a/target-arm/helper.c b/target-arm/helper.c
index 22e40fc..5e7205a 100644
--- a/target-arm/helper.c
+++ b/target-arm/helper.c
@@ -1764,7 +1764,11 @@ void HELPER(set_cp15)(CPUState *env, uint32_t insn,
uint32_t val)
goto bad_reg;
}
break;
-case 14: /* Reserved. */
+case 14: /* Generic timer */
+if (arm_feature(env, ARM_FEATURE_GENERIC_TIMER)) {
+/* Dummy implementation: RAZ/WI for all */
+break;
+}
goto bad_reg;
case 15: /* Implementation specific. */
if (arm_feature(env, ARM_FEATURE_XSCALE)) {
@@ -2134,7 +2138,11 @@ uint32_t HELPER(get_cp15)(CPUState *env, uint32_t insn)
default:
goto bad_reg;
}
-case 14: /* Reserved. */
+case 14: /* Generic timer */
+if (arm_feature(env, ARM_FEATURE_GENERIC_TIMER)) {
+/* Dummy implementation: RAZ/WI for all */
+return 0;
+}
goto bad_reg;
case 15: /* Implementation specific. */
if (arm_feature(env, ARM_FEATURE_XSCALE)) {
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [PATCH] qmp: add BLOCK_MEDIUM_EJECT event
Luiz Capitulino lcapitul...@redhat.com writes:
On Wed, 25 Jan 2012 11:19:59 +0100
Markus Armbruster arm...@redhat.com wrote:
Luiz Capitulino lcapitul...@redhat.com writes:
Libvirt wants to be notified when the guest ejects a medium, so that
it can update its view of the guest.
This code has been originally written by Daniel Berrange. It adds
the event to IDE and SCSI emulation.
Please, note that this only covers guest initiated ejects, that's,
the QMP/HMP commands 'eject' and 'change' are not covered.
Signed-off-by: Luiz Capitulino lcapitul...@redhat.com
---
PS: Bugs are mine.
QMP/qmp-events.txt | 18 ++
block.c| 12
block.h|5 +
block_int.h|3 +++
blockdev.c | 13 +
hw/ide/atapi.c |1 +
hw/scsi-disk.c |1 +
monitor.c |3 +++
monitor.h |1 +
9 files changed, 57 insertions(+), 0 deletions(-)
diff --git a/QMP/qmp-events.txt b/QMP/qmp-events.txt
index af586ec..e414128 100644
--- a/QMP/qmp-events.txt
+++ b/QMP/qmp-events.txt
@@ -26,6 +26,24 @@ Example:
Note: If action is stop, a STOP event will eventually follow the
BLOCK_IO_ERROR event.
+BLOCK_MEDIUM_EJECT
+--
+
+Emitted when the guest succeeds ejecting a medium. If the device has a
tray,
+then this event is emitted whenever the guest opens or closes the tray.
This wording could be a bit confusing for devices where the physical
device doesn't have a tray. Our CD-ROMs have a tray. Our floppy
doesn't. Our floppy device model doesn't let the guest eject, so it
doesn't matter right now. But trayless physical devices with removable
media exist.
Suggest to say something like Emitted whenever the guest successfully
ejects or loads a medium, or opens or closes the tray.
Ok.
+
+Data:
+
+- device: device name (json-string)
This is the backend name, i.e. the name that's shown in info block.
It's not the qdev ID. Consistent with BLOCK_IO_ERROR. Good.
We call too many things device...
+- ejected: true if the tray has been opened or false if it has been
closed
+
+Example:
+
+{ event: BLOCK_MEDIUM_EJECT,
+data: { device: ide1-cd1,
+ ejected: true },
+timestamp: { seconds: 1265044230, microseconds: 450486 } }
+
RESET
-
diff --git a/block.c b/block.c
index 3f072f6..b25932b 100644
--- a/block.c
+++ b/block.c
@@ -1998,6 +1998,18 @@ BlockErrorAction bdrv_get_on_error(BlockDriverState
*bs, int is_read)
return is_read ? bs-on_read_error : bs-on_write_error;
}
+void bdrv_dev_set_medium_eject_notify(BlockDriverState *bs,
+ bdrv_dev_medium_eject_notify_cb cb)
+{
+bs-dev_medium_eject_notify_cb = cb;
+}
+
+void bdrv_dev_medium_eject_notify(BlockDriverState *bs, int is_ejected)
+{
+assert(bs-dev_medium_eject_notify_cb);
+bs-dev_medium_eject_notify_cb(bs, is_ejected);
+}
+
int bdrv_is_read_only(BlockDriverState *bs)
{
return bs-read_only;
diff --git a/block.h b/block.h
index 3bd4398..344ca0d 100644
--- a/block.h
+++ b/block.h
@@ -247,6 +247,11 @@ int bdrv_get_translation_hint(BlockDriverState *bs);
void bdrv_set_on_error(BlockDriverState *bs, BlockErrorAction
on_read_error,
BlockErrorAction on_write_error);
BlockErrorAction bdrv_get_on_error(BlockDriverState *bs, int is_read);
+typedef void (*bdrv_dev_medium_eject_notify_cb)(BlockDriverState *bs,
+int is_ejected);
+void bdrv_dev_set_medium_eject_notify(BlockDriverState *bs,
+ bdrv_dev_medium_eject_notify_cb cb);
+void bdrv_dev_medium_eject_notify(BlockDriverState *bs, int is_ejected);
int bdrv_is_read_only(BlockDriverState *bs);
int bdrv_is_sg(BlockDriverState *bs);
int bdrv_enable_write_cache(BlockDriverState *bs);
diff --git a/block_int.h b/block_int.h
index 311bd2a..50c34f6 100644
--- a/block_int.h
+++ b/block_int.h
@@ -260,6 +260,9 @@ struct BlockDriverState {
QTAILQ_ENTRY(BlockDriverState) list;
void *private;
+/* Callback for medium eject */
+bdrv_dev_medium_eject_notify_cb dev_medium_eject_notify_cb;
+
QLIST_HEAD(, BdrvTrackedRequest) tracked_requests;
};
Why the indirection? Isn't this always on_medium_eject()?
bdrv_dev_medium_eject_notify_cb() asserts it's not null, and it's never
set to anything else.
If the indirection is justified, why is it per object (in
BlockDriverState) and not per driver (in BlockDriver)?
Update: I found a possible reason, see drive_init() below.
Let's discuss it below.
block.h and block_int.h don't typedef their methods, suggest to stick to
that.
Ok.
diff --git a/blockdev.c b/blockdev.c
index 1f83c88..71b50fa 100644
---
[Qemu-devel] Block-Migration eats my memory
Hi, we are trying to upgrade our systems from kvm 0.14 (Ubuntu 11.04) to 1.0 (Ubuntu 12.04). Everything works fine except block-migration. When startet, the kvm process allocates the size of the image as memory, which of course leads to an oom an large machines. I tried to debug with valgrind and gdb but didn't got very far. Does anybody else see this problem? Can I help somehow? I'm not member of this list, so please CC me. Cheers David
Re: [Qemu-devel] git bisect results
On 2012-01-25 12:48, erik.r...@rdsoftware.de wrote: Hi Jan, You should CC me then... :) This little change fixes my problem with the usb-tablet update rate. Can you please verify if this has some side effects? Surely as it disables in general valid code, namely the auto-grabbing feature. You should notice the difference. If not, can you post a real patch? I don't know how to handle the whole patching and committing stuff exactly. We need to understand the problem first anyway, and as I cannot reproduce it, I will need you help: Can you instrument the code, e.g. with printf, to find out which of the disabled branches is taken when, specifically how often? Can you also check if values like max_x/max_y or the ev-motion content make sense for your setup? Thanks, Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
Re: [Qemu-devel] [PATCH 1/2] Add dummy implementation of generic timer cp15 registers
On 25 January 2012 14:01, Andreas Färber afaer...@suse.de wrote: Am 25.01.2012 14:32, schrieb Peter Maydell: Add a dummy implementation of the cp15 registers for the generic timer (found in the Cortex-A15), just sufficient for Linux to decide that it can't use it. This requires at least CNTP_CTL and CNTFRQ to be implemented as RAZ/WI; we RAZ/WI all of c14. Signed-off-by: Peter Maydell peter.mayd...@linaro.org Reviewed-by: Andreas Färber afaer...@suse.de Took me a bit to figure out RAZ/WI. ;) Sorry, that's ARM ARM jargon :-) (Read As Zero/Writes Ignored, for anybody still baffled.) -- PMM
Re: [Qemu-devel] [PATCH 27/28] sysbus: apic: ioapic: convert to QEMU Object Model
On 2012-01-25 15:00, Anthony Liguori wrote:
On 01/25/2012 02:37 AM, Jan Kiszka wrote:
On 2012-01-25 00:03, Anthony Liguori wrote:
They're exactly the same size (16 lines). If you embed TypeInfo into
DeviceTypeInfo, and introduce a Device specific type registration
function, then you could do:
static DeviceTypeInfo my_device_type_info = {
.type.name = TYPE_MY_DEVICE,
.type.parent = TYPE_PARENT_DEVICE,
.reset = my_device_reset,
And if you introduce some
#define TYPE_UNIMPLEMENTED (void *)dummy_variable
(void *) isn't compatible with integers or function pointers (at least
not in a portable way).
The former is true, the latter not. However, if you use pointers in the
TypeInfo structs consistently (const int * etc.), this issue should be
solvable as well.
You would need to use type specific unimplemented mechanisms.
you can easily express
[.field = NULL] = use parent
.field = UNIMPLEMENTED = don't run any handler
};
static void register_devices(void)
{
device_type_register_static(my_device_type_info);
}
Which admittedly saves 6 lines, but also is a big step backwards IMHO.
Now you've got a lot of one-off functions which means you loose the
advantage of having everything work through the same infrastructure.
Can't follow. Four lines
[static inline] void device_type_register_static(DeviceTypeInfo *dt)
{
type_register_static(dt-type);
}
are neither ugly nor complex. Rather, this helps concentrating effort at
_central_ places instead of decentralizing and duplicating lines like in
your imperative approach. That's the whole point: keep the common case
(derived classes) compact.
Send a patch. The infrastructure available should be enough to do
whatever you need to.
I'm not being dismissive, I've already spent a lot of time trying to
make it work and have convinced myself that it isn't workable.
If you can show a mechanism that works, I don't mind scripting a mass
conversion. I'm also fairly confident that a workable solution is going
to be better than what we have.
Well, I'm surely not happy having to go through all of the devices
again, even if scripted (scripts tend to neglect some coding style rules
e.g.). But if this change is in a hurry and my concern is the only one,
then let it be.
Jan
signature.asc
Description: OpenPGP digital signature
[Qemu-devel] TCG register allocator
I am wondering how tcg reg alloc works. Specifically, how do i reserve a register only for one specific purpose. R14 on tcg i386 is reserved to point to the cpustate strcuture. it is assigned in the prologue, but what code makes sure that it is not clobbered in the middle of a TB ? Thanks Xin
Re: [Qemu-devel] [PATCH 27/28] sysbus: apic: ioapic: convert to QEMU Object Model
On 01/25/2012 02:33 AM, Andreas Färber wrote: Am 25.01.2012 00:03, schrieb Anthony Liguori: On 01/24/2012 04:06 PM, Jan Kiszka wrote: On 2012-01-24 22:53, Anthony Liguori wrote: But I don't like this. The problem is that the declarative syntax we have doesn't distinguish between not-specified and zero-initialized. That's surely solvable. Please try :-) I've spent a good chunk of time mulling this over and could not find an acceptable solution. I think the same is true for the GObject folks. There is a declarative solution for this that I know of, a C++ class definition ;-) So what's the reason not to go with one of the object-oriented, C-compatible languages GCC supports, like C++ or Objective-C/C++? (Objective-C has native reflection capabilities fwiw.) I actually prefer C++ but much in the same fashion that I prefer 8-space indenting. I think it's objectively better, but not significantly better enough to warrant the disruption of introducing it. C++ makes polymorphism easier and declaring classes a little nicer, but it doesn't help significantly with factories, properties, or introspection. Polymorphism in C is mostly a one-time cost so once you have the infrastructure (object.c), it's not really that bad. Regards, Anthony Liguori Personally I disliked those trivial mini init functions in the initial 2/4 series, too, but I don't really mind an imperative approach either. Andreas
Re: [Qemu-devel] [PATCH 27/28] sysbus: apic: ioapic: convert to QEMU Object Model
On 01/25/2012 08:23 AM, Jan Kiszka wrote:
On 2012-01-25 15:00, Anthony Liguori wrote:
On 01/25/2012 02:37 AM, Jan Kiszka wrote:
On 2012-01-25 00:03, Anthony Liguori wrote:
They're exactly the same size (16 lines). If you embed TypeInfo into
DeviceTypeInfo, and introduce a Device specific type registration
function, then you could do:
static DeviceTypeInfo my_device_type_info = {
.type.name = TYPE_MY_DEVICE,
.type.parent = TYPE_PARENT_DEVICE,
.reset = my_device_reset,
And if you introduce some
#define TYPE_UNIMPLEMENTED (void *)dummy_variable
(void *) isn't compatible with integers or function pointers (at least
not in a portable way).
I don't see how they can be compatible since on some platforms sizeof(void
(*)(void)) != sizeof(void *).
The former is true, the latter not. However, if you use pointers in the
TypeInfo structs consistently (const int * etc.), this issue should be
solvable as well.
How would you handle PCIDeviceInfo?
I'm not being dismissive, I've already spent a lot of time trying to
make it work and have convinced myself that it isn't workable.
If you can show a mechanism that works, I don't mind scripting a mass
conversion. I'm also fairly confident that a workable solution is going
to be better than what we have.
Well, I'm surely not happy having to go through all of the devices
again, even if scripted (scripts tend to neglect some coding style rules
e.g.). But if this change is in a hurry and my concern is the only one,
then let it be.
I wouldn't be happy with it either, but in the absence of a concrete counter
proposal and given that I've spent a fair amount of time trying to figure this
out, I strongly believe we won't need to make the change.
I'm happy to be proven wrong though.
Regards,
Anthony Liguori
Jan
Re: [Qemu-devel] [Android-virt] [PATCH 02/12] arm: make the number of GIC interrupts configurable
On 24 January 2012 08:42, Rusty Russell ru...@rustcorp.com.au wrote:
On Fri, 13 Jan 2012 20:52:39 +, Peter Maydell peter.mayd...@linaro.org
wrote:
From: Mark Langsdorf mark.langsd...@calxeda.com
Increase the maximum number of GIC interrupts for a9mp and a11mp to 1020,
and create a configurable property for each defaulting to 96 and 64
(respectively) so that device modelers can set the value appropriately
for their SoC. Other ARM processors also set their maximum number of
used IRQs appropriately.
Set the maximum theoretical number of GIC interrupts to 1020 and
update the save/restore code to only use the appropriate number for
each SoC.
Reading through this, I see a lot of - 32. Trivial patch follows,
which applies to your rebasing branch:
(If you send patches as fresh new emails then they just apply
with git am without needing manual cleanup, appear with sensible
subjects in patchwork/patches.linaro, etc.)
Subject: ARM: clean up GIC constants.
From: Rusty Russell ru...@rustcorp.com.au
Interrupts numbers 0-31 are private to the processor interface, 32-1019 are
general interrups. Add GIC_INTERNAL and substitute everywhere.
Also, add a check that the total number of interrupts is divisible by
32 (required for reporting interupt numbers, see gic_dist_readb(), and
is greater than 32. And remove a single stray tab.
I agree with Avi that the presence of Also in a git
commit message is generally a sign you should have submitted
more than one patch :-)
Signed-off-by: Rusty Russell ru...@rustcorp.com.au
---
hw/arm_gic.c | 48 ++--
1 files changed, 26 insertions(+), 22 deletions(-)
diff --git a/hw/arm_gic.c b/hw/arm_gic.c
index cf582a5..a29eacb 100644
--- a/hw/arm_gic.c
+++ b/hw/arm_gic.c
@@ -13,6 +13,8 @@
/* Maximum number of possible interrupts, determined by the GIC architecture
*/
#define GIC_MAXIRQ 1020
+/* First 32 are private to each CPU (SGIs and PPIs). */
+#define GIC_INTERNAL 32
//#define DEBUG_GIC
#ifdef DEBUG_GIC
@@ -74,7 +76,7 @@ typedef struct gic_irq_state
#define GIC_CLEAR_TRIGGER(irq) s-irq_state[irq].trigger = 0
#define GIC_TEST_TRIGGER(irq) s-irq_state[irq].trigger
#define GIC_GET_PRIORITY(irq, cpu) \
- (((irq) 32) ? s-priority1[irq][cpu] : s-priority2[(irq) - 32])
+ (((irq) GIC_INTERNAL) ? s-priority1[irq][cpu] : s-priority2[(irq) -
GIC_INTERNAL])
This line is now 80 characters and needs folding.
(scripts/checkpatch.pl will catch this kind of nit.)
@@ -812,11 +814,13 @@ static void gic_init(gic_state *s, int num_irq)
s-num_cpu = num_cpu;
#endif
s-num_irq = num_irq + GIC_BASE_IRQ;
- if (s-num_irq GIC_MAXIRQ) {
- hw_error(requested %u interrupt lines exceeds GIC maximum %d\n,
- num_irq, GIC_MAXIRQ);
+ if (s-num_irq GIC_MAXIRQ
+ || s-num_irq GIC_INTERNAL
+ || (s-num_irq % 32) != 0) {
So I guess our implementation isn't likely to work properly for a
non-multiple-of-32 number of IRQs, but this isn't an architectural GIC
restriction. (In fact the GIC architecture spec allows the supported
interrupt IDs to not even be in a contiguous range, which we certainly
don't support...)
I also think it's architecturally permitted that not all the internal
(SPI/PPI) interrupts are implemented, ie that s-num_irq 32 (you
have to read the GIC architecture manually quite closely to deduce
this, though).
Anyway, if we would otherwise die horribly later on we should
catch these cases, but it would be good to have at least a comment
saying that these are implementation limitations rather than
architectural ones.
Beefing up the parameter check should be a separate patch.
Otherwise OK.
-- PMM
Re: [Qemu-devel] TCG register allocator
On 25 January 2012 14:24, Xin Tong xerox.time.t...@gmail.com wrote: I am wondering how tcg reg alloc works. Specifically, how do i reserve a register only for one specific purpose. R14 on tcg i386 is reserved to point to the cpustate strcuture. it is assigned in the prologue, but what code makes sure that it is not clobbered in the middle of a TB ? target-i386/translate.c:optimize_flags_init() calls: cpu_env = tcg_global_reg_new_ptr(TCG_AREG0, env); which tells TCG that this register always has this value in it. TCG will then ensure that it doesn't try to use that register when it's doing allocation later. This is done by having tcg_global_reg_new_internal() call: tcg_regset_set_reg(s-reserved_regs, reg); We also add a register to the reserved_regs set in tcg/i386/tcg-target.c: tcg_target_init(): tcg_regset_set_reg(s-reserved_regs, TCG_REG_CALL_STACK); because attempting to allocate a value into ESP would be a bad idea :-) -- PMM
Re: [Qemu-devel] [PATCH 27/28] sysbus: apic: ioapic: convert to QEMU Object Model
Am 25.01.2012 15:40, schrieb Anthony Liguori:
On 01/25/2012 08:23 AM, Jan Kiszka wrote:
On 2012-01-25 15:00, Anthony Liguori wrote:
On 01/25/2012 02:37 AM, Jan Kiszka wrote:
On 2012-01-25 00:03, Anthony Liguori wrote:
They're exactly the same size (16 lines). If you embed TypeInfo into
DeviceTypeInfo, and introduce a Device specific type registration
function, then you could do:
static DeviceTypeInfo my_device_type_info = {
.type.name = TYPE_MY_DEVICE,
.type.parent = TYPE_PARENT_DEVICE,
.reset = my_device_reset,
And if you introduce some
#define TYPE_UNIMPLEMENTED (void *)dummy_variable
(void *) isn't compatible with integers or function pointers (at least
not in a portable way).
I don't see how they can be compatible since on some platforms
sizeof(void (*)(void)) != sizeof(void *).
Do you have an example of a platform relevant to QEMU?
Microcontrollers and DOS come to my mind.
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
[Qemu-devel] [PULL 0/6] qemu-ga queue and qemu-tool fixes
This pull adds 2 RPCs (guest-suspend and guest-set-support-level) to qemu-ga and some includes fixes/workarounds for building tools on Windows. The following changes since commit 5b4448d27d7c6ff6e18a1edc8245cb1db783e37c: Merge remote-tracking branch 'qemu-kvm/uq/master' into staging (2012-01-23 11:00:26 -0600) are available in the git repository at: git://github.com/mdroth/qemu.git qga-pull-2012-01-23 Luiz Capitulino (2): qemu-ga: set O_NONBLOCK for serial channels qemu-ga: Add the guest-suspend command Michael Roth (4): main-loop: Fix SetEvent() on uninitialized handle on win32 main-loop: For tools, initialize timers as part of qemu_init_main_loop() qemu-ga: Add schema documentation for types qemu-ga: add guest-set-support-level command main-loop.c|7 +- main-loop.h| 12 ++ qapi-schema-guest.json | 217 qemu-ga.c | 66 - qemu-tool.c|3 +- qga/guest-agent-commands.c | 239 qga/guest-agent-core.h | 11 ++ vl.c |5 + 8 files changed, 533 insertions(+), 27 deletions(-)
[Qemu-devel] [PATCH 1/6] main-loop: Fix SetEvent() on uninitialized handle on win32
The __attribute__((constructor)) init_main_loop() automatically get
called if qemu-tool.o is linked in. On win32, this leads to
a qemu_notify_event() call which attempts to SetEvent() on a HANDLE that
won't be initialized until qemu_init_main_loop() is manually called,
breaking qemu-tools.o programs on Windows at runtime.
This patch checks for an initialized event handle before attempting to
set it, which is analoguous to how we deal with an unitialized
io_thread_fd in the posix implementation.
Signed-off-by: Michael Roth mdr...@linux.vnet.ibm.com
---
main-loop.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/main-loop.c b/main-loop.c
index 692381c..62d95b9 100644
--- a/main-loop.c
+++ b/main-loop.c
@@ -164,7 +164,7 @@ static int qemu_signal_init(void)
#else /* _WIN32 */
-HANDLE qemu_event_handle;
+HANDLE qemu_event_handle = NULL;
static void dummy_event_handler(void *opaque)
{
@@ -183,6 +183,9 @@ static int qemu_event_init(void)
void qemu_notify_event(void)
{
+if (!qemu_event_handle) {
+return;
+}
if (!SetEvent(qemu_event_handle)) {
fprintf(stderr, qemu_notify_event: SetEvent failed: %ld\n,
GetLastError());
--
1.7.4.1
[Qemu-devel] [PATCH 5/6] qemu-ga: set O_NONBLOCK for serial channels
From: Luiz Capitulino lcapitul...@redhat.com
This fixes a bug when using -m isa-serial where qemu-ga will
hang on a read()'s when communicating to the host via isa-serial.
Original fix by Michael Roth.
Signed-off-by: Luiz Capitulino lcapitul...@redhat.com
Signed-off-by: Michael Roth mdr...@linux.vnet.ibm.com
---
qemu-ga.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/qemu-ga.c b/qemu-ga.c
index 8e5b075..d63b17c 100644
--- a/qemu-ga.c
+++ b/qemu-ga.c
@@ -544,7 +544,7 @@ static void init_guest_agent(GAState *s)
exit(EXIT_FAILURE);
}
} else if (strcmp(s-method, isa-serial) == 0) {
-fd = qemu_open(s-path, O_RDWR | O_NOCTTY);
+fd = qemu_open(s-path, O_RDWR | O_NOCTTY | O_NONBLOCK);
if (fd == -1) {
g_critical(error opening channel: %s, strerror(errno));
exit(EXIT_FAILURE);
--
1.7.4.1
[Qemu-devel] [PATCH 6/6] qemu-ga: Add the guest-suspend command
From: Luiz Capitulino lcapitul...@redhat.com
The guest-suspend command supports three modes:
o hibernate (suspend to disk)
o sleep (suspend to ram)
o hybrid(save RAM contents to disk, but suspend instead of
powering off)
Before trying to suspend, the command queries the guest in order
to know whether the given mode is supported. The sleep and hybrid
modes are only supported in QEMU 1.1 and later though, because
QEMU's S3 support is broken in previous versions.
The guest-suspend command will use the scripts provided by the
pm-utils package if they are available. If they aren't, a manual
process which directly writes to the /sys/power/state file is
used.
To reap terminated children, a new signal handler is installed in
the parent to catch SIGCHLD signals and a non-blocking call to
waitpid() is done to collect their exit statuses. The statuses,
however, are discarded.
The approach used to query the guest for suspend support deserves
some explanation. It's implemented by bios_supports_mode() and shown
below:
qemu-ga
|
create pipe
|
fork()
-
| |
| |
| fork()
| --
| ||
| ||
| | exec('pm-is-supported')
| |
| wait()
| write exit status to pipe
| exit
|
read pipe
This might look complex, but the resulting code is quite simple.
The purpose of that approach is to allow qemu-ga to reap its
children (semi-)automatically from its SIGCHLD handler.
Implementing this the obvious way, that's, doing the exec() call
from the first child process, would force us to introduce a more
complex way to reap qemu-ga's children. Like registering PIDs to
be reaped and having a way to wait for them when returning their
exit status to qemu-ga is necessary. The approach explained
above avoids that complexity.
Signed-off-by: Luiz Capitulino lcapitul...@redhat.com
Signed-off-by: Michael Roth mdr...@linux.vnet.ibm.com
---
qapi-schema-guest.json | 32 ++
qemu-ga.c | 18 -
qga/guest-agent-commands.c | 226
3 files changed, 275 insertions(+), 1 deletions(-)
diff --git a/qapi-schema-guest.json b/qapi-schema-guest.json
index 81cd773..9b1ab1c 100644
--- a/qapi-schema-guest.json
+++ b/qapi-schema-guest.json
@@ -360,3 +360,35 @@
##
{ 'command': 'guest-fsfreeze-thaw',
'returns': 'int' }
+
+##
+# @guest-suspend
+#
+# Suspend guest execution by entering ACPI power state S3 or S4.
+#
+# This command tries to execute the scripts provided by the pm-utils
+# package. If they are not available, it will perform the suspend
+# operation by manually writing to a sysfs file.
+#
+# For the best results it's strongly recommended to have the pm-utils
+# package installed in the guest.
+#
+# @mode: 'hibernate' RAM content is saved to the disk and the guest is
+#powered off (this corresponds to ACPI S4)
+#'sleep' execution is suspended but the RAM retains its contents
+#(this corresponds to ACPI S3)
+#'hybrid'RAM content is saved to the disk but the guest is
+#suspended instead of powering off
+#
+# Returns: nothing on success
+# If @mode is not supported by the guest, Unsupported
+#
+# Notes: o This is an asynchronous request. There's no guarantee a response
+# will be sent.
+#o Errors will be logged to guest's syslog.
+#o It's strongly recommended to issue the guest-sync command before
+# sending commands when the guest resumes.
+#
+# Since: 1.1
+##
+{ 'command': 'guest-suspend', 'data': { 'mode': 'str' } }
diff --git a/qemu-ga.c b/qemu-ga.c
index d63b17c..f8b12c7 100644
--- a/qemu-ga.c
+++ b/qemu-ga.c
@@ -17,6 +17,7 @@
#include getopt.h
#include termios.h
#include syslog.h
+#include sys/wait.h
#include qemu_socket.h
#include json-streamer.h
#include json-parser.h
@@ -60,9 +61,16 @@ static void quit_handler(int sig)
}
}
+/* reap _all_ terminated children */
+static void child_handler(int sig)
+{
+int status;
+while (waitpid(-1, status, WNOHANG) 0) /* NOTHING */;
+}
+
static void register_signal_handlers(void)
{
-struct sigaction sigact;
+struct sigaction sigact, sigact_chld;
int ret;
memset(sigact, 0, sizeof(struct sigaction));
@@ -77,6 +85,14 @@ static void register_signal_handlers(void)
if (ret == -1) {
g_error(error configuring signal handler: %s, strerror(errno));
}
+
+memset(sigact_chld, 0, sizeof(struct sigaction));
+sigact_chld.sa_handler = child_handler;
+sigact_chld.sa_flags = SA_NOCLDSTOP;
+ret = sigaction(SIGCHLD, sigact_chld, NULL);
+if (ret == -1) {
+g_error(error configuring signal handler: %s,
[Qemu-devel] [PATCH 1/5] target-arm: Fix implementation of TLB invalidate operations
Fix some bugs in the implementation of the TLB invalidate
operations on ARM:
* the 'invalidate all' op was not passing flush_global=1
to tlb_flush(); this doesn't have a practical effect since
tlb_flush() currently ignores that argument, but is
semantically incorrect
* 'invalidate by address for all ASIDs' was implemented as
flushing the whole TLB, which invalidates much more than
strictly necessary. Use tlb_flush_page() instead.
We also annotate the ops with the ARM ARM official acronyms.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
target-arm/helper.c | 13 ++---
1 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/target-arm/helper.c b/target-arm/helper.c
index 00458fc..f11279e 100644
--- a/target-arm/helper.c
+++ b/target-arm/helper.c
@@ -1610,18 +1610,17 @@ void HELPER(set_cp15)(CPUState *env, uint32_t insn,
uint32_t val)
break;
case 8: /* MMU TLB control. */
switch (op2) {
-case 0: /* Invalidate all. */
-tlb_flush(env, 0);
+case 0: /* Invalidate all (TLBIALL) */
+tlb_flush(env, 1);
break;
-case 1: /* Invalidate single TLB entry. */
+case 1: /* Invalidate single TLB entry by MVA and ASID (TLBIMVA) */
tlb_flush_page(env, val TARGET_PAGE_MASK);
break;
-case 2: /* Invalidate on ASID. */
+case 2: /* Invalidate by ASID (TLBIASID) */
tlb_flush(env, val == 0);
break;
-case 3: /* Invalidate single entry on MVA. */
-/* ??? This is like case 1, but ignores ASID. */
-tlb_flush(env, 1);
+case 3: /* Invalidate single entry by MVA, all ASIDs (TLBIMVAA) */
+tlb_flush_page(env, val TARGET_PAGE_MASK);
break;
default:
goto bad_reg;
--
1.7.1
[Qemu-devel] [PATCH 2/5] target-arm/helper.c: Don't assume softfloat int32 is 32 bits only
In the helper routines for VCVT float-to-int conversions, add
an explicit cast rather than relying on the softfloat int32
type being exactly 32 bits wide (which it is not guaranteed to be).
Without this, if the softfloat type was 64 bits wide we would
get zero-extension of the 32 bit value from the ARM register
rather than sign-extension, since TCG i32 values are passed as
uint32_t.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
target-arm/helper.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/target-arm/helper.c b/target-arm/helper.c
index f11279e..f6e998b 100644
--- a/target-arm/helper.c
+++ b/target-arm/helper.c
@@ -2785,7 +2785,7 @@ DO_VFP_cmp(d, float64)
float##fsz HELPER(name)(uint32_t x, void *fpstp) \
{ \
float_status *fpst = fpstp; \
-return sign##int32_to_##float##fsz(x, fpst); \
+return sign##int32_to_##float##fsz((sign##int32_t)x, fpst); \
}
#define CONV_FTOI(name, fsz, sign, round) \
--
1.7.1
Re: [Qemu-devel] [PATCH 27/28] sysbus: apic: ioapic: convert to QEMU Object Model
On 01/25/2012 07:40 AM, Anthony Liguori wrote: (void *) isn't compatible with integers or function pointers (at least not in a portable way). I don't see how they can be compatible since on some platforms sizeof(void (*)(void)) != sizeof(void *). C99 says they are not required to be the same, but POSIX adds an additional requirement on top of C that all function pointers must be convertible to void* and back without loss of data. Pretty much any system where qemu can compile is probably already complying with that particular POSIX extension to C, even if it is not portable in practice to a pure C environment. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [RFC/PATCH] Fix guest OS panic when 64bit BAR is present
On Wed, Jan 25, 2012 at 06:46:03PM +1300, Alexey Korolev wrote:
Hi,
In this post
http://lists.gnu.org/archive/html/qemu-devel/2011-12/msg03171.html I've
mentioned about the issues when 64Bit PCI BAR is present and 32bit
address range is selected for it.
The issue affects all recent qemu releases and all
old and recent guest Linux kernel versions.
For testing, I applied the following patch to qemu,
converting msix bar to 64 bit.
Guest did not seem to crash.
I booted Fedora Live CD 32 bit guest on a 32 bit host
to level 3 without crash, and verified that
the BAR is a 64 bit one, and that I got assigned an address
at fe00.
command line I used:
qemu-system-x86_64 -bios /scm/seabios/out/bios.bin -snapshot -drive
file=qemu-images/f15-test.qcow2,if=none,id=diskid,cache=unsafe
-device virtio-blk-pci,drive=diskid -net user -net nic,model=ne2k_pci
-cdrom Fedora-15-i686-Live-LXDE.iso
At boot prompt type tab and add '3' to kernel command line
to have guest boot into a fast text console instead
of a graphical one which is very slow.
diff --git a/hw/virtio-pci.c b/hw/virtio-pci.c
index 2ac87ea..5271394 100644
--- a/hw/virtio-pci.c
+++ b/hw/virtio-pci.c
@@ -711,7 +711,8 @@ void virtio_init_pci(VirtIOPCIProxy *proxy, VirtIODevice
*vdev)
memory_region_init(proxy-msix_bar, virtio-msix, 4096);
if (vdev-nvectors !msix_init(proxy-pci_dev, vdev-nvectors,
proxy-msix_bar, 1, 0)) {
-pci_register_bar(proxy-pci_dev, 1, PCI_BASE_ADDRESS_SPACE_MEMORY,
+pci_register_bar(proxy-pci_dev, 1, PCI_BASE_ADDRESS_SPACE_MEMORY |
+PCI_BASE_ADDRESS_MEM_TYPE_64,
proxy-msix_bar);
} else
vdev-nvectors = 0;
Re: [Qemu-devel] TCG register allocator
I tried to reserve a register in target-i386 with this code target-i386/translate.ctb_env = tcg_global_reg_new_ptr(TCG_AREG1, env); i386/tcg-target.h #define TCG_AREG1 TCG_REG_R13 i386/tcg-target.c tcg_out_movi(s, TCG_TYPE_PTR, TCG_AREG1, args[0]); But when i looked into the dynamically generated code, the place which i use TCG_AREG1 becomes RBP and RBP is not reserved either. Thanks Xin On Wed, Jan 25, 2012 at 10:19 AM, Peter Maydell peter.mayd...@linaro.org wrote: On 25 January 2012 14:24, Xin Tong xerox.time.t...@gmail.com wrote: I am wondering how tcg reg alloc works. Specifically, how do i reserve a register only for one specific purpose. R14 on tcg i386 is reserved to point to the cpustate strcuture. it is assigned in the prologue, but what code makes sure that it is not clobbered in the middle of a TB ? target-i386/translate.c:optimize_flags_init() calls: cpu_env = tcg_global_reg_new_ptr(TCG_AREG0, env); which tells TCG that this register always has this value in it. TCG will then ensure that it doesn't try to use that register when it's doing allocation later. This is done by having tcg_global_reg_new_internal() call: tcg_regset_set_reg(s-reserved_regs, reg); We also add a register to the reserved_regs set in tcg/i386/tcg-target.c: tcg_target_init(): tcg_regset_set_reg(s-reserved_regs, TCG_REG_CALL_STACK); because attempting to allocate a value into ESP would be a bad idea :-) -- PMM
Re: [Qemu-devel] TCG register allocator
On 25 January 2012 15:42, Xin Tong xerox.time.t...@gmail.com wrote: I tried to reserve a register in target-i386 with this code target-i386/translate.c tb_env = tcg_global_reg_new_ptr(TCG_AREG1, env); Why do you want to define a second global which holds the environment variable? Just use TCG_AREG0 for that. i386/tcg-target.h #define TCG_AREG1 TCG_REG_R13 i386/tcg-target.c tcg_out_movi(s, TCG_TYPE_PTR, TCG_AREG1, args[0]); But when i looked into the dynamically generated code, the place which i use TCG_AREG1 becomes RBP and RBP is not reserved either. If the reason you're trying to reserve a register is so you can use it as a temporary in tcg-target.c's codegen, then reserve it in tcg_target_init(). (But x86-32 is very short on registers as it is, so really it would be much better not to...) -- PMM
[Qemu-devel] [PATCH 3/6] qemu-ga: Add schema documentation for types
Document guest agent schema types in similar fashion as qmp schema
types.
Signed-off-by: Michael Roth mdr...@linux.vnet.ibm.com
---
qapi-schema-guest.json | 118 +++-
1 files changed, 97 insertions(+), 21 deletions(-)
diff --git a/qapi-schema-guest.json b/qapi-schema-guest.json
index 5f8a18d..706925d 100644
--- a/qapi-schema-guest.json
+++ b/qapi-schema-guest.json
@@ -37,17 +37,42 @@
{ 'command': 'guest-ping' }
##
-# @guest-info:
+# @GuestAgentCommandInfo:
#
-# Get some information about the guest agent.
+# Information about guest agent commands.
#
-# Since: 0.15.0
+# @name: name of the command
+#
+# @enabled: whether command is currently enabled by guest admin
+#
+# Since 1.1.0
##
{ 'type': 'GuestAgentCommandInfo',
'data': { 'name': 'str', 'enabled': 'bool' } }
+
+##
+# @GuestAgentInfo
+#
+# Information about guest agent.
+#
+# @version: guest agent version
+#
+# @supported_commands: Information about guest agent commands
+#
+# Since 0.15.0
+##
{ 'type': 'GuestAgentInfo',
'data': { 'version': 'str',
'supported_commands': ['GuestAgentCommandInfo'] } }
+##
+# @guest-info:
+#
+# Get some information about the guest agent.
+#
+# Returns: @GuestAgentInfo
+#
+# Since: 0.15.0
+##
{ 'command': 'guest-info',
'returns': 'GuestAgentInfo' }
@@ -98,6 +123,23 @@
'data': { 'handle': 'int' } }
##
+# @GuestFileRead
+#
+# Result of guest agent file-read operation
+#
+# @count: number of bytes read (note: count is *before*
+# base64-encoding is applied)
+#
+# @buf-b64: base64-encoded bytes read
+#
+# @eof: whether EOF was encountered during read operation.
+#
+# Since: 0.15.0
+##
+{ 'type': 'GuestFileRead',
+ 'data': { 'count': 'int', 'buf-b64': 'str', 'eof': 'bool' } }
+
+##
# @guest-file-read:
#
# Read from an open file in the guest. Data will be base64-encoded
@@ -106,19 +148,30 @@
#
# @count: #optional maximum number of bytes to read (default is 4KB)
#
-# Returns: GuestFileRead on success. Note: count is number of bytes read
-# *before* base64 encoding bytes read.
+# Returns: @GuestFileRead on success.
#
# Since: 0.15.0
##
-{ 'type': 'GuestFileRead',
- 'data': { 'count': 'int', 'buf-b64': 'str', 'eof': 'bool' } }
-
{ 'command': 'guest-file-read',
'data':{ 'handle': 'int', '*count': 'int' },
'returns': 'GuestFileRead' }
##
+# @GuestFileWrite
+#
+# Result of guest agent file-write operation
+#
+# @count: number of bytes written (note: count is actual bytes
+# written, after base64-decoding of provided buffer)
+#
+# @eof: whether EOF was encountered during write operation.
+#
+# Since: 0.15.0
+##
+{ 'type': 'GuestFileWrite',
+ 'data': { 'count': 'int', 'eof': 'bool' } }
+
+##
# @guest-file-write:
#
# Write to an open file in the guest.
@@ -130,17 +183,29 @@
# @count: #optional bytes to write (actual bytes, after base64-decode),
# default is all content in buf-b64 buffer after base64 decoding
#
-# Returns: GuestFileWrite on success. Note: count is the number of bytes
-# base64-decoded bytes written
+# Returns: @GuestFileWrite on success.
#
# Since: 0.15.0
##
-{ 'type': 'GuestFileWrite',
- 'data': { 'count': 'int', 'eof': 'bool' } }
{ 'command': 'guest-file-write',
'data':{ 'handle': 'int', 'buf-b64': 'str', '*count': 'int' },
'returns': 'GuestFileWrite' }
+
+##
+# @GuestFileSeek
+#
+# Result of guest agent file-seek operation
+#
+# @position: current file position
+#
+# @eof: whether EOF was encountered during file seek
+#
+# Since: 0.15.0
+##
+{ 'type': 'GuestFileSeek',
+ 'data': { 'position': 'int', 'eof': 'bool' } }
+
##
# @guest-file-seek:
#
@@ -154,13 +219,10 @@
#
# @whence: SEEK_SET, SEEK_CUR, or SEEK_END, as with fseek()
#
-# Returns: GuestFileSeek on success.
+# Returns: @GuestFileSeek on success.
#
# Since: 0.15.0
##
-{ 'type': 'GuestFileSeek',
- 'data': { 'position': 'int', 'eof': 'bool' } }
-
{ 'command': 'guest-file-seek',
'data':{ 'handle': 'int', 'offset': 'int', 'whence': 'int' },
'returns': 'GuestFileSeek' }
@@ -180,18 +242,32 @@
'data': { 'handle': 'int' } }
##
-# @guest-fsfreeze-status:
+# @GuestFsFreezeStatus
#
-# Get guest fsfreeze state. error state indicates failure to thaw 1 or more
-# previously frozen filesystems, or failure to open a previously cached
-# filesytem (filesystem unmounted/directory changes, etc).
+# An enumation of filesystem freeze states
#
-# Returns: GuestFsfreezeStatus (thawed, frozen, etc., as defined below)
+# @thawed: filesystems thawed/unfrozen
+#
+# @frozen: all non-network guest filesystems frozen
+#
+# @error: failure to thaw 1 or more
+# previously frozen filesystems, or failure to open a previously
+# cached filesytem (filesystem unmounted/directory changes, etc).
#
# Since: 0.15.0
##
{ 'enum': 'GuestFsfreezeStatus',
'data': [ 'thawed', 'frozen', 'error' ] }
+
+##
+# @guest-fsfreeze-status:
+#
+# Get guest fsfreeze state. error state indicates
Re: [Qemu-devel] TCG register allocator
I have a bug, it segfaults when executing a translation blocks. when i disable block chaining, the bug disappears. However, with block chaining, i do not know which translation block jumps to the code which caused the segfault. I want to reserve a register and use it to record the last translation block executed. So at entry, i assign the translation blocks address to the register and when the segfault happens, I can get the last translation block executed. Thanks On Wed, Jan 25, 2012 at 10:49 AM, Peter Maydell peter.mayd...@linaro.org wrote: On 25 January 2012 15:42, Xin Tong xerox.time.t...@gmail.com wrote: I tried to reserve a register in target-i386 with this code target-i386/translate.c tb_env = tcg_global_reg_new_ptr(TCG_AREG1, env); Why do you want to define a second global which holds the environment variable? Just use TCG_AREG0 for that. i386/tcg-target.h #define TCG_AREG1 TCG_REG_R13 i386/tcg-target.c tcg_out_movi(s, TCG_TYPE_PTR, TCG_AREG1, args[0]); But when i looked into the dynamically generated code, the place which i use TCG_AREG1 becomes RBP and RBP is not reserved either. If the reason you're trying to reserve a register is so you can use it as a temporary in tcg-target.c's codegen, then reserve it in tcg_target_init(). (But x86-32 is very short on registers as it is, so really it would be much better not to...) -- PMM
Re: [Qemu-devel] TCG register allocator
The segfault is caused by jumping to the middle of an instruction. so i want to know which TB jumps here. Thanks Xin On Wed, Jan 25, 2012 at 10:54 AM, Xin Tong xerox.time.t...@gmail.com wrote: I have a bug, it segfaults when executing a translation blocks. when i disable block chaining, the bug disappears. However, with block chaining, i do not know which translation block jumps to the code which caused the segfault. I want to reserve a register and use it to record the last translation block executed. So at entry, i assign the translation blocks address to the register and when the segfault happens, I can get the last translation block executed. Thanks On Wed, Jan 25, 2012 at 10:49 AM, Peter Maydell peter.mayd...@linaro.org wrote: On 25 January 2012 15:42, Xin Tong xerox.time.t...@gmail.com wrote: I tried to reserve a register in target-i386 with this code target-i386/translate.c tb_env = tcg_global_reg_new_ptr(TCG_AREG1, env); Why do you want to define a second global which holds the environment variable? Just use TCG_AREG0 for that. i386/tcg-target.h #define TCG_AREG1 TCG_REG_R13 i386/tcg-target.c tcg_out_movi(s, TCG_TYPE_PTR, TCG_AREG1, args[0]); But when i looked into the dynamically generated code, the place which i use TCG_AREG1 becomes RBP and RBP is not reserved either. If the reason you're trying to reserve a register is so you can use it as a temporary in tcg-target.c's codegen, then reserve it in tcg_target_init(). (But x86-32 is very short on registers as it is, so really it would be much better not to...) -- PMM
[Qemu-devel] [PATCH 3/5] arm: store the config_base_register during cpu_reset
From: Mark Langsdorf mark.langsd...@calxeda.com
Long term, the config_base_register will be a QDM parameter. In the
meantime, models that use it need to be able to preserve it across
cpu_reset() calls.
Signed-off-by: Mark Langsdorf mark.langsd...@calxeda.com
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
target-arm/helper.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/target-arm/helper.c b/target-arm/helper.c
index f6e998b..22e40fc 100644
--- a/target-arm/helper.c
+++ b/target-arm/helper.c
@@ -255,6 +255,7 @@ static void cpu_reset_model_id(CPUARMState *env, uint32_t
id)
void cpu_reset(CPUARMState *env)
{
uint32_t id;
+uint32_t tmp = 0;
if (qemu_loglevel_mask(CPU_LOG_RESET)) {
qemu_log(CPU Reset (CPU %d)\n, env-cpu_index);
@@ -262,9 +263,11 @@ void cpu_reset(CPUARMState *env)
}
id = env-cp15.c0_cpuid;
+tmp = env-cp15.c15_config_base_address;
memset(env, 0, offsetof(CPUARMState, breakpoints));
if (id)
cpu_reset_model_id(env, id);
+env-cp15.c15_config_base_address = tmp;
#if defined (CONFIG_USER_ONLY)
env-uncached_cpsr = ARM_CPU_MODE_USR;
/* For user mode we must enable access to coprocessors */
--
1.7.1
[Qemu-devel] [PATCH 5/5] Add Cortex-A15 CPU definition
Add a definition of a Cortex-A15 CPU. Note that for the moment we do
not implement any of:
* Large Physical Address Extensions (LPAE)
* Virtualization Extensions
* Generic Timer
* TrustZone (this is also true of our existing Cortex-A9 model, etc)
This CPU model is sufficient to boot a Linux kernel which has been
compiled for an A15 without LPAE enabled.
Reviewed-by: Andreas Färber afaer...@suse.de
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
target-arm/cpu.h|1 +
target-arm/helper.c | 56 ++
2 files changed, 52 insertions(+), 5 deletions(-)
diff --git a/target-arm/cpu.h b/target-arm/cpu.h
index 7442c99..0d9b39c 100644
--- a/target-arm/cpu.h
+++ b/target-arm/cpu.h
@@ -433,6 +433,7 @@ void cpu_arm_set_cp_io(CPUARMState *env, int cpnum,
#define ARM_CPUID_ARM11MPCORE 0x410fb022
#define ARM_CPUID_CORTEXA80x410fc080
#define ARM_CPUID_CORTEXA90x410fc090
+#define ARM_CPUID_CORTEXA15 0x412fc0f1
#define ARM_CPUID_CORTEXM30x410fc231
#define ARM_CPUID_ANY 0x
diff --git a/target-arm/helper.c b/target-arm/helper.c
index 5e7205a..ea4f35f 100644
--- a/target-arm/helper.c
+++ b/target-arm/helper.c
@@ -10,6 +10,16 @@
#if !defined(CONFIG_USER_ONLY)
#include hw/loader.h
#endif
+#include sysemu.h
+
+static uint32_t cortexa15_cp15_c0_c1[8] = {
+0x1131, 0x00011011, 0x02010555, 0x,
+0x10201105, 0x2000, 0x0124, 0x02102211
+};
+
+static uint32_t cortexa15_cp15_c0_c2[8] = {
+0x02101110, 0x13112111, 0x21232041, 0x2131, 0x10011142, 0, 0, 0
+};
static uint32_t cortexa9_cp15_c0_c1[8] =
{ 0x1031, 0x11, 0x000, 0, 0x00100103, 0x2000, 0x0123, 0x2111 };
@@ -158,6 +168,27 @@ static void cpu_reset_model_id(CPUARMState *env, uint32_t
id)
env-cp15.c0_ccsid[1] = 0x200fe015; /* 16k L1 icache. */
env-cp15.c1_sys = 0x00c50078;
break;
+case ARM_CPUID_CORTEXA15:
+set_feature(env, ARM_FEATURE_V7);
+set_feature(env, ARM_FEATURE_VFP4);
+set_feature(env, ARM_FEATURE_VFP_FP16);
+set_feature(env, ARM_FEATURE_NEON);
+set_feature(env, ARM_FEATURE_THUMB2EE);
+set_feature(env, ARM_FEATURE_ARM_DIV);
+set_feature(env, ARM_FEATURE_V7MP);
+set_feature(env, ARM_FEATURE_GENERIC_TIMER);
+env-vfp.xregs[ARM_VFP_FPSID] = 0x410430f0;
+env-vfp.xregs[ARM_VFP_MVFR0] = 0x10110222;
+env-vfp.xregs[ARM_VFP_MVFR1] = 0x;
+memcpy(env-cp15.c0_c1, cortexa15_cp15_c0_c1, 8 * sizeof(uint32_t));
+memcpy(env-cp15.c0_c2, cortexa15_cp15_c0_c2, 8 * sizeof(uint32_t));
+env-cp15.c0_cachetype = 0x8444c004;
+env-cp15.c0_clid = 0x0a200023;
+env-cp15.c0_ccsid[0] = 0x701fe00a; /* 32K L1 dcache */
+env-cp15.c0_ccsid[1] = 0x201fe00a; /* 32K L1 icache */
+env-cp15.c0_ccsid[2] = 0x711fe07a; /* 4096K L2 unified cache */
+env-cp15.c1_sys = 0x00c50078;
+break;
case ARM_CPUID_CORTEXM3:
set_feature(env, ARM_FEATURE_V7);
set_feature(env, ARM_FEATURE_M);
@@ -416,6 +447,7 @@ static const struct arm_cpu_t arm_cpu_names[] = {
{ ARM_CPUID_CORTEXM3, cortex-m3},
{ ARM_CPUID_CORTEXA8, cortex-a8},
{ ARM_CPUID_CORTEXA9, cortex-a9},
+{ ARM_CPUID_CORTEXA15, cortex-a15 },
{ ARM_CPUID_TI925T, ti925t },
{ ARM_CPUID_PXA250, pxa250 },
{ ARM_CPUID_SA1100,sa1100 },
@@ -670,8 +702,6 @@ uint32_t HELPER(get_r13_banked)(CPUState *env, uint32_t
mode)
#else
-extern int semihosting_enabled;
-
/* Map CPU modes onto saved register banks. */
static inline int bank_number(CPUState *env, int mode)
{
@@ -1945,6 +1975,7 @@ uint32_t HELPER(get_cp15)(CPUState *env, uint32_t insn)
case ARM_CPUID_CORTEXA8:
return 2;
case ARM_CPUID_CORTEXA9:
+case ARM_CPUID_CORTEXA15:
return 0;
default:
goto bad_reg;
@@ -2065,11 +2096,26 @@ uint32_t HELPER(get_cp15)(CPUState *env, uint32_t insn)
goto bad_reg;
}
case 1: /* L2 cache */
-if (crm != 0) {
+/* L2 Lockdown and Auxiliary control. */
+switch (op2) {
+case 0:
+/* L2 cache lockdown (A8 only) */
+return 0;
+case 2:
+/* L2 cache auxiliary control (A8) or control (A15) */
+if (ARM_CPUID(env) == ARM_CPUID_CORTEXA15) {
+/* Linux wants the number of processors from here.
+ * Might as well set the interrupt-controller bit too.
+ */
+return ((smp_cpus - 1) 24) | (1 23);
+}
+return 0;
+case 3:
+/* L2 cache extended control (A15) */
+return 0;
+default:
[Qemu-devel] [PATCH 4/5] Add dummy implementation of generic timer cp15 registers
Add a dummy implementation of the cp15 registers for the generic
timer (found in the Cortex-A15), just sufficient for Linux to
decide that it can't use it. This requires at least CNTP_CTL and
CNTFRQ to be implemented as RAZ/WI; we RAZ/WI all of c14.
Reviewed-by: Andreas Färber afaer...@suse.de
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
target-arm/cpu.h|1 +
target-arm/helper.c | 12 ++--
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/target-arm/cpu.h b/target-arm/cpu.h
index 42c53a7..7442c99 100644
--- a/target-arm/cpu.h
+++ b/target-arm/cpu.h
@@ -382,6 +382,7 @@ enum arm_features {
ARM_FEATURE_VAPA, /* cp15 VA to PA lookups */
ARM_FEATURE_ARM_DIV, /* divide supported in ARM encoding */
ARM_FEATURE_VFP4, /* VFPv4 (implies that NEON is v2) */
+ARM_FEATURE_GENERIC_TIMER,
};
static inline int arm_feature(CPUARMState *env, int feature)
diff --git a/target-arm/helper.c b/target-arm/helper.c
index 22e40fc..5e7205a 100644
--- a/target-arm/helper.c
+++ b/target-arm/helper.c
@@ -1764,7 +1764,11 @@ void HELPER(set_cp15)(CPUState *env, uint32_t insn,
uint32_t val)
goto bad_reg;
}
break;
-case 14: /* Reserved. */
+case 14: /* Generic timer */
+if (arm_feature(env, ARM_FEATURE_GENERIC_TIMER)) {
+/* Dummy implementation: RAZ/WI for all */
+break;
+}
goto bad_reg;
case 15: /* Implementation specific. */
if (arm_feature(env, ARM_FEATURE_XSCALE)) {
@@ -2134,7 +2138,11 @@ uint32_t HELPER(get_cp15)(CPUState *env, uint32_t insn)
default:
goto bad_reg;
}
-case 14: /* Reserved. */
+case 14: /* Generic timer */
+if (arm_feature(env, ARM_FEATURE_GENERIC_TIMER)) {
+/* Dummy implementation: RAZ/WI for all */
+return 0;
+}
goto bad_reg;
case 15: /* Implementation specific. */
if (arm_feature(env, ARM_FEATURE_XSCALE)) {
--
1.7.1
[Qemu-devel] [PULL 0/5] target-arm queue
Here's the latest target-arm pullreq. It includes Mark's fix for config_base_register, which is in turn a dependency of the arm-devs pullreq I'm about to send out, and which I'd like to get in before Anthony's QOM patchset lands and invalidates it :-) Please pull. -- PMM The following changes since commit 5b4448d27d7c6ff6e18a1edc8245cb1db783e37c: Merge remote-tracking branch 'qemu-kvm/uq/master' into staging (2012-01-23 11:00:26 -0600) are available in the git repository at: git://git.linaro.org/people/pmaydell/qemu-arm.git target-arm.for-upstream Mark Langsdorf (1): arm: store the config_base_register during cpu_reset Peter Maydell (4): target-arm: Fix implementation of TLB invalidate operations target-arm/helper.c: Don't assume softfloat int32 is 32 bits only Add dummy implementation of generic timer cp15 registers Add Cortex-A15 CPU definition target-arm/cpu.h|2 + target-arm/helper.c | 86 ++- 2 files changed, 73 insertions(+), 15 deletions(-)
Re: [Qemu-devel] [PATCH] iSCSI: add configuration variables for iSCSI
On 01/24/2012 11:47 PM, ronnie sahlberg wrote: Read from an arbitrary filedescriptor inherited from the parent process : 9iscsi.conf ./x86_64-softmmu/qemu-system-x86_64 -enable-kvm -display vnc=127.0.0.1:0 -drive file=iscsi://127.0.0.1/iqn.ronnie.test/1 -readconfig /proc/self/fd/9 That requires the existence of procfs, which is not portable (although it does work on Linux). I'd rather see: -readconfig fd:9 which matches things for -incoming; that is, if -readconfig starts with '/' or '.', it is a filename; otherwise, it is a protocol:value designation, where we recognize at least the fd: protocol where a value is the incoming fd, but we could also recognize things like exec: protocol which is an arbitrary command to use via popen. I imagine you would pipe() then fork() and pass the read side of your pipe to qemu here ? Yes, the idea is that libvirt would rather pipe() and then pass the read size fd to qemu, so that libvirt's handling of the decrypted secret information is only ever passed over the pipe and not stored on disk. If this works well or at least in some acceptable form it might be useful for other users needing to pass sensitive config data into QEMU too? Yes, the fd: notation of -incoming should be reusable in multiple contexsts, including any other location where sensitive information must be passed in. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] TCG register allocator
I have a bug, it segfaults when executing a translation blocks. when i disable block chaining, the bug disappears. However, with block chaining, i do not know which translation block jumps to the code which caused the segfault. I want to reserve a register and use it to record the last translation block executed. So at entry, i assign the translation blocks address to the register and when the segfault happens, I can get the last translation block executed. You could inject a helper call at the beginning of each TB that would record e.g. current program counter into a global variable. -- Thanks. -- Max
[Qemu-devel] [PATCH 4/6] qemu-ga: add guest-set-support-level command
Recently commands where introduced on the mailing that involved adding
commands to the guest agent that could potentially break older versions
of QEMU. While it's okay to expect that qemu-ga can be updated to support
newer host features, it's unrealistic to require a host to be updated to
support qemu-ga features, or to expect that qemu-ga should be downgraded
in these circumstances, especially considering that a large mix of
guests/agents may be running on a particular host.
To address this, we introduce here a mechanism to set qemu-ga's
feature-set to one that is known to be compatible with
the host/QEMU running the guest. As new commands/options are added, we
can maintain backward-compatibility by adding conditional checks to filter
out host-incompatible functionality based on the host-specified support
level (generally analogous to the host QEMU version) set by the
client.
The current default/minimum support level supports all versions of QEMU
that have had qemu-ga in-tree (0.15.0, 1.0.0) and so should be
backward-compatible with existing hosts/clients.
Signed-off-by: Michael Roth mdr...@linux.vnet.ibm.com
---
qapi-schema-guest.json | 67 +++-
qemu-ga.c | 46 ++
qga/guest-agent-commands.c | 13
qga/guest-agent-core.h | 11 +++
4 files changed, 136 insertions(+), 1 deletions(-)
diff --git a/qapi-schema-guest.json b/qapi-schema-guest.json
index 706925d..81cd773 100644
--- a/qapi-schema-guest.json
+++ b/qapi-schema-guest.json
@@ -51,6 +51,27 @@
'data': { 'name': 'str', 'enabled': 'bool' } }
##
+# @GuestAgentSupportLevel
+#
+# Guest agent support/compatability level (as configured by
+# guest agent defaults of guest-set-support-level command)
+#
+# Three numerical fields describe the support level:
+#
+# major.minor.micro
+#
+# @major: As above
+#
+# @minor: As above
+#
+# @micro: As above
+#
+# Since 1.1.0
+##
+{ 'type': 'GuestAgentSupportLevel',
+ 'data': { 'major': 'int', 'minor': 'int', 'micro': 'int' } }
+
+##
# @GuestAgentInfo
#
# Information about guest agent.
@@ -59,11 +80,17 @@
#
# @supported_commands: Information about guest agent commands
#
+# @support_level: Current support/compatability level, as set by
+# guest agent defaults or guest-set-support-level
+# command.
+#
# Since 0.15.0
##
{ 'type': 'GuestAgentInfo',
'data': { 'version': 'str',
-'supported_commands': ['GuestAgentCommandInfo'] } }
+'supported_commands': ['GuestAgentCommandInfo']
+'support_level': 'GuestAgentSupportLevel' } }
+
##
# @guest-info:
#
@@ -77,6 +104,44 @@
'returns': 'GuestAgentInfo' }
##
+# @guest-set-support-level:
+#
+# Set guest agent feature-set to one that is compatible with/supported by
+# the host.
+#
+# Certain commands/options may have dependencies on host
+# version/support-level, such as specific QEMU features (such
+# dependencies will be noted in this schema). By default we assume 1.0.0,
+# which is backward-compatible with QEMU 0.15.0/1.0, and should be compatible
+# with later versions of QEMU as well. To enable newer guest agent features,
+# this command must be issued to raise the support-level to one corresponding
+# to supported host QEMU/KVM/etc capabilities.
+#
+# The host support-level is generally = host QEMU version
+# level. Note that undefined behavior may occur if a support-level is
+# provided that exceeds the capabilities of the version of QEMU currently
+# running the guest. Any level specified below 1.0.0 will default to 1.0.0.
+#
+# The currently set support level is obtainable via the guest-info command.
+#
+# Three numerical fields describe the host support/compatability level:
+#
+# major.minor.micro
+#
+# @major: As above
+#
+# @minor: As above
+#
+# @micro: As above
+#
+# Returns: Nothing on success
+#
+# Since: 1.1.0
+##
+{ 'command': 'guest-set-support-level',
+ 'data':{ 'major': 'int', 'minor': 'int', '*micro': 'int' } }
+
+##
# @guest-shutdown:
#
# Initiate guest-activated shutdown. Note: this is an asynchronous
diff --git a/qemu-ga.c b/qemu-ga.c
index 29e4f64..8e5b075 100644
--- a/qemu-ga.c
+++ b/qemu-ga.c
@@ -28,6 +28,7 @@
#include qerror.h
#include error_int.h
#include qapi/qmp-core.h
+#include qga-qapi-types.h
#define QGA_VIRTIO_PATH_DEFAULT /dev/virtio-ports/org.qemu.guest_agent.0
#define QGA_PIDFILE_DEFAULT /var/run/qemu-ga.pid
@@ -102,6 +103,45 @@ static void usage(const char *cmd)
static void conn_channel_close(GAState *s);
+static GuestAgentSupportLevel ga_support_level;
+
+static int ga_cmp_support_levels(GuestAgentSupportLevel a,
+ GuestAgentSupportLevel b)
+{
+if (a.major == b.major) {
+if (a.minor == b.minor) {
+return a.micro - b.micro;
+}
+return a.minor - b.minor;
+}
+return a.major - b.major;
+}
+
+bool ga_has_support_level(int major, int minor, int
[Qemu-devel] [PATCH 2/6] main-loop: For tools, initialize timers as part of qemu_init_main_loop()
In some cases initializing the alarm timers can lead to non-negligable
overhead from programs that link against qemu-tool.o. At least,
setting a max-resolution WinMM alarm timer via mm_start_timer() (the
current default for Windows) can increase the tick rate on Windows
OSs and affect frequency scaling, and in the case of tools that run
in guest OSs such has qemu-ga, the impact can be fairly dramatic
(+20%/20% user/sys time on a core 2 processor was observed from an idle
Windows XP guest).
This patch doesn't address the issue directly (not sure what a good
solution would be for Windows, or what other situations it might be
noticeable), but it at least limits the scope of the issue to programs
that opt-in to using the main-loop.c functions by only enabling alarm
timers when qemu_init_main_loop() is called, which is already required
to make use of those facilities, so existing users shouldn't be
affected.
Signed-off-by: Michael Roth mdr...@linux.vnet.ibm.com
---
main-loop.c |2 +-
main-loop.h | 12
qemu-tool.c |3 ++-
vl.c|5 +
4 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/main-loop.c b/main-loop.c
index 62d95b9..db23de0 100644
--- a/main-loop.c
+++ b/main-loop.c
@@ -199,7 +199,7 @@ static int qemu_signal_init(void)
}
#endif
-int qemu_init_main_loop(void)
+int main_loop_init(void)
{
int ret;
diff --git a/main-loop.h b/main-loop.h
index f971013..4987041 100644
--- a/main-loop.h
+++ b/main-loop.h
@@ -41,10 +41,22 @@
* SIGUSR2, thread signals (SIGFPE, SIGILL, SIGSEGV, SIGBUS) and real-time
* signals if available. Remember that Windows in practice does not have
* signals, though.
+ *
+ * In the case of QEMU tools, this will also start/initialize timers.
*/
int qemu_init_main_loop(void);
/**
+ * main_loop_init: Initializes main loop
+ *
+ * Internal (but shared for compatibility reasons) initialization routine
+ * for the main loop. This should not be used by applications directly,
+ * use qemu_init_main_loop() instead.
+ *
+ */
+int main_loop_init(void);
+
+/**
* main_loop_wait: Run one iteration of the main loop.
*
* If @nonblocking is true, poll for events, otherwise suspend until
diff --git a/qemu-tool.c b/qemu-tool.c
index 6b69668..183a583 100644
--- a/qemu-tool.c
+++ b/qemu-tool.c
@@ -83,11 +83,12 @@ void qemu_clock_warp(QEMUClock *clock)
{
}
-static void __attribute__((constructor)) init_main_loop(void)
+int qemu_init_main_loop(void)
{
init_clocks();
init_timer_alarm();
qemu_clock_enable(vm_clock, false);
+return main_loop_init();
}
void slirp_select_fill(int *pnfds, fd_set *readfds,
diff --git a/vl.c b/vl.c
index 57378b6..9d14cc8 100644
--- a/vl.c
+++ b/vl.c
@@ -2159,6 +2159,11 @@ static void free_and_trace(gpointer mem)
free(mem);
}
+int qemu_init_main_loop(void)
+{
+return main_loop_init();
+}
+
int main(int argc, char **argv, char **envp)
{
const char *gdbstub_dev = NULL;
--
1.7.4.1
Re: [Qemu-devel] [PATCH v2 3/9] hw/a15mpcore.c: Add Cortex-A15 private peripheral model
Am 24.01.2012 13:39, schrieb Peter Maydell: Add a model of the Cortex-A15 memory mapped private peripheral space. This is fairly simple because the only memory mapped bit of the A15 is the GIC. Note that we don't currently model a VGIC and therefore don't map the VGIC related bits of the GIC. Signed-off-by: Peter Maydell peter.mayd...@linaro.org Reviewed-by: Andreas Färber afaer...@suse.de Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] TCG register allocator
On 25 January 2012 15:55, Xin Tong xerox.time.t...@gmail.com wrote: The segfault is caused by jumping to the middle of an instruction. so i want to know which TB jumps here. (a) Assuming it doesn't take too long to get there, you should be able to get this information by turning on the debug log via -d whatever. If it does take too long to get to the crash, you can use the savevm/loadvm support to save the VM state at some point slightly before the crash. Then you can run with the debug log enabled and '-loadvm tag' to start from the point when you saved the VM state. [disclaimer: depending on the guest machine you're emulating you might be unlucky and need to fix save/load first, but that's a worthwhile thing anyway :-)] (b) Might not be what you're seeing, but there's a class of bug that can look like a jump to the middle of an instruction that happens when: * step 1: we generate code for a TB * a load or store within that TB causes an exception * to get CPUState in sync with the point of the exception (and in particular to translate the host PC at the exception into the guest PC at that point) we call cpu_restore_state() * cpu_restore_state() calls gen_intermediate_code_pc() to request a retranslation of the TB with extra info to allow us to do a host-PC-to-guest-PC lookup * Note that gen_intermediate_code_pc() overwrites the generated code that already exists in memory, and stops as soon as it reaches the point of the exception. This is harmless because we are just rewriting the same bytes to memory that were there already, but disastrous if... * ...due to a bug, gen_intermediate_code_pc() generates different code to that generated back in step 1; this tends to result in writing half an instruction at the point where it stops * subsequent attempts to execute that TB tend to result in weird crashes, often looking like an attempt to jump into the middle of an instruction This is why it's critical that gen_intermediate_code()+TCG always deterministically generates exactly the same native code every time. -- PMM
Re: [Qemu-devel] [PATCH v9 7/9] hw/lan9118: Add basic 16-bit mode support.
On 20 January 2012 10:53, Evgeny Voevodin e.voevo...@samsung.com wrote:
@@ -294,6 +304,14 @@ static const VMStateDescription vmstate_lan9118 = {
VMSTATE_INT32(rxp_offset, lan9118_state),
VMSTATE_INT32(rxp_size, lan9118_state),
VMSTATE_INT32(rxp_pad, lan9118_state),
+ VMSTATE_UINT32(write_word_prev_offset, lan9118_state),
+ VMSTATE_UINT32(write_word_n, lan9118_state),
+ VMSTATE_UINT16(write_word_l, lan9118_state),
+ VMSTATE_UINT16(write_word_h, lan9118_state),
+ VMSTATE_UINT32(read_word_prev_offset, lan9118_state),
+ VMSTATE_UINT32(read_word_n, lan9118_state),
+ VMSTATE_UINT32(read_long, lan9118_state),
+ VMSTATE_UINT32(mode_16bit, lan9118_state),
VMSTATE_END_OF_LIST()
You need to bump .version_id and make your new fields
VMSTATE_UINT32(write_word_prev_offset, lan9118_state, 2),
etc.
-- PMM
Re: [Qemu-devel] [PATCH v2 4/9] hw/vexpress.c: Make motherboard peripheral memory map table-driven
Am 24.01.2012 13:39, schrieb Peter Maydell: Pull the addresses used for mapping motherboard peripherals into memory out into a table. This will allow us to simply provide a second table to implement the Cortex-A Series memory map used by the A15 variant of Versatile Express, as well as the current Legacy map used by A9. Signed-off-by: Peter Maydell peter.mayd...@linaro.org Reviewed-by: Andreas Färber afaer...@suse.de Nice! (Liked-by :)) Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [PATCH v2 11/33] scsi-disk: support DVD profile in GET CONFIGURATION
On 01/25/2012 05:34 PM, Artyom Tarasenko wrote: This patch produces the following error when booting Solaris/SPARC: WARNING: /iommu@0,1000/sbus@0,10001000/espdma@5,840/esp@5,880 (esp0): data transfer overrun: current esp state: esp:State=DATA Last State=DATA_DONE esp:Latched stat=0x91IPND,XZERO,IO intr=0x10BUS fifo 0x0 esp:last msg out: IDENTIFY; last msg in: COMMAND COMPLETE esp:DMA csr=0xa4240030FLSH,INTEN esp:addr=fc005860 dmacnt=0 last=fc005858 last_cnt=8 esp:Cmd dump for Target 6 Lun 0: esp:cdblen=10, cdb=[ 0x46 0x2 0x0 0x0 0x0 0x0 0x0 0x0 0x8 0x0 ] esp:pkt_state=0xfXFER,CMD,SEL,ARB pkt_flags=0x1 pkt_statistics=0x0 esp:cmd_flags=0x462 cmd_timeout=60 Particularly it seems that Solaris is not happy with respose length 8. Any idea, why? $ sparc-softmmu/qemu-system-sparc -bios ~/ss5-170.bin -m 32 -nographic -drive if=scsi,unit=6,media=cdrom,file=~/Solaris9cd1.iso From a quick look, it's the same bug that was reported recently on INQUIRY commands. Paolo
Re: [Qemu-devel] [PATCH v9 7/9] hw/lan9118: Add basic 16-bit mode support.
Am 25.01.2012 17:35, schrieb Peter Maydell:
On 20 January 2012 10:53, Evgeny Voevodin e.voevo...@samsung.com wrote:
@@ -294,6 +304,14 @@ static const VMStateDescription vmstate_lan9118 = {
VMSTATE_INT32(rxp_offset, lan9118_state),
VMSTATE_INT32(rxp_size, lan9118_state),
VMSTATE_INT32(rxp_pad, lan9118_state),
+VMSTATE_UINT32(write_word_prev_offset, lan9118_state),
+VMSTATE_UINT32(write_word_n, lan9118_state),
+VMSTATE_UINT16(write_word_l, lan9118_state),
+VMSTATE_UINT16(write_word_h, lan9118_state),
+VMSTATE_UINT32(read_word_prev_offset, lan9118_state),
+VMSTATE_UINT32(read_word_n, lan9118_state),
+VMSTATE_UINT32(read_long, lan9118_state),
+VMSTATE_UINT32(mode_16bit, lan9118_state),
VMSTATE_END_OF_LIST()
You need to bump .version_id and make your new fields
VMSTATE_UINT32(write_word_prev_offset, lan9118_state, 2),
VMSTATE_UINT32_V(write_word_prev_offset, lan9118_state, 2),
etc.
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
[Qemu-devel] [PATCH uq/master] kvm: Allow to set shadow MMU size
Introduce the KVM-specific machine option kvm_shadow_mem. It allows to
set a custom shadow MMU size for the virtual machine. This is useful for
stress testing e.g.
Only x86 supports this for now, but it is in principle a generic
concept for all targets with shadow MMUs.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
qemu-config.c |4
qemu-options.hx |5 -
target-i386/kvm.c | 13 +
3 files changed, 21 insertions(+), 1 deletions(-)
diff --git a/qemu-config.c b/qemu-config.c
index b030205..95bf5e5 100644
--- a/qemu-config.c
+++ b/qemu-config.c
@@ -535,6 +535,10 @@ static QemuOptsList qemu_machine_opts = {
.name = kernel_irqchip,
.type = QEMU_OPT_BOOL,
.help = use KVM in-kernel irqchip,
+}, {
+.name = kvm_shadow_mem,
+.type = QEMU_OPT_SIZE,
+.help = KVM shadow MMU size,
},
{ /* End of list */ }
},
diff --git a/qemu-options.hx b/qemu-options.hx
index 3a07ae8..067a319 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -32,7 +32,8 @@ DEF(machine, HAS_ARG, QEMU_OPTION_machine, \
selects emulated machine (-machine ? for list)\n
property accel=accel1[:accel2[:...]] selects
accelerator\n
supported accelerators are kvm, xen, tcg (default: tcg)\n
-kernel_irqchip=on|off controls accelerated irqchip
support\n,
+kernel_irqchip=on|off controls accelerated irqchip
support\n
+kvm_shadow_mem=size of KVM shadow MMU\n,
QEMU_ARCH_ALL)
STEXI
@item -machine [type=]@var{name}[,prop=@var{value}[,...]]
@@ -47,6 +48,8 @@ than one accelerator specified, the next one is used if the
previous one fails
to initialize.
@item kernel_irqchip=on|off
Enables in-kernel irqchip support for the chosen accelerator when available.
+@item kvm_shadow_mem=size
+Defines the size of the KVM shadow MMU.
@end table
ETEXI
diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index e41de39..445c060 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -646,7 +646,9 @@ static int kvm_get_supported_msrs(KVMState *s)
int kvm_arch_init(KVMState *s)
{
+QemuOptsList *list = qemu_find_opts(machine);
uint64_t identity_base = 0xfffbc000;
+uint64_t shadow_mem;
int ret;
struct utsname utsname;
@@ -693,6 +695,17 @@ int kvm_arch_init(KVMState *s)
}
qemu_register_reset(kvm_unpoison_all, NULL);
+if (!QTAILQ_EMPTY(list-head)) {
+shadow_mem = qemu_opt_get_size(QTAILQ_FIRST(list-head),
+ kvm_shadow_mem, -1);
+if (shadow_mem != -1) {
+shadow_mem /= 4096;
+ret = kvm_vm_ioctl(s, KVM_SET_NR_MMU_PAGES, shadow_mem);
+if (ret 0) {
+return ret;
+}
+}
+}
return 0;
}
--
1.7.3.4
Re: [Qemu-devel] [PATCH v9 7/9] hw/lan9118: Add basic 16-bit mode support.
On 25 January 2012 17:04, Andreas Färber afaer...@suse.de wrote: Am 25.01.2012 17:35, schrieb Peter Maydell: You need to bump .version_id and make your new fields VMSTATE_UINT32(write_word_prev_offset, lan9118_state, 2), VMSTATE_UINT32_V(write_word_prev_offset, lan9118_state, 2), Doh, yes. -- PMM
[Qemu-devel] [PATCH 10/10] PPC: booke206: move avail check to tlbwe
We can have TLBs that only support a single page size. This is defined
by the absence of the AVAIL flag in TLBnCFG. If this is the case, we
currently write invalid size info into the TLB, but override it on
internal fault.
Let's move the check over to tlbwe, so we don't have the AVAIL check in
the hotter fault path.
Signed-off-by: Alexander Graf ag...@suse.de
---
target-ppc/helper.c|8 +---
target-ppc/op_helper.c |9 +
2 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/target-ppc/helper.c b/target-ppc/helper.c
index 672494c..31a9897 100644
--- a/target-ppc/helper.c
+++ b/target-ppc/helper.c
@@ -1298,13 +1298,7 @@ target_phys_addr_t booke206_tlb_to_page_size(CPUState
*env, ppcmas_tlb_t *tlb)
int tlbm_size;
tlbncfg = env-spr[SPR_BOOKE_TLB0CFG + tlbn];
-
-if (tlbncfg TLBnCFG_AVAIL) {
-tlbm_size = (tlb-mas1 MAS1_TSIZE_MASK) MAS1_TSIZE_SHIFT;
-} else {
-tlbm_size = (tlbncfg TLBnCFG_MINSIZE) TLBnCFG_MINSIZE_SHIFT;
-tlbm_size = 1;
-}
+tlbm_size = (tlb-mas1 MAS1_TSIZE_MASK) MAS1_TSIZE_SHIFT;
return 1024ULL tlbm_size;
}
diff --git a/target-ppc/op_helper.c b/target-ppc/op_helper.c
index be4e539..0d1206a 100644
--- a/target-ppc/op_helper.c
+++ b/target-ppc/op_helper.c
@@ -4282,6 +4282,15 @@ void helper_booke206_tlbwe(void)
tlb-mas7_3 = ((uint64_t)env-spr[SPR_BOOKE_MAS7] 32) |
env-spr[SPR_BOOKE_MAS3];
tlb-mas1 = env-spr[SPR_BOOKE_MAS1];
+
+/* MAV 1.0 only */
+if (!(tlbncfg TLBnCFG_AVAIL)) {
+/* force !AVAIL TLB entries to correct page size */
+tlb-mas1 = ~MAS1_TSIZE_MASK;
+/* XXX can be configured in MMUCSR0 */
+tlb-mas1 |= (tlbncfg TLBnCFG_MINSIZE) 12;
+}
+
/* XXX needs to change when supporting 64-bit e500 */
tlb-mas2 = env-spr[SPR_BOOKE_MAS2] 0x;
--
1.6.0.2
[Qemu-devel] [PATCH 08/10] PPC: booke206: Implement tlbilx
The PowerPC 2.06 BookE ISA defines an opcode called tlbilx which is used
to flush TLB entries. It's the recommended way of flushing in virtualized
environments.
So far we got away without implementing it, but Linux for e500mc uses this
instruction, so we better add it :).
Signed-off-by: Alexander Graf ag...@suse.de
---
v1 - v2:
- remove sas/ts check
- isize is only valid for mav 2.0
v2 - v3:
- move tlbilx variants into their own helpers
---
target-ppc/helper.h|3 ++
target-ppc/op_helper.c | 64
target-ppc/translate.c | 35 ++
3 files changed, 102 insertions(+), 0 deletions(-)
diff --git a/target-ppc/helper.h b/target-ppc/helper.h
index 470e42f..4798fd5 100644
--- a/target-ppc/helper.h
+++ b/target-ppc/helper.h
@@ -336,6 +336,9 @@ DEF_HELPER_0(booke206_tlbre, void)
DEF_HELPER_0(booke206_tlbwe, void)
DEF_HELPER_1(booke206_tlbsx, void, tl)
DEF_HELPER_1(booke206_tlbivax, void, tl)
+DEF_HELPER_1(booke206_tlbilx0, void, tl)
+DEF_HELPER_1(booke206_tlbilx1, void, tl)
+DEF_HELPER_1(booke206_tlbilx3, void, tl)
DEF_HELPER_1(booke206_tlbflush, void, i32)
DEF_HELPER_2(booke_setpid, void, i32, tl)
DEF_HELPER_1(6xx_tlbd, void, tl)
diff --git a/target-ppc/op_helper.c b/target-ppc/op_helper.c
index 3b197f2..1f1fa09 100644
--- a/target-ppc/op_helper.c
+++ b/target-ppc/op_helper.c
@@ -4406,6 +4406,70 @@ void helper_booke206_tlbivax(target_ulong address)
}
}
+void helper_booke206_tlbilx0(target_ulong address)
+{
+/* XXX missing LPID handling */
+booke206_flush_tlb(env, -1, 1);
+}
+
+void helper_booke206_tlbilx1(target_ulong address)
+{
+int i, j;
+int tid = (env-spr[SPR_BOOKE_MAS6] MAS6_SPID);
+ppcmas_tlb_t *tlb = env-tlb.tlbm;
+int tlb_size;
+
+/* XXX missing LPID handling */
+for (i = 0; i BOOKE206_MAX_TLBN; i++) {
+tlb_size = booke206_tlb_size(env, i);
+for (j = 0; j tlb_size; j++) {
+if (!(tlb[j].mas1 MAS1_IPROT)
+((tlb[j].mas1 MAS1_TID_MASK) == tid)) {
+tlb[j].mas1 = ~MAS1_VALID;
+}
+}
+tlb += booke206_tlb_size(env, i);
+}
+tlb_flush(env, 1);
+}
+
+void helper_booke206_tlbilx3(target_ulong address)
+{
+int i, j;
+ppcmas_tlb_t *tlb;
+int tid = (env-spr[SPR_BOOKE_MAS6] MAS6_SPID);
+int pid = tid MAS6_SPID_SHIFT;
+int sgs = env-spr[SPR_BOOKE_MAS5] MAS5_SGS;
+int ind = (env-spr[SPR_BOOKE_MAS6] MAS6_SIND) ? MAS1_IND : 0;
+/* XXX check for unsupported isize and raise an invalid opcode then */
+int size = env-spr[SPR_BOOKE_MAS6] MAS6_ISIZE_MASK;
+/* XXX implement MAV2 handling */
+bool mav2 = false;
+
+/* XXX missing LPID handling */
+/* flush by pid and ea */
+for (i = 0; i BOOKE206_MAX_TLBN; i++) {
+int ways = booke206_tlb_ways(env, i);
+
+for (j = 0; j ways; j++) {
+tlb = booke206_get_tlbm(env, i, address, j);
+if ((ppcmas_tlb_check(env, tlb, NULL, address, pid) != 0) ||
+(tlb-mas1 MAS1_IPROT) ||
+((tlb-mas1 MAS1_IND) != ind) ||
+((tlb-mas8 MAS8_TGS) != sgs)) {
+continue;
+}
+if (mav2 ((tlb-mas1 MAS1_TSIZE_MASK) != size)) {
+/* XXX only check when MMUCFG[TWC] || TLBnCFG[HES] */
+continue;
+}
+/* XXX e500mc doesn't match SAS, but other cores might */
+tlb-mas1 = ~MAS1_VALID;
+}
+}
+tlb_flush(env, 1);
+}
+
void helper_booke206_tlbflush(uint32_t type)
{
int flags = 0;
diff --git a/target-ppc/translate.c b/target-ppc/translate.c
index adde65b..d8ef719 100644
--- a/target-ppc/translate.c
+++ b/target-ppc/translate.c
@@ -6110,6 +6110,39 @@ static void gen_tlbivax_booke206(DisasContext *ctx)
#endif
}
+static void gen_tlbilx_booke206(DisasContext *ctx)
+{
+#if defined(CONFIG_USER_ONLY)
+gen_inval_exception(ctx, POWERPC_EXCP_PRIV_OPC);
+#else
+TCGv t0;
+if (unlikely(!ctx-mem_idx)) {
+gen_inval_exception(ctx, POWERPC_EXCP_PRIV_OPC);
+return;
+}
+
+t0 = tcg_temp_new();
+gen_addr_reg_index(ctx, t0);
+
+switch((ctx-opcode 21) 0x3) {
+case 0:
+gen_helper_booke206_tlbilx0(t0);
+break;
+case 1:
+gen_helper_booke206_tlbilx1(t0);
+break;
+case 3:
+gen_helper_booke206_tlbilx3(t0);
+break;
+default:
+gen_inval_exception(ctx, POWERPC_EXCP_INVAL_INVAL);
+break;
+}
+
+tcg_temp_free(t0);
+#endif
+}
+
/* wrtee */
static void gen_wrtee(DisasContext *ctx)
@@ -8574,6 +8607,8 @@ GEN_HANDLER2_E(tlbwe_booke206, tlbwe, 0x1F, 0x12, 0x1E,
0x0001,
PPC_NONE, PPC2_BOOKE206),
GEN_HANDLER2_E(tlbivax_booke206, tlbivax, 0x1F, 0x12, 0x18, 0x0001,
PPC_NONE, PPC2_BOOKE206),
+GEN_HANDLER2_E(tlbilx_booke206, tlbilx, 0x1F, 0x12, 0x00, 0x0381,
+
