date:20120129

Am 29.01.2012 03:19, schrieb Max Filippov:
 Signed-off-by: Max Filippov jcmvb...@gmail.com

Reviewed-by: Andreas Färber afaer...@suse.de

Good catch!

Andreas

 ---
  exec.c |   12 +---
  1 files changed, 9 insertions(+), 3 deletions(-)
 
 diff --git a/exec.c b/exec.c
 index 5b9eb9a..0e93e0e 100644
 --- a/exec.c
 +++ b/exec.c
 @@ -3279,9 +3279,15 @@ static void watch_mem_write(void *opaque, 
 target_phys_addr_t addr,
  {
  check_watchpoint(addr  ~TARGET_PAGE_MASK, ~(size - 1), BP_MEM_WRITE);
  switch (size) {
 -case 1: stb_phys(addr, val);
 -case 2: stw_phys(addr, val);
 -case 4: stl_phys(addr, val);
 +case 1:
 +stb_phys(addr, val);
 +break;
 +case 2:
 +stw_phys(addr, val);
 +break;
 +case 4:
 +stl_phys(addr, val);
 +break;
  default: abort();
  }
  }

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

Re: [Qemu-devel] [PATCH] kvm: flush the dirty log when unregistering a slot

On 01/27/2012 08:50 AM, Gerhard Wiesinger wrote:
 On Thu, 26 Jan 2012, Avi Kivity wrote:

 On 01/25/2012 10:15 PM, Gerhard Wiesinger wrote:
 On Sun, 15 Jan 2012, Avi Kivity wrote:

 On 01/15/2012 04:40 PM, Gerhard Wiesinger wrote:
 On Sun, 15 Jan 2012, Jan Kiszka wrote:

 On 2012-01-15 15:17, Avi Kivity wrote:
 Otherwise, the dirty log information is lost in the kernel forever.

 Fixes opensuse-12.1 boot screen, which changes the vga windows
 rapidly.

 Confirmed, problems solved here.

 Problem from:
 http://permalink.gmane.org/gmane.comp.emulators.qemu/131853

 Confirmed to be fixed, too. Long awaited patch :-)

 Sorry, I forgot about that.  Please ping me if I do that.


 BTW: There is also a major difference in video performance:
 1.) With Patch: 1400MB/s (MByte/s)
 2.) Without Patch: 6MB/s

 Any reason for that?

 What are you measuring exactly?

 I'm measuring VGA video performance under DOS with own written test
 program.

 What's strange, new findings: Measurement doesn't depend on the patch.
 Sometimes it is high sometimes low. I think I have to investigate
 further.

 Any ideas?

 What vga mode are you using?  What does the test program do?

 DOS Test programs, source and binaries can be found at:
 http://www.wiesinger.com/opensource/qemu/


And which one is slower?

 1.) Measures page A000: with videomode 4F02, see:
 http://www.wiesinger.com/opensource/qemu/memperf.c

 2.) Second test program measures setting and getting video bank, see:
 http://www.wiesinger.com/opensource/qemu/int10per.c
 We already talked about the low performance some time ago and tracked
 it down to kernel = userspace switching. But I benchmarked it
 already once and I think there are some optimizations possible (linear
 list search) with mapping functions (e.g. trivial hash function before)

That would be due to srcu, but recent optimizations in srcu should make
is faster than it was initially (though still slow - kvm trades off
memory map update speed for run-time memory access speed).

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] [PATCH] exec-obsolete: fix length handling

On 01/28/2012 08:13 PM, Blue Swirl wrote:
 Fix suspend/resume broken by off-by-one error in
 59abb06198ee9471e29c970f294eae80c0b39be1.

 Adjust the loop so that it handles correctly the case
 start = (ram_addr_t)-TARGET_PAGE_SIZE, length = TARGET_PAGE_SIZE.

Is the ram_addr_t even legal? ram addresses start from 0 and end up
around ~(ram_addr_t)0  1, max.


 Reported-by: Stefan Berger stef...@linux.vnet.ibm.com
 Signed-off-by: Blue Swirl blauwir...@gmail.com
 ---
  exec-obsolete.h |   10 --
  1 files changed, 4 insertions(+), 6 deletions(-)

 diff --git a/exec-obsolete.h b/exec-obsolete.h
 index 03cf35e..1bba970 100644
 --- a/exec-obsolete.h
 +++ b/exec-obsolete.h
 @@ -81,11 +81,10 @@ static inline void
 cpu_physical_memory_set_dirty_range(ram_addr_t start,
 int dirty_flags)
  {
  uint8_t *p;
 -ram_addr_t addr, end;
 +ram_addr_t cur;

 -end = start + length;
  p = ram_list.phys_dirty + (start  TARGET_PAGE_BITS);
 -for (addr = start; addr = end; addr += TARGET_PAGE_SIZE) {
 +for (cur = 0; cur  length; cur += TARGET_PAGE_SIZE) {
  *p++ |= dirty_flags;
  }
  }
 @@ -96,12 +95,11 @@ static inline void
 cpu_physical_memory_mask_dirty_range(ram_addr_t start,
  {
  int mask;
  uint8_t *p;
 -ram_addr_t addr, end;
 +ram_addr_t cur;

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


-- 
error compiling committee.c: too many arguments to function

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

On 01/27/2012 11:34 PM, Jan Kiszka wrote:
  
  Yes please.  It's halfway through autotest and looks good.  Even if I
  have to change it, we can 'git rebase -p --onto' your branch (though I
  doubt it will be necessary).

 Done, see

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

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


Pulled, thanks a lot.  Testing now.

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] [RFC 00/15] Refactor PC machine to take advantage of QOM

On 01/26/2012 09:36 PM, Anthony Liguori wrote:
 On 01/26/2012 01:12 PM, Peter Maydell wrote:
 On 26 January 2012 19:00, Anthony Liguorialigu...@us.ibm.com  wrote:
 We need to modeled MemoryRegions and qemu_irq in QOM too.

 +1 : this ought to let us get rid of SysBus...

   MemoryRegions
 shouldn't be that difficult.  Our habit of passing qemu_irq's as
 arrays without
 an explicit size will probably require some refactoring but in
 principle,
 supporting irqs should be easy too.

 I think that there are probably a lot of cases where we're using an
 array
 of qemu_irqs now but should be using separately named signals of some
 sort
 instead (particularly where we're using them for things which aren't
 actually
 IRQs...)

 I started hacking up a Pin object that used a Notifier.  It's pretty
 easy to plumb that to an existing qemu_irq so I think that's the way
 to go.

 That way we could incrementally remove qemu_irq usage.

 I started with this path but the pc initialization was so fubar that I
 ran into too many problems.  Now I think I can go back and do it again
 and it will be more reasonable given this refactoring.

 At a high level, a Pin object looks and feels like a qemu_irq. 
 There's a pin_raise, pin_set_level, etc.  But there is also a
 pin_get_level() (it's stateful) and there's a
 pin_add_level_change_notifier() which allows you to register.

 Pins are objects so they can be added to the composition tree which
 means they can be addressed.  If you have a truly unidirectional path,
 then you can just use a child and link and connect them that way.


Like.  But note: like a MemoryRegion, a Pin reflects state held
elsewhere, so it should not be saved/restored.

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] [PATCH v7 05/11] Add XBZRLE to ram_save_block and ram_save_live

On 01/26/2012 04:24 PM, Orit Wasserman wrote:
 Add migration state to store XBRLE params (enablement and cache size).
 In the outgoing migration check to see if the page is cached and
 changed than send compressed page by using save_xbrle_page function.
 In the incoming migration check to see if RAM_SAVE_FLAG_XBRLE is set
 and decompress the page (by using load_xbrle function).

 +/* XBZRLE (Xor Based Zero Length Encoding */
 +typedef struct XBZRLEHeader {
 +uint8_t xh_flags;
 +uint16_t xh_len;
 +uint32_t xh_cksum;
 +} XBZRLEHeader;

__attribute__((packed))

 +
 +/* RAM Migration State */
 +typedef struct ArchMigrationState {
 +int use_xbzrle;
 +int64_t xbzrle_cache_size;
 +} ArchMigrationState;
 +
 +static ArchMigrationState arch_mig_state;

Strange name.

  
 +#define ENCODING_FLAG_XBZRLE 0x1
 +
 +static int save_xbzrle_page(QEMUFile *f, uint8_t *current_data,
 +ram_addr_t current_addr, RAMBlock *block,
 +ram_addr_t offset, int cont)
 +{

...

 +/* Send XBZRLE based compressed page */
 +save_block_hdr(f, block, offset, cont, RAM_SAVE_FLAG_XBZRLE);
 +qemu_put_buffer(f, (uint8_t *) hdr, sizeof(hdr));

Or better, encode the members separately so they get proper endian encoding.

 +qemu_put_buffer(f, encoded_buf, encoded_len);
 +bytes_sent = encoded_len + sizeof(hdr);
 +
 +done:
 +g_free(encoded_buf);
 +return bytes_sent;
 +}
 +
  static RAMBlock *last_block;
  static ram_addr_t last_offset;
  

  
 +/*
 +  page = zrun
 +   | zrun nzrun
 +   | zrun nzrun page

This is no longer accurate.

 +
 +  zrun = length
 +
 +  nzrun = length byte...
 +
 +  length = uleb128 encoded integer
 + */
 +int encode_page(uint8_t *old_buf, uint8_t *new_buf, int slen, uint8_t *dst,
 +int dlen)
 +{
...
 +}
 +
 +int decode_page(uint8_t *src, int slen, uint8_t *dst, int dlen)
 +{
 +int i = 0, d = 0;
 +uint32_t count = 0;
 +
 +while (i  slen - 1) {
 +/* zrun */
 +i += uleb128_decode_small(src + i, count);
 +d += count;
 +
 +/* overflow */
 +if (d  dlen) {
 +return -1;

assert instead?

 +}
 +
 +/* completed decoding */
 +if (i == slen) {
 +return d + 1;
 +}
 +
 +/* nzrun */
 +i += uleb128_decode_small(src + i, count);
 +/* overflow */
 +if (d + count  dlen) {
 +return -1;
 +}
 +memcpy(dst + d, src + i, count);
 +d += count;
 +i += count;
 +}
 +

memset() for the tail?

 +return d + 1;
 +}


-- 
error compiling committee.c: too many arguments to function

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

On 01/29/2012 12:33 PM, Avi Kivity wrote:
 On 01/27/2012 11:34 PM, Jan Kiszka wrote:
   
   Yes please.  It's halfway through autotest and looks good.  Even if I
   have to change it, we can 'git rebase -p --onto' your branch (though I
   doubt it will be necessary).
 
  Done, see
 
  git://git.kiszka.org/qemu-kvm.git queues/qemu-merge
 
  Only moderately tested so far, I'm counting on your machinery.
 

 Pulled, thanks a lot.  Testing now.


1. The default shows apic/ioapic in 'info qtree' (no kvm-), yet I see
the vcpu threads in kvm_vcpu_block(), implying in-kernel irqchip. 
Something's wrong.

2. Migration is broken.

-- 
error compiling committee.c: too many arguments to function

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

On 2012-01-29 12:12, Avi Kivity wrote:
 On 01/29/2012 12:33 PM, Avi Kivity wrote:
 On 01/27/2012 11:34 PM, Jan Kiszka wrote:

 Yes please.  It's halfway through autotest and looks good.  Even if I
 have to change it, we can 'git rebase -p --onto' your branch (though I
 doubt it will be necessary).

 Done, see

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

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


 Pulled, thanks a lot.  Testing now.

 
 1. The default shows apic/ioapic in 'info qtree' (no kvm-), yet I see
 the vcpu threads in kvm_vcpu_block(), implying in-kernel irqchip. 
 Something's wrong.

Nope, that's just the behavior of the original qemu-kvm irqchip (i.e.
kvm extension is merged into the emulated device). Nothing changed here
so far.

 
 2. Migration is broken.

OK, that's new. A trivial scenario?

Jan



signature.asc
Description: OpenPGP digital signature

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

2012-01-29 Thread Paul Brook

 There is a lot of configuration in the .dts file that the QEMU user may
 want to manipulate; particularly when using QEMU for testing embedded
 platforms. The direction I want to go is to select the machine model based
 on the top level DT compatible property (making -M optional), and then
 also allow a lot of the machine layout to be driven by DT data.  ie.
 populate emulated devices from DT data.

I want to remove -M, and the associated board specific knowledge altogether.  
A system that can only create limited variants of hardcoded boards is IMO not 
a viable medium/long term solution.

  This gets slightly more interesting when you have custom machine variants
  (i.e. once we fix the object model, and have proper dynamic machine
  construction).  Even then I'd expect the FDT to be derived
  from/specificed by the machine description, not a separate option.
 
 I started with going down that route, but switched to this model after
 playing with it and noticing that it doesn't seem to fit as well for
 embedded development as providing a .dtb file and having QEMU
 construct a machine that matches the data.

Problem is that a FDT doesn't really tell you everything you need to know in 
order to construct the machine.  If you look back in the archives you should 
find that I tried something similar when I first added the qdev code.  While 
it appears to be a nice idea at first, it doesn't actually work do well in 
practice.  It's maybe OK for simple embedded systems with a single system bus, 
but when you start looking at more sophisticated machines it doesn't fit so 
well.  In particular when you look at things like PCI, devices connected via 
multiple busses (a sound codec with both I2C [command] and I2S [data] 
connections), and some of the stranger bus topographies (some ppc boards have 
lots of weirdness in the FDT) the requirements of qemu and linux start to 
diverge.

Clearly we need to have some sort of FDT support.  However I'm unconvinced 
that it's the correct format for the primary data structure.  For one thing 
it's a hierarchical tree structure, and in my experience describing links 
outside that structure gets hairy.  One of the things we're doing with QOM is 
move from a hierarchical tree/bus to a more general connected web of links 
between devices.

Paul

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

On 01/29/2012 01:15 PM, Jan Kiszka wrote:
 On 2012-01-29 12:12, Avi Kivity wrote:
  On 01/29/2012 12:33 PM, Avi Kivity wrote:
  On 01/27/2012 11:34 PM, Jan Kiszka wrote:
 
  Yes please.  It's halfway through autotest and looks good.  Even if I
  have to change it, we can 'git rebase -p --onto' your branch (though I
  doubt it will be necessary).
 
  Done, see
 
  git://git.kiszka.org/qemu-kvm.git queues/qemu-merge
 
  Only moderately tested so far, I'm counting on your machinery.
 
 
  Pulled, thanks a lot.  Testing now.
 
  
  1. The default shows apic/ioapic in 'info qtree' (no kvm-), yet I see
  the vcpu threads in kvm_vcpu_block(), implying in-kernel irqchip. 
  Something's wrong.

 Nope, that's just the behavior of the original qemu-kvm irqchip (i.e.
 kvm extension is merged into the emulated device). Nothing changed here
 so far.

So, -no-kvm-irqchip should still work as expected?


  
  2. Migration is broken.

 OK, that's new. A trivial scenario?


Incoming command line:

  qemu-system-x86_64 -m 512 /images/Fedora.img -smp 2 -monitor stdio
-incoming tcp::

I expect you can remove '-smp 2' and it would still fail.

-- 
error compiling committee.c: too many arguments to function

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

On 2012-01-29 12:18, Avi Kivity wrote:
 On 01/29/2012 01:15 PM, Jan Kiszka wrote:
 On 2012-01-29 12:12, Avi Kivity wrote:
 On 01/29/2012 12:33 PM, Avi Kivity wrote:
 On 01/27/2012 11:34 PM, Jan Kiszka wrote:

 Yes please.  It's halfway through autotest and looks good.  Even if I
 have to change it, we can 'git rebase -p --onto' your branch (though I
 doubt it will be necessary).

 Done, see

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

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


 Pulled, thanks a lot.  Testing now.


 1. The default shows apic/ioapic in 'info qtree' (no kvm-), yet I see
 the vcpu threads in kvm_vcpu_block(), implying in-kernel irqchip. 
 Something's wrong.

 Nope, that's just the behavior of the original qemu-kvm irqchip (i.e.
 kvm extension is merged into the emulated device). Nothing changed here
 so far.
 
 So, -no-kvm-irqchip should still work as expected?

Yes. In addition, I've patches here to make -machine kernel_irqchip=off
work as well.

 


 2. Migration is broken.

 OK, that's new. A trivial scenario?

 
 Incoming command line:
 
   qemu-system-x86_64 -m 512 /images/Fedora.img -smp 2 -monitor stdio
 -incoming tcp::
 
 I expect you can remove '-smp 2' and it would still fail.
 

Will check.

Jan



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH] exec-obsolete: fix length handling

On Sun, Jan 29, 2012 at 10:22, Avi Kivity a...@redhat.com wrote:
 On 01/28/2012 08:13 PM, Blue Swirl wrote:
 Fix suspend/resume broken by off-by-one error in
 59abb06198ee9471e29c970f294eae80c0b39be1.

 Adjust the loop so that it handles correctly the case
 start = (ram_addr_t)-TARGET_PAGE_SIZE, length = TARGET_PAGE_SIZE.

 Is the ram_addr_t even legal? ram addresses start from 0 and end up
 around ~(ram_addr_t)0  1, max.

Is that defined somewhere? I think only the size of host virtual
address space should limit the range, for example on a 32 bit host,
near to 3GB should be possible as limited by host OS.

