Re: [Qemu-devel] [RFC] qed: Add QEMU Enhanced Disk format

[Avi Kivity]

 On 09/08/2010 06:07 PM, Stefan Hajnoczi wrote:

 uint32_t table_size;  /* table size, in clusters */

Presumably L1 table size?  Or any table size?

Hm.  It would be nicer not to require contiguous sectors anywhere.  How
about a variable- or fixed-height tree?

Both extents and fancier trees don't fit the philosophy, which is to
keep things straightforward and fast by doing less.  With extents and
trees you've got something that looks much more like a full-blown
filesystem.  Is there an essential feature or characteristic that QED
cannot provide in its current design?



Not using extents mean that random workloads on very large disks will 
continuously need to page in L2s (which are quite large, 256KB is large 
enough that you need to account for read time, not just seek time).  
Keeping it to two levels means that the image size is limited, not very 
good for an image format designed in 2010.



Is the physical image size always derived from the host file metadata?  Is
this always safe?

In my email summarizing crash scenarios and recovery we cover the
bases and I think it is safe to rely on file size as physical image
size.  The drawback is that you need a host filesystem and cannot
directly use a bare block device.  I think that is acceptable for a
sparse format, otherwise we'd be using raw.


Hm, we do have a use case for qcow2-over-lvm.  I can't say it's 
something I like, but a point to consider.


--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

Re: [Qemu-devel] [PATCH v3 00/14] trace: Add static tracing to QEMU

[Stefan Hajnoczi]

Any additional questions about this patch series?

Prerna and I are keen on growing trace event coverage and putting
static tracing to use outside our own development environments.  It
has been a powerful tool for block layer performance work and
developing QED, and I think it will be useful to others in QEMU.

Thanks,
Stefan

[Qemu-devel] Commit 8b33d9ee (was not on list)

[Kevin Wolf]

> commit 8b33d9eeba91422ee2d73b6936ad57262d18cf5a
> Author: Anthony Liguori 
> Date:   Wed Sep 8 17:09:15 2010 -0500
> 
> Revert "Make default invocation of block drivers safer (v3)"
> 
> This reverts commit 79368c81bf8cf93864d7afc88b81b05d8f0a2c90.
> 
> Conflicts:
> 
> block.c
> 
> I haven't been able to come up with a solution yet for the corruption 
> caused by
> unaligned requests from the IDE disk so revert until a solution can be 
> written.
> 
> Signed-off-by: Anthony Liguori 

I posted a fix for it on Tuesday.

Kevin

Re: [Qemu-devel] [PATCH] raw: Fix image header protection

[Anthony Liguori]

On 09/07/2010 07:08 AM, Kevin Wolf wrote:

Recenty a patch was committed to protect the first four bytes of an image to
avoid "converting" a probed raw image to a different format when a malicious
guest writes e.g. a qcow2 header to it.

This check relies on the assumption that all qiov entries are multiples of 512,
which isn't true in practice. At least the installers of some Windows versions
are reported to fail the corresponding assertion.

This patch removes the wrong assumption and fixes Win 2003 installation for me
(other Windows versions not tested, should be the same)

Signed-off-by: Kevin Wolf
---
  block/raw.c   |   57 -
  cutils.c  |   16 
  qemu-common.h |1 +
  3 files changed, 37 insertions(+), 37 deletions(-)

diff --git a/block/raw.c b/block/raw.c
index 61e6748..3286550 100644
--- a/block/raw.c
+++ b/block/raw.c
@@ -99,6 +99,7 @@ typedef struct RawScrubberBounce
  {
  BlockDriverCompletionFunc *cb;
  void *opaque;
+uint8_t *buf;
  QEMUIOVector qiov;
  } RawScrubberBounce;

@@ -113,6 +114,7 @@ static void raw_aio_writev_scrubbed(void *opaque, int ret)
  }

  qemu_iovec_destroy(&b->qiov);
+qemu_free(b->buf);
  qemu_free(b);
  }

@@ -120,46 +122,35 @@ static BlockDriverAIOCB *raw_aio_writev(BlockDriverState 
*bs,
  int64_t sector_num, QEMUIOVector *qiov, int nb_sectors,
  BlockDriverCompletionFunc *cb, void *opaque)
  {
-const uint8_t *first_buf;
-int first_buf_index = 0, i;
-
-/* This is probably being paranoid, but handle cases of zero size
-   vectors. */
-for (i = 0; i<  qiov->niov; i++) {
-if (qiov->iov[i].iov_len) {
-assert(qiov->iov[i].iov_len>= 512);
-first_buf_index = i;
-break;
-}
-}
+if (bs->probed) {
+uint8_t first_buf[512];
+qemu_iovec_part_to_buffer(qiov, first_buf, 512);

-first_buf = qiov->iov[first_buf_index].iov_base;
+if (check_write_unsafe(bs, sector_num, first_buf, nb_sectors)) {
+RawScrubberBounce *b;
+int ret;

-if (check_write_unsafe(bs, sector_num, first_buf, nb_sectors)) {
-RawScrubberBounce *b;
-int ret;
+/* write the first sector using sync I/O */
+ret = raw_write_scrubbed_bootsect(bs, first_buf);
+if (ret<  0) {
+return NULL;
+}

-/* write the first sector using sync I/O */
-ret = raw_write_scrubbed_bootsect(bs, first_buf);
-if (ret<  0) {
-return NULL;
-}
-
-/* adjust request to be everything but first sector */
+/* adjust request to be everything but first sector */

-b = qemu_malloc(sizeof(*b));
-b->cb = cb;
-b->opaque = opaque;
+b = qemu_malloc(sizeof(*b));
+b->cb = cb;
+b->opaque = opaque;

-qemu_iovec_init(&b->qiov, qiov->nalloc);
-qemu_iovec_concat(&b->qiov, qiov, qiov->size);
+b->buf = qemu_malloc(qiov->size);
+qemu_iovec_to_buffer(qiov, b->buf);
   


Isn't this an unbounded, guest controlled, malloc?  IOW, a guest could 
do a request of 4GB and on a 32-bit system crash the qemu instance.


Regards,

Anthony Liguori


-b->qiov.size -= 512;
-b->qiov.iov[first_buf_index].iov_base += 512;
-b->qiov.iov[first_buf_index].iov_len -= 512;
+qemu_iovec_init(&b->qiov, 1);
+qemu_iovec_add(&b->qiov, b->buf + 512, qiov->size - 512);

-return bdrv_aio_writev(bs->file, sector_num + 1,&b->qiov,
-   nb_sectors - 1, raw_aio_writev_scrubbed, b);
+return bdrv_aio_writev(bs->file, sector_num + 1,&b->qiov,
+   nb_sectors - 1, raw_aio_writev_scrubbed, b);
+}
  }

  return bdrv_aio_writev(bs->file, sector_num, qiov, nb_sectors, cb, 
opaque);
diff --git a/cutils.c b/cutils.c
index 036ae3c..0fb4968 100644
--- a/cutils.c
+++ b/cutils.c
@@ -207,17 +207,25 @@ void qemu_iovec_reset(QEMUIOVector *qiov)
  qiov->size = 0;
  }

-void qemu_iovec_to_buffer(QEMUIOVector *qiov, void *buf)
+void qemu_iovec_part_to_buffer(QEMUIOVector *qiov, void *buf, size_t len)
  {
  uint8_t *p = (uint8_t *)buf;
  int i;
+size_t n;

-for (i = 0; i<  qiov->niov; ++i) {
-memcpy(p, qiov->iov[i].iov_base, qiov->iov[i].iov_len);
-p += qiov->iov[i].iov_len;
+for (i = 0; len&&  i<  qiov->niov; ++i) {
+n = MIN(len, qiov->iov[i].iov_len);
+memcpy(p, qiov->iov[i].iov_base, n);
+p += n;
+len -= n;
  }
  }

+void qemu_iovec_to_buffer(QEMUIOVector *qiov, void *buf)
+{
+qemu_iovec_part_to_buffer(qiov, buf, qiov->size);
+}
+
  void qemu_iovec_from_buffer(QEMUIOVector *qiov, const void *buf, size_t count)
  {
  const uint8_t *p = (const uint8_t *)buf;
diff --git a/qemu-common.h b/qemu-common.h
index dfd3dc0..c58

Re: [Qemu-devel] Commit 8b33d9ee (was not on list)

[Anthony Liguori]

On 09/09/2010 06:35 AM, Kevin Wolf wrote:

commit 8b33d9eeba91422ee2d73b6936ad57262d18cf5a
Author: Anthony Liguori
Date:   Wed Sep 8 17:09:15 2010 -0500

 Revert "Make default invocation of block drivers safer (v3)"

 This reverts commit 79368c81bf8cf93864d7afc88b81b05d8f0a2c90.

 Conflicts:

 block.c

 I haven't been able to come up with a solution yet for the corruption 
caused by
 unaligned requests from the IDE disk so revert until a solution can be 
written.

 Signed-off-by: Anthony Liguori
 

I posted a fix for it on Tuesday.
   


It was a revert but yeah, I guess I should have posted first.

I don't think your fix is good enough.  I had the same thought but it's 
an unbounded memory allocation.


Regards,

Anthony Liguori


Kevin

   

Re: [Qemu-devel] [PATCH] raw: Fix image header protection

[Kevin Wolf]

Am 09.09.2010 14:30, schrieb Anthony Liguori:
> On 09/07/2010 07:08 AM, Kevin Wolf wrote:
>> Recenty a patch was committed to protect the first four bytes of an image to
>> avoid "converting" a probed raw image to a different format when a malicious
>> guest writes e.g. a qcow2 header to it.
>>
>> This check relies on the assumption that all qiov entries are multiples of 
>> 512,
>> which isn't true in practice. At least the installers of some Windows 
>> versions
>> are reported to fail the corresponding assertion.
>>
>> This patch removes the wrong assumption and fixes Win 2003 installation for 
>> me
>> (other Windows versions not tested, should be the same)
>>
>> Signed-off-by: Kevin Wolf
>> ---
>>   block/raw.c   |   57 
>> -
>>   cutils.c  |   16 
>>   qemu-common.h |1 +
>>   3 files changed, 37 insertions(+), 37 deletions(-)
>>
>> diff --git a/block/raw.c b/block/raw.c
>> index 61e6748..3286550 100644
>> --- a/block/raw.c
>> +++ b/block/raw.c
>> @@ -99,6 +99,7 @@ typedef struct RawScrubberBounce
>>   {
>>   BlockDriverCompletionFunc *cb;
>>   void *opaque;
>> +uint8_t *buf;
>>   QEMUIOVector qiov;
>>   } RawScrubberBounce;
>>
>> @@ -113,6 +114,7 @@ static void raw_aio_writev_scrubbed(void *opaque, int 
>> ret)
>>   }
>>
>>   qemu_iovec_destroy(&b->qiov);
>> +qemu_free(b->buf);
>>   qemu_free(b);
>>   }
>>
>> @@ -120,46 +122,35 @@ static BlockDriverAIOCB 
>> *raw_aio_writev(BlockDriverState *bs,
>>   int64_t sector_num, QEMUIOVector *qiov, int nb_sectors,
>>   BlockDriverCompletionFunc *cb, void *opaque)
>>   {
>> -const uint8_t *first_buf;
>> -int first_buf_index = 0, i;
>> -
>> -/* This is probably being paranoid, but handle cases of zero size
>> -   vectors. */
>> -for (i = 0; i<  qiov->niov; i++) {
>> -if (qiov->iov[i].iov_len) {
>> -assert(qiov->iov[i].iov_len>= 512);
>> -first_buf_index = i;
>> -break;
>> -}
>> -}
>> +if (bs->probed) {
>> +uint8_t first_buf[512];
>> +qemu_iovec_part_to_buffer(qiov, first_buf, 512);
>>
>> -first_buf = qiov->iov[first_buf_index].iov_base;
>> +if (check_write_unsafe(bs, sector_num, first_buf, nb_sectors)) {
>> +RawScrubberBounce *b;
>> +int ret;
>>
>> -if (check_write_unsafe(bs, sector_num, first_buf, nb_sectors)) {
>> -RawScrubberBounce *b;
>> -int ret;
>> +/* write the first sector using sync I/O */
>> +ret = raw_write_scrubbed_bootsect(bs, first_buf);
>> +if (ret<  0) {
>> +return NULL;
>> +}
>>
>> -/* write the first sector using sync I/O */
>> -ret = raw_write_scrubbed_bootsect(bs, first_buf);
>> -if (ret<  0) {
>> -return NULL;
>> -}
>> -
>> -/* adjust request to be everything but first sector */
>> +/* adjust request to be everything but first sector */
>>
>> -b = qemu_malloc(sizeof(*b));
>> -b->cb = cb;
>> -b->opaque = opaque;
>> +b = qemu_malloc(sizeof(*b));
>> +b->cb = cb;
>> +b->opaque = opaque;
>>
>> -qemu_iovec_init(&b->qiov, qiov->nalloc);
>> -qemu_iovec_concat(&b->qiov, qiov, qiov->size);
>> +b->buf = qemu_malloc(qiov->size);
>> +qemu_iovec_to_buffer(qiov, b->buf);
>>
> 
> Isn't this an unbounded, guest controlled, malloc?  IOW, a guest could 
> do a request of 4GB and on a 32-bit system crash the qemu instance.

If you're concerned about that, we need to ban qemu_iovec_to_buffer()
completely. Currently we do the same thing for every write request for
every format but raw. Or instead of completely removing it, we could add
a size limit, though I suspect that would mean violating some specs.

If I was a guest though and wanted to crash qemu, I would just mess up
the virtio ring a bit so that qemu would exit() voluntarily. ;-)

Kevin

Re: [Qemu-devel] [RFC] qed: Add QEMU Enhanced Disk format

[Anthony Liguori]

On 09/09/2010 01:45 AM, Avi Kivity wrote:
Loading very large L2 tables on demand will result in very long 
latencies.  Increasing cluster size will result in very long first 
write latencies.  Adding an extra level results in an extra random 
write every 4TB.


It would be trivially easy to add another level of tables as a feature 
bit so let's delay the decision.




qed is very careful about ensuring that we don't need to do syncs and 
we don't get corruption because of data loss.  I don't necessarily 
buy your checksumming argument.


The requirement for checksumming comes from a different place.  For 
decades we've enjoyed very low undetected bit error rates.  However 
the actual amount of data is increasing to the point that it makes an 
undetectable bit error likely, just by throwing a huge amount of bits 
at storage.  Write ordering doesn't address this issue.


I don't think we should optimize an image format for cheap disks and an 
old file system.


We should optimize for the future.  That means a btrfs file system 
and/or enterprise storage.


The point of an image format is not to recreate btrfs in software.  It's 
to provide a mechanism to allow users to move images around reasonable 
but once an image is present on a reasonable filesystem, we should more 
or less get the heck out of the way.




By creating two code paths within qcow2. 


You're creating two code paths for users.


No, I'm creating a single path: QED.

There are already two code paths: raw and qcow2.  qcow2 has had such a 
bad history that for a lot of users, it's not even a choice.


Today, users have to choose between performance and reliability or 
features.  QED offers an opportunity to be able to tell users to just 
always use QED as an image format and forget about raw/qcow2/everything 
else.


You can say, let's just make qcow2 better, but we've been trying that 
for years and we have an existence proof that we can do it in a straight 
forward fashion with QED.A new format doesn't introduce much additional 
complexity.  We provide image conversion tool and we can almost 
certainly provide an in-place conversion tool that makes the process 
very fast.




It requires users to make a decision.  By the time qed is ready for 
mass deployment, 1-2 years will have passed.  How many qcow2 images 
will be in the wild then?  How much scheduled downtime will be needed?


Zero if we're smart.  You can do QED stream + live migration to do a 
live conversion from raw to QED.



  How much user confusion will be caused?


User confusion is reduced if we can make strong, clear statements: all 
users should use QED even if they care about performance.  Today, 
there's mass confusion because of the poor state of qcow2.


Virtualization is about compatibility.  In-guest compatibility first, 
but keeping the external environment stable is also important.  We 
really need to exhaust the possibilities with qcow2 before giving up 
on it.


IMHO, we're long past exhausting the possibilities with qcow2.  We still 
haven't decided what we're going to do for 0.13.0.  Are we going to ship 
qcow2 with awful performance (a 15 minute operation taking hours) or 
with compromised data integrity?


It's been this way for every release since qcow2 existed.  Let's not let 
sunk cost cloud our judgement here.


qcow2 is not a properly designed image format.  It was a weekend hacking 
session from Fabrice that he dropped in the code base and never really 
finished doing what he originally intended.  The improvements that have 
been made to it are almost at the heroic level but we're only hurting 
our users by not moving on to something better.


Regards,

Anthony Liguori

Re: [Qemu-devel] [PATCH] raw: Fix image header protection

[Anthony Liguori]

On 09/09/2010 07:44 AM, Kevin Wolf wrote:

Isn't this an unbounded, guest controlled, malloc?  IOW, a guest could
do a request of 4GB and on a 32-bit system crash the qemu instance.
 

If you're concerned about that, we need to ban qemu_iovec_to_buffer()
completely. Currently we do the same thing for every write request for
every format but raw.


And QED ;-)


  Or instead of completely removing it, we could add
a size limit, though I suspect that would mean violating some specs.
   


One thing I was thinking of trying was splitting off the first sector 
into a linear buffer, then allocating a new iovec and adjusting the new 
iovec to cover the new request minus the first sector.



If I was a guest though and wanted to crash qemu, I would just mess up
the virtio ring a bit so that qemu would exit() voluntarily. ;-)
   


Yeah, we're terrible at this but we should try to avoid making things 
worse.  Particularly in a code path (like raw images) where we don't 
have this problem today.


Regards,

Anthony Liguori


Kevin
   

Re: [Qemu-devel] [PATCH] raw: Fix image header protection

[Kevin Wolf]

Am 09.09.2010 14:52, schrieb Anthony Liguori:
> On 09/09/2010 07:44 AM, Kevin Wolf wrote:
>>> Isn't this an unbounded, guest controlled, malloc?  IOW, a guest could
>>> do a request of 4GB and on a 32-bit system crash the qemu instance.
>>>  
>> If you're concerned about that, we need to ban qemu_iovec_to_buffer()
>> completely. Currently we do the same thing for every write request for
>> every format but raw.
> 
> And QED ;-)

qed doesn't exist. We have something some notices from a brainstorming
thread that should become a specification some day. And yes, there's
some prototype code. That's everything we have today.

Anyway, if you declare qemu_iovec_to_buffer() broken, it doesn't really
matter if n-1 formats or n-2 formats are broken...

>>   Or instead of completely removing it, we could add
>> a size limit, though I suspect that would mean violating some specs.
>>
> 
> One thing I was thinking of trying was splitting off the first sector 
> into a linear buffer, then allocating a new iovec and adjusting the new 
> iovec to cover the new request minus the first sector.

That doesn't help any of the other use cases. Either we consider it a
problem or not. If we do, it must be fixed everywhere.

Kevin

Re: [Qemu-devel] [PATCH] raw: Fix image header protection

[Anthony Liguori]

On 09/09/2010 08:02 AM, Kevin Wolf wrote:

   Or instead of completely removing it, we could add
a size limit, though I suspect that would mean violating some specs.

   

One thing I was thinking of trying was splitting off the first sector
into a linear buffer, then allocating a new iovec and adjusting the new
iovec to cover the new request minus the first sector.
 

That doesn't help any of the other use cases. Either we consider it a
problem or not. If we do, it must be fixed everywhere.
   


Yes, it's a problem.  In other places in the code base, we go to 
incredible lengths to avoid unbounded allocations.


I think we have to two choices: 1) refactor all of the code to not 
require qemu_iovec_to_buffer() or 2) cap the request size and fail a 
request if it's greater.


Regards,

Anthony Liguori


Kevin
   

Re: [Qemu-devel] [PATCH 2/8] [MIPS] qdev: convert ds1225y nvram to sysbus device

[Blue Swirl]

