Re: [Qemu-devel] [Qemu-trivial] [PATCH] main-loop: For tools, initialize timers as part of qemu_init_main_loop()

[Paolo Bonzini]

On 01/27/2012 06:46 AM, Stefan Hajnoczi wrote:

#ifndef _WIN32
#ifdef __linux__
 {"dynticks", dynticks_start_timer,
  dynticks_stop_timer, dynticks_rearm_timer},
#endif
 {"unix", unix_start_timer, unix_stop_timer, unix_rearm_timer},
#else
 {"mmtimer", mm_start_timer, mm_stop_timer, mm_rearm_timer},
 {"dynticks", win32_start_timer, win32_stop_timer, win32_rearm_timer},
#endif

It seems Windows host already has a "dynticks" implementation.  Have you
tried using this instead of "mmtimer"?


The dynticks Win32 timer doesn't boot Linux successfully, even though 
under Wine it works and it is actually more reliable than mmtimer (which 
is why I haven't thrown it away yet).



mm_start_timer() is using 1 ms intervals!


No, it's setting a 1 ms system quantum via timeBeginPeriod.  The actual 
implementation is using dynamic rather than periodic ticks (it has a 
rearm callback).  We threw away periodic timers a few months ago.


The problem is that Windows doesn't have something like Linux NOHZ and 
limits the timer resolution to the system quanta.  That's 1 ms for 
mmtimer and 10 ms (the default) for dynticks right now.  However, I 
suspect that the solution is to move timeBeginPeriod and timeEndPeriod 
from timer code to generic QEMU code, dynticks would start working on 
native Windows too.  Besides possibly fixing QEMU, it would definitely 
fix Michael's problem, too.  Tools do not need such a fine-grained 
timer, and shorter quanta cause the increased CPU usage that Michael 
observed.


However, Michael's patch makes sense as a cleanup anyway.  Since we have 
an initialization function, there's no need to have that _and_ a 
constructor.


Paolo

Re: [Qemu-devel] [RFC PATCH 5/7] vl.c: added -kerndtb option

[Markus Armbruster]

Eric Blake  writes:

> On 01/26/2012 12:34 PM, Scott Wood wrote:
>> On 01/24/2012 12:23 PM, Stefan Weil wrote:
>>> I'd prefer a different solution. As far as I have understood,
>>> the dtb is only useful with a kernel, so it could be handled
>>> as an optional attribute to the -kernel parameter:
>>>
>>> -kernel IMAGE[,dtb=DTB]
>>>
>>> Of course the same applies to -append, but that's a different issue.
>> 
>> -initrd as well.
>> 
>> This would mean you couldn't have a comma in a filename (shouldn't come
>> up often, but still ugly).
>
> In other instances where you use a comma to separate arguments and also
> want to accept commas in arbitrary file names, qemu has used the notion
> of a double comma as being the escape sequence for a single comma in the
> intended file name, rather than a separator for later arguments.

Use QemuOpts for NAME=VALUE,... arguments.  Common code, common
syntactic conventions.

Re: [Qemu-devel] [PATCH v2 07/10] block: add a transfer rate for floppy types

[Markus Armbruster]

Kevin Wolf  writes:

> Am 21.01.2012 20:02, schrieb Blue Swirl:
>> On Mon, Jan 16, 2012 at 10:18, Kevin Wolf  wrote:
>>> Am 15.01.2012 08:51, schrieb Hervé Poussineau:
 Floppies must be read at a specific transfer rate, depending of its own 
 format.
 Update floppy description table to include required transfer rate.

 Signed-off-by: Hervé Poussineau 
 ---
  block.c  |   74 
 -
  block.h  |   10 +++-
  hw/fdc.c |3 +-
  hw/pc.c  |3 +-
>>>
>>> Meh. Having any floppy-specific logic in the block layer is wrong. We
>>> need to finally get this moved into fdc.c.
>> 
>> Well, actually this code was moved recently from fdc.c to block.c
>> (5bbdbb4676d17e782ae83055bac58e0751b25e4b). The other geometry
>> guessing functions (ATA CHS) are also there. If we supported native
>> floppy (or ATA) pass trough, the geometry would have to be read from
>> the host device, so I think it's logical to keep that in block level
>> instead of all devices. Maybe we could also split block.c into
>> block-fdc.c, block-ata.c etc.
>
> The geometry is guest state, so it shouldn't be in the block layer,
> which deals with host state.

Fully agree.

I tried to tackle geometry in my quest to untangle block device host and
guest state, but didn't get far.

>  Maybe we could need some hw/block.c that
> deals with guest state concepts that are shared between multiple device.
> Images or passthrough backends could provide defaults.
>
> I'll admit that not having an obvious place for media (we only have it
> for images and guest devices) doesn't make the design decisions easier.

Yup.

Re: [Qemu-devel] [PATCH v3 1/9] fdc: take side count into account

[Markus Armbruster]

Hervé Poussineau  writes:

> Floppies can be simple or double-sided. However, current code
> was only taking the common case into account (ie 2 sides).

Impact?  Are single sided floppies broken before the patch?  How?

Re: [Qemu-devel] [Qemu-trivial] [PATCH] scsi: Guard against buflen exceeding req->cmd.xfer in scsi_disk_emulate_command

[Paolo Bonzini]

On 01/27/2012 06:59 AM, Stefan Hajnoczi wrote:

>  Signed-off-by: Thomas Higdon
>  ---

Kevin: Will you take this through your block/scsi tree?


Yes, he did already.

Paolo

Re: [Qemu-devel] [PATCH 01/15] pc: merge pc_piix.c into pc.c

[Jan Kiszka]

On 2012-01-26 20:00, Anthony Liguori wrote:
> A long time ago, there was a grand plan to merge q35 chipset support.  The 
> start
> of that series was a refactoring of pc.c which split a bunch of the "common"
> functionality into a separate file that could be shared by the two.
> 
> But q35 never got merged and the refactoring, in retrospect, just made things
> worse.  Making things proper objects and using composition is the right way
> to share common devices.
> 
> By pulling these files back together, we can start to fix some of this mess.

There are surely things to clean up and improve, but a clear NACK for
the general direction.

It's undoubted that we need a more modern chipset than this ancient
PIIX3, rather sooner than later. And it is clear that there is a good
amount of generic functions in pc.c for building a PC, even a fairly
modern one. So we need a common lib for PC chipsets and would only
revert what you start here.

Please name what you do not like, and then we can fix that concretely.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: [Qemu-devel] [Qemu-trivial] [PATCH] keep the PID file locked for the lifetime of the process

[Laszlo Ersek]

On 01/27/12 07:36, Stefan Hajnoczi wrote:

On Thu, Jan 26, 2012 at 10:36:41PM +0100, Laszlo Ersek wrote:

The lockf() call in qemu_create_pidfile() aims at ensuring mutual
exclusion. We shouldn't close the pidfile on success, because that drops
the lock as well [1]:

 "File locks shall be released on first close by the locking process
 of any file descriptor for the file."

Coverity may complain again about the leaked file descriptor; let's
worry about that later.

[1] http://pubs.opengroup.org/onlinepubs/9699919799/functions/lockf.html

Signed-off-by: Laszlo Ersek
---


Isn't the normal way to do pidfiles O_CREAT | O_EXCL?


Yes, it is.


It may not work
on all NFS versions but putting the pidfile on NFS doesn't really make
sense.

Then we can drop the lockf(3) completely.


When you rely on O_EXCL to ensure mutual exclusion, and an abruptly 
terminated process leaves the lockfile lying around, then the user has 
to clean it up manually before starting the next instance (and double 
check if the pid file is in fact stale or not). I'm personally OK with 
that, but I reckoned the qemu code tried to avoid that intentionally. 
Record locks can't remain stale when the process dies.


Laszlo

Re: [Qemu-devel] [Android-virt] [PATCH 02/12] arm: make the number of GIC interrupts configurable

[Peter Maydell]

On 27 January 2012 00:33, Rusty Russell  wrote:
> Peter Maydell wrote:
>> Anyway, if we would otherwise die horribly later on we should
>> catch these cases, but it would be good to have at least a comment
>> saying that these are implementation limitations rather than
>> architectural ones.
>
> Good point.  If we add an "supported" bit to each irq, we could do weird
> things, but presumably ->num_irq would still correspond to
> ITLinesNumber.
>
> I don't want to put too much of an essay in there.  How's this:
>
>        /* ITLinesNumber is represented as (N - 32) / 1.  See
>          gic_dist_readb. */
>        if (s->num_irq < 32 || (s->num_irq % 32)) {
>                hw_error("%u interrupt lines unsupported: not divisible by 
> 32\n",
>                         num_irq);

I think that's a notch too terse for my taste. How about:

/* ITLinesNumber is represented as (N - 32) / 1 (see
 * gic_dist_readb) so this is an implementation imposed
 * restriction, not an architectural one:
 */

thanks
-- PMM

Re: [Qemu-devel] [PATCH v3 5/9] fdc: add CCR (Configuration Control Register) write register

[Markus Armbruster]

Hervé Poussineau  writes:

> DIR and CCR registers share the same address ; DIR is read-only
> while CCR is write-only

Looks like guest writes to CCR are silently ignored before this patch.
Is that correct?  Impact?

Re: [Qemu-devel] [PATCH v3 9/9] fdc: DIR (Digital Input Register) should return status of current drive...

[Markus Armbruster]

Impact?  What exactly is broken and fixed?

Re: [Qemu-devel] [PATCH v3 7/9] fdc: check if media rate is correct before doing any transfer

[Markus Armbruster]

Hervé Poussineau  writes:

> The programmed rate has to be the same as the required rate for the
> floppy format ; if that's not the case, the transfer should abort.
>
> Revalidate floppy after migration, so media_rate field doesn't have
> to be saved/restored.

I'm not at all sure that's a good idea.

The rate is guest state.  It's value depends on the media.  We guess the
media to use for a particular image.  Same thing as for the geometry
(heads, tracks, sectors per track).  We do migrate the geometry, see
vmstate_fdrive.

Why is it a good idea to treat rate differently?

Doesn't your fd_revalidate() in fdc_post_load() clobber the migrated
geometry?

[Qemu-devel] cry for help: wiki.qemu.org spam

[Michael Tokarev]

The amount of spam our wiki.qemu.org collects, is
increasing every day.  It was easy several months
ago to manually delete these pages once a week to
keep wiki spam-free, now they sometimes manage to
re-create a page while I delete it!

No, it is not counted in 1000s per day - not yet
anyway.  But 10..20 new users with the same amount
of new spam pages per day become a norm.

To see how it looks like, see the RecentChanges:

 http://wiki.qemu.org/Special:RecentChanges

There, each new user adds one spam page.  And see
this link

 http://wiki.qemu.org/index.php?title=Special:RecentChanges&hidebots=0

to see my actions too.

What complicates things alot for me is the fact
that now, after wiki changes, *every* "Delete page"
operation takes 30..60 seconds to complete, and
during all this time the wiki is not doing anything.
This should be fixed too, I think.

Now, I think the best course is to restrict new
user creation, require moderation for new users.
The best will be to ask them to write some words
in the confirmation email as of why they want the
account, -- so that the moderator will be able to
tell somewhat if this is for real or not; but I've
no idea if such a feature exists in mediawiki.

I can play moderational role, -- this at least should
be significantly easier than my current delete page
approach.

And if not, I'd love to see Nuke extension enabled --
http://www.mediawiki.org/wiki/Extension:Nuke -- which
should help with page deletion.

Any other suggestions are ofcourse welcome.

Thanks,

/mjt

Re: [Qemu-devel] [PATCH v6] qdev: Add support for property type bool

[Andreas Färber]

Am 27.01.2012 07:23, schrieb Stefan Hajnoczi:
> On Tue, Jan 24, 2012 at 06:17:36PM +0100, Andreas Färber wrote:
>> From: Andreas Färber 
>>
>> VMState supports the type bool but qdev instead supports bit, backed by
>> uint32_t. Therefore let's add DEFINE_PROP_BOOL() and qdev_prop_set_bool().
>>
>> bool by definition is either true or false. Should the need arise to
>> parse yes/no, on/off, 1/0 or whatever as well, we can still add that at
>> a later point in time.
>>
>> Signed-off-by: Andreas Färber 
>> Cc: Juan Quintela 
>> Cc: Markus Armbruster 
>> Cc: Jan Kiszka 
>> Cc: Vasilis Liaskovitis 
>> ---
>>  v5 -> v6:
> 
> Please merge through a qemu.git committer.  v6 and discussion means this
> isn't trivial.

Unfortunately that hasn't happened for half a year though. Generally no
qemu.git committer seems to care about cherry-picking useful
infrastructures from bigger series even once discussions are resolved.

And for the record, it's net v3 as shown in the part you snipped.

Vasilis, unless Jan or someone has further nitpicks, just prepend my v8
to your series and reuse its DEFINE_PROP_BOOL().

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] [PATCH] qmp: add BLOCK_MEDIUM_EJECT event

[Kevin Wolf]

Am 26.01.2012 18:57, schrieb Luiz Capitulino:
> On Wed, 25 Jan 2012 10:42:04 -0200
> Luiz Capitulino  wrote:
> 
>> On Wed, 25 Jan 2012 09:41:20 +0100
>> Kevin Wolf  wrote:
>>
>>> Am 24.01.2012 21:03, schrieb Eric Blake:
 On 01/24/2012 11:16 AM, Luiz Capitulino wrote:
> Libvirt wants to be notified when the guest ejects a medium, so that
> it can update its view of the guest.
>
> This code has been originally written by Daniel Berrange. It adds
> the event to IDE and SCSI emulation.
>
> Please, note that this only covers guest initiated ejects, that's,
> the QMP/HMP commands 'eject' and 'change' are not covered.
>>>
>>> What's the reason for this behaviour? It feels inconsistent.
>>
>> I don't think it's inconsistent because we're limiting it to guest initiated
>> actions. Also, the mngt app knows when it sends a 'eject' or 'change' 
>> command.
>> The exception is if it allows HMP to run in parallel with QMP, but I don't 
>> think
>> this is recommended (at least not for commands that change any VM state).
> 
> Let me elaborate more. We have two options:
> 
>  1. Emit the event for guest initiated ejects (this patch, although I think
> the event should be renamed to GUEST_MEDIUM_EJECT)
> 
>  2. Emit the event for guest & QMP initiated ejects, that's, also emit the
> event for the eject and change commands
> 
> The first thing to note is that, they're not mutually exclusive. If we do
> item 1 now, we can add 2 later (as a different event).
> 
> But my point is that doing 2 is problematic and we should avoid it. The 
> problem
> is that the semantics of eject and change are complex and/or buggy. And 
> something
> I've learned about confusing semantics in QMP is that, they will give you 
> headaches
> soon or later.

But I'm not really interested in the semantics of QMP commands, because
they are irrelevant for the events.

My view is that a device generates an event each time its try status
changes. If it opens the tray, it does so by calling bdrv_eject - an
obvious place to send an event. If it closes the tray or the eject
monitor command is used, we go through bdrv_dev_change_media_cb - not
quite as obvious, but I think this despite its name this is really a
"tray status changed externally" callback.

QMP commands may cause any of these actions to occur. But the event is
tied to the actions and not to the QMP commands that may or may not
cause them according to their confusing semantics.

> The main problem with eject is that it's inconsistent with the handling of
> the tray status. Try this:
> 
> 1. Eject with no medium inserted
> 
> (qemu) info block
> ide1-cd0: removable=1 locked=0 tray-open=0 io-status=ok [not inserted]
> (qemu) eject ide1-cd0
> (qemu) info block
> ide1-cd0: removable=1 locked=0 tray-open=0 io-status=ok [not inserted]
> (qemu) 
> 
> Conclusion: the tray didn't move, we shouldn't emit the event.

Fails before bdrv_close, so bdrv_dev_change_media_cb is never called.
Works as it is today.

> 
> 2. Eject with medium inserted
> 
> (qemu) info block
> ide1-cd0: removable=1 locked=0 tray-open=0 io-status=ok file=/tmp/vl.iKvBAF 
> backing_file=/mnt/fernando/isos/linux/Fedora-14-x86_64-DVD.iso ro=0 drv=qcow2 
> encrypted=0 bps=0 bps_rd=0 bps_wr=0 iops=0 iops_rd=0 iops_wr=0
> (qemu) eject ide1-cd0
> (qemu) info block
> ide1-cd0: removable=1 locked=0 tray-open=1 io-status=ok [not inserted]
> (qemu) 
> 
> Conclusion: the tray opened and the media was purged. We should emit the 
> event.

bdrv_dev_change_media_cb is called, we can emit an event there.

> 
> 3. Eject with medium inserted and locked
> 
> (qemu) info block
> ide1-cd0: removable=1 locked=1 tray-open=0 io-status=ok file=/tmp/vl.2LHApn 
> backing_file=/mnt/fernando/isos/linux/Fedora-16-x86_64-DVD.iso ro=0 drv=qcow2 
> encrypted=0 bps=0 bps_rd=0 bps_wr=0 iops=0 iops_rd=0 iops_wr=0
> (qemu) eject ide1-cd0
> Device 'ide1-cd0' is locked
> (qemu) info block
> ide1-cd0: removable=1 locked=0 tray-open=1 io-status=ok file=/tmp/vl.2LHApn 
> backing_file=/mnt/fernando/isos/linux/Fedora-16-x86_64-DVD.iso ro=0 drv=qcow2 
> encrypted=0 bps=0 bps_rd=0 bps_wr=0 iops=0 iops_rd=0 iops_wr=0
> (qemu) 
> 
> Conclusion: eject returned an error, but a few seconds later the tray opened 
> and
> the media wasn't purged. What happened here is that, the _guest_
> opened the tray. The code in this patch would trigger the event, 
> but
> we shouldn't emit it twice if we cover eject & change (ie. 
> special case)

bdrv_dev_change_media_cb is not called because media cannot be ejected
with a locked drive. Instead bdrv_dev_eject_request is called which
doesn't emit an event.

If the guest happens to initiate an eject itself after receiving the
eject request, it calls bdrv_eject, where we can emit an event.

If we had force=true in the initial eject command, bdrv_close is called,
which in turn goes through bdrv_dev_change_media_cb where an event is
emitted.

> 
> Each of the three cases ha

Re: [Qemu-devel] [PATCH 2/6] qdev-property: Make bit property parsing stricter

[Andreas Färber]

Am 27.01.2012 08:27, schrieb Stefan Hajnoczi:
> From: Jan Kiszka 
> 
> By using strncasecmp, we allow for arbitrary characters after the
> "on"/"off" string. Fix this by switching to strcasecmp.
> 
> Reviewed-by: Andreas Färber 
> Reviewed-by: Markus Armbruster 
> Signed-off-by: Jan Kiszka 
> Signed-off-by: Stefan Hajnoczi 

FWIW the ordering is wrong here. The tags are supposed to document the
patch flow: The patch was first signed off by the author (Jan), then
reviewed, then signed off by committers. Not first reviewed.

No need to respin but please keep in mind for the future.
(Yeah, did that wrong myself before.)

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] [PATCH] optionroms: Silence intermediate file removal

[Andreas Färber]

