Re: [Qemu-devel] [RFC][PATCH 0/21] QEMU Object Model

2011-07-29 Thread Paolo Bonzini

On 07/28/2011 07:59 PM, Anthony Liguori wrote:

Just define an interface that returns a struct then.  It's no more
complicated than that.


Ok, so we're debating whether to: 1) add an interface returning a 
pointer to an internal struct; 2) include in the internal struct a 
pointer-to-function that does a container_of and returns the outer 
Device object.  Otherwise, we're on the same page.  I'm quite relieved. ;)


I can see advantages to both approach.  The main advantage to (2) is 
that it scales better when you have multiple interfaces of the same kind 
exposed by the device.  You cannot implement an interface twice.


Paolo



[Qemu-devel] Odd code in cpus.c

2011-07-29 Thread Frediano Ziglio
I  don't know that much this code however qemu_kvm_init_cpu_signals
seems a bit strange and duplicate to me, in cpus.c


static void qemu_kvm_init_cpu_signals(CPUState *env)
{
int r;
sigset_t set;
struct sigaction sigact;

memset(&sigact, 0, sizeof(sigact));
sigact.sa_handler = dummy_signal;
sigaction(SIG_IPI, &sigact, NULL);

#ifdef CONFIG_IOTHREAD
pthread_sigmask(SIG_BLOCK, NULL, &set);
sigdelset(&set, SIG_IPI);
sigdelset(&set, SIGBUS);
r = kvm_set_signal_mask(env, &set);
if (r) {
fprintf(stderr, "kvm_set_signal_mask: %s\n", strerror(-r));
exit(1);
}
#else
sigemptyset(&set);
sigaddset(&set, SIG_IPI);
sigaddset(&set, SIGIO);
sigaddset(&set, SIGALRM);
pthread_sigmask(SIG_BLOCK, &set, NULL);

pthread_sigmask(SIG_BLOCK, NULL, &set);
sigdelset(&set, SIGIO);
sigdelset(&set, SIGALRM);
#endif
sigdelset(&set, SIG_IPI);
sigdelset(&set, SIGBUS);
r = kvm_set_signal_mask(env, &set);
if (r) {
fprintf(stderr, "kvm_set_signal_mask: %s\n", strerror(-r));
exit(1);
}
}


if CONFIG_IOTHREAD is set you get


static void qemu_kvm_init_cpu_signals(CPUState *env)
{
int r;
sigset_t set;
struct sigaction sigact;

memset(&sigact, 0, sizeof(sigact));
sigact.sa_handler = dummy_signal;
sigaction(SIG_IPI, &sigact, NULL);

pthread_sigmask(SIG_BLOCK, NULL, &set);
sigdelset(&set, SIG_IPI);
sigdelset(&set, SIGBUS);
r = kvm_set_signal_mask(env, &set);
if (r) {
fprintf(stderr, "kvm_set_signal_mask: %s\n", strerror(-r));
exit(1);
}
sigdelset(&set, SIG_IPI);
sigdelset(&set, SIGBUS);
r = kvm_set_signal_mask(env, &set);
if (r) {
fprintf(stderr, "kvm_set_signal_mask: %s\n", strerror(-r));
exit(1);
}
}


which seems to set kvm signal twice with same values (taking into
account that in kvm_set_signal_mask the set is copied before the call
to kvm_vcpu_ioctl).

Frediano



Re: [Qemu-devel] [PATCH 18/55] scsi-disk: Reject CD-specific SCSI commands to disks

2011-07-29 Thread Markus Armbruster
Markus Armbruster  writes:

> Christoph Hellwig  writes:
>
>> On Wed, Jul 20, 2011 at 06:23:52PM +0200, Markus Armbruster wrote:
>>> Use a table to declare which drive kinds accept each command.
>>> 
>>> Limit READ_CAPACITY, READ_TOC, GET_CONFIGURATION to SCSI_CD, as per
>>> SPC-4.
>>
>> READ CAPACITY is defined in SBC, and absolutely required for proper
>> operation with disks.
>
> Will fix.

Second thoughts: dropping this bug fix patch for now, because it clashes
with Hannes's work in progress[*], and the rest of my series doesn't
depend on it.

[*] [PATCH 6/6] scsi-disk: Check for supported commands
http://lists.gnu.org/archive/html/qemu-devel/2011-07/msg03082.html



Re: [Qemu-devel] Volume key in qcow3?

2011-07-29 Thread Frediano Ziglio
2011/7/28 Kevin Wolf :
> Am 28.07.2011 10:05, schrieb Frediano Ziglio:
>> Hi,
>>   I noted that AES encryption using qcow2 just use the password given
>> as as key (and also truncating it to 16 bytes == 128 bits).
>> This is prone to brute force attacks and is not also easy to change
>> password (you have to decrypt and encrypt again the entire image).
>> LUKS and EncFS use another way. They generate a random key (the
>> "volume key") then use the password you give to encrypt N times (where
>> N is decided by security level or automatically based on time to
>> decrypt the volume key. To change the password just give the old one,
>> get the volume key and encrypt again using the new one. LUKS support
>> also multiple "slots" to allow multiple password and even using an
>> external key file.
>> Obviously this require an additional extension to qcow2 so I think it
>> require a new qcow3 format.
>
> Yes, once we have qcow3, adding things like this should be easy enough.
> I think the idea makes sense.
>
> Another thing to consider with encryption is that we don't encrypt
> metadata currently. I'm not entirely sure if this is a good or a bad
> thing. Metadata is relatively predictable and I think that might hurt
> the encryption? Though I'm really not an expert in this area.
>
> Kevin
>

I don't think this is a big issue, usually sensitive data is not in
knowing which clusters are allocated or in which sequence (perhaps
looking at allocation strategy you can detect operating system and
filesystem type), snapshot ids and descriptions are IMO more sensible.

Do anybody though that qcow2 can support data-deduplication using
refcounts? Well, in this case this is not possible with encrypted
data.

Frediano



Re: [Qemu-devel] Odd code in cpus.c

2011-07-29 Thread Jan Kiszka
On 2011-07-29 10:34, Frediano Ziglio wrote:
> I  don't know that much this code however qemu_kvm_init_cpu_signals
> seems a bit strange and duplicate to me, in cpus.c
> 
> 
> static void qemu_kvm_init_cpu_signals(CPUState *env)
> {
> int r;
> sigset_t set;
> struct sigaction sigact;
> 
> memset(&sigact, 0, sizeof(sigact));
> sigact.sa_handler = dummy_signal;
> sigaction(SIG_IPI, &sigact, NULL);
> 
> #ifdef CONFIG_IOTHREAD
> pthread_sigmask(SIG_BLOCK, NULL, &set);
> sigdelset(&set, SIG_IPI);
> sigdelset(&set, SIGBUS);
> r = kvm_set_signal_mask(env, &set);
> if (r) {
> fprintf(stderr, "kvm_set_signal_mask: %s\n", strerror(-r));
> exit(1);
> }
> #else
> sigemptyset(&set);
> sigaddset(&set, SIG_IPI);
> sigaddset(&set, SIGIO);
> sigaddset(&set, SIGALRM);
> pthread_sigmask(SIG_BLOCK, &set, NULL);
> 
> pthread_sigmask(SIG_BLOCK, NULL, &set);
> sigdelset(&set, SIGIO);
> sigdelset(&set, SIGALRM);
> #endif
> sigdelset(&set, SIG_IPI);
> sigdelset(&set, SIGBUS);
> r = kvm_set_signal_mask(env, &set);
> if (r) {
> fprintf(stderr, "kvm_set_signal_mask: %s\n", strerror(-r));
> exit(1);
> }
> }
> 
> 
> if CONFIG_IOTHREAD is set you get
> 
> 
> static void qemu_kvm_init_cpu_signals(CPUState *env)
> {
> int r;
> sigset_t set;
> struct sigaction sigact;
> 
> memset(&sigact, 0, sizeof(sigact));
> sigact.sa_handler = dummy_signal;
> sigaction(SIG_IPI, &sigact, NULL);
> 
> pthread_sigmask(SIG_BLOCK, NULL, &set);
> sigdelset(&set, SIG_IPI);
> sigdelset(&set, SIGBUS);
> r = kvm_set_signal_mask(env, &set);
> if (r) {
> fprintf(stderr, "kvm_set_signal_mask: %s\n", strerror(-r));
> exit(1);
> }
> sigdelset(&set, SIG_IPI);
> sigdelset(&set, SIGBUS);
> r = kvm_set_signal_mask(env, &set);
> if (r) {
> fprintf(stderr, "kvm_set_signal_mask: %s\n", strerror(-r));
> exit(1);
> }
> }
> 
> 
> which seems to set kvm signal twice with same values (taking into
> account that in kvm_set_signal_mask the set is copied before the call
> to kvm_vcpu_ioctl).

Indeed. Harmless fortunately. I suspect the duplicate bits in the #ifdef
CONFIG_IOTHREAD block were simply forgotten. Paolo?

Jan

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



Re: [Qemu-devel] Odd code in cpus.c

2011-07-29 Thread Paolo Bonzini

On 07/29/2011 10:49 AM, Jan Kiszka wrote:

>
>  which seems to set kvm signal twice with same values (taking into
>  account that in kvm_set_signal_mask the set is copied before the call
>  to kvm_vcpu_ioctl).

Indeed. Harmless fortunately. I suspect the duplicate bits in the #ifdef
CONFIG_IOTHREAD block were simply forgotten. Paolo?


Yes, perhaps a rebase conflict was resolved erroneously.  Can probably 
get in via qemu-trivial.


Paolo



Re: [Qemu-devel] [PATCH 49/55] block: Declare qemu_blockalign() in block.h, not block_int.h

2011-07-29 Thread Markus Armbruster
Christoph Hellwig  writes:

> On Wed, Jul 20, 2011 at 06:24:23PM +0200, Markus Armbruster wrote:
>> Device models should be able to use it without an unclean include of
>> block_int.h.
>
> Hmm.  We already do proper read-modify-write cycles for actual data
> transfers, so killing the buffer inside SD sounds like the better
> idea.  qemu_blockalign really should be used only for block-layer internal
> allocations.

What about the uses in scsi-disk.c and ide/core.c?



Re: [Qemu-devel] Volume key in qcow3?

2011-07-29 Thread Kevin Wolf
Am 29.07.2011 10:47, schrieb Frediano Ziglio:
> 2011/7/28 Kevin Wolf :
>> Am 28.07.2011 10:05, schrieb Frediano Ziglio:
>>> Hi,
>>>   I noted that AES encryption using qcow2 just use the password given
>>> as as key (and also truncating it to 16 bytes == 128 bits).
>>> This is prone to brute force attacks and is not also easy to change
>>> password (you have to decrypt and encrypt again the entire image).
>>> LUKS and EncFS use another way. They generate a random key (the
>>> "volume key") then use the password you give to encrypt N times (where
>>> N is decided by security level or automatically based on time to
>>> decrypt the volume key. To change the password just give the old one,
>>> get the volume key and encrypt again using the new one. LUKS support
>>> also multiple "slots" to allow multiple password and even using an
>>> external key file.
>>> Obviously this require an additional extension to qcow2 so I think it
>>> require a new qcow3 format.
>>
>> Yes, once we have qcow3, adding things like this should be easy enough.
>> I think the idea makes sense.
>>
>> Another thing to consider with encryption is that we don't encrypt
>> metadata currently. I'm not entirely sure if this is a good or a bad
>> thing. Metadata is relatively predictable and I think that might hurt
>> the encryption? Though I'm really not an expert in this area.
>>
>> Kevin
>>
> 
> I don't think this is a big issue, usually sensitive data is not in
> knowing which clusters are allocated or in which sequence (perhaps
> looking at allocation strategy you can detect operating system and
> filesystem type), snapshot ids and descriptions are IMO more sensible.
> 
> Do anybody though that qcow2 can support data-deduplication using
> refcounts? Well, in this case this is not possible with encrypted
> data.

No, you can't have two clusters in the active L1 table that are mapped
to the same cluster in the image file. The reason for this is that you
can't update the QCOW_OFLAG_COPIED flag when doing COW (you would have
to scan all L2 tables, which just doesn't work performance-wise)

If we were to do this, we would have to have a flag that turns off the
usage of QCOW_OFLAG_COPIED (it is only a performance optimisation, so
doing this would be possible). Not sure if it's worth it.

Kevin



Re: [Qemu-devel] [PATCH 0/3] small trivial patches

2011-07-29 Thread Stefan Hajnoczi
On Wed, Jul 27, 2011 at 7:11 PM, Frediano Ziglio  wrote:
> Minor fixes and improves
>
> Frediano Ziglio (3):
>  block: removed unused function
>  block: typo fix
>  aio: always check paio_init result
>
>  block.c           |   13 -
>  block.h           |    2 --
>  block/raw-posix.c |   13 ++---
>  3 files changed, 6 insertions(+), 22 deletions(-)

Reviewed-by: Stefan Hajnoczi 

Please send block patches to Kevin even if they are trivial.  The
trivial-patches tree tries to stay out of the way of subsystems with
an active maintainer.

Stefan



Re: [Qemu-devel] [PATCH] [RFC] qcow2: group refcount updates during cow

2011-07-29 Thread Kevin Wolf
Am 28.07.2011 16:15, schrieb Kevin Wolf:
> Am 28.07.2011 15:50, schrieb Frediano Ziglio:
>> Well, I think this is the first real improve patch.
>> Is more a RFC than a patch. Yes, some lines are terrible!
>> It collapses refcount decrement during cow.
>> From a first check time executing 015 test passed from about 600 seconds
>> to 70.
>> This at least prove that refcount updates counts!
>> Some doubt:
>> 1- place the code in qcow2-refcount.c as it update only refcount and not
>>   cluster?
>> 2- allow some sort of "begin transaction" / "commit" / "rollback" like 
>>   databases instead?
>> 3- allow changing tables from different coroutines?
>>
>> 1) If you have a sequence like (1, 2, 4) probably these clusters are all in
>> the same l2 table but with this code you get two write instead of one.
>> I'm thinking about a function in qcow2-refcount.c that accept an array of 
>> cluster
>> instead of a start + len.
>>
>> Signed-off-by: Frediano Ziglio 
> 
> I think what you're seeing is actually just one special case of a more
> general problem. The problem is that we're interpreting writethrough
> stricter than required.
> 
> The semantics that we really need is that on completion of a request,
> all of its data and metadata must be flushed to disk. There is no
> requirement that we flush all intermediate states.
> 
> My recent update to qcow2_update_snapshot_refcount() is just another
> case of the same problem. I think the solution should be similar to what
> I did there, i.e. switch the cache to writeback mode while we're
> operating on it and switch back when we're done. We should probably have
> functions that make both of this a one-liner (I think here we have some
> similarity to your begin/commit idea).
> 
> With the right functions, this could become as easy as this (might need
> better function names, but you get the idea):
> 
> diff --git a/block/qcow2-cluster.c b/block/qcow2-cluster.c
> index 882f50a..45b67b1 100644
> --- a/block/qcow2-cluster.c
> +++ b/block/qcow2-cluster.c
> @@ -612,6 +612,8 @@ int qcow2_alloc_cluster_link_l2(BlockDriverState
> *bs, QCowL2Meta *m)
>  if (m->nb_clusters == 0)
>  return 0;
> 
> +qcow2_cache_disable_writethrough(bs);
> +
>  old_cluster = qemu_malloc(m->nb_clusters * sizeof(uint64_t));
> 
>  /* copy content of unmodified sectors */
> @@ -683,6 +685,7 @@ int qcow2_alloc_cluster_link_l2(BlockDriverState
> *bs, QCowL2Meta *m)
> 
>  ret = 0;
>  err:
> +qcow2_cache_restore_writethrough(bs);
>  qemu_free(old_cluster);
>  return ret;
>   }

Maybe that's a bit too easy for a solution. With coroutines this
requires running under a CoMutex in order to avoid influencing other
requests and possibly missing a cache flush. This is contrary to our
goal of running requests in parallel, so maybe some more changes to how
the cache handles cache=writethrough are required.

Kevin



Re: [Qemu-devel] [PATCH 2/2] Makefile: delete config.log in distclean

2011-07-29 Thread Stefan Hajnoczi
On Mon, Jul 25, 2011 at 11:56:02PM -0400, Alexandre Raymond wrote:
> Distclean should remove anything created by the configure script.
> 
> Signed-off-by: Alexandre Raymond 
> ---
>  Makefile |1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)

Thanks, applied to the trivial patches tree:
http://repo.or.cz/w/qemu/stefanha.git/shortlog/refs/heads/trivial-patches-next

Stefan



[Qemu-devel] [Bug 802588] Re: Latest GIT version fails to compile on Linux - setjmp.h problem

2011-07-29 Thread Yongjie Ren
this issue got fixed. It doesn't exist in qemu-kvm.git
fda19064e889d4419dd3dc69ca8e6e7a1535fdf5

** Changed in: qemu
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/802588

Title:
  Latest GIT version fails to compile on Linux - setjmp.h problem

Status in QEMU:
  Fix Released

Bug description:
  Git version: f26e428da505709ec03b2ed2c9eb3db82b30bd7b
  Gcc: 4.6.1
  Host: Debinan/x86_64

  Fails to compile at

  In file included from /usr/include/png.h:518:0,
   from ui/vnc-enc-tight.c:37:
  /usr/include/pngconf.h: At top level:
  /usr/include/pngconf.h:371:21: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or 
‘__attribute__’ before ‘.’ token
  /usr/include/pngconf.h:372:12: error: unknown type name ‘__dont__’
  /usr/include/pngconf.h:372:29: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or 
‘__attribute__’ before ‘it’
  /usr/include/pngconf.h:372:29: error: unknown type name ‘it’

  
  Looking at pngconf.h around line 370 gives the reason for the compilation 
failure:

  #  ifdef _SETJMP_H
 /* If you encounter a compiler error here, see the explanation
  * near the end of INSTALL.
  */
 __pngconf.h__ in libpng already includes setjmp.h;
 __dont__ include it again.;
  #  endif

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/802588/+subscriptions



Re: [Qemu-devel] [Qemu-trivial] [PATCH 1/2] Makefile: distclean should clean all possible targets

2011-07-29 Thread Paolo Bonzini

On 07/27/2011 04:42 PM, Michael Roth wrote:

"Delete all files in the current directory (or created by this
makefile) that are created by configuring or building the program. If
you have unpacked the source and built the program without creating
any other files, ‘make distclean’ should leave only the files that
were in the distribution. However, there is no need to delete parent
directories that were created with ‘mkdir -p’, since they could have
existed anyway. "

Now, if everyone agrees that "distclean" is fine as it is, I won't
insist on anything.


I'm with you in that distclean to me reads as "make clean for
re-distribution". i.e. a pristine source tree.


It should be like that _as long as you rerun make distclean before every 
reconfiguration_.


Paolo



Re: [Qemu-devel] Block layer roadmap

2011-07-29 Thread Stefan Hajnoczi
Frediano suggested:

Enhanced volume key in qcow3
 * luks-like key scheme that allows changing passphrase without
re-encrypting image data



Re: [Qemu-devel] [PATCH -V2] coroutine: Add CoRwlock support

2011-07-29 Thread Kevin Wolf
Am 27.07.2011 18:21, schrieb Aneesh Kumar K.V:
> Signed-off-by: Aneesh Kumar K.V 
> ---
>  qemu-coroutine-lock.c |   44 
>  qemu-coroutine.h  |   12 
>  2 files changed, 56 insertions(+), 0 deletions(-)

Looks good to me.

What's your plan with getting this merged? Are you going to just include
it with another series that you'll send once the basic coroutine support
is in?

Kevin



Re: [Qemu-devel] Bug#632192: [PATCH] add QEMU_LD_PREFIX environment variable

2011-07-29 Thread Vagrant Cascadian
On Thu, Jul 28, 2011 at 11:41:09AM +0300, Riku Voipio wrote:
> On Sat, Jul 23, 2011 at 07:47:49AM +0200, josch wrote:
> > This could be avoided by setting the proposed environment variable 
> > QEMU_LD_PREFIX to the just
> > created debian rootfs. As mentioned earlier, the usage of the -L option
> > is not possible in this scenario because qemu-user is only implicitly
> > called by the binfmt mechanism.
> 
> What worries me here is that we are beginning to add a enviroment variable
> for each and every command line option of qemu linux-user. I think it would
> be better to have a wrapper binary to be registered as the binfmt runner.

setting up a wrapper makes trivial cross-architecture chroots harder as you'll 
have to copy two binaries into the chroot, and i'm not sure if it would work at 
all, as the wrapper will need to somehow emulate it's own interpreter...


> Alternatively we should have a generic setup for mapping enviroment variables
> to command line options. Now we get special per-option code every time 
> someone 
> needs to setup a command line option from binfmt.

this would seem a bit better alternative to me...


live well,
  vagrant



Re: [Qemu-devel] [PATCH v8 0/5] Coroutines for better asynchronous programming

2011-07-29 Thread Stefan Hajnoczi
On Tue, Jul 26, 2011 at 10:21 AM, Stefan Hajnoczi
 wrote:
> QEMU is event-driven and suffers when blocking operations are performed 
> because
> VM execution may be stopped until the operation completes.  Therefore many
> operations that could block are performed asynchronously and a callback is
> invoked when the operation has completed.  This allows QEMU to continue
> executing while the operation is pending.
>
> The downside to callbacks is that they split up code into many smaller
> functions, each of which is a single step in a state machine that quickly
> becomes complex and hard to understand.  Callback functions also result in 
> lots
> of noise as variables are packed and unpacked into temporary structs that pass
> state to the callback function.
>
> This patch series introduces coroutines as a solution for writing asynchronous
> code while still having a nice sequential control flow.  The semantics are
> explained in the second patch.  The fourth patch adds automated tests.
>
> A nice feature of coroutines is that it is relatively easy to take synchronous
> code and lift it into a coroutine to make it asynchronous.  Work has been done
> to move qcow2 request processing into coroutines and thereby make it
> asynchronous (today qcow2 will perform synchronous metadata accesses).  This
> qcow2 work is still ongoing and not quite ready for mainline yet.
>
> v8:
>  * Bisectability: introduce gthread implementation before ucontext/fibers

Aneesh's code on top of this will go in separately.

We're good to go.

Stefan



Re: [Qemu-devel] [PATCH 2/2] pc: Support system flash memory with pflash

2011-07-29 Thread Anthony Liguori

On 07/25/2011 04:34 PM, Jordan Justen wrote:

If a pflash image is found, then it is used for the system
firmware image.

If a pflash image is not initially found, then a read-only
pflash device is created using the -bios filename.

Signed-off-by: Jordan Justen
Cc: Anthony Liguori
Cc: Aurelien Jarno
---
  Makefile.target|2 +-
  default-configs/i386-softmmu.mak   |1 +
  default-configs/x86_64-softmmu.mak |1 +
  hw/boards.h|1 +
  hw/pc.c|   46 +
  hw/pc.h|2 +
  hw/pcflash.c   |  130 
  vl.c   |2 +-
  8 files changed, 141 insertions(+), 44 deletions(-)
  create mode 100644 hw/pcflash.c

diff --git a/Makefile.target b/Makefile.target
index cde509b..4d8821f 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -223,7 +223,7 @@ obj-$(CONFIG_IVSHMEM) += ivshmem.o

  # Hardware support
  obj-i386-y += vga.o
-obj-i386-y += mc146818rtc.o i8259.o pc.o
+obj-i386-y += mc146818rtc.o i8259.o pc.o pcflash.o


This should be able to live in hw-obj-y in Makefile.objs since it 
doesn't depend on any TARGET_ defines or CPUState.



diff --git a/hw/pc.c b/hw/pc.c
index a3e8539..cf7257b 100644
--- a/hw/pc.c
+++ b/hw/pc.c
@@ -55,10 +55,6 @@
  #define DPRINTF(fmt, ...)
  #endif

-#define BIOS_FILENAME "bios.bin"
-
-#define PC_MAX_BIOS_SIZE (4 * 1024 * 1024)
-
  /* Leave a chunk of memory at the top of RAM for the BIOS ACPI tables.  */
  #define ACPI_DATA_SIZE   0x1
  #define BIOS_CFG_IOPORT 0x510
@@ -963,10 +959,8 @@ void pc_memory_init(const char *kernel_filename,
  ram_addr_t below_4g_mem_size,
  ram_addr_t above_4g_mem_size)
  {
-char *filename;
-int ret, linux_boot, i;
-ram_addr_t ram_addr, bios_offset, option_rom_offset;
-int bios_size, isa_bios_size;
+int linux_boot, i;
+ram_addr_t ram_addr, option_rom_offset;
  void *fw_cfg;

  linux_boot = (kernel_filename != NULL);
@@ -983,44 +977,12 @@ void pc_memory_init(const char *kernel_filename,
   ram_addr + below_4g_mem_size);
  }

-/* BIOS load */
-if (bios_name == NULL)
-bios_name = BIOS_FILENAME;
-filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, bios_name);
-if (filename) {
-bios_size = get_image_size(filename);
-} else {
-bios_size = -1;
-}
-if (bios_size<= 0 ||
-(bios_size % 65536) != 0) {
-goto bios_error;
-}
-bios_offset = qemu_ram_alloc(NULL, "pc.bios", bios_size);
-ret = rom_add_file_fixed(bios_name, (uint32_t)(-bios_size), -1);
-if (ret != 0) {
-bios_error:
-fprintf(stderr, "qemu: could not load PC BIOS '%s'\n", bios_name);
-exit(1);
-}
-if (filename) {
-qemu_free(filename);
-}
-/* map the last 128KB of the BIOS in ISA space */
-isa_bios_size = bios_size;
-if (isa_bios_size>  (128 * 1024))
-isa_bios_size = 128 * 1024;
-cpu_register_physical_memory(0x10 - isa_bios_size,
- isa_bios_size,
- (bios_offset + bios_size - isa_bios_size) | 
IO_MEM_ROM);
+/* Initialize ROM or flash ranges for PC firmware */
+pc_system_firmware_init();

  option_rom_offset = qemu_ram_alloc(NULL, "pc.rom", PC_ROM_SIZE);
  cpu_register_physical_memory(PC_ROM_MIN_VGA, PC_ROM_SIZE, 
option_rom_offset);

-/* map all the bios at the top of memory */
-cpu_register_physical_memory((uint32_t)(-bios_size),
- bios_size, bios_offset | IO_MEM_ROM);
-
  fw_cfg = bochs_bios_init();
  rom_set_fw(fw_cfg);

diff --git a/hw/pc.h b/hw/pc.h
index 6d5730b..114816d 100644
--- a/hw/pc.h
+++ b/hw/pc.h
@@ -238,4 +238,6 @@ static inline bool isa_ne2000_init(int base, int irq, 
NICInfo *nd)

  int e820_add_entry(uint64_t, uint64_t, uint32_t);

+void pc_system_firmware_init(void);
+
  #endif
