gmane.comp.emulators.qemu

[PATCH 1/2] chardev: Make the name of memory deviceconsistent

Lei Li — 2013-05-21T10:27:58

Now we have memory char device, but the backend name of it
is a little confusion. We actually register it by 'memory', but
the description in qemu-option, the name of open functions
and the new api backend called it 'ringbuf'. It should keep
consistent. This patch named it all to 'memory'.

Signed-off-by: Lei Li <lilei< at >linux.vnet.ibm.com>
---
 qapi-schema.json |    6 +++---
 qemu-char.c      |   16 ++++++++--------
 qemu-options.hx  |    6 +++---
 3 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/qapi-schema.json b/qapi-schema.json
index 9302e7d..664b31f 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
< at >< at > -3286,7 +3286,7 < at >< at >
                                  '*rows'   : 'int' } }
 
 ##
-# < at >ChardevRingbuf:
+# < at >ChardevMemory:
 #
 # Configuration info for memory chardevs
 #
< at >< at > -3294,7 +3294,7 < at >< at >
 #
 # Since: 1.5
 ##
-{ 'type': 'ChardevRingbuf', 'data': { '*size'  : 'int' } }
+{ 'type': 'ChardevMemory', 'data': { '*size'  : 'int' } }
 
 ##
 # < at >ChardevBackend:
< at >< at > -3321,7 +3321,7 < at >< at >

[PATCH 0/2 v2] Chardev related fixes

Lei Li — 2013-05-21T10:27:57

This series tries to fix the consistency of char devices
ringbuf and a regression of chardev filename.

Changes since v1:
  - Rename the struct related to new qapi ringbuf to memory, and
    fix the wrong description in qemu-option from Paolo.

Lei Li (2):
  chardev: Make the name of memory device consistent
  chardev: Get filename for new qapi backend

 qapi-schema.json |    6 +++---
 qemu-char.c      |   18 ++++++++++--------
 qemu-options.hx  |    6 +++---
 3 files changed, 16 insertions(+), 14 deletions(-)

Re: [PATCH v3 0/8] block: drive-backup live backupcommand

Paolo Bonzini — 2013-05-21T10:36:33

Il 21/05/2013 12:34, Stefan Hajnoczi ha scritto:

Agreed.  Though this is something that management must do manually,
isn't it?  QEMU cannot distinguish a SIGKILL from a power failure, while
management can afford treating SIGKILL as a power failure.


Paolo

Re: [PATCH v3 0/8] block: drive-backup live backupcommand

Stefan Hajnoczi — 2013-05-21T10:34:13

I'd err on the side of caution, mark the persistent dirty bitmap while
QEMU is running.  Discard the file if there was a power failure.

It really depends what the dirty bitmap users are doing.  It could be
okay to have a tiny chance of missing a modification but it might not.

Stefan

[PATCH 2/2] chardev: Get filename for new qapi backend

Lei Li — 2013-05-21T10:27:59

This patch sets the filename when the new qapi backend
init from opts.

The previous patch and discussions as link below:

http://patchwork.ozlabs.org/patch/243896/

If anyone who have better idea to fix this please let
me know your suggestions.

Signed-off-by: Lei Li <lilei< at >linux.vnet.ibm.com>
---
 qemu-char.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/qemu-char.c b/qemu-char.c