Am 23.01.2012 19:34, schrieb Jan Kiszka:
> The build process of optionroms spits out an "rm ..." line. Moreover, it
> removes all .o files that can be handy for debugging purposes.
> 
> Disable automatic intermediate removal and only clean up the unneeded
> and large .img and .raw files.
> 
> Signed-off-by: Jan Kiszka 
> ---
>  pc-bios/optionrom/Makefile |6 --
>  1 files changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/pc-bios/optionrom/Makefile b/pc-bios/optionrom/Makefile
> index 51da288..3edde85 100644
> --- a/pc-bios/optionrom/Makefile
> +++ b/pc-bios/optionrom/Makefile
> @@ -16,14 +16,16 @@ QEMU_CFLAGS = $(CFLAGS)
>  
>  build-all: multiboot.bin linuxboot.bin
>  
> +.SECONDARY:
> +
>  %.img: %.o
>   $(call quiet-command,$(LD) -Ttext 0 -e _start -s -o $@ $<,"  Building 
> $(TARGET_DIR)$@")
>  
>  %.raw: %.img
> - $(call quiet-command,$(OBJCOPY) -O binary -j .text $< $@,"  Building 
> $(TARGET_DIR)$@")
> + $(call quiet-command,$(OBJCOPY) -O binary -j .text $< $@; rm -f $<,"  
> Building $(TARGET_DIR)$@")
>  
>  %.bin: %.raw
> - $(call quiet-command,$(SHELL) $(SRC_PATH)/scripts/signrom.sh $< $@,"  
> Signing $(TARGET_DIR)$@")
> + $(call quiet-command,$(SHELL) $(SRC_PATH)/scripts/signrom.sh $< $@; rm 
> -f $<,"  Signing $(TARGET_DIR)$@")
>  
>  clean:
>   rm -f *.o *.d *.raw *.img *.bin *~

It's possible that objcopy or a shell script fails. In that case,
&& rm -f $<
or a second output-suppressed Makefile line might be a better than
; rm -f $<

Stefan's comment on .SECONDARY seconded. :)

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] [Qemu-trivial] [PATCH] keep the PID file locked for the lifetime of the process

[Daniel P. Berrange]

On Fri, Jan 27, 2012 at 06:36:39AM +, Stefan Hajnoczi wrote:
> On Thu, Jan 26, 2012 at 10:36:41PM +0100, Laszlo Ersek wrote:
> > The lockf() call in qemu_create_pidfile() aims at ensuring mutual
> > exclusion. We shouldn't close the pidfile on success, because that drops
> > the lock as well [1]:
> > 
> > "File locks shall be released on first close by the locking process
> > of any file descriptor for the file."
> > 
> > Coverity may complain again about the leaked file descriptor; let's
> > worry about that later.
> > 
> > [1] http://pubs.opengroup.org/onlinepubs/9699919799/functions/lockf.html
> > 
> > Signed-off-by: Laszlo Ersek 
> > ---
> 
> Isn't the normal way to do pidfiles O_CREAT | O_EXCL?  It may not work
> on all NFS versions but putting the pidfile on NFS doesn't really make
> sense.
> 
> Then we can drop the lockf(3) completely.

IMHO it is preferable to use lockf because that makes sure you are crash
safe, so you don't get later bogus startup failures due to stale pidfiles


Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

Re: [Qemu-devel] [Android-virt] [PATCH 00/12] Add support for Cortex-A15 and vexpress-a15

[Marc Zyngier]

On 17/01/12 19:08, Peter Maydell wrote:
> On 15 January 2012 22:56, Christoffer Dall  wrote:
>> On Fri, Jan 13, 2012 at 3:57 PM, Peter Maydell  
>> wrote:
>>> PPS: these patches are against qemu-master so for kvm you'd need
>>> to (a) rebase them on qemu-linaro (b) put the kvm patches on top
>>> of these (c) wait for me to do a. for you ;-)
>>
>> ok, I'll test this with the most recent KVM changes soon and also look
>> forward for your merge... :)
> 
> vexpress-a15 now in qemu-linaro git tree. However it doesn't boot under
> KVM:
> 
> root@LinaroE102767:~# /usr/local/bin/qemu-system-arm  -enable-kvm
> -kernel /a15-no-lpae-uImage  -m 128 -serial stdio -drive
> if=sd,file=/maz/vex
> press.img -M vexpress-a15 -display none -append "console=ttyAMA0
> earlyprintk rootwait mem=128M root=/dev/mmcblk0p2 rw --debug"
> Uncompressing Linux... done, booting the kernel.
> Booting Linux on physical CPU 0
> Linux version 3.1.0+ (petmay01@LinaroE102767) (gcc version 4.6.1
> (Ubuntu/Linaro 4.6.1-9ubuntu3) ) #19 SMP Fri Jan 13 12:23:22 GMT 2012
> CPU: ARMv7 Processor [412fc0f1] revision 1 (ARMv7), cr=10c5387f
> CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
> Machine: ARM-Versatile Express
> SoC: ARM VE Platform
> bootconsole [earlycon0] enabled
> Memory policy: ECC disabled, Data cache writealloc
> error: kvm run failed Invalid argument
> Aborted
> 
> Under TCG the next thing printed is
> ct_ca15x4_init_cpu_map: ncores 1
> Architected timer frequency not available
> sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 178956ms
> 
> ...possibly the kernel side needs to implement the A15 L2 cache control
> register, which is where the guest kernel picks up the number of cores
> from; see patch 10 for the TCG version.

I've pushed a new branch (kvm-v3.3-rc1) to my arm-platforms repo. It
contains a fix (or shall we call it a horrible hack?) for the above.

M.
-- 
Jazz is not dead. It just smells funny...

Re: [Qemu-devel] [PATCH v8] qdev: Add support for property type bool

[Andreas Färber]

Am 26.01.2012 16:54, schrieb Andreas Färber:
> From: Andreas Färber 
> 
> VMState supports the type bool but qdev instead supports bit, backed by
> uint32_t. Therefore let's add PROP_TYPE_BOOL and qdev_prop_set_bool().
> 
> With non-programmers in mind, instead of universal true/false provide
> two different property types:
> * on/off for DEFINE_PROP_SWITCH() (requested by Jan) and
> * yes/no for DEFINE_PROP_BOOL() (also accepting true/false as input).
> 
> Signed-off-by: Andreas Färber 
> Cc: Juan Quintela 
> Cc: Markus Armbruster 
> Cc: Jan Kiszka 
> Cc: Vasilis Liaskovitis 
> ---
>  v7 -> v8:
>  * Add missing extern qdev_prop_bool_switch for DEFINE_PROP_SWITCH().
> 
>  v6 -> v7:
>  * Rename existing "boolean" type to "bit".
>  * Re-introduce qdev_prop_set_bool().
>  * Split "bool" into "switch" (on/off) and "boolean" (yes/no; true/false 
> input).
> 
>  v5 -> v6:
>  * Rebased onto QOM properties.
>  * Parse and print true/false for bool, leave bit untouched.
>  Please review, v6 untested.
>  [* Accidentally dropped qdev_prop_set_bool().]
> 
>  v4 -> v5 (40P):
>  * Parse on/off in addition to yes/no for both bit and bool, print yes/no for 
> bool.
> 
>  v4 (ISA):
>  * Introduced.
>  hw/qdev-properties.c |  102 
> +-
>  hw/qdev.h|8 
>  2 files changed, 109 insertions(+), 1 deletions(-)
> 
> diff --git a/hw/qdev-properties.c b/hw/qdev-properties.c
> index 02f0dae..0b1e9ea 100644
> --- a/hw/qdev-properties.c
> +++ b/hw/qdev-properties.c
> @@ -86,7 +86,7 @@ static void set_bit(DeviceState *dev, Visitor *v, void 
> *opaque,
>  }
>  
>  PropertyInfo qdev_prop_bit = {
> -.name  = "boolean",
> +.name  = "bit",
>  .legacy_name  = "on/off",
>  .type  = PROP_TYPE_BIT,
>  .size  = sizeof(uint32_t),
> @@ -96,6 +96,101 @@ PropertyInfo qdev_prop_bit = {
>  .set   = set_bit,
>  };
>  
> +/* --- bool --- */
> +
> +static int parse_bool(DeviceState *dev, Property *prop, const char *str)
> +{
> +bool *ptr = qdev_get_prop_ptr(dev, prop);
> +if (strcmp(str, "true") == 0 || strcmp(str, "yes") == 0) {
> +*ptr = true;
> +} else if (strcmp(str, "false") == 0 || strcmp(str, "no") == 0) {

I just noticed that Jan's patch does strncasecmp() for bit, so if we
want those semantics here too (foo=TRUE,bar=False,foobar=yES) I can send
a v9. I really hate replying to myself though, so I'll wait a bit for
other review comments to avoid a further surge in patch revisions.

Andreas

> +*ptr = false;
> +} else {
> +return -EINVAL;
> +}
> +
> +return 0;
> +}
> +
> +static int parse_bool_switch(DeviceState *dev, Property *prop,
> + const char *str)
> +{
> +bool *ptr = qdev_get_prop_ptr(dev, prop);
> +if (strcmp(str, "on") == 0) {
> +*ptr = true;
> +} else if (strcmp(str, "off") == 0) {
> +*ptr = false;
> +} else {
> +return -EINVAL;
> +}
> +
> +return 0;
> +}
> +
> +static int print_bool(DeviceState *dev, Property *prop,
> +  char *dest, size_t len)
> +{
> +bool *ptr = qdev_get_prop_ptr(dev, prop);
> +return snprintf(dest, len, *ptr ? "yes" : "no");
> +}
> +
> +static int print_bool_switch(DeviceState *dev, Property *prop,
> + char *dest, size_t len)
> +{
> +bool *ptr = qdev_get_prop_ptr(dev, prop);
> +return snprintf(dest, len, *ptr ? "on" : "off");
> +}
> +
> +static void get_bool(DeviceState *dev, Visitor *v, void *opaque,
> + const char *name, Error **errp)
> +{
> +Property *prop = opaque;
> +bool *ptr = qdev_get_prop_ptr(dev, prop);
> +
> +visit_type_bool(v, ptr, name, errp);
> +}
> +
> +static void set_bool(DeviceState *dev, Visitor *v, void *opaque,
> + const char *name, Error **errp)
> +{
> +Property *prop = opaque;
> +bool *ptr = qdev_get_prop_ptr(dev, prop);
> +Error *local_err = NULL;
> +bool value;
> +
> +if (dev->state != DEV_STATE_CREATED) {
> +error_set(errp, QERR_PERMISSION_DENIED);
> +return;
> +}
> +
> +visit_type_bool(v, &value, name, &local_err);
> +if (local_err) {
> +error_propagate(errp, local_err);
> +return;
> +}
> +*ptr = value;
> +}
> +
> +PropertyInfo qdev_prop_bool = {
> +.name = "boolean",
> +.type = PROP_TYPE_BOOL,
> +.size = sizeof(bool),
> +.parse = parse_bool,
> +.print = print_bool,
> +.get   = get_bool,
> +.set   = set_bool,
> +};
> +
> +PropertyInfo qdev_prop_bool_switch = {
> +.name = "switch",
> +.type = PROP_TYPE_BOOL,
> +.size = sizeof(bool),
> +.parse = parse_bool_switch,
> +.print = print_bool_switch,
> +.get   = get_bool,
> +.set   = set_bool,
> +};
> +
>  /* --- 8bit integer --- */
>  
>  static int parse_uint8(DeviceState *dev, Property *prop, const char *str)
> @@ -1055,6 +1150,11 @@ void qdev_prop_set_bit(DeviceState *dev, const char 
> *name, b

Re: [Qemu-devel] [PATCH] qmp: add BLOCK_MEDIUM_EJECT event

[Paolo Bonzini]

On 01/27/2012 10:52 AM, Kevin Wolf wrote:

>  Conclusion: eject returned an error, but a few seconds later the tray opened 
and
>   the media wasn't purged. What happened here is that, the_guest_
>   opened the tray. The code in this patch would trigger the 
event, but
>   we shouldn't emit it twice if we cover eject&  change (ie. 
special case)

bdrv_dev_change_media_cb is not called because media cannot be ejected
with a locked drive. Instead bdrv_dev_eject_request is called which
doesn't emit an event.

If the guest happens to initiate an eject itself after receiving the
eject request, it calls bdrv_eject, where we can emit an event.

If we had force=true in the initial eject command, bdrv_close is called,
which in turn goes through bdrv_dev_change_media_cb where an event is
emitted.


But we still emit the eject request, and the guest will cause bdrv_eject 
to raise the event again.


There can always be a race with the guest setting the locked bit, so 
management has to do a query-block anyway after eject or change.  That's 
why the event is not necessary when the eject is host-initiated.


Paolo

Re: [Qemu-devel] [PATCH] qmp: add BLOCK_MEDIUM_EJECT event

[Paolo Bonzini]

On 01/24/2012 07:16 PM, Luiz Capitulino wrote:

@@ -237,6 +238,17 @@ static bool do_check_io_limits(BlockIOLimit *io_limits)
 return true;
 }

+static void on_medium_eject(BlockDriverState *bs, int is_ejected)
+{
+QObject *data;
+
+data = qobject_from_jsonf("{ 'device': %s, 'ejected': %i }",
+  bdrv_get_device_name(bs), is_ejected);
+monitor_protocol_event(QEVENT_BLOCK_MEDIUM_EJECT, data);
+
+qobject_decref(data);
+}
+
 DriveInfo *drive_init(QemuOpts *opts, int default_to_scsi)
 {
 const char *buf;
@@ -503,6 +515,7 @@ DriveInfo *drive_init(QemuOpts *opts, int default_to_scsi)
 QTAILQ_INSERT_TAIL(&drives, dinfo, next);

 bdrv_set_on_error(dinfo->bdrv, on_read_error, on_write_error);
+bdrv_dev_set_medium_eject_notify(dinfo->bdrv, on_medium_eject);

 /* disk I/O throttling */
 bdrv_set_io_limits(dinfo->bdrv, &io_limits);


block.c/blockdev.c separation is nice, but do we really need a function 
pointer?  Also, we're already emitting the BLOCK_IO_ERROR event in 
block.c; is that another place to cleanup, or is this overkill and we 
can just put bdrv_dev_medium_eject_notify in block.c?



diff --git a/hw/ide/atapi.c b/hw/ide/atapi.c
index 0adb27b..4b4bc61 100644
--- a/hw/ide/atapi.c
+++ b/hw/ide/atapi.c
@@ -885,6 +885,7 @@ static void cmd_start_stop_unit(IDEState*s, uint8_t*  buf)
  }
  bdrv_eject(s->bs, !start);
  s->tray_open = !start;
+bdrv_dev_medium_eject_notify(s->bs, !start);
  }

  ide_atapi_cmd_ok(s);
diff --git a/hw/scsi-disk.c b/hw/scsi-disk.c
index 5d8bf53..35e55f4 100644
--- a/hw/scsi-disk.c
+++ b/hw/scsi-disk.c
@@ -1061,6 +1061,7 @@ static int scsi_disk_emulate_start_stop(SCSIDiskReq *r)
  }
  bdrv_eject(s->qdev.conf.bs, !start);
  s->tray_open = !start;
+bdrv_dev_medium_eject_notify(s->qdev.conf.bs, !start);
  }
  return 0;
  }


Can you do the call directly in bdrv_eject (but I would skip 
bdrv_close)?  The only other place where bdrv_eject is called is from 
block/raw.c's raw_eject, but I think you should only emit the event if 
bs->device_name[0] (otherwise the event is quite useless) and bs->file 
will fail the test.


Paolo

Re: [Qemu-devel] [PATCH v8] qdev: Add support for property type bool

[Juan Quintela]