diff --git a/hw/pcflash.c b/hw/pcflash.c
new file mode 100644
index 000..514b1ed
--- /dev/null
+++ b/hw/pcflash.c
@@ -0,0 +1,130 @@
+/*
+ * QEMU PC System Flash
+ *
+ * Copyright (c) 2003-2004 Fabrice Bellard
+ * Copyright (c) 2011 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to 
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMP

Re: [Qemu-devel] [RFC PATCH 1/4] add support for machine models to specify their migration format

2011-07-29 Thread Anthony Liguori

On 06/30/2011 10:46 AM, Paolo Bonzini wrote:

We need to provide a new migration format, and not break migration
in old machine models.  So add a migration_format field to QEMUMachine.

Signed-off-by: Paolo Bonzini
---
  cpu-common.h  |3 ---
  hw/boards.h   |1 +
  qemu-common.h |3 +++
  savevm.c  |7 +--
  4 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/cpu-common.h b/cpu-common.h
index b027e43..8c06dbb 100644
--- a/cpu-common.h
+++ b/cpu-common.h
@@ -26,9 +26,6 @@ enum device_endian {
  DEVICE_LITTLE_ENDIAN,
  };

-/* address in the RAM (different from a physical address) */
-typedef unsigned long ram_addr_t;
-
  /* memory API */

  typedef void CPUWriteMemoryFunc(void *opaque, target_phys_addr_t addr, 
uint32_t value);
diff --git a/hw/boards.h b/hw/boards.h
index 716fd7b..560dbaf 100644
--- a/hw/boards.h
+++ b/hw/boards.h
@@ -19,6 +19,7 @@ typedef struct QEMUMachine {
  QEMUMachineInitFunc *init;
  int use_scsi;
  int max_cpus;
+unsigned migration_format;
  unsigned int no_serial:1,
  no_parallel:1,
  use_virtcon:1,
diff --git a/qemu-common.h b/qemu-common.h
index 109498d..550fe2c 100644
--- a/qemu-common.h
+++ b/qemu-common.h
@@ -119,6 +119,9 @@ static inline char *realpath(const char *path, char 
*resolved_path)
  #define PRIo64 "I64o"
  #endif

+/* address in the RAM (different from a physical address) */
+typedef unsigned long ram_addr_t;
+
  /* FIXME: Remove NEED_CPU_H.  */
  #ifndef NEED_CPU_H

diff --git a/savevm.c b/savevm.c
index 8139bc7..74e6e99 100644
--- a/savevm.c
+++ b/savevm.c
@@ -72,6 +72,7 @@
  #include "qemu-common.h"
  #include "hw/hw.h"
  #include "hw/qdev.h"
+#include "hw/boards.h"
  #include "net.h"
  #include "monitor.h"
  #include "sysemu.h"
@@ -1474,7 +1475,7 @@ int qemu_savevm_state_begin(Monitor *mon, QEMUFile *f, 
int blk_enable,
  }

  qemu_put_be32(f, QEMU_VM_FILE_MAGIC);
-qemu_put_be32(f, QEMU_VM_FILE_VERSION);
+qemu_put_be32(f, current_machine->migration_format ?: 
QEMU_VM_FILE_VERSION);


Please avoid this gcc extension as it's relatively obscure.  But in 
addition, why would use you 0 as the new format instead of 
QEMU_VM_FILE_VERSION + 1?


Regards,

Anthony Liguori


  QTAILQ_FOREACH(se,&savevm_handlers, entry) {
  int len;
@@ -1747,8 +1748,10 @@ int qemu_loadvm_state(QEMUFile *f)
  fprintf(stderr, "SaveVM v2 format is obsolete and don't work 
anymore\n");
  return -ENOTSUP;
  }
-if (v != QEMU_VM_FILE_VERSION)
+if (v != (current_machine->migration_format ?: QEMU_VM_FILE_VERSION)) {
+fprintf(stderr, "Mismatching SaveVM format v%d\n", v);
  return -ENOTSUP;
+}

  while ((section_type = qemu_get_byte(f)) != QEMU_VM_EOF) {
  uint32_t instance_id, version_id, section_id;





Re: [Qemu-devel] [PATCH 49/55] block: Declare qemu_blockalign() in block.h, not block_int.h

2011-07-29 Thread Christoph Hellwig
On Fri, Jul 29, 2011 at 10:56:07AM +0200, Markus Armbruster wrote:
> > Hmm.  We already do proper read-modify-write cycles for actual data
> > transfers, so killing the buffer inside SD sounds like the better
> > idea.  qemu_blockalign really should be used only for block-layer internal
> > allocations.
> 
> What about the uses in scsi-disk.c and ide/core.c?

They are allocating internal bounce buffers due to suboptimal I/O
models.  But given that this is the reality in multiple qemu drivers I
think I'll give up and ack the move.



Re: [Qemu-devel] [RFC PATCH 3/4] savevm: define new unambiguous migration format

2011-07-29 Thread Anthony Liguori

On 06/30/2011 10:46 AM, Paolo Bonzini wrote:

With the current migration format, VMS_STRUCTs with subsections
are ambiguous.  The protocol cannot tell whether a 0x5 byte after
the VMS_STRUCT is a subsection or part of the parent data stream.
In the past QEMU assumed it was always a part of a subsection; after
commit eb60260 (savevm: fix corruption in vmstate_subsection_load().,
2011-02-03) the choice depends on whether the VMS_STRUCT has subsections
defined.

Unfortunately, this means that if a destination has no subsections
defined for the struct, it will happily read subsection data into
its own fields.  And if you are "lucky" enough to stumble on a
zero byte at the right time, it will be interpreted as QEMU_VM_EOF
and migration will be interrupted.

There is no way out of this except defining an incompatible
migration protocol with a sentinel at the end of embedded structs.
Of course, this is restricted to new machine models.

Signed-off-by: Paolo Bonzini
---
  hw/pc_piix.c |6 ++
  savevm.c |   27 +++
  2 files changed, 25 insertions(+), 8 deletions(-)

diff --git a/hw/pc_piix.c b/hw/pc_piix.c
index 18cc942..d8d629c 100644
--- a/hw/pc_piix.c
+++ b/hw/pc_piix.c
@@ -271,6 +271,7 @@ static QEMUMachine pc_machine_v0_14 = {
  .desc = "Standard PC",
  .init = pc_init_pci,
  .max_cpus = 255,
+.migration_format = 3,
  };


Please introduce a macro so this code is readable.

We have other machines that support migration in other archs too.

Regards,

Anthony Liguori



Re: [Qemu-devel] [RFC PATCH 0/4] Fix subsection ambiguity in the migration format

2011-07-29 Thread Anthony Liguori

On 07/25/2011 04:10 PM, Paolo Bonzini wrote:

On Thu, Jun 30, 2011 at 17:46, Paolo Bonzini  wrote:
I have now tested this series (exactly as sent) both by examining
manually the differences between the two formats on the same guest
state, and by a mix of saves/restores (new on new, 0.14 on new
pc-0.14, new pc-0.14 on 0.14; also the same combinations on RHEL).  It
always does what is expected.

Michael Tsirkin objected that the format should be passed as a
parameter in the migrate command.  I kind of agree, however since this
is a real bug you would need to bump the default for new machine
types, and this default would still go in the QEMUMachine struct like
I am doing.  So I consider the two settings to be orthogonal.  Also,
the alternative requires changes to the whole management stack and if
the default is not changed it imposes a broken format unless you
update the management tools.  Clearly much less bang for the buck.

I think this is ready to go into 0.15.  The bug happens when migrating
to 0.14 a pc-0.14 machine created with QEMU 0.15 and which has a
floppy.  The media changed subsection is almost always included, and
this causes problems when migrating to 0.14 which didn't have any
subsection for the floppy device.  While QEMU support for migration to
old version admittedly depends on luck, this isn't true of certain
downstreams :) which would like to have an unambiguous migration
format.


I really hate the idea of changing the migration format moments before 
the release.


Since subsections are optional, can't we take the offending subsections, 
remove them, bump the section version numbers and make the fields required?


That "fixes" this issue temporarily without changing the format and we 
can change the format for 1.0.


Regards,

Anthony Liguori



Paolo







Re: [Qemu-devel] [PATCH 05/10] qcow2: Use coroutines

2011-07-29 Thread Stefan Hajnoczi
On Tue, Jul 26, 2011 at 12:49 PM, Kevin Wolf  wrote:
> Signed-off-by: Kevin Wolf 
> ---
>  block/qcow2-cluster.c |   26 +++---
>  block/qcow2.c         |  240 
> ++---
>  block/qcow2.h         |    5 +-
>  3 files changed, 102 insertions(+), 169 deletions(-)

I like this.  The only thing that I would like to see is comments
explain what "lock" protects and why.

As I understand it lock is needed because the metadata accesses which
use bdrv_pread() and friends will yield.  So it is necessary to
prevent in-memory qcow2 metadata from getting corrupted during these
operations.

Stefan



Re: [Qemu-devel] [PATCH 0/3] small trivial patches

2011-07-29 Thread Kevin Wolf
Am 27.07.2011 20:11, schrieb Frediano Ziglio:
> Minor fixes and improves
> 
> Frediano Ziglio (3):
>   block: removed unused function
>   block: typo fix
>   aio: always check paio_init result
> 
>  block.c   |   13 -
>  block.h   |2 --
>  block/raw-posix.c |   13 ++---
>  3 files changed, 6 insertions(+), 22 deletions(-)

Thanks, applied all to the block branch (and modified the commit log to
say "raw-posix: ..." for patches 2 and 3)

Kevin



Re: [Qemu-devel] [RFC PATCH 0/4] Fix subsection ambiguity in the migration format

2011-07-29 Thread Kevin Wolf
Am 26.07.2011 14:37, schrieb Anthony Liguori:
> On 07/26/2011 07:07 AM, Juan Quintela wrote:
>> Anthony Liguori  wrote:
>>> == What we need ==
>>>
>>> We need to decompose migration into three different problems: 1)
>>> serializing device state 2) transforming the device model in order to
>>> satisfy forwards and backwards compatibility 3) encoding the
>>> serialized device model on the wire.
>>
>> I will change this to:
>> - We need to be able to "enable/disable" features of a device.
>>A.K.A. make -M pc-0.14 work with devices with the same features
>>than 0.14.  Notice that this is _independent_ of migration.
> 
> In theory, we already have this with qdev flags.
> 
>> - Be able to describe that different features/versions.  This is not the
>>difficult part, it can be subsections, optional fields, whatever.
>>What is the difficult part is _knowing_ what fields needs to be on
>>each version.  That again depends of the device, not migration.
>>
>> - Be able to to do forward/bacward compatibility (and without
>>comunication both sides is basically impossible).
> 
> Hrm, I'm not sure I agree with these conclusions.
> 
> Management tools should do their best job to create two compatible 
> device models.
> 
> Given two compatible device models, there *may* be differences in the 
> structure of the device models since we evolve things over time.  We may 
> rename a field, change the type, etc.  To support this, we can use 
> filters both on the destination and receive end to do our best to 
> massage the device model into something compatible.
> 
> But creating two creating compatible device models is not the job of the 
> migration protocol.  It's the job of management tools.

I'm not sure if I agree with this.

Let's forget about management tools for a moment, and just think of a
qemu instance with a given set of command line option describing its
devices. Then you start another instance with different options and
-incoming and start a migration. The result will be something, but
definitely not a successfully migrated VM (even though it might look
like one at first).

This is why I believe that the information about which devices to use
actually belongs into the migration data. There's no way to make use of
it with different options.

>>> 5) Once we're here, we can implement the next 5-year format.  That
>>> could be ASN.1 and be bidirectional or whatever makes the most sense.
>>> We could support 50 formats if we wanted to.  As long as the transport
>>> is distinct from the serialization and compat routines, it really
>>> doesn't matter.
>>
>> This means finishing the VMState support, once there, only thing needs
>> to change is "copy" the savevm, and change the "visitors" to whatever
>> else that we need/want.
> 
> There's no need to "finish" VMState to convert to visitors.  It's just 
> sed -e 's:qemu_put_be32:visit_type_int32:g'

Actually I think the real question is whether we want to have VMState or
not. If we do (and I think it's a good thing), then yes, we need to
finish it. If not, then we should revert the parts that are already
there. We shouldn't end up in an inconsistent state where half of qemu
is converted and we don't feel a need to do anything about the other half.

Kevin



Re: [Qemu-devel] [PATCH v2 00/23] Memory API, batch 1

2011-07-29 Thread Anthony Liguori

On 07/26/2011 06:25 AM, Avi Kivity wrote:

This patchset contains the core of the memory API, with one device
(usb-ohci) coverted for reference.  The API is currently implemented on
top of the old ram_addr_t/cpu_register_physical_memory() API, but the plan
is to make it standalone later.

The goals of the API are:
  - correctness: by modelling the memory hierarchy, things like the 440FX PAM
registers and movable, overlapping PCI BARs can be modelled accurately.
  - efficiency: by maintaining an object tree describing guest memory, we
can eventually get rid of the page descriptor array
  - security: by having more information available declaratively, we reduce
coding errors that may be exploited by malicious guests


Applied all.  Thanks.

Regards,

Anthony Liguori



Also available from

   git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git
  refs/tags/memory-region-batch-1-v2

Changes from v1:
  - switched to gtk-doc
  - more copyright blurbs
  - simplified flatview_simplify()
  - use assert() instead of abort() for invariant checks
(but keep abort() for runtime errors)
  - commit log fixups

Avi Kivity (23):
   Add memory API documentation
   Hierarchical memory region API
   memory: implement dirty tracking
   memory: merge adjacent segments of a single memory region
   Internal interfaces for memory API
   memory: abstract address space operations
   memory: rename MemoryRegion::has_ram_addr to ::terminates
   memory: late initialization of ram_addr
   memory: I/O address space support
   memory: add backward compatibility for old portio registration
   memory: add backward compatibility for old mmio registration
   memory: add ioeventfd support
   memory: separate building the final memory map into two steps
   memory: transaction API
   exec.c: initialize memory map
   ioport: register ranges by byte aligned addresses always
   pc: grab system_memory
   pc: convert pc_memory_init() to memory API
   pc: move global memory map out of pc_init1() and into its callers
   pci: pass address space to pci bus when created
   pci: add MemoryRegion based BAR management API
   sysbus: add MemoryRegion based memory management API
   usb-ohci: convert to MemoryRegion

  Makefile.target|1 +
  docs/memory.txt|  172 
  exec-memory.h  |   39 ++
  exec.c |   19 +
  hw/apb_pci.c   |2 +
  hw/bonito.c|4 +-
  hw/grackle_pci.c   |5 +-
  hw/gt64xxx.c   |4 +-
  hw/pc.c|   62 ++-
  hw/pc.h|9 +-
  hw/pc_piix.c   |   20 +-
  hw/pci.c   |   63 +++-
  hw/pci.h   |   15 +-
  hw/pci_host.h  |1 +
  hw/pci_internals.h |1 +
  hw/piix_pci.c  |   13 +-
  hw/ppc4xx_pci.c|5 +-
  hw/ppc_mac.h   |9 +-
  hw/ppc_newworld.c  |5 +-
  hw/ppc_oldworld.c  |3 +-
  hw/ppc_prep.c  |3 +-
  hw/ppce500_pci.c   |6 +-
  hw/prep_pci.c  |5 +-
  hw/prep_pci.h  |3 +-
  hw/sh_pci.c|4 +-
  hw/sysbus.c|   27 ++-
  hw/sysbus.h|3 +
  hw/unin_pci.c  |   10 +-
  hw/usb-ohci.c  |   42 +--
  hw/versatile_pci.c |2 +
  ioport.c   |4 +-
  memory.c   | 1141 
  memory.h   |  469 +
  33 files changed, 2072 insertions(+), 99 deletions(-)
  create mode 100644 docs/memory.txt
  create mode 100644 exec-memory.h
  create mode 100644 memory.c
  create mode 100644 memory.h






Re: [Qemu-devel] [PATCH v7] showing a splash picture when start

2011-07-29 Thread Anthony Liguori

On 07/27/2011 05:04 AM, Wayne Xia wrote:

From: wayne

 Added options to let qemu transfer two configuration files to bios:
"bootsplash.bmp" and "etc/boot-menu-wait", which could be specified by command
 -boot splash=P,splash-time=T
P is jpg/bmp file name or an absolute path, T have a max value of 0x, unit
is ms. With these two options, if user invoke qemu with menu=on option, then
a splash picture would be showed in a given time. For example:
 qemu -boot menu=on,splash=/root/boot.bmp,splash-time=5000
would make boot.bmp shown as a brand with 5 seconds in the booting up process.
This feature need the new seabios's support, which could be got from git.

Signed-off-by: Wayne Xia


Applied but haven't bumped SeaBIOS yet.  Will bump SeaBIOS once -rc1 
goes out.


Regards,

Anthony Liguori


---
  hw/fw_cfg.c |  140 ++-
  qemu-config.c   |   27 +++
  qemu-options.hx |   16 ++-
  sysemu.h|3 +
  vl.c|   17 ++-
  5 files changed, 199 insertions(+), 4 deletions(-)

diff --git a/hw/fw_cfg.c b/hw/fw_cfg.c
index 34e7526..a29db90 100644
--- a/hw/fw_cfg.c
+++ b/hw/fw_cfg.c
@@ -26,6 +26,7 @@
  #include "isa.h"
  #include "fw_cfg.h"
  #include "sysbus.h"
+#include "qemu-error.h"

  /* debug firmware config */
  //#define DEBUG_FW_CFG
@@ -56,6 +57,143 @@ struct FWCfgState {
  Notifier machine_ready;
  };

+#define JPG_FILE 0
+#define BMP_FILE 1
+
+static FILE *probe_splashfile(char *filename, int *file_sizep, int *file_typep)
+{
+FILE *fp = NULL;
+int fop_ret;
+int file_size;
+int file_type = -1;
+unsigned char buf[2] = {0, 0};
+unsigned int filehead_value = 0;
+int bmp_bpp;
+
+fp = fopen(filename, "rb");
+if (fp == NULL) {
+error_report("failed to open file '%s'.", filename);
+return fp;
+}
+/* check file size */
+fseek(fp, 0L, SEEK_END);
+file_size = ftell(fp);
+if (file_size<  2) {
+error_report("file size is less than 2 bytes '%s'.", filename);
+fclose(fp);
+fp = NULL;
+return fp;
+}
+/* check magic ID */
+fseek(fp, 0L, SEEK_SET);
+fop_ret = fread(buf, 1, 2, fp);
+filehead_value = (buf[0] + (buf[1]<<  8))&  0x;
+if (filehead_value == 0xd8ff) {
+file_type = JPG_FILE;
+} else {
+if (filehead_value == 0x4d42) {
+file_type = BMP_FILE;
+}
+}
+if (file_type<  0) {
+error_report("'%s' not jpg/bmp file,head:0x%x.",
+ filename, filehead_value);
+fclose(fp);
+fp = NULL;
+return fp;
+}
+/* check BMP bpp */
+if (file_type == BMP_FILE) {
+fseek(fp, 28, SEEK_SET);
+fop_ret = fread(buf, 1, 2, fp);
+bmp_bpp = (buf[0] + (buf[1]<<  8))&  0x;
+if (bmp_bpp != 24) {
+error_report("only 24bpp bmp file is supported.");
+fclose(fp);
+fp = NULL;
+return fp;
+}
+}
+/* return values */
+*file_sizep = file_size;
+*file_typep = file_type;
+return fp;
+}
+
+static void fw_cfg_bootsplash(FWCfgState *s)
+{
+int boot_splash_time = -1;
+const char *boot_splash_filename = NULL;
+char *p;
+char *filename;
+FILE *fp;
+int fop_ret;
+int file_size;
+int file_type = -1;
+const char *temp;
+
+/* get user configuration */
+QemuOptsList *plist = qemu_find_opts("boot-opts");
+QemuOpts *opts = QTAILQ_FIRST(&plist->head);
+if (opts != NULL) {
+temp = qemu_opt_get(opts, "splash");
+if (temp != NULL) {
+boot_splash_filename = temp;
+}
+temp = qemu_opt_get(opts, "splash-time");
+if (temp != NULL) {
+p = (char *)temp;
+boot_splash_time = strtol(p, (char **)&p, 10);
+}
+}
+
+/* insert splash time if user configurated */
+if (boot_splash_time>= 0) {
+/* validate the input */
+if (boot_splash_time>  0x) {
+error_report("splash time is big than 65535, force it to 65535.");
+boot_splash_time = 0x;
+}
+/* use little endian format */
+qemu_extra_params_fw[0] = (uint8_t)(boot_splash_time&  0xff);
+qemu_extra_params_fw[1] = (uint8_t)((boot_splash_time>>  8)&  0xff);
+fw_cfg_add_file(s, "etc/boot-menu-wait", qemu_extra_params_fw, 2);
+}
+
+/* insert splash file if user configurated */
+if (boot_splash_filename != NULL) {
+filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, boot_splash_filename);
+if (filename == NULL) {
+error_report("failed to find file '%s'.", boot_splash_filename);
+return;
+}
+/* probing the file */
+fp = probe_splashfile(filename,&file_size,&file_type);
+if (fp == NULL) {
+qemu_free(filename);
+return;
+}
+/* loading file data */
+i

Re: [Qemu-devel] [PATCH 0.16 v3 0/3] make endian-independent unaligned memory access functions available to libhw

2011-07-29 Thread Anthony Liguori

On 07/28/2011 05:10 AM, Paolo Bonzini wrote:

Functions like ldl_be_p and ldl_le_p are currently used only as building
blocks for {ld,st}XX_p.  As such, they are in cpu-all.h even though they
have absolutely no dependency on the target.

In order to make them globally available, this series moves them to
bswap.h instead.

An interesting part of this is that there are functions also for floating
point values.  Leaving them in cpu-all.h would be possible but untidy.
In fact handling these is easy, but it requires to make softfloat.h
target-dependent as well.  This is what patch 2 does.


Applied.  Thanks.

Regards,

Anthony Liguori



v2->v3:
 rebase

v1->v2:
 rebase, use softfloat-specialize.h instead of introducing
 softfloat-target.h

Paolo Bonzini (3):
   move WORDS_ALIGNED to qemu-common.h
   softfloat: change default nan definitions to variables
   move unaligned memory access functions to bswap.h

  Makefile.hw|2 +-
  bswap.h|  474 
  configure  |3 +-
  cpu-all.h  |  446 +-
  cpu-common.h   |4 -
  fpu/softfloat-specialize.h |   72 +++
  fpu/softfloat.h|   60 +-
  qemu-common.h  |4 +
  8 files changed, 562 insertions(+), 503 deletions(-)






Re: [Qemu-devel] [PATCH v2] qdev: Reset hot-plugged devices

2011-07-29 Thread Anthony Liguori

On 07/24/2011 12:38 PM, Jan Kiszka wrote:

From: Jan Kiszka

Device models rely on the core invoking their reset handlers after init.
We do this in the cold-plug case, but so far we miss this step after
hot-plug.

Signed-off-by: Jan Kiszka


Applied.  Thanks.

Regards,

Anthony Liguori


---

Changes in v2:
  - move reset to qdev_init in case the device is created by the
hot-plugged one (composed devices)

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

diff --git a/hw/qdev.c b/hw/qdev.c
index a0fcd06..b4ea8e1 100644
--- a/hw/qdev.c
+++ b/hw/qdev.c
@@ -289,6 +289,9 @@ int qdev_init(DeviceState *dev)
 dev->alias_required_for_version);
  }
  dev->state = DEV_STATE_INITIALIZED;
+if (dev->hotplugged&&  dev->info->reset) {
+dev->info->reset(dev);
+}
  return 0;
  }






Re: [Qemu-devel] [PATCH 1/2] linux aio: support flush operation

2011-07-29 Thread Christoph Hellwig
On Thu, Jul 28, 2011 at 02:41:02PM +0200, Kevin Wolf wrote:
> > More or less.  There's one corner case for all Linux I/O, and that is
> > only writes up to INT_MAX are supported, and larger writes (and reads)
> > get truncated to it.  It's pretty nasty, but Linux has been vocally
> > opposed to fixing this issue.
> 
> I think we can safely ignore this. So just replacing the current
> ret = -EINVAL; by a memset(buf + ret, 0, len - ret); ret = 0; should be
> okay, right? (Of course using the qiov versions, but you get the idea)

This should be safe.




Re: [Qemu-devel] [PATCH -V2] coroutine: Add CoRwlock support

2011-07-29 Thread Aneesh Kumar K.V
On Fri, 29 Jul 2011 14:53:14 +0200, Kevin Wolf  wrote:
> Am 27.07.2011 18:21, schrieb Aneesh Kumar K.V:
> > Signed-off-by: Aneesh Kumar K.V 
> > ---
> >  qemu-coroutine-lock.c |   44 
> >  qemu-coroutine.h  |   12 
> >  2 files changed, 56 insertions(+), 0 deletions(-)
> 
> Looks good to me.
> 
> What's your plan with getting this merged? Are you going to just include
> it with another series that you'll send once the basic coroutine support
> is in?

Since the patch already is dependent on CoQueue, it would be nice if you
can push it through your tree. I will stage the dependent VirtFS patch
after that get merged upstream.

-aneesh



Re: [Qemu-devel] [RFC PATCH 0/4] Fix subsection ambiguity in the migration format

2011-07-29 Thread Anthony Liguori

On 07/29/2011 09:03 AM, Kevin Wolf wrote:

Am 26.07.2011 14:37, schrieb Anthony Liguori:

Hrm, I'm not sure I agree with these conclusions.

Management tools should do their best job to create two compatible
device models.

Given two compatible device models, there *may* be differences in the
structure of the device models since we evolve things over time.  We may
rename a field, change the type, etc.  To support this, we can use
filters both on the destination and receive end to do our best to
massage the device model into something compatible.

But creating two creating compatible device models is not the job of the
migration protocol.  It's the job of management tools.


I'm not sure if I agree with this.

Let's forget about management tools for a moment, and just think of a
qemu instance with a given set of command line option describing its
devices. Then you start another instance with different options and
-incoming and start a migration. The result will be something, but
definitely not a successfully migrated VM (even though it might look
like one at first).

This is why I believe that the information about which devices to use
actually belongs into the migration data. There's no way to make use of
it with different options.


I agree with you actually.

Right now, it's the management tools job.  The complexity is daunting. 
Recreating the same object model, particularly after hotplug, is 
difficult and in many cases impossible.


I think the primary problem is that there are so many ways to create 
things.  -M pc creates a bunch of stuff that there's no way to create 
individually.  The stuff it creates can sort of be manipulated by using 
-global but not on a per device basis.  Much of it isn't even addressable.


Creating backends is a totally different mechanism and each backend has 
different mechanisms to enumerate and create.


The result is that introspecting what's there and recreating it is 
insanely complex today.


That's the motivation behind QOM.  plug_list lists *everything*.  All 
objects, whether they are created as part of the PIIX3 or whether it's a 
backing file, can be directly addressed and manipulated.


If you look at qsh, there's an import command.  The export command is 
trivial and I don't remember if I've already added it.  But the point is 
that you should be able to 'qsh export' everything and then 'qsh import' 
everything to create the exact same device model in another QEMU instance.


And yeah, this should end up becoming part of the migration protocol.


5) Once we're here, we can implement the next 5-year format.  That
could be ASN.1 and be bidirectional or whatever makes the most sense.
We could support 50 formats if we wanted to.  As long as the transport
is distinct from the serialization and compat routines, it really
doesn't matter.


This means finishing the VMState support, once there, only thing needs
to change is "copy" the savevm, and change the "visitors" to whatever
else that we need/want.


There's no need to "finish" VMState to convert to visitors.  It's just
sed -e 's:qemu_put_be32:visit_type_int32:g'


Actually I think the real question is whether we want to have VMState or
not.


VMState doesn't give me what I want by itself.

I want to be able to marshal the device tree to an in-memory 
representation that can be manipulated.  One approach to doing that is 
first completing VMState, and then writing something that can walk the 
VMState descriptions.  The VMState descriptions are fairly complicated 
but it's doable.


Another approach, which I'm arguing is much simpler, the imperative 
nature of our current serialization and use visitors.


There may be other advantages of a declarative description of VMState 
that would justify completing the conversions.  But I don't think we 
need it to start improving the migration protocol.


Regards,

Anthony Liguori



Re: [Qemu-devel] [PATCH] lm832x: Take DeviceState pointer in lm832x_key_event()

2011-07-29 Thread Anthony Liguori

On 07/28/2011 09:47 AM, Peter Maydell wrote:

Since lm832x has been qdev'ified, its users will generally
have a DeviceState pointer rather than an i2c_slave pointer,
so adjust lm832x_key_event's prototype to suit.

This allows the n810 (its only user) to actually pass a correct
pointer to it rather than NULL. The effect is that we no longer
segfault when a key is pressed.

Signed-off-by: Peter Maydell
---
NB: this patch depends on the OMAP GPIO v2 patchset.


Could you put together a pull request for these devices?

Regards,

Anthony Liguori



  hw/i2c.h |2 +-
  hw/lm832x.c  |4 ++--
  hw/nseries.c |7 +++
  3 files changed, 6 insertions(+), 7 deletions(-)

diff --git a/hw/i2c.h b/hw/i2c.h
index 5514402..9381d01 100644
--- a/hw/i2c.h
+++ b/hw/i2c.h
@@ -72,6 +72,6 @@ void wm8750_set_bclk_in(void *opaque, int new_hz);
  void tmp105_set(i2c_slave *i2c, int temp);

  /* lm832x.c */
-void lm832x_key_event(i2c_slave *i2c, int key, int state);
+void lm832x_key_event(DeviceState *dev, int key, int state);

  #endif
diff --git a/hw/lm832x.c b/hw/lm832x.c
index 590a4cc..992ce49 100644
--- a/hw/lm832x.c
+++ b/hw/lm832x.c
@@ -474,9 +474,9 @@ static int lm8323_init(i2c_slave *i2c)
  return 0;
  }

