Re: [Qemu-devel] Memory API: handling unassigned physical memory

[Avi Kivity]

On 04/29/2012 10:35 PM, Anthony Liguori wrote:
 On 04/29/2012 12:25 PM, Mark Cave-Ayland wrote:
 Hi all,

 I've been having a look at handling SBUS probes within
 qemu-system-sparc when I
 came across a very simple crash bug with git master trying to access
 unassigned
 physical addresses:

 (qemu) info mtree
 memory
 -7ffe (prio 0, RW): system
 -07ff (prio 0, RW): sun4m.ram
 0800-0fff (prio 0, RW): empty-slot
 1000-10003fff (prio 0, RW): iommu
 10004000-1fffefff (prio 0, RW): empty-slot
 5020-502f (prio 0, RW): tcx.dac
 ...
 ...

 AFAICT the devices are mapped to physical addresses (uandsing
 sysbus_mmio_map)
 so the xp monitor command should be able to at least read these regions:

 (qemu) xp 0x5020
 5020: 0x
 (qemu) xp 0x5010
 Segmentation fault

 There is definitely a QEMU bug here in that an incorrect physical
 memory access
 shouldn't segfault QEMU. However some off-list discussions with Blue
 suggested
 that it may be possible to defer this behaviour to the memory API
 (rather than
 in exec.c) by allowing boards to register a simple device to handle
 unassigned
 memory accesses, e.g. like the empty_slot device used to trap certain
 memory
 accesses within SPARC.

Yes.  I think it's even possible to do this now, you can create an mmio
region for the bus and add subregions to it.  All subregions
automatically overlap the container region.

Simply replace

  memory_region_init(bus-address_space, ...)
  memory_region_add_subregion(bus-address_space, addr, dev-mmio)

with

  memory_region_init_io(bus-address_space, bus_nodev_ops, bus, ...)
  memory_region_add_subregion(bus-address_space, addr, dev-mmio) //
unchanged

This was never used so it hasn't been tested, but the code was written
with it in mind.  I didn't want to document this so we could back out of
it, but if it's useful, let's use it.


 What does real hardware do?  Does hardware assert a line if an invalid
 MMIO request is generated?

Note that real hardware varies within the board.  Different buses can
take different actions (and possibly even be reconfigured at runtime).



 This would enable us to easily solve the problem for SPARC since we
 could create
 a parent memory region for the entire physical address space that
 would simply
 update the status register and raise the required IRQ. Is this the
 best way to
 solve the problem or is there something else that I've missed?

 I think you want to look at memory_region_add_subregion_overlap().

Unneeded, see above.  And remember, every time you need something from
the memory API, look at a window system.  In this case, we're replacing
a transparent container window with an opaque one.

Note that this may have side effects if the container region overlaps
another region with higher priority.  It's unlikely, but 'info mtree' is
recommended before use.

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

Re: [Qemu-devel] [PATCH v2 4/6] prep: move int-ack register from PReP to Raven PCI emulation

[Avi Kivity]

On 04/29/2012 11:12 PM, Andreas Färber wrote:
 Am 29.04.2012 10:32, schrieb Avi Kivity:
  On 04/28/2012 09:46 PM, Andreas Färber wrote:
  Am 14.04.2012 22:48, schrieb Hervé Poussineau:
  Register is one byte-wide (as per specification), so there is no need to 
  specify endianness.
 
  The region was 4 bytes before, now it's 1. What happens when a 4-byte
  read is attempted at that address? Do we need to specify the valid
  widths for the MemoryRegion? Or is such a read constructed from this
  region and (assuming) the return value of an unassigned read?
  
  This area of what happens during access that falls across region
  boundaries is very underspecified in qemu; nor is it clear what happens
  in real hardware (in all its variations).

 So, what's your conclusion here? Should we add .valid.max_access_size =
 1? Or shall I apply as is?

If the specification says 1 byte and there are no known guests that
abuse it, I say change it.  Regardless, we need to collect requirements
for this shady area and implement them.

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

Re: [Qemu-devel] [PATCH] ppce500_spin: Replace assert by hw_error (fixes compiler warning)

[Alexander Graf]

On 28.04.2012, at 17:52, Stefan Weil wrote:

 The default case in function spin_read should never be reached,
 therefore the old code used assert(0) to abort QEMU.
 
 This does not work when QEMU is compiled with macro NDEBUG defined.
 In this case (and also when the compiler does not know that assert
 never returns), there is a compiler warning because of the missing
 return value.
 
 Using hw_error allows an improved error message and aborts always.
 
 Signed-off-by: Stefan Weil s...@weilnetz.de

Thanks, applied to ppc-next. The patch didn't show up on patchworks btw, not 
sure what went wrong there.


Alex

Re: [Qemu-devel] [PATCH 14/22] ppc: cleanup MMU merge

[Alexander Graf]

On 22.04.2012, at 15:25, Blue Swirl wrote:

 Remove useless wrappers. In some cases 'int' parameters are
 changed to uint32_t.
 
 Make internal functions static.
 
 Signed-off-by: Blue Swirl blauwir...@gmail.com
 ---
 target-ppc/cpu.h|   22 -
 target-ppc/mmu_helper.c |  122 ++-
 2 files changed, 36 insertions(+), 108 deletions(-)
 
 diff --git a/target-ppc/cpu.h b/target-ppc/cpu.h
 index 6216fd9..46204dc 100644
 --- a/target-ppc/cpu.h
 +++ b/target-ppc/cpu.h
 @@ -1118,24 +1118,10 @@ void do_interrupt (CPUPPCState *env);
 void ppc_hw_interrupt (CPUPPCState *env);
 
 #if !defined(CONFIG_USER_ONLY)
 -void ppc6xx_tlb_store (CPUPPCState *env, target_ulong EPN, int way,
 int is_code,
 -   target_ulong pte0, target_ulong pte1);
 -void ppc_store_ibatu (CPUPPCState *env, int nr, target_ulong value);
 -void ppc_store_ibatl (CPUPPCState *env, int nr, target_ulong value);
 -void ppc_store_dbatu (CPUPPCState *env, int nr, target_ulong value);
 -void ppc_store_dbatl (CPUPPCState *env, int nr, target_ulong value);
 -void ppc_store_ibatu_601 (CPUPPCState *env, int nr, target_ulong value);
 -void ppc_store_ibatl_601 (CPUPPCState *env, int nr, target_ulong value);
 void ppc_store_sdr1 (CPUPPCState *env, target_ulong value);
 #if defined(TARGET_PPC64)
 void ppc_store_asr (CPUPPCState *env, target_ulong value);
 -target_ulong ppc_load_slb (CPUPPCState *env, int slb_nr);
 -target_ulong ppc_load_sr (CPUPPCState *env, int sr_nr);
 -int ppc_store_slb (CPUPPCState *env, target_ulong rb, target_ulong rs);

This function is used by kvm on ppc64. I'll just quickly merge this patch with 
yours:

diff --git a/target-ppc/cpu.h b/target-ppc/cpu.h
index 46204dc..b034d6b 100644
--- a/target-ppc/cpu.h
+++ b/target-ppc/cpu.h
@@ -1121,6 +1121,7 @@ void ppc_hw_interrupt (CPUPPCState *env);
 void ppc_store_sdr1 (CPUPPCState *env, target_ulong value);
 #if defined(TARGET_PPC64)
 void ppc_store_asr (CPUPPCState *env, target_ulong value);
+int ppc_store_slb (CPUPPCState *env, target_ulong rb, target_ulong rs);
 #endif /* defined(TARGET_PPC64) */
 #endif /* !defined(CONFIG_USER_ONLY) */
 void ppc_store_msr (CPUPPCState *env, target_ulong value);
diff --git a/target-ppc/mmu_helper.c b/target-ppc/mmu_helper.c
index 36eaab6..2260c1d 100644
--- a/target-ppc/mmu_helper.c
+++ b/target-ppc/mmu_helper.c
@@ -758,7 +758,7 @@ void helper_slbie(CPUPPCState *env, target_ulong addr)
 }
 }
 
-static int ppc_store_slb(CPUPPCState *env, target_ulong rb, target_ulong rs)
+int ppc_store_slb(CPUPPCState *env, target_ulong rb, target_ulong rs)
 {
 int slot = rb  0xfff;
 ppc_slb_t *slb = env-slb[slot];


Alex

[Qemu-devel] KVM call agenda for May, Thrusday 1st

[Juan Quintela]

Hi

Please send in any agenda items you are interested in covering.

Thanks, Juan.

Re: [Qemu-devel] [PULL] QOM CPUState for sh4, m68k and mips

[Andreas Färber]

Am 25.04.2012 16:23, schrieb Andreas Färber:
 Hello Anthony, Blue,
 
 Please pull the remainder of the QOM CPU conversions: sh4, m68k and mips.

Ping!

Blue, both Aurélien and Paul have consented to status Odd Fixes via IRC
in the meantime, so I've updated the below branch with Cc - Acked-by.

Aurélien wants to take up maintainership of sh4 and mips later on and
doesn't mind us applying changes in the meantime.
Paul doesn't consider his M: for m68k as indicating ownership at all.

Please pull. I'll have one more 1.1 patch as followup, cleaning up the
#ifdef from my recent linux-user bugfix, which I'll post as reply here.

Andreas

 There was no reaction from the listed maintainers to my patches for weeks
 nor to the MAINTAINERS RFC for one week, so please apply to let us proceed.
 
 Cc: Anthony Liguori anth...@codemonkey.ws
 Cc: Blue Swirl blauwir...@gmail.com
 
 Cc: Aurélien Jarno aurel...@aurel32.net
 Cc: Paul Brook p...@codesourcery.com
 
 The following changes since commit cf36b31db209a261ee3bc2737e788e1ced0a1bec:
 
   Limit ptimer rate to something achievable (2012-04-24 09:50:31 -0500)
 
 are available in the git repository at:
   git://github.com/afaerber/qemu-cpu.git qom-cpu-rest.v1
 
 Andreas Färber (12):
   MAINTAINERS: Downgrade target-m68k to Odd Fixes
   MAINTAINERS: Downgrade target-mips and target-sh4 to Odd Fixes
   target-sh4: QOM'ify CPU
   target-sh4: QOM'ify CPU reset
   target-sh4: Start QOM'ifying CPU init
   target-m68k: QOM'ify CPU
   target-m68k: QOM'ify CPU reset
   target-m68k: Start QOM'ifying CPU init
   target-m68k: Add QOM CPU subclasses
   target-mips: QOM'ify CPU
   target-mips: Start QOM'ifying CPU init
   Makefile: Simplify compilation of target-*/cpu.c
 
  MAINTAINERS |6 +-
  Makefile.target |   11 +---
  target-m68k/cpu-qom.h   |   70 +++
  target-m68k/cpu.c   |  170 
 +++
  target-m68k/cpu.h   |3 +-
  target-m68k/helper.c|  159 ++--
  target-mips/cpu-qom.h   |   74 
  target-mips/cpu.c   |   69 +++
  target-mips/cpu.h   |2 +
  target-mips/translate.c |5 +-
  target-sh4/cpu-qom.h|   70 +++
  target-sh4/cpu.c|   90 +
  target-sh4/cpu.h|2 +
  target-sh4/translate.c  |   28 ++--
  14 files changed, 612 insertions(+), 147 deletions(-)
  create mode 100644 target-m68k/cpu-qom.h
  create mode 100644 target-m68k/cpu.c
  create mode 100644 target-mips/cpu-qom.h
  create mode 100644 target-mips/cpu.c
  create mode 100644 target-sh4/cpu-qom.h
  create mode 100644 target-sh4/cpu.c

-- 
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 13/12] linux-user: Clean up interim solution for exit syscall

[Andreas Färber]

After all target CPUs have been QOM'ified, we no longer need an #ifdef
to switch between object_delete() and g_free() in NPTL thread exit.

Signed-off-by: Andreas Färber afaer...@suse.de
---
 linux-user/syscall.c |4 
 1 files changed, 0 insertions(+), 4 deletions(-)

diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index 7128618..801b8ed 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -5045,11 +5045,7 @@ abi_long do_syscall(void *cpu_env, int num, abi_long 
arg1,
 NULL, NULL, 0);
   }
   thread_env = NULL;
-#ifdef ENV_GET_CPU
   object_delete(OBJECT(ENV_GET_CPU(cpu_env)));
-#else
-  g_free(cpu_env);
-#endif
   g_free(ts);
   pthread_exit(NULL);
   }
-- 
1.7.7

Re: [Qemu-devel] [PATCH 4/4] configure: check for supported Python 2.x versions

[Stefan Hajnoczi]

On Fri, Apr 27, 2012 at 08:13:31PM +0200, Lluís Vilanova wrote:
 Stefan Hajnoczi writes:
 
  The tracetool code requires Python 2.4, which was released in 2004.
  Check for a supported Python version so we can give a clear error
  message.
 
  Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
  ---
   configure |7 ---
   1 file changed, 4 insertions(+), 3 deletions(-)
 
  diff --git a/configure b/configure
  index 15bbc73..39c7ac2 100755
  --- a/configure
  +++ b/configure
  @@ -1247,9 +1247,10 @@ fi
 
   # Note that if the Python conditional here evaluates True we will exit
   # with status 1 which is a shell 'false' value.
  -if ! $python -c 'import sys; sys.exit(sys.version_info[0] = 3)'; then
  -  echo Python 2 required but '$python' is version 3 or better.
  -  echo Use --python=/path/to/python to specify a Python 2.
  +if ! $python -c 'import sys; sys.exit(sys.version_info[0] != 2 or 
  sys.version_info[1]  4)'; then
  +  echo Cannot use '$python', Python 2.4 or later is required.
  +  echo Note that Python 3 or later is not yet supported.
  +  echo Use --python=/path/to/python to specify a supported Python.
 exit 1
   fi
 
 This looks more readable to me:
 
 sys.exit(sys.version_info  (2,4) or sys.version_info = (3,))

Nice, thanks.

Stefan

Re: [Qemu-devel] [PATCH 20/22] ppc: move load and store helpers, switch to AREG0 free mode

[Alexander Graf]

On 22.04.2012, at 15:26, Blue Swirl wrote:

 Add an explicit CPUPPCState parameter instead of relying on AREG0
 and rename op_helper.c (which only contains load and store helpers)
 to mem_helper.c. Remove AREG0 swapping in
 tlb_fill().
 
 Switch to AREG0 free mode. Use cpu_ld{l,uw}_code in translation
 and interrupt handling, cpu_{ld,st}{l,uw}_data in loads and stores.

This patch breaks qemu-system-ppc64 on ppc32 host user space for me. I'm trying 
to debug it down, but worst case I'll omit this patch set for 1.1.


Alex

[Qemu-devel] [PATCH v2 0/5] tracetool: Python 2.4 compatibility fixes

[Stefan Hajnoczi]

The new Python tracetool implementation works great but does not run on older
Python installations.  This series takes us back to the happy days of Python
2.4, which was released in 2004.

As a result tracetool should now work again on Mac OS X v10.5.8, OpenIndiana
oi_151a, Solaris 10 U9, and Red Hat Enterprise Linux 5.

I added a new patch which should make --list-backends work on Python 2.7 now.

Thanks for everyone's help testing on these platforms.

v2:
 * Use nicer version check Python expression [Lluís]
 * Avoid pkgutil.iter_modules() [Andreas]

Stefan Hajnoczi (5):
  tracetool: use Python 2.4-compatible exception handling syntax
  tracetool: use Python 2.4-compatible __import__() arguments
  tracetool: avoid str.rpartition() Python 2.5 function
  configure: check for supported Python 2.x versions
  tracetool: avoid pkgutil.iter_modules() Python 2.7 function

 configure |7 ---
 scripts/tracetool.py  |4 ++--
 scripts/tracetool/__init__.py |   19 +++
 scripts/tracetool/backend/__init__.py |8 ++--
 scripts/tracetool/format/__init__.py  |8 ++--
 5 files changed, 29 insertions(+), 17 deletions(-)

-- 
1.7.10

[Qemu-devel] [PATCH v2 1/5] tracetool: use Python 2.4-compatible exception handling syntax

[Stefan Hajnoczi]

The newer except exception-type as exception: syntax is not
supported by Python 2.4, we need to use except exception-type,
exception:.

Tested all trace backends with Python 2.4.

Reported-by: Andreas Färber afaer...@suse.de
Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
---
 scripts/tracetool.py |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/scripts/tracetool.py b/scripts/tracetool.py
index cacfd99..c003cf6 100755
--- a/scripts/tracetool.py
+++ b/scripts/tracetool.py
@@ -70,7 +70,7 @@ def main(args):
 
 try:
 opts, args = getopt.getopt(args[1:], , long_opts)
-except getopt.GetoptError as err:
+except getopt.GetoptError, err:
 error_opt(str(err))
 
 check_backend = False
@@ -131,7 +131,7 @@ def main(args):
 try:
 tracetool.generate(sys.stdin, arg_format, arg_backend,
binary = binary, probe_prefix = probe_prefix)
-except tracetool.TracetoolError as e:
+except tracetool.TracetoolError, e:
 error_opt(str(e))
 
 if __name__ == __main__:
-- 
1.7.10

[Qemu-devel] [PATCH v2 3/5] tracetool: avoid str.rpartition() Python 2.5 function

[Stefan Hajnoczi]

The str.rpartition() function is related to str.split() and is used for
splitting strings.  It was introduced in Python 2.5 and therefore cannot
be used in tracetool as Python 2.4 compatibility is required.

Replace the code using str.rsplit().

Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
---
 scripts/tracetool/__init__.py |   17 ++---
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/scripts/tracetool/__init__.py b/scripts/tracetool/__init__.py
index 49858c9..175df08 100644
--- a/scripts/tracetool/__init__.py
+++ b/scripts/tracetool/__init__.py
@@ -64,14 +64,17 @@ class Arguments:
 res = []
 for arg in arg_str.split(,):
 arg = arg.strip()
-parts = arg.split()
-head, sep, tail = parts[-1].rpartition(*)
-parts = parts[:-1]
-if tail == void:
-assert len(parts) == 0 and sep == 
+if arg == 'void':
 continue
-arg_type =  .join(parts + [  .join([head, sep]).strip() 
]).strip()
-res.append((arg_type, tail))
+
+if '*' in arg:
+arg_type, identifier = arg.rsplit('*', 1)
+arg_type += '*'
+identifier = identifier.strip()
+else:
+arg_type, identifier = arg.rsplit(None, 1)
+
+res.append((arg_type, identifier))
 return Arguments(res)
 
 def __iter__(self):
-- 
1.7.10

[Qemu-devel] [PATCH v2 4/5] configure: check for supported Python 2.x versions

[Stefan Hajnoczi]

The tracetool code requires Python 2.4, which was released in 2004.
Check for a supported Python version so we can give a clear error
message.

Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
---
 configure |7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/configure b/configure
index 25697bb..0e6fbbc 100755
--- a/configure
+++ b/configure
@@ -1247,9 +1247,10 @@ fi
 
 # Note that if the Python conditional here evaluates True we will exit
 # with status 1 which is a shell 'false' value.
-if ! $python -c 'import sys; sys.exit(sys.version_info[0] = 3)'; then
-  echo Python 2 required but '$python' is version 3 or better.
-  echo Use --python=/path/to/python to specify a Python 2.
+if ! $python -c 'import sys; sys.version_info  (2,4) or sys.version_info = 
(3,)'; then
+  echo Cannot use '$python', Python 2.4 or later is required.
+  echo Note that Python 3 or later is not yet supported.
+  echo Use --python=/path/to/python to specify a supported Python.
   exit 1
 fi
 
-- 
1.7.10

[Qemu-devel] [PATCH v2 2/5] tracetool: use Python 2.4-compatible __import__() arguments

[Stefan Hajnoczi]

In Python 2.5 keyword arguments were added to __import__().  Avoid using
them to achieve Python 2.4 compatibility.

Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
---
 scripts/tracetool/__init__.py |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/tracetool/__init__.py b/scripts/tracetool/__init__.py
index 74fe21b..49858c9 100644
--- a/scripts/tracetool/__init__.py
+++ b/scripts/tracetool/__init__.py
@@ -204,7 +204,7 @@ def try_import(mod_name, attr_name = None, attr_default = 
None):
 object or attribute value.
 
 try:
-module = __import__(mod_name, fromlist=[__package__])
+module = __import__(mod_name, globals(), locals(), [__package__])
 if attr_name is None:
 return True, module
 return True, getattr(module, str(attr_name), attr_default)
-- 
1.7.10

[Qemu-devel] [PATCH v2 5/5] tracetool: avoid pkgutil.iter_modules() Python 2.7 function

[Stefan Hajnoczi]

The pkgutil.iter_modules() function provides a way to enumerate child
modules.  Unfortunately it's missing in Python 2.7 so we must implement
similar behavior ourselves.

Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
---
 scripts/tracetool/backend/__init__.py |8 ++--
 scripts/tracetool/format/__init__.py  |8 ++--
 2 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/scripts/tracetool/backend/__init__.py 
b/scripts/tracetool/backend/__init__.py
index 34b7ed8..be43472 100644
--- a/scripts/tracetool/backend/__init__.py
+++ b/scripts/tracetool/backend/__init__.py
@@ -37,7 +37,7 @@ __maintainer__ = Stefan Hajnoczi
 __email__  = stefa...@linux.vnet.ibm.com
 
 
-import pkgutil
+import os
 
 import tracetool
 
@@ -45,7 +45,11 @@ import tracetool
 def get_list():
 Get a list of (name, description) pairs.
 res = [(nop, Tracing disabled.)]
-for _, modname, _ in pkgutil.iter_modules(tracetool.backend.__path__):
+modnames = []
+for filename in os.listdir(tracetool.backend.__path__[0]):
+if filename.endswith('.py') and filename != '__init__.py':
+modnames.append(filename.rsplit('.', 1)[0])
+for modname in modnames:
 module = tracetool.try_import(tracetool.backend. + modname)
 
 # just in case; should never fail unless non-module files are put there
diff --git a/scripts/tracetool/format/__init__.py 
b/scripts/tracetool/format/__init__.py
index 0e4baf0..3c2a0d8 100644
--- a/scripts/tracetool/format/__init__.py
+++ b/scripts/tracetool/format/__init__.py
@@ -41,7 +41,7 @@ __maintainer__ = Stefan Hajnoczi
 __email__  = stefa...@linux.vnet.ibm.com
 
 
-import pkgutil
+import os
 
 import tracetool
 
@@ -49,7 +49,11 @@ import tracetool
 def get_list():
 Get a list of (name, description) pairs.
 res = []
-for _, modname, _ in pkgutil.iter_modules(tracetool.format.__path__):
+modnames = []
+for filename in os.listdir(tracetool.format.__path__[0]):
+if filename.endswith('.py') and filename != '__init__.py':
+modnames.append(filename.rsplit('.', 1)[0])
+for modname in modnames:
 module = tracetool.try_import(tracetool.format. + modname)
 
 # just in case; should never fail unless non-module files are put there
-- 
1.7.10

Re: [Qemu-devel] [Qemu-ppc] [PATCH 20/22] ppc: move load and store helpers, switch to AREG0 free mode

[Alexander Graf]

On 30.04.2012, at 12:45, Alexander Graf wrote:

 
 On 22.04.2012, at 15:26, Blue Swirl wrote:
 
 Add an explicit CPUPPCState parameter instead of relying on AREG0
 and rename op_helper.c (which only contains load and store helpers)
 to mem_helper.c. Remove AREG0 swapping in
 tlb_fill().
 
 Switch to AREG0 free mode. Use cpu_ld{l,uw}_code in translation
 and interrupt handling, cpu_{ld,st}{l,uw}_data in loads and stores.
 
 This patch breaks qemu-system-ppc64 on ppc32 host user space for me. I'm 
 trying to debug it down, but worst case I'll omit this patch set for 1.1.

Ok, so apparently nobody ever tested TCG_AREG0 mode with the ppc tcg target. It 
looks as if the 64-bit-guest-registers-in-32-bit-host-registers code path is 
missing completely.

This actually makes me less confident that this is a change we want for 1.1. 
I'll remove the patches from the queue.


Alex


TCG register swizzling code:

#ifdef CONFIG_TCG_PASS_AREG0
/* XXX/FIXME: suboptimal */
tcg_out_mov(s, TCG_TYPE_I32, tcg_target_call_iarg_regs[3],
tcg_target_call_iarg_regs[2]);
tcg_out_mov(s, TCG_TYPE_I64, tcg_target_call_iarg_regs[2],
tcg_target_call_iarg_regs[1]);
tcg_out_mov(s, TCG_TYPE_TL, tcg_target_call_iarg_regs[1],
tcg_target_call_iarg_regs[0]);
tcg_out_mov(s, TCG_TYPE_PTR, tcg_target_call_iarg_regs[0],
TCG_AREG0);
#endif
tcg_out_call (s, (tcg_target_long) qemu_st_helpers[opc], 1);

Log output:

NIP fff024e4   LR  CTR  XER 