Andreas Färber  wrote:
> From: Andreas Färber 
>
> VMState supports the type bool but qdev instead supports bit, backed by
> uint32_t. Therefore let's add PROP_TYPE_BOOL and qdev_prop_set_bool().
>  PropertyInfo qdev_prop_bit = {
> -.name  = "boolean",
> +.name  = "bit",

my plan for vmstate was to name this "bool32", as it feels more
descriptive (on QDEV, we can change it, but for qemu for compatibility
reasons, it needs to stay as 4 bytes on the wire, but we can have a bool
on the struct).

This are all the uses of DEFINE_PROP_BIT.

./hw/scsi-disk.c:1736:DEFINE_PROP_BIT("removable", SCSIDiskState, 
removable, 0, false),

Con be movde to bool

./hw/scsi-disk.c:1780:DEFINE_PROP_BIT("removable", SCSIDiskState, 
removable, 0, false),

same

./hw/usb-msd.c:658:DEFINE_PROP_BIT("removable", MSDState, removable, 0, 
false),

s->scsi_dev = scsi_bus_legacy_add_drive(&s->bus, bs, 0, !!s->removable,
s->conf.bootindex);
*should* be moved to bool

./hw/hpet.c:707:DEFINE_PROP_BIT("msi", HPETState, flags, 
HPET_MSI_SUPPORT, false),

it is a bitmap with only one bit defined, not sure about this one.


./hw/virtio.h:213:  DEFINE_PROP_BIT("indirect_desc", _state, _field, \
./hw/virtio.h:215:  DEFINE_PROP_BIT("event_idx", _state, _field, \

This is a real bitmap with 2 values.

./hw/virtio-pci.c:800:DEFINE_PROP_BIT("ioeventfd", VirtIOPCIProxy, 
flags,
./hw/virtio-pci.c:819:DEFINE_PROP_BIT("ioeventfd", VirtIOPCIProxy, 
flags,
./hw/virtio-pci.c:843:DEFINE_PROP_BIT("ioeventfd", VirtIOPCIProxy, 
flags,
./hw/9pfs/virtio-9p-device.c:175:DEFINE_PROP_BIT("ioeventfd", 
VirtIOPCIProxy, flags,

Another bitmap with only one defined value.

./hw/virtio-blk.h:103:DEFINE_PROP_BIT("scsi", _state, _field, 
VIRTIO_BLK_F_SCSI, true)

It is a bitmap

./hw/ivshmem.c:782:DEFINE_PROP_BIT("ioeventfd", IVShmemState, features, 
IVSHMEM_IOEVENTFD, false),
./hw/ivshmem.c:783:DEFINE_PROP_BIT("msi", IVShmemState,
features, IVSHMEM_MSI, true),

Another bitmap with two values.

./hw/virtio-net.h:172:DEFINE_PROP_BIT("csum", _state, _field, 
VIRTIO_NET_F_CSUM, true), \
./hw/virtio-net.h:173:DEFINE_PROP_BIT("guest_csum", _state, _field, 
VIRTIO_NET_F_GUEST_CSUM, true), \
./hw/virtio-net.h:174:DEFINE_PROP_BIT("gso", _state, _field, 
VIRTIO_NET_F_GSO, true), \
./hw/virtio-net.h:175:DEFINE_PROP_BIT("guest_tso4", _state, _field, 
VIRTIO_NET_F_GUEST_TSO4, true), \
./hw/virtio-net.h:176:DEFINE_PROP_BIT("guest_tso6", _state, _field, 
VIRTIO_NET_F_GUEST_TSO6, true), \
./hw/virtio-net.h:177:DEFINE_PROP_BIT("guest_ecn", _state, _field, 
VIRTIO_NET_F_GUEST_ECN, true), \
./hw/virtio-net.h:178:DEFINE_PROP_BIT("guest_ufo", _state, _field, 
VIRTIO_NET_F_GUEST_UFO, true), \
./hw/virtio-net.h:179:DEFINE_PROP_BIT("host_tso4", _state, _field, 
VIRTIO_NET_F_HOST_TSO4, true), \
./hw/virtio-net.h:180:DEFINE_PROP_BIT("host_tso6", _state, _field, 
VIRTIO_NET_F_HOST_TSO6, true), \
./hw/virtio-net.h:181:DEFINE_PROP_BIT("host_ecn", _state, _field, 
VIRTIO_NET_F_HOST_ECN, true), \
./hw/virtio-net.h:182:DEFINE_PROP_BIT("host_ufo", _state, _field, 
VIRTIO_NET_F_HOST_UFO, true), \
./hw/virtio-net.h:183:DEFINE_PROP_BIT("mrg_rxbuf", _state, _field, 
VIRTIO_NET_F_MRG_RXBUF, true), \
./hw/virtio-net.h:184:DEFINE_PROP_BIT("status", _state, _field, 
VIRTIO_NET_F_STATUS, true), \
./hw/virtio-net.h:185:DEFINE_PROP_BIT("ctrl_vq", _state, _field, 
VIRTIO_NET_F_CTRL_VQ, true), \
./hw/virtio-net.h:186:DEFINE_PROP_BIT("ctrl_rx", _state, _field, 
VIRTIO_NET_F_CTRL_RX, true), \
./hw/virtio-net.h:187:DEFINE_PROP_BIT("ctrl_vlan", _state, _field, 
VIRTIO_NET_F_CTRL_VLAN, true), \
./hw/virtio-net.h:188:DEFINE_PROP_BIT("ctrl_rx_extra", _state, _field, 
VIRTIO_NET_F_CTRL_RX_EXTRA, true)

Bitmap.

./hw/i8259.c:570:DEFINE_PROP_BIT("master", PicState, master,  0, false),

BOOL

./hw/pci.c:58:DEFINE_PROP_BIT("multifunction", PCIDevice, cap_present,
./hw/pci.c:60:DEFINE_PROP_BIT("command_serr_enable", PCIDevice, 
cap_present,

bitmap with two values.

./hw/pxa2xx_timer.c:488:DEFINE_PROP_BIT("tm4", PXA2xxTimerInfo, flags,
./hw/pxa2xx_timer.c:502:DEFINE_PROP_BIT("tm4", PXA2xxTimerInfo, flags,

Bitmap with only one value.


> +{
> +bool *ptr = qdev_get_prop_ptr(dev, prop);
> +if (strcmp(str, "true") == 0 || strcmp(str, "yes") == 0) {
> +*ptr = true;
> +} else if (strcmp(str, "false") == 0 || strcmp(str, "no") == 0) {
> +*ptr = false;
> +} else {
> +return -EINVAL;
> +}
> +
> +return 0;
> +}
> +
> +static int parse_bool_switch(DeviceState *dev, Property *prop,
> + const char *str)
> +{
> +bool *ptr = qdev_get_prop_ptr(dev, prop);
> +if (strcmp(str, "on") == 0) {
> +*ptr = true;
> +}

Re: [Qemu-devel] [PATCH v8] qdev: Add support for property type bool

[Jan Kiszka]

On 2012-01-27 13:17, Juan Quintela wrote:
>> +{
>> +bool *ptr = qdev_get_prop_ptr(dev, prop);
>> +if (strcmp(str, "true") == 0 || strcmp(str, "yes") == 0) {
>> +*ptr = true;
>> +} else if (strcmp(str, "false") == 0 || strcmp(str, "no") == 0) {
>> +*ptr = false;
>> +} else {
>> +return -EINVAL;
>> +}
>> +
>> +return 0;
>> +}
>> +
>> +static int parse_bool_switch(DeviceState *dev, Property *prop,
>> + const char *str)
>> +{
>> +bool *ptr = qdev_get_prop_ptr(dev, prop);
>> +if (strcmp(str, "on") == 0) {
>> +*ptr = true;
>> +} else if (strcmp(str, "off") == 0) {
>> +*ptr = false;
>> +} else {
>> +return -EINVAL;
>> +}
>> +
>> +return 0;
>> +}
> 
> As I am joining late to this discussion, I am not going to point it very
> strong.  But I think that it is an easy to have a single bool type that
> accept yes/on/true and no/off/false.  Didn't really see a strong
> advantage with the split.

Accepting all this on input is a non-issue, but true/false as output is
suboptimal for quite a few existing and future switches.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

[Qemu-devel] [PATCH v2 0/5] prevent Qemu from waking up needlessly

[Stefano Stabellini]

Hi all,
this small patch series prevents Qemu from waking up needlessly on Xen
several times a second in order to check some timers.


The first patch stops Qemu from emulating the PIT on Xen, the second
patch disables the rtc_clock entirely.

The third patch makes use of a new mechanism to receive buffered io
event notifications from Xen, so that Qemu doesn't need to check the
buffered io page for data 10 times a sec for the entire life of the VM.

The fourth patch changes qemu_next_alarm_deadline only to check the
expire time of a clock if it is enabled.

Finally the last patch increases the default select timeout to 1h:
nothing should rely on the select timeout to be 1sec, so we might as
well increase it to 1h.



Shortlog and diffstat follow:

Stefano Stabellini (5):
  xen: do not initialize the interval timer emulator
  xen: disable rtc_clock
  xen: introduce an event channel for buffered io event notifications
  qemu_next_alarm_deadline: check the expire time of a clock only if it is 
enabled
  qemu_calculate_timeout: increase minimum timeout to 1h

 hw/pc.c  |7 +--
 qemu-timer.c |   12 +---
 xen-all.c|   43 +--
 3 files changed, 47 insertions(+), 15 deletions(-)


A git tree available here:

git://xenbits.xen.org/people/sstabellini/qemu-dm.git timers-2

Cheers,

Stefano

[Qemu-devel] [PATCH v2 1/5] xen: do not initialize the interval timer emulator

[Stefano Stabellini]

PIT is emulated by the hypervisor so we don't need to emulate it in Qemu:
this patch prevents Qemu from waking up needlessly at PIT_FREQ on Xen.

Signed-off-by: Stefano Stabellini 
---
 hw/pc.c |7 +--
 1 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/hw/pc.c b/hw/pc.c
index 85304cf..7a7ce98 100644
--- a/hw/pc.c
+++ b/hw/pc.c
@@ -43,6 +43,7 @@
 #include "ui/qemu-spice.h"
 #include "memory.h"
 #include "exec-memory.h"
+#include "arch_init.h"
 
 /* output Bochs bios info messages */
 //#define DEBUG_BIOS
@@ -1130,7 +1131,7 @@ void pc_basic_device_init(ISABus *isa_bus, qemu_irq *gsi,
 DriveInfo *fd[MAX_FD];
 qemu_irq rtc_irq = NULL;
 qemu_irq *a20_line;
-ISADevice *i8042, *port92, *vmmouse, *pit;
+ISADevice *i8042, *port92, *vmmouse, *pit = NULL;
 qemu_irq *cpu_exit_irq;
 
 register_ioport_write(0x80, 1, 1, ioport80_write, NULL);
@@ -1151,7 +1152,9 @@ void pc_basic_device_init(ISABus *isa_bus, qemu_irq *gsi,
 
 qemu_register_boot_set(pc_boot_set, *rtc_state);
 
-pit = pit_init(isa_bus, 0x40, 0);
+if (!xen_available()) {
+pit = pit_init(isa_bus, 0x40, 0);
+}
 pcspk_init(pit);
 
 for(i = 0; i < MAX_SERIAL_PORTS; i++) {
-- 
1.7.2.5

[Qemu-devel] [PATCH v2 2/5] xen: disable rtc_clock

[Stefano Stabellini]

rtc_clock is only used by the RTC emulator (mc146818rtc.c), however Xen
has its own RTC emulator in the hypervisor so we can disable it.

Signed-off-by: Stefano Stabellini 
---
 xen-all.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/xen-all.c b/xen-all.c
index d1fc597..bf183f7 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -513,6 +513,7 @@ void xen_vcpu_init(void)
 qemu_register_reset(xen_reset_vcpu, first_cpu);
 xen_reset_vcpu(first_cpu);
 }
+qemu_clock_enable(rtc_clock, false);
 }
 
 /* get the ioreq packets from share mem */
-- 
1.7.2.5

[Qemu-devel] [PATCH v2 5/5] qemu_calculate_timeout: increase minimum timeout to 1h

[Stefano Stabellini]

There is no reason why the minimum timeout should be 1sec, it could
easily be 1h and we would save lots of cpu cycles.

Signed-off-by: Stefano Stabellini 
---
 qemu-timer.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/qemu-timer.c b/qemu-timer.c
index 648db1d..b792a32 100644
--- a/qemu-timer.c
+++ b/qemu-timer.c
@@ -844,6 +844,6 @@ fail:
 
 int qemu_calculate_timeout(void)
 {
-return 1000;
+return 1000*60*60;
 }
 
-- 
1.7.2.5

[Qemu-devel] [PATCH v2 3/5] xen: introduce an event channel for buffered io event notifications

[Stefano Stabellini]

Use the newly introduced HVM_PARAM_BUFIOREQ_EVTCHN to receive
notifications for buffered io events.
After the first notification is received leave the event channel masked
and setup a timer to process the rest of the batch.
Once we have completed processing the batch, unmask the event channel
and delete the timer.

Signed-off-by: Stefano Stabellini 
---
 xen-all.c |   42 --
 1 files changed, 36 insertions(+), 6 deletions(-)

diff --git a/xen-all.c b/xen-all.c
index bf183f7..bfec4c1 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -77,6 +77,8 @@ typedef struct XenIOState {
 QEMUTimer *buffered_io_timer;
 /* the evtchn port for polling the notification, */
 evtchn_port_t *ioreq_local_port;
+/* evtchn local port for buffered io */
+evtchn_port_t bufioreq_local_port;
 /* the evtchn fd for polling */
 XenEvtchn xce_handle;
 /* which vcpu we are serving */
@@ -545,6 +547,12 @@ static ioreq_t *cpu_get_ioreq(XenIOState *state)
 evtchn_port_t port;
 
 port = xc_evtchn_pending(state->xce_handle);
+if (port == state->bufioreq_local_port) {
+qemu_mod_timer(state->buffered_io_timer,
+BUFFER_IO_MAX_DELAY + qemu_get_clock_ms(rt_clock));
+return NULL;
+}
+
 if (port != -1) {
 for (i = 0; i < smp_cpus; i++) {
 if (state->ioreq_local_port[i] == port) {
@@ -693,16 +701,18 @@ static void handle_ioreq(ioreq_t *req)
 }
 }
 
-static void handle_buffered_iopage(XenIOState *state)
+static int handle_buffered_iopage(XenIOState *state)
 {
 buf_ioreq_t *buf_req = NULL;
 ioreq_t req;
 int qw;
 
 if (!state->buffered_io_page) {
-return;
+return 0;
 }
 
+memset(&req, 0x00, sizeof(req));
+
 while (state->buffered_io_page->read_pointer != 
state->buffered_io_page->write_pointer) {
 buf_req = &state->buffered_io_page->buf_ioreq[
 state->buffered_io_page->read_pointer % IOREQ_BUFFER_SLOT_NUM];
@@ -727,15 +737,21 @@ static void handle_buffered_iopage(XenIOState *state)
 xen_mb();
 state->buffered_io_page->read_pointer += qw ? 2 : 1;
 }
+
+return req.count;
 }
 
 static void handle_buffered_io(void *opaque)
 {
 XenIOState *state = opaque;
 
-handle_buffered_iopage(state);
-qemu_mod_timer(state->buffered_io_timer,
-   BUFFER_IO_MAX_DELAY + qemu_get_clock_ms(rt_clock));
+if (handle_buffered_iopage(state)) {
+qemu_mod_timer(state->buffered_io_timer,
+BUFFER_IO_MAX_DELAY + qemu_get_clock_ms(rt_clock));
+} else {
+qemu_del_timer(state->buffered_io_timer);
+xc_evtchn_unmask(state->xce_handle, state->bufioreq_local_port);
+}
 }
 
 static void cpu_handle_ioreq(void *opaque)
@@ -865,7 +881,6 @@ static void xen_main_loop_prepare(XenIOState *state)
 
 state->buffered_io_timer = qemu_new_timer_ms(rt_clock, handle_buffered_io,
  state);
-qemu_mod_timer(state->buffered_io_timer, qemu_get_clock_ms(rt_clock));
 
 if (evtchn_fd != -1) {
 qemu_set_fd_handler(evtchn_fd, cpu_handle_ioreq, NULL, state);
@@ -917,6 +932,7 @@ int xen_hvm_init(void)
 {
 int i, rc;
 unsigned long ioreq_pfn;
+unsigned long bufioreq_evtchn;
 XenIOState *state;
 
 state = g_malloc0(sizeof (XenIOState));
@@ -966,6 +982,20 @@ int xen_hvm_init(void)
 state->ioreq_local_port[i] = rc;
 }
 
+rc = xc_get_hvm_param(xen_xc, xen_domid, HVM_PARAM_BUFIOREQ_EVTCHN,
+&bufioreq_evtchn);
+if (rc < 0) {
+fprintf(stderr, "failed to get HVM_PARAM_BUFIOREQ_EVTCHN\n");
+return -1;
+}
+rc = xc_evtchn_bind_interdomain(state->xce_handle, xen_domid,
+(uint32_t)bufioreq_evtchn);
+if (rc == -1) {
+fprintf(stderr, "bind interdomain ioctl error %d\n", errno);
+return -1;
+}
+state->bufioreq_local_port = rc;
+
 /* Init RAM management */
 xen_map_cache_init();
 xen_ram_init(ram_size);
-- 
1.7.2.5

[Qemu-devel] [PATCH v2 4/5] qemu_next_alarm_deadline: check the expire time of a clock only if it is enabled

[Stefano Stabellini]

Also delta in qemu_next_alarm_deadline is a 64 bit value so set the
default to INT64_MAX instead of INT32_MAX.

Signed-off-by: Stefano Stabellini 
---
 qemu-timer.c |   10 --
 1 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/qemu-timer.c b/qemu-timer.c
index cd026c6..648db1d 100644
--- a/qemu-timer.c
+++ b/qemu-timer.c
@@ -106,23 +106,21 @@ static inline int alarm_has_dynticks(struct 
qemu_alarm_timer *t)
 
 static int64_t qemu_next_alarm_deadline(void)
 {
-int64_t delta;
+int64_t delta = INT64_MAX;
 int64_t rtdelta;
 
-if (!use_icount && vm_clock->active_timers) {
+if (!use_icount && vm_clock->enabled && vm_clock->active_timers) {
 delta = vm_clock->active_timers->expire_time -
  qemu_get_clock_ns(vm_clock);
-} else {
-delta = INT32_MAX;
 }
-if (host_clock->active_timers) {
+if (host_clock->enabled && host_clock->active_timers) {
 int64_t hdelta = host_clock->active_timers->expire_time -
  qemu_get_clock_ns(host_clock);
 if (hdelta < delta) {
 delta = hdelta;
 }
 }
-if (rt_clock->active_timers) {
+if (rt_clock->enabled && rt_clock->active_timers) {
 rtdelta = (rt_clock->active_timers->expire_time -
  qemu_get_clock_ns(rt_clock));
 if (rtdelta < delta) {
-- 
1.7.2.5

[Qemu-devel] [PATCH v2] optionroms: Silence intermediate file removal

[Jan Kiszka]

The build process of optionroms spits out an "rm ..." line. Moreover, it
removes all .o files that can be handy for debugging purposes.

Disable automatic intermediate removal and only clean up the unneeded
and large .img and .raw files.

Signed-off-by: Jan Kiszka 
---

Changes in v2:
 - comment on .SECONDARY purpose
 - make rm -rf dependent on success of build command

 pc-bios/optionrom/Makefile |7 +--
 1 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/pc-bios/optionrom/Makefile b/pc-bios/optionrom/Makefile
index 51da288..4e7275b 100644
--- a/pc-bios/optionrom/Makefile
+++ b/pc-bios/optionrom/Makefile
@@ -16,14 +16,17 @@ QEMU_CFLAGS = $(CFLAGS)
 
 build-all: multiboot.bin linuxboot.bin
 
+# suppress auto-removal of intermediate files
+.SECONDARY:
+
 %.img: %.o
$(call quiet-command,$(LD) -Ttext 0 -e _start -s -o $@ $<,"  Building 
$(TARGET_DIR)$@")
 
 %.raw: %.img
-   $(call quiet-command,$(OBJCOPY) -O binary -j .text $< $@,"  Building 
$(TARGET_DIR)$@")
+   $(call quiet-command,$(OBJCOPY) -O binary -j .text $< $@ && rm -f $<,"  
Building $(TARGET_DIR)$@")
 
 %.bin: %.raw
-   $(call quiet-command,$(SHELL) $(SRC_PATH)/scripts/signrom.sh $< $@,"  
Signing $(TARGET_DIR)$@")
+   $(call quiet-command,$(SHELL) $(SRC_PATH)/scripts/signrom.sh $< $@ && 
rm -f $<,"  Signing $(TARGET_DIR)$@")
 
 clean:
rm -f *.o *.d *.raw *.img *.bin *~
-- 
1.7.3.4

[Qemu-devel] USB device plugged in => windows XP guest stalls at bootup

[Erik Rull]

 Hi all,

when having a USB device connected to a windows XP guest that is booting
(or rebooting) the guest will never finish booting. It hangs before the
screen gets resized and the well known Windows is starting dialog appears.
If there is no usb device given to the guest, everything is fine, if I plug
it in when booting is finished, I have no problem using it.

With a linux guest, it works perfectly.

How can I provide more information for helping debugging?  I have no idea
how to dig into the Windows XP boot process.

I tried different XP versions - professional and embedded, on both the
same.

Best regards,

Erik

[Qemu-devel] Coroutines and ucontext

[Alex Barcelo]

I have read that one of the reasons for using makecontext is that it
saves the signal state. But there also exist functions like
"sigsetjmp" and "siglongjmp" which can be used to jump around the
coroutines while preserving signal masks.

I have a patch that uses sigsetjmp and siglongjmp instead of
makecontext and getcontext (and all the ucontext stuff), and it
*seems* to work... but I'm not sure if it works "by accident" (not
sure what I'm doing to the stack, not sure what I should be doing to
the stack). I will test more, but first I wanted to ask a little bit
for advice and comments. (Well, I have to admit it: the only benchmark
I have done is "qemu-img create -f qcow2 imgfile.qcow2 5G"... an
extremely poor test, but enough to see if something works at all).

On a related side note, this is not very well-written:
/* The ucontext functions preserve signal masks which incurs a system call
 * overhead.  setjmp()/longjmp() does not preserve signal masks but only
 * works on the current stack.  Since we need a way to create and switch to
 * a new stack, use the ucontext functions for that but setjmp()/longjmp()
 * for everything else.
 */
[coroutine-ucontext.c, static Coroutine *coroutine_new(void)]
Because it is not clear (IMHO) why are the exact reasons for not using
setjmp and longjmp. Is it because the signal masks? Or is it (also?)
because the "only works on the current stack"? But which system call
are we talking about? Related to stack or related to signals? The
"but" is very ill-placed. And my knowledge is far below the needed for
correcting (or maybe simply understanding) this... sorry.

Re: [Qemu-devel] [PATCH v6] qdev: Add support for property type bool

[Anthony Liguori]

On 01/27/2012 03:38 AM, Andreas Färber wrote:

Am 27.01.2012 07:23, schrieb Stefan Hajnoczi:

On Tue, Jan 24, 2012 at 06:17:36PM +0100, Andreas Färber wrote:

From: Andreas Färber

VMState supports the type bool but qdev instead supports bit, backed by
uint32_t. Therefore let's add DEFINE_PROP_BOOL() and qdev_prop_set_bool().

bool by definition is either true or false. Should the need arise to
parse yes/no, on/off, 1/0 or whatever as well, we can still add that at
a later point in time.

Signed-off-by: Andreas Färber
Cc: Juan Quintela
Cc: Markus Armbruster
Cc: Jan Kiszka
Cc: Vasilis Liaskovitis
---
  v5 ->  v6:


Please merge through a qemu.git committer.  v6 and discussion means this
isn't trivial.


Unfortunately that hasn't happened for half a year though. Generally no
qemu.git committer seems to care about cherry-picking useful
infrastructures from bigger series even once discussions are resolved.


So... why are we introducing a type that's not being used anywhere?

Are you planning to use this type somewhere or is this purely speculative?

Regards,

Anthony Liguori



And for the record, it's net v3 as shown in the part you snipped.

Vasilis, unless Jan or someone has further nitpicks, just prepend my v8
to your series and reuse its DEFINE_PROP_BOOL().

Andreas

Re: [Qemu-devel] cry for help: wiki.qemu.org spam

[Anthony Liguori]

On 01/27/2012 03:14 AM, Michael Tokarev wrote:

The amount of spam our wiki.qemu.org collects, is
increasing every day.  It was easy several months
ago to manually delete these pages once a week to
keep wiki spam-free, now they sometimes manage to
re-create a page while I delete it!

No, it is not counted in 1000s per day - not yet
anyway.  But 10..20 new users with the same amount
of new spam pages per day become a norm.

To see how it looks like, see the RecentChanges:

  http://wiki.qemu.org/Special:RecentChanges

There, each new user adds one spam page.  And see
this link

  http://wiki.qemu.org/index.php?title=Special:RecentChanges&hidebots=0

to see my actions too.

What complicates things alot for me is the fact
that now, after wiki changes, *every* "Delete page"
operation takes 30..60 seconds to complete, and
during all this time the wiki is not doing anything.
This should be fixed too, I think.

Now, I think the best course is to restrict new
user creation, require moderation for new users.
The best will be to ask them to write some words
in the confirmation email as of why they want the
account, -- so that the moderator will be able to
tell somewhat if this is for real or not; but I've
no idea if such a feature exists in mediawiki.

I can play moderational role, -- this at least should
be significantly easier than my current delete page
approach.

And if not, I'd love to see Nuke extension enabled --
http://www.mediawiki.org/wiki/Extension:Nuke -- which
should help with page deletion.


Nuke's now available.  Let me look into how moderation would work..

And thanks for helping keep the wiki spam free!

Regards,

Anthony Liguori



Any other suggestions are ofcourse welcome.

Thanks,

/mjt

Re: [Qemu-devel] [PATCH 01/15] pc: merge pc_piix.c into pc.c

[Anthony Liguori]

On 01/27/2012 02:50 AM, Jan Kiszka wrote:

On 2012-01-26 20:00, Anthony Liguori wrote:

A long time ago, there was a grand plan to merge q35 chipset support.  The start
of that series was a refactoring of pc.c which split a bunch of the "common"
functionality into a separate file that could be shared by the two.

But q35 never got merged and the refactoring, in retrospect, just made things
worse.  Making things proper objects and using composition is the right way
to share common devices.

By pulling these files back together, we can start to fix some of this mess.


There are surely things to clean up and improve, but a clear NACK for
the general direction.


Hi Jan,

I think you're missing the bigger picture here.  Once this refactoring finishes, 
here's what we'll be left with:


1) pc_init creates an I440FX, any bus devices (ISA serial port, PCI vga and 
nics, etc.), sets properties appropriately, and realizes the devices.


2) I440FX is-a PCIHost, has-a I440FX-PMC, has-a PIIX3

3) PIIX3 has-a RTC, has-a I8042, has-a DMAController, etc.

Memory creation is done by the I440FX-PMC.

Now it's true that a newer chipset is going to be similar.  It will likely have 
a SuperI/O chip that looks similar to PIIX3.  The right way to share code would 
be to move most of the PIIX3 functionality to a base class (PCSuperIO) that 
PIIX3 inherits from.


This is probably how to support ISAPC properly too.  Once I sort out interrupts, 
I'll attempt to tackle that.  My guess is that a SuperIO chip could be an 
ISADevice and that we could simply make the PIIX3 has-a SuperIO.  Then the ISAPC 
would have a trivial ISA chipset that has-a SuperIO.


This is fairly trivial to do once we have the right structure to the code.

But the current code has the wrong structure which is why there's so much 
pointer chasing and passing.




It's undoubted that we need a more modern chipset than this ancient
PIIX3, rather sooner than later. And it is clear that there is a good
amount of generic functions in pc.c for building a PC, even a fairly
modern one. So we need a common lib for PC chipsets and would only
revert what you start here.


Sorry, but I don't view this as a useful requirement.  Today we support two 
types of PCs: an i440fx based system and an ISA-only system.  We should 
concentrate on modeling those two systems in the most natural way sharing as 
much code as possible.


When we add a third system, we'll figure out the best way to create additional 
abstractions.  But inhibiting the proper modeling of what we support today in 
order to support some future thing is a bit backwards to me.


Regards,

Anthony Liguori


Please name what you do not like, and then we can fix that concretely.

Jan

Re: [Qemu-devel] [PATCH] keep the PID file locked for the lifetime of the process

[Markus Armbruster]

Laszlo Ersek  writes:

> The lockf() call in qemu_create_pidfile() aims at ensuring mutual
> exclusion. We shouldn't close the pidfile on success, because that drops
> the lock as well [1]:
>
> "File locks shall be released on first close by the locking process
> of any file descriptor for the file."
>
> Coverity may complain again about the leaked file descriptor; let's
> worry about that later.
>
> [1] http://pubs.opengroup.org/onlinepubs/9699919799/functions/lockf.html

Broken in commit 1bbd1592 by yours truly %-}  Suitable pointer could be
added to the commit message.

> Signed-off-by: Laszlo Ersek 
> ---
> Please keep me CC'd, I'm not subscribed. Thanks!
>
>  os-posix.c |1 -
>  1 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/os-posix.c b/os-posix.c
> index 5c437ca..f4940c8 100644
> --- a/os-posix.c
> +++ b/os-posix.c
> @@ -348,6 +348,5 @@ int qemu_create_pidfile(const char *filename)
>  return -1;
>  }
>  
> -close(fd);
>  return 0;
>  }

We intentionally leak fd here.  A comment would be nice.

Reviewed-by: Markus Armbruster 

Re: [Qemu-devel] [PATCH v6] qdev: Add support for property type bool

[Andreas Färber]

Am 27.01.2012 13:41, schrieb Anthony Liguori:
> On 01/27/2012 03:38 AM, Andreas Färber wrote:
>> Am 27.01.2012 07:23, schrieb Stefan Hajnoczi:
>>> On Tue, Jan 24, 2012 at 06:17:36PM +0100, Andreas Färber wrote:
 From: Andreas Färber

 VMState supports the type bool but qdev instead supports bit, backed by
 uint32_t. Therefore let's add DEFINE_PROP_BOOL() and
 qdev_prop_set_bool().

 bool by definition is either true or false. Should the need arise to
 parse yes/no, on/off, 1/0 or whatever as well, we can still add that at
 a later point in time.

 Signed-off-by: Andreas Färber
 Cc: Juan Quintela
 Cc: Markus Armbruster
 Cc: Jan Kiszka
 Cc: Vasilis Liaskovitis
 ---
   v5 ->  v6:
>>>
>>> Please merge through a qemu.git committer.  v6 and discussion means this
>>> isn't trivial.
>>
>> Unfortunately that hasn't happened for half a year though. Generally no
>> qemu.git committer seems to care about cherry-picking useful
>> infrastructures from bigger series even once discussions are resolved.
> 
> So... why are we introducing a type that's not being used anywhere?
> 
> Are you planning to use this type somewhere or is this purely speculative?

My ISA series and later the 40P series used it (therefore
"cherry-picking" above; additionally it turned out recently that there
had been confusion over who was supposed to pull for PReP - thanks for
recently doing so btw).

Now Jan and I agreed that Vasilis should reuse it for his series in
place of uint32. Therefore I would've appreciated a quick merge (thus
qemu-trivial) so that it can be rebased upon.

Unfortunately I didn't have code for testing all paths handy, my bad.

But nevertheless all these discussions never opposed the core idea, only
the exact way things were printed or parsed. When using
qdev_prop_set_bool() internally, like I did for the pc87312 Super I/O,
none of this matters except for 'info qtree'. So if we could decide on
the DEFINE_PROP_*() macro name, all of the parsing and printing can
still be changed back and forth in a central place including when
someone ventures to translate QEMU to non-English, then everything gets
ugly anyway. :) Correct me if I'm wrong, but as far as I saw, your QOM
series only moved this around and the qdev macros remained.

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] [PATCH v2] optionroms: Silence intermediate file removal

[Andreas Färber]

Am 27.01.2012 13:26, schrieb Jan Kiszka:
> The build process of optionroms spits out an "rm ..." line. Moreover, it
> removes all .o files that can be handy for debugging purposes.
> 
> Disable automatic intermediate removal and only clean up the unneeded
> and large .img and .raw files.
> 
> Signed-off-by: Jan Kiszka 

Reviewed-by: Andreas Färber 

Thanks,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] [PATCH 01/15] pc: merge pc_piix.c into pc.c

[Jan Kiszka]

On 2012-01-27 14:07, Anthony Liguori wrote:
> On 01/27/2012 02:50 AM, Jan Kiszka wrote:
>> On 2012-01-26 20:00, Anthony Liguori wrote:
>>> A long time ago, there was a grand plan to merge q35 chipset support.  The 
>>> start
>>> of that series was a refactoring of pc.c which split a bunch of the "common"
>>> functionality into a separate file that could be shared by the two.
>>>
>>> But q35 never got merged and the refactoring, in retrospect, just made 
>>> things
>>> worse.  Making things proper objects and using composition is the right way
>>> to share common devices.
>>>
>>> By pulling these files back together, we can start to fix some of this mess.
>>
>> There are surely things to clean up and improve, but a clear NACK for
>> the general direction.
> 
> Hi Jan,
> 
> I think you're missing the bigger picture here.  Once this refactoring 
> finishes, 
> here's what we'll be left with:
> 
> 1) pc_init creates an I440FX, any bus devices (ISA serial port, PCI vga and 
> nics, etc.), sets properties appropriately, and realizes the devices.
> 
> 2) I440FX is-a PCIHost, has-a I440FX-PMC, has-a PIIX3
> 
> 3) PIIX3 has-a RTC, has-a I8042, has-a DMAController, etc.
> 
> Memory creation is done by the I440FX-PMC.
> 
> Now it's true that a newer chipset is going to be similar.  It will likely 
> have 
> a SuperI/O chip that looks similar to PIIX3.  The right way to share code 
> would 
> be to move most of the PIIX3 functionality to a base class (PCSuperIO) that 
> PIIX3 inherits from.
> 
> This is probably how to support ISAPC properly too.

The ISAPC is differently composed. The board creates all those
individual chips that are otherwise part of the SuperIO block of the
chipset. And IRQ wiring is different. So, no, I don't think it is the
right model. I would rather think of a pc_isa.c that does the proper
composing.

>  Once I sort out interrupts, 
> I'll attempt to tackle that.  My guess is that a SuperIO chip could be an 
> ISADevice and that we could simply make the PIIX3 has-a SuperIO.  Then the 
> ISAPC 
> would have a trivial ISA chipset that has-a SuperIO.
> 
> This is fairly trivial to do once we have the right structure to the code.
> 
> But the current code has the wrong structure which is why there's so much 
> pointer chasing and passing.

Just look at your code and count the generic, PIIX3-independent
functions. Keep them in pc.c, move the rest to pc_piix.c. You could try
to model the ISA accordingly. I think some pc_isa.c would help to
establish a good split-up already now, in the absence of a third chipset.

> 
>>
>> It's undoubted that we need a more modern chipset than this ancient
>> PIIX3, rather sooner than later. And it is clear that there is a good
>> amount of generic functions in pc.c for building a PC, even a fairly
>> modern one. So we need a common lib for PC chipsets and would only
>> revert what you start here.
> 
> Sorry, but I don't view this as a useful requirement.  Today we support two 
> types of PCs: an i440fx based system and an ISA-only system.  We should 
> concentrate on modeling those two systems in the most natural way sharing as 
> much code as possible.

A modern chipset is the only sane way to add things like PCIe,
hotplugging, power management, etc., and to enable standard PC
components like AHCI or EHCI/xHCI by default.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

[Qemu-devel] [PATCH v2] keep the PID file locked for the lifetime of the process

[Laszlo Ersek]

The lockf() call in qemu_create_pidfile() aims at ensuring mutual
exclusion. We shouldn't close the pidfile on success (as introduced by
commit 1bbd1592), because that drops the lock as well [1]:

"File locks shall be released on first close by the locking process
of any file descriptor for the file."

Coverity may complain again about the leaked file descriptor; let's
worry about that later.

v1->v2:
- add reference to 1bbd1592
- explain the intentional fd leak in the source

[1] http://pubs.opengroup.org/onlinepubs/9699919799/functions/lockf.html

Signed-off-by: Laszlo Ersek 
---
 os-posix.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/os-posix.c b/os-posix.c
index 5c437ca..e3ed497 100644
--- a/os-posix.c
+++ b/os-posix.c
@@ -348,6 +348,6 @@ int qemu_create_pidfile(const char *filename)
 return -1;
 }
 
-close(fd);
+/* keep pidfile open & locked forever */
 return 0;
 }
-- 
1.7.1

Re: [Qemu-devel] [PATCH 01/15] pc: merge pc_piix.c into pc.c

[Andreas Färber]

Am 27.01.2012 14:07, schrieb Anthony Liguori:
> [...] My guess is that a SuperIO
> chip could be an ISADevice and that we could simply make the PIIX3 has-a
> SuperIO.  Then the ISAPC would have a trivial ISA chipset that has-a
> SuperIO.

That sounds pretty much like our construction site for PReP...
Would you say that the SuperIO is-a ISADevice and has-a ISADevice or
would you want to remodel all ISADevices associated with a Super I/O
chipset as private devices to mess with their internals without the
whole enable/disable, etc. ugliness we ran into?

I somewhat doubt that we can find a generic "SuperIO" base class btw.

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] [PATCH 01/15] pc: merge pc_piix.c into pc.c

[Anthony Liguori]

On 01/27/2012 08:03 AM, Andreas Färber wrote:

Am 27.01.2012 14:07, schrieb Anthony Liguori:

[...] My guess is that a SuperIO
chip could be an ISADevice and that we could simply make the PIIX3 has-a
SuperIO.  Then the ISAPC would have a trivial ISA chipset that has-a
SuperIO.


That sounds pretty much like our construction site for PReP...


Yup.  It basically boils down to:

Root Complex[1] (PCI Host)
 - Northbridge (Memory Controller)
 - Southbridge (Super I/O chip)

Most platforms will follow this type of composition model with peripheral 
devices hanging off a bus in the Southbridge or directly from the Root Complex.



Would you say that the SuperIO is-a ISADevice


The SuperIO device is-a Root Complex device.  With the I440FX, the Root Complex 
was PCI bus so the SuperIO chip (the PIIX3) is-a PCIDevice.  In older PCIs, the 
Root Complex was ISA (sort of).


[1] A better name for this is System Bus but I'm using Root Complex to avoid 
confusion with sysbus.


But for the PC, we can make the SuperIO chip be is-a DeviceState and just have 
it expose a MemoryRegion and a bunch of IRQs.  That would trivialize the 
implementation of an PIIX3 such that it has-a PCSuperIO and then just routes 
IRQs appropriately.



and has-a ISADevice or
would you want to remodel all ISADevices associated with a Super I/O
chipset as private devices to mess with their internals without the
whole enable/disable, etc. ugliness we ran into?

I somewhat doubt that we can find a generic "SuperIO" base class btw.


Right, it's unlikely that a PC SuperIO chip would be useful outside of a PC. 
But you may find certain classes of platforms all have a common SuperI/O chip 
and can model similar things.


Regards,

Anthony Liguori


Andreas

Re: [Qemu-devel] [PATCH 01/15] pc: merge pc_piix.c into pc.c

[Anthony Liguori]

On 01/27/2012 07:32 AM, Jan Kiszka wrote:

On 2012-01-27 14:07, Anthony Liguori wrote:

On 01/27/2012 02:50 AM, Jan Kiszka wrote:

On 2012-01-26 20:00, Anthony Liguori wrote:

A long time ago, there was a grand plan to merge q35 chipset support.  The start
of that series was a refactoring of pc.c which split a bunch of the "common"
functionality into a separate file that could be shared by the two.

But q35 never got merged and the refactoring, in retrospect, just made things
worse.  Making things proper objects and using composition is the right way
to share common devices.

By pulling these files back together, we can start to fix some of this mess.


There are surely things to clean up and improve, but a clear NACK for
the general direction.


Hi Jan,

I think you're missing the bigger picture here.  Once this refactoring finishes,
here's what we'll be left with:

1) pc_init creates an I440FX, any bus devices (ISA serial port, PCI vga and
nics, etc.), sets properties appropriately, and realizes the devices.

2) I440FX is-a PCIHost, has-a I440FX-PMC, has-a PIIX3

3) PIIX3 has-a RTC, has-a I8042, has-a DMAController, etc.

Memory creation is done by the I440FX-PMC.

Now it's true that a newer chipset is going to be similar.  It will likely have
a SuperI/O chip that looks similar to PIIX3.  The right way to share code would
be to move most of the PIIX3 functionality to a base class (PCSuperIO) that
PIIX3 inherits from.

This is probably how to support ISAPC properly too.


The ISAPC is differently composed. The board creates all those
individual chips that are otherwise part of the SuperIO block of the
chipset. And IRQ wiring is different.


A SuperIO device can still have irq properties for each device that determines 
which ISA bus irq is used.


The other alternative is to stop making devices ISADevice, and then having 
SuperIO expose a bunch of device specific IRQs.  Those IRQs can then be routed 
in whatever way makes sense.


This is really the Right Approach but it's most likely a compatibility breaker 
so I'm trying my best to avoid these types of refactorings right now.



So, no, I don't think it is the
right model. I would rather think of a pc_isa.c that does the proper
composing.


Objects compose other objects.  Functions should not be creating devices.  So if 
you're view of pc_isa.c that there's a pc_basic_init() that takes a bunch of 
devicestate pointers, then that's definitely not the direction I'm heading.


Note that if we ever want to get to a board configuration file, we need to have 
three explicit steps in device creation:


1) device initialization where devices are allocates and the composition tree is 
filled out (which makes sure that every device has an addressable path)


2) device property setting (which requires all devices have an addressable path)

3) device realization where property settings are validated, and then any 
initialization that depends on properties is done.


The problem with the current code is that it doesn't split up these phases. 
Modeling composition really helps to get this split because it forces you to 
think about things in terms of distinct phases.



  Once I sort out interrupts,
I'll attempt to tackle that.  My guess is that a SuperIO chip could be an
ISADevice and that we could simply make the PIIX3 has-a SuperIO.  Then the ISAPC
would have a trivial ISA chipset that has-a SuperIO.

This is fairly trivial to do once we have the right structure to the code.

But the current code has the wrong structure which is why there's so much
pointer chasing and passing.


Just look at your code and count the generic, PIIX3-independent
functions.


I see zero.

"PIIX3-independent" means that some other piece of code would consume it in 
exactly the same way.  pc.c had a bunch of spaghetti in it doing tricks with if 
(pci_enabled) that ended up encoding two very separate paths into one maze of code.



Keep them in pc.c, move the rest to pc_piix.c. You could try
to model the ISA accordingly. I think some pc_isa.c would help to
establish a good split-up already now, in the absence of a third chipset.


I think creating a proper ISA model is a good idea and I'll certainly get there.

Regards,

Anthony Liguori





It's undoubted that we need a more modern chipset than this ancient
PIIX3, rather sooner than later. And it is clear that there is a good
amount of generic functions in pc.c for building a PC, even a fairly
modern one. So we need a common lib for PC chipsets and would only
revert what you start here.


Sorry, but I don't view this as a useful requirement.  Today we support two
types of PCs: an i440fx based system and an ISA-only system.  We should
concentrate on modeling those two systems in the most natural way sharing as
much code as possible.


A modern chipset is the only sane way to add things like PCIe,
hotplugging, power management, etc., and to enable standard PC
components like AHCI or EHCI/xHCI by default.

Jan

Re: [Qemu-devel] [PATCH 01/15] pc: merge pc_piix.c into pc.c

[Jan Kiszka]

On 2012-01-27 15:06, Anthony Liguori wrote:
> On 01/27/2012 07:32 AM, Jan Kiszka wrote:
>> On 2012-01-27 14:07, Anthony Liguori wrote:
>>> On 01/27/2012 02:50 AM, Jan Kiszka wrote:
 On 2012-01-26 20:00, Anthony Liguori wrote:
> A long time ago, there was a grand plan to merge q35 chipset support.  
> The start
> of that series was a refactoring of pc.c which split a bunch of the 
> "common"
> functionality into a separate file that could be shared by the two.
>
> But q35 never got merged and the refactoring, in retrospect, just made 
> things
> worse.  Making things proper objects and using composition is the right 
> way
> to share common devices.
>
> By pulling these files back together, we can start to fix some of this 
> mess.

 There are surely things to clean up and improve, but a clear NACK for
 the general direction.
>>>
>>> Hi Jan,
>>>
>>> I think you're missing the bigger picture here.  Once this refactoring 
>>> finishes,
>>> here's what we'll be left with:
>>>
>>> 1) pc_init creates an I440FX, any bus devices (ISA serial port, PCI vga and
>>> nics, etc.), sets properties appropriately, and realizes the devices.
>>>
>>> 2) I440FX is-a PCIHost, has-a I440FX-PMC, has-a PIIX3
>>>
>>> 3) PIIX3 has-a RTC, has-a I8042, has-a DMAController, etc.
>>>
>>> Memory creation is done by the I440FX-PMC.
>>>
>>> Now it's true that a newer chipset is going to be similar.  It will likely 
>>> have
>>> a SuperI/O chip that looks similar to PIIX3.  The right way to share code 
>>> would
>>> be to move most of the PIIX3 functionality to a base class (PCSuperIO) that
>>> PIIX3 inherits from.
>>>
>>> This is probably how to support ISAPC properly too.
>>
>> The ISAPC is differently composed. The board creates all those
>> individual chips that are otherwise part of the SuperIO block of the
>> chipset. And IRQ wiring is different.
> 
> A SuperIO device can still have irq properties for each device that 
> determines 
> which ISA bus irq is used.
> 
> The other alternative is to stop making devices ISADevice, and then having 
> SuperIO expose a bunch of device specific IRQs.  Those IRQs can then be 
> routed 
> in whatever way makes sense.
> 
> This is really the Right Approach but it's most likely a compatibility 
> breaker 
> so I'm trying my best to avoid these types of refactorings right now.
> 
>> So, no, I don't think it is the
>> right model. I would rather think of a pc_isa.c that does the proper
>> composing.
> 
> Objects compose other objects.  Functions should not be creating devices.  So 
> if 
> you're view of pc_isa.c that there's a pc_basic_init() that takes a bunch of 
> devicestate pointers, then that's definitely not the direction I'm heading.
> 
> Note that if we ever want to get to a board configuration file, we need to 
> have 
> three explicit steps in device creation:
> 
> 1) device initialization where devices are allocates and the composition tree 
> is 
> filled out (which makes sure that every device has an addressable path)
> 
> 2) device property setting (which requires all devices have an addressable 
> path)
> 
> 3) device realization where property settings are validated, and then any 
> initialization that depends on properties is done.
> 
> The problem with the current code is that it doesn't split up these phases. 
> Modeling composition really helps to get this split because it forces you to 
> think about things in terms of distinct phases.
> 
>>>   Once I sort out interrupts,
>>> I'll attempt to tackle that.  My guess is that a SuperIO chip could be an
>>> ISADevice and that we could simply make the PIIX3 has-a SuperIO.  Then the 
>>> ISAPC
>>> would have a trivial ISA chipset that has-a SuperIO.
>>>
>>> This is fairly trivial to do once we have the right structure to the code.
>>>
>>> But the current code has the wrong structure which is why there's so much
>>> pointer chasing and passing.
>>
>> Just look at your code and count the generic, PIIX3-independent
>> functions.
> 
> I see zero.

