[Qemu-devel] Unsubscription Confirmation
Thank you for subscribing. You have now unsubscribed and no more messages will be sent.
Re: [Qemu-devel] [libvirt] Modern CPU models cannot be used with libvirt
On Thu, Dec 15, 2011 at 03:42:44PM +, Daniel P. Berrange wrote: On Thu, Dec 15, 2011 at 03:54:15PM +0100, Jiri Denemark wrote: Hi, Recently I realized that all modern CPU models defined in /etc/qemu/target-x86_64.conf are useless when qemu is used through libvirt. That's because we start qemu with -nodefconfig which results in qemu ignoring that file with CPU model definitions. We have a very good reason for using -nodefconfig because we need to control the ABI presented to a guest OS and we don't want any configuration file that can contain lots of things including device definitions to be read by qemu. However, we would really like the new CPU models to be understood by qemu even if used through libvirt. What would be the best way to solve this? Ideally libvirt would just write out a config file with the CPU that was configured in libvirt and pass -readconfig /var/lib/libvirt/qemu/guestcpu.conf That way libvirt can configure CPU models without regard for what the particular QEMU version might have in its config. And how libvirt would know that particular QEMU/kvm version can create this CPU. Managing cpuid shouldn't be libvirt busyness. -- Gleb.
Re: [Qemu-devel] [PATCH v9 0/3] PC system flash support
On 12/15/2011 11:02 PM, Jordan Justen wrote: I verified that 'info mtree' and 'info qdev' are equivalent for pc-1.0 when using master and with my patches. However, I did discover that v1.0 seems to differ from master for this same test. That's are fine; pre-memory-API devices don't show up in info mtree. @@ -218,7 +221,7 @@ dev-prop: data_iobase = 0x511 irq 0 mmio /0002 -mmio /0002 +mmio /0001 This one isn't nice. Doesn't affect pc though. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] Modern CPU models cannot be used with libvirt
On 12/15/2011 05:30 PM, Jiri Denemark wrote: On Thu, Dec 15, 2011 at 08:58:55 -0600, Anthony Liguori wrote: Pass '-readconfig /etc/qemu/target-x86_64.conf' to pick up those models and if you are absolutely insistent on not giving the user any ability to change things on their own, cp the file from qemu.git into libvirt.git and install it in a safe place. Ah, this looks like a good idea (and we could even generate that file dynamically if we add support for family/stepping/... and other things that we do not model now). However, separating these definitions from qemu may result in incompatibilities with older qemu versions. I guess mainly because our configuration file would mention a CPU feature that an installed qemu version doesn't understand. Currently, qemu seems to just ignore such feature (although it prints an error) and continues happily without it. Is there any way for us to ask qemu what CPU features it knows about so that we could avoid using a CPU models which include features qemu doesn't understand? Libvirt should use the 'enforce' option and there is also a 'check' one too: qemu-kvm -cpu Conroe,+avx,enforce warning: host cpuid _0001 lacks requested flag 'avx' [0x1000] Unable to find x86 CPU definition Qemu supports backward compatibility of the command line and if libvirt stores additional cpuid related definitions it should still work on other qemu releases. btw: I do prompt the usage of the 'formal' cpu models as much as it can. If a user likes to toggle various options it should do it on top of our models. Regards, Dor Jirka
[Qemu-devel] Problem editing wiki page in wiki.qemu.org
Hi Anthony, I'm trying to edit a wiki page I create in qemu.org. I get the following error: You do not have permission to edit this page, for the following reason: Your IP address has been automatically blocked because it was used by another user, who was blocked by Mjt. The reason given is this: Autoblocked because your IP address has been recently used by Chruse Arroyo. The reason given for Chruse Arroyo's block is: Spamming links to external sites Start of block: 20:21, 17 December 2011 Expiry of block: 20:21, 18 December 2011 Intended blockee: 127.0.0.1 You may contact Mjt or one of the other administrators to discuss the block. Note that you may not use the e-mail this user feature unless you have a valid e-mail address registered in your user preferences and you have not been blocked from using it. Your current IP address is 127.0.0.1, and the block ID is #132. Please include all above details in any queries you make. Any idea how to solve it ? Regards, Orit Wasserman
Re: [Qemu-devel] Problem editing wiki page in wiki.qemu.org
On 18 December 2011 10:38, Orit Wasserman owass...@redhat.com wrote: Hi Anthony, I'm trying to edit a wiki page I create in qemu.org. I get the following error: Intended blockee: 127.0.0.1 Your current IP address is 127.0.0.1, and the block ID is #132. This looks very fishy ^ I get the same error, and I suspect everybody will. It looks like the wiki thinks we all access it from localhost now :-) -- PMM
Re: [Qemu-devel] Problem editing wiki page in wiki.qemu.org
Your current IP address is 127.0.0.1, and the block ID is #132. +1. :) Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] Problem editing wiki page in wiki.qemu.org
Am 18.12.2011 11:44, schrieb Peter Maydell: On 18 December 2011 10:38, Orit Wasserman owass...@redhat.com wrote: Hi Anthony, I'm trying to edit a wiki page I create in qemu.org. I get the following error: Intended blockee: 127.0.0.1 Your current IP address is 127.0.0.1, and the block ID is #132. This looks very fishy ^ I get the same error, and I suspect everybody will. It looks like the wiki thinks we all access it from localhost now :-) -- PMM It looks like the autoblock was created yesterday and terminates automaticallytoday (see http://wiki.qemu.org/index.php?title=Special:BlockListaction=searchip=%23132). That won't help much as long as the wiki thinks that everyone has the localhost address because the next autoblock will block all users again. Are block lists really useful to protect the QEMU wiki? Neither user names nor IP addresses are unique. Spammerscan create any number of new names. Regards, Stefan Weil
Re: [Qemu-devel] Problem editing wiki page in wiki.qemu.org
On 18.12.2011 15:20, Stefan Weil wrote: [] It looks like the autoblock was created yesterday and terminates automaticallytoday (see http://wiki.qemu.org/index.php?title=Special:BlockListaction=searchip=%23132). That won't help much as long as the wiki thinks that everyone has the localhost address because the next autoblock will block all users again. Are block lists really useful to protect the QEMU wiki? Neither user names nor IP addresses are unique. Spammerscan create any number of new names. It is not the blocklist which is useful. By blocking _users_ I just mention that this is a spammer/bot, so we have a chance to clean up the dead users. And since autoblock by IP is enabled by default it triggers too. I will uncheck the checkbox the next time I'll block a user account. It'd be nice to uncheck it by default, too. Thanks, /mjt
Re: [Qemu-devel] [PATCH v2 0/4] GTK-DOC build integration (v2)
Am 15.12.2011 11:21, schrieb Kevin Wolf: Am 15.12.2011 10:32, schrieb Stefan Weil: Am 15.12.2011 06:22, schrieb Andreas Färber: Their website has the following: GTK-Doc wasn't originally intended to be a general-purpose documentation tool, so it can be a bit awkward to setup and use. For a more polished general-purpose documentation tool you may want to look at Doxygen. However GTK-Doc has some special code to document the signals and properties of GTK+ widgets and GObject classes which other tools may not have. http://www.gtk.org/gtk-doc/ Don't know if Doxygen has less restrictions though. Andreas With doxygen, the documentation looks like this: http://qemu.weilnetz.de/doxygen/ I only modified the first lines of memory.h to get the global C functions, but of course more changes are needed if we choose doxygen as our standard. You seem to have included Anthony's patches (specifically the one to split out nested structs). Is Doxygen really as broken as gtk-doc seems to be or can we do without it? Kevin Yes, the previous results were based on QEMU with Anthony's latest gtkdoc patches. Here is the result from unpatched QEMU code: http://qemu.weilnetz.de/doxygen2/ or http://qemu.weilnetz.de/doxygen2/memory_8h.html I had to remove most graphics because they needed more than 1 GB disk space and filled all available space on my server. Regards, Stefan
Re: [Qemu-devel] [PATCH 0/2] [RFC] qemu-ga: add support for guest command execution
On Tue, Dec 06, 2011 at 10:43:42AM -0600, Michael Roth wrote:
On 12/06/2011 08:44 AM, Daniel P. Berrange wrote:
On Tue, Dec 06, 2011 at 08:34:06AM -0600, Michael Roth wrote:
The code is still in rough shape, but while we're on the topic of guest
agents
I wanted to put out a working example of how exec functionality can be added
to qemu-ga to provide a mechansim for building arbitrarilly high-level
interfaces.
The hope is that by allowing qemu-ga to execute commands in the guest,
paired
with file read/write access, we can instrument a guest on the fly to
support
any type of hyperviser functionality, and do so without dramatically
enlarging
the role qemu-ga plays as a small, QEMU-specific agent that is tightly
integrated with QEMU/QMP/libvirt.
These patches add the following interfaces:
guest-file-open-pipe
guest-exec
guest-exec-status
The guest-file-open-pipe interface is analagous to the existing
guest-file-open
interface (it might be best to roll it into it actually): it returns a
handle
that can be handled via the existing guest-file-{read,write,flush,close}
interface. Internally it creates a FIFO pair that we can use to associate
handles to the stdin/stdout/stderr of a guest-exec spawned process. We can
also
also use them to redirect output into other processes, giving us the basic
tools to build a basic shell (or a full-blown one if we add TTY support)
using
a single qemu-ga.
Theoretically we can even deploy other agents, including session-level
agents,
and communicate with them via these same handles. Thus, ovirt could deploy
and
run an agent via qemu-ga, Spice could deploy vdagent, etc. Since the
interface
is somewhat tedious, I'm working on a wrapper script to try out some of
these scenarios, but a basic use case using the raw QMP interface is
included
below.
Any thoughts/comments on this approach are appreciated.
Is there a seperate transport (another virtio channel) for the launched
guest process? I'm thinking as usual on the copy/paste functionallity,
when passing a large buffer, I would not want to block any other future
qemu-ga command. Also I would like to avoid having to uuencode/decode
the traffic.
EXAMPLE USAGE (execute `top -b -n1`):
{'execute': 'guest-file-open-pipe'}
{'return': 6}
{'execute': 'guest-exec',\
'arguments': {'detach': True, \
'handle_stdout': 6, \
'params': [{'param': '-b'}, \
{'param': '-n1'}], \
'path': 'top'}}
This feels like a rather verbose way of specifying
the ARGV. Why not just allow
{'execute': 'guest-exec',\
'arguments': {'detach': True, \
'handle_stdout': 6, \
'params': ['-b', '-n1'], \
'path': 'top'}}
Or even
{'execute': 'guest-exec',\
'arguments': {'detach': True, \
'handle_stdout': 6, \
'argv': ['top', '-b', '-n1']}} \
Agreed, this would look way nicer and is what I was shooting for
initially. Unfortunately, the QAPI-generated QMP marshalling code,
and the visitor interfaces it uses, expects lists to be of
structured types. We might be able to special-case it for int and
char* arrays though and open-code it though...
The problem I ran into when I looked at it though is that the QMP
request is a QObject at that point that's contained inside a
Visitor. So to manipulate it we'd have to extract the QList and
manipulate it outside the visitor, which would be difficult since
the Visitor is using a stack to manage it's traversal of the QObject
based on the visitor calls we make, so it's difficult to pull it out
of there...
Although, maybe we could just add a qmp_input_vistor_stack_top()
that gives us the top of the stack, then call it at the appropriate
point in the marshalling code and key into it to get qobj{'argv'}
and whatnot. It's kinda hacky, but it's QMP-specific, and useful, so
it might be worth it.
Alternatively, we could introduce another Visitor interface for
handling lists of int64_t and char*.
So maybe it's not so bad, I'll look into it more.
and just use the first element of argv as the binary to
execute. Also you might need to set env variables for
some tools, so we'd want
{'execute': 'guest-exec',\
'arguments': {'detach': True, \
'handle_stdout': 6, \
'argv': ['top', '-b', '-n1'], \
'env' : ['TMPDIR=/wibble']}}
and perhaps also you might want to run as a non-root
user, so allow a username/groupname ?
Good idea, this would open up a lot of potential use cases (X
session/display management, copy/paste, etc).
Regards,
Daniel
Re: [Qemu-devel] [PATCH] target-arm: Fixed ARMv7-M SHPR access
On 17/12/11 01:50, Peter Maydell wrote: On 16 December 2011 18:50, Sebastian Huber sebastian.hu...@embedded-brains.de wrote: According to ARMv7-M Architecture Reference Manual issue D section B3.2.10 System Handler Prioriy Register 1, SHPR1, B3.2.11 System Handler Prioriy Register 2, SHPR2, and B3.2.12 System Handler Prioriy Register 3, SHPR3. This would fix the specific issue of not being able to do byte or halfword accesses to the SHPR registers, but it doesn't do anything about other byte-accessible registers like the CFSR. The right fix for this is for armv7m_nvic to expose a memory region for the system control space which implements byte and halfword accesses, and not to try to indirect everything through a single GIC region. I am primary a Qemu user and fixed the bugs only as far as it was necessary to run my test suites. I used the surrounding code as a reference. Maybe I find some time in the next months to clean this up. -- Sebastian Huber, embedded brains GmbH Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany Phone : +49 89 18 90 80 79-6 Fax : +49 89 18 90 80 79-9 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: [Qemu-devel] [PATCH] iSCSI: add configuration variables for iSCSI
On 12/18/2011 05:48 AM, Ronnie Sahlberg wrote: This patch adds configuration variables for iSCSI to set initiator-name to use when logging in to the target, which type of header-digest to negotiate with the target and username and password for CHAP authentication. This allows specifying a initiator-name either from the command line -iscsi initiator-name=iqn.2004-01.com.example:test or from a configuration file included with -readconfig [iscsi] initiator-name = iqn.2004-01.com.example:test header-digest = CRC32C|CRC32C-NONE|NONE-CRC32C|NONE user = CHAP username password = CHAP password header digest and user look like they should be options to the block driver. For the password you can reuse the system used by qcow2 perhaps? Paolo
Re: [Qemu-devel] [PATCH] target-arm: Fixed ARMv7-M SHPR access
On 18 December 2011 13:30, Sebastian Huber sebastian.hu...@embedded-brains.de wrote: I am primary a Qemu user and fixed the bugs only as far as it was necessary to run my test suites. I used the surrounding code as a reference. Maybe I find some time in the next months to clean this up. Right. Thanks for tracking down what the various problems were, by the way; that's useful. -- PMM
[Qemu-devel] [Bug 696094] Re: TI Stellaris lm3s811evb (ARM Cortex-M3) : Systick interrupt not working
http://www.mail-archive.com/qemu-devel@nongnu.org/msg90256.html has some patches from Sebastian Huber which let him run the RTEMS real time system on the TI Stellaris LM3S6965 with a working system tick. As he notes, some of them are hacks and not suitable for applying to qemu, but they give a reasonable list of problems needing fixing: (1) SHPR* (and some other) system registers need to be byte and halfword accessible (2) GIC priority mask feature not correct for v7M? [actually this looks to be wrong for A profile too, at least as far as the reset value goes: 11MPCore had a reset value of 0xf0 but A9 has reset value of 0.] (3) BASEPRI and BASEPRI_MAX are totally ignored at the moment (4) not very much RAM and it's not configurable from command line (2) and (3) add up to we don't implement the M profile execution priority and exception model properly; I strongly suspect there are further bugs in this area. (I'm not convinced that sharing code between the A profile GIC and the M profile NVIC is worthwhile, incidentally.) -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/696094 Title: TI Stellaris lm3s811evb (ARM Cortex-M3) : Systick interrupt not working Status in QEMU: New Bug description: I've tried to create a small project that uses the CMSIS as base library. The problem is that the SysTick_interrupt_handler() doesn't get executed when the systick event is detected in QEMU. Furthermore, it seems asif QEMU gets stuck in an endless loop. QEMU doesn't respond to Ctrl-C on the command line and the GDB session also stalls. 'kill -9' is the only way to stop QEMU. It seems asif the initialisation of the NVIC works fine. I've traced the function calls in QEMU as follows: stellaris.c: stellaris_init() - Perform generic armv7 init: armv7m_init() armv7m.c: armv7m_init() - Create and init the nvic: nvic = qdev_create(NULL, armv7m_nvic); env-nvic = nvic; qdev_init_nofail(nvic); - Configure the programmable interrupt controller: Call: arm_pic_init_cpu() qemu_allocate_irqs(arm_pic_cpu_handler) - Initialise 64 interrupt structures. The following call sequence is observed when the systick event occur: armv7m_nvic.c: systick_timer_tick(): set pending interrupt armv7m_nvic.c: armv7m_nvic_set_pending() for irq:15 arm_gic.c: gic_set_pending_private(): GIC_SET_PENDING(15,) arm_gic.c: gic_update() - Raise IRQ with qemu_set_irq() irq.c: eqmu_set_irq() - Call the irq-handler -- I assume the irq handler is 'arm_pic_cpu_handler()', since that was passed as the parameter when qemu_allocate_irqs() was called in ... arm_pic.c: arm_pic_cpu_handler() - After evaluation, call cpu_interrupt() exec.c: cpu_interrupt() is called. The tools that were used during the testing of this project: GCC: Codesourcery ARM eabi 2010q3 QEMU: Checked out on 31/12/2010 - Last commit: 0fcec41eec0432c77645b4a407d3a3e030c4abc4 The project files are attached, for reproducing of the errors. Note: The CMSIS wants to perform byte accesses to the NVIC. For the Cortex-M3, unaligned 8 bit and 16 bit accesses are allowed. The current QEMU implementation doesn't yet cater for it. As a work around, updated versions of arm_gic.c armv7m_nvic.h armv7m_nvic.c is also included. Launch project with: go_gdb.sh Attach debugger with: arm-none-eabi-gdbtui --command=gdbCommands_tui (s = step, n = next, c = continue, Ctrl-C = stop, print variable to look at variable contents) To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/696094/+subscriptions
[Qemu-devel] [PATCH 0/2] xen: convert to memory API
I missed Xen while converting stuff to the memory API, as it's not in hw/. Here comes the first simple patches; expect more as ram_addr_t is retired. Please review test (build tested only here). Also in git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git memory/xen (includes a patchset not yet merged upstream) Avi Kivity (2): memory, xen: pass MemoryRegion to xen_ram_alloc() xen: convert to memory API exec-obsolete.h |7 +-- exec.c | 10 ++ hw/xen.h|4 +++- memory.c|6 +++--- xen-all.c | 43 +++ xen-stub.c |3 ++- 6 files changed, 42 insertions(+), 31 deletions(-) -- 1.7.7.1
[Qemu-devel] [PATCH 1/2] memory, xen: pass MemoryRegion to xen_ram_alloc()
Currently xen_ram_alloc() relies on ram_addr, which is going away.
Give it something else to use as a cookie.
Signed-off-by: Avi Kivity a...@redhat.com
---
exec-obsolete.h |7 +--
exec.c | 10 ++
hw/xen.h|4 +++-
memory.c|6 +++---
xen-all.c |2 +-
xen-stub.c |3 ++-
6 files changed, 20 insertions(+), 12 deletions(-)
diff --git a/exec-obsolete.h b/exec-obsolete.h
index bf0dea5..1d0b610 100644
--- a/exec-obsolete.h
+++ b/exec-obsolete.h
@@ -25,9 +25,12 @@
#ifndef CONFIG_USER_ONLY
+#include memory.h
+
ram_addr_t qemu_ram_alloc_from_ptr(DeviceState *dev, const char *name,
-ram_addr_t size, void *host);
-ram_addr_t qemu_ram_alloc(DeviceState *dev, const char *name, ram_addr_t size);
+ram_addr_t size, void *host, MemoryRegion *mr);
+ram_addr_t qemu_ram_alloc(DeviceState *dev, const char *name, ram_addr_t size,
+ MemoryRegion *mr);
void qemu_ram_free(ram_addr_t addr);
void qemu_ram_free_from_ptr(ram_addr_t addr);
diff --git a/exec.c b/exec.c
index 8fbf7e4..05336a5 100644
--- a/exec.c
+++ b/exec.c
@@ -2918,7 +2918,8 @@ static ram_addr_t last_ram_offset(void)
}
ram_addr_t qemu_ram_alloc_from_ptr(DeviceState *dev, const char *name,
- ram_addr_t size, void *host)
+ ram_addr_t size, void *host,
+ MemoryRegion *mr)
{
RAMBlock *new_block, *block;
@@ -2974,7 +2975,7 @@ ram_addr_t qemu_ram_alloc_from_ptr(DeviceState *dev,
const char *name,
}
#else
if (xen_enabled()) {
-xen_ram_alloc(new_block-offset, size);
+xen_ram_alloc(new_block-offset, size, mr);
} else {
new_block-host = qemu_vmalloc(size);
}
@@ -2997,9 +2998,10 @@ ram_addr_t qemu_ram_alloc_from_ptr(DeviceState *dev,
const char *name,
return new_block-offset;
}
-ram_addr_t qemu_ram_alloc(DeviceState *dev, const char *name, ram_addr_t size)
+ram_addr_t qemu_ram_alloc(DeviceState *dev, const char *name, ram_addr_t size,
+ MemoryRegion *mr)
{
-return qemu_ram_alloc_from_ptr(dev, name, size, NULL);
+return qemu_ram_alloc_from_ptr(dev, name, size, NULL, mr);
}
void qemu_ram_free_from_ptr(ram_addr_t addr)
diff --git a/hw/xen.h b/hw/xen.h
index 2162111..f9f66e8 100644
--- a/hw/xen.h
+++ b/hw/xen.h
@@ -44,7 +44,9 @@ void xen_vcpu_init(void);
void xenstore_store_pv_console_info(int i, struct CharDriverState *chr);
#if defined(NEED_CPU_H) !defined(CONFIG_USER_ONLY)
-void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size);
+struct MemoryRegion;
+void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size,
+ struct MemoryRegion *mr);
#endif
#if defined(CONFIG_XEN) CONFIG_XEN_CTRL_INTERFACE_VERSION 400
diff --git a/memory.c b/memory.c
index d2ba9c4..cbd6988 100644
--- a/memory.c
+++ b/memory.c
@@ -985,7 +985,7 @@ void memory_region_init_ram(MemoryRegion *mr,
memory_region_init(mr, name, size);
mr-terminates = true;
mr-destructor = memory_region_destructor_ram;
-mr-ram_addr = qemu_ram_alloc(dev, name, size);
+mr-ram_addr = qemu_ram_alloc(dev, name, size, mr);
mr-backend_registered = true;
}
@@ -998,7 +998,7 @@ void memory_region_init_ram_ptr(MemoryRegion *mr,
memory_region_init(mr, name, size);
mr-terminates = true;
mr-destructor = memory_region_destructor_ram_from_ptr;
-mr-ram_addr = qemu_ram_alloc_from_ptr(dev, name, size, ptr);
+mr-ram_addr = qemu_ram_alloc_from_ptr(dev, name, size, ptr, mr);
mr-backend_registered = true;
}
@@ -1025,7 +1025,7 @@ void memory_region_init_rom_device(MemoryRegion *mr,
mr-opaque = opaque;
mr-terminates = true;
mr-destructor = memory_region_destructor_rom_device;
-mr-ram_addr = qemu_ram_alloc(dev, name, size);
+mr-ram_addr = qemu_ram_alloc(dev, name, size, mr);
mr-ram_addr |= cpu_register_io_memory(memory_region_read_thunk,
memory_region_write_thunk,
mr,
diff --git a/xen-all.c b/xen-all.c
index b5e28ab..b441fc1 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -181,7 +181,7 @@ static void xen_ram_init(ram_addr_t ram_size)
}
}
-void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size)
+void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size, MemoryRegion *mr)
{
unsigned long nr_pfn;
xen_pfn_t *pfn_list;
diff --git a/xen-stub.c b/xen-stub.c
index efe2ab5..5fa400f 100644
--- a/xen-stub.c
+++ b/xen-stub.c
@@ -8,6 +8,7 @@
#include qemu-common.h
#include hw/xen.h
+#include memory.h
void xenstore_store_pv_console_info(int i, CharDriverState *chr)
{
@@ -30,7 +31,7 @@ void xen_cmos_set_s3_resume(void *opaque, int irq, int level)
{
}
-void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size)
+void xen_ram_alloc(ram_addr_t
[Qemu-devel] [PATCH 2/2] xen: convert to memory API
Undo the private implementation of qemu_ram_alloc(); use the global one
(which calls right back into xen_ram_alloc()).
Signed-off-by: Avi Kivity a...@redhat.com
---
xen-all.c | 41 ++---
1 files changed, 22 insertions(+), 19 deletions(-)
diff --git a/xen-all.c b/xen-all.c
index b441fc1..bd89889 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -16,6 +16,7 @@
#include range.h
#include xen-mapcache.h
#include trace.h
+#include exec-memory.h
#include xen/hvm/ioreq.h
#include xen/hvm/params.h
@@ -31,6 +32,8 @@
do { } while (0)
#endif
+static MemoryRegion ram_memory, ram_640k, ram_lo, ram_hi;
+
/* Compatibility with older version */
#if __XEN_LATEST_INTERFACE_VERSION__ 0x0003020a
static inline uint32_t xen_vcpu_eport(shared_iopage_t *shared_page, int i)
@@ -137,27 +140,18 @@ static void xen_set_irq(void *opaque, int irq, int level)
static void xen_ram_init(ram_addr_t ram_size)
{
-RAMBlock *new_block;
+MemoryRegion *sysmem = get_system_memory();
ram_addr_t below_4g_mem_size, above_4g_mem_size = 0;
+ram_addr_t block_len;
-new_block = g_malloc0(sizeof (*new_block));
-pstrcpy(new_block-idstr, sizeof (new_block-idstr), xen.ram);
-new_block-host = NULL;
-new_block-offset = 0;
-new_block-length = ram_size;
+block_len = ram_size;
if (ram_size = HVM_BELOW_4G_RAM_END) {
/* Xen does not allocate the memory continuously, and keep a hole at
* HVM_BELOW_4G_MMIO_START of HVM_BELOW_4G_MMIO_LENGTH
*/
-new_block-length += HVM_BELOW_4G_MMIO_LENGTH;
+block_len += HVM_BELOW_4G_MMIO_LENGTH;
}
-
-QLIST_INSERT_HEAD(ram_list.blocks, new_block, next);
-
-ram_list.phys_dirty = g_realloc(ram_list.phys_dirty,
- new_block-length TARGET_PAGE_BITS);
-memset(ram_list.phys_dirty + (new_block-offset TARGET_PAGE_BITS),
- 0xff, new_block-length TARGET_PAGE_BITS);
+memory_region_init_ram(ram_memory, NULL, xen.ram, block_len);
if (ram_size = HVM_BELOW_4G_RAM_END) {
above_4g_mem_size = ram_size - HVM_BELOW_4G_RAM_END;
@@ -166,18 +160,23 @@ static void xen_ram_init(ram_addr_t ram_size)
below_4g_mem_size = ram_size;
}
-cpu_register_physical_memory(0, 0xa, 0);
+memory_region_init_alias(ram_640k, xen.ram.640k,
+ ram_memory, 0, 0xa);
+memory_region_add_subregion(sysmem, 0, ram_640k);
/* Skip of the VGA IO memory space, it will be registered later by the VGA
* emulated device.
*
* The area between 0xc and 0x10 will be used by SeaBIOS to load
* the Options ROM, so it is registered here as RAM.
*/
-cpu_register_physical_memory(0xc, below_4g_mem_size - 0xc,
- 0xc);
+memory_region_init_alias(ram_lo, xen.ram.lo,
+ ram_memory, 0xc, below_4g_mem_size -
0xc);
+memory_region_add_subregion(sysmem, 0xc, ram_lo);
if (above_4g_mem_size 0) {
-cpu_register_physical_memory(0x1ULL, above_4g_mem_size,
- 0x1ULL);
+memory_region_init_alias(ram_hi, xen.ram.hi,
+ ram_memory, 0x1ULL,
+ above_4g_mem_size);
+memory_region_add_subregion(sysmem, 0x1ULL, ram_hi);
}
}
@@ -187,6 +186,10 @@ void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size,
MemoryRegion *mr)
xen_pfn_t *pfn_list;
int i;
+if (mr == ram_memory) {
+return;
+}
+
trace_xen_ram_alloc(ram_addr, size);
nr_pfn = size TARGET_PAGE_BITS;
--
1.7.7.1
[Qemu-devel] [Bug 899961] Re: qemu/kvm locks up when run 32bit userspace with 64bit kernel
** Changed in: qemu-kvm (Debian) Status: Unknown = Confirmed -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/899961 Title: qemu/kvm locks up when run 32bit userspace with 64bit kernel Status in QEMU: New Status in “qemu-kvm” package in Debian: Confirmed Bug description: Only applies to qemu-kvm 1.0, and only when kernel is 64bit and userspace is 32bit, on x86. Did not happen with previous released versions, such as 0.15. Not all guests triggers this issue - so far, only (32bit) windows 7 guest shows it, but does that quite reliable: first boot of an old guest with new qemu-kvm, windows finds a new CPU and suggests rebooting - hit Reboot and in a few seconds it will be locked up (including the monitor), with no CPU usage whatsoever. Killable only with -9. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/899961/+subscriptions
Re: [Qemu-devel] [PATCH 0/2] xen: convert to memory API
On 18 December 2011 15:32, Avi Kivity a...@redhat.com wrote: I missed Xen while converting stuff to the memory API, as it's not in hw/. Here comes the first simple patches; expect more as ram_addr_t is retired. Er, ram_addr_t is going away? Can you elaborate? -- PMM
Re: [Qemu-devel] [PATCH 0/2] xen: convert to memory API
On 12/18/2011 05:43 PM, Peter Maydell wrote: On 18 December 2011 15:32, Avi Kivity a...@redhat.com wrote: I missed Xen while converting stuff to the memory API, as it's not in hw/. Here comes the first simple patches; expect more as ram_addr_t is retired. Er, ram_addr_t is going away? Can you elaborate? Nothing dramatic. Uses of ram_addr_t to denote RAM will be replaced by a (MemoryRegion *, offset) pair. The type of the offset will be called ram_addr_t. -- error compiling committee.c: too many arguments to function
[Qemu-devel] [PATCH v3 0/8] qom: introduce non-legacy static properties
QOM right now does not have a way to communicate values for qdev
properties except as strings. This is bad.
This patch improves the Property implementation so that properties
export a visitor-based interface in addition to the string-based
interface. The new interface can then be registered as a static
property. It's called static because it uses a struct field for
storage and, as such, should be present in all objects of a given
class.
Patches 1-2 are bugfixes and patches 3-4 are cleanups.
Example using qmp-shell:
x86_64-softmmu/qemu-system-x86_64 \
-hda ~/test.img -snapshot -S \
-qmp unix:/tmp/server.sock,server,nowait \
-netdev type=user,id=net -device virtio-net-pci,netdev=net,id=net \
-net user,vlan=1 -device virtio-net-pci,id=net2,vlan=1 \
-chardev id=stdio,backend=stdio -device isa-serial,chardev=stdio,id=serial
Boolean properties:
(QEMU) qom-get path=/i440fx/piix3 property=command_serr_enable
{u'return': True}
(QEMU) qom-get path=/i440fx/piix3 property=legacycommand_serr_enable
{u'return': u'on'}
PCI address properties (perhaps will disappear later, but not yet):
(QEMU) qom-get path=/i440fx/piix3 property=addr
{u'return': u'01.0'}
(QEMU) qom-get path=/i440fx/piix3 property=legacy-addr
{u'return': u'01.0'}
String properties (NULL mapped to empty string):
(QEMU) qom-get path=/vga property=romfile
{u'return': u'vgabios-cirrus.bin'}
(QEMU) qom-get path=/vga property=legacy-romfile
{u'return': u'vgabios-cirrus.bin'}
(QEMU) qom-get path=/i440fx/piix3 property=romfile
{u'return': u''}
(QEMU) qom-get path=/i440fx/piix3 property=legacy-romfile
{u'return': u'null'}
MAC properties:
(QEMU) qom-get path=/peripheral/net property=mac
{u'return': u'52:54:00:12:34:56'}
(QEMU) qom-get path=/peripheral/net property=legacy-mac
{u'return': u'52:54:00:12:34:56'}
(QEMU) qom-set path=/peripheral/net property=mac value=52-54-00-12-34-57
{u'error': {u'data': {}, u'class': u'PermissionDenied', u'desc': u'Insufficient
permission to perform this operation'}}
Network properties:
(QEMU) qom-get path=/peripheral/net property=netdev
{u'return': u'net'}
(QEMU) qom-get path=/peripheral/net property=legacy-netdev
{u'return': u'net'}
VLAN properties:
(QEMU) qom-get path=/peripheral/net property=vlan
{u'return': -1}
(QEMU) qom-get path=/peripheral/net property=legacy-vlan
{u'return': u'null'}
(QEMU) qom-get path=/peripheral/net2 property=vlan
{u'return': 1}
(QEMU) qom-get path=/peripheral/net2 property=legacy-vlan
{u'return': u'1'}
Chardev properties:
(QEMU) qom-get path=/peripheral/serial property=chardev
{u'return': u'stdio'}
(QEMU) qom-get path=/peripheral/serial property=legacy-chardev
{u'return': u'stdio'}
Legacy hex32 properties:
(QEMU) qom-get path=/peripheral/serial property=iobase
{u'return': 1016}
(QEMU) qom-get path=/peripheral/serial property=legacy-iobase
{u'return': u'0x3f8'}
Examples of setting properties (after disabling the DEV_STATE_CREATED
check for testing only):
(QEMU) qom-set path=/peripheral/net2 property=vlan value=-1
{u'return': {}}
(QEMU) qom-get path=/peripheral/net2 property=vlan
{u'return': -1}
(QEMU) qom-get path=/peripheral/net2 property=legacy-vlan
{u'return': u'null'}
(QEMU) qom-set path=/peripheral/serial property=iobase value=760
{u'return': {}}
(QEMU) qom-get path=/peripheral/serial property=iobase
{u'return': 760}
(QEMU) qom-get path=/peripheral/serial property=legacy-iobase
{u'return': u'0x2f8'}
v2-v3:
Tweaks to patch 4.
v1-v2:
New qom: interpret the return value when setting legacy
properties. Always pass a value to the visitor when there
is no error. Handle empty strings as NULL. Did not change
QERR_PROPERTY_VALUE_OUT_OF_RANGE because it is consistent
with other QERR_PROPERTY_* errors, now used by QOM too.
Paolo Bonzini (8):
qapi: protect against NULL QObject in qmp_input_get_object
qom: fix swapped parameters
qom: push permission checks up into qdev_property_add_legacy
qom: interpret the return value when setting legacy properties
qom: introduce QERR_PROPERTY_VALUE_OUT_OF_RANGE
qom: introduce get/set methods for Property
qom: distinguish legacy property type name from QOM type name
qom: register qdev properties also as non-legacy properties
hw/qdev-addr.c | 41 +
hw/qdev-properties.c | 407 +++--
hw/qdev.c| 84 ++
hw/qdev.h| 14 +-
qapi/qmp-input-visitor.c | 10 +-
qerror.c |5 +
qerror.h |3 +
7 files changed, 502 insertions(+), 62 deletions(-)
--
1.7.7.1
[Qemu-devel] [PATCH 1/8] qapi: protect against NULL QObject in qmp_input_get_object
A NULL qobj can occur when a parameter is fetched via qdict_get, but
the parameter is not in the command. By returning NULL, the caller can
choose whether to raise a missing parameter error, an invalid parameter
type error, or use a default value. For example, qom-set could can
use this to reset a property to its default value, though at this time
it will fail with Invalid parameter type. In any case, anything is
better than crashing!
Reviewed-by: Anthony Liguori anth...@codemonkey.ws
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
qapi/qmp-input-visitor.c | 10 ++
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/qapi/qmp-input-visitor.c b/qapi/qmp-input-visitor.c
index 8cbc0ab..c78022b 100644
--- a/qapi/qmp-input-visitor.c
+++ b/qapi/qmp-input-visitor.c
@@ -49,10 +49,12 @@ static const QObject *qmp_input_get_object(QmpInputVisitor
*qiv,
qobj = qiv-stack[qiv-nb_stack - 1].obj;
}
-if (name qobject_type(qobj) == QTYPE_QDICT) {
-return qdict_get(qobject_to_qdict(qobj), name);
-} else if (qiv-nb_stack 0 qobject_type(qobj) == QTYPE_QLIST) {
-return qlist_entry_obj(qiv-stack[qiv-nb_stack - 1].entry);
+if (qobj) {
+if (name qobject_type(qobj) == QTYPE_QDICT) {
+return qdict_get(qobject_to_qdict(qobj), name);
+} else if (qiv-nb_stack 0 qobject_type(qobj) == QTYPE_QLIST) {
+return qlist_entry_obj(qiv-stack[qiv-nb_stack - 1].entry);
+}
}
return qobj;
--
1.7.7.1
[Qemu-devel] [PATCH 3/8] qom: push permission checks up into qdev_property_add_legacy
qdev_property_get and qdev_property_set can generate permission
denied errors themselves. Do not duplicate this functionality in
qdev_get/set_legacy_property, and clean up excessive indentation.
Reviewed-by: Anthony Liguori anth...@codemonkey.ws
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
hw/qdev.c | 46 +++---
1 files changed, 19 insertions(+), 27 deletions(-)
diff --git a/hw/qdev.c b/hw/qdev.c
index bda8d6c..c020a6f 100644
--- a/hw/qdev.c
+++ b/hw/qdev.c
@@ -1135,46 +1135,38 @@ static void qdev_get_legacy_property(DeviceState *dev,
Visitor *v, void *opaque,
{
Property *prop = opaque;
-if (prop-info-print) {
-char buffer[1024];
-char *ptr = buffer;
+char buffer[1024];
+char *ptr = buffer;
-prop-info-print(dev, prop, buffer, sizeof(buffer));
-visit_type_str(v, ptr, name, errp);
-} else {
-error_set(errp, QERR_PERMISSION_DENIED);
-}
+prop-info-print(dev, prop, buffer, sizeof(buffer));
+visit_type_str(v, ptr, name, errp);
}
static void qdev_set_legacy_property(DeviceState *dev, Visitor *v, void
*opaque,
const char *name, Error **errp)
{
Property *prop = opaque;
+Error *local_err = NULL;
+char *ptr = NULL;
+int ret;
if (dev-state != DEV_STATE_CREATED) {
error_set(errp, QERR_PERMISSION_DENIED);
return;
}
-if (prop-info-parse) {
-Error *local_err = NULL;
-char *ptr = NULL;
+visit_type_str(v, ptr, name, local_err);
+if (local_err) {
+error_propagate(errp, local_err);
+return;
+}
-visit_type_str(v, ptr, name, local_err);
-if (!local_err) {
-int ret;
-ret = prop-info-parse(dev, prop, ptr);
-if (ret != 0) {
-error_set(errp, QERR_INVALID_PARAMETER_VALUE,
- name, prop-info-name);
-}
-g_free(ptr);
-} else {
-error_propagate(errp, local_err);
-}
-} else {
-error_set(errp, QERR_PERMISSION_DENIED);
+ret = prop-info-parse(dev, prop, ptr);
+if (ret != 0) {
+error_set(errp, QERR_INVALID_PARAMETER_VALUE,
+ name, prop-info-name);
}
+g_free(ptr);
}
/**
@@ -1194,8 +1186,8 @@ void qdev_property_add_legacy(DeviceState *dev, Property
*prop,
type = g_strdup_printf(legacy%s, prop-info-name);
qdev_property_add(dev, prop-name, type,
- qdev_get_legacy_property,
- qdev_set_legacy_property,
+ prop-info-print ? qdev_get_legacy_property : NULL,
+ prop-info-parse ? qdev_set_legacy_property : NULL,
NULL,
prop, errp);
--
1.7.7.1
[Qemu-devel] [PATCH 8/8] qom: register qdev properties also as non-legacy properties
Push legacy properties into a legacy-... namespace, and make them
available with correct types too.
For now, all properties come in both variants. This need not be the
case for string properties. We will revisit this after -device is
changed to actually use the legacy properties.
Reviewed-by: Anthony Liguori aligu...@us.ibm.com
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
hw/qdev.c | 28 +---
hw/qdev.h |7 +++
2 files changed, 28 insertions(+), 7 deletions(-)
diff --git a/hw/qdev.c b/hw/qdev.c
index c6fcf4c..0465632 100644
--- a/hw/qdev.c
+++ b/hw/qdev.c
@@ -80,6 +80,9 @@ static DeviceInfo *qdev_find_info(BusInfo *bus_info, const
char *name)
return NULL;
}
+static void qdev_property_add_legacy(DeviceState *dev, Property *prop,
+ Error **errp);
+
static DeviceState *qdev_create_from_info(BusState *bus, DeviceInfo *info)
{
DeviceState *dev;
@@ -104,10 +107,12 @@ static DeviceState *qdev_create_from_info(BusState *bus,
DeviceInfo *info)
for (prop = dev-info-props; prop prop-name; prop++) {
qdev_property_add_legacy(dev, prop, NULL);
+qdev_property_add_static(dev, prop, NULL);
}
for (prop = dev-info-bus_info-props; prop prop-name; prop++) {
qdev_property_add_legacy(dev, prop, NULL);
+qdev_property_add_static(dev, prop, NULL);
}
qdev_property_add_str(dev, type, qdev_get_type, NULL, NULL);
@@ -1172,7 +1177,7 @@ static void qdev_set_legacy_property(DeviceState *dev,
Visitor *v, void *opaque,
* @qdev_add_legacy_property - adds a legacy property
*
* Do not use this is new code! Properties added through this interface will
- * be given types in the legacy type namespace.
+ * be given names and types in the legacy namespace.
*
* Legacy properties are always processed as strings. The format of the string
* depends on the property type.
@@ -1180,18 +1185,35 @@ static void qdev_set_legacy_property(DeviceState *dev,
Visitor *v, void *opaque,
void qdev_property_add_legacy(DeviceState *dev, Property *prop,
Error **errp)
{
-gchar *type;
+gchar *name, *type;
+name = g_strdup_printf(legacy-%s, prop-name);
type = g_strdup_printf(legacy%s,
prop-info-legacy_name ?: prop-info-name);
-qdev_property_add(dev, prop-name, type,
+qdev_property_add(dev, name, type,
prop-info-print ? qdev_get_legacy_property : NULL,
prop-info-parse ? qdev_set_legacy_property : NULL,
NULL,
prop, errp);
g_free(type);
+g_free(name);
+}
+
+/**
+ * @qdev_property_add_static - add a @Property to a device.
+ *
+ * Static properties access data in a struct. The actual type of the
+ * property and the field depends on the property type.
+ */
+void qdev_property_add_static(DeviceState *dev, Property *prop,
+ Error **errp)
+{
+qdev_property_add(dev, prop-name, prop-info-name,
+ prop-info-get, prop-info-set,
+ NULL,
+ prop, errp);
}
DeviceState *qdev_get_root(void)
diff --git a/hw/qdev.h b/hw/qdev.h
index 5f23cac..d5896be 100644
--- a/hw/qdev.h
+++ b/hw/qdev.h
@@ -487,11 +487,10 @@ const char *qdev_property_get_type(DeviceState *dev,
const char *name,
Error **errp);
/**
- * @qdev_property_add_legacy - add a legacy @Property to a device
- *
- * DO NOT USE THIS IN NEW CODE!
+ * @qdev_property_add_static - add a @Property to a device referencing a
+ * field in a struct.
*/
-void qdev_property_add_legacy(DeviceState *dev, Property *prop, Error **errp);
+void qdev_property_add_static(DeviceState *dev, Property *prop, Error **errp);
/**
* @qdev_get_root - returns the root device of the composition tree
--
1.7.7.1
[Qemu-devel] [PATCH 7/8] qom: distinguish legacy property type name from QOM type name
Reviewed-by: Anthony Liguori aligu...@us.ibm.com
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
hw/qdev-properties.c | 12
hw/qdev.c|9 ++---
hw/qdev.h|1 +
3 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/hw/qdev-properties.c b/hw/qdev-properties.c
index 41d2165..663c2a0 100644
--- a/hw/qdev-properties.c
+++ b/hw/qdev-properties.c
@@ -86,7 +86,8 @@ static void set_bit(DeviceState *dev, Visitor *v, void
*opaque,
}
PropertyInfo qdev_prop_bit = {
-.name = on/off,
+.name = boolean,
+.legacy_name = on/off,
.type = PROP_TYPE_BIT,
.size = sizeof(uint32_t),
.parse = parse_bit,
@@ -189,7 +190,8 @@ static int print_hex8(DeviceState *dev, Property *prop,
char *dest, size_t len)
}
PropertyInfo qdev_prop_hex8 = {
-.name = hex8,
+.name = uint8,
+.legacy_name = hex8,
.type = PROP_TYPE_UINT8,
.size = sizeof(uint8_t),
.parse = parse_hex8,
@@ -397,7 +399,8 @@ static int print_hex32(DeviceState *dev, Property *prop,
char *dest, size_t len)
}
PropertyInfo qdev_prop_hex32 = {
-.name = hex32,
+.name = uint32,
+.legacy_name = hex32,
.type = PROP_TYPE_UINT32,
.size = sizeof(uint32_t),
.parse = parse_hex32,
@@ -485,7 +488,8 @@ static int print_hex64(DeviceState *dev, Property *prop,
char *dest, size_t len)
}
PropertyInfo qdev_prop_hex64 = {
-.name = hex64,
+.name = uint64,
+.legacy_name = hex64,
.type = PROP_TYPE_UINT64,
.size = sizeof(uint64_t),
.parse = parse_hex64,
diff --git a/hw/qdev.c b/hw/qdev.c
index 2a146f7..c6fcf4c 100644
--- a/hw/qdev.c
+++ b/hw/qdev.c
@@ -218,13 +218,15 @@ int qdev_device_help(QemuOpts *opts)
if (!prop-info-parse) {
continue; /* no way to set it, don't show */
}
-error_printf(%s.%s=%s\n, info-name, prop-name, prop-info-name);
+error_printf(%s.%s=%s\n, info-name, prop-name,
+ prop-info-legacy_name ?: prop-info-name);
}
for (prop = info-bus_info-props; prop prop-name; prop++) {
if (!prop-info-parse) {
continue; /* no way to set it, don't show */
}
-error_printf(%s.%s=%s\n, info-name, prop-name, prop-info-name);
+error_printf(%s.%s=%s\n, info-name, prop-name,
+ prop-info-legacy_name ?: prop-info-name);
}
return 1;
}
@@ -1180,7 +1182,8 @@ void qdev_property_add_legacy(DeviceState *dev, Property
*prop,
{
gchar *type;
-type = g_strdup_printf(legacy%s, prop-info-name);
+type = g_strdup_printf(legacy%s,
+ prop-info-legacy_name ?: prop-info-name);
qdev_property_add(dev, prop-name, type,
prop-info-print ? qdev_get_legacy_property : NULL,
diff --git a/hw/qdev.h b/hw/qdev.h
index 42495ae..5f23cac 100644
--- a/hw/qdev.h
+++ b/hw/qdev.h
@@ -156,6 +156,7 @@ enum PropertyType {
struct PropertyInfo {
const char *name;
+const char *legacy_name;
size_t size;
enum PropertyType type;
int64_t min;
--
1.7.7.1
[Qemu-devel] [PATCH 6/8] qom: introduce get/set methods for Property
This patch adds a visitor interface to Property. This way, QOM will be
able to expose Properties that access a fixed field in a struct without
exposing also the everything-is-a-string feature of qdev properties.
Whenever the printed representation in both QOM and qdev (which is
typically the case for device backends), parse/print code can be reused
via get_generic/set_generic. Dually, whenever multiple PropertyInfos
have the same representation in both the struct and the visitors the
code can be reused (for example among all of int32/uint32/hex32).
Reviewed-by: Anthony Liguori aligu...@us.ibm.com
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
hw/qdev-addr.c | 41 ++
hw/qdev-properties.c | 354 ++
hw/qdev.h|4 +
3 files changed, 399 insertions(+), 0 deletions(-)
diff --git a/hw/qdev-addr.c b/hw/qdev-addr.c
index 305c2d3..5ddda2d 100644
--- a/hw/qdev-addr.c
+++ b/hw/qdev-addr.c
@@ -18,12 +18,53 @@ static int print_taddr(DeviceState *dev, Property *prop,
char *dest, size_t len)
return snprintf(dest, len, 0x TARGET_FMT_plx, *ptr);
}
+static void get_taddr(DeviceState *dev, Visitor *v, void *opaque,
+ const char *name, Error **errp)
+{
+Property *prop = opaque;
+target_phys_addr_t *ptr = qdev_get_prop_ptr(dev, prop);
+int64_t value;
+
+value = *ptr;
+visit_type_int(v, value, name, errp);
+}
+
+static void set_taddr(DeviceState *dev, Visitor *v, void *opaque,
+ const char *name, Error **errp)
+{
+Property *prop = opaque;
+target_phys_addr_t *ptr = qdev_get_prop_ptr(dev, prop);
+Error *local_err = NULL;
+int64_t value;
+
+if (dev-state != DEV_STATE_CREATED) {
+error_set(errp, QERR_PERMISSION_DENIED);
+return;
+}
+
+visit_type_int(v, value, name, local_err);
+if (local_err) {
+error_propagate(errp, local_err);
+return;
+}
+if ((uint64_t)value = (uint64_t) ~(target_phys_addr_t)0) {
+*ptr = value;
+} else {
+error_set(errp, QERR_PROPERTY_VALUE_OUT_OF_RANGE,
+ dev-id?:, name, value, (uint64_t) 0,
+ (uint64_t) ~(target_phys_addr_t)0);
+}
+}
+
+
PropertyInfo qdev_prop_taddr = {
.name = taddr,
.type = PROP_TYPE_TADDR,
.size = sizeof(target_phys_addr_t),
.parse = parse_taddr,
.print = print_taddr,
+.get = get_taddr,
+.set = set_taddr,
};
void qdev_prop_set_taddr(DeviceState *dev, const char *name,
target_phys_addr_t value)
diff --git a/hw/qdev-properties.c b/hw/qdev-properties.c
index de618f2..41d2165 100644
--- a/hw/qdev-properties.c
+++ b/hw/qdev-properties.c
@@ -55,12 +55,44 @@ static int print_bit(DeviceState *dev, Property *prop, char
*dest, size_t len)
return snprintf(dest, len, (*p qdev_get_prop_mask(prop)) ? on : off);
}
+static void get_bit(DeviceState *dev, Visitor *v, void *opaque,
+const char *name, Error **errp)
+{
+Property *prop = opaque;
+uint32_t *p = qdev_get_prop_ptr(dev, prop);
+bool value = (*p qdev_get_prop_mask(prop)) != 0;
+
+visit_type_bool(v, value, name, errp);
+}
+
+static void set_bit(DeviceState *dev, Visitor *v, void *opaque,
+const char *name, Error **errp)
+{
+Property *prop = opaque;
+Error *local_err = NULL;
+bool value;
+
+if (dev-state != DEV_STATE_CREATED) {
+error_set(errp, QERR_PERMISSION_DENIED);
+return;
+}
+
+visit_type_bool(v, value, name, local_err);
+if (local_err) {
+error_propagate(errp, local_err);
+return;
+}
+bit_prop_set(dev, prop, value);
+}
+
PropertyInfo qdev_prop_bit = {
.name = on/off,
.type = PROP_TYPE_BIT,
.size = sizeof(uint32_t),
.parse = parse_bit,
.print = print_bit,
+.get = get_bit,
+.set = set_bit,
};
/* --- 8bit integer --- */
@@ -85,12 +117,54 @@ static int print_uint8(DeviceState *dev, Property *prop,
char *dest, size_t len)
return snprintf(dest, len, % PRIu8, *ptr);
}
+static void get_int8(DeviceState *dev, Visitor *v, void *opaque,
+ const char *name, Error **errp)
+{
+Property *prop = opaque;
+int8_t *ptr = qdev_get_prop_ptr(dev, prop);
+int64_t value;
+
+value = *ptr;
+visit_type_int(v, value, name, errp);
+}
+
+static void set_int8(DeviceState *dev, Visitor *v, void *opaque,
+ const char *name, Error **errp)
+{
+Property *prop = opaque;
+int8_t *ptr = qdev_get_prop_ptr(dev, prop);
+Error *local_err = NULL;
+int64_t value;
+
+if (dev-state != DEV_STATE_CREATED) {
+error_set(errp, QERR_PERMISSION_DENIED);
+return;
+}
+
+visit_type_int(v, value, name, local_err);
+if (local_err) {
+error_propagate(errp, local_err);
+return;
+}
+if (value prop-info-min value = prop-info-max) {
+*ptr = value;
+
[Qemu-devel] [PATCH 5/8] qom: introduce QERR_PROPERTY_VALUE_OUT_OF_RANGE
This will be used when reject invalid values for integer fields that
are less than 64-bits wide.
Reviewed-by: Anthony Liguori aligu...@us.ibm.com
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
qerror.c |5 +
qerror.h |3 +++
2 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/qerror.c b/qerror.c
index adde8a5..9a75d06 100644
--- a/qerror.c
+++ b/qerror.c
@@ -206,6 +206,11 @@ static const QErrorStringTable qerror_table[] = {
.desc = Property '%(device).%(property)' can't find value
'%(value)',
},
{
+.error_fmt = QERR_PROPERTY_VALUE_OUT_OF_RANGE,
+.desc = Property '%(device).%(property)' doesn't take
+ value %(value) (minimum: %(min), maximum: %(max)',
+},
+{
.error_fmt = QERR_QMP_BAD_INPUT_OBJECT,
.desc = Expected '%(expected)' in QMP input,
},
diff --git a/qerror.h b/qerror.h
index 9190b02..efda232 100644
--- a/qerror.h
+++ b/qerror.h
@@ -171,6 +171,9 @@ QError *qobject_to_qerror(const QObject *obj);
#define QERR_PROPERTY_VALUE_NOT_FOUND \
{ 'class': 'PropertyValueNotFound', 'data': { 'device': %s, 'property':
%s, 'value': %s } }
+#define QERR_PROPERTY_VALUE_OUT_OF_RANGE \
+{ 'class': 'PropertyValueOutOfRange', 'data': { 'device': %s, 'property':
%s, 'value': %PRId64, 'min': %PRId64, 'max': %PRId64 } }
+
#define QERR_QMP_BAD_INPUT_OBJECT \
{ 'class': 'QMPBadInputObject', 'data': { 'expected': %s } }
--
1.7.7.1
[Qemu-devel] [PATCH 2/8] qom: fix swapped parameters
Reviewed-by: Anthony Liguori anth...@codemonkey.ws
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
hw/qdev.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/hw/qdev.c b/hw/qdev.c
index 83913c7..bda8d6c 100644
--- a/hw/qdev.c
+++ b/hw/qdev.c
@@ -1110,7 +1110,7 @@ void qdev_property_set(DeviceState *dev, Visitor *v,
const char *name,
if (!prop-set) {
error_set(errp, QERR_PERMISSION_DENIED);
} else {
-prop-set(dev, prop-opaque, v, name, errp);
+prop-set(dev, v, prop-opaque, name, errp);
}
}
--
1.7.7.1
[Qemu-devel] [PATCH 4/8] qom: interpret the return value when setting legacy properties
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
hw/qdev-properties.c | 41 ++---
hw/qdev.c|5 +
hw/qdev.h|2 ++
3 files changed, 29 insertions(+), 19 deletions(-)
diff --git a/hw/qdev-properties.c b/hw/qdev-properties.c
index f0b811c..de618f2 100644
--- a/hw/qdev-properties.c
+++ b/hw/qdev-properties.c
@@ -614,6 +614,28 @@ int qdev_prop_exists(DeviceState *dev, const char *name)
return qdev_prop_find(dev, name) ? true : false;
}
+void error_set_from_qdev_prop_error(Error **errp, int ret, DeviceState *dev,
+Property *prop, const char *value)
+{
+switch (ret) {
+case -EEXIST:
+error_set(errp, QERR_PROPERTY_VALUE_IN_USE,
+ dev-info-name, prop-name, value);
+break;
+default:
+case -EINVAL:
+error_set(errp, QERR_PROPERTY_VALUE_BAD,
+ dev-info-name, prop-name, value);
+break;
+case -ENOENT:
+error_set(errp, QERR_PROPERTY_VALUE_NOT_FOUND,
+ dev-info-name, prop-name, value);
+break;
+case 0:
+break;
+}
+}
+
int qdev_prop_parse(DeviceState *dev, const char *name, const char *value)
{
Property *prop;
@@ -632,21 +654,10 @@ int qdev_prop_parse(DeviceState *dev, const char *name,
const char *value)
}
ret = prop-info-parse(dev, prop, value);
if (ret 0) {
-switch (ret) {
-case -EEXIST:
-qerror_report(QERR_PROPERTY_VALUE_IN_USE,
- dev-info-name, name, value);
-break;
-default:
-case -EINVAL:
-qerror_report(QERR_PROPERTY_VALUE_BAD,
- dev-info-name, name, value);
-break;
-case -ENOENT:
-qerror_report(QERR_PROPERTY_VALUE_NOT_FOUND,
- dev-info-name, name, value);
-break;
-}
+Error *err;
+error_set_from_qdev_prop_error(err, ret, dev, prop, value);
+qerror_report_err(err);
+error_free(err);
return -1;
}
return 0;
diff --git a/hw/qdev.c b/hw/qdev.c
index c020a6f..2a146f7 100644
--- a/hw/qdev.c
+++ b/hw/qdev.c
@@ -1162,10 +1162,7 @@ static void qdev_set_legacy_property(DeviceState *dev,
Visitor *v, void *opaque,
}
ret = prop-info-parse(dev, prop, ptr);
-if (ret != 0) {
-error_set(errp, QERR_INVALID_PARAMETER_VALUE,
- name, prop-info-name);
-}
+error_set_from_qdev_prop_error(errp, ret, dev, prop, ptr);
g_free(ptr);
}
diff --git a/hw/qdev.h b/hw/qdev.h
index 6e18427..94f5ce9 100644
--- a/hw/qdev.h
+++ b/hw/qdev.h
@@ -370,6 +370,8 @@ void qdev_prop_set_defaults(DeviceState *dev, Property
*props);
void qdev_prop_register_global_list(GlobalProperty *props);
void qdev_prop_set_globals(DeviceState *dev);
+void error_set_from_qdev_prop_error(Error **errp, int ret, DeviceState *dev,
+Property *prop, const char *value);
static inline const char *qdev_fw_name(DeviceState *dev)
{
--
1.7.7.1
[Qemu-devel] [PATCH] hw/9pfs: iattr_valid flags are kernel internal flags map them to 9p values.
From: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
Kernel internal values can change, add protocol values for these constant and
use them.
Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
---
hw/9pfs/virtio-9p.c | 47 ---
1 files changed, 24 insertions(+), 23 deletions(-)
diff --git a/hw/9pfs/virtio-9p.c b/hw/9pfs/virtio-9p.c
index b3fc3d0..567f6cb 100644
--- a/hw/9pfs/virtio-9p.c
+++ b/hw/9pfs/virtio-9p.c
@@ -1293,17 +1293,18 @@ out_nofid:
complete_pdu(s, pdu, retval);
}
-/* From Linux kernel code */
-#define ATTR_MODE(1 0)
-#define ATTR_UID (1 1)
-#define ATTR_GID (1 2)
-#define ATTR_SIZE(1 3)
-#define ATTR_ATIME (1 4)
-#define ATTR_MTIME (1 5)
-#define ATTR_CTIME (1 6)
-#define ATTR_MASK127
-#define ATTR_ATIME_SET (1 7)
-#define ATTR_MTIME_SET (1 8)
+/* Attribute flags */
+#define P9_ATTR_MODE (1 0)
+#define P9_ATTR_UID(1 1)
+#define P9_ATTR_GID(1 2)
+#define P9_ATTR_SIZE (1 3)
+#define P9_ATTR_ATIME (1 4)
+#define P9_ATTR_MTIME (1 5)
+#define P9_ATTR_CTIME (1 6)
+#define P9_ATTR_ATIME_SET (1 7)
+#define P9_ATTR_MTIME_SET (1 8)
+
+#define P9_ATTR_MASK127
static void v9fs_setattr(void *opaque)
{
@@ -1322,16 +1323,16 @@ static void v9fs_setattr(void *opaque)
err = -EINVAL;
goto out_nofid;
}
-if (v9iattr.valid ATTR_MODE) {
+if (v9iattr.valid P9_ATTR_MODE) {
err = v9fs_co_chmod(pdu, fidp-path, v9iattr.mode);
if (err 0) {
goto out;
}
}
-if (v9iattr.valid (ATTR_ATIME | ATTR_MTIME)) {
+if (v9iattr.valid (P9_ATTR_ATIME | P9_ATTR_MTIME)) {
struct timespec times[2];
-if (v9iattr.valid ATTR_ATIME) {
-if (v9iattr.valid ATTR_ATIME_SET) {
+if (v9iattr.valid P9_ATTR_ATIME) {
+if (v9iattr.valid P9_ATTR_ATIME_SET) {
times[0].tv_sec = v9iattr.atime_sec;
times[0].tv_nsec = v9iattr.atime_nsec;
} else {
@@ -1340,8 +1341,8 @@ static void v9fs_setattr(void *opaque)
} else {
times[0].tv_nsec = UTIME_OMIT;
}
-if (v9iattr.valid ATTR_MTIME) {
-if (v9iattr.valid ATTR_MTIME_SET) {
+if (v9iattr.valid P9_ATTR_MTIME) {
+if (v9iattr.valid P9_ATTR_MTIME_SET) {
times[1].tv_sec = v9iattr.mtime_sec;
times[1].tv_nsec = v9iattr.mtime_nsec;
} else {
@@ -1359,13 +1360,13 @@ static void v9fs_setattr(void *opaque)
* If the only valid entry in iattr is ctime we can call
* chown(-1,-1) to update the ctime of the file
*/
-if ((v9iattr.valid (ATTR_UID | ATTR_GID)) ||
-((v9iattr.valid ATTR_CTIME)
- !((v9iattr.valid ATTR_MASK) ~ATTR_CTIME))) {
-if (!(v9iattr.valid ATTR_UID)) {
+if ((v9iattr.valid (P9_ATTR_UID | P9_ATTR_GID)) ||
+((v9iattr.valid P9_ATTR_CTIME)
+ !((v9iattr.valid P9_ATTR_MASK) ~P9_ATTR_CTIME))) {
+if (!(v9iattr.valid P9_ATTR_UID)) {
v9iattr.uid = -1;
}
-if (!(v9iattr.valid ATTR_GID)) {
+if (!(v9iattr.valid P9_ATTR_GID)) {
v9iattr.gid = -1;
}
err = v9fs_co_chown(pdu, fidp-path, v9iattr.uid,
@@ -1374,7 +1375,7 @@ static void v9fs_setattr(void *opaque)
goto out;
}
}
-if (v9iattr.valid (ATTR_SIZE)) {
+if (v9iattr.valid (P9_ATTR_SIZE)) {
err = v9fs_co_truncate(pdu, fidp-path, v9iattr.size);
if (err 0) {
goto out;
--
1.7.8.247.g10f4e.dirty
Re: [Qemu-devel] [PATCH V2 5/5] vga-cirrus: Workaround during restore when using Xen.
On 12/12/2011 05:32 PM, Stefano Stabellini wrote: Really, I think this is something inherently incompatible with the current memory API. If Xen has this unfixable special requirement (it's rather a design issue IMHO), adjust the API and adapt all devices. Hot-fixing only a single one this way is no good idea long term. Fair enough. What about introducing a type of savevm state that is going to be restored before machine-init? This way we could save and restore our physmap and we could handle memory maps and allocations transparently. There is no guarantee there is a physical mapping for the framebuffer. A guest could unmap the framebuffer, and its display should still be valid. It can even update it by using the cirrus bitblt functions. I suggest doing the following: 1. keep cirrus code unchanged 2. when the framebuffer is first mapped into physical memory (as known by your CPUPhysMemoryClient), copy it into a temporary buffer, map the guest memory into memory_region_get_ram_ptr(), and copy the temporary buffer into memory_region_get_ram_ptr() 3. when the framebuffer is unmapped, do the reverse: copy the framebuffer out, mmap() some anonymous memory into memory_region_get_ram_ptr(), and copy the temporary buffer into memory_region_get_ram_ptr() We can later add optimizations to avoid the copy, but correctness before performance. I think currently a guest moving its cirrus BAR will break, no? -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] early_savevm
On 12/13/2011 01:55 PM, Stefano Stabellini wrote: A bit more context to my suggestion: - we open the save state file and check the magic number and the version number before machine-init(); - we add a new set of entries to the save state file that contains early_savevm functions: they are called before machine-init(); - after reaching the end of the early_savevm functions we stop parsing the save state file and we call machine-init(); - after machine-init() is completed we continue parsing the save state file as usual. I think this is fragile. In the general case you can't describe the framebuffer BAR with just a single number, it may be partially obscured by another BAR. It's better to fix this behind the scenes. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [PATCH V2 1/5] vl.c: Do not save RAM state when Xen is used.
On 12/15/2011 05:12 PM, Anthony Liguori wrote:
On 12/09/2011 03:54 PM, Anthony PERARD wrote:
In Xen case, the guest RAM is not handle by QEMU, and it is saved by
Xen tools.
So, we just avoid to register the RAM save state handler.
-register_savevm_live(NULL, ram, 0, 4, NULL, ram_save_live, NULL,
- ram_load, NULL);
+if (!xen_enabled()) {
+register_savevm_live(NULL, ram, 0, 4, NULL, ram_save_live,
NULL,
+ ram_load, NULL);
+}
Why don't you just unregister the section in the xen initialization
code? That way we don't have xen_enabled()'s sprinkled all over the
place.
It's better to see them up front, having the magical string ram
connect the two is hard to follow.
--
error compiling committee.c: too many arguments to function
[Qemu-devel] Unsubscription Confirmation
Thank you for subscribing. You have now unsubscribed and no more messages will be sent.
[Qemu-devel] [PATCH 08/10] hw/sd.c: Correct handling of type B SD status bits
Correct how we handle the type B (cleared on valid command)
status bits. In particular, the CURRENT_STATE bits in a response
should be the state of the card when it received that command,
not the state when it received the preceding command. (This is
one of the issues noted in LP:597641.)
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
hw/sd.c | 44 +---
1 files changed, 25 insertions(+), 19 deletions(-)
diff --git a/hw/sd.c b/hw/sd.c
index 9eebfac..e1565b6 100644
--- a/hw/sd.c
+++ b/hw/sd.c
@@ -104,7 +104,7 @@ struct SDState {
int enable;
};
-static void sd_set_status(SDState *sd)
+static void sd_set_mode(SDState *sd)
{
switch (sd-state) {
case sd_inactive_state:
@@ -126,9 +126,6 @@ static void sd_set_status(SDState *sd)
sd-mode = sd_data_transfer_mode;
break;
}
-
-sd-card_status = ~CURRENT_STATE;
-sd-card_status |= sd-state 9;
}
static const sd_cmd_type_t sd_cmd_type[64] = {
@@ -341,13 +338,10 @@ static int sd_req_crc_validate(SDRequest *req)
return sd_crc7(buffer, 5) != req-crc; /* TODO */
}
-static void sd_response_r1_make(SDState *sd,
-uint8_t *response, uint32_t last_status)
+static void sd_response_r1_make(SDState *sd, uint8_t *response)
{
-uint32_t mask = CARD_STATUS_B ^ ILLEGAL_COMMAND;
-uint32_t status;
-
-status = (sd-card_status ~mask) | (last_status mask);
+uint32_t status = sd-card_status;
+/* Clear the clear on read status bits (except APP_CMD) */
sd-card_status = ~CARD_STATUS_C | APP_CMD;
response[0] = (status 24) 0xff;
@@ -1286,7 +1280,7 @@ static int cmd_valid_while_locked(SDState *sd, SDRequest
*req)
int sd_do_command(SDState *sd, SDRequest *req,
uint8_t *response) {
-uint32_t last_status = sd-card_status;
+int last_state;
sd_rsp_type_t rtype;
int rsplen;
@@ -1300,10 +1294,7 @@ int sd_do_command(SDState *sd, SDRequest *req,
goto send_response;
}
-sd-card_status = ~CARD_STATUS_B;
-sd_set_status(sd);
-
-if (last_status CARD_IS_LOCKED) {
+if (sd-card_status CARD_IS_LOCKED) {
if (!cmd_valid_while_locked(sd, req)) {
sd-card_status |= ILLEGAL_COMMAND;
fprintf(stderr, SD: Card is locked\n);
@@ -1312,7 +1303,10 @@ int sd_do_command(SDState *sd, SDRequest *req,
}
}
-if (last_status APP_CMD) {
+last_state = sd-state;
+sd_set_mode(sd);
+
+if (sd-card_status APP_CMD) {
rtype = sd_app_command(sd, *req);
sd-card_status = ~APP_CMD;
} else
@@ -1320,15 +1314,20 @@ int sd_do_command(SDState *sd, SDRequest *req,
if (rtype == sd_illegal) {
sd-card_status |= ILLEGAL_COMMAND;
+} else {
+/* Valid command, we can update the 'state before command' bits.
+ * (Do this now so they appear in r1 responses.)
+ */
+sd-current_cmd = req-cmd;
+sd-card_status = ~CURRENT_STATE;
+sd-card_status |= (last_state 9);
}
-sd-current_cmd = req-cmd;
-
send_response:
switch (rtype) {
case sd_r1:
case sd_r1b:
-sd_response_r1_make(sd, response, last_status);
+sd_response_r1_make(sd, response);
rsplen = 4;
break;
@@ -1364,6 +1363,13 @@ send_response:
break;
}
+if (rtype != sd_illegal) {
+/* Clear the clear on valid command status bits now we've
+ * sent any response
+ */
+sd-card_status = ~CARD_STATUS_B;
+}
+
#ifdef DEBUG_SD
if (rsplen) {
int i;
--
1.7.5.4
[Qemu-devel] [PATCH 01/10] hw/sd.c: Fix the set of commands which are failed when card is locked
Fix bugs in the code determining whether to accept a card when the
SD card is locked. Most notably, we had the condition completely
reversed, so we would accept all the commands we should refuse and
refuse all the commands we should accept. Correct this by refactoring
the enormous if () clause into a separate function.
We had also missed ACMD42 off the list of commands which are accepted
in locked state: add it.
This is one of the two problems reported in LP:597641.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
hw/sd.c | 29 ++---
1 files changed, 22 insertions(+), 7 deletions(-)
diff --git a/hw/sd.c b/hw/sd.c
index 10e26ad..a1c98c0 100644
--- a/hw/sd.c
+++ b/hw/sd.c
@@ -1265,6 +1265,25 @@ static sd_rsp_type_t sd_app_command(SDState *sd,
return sd_r0;
}
+static int cmd_valid_while_locked(SDState *sd, SDRequest *req)
+{
+/* Valid commands in locked state:
+ * basic class (0)
+ * lock card class (7)
+ * CMD16
+ * implicitly, the ACMD prefix CMD55
+ * ACMD41 and ACMD42
+ * Anything else provokes an illegal command response.
+ */
+if (sd-card_status APP_CMD) {
+return req-cmd == 41 || req-cmd == 42;
+}
+if (req-cmd == 16 || req-cmd == 55) {
+return 1;
+}
+return sd_cmd_class[req-cmd] == 0 || sd_cmd_class[req-cmd] == 7;
+}
+
int sd_do_command(SDState *sd, SDRequest *req,
uint8_t *response) {
uint32_t last_status = sd-card_status;
@@ -1283,17 +1302,13 @@ int sd_do_command(SDState *sd, SDRequest *req,
sd-card_status = ~CARD_STATUS_B;
sd_set_status(sd);
-if (last_status CARD_IS_LOCKED)
-if (((last_status APP_CMD)
- req-cmd == 41) ||
-(!(last_status APP_CMD)
- (sd_cmd_class[req-cmd] == 0 ||
- sd_cmd_class[req-cmd] == 7 ||
- req-cmd == 16 || req-cmd == 55))) {
+if (last_status CARD_IS_LOCKED) {
+if (!cmd_valid_while_locked(sd, req)) {
sd-card_status |= ILLEGAL_COMMAND;
fprintf(stderr, SD: Card is locked\n);
return 0;
}
+}
if (last_status APP_CMD) {
rtype = sd_app_command(sd, *req);
--
1.7.5.4
[Qemu-devel] [PATCH 10/10] hw/sd.c: Clear status bits when read via response r6
Response format r6 includes a subset of the status bits; clear the clear-on-read bits which are read by an r6 response. Signed-off-by: Peter Maydell peter.mayd...@linaro.org --- hw/sd.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/hw/sd.c b/hw/sd.c index 6614cbf..2b8ebe4 100644 --- a/hw/sd.c +++ b/hw/sd.c @@ -371,6 +371,7 @@ static void sd_response_r6_make(SDState *sd, uint8_t *response) status = ((sd-card_status 8) 0xc000) | ((sd-card_status 6) 0x2000) | (sd-card_status 0x1fff); +sd-card_status = ~(CARD_STATUS_C 0xc81fff); response[0] = (arg 8) 0xff; response[1] = arg 0xff; -- 1.7.5.4
[Qemu-devel] [PATCH RFC v3 1/2] hyper-v: introduce Hyper-V support infrastructure.
---
Makefile.target |2 +
target-i386/cpuid.c | 14 ++
target-i386/hyperv.c | 65 ++
target-i386/hyperv.h | 37
4 files changed, 118 insertions(+), 0 deletions(-)
create mode 100644 target-i386/hyperv.c
create mode 100644 target-i386/hyperv.h
diff --git a/Makefile.target b/Makefile.target
index 6e742c2..6245796 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -209,6 +209,8 @@ obj-$(CONFIG_NO_KVM) += kvm-stub.o
obj-y += memory.o
LIBS+=-lz
+obj-i386-y +=hyperv.o
+
QEMU_CFLAGS += $(VNC_TLS_CFLAGS)
QEMU_CFLAGS += $(VNC_SASL_CFLAGS)
QEMU_CFLAGS += $(VNC_JPEG_CFLAGS)
diff --git a/target-i386/cpuid.c b/target-i386/cpuid.c
index 1e8bcff..4193df1 100644
--- a/target-i386/cpuid.c
+++ b/target-i386/cpuid.c
@@ -27,6 +27,8 @@
#include qemu-option.h
#include qemu-config.h
+#include hyperv.h
+
/* feature flags taken from Intel Processor Identification and the CPUID
* Instruction and AMD's CPUID Specification. In cases of disagreement
* between feature naming conventions, aliases may be added.
@@ -716,6 +718,14 @@ static int cpu_x86_find_by_name(x86_def_t *x86_cpu_def,
const char *cpu_model)
goto error;
}
x86_cpu_def-tsc_khz = tsc_freq / 1000;
+} else if (!strcmp(featurestr, hv_spinlocks)) {
+char *err;
+numvalue = strtoul(val, err, 0);
+if (!*val || *err) {
+fprintf(stderr, bad numerical value %s\n, val);
+goto error;
+}
+hyperv_set_spinlock_retries(numvalue);
} else {
fprintf(stderr, unrecognized feature %s\n, featurestr);
goto error;
@@ -724,6 +734,10 @@ static int cpu_x86_find_by_name(x86_def_t *x86_cpu_def,
const char *cpu_model)
check_cpuid = 1;
} else if (!strcmp(featurestr, enforce)) {
check_cpuid = enforce_cpuid = 1;
+} else if (!strcmp(featurestr, hv_relaxed)) {
+hyperv_enable_relaxed_timing(true);
+} else if (!strcmp(featurestr, hv_vapic)) {
+hyperv_enable_vapic_recommended(true);
} else {
fprintf(stderr, feature string `%s' not in format
(+feature|-feature|feature=xyz)\n, featurestr);
goto error;
diff --git a/target-i386/hyperv.c b/target-i386/hyperv.c
new file mode 100644
index 000..b2e57ad
--- /dev/null
+++ b/target-i386/hyperv.c
@@ -0,0 +1,65 @@
+/*
+ * QEMU Hyper-V support
+ *
+ * Copyright Red Hat, Inc. 2011
+ *
+ * Author: Vadim Rozenfeld vroze...@redhat.com
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ *
+ */
+
+#include hyperv.h
+
+static bool hyperv_vapic;
+static bool hyperv_relaxed_timing;
+static int hyperv_spinlock_attempts = HYPERV_SPINLOCK_NEVER_RETRY;
+
+void hyperv_enable_vapic_recommended(bool val)
+{
+hyperv_vapic = val;
+}
+
+void hyperv_enable_relaxed_timing(bool val)
+{
+hyperv_relaxed_timing = val;
+}
+
+void hyperv_set_spinlock_retries(int val)
+{
+hyperv_spinlock_attempts = val;
+if (hyperv_spinlock_attempts 0xFFF) {
+hyperv_spinlock_attempts = 0xFFF;
+}
+}
+
+bool hyperv_enabled(void)
+{
+return hyperv_hypercall_available() || hyperv_relaxed_timing_enabled();
+}
+
+bool hyperv_hypercall_available(void)
+{
+if (hyperv_vapic ||
+(hyperv_spinlock_attempts != HYPERV_SPINLOCK_NEVER_RETRY)) {
+ return true;
+}
+return false;
+}
+
+bool hyperv_vapic_recommended(void)
+{
+return hyperv_vapic;
+}
+
+bool hyperv_relaxed_timing_enabled(void)
+{
+return hyperv_relaxed_timing;
+}
+
+int hyperv_get_spinlock_retries(void)
+{
+return hyperv_spinlock_attempts;
+}
+
diff --git a/target-i386/hyperv.h b/target-i386/hyperv.h
new file mode 100644
index 000..0d742f8
--- /dev/null
+++ b/target-i386/hyperv.h
@@ -0,0 +1,37 @@
+/*
+ * QEMU Hyper-V support
+ *
+ * Copyright Red Hat, Inc. 2011
+ *
+ * Author: Vadim Rozenfeld vroze...@redhat.com
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ *
+ */
+
+#ifndef QEMU_HW_HYPERV_H
+#define QEMU_HW_HYPERV_H 1
+
+#include qemu-common.h
+#include asm/hyperv.h
+
+#ifndef HYPERV_SPINLOCK_NEVER_RETRY
+#define HYPERV_SPINLOCK_NEVER_RETRY 0x
+#endif
+
+#ifndef KVM_CPUID_SIGNATURE_NEXT
+#define KVM_CPUID_SIGNATURE_NEXT0x4100
+#endif
+
+void hyperv_enable_vapic_recommended(bool val);
+void hyperv_enable_relaxed_timing(bool val);
+void hyperv_set_spinlock_retries(int val);
+
+bool hyperv_enabled(void);
+bool hyperv_hypercall_available(void);
+bool hyperv_vapic_recommended(void);
+bool hyperv_relaxed_timing_enabled(void);
+int hyperv_get_spinlock_retries(void);
+
+#endif /* QEMU_HW_HYPERV_H */
--
1.7.4.4
[Qemu-devel] [PATCH RFC v3 0/2] Initial support for Microsoft Hyper-V.
With the following series of patches we are starting to implement some basic Microsoft Hyper-V Enlightenment functionality. This series is mostly about adding support for relaxed timing, spinlock, and virtual apic. For more Hyper-V related information please see: Hypervisor Functional Specification v2.0: For Windows Server 2008 R2 at http://www.microsoft.com/download/en/details.aspx?displaylang=enid=18673 Changelog: v3-v2 - fix indention, - drop reading HV MSRs inside of kvm_get_msrs routine. v2-v1 - remove KVM_CAP_IRQCHIP ifdef, - remove CONFIG_HYPERV config option, - move KVM leaves to new location (0x4100), - cosmetic changes. v0-v1 - move hyper-v parameters under cpu category, - move hyper-v stuff to target-i386 directory, - make CONFIG_HYPERV enabled by default for i386-softmmu and x86_64-softmmu configurations, - rearrange the patches from v0, - set HV_X64_MSR_HYPERCALL, HV_X64_MSR_GUEST_OS_ID, and HV_X64_MSR_APIC_ASSIST_PAGE to 0 on system reset. Vadim Rozenfeld (2): hyper-v: introduce Hyper-V support infrastructure. hyper-v: initialize Hyper-V CPUID leaves. Makefile.target |2 + target-i386/cpuid.c | 14 ++ target-i386/hyperv.c | 65 ++ target-i386/hyperv.h | 37 target-i386/kvm.c| 65 - 5 files changed, 181 insertions(+), 2 deletions(-) create mode 100644 target-i386/hyperv.c create mode 100644 target-i386/hyperv.h -- 1.7.4.4
[Qemu-devel] [PATCH RFC v3 2/2] hyper-v: initialize Hyper-V CPUID leaves.
---
target-i386/kvm.c | 65 +++-
1 files changed, 63 insertions(+), 2 deletions(-)
diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index 9080996..731cc8d 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -29,6 +29,7 @@
#include hw/pc.h
#include hw/apic.h
#include ioport.h
+#include hyperv.h
//#define DEBUG_KVM
@@ -381,11 +382,16 @@ int kvm_arch_init_vcpu(CPUState *env)
cpuid_i = 0;
/* Paravirtualization CPUIDs */
-memcpy(signature, KVMKVMKVM\0\0\0, 12);
c = cpuid_data.entries[cpuid_i++];
memset(c, 0, sizeof(*c));
c-function = KVM_CPUID_SIGNATURE;
-c-eax = 0;
+if (!hyperv_enabled()) {
+memcpy(signature, KVMKVMKVM\0\0\0, 12);
+c-eax = 0;
+} else {
+memcpy(signature, Microsoft Hv, 12);
+c-eax = HYPERV_CPUID_MIN;
+}
c-ebx = signature[0];
c-ecx = signature[1];
c-edx = signature[2];
@@ -396,6 +402,54 @@ int kvm_arch_init_vcpu(CPUState *env)
c-eax = env-cpuid_kvm_features
kvm_arch_get_supported_cpuid(s, KVM_CPUID_FEATURES, 0, R_EAX);
+if (hyperv_enabled()) {
+memcpy(signature, Hv#1\0\0\0\0\0\0\0\0, 12);
+c-eax = signature[0];
+
+c = cpuid_data.entries[cpuid_i++];
+memset(c, 0, sizeof(*c));
+c-function = HYPERV_CPUID_VERSION;
+c-eax = 0x1bbc;
+c-ebx = 0x00060001;
+
+c = cpuid_data.entries[cpuid_i++];
+memset(c, 0, sizeof(*c));
+c-function = HYPERV_CPUID_FEATURES;
+if (hyperv_relaxed_timing_enabled()) {
+c-eax |= HV_X64_MSR_HYPERCALL_AVAILABLE;
+}
+if (hyperv_vapic_recommended()) {
+c-eax |= HV_X64_MSR_HYPERCALL_AVAILABLE;
+c-eax |= HV_X64_MSR_APIC_ACCESS_AVAILABLE;
+}
+
+c = cpuid_data.entries[cpuid_i++];
+memset(c, 0, sizeof(*c));
+c-function = HYPERV_CPUID_ENLIGHTMENT_INFO;
+if (hyperv_relaxed_timing_enabled()) {
+c-eax |= HV_X64_RELAXED_TIMING_RECOMMENDED;
+}
+if (hyperv_vapic_recommended()) {
+c-eax |= HV_X64_APIC_ACCESS_RECOMMENDED;
+}
+c-ebx = hyperv_get_spinlock_retries();
+
+c = cpuid_data.entries[cpuid_i++];
+memset(c, 0, sizeof(*c));
+c-function = HYPERV_CPUID_IMPLEMENT_LIMITS;
+c-eax = 0x40;
+c-ebx = 0x40;
+
+c = cpuid_data.entries[cpuid_i++];
+memset(c, 0, sizeof(*c));
+c-function = KVM_CPUID_SIGNATURE_NEXT;
+memcpy(signature, KVMKVMKVM\0\0\0, 12);
+c-eax = 0;
+c-ebx = signature[0];
+c-ecx = signature[1];
+c-edx = signature[2];
+}
+
has_msr_async_pf_en = c-eax (1 KVM_FEATURE_ASYNC_PF);
cpu_x86_cpuid(env, 0, 0, limit, unused, unused, unused);
@@ -962,6 +1016,13 @@ static int kvm_put_msrs(CPUState *env, int level)
kvm_msr_entry_set(msrs[n++], MSR_KVM_ASYNC_PF_EN,
env-async_pf_en_msr);
}
+if (hyperv_hypercall_available()) {
+kvm_msr_entry_set(msrs[n++], HV_X64_MSR_GUEST_OS_ID, 0);
+kvm_msr_entry_set(msrs[n++], HV_X64_MSR_HYPERCALL, 0);
+}
+if (hyperv_vapic_recommended()) {
+kvm_msr_entry_set(msrs[n++], HV_X64_MSR_APIC_ASSIST_PAGE, 0);
+}
}
if (env-mcg_cap) {
int i;
--
1.7.4.4
Re: [Qemu-devel] [RFC 0/4] virtio-mmio transport
On Mon, 12 Dec 2011 14:45:26 +, Paul Brook p...@codesourcery.com wrote: I can do that, but not this year (on holiday from Friday 16th, without any access to Internet whatsoever :-) One think to be decided is in what order the halfs should be filled? Low first, then high? High then low? Does it matter at all? :-) My inital though was that you shouldn't be changing this value when the ring is enabled. Unfortunately you disable the ring by setting the address to zero so that argument doesn't work :-/ It only does that after a reset, and since reset should set the values to 0 (I don't think the spec says that, but it will for the new config) we needn't do it at all. It's just a convenient value for the driver to read and know the ring has been cleaned up. I think initialize by QueueNum makes sense. Thanks, Rusty.
[Qemu-devel] [PATCH 06/10] hw/sd.c: Handle CRC and locked-card errors in normal code path
Handle returning CRC and locked-card errors in the same code path
we use for other responses. This makes no difference in behaviour
but means that these error responses will be printed by the debug
logging code.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
hw/sd.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/hw/sd.c b/hw/sd.c
index 57925af..9116f67 100644
--- a/hw/sd.c
+++ b/hw/sd.c
@@ -1296,7 +1296,8 @@ int sd_do_command(SDState *sd, SDRequest *req,
if (sd_req_crc_validate(req)) {
sd-card_status |= COM_CRC_ERROR;
-return 0;
+rtype = sd_illegal;
+goto send_response;
}
sd-card_status = ~CARD_STATUS_B;
@@ -1306,7 +1307,8 @@ int sd_do_command(SDState *sd, SDRequest *req,
if (!cmd_valid_while_locked(sd, req)) {
sd-card_status |= ILLEGAL_COMMAND;
fprintf(stderr, SD: Card is locked\n);
-return 0;
+rtype = sd_illegal;
+goto send_response;
}
}
@@ -1322,6 +1324,7 @@ int sd_do_command(SDState *sd, SDRequest *req,
sd-current_cmd = req-cmd;
+send_response:
switch (rtype) {
case sd_r1:
case sd_r1b:
--
1.7.5.4
[Qemu-devel] [PATCH 05/10] hw/sd.c: Handle illegal commands in sd_do_command
Add an extra sd_illegal value to the sd_rsp_type_t enum so that
sd_app_command() and sd_normal_command() can tell sd_do_command()
that the command was illegal. This is needed so we can do things
like reset certain status bits only on receipt of a valid command.
For the moment, just use it to pull out the setting of the
ILLEGAL_COMMAND status bit into sd_do_command().
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
hw/sd.c | 25 +++--
1 files changed, 11 insertions(+), 14 deletions(-)
diff --git a/hw/sd.c b/hw/sd.c
index dd28061..57925af 100644
--- a/hw/sd.c
+++ b/hw/sd.c
@@ -51,6 +51,7 @@ typedef enum {
sd_r6 = 6,/* Published RCA response */
sd_r7,/* Operating voltage */
sd_r1b = -1,
+sd_illegal = -2,
} sd_rsp_type_t;
struct SDState {
@@ -679,8 +680,7 @@ static sd_rsp_type_t sd_normal_command(SDState *sd,
break;
case 5: /* CMD5: reserved for SDIO cards */
-sd-card_status |= ILLEGAL_COMMAND;
-return sd_r0;
+return sd_illegal;
case 6:/* CMD6: SWITCH_FUNCTION */
if (sd-spi)
@@ -1115,8 +1115,7 @@ static sd_rsp_type_t sd_normal_command(SDState *sd,
* on stderr, as some OSes may use these in their
* probing for presence of an SDIO card.
*/
-sd-card_status |= ILLEGAL_COMMAND;
-return sd_r0;
+return sd_illegal;
/* Application specific commands (Class 8) */
case 55: /* CMD55: APP_CMD */
@@ -1145,21 +1144,17 @@ static sd_rsp_type_t sd_normal_command(SDState *sd,
default:
bad_cmd:
-sd-card_status |= ILLEGAL_COMMAND;
-
fprintf(stderr, SD: Unknown CMD%i\n, req.cmd);
-return sd_r0;
+return sd_illegal;
unimplemented_cmd:
/* Commands that are recognised but not yet implemented in SPI mode.
*/
-sd-card_status |= ILLEGAL_COMMAND;
fprintf(stderr, SD: CMD%i not implemented in SPI mode\n, req.cmd);
-return sd_r0;
+return sd_illegal;
}
-sd-card_status |= ILLEGAL_COMMAND;
fprintf(stderr, SD: CMD%i in a wrong state\n, req.cmd);
-return sd_r0;
+return sd_illegal;
}
static sd_rsp_type_t sd_app_command(SDState *sd,
@@ -1321,6 +1316,10 @@ int sd_do_command(SDState *sd, SDRequest *req,
} else
rtype = sd_normal_command(sd, *req);
+if (rtype == sd_illegal) {
+sd-card_status |= ILLEGAL_COMMAND;
+}
+
sd-current_cmd = req-cmd;
switch (rtype) {
@@ -1356,14 +1355,12 @@ int sd_do_command(SDState *sd, SDRequest *req,
break;
case sd_r0:
+case sd_illegal:
default:
rsplen = 0;
break;
}
-if (sd-card_status ILLEGAL_COMMAND)
-rsplen = 0;
-
#ifdef DEBUG_SD
if (rsplen) {
int i;
--
1.7.5.4
[Qemu-devel] [PATCH 07/10] hw/sd.c: Set ILLEGAL_COMMAND for ACMDs in invalid state
App commands in an invalid state should set ILLEGAL_COMMAND, not merely return a zero response. Signed-off-by: Peter Maydell peter.mayd...@linaro.org --- hw/sd.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/hw/sd.c b/hw/sd.c index 9116f67..9eebfac 100644 --- a/hw/sd.c +++ b/hw/sd.c @@ -1262,7 +1262,7 @@ static sd_rsp_type_t sd_app_command(SDState *sd, } fprintf(stderr, SD: ACMD%i in a wrong state\n, req.cmd); -return sd_r0; +return sd_illegal; } static int cmd_valid_while_locked(SDState *sd, SDRequest *req) -- 1.7.5.4
[Qemu-devel] [PATCH 09/10] hw/sd.c: Correct handling of APP_CMD status bit
Fix some bugs in our implementation of the APP_CMD status bit:
* the response to an ACMD should have APP_CMD set, not cleared
* if an illegal ACMD is sent then the next command should be
handled as a normal command
This requires that we split card is expecting an ACMD from
the state of the APP_CMD status bit (the latter indicates
both expecting ACMD and that was an ACMD).
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
hw/sd.c | 24 +---
1 files changed, 17 insertions(+), 7 deletions(-)
diff --git a/hw/sd.c b/hw/sd.c
index e1565b6..6614cbf 100644
--- a/hw/sd.c
+++ b/hw/sd.c
@@ -92,6 +92,10 @@ struct SDState {
int spi;
int current_cmd;
+/* True if we will handle the next command as an ACMD. Note that this does
+ * *not* track the APP_CMD status bit!
+ */
+int expecting_acmd;
int blk_written;
uint64_t data_start;
uint32_t data_offset;
@@ -341,8 +345,8 @@ static int sd_req_crc_validate(SDRequest *req)
static void sd_response_r1_make(SDState *sd, uint8_t *response)
{
uint32_t status = sd-card_status;
-/* Clear the clear on read status bits (except APP_CMD) */
-sd-card_status = ~CARD_STATUS_C | APP_CMD;
+/* Clear the clear on read status bits */
+sd-card_status = ~CARD_STATUS_C;
response[0] = (status 24) 0xff;
response[1] = (status 16) 0xff;
@@ -608,6 +612,9 @@ static sd_rsp_type_t sd_normal_command(SDState *sd,
uint32_t rca = 0x;
uint64_t addr = (sd-ocr (1 30)) ? (uint64_t) req.arg 9 : req.arg;
+/* Not interpreting this as an app command */
+sd-card_status = ~APP_CMD;
+
if (sd_cmd_type[req.cmd] == sd_ac || sd_cmd_type[req.cmd] == sd_adtc)
rca = req.arg 16;
@@ -1116,6 +1123,7 @@ static sd_rsp_type_t sd_normal_command(SDState *sd,
if (sd-rca != rca)
return sd_r0;
+sd-expecting_acmd = 1;
sd-card_status |= APP_CMD;
return sd_r1;
@@ -1155,6 +1163,7 @@ static sd_rsp_type_t sd_app_command(SDState *sd,
SDRequest req)
{
DPRINTF(ACMD%d 0x%08x\n, req.cmd, req.arg);
+sd-card_status |= APP_CMD;
switch (req.cmd) {
case 6:/* ACMD6: SET_BUS_WIDTH */
switch (sd-state) {
@@ -1251,7 +1260,6 @@ static sd_rsp_type_t sd_app_command(SDState *sd,
default:
/* Fall back to standard commands. */
-sd-card_status = ~APP_CMD;
return sd_normal_command(sd, req);
}
@@ -1269,7 +1277,7 @@ static int cmd_valid_while_locked(SDState *sd, SDRequest
*req)
* ACMD41 and ACMD42
* Anything else provokes an illegal command response.
*/
-if (sd-card_status APP_CMD) {
+if (sd-expecting_acmd) {
return req-cmd == 41 || req-cmd == 42;
}
if (req-cmd == 16 || req-cmd == 55) {
@@ -1297,6 +1305,7 @@ int sd_do_command(SDState *sd, SDRequest *req,
if (sd-card_status CARD_IS_LOCKED) {
if (!cmd_valid_while_locked(sd, req)) {
sd-card_status |= ILLEGAL_COMMAND;
+sd-expecting_acmd = 0;
fprintf(stderr, SD: Card is locked\n);
rtype = sd_illegal;
goto send_response;
@@ -1306,11 +1315,12 @@ int sd_do_command(SDState *sd, SDRequest *req,
last_state = sd-state;
sd_set_mode(sd);
-if (sd-card_status APP_CMD) {
+if (sd-expecting_acmd) {
+sd-expecting_acmd = 0;
rtype = sd_app_command(sd, *req);
-sd-card_status = ~APP_CMD;
-} else
+} else {
rtype = sd_normal_command(sd, *req);
+}
if (rtype == sd_illegal) {
sd-card_status |= ILLEGAL_COMMAND;
--
1.7.5.4
[Qemu-devel] [PATCH 02/10] hw/sd.c: Add comment regarding CARD_STATUS_* defines
Add a clarifying comment about what the CARD_STATUS_[ABC] macros are defining. Signed-off-by: Peter Maydell peter.mayd...@linaro.org --- hw/sd.c |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/hw/sd.c b/hw/sd.c index a1c98c0..245b6c3 100644 --- a/hw/sd.c +++ b/hw/sd.c @@ -309,6 +309,11 @@ static void sd_set_rca(SDState *sd) sd-rca += 0x4567; } +/* Card status bits, split by clear condition: + * A : According to the card current state + * B : Always related to the previous command + * C : Cleared by read + */ #define CARD_STATUS_A 0x02004100 #define CARD_STATUS_B 0x00c01e00 #define CARD_STATUS_C 0xfd39a028 -- 1.7.5.4
[Qemu-devel] [PATCH 03/10] hw/sd.c: On CRC error, set CRC error status bit rather than clearing it
If we fail to validate the CRC for an SD command we should be setting
COM_CRC_ERROR, not clearing it. (This bug actually has no effect currently
because sd_req_crc_validate() always returns success.)
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
hw/sd.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/hw/sd.c b/hw/sd.c
index 245b6c3..e57852e 100644
--- a/hw/sd.c
+++ b/hw/sd.c
@@ -1300,7 +1300,7 @@ int sd_do_command(SDState *sd, SDRequest *req,
}
if (sd_req_crc_validate(req)) {
-sd-card_status = ~COM_CRC_ERROR;
+sd-card_status |= COM_CRC_ERROR;
return 0;
}
--
1.7.5.4
[Qemu-devel] [PATCH 00/10] hw/sd.c: Fix various status related bugs
This patchset fixes a number of bugs in our SD card emulation, mostly in the status bit handling. In particular, it fixes the issues raised in https://bugs.launchpad.net/qemu/+bug/597641 . The others are things I noticed while I was poking around in the code. Patches 01-04, 07 are pretty straightforward. 05, 06 are refactoring for the benefit of later patches. 08 and 09 are more interesting. 10 makes sense to me although the spec is rather vague on the point. Peter Maydell (10): hw/sd.c: Fix the set of commands which are failed when card is locked hw/sd.c: Add comment regarding CARD_STATUS_* defines hw/sd.c: On CRC error, set CRC error status bit rather than clearing it hw/sd.c: When setting ADDRESS_ERROR bit, don't clear everything else hw/sd.c: Handle illegal commands in sd_do_command hw/sd.c: Handle CRC and locked-card errors in normal code path hw/sd.c: Set ILLEGAL_COMMAND for ACMDs in invalid state hw/sd.c: Correct handling of type B SD status bits hw/sd.c: Correct handling of APP_CMD status bit hw/sd.c: Clear status bits when read via response r6 hw/sd.c | 131 -- 1 files changed, 84 insertions(+), 47 deletions(-) -- 1.7.5.4
[Qemu-devel] [PATCH 04/10] hw/sd.c: When setting ADDRESS_ERROR bit, don't clear everything else
Fix a typo that meant that ADDRESS_ERRORs setting or clearing write
protection would clear every other bit in the status register.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
hw/sd.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/sd.c b/hw/sd.c
index e57852e..dd28061 100644
--- a/hw/sd.c
+++ b/hw/sd.c
@@ -999,7 +999,7 @@ static sd_rsp_type_t sd_normal_command(SDState *sd,
switch (sd-state) {
case sd_transfer_state:
if (addr = sd-size) {
-sd-card_status = ADDRESS_ERROR;
+sd-card_status |= ADDRESS_ERROR;
return sd_r1b;
}
@@ -1019,7 +1019,7 @@ static sd_rsp_type_t sd_normal_command(SDState *sd,
switch (sd-state) {
case sd_transfer_state:
if (addr = sd-size) {
-sd-card_status = ADDRESS_ERROR;
+sd-card_status |= ADDRESS_ERROR;
return sd_r1b;
}
--
1.7.5.4
Re: [Qemu-devel] [PATCH v3 1/3] sh_pci: remove sysbus_init_mmio_cb2 usage
On 16 December 2011 22:37, Benoît Canet benoit.ca...@gmail.com wrote: The isa region is not exposed as a sysbus region because the iobr register contains its address and use it to remap dynamically the region. (Peter Maydell's idea) Signed-off-by: Benoît Canet benoit.ca...@gmail.com Reviewed-by: Peter Maydell peter.mayd...@linaro.org
Re: [Qemu-devel] [PATCH v3 2/3] ppce500_pci: remove sysbus_init_mmio_cb2 usage
On 16 December 2011 22:37, Benoît Canet benoit.ca...@gmail.com wrote: Expose only one container MemoryRegion to sysbus. (Peter Maydell's idea) Signed-off-by: Benoît Canet benoit.ca...@gmail.com Reviewed-by: Peter Maydell peter.mayd...@linaro.org
Re: [Qemu-devel] [PATCH v3 3/3] sysbus: remove sysbus_init_mmio_cb2
On 16 December 2011 22:37, Benoît Canet benoit.ca...@gmail.com wrote: This function is not longer in use so remove it. Signed-off-by: Benoît Canet benoit.ca...@gmail.com Nothing wrong here, but you can go further: it's now the case that for all mmio regions s-mmio[n].memory is non-NULL, so you can remove some if() conditionals in sysbus_mmio_map() and sysbus_dev_print(). -- PMM
Re: [Qemu-devel] [RFC] Device isolation infrastructure v2
On Fri, Dec 16, 2011 at 03:53:53PM +0100, Joerg Roedel wrote: On Thu, Dec 15, 2011 at 11:05:07AM -0700, Alex Williamson wrote: Starting with it in the core and hand waving some future use that we don't plan to implement right now seems like the wrong direction. I agree with Alex. First of all, I havn't seen any real vfio problem that can't be solved with the current approach, and it has the great advantage of simplicity. It doesn't require a re-implementation of the driver-core based on groups. I'm not re-implementing the driver core in terms of groups, just adding the concept of groups to the driver core. I agree that we need some improvements to Alex' code for the dma-api layer to solve the problem with broken devices using the wrong requestor-id. But that can be done incrementally with the current (current == in the iommu-tree) approach implemented by Alex. I also think that all this does not belong into the driver core for two reasons: 1) The information for building the device groups is provided by the iommu-layer Yes.. no change there. 2) The group information is provided to vfio by the iommu-api Um.. huh? Currently, the iommu-api supplies the info vfio, therefore it should? I assume there's a non-circular argument you're trying to make here, but I can't figure out what it is. This makes the iommu-layer the logical point to place the grouping code. Well.. that's not where it is in Alex's code either. The iommu layer (to the extent that there is such a layer) supplies the group info, but the group management is in vfio, not the iommu layer. With mine it is in the driver core because the struct device seemed the logical place for the group id. Moving the group management into the iommu code itself probably does make more sense, although I think that would be a change more of code location than any actual content change. There are some sources outside of the iommu-layer that may influence grouping (like pci-quirks), but most of the job is done by the iommu-drivers. Right, so, the other problem is that a well boundaried iommu-driver' is something that only exists on x86 at present, and the iommu api is riddled with x86-centric thinking. Or more accurately, design based on how the current intel and amd iommus work. On systems like POWER, use of the iommu is not optional - it's built into the PCI host bridge and must be initialized when the bridge is probed, much earlier than iommu driver initialization on x86. They have no inbuilt concept of domains (though we could fake in software in some circumstances). Now, that is something that needs to be fixed longer term. I'm just not sure how to deal with that and sorting out some sort of device isolation / passthrough system. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson
Re: [Qemu-devel] [PATCH] w32: QEMU applications with SDL are always GUI applications
On Sat, Dec 17, 2011 at 07:12, Stefan Weil s...@weilnetz.de wrote: Am 16.12.2011 04:24, schrieb TeLeMan: On Sun, Dec 4, 2011 at 05:32, Stefan Weil s...@weilnetz.de wrote: Since commit 1d14ffa97eacd3cb722271eaf6f093038396eac4 (in 2005), QEMU applications on W32 don't use the default SDL compiler flags: Instead of a GUI application, a console application is created. This has disadvantages (there is always an empty console window) and no obvious reason, so this patch removes the strange flag modification. The SDL GUI applications still can be run from a console window and even send stdout and stderr to that console by setting environment variable SDL_STDIO_REDIRECT=no. Did you test it? Windows GUI applications can not send stdout to the startup console window unless they create their own console window. I did, but obviously not good enough: in an msys rxvt console the QEMU executables work as I wrote in the commit message. So msys-rxvt and some other applications (SciTE for example) allow running GUI applications with stdio channels. The Windows command prompt (cmd.exe) is different, and so is the normal MSYS console. Here console output does not work, and I also noticed problems when running an emulation with latest QEMU (application hangs). It seems to be difficult to get a solution which works for several scenarios: * It should be possible to create a link which starts an emulation with parameters and only one window (SDL, no extra console window). This needs a GUI application (or is it possible for a console application to suppress or close the console window?). * It must be possible to see stdout and stderr output. Default today: both are written to files in the program directory. This is bad because normally users have no write access there. It also does not allow running more than one emulation with separated output. * It should be possible to get stdout and stderr directly to the console. This is needed for running with curses, and it is useful when asking for -help. * It must be possible to run QEMU executables from cmd.exe. * It should be possible to run QEMU executables from other shells (msys command line, msys rxvt, cygwin command line, ...). What would you suggest? Add a configure option and let users decide which one is better. Regards, Stefan Weil
Re: [Qemu-devel] [PATCH] virtio-serial: Allow one MSI-X vector per virtqueue
于 2011/12/16,星期五 17:39, Amit Shah 写道: On (Fri) 16 Dec 2011 [09:14:26], zanghongy...@huawei.com wrote: From: Hongyong Zangzanghongy...@huawei.com In pci_enable_msix(), the guest's virtio-serial driver tries to set msi-x with one vector per queue. But it fails and eventually all virtio-serial ports share one MSI-X vector. Because every virtio-serial port has *two* virtqueues, virtio-serial needs (port+1)*2 vectors other than (port+1). Ouch, good catch. One comment below: This patch allows every virtqueue to have its own MSI-X vector. (When the MSI-X vectors needed are more than MSIX_MAX_ENTRIES defined in qemu: msix.c, all the queues still share one MSI-X vector as before.) Signed-off-by: Hongyong Zangzanghongy...@huawei.com --- hw/virtio-pci.c |5 - 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/hw/virtio-pci.c b/hw/virtio-pci.c index 77b75bc..2c9c6fb 100644 --- a/hw/virtio-pci.c +++ b/hw/virtio-pci.c @@ -718,8 +718,11 @@ static int virtio_serial_init_pci(PCIDevice *pci_dev) return -1; } vdev-nvectors = proxy-nvectors == DEV_NVECTORS_UNSPECIFIED -? proxy-serial.max_virtserial_ports + 1 +? (proxy-serial.max_virtserial_ports + 1) * 2 : proxy-nvectors; +/*msix.c: #define MSIX_MAX_ENTRIES 32*/ +if (vdev-nvectors 32) +vdev-nvectors = 32; This change isn't needed: if the proxy-nvectors value exceeds the max allowed, virtio_init_pci() will end up using a shared vector instead of separate ones. Thanks, Amit . Hi Amit, If the nvectors exceeds the max, msix_init() will return -EINVAL in QEMU, and the front-end driver in Guest will use regular interrupt instead of MSI-X. Hongyong
[Qemu-devel] [PATCH 1/3] vl.c: Move option generation logic into a wrapper file
From: Michael Ellerman mich...@ellerman.id.au
In vl.c and qemu-options.h we define macros and include qemu-options.def
in order to generate different content. Move the bulk of the def'ing and
undef'ing into a wrapper, this will make it cleaner when we add another
macro in the next patch.
AFAICS undefining GEN_DOCS services no purpose, but I've left it for now.
Signed-off-by: Michael Ellerman mich...@ellerman.id.au
---
qemu-options-wrapper.h | 32
qemu-options.h |9 ++---
vl.c | 18 --
3 files changed, 38 insertions(+), 21 deletions(-)
create mode 100644 qemu-options-wrapper.h
diff --git a/qemu-options-wrapper.h b/qemu-options-wrapper.h
new file mode 100644
index 000..202f5af
--- /dev/null
+++ b/qemu-options-wrapper.h
@@ -0,0 +1,32 @@
+
+#if defined(QEMU_OPTIONS_GENERATE_ENUM)
+
+#define DEF(option, opt_arg, opt_enum, opt_help, arch_mask) \
+opt_enum,
+#define DEFHEADING(text)
+
+#elif defined(QEMU_OPTIONS_GENERATE_HELP)
+
+#define DEF(option, opt_arg, opt_enum, opt_help, arch_mask) \
+opt_help
+#define DEFHEADING(text) stringify(text) \n
+
+#elif defined(QEMU_OPTIONS_GENERATE_OPTIONS)
+
+#define DEF(option, opt_arg, opt_enum, opt_help, arch_mask) \
+{ option, opt_arg, opt_enum, arch_mask },
+#define DEFHEADING(text)
+
+#else
+#error qemu-options-wrapper.h included with no option defined
+#endif
+
+#include qemu-options.def
+
+#undef DEF
+#undef DEFHEADING
+#undef GEN_DOCS
+
+#undef QEMU_OPTIONS_GENERATE_ENUM
+#undef QEMU_OPTIONS_GENERATE_HELP
+#undef QEMU_OPTIONS_GENERATE_OPTIONS
diff --git a/qemu-options.h b/qemu-options.h
index c96f994..89a009e 100644
--- a/qemu-options.h
+++ b/qemu-options.h
@@ -29,13 +29,8 @@
#define _QEMU_OPTIONS_H_
enum {
-#define DEF(option, opt_arg, opt_enum, opt_help, arch_mask) \
-opt_enum,
-#define DEFHEADING(text)
-#include qemu-options.def
-#undef DEF
-#undef DEFHEADING
-#undef GEN_DOCS
+#define QEMU_OPTIONS_GENERATE_ENUM
+#include qemu-options-wrapper.h
};
#endif
diff --git a/vl.c b/vl.c
index d51ac2e..25ec37b 100644
--- a/vl.c
+++ b/vl.c
@@ -1493,13 +1493,8 @@ static void version(void)
static void help(int exitcode)
{
const char *options_help =
-#define DEF(option, opt_arg, opt_enum, opt_help, arch_mask) \
-opt_help
-#define DEFHEADING(text) stringify(text) \n
-#include qemu-options.def
-#undef DEF
-#undef DEFHEADING
-#undef GEN_DOCS
+#define QEMU_OPTIONS_GENERATE_HELP
+#include qemu-options-wrapper.h
;
version();
printf(usage: %s [options] [disk_image]\n
@@ -1529,13 +1524,8 @@ typedef struct QEMUOption {
static const QEMUOption qemu_options[] = {
{ h, 0, QEMU_OPTION_h, QEMU_ARCH_ALL },
-#define DEF(option, opt_arg, opt_enum, opt_help, arch_mask) \
-{ option, opt_arg, opt_enum, arch_mask },
-#define DEFHEADING(text)
-#include qemu-options.def
-#undef DEF
-#undef DEFHEADING
-#undef GEN_DOCS
+#define QEMU_OPTIONS_GENERATE_OPTIONS
+#include qemu-options-wrapper.h
{ NULL },
};
static void select_vgahw (const char *p)
--
1.7.7.3
[Qemu-devel] [PATCH 2/3] vl.c: In qemu -h output, only print options for the arch we are running as
From: Michael Ellerman mich...@ellerman.id.au
Only print options in the help output that are accepted by our arch.
This is less confusing for users and also for other programs that
consume the help output.
The options affected are:
-g and -prom-env only displayed on PPC or SPARC
-win2k-hack, -rtc-td-hack, -no-fd-bootchk, -no-acpi, -no-hpet,
-acpitable, -smbios only displayed on i386
-semihosting only displayed on ARM, M68K or XTENSA
-old-param only displayed on ARM
Signed-off-by: Michael Ellerman mich...@ellerman.id.au
---
qemu-options-wrapper.h | 15 ---
qemu-options.hx|4 ++--
scripts/hxtool |3 +++
vl.c | 21 +
4 files changed, 26 insertions(+), 17 deletions(-)
diff --git a/qemu-options-wrapper.h b/qemu-options-wrapper.h
index 202f5af..13bfea0 100644
--- a/qemu-options-wrapper.h
+++ b/qemu-options-wrapper.h
@@ -4,18 +4,26 @@
#define DEF(option, opt_arg, opt_enum, opt_help, arch_mask) \
opt_enum,
#define DEFHEADING(text)
+#define ARCHHEADING(text, arch_mask)
#elif defined(QEMU_OPTIONS_GENERATE_HELP)
-#define DEF(option, opt_arg, opt_enum, opt_help, arch_mask) \
-opt_help
-#define DEFHEADING(text) stringify(text) \n
+#define DEF(option, opt_arg, opt_enum, opt_help, arch_mask)\
+if ((arch_mask) arch_type) \
+fputs(opt_help, stdout);
+
+#define ARCHHEADING(text, arch_mask) \
+if ((arch_mask) arch_type)\
+puts(stringify(text));
+
+#define DEFHEADING(text) ARCHHEADING(text, QEMU_ARCH_ALL)
#elif defined(QEMU_OPTIONS_GENERATE_OPTIONS)
#define DEF(option, opt_arg, opt_enum, opt_help, arch_mask) \
{ option, opt_arg, opt_enum, arch_mask },
#define DEFHEADING(text)
+#define ARCHHEADING(text, arch_mask)
#else
#error qemu-options-wrapper.h included with no option defined
@@ -25,6 +33,7 @@
#undef DEF
#undef DEFHEADING
+#undef ARCHHEADING
#undef GEN_DOCS
#undef QEMU_OPTIONS_GENERATE_ENUM
diff --git a/qemu-options.hx b/qemu-options.hx
index 087a3b9..749aee1 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -1070,9 +1070,9 @@ STEXI
@end table
ETEXI
-DEFHEADING()
+ARCHHEADING(, QEMU_ARCH_I386)
-DEFHEADING(i386 target only:)
+ARCHHEADING(i386 target only:, QEMU_ARCH_I386)
STEXI
@table @option
ETEXI
diff --git a/scripts/hxtool b/scripts/hxtool
index 7ca83ed..995bb7f 100644
--- a/scripts/hxtool
+++ b/scripts/hxtool
@@ -47,6 +47,9 @@ hxtotexi()
DEFHEADING*)
echo $(expr $str : DEFHEADING(\(.*\)))
;;
+ARCHHEADING*)
+echo $(expr $str : ARCHHEADING(\(.*\),.*))
+;;
*)
test $flag -eq 1 echo $str
;;
diff --git a/vl.c b/vl.c
index 25ec37b..da69f94 100644
--- a/vl.c
+++ b/vl.c
@@ -1492,24 +1492,21 @@ static void version(void)
static void help(int exitcode)
{
-const char *options_help =
+version();
+printf(usage: %s [options] [disk_image]\n\n
+ 'disk_image' is a raw hard disk image for IDE hard disk 0\n\n,
+error_get_progname());
+
#define QEMU_OPTIONS_GENERATE_HELP
#include qemu-options-wrapper.h
-;
-version();
-printf(usage: %s [options] [disk_image]\n
- \n
- 'disk_image' is a raw hard disk image for IDE hard disk 0\n
- \n
- %s\n
- During emulation, the following keys are useful:\n
+
+printf(\nDuring emulation, the following keys are useful:\n
ctrl-alt-f toggle full screen\n
ctrl-alt-n switch to virtual console 'n'\n
ctrl-alttoggle mouse and keyboard grab\n
\n
- When using -nographic, press 'ctrl-a h' to get some help.\n,
- error_get_progname(),
- options_help);
+ When using -nographic, press 'ctrl-a h' to get some help.\n);
+
exit(exitcode);
}
--
1.7.7.3
[Qemu-devel] [PATCH 3/3] Documentation: Move balloon option out of i386 only section
From: Michael Ellerman mich...@ellerman.id.au
The balloon option is not i386 only, so move it into the standard
options section.
Signed-off-by: Michael Ellerman mich...@ellerman.id.au
---
qemu-options.hx | 26 +-
1 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/qemu-options.hx b/qemu-options.hx
index 749aee1..a60191f 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -456,6 +456,19 @@ modprobe i810_audio clocking=48000
@end example
ETEXI
+DEF(balloon, HAS_ARG, QEMU_OPTION_balloon,
+-balloon none disable balloon device\n
+-balloon virtio[,addr=str]\n
+enable virtio balloon device (default)\n, QEMU_ARCH_ALL)
+STEXI
+@item -balloon none
+@findex -balloon
+Disable balloon device.
+@item -balloon virtio[,addr=@var{addr}]
+Enable virtio balloon device (default), optionally with PCI address
+@var{addr}.
+ETEXI
+
STEXI
@end table
ETEXI
@@ -1120,19 +1133,6 @@ STEXI
Disable HPET support.
ETEXI
-DEF(balloon, HAS_ARG, QEMU_OPTION_balloon,
--balloon none disable balloon device\n
--balloon virtio[,addr=str]\n
-enable virtio balloon device (default)\n, QEMU_ARCH_ALL)
-STEXI
-@item -balloon none
-@findex -balloon
-Disable balloon device.
-@item -balloon virtio[,addr=@var{addr}]
-Enable virtio balloon device (default), optionally with PCI address
-@var{addr}.
-ETEXI
-
DEF(acpitable, HAS_ARG, QEMU_OPTION_acpitable,
-acpitable
[sig=str][,rev=n][,oem_id=str][,oem_table_id=str][,oem_rev=n][,asl_compiler_id=str][,asl_compiler_rev=n][,{data|file}=file1[:file2]...]\n
ACPI table description\n, QEMU_ARCH_I386)
--
1.7.7.3
Re: [Qemu-devel] [PATCH 1/3] vl.c: Move option generation logic into a wrapper file
On Mon, 2011-12-19 at 17:19 +1100, y...@ozlabs.org wrote: From: Michael Ellerman mich...@ellerman.id.au These are from me obviously. Thankyou POS git-send-email. cheers signature.asc Description: This is a digitally signed message part
Re: [Qemu-devel] [PATCH] virtio-serial: Allow one MSI-X vector per virtqueue
On (Mon) 19 Dec 2011 [14:09:43], Zang Hongyong wrote: 于 2011/12/16,星期五 17:39, Amit Shah 写道: On (Fri) 16 Dec 2011 [09:14:26], zanghongy...@huawei.com wrote: From: Hongyong Zangzanghongy...@huawei.com In pci_enable_msix(), the guest's virtio-serial driver tries to set msi-x with one vector per queue. But it fails and eventually all virtio-serial ports share one MSI-X vector. Because every virtio-serial port has *two* virtqueues, virtio-serial needs (port+1)*2 vectors other than (port+1). Ouch, good catch. One comment below: This patch allows every virtqueue to have its own MSI-X vector. (When the MSI-X vectors needed are more than MSIX_MAX_ENTRIES defined in qemu: msix.c, all the queues still share one MSI-X vector as before.) Signed-off-by: Hongyong Zangzanghongy...@huawei.com --- hw/virtio-pci.c |5 - 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/hw/virtio-pci.c b/hw/virtio-pci.c index 77b75bc..2c9c6fb 100644 --- a/hw/virtio-pci.c +++ b/hw/virtio-pci.c @@ -718,8 +718,11 @@ static int virtio_serial_init_pci(PCIDevice *pci_dev) return -1; } vdev-nvectors = proxy-nvectors == DEV_NVECTORS_UNSPECIFIED -? proxy-serial.max_virtserial_ports + 1 +? (proxy-serial.max_virtserial_ports + 1) * 2 : proxy-nvectors; +/*msix.c: #define MSIX_MAX_ENTRIES 32*/ +if (vdev-nvectors 32) +vdev-nvectors = 32; This change isn't needed: if the proxy-nvectors value exceeds the max allowed, virtio_init_pci() will end up using a shared vector instead of separate ones. Hi Amit, If the nvectors exceeds the max, msix_init() will return -EINVAL in QEMU, and the front-end driver in Guest will use regular interrupt instead of MSI-X. In that case, I believe msix_init() should be changed to attempt to share interrupts instead of drivers doing this by themselves. Amit