MSR  HID0 6000  HF  idx 1
TB  01083771 DECR 4293883502
GPR00    fff0
GPR04  24b0  
GPR08    
GPR12    
GPR16    
GPR20    
GPR24    
GPR28    
CR 8000  [ L  -  -  -  -  -  -  -  ] RES 
FPR00    
FPR04    
FPR08    
FPR12    
FPR16    
FPR20    
FPR24    
FPR28    
FPSCR 
 SRR0   SRR1 PVR 003c0301 VRSAVE 

SPRG0  SPRG1   SPRG2   SPRG3 

SPRG4  SPRG5   SPRG6   SPRG7 

 SDR1 
IN: 
0xfff024e4:  stw r6,0(r4)

OP:
  0xfff024e4
 movi_i32 access_type,$0x20
 mov_i32 tmp0,r4_0
 movi_i32 tmp1,$0x0
 qemu_st32 r6_0,tmp0,tmp1,$0x1
 goto_tb $0x0
 movi_i32 nip_0,$0xfff024e8
 movi_i32 nip_1,$0x0
 exit_tb $0xf4bae508

OUT: [size=180]
0xf5faf7a0:  lwz r14,36(r27)
0xf5faf7a4:  lwz r15,52(r27)
0xf5faf7a8:  li  r16,0
0xf5faf7ac:  li  r17,32
0xf5faf7b0:  stw r17,672(r27)
0xf5faf7b4:  rlwinm  r3,r14,25,19,26
0xf5faf7b8:  add r3,r3,r27
0xf5faf7bc:  lwzur4,8912(r3)
0xf5faf7c0:  rlwinm  r0,r14,0,30,19
0xf5faf7c4:  cmpwcr7,r0,r4
0xf5faf7c8:  lwz r4,4(r3)
0xf5faf7cc:  cmpwcr6,r16,r4
0xf5faf7d0:  crand   4*cr7+eq,4*cr6+eq,4*cr7+eq
0xf5faf7d4:  beq-cr7,0xf5faf80c
0xf5faf7d8:  mr  r3,r16
0xf5faf7dc:  mr  r4,r14
0xf5faf7e0:  mr  r5,r15
0xf5faf7e4:  li  r6,1
0xf5faf7e8:  mr  r6,r5
0xf5faf7ec:  mr  r5,r4
0xf5faf7f0:  mr  r4,r3
0xf5faf7f4:  mr  r3,r27
0xf5faf7f8:  lis r0,4123
0xf5faf7fc:  ori r0,r0,27696
0xf5faf800:  mtctr   r0
0xf5faf804:  bctrl
0xf5faf808:  b   0xf5faf818
0xf5faf80c:  lwz r3,16(r3)
0xf5faf810:  add r3,r3,r14
0xf5faf814:  stwxr15,0,r3
0xf5faf818:  .long 0x0
0xf5faf81c:  .long 0x0
0xf5faf820:  .long 0x0
0xf5faf824:  .long 0x0
0xf5faf828:  lis r14,-16
0xf5faf82c:  ori r14,r14,9448
0xf5faf830:  stw r14,668(r27)
0xf5faf834:  li  r14,0
0xf5faf838:  stw r14,664(r27)
0xf5faf83c:  lis r3,-2886
0xf5faf840:  ori r3,r3,58632
0xf5faf844:  lis r0,4264
0xf5faf848:  ori r0,r0,20192
0xf5faf84c:  mtctr   r0
0xf5faf850:  bctr

Register state at bctr into helper_stl_mmu (0xf5faf804)