Then you should look more carefully:

- GSI handler
- ferr
- tsc
- smm
- pic irq handling
- cmos
- boot devices
- port92
- a20

well, this gets boring.

> 
> "PIIX3-independent" means that some other piece of code would consume it in 
> exactly the same way.  pc.c had a bunch of spaghetti in it doing tricks with 
> if 
> (pci_enabled) that ended up encoding two very separate paths into one maze of 
> code.

Right, the still existing pci_enabled mess should be resolved via
separate board instantiations that are based on common building blocks.
That avoids also regression in the ISA PC due to refactorings in the
PIIX3 as happened recently.

> 
>> Keep them in pc.c, move the rest to pc_piix.c. You could try
>> to model the ISA accordingly. I think some pc_isa.c would help to
>> establish a good split-up already now, in the absence of a third chipset.
> 
> I think creating a proper ISA model is a good idea and I'll certainly get 

Re: [Qemu-devel] [PATCH 01/15] pc: merge pc_piix.c into pc.c

[Anthony Liguori]

On 01/27/2012 08:15 AM, Jan Kiszka wrote:

On 2012-01-27 15:06, Anthony Liguori wrote:

On 01/27/2012 07:32 AM, Jan Kiszka wrote:

On 2012-01-27 14:07, Anthony Liguori wrote:

On 01/27/2012 02:50 AM, Jan Kiszka wrote:

On 2012-01-26 20:00, Anthony Liguori wrote:

A long time ago, there was a grand plan to merge q35 chipset support.  The start
of that series was a refactoring of pc.c which split a bunch of the "common"
functionality into a separate file that could be shared by the two.

But q35 never got merged and the refactoring, in retrospect, just made things
worse.  Making things proper objects and using composition is the right way
to share common devices.

By pulling these files back together, we can start to fix some of this mess.


There are surely things to clean up and improve, but a clear NACK for
the general direction.


Hi Jan,

I think you're missing the bigger picture here.  Once this refactoring finishes,
here's what we'll be left with:

1) pc_init creates an I440FX, any bus devices (ISA serial port, PCI vga and
nics, etc.), sets properties appropriately, and realizes the devices.

2) I440FX is-a PCIHost, has-a I440FX-PMC, has-a PIIX3

3) PIIX3 has-a RTC, has-a I8042, has-a DMAController, etc.

Memory creation is done by the I440FX-PMC.

Now it's true that a newer chipset is going to be similar.  It will likely have
a SuperI/O chip that looks similar to PIIX3.  The right way to share code would
be to move most of the PIIX3 functionality to a base class (PCSuperIO) that
PIIX3 inherits from.

This is probably how to support ISAPC properly too.


The ISAPC is differently composed. The board creates all those
individual chips that are otherwise part of the SuperIO block of the
chipset. And IRQ wiring is different.


A SuperIO device can still have irq properties for each device that determines
which ISA bus irq is used.

The other alternative is to stop making devices ISADevice, and then having
SuperIO expose a bunch of device specific IRQs.  Those IRQs can then be routed
in whatever way makes sense.

This is really the Right Approach but it's most likely a compatibility breaker
so I'm trying my best to avoid these types of refactorings right now.


So, no, I don't think it is the
right model. I would rather think of a pc_isa.c that does the proper
composing.


Objects compose other objects.  Functions should not be creating devices.  So if
you're view of pc_isa.c that there's a pc_basic_init() that takes a bunch of
devicestate pointers, then that's definitely not the direction I'm heading.

Note that if we ever want to get to a board configuration file, we need to have
three explicit steps in device creation:

1) device initialization where devices are allocates and the composition tree is
filled out (which makes sure that every device has an addressable path)

2) device property setting (which requires all devices have an addressable path)

3) device realization where property settings are validated, and then any
initialization that depends on properties is done.

The problem with the current code is that it doesn't split up these phases.
Modeling composition really helps to get this split because it forces you to
think about things in terms of distinct phases.


   Once I sort out interrupts,
I'll attempt to tackle that.  My guess is that a SuperIO chip could be an
ISADevice and that we could simply make the PIIX3 has-a SuperIO.  Then the ISAPC
would have a trivial ISA chipset that has-a SuperIO.

This is fairly trivial to do once we have the right structure to the code.

But the current code has the wrong structure which is why there's so much
pointer chasing and passing.


Just look at your code and count the generic, PIIX3-independent
functions.


I see zero.


Then you should look more carefully:

- GSI handler
- ferr
- tsc
- smm
- pic irq handling
- cmos
- boot devices
- port92
- a20

well, this gets boring.


Most of these things fall under the "we're not doing it right today" category 
IMHO.

But I'm still working on this so let's wait to have this discussion...



"PIIX3-independent" means that some other piece of code would consume it in
exactly the same way.  pc.c had a bunch of spaghetti in it doing tricks with if
(pci_enabled) that ended up encoding two very separate paths into one maze of 
code.


Right, the still existing pci_enabled mess should be resolved via
separate board instantiations that are based on common building blocks.
That avoids also regression in the ISA PC due to refactorings in the
PIIX3 as happened recently.


Yes, we're both on the same page here.  I think maybe we just view the paths 
there a bit differently.


Anyway, this was an RFC for a reason.  I was more interested in demonstrating 
what more intensively QOM-ified devices looked like than presenting a coherent 
end-to-end proposal for refactoring PC initialization.  I plan on doing that, 
but I'm not entirely prepared for that yet.


Regards,

Anthony Liguori

Re: [Qemu-devel] [PATCH 0/3] linux-user: Implement missing *xattr calls

[Peter Maydell]

Ping^2 ?

-- PMM

On 4 January 2012 11:39, Peter Maydell  wrote:
> Ping?
>
> -- PMM
>
> On 14 December 2011 15:37, Peter Maydell  wrote:
>> These patches implement the missing *xattr syscalls:
>>  listxattr
>>  fsetattr, fgetattr, fremovexattr, flistxattr
>>  lsetattr, lgetattr, lremovexattr, llistxattr
>>
>> They also fix a bug in the existing code where we weren't allowing a
>> NULL value pointer.
>>
>> Tested with the testcases in crackerjack. (There are some cases where
>> we don't behave exactly like the native kernel:
>>  * we check for bad pointers earlier, so tend to return EFAULT when the
>>   kernel might return EINVAL in a "caller did two wrong things" case
>>  * we insist on the whole of the caller's buffer being writable whereas
>>   the kernel only cares about being able to write the data it actually
>>   needs, so we will fail EFAULT some bad callers that the kernel doesn't
>> I don't think these are important.)
>>
>> Peter Maydell (3):
>>  linux-user: Allow NULL value pointer in setxattr and getxattr
>>  linux-user/syscall.c: Implement f and l versions of
>>    set/get/removexattr
>>  linux-user: Implement *listxattr syscalls
>>
>>  linux-user/syscall.c |  139 
>> --
>>  1 files changed, 123 insertions(+), 16 deletions(-)
>>
>> --
>> 1.7.5.4
>>
>>

Re: [Qemu-devel] Coroutines and ucontext

[Paolo Bonzini]

On 01/27/2012 01:39 PM, Alex Barcelo wrote:

I have read that one of the reasons for using makecontext is that it
saves the signal state. But there also exist functions like
"sigsetjmp" and "siglongjmp" which can be used to jump around the
coroutines while preserving signal masks.

I have a patch that uses sigsetjmp and siglongjmp instead of
makecontext and getcontext (and all the ucontext stuff), and it
*seems* to work... but I'm not sure if it works "by accident" (not
sure what I'm doing to the stack, not sure what I should be doing to
the stack).


You can post it, don't worry.  I'm curious how you are switching stacks 
when creating the coroutine.



I will test more, but first I wanted to ask a little bit
for advice and comments. (Well, I have to admit it: the only benchmark
I have done is "qemu-img create -f qcow2 imgfile.qcow2 5G"... an
extremely poor test, but enough to see if something works at all).


Booting a guest (even a raw image will do) is a decent smoke test.


On a related side note, this is not very well-written:
 /* The ucontext functions preserve signal masks which incurs a system call
  * overhead.  setjmp()/longjmp() does not preserve signal masks but only
  * works on the current stack.  Since we need a way to create and switch to
  * a new stack, use the ucontext functions for that but setjmp()/longjmp()
  * for everything else.
  */
[coroutine-ucontext.c, static Coroutine *coroutine_new(void)]
Because it is not clear (IMHO) why are the exact reasons for not using
setjmp and longjmp. Is it because the signal masks? Or is it (also?)
because the "only works on the current stack"?


It's because you have to create a new stack for the new coroutine. 
makecontext does it for you; you can later use it with setcontext. 
Anything else (getcontext+setcontext, setjmp+longjmp, 
sigsetjmp+siglongjmp) will only work on an existing stack.



But which system call are we talking about?


sigprocmask, which is invoked by sigsetjmp/siglongjmp and also 
getcontext/setcontext.  That's what we want to avoid.


Paolo

Re: [Qemu-devel] [PATCH v2 2/5] xen: disable rtc_clock

[Paolo Bonzini]

On 01/27/2012 01:26 PM, Stefano Stabellini wrote:

rtc_clock is only used by the RTC emulator (mc146818rtc.c), however Xen
has its own RTC emulator in the hypervisor so we can disable it.

Signed-off-by: Stefano Stabellini
---
  xen-all.c |1 +
  1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/xen-all.c b/xen-all.c
index d1fc597..bf183f7 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -513,6 +513,7 @@ void xen_vcpu_init(void)
  qemu_register_reset(xen_reset_vcpu, first_cpu);
  xen_reset_vcpu(first_cpu);
  }
+qemu_clock_enable(rtc_clock, false);
  }

  /* get the ioreq packets from share mem */


Depending on "-rtc clock=vm" or "-rtc clock=rt", this may not be true.

Why do you need to instantiate an RTC at all?

Paolo

Re: [Qemu-devel] [PATCH v2 4/5] qemu_next_alarm_deadline: check the expire time of a clock only if it is enabled

[Paolo Bonzini]

On 01/27/2012 01:26 PM, Stefano Stabellini wrote:

Also delta in qemu_next_alarm_deadline is a 64 bit value so set the
default to INT64_MAX instead of INT32_MAX.

Signed-off-by: Stefano Stabellini
---
  qemu-timer.c |   10 --
  1 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/qemu-timer.c b/qemu-timer.c
index cd026c6..648db1d 100644
--- a/qemu-timer.c
+++ b/qemu-timer.c
@@ -106,23 +106,21 @@ static inline int alarm_has_dynticks(struct 
qemu_alarm_timer *t)

  static int64_t qemu_next_alarm_deadline(void)
  {
-int64_t delta;
+int64_t delta = INT64_MAX;


I'm worried of overflows elsewhere...


  int64_t rtdelta;

-if (!use_icount&&  vm_clock->active_timers) {
+if (!use_icount&&  vm_clock->enabled&&  vm_clock->active_timers) {
  delta = vm_clock->active_timers->expire_time -
   qemu_get_clock_ns(vm_clock);
-} else {
-delta = INT32_MAX;
  }
-if (host_clock->active_timers) {
+if (host_clock->enabled&&  host_clock->active_timers) {
  int64_t hdelta = host_clock->active_timers->expire_time -
   qemu_get_clock_ns(host_clock);
  if (hdelta<  delta) {
  delta = hdelta;
  }
  }
-if (rt_clock->active_timers) {
+if (rt_clock->enabled&&  rt_clock->active_timers) {
  rtdelta = (rt_clock->active_timers->expire_time -
   qemu_get_clock_ns(rt_clock));
  if (rtdelta<  delta) {


The patch is otherwise okay, but without looking more closely at the 
callers I'm not quite ready to give my Reviewed-by.


Paolo

Re: [Qemu-devel] [PATCH v2 5/5] qemu_calculate_timeout: increase minimum timeout to 1h

[Paolo Bonzini]

On 01/27/2012 01:26 PM, Stefano Stabellini wrote:

There is no reason why the minimum timeout should be 1sec, it could
easily be 1h and we would save lots of cpu cycles.

Signed-off-by: Stefano Stabellini
---
  qemu-timer.c |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/qemu-timer.c b/qemu-timer.c
index 648db1d..b792a32 100644
--- a/qemu-timer.c
+++ b/qemu-timer.c
@@ -844,6 +844,6 @@ fail:

  int qemu_calculate_timeout(void)
  {
-return 1000;
+return 1000*60*60;
  }



This might break Windows networking, but I'm going to fix it before 1.1 
anyway.


Reviewed-by: Paolo Bonzini 

Paolo

Re: [Qemu-devel] [PATCH v2] keep the PID file locked for the lifetime of the process

[Markus Armbruster]

Laszlo Ersek  writes:

> The lockf() call in qemu_create_pidfile() aims at ensuring mutual
> exclusion. We shouldn't close the pidfile on success (as introduced by
> commit 1bbd1592), because that drops the lock as well [1]:
>
> "File locks shall be released on first close by the locking process
> of any file descriptor for the file."
>
> Coverity may complain again about the leaked file descriptor; let's
> worry about that later.
>
> v1->v2:
> - add reference to 1bbd1592
> - explain the intentional fd leak in the source
>
> [1] http://pubs.opengroup.org/onlinepubs/9699919799/functions/lockf.html
>
> Signed-off-by: Laszlo Ersek 

Thanks for cleaning up the mess I made!

Reviewed-by: Markus Armbruster 

Re: [Qemu-devel] Coroutines and ucontext

[Daniel P. Berrange]

On Fri, Jan 27, 2012 at 03:39:22PM +0100, Paolo Bonzini wrote:
> On 01/27/2012 01:39 PM, Alex Barcelo wrote:
> >I have read that one of the reasons for using makecontext is that it
> >saves the signal state. But there also exist functions like
> >"sigsetjmp" and "siglongjmp" which can be used to jump around the
> >coroutines while preserving signal masks.
> >
> >I have a patch that uses sigsetjmp and siglongjmp instead of
> >makecontext and getcontext (and all the ucontext stuff), and it
> >*seems* to work... but I'm not sure if it works "by accident" (not
> >sure what I'm doing to the stack, not sure what I should be doing to
> >the stack).
> 
> You can post it, don't worry.  I'm curious how you are switching
> stacks when creating the coroutine.

If you're curious about this kind of thing you might also want to
take a look at the GNU Pth code. In particular its pth_mctx.c
file which has several different implementations of userspace thread
switching, one using makecontext, another with sigstck/altstack
and some others doing something fugly I don't understand :-)

Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

[Qemu-devel] [PATCH v2] main-loop: Fix SetEvent() on uninitialized handle on win32

[Michael Roth]

The __attribute__((constructor)) init_main_loop() automatically get
called if qemu-tool.o is linked in. On win32, this leads to
a qemu_notify_event() call which attempts to SetEvent() on a HANDLE that
won't be initialized until qemu_init_main_loop() is manually called,
breaking qemu-tools.o programs on Windows at runtime.

This patch checks for an initialized event handle before attempting to
set it, which is analoguous to how we deal with an unitialized
io_thread_fd in the posix implementation.

Signed-off-by: Michael Roth 
---
 main-loop.c |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/main-loop.c b/main-loop.c
index 692381c..db90ace 100644
--- a/main-loop.c
+++ b/main-loop.c
@@ -183,6 +183,9 @@ static int qemu_event_init(void)
 
 void qemu_notify_event(void)
 {
+if (!qemu_event_handle) {
+return;
+}
 if (!SetEvent(qemu_event_handle)) {
 fprintf(stderr, "qemu_notify_event: SetEvent failed: %ld\n",
 GetLastError());
-- 
1.7.4.1

Re: [Qemu-devel] [PATCH 04/28] qom: add the base Object class (v2)

[Andreas Färber]

Am 25.01.2012 22:37, schrieb Anthony Liguori:
> On 01/25/2012 03:30 PM, Andreas Färber wrote:
>> Am 24.01.2012 20:32, schrieb Anthony Liguori:
>>> This class provides the main building block for QEMU Object Model and is
>>> extensively documented in the header file.  It is largely inspired by
>>> GObject.
>>>
>>> Signed-off-by: Anthony Liguori
>>> ---
>>> v1 ->  v2
>>>   - remove printf() in type registration
>>>   - fix typo in comment (Paolo)
>>>   - make Interface private
>>>   - move object into a new directory and move header into include/qemu/
>>
>> Some of us had expressed concerns over introducing include/. Any
>> particular reason you're doing it still?
> 
> Because it's a great idea and I thought everyone loved it?
> 
> Can you point me to the concerns raised, I'll go back and look.  I
> didn't think it was contentious...

Can't find it right now (stupid search keyword!) but I remember having a
discussion around whether these are actually "public" APIs because to
date we have always claimed that all APIs are internal and no guarantees
are made. IMO moving headers to an include/ dir marks a change of that
policy because header in include/ usually get installed alongside a
library so if we do it we should do it conciously.

Thing is, headers that are private to one part of code are public to
another. It's not black and white. E.g., hw -> IDE -> AHCI -> ICH9.
Whenever there's multiple subclasses code needs to be shared; it
shouldn't usually be poked at from the outside though in favor of
qdev/QOM properties.

Personally, I find it more handy to find pci_dec.c and pci_dec.h in the
same directory in Nautilus/gedit/whatever (but bad example because I'm
working on making that header go away). On the other hand compared to
like r955 we have seen a huge inflation in hw/ files.
I can live with it either way, and as Paolo says, it can easily be
changed later with git-mv. And #include "qemu/foo.h" sounds fair.

For these new "public" headers I'd be interested in finding a solution
where we can all easily collaborate on the documentation though. Right
now we need to trust you to get the markup right.

Andreas

> To summarize my rationale for it:
> 
>  1) It avoids all of the non-sense with conflicting system headers
> (because we -Iinclude and the headers live in include/qemu)
> 
>  2) It establishes what are public functions for use in other parts of
> qemu vs. private headers (which we currently use based on ad-hoc naming
> schemes like block_int.h).
> 
>  3) I think the kernel serves as an existence proof that this method to
> manage headers works really well in practice.
> 
> Regards,
> 
> Anthony Liguori

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] [PATCH 04/28] qom: add the base Object class (v2)

[Anthony Liguori]

On 01/27/2012 09:05 AM, Andreas Färber wrote:

Am 25.01.2012 22:37, schrieb Anthony Liguori:

On 01/25/2012 03:30 PM, Andreas Färber wrote:

Am 24.01.2012 20:32, schrieb Anthony Liguori:

This class provides the main building block for QEMU Object Model and is
extensively documented in the header file.  It is largely inspired by
GObject.

Signed-off-by: Anthony Liguori
---
v1 ->   v2
   - remove printf() in type registration
   - fix typo in comment (Paolo)
   - make Interface private
   - move object into a new directory and move header into include/qemu/


Some of us had expressed concerns over introducing include/. Any
particular reason you're doing it still?


Because it's a great idea and I thought everyone loved it?

Can you point me to the concerns raised, I'll go back and look.  I
didn't think it was contentious...


Can't find it right now (stupid search keyword!)


No problem.


but I remember having a
discussion around whether these are actually "public" APIs because to
date we have always claimed that all APIs are internal and no guarantees
are made. IMO moving headers to an include/ dir marks a change of that
policy because header in include/ usually get installed alongside a
library so if we do it we should do it conciously.

Thing is, headers that are private to one part of code are public to
another. It's not black and white. E.g., hw ->  IDE ->  AHCI ->  ICH9.
Whenever there's multiple subclasses code needs to be shared; it
shouldn't usually be poked at from the outside though in favor of
qdev/QOM properties.

Personally, I find it more handy to find pci_dec.c and pci_dec.h in the
same directory in Nautilus/gedit/whatever (but bad example because I'm
working on making that header go away). On the other hand compared to
like r955 we have seen a huge inflation in hw/ files.
I can live with it either way, and as Paolo says, it can easily be
changed later with git-mv. And #include "qemu/foo.h" sounds fair.


When I think of include/, I think of "internally public" headers.  IOW, things 
that are meant to be shared in other parts of QEMU.  For instance, something 
like qemu-queue.h.


In fact, there are 25 header files in $SRCDIR that are in the form qemu-$file.h. 
 They could (and should) probably be moved to include/qemu/$file.h


As we introduce more directory structure, having a single include directory will 
be very handy.  For instance, pci_dec.c may move to drivers/ppc/pci_dec.c.  But 
having pci_dec.h in include/qemu means that we don't have to worry about very 
long #include paths.


Regards,

Anthony Liguori



For these new "public" headers I'd be interested in finding a solution
where we can all easily collaborate on the documentation though. Right
now we need to trust you to get the markup right.

Andreas


To summarize my rationale for it:

  1) It avoids all of the non-sense with conflicting system headers
(because we -Iinclude and the headers live in include/qemu)

  2) It establishes what are public functions for use in other parts of