Anyway, this version is closer to your original code and should be
equal or better otherwise to current broken code.

 Reported-by: Stefan Berger stef...@linux.vnet.ibm.com
 Signed-off-by: Blue Swirl blauwir...@gmail.com
 ---
  exec-obsolete.h |   10 --
  1 files changed, 4 insertions(+), 6 deletions(-)

 diff --git a/exec-obsolete.h b/exec-obsolete.h
 index 03cf35e..1bba970 100644
 --- a/exec-obsolete.h
 +++ b/exec-obsolete.h
 @@ -81,11 +81,10 @@ static inline void
 cpu_physical_memory_set_dirty_range(ram_addr_t start,
                                                         int dirty_flags)
  {
      uint8_t *p;
 -    ram_addr_t addr, end;
 +    ram_addr_t cur;

 -    end = start + length;
      p = ram_list.phys_dirty + (start  TARGET_PAGE_BITS);
 -    for (addr = start; addr = end; addr += TARGET_PAGE_SIZE) {
 +    for (cur = 0; cur  length; cur += TARGET_PAGE_SIZE) {
          *p++ |= dirty_flags;
      }
  }
 @@ -96,12 +95,11 @@ static inline void
 cpu_physical_memory_mask_dirty_range(ram_addr_t start,
  {
      int mask;
      uint8_t *p;
 -    ram_addr_t addr, end;
 +    ram_addr_t cur;

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


 --
 error compiling committee.c: too many arguments to function

Re: [Qemu-devel] [PATCH] exec-obsolete: fix length handling

On 01/29/2012 01:37 PM, Blue Swirl wrote:
 On Sun, Jan 29, 2012 at 10:22, Avi Kivity a...@redhat.com wrote:
  On 01/28/2012 08:13 PM, Blue Swirl wrote:
  Fix suspend/resume broken by off-by-one error in
  59abb06198ee9471e29c970f294eae80c0b39be1.
 
  Adjust the loop so that it handles correctly the case
  start = (ram_addr_t)-TARGET_PAGE_SIZE, length = TARGET_PAGE_SIZE.
 
  Is the ram_addr_t even legal? ram addresses start from 0 and end up
  around ~(ram_addr_t)0  1, max.

 Is that defined somewhere? I think only the size of host virtual
 address space should limit the range, for example on a 32 bit host,
 near to 3GB should be possible as limited by host OS.

Correct, but the code limits it to 2GB.

 Anyway, this version is closer to your original code and should be
 equal or better otherwise to current broken code.

I prefer the earlier patch, but both should work.


-- 
error compiling committee.c: too many arguments to function

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

On 2012-01-29 12:18, Avi Kivity wrote:

 2. Migration is broken.

 OK, that's new. A trivial scenario?

 
 Incoming command line:
 
   qemu-system-x86_64 -m 512 /images/Fedora.img -smp 2 -monitor stdio
 -incoming tcp::
 
 I expect you can remove '-smp 2' and it would still fail.
 

Could you check if merge point 5fc4ecdf10 works for you? For me it does,
and b1b774ba43 starts failing. Given that the screen is corrupted on the
target side, I suspect the cirrus hwlib moving may have an influence.

Jan



signature.asc
Description: OpenPGP digital signature

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

On 01/29/2012 01:54 PM, Jan Kiszka wrote:
 On 2012-01-29 12:18, Avi Kivity wrote:
 
  2. Migration is broken.
 
  OK, that's new. A trivial scenario?
 
  
  Incoming command line:
  
qemu-system-x86_64 -m 512 /images/Fedora.img -smp 2 -monitor stdio
  -incoming tcp::
  
  I expect you can remove '-smp 2' and it would still fail.
  

 Could you check if merge point 5fc4ecdf10 works for you? For me it does,
 and b1b774ba43 starts failing. Given that the screen is corrupted on the
 target side, I suspect the cirrus hwlib moving may have an influence.


It does, and I see the screen corruption as well (on the HEAD of the
merge, not 5fc4).

-- 
error compiling committee.c: too many arguments to function

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

On 2012-01-29 13:01, Avi Kivity wrote:
 On 01/29/2012 01:54 PM, Jan Kiszka wrote:
 On 2012-01-29 12:18, Avi Kivity wrote:

 2. Migration is broken.

 OK, that's new. A trivial scenario?


 Incoming command line:

   qemu-system-x86_64 -m 512 /images/Fedora.img -smp 2 -monitor stdio
 -incoming tcp::

 I expect you can remove '-smp 2' and it would still fail.


 Could you check if merge point 5fc4ecdf10 works for you? For me it does,
 and b1b774ba43 starts failing. Given that the screen is corrupted on the
 target side, I suspect the cirrus hwlib moving may have an influence.

 
 It does, and I see the screen corruption as well (on the HEAD of the
 merge, not 5fc4).

Looks like 59abb06198 (memory: fix dirty mask function length handling)
is causing this. Might be visible with upstream as well then. Any idea?

Jan



signature.asc
Description: OpenPGP digital signature

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

On 01/29/2012 02:02 PM, Jan Kiszka wrote:
 On 2012-01-29 13:01, Avi Kivity wrote:
  On 01/29/2012 01:54 PM, Jan Kiszka wrote:
  On 2012-01-29 12:18, Avi Kivity wrote:
 
  2. Migration is broken.
 
  OK, that's new. A trivial scenario?
 
 
  Incoming command line:
 
qemu-system-x86_64 -m 512 /images/Fedora.img -smp 2 -monitor stdio
  -incoming tcp::
 
  I expect you can remove '-smp 2' and it would still fail.
 
 
  Could you check if merge point 5fc4ecdf10 works for you? For me it does,
  and b1b774ba43 starts failing. Given that the screen is corrupted on the
  target side, I suspect the cirrus hwlib moving may have an influence.
 
  
  It does, and I see the screen corruption as well (on the HEAD of the
  merge, not 5fc4).

 Looks like 59abb06198 (memory: fix dirty mask function length handling)
 is causing this. Might be visible with upstream as well then. Any idea?


Blue posted patches for this.  s/=// is the simplest.

-- 
error compiling committee.c: too many arguments to function

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

On 01/29/2012 02:04 PM, Avi Kivity wrote:
 On 01/29/2012 02:02 PM, Jan Kiszka wrote:
  On 2012-01-29 13:01, Avi Kivity wrote:
   On 01/29/2012 01:54 PM, Jan Kiszka wrote:
   On 2012-01-29 12:18, Avi Kivity wrote:
  
   2. Migration is broken.
  
   OK, that's new. A trivial scenario?
  
  
   Incoming command line:
  
 qemu-system-x86_64 -m 512 /images/Fedora.img -smp 2 -monitor stdio
   -incoming tcp::
  
   I expect you can remove '-smp 2' and it would still fail.
  
  
   Could you check if merge point 5fc4ecdf10 works for you? For me it does,
   and b1b774ba43 starts failing. Given that the screen is corrupted on the
   target side, I suspect the cirrus hwlib moving may have an influence.
  
   
   It does, and I see the screen corruption as well (on the HEAD of the
   merge, not 5fc4).
 
  Looks like 59abb06198 (memory: fix dirty mask function length handling)
  is causing this. Might be visible with upstream as well then. Any idea?
 

 Blue posted patches for this.  s/=// is the simplest.


Err, not.  I'll just try Blue's patch.

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] [PATCH] exec-obsolete: fix length handling

On 01/28/2012 08:13 PM, Blue Swirl wrote:
 Fix suspend/resume broken by off-by-one error in
 59abb06198ee9471e29c970f294eae80c0b39be1.

 Adjust the loop so that it handles correctly the case
 start = (ram_addr_t)-TARGET_PAGE_SIZE, length = TARGET_PAGE_SIZE.

 Reported-by: Stefan Berger stef...@linux.vnet.ibm.com
 Signed-off-by: Blue Swirl blauwir...@gmail.com
 ---
  exec-obsolete.h |   10 --
  1 files changed, 4 insertions(+), 6 deletions(-)

 diff --git a/exec-obsolete.h b/exec-obsolete.h
 index 03cf35e..1bba970 100644
 --- a/exec-obsolete.h
 +++ b/exec-obsolete.h
 @@ -81,11 +81,10 @@ static inline void
 cpu_physical_memory_set_dirty_range(ram_addr_t start,
 int dirty_flags)
  {
  uint8_t *p;
 -ram_addr_t addr, end;
 +ram_addr_t cur;

 -end = start + length;
  p = ram_list.phys_dirty + (start  TARGET_PAGE_BITS);
 -for (addr = start; addr = end; addr += TARGET_PAGE_SIZE) {
 +for (cur = 0; cur  length; cur += TARGET_PAGE_SIZE) {
  *p++ |= dirty_flags;
  }

I think this is still wrong - if length == 2 it will iterate once, but
we need two iterations if start == 0xfff.


-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] [PATCH] exec-obsolete: fix length handling

On Sun, Jan 29, 2012 at 12:08, Avi Kivity a...@redhat.com wrote:
 On 01/28/2012 08:13 PM, Blue Swirl wrote:
 Fix suspend/resume broken by off-by-one error in
 59abb06198ee9471e29c970f294eae80c0b39be1.

 Adjust the loop so that it handles correctly the case
 start = (ram_addr_t)-TARGET_PAGE_SIZE, length = TARGET_PAGE_SIZE.

 Reported-by: Stefan Berger stef...@linux.vnet.ibm.com
 Signed-off-by: Blue Swirl blauwir...@gmail.com
 ---
  exec-obsolete.h |   10 --
  1 files changed, 4 insertions(+), 6 deletions(-)

 diff --git a/exec-obsolete.h b/exec-obsolete.h
 index 03cf35e..1bba970 100644
 --- a/exec-obsolete.h
 +++ b/exec-obsolete.h
 @@ -81,11 +81,10 @@ static inline void
 cpu_physical_memory_set_dirty_range(ram_addr_t start,
                                                         int dirty_flags)
  {
      uint8_t *p;
 -    ram_addr_t addr, end;
 +    ram_addr_t cur;

 -    end = start + length;
      p = ram_list.phys_dirty + (start  TARGET_PAGE_BITS);
 -    for (addr = start; addr = end; addr += TARGET_PAGE_SIZE) {
 +    for (cur = 0; cur  length; cur += TARGET_PAGE_SIZE) {
          *p++ |= dirty_flags;
      }

 I think this is still wrong - if length == 2 it will iterate once, but
 we need two iterations if start == 0xfff.

Yes, tricky. We could do something like
for (cur = start  TARGET_PAGE_MASK; cur  length; cur += TARGET_PAGE_SIZE) {
but I'll send a new patch with just s/=//.



 --
 error compiling committee.c: too many arguments to function

[Qemu-devel] [PATCH] exec-obsolete: fix length handling

Fix suspend/resume broken by off-by-one error in
59abb06198ee9471e29c970f294eae80c0b39be1, based on patch by
Stefan Berger.

Reported-by: Stefan Berger stef...@linux.vnet.ibm.com
Signed-off-by: Blue Swirl blauwir...@gmail.com
---
 exec-obsolete.h |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/exec-obsolete.h b/exec-obsolete.h
index 03cf35e..5a1e468 100644
--- a/exec-obsolete.h
+++ b/exec-obsolete.h
@@ -85,7 +85,7 @@ static inline void
cpu_physical_memory_set_dirty_range(ram_addr_t start,

 end = start + length;
 p = ram_list.phys_dirty + (start  TARGET_PAGE_BITS);
-for (addr = start; addr = end; addr += TARGET_PAGE_SIZE) {
+for (addr = start; addr  end; addr += TARGET_PAGE_SIZE) {
 *p++ |= dirty_flags;
 }
 }
@@ -101,7 +101,7 @@ static inline void
cpu_physical_memory_mask_dirty_range(ram_addr_t start,
 end = start + length;
 mask = ~dirty_flags;
 p = ram_list.phys_dirty + (start  TARGET_PAGE_BITS);
-for (addr = start; addr = end; addr += TARGET_PAGE_SIZE) {
+for (addr = start; addr  end; addr += TARGET_PAGE_SIZE) {
 *p++ = mask;
 }
 }
-- 
1.7.9.rc0
From bd2cf8f212fe5b683f24c978f8844e93efab2aca Mon Sep 17 00:00:00 2001
Message-Id: bd2cf8f212fe5b683f24c978f8844e93efab2aca.1327842793.git.blauwir...@gmail.com
From: Blue Swirl blauwir...@gmail.com
Date: Sat, 28 Jan 2012 18:02:08 +
Subject: [PATCH] exec-obsolete: fix length handling

Fix suspend/resume broken by off-by-one error in
59abb06198ee9471e29c970f294eae80c0b39be1, based on patch by
Stefan Berger.

Reported-by: Stefan Berger stef...@linux.vnet.ibm.com
Signed-off-by: Blue Swirl blauwir...@gmail.com
---
 exec-obsolete.h |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/exec-obsolete.h b/exec-obsolete.h
index 03cf35e..5a1e468 100644
--- a/exec-obsolete.h
+++ b/exec-obsolete.h
@@ -85,7 +85,7 @@ static inline void cpu_physical_memory_set_dirty_range(ram_addr_t start,
 
 end = start + length;
 p = ram_list.phys_dirty + (start  TARGET_PAGE_BITS);
-for (addr = start; addr = end; addr += TARGET_PAGE_SIZE) {
+for (addr = start; addr  end; addr += TARGET_PAGE_SIZE) {
 *p++ |= dirty_flags;
 }
 }
@@ -101,7 +101,7 @@ static inline void cpu_physical_memory_mask_dirty_range(ram_addr_t start,
 end = start + length;
 mask = ~dirty_flags;
 p = ram_list.phys_dirty + (start  TARGET_PAGE_BITS);
-for (addr = start; addr = end; addr += TARGET_PAGE_SIZE) {
+for (addr = start; addr  end; addr += TARGET_PAGE_SIZE) {
 *p++ = mask;
 }
 }
-- 
1.7.2.5

Re: [Qemu-devel] [PATCH] exec-obsolete: fix length handling

On 01/29/2012 03:16 PM, Blue Swirl wrote:
 On Sun, Jan 29, 2012 at 12:08, Avi Kivity a...@redhat.com wrote:
  On 01/28/2012 08:13 PM, Blue Swirl wrote:
  Fix suspend/resume broken by off-by-one error in
  59abb06198ee9471e29c970f294eae80c0b39be1.
 
  Adjust the loop so that it handles correctly the case
  start = (ram_addr_t)-TARGET_PAGE_SIZE, length = TARGET_PAGE_SIZE.
 
  Reported-by: Stefan Berger stef...@linux.vnet.ibm.com
  Signed-off-by: Blue Swirl blauwir...@gmail.com
  ---
   exec-obsolete.h |   10 --
   1 files changed, 4 insertions(+), 6 deletions(-)
 
  diff --git a/exec-obsolete.h b/exec-obsolete.h
  index 03cf35e..1bba970 100644
  --- a/exec-obsolete.h
  +++ b/exec-obsolete.h
  @@ -81,11 +81,10 @@ static inline void
  cpu_physical_memory_set_dirty_range(ram_addr_t start,
  int dirty_flags)
   {
   uint8_t *p;
  -ram_addr_t addr, end;
  +ram_addr_t cur;
 
  -end = start + length;
   p = ram_list.phys_dirty + (start  TARGET_PAGE_BITS);
  -for (addr = start; addr = end; addr += TARGET_PAGE_SIZE) {
  +for (cur = 0; cur  length; cur += TARGET_PAGE_SIZE) {
   *p++ |= dirty_flags;
   }
 
  I think this is still wrong - if length == 2 it will iterate once, but
  we need two iterations if start == 0xfff.

 Yes, tricky. We could do something like
 for (cur = start  TARGET_PAGE_MASK; cur  length; cur += TARGET_PAGE_SIZE) {
 but I'll send a new patch with just s/=//.

That's broken too.

I have:

 uint8_t *p;
 ram_addr_t addr, end;
 
-end = start + length;
+end = (start + length - 1) | (TARGET_PAGE_SIZE - 1);
+start = TARGET_PAGE_MASK;
 p = ram_list.phys_dirty + (start  TARGET_PAGE_BITS);
 for (addr = start; addr = end; addr += TARGET_PAGE_SIZE) {
 *p++ |= dirty_flags;
@@ -98,7 +99,8 @@ static inline void
cpu_physical_memory_mask_dirty_range(ram_addr_t start,
 uint8_t *p;
 ram_addr_t addr, end;
 
-end = start + length;
+end = (start + length - 1) | (TARGET_PAGE_SIZE - 1);
+start = TARGET_PAGE_MASK;
 mask = ~dirty_flags;
 p = ram_list.phys_dirty + (start  TARGET_PAGE_BITS);
 for (addr = start; addr = end; addr += TARGET_PAGE_SIZE) {


And a non-terminating migration - not sure if this is the cause.

-- 
error compiling committee.c: too many arguments to function

[Qemu-devel] [PATCH RFC 0/7] Introduce QOM CPU and use for target-arm

Hello,

Here's a series against master, pushing QOM beyond what I've seen on Anthony's
qom-upstream and qom-rebase branches.
It depends on the object_class_foreach() fix posted separately.

Patch 1 is included here to show its use case in patch 5.

Patch 2 suggests a way to start using QOM beyond devices in system emulation.
Patch 3 suggests a way to integrate QOM into the user emulators as well.

Patches 4-5 introduce a CPU class and prepare its use in system and user mode.

Patches 6-7 build upon this infrastructure and start using it for ARM.

This series is surely not yet the final goal as discussed on IRC. It does help
with my and Peter's quest to further clean up the constantly growing mess
surrounding ARM reset vs. one-time initialization though.

The plan there is to get rid of the huge CPUID switch by moving the knowledge
of reset values to CPU classes and by dumb copying of values from class to
instance on reset. The latter for now requires to be able to obtain the
ObjectClass matching a CPUState - in target-specific code this works by simple
pointer arithmetic, encapsulated in a macro.

So, in a spirit similar to Anthony's i440FX rework I'm posting this to check if
I'm on the right track here before I start messing around with other targets.

Regards,
Andreas

Cc: Anthony Liguori aligu...@us.ibm.com
Cc: Peter Maydell peter.mayd...@linaro.org
Cc: Paul Brook p...@codesourcery.com

Andreas Färber (7):
  qom: Introduce object_class_is_abstract()
  qom: Register QOM infrastructure early
  qom: Add QOM support to user emulators
  qom: Introduce CPU class
  cpu: Introduce cpu_class_foreach()
  target-arm: Introduce QOM CPU and use for it CPUID lookup
  target-arm: Embed CPUARMState in QOM ARMCPU

 Makefile.objs |1 +
 Makefile.target   |   16 +++-
 Makefile.user |1 +
 arch_init.c   |1 +
 bsd-user/main.c   |3 +
 darwin-user/main.c|4 +
 hw/cpu.c  |   52 +
 include/qemu/cpu.h|   36 +++
 include/qemu/object.h |8 ++
 linux-user/main.c |3 +
 module.h  |4 +
 qom/object.c  |7 +-
 target-arm/cpu-core.c |  281 +
 target-arm/cpu-core.h |   40 +++
 target-arm/helper.c   |   87 +---
 vl.c  |2 +
 16 files changed, 480 insertions(+), 66 deletions(-)
 create mode 100644 hw/cpu.c
 create mode 100644 include/qemu/cpu.h
 create mode 100644 target-arm/cpu-core.c
 create mode 100644 target-arm/cpu-core.h

-- 
1.7.7

[Qemu-devel] [PATCH RFC 2/7] qom: Register QOM infrastructure early

QOM TYPE_INTERFACE was registered with device_init(), whose
constructors are executed rather late in vl.c's main().

Introduce a new module init type and register it very early so that QOM
can safely be used for machines and CPUs.

Note that *_init() defines an attributed function, so no semicolon is
needed after the brace.

Signed-off-by: Andreas Färber afaer...@suse.de
Cc: Anthony Liguori aligu...@us.ibm.com
---
 module.h |2 ++
 qom/object.c |2 +-
 vl.c |2 ++
 3 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/module.h b/module.h
index ef66730..567ff3a 100644
--- a/module.h
+++ b/module.h
@@ -21,6 +21,7 @@ static void __attribute__((constructor)) do_qemu_init_ ## 
function(void) {  \
 }
 
 typedef enum {
+MODULE_INIT_EARLY,
 MODULE_INIT_BLOCK,
 MODULE_INIT_DEVICE,
 MODULE_INIT_MACHINE,
@@ -28,6 +29,7 @@ typedef enum {
 MODULE_INIT_MAX
 } module_init_type;
 
+#define early_init(function) module_init(function, MODULE_INIT_EARLY)
 #define block_init(function) module_init(function, MODULE_INIT_BLOCK)
 #define device_init(function) module_init(function, MODULE_INIT_DEVICE)
 #define machine_init(function) module_init(function, MODULE_INIT_MACHINE)
diff --git a/qom/object.c b/qom/object.c
index 1821959..3c79e1d 100644
--- a/qom/object.c
+++ b/qom/object.c
@@ -388,7 +388,7 @@ static void register_interface(void)
 type_register_static(interface_info);
 }
 
-device_init(register_interface);
+early_init(register_interface)
 
 Object *object_dynamic_cast_assert(Object *obj, const char *typename)
 {
diff --git a/vl.c b/vl.c
index d88a18c..379ca4e 100644
--- a/vl.c
+++ b/vl.c
@@ -2208,6 +2208,8 @@ int main(int argc, char **argv, char **envp)
 #endif
 }
 
+module_call_init(MODULE_INIT_EARLY);
+
 runstate_init();
 
 init_clocks();
-- 
1.7.7

[Qemu-devel] [PATCH RFC 4/7] qom: Introduce CPU class

It's abstract, derived directly from TYPE_OBJECT (to avoid dependency
on MODULE_INIT_DEVICE) and for now is empty.

Place it in hw/. Have user emulators pick it up via VPATH, building it
per target since they didn't use any qdev/QOM devices so far.

Introduce processor_init() for registering, and call module init as
needed.

Signed-off-by: Andreas Färber afaer...@suse.de
Cc: Anthony Liguori aligu...@us.ibm.com
---
 Makefile.objs  |1 +
 Makefile.target|9 ++---
 arch_init.c|1 +
 bsd-user/main.c|1 +
 darwin-user/main.c |1 +
 hw/cpu.c   |   27 +++
 include/qemu/cpu.h |   27 +++
 linux-user/main.c  |1 +
 module.h   |2 ++
 9 files changed, 67 insertions(+), 3 deletions(-)
 create mode 100644 hw/cpu.c
 create mode 100644 include/qemu/cpu.h

diff --git a/Makefile.objs b/Makefile.objs
index b942625..a4b20fa 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -189,6 +189,7 @@ user-obj-y += $(trace-obj-y)
 
 hw-obj-y =
 hw-obj-y += vl.o loader.o
+hw-obj-y += cpu.o
 hw-obj-$(CONFIG_VIRTIO) += virtio-console.o
 hw-obj-y += usb-libhw.o
 hw-obj-$(CONFIG_VIRTIO_PCI) += virtio-pci.o
diff --git a/Makefile.target b/Makefile.target
index d1b7867..5d3470e 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -107,7 +107,7 @@ signal.o: QEMU_CFLAGS += $(HELPER_CFLAGS)
 
 ifdef CONFIG_LINUX_USER
 
-$(call set-vpath, 
$(SRC_PATH)/linux-user:$(SRC_PATH)/linux-user/$(TARGET_ABI_DIR))
+$(call set-vpath, 
$(SRC_PATH)/linux-user:$(SRC_PATH)/linux-user/$(TARGET_ABI_DIR):$(SRC_PATH)/hw)
 
 QEMU_CFLAGS+=-I$(SRC_PATH)/linux-user/$(TARGET_ABI_DIR) 
-I$(SRC_PATH)/linux-user
 obj-y = main.o syscall.o strace.o mmap.o signal.o thunk.o \
@@ -130,6 +130,7 @@ obj-m68k-y += m68k-sim.o m68k-semi.o
 $(obj-y) $(obj-$(TARGET_BASE_ARCH)-y): $(GENERATED_HEADERS)
 
 obj-y += module.o
+obj-y += cpu.o
 obj-y += $(addprefix ../qom/, $(qom-y))
 obj-y += $(addprefix ../libuser/, $(user-obj-y))
 obj-y += $(addprefix ../libdis-user/, $(libdis-y))
@@ -142,7 +143,7 @@ endif #CONFIG_LINUX_USER
 
 ifdef CONFIG_DARWIN_USER
 
-$(call set-vpath, $(SRC_PATH)/darwin-user)
+$(call set-vpath, $(SRC_PATH)/darwin-user:$(SRC_PATH)/hw)
 
 QEMU_CFLAGS+=-I$(SRC_PATH)/darwin-user -I$(SRC_PATH)/darwin-user/$(TARGET_ARCH)
 
@@ -159,6 +160,7 @@ obj-i386-y += ioport-user.o
 $(obj-y) $(obj-$(TARGET_BASE_ARCH)-y): $(GENERATED_HEADERS)
 
 obj-y += module.o
+obj-y += cpu.o
 obj-y += $(addprefix ../qom/, $(qom-y))
 obj-y += $(addprefix ../libuser/, $(user-obj-y))
 obj-y += $(addprefix ../libdis-user/, $(libdis-y))
@@ -171,7 +173,7 @@ endif #CONFIG_DARWIN_USER
 
 ifdef CONFIG_BSD_USER
 
-$(call set-vpath, $(SRC_PATH)/bsd-user)
+$(call set-vpath, $(SRC_PATH)/bsd-user:$(SRC_PATH)/hw)
 
 QEMU_CFLAGS+=-I$(SRC_PATH)/bsd-user -I$(SRC_PATH)/bsd-user/$(TARGET_ARCH)
 
@@ -183,6 +185,7 @@ obj-i386-y += ioport-user.o
 $(obj-y) $(obj-$(TARGET_BASE_ARCH)-y): $(GENERATED_HEADERS)
 
 obj-y += module.o
+obj-y += cpu.o
 obj-y += $(addprefix ../qom/, $(qom-y))
 obj-y += $(addprefix ../libuser/, $(user-obj-y))
 obj-y += $(addprefix ../libdis-user/, $(libdis-y))
diff --git a/arch_init.c b/arch_init.c
index 2366511..c0d5f4f 100644
--- a/arch_init.c
+++ b/arch_init.c
@@ -692,6 +692,7 @@ void do_smbios_option(const char *optarg)
 
 void cpudef_init(void)
 {
+module_call_init(MODULE_INIT_CPU);
 #if defined(cpudef_setup)
 cpudef_setup(); /* parse cpu definitions in target config file */
 #endif
diff --git a/bsd-user/main.c b/bsd-user/main.c
index 2ff0361..70e1146 100644
--- a/bsd-user/main.c
+++ b/bsd-user/main.c
@@ -761,6 +761,7 @@ int main(int argc, char **argv)
 }
 
 cpu_model = NULL;
+module_call_init(MODULE_INIT_CPU);
 #if defined(cpudef_setup)
 cpudef_setup(); /* parse cpu definitions in target config file (TBD) */
 #endif
diff --git a/darwin-user/main.c b/darwin-user/main.c
index a4c630d..d065f00 100644
--- a/darwin-user/main.c
+++ b/darwin-user/main.c
@@ -751,6 +751,7 @@ int main(int argc, char **argv)
 usage();
 
 module_call_init(MODULE_INIT_EARLY);
+module_call_init(MODULE_INIT_CPU);
 
 optind = 1;
 for(;;) {
diff --git a/hw/cpu.c b/hw/cpu.c
new file mode 100644
index 000..c0e9cfa
--- /dev/null
+++ b/hw/cpu.c
@@ -0,0 +1,27 @@
+/*
+ * QEMU CPU model
+ *
+ * Copyright (c) 2012 SUSE LINUX Products GmbH
+ *
+ * Licensed under the terms of the GNU GPL version 2
+ * or (at your option) any later version.
+ */
+
+#include qemu/object.h
+#include qemu/cpu.h
+#include qemu-common.h
+
+static TypeInfo cpu_type_info = {
+.name = TYPE_CPU,
+.parent = TYPE_OBJECT,
+.instance_size = sizeof(CPU),
+.abstract = true,
+.class_size = sizeof(CPUClass),
+};
+
+static void cpu_register_types(void)
+{
+type_register_static(cpu_type_info);
+}
+
+processor_init(cpu_register_types)
diff --git a/include/qemu/cpu.h b/include/qemu/cpu.h
new file mode 100644
index 000..4b81f3b
--- /dev/null
+++ b/include/qemu/cpu.h
@@ -0,0 +1,27 @@
+/*
+ *

[Qemu-devel] [PATCH RFC 3/7] qom: Add QOM support to user emulators

Link the Object base class and the module infrastructure for class
registration. Call early module init.

Signed-off-by: Andreas Färber afaer...@suse.de
Cc: Anthony Liguori aligu...@us.ibm.com
---
 Makefile.target|6 ++
 Makefile.user  |1 +
 bsd-user/main.c|2 ++
 darwin-user/main.c |3 +++
 linux-user/main.c  |2 ++
 5 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/Makefile.target b/Makefile.target
index 68481a3..d1b7867 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -129,6 +129,8 @@ obj-m68k-y += m68k-sim.o m68k-semi.o
 
 $(obj-y) $(obj-$(TARGET_BASE_ARCH)-y): $(GENERATED_HEADERS)
 
+obj-y += module.o
+obj-y += $(addprefix ../qom/, $(qom-y))
 obj-y += $(addprefix ../libuser/, $(user-obj-y))
 obj-y += $(addprefix ../libdis-user/, $(libdis-y))
 obj-y += $(libobj-y)
@@ -156,6 +158,8 @@ obj-i386-y += ioport-user.o
 
 $(obj-y) $(obj-$(TARGET_BASE_ARCH)-y): $(GENERATED_HEADERS)
 
+obj-y += module.o
+obj-y += $(addprefix ../qom/, $(qom-y))
 obj-y += $(addprefix ../libuser/, $(user-obj-y))
 obj-y += $(addprefix ../libdis-user/, $(libdis-y))
 obj-y += $(libobj-y)
@@ -178,6 +182,8 @@ obj-i386-y += ioport-user.o
 
 $(obj-y) $(obj-$(TARGET_BASE_ARCH)-y): $(GENERATED_HEADERS)
 
+obj-y += module.o
+obj-y += $(addprefix ../qom/, $(qom-y))
 obj-y += $(addprefix ../libuser/, $(user-obj-y))
 obj-y += $(addprefix ../libdis-user/, $(libdis-y))
 obj-y += $(libobj-y)
diff --git a/Makefile.user b/Makefile.user
index 2b1e4d1..72d01c1 100644
--- a/Makefile.user
+++ b/Makefile.user
@@ -9,6 +9,7 @@ include $(SRC_PATH)/rules.mak
 $(call set-vpath, $(SRC_PATH))
 
 QEMU_CFLAGS+=-I..
+QEMU_CFLAGS+=-I$(SRC_PATH)/include
 
 include $(SRC_PATH)/Makefile.objs
 
diff --git a/bsd-user/main.c b/bsd-user/main.c
index cc7d4a3..2ff0361 100644
--- a/bsd-user/main.c
+++ b/bsd-user/main.c
@@ -748,6 +748,8 @@ int main(int argc, char **argv)
 if (argc = 1)
 usage();
 
+module_call_init(MODULE_INIT_EARLY);
+
 if ((envlist = envlist_create()) == NULL) {
 (void) fprintf(stderr, Unable to allocate envlist\n);
 exit(1);
diff --git a/darwin-user/main.c b/darwin-user/main.c
index 9b57c20..a4c630d 100644
--- a/darwin-user/main.c
+++ b/darwin-user/main.c
@@ -28,6 +28,7 @@
 #include sys/mman.h
 
 #include qemu.h
+#include qemu-common.h
 
 #define DEBUG_LOGFILE /tmp/qemu.log
 
@@ -749,6 +750,8 @@ int main(int argc, char **argv)
 if (argc = 1)
 usage();
 
+module_call_init(MODULE_INIT_EARLY);
+
 optind = 1;
 for(;;) {
 if (optind = argc)
diff --git a/linux-user/main.c b/linux-user/main.c
index 64d2208..d4368b6 100644
--- a/linux-user/main.c
+++ b/linux-user/main.c
@@ -3280,6 +3280,8 @@ int main(int argc, char **argv, char **envp)
 
 qemu_cache_utils_init(envp);
 
+module_call_init(MODULE_INIT_EARLY);
+
 if ((envlist = envlist_create()) == NULL) {
 (void) fprintf(stderr, Unable to allocate envlist\n);
 exit(1);
-- 
1.7.7

[Qemu-devel] [PATCH RFC 5/7] cpu: Introduce cpu_class_foreach()

Provides an easy way to loop over all non-abstract CPU classes.

Signed-off-by: Andreas Färber afaer...@suse.de
---
 hw/cpu.c   |   25 +
 include/qemu/cpu.h |9 +
 2 files changed, 34 insertions(+), 0 deletions(-)

diff --git a/hw/cpu.c b/hw/cpu.c
index c0e9cfa..ac0add7 100644
--- a/hw/cpu.c
+++ b/hw/cpu.c
@@ -11,6 +11,31 @@
 #include qemu/cpu.h
 #include qemu-common.h
 
+struct CPUListData {
+void (*fn)(ObjectClass *klass, void *opaque);
+void *opaque;
+};
+
+static void cpu_class_foreach_tramp(ObjectClass *klass, void *opaque)
+{
+struct CPUListData *s = opaque;
+
+if (!object_class_is_abstract(klass) 
+object_class_dynamic_cast(klass, TYPE_CPU) != NULL) {
+s-fn(klass, s-opaque);
+}
+}
+
+void cpu_class_foreach(void (*fn)(ObjectClass *klass, void *opaque),
+   void *opaque)
+{
+struct CPUListData s = {
+.fn = fn,
+.opaque = opaque,
+};
+object_class_foreach(cpu_class_foreach_tramp, s);
+}
+
 static TypeInfo cpu_type_info = {
 .name = TYPE_CPU,
 .parent = TYPE_OBJECT,
diff --git a/include/qemu/cpu.h b/include/qemu/cpu.h
index 4b81f3b..d06c87e 100644
--- a/include/qemu/cpu.h
+++ b/include/qemu/cpu.h
@@ -24,4 +24,13 @@ typedef struct CPU {
 } CPU;
 
 
+/**
+ * cpu_class_foreach:
+ * @fn: Callback function called for each non-abstract CPU type.
+ * @opaque: Opaque data passed through to the callback function.
+ */
+void cpu_class_foreach(void (*fn)(ObjectClass *klass, void *opaque),
+   void *opaque);
+
+
 #endif
-- 
1.7.7

[Qemu-devel] [PATCH RFC 7/7] target-arm: Embed CPUARMState in QOM ARMCPU

We g_malloc0()'ed CPUARMState ourself, and exec.c's cpu_copy() runs
through cpu_init() as well, so we are at liberty to supply the CPUState
any way we see fit. Having CPUARMState as field in the QOM CPU allows
both to access env from an ARMCPU object and to access the QOM Object
and its ObjectClass from an env pointer, in ARM code for now.

The goal is to convert all CPUs to QOM and to use CPU objects in central
places, especially once we have property support for Object.
This will then allow to have TCG AREG0 point to target-specific fields
where small immediate offsets are desired (as pointed out by rth) while
allowing for common fields at known offsets from the base class.

Having the CPUID in ARMCPUClass, we can set it from the realize function.
Same for cpu_model_str, which is now the QOM class name.

Signed-off-by: Andreas Färber afaer...@suse.de
Cc: Anthony Liguori aligu...@us.ibm.com
Cc: Paul Brook p...@codesourcery.com
Cc: Peter Maydell peter.mayd...@linaro.org
Cc: Richard Henderson r...@twiddle.net
---
 target-arm/cpu-core.c |   13 +
 target-arm/cpu-core.h |7 +++
 target-arm/helper.c   |   13 ++---
 3 files changed, 26 insertions(+), 7 deletions(-)

diff --git a/target-arm/cpu-core.c b/target-arm/cpu-core.c
index 9761d8e..b1ac22c 100644
--- a/target-arm/cpu-core.c
+++ b/target-arm/cpu-core.c
@@ -234,12 +234,25 @@ static const struct ARMCPUDef arm_cpu_models[] = {
 { }
 };
 
+static void arm_cpu_realize(Object *obj)
+{
+ARMCPU *cpu = ARM_CPU(obj);
+ARMCPUClass *cpu_class = ARM_CPU_GET_CLASS(obj);
+
+memset(cpu-env, 0, sizeof(CPUARMState));
+cpu_exec_init(cpu-env);
+
+cpu-env.cpu_model_str = object_get_typename(obj);
+cpu-env.cp15.c0_cpuid = cpu_class-id;
+}
+
 static void cpu_register(const struct ARMCPUDef *def)
 {
 TypeInfo type = {
 .name = def-name,
 .parent = TYPE_ARM_CPU,
 .instance_size = sizeof(ARMCPU),
+.instance_init = arm_cpu_realize,
 .class_size = sizeof(ARMCPUClass),
 .class_init = def-class_init,
 };
diff --git a/target-arm/cpu-core.h b/target-arm/cpu-core.h
index be4bbc3..08b6b2b 100644
--- a/target-arm/cpu-core.h
+++ b/target-arm/cpu-core.h
@@ -10,6 +10,7 @@
 #define QEMU_ARM_CPU_CORE_H
 
 #include qemu/cpu.h
+#include cpu.h
 
 #define TYPE_ARM_CPU arm-cpu-core
 #define ARM_CPU_CLASS(klass) \
@@ -27,7 +28,13 @@ typedef struct ARMCPUClass {
 
 typedef struct ARMCPU {
 CPU parent_obj;
+
+/* TODO Inline this and split off common state */
+CPUARMState env;
 } ARMCPU;
 
+#define ENV_GET_OBJECT(e) \
+(Object *)((void *)(e) - offsetof(ARMCPU, env))
+
 
 #endif
diff --git a/target-arm/helper.c b/target-arm/helper.c
index ece9635..1ffd7ba 100644
--- a/target-arm/helper.c
+++ b/target-arm/helper.c
@@ -400,7 +400,7 @@ static int vfp_gdb_set_reg(CPUState *env, uint8_t *buf, int 
reg)
 CPUARMState *cpu_arm_init(const char *cpu_model)
 {
 ObjectClass *klass;
-ARMCPUClass *cpu_class;
+ARMCPU *cpu;
 CPUARMState *env;
 static int inited = 0;
 
@@ -408,16 +408,14 @@ CPUARMState *cpu_arm_init(const char *cpu_model)
 if (klass == NULL) {
 return NULL;
 }
-cpu_class = ARM_CPU_CLASS(klass);
-env = g_malloc0(sizeof(CPUARMState));
-cpu_exec_init(env);
+cpu = ARM_CPU(object_new_with_type(klass-type));
+env = cpu-env;
+
 if (tcg_enabled()  !inited) {
 inited = 1;
 arm_translate_init();
 }
 
-env-cpu_model_str = cpu_model;
-env-cp15.c0_cpuid = cpu_class-id;
 cpu_reset(env);
 if (arm_feature(env, ARM_FEATURE_NEON)) {
 gdb_register_coprocessor(env, vfp_gdb_get_reg, vfp_gdb_set_reg,
@@ -459,7 +457,8 @@ void arm_cpu_list(FILE *f, fprintf_function cpu_fprintf)
 
 void cpu_arm_close(CPUARMState *env)
 {
-g_free(env);
+Object *obj = ENV_GET_OBJECT(env);
+object_delete(obj);
 }
 
 static int bad_mode_switch(CPUState *env, int mode)
-- 
1.7.7

Re: [Qemu-devel] [PATCH] exec-obsolete: fix length handling

On Sun, Jan 29, 2012 at 13:20, Avi Kivity a...@redhat.com wrote:
 On 01/29/2012 03:16 PM, Blue Swirl wrote:
 On Sun, Jan 29, 2012 at 12:08, Avi Kivity a...@redhat.com wrote:
  On 01/28/2012 08:13 PM, Blue Swirl wrote:
  Fix suspend/resume broken by off-by-one error in
  59abb06198ee9471e29c970f294eae80c0b39be1.
 
  Adjust the loop so that it handles correctly the case
  start = (ram_addr_t)-TARGET_PAGE_SIZE, length = TARGET_PAGE_SIZE.
 
  Reported-by: Stefan Berger stef...@linux.vnet.ibm.com
  Signed-off-by: Blue Swirl blauwir...@gmail.com
  ---
   exec-obsolete.h |   10 --
   1 files changed, 4 insertions(+), 6 deletions(-)
 
  diff --git a/exec-obsolete.h b/exec-obsolete.h
  index 03cf35e..1bba970 100644
  --- a/exec-obsolete.h
  +++ b/exec-obsolete.h
  @@ -81,11 +81,10 @@ static inline void
  cpu_physical_memory_set_dirty_range(ram_addr_t start,
                                                          int dirty_flags)
   {
       uint8_t *p;
  -    ram_addr_t addr, end;
  +    ram_addr_t cur;
 
  -    end = start + length;
       p = ram_list.phys_dirty + (start  TARGET_PAGE_BITS);
  -    for (addr = start; addr = end; addr += TARGET_PAGE_SIZE) {
  +    for (cur = 0; cur  length; cur += TARGET_PAGE_SIZE) {
           *p++ |= dirty_flags;
       }
 
  I think this is still wrong - if length == 2 it will iterate once, but
  we need two iterations if start == 0xfff.

 Yes, tricky. We could do something like
 for (cur = start  TARGET_PAGE_MASK; cur  length; cur += TARGET_PAGE_SIZE) {
 but I'll send a new patch with just s/=//.

 That's broken too.

Because length should be adjusted by -1?

 I have:

     uint8_t *p;
     ram_addr_t addr, end;

 -    end = start + length;
 +    end = (start + length - 1) | (TARGET_PAGE_SIZE - 1);

Why  | (TARGET_PAGE_SIZE - 1), for length == 1? TARGET_PAGE_ALIGN()
could be useful here.

 +    start = TARGET_PAGE_MASK;
     p = ram_list.phys_dirty + (start  TARGET_PAGE_BITS);
     for (addr = start; addr = end; addr += TARGET_PAGE_SIZE) {
         *p++ |= dirty_flags;
 @@ -98,7 +99,8 @@ static inline void
 cpu_physical_memory_mask_dirty_range(ram_addr_t start,
     uint8_t *p;
     ram_addr_t addr, end;

 -    end = start + length;
 +    end = (start + length - 1) | (TARGET_PAGE_SIZE - 1);
 +    start = TARGET_PAGE_MASK;
     mask = ~dirty_flags;
     p = ram_list.phys_dirty + (start  TARGET_PAGE_BITS);
     for (addr = start; addr = end; addr += TARGET_PAGE_SIZE) {


 And a non-terminating migration - not sure if this is the cause.

 --
 error compiling committee.c: too many arguments to function

[Qemu-devel] [PATCH RFC 6/7] target-arm: Introduce QOM CPU and use for it CPUID lookup

Create a CPU subclass, and register classes matching all CPU models.
Don't name the file target-arm/cpu.c so that the user emulators can
still easily pick up the base class in hw/cpu.c via VPATH.

Make arm_cpu_list() enumerate CPU subclasses.

Replace cpu_arm_find_by_name()'s string - CPUID lookup by storing the
CPUID in the class.
NB: CPUIDs were first introduced by Paul Brook in r1765 (2006).

Signed-off-by: Andreas Färber afaer...@suse.de
Cc: Anthony Liguori aligu...@us.ibm.com
Cc: Paul Brook p...@codesourcery.com
Cc: Peter Maydell peter.mayd...@linaro.org
---
 Makefile.target   |1 +
 target-arm/cpu-core.c |  268 +
 target-arm/cpu-core.h |   33 ++
 target-arm/helper.c   |   80 ---
 4 files changed, 324 insertions(+), 58 deletions(-)
 create mode 100644 target-arm/cpu-core.c
 create mode 100644 target-arm/cpu-core.h

diff --git a/Makefile.target b/Makefile.target
index 5d3470e..96043c4 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -80,6 +80,7 @@ endif
 libobj-$(TARGET_SPARC64) += vis_helper.o
 libobj-$(CONFIG_NEED_MMU) += mmu.o
 libobj-$(TARGET_ARM) += neon_helper.o iwmmxt_helper.o
+libobj-$(TARGET_ARM) += cpu-core.o
 ifeq ($(TARGET_BASE_ARCH), sparc)
 libobj-y += fop_helper.o cc_helper.o win_helper.o mmu_helper.o ldst_helper.o
 libobj-y += cpu_init.o
diff --git a/target-arm/cpu-core.c b/target-arm/cpu-core.c
new file mode 100644
index 000..9761d8e
--- /dev/null
+++ b/target-arm/cpu-core.c
@@ -0,0 +1,268 @@
+/*
+ * QEMU ARM CPU core
+ *
+ * Copyright (c) 2012 SUSE LINUX Products GmbH
+ *
+ * Licensed under the terms of the GNU GPL version 2
+ * or (at your option) any later version.
+ */
+
+#include cpu-core.h
+#include qemu-common.h
+
+/* CPU models */
+
+static void arm926_class_init(ObjectClass *klass, void *data)
+{
+ARMCPUClass *k = ARM_CPU_CLASS(klass);
+
+k-id = 0x41069265;
+}
+
+static void arm946_class_init(ObjectClass *klass, void *data)
+{
+ARMCPUClass *k = ARM_CPU_CLASS(klass);
+
+k-id = 0x41059461;
+}
+
+static void arm1026_class_init(ObjectClass *klass, void *data)
+{
+ARMCPUClass *k = ARM_CPU_CLASS(klass);
+
+k-id = 0x4106a262;
+}
+
+static void arm1136_r0_class_init(ObjectClass *klass, void *data)
+{
+ARMCPUClass *k = ARM_CPU_CLASS(klass);
+
+k-id = 0x4107b362;
+}
+
+static void arm1136_r1_class_init(ObjectClass *klass, void *data)
+{
+ARMCPUClass *k = ARM_CPU_CLASS(klass);
+
+k-id = 0x4117b363;
+}
+
+static void arm1176_class_init(ObjectClass *klass, void *data)
+{
+ARMCPUClass *k = ARM_CPU_CLASS(klass);
+
+k-id = 0x410fb767;
+}
+
+static void arm11mpcore_class_init(ObjectClass *klass, void *data)
+{
+ARMCPUClass *k = ARM_CPU_CLASS(klass);
+
+k-id = 0x410fb022;
+}
+
+static void cortex_m3_class_init(ObjectClass *klass, void *data)
+{
+ARMCPUClass *k = ARM_CPU_CLASS(klass);
+
+k-id = 0x410fc231;
+}
+
+static void cortex_a8_class_init(ObjectClass *klass, void *data)
+{
+ARMCPUClass *k = ARM_CPU_CLASS(klass);
+
+k-id = 0x410fc080;
+}
+
+static void cortex_a9_class_init(ObjectClass *klass, void *data)
+{
+ARMCPUClass *k = ARM_CPU_CLASS(klass);
+
+k-id = 0x410fc090;
+}
+
+static void cortex_a15_class_init(ObjectClass *klass, void *data)
+{
+ARMCPUClass *k = ARM_CPU_CLASS(klass);
+
+k-id = 0x412fc0f1;
+}
+
+static void ti925t_class_init(ObjectClass *klass, void *data)
+{
+ARMCPUClass *k = ARM_CPU_CLASS(klass);
+
+k-id = 0x54029252;
+}
+
+static void sa1100_class_init(ObjectClass *klass, void *data)
+{
+ARMCPUClass *k = ARM_CPU_CLASS(klass);
+
+k-id = 0x4401A11B;
+}
+
+static void sa1110_class_init(ObjectClass *klass, void *data)
+{
+ARMCPUClass *k = ARM_CPU_CLASS(klass);
+
+k-id = 0x6901B119;
+}
+
+static void pxa250_class_init(ObjectClass *klass, void *data)
+{
+ARMCPUClass *k = ARM_CPU_CLASS(klass);
+
+k-id = 0x69052100;
+}
+
+static void pxa255_class_init(ObjectClass *klass, void *data)
+{
+ARMCPUClass *k = ARM_CPU_CLASS(klass);
+
+k-id = 0x69052d00;
+}
+
+static void pxa260_class_init(ObjectClass *klass, void *data)
+{
+ARMCPUClass *k = ARM_CPU_CLASS(klass);
+
+k-id = 0x69052903;
+}
+
+static void pxa261_class_init(ObjectClass *klass, void *data)
+{
+ARMCPUClass *k = ARM_CPU_CLASS(klass);
+
+k-id = 0x69052d05;
+}
+
+static void pxa262_class_init(ObjectClass *klass, void *data)
+{
+ARMCPUClass *k = ARM_CPU_CLASS(klass);
+
+k-id = 0x69052d06;
+}
+
+static void pxa270_a0_class_init(ObjectClass *klass, void *data)
+{
+ARMCPUClass *k = ARM_CPU_CLASS(klass);
+
+k-id = 0x69054110;
+}
+
+static void pxa270_a1_class_init(ObjectClass *klass, void *data)
+{
+ARMCPUClass *k = ARM_CPU_CLASS(klass);
+
+k-id = 0x69054111;
+}
+
+static void pxa270_b0_class_init(ObjectClass *klass, void *data)
+{
+ARMCPUClass *k = ARM_CPU_CLASS(klass);
+
+k-id = 0x69054112;
+}
+
+static void pxa270_b1_class_init(ObjectClass *klass, void *data)
+{
+ARMCPUClass *k

[Qemu-devel] [PATCH 1/7][RESEND] qom: Introduce object_class_is_abstract()

Since struct TypeImpl is not public, this is useful for enumerating
available types.

Signed-off-by: Andreas Färber afaer...@suse.de
Cc: Anthony Liguori aligu...@us.ibm.com
---
 include/qemu/object.h |8 
 qom/object.c  |5 +
 2 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/include/qemu/object.h b/include/qemu/object.h
index ba37850..8ec45f2 100644
--- a/include/qemu/object.h
+++ b/include/qemu/object.h
@@ -428,6 +428,14 @@ ObjectClass *object_class_dynamic_cast(ObjectClass *klass,
  */
 const char *object_class_get_name(ObjectClass *klass);
 
+/**
+ * object_class_is_abstract:
+ * @klass: The class to obtain the abstractness for.
+ *
+ * Returns: Whether @klass is an abstract class or not.
+ */
+bool object_class_is_abstract(ObjectClass *klass);
+
 ObjectClass *object_class_by_name(const char *typename);
 
 void object_class_foreach(void (*fn)(ObjectClass *klass, void *opaque),
diff --git a/qom/object.c b/qom/object.c
index 57cc592..1821959 100644
--- a/qom/object.c
+++ b/qom/object.c
@@ -451,6 +451,11 @@ const char *object_class_get_name(ObjectClass *klass)
 return klass-type-name;
 }
 
+bool object_class_is_abstract(ObjectClass *klass)
+{
+return klass-type-abstract;
+}
+
 ObjectClass *object_class_by_name(const char *typename)
 {
 TypeImpl *type = type_get_by_name(typename);
-- 
1.7.7

Re: [Qemu-devel] [PATCH] exec-obsolete: fix length handling

On 01/29/2012 03:39 PM, Blue Swirl wrote:
   +++ b/exec-obsolete.h
   @@ -81,11 +81,10 @@ static inline void
   cpu_physical_memory_set_dirty_range(ram_addr_t start,
   int dirty_flags)
{
uint8_t *p;
   -ram_addr_t addr, end;
   +ram_addr_t cur;
  
   -end = start + length;
p = ram_list.phys_dirty + (start  TARGET_PAGE_BITS);
   -for (addr = start; addr = end; addr += TARGET_PAGE_SIZE) {
   +for (cur = 0; cur  length; cur += TARGET_PAGE_SIZE) {
*p++ |= dirty_flags;
}
  
   I think this is still wrong - if length == 2 it will iterate once, but
   we need two iterations if start == 0xfff.
 
  Yes, tricky. We could do something like
  for (cur = start  TARGET_PAGE_MASK; cur  length; cur += 
  TARGET_PAGE_SIZE) {
  but I'll send a new patch with just s/=//.
 
  That's broken too.

 Because length should be adjusted by -1?

0xfff/2 breaks.

More generally, you can't have a loop that just looks at length, since
0/2 wants one iteration, and 0xfff/2 wants two.


  I have:
 
  uint8_t *p;
  ram_addr_t addr, end;
 
  -end = start + length;
  +end = (start + length - 1) | (TARGET_PAGE_SIZE - 1);

 Why  | (TARGET_PAGE_SIZE - 1), for length == 1? 

Yes.  More generally, I wanted something that is easily understood -
start/end addresses without trickery, given all the broken patches for
fixing this.

 TARGET_PAGE_ALIGN()
 could be useful here.

True, I'll respin.

-- 
error compiling committee.c: too many arguments to function

[Qemu-devel] [PATCH] Fix off-by-one in dirty bitmap functions

Reported-by: Stefan Berger stef...@linux.vnet.ibm.com
Signed-off-by: Avi Kivity a...@redhat.com
---
 exec-obsolete.h |   10 ++
 1 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/exec-obsolete.h b/exec-obsolete.h
index 03cf35e..d2749d3 100644
--- a/exec-obsolete.h
+++ b/exec-obsolete.h
@@ -83,9 +83,10 @@ static inline void 
cpu_physical_memory_set_dirty_range(ram_addr_t start,
 uint8_t *p;
 ram_addr_t addr, end;
 
-end = start + length;
+end = TARGET_PAGE_ALIGN(start + length);
+start = TARGET_PAGE_MASK;
 p = ram_list.phys_dirty + (start  TARGET_PAGE_BITS);
-for (addr = start; addr = end; addr += TARGET_PAGE_SIZE) {
+for (addr = start; addr  end; addr += TARGET_PAGE_SIZE) {
 *p++ |= dirty_flags;
 }
 }
@@ -98,10 +99,11 @@ static inline void 
cpu_physical_memory_mask_dirty_range(ram_addr_t start,
 uint8_t *p;
 ram_addr_t addr, end;
 
-end = start + length;
+end = TARGET_PAGE_ALIGN(start + length);
+start = TARGET_PAGE_MASK;
 mask = ~dirty_flags;
 p = ram_list.phys_dirty + (start  TARGET_PAGE_BITS);
-for (addr = start; addr = end; addr += TARGET_PAGE_SIZE) {
+for (addr = start; addr  end; addr += TARGET_PAGE_SIZE) {
 *p++ = mask;
 }
 }
-- 
1.7.7.1

Re: [Qemu-devel] [PATCH] Fix off-by-one in dirty bitmap functions

Thanks, applied.

On Sun, Jan 29, 2012 at 14:47, Avi Kivity a...@redhat.com wrote:
 Reported-by: Stefan Berger stef...@linux.vnet.ibm.com
 Signed-off-by: Avi Kivity a...@redhat.com
 ---
  exec-obsolete.h |   10 ++
  1 files changed, 6 insertions(+), 4 deletions(-)

 diff --git a/exec-obsolete.h b/exec-obsolete.h
 index 03cf35e..d2749d3 100644
 --- a/exec-obsolete.h
 +++ b/exec-obsolete.h
 @@ -83,9 +83,10 @@ static inline void 
 cpu_physical_memory_set_dirty_range(ram_addr_t start,
     uint8_t *p;
     ram_addr_t addr, end;

 -    end = start + length;
 +    end = TARGET_PAGE_ALIGN(start + length);
 +    start = TARGET_PAGE_MASK;
     p = ram_list.phys_dirty + (start  TARGET_PAGE_BITS);
 -    for (addr = start; addr = end; addr += TARGET_PAGE_SIZE) {
 +    for (addr = start; addr  end; addr += TARGET_PAGE_SIZE) {
         *p++ |= dirty_flags;
     }
  }
 @@ -98,10 +99,11 @@ static inline void 
 cpu_physical_memory_mask_dirty_range(ram_addr_t start,
     uint8_t *p;
     ram_addr_t addr, end;

 -    end = start + length;
 +    end = TARGET_PAGE_ALIGN(start + length);
 +    start = TARGET_PAGE_MASK;
     mask = ~dirty_flags;
     p = ram_list.phys_dirty + (start  TARGET_PAGE_BITS);
 -    for (addr = start; addr = end; addr += TARGET_PAGE_SIZE) {
 +    for (addr = start; addr  end; addr += TARGET_PAGE_SIZE) {
         *p++ = mask;
     }
  }
 --
 1.7.7.1

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

On 01/29/2012 02:35 PM, Avi Kivity wrote:
 On 01/29/2012 02:06 PM, Avi Kivity wrote:
  
   Blue posted patches for this.  s/=// is the simplest.
  
 
  Err, not.  I'll just try Blue's patch.
 

 With a fix, migration doesn't complete.  Looking into it.


Turns out the migration problems are unrelated, and are descendents of
the apic merge, so I merged just that.  I'll look at the migration
problems now.

Thanks again!

-- 
error compiling committee.c: too many arguments to function

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

2012-01-29 Thread Grant Likely

On Sun, Jan 29, 2012 at 11:15:42AM +, Paul Brook wrote:
 Clearly we need to have some sort of FDT support.  However I'm unconvinced 
 that it's the correct format for the primary data structure.  For one thing 
 it's a hierarchical tree structure, and in my experience describing links 
 outside that structure gets hairy.  One of the things we're doing with QOM is 
 move from a hierarchical tree/bus to a more general connected web of links 
 between devices.

Okay, well at least let's start with this.  Here is an updated version of the
patch that doesn't touch the board code.  It makes the -dtb option available
to all ARM platforms.

Even if dtb is not the primary structure, we absolutely need this option.
Developers using qemu to simulate real hardware are going to still want
to pass in the exact same .dtb file to qemu as they use for the real target,
and those .dtb files are maintained completely separately from qemu.

g.

---
diff --git a/Makefile.target b/Makefile.target
index 68481a3..5e465ec 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -363,6 +363,7 @@ obj-arm-y += vexpress.o
 obj-arm-y += strongarm.o
 obj-arm-y += collie.o
 obj-arm-y += pl041.o lm4549.o
+obj-arm-$(CONFIG_FDT) += device_tree.o
 
 obj-sh4-y = shix.o r2d.o sh7750.o sh7750_regnames.o tc58128.o
 obj-sh4-y += sh_timer.o sh_serial.o sh_intc.o sh_pci.o sm501.o
diff --git a/configure b/configure
index f69e08f..0c2deab 100755
--- a/configure
+++ b/configure
@@ -3411,6 +3411,9 @@ case $target_arch2 in
 gdb_xml_files=arm-core.xml arm-vfp.xml arm-vfp3.xml arm-neon.xml
 target_phys_bits=32
 target_llong_alignment=4
+if test $fdt = yes ; then
+  target_libs_softmmu=$fdt_libs
+fi
   ;;
   cris)
 target_nptl=yes
diff --git a/hw/arm_boot.c b/hw/arm_boot.c
index 5f163fd..35bfa62 100644
--- a/hw/arm_boot.c
+++ b/hw/arm_boot.c
@@ -7,11 +7,14 @@
  * This code is licensed under the GPL.
  */
 
+#include config.h
 #include hw.h
 #include arm-misc.h
 #include sysemu.h
+#include boards.h
 #include loader.h
 #include elf.h
+#include device_tree.h
 
 #define KERNEL_ARGS_ADDR 0x100
 #define KERNEL_LOAD_ADDR 0x0001
@@ -207,6 +210,66 @@ static void set_kernel_args_old(const struct arm_boot_info 
*info,
 }
 }
 
+static int load_dtb(target_phys_addr_t addr, const struct arm_boot_info *binfo)
+{
+#ifdef CONFIG_FDT
+uint32_t mem_reg_property[] = { cpu_to_be32(binfo-loader_start),
+cpu_to_be32(binfo-ram_size) };
+void *fdt = NULL;
+char *filename;
+int size, rc;
+
+if (!current_dtb_filename)
+return 0;
+
+filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, current_dtb_filename);
+if (!filename) {
+fprintf(stderr, Couldn't open dtb file %s\n, current_dtb_filename);
+return -1;
+}
+
+fdt = load_device_tree(filename, size);
+if (!fdt) {
+fprintf(stderr, Couldn't open dtb file %s\n, filename);
+g_free(filename);
+return -1;
+}
+g_free(filename);
+
+rc = qemu_devtree_setprop(fdt, /memory, reg, mem_reg_property,
+   sizeof(mem_reg_property));
+if (rc  0)
+fprintf(stderr, couldn't set /memory/reg\n);
+
+rc = qemu_devtree_setprop_string(fdt, /chosen, bootargs,
+  binfo-kernel_cmdline);
+if (rc  0)
+fprintf(stderr, couldn't set /chosen/bootargs\n);
+
+if (binfo-initrd_size) {
+rc = qemu_devtree_setprop_cell(fdt, /chosen, linux,initrd-start,
+binfo-loader_start + INITRD_LOAD_ADDR);
+if (rc  0)
+fprintf(stderr, couldn't set /chosen/linux,initrd-start\n);
+
+rc = qemu_devtree_setprop_cell(fdt, /chosen, linux,initrd-end,
+binfo-loader_start +INITRD_LOAD_ADDR +
+binfo-initrd_size);
+if (rc  0)
+fprintf(stderr, couldn't set /chosen/linux,initrd-end\n);
+}
+
+cpu_physical_memory_write (addr, fdt, size);
+
+return 0;
+
+#else
+fprintf(stderr, Platform requested a device tree, 
+but qemu was compiled without fdt support\n);
+return -1;
+#endif
+}
+
 static void do_cpu_reset(void *opaque)
 {
 CPUState *env = opaque;
@@ -221,12 +284,14 @@ static void do_cpu_reset(void *opaque)
 } else {
 if (env == first_cpu) {
 env-regs[15] = info-loader_start;
-if (old_param) {
-set_kernel_args_old(info, info-initrd_size,
+if (!current_dtb_filename) {
+if (old_param) {
+set_kernel_args_old(info, info-initrd_size,
+info-loader_start);
+} else {
+set_kernel_args(info, info-initrd_size,
 info-loader_start);
-} else {
-set_kernel_args(info, info-initrd_size,
-

Re: [Qemu-devel] buildbot failure in qemu on virtfs_x86_64_debian_6_0

2012-01-29 Thread Aneesh Kumar K.V

On Sun, 29 Jan 2012 10:06:58 +0100, q...@buildbot.b1-systems.de wrote:
 The Buildbot has detected a new failure on builder virtfs_x86_64_debian_6_0 
 while building qemu.
 Full details are available at:
  http://buildbot.b1-systems.de/qemu/builders/virtfs_x86_64_debian_6_0/builds/0
 
 Buildbot URL: http://buildbot.b1-systems.de/qemu/
 
 Buildslave for this Build: yuzuki
 
 Build Reason: The Nightly scheduler named 'nightly_virtfs' triggered this 
 build
 Build Source Stamp: [branch for-upstream] HEAD
 Blamelist: 
 
 BUILD FAILED: failed compile
 
 sincerely,
  -The Buildbot
 

I am not sure whether others would be interested in the virtfs build
errors. This is a pre-integration tree so only VirtFS related changes
are pushed to this tree. May be virtfs build errors can only got to
aneesh.ku...@linux.vnet.ibm.com ?


-anesh

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

Am 29.01.2012 17:01, schrieb Grant Likely:
 Okay, well at least let's start with this.  Here is an updated version of the
 patch that doesn't touch the board code.  It makes the -dtb option available
 to all ARM platforms.
 
 Even if dtb is not the primary structure, we absolutely need this option.

Well, the option itself is what has been the most controversial here.
Yours is at least the third attempt, so far we've seen discussed -dtb,
-kern-dtb, -kernel-dtb, -kernel dtb=, etc. Also how to pass around the
data obtained that way - whether as global variable or via struct passed
to machine init or in a few weeks via QOM.

Andreas

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

[Qemu-devel] [PATCH 0/6] VGA patches

Patch 1 has been sent several times, though the logic has been copied
from flawed implementations before.

Other patches should be trivial.

URL git://repo.or.cz/qemu/blueswirl.git
http://repo.or.cz/r/qemu/blueswirl.git

Blue Swirl (6):
  memory: change dirty getting API to take a size
  vga: move Cirrus VGA template to its own file
  Add vga.h unmodified from Linux
  vga.h: remove unused stuff and reformat
  vga: use constants from vga.h
  vga: improve documentation

 arch_init.c  |7 +-
 exec-obsolete.h  |   15 ++-
 hw/cirrus_vga.c  |9 +
 hw/cirrus_vga_template.h |  102 
 hw/framebuffer.c |9 +-
 hw/g364fb.c  |3 +-
 hw/sm501.c   |   11 +-
 hw/tcx.c |   19 +--
 hw/vga.c |  391 +-
 hw/vga.h |  159 +++
 hw/vga_int.h |   16 --
 hw/vga_template.h|   74 +
 memory.c |5 +-
 memory.h |9 +-
 14 files changed, 526 insertions(+), 303 deletions(-)
 create mode 100644 hw/cirrus_vga_template.h
 create mode 100644 hw/vga.h

-- 
1.7.9.rc0

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

2012-01-29 Thread Peter Maydell

On 29 January 2012 16:01, Grant Likely grant.lik...@secretlab.ca wrote:
 On Sun, Jan 29, 2012 at 11:15:42AM +, Paul Brook wrote:
 Clearly we need to have some sort of FDT support.  However I'm unconvinced
 that it's the correct format for the primary data structure.  For one thing
 it's a hierarchical tree structure, and in my experience describing links
 outside that structure gets hairy.  One of the things we're doing with QOM is
 move from a hierarchical tree/bus to a more general connected web of links
 between devices.

 Okay, well at least let's start with this.  Here is an updated version of the
 patch that doesn't touch the board code.  It makes the -dtb option available
 to all ARM platforms.

 Even if dtb is not the primary structure, we absolutely need this option.
 Developers using qemu to simulate real hardware are going to still want
 to pass in the exact same .dtb file to qemu as they use for the real target,
 and those .dtb files are maintained completely separately from qemu.

I agree with Paul that trying to use the dtb as the primary structure
for describing a machine model to qemu is decidedly problematic. Let's
start with the basic we're a bootloader, provide minimal support for
passing in a device tree blob...

Incidentally, it would probably be useful to sort out the problems with
libfdt not being very widely provided (cf previous discussion,
http://lists.gnu.org/archive/html/qemu-devel/2011-10/msg02252.html).
I see Aurelien has suggested a patch to the debian package to provide
it (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=477565) which
ought to help there.

Some more detailed-level code review follows on the assumption that
this patch is a reasonable direction to go in (which it seems like to me).

 diff --git a/Makefile.target b/Makefile.target
 index 68481a3..5e465ec 100644
 --- a/Makefile.target
 +++ b/Makefile.target
 @@ -363,6 +363,7 @@ obj-arm-y += vexpress.o
  obj-arm-y += strongarm.o
  obj-arm-y += collie.o
  obj-arm-y += pl041.o lm4549.o
 +obj-arm-$(CONFIG_FDT) += device_tree.o

  obj-sh4-y = shix.o r2d.o sh7750.o sh7750_regnames.o tc58128.o
  obj-sh4-y += sh_timer.o sh_serial.o sh_intc.o sh_pci.o sm501.o
 diff --git a/configure b/configure
 index f69e08f..0c2deab 100755
 --- a/configure
 +++ b/configure
 @@ -3411,6 +3411,9 @@ case $target_arch2 in
     gdb_xml_files=arm-core.xml arm-vfp.xml arm-vfp3.xml arm-neon.xml
     target_phys_bits=32
     target_llong_alignment=4
 +    if test $fdt = yes ; then
 +      target_libs_softmmu=$fdt_libs
 +    fi

This doesn't need to be conditional -- compare the similar stanzas
for other fdt-using architectures.

   ;;
   cris)
     target_nptl=yes
 diff --git a/hw/arm_boot.c b/hw/arm_boot.c
 index 5f163fd..35bfa62 100644
 --- a/hw/arm_boot.c
 +++ b/hw/arm_boot.c
 @@ -7,11 +7,14 @@
  * This code is licensed under the GPL.
  */

 +#include config.h
  #include hw.h
  #include arm-misc.h
  #include sysemu.h
 +#include boards.h
  #include loader.h
  #include elf.h
 +#include device_tree.h

  #define KERNEL_ARGS_ADDR 0x100
  #define KERNEL_LOAD_ADDR 0x0001
 @@ -207,6 +210,66 @@ static void set_kernel_args_old(const struct 
 arm_boot_info *info,
     }
  }

 +static int load_dtb(target_phys_addr_t addr, const struct arm_boot_info 
 *binfo)
 +{
 +#ifdef CONFIG_FDT
 +    uint32_t mem_reg_property[] = { cpu_to_be32(binfo-loader_start),
 +                                    cpu_to_be32(binfo-ram_size) };
 +    void *fdt = NULL;
 +    char *filename;
 +    int size, rc;
 +
 +    if (!current_dtb_filename)
 +        return 0;

scripts/checkpatch.pl complains about this and other style issues...

 +
 +    filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, current_dtb_filename);
 +    if (!filename) {
 +        fprintf(stderr, Couldn't open dtb file %s\n, current_dtb_filename);
 +        return -1;
 +    }
 +
 +    fdt = load_device_tree(filename, size);
 +    if (!fdt) {
 +        fprintf(stderr, Couldn't open dtb file %s\n, filename);
 +        g_free(filename);
 +        return -1;
 +    }
 +    g_free(filename);
 +
 +    rc = qemu_devtree_setprop(fdt, /memory, reg, mem_reg_property,
 +                               sizeof(mem_reg_property));
 +    if (rc  0)
 +        fprintf(stderr, couldn't set /memory/reg\n);
 +
 +    rc = qemu_devtree_setprop_string(fdt, /chosen, bootargs,
 +                                      binfo-kernel_cmdline);
 +    if (rc  0)
 +        fprintf(stderr, couldn't set /chosen/bootargs\n);

This seems kind of weird -- if you're not trying to use 'rc' as
a running something failed flag to return to the caller then
why not just have if (function()  0) { fprintf(...); } ?

 +
 +    if (binfo-initrd_size) {
 +        rc = qemu_devtree_setprop_cell(fdt, /chosen, linux,initrd-start,
 +                binfo-loader_start + INITRD_LOAD_ADDR);
 +        if (rc  0)
 +            fprintf(stderr, couldn't set /chosen/linux,initrd-start\n);
 +
 +        rc = qemu_devtree_setprop_cell(fdt, /chosen, linux,initrd-end,
 +

[Qemu-devel] [PATCH 1/6] memory: change dirty getting API to take a size

Instead of each device knowing or guessing the guest page size,
just pass the desired size of dirtied memory area.

Signed-off-by: Blue Swirl blauwir...@gmail.com
---
 arch_init.c  |7 ---
 exec-obsolete.h  |   15 +--
 hw/framebuffer.c |9 +
 hw/g364fb.c  |3 ++-
 hw/sm501.c   |   11 ---
 hw/tcx.c |   19 +--
 hw/vga.c |   17 +
 memory.c |5 +++--
 memory.h |9 +
 9 files changed, 46 insertions(+), 49 deletions(-)

diff --git a/arch_init.c b/arch_init.c
index 2366511..699bdd1 100644
--- a/arch_init.c
+++ b/arch_init.c
@@ -141,7 +141,8 @@ static int ram_save_block(QEMUFile *f)

 do {
 mr = block-mr;
-if (memory_region_get_dirty(mr, offset, DIRTY_MEMORY_MIGRATION)) {
+if (memory_region_get_dirty(mr, offset, TARGET_PAGE_SIZE,
+DIRTY_MEMORY_MIGRATION)) {
 uint8_t *p;
 int cont = (block == last_block) ? RAM_SAVE_FLAG_CONTINUE : 0;

@@ -198,7 +199,7 @@ static ram_addr_t ram_save_remaining(void)
 QLIST_FOREACH(block, ram_list.blocks, next) {
 ram_addr_t addr;
 for (addr = 0; addr  block-length; addr += TARGET_PAGE_SIZE) {
-if (memory_region_get_dirty(block-mr, addr,
+if (memory_region_get_dirty(block-mr, addr, TARGET_PAGE_SIZE,
 DIRTY_MEMORY_MIGRATION)) {
 count++;
 }
@@ -283,7 +284,7 @@ int ram_save_live(Monitor *mon, QEMUFile *f, int
stage, void *opaque)
 /* Make sure all dirty bits are set */
 QLIST_FOREACH(block, ram_list.blocks, next) {
 for (addr = 0; addr  block-length; addr += TARGET_PAGE_SIZE) {
-if (!memory_region_get_dirty(block-mr, addr,
+if (!memory_region_get_dirty(block-mr, addr, TARGET_PAGE_SIZE,
  DIRTY_MEMORY_MIGRATION)) {
 memory_region_set_dirty(block-mr, addr, TARGET_PAGE_SIZE);
 }
diff --git a/exec-obsolete.h b/exec-obsolete.h
index d2749d3..94c23d0 100644
--- a/exec-obsolete.h
+++ b/exec-obsolete.h
@@ -59,10 +59,21 @@ static inline int
cpu_physical_memory_get_dirty_flags(ram_addr_t addr)
 return ram_list.phys_dirty[addr  TARGET_PAGE_BITS];
 }

-static inline int cpu_physical_memory_get_dirty(ram_addr_t addr,
+static inline int cpu_physical_memory_get_dirty(ram_addr_t start,
+ram_addr_t length,
 int dirty_flags)
 {
-return ram_list.phys_dirty[addr  TARGET_PAGE_BITS]  dirty_flags;
+int ret = 0;
+uint8_t *p;
+ram_addr_t addr, end;
+
+end = TARGET_PAGE_ALIGN(start + length);
+start = TARGET_PAGE_MASK;
+p = ram_list.phys_dirty + (start  TARGET_PAGE_BITS);
+for (addr = start; addr  end; addr += TARGET_PAGE_SIZE) {
+ret |= *p++  dirty_flags;
+}
+return ret;
 }

 static inline void cpu_physical_memory_set_dirty(ram_addr_t addr)
diff --git a/hw/framebuffer.c b/hw/framebuffer.c
index 6bf48dc..ea122fb 100644
--- a/hw/framebuffer.c
+++ b/hw/framebuffer.c
@@ -87,15 +87,8 @@ void framebuffer_update_display(
 dest += i * dest_row_pitch;

 for (; i  rows; i++) {
-target_phys_addr_t dirty_offset;
-dirty = 0;
-dirty_offset = 0;
-while (addr + dirty_offset  TARGET_PAGE_ALIGN(addr + src_width)) {
-dirty |= memory_region_get_dirty(mem, addr + dirty_offset,
+dirty = memory_region_get_dirty(mem, addr, addr + src_width,
  DIRTY_MEMORY_VGA);
-dirty_offset += TARGET_PAGE_SIZE;
-}
-
 if (dirty || invalidate) {
 fn(opaque, dest, src, cols, dest_col_pitch);
 if (first == -1)
diff --git a/hw/g364fb.c b/hw/g364fb.c
index 82b31f7..fa25033 100644
--- a/hw/g364fb.c
+++ b/hw/g364fb.c
@@ -62,7 +62,8 @@ typedef struct G364State {

 static inline int check_dirty(G364State *s, ram_addr_t page)
 {
-return memory_region_get_dirty(s-mem_vram, page, DIRTY_MEMORY_VGA);
+return memory_region_get_dirty(s-mem_vram, page, G364_PAGE_SIZE,
+   DIRTY_MEMORY_VGA);
 }

 static inline void reset_dirty(G364State *s,
diff --git a/hw/sm501.c b/hw/sm501.c
index 09c5894..94c0abf 100644
--- a/hw/sm501.c
+++ b/hw/sm501.c
@@ -1323,15 +1323,12 @@ static void sm501_draw_crt(SM501State * s)
 for (y = 0; y  height; y++) {
int update_hwc = draw_hwc_line ? within_hwc_y_range(s, y, 1) : 0;
int update = full_update || update_hwc;
-   ram_addr_t page0 = offset  TARGET_PAGE_MASK;
-   ram_addr_t page1 = (offset + width * src_bpp - 1)  TARGET_PAGE_MASK;
-   ram_addr_t page;
+ram_addr_t page0 = offset;
+ram_addr_t page1 = offset + width * src_bpp - 1;

/* check dirty flags for each line */
-   for (page =

[Qemu-devel] [PATCH 2/6] vga: move Cirrus VGA template to its own file

Standard VGA does not use vga_draw_cursor_line_* functions.
Move the template to cirrus_vga_template.h.

Signed-off-by: Blue Swirl blauwir...@gmail.com
---
 hw/cirrus_vga.c  |9 
 hw/cirrus_vga_template.h |  102 ++
 hw/vga_int.h |   13 --
 hw/vga_template.h|   66 -
 4 files changed, 111 insertions(+), 79 deletions(-)
 create mode 100644 hw/cirrus_vga_template.h

diff --git a/hw/cirrus_vga.c b/hw/cirrus_vga.c
index c203080..457518b 100644
--- a/hw/cirrus_vga.c
+++ b/hw/cirrus_vga.c
@@ -2164,6 +2164,15 @@ static void cirrus_cursor_invalidate(VGACommonState *s1)
 }
 }

+#define DEPTH 8
+#include cirrus_vga_template.h
+
+#define DEPTH 16
+#include cirrus_vga_template.h
+
+#define DEPTH 32
+#include cirrus_vga_template.h
+
 static void cirrus_cursor_draw_line(VGACommonState *s1, uint8_t *d1, int scr_y)
 {
 CirrusVGAState *s = container_of(s1, CirrusVGAState, vga);
diff --git a/hw/cirrus_vga_template.h b/hw/cirrus_vga_template.h
new file mode 100644
index 000..3b28280
--- /dev/null
+++ b/hw/cirrus_vga_template.h
@@ -0,0 +1,102 @@
+/*
+ * QEMU Cirrus VGA Emulator templates
+ *
+ * Copyright (c) 2003 Fabrice Bellard
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the
Software), to deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
ARISING FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+#if DEPTH == 8
+#define BPP 1
+#elif DEPTH == 15 || DEPTH == 16
+#define BPP 2
+#elif DEPTH == 32
+#define BPP 4
+#else
+#error unsupported depth
+#endif
+
+static void glue(vga_draw_cursor_line_, DEPTH)(uint8_t *d1,
+   const uint8_t *src1,
+   int poffset, int w,
+   unsigned int color0,
+   unsigned int color1,
+   unsigned int color_xor)
+{
+const uint8_t *plane0, *plane1;
+int x, b0, b1;
+uint8_t *d;
+
+d = d1;
+plane0 = src1;
+plane1 = src1 + poffset;
+for (x = 0; x  w; x++) {
+b0 = (plane0[x  3]  (7 - (x  7)))  1;
+b1 = (plane1[x  3]  (7 - (x  7)))  1;
+#if DEPTH == 8
+switch (b0 | (b1  1)) {
+case 0:
+break;
+case 1:
+d[0] ^= color_xor;
+break;
+case 2:
+d[0] = color0;
+break;
+case 3:
+d[0] = color1;
+break;
+}
+#elif DEPTH == 16
+switch (b0 | (b1  1)) {
+case 0:
+break;
+case 1:
+((uint16_t *)d)[0] ^= color_xor;
+break;
+case 2:
+((uint16_t *)d)[0] = color0;
+break;
+case 3:
+((uint16_t *)d)[0] = color1;
+break;
+}
+#elif DEPTH == 32
+switch (b0 | (b1  1)) {
+case 0:
+break;
+case 1:
+((uint32_t *)d)[0] ^= color_xor;
+break;
+case 2:
+((uint32_t *)d)[0] = color0;
+break;
+case 3:
+((uint32_t *)d)[0] = color1;
+break;
+}
+#else
+#error unsupported depth
+#endif
+d += BPP;
+}
+}
+
+#undef DEPTH
+#undef BPP
diff --git a/hw/vga_int.h b/hw/vga_int.h
index c1e700f..f755582 100644
--- a/hw/vga_int.h
+++ b/hw/vga_int.h
@@ -205,19 +205,6 @@ void vga_mem_writeb(VGACommonState *s,
target_phys_addr_t addr, uint32_t val);
 void vga_invalidate_scanlines(VGACommonState *s, int y1, int y2);
 int ppm_save(const char *filename, struct DisplaySurface *ds);

-void vga_draw_cursor_line_8(uint8_t *d1, const uint8_t *src1,
-int poffset, int w,
-unsigned int color0, unsigned int color1,
-unsigned int color_xor);
-void vga_draw_cursor_line_16(uint8_t *d1, const uint8_t *src1,
- int poffset, int w,
- unsigned int color0,

[Qemu-devel] [PATCH 3/6] Add vga.h unmodified from Linux

Signed-off-by: Blue Swirl blauwir...@gmail.com
---
 hw/vga.h |  481 ++
 1 files changed, 481 insertions(+), 0 deletions(-)
 create mode 100644 hw/vga.h

diff --git a/hw/vga.h b/hw/vga.h
new file mode 100644
index 000..2b8691f
--- /dev/null
+++ b/hw/vga.h
@@ -0,0 +1,481 @@
+/*
+ * linux/include/video/vga.h -- standard VGA chipset interaction
+ *
+ * Copyright 1999 Jeff Garzik jgar...@pobox.com
+ *
+ * Copyright history from vga16fb.c:
+ * Copyright 1999 Ben Pfaff and Petr Vandrovec
+ * Based on VGA info at http://www.osdever.net/FreeVGA/home.htm
+ * Based on VESA framebuffer (c) 1998 Gerd Knorr
+ *
+ * This file is subject to the terms and conditions of the GNU General
+ * Public License.  See the file COPYING in the main directory of this
+ * archive for more details.
+ *
+ */
+
+#ifndef __linux_video_vga_h__
+#define __linux_video_vga_h__
+
+#include linux/types.h
+#include asm/io.h
+#ifndef CONFIG_AMIGA
+#include asm/vga.h
+#else
+/*
+ * FIXME
+ * Ugh, we don't have PCI space, so map readb() and friends to use Zorro space
+ * for MMIO accesses. This should make cirrusfb work again on Amiga
+ */
+#undef inb_p
+#undef inw_p
+#undef outb_p
+#undef outw
+#undef readb
+#undef writeb
+#undef writew
+#define inb_p(port)0
+#define inw_p(port)0
+#define outb_p(port, val)  do { } while (0)
+#define outw(port, val)do { } while (0)
+#define readb  z_readb
+#define writeb z_writeb
+#define writew z_writew
+#endif
+#include asm/byteorder.h
+
+
+/* Some of the code below is taken from SVGAlib.  The original,
+   unmodified copyright notice for that code is below. */
+/* VGAlib version 1.2 - (c) 1993 Tommy Frandsen*/
+/* */
+/* This library is free software; you can redistribute it and/or   */
+/* modify it without any restrictions. This library is distributed */
+/* in the hope that it will be useful, but without any warranty.   */
+
+/* Multi-chipset support Copyright 1993 Harm Hanemaayer */
+/* partially copyrighted (C) 1993 by Hartmut Schirmer */
+
+/* VGA data register ports */
+#define VGA_CRT_DC 0x3D5   /* CRT Controller Data Register - color 
emulation */
+#define VGA_CRT_DM 0x3B5   /* CRT Controller Data Register - mono 
emulation */
+#define VGA_ATT_R  0x3C1   /* Attribute Controller Data Read Register */
+#define VGA_ATT_W  0x3C0   /* Attribute Controller Data Write Register */
+#define VGA_GFX_D  0x3CF   /* Graphics Controller Data Register */
+#define VGA_SEQ_D  0x3C5   /* Sequencer Data Register */
+#define VGA_MIS_R  0x3CC   /* Misc Output Read Register */
+#define VGA_MIS_W  0x3C2   /* Misc Output Write Register */
+#define VGA_FTC_R  0x3CA   /* Feature Control Read Register */
+#define VGA_IS1_RC 0x3DA   /* Input Status Register 1 - color emulation */
+#define VGA_IS1_RM 0x3BA   /* Input Status Register 1 - mono emulation */
+#define VGA_PEL_D  0x3C9   /* PEL Data Register */
+#define VGA_PEL_MSK0x3C6   /* PEL mask register */
+
+/* EGA-specific registers */
+#define EGA_GFX_E0 0x3CC   /* Graphics enable processor 0 */
+#define EGA_GFX_E1 0x3CA   /* Graphics enable processor 1 */
+
+/* VGA index register ports */
+#define VGA_CRT_IC 0x3D4   /* CRT Controller Index - color emulation */
+#define VGA_CRT_IM 0x3B4   /* CRT Controller Index - mono emulation */
+#define VGA_ATT_IW 0x3C0   /* Attribute Controller Index  Data Write
Register */
+#define VGA_GFX_I  0x3CE   /* Graphics Controller Index */
+#define VGA_SEQ_I  0x3C4   /* Sequencer Index */
+#define VGA_PEL_IW 0x3C8   /* PEL Write Index */
+#define VGA_PEL_IR 0x3C7   /* PEL Read Index */
+
+/* standard VGA indexes max counts */
+#define VGA_CRT_C  0x19/* Number of CRT Controller Registers */
+#define VGA_ATT_C  0x15/* Number of Attribute Controller Registers */
+#define VGA_GFX_C  0x09/* Number of Graphics Controller Registers */
+#define VGA_SEQ_C  0x05/* Number of Sequencer Registers */
+#define VGA_MIS_C  0x01/* Number of Misc Output Register */
+
+/* VGA misc register bit masks */
+#define VGA_MIS_COLOR  0x01
+#define VGA_MIS_ENB_MEM_ACCESS 0x02
+#define VGA_MIS_DCLK_28322_720 0x04
+#define VGA_MIS_ENB_PLL_LOAD   (0x04 | 0x08)
+#define VGA_MIS_SEL_HIGH_PAGE  0x20
+
+/* VGA CRT controller register indices */
+#define VGA_CRTC_H_TOTAL   0
+#define VGA_CRTC_H_DISP1
+#define VGA_CRTC_H_BLANK_START 2
+#define VGA_CRTC_H_BLANK_END   3
+#define VGA_CRTC_H_SYNC_START  4
+#define VGA_CRTC_H_SYNC_END5
+#define VGA_CRTC_V_TOTAL   6
+#define VGA_CRTC_OVERFLOW  7
+#define VGA_CRTC_PRESET_ROW8
+#define VGA_CRTC_MAX_SCAN  9
+#define VGA_CRTC_CURSOR_START  0x0A
+#define VGA_CRTC_CURSOR_END0x0B
+#define VGA_CRTC_START_HI  0x0C
+#define VGA_CRTC_START_LO  0x0D
+#define

[Qemu-devel] [PATCH 4/6] vga.h: remove unused stuff and reformat

Signed-off-by: Blue Swirl blauwir...@gmail.com
---
 hw/vga.h |  534 +-
 1 files changed, 106 insertions(+), 428 deletions(-)

diff --git a/hw/vga.h b/hw/vga.h
index 2b8691f..d917046 100644
--- a/hw/vga.h
+++ b/hw/vga.h
@@ -2,49 +2,21 @@
  * linux/include/video/vga.h -- standard VGA chipset interaction
  *
  * Copyright 1999 Jeff Garzik jgar...@pobox.com
- *
+ *
  * Copyright history from vga16fb.c:
  * Copyright 1999 Ben Pfaff and Petr Vandrovec
- * Based on VGA info at http://www.osdever.net/FreeVGA/home.htm
+ * Based on VGA info at http://www.osdever.net/FreeVGA/home.htm
  * Based on VESA framebuffer (c) 1998 Gerd Knorr
  *
  * This file is subject to the terms and conditions of the GNU General
  * Public License.  See the file COPYING in the main directory of this
- * archive for more details.
+ * archive for more details.
  *
  */

 #ifndef __linux_video_vga_h__
 #define __linux_video_vga_h__

-#include linux/types.h
-#include asm/io.h
-#ifndef CONFIG_AMIGA
-#include asm/vga.h
-#else
-/*
- * FIXME
- * Ugh, we don't have PCI space, so map readb() and friends to use Zorro space
- * for MMIO accesses. This should make cirrusfb work again on Amiga
- */
-#undef inb_p
-#undef inw_p
-#undef outb_p
-#undef outw
-#undef readb
-#undef writeb
-#undef writew
-#define inb_p(port)0
-#define inw_p(port)0
-#define outb_p(port, val)  do { } while (0)
-#define outw(port, val)do { } while (0)
-#define readb  z_readb
-#define writeb z_writeb
-#define writew z_writew
-#endif
-#include asm/byteorder.h
-
-
 /* Some of the code below is taken from SVGAlib.  The original,
unmodified copyright notice for that code is below. */
 /* VGAlib version 1.2 - (c) 1993 Tommy Frandsen*/
@@ -57,425 +29,131 @@
 /* partially copyrighted (C) 1993 by Hartmut Schirmer */

 /* VGA data register ports */
-#define VGA_CRT_DC 0x3D5   /* CRT Controller Data Register - color 
emulation */
-#define VGA_CRT_DM 0x3B5   /* CRT Controller Data Register - mono 
emulation */
-#define VGA_ATT_R  0x3C1   /* Attribute Controller Data Read Register */
-#define VGA_ATT_W  0x3C0   /* Attribute Controller Data Write Register */
-#define VGA_GFX_D  0x3CF   /* Graphics Controller Data Register */
-#define VGA_SEQ_D  0x3C5   /* Sequencer Data Register */
-#define VGA_MIS_R  0x3CC   /* Misc Output Read Register */
-#define VGA_MIS_W  0x3C2   /* Misc Output Write Register */
-#define VGA_FTC_R  0x3CA   /* Feature Control Read Register */
-#define VGA_IS1_RC 0x3DA   /* Input Status Register 1 - color emulation */
-#define VGA_IS1_RM 0x3BA   /* Input Status Register 1 - mono emulation */
-#define VGA_PEL_D  0x3C9   /* PEL Data Register */
-#define VGA_PEL_MSK0x3C6   /* PEL mask register */
+#define VGA_CRT_DC  0x3D5   /* CRT Controller Data Register -
color emulation */
+#define VGA_CRT_DM  0x3B5   /* CRT Controller Data Register -
mono emulation */
+#define VGA_ATT_R   0x3C1   /* Attribute Controller Data Read Register */
+#define VGA_ATT_W   0x3C0   /* Attribute Controller Data Write Register */
+#define VGA_GFX_D   0x3CF   /* Graphics Controller Data Register */
+#define VGA_SEQ_D   0x3C5   /* Sequencer Data Register */
+#define VGA_MIS_R   0x3CC   /* Misc Output Read Register */
+#define VGA_MIS_W   0x3C2   /* Misc Output Write Register */
+#define VGA_FTC_R   0x3CA   /* Feature Control Read Register */
+#define VGA_IS1_RC  0x3DA   /* Input Status Register 1 - color emulation */
+#define VGA_IS1_RM  0x3BA   /* Input Status Register 1 - mono emulation */
+#define VGA_PEL_D   0x3C9   /* PEL Data Register */
+#define VGA_PEL_MSK 0x3C6   /* PEL mask register */

 /* EGA-specific registers */
-#define EGA_GFX_E0 0x3CC   /* Graphics enable processor 0 */
-#define EGA_GFX_E1 0x3CA   /* Graphics enable processor 1 */
+#define EGA_GFX_E0  0x3CC   /* Graphics enable processor 0 */
+#define EGA_GFX_E1  0x3CA   /* Graphics enable processor 1 */

 /* VGA index register ports */
-#define VGA_CRT_IC 0x3D4   /* CRT Controller Index - color emulation */
-#define VGA_CRT_IM 0x3B4   /* CRT Controller Index - mono emulation */
-#define VGA_ATT_IW 0x3C0   /* Attribute Controller Index  Data Write
Register */
-#define VGA_GFX_I  0x3CE   /* Graphics Controller Index */
-#define VGA_SEQ_I  0x3C4   /* Sequencer Index */
-#define VGA_PEL_IW 0x3C8   /* PEL Write Index */
-#define VGA_PEL_IR 0x3C7   /* PEL Read Index */
+#define VGA_CRT_IC  0x3D4   /* CRT Controller Index - color emulation */
+#define VGA_CRT_IM  0x3B4   /* CRT Controller Index - mono emulation */
+#define VGA_ATT_IW  0x3C0   /* Attribute Controller Index  Data
Write Register */
+#define VGA_GFX_I   0x3CE   /* Graphics Controller Index */
+#define VGA_SEQ_I   0x3C4   /* Sequencer Index */
+#define VGA_PEL_IW

[Qemu-devel] [PATCH 6/6] vga: improve documentation

Add links to chipset docs and FreeVGA site.

Signed-off-by: Blue Swirl blauwir...@gmail.com
---
 hw/vga.c |   12 
 1 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/hw/vga.c b/hw/vga.c
index 758bd92..d87c4f9 100644
--- a/hw/vga.c
+++ b/hw/vga.c
@@ -37,6 +37,18 @@

 //#define DEBUG_BOCHS_VBE

+/*
+ * Video Graphics Array (VGA)
+ *
+ * Chipset docs for original IBM VGA:
+ * http://www.mcamafia.de/pdf/ibm_vgaxga_trm2.pdf
+ *
+ * FreeVGA site:
+ * http://www.osdever.net/FreeVGA/home.htm
+ *
+ * Standard VGA features and Bochs VBE extensions are implemented.
+ */
+
 /* force some bits to zero */
 const uint8_t sr_mask[8] = {
 0x03,
-- 
1.7.9.rc0
From 99cbc90531365c11ec9fb374ebe0281925632736 Mon Sep 17 00:00:00 2001
Message-Id: 99cbc90531365c11ec9fb374ebe0281925632736.1327864041.git.blauwir...@gmail.com
In-Reply-To: 423f585cc5456c32fd49cf649825fa061dd898bd.1327864041.git.blauwir...@gmail.com
References: 423f585cc5456c32fd49cf649825fa061dd898bd.1327864041.git.blauwir...@gmail.com
From: Blue Swirl blauwir...@gmail.com
Date: Sun, 29 Jan 2012 17:29:12 +
Subject: [PATCH 6/6] vga: improve documentation

Add links to chipset docs and FreeVGA site.

Signed-off-by: Blue Swirl blauwir...@gmail.com
---
 hw/vga.c |   12 
 1 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/hw/vga.c b/hw/vga.c
index 758bd92..d87c4f9 100644
--- a/hw/vga.c
+++ b/hw/vga.c
@@ -37,6 +37,18 @@
 
 //#define DEBUG_BOCHS_VBE
 
+/*
+ * Video Graphics Array (VGA)
+ *
+ * Chipset docs for original IBM VGA:
+ * http://www.mcamafia.de/pdf/ibm_vgaxga_trm2.pdf
+ *
+ * FreeVGA site:
+ * http://www.osdever.net/FreeVGA/home.htm
+ *
+ * Standard VGA features and Bochs VBE extensions are implemented.
+ */
+
 /* force some bits to zero */
 const uint8_t sr_mask[8] = {
 0x03,
-- 
1.7.2.5

Re: [Qemu-devel] longjmp in qemu

2012-01-29 Thread Xin Tong

anyone cares to answer. I appreciate it.

Thanks

Xin


On Sat, Jan 28, 2012 at 5:17 PM, Xin Tong xerox.time.t...@gmail.com wrote:
 I am investigating what longjmp is used for in qemu.

 longjmp is used in a couple of places.

 1.
  void cpu_loop_exit(void)
 {
     env-current_tb = NULL;
     longjmp(env-jmp_env, 1);
 }

 cpu_loop_exit is called when there is an interrupt_request or exit_request
 pending

 2.
 void cpu_resume_from_signal(CPUState *env1, void *puc)
 {
    ...
    longjmp(env-jmp_env, 1);
 }

 cpu_resume_from_signal is called in a couple of places, each of which
 suggests something faulty has happened. my guess is that it will get call
 when exceptions have occurred in the code cache. Am I right ?


 Thanks


 Xin

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

2012-01-29 Thread Edgar E. Iglesias

On Sat, Jan 28, 2012 at 11:48:37AM -0700, Grant Likely wrote:
 On Fri, Jan 27, 2012 at 10:34:01PM +, Paul Brook wrote:
   If compiled with CONFIG_FDT, allow user to specify a device tree file 
   using
   the -dtb argument.  If the machine supports it then the dtb will be loaded
   into memory and passed to the kernel on boot.
  
  Adding annother machine feels wrong. Why does the board specific code need 
  to 
  know about this at all? You already going it via a global variable, so 
  can't 
  this be entirely contained within arm_boot.c?
 
 Mostly because the infrastructure isn't yet in place to pass the .dtb file
 through to the arm_boot code (or maybe it is; what is the best way to pass
 command line data through to the arm_boot.c code (or similar for other
 architectures)?
 
  If the board file is involved, why is it asking the user?
 
 There is a lot of configuration in the .dts file that the QEMU user may want
 to manipulate; particularly when using QEMU for testing embedded platforms.
 The direction I want to go is to select the machine model based on the top
 level DT compatible property (making -M optional), and then also allow a lot
 of the machine layout to be driven by DT data.  ie. populate emulated devices
 from DT data.
 
 I believe this is how Edgar is using the microblaze model, but I don't
 think those patches have been upstreamed yet.  I hope that microblaze,
 ARM and powerpc can all use the same model here.

Yes, that's right.

  
   +versatile_init(ram_size,
   +   boot_device,
   +   kernel_filename, kernel_cmdline,
   +   initrd_filename, cpu_model, 0x);
  
  This only works because we're currently too dumb to emulate the differences 
  between the two board variants.
 
 Yeah, this is a hack so I could play with forcing the machine id.
 I'll remove it.
 
  What we probably want to be doing is shipping/constructing device trees for 
  the boards we implement, with an option to turn this on/off.  Requiring a 
  user 
  to invent their own seems deeply sub-optimal given we know exactly what 
  hardware we're emulating.  A user that needs to provide their own FDT seems 
  like a fairly rare corner case.
 
 I disagree.  QEMU may want to ship stock .dts files, but it will
 absolutely be a common use case for embedded developers to pass in
 their own .dtb file.

  This gets slightly more interesting when you have custom machine variants 
  (i.e. once we fix the object model, and have proper dynamic machine 
  construction).  Even then I'd expect the FDT to be derived from/specificed 
  by 
  the machine description, not a separate option.
 
 I started with going down that route, but switched to this model after
 playing with it and noticing that it doesn't seem to fit as well for
 embedded development as providing a .dtb file and having QEMU
 construct a machine that matches the data.

That's the way I see it too. Our use-case is to build the virtual machine
from the dtb. We then run the exact same software that runs on real hw.
I don't know the details on how practical dtb's are for describing more
complex bus hierarchies, maybe Peter has more info on that.

Cheers,
Edgar

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

2012-01-29 Thread Peter Maydell

On 29 January 2012 18:48, Andreas Färber afaer...@suse.de wrote:
 Am 29.01.2012 17:01, schrieb Grant Likely:
 Okay, well at least let's start with this.  Here is an updated version of the
 patch that doesn't touch the board code.  It makes the -dtb option available
 to all ARM platforms.

 Even if dtb is not the primary structure, we absolutely need this option.

 Well, the option itself is what has been the most controversial here.
 Yours is at least the third attempt, so far we've seen discussed -dtb,
 -kern-dtb, -kernel-dtb, -kernel dtb=, etc.

FWIW, my vote is for '-dtb' because it parallels the existing -initrd
and -append. (Or -devicetree if we think -dtb is too cryptic; but anyway
not something with 'kernel' in it.)

-- PMM

[Qemu-devel] [PATCH RFC 8/7] target-arm: Use IoC for CPU init

Instead of having each CPU's class_init function call its parent's
function, indirect this through arm_cpu_class_init().

Signed-off-by: Andreas Färber afaer...@suse.de
---
 target-arm/cpu-core.c |   10 +-
 1 files changed, 9 insertions(+), 1 deletions(-)

diff --git a/target-arm/cpu-core.c b/target-arm/cpu-core.c
index b1ac22c..cdd049e 100644
--- a/target-arm/cpu-core.c
+++ b/target-arm/cpu-core.c
@@ -246,6 +246,13 @@ static void arm_cpu_realize(Object *obj)
 cpu-env.cp15.c0_cpuid = cpu_class-id;
 }
 
+static void arm_cpu_class_init(ObjectClass *klass, void *data)
+{
+const struct ARMCPUDef *d = data;
+
+(*d-class_init)(klass, NULL);
+}
+
 static void cpu_register(const struct ARMCPUDef *def)
 {
 TypeInfo type = {
@@ -254,7 +261,8 @@ static void cpu_register(const struct ARMCPUDef *def)
 .instance_size = sizeof(ARMCPU),
 .instance_init = arm_cpu_realize,
 .class_size = sizeof(ARMCPUClass),
-.class_init = def-class_init,
+.class_init = arm_cpu_class_init,
+.class_data = (void *)def,
 };
 
 type_register_static(type);
-- 
1.7.7

[Qemu-devel] [PATCH RFC 9/7] target-arm: Move CPU feature flags to class

The internal CPU feature flags were only ever set in
cpu_reset_model_id(). Therefore move them into ARMCPUClass.

The feature flags were saved and loaded as part of CPUState. Keep
writing them so that they can still be loaded in older versions, but
ignore when loading.

Since cpu.h defines ARMCPUState, which has been incorporated into
ARMCPU, and tries to use arm_feature() in cpu_get_tb_cpu_state(),
move arm_feature() to cpu-core.h and add a forward declaration.

Signed-off-by: Andreas Färber afaer...@suse.de
Cc: Peter Maydell peter.mayd...@linaro.org
---
 target-arm/cpu-core.c |  135 +
 target-arm/cpu-core.h |9 +++
 target-arm/cpu.h  |9 +---
 target-arm/helper.c   |   95 --
 target-arm/machine.c  |6 ++-
 5 files changed, 150 insertions(+), 104 deletions(-)

diff --git a/target-arm/cpu-core.c b/target-arm/cpu-core.c
index cdd049e..15b710b 100644
--- a/target-arm/cpu-core.c
+++ b/target-arm/cpu-core.c
@@ -10,6 +10,16 @@
 #include cpu-core.h
 #include qemu-common.h
 
+static inline void set_feature(ARMCPUClass *klass, int feature)
+{
+klass-features |= 1u  feature;
+}
+
+static inline int has_feature(ARMCPUClass *klass, int feature)
+{
+return (klass-features  (1u  feature)) != 0;
+}
+
 /* CPU models */
 
 static void arm926_class_init(ObjectClass *klass, void *data)
@@ -17,6 +27,8 @@ static void arm926_class_init(ObjectClass *klass, void *data)
 ARMCPUClass *k = ARM_CPU_CLASS(klass);
 
 k-id = 0x41069265;
+set_feature(k, ARM_FEATURE_V5);
+set_feature(k, ARM_FEATURE_VFP);
 }
 
 static void arm946_class_init(ObjectClass *klass, void *data)
@@ -24,6 +36,8 @@ static void arm946_class_init(ObjectClass *klass, void *data)
 ARMCPUClass *k = ARM_CPU_CLASS(klass);
 
 k-id = 0x41059461;
+set_feature(k, ARM_FEATURE_V5);
+set_feature(k, ARM_FEATURE_MPU);
 }
 
 static void arm1026_class_init(ObjectClass *klass, void *data)
@@ -31,6 +45,9 @@ static void arm1026_class_init(ObjectClass *klass, void *data)
 ARMCPUClass *k = ARM_CPU_CLASS(klass);
 
 k-id = 0x4106a262;
+set_feature(k, ARM_FEATURE_V5);
+set_feature(k, ARM_FEATURE_VFP);
+set_feature(k, ARM_FEATURE_AUXCR);
 }
 
 static void arm1136_r0_class_init(ObjectClass *klass, void *data)
@@ -38,13 +55,18 @@ static void arm1136_r0_class_init(ObjectClass *klass, void 
*data)
 ARMCPUClass *k = ARM_CPU_CLASS(klass);
 
 k-id = 0x4107b362;
+set_feature(k, ARM_FEATURE_V6);
+set_feature(k, ARM_FEATURE_VFP);
 }
 
 static void arm1136_r1_class_init(ObjectClass *klass, void *data)
 {
 ARMCPUClass *k = ARM_CPU_CLASS(klass);
 
+arm1136_r0_class_init(klass, data);
+
 k-id = 0x4117b363;
+set_feature(k, ARM_FEATURE_V6K);
 }
 
 static void arm1176_class_init(ObjectClass *klass, void *data)
@@ -52,6 +74,9 @@ static void arm1176_class_init(ObjectClass *klass, void *data)
 ARMCPUClass *k = ARM_CPU_CLASS(klass);
 
 k-id = 0x410fb767;
+set_feature(k, ARM_FEATURE_V6K);
+set_feature(k, ARM_FEATURE_VFP);
+set_feature(k, ARM_FEATURE_VAPA);
 }
 
 static void arm11mpcore_class_init(ObjectClass *klass, void *data)
@@ -59,6 +84,9 @@ static void arm11mpcore_class_init(ObjectClass *klass, void 
*data)
 ARMCPUClass *k = ARM_CPU_CLASS(klass);
 
 k-id = 0x410fb022;
+set_feature(k, ARM_FEATURE_V6K);
+set_feature(k, ARM_FEATURE_VFP);
+set_feature(k, ARM_FEATURE_VAPA);
 }
 
 static void cortex_m3_class_init(ObjectClass *klass, void *data)
@@ -66,6 +94,8 @@ static void cortex_m3_class_init(ObjectClass *klass, void 
*data)
 ARMCPUClass *k = ARM_CPU_CLASS(klass);
 
 k-id = 0x410fc231;
+set_feature(k, ARM_FEATURE_V7);
+set_feature(k, ARM_FEATURE_M);
 }
 
 static void cortex_a8_class_init(ObjectClass *klass, void *data)
@@ -73,6 +103,10 @@ static void cortex_a8_class_init(ObjectClass *klass, void 
*data)
 ARMCPUClass *k = ARM_CPU_CLASS(klass);
 
 k-id = 0x410fc080;
+set_feature(k, ARM_FEATURE_V7);
+set_feature(k, ARM_FEATURE_VFP3);
+set_feature(k, ARM_FEATURE_NEON);
+set_feature(k, ARM_FEATURE_THUMB2EE);
 }
 
 static void cortex_a9_class_init(ObjectClass *klass, void *data)
@@ -80,6 +114,16 @@ static void cortex_a9_class_init(ObjectClass *klass, void 
*data)
 ARMCPUClass *k = ARM_CPU_CLASS(klass);
 
 k-id = 0x410fc090;
+set_feature(k, ARM_FEATURE_V7);
+set_feature(k, ARM_FEATURE_VFP3);
+set_feature(k, ARM_FEATURE_VFP_FP16);
+set_feature(k, ARM_FEATURE_NEON);
+set_feature(k, ARM_FEATURE_THUMB2EE);
+/* Note that A9 supports the MP extensions even for
+ * A9UP and single-core A9MP (which are both different
+ * and valid configurations; we don't model A9UP).
+ */
+set_feature(k, ARM_FEATURE_V7MP);
 }
 
 static void cortex_a15_class_init(ObjectClass *klass, void *data)
@@ -87,6 +131,14 @@ static void cortex_a15_class_init(ObjectClass *klass, void 
*data)
 ARMCPUClass *k = ARM_CPU_CLASS(klass);
 
 k-id

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

2012-01-29 Thread Peter Crosthwaite

On Mon, Jan 30, 2012 at 6:42 AM, Edgar E. Iglesias edgar.igles...@gmail.com
 wrote:

 On Sat, Jan 28, 2012 at 11:48:37AM -0700, Grant Likely wrote:
  On Fri, Jan 27, 2012 at 10:34:01PM +, Paul Brook wrote:
If compiled with CONFIG_FDT, allow user to specify a device tree
 file using
the -dtb argument.  If the machine supports it then the dtb will be
 loaded
into memory and passed to the kernel on boot.
  
   Adding annother machine feels wrong. Why does the board specific code
 need to
   know about this at all? You already going it via a global variable, so
 can't
   this be entirely contained within arm_boot.c?
 
  Mostly because the infrastructure isn't yet in place to pass the .dtb
 file
  through to the arm_boot code (or maybe it is; what is the best way to
 pass
  command line data through to the arm_boot.c code (or similar for other
  architectures)?
 
   If the board file is involved, why is it asking the user?
 
  There is a lot of configuration in the .dts file that the QEMU user may
 want
  to manipulate; particularly when using QEMU for testing embedded
 platforms.
  The direction I want to go is to select the machine model based on the
 top
  level DT compatible property (making -M optional), and then also allow a
 lot
  of the machine layout to be driven by DT data.  ie. populate emulated
 devices
  from DT data.
 
  I believe this is how Edgar is using the microblaze model, but I don't
  think those patches have been upstreamed yet.  I hope that microblaze,
  ARM and powerpc can all use the same model here.

 Yes, that's right.

  
+versatile_init(ram_size,
+   boot_device,
+   kernel_filename, kernel_cmdline,
+   initrd_filename, cpu_model, 0x);
  
   This only works because we're currently too dumb to emulate the
 differences
   between the two board variants.
 
  Yeah, this is a hack so I could play with forcing the machine id.
  I'll remove it.
 
   What we probably want to be doing is shipping/constructing device
 trees for
   the boards we implement, with an option to turn this on/off.
  Requiring a user
   to invent their own seems deeply sub-optimal given we know exactly what
   hardware we're emulating.  A user that needs to provide their own FDT
 seems
   like a fairly rare corner case.


  I disagree.  QEMU may want to ship stock .dts files, but it will
  absolutely be a common use case for embedded developers to pass in
  their own .dtb file.
 
   This gets slightly more interesting when you have custom machine
 variants
   (i.e. once we fix the object model, and have proper dynamic machine
   construction).  Even then I'd expect the FDT to be derived
 from/specificed by
   the machine description, not a separate option.


  I started with going down that route, but switched to this model after
  playing with it and noticing that it doesn't seem to fit as well for
  embedded development as providing a .dtb file and having QEMU
  construct a machine that matches the data.


Another major issue with that is DTBs have little bits of software in them
as well, such as the chosen node, which would need to be populated before
passing off to software. Coding these dtb properties into machine models
would be sub-optimal, you would need some way of parameterizing certain dtb
properties at boot time. The easiest approach to this is just passing in
your own dtb file.


 That's the way I see it too. Our use-case is to build the virtual machine
 from the dtb. We then run the exact same software that runs on real hw.
 I don't know the details on how practical dtb's are for describing more
 complex bus hierarchies, maybe Peter has more info on that.

 Dtbs are capable of describing pretty much anything you want, the main
issue is ambiguity on how the dts data structure is used to describe
complex or irregular bus heirachies. Im our approach, device models
themselves describe how dts syntax is interpreted wrt to machine creation.
This means different device models can interpret dts node handles or
subnode relationships in any arbitrary way, which would proivde you a
backend with which you could implement complex bus heirachies. For example,
a device tree node with compatibility simple-bus will instantiate all its
subnodes as elements on the parent bus (or system bus in the case of the
dtb root node). There is however a software hook which would allow you to
implement more complex behaviours such as address range remapping for bus
bridges (based on the ranges property). We didnt do this, as the memory API
wasnt adequate at the time, but recent updates would now make this
possible. As another example, a USB controller could interpret its children
as USB devices and create the corresponding USB device model interconnects.
We successfully prototyped this idea out of tree for SPI busses, but the
mechanism is there to do USB, PCI, SD and the other usual suspects. Just
needs to be implemented and the framework

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

On Mon, Jan 30, 2012 at 5:13 AM, Peter Maydell peter.mayd...@linaro.org wrote:
 On 29 January 2012 16:01, Grant Likely grant.lik...@secretlab.ca wrote:
 On Sun, Jan 29, 2012 at 11:15:42AM +, Paul Brook wrote:
 Clearly we need to have some sort of FDT support.  However I'm unconvinced
 that it's the correct format for the primary data structure.  For one thing
 it's a hierarchical tree structure, and in my experience describing links
 outside that structure gets hairy.  One of the things we're doing with QOM 
 is
 move from a hierarchical tree/bus to a more general connected web of links
 between devices.

 Okay, well at least let's start with this.  Here is an updated version of the
 patch that doesn't touch the board code.  It makes the -dtb option available
 to all ARM platforms.

 Even if dtb is not the primary structure, we absolutely need this option.
 Developers using qemu to simulate real hardware are going to still want
 to pass in the exact same .dtb file to qemu as they use for the real target,
 and those .dtb files are maintained completely separately from qemu.

 I agree with Paul that trying to use the dtb as the primary structure
 for describing a machine model to qemu is decidedly problematic. Let's
 start with the basic we're a bootloader, provide minimal support for
 passing in a device tree blob...

We've never advocated DTB as primary structure, but rather just one
very useful, simple and generic approach.

Among the the sea of fixed machine models that is QEMU today, having a
DTB-driven machine in there would be an excellent proving ground for
QOM conversion and steps towards fully data driven machines which
should be the ultimate objective anyway.

As Peter C says elsewhere in this thread, through its link syntax
foo=ref you can describe any sort of topology you like in a device
tree.

Regards,

John
-- 
John Williams, PhD, B. Eng, B. IT
PetaLogix - Linux Solutions for a Reconfigurable World
w: www.petalogix.com  p: +61-7-30090663  f: +61-7-30090663

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

On Sun, Jan 29, 2012 at 4:51 PM, Peter Crosthwaite
peter.crosthwa...@petalogix.com wrote:
 Hi All,

 So on the topic of these command line arguments for initrd, dtb and friends,
 another related issue we have encountered (and have hacked around in our
 tree) is not being able to relocate the initrd or kernel. Currently these
 memory locations are hardcoded in arm_boot.c:

 #define KERNEL_ARGS_ADDR 0x100
 #define KERNEL_LOAD_ADDR 0x0001
 #define INITRD_LOAD_ADDR 0x00d0

 If you see patch 6/7 in this same series I put in place a hack to override
 the initrd location in memory, but I wonder if instead this should go up to
 the command line interface as a parameter. Currently the machine model (or
 arm_boot.c) defines exactly where kernels/initrds/command-line-args line in
 memory, but since these are software properties should perhaps they go up to
 the command line as -kernel,foo=bar options? E.G:

 qemu-system-arm
 -kernel,kernel-image=/foo/zImage,kernel-addr=0x0001,initrd=/foo/initrd,initrd_addr=0x00d0

There's an opportunity here - QEMU needs the cmdline ability to load
random binaries/elfs anyway, such as

--load file@address

e.g. --load image.bin@0xa400

-- load file.elf

(no address required)

This option or one like it would make it much easier and less
hard-coded to assemble any sort of initial memory state.

Extending this, kernels, initrds and DTBs all can have
machine-specific preferred addresses but can be overriden in the same
way:

--kernel zImage@0x2000 --initrd fs.img@0x4000

and so on

The '@' symbol will need to be escaped by it's a pretty natural syntax.

John
-- 
John Williams, PhD, B. Eng, B. IT
PetaLogix - Linux Solutions for a Reconfigurable World
w: www.petalogix.com  p: +61-7-30090663  f: +61-7-30090663

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

On Mon, Jan 30, 2012 at 10:28 AM, John Williams
john.willi...@petalogix.com wrote:
On Sun, Jan 29, 2012 at 4:51 PM, Peter Crosthwaite
peter.crosthwa...@petalogix.com wrote:
Hi All,

So on the topic of these command line arguments for initrd, dtb and friends,
another related issue we have encountered (and have hacked around in our
tree) is not being able to relocate the initrd or kernel. Currently these
memory locations are hardcoded in arm_boot.c:

#define KERNEL_ARGS_ADDR 0x100
#define KERNEL_LOAD_ADDR 0x0001
#define INITRD_LOAD_ADDR 0x00d0

If you see patch 6/7 in this same series I put in place a hack to override
the initrd location in memory, but I wonder if instead this should go up to
the command line interface as a parameter. Currently the machine model (or
arm_boot.c) defines exactly where kernels/initrds/command-line-args line in
memory, but since these are software properties should perhaps they go up to
the command line as -kernel,foo=bar options? E.G:

qemu-system-arm
-kernel,kernel-image=/foo/zImage,kernel-addr=0x0001,initrd=/foo/initrd,initrd_addr=0x00d0

There's an opportunity here - QEMU needs the cmdline ability to load
random binaries/elfs anyway, such as

--load file@address

e.g. --load image.bin@0xa400

And while we're at it how about overriding arbitrary boot PC addresses as well?

--boot-addr 0xdeadbeef

It should be possible to boot random bootrom code in QEMU without
hacking on the machine model.

qemu-system-arm -M foo --file bootrom.bin@0x00 --boot-addr 0x1000

We bumped into this recently - we need a cleaner way of telling QEMU
if it's pretending to be just the machine with some minimal initial
state as above(for running bootloaders, baremetal etc), or it's being
the machine *plus* a bootloader (booting vmlinux/zimage).

Currently it's pretty hacky.

John

-- load file.elf

(no address required)

This option or one like it would make it much easier and less
hard-coded to assemble any sort of initial memory state.

Extending this, kernels, initrds and DTBs all can have
machine-specific preferred addresses but can be overriden in the same
way:

--kernel zImage@0x2000 --initrd fs.img@0x4000

and so on

The '@' symbol will need to be escaped by it's a pretty natural syntax.

John
--
John Williams, PhD, B. Eng, B. IT
PetaLogix - Linux Solutions for a Reconfigurable World
w: www.petalogix.com p: +61-7-30090663 f: +61-7-30090663

--
John Williams, PhD, B. Eng, B. IT
PetaLogix - Linux Solutions for a Reconfigurable World
w: www.petalogix.com p: +61-7-30090663 f: +61-7-30090663

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


On 01/24/2012 12:23 PM, Stefan Weil wrote:

Am 24.01.2012 08:22, schrieb Andreas Färber:

Am 23.01.2012 08:20, schrieb Peter A. G. Crosthwaite:

Added linux specific kernel dtb option. This option can be specified to inject
an argument device tree blob (dtb) into linux.

Signed-off-by: Peter A. G. Crosthwaite peter.crosthwa...@petalogix.com
---
qemu-options.hx | 3 +++
vl.c | 4 
2 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/qemu-options.hx b/qemu-options.hx
index 6295cde..43cddff 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -1931,6 +1931,9 @@ ETEXI

DEF(kernel, HAS_ARG, QEMU_OPTION_kernel, \
-kernel bzImage use 'bzImage' as kernel image\n, QEMU_ARCH_ALL)
+DEF(kern-dtb, HAS_ARG, QEMU_OPTION_kerndtb, \
+ -kern-dtb dtb device tree blob passed to kernel boot\n, QEMU_ARCH_ALL)


We should probably call it -kernel-dtb. If there's some strncmp() from
-kernel interfering, we should fix that instead.

I don't see this variable being used anywhere in this series though.
Would it have been in the missing zynq machine of 7/7?

Andreas


I'd prefer a different solution. As far as I have understood,
the dtb is only useful with a kernel, so it could be handled
as an optional attribute to the -kernel parameter:

-kernel IMAGE[,dtb=DTB]


If it looks like a device, acts like a device, and smells like a device...

The best thing to do here is to make an arm-kernel-loader device that hangs off 
of sysbus and takes four string properties.


I was going to do this shortly for PC anyway.

BTW, for unknown command line options, we should probably assume they are 
-device and treat accordingly.  So -arm-kernel-loader 
dtb=DTB,kernel=/path/to/vmlinux would Just Work.


Regards,

Anthony Liguori



Of course the same applies to -append, but that's a different issue.

Regards,
Stefan

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


On 01/29/2012 06:28 PM, John Williams wrote:

On Sun, Jan 29, 2012 at 4:51 PM, Peter Crosthwaite
peter.crosthwa...@petalogix.com  wrote:

Hi All,

So on the topic of these command line arguments for initrd, dtb and friends,
another related issue we have encountered (and have hacked around in our
tree) is not being able to relocate the initrd or kernel. Currently these
memory locations are hardcoded in arm_boot.c:

#define KERNEL_ARGS_ADDR 0x100
#define KERNEL_LOAD_ADDR 0x0001
#define INITRD_LOAD_ADDR 0x00d0

If you see patch 6/7 in this same series I put in place a hack to override
the initrd location in memory, but I wonder if instead this should go up to
the command line interface as a parameter. Currently the machine model (or
arm_boot.c) defines exactly where kernels/initrds/command-line-args line in
memory, but since these are software properties should perhaps they go up to
the command line as -kernel,foo=bar options? E.G:

qemu-system-arm
-kernel,kernel-image=/foo/zImage,kernel-addr=0x0001,initrd=/foo/initrd,initrd_addr=0x00d0


There's an opportunity here - QEMU needs the cmdline ability to load
random binaries/elfs anyway, such as

--load file@address


Make an elf loader device if you desire this ability but I'm skeptical that it 
really is all that useful.


No special syntax though, we have a way to parameterize options as Markus 
rightly points out.


Regards,

Anthony Liguori



e.g. --load image.bin@0xa400

-- load file.elf

(no address required)

This option or one like it would make it much easier and less
hard-coded to assemble any sort of initial memory state.

Extending this, kernels, initrds and DTBs all can have
machine-specific preferred addresses but can be overriden in the same
way:

--kernel zImage@0x2000 --initrd fs.img@0x4000

and so on

The '@' symbol will need to be escaped by it's a pretty natural syntax.

John

Re: [Qemu-devel] [PATCH RFC 4/7] qom: Introduce CPU class


On 01/29/2012 07:25 AM, Andreas Färber wrote:

It's abstract, derived directly from TYPE_OBJECT (to avoid dependency
on MODULE_INIT_DEVICE) and for now is empty.

Place it in hw/. Have user emulators pick it up via VPATH, building it
per target since they didn't use any qdev/QOM devices so far.

Introduce processor_init() for registering, and call module init as
needed.

Signed-off-by: Andreas Färberafaer...@suse.de
Cc: Anthony Liguorialigu...@us.ibm.com
---
  Makefile.objs  |1 +
  Makefile.target|9 ++---
  arch_init.c|1 +
  bsd-user/main.c|1 +
  darwin-user/main.c |1 +
  hw/cpu.c   |   27 +++
  include/qemu/cpu.h |   27 +++
  linux-user/main.c  |1 +
  module.h   |2 ++
  9 files changed, 67 insertions(+), 3 deletions(-)
  create mode 100644 hw/cpu.c
  create mode 100644 include/qemu/cpu.h

diff --git a/Makefile.objs b/Makefile.objs
index b942625..a4b20fa 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -189,6 +189,7 @@ user-obj-y += $(trace-obj-y)

  hw-obj-y =
  hw-obj-y += vl.o loader.o
+hw-obj-y += cpu.o
  hw-obj-$(CONFIG_VIRTIO) += virtio-console.o
  hw-obj-y += usb-libhw.o
  hw-obj-$(CONFIG_VIRTIO_PCI) += virtio-pci.o
diff --git a/Makefile.target b/Makefile.target
index d1b7867..5d3470e 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -107,7 +107,7 @@ signal.o: QEMU_CFLAGS += $(HELPER_CFLAGS)

  ifdef CONFIG_LINUX_USER

-$(call set-vpath, 
$(SRC_PATH)/linux-user:$(SRC_PATH)/linux-user/$(TARGET_ABI_DIR))
+$(call set-vpath, 
$(SRC_PATH)/linux-user:$(SRC_PATH)/linux-user/$(TARGET_ABI_DIR):$(SRC_PATH)/hw)

  QEMU_CFLAGS+=-I$(SRC_PATH)/linux-user/$(TARGET_ABI_DIR) 
-I$(SRC_PATH)/linux-user
  obj-y = main.o syscall.o strace.o mmap.o signal.o thunk.o \
@@ -130,6 +130,7 @@ obj-m68k-y += m68k-sim.o m68k-semi.o
  $(obj-y) $(obj-$(TARGET_BASE_ARCH)-y): $(GENERATED_HEADERS)

  obj-y += module.o
+obj-y += cpu.o
  obj-y += $(addprefix ../qom/, $(qom-y))
  obj-y += $(addprefix ../libuser/, $(user-obj-y))
  obj-y += $(addprefix ../libdis-user/, $(libdis-y))
@@ -142,7 +143,7 @@ endif #CONFIG_LINUX_USER

  ifdef CONFIG_DARWIN_USER

-$(call set-vpath, $(SRC_PATH)/darwin-user)
+$(call set-vpath, $(SRC_PATH)/darwin-user:$(SRC_PATH)/hw)

  QEMU_CFLAGS+=-I$(SRC_PATH)/darwin-user 
-I$(SRC_PATH)/darwin-user/$(TARGET_ARCH)

@@ -159,6 +160,7 @@ obj-i386-y += ioport-user.o
  $(obj-y) $(obj-$(TARGET_BASE_ARCH)-y): $(GENERATED_HEADERS)

  obj-y += module.o
+obj-y += cpu.o
  obj-y += $(addprefix ../qom/, $(qom-y))
  obj-y += $(addprefix ../libuser/, $(user-obj-y))
  obj-y += $(addprefix ../libdis-user/, $(libdis-y))
@@ -171,7 +173,7 @@ endif #CONFIG_DARWIN_USER

  ifdef CONFIG_BSD_USER

-$(call set-vpath, $(SRC_PATH)/bsd-user)
+$(call set-vpath, $(SRC_PATH)/bsd-user:$(SRC_PATH)/hw)

  QEMU_CFLAGS+=-I$(SRC_PATH)/bsd-user -I$(SRC_PATH)/bsd-user/$(TARGET_ARCH)

@@ -183,6 +185,7 @@ obj-i386-y += ioport-user.o
  $(obj-y) $(obj-$(TARGET_BASE_ARCH)-y): $(GENERATED_HEADERS)

  obj-y += module.o
+obj-y += cpu.o
  obj-y += $(addprefix ../qom/, $(qom-y))
  obj-y += $(addprefix ../libuser/, $(user-obj-y))
  obj-y += $(addprefix ../libdis-user/, $(libdis-y))
diff --git a/arch_init.c b/arch_init.c
index 2366511..c0d5f4f 100644
--- a/arch_init.c
+++ b/arch_init.c
@@ -692,6 +692,7 @@ void do_smbios_option(const char *optarg)

  void cpudef_init(void)
  {
+module_call_init(MODULE_INIT_CPU);
  #if defined(cpudef_setup)
  cpudef_setup(); /* parse cpu definitions in target config file */
  #endif
diff --git a/bsd-user/main.c b/bsd-user/main.c
index 2ff0361..70e1146 100644
--- a/bsd-user/main.c
+++ b/bsd-user/main.c
@@ -761,6 +761,7 @@ int main(int argc, char **argv)
  }

  cpu_model = NULL;
+module_call_init(MODULE_INIT_CPU);
  #if defined(cpudef_setup)
  cpudef_setup(); /* parse cpu definitions in target config file (TBD) */
  #endif
diff --git a/darwin-user/main.c b/darwin-user/main.c
index a4c630d..d065f00 100644
--- a/darwin-user/main.c
+++ b/darwin-user/main.c
@@ -751,6 +751,7 @@ int main(int argc, char **argv)
  usage();

  module_call_init(MODULE_INIT_EARLY);
+module_call_init(MODULE_INIT_CPU);

  optind = 1;
  for(;;) {
diff --git a/hw/cpu.c b/hw/cpu.c
new file mode 100644
index 000..c0e9cfa
--- /dev/null
+++ b/hw/cpu.c
@@ -0,0 +1,27 @@
+/*
+ * QEMU CPU model
+ *
+ * Copyright (c) 2012 SUSE LINUX Products GmbH
+ *
+ * Licensed under the terms of the GNU GPL version 2
+ * or (at your option) any later version.
+ */
+
+#include qemu/object.h
+#include qemu/cpu.h
+#include qemu-common.h
+
+static TypeInfo cpu_type_info = {
+.name = TYPE_CPU,
+.parent = TYPE_OBJECT,
+.instance_size = sizeof(CPU),



Probably want to do CPUState or something of that nature so that you can use 
CPU() as a dynamic_cast macro.


BTW, if the class_size == parent.class_size you don't need to define or specific 
the class.


Regards,

Anthony Liguori


+.abstract = true,
+

Re: [Qemu-devel] [PATCH RFC 5/7] cpu: Introduce cpu_class_foreach()


On 01/29/2012 07:25 AM, Andreas Färber wrote:

Provides an easy way to loop over all non-abstract CPU classes.

Signed-off-by: Andreas Färberafaer...@suse.de


I have a patch in my next series which provides an interface for this.

https://github.com/aliguori/qemu/commit/42ab3f78477307438591c77816f06f12cf9d9fc0

I'll post a proper version tomorrow.

Regards,

Anthony Liguori


---
  hw/cpu.c   |   25 +
  include/qemu/cpu.h |9 +
  2 files changed, 34 insertions(+), 0 deletions(-)

diff --git a/hw/cpu.c b/hw/cpu.c
index c0e9cfa..ac0add7 100644
--- a/hw/cpu.c
+++ b/hw/cpu.c
@@ -11,6 +11,31 @@
  #include qemu/cpu.h
  #include qemu-common.h

+struct CPUListData {
+void (*fn)(ObjectClass *klass, void *opaque);
+void *opaque;
+};
+
+static void cpu_class_foreach_tramp(ObjectClass *klass, void *opaque)
+{
+struct CPUListData *s = opaque;
+
+if (!object_class_is_abstract(klass)
+object_class_dynamic_cast(klass, TYPE_CPU) != NULL) {
+s-fn(klass, s-opaque);
+}
+}
+
+void cpu_class_foreach(void (*fn)(ObjectClass *klass, void *opaque),
+   void *opaque)
+{
+struct CPUListData s = {
+.fn = fn,
+.opaque = opaque,
+};
+object_class_foreach(cpu_class_foreach_tramp,s);
+}
+
  static TypeInfo cpu_type_info = {
  .name = TYPE_CPU,
  .parent = TYPE_OBJECT,
diff --git a/include/qemu/cpu.h b/include/qemu/cpu.h
index 4b81f3b..d06c87e 100644
--- a/include/qemu/cpu.h
+++ b/include/qemu/cpu.h
@@ -24,4 +24,13 @@ typedef struct CPU {
  } CPU;


+/**
+ * cpu_class_foreach:
+ * @fn: Callback function called for each non-abstract CPU type.
+ * @opaque: Opaque data passed through to the callback function.
+ */
+void cpu_class_foreach(void (*fn)(ObjectClass *klass, void *opaque),
+   void *opaque);
+
+
  #endif

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

On Mon, Jan 30, 2012 at 12:11 PM, Anthony Liguori anth...@codemonkey.ws wrote:
 On 01/29/2012 06:28 PM, John Williams wrote:

 On Sun, Jan 29, 2012 at 4:51 PM, Peter Crosthwaite
 peter.crosthwa...@petalogix.com  wrote:

 Hi All,

 So on the topic of these command line arguments for initrd, dtb and
 friends,
 another related issue we have encountered (and have hacked around in our
 tree) is not being able to relocate the initrd or kernel. Currently these
 memory locations are hardcoded in arm_boot.c:

 #define KERNEL_ARGS_ADDR 0x100
 #define KERNEL_LOAD_ADDR 0x0001
 #define INITRD_LOAD_ADDR 0x00d0

 If you see patch 6/7 in this same series I put in place a hack to
 override
 the initrd location in memory, but I wonder if instead this should go up
 to
 the command line interface as a parameter. Currently the machine model
 (or
 arm_boot.c) defines exactly where kernels/initrds/command-line-args line
 in
 memory, but since these are software properties should perhaps they go up
 to
 the command line as -kernel,foo=bar options? E.G:

 qemu-system-arm

 -kernel,kernel-image=/foo/zImage,kernel-addr=0x0001,initrd=/foo/initrd,initrd_addr=0x00d0


 There's an opportunity here - QEMU needs the cmdline ability to load
 random binaries/elfs anyway, such as

 --load file@address


 Make an elf loader device if you desire this ability but I'm skeptical that
 it really is all that useful.

It is useful for non-Linux use-cases, of which there are many!

Can you explain how you'd see such a 'loader device' in practice?  How
does it get bound into the machine model?  How do we pass arguments to
it?

Thanks,

John
-- 
John Williams, PhD, B. Eng, B. IT
PetaLogix - Linux Solutions for a Reconfigurable World
w: www.petalogix.com  p: +61-7-30090663  f: +61-7-30090663

Re: [Qemu-devel] [PATCH RFC 6/7] target-arm: Introduce QOM CPU and use for it CPUID lookup


On 01/29/2012 07:25 AM, Andreas Färber wrote:

Create a CPU subclass, and register classes matching all CPU models.
Don't name the file target-arm/cpu.c so that the user emulators can
still easily pick up the base class in hw/cpu.c via VPATH.

Make arm_cpu_list() enumerate CPU subclasses.

Replace cpu_arm_find_by_name()'s string -  CPUID lookup by storing the
CPUID in the class.
NB: CPUIDs were first introduced by Paul Brook in r1765 (2006).

Signed-off-by: Andreas Färberafaer...@suse.de
Cc: Anthony Liguorialigu...@us.ibm.com
Cc: Paul Brookp...@codesourcery.com
Cc: Peter Maydellpeter.mayd...@linaro.org
---
  Makefile.target   |1 +
  target-arm/cpu-core.c |  268 +
  target-arm/cpu-core.h |   33 ++
  target-arm/helper.c   |   80 ---
  4 files changed, 324 insertions(+), 58 deletions(-)
  create mode 100644 target-arm/cpu-core.c
  create mode 100644 target-arm/cpu-core.h

diff --git a/Makefile.target b/Makefile.target
index 5d3470e..96043c4 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -80,6 +80,7 @@ endif
  libobj-$(TARGET_SPARC64) += vis_helper.o
  libobj-$(CONFIG_NEED_MMU) += mmu.o
  libobj-$(TARGET_ARM) += neon_helper.o iwmmxt_helper.o
+libobj-$(TARGET_ARM) += cpu-core.o
  ifeq ($(TARGET_BASE_ARCH), sparc)
  libobj-y += fop_helper.o cc_helper.o win_helper.o mmu_helper.o ldst_helper.o
  libobj-y += cpu_init.o
diff --git a/target-arm/cpu-core.c b/target-arm/cpu-core.c
new file mode 100644
index 000..9761d8e
--- /dev/null
+++ b/target-arm/cpu-core.c
@@ -0,0 +1,268 @@
+/*
+ * QEMU ARM CPU core
+ *
+ * Copyright (c) 2012 SUSE LINUX Products GmbH
+ *
+ * Licensed under the terms of the GNU GPL version 2
+ * or (at your option) any later version.
+ */
+
+#include cpu-core.h
+#include qemu-common.h
+
+/* CPU models */
+
+static void arm926_class_init(ObjectClass *klass, void *data)
+{
+ARMCPUClass *k = ARM_CPU_CLASS(klass);
+
+k-id = 0x41069265;
+}
+
+static void arm946_class_init(ObjectClass *klass, void *data)
+{
+ARMCPUClass *k = ARM_CPU_CLASS(klass);
+
+k-id = 0x41059461;
+}


In a situation like this, you probably want to make use of the class_data field 
in TypeInfo.  You can use that to create a bunch of types based on a table.


Take a look at hw/eepro100.c for an example of this (although read the comment 
for the reference to class_data and why we can't use it until after the next 
series).


Regards,

Anthony Liguori

Re: [Qemu-devel] [PATCH RFC 7/7] target-arm: Embed CPUARMState in QOM ARMCPU


On 01/29/2012 07:25 AM, Andreas Färber wrote:

We g_malloc0()'ed CPUARMState ourself, and exec.c's cpu_copy() runs
through cpu_init() as well, so we are at liberty to supply the CPUState
any way we see fit. Having CPUARMState as field in the QOM CPU allows
both to access env from an ARMCPU object and to access the QOM Object
and its ObjectClass from an env pointer, in ARM code for now.

The goal is to convert all CPUs to QOM and to use CPU objects in central
places, especially once we have property support for Object.
This will then allow to have TCG AREG0 point to target-specific fields
where small immediate offsets are desired (as pointed out by rth) while
allowing for common fields at known offsets from the base class.

Having the CPUID in ARMCPUClass, we can set it from the realize function.
Same for cpu_model_str, which is now the QOM class name.

Signed-off-by: Andreas Färberafaer...@suse.de
Cc: Anthony Liguorialigu...@us.ibm.com
Cc: Paul Brookp...@codesourcery.com
Cc: Peter Maydellpeter.mayd...@linaro.org
Cc: Richard Hendersonr...@twiddle.net
---
  target-arm/cpu-core.c |   13 +
  target-arm/cpu-core.h |7 +++
  target-arm/helper.c   |   13 ++---
  3 files changed, 26 insertions(+), 7 deletions(-)

diff --git a/target-arm/cpu-core.c b/target-arm/cpu-core.c
index 9761d8e..b1ac22c 100644
--- a/target-arm/cpu-core.c
+++ b/target-arm/cpu-core.c
@@ -234,12 +234,25 @@ static const struct ARMCPUDef arm_cpu_models[] = {
  { }
  };

+static void arm_cpu_realize(Object *obj)
+{
+ARMCPU *cpu = ARM_CPU(obj);
+ARMCPUClass *cpu_class = ARM_CPU_GET_CLASS(obj);
+
+memset(cpu-env, 0, sizeof(CPUARMState));
+cpu_exec_init(cpu-env);
+
+cpu-env.cpu_model_str = object_get_typename(obj);
+cpu-env.cp15.c0_cpuid = cpu_class-id;
+}
+
  static void cpu_register(const struct ARMCPUDef *def)
  {
  TypeInfo type = {
  .name = def-name,
  .parent = TYPE_ARM_CPU,
  .instance_size = sizeof(ARMCPU),
+.instance_init = arm_cpu_realize,



The convention I'm using is: instance_init = type_name_initfn.

DeviceState::init = type_name_realize,

Eventually, realized will become a property and there will be a realize and 
unrealize method.



  .class_size = sizeof(ARMCPUClass),
  .class_init = def-class_init,
  };
diff --git a/target-arm/cpu-core.h b/target-arm/cpu-core.h
index be4bbc3..08b6b2b 100644
--- a/target-arm/cpu-core.h
+++ b/target-arm/cpu-core.h
@@ -10,6 +10,7 @@
  #define QEMU_ARM_CPU_CORE_H

  #include qemu/cpu.h
+#include cpu.h

  #define TYPE_ARM_CPU arm-cpu-core
  #define ARM_CPU_CLASS(klass) \
@@ -27,7 +28,13 @@ typedef struct ARMCPUClass {

  typedef struct ARMCPU {
  CPU parent_obj;
+
+/* TODO Inline this and split off common state */
+CPUARMState env;


This is an interesting (and good) idea.  I think this could make it fairly easy 
to qomify things.



  } ARMCPU;

+#define ENV_GET_OBJECT(e) \
+(Object *)((void *)(e) - offsetof(ARMCPU, env))


sizeof(CPU) should be sizeof(void *).  Presumably it's okay to add 8 bytes to 
the beginning of CPUState?


If so, that would make things much nicer from a QOM perspective.

Regards,

Anthony Liguori



  #endif
diff --git a/target-arm/helper.c b/target-arm/helper.c
index ece9635..1ffd7ba 100644
--- a/target-arm/helper.c
+++ b/target-arm/helper.c
@@ -400,7 +400,7 @@ static int vfp_gdb_set_reg(CPUState *env, uint8_t *buf, int 
reg)
  CPUARMState *cpu_arm_init(const char *cpu_model)
  {
  ObjectClass *klass;
-ARMCPUClass *cpu_class;
+ARMCPU *cpu;
  CPUARMState *env;
  static int inited = 0;

@@ -408,16 +408,14 @@ CPUARMState *cpu_arm_init(const char *cpu_model)
  if (klass == NULL) {
  return NULL;
  }
-cpu_class = ARM_CPU_CLASS(klass);
-env = g_malloc0(sizeof(CPUARMState));
-cpu_exec_init(env);
+cpu = ARM_CPU(object_new_with_type(klass-type));
+env =cpu-env;
+
  if (tcg_enabled()  !inited) {
  inited = 1;
  arm_translate_init();
  }

-env-cpu_model_str = cpu_model;
-env-cp15.c0_cpuid = cpu_class-id;
  cpu_reset(env);
  if (arm_feature(env, ARM_FEATURE_NEON)) {
  gdb_register_coprocessor(env, vfp_gdb_get_reg, vfp_gdb_set_reg,
@@ -459,7 +457,8 @@ void arm_cpu_list(FILE *f, fprintf_function cpu_fprintf)

  void cpu_arm_close(CPUARMState *env)
  {
-g_free(env);
+Object *obj = ENV_GET_OBJECT(env);
+object_delete(obj);
  }

  static int bad_mode_switch(CPUState *env, int mode)

Re: [Qemu-devel] [PATCH RFC 8/7] target-arm: Use IoC for CPU init


On 01/29/2012 05:50 PM, Andreas Färber wrote:

Instead of having each CPU's class_init function call its parent's
function, indirect this through arm_cpu_class_init().

Signed-off-by: Andreas Färberafaer...@suse.de
---
  target-arm/cpu-core.c |   10 +-
  1 files changed, 9 insertions(+), 1 deletions(-)

diff --git a/target-arm/cpu-core.c b/target-arm/cpu-core.c
index b1ac22c..cdd049e 100644
--- a/target-arm/cpu-core.c
+++ b/target-arm/cpu-core.c
@@ -246,6 +246,13 @@ static void arm_cpu_realize(Object *obj)
  cpu-env.cp15.c0_cpuid = cpu_class-id;
  }

+static void arm_cpu_class_init(ObjectClass *klass, void *data)
+{
+const struct ARMCPUDef *d = data;
+
+(*d-class_init)(klass, NULL);
+}
+
  static void cpu_register(const struct ARMCPUDef *def)
  {
  TypeInfo type = {
@@ -254,7 +261,8 @@ static void cpu_register(const struct ARMCPUDef *def)
  .instance_size = sizeof(ARMCPU),
  .instance_init = arm_cpu_realize,
  .class_size = sizeof(ARMCPUClass),
-.class_init = def-class_init,
+.class_init = arm_cpu_class_init,
+.class_data = (void *)def,


Would be better IMHO to embed the data needed by class_init in class_data.  That 
way we're not going through multiple method tables.


Regards,

Anthony Liguori


  };

  type_register_static(type);

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


On 01/29/2012 08:19 PM, John Williams wrote:

On Mon, Jan 30, 2012 at 12:11 PM, Anthony Liguorianth...@codemonkey.ws  wrote:

On 01/29/2012 06:28 PM, John Williams wrote:


On Sun, Jan 29, 2012 at 4:51 PM, Peter Crosthwaite
peter.crosthwa...@petalogix.comwrote:


Hi All,

So on the topic of these command line arguments for initrd, dtb and
friends,
another related issue we have encountered (and have hacked around in our
tree) is not being able to relocate the initrd or kernel. Currently these
memory locations are hardcoded in arm_boot.c:

#define KERNEL_ARGS_ADDR 0x100
#define KERNEL_LOAD_ADDR 0x0001
#define INITRD_LOAD_ADDR 0x00d0

If you see patch 6/7 in this same series I put in place a hack to
override
the initrd location in memory, but I wonder if instead this should go up
to
the command line interface as a parameter. Currently the machine model
(or
arm_boot.c) defines exactly where kernels/initrds/command-line-args line
in
memory, but since these are software properties should perhaps they go up
to
the command line as -kernel,foo=bar options? E.G:

qemu-system-arm

-kernel,kernel-image=/foo/zImage,kernel-addr=0x0001,initrd=/foo/initrd,initrd_addr=0x00d0



There's an opportunity here - QEMU needs the cmdline ability to load
random binaries/elfs anyway, such as

--load file@address



Make an elf loader device if you desire this ability but I'm skeptical that
it really is all that useful.


It is useful for non-Linux use-cases, of which there are many!


It's not just a matter of loading an elf binary in memory.  You probably need to 
have a specific register state set in order to run non-Linux elf binaries which 
means you'll need binary specific logic.


If all of these binaries you want to run have a well known register state, they 
you can just use fw_cfg and a piece of firmware to read the binary (which is 
basically how -kernel works on target-i386).




Can you explain how you'd see such a 'loader device' in practice?  How
does it get bound into the machine model?  How do we pass arguments to
it?


You create a device via qdev (now QOM) that takes whatever properties you need. 
 You then do:


-device elf-loader,base=0xa0,file=my-elf-binary

No different than adding a network card.

As I mentioned in the previous note, we probably should short cut unknown 
options as just assume they're meant for -device such that you could also do:


-elf-loader base=0xa0,file=my-elf-binary

Regards,

Anthony Liguori



Thanks,

John

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

 There's an opportunity here - QEMU needs the cmdline ability to load
 random binaries/elfs anyway, such as

 --load file@address



 Make an elf loader device if you desire this ability but I'm skeptical
 that
 it really is all that useful.


 It is useful for non-Linux use-cases, of which there are many!


 It's not just a matter of loading an elf binary in memory.  You probably
 need to have a specific register state set in order to run non-Linux elf
 binaries which means you'll need binary specific logic.

The machine state at bootup is very well defined - it's whatever the TRM says!

An example may help.  We are working on the Xilinx Zynq model, dual
core Cortex A-9.  We currently are able to use QEMU for the entire
flow from

cold reset -
bootrom -
u-boot -
Linux

In this flow, we don't want any magic initial state, we want QEMU to
model the CPU just like the real hardware.

Equivalently, we might like to kick directly into the kernel, SMP==2 and so on.

It makes no sense to me that we should somehow use a different machine
model just to model a different boot flow on the same hardware.

Another example, we are working on remoteproc/rpmsg support so that we
can run Linux on one core, and firmware on another.  We have this
working in QEMU today, except we had to hack around the ARM boot
code's assumptions that we always want the 2nd CPU to run an WFE/WIQ
loop.  This is only true if you are running Linux *and* you want QEMU
to fake the actions of a bootloader.

If you are modelling a cold start you want those two CPUs to race
until one of them reads the CPUID register puts itself to sleep, ie
just run the bootrom.

All of these use cases are not about virtualisation, but about system
modeling and emulation, which really is where QEMU is valuable in the
embedded space.

 If all of these binaries you want to run have a well known register state,
 they you can just use fw_cfg and a piece of firmware to read the binary
 (which is basically how -kernel works on target-i386).



 Can you explain how you'd see such a 'loader device' in practice?  How
 does it get bound into the machine model?  How do we pass arguments to
 it?


 You create a device via qdev (now QOM) that takes whatever properties you
 need.  You then do:

 -device elf-loader,base=0xa0,file=my-elf-binary

 No different than adding a network card.

A network card is a tangible object, it can be present in the system.
The ELF loader is just emulator cruft, a necessary evil to get the
initial state of the machine.  Should it really be on a level footing
with actual devices?

Rgds,

John
-- 
John Williams, PhD, B. Eng, B. IT
PetaLogix - Linux Solutions for a Reconfigurable World
w: www.petalogix.com  p: +61-7-30090663  f: +61-7-30090663

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

On Jan 29, 2012 8:41 PM, John Williams john.willi...@petalogix.com
wrote:

  There's an opportunity here - QEMU needs the cmdline ability to load
  random binaries/elfs anyway, such as
 
  --load file@address
 
 
 
  Make an elf loader device if you desire this ability but I'm skeptical
  that
  it really is all that useful.
 
 
  It is useful for non-Linux use-cases, of which there are many!
 
 
  It's not just a matter of loading an elf binary in memory.  You probably
  need to have a specific register state set in order to run non-Linux elf
  binaries which means you'll need binary specific logic.

 The machine state at bootup is very well defined - it's whatever the TRM
says!

 An example may help.  We are working on the Xilinx Zynq model, dual
 core Cortex A-9.  We currently are able to use QEMU for the entire
 flow from

 cold reset -
 bootrom -
 u-boot -
 Linux

 In this flow, we don't want any magic initial state, we want QEMU to
 model the CPU just like the real hardware.

 Equivalently, we might like to kick directly into the kernel, SMP==2 and
so on.

 It makes no sense to me that we should somehow use a different machine
 model just to model a different boot flow on the same hardware.

 Another example, we are working on remoteproc/rpmsg support so that we
 can run Linux on one core, and firmware on another.  We have this
 working in QEMU today, except we had to hack around the ARM boot
 code's assumptions that we always want the 2nd CPU to run an WFE/WIQ
 loop.  This is only true if you are running Linux *and* you want QEMU
 to fake the actions of a bootloader.

 If you are modelling a cold start you want those two CPUs to race
 until one of them reads the CPUID register puts itself to sleep, ie
 just run the bootrom.

 All of these use cases are not about virtualisation, but about system
 modeling and emulation, which really is where QEMU is valuable in the
 embedded space.

I don't see how any of this is relevant.  Presumably, on real hardware, you
have a rom bank wired to a specific physical address with ip fixed to an
address which happens to be in that space?

Why not just use an emulated flash chip?


  If all of these binaries you want to run have a well known register
state,
  they you can just use fw_cfg and a piece of firmware to read the binary
  (which is basically how -kernel works on target-i386).
 
 
 
  Can you explain how you'd see such a 'loader device' in practice?  How
  does it get bound into the machine model?  How do we pass arguments to
  it?
 
 
  You create a device via qdev (now QOM) that takes whatever properties
you
  need.  You then do:
 
  -device elf-loader,base=0xa0,file=my-elf-binary
 
  No different than adding a network card.

 A network card is a tangible object, it can be present in the system.
 The ELF loader is just emulator cruft, a necessary evil to get the
 initial state of the machine.  Should it really be on a level footing
 with actual devices?

All systems have to bootstrap software some how.  Some device is reasonable
for this.  This isn't emulated magic :-)

Regards,

Anthony Liguori


 Rgds,

 John
 --
 John Williams, PhD, B. Eng, B. IT
 PetaLogix - Linux Solutions for a Reconfigurable World
 w: www.petalogix.com  p: +61-7-30090663  f: +61-7-30090663

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

2012-01-29 Thread Grant Likely

On Sun, Jan 29, 2012 at 07:13:55PM +, Peter Maydell wrote:
 On 29 January 2012 16:01, Grant Likely grant.lik...@secretlab.ca wrote:
  diff --git a/configure b/configure
  index f69e08f..0c2deab 100755
  --- a/configure
  +++ b/configure
  @@ -3411,6 +3411,9 @@ case $target_arch2 in
      gdb_xml_files=arm-core.xml arm-vfp.xml arm-vfp3.xml arm-neon.xml
      target_phys_bits=32
      target_llong_alignment=4
  +    if test $fdt = yes ; then
  +      target_libs_softmmu=$fdt_libs
  +    fi
 
 This doesn't need to be conditional -- compare the similar stanzas
 for other fdt-using architectures.

Okay.

    ;;
    cris)
      target_nptl=yes
  diff --git a/hw/arm_boot.c b/hw/arm_boot.c
  index 5f163fd..35bfa62 100644
  --- a/hw/arm_boot.c
  +++ b/hw/arm_boot.c
  @@ -7,11 +7,14 @@
   * This code is licensed under the GPL.
   */
 
  +#include config.h
   #include hw.h
   #include arm-misc.h
   #include sysemu.h
  +#include boards.h
   #include loader.h
   #include elf.h
  +#include device_tree.h
 
   #define KERNEL_ARGS_ADDR 0x100
   #define KERNEL_LOAD_ADDR 0x0001
  @@ -207,6 +210,66 @@ static void set_kernel_args_old(const struct 
  arm_boot_info *info,
      }
   }
 
  +static int load_dtb(target_phys_addr_t addr, const struct arm_boot_info 
  *binfo)
  +{
  +#ifdef CONFIG_FDT
  +    uint32_t mem_reg_property[] = { cpu_to_be32(binfo-loader_start),
  +                                    cpu_to_be32(binfo-ram_size) };
  +    void *fdt = NULL;
  +    char *filename;
  +    int size, rc;
  +
  +    if (!current_dtb_filename)
  +        return 0;
 
 scripts/checkpatch.pl complains about this and other style issues...
 

Fixed.

  +
  +    filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, current_dtb_filename);
  +    if (!filename) {
  +        fprintf(stderr, Couldn't open dtb file %s\n, 
  current_dtb_filename);
  +        return -1;
  +    }
  +
  +    fdt = load_device_tree(filename, size);
  +    if (!fdt) {
  +        fprintf(stderr, Couldn't open dtb file %s\n, filename);
  +        g_free(filename);
  +        return -1;
  +    }
  +    g_free(filename);
  +
  +    rc = qemu_devtree_setprop(fdt, /memory, reg, mem_reg_property,
  +                               sizeof(mem_reg_property));
  +    if (rc  0)
  +        fprintf(stderr, couldn't set /memory/reg\n);
  +
  +    rc = qemu_devtree_setprop_string(fdt, /chosen, bootargs,
  +                                      binfo-kernel_cmdline);
  +    if (rc  0)
  +        fprintf(stderr, couldn't set /chosen/bootargs\n);
 
 This seems kind of weird -- if you're not trying to use 'rc' as
 a running something failed flag to return to the caller then
 why not just have if (function()  0) { fprintf(...); } ?

Mostly because it looked ugly when done that way.  There is already a
line break to deal with the long arguments, it looked worse to me when
also put inside an if() block.  If you prefer, then I will change it.

 
  +
  +    if (binfo-initrd_size) {
  +        rc = qemu_devtree_setprop_cell(fdt, /chosen, 
  linux,initrd-start,
  +                binfo-loader_start + INITRD_LOAD_ADDR);
  +        if (rc  0)
  +            fprintf(stderr, couldn't set /chosen/linux,initrd-start\n);
  +
  +        rc = qemu_devtree_setprop_cell(fdt, /chosen, linux,initrd-end,
  +                    binfo-loader_start +INITRD_LOAD_ADDR +
  +                    binfo-initrd_size);
  +        if (rc  0)
  +            fprintf(stderr, couldn't set /chosen/linux,initrd-end\n);
  +    }
  +
  +    cpu_physical_memory_write (addr, fdt, size);
  +
  +    return 0;
  +
  +#else
  +    fprintf(stderr, Platform requested a device tree, 
  +                but qemu was compiled without fdt support\n);
  +    return -1;
  +#endif
  +}
  +
   static void do_cpu_reset(void *opaque)
   {
      CPUState *env = opaque;
  @@ -221,12 +284,14 @@ static void do_cpu_reset(void *opaque)
          } else {
              if (env == first_cpu) {
                  env-regs[15] = info-loader_start;
  -                if (old_param) {
  -                    set_kernel_args_old(info, info-initrd_size,
  +                if (!current_dtb_filename) {
  +                    if (old_param) {
  +                        set_kernel_args_old(info, info-initrd_size,
  +                                            info-loader_start);
  +                    } else {
  +                        set_kernel_args(info, info-initrd_size,
                                          info-loader_start);
  -                } else {
  -                    set_kernel_args(info, info-initrd_size,
  -                                    info-loader_start);
  +                    }
                  }
              } else {
                  info-secondary_cpu_reset_hook(env, info);
  @@ -239,10 +304,10 @@ void arm_load_kernel(CPUState *env, struct 
  arm_boot_info *info)
   {
      int kernel_size;
      int initrd_size;
  -    int n;
  +    int n, rc;
      int is_linux = 0;
      uint64_t elf_entry;
  -    target_phys_addr_t

Re: [Qemu-devel] [RFC][PATCH 09/15] introduce a new monitor command 'dump' to dump guest's memory

2012-01-29 Thread Wen Congyang

At 01/20/2012 12:32 AM, Eric Blake Wrote:
 On 01/18/2012 08:07 PM, Wen Congyang wrote:
 Signed-off-by: Wen Congyang we...@cn.fujitsu.com
 ---
  Makefile.target  |8 +-
  dump.c   |  590 
 ++
  dump.h   |3 +
  hmp-commands.hx  |   16 ++
  hmp.c|9 +
  hmp.h|1 +
  monitor.c|3 +
  qapi-schema.json |   13 ++
  qmp-commands.hx  |   26 +++
  9 files changed, 665 insertions(+), 4 deletions(-)
  create mode 100644 dump.c

 
 +void qmp_dump(const char *file, Error **errp)
 +{
 +const char *p;
 +int fd = -1;
 +DumpState *s;
 +
 +#if !defined(WIN32)
 +if (strstart(file, fd:, p)) {
 +fd = qemu_get_fd(p);
 +if (fd == -1) {
 +error_set(errp, QERR_FD_NOT_FOUND, p);
 +return;
 +}
 +}
 +#endif
 
 Thanks for implementing fd support off the bat.
 
 +
 +if  (strstart(file, file:, p)) {
 +fd = open(p, O_WRONLY | O_CREAT | O_TRUNC | O_BINARY);
 
 Use of O_CREAT requires that you pass a third argument to open()
 specifying the mode_t to use.

Yes, I forgot it, and will fix it.

 
 +++ b/hmp-commands.hx
 @@ -828,6 +828,22 @@ new parameters (if specified) once the vm migration 
 finished successfully.
  ETEXI
  
  {
 +.name   = dump,
 +.args_type  = file:s,
 +.params = file,
 +.help   = dump to file,
 +.user_print = monitor_user_noop,
 +.mhandler.cmd = hmp_dump,
 +},
 
 What if I want to dump only a fraction of the memory?  I think you need
 optional start and length parameters, to limit how much memory to be
 dumped, rather than forcing me to dump all memory at once.
 

It is OK to support it, but I do not know why do you want it?

The purpose of this command is dumping the memory when the guest is paniced.
And then we can use crash/gdb(or other application) to investigate why the guest
is paniced. So we should dump the whole memory.

Thanks
Wen Congyang

Re: [Qemu-devel] [RFC][PATCH 00/15 v5] introducing a new, dedicated memory dump mechanism

2012-01-29 Thread Wen Congyang

At 01/20/2012 12:34 AM, Eric Blake Wrote:
 On 01/18/2012 08:39 PM, Wen Congyang wrote:
 At 01/19/2012 11:32 AM, Jun Koi Wrote:
 On Thu, Jan 19, 2012 at 10:50 AM, Wen Congyang we...@cn.fujitsu.com wrote:
 Hi, all

 'virsh dump' can not work when host pci device is used by guest. We have
 discussed this issue here:
 http://lists.nongnu.org/archive/html/qemu-devel/2011-10/msg00736.html

 We have determined to introduce a new command dump to dump memory. The core
 file's format can be elf.

 do you pause the guest when the dump happen, or you can somehow let it
 continue to run?

 I pause the guest when the dump happens.


 would be wonderful if you can do the latter, since dumping a guest
 memory can take a lot of time.

 Yes, it may tak a lot of time. But we dump a guest memory when the guest
 panics, and there is no need to continue to run the guest.
 
 Would it be possible to have both a dump from a certain point in time
 and still allow the guest to run unpaused?
 
 I'm thinking something along the lines of pausing the guest, setting up
 control structures, then calling fork().  The parent can then unpause,
 and use the control structures to communicate the memory state from the
 child back out the monitor.  Meanwhile, the guest has a copy-on-write
 clone of the entire memory state, so as long as the control structures
 guarantee that the child will not accept any monitor commands and not
 resume the guest, then the child process can be used to stream the
 memory contents as they were at the time of the dump command back over
 the control structure back to the parent process.  I will admit,
 however, that following the fork(), you would be limited to
 async-signal-safe functions, so it may be a rather difficult task to design.
 

I do not understand this section. Do you say the reason of allowing the guest
to run unpaused? Or do you say the way to do it?

Thanks
Wen Congyang

[Qemu-devel] [PATCH v11 0/9] ARM: Samsung Exynos4210-based boards support.

This set of patches adds support for Samsung Exynos4210-based boards NURI and 
SMDKC210.
Tested on Linux kernel v3.x series.

Usage:
-smp 2 option is mandatory for now.
Linux kernel v3.x configured with exynos4_defconfig can be used for boards 
models testing with rootfs
on initrd.

To enable support of framebuffer in kernel, enable Samsung S3C framebuffer 
driver in kernel configuration.
Note: at present time (26.01.2012) Samsung S3C framebuffer support in 
mainline kernel is broken. This
problem will be solved soon by Samsung kernel developers. People interested 
in enabling framebuffer right
now can patch Linux kernel source files a bit to fix S3C framebuffer 
support:
- in array init_clocks_off (file arch/arm/mach-exynos/clock.c) for a member 
with .devname = exynos4-fb.0
  replace .name from fimd to lcd;
- for framebuffer support on nuri board you need to additionally change 
file arch/arm/mach-exynos/common.c:
  add include file
  #include linux/dma-mapping.h
  and add string
  init_consistent_dma_size(SZ_2M + SZ_4M);
  at the very beginning of function void __init exynos4_map_io(void).

To enable support of ethernet on smdkc210 board, enable SMSC LAN911x/LAN921x 
families
embedded ethernet driver in Linux kernel configuration file.
Note: NURI board does not have ethernet adapter and currently has no net 
support.


Example usage:
Boot smdkc210 board with root filesystem on NFS disk.
# qemu-system-arm -kernel ./zImage -append ip=dhcp root=/dev/nfs 
nfsroot=10.0.2.2:/srv/nfs/ rw rootwait -M smdkc210 -smp 2

Boot smdkc210 board with root filesystem on NFS disk and serial port #0 
redirected to terminal
# qemu-system-arm -kernel ./zImage -append console=ttySAC0,115200n8 ip=dhcp 
root=/dev/nfs nfsroot=10.0.2.2:/srv/nfs/ rw  -serial stdio -M smdkc210 -smp 2

Boot NURI with rootfs on inird and serial port #0 redirected to terminal
# qemu-system-arm -kernel ./zImage -append console=ttySAC0,115200n8 
root=/dev/ram rw  -serial stdio -M nuri -smp 2 -initrd ./rootfs.ext2


Changelog:
 v10-v11
 - rebased and converted to QOM: hw/exynos4210_combiner.c, hw/exynos4210_gic.c, 
hw/exynos4210_fimd.c, hw/exynos4210_mct.c, hw/exynos4210_pmu.c,
   hw/exynos4210_pwm.c, hw/exynos4210_uart.c.
   Also we have removed Reviewed-by: from those patches touched by conversion 
to QOM.
 v9-v10
 - hw/lan9118.c: fixed migration-breaking bug in previous patch version;
 - hw/exynos4210_pmu.c: we do not waste space for non-existing registers in PMU 
state anymore;
non-existing registers are now RAZ/WI;
added vmstate structure;

 v8-v9
 - exynos4210.c: secondary cpu bootloader memory region allocation is removed 
(it resides in already allocated IROM),
 removed hack memory region for secondary CPU boot loader (PMU 
device added).
 added l2x0 cache controller
 - exynos4210_pmu.c: PMU registers modelling device added to emulation. It is 
needed since PMU contains 
 INFORM5 register which is used to boot the secondary CPUs.
 - exynos4_boards.c: indentation fix
 - exynos4210_uart.c: indentation fix, BREAK event handling code added, fixed 
size of allocated registers region
 - exynos4210_gic.c: number of IRQs passed to gic_init() due to last mainline 
update.
 - lan9118.: added VMSTATE fields due to last mainline update.
 v7-v8
 - exynos4_boards.c: lack of spaces fix
 - exynos4210_gic.c: lack of spaces fix
 - exynos4210_combiner.c: lack of spaces fix
 - exynos4210_uart.c: lack of spaces fix, indentation fix
 - exynos4210_mct.c: ULL suffix fix
 v6-v7
 - exynos4210_pwm.c: added usage of ptimer.h
 - exynos4210_mct.c: added usage of ptimer.h
 v5-v6
 - arm_boot.c, vexpress.c, realview.c: board should specify smp_bootreg_addr if 
its ncpu  1
 - patch order changed, boot secondary CPU is included in exynos boards 
patch.
 - exynos4210_mct.c: usage of UINTX_MAX, removed excessive property list, fixed 
indentation,
 fixed comments
 - exynos4210_pwm.c: spaces and brakcets in macros, removed excessive property 
list,
 fixed indentation,
 - exynos4210_combiner.c: removed excessive reset, fixed indentation, fixed 
comments
 - exynos4210_gic.c: fixed indentation, fixed syntax
 - exynos4210_uart.c: fixed indentation, fixed syntax
 - exynos4210.c: fixed comments
 - Makefile.target: removed \
 - hw/exynos4210_fimd.c: rebased against current master: all manipulation with 
physical pages are dropped and
 replaced with new memory API functions;

 added three new members to winow's state: 
MemoryRegionSection to describe section
 of system RAM containing current framebuffer, host 
pointer to framebuffer data and
 framebuffer length;

 mapping of framebuffer now performed only on 
framebuffer settings change
 instead on every display

[Qemu-devel] [PATCH v11 4/9] ARM: exynos4210: PWM support.

Signed-off-by: Evgeny Voevodin e.voevo...@samsung.com
Reviewed-by: Peter Maydell peter.mayd...@linaro.org
---
 Makefile.target |2 +-
 hw/exynos4210.c |   12 ++
 hw/exynos4210_pwm.c |  420 +++
 3 files changed, 433 insertions(+), 1 deletions(-)
 create mode 100644 hw/exynos4210_pwm.c

diff --git a/Makefile.target b/Makefile.target
index 4291619..5f0726d 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -339,7 +339,7 @@ obj-arm-y += arm_boot.o pl011.o pl031.o pl050.o pl080.o 
pl110.o pl181.o pl190.o
 obj-arm-y += versatile_pci.o
 obj-arm-y += realview_gic.o realview.o arm_sysctl.o arm11mpcore.o a9mpcore.o
 obj-arm-y += exynos4210_gic.o exynos4210_combiner.o exynos4210.o
-obj-arm-y += exynos4_boards.o exynos4210_uart.o
+obj-arm-y += exynos4_boards.o exynos4210_uart.o exynos4210_pwm.o
 obj-arm-y += arm_l2x0.o
 obj-arm-y += arm_mptimer.o
 obj-arm-y += armv7m.o armv7m_nvic.o stellaris.o pl022.o stellaris_enet.o
diff --git a/hw/exynos4210.c b/hw/exynos4210.c
index 3838b96..ea5a1f8 100644
--- a/hw/exynos4210.c
+++ b/hw/exynos4210.c
@@ -29,6 +29,9 @@
 
 #define EXYNOS4210_CHIPID_ADDR 0x1000
 
+/* PWM */
+#define EXYNOS4210_PWM_BASE_ADDR   0x139D
+
 /* UART's definitions */
 #define EXYNOS4210_UART0_BASE_ADDR 0x1380
 #define EXYNOS4210_UART1_BASE_ADDR 0x1381
@@ -201,6 +204,15 @@ Exynos4210State *exynos4210_init(MemoryRegion *system_mem,
 memory_region_add_subregion(system_mem, EXYNOS4210_DRAM0_BASE_ADDR,
 s-dram0_mem);
 
+/* PWM */
+sysbus_create_varargs(exynos4210.pwm, EXYNOS4210_PWM_BASE_ADDR,
+irq_table[exynos4210_get_irq(22, 0)],
+irq_table[exynos4210_get_irq(22, 1)],
+irq_table[exynos4210_get_irq(22, 2)],
+irq_table[exynos4210_get_irq(22, 3)],
+irq_table[exynos4210_get_irq(22, 4)],
+NULL);
+
 /*** UARTs ***/
 exynos4210_uart_create(EXYNOS4210_UART0_BASE_ADDR,
EXYNOS4210_UART0_FIFO_SIZE, 0, NULL,
diff --git a/hw/exynos4210_pwm.c b/hw/exynos4210_pwm.c
new file mode 100644
index 000..c5c8221
--- /dev/null
+++ b/hw/exynos4210_pwm.c
@@ -0,0 +1,420 @@
+/*
+ * Samsung exynos4210 Pulse Width Modulation Timer
+ *
+ * Copyright (c) 2000 - 2011 Samsung Electronics Co., Ltd.
+ * All rights reserved.
+ *
+ * Evgeny Voevodin e.voevo...@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+ * See the GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, see http://www.gnu.org/licenses/.
+ */
+
+#include sysbus.h
+#include qemu-timer.h
+#include qemu-common.h
+#include ptimer.h
+
+#include exynos4210.h
+
+//#define DEBUG_PWM
+
+#ifdef DEBUG_PWM
+#define DPRINTF(fmt, ...) \
+do { fprintf(stdout, PWM: [%24s:%5d]  fmt, __func__, __LINE__, \
+## __VA_ARGS__); } while (0)
+#else
+#define DPRINTF(fmt, ...) do {} while (0)
+#endif
+
+#define EXYNOS4210_PWM_TIMERS_NUM  5
+#define EXYNOS4210_PWM_REG_MEM_SIZE0x50
+
+#define TCFG00x
+#define TCFG10x0004
+#define TCON 0x0008
+#define TCNTB0   0x000C
+#define TCMPB0   0x0010
+#define TCNTO0   0x0014
+#define TCNTB1   0x0018
+#define TCMPB1   0x001C
+#define TCNTO1   0x0020
+#define TCNTB2   0x0024
+#define TCMPB2   0x0028
+#define TCNTO2   0x002C
+#define TCNTB3   0x0030
+#define TCMPB3   0x0034
+#define TCNTO3   0x0038
+#define TCNTB4   0x003C
+#define TCNTO4   0x0040
+#define TINT_CSTAT   0x0044
+
+#define TCNTB(x)(0xC * (x))
+#define TCMPB(x)(0xC * (x) + 1)
+#define TCNTO(x)(0xC * (x) + 2)
+
+#define GET_PRESCALER(reg, x) (((reg)  (0xFF  (8 * (x  8 * (x))
+#define GET_DIVIDER(reg, x) (1  (((reg)  (0xF  (4 * (x  (4 * (x
+
+/*
+ * Attention! Timer4 doesn't have OUTPUT_INVERTER,
+ * so Auto Reload bit is not accessible by macros!
+ */
+#define TCON_TIMER_BASE(x)  (((x) ? 1 : 0) * 4 + 4 * (x))
+#define TCON_TIMER_START(x) (1  (TCON_TIMER_BASE(x) + 0))
+#define TCON_TIMER_MANUAL_UPD(x)(1  (TCON_TIMER_BASE(x) + 1))
+#define TCON_TIMER_OUTPUT_INV(x)(1  (TCON_TIMER_BASE(x) + 2))
+#define TCON_TIMER_AUTO_RELOAD(x)   (1  (TCON_TIMER_BASE(x) + 3))
+#define TCON_TIMER4_AUTO_RELOAD (1  22)
+
+#define TINT_CSTAT_STATUS(x)(1  (5 + (x)))
+#define TINT_CSTAT_ENABLE(x)

[Qemu-devel] [PATCH v11 2/9] ARM: Samsung exynos4210-based boards emulation

Add initial support of NURI and SMDKC210 boards

Signed-off-by: Evgeny Voevodin e.voevo...@samsung.com
---
 Makefile.target |3 +-
 hw/exynos4210.c |  193 +++
 hw/exynos4210.h |   40 +++
 hw/exynos4_boards.c |  143 +
 4 files changed, 378 insertions(+), 1 deletions(-)
 create mode 100644 hw/exynos4210.c
 create mode 100644 hw/exynos4_boards.c

diff --git a/Makefile.target b/Makefile.target
index 1b17f15..93eb7d6 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -338,7 +338,8 @@ obj-arm-y = integratorcp.o versatilepb.o arm_pic.o 
arm_timer.o
 obj-arm-y += arm_boot.o pl011.o pl031.o pl050.o pl080.o pl110.o pl181.o pl190.o
 obj-arm-y += versatile_pci.o
 obj-arm-y += realview_gic.o realview.o arm_sysctl.o arm11mpcore.o a9mpcore.o
-obj-arm-y += exynos4210_gic.o exynos4210_combiner.o
+obj-arm-y += exynos4210_gic.o exynos4210_combiner.o exynos4210.o
+obj-arm-y += exynos4_boards.o
 obj-arm-y += arm_l2x0.o
 obj-arm-y += arm_mptimer.o
 obj-arm-y += armv7m.o armv7m_nvic.o stellaris.o pl022.o stellaris_enet.o
diff --git a/hw/exynos4210.c b/hw/exynos4210.c
new file mode 100644
index 000..aff0081
--- /dev/null
+++ b/hw/exynos4210.c
@@ -0,0 +1,193 @@
+/*
+ *  Samsung exynos4210 SoC emulation
+ *
+ *  Copyright (c) 2011 Samsung Electronics Co., Ltd. All rights reserved.
+ *Maksim Kozlov m.koz...@samsung.com
+ *Evgeny Voevodin e.voevo...@samsung.com
+ *Igor Mitsyanko  i.mitsya...@samsung.com
+ *
+ *  This program is free software; you can redistribute it and/or modify it
+ *  under the terms of the GNU General Public License as published by the
+ *  Free Software Foundation; either version 2 of the License, or
+ *  (at your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful, but WITHOUT
+ *  ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ *  FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
+ *  for more details.
+ *
+ *  You should have received a copy of the GNU General Public License along
+ *  with this program; if not, see http://www.gnu.org/licenses/.
+ *
+ */
+
+#include boards.h
+#include sysemu.h
+#include sysbus.h
+#include arm-misc.h
+#include exynos4210.h
+
+#define EXYNOS4210_CHIPID_ADDR 0x1000
+
+/* External GIC */
+#define EXYNOS4210_EXT_GIC_CPU_BASE_ADDR0x1048
+#define EXYNOS4210_EXT_GIC_DIST_BASE_ADDR   0x1049
+
+/* Combiner */
+#define EXYNOS4210_EXT_COMBINER_BASE_ADDR   0x1044
+#define EXYNOS4210_INT_COMBINER_BASE_ADDR   0x10448000
+
+static uint8_t chipid_and_omr[] = { 0x11, 0x02, 0x21, 0x43,
+0x09, 0x00, 0x00, 0x00 };
+
+Exynos4210State *exynos4210_init(MemoryRegion *system_mem,
+unsigned long ram_size)
+{
+qemu_irq cpu_irq[4];
+int n;
+Exynos4210State *s = g_new(Exynos4210State, 1);
+qemu_irq *irq_table;
+qemu_irq *irqp;
+qemu_irq gate_irq[EXYNOS4210_IRQ_GATE_NINPUTS];
+unsigned long mem_size;
+DeviceState *dev;
+SysBusDevice *busdev;
+
+for (n = 0; n  smp_cpus; n++) {
+s-env[n] = cpu_init(cortex-a9);
+if (!s-env[n]) {
+fprintf(stderr, Unable to find CPU %d definition\n, n);
+exit(1);
+}
+/* Create PIC controller for each processor instance */
+irqp = arm_pic_init_cpu(s-env[n]);
+
+/*
+ * Get GICs gpio_in cpu_irq to connect a combiner to them later.
+ * Use only IRQ for a while.
+ */
+cpu_irq[n] = irqp[ARM_PIC_CPU_IRQ];
+}
+
+/*** IRQs ***/
+
+s-irq_table = exynos4210_init_irq(s-irqs);
+irq_table = s-irq_table;
+
+/* IRQ Gate */
+dev = qdev_create(NULL, exynos4210.irq_gate);
+qdev_init_nofail(dev);
+/* Get IRQ Gate input in gate_irq */
+for (n = 0; n  EXYNOS4210_IRQ_GATE_NINPUTS; n++) {
+gate_irq[n] = qdev_get_gpio_in(dev, n);
+}
+busdev = sysbus_from_qdev(dev);
+/* Connect IRQ Gate output to cpu_irq */
+for (n = 0; n  smp_cpus; n++) {
+sysbus_connect_irq(busdev, n, cpu_irq[n]);
+}
+
+/* Private memory region and Internal GIC */
+dev = qdev_create(NULL, a9mpcore_priv);
+qdev_prop_set_uint32(dev, num-cpu, smp_cpus);
+qdev_init_nofail(dev);
+busdev = sysbus_from_qdev(dev);
+sysbus_mmio_map(busdev, 0, EXYNOS4210_SMP_PRIVATE_BASE_ADDR);
+for (n = 0; n  smp_cpus; n++) {
+sysbus_connect_irq(busdev, n, gate_irq[n * 2]);
+}
+for (n = 0; n  EXYNOS4210_INT_GIC_NIRQ; n++) {
+s-irqs.int_gic_irq[n] = qdev_get_gpio_in(dev, n);
+}
+
+/* Cache controller */
+sysbus_create_simple(l2x0, EXYNOS4210_L2X0_BASE_ADDR, NULL);
+
+/* External GIC */
+dev = qdev_create(NULL, exynos4210.gic);
+qdev_prop_set_uint32(dev, num-cpu, smp_cpus);
+qdev_init_nofail(dev);
+busdev = sysbus_from_qdev(dev);
+/* Map CPU interface */
+

[Qemu-devel] [PATCH v11 1/9] ARM: exynos4210: IRQ subsystem support.

Signed-off-by: Evgeny Voevodin e.voevo...@samsung.com
---
 Makefile.target  |1 +
 hw/exynos4210.h  |   82 
 hw/exynos4210_combiner.c |  481 ++
 hw/exynos4210_gic.c  |  452 +++
 4 files changed, 1016 insertions(+), 0 deletions(-)
 create mode 100644 hw/exynos4210.h
 create mode 100644 hw/exynos4210_combiner.c
 create mode 100644 hw/exynos4210_gic.c

diff --git a/Makefile.target b/Makefile.target
index 68481a3..1b17f15 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -338,6 +338,7 @@ obj-arm-y = integratorcp.o versatilepb.o arm_pic.o 
arm_timer.o
 obj-arm-y += arm_boot.o pl011.o pl031.o pl050.o pl080.o pl110.o pl181.o pl190.o
 obj-arm-y += versatile_pci.o
 obj-arm-y += realview_gic.o realview.o arm_sysctl.o arm11mpcore.o a9mpcore.o
+obj-arm-y += exynos4210_gic.o exynos4210_combiner.o
 obj-arm-y += arm_l2x0.o
 obj-arm-y += arm_mptimer.o
 obj-arm-y += armv7m.o armv7m_nvic.o stellaris.o pl022.o stellaris_enet.o
diff --git a/hw/exynos4210.h b/hw/exynos4210.h
new file mode 100644
index 000..cef264b
--- /dev/null
+++ b/hw/exynos4210.h
@@ -0,0 +1,82 @@
+/*
+ *  Samsung exynos4210 SoC emulation
+ *
+ *  Copyright (c) 2011 Samsung Electronics Co., Ltd. All rights reserved.
+ *Maksim Kozlov m.koz...@samsung.com
+ *Evgeny Voevodin e.voevo...@samsung.com
+ *Igor Mitsyanko i.mitsya...@samsung.com
+ *
+ *
+ *  This program is free software; you can redistribute it and/or modify it
+ *  under the terms of the GNU General Public License as published by the
+ *  Free Software Foundation; either version 2 of the License, or
+ *  (at your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful, but WITHOUT
+ *  ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ *  FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
+ *  for more details.
+ *
+ *  You should have received a copy of the GNU General Public License along
+ *  with this program; if not, see http://www.gnu.org/licenses/.
+ *
+ */
+
+
+#ifndef EXYNOS4210_H_
+#define EXYNOS4210_H_
+
+#include qemu-common.h
+#include memory.h
+
+#define EXYNOS4210_MAX_CPUS 2
+
+/*
+ * exynos4210 IRQ subsystem stub definitions.
+ */
+#define EXYNOS4210_IRQ_GATE_NINPUTS 8
+
+#define EXYNOS4210_MAX_INT_COMBINER_OUT_IRQ  64
+#define EXYNOS4210_MAX_EXT_COMBINER_OUT_IRQ  16
+#define EXYNOS4210_MAX_INT_COMBINER_IN_IRQ   \
+(EXYNOS4210_MAX_INT_COMBINER_OUT_IRQ * 8)
+#define EXYNOS4210_MAX_EXT_COMBINER_IN_IRQ   \
+(EXYNOS4210_MAX_EXT_COMBINER_OUT_IRQ * 8)
+
+#define EXYNOS4210_COMBINER_GET_IRQ_NUM(grp, bit)  ((grp)*8 + (bit))
+#define EXYNOS4210_COMBINER_GET_GRP_NUM(irq)   ((irq) / 8)
+#define EXYNOS4210_COMBINER_GET_BIT_NUM(irq) \
+((irq) - 8 * EXYNOS4210_COMBINER_GET_GRP_NUM(irq))
+
+/* IRQs number for external and internal GIC */
+#define EXYNOS4210_EXT_GIC_NIRQ (160-32)
+#define EXYNOS4210_INT_GIC_NIRQ 64
+
+typedef struct Exynos4210Irq {
+qemu_irq int_combiner_irq[EXYNOS4210_MAX_INT_COMBINER_IN_IRQ];
+qemu_irq ext_combiner_irq[EXYNOS4210_MAX_EXT_COMBINER_IN_IRQ];
+qemu_irq int_gic_irq[EXYNOS4210_INT_GIC_NIRQ];
+qemu_irq ext_gic_irq[EXYNOS4210_EXT_GIC_NIRQ];
+qemu_irq board_irqs[EXYNOS4210_MAX_INT_COMBINER_IN_IRQ];
+} Exynos4210Irq;
+
+/* Initialize exynos4210 IRQ subsystem stub */
+qemu_irq *exynos4210_init_irq(Exynos4210Irq *env);
+
+/* Initialize board IRQs.
+ * These IRQs contain splitted Int/External Combiner and External Gic IRQs */
+void exynos4210_init_board_irqs(Exynos4210Irq *s);
+
+/* Get IRQ number from exynos4210 IRQ subsystem stub.
+ * To identify IRQ source use internal combiner group and bit number
+ *  grp - group number
+ *  bit - bit number inside group */
+uint32_t exynos4210_get_irq(uint32_t grp, uint32_t bit);
+
+/*
+ * Get Combiner input GPIO into irqs structure
+ */
+void exynos4210_combiner_get_gpioin(Exynos4210Irq *irqs, DeviceState *dev,
+int ext);
+
+#endif /* EXYNOS4210_H_ */
diff --git a/hw/exynos4210_combiner.c b/hw/exynos4210_combiner.c
new file mode 100644
index 000..4d41a1a
--- /dev/null
+++ b/hw/exynos4210_combiner.c
@@ -0,0 +1,481 @@
+/*
+ * Samsung exynos4210 Interrupt Combiner
+ *
+ * Copyright (c) 2000 - 2011 Samsung Electronics Co., Ltd.
+ * All rights reserved.
+ *
+ * Evgeny Voevodin e.voevo...@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+ * See the GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU

[Qemu-devel] [PATCH v11 6/9] ARM: exynos4210: MCT support.