Breakpoint 1, helper_stl_mmu (env=0x10ab1cb0, addr=0, val=4294967295, 

Re: [Qemu-devel] KVM call agenda for May, Thrusday 1st

[Anthony Liguori]

On 04/30/2012 04:17 AM, Juan Quintela wrote:



Hi

Please send in any agenda items you are interested in covering.


FYI, I won't be able to attend as I'll be at the LF End User Summit.

Regards,

Anthony Liguori



Thanks, Juan.

Re: [Qemu-devel] scsi-testsuite for virtio-scsi

[Stefan Hajnoczi]

On Sun, Apr 29, 2012 at 8:12 PM, Anthony Liguori anth...@codemonkey.ws wrote:
 On 04/28/2012 09:34 AM, Paolo Bonzini wrote:

 Il 28/04/2012 03:45, Zhi Yong Wu ha scritto:

 It's based on qemu-iotests, so the structure is familiar but uses
 sg3-utils to send SCSI commands instead of qemu-io.

 I think that those tests should be ran in guest, qemu-iotests has been
 merged into QEMU upstream, and those tests in it are mainly executed
 in host. Then will these scsi tests be maintained out of qemu-iotests?


 Yes, we can run these in qemu-test if Anthony adds sg_utils to qemu-jeos.


 FWIW, it ought to be trivial to setup a small Fedora guest that can run
 qemu-test tests.

 The only trouble is it'll run slower than qemu-jeos and we can't easily host
 binaries.  It also won't work for most architectures other than x86.

It's not ideal but if we had a kickstart file or another way of
building the guest with a single command, then at least regular QEMU
SCSI contributors and maintainers can use the test suite - I think a
Fedora guest would be fine.

Stefan

Re: [Qemu-devel] scsi-testsuite for virtio-scsi

[Anthony Liguori]

On 04/30/2012 06:59 AM, Stefan Hajnoczi wrote:

On Sun, Apr 29, 2012 at 8:12 PM, Anthony Liguorianth...@codemonkey.ws  wrote:

On 04/28/2012 09:34 AM, Paolo Bonzini wrote:


Il 28/04/2012 03:45, Zhi Yong Wu ha scritto:


It's based on qemu-iotests, so the structure is familiar but uses
sg3-utils to send SCSI commands instead of qemu-io.


I think that those tests should be ran in guest, qemu-iotests has been
merged into QEMU upstream, and those tests in it are mainly executed
in host. Then will these scsi tests be maintained out of qemu-iotests?



Yes, we can run these in qemu-test if Anthony adds sg_utils to qemu-jeos.



FWIW, it ought to be trivial to setup a small Fedora guest that can run
qemu-test tests.

The only trouble is it'll run slower than qemu-jeos and we can't easily host
binaries.  It also won't work for most architectures other than x86.


It's not ideal but if we had a kickstart file or another way of
building the guest with a single command, then at least regular QEMU
SCSI contributors and maintainers can use the test suite - I think a
Fedora guest would be fine.


At some point, I'll poke around and integrate sg3-utils into qemu-jeos but for 
now the most expedient thing would be to use a fedora guest.


Regards,

Anthony Liguori



Stefan

[Qemu-devel] [PATCH 0/2] SPI SDcard fixes v2

[Paul Brook]

Recent testing showed the SPI mode SD card emulation (ssi-sd.c) doesn't
actually work if the guest tries to use features from the SD Physical
Layer Specification v2 (this incluldes SDHC).

This series replaces my previous single patch.

Paul Brook (2):
  Fix SPI SD card command responses
  hw/sd.c: Implement CMD58

 hw/sd.c |  140 +--
 hw/sd.h |   17 
 hw/ssi-sd.c |   83 +++
 3 files changed, 138 insertions(+), 102 deletions(-)

-- 
1.7.10

[Qemu-devel] [PATCH 2/2] hw/sd.c: Implement CMD58

[Paul Brook]

Implement CMD58.  This command is only valid in SPI mode, and required when we
implement CMD8.  Most of the code is already there, we just need to
trigger it.

Signed-off-by: Paul Brook p...@codesourcery.com
---
 hw/sd.c |   15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/hw/sd.c b/hw/sd.c
index 220562e..952d5d8 100644
--- a/hw/sd.c
+++ b/hw/sd.c
@@ -141,7 +141,7 @@ static const sd_cmd_type_t sd_cmd_type[64] = {
 sd_ac,   sd_ac,   sd_none, sd_none, sd_none, sd_none, sd_ac,   sd_none,
 sd_none, sd_none, sd_bc,   sd_none, sd_none, sd_none, sd_none, sd_none,
 sd_none, sd_none, sd_none, sd_none, sd_none, sd_none, sd_none, sd_ac,
-sd_adtc, sd_none, sd_none, sd_none, sd_none, sd_none, sd_none, sd_none,
+sd_adtc, sd_none, sd_bcr,  sd_none,   sd_none, sd_none, sd_none, sd_none,
 };
 
 static const sd_cmd_type_t sd_acmd_type[64] = {
@@ -1223,6 +1223,19 @@ static sd_rsp_type_t sd_normal_command(SDState *sd,
 break;
 }
 break;
+case 58:/* CMD58: READ_OCR */
+if (!sd-spi) {
+goto bad_cmd;
+}
+switch (sd-state) {
+case sd_idle_state:
+case sd_transfer_state:
+return sd_r3;
+
+default:
+break;
+}
+break;
 
 default:
 bad_cmd:
-- 
1.7.10

[Qemu-devel] [PATCH 1/2] Fix SPI SD card command responses

[Paul Brook]

When in SPI mode, we give a bogus response to CMD8 (part of the SD physical
spec v2).  This command should return both the status byte and the
register value.

The current code returns long status words from sd.c, then parses translates
those to SPI status bytes ssi-sd.c.  For CMD8 (and CMD58 to follow)
this gets messy, with both parts requiring command specific knowledge.
We already have magic SPI-mode behavior in sd.c, so may as well just
generate the correct response there.

Signed-off-by: Paul Brook p...@codesourcery.com
---
 hw/sd.c |  125 ---
 hw/sd.h |   17 
 hw/ssi-sd.c |   83 +++
 3 files changed, 124 insertions(+), 101 deletions(-)

diff --git a/hw/sd.c b/hw/sd.c
index 07eb263..220562e 100644
--- a/hw/sd.c
+++ b/hw/sd.c
@@ -52,6 +52,7 @@ typedef enum {
 sd_r7,/* Operating voltage */
 sd_r1b = -1,
 sd_illegal = -2,
+sd_r1_long = -3, /* Two byte status in SPI mode.  */
 } sd_rsp_type_t;
 
 struct SDState {
@@ -342,24 +343,93 @@ static int sd_req_crc_validate(SDRequest *req)
 return sd_crc7(buffer, 5) != req-crc; /* TODO */
 }
 
-static void sd_response_r1_make(SDState *sd, uint8_t *response)
+
+/* Make SPI status word from full card status.  Most commands only use
+   the high byte.  */
+static uint16_t sd_get_spi_status(SDState *sd, uint32_t cardstatus)
+{
+uint16_t status = 0;
+
+if (((cardstatus  9)  0xf)  4)
+status |= SPI_SDR_IDLE;
+if (cardstatus  ERASE_RESET)
+status |= SPI_SDR_ERASE_RESET;
+if (cardstatus  ILLEGAL_COMMAND)
+status |= SPI_SDR_ILLEGAL_COMMAND;
+if (cardstatus  COM_CRC_ERROR)
+status |= SPI_SDR_COM_CRC_ERROR;
+if (cardstatus  ERASE_SEQ_ERROR)
+status |= SPI_SDR_ERASE_SEQ_ERROR;
+if (cardstatus  ADDRESS_ERROR)
+status |= SPI_SDR_ADDRESS_ERROR;
+if (cardstatus  CARD_IS_LOCKED)
+status |= SPI_SDR_LOCKED;
+if (cardstatus  (LOCK_UNLOCK_FAILED | WP_ERASE_SKIP))
+status |= SPI_SDR_WP_ERASE;
+if (cardstatus  SD_ERROR)
+status |= SPI_SDR_ERROR;
+if (cardstatus  CC_ERROR)
+status |= SPI_SDR_CC_ERROR;
+if (cardstatus  CARD_ECC_FAILED)
+status |= SPI_SDR_ECC_FAILED;
+if (cardstatus  WP_VIOLATION)
+status |= SPI_SDR_WP_VIOLATION;
+if (cardstatus  ERASE_PARAM)
+status |= SPI_SDR_ERASE_PARAM;
+if (cardstatus  (OUT_OF_RANGE | CID_CSD_OVERWRITE))
+status |= SPI_SDR_OUT_OF_RANGE;
+/* ??? Don't know what Parameter Error really means, so
+   assume it's set if the second byte is nonzero.  */
+if (status  0xff)
+status |= SPI_SDR_PARAMETER_ERROR;
+
+return status;
+}
+
+static int sd_response_r1_make(SDState *sd, uint8_t *response)
 {
 uint32_t status = sd-card_status;
 /* Clear the clear on read status bits */
 sd-card_status = ~CARD_STATUS_C;
 
-response[0] = (status  24)  0xff;
-response[1] = (status  16)  0xff;
-response[2] = (status  8)  0xff;
-response[3] = (status  0)  0xff;
+if (sd-spi) {
+response[0] = sd_get_spi_status(sd, status)  8;
+return 1;
+} else {
+response[0] = (status  24)  0xff;
+response[1] = (status  16)  0xff;
+response[2] = (status  8)  0xff;
+response[3] = (status  0)  0xff;
+return 4;
+}
+}
+
+/* Only used in SPI mode.  */
+static int sd_response_r1_long_make(SDState *sd, uint8_t *response)
+{
+uint32_t status = sd-card_status;
+/* Clear the clear on read status bits */
+sd-card_status = ~CARD_STATUS_C;
+status = sd_get_spi_status(sd, status);
+response[0] = status  8;
+response[1] = status  0xff;
+return 2;
 }
 
-static void sd_response_r3_make(SDState *sd, uint8_t *response)
+static int sd_response_r3_make(SDState *sd, uint8_t *response)
 {
-response[0] = (sd-ocr  24)  0xff;
-response[1] = (sd-ocr  16)  0xff;
-response[2] = (sd-ocr  8)  0xff;
-response[3] = (sd-ocr  0)  0xff;
+int len = 4;
+
+if (sd-spi) {
+len = 5;
+*(response++) = sd_get_spi_status(sd, sd-card_status)  8;
+}
+*(response++) = (sd-ocr  24)  0xff;
+*(response++) = (sd-ocr  16)  0xff;
+*(response++) = (sd-ocr  8)  0xff;
+*(response++) = (sd-ocr  0)  0xff;
+
+return len;
 }
 
 static void sd_response_r6_make(SDState *sd, uint8_t *response)
@@ -379,12 +449,20 @@ static void sd_response_r6_make(SDState *sd, uint8_t 
*response)
 response[3] = status  0xff;
 }
 
-static void sd_response_r7_make(SDState *sd, uint8_t *response)
+static int sd_response_r7_make(SDState *sd, uint8_t *response)
 {
-response[0] = (sd-vhs  24)  0xff;
-response[1] = (sd-vhs  16)  0xff;
-response[2] = (sd-vhs   8)  0xff;
-response[3] = (sd-vhs   0)  0xff;
+int len = 4;
+
+if (sd-spi) {
+len = 5;
+*(response++) = sd_get_spi_status(sd, sd-card_status)  8;
+}
+

Re: [Qemu-devel] Memory API: handling unassigned physical memory

[Mark Cave-Ayland]

On 30/04/12 09:41, Avi Kivity wrote:


Yes.  I think it's even possible to do this now, you can create an mmio
region for the bus and add subregions to it.  All subregions
automatically overlap the container region.

Simply replace

   memory_region_init(bus-address_space, ...)
   memory_region_add_subregion(bus-address_space, addr,dev-mmio)

with

   memory_region_init_io(bus-address_space,bus_nodev_ops, bus, ...)
   memory_region_add_subregion(bus-address_space, addr,dev-mmio) //
unchanged

This was never used so it hasn't been tested, but the code was written
with it in mind.  I didn't want to document this so we could back out of
it, but if it's useful, let's use it.


Hi Avi,

Well I've attempted to code something like this, but I've hit a problem 
with devices that aren't just used by SPARC, such as the disk controller 
- it seems that the sysbus API can only MMIO map devices into the root 
MemoryRegion :(


The SBUS I am trying to model is actually attached to the physical 
address bus, but effectively the top 4 bits of the address control the 
multiplexing of the on-board RAM and the individual per-slot address 
lines. Effectively what I'm trying to model based on a 128MB default 
memory setting is something like this:


Memory
0x0 - 0x007ff - Normal RAM

  SBus
  0x2000 - 0x02fff - SBus Slot 0
  0x3000 - 0x03fff - SBus Slot 1
  0x4000 - 0x04fff - SBus Slot 2
  0x5000 - 0x05fff - SBus Slot 3
0x5020 - 0x502f - TCX DAC
0x5030 - 0x5030081b - TCH THC8
0x50301000 - 0x50301fff - TCX THC24
0x5070 - 0x50700fff - TCX TEC

  0x6 - 0x06fff - SBus Slot 4
  0x7 - 0x07fff - SBus Slot 5

Using your example above, I believe I can create a simple memory 
hierarchy to represent this and catch unknown operations in a 
bus_nodev_ops section no problem. The issue is that several shared 
peripherals such as ESP have the following in their init function:


void esp_init(target_phys_addr_t espaddr, int it_shift,
  ESPDMAMemoryReadWriteFunc dma_memory_read,
  ESPDMAMemoryReadWriteFunc dma_memory_write,
  void *dma_opaque, qemu_irq irq, qemu_irq *reset,
  qemu_irq *dma_enable)
{
...
...
sysbus_mmio_map(s, 0, espaddr);
...
}

and sysbus_mmio_map() looks like this:

void sysbus_mmio_map(SysBusDevice *dev, int n, target_phys_addr_t addr)
{
...
...
memory_region_add_subregion(get_system_memory(),
addr,
dev-mmio[n].memory);
}

My understanding based upon this is that it would be impossible to 
register a different parent MemoryRegion without duplicating the init 
function for all shared devices which seems undesirable :(


The only solution I can think of is to make sysbus_mmio_map() more 
intelligent so that instead of blindly adding the device to the root 
MemoryRegion, it traverses down the MemoryRegion hierarchy starting from 
the root to the furtherest leaf node it can find based upon the 
specified address and then adds the new subregion there. Hence if I add 
my SBus memory regions first before call the various peripheral init 
functions, everything should end up in the correct part of the memory tree.


I believe this should preserve compatibility for existing sysbus API 
users with just a single root MemoryRegion, however due to lack of any 
documentation related to sysbus I'm not sure if this would break other 
platforms or maybe even violate one of its key design features?



ATB,

Mark.

[Qemu-devel] [PATCH V16 0/7] Qemu Trusted Platform Module (TPM) integration

[Stefan Berger]

The following series of patches adds TPM (Trusted Platform Module) support
to Qemu. An emulator for the TIS (TPM Interface Spec) interface is
added that provides the basis for accessing a 'backend' implementing the actual
TPM functionality. The TIS emulator serves as a 'frontend' enabling for
example Linux's TPM TIS (tpm_tis) driver.

In this series I am posting a backend implementation that makes use of the
host's TPM through a passthrough driver, which on Linux is accessed
using /dev/tpm0.

v16:
 - applied to checkout of 42fe1c2 (Apr 27)
 - followed Anthony's suggestions for v15
 - changed qemu-options.hx and vl.c to not show anything TPM-related if
   --enable-tpm-passthrough was not used on configure line

v15:
 - applies to checkout of 8a22565 (Mar 27)
 - replacing g_malloc's with g_new; no more checks for NULL after allocs
 - introducing usage of bottom half in TIS frontend to deliver responses
 - get rid of locks since global lock is held by all threads entering TIS
   code
 - cleanups

v14:
 - applies to checkout of da5361c (Dec 12)
 - implemented Anthony Liguori's suggestions
 - dropping the version log on individual patches

v13:
 - applies to checkout of 61a5872 (Dec 12)
 - only allowing character devices as fd parameter
 - fixing error path in tpm_tis_init

v12:
 - applies to checkout of ebffe2a (Oct 11)
 - added documentation for fd parameter
 - nits

v11:
 - applies to checkout of 46f3069 (Sep 28)
 - some filing on the documentation
 - small nits fixed

v10:
 - applies to checkout of 1ce9ce6 (Sep 27)
 - addressed Michael Tsirkin's comments on v9

v9:
 - addressed Michael Tsirkin's and other reviewers' comments
 - only posting Andreas Niederl's passthrough driver as the backend driver

v8:
 - applies to checkout of f0fb8b7 (Aug 30)
 - fixing compilation error pointed out by Andreas Niederl
 - adding patch that allows to feed an initial state into the libtpms TPM
 - following memory API changes (glib) where necessary

v7:
 - applies to checkout of b9c6cbf (Aug 9)
 - measuring the modules if multiboot is used
 - coding style fixes

v6:
 - applies to checkout of 75ef849 (July 2nd)
 - some fixes and improvements to existing patches; see individual patches
 - added a patch with a null driver responding to all TPM requests with
   a response indicating failure; this backend has no dependencies and
   can alwayy be built;
 - added a patch to support the hashing of kernel, ramfs and command line
   if those were passed to Qemu using -kernel, -initrd and -append
   respectively. Measurements are taken, logged, and passed to SeaBIOS using
   the firmware interface.
 - libtpms revision 7 now requires 83kb of block storage due to having more
   NVRAM space

v5:
 - applies to checkout of 1fddfba1
 - adding support for split command line using the -tpmdev ... -device ...
   options while keeping the -tpm option
 - support for querying the device models using -tpm model=?
 - support for monitor 'info tpm'
 - adding documentation of command line options for man page and web page
 - increasing room for ACPI tables that qemu reserves to 128kb (from 64kb)
 - adding (experimental) support for block migration
 - adding (experimental) support for taking measurements when kernel,
   initrd and kernel command line are directly passed to Qemu

v4:
 - applies to checkout of d2d979c6
 - more coding style fixes
 - adding patch for supporting blob encryption (in addition to the existing
   QCoW2-level encryption)
   - this allows for graceful termination of a migration if the target
 is detected to have a wrong key
   - tested with big and little endian hosts
 - main thread releases mutex while checking for work to do on behalf of
   backend
 - introducing file locking (fcntl) on the block layer for serializing access
   to shared (QCoW2) files (used during migration)

v3:
 - Building a null driver at patch 5/8 that responds to all requests
   with an error response; subsequently this driver is transformed to the
   libtpms-based driver for real TPM functionality
 - Reworked the threading; dropped the patch for qemu_thread_join; the
   main thread synchronizing with the TPM thread termination may need
   to write data to the block storage while waiting for the thread to 
   terminate; did not previously show a problem but is safer
 - A lot of testing based on recent git checkout 4b4a72e5 (4/10):
   - migration of i686 VM from x86_64 host to i686 host to ppc64 host while
 running tests inside the VM
   - tests with S3 suspend/resume
   - tests with snapshots
   - multiple-hour tests with VM suspend/resume (using virsh save/restore)
 while running a TPM test suite inside the VM
   All tests passed; [not all of them were done on the ppc64 host]

v2:
 - splitting some of the patches into smaller ones for easier review
 - fixes in individual patches

Regards,
Stefan


Stefan Berger (7):
  Support for TPM command line options
  Add TPM (frontend) hardware interface (TPM TIS) to Qemu
  Add a debug register
  

[Qemu-devel] [PATCH V16 4/7] Build the TPM frontend code

[Stefan Berger]

Build the TPM frontend code that has been added so far.

Signed-off-by: Stefan Berger stef...@linux.vnet.ibm.com
---
 Makefile.target |2 ++
 configure   |   11 +++
 2 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/Makefile.target b/Makefile.target
index 1cf6943..6a5f26f 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -229,6 +229,8 @@ obj-$(CONFIG_KVM) += kvm.o kvm-all.o
 obj-$(CONFIG_NO_KVM) += kvm-stub.o
 obj-$(CONFIG_VGA) += vga.o
 obj-y += memory.o savevm.o
+obj-y += tpm.o
+obj-$(CONFIG_TPM) += tpm_tis.o
 LIBS+=-lz
 
 obj-i386-$(CONFIG_KVM) += hyperv.o
diff --git a/configure b/configure
index 25697bb..1c5ce2d 100755
--- a/configure
+++ b/configure
@@ -195,6 +195,7 @@ zlib=yes
 guest_agent=yes
 libiscsi=
 coroutine=
+tpm=no
 
 # parse CC options first
 for opt do
@@ -827,6 +828,8 @@ for opt do
   ;;
   --disable-guest-agent) guest_agent=no
   ;;
+  --enable-tpm) tpm=yes
+  ;;
   *) echo ERROR: unknown option $opt; show_help=yes
   ;;
   esac
@@ -1118,6 +1121,7 @@ echo   --disable-guest-agentdisable building of the 
QEMU Guest Agent
 echo   --enable-guest-agent enable building of the QEMU Guest Agent
 echo   --with-coroutine=BACKEND coroutine backend. Supported options:
 echogthread, ucontext, sigaltstack, windows
+echo   --enable-tpm enable TPM support
 echo 
 echo NOTE: The object files are built at the place where configure is 
launched
 exit 1
@@ -3016,6 +3020,7 @@ echo OpenGL support$opengl
 echo libiscsi support  $libiscsi
 echo build guest agent $guest_agent
 echo coroutine backend $coroutine_backend
+echo TPM support   $tpm
 
 if test $sdl_too_old = yes; then
 echo - Your SDL version is too old - please upgrade to have SDL support
@@ -3906,6 +3911,12 @@ if test $gprof = yes ; then
   fi
 fi
 
+if test $tpm = yes; then
+  if test $target_softmmu = yes ; then
+echo CONFIG_TPM=y  $config_host_mak
+  fi
+fi
+
 if test $ARCH = tci; then
   linker_script=
 else
-- 
1.7.6.5

[Qemu-devel] [PATCH V16 5/7] Add a TPM Passthrough backend driver implementation

[Stefan Berger]

From Andreas Niederl's original posting with adaptations where necessary:

This patch is based of off version 9 of Stefan Berger's patch series
  Qemu Trusted Platform Module (TPM) integration
and adds a new backend driver for it.

This patch adds a passthrough backend driver for passing commands sent to the
emulated TPM device directly to a TPM device opened on the host machine.

Thus it is possible to use a hardware TPM device in a system running on QEMU,
providing the ability to access a TPM in a special state (e.g. after a Trusted
Boot).

This functionality is being used in the acTvSM Trusted Virtualization Platform
which is available on [1].

Usage example:
  qemu-system-x86_64 -tpmdev passthrough,id=tpm0,path=/dev/tpm0 \
 -device tpm-tis,tpmdev=tpm0 \
 -cdrom test.iso -boot d

Some notes about the host TPM:
The TPM needs to be enabled and activated. If that's not the case one
has to go through the BIOS/UEFI and enable and activate that TPM for TPM
commands to work as expected.
It may be necessary to boot the kernel using tpm_tis.force=1 in the boot
command line or 'modprobe tpm_tis force=1' in case of using it as a module.

Regards,
Andreas Niederl, Stefan Berger

[1] http://trustedjava.sourceforge.net/

Signed-off-by: Andreas Niederl andreas.nied...@iaik.tugraz.at
Signed-off-by: Stefan Berger stef...@linux.vnet.ibm.com
---
 Makefile.target  |3 +-
 configure|3 +
 hw/tpm_backend.c |   58 +++
 hw/tpm_backend.h |   43 ++
 hw/tpm_passthrough.c |  403 ++
 qemu-options.hx  |   38 +-
 tpm.c|   18 +++
 tpm.h|   33 
 vl.c |2 +
 9 files changed, 599 insertions(+), 2 deletions(-)
 create mode 100644 hw/tpm_backend.c
 create mode 100644 hw/tpm_backend.h
 create mode 100644 hw/tpm_passthrough.c

diff --git a/Makefile.target b/Makefile.target
index 6a5f26f..6802590 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -230,7 +230,8 @@ obj-$(CONFIG_NO_KVM) += kvm-stub.o
 obj-$(CONFIG_VGA) += vga.o
 obj-y += memory.o savevm.o
 obj-y += tpm.o
-obj-$(CONFIG_TPM) += tpm_tis.o
+obj-$(CONFIG_TPM) += tpm_tis.o tpm_backend.o
+obj-$(CONFIG_TPM_PASSTHROUGH) += tpm_passthrough.o
 LIBS+=-lz
 
 obj-i386-$(CONFIG_KVM) += hyperv.o
diff --git a/configure b/configure
index 1c5ce2d..b4e9cf9 100755
--- a/configure
+++ b/configure
@@ -3913,6 +3913,9 @@ fi
 
 if test $tpm = yes; then
   if test $target_softmmu = yes ; then
+if test $linux = yes ; then
+  echo CONFIG_TPM_PASSTHROUGH=y  $config_host_mak
+fi
 echo CONFIG_TPM=y  $config_host_mak
   fi
 fi
diff --git a/hw/tpm_backend.c b/hw/tpm_backend.c
new file mode 100644
index 000..4cf0809
--- /dev/null
+++ b/hw/tpm_backend.c
@@ -0,0 +1,58 @@
+/*
+ *  common TPM backend driver functions
+ *
+ *  Copyright (c) 2012 IBM Corporation
+ *  Authors:
+ *Stefan Berger stef...@us.ibm.com
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2 of the License, or (at your option) any later version.
+ *
+ * This library 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
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see http://www.gnu.org/licenses/
+ */
+
+#include tpm.h
+#include qemu-thread.h
+#include hw/tpm_backend.h
+
+void tpm_backend_thread_deliver_request(TPMBackendThread *tbt)
+{
+   g_thread_pool_push(tbt-pool, (gpointer)TPM_BACKEND_CMD_PROCESS_CMD, NULL);
+}
+
+void tpm_backend_thread_create(TPMBackendThread *tbt,
+   GFunc func, gpointer user_data)
+{
+if (!tbt-pool) {
+tbt-pool = g_thread_pool_new(func, user_data, 1, TRUE, NULL);
+g_thread_pool_push(tbt-pool, (gpointer)TPM_BACKEND_CMD_INIT, NULL);
+}
+}
+
+void tpm_backend_thread_end(TPMBackendThread *tbt)
+{
+if (tbt-pool) {
+g_thread_pool_push(tbt-pool, (gpointer)TPM_BACKEND_CMD_END, NULL);
+g_thread_pool_free(tbt-pool, FALSE, TRUE);
+tbt-pool = NULL;
+}
+}
+
+void tpm_backend_thread_tpm_reset(TPMBackendThread *tbt,
+  GFunc func, gpointer user_data)
+{
+if (!tbt-pool) {
+tpm_backend_thread_create(tbt, func, user_data);
+} else {
+g_thread_pool_push(tbt-pool, (gpointer)TPM_BACKEND_CMD_TPM_RESET,
+   NULL);
+}
+}
diff --git a/hw/tpm_backend.h b/hw/tpm_backend.h
new file mode 100644
index 000..f5fe198
--- /dev/null
+++ b/hw/tpm_backend.h
@@ -0,0 +1,43 @@
+/*
+ *  common TPM backend driver functions
+ *
+ *  Copyright (c) 2012 IBM Corporation
+ *  

[Qemu-devel] [PATCH V16 1/7] Support for TPM command line options

[Stefan Berger]

This patch adds support for TPM command line options.
The command line options supported here are

./qemu-... -tpmdev passthrough,path=path to TPM device,id=id
   -device tpm-tis,tpmdev=id

and

./qemu-... -tpmdev ?

where the latter works similar to -soundhw ? and shows a list of
available TPM backends (for example 'passthrough').

Using the type parameter, the backend is chosen, i.e., 'passthrough' for the
passthrough driver. The interpretation of the other parameters along
with determining whether enough parameters were provided is pushed into
the backend driver, which needs to implement the interface function
'create' and return a TPMDriver structure if the VM can be started or 'NULL'
if not enough or bad parameters were provided.

Monitor support for 'info tpm' has been added. It for example prints the
following:

(qemu) info tpm
TPM devices:
 tpm0: model=tpm-tis
  \ tpm0: type=passthrough,path=/dev/tpm0

Signed-off-by: Stefan Berger stef...@linux.vnet.ibm.com
---
 hmp-commands.hx  |2 +
 hmp.c|   28 +++
 hmp.h|1 +
 hw/tpm_tis.h |   78 
 monitor.c|8 ++
 qapi-schema.json |   29 
 qemu-config.c|   20 +
 qemu-options.hx  |   33 +
 tpm.c|  213 ++
 tpm.h|   81 +
 vl.c |   17 +
 11 files changed, 510 insertions(+), 0 deletions(-)
 create mode 100644 hw/tpm_tis.h
 create mode 100644 tpm.c
 create mode 100644 tpm.h

diff --git a/hmp-commands.hx b/hmp-commands.hx
index 18cb415..08f6942 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -1401,6 +1401,8 @@ show device tree
 show qdev device model list
 @item info roms
 show roms
+@item info tpm
+show the TPM device
 @end table
 ETEXI
 
diff --git a/hmp.c b/hmp.c
index eb96618..7e130c5 100644
--- a/hmp.c
+++ b/hmp.c
@@ -546,6 +546,34 @@ void hmp_info_block_jobs(Monitor *mon)
 }
 }
 
+void hmp_info_tpm(Monitor *mon)
+{
+TPMInfoList *info_list, *info;
+Error *err = NULL;
+unsigned int c = 0;
+
+info_list = qmp_query_tpm(err);
+if (err) {
+monitor_printf(mon, TPM device not supported\n);
+error_free(err);
+return;
+}
+
+monitor_printf(mon, TPM device:\n);
+
+for (info = info_list; info; info = info-next) {
+TPMInfo *ti = info-value;
+monitor_printf(mon,  tpm%d: model=%s\n,
+   c, ti-model);
+monitor_printf(mon,   \\ %s: type=%s%s%s\n,
+   ti-id, ti-type,
+   ti-parameters ? , : ,
+   ti-parameters ? ti-parameters : );
+c++;
+}
+qapi_free_TPMInfoList(info_list);
+}
+
 void hmp_quit(Monitor *mon, const QDict *qdict)
 {
 monitor_suspend(mon);
diff --git a/hmp.h b/hmp.h
index 443b812..8e2a858 100644
--- a/hmp.h
+++ b/hmp.h
@@ -33,6 +33,7 @@ void hmp_info_spice(Monitor *mon);
 void hmp_info_balloon(Monitor *mon);
 void hmp_info_pci(Monitor *mon);
 void hmp_info_block_jobs(Monitor *mon);
+void hmp_info_tpm(Monitor *mon);
 void hmp_quit(Monitor *mon, const QDict *qdict);
 void hmp_stop(Monitor *mon, const QDict *qdict);
 void hmp_system_reset(Monitor *mon, const QDict *qdict);
diff --git a/hw/tpm_tis.h b/hw/tpm_tis.h
new file mode 100644
index 000..5e1f731
--- /dev/null
+++ b/hw/tpm_tis.h
@@ -0,0 +1,78 @@
+/*
+ * tpm_tis.c - QEMU's TPM TIS interface emulator
+ *
+ * Copyright (C) 2006,2010,2011 IBM Corporation
+ *
+ * Authors:
+ *  Stefan Berger stef...@us.ibm.com
+ *  David Safford saff...@us.ibm.com
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ *
+ * Implementation of the TIS interface according to specs found at
+ * http://www.trustedcomputiggroup.org
+ *
+ */
+#ifndef HW_TPM_TIS_H
+#define HW_TPM_TIS_H
+
+#include isa.h
+#include qemu-common.h
+
+#define TPM_TIS_ADDR_BASE   0xFED4
+
+#define TPM_TIS_NUM_LOCALITIES  5 /* per spec */
+#define TPM_TIS_LOCALITY_SHIFT  12
+#define TPM_TIS_NO_LOCALITY 0xff
+
+#define TPM_TIS_IS_VALID_LOCTY(x)   ((x)  TPM_TIS_NUM_LOCALITIES)
+
+#define TPM_TIS_IRQ 5
+
+#define TPM_TIS_BUFFER_MAX  4096
+
+
+typedef struct TPMSizedBuffer {
+uint32_t size;
+uint8_t  *buffer;
+} TPMSizedBuffer;
+
+typedef enum {
+TPM_TIS_STATUS_IDLE = 0,
+TPM_TIS_STATUS_READY,
+TPM_TIS_STATUS_COMPLETION,
+TPM_TIS_STATUS_EXECUTION,
+TPM_TIS_STATUS_RECEPTION,
+} TPMTISStatus;
+
+/* locality data  -- all fields are persisted */
+typedef struct TPMLocality {
+TPMTISStatus status;
+uint8_t access;
+uint8_t sts;
+uint32_t inte;
+uint32_t ints;
+
+uint16_t w_offset;
+uint16_t r_offset;
+TPMSizedBuffer w_buffer;
+TPMSizedBuffer r_buffer;
+} TPMLocality;
+
+typedef struct TPMTISState {
+QEMUBH *bh;
+uint32_t offset;
+uint8_t buf[TPM_TIS_BUFFER_MAX];
+
+  

[Qemu-devel] [PATCH V16 3/7] Add a debug register

[Stefan Berger]

This patch uses the possibility to add a vendor-specific register and
adds a debug register useful for dumping the TIS's internal state. This
register is only active in a debug build (#define DEBUG_TIS).

Signed-off-by: Stefan Berger stef...@linux.vnet.ibm.com
---
 hw/tpm_tis.c |   70 ++
 1 files changed, 70 insertions(+), 0 deletions(-)

diff --git a/hw/tpm_tis.c b/hw/tpm_tis.c
index 02b9c2e..5f8899d 100644
--- a/hw/tpm_tis.c
+++ b/hw/tpm_tis.c
@@ -52,6 +52,9 @@
 #define TPM_TIS_REG_DID_VID   0xf00
 #define TPM_TIS_REG_RID   0xf04
 
+/* vendor-specific registers */
+#define TPM_TIS_REG_DEBUG 0xf90
+
 #define TPM_TIS_STS_VALID (1  7)
 #define TPM_TIS_STS_COMMAND_READY (1  6)
 #define TPM_TIS_STS_TPM_GO(1  5)
@@ -97,6 +100,11 @@
 
 #define TPM_TIS_NO_DATA_BYTE  0xff
 
+/* local prototypes */
+
+static uint64_t tpm_tis_mmio_read(void *opaque, target_phys_addr_t addr,
+  unsigned size);
+
 /* utility functions */
 
 static uint8_t tpm_tis_locality_from_addr(target_phys_addr_t addr)
@@ -331,6 +339,63 @@ static uint32_t tpm_tis_data_read(TPMState *s, uint8_t 
locty)
 return ret;
 }
 
+#ifdef DEBUG_TIS
+static void tpm_tis_dump_state(void *opaque, target_phys_addr_t addr)
+{
+static const unsigned regs[] = {
+TPM_TIS_REG_ACCESS,
+TPM_TIS_REG_INT_ENABLE,
+TPM_TIS_REG_INT_VECTOR,
+TPM_TIS_REG_INT_STATUS,
+TPM_TIS_REG_INTF_CAPABILITY,
+TPM_TIS_REG_STS,
+TPM_TIS_REG_DID_VID,
+TPM_TIS_REG_RID,
+0xfff};
+int idx;
+uint8_t locty = tpm_tis_locality_from_addr(addr);
+target_phys_addr_t base = addr  ~0xfff;
+TPMState *s = opaque;
+TPMTISState *tis = s-s.tis;
+
+dprintf(tpm_tis: active locality  : %d\n
+tpm_tis: state of locality %d : %d\n
+tpm_tis: register dump:\n,
+tis-active_locty,
+locty, tis-loc[locty].status);
+
+for (idx = 0; regs[idx] != 0xfff; idx++) {
+dprintf(tpm_tis: 0x%04x : 0x%08x\n, regs[idx],
+(uint32_t)tpm_tis_mmio_read(opaque, base + regs[idx], 4));
+}
+
+dprintf(tpm_tis: read offset   : %d\n
+tpm_tis: result buffer : ,
+tis-loc[locty].r_offset);
+for (idx = 0;
+ idx  tpm_tis_get_size_from_buffer(tis-loc[locty].r_buffer);
+ idx++) {
+dprintf(%c%02x%s,
+tis-loc[locty].r_offset == idx ? '' : ' ',
+tis-loc[locty].r_buffer.buffer[idx],
+((idx  0xf) == 0xf) ? \ntpm_tis:  : );
+}
+dprintf(\n
+tpm_tis: write offset  : %d\n
+tpm_tis: request buffer: ,
+tis-loc[locty].w_offset);
+for (idx = 0;
+ idx  tpm_tis_get_size_from_buffer(tis-loc[locty].w_buffer);
+ idx++) {
+dprintf(%c%02x%s,
+tis-loc[locty].w_offset == idx ? '' : ' ',
+tis-loc[locty].w_buffer.buffer[idx],
+((idx  0xf) == 0xf) ? \ntpm_tis:  : );
+}
+dprintf(\n);
+}
+#endif
+
 /*
  * Read a register of the TIS interface
  * See specs pages 33-63 for description of the registers
@@ -400,6 +465,11 @@ static uint64_t tpm_tis_mmio_read(void *opaque, 
target_phys_addr_t addr,
 case TPM_TIS_REG_RID:
 val = TPM_TIS_TPM_RID;
 break;
+#ifdef DEBUG_TIS
+case TPM_TIS_REG_DEBUG:
+tpm_tis_dump_state(opaque, addr);
+break;
+#endif
 }
 
 if (shift) {
-- 
1.7.6.5

[Qemu-devel] [PATCH V16 2/7] Add TPM (frontend) hardware interface (TPM TIS) to Qemu

[Stefan Berger]

This patch adds the main code of the TPM frontend driver, the TPM TIS
interface, to Qemu. The code is largely based on the previous implementation
for Xen but has been significantly extended to meet the standard's
requirements, such as the support for changing of localities and all the
functionality of the available flags.

Communication with the backend (i.e., for Xen or the libtpms-based one)
is cleanly separated through an interface which the backend driver needs
to implement.

The TPM TIS driver's backend was previously chosen in the code added
to arch_init. The frontend holds a pointer to the chosen backend (interface).

Communication with the backend is largely based on signals and conditions.
Whenever the frontend has collected a complete packet, it will signal
the backend, which then starts processing the command. Once the result
has been returned, the backend invokes a callback function
(tis_tpm_receive_cb()).

The one tricky part is support for VM suspend while the TPM is processing
a command. In this case the frontend driver is waiting for the backend
to return the result of the last command before shutting down. It waits
on a condition for a signal from the backend, which is delivered in
tis_tpm_receive_cb().

Testing the proper functioning of the different flags and localities
cannot be done from user space when running in Linux for example, since
access to the address space of the TPM TIS interface is not possible. Also
the Linux driver itself does not exercise all functionality. So, for
testing there is a fairly extensive test suite as part of the SeaBIOS patches
since from within the BIOS one can have full access to all the TPM's registers.


Signed-off-by: Stefan Berger stef...@linux.vnet.ibm.com
---
 hw/tpm_tis.c |  822 ++
 1 files changed, 822 insertions(+), 0 deletions(-)
 create mode 100644 hw/tpm_tis.c

diff --git a/hw/tpm_tis.c b/hw/tpm_tis.c
new file mode 100644
index 000..02b9c2e
--- /dev/null
+++ b/hw/tpm_tis.c
@@ -0,0 +1,822 @@
+/*
+ * tpm_tis.c - QEMU's TPM TIS interface emulator
+ *
+ * Copyright (C) 2006,2010,2011 IBM Corporation
+ *
+ * Authors:
+ *  Stefan Berger stef...@us.ibm.com
+ *  David Safford saff...@us.ibm.com
+ *
+ * Xen 4 support: Andrease Niederl andreas.nied...@iaik.tugraz.at
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ *
+ * Implementation of the TIS interface according to specs found at
+ * http://www.trustedcomputiggroup.org.
+ * In the developers menu choose the PC Client section then find the TIS
+ * specification.
+ */
+
+#include tpm.h
+#include block.h
+#include exec-memory.h
+#include hw/hw.h
+#include hw/pc.h
+#include hw/pci_ids.h
+#include hw/tpm_tis.h
+#include qemu-error.h
+#include qemu-common.h
+
+/*#define DEBUG_TIS */
+
+#ifdef DEBUG_TIS
+#define dprintf(fmt, ...) \
+do { fprintf(stderr, fmt, ## __VA_ARGS__); } while (0)
+#else
+#define dprintf(fmt, ...) \
+do { } while (0)
+#endif
+
+/* whether the STS interrupt is supported */
+/*#define RAISE_STS_IRQ */
+
+/* tis registers */
+#define TPM_TIS_REG_ACCESS0x00
+#define TPM_TIS_REG_INT_ENABLE0x08
+#define TPM_TIS_REG_INT_VECTOR0x0c
+#define TPM_TIS_REG_INT_STATUS0x10
+#define TPM_TIS_REG_INTF_CAPABILITY   0x14
+#define TPM_TIS_REG_STS   0x18
+#define TPM_TIS_REG_DATA_FIFO 0x24
+#define TPM_TIS_REG_DID_VID   0xf00
+#define TPM_TIS_REG_RID   0xf04
+
+#define TPM_TIS_STS_VALID (1  7)
+#define TPM_TIS_STS_COMMAND_READY (1  6)
+#define TPM_TIS_STS_TPM_GO(1  5)
+#define TPM_TIS_STS_DATA_AVAILABLE(1  4)
+#define TPM_TIS_STS_EXPECT(1  3)
+#define TPM_TIS_STS_RESPONSE_RETRY(1  1)
+
+#define TPM_TIS_ACCESS_TPM_REG_VALID_STS  (1  7)
+#define TPM_TIS_ACCESS_ACTIVE_LOCALITY(1  5)
+#define TPM_TIS_ACCESS_BEEN_SEIZED(1  4)
+#define TPM_TIS_ACCESS_SEIZE  (1  3)
+#define TPM_TIS_ACCESS_PENDING_REQUEST(1  2)
+#define TPM_TIS_ACCESS_REQUEST_USE(1  1)
+#define TPM_TIS_ACCESS_TPM_ESTABLISHMENT  (1  0)
+
+#define TPM_TIS_INT_ENABLED   (1  31)
+#define TPM_TIS_INT_DATA_AVAILABLE(1  0)
+#define TPM_TIS_INT_STS_VALID (1  1)
+#define TPM_TIS_INT_LOCALITY_CHANGED  (1  2)
+#define TPM_TIS_INT_COMMAND_READY (1  7)
+
+#ifndef RAISE_STS_IRQ
+
+#define TPM_TIS_INTERRUPTS_SUPPORTED (TPM_TIS_INT_LOCALITY_CHANGED | \
+  TPM_TIS_INT_DATA_AVAILABLE   | \
+  TPM_TIS_INT_COMMAND_READY)
+
+#else
+
+#define TPM_TIS_INTERRUPTS_SUPPORTED (TPM_TIS_INT_LOCALITY_CHANGED | \
+  TPM_TIS_INT_DATA_AVAILABLE   | \
+  TPM_TIS_INT_STS_VALID | \
+  

[Qemu-devel] [PATCH V16 7/7] Add fd parameter for TPM passthrough driver

[Stefan Berger]

Enable the passing of a file descriptor via fd=.. to access the host's
TPM device using the TPM passthrough driver.

Signed-off-by: Stefan Berger stef...@linux.vnet.ibm.com
---
 hw/tpm_passthrough.c |   61 ++---
 qemu-config.c|5 
 qemu-options.hx  |   11 ++--
 3 files changed, 60 insertions(+), 17 deletions(-)

diff --git a/hw/tpm_passthrough.c b/hw/tpm_passthrough.c
index 11980a8..a296048 100644
--- a/hw/tpm_passthrough.c
+++ b/hw/tpm_passthrough.c
@@ -306,30 +306,62 @@ static int tpm_passthrough_handle_device_opts(QemuOpts 
*opts, TPMBackend *tb)
 {
 const char *value;
 size_t bufsize;
+struct stat statbuf;
 
-value = qemu_opt_get(opts, path);
-if (!value) {
-value = TPM_PASSTHROUGH_DEFAULT_DEVICE;
-}
+value = qemu_opt_get(opts, fd);
+if (value) {
+if (qemu_opt_get(opts, path)) {
+error_report(fd= is invalid with path=);
+goto err_exit;
+}
+
+tb-s.tpm_pt-tpm_fd = qemu_parse_fd(value);
+if (tb-s.tpm_pt-tpm_fd  0) {
+error_report(Illegal file descriptor for TPM device.\n);
+goto err_exit;
+}
+
+bufsize = sizeof(fd=) + sizeof(stringify(INT_MAX)) + 1;
+
+tb-parameters = g_malloc0(bufsize);
+
+snprintf(tb-parameters, bufsize, fd=%d, tb-s.tpm_pt-tpm_fd);
+} else {
+value = qemu_opt_get(opts, path);
+if (!value) {
+value = TPM_PASSTHROUGH_DEFAULT_DEVICE;
+}
+
+tb-s.tpm_pt-tpm_dev = g_strdup(value);
 
-tb-s.tpm_pt-tpm_dev = g_strdup(value);
+bufsize = sizeof(path=) + strlen(tb-s.tpm_pt-tpm_dev) + 1;
 
-bufsize = sizeof(path=) + strlen(tb-s.tpm_pt-tpm_dev) + 1;
+tb-parameters = g_malloc0(bufsize);
 
-tb-parameters = g_malloc0(bufsize);
+snprintf(tb-parameters, bufsize, path=%s, tb-s.tpm_pt-tpm_dev);
 
-snprintf(tb-parameters, bufsize, path=%s, tb-s.tpm_pt-tpm_dev);
+tb-s.tpm_pt-tpm_fd = open(tb-s.tpm_pt-tpm_dev, O_RDWR);
+if (tb-s.tpm_pt-tpm_fd  0) {
+error_report(Cannot access TPM device using '%s'.\n,
+ tb-s.tpm_pt-tpm_dev);
+goto err_free_parameters;
+}
+}
+
+if (fstat(tb-s.tpm_pt-tpm_fd, statbuf) != 0) {
+error_report(Cannot determine file descriptor type for TPM 
+ device: %s, strerror(errno));
+goto err_close_tpmdev;
+}
 
-tb-s.tpm_pt-tpm_fd = open(tb-s.tpm_pt-tpm_dev, O_RDWR);
-if (tb-s.tpm_pt-tpm_fd  0) {
-error_report(Cannot access TPM device using '%s'.\n,
- tb-s.tpm_pt-tpm_dev);
+/* only allow character devices for now */
+if (!S_ISCHR(statbuf.st_mode)) {
+error_report(TPM file descriptor is not a character device);
 goto err_free_parameters;
 }
 
 if (tpm_passthrough_test_tpmdev(tb-s.tpm_pt-tpm_fd)) {
-error_report('%s' is not a TPM device.\n,
- tb-s.tpm_pt-tpm_dev);
+error_report(Device is not a TPM.\n);
 goto err_close_tpmdev;
 }
 
@@ -346,6 +378,7 @@ static int tpm_passthrough_handle_device_opts(QemuOpts 
*opts, TPMBackend *tb)
 g_free(tb-s.tpm_pt-tpm_dev);
 tb-s.tpm_pt-tpm_dev = NULL;
 
+ err_exit:
 return 1;
 }
 
diff --git a/qemu-config.c b/qemu-config.c
index edc8d5d..a5e2677 100644
--- a/qemu-config.c
+++ b/qemu-config.c
@@ -628,6 +628,11 @@ static QemuOptsList qemu_tpmdev_opts = {
 .type = QEMU_OPT_STRING,
 .help = Persistent storage for TPM state,
 },
+{
+.name = fd,
+.type = QEMU_OPT_STRING,
+.help = Filedescriptor for accessing the TPM,
+},
 { /* end of list */ }
 },
 };
diff --git a/qemu-options.hx b/qemu-options.hx
index b9920da..679a194 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -2008,8 +2008,9 @@ DEFHEADING()
 DEFHEADING(TPM device options:)
 
 DEF(tpmdev, HAS_ARG, QEMU_OPTION_tpmdev, \
--tpmdev passthrough,id=id[,path=path]\n
-use path to provide path to a character device; default 
is /dev/tpm0\n,
+-tpmdev passthrough,id=id[,path=path][,fd=h]\n
+use path to provide path to a character device; default 
is /dev/tpm0\n
+use fd to provide a file descriptor to a character 
device\n,
 QEMU_ARCH_ALL)
 STEXI
 
@@ -2031,7 +2032,7 @@ Use ? to print all available TPM backend types.
 qemu -tpmdev ?
 @end example
 
-@item -tpmdev passthrough, id=@var{id}, path=@var{path}
+@item -tpmdev passthrough, id=@var{id}, path=@var{path}, fd=@var{h}
 
 (Linux-host only) Enable access to the host's TPM using the passthrough
 driver.
@@ -2040,6 +2041,10 @@ driver.
 a Linux host this would be @code{/dev/tpm0}.
 @option{path} is optional and by default @code{/dev/tpm0} is used.
 
+@option{fd} specifies the file descriptor of the host's TPM device.
+@option{fd} and @option{path} are 

[Qemu-devel] [PATCH V16 6/7] Introduce --enable-tpm-passthrough configure option

[Stefan Berger]

Introduce --enable-tpm-passthrough configure option.

Signed-off-by: Stefan Berger stef...@linux.vnet.ibm.com
---
 configure |   16 +++-
 1 files changed, 15 insertions(+), 1 deletions(-)

diff --git a/configure b/configure
index b4e9cf9..1911204 100755
--- a/configure
+++ b/configure
@@ -196,6 +196,7 @@ guest_agent=yes
 libiscsi=
 coroutine=
 tpm=no
+tpm_passthrough=no
 
 # parse CC options first
 for opt do
@@ -830,11 +831,20 @@ for opt do
   ;;
   --enable-tpm) tpm=yes
   ;;
+  --enable-tpm-passthrough) tpm_passthrough=yes
+  ;;
   *) echo ERROR: unknown option $opt; show_help=yes
   ;;
   esac
 done
 
