Re: [Qemu-devel] [PATCH v2 0/3] io-thread optimizations

[Jan Kiszka]

On 2011-04-13 22:16, Aurelien Jarno wrote:
> On Mon, Apr 11, 2011 at 10:27:41PM +0200, Jan Kiszka wrote:
>> These patches were posted before. They bring down the overhead of the
>> io-thread mode for TCG here, specifically when emulating SMP.
>>
>> The major change in this version, besides rebasing, is the exclusion of
>> KVM from the main loop polling optimization.
>>
>>
>>
>> Jan Kiszka (3):
>>   Do not drop global mutex for polled main loop runs
>>   Poll main loop after I/O events were received
>>   Do not kick vcpus in TCG mode
>>
>>  cpus.c   |2 +-
>>  sysemu.h |2 +-
>>  vl.c |   22 --
>>  3 files changed, 18 insertions(+), 8 deletions(-)
>>
> 
> Thanks for working on improving the io-thread with TCG. Your patches 
> make sense, but they don't seems to fix the slowdown observed when
> enabling the io-thread. Well maybe they were not supposed to. This is
> for example the results of netperf between guest and host using virtio:
> 
> no io-thread122 MB/s
> io-thread97 MB/s
> io-thread + patches  98 MB/s
> 

Can you capture ftraces of io-thread enabled & disabled runs? They just
need to cover a hand full of frames.

Thanks,
Jan



signature.asc
Description: OpenPGP digital signature

[Qemu-devel] is it just me or is ne2k broken in qemu?

[Michael Tokarev]

I performed several tests of various emulated NICs
booting with iPXE, and discovered that ne2k_pci (*)
emulated device does not quite work, for quite some
time already, at least with linux guests.

The NIC works for a while, but after a few packets,
or a few 1000s of packets, it stalls.  In tcpdump
on the host I see many ARP requests coming from the
guest and each has corresponding ARP reply, but
nothing is actually reaching the guest.

This behavour is consistent since qemu-kvm 0.12,
and is demonstrated by guest kernel 2.6.32 and
2.6.38, either 32 or 64bit.

Anyone seen something similar?

Thanks!

/mjt

(*) can we make ne2k-pci to ebe an alias for ne2k_pci,
to be consistent with virtio-net-pci?

Re: [Qemu-devel] Question about total_sectors in block/vpc.c

[Kevin Wolf]

Am 13.04.2011 22:59, schrieb Lyu Mitnick:
> Hello Stefan,
> 
> I have a question about get_option_parameter(). I am wondering whether 
> get_option_parameter  is suitable to use instead of doing the search by
> myself 
> in the case like following:
> 
> /* Read out options */
> while (options && options->name) {
> if (!strcmp(options->name, BLOCK_OPT_SIZE)) {
> // do something
> } else if (!strcmp(options->name, BLOCK_OPT_CLUSTER_SIZE)) {
>// do something
> }
> options++;
> }

Yes, I think it is, though you need to check whether the option has been
set in order to allow use default values.

Kevin

Re: [Qemu-devel] [Bug 760060] [NEW] Open Solaris 2009 Assertion `size' failed

[Stefan Hajnoczi]

On Wed, Apr 13, 2011 at 6:58 PM, Nigel Horne <760...@bugs.launchpad.net> wrote:
> qemu-system-sparc: /home/njh/src/qemu/exec.c:2614:
> cpu_register_physical_memory_offset: Assertion `size' failed.

I you ./configure with --disable-strip and run under GDB using "gdb
--args " then you can get a backtrace.  Just enter
the GDB "r" command to run QEMU and then the "bt" command to get a
backtrace once the assertion has triggered.

The backtrace will show which device is registering a zero-size memory
region.  It will be easy to fix this once we have a backtrace.

Stefan

Re: [Qemu-devel] [PATCH v2 11/19] softfloat: rename float*_eq() into float*_eq_quiet()

[Edgar E. Iglesias]

On Thu, Apr 14, 2011 at 1:11 AM, Aurelien Jarno wrote:

> float*_eq functions have a different semantics than other comparison
> functions. Fix that by first renaming float*_quiet() into
> float*_eq_quiet().
>
> Note that it is purely mechanical, and the behaviour should be unchanged.
> That said it clearly highlight problems due to this different semantics,
> they are fixed later in this patch series.
>
> Cc: Edgar E. Iglesias 
> Cc: Alexander Graf 
> Reviewed-by: Peter Maydell 
> Signed-off-by: Aurelien Jarno 
>

Looks good to me
Acked-by: Edgar E. Iglesias 



