[Qemu-devel] [RFC PATCH] qapi: Allow setting default values for optional parameters
In command definition, 'default' is now parsed as a dict of default
values. Only optional parameters will have effect in generated code.
'str' and 'int' are supported, both need single quote in the schema. In
generated code, 'str' will be converted to g_strdup'ed pointer, 'int'
will be identically set.
E.g.
{ 'command': 'block-commit',
'data': { 'device': 'str', '*base': 'str', 'top': 'str',
'*speed': 'int' },
'default': {'base': 'earthquake', 'speed': '100' } }
will generate
int qmp_marshal_input_block_commit(Monitor *mon, const QDict *qdict,
QObject **ret)
{
...
bool has_base = true;
char * base = g_strdup(earthquake);
...
bool has_speed = true;
int64_t speed = 100;
Signed-off-by: Fam Zheng f...@redhat.com
---
scripts/qapi-commands.py | 24 +---
scripts/qapi.py | 8
2 files changed, 25 insertions(+), 7 deletions(-)
diff --git a/scripts/qapi-commands.py b/scripts/qapi-commands.py
index 9734ab0..be6eea4 100644
--- a/scripts/qapi-commands.py
+++ b/scripts/qapi-commands.py
@@ -83,16 +83,23 @@ Visitor *v;
return ret.rstrip()
-def gen_visitor_input_vars_decl(args):
+def gen_visitor_input_vars_decl(args, default):
ret =
push_indent()
for argname, argtype, optional, structured in parse_args(args):
if optional:
ret += mcgen('''
-bool has_%(argname)s = false;
+bool has_%(argname)s = %(has_val)s;
''',
- argname=c_var(argname))
-if c_type(argtype).endswith(*):
+ argname=c_var(argname),
+ has_val=true if default.get(argname) else false)
+if optional and default.get(argname):
+ret += mcgen('''
+%(argtype)s %(argname)s = %(argval)s;
+''',
+ argname=c_var(argname), argtype=c_type(argtype),
+ argval=c_val(argtype, default[argname]))
+elif c_type(argtype).endswith(*):
ret += mcgen('''
%(argtype)s %(argname)s = NULL;
''',
@@ -194,7 +201,7 @@ def gen_marshal_input_decl(name, args, ret_type,
middle_mode):
-def gen_marshal_input(name, args, ret_type, middle_mode):
+def gen_marshal_input(name, args, ret_type, middle_mode, default):
hdr = gen_marshal_input_decl(name, args, ret_type, middle_mode)
ret = mcgen('''
@@ -229,7 +236,7 @@ def gen_marshal_input(name, args, ret_type, middle_mode):
''',
visitor_input_containers_decl=gen_visitor_input_containers_decl(args),
- visitor_input_vars_decl=gen_visitor_input_vars_decl(args),
+ visitor_input_vars_decl=gen_visitor_input_vars_decl(args,
default),
visitor_input_block=gen_visitor_input_block(args,
QOBJECT(args)))
else:
ret += mcgen('''
@@ -434,9 +441,12 @@ if dispatch_type == sync:
for cmd in commands:
arglist = []
+default = {}
ret_type = None
if cmd.has_key('data'):
arglist = cmd['data']
+if cmd.has_key('default'):
+default = cmd['default']
if cmd.has_key('returns'):
ret_type = cmd['returns']
ret = generate_command_decl(cmd['command'], arglist, ret_type) + \n
@@ -448,7 +458,7 @@ if dispatch_type == sync:
if middle_mode:
fdecl.write('%s;\n' % gen_marshal_input_decl(cmd['command'],
arglist, ret_type, middle_mode))
-ret = gen_marshal_input(cmd['command'], arglist, ret_type,
middle_mode) + \n
+ret = gen_marshal_input(cmd['command'], arglist, ret_type,
middle_mode, default) + \n
fdef.write(ret)
fdecl.write(\n#endif\n);
diff --git a/scripts/qapi.py b/scripts/qapi.py
index b474c39..f12866a 100644
--- a/scripts/qapi.py
+++ b/scripts/qapi.py
@@ -421,6 +421,14 @@ def find_enum(name):
def is_enum(name):
return find_enum(name) != None
+def c_val(t, val):
+if t == 'str':
+return 'g_strdup(%s)' % val
+elif t == 'int':
+return val
+else:
+assert False, Unknown type: %s % t
+
def c_type(name):
if name == 'str':
return 'char *'
--
1.9.2
Re: [Qemu-devel] KVM call agenda for 2014-04-15
Alexander Graf ag...@suse.de writes: Am 15.04.2014 um 18:56 schrieb Markus Armbruster arm...@redhat.com: Alexander Graf ag...@suse.de writes: On 04/15/2014 04:00 PM, Markus Armbruster wrote: Juan Quintela quint...@redhat.com writes: Juan Quintela quint...@redhat.com wrote: Hi Please, send any topic that you are interested in covering. Thanks, Juan. As there are no topics, no call. Did we have a call anyway? IRC log looks like we did... Yes, we did. Whoever attended, please reply with things I mixed up or forgot. Two topics: [...] 2) -device for non-PCI devices Interesting stuff, hate to have missed it. Can we please ensure more useful advance notice than monitor the IRC channel around call time? Decide call / no call the night before would work nicely for me. I sent an email to the list earlier this werk as reply to the last call, because there was no mail for this week's agenda yet. That's probably why Juan didn't pick it up. Explanation, not criticizing either of you. If we post the call's agenda the night before, there's time to correct omissions. I'm fine with late agenda changes. I really don't like last minute call / no call decisions.
Re: [Qemu-devel] [PATCH v2 1/2] usb-hid: Add high speed mouse configuration
On Di, 2014-04-15 at 19:33 -0400, Ján Veselý wrote: Hi, I found some more time to work on this. However, I'm not sure I understand the purpose of compat property: I noticed that the only place it's set is in PC_COMPAT_1_3 (is this what you meant by older devices?), Older machine types, yes. This switches the tablet to usb1 by default if you start qemu with -M pc-1.3 (or older), because it was usb1 only in qemu 1.3 older. I guess same setting for FS mouse and kbd should be added there as well. They need to go to the (probably not added yet) PC_COMPAT_2_0. The switch statement in usb_tablet_initfn selects between two descriptor structures, however, these structures are almost identical with the sole exception of .high field being set in the HS version (desc_tablet2). So changing the switch statement to: if (us-usb_version 2) dev-usb_desc-high = NULL; should be OK for all usb hid devices, right? No. That struct is shared between all device instances, so if you muck with it all devices are affected, i.e. this ... qemu -device usb-tablet,usb_ver=1 -device usb_tablet,usb_ver=2 will not work correctly. cheers, Gerd
Re: [Qemu-devel] [QEMU v6 PATCH 00/17] SMBIOS: build full tables in QEMU
Kevin O'Connor ke...@koconnor.net writes: On Tue, Apr 15, 2014 at 10:29:26AM +0200, Gerd Hoffmann wrote: Leave the old interface code basically as-is. type0 and type1 individual fields are passed like they are passed today. We don't change to to pass full tables, and we don't extend that to new table types. Continue to provide these in parallel to the new interface, for compatibility with old firmware (and old machine types). The code to generate complete tables will only be used for etc/smbios/smbios-tables. Only machine types for 2.1 + newer will provide them, so with older machine types seabios will continue to generate the smbios tables and guest wouldn't notice a difference. This does mean that SeaBIOS would need to continue to support generating of smbios tables for the foreseeable future as it would need that support whenever one wanted to run a v2.0 or earlier machine type. It would be nice if a future version of SeaBIOS could drop the smbios generation code. However, I'm okay with either direction. If we want to retire the SMBIOS tables generation from SeaBIOS entirely, we first need to stop use of the old interface in QEMU, then let enough time pass to avoid awkward upgrade dependencies. Gerd's proposal is compatible with that.
Re: [Qemu-devel] [QEMU v6 PATCH 00/17] SMBIOS: build full tables in QEMU
Hi,
Add void smbios_get_tables() as a separate function to generate the
entry point and aggregate smbios table, and then:
if machine_type 2.1 then
insert smbios_get_table() into fw_cfg (compat mode)
else
insert smbios_get_tables() blob + entry point (new hotness)
fi
I mean this:
insert smbios_get_table() into fw_cfg (compat mode)
if (machine_type = 2.1)
insert smbios_get_tables() blob + entry point (new hotness)
But maybe your variant is better as it encourages the move to the new
interfaces on the firmware side. And if we merge it early in the 2.1
cycle there is quite some time for the firmware to sort things.
I guess both compat and new smbios_get_table[s] can use the same
default fields set via the command line.
Yes.
The remaining issue is how to handle -smbios file=foo blobs; maybe
smbios_set_defaults() can be used to set the version, and then the
command line parser (smbios_entry_add()) would know which kind of table
to insert the blob into, compat or aggregate ?
That being said, how do I even tell the difference between pre- and
post- 2.1 machine types ? Would that be in pc.c, or pc_[q35|piix].c ?
Global variable, simliar to smbios_type1_defaults. machine type init
code will set it accordingly. smbios code just does if
(smbios_generate_tables) { ... } (or however we name this).
cheers,
Gerd
Re: [Qemu-devel] [PATCH v1 1/3] qdev: Expose the qdev id string as a prop
Peter Crosthwaite peter.crosthwa...@xilinx.com writes: On Wed, Apr 16, 2014 at 2:16 AM, Andreas Färber afaer...@suse.de wrote: Am 15.04.2014 04:21, schrieb Peter Crosthwaite: So clients can set the top level id string. Signed-off-by: Peter Crosthwaite peter.crosthwa...@xilinx.com Anthony had nack'ed Paolo's attempt to generalize the qdev id to QOM, so I'm not sure if we should really do this even if just on device level. The id= is used to construct the canonical path, and we can't change that through a qdev setter. Let me try to paraphrase to make sure I got you: The canonical QOM path is fixed at creation time. Setting an ID dynamically would destroy the relationship between ID and canonical QOM path. Correct? How can we change it? The problem I am trying to solve, is getting meaningful device instance names instead of the anonymous defaults. This includes in the canonical path. I am completely open to proposals :) The qdev ID is for users. Corollary: there is none unless the user sets one. The qdev ID is fixed at creation time, and never changes. If it could change, we'd need machinery to notify clients such as libvirt, and we'd still suffer race conditions in multiple monitor situations. The need for a way to uniquely identify device instances by some name is real. But qdev IDs as presently designed are not a solution. What about the canonical QOM path? [...]
Re: [Qemu-devel] [PATCH] qmp: object-add: Validate class before creating object
Eduardo Habkost ehabk...@redhat.com writes:
Currently it is very easy to crash QEMU by issuing an object-add command
using an abstract class or a class that doesn't support
TYPE_USER_CREATABLE as parameter.
Example: with the following QMP command:
(QEMU) object-add qom-type=cpu id=foo
QEMU aborts at:
ERROR:qom/object.c:335:object_initialize_with_type: assertion failed:
(type-abstract == false)
This patch moves the check for TYPE_USER_CREATABLE before object_new(),
and adds a check to prevent the code from trying to instantiate abstract
classes.
Signed-off-by: Eduardo Habkost ehabk...@redhat.com
Related device_add fixes:
061e84f qdev-monitor: Avoid device_add crashing on non-device driver name
2fa4e56 qdev-monitor: Fix crash when device_add is called with abstract driver
7ea5e78 qdev: Do not let the user try to device_add when it cannot work
---
qmp.c | 21 ++---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/qmp.c b/qmp.c
index 87a28f7..e7ecbb7 100644
--- a/qmp.c
+++ b/qmp.c
@@ -540,14 +540,27 @@ void object_add(const char *type, const char *id, const
QDict *qdict,
Visitor *v, Error **errp)
{
Object *obj;
+ObjectClass *klass;
const QDictEntry *e;
Error *local_err = NULL;
-if (!object_class_by_name(type)) {
+klass = object_class_by_name(type);
+if (!klass) {
error_setg(errp, invalid class name);
return;
}
+if (object_class_is_abstract(klass)) {
+error_setg(errp, object type '%s' is abstract, type);
+return;
+}
+
+if (!object_class_dynamic_cast(klass, TYPE_USER_CREATABLE)) {
+error_setg(errp, object type '%s' isn't supported by object-add,
+ type);
+return;
+}
+
obj = object_new(type);
if (qdict) {
for (e = qdict_first(qdict); e; e = qdict_next(qdict, e)) {
For comparison, this is qdev_device_add():
oc = object_class_by_name(driver);
if (!oc) {
const char *typename = find_typename_by_alias(driver);
if (typename) {
driver = typename;
oc = object_class_by_name(driver);
}
}
if (!object_class_dynamic_cast(oc, TYPE_DEVICE)) {
qerror_report(ERROR_CLASS_GENERIC_ERROR,
'%s' is not a valid device model name, driver);
return NULL;
}
if (object_class_is_abstract(oc)) {
qerror_report(QERR_INVALID_PARAMETER_VALUE, driver,
non-abstract device type);
return NULL;
}
dc = DEVICE_CLASS(oc);
if (dc-cannot_instantiate_with_device_add_yet) {
qerror_report(QERR_INVALID_PARAMETER_VALUE, driver,
pluggable device type);
return NULL;
}
Got the subtype of and the not abstract check in the opposite order,
and the additional cannot_instantiate_with_device_add_yet check.
Does the different order matter?
@@ -558,12 +571,6 @@ void object_add(const char *type, const char *id, const
QDict *qdict,
}
}
-if (!object_dynamic_cast(obj, TYPE_USER_CREATABLE)) {
-error_setg(local_err, object type '%s' isn't supported by
object-add,
- type);
-goto out;
-}
-
user_creatable_complete(obj, local_err);
if (local_err) {
goto out;
Re: [Qemu-devel] [PATCH] qdev: fix crash by validating the object type
Amos Kong ak...@redhat.com writes:
QEMU crashed when I try to list device parameters, the driver name is
actually the available bus name.
# qemu -device virtio-pci-bus,?
# qemu -device virtio-bus,?
# qemu -device virtio-serial-bus,?
qdev-monitor.c:212:qdev_device_help: Object 0x7fd932f50620 is not an
instance of type device
Aborted (core dumped)
We can also reproduce this bug by adding device from monitor, so it's
worth to fix the crash.
(qemu) device_add virtio-serial-bus
qdev-monitor.c:491:qdev_device_add: Object 0x7f5e89530920 is not an
instance of type device
Aborted (core dumped)
Cc: qemu-sta...@nongnu.org
Signed-off-by: Amos Kong ak...@redhat.com
---
qdev-monitor.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/qdev-monitor.c b/qdev-monitor.c
index 9268c87..40c117d 100644
--- a/qdev-monitor.c
+++ b/qdev-monitor.c
@@ -206,7 +206,7 @@ int qdev_device_help(QemuOpts *opts)
if (!driver || !qemu_opt_has_help_opt(opts)) {
return 0;
}
klass = object_class_by_name(driver);
if (!klass) {
const char *typename = find_typename_by_alias(driver);
if (typename) {
driver = typename;
klass = object_class_by_name(driver);
}
}
-if (!klass) {
+if (!object_class_dynamic_cast(klass, TYPE_DEVICE)) {
return 0;
}
do {
Works because when qdev_device_help() returns zero, its caller
do_device_add() proceeds to call qdev_device_add(), which checks klass
subtype of TYPE_DEVICE again, and reports properly when it's not:
-device virtio-bus,help: 'virtio-bus' is not a valid device model
name.
Reviewed-by: Markus Armbruster arm...@redhat.com
Re: [Qemu-devel] [PATCH] scsi-disk: Improve error messager if can't get version number
Fam Zheng f...@redhat.com writes:
More often it is that bdrv_ioctl fails due to not supported by driver or
whatever reason, in this case we should be specific, because interface
too old is very confusing.
Signed-off-by: Fam Zheng f...@redhat.com
---
hw/scsi/scsi-disk.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/hw/scsi/scsi-disk.c b/hw/scsi/scsi-disk.c
index 48a28ae..d2e532e 100644
--- a/hw/scsi/scsi-disk.c
+++ b/hw/scsi/scsi-disk.c
@@ -2463,8 +2463,13 @@ static int scsi_block_initfn(SCSIDevice *dev)
}
/* check we are using a driver managing SG_IO (version 3 and after) */
-if (bdrv_ioctl(s-qdev.conf.bs, SG_GET_VERSION_NUM, sg_version) 0 ||
-sg_version 3) {
+rc = bdrv_ioctl(s-qdev.conf.bs, SG_GET_VERSION_NUM, sg_version);
+if (rc 0) {
+error_report(scsi-block: can not get version number: %s,
+ strerror(-rc));
+return -1;
+}
+if (sg_version 3) {
error_report(scsi-block: scsi generic interface too old);
return -1;
}
Reviewed-by: Markus Armbruster arm...@redhat.com
Re: [Qemu-devel] [PATCH trivial v2 0/2] vl: simplify code for main()
Chen Gang gang.chen.5...@gmail.com writes: In vl.c, at least, we can simplify the code below, so can let readers read professional C code (especially for new readers, which often start reading code at main function). - Remove useless 'continue' in main(). - Eliminate a superfluous local variable in main(). Signed-off-by: Chen Gang gang.chen.5...@gmail.com Reviewed-by: Markus Armbruster arm...@redhat.com
[Qemu-devel] [PATCH 3/7] megasas: add MegaRAID SAS 2108 emulation
The 2108 chip supports MSI and MSI-X, so update the emulation
to support both chips.
Signed-off-by: Hannes Reinecke h...@suse.de
---
hw/scsi/megasas.c| 95 ++--
hw/scsi/mfi.h| 7
include/hw/pci/pci_ids.h | 1 +
3 files changed, 91 insertions(+), 12 deletions(-)
diff --git a/hw/scsi/megasas.c b/hw/scsi/megasas.c
index ae3e9d6..687115e 100644
--- a/hw/scsi/megasas.c
+++ b/hw/scsi/megasas.c
@@ -30,7 +30,7 @@
#include mfi.h
-#define MEGASAS_VERSION 1.71
+#define MEGASAS_VERSION 1.80
#define MEGASAS_MAX_FRAMES 2048 /* Firmware limit at 65535 */
#define MEGASAS_DEFAULT_FRAMES 1000 /* Windows requires this */
#define MEGASAS_MAX_SGE 128 /* Firmware limit */
@@ -90,6 +90,8 @@ typedef struct MegasasState {
int intr_mask;
int doorbell;
int busy;
+int diag;
+int adp_reset;
MegasasCmd *event_cmd;
int event_locale;
@@ -115,12 +117,18 @@ typedef struct MegasasState {
} MegasasState;
#define TYPE_MEGASAS megasas
+#define TYPE_MEGASAS_GEN2 megasas-gen2
#define MEGASAS(obj) \
OBJECT_CHECK(MegasasState, (obj), TYPE_MEGASAS)
#define MEGASAS_INTR_DISABLED_MASK 0x
+static bool megasas_is_gen2(PCIDeviceClass *dc)
+{
+return dc-device_id == PCI_DEVICE_ID_LSI_SAS0079;
+}
+
static bool megasas_intr_enabled(MegasasState *s)
{
if ((s-intr_mask MEGASAS_INTR_DISABLED_MASK) !=
@@ -681,6 +689,7 @@ static void megasas_finish_dcmd(MegasasCmd *cmd, uint32_t
iov_size)
static int megasas_ctrl_get_info(MegasasState *s, MegasasCmd *cmd)
{
PCIDevice *pci_dev = PCI_DEVICE(s);
+PCIDeviceClass *pci_class = PCI_DEVICE_GET_CLASS(pci_dev);
struct mfi_ctrl_info info;
size_t dcmd_size = sizeof(info);
BusChild *kid;
@@ -694,10 +703,10 @@ static int megasas_ctrl_get_info(MegasasState *s,
MegasasCmd *cmd)
return MFI_STAT_INVALID_PARAMETER;
}
-info.pci.vendor = cpu_to_le16(PCI_VENDOR_ID_LSI_LOGIC);
-info.pci.device = cpu_to_le16(PCI_DEVICE_ID_LSI_SAS1078);
-info.pci.subvendor = cpu_to_le16(PCI_VENDOR_ID_LSI_LOGIC);
-info.pci.subdevice = cpu_to_le16(0x1013);
+info.pci.vendor = cpu_to_le16(pci_class-vendor_id);
+info.pci.device = cpu_to_le16(pci_class-device_id);
+info.pci.subvendor = cpu_to_le16(pci_class-subsystem_vendor_id);
+info.pci.subdevice = cpu_to_le16(pci_class-subsystem_id);
/*
* For some reason the firmware supports
@@ -723,7 +732,11 @@ static int megasas_ctrl_get_info(MegasasState *s,
MegasasCmd *cmd)
num_ld_disks++;
}
-memcpy(info.product_name, MegaRAID SAS 8708EM2, 20);
+if (megasas_is_gen2(pci_class)) {
+memcpy(info.product_name, LSI MegaRAID SAS 9260-8i, 24);
+} else {
+memcpy(info.product_name, LSI MegaRAID SAS 8708EM2, 24);
+}
snprintf(info.serial_number, 32, %s, s-hba_serial);
snprintf(info.package_version, 0x60, %s-QEMU, QEMU_VERSION);
memcpy(info.image_component[0].name, APP, 3);
@@ -1890,6 +1903,8 @@ static uint64_t megasas_mmio_read(void *opaque, hwaddr
addr,
unsigned size)
{
MegasasState *s = opaque;
+PCIDevice *pci_dev = PCI_DEVICE(s);
+PCIDeviceClass *pci_class = PCI_DEVICE_GET_CLASS(pci_dev);
uint32_t retval = 0;
switch (addr) {
@@ -1905,7 +1920,11 @@ static uint64_t megasas_mmio_read(void *opaque, hwaddr
addr,
break;
case MFI_OSTS:
if (megasas_intr_enabled(s) s-doorbell) {
-retval = MFI_1078_RM | 1;
+if (megasas_is_gen2(pci_class)) {
+retval = MFI_GEN2_RM;
+} else {
+retval = MFI_1078_RM | 1;
+}
}
break;
case MFI_OMSK:
@@ -1914,6 +1933,9 @@ static uint64_t megasas_mmio_read(void *opaque, hwaddr
addr,
case MFI_ODCR0:
retval = s-doorbell;
break;
+case MFI_DIAG:
+retval = s-diag;
+break;
default:
trace_megasas_mmio_invalid_readl(addr);
break;
@@ -1922,6 +1944,8 @@ static uint64_t megasas_mmio_read(void *opaque, hwaddr
addr,
return retval;
}
+static int adp_reset_seq[] = {0x00, 0x04, 0x0b, 0x02, 0x07, 0x0d};
+
static void megasas_mmio_write(void *opaque, hwaddr addr,
uint64_t val, unsigned size)
{
@@ -1996,6 +2020,28 @@ static void megasas_mmio_write(void *opaque, hwaddr addr,
frame_count = (val 1) 0xF;
megasas_handle_frame(s, frame_addr, frame_count);
break;
+case MFI_SEQ:
+/* Magic sequence to start ADP reset */
+if (adp_reset_seq[s-adp_reset] == val) {
+s-adp_reset++;
+} else {
+s-adp_reset = 0;
+s-diag = 0;
+}
+if (s-adp_reset == 6) {
+s-diag = MFI_DIAG_WRITE_ENABLE;
+}
+break;
+case MFI_DIAG:
+/* ADP reset */
+if ((s-diag MFI_DIAG_WRITE_ENABLE)
+
[Qemu-devel] [PATCH 1/7] megasas: Enable MSI-X support
MSI-X support has been fixed in qemu, so we can enable it again.
Signed-off-by: Hannes Reinecke h...@suse.de
---
hw/scsi/megasas.c | 20 ++--
1 file changed, 6 insertions(+), 14 deletions(-)
diff --git a/hw/scsi/megasas.c b/hw/scsi/megasas.c
index e6e1ffd..496bab8 100644
--- a/hw/scsi/megasas.c
+++ b/hw/scsi/megasas.c
@@ -29,7 +29,7 @@
#include mfi.h
-#define MEGASAS_VERSION 1.70
+#define MEGASAS_VERSION 1.71
#define MEGASAS_MAX_FRAMES 2048 /* Firmware limit at 65535 */
#define MEGASAS_DEFAULT_FRAMES 1000 /* Windows requires this */
#define MEGASAS_MAX_SGE 128 /* Firmware limit */
@@ -2083,9 +2083,7 @@ static void megasas_scsi_uninit(PCIDevice *d)
{
MegasasState *s = MEGASAS(d);
-#ifdef USE_MSIX
-msix_uninit(d, s-mmio_io);
-#endif
+msix_uninit(d, s-mmio_io, s-mmio_io);
memory_region_destroy(s-mmio_io);
memory_region_destroy(s-port_io);
memory_region_destroy(s-queue_io);
@@ -2124,15 +2122,11 @@ static int megasas_scsi_init(PCIDevice *dev)
memory_region_init_io(s-queue_io, OBJECT(s), megasas_queue_ops, s,
megasas-queue, 0x4);
-#ifdef USE_MSIX
-/* MSI-X support is currently broken */
if (megasas_use_msix(s)
-msix_init(dev, 15, s-mmio_io, 0, 0x2000)) {
+msix_init(dev, 15, s-mmio_io, 0, 0x2000,
+ s-mmio_io, 0, 0x3800, 0x68)) {
s-flags = ~MEGASAS_MASK_USE_MSIX;
}
-#else
-s-flags = ~MEGASAS_MASK_USE_MSIX;
-#endif
bar_type = PCI_BASE_ADDRESS_SPACE_MEMORY | PCI_BASE_ADDRESS_MEM_TYPE_64;
pci_register_bar(dev, 0, bar_type, s-mmio_io);
@@ -2151,7 +2145,7 @@ static int megasas_scsi_init(PCIDevice *dev)
s-sas_addr |= PCI_FUNC(dev-devfn);
}
if (!s-hba_serial) {
- s-hba_serial = g_strdup(MEGASAS_HBA_SERIAL);
+s-hba_serial = g_strdup(MEGASAS_HBA_SERIAL);
}
if (s-fw_sge = MEGASAS_MAX_SGE - MFI_PASS_FRAME_SIZE) {
s-fw_sge = MEGASAS_MAX_SGE - MFI_PASS_FRAME_SIZE;
@@ -2196,10 +2190,8 @@ static Property megasas_properties[] = {
MEGASAS_DEFAULT_FRAMES),
DEFINE_PROP_STRING(hba_serial, MegasasState, hba_serial),
DEFINE_PROP_UINT64(sas_address, MegasasState, sas_addr, 0),
-#ifdef USE_MSIX
DEFINE_PROP_BIT(use_msix, MegasasState, flags,
-MEGASAS_FLAG_USE_MSIX, false),
-#endif
+MEGASAS_FLAG_USE_MSIX, true),
DEFINE_PROP_BIT(use_jbod, MegasasState, flags,
MEGASAS_FLAG_USE_JBOD, false),
DEFINE_PROP_END_OF_LIST(),
--
1.8.1.4
[Qemu-devel] [PATCH 2/7] megasas: Add MSI support
Some hardware instances do support MSI, so we should do likewise.
Signed-off-by: Hannes Reinecke h...@suse.de
---
hw/scsi/megasas.c | 49 +++--
trace-events | 5 -
2 files changed, 47 insertions(+), 7 deletions(-)
diff --git a/hw/scsi/megasas.c b/hw/scsi/megasas.c
index 496bab8..ae3e9d6 100644
--- a/hw/scsi/megasas.c
+++ b/hw/scsi/megasas.c
@@ -21,6 +21,7 @@
#include hw/hw.h
#include hw/pci/pci.h
#include sysemu/dma.h
+#include hw/pci/msi.h
#include hw/pci/msix.h
#include qemu/iov.h
#include hw/scsi/scsi.h
@@ -43,9 +44,11 @@
#define MEGASAS_FLAG_USE_JBOD 0
#define MEGASAS_MASK_USE_JBOD (1 MEGASAS_FLAG_USE_JBOD)
-#define MEGASAS_FLAG_USE_MSIX 1
+#define MEGASAS_FLAG_USE_MSI 1
+#define MEGASAS_MASK_USE_MSI (1 MEGASAS_FLAG_USE_MSI)
+#define MEGASAS_FLAG_USE_MSIX 2
#define MEGASAS_MASK_USE_MSIX (1 MEGASAS_FLAG_USE_MSIX)
-#define MEGASAS_FLAG_USE_QUEUE64 2
+#define MEGASAS_FLAG_USE_QUEUE64 3
#define MEGASAS_MASK_USE_QUEUE64 (1 MEGASAS_FLAG_USE_QUEUE64)
static const char *mfi_frame_desc[] = {
@@ -132,6 +135,11 @@ static bool megasas_use_queue64(MegasasState *s)
return s-flags MEGASAS_MASK_USE_QUEUE64;
}
+static bool megasas_use_msi(MegasasState *s)
+{
+return s-flags MEGASAS_MASK_USE_MSI;
+}
+
static bool megasas_use_msix(MegasasState *s)
{
return s-flags MEGASAS_MASK_USE_MSIX;
@@ -538,6 +546,9 @@ static void megasas_complete_frame(MegasasState *s,
uint64_t context)
if (msix_enabled(pci_dev)) {
trace_megasas_msix_raise(0);
msix_notify(pci_dev, 0);
+} else if (msi_enabled(pci_dev)) {
+trace_megasas_msi_raise(0);
+msi_notify(pci_dev, 0);
} else {
trace_megasas_irq_raise();
pci_irq_assert(pci_dev);
@@ -1939,12 +1950,20 @@ static void megasas_mmio_write(void *opaque, hwaddr
addr,
break;
case MFI_OMSK:
s-intr_mask = val;
-if (!megasas_intr_enabled(s) !msix_enabled(pci_dev)) {
+if (!megasas_intr_enabled(s)
+!msi_enabled(pci_dev)
+!msix_enabled(pci_dev)) {
trace_megasas_irq_lower();
pci_irq_deassert(pci_dev);
}
if (megasas_intr_enabled(s)) {
-trace_megasas_intr_enabled();
+if (msix_enabled(pci_dev)) {
+trace_megasas_msix_enabled(0);
+} else if (msi_enabled(pci_dev)) {
+trace_megasas_msi_enabled(0);
+} else {
+trace_megasas_intr_enabled();
+}
} else {
trace_megasas_intr_disabled();
}
@@ -2083,7 +2102,12 @@ static void megasas_scsi_uninit(PCIDevice *d)
{
MegasasState *s = MEGASAS(d);
-msix_uninit(d, s-mmio_io, s-mmio_io);
+if (megasas_use_msix(s)) {
+msix_uninit(d, s-mmio_io, s-mmio_io);
+}
+if (megasas_use_msi(s)) {
+msi_uninit(d);
+}
memory_region_destroy(s-mmio_io);
memory_region_destroy(s-port_io);
memory_region_destroy(s-queue_io);
@@ -2122,6 +2146,10 @@ static int megasas_scsi_init(PCIDevice *dev)
memory_region_init_io(s-queue_io, OBJECT(s), megasas_queue_ops, s,
megasas-queue, 0x4);
+if (megasas_use_msi(s)
+msi_init(dev, 0x50, 1, true, false)) {
+s-flags = ~MEGASAS_MASK_USE_MSI;
+}
if (megasas_use_msix(s)
msix_init(dev, 15, s-mmio_io, 0, 0x2000,
s-mmio_io, 0, 0x3800, 0x68)) {
@@ -2158,7 +2186,6 @@ static int megasas_scsi_init(PCIDevice *dev)
s-fw_cmds = MEGASAS_MAX_FRAMES;
}
trace_megasas_init(s-fw_sge, s-fw_cmds,
- megasas_use_msix(s) ? MSI-X : INTx,
megasas_is_jbod(s) ? jbod : raid);
s-fw_luns = (MFI_MAX_LD MAX_SCSI_DEVS) ?
MAX_SCSI_DEVS : MFI_MAX_LD;
@@ -2183,6 +2210,13 @@ static int megasas_scsi_init(PCIDevice *dev)
return 0;
}
+static void
+megasas_write_config(PCIDevice *pci, uint32_t addr, uint32_t val, int len)
+{
+pci_default_write_config(pci, addr, val, len);
+msi_write_config(pci, addr, val, len);
+}
+
static Property megasas_properties[] = {
DEFINE_PROP_UINT32(max_sge, MegasasState, fw_sge,
MEGASAS_DEFAULT_SGE),
@@ -2190,6 +2224,8 @@ static Property megasas_properties[] = {
MEGASAS_DEFAULT_FRAMES),
DEFINE_PROP_STRING(hba_serial, MegasasState, hba_serial),
DEFINE_PROP_UINT64(sas_address, MegasasState, sas_addr, 0),
+DEFINE_PROP_BIT(use_msi, MegasasState, flags,
+MEGASAS_FLAG_USE_MSI, true),
DEFINE_PROP_BIT(use_msix, MegasasState, flags,
MEGASAS_FLAG_USE_MSIX, true),
DEFINE_PROP_BIT(use_jbod, MegasasState, flags,
@@ -2214,6 +2250,7 @@ static void megasas_class_init(ObjectClass *oc, void
*data)
dc-vmsd =
[Qemu-devel] [PATCH 0/7] megasas Update
Hi all, here's an update to the megasas driver. I've re-enabled MSI-X support and added a new emulation mode 'megasas-gen2' which emulates the MegaRAID SAS 2108 HBA. The advantage here is that the original silicon supports both MSI-X and MSI, so some drivers (most notably windows) will refuse to enable MSI-X with the older emulation. To go with that I've also added MSI support. Also an issue has been fixed which caused the megasas driver not to present any disks with current linux kernel version. And some smaller fixes. Plus I've updated the MAINTAINERS file to declare this driver as supported. Hannes Reinecke (7): megasas: Enable MSI-X support megasas: Add MSI support megasas: add MegaRAID SAS 2108 emulation megasas: simplify trace event messages megasas: Implement LD_LIST_QUERY megasas: Decode register names MAINTAINERS: mark megasas as maintained MAINTAINERS | 6 ++ hw/scsi/megasas.c| 195 +++ hw/scsi/mfi.h| 16 include/hw/pci/pci_ids.h | 1 + trace-events | 36 + 5 files changed, 207 insertions(+), 47 deletions(-) -- 1.8.1.4
[Qemu-devel] [PATCH 4/7] megasas: simplify trace event messages
The trace events already contain the function name, so the actual message doesn't need to contain any of these informations. Signed-off-by: Hannes Reinecke h...@suse.de --- trace-events | 26 +- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/trace-events b/trace-events index 7a83c96..e4057e0 100644 --- a/trace-events +++ b/trace-events @@ -611,16 +611,16 @@ megasas_init_firmware(uint64_t pa) pa % PRIx64 megasas_init_queue(uint64_t queue_pa, int queue_len, uint64_t head, uint64_t tail, uint32_t flags) queue at % PRIx64 len %d head % PRIx64 tail % PRIx64 flags %x megasas_initq_map_failed(int frame) scmd %d: failed to map queue megasas_initq_mismatch(int queue_len, int fw_cmds) queue size %d max fw cmds %d -megasas_qf_found(unsigned int index, uint64_t pa) found mapped frame %x pa % PRIx64 +megasas_qf_found(unsigned int index, uint64_t pa) mapped frame %x pa % PRIx64 megasas_qf_new(unsigned int index, void *cmd) return new frame %x cmd %p megasas_qf_failed(unsigned long pa) all frames busy for frame %lx megasas_qf_enqueue(unsigned int index, unsigned int count, uint64_t context, unsigned int tail, int busy) enqueue frame %x count %d context % PRIx64 tail %x busy %d -megasas_qf_update(unsigned int head, unsigned int busy) update reply queue head %x busy %d +megasas_qf_update(unsigned int head, unsigned int busy) reply queue head %x busy %d megasas_qf_map_failed(int cmd, unsigned long frame) scmd %d: frame %lu megasas_qf_complete_noirq(uint64_t context) context % PRIx64 megasas_qf_complete(uint64_t context, unsigned int tail, unsigned int offset, int busy, unsigned int doorbell) context % PRIx64 tail %x offset %d busy %d doorbell %x megasas_frame_busy(uint64_t addr) frame % PRIx64 busy -megasas_unhandled_frame_cmd(int cmd, uint8_t frame_cmd) scmd %d: Unhandled MFI cmd %x +megasas_unhandled_frame_cmd(int cmd, uint8_t frame_cmd) scmd %d: MFI cmd %x megasas_handle_scsi(const char *frame, int bus, int dev, int lun, void *sdev, unsigned long size) %s dev %x/%x/%x sdev %p xfer %lu megasas_scsi_target_not_present(const char *frame, int bus, int dev, int lun) %s dev %x/%x/%x target not present megasas_scsi_invalid_cdb_len(const char *frame, int bus, int dev, int lun, int len) %s dev %x/%x/%x invalid cdb len %d @@ -632,8 +632,8 @@ megasas_scsi_req_alloc_failed(const char *frame, int dev, int lun) %s dev %x/%x megasas_scsi_read_start(int cmd, int len) scmd %d: transfer %d bytes of data megasas_scsi_write_start(int cmd, int len) scmd %d: transfer %d bytes of data megasas_scsi_nodata(int cmd) scmd %d: no data to be transferred -megasas_scsi_complete(int cmd, uint32_t status, int len, int xfer) scmd %d: finished with status %x, len %u/%u -megasas_command_complete(int cmd, uint32_t status, uint32_t resid) scmd %d: command completed, status %x, residual %d +megasas_scsi_complete(int cmd, uint32_t status, int len, int xfer) scmd %d: status %x, len %u/%u +megasas_command_complete(int cmd, uint32_t status, uint32_t resid) scmd %d: status %x, residual %d megasas_handle_io(int cmd, const char *frame, int dev, int lun, unsigned long lba, unsigned long count) scmd %d: %s dev %x/%x lba %lx count %lu megasas_io_target_not_present(int cmd, const char *frame, int dev, int lun) scmd %d: %s dev 1/%x/%x LUN not present megasas_io_read_start(int cmd, unsigned long lba, unsigned long count, unsigned long len) scmd %d: start LBA %lx %lu blocks (%lu bytes) @@ -650,22 +650,22 @@ megasas_handle_dcmd(int cmd, int opcode) scmd %d: MFI DCMD opcode %x megasas_finish_dcmd(int cmd, int size) scmd %d: MFI DCMD wrote %d bytes megasas_dcmd_req_alloc_failed(int cmd, const char *desc) scmd %d: %s alloc failed megasas_dcmd_internal_submit(int cmd, const char *desc, int dev) scmd %d: %s to dev %d -megasas_dcmd_internal_finish(int cmd, int opcode, int lun) scmd %d: DCMD finish internal cmd %x lun %d -megasas_dcmd_internal_invalid(int cmd, int opcode) scmd %d: Invalid internal DCMD %x +megasas_dcmd_internal_finish(int cmd, int opcode, int lun) scmd %d: cmd %x lun %d +megasas_dcmd_internal_invalid(int cmd, int opcode) scmd %d: DCMD %x megasas_dcmd_unhandled(int cmd, int opcode, int len) scmd %d: opcode %x, len %d megasas_dcmd_zero_sge(int cmd) scmd %d: zero DCMD sge count -megasas_dcmd_invalid_sge(int cmd, int count) scmd %d: invalid DCMD sge count %d +megasas_dcmd_invalid_sge(int cmd, int count) scmd %d: DCMD sge count %d megasas_dcmd_invalid_xfer_len(int cmd, unsigned long size, unsigned long max) scmd %d: invalid xfer len %ld, max %ld megasas_dcmd_enter(int cmd, const char *dcmd, int len) scmd %d: DCMD %s len %d -megasas_dcmd_dummy(int cmd, unsigned long size) scmd %d: DCMD dummy xfer len %ld +megasas_dcmd_dummy(int cmd, unsigned long size) scmd %d: xfer len %ld megasas_dcmd_set_fw_time(int cmd, unsigned long time) scmd %d: Set FW time %lx megasas_dcmd_pd_get_list(int cmd, int num, int max, int offset) scmd %d: DCMD PD get list: %d / %d
[Qemu-devel] [PATCH 5/7] megasas: Implement LD_LIST_QUERY
New drivers implement a LD_LIST_QUERY command, and due to a driver
issue no drives might be detected if this command isn't supported.
So add emulation for this command, too.
Signed-off-by: Hannes Reinecke h...@suse.de
---
hw/scsi/megasas.c | 17 +
hw/scsi/mfi.h | 9 +
trace-events | 1 +
3 files changed, 27 insertions(+)
diff --git a/hw/scsi/megasas.c b/hw/scsi/megasas.c
index 687115e..859b294 100644
--- a/hw/scsi/megasas.c
+++ b/hw/scsi/megasas.c
@@ -1130,6 +1130,21 @@ static int megasas_dcmd_ld_get_list(MegasasState *s,
MegasasCmd *cmd)
return MFI_STAT_OK;
}
+static int megasas_dcmd_ld_list_query(MegasasState *s, MegasasCmd *cmd)
+{
+uint16_t flags;
+
+/* mbox0 contains flags */
+flags = le16_to_cpu(cmd-frame-dcmd.mbox[0]);
+trace_megasas_dcmd_ld_list_query(cmd-index, flags);
+if (flags == MR_LD_QUERY_TYPE_ALL ||
+flags == MR_LD_QUERY_TYPE_EXPOSED_TO_HOST) {
+return megasas_dcmd_ld_get_list(s, cmd);
+}
+
+return MFI_STAT_OK;
+}
+
static int megasas_ld_get_info_submit(SCSIDevice *sdev, int lun,
MegasasCmd *cmd)
{
@@ -1433,6 +1448,8 @@ static const struct dcmd_cmd_tbl_t {
megasas_dcmd_dummy },
{ MFI_DCMD_LD_GET_LIST, LD_GET_LIST,
megasas_dcmd_ld_get_list},
+{ MFI_DCMD_LD_LIST_QUERY, LD_LIST_QUERY,
+ megasas_dcmd_ld_list_query },
{ MFI_DCMD_LD_GET_INFO, LD_GET_INFO,
megasas_dcmd_ld_get_info },
{ MFI_DCMD_LD_GET_PROP, LD_GET_PROP,
diff --git a/hw/scsi/mfi.h b/hw/scsi/mfi.h
index c365356..b344e4a 100644
--- a/hw/scsi/mfi.h
+++ b/hw/scsi/mfi.h
@@ -171,6 +171,7 @@ typedef enum {
MFI_DCMD_PD_BLINK = 0x02070100,
MFI_DCMD_PD_UNBLINK = 0x02070200,
MFI_DCMD_LD_GET_LIST = 0x0301,
+MFI_DCMD_LD_LIST_QUERY =0x03010100,
MFI_DCMD_LD_GET_INFO = 0x0302,
MFI_DCMD_LD_GET_PROP = 0x0303,
MFI_DCMD_LD_SET_PROP = 0x0304,
@@ -418,6 +419,14 @@ typedef enum {
MR_PD_QUERY_TYPE_EXPOSED_TO_HOST = 5, /*query for system drives */
} mfi_pd_query_type;
+typedef enum {
+MR_LD_QUERY_TYPE_ALL = 0,
+MR_LD_QUERY_TYPE_EXPOSED_TO_HOST = 1,
+MR_LD_QUERY_TYPE_USED_TGT_IDS = 2,
+MR_LD_QUERY_TYPE_CLUSTER_ACCESS = 3,
+MR_LD_QUERY_TYPE_CLUSTER_LOCALE = 4,
+} mfi_ld_query_type;
+
/*
* Other propertities and definitions
*/
diff --git a/trace-events b/trace-events
index e4057e0..e0d65cb 100644
--- a/trace-events
+++ b/trace-events
@@ -664,6 +664,7 @@ megasas_dcmd_ld_get_list(int cmd, int num, int max) scmd
%d: DCMD LD get list:
megasas_dcmd_ld_get_info(int cmd, int ld_id) scmd %d: dev %d
megasas_dcmd_pd_get_info(int cmd, int pd_id) scmd %d: dev %d
megasas_dcmd_pd_list_query(int cmd, int flags) scmd %d: query flags %x
+megasas_dcmd_ld_list_query(int cmd, int flags) scmd %d: query flags %x
megasas_dcmd_unsupported(int cmd, unsigned long size) scmd %d: set properties
len %ld
megasas_abort_frame(int cmd, int abort_cmd) scmd %d: frame %x
megasas_abort_no_cmd(int cmd, uint64_t context) scmd %d: no active command
for frame context % PRIx64
--
1.8.1.4
[Qemu-devel] [PATCH 6/7] megasas: Decode register names
To ease debugging we should be decoding
the register names.
Signed-off-by: Hannes Reinecke h...@suse.de
---
hw/scsi/megasas.c | 22 +++---
trace-events | 4 ++--
2 files changed, 21 insertions(+), 5 deletions(-)
diff --git a/hw/scsi/megasas.c b/hw/scsi/megasas.c
index 859b294..dafa012 100644
--- a/hw/scsi/megasas.c
+++ b/hw/scsi/megasas.c
@@ -1927,6 +1927,7 @@ static uint64_t megasas_mmio_read(void *opaque, hwaddr
addr,
switch (addr) {
case MFI_IDB:
retval = 0;
+trace_megasas_mmio_readl(MFI_IDB, retval);
break;
case MFI_OMSG0:
case MFI_OSP0:
@@ -1934,6 +1935,8 @@ static uint64_t megasas_mmio_read(void *opaque, hwaddr
addr,
(s-fw_state MFI_FWSTATE_MASK) |
((s-fw_sge 0xff) 16) |
(s-fw_cmds 0x);
+trace_megasas_mmio_readl(addr == MFI_OMSG0 ? MFI_OMSG0 : MFI_OSP0,
+ retval);
break;
case MFI_OSTS:
if (megasas_intr_enabled(s) s-doorbell) {
@@ -1943,21 +1946,24 @@ static uint64_t megasas_mmio_read(void *opaque, hwaddr
addr,
retval = MFI_1078_RM | 1;
}
}
+trace_megasas_mmio_readl(MFI_OSTS, retval);
break;
case MFI_OMSK:
retval = s-intr_mask;
+trace_megasas_mmio_readl(MFI_OMSK, retval);
break;
case MFI_ODCR0:
retval = s-doorbell;
+trace_megasas_mmio_readl(MFI_ODCR0, retval);
break;
case MFI_DIAG:
retval = s-diag;
+trace_megasas_mmio_readl(MFI_DIAG, retval);
break;
default:
trace_megasas_mmio_invalid_readl(addr);
break;
}
-trace_megasas_mmio_readl(addr, retval);
return retval;
}
@@ -1972,9 +1978,9 @@ static void megasas_mmio_write(void *opaque, hwaddr addr,
uint32_t frame_count;
int i;
-trace_megasas_mmio_writel(addr, val);
switch (addr) {
case MFI_IDB:
+trace_megasas_mmio_writel(MFI_IDB, val);
if (val MFI_FWINIT_ABORT) {
/* Abort all pending cmds */
for (i = 0; i s-fw_cmds; i++) {
@@ -1990,6 +1996,7 @@ static void megasas_mmio_write(void *opaque, hwaddr addr,
}
break;
case MFI_OMSK:
+trace_megasas_mmio_writel(MFI_OMSK, val);
s-intr_mask = val;
if (!megasas_intr_enabled(s)
!msi_enabled(pci_dev)
@@ -2010,6 +2017,7 @@ static void megasas_mmio_write(void *opaque, hwaddr addr,
}
break;
case MFI_ODCR0:
+trace_megasas_mmio_writel(MFI_ODCR0, val);
s-doorbell = 0;
if (s-producer_pa megasas_intr_enabled(s)) {
/* Update reply queue pointer */
@@ -2023,13 +2031,19 @@ static void megasas_mmio_write(void *opaque, hwaddr
addr,
}
break;
case MFI_IQPH:
+trace_megasas_mmio_writel(MFI_IQPH, val);
/* Received high 32 bits of a 64 bit MFI frame address */
s-frame_hi = val;
break;
case MFI_IQPL:
+trace_megasas_mmio_writel(MFI_IQPL, val);
/* Received low 32 bits of a 64 bit MFI frame address */
case MFI_IQP:
-/* Received 32 bit MFI frame address */
+if (addr == MFI_IQP) {
+trace_megasas_mmio_writel(MFI_IQP, val);
+/* Received 32 bit MFI frame address */
+s-frame_hi = 0;
+}
frame_addr = (val ~0x1F);
/* Add possible 64 bit offset */
frame_addr |= ((uint64_t)s-frame_hi 32);
@@ -2038,6 +2052,7 @@ static void megasas_mmio_write(void *opaque, hwaddr addr,
megasas_handle_frame(s, frame_addr, frame_count);
break;
case MFI_SEQ:
+trace_megasas_mmio_writel(MFI_SEQ, val);
/* Magic sequence to start ADP reset */
if (adp_reset_seq[s-adp_reset] == val) {
s-adp_reset++;
@@ -2050,6 +2065,7 @@ static void megasas_mmio_write(void *opaque, hwaddr addr,
}
break;
case MFI_DIAG:
+trace_megasas_mmio_writel(MFI_DIAG, val);
/* ADP reset */
if ((s-diag MFI_DIAG_WRITE_ENABLE)
(val MFI_DIAG_RESET_ADP)) {
diff --git a/trace-events b/trace-events
index e0d65cb..5113cb1 100644
--- a/trace-events
+++ b/trace-events
@@ -679,9 +679,9 @@ megasas_intr_enabled(void) Interrupts enabled
megasas_intr_disabled(void) Interrupts disabled
megasas_msix_enabled(int vector) vector %d
megasas_msi_enabled(int vector) vector %d
-megasas_mmio_readl(unsigned long addr, uint32_t val) addr 0x%lx: 0x%x
+megasas_mmio_readl(const char *reg, uint32_t val) reg %s: 0x%x
megasas_mmio_invalid_readl(unsigned long addr) addr 0x%lx
-megasas_mmio_writel(uint32_t addr, uint32_t val) addr 0x%x: 0x%x
+megasas_mmio_writel(const char *reg, uint32_t val) reg %s: 0x%x
megasas_mmio_invalid_writel(uint32_t addr, uint32_t val) addr 0x%x: 0x%x
# hw/audio/milkymist-ac97.c
--
1.8.1.4
[Qemu-devel] [PATCH 7/7] MAINTAINERS: mark megasas as maintained
Signed-off-by: Hannes Reinecke h...@suse.de --- MAINTAINERS | 6 ++ 1 file changed, 6 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index c66946f..f1d3f09 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -651,6 +651,12 @@ S: Supported F: hw/block/nvme* F: tests/nvme-test.c +megasas +M: Hannes Reinecke h...@suse.de +S: Supported +F: hw/scsi/megasas.c +F: hw/scsi/mfi.h + Xilinx EDK M: Peter Crosthwaite peter.crosthwa...@xilinx.com M: Edgar E. Iglesias edgar.igles...@gmail.com -- 1.8.1.4
Re: [Qemu-devel] KVM call agenda for 2014-04-15
Am 16.04.2014 um 08:26 schrieb Markus Armbruster arm...@redhat.com: Alexander Graf ag...@suse.de writes: Am 15.04.2014 um 18:56 schrieb Markus Armbruster arm...@redhat.com: Alexander Graf ag...@suse.de writes: On 04/15/2014 04:00 PM, Markus Armbruster wrote: Juan Quintela quint...@redhat.com writes: Juan Quintela quint...@redhat.com wrote: Hi Please, send any topic that you are interested in covering. Thanks, Juan. As there are no topics, no call. Did we have a call anyway? IRC log looks like we did... Yes, we did. Whoever attended, please reply with things I mixed up or forgot. Two topics: [...] 2) -device for non-PCI devices Interesting stuff, hate to have missed it. Can we please ensure more useful advance notice than monitor the IRC channel around call time? Decide call / no call the night before would work nicely for me. I sent an email to the list earlier this werk as reply to the last call, because there was no mail for this week's agenda yet. That's probably why Juan didn't pick it up. Explanation, not criticizing either of you. If we post the call's agenda the night before, there's time to correct omissions. I'm fine with late agenda changes. I really don't like last minute call / no call decisions. How about we post the agenda mail for next time right after the last meeting? Then people have 2 weeks to gather ideas. Alex
Re: [Qemu-devel] [PATCH v1 0/3] Introduce qemu_get_boot_opts()
Peter Crosthwaite peter.crosthwa...@xilinx.com writes: Hi Markus, This series introduces qemu_get_boot_opts(), in much the same way as was done for qemu_get_machine_opts(). As usual, I have out-of-scope and out-of-tree usages :) But P3 does clean up the one existing instance of the long-and-awkward form of this query and makes it consistent with an immediately surrounding qemu_get_machine_opts(). I doubt this is worthwhile on its own as it stands. However, you missed the two uses of boot-opts in hw/nvram/fw_cfg.c. Since these uses are currently wrong the same way as the the uses of machine fixed in commit 36ad0e9 were, covering them could strengthen your case quite a bit,
Re: [Qemu-devel] QEMU 2.0 RC with Spice
* Rick Vernam (rtver...@hobi.com) wrote: On Tuesday 15 April 2014 19:25:22 Rick Vernam wrote: Looks like it's in Spice: snip old backtrace without symbols I'll see if I can build spice with debugging symbols and what not and write back with findings. Are others have problems with Qemu 2.0 RCs Spice? Here is how I started qemu with gdb: QEMU_AUDIO_DRV=spice TMPDIR=/home/rick/qemu/hds gdb --args /usr/local/bin/qemu-system-x86_64 -cpu host -enable-kvm \ -m 1536 -name Win7Pro64 -localtime -no-fd-bootchk -smp cores=4 \ -pidfile /home/rick/qemu/hds/win7pro64.pid \ -drive file=/home/rick/qemu/hds/win7pro64.qed,if=virtio,index=0,snapshot=on \ -vga qxl \ -net nic,model=virtio -net user \ -device virtio-serial-pci,id=virtio-serial0,max_ports=16,bus=pci.0,addr=0x5 \ -chardev spicevmc,name=vdagent,id=vdagent \ -device virtserialport,nr=1,bus=virtio-serial0.0,chardev=vdagent,name=com.redhat.sp ice.0 \ -spice port=1247,disable-ticketing \ -monitor telnet:localhost:12471,server,nowait \ -drive if=none,id=cd,file=/dev/sg1 \ -device virtio-scsi-pci,id=scsi \ -device scsi-generic,drive=cd \ -balloon virtio \ -soundhw hda \ -device usb-ehci Thanks, -Rick On Tuesday 15 April 2014 15:22:04 Dr. David Alan Gilbert wrote: * Rick Vernam (rtver...@hobi.com) wrote: I have been trying out the 2.0 RCs, and I've noticed that when I use spice qemu aborts when I reboot the VM. This occurs on Win XP guest, Win 7 (64-bit) guest and Win 8 (64-bit) guest. Is this something that anybody else experiences? I don't care to divert anybody's energy if this a spice thing - how best to determine this? You say qemu aborts; can you get a backtrace and the abort message? Dave -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK sorry, for top posting my last response. and also sorry for not noticing that I had let the binaries get stripped previously. Here with qemu-system-x86_64 not stripped, and spice lib not stripped: Program received signal SIGSEGV, Segmentation fault. 0x7211eae5 in spice_char_device_write_to_device (dev=0x5687bcf0) at char_device.c:443 443 sif = SPICE_CONTAINEROF(dev-sin-base.sif, SpiceCharDeviceInterface, base); (gdb) bt #0 0x7211eae5 in spice_char_device_write_to_device (dev=0x5687bcf0) at char_device.c:443 #1 0x7211fd81 in spice_char_device_start (dev=0x5687bcf0) at char_device.c:798 #2 0x72171f95 in spice_server_vm_start (s=0x561d4360) at reds.c:4520 #3 0x556a1119 in qdev_reset_one (dev=optimized out, opaque=optimized out) at hw/core/qdev.c:240 #4 0x556a0958 in qbus_walk_children (bus=0x567576a0, pre_devfn=0x0, pre_busfn=0x0, post_devfn=0x556a1100 qdev_reset_one, post_busfn=0x5569f060 qbus_reset_one, opaque=0x0) at hw/core/qdev.c:369 #5 0x556a0878 in qdev_walk_children (dev=0x5677c0b0, pre_devfn=0x0, pre_busfn=0x0, post_devfn=0x556a1100 qdev_reset_one, post_busfn=0x5569f060 qbus_reset_one, opaque=0x0) at hw/core/qdev.c:403 #6 0x556a0958 in qbus_walk_children (bus=0x567459c0, pre_devfn=0x0, pre_busfn=0x0, post_devfn=0x556a1100 qdev_reset_one, post_busfn=0x5569f060 qbus_reset_one, opaque=0x0) at hw/core/qdev.c:369 #7 0x557d717a in qemu_devices_reset () at vl.c:1867 #8 qemu_system_reset (report=report@entry=true) at vl.c:1880 #9 0x555f9e2f in main_loop_should_exit () at vl.c:2015 #10 main_loop () at vl.c:2055 #11 main (argc=optimized out, argv=optimized out, envp=optimized out) at vl.c:4507 Thanks, and what can I do to provide more info? I don't know much about spice; I've added kra...@redhat.com to cc who knows spice. Can you clarify a bit more about which spice version you're using and anything else about your setup that might be relevant. Dave -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
[Qemu-devel] [Bug 1257352] Re: kvm hangs occasionally when switching out of the qemu console
Hi Serge, I'm running on pure amd64 too so the problem is not arch-specific. The simplest way to recreate: $ kvm -cdrom /usr/lib/memtest86+/memtest86+.iso -m 512 Just hold down control+alt and frantically toggle the monitor using the '2' and '1'. Within a couple of seconds it hangs. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1257352 Title: kvm hangs occasionally when switching out of the qemu console Status in QEMU: New Status in “qemu” package in Ubuntu: Confirmed Bug description: To recreate (although this does *NOT* fail most of the time alas): 1) press ctrl-alt-2 to switch to the qemu console. 2) type say sendkey ctrl-alt-f1 3) press ctrl-alt-1. Expected outcome: Switch to tty1 in the VM. Actual outcome: No switch to tty1 in the VM. and qemu console unresponsive to any keyboard input. Rather a vague problem description I'm afraid but this has happened to me 3 times recently. No crash and no excessive CPU is observed. I'll grab an strace when it happens again and attach... ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: qemu-system-x86 1.6.0+dfsg-2ubuntu4 ProcVersionSignature: Ubuntu 3.12.0-4.12-generic 3.12.1 Uname: Linux 3.12.0-4-generic i686 NonfreeKernelModules: nvidia ApportVersion: 2.12.7-0ubuntu1 Architecture: i386 CurrentDesktop: Unity Date: Tue Dec 3 15:41:40 2013 InstallationDate: Installed on 2010-10-21 (1139 days ago) InstallationMedia: Ubuntu 10.10 Maverick Meerkat - Release i386 (20101007) SourcePackage: qemu UpgradeStatus: Upgraded to trusty on 2013-11-01 (31 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1257352/+subscriptions
[Qemu-devel] [questions] host panic happened when kvm guest access the memory which was provided by host remap_pfn_range page to qemu
Hi, all
I provide host's memory to guest by remap_pfn_range host page to qemu, and when
guest access the page, host paniced.
host code:
static int my_mmap(struct file *filep, struct vm_area_struct *vma)
{
int ret;
unsigned long page;
if (vma-vm_end vma-vm_start)
return -EINVAL;
page = __get_free_page(GFP_KERNEL);
if (!page)
return -ENOMEM;
ret = remap_pfn_range(vma, vma-vm_start, page PAGE_SHIFT, PAGE_SIZE,
vma-vm_page_prot);
return ret;
}
qemu code:
#define PC_SHMEM_PHY_ADDR 0xfeff8000
MemoryRegion *my_shmem_region = NULL;
static void pc_share_memory_init(MemoryRegion *system_memory)
{
int fd;
void *ptr;
fd = open(/dev/g2h, O_RDWR);
if (fd 0)
return;
ptr = mmap(NULL, PAGE_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED |
MAP_LOCKED, fd, 0);
if(!ptr) {
close(fd);
return;
}
my_shmem_region = g_malloc(sizeof(*my_shmem_region));
memory_region_init_ram_ptr(my_shmem_region, share.ram, PAGE_SIZE, ptr);
vmstate_register_ram_global(my_shmem_region);
memory_region_add_subregion(system_memory, PC_SHMEM_PHY_ADDR,
my_shmem_region);
e820_add_entry(PC_SHMEM_PHY_ADDR, PAGE_SIZE, E820_RESERVED);
return;
}
guest:
mapping the PC_SHMEM_PHY_ADDR, when access it, host paniced, [cut here] shown
as below,
[0.892825] [ cut here ]
[0.892850] kernel BUG at arch/x86/kvm/../../../virt/kvm/kvm_main.c:1346!
[0.892876] invalid opcode: [#1] SMP
[0.892934] Modules linked in: tun g2h_main(O) nfsv4 fuse nfsd auth_rpcgss
nfs_acl nfs lockd dns_resolver fscache sunrpc xt_tcpudp nf_conntrack_ipv4
nf_defrag_ipv4
[0.894519] CPU 0
[0.894541] Pid: 21808, comm: kvm Tainted: G O 3.9.7 #25 Gigabyte
Technology Co., Ltd. To be filled by O.E.M./B75M-D3V
[0.894590] RIP: 0010:[a097d06e] [a097d06e]
__gfn_to_pfn_memslot+0x2e6/0x355 [kvm]
[0.894660] RSP: 0018:8803a54dbb38 EFLAGS: 00010246
[0.894693] RAX: RBX: 7f37902be000 RCX: 88041e5dd000
[0.894728] RDX: ea00 RSI: 0046 RDI: ea00
[0.894763] RBP: 000fef00 R08: 0002 R09:
[0.894798] R10: R11: R12: 8803a54dbc4b
[0.894833] R13: 8803a55ebac8 R14: R15: 8803a56b8301
[0.894868] FS: 7f3784534700() GS:88041e20()
knlGS:
[0.894913] CS: 0010 DS: ES: CR0: 80050033
[0.894956] CR2: 01c4fc1c CR3: 0003ab076000 CR4: 001427e0
[0.895000] DR0: DR1: DR2:
[0.895035] DR3: DR6: 0ff0 DR7: 0400
[0.895070] Process kvm (pid: 21808, threadinfo 8803a54da000, task
8803ca961000)
[0.895114] Stack:
[0.895143] 8803a54dbbb8 0001 8803a54dbbb7
00ff
[0.895256] 8803a5588000 a097d11d 0003fe37
8803a5588000
[0.895374] 000feff8 feff8000
8803a54dbc50
[0.895487] Call Trace:
[0.895522] [a097d11d] ? __gfn_to_pfn+0x2b/0x50 [kvm]
[0.895565] [a09927ee] ? try_async_pf+0x38/0x1a1 [kvm]
[0.895603] [a097cd4d] ? kvm_host_page_size+0x73/0x7b [kvm]
[0.895643] [a099752e] ? tdp_page_fault+0xf1/0x1ee [kvm]
[0.895682] [a0993aee] ? kvm_mmu_page_fault+0x1e/0xbb [kvm]
[0.895719] [a0a17cb9] ? vmx_handle_exit+0x730/0x776 [kvm_intel]
[0.895756] [8149c09c] ? _raw_spin_unlock_irqrestore+0xc/0xd
[0.895792] [813d15b5] ? skb_dequeue+0x50/0x58
[0.895827] [81048aaf] ? recalc_sigpending+0x12/0x41
[0.895863] [a0a16d28] ? vmx_vcpu_run+0x38a/0x464 [kvm_intel]
[0.895902] [a099fc19] ? apic_update_ppr+0x15/0x74 [kvm]
[0.895941] [a09a5a29] ? e1000_check_irq_ignore+0xfa/0x129 [kvm]
[0.895981] [a0990174] ? kvm_arch_vcpu_ioctl_run+0xb3e/0xec5 [kvm]
[0.896021] [a098b737] ? kvm_arch_vcpu_load+0xc1/0x18c [kvm]
[0.896058] [a097c0d3] ? kvm_vcpu_ioctl+0x118/0x462 [kvm]
[0.896094] [8110e9a6] ? vfs_ioctl+0x1e/0x31
[0.896128] [8110f17d] ? do_vfs_ioctl+0x3ae/0x3f0
[0.896163] [81100d48] ? vfs_read+0x93/0xf5
[0.896196] [81101f69] ? fput+0xf/0xac
[0.896229] [8110f20c] ? sys_ioctl+0x4d/0x7d
[0.896263] [814a23e9] ? system_call_fastpath+0x16/0x1b
[0.896296] Code: 8a 9b a0 31 c0 e8 92 79 b1 e0 49 8b b5 98 00 00 00 48 c7
c7 e2 8a 9b a0 31 c0 e8 7d 79 b1 e0 4c 89 f7 e8 05 ed ff ff 84 c0 75 1e 0f 0b
45 84 ff
[0.897491] RIP [a097d06e] __gfn_to_pfn_memslot+0x2e6/0x355 [kvm]
[0.897545] RSP 8803a54dbb38
Any ideas?
Thanks,
Zhang Haoyu
[Qemu-devel] [PATCH v2 0/2] HMP: support specifying dump format for dump-guest-memory
The last version is here: http://lists.nongnu.org/archive/html/qemu-devel/2014-04/msg00018.html ChangLog: Changes from v7 to v8: 1. add a patch to fix doc of dump-guest-memory Qiao Nuohan (2): HMP: fix doc of dump-guest-memory HMP: support specifying dump format for dump-guest-memory hmp-commands.hx | 25 - hmp.c | 25 ++--- 2 files changed, 38 insertions(+), 12 deletions(-) -- 1.8.5.3
[Qemu-devel] [PATCH v2 1/2] HMP: fix doc of dump-guest-memory
Signed-off-by: Qiao Nuohan qiaonuo...@cn.fujitsu.com
---
hmp-commands.hx | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/hmp-commands.hx b/hmp-commands.hx
index 0da8f28..ca5737b 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -1000,10 +1000,10 @@ ETEXI
.name = dump-guest-memory,
.args_type = paging:-p,filename:F,begin:i?,length:i?,
.params = [-p] filename [begin length],
-.help = dump guest memory into file 'filename'\n\t\t\t
- -p: do paging to get guest's memory mapping\n\t\t\t
- begin: the starting physical address\n\t\t\t
- length: the memory size, in bytes,
+.help = dump guest memory into file 'filename'.\n\t\t\t
+ -p: do paging to get guest's memory mapping.\n\t\t\t
+ begin: the starting physical address.\n\t\t\t
+ length: the memory size, in bytes.,
.mhandler.cmd = hmp_dump_guest_memory,
},
@@ -1013,8 +1013,8 @@ STEXI
@findex dump-guest-memory
Dump guest memory to @var{filename}. The file can be processed with crash or
gdb.
--p: do paging to get guest's memory mapping
- filename: dump file name
+-p: do paging to get guest's memory mapping.
+ filename: dump file name.
begin: the starting physical address. It's optional, and should be
specified together with length.
length: the memory size, in bytes. It's optional, and should be specified
--
1.8.5.3
[Qemu-devel] [PATCH v2 2/2] HMP: support specifying dump format for dump-guest-memory
Dumping guest memory is available to specify the dump format now. This patch
adds options '-z|-l|-s' to HMP command dump-guest-memory to specify dumping in
kdump-compression format, with zlib/lzo/snappy compression. And without these
options ELF format will be used.
The discussion about this feature is here:
http://lists.nongnu.org/archive/html/qemu-devel/2014-03/msg04235.html
Signed-off-by: Qiao Nuohan qiaonuo...@cn.fujitsu.com
Suggested-by: Christian Borntraeger borntrae...@de.ibm.com
---
hmp-commands.hx | 13 ++---
hmp.c | 25 ++---
2 files changed, 32 insertions(+), 6 deletions(-)
diff --git a/hmp-commands.hx b/hmp-commands.hx
index ca5737b..8e7501b 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -998,10 +998,13 @@ ETEXI
{
.name = dump-guest-memory,
-.args_type = paging:-p,filename:F,begin:i?,length:i?,
-.params = [-p] filename [begin length],
+.args_type =
paging:-p,zlib:-z,lzo:-l,snappy:-s,filename:F,begin:i?,length:i?,
+.params = [-p] [-z|-l|-s] filename [begin length],
.help = dump guest memory into file 'filename'.\n\t\t\t
-p: do paging to get guest's memory mapping.\n\t\t\t
+ -z: dump in kdump-compressed format, with zlib
compression.\n\t\t\t
+ -l: dump in kdump-compressed format, with lzo
compression.\n\t\t\t
+ -s: dump in kdump-compressed format, with snappy
compression.\n\t\t\t
begin: the starting physical address.\n\t\t\t
length: the memory size, in bytes.,
.mhandler.cmd = hmp_dump_guest_memory,
@@ -1010,10 +1013,14 @@ ETEXI
STEXI
@item dump-guest-memory [-p] @var{filename} @var{begin} @var{length}
+@item dump-guest-memory [-z|-l|-s] @var{filename}
@findex dump-guest-memory
Dump guest memory to @var{filename}. The file can be processed with crash or
-gdb.
+gdb. Without -z|-l|-s, the dump format is ELF.
-p: do paging to get guest's memory mapping.
+-z: dump in kdump-compressed format, with zlib compression.
+-l: dump in kdump-compressed format, with lzo compression.
+-s: dump in kdump-compressed format, with snappy compression.
filename: dump file name.
begin: the starting physical address. It's optional, and should be
specified together with length.
diff --git a/hmp.c b/hmp.c
index 2f279c4..ca869ba 100644
--- a/hmp.c
+++ b/hmp.c
@@ -1308,16 +1308,35 @@ void hmp_dump_guest_memory(Monitor *mon, const QDict
*qdict)
{
Error *errp = NULL;
int paging = qdict_get_try_bool(qdict, paging, 0);
+int zlib = qdict_get_try_bool(qdict, zlib, 0);
+int lzo = qdict_get_try_bool(qdict, lzo, 0);
+int snappy = qdict_get_try_bool(qdict, snappy, 0);
const char *file = qdict_get_str(qdict, filename);
bool has_begin = qdict_haskey(qdict, begin);
bool has_length = qdict_haskey(qdict, length);
-/* kdump-compressed format is not supported for HMP */
-bool has_format = false;
int64_t begin = 0;
int64_t length = 0;
enum DumpGuestMemoryFormat dump_format = DUMP_GUEST_MEMORY_FORMAT_ELF;
char *prot;
+if (zlib + lzo + snappy 1) {
+error_setg(errp, only one of '-z|-l|-s' can be set);
+hmp_handle_error(mon, errp);
+return;
+}
+
+if (zlib) {
+dump_format = DUMP_GUEST_MEMORY_FORMAT_KDUMP_ZLIB;
+}
+
+if (lzo) {
+dump_format = DUMP_GUEST_MEMORY_FORMAT_KDUMP_LZO;
+}
+
+if (snappy) {
+dump_format = DUMP_GUEST_MEMORY_FORMAT_KDUMP_SNAPPY;
+}
+
if (has_begin) {
begin = qdict_get_int(qdict, begin);
}
@@ -1328,7 +1347,7 @@ void hmp_dump_guest_memory(Monitor *mon, const QDict
*qdict)
prot = g_strconcat(file:, file, NULL);
qmp_dump_guest_memory(paging, prot, has_begin, begin, has_length, length,
- has_format, dump_format, errp);
+ true, dump_format, errp);
hmp_handle_error(mon, errp);
g_free(prot);
}
--
1.8.5.3
Re: [Qemu-devel] [PATCH 13/35] pc: initialize memory hotplug address space
On Fri, Apr 04, 2014 at 03:36:38PM +0200, Igor Mammedov wrote:
initialize and map hotplug memory address space container
into guest's RAM address space.
Signed-off-by: Igor Mammedov imamm...@redhat.com
---
hw/i386/pc.c | 19 +--
include/hw/i386/pc.h | 10 ++
2 files changed, 27 insertions(+), 2 deletions(-)
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 32b4003..69e4225 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1171,6 +1171,9 @@ FWCfgState *pc_memory_init(MemoryRegion *system_memory,
MemoryRegion *ram, *option_rom_mr;
MemoryRegion *ram_below_4g, *ram_above_4g;
FWCfgState *fw_cfg;
+ram_addr_t ram_size = below_4g_mem_size + above_4g_mem_size;
+MachineState *machine = MACHINE(qdev_get_machine());
+PCMachineState *pcms = PC_MACHINE(machine);
linux_boot = (kernel_filename != NULL);
@@ -1179,8 +1182,7 @@ FWCfgState *pc_memory_init(MemoryRegion *system_memory,
* with older qemus that used qemu_ram_alloc().
*/
ram = g_malloc(sizeof(*ram));
-memory_region_init_ram(ram, NULL, pc.ram,
- below_4g_mem_size + above_4g_mem_size);
+memory_region_init_ram(ram, NULL, pc.ram, ram_size);
vmstate_register_ram_global(ram);
*ram_memory = ram;
ram_below_4g = g_malloc(sizeof(*ram_below_4g));
@@ -1197,6 +1199,19 @@ FWCfgState *pc_memory_init(MemoryRegion *system_memory,
e820_add_entry(0x1ULL, above_4g_mem_size, E820_RAM);
}
+/* initialize hotplug memory address space */
+if (ram_size machine-init_args.maxram_size) {
+ram_addr_t hotplug_mem_size =
+machine-init_args.maxram_size - ram_size;
+
+pcms-hotplug_memory_base =
+ROUND_UP(0x1ULL + above_4g_mem_size, 1ULL 30);
-m maxmem should be limited otherwise hotplug_memory_base + maxmem can
overflow(in dimm_get_free_addr()).
Re: [Qemu-devel] [PATCH 33/35] pc: ACPI BIOS: reserve SRAT entry for hotplug mem hole
On Tue, Apr 15, 2014 at 05:55:22PM +0200, Igor Mammedov wrote:
On Tue, 15 Apr 2014 14:37:01 +0800
Hu Tao hu...@cn.fujitsu.com wrote:
On Mon, Apr 14, 2014 at 06:44:42PM +0200, Igor Mammedov wrote:
On Mon, 14 Apr 2014 15:25:01 +0800
Hu Tao hu...@cn.fujitsu.com wrote:
On Fri, Apr 04, 2014 at 03:36:58PM +0200, Igor Mammedov wrote:
Needed for Windows to use hotplugged memory device, otherwise
it complains that server is not configured for memory hotplug.
Tests shows that aftewards it uses dynamically provided
proximity value from _PXM() method if available.
Signed-off-by: Igor Mammedov imamm...@redhat.com
---
hw/i386/acpi-build.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index ef89e99..012b100 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -1197,6 +1197,8 @@ build_srat(GArray *table_data, GArray *linker,
uint64_t curnode;
int srat_start, numa_start, slots;
uint64_t mem_len, mem_base, next_base;
+PCMachineState *pcms = PC_MACHINE(qdev_get_machine());
+ram_addr_t hotplug_as_size =
memory_region_size(pcms-hotplug_memory);
srat_start = table_data-len;
@@ -1261,6 +1263,18 @@ build_srat(GArray *table_data, GArray *linker,
acpi_build_srat_memory(numamem, 0, 0, 0,
MEM_AFFINITY_NOFLAGS);
}
+/*
+ * Fake entry required by Windows to enable memory hotplug in OS.
+ * Individual DIMM devices override proximity set here via _PXM
method,
+ * which returns associated with it NUMA node id.
+ */
+if (hotplug_as_size) {
+numamem = acpi_data_push(table_data, sizeof *numamem);
+acpi_build_srat_memory(numamem, pcms-hotplug_memory_base,
+ hotplug_as_size, 0,
MEM_AFFINITY_HOTPLUGGABLE |
+ MEM_AFFINITY_ENABLED);
+}
+
Hi Igor,
With the faked entry, memory unplug doesn't work. Entries should be set
up for each node with correct flags(enable, hotpluggable) to make memory
unplug work.
Could you be more specific, what and how doesn't work and why there is
need for SRAT entries per DIMM?
I've briefly tested with your unplug patches and linux seemed be ok with
unplug,
i.e. device node was removed from /sys after receiving remove
notification.
Following are fail cases:
I did some testing using upstream kernel with hot-remove enabled.
tested only this patch case
+--
guest commands |
this patch| hacked SRAT
+--
echo 'online' /sys/devices/system/memory/memory32/state \ |
|
echo 'offline' /sys/devices/system/memory/memory32/state |
fail | success
works for me, but it might/allowed to fail offline since page
migration may fail if memory section or its part is not movable.
You're right. More tests(latest kernel) show that offline memory
randomly success and fail in both cases.
+--
echo 'online' /sys/devices/system/memory/memory32/state \ |
|
echo 1 /sys/devices/LNXSYSTM\:00/device\:00/PNP0C80\:00/eject |
fail | success
the same as #1
+--
echo 'online_movable' /sys/devices/system/memory/memory32/state |
fail[first memory block] | fail
it's linux implementation specific, should be fixed in guest and has
nothing to do with qemu side.
PS: all hot-added memory sections could be onlined with 'online_movable'
in reverse order.
Correct.
+--
echo 'online_movable' /sys/devices/system/memory/memory35/state \ |
|
echo 'offline' /sys/devices/system/memory/memory35/state |
success[last memory block] | success
+--
echo 'online_movable' /sys/devices/system/memory/memory32/state \ |
|
echo 1 /sys/devices/LNXSYSTM\:00/device\:00/PNP0C80\:00/eject
[Qemu-devel] [PATCH] ivshmem: fix potential OOB r/w access
Fix OOB access via malformed incoming_posn parameters
and check that requested memory is actually alloced.
Signed-off-by: Sebastian Krahmer krah...@suse.de
---
diff --git a/hw/misc/ivshmem.c b/hw/misc/ivshmem.c
index 8d144ba..f58356e 100644
--- a/hw/misc/ivshmem.c
+++ b/hw/misc/ivshmem.c
@@ -28,6 +28,7 @@
#include sys/mman.h
#include sys/types.h
+#include limits.h
#define PCI_VENDOR_ID_IVSHMEM PCI_VENDOR_ID_REDHAT_QUMRANET
#define PCI_DEVICE_ID_IVSHMEM 0x1110
@@ -401,23 +402,34 @@ static void close_guest_eventfds(IVShmemState *s, int
posn)
/* this function increase the dynamic storage need to store data about other
* guests */
-static void increase_dynamic_storage(IVShmemState *s, int new_min_size) {
+static int increase_dynamic_storage(IVShmemState *s, int new_min_size) {
int j, old_nb_alloc;
+/* check for integer overflow */
+if (new_min_size = INT_MAX/sizeof(Peer) - 1 || new_min_size = 0)
+return -1;
+
old_nb_alloc = s-nb_peers;
-while (new_min_size = s-nb_peers)
-s-nb_peers = s-nb_peers * 2;
+/* heap allocators already have good alloc strategies, no need
+ * to re-implement here. +1 because #new_min_size is used as last array
index */
+if (new_min_size = s-nb_peers)
+s-nb_peers = new_min_size + 1;
+else
+return 0;
IVSHMEM_DPRINTF(bumping storage to %d guests\n, s-nb_peers);
s-peers = g_realloc(s-peers, s-nb_peers * sizeof(Peer));
+if (!s-peers)
+return -1;
/* zero out new pointers */
for (j = old_nb_alloc; j s-nb_peers; j++) {
s-peers[j].eventfds = NULL;
s-peers[j].nb_eventfds = 0;
}
+return 0;
}
static void ivshmem_read(void *opaque, const uint8_t * buf, int flags)
@@ -428,13 +440,19 @@ static void ivshmem_read(void *opaque, const uint8_t *
buf, int flags)
long incoming_posn;
memcpy(incoming_posn, buf, sizeof(long));
+if (incoming_posn -1) {
+fprintf(stderr, invalid posn index\n);
+return;
+}
/* pick off s-server_chr-msgfd and store it, posn should accompany msg */
tmp_fd = qemu_chr_fe_get_msgfd(s-server_chr);
IVSHMEM_DPRINTF(posn is %ld, fd is %d\n, incoming_posn, tmp_fd);
-
/* make sure we have enough space for this guest */
if (incoming_posn = s-nb_peers) {
-increase_dynamic_storage(s, incoming_posn);
+if (increase_dynamic_storage(s, incoming_posn) 0) {
+fprintf(stderr, could not allocate memory\n);
+return;
+}
}
if (tmp_fd == -1) {
--
~ perl self.pl
~ $_='print\$_=\47$_\47;eval';eval
~ krah...@suse.de - SuSE Security Team
[Qemu-devel] [Bug 1308381] [NEW] illegal instructions for AArch64 ARMv8
Public bug reported: The test case is in the attachment. To reproduce as following (I tried both GCC and Clang): $aarch64-linux-gnu-gcc qemu.c -o test $./test qemu: uncaught target signal 4 (Illegal instruction) - core dumped Illegal instruction (core dumped) In the test case, 3 intrinsics are tested: vqmovunh_s16, vqmovuns_s32, vqmovund_s64. They will be compiled into instructions: SQXTUN Bd, Hn SQXTUN Hd, Sn SQXTUN Sd, Dn. It seems that these instructions are not supported in QEMU. Is this a bug? ** Affects: qemu Importance: Undecided Status: New ** Attachment added: qemu.c https://bugs.launchpad.net/bugs/1308381/+attachment/4085154/+files/qemu.c ** Description changed: The test case is in the attachment. To reproduce as following (I tried both GCC and Clang): $aarch64-linux-gnu-gcc qemu.c -o test $./test qemu: uncaught target signal 4 (Illegal instruction) - core dumped Illegal instruction (core dumped) - There are 3 intrinsics are tested in the test case: vqmovunh_s16, vqmovuns_s32, vqmovund_s64. They will be compiled into instructions: + + In the test case, 3 intrinsics are tested: vqmovunh_s16, vqmovuns_s32, vqmovund_s64. They will be compiled into instructions: SQXTUN Bd, Hn SQXTUN Hd, Sn SQXTUN Sd, Dn. It seems that these instructions are not supported in QEMU. Is this a bug? -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1308381 Title: illegal instructions for AArch64 ARMv8 Status in QEMU: New Bug description: The test case is in the attachment. To reproduce as following (I tried both GCC and Clang): $aarch64-linux-gnu-gcc qemu.c -o test $./test qemu: uncaught target signal 4 (Illegal instruction) - core dumped Illegal instruction (core dumped) In the test case, 3 intrinsics are tested: vqmovunh_s16, vqmovuns_s32, vqmovund_s64. They will be compiled into instructions: SQXTUN Bd, Hn SQXTUN Hd, Sn SQXTUN Sd, Dn. It seems that these instructions are not supported in QEMU. Is this a bug? To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1308381/+subscriptions
[Qemu-devel] [Bug 1308381] Re: illegal instructions for AArch64 ARMv8
** Description changed: The test case is in the attachment. To reproduce as following (I tried both GCC and Clang): $aarch64-linux-gnu-gcc qemu.c -o test $./test qemu: uncaught target signal 4 (Illegal instruction) - core dumped Illegal instruction (core dumped) - In the test case, 3 intrinsics are tested: vqmovunh_s16, vqmovuns_s32, vqmovund_s64. They will be compiled into instructions: SQXTUN Bd, Hn SQXTUN Hd, Sn SQXTUN Sd, Dn. - It seems that these instructions are not supported in QEMU. Is this a - bug? + QEMU is get from trunk git://git.qemu.org/qemu.git. Other instructions + work well. It seems that these instructions are not supported in QEMU. + Is this a bug? -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1308381 Title: illegal instructions for AArch64 ARMv8 Status in QEMU: New Bug description: The test case is in the attachment. To reproduce as following (I tried both GCC and Clang): $aarch64-linux-gnu-gcc qemu.c -o test $./test qemu: uncaught target signal 4 (Illegal instruction) - core dumped Illegal instruction (core dumped) In the test case, 3 intrinsics are tested: vqmovunh_s16, vqmovuns_s32, vqmovund_s64. They will be compiled into instructions: SQXTUN Bd, Hn SQXTUN Hd, Sn SQXTUN Sd, Dn. QEMU is get from trunk git://git.qemu.org/qemu.git. Other instructions work well. It seems that these instructions are not supported in QEMU. Is this a bug? To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1308381/+subscriptions
[Qemu-devel] smp support in mips64
I am trying to add smp support in octeon-mips by usnig QEM-1.0.1. My octeon guest is not initializing secondary cores. QEMU monitor show (qemu) info cpus * CPU #0: PC=0xc0031d04 thread_id=12661 CPU #1: PC=0xbfc00380 thread_id=12660 Can anyone have any idea about this issue? -- Maryyam Muhammad Din Al-Khawarizmi Institute of Computer Science UET LahoreU
[Qemu-devel] [Bug 1308381] Re: illegal instructions for AArch64 ARMv8
Can you attach a statically linked test case binary, please? -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1308381 Title: illegal instructions for AArch64 ARMv8 Status in QEMU: New Bug description: The test case is in the attachment. To reproduce as following (I tried both GCC and Clang): $aarch64-linux-gnu-gcc qemu.c -o test $./test qemu: uncaught target signal 4 (Illegal instruction) - core dumped Illegal instruction (core dumped) In the test case, 3 intrinsics are tested: vqmovunh_s16, vqmovuns_s32, vqmovund_s64. They will be compiled into instructions: SQXTUN Bd, Hn SQXTUN Hd, Sn SQXTUN Sd, Dn. QEMU is get from trunk git://git.qemu.org/qemu.git. Other instructions work well. It seems that these instructions are not supported in QEMU. Is this a bug? To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1308381/+subscriptions
Re: [Qemu-devel] [Qemu-ppc] [PATCH] target-ppc: Eliminate Magic Number MSR Masks
On 15.04.14 19:21, Tom Musta wrote: Use MSR mnemonics from cpu.h instead of magic numbers for the CPUPPCState.msr_mask initialization. There is one bit in the 401x2 (and subsequent) model that I could not find any documentation for. It is open coded at little endian bit position 20: pcc-msr_mask = (1ull 20) | (1ull MSR_KEY) | (1ull MSR_POW) | (1ull MSR_CE) | ... Signed-off-by: Tom Musta tommu...@gmail.com Thanks a lot for the cleanup! Applied to ppc-next. Alex
Re: [Qemu-devel] KVM call agenda for 2014-04-15
On 15.04.14 17:32, Eric Auger wrote: On 04/15/2014 04:55 PM, Alexander Graf wrote: On 04/15/2014 04:00 PM, Markus Armbruster wrote: Juan Quintela quint...@redhat.com writes: Juan Quintela quint...@redhat.com wrote: Hi Please, send any topic that you are interested in covering. Thanks, Juan. As there are no topics, no call. Did we have a call anyway? IRC log looks like we did... Yes, we did. Whoever attended, please reply with things I mixed up or forgot. Two topics: 1) pSeries IOMMU bus Live migration registers the name for a migration blob in register_savevm_live() through qdev bus enumeration. The IOMMUs in our pSeries machine don't live on any bus, so they all get the same name. That leads to problems when we change the order of -device arguments on the command line. One proposed solution to this is to create a bus for IOMMUs which allows us to give each IOMMU a unique name; patch is on the list. Another proposed solution is to give devices the chance to override their name themselves. IOMMUs do know their system wide unique ID and can easily generate a unique device name for themselves. If we keep names the way they were without this callback, we can stay backwards compatible for x86 and have our IOMMUs return unique names. 2) -device for non-PCI devices There are 2 reasons we want to create platform devices using -device on the command line. One is that Xilinx is trying to create a full machine from the command line. The other one is that we want VFIO for platform devices. a) IRQs The Anthony way of doing IRQ links between random devices is his stateful Pin object approach. Since Anthony is gone and it'd be a lot of refactoring, we don't deem this approach realistic. Andreas suggested that we could make every qemu_irq a QOM object that then gets a global name in the QOM hierarchy and can be addressed as connector for IRQ output lines of devices in the -device command line syntax. b) Memory Regions The Anthony approach was to turn memory regions into QOM objects. That allows to expose memory region links as QOM links. The currently proposed approach is to add a -sysbusdev (or -device) command line option that hard codedly puts memory region n of device x into address a of the physical address space. c) Device Granularity We talked about the granularity of VFIO platform devices per -device option. I was advocating that we should have a -device granularity that makes sense for the user, rather than individual separate components. The main reason for that is that we lose information about links of different components of a device when we make it separate devices. Hi Alex, all in last week [RFC v2 5/6] virt: Assign a VFIO platform device to a virt VM in QEMU command line, available in https://lists.gnu.org/archive/html/qemu-devel/2014-04/msg01419.html I proposed an implementation using this kind of option line -device vfio-platform,vfio_device=fff51000.ethernet,\ compat=calxeda/hb-xgmac,mmap-timeout-ms=1000 where the machine file, ie. virt.c does the bulk of the work to simplify the work for the end-user. For devices that are more complex than the Midway xgmac we could imagine to have some device specific code in virt.c. I am not satified with the implementation which calls the realize function twice. However on the principle, do you think this could make sense? That's one of the unsolved questions that we have outstanding. For the mapping I see 3 possible solutions: 1) Create a special platform bus that allows for dynamic memory region and irq placement according to children's properties 2) Loop through the QOM tree and search for unassigned devices, map them in the machine file 3) Detangle everything and do explicit links between 2 globally accessible objects somehow (-sysbusdev) The device tree generation should always happen by walking the QOM tree. Alex
Re: [Qemu-devel] [PATCH] target-ppc: Remove PVR check from migration
On 15.04.14 07:06, Alexey Kardashevskiy wrote:
Currently migration fails if CPU version (PVR register) is different
even a bit. This check is performed at the very end of migration when
device states are sent. This is too late for management software and
we need to provide a way for the user to make sure that migration
will succeed if QEMU is started with appropritate command line parameters.
This removes the PVR check.
This resets PVR to the default value as the existing VMSTATE record
for SPR array sends all 1024 registers unconditionally and overwrites
the destination PVR.
If the user wants some guarantees for migration to succeed, then
a CPU name or host CPU with a compat option (on its way to upsteam)
should be used and KVM or TCG is expected to fail on unsupported values
at the moment of QEMU start.
Cc: Bharata B Rao bhar...@linux.vnet.ibm.com
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
We should propably reset to the default value all SPRs which do not have
env-spr_cb[num]-oea_write callback initialized. Yes, in a separate patch.
What can it possibly break?
oea_write means that supervisor state can change the state. What about
registers like LPCR which are hypervisor privileged? Those wouldn't have
a callback, but still change thanks to H_SET_MODE, no?
Thanks, applied to ppc-next.
Alex
---
target-ppc/machine.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/target-ppc/machine.c b/target-ppc/machine.c
index 063b379..df7cfc5 100644
--- a/target-ppc/machine.c
+++ b/target-ppc/machine.c
@@ -160,6 +160,11 @@ static int cpu_post_load(void *opaque, int version_id)
CPUPPCState *env = cpu-env;
int i;
+/*
+ * We always ignore the source PVR. The user or management
+ * software has to take care of running QEMU in a compatible mode.
+ */
+env-spr[SPR_PVR] = env-spr_cb[SPR_PVR].default_value;
env-lr = env-spr[SPR_LR];
env-ctr = env-spr[SPR_CTR];
env-xer = env-spr[SPR_XER];
@@ -471,8 +476,7 @@ const VMStateDescription vmstate_ppc_cpu = {
.pre_save = cpu_pre_save,
.post_load = cpu_post_load,
.fields = (VMStateField []) {
-/* Verify we haven't changed the pvr */
-VMSTATE_UINTTL_EQUAL(env.spr[SPR_PVR], PowerPCCPU),
+VMSTATE_UNUSED(sizeof(target_ulong)), /* was _EQUAL(env.spr[SPR_PVR])
*/
/* User mode architected state */
VMSTATE_UINTTL_ARRAY(env.gpr, PowerPCCPU, 32),
Re: [Qemu-devel] [Bug 1308381] Re: illegal instructions for AArch64ARMv88
Peter Maydell peter.mayd...@linaro.org writes:
Can you attach a statically linked test case binary, please?
I can reproduce with the source file. It looks like:
@@ -7553,12 +7555,9 @@ static void disas_simd_scalar_two_reg_misc(DisasContext
*s, uint32_t insn)
}
break;
case 0x12: /* SQXTUN */
-if (u) {
-unallocated_encoding(s);
-return;
-}
/* fall through */
Fixes it. Let me check why this slipped through the risu tests and
re-validate. I'll submit a patch once I've double checked.
--
Alex Bennée
Re: [Qemu-devel] [Bug 1308381] Re: illegal instructions for AArch64ARMv88
On 16 April 2014 11:55, Alex Bennée alex.ben...@linaro.org wrote:
Peter Maydell peter.mayd...@linaro.org writes:
Can you attach a statically linked test case binary, please?
I can reproduce with the source file. It looks like:
@@ -7553,12 +7555,9 @@ static void
disas_simd_scalar_two_reg_misc(DisasContext *s, uint32_t insn)
}
break;
case 0x12: /* SQXTUN */
-if (u) {
-unallocated_encoding(s);
-return;
-}
/* fall through */
Fixes it.
However the ARM ARM, unless I'm misreading it, requires scalar-2-misc
SQXTUN to have U==1, so the correct fix should be to turn that if (u)
into if (!u) I think. (Opcode 0x12 u==0 isn't in the table so should undef.)
Better check we didn't make the same mistake in the vector-2-misc
decode as well.
thanks
-- PMM
Re: [Qemu-devel] [Bug 1308381] Re: illegal instructions for AArch64ARMv88
On 2014-04-16 11:59:58 +0100, Peter Maydell wrote:
On 16 April 2014 11:55, Alex Bennée alex.ben...@linaro.org wrote:
Peter Maydell peter.mayd...@linaro.org writes:
Can you attach a statically linked test case binary, please?
I can reproduce with the source file. It looks like:
@@ -7553,12 +7555,9 @@ static void
disas_simd_scalar_two_reg_misc(DisasContext *s, uint32_t insn)
}
break;
case 0x12: /* SQXTUN */
-if (u) {
-unallocated_encoding(s);
-return;
-}
/* fall through */
Fixes it.
However the ARM ARM, unless I'm misreading it, requires scalar-2-misc
SQXTUN to have U==1, so the correct fix should be to turn that if (u)
into if (!u) I think. (Opcode 0x12 u==0 isn't in the table so should undef.)
agree, was about to send a patch
Better check we didn't make the same mistake in the vector-2-misc
decode as well.
The vector sqxtun2? halfword to byte is used in libav and works as
expected.
Janne
Re: [Qemu-devel] [PATCH v6] spapr: Add support for time base offset migration
On 14.04.14 14:53, Alexey Kardashevskiy wrote:
This allows guests to have a different timebase origin from the host.
This is needed for migration, where a guest can migrate from one host
to another and the two hosts might have a different timebase origin.
However, the timebase seen by the guest must not go backwards, and
should go forwards only by a small amount corresponding to the time
taken for the migration.
This is only supported for recent POWER hardware which has the TBU40
(timebase upper 40 bits) register. That includes POWER6, 7, 8 but not
970.
This adds kvm_access_one_reg() to access a special register which is not
in env-spr. This requires kvm_set_one_reg/kvm_get_one_reg patch.
The feature must be present in the host kernel.
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
Changes:
v6:
* time_of_the_day is now time_of_the_day_ns and measured in nm instead of us
* VMSTATE_PPC_TIMEBASE_V supports versions now
v5:
* fixed multiple comments in cpu_ppc_get_adjusted_tb and merged it
into timebase_post_load()
* removed round_up(124) as KVM is expected to do this anyway
* removed @freq from migration stream
* renamed PPCTimebaseOffset to PPCTimebase
* CLOCKS_PER_SEC is used as a constant which 100us/s (man clock)
v4:
* made it per machine timebase offser rather than per CPU
v3:
* kvm_access_one_reg moved out to a separate patch
* tb_offset and host_timebase were replaced with guest_timebase as
the destionation does not really care of offset on the source
v2:
* bumped the vmstate_ppc_cpu version
* defined version for the env.tb_env field
---
hw/ppc/ppc.c | 78 ++
hw/ppc/spapr.c | 4 +--
include/hw/ppc/spapr.h | 1 +
target-ppc/cpu-qom.h | 16 +++
target-ppc/kvm.c | 5
trace-events | 3 ++
6 files changed, 105 insertions(+), 2 deletions(-)
diff --git a/hw/ppc/ppc.c b/hw/ppc/ppc.c
index 71df471..3be4d8c 100644
--- a/hw/ppc/ppc.c
+++ b/hw/ppc/ppc.c
@@ -29,9 +29,11 @@
#include sysemu/cpus.h
#include hw/timer/m48t59.h
#include qemu/log.h
+#include qemu/error-report.h
#include hw/loader.h
#include sysemu/kvm.h
#include kvm_ppc.h
+#include trace.h
//#define PPC_DEBUG_IRQ
//#define PPC_DEBUG_TB
@@ -49,6 +51,8 @@
# define LOG_TB(...) do { } while (0)
#endif
+#define NSEC_PER_SEC10LL
+
static void cpu_ppc_tb_stop (CPUPPCState *env);
static void cpu_ppc_tb_start (CPUPPCState *env);
@@ -829,6 +833,80 @@ static void cpu_ppc_set_tb_clk (void *opaque, uint32_t freq)
cpu_ppc_store_purr(cpu, 0xULL);
}
+static void timebase_pre_save(void *opaque)
+{
+PPCTimebase *tb = opaque;
+uint64_t ticks = cpu_get_real_ticks();
+PowerPCCPU *first_ppc_cpu = POWERPC_CPU(first_cpu);
+
+if (!first_ppc_cpu-env.tb_env) {
+error_report(No timebase object);
+return;
+}
+
+tb-time_of_the_day_ns = get_clock_realtime();
+/*
+ * tb_offset is only expected to be changed by migration so
+ * there is no need to update it from KVM here
+ */
+tb-guest_timebase = ticks + first_ppc_cpu-env.tb_env-tb_offset;
+}
+
+static int timebase_post_load(void *opaque, int version_id)
+{
+PPCTimebase *tb = opaque;
I think if we call this remote or so it becomes more obvious what data
this contains.
+CPUState *cpu;
+PowerPCCPU *first_ppc_cpu = POWERPC_CPU(first_cpu);
+int64_t tb_off_adj, tb_off;
+int64_t migration_duration_ns, migration_duration_tb, guest_tb, host_ns;
+unsigned long freq;
+
+if (!first_ppc_cpu-env.tb_env) {
+error_report(No timebase object);
+return -1;
+}
+
+freq = first_ppc_cpu-env.tb_env-tb_freq;
+/*
+ * Calculate timebase on the destination side of migration.
+ * The destination timebase must be not less than the source timebase.
+ * We try to adjust timebase by downtime if host clocks are not
+ * too much out of sync (1 second for now).
+ */
+host_ns = get_clock_realtime();
+migration_duration_ns = MIN(NSEC_PER_SEC, host_ns -
tb-time_of_the_day_ns);
+migration_duration_tb = muldiv64(migration_duration_ns, freq,
NSEC_PER_SEC);
+guest_tb = tb-guest_timebase + MIN(0, migration_duration_tb);
This means the shift has to be negative, or it gets truncated to 0, no?
What we really want is to have the time not go backwards, so we need
MAX, right? Or did I mess things up again? ;)
In fact, I think it would make things more obvious if we force
migration_duration_ns to always be between [0...1s] rather than force
migration_duration_ns to always be [inf...1s] and then guest_tb as
[0...inf].
+
+tb_off_adj = guest_tb - cpu_get_real_ticks();
+
+tb_off = first_ppc_cpu-env.tb_env-tb_offset;
+trace_ppc_tb_adjust(tb_off, tb_off_adj, tb_off_adj - tb_off,
+(tb_off_adj - tb_off) / freq);
+
+/* Set new offset to all CPUs */
+CPU_FOREACH(cpu) {
+
Re: [Qemu-devel] [PATCH 2/9] kvm: add kvm_enable_cap_{vm,vcpu}
On 14.04.14 18:48, Cornelia Huck wrote:
Provide helper functions for enabling capabilities (on a vcpu and on a vm).
Reviewed-by: Thomas Huth th...@linux.vnet.ibm.com
Signed-off-by: Cornelia Huck cornelia.h...@de.ibm.com
---
include/sysemu/kvm.h |4
kvm-all.c| 33 -
2 files changed, 36 insertions(+), 1 deletion(-)
diff --git a/include/sysemu/kvm.h b/include/sysemu/kvm.h
index 0bee1e8..2ff5ad3 100644
--- a/include/sysemu/kvm.h
+++ b/include/sysemu/kvm.h
@@ -294,6 +294,10 @@ bool kvm_arch_stop_on_emulation_error(CPUState *cpu);
int kvm_check_extension(KVMState *s, unsigned int extension);
+int kvm_enable_cap_vm(KVMState *s, unsigned int capability, ...);
+
+int kvm_enable_cap_vcpu(CPUState *cpu, unsigned int capability, ...);
+
uint32_t kvm_arch_get_supported_cpuid(KVMState *env, uint32_t function,
uint32_t index, int reg);
diff --git a/kvm-all.c b/kvm-all.c
index cd4111d..658e50c 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -501,7 +501,38 @@ int kvm_check_extension(KVMState *s, unsigned int
extension)
return ret;
}
-static int kvm_set_ioeventfd_mmio(int fd, hwaddr addr, uint32_t val,
+int kvm_enable_cap_vm(KVMState *s, unsigned int capability, ...)
+{
+struct kvm_enable_cap cap = {};
+va_list ap;
+int i;
+
+cap.cap = capability;
+va_start(ap, capability);
+for (i = 0; i 4; i++) {
+cap.args[i] = va_arg(ap, uint64_t);
Is this legit? Can we just pull items off the stack without running beyond?
Alex
+}
+va_end(ap);
+return kvm_vm_ioctl(s, KVM_ENABLE_CAP, cap);
+}
+
+int kvm_enable_cap_vcpu(CPUState *cpu, unsigned int capability, ...)
+{
+struct kvm_enable_cap cap = {};
+va_list ap;
+int i;
+
+cap.cap = capability;
+va_start(ap, capability);
+for (i = 0; i 4; i++) {
+cap.args[i] = va_arg(ap, uint64_t);
+}
+va_end(ap);
+return kvm_vcpu_ioctl(cpu, KVM_ENABLE_CAP, cap);
+}
+
+
+static int kvm_set_ioeventfd_mmio(int fd, uint32_t addr, uint32_t val,
bool assign, uint32_t size, bool datamatch)
{
int ret;
Re: [Qemu-devel] [PATCH 3/9] s390x: use kvm_enable_cap_vcpu()
On 14.04.14 18:48, Cornelia Huck wrote:
Make kvm_s390_enable_css_support() use new interface.
Signed-off-by: Cornelia Huck cornelia.h...@de.ibm.com
What I was trying to indicate with the convert users comment last time
was to convert non-s390 users :). After all, ENABLE_CAP is a
cross-architecture interface and we should treat it as such.
Alex
---
target-s390x/kvm.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/target-s390x/kvm.c b/target-s390x/kvm.c
index 56b9af7..fbdc1bb 100644
--- a/target-s390x/kvm.c
+++ b/target-s390x/kvm.c
@@ -910,12 +910,10 @@ void kvm_s390_crw_mchk(S390CPU *cpu)
void kvm_s390_enable_css_support(S390CPU *cpu)
{
-struct kvm_enable_cap cap = {};
int r;
/* Activate host kernel channel subsystem support. */
-cap.cap = KVM_CAP_S390_CSS_SUPPORT;
-r = kvm_vcpu_ioctl(CPU(cpu), KVM_ENABLE_CAP, cap);
+r = kvm_enable_cap_vcpu(CPU(cpu), KVM_CAP_S390_CSS_SUPPORT);
assert(r == 0);
}
Re: [Qemu-devel] [PATCH 4/9] s390x: Add I/O adapter registration.
On 14.04.14 18:48, Cornelia Huck wrote:
Register an I/O adapter interrupt source for when virtio-ccw devices start
using adapter interrupts.
Reviewed-by: Thomas Huth th...@linux.vnet.ibm.com
Signed-off-by: Cornelia Huck cornelia.h...@de.ibm.com
---
hw/intc/s390_flic.c | 59 +
hw/s390x/css.c| 51 ++
hw/s390x/css.h|4
hw/s390x/virtio-ccw.c |4
hw/s390x/virtio-ccw.h |1 +
target-s390x/cpu.h| 33 +++
6 files changed, 152 insertions(+)
diff --git a/hw/intc/s390_flic.c b/hw/intc/s390_flic.c
index b2ef3e3..c033c8a 100644
--- a/hw/intc/s390_flic.c
+++ b/hw/intc/s390_flic.c
@@ -21,6 +21,11 @@
#define FLIC_FAILED (-1UL)
#define FLIC_SAVEVM_VERSION 1
+static KVMS390FLICState *s390_get_flic(void)
+{
+return KVM_S390_FLIC(object_resolve_path(/machine/s390-flic, NULL));
+}
+
void s390_flic_init(void)
{
DeviceState *dev;
@@ -148,6 +153,60 @@ static int __get_all_irqs(KVMS390FLICState *flic,
return r;
}
+int kvm_s390_register_io_adapter(uint32_t id, uint8_t isc, bool swap,
+ bool is_maskable)
+{
+struct kvm_s390_io_adapter adapter = {
+.id = id,
+.isc = isc,
+.maskable = is_maskable,
+.swap = swap,
+};
+KVMS390FLICState *flic = s390_get_flic();
+int r, ret;
+struct kvm_device_attr attr = {
+.group = KVM_DEV_FLIC_ADAPTER_REGISTER,
+.addr = (uint64_t)adapter,
+};
+
+if (!flic) {
+return -ENOSYS;
+}
+if (!kvm_check_extension(kvm_state, KVM_CAP_IRQ_ROUTING)) {
+return -ENOSYS;
+}
+
+r = ioctl(flic-fd, KVM_SET_DEVICE_ATTR, attr);
+
+ret = r ? -errno : 0;
+return ret;
+}
+
+int kvm_s390_io_adapter_map(uint32_t id, uint64_t map_addr, bool do_map)
+{
+struct kvm_s390_io_adapter_req req = {
+.id = id,
+.type = do_map ? KVM_S390_IO_ADAPTER_MAP : KVM_S390_IO_ADAPTER_UNMAP,
+.addr = map_addr,
+};
+KVMS390FLICState *flic = s390_get_flic();
+struct kvm_device_attr attr = {
+.group = KVM_DEV_FLIC_ADAPTER_MODIFY,
+.addr = (uint64_t)req,
+};
+int r;
+
+if (!flic) {
+return -ENOSYS;
+}
+if (!kvm_check_extension(kvm_state, KVM_CAP_IRQ_ROUTING)) {
+return -ENOSYS;
+}
+
+r = ioctl(flic-fd, KVM_SET_DEVICE_ATTR, attr);
+return r ? -errno : 0;
+}
+
/**
* kvm_flic_save - Save pending floating interrupts
* @f: QEMUFile containing migration state
diff --git a/hw/s390x/css.c b/hw/s390x/css.c
index 7074d2b..a6d173f 100644
--- a/hw/s390x/css.c
+++ b/hw/s390x/css.c
@@ -39,6 +39,13 @@ typedef struct CssImage {
ChpInfo chpids[MAX_CHPID + 1];
} CssImage;
+typedef struct IoAdapter {
+uint32_t id;
+uint8_t type;
+uint8_t isc;
+QTAILQ_ENTRY(IoAdapter) sibling;
+} IoAdapter;
+
typedef struct ChannelSubSys {
QTAILQ_HEAD(, CrwContainer) pending_crws;
bool do_crw_mchk;
@@ -49,6 +56,7 @@ typedef struct ChannelSubSys {
uint64_t chnmon_area;
CssImage *css[MAX_CSSID + 1];
uint8_t default_cssid;
+QTAILQ_HEAD(, IoAdapter) io_adapters;
} ChannelSubSys;
static ChannelSubSys *channel_subsys;
@@ -69,6 +77,48 @@ int css_create_css_image(uint8_t cssid, bool default_image)
return 0;
}
+int css_register_io_adapter(uint8_t type, uint8_t isc, bool swap,
+bool maskable, uint32_t *id)
+{
+IoAdapter *adapter;
+bool found = false;
+int ret;
+
+*id = 0;
+QTAILQ_FOREACH(adapter, channel_subsys-io_adapters, sibling) {
+if ((adapter-type == type) (adapter-isc == isc)) {
+*id = adapter-id;
+found = true;
+ret = 0;
+break;
+}
+if (adapter-id = *id) {
+*id = adapter-id + 1;
+}
+}
+if (found) {
+goto out;
+}
+adapter = g_new0(IoAdapter, 1);
+ret = s390_register_io_adapter(*id, isc, swap, maskable);
+if (ret == -ENOSYS) {
+/* Keep adapter even if we didn't register it anywhere. */
+ret = 0;
+}
+if (ret == 0) {
+adapter-id = *id;
+adapter-isc = isc;
+adapter-type = type;
+QTAILQ_INSERT_TAIL(channel_subsys-io_adapters, adapter, sibling);
+} else {
+g_free(adapter);
+fprintf(stderr, Unexpected error %d when registering adapter %d\n,
+ret, *id);
+}
+out:
+return ret;
+}
+
uint16_t css_build_subchannel_id(SubchDev *sch)
{
if (channel_subsys-max_cssid 0) {
@@ -1239,6 +1289,7 @@ static void css_init(void)
channel_subsys-do_crw_mchk = true;
channel_subsys-crws_lost = false;
channel_subsys-chnmon_active = false;
+QTAILQ_INIT(channel_subsys-io_adapters);
}
machine_init(css_init);
diff --git a/hw/s390x/css.h b/hw/s390x/css.h
index e9b4405..380e8e7
[Qemu-devel] [PATCH] target-arm: A64: fix unallocated test of scalar SQXTUN
The test for the U bit was incorrectly inverted in the scalar case of SQXTUN.
This doesn't affect the vector case as the U bit is used to select XTN(2).
Reported-by: Hao Liu hao@arm.com
Signed-off-by: Alex Bennée alex.ben...@linaro.org
---
target-arm/translate-a64.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target-arm/translate-a64.c b/target-arm/translate-a64.c
index a74128c..0adffbb 100644
--- a/target-arm/translate-a64.c
+++ b/target-arm/translate-a64.c
@@ -7553,7 +7553,7 @@ static void disas_simd_scalar_two_reg_misc(DisasContext
*s, uint32_t insn)
}
break;
case 0x12: /* SQXTUN */
-if (u) {
+if (!u) {
unallocated_encoding(s);
return;
}
--
1.9.2
Re: [Qemu-devel] [PATCH 6/9] s390x/virtio-ccw: Wire up irq routing and irqfds.
On 14.04.14 18:48, Cornelia Huck wrote:
Make use of the new s390 adapter irq routing support to enable real
in-kernel irqfds for virtio-ccw with adapter interrupts.
Note that s390 doesn't provide the common KVM_CAP_IRQCHIP capability, but
rather needs KVM_CAP_S390_IRQCHIP to be enabled. This is to ensure backward
compatibility.
Reviewed-by: Thomas Huth th...@linux.vnet.ibm.com
Signed-off-by: Cornelia Huck cornelia.h...@de.ibm.com
---
hw/s390x/virtio-ccw.c | 165
hw/s390x/virtio-ccw.h |2 +
include/hw/s390x/adapter.h | 23 ++
include/qemu/typedefs.h|1 +
include/sysemu/kvm.h |2 +
kvm-all.c | 38 +-
kvm-stub.c |5 ++
target-s390x/kvm.c |5 ++
8 files changed, 228 insertions(+), 13 deletions(-)
create mode 100644 include/hw/s390x/adapter.h
diff --git a/hw/s390x/virtio-ccw.c b/hw/s390x/virtio-ccw.c
index 69efa6c..5612ccc 100644
--- a/hw/s390x/virtio-ccw.c
+++ b/hw/s390x/virtio-ccw.c
@@ -21,6 +21,7 @@
#include hw/sysbus.h
#include qemu/bitops.h
#include hw/virtio/virtio-bus.h
+#include hw/s390x/adapter.h
#include ioinst.h
#include css.h
@@ -48,7 +49,7 @@ static IndAddr *get_indicator(hwaddr ind_addr, int len)
return indicator;
}
-static void release_indicator(IndAddr *indicator)
+static void release_indicator(uint32_t adapter_id, IndAddr *indicator)
{
assert(indicator-refcnt 0);
indicator-refcnt--;
@@ -56,9 +57,31 @@ static void release_indicator(IndAddr *indicator)
return;
}
QTAILQ_REMOVE(indicator_addresses, indicator, sibling);
+if (indicator-map) {
+s390_io_adapter_map(adapter_id, indicator-map, false);
+}
g_free(indicator);
}
+static int map_indicator(uint32_t adapter_id, IndAddr *indicator)
+{
+int ret;
+
+if (indicator-map) {
+return 0; /* already mapped is not an error */
+}
+indicator-map = indicator-addr;
+ret = s390_io_adapter_map(adapter_id, indicator-map, true);
+if ((ret != 0) (ret != -ENOSYS)) {
+goto out_err;
+}
+return 0;
+
+out_err:
+indicator-map = 0;
+return -EFAULT;
+}
+
static void virtio_ccw_bus_new(VirtioBusState *bus, size_t bus_size,
VirtioCcwDevice *dev);
@@ -733,7 +756,7 @@ static int virtio_ccw_exit(VirtioCcwDevice *dev)
g_free(sch);
}
if (dev-indicators) {
-release_indicator(dev-indicators);
+release_indicator(dev-adapter_id, dev-indicators);
dev-indicators = NULL;
}
return 0;
@@ -1034,15 +1057,15 @@ static void virtio_ccw_reset(DeviceState *d)
virtio_reset(vdev);
css_reset_sch(dev-sch);
if (dev-indicators) {
-release_indicator(dev-indicators);
+release_indicator(dev-adapter_id, dev-indicators);
dev-indicators = NULL;
}
if (dev-indicators2) {
-release_indicator(dev-indicators2);
+release_indicator(dev-adapter_id, dev-indicators2);
dev-indicators2 = NULL;
}
if (dev-summary_indicator) {
-release_indicator(dev-summary_indicator);
+release_indicator(dev-adapter_id, dev-summary_indicator);
dev-summary_indicator = NULL;
}
}
@@ -1078,6 +1101,100 @@ static int virtio_ccw_set_host_notifier(DeviceState *d,
int n, bool assign)
return virtio_ccw_set_guest2host_notifier(dev, n, assign, false);
}
+static int virtio_ccw_get_adapter_info(VirtioCcwDevice *dev,
+ AdapterInfo *adapter)
+{
+int r;
+
+if (!dev-sch-thinint_active) {
+return -EINVAL;
+}
+
+r = map_indicator(dev-adapter_id, dev-summary_indicator);
+if (r) {
+return r;
+}
+r = map_indicator(dev-adapter_id, dev-indicators);
+if (r) {
+return r;
+}
+adapter-summary_addr = dev-summary_indicator-map;
+adapter-ind_addr = dev-indicators-map;
+adapter-ind_offset = dev-ind_bit;
+adapter-summary_offset = 7;
+adapter-adapter_id = dev-adapter_id;
+
+return 0;
+}
+
+static int virtio_ccw_setup_irqroutes(VirtioCcwDevice *dev, int nvqs)
+{
+int i;
+VirtIODevice *vdev = virtio_bus_get_device(dev-bus);
+int ret;
+AdapterInfo adapter;
+
+ret = virtio_ccw_get_adapter_info(dev, adapter);
+if (ret) {
+return ret;
+}
+for (i = 0; i nvqs; i++) {
+if (!virtio_queue_get_num(vdev, i)) {
+break;
+}
+ret = kvm_irqchip_add_adapter_route(kvm_state, adapter);
Why is interrupt routing code in virtio-ccw.c? Shouldn't that live in
the flic?
Alex
Re: [Qemu-devel] [PATCH 9/9] s390x/kvm: sync gbea and pp register
On 14.04.14 18:48, Cornelia Huck wrote:
From: Christian Borntraeger borntrae...@de.ibm.com
We also need to sync guest breaking event address and program parameter
register for migration support.
Signed-off-by: Christian Borntraeger borntrae...@de.ibm.com
Reviewed-by: Jason J. Herne jjhe...@us.ibm.com
Reviewed-by: Thomas Huth th...@linux.vnet.ibm.com
Signed-off-by: Cornelia Huck cornelia.h...@de.ibm.com
---
target-s390x/cpu.h |3 +++
target-s390x/kvm.c | 24
2 files changed, 27 insertions(+)
diff --git a/target-s390x/cpu.h b/target-s390x/cpu.h
index 53391fd..55ef6d3 100644
--- a/target-s390x/cpu.h
+++ b/target-s390x/cpu.h
@@ -126,6 +126,9 @@ typedef struct CPUS390XState {
uint64_t pfault_compare;
uint64_t pfault_select;
+uint64_t gbea;
+uint64_t pp;
+
CPU_COMMON
/* reset does memset(0) up to here */
diff --git a/target-s390x/kvm.c b/target-s390x/kvm.c
index ec1ce2f..03d61d3 100644
--- a/target-s390x/kvm.c
+++ b/target-s390x/kvm.c
@@ -204,6 +204,18 @@ int kvm_arch_put_registers(CPUState *cs, int level)
}
}
+reg.id = KVM_REG_S390_GBEA;
+reg.addr = (__u64) env-gbea;
+if (kvm_vcpu_ioctl(cs, KVM_SET_ONE_REG, reg)) {
Maybe we should have helpers for SET_ONE_REG and GET_ONE_REG as well ;).
Those could even contain the traces ;).
Alex
+trace_kvm_failed_reg_set(reg.id, strerror(errno));
+}
+
+reg.id = KVM_REG_S390_PP;
+reg.addr = (__u64) env-pp;
+if (kvm_vcpu_ioctl(cs, KVM_SET_ONE_REG, reg)) {
+trace_kvm_failed_reg_set(reg.id, strerror(errno));
+}
+
if (cap_sync_regs
cs-kvm_run-kvm_valid_regs KVM_SYNC_ACRS
cs-kvm_run-kvm_valid_regs KVM_SYNC_CRS) {
@@ -305,6 +317,18 @@ int kvm_arch_get_registers(CPUState *cs)
trace_kvm_failed_reg_get(reg.id, strerror(errno));
}
+reg.id = KVM_REG_S390_GBEA;
+reg.addr = (__u64) env-gbea;
+if (kvm_vcpu_ioctl(cs, KVM_GET_ONE_REG, reg)) {
+trace_kvm_failed_reg_get(reg.id, strerror(errno));
+}
+
+reg.id = KVM_REG_S390_PP;
+reg.addr = (__u64) env-pp;
+if (kvm_vcpu_ioctl(cs, KVM_GET_ONE_REG, reg)) {
+trace_kvm_failed_reg_get(reg.id, strerror(errno));
+}
+
if (cap_async_pf) {
reg.id = KVM_REG_S390_PFTOKEN;
reg.addr = (__u64)(env-pfault_token);
Re: [Qemu-devel] [PATCH] target-arm: A64: fix unallocated test of scalar SQXTUN
On 16.04.2014 13:29, Alex Bennée wrote:
The test for the U bit was incorrectly inverted in the scalar case of SQXTUN.
This doesn't affect the vector case as the U bit is used to select XTN(2).
Reported-by: Hao Liu hao@arm.com
Signed-off-by: Alex Bennée alex.ben...@linaro.org
---
target-arm/translate-a64.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target-arm/translate-a64.c b/target-arm/translate-a64.c
index a74128c..0adffbb 100644
--- a/target-arm/translate-a64.c
+++ b/target-arm/translate-a64.c
@@ -7553,7 +7553,7 @@ static void disas_simd_scalar_two_reg_misc(DisasContext
*s, uint32_t insn)
}
break;
case 0x12: /* SQXTUN */
-if (u) {
+if (!u) {
unallocated_encoding(s);
return;
}
Reviewed-by: Claudio Fontana claudio.font...@huawei.com
Re: [Qemu-devel] [PATCH 1/1] ppc: use kvm_enable_cap_vcpu()
On 14.04.14 18:48, Cornelia Huck wrote: Convert existing users of KVM_ENABLE_CAP to new helper. Signed-off-by: Cornelia Huck cornelia.h...@de.ibm.com Ah, you made the ppc patch separate. I would prefer if we had one patch set that introduces the helper and converts every arch in follow-up patches. Then your s390x patch set can just have a comment in the cover letter saying depends on the other patch set :). Reviewed-by: Alexander Graf ag...@suse.de Alex
Re: [Qemu-devel] [PATCH 2/9] kvm: add kvm_enable_cap_{vm,vcpu}
On 16.04.2014, at 13:22, Alexander Graf ag...@suse.de wrote:
On 14.04.14 18:48, Cornelia Huck wrote:
Provide helper functions for enabling capabilities (on a vcpu and on a vm).
Reviewed-by: Thomas Huth th...@linux.vnet.ibm.com
Signed-off-by: Cornelia Huck cornelia.h...@de.ibm.com
---
include/sysemu/kvm.h |4
kvm-all.c| 33 -
2 files changed, 36 insertions(+), 1 deletion(-)
diff --git a/include/sysemu/kvm.h b/include/sysemu/kvm.h
index 0bee1e8..2ff5ad3 100644
--- a/include/sysemu/kvm.h
+++ b/include/sysemu/kvm.h
@@ -294,6 +294,10 @@ bool kvm_arch_stop_on_emulation_error(CPUState *cpu);
int kvm_check_extension(KVMState *s, unsigned int extension);
+int kvm_enable_cap_vm(KVMState *s, unsigned int capability, ...);
+
+int kvm_enable_cap_vcpu(CPUState *cpu, unsigned int capability, ...);
+
uint32_t kvm_arch_get_supported_cpuid(KVMState *env, uint32_t function,
uint32_t index, int reg);
diff --git a/kvm-all.c b/kvm-all.c
index cd4111d..658e50c 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -501,7 +501,38 @@ int kvm_check_extension(KVMState *s, unsigned int
extension)
return ret;
}
-static int kvm_set_ioeventfd_mmio(int fd, hwaddr addr, uint32_t val,
+int kvm_enable_cap_vm(KVMState *s, unsigned int capability, ...)
+{
+struct kvm_enable_cap cap = {};
+va_list ap;
+int i;
+
+cap.cap = capability;
+va_start(ap, capability);
+for (i = 0; i 4; i++) {
+cap.args[i] = va_arg(ap, uint64_t);
Is this legit? Can we just pull items off the stack without running beyond?
For inspiration on how to know the number of arguments that got passed in,
check out
http://git.qemu.org/?p=qemu.git;a=blob;f=include/sysemu/device_tree.h#l40
Alex
[Qemu-devel] [Bug 1308381] Re: illegal instructions for AArch64 ARMv8
@pmaydell: yeah vector is unaffected as U is used to select another opcode. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1308381 Title: illegal instructions for AArch64 ARMv8 Status in QEMU: New Bug description: The test case is in the attachment. To reproduce as following (I tried both GCC and Clang): $aarch64-linux-gnu-gcc qemu.c -o test $./test qemu: uncaught target signal 4 (Illegal instruction) - core dumped Illegal instruction (core dumped) In the test case, 3 intrinsics are tested: vqmovunh_s16, vqmovuns_s32, vqmovund_s64. They will be compiled into instructions: SQXTUN Bd, Hn SQXTUN Hd, Sn SQXTUN Sd, Dn. QEMU is get from trunk git://git.qemu.org/qemu.git. Other instructions work well. It seems that these instructions are not supported in QEMU. Is this a bug? To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1308381/+subscriptions
[Qemu-devel] [Bug 1308381] Re: illegal instructions for AArch64 ARMv8
Fix identified ** Changed in: qemu Assignee: (unassigned) = Alex Bennée (ajbennee) -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1308381 Title: illegal instructions for AArch64 ARMv8 Status in QEMU: New Bug description: The test case is in the attachment. To reproduce as following (I tried both GCC and Clang): $aarch64-linux-gnu-gcc qemu.c -o test $./test qemu: uncaught target signal 4 (Illegal instruction) - core dumped Illegal instruction (core dumped) In the test case, 3 intrinsics are tested: vqmovunh_s16, vqmovuns_s32, vqmovund_s64. They will be compiled into instructions: SQXTUN Bd, Hn SQXTUN Hd, Sn SQXTUN Sd, Dn. QEMU is get from trunk git://git.qemu.org/qemu.git. Other instructions work well. It seems that these instructions are not supported in QEMU. Is this a bug? To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1308381/+subscriptions
[Qemu-devel] [Bug 1308381] Re: illegal instructions for AArch64 ARMv8
I've sent this patch to the mailing list but it fixes the attached test case and has been tested with risu patterns. ** Patch added: fix https://bugs.launchpad.net/qemu/+bug/1308381/+attachment/4085353/+files/0001-target-arm-A64-fix-unallocated-test-of-scalar-SQXTUN.patch -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1308381 Title: illegal instructions for AArch64 ARMv8 Status in QEMU: New Bug description: The test case is in the attachment. To reproduce as following (I tried both GCC and Clang): $aarch64-linux-gnu-gcc qemu.c -o test $./test qemu: uncaught target signal 4 (Illegal instruction) - core dumped Illegal instruction (core dumped) In the test case, 3 intrinsics are tested: vqmovunh_s16, vqmovuns_s32, vqmovund_s64. They will be compiled into instructions: SQXTUN Bd, Hn SQXTUN Hd, Sn SQXTUN Sd, Dn. QEMU is get from trunk git://git.qemu.org/qemu.git. Other instructions work well. It seems that these instructions are not supported in QEMU. Is this a bug? To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1308381/+subscriptions
Re: [Qemu-devel] [PATCH] target-arm: A64: fix unallocated test of scalar SQXTUN
On 16 April 2014 12:29, Alex Bennée alex.ben...@linaro.org wrote: The test for the U bit was incorrectly inverted in the scalar case of SQXTUN. This doesn't affect the vector case as the U bit is used to select XTN(2). Reported-by: Hao Liu hao@arm.com Signed-off-by: Alex Bennée alex.ben...@linaro.org Reviewed-by: Peter Maydell peter.mayd...@linaro.org Cc: qemu-sta...@nongnu.org -- PMM
Re: [Qemu-devel] [PATCH 1/7] megasas: Enable MSI-X support
On 16.04.14 09:16, Hannes Reinecke wrote: MSI-X support has been fixed in qemu, so we can enable it again. Signed-off-by: Hannes Reinecke h...@suse.de --- hw/scsi/megasas.c | 20 ++-- 1 file changed, 6 insertions(+), 14 deletions(-) diff --git a/hw/scsi/megasas.c b/hw/scsi/megasas.c index e6e1ffd..496bab8 100644 --- a/hw/scsi/megasas.c +++ b/hw/scsi/megasas.c @@ -29,7 +29,7 @@ #include mfi.h -#define MEGASAS_VERSION 1.70 +#define MEGASAS_VERSION 1.71 What happens when I create a VM on 2.0 and then run it with 2.1? Will the VM see a difference? Alex
Re: [Qemu-devel] [PATCH 5/7] megasas: Implement LD_LIST_QUERY
On 16.04.14 09:17, Hannes Reinecke wrote: New drivers implement a LD_LIST_QUERY command, and due to a driver issue no drives might be detected if this command isn't supported. So add emulation for this command, too. Signed-off-by: Hannes Reinecke h...@suse.de Should this go into stable? After all it would fix megasas in 2.0, no? Alex
Re: [Qemu-devel] [PATCH 0/7] megasas Update
On 16.04.14 09:16, Hannes Reinecke wrote: Hi all, here's an update to the megasas driver. I've re-enabled MSI-X support and added a new emulation mode 'megasas-gen2' which emulates the MegaRAID SAS 2108 HBA. The advantage here is that the original silicon supports both MSI-X and MSI, so some drivers (most notably windows) will refuse to enable MSI-X with the older emulation. To go with that I've also added MSI support. Also an issue has been fixed which caused the megasas driver not to present any disks with current linux kernel version. And some smaller fixes. Plus I've updated the MAINTAINERS file to declare this driver as supported. Apart from the nit on guest visible changes, this is Reviewed-by: Alexander Graf ag...@suse.de Alex
Re: [Qemu-devel] [PATCH 5/7] megasas: Implement LD_LIST_QUERY
On 04/16/2014 01:45 PM, Alexander Graf wrote: On 16.04.14 09:17, Hannes Reinecke wrote: New drivers implement a LD_LIST_QUERY command, and due to a driver issue no drives might be detected if this command isn't supported. So add emulation for this command, too. Signed-off-by: Hannes Reinecke h...@suse.de Should this go into stable? After all it would fix megasas in 2.0, no? Yes, presumably. (I'm not that familiar with qemu policies here) Cheers, Hannes -- Dr. Hannes Reinecke zSeries Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
Re: [Qemu-devel] [PATCH 5/7] megasas: Implement LD_LIST_QUERY
On 16.04.14 13:47, Hannes Reinecke wrote: On 04/16/2014 01:45 PM, Alexander Graf wrote: On 16.04.14 09:17, Hannes Reinecke wrote: New drivers implement a LD_LIST_QUERY command, and due to a driver issue no drives might be detected if this command isn't supported. So add emulation for this command, too. Signed-off-by: Hannes Reinecke h...@suse.de Should this go into stable? After all it would fix megasas in 2.0, no? Yes, presumably. (I'm not that familiar with qemu policies here) Usually it's the maintainer's responsibility to CC qemu-sta...@nongnu.org. However, it makes life easier for him if you could indicate that you'd like to see it in stable below a --- line in the patch description. Alex
Re: [Qemu-devel] [PATCH 1/7] megasas: Enable MSI-X support
On 04/16/2014 01:43 PM, Alexander Graf wrote: On 16.04.14 09:16, Hannes Reinecke wrote: MSI-X support has been fixed in qemu, so we can enable it again. Signed-off-by: Hannes Reinecke h...@suse.de --- hw/scsi/megasas.c | 20 ++-- 1 file changed, 6 insertions(+), 14 deletions(-) diff --git a/hw/scsi/megasas.c b/hw/scsi/megasas.c index e6e1ffd..496bab8 100644 --- a/hw/scsi/megasas.c +++ b/hw/scsi/megasas.c @@ -29,7 +29,7 @@ #include mfi.h -#define MEGASAS_VERSION 1.70 +#define MEGASAS_VERSION 1.71 What happens when I create a VM on 2.0 and then run it with 2.1? Will the VM see a difference? The only difference you'll see is a different PCI configuration. Other than that the behaviour will be identical. For compatible behaviour you'd need to set 'use_msix=false' in the megasas configuration. If this really is an issue I can re-sent the patch with defaulting back to 'false'. Cheers, Hannes -- Dr. Hannes Reinecke zSeries Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
Re: [Qemu-devel] [PATCH 1/7] megasas: Enable MSI-X support
On 16.04.14 13:49, Hannes Reinecke wrote: On 04/16/2014 01:43 PM, Alexander Graf wrote: On 16.04.14 09:16, Hannes Reinecke wrote: MSI-X support has been fixed in qemu, so we can enable it again. Signed-off-by: Hannes Reinecke h...@suse.de --- hw/scsi/megasas.c | 20 ++-- 1 file changed, 6 insertions(+), 14 deletions(-) diff --git a/hw/scsi/megasas.c b/hw/scsi/megasas.c index e6e1ffd..496bab8 100644 --- a/hw/scsi/megasas.c +++ b/hw/scsi/megasas.c @@ -29,7 +29,7 @@ #include mfi.h -#define MEGASAS_VERSION 1.70 +#define MEGASAS_VERSION 1.71 What happens when I create a VM on 2.0 and then run it with 2.1? Will the VM see a difference? The only difference you'll see is a different PCI configuration. Other than that the behaviour will be identical. Hrm. Can we keep this at 1.70 for the old PCI model and bump to 1.80 for the new one? For compatible behaviour you'd need to set 'use_msix=false' in the megasas configuration. If this really is an issue I can re-sent the patch with defaulting back to 'false'. I think it makes sense to default to false for the old device type only. Alex
Re: [Qemu-devel] [PATCH 2/9] kvm: add kvm_enable_cap_{vm,vcpu}
On Wed, 16 Apr 2014 13:38:27 +0200
Alexander Graf ag...@suse.de wrote:
On 16.04.2014, at 13:22, Alexander Graf ag...@suse.de wrote:
On 14.04.14 18:48, Cornelia Huck wrote:
Provide helper functions for enabling capabilities (on a vcpu and on a vm).
Reviewed-by: Thomas Huth th...@linux.vnet.ibm.com
Signed-off-by: Cornelia Huck cornelia.h...@de.ibm.com
---
include/sysemu/kvm.h |4
kvm-all.c| 33 -
2 files changed, 36 insertions(+), 1 deletion(-)
diff --git a/include/sysemu/kvm.h b/include/sysemu/kvm.h
index 0bee1e8..2ff5ad3 100644
--- a/include/sysemu/kvm.h
+++ b/include/sysemu/kvm.h
@@ -294,6 +294,10 @@ bool kvm_arch_stop_on_emulation_error(CPUState *cpu);
int kvm_check_extension(KVMState *s, unsigned int extension);
+int kvm_enable_cap_vm(KVMState *s, unsigned int capability, ...);
+
+int kvm_enable_cap_vcpu(CPUState *cpu, unsigned int capability, ...);
+
uint32_t kvm_arch_get_supported_cpuid(KVMState *env, uint32_t function,
uint32_t index, int reg);
diff --git a/kvm-all.c b/kvm-all.c
index cd4111d..658e50c 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -501,7 +501,38 @@ int kvm_check_extension(KVMState *s, unsigned int
extension)
return ret;
}
-static int kvm_set_ioeventfd_mmio(int fd, hwaddr addr, uint32_t val,
+int kvm_enable_cap_vm(KVMState *s, unsigned int capability, ...)
+{
+struct kvm_enable_cap cap = {};
+va_list ap;
+int i;
+
+cap.cap = capability;
+va_start(ap, capability);
+for (i = 0; i 4; i++) {
+cap.args[i] = va_arg(ap, uint64_t);
Is this legit? Can we just pull items off the stack without running beyond?
For inspiration on how to know the number of arguments that got passed in,
check out
http://git.qemu.org/?p=qemu.git;a=blob;f=include/sysemu/device_tree.h#l40
Ah, that is probably better than splattering args with random stuff.
Will try.
Re: [Qemu-devel] [PATCH 28/35] pc: propagate memory hotplug event to ACPI device
On Fri, Apr 11, 2014 at 11:14:00AM +0200, Igor Mammedov wrote:
On Mon, 7 Apr 2014 18:14:51 +0300
Michael S. Tsirkin m...@redhat.com wrote:
On Mon, Apr 07, 2014 at 04:32:16PM +0200, Igor Mammedov wrote:
On Mon, 7 Apr 2014 13:23:54 +0300
Michael S. Tsirkin m...@redhat.com wrote:
On Fri, Apr 04, 2014 at 03:36:53PM +0200, Igor Mammedov wrote:
Notify PIIX4_PM/ICH9LPC device about hotplug event,
so that it would send SCI to guest notifying about
newly added memory.
Signed-off-by: Igor Mammedov imamm...@redhat.com
---
hw/i386/pc.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 734c6ee..ee5cf88 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -60,6 +60,8 @@
#include acpi-build.h
#include hw/mem/dimm.h
#include trace.h
+#include hw/acpi/piix4.h
+#include hw/i386/ich9.h
/* debug PC/ISA interrupts */
//#define DEBUG_IRQ
@@ -1484,6 +1486,8 @@ void qemu_register_pc_machine(QEMUMachine *m)
static void pc_dimm_plug(HotplugHandler *hotplug_dev,
DeviceState *dev, Error **errp)
{
+Object *acpi_dev;
+HotplugHandlerClass *hhc;
Error *local_err = NULL;
PCMachineState *pcms = PC_MACHINE(hotplug_dev);
DimmDevice *dimm = DIMM(dev);
@@ -1517,10 +1521,19 @@ static void pc_dimm_plug(HotplugHandler
*hotplug_dev,
}
trace_mhp_pc_dimm_assigned_slot(dimm-slot);
+acpi_dev = (acpi_dev = piix4_pm_find()) ? acpi_dev :
ich9_lpc_find();
+if (!acpi_dev) {
+error_setg(local_err,
+ memory hotplug is not enabled: missing acpi
device);
+return;
+}
+
+hhc = HOTPLUG_HANDLER_GET_CLASS(acpi_dev);
How about simply looking for a hotplug handler type device instead?
We aren't likely to have many of these, are we?
How about adding linkacpi_device to PCMachine when it's created
and use it instead of piix4_pm_find()/ich9_lpc_find() everywhere?
that would allow to remove above searches in QOM tree and simplify
code including acpi-build.c
So each acpi implementation registers a link at a pre-defined path?
I'm fine with this, need an ack from afaerber though.
It could be a just plain pointer since it points to system device which
won't disappear suddenly (i.e. it's not hot-unplugable).
It would be nice to support removing them if we want to allow guests to
disable ACPI and switch to native hotplug.
memory_region_add_subregion(pcms-hotplug_memory,
addr - pcms-hotplug_memory_base,
mr);
vmstate_register_ram(mr, dev);
+hhc-plug(HOTPLUG_HANDLER(acpi_dev), dev, local_err);
out:
error_propagate(errp, local_err);
--
1.9.0
--
Regards,
Igor
Re: [Qemu-devel] QEMU 2.0 RC with Spice
On Apr 16, 2014 3:07 AM, Dr. David Alan Gilbert dgilb...@redhat.com wrote: * Rick Vernam (rtver...@hobi.com) wrote: On Tuesday 15 April 2014 19:25:22 Rick Vernam wrote: Looks like it's in Spice: snip old backtrace without symbols I'll see if I can build spice with debugging symbols and what not and write back with findings. Are others have problems with Qemu 2.0 RCs Spice? Here is how I started qemu with gdb: QEMU_AUDIO_DRV=spice TMPDIR=/home/rick/qemu/hds gdb --args /usr/local/bin/qemu-system-x86_64 -cpu host -enable-kvm \ -m 1536 -name Win7Pro64 -localtime -no-fd-bootchk -smp cores=4 \ -pidfile /home/rick/qemu/hds/win7pro64.pid \ -drive file=/home/rick/qemu/hds/win7pro64.qed,if=virtio,index=0,snapshot=on \ -vga qxl \ -net nic,model=virtio -net user \ -device virtio-serial-pci,id=virtio-serial0,max_ports=16,bus=pci.0,addr=0x5 \ -chardev spicevmc,name=vdagent,id=vdagent \ -device virtserialport,nr=1,bus=virtio-serial0.0,chardev=vdagent,name=com.redhat.sp ice.0 \ -spice port=1247,disable-ticketing \ -monitor telnet:localhost:12471,server,nowait \ -drive if=none,id=cd,file=/dev/sg1 \ -device virtio-scsi-pci,id=scsi \ -device scsi-generic,drive=cd \ -balloon virtio \ -soundhw hda \ -device usb-ehci Thanks, -Rick On Tuesday 15 April 2014 15:22:04 Dr. David Alan Gilbert wrote: * Rick Vernam (rtver...@hobi.com) wrote: I have been trying out the 2.0 RCs, and I've noticed that when I use spice qemu aborts when I reboot the VM. This occurs on Win XP guest, Win 7 (64-bit) guest and Win 8 (64-bit) guest. Is this something that anybody else experiences? I don't care to divert anybody's energy if this a spice thing - how best to determine this? You say qemu aborts; can you get a backtrace and the abort message? Dave -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK sorry, for top posting my last response. and also sorry for not noticing that I had let the binaries get stripped previously. Here with qemu-system-x86_64 not stripped, and spice lib not stripped: Program received signal SIGSEGV, Segmentation fault. 0x7211eae5 in spice_char_device_write_to_device (dev=0x5687bcf0) at char_device.c:443 443 sif = SPICE_CONTAINEROF(dev-sin-base.sif, SpiceCharDeviceInterface, base); (gdb) bt #0 0x7211eae5 in spice_char_device_write_to_device (dev=0x5687bcf0) at char_device.c:443 #1 0x7211fd81 in spice_char_device_start (dev=0x5687bcf0) at char_device.c:798 #2 0x72171f95 in spice_server_vm_start (s=0x561d4360) at reds.c:4520 #3 0x556a1119 in qdev_reset_one (dev=optimized out, opaque=optimized out) at hw/core/qdev.c:240 #4 0x556a0958 in qbus_walk_children (bus=0x567576a0, pre_devfn=0x0, pre_busfn=0x0, post_devfn=0x556a1100 qdev_reset_one, post_busfn=0x5569f060 qbus_reset_one, opaque=0x0) at hw/core/qdev.c:369 #5 0x556a0878 in qdev_walk_children (dev=0x5677c0b0, pre_devfn=0x0, pre_busfn=0x0, post_devfn=0x556a1100 qdev_reset_one, post_busfn=0x5569f060 qbus_reset_one, opaque=0x0) at hw/core/qdev.c:403 #6 0x556a0958 in qbus_walk_children (bus=0x567459c0, pre_devfn=0x0, pre_busfn=0x0, post_devfn=0x556a1100 qdev_reset_one, post_busfn=0x5569f060 qbus_reset_one, opaque=0x0) at hw/core/qdev.c:369 #7 0x557d717a in qemu_devices_reset () at vl.c:1867 #8 qemu_system_reset (report=report@entry=true) at vl.c:1880 #9 0x555f9e2f in main_loop_should_exit () at vl.c:2015 #10 main_loop () at vl.c:2055 #11 main (argc=optimized out, argv=optimized out, envp=optimized out) at vl.c:4507 Thanks, and what can I do to provide more info? I don't know much about spice; I've added kra...@redhat.com to cc who knows spice. Can you clarify a bit more about which spice version you're using and anything else about your setup that might be relevant. Dave -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK Spice is 0.12.4 via Gentoo, which makes me wonder if gentoo is applying any patches over vanilla spice. If they are, I'll grab vanilla spice. This happens during reboot, seemingly right at the transition between shutting down and starting back up; and so I wonder if it crashes during shutdown too, and I just didn't notice since I was shutting down anyway. I'll check on this as well.
Re: [Qemu-devel] [PATCH v1 2/3] memory: Add sysbus memory device
On 15.04.14 04:21, Peter Crosthwaite wrote: Add a sysbus device consisting of a single ram. This allows for instantiation of RAM just like any other device. There are a number of good reasons to want to do this this: 1: Consistency. RAM is not that special where board level files should have to instantiate it with a completely different API. This reduces complexity of board level development by hiding the memory API completely and handling everything via the sysbus API. 2: Device tree completeness. Ram Now shows up in info-qtree and friends. E.g. Info qtree gives meaningful information under the root system bus: dev: sysbus-memory, id zynq.ocm_ram size = 262144 (0x4) read-only = false irq 0 mmio fffc/0004 dev: sysbus-memory, id zynq.ext_ram size = 134217728 (0x800) read-only = false irq 0 mmio /0800 3: Remove dependence of global state. Board files don't have to explicity request the global singleton (and much unloved) address_space_memory() and go hacking on it. address_space_memory() is still ultimately used, but the ugliness is hidden in one place - the sysbus core (we can fix that another day). 4: Data driven machine creation. There is list discussion on being able to create or append-to sysbus machines in a data-driven way (whether thats from command-line, monitor or scripts or whatever). This patch removes the memory special case from that problem and allows RAM instantiation to come via whatever solutions we come up with sysbus device instantiation. Signed-off-by: Peter Crosthwaite peter.crosthwa...@xilinx.com Could you please show that this approach works for more complicated machines, like x86's pc machine and its PCI holes? Alex
Re: [Qemu-devel] [QEMU v6 PATCH 00/17] SMBIOS: build full tables in QEMU
On Di, 2014-04-15 at 20:47 -0400, Kevin O'Connor wrote: On Tue, Apr 15, 2014 at 10:29:26AM +0200, Gerd Hoffmann wrote: Leave the old interface code basically as-is. type0 and type1 individual fields are passed like they are passed today. We don't change to to pass full tables, and we don't extend that to new table types. Continue to provide these in parallel to the new interface, for compatibility with old firmware (and old machine types). The code to generate complete tables will only be used for etc/smbios/smbios-tables. Only machine types for 2.1 + newer will provide them, so with older machine types seabios will continue to generate the smbios tables and guest wouldn't notice a difference. This does mean that SeaBIOS would need to continue to support generating of smbios tables for the foreseeable future as it would need that support whenever one wanted to run a v2.0 or earlier machine type. It would be nice if a future version of SeaBIOS could drop the smbios generation code. However, I'm okay with either direction. Same situation as with acpi, where qemu generating the tables is limited to new machine types too. So we'll continue to need the acpi/smbios generation code. Maintenance burden should be low as there is little reason to ever touch that code as any new development happens in qemu. We can add config options to disable it, so it is possible to reduce the memory footprint in case you know you don't need it. cheers, Gerd
Re: [Qemu-devel] segfault while booting from saved snapshot
Am 15.04.2014 um 16:55 hat Shehbaz Jaffer geschrieben: Thankyou for your reply. I do not face the error using qemu.1.7.1 version. 1 quick question: I want to create a qcow2 image file after my VM has completed booting; i.e., when I boot from this new snapshot, I should directly get to my VMs login prompt. How can i create such a qcow2 snapshot? I tried stopped the VM using QMP after the VM had completed booting, and then using host CLI to create a qcow2 image : qemu-img create -b ubuntu.qcow2 -f qcow2 newsnap.qcow2 This created a new qcow2 file - newsnap.qcow2 on top of ubuntu.qcow2, however when I boot using newsnap.qcow2, It takes me again through the complete boot process - till the login prompt. Is there a way to create the qcow2 snapshot after VM has completed booting? The reason for this is that you only create a snapshot of the disk this way, not of the VM state (i.e. RAM contents, device states, etc.) The most convenient way when you're using qemu directly is probably using internal snapshots. This is what the savevm/loadvm HMP commands provide (not sure if there is a QMP equivalent); you can also use the -loadvm command line parameter to start a VM from a snapshot. Another option is that you take an external snapshot in a new qcow2 file like you did, but you additionally do a live migration into a file. When restarting the VM, you need to use the -incoming option and feed that file back to qemu. As this is a bit more cumbersome, this is probably more an option for management tools than for manual use. Kevin
[Qemu-devel] [PATCH 0/3] block: Improve request length checks
Kevin Wolf (3): block: Fix nb_sectors check in bdrv_check_byte_request() block: Limit size to INT_MAX in bdrv_check_byte_request() block: Catch integer overflow in bdrv_rw_co() block.c| 10 +- tests/qemu-iotests/084.out | 5 + 2 files changed, 10 insertions(+), 5 deletions(-) -- 1.8.3.1
[Qemu-devel] [PATCH 2/3] block: Limit size to INT_MAX in bdrv_check_byte_request()
Commit 8f4754ed intended to protect against integer overflow bugs in
block drivers by making sure that a single request that is passed to
drivers is no longer than INT_MAX bytes.
However, meanwhile there are some callers that don't use that code path
any more but call bdrv_check_byte_request() directy, so let's add a
check there as well.
Signed-off-by: Kevin Wolf kw...@redhat.com
---
block.c | 4
1 file changed, 4 insertions(+)
diff --git a/block.c b/block.c
index 8be40bb..bcf9dc9 100644
--- a/block.c
+++ b/block.c
@@ -2589,6 +2589,10 @@ static int bdrv_check_byte_request(BlockDriverState *bs,
int64_t offset,
{
int64_t len;
+if (size INT_MAX) {
+return -EIO;
+}
+
if (!bdrv_is_inserted(bs))
return -ENOMEDIUM;
--
1.8.3.1
[Qemu-devel] [PATCH 1/3] block: Fix nb_sectors check in bdrv_check_byte_request()
nb_sectors is signed, check for negative values.
Signed-off-by: Kevin Wolf kw...@redhat.com
---
block.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/block.c b/block.c
index 75c3948..8be40bb 100644
--- a/block.c
+++ b/block.c
@@ -2609,7 +2609,7 @@ static int bdrv_check_byte_request(BlockDriverState *bs,
int64_t offset,
static int bdrv_check_request(BlockDriverState *bs, int64_t sector_num,
int nb_sectors)
{
-if (nb_sectors INT_MAX / BDRV_SECTOR_SIZE) {
+if (nb_sectors 0 || nb_sectors INT_MAX / BDRV_SECTOR_SIZE) {
return -EIO;
}
--
1.8.3.1
[Qemu-devel] [PATCH 3/3] block: Catch integer overflow in bdrv_rw_co()
Insanely large requests could cause an integer overflow in
bdrv_rw_co() while converting sectors to bytes. This patch catches the
problem and returns an error (if we hadn't overflown the integer here,
bdrv_check_byte_request() would have rejected the request, so we're not
breaking anything that was supposed to work before).
We actually do have a test case that triggers behaviour where we
accidentally let such a request pass, so that it would return success,
but read 0 bytes instead of the requested 4 GB. It fails now like it
should.
If the vdi block driver wants to be able to deal with huge images, it
can't read the whole block bitmap at once into memory like it does
today, but needs to use a metadata cache like qcow2 does.
Signed-off-by: Kevin Wolf kw...@redhat.com
---
block.c| 4
tests/qemu-iotests/084.out | 5 +
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/block.c b/block.c
index bcf9dc9..d268ece 100644
--- a/block.c
+++ b/block.c
@@ -2698,6 +2698,10 @@ static int bdrv_rw_co(BlockDriverState *bs, int64_t
sector_num, uint8_t *buf,
.iov_len = nb_sectors * BDRV_SECTOR_SIZE,
};
+if (nb_sectors 0 || nb_sectors INT_MAX / BDRV_SECTOR_SIZE) {
+return -EINVAL;
+}
+
qemu_iovec_init_external(qiov, iov, 1);
return bdrv_prwv_co(bs, sector_num BDRV_SECTOR_BITS,
qiov, is_write, flags);
diff --git a/tests/qemu-iotests/084.out b/tests/qemu-iotests/084.out
index e681924..c7120d9 100644
--- a/tests/qemu-iotests/084.out
+++ b/tests/qemu-iotests/084.out
@@ -4,10 +4,7 @@ QA output created by 084
Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=67108864
Test 1: Maximum size (1024 TB):
-image: TEST_DIR/t.IMGFMT
-file format: IMGFMT
-virtual size: 1024T (1125899905794048 bytes)
-cluster_size: 1048576
+qemu-img: Could not open 'TEST_DIR/t.IMGFMT': Could not open
'TEST_DIR/t.IMGFMT': Invalid argument
Test 2: Size too large (1024TB + 1)
qemu-img: Could not open 'TEST_DIR/t.IMGFMT': Unsupported VDI image size (size
is 0x3fff1, max supported is 0x3fff0)
--
1.8.3.1
[Qemu-devel] [PATCH] block: Check bdrv_getlength() return value in bdrv_make_zero()
Signed-off-by: Kevin Wolf kw...@redhat.com
---
block.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/block.c b/block.c
index d268ece..8510ba2 100644
--- a/block.c
+++ b/block.c
@@ -2757,10 +2757,16 @@ int bdrv_write_zeroes(BlockDriverState *bs, int64_t
sector_num,
*/
int bdrv_make_zero(BlockDriverState *bs, BdrvRequestFlags flags)
{
-int64_t target_size = bdrv_getlength(bs) / BDRV_SECTOR_SIZE;
+int64_t target_size;
int64_t ret, nb_sectors, sector_num = 0;
int n;
+target_size = bdrv_getlength(bs);
+if (target_size 0) {
+return target_size;
+}
+target_size /= BDRV_SECTOR_SIZE;
+
for (;;) {
nb_sectors = target_size - sector_num;
if (nb_sectors = 0) {
--
1.8.3.1
Re: [Qemu-devel] [RFC v2 4/6] vfio: Add initial IRQ support in QEMU platform device
On 04/11/2014 03:34 AM, Kim Phillips wrote:
On Wed, 9 Apr 2014 16:33:07 +0100
Eric Auger eric.au...@linaro.org wrote:
This work is inspired of PCI INTx. The code was prepared to support
multiple IRQs but this was not tested at that stage. Similarly to what
is done on PCI, the device register space is RAM unmapped on IRQ hit
in order to trap the end of interrupt (EOI). On mmap timer hit, if the
EOI was trapped, the mmapping is restored. the physical interrupt is
unmasked on the first read/write with the MMIO register space.
Tested on Calxeda Midway xgmac which can be directly assigned to one
virt VM.
Acknowledgements:
- vfio device name, guest physical address and IRQ indexes are
hardcoded. This will be improved in another patch
- currently tested on a single IRQ (xgmac main IRQ)
- a KVM patch is required to invalidate stage2 entries on RAM memory
region destruction (see [PATCH] ARM: KVM: Handle IPA unmapping on
memory region deletion)
Signed-off-by: Eric Auger eric.au...@linaro.org
---
thanks for this, Eric.
hw/arm/virt.c | 13 ++-
hw/vfio/platform.c | 316
+
2 files changed, 304 insertions(+), 25 deletions(-)
diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index 5d43cf0..31ae7d2 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -108,12 +108,13 @@ static const MemMapEntry a15memmap[] = {
/* ...repeating for a total of NUM_VIRTIO_TRANSPORTS, each of that size
*/
/* 0x1000 .. 0x4000 reserved for PCI */
[VIRT_MEM] = { 0x4000, 1ULL * 1024 * 1024 * 1024 },
-[VIRT_ETHERNET] = { 0xfff51000, 0x1000 },
+[VIRT_ETHERNET] = { 0xfff41000, 0x1000 },
this change isn't explained (the device is at physical 0xfff51000,
not 0xfff41000), and looks like it belongs in the first patch of the
series anyway. Note: see e.g., commit f5fdcd6e5 hw/arm: Add
'virt' platform for an example of how to re-compose commit message
text for patches that undergo a change of author.
Hi Kim,
I acknowledge the change is not justified in the context of IRQ support
introduction. I will remove it.
I changed this because the address used in the prior patch was
misleading to me, as I reported in one comment. Indeed 0xFFF51000 is the
host physical address of the device but here we specify the guest
physical address which in general does not relate at all with the host
physical address.
};
static const int a15irqmap[] = {
[VIRT_UART] = 1,
[VIRT_MMIO] = 16, /* ...to 16 + NUM_VIRTIO_TRANSPORTS - 1 */
+[VIRT_ETHERNET] = 77,
};
static VirtBoardInfo machines[] = {
@@ -299,8 +300,12 @@ static void create_ethernet(const VirtBoardInfo *vbi,
qemu_irq *pic)
hwaddr base = vbi-memmap[VIRT_ETHERNET].base;
hwaddr size = vbi-memmap[VIRT_ETHERNET].size;
const char compat[] = calxeda,hb-xgmac;
+int irqm = vbi-irqmap[VIRT_ETHERNET];
+int irqp = irqm+1;
+int irqlp = irqm+2;
-sysbus_create_simple(vfio-platform, base, NULL);
+sysbus_create_varargs(vfio-platform, base,
+ pic[irqm], pic[irqp], pic[irqlp], NULL);
nodename = g_strdup_printf(/ethernet@% PRIx64, base);
qemu_fdt_add_subnode(vbi-fdt, nodename);
@@ -308,6 +313,10 @@ static void create_ethernet(const VirtBoardInfo *vbi,
qemu_irq *pic)
/* Note that we can't use setprop_string because of the embedded NUL */
qemu_fdt_setprop(vbi-fdt, nodename, compatible, compat,
sizeof(compat));
qemu_fdt_setprop_sized_cells(vbi-fdt, nodename, reg, 2, base, 2,
size);
+qemu_fdt_setprop_cells(vbi-fdt, nodename, interrupts,
+0x0, irqm, 0x4,
+0x0, irqp, 0x4,
+0x0, irqlp, 0x4);
fwiw, it would have been nice to reuse the irq variable names used
in hw/net/xgmac.c, but whatever...
OK, I used irqM for Main, irqP for Power and irqLP for Low Power. The
driver only uses 2 of them: main and power. I can rename. Anyway this
code is bound to disappear. See next patch.
g_free(nodename);
}
diff --git a/hw/vfio/platform.c b/hw/vfio/platform.c
index 138fb13..f148edd 100644
--- a/hw/vfio/platform.c
+++ b/hw/vfio/platform.c
@@ -24,6 +24,7 @@
#include config.h
#include exec/address-spaces.h
#include exec/memory.h
+
#include qemu-common.h
#include qemu/error-report.h
#include qemu/event_notifier.h
@@ -31,6 +32,7 @@
#include qemu/range.h
#include sysemu/kvm.h
#include sysemu/sysemu.h
+
#include hw/qdev-properties.h
#include migration/vmstate.h
#include hw/hw.h
@@ -41,12 +43,15 @@
#define DEBUG_VFIO
#ifdef DEBUG_VFIO
#define DPRINTF(fmt, ...) \
-do { fprintf(stderr, vfio: fmt, ## __VA_ARGS__); } while (0)
+do { fprintf(stderr, vfio: %s: fmt, __func__, ## __VA_ARGS__); } \
+while (0)
these changes are unrelated to the subject of this add IRQ patch -
either make them their own patch (in
Re: [Qemu-devel] [PATCH 3/7] megasas: add MegaRAID SAS 2108 emulation
Am 16.04.2014 09:16, schrieb Hannes Reinecke:
The 2108 chip supports MSI and MSI-X, so update the emulation
to support both chips.
Signed-off-by: Hannes Reinecke h...@suse.de
---
hw/scsi/megasas.c| 95
++--
hw/scsi/mfi.h| 7
include/hw/pci/pci_ids.h | 1 +
3 files changed, 91 insertions(+), 12 deletions(-)
diff --git a/hw/scsi/megasas.c b/hw/scsi/megasas.c
index ae3e9d6..687115e 100644
--- a/hw/scsi/megasas.c
+++ b/hw/scsi/megasas.c
[...]
@@ -1890,6 +1903,8 @@ static uint64_t megasas_mmio_read(void *opaque, hwaddr
addr,
unsigned size)
{
MegasasState *s = opaque;
+PCIDevice *pci_dev = PCI_DEVICE(s);
+PCIDeviceClass *pci_class = PCI_DEVICE_GET_CLASS(pci_dev);
Seeing that you don't use pci_dev elsewhere, you can just pass s to this
macro directly.
Cheers,
Andreas
uint32_t retval = 0;
switch (addr) {
@@ -1905,7 +1920,11 @@ static uint64_t megasas_mmio_read(void *opaque, hwaddr
addr,
break;
case MFI_OSTS:
if (megasas_intr_enabled(s) s-doorbell) {
-retval = MFI_1078_RM | 1;
+if (megasas_is_gen2(pci_class)) {
+retval = MFI_GEN2_RM;
+} else {
+retval = MFI_1078_RM | 1;
+}
}
break;
case MFI_OMSK:
@@ -1914,6 +1933,9 @@ static uint64_t megasas_mmio_read(void *opaque, hwaddr
addr,
case MFI_ODCR0:
retval = s-doorbell;
break;
+case MFI_DIAG:
+retval = s-diag;
+break;
default:
trace_megasas_mmio_invalid_readl(addr);
break;
@@ -1922,6 +1944,8 @@ static uint64_t megasas_mmio_read(void *opaque, hwaddr
addr,
return retval;
}
+static int adp_reset_seq[] = {0x00, 0x04, 0x0b, 0x02, 0x07, 0x0d};
+
static void megasas_mmio_write(void *opaque, hwaddr addr,
uint64_t val, unsigned size)
{
[snip]
--
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] what is the differences between file and block disk
hi,all 1. what is the differences between file and block disk? which is better? it seems that qemu always use pread and pwrite , does not care about the type of vm's disk. am i right? thanks
Re: [Qemu-devel] [PATCH 1/7] megasas: Enable MSI-X support
Am 16.04.2014 09:16, schrieb Hannes Reinecke: MSI-X support has been fixed in qemu, so we can enable it again. QEMU fwiw Signed-off-by: Hannes Reinecke h...@suse.de We had discussed enabling MSI-X before, and what I am missing here is a change to the VMStateDescription. As long as no patches moving that responsibility to PCIDevice / PCIEDevice are applied [1], it is your responsibility to add appropriate VMSTATE_MSIX() macro for your device. Regards, Andreas [1] http://lists.nongnu.org/archive/html/qemu-devel/2013-09/msg00219.html -- 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 28/35] pc: propagate memory hotplug event to ACPI device
On Wed, 16 Apr 2014 15:02:40 +0300
Michael S. Tsirkin m...@redhat.com wrote:
On Fri, Apr 11, 2014 at 11:14:00AM +0200, Igor Mammedov wrote:
On Mon, 7 Apr 2014 18:14:51 +0300
Michael S. Tsirkin m...@redhat.com wrote:
On Mon, Apr 07, 2014 at 04:32:16PM +0200, Igor Mammedov wrote:
On Mon, 7 Apr 2014 13:23:54 +0300
Michael S. Tsirkin m...@redhat.com wrote:
On Fri, Apr 04, 2014 at 03:36:53PM +0200, Igor Mammedov wrote:
Notify PIIX4_PM/ICH9LPC device about hotplug event,
so that it would send SCI to guest notifying about
newly added memory.
Signed-off-by: Igor Mammedov imamm...@redhat.com
---
hw/i386/pc.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 734c6ee..ee5cf88 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -60,6 +60,8 @@
#include acpi-build.h
#include hw/mem/dimm.h
#include trace.h
+#include hw/acpi/piix4.h
+#include hw/i386/ich9.h
/* debug PC/ISA interrupts */
//#define DEBUG_IRQ
@@ -1484,6 +1486,8 @@ void qemu_register_pc_machine(QEMUMachine *m)
static void pc_dimm_plug(HotplugHandler *hotplug_dev,
DeviceState *dev, Error **errp)
{
+Object *acpi_dev;
+HotplugHandlerClass *hhc;
Error *local_err = NULL;
PCMachineState *pcms = PC_MACHINE(hotplug_dev);
DimmDevice *dimm = DIMM(dev);
@@ -1517,10 +1521,19 @@ static void pc_dimm_plug(HotplugHandler
*hotplug_dev,
}
trace_mhp_pc_dimm_assigned_slot(dimm-slot);
+acpi_dev = (acpi_dev = piix4_pm_find()) ? acpi_dev :
ich9_lpc_find();
+if (!acpi_dev) {
+error_setg(local_err,
+ memory hotplug is not enabled: missing acpi
device);
+return;
+}
+
+hhc = HOTPLUG_HANDLER_GET_CLASS(acpi_dev);
How about simply looking for a hotplug handler type device instead?
We aren't likely to have many of these, are we?
How about adding linkacpi_device to PCMachine when it's created
and use it instead of piix4_pm_find()/ich9_lpc_find() everywhere?
that would allow to remove above searches in QOM tree and simplify
code including acpi-build.c
So each acpi implementation registers a link at a pre-defined path?
I'm fine with this, need an ack from afaerber though.
It could be a just plain pointer since it points to system device which
won't disappear suddenly (i.e. it's not hot-unplugable).
It would be nice to support removing them if we want to allow guests to
disable ACPI and switch to native hotplug.
Pointer/link to ACPI in PCMachine is nothing more than a convenience, to avoid
lookups each time we need to get property from ACPI device.
It's not limited to hotplug handler in any way and could/would be used
in acpi_build.c as well.
I guess that under allow guests to disable ACPI you mean switching hotplug
handlers on pci bridges, i.e. not really removing/disabling ACPI device itself.
About switching ACPI/SHPC hotplug modes,
do you have an idea how it could be implemented, starting from guest side
and till the switch actually happens?
memory_region_add_subregion(pcms-hotplug_memory,
addr - pcms-hotplug_memory_base,
mr);
vmstate_register_ram(mr, dev);
+hhc-plug(HOTPLUG_HANDLER(acpi_dev), dev, local_err);
out:
error_propagate(errp, local_err);
--
1.9.0
--
Regards,
Igor
[Qemu-devel] [PATCH v2] Add remove_boot_device_path() function for hot-unplug device
Add remove_boot_device_path() function to remove bootindex when hot-unplug
a device. This patch fixed virtio-blk/virtio-net/scsi-disk/scsi-generic device.
So it has fixed bug1086603, ref:
https://bugzilla.redhat.com/show_bug.cgi?id=1086603
Make some changes based on Andreas's good suggestion.
Signed-off-by: Jun Li junm...@gmail.com
---
hw/block/virtio-blk.c | 1 +
hw/net/virtio-net.c | 1 +
hw/scsi/scsi-disk.c | 6 --
hw/scsi/scsi-generic.c | 3 +++
include/sysemu/sysemu.h | 2 ++
vl.c| 16
6 files changed, 27 insertions(+), 2 deletions(-)
diff --git a/hw/block/virtio-blk.c b/hw/block/virtio-blk.c
index 8a568e5..ecdd266 100644
--- a/hw/block/virtio-blk.c
+++ b/hw/block/virtio-blk.c
@@ -752,6 +752,7 @@ static void virtio_blk_device_unrealize(DeviceState *dev,
Error **errp)
unregister_savevm(dev, virtio-blk, s);
blockdev_mark_auto_del(s-bs);
virtio_cleanup(vdev);
+remove_boot_device_path(s-conf-bootindex, dev, /disk@0,0);
}
static Property virtio_blk_properties[] = {
diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index 33bd233..520c029 100644
--- a/hw/net/virtio-net.c
+++ b/hw/net/virtio-net.c
@@ -1633,6 +1633,7 @@ static void virtio_net_device_unrealize(DeviceState *dev,
Error **errp)
g_free(n-vqs);
qemu_del_nic(n-nic);
virtio_cleanup(vdev);
+remove_boot_device_path(n-nic_conf.bootindex, dev, /ethernet-phy@0);
}
static void virtio_net_instance_init(Object *obj)
diff --git a/hw/scsi/scsi-disk.c b/hw/scsi/scsi-disk.c
index 48a28ae..bb2176a 100644
--- a/hw/scsi/scsi-disk.c
+++ b/hw/scsi/scsi-disk.c
@@ -2150,12 +2150,14 @@ static void scsi_disk_reset(DeviceState *dev)
s-tray_open = 0;
}
-static void scsi_destroy(SCSIDevice *dev)
+static void scsi_destroy(SCSIDevice *sdev)
{
-SCSIDiskState *s = DO_UPCAST(SCSIDiskState, qdev, dev);
+SCSIDiskState *s = DO_UPCAST(SCSIDiskState, qdev, sdev);
+DeviceState *dev = DEVICE(sdev);
scsi_device_purge_requests(s-qdev, SENSE_CODE(NO_SENSE));
blockdev_mark_auto_del(s-qdev.conf.bs);
+remove_boot_device_path(s-qdev.conf.bootindex, dev, NULL);
}
static void scsi_disk_resize_cb(void *opaque)
diff --git a/hw/scsi/scsi-generic.c b/hw/scsi/scsi-generic.c
index 8d92e0d..2531a44 100644
--- a/hw/scsi/scsi-generic.c
+++ b/hw/scsi/scsi-generic.c
@@ -388,8 +388,11 @@ static void scsi_generic_reset(DeviceState *dev)
static void scsi_destroy(SCSIDevice *s)
{
+DeviceState *dev = DEVICE(s);
+
scsi_device_purge_requests(s, SENSE_CODE(NO_SENSE));
blockdev_mark_auto_del(s-conf.bs);
+remove_boot_device_path(s-conf.bootindex, dev, NULL);
}
static int scsi_generic_initfn(SCSIDevice *s)
diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h
index ba5c7f8..f7ad1e2 100644
--- a/include/sysemu/sysemu.h
+++ b/include/sysemu/sysemu.h
@@ -193,6 +193,8 @@ void rtc_change_mon_event(struct tm *tm);
void add_boot_device_path(int32_t bootindex, DeviceState *dev,
const char *suffix);
+void remove_boot_device_path(int32_t bootindex, DeviceState *dev,
+ const char *suffix);
char *get_boot_devices_list(size_t *size, bool ignore_suffixes);
DeviceState *get_boot_device(uint32_t position);
diff --git a/vl.c b/vl.c
index 9975e5a..1713c68 100644
--- a/vl.c
+++ b/vl.c
@@ -1184,6 +1184,22 @@ void add_boot_device_path(int32_t bootindex, DeviceState
*dev,
QTAILQ_INSERT_TAIL(fw_boot_order, node, link);
}
+void remove_boot_device_path(int32_t bootindex, DeviceState *dev,
+ const char *suffix)
+{
+FWBootEntry *node, *next_node;
+
+if (bootindex == -1) {
+return;
+}
+
+QTAILQ_FOREACH_SAFE(node, fw_boot_order, link, next_node)
+if (node-bootindex == bootindex) {
+QTAILQ_REMOVE(fw_boot_order, node, link);
+return;
+}
+}
+
DeviceState *get_boot_device(uint32_t position)
{
uint32_t counter = 0;
--
1.8.3.1
[Qemu-devel] QEMU APIC version ID bug?
Seems there is a bug in qemu where the APIC version is being checked as
value 3. However, it should be 1.
static uint32_t apic_mem_readl(void *opaque, hwaddr addr)
{
...
switch(index) {
case 0x03: /* version */
val = 0x11 | ((APIC_LVT_NB - 1) 16); /* version 0x11 */
break;
Comparing to KVM, it has the correct value:
static unsigned long ioapic_read_indirect(struct kvm_ioapic *ioapic,
unsigned long addr,
unsigned long length)
{
unsigned long result = 0;
switch (ioapic-ioregsel) {
case IOAPIC_REG_VERSION:
result = IOAPIC_NUM_PINS - 1) 0xff) 16)
| (IOAPIC_VERSION_ID 0xff));
break;
./virt/kvm/ioapic.h:#define IOAPIC_REG_VERSION 0x01
I hit this as we have on OS that was checking for the number of IRQ pins
and we were falling into the default case.
Is this a known issue? What's the best way to submit a patch/get this
committed if it is an accepted bug?
tx
neil
Re: [Qemu-devel] [PATCH RFC qom-next for-next v2 6/6] pci: Move VMSTATE_MSIX() into vmstate_pci_device
Am 02.09.2013 13:31, schrieb Michael S. Tsirkin:
On Mon, Jul 29, 2013 at 02:27:01AM +0200, Andreas Färber wrote:
Use it conditional on msix_present() and drop msix_{save,load}() calls
following pci_device_{save,load}().
This reorders the msix_save() and msix_unuse_all_vectors() calls for
virtio-pci, but they seem independent of each other.
No, that's a bug. msix_unuse_all_vectors clears pending state
if any, it will lose state if called before load.
Michael, you were just saying no here, now MegaSAS is forgetting to add
appropriate VMState. How do you envision solving that bug? Can we move
msix_unuse_all_vectors() to common code or something?
FTR, Stefan had requested on IRC that vmxnet state not be changed
incompatibly. What we discussed there was to register the legacy savevm
handler only for reading incoming state (NULL for writing new state);
but I am no longer sure that could work due to new VMSTATE_PCI().
Dmitry, why is vmxnet using such a non-standard way of registering
VMState for MSI-X, and can you please help to fix that for the benefit
of all PCI devices?
Thanks,
Andreas
Signed-off-by: Andreas Färber afaer...@suse.de
---
hw/misc/ivshmem.c | 7 ++-
hw/net/vmxnet3.c | 27 +++
hw/pci/pci.c | 8
hw/usb/hcd-xhci.c | 1 -
hw/virtio/virtio-pci.c | 19 +++
include/hw/pci/msix.h | 7 ---
6 files changed, 28 insertions(+), 41 deletions(-)
diff --git a/hw/misc/ivshmem.c b/hw/misc/ivshmem.c
index 4a74856..de997cd 100644
--- a/hw/misc/ivshmem.c
+++ b/hw/misc/ivshmem.c
@@ -599,9 +599,7 @@ static void ivshmem_save(QEMUFile* f, void *opaque)
IVSHMEM_DPRINTF(ivshmem_save\n);
pci_device_save(pci_dev, f);
-if (ivshmem_has_feature(proxy, IVSHMEM_MSI)) {
-msix_save(pci_dev, f);
-} else {
+if (!ivshmem_has_feature(proxy, IVSHMEM_MSI)) {
qemu_put_be32(f, proxy-intrstatus);
qemu_put_be32(f, proxy-intrmask);
}
@@ -631,8 +629,7 @@ static int ivshmem_load(QEMUFile* f, void *opaque, int
version_id)
}
if (ivshmem_has_feature(proxy, IVSHMEM_MSI)) {
-msix_load(pci_dev, f);
-ivshmem_use_msix(proxy);
+ivshmem_use_msix(proxy);
} else {
proxy-intrstatus = qemu_get_be32(f);
proxy-intrmask = qemu_get_be32(f);
diff --git a/hw/net/vmxnet3.c b/hw/net/vmxnet3.c
index 3bad83c..471ca24 100644
--- a/hw/net/vmxnet3.c
+++ b/hw/net/vmxnet3.c
@@ -2031,21 +2031,6 @@ vmxnet3_cleanup_msi(VMXNET3State *s)
}
}
-static void
-vmxnet3_msix_save(QEMUFile *f, void *opaque)
-{
-PCIDevice *d = PCI_DEVICE(opaque);
-msix_save(d, f);
-}
-
-static int
-vmxnet3_msix_load(QEMUFile *f, void *opaque, int version_id)
-{
-PCIDevice *d = PCI_DEVICE(opaque);
-msix_load(d, f);
-return 0;
-}
-
static const MemoryRegionOps b0_ops = {
.read = vmxnet3_io_bar0_read,
.write = vmxnet3_io_bar0_write,
@@ -2103,9 +2088,6 @@ static int vmxnet3_pci_init(PCIDevice *pci_dev)
vmxnet3_net_init(s);
-register_savevm(dev, vmxnet3-msix, -1, 1,
-vmxnet3_msix_save, vmxnet3_msix_load, s);
-
add_boot_device_path(s-conf.bootindex, dev, /ethernet-phy@0);
return 0;
@@ -2114,13 +2096,10 @@ static int vmxnet3_pci_init(PCIDevice *pci_dev)
static void vmxnet3_pci_uninit(PCIDevice *pci_dev)
{
-DeviceState *dev = DEVICE(pci_dev);
VMXNET3State *s = VMXNET3(pci_dev);
VMW_CBPRN(Starting uninit...);
-unregister_savevm(dev, vmxnet3-msix, s);
-
vmxnet3_net_uninit(s);
vmxnet3_cleanup_msix(s);
@@ -2372,9 +2351,9 @@ const VMStateInfo int_state_info = {
static const VMStateDescription vmstate_vmxnet3 = {
.name = vmxnet3,
-.version_id = 1,
-.minimum_version_id = 1,
-.minimum_version_id_old = 1,
+.version_id = 2,
+.minimum_version_id = 2,
+.minimum_version_id_old = 2,
.pre_save = vmxnet3_pre_save,
.post_load = vmxnet3_post_load,
.fields = (VMStateField[]) {
diff --git a/hw/pci/pci.c b/hw/pci/pci.c
index b790d98..bd6078b 100644
--- a/hw/pci/pci.c
+++ b/hw/pci/pci.c
@@ -481,6 +481,13 @@ static bool pci_device_aer_needed(void *opaque, int
version_id)
return pci_is_express(s) s-exp.aer_log.log != NULL;
}
+static bool pci_device_msix_needed(void *opaque, int version_id)
+{
+PCIDevice *s = opaque;
+
+return msix_present(s);
+}
+
const VMStateDescription vmstate_pci_device = {
.name = PCIDevice,
.version_id = 2,
@@ -499,6 +506,7 @@ const VMStateDescription vmstate_pci_device = {
VMSTATE_BUFFER_UNSAFE_INFO(irq_state, PCIDevice, 2,
vmstate_info_pci_irq_state,
PCI_NUM_PINS * sizeof(int32_t)),
+VMSTATE_MSIX_TEST(pci_device_msix_needed),
VMSTATE_STRUCT_TEST(exp.aer_log, PCIDevice,
[Qemu-devel] disk cache question and drawback of cache
hi,all libvirt supply default, none, writethrough, writeback, directsync, unsafe disk cache options 1. as for qemu, how qemu uses those options? and what are the differences? better tell me where are the codes corresponding to those options? 2. after a long time of running , it seems that vms will slow down? do you know why? cache hit rate goes down or kernel takes time to flush cache? how to avoid it? thanks
Re: [Qemu-devel] [PATCH 13/35] pc: initialize memory hotplug address space
On Wed, 16 Apr 2014 16:59:25 +0800
Hu Tao hu...@cn.fujitsu.com wrote:
On Fri, Apr 04, 2014 at 03:36:38PM +0200, Igor Mammedov wrote:
initialize and map hotplug memory address space container
into guest's RAM address space.
Signed-off-by: Igor Mammedov imamm...@redhat.com
---
hw/i386/pc.c | 19 +--
include/hw/i386/pc.h | 10 ++
2 files changed, 27 insertions(+), 2 deletions(-)
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 32b4003..69e4225 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1171,6 +1171,9 @@ FWCfgState *pc_memory_init(MemoryRegion
*system_memory,
MemoryRegion *ram, *option_rom_mr;
MemoryRegion *ram_below_4g, *ram_above_4g;
FWCfgState *fw_cfg;
+ram_addr_t ram_size = below_4g_mem_size + above_4g_mem_size;
+MachineState *machine = MACHINE(qdev_get_machine());
+PCMachineState *pcms = PC_MACHINE(machine);
linux_boot = (kernel_filename != NULL);
@@ -1179,8 +1182,7 @@ FWCfgState *pc_memory_init(MemoryRegion
*system_memory,
* with older qemus that used qemu_ram_alloc().
*/
ram = g_malloc(sizeof(*ram));
-memory_region_init_ram(ram, NULL, pc.ram,
- below_4g_mem_size + above_4g_mem_size);
+memory_region_init_ram(ram, NULL, pc.ram, ram_size);
vmstate_register_ram_global(ram);
*ram_memory = ram;
ram_below_4g = g_malloc(sizeof(*ram_below_4g));
@@ -1197,6 +1199,19 @@ FWCfgState *pc_memory_init(MemoryRegion
*system_memory,
e820_add_entry(0x1ULL, above_4g_mem_size, E820_RAM);
}
+/* initialize hotplug memory address space */
+if (ram_size machine-init_args.maxram_size) {
+ram_addr_t hotplug_mem_size =
+machine-init_args.maxram_size - ram_size;
+
+pcms-hotplug_memory_base =
+ROUND_UP(0x1ULL + above_4g_mem_size, 1ULL 30);
-m maxmem should be limited otherwise hotplug_memory_base + maxmem can
overflow(in dimm_get_free_addr()).
If overflow happens than dimm_get_free_addr() will return error,
if you look its end.
dimm_get_free_addr() {
...
if (new_start address_space_start) {
error_setg(...
that of cause doesn't mean that maxmem limit shouldn't be set and verified
with proper error reporting in case of one.
Is there any suggestion as to what max supported RAM amount should be?
Re: [Qemu-devel] [PATCH 2/9] kvm: add kvm_enable_cap_{vm,vcpu}
On Wed, 16 Apr 2014 13:58:31 +0200
Cornelia Huck cornelia.h...@de.ibm.com wrote:
On Wed, 16 Apr 2014 13:38:27 +0200
Alexander Graf ag...@suse.de wrote:
On 16.04.2014, at 13:22, Alexander Graf ag...@suse.de wrote:
On 14.04.14 18:48, Cornelia Huck wrote:
Provide helper functions for enabling capabilities (on a vcpu and on a
vm).
Reviewed-by: Thomas Huth th...@linux.vnet.ibm.com
Signed-off-by: Cornelia Huck cornelia.h...@de.ibm.com
---
include/sysemu/kvm.h |4
kvm-all.c| 33 -
2 files changed, 36 insertions(+), 1 deletion(-)
diff --git a/include/sysemu/kvm.h b/include/sysemu/kvm.h
index 0bee1e8..2ff5ad3 100644
--- a/include/sysemu/kvm.h
+++ b/include/sysemu/kvm.h
@@ -294,6 +294,10 @@ bool kvm_arch_stop_on_emulation_error(CPUState
*cpu);
int kvm_check_extension(KVMState *s, unsigned int extension);
+int kvm_enable_cap_vm(KVMState *s, unsigned int capability, ...);
+
+int kvm_enable_cap_vcpu(CPUState *cpu, unsigned int capability, ...);
+
uint32_t kvm_arch_get_supported_cpuid(KVMState *env, uint32_t function,
uint32_t index, int reg);
diff --git a/kvm-all.c b/kvm-all.c
index cd4111d..658e50c 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -501,7 +501,38 @@ int kvm_check_extension(KVMState *s, unsigned int
extension)
return ret;
}
-static int kvm_set_ioeventfd_mmio(int fd, hwaddr addr, uint32_t val,
+int kvm_enable_cap_vm(KVMState *s, unsigned int capability, ...)
+{
+struct kvm_enable_cap cap = {};
+va_list ap;
+int i;
+
+cap.cap = capability;
+va_start(ap, capability);
+for (i = 0; i 4; i++) {
+cap.args[i] = va_arg(ap, uint64_t);
Is this legit? Can we just pull items off the stack without running
beyond?
For inspiration on how to know the number of arguments that got passed in,
check out
http://git.qemu.org/?p=qemu.git;a=blob;f=include/sysemu/device_tree.h#l40
Ah, that is probably better than splattering args with random stuff.
Will try.
Huh, how does
integer type array[] = { __VA_ARGS__ };
even compile? On both i386 and s390, I get initialization makes
integer from pointer without a cast - is arm different?
Re: [Qemu-devel] [PATCH 2/9] kvm: add kvm_enable_cap_{vm,vcpu}
On 16.04.14 16:25, Cornelia Huck wrote:
On Wed, 16 Apr 2014 13:58:31 +0200
Cornelia Huck cornelia.h...@de.ibm.com wrote:
On Wed, 16 Apr 2014 13:38:27 +0200
Alexander Graf ag...@suse.de wrote:
On 16.04.2014, at 13:22, Alexander Graf ag...@suse.de wrote:
On 14.04.14 18:48, Cornelia Huck wrote:
Provide helper functions for enabling capabilities (on a vcpu and on a vm).
Reviewed-by: Thomas Huth th...@linux.vnet.ibm.com
Signed-off-by: Cornelia Huck cornelia.h...@de.ibm.com
---
include/sysemu/kvm.h |4
kvm-all.c| 33 -
2 files changed, 36 insertions(+), 1 deletion(-)
diff --git a/include/sysemu/kvm.h b/include/sysemu/kvm.h
index 0bee1e8..2ff5ad3 100644
--- a/include/sysemu/kvm.h
+++ b/include/sysemu/kvm.h
@@ -294,6 +294,10 @@ bool kvm_arch_stop_on_emulation_error(CPUState *cpu);
int kvm_check_extension(KVMState *s, unsigned int extension);
+int kvm_enable_cap_vm(KVMState *s, unsigned int capability, ...);
+
+int kvm_enable_cap_vcpu(CPUState *cpu, unsigned int capability, ...);
+
uint32_t kvm_arch_get_supported_cpuid(KVMState *env, uint32_t function,
uint32_t index, int reg);
diff --git a/kvm-all.c b/kvm-all.c
index cd4111d..658e50c 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -501,7 +501,38 @@ int kvm_check_extension(KVMState *s, unsigned int
extension)
return ret;
}
-static int kvm_set_ioeventfd_mmio(int fd, hwaddr addr, uint32_t val,
+int kvm_enable_cap_vm(KVMState *s, unsigned int capability, ...)
+{
+struct kvm_enable_cap cap = {};
+va_list ap;
+int i;
+
+cap.cap = capability;
+va_start(ap, capability);
+for (i = 0; i 4; i++) {
+cap.args[i] = va_arg(ap, uint64_t);
Is this legit? Can we just pull items off the stack without running beyond?
For inspiration on how to know the number of arguments that got passed in,
check out
http://git.qemu.org/?p=qemu.git;a=blob;f=include/sysemu/device_tree.h#l40
Ah, that is probably better than splattering args with random stuff.
Will try.
Huh, how does
integer type array[] = { __VA_ARGS__ };
even compile? On both i386 and s390, I get initialization makes
integer from pointer without a cast - is arm different?
This only works when used inside a #define, since then the preprocessor
resolves __VA_ARGS__ :).
Alex
Re: [Qemu-devel] [PATCH 2/9] kvm: add kvm_enable_cap_{vm,vcpu}
On Wed, 16 Apr 2014 16:26:30 +0200
Alexander Graf ag...@suse.de wrote:
On 16.04.14 16:25, Cornelia Huck wrote:
On Wed, 16 Apr 2014 13:58:31 +0200
Cornelia Huck cornelia.h...@de.ibm.com wrote:
On Wed, 16 Apr 2014 13:38:27 +0200
Alexander Graf ag...@suse.de wrote:
On 16.04.2014, at 13:22, Alexander Graf ag...@suse.de wrote:
On 14.04.14 18:48, Cornelia Huck wrote:
Provide helper functions for enabling capabilities (on a vcpu and on a
vm).
Reviewed-by: Thomas Huth th...@linux.vnet.ibm.com
Signed-off-by: Cornelia Huck cornelia.h...@de.ibm.com
---
include/sysemu/kvm.h |4
kvm-all.c| 33 -
2 files changed, 36 insertions(+), 1 deletion(-)
diff --git a/include/sysemu/kvm.h b/include/sysemu/kvm.h
index 0bee1e8..2ff5ad3 100644
--- a/include/sysemu/kvm.h
+++ b/include/sysemu/kvm.h
@@ -294,6 +294,10 @@ bool kvm_arch_stop_on_emulation_error(CPUState
*cpu);
int kvm_check_extension(KVMState *s, unsigned int extension);
+int kvm_enable_cap_vm(KVMState *s, unsigned int capability, ...);
+
+int kvm_enable_cap_vcpu(CPUState *cpu, unsigned int capability, ...);
+
uint32_t kvm_arch_get_supported_cpuid(KVMState *env, uint32_t
function,
uint32_t index, int reg);
diff --git a/kvm-all.c b/kvm-all.c
index cd4111d..658e50c 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -501,7 +501,38 @@ int kvm_check_extension(KVMState *s, unsigned int
extension)
return ret;
}
-static int kvm_set_ioeventfd_mmio(int fd, hwaddr addr, uint32_t val,
+int kvm_enable_cap_vm(KVMState *s, unsigned int capability, ...)
+{
+struct kvm_enable_cap cap = {};
+va_list ap;
+int i;
+
+cap.cap = capability;
+va_start(ap, capability);
+for (i = 0; i 4; i++) {
+cap.args[i] = va_arg(ap, uint64_t);
Is this legit? Can we just pull items off the stack without running
beyond?
For inspiration on how to know the number of arguments that got passed
in, check out
http://git.qemu.org/?p=qemu.git;a=blob;f=include/sysemu/device_tree.h#l40
Ah, that is probably better than splattering args with random stuff.
Will try.
Huh, how does
integer type array[] = { __VA_ARGS__ };
even compile? On both i386 and s390, I get initialization makes
integer from pointer without a cast - is arm different?
This only works when used inside a #define, since then the preprocessor
resolves __VA_ARGS__ :).
Obviously. That's where I got the error :)
Re: [Qemu-devel] [Xen-devel] [PATCH 1/2] xen: fix usage of ENODATA
On 15/04/14 14:33, Egger, Christoph wrote:
On 15.04.14 10:33, Roger Pau Monne wrote:
ENODATA doesn't exist on FreeBSD, so ENODATA errors returned by the
hypervisor are translated to ENOENT.
Also, the error code is returned in errno if the call returns -1, so
compare the error code with the value in errno instead of the value
returned by the function.
Signed-off-by: Roger Pau Monné roger@citrix.com
Cc: xen-de...@lists.xenproject.org
Cc: Stefano Stabellini stefano.stabell...@eu.citrix.com
Cc: Anthony Perard anthony.per...@citrix.com
---
xen-all.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/xen-all.c b/xen-all.c
index 0b4d934..4026b7b 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -499,11 +499,15 @@ static void xen_sync_dirty_bitmap(XenIOState *state,
start_addr TARGET_PAGE_BITS, npages,
bitmap);
if (rc 0) {
-if (rc != -ENODATA) {
+#ifdef ENODATA
+if (errno == ENODATA) {
+#else
+if (errno == ENOENT) {
+#endif
This does not look good to me.
I suggest this:
#ifndef ENODATA
#define ENODATA ENOENT
#endif
Hello Christoph,
Thanks for the review, I slightly prefer my original proposal over what
you suggest, I think it's more clear that there are different error
codes, while your suggestion simply masks the fact than FreeBSD doesn't
have ENODATA. Anyway, I wouldn't mind changing it if the maintainer
prefers your approach.
Roger.
Re: [Qemu-devel] [PATCH 4/9] s390x: Add I/O adapter registration.
On Wed, 16 Apr 2014 13:25:49 +0200
Alexander Graf ag...@suse.de wrote:
On 14.04.14 18:48, Cornelia Huck wrote:
Register an I/O adapter interrupt source for when virtio-ccw devices start
using adapter interrupts.
Reviewed-by: Thomas Huth th...@linux.vnet.ibm.com
Signed-off-by: Cornelia Huck cornelia.h...@de.ibm.com
---
hw/intc/s390_flic.c | 59
+
hw/s390x/css.c| 51 ++
hw/s390x/css.h|4
hw/s390x/virtio-ccw.c |4
hw/s390x/virtio-ccw.h |1 +
target-s390x/cpu.h| 33 +++
6 files changed, 152 insertions(+)
diff --git a/hw/intc/s390_flic.c b/hw/intc/s390_flic.c
index b2ef3e3..c033c8a 100644
--- a/hw/intc/s390_flic.c
+++ b/hw/intc/s390_flic.c
@@ -21,6 +21,11 @@
#define FLIC_FAILED (-1UL)
#define FLIC_SAVEVM_VERSION 1
+static KVMS390FLICState *s390_get_flic(void)
+{
+return KVM_S390_FLIC(object_resolve_path(/machine/s390-flic, NULL));
+}
+
void s390_flic_init(void)
{
DeviceState *dev;
@@ -148,6 +153,60 @@ static int __get_all_irqs(KVMS390FLICState *flic,
return r;
}
+int kvm_s390_register_io_adapter(uint32_t id, uint8_t isc, bool swap,
+ bool is_maskable)
+{
+struct kvm_s390_io_adapter adapter = {
+.id = id,
+.isc = isc,
+.maskable = is_maskable,
+.swap = swap,
+};
+KVMS390FLICState *flic = s390_get_flic();
+int r, ret;
+struct kvm_device_attr attr = {
+.group = KVM_DEV_FLIC_ADAPTER_REGISTER,
+.addr = (uint64_t)adapter,
+};
+
+if (!flic) {
+return -ENOSYS;
+}
+if (!kvm_check_extension(kvm_state, KVM_CAP_IRQ_ROUTING)) {
+return -ENOSYS;
+}
+
+r = ioctl(flic-fd, KVM_SET_DEVICE_ATTR, attr);
+
+ret = r ? -errno : 0;
+return ret;
+}
+
+int kvm_s390_io_adapter_map(uint32_t id, uint64_t map_addr, bool do_map)
+{
+struct kvm_s390_io_adapter_req req = {
+.id = id,
+.type = do_map ? KVM_S390_IO_ADAPTER_MAP :
KVM_S390_IO_ADAPTER_UNMAP,
+.addr = map_addr,
+};
+KVMS390FLICState *flic = s390_get_flic();
+struct kvm_device_attr attr = {
+.group = KVM_DEV_FLIC_ADAPTER_MODIFY,
+.addr = (uint64_t)req,
+};
+int r;
+
+if (!flic) {
+return -ENOSYS;
+}
+if (!kvm_check_extension(kvm_state, KVM_CAP_IRQ_ROUTING)) {
+return -ENOSYS;
+}
+
+r = ioctl(flic-fd, KVM_SET_DEVICE_ATTR, attr);
+return r ? -errno : 0;
+}
+
/**
* kvm_flic_save - Save pending floating interrupts
* @f: QEMUFile containing migration state
diff --git a/hw/s390x/css.c b/hw/s390x/css.c
index 7074d2b..a6d173f 100644
--- a/hw/s390x/css.c
+++ b/hw/s390x/css.c
@@ -39,6 +39,13 @@ typedef struct CssImage {
ChpInfo chpids[MAX_CHPID + 1];
} CssImage;
+typedef struct IoAdapter {
+uint32_t id;
+uint8_t type;
+uint8_t isc;
+QTAILQ_ENTRY(IoAdapter) sibling;
+} IoAdapter;
+
typedef struct ChannelSubSys {
QTAILQ_HEAD(, CrwContainer) pending_crws;
bool do_crw_mchk;
@@ -49,6 +56,7 @@ typedef struct ChannelSubSys {
uint64_t chnmon_area;
CssImage *css[MAX_CSSID + 1];
uint8_t default_cssid;
+QTAILQ_HEAD(, IoAdapter) io_adapters;
} ChannelSubSys;
static ChannelSubSys *channel_subsys;
@@ -69,6 +77,48 @@ int css_create_css_image(uint8_t cssid, bool
default_image)
return 0;
}
+int css_register_io_adapter(uint8_t type, uint8_t isc, bool swap,
+bool maskable, uint32_t *id)
+{
+IoAdapter *adapter;
+bool found = false;
+int ret;
+
+*id = 0;
+QTAILQ_FOREACH(adapter, channel_subsys-io_adapters, sibling) {
+if ((adapter-type == type) (adapter-isc == isc)) {
+*id = adapter-id;
+found = true;
+ret = 0;
+break;
+}
+if (adapter-id = *id) {
+*id = adapter-id + 1;
+}
+}
+if (found) {
+goto out;
+}
+adapter = g_new0(IoAdapter, 1);
+ret = s390_register_io_adapter(*id, isc, swap, maskable);
+if (ret == -ENOSYS) {
+/* Keep adapter even if we didn't register it anywhere. */
+ret = 0;
+}
+if (ret == 0) {
+adapter-id = *id;
+adapter-isc = isc;
+adapter-type = type;
+QTAILQ_INSERT_TAIL(channel_subsys-io_adapters, adapter, sibling);
+} else {
+g_free(adapter);
+fprintf(stderr, Unexpected error %d when registering adapter
%d\n,
+ret, *id);
+}
+out:
+return ret;
+}
+
uint16_t
Re: [Qemu-devel] [PATCH v4 3/6] qemu-img: Implement commit like QMP
Am 12.04.2014 um 20:57 hat Max Reitz geschrieben:
qemu-img should use QMP commands whenever possible in order to ensure
feature completeness of both online and offline image operations. As
qemu-img itself has no access to QMP (since this would basically require
just everything being linked into qemu-img), imitate QMP's
implementation of block-commit by using commit_active_start() and then
waiting for the block job to finish.
This new implementation does not empty the snapshot image, as opposed to
the old implementation using bdrv_commit(). However, as QMP's
block-commit apparently never did this and as qcow2 (which is probably
qemu's standard image format) does not even implement the required
function (bdrv_make_empty()), it does not seem necessary.
Signed-off-by: Max Reitz mre...@redhat.com
---
block/Makefile.objs | 2 +-
qemu-img.c | 86
+
2 files changed, 68 insertions(+), 20 deletions(-)
diff --git a/block/Makefile.objs b/block/Makefile.objs
index fd88c03..2c37e80 100644
--- a/block/Makefile.objs
+++ b/block/Makefile.objs
@@ -9,6 +9,7 @@ block-obj-y += snapshot.o qapi.o
block-obj-$(CONFIG_WIN32) += raw-win32.o win32-aio.o
block-obj-$(CONFIG_POSIX) += raw-posix.o
block-obj-$(CONFIG_LINUX_AIO) += linux-aio.o
+block-obj-y += mirror.o
ifeq ($(CONFIG_POSIX),y)
block-obj-y += nbd.o nbd-client.o sheepdog.o
@@ -22,7 +23,6 @@ endif
common-obj-y += stream.o
common-obj-y += commit.o
-common-obj-y += mirror.o
common-obj-y += backup.o
iscsi.o-cflags := $(LIBISCSI_CFLAGS)
diff --git a/qemu-img.c b/qemu-img.c
index 8455994..9fe6384 100644
--- a/qemu-img.c
+++ b/qemu-img.c
@@ -30,6 +30,7 @@
#include qemu/osdep.h
#include sysemu/sysemu.h
#include block/block_int.h
+#include block/blockjob.h
#include block/qapi.h
#include getopt.h
@@ -682,12 +683,49 @@ fail:
return ret;
}
+struct CommonBlockJobCBInfo {
+Error **errp;
+bool done;
Looks unused (set, but never read).
+};
+
+static void common_block_job_cb(void *opaque, int ret)
+{
+struct CommonBlockJobCBInfo *cbi = opaque;
+
+if (ret 0) {
+error_setg_errno(cbi-errp, -ret, Block job failed);
+}
In practice, I guess this will give us rather bad error messages.
Perhaps we need to replace 'int ret' with 'Error *errp' for block job
callbacks in a followup.
+
+cbi-done = true;
+}
+
+static void run_block_job(BlockJob *job, struct CommonBlockJobCBInfo *cbi)
+{
+BlockJobInfo *info;
+
+do {
+qemu_aio_wait();
+
+info = block_job_query(job);
Where does info get freed?
+
+if (!info-busy info-offset info-len) {
+block_job_resume(job);
+}
+} while (info-offset info-len);
+
+block_job_complete_sync(job, cbi-errp);
+}
+
+/* Same as in block.c */
+#define COMMIT_BUF_SECTORS 2048
[...]
+commit_active_start(bs, base_bs, 0, COMMIT_BUF_SECTORS
BDRV_SECTOR_BITS,
+BLOCKDEV_ON_ERROR_REPORT, common_block_job_cb, cbi,
+local_err);
Though bdrv_commit() uses it for a different purpose: There it's the
buffer size that is used for committing. A single request can never be
larger than this value, but depending on bdrv_is_allocated() it can be
smaller. So the granularity for the decision whether to copy data is
still the granularity of bdrv_is_allocated(), i.e. one cluster.
For the mirror block job, the decision is taken on the granularity that
you specify. This should be the same as for bdrv_commit(), i.e. the
default that you get when you specify 0. mirror_start_job() also has a
buf_size parameter, which is however not exposed by
commit_active_start(). This is where COMMIT_BUF_SECTORS would be right.
Kevin
Re: [Qemu-devel] [PATCH v4 2/6] blockjob: Introduce block_job_complete_sync()
Am 12.04.2014 um 20:57 hat Max Reitz geschrieben:
Implement block_job_complete_sync() by doing the exact same thing as
block_job_cancel_sync() does, only with calling block_job_complete()
instead of block_job_cancel().
Signed-off-by: Max Reitz mre...@redhat.com
---
blockjob.c | 24 ++--
include/block/blockjob.h | 15 +++
2 files changed, 37 insertions(+), 2 deletions(-)
diff --git a/blockjob.c b/blockjob.c
index b3ce14c..d12f3ea 100644
--- a/blockjob.c
+++ b/blockjob.c
@@ -165,7 +165,9 @@ static void block_job_cancel_cb(void *opaque, int ret)
data-cb(data-opaque, ret);
}
-int block_job_cancel_sync(BlockJob *job)
+static int block_job_finish_sync(BlockJob *job,
+ void (*finish)(BlockJob *, Error **errp),
+ Error **errp)
{
struct BlockCancelData data;
BlockDriverState *bs = job-bs;
@@ -181,13 +183,31 @@ int block_job_cancel_sync(BlockJob *job)
data.ret = -EINPROGRESS;
job-cb = block_job_cancel_cb;
Rename this as block_job_finish_cb?
Kevin
Re: [Qemu-devel] [PATCH 4/9] s390x: Add I/O adapter registration.
On 16.04.14 16:38, Cornelia Huck wrote:
On Wed, 16 Apr 2014 13:25:49 +0200
Alexander Graf ag...@suse.de wrote:
On 14.04.14 18:48, Cornelia Huck wrote:
Register an I/O adapter interrupt source for when virtio-ccw devices start
using adapter interrupts.
Reviewed-by: Thomas Huth th...@linux.vnet.ibm.com
Signed-off-by: Cornelia Huck cornelia.h...@de.ibm.com
---
hw/intc/s390_flic.c | 59
+
hw/s390x/css.c| 51 ++
hw/s390x/css.h|4
hw/s390x/virtio-ccw.c |4
hw/s390x/virtio-ccw.h |1 +
target-s390x/cpu.h| 33 +++
6 files changed, 152 insertions(+)
diff --git a/hw/intc/s390_flic.c b/hw/intc/s390_flic.c
index b2ef3e3..c033c8a 100644
--- a/hw/intc/s390_flic.c
+++ b/hw/intc/s390_flic.c
@@ -21,6 +21,11 @@
#define FLIC_FAILED (-1UL)
#define FLIC_SAVEVM_VERSION 1
+static KVMS390FLICState *s390_get_flic(void)
+{
+return KVM_S390_FLIC(object_resolve_path(/machine/s390-flic, NULL));
+}
+
void s390_flic_init(void)
{
DeviceState *dev;
@@ -148,6 +153,60 @@ static int __get_all_irqs(KVMS390FLICState *flic,
return r;
}
+int kvm_s390_register_io_adapter(uint32_t id, uint8_t isc, bool swap,
+ bool is_maskable)
+{
+struct kvm_s390_io_adapter adapter = {
+.id = id,
+.isc = isc,
+.maskable = is_maskable,
+.swap = swap,
+};
+KVMS390FLICState *flic = s390_get_flic();
+int r, ret;
+struct kvm_device_attr attr = {
+.group = KVM_DEV_FLIC_ADAPTER_REGISTER,
+.addr = (uint64_t)adapter,
+};
+
+if (!flic) {
+return -ENOSYS;
+}
+if (!kvm_check_extension(kvm_state, KVM_CAP_IRQ_ROUTING)) {
+return -ENOSYS;
+}
+
+r = ioctl(flic-fd, KVM_SET_DEVICE_ATTR, attr);
+
+ret = r ? -errno : 0;
+return ret;
+}
+
+int kvm_s390_io_adapter_map(uint32_t id, uint64_t map_addr, bool do_map)
+{
+struct kvm_s390_io_adapter_req req = {
+.id = id,
+.type = do_map ? KVM_S390_IO_ADAPTER_MAP : KVM_S390_IO_ADAPTER_UNMAP,
+.addr = map_addr,
+};
+KVMS390FLICState *flic = s390_get_flic();
+struct kvm_device_attr attr = {
+.group = KVM_DEV_FLIC_ADAPTER_MODIFY,
+.addr = (uint64_t)req,
+};
+int r;
+
+if (!flic) {
+return -ENOSYS;
+}
+if (!kvm_check_extension(kvm_state, KVM_CAP_IRQ_ROUTING)) {
+return -ENOSYS;
+}
+
+r = ioctl(flic-fd, KVM_SET_DEVICE_ATTR, attr);
+return r ? -errno : 0;
+}
+
/**
* kvm_flic_save - Save pending floating interrupts
* @f: QEMUFile containing migration state
diff --git a/hw/s390x/css.c b/hw/s390x/css.c
index 7074d2b..a6d173f 100644
--- a/hw/s390x/css.c
+++ b/hw/s390x/css.c
@@ -39,6 +39,13 @@ typedef struct CssImage {
ChpInfo chpids[MAX_CHPID + 1];
} CssImage;
+typedef struct IoAdapter {
+uint32_t id;
+uint8_t type;
+uint8_t isc;
+QTAILQ_ENTRY(IoAdapter) sibling;
+} IoAdapter;
+
typedef struct ChannelSubSys {
QTAILQ_HEAD(, CrwContainer) pending_crws;
bool do_crw_mchk;
@@ -49,6 +56,7 @@ typedef struct ChannelSubSys {
uint64_t chnmon_area;
CssImage *css[MAX_CSSID + 1];
uint8_t default_cssid;
+QTAILQ_HEAD(, IoAdapter) io_adapters;
} ChannelSubSys;
static ChannelSubSys *channel_subsys;
@@ -69,6 +77,48 @@ int css_create_css_image(uint8_t cssid, bool default_image)
return 0;
}
+int css_register_io_adapter(uint8_t type, uint8_t isc, bool swap,
+bool maskable, uint32_t *id)
+{
+IoAdapter *adapter;
+bool found = false;
+int ret;
+
+*id = 0;
+QTAILQ_FOREACH(adapter, channel_subsys-io_adapters, sibling) {
+if ((adapter-type == type) (adapter-isc == isc)) {
+*id = adapter-id;
+found = true;
+ret = 0;
+break;
+}
+if (adapter-id = *id) {
+*id = adapter-id + 1;
+}
+}
+if (found) {
+goto out;
+}
+adapter = g_new0(IoAdapter, 1);
+ret = s390_register_io_adapter(*id, isc, swap, maskable);
+if (ret == -ENOSYS) {
+/* Keep adapter even if we didn't register it anywhere. */
+ret = 0;
+}
+if (ret == 0) {
+adapter-id = *id;
+adapter-isc = isc;
+adapter-type = type;
+QTAILQ_INSERT_TAIL(channel_subsys-io_adapters, adapter, sibling);
+} else {
+g_free(adapter);
+fprintf(stderr, Unexpected error %d when registering adapter %d\n,
+ret, *id);
+}
+out:
+return ret;
+}
+
uint16_t css_build_subchannel_id(SubchDev *sch)
{
if (channel_subsys-max_cssid 0) {
@@ -1239,6 +1289,7 @@ static void css_init(void)
channel_subsys-do_crw_mchk = true;
channel_subsys-crws_lost = false;
channel_subsys-chnmon_active =
[Qemu-devel] [PATCH 1/7] megasas: Implement LD_LIST_QUERY
Newer firmware implement a LD_LIST_QUERY command, and due to a driver
issue no drives might be detected if this command isn't supported.
So add emulation for this command, too.
Cc: qemu-sta...@nongnu.org
Signed-off-by: Hannes Reinecke h...@suse.de
---
hw/scsi/megasas.c | 17 +
hw/scsi/mfi.h | 9 +
trace-events | 1 +
3 files changed, 27 insertions(+)
diff --git a/hw/scsi/megasas.c b/hw/scsi/megasas.c
index e6e1ffd..1781525 100644
--- a/hw/scsi/megasas.c
+++ b/hw/scsi/megasas.c
@@ -1106,6 +1106,21 @@ static int megasas_dcmd_ld_get_list(MegasasState *s,
MegasasCmd *cmd)
return MFI_STAT_OK;
}
+static int megasas_dcmd_ld_list_query(MegasasState *s, MegasasCmd *cmd)
+{
+uint16_t flags;
+
+/* mbox0 contains flags */
+flags = le16_to_cpu(cmd-frame-dcmd.mbox[0]);
+trace_megasas_dcmd_ld_list_query(cmd-index, flags);
+if (flags == MR_LD_QUERY_TYPE_ALL ||
+flags == MR_LD_QUERY_TYPE_EXPOSED_TO_HOST) {
+return megasas_dcmd_ld_get_list(s, cmd);
+}
+
+return MFI_STAT_OK;
+}
+
static int megasas_ld_get_info_submit(SCSIDevice *sdev, int lun,
MegasasCmd *cmd)
{
@@ -1409,6 +1424,8 @@ static const struct dcmd_cmd_tbl_t {
megasas_dcmd_dummy },
{ MFI_DCMD_LD_GET_LIST, LD_GET_LIST,
megasas_dcmd_ld_get_list},
+{ MFI_DCMD_LD_LIST_QUERY, LD_LIST_QUERY,
+ megasas_dcmd_ld_list_query },
{ MFI_DCMD_LD_GET_INFO, LD_GET_INFO,
megasas_dcmd_ld_get_info },
{ MFI_DCMD_LD_GET_PROP, LD_GET_PROP,
diff --git a/hw/scsi/mfi.h b/hw/scsi/mfi.h
index cd8355b..a3034f6 100644
--- a/hw/scsi/mfi.h
+++ b/hw/scsi/mfi.h
@@ -164,6 +164,7 @@ typedef enum {
MFI_DCMD_PD_BLINK = 0x02070100,
MFI_DCMD_PD_UNBLINK = 0x02070200,
MFI_DCMD_LD_GET_LIST = 0x0301,
+MFI_DCMD_LD_LIST_QUERY =0x03010100,
MFI_DCMD_LD_GET_INFO = 0x0302,
MFI_DCMD_LD_GET_PROP = 0x0303,
MFI_DCMD_LD_SET_PROP = 0x0304,
@@ -411,6 +412,14 @@ typedef enum {
MR_PD_QUERY_TYPE_EXPOSED_TO_HOST = 5, /*query for system drives */
} mfi_pd_query_type;
+typedef enum {
+MR_LD_QUERY_TYPE_ALL = 0,
+MR_LD_QUERY_TYPE_EXPOSED_TO_HOST = 1,
+MR_LD_QUERY_TYPE_USED_TGT_IDS = 2,
+MR_LD_QUERY_TYPE_CLUSTER_ACCESS = 3,
+MR_LD_QUERY_TYPE_CLUSTER_LOCALE = 4,
+} mfi_ld_query_type;
+
/*
* Other propertities and definitions
*/
diff --git a/trace-events b/trace-events
index 9303245..d97a7cf 100644
--- a/trace-events
+++ b/trace-events
@@ -664,6 +664,7 @@ megasas_dcmd_ld_get_list(int cmd, int num, int max) scmd
%d: DCMD LD get list:
megasas_dcmd_ld_get_info(int cmd, int ld_id) scmd %d: DCMD LD get info for
dev %d
megasas_dcmd_pd_get_info(int cmd, int pd_id) scmd %d: DCMD PD get info for
dev %d
megasas_dcmd_pd_list_query(int cmd, int flags) scmd %d: DCMD PD list query
flags %x
+megasas_dcmd_ld_list_query(int cmd, int flags) scmd %d: DCMD LD list query
flags %x
megasas_dcmd_unsupported(int cmd, unsigned long size) scmd %d: set properties
len %ld
megasas_abort_frame(int cmd, int abort_cmd) scmd %d: aborting frame %x
megasas_abort_no_cmd(int cmd, uint64_t context) scmd %d: no active command
for frame context % PRIx64
--
1.8.1.4
[Qemu-devel] [PATCHv2 0/7] megasas Update
Hi all, here is now the second iteration of my megasas update. Changes to the previous version: - Keep original emulation backwards-compatible by not changing defaults and keeping the original version number - Save MSIX vmstate - Reshuffle patches - Add different defaults for megasas and megasas-gen2 Hannes Reinecke (7): megasas: Implement LD_LIST_QUERY megasas: Enable MSI-X support megasas: Add MSI support megasas: add MegaRAID SAS 2108 emulation megasas: simplify trace event messages megasas: Decode register names MAINTAINERS: mark megasas as maintained MAINTAINERS | 6 ++ hw/scsi/megasas.c| 219 --- hw/scsi/mfi.h| 16 include/hw/pci/pci_ids.h | 1 + trace-events | 40 + 5 files changed, 233 insertions(+), 49 deletions(-) -- 1.8.1.4
[Qemu-devel] [PATCH 3/7] megasas: Add MSI support
Some hardware instances do support MSI, so we should do likewise.
Signed-off-by: Hannes Reinecke h...@suse.de
---
hw/scsi/megasas.c | 49 +++--
trace-events | 5 -
2 files changed, 47 insertions(+), 7 deletions(-)
diff --git a/hw/scsi/megasas.c b/hw/scsi/megasas.c
index df45286..a12cd92 100644
--- a/hw/scsi/megasas.c
+++ b/hw/scsi/megasas.c
@@ -21,6 +21,7 @@
#include hw/hw.h
#include hw/pci/pci.h
#include sysemu/dma.h
+#include hw/pci/msi.h
#include hw/pci/msix.h
#include qemu/iov.h
#include hw/scsi/scsi.h
@@ -43,9 +44,11 @@
#define MEGASAS_FLAG_USE_JBOD 0
#define MEGASAS_MASK_USE_JBOD (1 MEGASAS_FLAG_USE_JBOD)
-#define MEGASAS_FLAG_USE_MSIX 1
+#define MEGASAS_FLAG_USE_MSI 1
+#define MEGASAS_MASK_USE_MSI (1 MEGASAS_FLAG_USE_MSI)
+#define MEGASAS_FLAG_USE_MSIX 2
#define MEGASAS_MASK_USE_MSIX (1 MEGASAS_FLAG_USE_MSIX)
-#define MEGASAS_FLAG_USE_QUEUE64 2
+#define MEGASAS_FLAG_USE_QUEUE64 3
#define MEGASAS_MASK_USE_QUEUE64 (1 MEGASAS_FLAG_USE_QUEUE64)
static const char *mfi_frame_desc[] = {
@@ -132,6 +135,11 @@ static bool megasas_use_queue64(MegasasState *s)
return s-flags MEGASAS_MASK_USE_QUEUE64;
}
+static bool megasas_use_msi(MegasasState *s)
+{
+return s-flags MEGASAS_MASK_USE_MSI;
+}
+
static bool megasas_use_msix(MegasasState *s)
{
return s-flags MEGASAS_MASK_USE_MSIX;
@@ -538,6 +546,9 @@ static void megasas_complete_frame(MegasasState *s,
uint64_t context)
if (msix_enabled(pci_dev)) {
trace_megasas_msix_raise(0);
msix_notify(pci_dev, 0);
+} else if (msi_enabled(pci_dev)) {
+trace_megasas_msi_raise(0);
+msi_notify(pci_dev, 0);
} else {
trace_megasas_irq_raise();
pci_irq_assert(pci_dev);
@@ -1956,12 +1967,20 @@ static void megasas_mmio_write(void *opaque, hwaddr
addr,
break;
case MFI_OMSK:
s-intr_mask = val;
-if (!megasas_intr_enabled(s) !msix_enabled(pci_dev)) {
+if (!megasas_intr_enabled(s)
+!msi_enabled(pci_dev)
+!msix_enabled(pci_dev)) {
trace_megasas_irq_lower();
pci_irq_deassert(pci_dev);
}
if (megasas_intr_enabled(s)) {
-trace_megasas_intr_enabled();
+if (msix_enabled(pci_dev)) {
+trace_megasas_msix_enabled(0);
+} else if (msi_enabled(pci_dev)) {
+trace_megasas_msi_enabled(0);
+} else {
+trace_megasas_intr_enabled();
+}
} else {
trace_megasas_intr_disabled();
}
@@ -2101,7 +2120,12 @@ static void megasas_scsi_uninit(PCIDevice *d)
{
MegasasState *s = MEGASAS(d);
-msix_uninit(d, s-mmio_io, s-mmio_io);
+if (megasas_use_msix(s)) {
+msix_uninit(d, s-mmio_io, s-mmio_io);
+}
+if (megasas_use_msi(s)) {
+msi_uninit(d);
+}
memory_region_destroy(s-mmio_io);
memory_region_destroy(s-port_io);
memory_region_destroy(s-queue_io);
@@ -2140,6 +2164,10 @@ static int megasas_scsi_init(PCIDevice *dev)
memory_region_init_io(s-queue_io, OBJECT(s), megasas_queue_ops, s,
megasas-queue, 0x4);
+if (megasas_use_msi(s)
+msi_init(dev, 0x50, 1, true, false)) {
+s-flags = ~MEGASAS_MASK_USE_MSI;
+}
if (megasas_use_msix(s)
msix_init(dev, 15, s-mmio_io, 0, 0x2000,
s-mmio_io, 0, 0x3800, 0x68)) {
@@ -2176,7 +2204,6 @@ static int megasas_scsi_init(PCIDevice *dev)
s-fw_cmds = MEGASAS_MAX_FRAMES;
}
trace_megasas_init(s-fw_sge, s-fw_cmds,
- megasas_use_msix(s) ? MSI-X : INTx,
megasas_is_jbod(s) ? jbod : raid);
s-fw_luns = (MFI_MAX_LD MAX_SCSI_DEVS) ?
MAX_SCSI_DEVS : MFI_MAX_LD;
@@ -2201,6 +2228,13 @@ static int megasas_scsi_init(PCIDevice *dev)
return 0;
}
+static void
+megasas_write_config(PCIDevice *pci, uint32_t addr, uint32_t val, int len)
+{
+pci_default_write_config(pci, addr, val, len);
+msi_write_config(pci, addr, val, len);
+}
+
static Property megasas_properties[] = {
DEFINE_PROP_UINT32(max_sge, MegasasState, fw_sge,
MEGASAS_DEFAULT_SGE),
@@ -2208,6 +2242,8 @@ static Property megasas_properties[] = {
MEGASAS_DEFAULT_FRAMES),
DEFINE_PROP_STRING(hba_serial, MegasasState, hba_serial),
DEFINE_PROP_UINT64(sas_address, MegasasState, sas_addr, 0),
+DEFINE_PROP_BIT(use_msi, MegasasState, flags,
+MEGASAS_FLAG_USE_MSI, false),
DEFINE_PROP_BIT(use_msix, MegasasState, flags,
MEGASAS_FLAG_USE_MSIX, false),
DEFINE_PROP_BIT(use_jbod, MegasasState, flags,
@@ -2232,6 +2268,7 @@ static void megasas_class_init(ObjectClass *oc, void
*data)
dc-vmsd =
[Qemu-devel] [PATCH 2/7] megasas: Enable MSI-X support
MSI-X support has been fixed in qemu, so we can enable it again.
Signed-off-by: Hannes Reinecke h...@suse.de
---
hw/scsi/megasas.c | 19 ++-
1 file changed, 6 insertions(+), 13 deletions(-)
diff --git a/hw/scsi/megasas.c b/hw/scsi/megasas.c
index 1781525..df45286 100644
--- a/hw/scsi/megasas.c
+++ b/hw/scsi/megasas.c
@@ -2084,7 +2084,8 @@ static const VMStateDescription vmstate_megasas = {
.minimum_version_id = 0,
.minimum_version_id_old = 0,
.fields = (VMStateField[]) {
-VMSTATE_PCI_DEVICE(parent_obj, MegasasState),
+VMSTATE_PCIE_DEVICE(parent_obj, MegasasState),
+VMSTATE_MSIX(parent_obj, MegasasState),
VMSTATE_INT32(fw_state, MegasasState),
VMSTATE_INT32(intr_mask, MegasasState),
@@ -2100,9 +2101,7 @@ static void megasas_scsi_uninit(PCIDevice *d)
{
MegasasState *s = MEGASAS(d);
-#ifdef USE_MSIX
-msix_uninit(d, s-mmio_io);
-#endif
+msix_uninit(d, s-mmio_io, s-mmio_io);
memory_region_destroy(s-mmio_io);
memory_region_destroy(s-port_io);
memory_region_destroy(s-queue_io);
@@ -2141,15 +2140,11 @@ static int megasas_scsi_init(PCIDevice *dev)
memory_region_init_io(s-queue_io, OBJECT(s), megasas_queue_ops, s,
megasas-queue, 0x4);
-#ifdef USE_MSIX
-/* MSI-X support is currently broken */
if (megasas_use_msix(s)
-msix_init(dev, 15, s-mmio_io, 0, 0x2000)) {
+msix_init(dev, 15, s-mmio_io, 0, 0x2000,
+ s-mmio_io, 0, 0x3800, 0x68)) {
s-flags = ~MEGASAS_MASK_USE_MSIX;
}
-#else
-s-flags = ~MEGASAS_MASK_USE_MSIX;
-#endif
bar_type = PCI_BASE_ADDRESS_SPACE_MEMORY | PCI_BASE_ADDRESS_MEM_TYPE_64;
pci_register_bar(dev, 0, bar_type, s-mmio_io);
@@ -2168,7 +2163,7 @@ static int megasas_scsi_init(PCIDevice *dev)
s-sas_addr |= PCI_FUNC(dev-devfn);
}
if (!s-hba_serial) {
- s-hba_serial = g_strdup(MEGASAS_HBA_SERIAL);
+s-hba_serial = g_strdup(MEGASAS_HBA_SERIAL);
}
if (s-fw_sge = MEGASAS_MAX_SGE - MFI_PASS_FRAME_SIZE) {
s-fw_sge = MEGASAS_MAX_SGE - MFI_PASS_FRAME_SIZE;
@@ -2213,10 +2208,8 @@ static Property megasas_properties[] = {
MEGASAS_DEFAULT_FRAMES),
DEFINE_PROP_STRING(hba_serial, MegasasState, hba_serial),
DEFINE_PROP_UINT64(sas_address, MegasasState, sas_addr, 0),
-#ifdef USE_MSIX
DEFINE_PROP_BIT(use_msix, MegasasState, flags,
MEGASAS_FLAG_USE_MSIX, false),
-#endif
DEFINE_PROP_BIT(use_jbod, MegasasState, flags,
MEGASAS_FLAG_USE_JBOD, false),
DEFINE_PROP_END_OF_LIST(),
--
1.8.1.4
Re: [Qemu-devel] [PATCH 6/9] s390x/virtio-ccw: Wire up irq routing and irqfds.
On Wed, 16 Apr 2014 13:29:05 +0200
Alexander Graf ag...@suse.de wrote:
On 14.04.14 18:48, Cornelia Huck wrote:
Make use of the new s390 adapter irq routing support to enable real
in-kernel irqfds for virtio-ccw with adapter interrupts.
Note that s390 doesn't provide the common KVM_CAP_IRQCHIP capability, but
rather needs KVM_CAP_S390_IRQCHIP to be enabled. This is to ensure backward
compatibility.
Reviewed-by: Thomas Huth th...@linux.vnet.ibm.com
Signed-off-by: Cornelia Huck cornelia.h...@de.ibm.com
---
hw/s390x/virtio-ccw.c | 165
hw/s390x/virtio-ccw.h |2 +
include/hw/s390x/adapter.h | 23 ++
include/qemu/typedefs.h|1 +
include/sysemu/kvm.h |2 +
kvm-all.c | 38 +-
kvm-stub.c |5 ++
target-s390x/kvm.c |5 ++
8 files changed, 228 insertions(+), 13 deletions(-)
create mode 100644 include/hw/s390x/adapter.h
diff --git a/hw/s390x/virtio-ccw.c b/hw/s390x/virtio-ccw.c
index 69efa6c..5612ccc 100644
--- a/hw/s390x/virtio-ccw.c
+++ b/hw/s390x/virtio-ccw.c
@@ -21,6 +21,7 @@
#include hw/sysbus.h
#include qemu/bitops.h
#include hw/virtio/virtio-bus.h
+#include hw/s390x/adapter.h
#include ioinst.h
#include css.h
@@ -48,7 +49,7 @@ static IndAddr *get_indicator(hwaddr ind_addr, int len)
return indicator;
}
-static void release_indicator(IndAddr *indicator)
+static void release_indicator(uint32_t adapter_id, IndAddr *indicator)
{
assert(indicator-refcnt 0);
indicator-refcnt--;
@@ -56,9 +57,31 @@ static void release_indicator(IndAddr *indicator)
return;
}
QTAILQ_REMOVE(indicator_addresses, indicator, sibling);
+if (indicator-map) {
+s390_io_adapter_map(adapter_id, indicator-map, false);
+}
g_free(indicator);
}
+static int map_indicator(uint32_t adapter_id, IndAddr *indicator)
+{
+int ret;
+
+if (indicator-map) {
+return 0; /* already mapped is not an error */
+}
+indicator-map = indicator-addr;
+ret = s390_io_adapter_map(adapter_id, indicator-map, true);
+if ((ret != 0) (ret != -ENOSYS)) {
+goto out_err;
+}
+return 0;
+
+out_err:
+indicator-map = 0;
+return -EFAULT;
+}
+
static void virtio_ccw_bus_new(VirtioBusState *bus, size_t bus_size,
VirtioCcwDevice *dev);
@@ -733,7 +756,7 @@ static int virtio_ccw_exit(VirtioCcwDevice *dev)
g_free(sch);
}
if (dev-indicators) {
-release_indicator(dev-indicators);
+release_indicator(dev-adapter_id, dev-indicators);
dev-indicators = NULL;
}
return 0;
@@ -1034,15 +1057,15 @@ static void virtio_ccw_reset(DeviceState *d)
virtio_reset(vdev);
css_reset_sch(dev-sch);
if (dev-indicators) {
-release_indicator(dev-indicators);
+release_indicator(dev-adapter_id, dev-indicators);
dev-indicators = NULL;
}
if (dev-indicators2) {
-release_indicator(dev-indicators2);
+release_indicator(dev-adapter_id, dev-indicators2);
dev-indicators2 = NULL;
}
if (dev-summary_indicator) {
-release_indicator(dev-summary_indicator);
+release_indicator(dev-adapter_id, dev-summary_indicator);
dev-summary_indicator = NULL;
}
}
@@ -1078,6 +1101,100 @@ static int virtio_ccw_set_host_notifier(DeviceState
*d, int n, bool assign)
return virtio_ccw_set_guest2host_notifier(dev, n, assign, false);
}
+static int virtio_ccw_get_adapter_info(VirtioCcwDevice *dev,
+ AdapterInfo *adapter)
+{
+int r;
+
+if (!dev-sch-thinint_active) {
+return -EINVAL;
+}
+
+r = map_indicator(dev-adapter_id, dev-summary_indicator);
+if (r) {
+return r;
+}
+r = map_indicator(dev-adapter_id, dev-indicators);
+if (r) {
+return r;
+}
+adapter-summary_addr = dev-summary_indicator-map;
+adapter-ind_addr = dev-indicators-map;
+adapter-ind_offset = dev-ind_bit;
+adapter-summary_offset = 7;
+adapter-adapter_id = dev-adapter_id;
+
+return 0;
+}
+
+static int virtio_ccw_setup_irqroutes(VirtioCcwDevice *dev, int nvqs)
+{
+int i;
+VirtIODevice *vdev = virtio_bus_get_device(dev-bus);
+int ret;
+AdapterInfo adapter;
+
+ret = virtio_ccw_get_adapter_info(dev, adapter);
+if (ret) {
+return ret;
+}
+for (i = 0; i nvqs; i++) {
+if (!virtio_queue_get_num(vdev, i)) {
+break;
+}
+ret = kvm_irqchip_add_adapter_route(kvm_state, adapter);
Why is
[Qemu-devel] [PATCH 4/7] megasas: add MegaRAID SAS 2108 emulation
The 2108 chip supports MSI and MSI-X, so update the emulation
to support both chips.
Signed-off-by: Hannes Reinecke h...@suse.de
---
hw/scsi/megasas.c| 118 ++-
hw/scsi/mfi.h| 7 +++
include/hw/pci/pci_ids.h | 1 +
3 files changed, 114 insertions(+), 12 deletions(-)
diff --git a/hw/scsi/megasas.c b/hw/scsi/megasas.c
index a12cd92..a5bfeba 100644
--- a/hw/scsi/megasas.c
+++ b/hw/scsi/megasas.c
@@ -31,6 +31,7 @@
#include mfi.h
#define MEGASAS_VERSION 1.70
+#define MEGASAS_VERSION_GEN2 1.80
#define MEGASAS_MAX_FRAMES 2048 /* Firmware limit at 65535 */
#define MEGASAS_DEFAULT_FRAMES 1000 /* Windows requires this */
#define MEGASAS_MAX_SGE 128 /* Firmware limit */
@@ -90,6 +91,8 @@ typedef struct MegasasState {
int intr_mask;
int doorbell;
int busy;
+int diag;
+int adp_reset;
MegasasCmd *event_cmd;
int event_locale;
@@ -115,12 +118,18 @@ typedef struct MegasasState {
} MegasasState;
#define TYPE_MEGASAS megasas
+#define TYPE_MEGASAS_GEN2 megasas-gen2
#define MEGASAS(obj) \
OBJECT_CHECK(MegasasState, (obj), TYPE_MEGASAS)
#define MEGASAS_INTR_DISABLED_MASK 0x
+static bool megasas_is_gen2(PCIDeviceClass *dc)
+{
+return dc-device_id == PCI_DEVICE_ID_LSI_SAS0079;
+}
+
static bool megasas_intr_enabled(MegasasState *s)
{
if ((s-intr_mask MEGASAS_INTR_DISABLED_MASK) !=
@@ -681,6 +690,7 @@ static void megasas_finish_dcmd(MegasasCmd *cmd, uint32_t
iov_size)
static int megasas_ctrl_get_info(MegasasState *s, MegasasCmd *cmd)
{
PCIDevice *pci_dev = PCI_DEVICE(s);
+PCIDeviceClass *pci_class = PCI_DEVICE_GET_CLASS(pci_dev);
struct mfi_ctrl_info info;
size_t dcmd_size = sizeof(info);
BusChild *kid;
@@ -694,10 +704,10 @@ static int megasas_ctrl_get_info(MegasasState *s,
MegasasCmd *cmd)
return MFI_STAT_INVALID_PARAMETER;
}
-info.pci.vendor = cpu_to_le16(PCI_VENDOR_ID_LSI_LOGIC);
-info.pci.device = cpu_to_le16(PCI_DEVICE_ID_LSI_SAS1078);
-info.pci.subvendor = cpu_to_le16(PCI_VENDOR_ID_LSI_LOGIC);
-info.pci.subdevice = cpu_to_le16(0x1013);
+info.pci.vendor = cpu_to_le16(pci_class-vendor_id);
+info.pci.device = cpu_to_le16(pci_class-device_id);
+info.pci.subvendor = cpu_to_le16(pci_class-subsystem_vendor_id);
+info.pci.subdevice = cpu_to_le16(pci_class-subsystem_id);
/*
* For some reason the firmware supports
@@ -723,11 +733,21 @@ static int megasas_ctrl_get_info(MegasasState *s,
MegasasCmd *cmd)
num_ld_disks++;
}
-memcpy(info.product_name, MegaRAID SAS 8708EM2, 20);
+if (megasas_is_gen2(pci_class)) {
+memcpy(info.product_name, LSI MegaRAID SAS 9260-8i, 24);
+} else {
+memcpy(info.product_name, LSI MegaRAID SAS 8708EM2, 24);
+}
snprintf(info.serial_number, 32, %s, s-hba_serial);
snprintf(info.package_version, 0x60, %s-QEMU, QEMU_VERSION);
memcpy(info.image_component[0].name, APP, 3);
-memcpy(info.image_component[0].version, MEGASAS_VERSION -QEMU, 9);
+if (megasas_is_gen2(pci_class)) {
+memcpy(info.image_component[0].version,
+ MEGASAS_VERSION_GEN2 -QEMU, 9);
+} else {
+memcpy(info.image_component[0].version,
+ MEGASAS_VERSION -QEMU, 9);
+}
memcpy(info.image_component[0].build_date, __DATE__, 11);
memcpy(info.image_component[0].build_time, __TIME__, 8);
info.image_component_count = 1;
@@ -1907,6 +1927,7 @@ static uint64_t megasas_mmio_read(void *opaque, hwaddr
addr,
unsigned size)
{
MegasasState *s = opaque;
+PCIDeviceClass *pci_class = PCI_DEVICE_GET_CLASS(s);
uint32_t retval = 0;
switch (addr) {
@@ -1922,7 +1943,11 @@ static uint64_t megasas_mmio_read(void *opaque, hwaddr
addr,
break;
case MFI_OSTS:
if (megasas_intr_enabled(s) s-doorbell) {
-retval = MFI_1078_RM | 1;
+if (megasas_is_gen2(pci_class)) {
+retval = MFI_GEN2_RM;
+} else {
+retval = MFI_1078_RM | 1;
+}
}
break;
case MFI_OMSK:
@@ -1931,6 +1956,9 @@ static uint64_t megasas_mmio_read(void *opaque, hwaddr
addr,
case MFI_ODCR0:
retval = s-doorbell;
break;
+case MFI_DIAG:
+retval = s-diag;
+break;
default:
trace_megasas_mmio_invalid_readl(addr);
break;
@@ -1939,6 +1967,8 @@ static uint64_t megasas_mmio_read(void *opaque, hwaddr
addr,
return retval;
}
+static int adp_reset_seq[] = {0x00, 0x04, 0x0b, 0x02, 0x07, 0x0d};
+
static void megasas_mmio_write(void *opaque, hwaddr addr,
uint64_t val, unsigned size)
{
@@ -2013,6 +2043,28 @@ static void megasas_mmio_write(void *opaque, hwaddr addr,
frame_count = (val 1) 0xF;
megasas_handle_frame(s, frame_addr, frame_count);
[Qemu-devel] [PATCH 5/7] megasas: simplify trace event messages
The trace events already contain the function name, so the actual message doesn't need to contain any of these informations. Signed-off-by: Hannes Reinecke h...@suse.de --- trace-events | 32 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/trace-events b/trace-events index 79d1f51..c12fc02 100644 --- a/trace-events +++ b/trace-events @@ -611,16 +611,16 @@ megasas_init_firmware(uint64_t pa) pa % PRIx64 megasas_init_queue(uint64_t queue_pa, int queue_len, uint64_t head, uint64_t tail, uint32_t flags) queue at % PRIx64 len %d head % PRIx64 tail % PRIx64 flags %x megasas_initq_map_failed(int frame) scmd %d: failed to map queue megasas_initq_mismatch(int queue_len, int fw_cmds) queue size %d max fw cmds %d -megasas_qf_found(unsigned int index, uint64_t pa) found mapped frame %x pa % PRIx64 +megasas_qf_found(unsigned int index, uint64_t pa) mapped frame %x pa % PRIx64 megasas_qf_new(unsigned int index, void *cmd) return new frame %x cmd %p megasas_qf_failed(unsigned long pa) all frames busy for frame %lx megasas_qf_enqueue(unsigned int index, unsigned int count, uint64_t context, unsigned int tail, int busy) enqueue frame %x count %d context % PRIx64 tail %x busy %d -megasas_qf_update(unsigned int head, unsigned int busy) update reply queue head %x busy %d +megasas_qf_update(unsigned int head, unsigned int busy) reply queue head %x busy %d megasas_qf_map_failed(int cmd, unsigned long frame) scmd %d: frame %lu megasas_qf_complete_noirq(uint64_t context) context % PRIx64 megasas_qf_complete(uint64_t context, unsigned int tail, unsigned int offset, int busy, unsigned int doorbell) context % PRIx64 tail %x offset %d busy %d doorbell %x megasas_frame_busy(uint64_t addr) frame % PRIx64 busy -megasas_unhandled_frame_cmd(int cmd, uint8_t frame_cmd) scmd %d: Unhandled MFI cmd %x +megasas_unhandled_frame_cmd(int cmd, uint8_t frame_cmd) scmd %d: MFI cmd %x megasas_handle_scsi(const char *frame, int bus, int dev, int lun, void *sdev, unsigned long size) %s dev %x/%x/%x sdev %p xfer %lu megasas_scsi_target_not_present(const char *frame, int bus, int dev, int lun) %s dev %x/%x/%x target not present megasas_scsi_invalid_cdb_len(const char *frame, int bus, int dev, int lun, int len) %s dev %x/%x/%x invalid cdb len %d @@ -632,8 +632,8 @@ megasas_scsi_req_alloc_failed(const char *frame, int dev, int lun) %s dev %x/%x megasas_scsi_read_start(int cmd, int len) scmd %d: transfer %d bytes of data megasas_scsi_write_start(int cmd, int len) scmd %d: transfer %d bytes of data megasas_scsi_nodata(int cmd) scmd %d: no data to be transferred -megasas_scsi_complete(int cmd, uint32_t status, int len, int xfer) scmd %d: finished with status %x, len %u/%u -megasas_command_complete(int cmd, uint32_t status, uint32_t resid) scmd %d: command completed, status %x, residual %d +megasas_scsi_complete(int cmd, uint32_t status, int len, int xfer) scmd %d: status %x, len %u/%u +megasas_command_complete(int cmd, uint32_t status, uint32_t resid) scmd %d: status %x, residual %d megasas_handle_io(int cmd, const char *frame, int dev, int lun, unsigned long lba, unsigned long count) scmd %d: %s dev %x/%x lba %lx count %lu megasas_io_target_not_present(int cmd, const char *frame, int dev, int lun) scmd %d: %s dev 1/%x/%x LUN not present megasas_io_read_start(int cmd, unsigned long lba, unsigned long count, unsigned long len) scmd %d: start LBA %lx %lu blocks (%lu bytes) @@ -650,23 +650,23 @@ megasas_handle_dcmd(int cmd, int opcode) scmd %d: MFI DCMD opcode %x megasas_finish_dcmd(int cmd, int size) scmd %d: MFI DCMD wrote %d bytes megasas_dcmd_req_alloc_failed(int cmd, const char *desc) scmd %d: %s alloc failed megasas_dcmd_internal_submit(int cmd, const char *desc, int dev) scmd %d: %s to dev %d -megasas_dcmd_internal_finish(int cmd, int opcode, int lun) scmd %d: DCMD finish internal cmd %x lun %d -megasas_dcmd_internal_invalid(int cmd, int opcode) scmd %d: Invalid internal DCMD %x +megasas_dcmd_internal_finish(int cmd, int opcode, int lun) scmd %d: cmd %x lun %d +megasas_dcmd_internal_invalid(int cmd, int opcode) scmd %d: cmd %x megasas_dcmd_unhandled(int cmd, int opcode, int len) scmd %d: opcode %x, len %d megasas_dcmd_zero_sge(int cmd) scmd %d: zero DCMD sge count -megasas_dcmd_invalid_sge(int cmd, int count) scmd %d: invalid DCMD sge count %d +megasas_dcmd_invalid_sge(int cmd, int count) scmd %d: DCMD sge count %d megasas_dcmd_invalid_xfer_len(int cmd, unsigned long size, unsigned long max) scmd %d: invalid xfer len %ld, max %ld megasas_dcmd_enter(int cmd, const char *dcmd, int len) scmd %d: DCMD %s len %d -megasas_dcmd_dummy(int cmd, unsigned long size) scmd %d: DCMD dummy xfer len %ld +megasas_dcmd_dummy(int cmd, unsigned long size) scmd %d: xfer len %ld megasas_dcmd_set_fw_time(int cmd, unsigned long time) scmd %d: Set FW time %lx -megasas_dcmd_pd_get_list(int cmd, int num, int max, int offset) scmd %d: DCMD PD get list: %d /
[Qemu-devel] [PATCH 7/7] MAINTAINERS: mark megasas as maintained
Signed-off-by: Hannes Reinecke h...@suse.de --- MAINTAINERS | 6 ++ 1 file changed, 6 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index c66946f..f1d3f09 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -651,6 +651,12 @@ S: Supported F: hw/block/nvme* F: tests/nvme-test.c +megasas +M: Hannes Reinecke h...@suse.de +S: Supported +F: hw/scsi/megasas.c +F: hw/scsi/mfi.h + Xilinx EDK M: Peter Crosthwaite peter.crosthwa...@xilinx.com M: Edgar E. Iglesias edgar.igles...@gmail.com -- 1.8.1.4
[Qemu-devel] [PATCH 6/7] megasas: Decode register names
To ease debugging we should be decoding
the register names.
Signed-off-by: Hannes Reinecke h...@suse.de
---
hw/scsi/megasas.c | 22 +++---
trace-events | 4 ++--
2 files changed, 21 insertions(+), 5 deletions(-)
diff --git a/hw/scsi/megasas.c b/hw/scsi/megasas.c
index a5bfeba..6d60427 100644
--- a/hw/scsi/megasas.c
+++ b/hw/scsi/megasas.c
@@ -1933,6 +1933,7 @@ static uint64_t megasas_mmio_read(void *opaque, hwaddr
addr,
switch (addr) {
case MFI_IDB:
retval = 0;
+trace_megasas_mmio_readl(MFI_IDB, retval);
break;
case MFI_OMSG0:
case MFI_OSP0:
@@ -1940,6 +1941,8 @@ static uint64_t megasas_mmio_read(void *opaque, hwaddr
addr,
(s-fw_state MFI_FWSTATE_MASK) |
((s-fw_sge 0xff) 16) |
(s-fw_cmds 0x);
+trace_megasas_mmio_readl(addr == MFI_OMSG0 ? MFI_OMSG0 : MFI_OSP0,
+ retval);
break;
case MFI_OSTS:
if (megasas_intr_enabled(s) s-doorbell) {
@@ -1949,21 +1952,24 @@ static uint64_t megasas_mmio_read(void *opaque, hwaddr
addr,
retval = MFI_1078_RM | 1;
}
}
+trace_megasas_mmio_readl(MFI_OSTS, retval);
break;
case MFI_OMSK:
retval = s-intr_mask;
+trace_megasas_mmio_readl(MFI_OMSK, retval);
break;
case MFI_ODCR0:
retval = s-doorbell;
+trace_megasas_mmio_readl(MFI_ODCR0, retval);
break;
case MFI_DIAG:
retval = s-diag;
+trace_megasas_mmio_readl(MFI_DIAG, retval);
break;
default:
trace_megasas_mmio_invalid_readl(addr);
break;
}
-trace_megasas_mmio_readl(addr, retval);
return retval;
}
@@ -1978,9 +1984,9 @@ static void megasas_mmio_write(void *opaque, hwaddr addr,
uint32_t frame_count;
int i;
-trace_megasas_mmio_writel(addr, val);
switch (addr) {
case MFI_IDB:
+trace_megasas_mmio_writel(MFI_IDB, val);
if (val MFI_FWINIT_ABORT) {
/* Abort all pending cmds */
for (i = 0; i s-fw_cmds; i++) {
@@ -1996,6 +2002,7 @@ static void megasas_mmio_write(void *opaque, hwaddr addr,
}
break;
case MFI_OMSK:
+trace_megasas_mmio_writel(MFI_OMSK, val);
s-intr_mask = val;
if (!megasas_intr_enabled(s)
!msi_enabled(pci_dev)
@@ -2016,6 +2023,7 @@ static void megasas_mmio_write(void *opaque, hwaddr addr,
}
break;
case MFI_ODCR0:
+trace_megasas_mmio_writel(MFI_ODCR0, val);
s-doorbell = 0;
if (s-producer_pa megasas_intr_enabled(s)) {
/* Update reply queue pointer */
@@ -2029,13 +2037,19 @@ static void megasas_mmio_write(void *opaque, hwaddr
addr,
}
break;
case MFI_IQPH:
+trace_megasas_mmio_writel(MFI_IQPH, val);
/* Received high 32 bits of a 64 bit MFI frame address */
s-frame_hi = val;
break;
case MFI_IQPL:
+trace_megasas_mmio_writel(MFI_IQPL, val);
/* Received low 32 bits of a 64 bit MFI frame address */
case MFI_IQP:
-/* Received 32 bit MFI frame address */
+if (addr == MFI_IQP) {
+trace_megasas_mmio_writel(MFI_IQP, val);
+/* Received 32 bit MFI frame address */
+s-frame_hi = 0;
+}
frame_addr = (val ~0x1F);
/* Add possible 64 bit offset */
frame_addr |= ((uint64_t)s-frame_hi 32);
@@ -2044,6 +2058,7 @@ static void megasas_mmio_write(void *opaque, hwaddr addr,
megasas_handle_frame(s, frame_addr, frame_count);
break;
case MFI_SEQ:
+trace_megasas_mmio_writel(MFI_SEQ, val);
/* Magic sequence to start ADP reset */
if (adp_reset_seq[s-adp_reset] == val) {
s-adp_reset++;
@@ -2056,6 +2071,7 @@ static void megasas_mmio_write(void *opaque, hwaddr addr,
}
break;
case MFI_DIAG:
+trace_megasas_mmio_writel(MFI_DIAG, val);
/* ADP reset */
if ((s-diag MFI_DIAG_WRITE_ENABLE)
(val MFI_DIAG_RESET_ADP)) {
diff --git a/trace-events b/trace-events
index c12fc02..f02cde5 100644
--- a/trace-events
+++ b/trace-events
@@ -679,9 +679,9 @@ megasas_intr_enabled(void) Interrupts enabled
megasas_intr_disabled(void) Interrupts disabled
megasas_msix_enabled(int vector) vector %d
megasas_msi_enabled(int vector) vector %d
-megasas_mmio_readl(unsigned long addr, uint32_t val) addr 0x%lx: 0x%x
+megasas_mmio_readl(const char *reg, uint32_t val) reg %s: 0x%x
megasas_mmio_invalid_readl(unsigned long addr) addr 0x%lx
-megasas_mmio_writel(uint32_t addr, uint32_t val) addr 0x%x: 0x%x
+megasas_mmio_writel(const char *reg, uint32_t val) reg %s: 0x%x
megasas_mmio_invalid_writel(uint32_t addr, uint32_t val) addr 0x%x: 0x%x
# hw/audio/milkymist-ac97.c
--
1.8.1.4
Re: [Qemu-devel] [PATCH V6 0/2] hw/pci: reserve IO and mem for pci-2-pci bridges with no devices attached
On Thu, Apr 10, 2014 at 09:55:20PM +0300, Marcel Apfelbaum wrote: If a pci-2-pci bridge supports hot-plug functionality but there are no devices connected to it, reserve IO/mem in order to be able to attach devices later. Do not waste space, use minimum allowed. Thanks - I have committed this series. -Kevin
Re: [Qemu-devel] [PATCH v4 4/6] qemu-img: Enable progress output for commit
Am 12.04.2014 um 20:57 hat Max Reitz geschrieben:
Implement progress output for the commit command by querying the
progress of the block job.
Signed-off-by: Max Reitz mre...@redhat.com
---
qemu-img-cmds.hx | 4 ++--
qemu-img.c | 44 ++--
qemu-img.texi| 2 +-
3 files changed, 45 insertions(+), 5 deletions(-)
diff --git a/qemu-img-cmds.hx b/qemu-img-cmds.hx
index d029609..8bc55cd 100644
--- a/qemu-img-cmds.hx
+++ b/qemu-img-cmds.hx
@@ -22,9 +22,9 @@ STEXI
ETEXI
DEF(commit, img_commit,
-commit [-q] [-f fmt] [-t cache] filename)
+commit [-q] [-f fmt] [-t cache] [-p] filename)
STEXI
-@item commit [-q] [-f @var{fmt}] [-t @var{cache}] @var{filename}
+@item commit [-q] [-f @var{fmt}] [-t @var{cache}] [-p] @var{filename}
ETEXI
DEF(compare, img_compare,
diff --git a/qemu-img.c b/qemu-img.c
index 9fe6384..50d7519 100644
--- a/qemu-img.c
+++ b/qemu-img.c
@@ -686,6 +686,9 @@ fail:
struct CommonBlockJobCBInfo {
Error **errp;
bool done;
+/* If the blockjob works on several sectors at once, this field has to
+ * contain that granularity in bytes */
+uint64_t granularity;
};
static void common_block_job_cb(void *opaque, int ret)
@@ -702,12 +705,34 @@ static void common_block_job_cb(void *opaque, int ret)
static void run_block_job(BlockJob *job, struct CommonBlockJobCBInfo *cbi)
{
BlockJobInfo *info;
+uint64_t mod_offset = 0;
do {
qemu_aio_wait();
info = block_job_query(job);
+if (info-offset) {
+if (!mod_offset) {
+/* Some block jobs (at least commit) will only work on a
+ * subset of the image file and therefore basically skip many
+ * sectors at the start (processing them apparently
+ * instantaneously). These sectors should be ignored when
+ * calculating the progress.
+ * If the blockjob processes several sectors at once, the
first
+ * progress report is likely to come after one such sector
group
+ * (whose size is cbi-granularity), therefore subtract it
from
+ * the current offset in order to obtain a more probable
+ * starting offset. */
+mod_offset = info-offset cbi-granularity
+ ? info-offset - cbi-granularity
+ : 0;
granularity != buf_size. And you still can't distinguish whether the
first chunk was skipped or copied.
In the v2 review I suggested changing mirror_run() to update
s-common.len. There you wouldn't have to make any assumptions, but
would know exactly where the bitmap initialisation is done. And it would
improve traditional block job progress output, too.
Am I missing anything that makes this approach harder than it seems?
Kevin