+if test $tpm = no ; then
+if test $tpm_passthrough = yes; then
+echo ERROR: --enable-tpm-passthrough requires --enable-tpm
+exit 1
+fi
+fi
+
 #
 # If cpu ~= sparc and  sparc_cpu hasn't been defined, plug in the right
 # QEMU_CFLAGS/LDFLAGS (assume sparc_v8plus for 32-bit and sparc_v9 for 64-bit)
@@ -1122,6 +1132,7 @@ echo   --enable-guest-agent enable building of the 
QEMU Guest Agent
 echo   --with-coroutine=BACKEND coroutine backend. Supported options:
 echogthread, ucontext, sigaltstack, windows
 echo   --enable-tpm enable TPM support
+echo   --enable-tpm-passthrough enable TPM passthrough driver
 echo 
 echo NOTE: The object files are built at the place where configure is 
launched
 exit 1
@@ -3021,6 +3032,7 @@ echo libiscsi support  $libiscsi
 echo build guest agent $guest_agent
 echo coroutine backend $coroutine_backend
 echo TPM support   $tpm
+echo TPM passthrough   $tpm_passthrough
 
 if test $sdl_too_old = yes; then
 echo - Your SDL version is too old - please upgrade to have SDL support
@@ -3914,7 +3926,9 @@ fi
 if test $tpm = yes; then
   if test $target_softmmu = yes ; then
 if test $linux = yes ; then
-  echo CONFIG_TPM_PASSTHROUGH=y  $config_host_mak
+  if test $tpm_passthrough = yes ; then
+echo CONFIG_TPM_PASSTHROUGH=y  $config_host_mak
+  fi
 fi
 echo CONFIG_TPM=y  $config_host_mak
   fi
-- 
1.7.6.5

Re: [Qemu-devel] [Bug 990364] [NEW] virtio_ioport_write: unexpected address 0x13 value 0x1

[Stefan Hajnoczi]

Hi Vadim,
Here is a recent bug report with virtio-win-0.1-22.iso.  Wanted to
bring it to your attention, please let me know if you already monitor
these bug emails.

Stefan

On Sat, Apr 28, 2012 at 9:49 AM, Vitalis wor...@gmail.com wrote:
 Public bug reported:

 Hello! I have:

 virtio_ioport_write: unexpected address 0x13 value 0x1

 on config:

 LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin 
 QEMU_AUDIO_DRV=none /usr/bin/kvm -S -M pc-0.12 -cpu qemu32 -enable-kvm -m 
 3072 -smp 1 -name nata_xp -uuid da607499-1d8f-e7ef-d1d2-38
 1c1839e4ba -chardev 
 socket,id=monitor,path=/var/lib/libvirt/qemu/nata_xp.monitor,server,nowait 
 -monitor chardev:monitor -localtime -boot c -drive 
 file=/root/nata_xp.qcow2,if=virtio,index=0,boot=on,format=raw
 ,cache=none -drive 
 file=/home/admino/virtio-win-0.1-22.iso,if=ide,media=cdrom,index=2,format=raw 
 -net nic,macaddr=00:16:36:06:02:69,vlan=0,model=virtio,name=virtio.0 -net 
 tap,fd=43,vlan=0,name=tap.0 -serial
 none -parallel none -usb -usbdevice tablet -vnc 127.0.0.1:3 -k en-us -vga 
 cirrus
 pci_add_option_rom: failed to find romfile pxe-virtio.bin

 with kernel 2.6.32-40-generic #87-Ubuntu SMP Tue Mar 6 00:56:56 UTC 2012 
 x86_64 GNU/Linux
 qemu drivers are virtio-win-0.1-22.iso
 kvm version 1:84+dfsg-0ubuntu16+0.12.3+noroms+0ubuntu9.18
 qemu 0.12.3+noroms-0ubuntu9.18

 ** Affects: qemu
     Importance: Undecided
         Status: New


 ** Tags: bug kvm virtio

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

 Title:
  virtio_ioport_write: unexpected address 0x13 value 0x1

 Status in QEMU:
  New

 Bug description:
  Hello! I have:

  virtio_ioport_write: unexpected address 0x13 value 0x1

  on config:

  LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin 
 QEMU_AUDIO_DRV=none /usr/bin/kvm -S -M pc-0.12 -cpu qemu32 -enable-kvm -m 
 3072 -smp 1 -name nata_xp -uuid da607499-1d8f-e7ef-d1d2-38
  1c1839e4ba -chardev 
 socket,id=monitor,path=/var/lib/libvirt/qemu/nata_xp.monitor,server,nowait 
 -monitor chardev:monitor -localtime -boot c -drive 
 file=/root/nata_xp.qcow2,if=virtio,index=0,boot=on,format=raw
  ,cache=none -drive 
 file=/home/admino/virtio-win-0.1-22.iso,if=ide,media=cdrom,index=2,format=raw 
 -net nic,macaddr=00:16:36:06:02:69,vlan=0,model=virtio,name=virtio.0 -net 
 tap,fd=43,vlan=0,name=tap.0 -serial
  none -parallel none -usb -usbdevice tablet -vnc 127.0.0.1:3 -k en-us -vga 
 cirrus
  pci_add_option_rom: failed to find romfile pxe-virtio.bin

  with kernel 2.6.32-40-generic #87-Ubuntu SMP Tue Mar 6 00:56:56 UTC 2012 
 x86_64 GNU/Linux
  qemu drivers are virtio-win-0.1-22.iso
  kvm version 1:84+dfsg-0ubuntu16+0.12.3+noroms+0ubuntu9.18
  qemu 0.12.3+noroms-0ubuntu9.18

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

Re: [Qemu-devel] [PATCH 1/2] qcow2: remove a line of unnecessary code

[Stefan Hajnoczi]

On Sat, Apr 28, 2012 at 8:37 AM,  zwu.ker...@gmail.com wrote:
 From: Zhi Yong Wu wu...@linux.vnet.ibm.com

 Signed-off-by: Zhi Yong Wu wu...@linux.vnet.ibm.com
 ---
  block/qcow2-cluster.c |    1 -
  1 files changed, 0 insertions(+), 1 deletions(-)

Reviewed-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com

I took a look to understand why that line of code was there.  This can
be important in case there was a mis-merge.

commit 3948d1d4876065160583e79533bf604481063833
Author: Kevin Wolf kw...@redhat.com
Date:   Mon Mar 12 17:46:51 2012 +0100

qcow2: Remove unused parameter in get_cluster_table()

Since everything goes through the cache, callers don't use the L2 table
offset any more.

This commit removed the pointer argument we filled in with l2_offset
but forgot to remove the unnecessary l2_offset assignment.

It's worth adding this sort of info into commit descriptions in the future.

Stefan

Re: [Qemu-devel] [PATCH 2/2] qcow2: fix the byte endian convertion

[Stefan Hajnoczi]

On Sat, Apr 28, 2012 at 8:38 AM,  zwu.ker...@gmail.com wrote:
 From: Zhi Yong Wu wu...@linux.vnet.ibm.com

 Signed-off-by: Zhi Yong Wu wu...@linux.vnet.ibm.com
 ---
  block/qcow2-refcount.c |    2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

Reviewed-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com

Re: [Qemu-devel] [PATCH qemu 4/6] vl.c: change 'defconfig' variable to bool

[Eduardo Habkost]

On Sat, Apr 28, 2012 at 07:53:41AM +, Blue Swirl wrote:
 On Tue, Apr 24, 2012 at 20:32, Eduardo Habkost ehabk...@redhat.com wrote:
  Signed-off-by: Eduardo Habkost ehabk...@redhat.com
  ---
   vl.c |    4 ++--
   1 files changed, 2 insertions(+), 2 deletions(-)
 
  diff --git a/vl.c b/vl.c
  index 1e5e593..a4f4676 100644
  --- a/vl.c
  +++ b/vl.c
  @@ -2279,7 +2279,7 @@ int main(int argc, char **argv, char **envp)
   #ifdef CONFIG_VNC
      int show_vnc_port = 0;
   #endif
  -    int defconfig = 1;
  +    int defconfig = true;
 
 The type is still 'int', is that intentional?

Oops! It was not, sorry. I will respin the series.

-- 
Eduardo

Re: [Qemu-devel] Memory API: handling unassigned physical memory

[Avi Kivity]

On 04/30/2012 03:17 PM, Mark Cave-Ayland wrote:
 On 30/04/12 09:41, Avi Kivity wrote:

 Yes.  I think it's even possible to do this now, you can create an mmio
 region for the bus and add subregions to it.  All subregions
 automatically overlap the container region.

 Simply replace

memory_region_init(bus-address_space, ...)
memory_region_add_subregion(bus-address_space, addr,dev-mmio)

 with