qemu vs. private headers (which we currently use based on ad-hoc naming
schemes like block_int.h).

  3) I think the kernel serves as an existence proof that this method to
manage headers works really well in practice.

Regards,

Anthony Liguori

Re: [Qemu-devel] [PATCH v2 4/5] qemu_next_alarm_deadline: check the expire time of a clock only if it is enabled

[Stefano Stabellini]

On Fri, 27 Jan 2012, Paolo Bonzini wrote:
> On 01/27/2012 01:26 PM, Stefano Stabellini wrote:
> > Also delta in qemu_next_alarm_deadline is a 64 bit value so set the
> > default to INT64_MAX instead of INT32_MAX.
> >
> > Signed-off-by: Stefano Stabellini
> > ---
> >   qemu-timer.c |   10 --
> >   1 files changed, 4 insertions(+), 6 deletions(-)
> >
> > diff --git a/qemu-timer.c b/qemu-timer.c
> > index cd026c6..648db1d 100644
> > --- a/qemu-timer.c
> > +++ b/qemu-timer.c
> > @@ -106,23 +106,21 @@ static inline int alarm_has_dynticks(struct 
> > qemu_alarm_timer *t)
> >
> >   static int64_t qemu_next_alarm_deadline(void)
> >   {
> > -int64_t delta;
> > +int64_t delta = INT64_MAX;
> 
> I'm worried of overflows elsewhere...

I think that you are right: mm_rearm_timer and win32_rearm_timer would
overflow.
I'll just repost the patch using INT32_MAX.

Re: [Qemu-devel] [PATCH v2 5/5] qemu_calculate_timeout: increase minimum timeout to 1h

[Stefano Stabellini]

On Fri, 27 Jan 2012, Paolo Bonzini wrote:
> On 01/27/2012 01:26 PM, Stefano Stabellini wrote:
> > There is no reason why the minimum timeout should be 1sec, it could
> > easily be 1h and we would save lots of cpu cycles.
> >
> > Signed-off-by: Stefano Stabellini
> > ---
> >   qemu-timer.c |2 +-
> >   1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/qemu-timer.c b/qemu-timer.c
> > index 648db1d..b792a32 100644
> > --- a/qemu-timer.c
> > +++ b/qemu-timer.c
> > @@ -844,6 +844,6 @@ fail:
> >
> >   int qemu_calculate_timeout(void)
> >   {
> > -return 1000;
> > +return 1000*60*60;
> >   }
> >
> 
> This might break Windows networking, but I'm going to fix it before 1.1 
> anyway.
> 
> Reviewed-by: Paolo Bonzini 
 
Thanks!

Re: [Qemu-devel] [PATCH 04/28] qom: add the base Object class (v2)

[Andreas Färber]

Am 27.01.2012 16:42, schrieb Anthony Liguori:
> On 01/27/2012 09:05 AM, Andreas Färber wrote:
>> Am 25.01.2012 22:37, schrieb Anthony Liguori:
>>> On 01/25/2012 03:30 PM, Andreas Färber wrote:
 Am 24.01.2012 20:32, schrieb Anthony Liguori:
> This class provides the main building block for QEMU Object Model
> and is
> extensively documented in the header file.  It is largely inspired by
> GObject.
>
> Signed-off-by: Anthony Liguori
> ---
> v1 ->   v2
>- remove printf() in type registration
>- fix typo in comment (Paolo)
>- make Interface private
>- move object into a new directory and move header into
> include/qemu/

 Some of us had expressed concerns over introducing include/. Any
 particular reason you're doing it still?
>>>
>>> Because it's a great idea and I thought everyone loved it?
>>>
>>> Can you point me to the concerns raised, I'll go back and look.  I
>>> didn't think it was contentious...
>>
>> Can't find it right now (stupid search keyword!)
> 
> No problem.
> 
>> but I remember having a
>> discussion around whether these are actually "public" APIs because to
>> date we have always claimed that all APIs are internal and no guarantees
>> are made. IMO moving headers to an include/ dir marks a change of that
>> policy because header in include/ usually get installed alongside a
>> library so if we do it we should do it conciously.
>>
>> Thing is, headers that are private to one part of code are public to
>> another. It's not black and white. E.g., hw ->  IDE ->  AHCI ->  ICH9.
>> Whenever there's multiple subclasses code needs to be shared; it
>> shouldn't usually be poked at from the outside though in favor of
>> qdev/QOM properties.
>>
>> Personally, I find it more handy to find pci_dec.c and pci_dec.h in the
>> same directory in Nautilus/gedit/whatever (but bad example because I'm
>> working on making that header go away). On the other hand compared to
>> like r955 we have seen a huge inflation in hw/ files.
>> I can live with it either way, and as Paolo says, it can easily be
>> changed later with git-mv. And #include "qemu/foo.h" sounds fair.
> 
> When I think of include/, I think of "internally public" headers.  IOW,
> things that are meant to be shared in other parts of QEMU.  For
> instance, something like qemu-queue.h.
> 
> In fact, there are 25 header files in $SRCDIR that are in the form
> qemu-$file.h.  They could (and should) probably be moved to
> include/qemu/$file.h

Okay, agree.

Regards,
Andreas

> 
> As we introduce more directory structure, having a single include
> directory will be very handy.  For instance, pci_dec.c may move to
> drivers/ppc/pci_dec.c.  But having pci_dec.h in include/qemu means that
> we don't have to worry about very long #include paths.
> 
> Regards,
> 
> Anthony Liguori
> 
>>
>> For these new "public" headers I'd be interested in finding a solution
>> where we can all easily collaborate on the documentation though. Right
>> now we need to trust you to get the markup right.
>>
>> Andreas
>>
>>> To summarize my rationale for it:
>>>
>>>   1) It avoids all of the non-sense with conflicting system headers
>>> (because we -Iinclude and the headers live in include/qemu)
>>>
>>>   2) It establishes what are public functions for use in other parts of
>>> qemu vs. private headers (which we currently use based on ad-hoc naming
>>> schemes like block_int.h).
>>>
>>>   3) I think the kernel serves as an existence proof that this method to
>>> manage headers works really well in practice.
>>>
>>> Regards,
>>>
>>> Anthony Liguori
>>
> 


-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] [PATCH v2 4/5] qemu_next_alarm_deadline: check the expire time of a clock only if it is enabled

[Stefano Stabellini]

On Fri, 27 Jan 2012, Stefano Stabellini wrote:
> On Fri, 27 Jan 2012, Paolo Bonzini wrote:
> > On 01/27/2012 01:26 PM, Stefano Stabellini wrote:
> > > Also delta in qemu_next_alarm_deadline is a 64 bit value so set the
> > > default to INT64_MAX instead of INT32_MAX.
> > >
> > > Signed-off-by: Stefano Stabellini
> > > ---
> > >   qemu-timer.c |   10 --
> > >   1 files changed, 4 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/qemu-timer.c b/qemu-timer.c
> > > index cd026c6..648db1d 100644
> > > --- a/qemu-timer.c
> > > +++ b/qemu-timer.c
> > > @@ -106,23 +106,21 @@ static inline int alarm_has_dynticks(struct 
> > > qemu_alarm_timer *t)
> > >
> > >   static int64_t qemu_next_alarm_deadline(void)
> > >   {
> > > -int64_t delta;
> > > +int64_t delta = INT64_MAX;
> > 
> > I'm worried of overflows elsewhere...
> 
> I think that you are right: mm_rearm_timer and win32_rearm_timer would
> overflow.
> I'll just repost the patch using INT32_MAX.
 
Actually it is better to fix mm_rearm_timer and win32_rearm_timer so
that they won't overflow anymore.
I'll add a patch to do that.

Re: [Qemu-devel] cry for help: wiki.qemu.org spam

[Stefan Weil]

Am 27.01.2012 13:47, schrieb Anthony Liguori:

On 01/27/2012 03:14 AM, Michael Tokarev wrote:

The amount of spam our wiki.qemu.org collects, is
increasing every day.  It was easy several months
ago to manually delete these pages once a week to
keep wiki spam-free, now they sometimes manage to
re-create a page while I delete it!

No, it is not counted in 1000s per day - not yet
anyway.  But 10..20 new users with the same amount
of new spam pages per day become a norm.

To see how it looks like, see the RecentChanges:

  http://wiki.qemu.org/Special:RecentChanges

There, each new user adds one spam page.  And see
this link

  http://wiki.qemu.org/index.php?title=Special:RecentChanges&hidebots=0

to see my actions too.

What complicates things alot for me is the fact
that now, after wiki changes, *every* "Delete page"
operation takes 30..60 seconds to complete, and
during all this time the wiki is not doing anything.
This should be fixed too, I think.

Now, I think the best course is to restrict new
user creation, require moderation for new users.
The best will be to ask them to write some words
in the confirmation email as of why they want the
account, -- so that the moderator will be able to
tell somewhat if this is for real or not; but I've
no idea if such a feature exists in mediawiki.

I can play moderational role, -- this at least should
be significantly easier than my current delete page
approach.

And if not, I'd love to see Nuke extension enabled --
http://www.mediawiki.org/wiki/Extension:Nuke -- which
should help with page deletion.


Nuke's now available.  Let me look into how moderation would work..

And thanks for helping keep the wiki spam free!

Regards,

Anthony Liguori



Any other suggestions are ofcourse welcome.

Thanks,

/mjt




Hi Anthony,

I suggest installing these two extensions (I use both on my Wiki):

http://www.mediawiki.org/wiki/Extension:AntiSpoof
http://www.mediawiki.org/wiki/Extension:ConfirmAccount

Cheers,
Stefan W.

Re: [Qemu-devel] cry for help: wiki.qemu.org spam

[Stefan Weil]

Am 27.01.2012 13:47, schrieb Anthony Liguori:

On 01/27/2012 03:14 AM, Michael Tokarev wrote:

The amount of spam our wiki.qemu.org collects, is
increasing every day.  It was easy several months
ago to manually delete these pages once a week to
keep wiki spam-free, now they sometimes manage to
re-create a page while I delete it!

No, it is not counted in 1000s per day - not yet
anyway.  But 10..20 new users with the same amount
of new spam pages per day become a norm.

To see how it looks like, see the RecentChanges:

  http://wiki.qemu.org/Special:RecentChanges

There, each new user adds one spam page.  And see
this link

  http://wiki.qemu.org/index.php?title=Special:RecentChanges&hidebots=0

to see my actions too.

What complicates things alot for me is the fact
that now, after wiki changes, *every* "Delete page"
operation takes 30..60 seconds to complete, and
during all this time the wiki is not doing anything.
This should be fixed too, I think.

Now, I think the best course is to restrict new
user creation, require moderation for new users.
The best will be to ask them to write some words
in the confirmation email as of why they want the
account, -- so that the moderator will be able to
tell somewhat if this is for real or not; but I've
no idea if such a feature exists in mediawiki.

I can play moderational role, -- this at least should
be significantly easier than my current delete page
approach.

And if not, I'd love to see Nuke extension enabled --
http://www.mediawiki.org/wiki/Extension:Nuke -- which
should help with page deletion.


Nuke's now available.  Let me look into how moderation would work..

And thanks for helping keep the wiki spam free!

Regards,

Anthony Liguori



Any other suggestions are ofcourse welcome.

Thanks,

/mjt






http://www.mediawiki.org/wiki/Special:Version shows the extensions
used by Mediawiki. Look for "Spam prevention" - there are lots of
extensions installed there for that purpose.

Cheers,
Stefan Weil

Re: [Qemu-devel] [PATCH] network: Added option to disable NIC option roms

[Gerhard Wiesinger]

On Thu, 26 Jan 2012, Markus Armbruster wrote:


Gerd Hoffmann  writes:


On 01/26/12 08:45, Markus Armbruster wrote:

Gerhard Wiesinger  writes:


Option ROM for network interface cards (NICs) can now explicitly disabled
with romfile=disabled (or romfile=no or romfile=none) parameter.
With hotplugable NICs (currently NE2000, PCNET) romfile=(empty) didn't work.
This patch disables Option ROMs for iPXE for alls supported NICs
(hotplugable and non hotplugable).


And now filenames "disabled", "no" and "none" don't work.

Any way to fix "romfile="?


Sure.


This patch looks much better.  Gerhard does it solve your problem?
Gerd, you might want to repost it in its own thread, as maintainers can
easily miss patches buried deep in replies.


Can confirm this patch works well in all tried combinations.

3 Comments:
1.) NOK?: 2 NICs installed, no bootindex specified: Tries to boot only 
from one NIC, then from C: (one NIC has index first, second one has last 
index)

-boot order=nca,menu=on
-device rtl8139,mac=1a:46:0b:ca:bc:7c,vlan=0 -net 
tap,ifname=tap0,script=no,downscript=no,vlan=0
 -device pcnet,mac=1a:46:0b:ca:bc:7e,vlan=1 -net 
tap,ifname=tap1,script=no,downscript=no,vlan=1
I would expect to try to boot from both NICs
1. iPXE (PCI 00:04:0)
...
8. iPXE (PCI 00:05:0)

2.) OK: 2 NICs installed, bootindex specified: Tries to boot from first 
and second NIC

-boot order=nca,menu=on
-device rtl8139,mac=1a:46:0b:ca:bc:7c,vlan=0,bootindex=1 -net 
tap,ifname=tap0,script=no,downscript=no,vlan=0
-device pcnet,mac=1a:46:0b:ca:bc:7e,vlan=1,bootindex=2 -net 
tap,ifname=tap1,script=no,downscript=no,vlan=1
1. iPXE (PCI 00:04:0)
2. iPXE (PCI 00:05:0)
...

3.) NOK: 2 NICs installed, bootindex specified in reverse order: Tries to 
boot from 7e NIC and reboots ...

-boot order=nca,menu=on
-device rtl8139,mac=1a:46:0b:ca:bc:7c,vlan=0,bootindex=2 -net 
tap,ifname=tap0,script=no,downscript=no,vlan=0
-device pcnet,mac=1a:46:0b:ca:bc:7e,vlan=1,bootindex=1 -net 
tap,ifname=tap1,script=no,downscript=no,vlan=1
1. iPXE (PCI 00:05:0)
2. iPXE (PCI 00:04:0)
...

Ciao,
Gerhard

--
http://www.wiesinger.com/

Re: [Qemu-devel] cry for help: wiki.qemu.org spam

[Daniel P. Berrange]

On Fri, Jan 27, 2012 at 01:14:11PM +0400, Michael Tokarev wrote:
> The amount of spam our wiki.qemu.org collects, is
> increasing every day.  It was easy several months
> ago to manually delete these pages once a week to
> keep wiki spam-free, now they sometimes manage to
> re-create a page while I delete it!
> 
> No, it is not counted in 1000s per day - not yet
> anyway.  But 10..20 new users with the same amount
> of new spam pages per day become a norm.
> 
> To see how it looks like, see the RecentChanges:
> 
>  http://wiki.qemu.org/Special:RecentChanges
> 
> There, each new user adds one spam page.  And see
> this link
> 
>  http://wiki.qemu.org/index.php?title=Special:RecentChanges&hidebots=0
> 
> to see my actions too.
> 
> What complicates things alot for me is the fact
> that now, after wiki changes, *every* "Delete page"
> operation takes 30..60 seconds to complete, and
> during all this time the wiki is not doing anything.
> This should be fixed too, I think.
> 
> Now, I think the best course is to restrict new
> user creation, require moderation for new users.
> The best will be to ask them to write some words
> in the confirmation email as of why they want the
> account, -- so that the moderator will be able to
> tell somewhat if this is for real or not; but I've
> no idea if such a feature exists in mediawiki.
> 
> I can play moderational role, -- this at least should
> be significantly easier than my current delete page
> approach.
> 
> And if not, I'd love to see Nuke extension enabled --
> http://www.mediawiki.org/wiki/Extension:Nuke -- which
> should help with page deletion.
> 
> Any other suggestions are ofcourse welcome.

On the KVM mediawiki (and all the others I maintain) I enabled the Math
question captcha which has pretty much solved the problem of bots now.

NB, you need to tweak it to use custom form field names, since bots can
detect it & auto-fill the questions if you use the default form names.

Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

Re: [Qemu-devel] cry for help: wiki.qemu.org spam

[Stefan Weil]

Am 27.01.2012 13:47, schrieb Anthony Liguori:

On 01/27/2012 03:14 AM, Michael Tokarev wrote:

The amount of spam our wiki.qemu.org collects, is
increasing every day.  It was easy several months
ago to manually delete these pages once a week to
keep wiki spam-free, now they sometimes manage to
re-create a page while I delete it!

No, it is not counted in 1000s per day - not yet
anyway.  But 10..20 new users with the same amount
of new spam pages per day become a norm.

To see how it looks like, see the RecentChanges:

  http://wiki.qemu.org/Special:RecentChanges

There, each new user adds one spam page.  And see
this link

  http://wiki.qemu.org/index.php?title=Special:RecentChanges&hidebots=0

to see my actions too.

What complicates things alot for me is the fact
that now, after wiki changes, *every* "Delete page"
operation takes 30..60 seconds to complete, and
during all this time the wiki is not doing anything.
This should be fixed too, I think.

Now, I think the best course is to restrict new
user creation, require moderation for new users.
The best will be to ask them to write some words
in the confirmation email as of why they want the
account, -- so that the moderator will be able to
tell somewhat if this is for real or not; but I've
no idea if such a feature exists in mediawiki.

I can play moderational role, -- this at least should
be significantly easier than my current delete page
approach.

And if not, I'd love to see Nuke extension enabled --
http://www.mediawiki.org/wiki/Extension:Nuke -- which
should help with page deletion.


Nuke's now available.  Let me look into how moderation would work..

And thanks for helping keep the wiki spam free!

Regards,

Anthony Liguori



Any other suggestions are ofcourse welcome.

Thanks,

/mjt




This is also a useful mediawiki extension:

http://www.mediawiki.org/wiki/Extension:ConfirmEdit

It tries to prevent spam bots from editing wiki pages by
using captcha techniques.

Regards,
Stefan W.

Re: [Qemu-devel] [PATCH] To support scsi Virtual Adapter while creating VMDK images

[Andreas Färber]

Am 27.01.2012 00:46, schrieb praveen_palad...@dell.com:
> According to VMDK specification, while using virtual scsi adapter, the value 
> of adapterType has to be set to "lsilogic" or "buslogic". When the user adds 
> "scsi" to the list of qemu-img options (Example: qemu-img create -f vmdk foo 
> -o scsi,size=100M) this patch will set the value of adapterType to "lsilogic".
> 
> When the "scsi" is not passed, the default "ide" value is used.

> Signed-off-by: Praveen K Paladugu 

SoB should be above the patch so that it gets committed. Please cc the
block maintainer, scripts/get_maintainer.pl can help with that.

We're carrying a pretty similar patch from 2009 in OBS:

https://build.opensuse.org/package/view_file?file=qemu-img-vmdk-scsi.patch&package=virt-utils&project=Virtualization&rev=34c58db02d6bfdb1a9dd49fc3c7fa9d4

There were also patches by Soren Hansen and Kevin Wolf back in 2008, by
Pantelis Koukousoulas in 2009, by Aaron Mason and Alex Graf in 2010; are
these all independent or is someone's SoB missing here?

There were some issues raised about BLOCK_FLAG_SCSI that I don't see
addressed here.

Google found these other versions for reference (there may be more):

http://patchwork.ozlabs.org/patch/60730/
http://patchwork.ozlabs.org/patch/60080/
http://copilotco.com/mail-archives/qemu.2008/msg04541.html
http://lists.gnu.org/archive/html/qemu-devel/2009-07/msg02509.html
http://www.mail-archive.com/qemu-devel@nongnu.org/msg15054.html

Regards,
Andreas

