On Thu, Mar 11, 2010 at 04:48:43PM +0200, Avi Kivity wrote:
> Signed-off-by: Avi Kivity
> ---
> CODING_STYLE |3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/CODING_STYLE b/CODING_STYLE
> index a579cb1..92036f3 100644
> --- a/CODING_STYLE
> +++ b/CODING_STYLE
> @@
On (Thu) Mar 11 2010 [23:45:51], Marcelo Tosatti wrote:
> Wake up iothread when buffers are consumed.
>
> Signed-off-by: Marcelo Tosatti
>
> Index: qemu-ioworker/hw/virtio-serial-bus.c
> ===
> --- qemu-ioworker.orig/hw/virtio-serial
This can be used later to introduce generic iothread workers.
Signed-off-by: Marcelo Tosatti
Index: qemu-ioworker/async.c
===
--- qemu-ioworker.orig/async.c
+++ qemu-ioworker/async.c
@@ -180,7 +180,7 @@ void qemu_bh_schedule(QEMUBH
Wake up iothread when buffers are consumed.
Signed-off-by: Marcelo Tosatti
Index: qemu-ioworker/hw/virtio-serial-bus.c
===
--- qemu-ioworker.orig/hw/virtio-serial-bus.c
+++ qemu-ioworker/hw/virtio-serial-bus.c
@@ -331,6 +331,7 @@ st
irqs in the
handlers being called (same issue seen on "d090723b.zip" image
reported by Roy).
I've put a test image with a workaround for the issue at:
http://linuxtogo.org/~kevin/SeaBIOS/test/bios.bin-0.5.1-debug-20100311
See below for the patch I used - I'm still researching i
2010/3/12 Kevin O'Connor :
> On Thu, Mar 11, 2010 at 03:42:28PM +0800, Roy Tam wrote:
>> Sorry I can't find documentation on this usage. But instead I have
>> lots of old programs written with this usage.
>> Using undocumented features from BIOS/DOS is very usual in that time.
>
> Can you confirm t
On Thu, Mar 11, 2010 at 03:42:28PM +0800, Roy Tam wrote:
> Sorry I can't find documentation on this usage. But instead I have
> lots of old programs written with this usage.
> Using undocumented features from BIOS/DOS is very usual in that time.
Can you confirm these other programs fail in the sam
Avi Kivity wrote:
> Signed-off-by: Avi Kivity
> ---
> CODING_STYLE |3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/CODING_STYLE b/CODING_STYLE
> index a579cb1..92036f3 100644
> --- a/CODING_STYLE
> +++ b/CODING_STYLE
> @@ -49,6 +49,9 @@ and is therefore likely to
Anthony Liguori wrote:
> On 03/11/2010 08:48 AM, Avi Kivity wrote:
> >Signed-off-by: Avi Kivity
> >---
> > CODING_STYLE |3 +++
> > 1 files changed, 3 insertions(+), 0 deletions(-)
> >
> >diff --git a/CODING_STYLE b/CODING_STYLE
> >index a579cb1..92036f3 100644
> >--- a/CODING_STYLE
> >+++ b/C
Avi Kivity wrote:
> On 03/10/2010 11:30 PM, Luiz Capitulino wrote:
> >
> >2. Do we have kvm-specific projects? Can they be part of the QEMU project
> >or do we need a different mentoring organization for it?
> >
>
> Something really interesting is kvm-assisted tcg. I'm afraid it's a bit
>
Currently qemu use the last keyboard device that added,
When removing keyboard (via device_del kbd) you get segfault next time
you try to write in the client.
i.e. start qemu
x86_64-softmmu/qemu-system-x86_64 -usb -device usb-kbd,id=kbd
switch to monitor
device_del kbd
switch back to client, s
Anthony Liguori wrote:
> On 03/09/2010 05:10 PM, Juan Quintela wrote:
>> This was the only incoming migration without autostart check
>>
>> Signed-off-by: Juan Quintela
>> ---
>> migration-unix.c |2 ++
>> 1 files changed, 2 insertions(+), 0 deletions(-)
>>
>> diff --git a/migration-unix.c
On 03/09/2010 05:10 PM, Juan Quintela wrote:
This was the only incoming migration without autostart check
Signed-off-by: Juan Quintela
---
migration-unix.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/migration-unix.c b/migration-unix.c
index ce59a2a..49de1b9 1006
On Thu, Mar 11, 2010 at 10:32:50AM +0200, Avi Kivity wrote:
> On 03/02/2010 02:14 AM, Marcelo Tosatti wrote:
> >On Mon, Mar 01, 2010 at 07:10:30PM +0100, Jan Kiszka wrote:
> >>This grand cleanup drops all reset and vmsave/load related
> >>synchronization points in favor of four(!) generic hooks:
>
On Thu, Mar 11, 2010 at 10:35:21AM +0200, Avi Kivity wrote:
> On 03/09/2010 03:53 AM, Marcelo Tosatti wrote:
> >Signed-off-by: Marcelo Tosatti
> >
> >Index: qemu-kvm-uq/target-i386/helper.c
> >===
> >--- qemu-kvm-uq.orig/target-i386/he
On Thu, Mar 11, 2010 at 5:03 AM, Alexander Graf wrote:
>
> On 11.03.2010, at 12:58, Avi Kivity wrote:
>
>> On 03/11/2010 01:56 PM, Alexander Graf wrote:
>>> On 11.03.2010, at 12:54, Avi Kivity wrote:
>>>
>>>
On 03/11/2010 01:25 PM, Alexander Graf wrote:
> The list is also still missi
On Thu, Mar 11, 2010 at 05:55:10PM +, Paul Brook wrote:
> sysconf(_SC_HUGEPAGESIZE); would seem to be the obvious answer.
There's not just one hugepage size and that thing doesn't exist yet
plus it'd require mangling over glibc too. If it existed I could use
it but I think this is better:
$ c
> On Thu, Mar 11, 2010 at 04:28:04PM +, Paul Brook wrote:
> > > > + /*
> > > > +* Align on HPAGE_SIZE so "(gfn ^ pfn)&
> > > > +* (HPAGE_SIZE-1) == 0" to allow KVM to take advantage
> > > > +* of hugepages with NPT/EPT.
> > > > +
Switch all users of qemu_set_fd_handler(fd, NULL, NULL, NULL) to this
new function.
Signed-off-by: Juan Quintela
---
audio/alsaaudio.c |4 ++--
audio/ossaudio.c |6 +++---
hw/xen_backend.c |4 ++--
migration-exec.c |2 +-
migration-fd.c|2 +-
migration-tcp.c |4 +
Signed-off-by: Juan Quintela
---
vl.c |5 +
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/vl.c b/vl.c
index f102a82..304d05c 100644
--- a/vl.c
+++ b/vl.c
@@ -2590,7 +2590,6 @@ void pcmcia_info(Monitor *mon)
typedef struct IOHandlerRecord {
int fd;
-IOCanReadHa
Now that there are no more poll_read users, we can remove it. Convert all
users to qemu_set_fd_handler().
Signed-off-by: Juan Quintela
---
aio.c |2 +-
migration-exec.c|6 +++---
migration-fd.c |4 ++--
migration-tcp.c | 10 +-
migration-unix.c
This way we can remove the poll test
Signed-off-by: Juan Quintela
---
qemu-char.c | 13 ++---
1 files changed, 2 insertions(+), 11 deletions(-)
diff --git a/qemu-char.c b/qemu-char.c
index bc294af..9098d79 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -1767,7 +1767,7 @@ static int udp
This way we can remove the poll test
Signed-off-by: Juan Quintela
---
qemu-char.c | 15 ---
1 files changed, 4 insertions(+), 11 deletions(-)
diff --git a/qemu-char.c b/qemu-char.c
index 063da94..875f254 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -536,15 +536,6 @@ static int fd
This way we can remove the poll test
Signed-off-by: Juan Quintela
---
qemu-char.c | 16 +---
1 files changed, 5 insertions(+), 11 deletions(-)
diff --git a/qemu-char.c b/qemu-char.c
index 875f254..bc294af 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -833,15 +833,6 @@ static int p
Signed-off-by: Juan Quintela
---
vl.c | 17 +++--
1 files changed, 7 insertions(+), 10 deletions(-)
diff --git a/vl.c b/vl.c
index e790c6a..52dc4f4 100644
--- a/vl.c
+++ b/vl.c
@@ -3846,20 +3846,17 @@ void main_loop_wait(int timeout)
if (ret > 0) {
IOHandlerRecord *p
This way we can remove the poll test
Signed-off-by: Juan Quintela
---
qemu-char.c | 18 +-
1 files changed, 5 insertions(+), 13 deletions(-)
diff --git a/qemu-char.c b/qemu-char.c
index 93b3ea4..063da94 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -1899,16 +1899,6 @@ static i
This way we can remove the poll test
Signed-off-by: Juan Quintela
---
qemu-char.c | 22 +++---
1 files changed, 7 insertions(+), 15 deletions(-)
diff --git a/qemu-char.c b/qemu-char.c
index 6ea4e8c..93b3ea4 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -664,8 +664,10 @@ static
It allways returned true, that is the equivalent of not having the
callback.
Signed-off-by: Juan Quintela
---
bt-host.c |9 +
1 files changed, 1 insertions(+), 8 deletions(-)
diff --git a/bt-host.c b/bt-host.c
index 964ac11..33b2761 100644
--- a/bt-host.c
+++ b/bt-host.c
@@ -80,13 +
values are already pointers, no need to cast them to void *
Signed-off-by: Juan Quintela
---
migration-exec.c |3 +--
migration-fd.c |3 +--
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/migration-exec.c b/migration-exec.c
index 6ff8449..5435827 100644
--- a/migration-
This way we can remove the poll test
Signed-off-by: Juan Quintela
---
net/tap.c | 27 +--
1 files changed, 9 insertions(+), 18 deletions(-)
diff --git a/net/tap.c b/net/tap.c
index 7a7320c..3ab65a3 100644
--- a/net/tap.c
+++ b/net/tap.c
@@ -61,17 +61,15 @@ typedef stru
Not clearing the fd and closing the file makes qemu spin using 100%CPU
after incoming migration error.
See for instance bug:
https://bugzilla.redhat.com/show_bug.cgi?id=518032
Signed-off-by: Juan Quintela
---
migration-exec.c |4 ++--
migration-fd.c |4 ++--
migration-tcp.c |5 ++
It was always only used for reads
Signed-off-by: Juan Quintela
---
qemu-char.c |4 ++--
qemu-char.h |7 +++
qemu-common.h |2 +-
qemu-tool.c |2 +-
vl.c |4 ++--
5 files changed, 9 insertions(+), 10 deletions(-)
diff --git a/qemu-char.c b/qemu-char.c
index
Signed-off-by: Juan Quintela
---
vl.c | 35 ++-
1 files changed, 14 insertions(+), 21 deletions(-)
diff --git a/vl.c b/vl.c
index 10d8e34..051eb1c 100644
--- a/vl.c
+++ b/vl.c
@@ -2597,10 +2597,12 @@ typedef struct IOHandlerRecord {
void *opaque;
/* t
This was the only incoming migration without autostart check
Signed-off-by: Juan Quintela
---
migration-unix.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/migration-unix.c b/migration-unix.c
index ce59a2a..49de1b9 100644
--- a/migration-unix.c
+++ b/migration-unix.c
*** BLURB HERE ***
Juan Quintela (16):
migration: Clear fd also in error cases
migration: unix migration should obey autostart are the other ones
Convert io handlers to QLIST
remove useless cast
rename IOCanRWHandler to IOCanReadHandler
bt: remove bt_host_read_poll()
Handle deleted I
> Paul Brook wrote:
> >> Is there any reason (other than being coding style) in using
> >> qemu_free() instead of free()? As per qem-malloc.c qemu_free() is
> >> nothing but free().
> >
> > The whole point of qemu_{malloc,free} is to isolate code from the system
> > implementation of malloc/free.
On Thu, Mar 11, 2010 at 04:28:04PM +, Paul Brook wrote:
> > > + /*
> > > + * Align on HPAGE_SIZE so "(gfn ^ pfn)&
> > > + * (HPAGE_SIZE-1) == 0" to allow KVM to take advantage
> > > + * of hugepages with NPT/EPT.
> > > + */
> > > + new_block->
> > + /*
> > +* Align on HPAGE_SIZE so "(gfn ^ pfn)&
> > +* (HPAGE_SIZE-1) == 0" to allow KVM to take advantage
> > +* of hugepages with NPT/EPT.
> > +*/
> > + new_block->host = qemu_memalign(1<< TARGET_HPAGE_BITS, size);
This sh
Avi Kivity writes:
> Signed-off-by: Avi Kivity
> ---
> CODING_STYLE |3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/CODING_STYLE b/CODING_STYLE
> index a579cb1..92036f3 100644
> --- a/CODING_STYLE
> +++ b/CODING_STYLE
> @@ -49,6 +49,9 @@ and is therefore likely t
Am 11.03.2010 15:19, schrieb Anthony Liguori:
> On 03/11/2010 02:34 AM, Kevin Wolf wrote:
>>
>> Well, if you're aware of the semantics of this value, it might be. It's
>> not exactly intuitive, but this is currently hidden inside qemu.
>>
>> What the high watermark says (in this implementation) is
On Thu, Mar 11, 2010 at 05:52:16PM +0200, Avi Kivity wrote:
> That is a little wasteful. How about a hint to mmap() requesting proper
> alignment (MAP_HPAGE_ALIGN)?
So you suggest adding a new kernel feature to mmap? Not sure if it's
worth it, considering it'd also increase the number of vmas be
On 03/11/2010 05:14 PM, Andrea Arcangeli wrote:
From: Andrea Arcangeli
This will allow proper alignment so NPT/EPT can take advantage of linux host
backing the guest memory with hugepages (only relevant for KVM and not for QEMU
that has no NPT/EPT support). To complete it, it will also notify
th
tags 573439 + upstream patch pending
thanks
Kouichi ONO wrote:
> Package: qemu-kvm
> Version: 0.12.3+dfsg-3
> Severity: normal
>
> Hello,
>
> On version 0.12.3, -drive serial=XXX option does not work.
> Below patch fixes it. 'serial' is pointer, not array.
>
>
> --- qemu-kvm-0.12.3+dfsg/vl.c 2
On 03/11/2010 04:54 PM, Anthony Liguori wrote:
I take it your not opposed to converting QEMUBH to be a QEMUNotifier?
If so, I'm happy to do it.
It's unclear to me why you've invented a new thing in the first place.
This style of callback has a number of advantages:
- It provides better type
On 03/11/2010 03:11 AM, Aurelien Jarno wrote:
>> +/* ??? MIPS64 no doubt has a larger address space. */
>> +#define TARGET_PHYS_ADDR_SPACE_BITS 32
>> +#define TARGET_VIRT_ADDR_SPACE_BITS 32
>> +
>
> In 32-bit mode, TARGET_VIRT_ADDR_SPACE_BITS is 32 bits, and
> TARGET_PHYS_ADDR_SPACE_BITS is 36 bi
From: Andrea Arcangeli
This will allow proper alignment so NPT/EPT can take advantage of linux host
backing the guest memory with hugepages (only relevant for KVM and not for QEMU
that has no NPT/EPT support). To complete it, it will also notify
the kernel that this memory is important to be back
On 03/11/2010 05:07 PM, Anthony Liguori wrote:
Still, if management is actually interested in the change, not just
to grow the volume (perhaps to handle out-of-space, or to check
against a global disk low condition), the helper/driver then needs to
communicate with the management system, whic
On 03/11/2010 08:42 AM, Avi Kivity wrote:
On 03/11/2010 04:36 PM, Paolo Bonzini wrote:
On 03/11/2010 02:42 PM, Avi Kivity wrote:
On 03/11/2010 03:25 PM, Paolo Bonzini wrote:
I didn't understand the advantage of making QEMUNotifier a
struct. Instead of using container_of, reusing QEMUBHFunc (re
On 03/11/2010 08:58 AM, Avi Kivity wrote:
On 03/11/2010 04:19 PM, Anthony Liguori wrote:
But honestly, while I do understand your point, this feels like a hack
to work around shortcomings of an interface. So what we need to decide
is which criterion outweighs the other in practice.
If I unde
On 03/11/2010 04:19 PM, Anthony Liguori wrote:
But honestly, while I do understand your point, this feels like a hack
to work around shortcomings of an interface. So what we need to decide
is which criterion outweighs the other in practice.
If I understand the use case correctly, what this re
On 03/11/2010 08:48 AM, Avi Kivity wrote:
Signed-off-by: Avi Kivity
---
CODING_STYLE |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/CODING_STYLE b/CODING_STYLE
index a579cb1..92036f3 100644
--- a/CODING_STYLE
+++ b/CODING_STYLE
@@ -49,6 +49,9 @@ and is therefore lik
On 03/11/2010 08:19 AM, Paul Brook wrote:
On 03/11/2010 06:57 AM, Paul Brook wrote:
+struct QEMUNotifier
+{
+void (*notify)(QEMUNotifier *notifier);
+};
I suggest combining this with QEMUBH.
I take it your not opposed to converting QEMUBH to be a QEMUNotifier?
If so
Signed-off-by: Avi Kivity
---
CODING_STYLE |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/CODING_STYLE b/CODING_STYLE
index a579cb1..92036f3 100644
--- a/CODING_STYLE
+++ b/CODING_STYLE
@@ -49,6 +49,9 @@ and is therefore likely to be changed.
Typedefs are used to elim
Don't rely on CDROM hint for read_only attribute
Signed-off-by: Naphtali Sprei
---
hw/scsi-disk.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/hw/scsi-disk.c b/hw/scsi-disk.c
index 8f7ffc1..5cd6ae6 100644
--- a/hw/scsi-disk.c
+++ b/hw/scsi-disk.c
@@ -612,8 +612,7 @@
Really use read-only flags for opening the file when asked for read-only
Signed-off-by: Naphtali Sprei
---
qemu-nbd.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/qemu-nbd.c b/qemu-nbd.c
index eac0c21..d803bfd 100644
--- a/qemu-nbd.c
+++ b/qemu-nbd.c
@@ -258,6 +258,7
On 03/11/2010 04:36 PM, Paolo Bonzini wrote:
On 03/11/2010 02:42 PM, Avi Kivity wrote:
On 03/11/2010 03:25 PM, Paolo Bonzini wrote:
I didn't understand the advantage of making QEMUNotifier a
struct. Instead of using container_of, reusing QEMUBHFunc (renamed to
QEMUCallbackFunc maybe?) in QEMUNo
On Thu, 11 Mar 2010, Nick Piggin wrote:
> On Thu, Mar 11, 2010 at 03:10:47AM +, Jamie Lokier wrote:
> > Paul Brook wrote:
> > > > > In a cross environment that becomes extremely hairy. For example the
> > > > > x86
> > > > > architecture effectively has an implicit write barrier before every
On 03/11/2010 02:42 PM, Avi Kivity wrote:
On 03/11/2010 03:25 PM, Paolo Bonzini wrote:
I didn't understand the advantage of making QEMUNotifier a
struct. Instead of using container_of, reusing QEMUBHFunc (renamed to
QEMUCallbackFunc maybe?) in QEMUNotifierNode [...]
seems cleaner. You would plac
On 03/11/2010 02:58 PM, Paul Brook wrote:
On 03/11/2010 01:57 PM, Paul Brook wrote:
+struct QEMUNotifier
+{
+void (*notify)(QEMUNotifier *notifier);
+};
I suggest combining this with QEMUBH.
I didn't understand this suggestion exactly, but I think it's related
that I didn't under
On Thursday 11 March 2010, Avi Kivity wrote:
> >> That would be much slower. The current scheme allows for an
> >> ioeventfd/irqfd short circuit which allows one guest to interrupt
> >> another without involving their qemus at all.
> >>
> > Yes, the serial line approach would be much slower,
> On 03/11/2010 06:57 AM, Paul Brook wrote:
> >> +struct QEMUNotifier
> >> +{
> >> +void (*notify)(QEMUNotifier *notifier);
> >> +};
> >
> > I suggest combining this with QEMUBH.
>
> I take it your not opposed to converting QEMUBH to be a QEMUNotifier?
> If so, I'm happy to do it.
It's unclea
On 03/11/2010 02:34 AM, Kevin Wolf wrote:
Well, if you're aware of the semantics of this value, it might be. It's
not exactly intuitive, but this is currently hidden inside qemu.
What the high watermark says (in this implementation) is the highest
offset into the image file of an cluster that w
On 03/11/2010 07:25 AM, Paolo Bonzini wrote:
On 03/11/2010 01:57 PM, Paul Brook wrote:
+struct QEMUNotifier
> +{
> +void (*notify)(QEMUNotifier *notifier);
> +};
I suggest combining this with QEMUBH.
I didn't understand this suggestion exactly, but I think it's related
that I didn't u
On Wed, 10 Mar 2010 10:51:07 -0600
Anthony Liguori wrote:
> For QMP, we just add an attribute which is backwards compatible. For the
> human
> monitor, we add (absolute) to the end of the line.
>
> Signed-off-by: Anthony Liguori
Looks good to me.
> ---
> input.c | 18 --
On 03/11/2010 07:36 AM, Avi Kivity wrote:
On 03/10/2010 06:51 PM, Anthony Liguori wrote:
+
+#ifndef QEMU_NOTIFY_H
+#define QEMU_NOTIFY_H
+
+#include "qemu-queue.h"
+
+typedef struct QEMUNotifier QEMUNotifier;
+typedef struct QEMUNotifierNode QEMUNotifierNode;
+
+struct QEMUNotifier
+{
+void
On 03/11/2010 06:57 AM, Paul Brook wrote:
+struct QEMUNotifier
+{
+void (*notify)(QEMUNotifier *notifier);
+};
I suggest combining this with QEMUBH.
I take it your not opposed to converting QEMUBH to be a QEMUNotifier?
If so, I'm happy to do it.
Regards,
Anthony Liguori
P
> On 03/11/2010 01:57 PM, Paul Brook wrote:
> > +struct QEMUNotifier
> >
> > > +{
> > > +void (*notify)(QEMUNotifier *notifier);
> > > +};
> >
> > I suggest combining this with QEMUBH.
>
> I didn't understand this suggestion exactly, but I think it's related
> that I didn't understand the a
On 03/11/2010 03:25 PM, Paolo Bonzini wrote:
On 03/11/2010 01:57 PM, Paul Brook wrote:
+struct QEMUNotifier
> +{
> +void (*notify)(QEMUNotifier *notifier);
> +};
I suggest combining this with QEMUBH.
I didn't understand this suggestion exactly, but I think it's related
that I didn't u
Create a kvm32 CPU model that describes a least common denominator
for KVM capable guest CPUs. Useful for migration purposes.
Signed-off-by: Andre Przywara
---
target-i386/cpuid.c | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/target-i386/cpuid.c b/target-
Some CPUID feature flags had no string value, so they could not be
switched on or off from the command line.
Add names for the missing ones mentioned in the current public CPUID
specification from both Intel and AMD. Those only mentioned in the
Linux kernel source I put as comments.
Signed-off-by:
Correct me if I am wrong, but kvm_trim looks like a really bloated
implementation of a bitwise AND. So remove this function and replace
it with the real stuff(TM).
Signed-off-by: Andre Przywara
---
target-i386/kvm.c | 27 ++-
1 files changed, 6 insertions(+), 21 deletio
Since 64-bit capability is just another CPUID bit we now properly
mask, there is no reason anymore to hide the 64-bit capable CPU
models from a 32-bit only QEMU. All 64-bit CPUs can be used
perfectly in 32-bit legacy mode anyway, so these models also make
sense for 32-bit.
Signed-off-by: Andre Prz
CPUID leaf Fn8000_0001.EDX contains a copy of many Fn_0001.EDX bits.
Define a name for this mask to improve readability and avoid typos.
Signed-off-by: Andre Przywara
---
target-i386/cpuid.c | 11 ++-
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/target-i386/cpuid.
Since we now have a real TCG feature set, use it to describe the
artificial qemu CPUs (both 64 and 32-bit). If new features are added
to TCG, the capability of qemu64/32 will automatically be adjusted.
Signed-off-by: Andre Przywara
---
target-i386/cpuid.c | 25 +
1 file
the host_cpuid function was located at the end of the file and had
a prototype before it's first use. Move it up and remove the
prototype.
Signed-off-by: Andre Przywara
---
target-i386/cpuid.c | 71 --
1 files changed, 34 insertions(+), 37 deleti
In KVM we trim the user provided CPUID bits to match the host CPU's
one. Introduce a similar feature to QEMU/TCG. Create a mask of TCG's
capabilities and apply it to the user bits.
This allows to let the CPU models reflect their native archetypes.
Signed-off-by: Andre Przywara
---
target-i386/cp
Bump up the xlevel number for qemu32 to allow parsing of the processor
name string for this model.
Similiarly the 486 processor should have at least the feature bit
leaf enabled.
Signed-off-by: Andre Przywara
---
target-i386/cpuid.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
-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: Andre Przywara
---
target-i386/cpu.h |6 +-
target-i386/cpu
Signed-off-by: Andre Przywara
---
target-i386/cpuid.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/target-i386/cpuid.c b/target-i386/cpuid.c
index 56ae71a..1e1c25b 100644
--- a/target-i386/cpuid.c
+++ b/target-i386/cpuid.c
@@ -757,6 +757,9 @@ void x86_cpu_list (FILE
Hi,
a rebased and refined version of my CPUID cleanup series. This should
now apply on top of git head. Compared to the last post this leaves
out the bits already done by John Cooper's patch. Also I added a separate
patch to deal with an accidently removed line (patch 3/13).
This patchset cleans
This one was accidently removed with commit
bb0300dc57c10b3721451b0ff566a03f9276cc77
Signed-off-by: Andre Przywara
---
target-i386/cpuid.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/target-i386/cpuid.c b/target-i386/cpuid.c
index 5e4f057..1bceb4b 100644
--- a/targe
On 03/10/2010 06:51 PM, Anthony Liguori wrote:
+
+#ifndef QEMU_NOTIFY_H
+#define QEMU_NOTIFY_H
+
+#include "qemu-queue.h"
+
+typedef struct QEMUNotifier QEMUNotifier;
+typedef struct QEMUNotifierNode QEMUNotifierNode;
+
+struct QEMUNotifier
+{
+void (*notify)(QEMUNotifier *notifier);
+};
+
+s
On 03/11/2010 01:57 PM, Paul Brook wrote:
+struct QEMUNotifier
> +{
> +void (*notify)(QEMUNotifier *notifier);
> +};
I suggest combining this with QEMUBH.
I didn't understand this suggestion exactly, but I think it's related
that I didn't understand the advantage of making QEMUNotifier
On Thu, 11 Mar 2010 14:00:46 +0100
Alexander Graf wrote:
>
> On 11.03.2010, at 13:59, Luiz Capitulino wrote:
>
> > On Thu, 11 Mar 2010 10:43:09 +0100
> > Paolo Bonzini wrote:
> >
> >> On 03/11/2010 08:55 AM, Avi Kivity wrote:
> >>> On 03/10/2010 11:30 PM, Luiz Capitulino wrote:
>
>
On Thu, 11 Mar 2010 13:09:37 +0100
Paolo Bonzini wrote:
> On 03/11/2010 12:25 PM, Alexander Graf wrote:
> > == Write a C QMP library based on QEMU JSON and QMP code ==
> >
> > Suggested by Anthony, mentored by Anthony?:) Possible other
> > candidates are Luiz and Kraxel I guess? I haven't really
On Thu, 11 Mar 2010 12:25:24 +0100
Alexander Graf wrote:
> == Write a C QMP library based on QEMU JSON and QMP code ==
>
> Suggested by Anthony, mentored by Anthony? :) Possible other candidates are
> Luiz and Kraxel I guess? I haven't really tracked QMP that much.
I didn't candidate as a men
Am 09.03.2010 02:13, schrieb Rob Earhart:
> Modify the snapshot load path to find and load snapshots contained in backing
> disks, useful when the current disk is a differencing disk.
>
> Add the source of a snapshot when listing snapshots.
>
> This should only break backwards compatibility for s
On Wed, 2010-03-10 at 18:30 -0300, Luiz Capitulino wrote:
> Hi there,
>
> Our wiki page for the Summer of Code 2010 is doing quite well:
>
> http://wiki.qemu.org/Google_Summer_of_Code_2010
Just to let you guys know that I'm going to give a talk at the local
university (Unicamp) about kvm autote
On 03/11/2010 02:57 PM, Arnd Bergmann wrote:
On Thursday 11 March 2010, Avi Kivity wrote:
A totally different option that avoids this whole problem would
be to separate the signalling from the shared memory, making the
PCI shared memory device a trivial device with a single memory BAR,
and u
Hi all,
When I run qemu-arm it gives me following error:
qemu-arm: symbol lookup error: qemu-arm: undefined symbol: sys_inotify_rm_watch
Any idea?
-Taimoor
_
Hotmail: Trust
On 11.03.2010, at 13:59, Luiz Capitulino wrote:
> On Thu, 11 Mar 2010 10:43:09 +0100
> Paolo Bonzini wrote:
>
>> On 03/11/2010 08:55 AM, Avi Kivity wrote:
>>> On 03/10/2010 11:30 PM, Luiz Capitulino wrote:
2. Do we have kvm-specific projects? Can they be part of the QEMU project
On Thu, 11 Mar 2010 10:43:09 +0100
Paolo Bonzini wrote:
> On 03/11/2010 08:55 AM, Avi Kivity wrote:
> > On 03/10/2010 11:30 PM, Luiz Capitulino wrote:
> >>
> >> 2. Do we have kvm-specific projects? Can they be part of the QEMU project
> >> or do we need a different mentoring organization for it?
On Thursday 11 March 2010, Avi Kivity wrote:
> > A totally different option that avoids this whole problem would
> > be to separate the signalling from the shared memory, making the
> > PCI shared memory device a trivial device with a single memory BAR,
> > and using something a higher-level concep
> +struct QEMUNotifier
> +{
> +void (*notify)(QEMUNotifier *notifier);
> +};
>
I suggest combining this with QEMUBH.
Paul
On 03/09/2010 07:24 PM, Jes Sorensen wrote:
Hi,
This is the last piece needed for QEMU-KVM to match the changes that
went into upstream QEMU.
Applied, thanks.
--
error compiling committee.c: too many arguments to function
On 03/10/2010 11:30 PM, Luiz Capitulino wrote:
2. Do we have kvm-specific projects? Can they be part of the QEMU project
or do we need a different mentoring organization for it?
Complete big real mode emulation. I'll add this.
--
error compiling committee.c: too many arguments to func
> On 03/10/2010 07:41 PM, Paul Brook wrote:
> >>> You're much better off using a bulk-data transfer API that relaxes
> >>> coherency requirements. IOW, shared memory doesn't make sense for TCG
> >>
> >> Rather, tcg doesn't make sense for shared memory smp. But we knew that
> >> already.
> >
> > I
On 03/11/2010 02:03 PM, Alexander Graf wrote:
Another idea I'd have would be upstream integration (and cleanup) of the ARM
KVM port: https://wiki.ncl.cs.columbia.edu/wiki/index.php/AndroidVirt:MainPage
Huh, didn't even know this thing existed. Definitely something to merge.
--
error comp
On 03/11/2010 12:25 PM, Alexander Graf wrote:
== Write a C QMP library based on QEMU JSON and QMP code ==
Suggested by Anthony, mentored by Anthony?:) Possible other
candidates are Luiz and Kraxel I guess? I haven't really tracked QMP
that much.
If you guys are okay with this, I think I could
1 - 100 of 115 matches
Mail list logo