memory_region_init_io(bus-address_space,bus_nodev_ops, bus, ...)
memory_region_add_subregion(bus-address_space, addr,dev-mmio) //
 unchanged

 This was never used so it hasn't been tested, but the code was written
 with it in mind.  I didn't want to document this so we could back out of
 it, but if it's useful, let's use it.

 Hi Avi,

 Well I've attempted to code something like this, but I've hit a
 problem with devices that aren't just used by SPARC, such as the disk
 controller - it seems that the sysbus API can only MMIO map devices
 into the root MemoryRegion :(

 The SBUS I am trying to model is actually attached to the physical
 address bus, but effectively the top 4 bits of the address control the
 multiplexing of the on-board RAM and the individual per-slot address
 lines. Effectively what I'm trying to model based on a 128MB default
 memory setting is something like this:

 Memory
 0x0 - 0x007ff - Normal RAM

   SBus
   0x2000 - 0x02fff - SBus Slot 0
   0x3000 - 0x03fff - SBus Slot 1
   0x4000 - 0x04fff - SBus Slot 2
   0x5000 - 0x05fff - SBus Slot 3
 0x5020 - 0x502f - TCX DAC
 0x5030 - 0x5030081b - TCH THC8
 0x50301000 - 0x50301fff - TCX THC24
 0x5070 - 0x50700fff - TCX TEC

   0x6 - 0x06fff - SBus Slot 4
   0x7 - 0x07fff - SBus Slot 5

 Using your example above, I believe I can create a simple memory
 hierarchy to represent this and catch unknown operations in a
 bus_nodev_ops section no problem. The issue is that several shared
 peripherals such as ESP have the following in their init function:

 void esp_init(target_phys_addr_t espaddr, int it_shift,
   ESPDMAMemoryReadWriteFunc dma_memory_read,
   ESPDMAMemoryReadWriteFunc dma_memory_write,
   void *dma_opaque, qemu_irq irq, qemu_irq *reset,
   qemu_irq *dma_enable)
 {
 ...
 ...
 sysbus_mmio_map(s, 0, espaddr);
 ...
 }

 and sysbus_mmio_map() looks like this:

 void sysbus_mmio_map(SysBusDevice *dev, int n, target_phys_addr_t addr)
 {
 ...
 ...
 memory_region_add_subregion(get_system_memory(),
 addr,
 dev-mmio[n].memory);
 }

 My understanding based upon this is that it would be impossible to
 register a different parent MemoryRegion without duplicating the init
 function for all shared devices which seems undesirable :(

What are the requirements?  You need a different catch-all mmio handler
for each slot?  Or would one catch-all mmio handler for all sysbus
devices suffice?


 The only solution I can think of is to make sysbus_mmio_map() more
 intelligent so that instead of blindly adding the device to the root
 MemoryRegion, it traverses down the MemoryRegion hierarchy starting
 from the root to the furtherest leaf node it can find based upon the
 specified address and then adds the new subregion there. Hence if I
 add my SBus memory regions first before call the various peripheral
 init functions, everything should end up in the correct part of the
 memory tree.


This solution attempts to reconstruct the memory hierarchy from the
address, instead of maintaining it in the device tree.

 I believe this should preserve compatibility for existing sysbus API
 users with just a single root MemoryRegion, however due to lack of
 any documentation related to sysbus I'm not sure if this would break
 other platforms or maybe even violate one of its key design features?

IMO the best fix is to unsysbus the device and qomify it instead.  This
way we're 100% flexible in how we can attach it.

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

Re: [Qemu-devel] Memory API: handling unassigned physical memory

[Peter Maydell]

On 30 April 2012 14:23, Avi Kivity a...@redhat.com wrote:
 IMO the best fix is to unsysbus the device and qomify it instead.  This
 way we're 100% flexible in how we can attach it.

You don't need to wait for QOM to grow enough features to
replace sysbus. If you don't like what sysbus_mmio_map() does, you
can always use sysbus_mmio_get_region() to get the MemoryRegion* and
then deal with it however you need to. This is the standard way
to deal with I have a sysbus device which I want to map into my
custom container object.

-- PMM

[Qemu-devel] [PATCH qemu 7/6] vl.c: actually change defconfig variable to bool

[Eduardo Habkost]

I changed everything on my previous patch to change 'defconfig', but
forgot to actually change the variable data type.

As the incomplete change doesn't cause any issues or compiler warnings,
I am simply sending this additional patch instead of respinning the
whole series.

Signed-off-by: Eduardo Habkost ehabk...@redhat.com
---
 vl.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/vl.c b/vl.c
index 967b7e8..87db855 100644
--- a/vl.c
+++ b/vl.c
@@ -2279,7 +2279,7 @@ int main(int argc, char **argv, char **envp)
 #ifdef CONFIG_VNC
 int show_vnc_port = 0;
 #endif
-int defconfig = true;
+bool defconfig = true;
 bool userconfig = true;
 const char *log_mask = NULL;
 const char *log_file = NULL;
-- 
1.7.3.2

Re: [Qemu-devel] Memory API: handling unassigned physical memory

[Avi Kivity]

On 04/30/2012 04:27 PM, Peter Maydell wrote:
 On 30 April 2012 14:23, Avi Kivity a...@redhat.com wrote:
  IMO the best fix is to unsysbus the device and qomify it instead.  This
  way we're 100% flexible in how we can attach it.

 You don't need to wait for QOM to grow enough features to
 replace sysbus. If you don't like what sysbus_mmio_map() does, you
 can always use sysbus_mmio_get_region() to get the MemoryRegion* and
 then deal with it however you need to. This is the standard way
 to deal with I have a sysbus device which I want to map into my
 custom container object.

I believe that API voids you warrantee.

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

Re: [Qemu-devel] Memory API: handling unassigned physical memory

[Mark Cave-Ayland]

On 30/04/12 14:23, Avi Kivity wrote:

Hi Avi,


My understanding based upon this is that it would be impossible to
register a different parent MemoryRegion without duplicating the init
function for all shared devices which seems undesirable :(


What are the requirements?  You need a different catch-all mmio handler
for each slot?  Or would one catch-all mmio handler for all sysbus
devices suffice?


A single catch-all for all sysbus devices would suffice, however I'm 
thinking it makes sense to have one MemoryRegion per slot so that the 
devices can register onto the bus using their slot relative address to 
allow for potentially moving hardware between slots.



The only solution I can think of is to make sysbus_mmio_map() more
intelligent so that instead of blindly adding the device to the root
MemoryRegion, it traverses down the MemoryRegion hierarchy starting
from the root to the furtherest leaf node it can find based upon the
specified address and then adds the new subregion there. Hence if I
add my SBus memory regions first before call the various peripheral
init functions, everything should end up in the correct part of the
memory tree.



This solution attempts to reconstruct the memory hierarchy from the
address, instead of maintaining it in the device tree.


So I guess that is bad...


I believe this should preserve compatibility for existing sysbus API
users with just a single root MemoryRegion, however due to lack of
any documentation related to sysbus I'm not sure if this would break
other platforms or maybe even violate one of its key design features?


IMO the best fix is to unsysbus the device and qomify it instead.  This
way we're 100% flexible in how we can attach it.


That's interesting - I didn't realise that sysbus is a legacy interface 
with respect to QOM. Is there any documentation related to this? Then 
again, converting all of the devices over to QOM and testing that it 
doesn't break all platforms/busses suddenly becomes a huge job...



ATB,

Mark.

Re: [Qemu-devel] Memory API: handling unassigned physical memory

[Peter Maydell]

On 30 April 2012 14:36, Avi Kivity a...@redhat.com wrote:
 On 04/30/2012 04:27 PM, Peter Maydell wrote:
 On 30 April 2012 14:23, Avi Kivity a...@redhat.com wrote:
  IMO the best fix is to unsysbus the device and qomify it instead.  This
  way we're 100% flexible in how we can attach it.

 You don't need to wait for QOM to grow enough features to
 replace sysbus. If you don't like what sysbus_mmio_map() does, you
 can always use sysbus_mmio_get_region() to get the MemoryRegion* and
 then deal with it however you need to. This is the standard way
 to deal with I have a sysbus device which I want to map into my
 custom container object.

 I believe that API voids you warrantee.

I wrote it for essentially the purpose described above :-)
If you're the owner of the sysbus device in question then it's
entirely fine as you are the one deciding whether to use the
traditional map function or not.

It's as good as we're going to get until QOM actually lets
you export memory regions and pins, at which point we can just
convert all the sysbus devices.

-- PMM

Re: [Qemu-devel] Memory API: handling unassigned physical memory

[Anthony Liguori]

On 04/30/2012 08:36 AM, Avi Kivity wrote:

On 04/30/2012 04:27 PM, Peter Maydell wrote:

On 30 April 2012 14:23, Avi Kivitya...@redhat.com  wrote:

IMO the best fix is to unsysbus the device and qomify it instead.  This
way we're 100% flexible in how we can attach it.


You don't need to wait for QOM to grow enough features to
replace sysbus. If you don't like what sysbus_mmio_map() does, you
can always use sysbus_mmio_get_region() to get the MemoryRegion* and
then deal with it however you need to. This is the standard way
to deal with I have a sysbus device which I want to map into my
custom container object.


I believe that API voids you warrantee.


All that a QOM conversion would do is eliminate the use of sysbus and derive 
the object directly from DeviceState.  Then, you would map the MemoryRegion 
exported by the device directly.


So sysbus_mmio_get_region() seems like the right API to use.

Regards,

Anthony Liguori

Re: [Qemu-devel] [PULL] qemu-ga: fsfreeze hardening/fixes

[Michael Roth]

On Sun, Apr 29, 2012 at 03:10:11PM -0500, Anthony Liguori wrote:
 On 04/27/2012 05:39 PM, Michael Roth wrote:
 The following changes since commit a8b69b8e2431edfcb6c4cfb069787e9071d6235b:
 
Merge remote-tracking branch 'qmp/queue/qmp' into staging (2012-04-27 
  12:00:06 -0500)
 
 are available in the git repository at:
 
git://github.com/mdroth/qemu.git qga-pull-4-27-12
 
 None of the commits in your branch have Signed-off-bys.

Sorry, fixed now in the pull branch

 
 Regards,
 
 Anthony Liguori
 
 
 Michael Roth (3):
qemu-ga: improve recovery options for fsfreeze
qemu-ga: add a whitelist for fsfreeze-safe commands
qemu-ga: persist tracking of fsfreeze state via filesystem
 
   qapi-schema-guest.json |   25 ++--
   qapi/qmp-core.h|1 +
   qapi/qmp-registry.c|   14 ++-
   qemu-ga.c  |  334 
  +---
   qga/commands-posix.c   |  170 +---
   qga/guest-agent-core.h |3 +
   6 files changed, 409 insertions(+), 138 deletions(-)
 
 
 
 

Re: [Qemu-devel] Memory API: handling unassigned physical memory

[Mark Cave-Ayland]

On 30/04/12 14:27, Peter Maydell wrote:

Hi Peter,


IMO the best fix is to unsysbus the device and qomify it instead.  This
way we're 100% flexible in how we can attach it.


You don't need to wait for QOM to grow enough features to
replace sysbus. If you don't like what sysbus_mmio_map() does, you


Oh - so does this mean that QOM is not feature-complete?


can always use sysbus_mmio_get_region() to get the MemoryRegion* and
then deal with it however you need to. This is the standard way
to deal with I have a sysbus device which I want to map into my
custom container object.


I already have code to do this for the sun4m-only hardware modelled on 
sysbus_mmio_map() like this:



static void sbus_mmio_map(void *sbus, SysBusDevice *s, int n, 
target_phys_addr_t addr)

{
MemoryRegion *sbus_mem, *mem;
target_phys_addr_t sbus_base;
SBusState *sbus_state = FROM_SYSBUS(SBusState, (SysBusDevice *)sbus);

sbus_mem = sysbus_mmio_get_region((SysBusDevice *)sbus, 0);
mem = sysbus_mmio_get_region(s, n);

/* SBus addresses are physical addresses, so subtract start of 
region */

sbus_base = sbus_state-base;
memory_region_add_subregion(sbus_mem, addr - sbus_base, mem);
}


The key problem is that this doesn't worked with shared peripherals, 
such as the ESP device which is also used on various PPC Mac models as 
well as SPARC. That's because its init function looks like this:



void esp_init(target_phys_addr_t espaddr, int it_shift,
  ESPDMAMemoryReadWriteFunc dma_memory_read,
  ESPDMAMemoryReadWriteFunc dma_memory_write,
  void *dma_opaque, qemu_irq irq, qemu_irq *reset,
  qemu_irq *dma_enable)
{
...
...
sysbus_mmio_map(s, 0, espaddr);
...
}


Therefore I can't change it to my (modified) sbus_mmio_map() function 
because it would break other non-SPARC platforms, and AIUI there is 
nothing in the memory API that allows me to move a subregion to a 
different MemoryRegion parent, even if I can get a reference to it with 
sysbus_mmio_get_region() after the sysbus_mmio_map() call - or have I 
misunderstood something?



ATB,

Mark.

Re: [Qemu-devel] scsi-testsuite for virtio-scsi

[Christoph Hellwig]

On Fri, Apr 27, 2012 at 04:15:43PM +0100, Stefan Hajnoczi wrote:
 Christoph Hellwig has announced a new testsuite for the Linux
 in-kernel SCSI target:
 
 http://risingtidesystems.com/git/?p=scsi-testsuite.git;a=tree
 
 We will need something similar for virtio-scsi.  Maybe we can
 contribute and use this for QEMU SCSI emulation testing, I haven't
 checked how target-specific the golden output is yet.

It shouldn't be target specific, that's the whole point.  Please try
to work on the tesuite and make it more generically useful.

Re: [Qemu-devel] scsi-testsuite for virtio-scsi

[Christoph Hellwig]

On Mon, Apr 30, 2012 at 12:59:53PM +0100, Stefan Hajnoczi wrote:
 It's not ideal but if we had a kickstart file or another way of
 building the guest with a single command, then at least regular QEMU
 SCSI contributors and maintainers can use the test suite - I think a
 Fedora guest would be fine.

At work I have a script that creates a bootable Debian image using a
script around debootstrap.  It's just a couple dozend lines of code,
so I can probably release it easily.

Something similar using febootstrap should be possible, too.

Re: [Qemu-devel] Memory API: handling unassigned physical memory

[Peter Maydell]

On 30 April 2012 14:52, Mark Cave-Ayland mark.cave-ayl...@ilande.co.uk wrote:
 The key problem is that this doesn't worked with shared peripherals, such as
 the ESP device which is also used on various PPC Mac models as well as
 SPARC. That's because its init function looks like this:



 void esp_init(target_phys_addr_t espaddr, int it_shift,
              ESPDMAMemoryReadWriteFunc dma_memory_read,
              ESPDMAMemoryReadWriteFunc dma_memory_write,
              void *dma_opaque, qemu_irq irq, qemu_irq *reset,
              qemu_irq *dma_enable)
 {
    ...
    ...
    sysbus_mmio_map(s, 0, espaddr);
    ...
 }


 Therefore I can't change it to my (modified) sbus_mmio_map() function
 because it would break other non-SPARC platforms, and AIUI there is nothing
 in the memory API that allows me to move a subregion to a different
 MemoryRegion parent, even if I can get a reference to it with
 sysbus_mmio_get_region() after the sysbus_mmio_map() call - or have I
 misunderstood something?

Init functions like esp_init should be purely convenience functions
which create, set properties on, and map the sysbus/qdev device. If
they make use of private knowledge about the internals of the device
then this is wrong and should be fixed. For esp_init() it looks like
the handling of dma_memory_read, dma_memory_write, dma_opaque, it_shift
and dma_enabled are wrong.

If you fix that then you can just ignore the convenience function,
and create, configure and map the device as appropriate for you.

-- PMM

Re: [Qemu-devel] scsi-testsuite for virtio-scsi

[Anthony Liguori]

On 04/30/2012 09:01 AM, Christoph Hellwig wrote:

On Mon, Apr 30, 2012 at 12:59:53PM +0100, Stefan Hajnoczi wrote:

It's not ideal but if we had a kickstart file or another way of
building the guest with a single command, then at least regular QEMU
SCSI contributors and maintainers can use the test suite - I think a
Fedora guest would be fine.


At work I have a script that creates a bootable Debian image using a
script around debootstrap.  It's just a couple dozend lines of code,
so I can probably release it easily.


Seed files work nicely because they don't require root.  I've posted some tests 
in the past that use seed files to create a guest from an ISO (without requiring 
root privileges).


Regards,

Anthony Liguori



Something similar using febootstrap should be possible, too.

Re: [Qemu-devel] [PATCH 4/7] qapi: String visitor, use %f represenation for floats

[Michael Roth]

On Sat, Apr 28, 2012 at 06:20:47PM +0200, Andreas Färber wrote:
 Am 27.04.2012 22:21, schrieb Michael Roth:
  Currently string-output-visitor formats floats as %g, which is nice in
  that trailing 0's are automatically truncated, but otherwise this causes
  some issues:
  
   - it 6 uses significant figures instead of 6 decimal places, which
 
 it uses 6 significant
 

Doh, I'll send an updated patch with the commit msg fixed.

 means something like 155777.5 (which even has an exact floating point
 representation) will be rounded to 155778 when converted to a string.
  
   - output will be presented in scientific notation when the normalized
 form requires a 10^x multiplier. Not a huge deal, but arguably less
 readable for command-line arguments.
  
   - due to using sig figs instead of hard-defined decimal places, it
 
 six figs?
 

significant figures, scientific notation is probably clearer, I'll
include it in the update.

 fails a lot of the test-visitor-serialization unit tests for floats.
  
  Instead, let's just use %f, which is what the QJSON and the QMP visitors
  use.
  
  Signed-off-by: Michael Roth mdr...@linux.vnet.ibm.com
 
 /-F
 
 -- 
 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] KVM call agenda for May, Thrusday 1st

[Peter Portante]

On Mon, Apr 30, 2012 at 7:58 AM, Anthony Liguori anth...@codemonkey.wswrote:

 On 04/30/2012 04:17 AM, Juan Quintela wrote:



 Hi

 Please send in any agenda items you are interested in covering.


 FYI, I won't be able to attend as I'll be at the LF End User Summit.

 Regards,

 Anthony Liguori


 Thanks, Juan.



 Just for clarity, is this for Tuesday, May 1st, or Thursday, May 3rd?

Re: [Qemu-devel] Memory API: handling unassigned physical memory

[Mark Cave-Ayland]

On 30/04/12 15:03, Peter Maydell wrote:


Therefore I can't change it to my (modified) sbus_mmio_map() function
because it would break other non-SPARC platforms, and AIUI there is nothing
in the memory API that allows me to move a subregion to a different
MemoryRegion parent, even if I can get a reference to it with
sysbus_mmio_get_region() after the sysbus_mmio_map() call - or have I
misunderstood something?


Init functions like esp_init should be purely convenience functions
which create, set properties on, and map the sysbus/qdev device. If
they make use of private knowledge about the internals of the device
then this is wrong and should be fixed. For esp_init() it looks like
the handling of dma_memory_read, dma_memory_write, dma_opaque, it_shift
and dma_enabled are wrong.

If you fix that then you can just ignore the convenience function,
and create, configure and map the device as appropriate for you.


Right I think I'm starting to understand this now - in which case it 
becomes a matter of just copying a handful of lines within sun4m which 
is more bearable.


In your view, would a suitable fix be to change dma_memory_read, 
dma_memory_write, dma_opaque, it_shift and dma_enabled to be qdev 
properties and modify esp_init() to return the qdev reference so they 
can be set by the caller?



ATB,

Mark.

[Qemu-devel] [PATCH v6 4/7] qapi: String visitor, use %f representation for floats

[Michael Roth]

Currently string-output-visitor formats floats as %g, which is nice in
that trailing 0's are automatically truncated, but otherwise this causes
some issues:

 - it uses 6 significant figures instead of 6 decimal places, which
   means something like 155777.5 (which even has an exact floating point
   representation) will be rounded to 155778 when converted to a string.

 - output will be presented in scientific notation when the normalized
   form requires a 10^x multiplier. Not a huge deal, but arguably less
   readable for command-line arguments.

 - due to using scientific notation for numbers requiring more than 6
   significant figures, instead of hard-defined decimal places, it
   fails a lot of the test-visitor-serialization unit tests for floats.

Instead, let's just use %f, which is what the QJSON and the QMP visitors
use.

Signed-off-by: Michael Roth mdr...@linux.vnet.ibm.com
---
 qapi/string-output-visitor.c   |2 +-
 tests/test-string-output-visitor.c |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/qapi/string-output-visitor.c b/qapi/string-output-visitor.c
index 92b0305..34e525e 100644
--- a/qapi/string-output-visitor.c
+++ b/qapi/string-output-visitor.c
@@ -52,7 +52,7 @@ static void print_type_number(Visitor *v, double *obj, const 
char *name,
   Error **errp)
 {
 StringOutputVisitor *sov = DO_UPCAST(StringOutputVisitor, visitor, v);
-string_output_set(sov, g_strdup_printf(%g, *obj));
+string_output_set(sov, g_strdup_printf(%f, *obj));
 }
 
 char *string_output_get_string(StringOutputVisitor *sov)
diff --git a/tests/test-string-output-visitor.c 
b/tests/test-string-output-visitor.c
index 22909b8..608f14a 100644
--- a/tests/test-string-output-visitor.c
+++ b/tests/test-string-output-visitor.c
@@ -84,7 +84,7 @@ static void test_visitor_out_number(TestOutputVisitorData 
*data,
 
 str = string_output_get_string(data-sov);
 g_assert(str != NULL);
-g_assert_cmpstr(str, ==, 3.14);
+g_assert_cmpstr(str, ==, 3.14);
 g_free(str);
 }
 
-- 
1.7.4.1

Re: [Qemu-devel] Memory API: handling unassigned physical memory

[Peter Maydell]

On 30 April 2012 15:33, Mark Cave-Ayland mark.cave-ayl...@ilande.co.uk wrote:
 On 30/04/12 15:03, Peter Maydell wrote:
 Right I think I'm starting to understand this now - in which case it becomes
 a matter of just copying a handful of lines within sun4m which is more
 bearable.

 In your view, would a suitable fix be to change dma_memory_read,
 dma_memory_write, dma_opaque, it_shift and dma_enabled to be qdev properties
 and modify esp_init() to return the qdev reference so they can be set by the
 caller?

They should be some kind of qdev property, probably. Since you can't
change a property after the qdev_init there's not much point changing
esp_init to return the DeviceState*, though.

(Disclaimer: I'm not sure what the best QOM/qdev practice is for here
is a set of function pointers. In my ideal world this would be done
by setting a single strongly typed qdev property which encapsulates
the idea of here is a connection into which you can plug something
that satisfies this dma read/write API.)

-- PMM

[Qemu-devel] [PATCH] qemu: fix cpuid eax for kvm cpu

[Michael S. Tsirkin]

cpuid eax should return the max leaf so that
guests can find out the valid range.
This matches Xen et al.

Tested using -cpu kvm64.

Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
 target-i386/kvm.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index e74a9e4..c097248 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -379,7 +379,7 @@ int kvm_arch_init_vcpu(CPUX86State *env)
 c-function = KVM_CPUID_SIGNATURE;
 if (!hyperv_enabled()) {
 memcpy(signature, KVMKVMKVM\0\0\0, 12);
-c-eax = 0;
+c-eax = KVM_CPUID_FEATURES;
 } else {
 memcpy(signature, Microsoft Hv, 12);
 c-eax = HYPERV_CPUID_MIN;
-- 
MST

[Qemu-devel] [PATCH 1/5] i82378/i82374: Do not create DMA controller twice

[Andreas Färber]

From: Hervé Poussineau hpous...@reactos.org

This fixes a crash in PReP emulation when using DMA controller to access
floppy drive.

Signed-off-by: Hervé Poussineau hpous...@reactos.org
Signed-off-by: Andreas Färber andreas.faer...@web.de
---
 hw/i82374.c |5 -
 hw/i82378.c |5 +++--
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/hw/i82374.c b/hw/i82374.c
index 67298a3..4a922c3 100644
--- a/hw/i82374.c
+++ b/hw/i82374.c
@@ -38,6 +38,7 @@ do { fprintf(stderr, i82374 ERROR:  fmt , ## __VA_ARGS__); 
} while (0)
 
 typedef struct I82374State {
 uint8_t commands[8];
+qemu_irq out;
 } I82374State;
 
 static const VMStateDescription vmstate_i82374 = {
@@ -99,7 +100,7 @@ static uint32_t i82374_read_descriptor(void *opaque, 
uint32_t nport)
 
 static void i82374_init(I82374State *s)
 {
-DMA_init(1, NULL);
+DMA_init(1, s-out);
 memset(s-commands, 0, sizeof(s-commands));
 }
 
@@ -132,6 +133,8 @@ static int i82374_isa_init(ISADevice *dev)
 
 i82374_init(s);
 
+qdev_init_gpio_out(dev-qdev, s-out, 1);
+
 return 0;
 }
 
diff --git a/hw/i82378.c b/hw/i82378.c
index faad1a3..9b11d90 100644
--- a/hw/i82378.c
+++ b/hw/i82378.c
@@ -170,6 +170,7 @@ static void i82378_init(DeviceState *dev, I82378State *s)
 {
 ISABus *isabus = DO_UPCAST(ISABus, qbus, qdev_get_child_bus(dev, isa.0));
 ISADevice *pit;
+ISADevice *isa;
 qemu_irq *out0_irq;
 
 /* This device has:
@@ -199,8 +200,8 @@ static void i82378_init(DeviceState *dev, I82378State *s)
 pcspk_init(isabus, pit);
 
 /* 2 82C37 (dma) */
-DMA_init(1, s-out[1]);
-isa_create_simple(isabus, i82374);
+isa = isa_create_simple(isabus, i82374);
+qdev_connect_gpio_out(isa-qdev, 0, s-out[1]);
 
 /* timer */
 isa_create_simple(isabus, mc146818rtc);
-- 
1.7.7

[Qemu-devel] [PATCH 3/5] isa: Add isa_bus_from_device() method

[Andreas Färber]

From: Hervé Poussineau hpous...@reactos.org

Signed-off-by: Hervé Poussineau hpous...@reactos.org
Acked-by: Gerd Hoffmann kra...@redhat.com
Signed-off-by: Andreas Färber andreas.faer...@web.de
---
 hw/isa.h |5 +
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/hw/isa.h b/hw/isa.h
index 40373fb..f7bc4b5 100644
--- a/hw/isa.h
+++ b/hw/isa.h
@@ -76,6 +76,11 @@ void isa_register_portio_list(ISADevice *dev, uint16_t start,
   const MemoryRegionPortio *portio,
   void *opaque, const char *name);
 
+static inline ISABus *isa_bus_from_device(ISADevice *d)
+{
+return DO_UPCAST(ISABus, qbus, d-qdev.parent_bus);
+}
+
 extern target_phys_addr_t isa_mem_base;
 
 void isa_mmio_setup(MemoryRegion *mr, target_phys_addr_t size);
-- 
1.7.7

[Qemu-devel] [PATCH 2/5] fdc: Parametrize ISA base, IRQ and DMA

[Andreas Färber]

From: Hervé Poussineau hpous...@reactos.org

Keep the PC values as defaults but allow to override them for PReP.

Signed-off-by: Hervé Poussineau hpous...@reactos.org
Signed-off-by: Andreas Färber andreas.faer...@web.de
Reviewed-by: Markus Armbruster arm...@redhat.com
---
 hw/fdc.c |   17 ++---
 1 files changed, 10 insertions(+), 7 deletions(-)

diff --git a/hw/fdc.c b/hw/fdc.c
index a0236b7..756d4ce 100644
--- a/hw/fdc.c
+++ b/hw/fdc.c
@@ -438,6 +438,9 @@ typedef struct FDCtrlSysBus {
 
 typedef struct FDCtrlISABus {
 ISADevice busdev;
+uint32_t iobase;
+uint32_t irq;
+uint32_t dma;
 struct FDCtrl state;
 int32_t bootindexA;
 int32_t bootindexB;
@@ -1971,17 +1974,14 @@ static int isabus_fdc_init1(ISADevice *dev)
 {
 FDCtrlISABus *isa = DO_UPCAST(FDCtrlISABus, busdev, dev);
 FDCtrl *fdctrl = isa-state;
-int iobase = 0x3f0;
-int isairq = 6;
-int dma_chann = 2;
 int ret;
 
-isa_register_portio_list(dev, iobase, fdc_portio_list, fdctrl, fdc);
+isa_register_portio_list(dev, isa-iobase, fdc_portio_list, fdctrl, fdc);
 
-isa_init_irq(isa-busdev, fdctrl-irq, isairq);
-fdctrl-dma_chann = dma_chann;
+isa_init_irq(isa-busdev, fdctrl-irq, isa-irq);
+fdctrl-dma_chann = isa-dma;
 
-qdev_set_legacy_instance_id(dev-qdev, iobase, 2);
+qdev_set_legacy_instance_id(dev-qdev, isa-iobase, 2);
 ret = fdctrl_init_common(fdctrl);
 
 add_boot_device_path(isa-bootindexA, dev-qdev, /floppy@0);
@@ -2046,6 +2046,9 @@ static const VMStateDescription vmstate_isa_fdc ={
 };
 
 static Property isa_fdc_properties[] = {
+DEFINE_PROP_HEX32(iobase, FDCtrlISABus, iobase, 0x3f0),
+DEFINE_PROP_UINT32(irq, FDCtrlISABus, irq, 6),
+DEFINE_PROP_UINT32(dma, FDCtrlISABus, dma, 2),
 DEFINE_PROP_DRIVE(driveA, FDCtrlISABus, state.drives[0].bs),
 DEFINE_PROP_DRIVE(driveB, FDCtrlISABus, state.drives[1].bs),
 DEFINE_PROP_INT32(bootindexA, FDCtrlISABus, bootindexA, -1),
-- 
1.7.7

[Qemu-devel] [PATCH 5/5] prep: Move int-ack register from PReP to Raven PCI emulation

[Andreas Färber]

From: Hervé Poussineau hpous...@reactos.org

Register is one byte-wide (as per specification), so there is no need
to specify endianness.

Signed-off-by: Hervé Poussineau hpous...@reactos.org
[AF: Limit access validity to size 1]
Signed-off-by: Andreas Färber andreas.faer...@web.de
---
 hw/ppc_prep.c |   36 
 hw/prep_pci.c |   17 +
 2 files changed, 17 insertions(+), 36 deletions(-)

diff --git a/hw/ppc_prep.c b/hw/ppc_prep.c
index 61c655c..b1da114 100644
--- a/hw/ppc_prep.c
+++ b/hw/ppc_prep.c
@@ -86,38 +86,6 @@ static int ne2000_irq[NE2000_NB_MAX] = { 9, 10, 11, 3, 4, 5 
};
 /* ISA IO ports bridge */
 #define PPC_IO_BASE 0x8000
 
-/* PCI intack register */
-/* Read-only register (?) */
-static void PPC_intack_write (void *opaque, target_phys_addr_t addr,
-  uint64_t value, unsigned size)
-{
-#if 0
-printf(%s: 0x TARGET_FMT_plx  = 0x%08 PRIx64 \n, __func__, addr,
-   value);
-#endif
-}
-
-static uint64_t PPC_intack_read(void *opaque, target_phys_addr_t addr,
-unsigned size)
-{
-uint32_t retval = 0;
-
-if ((addr  0xf) == 0)
-retval = pic_read_irq(isa_pic);
-#if 0
-printf(%s: 0x TARGET_FMT_plx  = %08 PRIx32 \n, __func__, addr,
-   retval);
-#endif
-
-return retval;
-}
-
-static const MemoryRegionOps PPC_intack_ops = {
-.read = PPC_intack_read,
-.write = PPC_intack_write,
-.endianness = DEVICE_LITTLE_ENDIAN,
-};
-
 /* PowerPC control and status registers */
 #if 0 // Not used
 static struct {
@@ -492,7 +460,6 @@ static void ppc_prep_init (ram_addr_t ram_size,
 nvram_t nvram;
 M48t59State *m48t59;
 MemoryRegion *PPC_io_memory = g_new(MemoryRegion, 1);
-MemoryRegion *intack = g_new(MemoryRegion, 1);
 #if 0
 MemoryRegion *xcsr = g_new(MemoryRegion, 1);
 #endif
@@ -685,9 +652,6 @@ static void ppc_prep_init (ram_addr_t ram_size,
 register_ioport_write(0x0092, 0x01, 1, PREP_io_800_writeb, sysctrl);
 register_ioport_read(0x0800, 0x52, 1, PREP_io_800_readb, sysctrl);
 register_ioport_write(0x0800, 0x52, 1, PREP_io_800_writeb, sysctrl);
-/* PCI intack location */
-memory_region_init_io(intack, PPC_intack_ops, NULL, ppc-intack, 4);
-memory_region_add_subregion(sysmem, 0xBFF0, intack);
 /* PowerPC control and status register group */
 #if 0
 memory_region_init_io(xcsr, PPC_XCSR_ops, NULL, ppc-xcsr, 0x1000);
diff --git a/hw/prep_pci.c b/hw/prep_pci.c
index 8b29da9..38dbff4 100644
--- a/hw/prep_pci.c
+++ b/hw/prep_pci.c
@@ -25,10 +25,12 @@
 #include hw.h
 #include pci.h
 #include pci_host.h
+#include pc.h
 #include exec-memory.h
 
 typedef struct PRePPCIState {
 PCIHostState host_state;
+MemoryRegion intack;
 qemu_irq irq[4];
 } PREPPCIState;
 
@@ -67,6 +69,19 @@ static const MemoryRegionOps PPC_PCIIO_ops = {
 .endianness = DEVICE_LITTLE_ENDIAN,
 };
 
+static uint64_t ppc_intack_read(void *opaque, target_phys_addr_t addr,
+unsigned int size)
+{
+return pic_read_irq(isa_pic);
+}
+
+static const MemoryRegionOps PPC_intack_ops = {
+.read = ppc_intack_read,
+.valid = {
+.max_access_size = 1,
+},
+};
+
 static int prep_map_irq(PCIDevice *pci_dev, int irq_num)
 {
 return (irq_num + (pci_dev-devfn  3))  1;
@@ -110,6 +125,8 @@ static int raven_pcihost_init(SysBusDevice *dev)
 memory_region_init_io(h-mmcfg, PPC_PCIIO_ops, s, pciio, 0x0040);
 memory_region_add_subregion(address_space_mem, 0x8080, h-mmcfg);
 
+memory_region_init_io(s-intack, PPC_intack_ops, s, pci-intack, 1);
+memory_region_add_subregion(address_space_mem, 0xbff0, s-intack);
 pci_create_simple(bus, 0, raven);
 
 return 0;
-- 
1.7.7

[Qemu-devel] [PULL] PReP patch queue 2012-04-30

[Andreas Färber]

Hello Blue,

Please pull the PowerPC Reference Platform (PReP) queue into qemu.git master.

The following changes since commit 42fe1c245f0239ebcdc084740a1777ac3699d071:

  main-loop: Fix build for w32 and w64 (2012-04-28 09:25:54 +)

are available in the git repository at:
  git://repo.or.cz/qemu/afaerber.git prep-up

Hervé Poussineau (4):
  i82378/i82374: Do not create DMA controller twice
  fdc: Parametrize ISA base, IRQ and DMA
  isa: Add isa_bus_from_device() method
  prep: Initialize PC speaker

 hw/fdc.c  |   17 ++---
 hw/i82374.c   |5 -
 hw/i82378.c   |5 +++--
 hw/isa.h  |5 +
 hw/ppc_prep.c |4 
 5 files changed, 26 insertions(+), 10 deletions(-)

[Qemu-devel] [PATCH 4/5] prep: Initialize PC speaker

[Andreas Färber]

From: Hervé Poussineau hpous...@reactos.org

Speaker init has been added in 506b7ddf889312659b36c667f7ae17bc9e909418,
but audio subsystem init was missing.

Signed-off-by: Hervé Poussineau hpous...@reactos.org
Signed-off-by: Andreas Färber andreas.faer...@web.de
---
 hw/ppc_prep.c |4 
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/hw/ppc_prep.c b/hw/ppc_prep.c
index 9d8e659..61c655c 100644
--- a/hw/ppc_prep.c
+++ b/hw/ppc_prep.c
@@ -37,6 +37,7 @@
 #include loader.h
 #include mc146818rtc.h
 #include blockdev.h
+#include arch_init.h
 #include exec-memory.h
 
 //#define HARD_DEBUG_PPC_IO
@@ -716,6 +717,9 @@ static void ppc_prep_init (ram_addr_t ram_size,
 
 /* Special port to get debug messages from Open-Firmware */
 register_ioport_write(0x0F00, 4, 1, PPC_debug_write, NULL);
+
+/* Initialize audio subsystem */
+audio_init(isa_bus, pci_bus);
 }
 
 static QEMUMachine prep_machine = {
-- 
1.7.7

Re: [Qemu-devel] [PATCH] ppce500_spin: Replace assert by hw_error (fixes compiler warning)

[Stefan Weil]

Am 30.04.2012 10:54, schrieb Alexander Graf:

On 28.04.2012, at 17:52, Stefan Weil wrote:
The default case in function spin_read should never be reached, 
therefore the old code used assert(0) to abort QEMU. This does not 
work when QEMU is compiled with macro NDEBUG defined. In this case 
(and also when the compiler does not know that assert never returns), 
there is a compiler warning because of the missing return value. 
Using hw_error allows an improved error message and aborts always. 
Signed-off-by: Stefan Weil s...@weilnetz.de 
Thanks, applied to ppc-next. The patch didn't show up on patchworks 
btw, not sure what went wrong there. Alex


http://patchwork.ozlabs.org/patch/155666/
Did you filter on state new? I update the state for my patches.

Are you planning to send a pull request for QEMU 1.1?
I'd like to have this compiler warning fixed in the new version.

Regards,
Stefan

Re: [Qemu-devel] Memory API: handling unassigned physical memory

[Mark Cave-Ayland]

On 30/04/12 15:39, Peter Maydell wrote:


Right I think I'm starting to understand this now - in which case it becomes
a matter of just copying a handful of lines within sun4m which is more
bearable.

In your view, would a suitable fix be to change dma_memory_read,
dma_memory_write, dma_opaque, it_shift and dma_enabled to be qdev properties
and modify esp_init() to return the qdev reference so they can be set by the
caller?


They should be some kind of qdev property, probably. Since you can't
change a property after the qdev_init there's not much point changing
esp_init to return the DeviceState*, though.


In the meantime I've found a bit of reference documentation related to 
QOM and properties here: http://wiki.qemu.org/Features/QOM.



(Disclaimer: I'm not sure what the best QOM/qdev practice is for here
is a set of function pointers. In my ideal world this would be done
by setting a single strongly typed qdev property which encapsulates
the idea of here is a connection into which you can plug something
that satisfies this dma read/write API.)


Note that if properties can't be set by the caller after construction, 
then I'm effectively going to have to copy the entire esp_init() 
function; so until the QOM magic happens to allow plugging things into 
arbitrary buses, I might as well just keep a copy in sun4m.c with my 
local modifications as sun4_esp_init() and be done with it. Slightly 
frustrating, but I think that's going to be the easiest solution for the 
moment.



ATB,

Mark.

Re: [Qemu-devel] Memory API: handling unassigned physical memory

[Peter Maydell]

On 30 April 2012 15:55, Mark Cave-Ayland mark.cave-ayl...@ilande.co.uk wrote:
 Note that if properties can't be set by the caller after construction, then
 I'm effectively going to have to copy the entire esp_init() function

Yes. As I say, these init functions are purely convenience functions
for the simple case. (My opinion is that if it seems like a pain to
have to open code them it's an indication that we ought to be trying
to make it easier to create-configure-init QOM objects. But that's
not entirely trivial in C.)

-- PMM

Re: [Qemu-devel] [PATCH] ppce500_spin: Replace assert by hw_error (fixes compiler warning)

[Andreas Färber]

Am 30.04.2012 10:54, schrieb Alexander Graf:
 
 On 28.04.2012, at 17:52, Stefan Weil wrote:
 
 The default case in function spin_read should never be reached,
 therefore the old code used assert(0) to abort QEMU.

 This does not work when QEMU is compiled with macro NDEBUG defined.
 In this case (and also when the compiler does not know that assert
 never returns), there is a compiler warning because of the missing
 return value.

 Using hw_error allows an improved error message and aborts always.

 Signed-off-by: Stefan Weil s...@weilnetz.de
 
 Thanks, applied to ppc-next. The patch didn't show up on patchworks btw, not 
 sure what went wrong there.

Please consider fixing up on your branch as follows:

diff --git a/hw/ppce500_spin.c b/hw/ppce500_spin.c
index 8522c41..fddf219 100644
--- a/hw/ppce500_spin.c
+++ b/hw/ppce500_spin.c
@@ -179,7 +179,7 @@ static uint64_t spin_read(void *opaque,
target_phys_addr_t addr, unsigned len)
 case 4:
 return ldl_p(spin_p);
 default:
-hw_error(ppce500: unexpected spin_read with len = %u, len);
+hw_error(ppce500: unexpected %s with len = %u, __func__, len);
 }
 }


Andreas

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

Re: [Qemu-devel] Memory API: handling unassigned physical memory

[Peter Maydell]

On 30 April 2012 15:55, Mark Cave-Ayland mark.cave-ayl...@ilande.co.uk wrote:
 I
 might as well just keep a copy in sun4m.c with my local modifications as
 sun4_esp_init() and be done with it. Slightly frustrating, but I think
 that's going to be the easiest solution for the moment.

You will need to address the properties issue anyway, though, because
sun4m.c doesn't have access to the layout of struct ESPState.

-- PMM

Re: [Qemu-devel] Memory API: handling unassigned physical memory

[Andreas Färber]

Am 30.04.2012 16:55, schrieb Mark Cave-Ayland:
 Note that if properties can't be set by the caller after construction,
 then I'm effectively going to have to copy the entire esp_init()
 function;

The idea would be to use the QOM way of creating the object, using QOM
and/or custom ways to set properties/fields and then realize it. The
infrastructure for the latter is still missing, so for now you would
split the esp_init function into one part that goes to the call sites
and an esp_realize function that gets called for any remaining part
after the appropriate properties and MMIO mappings have been set up.

Andreas

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

Re: [Qemu-devel] [PULL] PReP patch queue 2012-04-30

[Andreas Färber]

Am 30.04.2012 16:47, schrieb Andreas Färber:
 Hello Blue,
 
 Please pull the PowerPC Reference Platform (PReP) queue into qemu.git master.
 
 The following changes since commit 42fe1c245f0239ebcdc084740a1777ac3699d071:
 
   main-loop: Fix build for w32 and w64 (2012-04-28 09:25:54 +)
 
 are available in the git repository at:
   git://repo.or.cz/qemu/afaerber.git prep-up
 
 Hervé Poussineau (4):
   i82378/i82374: Do not create DMA controller twice
   fdc: Parametrize ISA base, IRQ and DMA
   isa: Add isa_bus_from_device() method
   prep: Initialize PC speaker

Er, forgot to update the prep-up branch after applying the patch I had
been waiting on, please ignore. Fixed PULL coming up shortly.

Andreas

 
  hw/fdc.c  |   17 ++---
  hw/i82374.c   |5 -
  hw/i82378.c   |5 +++--
  hw/isa.h  |5 +
  hw/ppc_prep.c |4 
  5 files changed, 26 insertions(+), 10 deletions(-)
 

[Qemu-devel] [PATCH 3/5] isa: Add isa_bus_from_device() method

[Andreas Färber]

From: Hervé Poussineau hpous...@reactos.org

Signed-off-by: Hervé Poussineau hpous...@reactos.org
Acked-by: Gerd Hoffmann kra...@redhat.com
Signed-off-by: Andreas Färber andreas.faer...@web.de
---
 hw/isa.h |5 +
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/hw/isa.h b/hw/isa.h
index 40373fb..f7bc4b5 100644
--- a/hw/isa.h
+++ b/hw/isa.h
@@ -76,6 +76,11 @@ void isa_register_portio_list(ISADevice *dev, uint16_t start,
   const MemoryRegionPortio *portio,
   void *opaque, const char *name);
 
+static inline ISABus *isa_bus_from_device(ISADevice *d)
+{
+return DO_UPCAST(ISABus, qbus, d-qdev.parent_bus);
+}
+
 extern target_phys_addr_t isa_mem_base;
 
 void isa_mmio_setup(MemoryRegion *mr, target_phys_addr_t size);
-- 
1.7.7

[Qemu-devel] [PATCH 1/5] i82378/i82374: Do not create DMA controller twice

[Andreas Färber]

From: Hervé Poussineau hpous...@reactos.org

This fixes a crash in PReP emulation when using DMA controller to access
floppy drive.

Signed-off-by: Hervé Poussineau hpous...@reactos.org
Signed-off-by: Andreas Färber andreas.faer...@web.de
---
 hw/i82374.c |5 -
 hw/i82378.c |5 +++--
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/hw/i82374.c b/hw/i82374.c
index 67298a3..4a922c3 100644
--- a/hw/i82374.c
+++ b/hw/i82374.c
@@ -38,6 +38,7 @@ do { fprintf(stderr, i82374 ERROR:  fmt , ## __VA_ARGS__); 
} while (0)
 
 typedef struct I82374State {
 uint8_t commands[8];
+qemu_irq out;
 } I82374State;
 
 static const VMStateDescription vmstate_i82374 = {
@@ -99,7 +100,7 @@ static uint32_t i82374_read_descriptor(void *opaque, 
uint32_t nport)
 
 static void i82374_init(I82374State *s)
 {
-DMA_init(1, NULL);
+DMA_init(1, s-out);
 memset(s-commands, 0, sizeof(s-commands));
 }
 
@@ -132,6 +133,8 @@ static int i82374_isa_init(ISADevice *dev)
 
 i82374_init(s);
 
+qdev_init_gpio_out(dev-qdev, s-out, 1);
+
 return 0;
 }
 
diff --git a/hw/i82378.c b/hw/i82378.c
index faad1a3..9b11d90 100644
--- a/hw/i82378.c
+++ b/hw/i82378.c
@@ -170,6 +170,7 @@ static void i82378_init(DeviceState *dev, I82378State *s)
 {
 ISABus *isabus = DO_UPCAST(ISABus, qbus, qdev_get_child_bus(dev, isa.0));
 ISADevice *pit;
+ISADevice *isa;
 qemu_irq *out0_irq;
 
 /* This device has:
@@ -199,8 +200,8 @@ static void i82378_init(DeviceState *dev, I82378State *s)
 pcspk_init(isabus, pit);
 
 /* 2 82C37 (dma) */
-DMA_init(1, s-out[1]);
-isa_create_simple(isabus, i82374);
+isa = isa_create_simple(isabus, i82374);
+qdev_connect_gpio_out(isa-qdev, 0, s-out[1]);
 
 /* timer */
 isa_create_simple(isabus, mc146818rtc);
-- 
1.7.7

[Qemu-devel] [PATCH 2/5] fdc: Parametrize ISA base, IRQ and DMA

[Andreas Färber]

From: Hervé Poussineau hpous...@reactos.org

Keep the PC values as defaults but allow to override them for PReP.

Signed-off-by: Hervé Poussineau hpous...@reactos.org
Signed-off-by: Andreas Färber andreas.faer...@web.de
Reviewed-by: Markus Armbruster arm...@redhat.com
---
 hw/fdc.c |   17 ++---
 1 files changed, 10 insertions(+), 7 deletions(-)

diff --git a/hw/fdc.c b/hw/fdc.c
index a0236b7..756d4ce 100644
--- a/hw/fdc.c
+++ b/hw/fdc.c
@@ -438,6 +438,9 @@ typedef struct FDCtrlSysBus {
 
 typedef struct FDCtrlISABus {
 ISADevice busdev;
+uint32_t iobase;
+uint32_t irq;
+uint32_t dma;
 struct FDCtrl state;
 int32_t bootindexA;
 int32_t bootindexB;
@@ -1971,17 +1974,14 @@ static int isabus_fdc_init1(ISADevice *dev)
 {
 FDCtrlISABus *isa = DO_UPCAST(FDCtrlISABus, busdev, dev);
 FDCtrl *fdctrl = isa-state;
-int iobase = 0x3f0;
-int isairq = 6;
-int dma_chann = 2;
 int ret;
 
-isa_register_portio_list(dev, iobase, fdc_portio_list, fdctrl, fdc);
+isa_register_portio_list(dev, isa-iobase, fdc_portio_list, fdctrl, fdc);
 
-isa_init_irq(isa-busdev, fdctrl-irq, isairq);
-fdctrl-dma_chann = dma_chann;
+isa_init_irq(isa-busdev, fdctrl-irq, isa-irq);
+fdctrl-dma_chann = isa-dma;
 
-qdev_set_legacy_instance_id(dev-qdev, iobase, 2);
+qdev_set_legacy_instance_id(dev-qdev, isa-iobase, 2);
 ret = fdctrl_init_common(fdctrl);
 
 add_boot_device_path(isa-bootindexA, dev-qdev, /floppy@0);
@@ -2046,6 +2046,9 @@ static const VMStateDescription vmstate_isa_fdc ={
 };
 
 static Property isa_fdc_properties[] = {
+DEFINE_PROP_HEX32(iobase, FDCtrlISABus, iobase, 0x3f0),
+DEFINE_PROP_UINT32(irq, FDCtrlISABus, irq, 6),
+DEFINE_PROP_UINT32(dma, FDCtrlISABus, dma, 2),
 DEFINE_PROP_DRIVE(driveA, FDCtrlISABus, state.drives[0].bs),
 DEFINE_PROP_DRIVE(driveB, FDCtrlISABus, state.drives[1].bs),
 DEFINE_PROP_INT32(bootindexA, FDCtrlISABus, bootindexA, -1),
-- 
1.7.7

[Qemu-devel] [PATCH 5/5] prep: Move int-ack register from PReP to Raven PCI emulation

[Andreas Färber]

From: Hervé Poussineau hpous...@reactos.org

Register is one byte-wide (as per specification), so there is no need
to specify endianness.

Signed-off-by: Hervé Poussineau hpous...@reactos.org
[AF: Limit access validity to size 1]
Signed-off-by: Andreas Färber andreas.faer...@web.de
---
 hw/ppc_prep.c |   36 
 hw/prep_pci.c |   17 +
 2 files changed, 17 insertions(+), 36 deletions(-)

diff --git a/hw/ppc_prep.c b/hw/ppc_prep.c
index 61c655c..b1da114 100644
--- a/hw/ppc_prep.c
+++ b/hw/ppc_prep.c
@@ -86,38 +86,6 @@ static int ne2000_irq[NE2000_NB_MAX] = { 9, 10, 11, 3, 4, 5 
};
 /* ISA IO ports bridge */
 #define PPC_IO_BASE 0x8000
 
-/* PCI intack register */
-/* Read-only register (?) */
-static void PPC_intack_write (void *opaque, target_phys_addr_t addr,
-  uint64_t value, unsigned size)
-{
-#if 0
-printf(%s: 0x TARGET_FMT_plx  = 0x%08 PRIx64 \n, __func__, addr,
-   value);
-#endif
-}
-
-static uint64_t PPC_intack_read(void *opaque, target_phys_addr_t addr,
-unsigned size)
-{
-uint32_t retval = 0;
-
-if ((addr  0xf) == 0)
-retval = pic_read_irq(isa_pic);
-#if 0
-printf(%s: 0x TARGET_FMT_plx  = %08 PRIx32 \n, __func__, addr,
-   retval);
-#endif
-
-return retval;
-}
-
-static const MemoryRegionOps PPC_intack_ops = {
-.read = PPC_intack_read,
-.write = PPC_intack_write,
-.endianness = DEVICE_LITTLE_ENDIAN,
-};
-
 /* PowerPC control and status registers */
 #if 0 // Not used
 static struct {
@@ -492,7 +460,6 @@ static void ppc_prep_init (ram_addr_t ram_size,
 nvram_t nvram;
 M48t59State *m48t59;
 MemoryRegion *PPC_io_memory = g_new(MemoryRegion, 1);
-MemoryRegion *intack = g_new(MemoryRegion, 1);
 #if 0
 MemoryRegion *xcsr = g_new(MemoryRegion, 1);
 #endif
@@ -685,9 +652,6 @@ static void ppc_prep_init (ram_addr_t ram_size,
 register_ioport_write(0x0092, 0x01, 1, PREP_io_800_writeb, sysctrl);
 register_ioport_read(0x0800, 0x52, 1, PREP_io_800_readb, sysctrl);
 register_ioport_write(0x0800, 0x52, 1, PREP_io_800_writeb, sysctrl);
-/* PCI intack location */
-memory_region_init_io(intack, PPC_intack_ops, NULL, ppc-intack, 4);
-memory_region_add_subregion(sysmem, 0xBFF0, intack);
 /* PowerPC control and status register group */
 #if 0
 memory_region_init_io(xcsr, PPC_XCSR_ops, NULL, ppc-xcsr, 0x1000);
diff --git a/hw/prep_pci.c b/hw/prep_pci.c
index 8b29da9..38dbff4 100644
--- a/hw/prep_pci.c
+++ b/hw/prep_pci.c
@@ -25,10 +25,12 @@
 #include hw.h
 #include pci.h
 #include pci_host.h
+#include pc.h
 #include exec-memory.h
 
 typedef struct PRePPCIState {
 PCIHostState host_state;
+MemoryRegion intack;
 qemu_irq irq[4];
 } PREPPCIState;
 
@@ -67,6 +69,19 @@ static const MemoryRegionOps PPC_PCIIO_ops = {
 .endianness = DEVICE_LITTLE_ENDIAN,
 };
 
+static uint64_t ppc_intack_read(void *opaque, target_phys_addr_t addr,
+unsigned int size)
+{
+return pic_read_irq(isa_pic);
+}
+
+static const MemoryRegionOps PPC_intack_ops = {
+.read = ppc_intack_read,
+.valid = {
+.max_access_size = 1,
+},
+};
+
 static int prep_map_irq(PCIDevice *pci_dev, int irq_num)
 {
 return (irq_num + (pci_dev-devfn  3))  1;
@@ -110,6 +125,8 @@ static int raven_pcihost_init(SysBusDevice *dev)
 memory_region_init_io(h-mmcfg, PPC_PCIIO_ops, s, pciio, 0x0040);
 memory_region_add_subregion(address_space_mem, 0x8080, h-mmcfg);
 
+memory_region_init_io(s-intack, PPC_intack_ops, s, pci-intack, 1);
+memory_region_add_subregion(address_space_mem, 0xbff0, s-intack);
 pci_create_simple(bus, 0, raven);
 
 return 0;
-- 
1.7.7

[Qemu-devel] [PULL v2] PReP patch queue 2012-04-30

[Andreas Färber]

Hello Blue,

Please pull the PowerPC Reference Platform (PReP) queue into qemu.git master.

The following changes since commit 42fe1c245f0239ebcdc084740a1777ac3699d071:

  main-loop: Fix build for w32 and w64 (2012-04-28 09:25:54 +)

are available in the git repository at:
  git://repo.or.cz/qemu/afaerber.git prep-up

Hervé Poussineau (5):
  i82378/i82374: Do not create DMA controller twice
  fdc: Parametrize ISA base, IRQ and DMA
  isa: Add isa_bus_from_device() method
  prep: Initialize PC speaker
  prep: Move int-ack register from PReP to Raven PCI emulation

 hw/fdc.c  |   17 ++---
 hw/i82374.c   |5 -
 hw/i82378.c   |5 +++--
 hw/isa.h  |5 +
 hw/ppc_prep.c |   40 
 hw/prep_pci.c |   17 +
 6 files changed, 43 insertions(+), 46 deletions(-)

[Qemu-devel] [PATCH 4/5] prep: Initialize PC speaker

[Andreas Färber]

From: Hervé Poussineau hpous...@reactos.org

Speaker init has been added in 506b7ddf889312659b36c667f7ae17bc9e909418,
but audio subsystem init was missing.

Signed-off-by: Hervé Poussineau hpous...@reactos.org
Signed-off-by: Andreas Färber andreas.faer...@web.de
---
 hw/ppc_prep.c |4 
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/hw/ppc_prep.c b/hw/ppc_prep.c
index 9d8e659..61c655c 100644
--- a/hw/ppc_prep.c
+++ b/hw/ppc_prep.c
@@ -37,6 +37,7 @@
 #include loader.h
 #include mc146818rtc.h
 #include blockdev.h
+#include arch_init.h
 #include exec-memory.h
 
 //#define HARD_DEBUG_PPC_IO
@@ -716,6 +717,9 @@ static void ppc_prep_init (ram_addr_t ram_size,
 
 /* Special port to get debug messages from Open-Firmware */
 register_ioport_write(0x0F00, 4, 1, PPC_debug_write, NULL);
+
+/* Initialize audio subsystem */
+audio_init(isa_bus, pci_bus);
 }
 
 static QEMUMachine prep_machine = {
-- 
1.7.7

Re: [Qemu-devel] [PATCH] Fix SPI SD emulation

[Paul Brook]

  If this command could be issued in transfer state maybe in addition to
  IDLE_STATE you also need to set other bits (ADDRESS_ERROR,
  COM_CRC_ERROR, ILLEGAL_COMMAND, ERASE_SEQ_ERROR) in MSB of R3 response?
  
  In theory, yes.  I was thinking of a follow-up patch to move the spi
  status byte generation into sd.c.  Maybe I should do that first.
 
 Do you mean the one in ssi-sd.c? That would be nice I think, a bit less
 confusing.

I posted v2 of the patch earlier today:

http://lists.nongnu.org/archive/html/qemu-devel/2012-04/msg04214.html

Paul

Re: [Qemu-devel] [Qemu-ppc] [PATCH 20/22] ppc: move load and store helpers, switch to AREG0 free mode

[malc]

On Mon, 30 Apr 2012, Alexander Graf wrote:

 
 On 30.04.2012, at 12:45, Alexander Graf wrote:
 
  
  On 22.04.2012, at 15:26, Blue Swirl wrote:
  
  Add an explicit CPUPPCState parameter instead of relying on AREG0
  and rename op_helper.c (which only contains load and store helpers)
  to mem_helper.c. Remove AREG0 swapping in
  tlb_fill().
  
  Switch to AREG0 free mode. Use cpu_ld{l,uw}_code in translation
  and interrupt handling, cpu_{ld,st}{l,uw}_data in loads and stores.
  
  This patch breaks qemu-system-ppc64 on ppc32 host user space for me. I'm 
  trying to debug it down, but worst case I'll omit this patch set for 1.1.
 
 Ok, so apparently nobody ever tested TCG_AREG0 mode with the ppc tcg 
 target. It looks as if the 
 64-bit-guest-registers-in-32-bit-host-registers code path is missing 
 completely.
 
 This actually makes me less confident that this is a change we want for 
 1.1. I'll remove the patches from the queue.
 
 
 Alex
 
 
 TCG register swizzling code:
 
 #ifdef CONFIG_TCG_PASS_AREG0
 /* XXX/FIXME: suboptimal */
 tcg_out_mov(s, TCG_TYPE_I32, tcg_target_call_iarg_regs[3],
 tcg_target_call_iarg_regs[2]);
 tcg_out_mov(s, TCG_TYPE_I64, tcg_target_call_iarg_regs[2],
 tcg_target_call_iarg_regs[1]);
 tcg_out_mov(s, TCG_TYPE_TL, tcg_target_call_iarg_regs[1],
 tcg_target_call_iarg_regs[0]);
 tcg_out_mov(s, TCG_TYPE_PTR, tcg_target_call_iarg_regs[0],
 TCG_AREG0);
 #endif
 tcg_out_call (s, (tcg_target_long) qemu_st_helpers[opc], 1);
 

The above snippet is incorrect for SysV ppc32 ABI, due to misalignment
of long long argument in register file.

[..snip..]

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

[Qemu-devel] [PATCH] increase BlockConf.min_io_size type from uint16_t to uint32_t

[Michael Tokarev]

This value is used currently for virtio-blk only.  It was defined
as uint16_t before, which is the same as in kernel=user interface
(in virtio_blk.h, struct virtio_blk_config).  But the problem is
that in kernel=user interface the units are sectors (which is
usually 512 bytes or more), while in qemu it is in bytes.  However,
for, say, md raid5 arrays, it is typical to have actual min_io_size
of a host device to be large.  For example, for raid5 device of
3 drives with 64Kb chunk size, that value will be 128Kb, which does
not fit in a uint16_t anymore.

Increase the value size from 16bits to 32bits for now.

But apparently, the kernel=user interface needs to be fixed too
(while it is much more difficult due to compatibility issues),
because even with 512byte units, the 16bit value there will overflow
too with quite normal MD RAID configuration.

Signed-off-by: Michael Tokarev m...@tls.msk.ru
---
 block.h |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/block.h b/block.h
index f163e54..cd5ae79 100644
--- a/block.h
+++ b/block.h
@@ -425,7 +425,7 @@ typedef struct BlockConf {
 BlockDriverState *bs;
 uint16_t physical_block_size;
 uint16_t logical_block_size;
-uint16_t min_io_size;
+uint32_t min_io_size;
 uint32_t opt_io_size;
 int32_t bootindex;
 uint32_t discard_granularity;
@@ -450,7 +450,7 @@ static inline unsigned int get_physical_block_exp(BlockConf 
*conf)
   _conf.logical_block_size, 512),   \
 DEFINE_PROP_BLOCKSIZE(physical_block_size, _state,\
   _conf.physical_block_size, 512),  \
-DEFINE_PROP_UINT16(min_io_size, _state, _conf.min_io_size, 0),  \
+DEFINE_PROP_UINT32(min_io_size, _state, _conf.min_io_size, 0),  \
 DEFINE_PROP_UINT32(opt_io_size, _state, _conf.opt_io_size, 0),\
 DEFINE_PROP_INT32(bootindex, _state, _conf.bootindex, -1),\
 DEFINE_PROP_UINT32(discard_granularity, _state, \
-- 
1.7.10

[Qemu-devel] [PATCH for-1.1 1/2] qemu-ga: Implement alternative to O_ASYNC

[Andreas Färber]

ga_channel_open() was using open flag O_ASYNC for SIGIO-driven I/O.
This breaks on illumos, so fall back to POSIX I_SETSIG ioctl (SIGPOLL).

Signed-off-by: Lee Essen lee.es...@nowonline.co.uk
Signed-off-by: Andreas Färber andreas.faer...@web.de
---
 qga/channel-posix.c |   18 +-
 1 files changed, 17 insertions(+), 1 deletions(-)

diff --git a/qga/channel-posix.c b/qga/channel-posix.c
index 40f7658..57eea06 100644
--- a/qga/channel-posix.c
+++ b/qga/channel-posix.c
@@ -3,6 +3,10 @@
 #include qemu_socket.h
 #include qga/channel.h
 
+#ifdef CONFIG_SOLARIS
+#include stropts.h
+#endif
+
 #define GA_CHANNEL_BAUDRATE_DEFAULT B38400 /* for isa-serial channels */
 
 struct GAChannel {
@@ -123,11 +127,23 @@ static gboolean ga_channel_open(GAChannel *c, const gchar 
*path, GAChannelMethod
 
 switch (c-method) {
 case GA_CHANNEL_VIRTIO_SERIAL: {
-int fd = qemu_open(path, O_RDWR | O_NONBLOCK | O_ASYNC);
+int fd = qemu_open(path, O_RDWR | O_NONBLOCK
+#ifndef CONFIG_SOLARIS
+   | O_ASYNC
+#endif
+   );
 if (fd == -1) {
 g_critical(error opening channel: %s, strerror(errno));
 exit(EXIT_FAILURE);
 }
+#ifdef CONFIG_SOLARIS
+ret = ioctl(fd, I_SETSIG, S_OUTPUT | S_INPUT | S_HIPRI);
+if (ret == -1) {
+g_critical(error setting event mask for channel: %s,
+   strerror(errno));
+exit(EXIT_FAILURE);
+}
+#endif
 ret = ga_channel_client_add(c, fd);
 if (ret) {
 g_critical(error adding channel to main loop);
-- 
1.7.7

[Qemu-devel] [PATCH for-1.1 2/2] configure: Add libraries for qemu-ga on Solaris

[Andreas Färber]

Move socket-related Solaris libraries to $solarisnetlibs and use them
for both $LIBS and $libs_qga.

Fixes build on illumos without --disable-guest-agent.

Signed-off-by: Lee Essen lee.es...@nowonline.co.uk
Signed-off-by: Andreas Färber andreas.faer...@web.de
---
 configure |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/configure b/configure
index fbe4e85..89c58f6 100755
--- a/configure
+++ b/configure
@@ -470,7 +470,9 @@ SunOS)
 # needed for TIOCWIN* defines in termios.h
   QEMU_CFLAGS=-D__EXTENSIONS__ $QEMU_CFLAGS
   QEMU_CFLAGS=-std=gnu99 $QEMU_CFLAGS
-  LIBS=-lsocket -lnsl -lresolv $LIBS
+  solarisnetlibs=-lsocket -lnsl -lresolv
+  LIBS=$solarisnetlibs $LIBS
+  libs_qga=$solarisnetlibs $libs_qga
 ;;
 AIX)
   aix=yes
-- 
1.7.7

[Qemu-devel] [PATCH for-1.1 0/2] qemu-ga: Build fixes for Solaris/illumos

[Andreas Färber]

Hello,

Here's a mini-series fixing the build on illumos like I had requested Lee to do.

Patch 1 introduces a Solaris-only workaround for O_ASYNC that we could
generalize for 1.2 (ifdef O_ASYNC seemed a bit risky to me on Hard Freeze eve
in case some platform uses an enum rather than preprocessor define, given that
ioctl() is consider obsolescent and I_SETSIG optional in POSIX).

Patch 2 adds libraries needed to link qemu-ga on Solaris, reusing the existing
set of backwards-compatible network libraries rather than the new libxnet.

Regards,
Andreas

Cc: Michael Roth mdr...@linux.vnet.ibm.com
Cc: Lee Essen lee.es...@nowonline.co.uk
Cc: Stefan Hajnoczi stefa...@gmail.com
Cc: Blue Swirl blauwir...@gmail.com

Andreas Färber (2):
  qemu-ga: Implement alternative to O_ASYNC
  configure: Add libraries for qemu-ga on Solaris

 configure   |4 +++-
 qga/channel-posix.c |   18 +-
 2 files changed, 20 insertions(+), 2 deletions(-)

-- 
1.7.7

Re: [Qemu-devel] [PATCH V3 11/13] SD card: introduce spi property for SD card objects

[Paul Brook]

 And drop passing is_spi argument to SDCardClass::init function.
 spi property could be set while SD card is in IDLE state. It defaults to
 false.

Why?  This isn't something that should be under user or board control.  The SD 
card object is an implementation detail.  It's something that's part of the 
host controller. i.e. ether an SD host controller or an SPI bus device.

Do you have an example of why you would need to defer this decision?

If you want to separate instantiation of the SD card from the controller (e.g. 
to implement sdio devices) then you need a SD bus, plus an sd card device.  
Something like we do for spi connected cards.

Paul

Re: [Qemu-devel] [Bug 990364] [NEW] virtio_ioport_write: unexpected address 0x13 value 0x1

[Vadim Rozenfeld]

On Monday, April 30, 2012 03:31:03 PM Stefan Hajnoczi wrote:
 Hi Vadim,
 Here is a recent bug report with virtio-win-0.1-22.iso.  Wanted to
 bring it to your attention, please let me know if you already monitor
 these bug emails.
Hi Stefan,
Yes, it's on my radar.
Cheers,
Vadim.
 
 Stefan
 
 On Sat, Apr 28, 2012 at 9:49 AM, Vitalis wor...@gmail.com wrote:
  Public bug reported:
  
  Hello! I have:
  
  virtio_ioport_write: unexpected address 0x13 value 0x1
  
  on config:
  
  LC_ALL=C
  PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin
  QEMU_AUDIO_DRV=none /usr/bin/kvm -S -M pc-0.12 -cpu qemu32 -enable-kvm
  -m 3072 -smp 1 -name nata_xp -uuid da607499-1d8f-e7ef-d1d2-38 1c1839e4ba
  -chardev
  socket,id=monitor,path=/var/lib/libvirt/qemu/nata_xp.monitor,server,nowa
  it -monitor chardev:monitor -localtime -boot c -drive
  file=/root/nata_xp.qcow2,if=virtio,index=0,boot=on,format=raw
  ,cache=none -drive
  file=/home/admino/virtio-win-0.1-22.iso,if=ide,media=cdrom,index=2,forma
  t=raw -net
  nic,macaddr=00:16:36:06:02:69,vlan=0,model=virtio,name=virtio.0 -net
  tap,fd=43,vlan=0,name=tap.0 -serial none -parallel none -usb -usbdevice
  tablet -vnc 127.0.0.1:3 -k en-us -vga cirrus pci_add_option_rom: failed
  to find romfile pxe-virtio.bin
  
  with kernel 2.6.32-40-generic #87-Ubuntu SMP Tue Mar 6 00:56:56 UTC 2012
  x86_64 GNU/Linux qemu drivers are virtio-win-0.1-22.iso
  kvm version 1:84+dfsg-0ubuntu16+0.12.3+noroms+0ubuntu9.18
  qemu 0.12.3+noroms-0ubuntu9.18
  
  ** Affects: qemu
  Importance: Undecided
  Status: New
  
  
  ** Tags: bug kvm virtio
  
  --
  You received this bug notification because you are a member of qemu-
  devel-ml, which is subscribed to QEMU.
  https://bugs.launchpad.net/bugs/990364
  
  Title:
   virtio_ioport_write: unexpected address 0x13 value 0x1
  
  Status in QEMU:
   New
  
  Bug description:
   Hello! I have:
  
   virtio_ioport_write: unexpected address 0x13 value 0x1
  
   on config:
  
   LC_ALL=C
  PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin
  QEMU_AUDIO_DRV=none /usr/bin/kvm -S -M pc-0.12 -cpu qemu32 -enable-kvm
  -m 3072 -smp 1 -name nata_xp -uuid da607499-1d8f-e7ef-d1d2-38 1c1839e4ba
  -chardev
  socket,id=monitor,path=/var/lib/libvirt/qemu/nata_xp.monitor,server,nowa
  it -monitor chardev:monitor -localtime -boot c -drive
  file=/root/nata_xp.qcow2,if=virtio,index=0,boot=on,format=raw
  ,cache=none -drive
  file=/home/admino/virtio-win-0.1-22.iso,if=ide,media=cdrom,index=2,forma
  t=raw -net
  nic,macaddr=00:16:36:06:02:69,vlan=0,model=virtio,name=virtio.0 -net
  tap,fd=43,vlan=0,name=tap.0 -serial none -parallel none -usb -usbdevice
  tablet -vnc 127.0.0.1:3 -k en-us -vga cirrus pci_add_option_rom: failed
  to find romfile pxe-virtio.bin
  
   with kernel 2.6.32-40-generic #87-Ubuntu SMP Tue Mar 6 00:56:56 UTC 2012
  x86_64 GNU/Linux qemu drivers are virtio-win-0.1-22.iso
   kvm version 1:84+dfsg-0ubuntu16+0.12.3+noroms+0ubuntu9.18
   qemu 0.12.3+noroms-0ubuntu9.18
  
  To manage notifications about this bug go to:
  https://bugs.launchpad.net/qemu/+bug/990364/+subscriptions

Re: [Qemu-devel] [PATCH 10/14] target-arm: Move feature register setup to per-CPU init fns

[Paul Brook]

 Move feature register value setup to per-CPU init functions.

 +env-cp15.c0_c1[0] = cpu-id_pfr0;
 +env-cp15.c0_c1[1] = cpu-id_pfr1;
 +env-cp15.c0_c1[2] = cpu-id_dfr0;
 +env-cp15.c0_c1[3] = cpu-id_afr0;
 +env-cp15.c0_c1[4] = cpu-id_mmfr0;
 +env-cp15.c0_c1[5] = cpu-id_mmfr1;
 +env-cp15.c0_c1[6] = cpu-id_mmfr2;
 +env-cp15.c0_c1[7] = cpu-id_mmfr3;
 +env-cp15.c0_c2[0] = cpu-id_isar0;
 +env-cp15.c0_c2[1] = cpu-id_isar1;
 +env-cp15.c0_c2[2] = cpu-id_isar2;
 +env-cp15.c0_c2[3] = cpu-id_isar3;
 +env-cp15.c0_c2[4] = cpu-id_isar4;
 +env-cp15.c0_c2[5] = cpu-id_isar5;

Why are we copying these values? All these registers are readonly, so the 
duplication seems wrong.  Shouldn't we should be using cpu-whatever 
everywhere?

I feel like I've asked this before, but don't remember seeing an answer.


Also, I'd prefer that id_isr5 were explicitly initialized, rather than relying 
on it being implicitly zero.  Bugs in an earlier patch series show how easy it 
is to accidentally miss a register.   IMO it's worth distinguishing a defined 
register that happens to be zero from a register this core doesn't have.  
Overall I'm not convinced that the new open-coded initialization is better 
then the tables it replaces.

Paul

Re: [Qemu-devel] [PATCH 10/14] target-arm: Move feature register setup to per-CPU init fns

[Peter Maydell]

On 30 April 2012 17:21, Paul Brook p...@codesourcery.com wrote:
 Move feature register value setup to per-CPU init functions.

 +    env-cp15.c0_c1[0] = cpu-id_pfr0;
 +    env-cp15.c0_c1[1] = cpu-id_pfr1;
 +    env-cp15.c0_c1[2] = cpu-id_dfr0;
 +    env-cp15.c0_c1[3] = cpu-id_afr0;
 +    env-cp15.c0_c1[4] = cpu-id_mmfr0;
 +    env-cp15.c0_c1[5] = cpu-id_mmfr1;
 +    env-cp15.c0_c1[6] = cpu-id_mmfr2;
 +    env-cp15.c0_c1[7] = cpu-id_mmfr3;
 +    env-cp15.c0_c2[0] = cpu-id_isar0;
 +    env-cp15.c0_c2[1] = cpu-id_isar1;
 +    env-cp15.c0_c2[2] = cpu-id_isar2;
 +    env-cp15.c0_c2[3] = cpu-id_isar3;
 +    env-cp15.c0_c2[4] = cpu-id_isar4;
 +    env-cp15.c0_c2[5] = cpu-id_isar5;

 Why are we copying these values? All these registers are readonly, so the
 duplication seems wrong.  Shouldn't we should be using cpu-whatever
 everywhere?

 I feel like I've asked this before, but don't remember seeing an answer.

My proposed cp15 rework deletes this copying code; instead the registers
are defined with values set directly from the cpu-whatever fields:
 http://lists.gnu.org/archive/html/qemu-devel/2012-04/msg01811.html

 Also, I'd prefer that id_isr5 were explicitly initialized, rather than relying
 on it being implicitly zero.  Bugs in an earlier patch series show how easy it
 is to accidentally miss a register.   IMO it's worth distinguishing a defined
 register that happens to be zero from a register this core doesn't have.

Yes, I think that's probably a good idea.

-- PMM

[Qemu-devel] Poking a sun4v machine

[Artyom Tarasenko]

Tried to boot QEMU Niagara machine with the firmware from the
OpenSPARC T1 emulator ( www.opensparc.net/opensparc-t1/download.html )
, and it dies very early.
The reason: in translate.c

#define hypervisor(dc) (dc-mem_idx == MMU_HYPV_IDX)
#define supervisor(dc) (dc-mem_idx = MMU_KERNEL_IDX)

and the dc-mem_idx is initialized like this:

if (env1-tl  0) {
return MMU_NUCLEUS_IDX;
} else if (cpu_hypervisor_mode(env1)) {
return MMU_HYPV_IDX;
} else if (cpu_supervisor_mode(env1)) {
return MMU_KERNEL_IDX;
} else {
return MMU_USER_IDX;
}

Which seems to be conceptually incorrect. After reset tl == MAXTL, but
still super- and hyper-visor bits are set, so both supervisor(dc) and
hypervisor(dc) must return 1 which is impossible in the current
implementation.

What would be the proper way to fix it? Make mem_idx bitmap, add two
more variables to DisasContext, or ...?

Some other findings/questions:

/* Sun4v generic Niagara machine */
{
.default_cpu_model = Sun UltraSparc T1,
.console_serial_base = 0xfff0c2c000ULL,

Where is this address coming from? The OpenSPARC Niagara machine has a
dumb serial at 0x1f1000ULL.

And the biggest issue: UA2005 (as well as UA2007) describe a totally
different format for a MMU TTE entry than the one sun4u CPU are using.
I think the best way to handle it would be splitting off Niagara
machine, and #defining MMU bits differently for sun4u and sun4v
machines.

Do we the cases in qemu where more than two (qemu-system-xxx and
qemu-system-xxx64) binaries are produced?
Would the name qemu-system-sun4v fit the naming convention?

Artyom

-- 
Regards,
Artyom Tarasenko

solaris/sparc under qemu blog: http://tyom.blogspot.com/search/label/qemu

Re: [Qemu-devel] [PATCH 10/14] target-arm: Move feature register setup to per-CPU init fns

[Andreas Färber]

Am 30.04.2012 18:21, schrieb Paul Brook:
 Move feature register value setup to per-CPU init functions.
 
 +env-cp15.c0_c1[0] = cpu-id_pfr0;
 +env-cp15.c0_c1[1] = cpu-id_pfr1;
 +env-cp15.c0_c1[2] = cpu-id_dfr0;
 +env-cp15.c0_c1[3] = cpu-id_afr0;
 +env-cp15.c0_c1[4] = cpu-id_mmfr0;
 +env-cp15.c0_c1[5] = cpu-id_mmfr1;
 +env-cp15.c0_c1[6] = cpu-id_mmfr2;
 +env-cp15.c0_c1[7] = cpu-id_mmfr3;
 +env-cp15.c0_c2[0] = cpu-id_isar0;
 +env-cp15.c0_c2[1] = cpu-id_isar1;
 +env-cp15.c0_c2[2] = cpu-id_isar2;
 +env-cp15.c0_c2[3] = cpu-id_isar3;
 +env-cp15.c0_c2[4] = cpu-id_isar4;
 +env-cp15.c0_c2[5] = cpu-id_isar5;
 
 Why are we copying these values? All these registers are readonly, so the 
 duplication seems wrong.  Shouldn't we should be using cpu-whatever 
 everywhere?
 
 I feel like I've asked this before, but don't remember seeing an answer.

You had asked about duplication between ARMCPUClass and ARMCPU, and
there were answers.

Peter has now avoided adding fields to ARMCPUClass in favor of adding
some fields to ARMCPU and multiple initfn functions that spare some
ARMCPUClass - ARMCPU copying through imperative hardcoding. In
particular that was your request wrt non-declarative feature flags.

There is also a follow-up series by Peter which reworks cp15 as a list
of structs, so touching all cp15 code for cpu- rather than env- access
did not seem like a good idea to me.

 Overall I'm not convinced that the new open-coded initialization is better 
 then the tables it replaces.

What I like better after this series is that it's in CPU-specific code
rather than in common code trying to cater to all CPU models based on
CPUID, which includes revision and variant numbers that we would like to
expose as user-tunable QOM properties rather than as different CPU types
where possible.

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] sdl: Disable broken scaling

[Stefan Weil]

SDL scaling uses a broken version of SDL_rotozoom
which does out-of-bounds memory access.

Disable it for QEMU 1.1 until a better solution is found.

Cc: Anthony Liguori aligu...@us.ibm.com
Signed-off-by: Stefan Weil s...@weilnetz.de
---
 qemu-doc.texi |4 ++--
 ui/sdl.c  |   12 
 2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/qemu-doc.texi b/qemu-doc.texi
index 9e07ba6..a72289f 100644
--- a/qemu-doc.texi
+++ b/qemu-doc.texi
@@ -290,11 +290,11 @@ Toggle full screen
 
 @item Ctrl-Alt-+
 @kindex Ctrl-Alt-+
-Enlarge the screen
+Enlarge the screen. This function is currently disabled.
 
 @item Ctrl-Alt--
 @kindex Ctrl-Alt--
-Shrink the screen
+Shrink the screen. This function is currently disabled.
 
 @item Ctrl-Alt-u
 @kindex Ctrl-Alt-u
diff --git a/ui/sdl.c b/ui/sdl.c
index f6f711c..8700b7a 100644
--- a/ui/sdl.c
+++ b/ui/sdl.c
@@ -34,6 +34,13 @@
 #include x_keymap.h
 #include sdl_zoom.h
 
+#if 0
+/* Scaling with SDL is broken, therefore it is disabled by default.
+ * It can be enabled by defining the following macro.
+ */
+# define CONFIG_SDL_SCALING
+#endif
+
 static DisplayChangeListener *dcl;
 static SDL_Surface *real_screen;
 static SDL_Surface *guest_screen = NULL;
@@ -638,6 +645,7 @@ static void handle_keydown(DisplayState *ds, SDL_Event *ev)
 break;
 case 0x1b: /* '+' */
 case 0x35: /* '-' */
+#if defined(CONFIG_SDL_SCALING)
 if (!gui_fullscreen) {
 int width = MAX(real_screen-w + (keycode == 0x1b ? 50 : -50),
 160);
@@ -648,6 +656,8 @@ static void handle_keydown(DisplayState *ds, SDL_Event *ev)
 vga_hw_update();
 gui_keysym = 1;
 }
+#endif /* CONFIG_SDL_SCALING */
+break;
 default:
 break;
 }
@@ -889,9 +899,11 @@ static void sdl_refresh(DisplayState *ds)
 handle_activation(ds, ev);
 break;
 case SDL_VIDEORESIZE:
+#if defined(CONFIG_SDL_SCALING)
 sdl_scale(ds, ev-resize.w, ev-resize.h);
 vga_hw_invalidate();
 vga_hw_update();
+#endif
 break;
 default:
 break;
-- 
1.7.9

Re: [Qemu-devel] Poking a sun4v machine

[Andreas Färber]

Am 30.04.2012 18:39, schrieb Artyom Tarasenko:
 Tried to boot QEMU Niagara machine with the firmware from the
 OpenSPARC T1 emulator ( www.opensparc.net/opensparc-t1/download.html )
 , and it dies very early.
 The reason: in translate.c
 
 #define hypervisor(dc) (dc-mem_idx == MMU_HYPV_IDX)
 #define supervisor(dc) (dc-mem_idx = MMU_KERNEL_IDX)
 
 and the dc-mem_idx is initialized like this:
 
 if (env1-tl  0) {
 return MMU_NUCLEUS_IDX;
 } else if (cpu_hypervisor_mode(env1)) {
 return MMU_HYPV_IDX;
 } else if (cpu_supervisor_mode(env1)) {
 return MMU_KERNEL_IDX;
 } else {
 return MMU_USER_IDX;
 }
 
 Which seems to be conceptually incorrect. After reset tl == MAXTL, but
 still super- and hyper-visor bits are set, so both supervisor(dc) and
 hypervisor(dc) must return 1 which is impossible in the current
 implementation.
 
 What would be the proper way to fix it? Make mem_idx bitmap, add two
 more variables to DisasContext, or ...?
 
 Some other findings/questions:
 
 /* Sun4v generic Niagara machine */
 {
 .default_cpu_model = Sun UltraSparc T1,
 .console_serial_base = 0xfff0c2c000ULL,
 
 Where is this address coming from? The OpenSPARC Niagara machine has a
 dumb serial at 0x1f1000ULL.
 
 And the biggest issue: UA2005 (as well as UA2007) describe a totally
 different format for a MMU TTE entry than the one sun4u CPU are using.
 I think the best way to handle it would be splitting off Niagara
 machine, and #defining MMU bits differently for sun4u and sun4v
 machines.
 
 Do we the cases in qemu where more than two (qemu-system-xxx and
 qemu-system-xxx64) binaries are produced?
 Would the name qemu-system-sun4v fit the naming convention?

We have such a case for ppc (ppcemb) and it is kind of a maintenance
nightmare - I'm working towards getting rid of it with my QOM CPU work.
Better avoid it for sparc in the first place.

Instead, you should add a callback function pointer to SPARCCPUClass
that you initialize based on CPU model so that is behaves differently at
runtime rather than at compile time.
Or if it's just about the class_init then after the Hard Freeze I can
start polishing my subclasses for sparc so that you can add a special
class_init for Niagara.

Helpers such as cpu_hypervisor_mode() will need to be changed to take a
SPARCCPU *cpu rather than CPUSPARCState *env argument; as an interim
solution sparc_env_get_cpu() can be used. (examples on the list for sh4)

Andreas

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

Re: [Qemu-devel] Poking a sun4v machine

[Artyom Tarasenko]

On Mon, Apr 30, 2012 at 7:15 PM, Andreas Färber afaer...@suse.de wrote:
 Am 30.04.2012 18:39, schrieb Artyom Tarasenko:
 Tried to boot QEMU Niagara machine with the firmware from the
 OpenSPARC T1 emulator ( www.opensparc.net/opensparc-t1/download.html )
 , and it dies very early.
 The reason: in translate.c

 #define hypervisor(dc) (dc-mem_idx == MMU_HYPV_IDX)
 #define supervisor(dc) (dc-mem_idx = MMU_KERNEL_IDX)

 and the dc-mem_idx is initialized like this:

     if (env1-tl  0) {
         return MMU_NUCLEUS_IDX;
     } else if (cpu_hypervisor_mode(env1)) {
         return MMU_HYPV_IDX;
     } else if (cpu_supervisor_mode(env1)) {
         return MMU_KERNEL_IDX;
     } else {
         return MMU_USER_IDX;
     }

 Which seems to be conceptually incorrect. After reset tl == MAXTL, but
 still super- and hyper-visor bits are set, so both supervisor(dc) and
 hypervisor(dc) must return 1 which is impossible in the current
 implementation.

 What would be the proper way to fix it? Make mem_idx bitmap, add two
 more variables to DisasContext, or ...?

 Some other findings/questions:

     /* Sun4v generic Niagara machine */
     {
         .default_cpu_model = Sun UltraSparc T1,
         .console_serial_base = 0xfff0c2c000ULL,

 Where is this address coming from? The OpenSPARC Niagara machine has a
 dumb serial at 0x1f1000ULL.

 And the biggest issue: UA2005 (as well as UA2007) describe a totally
 different format for a MMU TTE entry than the one sun4u CPU are using.
 I think the best way to handle it would be splitting off Niagara
 machine, and #defining MMU bits differently for sun4u and sun4v
 machines.

 Do we the cases in qemu where more than two (qemu-system-xxx and
 qemu-system-xxx64) binaries are produced?
 Would the name qemu-system-sun4v fit the naming convention?

 We have such a case for ppc (ppcemb) and it is kind of a maintenance
 nightmare - I'm working towards getting rid of it with my QOM CPU work.
 Better avoid it for sparc in the first place.

 Instead, you should add a callback function pointer to SPARCCPUClass
 that you initialize based on CPU model so that is behaves differently at
 runtime rather than at compile time.
 Or if it's just about the class_init then after the Hard Freeze I can
 start polishing my subclasses for sparc so that you can add a special
 class_init for Niagara.

But this would mean that the defines from
#define TTE_NFO_BIT (1ULL  60)
to
#define TTE_PGSIZE(tte) (((tte)  61)  3ULL)

inclusive would need to be replaced with functions and variables?
Sounds like a further performance regression for sun4u?

And would it be possible to have a different register set for an
inherited SPARCCPUClass ?
Also trap handling and related cpu registers behavior has to be quite different.

Artyom

 Helpers such as cpu_hypervisor_mode() will need to be changed to take a
 SPARCCPU *cpu rather than CPUSPARCState *env argument; as an interim
 solution sparc_env_get_cpu() can be used. (examples on the list for sh4)

 Andreas

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



-- 
Regards,
Artyom Tarasenko

solaris/sparc under qemu blog: http://tyom.blogspot.com/search/label/qemu

Re: [Qemu-devel] [PATCH v2 4/6] prep: move int-ack register from PReP to Raven PCI emulation

[Andreas Färber]

Am 30.04.2012 10:43, schrieb Avi Kivity:
 On 04/29/2012 11:12 PM, Andreas Färber wrote:
 Am 29.04.2012 10:32, schrieb Avi Kivity:
 On 04/28/2012 09:46 PM, Andreas Färber wrote:
 Am 14.04.2012 22:48, schrieb Hervé Poussineau:
 Register is one byte-wide (as per specification), so there is no need to 
 specify endianness.

 The region was 4 bytes before, now it's 1. What happens when a 4-byte
 read is attempted at that address? Do we need to specify the valid
 widths for the MemoryRegion? Or is such a read constructed from this
 region and (assuming) the return value of an unassigned read?

 This area of what happens during access that falls across region
 boundaries is very underspecified in qemu; nor is it clear what happens
 in real hardware (in all its variations).

 So, what's your conclusion here? Should we add .valid.max_access_size =
 1? Or shall I apply as is?
 
 If the specification says 1 byte and there are no known guests that
 abuse it, I say change it.

Thanks, applied to prep-up branch (with .max_access_size = 1 and
autobreaking the commit message):
http://repo.or.cz/w/qemu/afaerber.git/shortlog/refs/heads/prep-up

Andreas

[Qemu-devel] [Bug 992067] [NEW] Windows 2008R2 very slow cold boot when 4GB memory

[Matthew Anderson]

Public bug reported:

I've been having a consistent problem booting 2008R2 guests with 4096MB
of RAM or greater. On the initial boot the KVM process starts out with a
~200MB memory allocation and will use 100% of all CPU allocated to it.
The RES memory of the KVM process slowly rises by around 200mb every few
minutes until it reaches it's memory allocation (several hours in some
cases). Whilst this is happening the guest will usually blue screen with
the message of -

A clock interrupt was not received on a secondary processor within the
allocated time interval

If I let the KVM process continue to run it will eventually allocate the
required memory the guest will run at full speed, usually restarting
after the blue screen and booting into startup repair. From here you can
restart it and it will boot perfectly. Once booted the guest has no
performance issues at all.

I've tried everything I could think of. Removing PAE, playing with huge
pages, different kernels, different userspaces, different systems,
different backing file systems, different processor feature set, with or
without Virtio etc. My best theory is that the problem is caused by
Windows 2008 zeroing out all the memory on boot and something is causing
this to be held up or slowed to a crawl. The hosts always have memory
free to boot the guest and are not using swap at all.

Nothing so far has solved the issue. A few observations I've made about the 
issue are - 
Large memory 2008R2 guests seem to boot fine (or with a small delay) when they 
are the first to boot on the host after a reboot
Sometimes dropping the disk cache (echo 1  /proc/sys/vm/drop_caches) will 
cause them to boot faster


The hosts I've tried are -
All Nehalem based (5540, 5620 and 5660)
Host ram of 48GB, 96GB and 192GB
Storage on NFS, Gluster and local (ext4, xfs and zfs)
QED, QCOW and RAW formats
Scientific Linux 6.1 with the standard kernel 2.6.32, 2.6.38 and 3.3.1
KVM userspaces 0.12, 0.14 and (currently) 0.15.1

** Affects: qemu
 Importance: Undecided
 Status: New

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

Title:
  Windows 2008R2 very slow cold boot when 4GB memory

Status in QEMU:
  New

Bug description:
  I've been having a consistent problem booting 2008R2 guests with
  4096MB of RAM or greater. On the initial boot the KVM process starts
  out with a ~200MB memory allocation and will use 100% of all CPU
  allocated to it. The RES memory of the KVM process slowly rises by
  around 200mb every few minutes until it reaches it's memory allocation
  (several hours in some cases). Whilst this is happening the guest will
  usually blue screen with the message of -

  A clock interrupt was not received on a secondary processor within the
  allocated time interval

  If I let the KVM process continue to run it will eventually allocate
  the required memory the guest will run at full speed, usually
  restarting after the blue screen and booting into startup repair. From
  here you can restart it and it will boot perfectly. Once booted the
  guest has no performance issues at all.

  I've tried everything I could think of. Removing PAE, playing with
  huge pages, different kernels, different userspaces, different
  systems, different backing file systems, different processor feature
  set, with or without Virtio etc. My best theory is that the problem is
  caused by Windows 2008 zeroing out all the memory on boot and
  something is causing this to be held up or slowed to a crawl. The
  hosts always have memory free to boot the guest and are not using swap
  at all.

  Nothing so far has solved the issue. A few observations I've made about the 
issue are - 
  Large memory 2008R2 guests seem to boot fine (or with a small delay) when 
they are the first to boot on the host after a reboot
  Sometimes dropping the disk cache (echo 1  /proc/sys/vm/drop_caches) will 
cause them to boot faster

  
  The hosts I've tried are -
  All Nehalem based (5540, 5620 and 5660)
  Host ram of 48GB, 96GB and 192GB
  Storage on NFS, Gluster and local (ext4, xfs and zfs)
  QED, QCOW and RAW formats
  Scientific Linux 6.1 with the standard kernel 2.6.32, 2.6.38 and 3.3.1
  KVM userspaces 0.12, 0.14 and (currently) 0.15.1

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

[Qemu-devel] [Bug 992067] Re: Windows 2008R2 very slow cold boot when 4GB memory

[Anthony Liguori]

This should be resolved by using Hyper-V relaxed timers which is in the
latest development version of QEMU.  You would need to add -cpu
host,+hv_relaxed to the command line to verify this.

** Changed in: qemu
   Status: New = Fix Committed

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

Title:
  Windows 2008R2 very slow cold boot when 4GB memory

Status in QEMU:
  Fix Committed

Bug description:
  I've been having a consistent problem booting 2008R2 guests with
  4096MB of RAM or greater. On the initial boot the KVM process starts
  out with a ~200MB memory allocation and will use 100% of all CPU
  allocated to it. The RES memory of the KVM process slowly rises by
  around 200mb every few minutes until it reaches it's memory allocation
  (several hours in some cases). Whilst this is happening the guest will
  usually blue screen with the message of -

  A clock interrupt was not received on a secondary processor within the
  allocated time interval

  If I let the KVM process continue to run it will eventually allocate
  the required memory the guest will run at full speed, usually
  restarting after the blue screen and booting into startup repair. From
  here you can restart it and it will boot perfectly. Once booted the
  guest has no performance issues at all.

  I've tried everything I could think of. Removing PAE, playing with
  huge pages, different kernels, different userspaces, different
  systems, different backing file systems, different processor feature
  set, with or without Virtio etc. My best theory is that the problem is
  caused by Windows 2008 zeroing out all the memory on boot and
  something is causing this to be held up or slowed to a crawl. The
  hosts always have memory free to boot the guest and are not using swap
  at all.

  Nothing so far has solved the issue. A few observations I've made about the 
issue are - 
  Large memory 2008R2 guests seem to boot fine (or with a small delay) when 
they are the first to boot on the host after a reboot
  Sometimes dropping the disk cache (echo 1  /proc/sys/vm/drop_caches) will 
cause them to boot faster

  
  The hosts I've tried are -
  All Nehalem based (5540, 5620 and 5660)
  Host ram of 48GB, 96GB and 192GB
  Storage on NFS, Gluster and local (ext4, xfs and zfs)
  QED, QCOW and RAW formats
  Scientific Linux 6.1 with the standard kernel 2.6.32, 2.6.38 and 3.3.1
  KVM userspaces 0.12, 0.14 and (currently) 0.15.1

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

Re: [Qemu-devel] [PATCH] main-loop: Calculate poll timeout using timeout argument

[Paolo Bonzini]

Il 29/04/2012 19:15, Stefan Weil ha scritto:
 The timeout argument was unused up to now,
 but it can be used to reduce the poll_timeout when it is infinite
 (negative value) or larger than timeout.
 
 Signed-off-by: Stefan Weil s...@weilnetz.de
 ---
  main-loop.c |6 +-
  1 files changed, 5 insertions(+), 1 deletions(-)
 
 diff --git a/main-loop.c b/main-loop.c
 index 24cf540..eb3b6e6 100644
 --- a/main-loop.c
 +++ b/main-loop.c
 @@ -425,7 +425,7 @@ static int os_host_main_loop_wait(uint32_t timeout)
  if (nfds = 0) {
  ret = select(nfds + 1, rfds, wfds, xfds, tv0);
  if (ret != 0) {
 -/* TODO. */
 +timeout = 0;
  }
  }
  
 @@ -439,6 +439,10 @@ static int os_host_main_loop_wait(uint32_t timeout)
  poll_fds[n_poll_fds + i].events = G_IO_IN;
  }
  
 +if (poll_timeout  0 || timeout  poll_timeout) {
 +poll_timeout = timeout;
 +}
 +
  qemu_mutex_unlock_iothread();
  ret = g_poll(poll_fds, n_poll_fds + w-num, poll_timeout);
  qemu_mutex_lock_iothread();

Reviewed-by: Paolo Bonzini pbonz...@redhat.com

Re: [Qemu-devel] [PATCH v2 06/24] qdev: fix -device foo,?

[Paolo Bonzini]

Il 27/04/2012 17:44, Anthony Liguori ha scritto:
 On 04/27/2012 04:37 AM, Jiri Denemark wrote:
 On Wed, Apr 11, 2012 at 23:30:24 +0200, Paolo Bonzini wrote:
 Since most property types do not have a parse property now, this was
 broken.  Fix it by looking at the setter instead.

 Signed-off-by: Paolo Bonzinipbonz...@redhat.com
 ---
   hw/qdev-monitor.c |4 ++--
   1 file changed, 2 insertions(+), 2 deletions(-)

 diff --git a/hw/qdev-monitor.c b/hw/qdev-monitor.c
 index 4783366..0acfc82 100644
 --- a/hw/qdev-monitor.c
 +++ b/hw/qdev-monitor.c
 @@ -157,7 +157,7 @@ int qdev_device_help(QemuOpts *opts)
* for removal.  This conditional should be removed along with
* it.
*/
 -if (!prop-info-parse) {
 +if (!prop-info-set) {
   continue;   /* no way to set it, don't show */
   }
   error_printf(%s.%s=%s\n, driver, prop-name,
 @@ -165,7 +165,7 @@ int qdev_device_help(QemuOpts *opts)
   }
   if (info-bus_info) {
   for (prop = info-bus_info-props; prop  prop-name;
 prop++) {
 -if (!prop-info-parse) {
 +if (!prop-info-set) {
   continue;   /* no way to set it, don't show */
   }
   error_printf(%s.%s=%s\n, driver, prop-name,

 Oops, this patch (or an equivalent fix) doesn't seem to have been ever
 applied,
 
 Yeah, there were a couple problems with the full series.  Paolo, can I
 just cherry pick this patch?

Yes, please.

Paolo

Re: [Qemu-devel] [PATCH 3/3] configure: add '--disable-cocoa' switch

[Andreas Färber]

Am 17.01.2012 00:46, schrieb Andrzej Zaborowski:
 On 14 January 2012 01:42, Andreas Färber andreas.faer...@web.de wrote:
 Am 08.12.2011 01:41, schrieb Andreas Färber:
 Am 10.11.2011 19:40, schrieb Pavel Borzenkov:
 When SDL support is disabled, there is no way to build QEMU without
 Cocoa support on MacOS X. This patch adds '--disable-cocoa' switch and
 allows to build QEMU without both SDL and Cocoa frontends.

 Signed-off-by: Pavel Borzenkov pavel.borzen...@gmail.com
 ---
  configure |7 ++-
  1 files changed, 6 insertions(+), 1 deletions(-)

 diff --git a/configure b/configure
 index 401d9a6..4720bb2 100755
 --- a/configure
 +++ b/configure
 @@ -670,6 +670,8 @@ for opt do
;;
--enable-profiler) profiler=yes
;;
 +  --disable-cocoa) cocoa=no
 +  ;;
--enable-cocoa)
cocoa=yes ;
sdl=no ;

 Tested-by: Andreas Färber andreas.faer...@web.de

 @@ -980,7 +982,10 @@ echo   --disable-sdldisable SDL
  echo   --enable-sdl enable SDL
  echo   --disable-vncdisable VNC
  echo   --enable-vnc enable VNC
 -echo   --enable-cocoa   enable COCOA (Mac OS X only)
 +if test $darwin = yes ; then
 +echo   --disable-cocoa  disable COCOA
 +echo   --enable-cocoa   enable COCOA (default)
 +fi
  echo   --audio-drv-list=LISTset audio drivers list:
  echoAvailable drivers: 
 $audio_possible_drivers
  echo   --audio-card-list=LIST   set list of emulated audio cards 
 [$audio_card_list]

 I see no prior art of any conditional help output in configure. Anthony?
 Andrzej?

 Ping? Should we keep command line options a flat list with comments on
 applicability or start introducing tests like above?

 Me, I'd prefer not doing this since the switch cases above don't check.
 
 Perhaps --diable-cocoa should be allowed on any platform.  You're
 right we don't have such checks now, but then it's hard to see
 downsides of doing them, so I'm quite ambivalent.

Lacking time for larger configure refactorings before 1.1 I've applied
it to the cocoa branch (with the if removed and text adjusted):
http://repo.or.cz/w/qemu/afaerber.git/shortlog/refs/heads/cocoa-for-upstream

Andreas

[Qemu-devel] [Bug 992067] Re: Windows 2008R2 very slow cold boot when 4GB memory

[Matthew Anderson]

Thanks for the quick reply,

I pulled the latest version from Git and on first attempt it said the
hv_relaxed feature was not present. I checked the source and the
'hv_relaxed' feature was not included in a 'feature_name' array so the
flag was being discarded before it could be enabled.

Once added in to the 'feature_name' array it was enabled but the VM
crashes on boot with a blue screen and the error message
Phase0_exception followed by a reboot.

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

Title:
  Windows 2008R2 very slow cold boot when 4GB memory

Status in QEMU:
  Fix Committed

Bug description:
  I've been having a consistent problem booting 2008R2 guests with
  4096MB of RAM or greater. On the initial boot the KVM process starts
  out with a ~200MB memory allocation and will use 100% of all CPU
  allocated to it. The RES memory of the KVM process slowly rises by
  around 200mb every few minutes until it reaches it's memory allocation
  (several hours in some cases). Whilst this is happening the guest will
  usually blue screen with the message of -

  A clock interrupt was not received on a secondary processor within the
  allocated time interval

  If I let the KVM process continue to run it will eventually allocate
  the required memory the guest will run at full speed, usually
  restarting after the blue screen and booting into startup repair. From
  here you can restart it and it will boot perfectly. Once booted the
  guest has no performance issues at all.

  I've tried everything I could think of. Removing PAE, playing with
  huge pages, different kernels, different userspaces, different
  systems, different backing file systems, different processor feature
  set, with or without Virtio etc. My best theory is that the problem is
  caused by Windows 2008 zeroing out all the memory on boot and
  something is causing this to be held up or slowed to a crawl. The
  hosts always have memory free to boot the guest and are not using swap
  at all.

  Nothing so far has solved the issue. A few observations I've made about the 
issue are - 
  Large memory 2008R2 guests seem to boot fine (or with a small delay) when 
they are the first to boot on the host after a reboot
  Sometimes dropping the disk cache (echo 1  /proc/sys/vm/drop_caches) will 
cause them to boot faster

  
  The hosts I've tried are -
  All Nehalem based (5540, 5620 and 5660)
  Host ram of 48GB, 96GB and 192GB
  Storage on NFS, Gluster and local (ext4, xfs and zfs)
  QED, QCOW and RAW formats
  Scientific Linux 6.1 with the standard kernel 2.6.32, 2.6.38 and 3.3.1
  KVM userspaces 0.12, 0.14 and (currently) 0.15.1

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

Re: [Qemu-devel] [Bug 992067] Re: Windows 2008R2 very slow cold boot when 4GB memory

[Andreas Färber]

Am 30.04.2012 22:14, schrieb Matthew Anderson:
 I pulled the latest version from Git and on first attempt it said the
 hv_relaxed feature was not present. I checked the source and the
 'hv_relaxed' feature was not included in a 'feature_name' array so the
 flag was being discarded before it could be enabled.

It should've been -cpu host,hv_relaxed (without the +).
No need to add to the feature_name array.

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] ARM target w/ self modifying code

[Emmanuel Blot]

Hi,

I'm porting QEMU (1.0.x) to a new ARM based platform (qemu-system-arm
on a x86/64 host)

The platform is using an ARM7TDMI core with no cache.

Up to now everything was working fine, but I've recently bumped into
an issue I have real hard time to solve:

The native ARM code is replicating time-critical code (ISR mostly) at
run time from a DRAM memory into a small faster SRAM memory of the
physical device. The DRAM and SRAM physical devices are implemented as
two distinct memory regions.

The behavior is quite similar to self-modifying code [1], as new code
is added into an uninitialized memory region (it is replicated rather
than created).

As there is no cache and no MMU on the platform, there is no explicit
way to inform QEMU that new code has been updated in the SRAM memory
region.

It seems that this causes trouble to QEMU: the virtual ARM CPU
triggers an undefined instruction exception the first time the ARM PC
points to code that has been replicated in SRAM. Using the QEMU traces
shows that QEMU thinks the memory region is initialized with zeroes
rather than with the replicated code. The TCG generates host opcode
for the ARM '0x0' instruction, which is not a valid ARM instruction.

Looking at old QEMU documentation, it seems that x86 targets have
solve this issue by flagging the TB memory pages as read/only [2],
which allows to invalidate the TB cache whenever a page is overwritten
with new code.

I'm not sure if my analysis is correct, if the x86 hint is still in
use, and if it is the best way to address this issue on cache-less,
MMU-less ARM targets.

I've spent some hours trying to understand the QEMU code on this
topic, but I'm a bit confused right now.

Any advice would be great, as well as specific function(s) to look at.

Thanks,
Manu

[1] http://lists.gnu.org/archive/html/qemu-devel/2011-11/msg00556.html
[2] 
http://static.usenix.org/event/usenix05/tech/freenix/full_papers/bellard/bellard.pdf

[Qemu-devel] [PULL] Cocoa patch queue 2012-05-01

[Andreas Färber]

Hello Blue,

Please pull the Cocoa queue into qemu.git master.

The following changes since commit 42fe1c245f0239ebcdc084740a1777ac3699d071:
  Stefan Weil (1):
main-loop: Fix build for w32 and w64

are available in the git repository at:

  git://repo.or.cz/qemu/afaerber.git cocoa-for-upstream

Andreas Färber (1):
  Drop darwin-user

Pavel Borzenkov (2):
  raw-posix: Do not use CONFIG_COCOA macro
  configure: add '--disable-cocoa' switch

 MAINTAINERS  |5 -
 Makefile.target  |   28 -
 block/raw-posix.c|8 +-
 configure|   30 +-
 darwin-user/commpage.c   |  357 
 darwin-user/ioctls.h |4 -
 darwin-user/ioctls_types.h   |1 -
 darwin-user/machload.c   |  902 ---
 darwin-user/main.c   | 1027 --
 darwin-user/mmap.c   |  409 -
 darwin-user/qemu.h   |  178 
 darwin-user/signal.c |  452 --
 darwin-user/syscall.c| 1566 --
 darwin-user/syscalls.h   |  384 -
 default-configs/i386-darwin-user.mak |1 -
 default-configs/ppc-darwin-user.mak  |3 -
 qemu-doc.texi|   90 --
 qemu-tech.texi   |3 +-
 18 files changed, 9 insertions(+), 5439 deletions(-)
 delete mode 100644 darwin-user/commpage.c
 delete mode 100644 darwin-user/ioctls.h
 delete mode 100644 darwin-user/ioctls_types.h
 delete mode 100644 darwin-user/machload.c
 delete mode 100644 darwin-user/main.c
 delete mode 100644 darwin-user/mmap.c
 delete mode 100644 darwin-user/qemu.h
 delete mode 100644 darwin-user/signal.c
 delete mode 100644 darwin-user/syscall.c
 delete mode 100644 darwin-user/syscalls.h
 delete mode 100644 default-configs/i386-darwin-user.mak
 delete mode 100644 default-configs/ppc-darwin-user.mak

[Qemu-devel] [PATCH 2/3] configure: add '--disable-cocoa' switch

[Andreas Färber]

From: Pavel Borzenkov pavel.borzen...@gmail.com

When SDL support is disabled, there is no way to build QEMU without
Cocoa support on MacOS X. This patch adds '--disable-cocoa' switch and
allows to build QEMU without both SDL and Cocoa frontends.

Signed-off-by: Pavel Borzenkov pavel.borzen...@gmail.com
[AF: Adapt help output]
Signed-off-by: Andreas Färber andreas.faer...@web.de
---
 configure |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/configure b/configure
index 25697bb..0cf3bbb 100755
--- a/configure
+++ b/configure
@@ -714,6 +714,8 @@ for opt do
   ;;
   --enable-profiler) profiler=yes
   ;;
+  --disable-cocoa) cocoa=no
+  ;;
   --enable-cocoa)
   cocoa=yes ;
   sdl=no ;
@@ -1027,7 +1029,8 @@ echo   --disable-virtfs disable VirtFS
 echo   --enable-virtfs  enable VirtFS
 echo   --disable-vncdisable VNC
 echo   --enable-vnc enable VNC
-echo   --enable-cocoa   enable COCOA (Mac OS X only)
+echo   --disable-cocoa  disable Cocoa (Mac OS X only)
+echo   --enable-cocoa   enable Cocoa (default on Mac OS X)
 echo   --audio-drv-list=LISTset audio drivers list:
 echoAvailable drivers: $audio_possible_drivers
 echo   --audio-card-list=LIST   set list of emulated audio cards 
[$audio_card_list]
-- 
1.7.0.3

[Qemu-devel] [PATCH 1/3] raw-posix: Do not use CONFIG_COCOA macro

[Andreas Färber]

From: Pavel Borzenkov pavel.borzen...@gmail.com

Use __APPLE__ and __MACH__ macros instead of CONFIG_COCOA to detect Mac
OS X host. The patch is based on Ben Leslie's patch:
http://patchwork.ozlabs.org/patch/97859/

Signed-off-by: Ben Leslie be...@benno.id.au
Signed-off-by: Pavel Borzenkov pavel.borzen...@gmail.com
Signed-off-by: Andreas Färber andreas.faer...@web.de
---
 block/raw-posix.c |8 
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/block/raw-posix.c b/block/raw-posix.c
index 2d1bc13..03fcfcc 100644
--- a/block/raw-posix.c
+++ b/block/raw-posix.c
@@ -29,7 +29,7 @@
 #include module.h
 #include block/raw-posix-aio.h
 
-#ifdef CONFIG_COCOA
+#if defined(__APPLE__)  (__MACH__)
 #include paths.h
 #include sys/param.h
 #include IOKit/IOKitLib.h
@@ -505,7 +505,7 @@ again:
 }
 if (size == 0)
 #endif
-#ifdef CONFIG_COCOA
+#if defined(__APPLE__)  defined(__MACH__)
 size = LONG_LONG_MAX;
 #else
 size = lseek(fd, 0LL, SEEK_END);
@@ -650,7 +650,7 @@ static BlockDriver bdrv_file = {
 /***/
 /* host device */
 
-#ifdef CONFIG_COCOA
+#if defined(__APPLE__)  defined(__MACH__)
 static kern_return_t FindEjectableCDMedia( io_iterator_t *mediaIterator );
 static kern_return_t GetBSDPath( io_iterator_t mediaIterator, char *bsdPath, 
CFIndex maxPathSize );
 
@@ -728,7 +728,7 @@ static int hdev_open(BlockDriverState *bs, const char 
*filename, int flags)
 {
 BDRVRawState *s = bs-opaque;
 
-#ifdef CONFIG_COCOA
+#if defined(__APPLE__)  defined(__MACH__)
 if (strstart(filename, /dev/cdrom, NULL)) {
 kern_return_t kernResult;
 io_iterator_t mediaIterator;
-- 
1.7.0.3