-void lm832x_key_event(struct i2c_slave *i2c, int key, int state)
+void lm832x_key_event(DeviceState *dev, int key, int state)
  {
-LM823KbdState *s = (LM823KbdState *) i2c;
+LM823KbdState *s = FROM_I2C_SLAVE(LM823KbdState, I2C_SLAVE_FROM_QDEV(dev));

  if ((s->status&  INT_ERROR)&&  (s->error&  ERR_FIFOOVR))
  return;
diff --git a/hw/nseries.c b/hw/nseries.c
index 32f2f53..45b52bb 100644
--- a/hw/nseries.c
+++ b/hw/nseries.c
@@ -45,7 +45,7 @@ struct n800_s {
  i2c_bus *i2c;

  int keymap[0x80];
-i2c_slave *kbd;
+DeviceState *kbd;

  TUSBState *usb;
  void *retu;
@@ -362,7 +362,6 @@ static int n810_keys[0x80] = {
  static void n810_kbd_setup(struct n800_s *s)
  {
  qemu_irq kbd_irq = qdev_get_gpio_in(s->cpu->gpio, N810_KEYBOARD_GPIO);
-DeviceState *dev;
  int i;

  for (i = 0; i<  0x80; i ++)
@@ -375,8 +374,8 @@ static void n810_kbd_setup(struct n800_s *s)

  /* Attach the LM8322 keyboard to the I2C bus,
   * should happen in n8x0_i2c_setup and s->kbd be initialised here.  */
-dev = i2c_create_slave(s->i2c, "lm8323", N810_LM8323_ADDR);
-qdev_connect_gpio_out(dev, 0, kbd_irq);
+s->kbd = i2c_create_slave(s->i2c, "lm8323", N810_LM8323_ADDR);
+qdev_connect_gpio_out(s->kbd, 0, kbd_irq);
  }

  /* LCD MIPI DBI-C controller (URAL) */





Re: [Qemu-devel] [RFC PATCH 1/4] add support for machine models to specify their migration format

2011-07-29 Thread Paolo Bonzini

On 07/29/2011 03:08 PM, Anthony Liguori wrote:


Please avoid this gcc extension as it's relatively obscure.  But in
addition, why would use you 0 as the new format instead of
QEMU_VM_FILE_VERSION + 1?


0 is the default.  If a machine doesn't specify a format, it gets the 
newest one automatically.


Paolo



Re: [Qemu-devel] [RFC PATCH 3/4] savevm: define new unambiguous migration format

2011-07-29 Thread Paolo Bonzini

On 07/29/2011 03:12 PM, Anthony Liguori wrote:

Please introduce a macro so this code is readable.


Ok.


We have other machines that support migration in other archs too.


Those machine types are not versioned, so they will automatically switch 
to the newest version.


Paolo



Re: [Qemu-devel] [PATCH v2] multiboot: Fix bss segment support

2011-07-29 Thread Anthony Liguori

On 07/24/2011 10:55 AM, Göran Weinholt wrote:

Multiboot images can specify a bss segment. The boot loader must clear
the memory of the bss and ensure that no modules or structures are
allocated inside it. Several fields are provided in the Multiboot
header that were previously not used properly. The header is now used
to determine how much data should be read from the image and how much
memory should be reserved to the bss segment.

Signed-off-by: Göran Weinholt


Applied.  Thanks.

Regards,

Anthony Liguori


---
  hw/multiboot.c |   14 +-
  1 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/hw/multiboot.c b/hw/multiboot.c
index 2426e84..a1d3f41 100644
--- a/hw/multiboot.c
+++ b/hw/multiboot.c
@@ -198,11 +198,14 @@ int load_multiboot(void *fw_cfg,
  } else {
  /* Valid if mh_flags sets MULTIBOOT_HEADER_HAS_ADDR. */
  uint32_t mh_header_addr = ldl_p(header+i+12);
+uint32_t mh_load_end_addr = ldl_p(header+i+20);
+uint32_t mh_bss_end_addr = ldl_p(header+i+24);
  mh_load_addr = ldl_p(header+i+16);
  uint32_t mb_kernel_text_offset = i - (mh_header_addr - mh_load_addr);
+uint32_t mb_load_size = mh_load_end_addr - mh_load_addr;

  mh_entry_addr = ldl_p(header+i+28);
-mb_kernel_size = kernel_file_size - mb_kernel_text_offset;
+mb_kernel_size = mh_bss_end_addr - mh_load_addr;

  /* Valid if mh_flags sets MULTIBOOT_HEADER_HAS_VBE.
  uint32_t mh_mode_type = ldl_p(header+i+32);
@@ -212,17 +215,18 @@ int load_multiboot(void *fw_cfg,

  mb_debug("multiboot: mh_header_addr = %#x\n", mh_header_addr);
  mb_debug("multiboot: mh_load_addr = %#x\n", mh_load_addr);
-mb_debug("multiboot: mh_load_end_addr = %#x\n", ldl_p(header+i+20));
-mb_debug("multiboot: mh_bss_end_addr = %#x\n", ldl_p(header+i+24));
+mb_debug("multiboot: mh_load_end_addr = %#x\n", mh_load_end_addr);
+mb_debug("multiboot: mh_bss_end_addr = %#x\n", mh_bss_end_addr);
  mb_debug("qemu: loading multiboot kernel (%#x bytes) at %#x\n",
- mb_kernel_size, mh_load_addr);
+ mb_load_size, mh_load_addr);

  mbs.mb_buf = qemu_malloc(mb_kernel_size);
  fseek(f, mb_kernel_text_offset, SEEK_SET);
-if (fread(mbs.mb_buf, 1, mb_kernel_size, f) != mb_kernel_size) {
+if (fread(mbs.mb_buf, 1, mb_load_size, f) != mb_load_size) {
  fprintf(stderr, "fread() failed\n");
  exit(1);
  }
+memset(mbs.mb_buf + mb_load_size, 0, mb_kernel_size - mb_load_size);
  fclose(f);
  }






Re: [Qemu-devel] [PATCH] monitor: fix build breakage with --disable-vnc

2011-07-29 Thread Anthony Liguori

On 07/25/2011 03:29 AM, TeLeMan wrote:

The breakage was introduced by the commit 
13661089810d3e59931f3e80d7cb541b99af7071

Signed-off-by: TeLeMan


Applied.  Thanks.

Regards,

Anthony Liguori


---
  monitor.c |2 ++
  1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/monitor.c b/monitor.c
index 92cdd05..52ae5f2 100644
--- a/monitor.c
+++ b/monitor.c
@@ -1200,10 +1200,12 @@ static int add_graphics_client(Monitor *mon, const 
QDict *qdict, QObject **ret_d
  }
qerror_report(QERR_ADD_CLIENT_FAILED);
return -1;
+#ifdef CONFIG_VNC
  } else if (strcmp(protocol, "vnc") == 0) {
int fd = monitor_get_fd(mon, fdname);
vnc_display_add_client(NULL, fd, skipauth);
return 0;
+#endif
  } else if ((s = qemu_chr_find(protocol)) != NULL) {
int fd = monitor_get_fd(mon, fdname);
if (qemu_chr_add_client(s, fd)<  0) {





Re: [Qemu-devel] [PATCH] Fix last sector write on sd card

2011-07-29 Thread Anthony Liguori

On 07/25/2011 07:21 AM, Dr. David Alan Gilbert wrote:

 When writing the last sector of an SD card using WRITE_MULTIPLE_BLOCK
QEmu throws an error saying that we've run off the end, and leaves
itself in the wrong state.

 Tested on ARM Vexpress model.

Signed-off-by: Dr. David Alan Gilbert


Applied.  Thanks.

Regards,

Anthony Liguori



---
Don't throw address error on last block, and leave in correct state.

diff --git a/hw/sd.c b/hw/sd.c
index cedfb20..219a0dd 100644
--- a/hw/sd.c
+++ b/hw/sd.c
@@ -1450,14 +1450,8 @@ void sd_write_data(SDState *sd, uint8_t value)
  break;

  case 25:  /* CMD25:  WRITE_MULTIPLE_BLOCK */
-sd->data[sd->data_offset ++] = value;
-if (sd->data_offset>= sd->blk_len) {
-/* TODO: Check CRC before committing */
-sd->state = sd_programming_state;
-BLK_WRITE_BLOCK(sd->data_start, sd->data_offset);
-sd->blk_written ++;
-sd->data_start += sd->blk_len;
-sd->data_offset = 0;
+if (sd->data_offset == 0) {
+/* Start of the block - lets check the address is valid */
  if (sd->data_start + sd->blk_len>  sd->size) {
  sd->card_status |= ADDRESS_ERROR;
  break;
@@ -1466,6 +1460,15 @@ void sd_write_data(SDState *sd, uint8_t value)
  sd->card_status |= WP_VIOLATION;
  break;
  }
+}
+sd->data[sd->data_offset++] = value;
+if (sd->data_offset>= sd->blk_len) {
+/* TODO: Check CRC before committing */
+sd->state = sd_programming_state;
+BLK_WRITE_BLOCK(sd->data_start, sd->data_offset);
+sd->blk_written++;
+sd->data_start += sd->blk_len;
+sd->data_offset = 0;
  sd->csd[14] |= 0x40;

  /* Bzzztt  Operation complete.  */







Re: [Qemu-devel] [PATCH resend] Add missing trace call to oslib-posix.c:qemu_vmalloc()

2011-07-29 Thread Anthony Liguori

On 07/25/2011 10:13 AM, jes.soren...@redhat.com wrote:

From: Jes Sorensen

Signed-off-by: Jes Sorensen


Applied.  Thanks.

Regards,

Anthony Liguori


---
  oslib-posix.c |5 -
  1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/oslib-posix.c b/oslib-posix.c
index 3a18e86..196099c 100644
--- a/oslib-posix.c
+++ b/oslib-posix.c
@@ -79,7 +79,10 @@ void *qemu_memalign(size_t alignment, size_t size)
  /* alloc shared memory pages */
  void *qemu_vmalloc(size_t size)
  {
-return qemu_memalign(getpagesize(), size);
+void *ptr;
+ptr = qemu_memalign(getpagesize(), size);
+trace_qemu_vmalloc(size, ptr);
+return ptr;
  }

  void qemu_vfree(void *ptr)





Re: [Qemu-devel] [PATCH] Allow to leave type on default in -machine

2011-07-29 Thread Anthony Liguori

On 07/25/2011 11:11 AM, Jan Kiszka wrote:

On 2011-07-25 13:48, Jan Kiszka wrote:

On 2011-07-25 13:39, Markus Armbruster wrote:

Jan Kiszka  writes:


On 2011-07-25 12:45, Richard W.M. Jones wrote:

On Mon, Jul 25, 2011 at 12:33:01PM +0200, Jan Kiszka wrote:

On 2011-07-25 11:41, Richard W.M. Jones wrote:

On Sat, Jul 23, 2011 at 12:38:37PM +0200, Jan Kiszka wrote:

From: Jan Kiszka

-machine somehow suggests that it selects the machine, but it doesn't.
Fix that before this command is set in stone.

Actually, -machine should supersede -M and allow to introduce arbitrary
per-machine options to the command line. That will change the internal
realization again, but we will be able to keep the user interface
stable.


This breaks libguestfs which was doing:

   qemu -machine accel=kvm:tcg ...

We are not passing any -M option at all.  We don't particularly care
about the machine type since we're not that performance sensitive and
we don't need to serialize the machine state.

I have checked, and this works:

   qemu -machine pc,accel=kvm:tcg ...

"pc" is the default, right?  What about for other architectures?


Yes, pc is the right default. Other arch have other defaults.


So what you're saying is we have to parse qemu -machine \? output by
looking for the string '(default)'?  eg:

$ ./arm-softmmu/qemu-system-arm -machine \?|fgrep '(default)'
integratorcp ARM Integrator/CP (ARM926EJ-S) (default)

$ ./i386-softmmu/qemu -machine \?|fgrep '(default)'
pc-0.14Standard PC (default)


I understand, this is clumsy. Will see if we can do better.


Is there a technical reason why type isn't optional with -machine?

[...]


Maybe it's just the

assert(!permit_abbrev || list->implied_opt_name);

in qemu_opts_parse, but I haven't looked at all details (and all other
users) yet.


I was incorrectly pointing the core, the problem is solvable at the
level where we parse -machine:

---8<

This allows to specify -machine options without setting an explicit
machine type. We will pick the default machine in this case. Requesting
the list of available machines is still possible via '-machine ?' e.g.

Signed-off-by: Jan Kiszka


Applied.  Thanks.

Regards,

Anthony Liguori


---
  vl.c |5 -
  1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/vl.c b/vl.c
index 8256504..5e53ddc 100644
--- a/vl.c
+++ b/vl.c
@@ -2720,7 +2720,10 @@ int main(int argc, char **argv, char **envp)
  fprintf(stderr, "parse error: %s\n", optarg);
  exit(1);
  }
-machine = machine_parse(qemu_opt_get(opts, "type"));
+optarg = qemu_opt_get(opts, "type");
+if (optarg) {
+machine = machine_parse(optarg);
+}
  break;
  case QEMU_OPTION_usb:
  usb_enabled = 1;





Re: [Qemu-devel] [PATCH] CODING_STYLE: explicitly allow braceless 'else if'

2011-07-29 Thread Anthony Liguori

On 07/25/2011 10:55 AM, Avi Kivity wrote:

It's already allowed by the example; there are about 1800 instances in the
tree; and disallowing it would lead to

 if (a) {
 ...
 } else {
 if (b) {
 ...
 } else {
 if (c) {
 ...
 } else {
 if (d) {
 ...
 } else {
 ...
 }
 }
 }
 }

instead of

 if (a) {
 ...
 } else if (b) {
 ...
 } else if (c) {
 ...
 } else if (d) {
 ...
 } else {
 ...
 }

which is more readable.

Signed-off-by: Avi Kivity


Applied.  Thanks.

Regards,

Anthony Liguori


---
  CODING_STYLE |4 
  1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/CODING_STYLE b/CODING_STYLE
index 5ecfa22..6e61c49 100644
--- a/CODING_STYLE
+++ b/CODING_STYLE
@@ -68,6 +68,10 @@ keyword.  Example:
  printf("a was something else entirely.\n");
  }

+Note that 'else if' is considered a single statement; otherwise a long if/
+else if/else if/.../else sequence would need an indent for every else
+statement.
+
  An exception is the opening brace for a function; for reasons of tradition
  and clarity it comes on a line by itself:






Re: [Qemu-devel] [PATCH] configure: add --disable-zlib-test

2011-07-29 Thread Anthony Liguori

On 07/26/2011 04:30 AM, Alon Levy wrote:

This is required for building libcacard which doesn't itself require
zlib without bringing in this requirement to the build environment.

Signed-off-by: Alon Levy


Applied.  Thanks.

Regards,

Anthony Liguori


---
I'd like this to go into 0.15.0 too, it makes building libcacard possible
without zlib-devel being installed.
---
  configure |   23 ++-
  1 files changed, 14 insertions(+), 9 deletions(-)

diff --git a/configure b/configure
index 88159ac..5fc0f82 100755
--- a/configure
+++ b/configure
@@ -178,6 +178,7 @@ rbd=""
  smartcard=""
  smartcard_nss=""
  opengl=""
+zlib="yes"

  # parse CC options first
  for opt do
@@ -743,6 +744,8 @@ for opt do
;;
--enable-smartcard-nss) smartcard_nss="yes"
;;
+  --disable-zlib-test) zlib="no"
+  ;;
*) echo "ERROR: unknown option $opt"; show_help="yes"
;;
esac
@@ -1172,18 +1175,20 @@ fi
  ##
  # zlib check

-cat>  $TMPC<<  EOF
+if test "$zlib" != "no" ; then
+cat>  $TMPC<<  EOF
  #include
  int main(void) { zlibVersion(); return 0; }
  EOF
-if compile_prog "" "-lz" ; then
-:
-else
-echo
-echo "Error: zlib check failed"
-echo "Make sure to have the zlib libs and headers installed."
-echo
-exit 1
+if compile_prog "" "-lz" ; then
+:
+else
+echo
+echo "Error: zlib check failed"
+echo "Make sure to have the zlib libs and headers installed."
+echo
+exit 1
+fi
  fi

  ##





Re: [Qemu-devel] [PATCH] Fix a compilation error in xen-mapcache.c

2011-07-29 Thread Anthony Liguori

On 07/26/2011 09:33 AM, Stefan Berger wrote:

This patch fixes a compilation error in xen-mapcache.c .

/home/stefanb/qemu/qemu-git/xen-mapcache.c: In function 
‘xen_ram_addr_from_mapcache’:
/home/stefanb/qemu/qemu-git/xen-mapcache.c:240:42: error: variable ‘pentry’ set 
but not used [-Werror=unused-but-set-variable]
cc1: all warnings being treated as errors

Signed-off-by: Stefan Berger


Applied.  Thanks.

Regards,

Anthony Liguori



---
  xen-mapcache.c |3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