> diff --git a/block.c b/block.c
> index 3f072f6..2a2e725 100644
> --- a/block.c
> +++ b/block.c
> @@ -3690,7 +3690,7 @@ int bdrv_img_create(const char *filename, const char 
> *fmt,
>  char *options, uint64_t img_size, int flags)
>  {
>  QEMUOptionParameter *param = NULL, *create_options = NULL;
> -QEMUOptionParameter *backing_fmt, *backing_file, *size;
> +QEMUOptionParameter *backing_fmt, *backing_file, *size, *scsi;
>  BlockDriverState *bs = NULL;
>  BlockDriver *drv, *proto_drv;
>  BlockDriver *backing_drv = NULL;
> @@ -3797,6 +3797,12 @@ int bdrv_img_create(const char *filename, const char 
> *fmt,
>  goto out;
>  }
>  }
> +scsi = get_option_parameter(param, BLOCK_OPT_SCSI);
> +if (scsi && scsi->value.n && strcmp(drv->format_name, "vmdk")) {
> +error_report("SCSI devices not supported for this file format");
> +ret = -1;
> +goto out;
> +   }
>  
>  printf("Formatting '%s', fmt=%s ", filename, fmt);
>  print_option_parameters(param);
> diff --git a/block/vmdk.c b/block/vmdk.c
> index 5623ac1..fc1ac65 100644
> --- a/block/vmdk.c
> +++ b/block/vmdk.c
> @@ -1377,7 +1377,7 @@ static int vmdk_create(const char *filename, 
> QEMUOptionParameter *options)
>  "ddb.geometry.cylinders = \"%" PRId64 "\"\n"
>  "ddb.geometry.heads = \"16\"\n"
>  "ddb.geometry.sectors = \"63\"\n"
> -"ddb.adapterType = \"ide\"\n";
> +"ddb.adapterType = \"%s\"\n";
>  
>  if (filename_decompose(filename, path, prefix, postfix, PATH_MAX)) {
>  return -EINVAL;
> @@ -1390,6 +1390,8 @@ static int vmdk_create(const char *filename, 
> QEMUOptionParameter *options)
>  backing_file = options->value.s;
>  } else if (!strcmp(options->name, BLOCK_OPT_COMPAT6)) {
>  flags |= options->value.n ? BLOCK_FLAG_COMPAT6 : 0;
> +} else if (!strcmp(options->name, BLOCK_OPT_SCSI)) {
> +flags |= options->value.n ? BLOCK_FLAG_SCSI : 0;
>  } else if (!strcmp(options->name, BLOCK_OPT_SUBFMT)) {
>  fmt = options->value.s;
>  }
> @@ -1482,7 +1484,8 @@ static int vmdk_create(const char *filename, 
> QEMUOptionParameter *options)
>  parent_desc_line,
>  ext_desc_lines,
>  (flags & BLOCK_FLAG_COMPAT6 ? 6 : 4),
> -total_size / (int64_t)(63 * 16 * 512));
> +total_size / (int64_t)(63 * 16 * 512),
> +(flags & BLOCK_FLAG_SCSI ? "lsilogic" : "ide"));
>  if (split || flat) {
>  fd = open(
>  filename,
> @@ -1585,6 +1588,12 @@ static QEMUOptionParameter vmdk_create_options[] = {
>  "VMDK flat extent format, can be one of "
>  "{monolithicSparse (default) | monolithicFlat | 
> twoGbMaxExtentSparse | twoGbMaxExtentFlat | streamOptimized} "
>  },
> +{
> +.name = BLOCK_OPT_SCSI,
> +.type = OPT_FLAG,
> +.help = "Virtual SCSI Adapter"
> +},
> +
>  { NULL }
>  };
>  
> diff --git a/block_int.h b/block_int.h
> index 311bd2a..5e332fb 100644
> --- a/block_int.h
> +++ b/block_int.h
> @@ -33,6 +33,7 @@
>  
>  #define BLOCK_FLAG_ENCRYPT   1
>  #define BLOCK_FLAG_COMPAT6   4
> +#define BLOCK_FLAG_SCSI 8
>  
>  #define BLOCK_IO_LIMIT_READ 0
>  #define BLOCK_IO_LIMIT_WRITE1
> @@ -44,6 +45,7 @@
>  #define BLOCK_OPT_SIZE  "size"
>  #define BLOCK_OPT_ENCRYPT   "encryption"
>  #define BLOCK_OPT_COMPAT6   "compat6"

Re: [Qemu-devel] [PATCH] To support scsi Virtual Adapter while creating VMDK images

[Kevin Wolf]

Am 27.01.2012 17:19, schrieb Andreas Färber:
> Am 27.01.2012 00:46, schrieb praveen_palad...@dell.com:
>> According to VMDK specification, while using virtual scsi adapter, the value 
>> of adapterType has to be set to "lsilogic" or "buslogic". When the user adds 
>> "scsi" to the list of qemu-img options (Example: qemu-img create -f vmdk foo 
>> -o scsi,size=100M) this patch will set the value of adapterType to 
>> "lsilogic".
>>
>> When the "scsi" is not passed, the default "ide" value is used.
> 
>> Signed-off-by: Praveen K Paladugu 
> 
> SoB should be above the patch so that it gets committed. Please cc the
> block maintainer, scripts/get_maintainer.pl can help with that.
> 
> We're carrying a pretty similar patch from 2009 in OBS:
> 
> https://build.opensuse.org/package/view_file?file=qemu-img-vmdk-scsi.patch&package=virt-utils&project=Virtualization&rev=34c58db02d6bfdb1a9dd49fc3c7fa9d4
> 
> There were also patches by Soren Hansen and Kevin Wolf back in 2008, by
> Pantelis Koukousoulas in 2009, by Aaron Mason and Alex Graf in 2010; are
> these all independent or is someone's SoB missing here?