index ebeed04..781e969 100644
--- a/qemu-char.c
+++ b/qemu-char.c
< at >< at > -3276,6 +3276,7 < at >< at > CharDriverState *qemu_chr_new_from_opts(QemuOpts *opts,
         ChardevReturn *ret = NULL;
         const char *id = qemu_opts_id(opts);
         const char *bid = NULL;
+        char *filename = g_strdup(qemu_opt_get(opts, "backend"));
 
         if (qemu_opt_get_bool(opts, "mux", 0)) {
             bid = g_strdup_printf("%s-base", id);
< at >< at > -3308,6 +3309,7 < at >< at > CharDriverState *qemu_chr_new_from_opts(QemuOpts *opts,
         }
 
         chr = qemu_chr_find(id);
+        chr->filename = filename;
 
     qapi_out:

Re: [for 1.5? Qemu-devel] [PATCH 2/3] chardev: Make the name of ringbuf device consistent

Lei Li — 2013-05-21T10:14:22

Sure, patches based on this will be send out soon.
Thanks!

Re: [qemu-devel][libvirt] Default machine type setting for ppc64

Peter Maydell — 2013-05-21T10:22:37

I think this would make sense. Currently for ARM to get KVM
acceleration you have to use a specific guest CPU (A15), and
so you have to use a machine which supports that CPU (currently
just vexpress-a15). But we don't expose any way for libvirt to
tell that it needs an A15 or which machine models support which
CPUs. In fact we don't even give a sensible error message if
you try to use a wrong CPU, we'll just blithely push ahead
and behave very weirdly.

thanks

Re: [qemu-devel][libvirt] Default machine type setting for ppc64

Daniel P. Berrange — 2013-05-21T10:01:36

Obviously not, since you've not specified any machine type and
thus you'll get the default. If you don't like that, change your
app to request a specific machine type.


That's just the way it was chosen to be represented when first
implemented. In hindsight that may be sub-optimal, but libvirt
will not change existing XML schema design since that breaks
back compatibilty which is worse.


If QEMU can provide more intelligent info in this respect, then
libvirt can use it. We're doing the best we can with picking
defaults given the info QEMU currently provides us.


Daniel

Re: [PATCH] ps2: add support of auto-repeat

Paolo Bonzini — 2013-05-21T09:54:00

Il 21/05/2013 11:51, Amos Kong ha scritto:

Probably.  Testing Windows is enough, I didn't think of it.

Which backends did you test among SDL/VNC/SPICE/GTK+?

Paolo

Re: [PATCH arm-devs v1 4/5] sd/sdhci.c: Fix bdata_readDPRINT message

Peter Maydell — 2013-05-21T09:47:52

Reviewed-by: Peter Maydell <peter.maydell< at >linaro.org>

Re: [PATCH] ps2: add support of auto-repeat

Amos Kong — 2013-05-21T09:51:54




When I test with linux guest, set rate by 'kbdrate -r ..',
emulated PS2 device can get a keyboard_write (cmd: 0xf3), rate will
be set, auto-repeat rate can be controlled.

I also tested by Win7, set rate by 'mode con rate=2',emulated PS2
device can get a keyboard_write (cmd: 0xf3), rate will
be set, auto-repeat rate can be controlled.

Is it enough to prove the auto-repeat implemented in ps2 is ok?
 

In FreeDOS, I set rate by 'mode con rate=2', got a success prompt.
but emulated PS2 device can't get a keyboard_write (cmd: 0xf3) in init
stage & when I execute mode command. Auto-repeat always use default
rate in qemu-ps2 code.

FreeDOS bug?

Will study it tomorrow.

Re: [PATCH arm-devs v1 1/5] sd/sd.c: Fix "inquiry"ACMD41

Peter Maydell — 2013-05-21T09:46:03

Reviewed-by: Peter Maydell <peter.maydell< at >linaro.org>

Re: [qemu-devel][libvirt] Default machine type setting for ppc64

Daniel P. Berrange — 2013-05-21T09:25:07

What is the application above libvirt you are using ? It clearly
needs to be fixed if it is to use non-x86 archs successfully.


Daniel

Re: [qemu-devel][libvirt] Default machine type setting for ppc64

Peter Maydell — 2013-05-21T09:24:52


Right. I think we've now identified the bit of software
whose x86-centric assumptions need fixing :-)

thanks

[Bug 1182344] Re: ARM: invalid code execution aftersubs instruction

Sebastian Huber — 2013-05-21T09:07:27

** Attachment added: "ELF file of the application."
   https://bugs.launchpad.net/qemu/+bug/1182344/+attachment/3682743/+files/app.exe

Re: [PATCH] ps2: add support of auto-repeat

Amos Kong — 2013-05-21T09:04:30

Yes, if we don't process events from host, the rate set in guest
doesn't work for SDL/VNC/SPICE/..

I have fixed it by ignoring continual/repated(same keycode) press
events. It works now :)

I just tested by Linux guest (set rate by 'kbdrate -s ..'),
will test with FreeDOS.
 
                Amos.

Re: [qemu-devel][libvirt] Default machine type setting for ppc64

Li Zhang — 2013-05-21T09:02:51

Currently, the next layer above libvirt is not configurable.
It is dependent on this default setting. Users also expect
to start one VM successfully by default.

Thanks.

Re: [PATCH 2/2] pcie: Add more ASPM support

Michael S. Tsirkin — 2013-05-21T08:45:56

Okay. The closest thing is when we made SERR enable writeable.
You can grep for command_serr_enable and QEMU_PCI_CAP_SERR_BITNR.


I agree and at least for L0s, I think it's worth fixing.
It looks like we could advertize L1 or ignore it,
so I don't mind what happens there, it's up to you to decide.

Re: [PATCH v2 1/2] net: introduce MAC_TABLE_CHANGED event

Michael S. Tsirkin — 2013-05-21T08:51:17

I still think it will work, since the event does not have any
information, what does it matter that we send one and not many events?


Looks a bit too complex, to me.

Re: [PATCH] ps2: add support of auto-repeat

Amos Kong — 2013-05-21T08:33:56

Please correct me if something is wrong, thanks.

When we use VNC/SPICE/SDL, vm Window will captured the key events,
then qemu process the events and transfer to guest through emulated PS2
device.

When we hold the key in keyboard of host, real keyboard or host OS will
do auto-repeat. vm Window will transfer repeated events to guest.
In this case, it seems the auto-repeat of emulated PS2 device doesn't
needed.

But when keyboard/host os doesn't support auto-repeat, or we directly
send event from monitor by 'sendkey'. held key could not be repeated
without auto-repeat support of emulated PS2 device.


When I use (Lenovo t430s & Fedoar 18 host), when I hold the real key,
qemu will get PPPPPPPR style events queue from host.

Guest (RHEL6/Win7/WinXp) & (SDL & VNC & SPICE) works well.


Others:
1. I read the keyboard driver in linux kernel, soft_auto-repeat was
   implemented in linux ps2 driver is PPPPPPPR style.

2. PPPPPPPPR style is described in freescale hardware manual:
   http://www.freescale.com/files/mi

Re: [qemu-devel][libvirt] Default machine type setting for ppc64

Daniel P. Berrange — 2013-05-21T08:39:53

Libvirt has always had support for specifying what machine type to use.
This discussion is simply about what machine type to default to, if the
user hasn't explicitly asked for one.

QEMU has the notion of a default machine for each target, and that is
what libvirt uses if the user hasn't specified a machine.  It is not
libvirt's job to override QEMU's notion of the default machine here,
so if the 'mac99' machine type isn't suitable as the default either
QEMU needs to change that for the ppc target, or the user needs to
explicitly specify their desired machine type.

Regards,
Daniel