[Qemu-devel] Haster / Detaljer
- This mail is in HTML. Some elements may be ommited in plain text. - Jeg jobbet med SNS Bank i Holland.I am kontakte deg på grunn av din avdøde slektning konto i vår bank. Vennligst sender meg en epost med et telefonnummer og også indikerer den beste tiden at jeg kan ringe deg på telefonen. Dette vil gjøre meg å gi deg mer informasjon om denne saken. Vær oppmerksom på at jeg er for tiden i Storbritannia på momenty gjennomgår noen Finacial kurs. hilsen Frank Mills www.snsbank.nl 447741782385
[Qemu-devel] [PATCH] kvm-ppc: halt secondary cpus when guest reset
When guest reset, we need to halt secondary cpus until guest kick them.
This already works for tcg. The patch add the support for kvm.
For kvm, if use in-kernel mpic, it should not be halted.
In this case, we pause the sencondaries instead.
This has impact to handling of halt exit,
but fortunately, kvmppc doesn't use halt exit.
Signed-off-by: Liu Yu yu@freescale.com
---
hw/ppce500_spin.c |1 +
target-ppc/kvm.c | 11 ++-
2 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/hw/ppce500_spin.c b/hw/ppce500_spin.c
index cccd940..2b52728 100644
--- a/hw/ppce500_spin.c
+++ b/hw/ppce500_spin.c
@@ -112,6 +112,7 @@ static void spin_kick(void *data)
env-halted = 0;
env-exception_index = -1;
+env-stopped = 0;
qemu_cpu_kick(env);
}
diff --git a/target-ppc/kvm.c b/target-ppc/kvm.c
index 429349f..ff4cfdb 100644
--- a/target-ppc/kvm.c
+++ b/target-ppc/kvm.c
@@ -504,7 +504,16 @@ void kvm_arch_post_run(CPUState *env, struct kvm_run *run)
int kvm_arch_process_async_events(CPUState *env)
{
-return 0;
+if (kvm_irqchip_in_kernel()) {
+if (env-halted == 1 env-exception_index == EXCP_HLT) {
+env-stopped = 1;
+return 1;
+} else {
+return 0;
+}
+}
+
+return env-halted;
}
static int kvmppc_handle_halt(CPUState *env)
--
1.6.4
[Qemu-devel] RFC: Design Doc for a new trace format (to support variable number/size of args per event) simpletrace-v2
Currently, Qemu provides an in-built simple trace backend which is
simple and easy to use (no additional/external dependencies) and allows
developers to trace events in Qemu code, however, it suffers from
limitations like unability to trace more than 6 elements per trace
event, lack of string support, etc. There are various places in Qemu
code, where one would want to trace events having multiple arguments
including strings. This results into motivation for defining an
advanced, yet simple trace format which will address these limitations.
For the sake of convinence, let us call this new trace format as
simpletrace v2 (any other better name?).
HLD for Simpletrace v2:
==
This new trace format defines 3 types of structures for trace data
organization:
1) Trace Log Header (per log file, provides meta-data about the entire
trace log, like trace format version, endianness, etc.)
2) Trace Event Header (per trace event, provides meta-data per trace event)
3) Trace Data (per argument/data in a trace event, provides size of data
followed by data itself)
The Trace Log header can be defined like this:
typedef struct {
uint64_t endian_magic; /* =0xAA0011FF, a magic number helps
identifying validity and endian-ness of trace log to its readers */
uint64_t pid; /* pid of qemu process can be traced here */
uint64_t version; /* Keeping version info as 3rd 64-bit element as
expected by current simpletrace format */
unit64_t timestamp; /* timestamp info */
} TraceLogHeader;
Suggestions are invited to make this header more informative as required.
Further, this TraceLogHeader will be followed by 0 or more Trace Event
Headers (further followed by trace data) as defined below:
typedef struct {
uint64_t magic; /* =0xA1B2C3D4, ensures a valid trace record,
otherwise corrupted */
unit64_t id;/* unique identifer per trace event */
uint64_t timestamp; /* timestamp info */
uint64_t num_args; /* number of arguments (followed by this
TraceEventHeader) traced in this trace event */
} TraceEventHeader;
Trace Data is expected to be stored in following format followed by
TraceEventHeader:
typedef struct {
uint64_t size; /* size of data in bytes to be read following this
header */
uint8_t data[0] /* variable sized data */
} TraceData;
So, a typical trace log would look like this:
|TraceLogHeader|TraceEventHeader1|TraceData11|TraceData12|TraceEventHeader2|TraceData21|
...
...
...
... |TraceEventHeader-n|TraceData-n1|TraceData-n2|... TraceData-nm|
Programatically,
typedef struct TraceEvent {
TraceEventHeader eheader;
TraceData edata[0];
};
typedef struct TraceLog {
TraceLogHeader lheader;
TraceEvent levents[0];
};
I am planning to implement this new trace format soon and therefore
would like to have suggestions/feedback at an early date if possible.
regards,
Harsh
Re: [Qemu-devel] [PATCH v2] Support for UDP unicast network backend
On 11/28/11 20:39, Stefan Hajnoczi wrote:
On Fri, Nov 25, 2011 at 12:49 PM, Benjaminmlspira...@gmail.com wrote:
+fd = qemu_socket(PF_INET, SOCK_DGRAM, 0);
+if (fd 0) {
+perror(socket(PF_INET, SOCK_DGRAM));
+return -1;
+}
+val = 1;
+ret = setsockopt(fd, SOL_SOCKET, SO_REUSEADDR,
+ (const char *)val, sizeof(val));
+if (ret 0) {
+perror(setsockopt(SOL_SOCKET, SO_REUSEADDR));
Please avoid leaking the file descriptor on error:
closesocket(fd);
Since existing code also does this it may be more appropriate to send
a follow-up patch that cleans up all of net/socket.c.
Reviewed-by: Stefan Hajnoczistefa...@linux.vnet.ibm.com
Stefan
I can do that. However is it really a leak considering the fact that
the program will call exit just after?
If it's a matter of consistency and coding style I would understand
though.
One more thing, git-format-patch added a From field to the header and
caused this glitch in the mail. I thought git-send-mail or the mail
server would handle it well but apparently not:
From 2f5b85fcadcfee3b75a6a21dc86d10b945c99f0f Mon Sep 17 00:00:00 2001
From: Benjamin MARSILI marsi...@epitech.eu
git-am didn't complain with the patch that I sent but it may break after
gmail relayed it
(http://lists.gnu.org/archive/html/qemu-devel/2011-11/msg03152.html).
The second from header is interpreted as text... Should I remove the
first From field before sending the patch?
Sorry for the noise on the ML and thanks to all those who helped me get
involved.
Benjamin
Re: [Qemu-devel] [PATCH v8 1.0] configure: build position independent executables on x86-Linux hosts
On 20/11/11 12:34 PM, Blue Swirl wrote: On Sun, Nov 20, 2011 at 09:11, Avi Kivitya...@redhat.com wrote: On 11/15/2011 08:12 PM, Avi Kivity wrote: Change the default on x86 Linux hosts to building PIE (position independent executables); instead of restricting the option to user-only targets, apply it to all targets. In addition, set the relocation sections to read-only (relro) when available; this reduces the attack surface by disallowing changes to relocation tables at runtime. While PIE reduces performance and relro increases load time, it greatly improves security, with the potential to reduce a code execution vulnerability to a self denial of service. Non-x86 are not changed, as they require TCG changes; neither are non-Linux, due to lack of test coverage. Ping. I tested the patch on OpenBSD 5.0/Sparc64 with --enable-pie, but the resulting executables crash immediately. Maybe the PIE binaries are not supported by the Sparc64 kernel or ld.so, some PIE support was added in 4.4. OpenBSD has had PIE support as of 4.5. sparc64 has PIE support as does alpha/amd64/i386/powerpc/mips64/mips64el/sh. sparc was updated from gcc2 to 4 recently so maybe it'll get PIE support and arm/hppa suffer due to binutils bugs that need to be resolved by a binutils update. We build a handful of projects in our ports tree with PIE support either because they automatically do so or we've enabled them to do so and build with PIE support on all of the archs listed. It looks like the support for PIE executables was only added to GDB 7.1. For example Debian stable: OpenBSD has some level of PIE support in its GDB 6.3. CVSROOT:/cvs Module name:src Changes by: k...@cvs.openbsd.org2008/11/11 15:57:48 Modified files: gnu/usr.bin/binutils/gdb: Makefile.in breakpoint.c breakpoint.h infrun.c objfiles.c solib-svr4.c solib.c solist.h symfile-mem.c symfile.c varobj.c varobj.h Log message: Enable support for debugging pie programs. Code from Elena Zannoni's ezannoni at redhat dot com pie branch in gdb cvs, less extraneous parts and with some bug fixes. Debugging w/core files for pie programs isn't working yet since AUXV data isn't included in our core files at the moment. feedback and ok kettenis@ Perhaps developers or users inclined to debug can be assumed to have a recent GDB. Though on OpenBSD, GDB is pretty old 6.3. There is also newer gdb (7.2) in OpenBSD ports under devel/gdb and gdb package and installs as egdb, although only available for non x86 archs with -current due to a silly misfeature in the port Makefile. Another issue is that this creates a point for bisection where crossing it, all objects must be thrown away. We have a few other such points already due to generated file name clashes so this has not been a blocking issue. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: [Qemu-devel] [PATCH 4/9] virtio-9p: remove PCI dependencies from hw/9pfs/
On 11/28/2011 07:46 PM, Michael S. Tsirkin wrote:
+#ifdef CONFIG_LINUX
+static int virtio_9p_init_pci(PCIDevice *pci_dev)
+{
+VirtIOPCIProxy *proxy = DO_UPCAST(VirtIOPCIProxy, pci_dev, pci_dev);
+VirtIODevice *vdev;
+
+vdev = virtio_9p_init(pci_dev-qdev,proxy-fsconf);
+vdev-nvectors = proxy-nvectors;
+virtio_init_pci(proxy, vdev);
+/* make the actual value visible */
+proxy-nvectors = vdev-nvectors;
+return 0;
+}
+#endif
+
This ifdef looks wrong to me - is there no way 9p can thinkably
work on non-linux hosts? If yes, we should have a separate config
entry for 9p, configure script can make it
conditional on linux host.
I think it was true in the beginning, but more recent versions should
only depend on CONFIG_POSIX. I will set up FreeBSD and come back.
Paolo
Re: [Qemu-devel] [PATCH 1.0] 9pfs: improve portability to older systems
On 11/28/2011 11:36 PM, Anthony Liguori wrote: Hrm, I may have messed this up. My mailbox processing script seems to have found Aneesh's patch instead of Paolo's. Can ya'll take a look at 2507718baf311ea78156c6777d38410a9f89ce89 and tell me if I need to revert it? No, qemu.git master is fine. Erik, if you can test on your Debian 4.0 installation, that would be nice. Thanks! Paolo
[Qemu-devel] [PATCH 1/2 v2] fix typo: delete redundant semicolon
From: Dong Xu Wang wdon...@linux.vnet.ibm.com
Double semicolons should be single.
Signed-off-by: Dong Xu Wang wdon...@linux.vnet.ibm.com
---
block/nbd.c|4 ++--
cpus.c |2 +-
hw/9pfs/codir.c|6 +++---
hw/9pfs/virtio-9p-handle.c |2 +-
hw/9pfs/virtio-9p.c|4 ++--
hw/acpi.c |2 +-
hw/eepro100.c |2 +-
hw/ide/via.c |2 +-
hw/ppc.c |2 +-
hw/smc91c111.c |2 +-
linux-user/syscall.c |2 +-
net/tap-solaris.c |2 +-
target-s390x/op_helper.c |4 ++--
ui/vnc.c |2 +-
usb-redir.c|4 ++--
15 files changed, 21 insertions(+), 21 deletions(-)
diff --git a/block/nbd.c b/block/nbd.c
index 882b2dc..95212da 100644
--- a/block/nbd.c
+++ b/block/nbd.c
@@ -189,7 +189,7 @@ static int nbd_read(BlockDriverState *bs, int64_t
sector_num,
request.type = NBD_CMD_READ;
request.handle = (uint64_t)(intptr_t)bs;
-request.from = sector_num * 512;;
+request.from = sector_num * 512;
request.len = nb_sectors * 512;
if (nbd_send_request(s-sock, request) == -1)
@@ -219,7 +219,7 @@ static int nbd_write(BlockDriverState *bs, int64_t
sector_num,
request.type = NBD_CMD_WRITE;
request.handle = (uint64_t)(intptr_t)bs;
-request.from = sector_num * 512;;
+request.from = sector_num * 512;
request.len = nb_sectors * 512;
if (nbd_send_request(s-sock, request) == -1)
diff --git a/cpus.c b/cpus.c
index 82530c4..a47783b 100644
--- a/cpus.c
+++ b/cpus.c
@@ -89,7 +89,7 @@ TimersState timers_state;
int64_t cpu_get_icount(void)
{
int64_t icount;
-CPUState *env = cpu_single_env;;
+CPUState *env = cpu_single_env;
icount = qemu_icount;
if (env) {
diff --git a/hw/9pfs/codir.c b/hw/9pfs/codir.c
index 9b6d47d..3d18828 100644
--- a/hw/9pfs/codir.c
+++ b/hw/9pfs/codir.c
@@ -90,7 +90,7 @@ int v9fs_co_mkdir(V9fsPDU *pdu, V9fsFidState *fidp,
V9fsString *name,
V9fsState *s = pdu-s;
if (v9fs_request_cancelled(pdu)) {
-return -EINTR;;
+return -EINTR;
}
cred_init(cred);
cred.fc_mode = mode;
@@ -124,7 +124,7 @@ int v9fs_co_opendir(V9fsPDU *pdu, V9fsFidState *fidp)
V9fsState *s = pdu-s;
if (v9fs_request_cancelled(pdu)) {
-return -EINTR;;
+return -EINTR;
}
v9fs_path_read_lock(s);
v9fs_co_run_in_worker(
@@ -152,7 +152,7 @@ int v9fs_co_closedir(V9fsPDU *pdu, V9fsFidOpenState *fs)
V9fsState *s = pdu-s;
if (v9fs_request_cancelled(pdu)) {
-return -EINTR;;
+return -EINTR;
}
v9fs_co_run_in_worker(
{
diff --git a/hw/9pfs/virtio-9p-handle.c b/hw/9pfs/virtio-9p-handle.c
index 7644ae5..f443da6 100644
--- a/hw/9pfs/virtio-9p-handle.c
+++ b/hw/9pfs/virtio-9p-handle.c
@@ -92,7 +92,7 @@ static inline int open_by_handle(int mountfd, const char *fh,
int flags)
static int handle_update_file_cred(int dirfd, const char *name, FsCred *credp)
{
int fd, ret;
-fd = openat(dirfd, name, O_NONBLOCK | O_NOFOLLOW);;
+fd = openat(dirfd, name, O_NONBLOCK | O_NOFOLLOW);
if (fd 0) {
return fd;
}
diff --git a/hw/9pfs/virtio-9p.c b/hw/9pfs/virtio-9p.c
index 1b2fc5d..150f9a2 100644
--- a/hw/9pfs/virtio-9p.c
+++ b/hw/9pfs/virtio-9p.c
@@ -1447,7 +1447,7 @@ static void v9fs_walk(void *opaque)
int32_t fid, newfid;
V9fsString *wnames = NULL;
V9fsFidState *fidp;
-V9fsFidState *newfidp = NULL;;
+V9fsFidState *newfidp = NULL;
V9fsPDU *pdu = opaque;
V9fsState *s = pdu-s;
@@ -2353,7 +2353,7 @@ static void v9fs_link(void *opaque)
V9fsState *s = pdu-s;
int32_t dfid, oldfid;
V9fsFidState *dfidp, *oldfidp;
-V9fsString name;;
+V9fsString name;
size_t offset = 7;
int err = 0;
diff --git a/hw/acpi.c b/hw/acpi.c
index 1cf35e1..9c35f2d 100644
--- a/hw/acpi.c
+++ b/hw/acpi.c
@@ -304,7 +304,7 @@ void acpi_pm_tmr_calc_overflow_time(ACPIPMTimer *tmr)
uint32_t acpi_pm_tmr_get(ACPIPMTimer *tmr)
{
-uint32_t d = acpi_pm_tmr_get_clock();;
+uint32_t d = acpi_pm_tmr_get_clock();
return d 0xff;
}
diff --git a/hw/eepro100.c b/hw/eepro100.c
index 7d59e71..5eacb9a 100644
--- a/hw/eepro100.c
+++ b/hw/eepro100.c
@@ -258,7 +258,7 @@ typedef struct {
/* Data in mem is always in the byte order of the controller (le).
* It must be dword aligned to allow direct access to 32 bit values. */
-uint8_t mem[PCI_MEM_SIZE] __attribute__((aligned(8)));;
+uint8_t mem[PCI_MEM_SIZE] __attribute__((aligned(8)));
/* Configuration bytes. */
uint8_t configuration[22];
diff --git a/hw/ide/via.c b/hw/ide/via.c
index 098f150..a57134c 100644
--- a/hw/ide/via.c
+++ b/hw/ide/via.c
@@ -172,7 +172,7 @@ static void vt82c686b_init_ports(PCIIDEState *d) {
/* via ide func */
static int vt82c686b_ide_initfn(PCIDevice *dev)
{
-PCIIDEState *d =
[Qemu-devel] [PATCH 2/2 v2] fix spelling in hw sub directory
From: Dong Xu Wang wdon...@linux.vnet.ibm.com
Correct obvious spelling errors in qemu/hw direcotry.
Signed-off-by: Dong Xu Wang wdon...@linux.vnet.ibm.com
---
hw/9pfs/virtio-9p-coth.h |2 +-
hw/9pfs/virtio-9p-handle.c |2 +-
hw/alpha_dp264.c |2 +-
hw/arm_gic.c |2 +-
hw/bt-hci-csr.c|2 +-
hw/cirrus_vga.c|2 +-
hw/e1000_hw.h |2 +-
hw/etraxfs_dma.c |2 +-
hw/etraxfs_pic.c |2 +-
hw/fmopl.c |8
hw/gusemu.h|2 +-
hw/gusemu_hal.c|4 ++--
hw/ide/core.c |2 +-
hw/lan9118.c |4 ++--
hw/omap2.c |6 +++---
hw/pc.c|2 +-
hw/pcie_aer.c |2 +-
hw/pl110.c |2 +-
hw/pl181.c |4 ++--
hw/sh7750_regs.h |2 +-
hw/spapr.h |2 +-
hw/wdt_ib700.c |2 +-
22 files changed, 30 insertions(+), 30 deletions(-)
diff --git a/hw/9pfs/virtio-9p-coth.h b/hw/9pfs/virtio-9p-coth.h
index c4b74b0..c31c965 100644
--- a/hw/9pfs/virtio-9p-coth.h
+++ b/hw/9pfs/virtio-9p-coth.h
@@ -44,7 +44,7 @@ typedef struct V9fsThPool {
qemu_coroutine_self()); \
qemu_bh_schedule(co_bh);\
/* \
- * yeild in qemu thread and re-enter back \
+ * yield in qemu thread and re-enter back \
* in glib worker thread\
*/ \
qemu_coroutine_yield(); \
diff --git a/hw/9pfs/virtio-9p-handle.c b/hw/9pfs/virtio-9p-handle.c
index f443da6..6683754 100644
--- a/hw/9pfs/virtio-9p-handle.c
+++ b/hw/9pfs/virtio-9p-handle.c
@@ -537,7 +537,7 @@ static int handle_name_to_path(FsContext *ctx, V9fsPath
*dir_path,
}
fh = g_malloc(sizeof(struct file_handle) + data-handle_bytes);
fh-handle_bytes = data-handle_bytes;
-/* add a ./ at the begining of the path */
+/* add a ./ at the beginning of the path */
snprintf(buffer, PATH_MAX, ./%s, name);
/* flag = 0 imply don't follow symlink */
ret = name_to_handle(dirfd, buffer, fh, mnt_id, 0);
diff --git a/hw/alpha_dp264.c b/hw/alpha_dp264.c
index fcc20e9..598b830 100644
--- a/hw/alpha_dp264.c
+++ b/hw/alpha_dp264.c
@@ -2,7 +2,7 @@
* QEMU Alpha DP264/CLIPPER hardware system emulator.
*
* Choose CLIPPER IRQ mappings over, say, DP264, MONET, or WEBBRICK
- * variants because CLIPPER doesn't have an SMC669 SuperIO controler
+ * variants because CLIPPER doesn't have an SMC669 SuperIO controller
* that we need to emulate as well.
*/
diff --git a/hw/arm_gic.c b/hw/arm_gic.c
index f3f3516..bbbaf92 100644
--- a/hw/arm_gic.c
+++ b/hw/arm_gic.c
@@ -593,7 +593,7 @@ static uint32_t gic_cpu_read(gic_state *s, int cpu, int
offset)
return 0;
case 0x0c: /* Acknowledge */
return gic_acknowledge_irq(s, cpu);
-case 0x14: /* Runing Priority */
+case 0x14: /* Running Priority */
return s-running_priority[cpu];
case 0x18: /* Highest Pending Interrupt */
return s-current_pending[cpu];
diff --git a/hw/bt-hci-csr.c b/hw/bt-hci-csr.c
index 0dcf897..772b677 100644
--- a/hw/bt-hci-csr.c
+++ b/hw/bt-hci-csr.c
@@ -222,7 +222,7 @@ static void csrhci_in_packet(struct csrhci_s *s, uint8_t
*pkt)
rpkt = csrhci_out_packet_csr(s, H4_NEG_PKT, 10);
-*rpkt ++ = 0x20; /* Operational settings negotation Ok */
+*rpkt ++ = 0x20; /* Operational settings negotiation Ok */
memcpy(rpkt, pkt, 7); rpkt += 7;
*rpkt ++ = 0xff;
*rpkt = 0xff;
diff --git a/hw/cirrus_vga.c b/hw/cirrus_vga.c
index c7e365b..1b216e8 100644
--- a/hw/cirrus_vga.c
+++ b/hw/cirrus_vga.c
@@ -783,7 +783,7 @@ static void cirrus_bitblt_cputovideo_next(CirrusVGAState *
s)
s-cirrus_srccounter -= s-cirrus_blt_srcpitch;
if (s-cirrus_srccounter = 0)
goto the_end;
-/* more bytes than needed can be transfered because of
+/* more bytes than needed can be transferred because of
word alignment, so we keep them for the next line */
/* XXX: keep alignment to speed up transfer */
end_ptr = s-cirrus_bltbuf + s-cirrus_blt_srcpitch;
diff --git a/hw/e1000_hw.h b/hw/e1000_hw.h
index 2e341ac..9e29af8 100644
--- a/hw/e1000_hw.h
+++ b/hw/e1000_hw.h
@@ -295,7 +295,7 @@
#define E1000_KUMCTRLSTA 0x00034 /* MAC-PHY interface - RW */
#define E1000_MDPHYA 0x0003C /* PHY address - RW */
-#define E1000_MANC2H 0x05860 /* Managment Control To Host - RW */
+#define E1000_MANC2H
Re: [Qemu-devel] Status of the SH4 / ARM7 emulators
On Nov 24, 2011, at 11:44 AM, Andreas Färber wrote: Am 23.11.2011 22:59, schrieb Richard Henderson: On 11/20/2011 12:51 PM, Andreas Färber wrote: * Part of the problem is that common CPUState fields are not at the start of the struct. I have therefore been playing with a CPU_COMMON_PREFIX at the start of the struct and using a macro for clearing on reset, which preserves part of the common prefix fields. Most of the RISC hosts have a limited displacement in their load and store instructions. E.g. 14 bits for Sparc, 12 bits for ARM, 10. We want to be able to load and store the target cpu registers very efficiently. If you move all the common fields to the beginning, that will include the (rather large) TLB tables, and overflow those small offsets. This change would almost certainly be a Large Mistake. Then what is your suggestion? Point to the middle ? IE, positive offsets for the common structure, negative offsets for the architecture defined ones. Today, common code is accessing env- struct members directly for icount, TLB, etc. If they're at the end of the struct, offsets vary and we can't cast to a common-subset struct. Anthony's qom-upstream.4 branch doesn't seem to touch CPUState yet. Having an empty C++ base class with virtual, non-implemented accessor methods that are implemented for each arch is the only solution I can think of other than proxy functions with large switches based on a common (=prefixed) type field. Andreas
Re: [Qemu-devel] [PATCH] ccid: Fix buffer overrun in handling of VSC_ATR message
On Mon, Nov 28, 2011 at 08:27:37PM +0100, Markus Armbruster wrote: ATR size exceeding the limit is diagnosed, but then we merrily use it anyway, overrunning card-atr[]. The message is read from a character device. Obvious security implications unless the other end of the character device is trusted. Spotted by Coverity. CVE-2011-4111. Anthony, do you want me to do a pull request for this or can you merge it as is? Alon Signed-off-by: Markus Armbruster arm...@redhat.com --- hw/ccid-card-passthru.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/hw/ccid-card-passthru.c b/hw/ccid-card-passthru.c index 2cbc81b..9f51c6c 100644 --- a/hw/ccid-card-passthru.c +++ b/hw/ccid-card-passthru.c @@ -150,6 +150,7 @@ static void ccid_card_vscard_handle_message(PassthruState *card, error_report(ATR size exceeds spec, ignoring); ccid_card_vscard_send_error(card, scr_msg_header-reader_id, VSC_GENERAL_ERROR); +break; } memcpy(card-atr, data, scr_msg_header-length); card-atr_length = scr_msg_header-length; -- 1.7.6.4
Re: [Qemu-devel] [PATCH v8 0/2] PC system flash support
On 11/29/2011 09:03 AM, Jordan Justen wrote: On Mon, Nov 28, 2011 at 02:28, Avi Kivity a...@redhat.com wrote: On 11/28/2011 04:26 AM, Jordan Justen wrote: Enable flash emulation in a PC system using pflash_cfi01. The new memory layout should be made conditional on the machine type (-M pc-1.1 or later) to allow migration from/to pc-1.0 and earlier. Memory layout in this context are the names of memory ranges given to memory_region_init_ram(), sizes, and locations. Also, the flash interface should not be there for older machines. Is this the right way to go about it? 1. Create a new pc-sysfw qdev 2. Use a flash property in pc_piix.c to selectively enable the flash Or, is there an easier or better way to say pc pc-1.0? No idea, copying some qdev people. How do I enable migration from/to pc-1.0 and earlier? It seems like some code will need to shuttle the data (rom = pflash). Can you point me an an example? It should be completely transparent, so long as you instantiate a ROM for = pc-1.0 (say based on a property) and flash for = pc-1.1. One way to verify is to to 'info qdev' and 'info mtree' with qemu-1.0 and qemu-1.1 -M pc-1.0, and see that you get the same results. -- error compiling committee.c: too many arguments to function
[Qemu-devel] [PATCH] hw/9pfs: Improve portability to older systems
From: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
commit ae0f940e6b4f5177892dd6a12762282fa9089972
2507718baf311ea78156c6777d38410a9f89ce89 missed updating
virtio-9p-handle.c.
Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
---
hw/9pfs/virtio-9p-handle.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/hw/9pfs/virtio-9p-handle.c b/hw/9pfs/virtio-9p-handle.c
index 7644ae5..93552a1 100644
--- a/hw/9pfs/virtio-9p-handle.c
+++ b/hw/9pfs/virtio-9p-handle.c
@@ -599,7 +599,8 @@ static int handle_unlinkat(FsContext *ctx, V9fsPath *dir,
static int handle_ioc_getversion(FsContext *ctx, V9fsPath *path,
mode_t st_mode, uint64_t *st_gen)
{
-int err;
+int err = -ENOTTY;
+#ifdef FS_IOC_GETVERSION
V9fsFidOpenState fid_open;
/*
@@ -615,6 +616,7 @@ static int handle_ioc_getversion(FsContext *ctx, V9fsPath
*path,
}
err = ioctl(fid_open.fd, FS_IOC_GETVERSION, st_gen);
handle_close(ctx, fid_open);
+#endif
return err;
}
@@ -630,6 +632,7 @@ static int handle_init(FsContext *ctx)
ret = data-mountfd;
goto err_out;
}
+#ifdef FS_IOC_GETVERSION
ret = statfs(ctx-fs_root, stbuf);
if (!ret) {
switch (stbuf.f_type) {
@@ -641,6 +644,7 @@ static int handle_init(FsContext *ctx)
break;
}
}
+#endif
memset(fh, 0, sizeof(struct file_handle));
ret = name_to_handle(data-mountfd, ., fh, mnt_id, 0);
if (ret errno == EOVERFLOW) {
--
1.7.5.4
Re: [Qemu-devel] [PATCH 1.0] 9pfs: improve portability to older systems
On Mon, 28 Nov 2011 16:36:18 -0600, Anthony Liguori anth...@codemonkey.ws
wrote:
On 11/23/2011 12:16 AM, Aneesh Kumar K.V wrote:
On Mon, 21 Nov 2011 09:29:11 +0100, Paolo Bonzinipbonz...@redhat.com
wrote:
Small requirements on new features have percolated to virtio-9p-local.c.
In particular, the utimensat wrapper actually only supports dirfd =
AT_FDCWD
and flags = AT_SYMLINK_NOFOLLOW in the fallback code. Remove the arguments
so that virtio-9p-local.c will not use AT_* constants.
At the same time, fail local_ioc_getversion if the ioctl is not supported
by the host.
Signed-off-by: Paolo Bonzinipbonz...@redhat.com
Hrm, I may have messed this up. My mailbox processing script seems to have
found Aneesh's patch instead of Paolo's.
Can ya'll take a look at 2507718baf311ea78156c6777d38410a9f89ce89 and tell me
if
I need to revert it?
No i don't think that needs a revert. But we may need the below patch. I
have also send the change as a separate mail to the list.
From db7fdc1c8eb95d556c18ee44fd4f9d5a3aabf9c4 Mon Sep 17 00:00:00 2001
From: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
Date: Tue, 29 Nov 2011 15:10:52 +0530
Subject: [PATCH] hw/9pfs: Improve portability to older systems
commit ae0f940e6b4f5177892dd6a12762282fa9089972
2507718baf311ea78156c6777d38410a9f89ce89 missed updating
virtio-9p-handle.c.
Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
---
hw/9pfs/virtio-9p-handle.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/hw/9pfs/virtio-9p-handle.c b/hw/9pfs/virtio-9p-handle.c
index 7644ae5..93552a1 100644
--- a/hw/9pfs/virtio-9p-handle.c
+++ b/hw/9pfs/virtio-9p-handle.c
@@ -599,7 +599,8 @@ static int handle_unlinkat(FsContext *ctx, V9fsPath *dir,
static int handle_ioc_getversion(FsContext *ctx, V9fsPath *path,
mode_t st_mode, uint64_t *st_gen)
{
-int err;
+int err = -ENOTTY;
+#ifdef FS_IOC_GETVERSION
V9fsFidOpenState fid_open;
/*
@@ -615,6 +616,7 @@ static int handle_ioc_getversion(FsContext *ctx, V9fsPath
*path,
}
err = ioctl(fid_open.fd, FS_IOC_GETVERSION, st_gen);
handle_close(ctx, fid_open);
+#endif
return err;
}
@@ -630,6 +632,7 @@ static int handle_init(FsContext *ctx)
ret = data-mountfd;
goto err_out;
}
+#ifdef FS_IOC_GETVERSION
ret = statfs(ctx-fs_root, stbuf);
if (!ret) {
switch (stbuf.f_type) {
@@ -641,6 +644,7 @@ static int handle_init(FsContext *ctx)
break;
}
}
+#endif
memset(fh, 0, sizeof(struct file_handle));
ret = name_to_handle(data-mountfd, ., fh, mnt_id, 0);
if (ret errno == EOVERFLOW) {
--
1.7.5.4
Re: [Qemu-devel] [PATCH v2] Support for UDP unicast network backend
On Tue, Nov 29, 2011 at 5:29 PM, Benjamin mlspira...@gmail.com wrote:
On 11/28/11 20:39, Stefan Hajnoczi wrote:
On Fri, Nov 25, 2011 at 12:49 PM, Benjaminmlspira...@gmail.com wrote:
+ fd = qemu_socket(PF_INET, SOCK_DGRAM, 0);
+ if (fd 0) {
+ perror(socket(PF_INET, SOCK_DGRAM));
+ return -1;
+ }
+ val = 1;
+ ret = setsockopt(fd, SOL_SOCKET, SO_REUSEADDR,
+ (const char *)val, sizeof(val));
+ if (ret 0) {
+ perror(setsockopt(SOL_SOCKET, SO_REUSEADDR));
Please avoid leaking the file descriptor on error:
closesocket(fd);
Since existing code also does this it may be more appropriate to send
a follow-up patch that cleans up all of net/socket.c.
Reviewed-by: Stefan Hajnoczistefa...@linux.vnet.ibm.com
Stefan
I can do that. However is it really a leak considering the fact that
the program will call exit just after?
If it's a matter of consistency and coding style I would understand
though.
net/socket.c should not make assumptions about the main program
exiting after an error. NICs can be added at runtime using netdev_add
and that should not leak file descriptors.
One more thing, git-format-patch added a From field to the header and
caused this glitch in the mail. I thought git-send-mail or the mail
server would handle it well but apparently not:
From 2f5b85fcadcfee3b75a6a21dc86d10b945c99f0f Mon Sep 17 00:00:00 2001
From: Benjamin MARSILI marsi...@epitech.eu
git-am didn't complain with the patch that I sent but it may break after
gmail relayed it
(http://lists.gnu.org/archive/html/qemu-devel/2011-11/msg03152.html).
The second from header is interpreted as text... Should I remove the
first From field before sending the patch?
This is normal and is not a problem. Your git commit is authored by
Benjamin MARSILI marsi...@epitech.eu but you sent the mail from
Benjamin mlspira...@gmail.com.
git-am will apply the patch with Benjamin MARSILI
marsi...@epitech.eu as the author and it will forget about Benjamin
mlspira...@gmail.com. This is usually what you want - it let's you
credit commits to other people but send the patch emails on their
behalf.
Stefan
Re: [Qemu-devel] [PATCH] ccid: Fix buffer overrun in handling of VSC_ATR message
Alon Levy al...@redhat.com writes: On Mon, Nov 28, 2011 at 08:27:37PM +0100, Markus Armbruster wrote: ATR size exceeding the limit is diagnosed, but then we merrily use it anyway, overrunning card-atr[]. The message is read from a character device. Obvious security implications unless the other end of the character device is trusted. Spotted by Coverity. CVE-2011-4111. Anthony, do you want me to do a pull request for this or can you merge it as is? It's already in, commit 7e62255a.
Re: [Qemu-devel] [PATCH] exec.c: Fix subpage memory access to RAM MemoryRegion
On 11/29/2011 12:39 AM, Andreas Färber wrote:
Am 28.11.2011 18:17, schrieb Avi Kivity:
On 11/28/2011 05:06 PM, Andreas Färber wrote:
Commit 95c318f5e1f88d7e5bcc6deac17330fd4806a2d3 (Fix segfault in mmio
subpage
handling code.) prevented a segfault by making all subpage registrations
over an existing memory page perform an unassigned access. Symptoms were
writes not taking effect and reads returning zero.
Very small page sizes are not currently supported either, so subpage memory
areas cannot fully be avoided.
Therefore revert the previous fix and defer recognition of IO_MEM_RAM to
subpage_{read,write}len() and translate any access there.
Signed-off-by: Andreas Färber afaer...@suse.de
Cc: Avi Kivity a...@redhat.com
Cc: Gleb Natapov g...@redhat.com
Cc: Blue Swirl blauwir...@gmail.com
---
exec.c | 33 +++--
1 files changed, 31 insertions(+), 2 deletions(-)
diff --git a/exec.c b/exec.c
index 6b92198..fba5ba1 100644
--- a/exec.c
+++ b/exec.c
@@ -3508,6 +3508,21 @@ static inline uint32_t subpage_readlen (subpage_t
*mmio,
addr += mmio-region_offset[idx];
idx = mmio-sub_io_index[idx];
+if (unlikely(idx == IO_MEM_RAM)) {
IMO, io_mem_init() should have something like
cpu_register_io_memory_fixed(IO_MEM_SUBPAGE_RAM, subpage_ram_read,
subpage_ram_write, ...);
so you don't need those ugly switches; you just convert IO_MEM_RAM to
IO_MEM_SUBPAGE_RAM. Maybe even register IO_MEM_RAM itself. Note need
to handle dirty logging carefully.
That didn't work because cpu_register_io_memory_fixed() is called from
subpage_init(), which is called once for the whole page only, and the
actual subpages are set up with multiple calls to subpage_register()
instead.
I don't mean replacing the subpage handle with a call to c_r_io_m_f();
just make the handle that is placed supage_t::sub_io_index have real io
callbacks.
In io_mem_init(), call cpu_register_io_memory_fixed() with a new
mem_read[] callback array an the existing notdirty_mem_write[] array.
In subpage_register(), if we get an IO_MEM_RAM, convert it to
IO_MEM_SUBPAGE_RAM (and copy the 'memory' to region_offset).
--
error compiling committee.c: too many arguments to function
[Qemu-devel] problem in setting up vmchannel with libvirt
Hi, I am trying to set up vmchannel between the host and guest os. However, sudo virsh start vm1 always gave me this error: * error: Failed to start domain vm1 error: internal error Process exited while reading console log output: char device redirected to /dev/pts/5 bind(unix:/tmp/foo): Permission denied chardev: opening backend socket failed * Related xml is: * channel type='unix' source mode='bind' path='/tmp/foo'/ target type='virtio' name='channel.port.0'/ address type='virtio-serial' controller='0' bus='0' port='1'/ /channel * I can succeed while I manually run the guest os by: * sudo kvm -device virtio-serial \ -chardev socket,path=/tmp/foo,server,nowait,id=foo \ -device virtserialport,chardev=foo,name=org.fedoraproject.port.0\ /path/to/vm1.img * I also noticed that libvirt is able to create socke /var/lib/libvirt/qemu/vm1.monitor every time. I can't win even I change the unix socket path to /var/lib/libvirt/qemu/foo Any information will be appreciated!
[Qemu-devel] When is the trace_dev_write() called?
Hi, I set a breakpoint on trace_dev_write() but the back-trace I see in gdb is something like this: #0 trace_dev_write () #1 0x081488fe in io_writel () #2 0x081487aa in __stl_mmu () #3 0xf5e4e107 in ?? () #4 0x0001 in ?? () #5 0x in ?? () Which is not very helpful. Does anyone know from where this function is called ? It will be really helpful :). Any pointers to the working of the goldfish_trace device would be helpful! Thanks, V
Re: [Qemu-devel] [PATCH 1/2 v2] fix typo: delete redundant semicolon
On Tue, Nov 29, 2011 at 04:52:38PM +0800, Dong Xu Wang wrote: From: Dong Xu Wang wdon...@linux.vnet.ibm.com Double semicolons should be single. Signed-off-by: Dong Xu Wang wdon...@linux.vnet.ibm.com --- block/nbd.c|4 ++-- cpus.c |2 +- hw/9pfs/codir.c|6 +++--- hw/9pfs/virtio-9p-handle.c |2 +- hw/9pfs/virtio-9p.c|4 ++-- hw/acpi.c |2 +- hw/eepro100.c |2 +- hw/ide/via.c |2 +- hw/ppc.c |2 +- hw/smc91c111.c |2 +- linux-user/syscall.c |2 +- net/tap-solaris.c |2 +- target-s390x/op_helper.c |4 ++-- ui/vnc.c |2 +- usb-redir.c|4 ++-- 15 files changed, 21 insertions(+), 21 deletions(-) Thanks, applied both to the trivial patches -next tree: http://repo.or.cz/w/qemu/stefanha.git/shortlog/refs/heads/trivial-patches-next BTW there was a typo in your commit message in Patch 2/2. I fixed it ;-). Stefan
Re: [Qemu-devel] When is the trace_dev_write() called?
On Tue, Nov 29, 2011 at 10:11 AM, Vikram Bhatt vikrams...@gmail.com wrote: I set a breakpoint on trace_dev_write() but the back-trace I see in gdb is something like this: #0 trace_dev_write () #1 0x081488fe in io_writel () #2 0x081487aa in __stl_mmu () #3 0xf5e4e107 in ?? () #4 0x0001 in ?? () #5 0x in ?? () Which is not very helpful. Does anyone know from where this function is called ? It will be really helpful :). Any pointers to the working of the goldfish_trace device would be helpful! Which QEMU source tree are you working on? Is this an Android tree because I don't see the things you mention in qemu.git/master? I suggest mailing the maintainers of that tree. Stefan
Re: [Qemu-devel] [PATCH v2] Support for UDP unicast network backend
On 11/29/11 18:47, Stefan Hajnoczi wrote:
On Tue, Nov 29, 2011 at 5:29 PM, Benjaminmlspira...@gmail.com wrote:
On 11/28/11 20:39, Stefan Hajnoczi wrote:
On Fri, Nov 25, 2011 at 12:49 PM, Benjaminmlspira...@gmail.comwrote:
+fd = qemu_socket(PF_INET, SOCK_DGRAM, 0);
+if (fd0) {
+perror(socket(PF_INET, SOCK_DGRAM));
+return -1;
+}
+val = 1;
+ret = setsockopt(fd, SOL_SOCKET, SO_REUSEADDR,
+ (const char *)val, sizeof(val));
+if (ret0) {
+perror(setsockopt(SOL_SOCKET, SO_REUSEADDR));
Please avoid leaking the file descriptor on error:
closesocket(fd);
Since existing code also does this it may be more appropriate to send
a follow-up patch that cleans up all of net/socket.c.
Reviewed-by: Stefan Hajnoczistefa...@linux.vnet.ibm.com
Stefan
I can do that. However is it really a leak considering the fact that
the program will call exit just after?
If it's a matter of consistency and coding style I would understand
though.
net/socket.c should not make assumptions about the main program
exiting after an error. NICs can be added at runtime using netdev_add
and that should not leak file descriptors.
Ah, indeed, I mixed up err and perror since I'm used to calling
warn instead of perror.
One more thing, git-format-patch added a From field to the header and
caused this glitch in the mail. I thought git-send-mail or the mail
server would handle it well but apparently not:
From 2f5b85fcadcfee3b75a6a21dc86d10b945c99f0f Mon Sep 17 00:00:00 2001
From: Benjamin MARSILImarsi...@epitech.eu
git-am didn't complain with the patch that I sent but it may break after
gmail relayed it
(http://lists.gnu.org/archive/html/qemu-devel/2011-11/msg03152.html).
The second from header is interpreted as text... Should I remove the
first From field before sending the patch?
This is normal and is not a problem. Your git commit is authored by
Benjamin MARSILImarsi...@epitech.eu but you sent the mail from
Benjaminmlspira...@gmail.com.
git-am will apply the patch with Benjamin MARSILI
marsi...@epitech.eu as the author and it will forget about Benjamin
mlspira...@gmail.com. This is usually what you want - it let's you
credit commits to other people but send the patch emails on their
behalf.
Stefan
Great, thank you, sending v3 soon.
Benjamin
Re: [Qemu-devel] [PATCH V3 2/2] Add -f option to qemu-nbd
On Fri, Nov 25, 2011 at 10:19 AM, Chunyan Liu cy...@suse.com wrote: 2011/11/24 Stefan Hajnoczi stefa...@gmail.com On Thu, Nov 24, 2011 at 3:38 AM, Chunyan Liu cy...@suse.com wrote: 2011/11/23 Stefan Hajnoczi stefa...@gmail.com On Wed, Nov 23, 2011 at 10:14 AM, Chunyan Liu cy...@suse.com wrote: V3: Remove file lock in main(). Try to find new free nbd device and connect to it if connecting to the first first found free nbd device failed. Signed-off-by: Chunyan Liu cy...@suse.com --- qemu-nbd.c | 80 +++- 1 files changed, 79 insertions(+), 1 deletions(-) I not seeing the part where you adjusted the ioctl order. The /proc/partitions scanning is unnecessary since we can just loop over /dev/ndb%d and try to initialize. If a device is in use then init will fail and we need to try the next one. If a device is free we can continue with normal operation. I guess I'm saying that once you fix the ioctl order then there's no need for another mechanism to test whether or not a device is in use. The way of scanning /proc/partitions to find an unused nbd device first can borrow the code for qemu-nbd -c to do the left things. . The way of loop over /dev/nbd%d and try to initialize, from the first thought, needs do all things in the loop, including handling -v, nbd_init, nbd_client, etc. That part of code is quite similar to qemu-nbd -c. I don't know if that is better? This might be a chance to refactor the code slightly, that would also avoid you having to introduce a goto retry. About detail implementation of the loop over /dev/nbd%d way, have done some coding and testing. I'm afraid the reorganization work is not very slight, not sure how do you think. First, through nbd_init() success or fail to check if the device is in use, at least nbd_init() and operations before nbd_init() but device relative should be in the loop. Usually, there are two ways to be considered: 1. Try to divide current qemu-nbd -c processing code into two parts ( nbd_init() and before, and operations after nbd_init()), 1st part put into the loop, 2nd part outside loop. This way is hard to achieve. nbd_init() should be in client thread, but the loop is outside that thread, it's not proper to drag out nbd_init() from client thread and put it into the loop. 2. Put all qemu-nbd -c processing code (device relative) in the loop, directly check the qemu-nbd -c /dev/nbd%d disk.img result, if fail, try next nbd device. In this way, will adjust current code order and extract device related codes to a new function so that both qemu-nbd -c and qemu-nbd -f can use.(some initialization work and cleanup work to be cared) A draft is in attachment. qemu-nbd -f is working, since I'm not sure such change is acceptable or not, not extract code in the loop into a function yet. I think a common function makes sense. This may be nicest in two patches, Patch 1 moves the code into a function, Patch 2 implements -f/find. Stefan
[Qemu-devel] [PATCH v3] Support for UDP unicast network backend
Signed-off-by: Benjamin mlspira...@gmail.com
---
net.c |6 -
net/socket.c| 73 +-
qemu-options.hx |2 +
3 files changed, 78 insertions(+), 3 deletions(-)
diff --git a/net.c b/net.c
index cb52050..8e957b2 100644
--- a/net.c
+++ b/net.c
@@ -999,7 +999,11 @@ static const struct {
}, {
.name = localaddr,
.type = QEMU_OPT_STRING,
-.help = source address for multicast packets,
+.help = source address and port for multicast and udp
packets,
+}, {
+.name = udp,
+.type = QEMU_OPT_STRING,
+.help = UDP unicast address and port number,
},
{ /* end of list */ }
},
diff --git a/net/socket.c b/net/socket.c
index e9ef128..69a03e6 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -524,6 +524,57 @@ static int net_socket_mcast_init(VLANState *vlan,
}
+static int net_socket_udp_init(VLANState *vlan,
+ const char *model,
+ const char *name,
+ const char *rhost,
+ const char *lhost)
+{
+NetSocketState *s;
+int fd, val, ret;
+struct sockaddr_in laddr, raddr;
+
+if (parse_host_port(laddr, lhost) 0) {
+return -1;
+}
+
+if (parse_host_port(raddr, rhost) 0) {
+return -1;
+}
+
+fd = qemu_socket(PF_INET, SOCK_DGRAM, 0);
+if (fd 0) {
+perror(socket(PF_INET, SOCK_DGRAM));
+return -1;
+}
+val = 1;
+ret = setsockopt(fd, SOL_SOCKET, SO_REUSEADDR,
+ (const char *)val, sizeof(val));
+if (ret 0) {
+perror(setsockopt(SOL_SOCKET, SO_REUSEADDR));
+closesocket(fd);
+return -1;
+}
+ret = bind(fd, (struct sockaddr *)laddr, sizeof(laddr));
+if (ret 0) {
+perror(bind);
+closesocket(fd);
+return -1;
+}
+
+s = net_socket_fd_init(vlan, model, name, fd, 0);
+if (!s) {
+return -1;
+}
+
+s-dgram_dst = raddr;
+
+snprintf(s-nc.info_str, sizeof(s-nc.info_str),
+ socket: udp=%s:%d,
+ inet_ntoa(raddr.sin_addr), ntohs(raddr.sin_port));
+return 0;
+}
+
int net_init_socket(QemuOpts *opts,
Monitor *mon,
const char *name,
@@ -597,10 +648,28 @@ int net_init_socket(QemuOpts *opts,
if (net_socket_mcast_init(vlan, socket, name, mcast, localaddr) ==
-1) {
return -1;
}
+} else if (qemu_opt_get(opts, udp)) {
+const char *udp, *localaddr;
+
+if (qemu_opt_get(opts, fd) ||
+qemu_opt_get(opts, connect) ||
+qemu_opt_get(opts, listen) ||
+qemu_opt_get(opts, mcast)) {
+error_report(fd=, connect=, listen=\
+ and mcast= is invalid with udp=);
+return -1;
+}
+
+udp = qemu_opt_get(opts, udp);
+localaddr = qemu_opt_get(opts, localaddr);
+
+if (net_socket_udp_init(vlan, udp, name, udp, localaddr) == -1) {
+return -1;
+}
} else {
-error_report(-socket requires fd=, listen=, connect= or mcast=);
+error_report(-socket requires fd=, listen=, \
+ connect=, mcast= or udp=);
return -1;
}
-
return 0;
}
diff --git a/qemu-options.hx b/qemu-options.hx
index 681eaf1..5495368 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -1217,6 +1217,8 @@ DEF(net, HAS_ARG, QEMU_OPTION_net,
-net
socket[,vlan=n][,name=str][,fd=h][,mcast=maddr:port[,localaddr=addr]]\n
connect the vlan 'n' to multicast maddr and port\n
use 'localaddr=addr' to specify the host address to send
packets from\n
+-net
socket[,vlan=n][,name=str][,fd=h][,udp=host:port][,localaddr=host:port]\n
+connect the vlan 'n' to another VLAN using an UDP
tunnel\n
#ifdef CONFIG_VDE
-net
vde[,vlan=n][,name=str][,sock=socketpath][,port=n][,group=groupname][,mode=octalmode]\n
connect the vlan 'n' to port 'n' of a vde switch
running\n
--
1.7.6
Re: [Qemu-devel] RFC: Design Doc for a new trace format (to support variable number/size of args per event) simpletrace-v2
On Tue, Nov 29, 2011 at 8:29 AM, Harsh Bora ha...@linux.vnet.ibm.com wrote:
Currently, Qemu provides an in-built simple trace backend which is simple
and easy to use (no additional/external dependencies) and allows developers
to trace events in Qemu code, however, it suffers from limitations like
unability to trace more than 6 elements per trace event, lack of string
support, etc. There are various places in Qemu code, where one would want to
trace events having multiple arguments including strings. This results into
motivation for defining an advanced, yet simple trace format which will
address these limitations. For the sake of convinence, let us call this new
trace format as simpletrace v2 (any other better name?).
HLD for Simpletrace v2:
==
This new trace format defines 3 types of structures for trace data
organization:
1) Trace Log Header (per log file, provides meta-data about the entire trace
log, like trace format version, endianness, etc.)
2) Trace Event Header (per trace event, provides meta-data per trace event)
3) Trace Data (per argument/data in a trace event, provides size of data
followed by data itself)
The Trace Log header can be defined like this:
typedef struct {
uint64_t endian_magic; /* =0xAA0011FF, a magic number helps
identifying validity and endian-ness of trace log to its readers */
uint64_t pid; /* pid of qemu process can be traced here */
uint64_t version; /* Keeping version info as 3rd 64-bit element
as expected by current simpletrace format */
unit64_t timestamp; /* timestamp info */
} TraceLogHeader;
Suggestions are invited to make this header more informative as required.
Further, this TraceLogHeader will be followed by 0 or more Trace Event
Headers (further followed by trace data) as defined below:
typedef struct {
uint64_t magic; /* =0xA1B2C3D4, ensures a valid trace record,
otherwise corrupted */
unit64_t id; /* unique identifer per trace event */
uint64_t timestamp; /* timestamp info */
uint64_t num_args; /* number of arguments (followed by this
TraceEventHeader) traced in this trace event */
What exactly is num_args?
} TraceEventHeader;
Trace Data is expected to be stored in following format followed by
TraceEventHeader:
typedef struct {
uint64_t size; /* size of data in bytes to be read following this
header */
uint8_t data[0] /* variable sized data */
} TraceData;
This format does not support variable-length strings in a
self-describing way. What I mean is that a trace record containing a
string should work in the simpletrace Python module:
class QMPAnalyzer(simpletrace.Analyzer):
def handle_qmp_command(self, mon, cmd_name):
print 'QMP command %s on monitor %#x' % (cmd_name, mon)
The cmd_name argument is a string and this script shows all QMP
commands that were handled.
A simple way of implementing this is to have simpletrace.py parse
trace-events and look for (const) char * arguments. String arguments
are serialized like this:
uint16_t length;
char chars[length];
It may be useful to pad to the next 8-byte boundary after a string argument.
Stefan
[Qemu-devel] [PULL][1.1] Memory API conversions
Please pull from git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git memory/batch to receive the final batch of mmio conversions to the memory API (note that ioports still use the old API). While there may be a few regressions in there, it will be a lot easier to find them in the tree, and the series is easily bisectable. I tested it on and x86_64 host with the images from the wiki, and saw no obvious issues. This conversion was brought to you by: Avi Kivity, Benoît Canet, Blue Swirl, Edgar E. Iglesias, Fabien Chouteau, Hervé Poussineau, Jan Kiszka, Michael Walle, Peter Maydell, and Richard Henderson. Thanks to everyone who contributed. Avi Kivity (66): tosa: convert to memory API versatilepb: convert to memory API vexpress: convert to memory API virtex_ml507: convert to memory API shix: convert to memory API jazz_led: convert to memory API parallel: convert to memory API zaurus: convert to memory API pl011: convert to memory API pl022: convert to memory API pl031: convert to memory API pl050: convert to memory API pl061: convert to memory API pl080: convert to memory API pl110: convert to memory API pl181: convert to memory API pl190: convert to memory API fdc: convert to memory API sbi: convert to memory API rc4030: convert to memory API hpet: convert to memory API ide/mmio: convert to memory API cs4321: convert to memory API dp8393x: convert to memory API ds1225y: convert to memory API m48t59: convert to memory API memory: add MemoryRegionOps::valid.accepts esp: convert to memory API fw_cfg: convert to memory API mpc8544_guts: convert to memory API empty_slot: convert to memory API eccmemctl: convert to memory API axis_dev88: convert to memory API pxa2xx_dma: convert to memory API sparc32_dma: convert to memory API bitbang_i2c: avoid call to sysbus_init_mmio() musicpal: avoid call to sysbus_init_mmio() grlib_apbuart: convert to memory API grlib_gptimer: convert to memory API grlib_irqmp: convert to memory API sun4m_iommu: convert to memory API sun4c_intctl: convert to memory API xilinx_axidma: convert to memory API xilinx_axienet: convert to memory API lm32_timer: convert to memory API ppc4xx_pci: convert to memory API ppce500_pci: convert to memory API prep_pci: convert to memory API omap_uart: convert to memory API omap: remove L4_MUX_HACK omap: eliminate l4_register_io_memory omap_l4: add memory API variant of omap_l4_attach() omap_mmc: convert to memory API omap_tap: convert to memory API omap_synctimer: convert to memory API omap_gp_timer: convert to memory API omap_sdrc: convert to memory API omap_dma: convert to memory API omap_gpio: convert to memory API sysbus: remove sysbus_init_mmio() sysbus: rename sysbus_init_mmio_region() to sysbus_init_mmio() omap2: convert to memory API (part I) omap2: convert to memory API (part II) omap_dss: convert to memory API omap_l4: remove omap_l4_attach() omap_l4: rename omap_l4_attach_region() to omap_l4_attach() Benoît Canet (58): integratorcp: convert core to memory API integratorcp: convert icp pic to memory API integratorcp: convert control to memory API stellaris: convert sys to memory API stellaris: convert i2c to memory API stellaris: convert adc to memory API stellaris: convert gptm to memory API marvell_88x8618_audio: convert to memory API mst_fpga: convert to memory API syborg_fb: convert to memory API syborg_interrupt: convert to memory API syborg_keyboard: convert to memory API syborg_pointer: convert to memory API syborg_rtc: convert to memory API syborg_serial: convert to memory API syborg_timer: convert to memory API syborg_virtio: convert to memory API pxa2xx_gpio: convert to memory API pxa2xx_pcmcia.c: convert common memory space to memory API pxa2xx_pcmcia.c: convert attribute memory space to memory API pxa2xx_pcmcia.c: convert io memory space to memory API pxa2xx_keypad: convert to memory API pxa2xx_timer: convert to memory API pxa2xx_pic: convert to memory API pxa2xx_mmci: convert to memory API pxa2xx_lcd: convert to memory API slavio_misc: convert apc to memory API slavio_misc: convert configuration to memory API slavio_misc: convert diagnostic to memory API slavio_misc: convert modem to memory API slavio_misc: convert leds to memory API slavio_misc: convert system control to memory API slavio_misc: convert aux1 to memory API slavio_misc: convert aux2 to memory API slavio_intctl: convert master interrupt controller to memory API
Re: [Qemu-devel] RFC: Design Doc for a new trace format (to support variable number/size of args per event) simpletrace-v2
On Tue, Nov 29, 2011 at 11:34 AM, Stefan Hajnoczi stefa...@gmail.com wrote:
On Tue, Nov 29, 2011 at 8:29 AM, Harsh Bora ha...@linux.vnet.ibm.com wrote:
Currently, Qemu provides an in-built simple trace backend which is simple
and easy to use (no additional/external dependencies) and allows developers
to trace events in Qemu code, however, it suffers from limitations like
unability to trace more than 6 elements per trace event, lack of string
support, etc. There are various places in Qemu code, where one would want to
trace events having multiple arguments including strings. This results into
motivation for defining an advanced, yet simple trace format which will
address these limitations. For the sake of convinence, let us call this new
trace format as simpletrace v2 (any other better name?).
HLD for Simpletrace v2:
==
This new trace format defines 3 types of structures for trace data
organization:
1) Trace Log Header (per log file, provides meta-data about the entire trace
log, like trace format version, endianness, etc.)
2) Trace Event Header (per trace event, provides meta-data per trace event)
3) Trace Data (per argument/data in a trace event, provides size of data
followed by data itself)
The Trace Log header can be defined like this:
typedef struct {
uint64_t endian_magic; /* =0xAA0011FF, a magic number helps
identifying validity and endian-ness of trace log to its readers */
uint64_t pid; /* pid of qemu process can be traced here */
uint64_t version; /* Keeping version info as 3rd 64-bit element
as expected by current simpletrace format */
unit64_t timestamp; /* timestamp info */
} TraceLogHeader;
Suggestions are invited to make this header more informative as required.
Further, this TraceLogHeader will be followed by 0 or more Trace Event
Headers (further followed by trace data) as defined below:
typedef struct {
uint64_t magic; /* =0xA1B2C3D4, ensures a valid trace record,
otherwise corrupted */
unit64_t id; /* unique identifer per trace event */
uint64_t timestamp; /* timestamp info */
uint64_t num_args; /* number of arguments (followed by this
TraceEventHeader) traced in this trace event */
What exactly is num_args?
} TraceEventHeader;
Trace Data is expected to be stored in following format followed by
TraceEventHeader:
typedef struct {
uint64_t size; /* size of data in bytes to be read following this
header */
uint8_t data[0] /* variable sized data */
} TraceData;
This format does not support variable-length strings in a
self-describing way.
I used the word self-describing. To be clear I think we should not
put any trace event metadata into the trace file. Instead we continue
to rely on having the trace-events file together with the trace file.
This keeps the trace format simple. If we do want a self-describing
trace format then I think we should use the Common Trace Format that
LTTng is working on instead of rolling our own.
So forget I said self-describing :). I think the only changes from
the v1 format we need are:
1. New magic number to mark v2 format.
2. Trace records are no longer fixed-length, they include a size field:
typedef struct {
uint32_t length; /* in bytes */
uint32_t reserved; /* unused */
uint64_t event;
uint64_t timestamp_ns;
uint8_t arguments[];
} TraceRecord;
3. Strings are serialized like this:
uint16_t length;
char chars[length];
These changes enable:
1. Variable number of trace event arguments.
2. Variable-length strings.
Stefan
Re: [Qemu-devel] [PATCH v3] Support for UDP unicast network backend
On Tue, Nov 29, 2011 at 7:55 PM, Benjamin mlspira...@gmail.com wrote:
Signed-off-by: Benjamin mlspira...@gmail.com
---
net.c | 6 -
net/socket.c | 73 +-
qemu-options.hx | 2 +
3 files changed, 78 insertions(+), 3 deletions(-)
Reviewed-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
+ s = net_socket_fd_init(vlan, model, name, fd, 0);
+ if (!s) {
+ return -1;
+ }
I'll add a TODO to my list about net_socket_fd_init(). It does not
consistently take ownership of fd. It may return NULL without closing
it, but then again it might close it on error in another code path :(.
Don't worry about this for now.
Stefan
[Qemu-devel] Offres emplois pour vous
Bonjour, des nouveaux offres emplois pour vous http://www.universfreeads.com/emplois.php ..
Re: [Qemu-devel] RFC: Design Doc for a new trace format (to support variable number/size of args per event) simpletrace-v2
Stefan Hajnoczi stefa...@gmail.com writes:
[...]
So forget I said self-describing :). I think the only changes from
the v1 format we need are:
1. New magic number to mark v2 format.
2. Trace records are no longer fixed-length, they include a size field:
typedef struct {
uint32_t length; /* in bytes */
uint32_t reserved; /* unused */
uint64_t event;
uint64_t timestamp_ns;
uint8_t arguments[];
} TraceRecord;
3. Strings are serialized like this:
uint16_t length;
char chars[length];
16 bit length? Sure you want that?
These changes enable:
1. Variable number of trace event arguments.
2. Variable-length strings.
Byte strings, i.e. zero bytes not special.
Re: [Qemu-devel] windows guest virtio serial and balloon driver test issues
On Tue, 2011-11-29 at 08:58 +0800, Cao,Bing Bu wrote: Hi, Rozenfeld,Thanks,got it! And do you know whether there are some sufficient test tools (such as IOmeter) to test the virtio driver performance? IoMeter is good. But you also might be interested in SQLIOSim, database hammer, and diskio (part of WLK) + xperf. On 11/25/2011 02:42 PM, Vadim Rozenfeld wrote: On Fri, 2011-11-25 at 09:59 +0800, Cao,Bing Bu wrote: Hi,all Thanks,Frenkel.The test application of the balloon must be run as admin. But I found 2 problems(question) this week when testing windows guest drivers: * If only virtio serial driver installed,the virtio serial test app can not enumerate/find the virtio serial device, but after virtio balloon driver installed,the app can find the virtio serial device correctly. Because of the same GUID which balloon and serial both use? Correct. This test application is a very simplified one. We published it mostly as an example, but not as a real test application. It doesn't enumerate all virtio serial instances, rather just find the first one and use it. * When inflate/deflate the balloon size using qemu monitor balloon command, the total physical memory did not decrease/increase correspondingly,as seen from resource monitor, only the available memory size descrease/increase.But I test on other Linux guest, the total physical memory of the guest OS was changed. Is it a problem? If not,is it confusing to user? Related to the windows internal memory management? Total physical memory on Windows will always be the same, because we don't hot-plug/unplug physical memory. Balloon driver works with non-paged pool memory instead. So, every time you inflate or deflate balloon in your system, you should see Available memory is changing, while physical will always be the same. Best, Vadim. On 11/21/2011 06:33 PM, Arkady Frenkel wrote: On 11/21/2011 10:39 AM, Cao,Bing Bu wrote: Hi, Recently,I am testing windows guest driver on Win7 and WinXP(32bit) with the latest windows guest driver development source. Download from http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/src/ virtio-blk: It seems OK both on Win7 and WinXP,the r/w performance is better than IDE disk. virtio-serial: I tried to test virtio serial driver using the test application in the project. WinXP: Write: OK Read: Error: Read File Failed. Win7: The test application return error can not find vioserial device. But i debug the code and check that the GetDevicePath() return value is not NULL,and same as the value when testing on WinXP. Why the CreateFile() in init() not called? (: virtio-balloon: QEMU monitor: device_add virtio-balloon-pci On the guest,a new device PCI standard RAM controller added. But the Device Manager prompt No driver installed for this device, but install the driver balloon.sys failed. It said the driver is up to date.Confused. (: How can I install and test the balloon driver on Windows? The kvm-guest-drivers-windows.git on kernel.org is not available,is there any mirror git repository? Any mail-list or bugzilla for windows guest driver? Any help from will be appreciated. You need to run serial test app as admin only. To install balloon you have to go throw additional option when click on Browse my computer for driver software. Choose Let me pick from the list of device drivers on my computer option. Arkady Best regards Cao,Bing Bu
Re: [Qemu-devel] [PATCH] exec.c: Fix subpage memory access to RAM MemoryRegion
Am 28.11.2011 16:06, schrieb Andreas Färber:
Commit 95c318f5e1f88d7e5bcc6deac17330fd4806a2d3 (Fix segfault in mmio subpage
handling code.) prevented a segfault by making all subpage registrations
over an existing memory page perform an unassigned access. Symptoms were
writes not taking effect and reads returning zero.
Very small page sizes are not currently supported either, so subpage memory
areas cannot fully be avoided.
Therefore revert the previous fix and defer recognition of IO_MEM_RAM to
subpage_{read,write}len() and translate any access there.
Signed-off-by: Andreas Färber afaer...@suse.de
Cc: Avi Kivity a...@redhat.com
Cc: Gleb Natapov g...@redhat.com
Cc: Blue Swirl blauwir...@gmail.com
---
exec.c | 33 +++--
1 files changed, 31 insertions(+), 2 deletions(-)
diff --git a/exec.c b/exec.c
index 6b92198..fba5ba1 100644
--- a/exec.c
+++ b/exec.c
@@ -3508,6 +3508,21 @@ static inline uint32_t subpage_readlen (subpage_t
*mmio,
addr += mmio-region_offset[idx];
idx = mmio-sub_io_index[idx];
+if (unlikely(idx == IO_MEM_RAM)) {
+ram_addr_t raddr = /*mmio-base |*/ addr;
+void *ptr = qemu_get_ram_ptr(raddr);
This...
+switch (len) {
+default:
+case 0:
+return ldub_p(ptr);
+case 1:
+return lduw_p(ptr);
+case 2:
+return ldl_p(ptr);
+case 3:
+return ldq_p(ptr);
+}
+}
return io_mem_read[idx][len](io_mem_opaque[idx], addr);
}
@@ -3522,6 +3537,22 @@ static inline void subpage_writelen (subpage_t *mmio,
target_phys_addr_t addr,
addr += mmio-region_offset[idx];
idx = mmio-sub_io_index[idx];
+if (unlikely(idx == IO_MEM_RAM)) {
+ram_addr_t raddr = /*mmio-base |*/ addr;
+void *ptr = qemu_get_ram_ptr(raddr);
...and/or this seems to lead to Bad RAM pointer (or so) when there's
ELF code loaded into the subpage at that address despite being IO_MEM_RAM?
(Seen, e.g., if for RL78 I increase the page size from 12 to 16.)
+switch (len) {
+default:
+case 0:
+stb_p(ptr, value);
break;
+case 1:
+stw_p(ptr, value);
break;
+case 2:
+stl_p(ptr, value);
break;
+case 3:
+stq_p(ptr, value);
break;
Andreas
+}
+return;
+}
io_mem_write[idx][len](io_mem_opaque[idx], addr, value);
}
@@ -3583,8 +3614,6 @@ static int subpage_register (subpage_t *mmio, uint32_t
start, uint32_t end,
printf(%s: %p start %08x end %08x idx %08x eidx %08x mem %ld\n,
__func__,
mmio, start, end, idx, eidx, memory);
#endif
-if ((memory ~TARGET_PAGE_MASK) == IO_MEM_RAM)
-memory = IO_MEM_UNASSIGNED;
memory = (memory IO_MEM_SHIFT) (IO_MEM_NB_ENTRIES - 1);
for (; idx = eidx; idx++) {
mmio-sub_io_index[idx] = memory;
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] RFC: Design Doc for a new trace format (to support variable number/size of args per event) simpletrace-v2
On Tue, Nov 29, 2011 at 12:35 PM, Markus Armbruster arm...@redhat.com wrote:
Stefan Hajnoczi stefa...@gmail.com writes:
[...]
So forget I said self-describing :). I think the only changes from
the v1 format we need are:
1. New magic number to mark v2 format.
2. Trace records are no longer fixed-length, they include a size field:
typedef struct {
uint32_t length; /* in bytes */
uint32_t reserved; /* unused */
uint64_t event;
uint64_t timestamp_ns;
uint8_t arguments[];
} TraceRecord;
3. Strings are serialized like this:
uint16_t length;
char chars[length];
16 bit length? Sure you want that?
You're right, it's more future-proof to use a larger type. Since I
said uint32_t length in TraceRecord, uint32_t here would work well.
Stefan
[Qemu-devel] virtio-9p compiling error
Hi all, when compiling the 1.0-rc4 I get the following error. 0.14.0-kvm and 0.15.0-kvm were fine, I found no configure switch possibility to disable this code part. I really don't need it. Please help here: CClibhw64/9pfs/virtio-9p.o CClibhw64/9pfs/virtio-9p-local.o /home/erik/qemu-1.0-rc4/hw/9pfs/virtio-9p-local.c: In function 'local_init': /home/erik/qemu-1.0-rc4/hw/9pfs/virtio-9p-local.c:721: warning: unused variable 'stbuf' /home/erik/qemu-1.0-rc4/hw/9pfs/virtio-9p-local.c: At top level: /home/erik/qemu-1.0-rc4/hw/9pfs/virtio-9p-local.c:694: warning: 'local_ioc_getversion' defined but not used CClibhw64/9pfs/virtio-9p-xattr.o CClibhw64/9pfs/virtio-9p-xattr-user.o CClibhw64/9pfs/virtio-9p-posix-acl.o CClibhw64/9pfs/virtio-9p-coth.o CClibhw64/9pfs/cofs.o CClibhw64/9pfs/codir.o CClibhw64/9pfs/cofile.o CClibhw64/9pfs/coxattr.o CClibhw64/9pfs/virtio-9p-handle.o /home/erik/qemu-1.0-rc4/hw/9pfs/virtio-9p-handle.c: In function 'handle_update_file_cred': /home/erik/qemu-1.0-rc4/hw/9pfs/virtio-9p-handle.c:95: warning: implicit declaration of function 'openat' /home/erik/qemu-1.0-rc4/hw/9pfs/virtio-9p-handle.c:95: warning: nested extern declaration of 'openat' /home/erik/qemu-1.0-rc4/hw/9pfs/virtio-9p-handle.c:103: warning: implicit declaration of function 'fchownat' /home/erik/qemu-1.0-rc4/hw/9pfs/virtio-9p-handle.c:103: warning: nested extern declaration of 'fchownat' /home/erik/qemu-1.0-rc4/hw/9pfs/virtio-9p-handle.c: In function 'handle_lstat': /home/erik/qemu-1.0-rc4/hw/9pfs/virtio-9p-handle.c:120: warning: implicit declaration of function 'fstatat' /home/erik/qemu-1.0-rc4/hw/9pfs/virtio-9p-handle.c:120: warning: nested extern declaration of 'fstatat' /home/erik/qemu-1.0-rc4/hw/9pfs/virtio-9p-handle.c: In function 'handle_readlink': /home/erik/qemu-1.0-rc4/hw/9pfs/virtio-9p-handle.c:135: warning: implicit declaration of function 'readlinkat' /home/erik/qemu-1.0-rc4/hw/9pfs/virtio-9p-handle.c:135: warning: nested extern declaration of 'readlinkat' /home/erik/qemu-1.0-rc4/hw/9pfs/virtio-9p-handle.c: In function 'handle_opendir': /home/erik/qemu-1.0-rc4/hw/9pfs/virtio-9p-handle.c:167: warning: implicit declaration of function 'fdopendir' /home/erik/qemu-1.0-rc4/hw/9pfs/virtio-9p-handle.c:167: warning: nested extern declaration of 'fdopendir' /home/erik/qemu-1.0-rc4/hw/9pfs/virtio-9p-handle.c:167: warning: assignment makes pointer from integer without a cast /home/erik/qemu-1.0-rc4/hw/9pfs/virtio-9p-handle.c: In function 'handle_mknod': /home/erik/qemu-1.0-rc4/hw/9pfs/virtio-9p-handle.c:265: warning: implicit declaration of function 'mknodat' /home/erik/qemu-1.0-rc4/hw/9pfs/virtio-9p-handle.c:265: warning: nested extern declaration of 'mknodat' /home/erik/qemu-1.0-rc4/hw/9pfs/virtio-9p-handle.c: In function 'handle_mkdir': /home/erik/qemu-1.0-rc4/hw/9pfs/virtio-9p-handle.c:283: warning: implicit declaration of function 'mkdirat' /home/erik/qemu-1.0-rc4/hw/9pfs/virtio-9p-handle.c:283: warning: nested extern declaration of 'mkdirat' /home/erik/qemu-1.0-rc4/hw/9pfs/virtio-9p-handle.c: In function 'handle_symlink': /home/erik/qemu-1.0-rc4/hw/9pfs/virtio-9p-handle.c:333: warning: implicit declaration of function 'symlinkat' /home/erik/qemu-1.0-rc4/hw/9pfs/virtio-9p-handle.c:333: warning: nested extern declaration of 'symlinkat' /home/erik/qemu-1.0-rc4/hw/9pfs/virtio-9p-handle.c: In function 'handle_link': /home/erik/qemu-1.0-rc4/hw/9pfs/virtio-9p-handle.c:363: warning: implicit declaration of function 'linkat' /home/erik/qemu-1.0-rc4/hw/9pfs/virtio-9p-handle.c:363: warning: nested extern declaration of 'linkat' /home/erik/qemu-1.0-rc4/hw/9pfs/virtio-9p-handle.c: In function 'handle_renameat': /home/erik/qemu-1.0-rc4/hw/9pfs/virtio-9p-handle.c:570: warning: implicit declaration of function 'renameat' /home/erik/qemu-1.0-rc4/hw/9pfs/virtio-9p-handle.c:570: warning: nested extern declaration of 'renameat' /home/erik/qemu-1.0-rc4/hw/9pfs/virtio-9p-handle.c: In function 'handle_unlinkat': /home/erik/qemu-1.0-rc4/hw/9pfs/virtio-9p-handle.c:593: warning: implicit declaration of function 'unlinkat' /home/erik/qemu-1.0-rc4/hw/9pfs/virtio-9p-handle.c:593: warning: nested extern declaration of 'unlinkat' /home/erik/qemu-1.0-rc4/hw/9pfs/virtio-9p-handle.c: In function 'handle_ioc_getversion': /home/erik/qemu-1.0-rc4/hw/9pfs/virtio-9p-handle.c:616: error: 'FS_IOC_GETVERSION' undeclared (first use in this function) /home/erik/qemu-1.0-rc4/hw/9pfs/virtio-9p-handle.c:616: error: (Each undeclared identifier is reported only once /home/erik/qemu-1.0-rc4/hw/9pfs/virtio-9p-handle.c:616: error: for each function it appears in.) make[2]: *** [9pfs/virtio-9p-handle.o] Error 1 make[1]: *** [subdir-libhw64] Error 2 make[1]: Leaving directory `/home/erik/qemu-1.0-rc4' make: *** [qemu-build] Error 2 erik@debian:~$
[Qemu-devel] [Bug 897193] Re: virtfs: kernel compile fails
Hi Avishay, Are you running qemu as a normal user? In that case, could you please check whether normal user has rw access to the kernel source? Also could you please attach the output of strace scripts/kconfig/conf --silentoldconfig Kconfig ? -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/897193 Title: virtfs: kernel compile fails Status in QEMU: New Bug description: I am trying to compile a kernel under virtfs, and am getting an error. The error does not occur when compiling outside of the virtfs mount. Both guest and host are running the 3.0.4 kernel. QEMU is latest from git: bc75c9e50d308b2ec6623a40179c5cdc84b63dae QEMU command line: /usr/local/bin/qemu-system-x86_64 -nographic -boot c -m 1024 -machine type=pc,accel=kvm -drive file=/root/hdd1.img,if=virtio -drive file=/root/test1.img,if=virtio -drive file=/root/test2.img,if=virtio -virtfs local,path=/mnt/virtfs,security_model=none,mount_tag=virtfs -net nic,model=virtio,macaddr=DE:AD:BE:EF:AA:BB -net tap,ifname=qtap0,script=no virtfs line in /etc/fstab: virtfs /mnt/virtfs 9p defaults,noauto,trans=virtio0 0 Steps to reproduce and output: [root@guest linux-3.0.4]# make mrproper CLEAN scripts/basic CLEAN scripts/kconfig CLEAN include/config include/generated CLEAN .config .config.old [root@guest linux-3.0.4]# make defconfig HOSTCC scripts/basic/fixdep HOSTCC scripts/kconfig/conf.o SHIPPED scripts/kconfig/zconf.tab.c SHIPPED scripts/kconfig/lex.zconf.c SHIPPED scripts/kconfig/zconf.hash.c HOSTCC scripts/kconfig/zconf.tab.o HOSTLD scripts/kconfig/conf *** Default configuration is based on 'x86_64_defconfig' # # configuration written to .config # [root@guest linux-3.0.4]# make scripts/kconfig/conf --silentoldconfig Kconfig *** Error during update of the configuration. make[2]: *** [silentoldconfig] Error 1 make[1]: *** [silentoldconfig] Error 2 make: *** No rule to make target `include/config/auto.conf', needed by `include/config/kernel.release'. Stop. Please let me know if you need any other information. Thanks! To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/897193/+subscriptions
Re: [Qemu-devel] [PATCH 4/9] virtio-9p: remove PCI dependencies from hw/9pfs/
On Tue, Nov 29, 2011 at 09:38:43AM +0100, Paolo Bonzini wrote:
On 11/28/2011 07:46 PM, Michael S. Tsirkin wrote:
+#ifdef CONFIG_LINUX
+static int virtio_9p_init_pci(PCIDevice *pci_dev)
+{
+VirtIOPCIProxy *proxy = DO_UPCAST(VirtIOPCIProxy, pci_dev, pci_dev);
+VirtIODevice *vdev;
+
+vdev = virtio_9p_init(pci_dev-qdev,proxy-fsconf);
+vdev-nvectors = proxy-nvectors;
+virtio_init_pci(proxy, vdev);
+/* make the actual value visible */
+proxy-nvectors = vdev-nvectors;
+return 0;
+}
+#endif
+
This ifdef looks wrong to me - is there no way 9p can thinkably
work on non-linux hosts? If yes, we should have a separate config
entry for 9p, configure script can make it
conditional on linux host.
I think it was true in the beginning, but more recent versions
should only depend on CONFIG_POSIX. I will set up FreeBSD and come
back.
Paolo
It might be easier to add CONFIG_VIRTIO_9P. That won't hurt in any case.
--
MST
Re: [Qemu-devel] virtio-9p compiling error
Could you please give your host information? Such as gcc version, distro version etc? I could compile in my Fedora 15 x86-64 system using gcc 4.6.0 -- Regards, M. Mohan Kumar On Tuesday, November 29, 2011 06:27:00 PM erik.r...@rdsoftware.de wrote: Hi all, when compiling the 1.0-rc4 I get the following error. 0.14.0-kvm and 0.15.0-kvm were fine, I found no configure switch possibility to disable this code part. I really don't need it. Please help here: CClibhw64/9pfs/virtio-9p.o CClibhw64/9pfs/virtio-9p-local.o /home/erik/qemu-1.0-rc4/hw/9pfs/virtio-9p-local.c: In function 'local_init': /home/erik/qemu-1.0-rc4/hw/9pfs/virtio-9p-local.c:721: warning: unused variable 'stbuf' /home/erik/qemu-1.0-rc4/hw/9pfs/virtio-9p-local.c: At top level: /home/erik/qemu-1.0-rc4/hw/9pfs/virtio-9p-local.c:694: warning: 'local_ioc_getversion' defined but not used CClibhw64/9pfs/virtio-9p-xattr.o CClibhw64/9pfs/virtio-9p-xattr-user.o CClibhw64/9pfs/virtio-9p-posix-acl.o CClibhw64/9pfs/virtio-9p-coth.o CClibhw64/9pfs/cofs.o CClibhw64/9pfs/codir.o CClibhw64/9pfs/cofile.o CClibhw64/9pfs/coxattr.o CClibhw64/9pfs/virtio-9p-handle.o /home/erik/qemu-1.0-rc4/hw/9pfs/virtio-9p-handle.c: In function 'handle_update_file_cred': /home/erik/qemu-1.0-rc4/hw/9pfs/virtio-9p-handle.c:95: warning: implicit declaration of function 'openat' /home/erik/qemu-1.0-rc4/hw/9pfs/virtio-9p-handle.c:95: warning: nested extern declaration of 'openat' /home/erik/qemu-1.0-rc4/hw/9pfs/virtio-9p-handle.c:103: warning: implicit declaration of function 'fchownat' /home/erik/qemu-1.0-rc4/hw/9pfs/virtio-9p-handle.c:103: warning: nested extern declaration of 'fchownat' /home/erik/qemu-1.0-rc4/hw/9pfs/virtio-9p-handle.c: In function 'handle_lstat': /home/erik/qemu-1.0-rc4/hw/9pfs/virtio-9p-handle.c:120: warning: implicit declaration of function 'fstatat' /home/erik/qemu-1.0-rc4/hw/9pfs/virtio-9p-handle.c:120: warning: nested extern declaration of 'fstatat' /home/erik/qemu-1.0-rc4/hw/9pfs/virtio-9p-handle.c: In function 'handle_readlink': /home/erik/qemu-1.0-rc4/hw/9pfs/virtio-9p-handle.c:135: warning: implicit declaration of function 'readlinkat' /home/erik/qemu-1.0-rc4/hw/9pfs/virtio-9p-handle.c:135: warning: nested extern declaration of 'readlinkat' /home/erik/qemu-1.0-rc4/hw/9pfs/virtio-9p-handle.c: In function 'handle_opendir': /home/erik/qemu-1.0-rc4/hw/9pfs/virtio-9p-handle.c:167: warning: implicit declaration of function 'fdopendir' /home/erik/qemu-1.0-rc4/hw/9pfs/virtio-9p-handle.c:167: warning: nested extern declaration of 'fdopendir' /home/erik/qemu-1.0-rc4/hw/9pfs/virtio-9p-handle.c:167: warning: assignment makes pointer from integer without a cast /home/erik/qemu-1.0-rc4/hw/9pfs/virtio-9p-handle.c: In function 'handle_mknod': /home/erik/qemu-1.0-rc4/hw/9pfs/virtio-9p-handle.c:265: warning: implicit declaration of function 'mknodat' /home/erik/qemu-1.0-rc4/hw/9pfs/virtio-9p-handle.c:265: warning: nested extern declaration of 'mknodat' /home/erik/qemu-1.0-rc4/hw/9pfs/virtio-9p-handle.c: In function 'handle_mkdir': /home/erik/qemu-1.0-rc4/hw/9pfs/virtio-9p-handle.c:283: warning: implicit declaration of function 'mkdirat' /home/erik/qemu-1.0-rc4/hw/9pfs/virtio-9p-handle.c:283: warning: nested extern declaration of 'mkdirat' /home/erik/qemu-1.0-rc4/hw/9pfs/virtio-9p-handle.c: In function 'handle_symlink': /home/erik/qemu-1.0-rc4/hw/9pfs/virtio-9p-handle.c:333: warning: implicit declaration of function 'symlinkat' /home/erik/qemu-1.0-rc4/hw/9pfs/virtio-9p-handle.c:333: warning: nested extern declaration of 'symlinkat' /home/erik/qemu-1.0-rc4/hw/9pfs/virtio-9p-handle.c: In function 'handle_link': /home/erik/qemu-1.0-rc4/hw/9pfs/virtio-9p-handle.c:363: warning: implicit declaration of function 'linkat' /home/erik/qemu-1.0-rc4/hw/9pfs/virtio-9p-handle.c:363: warning: nested extern declaration of 'linkat' /home/erik/qemu-1.0-rc4/hw/9pfs/virtio-9p-handle.c: In function 'handle_renameat': /home/erik/qemu-1.0-rc4/hw/9pfs/virtio-9p-handle.c:570: warning: implicit declaration of function 'renameat' /home/erik/qemu-1.0-rc4/hw/9pfs/virtio-9p-handle.c:570: warning: nested extern declaration of 'renameat' /home/erik/qemu-1.0-rc4/hw/9pfs/virtio-9p-handle.c: In function 'handle_unlinkat': /home/erik/qemu-1.0-rc4/hw/9pfs/virtio-9p-handle.c:593: warning: implicit declaration of function 'unlinkat' /home/erik/qemu-1.0-rc4/hw/9pfs/virtio-9p-handle.c:593: warning: nested extern declaration of 'unlinkat' /home/erik/qemu-1.0-rc4/hw/9pfs/virtio-9p-handle.c: In function 'handle_ioc_getversion': /home/erik/qemu-1.0-rc4/hw/9pfs/virtio-9p-handle.c:616: error: 'FS_IOC_GETVERSION' undeclared (first use in this function) /home/erik/qemu-1.0-rc4/hw/9pfs/virtio-9p-handle.c:616: error: (Each undeclared identifier is reported only once /home/erik/qemu-1.0-rc4/hw/9pfs/virtio-9p-handle.c:616: error: for each function it appears in.)
Re: [Qemu-devel] KVM call agenda for November 29
Avi Kivity a...@redhat.com wrote: On 11/28/2011 04:35 PM, Anthony Liguori wrote: (somewhat related) memory API conversion queue merge plan No need to wait until tomorrow to discuss it, I guess. 1.1 will open up on Friday. I was going to make the suggestion that if anyone has more than 50 non-trivial patches queued in their trees (I suspect a few people do), they split up the pull requests into ~50 or so chunks and send them with a week or so spacing. 50 is just a random number. Just split the requests into reasonable chunks so master doesn't totally fall apart all at once :-) I think memory API may be a special case since a lot of the changes are trivial. So I would expect a larger pull request for the memory API bits. Yes, for the memory API conversion I'd like use 126 patch chunks. While there are probably a few regressions lurking in there, it's easily bisectable and fixable. Better in than out. Bad boy, you should use 128 patchs chunks O:-) I have the vmstate cpus conversion done, and for Friday would have something about virtio conversion. Later, Juan.
Re: [Qemu-devel] [PATCH] qed: limit to image size in qed_find_cluster()
On Tue, Nov 29, 2011 at 5:01 AM, Mark Wu wu...@linux.vnet.ibm.com wrote: On 11/29/2011 12:18 AM, Stefan Hajnoczi wrote: Callers of bdrv_is_allocated() may go beyond the end of the image. For general robustness we should limit to the end of the image so that callers don't end up using out-of-range sector counts and receive -EIO. It seems the same problem exists in qcow/qcow2, why do we not add the limit in bdrv_is_allocated? Then it can cover all formats. Actually, I can't figure out how the caller can go beyond the end of the image. If the I/O request for sectors beyond image size comes from guest, it should be dropped in the guest block layer. If the request comes from qemu, like block streaming, it should also honor the image size, right? Today's bdrv_is_allocated() implementation limits to the end of device if BlockDriver.bdrv_is_allocated is NULL (there is a default implementation). This is a hint that callers may pass pnum values beyond the end of the image. Why is it useful to allow this? Because it makes the caller's job simpler. They can pass in their buffer size directly instead of checking for end of device. The result from bdrv_is_allocated() should limit to the end of device and the caller can safely use it. I think we should preserve this behavior. I like your idea of making it generic and will do that in a new patch. Stefan
Re: [Qemu-devel] windows guest virtio serial and balloon driver test issues
On Tue, 2011-11-29 at 10:43 +0800, Mark Wu wrote: Total physical memory on Windows will always be the same, because we don't hot-plug/unplug physical memory. Balloon driver works with non-paged pool memory instead. So, every time you inflate or deflate balloon in your system, you should see Available memory is changing, while physical will always be the same. But the behaviour of virtio-balloon is different on Linux guest. It updates the totalram_pages on deflate/inflate. Therefore the total In Windows MmNumberOfPhysicalPages is almost totally undocumented. It doesn't mean you can't abuse it. But it will be a hack. physical memory will be updated in the system management interface even though it doesn't really hot-plug/unplug any physical memory. If we just use 'info balloon' to query the balloon status, that should be fine. But if the VM management tool also collects memory information from guest, it will become confusing. Actually, I am not sure which one make more sense. I just think that it should have unified behaviour on both Linux and Windows guests. IMO VM management tools should reference to balloon actual size and amount of available memory, retrieved from guest.
[Qemu-devel] [PATCH] block: implement bdrv_co_is_allocated() boundary cases
Cases beyond the end of the disk image are only implemented for block
drivers that do not provide .bdrv_co_is_allocated(). It's worth making
these cases generic so that block drivers that do implement
.bdrv_co_is_allocated() also get them for free.
Suggested-by: Mark Wu wu...@linux.vnet.ibm.com
Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
---
block.c | 26 ++
1 files changed, 18 insertions(+), 8 deletions(-)
diff --git a/block.c b/block.c
index 4310eb5..1e468a7 100644
--- a/block.c
+++ b/block.c
@@ -2117,23 +2117,33 @@ typedef struct BdrvCoIsAllocatedData {
* not implementing the functionality are assumed to not support backing files,
* hence all their sectors are reported as allocated.
*
+ * If 'sector_num' is beyond the end of the disk image the return value is 0
+ * and 'pnum' is set to 0.
+ *
* 'pnum' is set to the number of sectors (including and immediately following
* the specified sector) that are known to be in the same
* allocated/unallocated state.
*
- * 'nb_sectors' is the max value 'pnum' should be set to.
+ * 'nb_sectors' is the max value 'pnum' should be set to. If nb_sectors goes
+ * beyond the end of the disk image it will be clamped.
*/
int coroutine_fn bdrv_co_is_allocated(BlockDriverState *bs, int64_t sector_num,
int nb_sectors, int *pnum)
{
+int64_t n;
+
+if (sector_num = bs-total_sectors) {
+*pnum = 0;
+return 0;
+}
+
+n = bs-total_sectors - sector_num;
+if (n nb_sectors) {
+nb_sectors = n;
+}
+
if (!bs-drv-bdrv_co_is_allocated) {
-int64_t n;
-if (sector_num = bs-total_sectors) {
-*pnum = 0;
-return 0;
-}
-n = bs-total_sectors - sector_num;
-*pnum = (n nb_sectors) ? (n) : (nb_sectors);
+*pnum = nb_sectors;
return 1;
}
--
1.7.7.3
Re: [Qemu-devel] KVM call agenda for November 29
On 11/28/2011 08:24 AM, Juan Quintela wrote: Hi Please send in any agenda items you are interested in covering. Few more items: - sandboxing/embedding dynamic languages Also a heads up about a couple series I've been waiting to send out for post 1.0: - QOM phase 1 (dynamic properties/stable paths) - Device model test frame work Regards, Anthony Liguori Thanks, Juan. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH] exec.c: Fix subpage memory access to RAM MemoryRegion
On 11/29/2011 02:47 PM, Andreas Färber wrote:
addr += mmio-region_offset[idx];
idx = mmio-sub_io_index[idx];
+if (unlikely(idx == IO_MEM_RAM)) {
+ram_addr_t raddr = /*mmio-base |*/ addr;
+void *ptr = qemu_get_ram_ptr(raddr);
...and/or this seems to lead to Bad RAM pointer (or so) when there's
ELF code loaded into the subpage at that address despite being IO_MEM_RAM?
(Seen, e.g., if for RL78 I increase the page size from 12 to 16.)
addr is relative to the start of the page, instead of the start of the
region. You can use mmio-region_offset[idx] to compensate.
--
error compiling committee.c: too many arguments to function
[Qemu-devel] [Bug 897193] Re: virtfs: kernel compile fails
Hi, I am running qemu as root. The output from strace for the command that you requested shows that this is the problem: rename(.tmpconfig.h, include/generated/autoconf.h) = -1 ENOENT (No such file or directory) The command fails because the directory 'include/generated' doesn't exist because I ran only the command you mentioned, and not 'make'. So I attached the output for: strace -f make /tmp/strace.out Hope that helps, and thanks! ** Attachment added: strace output for make https://bugs.launchpad.net/qemu/+bug/897193/+attachment/2612472/+files/strace.out -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/897193 Title: virtfs: kernel compile fails Status in QEMU: New Bug description: I am trying to compile a kernel under virtfs, and am getting an error. The error does not occur when compiling outside of the virtfs mount. Both guest and host are running the 3.0.4 kernel. QEMU is latest from git: bc75c9e50d308b2ec6623a40179c5cdc84b63dae QEMU command line: /usr/local/bin/qemu-system-x86_64 -nographic -boot c -m 1024 -machine type=pc,accel=kvm -drive file=/root/hdd1.img,if=virtio -drive file=/root/test1.img,if=virtio -drive file=/root/test2.img,if=virtio -virtfs local,path=/mnt/virtfs,security_model=none,mount_tag=virtfs -net nic,model=virtio,macaddr=DE:AD:BE:EF:AA:BB -net tap,ifname=qtap0,script=no virtfs line in /etc/fstab: virtfs /mnt/virtfs 9p defaults,noauto,trans=virtio0 0 Steps to reproduce and output: [root@guest linux-3.0.4]# make mrproper CLEAN scripts/basic CLEAN scripts/kconfig CLEAN include/config include/generated CLEAN .config .config.old [root@guest linux-3.0.4]# make defconfig HOSTCC scripts/basic/fixdep HOSTCC scripts/kconfig/conf.o SHIPPED scripts/kconfig/zconf.tab.c SHIPPED scripts/kconfig/lex.zconf.c SHIPPED scripts/kconfig/zconf.hash.c HOSTCC scripts/kconfig/zconf.tab.o HOSTLD scripts/kconfig/conf *** Default configuration is based on 'x86_64_defconfig' # # configuration written to .config # [root@guest linux-3.0.4]# make scripts/kconfig/conf --silentoldconfig Kconfig *** Error during update of the configuration. make[2]: *** [silentoldconfig] Error 1 make[1]: *** [silentoldconfig] Error 2 make: *** No rule to make target `include/config/auto.conf', needed by `include/config/kernel.release'. Stop. Please let me know if you need any other information. Thanks! To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/897193/+subscriptions
Re: [Qemu-devel] [PATCH 0/5] convert some omap devices to memory API
Avi, Do you have some reference commits regarding portio conversions ? 2011/11/28 Avi Kivity a...@redhat.com On 11/25/2011 04:21 PM, Benoît Canet wrote: These patch convert some omap devices to the memory API Thanks, applied. patch 5 didn't make it to the list, so I took an earlier version. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [PATCH 0/5] convert some omap devices to memory API
On 11/29/2011 04:43 PM, Benoît Canet wrote: Avi, Do you have some reference commits regarding portio conversions ? Sure: isa bus: 23af670e5350e3 f75317b420ed8 4a91d3b33784e7a non-isa: d2c33733c85c4d (hw/prep_pci.c, hw/piix_pci.c) 561e182755f -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] Status of the SH4 / ARM7 emulators
On 11/29/2011 01:09 AM, Tristan Gingold wrote: Then what is your suggestion? Point to the middle ? IE, positive offsets for the common structure, negative offsets for the architecture defined ones. Well, Andreas wants to put the common data at the beginning, which would mean vice versa -- negative for common and positive for arch. Which sounds like it would actually work out well, since ARM only has small positive offsets for address formation. r~
[Qemu-devel] KVM call minutes for November 29
Plans for 1.0 - rc4 should be the last release - should ship 1.0 on Thrusday Merge window start on Monday How to handle stable tree, getting a stable team? - Justin: he don't do schedules for releases because it depends on when patches arrive. - Adding a list for stable patches instead of more maintainers? Next release? - 6 month long also? Anthony: discuss it next week * think about it, and do proposals for next week call Update on QOM - Dynamic propierties for qdev - change types on qdev without touching all the tree several times Test infraestructure - Using a mini-os as an external process to be able to use libc and things like that. Sandboxing and other languages - sandboxing difficult - embedding a language (python?), that would make doing the easy devices emulation really easy How to do high level stuff? - python? Maintainer not responsive: - MIPS as an example, what to do. - In the specific case of MIPS, we haven't had a maintaner since Thiemo - If you feel that a subsystem is not being maintained, just make noise on the list See you next week.
Re: [Qemu-devel] virtio-9p compiling error
My host system is Debian 4.0 My compiler is gcc (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) Due to other hardware constraints I'm forced to this version as build machine. If you need more information, just let me know. Best regards, Erik
Re: [Qemu-devel] [PATCH] exec.c: Fix subpage memory access to RAM MemoryRegion
Am 29.11.2011 15:00, schrieb Avi Kivity:
On 11/29/2011 02:47 PM, Andreas Färber wrote:
addr += mmio-region_offset[idx];
idx = mmio-sub_io_index[idx];
+if (unlikely(idx == IO_MEM_RAM)) {
+ram_addr_t raddr = /*mmio-base |*/ addr;
+void *ptr = qemu_get_ram_ptr(raddr);
...and/or this seems to lead to Bad RAM pointer (or so) when there's
ELF code loaded into the subpage at that address despite being IO_MEM_RAM?
(Seen, e.g., if for RL78 I increase the page size from 12 to 16.)
addr is relative to the start of the page, instead of the start of the
region. You can use mmio-region_offset[idx] to compensate.
That's exactly what the first line of the snippet above does, no?
(sorry, there's still a confusing comment from an earlier attempt)
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [PATCH] fix out of tree build
On Mon, 28 Nov 2011, Stefan Weil wrote:
The broken build can be reproduced with a source path containing at
least one dot.
Source paths without any dot will show no problems. My source path was
~/src/qemu/qemu.org/qemu.
Sorry for the build break, I didn't have any dots in my source path so
I didn't notice it :-/
File scripts/qapi.py fails to create unique guard names when given a
filename with 2 or more dots:
def guardname(filename):
if filename.startswith('./'):
filename = filename[2:]
return filename.replace(/, _).replace(-,
_).split(.)[0].upper() + '_H'
The function always returns the same guard name (in my case
_HOME_STEFAN_SRC_QEMU_QEMU_H)
which won't work when used for more than one header file.
I expect that blanks in the source path will also give unexpected results.
Even when this function were fixed, I think that
qapi-dir := $(BUILD_DIR)/qapi-generated
would be better.
Doing a more careful analysis of the out-of-tree build, I noticed that
the system actually works correctly if the source directory is
distclean.
I don't think we support building qemu out-of-tree if the source dir
hasn't been cleaned properly, so I don't think is worth pursuing this
patch anymore.
Just be aware that a make clean is not enough.
Re: [Qemu-devel] [PATCH] exec.c: Fix subpage memory access to RAM MemoryRegion
On 11/29/2011 06:19 PM, Andreas Färber wrote:
Am 29.11.2011 15:00, schrieb Avi Kivity:
On 11/29/2011 02:47 PM, Andreas Färber wrote:
addr += mmio-region_offset[idx];
idx = mmio-sub_io_index[idx];
+if (unlikely(idx == IO_MEM_RAM)) {
+ram_addr_t raddr = /*mmio-base |*/ addr;
+void *ptr = qemu_get_ram_ptr(raddr);
...and/or this seems to lead to Bad RAM pointer (or so) when there's
ELF code loaded into the subpage at that address despite being IO_MEM_RAM?
(Seen, e.g., if for RL78 I increase the page size from 12 to 16.)
addr is relative to the start of the page, instead of the start of the
region. You can use mmio-region_offset[idx] to compensate.
That's exactly what the first line of the snippet above does, no?
(sorry, there's still a confusing comment from an earlier attempt)
Depends on whether -region_offset has the right value or not, where's
the code that adjusts it? For your case that does f00-fff it should be
-0xf00 + ram_addr (of the start of the region).
--
error compiling committee.c: too many arguments to function
[Qemu-devel] [Bug 897771] [NEW] qemu 1.0-rc4 no longer able to boot NetBSD-current/i386
Public bug reported:
Booting a NetBSD-current/i386 install CD using qemu 1.0-rc4 fails. The
same CD does boot in earlier versions of qemu, for example, 0.11.0.
To reproduce, download the
http://www.gson.org/netbsd/bugs/qemu/boot-com-20270050Z.iso
and attempt to boot it with:
qemu -nographic -cdrom boot-com-20270050Z.iso
This fails with a guest kernel panic:
NetBSD 5.99.57 (GENERIC) #0: Sun Nov 27 07:41:56 UTC 2011
bui...@b8.netbsd.org:/home/builds/ab/HEAD/i386/20270050Z-obj/home/builds/ab/HEAD/src/sys/arch/i386/compile/GENERIC
total memory = 127 MB
avail memory = 112 MB
cprng kernel: WARNING insufficient entropy at creation.
mainbus0 (root)
cpu0 at mainbus0 apid 0: QEMU Virtual CPU version 0.15.93, id 0x633
ioapic0 at mainbus0 apid 1
acpi0 at mainbus0: Intel ACPICA 20110623
panic: pci_make_tag: bad request
fatal breakpoint trap in supervisor mode
trap type 1 code 0 eip c0269b04 cs 8 eflags 282 cr2 0 ilevel 8
Stopped in pid 0.1 (system) at netbsd:breakpoint+0x4: popl%ebp
db{0} t
breakpoint(c0c04c75,c0cc2f80,c0bc91a4,c0e358e4,2,c11b70d6,c0e35908,c053999d,c0cdef20,0)
at netbsd:breakpoint+0x4
vpanic(c0bc91a4,c0e358e4,c117d068,f,c11e6fcc,0,c0e35918,c0665969,c0bc91a4,c0b1bf4c)
at netbsd:vpanic+0x1e2
printf_nolog(c0bc91a4,c0b1bf4c,c0e35908,c010d957,8,c0c1f2c0,0,0,c0d08e20,0)
at netbsd:printf_nolog
pci_decompose_tag(c0e3599c,0,0,10,0,ca675898,c0e35988,c0d08e20,c11b9200,0) at
netbsd:pci_decompose_tag
acpi_pci_link_add_reference(c12011c0,0,0,10,0,ca41eb90,0,3,0,4) at
netbsd:acpi_pci_link_add_reference+0xb2
mpacpi_find_interrupts(ca41eb90,c0116a4a,c0116a5e,0,ca41eb90,c0e35b50,c0e35aa8,c01180c7,c,c0116a4a)
at netbsd:mpacpi_find_interrupts+0x5ea
acpi_md_callback(c,c0116a4a,c0116a5e,0,1,ca3fd7cc,1,c078e2e4,c0cb6ce0,ca435ea0)
at netbsd:acpi_md_callback+0x1c
acpi_attach(ca660500,ca660d00,c0e35b50,0,c0e35b50,80,f,10,c0b5dcd9,c0e35b42)
at netbsd:acpi_attach+0x14a
config_attach_loc(ca660500,c0c1d7a0,0,c0e35b50,0,0,2589,58421301,4350,53445842)
at netbsd:config_attach_loc+0x176
config_found_ia(ca660500,c0b59f3c,c0e35b50,0,4f424101,20534843,80,f,c0c2bbe0,c0c2bc00)
at netbsd:config_found_ia+0x36
mainbus_rescan(ca660500,c0b59f3c,0,ca660500,c0cb6ce0,c0bd71ce,c0e35bd8,c093575c,ca437f28,c0b8e0a1)
at netbsd:mainbus_rescan+0x1c2
mainbus_attach(0,ca660500,0,c078f4b7,c0b59187,c0b59187,636f4200,7368,3001403,101)
at netbsd:mainbus_attach+0xb4
config_attach_loc(0,c0c1bbb0,0,0,0,7368,f10,0,c0b59187,e3b000) at
netbsd:config_attach_loc+0x176
config_attach(0,c0c1bbb0,0,0,1984,c0cc5680,c0e35cd8,c01f224e,c0b59187,0) at
netbsd:config_attach+0x2e
config_rootfound(c0b59187,0,0,8,1984,1984,c0e35d40,c04b78d8,c0ba59a1,6) at
netbsd:config_rootfound+0x42
cpu_configure(c0ba59a1,6,3,0,,f9b00,,f9300,0,0) at
netbsd:cpu_configure+0x2a
main(0,0,0,0,0,0,0,0,0,0) at netbsd:main+0x2ba
db{0}
** Affects: qemu
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/897771
Title:
qemu 1.0-rc4 no longer able to boot NetBSD-current/i386
Status in QEMU:
New
Bug description:
Booting a NetBSD-current/i386 install CD using qemu 1.0-rc4 fails. The
same CD does boot in earlier versions of qemu, for example, 0.11.0.
To reproduce, download the
http://www.gson.org/netbsd/bugs/qemu/boot-com-20270050Z.iso
and attempt to boot it with:
qemu -nographic -cdrom boot-com-20270050Z.iso
This fails with a guest kernel panic:
NetBSD 5.99.57 (GENERIC) #0: Sun Nov 27 07:41:56 UTC 2011
bui...@b8.netbsd.org:/home/builds/ab/HEAD/i386/20270050Z-obj/home/builds/ab/HEAD/src/sys/arch/i386/compile/GENERIC
total memory = 127 MB
avail memory = 112 MB
cprng kernel: WARNING insufficient entropy at creation.
mainbus0 (root)
cpu0 at mainbus0 apid 0: QEMU Virtual CPU version 0.15.93, id 0x633
ioapic0 at mainbus0 apid 1
acpi0 at mainbus0: Intel ACPICA 20110623
panic: pci_make_tag: bad request
fatal breakpoint trap in supervisor mode
trap type 1 code 0 eip c0269b04 cs 8 eflags 282 cr2 0 ilevel 8
Stopped in pid 0.1 (system) at netbsd:breakpoint+0x4: popl%ebp
db{0} t
breakpoint(c0c04c75,c0cc2f80,c0bc91a4,c0e358e4,2,c11b70d6,c0e35908,c053999d,c0cdef20,0)
at netbsd:breakpoint+0x4
vpanic(c0bc91a4,c0e358e4,c117d068,f,c11e6fcc,0,c0e35918,c0665969,c0bc91a4,c0b1bf4c)
at netbsd:vpanic+0x1e2
printf_nolog(c0bc91a4,c0b1bf4c,c0e35908,c010d957,8,c0c1f2c0,0,0,c0d08e20,0)
at netbsd:printf_nolog
pci_decompose_tag(c0e3599c,0,0,10,0,ca675898,c0e35988,c0d08e20,c11b9200,0)
at netbsd:pci_decompose_tag
acpi_pci_link_add_reference(c12011c0,0,0,10,0,ca41eb90,0,3,0,4) at
netbsd:acpi_pci_link_add_reference+0xb2
mpacpi_find_interrupts(ca41eb90,c0116a4a,c0116a5e,0,ca41eb90,c0e35b50,c0e35aa8,c01180c7,c,c0116a4a)
at
Re: [Qemu-devel] KVM call minutes for November 29
On 11/29/2011 05:51 PM, Juan Quintela wrote: How to do high level stuff? - python? One of the disadvantages of the various scripting languages is the lack of static type checking, which makes it harder to do full sweeps of the source for API changes, relying on the compiler to catch type (or other) errors. On the other hand, the statically typed languages usually have more boilerplate. Since one of the goals is to simplify things, this indicates the need for a language with type inference. On the third hand, languages with type inferences are still immature (golang?), so we probably need to keep this discussion going until an obvious choice presents itself. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [Bug 897771] [NEW] qemu 1.0-rc4 no longer able to boot NetBSD-current/i386
On 11/29/2011 06:46 PM, Andreas Gustafsson wrote: Public bug reported: Booting a NetBSD-current/i386 install CD using qemu 1.0-rc4 fails. The same CD does boot in earlier versions of qemu, for example, 0.11.0. Please try to find what is the last major release of qemu that did boot this correctly. -- error compiling committee.c: too many arguments to function
[Qemu-devel] [PATCH] configure: Drop armv4l/armv4b distinction in $cpu
Drop the distinction between armv4l/armv4b in the $cpu variable (ie host cpu type) in favour of calling everything 'arm'. This makes it the same as the ARCH setting and removes some special casing. The only thing we were using the distinction for was to decide which endianness to use in cross compilation; do a cpp define check there instead. Signed-off-by: Peter Maydell peter.mayd...@linaro.org --- A minor cleanup because I got fed up with saying armv4b or armv4l. configure | 26 -- 1 files changed, 12 insertions(+), 14 deletions(-) diff --git a/configure b/configure index ac4840d..018bf23 100755 --- a/configure +++ b/configure @@ -287,10 +287,8 @@ elif check_define __s390__ ; then else cpu=s390 fi -elif check_define __ARMEB__ ; then - cpu=armv4b -elif check_define __ARMEL__ ; then - cpu=armv4l +elif check_define __arm__ ; then + cpu=arm elif check_define __hppa__ ; then cpu=hppa else @@ -307,11 +305,8 @@ case $cpu in x86_64|amd64) cpu=x86_64 ;; - armv*b) -cpu=armv4b - ;; - armv*l) -cpu=armv4l + armv*b|armv*l|arm) +cpu=arm ;; hppa|parisc|parisc64) cpu=hppa @@ -1243,7 +1238,13 @@ else # if cross compiling, cannot launch a program, so make a static guess case $cpu in - armv4b|hppa|m68k|mips|mips64|ppc|ppc64|s390|s390x|sparc|sparc64) + arm) +# ARM can be either way; ask the compiler which one we are +if check_define __ARMEB__; then + bigendian=yes +fi + ;; + hppa|m68k|mips|mips64|ppc|ppc64|s390|s390x|sparc|sparc64) bigendian=yes ;; esac @@ -2871,12 +2872,9 @@ echo docdir=$docdir $config_host_mak echo confdir=$confdir $config_host_mak case $cpu in - i386|x86_64|alpha|cris|hppa|ia64|lm32|m68k|microblaze|mips|mips64|ppc|ppc64|s390|s390x|sparc|sparc64|unicore32) + i386|x86_64|alpha|cris|hppa|ia64|lm32|m68k|microblaze|mips|mips64|ppc|ppc64|s390|s390x|sparc|sparc64|unicore32|arm) ARCH=$cpu ;; - armv4b|armv4l) -ARCH=arm - ;; *) if test $tcg_interpreter = yes ; then echo Unsupported CPU = $cpu, will use TCG with TCI (experimental) -- 1.7.1
Re: [Qemu-devel] problem in setting up vmchannel with libvirt
On Tue, Nov 29, 2011 at 09:55:32AM +, will wrote: Hi, I am trying to set up vmchannel between the host and guest os. However, sudo virsh start vm1 always gave me this error: * error: Failed to start domain vm1 error: internal error Process exited while reading console log output: char device redirected to /dev/pts/5 bind(unix:/tmp/foo): Permission denied chardev: opening backend socket failed * Related xml is: * channel type='unix' source mode='bind' path='/tmp/foo'/ target type='virtio' name='channel.port.0'/ address type='virtio-serial' controller='0' bus='0' port='1'/ /channel * I can succeed while I manually run the guest os by: * sudo kvm -device virtio-serial \ -chardev socket,path=/tmp/foo,server,nowait,id=foo \ -device virtserialport,chardev=foo,name=org.fedoraproject.port.0\ /path/to/vm1.img * I also noticed that libvirt is able to create socke /var/lib/libvirt/qemu/vm1.monitor every time. I can't win even I change the unix socket path to /var/lib/libvirt/qemu/foo Any information will be appreciated! Try the libvirt-users list for questions like this one: libvirt-us...@redhat.com Dave
Re: [Qemu-devel] [Android-virt] plans for QEMU support for KVM on ARM
On 24 November 2011 23:06, Peter Maydell peter.mayd...@linaro.org wrote: On 24 November 2011 22:02, Christoffer Dall cd...@cs.columbia.edu wrote: On Thu, Nov 24, 2011 at 4:27 PM, Peter Maydell peter.mayd...@linaro.org wrote: Pretty high up my todo list was rebasing your kvm patch on to master / qemu-linaro (the two are more or less the same for this purpose). if you could take charge on that it would be awesome from my point of view. I will send you a (slightly) cleaned up patch that you can use or throw away. That would be good, thanks. I'll try to get that rebasing started tomorrow and done early next week. I've now done this rebasing, fixed a few other minor issues and put the resulting patches into qemu-linaro as experimental work in progress: http://git.linaro.org/gitweb?p=qemu/qemu-linaro.git;a=summary Note that I've defaulted KVM to off for ARM hosts (for the benefit of other users of qemu-linaro who don't care about KVM yet), so run configure with --enable-kvm. A note about the branches here: the 'rebasing' branch is the patch stack, and (as the name suggests) it rebases on qemu upstream fairly frequently. 'master' is a never-rebases branch which always has identical contents to the head of 'rebasing' (generated by stg publish). Pick whichever branch suits your use case best. Instructions on how to cross-compile it are here: https://wiki.linaro.org/PeterMaydell/A15OnFastModels (if you're moving from Christoffer's qemu tree these are worth checking, because QEMU now requires glib/gthread so a cross compile setup that could compile Christoffer's tree won't necessarily build this one.) -- PMM
Re: [Qemu-devel] [Android-virt] plans for QEMU support for KVM on ARM
On Tue, Nov 29, 2011 at 1:16 PM, Peter Maydell peter.mayd...@linaro.org wrote: On 24 November 2011 23:06, Peter Maydell peter.mayd...@linaro.org wrote: On 24 November 2011 22:02, Christoffer Dall cd...@cs.columbia.edu wrote: On Thu, Nov 24, 2011 at 4:27 PM, Peter Maydell peter.mayd...@linaro.org wrote: Pretty high up my todo list was rebasing your kvm patch on to master / qemu-linaro (the two are more or less the same for this purpose). if you could take charge on that it would be awesome from my point of view. I will send you a (slightly) cleaned up patch that you can use or throw away. That would be good, thanks. I'll try to get that rebasing started tomorrow and done early next week. I've now done this rebasing, fixed a few other minor issues and put the resulting patches into qemu-linaro as experimental work in progress: http://git.linaro.org/gitweb?p=qemu/qemu-linaro.git;a=summary Note that I've defaulted KVM to off for ARM hosts (for the benefit of other users of qemu-linaro who don't care about KVM yet), so run configure with --enable-kvm. A note about the branches here: the 'rebasing' branch is the patch stack, and (as the name suggests) it rebases on qemu upstream fairly frequently. 'master' is a never-rebases branch which always has identical contents to the head of 'rebasing' (generated by stg publish). Pick whichever branch suits your use case best. Instructions on how to cross-compile it are here: https://wiki.linaro.org/PeterMaydell/A15OnFastModels (if you're moving from Christoffer's qemu tree these are worth checking, because QEMU now requires glib/gthread so a cross compile setup that could compile Christoffer's tree won't necessarily build this one.) this is great, thanks! looking forward to trying it out later this week.
[Qemu-devel] [Bug 897771] Re: qemu 1.0-rc4 no longer able to boot NetBSD-current/i386
Bisecting shows this commit caused the problem:
d0ed8076cbdc26138a7e33fed5e45a35d019a103 is the first bad commit
commit d0ed8076cbdc26138a7e33fed5e45a35d019a103
Author: Avi Kivity a...@redhat.com
Date: Sun Jul 24 17:47:18 2011 +0300
pci_host: convert conf index and data ports to memory API
Reviewed-by: Richard Henderson r...@twiddle.net
Signed-off-by: Avi Kivity a...@redhat.com
** Changed in: qemu
Status: New = 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/897771
Title:
qemu 1.0-rc4 no longer able to boot NetBSD-current/i386
Status in QEMU:
Confirmed
Bug description:
Booting a NetBSD-current/i386 install CD using qemu 1.0-rc4 fails. The
same CD does boot in earlier versions of qemu, for example, 0.11.0.
To reproduce, download the
http://www.gson.org/netbsd/bugs/qemu/boot-com-20270050Z.iso
and attempt to boot it with:
qemu -nographic -cdrom boot-com-20270050Z.iso
This fails with a guest kernel panic:
NetBSD 5.99.57 (GENERIC) #0: Sun Nov 27 07:41:56 UTC 2011
bui...@b8.netbsd.org:/home/builds/ab/HEAD/i386/20270050Z-obj/home/builds/ab/HEAD/src/sys/arch/i386/compile/GENERIC
total memory = 127 MB
avail memory = 112 MB
cprng kernel: WARNING insufficient entropy at creation.
mainbus0 (root)
cpu0 at mainbus0 apid 0: QEMU Virtual CPU version 0.15.93, id 0x633
ioapic0 at mainbus0 apid 1
acpi0 at mainbus0: Intel ACPICA 20110623
panic: pci_make_tag: bad request
fatal breakpoint trap in supervisor mode
trap type 1 code 0 eip c0269b04 cs 8 eflags 282 cr2 0 ilevel 8
Stopped in pid 0.1 (system) at netbsd:breakpoint+0x4: popl%ebp
db{0} t
breakpoint(c0c04c75,c0cc2f80,c0bc91a4,c0e358e4,2,c11b70d6,c0e35908,c053999d,c0cdef20,0)
at netbsd:breakpoint+0x4
vpanic(c0bc91a4,c0e358e4,c117d068,f,c11e6fcc,0,c0e35918,c0665969,c0bc91a4,c0b1bf4c)
at netbsd:vpanic+0x1e2
printf_nolog(c0bc91a4,c0b1bf4c,c0e35908,c010d957,8,c0c1f2c0,0,0,c0d08e20,0)
at netbsd:printf_nolog
pci_decompose_tag(c0e3599c,0,0,10,0,ca675898,c0e35988,c0d08e20,c11b9200,0)
at netbsd:pci_decompose_tag
acpi_pci_link_add_reference(c12011c0,0,0,10,0,ca41eb90,0,3,0,4) at
netbsd:acpi_pci_link_add_reference+0xb2
mpacpi_find_interrupts(ca41eb90,c0116a4a,c0116a5e,0,ca41eb90,c0e35b50,c0e35aa8,c01180c7,c,c0116a4a)
at netbsd:mpacpi_find_interrupts+0x5ea
acpi_md_callback(c,c0116a4a,c0116a5e,0,1,ca3fd7cc,1,c078e2e4,c0cb6ce0,ca435ea0)
at netbsd:acpi_md_callback+0x1c
acpi_attach(ca660500,ca660d00,c0e35b50,0,c0e35b50,80,f,10,c0b5dcd9,c0e35b42) at
netbsd:acpi_attach+0x14a
config_attach_loc(ca660500,c0c1d7a0,0,c0e35b50,0,0,2589,58421301,4350,53445842)
at netbsd:config_attach_loc+0x176
config_found_ia(ca660500,c0b59f3c,c0e35b50,0,4f424101,20534843,80,f,c0c2bbe0,c0c2bc00)
at netbsd:config_found_ia+0x36
mainbus_rescan(ca660500,c0b59f3c,0,ca660500,c0cb6ce0,c0bd71ce,c0e35bd8,c093575c,ca437f28,c0b8e0a1)
at netbsd:mainbus_rescan+0x1c2
mainbus_attach(0,ca660500,0,c078f4b7,c0b59187,c0b59187,636f4200,7368,3001403,101)
at netbsd:mainbus_attach+0xb4
config_attach_loc(0,c0c1bbb0,0,0,0,7368,f10,0,c0b59187,e3b000) at
netbsd:config_attach_loc+0x176
config_attach(0,c0c1bbb0,0,0,1984,c0cc5680,c0e35cd8,c01f224e,c0b59187,0) at
netbsd:config_attach+0x2e
config_rootfound(c0b59187,0,0,8,1984,1984,c0e35d40,c04b78d8,c0ba59a1,6) at
netbsd:config_rootfound+0x42
cpu_configure(c0ba59a1,6,3,0,,f9b00,,f9300,0,0) at
netbsd:cpu_configure+0x2a
main(0,0,0,0,0,0,0,0,0,0) at netbsd:main+0x2ba
db{0}
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/897771/+subscriptions
[Qemu-devel] [Bug 897466] Re: UHCI Host Controller no longer present with -usb
Reproduced with today's qemu git head as well. ** Also affects: qemu Importance: Undecided Status: New -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/897466 Title: UHCI Host Controller no longer present with -usb Status in QEMU: New Status in “qemu-kvm” package in Ubuntu: Confirmed Status in “qemu-kvm” source package in Precise: Confirmed Bug description: If on an up to date 12.04 install and I start a VM with: $ qemu -m 192 -serial none -chardev null,id=chardevmon -pidfile /tmp/pid -daemonize -nographic -monitor tcp:127.0.0.1:,server,nowait -net user,hostfwd=tcp:127.0.0.1:4422-:22 -usb -rtc base=utc -name qatest-vm -uuid ded3a46b-bb60-43f4-8113-d041aeb93cdf -hda libvirt/qatest/qatest.qcow2 Then use the 'info usbhost' in the monitor, I get: $ echo 'info usbhost' | nc -q 1 127.0.0.1 (qemu) info usbhost husb: using sys file-system with /dev/bus/usb $ In Oneiric and eariler, 'info usbhost' would show a UHCI Host Controller. Eg: $ qemu -m 192 -serial none -chardev null,id=chardevmon -pidfile /tmp/pid -daemonize -nographic -monitor tcp:127.0.0.1:,server,nowait -net user,hostfwd=tcp:127.0.0.1:4422-:22 -usb -rtc base=utc -name qatest-vm -uuid ded3a46b-bb60-43f4-8113-d041aeb93cdf -hda libvirt/qatest/qatest.qcow2 $ echo 'info usbhost' | nc -q 1 127.0.0.1 QEMU 0.14.1 monitor - type 'help' for more information (qemu) info usbhost husb: using sys file-system with /dev/bus/usb Device 1.1, speed 12 Mb/s Hub: USB device 1d6b:0001, UHCI Host Controller This breaks QRT/scripts/test-qemu.py and appears to be a regression, but I am not sure if it is a 3.2 kernel issue or a 0.14.1 vs 0.15 issue. I should mention this is happening with qemu without /dev/kvm available (ie, I am running test-qemu.py in an up to date precise VM). To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/897466/+subscriptions
Re: [Qemu-devel] KVM call minutes for November 29
Avi Kivity a...@redhat.com writes: On 11/29/2011 05:51 PM, Juan Quintela wrote: How to do high level stuff? - python? One of the disadvantages of the various scripting languages is the lack of static type checking, which makes it harder to do full sweeps of the source for API changes, relying on the compiler to catch type (or other) errors. On the other hand, the statically typed languages usually have more boilerplate. Since one of the goals is to simplify things, this indicates the need for a language with type inference. On the third hand, languages with type inferences are still immature (golang?), so we probably need to keep this discussion going until an obvious choice presents itself. I wouldn't call ML immature. But I wouldn't call it a scripting language, either.
Re: [Qemu-devel] [RFC PATCH] vfio: VFIO Driver core framework
On Mon, 2011-11-28 at 20:54 -0700, Alex Williamson wrote:
On Tue, 2011-11-29 at 13:01 +1100, Alexey Kardashevskiy wrote:
Hi all,
Another problem I hit on POWER - MSI interrupts allocation. The existing
VFIO does not expect a PBH
to support less interrupts that a device might request. In my case, PHB's
limit is 8 interrupts
while my test card (10Gb ethernet CXGB3) wants 9. Below are the patches to
demonstrate the idea.
Seems reasonable. I assume we'd need similar for vfio_pci_setup_msi,
though I haven't seen anything use more than a single MSI interrupt.
Thanks,
Hmm, I'm thinking maybe we should reflect the pci_enable_msix() behavior
directly and let the caller decide if they want to make do with fewer
MSI vectors. So the ioctl will return 0: error, 0:success, 0: number
of MSIs we think we can setup, without actually setting them. Sound
good?
BTW, github now has updated trees:
git://github.com/awilliam/linux-vfio.git vfio-next-2029
git://github.com/awilliam/qemu-vfio.git vfio-ng
Thanks,
Alex
KERNEL patch:
diff --git a/drivers/vfio/pci/vfio_pci_intrs.c
b/drivers/vfio/pci/vfio_pci_intrs.c
index 7d45c6b..d44b9bf 100644
--- a/drivers/vfio/pci/vfio_pci_intrs.c
+++ b/drivers/vfio/pci/vfio_pci_intrs.c
@@ -458,17 +458,32 @@ int vfio_pci_setup_msix(struct vfio_pci_device *vdev,
int nvec, int __user *inta
vdev-msix[i].entry = i;
vdev-ev_msix[i] = ctx;
}
- if (!ret)
+ if (!ret) {
ret = pci_enable_msix(pdev, vdev-msix, nvec);
+ /*
+ The kernel is unable to allocate requested number of IRQs
+ and returned the available number.
+*/
+ if (0 ret) {
+ ret = pci_enable_msix(pdev, vdev-msix, ret);
+ }
+ }
vdev-msix_nvec = 0;
- for (i = 0; i nvec !ret; i++) {
- ret = request_irq(vdev-msix[i].vector, msihandler, 0,
- vfio, vdev-ev_msix[i]);
- if (ret)
- break;
- vdev-msix_nvec = i+1;
+ if (0 == ret) {
+ vdev-msix_nvec = 0;
+ ret = 0;
+ for (i = 0; i nvec !ret; i++) {
+ ret = request_irq(vdev-msix[i].vector, msihandler, 0,
+ vfio, vdev-ev_msix[i]);
+ if (ret)
+ break;
+ vdev-msix_nvec = i+1;
+ }
+ if ((0 == vdev-msix_nvec) (0 != ret))
+ vfio_pci_drop_msix(vdev);
+ else
+ ret = vdev-msix_nvec;
}
- if (ret)
- vfio_pci_drop_msix(vdev);
+
return ret;
}
=== end ===
QEMU patch:
diff --git a/hw/vfio_pci.c b/hw/vfio_pci.c
index 020961a..980eec7 100644
--- a/hw/vfio_pci.c
+++ b/hw/vfio_pci.c
@@ -341,7 +341,8 @@ static void vfio_enable_msi(VFIODevice *vdev, bool msix)
}
}
-if (ioctl(vdev-fd, VFIO_DEVICE_SET_IRQ_EVENTFDS, fds)) {
+ret = ioctl(vdev-fd, VFIO_DEVICE_SET_IRQ_EVENTFDS, fds);
+if (0 ret) {
fprintf(stderr, vfio: Error: Failed to setup MSI/X fds %s\n,
strerror(errno));
for (i = 0; i vdev-nr_vectors; i++) {
@@ -355,6 +356,8 @@ static void vfio_enable_msi(VFIODevice *vdev, bool msix)
qemu_free(vdev-msi_vectors);
vdev-nr_vectors = 0;
return;
+} else if (0 ret) {
+vdev-nr_vectors = ret;
}
vdev-interrupt = msix ? INT_MSIX : INT_MSI;
=== end ===
Re: [Qemu-devel] [PATCH] configure: Drop armv4l/armv4b distinction in $cpu
Am 29.11.2011 18:18, schrieb Peter Maydell: Drop the distinction between armv4l/armv4b in the $cpu variable (ie host cpu type) in favour of calling everything 'arm'. This makes it the same as the ARCH setting and removes some special casing. The only thing we were using the distinction for was to decide which endianness to use in cross compilation; do a cpp define check there instead. Signed-off-by: Peter Maydell peter.mayd...@linaro.org --- A minor cleanup because I got fed up with saying armv4b or armv4l. Nice! Reading armv4l on armv7l was pretty confusing at first. configure | 26 -- 1 files changed, 12 insertions(+), 14 deletions(-) diff --git a/configure b/configure index ac4840d..018bf23 100755 --- a/configure +++ b/configure @@ -287,10 +287,8 @@ elif check_define __s390__ ; then else cpu=s390 fi -elif check_define __ARMEB__ ; then - cpu=armv4b -elif check_define __ARMEL__ ; then - cpu=armv4l +elif check_define __arm__ ; then + cpu=arm elif check_define __hppa__ ; then cpu=hppa else @@ -307,11 +305,8 @@ case $cpu in x86_64|amd64) cpu=x86_64 ;; - armv*b) -cpu=armv4b - ;; - armv*l) -cpu=armv4l + armv*b|armv*l|arm) +cpu=arm ;; hppa|parisc|parisc64) cpu=hppa @@ -1243,7 +1238,13 @@ else # if cross compiling, cannot launch a program, so make a static guess case $cpu in - armv4b|hppa|m68k|mips|mips64|ppc|ppc64|s390|s390x|sparc|sparc64) + arm) +# ARM can be either way; ask the compiler which one we are +if check_define __ARMEB__; then + bigendian=yes +fi + ;; + hppa|m68k|mips|mips64|ppc|ppc64|s390|s390x|sparc|sparc64) bigendian=yes ;; esac @@ -2871,12 +2872,9 @@ echo docdir=$docdir $config_host_mak echo confdir=$confdir $config_host_mak case $cpu in - i386|x86_64|alpha|cris|hppa|ia64|lm32|m68k|microblaze|mips|mips64|ppc|ppc64|s390|s390x|sparc|sparc64|unicore32) + i386|x86_64|alpha|cris|hppa|ia64|lm32|m68k|microblaze|mips|mips64|ppc|ppc64|s390|s390x|sparc|sparc64|unicore32|arm) If you place arm between alpha and cris instead (alphabetical order except for i386+x86_64), Reviewed-by: Andreas Färber afaer...@suse.de Andreas ARCH=$cpu ;; - armv4b|armv4l) -ARCH=arm - ;; *) if test $tcg_interpreter = yes ; then echo Unsupported CPU = $cpu, will use TCG with TCI (experimental) -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
[Qemu-devel] [Bug 897750] Re: libvirt/kvm problem with disk attach/detach/reattach on running virt
(qemu) device_add driver=ne2k_pci,id=x
(qemu) device_del x
(qemu) device_add driver=ne2k_pci,id=x
Duplicate ID 'x' for device
It appears that drive_add/drive_del works fine, but device_del does not
fully delete its members.
This happens with today's git HEAD of qemu as well, in other words it
affects upstream.
** Also affects: qemu
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/897750
Title:
libvirt/kvm problem with disk attach/detach/reattach on running virt
Status in QEMU:
New
Status in “qemu-kvm” package in Ubuntu:
Confirmed
Bug description:
Release: Ubuntu 11.10 (Oneiric)
libvirt-bin: 0.9.2-4ubuntu15.1
qemu-kvm: 0.14.1+noroms-0ubuntu6
Summary:With a running KVM virt, performing an 'attach-disk', then a
'detach-disk', then another 'attach-disk'
in an attempt to reattach the volume at the same point on the virt, fails,
with the qemu reporting back to
libvirt a 'Duplicate ID' error.
Expected behavior: The 2nd invocation of 'attach-disk' should have succeeded
Actual behavior: Duplicate ID error reported
I believe this is most likely a qemu-kvm issue, as the DOM kvm spits back at
libvirt after the 'detach-disk'
does not show the just-detached disk. There is some kind of registry/lookup
for devices in qemu-kvm
and for whatever reason, the entry for the disk does not get removed when it
is detached from the
virt. Specifically, the error gets reported at the 2nd attach-disk attempt
from:
qemu-option.c:qemu_opts_create:697
684 QemuOpts *qemu_opts_create(QemuOptsList *list, const char *id, int
fail_if_exists)
685 {
686 QemuOpts *opts = NULL;
687
688 if (id) {
689 if (!id_wellformed(id)) {
690 qerror_report(QERR_INVALID_PARAMETER_VALUE, id, an
identifier);
691 error_printf_unless_qmp(Identifiers consist of letters,
digits, '-', '.', '_', starting with a letter.\n);
692 return NULL;
693 }
694 opts = qemu_opts_find(list, id);
695 if (opts != NULL) {
696 if (fail_if_exists) {
697 qerror_report(QERR_DUPLICATE_ID, id, list-name);
== HERE ===
698 return NULL;
699 } else {
700 return opts;
701 }
702 }
703 }
704 opts = qemu_mallocz(sizeof(*opts));
705 if (id) {
706 opts-id = qemu_strdup(id);
707 }
Re: [Qemu-devel] [PATCH] configure: Drop armv4l/armv4b distinction in $cpu
On 29 November 2011 19:26, Andreas Färber afaer...@suse.de wrote: If you place arm between alpha and cris instead (alphabetical order except for i386+x86_64), Reviewed-by: Andreas Färber afaer...@suse.de Doh, good point. Will send v2 tomorrow. -- PMM
Re: [Qemu-devel] [PATCH v8 0/2] PC system flash support
On Tue, Nov 29, 2011 at 01:38, Avi Kivity a...@redhat.com wrote: On 11/29/2011 09:03 AM, Jordan Justen wrote: On Mon, Nov 28, 2011 at 02:28, Avi Kivity a...@redhat.com wrote: On 11/28/2011 04:26 AM, Jordan Justen wrote: Enable flash emulation in a PC system using pflash_cfi01. The new memory layout should be made conditional on the machine type (-M pc-1.1 or later) to allow migration from/to pc-1.0 and earlier. Memory layout in this context are the names of memory ranges given to memory_region_init_ram(), sizes, and locations. Also, the flash interface should not be there for older machines. Is this the right way to go about it? 1. Create a new pc-sysfw qdev 2. Use a flash property in pc_piix.c to selectively enable the flash Or, is there an easier or better way to say pc pc-1.0? No idea, copying some qdev people. How do I enable migration from/to pc-1.0 and earlier? It seems like some code will need to shuttle the data (rom = pflash). Can you point me an an example? It should be completely transparent, so long as you instantiate a ROM for = pc-1.0 (say based on a property) and flash for = pc-1.1. One way to verify is to to 'info qdev' and 'info mtree' with qemu-1.0 and qemu-1.1 -M pc-1.0, and see that you get the same results. I think this means that I cannot add a pc-sysfw qdev for pc-1.0. (Even if the rom memory usage matches pc-1.0.) Is that right? If so, the plan I mentioned above would not work. In the plan above, a property of the pc-sysfw qdev would have determined if the old rom method would be used, or the newer flash method would be used. Thanks, -Jordan
Re: [Qemu-devel] [Xen-devel] [PATCH V5 06/10] pci.c: Add pci_check_bar_overlap
On Thu, Nov 24, 2011 at 05:44:35PM +, Anthony PERARD wrote:
From: Yuji Shimada shimada-...@necst.nec.co.jp
This function help Xen PCI Passthrough device to check for overlap.
helps
Signed-off-by: Yuji Shimada shimada-...@necst.nec.co.jp
Signed-off-by: Anthony PERARD anthony.per...@citrix.com
---
hw/pci.c | 47 +++
hw/pci.h |3 +++
2 files changed, 50 insertions(+), 0 deletions(-)
diff --git a/hw/pci.c b/hw/pci.c
index 399227f..563bb37 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -2038,3 +2038,50 @@ MemoryRegion *pci_address_space_io(PCIDevice *dev)
{
return dev-bus-address_space_io;
}
+
+int pci_check_bar_overlap(PCIDevice *dev,
+ pcibus_t addr, pcibus_t size, uint8_t type)
+{
+PCIBus *bus = dev-bus;
+PCIDevice *devices = NULL;
+PCIIORegion *r;
+int i, j;
+int rc = 0;
+
+/* check Overlapped to Base Address */
+for (i = 0; i ARRAY_SIZE(bus-devices); i++) {
+devices = bus-devices[i];
+if (!devices) {
+continue;
+}
+
+/* skip itself */
+if (devices-devfn == dev-devfn) {
+continue;
+}
+
+for (j = 0; j PCI_NUM_REGIONS; j++) {
+r = devices-io_regions[j];
+
+/* skip different resource type, but don't skip when
+ * prefetch and non-prefetch memory are compared.
+ */
+if (type != r-type) {
+if (type == PCI_BASE_ADDRESS_SPACE_IO ||
+r-type == PCI_BASE_ADDRESS_SPACE_IO) {
+continue;
+}
+}
+
+if ((addr (r-addr + r-size)) ((addr + size) r-addr)) {
+printf(Overlapped to device[%02x:%02x.%x][Region:%d]
+ [Address:%PRIx64h][Size:%PRIx64h]\n,
+ pci_bus_num(bus), PCI_SLOT(devices-devfn),
+ PCI_FUNC(devices-devfn), j, r-addr, r-size);
+rc = 1;
+}
+}
+}
+
+return rc;
+}
diff --git a/hw/pci.h b/hw/pci.h
index 625e717..9a723d2 100644
--- a/hw/pci.h
+++ b/hw/pci.h
@@ -552,4 +552,7 @@ static inline void pci_dma_sglist_init(QEMUSGList *qsg,
PCIDevice *dev,
qemu_sglist_init(qsg, alloc_hint);
}
+int pci_check_bar_overlap(PCIDevice *dev,
+ pcibus_t addr, pcibus_t size, uint8_t type);
+
#endif
--
Anthony PERARD
___
Xen-devel mailing list
xen-de...@lists.xensource.com
http://lists.xensource.com/xen-devel
[Qemu-devel] [PATCH] Guest stop notification
Often when a guest is stopped from the qemu console, it will report spurious
soft lockup warnings on resume. There are kernel patches being discussed that
will give the host the ability to tell the guest that it is being stopped and
should ignore the soft lockup warning that generates.
Signed-off-by: Eric B Munson emun...@mgebm.net
Cc: ry...@linux.vnet.ibm.com
Cc: aligu...@us.ibm.com
Cc: mtosa...@redhat.com
Cc: a...@redhat.com
Cc: k...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
---
target-i386/kvm.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index 5bfc21f..defd364 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -336,12 +336,18 @@ static int kvm_inject_mce_oldstyle(CPUState *env)
return 0;
}
+static void kvm_put_guest_paused(CPUState *penv)
+{
+kvm_vcpu_ioctl(penv, KVM_GUEST_PAUSED, 0);
+}
+
static void cpu_update_state(void *opaque, int running, RunState state)
{
CPUState *env = opaque;
if (running) {
env-tsc_valid = false;
+ kvm_put_guest_paused(env);
}
}
--
1.7.5.4
Re: [Qemu-devel] [PATCH] Guest stop notification
On 11/29/2011 03:36 PM, Eric B Munson wrote:
Often when a guest is stopped from the qemu console, it will report spurious
soft lockup warnings on resume. There are kernel patches being discussed that
will give the host the ability to tell the guest that it is being stopped and
should ignore the soft lockup warning that generates.
Signed-off-by: Eric B Munsonemun...@mgebm.net
Reviewed-by: Anthony Liguori aligu...@us.ibm.com
Regards,
Anthony Liguori
Cc: ry...@linux.vnet.ibm.com
Cc: aligu...@us.ibm.com
Cc: mtosa...@redhat.com
Cc: a...@redhat.com
Cc: k...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
---
target-i386/kvm.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index 5bfc21f..defd364 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -336,12 +336,18 @@ static int kvm_inject_mce_oldstyle(CPUState *env)
return 0;
}
+static void kvm_put_guest_paused(CPUState *penv)
+{
+kvm_vcpu_ioctl(penv, KVM_GUEST_PAUSED, 0);
+}
+
static void cpu_update_state(void *opaque, int running, RunState state)
{
CPUState *env = opaque;
if (running) {
env-tsc_valid = false;
+ kvm_put_guest_paused(env);
}
}
[Qemu-devel] [PATCH 2/2] Makefile: use full path for qapi-generated directory
Generally $(BUILD_DIR) == $(CURDIR), but that isn't necessarilly the case, so use $(BUILD_DIR)/qapi-generated for generated files to avoid potentionally sticking generating files in odd places outside the build's include paths. --- Makefile |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Makefile b/Makefile index 168093c..0b4b2c3 100644 --- a/Makefile +++ b/Makefile @@ -167,7 +167,7 @@ check-qjson: check-qjson.o $(qobject-obj-y) $(tools-obj-y) test-coroutine: test-coroutine.o qemu-timer-common.o async.o $(coroutine-obj-y) $(tools-obj-y) $(qapi-obj-y): $(GENERATED_HEADERS) -qapi-dir := qapi-generated +qapi-dir := $(BUILD_DIR)/qapi-generated test-visitor.o test-qmp-commands.o qemu-ga$(EXESUF): QEMU_CFLAGS += -I $(qapi-dir) qemu-ga$(EXESUF): LIBS = $(LIBS_QGA) -- 1.7.4.1
[Qemu-devel] [PATCH 1/2] qapi: fix guardname generation
Fix a bug in handling dotted paths, and exclude directory prefixes
from generated guardnames to avoid odd/pseudo-random guardnames in
generated headers.
---
scripts/qapi.py |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/scripts/qapi.py b/scripts/qapi.py
index 5299976..6e05469 100644
--- a/scripts/qapi.py
+++ b/scripts/qapi.py
@@ -200,6 +200,7 @@ def basename(filename):
return filename.split(/)[-1]
def guardname(filename):
-if filename.startswith('./'):
-filename = filename[2:]
-return filename.replace(/, _).replace(-, _).split(.)[0].upper()
+ '_H'
+guard = basename(filename).rsplit(., 1)[0]
+for substr in [., , -]:
+guard = guard.replace(substr, _)
+return guard.upper() + '_H'
--
1.7.4.1
Re: [Qemu-devel] KVM call minutes for November 29
On 11/29/2011 10:59 AM, Avi Kivity wrote: On 11/29/2011 05:51 PM, Juan Quintela wrote: How to do high level stuff? - python? One of the disadvantages of the various scripting languages is the lack of static type checking, which makes it harder to do full sweeps of the source for API changes, relying on the compiler to catch type (or other) errors. This is less interesting to me (figuring out the perfectest language to use). I think what's more interesting is the practical execution of something like this. Just assuming we used python (since that's what I know best), I think we could do something like this: 1) We could write a binding layer to expose the QMP interface as a python module. This would be very little binding code but would bring a bunch of functionality to python bits. 2) We could then add a binding layer to let python code implement a character device. 3) We could implement the HMP logic in Python. 4) We could add a GTK widget to replace the SDL displaystate and then use python code to implement a more friendly UI. Most of the interaction with such an interface would probably go through (1). With clever coding, you could probably let the UI also be stand alone using GtkVnc in place of the builtin widget and using a remote interface for QMP. Regards, Anthony Liguori On the other hand, the statically typed languages usually have more boilerplate. Since one of the goals is to simplify things, this indicates the need for a language with type inference. On the third hand, languages with type inferences are still immature (golang?), so we probably need to keep this discussion going until an obvious choice presents itself.
Re: [Qemu-devel] [RFC PATCH] vfio: VFIO Driver core framework
BTW, github now has updated trees: git://github.com/awilliam/linux-vfio.git vfio-next-2029 git://github.com/awilliam/qemu-vfio.git vfio-ng Hi Alex, Have been looking at vfio a bit. A few observations and things we'll need to figure out as it relates to the Freescale iommu. __vfio_dma_map() assumes that mappings are broken into 4KB pages. That will not be true for us. We normally will be mapping much larger physically contiguous chunks for our guests. Guests will get hugetlbfs backed memory with very large pages (e.g. 16MB, 64MB) or very large chunks allocated by some proprietary means. Also, mappings will have additional Freescale-specific attributes that need to get passed through to dma_map somehow. For example, the iommu can stash directly into a CPU's cache and we have iommu mapping properties like the cache stash target id and an operation mapping attribute. How do you envision handling proprietary attributes in struct vfio_dma_map? Stuart
Re: [Qemu-devel] [RFC PATCH] vfio: VFIO Driver core framework
On Tue, 2011-11-29 at 17:20 -0600, Stuart Yoder wrote: BTW, github now has updated trees: git://github.com/awilliam/linux-vfio.git vfio-next-2029 git://github.com/awilliam/qemu-vfio.git vfio-ng Hi Alex, Have been looking at vfio a bit. A few observations and things we'll need to figure out as it relates to the Freescale iommu. __vfio_dma_map() assumes that mappings are broken into 4KB pages. That will not be true for us. We normally will be mapping much larger physically contiguous chunks for our guests. Guests will get hugetlbfs backed memory with very large pages (e.g. 16MB, 64MB) or very large chunks allocated by some proprietary means. Hi Stuart, I think practically everyone has commented on the 4k mappings ;) There are a few problems around this. The first is that iommu drivers don't necessarily support sub-region unmapping, so if we map 1GB and later want to unmap 4k, we can't do it atomically. 4k gives us the most flexibility for supporting fine granularities. Another problem is that we're using get_user_pages to pin memory. It's been suggested that we should use mlock for this, but I can't find anything that prevents a user from later munlock'ing the memory and then getting access to memory they shouldn't have. Those kind of limit us, but I don't see it being an API problem for VFIO, just implementation. Also, mappings will have additional Freescale-specific attributes that need to get passed through to dma_map somehow. For example, the iommu can stash directly into a CPU's cache and we have iommu mapping properties like the cache stash target id and an operation mapping attribute. How do you envision handling proprietary attributes in struct vfio_dma_map? Let me turn the question around, how do you plan to support proprietary attributes in the IOMMU API? Is the user level the appropriate place to specify them, or are they an intrinsic feature of the domain? We've designed struct vfio_dma_map for extension, so depending on how many bits you need, we can make a conduit using the flags directly or setting a new flag to indicate presence of an arch specific attributes field. Thanks, Alex
Re: [Qemu-devel] [PATCH 2/3] raw-posix: Do not use CONFIG_COCOA macro
Am 10.11.2011 19:40, schrieb Pavel Borzenkov:
Use __APPLE__ and __MACH__ macros instead of CONFIG_COCOA to detect Mac
OS X host. The patch is based on the Ben Leslie's patch:
http://patchwork.ozlabs.org/patch/97859/
Signed-off-by: Pavel Borzenkov pavel.borzen...@gmail.com
Reviewed-by: Andreas Färber andreas.faer...@web.de
Still in my queue for testing on a Mac though.
Andreas
---
block/raw-posix.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/block/raw-posix.c b/block/raw-posix.c
index 17e1c6f..ee08f80 100644
--- a/block/raw-posix.c
+++ b/block/raw-posix.c
@@ -29,7 +29,7 @@
#include module.h
#include block/raw-posix-aio.h
-#ifdef CONFIG_COCOA
+#if defined(__APPLE__) (__MACH__)
#include paths.h
#include sys/param.h
#include IOKit/IOKitLib.h
@@ -487,7 +487,7 @@ again:
}
if (size == 0)
#endif
-#ifdef CONFIG_COCOA
+#if defined(__APPLE__) defined(__MACH__)
size = LONG_LONG_MAX;
#else
size = lseek(fd, 0LL, SEEK_END);
@@ -632,7 +632,7 @@ static BlockDriver bdrv_file = {
/***/
/* host device */
-#ifdef CONFIG_COCOA
+#if defined(__APPLE__) defined(__MACH__)
static kern_return_t FindEjectableCDMedia( io_iterator_t *mediaIterator );
static kern_return_t GetBSDPath( io_iterator_t mediaIterator, char *bsdPath,
CFIndex maxPathSize );
@@ -710,7 +710,7 @@ static int hdev_open(BlockDriverState *bs, const char
*filename, int flags)
{
BDRVRawState *s = bs-opaque;
-#ifdef CONFIG_COCOA
+#if defined(__APPLE__) defined(__MACH__)
if (strstart(filename, /dev/cdrom, NULL)) {
kern_return_t kernResult;
io_iterator_t mediaIterator;
[Qemu-devel] SEMPRE MAIS
Caso não visualize esse email adequadamente VIEW_LINK http://infomaisnet1.enviodenews.com/ver_mensagem.php?id=H|2149|75271|13300584354600acesse este link[/VIEW_LINK] Se você não deseja mais receber nossos e-mails, cancele sua inscrição através do link http://infomaisnet1.enviodenews.com/admin/sair.php?id=75271|2149|0uid=13300584354600
[Qemu-devel] [BUG] [Seabios] PCI 64bit BARs on Win2008 - unable to start the device. (ACPI lacks the _DSM method)
Hi, We have got some issues with 64bit PCI devices support under Windows guests. Windows fails to start any PCI devices with 64bit BARs when size exceeds 512MB with error code 12 (can't allocate resources). In other words it fails when the PCI memory region is located above 4GB. I tried to investigate this problem and found document from Microsoft: http://msdn.microsoft.com/en-us/windows/hardware/gg462986 It states that the _DSM method must be implemented to support devices above 4GB. Unfortunately I'm not familiar with ACPI code of seabios, so can't implement the _DSM method. May be you have other ideas what needs to be done to fix it? Any help is appreciated. Thanks, Alexey
Re: [Qemu-devel] KVM call minutes for November 29
Markus Armbruster arm...@redhat.com wrote: Avi Kivity a...@redhat.com writes: On 11/29/2011 05:51 PM, Juan Quintela wrote: How to do high level stuff? - python? One of the disadvantages of the various scripting languages is the lack of static type checking, which makes it harder to do full sweeps of the source for API changes, relying on the compiler to catch type (or other) errors. On the other hand, the statically typed languages usually have more boilerplate. Since one of the goals is to simplify things, this indicates the need for a language with type inference. On the third hand, languages with type inferences are still immature (golang?), so we probably need to keep this discussion going until an obvious choice presents itself. I wouldn't call ML immature. But I wouldn't call it a scripting language, either. ocaml (Standard ML is a big monster) is not inmature. But depending on how much we want to implement on it, its integral types are not very good. - no unsigned types - signed types are 31 and 63 bits wide, sniff. And its object system is .. bizarre? On the other side, inference is quite understable, and its type inference works pretty well. And doing stubs with * is tedious, but not difficult at all. Later, Juan.
Re: [Qemu-devel] [ICON] My name is Q, Q Emu!
* The nostril is Yin-shaped; the matching Yang would be KVM or Xen. :) Hey, you know Yin-Yang! XD But, there should be a Yang spot in the Yin-shape. I'm just too picky. :p http://en.wikipedia.org/wiki/Taiji 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
[Qemu-devel] [PATCH V3 0/4] i.MX31 and KZM board support
Changes since last patchset: * All files now under GPL version 2 or later (I've talked with OK-Labs and they've agreed). * `DPRINTF' like macro for printing out guest kernel and qemu implementation errors * Fixed bugs in avic implementation, as found by PMM * Use a static initialiser and sysbus_register_withprop() instead of calls to sysbus_register() adn vmstate_register() * Fixed bugs in imx_timer.c as noted by PMM and Andreas -- Dr Peter Chubb http://www.gelato.unsw.edu.au peterc AT gelato.unsw.edu.au http://www.ertos.nicta.com.au ERTOS within National ICT Australia
[Qemu-devel] [PATCH V3 4/4] Board support for Kyoto Micros KZM-ARM11-01, an evaluation board built around the FreeScale i.MX31.
Signed-off-by: Hans Jang hsj...@ok-labs.com
Signed-off-by: Adam Clench ad...@ok-labs.com
Signed-off-by: Peter Chubb peter.ch...@nicta.com.au
---
Makefile.target |1
hw/kzm.c| 155
2 files changed, 156 insertions(+)
create mode 100644 hw/kzm.c
Index: qemu-working/hw/kzm.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ qemu-working/hw/kzm.c 2011-11-30 13:38:28.210797633 +1100
@@ -0,0 +1,155 @@
+/*
+ * KZM Board System emulation.
+ *
+ * Copyright (c) 2008 OKL and 2011 NICTA
+ * Written by Hans
+ * Updated by Peter Chubb.
+ *
+ * This code is licenced under the GPL, version 2 or later.
+ *
+ * It (partially) emulates a Kyoto Microcomputer
+ * KZM-ARM11-01 evaluation board, with a FreeScale
+ * I.MX31 SoC
+ */
+
+#include sysbus.h
+#include exec-memory.h
+#include hw.h
+#include arm-misc.h
+#include primecell.h
+#include devices.h
+#include pci.h
+#include net.h
+#include sysemu.h
+#include boards.h
+#include pc.h /* for the FPGA UART that emulates a 16550 */
+
+/* Memory map for Kzm Emulation Baseboard:
+ * 0x-0x3fff 16k secure ROM IGNORED
+ * 0x4000-0x00407fff Reserved IGNORED
+ * 0x00404000-0x00407fff ROM IGNORED
+ * 0x00408000-0x0fff Reserved IGNORED
+ * 0x1000-0x1fffBfff RAM aliasing IGNORED
+ * 0x1fffc000-0x1fff RAM EMULATED
+ * 0x2000-0x2fff Reserved IGNORED
+ * 0x3000-0x7fff I.MX31 Internal Register Space
+ * 0x43f0 IO_AREA0
+ * 0x43f9 UART1 EMULATED
+ * 0x43f94000 UART2 EMULATED
+ * 0x6800 PIC EMULATED
+ * 0x53f94000 PIT 1 EMULATED
+ * 0x53f98000 PIT 2 EMULATED
+ * 0x53f9 GPT EMULATED
+ * 0x8000-0x87ff RAM EMULATED
+ * 0x8800-0x8fff RAM Aliasing EMULATED
+ * 0xa000-0xafff NAND Flash IGNORED
+ * 0xb000-0xb3ff Unavailable IGNORED
+ * 0xb400-0xb4000fff 8-bit free space IGNORED
+ * 0xb4001000-0xb400100f Board controlIGNORED
+ * 0xb4001003 DIP switch
+ * 0xb4001010-0xb400101f 7-segment LEDIGNORED
+ * 0xb4001020-0xb400102f LED IGNORED
+ * 0xb4001030-0xb400103f LED IGNORED
+ * 0xb4001040-0xb400104f FPGA, UART EMULATED
+ * 0xb4001050-0xb400105f FPGA, UART EMULATED
+ * 0xb4001060-0xb40f FPGA IGNORED
+ * 0xb600-0xb61f LAN controller EMULATED
+ * 0xb620-0xb62f FPGA NAND Controller IGNORED
+ * 0xb630-0xb7ff Free IGNORED
+ * 0xb800-0xb8004fff Memory control registers IGNORED
+ * 0xc000-0xc3ff PCMCIA/CFIGNORED
+ * 0xc400-0x Reserved IGNORED
+ */
+
+#define KZM_RAMADDRESS (0x8000)
+#define KZM_FPGA (0xb4001040)
+
+static struct arm_boot_info kzm_binfo = {
+.loader_start = KZM_RAMADDRESS,
+.board_id = 1722,
+};
+
+static void kzm_init(ram_addr_t ram_size,
+ const char *boot_device,
+ const char *kernel_filename, const char *kernel_cmdline,
+ const char *initrd_filename, const char *cpu_model)
+{
+CPUState *env;
+MemoryRegion *address_space_mem = get_system_memory();
+MemoryRegion *ram = g_new(MemoryRegion, 1);
+MemoryRegion *sram = g_new(MemoryRegion, 1);
+MemoryRegion *ram_alias = g_new(MemoryRegion, 1);
+qemu_irq *cpu_pic;
+DeviceState *dev;
+
+if (!cpu_model) {
+cpu_model = arm1136;
+}
+
+env = cpu_init(cpu_model);
+if (!env) {
+fprintf(stderr, Unable to find CPU definition\n);
+exit(1);
+}
+
+/* On a real system, the first 16k is a `secure boot rom' */
+
+memory_region_init_ram(ram, NULL, kzm.ram, ram_size);
+memory_region_add_subregion(address_space_mem, KZM_RAMADDRESS, ram);
+
+memory_region_init_alias(ram_alias, ram.alias, ram, 0, ram_size);
+memory_region_add_subregion(address_space_mem, 0x8800, ram_alias);
+
+memory_region_init_ram(sram, NULL, kzm.sram, 0x4000);
+memory_region_add_subregion(address_space_mem, 0x1FFFC000, sram);
+
+
+cpu_pic = arm_pic_init_cpu(env);
+dev = sysbus_create_varargs(imx_int, 0x6800,
+ cpu_pic[ARM_PIC_CPU_IRQ],
+ cpu_pic[ARM_PIC_CPU_FIQ], NULL);
+
+
+sysbus_create_simple(imx_serial, 0x43f9, qdev_get_gpio_in(dev, 45));
+sysbus_create_simple(imx_serial, 0x43f94000, qdev_get_gpio_in(dev, 32));
+sysbus_create_simple(imx_timerp, 0x53f94000,
[Qemu-devel] [PATCH V3 3/4] Implement the FreeSCALE i.MX31 advanced vectored interrupt controller, at least to the extent it is used by Linux 3.0.x
Signed-off-by: Hans Jang hsj...@ok-labs.com
Signed-off-by: Adam Clench ad...@ok-labs.com
Signed-off-by: Peter Chubb peter.ch...@nicta.com.au
---
Makefile.target |2
hw/imx_avic.c | 378
2 files changed, 379 insertions(+), 1 deletion(-)
create mode 100644 hw/imx_avic.c
Index: qemu-working/hw/imx_avic.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ qemu-working/hw/imx_avic.c 2011-11-30 13:38:27.070791665 +1100
@@ -0,0 +1,378 @@
+/*
+ * IMX31 Vectored Interrupt Controller
+ *
+ * Note this is NOT the PL192 provided by ARM, but
+ * a custom implementation by FreeScale.
+ *
+ * Copyright (c) 2008 OKL
+ * Copyright (c) 2011 NICTA Pty Ltd
+ * Originally Written by Hans Jiang
+ *
+ * This code is licenced under the GPL version 2 or later. See
+ * the COPYING file in the top-level directory.
+ *
+ * TODO: implement vectors and priorities.
+ */
+
+#include hw.h
+#include sysbus.h
+#include host-utils.h
+
+#define DEBUG_INT 1
+#undef DEBUG_INT /* comment out for debugging */
+
+#ifdef DEBUG_INT
+#define DPRINTF(fmt, args...) \
+do { printf(imx_avic: fmt , ##args); } while (0)
+#else
+#define DPRINTF(fmt, args...) do {} while (0)
+#endif
+
+/*
+ * Define to 1 for messages about attempts to
+ * access unimplemented registers or similar.
+ */
+#define DEBUG_IMPLEMENTATION 1
+#if DEBUG_IMPLEMENTATION
+# define IPRINTF(fmt, args...) \
+do { fprintf(stderr, imx_avic: fmt, ##args); } while (0)
+#else
+# define IPRINTF(fmt, args...) do {} while (0)
+#endif
+
+#define IMX_INT_NUM_IRQS 64
+
+/* Interrupt Control Bits */
+#define ABFLAG (125)
+#define ABFEN (124)
+#define NIDIS (122) /* Normal Interrupt disable */
+#define FIDIS (121) /* Fast interrupt disable */
+#define NIAD (120) /* Normal Interrupt Arbiter Rise ARM level */
+#define FIAD (119) /* Fast Interrupt Arbiter Rise ARM level */
+#define NM(118) /* Normal interrupt mode */
+
+
+#define PRIO_PER_WORD (sizeof(uint32_t) * 8 / 4)
+#define PRIO_WORDS (IMX_INT_NUM_IRQS/PRIO_PER_WORD)
+
+typedef struct {
+SysBusDevice busdev;
+MemoryRegion iomem;
+uint64_t pending;
+uint64_t enabled;
+uint64_t is_fiq;
+uint32_t intcntl;
+uint32_t intmask;
+qemu_irq irq;
+qemu_irq fiq;
+uint32_t prio[PRIO_WORDS]; /* Priorities are 4-bits each */
+} imx_int_state;
+
+static const VMStateDescription vmstate_imx_avic = {
+.name = imx-avic,
+.version_id = 1,
+.minimum_version_id = 1,
+.minimum_version_id_old = 1,
+.fields = (VMStateField[]) {
+VMSTATE_UINT64(pending, imx_int_state),
+VMSTATE_UINT64(enabled, imx_int_state),
+VMSTATE_UINT64(is_fiq, imx_int_state),
+VMSTATE_UINT32(intcntl, imx_int_state),
+VMSTATE_UINT32(intmask, imx_int_state),
+VMSTATE_UINT32_ARRAY(prio, imx_int_state, PRIO_WORDS),
+VMSTATE_END_OF_LIST()
+},
+};
+
+
+
+static inline int imx_int_prio(imx_int_state *s, int irq)
+{
+uint32_t word = irq / PRIO_PER_WORD;
+uint32_t part = 4 * (irq % PRIO_PER_WORD);
+return 0xf (s-prio[word] part);
+}
+
+static inline void imx_int_set_prio(imx_int_state *s, int irq, int prio)
+{
+uint32_t word = irq / PRIO_PER_WORD;
+uint32_t part = 4 * (irq % PRIO_PER_WORD);
+uint32_t mask = ~(0xf part);
+s-prio[word] = mask;
+s-prio[word] |= prio part;
+}
+
+/* Update interrupts. */
+static void imx_int_update(imx_int_state *s)
+{
+int i;
+uint64_t new = s-pending;
+uint64_t flags;
+
+flags = new s-enabled s-is_fiq;
+qemu_set_irq(s-fiq, !!flags);
+
+flags = new s-enabled ~s-is_fiq;
+if (!flags || (s-intmask == 0x1f)) {
+qemu_set_irq(s-irq, !!flags);
+return;
+}
+
+/*
+ * Take interrupt if prio lower than the value of intmask
+ * (should really take highest priority interrupt here,
+ * but that would involve processing interrupt sources
+ * in priority order)
+ */
+for (i = 0; i IMX_INT_NUM_IRQS; i++) {
+if (flags (1UL i)) {
+if (imx_int_prio(s, i) s-intmask) {
+qemu_set_irq(s-irq, 1);
+return;
+}
+}
+}
+qemu_set_irq(s-irq, 0);
+}
+
+static void imx_int_set_irq(void *opaque, int irq, int level)
+{
+imx_int_state *s = (imx_int_state *)opaque;
+
+if (level) {
+s-pending |= (1ULL irq);
+} else {
+s-pending = ~(1ULL irq);
+}
+
+imx_int_update(s);
+}
+
+
+static uint64_t imx_int_read(void *opaque,
+ target_phys_addr_t offset, unsigned size)
+{
+imx_int_state *s = (imx_int_state *)opaque;
+
+
+DPRINTF(read(offset = 0x%x)\n, offset 2);
+switch (offset 2) {
+case 0: /* INTCNTL */
+return s-intcntl;
+
+case 1: /* Normal Interrupt Mask Register, NIMASK */
+return s-intmask;
+
+case 2: /* Interrupt Enable Number Register, INTENNUM
[Qemu-devel] [PATCH V3 2/4] Implement the timers on the FreeScale i.MX31 SoC. This is not a complete implementation, but gives enough for Linux to boot and run.
Signed-off-by: Hans Jang hsj...@ok-labs.com
Signed-off-by: Adam Clench ad...@ok-labs.com
Signed-off-by: Peter Chubb peter.ch...@nicta.com.au
---
Makefile.target |2
hw/imx_timer.c | 460
2 files changed, 461 insertions(+), 1 deletion(-)
create mode 100644 hw/imx_timer.c
Index: qemu-working/hw/imx_timer.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ qemu-working/hw/imx_timer.c 2011-11-30 13:38:25.818785258 +1100
@@ -0,0 +1,460 @@
+/*
+ * IMX31 Timer
+ *
+ * Copyright (c) 2008 OKL
+ * Copyright (c) 2011 NICTA Pty Ltd
+ * Originally Written by Hans Jiang
+ * Updated by Peter Chubb
+ *
+ * This code is licenced under GPL version 2 or later. See
+ * the COPYING file in the top-level directory.
+ */
+
+#include hw.h
+#include qemu-timer.h
+#include sysbus.h
+
+//#define DEBUG_TIMER 1
+
+#ifdef DEBUG_TIMER
+# define DPRINTF(fmt, args...) \
+do { printf(imx_timer: fmt , ##args); } while (0)
+#else
+# define DPRINTF(fmt, args...) do {} while (0)
+#endif
+
+/*
+ * Define to 1 for messages about attempts to
+ * access unimplemented registers or similar.
+ */
+#define DEBUG_IMPLEMENTATION 1
+#if DEBUG_IMPLEMENTATION
+# define IPRINTF(fmt, args...) \
+do { fprintf(stderr, imx_timer: fmt, ##args); } while (0)
+#else
+# define IPRINTF(fmt, args...) do {} while (0)
+#endif
+
+/*
+ * GPT : General purpose timer
+ */
+
+#define TIMER_MAX 0xUL
+#define GPT_FREQ 5000/* Hz == 50 MHz */
+
+/* Control register. Not all of these bits have any effect (yet) */
+#define GPT_CR_EN (1 0)/* GPT Enable */
+#define GPT_CR_ENMODE (1 1) /* GPT Enable Mode */
+#define GPT_CR_DBGEN (1 2) /* GPT Debug mode enable */
+#define GPT_CR_WAITEN (1 3) /* GPT Wait Mode Enable */
+#define GPT_CR_DOZEN (1 4) /* GPT Doze mode enable */
+#define GPT_CR_STOPEN (1 5) /* GPT Stop Mode Enable */
+#define GPT_CR_CLKSRC (7 6) /* Clock source select (3 bits) */
+#define GPT_CR_FRR (1 9)/* Freerun or Restart */
+#define GPT_CR_SWR (1 15)
+#define GPT_CR_IM1 (3 16) /* Input capture channel 1 mode (2 bits) */
+#define GPT_CR_IM2 (3 18) /* Input capture channel 2 mode (2 bits) */
+#define GPT_CR_OM1 (7 20) /* Output Compare Channel 1 Mode (3 bits) */
+#define GPT_CR_OM2 (7 23) /* Output Compare Channel 2 Mode (3 bits) */
+#define GPT_CR_OM3 (7 26) /* Output Compare Channel 3 Mode (3 bits) */
+#define GPT_CR_FO1 (1 29) /* Force Output Compare Channel 1 */
+#define GPT_CR_FO2 (1 30) /* Force Output Compare Channel 2 */
+#define GPT_CR_FO3 (1 31) /* Force Output Compare Channel 3 */
+
+#define GPT_SR_OF1 (1 0)
+#define GPT_SR_ROV (1 5)
+
+#define GPT_IR_OF1IE (1 0)
+#define GPT_IR_ROVIE (1 5)
+
+typedef struct {
+SysBusDevice busdev;
+QEMUTimer *timer;
+MemoryRegion iomem;
+uint32_t cr;
+uint32_t sr;
+uint32_t pr;
+uint32_t ir;
+uint32_t ocr1;
+uint32_t cnt;
+
+int waiting_rov;
+qemu_irq irq;
+} imxg_timer_state;
+
+static const VMStateDescription vmstate_imxg_timer = {
+.name = imxg-timer,
+.version_id = 1,
+.minimum_version_id = 1,
+.minimum_version_id_old = 1,
+.fields = (VMStateField[]) {
+VMSTATE_UINT32(cr, imxg_timer_state),
+VMSTATE_UINT32(sr, imxg_timer_state),
+VMSTATE_UINT32(ir, imxg_timer_state),
+VMSTATE_UINT32(cnt, imxg_timer_state),
+VMSTATE_UINT32(ocr1, imxg_timer_state),
+VMSTATE_TIMER(timer, imxg_timer_state),
+VMSTATE_END_OF_LIST()
+}
+};
+
+
+/* Check all active timers, and schedule the next timer interrupt. */
+static void imxg_timer_update(imxg_timer_state *s)
+{
+uint32_t flags = s-sr s-ir (GPT_SR_OF1 | GPT_SR_ROV);
+
+if ((s-cr GPT_CR_EN) flags) {
+qemu_irq_raise(s-irq);
+} else {
+qemu_irq_lower(s-irq);
+}
+}
+
+static uint64_t imxg_timer_update_count(imxg_timer_state *s)
+{
+uint64_t clk = qemu_get_clock_ns(vm_clock);
+
+s-cnt = ((uint32_t)muldiv64(clk, GPT_FREQ/100,
+ 1000)) % TIMER_MAX;
+return clk;
+}
+
+static void imxg_timer_run(imxg_timer_state *s, uint32_t timeout)
+{
+uint64_t clk = imxg_timer_update_count(s);
+uint32_t diff_cnt;
+if (s-cnt timeout) {
+diff_cnt = (timeout - s-cnt);
+s-waiting_rov = 0;
+} else {
+diff_cnt = (TIMER_MAX - s-cnt);
+s-waiting_rov = 1;
+}
+qemu_mod_timer(s-timer, clk + diff_cnt * 1000 / (GPT_FREQ/100));
+}
+
+static uint64_t imxg_timer_read(void *opaque, target_phys_addr_t offset,
+unsigned size)
+{
+imxg_timer_state *s = (imxg_timer_state *)opaque;
+
+DPRINTF(g-read(offset=%x)\n, offset 2);
+switch (offset 2) {
+case 0: /* CR */
+return s-cr;
+
+case 1: /* prescaler */
+return s-pr;
+
+case 2:
+return
[Qemu-devel] [PATCH V3 1/4] Implement the FreeScale i.MX UART. This uart is used in a variety of SoCs, including some by Motorola, as well as in the FreeScale i.MX series.
Signed-off-by: Hans Jang hsj...@ok-labs.com
Signed-off-by: Adam Clench ad...@ok-labs.com
Signed-off-by: Peter Chubb peter.ch...@nicta.com.au
---
Makefile.target |1
hw/imx_serial.c | 320
2 files changed, 321 insertions(+)
create mode 100644 hw/imx_serial.c
Index: qemu-working/hw/imx_serial.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ qemu-working/hw/imx_serial.c2011-11-30 13:38:24.434778115 +1100
@@ -0,0 +1,320 @@
+/*
+ * IMX31 UARTS
+ *
+ * Copyright (c) 2008 OKL
+ * Originally Written by Hans Jiang
+ * Copyright (c) 2011 NICTA Pty Ltd.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2. See
+ * the COPYING file in the top-level directory.
+ *
+ * This is a `bare-bones' implementation of the IMX series serial ports.
+ * TODO:
+ * -- implement FIFOs. The real hardware has 32 word transmit
+ * and receive FIFOs; we currently use a 1-char buffer
+ * -- implement DMA
+ * -- implement BAUD-rate and modem lines, for when the backend
+ * is a real serial device.
+ */
+
+#include hw.h
+#include sysbus.h
+#include qemu-char.h
+
+//#define DEBUG_SERIAL 1
+
+#ifdef DEBUG_SERIAL
+#define DPRINTF(fmt, args...) \
+do { printf(imx_serial: fmt , ##args); } while (0)
+#else
+#define DPRINTF(fmt, args...) do {} while (0)
+#endif
+
+/*
+ * Define to 1 for messages about attempts to
+ * access unimplemented registers or similar.
+ */
+#define DEBUG_IMPLEMENTATION 1
+#if DEBUG_IMPLEMENTATION
+# define IPRINTF(fmt, args...) \
+do { fprintf(stderr, imx_serial: fmt, ##args); } while (0)
+#else
+# define IPRINTF(fmt, args...) do {} while (0)
+#endif
+
+typedef struct {
+SysBusDevice busdev;
+MemoryRegion iomem;
+int32_t readbuff;
+
+uint32_t usr1;
+uint32_t usr2;
+uint32_t ucr1;
+uint32_t uts1;
+
+uint32_t ubrm;
+uint32_t ubrc;
+
+qemu_irq irq;
+CharDriverState *chr;
+} imx_state;
+
+static const VMStateDescription vmstate_imx_serial = {
+.name = imx-serial,
+.version_id = 1,
+.minimum_version_id = 1,
+.minimum_version_id_old = 1,
+.fields = (VMStateField[]) {
+VMSTATE_INT32(readbuff, imx_state),
+VMSTATE_UINT32(usr1, imx_state),
+VMSTATE_UINT32(usr2, imx_state),
+VMSTATE_UINT32(ucr1, imx_state),
+VMSTATE_UINT32(uts1, imx_state),
+VMSTATE_UINT32(ubrm, imx_state),
+VMSTATE_UINT32(ubrc, imx_state),
+VMSTATE_END_OF_LIST()
+},
+};
+
+
+#define URXD_CHARRDY(115) /* character read is valid */
+
+#define USR1_TRDY (113) /* Xmitter ready */
+#define USR1_RRDY (19)/* receiver ready */
+
+#define USR2_TXFE (114) /* Transmit FIFO empty */
+#define USR2_TXDC (13)/* Transmission complete */
+#define USR2_RDR(10)/* Receive data ready */
+
+#define UCR1_TRDYEN (113)
+#define UCR1_RRDYEN (19)
+#define UCR1_TXMPTYEN (16)
+#define UCR1_UARTEN (10)
+
+#define UTS1_TXEMPTY(16)
+#define UTS1_RXEMPTY(15)
+#define UTS1_TXFULL (14)
+#define UTS1_RXFULL (13)
+
+static void imx_update(imx_state *s)
+{
+uint32_t flags;
+
+flags = ((s-usr1 s-ucr1)) (USR1_TRDY|USR1_RRDY);
+if (!(s-ucr1 UCR1_TXMPTYEN)) {
+flags = ~USR1_TRDY;
+}
+
+if (flags) {
+DPRINTF(imx_serial: raising interrupt\n);
+}
+
+qemu_set_irq(s-irq, !!flags);
+}
+
+static void imx_serial_reset(DeviceState *dev)
+{
+imx_state *s = container_of(dev, imx_state, busdev.qdev);
+
+s-usr1 = USR1_TRDY;
+s-usr2 = USR2_TXFE | USR2_TXDC;
+s-uts1 = UTS1_RXEMPTY | UTS1_TXEMPTY;
+s-ubrm = 0;
+s-ubrc = 0;
+s-readbuff = 0;
+
+imx_update(s);
+}
+
+static uint64_t imx_serial_read(void *opaque, target_phys_addr_t offset,
+unsigned size)
+{
+imx_state *s = (imx_state *)opaque;
+uint32_t c;
+
+DPRINTF(read(offset=%x)\n, offset 2);
+switch (offset 2) {
+case 0x0: /* URXD */
+c = s-readbuff;
+if (!(s-uts1 UTS1_RXEMPTY)) {
+/* Character is valid */
+c |= URXD_CHARRDY;
+s-usr1 = ~USR1_RRDY;
+s-usr2 = ~USR2_RDR;
+s-uts1 |= UTS1_RXEMPTY;
+imx_update(s);
+qemu_chr_accept_input(s-chr);
+}
+return c;
+
+case 0x20: /* UCR1 */
+return s-ucr1;
+
+case 0x21: /* UCR2 */
+return 1; /* reset complete */
+
+case 0x25: /* USR1 */
+return s-usr1;
+
+case 0x26: /* USR2 */
+return s-usr2;
+
+case 0x2A: /* BRM Modulator */
+return s-ubrm;
+
+case 0x2B: /* Baud Rate Count */
+return s-ubrc;
+
+case 0x2d: /* UTS1 */
+return s-uts1;
+
+case 0x22: /* UCR3 */
+case 0x23: /* UCR4 */
+case 0x24: /* UFCR */
+case 0x29: /* BRM Incremental */
+return 0x0; /* TODO */
+
+
Re: [Qemu-devel] [PATCH 0/4] KVM: Dirty logging optimization using rmap
CCing qemu devel, Juan, (2011/11/29 23:03), Avi Kivity wrote: On 11/29/2011 02:01 PM, Avi Kivity wrote: On 11/29/2011 01:56 PM, Xiao Guangrong wrote: On 11/29/2011 07:20 PM, Avi Kivity wrote: We used to have a bitmap in a shadow page with a bit set for every slot pointed to by the page. If we extend this to non-leaf pages (so, when we set a bit, we propagate it through its parent_ptes list), then we do the following on write fault: Thanks for the detail. Um, propagating slot bit to parent ptes is little slow, especially, it is the overload for no Xwindow guests which is dirty logged only in the migration(i guess most linux guests are running on this mode and migration is not frequent). No? You need to propagate very infrequently. The first pte added to a page will need to propagate, but the second (if from the same slot, which is likely) will already have the bit set in the page, so we're assured it's set in all its parents. btw, if you plan to work on this, let's agree on pseudocode/data structures first to minimize churn. I'll also want this documented in mmu.txt. Of course we can still end up with something different than planned, but let's at least try to think of the issues in advance. I want to hear the overall view as well. Now we are trying to improve cases when there are too many dirty pages during live migration. I did some measurements of live migration some months ago on 10Gbps dedicated line, two servers were directly connected, and checked that transferring only a few MBs of memory took ms order of latency, even if I excluded other QEMU side overheads: it matches simple math calculation. In another test, I found that even in a relatively normal workload, it needed a few seconds of pause at the last timing. Juan has more data? So, the current scheme is not scalable with respect to the number of dirty pages, and administrators should control not to migrate during such workload if possible. Server consolidation in the night will be OK, but dynamic load balancing may not work well in such restrictions: I am now more interested in the former. Then, taking that in mind, I put the goal on 1K dirty pages, 4MB memory, when I did the rmap optimization. Now it takes a few ms or so for write protecting such number of pages, IIRC: that is not so bad compared to the overall latency? So, though I like O(1) method, I want to hear the expected improvements in a bit more detail, if possible. IIUC, even though O(1) is O(1) at the timing of GET DIRTY LOG, it needs O(N) write protections with respect to the total number of dirty pages: distributed, but actually each page fault, which should be logged, does some write protection? In general, what kind of improvements actually needed for live migration? Thanks, Takuya
Re: [Qemu-devel] [PATCH 0/4] KVM: Dirty logging optimization using rmap
(2011/11/30 14:02), Takuya Yoshikawa wrote: IIUC, even though O(1) is O(1) at the timing of GET DIRTY LOG, it needs O(N) write protections with respect to the total number of dirty pages: distributed, but actually each page fault, which should be logged, does some write protection? Sorry, was not precise. It depends on the level, and not completely distributed. But I think it is O(N), and the total number of costs will not change so much, I guess. Takuya In general, what kind of improvements actually needed for live migration? Thanks, Takuya -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] RFC: Design Doc for a new trace format (to support variable number/size of args per event) simpletrace-v2
On 11/29/2011 06:26 PM, Stefan Hajnoczi wrote:
On Tue, Nov 29, 2011 at 12:35 PM, Markus Armbrusterarm...@redhat.com wrote:
Stefan Hajnoczistefa...@gmail.com writes:
[...]
So forget I said self-describing :). I think the only changes from
the v1 format we need are:
1. New magic number to mark v2 format.
2. Trace records are no longer fixed-length, they include a size field:
typedef struct {
uint32_t length; /* in bytes */
uint32_t reserved; /* unused */
uint64_t event;
uint64_t timestamp_ns;
uint8_t arguments[];
} TraceRecord;
3. Strings are serialized like this:
uint16_t length;
char chars[length];
16 bit length? Sure you want that?
You're right, it's more future-proof to use a larger type. Since I
said uint32_t length in TraceRecord, uint32_t here would work well.
Makes sense to store size info only for strings as long as we rely on
trace-events file to identify other meta-data about trace-events.
thanks,
Harsh
Stefan
Re: [Qemu-devel] [PATCH V3 0/4] i.MX31 and KZM board support
Am 30.11.2011 04:36, schrieb Peter Chubb: Changes since last patchset: * All files now under GPL version 2 or later (I've talked with OK-Labs and they've agreed). hw/imx_serial.c is still GPL 2 only. I did not review the rest. * `DPRINTF' like macro for printing out guest kernel and qemu implementation errors * Fixed bugs in avic implementation, as found by PMM * Use a static initialiser and sysbus_register_withprop() instead of calls to sysbus_register() adn vmstate_register() * Fixed bugs in imx_timer.c as noted by PMM and Andreas Could you please use 'git send-email' to send the patches? Patches which are appended to a mail make review and answering difficult. Regards, Stefan Weil
Re: [Qemu-devel] [PATCH V3 0/4] i.MX31 and KZM board support
Stefan == Stefan Weil s...@weilnetz.de writes: Stefan Am 30.11.2011 04:36, schrieb Peter Chubb: Changes since last patchset: * All files now under GPL version 2 or later (I've talked with OK-Labs and they've agreed). Stefan hw/imx_serial.c is still GPL 2 only. I did not review the Stefan rest. Missed one, sorry. * `DPRINTF' like macro for printing out guest kernel and qemu implementation errors * Fixed bugs in avic implementation, as found by PMM * Use a static initialiser and sysbus_register_withprop() instead of calls to sysbus_register() adn vmstate_register() * Fixed bugs in imx_timer.c as noted by PMM and Andreas Stefan Could you please use 'git send-email' to send the patches? Stefan Patches which are appended to a mail make review and answering Stefan difficult. I used quilt mail --send Peter C -- Dr Peter Chubb http://www.gelato.unsw.edu.au peterc AT gelato.unsw.edu.au http://www.ertos.nicta.com.au ERTOS within National ICT Australia
Re: [Qemu-devel] [BUG] [Seabios] PCI 64bit BARs on Win2008 - unable to start the device. (ACPI lacks the _DSM method)
On Wed, Nov 30, 2011 at 02:04:08PM +1300, Alexey Korolev wrote: Hi, We have got some issues with 64bit PCI devices support under Windows guests. Windows fails to start any PCI devices with 64bit BARs when size exceeds 512MB with error code 12 (can't allocate resources). In other words it fails when the PCI memory region is located above 4GB. I tried to investigate this problem and found document from Microsoft: http://msdn.microsoft.com/en-us/windows/hardware/gg462986 It states that the _DSM method must be implemented to support devices above 4GB. That's not how I read it: Windows Vista always respects the boot configuration of devices above 4 GB, considering the processor’s addressing capability and the version of the Windows operating system that is running. Unfortunately I'm not familiar with ACPI code of seabios, so can't implement the _DSM method. May be you have other ideas what needs to be done to fix it? Any help is appreciated. Thanks, Alexey Could you share some more detail about your setup? -- MST