> ---
>  fpu/softfloat-native.h|6 +++---
>  fpu/softfloat.c   |8 
>  fpu/softfloat.h   |8 
>  linux-user/arm/nwfpe/fpa11_cprt.c |2 +-
>  target-alpha/op_helper.c  |4 ++--
>  target-i386/ops_sse.h |8 
>  target-microblaze/op_helper.c |4 ++--
>  target-mips/op_helper.c   |   32 
>  target-ppc/op_helper.c|4 ++--
>  9 files changed, 38 insertions(+), 38 deletions(-)
>
> diff --git a/fpu/softfloat-native.h b/fpu/softfloat-native.h
> index 406e180..0c7f48b 100644
> --- a/fpu/softfloat-native.h
> +++ b/fpu/softfloat-native.h
> @@ -210,7 +210,7 @@ INLINE float32 float32_div( float32 a, float32 b
> STATUS_PARAM)
>  }
>  float32 float32_rem( float32, float32  STATUS_PARAM);
>  float32 float32_sqrt( float32  STATUS_PARAM);
> -INLINE int float32_eq( float32 a, float32 b STATUS_PARAM)
> +INLINE int float32_eq_quiet( float32 a, float32 b STATUS_PARAM)
>  {
> return a == b;
>  }
> @@ -321,7 +321,7 @@ INLINE float64 float64_div( float64 a, float64 b
> STATUS_PARAM)
>  }
>  float64 float64_rem( float64, float64 STATUS_PARAM );
>  float64 float64_sqrt( float64 STATUS_PARAM );
> -INLINE int float64_eq( float64 a, float64 b STATUS_PARAM)
> +INLINE int float64_eq_quiet( float64 a, float64 b STATUS_PARAM)
>  {
> return a == b;
>  }
> @@ -428,7 +428,7 @@ INLINE floatx80 floatx80_div( floatx80 a, floatx80 b
> STATUS_PARAM)
>  }
>  floatx80 floatx80_rem( floatx80, floatx80 STATUS_PARAM );
>  floatx80 floatx80_sqrt( floatx80 STATUS_PARAM );
> -INLINE int floatx80_eq( floatx80 a, floatx80 b STATUS_PARAM)
> +INLINE int floatx80_eq_quiet( floatx80 a, floatx80 b STATUS_PARAM)
>  {
> return a == b;
>  }
> diff --git a/fpu/softfloat.c b/fpu/softfloat.c
> index 11f6584..492ef36 100644
> --- a/fpu/softfloat.c
> +++ b/fpu/softfloat.c
> @@ -2318,7 +2318,7 @@ float32 float32_log2( float32 a STATUS_PARAM )
>  | according to the IEC/IEEE Standard for Binary Floating-Point Arithmetic.
>
>  
> **/
>
> -int float32_eq( float32 a, float32 b STATUS_PARAM )
> +int float32_eq_quiet( float32 a, float32 b STATUS_PARAM )
>  {
> a = float32_squash_input_denormal(a STATUS_VAR);
> b = float32_squash_input_denormal(b STATUS_VAR);
> @@ -3582,7 +3582,7 @@ float64 float64_log2( float64 a STATUS_PARAM )
>  | according to the IEC/IEEE Standard for Binary Floating-Point Arithmetic.
>
>  
> **/
>
> -int float64_eq( float64 a, float64 b STATUS_PARAM )
> +int float64_eq_quiet( float64 a, float64 b STATUS_PARAM )
>  {
> uint64_t av, bv;
> a = float64_squash_input_denormal(a STATUS_VAR);
> @@ -4592,7 +4592,7 @@ floatx80 floatx80_sqrt( floatx80 a STATUS_PARAM )
>  | Arithmetic.
>
>  
> **/
>
> -int floatx80_eq( floatx80 a, floatx80 b STATUS_PARAM )
> +int floatx80_eq_quiet( floatx80 a, floatx80 b STATUS_PARAM )
>  {
>
> if ((( extractFloatx80Exp( a ) == 0x7FFF )
> @@ -5754,7 +5754,7 @@ float128 float128_sqrt( float128 a STATUS_PARAM )
>  | according to the IEC/IEEE Standard for Binary Floating-Point Arithmetic.
>
>  
> **/
>
> -int float128_eq( float128 a, float128 b STATUS_PARAM )
> +int float128_eq_quiet( float128 a, float128 b STATUS_PARAM )
>  {
>
> if ((( extractFloat128Exp( a ) == 0x7FFF )
> diff --git a/fpu/softfloat.h b/fpu/softfloat.h
> index 55c0c1c..738a50c 100644
> --- a/fpu/softfloat.h
> +++ b/fpu/softfloat.h
> @@ -320,7 +320,7 @@ float32 float32_rem( float32, float32 STATUS_PARAM );
>  float32 float32_sqrt( float32 STATUS_PARAM );
>  float32 float32_exp2( float32 STATUS_PARAM );
>  float32 float32_log2( float32 STATUS_PARAM );
> -int float32_eq( float32, float32 STATUS_PARAM );
> +int float32_eq_quiet( float32, float32 STATUS_PARAM );
>  int float32_le( float32, float32 STATUS_PARAM );
>  int float32_lt( float32, float32 STATUS_PARAM );
>  int float32_unordered( float32, float32 STATUS_PARAM );
> @@ -436,7 +436,7 @@ float64 float64_div( float64, float64 STATUS_PARAM );
>  float64 float64_rem( float64, float64 STATUS_PARAM );
>  float64 float64_sqrt( float64 STATUS_PARAM );
> 

Re: [Qemu-devel] [PATCH] qemu-img: allow rebase to a NULL backing file when unsafe

[Kevin Wolf]

Am 13.04.2011 16:51, schrieb Stefan Hajnoczi:
> From: Anthony Liguori 
> 
> QEMU can drop a backing file so that an image file no longer depends on
> the backing file, but this feature has not been exposed in qemu-img.
> This is useful in an image streaming usecase or when an image file has
> been fully allocated and no reads can hit the backing file anymore.
> 
> Since the dropping the backing file can make the image unusable, only
> allow this when the unsafe flag has been set.

I think it would also make sense to allow it in safe mode, it would have
the same effect as rebasing onto an empty new backing file. Might take
more than a one-liner, though.

In case you need a workaround for older qemu-img versions, -b "" works,
too (at least for qcow2).

> Signed-off-by: Anthony Liguori 
> Signed-off-by: Stefan Hajnoczi 
> ---
>  qemu-img.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/qemu-img.c b/qemu-img.c
> index d9c2c12..ed5ba91 100644
> --- a/qemu-img.c
> +++ b/qemu-img.c
> @@ -1240,7 +1240,7 @@ static int img_rebase(int argc, char **argv)
>  }
>  }
>  
> -if ((optind >= argc) || !out_baseimg) {
> +if ((optind >= argc) || (!unsafe && !out_baseimg)) {
>  help();
>  }
>  filename = argv[optind++];

Thanks, applied to the block branch.

Kevin

[Qemu-devel] [BUG] Re: [2/6] loadvm: improve tests before bdrv_snapshot_goto()

[Philipp Hahn]

Hello,

Am Dienstag 03 August 2010 06:44:26 schrieb Kevin Wolf:
> From: Miguel Di Ciurcio Filho 
>
> This patch improves the resilience of the load_vmstate() function, doing
> further and better ordered tests.

This patch broke restoring not-running VMs using libvirt-0.8.7 with qemu-0.14: 
When the domain is not running while taking a snpshot, the sn.vm_state_size 
== 0:

2021} else if (sn.vm_state_size == 0) {
(gdb) print sn
$6 = {id_str = "1", '\0' , name = "pre-update-flash", '\0' 
, vm_state_size = 0, date_sec = 1302698007, date_nsec = 
711909000, 
  vm_clock_nsec = 0}

> The [old] process:
...
> - run bdrv_snapshot_goto() on devices
> - if fails, give an warning and goes to the next (not good!)
> - if fails on the VM state device, return zero (not good!)
> - check if the requested snapshot exists on the device that saves the VM
> state and the state is not zero
> - if fails return -error

Previously the qcow2 image was still reverted to the old state, so on the next 
start of the domain the qcow2 image would be in the state of the snapshot

> New behavior:
...
> - check if the requested snapshot exists on the device that saves the VM
> state and the state is not zero
> - if fails return -error
...
> - run snapshot_goto() on devices

Now the qcow2 image is not reverted and when the domain is started, it is NOT 
in the state of the snapshot.

I can't decide if this regression is an Qemu bug or libvirt should be adapted 
to this new behavior.

I found the Bug also reported with Ubuntu and created a Bug in our own German 
bugtracker:



Sincerely
Philipp Hahn
-- 
Philipp Hahn   Open Source Software Engineer  h...@univention.de
Univention GmbHLinux for Your Businessfon: +49 421 22 232- 0
Mary-Somerville-Str.1  D-28359 Bremen fax: +49 421 22 232-99
   http://www.univention.de/


signature.asc
Description: This is a digitally signed message part.

Re: [Qemu-devel] [PATCH 08/19] target-alpha: use new float64_unordered() function

[Peter Maydell]

On 13 April 2011 16:38, Richard Henderson  wrote:
> (It looks like some of the Alpha code can be cleaned up a bit.
> I don't recall flush_inputs_to_zero option being there before,
> and we do that by hand in helper_ieee_input*.)

While we're on the subject of Alpha and flush-to-zero modes,
do you know what exception bits should get set when Alpha
flushes a denormal output (not input) to zero?

At the moment softfloat doesn't set any flags when it does
this, which is definitely wrong for ARM. I had a look at
the manuals for the other archs which might set flush_to_zero:

 SH: should set underflow flag
 ARM: should set underflow flag
 PPC: should set underflow (I think)
 MIPS: docs didn't say

I think Alpha should set Inexact and not Underflow, but
I'm not sure -- can you confirm/deny?

(Obviously I would prefer it if every architecture just
needed to set underflow, but somehow I don't think it
will work out that cleanly :-))

thanks
-- PMM

Re: [Qemu-devel] [Qemu-trivial] [PATCH] Fix some typos in comments and documentation

[Stefan Hajnoczi]

On Wed, Apr 13, 2011 at 10:45:22PM +0200, Stefan Weil wrote:
> helpfull -> helpful
> usefull -> useful
> cotrol -> control
> 
> and a grammar fix.
> 
> Signed-off-by: Stefan Weil 
> ---
>  qemu-options.hx |4 ++--
>  savevm.c|2 +-
>  target-arm/helper.c |2 +-
>  3 files changed, 4 insertions(+), 4 deletions(-)

Merged into the trivial-patches tree.  I will send a pull request to the
qemu.git maintainers:
http://repo.or.cz/w/qemu/stefanha.git/shortlog/refs/heads/trivial-patches

For more information, see
http://wiki.qemu.org/Contribute/TrivialPatches.

Stefan

Re: [Qemu-devel] [BUG] Re: [2/6] loadvm: improve tests before bdrv_snapshot_goto()

[Kevin Wolf]

Am 14.04.2011 11:10, schrieb Philipp Hahn:
> Hello,
> 
> Am Dienstag 03 August 2010 06:44:26 schrieb Kevin Wolf:
>> From: Miguel Di Ciurcio Filho 
>>
>> This patch improves the resilience of the load_vmstate() function, doing
>> further and better ordered tests.
> 
> This patch broke restoring not-running VMs using libvirt-0.8.7 with 
> qemu-0.14: 
> When the domain is not running while taking a snpshot, the sn.vm_state_size 
> == 0:
> 
> [...]
> 
> Previously the qcow2 image was still reverted to the old state, so on the 
> next 
> start of the domain the qcow2 image would be in the state of the snapshot
> 
> [...]
> 
> Now the qcow2 image is not reverted and when the domain is started, it is NOT 
> in the state of the snapshot.
> 
> I can't decide if this regression is an Qemu bug or libvirt should be adapted 
> to this new behavior.

Ouch. I wouldn't have expected that libvirt relies on this qemu bug.
When libvirt doesn't use the VM state but boots a fresh VM, it should
call qemu-img snapshot -a for the disks rather than using the loadvm
monitor command.

Kevin

Re: [Qemu-devel] [PATCH 2/2 V7] qemu, qmp: add inject-nmi qmp command

[Daniel P. Berrange]

On Wed, Apr 13, 2011 at 10:56:21PM +0300, Blue Swirl wrote:
> On Wed, Apr 13, 2011 at 4:08 PM, Luiz Capitulino  
> wrote:
> > On Tue, 12 Apr 2011 21:31:18 +0300
> > Blue Swirl  wrote:
> >
> >> On Tue, Apr 12, 2011 at 10:52 AM, Avi Kivity  wrote:
> >> > On 04/11/2011 08:15 PM, Blue Swirl wrote:
> >> >>
> >> >> On Mon, Apr 11, 2011 at 10:01 AM, Markus Armbruster
> >> >>  wrote:
> >> >> >  Avi Kivity  writes:
> >> >> >
> >> >> >>  On 04/08/2011 12:41 AM, Anthony Liguori wrote:
> >> >> >>>
> >> >> >>>  And it's a good thing to have, but exposing this as the only API to
> >> >> >>>  do something as simple as generating a guest crash dump is not the
> >> >> >>>  friendliest thing in the world to do to users.
> >> >> >>
> >> >> >>  nmi is a fine name for something that corresponds to a real-life nmi
> >> >> >>  button (often labeled "NMI").
> >> >> >
> >> >> >  Agree.
> >> >>
> >> >> We could also introduce an alias mechanism for user friendly names, so
> >> >> nmi could be used in addition of full path. Aliases could be useful
> >> >> for device paths as well.
> >> >
> >> > Yes.  Perhaps limited to the human monitor.
> >>
> >> I'd limit all debugging commands (including NMI) to the human monitor.
> >
> > Why?
> 
> Do they have any real use in production environment? Also, we should
> have the freedom to change the debugging facilities (for example, to
> improve some internal implementation) as we want without regard to
> compatibility to previous versions.

We have users of libvirt requesting that we add an API for triggering
a NMI. They want this for support in a production environment, to be
able to initiate Windows crash dumps.  We really don't want to have to
use HMP passthrough for this, instead of a proper QMP command.

More generally I don't want to see stuff in HMP, that isn't in the QMP.
We already have far too much that we have to do via HMP passthrough in
libvirt due to lack of QMP commands, to the extent that we might as
well have just ignored QMP and continued with HMP for everything.

If we want the flexibility to change the debugging commands between
releases then we should come up with a plan to do this within the
scope of QMP, not restrict them to HMP only.

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

[Qemu-devel] why is NPTL support not enabled for x86, x86_64?

[Yale Zhang]

Hi. I want to run wine inside qemu userspace (host = arm, target = x86), but
it doesn't function due to lack of NPTL (native posix thread library)
support. I tried turning it on by editing configure and trying it on a
simple pthread program, but it crashes.
Why is NPTL not supported on x86 or x86_64?


Has anyone had any success running wine inside qemu userspace?

Re: [Qemu-devel] [PATCH] Clean up after "make pdf"

[Brad Hards]

On Wednesday 13 April 2011 16:42:16 Brad Hards wrote:
> ---
>  .gitignore |3 +++
>  Makefile   |5 -
>  2 files changed, 7 insertions(+), 1 deletions(-)
Signed-off-by: Brad Hards 

Sorry about that.

Brad

[Qemu-devel] [Bug 757654] Re: UHCI fails to signal stall response

[jvesely]

No problem, it's not like it breaks something. This fix just makes
driver development easier.

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

Title:
  UHCI fails to signal stall response

Status in QEMU:
  New

Bug description:
  When TD execution results in STALL error (STALL handshake, no stall as
  a result of err count reaching 0), there is no way to know about it
  except for checking that TD. IMO it is an error condition and it
  should be reflected in the status register (and issue an interrupt if
  enabled).

  Ways to replicate:
  Send a query that is answered by stall (like set_idle request to a mouse)

  Expected behavior:
  UHCI hc sets status bit 1 (usb error interrupt) and issues an interrupt

  current behavior:
  Neither status bit is set nor interrupt triggered

  Version 0.14
  attached patch for current master (quick fix, it might be I got something 
wrong)

Re: [Qemu-devel] [PATCH 0/4] Minor USB fixes

[Stefan Hajnoczi]

On Wed, Apr 13, 2011 at 07:45:30PM +1000, Brad Hards wrote:
> 1 fixes spellos in the mass-storage driver
> 2-4 fix issues in Linux usb pass-through code. 

Patches 1-3 merged into the trivial patches tree.  Patch 4 should be a
separate patch and needs Ack from Hans.

I will send a pull request to the qemu.git maintainers:
http://repo.or.cz/w/qemu/stefanha.git/shortlog/refs/heads/trivial-patches

For more information, see
http://wiki.qemu.org/Contribute/TrivialPatches.

Stefan

Re: [Qemu-devel] [PATCH] Clean up after "make pdf"

[Stefan Hajnoczi]

On Wed, Apr 13, 2011 at 04:42:16PM +1000, Brad Hards wrote:
> ---
>  .gitignore |3 +++
>  Makefile   |5 -
>  2 files changed, 7 insertions(+), 1 deletions(-)

Merged into the trivial-patches tree.  I will send a pull request to the
qemu.git maintainers:
http://repo.or.cz/w/qemu/stefanha.git/shortlog/refs/heads/trivial-patches

Stefan

Re: [Qemu-devel] [Bug 757654] Re: UHCI fails to signal stall response

[Stefan Hajnoczi]

On Thu, Apr 14, 2011 at 11:35 AM, jvesely <757...@bugs.launchpad.net> wrote:
> No problem, it's not like it breaks something. This fix just makes
> driver development easier.

Please send your patch to the mailing list:

http://wiki.qemu.org/Contribute/SubmitAPatch

It may seem petty to ask this since you've already attached it to the
bug, but for QEMU development to scale and keep at a rapid pace,
everyone needs to follow these steps on submitting patches.  Thanks
for your effort!

Stefan

[Qemu-devel] Property Intensive Seminar by Milan Doshi (April)

[RealEstateMalaysian.com]

	Click HERE if you unable to view the message

	



	

			

If you wish to cancel your subscription, simply click once on the link below.Click here to unsubscribe

Re: [Qemu-devel] is it just me or is ne2k broken in qemu?

[Mulyadi Santosa]

On Thu, Apr 14, 2011 at 09:31, Michael Tokarev  wrote:
> I performed several tests of various emulated NICs
> booting with iPXE, and discovered that ne2k_pci (*)
> emulated device does not quite work, for quite some
> time already, at least with linux guests.
>
> The NIC works for a while, but after a few packets,
> or a few 1000s of packets, it stalls.  In tcpdump
> on the host I see many ARP requests coming from the
> guest and each has corresponding ARP reply, but
> nothing is actually reaching the guest.

IIRC, several people complained roughly the same thing about
ne2k...and it's about timer implementation inside the code.

For workaround, if possible, use e1000...works for me so far

-- 
regards,

Mulyadi Santosa
Freelance Linux trainer and consultant

blog: the-hydra.blogspot.com
training: mulyaditraining.blogspot.com

[Qemu-devel] Unsubscription Confirmation

[RealEstateMalaysian.com]

Thank you for subscribing. You have now unsubscribed and no more messages will 
be sent.

[Qemu-devel] [PATCH] tests/test-mmap.c: Check mmap() return value before using it

[Peter Maydell]

Correct the position of a "stop if MAP_FAILED" check in the mmap()
tests, so that if mmap() does fail we print a failure message
rather than segfaulting inside memcpy().

Signed-off-by: Peter Maydell 
---
 tests/test-mmap.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/tests/test-mmap.c b/tests/test-mmap.c
index fcb365f..c578e25 100644
--- a/tests/test-mmap.c
+++ b/tests/test-mmap.c
@@ -164,6 +164,7 @@ void check_aligned_anonymous_unfixed_colliding_mmaps(void)
nlen = pagesize * 8;
p3 = mmap(NULL, nlen, PROT_READ, 
  MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
+   fail_unless (p3 != MAP_FAILED);
 
/* Check if the mmaped areas collide.  */
if (p3 < p2 
@@ -174,7 +175,6 @@ void check_aligned_anonymous_unfixed_colliding_mmaps(void)
 
/* Make sure we get pages aligned with the pagesize. The
   target expects this.  */
-   fail_unless (p3 != MAP_FAILED);
p = (uintptr_t) p3;
fail_unless ((p & pagemask) == 0);
munmap (p2, pagesize);
-- 
1.7.1

Re: [Qemu-devel] [PATCH v2 0/3] io-thread optimizations

[Avi Kivity]

On 04/14/2011 10:14 AM, Jan Kiszka wrote:

On 2011-04-13 22:16, Aurelien Jarno wrote:
>  On Mon, Apr 11, 2011 at 10:27:41PM +0200, Jan Kiszka wrote:
>>  These patches were posted before. They bring down the overhead of the
>>  io-thread mode for TCG here, specifically when emulating SMP.
>>
>>  The major change in this version, besides rebasing, is the exclusion of
>>  KVM from the main loop polling optimization.
>>
>>
>>
>>  Jan Kiszka (3):
>>Do not drop global mutex for polled main loop runs
>>Poll main loop after I/O events were received
>>Do not kick vcpus in TCG mode
>>
>>   cpus.c   |2 +-
>>   sysemu.h |2 +-
>>   vl.c |   22 --
>>   3 files changed, 18 insertions(+), 8 deletions(-)
>>
>
>  Thanks for working on improving the io-thread with TCG. Your patches
>  make sense, but they don't seems to fix the slowdown observed when
>  enabling the io-thread. Well maybe they were not supposed to. This is
>  for example the results of netperf between guest and host using virtio:
>
>  no io-thread122 MB/s
>  io-thread97 MB/s
>  io-thread + patches  98 MB/s
>

Can you capture ftraces of io-thread enabled&  disabled runs? They just
need to cover a hand full of frames.



Also interesting would be the context switch rates on the host.

If they're large, perhaps using user-space threading instead of native 
threads would help.


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

Re: [Qemu-devel] [PATCH] Slirp reverse UDP firewall

[Avi Kivity]

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

On 2011-04-12 18:19, Daisuke Nojiri wrote:
>  This patch adds: -drop-udp, -allow-udp ADDR:PORT, -drop-log FILE
>
>e.g.) $ qemu -net user -drop-log qemu.drop -drop-udp -allow-udp
>  10.0.2.3:53

No more stand-alone slirp arguments please. That syntax breaks when
instantiating>1 back-ends.

>
>  -drop-udp enables usermode firewall for out-going UDP packats from a guest.
>  All UDP packets except ones allowed by -allow-udp will be dropped. Dropped
>  packets are logged in the file specified by FILE. PORT can be a single
>  number
>  (e.g. 53) or a range (e.g. [80-81]). If ADDR is ommitted, all addresses
>  match
>  the rule.

Will we see a TCP firewall as well? Can we prepare for a more generic
infrastructure, or what makes UDP special?


If some generic firewall like BPF is available as a user library, 
perhaps we can integrate one instead of writing a new one from scratch.


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

Re: [Qemu-devel] [PATCH v2 0/3] io-thread optimizations

[Anthony Liguori]

On 04/14/2011 08:45 AM, Avi Kivity wrote:

On 04/14/2011 10:14 AM, Jan Kiszka wrote:

On 2011-04-13 22:16, Aurelien Jarno wrote:
>  On Mon, Apr 11, 2011 at 10:27:41PM +0200, Jan Kiszka wrote:
>>  These patches were posted before. They bring down the overhead of 
the

>>  io-thread mode for TCG here, specifically when emulating SMP.
>>
>>  The major change in this version, besides rebasing, is the 
exclusion of

>>  KVM from the main loop polling optimization.
>>
>>
>>
>>  Jan Kiszka (3):
>>Do not drop global mutex for polled main loop runs
>>Poll main loop after I/O events were received
>>Do not kick vcpus in TCG mode
>>
>>   cpus.c   |2 +-
>>   sysemu.h |2 +-
>>   vl.c |   22 --
>>   3 files changed, 18 insertions(+), 8 deletions(-)
>>
>
>  Thanks for working on improving the io-thread with TCG. Your patches
>  make sense, but they don't seems to fix the slowdown observed when
>  enabling the io-thread. Well maybe they were not supposed to. This is
>  for example the results of netperf between guest and host using 
virtio:

>
>  no io-thread122 MB/s
>  io-thread97 MB/s
>  io-thread + patches  98 MB/s
>

Can you capture ftraces of io-thread enabled&  disabled runs? They just
need to cover a hand full of frames.



Also interesting would be the context switch rates on the host.

If they're large, perhaps using user-space threading instead of native 
threads would help.


I still suspect mitigation as the culprit here.  Select is going to get 
to run more often which means more interrupt generation.


I bet if you count the number of packets per interrupt/notify you'll 
find that less batching is occurring.


Regards,

Anthony Liguori

Re: [Qemu-devel] [PATCH v2 0/3] io-thread optimizations

[Avi Kivity]

On 04/14/2011 04:59 PM, Anthony Liguori wrote:

On 04/14/2011 08:45 AM, Avi Kivity wrote:

On 04/14/2011 10:14 AM, Jan Kiszka wrote:

On 2011-04-13 22:16, Aurelien Jarno wrote:
>  On Mon, Apr 11, 2011 at 10:27:41PM +0200, Jan Kiszka wrote:
>>  These patches were posted before. They bring down the overhead 
of the

>>  io-thread mode for TCG here, specifically when emulating SMP.
>>
>>  The major change in this version, besides rebasing, is the 
exclusion of

>>  KVM from the main loop polling optimization.
>>
>>
>>
>>  Jan Kiszka (3):
>>Do not drop global mutex for polled main loop runs
>>Poll main loop after I/O events were received
>>Do not kick vcpus in TCG mode
>>
>>   cpus.c   |2 +-
>>   sysemu.h |2 +-
>>   vl.c |   22 --
>>   3 files changed, 18 insertions(+), 8 deletions(-)
>>
>
>  Thanks for working on improving the io-thread with TCG. Your patches
>  make sense, but they don't seems to fix the slowdown observed when
>  enabling the io-thread. Well maybe they were not supposed to. 
This is
>  for example the results of netperf between guest and host using 
virtio:

>
>  no io-thread122 MB/s
>  io-thread97 MB/s
>  io-thread + patches  98 MB/s
>

Can you capture ftraces of io-thread enabled&  disabled runs? They just
need to cover a hand full of frames.



Also interesting would be the context switch rates on the host.

If they're large, perhaps using user-space threading instead of 
native threads would help.


I still suspect mitigation as the culprit here.  Select is going to 
get to run more often which means more interrupt generation.


I bet if you count the number of packets per interrupt/notify you'll 
find that less batching is occurring.




Can you clarify?  Which mitigation? virtio-net interrupt mitigation?

virtio-net interrupt mitigation is time-based, no? so why should 
threading affect it?  and why would select() run more often? since we 
make all fds generate a signal, we ought to run a similar number same 
number of select()s.


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

Re: [Qemu-devel] [PATCH] Slirp reverse UDP firewall

[Avi Kivity]

On 04/14/2011 04:48 PM, Avi Kivity wrote:

Will we see a TCP firewall as well? Can we prepare for a more generic
infrastructure, or what makes UDP special?



If some generic firewall like BPF is available as a user library, 
perhaps we can integrate one instead of writing a new one from scratch.




Heck, you could even write a tcg backend for bpf instructions and run 
the jit the firewall filter set.


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

[Qemu-devel] Europe Recouvrement se met aux couleurs de l'Allemagne

[EUROPE RECOUVREMENT]

Bonjour, 

Vous avez des impayés à encaisser en France, en Europe ou dans le reste du 
Monde ? 

Confiez vos impayés à Europe Recouvrement, spécialisé en recouvrement de 
créances à l'international depuis 1970. 

Les interventions amiables et judiciaires sont basées sur un principe de 
résultats obtenus pour votre compte : PAS DE SUCCES, PAS D'HONORAIRES. 

Europe Recouvrement c'est : 

- Des interventions personnalisées en 7 langues, 
- Des services certifiés à la norme ISO 9001, 
- Des équipes de juristes expérimentés, 
- Des résultats garantis dans les 30 jours. 

En ce moment, un chèque de réduction de 100 ? vous est offert à valoir sur les 
honoraires d'encaissement de votre deuxième impayé remis. 


Je demeure à votre entière disposition pour tous renseignements 
complémentaires. 

Très cordialement, 

EUROPE RECOUVREMENT 




Pour vous désabonner, collez ce lien dans votre navigateur : 
http://www.gce-mailer-14.com/unsuscribe.asp?lang=francais&id_formulaire=4&email=qemu-devel@nongnu.org&id_message=981
 

Re: [Qemu-devel] [PATCH 08/19] target-alpha: use new float64_unordered() function

[Richard Henderson]

On 04/14/2011 02:14 AM, Peter Maydell wrote:
> While we're on the subject of Alpha and flush-to-zero modes,
> do you know what exception bits should get set when Alpha
> flushes a denormal output (not input) to zero?
...
> I think Alpha should set Inexact and not Underflow, but
> I'm not sure -- can you confirm/deny?

Deny.

Page B-8, Add Sub Output Exceptions,

  Exponent underflow and disabled:
Supply +0, no exception delivered to user.

  Exponent underflow and enabled:
Supply +-MIN denorm, Underflow delivered to user.

Footnote 3, Overflow and Underflow have priority over Inexact.


r~

[Qemu-devel] Problem in setting breakpoints at kernel code using "qemu and gdb"

[Amirali Shambayati]

Dear all,
I want to use combination of qemu and gdb to debug my modified linux
kernel code. First I tried this
link:http://issaris.blogspot.com/2007/12/download-linux-kernel-sourcecode-from.html
to configure eclipse CDT and qemu to achieve my goal.

According to the tutorial, I tried following command to run qemu:
sudo qemu -s -S -hda linux-0.2.img -append "root=/dev/sda" -kernel
/mnt/build/linux-2.6/arch/x86/boot/bzImage

As I used my modified kernel code, I encountered with kernel oops; So
I tried to find the related code line which causes problem, using
breakpoints.
Now my problem is, when I set breakpoints before start debugging in
eclipse, it seems that it ignores breakpoints and kernel goes to oops
condition again.

Also I tried combination of gdb and qemu using following commands:
#gdb
(gdb) symbol-file vmlinux.o
(gdb) target remote localhost:1234
(gdb) break scsi_lib.c 1420
(gdb) c

I tried above commands to check if stops at breakpoint or not. I put a
printk after breakpoint line. It printed it and it means that it has
ignored breakpoint.
Would you guide me what is wrong with what I have done?

It's related to my thesis project, and I need to pass this step as
soon as possible.

Thanks in advance,
--
Amirali Shambayati
Bachelor Student
Computer Engineering Department
Sharif University of Technology
Tehran, Iran

Re: [Qemu-devel] [PATCH] tests/test-mmap.c: Check mmap() return value before using it

[Edgar E. Iglesias]

On Thu, Apr 14, 2011 at 02:11:56PM +0100, Peter Maydell wrote:
> Correct the position of a "stop if MAP_FAILED" check in the mmap()
> tests, so that if mmap() does fail we print a failure message
> rather than segfaulting inside memcpy().
> 
> Signed-off-by: Peter Maydell 

I've applied this, thanks.


> ---
>  tests/test-mmap.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/tests/test-mmap.c b/tests/test-mmap.c
> index fcb365f..c578e25 100644
> --- a/tests/test-mmap.c
> +++ b/tests/test-mmap.c
> @@ -164,6 +164,7 @@ void check_aligned_anonymous_unfixed_colliding_mmaps(void)
>   nlen = pagesize * 8;
>   p3 = mmap(NULL, nlen, PROT_READ, 
> MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
> + fail_unless (p3 != MAP_FAILED);
>  
>   /* Check if the mmaped areas collide.  */
>   if (p3 < p2 
> @@ -174,7 +175,6 @@ void check_aligned_anonymous_unfixed_colliding_mmaps(void)
>  
>   /* Make sure we get pages aligned with the pagesize. The
>  target expects this.  */
> - fail_unless (p3 != MAP_FAILED);
>   p = (uintptr_t) p3;
>   fail_unless ((p & pagemask) == 0);
>   munmap (p2, pagesize);
> -- 
> 1.7.1
> 
> 

Re: [Qemu-devel] [PATCH 08/19] target-alpha: use new float64_unordered() function

[Peter Maydell]

On 14 April 2011 16:14, Richard Henderson  wrote:
> On 04/14/2011 02:14 AM, Peter Maydell wrote:
>> While we're on the subject of Alpha and flush-to-zero modes,
>> do you know what exception bits should get set when Alpha
>> flushes a denormal output (not input) to zero?
> ...
>> I think Alpha should set Inexact and not Underflow, but
>> I'm not sure -- can you confirm/deny?
>
> Deny.
>
> Page B-8, Add Sub Output Exceptions,
>
>  Exponent underflow and disabled:
>    Supply +0, no exception delivered to user.
>
>  Exponent underflow and enabled:
>    Supply +-MIN denorm, Underflow delivered to user.
>
>    Footnote 3, Overflow and Underflow have priority over Inexact.

Thanks. Does "no exception delivered to user" mean also
"and do not set FPCR bit UNF" ?

The reason I thought it might set Inexact is that I was looking
at page 4-79, which says:

"If both the UNFD (underflow disable) bit and the UNDZ (underflow
 to zero) bit are set in the FPCR, the implementation sets the
 result of an underflow operation to a true zero result. The
 zeroing of a denormal result by UNDZ must also be treated as an
 inexact result."

-- PMM

Re: [Qemu-devel] [PATCH 15/15] tcg: use ext op for deposit

[Alexander Graf]

On 04/10/2011 10:28 PM, Aurelien Jarno wrote:

On Sun, Apr 10, 2011 at 10:17:26PM +0200, Alexander Graf wrote:

On 10.04.2011, at 22:08, Aurelien Jarno wrote:


On Sun, Apr 10, 2011 at 09:25:33PM +0200, Alexander Graf wrote:

On 10.04.2011, at 21:23, Aurelien Jarno wrote:


On Tue, Apr 05, 2011 at 09:55:09AM +0200, Alexander Graf wrote:

On 05.04.2011, at 06:54, Aurelien Jarno wrote:


On Mon, Apr 04, 2011 at 04:32:24PM +0200, Alexander Graf wrote:

With the s390x target we use the deposit instruction to store 32bit values
into 64bit registers without clobbering the upper 32 bits.

This specific operation can be optimized slightly by using the ext operation
instead of an explicit and in the deposit instruction. This patch adds that
special case to the generic deposit implementation.

Signed-off-by: Alexander Graf
---
tcg/tcg-op.h |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)

Have you really measuring a difference here? This should already be
handled, at least on x86, by this code:

  if (TCG_TARGET_REG_BITS == 64) {
  if (val == 0xu) {
  tcg_out_ext32u(s, r0, r0);
  return;
  }
  if (val == (uint32_t)val) {
  /* AND with no high bits set can use a 32-bit operation.  */
  rexw = 0;
  }
  }

I've certainly looked at the -d op logs and seen that instead of creating a 
const tcg variable plus an AND there was now an extu opcode issued, yes. No 
idea why the case up there didn't trigger.


The question there is looking at -d out_asm. They should be the same at
the end as the code I pasted above is from tcg/i386/tcg-target.c.

Yes. I was trying to optimize for maximum op length. TCG defines a maximum 
number of tcg ops to be issued by each target instruction. Since s390 is very 
CISCy, there are instructions that translate into lots of microops, but are 
still faster than a C call (register save/restore mostly).

Without this patch, there are some places where we hit that number :).

Is it on 32-bit on or 64-bit? If we reach this number, it's probably
better to either implement this instruction with an helper, or maybe
increase the number of maximum ops. What is this instruction?

This was on x86_64. I hit limits with LMH and LM, but reduced them to fit into 
the picture with this optimization :). If you like, I can give you a statically 
linked binary that could exceed the limits.


Yeah for what I see it's the loop is unrolled there. Not sure it is the
best to do. Also if the limit is exceeded on 64-bit it is for sure
exceeded on 32-bit hosts.



Ok, I've optimized some code paths for 32bit hosts now and bumped up the 
limit on 32bit to 128 ops. I've also dropped the ext op patch - it's not 
necessary anymore. I've optimized the 64bit version well enough so we 
don't require it anymore :)



Alex

Re: [Qemu-devel] [PATCH 08/19] target-alpha: use new float64_unordered() function

[Richard Henderson]

On 04/14/2011 08:39 AM, Peter Maydell wrote:
>>  Exponent underflow and disabled:
>>Supply +0, no exception delivered to user.
>>
>>  Exponent underflow and enabled:
>>Supply +-MIN denorm, Underflow delivered to user.
>>
>>Footnote 3, Overflow and Underflow have priority over Inexact.
> 
> Thanks. Does "no exception delivered to user" mean also
> "and do not set FPCR bit UNF" ?

Yes.

> The reason I thought it might set Inexact is that I was looking
> at page 4-79, which says:
> 
> "If both the UNFD (underflow disable) bit and the UNDZ (underflow
>  to zero) bit are set in the FPCR, the implementation sets the
>  result of an underflow operation to a true zero result. The
>  zeroing of a denormal result by UNDZ must also be treated as an
>  inexact result."

Hum.  It looks like we can choose between these results then,
depending on the intersection of the FPCR disable bits, and
the per-instruction trapping mode bits (see section 4.7.7.2).

I *think* what would be best for Alpha is if, within softfloat,
both conditions are signaled, and then we can filter the result
that is actually needed via helper_fp_exc_raise?  It's hard to
say without actually doing the work...

Unfortunately, I suspect that the Correct result on real HW
also depends on the OS completion handler, and I know that at
least for Linux that code was written before UNDZ was added.
So I don't know if even real HW produces the correct result
when considering Underflow priority over Inexact.


r~

Re: [Qemu-devel] [PATCH v2 08/19] target-alpha: use new float64_unordered_quiet() function

[Richard Henderson]

On 04/13/2011 04:11 PM, Aurelien Jarno wrote:
> Use float64_unordered_quiet() in helper_cmptun() instead of doing the
> the comparison manually.
> 
> According to the "Alpha Compiler Writer's Guide", we should use the
> _quiet version here, as CMPTUN and CMPTEQ should generate InvalidOp
> for SNaNs but not for QNaNs.
> 
> Thanks to Peter Maydell  and Richard
> Henderson  for digging into the manuals.
> 
> Signed-off-by: Aurelien Jarno 

Acked-by: Richard Henderson  



r~

Re: [Qemu-devel] [PATCH 08/19] target-alpha: use new float64_unordered() function

[Peter Maydell]

On 14 April 2011 17:27, Richard Henderson  wrote:
> On 04/14/2011 08:39 AM, Peter Maydell wrote:
>>>  Exponent underflow and disabled:
>>>    Supply +0, no exception delivered to user.
>>>
>>>  Exponent underflow and enabled:
>>>    Supply +-MIN denorm, Underflow delivered to user.
>>>
>>>    Footnote 3, Overflow and Underflow have priority over Inexact.
>>
>> Thanks. Does "no exception delivered to user" mean also
>> "and do not set FPCR bit UNF" ?
>
> Yes.
>
>> The reason I thought it might set Inexact is that I was looking
>> at page 4-79, which says:
>>
>> "If both the UNFD (underflow disable) bit and the UNDZ (underflow
>>  to zero) bit are set in the FPCR, the implementation sets the
>>  result of an underflow operation to a true zero result. The
>>  zeroing of a denormal result by UNDZ must also be treated as an
>>  inexact result."
>
> Hum.  It looks like we can choose between these results then,
> depending on the intersection of the FPCR disable bits, and
> the per-instruction trapping mode bits (see section 4.7.7.2).
>
> I *think* what would be best for Alpha is if, within softfloat,
> both conditions are signaled, and then we can filter the result
> that is actually needed via helper_fp_exc_raise?  It's hard to
> say without actually doing the work...

Unfortunately doing that is bad for other architectures because
they tend to let the softfloat status flags act directly as
the cumulative exception flags, so if softfloat sets flags they
don't want you've suddenly imposed a burden of saving and
restoring flags or something similarly ugly.

It sounds like maybe what we need is to have a
 signed char float_ftz_flags
or similar in float_status which should be set to the
float_flags which should be passed to float_raise() when
we flush an output denormal to zero. Then we can set that to
float_flag_underflow for ARM, leave it at 0 for other
architectures [preserve existing semantics] and set it to
float_flag_underflow | float_flag_inexact for Alpha.

Or the other approach would be to do something like
how the 'denormal-input-went-to-zero' case is handled: have
an extra float_flag for float_flag_output_denormal, and let
targets either (a) special-case it or (b) merge it with
whichever of underflow or inexact they like when constructing
the guest-visible floating point status flags. I kind of like
that better, actually.

-- PMM

Re: [Qemu-devel] [PATCH 08/19] target-alpha: use new float64_unordered() function

[Richard Henderson]

On 04/14/2011 09:48 AM, Peter Maydell wrote:
> Or the other approach would be to do something like
> how the 'denormal-input-went-to-zero' case is handled: have
> an extra float_flag for float_flag_output_denormal, and let
> targets either (a) special-case it or (b) merge it with
> whichever of underflow or inexact they like when constructing
> the guest-visible floating point status flags. I kind of like
> that better, actually.

Either of your proposed solutions works for me.

Either allows significant freedom in the backend to decide on
how to implement the per-instruction selection.


r~

[Qemu-devel] [PATCH] sparc: Fix assertion caused by empty memory slot with 0 byte

[Stefan Weil]

If the memory size given on the command line is equal to the
maximum size of memory defined by the hardware, there is no
"empty slot" after physical memory.

The following command

qemu-system-sparc -m 256

raised an assertion:
exec.c:2614: cpu_register_physical_memory_offset: Assertion `size' failed

This can be fixed either at the caller side (don't call empty_slot_init)
or in empty_slot_init (do nothing) when size == 0. The second solution
was choosen here because it is more robust.

Signed-off-by: Stefan Weil 
---
 hw/empty_slot.c |   21 -
 1 files changed, 12 insertions(+), 9 deletions(-)

diff --git a/hw/empty_slot.c b/hw/empty_slot.c
index 664b8d9..da8adc4 100644
--- a/hw/empty_slot.c
+++ b/hw/empty_slot.c
@@ -53,18 +53,21 @@ static CPUWriteMemoryFunc * const empty_slot_write[3] = {
 
 void empty_slot_init(target_phys_addr_t addr, uint64_t slot_size)
 {
-DeviceState *dev;
-SysBusDevice *s;
-EmptySlot *e;
+if (slot_size > 0) {
+/* Only empty slots larger than 0 byte need handling. */
+DeviceState *dev;
+SysBusDevice *s;
+EmptySlot *e;
 
-dev = qdev_create(NULL, "empty_slot");
-s = sysbus_from_qdev(dev);
-e = FROM_SYSBUS(EmptySlot, s);
-e->size = slot_size;
+dev = qdev_create(NULL, "empty_slot");
+s = sysbus_from_qdev(dev);
+e = FROM_SYSBUS(EmptySlot, s);
+e->size = slot_size;
 
-qdev_init_nofail(dev);
+qdev_init_nofail(dev);
 
-sysbus_mmio_map(s, 0, addr);
+sysbus_mmio_map(s, 0, addr);
+}
 }
 
 static int empty_slot_init1(SysBusDevice *dev)
-- 
1.7.2.5

[Qemu-devel] [Bug 760060] Re: Open Solaris 2009 Assertion `size' failed

[Stefan Weil]

The bug was caused by memory size (256 MiB) == maximum memory size supported by 
emulated hardware,
so the gap between both values (the empty slot) was 0 byte large.

qemu-system-sparc -m 256 (and code with assertions enabled) is enough to
reproduce it.

The bug is fixed with patch http://patchwork.ozlabs.org/patch/91268/.


** 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/760060

Title:
  Open Solaris 2009 Assertion `size' failed

Status in QEMU:
  Fix Committed

Bug description:
  The latest git version of qemu (commit
  9df38c47d01eb1fd7eb9d60ac70a4170e638b4a2) fails to boot the
  OpenSolaris image from
  http://dlc.sun.com/osol/opensolaris/2009/06/osol-0906-ai-sparc.iso.

  qemu-img create opensolaris 3G
  qemu-system-sparc -hda opensolaris -cdrom osol-0906-ai-sparc.iso -boot d 
-redir tcp:2232::22 -k en-us -m 256

  gives:

  qemu-system-sparc: /home/njh/src/qemu/exec.c:2614:
  cpu_register_physical_memory_offset: Assertion `size' failed.

  Host: Linux/x86_64
  gcc4.5
  ./configure --enable-linux-aio --enable-io-thread --enable-kvm

[Qemu-devel] [Bug 704904] Re: No rule to make target ../libhw32/virtio.o

[Stefan Weil]

The bug has been fixed, therefore I closed it.

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

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

Title:
  No rule to make target ../libhw32/virtio.o

Status in QEMU:
  Fix Released

Bug description:
  Building qemu from current git using 32-bit MinGW (installer from
  2010-11-07) on Windows Vista (64-bit) fails with the following error:

  make[1]: *** No rule to make target `../libhw32/virtio.o', needed by 
`qemu.exe'.  Stop.
  make: *** [subdir-i386-softmmu] Error 2

  Here is my ./configure summary:

  ###
  Mateuszl@dog /g/src/qemu/_git/master
  $ ./configure
  warning: proceeding without pkg-config
  Install prefixc:/Program Files/Qemu
  BIOS directoryc:/Program Files/Qemu
  binary directory  c:/Program Files/Qemu
  config directory  c:/Program Files/Qemu
  Source path   /g/src/qemu/_git/master
  C compilergcc
  Host C compiler   gcc
  CFLAGS-O2 -g
  QEMU_CFLAGS   -m32 -D__USE_MINGW_ANSI_STDIO=1 -DWIN32_LEAN_AND_MEAN 
-DWINVER=0x501 -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 
-D_LARGEFILE_SOU
  RCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wendif-labels 
-Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing  
-fstack-protector-all -Wmissin
  g-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k 
-Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition 
-Wty
  pe-limits
  LDFLAGS   -Wl,--nxcompat -Wl,--no-seh -Wl,--dynamicbase 
-Wl,--warn-common -m32 -g
  make  make
  install   install
  host CPU  i386
  host big endian   no
  target list   i386-softmmu x86_64-softmmu arm-softmmu cris-softmmu 
m68k-softmmu microblaze-softmmu mips-softmmu mipsel-softmmu mips64-softmmu 
mips64el-softm
  mu ppc-softmmu ppcemb-softmmu ppc64-softmmu sh4-softmmu sh4eb-softmmu 
sparc-softmmu sparc64-softmmu
  tcg debug enabled no
  Mon debug enabled no
  gprof enabled no
  sparse enabledno
  strip binariesyes
  profiler  no
  static build  no
  -Werror enabled   no
  SDL support   yes
  curses supportno
  curl support  no
  check support no
  mingw32 support   yes
  Audio drivers winwave
  Extra audio cards ac97 es1370 sb16 hda
  Block whitelist
  Mixer emulation   no
  VNC TLS support   no
  VNC SASL support  no
  VNC JPEG support  no
  VNC PNG support   no
  VNC threadno
  xen support   no
  brlapi supportno
  bluez  supportno
  Documentation no
  NPTL support  no
  GUEST_BASEyes
  PIE user targets  no
  vde support   no
  IO thread no
  Linux AIO support no
  ATTR/XATTR support no
  Install blobs yes
  KVM support   no
  fdt support   no
  preadv supportno
  fdatasync no
  madvise   no
  posix_madvise no
  uuid support  no
  vhost-net support no
  Trace backend nop
  Trace output file trace-
  spice support no
  rbd support   no
  xfsctl supportno
  ###

  and here is full make output until the error:

  ###
  GEN   qemu-img-cmds.h
GEN   config-host.h
GEN   trace.h
GEN   qemu-options.def
CCqemu-img.o
  qemu-img.c: In function 'img_convert':
  qemu-img.c:826:27: warning: format '%I64d' expects type 'int', but argument 2 
has type 'int64_t'
CCqemu-tool.o
CCqemu-error.o
CCosdep.o
CCoslib-win32.o
GEN   trace.c
CCtrace.o
CCcutils.o
CCcache-utils.o
CCqemu-malloc.o
CCqemu-option.o
CCmodule.o
CCnbd.o
CCblock.o
  block.c: In function 'bdrv_stats_iter':
  block.c:1694:25: warning: format '%I64d' expects type 'int', but argument 3 
has type 'int64_t'
  block.c:1694:25: warning: format '%I64d' expects type 'int', but argument 4 
has type 'int64_t'
  block.c:1694:25: warning: format '%I64d' expects type 'int', but argument 5 
has type 'int64_t'
  block.c:1694:25: warning: format '%I64d' expects type 'int', but argument 6 
has type 'int64_t'
  block.c: In function 'bdrv_info_stats_bs':
  block.c:1717:30: warning: format '%I64d' expects type 'int', but argument 2 
has type 'uint64_t'
  block.c:1717:30: warning: format '%I64d' expects type 'int', but argument 3 
has type 'uint64_t'
  block.c:1717:30: warning: format '%I64d' expects type 'int', but argument 4 
has type 'uint64_t'
  block.c:1717:30: warning: format '%I64d' expects type 'int', but argument 5 
has type 'uint64_t'
  block.c:1717:30: warning: format '%I64d' expects type 'int', but argument 6 
has type 'long long unsigned int'
CCaio.o
CCaes.o
CCqemu-config.o
CCblock/raw.o
CCblock/cow.o
CCb

[Qemu-devel] [Bug 760060] Re: Open Solaris 2009 Assertion `size' failed

[Nigel Horne]

Thanks Stefan, I appreciate it.  I will try your suggestion - in the
meantime here is the stack trace if it helps you to confirm.

(gdb) r
Starting program: /usr/local/bin/qemu-system-sparc -hda opensolaris -cdrom 
osol-0906-ai-sparc.iso -boot d -k en-us -m 256
[Thread debugging using libthread_db enabled]
[New Thread 0x710f9700 (LWP 24099)]
qemu-system-sparc: /home/njh/src/qemu/exec.c:2614: 
cpu_register_physical_memory_offset: Assertion `size' failed.

Program received signal SIGABRT, Aborted.
0x75f5d165 in raise (sig=)
at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
64  ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
in ../nptl/sysdeps/unix/sysv/linux/raise.c
(gdb) bt
#0  0x75f5d165 in raise (sig=)
at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x75f5ff70 in abort () at abort.c:92
#2  0x75f562b1 in __assert_fail (assertion=0x4f16af "size", 
file=, line=2614, 
function=0x562ae0 "cpu_register_physical_memory_offset") at assert.c:81
#3  0x004a40fe in cpu_register_physical_memory_offset (
start_addr=268435456, size=0, phys_offset=48, region_offset=0)
at /home/njh/src/qemu/exec.c:2614
#4  0x004eb886 in sun4m_hw_init (hwdef=0x56ffc0, RAM_size=268435456, 
boot_device=0x7fffde90 "d", kernel_filename=0x0, 
kernel_cmdline=0x4f15f2 "", initrd_filename=0x0, 
cpu_model=) at /home/njh/src/qemu/hw/sun4m.c:836
#5  0x004ebcb1 in ss5_init (RAM_size=, 
boot_device=, kernel_filename=, 
kernel_cmdline=, 
initrd_filename=, cpu_model=)
at /home/njh/src/qemu/hw/sun4m.c:1260
#6  0x004d96ba in main (argc=, 
argv=, envp=)
at /home/njh/src/qemu/vl.c:3059
(gdb)

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