2010/9/8 Hervé Poussineau :
> Use it in Jazz emulation
> Remove protection stuff, which doesn't belong to this device
> Remove ds1225y_init() and ds1225y_set_protection() functions, which are not 
> used anymore
>
> Signed-off-by: Hervé Poussineau 
> ---
>  hw/ds1225y.c   |  151 
> ++--
>  hw/mips.h      |    4 --
>  hw/mips_jazz.c |    4 +-
>  3 files changed, 83 insertions(+), 76 deletions(-)
>
> diff --git a/hw/ds1225y.c b/hw/ds1225y.c
> index 009d127..046d1ec 100644
> --- a/hw/ds1225y.c
> +++ b/hw/ds1225y.c
> @@ -22,31 +22,34 @@
>  * THE SOFTWARE.
>  */
>
> -#include "hw.h"
> -#include "mips.h"
> -#include "nvram.h"
> +#include "sysbus.h"
>
>  //#define DEBUG_NVRAM
>
> -typedef struct ds1225y_t
> -{
> -    uint32_t chip_size;
> +#ifdef DEBUG_NVRAM
> +#define DPRINTF(fmt, ...)                                       \
> +    do { printf("nvram: " fmt , ## __VA_ARGS__); } while (0)
> +#else
> +#define DPRINTF(fmt, ...) do {} while (0)
> +#endif
> +
> +typedef struct {
> +    DeviceState qdev;
> +    int32_t chip_size;
> +    char* filename;
>     QEMUFile *file;
>     uint8_t *contents;
> -    uint8_t protection;
> -} ds1225y_t;
> -
> +} NvRamState;
>
>  static uint32_t nvram_readb (void *opaque, target_phys_addr_t addr)
>  {
> -    ds1225y_t *s = opaque;
> +    NvRamState *s = opaque;
>     uint32_t val;
>
>     val = s->contents[addr];
>
> -#ifdef DEBUG_NVRAM
> -    printf("nvram: read 0x%x at " TARGET_FMT_lx "\n", val, addr);
> -#endif
> +    DPRINTF("read 0x%x at " TARGET_FMT_plx "\n", val, addr);
> +
>     return val;
>  }
>
> @@ -70,11 +73,9 @@ static uint32_t nvram_readl (void *opaque, 
> target_phys_addr_t addr)
>
>  static void nvram_writeb (void *opaque, target_phys_addr_t addr, uint32_t 
> val)
>  {
> -    ds1225y_t *s = opaque;
> +    NvRamState *s = opaque;
>
> -#ifdef DEBUG_NVRAM
> -    printf("nvram: write 0x%x at " TARGET_FMT_lx "\n", val, addr);
> -#endif
> +    DPRINTF("write 0x%x at " TARGET_FMT_plx "\n", val, addr);
>
>     s->contents[addr] = val & 0xff;
>     if (s->file) {
> @@ -98,34 +99,6 @@ static void nvram_writel (void *opaque, target_phys_addr_t 
> addr, uint32_t val)
>     nvram_writeb(opaque, addr + 3, (val >> 24) & 0xff);
>  }
>
> -static void nvram_writeb_protected (void *opaque, target_phys_addr_t addr, 
> uint32_t val)
> -{
> -    ds1225y_t *s = opaque;
> -
> -    if (s->protection != 7) {
> -#ifdef DEBUG_NVRAM
> -    printf("nvram: prevent write of 0x%x at " TARGET_FMT_lx "\n", val, addr);
> -#endif
> -        return;
> -    }
> -
> -    nvram_writeb(opaque, addr, val);
> -}
> -
> -static void nvram_writew_protected (void *opaque, target_phys_addr_t addr, 
> uint32_t val)
> -{
> -    nvram_writeb_protected(opaque, addr, val & 0xff);
> -    nvram_writeb_protected(opaque, addr + 1, (val >> 8) & 0xff);
> -}
> -
> -static void nvram_writel_protected (void *opaque, target_phys_addr_t addr, 
> uint32_t val)
> -{
> -    nvram_writeb_protected(opaque, addr, val & 0xff);
> -    nvram_writeb_protected(opaque, addr + 1, (val >> 8) & 0xff);
> -    nvram_writeb_protected(opaque, addr + 2, (val >> 16) & 0xff);
> -    nvram_writeb_protected(opaque, addr + 3, (val >> 24) & 0xff);
> -}
> -
>  static CPUReadMemoryFunc * const nvram_read[] = {
>     &nvram_readb,
>     &nvram_readw,
> @@ -138,43 +111,81 @@ static CPUWriteMemoryFunc * const nvram_write[] = {
>     &nvram_writel,
>  };
>
> -static CPUWriteMemoryFunc * const nvram_write_protected[] = {
> -    &nvram_writeb_protected,
> -    &nvram_writew_protected,
> -    &nvram_writel_protected,
> +static int nvram_post_load(void *opaque, int version_id)
> +{
> +    NvRamState *s = opaque;
> +
> +    if (s->file) {
> +        qemu_fclose(s->file);
> +    }
> +
> +    /* Write back nvram contents */
> +    s->file = qemu_fopen(s->filename, "wb");

How about ftruncate(fileno(s->file), 0)?

> +    if (s->file) {
> +        /* Write back contents, as 'wb' mode cleaned the file */
> +        qemu_put_buffer(s->file, s->contents, s->chip_size);
> +        qemu_fflush(s->file);
> +    }
> +
> +    return 0;
> +}
> +
> +static const VMStateDescription vmstate_nvram = {
> +    .name = "nvram",
> +    .version_id = 0,
> +    .minimum_version_id = 0,
> +    .minimum_version_id_old = 0,
> +    .post_load = nvram_post_load,
> +    .fields = (VMStateField []) {
> +        VMSTATE_VARRAY_INT32(contents, NvRamState, chip_size, 0, 
> vmstate_info_uint8,
> +                             uint8_t),
> +        VMSTATE_END_OF_LIST()
> +    }
>  };
>
> -/* Initialisation routine */
> -void *ds1225y_init(target_phys_addr_t mem_base, const char *filename)
> +typedef struct {
> +    SysBusDevice busdev;
> +    NvRamState nvram;
> +} SysBusNvRamState;
> +
> +static int nvram_sysbus_initfn(SysBusDevice *dev)
>  {
> -    ds1225y_t *s;
> -    int mem_indexRW, mem_indexRP;
> +    NvRamState *s = &FROM_SYSBUS(SysBusNvRamState, dev)->nvram;
>     QEMUFile *file;
> +    int s_io;
>
> -    s = qemu_mallocz(sizeof(ds1225y_t));

Re: [Qemu-devel] [PATCH 5/8] [MIPS] qdev: convert ISA VGA MM to sysbus device

[Blue Swirl]

2010/9/8 Hervé Poussineau :
> Use it in Jazz emulation
> Remove isa_vga_mm_init() function, which is not used anymore
>
> Signed-off-by: Hervé Poussineau 
> ---
>  hw/mips_jazz.c  |    2 +-
>  hw/pc.h         |    2 -
>  hw/vga-isa-mm.c |   94 
> ---
>  3 files changed, 56 insertions(+), 42 deletions(-)
>
> diff --git a/hw/mips_jazz.c b/hw/mips_jazz.c
> index 5c66cd4..98567d2 100644
> --- a/hw/mips_jazz.c
> +++ b/hw/mips_jazz.c
> @@ -218,7 +218,7 @@ void mips_jazz_init (ram_addr_t ram_size,
>         g364fb_mm_init(0x4000, 0x6000, 0, rc4030[3]);
>         break;
>     case JAZZ_PICA61:
> -        isa_vga_mm_init(0x4000, 0x6000, 0);
> +        sysbus_create_simple("sysbus-vga", 0x6000, NULL);
>         break;
>     default:
>         break;
> diff --git a/hw/pc.h b/hw/pc.h
> index e078fd9..946ae78 100644
> --- a/hw/pc.h
> +++ b/hw/pc.h
> @@ -153,8 +153,6 @@ extern enum vga_retrace_method vga_retrace_method;
>  int isa_vga_init(void);
>  int pci_vga_init(PCIBus *bus,
>                  unsigned long vga_bios_offset, int vga_bios_size);
> -int isa_vga_mm_init(target_phys_addr_t vram_base,
> -                    target_phys_addr_t ctrl_base, int it_shift);
>
>  /* cirrus_vga.c */
>  void pci_cirrus_vga_init(PCIBus *bus);
> diff --git a/hw/vga-isa-mm.c b/hw/vga-isa-mm.c
> index 680b557..ecd6a41 100644
> --- a/hw/vga-isa-mm.c
> +++ b/hw/vga-isa-mm.c
> @@ -21,62 +21,58 @@
>  * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
>  * THE SOFTWARE.
>  */
> -#include "hw.h"
> +
>  #include "console.h"
> -#include "pc.h"
>  #include "vga_int.h"
>  #include "pixel_ops.h"
> -#include "qemu-timer.h"
> +#include "sysbus.h"
>
> -typedef struct ISAVGAMMState {
> -    VGACommonState vga;
> -    int it_shift;
> -} ISAVGAMMState;
> +#define VRAM_BASE 0x4000
>
>  /* Memory mapped interface */
>  static uint32_t vga_mm_readb (void *opaque, target_phys_addr_t addr)
>  {
> -    ISAVGAMMState *s = opaque;
> +    VGACommonState *s = opaque;
>
> -    return vga_ioport_read(&s->vga, addr >> s->it_shift) & 0xff;
> +    return vga_ioport_read(s, addr) & 0xff;
>  }
>
>  static void vga_mm_writeb (void *opaque,
>                            target_phys_addr_t addr, uint32_t value)
>  {
> -    ISAVGAMMState *s = opaque;
> +    VGACommonState *s = opaque;
>
> -    vga_ioport_write(&s->vga, addr >> s->it_shift, value & 0xff);
> +    vga_ioport_write(s, addr, value & 0xff);
>  }
>
>  static uint32_t vga_mm_readw (void *opaque, target_phys_addr_t addr)
>  {
> -    ISAVGAMMState *s = opaque;
> +    VGACommonState *s = opaque;
>
> -    return vga_ioport_read(&s->vga, addr >> s->it_shift) & 0x;
> +    return vga_ioport_read(s, addr) & 0x;
>  }
>
>  static void vga_mm_writew (void *opaque,
>                            target_phys_addr_t addr, uint32_t value)
>  {
> -    ISAVGAMMState *s = opaque;
> +    VGACommonState *s = opaque;
>
> -    vga_ioport_write(&s->vga, addr >> s->it_shift, value & 0x);
> +    vga_ioport_write(s, addr, value & 0x);
>  }
>
>  static uint32_t vga_mm_readl (void *opaque, target_phys_addr_t addr)
>  {
> -    ISAVGAMMState *s = opaque;
> +    VGACommonState *s = opaque;
>
> -    return vga_ioport_read(&s->vga, addr >> s->it_shift);
> +    return vga_ioport_read(s, addr);
>  }
>
>  static void vga_mm_writel (void *opaque,
>                            target_phys_addr_t addr, uint32_t value)
>  {
> -    ISAVGAMMState *s = opaque;
> +    VGACommonState *s = opaque;
>
> -    vga_ioport_write(&s->vga, addr >> s->it_shift, value);
> +    vga_ioport_write(s, addr, value);
>  }
>
>  static CPUReadMemoryFunc * const vga_mm_read_ctrl[] = {
> @@ -91,36 +87,56 @@ static CPUWriteMemoryFunc * const vga_mm_write_ctrl[] = {
>     &vga_mm_writel,
>  };
>
> -static void vga_mm_init(ISAVGAMMState *s, target_phys_addr_t vram_base,
> -                        target_phys_addr_t ctrl_base, int it_shift)
> +typedef struct {
> +    SysBusDevice busdev;
> +    VGACommonState vga;
> +} SysBusVGAState;
> +
> +static const VMStateDescription vmstate_vga = {
> +    .name = "sysbus-vga",
> +    .version_id = 0,
> +    .minimum_version_id = 0,
> +    .minimum_version_id_old = 0,
> +    .fields = (VMStateField []) {
> +        VMSTATE_STRUCT(vga, SysBusVGAState, 0, vmstate_vga_common, 
> VGACommonState),
> +        VMSTATE_END_OF_LIST()
> +    }
> +};
> +
> +static int vga_sysbus_initfn(SysBusDevice *dev)
>  {
> +    VGACommonState *s = &FROM_SYSBUS(SysBusVGAState, dev)->vga;
>     int s_ioport_ctrl, vga_io_memory;
>
> -    s->it_shift = it_shift;
> +    vga_common_init(s, VGA_RAM_SIZE);
> +    s->bank_offset = 0;
> +
>     s_ioport_ctrl = cpu_register_io_memory(vga_mm_read_ctrl, 
> vga_mm_write_ctrl, s);
>     vga_io_memory = cpu_register_io_memory(vga_mem_read, vga_mem_write, s);
>
> -    vmstate_register(NULL, 0, &vmstate_vga_common, s);
> +    cpu_register_physical_memory(VRAM_BASE + 0x000a, 0x2, 
> vga_io_memory);
> +    qemu_regis

Re: [Qemu-devel] [PATCH 6/8] [MIPS] qdev: convert g364fb to sysbus device

[Blue Swirl]

2010/9/8 Hervé Poussineau :
> Use it in Jazz emulation
> Remove g364fb_mm_init() function, which is not used anymore
>
> Signed-off-by: Hervé Poussineau 
> ---
>  hw/g364fb.c    |  120 +--
>  hw/mips.h      |    5 --
>  hw/mips_jazz.c |    2 +-
>  3 files changed, 64 insertions(+), 63 deletions(-)
>
> diff --git a/hw/g364fb.c b/hw/g364fb.c
> index 3c8fb98..10c53fc 100644
> --- a/hw/g364fb.c
> +++ b/hw/g364fb.c
> @@ -17,10 +17,9 @@
>  * with this program; if not, see .
>  */
>
> -#include "hw.h"
> -#include "mips.h"
>  #include "console.h"
>  #include "pixel_ops.h"
> +#include "sysbus.h"
>
>  //#define DEBUG_G364
>
> @@ -33,11 +32,14 @@ do { printf("g364: " fmt , ## __VA_ARGS__); } while (0)
>  #define BADF(fmt, ...) \
>  do { fprintf(stderr, "g364 ERROR: " fmt , ## __VA_ARGS__);} while (0)
>
> +#define VRAM_BASE 0x4000
> +
>  typedef struct G364State {
> +    DeviceState qdev;
>     /* hardware */
>     uint8_t *vram;
>     ram_addr_t vram_offset;
> -    int vram_size;
> +    uint32_t vram_size;
>     qemu_irq irq;
>     /* registers */
>     uint8_t color_palette[256][3];
> @@ -279,9 +281,8 @@ static inline void g364fb_invalidate_display(void *opaque)
>     }
>  }
>
> -static void g364fb_reset(void *opaque)
> +static void g364fb_reset(G364State *s)
>  {
> -    G364State *s = opaque;
>     qemu_irq_lower(s->irq);
>
>     memset(s->color_palette, 0, sizeof(s->color_palette));
> @@ -292,7 +293,7 @@ static void g364fb_reset(void *opaque)
>     s->top_of_screen = 0;
>     s->width = s->height = 0;
>     memset(s->vram, 0, s->vram_size);
> -    g364fb_invalidate_display(opaque);
> +    g364fb_invalidate_display(s);
>  }
>
>  static void g364fb_screen_dump(void *opaque, const char *filename)
> @@ -534,28 +535,9 @@ static CPUWriteMemoryFunc * const g364fb_ctrl_write[3] = 
> {
>     g364fb_ctrl_writel,
>  };
>
> -static int g364fb_load(QEMUFile *f, void *opaque, int version_id)
> +static int g364fb_post_load(void *opaque, int version_id)
>  {
>     G364State *s = opaque;
> -    unsigned int i, vram_size;
> -
> -    if (version_id != 1)
> -        return -EINVAL;
> -
> -    vram_size = qemu_get_be32(f);
> -    if (vram_size < s->vram_size)
> -        return -EINVAL;
> -    qemu_get_buffer(f, s->vram, s->vram_size);
> -    for (i = 0; i < 256; i++)
> -        qemu_get_buffer(f, s->color_palette[i], 3);
> -    for (i = 0; i < 3; i++)
> -        qemu_get_buffer(f, s->cursor_palette[i], 3);
> -    qemu_get_buffer(f, (uint8_t *)s->cursor, sizeof(s->cursor));
> -    s->cursor_position = qemu_get_be32(f);
> -    s->ctla = qemu_get_be32(f);
> -    s->top_of_screen = qemu_get_be32(f);
> -    s->width = qemu_get_be32(f);
> -    s->height = qemu_get_be32(f);
>
>     /* force refresh */
>     g364fb_update_depth(s);
> @@ -564,51 +546,75 @@ static int g364fb_load(QEMUFile *f, void *opaque, int 
> version_id)
>     return 0;
>  }
>
> -static void g364fb_save(QEMUFile *f, void *opaque)
> -{
> -    G364State *s = opaque;
> -    int i;
> +static const VMStateDescription vmstate_g364fb = {
> +    .name = "g364fb",
> +    .version_id = 0,
> +    .minimum_version_id = 0,
> +    .minimum_version_id_old = 0,
> +    .post_load = g364fb_post_load,
> +    .fields = (VMStateField []) {
> +        /* FIXME: vram? */
> +        VMSTATE_BUFFER_UNSAFE(color_palette, G364State, 0, 256 * 3),
> +        VMSTATE_BUFFER_UNSAFE(cursor_palette, G364State, 0, 9),
> +        VMSTATE_UINT16_ARRAY(cursor, G364State, 512),
> +        VMSTATE_UINT32(cursor_position, G364State),
> +        VMSTATE_UINT32(ctla, G364State),
> +        VMSTATE_UINT32(top_of_screen, G364State),
> +        VMSTATE_UINT32(width, G364State),
> +        VMSTATE_UINT32(height, G364State),
> +        VMSTATE_END_OF_LIST()
> +    }
> +};
>
> -    qemu_put_be32(f, s->vram_size);
> -    qemu_put_buffer(f, s->vram, s->vram_size);
> -    for (i = 0; i < 256; i++)
> -        qemu_put_buffer(f, s->color_palette[i], 3);
> -    for (i = 0; i < 3; i++)
> -        qemu_put_buffer(f, s->cursor_palette[i], 3);
> -    qemu_put_buffer(f, (uint8_t *)s->cursor, sizeof(s->cursor));
> -    qemu_put_be32(f, s->cursor_position);
> -    qemu_put_be32(f, s->ctla);
> -    qemu_put_be32(f, s->top_of_screen);
> -    qemu_put_be32(f, s->width);
> -    qemu_put_be32(f, s->height);
> -}
> +typedef struct {
> +    SysBusDevice busdev;
> +    G364State g364;
> +} SysBusG364State;
>
> -int g364fb_mm_init(target_phys_addr_t vram_base,
> -                   target_phys_addr_t ctrl_base, int it_shift,
> -                   qemu_irq irq)
> +static int g364fb_sysbus_initfn(SysBusDevice *dev)
>  {
> -    G364State *s;
> +    G364State *s = &FROM_SYSBUS(SysBusG364State, dev)->g364;
>     int io_ctrl;
>
> -    s = qemu_mallocz(sizeof(G364State));
> -
> -    s->vram_size = 8 * 1024 * 1024;
>     s->vram_offset = qemu_ram_alloc(NULL, "g364fb.vram", s->vram_size);
>     s->vram = qemu_get_ram_ptr(s->vram_offset);
> -    s->irq = irq;
> -
> - 

Re: [Qemu-devel] [PATCH 8/8] [MIPS] qdev: convert rc4030 to sysbus device

[Blue Swirl]

2010/9/8 Hervé Poussineau :
> Use it in Jazz emulation
> Remove rc4030_init() function, which is not used anymore
>
> Signed-off-by: Hervé Poussineau 
> ---
>  hw/mips.h      |    4 +-
>  hw/mips_jazz.c |    8 +--
>  hw/rc4030.c    |  135 ++-
>  3 files changed, 69 insertions(+), 78 deletions(-)
>
> diff --git a/hw/mips.h b/hw/mips.h
> index 2897ea6..bdbe024 100644
> --- a/hw/mips.h
> +++ b/hw/mips.h
> @@ -16,8 +16,8 @@ typedef struct rc4030DMAState *rc4030_dma;
>  void rc4030_dma_memory_rw(void *opaque, target_phys_addr_t addr, uint8_t 
> *buf, int len, int is_write);
>  void rc4030_dma_read(void *dma, uint8_t *buf, int len);
>  void rc4030_dma_write(void *dma, uint8_t *buf, int len);
> -
> -void *rc4030_init(qemu_irq timer, rc4030_dma **dmas);
> +extern rc4030_dma *rc4030_dmas;
> +extern void *rc4030_dma_opaque;

These should be device properties (DEFINE_PROP_PTR, qdev_set_prop_ptr().

>
>  /* dp8393x.c */
>  void dp83932_init(NICInfo *nd, target_phys_addr_t base, int it_shift,
> diff --git a/hw/mips_jazz.c b/hw/mips_jazz.c
> index 56739db..eec30c8 100644
> --- a/hw/mips_jazz.c
> +++ b/hw/mips_jazz.c
> @@ -133,8 +133,6 @@ void mips_jazz_init (ram_addr_t ram_size,
>     CPUState *env;
>     DeviceState *dev;
>     qemu_irq rc4030[16], *i8259;
> -    rc4030_dma *dmas;
> -    void* rc4030_opaque;
>     int s_rtc, s_dma_dummy;
>     NICInfo *nd;
>     PITState *pit;
> @@ -196,7 +194,7 @@ void mips_jazz_init (ram_addr_t ram_size,
>         rc4030[n] = qdev_get_gpio_in(dev, n);
>     }
>
> -    rc4030_opaque = rc4030_init(env->irq[6], &dmas);
> +    sysbus_create_simple("rc4030", 0x8000, env->irq[6]);
>     s_dma_dummy = cpu_register_io_memory(dma_dummy_read, dma_dummy_write, 
> NULL);
>     cpu_register_physical_memory(0x8000d000, 0x1000, s_dma_dummy);
>
> @@ -237,7 +235,7 @@ void mips_jazz_init (ram_addr_t ram_size,
>             nd->model = qemu_strdup("dp83932");
>         if (strcmp(nd->model, "dp83932") == 0) {
>             dp83932_init(nd, 0x80001000, 2, rc4030[4],
> -                         rc4030_opaque, rc4030_dma_memory_rw);
> +                         rc4030_dma_opaque, rc4030_dma_memory_rw);
>             break;
>         } else if (strcmp(nd->model, "?") == 0) {
>             fprintf(stderr, "qemu: Supported NICs: dp83932\n");
> @@ -250,7 +248,7 @@ void mips_jazz_init (ram_addr_t ram_size,
>
>     /* SCSI adapter */
>     esp_init(0x80002000, 0,
> -             rc4030_dma_read, rc4030_dma_write, dmas[0],
> +             rc4030_dma_read, rc4030_dma_write, rc4030_dmas[0],
>              rc4030[5], &esp_reset);
>
>     /* Floppy */
> diff --git a/hw/rc4030.c b/hw/rc4030.c
> index 811d12d..0c77c44 100644
> --- a/hw/rc4030.c
> +++ b/hw/rc4030.c
> @@ -45,6 +45,9 @@ static const char* irq_names[] = { "parallel", "floppy", 
> "sound", "video",
>  #define RC4030_ERROR(fmt, ...) \
>  do { fprintf(stderr, "rc4030 ERROR: %s: " fmt, __func__ , ## __VA_ARGS__); } 
> while (0)
>
> +rc4030_dma *rc4030_dmas = NULL;
> +void *rc4030_dma_opaque = NULL;
> +
>  //
>  /* rc4030 emulation                                     */
>
> @@ -584,9 +587,8 @@ static void jazzio_reset(JazzIoState* s)
>     qemu_irq_lower(s->irq);
>  }
>
> -static void rc4030_reset(void *opaque)
> +static void rc4030_reset(rc4030State *s)
>  {
> -    rc4030State *s = opaque;
>     int i;
>
>     s->config = 0x410; /* some boards seem to accept 0x104 too */
> @@ -611,63 +613,6 @@ static void rc4030_reset(void *opaque)
>     qemu_irq_lower(s->timer_irq);
>  }
>
> -static int rc4030_load(QEMUFile *f, void *opaque, int version_id)
> -{
> -    rc4030State* s = opaque;
> -    int i, j;
> -
> -    if (version_id != 2)
> -        return -EINVAL;
> -
> -    s->config = qemu_get_be32(f);
> -    s->invalid_address_register = qemu_get_be32(f);
> -    for (i = 0; i < 8; i++)
> -        for (j = 0; j < 4; j++)
> -            s->dma_regs[i][j] = qemu_get_be32(f);
> -    s->dma_tl_base = qemu_get_be32(f);
> -    s->dma_tl_limit = qemu_get_be32(f);
> -    s->cache_maint = qemu_get_be32(f);
> -    s->remote_failed_address = qemu_get_be32(f);
> -    s->memory_failed_address = qemu_get_be32(f);
> -    s->cache_ptag = qemu_get_be32(f);
> -    s->cache_ltag = qemu_get_be32(f);
> -    s->cache_bmask = qemu_get_be32(f);
> -    s->offset210 = qemu_get_be32(f);
> -    s->nvram_protect = qemu_get_be32(f);
> -    for (i = 0; i < 15; i++)
> -        s->rem_speed[i] = qemu_get_be32(f);
> -    s->itr = qemu_get_be32(f);
> -
> -    set_next_tick(s);
> -
> -    return 0;
> -}
> -
> -static void rc4030_save(QEMUFile *f, void *opaque)
> -{
> -    rc4030State* s = opaque;
> -    int i, j;
> -
> -    qemu_put_be32(f, s->config);
> -    qemu_put_be32(f, s->invalid_address_register);
> -    for (i = 0; i < 8; i++)
> -        for (j = 0; j < 4; j++)
> -            qemu_put_be32(f, s->dma_regs[i][j]);
> -    qemu_put_be32(f, s->dma_tl_base);
> -    qemu_put_be32(f, s->dma

[Qemu-devel] Re: [RFC] qed: Add QEMU Enhanced Disk format

[Paolo Bonzini]

On 09/09/2010 02:49 PM, Anthony Liguori wrote:

We should optimize for the future. That means a btrfs file system and/or
enterprise storage.


So we should just implement a copy-on-read wrapper that generates a 
sparse raw image and uses FIEMAP (or whatever it is called these days) 
to test for the presence of extents.  Then you let btrfs handle 
everything else...


Paolo

[Qemu-devel] Re: [RFC] qed: Add QEMU Enhanced Disk format

[Anthony Liguori]

On 09/09/2010 11:48 AM, Paolo Bonzini wrote:

On 09/09/2010 02:49 PM, Anthony Liguori wrote:

We should optimize for the future. That means a btrfs file system and/or
enterprise storage.


So we should just implement a copy-on-read wrapper that generates a 
sparse raw image and uses FIEMAP (or whatever it is called these days) 
to test for the presence of extents.  Then you let btrfs handle 
everything else...


My position is that we'll need a sparse image format well into the 
future because while btrfs may be ubiquitous as a file system, IRL, 
people transfer images around all of the time through dumb transports 
like HTTP and fat-formatted USB keys.  A 100GB image with 1GB allocated 
cannot explode to 100GB just because HTTP is a dump transport.


Where we should do copy-on-read is a different topic.  Really, I should 
have waited to share that feature to avoid confusing the current discussion.


Regards,

Anthony Liguori



Paolo

Re: [Qemu-devel] [PATCH] Add new user mode option -ignore-environment

[Stefan Weil]

Am 16.07.2010 09:04, schrieb Markus Armbruster:

Stefan Weil  writes:

   

An empty environment is sometimes useful in user mode.
The new option provides it for linux-user and bsd-user
(darwin-user still has no environment related options).
 

Stupid question: why is /usr/bin/env insufficient?

[...]
   


Hi Markus,

was your question answered (and can Antony commit this change to QEMU 
master)?


Regards
Stefan

[Qemu-devel] Re: [PATCH] docs: Improve documentation

[Stefan Weil]

Am 03.08.2010 11:48, schrieb Juan Quintela:

Stefan Weil  wrote:
   

Fix some inconsistencies (tabs and punctuation)
and try to improve grammar and spelling.

Cc: Juan Quintela
Signed-off-by: Stefan Weil
 

Acked-by: Juan Quintela

Anthony, please apply.

Stefan, thanks very much for the improvements.

Later, Juan.
   



Hello Anthony,

this patch got lost in your queue. Could you please apply it?

Thanks,
Stefan

Re: [Qemu-devel] [PATCH] Add new user mode option -ignore-environment

[Anthony Liguori]

On 09/09/2010 12:30 PM, Stefan Weil wrote:

Am 16.07.2010 09:04, schrieb Markus Armbruster:

Stefan Weil  writes:


An empty environment is sometimes useful in user mode.
The new option provides it for linux-user and bsd-user
(darwin-user still has no environment related options).

Stupid question: why is /usr/bin/env insufficient?

[...]


Hi Markus,

was your question answered (and can Antony commit this change to QEMU 
master)?


Riku is the linux-user maintainer so it really ought to go through his tree.

Regards,

Anthony Liguori


Regards
Stefan

[Qemu-devel] Re: [PATCH] hw/omap: Fix default setup for OMAP UART devices

[Stefan Weil]

Am 08.08.2010 14:09, schrieb Stefan Weil:

Character devices created by qemu_chr_open don't
allow duplicate device names, so naming all
UART devices "null" no longer works.

Running "qemu-system-arm -M n800" (and some other machines)
results in this error message:

qemu-system-arm: Duplicate ID 'null' for chardev
Can't create serial device, empty char device

This is fixed by setting a default label "uart1",
"uart2" or "uart3".

Cc: Andrzej Zaborowski
Signed-off-by: Stefan Weil
---
  hw/omap.h  |6 --
  hw/omap1.c |3 +++
  hw/omap2.c |6 +-
  hw/omap_uart.c |   12 +++-
  4 files changed, 19 insertions(+), 8 deletions(-)

diff --git a/hw/omap.h b/hw/omap.h
index 18eb72b..fe32ca5 100644
--- a/hw/omap.h
+++ b/hw/omap.h
@@ -664,10 +664,12 @@ void omap_synctimer_reset(struct omap_synctimer_s *s);
  struct omap_uart_s;
  struct omap_uart_s *omap_uart_init(target_phys_addr_t base,
  qemu_irq irq, omap_clk fclk, omap_clk iclk,
-qemu_irq txdma, qemu_irq rxdma, CharDriverState *chr);
+qemu_irq txdma, qemu_irq rxdma,
+const char *label, CharDriverState *chr);
  struct omap_uart_s *omap2_uart_init(struct omap_target_agent_s *ta,
  qemu_irq irq, omap_clk fclk, omap_clk iclk,
-qemu_irq txdma, qemu_irq rxdma, CharDriverState *chr);
+qemu_irq txdma, qemu_irq rxdma,
+const char *label, CharDriverState *chr);
  void omap_uart_reset(struct omap_uart_s *s);
  void omap_uart_attach(struct omap_uart_s *s, CharDriverState *chr);

diff --git a/hw/omap1.c b/hw/omap1.c
index cf0d428..5fc2345 100644
--- a/hw/omap1.c
+++ b/hw/omap1.c
@@ -3808,16 +3808,19 @@ struct omap_mpu_state_s *omap310_mpu_init(unsigned long 
sdram_size,
  omap_findclk(s, "uart1_ck"),
  omap_findclk(s, "uart1_ck"),
  s->drq[OMAP_DMA_UART1_TX], s->drq[OMAP_DMA_UART1_RX],
+"uart1",
  serial_hds[0]);
  s->uart[1] = omap_uart_init(0xfffb0800, s->irq[1][OMAP_INT_UART2],
  omap_findclk(s, "uart2_ck"),
  omap_findclk(s, "uart2_ck"),
  s->drq[OMAP_DMA_UART2_TX], s->drq[OMAP_DMA_UART2_RX],
+"uart2",
  serial_hds[0] ? serial_hds[1] : NULL);
  s->uart[2] = omap_uart_init(0xfffb9800, s->irq[0][OMAP_INT_UART3],
  omap_findclk(s, "uart3_ck"),
  omap_findclk(s, "uart3_ck"),
  s->drq[OMAP_DMA_UART3_TX], s->drq[OMAP_DMA_UART3_RX],
+"uart3",
  serial_hds[0]&&  serial_hds[1] ? serial_hds[2] : NULL);

  omap_dpll_init(&s->dpll[0], 0xfffecf00, omap_findclk(s, "dpll1"));
diff --git a/hw/omap2.c b/hw/omap2.c
index 179075e..e35a56e 100644
--- a/hw/omap2.c
+++ b/hw/omap2.c
@@ -2291,13 +2291,16 @@ struct omap_mpu_state_s *omap2420_mpu_init(unsigned 
long sdram_size,
  omap_findclk(s, "uart1_fclk"),
  omap_findclk(s, "uart1_iclk"),
  s->drq[OMAP24XX_DMA_UART1_TX],
-s->drq[OMAP24XX_DMA_UART1_RX], serial_hds[0]);
+s->drq[OMAP24XX_DMA_UART1_RX],
+"uart1",
+serial_hds[0]);
  s->uart[1] = omap2_uart_init(omap_l4ta(s->l4, 20),
  s->irq[0][OMAP_INT_24XX_UART2_IRQ],
  omap_findclk(s, "uart2_fclk"),
  omap_findclk(s, "uart2_iclk"),
  s->drq[OMAP24XX_DMA_UART2_TX],
  s->drq[OMAP24XX_DMA_UART2_RX],
+"uart2",
  serial_hds[0] ? serial_hds[1] : NULL);
  s->uart[2] = omap2_uart_init(omap_l4ta(s->l4, 21),
  s->irq[0][OMAP_INT_24XX_UART3_IRQ],
@@ -2305,6 +2308,7 @@ struct omap_mpu_state_s *omap2420_mpu_init(unsigned long 
sdram_size,
  omap_findclk(s, "uart3_iclk"),
  s->drq[OMAP24XX_DMA_UART3_TX],
  s->drq[OMAP24XX_DMA_UART3_RX],
+"uart3",
  serial_hds[0]&&  serial_hds[1] ? serial_hds[2] : NULL);

  s->gptimer[0] = omap_gp_timer_init(omap_l4ta(s->l4, 7),
diff --git a/hw/omap_uart.c b/hw/omap_uart.c
index 395bf0c..cc66cd9 100644
--- a/hw/omap_uart.c
+++ b/hw/omap_uart.c
@@ -51,7 +51,8 @@ void omap_uart_reset(struct omap_uart_s *s)

  struct omap_uart_s *omap_uart_init(target_phys_addr_t base,
  qemu_irq irq, omap_clk fclk, omap_clk iclk,
-qemu_irq txdma, qemu_irq rxdma, CharDriverState *chr)
+qemu_irq txdma, qemu_irq rxdma,
+const char *label, CharDriverState *chr)
  {
  struct omap_uart_s *s = (struct omap_uart_s *)
  qemu_mallocz(sizeof(struct omap_uart_s));
@@ -61,11 +62,11 @@ struct omap_uart_s *omap_uart_init(target_phys_addr_t base,

Re: [Qemu-devel] [PATCH] elf: Calculate symbol size if needed

[Stefan Weil]

Am 11.08.2010 18:21, schrieb Blue Swirl:

On Mon, Aug 9, 2010 at 2:43 PM, Stefan Weil  wrote:
   

Symbols with a size of 0 are unusable for the disassembler.

Example:

While running an arm linux kernel, no symbolic names are
used in qemu.log when the cpu is executing an assembler function.
 

That is a problem of the assembler function, it should use '.size'
directive like what happens when C code is compiled. And why just ARM?

   

Assume that the size of such symbols is the difference to the
next symbol value.

Signed-off-by: Stefan Weil
---
  hw/elf_ops.h |5 +
  1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/hw/elf_ops.h b/hw/elf_ops.h
index 27d1ab9..0bd7235 100644
--- a/hw/elf_ops.h
+++ b/hw/elf_ops.h
@@ -153,6 +153,11 @@ static int glue(load_symbols, SZ)(struct elfhdr *ehdr, int 
fd, int must_swab,
 syms = qemu_realloc(syms, nsyms * sizeof(*syms));

 qsort(syms, nsyms, sizeof(*syms), glue(symcmp, SZ));
+for (i = 0; i<  nsyms - 1; i++) {
+if (syms[i].st_size == 0) {
+syms[i].st_size = syms[i + 1].st_value - syms[i].st_value;
+}
+}
 

The size of the last symbol is not guesstimated, it could be assumed
to be _etext - syms[nsyms].st_value.

   

 } else {
 qemu_free(syms);
 syms = NULL;
--
1.7.1





The patch is still missing in qemu master.
From the two feedbacks I did not read that anything needs to be changed.
Was I wrong, or can it be applied?

Re: [Qemu-devel] [RFC] qed: Add QEMU Enhanced Disk format

[Anthony Liguori]

On 09/09/2010 01:59 AM, Avi Kivity wrote:

 On 09/08/2010 06:07 PM, Stefan Hajnoczi wrote:

 uint32_t table_size;  /* table size, in clusters */

Presumably L1 table size?  Or any table size?

Hm.  It would be nicer not to require contiguous sectors anywhere.  How
about a variable- or fixed-height tree?

Both extents and fancier trees don't fit the philosophy, which is to
keep things straightforward and fast by doing less.  With extents and
trees you've got something that looks much more like a full-blown
filesystem.  Is there an essential feature or characteristic that QED
cannot provide in its current design?



Not using extents mean that random workloads on very large disks will 
continuously need to page in L2s (which are quite large, 256KB is 
large enough that you need to account for read time, not just seek 
time).  Keeping it to two levels means that the image size is limited, 
not very good for an image format designed in 2010.


Define "very large disks".

My target for VM images is 100GB-1TB.  Practically speaking, that at 
least covers us for the next 5 years.


Since QED has rich support for features, we can continue to evolve the 
format over time in a backwards compatible way.  I'd rather delay 
supporting massively huge disks for the future when we better understand 
true nature of the problem.


Is the physical image size always derived from the host file 
metadata?  Is

this always safe?

In my email summarizing crash scenarios and recovery we cover the
bases and I think it is safe to rely on file size as physical image
size.  The drawback is that you need a host filesystem and cannot
directly use a bare block device.  I think that is acceptable for a
sparse format, otherwise we'd be using raw.


Hm, we do have a use case for qcow2-over-lvm.  I can't say it's 
something I like, but a point to consider.


We specifically are not supporting that use-case in QED today.  There's 
a good reason for it.  For cluster allocation, we achieve good 
performance because for L2 cluster updates, we can avoid synchronous 
metadata updates (except for L1 updates).


We achieve synchronous metadata updates by leveraging the underlying 
filesystem's metadata.  The underlying filesystems are much smarter 
about their metadata updates.  They'll keep a journal to delay 
synchronous updates and other fancy things.


If we tried to represent the disk size in the header, we would have to 
do an fsync() on every cluster allocation.


I can only imagine the use case for qcow2-over-lvm is performance.  But 
the performance of QED on a file system is so much better than qcow2 
that you can safely just use a file system and avoid the complexity of 
qcow2 over lvm.


Regards,

Anthony Liguori

[Qemu-devel] Re: [PATCH] hw/arm: Improve detection of Linux kernels

[Stefan Weil]

Am 09.08.2010 16:48, schrieb Stefan Weil:

ELF images were not detected as linux kernels.

Assume that they are linux kernels if the kernel name contains 'vmlinux'.

Cc: Paul Brook
Signed-off-by: Stefan Weil
---
  hw/arm_boot.c |6 --
  1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/hw/arm_boot.c b/hw/arm_boot.c
index 620550b..e73ef42 100644
--- a/hw/arm_boot.c
+++ b/hw/arm_boot.c
@@ -204,7 +204,7 @@ void arm_load_kernel(CPUState *env, struct arm_boot_info 
*info)
  int kernel_size;
  int initrd_size;
  int n;
-int is_linux = 0;
+int is_linux;
  uint64_t elf_entry;
  target_phys_addr_t entry;
  int big_endian;
@@ -225,7 +225,9 @@ void arm_load_kernel(CPUState *env, struct arm_boot_info 
*info)
  big_endian = 0;
  #endif

-/* Assume that raw images are linux kernels, and ELF images are not.  */
+/* Assume that raw images are linux kernels, and ELF images
+   are not (unless the kernel filename contains 'vmlinux'). */
+is_linux = (strstr(info->kernel_filename, "vmlinux") != NULL);
  kernel_size = load_elf(info->kernel_filename, NULL, NULL,&elf_entry,
 NULL, NULL, big_endian, ELF_MACHINE, 1);
  entry = elf_entry;
   



The patch is still missing in qemu master. Is anything missing,
or can it be applied?

Re: [Qemu-devel] [PATCH 4/4] cpu model corrections/updates: add verbose config file handling

[Blue Swirl]

On Thu, Sep 9, 2010 at 3:48 AM, john cooper  wrote:
> Blue Swirl wrote:
>> On Tue, Sep 7, 2010 at 12:31 PM, john cooper  wrote:
>>> Failure by qemu to open a default config file isn't cause to
>>> error exit -- it just quietly continues on.   After puzzling
>>> issues with otherwise opaque config file locations and
>>> startup handling numerous times, some help from qemu seemed
>>> justified.
>>
>> Maybe there should be an error exit if the user specifies a config
>> file but there are problems with it?
>
> That's one possibility.  However given the preexisting
> behavior where open of at least one of the config files
> routinely fails and is quietly dismissed, issuing warnings
> would seem distracting to the user.
>
> I think one config file is all which is needed, and the
> config syntax can be extended to allow including other
> vendor/install specific files as needed.  I particularly
> feel so as we've locally had to add yet a third config file
> to push system quasi-static config data out of the way of
> possible user modification for libvirt concerns.  That was
> a last-minute bandaid solution which just makes the problem
> worse.  Anyway such vendor specific config structure should
> be handled within the config mechanism itself vs. hard coding
> it into qemu startup.
>
>>> In the case of a "?" pseudo filename arg to -readconfig,
>>> verbose open of all config files will be enabled.  Normal
>>> handling of config files is otherwise unaffected by this
>>> option.
>>
>> I think '?' is not very good name.
>
> I agree, a shell meta char wasn't my first choice.  However
> it follows the precedent of '?' used in similar query operations
> and was chosen only for CLI consistency.

But '?' is used for other purposes: query available options. It would
be more logical if -readconfig '?' instead could be used to query the
default config files.

>> Could we add flags to -readconfig,
>> like -readconfig verbose,nodefaultconfig,file='', to match other
>> options' syntax?
>
> That seems most natural for options specific to the associated
> config file.  However the verbose flag was intended as a
> global action rather than local to a given config file.  The
> preexisting "nodefconfig" is also a global option.

Right. It just seems that there are a lot of global flags. How about
-config nodefaults,verbose?

Re: [Qemu-devel] [PATCH] elf: Calculate symbol size if needed

[Blue Swirl]

On Thu, Sep 9, 2010 at 5:42 PM, Stefan Weil  wrote:
> Am 11.08.2010 18:21, schrieb Blue Swirl:
>>
>> On Mon, Aug 9, 2010 at 2:43 PM, Stefan Weil  wrote:
>>
>>>
>>> Symbols with a size of 0 are unusable for the disassembler.
>>>
>>> Example:
>>>
>>> While running an arm linux kernel, no symbolic names are
>>> used in qemu.log when the cpu is executing an assembler function.
>>>
>>
>> That is a problem of the assembler function, it should use '.size'
>> directive like what happens when C code is compiled. And why just ARM?
>>
>>
>>>
>>> Assume that the size of such symbols is the difference to the
>>> next symbol value.
>>>
>>> Signed-off-by: Stefan Weil
>>> ---
>>>  hw/elf_ops.h |    5 +
>>>  1 files changed, 5 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/hw/elf_ops.h b/hw/elf_ops.h
>>> index 27d1ab9..0bd7235 100644
>>> --- a/hw/elf_ops.h
>>> +++ b/hw/elf_ops.h
>>> @@ -153,6 +153,11 @@ static int glue(load_symbols, SZ)(struct elfhdr
>>> *ehdr, int fd, int must_swab,
>>>         syms = qemu_realloc(syms, nsyms * sizeof(*syms));
>>>
>>>         qsort(syms, nsyms, sizeof(*syms), glue(symcmp, SZ));
>>> +        for (i = 0; i<  nsyms - 1; i++) {
>>> +            if (syms[i].st_size == 0) {
>>> +                syms[i].st_size = syms[i + 1].st_value -
>>> syms[i].st_value;
>>> +            }
>>> +        }
>>>
>>
>> The size of the last symbol is not guesstimated, it could be assumed
>> to be _etext - syms[nsyms].st_value.
>>
>>
>>>
>>>     } else {
>>>         qemu_free(syms);
>>>         syms = NULL;
>>> --
>>> 1.7.1
>>
>
>
> The patch is still missing in qemu master.
> From the two feedbacks I did not read that anything needs to be changed.
> Was I wrong, or can it be applied?

Please fix the last symbol. Either we should fix all symbols or none,
half fixed (OK, practically all) is not so great.

Re: [Qemu-devel] [PATCH] elf: Calculate symbol size if needed

[Stefan Weil]

Am 09.09.2010 20:44, schrieb Blue Swirl:

On Thu, Sep 9, 2010 at 5:42 PM, Stefan Weil  wrote:

Am 11.08.2010 18:21, schrieb Blue Swirl:


On Mon, Aug 9, 2010 at 2:43 PM, Stefan Weil 
 wrote:




Symbols with a size of 0 are unusable for the disassembler.

Example:

While running an arm linux kernel, no symbolic names are
used in qemu.log when the cpu is executing an assembler function.



That is a problem of the assembler function, it should use '.size'
directive like what happens when C code is compiled. And why just ARM?




Assume that the size of such symbols is the difference to the
next symbol value.

Signed-off-by: Stefan Weil
---
 hw/elf_ops.h |5 +
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/hw/elf_ops.h b/hw/elf_ops.h
index 27d1ab9..0bd7235 100644
--- a/hw/elf_ops.h
+++ b/hw/elf_ops.h
@@ -153,6 +153,11 @@ static int glue(load_symbols, SZ)(struct elfhdr
*ehdr, int fd, int must_swab,
syms = qemu_realloc(syms, nsyms * sizeof(*syms));

qsort(syms, nsyms, sizeof(*syms), glue(symcmp, SZ));
+for (i = 0; i<  nsyms - 1; i++) {
+if (syms[i].st_size == 0) {
+syms[i].st_size = syms[i + 1].st_value -
syms[i].st_value;
+}
+}



The size of the last symbol is not guesstimated, it could be assumed
to be _etext - syms[nsyms].st_value.




} else {
qemu_free(syms);
syms = NULL;
--
1.7.1





The patch is still missing in qemu master.
From the two feedbacks I did not read that anything needs to be changed.
Was I wrong, or can it be applied?


Please fix the last symbol. Either we should fix all symbols or none,
half fixed (OK, practically all) is not so great.



The last symbol is one of several thousands, and most symbols don't need 
a fix,
so with my fix more than 99.9 or even 99.99 percent of all symbols are 
ok :-)
If the last symbol happens to be wrong, there is still a high 
probability that
nobody will notice this because it is unused by QEMU. The problem I 
faced with

QEMU's disassembly came from symbols with an address followed by code.
Is there any code after the last symbol? I don't expect that. In a 
sorted list

of symbols from the text segment, _etext should be the last symbols!

I think that the small chance of a missing fix for the last symbol is in 
no relation

to the code needed.

Even worse, I have no simple formula to guess a valid value for the last 
symbol.
The formula you suggested (with the corrections I wrote in my reply) is 
only ok
if the last symbol is in the text segment. Usually there are also 
symbols for data

in other segments, and in many cases these segments are located after the
text segment. In these cases the last symbol is not located in the text 
segment

which makes guesses of its size much more complicated.

To make it short: I don't know how to fix the last symbol in a 
reasonable way.


Sorry,
Stefan

Re: [Qemu-devel] [PATCH] elf: Calculate symbol size if needed

[Blue Swirl]

On Thu, Sep 9, 2010 at 7:11 PM, Stefan Weil  wrote:
> Am 09.09.2010 20:44, schrieb Blue Swirl:
>>
>> On Thu, Sep 9, 2010 at 5:42 PM, Stefan Weil  wrote:
>>>
>>> Am 11.08.2010 18:21, schrieb Blue Swirl:

 On Mon, Aug 9, 2010 at 2:43 PM, Stefan Weil
  wrote:

>
> Symbols with a size of 0 are unusable for the disassembler.
>
> Example:
>
> While running an arm linux kernel, no symbolic names are
> used in qemu.log when the cpu is executing an assembler function.
>

 That is a problem of the assembler function, it should use '.size'
 directive like what happens when C code is compiled. And why just ARM?


>
> Assume that the size of such symbols is the difference to the
> next symbol value.
>
> Signed-off-by: Stefan Weil
> ---
>  hw/elf_ops.h |    5 +
>  1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/hw/elf_ops.h b/hw/elf_ops.h
> index 27d1ab9..0bd7235 100644
> --- a/hw/elf_ops.h
> +++ b/hw/elf_ops.h
> @@ -153,6 +153,11 @@ static int glue(load_symbols, SZ)(struct elfhdr
> *ehdr, int fd, int must_swab,
>        syms = qemu_realloc(syms, nsyms * sizeof(*syms));
>
>        qsort(syms, nsyms, sizeof(*syms), glue(symcmp, SZ));
> +        for (i = 0; i<  nsyms - 1; i++) {
> +            if (syms[i].st_size == 0) {
> +                syms[i].st_size = syms[i + 1].st_value -
> syms[i].st_value;
> +            }
> +        }
>

 The size of the last symbol is not guesstimated, it could be assumed
 to be _etext - syms[nsyms].st_value.


>
>    } else {
>        qemu_free(syms);
>        syms = NULL;
> --
> 1.7.1

>>>
>>>
>>> The patch is still missing in qemu master.
>>> From the two feedbacks I did not read that anything needs to be changed.
>>> Was I wrong, or can it be applied?
>>
>> Please fix the last symbol. Either we should fix all symbols or none,
>> half fixed (OK, practically all) is not so great.
>
>
> The last symbol is one of several thousands, and most symbols don't need a
> fix,
> so with my fix more than 99.9 or even 99.99 percent of all symbols are ok
> :-)
> If the last symbol happens to be wrong, there is still a high probability
> that
> nobody will notice this because it is unused by QEMU. The problem I faced
> with
> QEMU's disassembly came from symbols with an address followed by code.
> Is there any code after the last symbol? I don't expect that. In a sorted
> list
> of symbols from the text segment, _etext should be the last symbols!
>
> I think that the small chance of a missing fix for the last symbol is in no
> relation
> to the code needed.
>
> Even worse, I have no simple formula to guess a valid value for the last
> symbol.
> The formula you suggested (with the corrections I wrote in my reply) is only
> ok
> if the last symbol is in the text segment. Usually there are also symbols
> for data
> in other segments, and in many cases these segments are located after the
> text segment. In these cases the last symbol is not located in the text
> segment
> which makes guesses of its size much more complicated.

How about using _end then?

[Qemu-devel] [PATCH] MAINTAINERS: Add new maintainer for Linux user

[Stefan Weil]

According to Antony, Riku is the maintainer for Linux user,
so make this visible for everyone.

(The patch also fixes a whitespace issue at end of line -
required by git and by my editor).

Cc: Riku Voipio 
Cc: Antony Liguori 
Signed-off-by: Stefan Weil 
---
 MAINTAINERS |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index e5165fb..63deb87 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -68,7 +68,7 @@ S390
   s390-*.cAlexander Graf
 
 Generic Subsystems:
  
+---
 
 Dynamic translatorFabrice Bellard
 Main loop Fabrice Bellard (new maintainer needed)
@@ -83,6 +83,6 @@ Audio device layerVassili Karpov (malc)
 Character device layer?
 Network device layer  ?
 GDB stub  ?
-Linux user?
+Linux userRiku Voipio
 Darwin user   ?
 SLIRP ?
-- 
1.7.1

Re: [Qemu-devel] [PATCH] elf: Calculate symbol size if needed

[Stefan Weil]

Am 09.09.2010 21:29, schrieb Blue Swirl:

On Thu, Sep 9, 2010 at 7:11 PM, Stefan Weil  wrote:
   

Am 09.09.2010 20:44, schrieb Blue Swirl:
 

On Thu, Sep 9, 2010 at 5:42 PM, Stefan Weil  wrote:
   

Am 11.08.2010 18:21, schrieb Blue Swirl:
 

On Mon, Aug 9, 2010 at 2:43 PM, Stefan Weil
  wrote:

   

Symbols with a size of 0 are unusable for the disassembler.

Example:

While running an arm linux kernel, no symbolic names are
used in qemu.log when the cpu is executing an assembler function.

 

That is a problem of the assembler function, it should use '.size'
directive like what happens when C code is compiled. And why just ARM?


   

Assume that the size of such symbols is the difference to the
next symbol value.

Signed-off-by: Stefan Weil
---
  hw/elf_ops.h |5 +
  1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/hw/elf_ops.h b/hw/elf_ops.h
index 27d1ab9..0bd7235 100644
--- a/hw/elf_ops.h
+++ b/hw/elf_ops.h
@@ -153,6 +153,11 @@ static int glue(load_symbols, SZ)(struct elfhdr
*ehdr, int fd, int must_swab,
syms = qemu_realloc(syms, nsyms * sizeof(*syms));

qsort(syms, nsyms, sizeof(*syms), glue(symcmp, SZ));
+for (i = 0; i

Re: [Qemu-devel] [PATCH] elf: Calculate symbol size if needed

[Blue Swirl]

On Thu, Sep 9, 2010 at 7:34 PM, Stefan Weil  wrote:
> Am 09.09.2010 21:29, schrieb Blue Swirl:
>>
>> On Thu, Sep 9, 2010 at 7:11 PM, Stefan Weil  wrote:
>>
>>>
>>> Am 09.09.2010 20:44, schrieb Blue Swirl:
>>>

 On Thu, Sep 9, 2010 at 5:42 PM, Stefan Weil
  wrote:

>
> Am 11.08.2010 18:21, schrieb Blue Swirl:
>
>>
>> On Mon, Aug 9, 2010 at 2:43 PM, Stefan Weil
>>  wrote:
>>
>>
>>>
>>> Symbols with a size of 0 are unusable for the disassembler.
>>>
>>> Example:
>>>
>>> While running an arm linux kernel, no symbolic names are
>>> used in qemu.log when the cpu is executing an assembler function.
>>>
>>>
>>
>> That is a problem of the assembler function, it should use '.size'
>> directive like what happens when C code is compiled. And why just ARM?
>>
>>
>>
>>>
>>> Assume that the size of such symbols is the difference to the
>>> next symbol value.
>>>
>>> Signed-off-by: Stefan Weil
>>> ---
>>>  hw/elf_ops.h |    5 +
>>>  1 files changed, 5 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/hw/elf_ops.h b/hw/elf_ops.h
>>> index 27d1ab9..0bd7235 100644
>>> --- a/hw/elf_ops.h
>>> +++ b/hw/elf_ops.h
>>> @@ -153,6 +153,11 @@ static int glue(load_symbols, SZ)(struct elfhdr
>>> *ehdr, int fd, int must_swab,
>>>        syms = qemu_realloc(syms, nsyms * sizeof(*syms));
>>>
>>>        qsort(syms, nsyms, sizeof(*syms), glue(symcmp, SZ));
>>> +        for (i = 0; i<    nsyms - 1; i++) {
>>> +            if (syms[i].st_size == 0) {
>>> +                syms[i].st_size = syms[i + 1].st_value -
>>> syms[i].st_value;
>>> +            }
>>> +        }
>>>
>>>
>>
>> The size of the last symbol is not guesstimated, it could be assumed
>> to be _etext - syms[nsyms].st_value.
>>
>>
>>
>>>
>>>    } else {
>>>        qemu_free(syms);
>>>        syms = NULL;
>>> --
>>> 1.7.1
>>>
>>
>>
>
> The patch is still missing in qemu master.
>  From the two feedbacks I did not read that anything needs to be
> changed.
> Was I wrong, or can it be applied?
>

 Please fix the last symbol. Either we should fix all symbols or none,
 half fixed (OK, practically all) is not so great.

>>>
>>> The last symbol is one of several thousands, and most symbols don't need
>>> a
>>> fix,
>>> so with my fix more than 99.9 or even 99.99 percent of all symbols are ok
>>> :-)
>>> If the last symbol happens to be wrong, there is still a high probability
>>> that
>>> nobody will notice this because it is unused by QEMU. The problem I faced
>>> with
>>> QEMU's disassembly came from symbols with an address followed by code.
>>> Is there any code after the last symbol? I don't expect that. In a sorted
>>> list
>>> of symbols from the text segment, _etext should be the last symbols!
>>>
>>> I think that the small chance of a missing fix for the last symbol is in
>>> no
>>> relation
>>> to the code needed.
>>>
>>> Even worse, I have no simple formula to guess a valid value for the last
>>> symbol.
>>> The formula you suggested (with the corrections I wrote in my reply) is
>>> only
>>> ok
>>> if the last symbol is in the text segment. Usually there are also symbols
>>> for data
>>> in other segments, and in many cases these segments are located after the
>>> text segment. In these cases the last symbol is not located in the text
>>> segment
>>> which makes guesses of its size much more complicated.
>>>
>>
>> How about using _end then?
>>
>>
>
> Wouldn't _end be the last symbol then?

Right, _end should be the last one in any case. I'll apply the patch.

Re: [Qemu-devel] [PATCH] MAINTAINERS: Add new maintainer for Linux user

[Andreas Färber]

Am 09.09.2010 um 21:32 schrieb Stefan Weil:


According to Antony, Riku is the maintainer for Linux user,
so make this visible for everyone.


You beat me! :)

Acked-by: Andreas Färber 

Andreas


(The patch also fixes a whitespace issue at end of line -
required by git and by my editor).

Cc: Riku Voipio 
Cc: Antony Liguori 
Signed-off-by: Stefan Weil 


P.S. It's Anthony.

Re: [Qemu-devel] [PATCH] MAINTAINERS: Add new maintainer for Linux user

[Stefan Weil]

Am 09.09.2010 21:43, schrieb Andreas Färber:

Am 09.09.2010 um 21:32 schrieb Stefan Weil:


According to Antony, Riku is the maintainer for Linux user,
so make this visible for everyone.


You beat me! :)

Acked-by: Andreas Färber 

Andreas


(The patch also fixes a whitespace issue at end of line -
required by git and by my editor).

Cc: Riku Voipio 
Cc: Antony Liguori 
Signed-off-by: Stefan Weil 


P.S. It's Anthony.



Sorry, Anthony. Thanks, Andreas, for the hint.
I'll sent a new patch which corrects this important issue.

Stefan

[Qemu-devel] [PATCH] MAINTAINERS: Add new maintainer for Linux user

[Stefan Weil]

According to Anthony, Riku is the maintainer for Linux user,
so make this visible for everyone.

(The patch also fixes a whitespace issue at end of line -
required by git and by my editor).

Cc: Riku Voipio 
Cc: Anthony Liguori 
Signed-off-by: Stefan Weil 
---
 MAINTAINERS |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index e5165fb..63deb87 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -68,7 +68,7 @@ S390
   s390-*.cAlexander Graf
 
 Generic Subsystems:
  
+---
 
 Dynamic translatorFabrice Bellard
 Main loop Fabrice Bellard (new maintainer needed)
@@ -83,6 +83,6 @@ Audio device layerVassili Karpov (malc)
 Character device layer?
 Network device layer  ?
 GDB stub  ?
-Linux user?
+Linux userRiku Voipio
 Darwin user   ?
 SLIRP ?
-- 
1.7.1

[Qemu-devel] [PATCH] Update MAINTAINERS

[Anthony Liguori]

The goal of this file is not to establish strict ownership of the code base but
rather to provide a place for people to direct questions to and for names of
people to CC on patches.

I'm basing this update on my observations on how things currently work today.
If you think your name should be on something and it's not, don't read anything
into it and just correct me :-)

Signed-off-by: Anthony Liguori 

diff --git a/MAINTAINERS b/MAINTAINERS
index e5165fb..ee84f3f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4,13 +4,12 @@ QEMU Maintainers
 Project leaders:
 
 
-Fabrice Bellard
 Paul Brook
 
-CPU cores:
+TCG cores:
 --
 
-x86Fabrice Bellard
+x86?
 ARMPaul Brook
 SPARC  Blue Swirl
 MIPS   ?
@@ -26,7 +25,7 @@ Machines (sorted by CPU):
 -
 
 x86
-  pc.cFabrice Bellard (new maintainer needed)
+  pc.cAnthony Liguori
 ARM
   integratorcp.c  Paul Brook
   versatilepb.c   Paul Brook
@@ -70,19 +69,20 @@ S390
 Generic Subsystems:
 ---  
 
-Dynamic translatorFabrice Bellard
-Main loop Fabrice Bellard (new maintainer needed)
-TCG   Fabrice Bellard
-IDE device?
-SCSI device   Paul Brook
+Main loop Anthony Liguori
+TCG   ?
+KVM   Marcelo Tosatti/Avi Kivity
+Virtio devicesAnthony Liguori
+IDE devices   ?
+SCSI devices  Paul Brook
 PCI layer Michael S. Tsirkin
 USB layer ?
-Block layer   ?
-Graphic layer ?
+Block layer   Kevin Wolf
+Graphic layer Anthony Liguori
 Audio device layerVassili Karpov (malc)
-Character device layer?
-Network device layer  ?
+Character device layerAnthony Liguori
+Network device layer  Anthony Liguori/Mark McLoughlin
 GDB stub  ?
-Linux user?
-Darwin user   ?
-SLIRP ?
+Linux userRiku Voipio
+Darwin user   Unmaintained (likely to be removed)
+SLIRP Unmaintained
-- 
1.7.0.4

Re: [Qemu-devel] [PATCH] MAINTAINERS: Add new maintainer for Linux user

[Anthony Liguori]

On 09/09/2010 02:50 PM, Stefan Weil wrote:

According to Anthony, Riku is the maintainer for Linux user,
so make this visible for everyone.

(The patch also fixes a whitespace issue at end of line -
required by git and by my editor).

Cc: Riku Voipio
Cc: Anthony Liguori
Signed-off-by: Stefan Weil
   


I've got mixed feelings about it, but let me take a stab at doing a more 
thorough update to MAINTAINERS.  Comments appreciated.


Regards,

Anthony Liguori


---
  MAINTAINERS |4 ++--
  1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index e5165fb..63deb87 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -68,7 +68,7 @@ S390
s390-*.cAlexander Graf

  Generic Subsystems:

+---

  Dynamic translatorFabrice Bellard
  Main loop Fabrice Bellard (new maintainer needed)
@@ -83,6 +83,6 @@ Audio device layerVassili Karpov (malc)
  Character device layer?
  Network device layer  ?
  GDB stub  ?
-Linux user?
+Linux userRiku Voipio
  Darwin user   ?
  SLIRP ?
   

Re: [Qemu-devel] [PATCH] Update MAINTAINERS

[Stefan Weil]

Am 09.09.2010 21:54, schrieb Anthony Liguori:

The goal of this file is not to establish strict ownership of the code base but
rather to provide a place for people to direct questions to and for names of
people to CC on patches.
   


This text should be added to MAINTAINERS.


I'm basing this update on my observations on how things currently work today.
If you think your name should be on something and it's not, don't read anything
into it and just correct me :-)

Signed-off-by: Anthony Liguori

diff --git a/MAINTAINERS b/MAINTAINERS
index e5165fb..ee84f3f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4,13 +4,12 @@ QEMU Maintainers
  Project leaders:
  

-Fabrice Bellard
  Paul Brook

-CPU cores:
+TCG cores:
  --

-x86Fabrice Bellard
+x86?
  ARMPaul Brook
  SPARC  Blue Swirl
  MIPS   ?
@@ -26,7 +25,7 @@ Machines (sorted by CPU):
  -

  x86
-  pc.cFabrice Bellard (new maintainer needed)
+  pc.cAnthony Liguori
  ARM
integratorcp.c  Paul Brook
versatilepb.c   Paul Brook
@@ -70,19 +69,20 @@ S390
  Generic Subsystems:
  ---

-Dynamic translatorFabrice Bellard
-Main loop Fabrice Bellard (new maintainer needed)
-TCG   Fabrice Bellard
-IDE device?
-SCSI device   Paul Brook
+Main loop Anthony Liguori
+TCG   ?
+KVM   Marcelo Tosatti/Avi Kivity
+Virtio devicesAnthony Liguori
+IDE devices   ?
+SCSI devices  Paul Brook
  PCI layer Michael S. Tsirkin
  USB layer ?
-Block layer   ?
-Graphic layer ?
+Block layer   Kevin Wolf
+Graphic layer Anthony Liguori
  Audio device layerVassili Karpov (malc)
-Character device layer?
-Network device layer  ?
+Character device layerAnthony Liguori
+Network device layer  Anthony Liguori/Mark McLoughlin
  GDB stub  ?
-Linux user?
-Darwin user   ?
-SLIRP ?
+Linux userRiku Voipio
+Darwin user   Unmaintained (likely to be removed)
+SLIRP Unmaintained
   


Hello Anthony,

I feel responsible for any file with "Copyright (c) 20xx Stefan Weil" in 
the header.


Maybe a general remark like this would be good:

For individual files, there is usually a copyright owner mentioned in 
the file's header.

In most cases, this person also maintains this file.

(or anything similar)

For people who don't know what "Main loop" (and the other topics) is and 
also
for automated parsing (matching of files to maintainers like it is done 
by the linux kernel)

additional path or filename entries would be helpful in a future version.

Regards
Stefan

Re: [Qemu-devel] [PATCH] Update MAINTAINERS

[Blue Swirl]

On Thu, Sep 9, 2010 at 7:54 PM, Anthony Liguori  wrote:
> The goal of this file is not to establish strict ownership of the code base 
> but
> rather to provide a place for people to direct questions to and for names of
> people to CC on patches.
>
> I'm basing this update on my observations on how things currently work today.
> If you think your name should be on something and it's not, don't read 
> anything
> into it and just correct me :-)
>
> Signed-off-by: Anthony Liguori 
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index e5165fb..ee84f3f 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4,13 +4,12 @@ QEMU Maintainers
>  Project leaders:
>  
>
> -Fabrice Bellard
>  Paul Brook

+Anthony Liguori

I think that is how things work today.

>
> -CPU cores:
> +TCG cores:

That could be read as TCG host support. How about 'Guest CPU cores
(TCG)' with 'Guest CPU cores (KVM)' added later?

>  --
>
> -x86                Fabrice Bellard
> +x86                ?
>  ARM                Paul Brook
>  SPARC              Blue Swirl
>  MIPS               ?
> @@ -26,7 +25,7 @@ Machines (sorted by CPU):
>  -
>
>  x86
> -  pc.c                    Fabrice Bellard (new maintainer needed)
> +  pc.c                    Anthony Liguori
>  ARM
>   integratorcp.c          Paul Brook
>   versatilepb.c           Paul Brook
> @@ -70,19 +69,20 @@ S390
>  Generic Subsystems:
>  ---
>
> -Dynamic translator        Fabrice Bellard
> -Main loop                 Fabrice Bellard (new maintainer needed)
> -TCG                       Fabrice Bellard
> -IDE device                ?
> -SCSI device               Paul Brook
> +Main loop                 Anthony Liguori
> +TCG                       ?
> +KVM                       Marcelo Tosatti/Avi Kivity
> +Virtio devices            Anthony Liguori
> +IDE devices               ?
> +SCSI devices              Paul Brook
>  PCI layer                 Michael S. Tsirkin
>  USB layer                 ?
> -Block layer               ?
> -Graphic layer             ?
> +Block layer               Kevin Wolf
> +Graphic layer             Anthony Liguori
>  Audio device layer        Vassili Karpov (malc)
> -Character device layer    ?
> -Network device layer      ?
> +Character device layer    Anthony Liguori
> +Network device layer      Anthony Liguori/Mark McLoughlin
>  GDB stub                  ?
> -Linux user                ?
> -Darwin user               ?
> -SLIRP                     ?
> +Linux user                Riku Voipio

+BSD userBlue Swirl

> +Darwin user               Unmaintained (likely to be removed)
> +SLIRP                     Unmaintained
> --
> 1.7.0.4
>
>
>

Re: [Qemu-devel] [PATCH] Update MAINTAINERS

[Anthony Liguori]

On 09/09/2010 03:12 PM, Stefan Weil wrote:

Am 09.09.2010 21:54, schrieb Anthony Liguori:
The goal of this file is not to establish strict ownership of the 
code base but
rather to provide a place for people to direct questions to and for 
names of

people to CC on patches.


This text should be added to MAINTAINERS.

I'm basing this update on my observations on how things currently 
work today.
If you think your name should be on something and it's not, don't 
read anything

into it and just correct me :-)

Signed-off-by: Anthony Liguori

diff --git a/MAINTAINERS b/MAINTAINERS
index e5165fb..ee84f3f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4,13 +4,12 @@ QEMU Maintainers
  Project leaders:
  

-Fabrice Bellard
  Paul Brook

-CPU cores:
+TCG cores:
  --

-x86Fabrice Bellard
+x86?
  ARMPaul Brook
  SPARC  Blue Swirl
  MIPS   ?
@@ -26,7 +25,7 @@ Machines (sorted by CPU):
  -

  x86
-  pc.cFabrice Bellard (new maintainer needed)
+  pc.cAnthony Liguori
  ARM
integratorcp.c  Paul Brook
versatilepb.c   Paul Brook
@@ -70,19 +69,20 @@ S390
  Generic Subsystems:
  ---

-Dynamic translatorFabrice Bellard
-Main loop Fabrice Bellard (new maintainer needed)
-TCG   Fabrice Bellard
-IDE device?
-SCSI device   Paul Brook
+Main loop Anthony Liguori
+TCG   ?
+KVM   Marcelo Tosatti/Avi Kivity
+Virtio devicesAnthony Liguori
+IDE devices   ?
+SCSI devices  Paul Brook
  PCI layer Michael S. Tsirkin
  USB layer ?
-Block layer   ?
-Graphic layer ?
+Block layer   Kevin Wolf
+Graphic layer Anthony Liguori
  Audio device layerVassili Karpov (malc)
-Character device layer?
-Network device layer  ?
+Character device layerAnthony Liguori
+Network device layer  Anthony Liguori/Mark McLoughlin
  GDB stub  ?
-Linux user?
-Darwin user   ?
-SLIRP ?
+Linux userRiku Voipio
+Darwin user   Unmaintained (likely to be removed)
+SLIRP Unmaintained


Hello Anthony,

I feel responsible for any file with "Copyright (c) 20xx Stefan Weil" 
in the header.


Yeah, I'm thinking of converting to a Linux style maintainers that's 
more conducive to fine-grain info.  Again, my intention is for people 
who are looking to ask for help or patch review for a particular piece 
of code so having more granularity is a good thing.



Maybe a general remark like this would be good:

For individual files, there is usually a copyright owner mentioned in 
the file's header.


It's very often that the original copyright holder is no longer involved 
in the project.  Hence the need for something beyond the copyright 
header in the first place.



In most cases, this person also maintains this file.

(or anything similar)

For people who don't know what "Main loop" (and the other topics) is 
and also
for automated parsing (matching of files to maintainers like it is 
done by the linux kernel)

additional path or filename entries would be helpful in a future version.


Yes, hence the desire to move to a Linux style format.

Regards,

Anthony Liguori



Regards
Stefan

[Qemu-devel] Linux framebuffer emulation in qemu linux-user

[Ilyes Gouta]

Hi,

Is it possible, as of today, to emulate a classic Linux framebuffer when
using qemu linux-user mode?

At a first glance, I saw in the code that
FBIOGET_FSCREENINFO, FBIOGET_VSCREENINFO and FBIOPUT_VSCREENINFO being
declared by couldn't locate where they're handled. Are these hooked to the
SDL back-end?

Thanks,

-Ilyes

Re: [Qemu-devel] [PATCH] Update MAINTAINERS

[Anthony Liguori]

On 09/09/2010 03:12 PM, Blue Swirl wrote:

diff --git a/MAINTAINERS b/MAINTAINERS
index e5165fb..ee84f3f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4,13 +4,12 @@ QEMU Maintainers
  Project leaders:
  

-Fabrice Bellard
  Paul Brook
 

+Anthony Liguori

I think that is how things work today.
   


I don't object to that :-) But I was also considering just removing the 
section or maybe listing "core maintainers" which are the folks that 
have commit access.



-CPU cores:
+TCG cores:
 

That could be read as TCG host support. How about 'Guest CPU cores
(TCG)' with 'Guest CPU cores (KVM)' added later?
   


That makes sense.


  --

-x86Fabrice Bellard
+x86?
  ARMPaul Brook
  SPARC  Blue Swirl
  MIPS   ?
@@ -26,7 +25,7 @@ Machines (sorted by CPU):
  -

  x86
-  pc.cFabrice Bellard (new maintainer needed)
+  pc.cAnthony Liguori
  ARM
   integratorcp.c  Paul Brook
   versatilepb.c   Paul Brook
@@ -70,19 +69,20 @@ S390
  Generic Subsystems:
  ---

-Dynamic translatorFabrice Bellard
-Main loop Fabrice Bellard (new maintainer needed)
-TCG   Fabrice Bellard
-IDE device?
-SCSI device   Paul Brook
+Main loop Anthony Liguori
+TCG   ?
+KVM   Marcelo Tosatti/Avi Kivity
+Virtio devicesAnthony Liguori
+IDE devices   ?
+SCSI devices  Paul Brook
  PCI layer Michael S. Tsirkin
  USB layer ?
-Block layer   ?
-Graphic layer ?
+Block layer   Kevin Wolf
+Graphic layer Anthony Liguori
  Audio device layerVassili Karpov (malc)
-Character device layer?
-Network device layer  ?
+Character device layerAnthony Liguori
+Network device layer  Anthony Liguori/Mark McLoughlin
  GDB stub  ?
-Linux user?
-Darwin user   ?
-SLIRP ?
+Linux userRiku Voipio
 

+BSD userBlue Swirl
   


Indeed.

Regards,

Anthony Liguori


+Darwin user   Unmaintained (likely to be removed)
+SLIRP Unmaintained
--
1.7.0.4



 

Re: [Qemu-devel] CoreAudio warnings (was: [PATCH 4/4] PPC: Change PPC maintainer)

[Andreas Färber]

Am 08.09.2010 um 03:19 schrieb malc:


On Wed, 8 Sep 2010, Alexander Graf wrote:


On 08.09.2010, at 00:48, malc wrote:


On Wed, 8 Sep 2010, Andreas F?rber wrote:

What I don't intend to investigate any time soon is
the chatty CoreAudio code.


What about it?


It throws about 100 warnings when compiled on 10.6 :).


Oh, i thought it was a runtime issue, aslo and given that i don't have
10.6...


For reference here's v10.5/ppc64 audio output (ppc below):

  CCaudio/audio.o
  CCaudio/noaudio.o
  CCaudio/wavaudio.o
  CCaudio/mixeng.o
In file included from /Users/andreas/QEMU/qemu/audio/mixeng.c:112:
/Users/andreas/QEMU/qemu/audio/mixeng_template.h: In function  
‘conv_natural_int32_t’:
/Users/andreas/QEMU/qemu/audio/mixeng_template.h:59: warning: integer  
overflow in expression
/Users/andreas/QEMU/qemu/audio/mixeng_template.h: In function  
‘clip_natural_int32_t’:
/Users/andreas/QEMU/qemu/audio/mixeng_template.h:76: warning: integer  
overflow in expression

In file included from /Users/andreas/QEMU/qemu/audio/mixeng.c:117:
/Users/andreas/QEMU/qemu/audio/mixeng_template.h: In function  
‘conv_swap_int32_t’:
/Users/andreas/QEMU/qemu/audio/mixeng_template.h:59: warning: integer  
overflow in expression
/Users/andreas/QEMU/qemu/audio/mixeng_template.h: In function  
‘clip_swap_int32_t’:
/Users/andreas/QEMU/qemu/audio/mixeng_template.h:76: warning: integer  
overflow in expression

  CCaudio/coreaudio.o
/Users/andreas/QEMU/qemu/audio/coreaudio.c: In function  
‘coreaudio_logstatus’:
/Users/andreas/QEMU/qemu/audio/coreaudio.c:59: warning: initialization  
discards qualifiers from pointer target type
/Users/andreas/QEMU/qemu/audio/coreaudio.c:63: warning: assignment  
discards qualifiers from pointer target type
/Users/andreas/QEMU/qemu/audio/coreaudio.c:67: warning: assignment  
discards qualifiers from pointer target type
/Users/andreas/QEMU/qemu/audio/coreaudio.c:71: warning: assignment  
discards qualifiers from pointer target type
/Users/andreas/QEMU/qemu/audio/coreaudio.c:75: warning: assignment  
discards qualifiers from pointer target type
/Users/andreas/QEMU/qemu/audio/coreaudio.c:79: warning: assignment  
discards qualifiers from pointer target type
/Users/andreas/QEMU/qemu/audio/coreaudio.c:83: warning: assignment  
discards qualifiers from pointer target type
/Users/andreas/QEMU/qemu/audio/coreaudio.c:87: warning: assignment  
discards qualifiers from pointer target type
/Users/andreas/QEMU/qemu/audio/coreaudio.c:91: warning: assignment  
discards qualifiers from pointer target type
/Users/andreas/QEMU/qemu/audio/coreaudio.c:95: warning: assignment  
discards qualifiers from pointer target type
/Users/andreas/QEMU/qemu/audio/coreaudio.c:99: warning: assignment  
discards qualifiers from pointer target type
/Users/andreas/QEMU/qemu/audio/coreaudio.c:103: warning: assignment  
discards qualifiers from pointer target type
/Users/andreas/QEMU/qemu/audio/coreaudio.c:107: warning: format ‘%ld’  
expects type ‘long int’, but argument 3 has type ‘OSStatus’
/Users/andreas/QEMU/qemu/audio/coreaudio.c: In function  
‘coreaudio_init_out’:
/Users/andreas/QEMU/qemu/audio/coreaudio.c:364: warning: format ‘%ld’  
expects type ‘long int’, but argument 4 has type ‘UInt32’
/Users/andreas/QEMU/qemu/audio/coreaudio.c:419: warning:  
‘AudioDeviceAddIOProc’ is deprecated (declared at /System/Library/ 
Frameworks/CoreAudio.framework/Headers/AudioHardware.h:2067)
/Users/andreas/QEMU/qemu/audio/coreaudio.c:431: warning:  
‘AudioDeviceRemoveIOProc’ is deprecated (declared at /System/Library/ 
Frameworks/CoreAudio.framework/Headers/AudioHardware.h:2081)
/Users/andreas/QEMU/qemu/audio/coreaudio.c: In function  
‘coreaudio_fini_out’:
/Users/andreas/QEMU/qemu/audio/coreaudio.c:456: warning:  
‘AudioDeviceRemoveIOProc’ is deprecated (declared at /System/Library/ 
Frameworks/CoreAudio.framework/Headers/AudioHardware.h:2081)

  CCaudio/wavcapture.o

v10.5/ppc:

  CCaudio/audio.o
  CCaudio/noaudio.o
  CCaudio/wavaudio.o
  CCaudio/mixeng.o
In file included from /Users/andreas/QEMU/qemu/audio/mixeng.c:112:
/Users/andreas/QEMU/qemu/audio/mixeng_template.h: In function  
‘conv_natural_int32_t’:
/Users/andreas/QEMU/qemu/audio/mixeng_template.h:59: warning: integer  
overflow in expression
/Users/andreas/QEMU/qemu/audio/mixeng_template.h: In function  
‘clip_natural_int32_t’:
/Users/andreas/QEMU/qemu/audio/mixeng_template.h:76: warning: integer  
overflow in expression

In file included from /Users/andreas/QEMU/qemu/audio/mixeng.c:117:
/Users/andreas/QEMU/qemu/audio/mixeng_template.h: In function  
‘conv_swap_int32_t’:
/Users/andreas/QEMU/qemu/audio/mixeng_template.h:59: warning: integer  
overflow in expression
/Users/andreas/QEMU/qemu/audio/mixeng_template.h: In function  
‘clip_swap_int32_t’:
/Users/andreas/QEMU/qemu/audio/mixeng_template.h:76: warning: integer  
overflow in expression

  CCaudio/coreaudio.o
/Users/andreas/QEMU/qemu/audio/coreaudio.c: In function  
‘coreaudio_logstatus’:
/User

Re: [Qemu-devel] Linux framebuffer emulation in qemu linux-user

[Blue Swirl]

On Thu, Sep 9, 2010 at 8:19 PM, Ilyes Gouta  wrote:
> Hi,
> Is it possible, as of today, to emulate a classic Linux framebuffer when
> using qemu linux-user mode?
> At a first glance, I saw in the code that
> FBIOGET_FSCREENINFO, FBIOGET_VSCREENINFO and FBIOPUT_VSCREENINFO being
> declared by couldn't locate where they're handled. Are these hooked to the
> SDL back-end?

SDL is only used for system emulation. It should be possible to add
conversions (for example, from PPC 32 bit BE to x86_64 64 bit LE) for
FB ioctls in order to pass them to the host FB device. But what would
be the use case for this?

[Qemu-devel] Re: [PATCH] pci: fix pci_resource_alignment prototype

[Jesse Barnes]

On Tue, 7 Sep 2010 17:25:20 -0700
Chris Wright  wrote:

> From: Cam Macdonell 
> 
> * Cam Macdonell (c...@cs.ualberta.ca) wrote:
> > It seems it was the alignment value being passed back from
> > pci_resource_alignment().  The return type is an int, which was
> > causing value of 2GB to be sign extended to to 0x8000.
> > Changing the return type to resource_size_t allows BAR values >= 2GB
> > to be successfully assigned.
> 
> > -static inline int pci_resource_alignment(struct pci_dev *dev,
> > +static inline resource_size_t pci_resource_alignment(struct pci_dev *dev,
> >  struct resource *res)
> 
> Yes, that's my mistake.  Thanks for debugging the issue Cam.
> This fixes the prototype for both pci_resource_alignment() and
> pci_sriov_resource_alignment().
> 
> Patch started as debugging effort from Cam Macdonell.
> 
> Cc: Cam Macdonell 
> Cc: Avi Kivity 
> Cc: Jesse Barnes 
> [chrisw: add iov bits]
> Signed-off-by: Chris Wright 
> ---
>  drivers/pci/iov.c |2 +-
>  drivers/pci/pci.h |5 +++--
>  2 files changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/pci/iov.c b/drivers/pci/iov.c
> index ce6a366..553d8ee 100644
> --- a/drivers/pci/iov.c
> +++ b/drivers/pci/iov.c
> @@ -608,7 +608,7 @@ int pci_iov_resource_bar(struct pci_dev *dev, int resno,
>   * the VF BAR size multiplied by the number of VFs.  The alignment
>   * is just the VF BAR size.
>   */
> -int pci_sriov_resource_alignment(struct pci_dev *dev, int resno)
> +resource_size_t pci_sriov_resource_alignment(struct pci_dev *dev, int resno)
>  {
>   struct resource tmp;
>   enum pci_bar_type type;
> diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
> index 679c39d..5d0aeb1 100644
> --- a/drivers/pci/pci.h
> +++ b/drivers/pci/pci.h
> @@ -262,7 +262,8 @@ extern int pci_iov_init(struct pci_dev *dev);
>  extern void pci_iov_release(struct pci_dev *dev);
>  extern int pci_iov_resource_bar(struct pci_dev *dev, int resno,
>   enum pci_bar_type *type);
> -extern int pci_sriov_resource_alignment(struct pci_dev *dev, int resno);
> +extern resource_size_t pci_sriov_resource_alignment(struct pci_dev *dev,
> + int resno);
>  extern void pci_restore_iov_state(struct pci_dev *dev);
>  extern int pci_iov_bus_range(struct pci_bus *bus);
>  
> @@ -318,7 +319,7 @@ static inline int pci_ats_enabled(struct pci_dev *dev)
>  }
>  #endif /* CONFIG_PCI_IOV */
>  
> -static inline int pci_resource_alignment(struct pci_dev *dev,
> +static inline resource_size_t pci_resource_alignment(struct pci_dev *dev,
>struct resource *res)
>  {
>  #ifdef CONFIG_PCI_IOV
> 
> 

Applied to my for-linus branch, thanks.

-- 
Jesse Barnes, Intel Open Source Technology Center

Re: [Qemu-devel] [RFC] qed: Add QEMU Enhanced Disk format

[Christoph Hellwig]

On Thu, Sep 09, 2010 at 12:43:28PM -0500, Anthony Liguori wrote:
> Define "very large disks".
> 
> My target for VM images is 100GB-1TB.  Practically speaking, that at 
> least covers us for the next 5 years.

We have 2TB SATA disks shipping already, and people tend to produce
more and more "data".  I don't think adding such a limit these days
is a good idea at all.  It's fine to limit the (tested)implementation
to around 100TB for now, but desining a new image format that doesn't
reach into the petabyte range today is extremly short sightened.

> I can only imagine the use case for qcow2-over-lvm is performance.  But 
> the performance of QED on a file system is so much better than qcow2 
> that you can safely just use a file system and avoid the complexity of 
> qcow2 over lvm.

A volume manager has many advantages over an image format.  For one it
allows much larger extent allocation sizes, given you much less
fragmentation.  There's also lots of infrastructure for dealing with it.

Last but not least using clustered lvm is much simpler than a clustered
filesystem.

Re: [Qemu-devel] Re: [RFC] qed: Add QEMU Enhanced Disk format

[Christoph Hellwig]

On Thu, Sep 09, 2010 at 12:02:26PM -0500, Anthony Liguori wrote:
> My position is that we'll need a sparse image format well into the 
> future because while btrfs may be ubiquitous as a file system, IRL, 
> people transfer images around all of the time through dumb transports 
> like HTTP and fat-formatted USB keys.  A 100GB image with 1GB allocated 
> cannot explode to 100GB just because HTTP is a dump transport.
> 
> Where we should do copy-on-read is a different topic.  Really, I should 
> have waited to share that feature to avoid confusing the current discussion.

Yes, we will need an image format forever.  However I'd be a much
happier camper if typical production setups wouldn't use them.

Either way the qed image format is something that too me looks much
better than qcow2, primarily due to the simpliciy.  I haven't managed
to fully review it yet, so I might change my opinion again.

Re: [Qemu-devel] [RFC] qed: Add QEMU Enhanced Disk format

[Christoph Hellwig]

On Thu, Sep 09, 2010 at 09:24:26AM +0300, Avi Kivity wrote:
> The other thing we can do is defragment the logical image, then 
> defragment the underlying file (if the filesystem supports it, issue the 
> appropriate ioctl, otherwise defragment to a new file which you write 
> linearly).

What's what the defragmentation code does in a slightly optimized
fashion anyway - so if you want to do it from qemu just do it that
way.  Don't even bother calling the filesystem ioctls directly given
that they just implementa low-level helpers and the actual logic is
in the userspace side of the defragmentation tools.

Re: [Qemu-devel] [PATCH] elf: Calculate symbol size if needed

[Edgar E. Iglesias]

On Thu, Sep 09, 2010 at 07:36:28PM +, Blue Swirl wrote:
> On Thu, Sep 9, 2010 at 7:34 PM, Stefan Weil  wrote:
> > Am 09.09.2010 21:29, schrieb Blue Swirl:
> >>
> >> On Thu, Sep 9, 2010 at 7:11 PM, Stefan Weil  wrote:
> >>
> >>>
> >>> Am 09.09.2010 20:44, schrieb Blue Swirl:
> >>>
> 
>  On Thu, Sep 9, 2010 at 5:42 PM, Stefan Weil
>   wrote:
> 
> >
> > Am 11.08.2010 18:21, schrieb Blue Swirl:
> >
> >>
> >> On Mon, Aug 9, 2010 at 2:43 PM, Stefan Weil
> >>  wrote:
> >>
> >>
> >>>
> >>> Symbols with a size of 0 are unusable for the disassembler.
> >>>
> >>> Example:
> >>>
> >>> While running an arm linux kernel, no symbolic names are
> >>> used in qemu.log when the cpu is executing an assembler function.
> >>>
> >>>
> >>
> >> That is a problem of the assembler function, it should use '.size'
> >> directive like what happens when C code is compiled. And why just ARM?
> >>
> >>
> >>
> >>>
> >>> Assume that the size of such symbols is the difference to the
> >>> next symbol value.
> >>>
> >>> Signed-off-by: Stefan Weil
> >>> ---
> >>>  hw/elf_ops.h |    5 +
> >>>  1 files changed, 5 insertions(+), 0 deletions(-)
> >>>
> >>> diff --git a/hw/elf_ops.h b/hw/elf_ops.h
> >>> index 27d1ab9..0bd7235 100644
> >>> --- a/hw/elf_ops.h
> >>> +++ b/hw/elf_ops.h
> >>> @@ -153,6 +153,11 @@ static int glue(load_symbols, SZ)(struct elfhdr
> >>> *ehdr, int fd, int must_swab,
> >>>        syms = qemu_realloc(syms, nsyms * sizeof(*syms));
> >>>
> >>>        qsort(syms, nsyms, sizeof(*syms), glue(symcmp, SZ));
> >>> +        for (i = 0; i<    nsyms - 1; i++) {
> >>> +            if (syms[i].st_size == 0) {
> >>> +                syms[i].st_size = syms[i + 1].st_value -
> >>> syms[i].st_value;
> >>> +            }
> >>> +        }
> >>>
> >>>
> >>
> >> The size of the last symbol is not guesstimated, it could be assumed
> >> to be _etext - syms[nsyms].st_value.
> >>
> >>
> >>
> >>>
> >>>    } else {
> >>>        qemu_free(syms);
> >>>        syms = NULL;
> >>> --
> >>> 1.7.1
> >>>
> >>
> >>
> >
> > The patch is still missing in qemu master.
> >  From the two feedbacks I did not read that anything needs to be
> > changed.
> > Was I wrong, or can it be applied?
> >
> 
>  Please fix the last symbol. Either we should fix all symbols or none,
>  half fixed (OK, practically all) is not so great.
> 
> >>>
> >>> The last symbol is one of several thousands, and most symbols don't need
> >>> a
> >>> fix,
> >>> so with my fix more than 99.9 or even 99.99 percent of all symbols are ok
> >>> :-)
> >>> If the last symbol happens to be wrong, there is still a high probability
> >>> that
> >>> nobody will notice this because it is unused by QEMU. The problem I faced
> >>> with
> >>> QEMU's disassembly came from symbols with an address followed by code.
> >>> Is there any code after the last symbol? I don't expect that. In a sorted
> >>> list
> >>> of symbols from the text segment, _etext should be the last symbols!
> >>>
> >>> I think that the small chance of a missing fix for the last symbol is in
> >>> no
> >>> relation
> >>> to the code needed.
> >>>
> >>> Even worse, I have no simple formula to guess a valid value for the last
> >>> symbol.
> >>> The formula you suggested (with the corrections I wrote in my reply) is
> >>> only
> >>> ok
> >>> if the last symbol is in the text segment. Usually there are also symbols
> >>> for data
> >>> in other segments, and in many cases these segments are located after the
> >>> text segment. In these cases the last symbol is not located in the text
> >>> segment
> >>> which makes guesses of its size much more complicated.
> >>>
> >>
> >> How about using _end then?
> >>
> >>
> >
> > Wouldn't _end be the last symbol then?
> 
> Right, _end should be the last one in any case. I'll apply the patch.

I'm not so sure that is the case. The load_symbols call throws away
symbols that are not typed as functions. The filtering is done
prior to the suggested size fixups so my guess is that _end is typically
gone when the suggested size fixup is done.

I'm not opposed to the patch though...

Cheers

Re: [Qemu-devel] Linux framebuffer emulation in qemu linux-user

[Ilyes Gouta]

On Thu, Sep 9, 2010 at 9:39 PM, Ilyes Gouta  wrote:

> Hi,
>
> Well, actually I'd like to run sh4 binaries in linux-user mode, where these
> are actually DirectFB applications which rely on the standard Linux
> framebuffer to display things.
>
> In my use case, I'd like to route these ioctl in qemu to be handled by the
> SDL back-end (or even a DirectFB instance running on the host) instead of
> being dispatched to the native framebuffer driver, running on the host.
>
> Is this feature available in the current qemu code base?
>
> Thanks,
>
> -Ilyes
>
>
> On Thu, Sep 9, 2010 at 9:28 PM, Blue Swirl  wrote:
>
>> On Thu, Sep 9, 2010 at 8:19 PM, Ilyes Gouta 
>> wrote:
>> > Hi,
>> > Is it possible, as of today, to emulate a classic Linux framebuffer when
>> > using qemu linux-user mode?
>> > At a first glance, I saw in the code that
>> > FBIOGET_FSCREENINFO, FBIOGET_VSCREENINFO and FBIOPUT_VSCREENINFO being
>> > declared by couldn't locate where they're handled. Are these hooked to
>> the
>> > SDL back-end?
>>
>> SDL is only used for system emulation. It should be possible to add
>> conversions (for example, from PPC 32 bit BE to x86_64 64 bit LE) for
>> FB ioctls in order to pass them to the host FB device. But what would
>> be the use case for this?
>>
>
>

Re: [Qemu-devel] CoreAudio warnings (was: [PATCH 4/4] PPC: Change PPC maintainer)

[malc]

On Thu, 9 Sep 2010, Andreas F?rber wrote:

> Am 08.09.2010 um 03:19 schrieb malc:
> 
> > On Wed, 8 Sep 2010, Alexander Graf wrote:
> > 
> > > On 08.09.2010, at 00:48, malc wrote:
> > > 
> > > > On Wed, 8 Sep 2010, Andreas F?rber wrote:
> > > > > What I don't intend to investigate any time soon is
> > > > > the chatty CoreAudio code.
> > > > 
> > > > What about it?
> > > 
> > > It throws about 100 warnings when compiled on 10.6 :).
> > 
> > Oh, i thought it was a runtime issue, aslo and given that i don't have
> > 10.6...
> 
> For reference here's v10.5/ppc64 audio output (ppc below):
> 

[..snip..]

Thanks. Though most of those warnings are either bogus or require access
to the 10.5/6 system to fix.

-- 
mailto:av1...@comtv.ru

Re: [Qemu-devel] Linux framebuffer emulation in qemu linux-user

[Ilyes Gouta]

Hi,

> No, but it could be possible to convert the DirectFB ioctl structures
> between guest and host. Other ioctls are translated this way. I guess
> nobody has cared about framebuffer support yet.

DirectFB (on the sh4 side) is just a client which is interacting with the
framebuffer. It doesn't have its "own" set of ioctls.

Is handling FBIOGET_FSCREENINFO, FBIOGET_VSCREENINFO and FBIOPUT_VSCREENINFO
enough to abstract a basic Linux framebuffer and emulate it (by not
forwarding these to a native framebuffer)?

-Ilyes

On Thu, Sep 9, 2010 at 9:57 PM, Blue Swirl  wrote:

> On Thu, Sep 9, 2010 at 8:39 PM, Ilyes Gouta  wrote:
> > Hi,
> > Well, actually I'd like to run sh4 binaries in linux-user mode, where
> these
> > are actually DirectFB applications which rely on the standard Linux
> > framebuffer to display things.
> > In my use case, I'd like to route these ioctl in qemu to be handled by
> the
> > SDL back-end (or even a DirectFB instance running on the host) instead of
> > being dispatched to the native framebuffer driver, running on the host.
> > Is this feature available in the current qemu code base?
>
> No, but it could be possible to convert the DirectFB ioctl structures
> between guest and host. Other ioctls are translated this way. I guess
> nobody has cared about framebuffer support yet.
>
> See linux-user/ioctls.h.
>
> > Thanks,
> > -Ilyes
> >
> > On Thu, Sep 9, 2010 at 9:28 PM, Blue Swirl  wrote:
> >>
> >> On Thu, Sep 9, 2010 at 8:19 PM, Ilyes Gouta 
> wrote:
> >> > Hi,
> >> > Is it possible, as of today, to emulate a classic Linux framebuffer
> when
> >> > using qemu linux-user mode?
> >> > At a first glance, I saw in the code that
> >> > FBIOGET_FSCREENINFO, FBIOGET_VSCREENINFO and FBIOPUT_VSCREENINFO being
> >> > declared by couldn't locate where they're handled. Are these hooked to
> >> > the
> >> > SDL back-end?
> >>
> >> SDL is only used for system emulation. It should be possible to add
> >> conversions (for example, from PPC 32 bit BE to x86_64 64 bit LE) for
> >> FB ioctls in order to pass them to the host FB device. But what would
> >> be the use case for this?
> >
> >
>

Re: [Qemu-devel] Linux framebuffer emulation in qemu linux-user

[Alexander Graf]

On 09.09.2010, at 23:06, Ilyes Gouta wrote:

> 
> 
> On Thu, Sep 9, 2010 at 9:39 PM, Ilyes Gouta  wrote:
> Hi,
> 
> Well, actually I'd like to run sh4 binaries in linux-user mode, where these 
> are actually DirectFB applications which rely on the standard Linux 
> framebuffer to display things.
> 
> In my use case, I'd like to route these ioctl in qemu to be handled by the 
> SDL back-end (or even a DirectFB instance running on the host) instead of 
> being dispatched to the native framebuffer driver, running on the host.
> 
> Is this feature available in the current qemu code base?

Please don't top post.

It is not available in qemu and doesn't belong there. Qemu's linux-user target 
really only passes things through. It shouldn't intercept them and try to be 
clever. That's the task of the surrounding stack.

For example in your case, I'd write an LD_PRELOAD that would trap open on 
/dev/fb* and emulates mmap and ioctls to that device. This way you get a 
generic way of displaying fb contents in windows that might be useful for other 
use cases too.

Another thing you could look into is cuse. Maybe you could expose /dev/fb0 as a 
cuse device and trap things through that.


Alex

Re: [Qemu-devel] Linux framebuffer emulation in qemu linux-user

[Ilyes Gouta]

On Thu, Sep 9, 2010 at 11:57 PM, Alexander Graf  wrote:

>
> On 09.09.2010, at 23:06, Ilyes Gouta wrote:
>
> >
> >
> > On Thu, Sep 9, 2010 at 9:39 PM, Ilyes Gouta 
> wrote:
> > Hi,
> >
> > Well, actually I'd like to run sh4 binaries in linux-user mode, where
> these are actually DirectFB applications which rely on the standard Linux
> framebuffer to display things.
> >
> > In my use case, I'd like to route these ioctl in qemu to be handled by
> the SDL back-end (or even a DirectFB instance running on the host) instead
> of being dispatched to the native framebuffer driver, running on the host.
> >
> > Is this feature available in the current qemu code base?
>
> Please don't top post.
>
> It is not available in qemu and doesn't belong there. Qemu's linux-user
> target really only passes things through. It shouldn't intercept them and
> try to be clever. That's the task of the surrounding stack.
>
> For example in your case, I'd write an LD_PRELOAD that would trap open on
> /dev/fb* and emulates mmap and ioctls to that device. This way you get a
> generic way of displaying fb contents in windows that might be useful for
> other use cases too.
>
> Another thing you could look into is cuse. Maybe you could expose /dev/fb0
> as a cuse device and trap things through that.


Indeed, it sounds a lot more generic. I already started hacking into qemu to
implement (prototype) rerouting the framebuffer ioctls, and it's
surprisingly easy :) If cuse's learning curve isn't stiff, I'll consider
moving my changes into a separate shared library.

Thanks Alex,

-Ilyes






> Alex
>
>

[Qemu-devel] [PATCH] Copy snapshots out of QCOW2 disk

[disheng . su]

From: edison 

In order to backup snapshots, created from QCOW2 iamge, we want to copy 
snapshots out of QCOW2 disk to a seperate storage.
The following patch adds a new option in "qemu-img": qemu-img convert -f qcow2 
-O qcow2 -s snapshot_name src_img bck_img.
Right now, it only supports to copy the full snapshot, delta snapshot is on the 
way.

Signed-off-by: Disheng Su 
---
 block.c|   11 +++
 block.h|2 ++
 block/qcow2-snapshot.c |   26 ++
 block/qcow2.c  |1 +
 block/qcow2.h  |1 +
 block_int.h|2 ++
 qemu-img-cmds.hx   |4 ++--
 qemu-img.c |   19 ++-
 8 files changed, 63 insertions(+), 3 deletions(-)

diff --git a/block.c b/block.c
index ebbc376..eaf78f6 100644
--- a/block.c
+++ b/block.c
@@ -1899,6 +1899,17 @@ int bdrv_snapshot_list(BlockDriverState *bs,
 return -ENOTSUP;
 }
 
+int bdrv_snapshot_load(BlockDriverState *bs,
+  const char *snapshot_name)
+{
+BlockDriver *drv = bs->drv;
+if (!drv)
+return -ENOMEDIUM;
+if (drv->bdrv_snapshot_load)
+   return drv->bdrv_snapshot_load(bs, snapshot_name);
+return -ENOTSUP;
+}
+
 #define NB_SUFFIXES 4
 
 char *get_human_readable_size(char *buf, int buf_size, int64_t size)
diff --git a/block.h b/block.h
index 5f64380..9ec6219 100644
--- a/block.h
+++ b/block.h
@@ -211,6 +211,8 @@ int bdrv_snapshot_goto(BlockDriverState *bs,
 int bdrv_snapshot_delete(BlockDriverState *bs, const char *snapshot_id);
 int bdrv_snapshot_list(BlockDriverState *bs,
QEMUSnapshotInfo **psn_info);
+int bdrv_snapshot_load(BlockDriverState *bs,
+   const char *snapshot_name);
 char *bdrv_snapshot_dump(char *buf, int buf_size, QEMUSnapshotInfo *sn);
 
 char *get_human_readable_size(char *buf, int buf_size, int64_t size);
diff --git a/block/qcow2-snapshot.c b/block/qcow2-snapshot.c
index 6228612..e663e8b 100644
--- a/block/qcow2-snapshot.c
+++ b/block/qcow2-snapshot.c
@@ -416,3 +416,29 @@ int qcow2_snapshot_list(BlockDriverState *bs, 
QEMUSnapshotInfo **psn_tab)
 return s->nb_snapshots;
 }
 
+int qcow2_snapshot_load(BlockDriverState *bs, const char *snapshot_name) {
+int i, snapshot_index, l1_size2;
+BDRVQcowState *s = bs->opaque;
+QCowSnapshot *sn;
+snapshot_index = find_snapshot_by_id_or_name(bs, snapshot_name);
+if (snapshot_index < 0)
+return -ENOENT;
+sn = &s->snapshots[snapshot_index];
+s->l1_size = sn->l1_size;
+l1_size2 = s->l1_size * sizeof(uint64_t);
+if (s->l1_table != NULL) {
+   qemu_free(s->l1_table);
+}
+s->l1_table_offset = sn->l1_table_offset;
+s->l1_table = qemu_mallocz(
+align_offset(l1_size2, 512));
+/* copy the snapshot l1 table to the current l1 table */
+if (bdrv_pread(bs->file, sn->l1_table_offset,
+   s->l1_table, l1_size2) != l1_size2) {
+return -1;
+}
+for(i = 0;i < s->l1_size; i++) {
+be64_to_cpus(&s->l1_table[i]);
+}
+return 0;
+}
diff --git a/block/qcow2.c b/block/qcow2.c
index a53014d..da98a01 100644
--- a/block/qcow2.c
+++ b/block/qcow2.c
@@ -1352,6 +1352,7 @@ static BlockDriver bdrv_qcow2 = {
 .bdrv_snapshot_goto = qcow2_snapshot_goto,
 .bdrv_snapshot_delete   = qcow2_snapshot_delete,
 .bdrv_snapshot_list = qcow2_snapshot_list,
+.bdrv_snapshot_load = qcow2_snapshot_load,
 .bdrv_get_info = qcow_get_info,
 
 .bdrv_save_vmstate= qcow_save_vmstate,
diff --git a/block/qcow2.h b/block/qcow2.h
index 3ff162e..cbbba48 100644
--- a/block/qcow2.h
+++ b/block/qcow2.h
@@ -211,6 +211,7 @@ int qcow2_snapshot_create(BlockDriverState *bs, 
QEMUSnapshotInfo *sn_info);
 int qcow2_snapshot_goto(BlockDriverState *bs, const char *snapshot_id);
 int qcow2_snapshot_delete(BlockDriverState *bs, const char *snapshot_id);
 int qcow2_snapshot_list(BlockDriverState *bs, QEMUSnapshotInfo **psn_tab);
+int qcow2_snapshot_load(BlockDriverState *bs, const char *snapshot_name);
 
 void qcow2_free_snapshots(BlockDriverState *bs);
 int qcow2_read_snapshots(BlockDriverState *bs);
diff --git a/block_int.h b/block_int.h
index e8e7156..93d5a1b 100644
--- a/block_int.h
+++ b/block_int.h
@@ -93,6 +93,8 @@ struct BlockDriver {
 int (*bdrv_snapshot_delete)(BlockDriverState *bs, const char *snapshot_id);
 int (*bdrv_snapshot_list)(BlockDriverState *bs,
   QEMUSnapshotInfo **psn_info);
+int (*bdrv_snapshot_load)(BlockDriverState *bs,
+  const char *snapshot_name);
 int (*bdrv_get_info)(BlockDriverState *bs, BlockDriverInfo *bdi);
 
 int (*bdrv_save_vmstate)(BlockDriverState *bs, const uint8_t *buf,
diff --git a/qemu-img-cmds.hx b/qemu-img-cmds.hx
index 6d3e5f8..6c7176f 100644
--- a/qemu-img-cmds.hx
+++ b/qemu-img-cmds.hx
@@ -28,9 +28,9 @@ STEXI
 ETEXI
 
 DEF("convert", img_convert,
-"convert [-c] [-f fmt] [-O output_fmt] [

[Qemu-devel] Re: virtio-9p error

[Venkateswararao Jujjuri (JV)]

On 9/7/2010 9:41 AM, Venkateswararao Jujjuri (JV) wrote:

Bruno Cesar Ribas wrote:

On Thu, Aug 26, 2010 at 09:44:32AM -0700, Venkateswararao Jujjuri (JV) wrote:

Bruno Cesar Ribas wrote:

Hi,


[snip]
This quick test is with QEMU patches that are on mailing lists but not merged
into mainline.
Being said that, I don't think they really affect this.


is there any work to bring these patches to mainline?

There's no imprevement on virtio-9p in qemu since my first email.


I sent a new revision on Thursday. I am expecting that they will go in anytime.

Last time I talked to Anthony, he is planning on taking these patches soon.


Hello, now the patches are on the mainline tree. Please try them out.

Thanks,
JV



Thanks,
JV




[snip]





--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Qemu-devel] Unknown command 0xffffff in SVGA command FIFO

[andrzej zaborowski]

Hi,

On 16 August 2010 22:26, Janne Huttunen  wrote:
> Yes, your version works (both on paper and in practice). I'm not
> quite sure I like the way it breaches the apparent abstraction
> of the FIFO handling routines (if you can call it that) or the
> way it first gives FIFO slots back to the guest but then rewinds
> them back. Not that either of those concerns necessarily matter
> much.

Since the incomplete commands are expected to be very rare compared to
normal handling, I think the rewinding makes more sense logically.  We
also save some cycles this way.

>
> BTW, now that I look at it, if either HW_FILL_ACCEL or HW_RECT_ACCEL
> is not set 'badcmd' will be called, but args won't be set (as far
> as I can see). Isn't that wrong? Although I think the bug was there
> even before your changes.

Yeah, you're right.  I added the missing args = 0; for those two cases
and pushed the change.

Cheers

[Qemu-devel] [PATCH] [RFC] savevm only saves disk state

[disheng . su]

From: edison 

Add a new option when "savevm": savevm -n snapshotName, which only takes 
snapshot on disk, but doesn't save vm state(memory,cpu,devices...).
Saving vm state on QCOW2 disk will take a long time, per my test, it will take 
1~2 minutes to "savevm" on VM with 1G memory. Even worse, the VM is wholely 
stopped at that time, makes "savevm" not that useful.
All we know the side effect of it:) but does it make sense to give user the 
choice?
---
 qemu-monitor.hx |6 +++---
 savevm.c|   34 ++
 2 files changed, 25 insertions(+), 15 deletions(-)

diff --git a/qemu-monitor.hx b/qemu-monitor.hx
index 49bcd8d..724e0a2 100644
--- a/qemu-monitor.hx
+++ b/qemu-monitor.hx
@@ -327,9 +327,9 @@ ETEXI
 
 {
 .name   = "savevm",
-.args_type  = "name:s?",
-.params = "[tag|id]",
-.help   = "save a VM snapshot. If no tag or id are provided, a new 
snapshot is created",
+.args_type  = "nostate:-n,name:s?",
+.params = "[-n] [tag|id]",
+.help   = "save a VM snapshot. If no tag or id are provided, a new 
snapshot is created. If -n is specified, do not save vm state",
 .mhandler.cmd = do_savevm,
 },
 
diff --git a/savevm.c b/savevm.c
index 6fa7a5f..b0963b5 100644
--- a/savevm.c
+++ b/savevm.c
@@ -1834,7 +1834,8 @@ void do_savevm(Monitor *mon, const QDict *qdict)
 int ret;
 QEMUFile *f;
 int saved_vm_running;
-uint32_t vm_state_size;
+uint32_t vm_state_size = 0;
+
 #ifdef _WIN32
 struct _timeb tb;
 struct tm *ptm;
@@ -1844,6 +1845,8 @@ void do_savevm(Monitor *mon, const QDict *qdict)
 #endif
 const char *name = qdict_get_try_str(qdict, "name");
 
+int nostate = qdict_get_try_bool(qdict, "nostate", 0);
+
 /* Verify if there is a device that doesn't support snapshots and is 
writable */
 bs = NULL;
 while ((bs = bdrv_next(bs))) {
@@ -1909,17 +1912,19 @@ void do_savevm(Monitor *mon, const QDict *qdict)
 }
 
 /* save the VM state */
-f = qemu_fopen_bdrv(bs, 1);
-if (!f) {
-monitor_printf(mon, "Could not open VM state file\n");
-goto the_end;
-}
-ret = qemu_savevm_state(mon, f);
-vm_state_size = qemu_ftell(f);
-qemu_fclose(f);
-if (ret < 0) {
-monitor_printf(mon, "Error %d while writing VM\n", ret);
-goto the_end;
+if (!nostate) {
+f = qemu_fopen_bdrv(bs, 1);
+if (!f) {
+monitor_printf(mon, "Could not open VM state file\n");
+goto the_end;
+}
+ret = qemu_savevm_state(mon, f);
+vm_state_size = qemu_ftell(f);
+qemu_fclose(f);
+if (ret < 0) {
+monitor_printf(mon, "Error %d while writing VM\n", ret);
+goto the_end;
+}
 }
 
 /* create the snapshots */
@@ -1984,6 +1989,11 @@ int load_vmstate(const char *name)
bdrv_get_device_name(bs), name);
 return ret;
 }
+
+if (sn.vm_state_size == 0) {
+error_report("No vm state stored on snapshot: '%s'.", name);
+return -ENOTSUP;
+}
 }
 
 /* Flush all IO requests so they don't interfere with the new state.  */
-- 
1.7.2.2

Re: [Qemu-devel] [PATCH] [RFC] savevm only saves disk state

[Anthony Liguori]

On 09/09/2010 08:43 PM, disheng...@gmail.com wrote:

From: edison

Add a new option when "savevm": savevm -n snapshotName, which only takes 
snapshot on disk, but doesn't save vm state(memory,cpu,devices...).
Saving vm state on QCOW2 disk will take a long time, per my test, it will take 1~2 minutes to 
"savevm" on VM with 1G memory. Even worse, the VM is wholely stopped at that time, makes 
"savevm" not that useful.
All we know the side effect of it:) but does it make sense to give user the 
choice?
   


I think it would be better to explore ways to make savevm live.  A round 
about option would be to combine a disk-only snapshot with a live 
migration to disk and somehow allow qcow2 to refer to an external memory 
snapshot.


A better alternative would be a live snapshot within qcow2.  I think 
Kevin has some good ideas about how to do this with qcow2 today but 
provided we had a nice interface to do this, the changes to the live 
migration code should be fairly straight forward.


Regards,

Anthony Liguori

Re: [Qemu-devel] Template for developing a Qemu device with?PCIe?and MSI-X

[Isaku Yamahata]

http://www.seabios.org/pipermail/seabios/2010-July/000796.html

I haven't found my time to respin to check PMM stuff yet.
If you give it a try, it would be appreciated.

thanks,

On Thu, Sep 09, 2010 at 02:07:13PM -0500, Adnan Khaleel wrote:
> Can you point me to this patch? I found one for BAR overflow checking that you
> wrote which isn't merged with the seabios git source I downloaded from you. 
> I'm
> assuming this is not the one you're talking about correct?
> 
> 
> ━
> From: Isaku Yamahata [mailto:yamah...@valinux.co.jp]
> To: Adnan Khaleel [mailto:ad...@khaleel.us]
> Cc: Cam Macdonell [mailto:c...@cs.ualberta.ca], qemu-devel@nongnu.org
> Sent: Thu, 02 Sep 2010 21:20:12 -0500
> Subject: Re: [Qemu-devel] Template for developing a Qemu device with PCIe?
> and MSI-X
> 
> On Thu, Sep 02, 2010 at 12:42:42PM -0500, Adnan Khaleel wrote:
> > I've tried everything you mentioned and I still get the same problem. 
> The
> only
> > thing that seems to avoid that issue is if I reduce the aperture size
> from
> > 0x20ull to 0x200ull.
> 
> I suppose that Cam is seeing the same issue.
> 
> Right now seabios can't handle too huge BAR due
> to overflow.
> There is a rejected patch floating around,
> but I haven't created a revised patch yet.
> 
> >
> > Here is the relevant section of code:
> >
> > static const unsigned long long BAR_Regions[6][2] =
> > {
> > // len , type
> > { 0x200ull, PCI_BASE_ADDRESS_SPACE_MEMORY |
> > PCI_BASE_ADDRESS_MEM_TYPE_64} , //BAR0,
> > { 0, 0} , // BAR1
> > { 0x200ull, PCI_BASE_ADDRESS_SPACE_IO } , //BAR2,
> > { 0, 0} , // BAR3 for MSI-X
> > { 0, 0} , // BAR4
> > { 0, 0} , // BAR5
> > };
> >
> > static int pcie_msix_initfn(PCIDevice *pci_dev)
> > {
> > PCIE_MSIX_DEVState *d = DO_UPCAST(PCIE_MSIX_DEVState, dev, pci_dev);
> > PCIBridge *br = DO_UPCAST(PCIBridge, dev, pci_dev);
> > PCIEPort *p = DO_UPCAST(PCIEPort, br, br);
> > int rc, i;
> >
> > PRINT_DEBUG("%s: PCIE MSIX Device init...\n", __FUNCTION__);
> >
> > pci_config_set_vendor_id(d->dev.config, PCIE_MSIX_VID);
> > pci_config_set_device_id(d->dev.config, PCIE_MSIX_DID);
> >
> > memcpy(d->dev.config, g_cfg_init, sizeof(g_cfg_init[0x20]));
> > d->mmio_index = cpu_register_io_memory(pcie_msix_mem_read_fn,
> > pcie_msix_mem_write_fn, d);
> >
> > int msix_mem_bar = 0; // Since its a 64bit BAR, we take up BAR0 & BAR1
> > int msix_io_bar = 2;
> > int msix_mmio_bar = 3;
> >
> > pci_register_bar(&d->dev, msix_mem_bar, BAR_Regions[msix_mem_bar][0],
> > BAR_Regions[msix_mem_bar][1], pcie_msix_mem_map);
> > pci_register_bar(&d->dev, msix_io_bar, BAR_Regions[msix_io_bar][0],
> > BAR_Regions[msix_io_bar][1], pcie_msix_io_map);
> >
> > rc = msix_init(&d->dev, d->vectors, msix_mmio_bar, 0);
> >
> > if (!rc) {
> > PRINT_DEBUG("%s: Registering Bar %i as I/O BAR\n", __FUNCTION__,
> > msix_mmio_bar);
> > pci_register_bar(&d->dev, msix_mmio_bar, msix_bar_size(&d->dev),
> > PCI_BASE_ADDRESS_SPACE_MEMORY, msix_mmio_map);
> > PRINT_DEBUG("%s: MSI-X initialized (%d vectors)\n", __FUNCTION__, d->
> > vectors);
> > }
> > else {
> > PRINT_DEBUG("%s: MSI-X initialization failed!\n", __FUNCTION__);
> > return rc;
> > }
> >
> > // Activate the vectors
> > for (i = 0; i < d->vectors; i++) {
> > msix_vector_use(&d->dev, i);
> > }
> >
> > rc = pci_pcie_cap_init(&d->dev, PCIE_MSIX_EXP_OFFSET,
> > PCI_EXP_TYPE_ENDPOINT, p->port);
> > if (rc < 0) {
> > return rc;
> > }
> >
> > pcie_cap_flr_init(&d->dev, &pcie_msix_flr);
> > pcie_cap_deverr_init(&d->dev);
> > pcie_cap_ari_init(&d->dev);
> > rc = pcie_aer_init(&d->dev, PCIE_MSIX_AER_OFFSET);
> > if (rc < 0) {
> > return rc;
> > }
> >
> > PRINT_DEBUG("%s: Init done\n", __FUNCTION__);
> > return 0;
> > }
> >
> > Another question I have is why doesn't the device show up when I try a
> cat /
> > proc/interrupts.
> >
> > linux-an84:~/AriesKernelModules/gni/aries/ghal # cat /proc/interrupts
> > CPU0
> > 0: 694 IO-APIC-edge timer
> > 1: 6 IO-APIC-edge i8042
> > 4: 753 IO-APIC-edge serial
> > 8: 1 IO-APIC-edge rtc0
> > 9: 0 IO-APIC-fasteoi acpi
> > 12: 89 IO-APIC-edge i8042
> > 14: 3522 IO-APIC-edge ata_piix
> > 15: 785 IO-APIC-edge ata_piix
> > 16: 162 IO-APIC-fasteoi eth0
> > 4344: 0 PCI-MSI-edge aerdrv
> > 4345: 0 PCI-MSI-edge aerdrv
> > 4346: 0 PCI-MSI-edge aerdrv
> > 4347: 0 PCI-MSI-edge aerdrv
> > 4348: 0 PCI-MSI-edge aerdrv
> > 4349: 0 PCI-MSI-edge aerdrv
> > 4350: 0 PCI-MSI-edge aerdrv
> > 4351: 0 PCI-MSI-edge aerdrv
> > NMI: 0 Non-maskable interrupts
> > LOC: 107095 Local timer interrupts

[Qemu-devel] [PATCH] Use a Linux-style MAINTAINERS file

[Anthony Liguori]

I make no claims that this is accurate or exhaustive but I think it's a
reasonable place to start.

As the file mentions, the purpose of this file is to give contributors
information about who they can go to with questions about a particular piece of
code or who they can ask for review.

If you sign up for a piece of code and indicate that it's Maintained or
Supported, please be prepared to be responsive to questions about that
subsystem.

Signed-off-by: Anthony Liguori 

diff --git a/MAINTAINERS b/MAINTAINERS
index 79dfc7f..3894cd8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9,89 +9,388 @@ to be CC'd when submitting a patch to obtain appropriate 
review.
 In general, if you have a question about inclusion of a patch, you should
 consult qemu-devel and not any specific individual privately.
 
-Project leaders:
-
+Please see the MAINTAINERS file in the Linux kernel for information about how
+to update this file.
 
-Paul Brook
-Anthony Liguori
+General Project Administration
+--
+M: Anthony Liguori 
+M: Paul Brook 
 
 Guest CPU cores (TCG):
 --
-
-x86?
-ARMPaul Brook
-SPARC  Blue Swirl
-MIPS   ?
-PowerPCAlexander Graf
-M68K   Paul Brook
-SH4?
-CRIS   Edgar E. Iglesias
-Alpha  ?
-MicroBlaze Edgar E. Iglesias
-S390   ?
-
-Machines (sorted by CPU):
--
-
 x86
-  pc.cAnthony Liguori
+M: qemu-devel@nongnu.org
+S: Odd Fixes
+F: target-i386/
+
 ARM
-  integratorcp.c  Paul Brook
-  versatilepb.c   Paul Brook
-  Real View   Paul Brook
-  spitz.c Andrzej Zaborowski
-  palm.c  Andrzej Zaborowski
-  nseries.c   Andrzej Zaborowski
-  stellaris.c Paul Brook
-  gumstix.c   Thorsten Zitterell
-  mainstone.c Armin Kuster
-  musicpal.c  Jan Kiszka
+M: Paul Brook 
+S: Maintained
+F: target-arm/
+
 SPARC
-  sun4u.c Blue Swirl
-  sun4m.c Blue Swirl
+M: Blue Swirl 
+S: Maintained
+F: target-sparc/
+
 MIPS
-  mips_r4k.c  Aurelien Jarno
-  mips_malta.cAurelien Jarno
-  mips_jazz.c Hervé Poussineau
-  mips_mipssim.c  ?
+M: qemu-devel@nongnu.org
+S: Orphan
+F: target-mips/
+
 PowerPC
-  ppc_prep.c  ?
-  ppc_oldworld.c  Alexander Graf
-  ppc_newworld.c  Alexander Graf
-  ppc405_boards.c Alexander Graf
-M86K
-  mcf5208.c   Paul Brook
-  an5206.cPaul Brook
-  dummy_m68k.cPaul Brook
+M: Alexander Graf 
+S: Maintained
+F: target-ppc/
+
+M68K
+M: Paul Brook 
+S: Maintained
+F: target-m68k/
+
 SH4
-  shix.c  ?
-  r2d.c   Magnus Damm
+M: qemu-devel@nongnu.org
+S: Orphan
+F: target-sh4/
+
 CRIS
-  etraxfs.c   Edgar E. Iglesias
-  axis_dev88.cEdgar E. Iglesias
+M: Edgar E. Iglesias 
+S: Maintained
+F: target-cris/
+
 Alpha
+M: qemu-devel@nongnu.org
+S: Orphan
+F: target-alpha/
+
 MicroBlaze
-  petalogix_s3adsp1800.c  Edgar E. Iglesias
+M: Edgar E. Iglesias 
+S: Maintained
+F: target-microblaze/
+
+S390
+M: Alexander Graf 
+S: Maintained
+F: target-s390x/
+
+Guest CPU Cores (KVM):
+--
+
+Overall
+M: Avi Kivity 
+M: Marcelo Tosatti 
+L: k...@vger.kernel.org
+S: Supported
+F: kvm-*
+F: */kvm.*
+
+X86
+M: Avi Kivity 
+M: Marcelo Tosatti 
+L: k...@vger.kernel.org
+S: Supported
+F: target-i386/kvm.c
+
+PPC
+M: Alexander Graf 
+S: Maintained
+F: target-ppc/kvm.c
+
 S390
-  s390-*.cAlexander Graf
+M: Alexander Graf 
+S: Maintained
+F: target-s390x/kvm.c
+
+X86 Machines
+
+
+PC
+M: Anthony Liguori 
+S: Supported
+F: hw/pc.[ch] hw/pc_piix.c
+
+
+ARM Machines
+
+M: Paul Brook 
+S: Maintained
+F: hw/integratorcp.c
+
+Versatile PB
+M: Paul Brook 
+S: Maintained
+F: hw/versatilepb.c
+
+Real View
+M: Paul Brook 
+S: Maintained
+F: hw/realview*
+
+Spitz
+M: Andrzej Zaborowski 
+S: Maintained
+F: hw/spitz.c
+
+Palm
+M: Andrzej Zaborowski 
+S: Maintained
+F: hw/palm.c
+
+nSeries
+M: Andrzej Zaborowski 
+S: Maintained
+F: hw/nseries.c
+
+Stellaris
+M: Paul Brook 
+S: Maintained
+F: hw/stellaris.c
+
+Gumstix
+M: qemu-devel@nongnu.org
+S: Orphan
+F: hw/gumstix.c
+
+Mainstone
+M: qemu-devel@nongnu.org
+S: Orphan
+F: hw/mainstone.c
+
+Musicpal
+M: Jan Kiszka 
+S: Maintained
+F: hw/musicpal.c
+
+SPARC Machines
+--
+Sun4u
+M: Blue Swirl 
+S: Maintained
+F: hw/sun4u.c
+
+Sun4m
+M: Blue Swirl 
+S: Maintained
+F: hw/sun4m.c
+
+MIPS Machines
+-
+R4000
+M: Aurelien Jarno 
+S: Maintained
+F: hw/mips_r4k.c
+
+Malta
+M: Aurelien Jarno 
+S: Maintained
+F: hw/mips_malta.c
+
+Jazz
+M: Hervé Poussineau 
+S: Maintained
+F: hw/mips_jazz.c
+
+Mipssim
+M: qemu-devel@nongnu.org
+S: Orphan
+F: hw/mips_mipssim.c
 
-Generic Subsystems:

[Qemu-devel] Re: [PATCH] Use a Linux-style MAINTAINERS file

[Edgar E. Iglesias]

On Thu, Sep 09, 2010 at 04:18:37PM -0500, Anthony Liguori wrote:
> I make no claims that this is accurate or exhaustive but I think it's a
> reasonable place to start.
> 
> As the file mentions, the purpose of this file is to give contributors
> information about who they can go to with questions about a particular piece 
> of
> code or who they can ask for review.
> 
> If you sign up for a piece of code and indicate that it's Maintained or
> Supported, please be prepared to be responsive to questions about that
> subsystem.
> 
> Signed-off-by: Anthony Liguori 
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 79dfc7f..3894cd8 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -9,89 +9,388 @@ to be CC'd when submitting a patch to obtain appropriate 
> review.
>  In general, if you have a question about inclusion of a patch, you should
>  consult qemu-devel and not any specific individual privately.
>  
> -Project leaders:
> -
> +Please see the MAINTAINERS file in the Linux kernel for information about how
> +to update this file.
>  
> -Paul Brook
> -Anthony Liguori
> +General Project Administration
> +--
> +M: Anthony Liguori 
> +M: Paul Brook 
>  
>  Guest CPU cores (TCG):
>  --
> -
> -x86?
> -ARMPaul Brook
> -SPARC  Blue Swirl
> -MIPS   ?
> -PowerPCAlexander Graf
> -M68K   Paul Brook
> -SH4?
> -CRIS   Edgar E. Iglesias
> -Alpha  ?
> -MicroBlaze Edgar E. Iglesias
> -S390   ?
> -
> -Machines (sorted by CPU):
> --
> -
>  x86
> -  pc.cAnthony Liguori
> +M: qemu-devel@nongnu.org
> +S: Odd Fixes
> +F: target-i386/
> +
>  ARM
> -  integratorcp.c  Paul Brook
> -  versatilepb.c   Paul Brook
> -  Real View   Paul Brook
> -  spitz.c Andrzej Zaborowski
> -  palm.c  Andrzej Zaborowski
> -  nseries.c   Andrzej Zaborowski
> -  stellaris.c Paul Brook
> -  gumstix.c   Thorsten Zitterell
> -  mainstone.c Armin Kuster
> -  musicpal.c  Jan Kiszka
> +M: Paul Brook 
> +S: Maintained
> +F: target-arm/
> +
>  SPARC
> -  sun4u.c Blue Swirl
> -  sun4m.c Blue Swirl
> +M: Blue Swirl 
> +S: Maintained
> +F: target-sparc/
> +
>  MIPS
> -  mips_r4k.c  Aurelien Jarno
> -  mips_malta.cAurelien Jarno
> -  mips_jazz.c Hervé Poussineau
> -  mips_mipssim.c  ?
> +M: qemu-devel@nongnu.org
> +S: Orphan
> +F: target-mips/
> +
>  PowerPC
> -  ppc_prep.c  ?
> -  ppc_oldworld.c  Alexander Graf
> -  ppc_newworld.c  Alexander Graf
> -  ppc405_boards.c Alexander Graf
> -M86K
> -  mcf5208.c   Paul Brook
> -  an5206.cPaul Brook
> -  dummy_m68k.cPaul Brook
> +M: Alexander Graf 
> +S: Maintained
> +F: target-ppc/
> +
> +M68K
> +M: Paul Brook 
> +S: Maintained
> +F: target-m68k/
> +
>  SH4
> -  shix.c  ?
> -  r2d.c   Magnus Damm
> +M: qemu-devel@nongnu.org
> +S: Orphan
> +F: target-sh4/
> +
>  CRIS
> -  etraxfs.c   Edgar E. Iglesias
> -  axis_dev88.cEdgar E. Iglesias
> +M: Edgar E. Iglesias 
> +S: Maintained
> +F: target-cris/
> +
>  Alpha
> +M: qemu-devel@nongnu.org
> +S: Orphan
> +F: target-alpha/
> +
>  MicroBlaze
> -  petalogix_s3adsp1800.c  Edgar E. Iglesias
> +M: Edgar E. Iglesias 
> +S: Maintained
> +F: target-microblaze/
> +
> +S390
> +M: Alexander Graf 
> +S: Maintained
> +F: target-s390x/
> +
> +Guest CPU Cores (KVM):
> +--
> +
> +Overall
> +M: Avi Kivity 
> +M: Marcelo Tosatti 
> +L: k...@vger.kernel.org
> +S: Supported
> +F: kvm-*
> +F: */kvm.*
> +
> +X86
> +M: Avi Kivity 
> +M: Marcelo Tosatti 
> +L: k...@vger.kernel.org
> +S: Supported
> +F: target-i386/kvm.c
> +
> +PPC
> +M: Alexander Graf 
> +S: Maintained
> +F: target-ppc/kvm.c
> +
>  S390
> -  s390-*.cAlexander Graf
> +M: Alexander Graf 
> +S: Maintained
> +F: target-s390x/kvm.c
> +
> +X86 Machines
> +
> +
> +PC
> +M: Anthony Liguori 
> +S: Supported
> +F: hw/pc.[ch] hw/pc_piix.c
> +
> +
> +ARM Machines
> +
> +M: Paul Brook 
> +S: Maintained
> +F: hw/integratorcp.c
> +
> +Versatile PB
> +M: Paul Brook 
> +S: Maintained
> +F: hw/versatilepb.c
> +
> +Real View
> +M: Paul Brook 
> +S: Maintained
> +F: hw/realview*
> +
> +Spitz
> +M: Andrzej Zaborowski 
> +S: Maintained
> +F: hw/spitz.c
> +
> +Palm
> +M: Andrzej Zaborowski 
> +S: Maintained
> +F: hw/palm.c
> +
> +nSeries
> +M: Andrzej Zaborowski 
> +S: Maintained
> +F: hw/nseries.c
> +
> +Stellaris
> +M: Paul Brook 
> +S: Maintained
> +F: hw/stellaris.c
> +
> +Gumstix
> +M: qemu-devel@nongnu.org
> +S: Orphan
> +F: hw/gumstix.c
> +
> +Mainstone
> +M: qemu-devel@nongnu.org
> +S: Orphan
> +F: hw/mainstone.c
> +
> +Mu

[Qemu-devel] Re: [PATCH] Use a Linux-style MAINTAINERS file

[Alexander Graf]

On 09.09.2010, at 23:18, Anthony Liguori wrote:

> I make no claims that this is accurate or exhaustive but I think it's a
> reasonable place to start.
> 
> As the file mentions, the purpose of this file is to give contributors
> information about who they can go to with questions about a particular piece 
> of
> code or who they can ask for review.
> 
> If you sign up for a piece of code and indicate that it's Maintained or
> Supported, please be prepared to be responsive to questions about that
> subsystem.
> 
> Signed-off-by: Anthony Liguori 
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 79dfc7f..3894cd8 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -9,89 +9,388 @@ to be CC'd when submitting a patch to obtain appropriate 
> review.
> In general, if you have a question about inclusion of a patch, you should
> consult qemu-devel and not any specific individual privately.
> 
> -Project leaders:
> -
> +Please see the MAINTAINERS file in the Linux kernel for information about how
> +to update this file.
> 
> -Paul Brook
> -Anthony Liguori
> +General Project Administration
> +--
> +M: Anthony Liguori 
> +M: Paul Brook 
> 
> Guest CPU cores (TCG):
> --
> -
> -x86?
> -ARMPaul Brook
> -SPARC  Blue Swirl
> -MIPS   ?
> -PowerPCAlexander Graf
> -M68K   Paul Brook
> -SH4?
> -CRIS   Edgar E. Iglesias
> -Alpha  ?
> -MicroBlaze Edgar E. Iglesias
> -S390   ?
> -
> -Machines (sorted by CPU):
> --
> -
> x86
> -  pc.cAnthony Liguori
> +M: qemu-devel@nongnu.org
> +S: Odd Fixes
> +F: target-i386/
> +
> ARM
> -  integratorcp.c  Paul Brook
> -  versatilepb.c   Paul Brook
> -  Real View   Paul Brook
> -  spitz.c Andrzej Zaborowski
> -  palm.c  Andrzej Zaborowski
> -  nseries.c   Andrzej Zaborowski
> -  stellaris.c Paul Brook
> -  gumstix.c   Thorsten Zitterell
> -  mainstone.c Armin Kuster
> -  musicpal.c  Jan Kiszka
> +M: Paul Brook 
> +S: Maintained
> +F: target-arm/
> +
> SPARC
> -  sun4u.c Blue Swirl
> -  sun4m.c Blue Swirl
> +M: Blue Swirl 
> +S: Maintained
> +F: target-sparc/
> +
> MIPS
> -  mips_r4k.c  Aurelien Jarno
> -  mips_malta.cAurelien Jarno
> -  mips_jazz.c Hervé Poussineau
> -  mips_mipssim.c  ?
> +M: qemu-devel@nongnu.org
> +S: Orphan
> +F: target-mips/
> +
> PowerPC
> -  ppc_prep.c  ?
> -  ppc_oldworld.c  Alexander Graf
> -  ppc_newworld.c  Alexander Graf
> -  ppc405_boards.c Alexander Graf
> -M86K
> -  mcf5208.c   Paul Brook
> -  an5206.cPaul Brook
> -  dummy_m68k.cPaul Brook
> +M: Alexander Graf 
> +S: Maintained
> +F: target-ppc/
> +
> +M68K
> +M: Paul Brook 
> +S: Maintained
> +F: target-m68k/
> +
> SH4
> -  shix.c  ?
> -  r2d.c   Magnus Damm
> +M: qemu-devel@nongnu.org
> +S: Orphan
> +F: target-sh4/
> +
> CRIS
> -  etraxfs.c   Edgar E. Iglesias
> -  axis_dev88.cEdgar E. Iglesias
> +M: Edgar E. Iglesias 
> +S: Maintained
> +F: target-cris/
> +
> Alpha
> +M: qemu-devel@nongnu.org
> +S: Orphan
> +F: target-alpha/
> +
> MicroBlaze
> -  petalogix_s3adsp1800.c  Edgar E. Iglesias
> +M: Edgar E. Iglesias 
> +S: Maintained
> +F: target-microblaze/
> +
> +S390
> +M: Alexander Graf 
> +S: Maintained
> +F: target-s390x/
> +
> +Guest CPU Cores (KVM):
> +--
> +
> +Overall
> +M: Avi Kivity 
> +M: Marcelo Tosatti 
> +L: k...@vger.kernel.org
> +S: Supported
> +F: kvm-*
> +F: */kvm.*
> +
> +X86
> +M: Avi Kivity 
> +M: Marcelo Tosatti 
> +L: k...@vger.kernel.org
> +S: Supported
> +F: target-i386/kvm.c
> +
> +PPC
> +M: Alexander Graf 

L: kvm-...@vger.kernel.org

> +S: Maintained
> +F: target-ppc/kvm.c

F: target-ppc/kvm*

> +
> S390
> -  s390-*.cAlexander Graf
> +M: Alexander Graf 
> +S: Maintained
> +F: target-s390x/kvm.c
> +
> +X86 Machines
> +
> +
> +PC
> +M: Anthony Liguori 
> +S: Supported
> +F: hw/pc.[ch] hw/pc_piix.c
> +
> +
> +ARM Machines
> +
> +M: Paul Brook 
> +S: Maintained
> +F: hw/integratorcp.c
> +
> +Versatile PB
> +M: Paul Brook 
> +S: Maintained
> +F: hw/versatilepb.c
> +
> +Real View
> +M: Paul Brook 
> +S: Maintained
> +F: hw/realview*
> +
> +Spitz
> +M: Andrzej Zaborowski 
> +S: Maintained
> +F: hw/spitz.c
> +
> +Palm
> +M: Andrzej Zaborowski 
> +S: Maintained
> +F: hw/palm.c
> +
> +nSeries
> +M: Andrzej Zaborowski 
> +S: Maintained
> +F: hw/nseries.c
> +
> +Stellaris
> +M: Paul Brook 
> +S: Maintained
> +F: hw/stellaris.c
> +
> +Gumstix
> +M: qemu-devel@nongnu.org
> +S: Orphan
> +F: hw/gumstix.c
> +
> +Mainstone
> +M: qemu-devel@nongnu.org
> +S: Orphan
> +F: hw/main

[Qemu-devel] Re: [PATCH] Use a Linux-style MAINTAINERS file

[Anthony Liguori]

On 09/09/2010 04:35 PM, Edgar E. Iglesias wrote:

+CRIS Machines
+-
+etraxfs
+M: Edgar E. Iglesias
+S: Maintained
+F: hw/etraxfs.c
+
+Axis Dev88
+M: Edgar E. Iglesias
+S: Maintained
+F: hw/axis_dev88.c
+
+MicroBlaze
 

For consistency, this should be:

MicroBlaze Machines
---

Other than that it looks good to me!

Acked-by: Edgar E. Iglesias
   


Indeed, thanks!

Regards,

Anthony Liguori


Thanks,
Edgar


   

+petalogix_s3adsp1800
+M: Edgar E. Iglesias
+S: Maintained
+F: hw/petalogix_s3adsp1800.c