On Mon, May 24, 2010 at 10:13:40PM +0200, Jan Kiszka wrote:
From: Jan Kiszka jan.kis...@siemens.com
This allows to communicate potential IRQ coalescing during delivery from
the sink back to the source. Targets that support IRQ coalescing
workarounds need to register handlers that return the
Gleb Natapov wrote:
On Mon, May 24, 2010 at 10:20:31PM +0200, Jan Kiszka wrote:
Maybe the coalescing should be pushed to APIC, or even generalized.
The latter has happened, hopefully in the right direction.
What do you mean by that?
The latter: I tried to generalize. Please look at patch 7
On Tue, May 25, 2010 at 08:09:02AM +0200, Jan Kiszka wrote:
Gleb Natapov wrote:
On Mon, May 24, 2010 at 10:20:31PM +0200, Jan Kiszka wrote:
Maybe the coalescing should be pushed to APIC, or even generalized.
The latter has happened, hopefully in the right direction.
What do you mean by
TeLeMan wrote:
setenv() is not implemented on MinGW, so we have to use putenv().
What a ... pity.
Signed-off-by: TeLeMan gele...@gmail.com
---
sdl.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/sdl.c b/sdl.c
index add1148..eb4a87f 100644
--- a/sdl.c
Gleb Natapov wrote:
On Mon, May 24, 2010 at 10:13:40PM +0200, Jan Kiszka wrote:
From: Jan Kiszka jan.kis...@siemens.com
This allows to communicate potential IRQ coalescing during delivery from
the sink back to the source. Targets that support IRQ coalescing
workarounds need to register
On Tue, May 25, 2010 at 08:31:06AM +0200, Jan Kiszka wrote:
Gleb Natapov wrote:
On Mon, May 24, 2010 at 10:13:40PM +0200, Jan Kiszka wrote:
From: Jan Kiszka jan.kis...@siemens.com
This allows to communicate potential IRQ coalescing during delivery from
the sink back to the source.
Gleb Natapov wrote:
On Tue, May 25, 2010 at 08:31:06AM +0200, Jan Kiszka wrote:
Gleb Natapov wrote:
On Mon, May 24, 2010 at 10:13:40PM +0200, Jan Kiszka wrote:
From: Jan Kiszka jan.kis...@siemens.com
This allows to communicate potential IRQ coalescing during delivery from
the sink back to
On Mon, May 24, 2010 at 05:21:04PM -0700, Chris Wright wrote:
Please send in any agenda items you are interested in covering.
Sorry for the delayed response.
If the community is interested, I would
like to discuss the Generic Asynchronous task offloading framework
patches posted to the
This looks very promissing.
I just got a couple of observations:
- Your patch does not work on my machine with the vesafb driver. It
reports can't handle 8 bpp frame buffers. It turns out that the
vesafb driver seems to initialize the framebuffer in PSEUDOCOLOR
mode.
Depends on the video mode
Om du har problem med att läsa detta e-postmeddelande, klicka här
(http://www.anp.se/newsletter/706025/444059437941455D4B7142445C43) för en
webb-version.
Vårt nyhetsbrev skickas automatiskt till våra kunder och intressenter. Vill du
inte ha detta nyhetsbrev framöver, klicka här för att
On 05/24/2010 11:22 PM, Anthony Liguori wrote:
This converts the entire qdev tree into an undocumented stable
protocol (the qdev paths were already in this state I believe). This
really worries me.
N.B. the association with qdev is only in identifying the device. The
contents of the
On 05/25/2010 01:10 AM, Anthony Liguori wrote:
On 05/21/2010 02:50 AM, Andre Przywara wrote:
-cpu host currently only propagates the CPU's family/model/stepping,
the brand name and the feature bits.
Add a whitelist of safe CPUID leafs to let the guest see the actual
CPU's cache details and
On 05/24/2010 10:17 PM, Anthony Liguori wrote:
On 05/24/2010 02:39 AM, Paolo Bonzini wrote:
Signed-off-by: Paolo Bonzinipbonz...@redhat.com
I think this series conflicts a bit with Luiz's series which I just
pushed. Could you rebase against the latest?
You didn't apply this one yet, at
Hi, everyone.
I tried to test the qemu, but I found only qemu-i386 is tested.
But is there any test about other command like qemu-system-arm or
qemu-arm to make sure the function still work after modification?
Best Regards,
robert
On Mon, May 24, 2010 at 11:20 PM, Anthony Liguori
aligu...@linux.vnet.ibm.com wrote:
+# check if trace backend exists
+
+sh tracetool --$trace_backend --check-backend /dev/null 2 /dev/null
This will fail if objdir != srcdir. You have to qualify tracetool with the
path to srcdir.
Thanks
On 05/24/2010 11:07 PM, Neo Jia wrote:
hi,
I am using KVM/Qemu to debug my Windows guest according to KVM wiki
page (http://www.linux-kvm.org/page/WindowsGuestDrivers/GuestDebugging).
It works for me and also I can only use one Windows guest and bind its
serial port to a TCP port and run
Hi all.
I am very new to dev for QEMU, so I have some very basic questions.
1) I understand that QEMU has a built-in GDB server that is somewhat a
simulation of a JTAG device on dev boards, connected directly to the CPU. Is
that a correct analogy?
2) How can the GDB server handle a MMU? Would it
On 05/24/2010 07:54 PM, Juan Quintela wrote:
But for the other call, what do you propose?
My best try was to hide the availability of hpet inside hpet_emul.h
with:
#ifdef CONFIG_HPET
uint32_t hpet_in_legacy_mode(void);
else
uint32_t hpet_in_legacy_mode(void) { return 0;}
#endif
Change this
On Mon, May 24, 2010 at 08:10:16PM +, Blue Swirl wrote:
On Mon, May 24, 2010 at 3:40 PM, Joerg Roedel j...@8bytes.org wrote:
+
+#define MMIO_SIZE 0x2028
This size should be a power-of-two value. In this case probably 0x4000.
Not really, the devices can reserve regions
Modify inuse type to uint16_t, let save/load to handle, and revert
last_avail_idx with inuse if there are outstanding emulation.
Signed-off-by: Yoshiaki Tamura tamura.yoshi...@lab.ntt.co.jp
---
hw/virtio.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git
Signed-off-by: Yoshiaki Tamura tamura.yoshi...@lab.ntt.co.jp
---
vl.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/vl.c b/vl.c
index 70a8aed..56d12c7 100644
--- a/vl.c
+++ b/vl.c
@@ -169,6 +169,8 @@ int main(int argc, char **argv)
#include qemu-queue.h
When -k option is set to migrate command, it will turn on ft_mode to
start FT migration mode (Kemari).
Signed-off-by: Yoshiaki Tamura tamura.yoshi...@lab.ntt.co.jp
---
migration.c |3 +++
qemu-monitor.hx |7 ---
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git
Record mmio write event to replay it upon failover.
Signed-off-by: Yoshiaki Tamura tamura.yoshi...@lab.ntt.co.jp
---
exec.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/exec.c b/exec.c
index d5c2a05..e9ed477 100644
--- a/exec.c
+++ b/exec.c
@@ -44,6 +44,7 @@
Modifies ram_save_block() and ram_save_remaining() to use
cpu_physical_memory_get_dirty_range() to check multiple dirty and non-dirty
pages at once.
Signed-off-by: Yoshiaki Tamura tamura.yoshi...@lab.ntt.co.jp
Signed-off-by: OHMURA Kei ohmura@lab.ntt.co.jp
---
vl.c | 52
Introduce event-tap callbacks to functions which actually fire outputs
at net/block layer. By synchronizing VMs before outputs are fired, we
can failover to the receiver upon failure.
Signed-off-by: Yoshiaki Tamura tamura.yoshi...@lab.ntt.co.jp
---
block.c | 22 ++
Record ioport event to replay it upon failover.
Signed-off-by: Yoshiaki Tamura tamura.yoshi...@lab.ntt.co.jp
---
ioport.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/ioport.c b/ioport.c
index 53dd87a..ad7a017 100644
--- a/ioport.c
+++ b/ioport.c
@@ -26,6 +26,7 @@
To utilize ft_transaction function, savevm needs interfaces to be
exported.
Signed-off-by: Yoshiaki Tamura tamura.yoshi...@lab.ntt.co.jp
---
hw/hw.h |5 +
savevm.c | 41 +
2 files changed, 46 insertions(+), 0 deletions(-)
diff --git a/hw/hw.h
The option looks like, -incoming protocol:address:port,ft_mode
Signed-off-by: Yoshiaki Tamura tamura.yoshi...@lab.ntt.co.jp
---
migration.c | 14 +-
1 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/migration.c b/migration.c
index 3334650..a4850f9 100644
---
Modifies kvm_get_dirty_pages_log_range to use
cpu_physical_memory_set_dirty_range() to update the row of the
bit-based phys_ram_dirty bitmap at once.
Signed-off-by: Yoshiaki Tamura tamura.yoshi...@lab.ntt.co.jp
Signed-off-by: OHMURA Kei ohmura@lab.ntt.co.jp
---
qemu-kvm.c | 19
Introduce ft_tranx_ready() which kicks the FT transaction cycle. When
ft_mode is on, migrate_fd_put_ready() would open ft_transaction file
and turn on event_tap. To end or cancel ft_transaction, ft_mode and
event_tap is turned off.
Signed-off-by: Yoshiaki Tamura tamura.yoshi...@lab.ntt.co.jp
Introduce skip_header parameter to qemu_loadvm_state() so that it can
be called iteratively without reading the header.
Signed-off-by: Yoshiaki Tamura tamura.yoshi...@lab.ntt.co.jp
---
migration-exec.c |2 +-
migration-fd.c |2 +-
migration-tcp.c |2 +-
migration-unix.c |2 +-
Currently FdMigrationState doesn't support read(), and this patch
introduces it to get response from the other side.
Signed-off-by: Yoshiaki Tamura tamura.yoshi...@lab.ntt.co.jp
---
migration-tcp.c | 14 ++
migration.c | 12
migration.h |3 +++
3 files
Signed-off-by: Yoshiaki Tamura tamura.yoshi...@lab.ntt.co.jp
---
osdep.c | 13 +
qemu-char.c | 25 -
qemu_socket.h |4
3 files changed, 41 insertions(+), 1 deletions(-)
diff --git a/osdep.c b/osdep.c
index 3bab79a..63444e7 100644
---
Call event_tap_replay() at vm_start() to replay the last ioport/mmio
event upon failover.
Signed-off-by: Yoshiaki Tamura tamura.yoshi...@lab.ntt.co.jp
---
vl.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/vl.c b/vl.c
index 56d12c7..762440d 100644
--- a/vl.c
+++ b/vl.c
When ft_mode is set in the header, tcp_accept_incoming_migration()
receives ft_transaction iteratively. We also need a hack no to close
fd before moving to ft_transaction mode, so that we can reuse the fd
for it.
Signed-off-by: Yoshiaki Tamura tamura.yoshi...@lab.ntt.co.jp
---
migration-tcp.c |
event-tap controls when to start ft transaction, and inserts callbacks
to the net/block.
Signed-off-by: Yoshiaki Tamura tamura.yoshi...@lab.ntt.co.jp
---
Makefile.target |1 +
event-tap.c | 184 +++
event-tap.h | 32 ++
3
Introduce qemu_savevm_state_all() to send the memory and device info
together, while avoiding cancelling memory state tracking.
Signed-off-by: Yoshiaki Tamura tamura.yoshi...@lab.ntt.co.jp
---
savevm.c | 60
sysemu.h |1 +
2
Skip assert(!cpu_single_env) in resume_all_threads() when
event_tap_state weren't EVENT_TAP_OFF.
Signed-off-by: Yoshiaki Tamura tamura.yoshi...@lab.ntt.co.jp
---
qemu-kvm.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/qemu-kvm.c b/qemu-kvm.c
index 1414f49..e28bf59
Hi,
This patch series is a revised version of Kemari for KVM, which applied comments
for the previous post. The current code is based on qemu-kvm.git
2b644fd0e737407133c88054ba498e772ce01f27.
On the contrary to the previous version, this series doesn't require any
modifications to KVM. The I/O
Replaces byte-based phys_ram_dirty bitmap with four (MASTER, VGA,
CODE, MIGRATION) bit-based phys_ram_dirty bitmap. On allocation, it
sets all bits in the bitmap. It uses ffs() to convert DIRTY_FLAG to
DIRTY_IDX.
Modifies wrapper functions for byte-based phys_ram_dirty bitmap to
bit-based
Currently buf size is fixed at 32KB. It would be useful if it could
be flexible.
Signed-off-by: Yoshiaki Tamura tamura.yoshi...@lab.ntt.co.jp
---
hw/hw.h |2 ++
savevm.c | 21 -
2 files changed, 22 insertions(+), 1 deletions(-)
diff --git a/hw/hw.h b/hw/hw.h
index
Hi,
This patch series is a revised version of Kemari for KVM, which applied comments
for the previous post. The current code is based on qemu-kvm.git
2b644fd0e737407133c88054ba498e772ce01f27.
On the contrary to the previous version, this series doesn't require any
modifications to KVM. The I/O
On 05/24/2010 10:19 PM, Anthony Liguori wrote:
On 05/24/2010 06:03 AM, Avi Kivity wrote:
On 05/24/2010 11:27 AM, Stefan Hajnoczi wrote:
On Sun, May 23, 2010 at 1:01 PM, Avi Kivitya...@redhat.com wrote:
On 05/21/2010 12:29 AM, Anthony Liguori wrote:
I'd be more interested in enabling people
On 05/24/2010 10:16 PM, Anthony Liguori wrote:
On 05/24/2010 06:56 AM, Avi Kivity wrote:
On 05/24/2010 02:42 PM, MORITA Kazutaka wrote:
The server would be local and talk over a unix domain socket, perhaps
anonymous.
nbd has other issues though, such as requiring a copy and no
support for
On 05/21/10 19:55, Shahar Havivi wrote:
Remove usb_host_device_release and using usb_host_close to handle usb_del
command.
Gerd, What do you think about the usb_cleanup()?
We need a mechanism to handle this for sure. I don't like that
usb-specific approach very much though.
I think we
for (i = 0; i 24; i++) {
sysbus_connect_irq(sysbus_from_qdev(hpet), i, isa_irq[i]);
}
+rtc_irq = qemu_allocate_feedback_irqs(hpet_handle_rtc_irq,
+ sysbus_from_qdev(hpet), 1);
}
This is wrong. The hpet
On 05/25/2010 01:07 AM, Anthony Liguori wrote:
Interesting approach as it lets us defer the tracing backend decision.
Also, it's compatible with the multiplatform nature of qemu.
--
error compiling committee.c: too many arguments to function
On 05/24/2010 10:38 PM, Anthony Liguori wrote:
- Building a plugin API seems a bit simpler to me, although I'm to
sure if I'd get the
idea correctly:
The block layer has already some kind of api (.bdrv_file_open,
.bdrv_read). We
could simply compile the block-drivers as shared
+static SysBusDeviceInfo hpet_device_info = {
+.qdev.name= hpet,
+.qdev.size= sizeof(HPETState),
+.qdev.no_user = 1,
Why shouldn't the user create HPET devices? I thought you'd removed all the
global state.
Paul
It checks the first row and puts dirty addr in the array. If the
first row is empty, it skips to the first non-dirty row or the end
addr, and put the length in the first entry of the array.
Signed-off-by: Yoshiaki Tamura tamura.yoshi...@lab.ntt.co.jp
Signed-off-by: OHMURA Kei
On Tue, 25 May 2010, Gerd Hoffmann wrote:
The actual stretching is done by SDL I think. For that kind of stuff a
rendering library is actually helpful ...
not really, the sdl_zoom* stuff is completely generic
On 05/24/10 14:32, Paul Brook wrote:
+int is_ioport_assigned(pio_addr_t addr)
Shouldn't we move this into register_ioport_{read,write}, and have that fail
if the port has already been assigned?
It already checks and fails with hw_error(). Problem with that is that
this kills qemu in case
On Mon, May 24, 2010 at 08:45:31AM -0700, Richard Henderson wrote:
On 05/24/2010 07:57 AM, Edgar E. Iglesias wrote:
I took a look at the code again and I dont really understand how the
particular case when we get a high address from the kernel while
mmap_min_addr is busy case is supposed to
This code implements VM transaction protocol. Like buffered_file, it
sits between savevm and migration layer. With this architecture, VM
transaction protocol is implemented mostly independent from other
existing code.
Signed-off-by: Yoshiaki Tamura tamura.yoshi...@lab.ntt.co.jp
Signed-off-by:
Fixed by ae6b2c4ed956c17456e70efefe13ad0ab7db31de
** Changed in: qemu
Status: New = Fix Committed
--
cirrus_vga display is buggy after migration
https://bugs.launchpad.net/bugs/494486
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to
On 05/19/2010 11:20 AM, Christoph Hellwig wrote:
It's time we get a proper bugzilla.qemu.org for both qemu and qemu-kvm
that can be used sanely. If you ask nicely you might even get a virtual
instance of bugzilla.kernel.org which works quite nicely.
That would be my preference too but
Paolo Bonzini wrote:
On 05/24/2010 07:54 PM, Juan Quintela wrote:
But for the other call, what do you propose?
My best try was to hide the availability of hpet inside hpet_emul.h
with:
#ifdef CONFIG_HPET
uint32_t hpet_in_legacy_mode(void);
else
uint32_t hpet_in_legacy_mode(void) { return
On 05/25/2010 11:05 AM, Jan Kiszka wrote:
Please don't waste your time:
http://permalink.gmane.org/gmane.comp.emulators.qemu/71377
I wasn't going to. :-) I had seen the series---very nice work!
Paolo
Paul Brook wrote:
+static SysBusDeviceInfo hpet_device_info = {
+.qdev.name= hpet,
+.qdev.size= sizeof(HPETState),
+.qdev.no_user = 1,
Why shouldn't the user create HPET devices? I thought you'd removed all the
global state.
Long-term, there is no reason to deny this.
Paul Brook wrote:
for (i = 0; i 24; i++) {
sysbus_connect_irq(sysbus_from_qdev(hpet), i, isa_irq[i]);
}
+rtc_irq = qemu_allocate_feedback_irqs(hpet_handle_rtc_irq,
+ sysbus_from_qdev(hpet), 1);
}
Sometimes it is useful to disable a trace event. Removing the event
from trace-events is not enough since source code will call the
trace_*() function for the event.
This patch makes it easy to build without specific trace events by
marking them disabled in trace-events:
disable
This patch adds trace events that make it possible to observe
virtio-blk.
Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
---
block.c|7 +++
hw/virtio-blk.c|7 +++
posix-aio-compat.c |2 ++
trace-events | 14 ++
4 files changed,
This patch adds trace events for virtqueue operations including
adding/removing buffers, notifying the guest, and receiving a notify
from the guest.
Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
---
v2:
* This patch is new in v2
hw/virtio.c |8
trace-events |8
After the RFC discussion, updated patches which I propose for review and merge:
The following patches against qemu.git allow static trace events to be declared
in QEMU. Trace events use a lightweight syntax and are independent of the
backend tracing system (e.g. LTTng UST).
Supported backends
This patch introduces the trace-events file where trace events can be
declared like so:
qemu_malloc(size_t size) size %zu
qemu_free(void *ptr) ptr %p
These trace event declarations are processed by a new tool called
tracetool to generate code for the trace events. Trace event
declarations are
It is often useful to instrument memory management functions in order to
find leaks or performance problems. This patch adds trace events for
the memory allocation primitives.
Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
---
v2:
* Record pointer result from allocation functions
This patch adds LTTng Userspace Tracer (UST) backend support. The UST
system requires no kernel support but libust and liburcu must be
installed.
$ ./configure --trace-backend ust
$ make
Start the UST daemon:
$ ustd
List available tracepoints and enable some:
$ ustctl --list-markers $(pgrep
Am 23.05.2010 14:01, schrieb Avi Kivity:
On 05/21/2010 12:29 AM, Anthony Liguori wrote:
I'd be more interested in enabling people to build these types of
storage systems without touching qemu.
Both sheepdog and ceph ultimately transmit I/O over a socket to a
central daemon, right?
Michael Tokarev wrote:
23.05.2010 13:55, Peter Lieven wrote:
Hi,
after live migrating ubuntu 9.10 server (2.6.31-14-server) and suse
linux 10.1 (2.6.16.13-4-smp)
it happens sometimes that the guest runs into irq problems. i mention
these 2 guest oss
since i have seen the error there. there
This is wrong. The hpet device should expose this as an IO pin.
Will look into this.
BTW, I just realized that the GPIO handling is apparently lacking
support for attaching an output to multiple inputs. Or am I missing
something?
Use an explicit mux.
Incidentally I suspect your
Paul Brook wrote:
This is wrong. The hpet device should expose this as an IO pin.
Will look into this.
BTW, I just realized that the GPIO handling is apparently lacking
support for attaching an output to multiple inputs. Or am I missing
something?
Use an explicit mux.
Incidentally I
Paul Brook wrote:
This is wrong. The hpet device should expose this as an IO pin.
Will look into this.
BTW, I just realized that the GPIO handling is apparently lacking
support for attaching an output to multiple inputs. Or am I missing
something?
Use an explicit mux.
On 05/25/2010 02:02 PM, Kevin Wolf wrote:
So could we not standardize a protocol for this that both sheepdog and
ceph could implement?
The protocol already exists, nbd. It doesn't support snapshotting etc.
but we could extend it.
But IMO what's needed is a plugin API for the block
On Tue, May 25, 2010 at 10:39:22AM +0200, Joerg Roedel wrote:
On Mon, May 24, 2010 at 08:10:16PM +, Blue Swirl wrote:
On Mon, May 24, 2010 at 3:40 PM, Joerg Roedel j...@8bytes.org wrote:
+
+#define MMIO_SIZE ? ? ? ? ? ? ? 0x2028
This size should be a power-of-two value. In this
Paul Brook wrote:
Paul Brook wrote:
This is wrong. The hpet device should expose this as an IO pin.
Will look into this.
BTW, I just realized that the GPIO handling is apparently lacking
support for attaching an output to multiple inputs. Or am I missing
something?
Use an explicit mux.
From: Igor V. Kovalenko igor.v.kovale...@gmail.com
- remove unused host state and store pci bus pointer only
- do not map host state access into unused 1fe.1000 range
- reorder pci region registration
- assign pci i/o region to isa_mem_base
- rename default machine (it's Ultrasparc IIi now)
@@ -87,6 +91,8 @@ static void virtio_blk_rw_complete(void
{
VirtIOBlockReq *req = opaque;
+trace_virtio_blk_rw_complete(req, ret);
+
if (ret) {
int is_read = !(req-out-type VIRTIO_BLK_T_OUT);
if (virtio_blk_handle_rw_error(req, -ret, is_read))
What happens when
+#define DEFINE_TRACE(name, tproto, tassign, tprint)\
+ void trace_##name(tproto) \
+ { \
+ unsigned int hash;\
+ char tpname[] =
Interesting to see your patches, tracepoint definitions/declarations
look similar to in-kernel tracepoints :).
Please post future patches inline to the email so reviewing and
replying is easy (e.g. use git-send-email to send patches).
Stefan
2010/5/25 Igor V. Kovalenko igor.v.kovale...@gmail.com:
From: Igor V. Kovalenko igor.v.kovale...@gmail.com
- remove unused host state and store pci bus pointer only
- do not map host state access into unused 1fe.1000 range
- reorder pci region registration
- assign pci i/o region to
On Tue, May 25, 2010 at 02:25:53PM +0300, Avi Kivity wrote:
Currently if someone wants to add a new block format, they have to
upstream it and wait for a new qemu to be released. With a plugin API,
they can add a new block format to an existing, supported qemu.
So? Unless we want a
On 05/25/2010 01:24 PM, Stefan Hajnoczi wrote:
This patch adds trace events for virtqueue operations including
adding/removing buffers, notifying the guest, and receiving a notify
from the guest.
diff --git a/trace-events b/trace-events
index 48415f8..a533414 100644
--- a/trace-events
+++
I realise that. However I'd expect things to break if the guest OS
devices to share an IRQ line between the HPET and some other device.
The guest would share IRQ8, not the RTC output. So there would be no
difference to the current situation.
The difference is that you've removed the check
- rename sun4u cpu to Ultrasparc IIi
- cleanup pci bridge map (requires openbios change)
v0-v1: split out rename of sun4u cpu to separate patch
---
Igor V. Kovalenko (2):
sparc64: rename sun4u cpu to Ultrasparc IIi
sparc64: clean up pci bridge map
hw/apb_pci.c | 49
From: Igor V. Kovalenko igor.v.kovale...@gmail.com
Signed-off-by: Igor V. Kovalenko igor.v.kovale...@gmail.com
---
hw/sun4u.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/hw/sun4u.c b/hw/sun4u.c
index e9a1e23..1e92900 100644
--- a/hw/sun4u.c
+++ b/hw/sun4u.c
@@
From: Igor V. Kovalenko igor.v.kovale...@gmail.com
- remove unused host state and store pci bus pointer only
- do not map host state access into unused 1fe.1000 range
- reorder pci region registration
- assign pci i/o region to isa_mem_base
Signed-off-by: Igor V. Kovalenko
On 05/25/2010 03:03 PM, Christoph Hellwig wrote:
On Tue, May 25, 2010 at 02:25:53PM +0300, Avi Kivity wrote:
Currently if someone wants to add a new block format, they have to
upstream it and wait for a new qemu to be released. With a plugin API,
they can add a new block format to an
On Tue, May 25, 2010 at 3:56 PM, Artyom Tarasenko
atar4q...@googlemail.com wrote:
2010/5/25 Igor V. Kovalenko igor.v.kovale...@gmail.com:
From: Igor V. Kovalenko igor.v.kovale...@gmail.com
- remove unused host state and store pci bus pointer only
- do not map host state access into unused
Paul Brook wrote:
I realise that. However I'd expect things to break if the guest OS
devices to share an IRQ line between the HPET and some other device.
The guest would share IRQ8, not the RTC output. So there would be no
difference to the current situation.
The difference is that you've
On 05/25/2010 02:23 AM, Avi Kivity wrote:
On 05/24/2010 11:22 PM, Anthony Liguori wrote:
This converts the entire qdev tree into an undocumented stable
protocol (the qdev paths were already in this state I believe).
This really worries me.
N.B. the association with qdev is only in
On 05/25/2010 02:28 AM, Paolo Bonzini wrote:
On 05/24/2010 10:17 PM, Anthony Liguori wrote:
On 05/24/2010 02:39 AM, Paolo Bonzini wrote:
Signed-off-by: Paolo Bonzinipbonz...@redhat.com
I think this series conflicts a bit with Luiz's series which I just
pushed. Could you rebase against the
On 05/25/2010 04:14 AM, Avi Kivity wrote:
On 05/24/2010 10:38 PM, Anthony Liguori wrote:
- Building a plugin API seems a bit simpler to me, although I'm to
sure if I'd get the
idea correctly:
The block layer has already some kind of api (.bdrv_file_open,
.bdrv_read). We
could simply
On 05/25/2010 04:03 PM, Anthony Liguori wrote:
I don't think that qdev device names and paths are something we have
to worry much about changing over time since they reflect logical
bus layout. They should remain static provided the devices remain
static.
Modulo mistakes. We already saw
Anthony Liguori wrote:
On 05/21/2010 02:50 AM, Andre Przywara wrote:
-cpu host currently only propagates the CPU's family/model/stepping,
the brand name and the feature bits.
Add a whitelist of safe CPUID leafs to let the guest see the actual
CPU's cache details and other things.
On 05/25/2010 06:25 AM, Avi Kivity wrote:
On 05/25/2010 02:02 PM, Kevin Wolf wrote:
So could we not standardize a protocol for this that both sheepdog and
ceph could implement?
The protocol already exists, nbd. It doesn't support snapshotting etc.
but we could extend it.
But IMO what's
On 05/25/2010 04:17 PM, Anthony Liguori wrote:
On 05/25/2010 04:14 AM, Avi Kivity wrote:
On 05/24/2010 10:38 PM, Anthony Liguori wrote:
- Building a plugin API seems a bit simpler to me, although I'm to
sure if I'd get the
idea correctly:
The block layer has already some kind of api
USB 2.0 leverages companion UHCI or OHCI host controllers for full and
low speed devices. I do not see an appropriate means for doing that bus
transition and could use some suggestions.
I've read through the code for the legacy path in handling USB devices
(-usbdevice CLI arg and usb_add monitor
On 05/25/2010 04:29 PM, Anthony Liguori wrote:
The current situation is that those block format drivers only exist
in qemu.git or as patches. Surely that's even more unhappiness.
Confusion could be mitigated:
$ qemu -module my-fancy-block-format-driver.so
my-fancy-block-format-driver.so
On 05/25/2010 08:31 AM, Avi Kivity wrote:
A protocol based mechanism has the advantage of being more robust in
the face of poorly written block backends so if it's possible to make
it perform as well as a plugin, it's a preferable approach.
May be hard due to difficulty of exposing guest
On 05/25/2010 04:35 PM, Anthony Liguori wrote:
On 05/25/2010 08:31 AM, Avi Kivity wrote:
A protocol based mechanism has the advantage of being more robust in
the face of poorly written block backends so if it's possible to
make it perform as well as a plugin, it's a preferable approach.
May
1 - 100 of 191 matches
Mail list logo