Index: qemu-git/xen-mapcache.c
===
--- qemu-git.orig/xen-mapcache.c
+++ qemu-git/xen-mapcache.c
@@ -237,7 +237,7 @@ uint8_t *xen_map_cache(target_phys_addr_

  ram_addr_t xen_ram_addr_from_mapcache(void *ptr)
  {
-MapCacheEntry *entry = NULL, *pentry = NULL;
+MapCacheEntry *entry = NULL;
  MapCacheRev *reventry;
  target_phys_addr_t paddr_index;
  target_phys_addr_t size;
@@ -263,7 +263,6 @@ ram_addr_t xen_ram_addr_from_mapcache(vo

  entry =&mapcache->entry[paddr_index % mapcache->nr_buckets];
  while (entry&&  (entry->paddr_index != paddr_index || entry->size != 
size)) {
-pentry = entry;
  entry = entry->next;
  }
  if (!entry) {








Re: [Qemu-devel] [PATCH] lm832x: Take DeviceState pointer in lm832x_key_event()

2011-07-29 Thread Peter Maydell
On 29 July 2011 15:31, Anthony Liguori  wrote:
> On 07/28/2011 09:47 AM, Peter Maydell wrote:
>>
>> Since lm832x has been qdev'ified, its users will generally
>> have a DeviceState pointer rather than an i2c_slave pointer,
>> so adjust lm832x_key_event's prototype to suit.
>>
>> This allows the n810 (its only user) to actually pass a correct
>> pointer to it rather than NULL. The effect is that we no longer
>> segfault when a key is pressed.
>>
>> Signed-off-by: Peter Maydell
>> ---
>> NB: this patch depends on the OMAP GPIO v2 patchset.
>
> Could you put together a pull request for these devices?

Sure. Do you want just the GPIO patches and this patch,
or shall I put the nand/onenand patches in too?

thanks
-- PMM



Re: [Qemu-devel] [RFC PATCH 0/4] Fix subsection ambiguity in the migration format

2011-07-29 Thread Paolo Bonzini

On 07/29/2011 03:14 PM, Anthony Liguori wrote:

I really hate the idea of changing the migration format moments before
the release.


So do I, but that's life.


Since subsections are optional, can't we take the offending subsections,
remove them, bump the section version numbers and make the fields required?


The bug happens when you migrate from 0.15 to 0.15, and 0.14 didn't have 
any subsection for that device.  This happens pretty much in all cases 
that were added to 0.15.  It quickly makes a bigger patch than this one, 
and actually one that's harder to review.  At least with this one things 
can only go _royally_ wrong, and any serious automated test would catch it.


Paolo



[Qemu-devel] [PATCH] MAINTAINERS: add entry for Xen

2011-07-29 Thread stefano.stabellini
From: Stefano Stabellini 

Signed-off-by: Stefano Stabellini 
---
 MAINTAINERS |   10 ++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 6115e4e..273a6a7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -143,6 +143,16 @@ L: k...@vger.kernel.org
 S: Supported
 F: target-i386/kvm.c
 
+Guest CPU Cores (Xen):
+--
+
+X86
+M: Stefano Stabellini 
+L: xen-de...@lists.xensource.com
+S: Supported
+F: xen-*
+F: */xen*
+
 ARM Machines
 
 Gumstix
-- 
1.7.2.3




Re: [Qemu-devel] [RFC PATCH 0/4] Fix subsection ambiguity in the migration format

2011-07-29 Thread Kevin Wolf
Am 29.07.2011 16:28, schrieb Anthony Liguori:
> On 07/29/2011 09:03 AM, Kevin Wolf wrote:
>> Am 26.07.2011 14:37, schrieb Anthony Liguori:
>>> Hrm, I'm not sure I agree with these conclusions.
>>>
>>> Management tools should do their best job to create two compatible
>>> device models.
>>>
>>> Given two compatible device models, there *may* be differences in the
>>> structure of the device models since we evolve things over time.  We may
>>> rename a field, change the type, etc.  To support this, we can use
>>> filters both on the destination and receive end to do our best to
>>> massage the device model into something compatible.
>>>
>>> But creating two creating compatible device models is not the job of the
>>> migration protocol.  It's the job of management tools.
>>
>> I'm not sure if I agree with this.
>>
>> Let's forget about management tools for a moment, and just think of a
>> qemu instance with a given set of command line option describing its
>> devices. Then you start another instance with different options and
>> -incoming and start a migration. The result will be something, but
>> definitely not a successfully migrated VM (even though it might look
>> like one at first).
>>
>> This is why I believe that the information about which devices to use
>> actually belongs into the migration data. There's no way to make use of
>> it with different options.
> 
> I agree with you actually.
> 
> Right now, it's the management tools job.  The complexity is daunting. 
> Recreating the same object model, particularly after hotplug, is 
> difficult and in many cases impossible.
> 
> I think the primary problem is that there are so many ways to create 
> things.  -M pc creates a bunch of stuff that there's no way to create 
> individually.  The stuff it creates can sort of be manipulated by using 
> -global but not on a per device basis.  Much of it isn't even addressable.
> 
> Creating backends is a totally different mechanism and each backend has 
> different mechanisms to enumerate and create.

And backends are actually something totally different: They are the part
that you can't migrate automatically, but that you must create on the
destination host like we're doing it today. The paths to images etc.
could be completely different from the source host.

The one change for backends is that if we migrate a device in way so
that it can say "I need the block backend with the ID 'foo'", then we
can at least make sure that the backend actually exists and is usable.

> The result is that introspecting what's there and recreating it is 
> insanely complex today.
> 
> That's the motivation behind QOM.  plug_list lists *everything*.  All 
> objects, whether they are created as part of the PIIX3 or whether it's a 
> backing file, can be directly addressed and manipulated.
> 
> If you look at qsh, there's an import command.  The export command is 
> trivial and I don't remember if I've already added it.  But the point is 
> that you should be able to 'qsh export' everything and then 'qsh import' 
> everything to create the exact same device model in another QEMU instance.
> 
> And yeah, this should end up becoming part of the migration protocol.

If all you're saying is that we can't get it tomorrow, that's fine for
me. Good to know that we agree on the goal anyway.

> 5) Once we're here, we can implement the next 5-year format.  That
> could be ASN.1 and be bidirectional or whatever makes the most sense.
> We could support 50 formats if we wanted to.  As long as the transport
> is distinct from the serialization and compat routines, it really
> doesn't matter.

 This means finishing the VMState support, once there, only thing needs
 to change is "copy" the savevm, and change the "visitors" to whatever
 else that we need/want.
>>>
>>> There's no need to "finish" VMState to convert to visitors.  It's just
>>> sed -e 's:qemu_put_be32:visit_type_int32:g'
>>
>> Actually I think the real question is whether we want to have VMState or
>> not.
> 
> VMState doesn't give me what I want by itself.
> 
> I want to be able to marshal the device tree to an in-memory 
> representation that can be manipulated.  One approach to doing that is 
> first completing VMState, and then writing something that can walk the 
> VMState descriptions.  The VMState descriptions are fairly complicated 
> but it's doable.
> 
> Another approach, which I'm arguing is much simpler, the imperative 
> nature of our current serialization and use visitors.
> 
> There may be other advantages of a declarative description of VMState 
> that would justify completing the conversions.  But I don't think we 
> need it to start improving the migration protocol.

Yeah, I somehow read it as "there's no reason to continue with
converting to VMState", which isn't what you were saying.

Kevin



Re: [Qemu-devel] Bug#632192: [PATCH] add QEMU_LD_PREFIX environment variable

2011-07-29 Thread Johannes Schauer
On Fri, Jul 29, 2011 at 05:52:50AM -0700, Vagrant Cascadian wrote:
> setting up a wrapper makes trivial cross-architecture chroots harder
> as you'll have to copy two binaries into the chroot, and i'm not sure
> if it would work at all, as the wrapper will need to somehow emulate
> it's own interpreter...

Agreed - this makes a wrapper not an option. I didnt think of that.

> > Alternatively we should have a generic setup for mapping enviroment
> > variables to command line options. Now we get special per-option
> > code every time someone needs to setup a command line option from
> > binfmt.
> 
> this would seem a bit better alternative to me...

So if we agree on using environment variables to pass options to
qemu-user we next need to agree on how to name the options.

The following commandline arguments exist (in order as they are checked
in linux-user/main.c) and I shortly described and proposed a name for
the environment variable in the same line.

-d (activate log) - QEMU_LOG
-D (logfile)  - QEMU_LOGFILE
-E (set target env variabe)   - QEMU_SET_ENV
-U (unset target env variabe) - QEMU_UNSET_ENV
-0 (set target argv[0])   - QEMU_ARGV0
-s (stack size)   - QEMU_STACK_SIZE
-L (elf interpreter prefix)   - QEMU_LD_PREFIX
-p (page size)- QEMU_PAGESIZE
-g (listen for gdb on port)   - QEMU_GDB
-r (uname)- QEMU_UNAME
-cpu (cpu model)  - QEMU_CPU
-B (guest base)   - QEMU_GUEST_BASE
-R (reserved virtual address) - QEMU_RESERVED_VA
-drop-ld-preload  - QEMU_DROP_LD_PRELOAD
-singlestep   - QEMU_SINGLESTEP
-strace   - QEMU_STRACE

also, there already is the QEMU_STRACE environment variable which could
be incorporated into the solution?

the -E and -U options can be specified several times so the environment
variables should be able to receive a list - maybe in the getsubopt(3)
style?

So what do you think?

cheers, josch



Re: [Qemu-devel] [PATCH -V2] coroutine: Add CoRwlock support

2011-07-29 Thread Kevin Wolf
Am 29.07.2011 16:24, schrieb Aneesh Kumar K.V:
> On Fri, 29 Jul 2011 14:53:14 +0200, Kevin Wolf  wrote:
>> Am 27.07.2011 18:21, schrieb Aneesh Kumar K.V:
>>> Signed-off-by: Aneesh Kumar K.V 
>>> ---
>>>  qemu-coroutine-lock.c |   44 
>>>  qemu-coroutine.h  |   12 
>>>  2 files changed, 56 insertions(+), 0 deletions(-)
>>
>> Looks good to me.
>>
>> What's your plan with getting this merged? Are you going to just include
>> it with another series that you'll send once the basic coroutine support
>> is in?
> 
> Since the patch already is dependent on CoQueue, it would be nice if you
> can push it through your tree. I will stage the dependent VirtFS patch
> after that get merged upstream.

Okay, I applied it to my branch so that I won't forget about it, but
while merging I noticed two things that you could fix: The patch adds an
#include "qemu-thread.h" to qemu-coroutine.h for apparently no reason,
and it would be nice to have comments in qemu-coroutine.h like all other
functions have.

Kevin



Re: [Qemu-devel] [PATCH 1/2] linux aio: support flush operation

2011-07-29 Thread Stefan Hajnoczi
On Thu, Jul 28, 2011 at 1:15 PM, Christoph Hellwig  wrote:
> On Thu, Jul 28, 2011 at 09:47:05AM +0200, Kevin Wolf wrote:
>> > Indeed.  This has come up a few times, and actually is a mostly trivial
>> > task.  Maybe we should give up waiting for -blockdev and separate cache
>> > mode settings and allow a nocache-writethrough or similar mode now?  It's
>> > going to be around 10 lines of code + documentation.
>>
>> I understand that there may be reasons for using O_DIRECT | O_DSYNC, but
>> what is the explanation for O_DSYNC improving performance?
>
> There isn't any, at least for modern Linux.  O_DSYNC at this point is
> equivalent to a range fdatasync for each write call, and given that we're
> doing O_DIRECT the ranges flush doesn't matter.  If you do have a modern
> host and an old guest it might end up beeing faster because the barrier
> implementation in Linux used to suck so badly, but that's not inhrent
> to the I/O model.  If you guest however doesn't support cache flushes
> at all O_DIRECT | O_DSYNC is the only sane model to use for local filesystems
> and block devices.

I can rebase this cache=directsync patch and send it:
http://repo.or.cz/w/qemu/stefanha.git/commitdiff/6756719a46ac9876ac6d0460a33ad98e96a3a923

The other weird caching-related option I was playing with is -drive
...,readahead=on|off.  It lets you disable the host kernel readahead
on buffered modes (cache=writeback|writethrough):
http://repo.or.cz/w/qemu/stefanha.git/commitdiff/f2fc2b297a2b2dd0cccd1dc2f7c519f3b0374e0d

Stefan



[Qemu-devel] [PATCH v2 0.15 1/4] add support for machine models to specify their migration format

2011-07-29 Thread Paolo Bonzini
We need to provide a new migration format, and not break migration
in old machine models.  So add a migration_format field to QEMUMachine.

Signed-off-by: Paolo Bonzini 
---
 cpu-common.h  |3 ---
 hw/boards.h   |1 +
 qemu-common.h |3 +++
 savevm.c  |   16 ++--
 4 files changed, 18 insertions(+), 5 deletions(-)

diff --git a/cpu-common.h b/cpu-common.h
index 44b04b3..8c61b18 100644
--- a/cpu-common.h
+++ b/cpu-common.h
@@ -26,9 +26,6 @@ enum device_endian {
 DEVICE_LITTLE_ENDIAN,
 };
 
-/* address in the RAM (different from a physical address) */
-typedef unsigned long ram_addr_t;
-
 /* memory API */
 
 typedef void CPUWriteMemoryFunc(void *opaque, target_phys_addr_t addr, 
uint32_t value);
diff --git a/hw/boards.h b/hw/boards.h
index 716fd7b..560dbaf 100644
--- a/hw/boards.h
+++ b/hw/boards.h
@@ -19,6 +19,7 @@ typedef struct QEMUMachine {
 QEMUMachineInitFunc *init;
 int use_scsi;
 int max_cpus;
+unsigned migration_format;
 unsigned int no_serial:1,
 no_parallel:1,
 use_virtcon:1,
diff --git a/qemu-common.h b/qemu-common.h
index ba55719..24330be 100644
--- a/qemu-common.h
+++ b/qemu-common.h
@@ -91,6 +91,9 @@ static inline char *realpath(const char *path, char 
*resolved_path)
 }
 #endif
 
+/* address in the RAM (different from a physical address) */
+typedef unsigned long ram_addr_t;
+
 /* FIXME: Remove NEED_CPU_H.  */
 #ifndef NEED_CPU_H
 
diff --git a/savevm.c b/savevm.c
index 8139bc7..3049aa1 100644
--- a/savevm.c
+++ b/savevm.c
@@ -72,6 +72,7 @@
 #include "qemu-common.h"
 #include "hw/hw.h"
 #include "hw/qdev.h"
+#include "hw/boards.h"
 #include "net.h"
 #include "monitor.h"
 #include "sysemu.h"
@@ -1461,6 +1462,16 @@ bool qemu_savevm_state_blocked(Monitor *mon)
 return false;
 }
 
+static inline int qemu_current_migration_format(void)
+{
+if (current_machine->migration_format) {
+return current_machine->migration_format;
+}
+
+/* No format specified, default to the latest.  */
+return QEMU_VM_FILE_VERSION;
+}
+
 int qemu_savevm_state_begin(Monitor *mon, QEMUFile *f, int blk_enable,
 int shared)
 {
@@ -1474,7 +1484,7 @@ int qemu_savevm_state_begin(Monitor *mon, QEMUFile *f, 
int blk_enable,
 }
 
 qemu_put_be32(f, QEMU_VM_FILE_MAGIC);
-qemu_put_be32(f, QEMU_VM_FILE_VERSION);
+qemu_put_be32(f, qemu_current_migration_format());
 
 QTAILQ_FOREACH(se, &savevm_handlers, entry) {
 int len;
@@ -1747,8 +1757,10 @@ int qemu_loadvm_state(QEMUFile *f)
 fprintf(stderr, "SaveVM v2 format is obsolete and don't work 
anymore\n");
 return -ENOTSUP;
 }
-if (v != QEMU_VM_FILE_VERSION)
+if (v != qemu_current_migration_format()) {
+fprintf(stderr, "Mismatching SaveVM format v%d\n", v);
 return -ENOTSUP;
+}
 
 while ((section_type = qemu_get_byte(f)) != QEMU_VM_EOF) {
 uint32_t instance_id, version_id, section_id;
-- 
1.7.6





[Qemu-devel] [PATCH v2 0.15 0/4] Fix subsection ambiguity in the migration format

2011-07-29 Thread Paolo Bonzini
With the current migration format, VMS_STRUCTs with subsections
are ambiguous.  The protocol cannot tell whether a 0x5 byte after
the VMS_STRUCT is a subsection or part of the parent data stream.
In the past QEMU assumed it was always a part of a subsection; after
commit eb60260 (savevm: fix corruption in vmstate_subsection_load(),
2011-02-03) the choice depends on whether the VMS_STRUCT has subsections
defined.

Unfortunately, this means that if a destination has no subsections
defined for the struct, it will happily read subsection data into
its own fields.  And if you are "lucky" enough to stumble on a
zero byte at the right time, it will be interpreted as QEMU_VM_EOF
and migration will be interrupted with half-loaded state.

There is no way out of this except defining an incompatible
migration protocol.  Not-so-long-term we should really try to define
one that is not a joke, but the bug is serious so we need a solution
for 0.15.  A sentinel at the end of embedded structs does remove the
ambiguity.

Of course, this can be restricted to new machine models, and this
is what the patch series does.  (And note that only patch 3 is specific
to the short-term solution, everything else is entirely generic).

I am still proposing this for 0.15.  Tested new on new, 0.14 on new
pc-0.14, new pc-0.14 on 0.14; also for v1 the same combinations on RHEL.

v1->v2:
added qemu_current_migration_format() and
QEMU_VM_FILE_VERSION_0_14.

Paolo Bonzini (4):
  add support for machine models to specify their migration format
  add pc-0.14 machine
  savevm: define new unambiguous migration format
  Partially revert "savevm: fix corruption in
vmstate_subsection_load()."

 cpu-common.h  |3 ---
 hw/boards.h   |4 
 hw/pc_piix.c  |   15 ++-
 qemu-common.h |3 +++
 savevm.c  |   46 --
 5 files changed, 53 insertions(+), 18 deletions(-)

-- 
1.7.6




[Qemu-devel] [PATCH v2 0.15 3/4] savevm: define new unambiguous migration format

2011-07-29 Thread Paolo Bonzini
With the current migration format, VMS_STRUCTs with subsections
are ambiguous.  The protocol cannot tell whether a 0x5 byte after
the VMS_STRUCT is a subsection or part of the parent data stream.
In the past QEMU assumed it was always a part of a subsection; after
commit eb60260 (savevm: fix corruption in vmstate_subsection_load().,
2011-02-03) the choice depends on whether the VMS_STRUCT has subsections
defined.

Unfortunately, this means that if a destination has no subsections
defined for the struct, it will happily read subsection data into
its own fields.  And if you are "lucky" enough to stumble on a
zero byte at the right time, it will be interpreted as QEMU_VM_EOF
and migration will be interrupted.

There is no way out of this except defining an incompatible
migration protocol with a sentinel at the end of embedded structs.
Of course, this is restricted to new machine models.

Signed-off-by: Paolo Bonzini 
---
 hw/boards.h  |3 +++
 hw/pc_piix.c |5 +
 savevm.c |   26 ++
 3 files changed, 26 insertions(+), 8 deletions(-)

diff --git a/hw/boards.h b/hw/boards.h
index 560dbaf..1cca3ce 100644
--- a/hw/boards.h
+++ b/hw/boards.h
@@ -5,6 +5,9 @@
 
 #include "qdev.h"
 
+#define QEMU_VM_FILE_VERSION_0_140x0003
+#define QEMU_VM_FILE_VERSION 0x0004
+
 typedef void QEMUMachineInitFunc(ram_addr_t ram_size,
  const char *boot_device,
  const char *kernel_filename,
diff --git a/hw/pc_piix.c b/hw/pc_piix.c
index 61f8cbb..38818de 100644
--- a/hw/pc_piix.c
+++ b/hw/pc_piix.c
@@ -271,6 +271,7 @@ static QEMUMachine pc_machine_v0_14 = {
 .desc = "Standard PC",
 .init = pc_init_pci,
 .max_cpus = 255,
+.migration_format = QEMU_VM_FILE_VERSION_0_14,
 };
 
 static QEMUMachine pc_machine_v0_13 = {
@@ -278,6 +279,7 @@ static QEMUMachine pc_machine_v0_13 = {
 .desc = "Standard PC",
 .init = pc_init_pci_no_kvmclock,
 .max_cpus = 255,
+.migration_format = QEMU_VM_FILE_VERSION_0_14,
 .compat_props = (GlobalProperty[]) {
 {
 .driver   = "virtio-9p-pci",
@@ -317,6 +319,7 @@ static QEMUMachine pc_machine_v0_12 = {
 .desc = "Standard PC",
 .init = pc_init_pci_no_kvmclock,
 .max_cpus = 255,
+.migration_format = QEMU_VM_FILE_VERSION_0_14,
 .compat_props = (GlobalProperty[]) {
 {
 .driver   = "virtio-serial-pci",
@@ -360,6 +363,7 @@ static QEMUMachine pc_machine_v0_11 = {
 .desc = "Standard PC, qemu 0.11",
 .init = pc_init_pci_no_kvmclock,
 .max_cpus = 255,
+.migration_format = QEMU_VM_FILE_VERSION_0_14,
 .compat_props = (GlobalProperty[]) {
 {
 .driver   = "virtio-blk-pci",
@@ -411,6 +415,7 @@ static QEMUMachine pc_machine_v0_10 = {
 .desc = "Standard PC, qemu 0.10",
 .init = pc_init_pci_no_kvmclock,
 .max_cpus = 255,
+.migration_format = QEMU_VM_FILE_VERSION_0_14,
 .compat_props = (GlobalProperty[]) {
 {
 .driver   = "virtio-blk-pci",
diff --git a/savevm.c b/savevm.c
index 3049aa1..197af4b 100644
--- a/savevm.c
+++ b/savevm.c
@@ -158,6 +158,14 @@ void qemu_announce_self(void)
 
 #define IO_BUF_SIZE 32768
 
+#define QEMU_VM_EOF  0x00
+#define QEMU_VM_SECTION_START0x01
+#define QEMU_VM_SECTION_PART 0x02
+#define QEMU_VM_SECTION_END  0x03
+#define QEMU_VM_SECTION_FULL 0x04
+#define QEMU_VM_SUBSECTION   0x05
+#define QEMU_VM_SUBSECTIONS_END  0x06
+
 struct QEMUFile {
 QEMUFilePutBufferFunc *put_buffer;
 QEMUFileGetBufferFunc *get_buffer;
@@ -1348,6 +1356,12 @@ int vmstate_load_state(QEMUFile *f, const 
VMStateDescription *vmsd,
 }
 if (field->flags & VMS_STRUCT) {
 ret = vmstate_load_state(f, field->vmsd, addr, 
field->vmsd->version_id);
+if (!current_machine->migration_format ||
+current_machine->migration_format >= 4) {
+if (qemu_get_byte(f) != QEMU_VM_SUBSECTIONS_END) {
+return -EINVAL;
+}
+}
 } else {
 ret = field->info->get(f, addr, size);
 
@@ -1410,6 +1424,10 @@ void vmstate_save_state(QEMUFile *f, const 
VMStateDescription *vmsd,
 }
 if (field->flags & VMS_STRUCT) {
 vmstate_save_state(f, field->vmsd, addr);
+if (!current_machine->migration_format ||
+current_machine->migration_format >= 4) {
+qemu_put_byte(f, QEMU_VM_SUBSECTIONS_END);
+}
 } else {
 field->info->put(f, addr, size);
 }
@@ -1439,14 +1457,6 @@ static void vmstate_save(QEMUFile *f, SaveStateEntry *se)
 
 #define QEMU_VM_FILE_MAGIC   0x5145564d
 #define QEMU_VM_FILE_VERSION_COMPAT  0x000

[Qemu-devel] [PATCH v2 0.15 4/4] Partially revert "savevm: fix corruption in vmstate_subsection_load()."

2011-07-29 Thread Paolo Bonzini
This reverts the additional check in commit eb60260d (but not the
assertions).

The new format does not require the check, and with the old format
it traded one kind of bogus failure for a different kind of silent
failure.

Signed-off-by: Paolo Bonzini 
---
 savevm.c |4 
 1 files changed, 0 insertions(+), 4 deletions(-)

diff --git a/savevm.c b/savevm.c
index 197af4b..c849914 100644
--- a/savevm.c
+++ b/savevm.c
@@ -1687,10 +1687,6 @@ static int vmstate_subsection_load(QEMUFile *f, const 
VMStateDescription *vmsd,
 {
 const VMStateSubsection *sub = vmsd->subsections;
 
-if (!sub || !sub->needed) {
-return 0;
-}
-
 while (qemu_peek_byte(f) == QEMU_VM_SUBSECTION) {
 char idstr[256];
 int ret;
-- 
1.7.6




[Qemu-devel] [PATCH 10/15] hw/nand: Writing to NAND can only clear bits

2011-07-29 Thread Peter Maydell
Writing to a NAND device cannot set bits, it can only clear them;
implement this rather than simply copying the data.

Signed-off-by: Peter Maydell 
---
 hw/nand.c |   17 +
 1 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/hw/nand.c b/hw/nand.c
index e6c551d..d068eb6 100644
--- a/hw/nand.c
+++ b/hw/nand.c
@@ -75,6 +75,15 @@ struct NANDFlashState {
 uint32_t ioaddr_vmstate;
 };
 
+static void mem_and(uint8_t *dest, const uint8_t *src, size_t n)
+{
+/* Like memcpy() but we logical-AND the data into the destination */
+int i;
+for (i = 0; i < n; i++) {
+dest[i] &= src[i];
+}
+}
+
 # define NAND_NO_AUTOINCR  0x0001
 # define NAND_BUSWIDTH_16  0x0002
 # define NAND_NO_PADDING   0x0004
@@ -595,7 +604,7 @@ static void glue(nand_blk_write_, PAGE_SIZE)(NANDFlashState 
*s)
 return;
 
 if (!s->bdrv) {
-memcpy(s->storage + PAGE_START(s->addr) + (s->addr & PAGE_MASK) +
+mem_and(s->storage + PAGE_START(s->addr) + (s->addr & PAGE_MASK) +
 s->offset, s->io, s->iolen);
 } else if (s->mem_oob) {
 sector = SECTOR(s->addr);
@@ -606,10 +615,10 @@ static void glue(nand_blk_write_, 
PAGE_SIZE)(NANDFlashState *s)
 return;
 }
 
-memcpy(iobuf + (soff | off), s->io, MIN(s->iolen, PAGE_SIZE - off));
+mem_and(iobuf + (soff | off), s->io, MIN(s->iolen, PAGE_SIZE - off));
 if (off + s->iolen > PAGE_SIZE) {
 page = PAGE(s->addr);
-memcpy(s->storage + (page << OOB_SHIFT), s->io + PAGE_SIZE - off,
+mem_and(s->storage + (page << OOB_SHIFT), s->io + PAGE_SIZE - off,
 MIN(OOB_SIZE, off + s->iolen - PAGE_SIZE));
 }
 
@@ -624,7 +633,7 @@ static void glue(nand_blk_write_, PAGE_SIZE)(NANDFlashState 
*s)
 return;
 }
 
-memcpy(iobuf + soff, s->io, s->iolen);
+mem_and(iobuf + soff, s->io, s->iolen);
 
 if (bdrv_write(s->bdrv, sector, iobuf, PAGE_SECTORS + 2) == -1)
 printf("%s: write error in sector %" PRIu64 "\n", __func__, 
sector);
-- 
1.7.1




[Qemu-devel] [PATCH 14/15] onenand: Ignore zero writes to boot command space

2011-07-29 Thread Peter Maydell
From: Juha Riihimäki 

Ignore zero writes to the boot command space; Linux will issue
these in the powerdown/reset sequence.

Signed-off-by: Juha Riihimäki 
[Riku Voipio: Fixes and restructuring patchset]
Signed-off-by: Riku Voipio 
[Peter Maydell: More fixes and cleanups for upstream submission]
Signed-off-by:  Peter Maydell 
---
 hw/onenand.c |7 +++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/hw/onenand.c b/hw/onenand.c
index 9f02736..0edcfe2 100644
--- a/hw/onenand.c
+++ b/hw/onenand.c
@@ -550,6 +550,13 @@ static void onenand_write(void *opaque, target_phys_addr_t 
addr,
 s->boot[0][2 << s->shift] = s->wpstatus & 0xff;
 break;
 
+case 0x:
+/* ignore zero writes without error messages,
+ * linux omap2/3 kernel will issue these upon
+ * powerdown/reset sequence.
+ */
+break;
+
 default:
 fprintf(stderr, "%s: unknown OneNAND boot command %x\n",
 __FUNCTION__, value);
-- 
1.7.1




[Qemu-devel] [PATCH 06/15] hw/nand: Pass block device state to init function

2011-07-29 Thread Peter Maydell
Pass the BlockDeviceState to the nand_init() function rather
than having it look it up via drive_get() itself.

Signed-off-by: Peter Maydell 
---
 hw/axis_dev88.c |6 +-
 hw/flash.h  |2 +-
 hw/nand.c   |8 ++--
 hw/spitz.c  |4 +++-
 hw/tc6393xb.c   |5 -
 5 files changed, 15 insertions(+), 10 deletions(-)

diff --git a/hw/axis_dev88.c b/hw/axis_dev88.c
index 0e2135a..de1f5a5 100644
--- a/hw/axis_dev88.c
+++ b/hw/axis_dev88.c
@@ -30,6 +30,7 @@
 #include "loader.h"
 #include "elf.h"
 #include "cris-boot.h"
+#include "blockdev.h"
 
 #define D(x)
 #define DNAND(x)
@@ -251,6 +252,7 @@ void axisdev88_init (ram_addr_t ram_size,
 CPUState *env;
 DeviceState *dev;
 SysBusDevice *s;
+DriveInfo *nand;
 qemu_irq irq[30], nmi[2], *cpu_irq;
 void *etraxfs_dmac;
 struct etraxfs_dma_client *eth[2] = {NULL, NULL};
@@ -278,7 +280,9 @@ void axisdev88_init (ram_addr_t ram_size,
 
 
   /* Attach a NAND flash to CS1.  */
-nand_state.nand = nand_init(NAND_MFR_STMICRO, 0x39);
+nand = drive_get(IF_MTD, 0, 0);
+nand_state.nand = nand_init(nand ? nand->bdrv : NULL,
+NAND_MFR_STMICRO, 0x39);
 nand_regs = cpu_register_io_memory(nand_read, nand_write, &nand_state,
DEVICE_NATIVE_ENDIAN);
 cpu_register_physical_memory(0x1000, 0x0500, nand_regs);
diff --git a/hw/flash.h b/hw/flash.h
index c22e1a9..a992bb8 100644
--- a/hw/flash.h
+++ b/hw/flash.h
@@ -19,7 +19,7 @@ pflash_t *pflash_cfi02_register(target_phys_addr_t base, 
ram_addr_t off,
 
 /* nand.c */
 typedef struct NANDFlashState NANDFlashState;
-NANDFlashState *nand_init(int manf_id, int chip_id);
+NANDFlashState *nand_init(BlockDriverState *bdrv, int manf_id, int chip_id);
 void nand_done(NANDFlashState *s);
 void nand_setpins(NANDFlashState *s, uint8_t cle, uint8_t ale,
   uint8_t ce, uint8_t wp, uint8_t gnd);
diff --git a/hw/nand.c b/hw/nand.c
index 37e51d7..d6204d9 100644
--- a/hw/nand.c
+++ b/hw/nand.c
@@ -14,7 +14,6 @@
 # include "hw.h"
 # include "flash.h"
 # include "blockdev.h"
-/* FIXME: Pass block device as an argument.  */
 
 # define NAND_CMD_READ00x00
 # define NAND_CMD_READ10x01
@@ -451,20 +450,17 @@ uint8_t nand_getio(NANDFlashState *s)
 return *(s->ioaddr ++);
 }
 
-NANDFlashState *nand_init(int manf_id, int chip_id)
+NANDFlashState *nand_init(BlockDriverState *bdrv, int manf_id, int chip_id)
 {
 int pagesize;
 NANDFlashState *s;
-DriveInfo *dinfo;
 
 if (nand_flash_ids[chip_id].size == 0) {
 hw_error("%s: Unsupported NAND chip ID.\n", __FUNCTION__);
 }
 
 s = (NANDFlashState *) qemu_mallocz(sizeof(NANDFlashState));
-dinfo = drive_get(IF_MTD, 0, 0);
-if (dinfo)
-s->bdrv = dinfo->bdrv;
+s->bdrv = bdrv;
 s->manf_id = manf_id;
 s->chip_id = chip_id;
 s->size = nand_flash_ids[s->chip_id].size << 20;
diff --git a/hw/spitz.c b/hw/spitz.c
index 006f7a9..78e9c34 100644
--- a/hw/spitz.c
+++ b/hw/spitz.c
@@ -169,11 +169,13 @@ static void sl_flash_register(PXA2xxState *cpu, int size)
 static int sl_nand_init(SysBusDevice *dev) {
 int iomemtype;
 SLNANDState *s;
+DriveInfo *nand;
 
 s = FROM_SYSBUS(SLNANDState, dev);
 
 s->ctl = 0;
-s->nand = nand_init(s->manf_id, s->chip_id);
+nand = drive_get(IF_MTD, 0, 0);
+s->nand = nand_init(nand ? nand->bdrv : NULL, s->manf_id, s->chip_id);
 
 iomemtype = cpu_register_io_memory(sl_readfn,
 sl_writefn, s, DEVICE_NATIVE_ENDIAN);
diff --git a/hw/tc6393xb.c b/hw/tc6393xb.c
index ed49e94..4de0819 100644
--- a/hw/tc6393xb.c
+++ b/hw/tc6393xb.c
@@ -12,6 +12,7 @@
 #include "flash.h"
 #include "console.h"
 #include "pixel_ops.h"
+#include "blockdev.h"
 
 #define IRQ_TC6393_NAND0
 #define IRQ_TC6393_MMC 1
@@ -566,6 +567,7 @@ TC6393xbState *tc6393xb_init(uint32_t base, qemu_irq irq)
 {
 int iomemtype;
 TC6393xbState *s;
+DriveInfo *nand;
 CPUReadMemoryFunc * const tc6393xb_readfn[] = {
 tc6393xb_readb,
 tc6393xb_readw,
@@ -586,7 +588,8 @@ TC6393xbState *tc6393xb_init(uint32_t base, qemu_irq irq)
 
 s->sub_irqs = qemu_allocate_irqs(tc6393xb_sub_irq, s, TC6393XB_NR_IRQS);
 
-s->flash = nand_init(NAND_MFR_TOSHIBA, 0x76);
+nand = drive_get(IF_MTD, 0, 0);
+s->flash = nand_init(nand ? nand->bdrv : NULL, NAND_MFR_TOSHIBA, 0x76);
 
 iomemtype = cpu_register_io_memory(tc6393xb_readfn,
 tc6393xb_writefn, s, DEVICE_NATIVE_ENDIAN);
-- 
1.7.1




[Qemu-devel] [PATCH 04/15] hw/omap_gpio.c: Convert to qdev

2011-07-29 Thread Peter Maydell
From: Juha Riihimäki 

Convert the OMAP GPIO module to qdev.

Signed-off-by: Juha Riihimäki 
[Riku Voipio: Fixes and restructuring patchset]
Signed-off-by: Riku Voipio 
[Peter Maydell: More fixes and cleanups for upstream submission]
Signed-off-by:  Peter Maydell 
---
 hw/nseries.c   |   47 +-
 hw/omap.h  |   20 +
 hw/omap1.c |   10 ++-
 hw/omap2.c |   34 ++--
 hw/omap_gpio.c |  259 ---
 hw/palm.c  |   26 +++---
 6 files changed, 220 insertions(+), 176 deletions(-)

diff --git a/hw/nseries.c b/hw/nseries.c
index 2f84f53..32f2f53 100644
--- a/hw/nseries.c
+++ b/hw/nseries.c
@@ -134,9 +134,9 @@ static void n800_mmc_cs_cb(void *opaque, int line, int 
level)
 static void n8x0_gpio_setup(struct n800_s *s)
 {
 qemu_irq *mmc_cs = qemu_allocate_irqs(n800_mmc_cs_cb, s->cpu->mmc, 1);
-omap2_gpio_out_set(s->cpu->gpif, N8X0_MMC_CS_GPIO, mmc_cs[0]);
+qdev_connect_gpio_out(s->cpu->gpio, N8X0_MMC_CS_GPIO, mmc_cs[0]);
 
-qemu_irq_lower(omap2_gpio_in_get(s->cpu->gpif, N800_BAT_COVER_GPIO)[0]);
+qemu_irq_lower(qdev_get_gpio_in(s->cpu->gpio, N800_BAT_COVER_GPIO));
 }
 
 #define MAEMO_CAL_HEADER(...)  \
@@ -168,8 +168,8 @@ static void n8x0_nand_setup(struct n800_s *s)
 omap_gpmc_attach(s->cpu->gpmc, N8X0_ONENAND_CS, 0, onenand_base_update,
 onenand_base_unmap,
 (s->nand = onenand_init(0xec4800, 1,
-omap2_gpio_in_get(s->cpu->gpif,
-N8X0_ONENAND_GPIO)[0])));
+qdev_get_gpio_in(s->cpu->gpio,
+N8X0_ONENAND_GPIO;
 otp_region = onenand_raw_otp(s->nand);
 
 memcpy(otp_region + 0x000, n8x0_cal_wlan_mac, sizeof(n8x0_cal_wlan_mac));
@@ -180,7 +180,7 @@ static void n8x0_nand_setup(struct n800_s *s)
 static void n8x0_i2c_setup(struct n800_s *s)
 {
 DeviceState *dev;
-qemu_irq tmp_irq = omap2_gpio_in_get(s->cpu->gpif, N8X0_TMP105_GPIO)[0];
+qemu_irq tmp_irq = qdev_get_gpio_in(s->cpu->gpio, N8X0_TMP105_GPIO);
 
 /* Attach the CPU on one end of our I2C bus.  */
 s->i2c = omap_i2c_bus(s->cpu->i2c[0]);
@@ -249,8 +249,8 @@ static void n800_tsc_kbd_setup(struct n800_s *s)
 /* XXX: are the three pins inverted inside the chip between the
  * tsc and the cpu (N4111)?  */
 qemu_irq penirq = NULL;/* NC */
-qemu_irq kbirq = omap2_gpio_in_get(s->cpu->gpif, N800_TSC_KP_IRQ_GPIO)[0];
-qemu_irq dav = omap2_gpio_in_get(s->cpu->gpif, N800_TSC_TS_GPIO)[0];
+qemu_irq kbirq = qdev_get_gpio_in(s->cpu->gpio, N800_TSC_KP_IRQ_GPIO);
+qemu_irq dav = qdev_get_gpio_in(s->cpu->gpio, N800_TSC_TS_GPIO);
 
 s->ts.chip = tsc2301_init(penirq, kbirq, dav);
 s->ts.opaque = s->ts.chip->opaque;
@@ -269,7 +269,7 @@ static void n800_tsc_kbd_setup(struct n800_s *s)
 
 static void n810_tsc_setup(struct n800_s *s)
 {
-qemu_irq pintdav = omap2_gpio_in_get(s->cpu->gpif, N810_TSC_TS_GPIO)[0];
+qemu_irq pintdav = qdev_get_gpio_in(s->cpu->gpio, N810_TSC_TS_GPIO);
 
 s->ts.opaque = tsc2005_init(pintdav);
 s->ts.txrx = tsc2005_txrx;
@@ -361,7 +361,7 @@ static int n810_keys[0x80] = {
 
 static void n810_kbd_setup(struct n800_s *s)
 {
-qemu_irq kbd_irq = omap2_gpio_in_get(s->cpu->gpif, N810_KEYBOARD_GPIO)[0];
+qemu_irq kbd_irq = qdev_get_gpio_in(s->cpu->gpio, N810_KEYBOARD_GPIO);
 DeviceState *dev;
 int i;
 
@@ -726,15 +726,15 @@ static void n8x0_dss_setup(struct n800_s *s)
 
 static void n8x0_cbus_setup(struct n800_s *s)
 {
-qemu_irq dat_out = omap2_gpio_in_get(s->cpu->gpif, N8X0_CBUS_DAT_GPIO)[0];
-qemu_irq retu_irq = omap2_gpio_in_get(s->cpu->gpif, N8X0_RETU_GPIO)[0];
-qemu_irq tahvo_irq = omap2_gpio_in_get(s->cpu->gpif, N8X0_TAHVO_GPIO)[0];
+qemu_irq dat_out = qdev_get_gpio_in(s->cpu->gpio, N8X0_CBUS_DAT_GPIO);
+qemu_irq retu_irq = qdev_get_gpio_in(s->cpu->gpio, N8X0_RETU_GPIO);
+qemu_irq tahvo_irq = qdev_get_gpio_in(s->cpu->gpio, N8X0_TAHVO_GPIO);
 
 CBus *cbus = cbus_init(dat_out);
 
-omap2_gpio_out_set(s->cpu->gpif, N8X0_CBUS_CLK_GPIO, cbus->clk);
-omap2_gpio_out_set(s->cpu->gpif, N8X0_CBUS_DAT_GPIO, cbus->dat);
-omap2_gpio_out_set(s->cpu->gpif, N8X0_CBUS_SEL_GPIO, cbus->sel);
+qdev_connect_gpio_out(s->cpu->gpio, N8X0_CBUS_CLK_GPIO, cbus->clk);
+qdev_connect_gpio_out(s->cpu->gpio, N8X0_CBUS_DAT_GPIO, cbus->dat);
+qdev_connect_gpio_out(s->cpu->gpio, N8X0_CBUS_SEL_GPIO, cbus->sel);
 
 cbus_attach(cbus, s->retu = retu_init(retu_irq, 1));
 cbus_attach(cbus, s->tahvo = tahvo_init(tahvo_irq, 1));
@@ -743,13 +743,12 @@ static void n8x0_cbus_setup(struct n800_s *s)
 static void n8x0_uart_setup(struct n800_s *s)
 {
 CharDriverState *radio = uart_hci_init(
-omap2_gpio_in_get(s->cpu->gpif,
-N8X0_BT_HOST_WKUP_GPIO)[0]);
+ 

[Qemu-devel] [PATCH 07/15] hw/nand: Support large NAND devices

2011-07-29 Thread Peter Maydell
From: Juha Riihimäki 

Add support for NAND devices of over 1Gb.

Signed-off-by: Juha Riihimäki 
[Riku Voipio: Fixes and restructuring patchset]
Signed-off-by: Riku Voipio 
[Peter Maydell: More fixes and cleanups for upstream submission]
Signed-off-by:  Peter Maydell 
---
 hw/nand.c |   48 +++-
 1 files changed, 27 insertions(+), 21 deletions(-)

diff --git a/hw/nand.c b/hw/nand.c
index d6204d9..18aa226 100644
--- a/hw/nand.c
+++ b/hw/nand.c
@@ -6,6 +6,10 @@
  * Copyright (c) 2006 Openedhand Ltd.
  * Written by Andrzej Zaborowski 
  *
+ * Support for additional features based on "MT29F2G16ABCWP 2Gx16"
+ * datasheet from Micron Technology and "NAND02G-B2C" datasheet
+ * from ST Microelectronics.
+ *
  * This code is licensed under the GNU GPL v2.
  */
 
@@ -57,14 +61,15 @@ struct NANDFlashState {
 uint8_t *ioaddr;
 int iolen;
 
-uint32_t cmd, addr;
+uint32_t cmd;
+uint64_t addr;
 int addrlen;
 int status;
 int offset;
 
 void (*blk_write)(NANDFlashState *s);
 void (*blk_erase)(NANDFlashState *s);
-void (*blk_load)(NANDFlashState *s, uint32_t addr, int offset);
+void (*blk_load)(NANDFlashState *s, uint64_t addr, int offset);
 
 uint32_t ioaddr_vmstate;
 };
@@ -318,7 +323,7 @@ static const VMStateDescription vmstate_nand = {
 VMSTATE_UINT32(ioaddr_vmstate, NANDFlashState),
 VMSTATE_INT32(iolen, NANDFlashState),
 VMSTATE_UINT32(cmd, NANDFlashState),
-VMSTATE_UINT32(addr, NANDFlashState),
+VMSTATE_UINT64(addr, NANDFlashState),
 VMSTATE_INT32(addrlen, NANDFlashState),
 VMSTATE_INT32(status, NANDFlashState),
 VMSTATE_INT32(offset, NANDFlashState),
@@ -432,7 +437,7 @@ uint8_t nand_getio(NANDFlashState *s)
 
 /* Allow sequential reading */
 if (!s->iolen && s->cmd == NAND_CMD_READ0) {
-offset = (s->addr & ((1 << s->addr_shift) - 1)) + s->offset;
+offset = (int)(s->addr & ((1 << s->addr_shift) - 1)) + s->offset;
 s->offset = 0;
 
 s->blk_load(s, s->addr, offset);
@@ -526,7 +531,7 @@ void nand_done(NANDFlashState *s)
 /* Program a single page */
 static void glue(nand_blk_write_, PAGE_SIZE)(NANDFlashState *s)
 {
-uint32_t off, page, sector, soff;
+uint64_t off, page, sector, soff;
 uint8_t iobuf[(PAGE_SECTORS + 2) * 0x200];
 if (PAGE(s->addr) >= s->pages)
 return;
@@ -539,7 +544,7 @@ static void glue(nand_blk_write_, PAGE_SIZE)(NANDFlashState 
*s)
 off = (s->addr & PAGE_MASK) + s->offset;
 soff = SECTOR_OFFSET(s->addr);
 if (bdrv_read(s->bdrv, sector, iobuf, PAGE_SECTORS) == -1) {
-printf("%s: read error in sector %i\n", __FUNCTION__, sector);
+printf("%s: read error in sector %" PRIu64 "\n", __func__, sector);
 return;
 }
 
@@ -551,20 +556,20 @@ static void glue(nand_blk_write_, 
PAGE_SIZE)(NANDFlashState *s)
 }
 
 if (bdrv_write(s->bdrv, sector, iobuf, PAGE_SECTORS) == -1)
-printf("%s: write error in sector %i\n", __FUNCTION__, sector);
+printf("%s: write error in sector %" PRIu64 "\n", __func__, 
sector);
 } else {
 off = PAGE_START(s->addr) + (s->addr & PAGE_MASK) + s->offset;
 sector = off >> 9;
 soff = off & 0x1ff;
 if (bdrv_read(s->bdrv, sector, iobuf, PAGE_SECTORS + 2) == -1) {
-printf("%s: read error in sector %i\n", __FUNCTION__, sector);
+printf("%s: read error in sector %" PRIu64 "\n", __func__, sector);
 return;
 }
 
 memcpy(iobuf + soff, s->io, s->iolen);
 
 if (bdrv_write(s->bdrv, sector, iobuf, PAGE_SECTORS + 2) == -1)
-printf("%s: write error in sector %i\n", __FUNCTION__, sector);
+printf("%s: write error in sector %" PRIu64 "\n", __func__, 
sector);
 }
 s->offset = 0;
 }
@@ -572,7 +577,7 @@ static void glue(nand_blk_write_, PAGE_SIZE)(NANDFlashState 
*s)
 /* Erase a single block */
 static void glue(nand_blk_erase_, PAGE_SIZE)(NANDFlashState *s)
 {
-uint32_t i, page, addr;
+uint64_t i, page, addr;
 uint8_t iobuf[0x200] = { [0 ... 0x1ff] = 0xff, };
 addr = s->addr & ~((1 << (ADDR_SHIFT + s->erase_shift)) - 1);
 
@@ -589,34 +594,35 @@ static void glue(nand_blk_erase_, 
PAGE_SIZE)(NANDFlashState *s)
 page = SECTOR(addr + (ADDR_SHIFT + s->erase_shift));
 for (; i < page; i ++)
 if (bdrv_write(s->bdrv, i, iobuf, 1) == -1)
-printf("%s: write error in sector %i\n", __FUNCTION__, i);
+printf("%s: write error in sector %" PRIu64 "\n", __func__, i);
 } else {
 addr = PAGE_START(addr);
 page = addr >> 9;
 if (bdrv_read(s->bdrv, page, iobuf, 1) == -1)
-printf("%s: read error in sector %i\n", __FUNCTION__, page);
+printf("%s: read error in sector %" PRIu64 "\n", __func__, page);
 memset(iobuf + (addr & 0x1ff), 0xff, (~addr & 0

Re: [Qemu-devel] [PATCH] MAINTAINERS: add entry for Xen

2011-07-29 Thread Alexander Graf




Am 29.07.2011 um 17:05 schrieb :

> From: Stefano Stabellini 
> 
> Signed-off-by: Stefano Stabellini 

Acked-by: Alexander Graf 

:)

Alex

> ---
> MAINTAINERS |   10 ++
> 1 files changed, 10 insertions(+), 0 deletions(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 6115e4e..273a6a7 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -143,6 +143,16 @@ L: k...@vger.kernel.org
> S: Supported
> F: target-i386/kvm.c
> 
> +Guest CPU Cores (Xen):
> +--
> +
> +X86
> +M: Stefano Stabellini 
> +L: xen-de...@lists.xensource.com
> +S: Supported
> +F: xen-*
> +F: */xen*
> +
> ARM Machines
> 
> Gumstix
> -- 
> 1.7.2.3
> 



[Qemu-devel] [PATCH 15/15] hw/onenand: program actions can only clear bits

2011-07-29 Thread Peter Maydell
From: Juha Riihimäki 

The program actions onenand_prog_main() and onenand_prog_spare()
can only set bits.

This implies a rewrite of onenand_erase() to not use the program
functions, since erase does need to set bits.

Signed-off-by: Juha Riihimäki 
[Riku Voipio: Fixes and restructuring patchset]
Signed-off-by: Riku Voipio 
[Peter Maydell: More fixes and cleanups for upstream submission]
Signed-off-by:  Peter Maydell 
---
 hw/onenand.c |  135 +
 1 files changed, 106 insertions(+), 29 deletions(-)

diff --git a/hw/onenand.c b/hw/onenand.c
index 0edcfe2..981d23c 100644
--- a/hw/onenand.c
+++ b/hw/onenand.c
@@ -179,14 +179,39 @@ static inline int onenand_load_main(OneNANDState *s, int 
sec, int secn,
 static inline int onenand_prog_main(OneNANDState *s, int sec, int secn,
 void *src)
 {
-if (s->bdrv_cur)
-return bdrv_write(s->bdrv_cur, sec, src, secn) < 0;
-else if (sec + secn > s->secs_cur)
-return 1;
-
-memcpy(s->current + (sec << 9), src, secn << 9);
+int result = 0;
+
+if (secn > 0) {
+uint32_t size = (uint32_t)secn * 512;
+const uint8_t *sp = (const uint8_t *)src;
+uint8_t *dp = 0;
+if (s->bdrv_cur) {
+dp = qemu_malloc(size);
+if (!dp || bdrv_read(s->bdrv_cur, sec, dp, secn) < 0) {
+result = 1;
+}
+} else {
+if (sec + secn > s->secs_cur) {
+result = 1;
+} else {
+dp = (uint8_t *)s->current + (sec << 9);
+}
+}
+if (!result) {
+uint32_t i;
+for (i = 0; i < size; i++) {
+dp[i] &= sp[i];
+}
+if (s->bdrv_cur) {
+result = bdrv_write(s->bdrv_cur, sec, dp, secn) < 0;
+}
+}
+if (dp && s->bdrv_cur) {
+qemu_free(dp);
+}
+}
 
-return 0;
+return result;
 }
 
 static inline int onenand_load_spare(OneNANDState *s, int sec, int secn,
@@ -209,35 +234,87 @@ static inline int onenand_load_spare(OneNANDState *s, int 
sec, int secn,
 static inline int onenand_prog_spare(OneNANDState *s, int sec, int secn,
 void *src)
 {
-uint8_t buf[512];
-
-if (s->bdrv_cur) {
-if (bdrv_read(s->bdrv_cur, s->secs_cur + (sec >> 5), buf, 1) < 0)
-return 1;
-memcpy(buf + ((sec & 31) << 4), src, secn << 4);
-return bdrv_write(s->bdrv_cur, s->secs_cur + (sec >> 5), buf, 1) < 0;
-} else if (sec + secn > s->secs_cur)
-return 1;
-
-memcpy(s->current + (s->secs_cur << 9) + (sec << 4), src, secn << 4);
- 
-return 0;
+int result = 0;
+if (secn > 0) {
+const uint8_t *sp = (const uint8_t *)src;
+uint8_t *dp = 0, *dpp = 0;
+if (s->bdrv_cur) {
+dp = qemu_malloc(512);
+if (!dp || bdrv_read(s->bdrv_cur,
+ s->secs_cur + (sec >> 5),
+ dp, 1) < 0) {
+result = 1;
+} else {
+dpp = dp + ((sec & 31) << 4);
+}
+} else {
+if (sec + secn > s->secs_cur) {
+result = 1;
+} else {
+dpp = s->current + (s->secs_cur << 9) + (sec << 4);
+}
+}
+if (!result) {
+uint32_t i;
+for (i = 0; i < (secn << 4); i++) {
+dpp[i] &= sp[i];
+}
+if (s->bdrv_cur) {
+result = bdrv_write(s->bdrv_cur, s->secs_cur + (sec >> 5),
+dp, 1) < 0;
+}
+}
+if (dp) {
+qemu_free(dp);
+}
+}
+return result;
 }
 
 static inline int onenand_erase(OneNANDState *s, int sec, int num)
 {
-/* TODO: optimise */
-uint8_t buf[512];
-
-memset(buf, 0xff, sizeof(buf));
-for (; num > 0; num --, sec ++) {
-if (onenand_prog_main(s, sec, 1, buf))
-return 1;
-if (onenand_prog_spare(s, sec, 1, buf))
-return 1;
+uint8_t *blankbuf, *tmpbuf;
+blankbuf = qemu_malloc(512);
+if (!blankbuf) {
+return 1;
+}
+tmpbuf = qemu_malloc(512);
+if (!tmpbuf) {
+qemu_free(blankbuf);
+return 1;
+}
+memset(blankbuf, 0xff, 512);
+for (; num > 0; num--, sec++) {
+if (s->bdrv_cur) {
+int erasesec = s->secs_cur + (sec >> 5);
+if (bdrv_write(s->bdrv_cur, sec, blankbuf, 1)) {
+goto fail;
+}
+if (bdrv_read(s->bdrv_cur, erasesec, tmpbuf, 1) < 0) {
+goto fail;
+}
+memcpy(tmpbuf + ((sec & 31) << 4), blankbuf, 1 << 4);
+if (bdrv_write(s->bdrv_cur, erasesec, tmpbuf, 1) < 0) {
+goto fail;
+}
+} else {
+if (sec + 1 > s->secs_cur) {
+goto f

Re: [Qemu-devel] [PULL] non-migratable devices

2011-07-29 Thread Anthony Liguori

On 07/20/2011 05:09 AM, Gerd Hoffmann wrote:

   Hi,

This patch series adds an easy way to tag devices as non-migratable
and puts it into use for ahci, ehci and a number of usb devices.


Pulled.  Thanks.

Regards,

Anthony Liguori



cheers,
   Gerd

The following changes since commit 03ff09580ef6cbc4a893b6e3e6bbff33180ec70a:

   Merge remote-tracking branch 'agraf/xen-next' into staging (2011-07-19 
08:04:35 -0500)

are available in the git repository at:

   git://git.kraxel.org/qemu migration.1

Gerd Hoffmann (9):
   vmstate: add no_migrate flag to VMStateDescription
   vmstate: complain about devices without vmstate
   ahci doesn't support migration
   ehci doesn't support migration
   usb storage: first migration support bits.
   usb-wacom doesn't support migration
   usb-bt doesn't support migration
   usb-net doesn't support migration
   usb-serial doesn't support migration

  hw/hw.h |3 +++
  hw/ide/ich.c|6 ++
  hw/qdev.c   |7 ++-
  hw/usb-bt.c |6 ++
  hw/usb-ehci.c   |7 +++
  hw/usb-msd.c|   12 
  hw/usb-net.c|6 ++
  hw/usb-serial.c |7 +++
  hw/usb-wacom.c  |6 ++
  savevm.c|1 +
  10 files changed, 60 insertions(+), 1 deletions(-)







Re: [Qemu-devel] [PULL] libcacard AFE support and bug fixes

2011-07-29 Thread Anthony Liguori

On 07/22/2011 10:08 AM, Alon Levy wrote:

Hi,

  Please pull fixes for AFE smart cards, cleanup and missing frees
  by Robert Relyea and Christophe Fergeau. Thanks.

The following changes since commit d1afc48b7cfdb4490f322d5d82a2aae6d545ec06:

   SPARC64: implement addtional MMU faults related to nonfaulting load 
(2011-07-21 20:02:22 +)

are available in the git repository at:
   git://anongit.freedesktop.org/~alon/qemu pull-libcacard.afe


Pulled.  Thanks.

Regards,

Anthony Liguori



Christophe Fergeau (5):
   libcacard: don't leak vcard_emul_alloc_arrays mem
   libcacard: s/strip(args++)/strip(args+1)
   libcacard: fix soft=... parsing in vcard_emul_options
   libcacard: introduce NEXT_TOKEN macro
   libcacard: replace copy_string with strndup

Robert Relyea (1):
   libcacard/vcard_emul_nss: support cards lying about CKM_RSA_X_509 support

  libcacard/vcard_emul_nss.c |  257 +++-
  1 files changed, 182 insertions(+), 75 deletions(-)

Alon







Re: [Qemu-devel] [PULL v2] Trivial patches for June 25 to July 27 2011

2011-07-29 Thread Anthony Liguori

On 07/27/2011 10:14 AM, Stefan Hajnoczi wrote:

Quick update: I have dropped the superfluous "Makefile: fix out-of-tree builds"
patch.

The following changes since commit c886edfb851c0c590d4e77f058f2ec8ed95ad1b5:

   Let users select their pythons (2011-07-25 16:50:12 +)

are available in the git repository at:
   ssh://repo.or.cz/srv/git/qemu/stefanha.git trivial-patches


Pulled.  Thanks.

Regards,

Anthony Liguori



Alexandre Raymond (1):
   Makefile: Minor cscope fixups

Juan Quintela (1):
   xen_mapcache: remove unused variable

Michael Roth (1):
   Makefile: add missing deps on $(GENERATED_HEADERS)

Stefan Weil (1):
   slirp: Fix unusual "comments" in unused code

Wolfgang Mauerer (1):
   vhost build fix for i386

Zhi Yong Wu (1):
   qmp: fix efect ->  effect typo in qmp-commands.hx

  Makefile |6 --
  configure|   23 +++
  qmp-commands.hx  |2 +-
  slirp/ip_input.c |4 ++--
  xen-mapcache.c   |3 +--
  5 files changed, 31 insertions(+), 7 deletions(-)







Re: [Qemu-devel] [PULL 0/9] xen patch queue 2011-07-26

2011-07-29 Thread Anthony Liguori

On 07/27/2011 08:30 AM, Alexander Graf wrote:

Hi Anthony,

This is my current patch queue for xen. Please pull.

Alex


The following changes since commit c886edfb851c0c590d4e77f058f2ec8ed95ad1b5:
   Blue Swirl (1):
 Let users select their pythons

are available in the git repository at:

   git://repo.or.cz/qemu/agraf.git xen-next


Pulled.  Thanks.

Regards,

Anthony Liguori



Alexander Graf (2):
   xen: remove CONFIG_XEN_MAPCACHE
   xen: make xen_enabled even more clever

Anthony PERARD (6):
   xen: introduce xen_change_state_handler
   xen: Fix xen_enabled().
   exec.c: Use ram_addr_t in cpu_physical_memory_rw(...).
   cpu-common: Have a ram_addr_t of uint64 with Xen.
   xen: Fix the memory registration to reflect of what is done by Xen.
   vl.c: Check the asked ram_size later.

Stefano Stabellini (1):
   xen: implement unplug protocol in xen_platform

  configure |8 --
  cpu-common.h  |8 +++
  exec.c|   13 ++-
  hw/ide.h  |1 +
  hw/ide/piix.c |   44 +++
  hw/pc_piix.c  |6 -
  hw/xen.h  |2 +-
  hw/xen_platform.c |   43 +-
  vl.c  |   16 +-
  xen-all.c |   54 ++--
  10 files changed, 162 insertions(+), 33 deletions(-)







Re: [Qemu-devel] [PATCH 5/9] usb storage: first migration support bits.

2011-07-29 Thread Paolo Bonzini

On 07/20/2011 12:09 PM, Gerd Hoffmann wrote:

Tag vmstate as unmigratable for the time being,
to be removed when mgration support is finished.


I'm going to handle this at the SCSI level by canceling all transactions 
on pre-load.  Expect patches next week.


Paolo



Re: [Qemu-devel] [PATCH 6/9] usb-wacom doesn't support migration

2011-07-29 Thread Paolo Bonzini

On 07/20/2011 12:09 PM, Gerd Hoffmann wrote:

Signed-off-by: Gerd Hoffmann
---
  hw/usb-wacom.c |6 ++
  1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/hw/usb-wacom.c b/hw/usb-wacom.c
index 9d348e1..d76ee97 100644
--- a/hw/usb-wacom.c
+++ b/hw/usb-wacom.c
@@ -349,6 +349,11 @@ static int usb_wacom_initfn(USBDevice *dev)
  return 0;
  }

+static const VMStateDescription vmstate_usb_wacom = {
+.name = "usb-wacom",
+.unmigratable = 1,
+};
+
  static struct USBDeviceInfo wacom_info = {
  .product_desc   = "QEMU PenPartner Tablet",
  .qdev.name  = "usb-wacom-tablet",
@@ -356,6 +361,7 @@ static struct USBDeviceInfo wacom_info = {
  .usbdevice_name = "wacom-tablet",
  .usb_desc   =&desc_wacom,
  .qdev.size  = sizeof(USBWacomState),
+.qdev.vmsd  =&vmstate_usb_wacom,
  .init   = usb_wacom_initfn,
  .handle_packet  = usb_generic_handle_packet,
  .handle_reset   = usb_wacom_handle_reset,


Since usb_wacom does not support auto-wakeup, it should actually kinda 
sorta work like usb-tablet used to, right?


Paolo



[Qemu-devel] [PATCH 03/15] hw/omap_clk: Add the clock for the OMAP2430-specific fifth GPIO module

2011-07-29 Thread Peter Maydell
The OMAP2430 has a fifth GPIO module which earlier OMAP2 models lack; add
the clock definition for it.

Signed-off-by: Peter Maydell 
---
 hw/omap_clk.c |6 +-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/hw/omap_clk.c b/hw/omap_clk.c
index 6bcabef..577b326 100644
--- a/hw/omap_clk.c
+++ b/hw/omap_clk.c
@@ -836,7 +836,7 @@ static struct clk i2c2_iclk = {
 .parent= &core_l4_iclk,
 };
 
-static struct clk gpio_dbclk[4] = {
+static struct clk gpio_dbclk[5] = {
 {
 .name  = "gpio1_dbclk",
 .flags = CLOCK_IN_OMAP242X | CLOCK_IN_OMAP243X,
@@ -853,6 +853,10 @@ static struct clk gpio_dbclk[4] = {
 .name  = "gpio4_dbclk",
 .flags = CLOCK_IN_OMAP242X | CLOCK_IN_OMAP243X,
 .parent= &wu_32k_clk,
+}, {
+.name   = "gpio5_dbclk",
+.flags  = CLOCK_IN_OMAP243X,
+.parent = &wu_32k_clk,
 },
 };
 
-- 
1.7.1




[Qemu-devel] [PATCH 13/15] onenand: Handle various ID fields separately

2011-07-29 Thread Peter Maydell
From: Juha Riihimäki 

Handle the manufacturer, device and version IDs separately rather than
smooshing them all together into a single uint32_t. Note that the ID
registers are actually 16 bit, even though typically the top bits are 0
and the Read Identification Data command only returns the bottom 8 bits.

Signed-off-by: Juha Riihimäki 
[Riku Voipio: Fixes and restructuring patchset]
Signed-off-by: Riku Voipio 
[Peter Maydell: More fixes and cleanups for upstream submission]
Signed-off-by:  Peter Maydell 
---
 hw/flash.h   |3 ++-
 hw/nseries.c |5 +++--
 hw/onenand.c |   29 ++---
 3 files changed, 23 insertions(+), 14 deletions(-)

diff --git a/hw/flash.h b/hw/flash.h
index 1aae43d..1064fd0 100644
--- a/hw/flash.h
+++ b/hw/flash.h
@@ -38,7 +38,8 @@ uint32_t nand_getbuswidth(DeviceState *dev);
 /* onenand.c */
 void onenand_base_update(void *opaque, target_phys_addr_t new);
 void onenand_base_unmap(void *opaque);
-void *onenand_init(BlockDriverState *bdrv, uint32_t id,
+void *onenand_init(BlockDriverState *bdrv,
+   uint16_t man_id, uint16_t dev_id, uint16_t ver_id,
int regshift, qemu_irq irq);
 void *onenand_raw_otp(void *opaque);
 
diff --git a/hw/nseries.c b/hw/nseries.c
index 96cc490..7cdba25 100644
--- a/hw/nseries.c
+++ b/hw/nseries.c
@@ -167,8 +167,9 @@ static void n8x0_nand_setup(struct n800_s *s)
 DriveInfo *dinfo;
 
 dinfo = drive_get(IF_MTD, 0, 0);
-/* Either ec40xx or ec48xx are OK for the ID */
-s->nand = onenand_init(dinfo ? dinfo->bdrv : 0, 0xec4800, 1,
+/* Either 0x40 or 0x48 are OK for the device ID */
+s->nand = onenand_init(dinfo ? dinfo->bdrv : 0,
+   NAND_MFR_SAMSUNG, 0x48, 0, 1,
qdev_get_gpio_in(s->cpu->gpio, N8X0_ONENAND_GPIO));
 omap_gpmc_attach(s->cpu->gpmc, N8X0_ONENAND_CS, 0, onenand_base_update,
  onenand_base_unmap, s->nand);
diff --git a/hw/onenand.c b/hw/onenand.c
index 3a19d7f..9f02736 100644
--- a/hw/onenand.c
+++ b/hw/onenand.c
@@ -31,7 +31,11 @@
 #define BLOCK_SHIFT(PAGE_SHIFT + 6)
 
 typedef struct {
-uint32_t id;
+struct {
+uint16_t man;
+uint16_t dev;
+uint16_t ver;
+} id;
 int shift;
 target_phys_addr_t base;
 qemu_irq intr;
@@ -453,12 +457,12 @@ static uint32_t onenand_read(void *opaque, 
target_phys_addr_t addr)
 return lduw_le_p(s->boot[0] + addr);
 
 case 0xf000:   /* Manufacturer ID */
-return (s->id >> 16) & 0xff;
+return s->id.man;
 case 0xf001:   /* Device ID */
-return (s->id >>  8) & 0xff;
-/* TODO: get the following values from a real chip!  */
+return s->id.dev;
 case 0xf002:   /* Version ID */
-return (s->id >>  0) & 0xff;
+return s->id.ver;
+/* TODO: get the following values from a real chip!  */
 case 0xf003:   /* Data Buffer size */
 return 1 << PAGE_SHIFT;
 case 0xf004:   /* Boot Buffer size */
@@ -541,8 +545,8 @@ static void onenand_write(void *opaque, target_phys_addr_t 
addr,
 
 case 0x0090:   /* Read Identification Data */
 memset(s->boot[0], 0, 3 << s->shift);
-s->boot[0][0 << s->shift] = (s->id >> 16) & 0xff;
-s->boot[0][1 << s->shift] = (s->id >>  8) & 0xff;
+s->boot[0][0 << s->shift] = s->id.man & 0xff;
+s->boot[0][1 << s->shift] = s->id.dev & 0xff;
 s->boot[0][2 << s->shift] = s->wpstatus & 0xff;
 break;
 
@@ -615,21 +619,24 @@ static CPUWriteMemoryFunc * const onenand_writefn[] = {
 onenand_write,
 };
 
-void *onenand_init(BlockDriverState *bdrv, uint32_t id,
+void *onenand_init(BlockDriverState *bdrv,
+   uint16_t man_id, uint16_t dev_id, uint16_t ver_id,
int regshift, qemu_irq irq)
 {
 OneNANDState *s = (OneNANDState *) qemu_mallocz(sizeof(*s));
-uint32_t size = 1 << (24 + ((id >> 12) & 7));
+uint32_t size = 1 << (24 + ((dev_id >> 4) & 7));
 void *ram;
 
 s->shift = regshift;
 s->intr = irq;
 s->rdy = NULL;
-s->id = id;
+s->id.man = man_id;
+s->id.dev = dev_id;
+s->id.ver = ver_id;
 s->blocks = size >> BLOCK_SHIFT;
 s->secs = size >> 9;
 s->blockwp = qemu_malloc(s->blocks);
-s->density_mask = (id & (1 << 11)) ? (1 << (6 + ((id >> 12) & 7))) : 0;
+s->density_mask = (dev_id & 0x08) ? (1 << (6 + ((dev_id >> 4) & 7))) : 0;
 s->iomemtype = cpu_register_io_memory(onenand_readfn,
 onenand_writefn, s, DEVICE_NATIVE_ENDIAN);
 s->bdrv = bdrv;
-- 
1.7.1




[Qemu-devel] [PATCH 11/15] hw/nand: qdevify

2011-07-29 Thread Peter Maydell
From: Juha Riihimäki 

Qdevify the NAND device.

Signed-off-by: Juha Riihimäki 
[Riku Voipio: Fixes and restructuring patchset]
Signed-off-by: Riku Voipio 
[Peter Maydell: More fixes and cleanups for upstream submission]
Signed-off-by:  Peter Maydell 
---
 hw/axis_dev88.c |2 +-
 hw/flash.h  |   14 ++---
 hw/nand.c   |  164 +++
 hw/spitz.c  |2 +-
 hw/tc6393xb.c   |2 +-
 5 files changed, 102 insertions(+), 82 deletions(-)

diff --git a/hw/axis_dev88.c b/hw/axis_dev88.c
index de1f5a5..e0a8c14 100644
--- a/hw/axis_dev88.c
+++ b/hw/axis_dev88.c
@@ -37,7 +37,7 @@
 
 struct nand_state_t
 {
-NANDFlashState *nand;
+DeviceState *nand;
 unsigned int rdy:1;
 unsigned int ale:1;
 unsigned int cle:1;
diff --git a/hw/flash.h b/hw/flash.h
index 132ad29..43260ce 100644
--- a/hw/flash.h
+++ b/hw/flash.h
@@ -18,15 +18,13 @@ pflash_t *pflash_cfi02_register(target_phys_addr_t base, 
ram_addr_t off,
 int be);
 
 /* nand.c */
-typedef struct NANDFlashState NANDFlashState;
-NANDFlashState *nand_init(BlockDriverState *bdrv, int manf_id, int chip_id);
-void nand_done(NANDFlashState *s);
-void nand_setpins(NANDFlashState *s, uint8_t cle, uint8_t ale,
+DeviceState *nand_init(BlockDriverState *bdrv, int manf_id, int chip_id);
+void nand_setpins(DeviceState *dev, uint8_t cle, uint8_t ale,
   uint8_t ce, uint8_t wp, uint8_t gnd);
-void nand_getpins(NANDFlashState *s, int *rb);
-void nand_setio(NANDFlashState *s, uint32_t value);
-uint32_t nand_getio(NANDFlashState *s);
-uint32_t nand_getbuswidth(NANDFlashState *s);
+void nand_getpins(DeviceState *dev, int *rb);
+void nand_setio(DeviceState *dev, uint32_t value);
+uint32_t nand_getio(DeviceState *dev);
+uint32_t nand_getbuswidth(DeviceState *dev);
 
 #define NAND_MFR_TOSHIBA   0x98
 #define NAND_MFR_SAMSUNG   0xec
diff --git a/hw/nand.c b/hw/nand.c
index d068eb6..2f5a40e 100644
--- a/hw/nand.c
+++ b/hw/nand.c
@@ -18,6 +18,7 @@
 # include "hw.h"
 # include "flash.h"
 # include "blockdev.h"
+# include "sysbus.h"
 
 # define NAND_CMD_READ00x00
 # define NAND_CMD_READ10x01
@@ -47,7 +48,9 @@
 # define MAX_PAGE  0x800
 # define MAX_OOB   0x40
 
+typedef struct NANDFlashState NANDFlashState;
 struct NANDFlashState {
+SysBusDevice busdev;
 uint8_t manf_id, chip_id;
 uint8_t buswidth; /* in BYTES */
 int size, pages;
@@ -215,8 +218,9 @@ static const struct {
 [0xc5] = { 2048,   16, 0, 0, LP_OPTIONS16 },
 };
 
-static void nand_reset(NANDFlashState *s)
+static void nand_reset(DeviceState *dev)
 {
+NANDFlashState *s = FROM_SYSBUS(NANDFlashState, sysbus_from_qdev(dev));
 s->cmd = NAND_CMD_READ0;
 s->addr = 0;
 s->addrlen = 0;
@@ -270,7 +274,7 @@ static void nand_command(NANDFlashState *s)
 break;
 
 case NAND_CMD_RESET:
-nand_reset(s);
+nand_reset(&s->busdev.qdev);
 break;
 
 case NAND_CMD_PAGEPROGRAM1:
@@ -354,15 +358,84 @@ static const VMStateDescription vmstate_nand = {
 }
 };
 
+static int nand_device_init(SysBusDevice *dev)
+{
+int pagesize;
+NANDFlashState *s = FROM_SYSBUS(NANDFlashState, dev);
+s->buswidth = nand_flash_ids[s->chip_id].width >> 3;
+s->size = nand_flash_ids[s->chip_id].size << 20;
+if (nand_flash_ids[s->chip_id].options & NAND_SAMSUNG_LP) {
+s->page_shift = 11;
+s->erase_shift = 6;
+} else {
+s->page_shift = nand_flash_ids[s->chip_id].page_shift;
+s->erase_shift = nand_flash_ids[s->chip_id].erase_shift;
+}
+
+switch (1 << s->page_shift) {
+case 256:
+nand_init_256(s);
+break;
+case 512:
+nand_init_512(s);
+break;
+case 2048:
+nand_init_2048(s);
+break;
+default:
+hw_error("%s: Unsupported NAND block size.\n", __func__);
+}
+
+pagesize = 1 << s->oob_shift;
+s->mem_oob = 1;
+if (s->bdrv && bdrv_getlength(s->bdrv) >=
+(s->pages << s->page_shift) + (s->pages << s->oob_shift)) {
+pagesize = 0;
+s->mem_oob = 0;
+}
+
+if (!s->bdrv) {
+pagesize += 1 << s->page_shift;
+}
+if (pagesize) {
+s->storage = (uint8_t *) memset(qemu_malloc(s->pages * pagesize),
+0xff, s->pages * pagesize);
+}
+/* Give s->ioaddr a sane value in case we save state before it is used. */
+s->ioaddr = s->io;
+
+return 0;
+}
+
+static SysBusDeviceInfo nand_info = {
+.init = nand_device_init,
+.qdev.name = "nand",
+.qdev.size = sizeof(NANDFlashState),
+.qdev.reset = nand_reset,
+.qdev.vmsd = &vmstate_nand,
+.qdev.props = (Property[]) {
+DEFINE_PROP_UINT8("manufacturer_id", NANDFlashState, manf_id, 0),
+DEFINE_PROP_UINT8("chip_id", NANDFlashState, chip_id, 0),
+DEFINE_PROP_DRIVE("drive", NANDFlashState, bdrv),
+DEFINE_

[Qemu-devel] [PATCH 08/15] hw/nand: Support devices wider than 8 bits

2011-07-29 Thread Peter Maydell
From: Juha Riihimäki 

Support NAND devices which are wider than 8 bits.

Signed-off-by: Juha Riihimäki 
[Riku Voipio: Fixes and restructuring patchset]
Signed-off-by: Riku Voipio 
[Peter Maydell: More fixes and cleanups for upstream submission]
Signed-off-by:  Peter Maydell 
---
 hw/flash.h |5 ++-
 hw/nand.c  |  119 +++-
 2 files changed, 89 insertions(+), 35 deletions(-)

diff --git a/hw/flash.h b/hw/flash.h
index a992bb8..132ad29 100644
--- a/hw/flash.h
+++ b/hw/flash.h
@@ -24,8 +24,9 @@ void nand_done(NANDFlashState *s);
 void nand_setpins(NANDFlashState *s, uint8_t cle, uint8_t ale,
   uint8_t ce, uint8_t wp, uint8_t gnd);
 void nand_getpins(NANDFlashState *s, int *rb);
-void nand_setio(NANDFlashState *s, uint8_t value);
-uint8_t nand_getio(NANDFlashState *s);
+void nand_setio(NANDFlashState *s, uint32_t value);
+uint32_t nand_getio(NANDFlashState *s);
+uint32_t nand_getbuswidth(NANDFlashState *s);
 
 #define NAND_MFR_TOSHIBA   0x98
 #define NAND_MFR_SAMSUNG   0xec
diff --git a/hw/nand.c b/hw/nand.c
index 18aa226..2e98f25 100644
--- a/hw/nand.c
+++ b/hw/nand.c
@@ -49,6 +49,7 @@
 
 struct NANDFlashState {
 uint8_t manf_id, chip_id;
+uint8_t buswidth; /* in BYTES */
 int size, pages;
 int page_shift, oob_shift, erase_shift, addr_shift;
 uint8_t *storage;
@@ -215,6 +216,14 @@ static void nand_reset(NANDFlashState *s)
 s->status &= NAND_IOSTATUS_UNPROTCT;
 }
 
+static inline void nand_pushio_byte(NANDFlashState *s, uint8_t value)
+{
+s->ioaddr[s->iolen++] = value;
+for (value = s->buswidth; --value;) {
+s->ioaddr[s->iolen++] = 0;
+}
+}
+
 static void nand_command(NANDFlashState *s)
 {
 unsigned int offset;
@@ -224,15 +233,19 @@ static void nand_command(NANDFlashState *s)
 break;
 
 case NAND_CMD_READID:
-s->io[0] = s->manf_id;
-s->io[1] = s->chip_id;
-s->io[2] = 'Q';/* Don't-care byte (often 0xa5) */
-if (nand_flash_ids[s->chip_id].options & NAND_SAMSUNG_LP)
-s->io[3] = 0x15;   /* Page Size, Block Size, Spare Size.. */
-else
-s->io[3] = 0xc0;   /* Multi-plane */
 s->ioaddr = s->io;
-s->iolen = 4;
+s->iolen = 0;
+nand_pushio_byte(s, s->manf_id);
+nand_pushio_byte(s, s->chip_id);
+nand_pushio_byte(s, 'Q'); /* Don't-care byte (often 0xa5) */
+if (nand_flash_ids[s->chip_id].options & NAND_SAMSUNG_LP) {
+/* Page Size, Block Size, Spare Size; bit 6 indicates
+ * 8 vs 16 bit width NAND.
+ */
+nand_pushio_byte(s, (s->buswidth == 2) ? 0x55 : 0x15);
+} else {
+nand_pushio_byte(s, 0xc0); /* Multi-plane */
+}
 break;
 
 case NAND_CMD_RANDOMREAD2:
@@ -277,9 +290,9 @@ static void nand_command(NANDFlashState *s)
 break;
 
 case NAND_CMD_READSTATUS:
-s->io[0] = s->status;
 s->ioaddr = s->io;
-s->iolen = 1;
+s->iolen = 0;
+nand_pushio_byte(s, s->status);
 break;
 
 default:
@@ -357,8 +370,10 @@ void nand_getpins(NANDFlashState *s, int *rb)
 *rb = 1;
 }
 
-void nand_setio(NANDFlashState *s, uint8_t value)
+void nand_setio(NANDFlashState *s, uint32_t value)
 {
+int i;
+
 if (!s->ce && s->cle) {
 if (nand_flash_ids[s->chip_id].options & NAND_SAMSUNG_LP) {
 if (s->cmd == NAND_CMD_READ0 && value == NAND_CMD_LPREAD2)
@@ -404,36 +419,64 @@ void nand_setio(NANDFlashState *s, uint8_t value)
 s->addr = (s->addr & mask) | v;
 s->addrlen ++;
 
-if (s->addrlen == 1 && s->cmd == NAND_CMD_READID)
-nand_command(s);
-
-if (!(nand_flash_ids[s->chip_id].options & NAND_SAMSUNG_LP) &&
-s->addrlen == 3 && (
-s->cmd == NAND_CMD_READ0 ||
-s->cmd == NAND_CMD_PAGEPROGRAM1))
-nand_command(s);
-if ((nand_flash_ids[s->chip_id].options & NAND_SAMSUNG_LP) &&
-   s->addrlen == 4 && (
-s->cmd == NAND_CMD_READ0 ||
-s->cmd == NAND_CMD_PAGEPROGRAM1))
-nand_command(s);
+switch (s->addrlen) {
+case 1:
+if (s->cmd == NAND_CMD_READID) {
+nand_command(s);
+}
+break;
+case 2: /* fix cache address as a byte address */
+s->addr <<= (s->buswidth - 1);
+break;
+case 3:
+if (!(nand_flash_ids[s->chip_id].options & NAND_SAMSUNG_LP)
+&& (s->cmd == NAND_CMD_READ0
+|| s->cmd == NAND_CMD_PAGEPROGRAM1)) {
+nand_command(s);
+}
+break;
+case 4:
+if ((nand_flash_ids[s->chip_id].options & NAND_SAMSUNG_LP)
+&& nand_flash_ids[s->chip_id].size < 256 /* 1Gb or less */
+&& (s->cmd == NAND_CMD_READ0 ||
+  

[Qemu-devel] [PULL 00/15] omap patches (gpio, nand, onenand, lm832x)

2011-07-29 Thread Peter Maydell
This pull request gathers up my recent omap patches:
 * omap-gpio qdevification
 * nand bugfixes and qdevification
 * onenand bugfixes
 * fix crash bug in n810/lm832x when key is pressed

I have omitted patch 11/12 from the nand/onenand patchset
(http://patchwork.ozlabs.org/patch/104841/
 "hw/sysbus: Add sysbus_mmio_unmap() for unmapping a region")
because it needs updating now Avi's memory API changes have landed,
and 12/12 (hw/onenand: qdevify) because that depends on 11/12.
I'll post newer versions of those next week, probably.

The following changes since commit c62f6d1d76aea587556c85b6b7b5c44167006264:

  monitor: fix build breakage with --disable-vnc (2011-07-29 09:33:56 -0500)

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

Juha Riihimäki (9):
  hw/omap_l4.c: Add helper function omap_l4_region_base
  hw/omap_gpio.c: Convert to qdev
  hw/nand: Support large NAND devices
  hw/nand: Support devices wider than 8 bits
  hw/nand: Support multiple reads following READ STATUS
  hw/nand: qdevify
  onenand: Handle various ID fields separately
  onenand: Ignore zero writes to boot command space
  hw/onenand: program actions can only clear bits

Peter Maydell (6):
  hw/omap_gpio.c: Don't complain about some writes to r/o registers
  hw/omap_clk: Add the clock for the OMAP2430-specific fifth GPIO module
  lm832x: Take DeviceState pointer in lm832x_key_event()
  hw/nand: Pass block device state to init function
  hw/nand: Writing to NAND can only clear bits
  onenand: Pass BlockDriverState to init function

 hw/axis_dev88.c |8 +-
 hw/flash.h  |   17 ++--
 hw/i2c.h|2 +-
 hw/lm832x.c |4 +-
 hw/nand.c   |  345 +++
 hw/nseries.c|   63 +-
 hw/omap.h   |   22 +---
 hw/omap1.c  |   10 +-
 hw/omap2.c  |   34 --
 hw/omap_clk.c   |6 +-
 hw/omap_gpio.c  |  263 --
 hw/omap_l4.c|6 +
 hw/onenand.c|  183 ++---
 hw/palm.c   |   26 ++--
 hw/spitz.c  |6 +-
 hw/tc6393xb.c   |7 +-
 16 files changed, 627 insertions(+), 375 deletions(-)



[Qemu-devel] [PATCH v2 0.15 2/4] add pc-0.14 machine

2011-07-29 Thread Paolo Bonzini
The new pc-0.15 machine will have a different migration format, so
define the compatibility one right now.

Signed-off-by: Paolo Bonzini 
---
 hw/pc_piix.c |   10 +-
 1 files changed, 9 insertions(+), 1 deletions(-)

diff --git a/hw/pc_piix.c b/hw/pc_piix.c
index c5c16b4..61f8cbb 100644
--- a/hw/pc_piix.c
+++ b/hw/pc_piix.c
@@ -258,7 +258,7 @@ static void pc_xen_hvm_init(ram_addr_t ram_size,
 #endif
 
 static QEMUMachine pc_machine = {
-.name = "pc-0.14",
+.name = "pc-0.15",
 .alias = "pc",
 .desc = "Standard PC",
 .init = pc_init_pci,
@@ -266,6 +266,13 @@ static QEMUMachine pc_machine = {
 .is_default = 1,
 };
 
+static QEMUMachine pc_machine_v0_14 = {
+.name = "pc-0.14",
+.desc = "Standard PC",
+.init = pc_init_pci,
+.max_cpus = 255,
+};
+
 static QEMUMachine pc_machine_v0_13 = {
 .name = "pc-0.13",
 .desc = "Standard PC",
@@ -482,6 +489,7 @@ static QEMUMachine xenfv_machine = {
 static void pc_machine_init(void)
 {
 qemu_register_machine(&pc_machine);
+qemu_register_machine(&pc_machine_v0_14);
 qemu_register_machine(&pc_machine_v0_13);
 qemu_register_machine(&pc_machine_v0_12);
 qemu_register_machine(&pc_machine_v0_11);
-- 
1.7.6





[Qemu-devel] [PATCH 01/15] hw/omap_l4.c: Add helper function omap_l4_region_base

2011-07-29 Thread Peter Maydell
From: Juha Riihimäki 

Add helper function omap_l4_region_base() to return the base address
of a particular region of an L4 target agent.

Signed-off-by: Juha Riihimäki 
[Riku Voipio: Fixes and restructuring patchset]
Signed-off-by: Riku Voipio 
[Peter Maydell: More fixes and cleanups for upstream submission]
Signed-off-by:  Peter Maydell 
---
 hw/omap.h|2 ++
 hw/omap_l4.c |6 ++
 2 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/hw/omap.h b/hw/omap.h
index c227a82..00a0ea9 100644
--- a/hw/omap.h
+++ b/hw/omap.h
@@ -93,6 +93,8 @@ struct omap_target_agent_s *omap_l4ta_get(
 int cs);
 target_phys_addr_t omap_l4_attach(struct omap_target_agent_s *ta, int region,
 int iotype);
+target_phys_addr_t omap_l4_region_base(struct omap_target_agent_s *ta,
+   int region);
 int l4_register_io_memory(CPUReadMemoryFunc * const *mem_read,
 CPUWriteMemoryFunc * const *mem_write, void *opaque);
 
diff --git a/hw/omap_l4.c b/hw/omap_l4.c
index 4af0ca8..59c84b1 100644
--- a/hw/omap_l4.c
+++ b/hw/omap_l4.c
@@ -146,6 +146,12 @@ struct omap_l4_s *omap_l4_init(target_phys_addr_t base, 
int ta_num)
 return bus;
 }
 
+target_phys_addr_t omap_l4_region_base(struct omap_target_agent_s *ta,
+   int region)
+{
+return ta->bus->base + ta->start[region].offset;
+}
+
 static uint32_t omap_l4ta_read(void *opaque, target_phys_addr_t addr)
 {
 struct omap_target_agent_s *s = (struct omap_target_agent_s *) opaque;
-- 
1.7.1




[Qemu-devel] [PATCH V2 2/2] [SLIRP] Delayed IP packets

2011-07-29 Thread Fabien Chouteau
In the current implementation, if Slirp tries to send an IP packet to a client
with an unknown hardware address, the packet is simply dropped and an ARP
request is sent (if_encap in slirp/slirp.c).

With this patch, Slirp will send the ARP request, re-queue the packet and try
to send it later. The packet is dropped after one second if the ARP reply is
not received.

Signed-off-by: Fabien Chouteau 
---
 slirp/if.c|   28 ---
 slirp/main.h  |2 +-
 slirp/mbuf.c  |2 +
 slirp/mbuf.h  |2 +
 slirp/slirp.c |   67 ++--
 slirp/slirp.h |   15 
 6 files changed, 80 insertions(+), 36 deletions(-)

diff --git a/slirp/if.c b/slirp/if.c
index 0f04e13..80a5c4e 100644
--- a/slirp/if.c
+++ b/slirp/if.c
@@ -6,6 +6,7 @@
  */
 
 #include 
+#include "qemu-timer.h"
 
 #define ifs_init(ifm) ((ifm)->ifs_next = (ifm)->ifs_prev = (ifm))
 
@@ -105,6 +106,9 @@ if_output(struct socket *so, struct mbuf *ifm)
ifs_init(ifm);
insque(ifm, ifq);
 
+/* Expiration date = Now + 1 second */
+ifm->expiration_date = qemu_get_clock_ns(vm_clock) + 10ULL;
+
 diddit:
slirp->if_queued++;
 
@@ -153,6 +157,9 @@ diddit:
 void
 if_start(Slirp *slirp)
 {
+int requeued = 0;
+uint64_t now;
+
struct mbuf *ifm, *ifqt;
 
DEBUG_CALL("if_start");
@@ -165,6 +172,8 @@ if_start(Slirp *slirp)
 if (!slirp_can_output(slirp->opaque))
 return;
 
+now = qemu_get_clock_ns(vm_clock);
+
/*
 * See which queue to get next packet from
 * If there's something in the fastq, select it immediately
@@ -199,11 +208,22 @@ if_start(Slirp *slirp)
   ifm->ifq_so->so_nqueued = 0;
}
 
-   /* Encapsulate the packet for sending */
-if_encap(slirp, (uint8_t *)ifm->m_data, ifm->m_len);
-
-m_free(ifm);
+if (ifm->expiration_date < now) {
+/* Expired */
+m_free(ifm);
+} else {
+/* Encapsulate the packet for sending */
+if (if_encap(slirp, ifm)) {
+m_free(ifm);
+} else {
+/* re-queue */
+insque(ifm, ifqt);
+requeued++;
+}
+}
 
if (slirp->if_queued)
   goto again;
+
+slirp->if_queued = requeued;
 }
diff --git a/slirp/main.h b/slirp/main.h
index 0dd8d81..028df4b 100644
--- a/slirp/main.h
+++ b/slirp/main.h
@@ -42,5 +42,5 @@ extern int tcp_keepintvl;
 #define PROTO_PPP 0x2
 #endif
 
-void if_encap(Slirp *slirp, const uint8_t *ip_data, int ip_data_len);
+int if_encap(Slirp *slirp, struct mbuf *ifm);
 ssize_t slirp_send(struct socket *so, const void *buf, size_t len, int flags);
diff --git a/slirp/mbuf.c b/slirp/mbuf.c
index ce2eb84..c699c75 100644
--- a/slirp/mbuf.c
+++ b/slirp/mbuf.c
@@ -70,6 +70,8 @@ m_get(Slirp *slirp)
m->m_len = 0;
 m->m_nextpkt = NULL;
 m->m_prevpkt = NULL;
+m->arp_requested = false;
+m->expiration_date = (uint64_t)-1;
 end_error:
DEBUG_ARG("m = %lx", (long )m);
return m;
diff --git a/slirp/mbuf.h b/slirp/mbuf.h
index b74544b..55170e5 100644
--- a/slirp/mbuf.h
+++ b/slirp/mbuf.h
@@ -86,6 +86,8 @@ struct mbuf {
charm_dat_[1]; /* ANSI don't like 0 sized arrays */
char*m_ext_;
} M_dat;
+bool arp_requested;
+uint64_t expiration_date;
 };
 
 #define m_next m_hdr.mh_next
diff --git a/slirp/slirp.c b/slirp/slirp.c
index ba76757..b006620 100644
--- a/slirp/slirp.c
+++ b/slirp/slirp.c
@@ -237,6 +237,8 @@ Slirp *slirp_init(int restricted, struct in_addr vnetwork,
 
 QTAILQ_INSERT_TAIL(&slirp_instances, slirp, entry);
 
+slirp->delayed = NULL;
+
 return slirp;
 }
 
@@ -693,54 +695,57 @@ void slirp_input(Slirp *slirp, const uint8_t *pkt, int 
pkt_len)
 }
 
 /* output the IP packet to the ethernet device */
-void if_encap(Slirp *slirp, const uint8_t *ip_data, int ip_data_len)
+int if_encap(Slirp *slirp, struct mbuf *ifm)
 {
 uint8_t buf[1600];
 struct ethhdr *eh = (struct ethhdr *)buf;
 uint8_t ethaddr[ETH_ALEN];
-const struct ip *iph = (const struct ip *)ip_data;
+const struct ip *iph = (const struct ip *)ifm->m_data;
 
-if (ip_data_len + ETH_HLEN > sizeof(buf))
-return;
+if (ifm->m_len + ETH_HLEN > sizeof(buf))
+return 1;
 
 if (!arp_table_search(&slirp->arp_table, iph->ip_dst.s_addr, ethaddr)) {
 uint8_t arp_req[ETH_HLEN + sizeof(struct arphdr)];
 struct ethhdr *reh = (struct ethhdr *)arp_req;
 struct arphdr *rah = (struct arphdr *)(arp_req + ETH_HLEN);
 
-/* If the client addr is not known, there is no point in
-   sending the packet to it. Normally the sender should have
-   done an ARP request to get its MAC address. Here we do it
-   in place of sending the packet and we hope that the sender
-   will r

[Qemu-devel] [PATCH V2 1/2] [SLIRP] Simple ARP table

2011-07-29 Thread Fabien Chouteau
This patch adds a simple ARP table in Slirp and also adds handling of
gratuitous ARP requests.

Signed-off-by: Fabien Chouteau 
---
 Makefile.objs |2 +-
 slirp/arp_table.c |   50 ++
 slirp/bootp.c |   23 --
 slirp/slirp.c |   63 +---
 slirp/slirp.h |   50 +++--
 5 files changed, 129 insertions(+), 59 deletions(-)
 create mode 100644 slirp/arp_table.c

diff --git a/Makefile.objs b/Makefile.objs
index 6991a9f..0c10557 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -151,7 +151,7 @@ common-obj-y += qemu-timer.o qemu-timer-common.o
 
 slirp-obj-y = cksum.o if.o ip_icmp.o ip_input.o ip_output.o
 slirp-obj-y += slirp.o mbuf.o misc.o sbuf.o socket.o tcp_input.o tcp_output.o
-slirp-obj-y += tcp_subr.o tcp_timer.o udp.o bootp.o tftp.o
+slirp-obj-y += tcp_subr.o tcp_timer.o udp.o bootp.o tftp.o arp_table.o
 common-obj-$(CONFIG_SLIRP) += $(addprefix slirp/, $(slirp-obj-y))
 
 # xen backend driver support
diff --git a/slirp/arp_table.c b/slirp/arp_table.c
new file mode 100644
index 000..5d7404b
--- /dev/null
+++ b/slirp/arp_table.c
@@ -0,0 +1,50 @@
+#include "slirp.h"
+
+void arp_table_add(ArpTable *arptbl,
+   int   ip_addr,
+   uint8_t   ethaddr[ETH_ALEN])
+{
+int i;
+
+DEBUG_CALL("arp_table_add");
+DEBUG_ARG("ip = 0x%x", ip_addr);
+DEBUG_ARGS((dfd, " hw addr = %02x:%02x:%02x:%02x:%02x:%02x\n",
+ethaddr[0], ethaddr[1], ethaddr[2],
+ethaddr[3], ethaddr[4], ethaddr[5]));
+
+/* Search for an entry */
+for (i = 0; i < ARP_TABLE_SIZE && arptbl->table[i].ar_sip != 0; i++) {
+if (arptbl->table[i].ar_sip == ip_addr) {
+/* Update the entry */
+memcpy(arptbl->table[i].ar_sha, ethaddr, ETH_ALEN);
+return;
+}
+}
+
+/* No entry found, create a new one */
+arptbl->table[arptbl->next_victim].ar_sip = ip_addr;
+memcpy(arptbl->table[arptbl->next_victim].ar_sha,  ethaddr, ETH_ALEN);
+arptbl->next_victim = (arptbl->next_victim + 1) % ARP_TABLE_SIZE;
+}
+
+bool arp_table_search(ArpTable *arptbl,
+  int   in_ip_addr,
+  uint8_t   out_ethaddr[ETH_ALEN])
+{
+int i;
+
+DEBUG_CALL("arp_table_search");
+DEBUG_ARG("ip = 0x%x", in_ip_addr);
+
+for (i = 0; i < ARP_TABLE_SIZE; i++) {
+if (arptbl->table[i].ar_sip == in_ip_addr) {
+memcpy(out_ethaddr, arptbl->table[i].ar_sha,  ETH_ALEN);
+DEBUG_ARGS((dfd, " found hw addr = 
%02x:%02x:%02x:%02x:%02x:%02x\n",
+out_ethaddr[0], out_ethaddr[1], out_ethaddr[2],
+out_ethaddr[3], out_ethaddr[4], out_ethaddr[5]));
+return 1;
+}
+}
+
+return 0;
+}
diff --git a/slirp/bootp.c b/slirp/bootp.c
index 1eb2ed1..07cbb80 100644
--- a/slirp/bootp.c
+++ b/slirp/bootp.c
@@ -149,6 +149,7 @@ static void bootp_reply(Slirp *slirp, const struct bootp_t 
*bp)
 struct in_addr preq_addr;
 int dhcp_msg_type, val;
 uint8_t *q;
+uint8_t client_ethaddr[ETH_ALEN];
 
 /* extract exact DHCP msg type */
 dhcp_decode(bp, &dhcp_msg_type, &preq_addr);
@@ -164,8 +165,9 @@ static void bootp_reply(Slirp *slirp, const struct bootp_t 
*bp)
 if (dhcp_msg_type != DHCPDISCOVER &&
 dhcp_msg_type != DHCPREQUEST)
 return;
-/* XXX: this is a hack to get the client mac address */
-memcpy(slirp->client_ethaddr, bp->bp_hwaddr, 6);
+
+/* Get client's hardware address from bootp request */
+memcpy(client_ethaddr, bp->bp_hwaddr, ETH_ALEN);
 
 m = m_get(slirp);
 if (!m) {
@@ -178,25 +180,25 @@ static void bootp_reply(Slirp *slirp, const struct 
bootp_t *bp)
 
 if (dhcp_msg_type == DHCPDISCOVER) {
 if (preq_addr.s_addr != htonl(0L)) {
-bc = request_addr(slirp, &preq_addr, slirp->client_ethaddr);
+bc = request_addr(slirp, &preq_addr, client_ethaddr);
 if (bc) {
 daddr.sin_addr = preq_addr;
 }
 }
 if (!bc) {
  new_addr:
-bc = get_new_addr(slirp, &daddr.sin_addr, slirp->client_ethaddr);
+bc = get_new_addr(slirp, &daddr.sin_addr, client_ethaddr);
 if (!bc) {
 DPRINTF("no address left\n");
 return;
 }
 }
-memcpy(bc->macaddr, slirp->client_ethaddr, 6);
+memcpy(bc->macaddr, client_ethaddr, ETH_ALEN);
 } else if (preq_addr.s_addr != htonl(0L)) {
-bc = request_addr(slirp, &preq_addr, slirp->client_ethaddr);
+bc = request_addr(slirp, &preq_addr, client_ethaddr);
 if (bc) {
 daddr.sin_addr = preq_addr;
-memcpy(bc->macaddr, slirp->client_ethaddr, 6);
+memcpy(bc->macaddr, client_ethaddr, ETH_ALEN);
 } else {
 daddr.sin_addr.s_addr =

[Qemu-devel] [PATCH 05/15] lm832x: Take DeviceState pointer in lm832x_key_event()

2011-07-29 Thread Peter Maydell
Since lm832x has been qdev'ified, its users will generally
have a DeviceState pointer rather than an i2c_slave pointer,
so adjust lm832x_key_event's prototype to suit.

This allows the n810 (its only user) to actually pass a correct
pointer to it rather than NULL. The effect is that we no longer
segfault when a key is pressed.

Signed-off-by: Peter Maydell 
---
 hw/i2c.h |2 +-
 hw/lm832x.c  |4 ++--
 hw/nseries.c |7 +++
 3 files changed, 6 insertions(+), 7 deletions(-)

diff --git a/hw/i2c.h b/hw/i2c.h
index 5514402..9381d01 100644
--- a/hw/i2c.h
+++ b/hw/i2c.h
@@ -72,6 +72,6 @@ void wm8750_set_bclk_in(void *opaque, int new_hz);
 void tmp105_set(i2c_slave *i2c, int temp);
 
 /* lm832x.c */
-void lm832x_key_event(i2c_slave *i2c, int key, int state);
+void lm832x_key_event(DeviceState *dev, int key, int state);
 
 #endif
diff --git a/hw/lm832x.c b/hw/lm832x.c
index 590a4cc..992ce49 100644
--- a/hw/lm832x.c
+++ b/hw/lm832x.c
@@ -474,9 +474,9 @@ static int lm8323_init(i2c_slave *i2c)
 return 0;
 }
 
-void lm832x_key_event(struct i2c_slave *i2c, int key, int state)
+void lm832x_key_event(DeviceState *dev, int key, int state)
 {
-LM823KbdState *s = (LM823KbdState *) i2c;
+LM823KbdState *s = FROM_I2C_SLAVE(LM823KbdState, I2C_SLAVE_FROM_QDEV(dev));
 
 if ((s->status & INT_ERROR) && (s->error & ERR_FIFOOVR))
 return;
diff --git a/hw/nseries.c b/hw/nseries.c
index 32f2f53..45b52bb 100644
--- a/hw/nseries.c
+++ b/hw/nseries.c
@@ -45,7 +45,7 @@ struct n800_s {
 i2c_bus *i2c;
 
 int keymap[0x80];
-i2c_slave *kbd;
+DeviceState *kbd;
 
 TUSBState *usb;
 void *retu;
@@ -362,7 +362,6 @@ static int n810_keys[0x80] = {
 static void n810_kbd_setup(struct n800_s *s)
 {
 qemu_irq kbd_irq = qdev_get_gpio_in(s->cpu->gpio, N810_KEYBOARD_GPIO);
-DeviceState *dev;
 int i;
 
 for (i = 0; i < 0x80; i ++)
@@ -375,8 +374,8 @@ static void n810_kbd_setup(struct n800_s *s)
 
 /* Attach the LM8322 keyboard to the I2C bus,
  * should happen in n8x0_i2c_setup and s->kbd be initialised here.  */
-dev = i2c_create_slave(s->i2c, "lm8323", N810_LM8323_ADDR);
-qdev_connect_gpio_out(dev, 0, kbd_irq);
+s->kbd = i2c_create_slave(s->i2c, "lm8323", N810_LM8323_ADDR);
+qdev_connect_gpio_out(s->kbd, 0, kbd_irq);
 }
 
 /* LCD MIPI DBI-C controller (URAL) */
-- 
1.7.1




[Qemu-devel] [PATCH 12/15] onenand: Pass BlockDriverState to init function

2011-07-29 Thread Peter Maydell
Pass the BlockDriverState to the onenand init function so it doesn't
need to look up the drive itself.

Signed-off-by: Peter Maydell 
---
 hw/flash.h   |3 ++-
 hw/nseries.c |   10 ++
 hw/onenand.c |   14 --
 3 files changed, 16 insertions(+), 11 deletions(-)

diff --git a/hw/flash.h b/hw/flash.h
index 43260ce..1aae43d 100644
--- a/hw/flash.h
+++ b/hw/flash.h
@@ -38,7 +38,8 @@ uint32_t nand_getbuswidth(DeviceState *dev);
 /* onenand.c */
 void onenand_base_update(void *opaque, target_phys_addr_t new);
 void onenand_base_unmap(void *opaque);
-void *onenand_init(uint32_t id, int regshift, qemu_irq irq);
+void *onenand_init(BlockDriverState *bdrv, uint32_t id,
+   int regshift, qemu_irq irq);
 void *onenand_raw_otp(void *opaque);
 
 /* ecc.c */
diff --git a/hw/nseries.c b/hw/nseries.c
index 45b52bb..96cc490 100644
--- a/hw/nseries.c
+++ b/hw/nseries.c
@@ -31,6 +31,7 @@
 #include "hw.h"
 #include "bt.h"
 #include "loader.h"
+#include "blockdev.h"
 
 /* Nokia N8x0 support */
 struct n800_s {
@@ -163,13 +164,14 @@ static const uint8_t n8x0_cal_bt_id[] = {
 static void n8x0_nand_setup(struct n800_s *s)
 {
 char *otp_region;
+DriveInfo *dinfo;
 
+dinfo = drive_get(IF_MTD, 0, 0);
 /* Either ec40xx or ec48xx are OK for the ID */
+s->nand = onenand_init(dinfo ? dinfo->bdrv : 0, 0xec4800, 1,
+   qdev_get_gpio_in(s->cpu->gpio, N8X0_ONENAND_GPIO));
 omap_gpmc_attach(s->cpu->gpmc, N8X0_ONENAND_CS, 0, onenand_base_update,
-onenand_base_unmap,
-(s->nand = onenand_init(0xec4800, 1,
-qdev_get_gpio_in(s->cpu->gpio,
-N8X0_ONENAND_GPIO;
+ onenand_base_unmap, s->nand);
 otp_region = onenand_raw_otp(s->nand);
 
 memcpy(otp_region + 0x000, n8x0_cal_wlan_mac, sizeof(n8x0_cal_wlan_mac));
diff --git a/hw/onenand.c b/hw/onenand.c
index 71c1ab4..3a19d7f 100644
--- a/hw/onenand.c
+++ b/hw/onenand.c
@@ -615,10 +615,10 @@ static CPUWriteMemoryFunc * const onenand_writefn[] = {
 onenand_write,
 };
 
-void *onenand_init(uint32_t id, int regshift, qemu_irq irq)
+void *onenand_init(BlockDriverState *bdrv, uint32_t id,
+   int regshift, qemu_irq irq)
 {
 OneNANDState *s = (OneNANDState *) qemu_mallocz(sizeof(*s));
-DriveInfo *dinfo = drive_get(IF_MTD, 0, 0);
 uint32_t size = 1 << (24 + ((id >> 12) & 7));
 void *ram;
 
@@ -632,11 +632,13 @@ void *onenand_init(uint32_t id, int regshift, qemu_irq 
irq)
 s->density_mask = (id & (1 << 11)) ? (1 << (6 + ((id >> 12) & 7))) : 0;
 s->iomemtype = cpu_register_io_memory(onenand_readfn,
 onenand_writefn, s, DEVICE_NATIVE_ENDIAN);
-if (!dinfo)
+s->bdrv = bdrv;
+if (!s->bdrv) {
 s->image = memset(qemu_malloc(size + (size >> 5)),
-0xff, size + (size >> 5));
-else
-s->bdrv = dinfo->bdrv;
+  0xff, size + (size >> 5));
+} else {
+s->bdrv_cur = s->bdrv;
+}
 s->otp = memset(qemu_malloc((64 + 2) << PAGE_SHIFT),
 0xff, (64 + 2) << PAGE_SHIFT);
 s->ram = qemu_ram_alloc(NULL, "onenand.ram", 0xc000 << s->shift);
-- 
1.7.1




[Qemu-devel] [PATCH 09/15] hw/nand: Support multiple reads following READ STATUS

2011-07-29 Thread Peter Maydell
From: Juha Riihimäki 

After receiving READ STATUS command all subsequent IO reads should return
the status register value until another command is issued.

Signed-off-by: Juha Riihimäki 
[Riku Voipio: Fixes and restructuring patchset]
Signed-off-by: Riku Voipio 
[Peter Maydell: More fixes and cleanups for upstream submission]
Signed-off-by:  Peter Maydell 
---
 hw/nand.c |   11 ---
 1 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/hw/nand.c b/hw/nand.c
index 2e98f25..e6c551d 100644
--- a/hw/nand.c
+++ b/hw/nand.c
@@ -496,9 +496,14 @@ uint32_t nand_getio(NANDFlashState *s)
 for (offset = s->buswidth; offset--;) {
 x |= s->ioaddr[offset] << (offset << 3);
 }
-s->addr   += s->buswidth;
-s->ioaddr += s->buswidth;
-s->iolen  -= s->buswidth;
+/* after receiving READ STATUS command all subsequent reads will
+ * return the status register value until another command is issued
+ */
+if (s->cmd != NAND_CMD_READSTATUS) {
+s->addr   += s->buswidth;
+s->ioaddr += s->buswidth;
+s->iolen  -= s->buswidth;
+}
 return x;
 }
 
-- 
1.7.1




[Qemu-devel] [PATCH 02/15] hw/omap_gpio.c: Don't complain about some writes to r/o registers

2011-07-29 Thread Peter Maydell
Don't complain about some writes to r/o OMAP2 GPIO registers, because the
kernel will do them anyway.

Signed-off-by: Peter Maydell 
---
 hw/omap_gpio.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/hw/omap_gpio.c b/hw/omap_gpio.c
index 478f7d9..b53b13b 100644
--- a/hw/omap_gpio.c
+++ b/hw/omap_gpio.c
@@ -385,7 +385,7 @@ static void omap2_gpio_module_write(void *opaque, 
target_phys_addr_t addr,
 case 0x00: /* GPIO_REVISION */
 case 0x14: /* GPIO_SYSSTATUS */
 case 0x38: /* GPIO_DATAIN */
-OMAP_RO_REG(addr);
+/* read-only, ignore quietly */
 break;
 
 case 0x10: /* GPIO_SYSCONFIG */
@@ -531,7 +531,7 @@ static void omap2_gpio_module_writep(void *opaque, 
target_phys_addr_t addr,
 case 0x00: /* GPIO_REVISION */
 case 0x14: /* GPIO_SYSSTATUS */
 case 0x38: /* GPIO_DATAIN */
-OMAP_RO_REG(addr);
+/* read-only, ignore quietly */
 break;
 
 case 0x10: /* GPIO_SYSCONFIG */
-- 
1.7.1




Re: [Qemu-devel] [PATCH V2 1/2] [SLIRP] Simple ARP table

2011-07-29 Thread Jan Kiszka
On 2011-07-29 18:25, Fabien Chouteau wrote:
> This patch adds a simple ARP table in Slirp and also adds handling of
> gratuitous ARP requests.
> 
> Signed-off-by: Fabien Chouteau 
> ---
>  Makefile.objs |2 +-
>  slirp/arp_table.c |   50 ++
>  slirp/bootp.c |   23 --
>  slirp/slirp.c |   63 +---
>  slirp/slirp.h |   50 +++--
>  5 files changed, 129 insertions(+), 59 deletions(-)
>  create mode 100644 slirp/arp_table.c
> 
> diff --git a/Makefile.objs b/Makefile.objs
> index 6991a9f..0c10557 100644
> --- a/Makefile.objs
> +++ b/Makefile.objs
> @@ -151,7 +151,7 @@ common-obj-y += qemu-timer.o qemu-timer-common.o
> 
>  slirp-obj-y = cksum.o if.o ip_icmp.o ip_input.o ip_output.o
>  slirp-obj-y += slirp.o mbuf.o misc.o sbuf.o socket.o tcp_input.o tcp_output.o
> -slirp-obj-y += tcp_subr.o tcp_timer.o udp.o bootp.o tftp.o
> +slirp-obj-y += tcp_subr.o tcp_timer.o udp.o bootp.o tftp.o arp_table.o
>  common-obj-$(CONFIG_SLIRP) += $(addprefix slirp/, $(slirp-obj-y))
> 
>  # xen backend driver support
> diff --git a/slirp/arp_table.c b/slirp/arp_table.c
> new file mode 100644
> index 000..5d7404b
> --- /dev/null
> +++ b/slirp/arp_table.c
> @@ -0,0 +1,50 @@
> +#include "slirp.h"
> +
> +void arp_table_add(ArpTable *arptbl,
> +   int   ip_addr,
> +   uint8_t   ethaddr[ETH_ALEN])

I still prefer the condensed formatting, but that's a minor nit.

> +{
> +int i;
> +
> +DEBUG_CALL("arp_table_add");
> +DEBUG_ARG("ip = 0x%x", ip_addr);
> +DEBUG_ARGS((dfd, " hw addr = %02x:%02x:%02x:%02x:%02x:%02x\n",
> +ethaddr[0], ethaddr[1], ethaddr[2],
> +ethaddr[3], ethaddr[4], ethaddr[5]));
> +
> +/* Search for an entry */
> +for (i = 0; i < ARP_TABLE_SIZE && arptbl->table[i].ar_sip != 0; i++) {

Missed that on round #1: Why treating 0.0.0.0 special? If ip_addr can be
zero, the current logic will append every "update" of that address as a
new entry.

> +if (arptbl->table[i].ar_sip == ip_addr) {
> +/* Update the entry */
> +memcpy(arptbl->table[i].ar_sha, ethaddr, ETH_ALEN);
> +return;
> +}
> +}
> +
> +/* No entry found, create a new one */
> +arptbl->table[arptbl->next_victim].ar_sip = ip_addr;
> +memcpy(arptbl->table[arptbl->next_victim].ar_sha,  ethaddr, ETH_ALEN);
> +arptbl->next_victim = (arptbl->next_victim + 1) % ARP_TABLE_SIZE;
> +}
> +
> +bool arp_table_search(ArpTable *arptbl,
> +  int   in_ip_addr,
> +  uint8_t   out_ethaddr[ETH_ALEN])
> +{
> +int i;
> +
> +DEBUG_CALL("arp_table_search");
> +DEBUG_ARG("ip = 0x%x", in_ip_addr);
> +
> +for (i = 0; i < ARP_TABLE_SIZE; i++) {
> +if (arptbl->table[i].ar_sip == in_ip_addr) {
> +memcpy(out_ethaddr, arptbl->table[i].ar_sha,  ETH_ALEN);
> +DEBUG_ARGS((dfd, " found hw addr = 
> %02x:%02x:%02x:%02x:%02x:%02x\n",
> +out_ethaddr[0], out_ethaddr[1], out_ethaddr[2],
> +out_ethaddr[3], out_ethaddr[4], out_ethaddr[5]));
> +return 1;
> +}
> +}
> +
> +return 0;
> +}
> diff --git a/slirp/bootp.c b/slirp/bootp.c
> index 1eb2ed1..07cbb80 100644
> --- a/slirp/bootp.c
> +++ b/slirp/bootp.c
> @@ -149,6 +149,7 @@ static void bootp_reply(Slirp *slirp, const struct 
> bootp_t *bp)
>  struct in_addr preq_addr;
>  int dhcp_msg_type, val;
>  uint8_t *q;
> +uint8_t client_ethaddr[ETH_ALEN];
> 
>  /* extract exact DHCP msg type */
>  dhcp_decode(bp, &dhcp_msg_type, &preq_addr);
> @@ -164,8 +165,9 @@ static void bootp_reply(Slirp *slirp, const struct 
> bootp_t *bp)
>  if (dhcp_msg_type != DHCPDISCOVER &&
>  dhcp_msg_type != DHCPREQUEST)
>  return;
> -/* XXX: this is a hack to get the client mac address */
> -memcpy(slirp->client_ethaddr, bp->bp_hwaddr, 6);
> +
> +/* Get client's hardware address from bootp request */
> +memcpy(client_ethaddr, bp->bp_hwaddr, ETH_ALEN);
> 
>  m = m_get(slirp);
>  if (!m) {
> @@ -178,25 +180,25 @@ static void bootp_reply(Slirp *slirp, const struct 
> bootp_t *bp)
> 
>  if (dhcp_msg_type == DHCPDISCOVER) {
>  if (preq_addr.s_addr != htonl(0L)) {
> -bc = request_addr(slirp, &preq_addr, slirp->client_ethaddr);
> +bc = request_addr(slirp, &preq_addr, client_ethaddr);
>  if (bc) {
>  daddr.sin_addr = preq_addr;
>  }
>  }
>  if (!bc) {
>   new_addr:
> -bc = get_new_addr(slirp, &daddr.sin_addr, slirp->client_ethaddr);
> +bc = get_new_addr(slirp, &daddr.sin_addr, client_ethaddr);
>  if (!bc) {
>  DPRINTF("no address left\n");
>  return;
>  }
>  }
> -   

Re: [Qemu-devel] [PATCH V2 2/2] [SLIRP] Delayed IP packets

2011-07-29 Thread Jan Kiszka
On 2011-07-29 18:25, Fabien Chouteau wrote:
> In the current implementation, if Slirp tries to send an IP packet to a client
> with an unknown hardware address, the packet is simply dropped and an ARP
> request is sent (if_encap in slirp/slirp.c).
> 
> With this patch, Slirp will send the ARP request, re-queue the packet and try
> to send it later. The packet is dropped after one second if the ARP reply is
> not received.
> 
> Signed-off-by: Fabien Chouteau 
> ---
>  slirp/if.c|   28 ---
>  slirp/main.h  |2 +-
>  slirp/mbuf.c  |2 +
>  slirp/mbuf.h  |2 +
>  slirp/slirp.c |   67 ++--
>  slirp/slirp.h |   15 
>  6 files changed, 80 insertions(+), 36 deletions(-)
> 
> diff --git a/slirp/if.c b/slirp/if.c
> index 0f04e13..80a5c4e 100644
> --- a/slirp/if.c
> +++ b/slirp/if.c
> @@ -6,6 +6,7 @@
>   */
>  
>  #include 
> +#include "qemu-timer.h"
>  
>  #define ifs_init(ifm) ((ifm)->ifs_next = (ifm)->ifs_prev = (ifm))
>  
> @@ -105,6 +106,9 @@ if_output(struct socket *so, struct mbuf *ifm)
>   ifs_init(ifm);
>   insque(ifm, ifq);
>  
> +/* Expiration date = Now + 1 second */
> +ifm->expiration_date = qemu_get_clock_ns(vm_clock) + 10ULL;

Slirp uses rt_clock for expiry, let's stick with that clock.

> +
>  diddit:
>   slirp->if_queued++;
>  
> @@ -153,6 +157,9 @@ diddit:
>  void
>  if_start(Slirp *slirp)
>  {
> +int requeued = 0;
> +uint64_t now;
> +
>   struct mbuf *ifm, *ifqt;
>  
>   DEBUG_CALL("if_start");
> @@ -165,6 +172,8 @@ if_start(Slirp *slirp)
>  if (!slirp_can_output(slirp->opaque))
>  return;
>  
> +now = qemu_get_clock_ns(vm_clock);
> +
>   /*
>* See which queue to get next packet from
>* If there's something in the fastq, select it immediately
> @@ -199,11 +208,22 @@ if_start(Slirp *slirp)
>  ifm->ifq_so->so_nqueued = 0;
>   }
>  
> - /* Encapsulate the packet for sending */
> -if_encap(slirp, (uint8_t *)ifm->m_data, ifm->m_len);
> -
> -m_free(ifm);
> +if (ifm->expiration_date < now) {
> +/* Expired */
> +m_free(ifm);
> +} else {
> +/* Encapsulate the packet for sending */
> +if (if_encap(slirp, ifm)) {
> +m_free(ifm);
> +} else {
> +/* re-queue */
> +insque(ifm, ifqt);
> +requeued++;
> +}
> +}
>  
>   if (slirp->if_queued)
>  goto again;
> +
> +slirp->if_queued = requeued;
>  }
> diff --git a/slirp/main.h b/slirp/main.h
> index 0dd8d81..028df4b 100644
> --- a/slirp/main.h
> +++ b/slirp/main.h
> @@ -42,5 +42,5 @@ extern int tcp_keepintvl;
>  #define PROTO_PPP 0x2
>  #endif
>  
> -void if_encap(Slirp *slirp, const uint8_t *ip_data, int ip_data_len);
> +int if_encap(Slirp *slirp, struct mbuf *ifm);
>  ssize_t slirp_send(struct socket *so, const void *buf, size_t len, int 
> flags);
> diff --git a/slirp/mbuf.c b/slirp/mbuf.c
> index ce2eb84..c699c75 100644
> --- a/slirp/mbuf.c
> +++ b/slirp/mbuf.c
> @@ -70,6 +70,8 @@ m_get(Slirp *slirp)
>   m->m_len = 0;
>  m->m_nextpkt = NULL;
>  m->m_prevpkt = NULL;
> +m->arp_requested = false;
> +m->expiration_date = (uint64_t)-1;
>  end_error:
>   DEBUG_ARG("m = %lx", (long )m);
>   return m;
> diff --git a/slirp/mbuf.h b/slirp/mbuf.h
> index b74544b..55170e5 100644
> --- a/slirp/mbuf.h
> +++ b/slirp/mbuf.h
> @@ -86,6 +86,8 @@ struct mbuf {
>   charm_dat_[1]; /* ANSI don't like 0 sized arrays */
>   char*m_ext_;
>   } M_dat;
> +bool arp_requested;
> +uint64_t expiration_date;
>  };
>  
>  #define m_next   m_hdr.mh_next
> diff --git a/slirp/slirp.c b/slirp/slirp.c
> index ba76757..b006620 100644
> --- a/slirp/slirp.c
> +++ b/slirp/slirp.c
> @@ -237,6 +237,8 @@ Slirp *slirp_init(int restricted, struct in_addr vnetwork,
>  
>  QTAILQ_INSERT_TAIL(&slirp_instances, slirp, entry);
>  
> +slirp->delayed = NULL;
> +
>  return slirp;
>  }
>  
> @@ -693,54 +695,57 @@ void slirp_input(Slirp *slirp, const uint8_t *pkt, int 
> pkt_len)
>  }
>  
>  /* output the IP packet to the ethernet device */
> -void if_encap(Slirp *slirp, const uint8_t *ip_data, int ip_data_len)
> +int if_encap(Slirp *slirp, struct mbuf *ifm)
>  {
>  uint8_t buf[1600];
>  struct ethhdr *eh = (struct ethhdr *)buf;
>  uint8_t ethaddr[ETH_ALEN];
> -const struct ip *iph = (const struct ip *)ip_data;
> +const struct ip *iph = (const struct ip *)ifm->m_data;
>  
> -if (ip_data_len + ETH_HLEN > sizeof(buf))
> -return;
> +if (ifm->m_len + ETH_HLEN > sizeof(buf))
> +return 1;

Even if the old cold lacked them as well: { }

>  
>  if (!arp_table_search(&slirp->arp_table, iph->ip_dst.s_addr, ethaddr)) {
>  uint8_t arp_req[ETH_HLEN + sizeof

Re: [Qemu-devel] [libvirt] How to connect to the running VM

2011-07-29 Thread bala suru
Hi,
Let me tell clearly ,

i'm trying to manage VMs using opennebula toolkit , I downloaded the
ttylinux image from opennebula site , the Image I downloaded was already
created from kvm by opennebula community , so I  can use it to deploy on
kvm. link for this is - > http://opennebula.org/documentation:rel2.2:vmg
Since this is very old version ,and I need new version of ttylinux , so I
can download new version of ttylinux.iso disc file from ttylinx site .

Hence  I need  to create  image  from  KVM of  dvd or iso disc file . Once I
created in KVM then I can copy the image to opennebula tool kit and register
it .

Therefore I need to create a image out of  ttylinux.iso disc file
pls tell me how to do it..?


regards
Bala



On Fri, Jul 29, 2011 at 10:46 AM, Dave Allan  wrote:

> On Fri, Jul 29, 2011 at 10:36:48AM -0700, bala suru wrote:
> > Hi,
> > Can you suggest any links /docs which explain  the  kvm image creation
> steps
> > ..?
>
> Replying on list for the benefit of everyone.
>
> I don't know what you're referring to when you say kvm image.  Are you
> asking how to install the OS in the guest?
>
> Dave
>
> > rgds
> >
> > On Fri, Jul 29, 2011 at 9:17 AM, Dave Allan  wrote:
> >
> > > On Fri, Jul 29, 2011 at 05:06:06PM +0530, bala suru wrote:
> > > > Hi,
> > > > I have deployed some VM on to the KVM-qemu and installed libvirtd ..
> > > >
> > > > I could see the VM running by command virsh list .
> > > >
> > > > but how to login to the VMs other than SSH ..? i tried virsh
> vncdisplay ,
> > > > but no output ..
> > >
> > > virt-viewer 
> > >
> > > will give you the graphical console if you have one set up.
> > >
> > > virt-manager gives you both graphical console and a graphical
> > > interface to configure the VM.
> > >
> > > Dave
> > >
> > > > regards
> > > > bala
> > >
> > > > --
> > > > libvir-list mailing list
> > > > libvir-l...@redhat.com
> > > > https://www.redhat.com/mailman/listinfo/libvir-list
> > >
> > >
>


[Qemu-devel] [PATCH] Fix gcc-4.6 compiler error

2011-07-29 Thread Stefan Weil
Commit 3d3b8303c6f83b9b245bc774af530a6403cc4ce6
breaks builds with gcc-4.6:

hw/fw_cfg.c: In function ‘probe_splashfile’:
hw/fw_cfg.c:66:9: error: variable ‘fop_ret’ set but not used 
[-Werror=unused-but-set-variable]
hw/fw_cfg.c: In function ‘fw_cfg_bootsplash’:
hw/fw_cfg.c:130:9: error: variable ‘fop_ret’ set but not used 
[-Werror=unused-but-set-variable]

Remove fop_ret. Testing the result of fread() is normally
a good idea, but I don't think it is needed here.

Cc: Wayne Xia 
Cc: Anthony Liguori 
Signed-off-by: Stefan Weil 
---
 hw/fw_cfg.c |8 +++-
 1 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/hw/fw_cfg.c b/hw/fw_cfg.c
index a29db90..d906b83 100644
--- a/hw/fw_cfg.c
+++ b/hw/fw_cfg.c
@@ -63,7 +63,6 @@ struct FWCfgState {
 static FILE *probe_splashfile(char *filename, int *file_sizep, int *file_typep)
 {
 FILE *fp = NULL;
-int fop_ret;
 int file_size;
 int file_type = -1;
 unsigned char buf[2] = {0, 0};
@@ -86,7 +85,7 @@ static FILE *probe_splashfile(char *filename, int 
*file_sizep, int *file_typep)
 }
 /* check magic ID */
 fseek(fp, 0L, SEEK_SET);
-fop_ret = fread(buf, 1, 2, fp);
+(void)fread(buf, 1, 2, fp);
 filehead_value = (buf[0] + (buf[1] << 8)) & 0x;
 if (filehead_value == 0xd8ff) {
 file_type = JPG_FILE;
@@ -105,7 +104,7 @@ static FILE *probe_splashfile(char *filename, int 
*file_sizep, int *file_typep)
 /* check BMP bpp */
 if (file_type == BMP_FILE) {
 fseek(fp, 28, SEEK_SET);
-fop_ret = fread(buf, 1, 2, fp);
+(void)fread(buf, 1, 2, fp);
 bmp_bpp = (buf[0] + (buf[1] << 8)) & 0x;
 if (bmp_bpp != 24) {
 error_report("only 24bpp bmp file is supported.");
@@ -127,7 +126,6 @@ static void fw_cfg_bootsplash(FWCfgState *s)
 char *p;
 char *filename;
 FILE *fp;
-int fop_ret;
 int file_size;
 int file_type = -1;
 const char *temp;
@@ -180,7 +178,7 @@ static void fw_cfg_bootsplash(FWCfgState *s)
 boot_splash_filedata = qemu_malloc(file_size);
 boot_splash_filedata_size = file_size;
 fseek(fp, 0L, SEEK_SET);
-fop_ret = fread(boot_splash_filedata, 1, file_size, fp);
+(void)fread(boot_splash_filedata, 1, file_size, fp);
 fclose(fp);
 /* insert data */
 if (file_type == JPG_FILE) {
-- 
1.7.2.5




[Qemu-devel] [PATCH] tcg/arm: Fix compiler error caused by unused function

2011-07-29 Thread Stefan Weil
Function tcg_out_addi is obviously unused and causes a compiler
error (tested with cross compilation on x86 Debian Linux):

tcg/arm/tcg-target.c:1824: error: ‘tcg_out_addi’ defined but not used

Don't remove it because it might be useful in the future,
but declare it inline. This fixes the compiler error and
is similar to other tcg targets.

Cc: Andrzej Zaborowski 
Signed-off-by: Stefan Weil 
---
 tcg/arm/tcg-target.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/tcg/arm/tcg-target.c b/tcg/arm/tcg-target.c
index 93eb0f1..c94a354 100644
--- a/tcg/arm/tcg-target.c
+++ b/tcg/arm/tcg-target.c
@@ -1820,7 +1820,7 @@ static inline void tcg_out_st(TCGContext *s, TCGType 
type, int arg,
 tcg_out_st32(s, COND_AL, arg, arg1, arg2);
 }
 
-static void tcg_out_addi(TCGContext *s, int reg, tcg_target_long val)
+static inline void tcg_out_addi(TCGContext *s, int reg, tcg_target_long val)
 {
 if (val > 0)
 if (val < 0x100)
-- 
1.7.2.5




[Qemu-devel] [PATCH] configure: Fix bad shell expression for non-Linux hosts

2011-07-29 Thread Stefan Weil
With vhost_net="" (most non-Linux hosts), configure prints an
error message:

test: 2551: =: unexpected operator

Fix this and similar code by adding the missing "".

Cc: Wolfgang Mauerer 
Cc: Stefan Hajnoczi 
Signed-off-by: Stefan Weil 
---
 configure |8 
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/configure b/configure
index b582f5e..001208d 100755
--- a/configure
+++ b/configure
@@ -2521,7 +2521,7 @@ fi
 # __sync_fetch_and_and requires at least -march=i486. Many toolchains
 # use i686 as default anyway, but for those that don't, an explicit
 # specification is necessary
-if test $vhost_net = "yes" && test $cpu = "i386"; then
+if test "$vhost_net" = "yes" && test "$cpu" = "i386"; then
   cat > $TMPC << EOF
 int sfaa(unsigned *ptr)
 {
@@ -2700,7 +2700,7 @@ echo "nss used  $smartcard_nss"
 echo "usb net redir $usb_redir"
 echo "OpenGL support$opengl"
 
-if test $sdl_too_old = "yes"; then
+if test "$sdl_too_old" = "yes"; then
 echo "-> Your SDL version is too old - please upgrade to have SDL support"
 fi
 
@@ -2788,7 +2788,7 @@ fi
 if test "$static" = "yes" ; then
   echo "CONFIG_STATIC=y" >> $config_host_mak
 fi
-if test $profiler = "yes" ; then
+if test "$profiler" = "yes" ; then
   echo "CONFIG_PROFILER=y" >> $config_host_mak
 fi
 if test "$slirp" = "yes" ; then
@@ -3342,7 +3342,7 @@ case "$target_arch2" in
   \( "$target_arch2" = "x86_64" -a "$cpu" = "i386"   \) -o \
   \( "$target_arch2" = "i386"   -a "$cpu" = "x86_64" \) \) ; then
   echo "CONFIG_KVM=y" >> $config_target_mak
-  if test $vhost_net = "yes" ; then
+  if test "$vhost_net" = "yes" ; then
 echo "CONFIG_VHOST_NET=y" >> $config_target_mak
   fi
 fi
-- 
1.7.2.5




[Qemu-devel] [RFC PATCH v2 0/3] separate thread for VM migration

2011-07-29 Thread Umesh Deshpande
Following patch deals with VCPU and iothread starvation during the migration of
a guest. Currently the iothread is responsible for performing the guest
migration. It holds qemu_mutex during the migration and doesn't allow VCPU to
enter the qemu mode and delays its return to the guest. The guest migration,
executed as an iohandler also delays the execution of other iohandlers.
In the following patch series,

The migration has been moved to a separate thread to
reduce the qemu_mutex contention and iohandler starvation.

Also current dirty bitmap is split into per memslot bitmap to reduce its size.

Umesh Deshpande (3):
  separate thread for VM migration
  fine grained qemu_mutex locking for migration
  per memslot dirty bitmap

 arch_init.c |   14 ++--
 buffered_file.c |   28 -
 buffered_file.h |4 +++
 cpu-all.h   |   40 ++--
 exec.c  |   38 +-
 migration.c |   60 --
 migration.h |3 ++
 savevm.c|   22 +---
 savevm.h|   29 ++
 xen-all.c   |6 +---
 10 files changed, 173 insertions(+), 71 deletions(-)
 create mode 100644 savevm.h

-- 
1.7.4.1




[Qemu-devel] [RFC PATCH v2 1/3] separate thread for VM migration

2011-07-29 Thread Umesh Deshpande
This patch creates a separate thread for the guest migration on the source side.

Signed-off-by: Umesh Deshpande 
---
 buffered_file.c |   28 -
 buffered_file.h |4 +++
 migration.c |   59 +++---
 migration.h |3 ++
 savevm.c|   22 +---
 savevm.h|   29 +++
 6 files changed, 102 insertions(+), 43 deletions(-)
 create mode 100644 savevm.h

diff --git a/buffered_file.c b/buffered_file.c
index 41b42c3..d4146bf 100644
--- a/buffered_file.c
+++ b/buffered_file.c
@@ -16,12 +16,16 @@
 #include "qemu-timer.h"
 #include "qemu-char.h"
 #include "buffered_file.h"
+#include "migration.h"
+#include "savevm.h"
+#include "qemu-thread.h"
 
 //#define DEBUG_BUFFERED_FILE
 
 typedef struct QEMUFileBuffered
 {
 BufferedPutFunc *put_buffer;
+BufferedBeginFunc *begin;
 BufferedPutReadyFunc *put_ready;
 BufferedWaitForUnfreezeFunc *wait_for_unfreeze;
 BufferedCloseFunc *close;
@@ -35,6 +39,7 @@ typedef struct QEMUFileBuffered
 size_t buffer_size;
 size_t buffer_capacity;
 QEMUTimer *timer;
+QemuThread thread;
 } QEMUFileBuffered;
 
 #ifdef DEBUG_BUFFERED_FILE
@@ -181,8 +186,6 @@ static int buffered_close(void *opaque)
 
 ret = s->close(s->opaque);
 
-qemu_del_timer(s->timer);
-qemu_free_timer(s->timer);
 qemu_free(s->buffer);
 qemu_free(s);
 
@@ -228,17 +231,15 @@ static int64_t buffered_get_rate_limit(void *opaque)
 return s->xfer_limit;
 }
 
-static void buffered_rate_tick(void *opaque)
+void buffered_rate_tick(QEMUFile *file)
 {
-QEMUFileBuffered *s = opaque;
+QEMUFileBuffered *s = file->opaque;
 
 if (s->has_error) {
 buffered_close(s);
 return;
 }
 
-qemu_mod_timer(s->timer, qemu_get_clock_ms(rt_clock) + 100);
-
 if (s->freeze_output)
 return;
 
@@ -250,9 +251,17 @@ static void buffered_rate_tick(void *opaque)
 s->put_ready(s->opaque);
 }
 
+static void *migrate_vm(void *opaque)
+{
+QEMUFileBuffered *s = opaque;
+s->begin(s->opaque);
+return NULL;
+}
+
 QEMUFile *qemu_fopen_ops_buffered(void *opaque,
   size_t bytes_per_sec,
   BufferedPutFunc *put_buffer,
+  BufferedBeginFunc *begin,
   BufferedPutReadyFunc *put_ready,
   BufferedWaitForUnfreezeFunc 
*wait_for_unfreeze,
   BufferedCloseFunc *close)
@@ -264,6 +273,7 @@ QEMUFile *qemu_fopen_ops_buffered(void *opaque,
 s->opaque = opaque;
 s->xfer_limit = bytes_per_sec / 10;
 s->put_buffer = put_buffer;
+s->begin = begin;
 s->put_ready = put_ready;
 s->wait_for_unfreeze = wait_for_unfreeze;
 s->close = close;
@@ -271,11 +281,9 @@ QEMUFile *qemu_fopen_ops_buffered(void *opaque,
 s->file = qemu_fopen_ops(s, buffered_put_buffer, NULL,
  buffered_close, buffered_rate_limit,
  buffered_set_rate_limit,
-buffered_get_rate_limit);
-
-s->timer = qemu_new_timer_ms(rt_clock, buffered_rate_tick, s);
+ buffered_get_rate_limit);
 
-qemu_mod_timer(s->timer, qemu_get_clock_ms(rt_clock) + 100);
+qemu_thread_create(&s->thread, migrate_vm, s);
 
 return s->file;
 }
diff --git a/buffered_file.h b/buffered_file.h
index 98d358b..cfe2833 100644
--- a/buffered_file.h
+++ b/buffered_file.h
@@ -17,12 +17,16 @@
 #include "hw/hw.h"
 
 typedef ssize_t (BufferedPutFunc)(void *opaque, const void *data, size_t size);
+typedef void (BufferedBeginFunc)(void *opaque);
 typedef void (BufferedPutReadyFunc)(void *opaque);
 typedef void (BufferedWaitForUnfreezeFunc)(void *opaque);
 typedef int (BufferedCloseFunc)(void *opaque);
 
+void buffered_rate_tick(QEMUFile *file);
+
 QEMUFile *qemu_fopen_ops_buffered(void *opaque, size_t xfer_limit,
   BufferedPutFunc *put_buffer,
+  BufferedBeginFunc *begin,
   BufferedPutReadyFunc *put_ready,
   BufferedWaitForUnfreezeFunc 
*wait_for_unfreeze,
   BufferedCloseFunc *close);
diff --git a/migration.c b/migration.c
index af3a1f2..bf86067 100644
--- a/migration.c
+++ b/migration.c
@@ -31,6 +31,8 @@
 do { } while (0)
 #endif
 
+static int64_t expire_time;
+
 /* Migration speed throttling */
 static int64_t max_throttle = (32 << 20);
 
@@ -284,8 +286,6 @@ int migrate_fd_cleanup(FdMigrationState *s)
 {
 int ret = 0;
 
-qemu_set_fd_handler2(s->fd, NULL, NULL, NULL, NULL);
-
 if (s->file) {
 DPRINTF("closing file\n");
 if (qemu_fclose(s->file) != 0) {
@@ -310,8 +310,7 @@ int migrate_fd_cleanup(FdMigrationState *s)
 void migrate_fd_put_notify(void *opaque)
 {
 FdMigrationState *s = op

[Qemu-devel] [RFC PATCH v2 2/3] fine grained qemu_mutex locking for migration

2011-07-29 Thread Umesh Deshpande
In the migration thread, qemu_mutex is released during the most time consuming
part. i.e. during is_dup_page which identifies the uniform data pages and during
the put_buffer. qemu_mutex is also released while blocking on select to wait for
the descriptor to become ready for writes.

Signed-off-by: Umesh Deshpande 
---
 arch_init.c |   14 +++---
 migration.c |   11 +++
 2 files changed, 18 insertions(+), 7 deletions(-)

diff --git a/arch_init.c b/arch_init.c
index 484b39d..cd545bc 100644
--- a/arch_init.c
+++ b/arch_init.c
@@ -110,7 +110,7 @@ static int is_dup_page(uint8_t *page, uint8_t ch)
 static RAMBlock *last_block;
 static ram_addr_t last_offset;
 
-static int ram_save_block(QEMUFile *f)
+static int ram_save_block(QEMUFile *f, int stage)
 {
 RAMBlock *block = last_block;
 ram_addr_t offset = last_offset;
@@ -131,6 +131,10 @@ static int ram_save_block(QEMUFile *f)
 current_addr + TARGET_PAGE_SIZE,
 MIGRATION_DIRTY_FLAG);
 
+if (stage != 3) {
+qemu_mutex_unlock_iothread();
+}
+
 p = block->host + offset;
 
 if (is_dup_page(p, *p)) {
@@ -153,6 +157,10 @@ static int ram_save_block(QEMUFile *f)
 bytes_sent = TARGET_PAGE_SIZE;
 }
 
+if (stage != 3) {
+qemu_mutex_lock_iothread();
+}
+
 break;
 }
 
@@ -301,7 +309,7 @@ int ram_save_live(Monitor *mon, QEMUFile *f, int stage, 
void *opaque)
 while (!qemu_file_rate_limit(f)) {
 int bytes_sent;
 
-bytes_sent = ram_save_block(f);
+bytes_sent = ram_save_block(f, stage);
 bytes_transferred += bytes_sent;
 if (bytes_sent == 0) { /* no more blocks */
 break;
@@ -322,7 +330,7 @@ int ram_save_live(Monitor *mon, QEMUFile *f, int stage, 
void *opaque)
 int bytes_sent;
 
 /* flush all remaining blocks regardless of rate limiting */
-while ((bytes_sent = ram_save_block(f)) != 0) {
+while ((bytes_sent = ram_save_block(f, stage)) != 0) {
 bytes_transferred += bytes_sent;
 }
 cpu_physical_memory_set_dirty_tracking(0);
diff --git a/migration.c b/migration.c
index bf86067..992fef5 100644
--- a/migration.c
+++ b/migration.c
@@ -375,15 +375,19 @@ void migrate_fd_begin(void *arg)
 if (ret < 0) {
 DPRINTF("failed, %d\n", ret);
 migrate_fd_error(s);
-goto out;
+qemu_mutex_unlock_iothread();
+return;
 }
 
 expire_time = qemu_get_clock_ms(rt_clock) + 100;
 migrate_fd_put_ready(s);
+qemu_mutex_unlock_iothread();
 
 while (s->state == MIG_STATE_ACTIVE) {
 if (migrate_fd_check_expire()) {
+qemu_mutex_lock_iothread();
 buffered_rate_tick(s->file);
+qemu_mutex_unlock_iothread();
 }
 
 if (s->state != MIG_STATE_ACTIVE) {
@@ -392,12 +396,11 @@ void migrate_fd_begin(void *arg)
 
 if (s->callback) {
 migrate_fd_wait_for_unfreeze(s);
+qemu_mutex_lock_iothread();
 s->callback(s);
+qemu_mutex_unlock_iothread();
 }
 }
-
-out:
-qemu_mutex_unlock_iothread();
 }
 
 
-- 
1.7.4.1




[Qemu-devel] [RFC PATCH v2 3/3] Per memslot dirty bitmap

2011-07-29 Thread Umesh Deshpande
This patch creates a separate dirty bitmap for each slot. Currently dirty bitmap
is created for addresses ranging from 0 to the end address of the last memory
slot. Since the memslots are not necessarily contiguous, current bitmap might
contain empty region or holes that doesn't represent any VM pages. This patch
reduces the size of the dirty bitmap by allocating per memslot dirty bitmaps.

Signed-off-by: Umesh Deshpande 
---
 cpu-all.h |   40 +---
 exec.c|   38 +++---
 xen-all.c |6 ++
 3 files changed, 58 insertions(+), 26 deletions(-)

diff --git a/cpu-all.h b/cpu-all.h
index e839100..9517a9b 100644
--- a/cpu-all.h
+++ b/cpu-all.h
@@ -920,6 +920,7 @@ extern ram_addr_t ram_size;
 
 typedef struct RAMBlock {
 uint8_t *host;
+uint8_t *phys_dirty;
 ram_addr_t offset;
 ram_addr_t length;
 uint32_t flags;
@@ -931,7 +932,6 @@ typedef struct RAMBlock {
 } RAMBlock;
 
 typedef struct RAMList {
-uint8_t *phys_dirty;
 QLIST_HEAD(ram, RAMBlock) blocks;
 } RAMList;
 extern RAMList ram_list;
@@ -961,32 +961,55 @@ extern int mem_prealloc;
 #define CODE_DIRTY_FLAG  0x02
 #define MIGRATION_DIRTY_FLAG 0x08
 
+RAMBlock *qemu_addr_to_ramblock(ram_addr_t);
+
+static inline int get_page_nr(ram_addr_t addr, RAMBlock **block)
+{
+int page_nr;
+*block = qemu_addr_to_ramblock(addr);
+
+page_nr = addr - (*block)->offset;
+page_nr = page_nr >> TARGET_PAGE_BITS;
+
+return page_nr;
+}
+
 /* read dirty bit (return 0 or 1) */
 static inline int cpu_physical_memory_is_dirty(ram_addr_t addr)
 {
-return ram_list.phys_dirty[addr >> TARGET_PAGE_BITS] == 0xff;
+RAMBlock *block;
+int page_nr = get_page_nr(addr, &block);
+return block->phys_dirty[page_nr] == 0xff;
 }
 
 static inline int cpu_physical_memory_get_dirty_flags(ram_addr_t addr)
 {
-return ram_list.phys_dirty[addr >> TARGET_PAGE_BITS];
+RAMBlock *block;
+int page_nr = get_page_nr(addr, &block);
+return block->phys_dirty[page_nr];
 }
 
 static inline int cpu_physical_memory_get_dirty(ram_addr_t addr,
 int dirty_flags)
 {
-return ram_list.phys_dirty[addr >> TARGET_PAGE_BITS] & dirty_flags;
+RAMBlock *block;
+int page_nr = get_page_nr(addr, &block);
+return block->phys_dirty[page_nr] & dirty_flags;
 }
 
 static inline void cpu_physical_memory_set_dirty(ram_addr_t addr)
 {
-ram_list.phys_dirty[addr >> TARGET_PAGE_BITS] = 0xff;
+RAMBlock *block;
+int page_nr = get_page_nr(addr, &block);
+block->phys_dirty[page_nr] = 0xff;
 }
 
 static inline int cpu_physical_memory_set_dirty_flags(ram_addr_t addr,
   int dirty_flags)
 {
-return ram_list.phys_dirty[addr >> TARGET_PAGE_BITS] |= dirty_flags;
+RAMBlock *block;
+int page_nr = get_page_nr(addr, &block);
+return block->phys_dirty[page_nr] |= dirty_flags;
 }
 
 static inline void cpu_physical_memory_mask_dirty_range(ram_addr_t start,
@@ -995,10 +1018,13 @@ static inline void 
cpu_physical_memory_mask_dirty_range(ram_addr_t start,
 {
 int i, mask, len;
 uint8_t *p;
+RAMBlock *block;
+int page_nr = get_page_nr(start, &block);
 
 len = length >> TARGET_PAGE_BITS;
 mask = ~dirty_flags;
-p = ram_list.phys_dirty + (start >> TARGET_PAGE_BITS);
+
+p = block->phys_dirty + page_nr;
 for (i = 0; i < len; i++) {
 p[i] &= mask;
 }
diff --git a/exec.c b/exec.c
index 0e2ce57..6312550 100644
--- a/exec.c
+++ b/exec.c
@@ -2106,6 +2106,10 @@ void cpu_physical_memory_reset_dirty(ram_addr_t start, 
ram_addr_t end,
 abort();
 }
 
+if (kvm_enabled()) {
+return;
+}
+
 for(env = first_cpu; env != NULL; env = env->next_cpu) {
 int mmu_idx;
 for (mmu_idx = 0; mmu_idx < NB_MMU_MODES; mmu_idx++) {
@@ -2894,17 +2898,6 @@ static ram_addr_t find_ram_offset(ram_addr_t size)
 return offset;
 }
 
-static ram_addr_t last_ram_offset(void)
-{
-RAMBlock *block;
-ram_addr_t last = 0;
-
-QLIST_FOREACH(block, &ram_list.blocks, next)
-last = MAX(last, block->offset + block->length);
-
-return last;
-}
-
 ram_addr_t qemu_ram_alloc_from_ptr(DeviceState *dev, const char *name,
ram_addr_t size, void *host)
 {
@@ -2974,10 +2967,8 @@ ram_addr_t qemu_ram_alloc_from_ptr(DeviceState *dev, 
const char *name,
 
 QLIST_INSERT_HEAD(&ram_list.blocks, new_block, next);
 
-ram_list.phys_dirty = qemu_realloc(ram_list.phys_dirty,
-   last_ram_offset() >> TARGET_PAGE_BITS);
-memset(ram_list.phys_dirty + (new_block->offset >> TARGET_PAGE_BITS),
-   0xff, size >> TARGET_PAGE_BITS);
+new_block->phys_dirty = qemu_mallocz(new_block->length >> 
TARGET_PAGE_BITS);
+memset(new_block->phys_dirty, 0xff, new_block->length >> TARGET_PAGE_BITS);
 
 if (kvm_enabled())
 kvm_setup_gu

Re: [Qemu-devel] [RFC PATCH 0/4] Fix subsection ambiguity in the migration format

2011-07-29 Thread Anthony Liguori

On 07/29/2011 10:18 AM, Kevin Wolf wrote:

Am 29.07.2011 16:28, schrieb Anthony Liguori:

The one change for backends is that if we migrate a device in way so
that it can say "I need the block backend with the ID 'foo'", then we
can at least make sure that the backend actually exists and is usable.


Yup.  So with QOM, this could work in a couple ways.

You could dump the full graph including the backends, and then recreate 
it but not realize any objects.  This would give you a chance to make 
changes to things like the block device filenames.  It could be as 
simple as just changing the filename of a device, or deleting a complex 
block device chain (from backing files) and replacing it with something 
totally different.


I think the common case is that the backends are much the same so I 
think an interface centered around recreating the backends verbatim but 
allowing tweaks would probably be the friendliest.


We could also require that the backends are created before we migrate 
the device model.  In QOM, while you would be allowed to create a 
virtio-blk device, when you tried to set the drive property to 'foo', 
you'd get an error unless the 'foo' backend existed and was of the 
appropriate type.


Since it's pretty easy to enumerate the required backends, it's really 
not so bad for the management tools to do this work.  My only concern is 
that this all has to happen in the migration downtime window in order 
for hotplug to work robustly.





The result is that introspecting what's there and recreating it is
insanely complex today.

That's the motivation behind QOM.  plug_list lists *everything*.  All
objects, whether they are created as part of the PIIX3 or whether it's a
backing file, can be directly addressed and manipulated.

If you look at qsh, there's an import command.  The export command is
trivial and I don't remember if I've already added it.  But the point is
that you should be able to 'qsh export' everything and then 'qsh import'
everything to create the exact same device model in another QEMU instance.

And yeah, this should end up becoming part of the migration protocol.


If all you're saying is that we can't get it tomorrow, that's fine for
me. Good to know that we agree on the goal anyway.


Yup :-)



5) Once we're here, we can implement the next 5-year format.  That
could be ASN.1 and be bidirectional or whatever makes the most sense.
We could support 50 formats if we wanted to.  As long as the transport
is distinct from the serialization and compat routines, it really
doesn't matter.


This means finishing the VMState support, once there, only thing needs
to change is "copy" the savevm, and change the "visitors" to whatever
else that we need/want.


There's no need to "finish" VMState to convert to visitors.  It's just
sed -e 's:qemu_put_be32:visit_type_int32:g'


Actually I think the real question is whether we want to have VMState or
not.


VMState doesn't give me what I want by itself.

I want to be able to marshal the device tree to an in-memory
representation that can be manipulated.  One approach to doing that is
first completing VMState, and then writing something that can walk the
VMState descriptions.  The VMState descriptions are fairly complicated
but it's doable.

Another approach, which I'm arguing is much simpler, the imperative
nature of our current serialization and use visitors.

There may be other advantages of a declarative description of VMState
that would justify completing the conversions.  But I don't think we
need it to start improving the migration protocol.


Yeah, I somehow read it as "there's no reason to continue with
converting to VMState", which isn't what you were saying.


No, not at all.  Just that converting everything to VMState isn't a 
prerequisite for building a more robust migration protocol.


Regards,

Anthony Liguori


Kevin






[Qemu-devel] [PATCH] Fix forcing multicast msgs to loopback on OpenBSD.

2011-07-29 Thread Brad
Fix forcing multicast msgs to loopback on OpenBSD.

e.g.
$ sudo qemu -m 128 -no-fd-bootchk \
-hda virtual.img -boot n -nographic \
-net nic,vlan=0,model=rtl8139,macaddr=52:54:00:12:34:03 \
-net user -tftp /usr/src/sys/arch/i386/compile/TEST -bootp pxeboot \
-net nic,vlan=1,model=rtl8139,macaddr=52:54:00:23:03:01 \
-net tap,vlan=1,script=no \
-net nic,vlan=3,model=rtl8139,macaddr=52:54:00:23:03:03 \
-net socket,vlan=3,mcast=230.0.0.1:10003 
setsockopt(SOL_IP, IP_MULTICAST_LOOP): Invalid argument
qemu: -net socket,vlan=3,mcast=230.0.0.1:10003: Device 'socket' could not be 
initialized


Signed-off-by: Brad Smith 

---
 net/socket.c |   10 --
 1 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/net/socket.c b/net/socket.c
index 11fe5f3..4c27097 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -154,6 +154,12 @@ static int net_socket_mcast_create(struct sockaddr_in 
*mcastaddr, struct in_addr
 struct ip_mreq imr;
 int fd;
 int val, ret;
+#ifdef __OpenBSD__
+u_char loop;
+#else
+int loop;
+#endif
+
 if (!IN_MULTICAST(ntohl(mcastaddr->sin_addr.s_addr))) {
fprintf(stderr, "qemu: error: specified mcastaddr \"%s\" (0x%08x) does 
not contain a multicast address\n",
inet_ntoa(mcastaddr->sin_addr),
@@ -197,9 +203,9 @@ static int net_socket_mcast_create(struct sockaddr_in 
*mcastaddr, struct in_addr
 }
 
 /* Force mcast msgs to loopback (eg. several QEMUs in same host */
-val = 1;
+loop = 1;
 ret=setsockopt(fd, IPPROTO_IP, IP_MULTICAST_LOOP,
-   (const char *)&val, sizeof(val));
+   (const char *)&loop, sizeof(loop));
 if (ret < 0) {
perror("setsockopt(SOL_IP, IP_MULTICAST_LOOP)");
goto fail;
-- 
1.7.6


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.




Re: [Qemu-devel] [PATCH] Fix gcc-4.6 compiler error

2011-07-29 Thread Peter Maydell
On 29 July 2011 20:30, Stefan Weil  wrote:
> Commit 3d3b8303c6f83b9b245bc774af530a6403cc4ce6
> breaks builds with gcc-4.6:
>
> hw/fw_cfg.c: In function ‘probe_splashfile’:
> hw/fw_cfg.c:66:9: error: variable ‘fop_ret’ set but not used 
> [-Werror=unused-but-set-variable]
> hw/fw_cfg.c: In function ‘fw_cfg_bootsplash’:
> hw/fw_cfg.c:130:9: error: variable ‘fop_ret’ set but not used 
> [-Werror=unused-but-set-variable]
>
> Remove fop_ret. Testing the result of fread() is normally
> a good idea, but I don't think it is needed here.

> @@ -86,7 +85,7 @@ static FILE *probe_splashfile(char *filename, int 
> *file_sizep, int *file_typep)
>     }
>     /* check magic ID */
>     fseek(fp, 0L, SEEK_SET);
> -    fop_ret = fread(buf, 1, 2, fp);
> +    (void)fread(buf, 1, 2, fp);

Usually this kind of thing is added in order to stop gcc complaining about
you ignoring the return value of a function which has been marked (by libc)
as 'don't-ignore-return-value'. In such cases a "(void)" is not sufficient
to suppress the "return value ignored" warning.

At least some of these cases really should be checking fread return values;
I see we also don't check fseek() return values either in all places. So
the easiest fix is just to check all the fread() calls.

Alternative suggestion: it would be easier to just slurp the whole file
into memory (which is what we do once we've figured out it's an image)
and then check the magic numbers in the memory buffer, which removes
a lot of these unchecked function calls altogether. Since we're linking
against glib anyway it looks like g_file_get_contents() would do 95%
of the work for us. [disclaimer: I haven't used that API myself but it
looks the right shape...g_malloc vs qemu_malloc issues, maybe?] Failing
that, fopen/fstat/fread/fclose/check magic numbers.

-- PMM



[Qemu-devel] [ANNOUNCE] QEMU 0.15.0-rc1 Release

2011-07-29 Thread Anthony Liguori

Hi,

On behalf of the entire QEMU team, I'm please to announce the release of 
QEMU 0.15.0-rc1.  This is the second release candidate for the 0.15.0 
release.


There are numerous ways you can help participate in the 0.15.0 release. 
 There is a testing coordination wiki page located at:


http://wiki.qemu.org/Planning/0.15/Testing

You can also help improve the ChangeLog documentation at:

http://wiki.qemu.org/ChangeLog/0.15

And of course, you can download the 0.15.0-rc1 release at:

http://wiki.qemu.org/download/qemu-0.15.0-rc1.tar.gz

Below are the changes since the 0.15.0-rc0 release.  I'd like to thank 
everyone who's participated in this release!


 - virtio-balloon: Unregister savevm section on device unplug (Amit Shah)
 - virtio-balloon: Add exit handler, fix memleaks (Amit Shah)
 - balloon: Reject negative balloon values (Amit Shah)
 - virtio-balloon: Check if balloon registration failed (Amit Shah)
 - balloon: Don't allow multiple balloon handler registrations (Amit Shah)
 - target-arm: UNDEF on a VCVTT/VCVTB UNPREDICTABLE to avoid TCG assert 
(Peter M
 - target-arm: Handle UNDEF and UNPREDICTABLE cases for VLDM, VSTM 
(Peter Maydel

 - target-arm: Support v6 barriers in linux-user mode (Peter Maydell)
 - target-arm: Mark 1136r1 as a v6K core (Peter Maydell)
 - virtio-balloon: Fix header comment; add Copyright (Amit Shah)
 - balloon: Fix header comment; add Copyright (Amit Shah)
 - balloon: Separate out stat and balloon handling (Amit Shah)
 - virtio-balloon: Separate status handling into separate function 
(Amit Shah)

 - balloon: Simplify code flow (Amit Shah)
 - balloon: Add braces around if statements (Amit Shah)
 - balloon: Make functions, local vars static (Amit Shah)
 - Let users select their pythons (Blue Swirl)
 - simpletrace: suppress a warning from unused variable (Blue Swirl)
 - Wrap recv to avoid warnings (Blue Swirl)
 - Fix chrdev return value conversion (Blue Swirl)
 - qemu-ga: remove dependency on gio and gthread (Anthony Liguori)
 - guest-agent: only enable FSFREEZE when it's supported by the kernel 
(Anthony Liguori)


Regards,

Anthony Liguori



Re: [Qemu-devel] [PATCH 44/55] spitz tosa: Simplify "drive is suitable for microdrive" test

2011-07-29 Thread andrzej zaborowski
On 20 July 2011 18:24, Markus Armbruster  wrote:
> We try the drive defined with -drive if=ide,index=0 (or equivalent
> sugar).  We use it only if (dinfo && bdrv_is_inserted(dinfo->bdrv) &&
> !bdrv_is_removable(dinfo->bdrv)).  This is a convoluted way to test
> for "drive media can't be removed".
>
> The only way to create such a drive with -drive if=ide is media=cdrom.
> And that sets dinfo->media_cd, so just test that.

This is a less generic test and more prone to be broken inadvertently,
so it seems like a step back.  What's the argument against the
convoluted and explicit test?

Cheers



Re: [Qemu-devel] [PATCH 1/6] VMDK: enable twoGbMaxExtentFlat

2011-07-29 Thread Fam Zheng
Enable the createType 'twoGbMaxExtentFlat'. The supporting code is
already in.

Signed-off-by: Fam Zheng 
---
 block/vmdk.c |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/block/vmdk.c b/block/vmdk.c
index 37478d2..e22a893 100644
--- a/block/vmdk.c
+++ b/block/vmdk.c
@@ -551,7 +551,8 @@ static int vmdk_open_desc_file(BlockDriverState *bs, int 
flags)
 if (vmdk_parse_description(buf, "createType", ct, sizeof(ct))) {
 return -EINVAL;
 }
-if (strcmp(ct, "monolithicFlat")) {
+if (strcmp(ct, "monolithicFlat") &&
+strcmp(ct, "twoGbMaxExtentFlat")) {
 fprintf(stderr,
 "VMDK: Not supported image type \"%s\""".\n", ct);
 return -ENOTSUP;
@@ -672,6 +673,7 @@ static int get_cluster_offset(BlockDriverState *bs,
 return 0;
 }
 
+offset -= (extent->end_sector - extent->sectors) * SECTOR_SIZE;
 l1_index = (offset >> 9) / extent->l1_entry_sectors;
 if (l1_index >= extent->l1_size) {
 return -1;



Re: [Qemu-devel] [PATCH 02/15] hw/omap_gpio.c: Don't complain about some writes to r/o registers

2011-07-29 Thread andrzej zaborowski
Hi,

I went ahead and pushed the series with the exception of this patch
and 14/15 because I think these are the types of patches that should
remain in downstream as a reminder, is there an argument for not
fixing these things in Linux?

In patch 04 I renamed omap2_gpio_module_set to omap2_gpio_set because
the parameter is no longer the module pointer.  By the way I think we
should also pass the target agent pointer on creation the same way
clocks are passed and use omap_l4_attach.

In patch 07 I bumped the vmstate version because the structure seems
to have changed.

In patch 12 I removed the
else {
s->bdrv_cur = s->bdrv;
} part because there seemed to be no reason to add it, please check
that I haven't broken something.

Cheers

On 29 July 2011 17:35, Peter Maydell  wrote:
> Don't complain about some writes to r/o OMAP2 GPIO registers, because the
> kernel will do them anyway.
>
> Signed-off-by: Peter Maydell 
> ---
>  hw/omap_gpio.c |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/hw/omap_gpio.c b/hw/omap_gpio.c
> index 478f7d9..b53b13b 100644
> --- a/hw/omap_gpio.c
> +++ b/hw/omap_gpio.c
> @@ -385,7 +385,7 @@ static void omap2_gpio_module_write(void *opaque, 
> target_phys_addr_t addr,
>     case 0x00: /* GPIO_REVISION */
>     case 0x14: /* GPIO_SYSSTATUS */
>     case 0x38: /* GPIO_DATAIN */
> -        OMAP_RO_REG(addr);
> +        /* read-only, ignore quietly */
>         break;
>
>     case 0x10: /* GPIO_SYSCONFIG */
> @@ -531,7 +531,7 @@ static void omap2_gpio_module_writep(void *opaque, 
> target_phys_addr_t addr,
>     case 0x00: /* GPIO_REVISION */
>     case 0x14: /* GPIO_SYSSTATUS */
>     case 0x38: /* GPIO_DATAIN */
> -        OMAP_RO_REG(addr);
> +        /* read-only, ignore quietly */
>         break;
>
>     case 0x10: /* GPIO_SYSCONFIG */
> --
> 1.7.1
>
>



Re: [Qemu-devel] [PATCH v5] Add support for Zipit Z2 machine

2011-07-29 Thread andrzej zaborowski
On 6 July 2011 15:52, Vasily Khoruzhick  wrote:
> Zipit Z2 is small PXA270 based handheld.

Thanks, I pushed this version.

Cheers



Re: [Qemu-devel] [PATCH 15/15] hw/onenand: program actions can only clear bits

2011-07-29 Thread andrzej zaborowski
On 29 July 2011 17:35, Peter Maydell  wrote:
> From: Juha Riihimäki 
>
> The program actions onenand_prog_main() and onenand_prog_spare()
> can only set bits.
>
> This implies a rewrite of onenand_erase() to not use the program
> functions, since erase does need to set bits.
>
> Signed-off-by: Juha Riihimäki 
> [Riku Voipio: Fixes and restructuring patchset]
> Signed-off-by: Riku Voipio 
> [Peter Maydell: More fixes and cleanups for upstream submission]
> Signed-off-by:  Peter Maydell 
> ---
>  hw/onenand.c |  135 +
>  1 files changed, 106 insertions(+), 29 deletions(-)
>
> diff --git a/hw/onenand.c b/hw/onenand.c
...
>  static inline int onenand_erase(OneNANDState *s, int sec, int num)
>  {
> -    /* TODO: optimise */
> -    uint8_t buf[512];
> -
> -    memset(buf, 0xff, sizeof(buf));
> -    for (; num > 0; num --, sec ++) {
> -        if (onenand_prog_main(s, sec, 1, buf))
> -            return 1;
> -        if (onenand_prog_spare(s, sec, 1, buf))
> -            return 1;
> +    uint8_t *blankbuf, *tmpbuf;
> +    blankbuf = qemu_malloc(512);
> +    if (!blankbuf) {
> +        return 1;
> +    }
> +    tmpbuf = qemu_malloc(512);
> +    if (!tmpbuf) {
> +        qemu_free(blankbuf);
> +        return 1;
> +    }
> +    memset(blankbuf, 0xff, 512);
> +    for (; num > 0; num--, sec++) {
> +        if (s->bdrv_cur) {
> +            int erasesec = s->secs_cur + (sec >> 5);
> +            if (bdrv_write(s->bdrv_cur, sec, blankbuf, 1)) {
> +                goto fail;
> +            }
> +            if (bdrv_read(s->bdrv_cur, erasesec, tmpbuf, 1) < 0) {
> +                goto fail;
> +            }
> +            memcpy(tmpbuf + ((sec & 31) << 4), blankbuf, 1 << 4);
> +            if (bdrv_write(s->bdrv_cur, erasesec, tmpbuf, 1) < 0) {
> +                goto fail;
> +            }

By the way it seems that this can be optimised to require just one
read for the entire erase.

Cheers



[Qemu-devel] [PATCH] Add support for finding libpng via pkg-config

2011-07-29 Thread Brad
Add support for finding libpng via pkg-config.

Signed-off-by: Brad Smith 

---
 configure |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/configure b/configure
index 4012d15..25aa75f 100755
--- a/configure
+++ b/configure
@@ -1519,11 +1519,17 @@ int main(void) {
 return 0;
 }
 EOF
+  if $pkg_config libpng --modversion >/dev/null 2>&1; then
+vnc_png_cflags=`$pkg_config libpng --cflags 2> /dev/null`
+vnc_png_libs=`$pkg_config libpng --libs 2> /dev/null`
+  else
 vnc_png_cflags=""
 vnc_png_libs="-lpng"
+  fi
   if compile_prog "$vnc_png_cflags" "$vnc_png_libs" ; then
 vnc_png=yes
 libs_softmmu="$vnc_png_libs $libs_softmmu"
+QEMU_CFLAGS="$QEMU_CFLAGS $vnc_png_cflags"
   else
 if test "$vnc_png" = "yes" ; then
   feature_not_found "vnc-png"
-- 
1.7.6


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.




  1   2   >