I think they are all independent. Aaron's patch came closest, it just
had some coding style issues (I would fix these myself) and was missing
a Signed-off-by (I can't do anything about that).

The other patches (just like this one) all didn't allow both buslogic
and lsilogic, but hardcoded one of them.

Kevin

[Qemu-devel] [PATCH] Change license from GPLv2 to GPLv2+

[Stefan Weil]

This file only contains code from Red Hat, so it can use GPLv2+.
Tested with `git blame -M -C net/checksum.c`.

Signed-off-by: Stefan Weil 
---
 net/checksum.c |5 +
 1 files changed, 1 insertions(+), 4 deletions(-)

diff --git a/net/checksum.c b/net/checksum.c
index 264c23f..9919b2e 100644
--- a/net/checksum.c
+++ b/net/checksum.c
@@ -4,7 +4,7 @@
  *
  *  This program is free software; you can redistribute it and/or modify
  *  it under the terms of the GNU General Public License as published by
- *  the Free Software Foundation; under version 2 of the License.
+ *  the Free Software Foundation; under version 2 or later of the License.
  *
  *  This program is distributed in the hope that it will be useful,
  *  but WITHOUT ANY WARRANTY; without even the implied warranty of
@@ -13,9 +13,6 @@
  *
  *  You should have received a copy of the GNU General Public License
  *  along with this program; if not, see .
- *
- *  Contributions after 2012-01-13 are licensed under the terms of the
- *  GNU GPL, version 2 or (at your option) any later version.
  */
 
 #include "net/checksum.h"
-- 
1.7.7.3

Re: [Qemu-devel] [PULL 00/22] Block patches

[Anthony Liguori]

On 01/26/2012 10:37 AM, Kevin Wolf wrote:

The following changes since commit 331636431af32ece373f4b1fb7c3ae9d0615e2a6:

   vga: compile cirrus_vga in hwlib (2012-01-25 18:32:59 +)

are available in the git repository at:
   git://repo.or.cz/qemu/kevin.git for-anthony


Pulled.  Thanks.

Regards,

Anthony Liguori



Gregory Farnum (1):
   rbd: wire up snapshot removal and rollback functionality

Li Zhi Hui (2):
   qcow: Return real error code in qcow_open
   qcow: Use bdrv functions to replace file operation

Marcelo Tosatti (4):
   block: add bdrv_find_backing_image
   add QERR_BASE_NOT_FOUND
   block: add support for partial streaming
   docs: describe live block operations

Stefan Hajnoczi (13):
   block: replace unchecked strdup/malloc/calloc with glib
   coroutine: add co_sleep_ns() coroutine sleep function
   block: check bdrv_in_use() before blockdev operations
   block: make copy-on-read a per-request flag
   block: add BlockJob interface for long-running operations
   block: add image streaming block job
   block: rate-limit streaming operations
   qmp: add block_stream command
   qmp: add block_job_set_speed command
   qmp: add block_job_cancel command
   qmp: add query-block-jobs
   blockdev: make image streaming safe across hotplug
   virtio-blk: add virtio_blk_handle_read trace event

Stefan Weil (1):
   block/vdi: Zero unused parts when allocating a new block (fix #919242)

Thomas Higdon (1):
   scsi: Guard against buflen exceeding req->cmd.xfer in 
scsi_disk_emulate_command

  Makefile.objs   |2 +
  QMP/qmp-events.txt  |   53 +
  block.c |  119 +++--
  block.h |4 +
  block/blkdebug.c|4 +-
  block/blkverify.c   |4 +-
  block/qcow.c|  104 ---
  block/rbd.c |   22 
  block/stream.c  |  269 +++
  block/vdi.c |8 +-
  block_int.h |   47 
  blockdev.c  |  199 ++-
  docs/live-block-ops.txt |   58 ++
  hmp-commands.hx |   41 +++
  hmp.c   |   68 
  hmp.h   |4 +
  hw/scsi-disk.c  |   10 +--
  hw/virtio-blk.c |2 +
  monitor.c   |   13 +++
  monitor.h   |2 +
  qapi-schema.json|  115 
  qemu-coroutine-sleep.c  |   38 +++
  qemu-coroutine.h|9 ++
  qemu-io.c   |   48 
  qerror.c|8 ++
  qerror.h|6 +
  qmp-commands.hx |   24 
  trace-events|   13 ++-
  28 files changed, 1206 insertions(+), 88 deletions(-)
  create mode 100644 block/stream.c
  create mode 100644 docs/live-block-ops.txt
  create mode 100644 qemu-coroutine-sleep.c

Re: [Qemu-devel] [PULL 0/5] arm-devs queue (to go after target-arm queue)

[Anthony Liguori]

On 01/26/2012 08:02 AM, Peter Maydell wrote:

Hi; this is a pullreq for my arm-devs queue, which is basically
the Highbank patches.

There is a slight sequencing issue here: it would be better if
this went in after the target-arm queue which I sent a pullreq
for yesterday, because that includes a bugfix which Highbank
depends on. It's not a disaster to put them in out of order,
because it won't fail to build, it's just you don't get a working
Highbank model until both bits are there and it seems aesthetically
more pleasing for that to be the point where we commit the actual
board model patch.

I'd also like this to go in before Anthony's QOM patchset, which
is why I'm posting this now rather than waiting for target-arm
to be pulled :-)

thanks
-- PMM


Pulled.  Thanks.

Regards,

Anthony Liguori



The following changes since commit 331636431af32ece373f4b1fb7c3ae9d0615e2a6:

   vga: compile cirrus_vga in hwlib (2012-01-25 18:32:59 +)

are available in the git repository at:
   git://git.linaro.org/people/pmaydell/qemu-arm.git arm-devs.for-upstream

Mark Langsdorf (1):
   arm: add secondary cpu boot callbacks to arm_boot.c

Peter Maydell (1):
   arm_boot: support board IDs more than 16 bits wide

Rob Herring (3):
   Add xgmac ethernet model
   ahci: add support for non-PCI based controllers
   arm: SoC model for Calxeda Highbank

  Makefile.target |2 +
  hw/arm-misc.h   |   17 +++
  hw/arm_boot.c   |   65 +++---
  hw/highbank.c   |  330 +++
  hw/ide/ahci.c   |   44 ++
  hw/xgmac.c  |  421 +++
  6 files changed, 862 insertions(+), 17 deletions(-)
  create mode 100644 hw/highbank.c
  create mode 100644 hw/xgmac.c

Re: [Qemu-devel] [PULL 0/6] Trivial patches for 20 to 27 January 2012

[Anthony Liguori]

On 01/27/2012 01:27 AM, Stefan Hajnoczi wrote:

The following changes since commit 331636431af32ece373f4b1fb7c3ae9d0615e2a6:

   vga: compile cirrus_vga in hwlib (2012-01-25 18:32:59 +)

are available in the git repository at:
   git://github.com/stefanha/qemu.git trivial-patches


Pulled.  Thanks.

Regards,

Anthony Liguori



Jan Kiszka (3):
   qdev-property: Make bit property parsing stricter
   e1000: Preserve link state across device reset
   pcnet: Preserve link state across device reset

Laszlo Ersek (1):
   qemu-io: end aio help text sentences with periods

Paolo Bonzini (1):
   remove #if 0 code for timers

Sergei Trofimovich (1):
   ./configure: export xfs config via --{enable, disable}-xfsctl

  configure|4 
  hw/e1000.c   |5 +
  hw/pcnet.c   |3 ++-
  hw/qdev-properties.c |4 ++--
  qemu-io.c|4 ++--
  qemu-timer.c |   29 -
  6 files changed, 15 insertions(+), 34 deletions(-)

Re: [Qemu-devel] [PATCH v3 0/28] qom: add QEMU Object Model type hierarchy to qdev

[Anthony Liguori]

On 01/24/2012 01:32 PM, Anthony Liguori wrote:

This series makes qdev a proper Object and converts qdev's type inheritance to
QOM inheritance.

The first half of the series are manual cleanups/refactorings.  The second half
is mostly scripted conversion, separated out into reviewable and bisectable
chunks.

I've tested this series extensively for the pc target including bisectability.
I have not tested any other targets yet so your mileage may vary.

Since the original RFC, I've fixed any of the not-for-upstream issues.  This
also includes some uni-north patches that are in ppc-next.

Paolo and Andreas have asked that I declare a date when I'll merge this so that
people can be prepared for the rebase fall out.  I will merge this on Friday
unless there is a major problem found in review.


Applied (with the few changes requested).

Even anyone encounters a problem rebasing after this series, please feel free to 
poke me for help.  There should be ample examples of how to use the new 
infrastructure too.


Regards,

Anthony Liguori



This is also available at:

https://github.com/aliguori/qemu/tree/qom-upstream.10

For full context, the whole tree is located at:

https://github.com/aliguori/qemu/commits/qom-rebase.7

git diffstat origin/master HEAD
  Makefile   |2
  Makefile.hw|1
  Makefile.objs  |3
  Makefile.target|2
  configure  |2
  hw/9pfs/virtio-9p-device.c |   44 ++--
  hw/a9mpcore.c  |   21 +
  hw/ac97.c  |   39 ++-
  hw/acpi_piix4.c|   59 +++--
  hw/ads7846.c   |   17 +
  hw/alpha_typhoon.c |   17 +
  hw/apb_pci.c   |   71 --
  hw/apic.c  |   21 +
  hw/apic_common.c   |   88 +---
  hw/apic_internal.h |   32 +-
  hw/applesmc.c  |   18 +
  hw/arm11mpcore.c   |   68 +++---
  hw/arm_l2x0.c  |   25 +-
  hw/arm_mptimer.c   |   23 +-
  hw/arm_sysctl.c|   31 +-
  hw/arm_timer.c |   46 +++-
  hw/armv7m.c|   25 +-
  hw/armv7m_nvic.c   |   21 +
  hw/bitbang_i2c.c   |   17 +
  hw/bonito.c|   47 ++--
  hw/ccid-card-emulated.c|   27 +-
  hw/ccid-card-passthru.c|   27 +-
  hw/ccid.h  |   28 +-
  hw/cirrus_vga.c|   50 ++--
  hw/container.c |   17 +
  hw/cs4231.c|   27 +-
  hw/cs4231a.c   |   20 +
  hw/debugcon.c  |   16 +
  hw/dec_pci.c   |   74 --
  hw/ds1225y.c   |   29 +-
  hw/ds1338.c|   31 +-
  hw/e1000.c |   45 ++--
  hw/eccmemctl.c |   29 +-
  hw/eepro100.c  |  202 +++---
  hw/empty_slot.c|   15 +
  hw/es1370.c|   36 +--
  hw/escc.c  |   43 ++-
  hw/esp.c   |   27 +-
  hw/etraxfs_eth.c   |   33 +--
  hw/etraxfs_pic.c   |   25 +-
  hw/etraxfs_ser.c   |   17 +
  hw/etraxfs_timer.c |   16 +
  hw/fdc.c   |   84 +--
  hw/fw_cfg.c|   33 +--
  hw/g364fb.c|   33 +--
  hw/grackle_pci.c   |   44 ++--
  hw/grlib_apbuart.c |   25 +-
  hw/grlib_gptimer.c |   31 +-
  hw/grlib_irqmp.c   |   29 +-
  hw/gt64xxx.c   |   39 ++-
  hw/gus.c   |   20 +
  hw/hda-audio.c |   60 +++--
  hw/hpet.c  |   33 +--
  hw/i2c.c   |  111 +++---
  hw/i2c.h   |   52 ++--
  hw/i82374.c|   19 +
  hw/i82378.c|   31 +-
  hw/i8254.c |   22 +-
  hw/i8259.c |   15 +
  hw/i8259_common.c  |   45 ++--
  hw/i8259_internal.h|   27 +-
  hw/ide/cmd646.c|   41 ++-
  hw/ide/ich.c   |   37 +--
  hw/ide/internal.h  |   20 +
  hw/ide/isa.c   |   20 +
  hw/ide/piix.c  |   91 +---
  hw/ide/qdev.c  |  111 ++
  hw/ide/via.c   |   27 +-
  hw/integratorcp.c  |   40 ++-
  hw/intel-hda.c |   91 +---
  hw/intel-hda.h |   26 +-
  hw/ioapic.c|   17 +
  hw/ioapic_common.c |   49 +++-
  hw/ioapic_internal.h   |   26 +-
  hw/ioh3420.c   |   59 +++--
  hw/isa-bus.c   |   57 +++--
  hw/isa.h   |   23 +-
  hw/ivshmem.c   |   47 ++--
  hw/kvm/apic.c  |   19 +
  hw/kvm/clock.c |   19 +
  hw/kvm/i8259.c |   19 +
  hw/kvm/ioapic.c|   23 +-
  hw/lan9118.c   |   31 +-
  hw/lance.c |   33 +--
  hw/lm32_juart.c|   19 +
  hw/lm32_pic.c  |   19 +
  hw/lm32_sys.c  |   29 +-
  hw/lm32_timer.c|   31 +-
  hw/lm32_uart.c |

[Qemu-devel] ICH6+ chipset emulation

[Dmitry Zamaruev]

Hi,

I'm trying to run specific firmware under QEMU, and it is tied
(hardcoded) to newer chipsets than QEMU currently supports.
I know there was an effort to emulate Q35, but it seems not to get mainstream.
Is there any chance to see one of ICH6/7/8/9/10 emulated in QEMU ?

wbr,
Dmitry.

[Qemu-devel] [PATCH] MAINTAINERS: Add a section for the host OS and a W32 maintainer

[Stefan Weil]

Up to now, there was no special section for the different
host operating systems used with QEMU.

scripts/get_maintainer.pl did not show a maintainer for
OS specific files and patches.

Therefore I added three hosts systems:

* POSIX for the majority of host systems which are supported.
  This includes BSD and Linux host systems.

* LINUX is a special case of POSIX needed for some Linux specific
  files and directories.

* W32, W64 for a well known family of closed source operating systems.

I also added myself as a maintainer for W32, W64.

Signed-off-by: Stefan Weil 
---
 MAINTAINERS |   20 
 1 files changed, 20 insertions(+), 0 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 73c0a10..882958e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -161,6 +161,26 @@ S: Supported
 F: xen-*
 F: */xen*
 
+Hosts:
+--
+
+LINUX
+L: qemu-devel@nongnu.org
+S: Maintained
+F: linux-*
+F: linux-headers/
+
+POSIX
+L: qemu-devel@nongnu.org
+S: Maintained
+F: *posix*
+
+W32, W64
+L: qemu-devel@nongnu.org
+M: Stefan Weil 
+S: Maintained
+F: *win32*
+
 ARM Machines
 
 Gumstix
-- 
1.7.7.3

Re: [Qemu-devel] [PATCH] To support scsi Virtual Adapter while creating VMDK images

[Praveen_Paladugu]

I didn't know other patches were already submitted. I picked up the patch from 
opensuse distribution. I realized no related code is available in upstream 
project. So I created one based on the head of the git tree.

Please feel free to ignore this patch, since other/better patches seem to be 
available. 



Thank you 
Praveen K Paladugu
Dell Linux Engineering

[Qemu-devel] [PATCH v3 0/6] prevent Qemu from waking up needlessly

[Stefano Stabellini]

Hi all,
this small patch series prevents Qemu from waking up needlessly on Xen
several times a second in order to check some timers.



The first patch stops Qemu from emulating the PIT on Xen, the second
patch disables the rtc_clock entirely.

The third patch makes use of a new mechanism to receive buffered io
event notifications from Xen, so that Qemu doesn't need to check the
buffered io page for data 10 times a sec for the entire life of the VM.

The fourth patch fixes win32_rearm_timer and mm_rearm_timer that
risk an overflow if INT64_MAX is passed as delta.

The fifth patch changes qemu_next_alarm_deadline only to check the
expire time of a clock if it is enabled.

Finally the last patch increases the default select timeout to 1h:
nothing should rely on the select timeout to be 1sec, so we might as
well increase it to 1h.



Changes in v3:

- added a new patch to fix win32_rearm_timer and mm_rearm_timer, that
risk an overflow if INT64_MAX is passed as delta.




Shortlog and diffstat follow:

Stefano Stabellini (6):
  xen: do not initialize the interval timer emulator
  xen: disable rtc_clock
  xen: introduce an event channel for buffered io event notifications
  timers: the rearm function should be able to handle delta = INT64_MAX
  qemu_next_alarm_deadline: check the expire time of a clock only if it is 
enabled
  qemu_calculate_timeout: increase minimum timeout to 1h

 hw/pc.c  |7 +--
 qemu-timer.c |   30 ++
 xen-all.c|   43 +--
 3 files changed, 60 insertions(+), 20 deletions(-)


A git tree available here:

git://xenbits.xen.org/people/sstabellini/qemu-dm.git timers-3

Cheers,

Stefano

[Qemu-devel] [PATCH v3 5/6] qemu_next_alarm_deadline: check the expire time of a clock only if it is enabled

[Stefano Stabellini]

Also delta in qemu_next_alarm_deadline is a 64 bit value so set the
default to INT64_MAX instead of INT32_MAX.

Signed-off-by: Stefano Stabellini 
---
 qemu-timer.c |   10 --
 1 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/qemu-timer.c b/qemu-timer.c
index a9ba0eb..8c8bbc3 100644
--- a/qemu-timer.c
+++ b/qemu-timer.c
@@ -106,23 +106,21 @@ static inline int alarm_has_dynticks(struct 
qemu_alarm_timer *t)
 
 static int64_t qemu_next_alarm_deadline(void)
 {
-int64_t delta;
+int64_t delta = INT64_MAX;
 int64_t rtdelta;
 
-if (!use_icount && vm_clock->active_timers) {
+if (!use_icount && vm_clock->enabled && vm_clock->active_timers) {
 delta = vm_clock->active_timers->expire_time -
  qemu_get_clock_ns(vm_clock);
-} else {
-delta = INT32_MAX;
 }
-if (host_clock->active_timers) {
+if (host_clock->enabled && host_clock->active_timers) {
 int64_t hdelta = host_clock->active_timers->expire_time -
  qemu_get_clock_ns(host_clock);
 if (hdelta < delta) {
 delta = hdelta;
 }
 }
-if (rt_clock->active_timers) {
+if (rt_clock->enabled && rt_clock->active_timers) {
 rtdelta = (rt_clock->active_timers->expire_time -
  qemu_get_clock_ns(rt_clock));
 if (rtdelta < delta) {
-- 
1.7.2.5

[Qemu-devel] [PATCH v3 1/6] xen: do not initialize the interval timer emulator

[Stefano Stabellini]

PIT is emulated by the hypervisor so we don't need to emulate it in Qemu:
this patch prevents Qemu from waking up needlessly at PIT_FREQ on Xen.

Signed-off-by: Stefano Stabellini 
---
 hw/pc.c |7 +--
 1 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/hw/pc.c b/hw/pc.c
index 85304cf..7a7ce98 100644
--- a/hw/pc.c
+++ b/hw/pc.c
@@ -43,6 +43,7 @@
 #include "ui/qemu-spice.h"
 #include "memory.h"
 #include "exec-memory.h"
+#include "arch_init.h"
 
 /* output Bochs bios info messages */
 //#define DEBUG_BIOS
@@ -1130,7 +1131,7 @@ void pc_basic_device_init(ISABus *isa_bus, qemu_irq *gsi,
 DriveInfo *fd[MAX_FD];
 qemu_irq rtc_irq = NULL;
 qemu_irq *a20_line;
-ISADevice *i8042, *port92, *vmmouse, *pit;
+ISADevice *i8042, *port92, *vmmouse, *pit = NULL;
 qemu_irq *cpu_exit_irq;
 
 register_ioport_write(0x80, 1, 1, ioport80_write, NULL);
@@ -1151,7 +1152,9 @@ void pc_basic_device_init(ISABus *isa_bus, qemu_irq *gsi,
 
 qemu_register_boot_set(pc_boot_set, *rtc_state);
 
-pit = pit_init(isa_bus, 0x40, 0);
+if (!xen_available()) {
+pit = pit_init(isa_bus, 0x40, 0);
+}
 pcspk_init(pit);
 
 for(i = 0; i < MAX_SERIAL_PORTS; i++) {
-- 
1.7.2.5

[Qemu-devel] [PATCH v3 6/6] qemu_calculate_timeout: increase minimum timeout to 1h

[Stefano Stabellini]

There is no reason why the minimum timeout should be 1sec, it could
easily be 1h and we would save lots of cpu cycles.

Signed-off-by: Stefano Stabellini 
---
 qemu-timer.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/qemu-timer.c b/qemu-timer.c
index 8c8bbc3..3207e40 100644
--- a/qemu-timer.c
+++ b/qemu-timer.c
@@ -852,6 +852,6 @@ fail:
 
 int qemu_calculate_timeout(void)
 {
-return 1000;
+return 1000*60*60;
 }
 
-- 
1.7.2.5

[Qemu-devel] [PATCH v3 4/6] timers: the rearm function should be able to handle delta = INT64_MAX

[Stefano Stabellini]

Fix win32_rearm_timer and mm_rearm_timer: they should be able to handle
INT64_MAX as a delta parameter without overflowing.
Also, the next deadline in ms should be calculated rounding down rather
than up (see unix_rearm_timer and dynticks_rearm_timer).

Finally ChangeTimerQueueTimer takes an unsigned long and timeSetEvent
takes an unsigned int as delta, so cast the ms delta to the appropriate
unsigned integer.

Signed-off-by: Stefano Stabellini 
---
 qemu-timer.c |   18 +-
 1 files changed, 13 insertions(+), 5 deletions(-)

diff --git a/qemu-timer.c b/qemu-timer.c
index cd026c6..a9ba0eb 100644
--- a/qemu-timer.c
+++ b/qemu-timer.c
@@ -725,13 +725,17 @@ static void mm_stop_timer(struct qemu_alarm_timer *t)
 
 static void mm_rearm_timer(struct qemu_alarm_timer *t, int64_t delta)
 {
-int nearest_delta_ms = (delta + 99) / 100;
+int64_t nearest_delta_ms = delta / 100;
 if (nearest_delta_ms < 1) {
 nearest_delta_ms = 1;
 }
+/* UINT_MAX can be 32 bit */
+if (nearest_delta_ms > UINT_MAX) {
+nearest_delta_ms = UINT_MAX;
+}
 
 timeKillEvent(mm_timer);
-mm_timer = timeSetEvent(nearest_delta_ms,
+mm_timer = timeSetEvent((unsigned int) nearest_delta_ms,
 mm_period,
 mm_alarm_handler,
 (DWORD_PTR)t,
@@ -786,16 +790,20 @@ static void win32_rearm_timer(struct qemu_alarm_timer *t,
   int64_t nearest_delta_ns)
 {
 HANDLE hTimer = t->timer;
-int nearest_delta_ms;
+int64_t nearest_delta_ms;
 BOOLEAN success;
 
-nearest_delta_ms = (nearest_delta_ns + 99) / 100;
+nearest_delta_ms = nearest_delta_ns / 100;
 if (nearest_delta_ms < 1) {
 nearest_delta_ms = 1;
 }
+/* ULONG_MAX can be 32 bit */
+if (nearest_delta_ms > ULONG_MAX) {
+nearest_delta_ms = ULONG_MAX;
+}
 success = ChangeTimerQueueTimer(NULL,
 hTimer,
-nearest_delta_ms,
+(unsigned long) nearest_delta_ms,
 360);
 
 if (!success) {
-- 
1.7.2.5

[Qemu-devel] [PATCH v3 3/6] xen: introduce an event channel for buffered io event notifications

[Stefano Stabellini]

Use the newly introduced HVM_PARAM_BUFIOREQ_EVTCHN to receive
notifications for buffered io events.
After the first notification is received leave the event channel masked
and setup a timer to process the rest of the batch.
Once we have completed processing the batch, unmask the event channel
and delete the timer.

Signed-off-by: Stefano Stabellini 
---
 xen-all.c |   42 --
 1 files changed, 36 insertions(+), 6 deletions(-)

diff --git a/xen-all.c b/xen-all.c
index bf183f7..bfec4c1 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -77,6 +77,8 @@ typedef struct XenIOState {
 QEMUTimer *buffered_io_timer;
 /* the evtchn port for polling the notification, */
 evtchn_port_t *ioreq_local_port;
+/* evtchn local port for buffered io */
+evtchn_port_t bufioreq_local_port;
 /* the evtchn fd for polling */
 XenEvtchn xce_handle;
 /* which vcpu we are serving */
@@ -545,6 +547,12 @@ static ioreq_t *cpu_get_ioreq(XenIOState *state)
 evtchn_port_t port;
 
 port = xc_evtchn_pending(state->xce_handle);
+if (port == state->bufioreq_local_port) {
+qemu_mod_timer(state->buffered_io_timer,
+BUFFER_IO_MAX_DELAY + qemu_get_clock_ms(rt_clock));
+return NULL;
+}
+
 if (port != -1) {
 for (i = 0; i < smp_cpus; i++) {
 if (state->ioreq_local_port[i] == port) {
@@ -693,16 +701,18 @@ static void handle_ioreq(ioreq_t *req)
 }
 }
 
-static void handle_buffered_iopage(XenIOState *state)
+static int handle_buffered_iopage(XenIOState *state)
 {
 buf_ioreq_t *buf_req = NULL;
 ioreq_t req;
 int qw;
 
 if (!state->buffered_io_page) {
-return;
+return 0;
 }
 
+memset(&req, 0x00, sizeof(req));
+
 while (state->buffered_io_page->read_pointer != 
state->buffered_io_page->write_pointer) {
 buf_req = &state->buffered_io_page->buf_ioreq[
 state->buffered_io_page->read_pointer % IOREQ_BUFFER_SLOT_NUM];
@@ -727,15 +737,21 @@ static void handle_buffered_iopage(XenIOState *state)
 xen_mb();
 state->buffered_io_page->read_pointer += qw ? 2 : 1;
 }
+
+return req.count;
 }
 
 static void handle_buffered_io(void *opaque)
 {
 XenIOState *state = opaque;
 
-handle_buffered_iopage(state);
-qemu_mod_timer(state->buffered_io_timer,
-   BUFFER_IO_MAX_DELAY + qemu_get_clock_ms(rt_clock));
+if (handle_buffered_iopage(state)) {
+qemu_mod_timer(state->buffered_io_timer,
+BUFFER_IO_MAX_DELAY + qemu_get_clock_ms(rt_clock));
+} else {
+qemu_del_timer(state->buffered_io_timer);
+xc_evtchn_unmask(state->xce_handle, state->bufioreq_local_port);
+}
 }
 
 static void cpu_handle_ioreq(void *opaque)
@@ -865,7 +881,6 @@ static void xen_main_loop_prepare(XenIOState *state)
 
 state->buffered_io_timer = qemu_new_timer_ms(rt_clock, handle_buffered_io,
  state);
-qemu_mod_timer(state->buffered_io_timer, qemu_get_clock_ms(rt_clock));
 
 if (evtchn_fd != -1) {
 qemu_set_fd_handler(evtchn_fd, cpu_handle_ioreq, NULL, state);
@@ -917,6 +932,7 @@ int xen_hvm_init(void)
 {
 int i, rc;
 unsigned long ioreq_pfn;
+unsigned long bufioreq_evtchn;
 XenIOState *state;
 
 state = g_malloc0(sizeof (XenIOState));
@@ -966,6 +982,20 @@ int xen_hvm_init(void)
 state->ioreq_local_port[i] = rc;
 }
 
+rc = xc_get_hvm_param(xen_xc, xen_domid, HVM_PARAM_BUFIOREQ_EVTCHN,
+&bufioreq_evtchn);
+if (rc < 0) {
+fprintf(stderr, "failed to get HVM_PARAM_BUFIOREQ_EVTCHN\n");
+return -1;
+}
+rc = xc_evtchn_bind_interdomain(state->xce_handle, xen_domid,
+(uint32_t)bufioreq_evtchn);
+if (rc == -1) {
+fprintf(stderr, "bind interdomain ioctl error %d\n", errno);
+return -1;
+}
+state->bufioreq_local_port = rc;
+
 /* Init RAM management */
 xen_map_cache_init();
 xen_ram_init(ram_size);
-- 
1.7.2.5

[Qemu-devel] [PATCH v3 2/6] xen: disable rtc_clock

[Stefano Stabellini]

rtc_clock is only used by the RTC emulator (mc146818rtc.c), however Xen
has its own RTC emulator in the hypervisor so we can disable it.

Signed-off-by: Stefano Stabellini 
---
 xen-all.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/xen-all.c b/xen-all.c
index d1fc597..bf183f7 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -513,6 +513,7 @@ void xen_vcpu_init(void)
 qemu_register_reset(xen_reset_vcpu, first_cpu);
 xen_reset_vcpu(first_cpu);
 }
+qemu_clock_enable(rtc_clock, false);
 }
 
 /* get the ioreq packets from share mem */
-- 
1.7.2.5

[Qemu-devel] [PATCH 1/2] qemu-option: Introduce default mechanism

[Jan Kiszka]

This adds qemu_opts_set_defaults, an interface provide default values
for a QemuOpts set. Default options are parsed from a string and then
prepended to the list of existing options, or they serve as the sole
QemuOpts set.

Signed-off-by: Jan Kiszka 
---
 qemu-option.c |   58 +---
 qemu-option.h |2 +
 2 files changed, 52 insertions(+), 8 deletions(-)

diff --git a/qemu-option.c b/qemu-option.c
index a303f87..4626ccf 100644
--- a/qemu-option.c
+++ b/qemu-option.c
@@ -603,7 +603,8 @@ static void qemu_opt_del(QemuOpt *opt)
 g_free(opt);
 }
 
-int qemu_opt_set(QemuOpts *opts, const char *name, const char *value)
+static int opt_set(QemuOpts *opts, const char *name, const char *value,
+   bool prepend)
 {
 QemuOpt *opt;
 const QemuOptDesc *desc = opts->list->desc;
@@ -626,7 +627,11 @@ int qemu_opt_set(QemuOpts *opts, const char *name, const 
char *value)
 opt = g_malloc0(sizeof(*opt));
 opt->name = g_strdup(name);
 opt->opts = opts;
-QTAILQ_INSERT_TAIL(&opts->head, opt, next);
+if (prepend) {
+QTAILQ_INSERT_HEAD(&opts->head, opt, next);
+} else {
+QTAILQ_INSERT_TAIL(&opts->head, opt, next);
+}
 if (desc[i].name != NULL) {
 opt->desc = desc+i;
 }
@@ -640,6 +645,11 @@ int qemu_opt_set(QemuOpts *opts, const char *name, const 
char *value)
 return 0;
 }
 
+int qemu_opt_set(QemuOpts *opts, const char *name, const char *value)
+{
+return opt_set(opts, name, value, false);
+}
+
 int qemu_opt_set_bool(QemuOpts *opts, const char *name, bool val)
 {
 QemuOpt *opt;
@@ -691,6 +701,9 @@ QemuOpts *qemu_opts_find(QemuOptsList *list, const char *id)
 
 QTAILQ_FOREACH(opts, &list->head, next) {
 if (!opts->id) {
+if (!id) {
+return opts;
+}
 continue;
 }
 if (strcmp(opts->id, id) != 0) {
@@ -806,7 +819,8 @@ int qemu_opts_print(QemuOpts *opts, void *dummy)
 return 0;
 }
 
-int qemu_opts_do_parse(QemuOpts *opts, const char *params, const char 
*firstname)
+static int opts_do_parse(QemuOpts *opts, const char *params,
+ const char *firstname, bool prepend)
 {
 char option[128], value[1024];
 const char *p,*pe,*pc;
@@ -841,7 +855,7 @@ int qemu_opts_do_parse(QemuOpts *opts, const char *params, 
const char *firstname
 }
 if (strcmp(option, "id") != 0) {
 /* store and parse */
-if (qemu_opt_set(opts, option, value) == -1) {
+if (opt_set(opts, option, value, prepend) == -1) {
 return -1;
 }
 }
@@ -852,8 +866,13 @@ int qemu_opts_do_parse(QemuOpts *opts, const char *params, 
const char *firstname
 return 0;
 }
 
-QemuOpts *qemu_opts_parse(QemuOptsList *list, const char *params,
-  int permit_abbrev)
+int qemu_opts_do_parse(QemuOpts *opts, const char *params, const char 
*firstname)
+{
+return opts_do_parse(opts, params, firstname, false);
+}
+
+static QemuOpts *opts_parse(QemuOptsList *list, const char *params,
+int permit_abbrev, bool defaults)
 {
 const char *firstname;
 char value[1024], *id = NULL;
@@ -870,11 +889,19 @@ QemuOpts *qemu_opts_parse(QemuOptsList *list, const char 
*params,
 get_opt_value(value, sizeof(value), p+4);
 id = value;
 }
-opts = qemu_opts_create(list, id, 1);
+if (defaults) {
+if (!id && !QTAILQ_EMPTY(&list->head)) {
+opts = qemu_opts_find(list, NULL);
+} else {
+opts = qemu_opts_create(list, id, 0);
+}
+} else {
+opts = qemu_opts_create(list, id, 1);
+}
 if (opts == NULL)
 return NULL;
 
-if (qemu_opts_do_parse(opts, params, firstname) != 0) {
+if (opts_do_parse(opts, params, firstname, defaults) != 0) {
 qemu_opts_del(opts);
 return NULL;
 }
@@ -882,6 +909,21 @@ QemuOpts *qemu_opts_parse(QemuOptsList *list, const char 
*params,
 return opts;
 }
 
+QemuOpts *qemu_opts_parse(QemuOptsList *list, const char *params,
+  int permit_abbrev)
+{
+return opts_parse(list, params, permit_abbrev, false);
+}
+
+void qemu_opts_set_defaults(QemuOptsList *list, const char *params,
+int permit_abbrev)
+{
+QemuOpts *opts;
+
+opts = opts_parse(list, params, permit_abbrev, true);
+assert(opts);
+}
+
 static void qemu_opts_from_qdict_1(const char *key, QObject *obj, void *opaque)
 {
 char buf[32];
diff --git a/qemu-option.h b/qemu-option.h
index 07958e4..e6f61e6 100644
--- a/qemu-option.h
+++ b/qemu-option.h
@@ -125,6 +125,8 @@ void qemu_opts_del(QemuOpts *opts);
 int qemu_opts_validate(QemuOpts *opts, const QemuOptDesc *desc);
 int qemu_opts_do_parse(QemuOpts *opts, const char *params, const char 
*firstname);
 QemuOpts *qemu_opts_parse(QemuOptsList *list, const char *params, int 
permit_abbrev);
+void qemu

[Qemu-devel] [PATCH 2/2] Improve default machine options usability

[Jan Kiszka]

So far we overwrite the machine options completely with defaults if no
accel=value is provided. More user friendly is to fill in only
unspecified options. The new qemu_opts_set_defaults enables this.

Signed-off-by: Jan Kiszka 
---
 vl.c |   17 ++---
 1 files changed, 2 insertions(+), 15 deletions(-)

diff --git a/vl.c b/vl.c
index 6af0f83..138f6bc 100644
--- a/vl.c
+++ b/vl.c
@@ -3153,21 +3153,8 @@ int main(int argc, char **argv, char **envp)
  * specified either by the configuration file or by the command line.
  */
 if (machine->default_machine_opts) {
-QemuOptsList *list = qemu_find_opts("machine");
-const char *p = NULL;
-
-if (!QTAILQ_EMPTY(&list->head)) {
-p = qemu_opt_get(QTAILQ_FIRST(&list->head), "accel");
-}
-if (p == NULL) {
-qemu_opts_reset(list);
-opts = qemu_opts_parse(list, machine->default_machine_opts, 0);
-if (!opts) {
-fprintf(stderr, "parse error for machine %s: %s\n",
-machine->name, machine->default_machine_opts);
-exit(1);
-}
-}
+qemu_opts_set_defaults(qemu_find_opts("machine"),
+   machine->default_machine_opts, 0);
 }
 
 qemu_opts_foreach(qemu_find_opts("device"), default_driver_check, NULL, 0);
-- 
1.7.3.4

Re: [Qemu-devel] [PATCH v3 1/6] xen: do not initialize the interval timer emulator

[Jan Kiszka]

On 2012-01-27 19:21, Stefano Stabellini wrote:
> PIT is emulated by the hypervisor so we don't need to emulate it in Qemu:
> this patch prevents Qemu from waking up needlessly at PIT_FREQ on Xen.
> 
> Signed-off-by: Stefano Stabellini 
> ---
>  hw/pc.c |7 +--
>  1 files changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/hw/pc.c b/hw/pc.c
> index 85304cf..7a7ce98 100644
> --- a/hw/pc.c
> +++ b/hw/pc.c
> @@ -43,6 +43,7 @@
>  #include "ui/qemu-spice.h"
>  #include "memory.h"
>  #include "exec-memory.h"
> +#include "arch_init.h"
>  
>  /* output Bochs bios info messages */
>  //#define DEBUG_BIOS
> @@ -1130,7 +1131,7 @@ void pc_basic_device_init(ISABus *isa_bus, qemu_irq 
> *gsi,
>  DriveInfo *fd[MAX_FD];
>  qemu_irq rtc_irq = NULL;
>  qemu_irq *a20_line;
> -ISADevice *i8042, *port92, *vmmouse, *pit;
> +ISADevice *i8042, *port92, *vmmouse, *pit = NULL;
>  qemu_irq *cpu_exit_irq;
>  
>  register_ioport_write(0x80, 1, 1, ioport80_write, NULL);
> @@ -1151,7 +1152,9 @@ void pc_basic_device_init(ISABus *isa_bus, qemu_irq 
> *gsi,
>  
>  qemu_register_boot_set(pc_boot_set, *rtc_state);
>  
> -pit = pit_init(isa_bus, 0x40, 0);
> +if (!xen_available()) {
> +pit = pit_init(isa_bus, 0x40, 0);
> +}
>  pcspk_init(pit);
>  
>  for(i = 0; i < MAX_SERIAL_PORTS; i++) {

Thus as guest accessing to port 0x61 will be able to crash qemu because
pit is NULL? Or do you emulate that port in the kernel? If not, you
likely want to move pcspk_init() under the same umbrella.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

[Qemu-devel] [PATCH] unin_pci: Fix typos in device names

[Andreas Färber]

Commit 999e12bbe85c5dcf49bef13bce4f97399c7105f4 (sysbus: apic: ioapic:
convert to QEMU Object Model) introduced two typos, one of which broke
the mac99 machine.

Signed-off-by: Andreas Färber 
Cc: Anthony Liguori 
---
 hw/unin_pci.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/hw/unin_pci.c b/hw/unin_pci.c
index 2b394c0..9822353 100644
--- a/hw/unin_pci.c
+++ b/hw/unin_pci.c
@@ -415,7 +415,7 @@ static void pci_unin_main_class_init(ObjectClass *klass, 
void *data)
 }
 
 static DeviceInfo pci_unin_main_info = {
-.name = "uni-north-pci-pchost",
+.name = "uni-north-pci-pcihost",
 .size = sizeof(UNINState),
 .class_init = pci_unin_main_class_init,
 };
@@ -454,7 +454,7 @@ static void pci_unin_internal_class_init(ObjectClass 
*klass, void *data)
 }
 
 static DeviceInfo pci_unin_internal_info = {
-.name = "uni-north-internal-pci-pichost",
+.name = "uni-north-internal-pci-pcihost",
 .size = sizeof(UNINState),
 .class_init = pci_unin_internal_class_init,
 };
-- 
1.7.7

Re: [Qemu-devel] ICH6+ chipset emulation

[Jan Kiszka]

On 2012-01-27 17:18, Dmitry Zamaruev wrote:
> Hi,
> 
> I'm trying to run specific firmware under QEMU, and it is tied
> (hardcoded) to newer chipsets than QEMU currently supports.
> I know there was an effort to emulate Q35, but it seems not to get mainstream.
> Is there any chance to see one of ICH6/7/8/9/10 emulated in QEMU ?

Good question. Isaku, what is the current state of your q35 efforts?

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: [Qemu-devel] [PATCH v3 5/9] fdc: add CCR (Configuration Control Register) write register

[Hervé Poussineau]

Markus Armbruster a écrit :

Hervé Poussineau  writes:


DIR and CCR registers share the same address ; DIR is read-only
while CCR is write-only


Looks like guest writes to CCR are silently ignored before this patch.
Is that correct?  


Yes.


Impact?


CCR is only used to program media rate, which is not checked without 
this patchset.


So, none for this patch.

Re: [Qemu-devel] [PATCH v3 2/6] xen: disable rtc_clock

[Paolo Bonzini]

On 01/27/2012 07:21 PM, Stefano Stabellini wrote:

rtc_clock is only used by the RTC emulator (mc146818rtc.c), however Xen
has its own RTC emulator in the hypervisor so we can disable it.

Signed-off-by: Stefano Stabellini
---
  xen-all.c |1 +
  1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/xen-all.c b/xen-all.c
index d1fc597..bf183f7 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -513,6 +513,7 @@ void xen_vcpu_init(void)
  qemu_register_reset(xen_reset_vcpu, first_cpu);
  xen_reset_vcpu(first_cpu);
  }
+qemu_clock_enable(rtc_clock, false);
  }

  /* get the ioreq packets from share mem */


I explained why this is wrong.

Paolo

Re: [Qemu-devel] [PATCH v3 1/9] fdc: take side count into account

[Hervé Poussineau]

Markus Armbruster a écrit :

Hervé Poussineau  writes:


Floppies can be simple or double-sided. However, current code
was only taking the common case into account (ie 2 sides).


Impact?


This repairs single-sided floppies


Are single sided floppies broken before the patch? How?


Yes. For head > 0, wrong sector number is calculated, so data is 
read/written at wrong place on underlying block device.


Fortunately, mostly nobody is still using single-sided floppies (only 
some 360 kB floppies are single-sided), so bug has been neglected since 
a long time.


Hervé

Re: [Qemu-devel] [PATCH V7] Guest stop notification

[Eric B Munson]

On Tue, 17 Jan 2012, Eric B Munson wrote:

> Often when a guest is stopped from the qemu console, it will report spurious
> soft lockup warnings on resume.  There are kernel patches being discussed that
> will give the host the ability to tell the guest that it is being stopped and
> should ignore the soft lockup warning that generates.  This patch uses the 
> qemu
> Notifier system to tell the guest it is about to be stopped.
> 
> Signed-off-by: Eric B Munson 

Just poking to make sure this doesn't fall through the cracks.

Eric


signature.asc
Description: Digital signature

Re: [Qemu-devel] [PATCH V7] Guest stop notification

[Anthony Liguori]

On 01/17/2012 12:27 PM, Eric B Munson wrote:

Often when a guest is stopped from the qemu console, it will report spurious
soft lockup warnings on resume.  There are kernel patches being discussed that
will give the host the ability to tell the guest that it is being stopped and
should ignore the soft lockup warning that generates.  This patch uses the qemu
Notifier system to tell the guest it is about to be stopped.

Signed-off-by: Eric B Munson

Cc: Avi Kivity
Cc: Marcelo Tosatti
Cc: Jan Kiszka
Cc: ry...@linux.vnet.ibm.com
Cc: aligu...@us.ibm.com
Cc: k...@vger.kernel.org
---
Changes from V6:
  Remove unnecessary include

Changes from V5:
  KVM_GUEST_PAUSED is now a per vm ioctl instead of per vcpu

Changes from V4:
  Test if the guest paused capability is available before use

Changes from V3:
  Collapse new state change notification function into existsing function.
  Correct whitespace issues
  Change ioctl name to KVMCLOCK_GUEST_PAUSED
  Use for loop to iterate vpcu's

Changes from V2:
  Move ioctl into hw/kvmclock.c so as other arches can use it as it is
implemented

Changes from V1:
  Remove unnecessary encapsulating function

  hw/kvmclock.c |   11 +++
  1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/hw/kvmclock.c b/hw/kvmclock.c
index 3b9fb20..ad79f52 100644
--- a/hw/kvmclock.c
+++ b/hw/kvmclock.c
@@ -64,10 +64,21 @@ static int kvmclock_post_load(void *opaque, int version_id)
  static void kvmclock_vm_state_change(void *opaque, int running,
   RunState state)
  {
+int ret;
  KVMClockState *s = opaque;
+int cap_guest_paused = kvm_check_extension(kvm_state, 
KVM_CAP_GUEST_PAUSED);

  if (running) {
  s->clock_valid = false;
+
+if (!cap_guest_paused) {
+return;
+}
+
+ret = kvm_vm_ioctl(kvm_state, KVMCLOCK_GUEST_PAUSED, 0);
+if (ret) {
+fprintf(stderr, "kvmclock_vm_state_change: %s\n", strerror(-ret));
+}
  }
  }



This change looks harmless enough.  What's the state of the kernel bits?  I 
would expect this through uq/master.


Regards,

Anthony Liguori

[Qemu-devel] [PATCH v2] macio: Improve shallow, half-hearted qdev'ification

[Andreas Färber]

From: Anthony Liguori 

Split macio into two PCIDevices with declarative device ID,
macio-oldworld and macio-newworld. Drop is_oldworld state in favor
of two separate init functions and deferred creation.

Signed-off-by: Andreas Färber 
Cc: Alexander Graf 
---
 v1 -> v2:
 * Patch was ignored for QOM second series: Rebase onto Anthony's older version.

 hw/macio.c|  106 +++--
 hw/ppc_mac.h  |8 ++--
 hw/ppc_newworld.c |2 +-
 hw/ppc_oldworld.c |2 +-
 4 files changed, 76 insertions(+), 42 deletions(-)

diff --git a/hw/macio.c b/hw/macio.c
index ae9db08..8e2a1f8 100644
--- a/hw/macio.c
+++ b/hw/macio.c
@@ -27,10 +27,8 @@
 #include "pci.h"
 #include "escc.h"
 
-typedef struct MacIOState
-{
+typedef struct MacIOState {
 PCIDevice parent;
-int is_oldworld;
 MemoryRegion bar;
 MemoryRegion *pic_mem;
 MemoryRegion *dbdma_mem;
@@ -47,15 +45,6 @@ static void macio_bar_setup(MacIOState *macio_state)
 MemoryRegion *bar = &macio_state->bar;
 
 memory_region_init(bar, "macio", 0x8);
-if (macio_state->pic_mem) {
-if (macio_state->is_oldworld) {
-/* Heathrow PIC */
-memory_region_add_subregion(bar, 0x0, macio_state->pic_mem);
-} else {
-/* OpenPIC */
-memory_region_add_subregion(bar, 0x4, macio_state->pic_mem);
-}
-}
 if (macio_state->dbdma_mem) {
 memory_region_add_subregion(bar, 0x08000, macio_state->dbdma_mem);
 }
@@ -71,52 +60,92 @@ static void macio_bar_setup(MacIOState *macio_state)
 macio_state->ide_mem[i]);
 }
 }
-if (macio_state->nvram != NULL)
+if (macio_state->nvram != NULL) {
 macio_nvram_setup_bar(macio_state->nvram, bar, 0x6);
+}
+}
+
+static void macio_common_init(MacIOState *macio_state)
+{
+PCIDevice *d = &macio_state->parent;
+
+d->config[PCI_INTERRUPT_PIN] = 0x01; /* interrupt on pin 1 */
+
+macio_bar_setup(macio_state);
+pci_register_bar(d, 0, PCI_BASE_ADDRESS_SPACE_MEMORY, &macio_state->bar);
+}
+
+static int macio_oldworld_initfn(PCIDevice *d)
+{
+MacIOState *s = DO_UPCAST(MacIOState, parent, d);
+
+macio_common_init(s);
+
+if (s->pic_mem != NULL) {
+/* Heathrow PIC */
+memory_region_add_subregion(&s->bar, 0x0, s->pic_mem);
+}
+return 0;
 }
 
-static int macio_initfn(PCIDevice *d)
+static int macio_newworld_initfn(PCIDevice *d)
 {
-d->config[0x3d] = 0x01; // interrupt on pin 1
+MacIOState *s = DO_UPCAST(MacIOState, parent, d);
+
+macio_common_init(s);
+
+if (s->pic_mem != NULL) {
+/* OpenPIC */
+memory_region_add_subregion(&s->bar, 0x4, s->pic_mem);
+}
 return 0;
 }
 
-static void macio_class_init(ObjectClass *klass, void *data)
+static void macio_oldworld_class_init(ObjectClass *klass, void *data)
 {
 PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
 
-k->init = macio_initfn;
+k->init = macio_oldworld_initfn;
 k->vendor_id = PCI_VENDOR_ID_APPLE;
+k->device_id = PCI_DEVICE_ID_APPLE_343S1201;
 k->class_id = PCI_CLASS_OTHERS << 8;
 }
 
-static DeviceInfo macio_info = {
-.name = "macio",
-.size = sizeof(MacIOState),
-.class_init = macio_class_init,
-};
-
-static void macio_register(void)
+static void macio_newworld_class_init(ObjectClass *klass, void *data)
 {
-pci_qdev_register(&macio_info);
+PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+k->init = macio_newworld_initfn;
+k->vendor_id = PCI_VENDOR_ID_APPLE;
+k->device_id = PCI_DEVICE_ID_APPLE_UNI_N_KEYL;
+k->class_id = PCI_CLASS_OTHERS << 8;
 }
 
-device_init(macio_register);
+static DeviceInfo macio_oldworld_info = {
+.name = "macio-oldworld",
+.size = sizeof(MacIOState),
+.class_init = macio_oldworld_class_init,
+};
+
+static DeviceInfo macio_newworld_info = {
+.name = "macio-newworld",
+.size = sizeof(MacIOState),
+.class_init = macio_newworld_class_init,
+};
 
-void macio_init (PCIBus *bus, int device_id, int is_oldworld,
- MemoryRegion *pic_mem, MemoryRegion *dbdma_mem,
- MemoryRegion *cuda_mem, void *nvram,
- int nb_ide, MemoryRegion **ide_mem,
- MemoryRegion *escc_mem)
+void macio_init(PCIBus *bus, bool is_oldworld,
+MemoryRegion *pic_mem, MemoryRegion *dbdma_mem,
+MemoryRegion *cuda_mem, void *nvram,
+int nb_ide, MemoryRegion **ide_mem,
+MemoryRegion *escc_mem)
 {
 PCIDevice *d;
 MacIOState *macio_state;
 int i;
 
-d = pci_create_simple(bus, -1, "macio");
+d = pci_create(bus, -1, is_oldworld ? "macio-oldworld" : "macio-newworld");
 
 macio_state = DO_UPCAST(MacIOState, parent, d);
-macio_state->is_oldworld = is_oldworld;
 macio_state->pic_mem = pic_mem;
 macio_state->dbdma_mem = dbdma_mem;
 macio_state->cuda_mem = cuda_mem;
@

[Qemu-devel] suspend/resume not working on tip due to 59abb06

[Stefan Berger]

After bisecting the following commit seems to be the culprit for the 
suspend/resume problems that I am seeing with the current tip 
(73093354418602a2ff5e43cb91a21b17fbf047d8).


commit 59abb06198ee9471e29c970f294eae80c0b39be1
Author: Blue Swirl 
Date:   Sun Jan 22 11:00:44 2012 +

Once I revert this patch on the tip everything works fine again...

   Stefan

Re: [Qemu-devel] suspend/resume not working on tip due to 59abb06

[Stefan Berger]

On 01/27/2012 04:10 PM, Stefan Berger wrote:
After bisecting the following commit seems to be the culprit for the 
suspend/resume problems that I am seeing with the current tip 
(73093354418602a2ff5e43cb91a21b17fbf047d8).


commit 59abb06198ee9471e29c970f294eae80c0b39be1
Author: Blue Swirl 
Date:   Sun Jan 22 11:00:44 2012 +

Once I revert this patch on the tip everything works fine again...

   Stefan



And this patch here gets it to work:

diff --git a/exec-obsolete.h b/exec-obsolete.h
index 03cf35e..a673386 100644
--- a/exec-obsolete.h
+++ b/exec-obsolete.h
@@ -101,7 +101,7 @@ static inline void 
cpu_physical_memory_mask_dirty_range(ram_

 end = start + length;
 mask = ~dirty_flags;
 p = ram_list.phys_dirty + (start >> TARGET_PAGE_BITS);
-for (addr = start; addr <= end; addr += TARGET_PAGE_SIZE) {
+for (addr = start; addr < end; addr += TARGET_PAGE_SIZE) {
 *p++ &= mask;
 }
 }

Re: [Qemu-devel] [PATCH] Init win32 CRITICAL_SECTION before starting thread; crash when attaching disks

[Stefan Weil]

Am 29.12.2011 18:29, schrieb Bogdan Harjoc:
Git commit 8d3bc51 crashes on win32 on startup because 
qemu_tcg_init_vcpu calls:


qemu_thread_create(th, qemu_tcg_cpu_thread_fn, ...
...
qemu_thread_get_handle(th)

which locks th->data->cs, a CRITICAL_SECTION which is initialized only 
in the thread_fn, so it finds garbage.


Attached patch initializes it before calling _beginthreadex. 
GDB/windbg probably start newly created threads sooner, because this 
doesn't happen under a debugger.


With the patch below it boots until it crashes somewhere while 
attaching disks (-hda raw_img).


"bt" in gdb only returns "#0  0x in ??" and generate-core-file 
didn't work.


Cheers,

diff -du qemu-8d3bc51\qemu-thread-win32.c 
qemu-8d3bc51-new\qemu-thread-win32.c

--- qemu-8d3bc51\qemu-thread-win32.cTue Dec 27 17:28:58 2011
+++ qemu-8d3bc51-new\qemu-thread-win32.cThu Dec 29 18:59:50 2011
@@ -215,8 +215,6 @@
 if (data->mode == QEMU_THREAD_DETACHED) {
 g_free(data);
 data = NULL;
-} else {
-InitializeCriticalSection(&data->cs);
 }
 TlsSetValue(qemu_thread_tls_index, data);
 qemu_thread_exit(start_routine(thread_arg));
@@ -287,6 +285,10 @@
 data->arg = arg;
 data->mode = mode;
 data->exited = false;
+
+if (data->mode != QEMU_THREAD_DETACHED) {
+InitializeCriticalSection(&data->cs);
+}

 hThread = (HANDLE) _beginthreadex(NULL, 0, win32_start_routine,
   data, 0, &thread->tid);




Tested-by: Stefan Weil 


Hi Bogdan,

I can confirm that your patch fixes a crash which otherwise makes
QEMU unusable on Windows hosts.

Could you please sign your patch with a Signed-off-by line including
your name and e-mail address (similar to my Tested-by above)?
We need this before we can commit your patch to QEMU master.

See http://wiki.qemu.org/Contribute/SubmitAPatch for more information.

Please contact me if you need more information.

Regards,

Stefan

Re: [Qemu-devel] Merging kvm-apic into qemu-kvm

[Jan Kiszka]

On 2012-01-26 16:49, Avi Kivity wrote:
> On 01/26/2012 05:45 PM, Jan Kiszka wrote:
>>>
 I merged the upstream patches one by one, resolving the mechanical and
 logical conflicts in each step. Was done for that backend/frontend
 concept, but the adjustments should basically be the same now. Want me
 to prepare a branch or will you do this?
>>>
>>> It's much more likely that you'll get it right - I started to do this
>>> but backed out.
>>>
>>> btw, the branch doesn't appear to be merges, so I'll still have huge
>>> conflicts at the end.  If you do this with real merges, git will
>>> recognize it and just adopt your version.
>>
>> I will try to use your concept: pull in upstream commits into a merge
>> branch as long as there is a mechanical or logical conflict. 
> 
> That's what I do in my upstream merges.  I use bisect to find the first
> conflict, but in this case I imagine there will be a conflict in every
> merge except the memory.c one.
> 
>> Will then
>> publish the branch for pulling. Can I start at the current 'next' head?
> 
> Yes please.  It's halfway through autotest and looks good.  Even if I
> have to change it, we can 'git rebase -p --onto' your branch (though I
> doubt it will be necessary).

Done, see

git://git.kiszka.org/qemu-kvm.git queues/qemu-merge

Only moderately tested so far, I'm counting on your machinery.

Jan



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH V7] Guest stop notification

[Jan Kiszka]

On 2012-01-27 21:48, Anthony Liguori wrote:
> On 01/17/2012 12:27 PM, Eric B Munson wrote:
>> Often when a guest is stopped from the qemu console, it will report
>> spurious
>> soft lockup warnings on resume.  There are kernel patches being
>> discussed that
>> will give the host the ability to tell the guest that it is being
>> stopped and
>> should ignore the soft lockup warning that generates.  This patch uses
>> the qemu
>> Notifier system to tell the guest it is about to be stopped.
>>
>> Signed-off-by: Eric B Munson
>>
>> Cc: Avi Kivity
>> Cc: Marcelo Tosatti
>> Cc: Jan Kiszka
>> Cc: ry...@linux.vnet.ibm.com
>> Cc: aligu...@us.ibm.com
>> Cc: k...@vger.kernel.org
>> ---
>> Changes from V6:
>>   Remove unnecessary include
>>
>> Changes from V5:
>>   KVM_GUEST_PAUSED is now a per vm ioctl instead of per vcpu
>>
>> Changes from V4:
>>   Test if the guest paused capability is available before use
>>
>> Changes from V3:
>>   Collapse new state change notification function into existsing
>> function.
>>   Correct whitespace issues
>>   Change ioctl name to KVMCLOCK_GUEST_PAUSED
>>   Use for loop to iterate vpcu's
>>
>> Changes from V2:
>>   Move ioctl into hw/kvmclock.c so as other arches can use it as it is
>> implemented
>>
>> Changes from V1:
>>   Remove unnecessary encapsulating function
>>
>>   hw/kvmclock.c |   11 +++
>>   1 files changed, 11 insertions(+), 0 deletions(-)
>>
>> diff --git a/hw/kvmclock.c b/hw/kvmclock.c
>> index 3b9fb20..ad79f52 100644
>> --- a/hw/kvmclock.c
>> +++ b/hw/kvmclock.c
>> @@ -64,10 +64,21 @@ static int kvmclock_post_load(void *opaque, int
>> version_id)
>>   static void kvmclock_vm_state_change(void *opaque, int running,
>>RunState state)
>>   {
>> +int ret;
>>   KVMClockState *s = opaque;
>> +int cap_guest_paused = kvm_check_extension(kvm_state,
>> KVM_CAP_GUEST_PAUSED);
>>
>>   if (running) {
>>   s->clock_valid = false;
>> +
>> +if (!cap_guest_paused) {
>> +return;
>> +}
>> +
>> +ret = kvm_vm_ioctl(kvm_state, KVMCLOCK_GUEST_PAUSED, 0);
>> +if (ret) {
>> +fprintf(stderr, "kvmclock_vm_state_change: %s\n",
>> strerror(-ret));
>> +}
>>   }
>>   }
> 
> 
> This change looks harmless enough.

Yep, but needs to be redirected after the file renaming in upstream.

>  What's the state of the kernel
> bits?  I would expect this through uq/master.

Kernel bits aren't merged yet. And the kernel headers will have to be
updated in a previous step.

BTW, this series [1] would be nice to have. Dunno if there is a pull
planned, but anyone trying to extend the KVM interface current runs
against this.

Jan

[1] http://thread.gmane.org/gmane.comp.emulators.qemu/132962



signature.asc
Description: OpenPGP digital signature

[Qemu-devel] [PATCH] arm: add device tree support

[Grant Likely]

If compiled with CONFIG_FDT, allow user to specify a device tree file using
the -dtb argument.  If the machine supports it then the dtb will be loaded
into memory and passed to the kernel on boot.

This version of the patch only adds support to the arm versatile and versatile
express platforms.  Other platforms can easily be added.

Signed-off-by: Jeremy Kerr 
[grant.likely: Changed from platform specifying dtb to user option]
[grant.likely: Squashed in initrd and memory property manipulation patches]
Signed-off-by: Grant Likely 
Cc: Paul Brook 
Cc: Peter Maydell 
Cc: Rob Herring 
Cc: Edgar E. Iglesias 
---
I've been working with this patch for quite a while now.  It works well for
me.  It should be easy to extend to add support for other architectures too.

Note: I've done something ugly here for passing the dtb filename into the
machine->init() function by using a global variable.  I did it this way to
avoid changing the ->init() function prototype which would mean a lot of
functions need to be changed, but I'm not happy with it.

Alternately, I could change the prototype to accept an arguments structure
which can easily be extended in the future to support more machine arguments
without requires every machine to be changed.

g.

 Makefile.target  |1 +
 configure|3 ++
 hw/arm-misc.h|1 +
 hw/arm_boot.c|   95 -
 hw/boards.h  |1 +
 hw/versatilepb.c |   20 +++
 hw/vexpress.c|1 +
 qemu-options.hx  |9 +
 vl.c |   11 ++
 9 files changed, 133 insertions(+), 9 deletions(-)

diff --git a/Makefile.target b/Makefile.target
index 68481a3..5e465ec 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -363,6 +363,7 @@ obj-arm-y += vexpress.o
 obj-arm-y += strongarm.o
 obj-arm-y += collie.o
 obj-arm-y += pl041.o lm4549.o
+obj-arm-$(CONFIG_FDT) += device_tree.o
 
 obj-sh4-y = shix.o r2d.o sh7750.o sh7750_regnames.o tc58128.o
 obj-sh4-y += sh_timer.o sh_serial.o sh_intc.o sh_pci.o sm501.o
diff --git a/configure b/configure
index f69e08f..0c2deab 100755
--- a/configure
+++ b/configure
@@ -3411,6 +3411,9 @@ case "$target_arch2" in
 gdb_xml_files="arm-core.xml arm-vfp.xml arm-vfp3.xml arm-neon.xml"
 target_phys_bits=32
 target_llong_alignment=4
+if test "$fdt" = "yes" ; then
+  target_libs_softmmu="$fdt_libs"
+fi
   ;;
   cris)
 target_nptl="yes"
diff --git a/hw/arm-misc.h b/hw/arm-misc.h
index 5e5204b..4b55fb8 100644
--- a/hw/arm-misc.h
+++ b/hw/arm-misc.h
@@ -29,6 +29,7 @@ struct arm_boot_info {
 const char *kernel_filename;
 const char *kernel_cmdline;
 const char *initrd_filename;
+const char *dtb_filename;
 target_phys_addr_t loader_start;
 /* multicore boards that use the default secondary core boot functions
  * need to put the address of the secondary boot code, the boot reg,
diff --git a/hw/arm_boot.c b/hw/arm_boot.c
index 5f163fd..93edeb1 100644
--- a/hw/arm_boot.c
+++ b/hw/arm_boot.c
@@ -7,11 +7,13 @@
  * This code is licensed under the GPL.
  */
 
+#include "config.h"
 #include "hw.h"
 #include "arm-misc.h"
 #include "sysemu.h"
 #include "loader.h"
 #include "elf.h"
+#include "device_tree.h"
 
 #define KERNEL_ARGS_ADDR 0x100
 #define KERNEL_LOAD_ADDR 0x0001
@@ -207,6 +209,66 @@ static void set_kernel_args_old(const struct arm_boot_info 
*info,
 }
 }
 
+static int load_dtb(target_phys_addr_t addr, const struct arm_boot_info *binfo)
+{
+#ifdef CONFIG_FDT
+uint32_t mem_reg_property[] = { cpu_to_be32(binfo->loader_start),
+cpu_to_be32(binfo->ram_size) };
+void *fdt = NULL;
+char *filename;
+int size, rc;
+
+if (!binfo->dtb_filename)
+return 0;
+
+filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, binfo->dtb_filename);
+if (!filename) {
+fprintf(stderr, "Couldn't open dtb file %s\n", binfo->dtb_filename);
+return -1;
+}
+
+fdt = load_device_tree(filename, &size);
+if (!fdt) {
+fprintf(stderr, "Couldn't open dtb file %s\n", filename);
+g_free(filename);
+return -1;
+}
+g_free(filename);
+
+rc = qemu_devtree_setprop(fdt, "/memory", "reg", mem_reg_property,
+   sizeof(mem_reg_property));
+if (rc < 0)
+fprintf(stderr, "couldn't set /memory/reg\n");
+
+rc = qemu_devtree_setprop_string(fdt, "/chosen", "bootargs",
+  binfo->kernel_cmdline);
+if (rc < 0)
+fprintf(stderr, "couldn't set /chosen/bootargs\n");
+
+if (binfo->initrd_size) {
+rc = qemu_devtree_setprop_cell(fdt, "/chosen", "linux,initrd-start",
+binfo->loader_start + INITRD_LOAD_ADDR);
+if (rc < 0)
+fprintf(stderr, "couldn't set /chosen/linux,initrd-start\n");
+
+rc = qemu_devtree_setprop_cell(fdt, "/chosen", "linux,initrd-end",
+binfo->loader_start +INITRD_LOAD_ADDR +
+  

Re: [Qemu-devel] [PATCH] arm: add device tree support

[Paul Brook]

> If compiled with CONFIG_FDT, allow user to specify a device tree file using
> the -dtb argument.  If the machine supports it then the dtb will be loaded
> into memory and passed to the kernel on boot.

Adding annother machine feels wrong. Why does the board specific code need to 
know about this at all? You already going it via a global variable, so can't 
this be entirely contained within arm_boot.c?  If the board file is involved, 
why is it asking the user?

> +versatile_init(ram_size,
> +   boot_device,
> +   kernel_filename, kernel_cmdline,
> +   initrd_filename, cpu_model, 0x);

This only works because we're currently too dumb to emulate the differences 
between the two board variants.


What we probably want to be doing is shipping/constructing device trees for 
the boards we implement, with an option to turn this on/off.  Requiring a user 
to invent their own seems deeply sub-optimal given we know exactly what 
hardware we're emulating.  A user that needs to provide their own FDT seems 
like a fairly rare corner case.

This gets slightly more interesting when you have custom machine variants 
(i.e. once we fix the object model, and have proper dynamic machine 
construction).  Even then I'd expect the FDT to be derived from/specificed by 
the machine description, not a separate option.

Paul

[Qemu-devel] [PATCH] sdl: Do not grab mouse on mode switch while in background

[Jan Kiszka]

From: Jan Kiszka 

When the mouse mode changes to absolute while the SDL windows is not in
focus, refrain from grabbing the input. It would steal from some other
window.

Signed-off-by: Jan Kiszka 
---

I bet this makes no difference for your problem, Erik, but I came
across this while trying to reproduce the issue.

 ui/sdl.c |   30 --
 1 files changed, 16 insertions(+), 14 deletions(-)

diff --git a/ui/sdl.c b/ui/sdl.c
index 8cafc44..384276d 100644
--- a/ui/sdl.c
+++ b/ui/sdl.c
@@ -483,12 +483,27 @@ static void sdl_grab_end(void)
 sdl_update_caption();
 }
 
+static void absolute_mouse_grab(void)
+{
+int mouse_x, mouse_y;
+
+if (SDL_GetAppState() & SDL_APPINPUTFOCUS) {
+SDL_GetMouseState(&mouse_x, &mouse_y);
+if (mouse_x > 0 && mouse_x < real_screen->w - 1 &&
+mouse_y > 0 && mouse_y < real_screen->h - 1) {
+sdl_grab_start();
+}
+}
+}
+
 static void sdl_mouse_mode_change(Notifier *notify, void *data)
 {
 if (kbd_mouse_is_absolute()) {
 if (!absolute_enabled) {
-sdl_grab_start();
 absolute_enabled = 1;
+if (is_graphic_console()) {
+absolute_mouse_grab();
+}
 }
 } else if (absolute_enabled) {
 if (!gui_fullscreen) {
@@ -571,19 +586,6 @@ static void toggle_full_screen(DisplayState *ds)
 vga_hw_update();
 }
 
-static void absolute_mouse_grab(void)
-{
-int mouse_x, mouse_y;
-
-if (SDL_GetAppState() & SDL_APPINPUTFOCUS) {
-SDL_GetMouseState(&mouse_x, &mouse_y);
-if (mouse_x > 0 && mouse_x < real_screen->w - 1 &&
-mouse_y > 0 && mouse_y < real_screen->h - 1) {
-sdl_grab_start();
-}
-}
-}
-
 static void handle_keydown(DisplayState *ds, SDL_Event *ev)
 {
 int mod_state;
-- 
1.7.3.4