Title:
  Open Solaris 2009 Assertion `size' failed

Status in QEMU:
  Fix Committed

Bug description:
  The latest git version of qemu (commit
  9df38c47d01eb1fd7eb9d60ac70a4170e638b4a2) fails to boot the
  OpenSolaris image from
  http://dlc.sun.com/osol/opensolaris/2009/06/osol-0906-ai-sparc.iso.

  qemu-img create opensolaris 3G
  qemu-system-sparc -hda opensolaris -cdrom osol-0906-ai-sparc.iso -boot d 
-redir tcp:2232::22 -k en-us -m 256

  gives:

  qemu-system-sparc: /home/njh/src/qemu/exec.c:2614:
  cpu_register_physical_memory_offset: Assertion `size' failed.

  Host: Linux/x86_64
  gcc4.5
  ./configure --enable-linux-aio --enable-io-thread --enable-kvm

[Qemu-devel] [Bug 760060] Re: Open Solaris 2009 Assertion `size' failed

[Nigel Horne]

It still doesn't boot, but that's something different - I will log that
as a separate bug.

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

Title:
  Open Solaris 2009 Assertion `size' failed

Status in QEMU:
  Fix Committed

Bug description:
  The latest git version of qemu (commit
  9df38c47d01eb1fd7eb9d60ac70a4170e638b4a2) fails to boot the
  OpenSolaris image from
  http://dlc.sun.com/osol/opensolaris/2009/06/osol-0906-ai-sparc.iso.

  qemu-img create opensolaris 3G
  qemu-system-sparc -hda opensolaris -cdrom osol-0906-ai-sparc.iso -boot d 
