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 mod
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 avprenu
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 device
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 other
On 05/24/2010 10:17 PM, Anthony Liguori wrote:
On 05/24/2010 02:39 AM, Paolo Bonzini wrote:
Signed-off-by: Paolo Bonzini
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 least I don't see it on
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
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 Anthony, fixe
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 "Virtua
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 to
On Mon, May 24, 2010 at 08:10:16PM +, Blue Swirl wrote:
> On Mon, May 24, 2010 at 3:40 PM, Joerg Roedel 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 of
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
---
hw/virtio.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/hw/virtio.c b/hw/virtio.c
index 7c020a3.
Signed-off-by: Yoshiaki Tamura
---
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"
+#include "event-tap.h"
+
//#define
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
---
migration.c |3 +++
qemu-monitor.hx |7 ---
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/migration.c b/migration.c
index 5b9
Record mmio write event to replay it upon failover.
Signed-off-by: Yoshiaki Tamura
---
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 @@
#include "hw/hw.h"
#include "osdep
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
Signed-off-by: OHMURA Kei
---
vl.c | 52 +---
1 files changed, 33
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
---
block.c | 22 ++
block.h |4
net/queu
Record ioport event to replay it upon failover.
Signed-off-by: Yoshiaki Tamura
---
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 @@
*/
#include "ioport.h"
+#in
To utilize ft_transaction function, savevm needs interfaces to be
exported.
Signed-off-by: Yoshiaki Tamura
---
hw/hw.h |5 +
savevm.c | 41 +
2 files changed, 46 insertions(+), 0 deletions(-)
diff --git a/hw/hw.h b/hw/hw.h
index fc9ed29..5a48a9
The option looks like, -incoming ::,ft_mode
Signed-off-by: Yoshiaki Tamura
---
migration.c | 14 +-
1 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/migration.c b/migration.c
index 3334650..a4850f9 100644
--- a/migration.c
+++ b/migration.c
@@ -42,7 +42,19 @@ static
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
Signed-off-by: OHMURA Kei
---
qemu-kvm.c | 19 +++
1 files changed, 7 insertions(+), 12 deletion
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
---
migration.c | 78
Introduce skip_header parameter to qemu_loadvm_state() so that it can
be called iteratively without reading the header.
Signed-off-by: Yoshiaki Tamura
---
migration-exec.c |2 +-
migration-fd.c |2 +-
migration-tcp.c |2 +-
migration-unix.c |2 +-
savevm.c | 24 +
Currently FdMigrationState doesn't support read(), and this patch
introduces it to get response from the other side.
Signed-off-by: Yoshiaki Tamura
---
migration-tcp.c | 14 ++
migration.c | 12
migration.h |3 +++
3 files changed, 29 insertions(+), 0 del
Signed-off-by: Yoshiaki Tamura
---
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
--- a/osdep.c
+++ b/osdep.c
@@ -201,6 +
Call event_tap_replay() at vm_start() to replay the last ioport/mmio
event upon failover.
Signed-off-by: Yoshiaki Tamura
---
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
@@ -3094,6 +3094,7 @@ void vm
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
---
migration-tcp.c | 36
event-tap controls when to start ft transaction, and inserts callbacks
to the net/block.
Signed-off-by: Yoshiaki Tamura
---
Makefile.target |1 +
event-tap.c | 184 +++
event-tap.h | 32 ++
3 files changed, 217 insertions
Introduce qemu_savevm_state_all() to send the memory and device info
together, while avoiding cancelling memory state tracking.
Signed-off-by: Yoshiaki Tamura
---
savevm.c | 60
sysemu.h |1 +
2 files changed, 61 insertions(+), 0
Skip assert(!cpu_single_env) in resume_all_threads() when
event_tap_state weren't EVENT_TAP_OFF.
Signed-off-by: Yoshiaki Tamura
---
qemu-kvm.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/qemu-kvm.c b/qemu-kvm.c
index 1414f49..e28bf59 100644
--- a/qemu-kvm.c
+++ b/
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 phys_r
Currently buf size is fixed at 32KB. It would be useful if it could
be flexible.
Signed-off-by: Yoshiaki Tamura
---
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 05131a0..fc9ed29 100644
--- a/hw
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 Kivity wrote:
On 05/21/2010 12:29 AM, Anthony Liguori wrote:
I'd be more interested in enabling people to build these ty
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 shou
> 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. Th
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 objects
> +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
Signed-off-by: OHMURA Kei
---
cpu-all.h |4 +++
exec.c| 67
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 yo
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 suppo
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
Signed-off-by: OHMURA Kei
---
Makefile.objs
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 QE
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 the
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_m
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 t
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 multiwrite_cb(vo
This patch adds trace events that make it possible to observe
virtio-blk.
Signed-off-by: Stefan Hajnoczi
---
block.c|7 +++
hw/virtio-blk.c|7 +++
posix-aio-compat.c |2 ++
trace-events | 14 ++
4 files changed, 30 insertions(+), 0 deletion
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
---
v2:
* This patch is new in v2
hw/virtio.c |8
trace-events |8
2 files changed, 16
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 ar
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 ar
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
---
v2:
* Record pointer result from allocation functions
osdep.c | 24 +++
This patch adds a simple tracer which produces binary trace files and is
built into QEMU. The main purpose of this patch is to show how new
tracing backends can be added to tracetool.
To try out the simple backend:
./configure --trace-backend=simple
make
After running QEMU you can pretty-print
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 q
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, ri
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 ar
> > 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.
>
> 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?
> >
> > Us
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 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?
From: Igor V. Kovalenko
- 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)
Signed-off-by: Igor V. Kova
@@ -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 whe
+#define DEFINE_TRACE(name, tproto, tassign, tprint)\
+ void trace_##name(tproto) \
+ { \
+ unsigned int hash;\
+ char tpname[] = __stringify(name)
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 :
> From: Igor V. Kovalenko
>
> - 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 Ultra
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 sta
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
+++ b/trac
> > 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
- 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
Signed-off-by: Igor V. Kovalenko
---
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
@@ -859,7 +859,7 @@ enum {
static const struct hwdef hwdefs[
From: Igor V. Kovalenko
- 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
---
hw/apb_pci.c | 49 +++
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 existi
On Tue, May 25, 2010 at 3:56 PM, Artyom Tarasenko
wrote:
> 2010/5/25 Igor V. Kovalenko :
>> From: Igor V. Kovalenko
>>
>> - 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
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 th
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 identifyi
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 Bonzini
I think this series conflicts a bit with Luiz's series which I just
pushed. Could you rebase against the latest?
You didn't a
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 o
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.
Signed-off-by:
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 ne
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 (.b
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 monito
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 d
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 memor
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 b
On 05/25/2010 04:25 PM, Anthony Liguori 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.
Whether we have a plugin or protocol based
On 05/25/2010 04:26 PM, Anthony Liguori wrote:
On 05/25/2010 08:21 AM, Andre Przywara wrote:
What's the benefit of exposing this information to the guest?
That is mostly to propagate the cache size and organization
parameters to the guest:
>> +/* safe CPUID leafs to propagate to guest if -cp
Am 25.05.2010 15:25, schrieb Anthony Liguori:
> 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
On 05/25/2010 08:19 AM, Avi Kivity wrote:
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 s
On 05/25/2010 04:53 PM, Kevin Wolf wrote:
I'm still not convinced that we need either. I share Christoph's concern
that we would make our life harder for almost no gain. It's probably a
very small group of users (if it exists at all) that wants to add new
block drivers themselves, but at the sam
Am 24.05.2010 08:34, schrieb MORITA Kazutaka:
> At Fri, 21 May 2010 18:57:36 +0200,
> Kevin Wolf wrote:
>>
>> Am 20.05.2010 07:36, schrieb MORITA Kazutaka:
>>> +
>>> +/*
>>> + * Append an option list (list) to an option list (dest).
>>> + *
>>> + * If dest is NULL, a new copy of list is created.
>>
On Tue, May 25, 2010 at 1:04 PM, Avi Kivity wrote:
> Those %ps are more or less useless. We need better ways of identifying
> them.
You're right, the vq pointer is useless in isolation. We don't know
which virtio device or which virtqueue number.
With the full context of a trace it would be po
1 - 100 of 191 matches
Mail list logo