-redir tcp:2232::22 -k en-us -m 256

  gives:

  qemu-system-sparc: /home/njh/src/qemu/exec.c:2614:
  cpu_register_physical_memory_offset: Assertion `size' failed.

  Host: Linux/x86_64
  gcc4.5
  ./configure --enable-linux-aio --enable-io-thread --enable-kvm

[Qemu-devel] [Bug 760956] [NEW] Open Solaris 2009 Doesn't Boot

[Nigel Horne]

Public bug reported:

The latest git version of qemu (commit
420b6c317de87890e06225de6e2f8af7bf714df0) fails to boot the OpenSolaris
image from http://dlc.sun.com/osol/opensolaris/2009/06/osol-0906-ai-
sparc.iso.

qemu-img create opensolaris 3G
qemu-system-sparc -hda opensolaris -cdrom osol-0906-ai-sparc.iso -boot d -redir 
tcp:2232::22 -k en-us -m 192

gives:

...
Trying cdrom:d
File not found
Trying cdrom...
Not a bootable ELF image
Not a bootable a.out image
No valid state has been set by load or init_program

Host: Linux/x86_64
gcc4.5
./configure --enable-linux-aio --enable-io-thread --enable-kvm

** 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/760956

Title:
  Open Solaris 2009 Doesn't Boot

Status in QEMU:
  New

Bug description:
  The latest git version of qemu (commit
  420b6c317de87890e06225de6e2f8af7bf714df0) fails to boot the
  OpenSolaris image from
  http://dlc.sun.com/osol/opensolaris/2009/06/osol-0906-ai-sparc.iso.

  qemu-img create opensolaris 3G
  qemu-system-sparc -hda opensolaris -cdrom osol-0906-ai-sparc.iso -boot d 
-redir tcp:2232::22 -k en-us -m 192

  gives:

  ...
  Trying cdrom:d
  File not found
  Trying cdrom...
  Not a bootable ELF image
  Not a bootable a.out image
  No valid state has been set by load or init_program

  Host: Linux/x86_64
  gcc4.5
  ./configure --enable-linux-aio --enable-io-thread --enable-kvm

[Qemu-devel] [Bug 760976] [NEW] Nexenta 3.0.1 fails to install

[Nigel Horne]

Public bug reported:

The latest git version of qemu (commit
420b6c317de87890e06225de6e2f8af7bf714df0) fails to boot Nexenta3.0.1. I
don't know if this is a bug in nextenta, or in QEMU or both.

You can obtain a bootable image of Nextenta from
http://www.nexenta.org/releases/nexenta-core-
platform_3.0.1-b134_x86.iso.zip

Host: Linux/x86_64 gcc4.5 ./configure --enable-linux-aio --enable-io-
thread --enable-kvm

qemu-img create nexenta3.0.1 3G
qemu -hda nexenta3.0.1 -cdrom nexenta-core-platform3.0.1-b134x86.iso -boot d -k 
en-us -m 256

Boots to grub OK, but when you hit install you get
panic[cpu0]/thread=fec226c0: vmem_hash_delete(d4404690, d445abc0, 0):
bad free.

You get the same error with or without -enable-kvm

** 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/760976

Title:
  Nexenta 3.0.1 fails to install

Status in QEMU:
  New

Bug description:
  The latest git version of qemu (commit
  420b6c317de87890e06225de6e2f8af7bf714df0) fails to boot Nexenta3.0.1.
  I don't know if this is a bug in nextenta, or in QEMU or both.

  You can obtain a bootable image of Nextenta from
  http://www.nexenta.org/releases/nexenta-core-
  platform_3.0.1-b134_x86.iso.zip

  Host: Linux/x86_64 gcc4.5 ./configure --enable-linux-aio --enable-io-
  thread --enable-kvm

  qemu-img create nexenta3.0.1 3G
  qemu -hda nexenta3.0.1 -cdrom nexenta-core-platform3.0.1-b134x86.iso -boot d 
-k en-us -m 256

  Boots to grub OK, but when you hit install you get
  panic[cpu0]/thread=fec226c0: vmem_hash_delete(d4404690, d445abc0, 0):
  bad free.

  You get the same error with or without -enable-kvm

[Qemu-devel] [Bug 760976] Re: Nexenta 3.0.1 fails to install

[Nigel Horne]

** Attachment added: "Screenshot"
   
https://bugs.launchpad.net/qemu/+bug/760976/+attachment/2036109/+files/Screen%20shot%202011-04-14%20at%2013.58.46.png

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

Title:
  Nexenta 3.0.1 fails to install

Status in QEMU:
  New

Bug description:
  The latest git version of qemu (commit
  420b6c317de87890e06225de6e2f8af7bf714df0) fails to boot Nexenta3.0.1.
  I don't know if this is a bug in nextenta, or in QEMU or both.

  You can obtain a bootable image of Nextenta from
  http://www.nexenta.org/releases/nexenta-core-
  platform_3.0.1-b134_x86.iso.zip

  Host: Linux/x86_64 gcc4.5 ./configure --enable-linux-aio --enable-io-
  thread --enable-kvm

  qemu-img create nexenta3.0.1 3G
  qemu -hda nexenta3.0.1 -cdrom nexenta-core-platform3.0.1-b134x86.iso -boot d 
-k en-us -m 256

  Boots to grub OK, but when you hit install you get
  panic[cpu0]/thread=fec226c0: vmem_hash_delete(d4404690, d445abc0, 0):
  bad free.

  You get the same error with or without -enable-kvm

[Qemu-devel] [Bug 760956] Re: Open Solaris 2009 Doesn't Boot

[Stefan Weil]

Are you sure that it boots on real hardware? From the information given in
http://dlc.sun.com.edgesuite.net/osol/opensolaris/2009/06/README.osol-repo
I'd expect that this image is not bootable from CD-ROM.

A Debian CD-ROM boots without any problem.

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

Title:
  Open Solaris 2009 Doesn't Boot

Status in QEMU:
  New

Bug description:
  The latest git version of qemu (commit
  420b6c317de87890e06225de6e2f8af7bf714df0) fails to boot the
  OpenSolaris image from
  http://dlc.sun.com/osol/opensolaris/2009/06/osol-0906-ai-sparc.iso.

  qemu-img create opensolaris 3G
  qemu-system-sparc -hda opensolaris -cdrom osol-0906-ai-sparc.iso -boot d 
-redir tcp:2232::22 -k en-us -m 192

  gives:

  ...
  Trying cdrom:d
  File not found
  Trying cdrom...
  Not a bootable ELF image
  Not a bootable a.out image
  No valid state has been set by load or init_program

  Host: Linux/x86_64
  gcc4.5
  ./configure --enable-linux-aio --enable-io-thread --enable-kvm

Re: [Qemu-devel] [PATCH] Remove unneeded function parameter from gen_pc_load

[Stefan Weil]

Am 13.04.2011 23:05, schrieb Peter Maydell:

On 13 April 2011 21:38, Stefan Weil  wrote:

gen_pc_load was introduced in commit
d2856f1ad4c259e5766847c49acbb4e390731bd4.
The only reason for parameter searched_pc was
a debug statement in target-i386/translate.c.

Remove searched_pc from the debug statement
and from the parameter list of gen_pc_load.


No issues with the meat of the patch, but if we're going to
change all the callers and implementations of this anyway,
is there any appetite for giving it a more appropriate name?
It doesn't generate any code, it affects more than just the
pc, and it doesn't do a load...

restore_state_to_opc() ? set_env_for_opc() ?

-- PMM



What about cpu_restore_pc()? That's not always the whole truth,
but it's always the main action done in function n.n. which currently
is called gen_pc_load.

Or cpu_restore_helper()? Helper is very generic - it always fits.

Aurelien, please feel free to choose a name which suits bests.
I don't mind if you simply patch my patch, create a new one
or tell me which name should go into a new version of the patch
so I can send it.

Kind regards,
Stefan

Re: [Qemu-devel] [PATCH] Slirp reverse UDP firewall

[Daisuke Nojiri]

Hi, Blue,

> I missed somehow 1/3, so I'll comment to this one.

I updated 1/3 and pasted it below. The rest of the points you raised will be
addressed in 2/3 and 3/3.

> With the TCP firewall in mind, I'd use a more general syntax,
> something like "deny=proto:udp". More complete rules would need
> denying a block inside allowed block, so address part should be used
> here (or "all" for deny all).

How about drop=udp|tcp|all? drop switch makes all packets denied and allow
rules will work as exceptions.
This way, we can avoid conflicts between denys and allows.

> Don't use global variables. It's possible to have several interfaces,
> each on a different user mode stack, so each interface may have
> different rules. There's struct Slirp defined in slirp.h, please put
> these there.

Addressed as suggested. Thanks, Blue.

Dai

--- Subject: [Qemu-devel] [Patch 1/3] Slirp Reverse UDP Firewall

This patch series adds a simple reverse UDP firewall functionality to Slirp.
The series consists of three patches. Each adds one -net user option:

1. drop=udp|all - enables the firewall
2. droplog=FILE - sets the drop log filename
3. allow=PROTO:ADDR:PORT - adds an allow rule

  e.g.) $ qemu -net user,drop=udp,droplog=qemu.drop,allow=udp:10.0.2.3:53

All UDP packets except ones allowed by allow rules will be dropped. The
source
and the destination of the dropped packets are logged in the file specified
by FILE.
PORT can be a single number (e.g. 53) or a range (e.g. [80-81]). ADDR can be
a
single address (e.g. 1.2.3.4) or a range (e.g. 1.2.3.4/24). If ADDR
is ommitted,
all addresses match the rule. If PROTO is omitted, all protocols match the
rule.

TCP support will follow in another patch series.

Signed-off-by: Daisuke Nojiri 

diff --git a/net.c b/net.c
index 8d6a555..2742741 100644
--- a/net.c
+++ b/net.c
@@ -925,6 +925,10 @@ static const struct {
 .name = "guestfwd",
 .type = QEMU_OPT_STRING,
 .help = "IP address and port to forward guest TCP
connections",
+}, {
+.name = "drop",
+.type = QEMU_OPT_STRING,
+.help = "Enable the simple reverse firewall",
 },
 { /* end of list */ }
 },
diff --git a/net/slirp.c b/net/slirp.c
index b41c60a..bd83700 100644
--- a/net/slirp.c
+++ b/net/slirp.c
@@ -141,7 +141,7 @@ static int net_slirp_init(VLANState *vlan, const char
*model,
   const char *vhostname, const char *tftp_export,
   const char *bootfile, const char *vdhcp_start,
   const char *vnameserver, const char *smb_export,
-  const char *vsmbserver)
+  const char *vsmbserver, unsigned char drop)
 {
 /* default settings according to historic slirp */
 struct in_addr net  = { .s_addr = htonl(0x0a000200) }; /* 10.0.2.0 */
@@ -246,7 +246,7 @@ static int net_slirp_init(VLANState *vlan, const char
*model,
 s = DO_UPCAST(SlirpState, nc, nc);

 s->slirp = slirp_init(restricted, net, mask, host, vhostname,
-  tftp_export, bootfile, dhcp, dns, s);
+  tftp_export, bootfile, dhcp, dns, drop, s);
 QTAILQ_INSERT_TAIL(&slirp_stacks, s, entry);

 for (config = slirp_configs; config; config = config->next) {
@@ -693,6 +693,7 @@ int net_init_slirp(QemuOpts *opts,
 char *vnet = NULL;
 int restricted = 0;
 int ret;
+unsigned char drop = 0;

 vhost   = qemu_opt_get(opts, "host");
 vhostname   = qemu_opt_get(opts, "hostname");
@@ -726,11 +727,25 @@ int net_init_slirp(QemuOpts *opts,
 restricted = 1;
 }

+if (qemu_opt_get(opts, "drop")) {
+switch (qemu_opt_get(opts, "drop")[0]) {
+case 'u':
+drop &= SLIRP_DROP_UDP;
+break;
+case 'a':
+drop &= SLIRP_DROP_UDP;
+break;
+default:
+error_report("Unknown protocol name given to drop option");
+return -1;
+}
+}
+
 qemu_opt_foreach(opts, net_init_slirp_configs, NULL, 0);

 ret = net_slirp_init(vlan, "user", name, restricted, vnet, vhost,
  vhostname, tftp_export, bootfile, vdhcp_start,
- vnamesrv, smb_export, vsmbsrv);
+ vnamesrv, smb_export, vsmbsrv, drop);

 while (slirp_configs) {
 config = slirp_configs;
@@ -768,4 +783,3 @@ int net_slirp_parse_legacy(QemuOptsList *opts_list,
const char *optarg, int *ret

 return 1;
 }
-
diff --git a/qemu-options.hx b/qemu-options.hx
index ef60730..ef3e726 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -1067,7 +1067,7 @@ DEF("net", HAS_ARG, QEMU_OPTION_net,
 #ifdef CONFIG_SLIRP
 "-net
user[,vlan=n][,name=str][,net=addr[/mask]][,host=addr][,restrict=y|n]\n"
 "
[,hostname=host][,dhcpstart=addr][,dns=addr][,tftp=dir][,bootfile=f]\n"
-" [

Re: [Qemu-devel] [PATCH] Slirp reverse UDP firewall

[Stefan Berger]

On 04/12/2011 12:19 PM, Daisuke Nojiri wrote:

This patch adds: -drop-udp, -allow-udp ADDR:PORT, -drop-log FILE

  e.g.) $ qemu -net user -drop-log qemu.drop -drop-udp -allow-udp 
10.0.2.3:53 


-drop-udp enables usermode firewall for out-going UDP packats from a 
guest.

All UDP packets except ones allowed by -allow-udp will be dropped. Dropped
packets are logged in the file specified by FILE. PORT can be a single 
number
(e.g. 53) or a range (e.g. [80-81]). If ADDR is ommitted, all 
addresses match

the rule.


If you want to end up providing functionality like ebtables/iptables 
does then you'll need to think of user-defined tables or 'labeled rules' 
along with gotos/jumps -- not just for efficiency reasons but also 
because strictly linear evaluation of rules doesn't cover all the cases.
Besides that you'd probably want a connection tracking system so that 
you can for example enable only a few [UDP] ports of the VM to be 
reachable yet can initiate any kind of traffic... A bigger undertaking 
to say the least.


My $.02,
   Stefan

Re: [Qemu-devel] [Bug 760956] [NEW] Open Solaris 2009 Doesn't Boot

[Artyom Tarasenko]

As already mentioned in the Bug 760060,

OpenSolaris doesn't support 32 bit SPARC machines, so you should use a
qemu-system-sparc64 and not qemu-system-sparc.
(Although booting [Open]Solaris to the command prompt is not possible
with qemu-system-sparc64 yet)

Also --enable-kvm makes no effect when host arch <> guest arch. And
there is no kvm
support for SPARC.

On Thu, Apr 14, 2011 at 7:49 PM, Nigel Horne <760...@bugs.launchpad.net> wrote:
> Public bug reported:
>
> The latest git version of qemu (commit
> 420b6c317de87890e06225de6e2f8af7bf714df0) fails to boot the OpenSolaris
> image from http://dlc.sun.com/osol/opensolaris/2009/06/osol-0906-ai-
> sparc.iso.
>
> qemu-img create opensolaris 3G
> qemu-system-sparc -hda opensolaris -cdrom osol-0906-ai-sparc.iso -boot d 
> -redir tcp:2232::22 -k en-us -m 192
>
> gives:
>
> ...
> Trying cdrom:d
> File not found
> Trying cdrom...
> Not a bootable ELF image
> Not a bootable a.out image
> No valid state has been set by load or init_program
>
> Host: Linux/x86_64
> gcc4.5
> ./configure --enable-linux-aio --enable-io-thread --enable-kvm
>
> ** 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/760956
>
> Title:
>  Open Solaris 2009 Doesn't Boot
>
> Status in QEMU:
>  New
>
> Bug description:
>  The latest git version of qemu (commit
>  420b6c317de87890e06225de6e2f8af7bf714df0) fails to boot the
>  OpenSolaris image from
>  http://dlc.sun.com/osol/opensolaris/2009/06/osol-0906-ai-sparc.iso.
>
>  qemu-img create opensolaris 3G
>  qemu-system-sparc -hda opensolaris -cdrom osol-0906-ai-sparc.iso -boot d 
> -redir tcp:2232::22 -k en-us -m 192
>
>  gives:
>
>  ...
>  Trying cdrom:d
>  File not found
>  Trying cdrom...
>  Not a bootable ELF image
>  Not a bootable a.out image
>  No valid state has been set by load or init_program
>
>  Host: Linux/x86_64
>  gcc4.5
>  ./configure --enable-linux-aio --enable-io-thread --enable-kvm
>
>



-- 
Regards,
Artyom Tarasenko

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

Re: [Qemu-devel] [PATCH] Slirp reverse UDP firewall

[Daisuke Nojiri]

Hi, Avi,

Complex and complete firewalling is probably out of my focus for now. I'm
trying to introduce a simple reverse firewall functionality which filters
outgoing patckets based on only destination address and port. Since Qemu
doesn't have any reverse firewall currently, I believe this is a good
addition and start.

Dai

On Thu, Apr 14, 2011 at 7:08 AM, Avi Kivity  wrote:

> On 04/14/2011 04:48 PM, Avi Kivity wrote:
>
>> Will we see a TCP firewall as well? Can we prepare for a more generic
>>> infrastructure, or what makes UDP special?
>>>
>>
>>
>> If some generic firewall like BPF is available as a user library, perhaps
>> we can integrate one instead of writing a new one from scratch.
>>
>>
> Heck, you could even write a tcg backend for bpf instructions and run the
> jit the firewall filter set.
>
>
> --
> error compiling committee.c: too many arguments to function
>
>

[Qemu-devel] [RFC][PATCH] configure: target dependent linking

[Michael Walle]

This patch is the first attempt to make configure more intelligent with
regard to how it links to libraries. It divides the softmmu libraries into
two lists, a general one and a list which depends on the target
architecture.

---
 configure |   12 +---
 1 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/configure b/configure
index da2da04..9825b12 100755
--- a/configure
+++ b/configure
@@ -1946,11 +1946,11 @@ int main(void) { return 0; }
 EOF
   if compile_prog "" "$fdt_libs" ; then
 fdt=yes
-libs_softmmu="$fdt_libs $libs_softmmu"
   else
 if test "$fdt" = "yes" ; then
   feature_not_found "fdt"
 fi
+fdt_libs=
 fdt=no
   fi
 fi
@@ -1967,11 +1967,11 @@ int main(void) { GL_VERSION; return 0; }
 EOF
   if compile_prog "" "-lGL" ; then
 opengl=yes
-   libs_softmmu="$opengl_libs $libs_softmmu"
   else
 if test "$opengl" = "yes" ; then
   feature_not_found "opengl"
 fi
+opengl_libs=
 opengl=no
   fi
 fi
@@ -3071,6 +3071,7 @@ target_short_alignment=2
 target_int_alignment=4
 target_long_alignment=4
 target_llong_alignment=8
+target_libs_softmmu=
 
 TARGET_ARCH="$target_arch2"
 TARGET_BASE_ARCH=""
@@ -3104,6 +3105,7 @@ case "$target_arch2" in
   ;;
   lm32)
 target_phys_bits=32
+target_libs_softmmu="$opengl_libs"
   ;;
   m68k)
 bflt="yes"
@@ -3142,6 +3144,7 @@ case "$target_arch2" in
 gdb_xml_files="power-core.xml power-fpu.xml power-altivec.xml 
power-spe.xml"
 target_phys_bits=32
 target_nptl="yes"
+target_libs_softmmu="$fdt_libs"
   ;;
   ppcemb)
 TARGET_BASE_ARCH=ppc
@@ -3149,6 +3152,7 @@ case "$target_arch2" in
 gdb_xml_files="power-core.xml power-fpu.xml power-altivec.xml 
power-spe.xml"
 target_phys_bits=64
 target_nptl="yes"
+target_libs_softmmu="$fdt_libs"
   ;;
   ppc64)
 TARGET_BASE_ARCH=ppc
@@ -3156,6 +3160,7 @@ case "$target_arch2" in
 gdb_xml_files="power64-core.xml power-fpu.xml power-altivec.xml 
power-spe.xml"
 target_phys_bits=64
 target_long_alignment=8
+target_libs_softmmu="$fdt_libs"
   ;;
   ppc64abi32)
 TARGET_ARCH=ppc64
@@ -3164,6 +3169,7 @@ case "$target_arch2" in
 echo "TARGET_ABI32=y" >> $config_target_mak
 gdb_xml_files="power64-core.xml power-fpu.xml power-altivec.xml 
power-spe.xml"
 target_phys_bits=64
+target_libs_softmmu="$fdt_libs"
   ;;
   sh4|sh4eb)
 TARGET_ARCH=sh4
@@ -3249,7 +3255,7 @@ fi
 if test "$target_softmmu" = "yes" ; then
   echo "TARGET_PHYS_ADDR_BITS=$target_phys_bits" >> $config_target_mak
   echo "CONFIG_SOFTMMU=y" >> $config_target_mak
-  echo "LIBS+=$libs_softmmu" >> $config_target_mak
+  echo "LIBS+=$libs_softmmu $target_libs_softmmu" >> $config_target_mak
   echo "HWDIR=../libhw$target_phys_bits" >> $config_target_mak
   echo "subdir-$target: subdir-libhw$target_phys_bits" >> $config_host_mak
 fi
-- 
1.7.2.3

[Qemu-devel] Estimado usuario Webmail

[Webmail administrador]

Estimado usuario Webmail 



Hemos limitado temporalmente el acceso a todas las funciones 

Susceptibles a todas las cuentas de correo web. Para restaurar su acceso 

Cuenta, debe responder de inmediato a este correo electrónico con su 

Nombre de usuario y contraseña. Usuario: Contraseña (  ): 

(  )



Debido a que una gran cantidad de correo basura o spam que recibe todos los 
días, 

Actualizar todas las cuentas de correo electrónico spam filtro para limitar no 
electrónicos 

Preguntado por razones de seguridad y reforzar la nueva 

Mejorar las características de cuenta de correo web / correo electrónico para 
asegurarse de que 

No es la experiencia la interrupción del servicio. 



Usted debe responder a este mensaje de inmediato e introduzca el nombre 

Nombre de usuario y contraseña en el espacio provisto para que podamos 
actualizar su 

Cuenta de correo electrónico correctamente. Un enlace será enviado a usted 
confirmar 

Para volver a activar su cuenta de correo electrónico, obtener su 

Responder 



Gracias por su comprensión. 

3xepyl Error 506: Advertencia Código 



Gracias 

Webmail administrador 

Soporte Copyright 2010. 

ListenRead fonéticamente 

[Qemu-devel] Estimado usuario Webmail

[Webmail administrador]

Estimado usuario Webmail 



Hemos limitado temporalmente el acceso a todas las funciones 

Susceptibles a todas las cuentas de correo web. Para restaurar su acceso 

Cuenta, debe responder de inmediato a este correo electrónico con su 

Nombre de usuario y contraseña. Usuario: Contraseña (  ): 

(  )



Debido a que una gran cantidad de correo basura o spam que recibe todos los 
días, 

Actualizar todas las cuentas de correo electrónico spam filtro para limitar no 
electrónicos 

Preguntado por razones de seguridad y reforzar la nueva 

Mejorar las características de cuenta de correo web / correo electrónico para 
asegurarse de que 

No es la experiencia la interrupción del servicio. 



Usted debe responder a este mensaje de inmediato e introduzca el nombre 

Nombre de usuario y contraseña en el espacio provisto para que podamos 
actualizar su 

Cuenta de correo electrónico correctamente. Un enlace será enviado a usted 
confirmar 

Para volver a activar su cuenta de correo electrónico, obtener su 

Responder 



Gracias por su comprensión. 

3xepyl Error 506: Advertencia Código 



Gracias 

Webmail administrador 

Soporte Copyright 2010. 

ListenRead fonéticamente 

[Qemu-devel] Estimado usuario Webmail

[Webmail administrador]

Estimado usuario Webmail 



Hemos limitado temporalmente el acceso a todas las funciones 

Susceptibles a todas las cuentas de correo web. Para restaurar su acceso 

Cuenta, debe responder de inmediato a este correo electrónico con su 

Nombre de usuario y contraseña. Usuario: Contraseña (  ): 

(  )



Debido a que una gran cantidad de correo basura o spam que recibe todos los 
días, 

Actualizar todas las cuentas de correo electrónico spam filtro para limitar no 
electrónicos 

Preguntado por razones de seguridad y reforzar la nueva 

Mejorar las características de cuenta de correo web / correo electrónico para 
asegurarse de que 

No es la experiencia la interrupción del servicio. 



Usted debe responder a este mensaje de inmediato e introduzca el nombre 

Nombre de usuario y contraseña en el espacio provisto para que podamos 
actualizar su 

Cuenta de correo electrónico correctamente. Un enlace será enviado a usted 
confirmar 

Para volver a activar su cuenta de correo electrónico, obtener su 

Responder 



Gracias por su comprensión. 

3xepyl Error 506: Advertencia Código 



Gracias 

Webmail administrador 

Soporte Copyright 2010. 

ListenRead fonéticamente 

Re: [Qemu-devel] [Bug 760976] [NEW] Nexenta 3.0.1 fails to install

[Natalia Portillo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Please report to Official OS Support List.

El 14/04/2011, a las 19:03, Nigel Horne escribió:

> Public bug reported:
> 
> The latest git version of qemu (commit
> 420b6c317de87890e06225de6e2f8af7bf714df0) fails to boot Nexenta3.0.1. I
> don't know if this is a bug in nextenta, or in QEMU or both.
> 
> You can obtain a bootable image of Nextenta from
> http://www.nexenta.org/releases/nexenta-core-
> platform_3.0.1-b134_x86.iso.zip
> 
> Host: Linux/x86_64 gcc4.5 ./configure --enable-linux-aio --enable-io-
> thread --enable-kvm
> 
> qemu-img create nexenta3.0.1 3G
> qemu -hda nexenta3.0.1 -cdrom nexenta-core-platform3.0.1-b134x86.iso -boot d 
> -k en-us -m 256
> 
> Boots to grub OK, but when you hit install you get
> panic[cpu0]/thread=fec226c0: vmem_hash_delete(d4404690, d445abc0, 0):
> bad free.
> 
> You get the same error with or without -enable-kvm
> 
> ** 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/760976
> 
> Title:
>  Nexenta 3.0.1 fails to install
> 
> Status in QEMU:
>  New
> 
> Bug description:
>  The latest git version of qemu (commit
>  420b6c317de87890e06225de6e2f8af7bf714df0) fails to boot Nexenta3.0.1.
>  I don't know if this is a bug in nextenta, or in QEMU or both.
> 
>  You can obtain a bootable image of Nextenta from
>  http://www.nexenta.org/releases/nexenta-core-
>  platform_3.0.1-b134_x86.iso.zip
> 
>  Host: Linux/x86_64 gcc4.5 ./configure --enable-linux-aio --enable-io-
>  thread --enable-kvm
> 
>  qemu-img create nexenta3.0.1 3G
>  qemu -hda nexenta3.0.1 -cdrom nexenta-core-platform3.0.1-b134x86.iso -boot d 
> -k en-us -m 256
> 
>  Boots to grub OK, but when you hit install you get
>  panic[cpu0]/thread=fec226c0: vmem_hash_delete(d4404690, d445abc0, 0):
>  bad free.
> 
>  You get the same error with or without -enable-kvm
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org

iF4EAREIAAYFAk2nheIACgkQv/wfOsykIRRr+AD+PGFqmHGovfcG9f3a5axB2o2a
86FPUdWkuCvz84rJZ5AA/2PA9+6U0XLM7+N1mLVWLg2tlXJkP2uLI5t7gGtjVUVQ
=FcGz
-END PGP SIGNATURE-

Re: [Qemu-devel] Problem in setting breakpoints at kernel code using "qemu and gdb"

[Craig Brozefsky]

On Thu, Apr 14, 2011 at 10:16 AM, Amirali Shambayati
 wrote:

>
> Also I tried combination of gdb and qemu using following commands:
> #gdb
> (gdb) symbol-file vmlinux.o
> (gdb) target remote localhost:1234
> (gdb) break scsi_lib.c 1420
> (gdb) c
>
> I tried above commands to check if stops at breakpoint or not. I put a
> printk after breakpoint line. It printed it and it means that it has
> ignored breakpoint.

Try using a hbreak, hardware breakpoint, instead of the software breakpoint.