[Qemu-devel] (no subject)

[Yang Weijiang]

Subject: [Qemu-devel][PATCH v3 0/5] This patch-set is to enable Guest
CET support.

Control-flow Enforcement Technology (CET) provides protection against
return/jump-oriented programming (ROP) attacks. To make kvm Guest OS own
the capability, this patch-set is required. It enables CET related CPUID
report, xsaves/xrstors and live-migration etc. in Qemu.

Changelog:

 v3:
 - Add CET MSR save/restore support for live-migration.

 v2:
 - In CPUID.(EAX=d, ECX=1), set return ECX[n] = 0 if bit n corresponds
   to a bit in MSR_IA32_XSS.
 - In CPUID.(EAX=d, ECX=n), set return ECX = 1 if bit n corresponds
   to a bit in MSR_IA32_XSS.
 - Skip Supervisor mode xsave component when calculate User mode
   xave component size in xsave_area_size() and x86_cpu_reset().

Yang Weijiang (5):
  Add CET xsaves/xrstors related macros and structures.
  Add CET SHSTK and IBT CPUID feature-word definitions.
  Add hepler functions for CPUID xsave area size calculation.
  Report CPUID xsave area support for CET.
  Add CET MSR save/restore support for migration

 target/i386/cpu.c |  73 --
 target/i386/cpu.h |  48 +++-
 target/i386/kvm.c |  27 
 target/i386/machine.c | 100 ++
 4 files changed, 244 insertions(+), 4 deletions(-)

-- 
2.17.1

[Qemu-devel] (no subject)

[Yaowei Bai]

baiyao...@cmss.chinamobile.com
Bcc: 
Subject: Re: [Qemu-devel] [PATCH] tcmu: Introduce qemu-tcmu utility
Reply-To: baiyao...@cmss.chinamobile.com
In-Reply-To: <20190102015321.GA26514@byw>

Add Xiubo.

On Wed, Jan 02, 2019 at 09:53:21AM +0800, Yaowei Bai wrote:
> Ping.
> 
> BTW, it should be update docker image to install glib to fix this.
> 
> On Wed, Dec 26, 2018 at 12:19:48AM -0800, no-re...@patchew.org wrote:
> > Patchew URL: 
> > https://patchew.org/QEMU/1545387387-9613-1-git-send-email-baiyao...@cmss.chinamobile.com/
> > 
> > 
> > 
> > Hi,
> > 
> > This series seems to have some coding style problems. See output below for
> > more information:
> > 
> > Message-id: 1545387387-9613-1-git-send-email-baiyao...@cmss.chinamobile.com
> > Type: series
> > Subject: [Qemu-devel] [PATCH] tcmu: Introduce qemu-tcmu utility
> > 
> > === TEST SCRIPT BEGIN ===
> > #!/bin/bash
> > 
> > BASE=base
> > n=1
> > total=$(git log --oneline $BASE.. | wc -l)
> > failed=0
> > 
> > git config --local diff.renamelimit 0
> > git config --local diff.renames True
> > git config --local diff.algorithm histogram
> > 
> > commits="$(git log --format=%H --reverse $BASE..)"
> > for c in $commits; do
> > echo "Checking PATCH $n/$total: $(git log -n 1 --format=%s $c)..."
> > if ! git show $c --format=email | ./scripts/checkpatch.pl --mailback -; 
> > then
> > failed=1
> > echo
> > fi
> > n=$((n+1))
> > done
> > 
> > exit $failed
> > === TEST SCRIPT END ===
> > 
> > Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
> > Switched to a new branch 'test'
> > 52869e1 tcmu: Introduce qemu-tcmu utility
> > 
> > === OUTPUT BEGIN ===
> > Checking PATCH 1/1: tcmu: Introduce qemu-tcmu utility...
> > WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
> > #157: 
> > new file mode 100644
> > 
> > ERROR: trailing whitespace
> > #329: FILE: qemu-tcmu.c:51:
> > +"Usage:\n" $
> > 
> > WARNING: Block comments use a leading /* on a separate line
> > #466: FILE: qemu-tcmu.c:188:
> > +/* now when the initialization is (almost) complete, chdir("/")
> > 
> > WARNING: Block comments use a trailing */ on a separate line
> > #467: FILE: qemu-tcmu.c:189:
> > + * to free any busy filesystems */
> > 
> > ERROR: code indent should never use tabs
> > #525: FILE: tcmu/helper.c:16:
> > +^Iuint8_t *cdb,$
> > 
> > ERROR: code indent should never use tabs
> > #526: FILE: tcmu/helper.c:17:
> > +^Istruct iovec *iovec,$
> > 
> > ERROR: code indent should never use tabs
> > #527: FILE: tcmu/helper.c:18:
> > +^Isize_t iov_cnt)$
> > 
> > ERROR: code indent should never use tabs
> > #529: FILE: tcmu/helper.c:20:
> > +^Iuint8_t buf[36];$
> > 
> > ERROR: code indent should never use tabs
> > #531: FILE: tcmu/helper.c:22:
> > +^Imemset(buf, 0, sizeof(buf));$
> > 
> > ERROR: code indent should never use tabs
> > #533: FILE: tcmu/helper.c:24:
> > +^Ibuf[2] = 0x05; /* SPC-3 */$
> > 
> > ERROR: code indent should never use tabs
> > #534: FILE: tcmu/helper.c:25:
> > +^Ibuf[3] = 0x02; /* response data format */$
> > 
> > ERROR: code indent should never use tabs
> > #536: FILE: tcmu/helper.c:27:
> > +^I/*$
> > 
> > ERROR: code indent should never use tabs
> > #537: FILE: tcmu/helper.c:28:
> > +^I * A Third-Party Copy (3PC)$
> > 
> > ERROR: code indent should never use tabs
> > #538: FILE: tcmu/helper.c:29:
> > +^I *$
> > 
> > ERROR: code indent should never use tabs
> > #539: FILE: tcmu/helper.c:30:
> > +^I * Enable the XCOPY$
> > 
> > ERROR: code indent should never use tabs
> > #540: FILE: tcmu/helper.c:31:
> > +^I */$
> > 
> > ERROR: code indent should never use tabs
> > #541: FILE: tcmu/helper.c:32:
> > +^Ibuf[5] = 0x08;$
> > 
> > ERROR: code indent should never use tabs
> > #543: FILE: tcmu/helper.c:34:
> > +^Ibuf[7] = 0x02; /* CmdQue */$
> > 
> > ERROR: code indent should never use tabs
> > #545: FILE: tcmu/helper.c:36:
> > +^Imemcpy([8], "LIO-ORG ", 8);$
> > 
> > ERROR: code indent should never use tabs
> > #546: FILE: tcmu/helper.c:37:
> > +^Imemset([16], 0x20, 16);$
> > 
> > ERROR: code indent should never use tabs
> > #547: FILE: tcmu/helper.c:38:
> > +^Imemcpy([16], "TCMU device"

[Qemu-devel] (no subject)

[Илья Резников]

Please add android support

Re: [Qemu-devel] (no subject)

[Peter Maydell]

On Thu, 29 Nov 2018 at 02:11, berkus infinitus  wrote:
>
> I suspect the main problem is the blocking call to qemu_main
> from the UI thread in the app delegate didFinishLoadingWithOptions
> if i’m not mistaken and everything else grows from there.

Yes; if there's no way that Mojave will allow us to run
qemu_main directly on the main thread, then we have to
create a 2nd thread to run qemu_main on (which then becomes
what QEMU thinks of as the "main loop thread"), and then
we run into the need to make all the UI calls be forwarded
from the main loop thread to the main thread, and to get
QEMU locks when making calls into qemu from the main thread.

I think the code we have in git currently will already do
all the UI calls on the main thread -- it just does it by
doing a blocking call into qemu_main which later does
event processing itself. (It's a shame OSX doesn't document
what you need to do to write code that way, it's a fairly
common paradigm for other GUIs.)

For High Sierra there is apparently a "main thread checker"
utility: 
https://developer.apple.com/documentation/code_diagnostics/main_thread_checker
so running
DYLD_INSERT_LIBRARIES=/Applications/Xcode.app/Contents/Developer/usr/lib/libMainThreadChecker.dylib
qemu-system-x86_64 args...

will let us check for violations of the "do things on main
thread" principle even without Mohave. For me with current
QEMU it doesn't report any issues.

thanks
-- PMM

Re: [Qemu-devel] (no subject)

[berkus infinitus]

I suspect the main problem is the blocking call to qemu_main from the UI
thread in the app delegate didFinishLoadingWithOptions if i’m not mistaken
and everything else grows from there. Going to build and run it now, since
I woke up in the middle of the night anyway for reasons unexplainable)
On Thu, 29 Nov 2018 at 02:21, Programmingkid 
wrote:

>
> > On Nov 28, 2018, at 2:39 PM, Peter Maydell 
> wrote:
> >
> > On Wed, 28 Nov 2018 at 01:12, John Arbuckle 
> wrote:
> >>
> >> From af4497f2b161bb4165acb8eee5cae3f2a7ea2227 Mon Sep 17 00:00:00 2001
> >> From: John Arbuckle 
> >> Date: Tue, 27 Nov 2018 20:01:20 -0500
> >> Subject: [PATCH] ui/cocoa.m: fix crash due to cocoa_refresh() on Mac OS
> 10.14
> >
> > Something seems to have got the formatting of this patch email
> > wrong -- it's got all this in the body and the actual Subject
> > line of the email is blank.
>
> I don't know what happened.
>
> >
> >> Mac OS 10.14 only wants UI code to be called from the main thread. The
> >> cocoa_refresh() function is called on another thread and this causes a
> >> crash to take place. To fix this problem the cocoa_refresh() code is
> >> called from the main thread only.
> >>
> >> Signed-off-by: John Arbuckle 
> >> ---
> >> ui/cocoa.m | 59
> ++-
> >> 1 file changed, 34 insertions(+), 25 deletions(-)
> >
> > I get a compile warning with this patch:
> > /Users/pm215/src/qemu/ui/cocoa.m:1615:23: warning: instance method
> > '-cocoa_refresh' not found (return type defaults to 'id')
> > [-Wobjc-method-access]
> >[[NSApp delegate] cocoa_refresh];
> >  ^
>
> This will fix the problem:
>
> static void cocoa_refresh(DisplayChangeListener *dcl)
> {
> QemuCocoaAppController *controller = (QemuCocoaAppController *)[NSApp
> delegate];
> [controller cocoa_refresh];
> }
>
> > To be honest, I'm still confused about what is causing the
> > problems on Mojave. The refresh method should be being called
> > on the main thread even with the code on master -- it's just
> > that that is the iothread and it's running the event pumping
> > code in the refresh callback rather than a standard OSX
> > event loop. I'm hoping that the backtrace with symbols of
> > the Mojave assertion failure will help there, since I
> > can't currently see where refresh gets called from some
> > non-main thread.
>
> This might be a Mojave issue and not a QEMU issue.
> I'm on Mac OS 10.12 so I can't confirm anything.
>
> > I also think that this patch doesn't address the problems
> > of locking that I mention on the discussion thread for
> > Berkus' patch. It also doesn't handle any of the other
> > callbacks from QEMU to the cocoa UI -- surely we need to
> > handle all of them if there is a problem here?
>
> To answer this question I would have to know how my patch
> does on Mac OS 10.14. Does it stop the crashing issue? If
> this patch does fix that problem then I think sticking to
> a simple solution may be the answer. The use of locks may
> not be needed.
>
> > (I have some prototype patches which I've been working
> > on which address the locking problem and also make all
> > the QEMU callbacks run their work on the main thread.
> > I may be able get those into shape to post those next week.)
>
> Please CC me when do release it. I will test it on Mac OS 10.12
> and Mac OS 10.6.

Re: [Qemu-devel] (no subject)

[Programmingkid]

> On Nov 28, 2018, at 2:39 PM, Peter Maydell  wrote:
> 
> On Wed, 28 Nov 2018 at 01:12, John Arbuckle  wrote:
>> 
>> From af4497f2b161bb4165acb8eee5cae3f2a7ea2227 Mon Sep 17 00:00:00 2001
>> From: John Arbuckle 
>> Date: Tue, 27 Nov 2018 20:01:20 -0500
>> Subject: [PATCH] ui/cocoa.m: fix crash due to cocoa_refresh() on Mac OS 10.14
> 
> Something seems to have got the formatting of this patch email
> wrong -- it's got all this in the body and the actual Subject
> line of the email is blank.

I don't know what happened.

> 
>> Mac OS 10.14 only wants UI code to be called from the main thread. The
>> cocoa_refresh() function is called on another thread and this causes a
>> crash to take place. To fix this problem the cocoa_refresh() code is
>> called from the main thread only.
>> 
>> Signed-off-by: John Arbuckle 
>> ---
>> ui/cocoa.m | 59 ++-
>> 1 file changed, 34 insertions(+), 25 deletions(-)
> 
> I get a compile warning with this patch:
> /Users/pm215/src/qemu/ui/cocoa.m:1615:23: warning: instance method
> '-cocoa_refresh' not found (return type defaults to 'id')
> [-Wobjc-method-access]
>[[NSApp delegate] cocoa_refresh];
>  ^

This will fix the problem:

static void cocoa_refresh(DisplayChangeListener *dcl)
{
QemuCocoaAppController *controller = (QemuCocoaAppController *)[NSApp 
delegate];
[controller cocoa_refresh];
}

> To be honest, I'm still confused about what is causing the
> problems on Mojave. The refresh method should be being called
> on the main thread even with the code on master -- it's just
> that that is the iothread and it's running the event pumping
> code in the refresh callback rather than a standard OSX
> event loop. I'm hoping that the backtrace with symbols of
> the Mojave assertion failure will help there, since I
> can't currently see where refresh gets called from some
> non-main thread.

This might be a Mojave issue and not a QEMU issue. 
I'm on Mac OS 10.12 so I can't confirm anything.

> I also think that this patch doesn't address the problems
> of locking that I mention on the discussion thread for
> Berkus' patch. It also doesn't handle any of the other
> callbacks from QEMU to the cocoa UI -- surely we need to
> handle all of them if there is a problem here?

To answer this question I would have to know how my patch
does on Mac OS 10.14. Does it stop the crashing issue? If
this patch does fix that problem then I think sticking to
a simple solution may be the answer. The use of locks may
not be needed.

> (I have some prototype patches which I've been working
> on which address the locking problem and also make all
> the QEMU callbacks run their work on the main thread.
> I may be able get those into shape to post those next week.)

Please CC me when do release it. I will test it on Mac OS 10.12
and Mac OS 10.6. 

Re: [Qemu-devel] (no subject)

[Peter Maydell]

On Wed, 28 Nov 2018 at 01:12, John Arbuckle  wrote:
>
> From af4497f2b161bb4165acb8eee5cae3f2a7ea2227 Mon Sep 17 00:00:00 2001
> From: John Arbuckle 
> Date: Tue, 27 Nov 2018 20:01:20 -0500
> Subject: [PATCH] ui/cocoa.m: fix crash due to cocoa_refresh() on Mac OS 10.14

Something seems to have got the formatting of this patch email
wrong -- it's got all this in the body and the actual Subject
line of the email is blank.

> Mac OS 10.14 only wants UI code to be called from the main thread. The
> cocoa_refresh() function is called on another thread and this causes a
> crash to take place. To fix this problem the cocoa_refresh() code is
> called from the main thread only.
>
> Signed-off-by: John Arbuckle 
> ---
>  ui/cocoa.m | 59 ++-
>  1 file changed, 34 insertions(+), 25 deletions(-)

I get a compile warning with this patch:
/Users/pm215/src/qemu/ui/cocoa.m:1615:23: warning: instance method
'-cocoa_refresh' not found (return type defaults to 'id')
[-Wobjc-method-access]
[[NSApp delegate] cocoa_refresh];
  ^

To be honest, I'm still confused about what is causing the
problems on Mojave. The refresh method should be being called
on the main thread even with the code on master -- it's just
that that is the iothread and it's running the event pumping
code in the refresh callback rather than a standard OSX
event loop. I'm hoping that the backtrace with symbols of
the Mojave assertion failure will help there, since I
can't currently see where refresh gets called from some
non-main thread.

I also think that this patch doesn't address the problems
of locking that I mention on the discussion thread for
Berkus' patch. It also doesn't handle any of the other
callbacks from QEMU to the cocoa UI -- surely we need to
handle all of them if there is a problem here?

(I have some prototype patches which I've been working
on which address the locking problem and also make all
the QEMU callbacks run their work on the main thread.
I may be able get those into shape to post those next week.)

thanks
-- PMM

[Qemu-devel] (no subject)

[John Arbuckle]

>From af4497f2b161bb4165acb8eee5cae3f2a7ea2227 Mon Sep 17 00:00:00 2001
From: John Arbuckle 
Date: Tue, 27 Nov 2018 20:01:20 -0500
Subject: [PATCH] ui/cocoa.m: fix crash due to cocoa_refresh() on Mac OS 10.14

Mac OS 10.14 only wants UI code to be called from the main thread. The
cocoa_refresh() function is called on another thread and this causes a
crash to take place. To fix this problem the cocoa_refresh() code is
called from the main thread only. 

Signed-off-by: John Arbuckle 
---
 ui/cocoa.m | 59 ++-
 1 file changed, 34 insertions(+), 25 deletions(-)

diff --git a/ui/cocoa.m b/ui/cocoa.m
index ecf12bfc2e..17c168d08f 100644
--- a/ui/cocoa.m
+++ b/ui/cocoa.m
@@ -972,6 +972,8 @@ - (void)openDocumentation:(NSString *)filename;
 - (IBAction) do_about_menu_item: (id) sender;
 - (void)make_about_window;
 - (void)adjustSpeed:(id)sender;
+- (void) cocoa_refresh;
+- (void) cocoa_refresh_internal: (id) dummy;
 @end
 
 @implementation QemuCocoaAppController
@@ -1406,6 +1408,37 @@ - (void)adjustSpeed:(id)sender
 COCOA_DEBUG("cpu throttling at %d%c\n", cpu_throttle_get_percentage(), 
'%');
 }
 
+- (void) cocoa_refresh
+{
+[self performSelectorOnMainThread: @selector(cocoa_refresh_internal:) 
withObject: nil waitUntilDone: YES];
+}
+
+- (void) cocoa_refresh_internal: (id) dummy
+{
+COCOA_DEBUG("qemu_cocoa: cocoa_refresh\n");
+graphic_hw_update(NULL);
+
+if (qemu_input_is_absolute()) {
+if (![cocoaView isAbsoluteEnabled]) {
+if ([cocoaView isMouseGrabbed]) {
+[cocoaView ungrabMouse];
+}
+}
+[cocoaView setAbsoluteEnabled:YES];
+}
+
+NSDate *distantPast;
+NSEvent *event;
+distantPast = [NSDate distantPast];
+do {
+event = [NSApp nextEventMatchingMask:NSEventMaskAny 
untilDate:distantPast
+  inMode: NSDefaultRunLoopMode 
dequeue:YES];
+if (event != nil) {
+[cocoaView handleEvent:event];
+}
+} while(event != nil);
+}
+
 @end
 
 
@@ -1579,31 +1612,7 @@ static void cocoa_switch(DisplayChangeListener *dcl,
 
 static void cocoa_refresh(DisplayChangeListener *dcl)
 {
-NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
-
-COCOA_DEBUG("qemu_cocoa: cocoa_refresh\n");
-graphic_hw_update(NULL);
-
-if (qemu_input_is_absolute()) {
-if (![cocoaView isAbsoluteEnabled]) {
-if ([cocoaView isMouseGrabbed]) {
-[cocoaView ungrabMouse];
-}
-}
-[cocoaView setAbsoluteEnabled:YES];
-}
-
-NSDate *distantPast;
-NSEvent *event;
-distantPast = [NSDate distantPast];
-do {
-event = [NSApp nextEventMatchingMask:NSEventMaskAny 
untilDate:distantPast
-inMode: NSDefaultRunLoopMode dequeue:YES];
-if (event != nil) {
-[cocoaView handleEvent:event];
-}
-} while(event != nil);
-[pool release];
+[[NSApp delegate] cocoa_refresh];
 }
 
 static void cocoa_cleanup(void)
-- 
2.14.3 (Apple Git-98)

[Qemu-devel] (no subject)

[Liujinsong (Paul)]

[Qemu-devel] (no subject)

[Markus Armbruster]

I fooled around a bit, and I think there are a few lose ends.

Lets update the examples in docs/interop/qmp-spec.txt to show the
current greeting (section 3.1) and how to accept a capability (section
3.2).  The capability negotiation documentation could use some polish.
I'll post a patch.

Talking to a QMP monitor that supports OOB:

$ socat UNIX:test-qmp READLINE,history=$HOME/.qmp_history,prompt='QMP> '
{"QMP": {"version": {"qemu": {"micro": 50, "minor": 12, "major": 2}, 
"package": "v2.12.0-1703-gb909799463"}, "capabilities": ["oob"]}}
QMP> { "execute": "qmp_capabilities", "arguments": { "oob": true } }
{"error": {"class": "GenericError", "desc": "Parameter 'oob' is 
unexpected"}}
QMP> { "execute": "qmp_capabilities", "arguments": { "enable": ["oob"] } }
{"return": {}}
QMP> { "execute": "query-qmp-schema" }
{"error": {"class": "GenericError", "desc": "Out-Of-Band capability 
requires that every command contains an 'id' field"}}

Why does every command require 'id'?

Talking to a QMP monitor that doesn't support OOB:

{"QMP": {"version": {"qemu": {"micro": 50, "minor": 12, "major": 2}, 
"package": "v2.12.0-1703-gb909799463"}, "capabilities": []}}
QMP> { "execute": "qmp_capabilities", "arguments": { "enable": ["oob"] } }
{"error": {"class": "GenericError", "desc": "This monitor does not support 
Out-Of-Band (OOB)"}}
QMP> { "execute": "qmp_capabilities" }
{"return": {}}
QMP> { "execute": "query-kvm" }
{"return": {"enabled": true, "present": true}}
QMP> { "execute": "query-kvm", "control": { "run-oob": true } }
{"error": {"class": "GenericError", "desc": "Please enable Out-Of-Band 
first for the session during capabilities negotiation"}}

Telling people to enable OOB when that cannot be done is suboptimal.
More so when it cannot be used here anyway.  I'll post a patch.

[Qemu-devel] (no subject)

[Anatol Pomozov]

It is V3 of multiboot improvements to Qemu

Changes made sinse V2:
 - rebase on top of qemu master changes
 - make multiboot/sections test more reliable
 Add generate_sections_out.py script that generates ELF sections information
 - rename 'struct section_data' to 'struct SectionData' to match naming
 convention in include/hw/loader.h

[Qemu-devel] (no subject)

[Eduardo Otubo]

zhangchen.f...@cn.fujitsu.com, wang.guan...@zte.com.cn,
wang.yong...@zte.com.cn 
Bcc: 
Subject: colo-compare: segfault and assert on colo_compare_finalize
Reply-To: 

Hi all,

I have found a problem on colo-compare that leads to segmentation fault
when calling qemu like this:

 $ qemu-system-x86_64 -S -machine pc -object colo-compare,id=test-object

First I got an assert failed:

 (qemu-system-x86_64:7887): GLib-CRITICAL **: g_main_loop_quit: assertion 'loop 
!= NULL' failed

>From this looks like s->compare_loop is NULL on the function
colo_compare_finalize(), then I just added a check there and the assert went
away. But then there's the segfault:

 Thread 1 "qemu-system-x86" received signal SIGSEGV, Segmentation fault.
 0x7333f79e in pthread_join () from /lib64/libpthread.so.0
 (gdb) bt
 #0  0x7333f79e in pthread_join () at /lib64/libpthread.so.0
 #1  0x55c379d2 in qemu_thread_join (thread=0x77ff5160) at 
util/qemu-thread-posix.c:547
 #2  0x55adfc1a in colo_compare_finalize (obj=0x77fd3010) at 
net/colo-compare.c:867
 #3  0x55b2cd87 in object_deinit (obj=0x77fd3010, 
type=0x567432e0) at qom/object.c:453
 #4  0x55b2cdf9 in object_finalize (data=0x77fd3010) at 
qom/object.c:467
 #5  0x55b2dd80 in object_unref (obj=0x77fd3010) at qom/object.c:902
 #6  0x55b319a5 in user_creatable_add_type (type=0x567499a0 
"colo-compare", id=0x56749960 "test-object", qdict=0x56835750, 
v=0x5681a3f0, errp=0x7fffde58) at qom/object_interfaces.c:105
 #7  0x55b31b02 in user_creatable_add_opts (opts=0x56749910, 
errp=0x7fffde58) at qom/object_interfaces.c:135
 #8  0x55b31bfd in user_creatable_add_opts_foreach 
(opaque=0x558e9c39 , opts=0x56749910, errp=0x0) 
at qom/object_interfaces.c:159
 #9  0x55c4aecf in qemu_opts_foreach (list=0x56157ac0 
, func=0x55b31b6f , 
opaque=0x558e9c39 , errp=0x0) at 
util/qemu-option.c:1104
 #10 0x558edb75 in main (argc=6, argv=0x7fffe2d8, 
envp=0x7fffe310) at vl.c:4520

At this point '>thread' is '0'. Is this segfault and the above mentioned
assert trigged because I'm creating a colo-compare object without any other
parameter? In a positive case, a simple workaround and error check should do
it. Otherwise I'll debug a little more.

Best regards,

-- 
Eduardo Otubo
Senior Software Engineer @ RedHat

[Qemu-devel] (no subject)

[vaibhav shukla]

Hello,

I am Vaibhav Shukla, sophomore student of Indian Institute of Information 
Technology, Kalyani, India.

I would like to contribute in some projects in your company, please guide me 
that how can I do so.

I shall be highly grateful to you.

Yours Sincerely

Re: [Qemu-devel] (no subject)

[no-reply]

Hi,

This series seems to have some coding style problems. See output below for
more information:

Subject: [Qemu-devel] (no subject)
Type: series
Message-id: 536fb79a-5753-4143-a5a6-7a189ef5137e@ONE.local

=== TEST SCRIPT BEGIN ===
#!/bin/bash

BASE=base
n=1
total=$(git log --oneline $BASE.. | wc -l)
failed=0

git config --local diff.renamelimit 0
git config --local diff.renames True

commits="$(git log --format=%H --reverse $BASE..)"
for c in $commits; do
echo "Checking PATCH $n/$total: $(git log -n 1 --format=%s $c)..."
if ! git show $c --format=email | ./scripts/checkpatch.pl --mailback -; then
failed=1
echo
fi
n=$((n+1))
done

exit $failed
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
Switched to a new branch 'test'
32d5d78 (no subject)

=== OUTPUT BEGIN ===
Checking PATCH 1/1: (no subject)...
ERROR: space prohibited before that '++' (ctx:WxB)
#34: FILE: hw/gpio/bcm2835_gpio.c:58:
+for (i = 0; i < 10; i ++) {
   ^

ERROR: space prohibited between function name and open parenthesis '('
#37: FILE: hw/gpio/bcm2835_gpio.c:60:
+if (index < sizeof (s->fsel)) {

ERROR: space prohibited before that '++' (ctx:WxB)
#46: FILE: hw/gpio/bcm2835_gpio.c:70:
+for (i = 0; i < 10; i ++) {
   ^

ERROR: space prohibited between function name and open parenthesis '('
#49: FILE: hw/gpio/bcm2835_gpio.c:72:
+if (index < sizeof (s->fsel)) {

ERROR: space prohibited after that '~' (ctx:WxW)
#100: FILE: hw/gpio/bcm2835_gpio.c:115:
+uint32_t changes = val & ~ *lev;
  ^

ERROR: space prohibited before that '++' (ctx:WxB)
#105: FILE: hw/gpio/bcm2835_gpio.c:119:
+for (i = 0; i < count; i ++) {
  ^

ERROR: space prohibited before that '++' (ctx:WxB)
#121: FILE: hw/gpio/bcm2835_gpio.c:136:
+for (i = 0; i < count; i ++) {
  ^

ERROR: space prohibited after that '~' (ctx:WxW)
#129: FILE: hw/gpio/bcm2835_gpio.c:143:
+*lev &= ~ val;
 ^

ERROR: switch and case should be at the same indent
#141: FILE: hw/gpio/bcm2835_gpio.c:152:
 switch (offset) {
+case GPFSEL0:
+case GPFSEL1:
+case GPFSEL2:
+case GPFSEL3:
+case GPFSEL4:
+case GPFSEL5:
[...]
+case GPSET0:
+case GPSET1:
[...]
+case GPCLR0:
+case GPCLR1:
[...]
+case GPLEV0:
[...]
+case GPLEV1:
[...]
+case GPEDS0:
+case GPEDS1:
+case GPREN0:
+case GPREN1:
+case GPFEN0:
+case GPFEN1:
+case GPHEN0:
+case GPHEN1:
+case GPLEN0:
+case GPLEN1:
+case GPAREN0:
+case GPAREN1:
+case GPAFEN0:
+case GPAFEN1:
+case GPPUD:
+case GPPUDCLK0:
+case GPPUDCLK1:
[...]
+default:

ERROR: space prohibited after that '-' (ctx:WxW)
#200: FILE: hw/gpio/bcm2835_gpio.c:169:
+if (s->panel.socket != - 1) {
^

ERROR: space prohibited after that '-' (ctx:WxW)
#208: FILE: hw/gpio/bcm2835_gpio.c:177:
+if (s->panel.socket != - 1) {
^

ERROR: switch and case should be at the same indent
#252: FILE: hw/gpio/bcm2835_gpio.c:219:
 switch (offset) {
+case GPFSEL0:
+case GPFSEL1:
+case GPFSEL2:
+case GPFSEL3:
+case GPFSEL4:
+case GPFSEL5:
[...]
+case GPSET0:
[...]
+case GPSET1:
[...]
+case GPCLR0:
[...]
+case GPCLR1:
[...]
+case GPLEV0:
+case GPLEV1:
[...]
+case GPEDS0:
+case GPEDS1:
+case GPREN0:
+case GPREN1:
+case GPFEN0:
+case GPFEN1:
+case GPHEN0:
+case GPHEN1:
+case GPLEN0:
+case GPLEN1:
+case GPAREN0:
+case GPAREN1:
+case GPAFEN0:
+case GPAFEN1:
+case GPPUD:
+case GPPUDCLK0:
+case GPPUDCLK1:
[...]
+default:

ERROR: space prohibited after that '-' (ctx:WxW)
#308: FILE: hw/gpio/bcm2835_gpio.c:230:
+if (s->panel.socket != - 1) {
^

WARNING: line over 80 characters
#310: FILE: hw/gpio/bcm2835_gpio.c:232:
+senddatatopanel(>panel, Data, true); //John Bradley dummy 
GPIO Panel

ERROR: do not use C99 // comments
#310: FILE: hw/gpio/bcm2835_gpio.c:232:
+senddatatopanel(>panel, Data, true); //John Bradley dummy 
GPIO Panel

ERROR: space prohibited after that '-' (ctx:WxW)
#315: FILE: hw/gpio/bcm2835_gpio.c:237:
+if (s->panel.socket != - 1) {
^

WARNING: line over 80 characters
#318: FILE: hw/gpio/bcm2835_gpio.c:240:
+senddatatopanel(>panel, Data, true); //John Bradley dummy 
GPIO Panel

Re: [Qemu-devel] (no subject)

[no-reply]

Hi,

This series failed automatic build test. Please find the testing commands and
their output below. If you have docker installed, you can probably reproduce it
locally.

Subject: [Qemu-devel] (no subject)
Type: series
Message-id: 536fb79a-5753-4143-a5a6-7a189ef5137e@ONE.local

=== TEST SCRIPT BEGIN ===
#!/bin/bash
set -e
git submodule update --init dtc
# Let docker tests dump environment info
export SHOW_ENV=1
export J=8
time make docker-test-quick@centos6
time make docker-test-mingw@fedora
time make docker-test-build@min-glib
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
 * [new tag] patchew/536fb79a-5753-4143-a5a6-7a189ef5137e@ONE.local -> 
patchew/536fb79a-5753-4143-a5a6-7a189ef5137e@ONE.local
Switched to a new branch 'test'
32d5d78 (no subject)

=== OUTPUT BEGIN ===
Submodule 'dtc' (git://git.qemu-project.org/dtc.git) registered for path 'dtc'
Cloning into '/var/tmp/patchew-tester-tmp-1zdsj2xe/src/dtc'...
Submodule path 'dtc': checked out '558cd81bdd432769b59bff01240c44f82cfb1a9d'
  BUILD   centos6
make[1]: Entering directory '/var/tmp/patchew-tester-tmp-1zdsj2xe/src'
  ARCHIVE qemu.tgz
  ARCHIVE dtc.tgz
  COPYRUNNER
RUN test-quick in qemu:centos6 
Packages installed:
SDL-devel-1.2.14-7.el6_7.1.x86_64
ccache-3.1.6-2.el6.x86_64
epel-release-6-8.noarch
gcc-4.4.7-17.el6.x86_64
git-1.7.1-4.el6_7.1.x86_64
glib2-devel-2.28.8-5.el6.x86_64
libfdt-devel-1.4.0-1.el6.x86_64
make-3.81-23.el6.x86_64
package g++ is not installed
pixman-devel-0.32.8-1.el6.x86_64
tar-1.23-15.el6_8.x86_64
zlib-devel-1.2.3-29.el6.x86_64

Environment variables:
PACKAGES=libfdt-devel ccache tar git make gcc g++ zlib-devel 
glib2-devel SDL-devel pixman-devel epel-release
HOSTNAME=d9b60ec0a426
TERM=xterm
MAKEFLAGS= -j8
HISTSIZE=1000
J=8
USER=root
CCACHE_DIR=/var/tmp/ccache
EXTRA_CONFIGURE_OPTS=
V=
SHOW_ENV=1
MAIL=/var/spool/mail/root
PATH=/usr/lib/ccache:/usr/lib64/ccache:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
PWD=/
LANG=en_US.UTF-8
TARGET_LIST=
HISTCONTROL=ignoredups
SHLVL=1
HOME=/root
TEST_DIR=/tmp/qemu-test
LOGNAME=root
LESSOPEN=||/usr/bin/lesspipe.sh %s
FEATURES= dtc
DEBUG=
G_BROKEN_FILENAMES=1
CCACHE_HASHDIR=
_=/usr/bin/env

Configure options:
--enable-werror --target-list=x86_64-softmmu,aarch64-softmmu 
--prefix=/var/tmp/qemu-build/install
No C++ compiler available; disabling C++ specific optional code
Install prefix/var/tmp/qemu-build/install
BIOS directory/var/tmp/qemu-build/install/share/qemu
binary directory  /var/tmp/qemu-build/install/bin
library directory /var/tmp/qemu-build/install/lib
module directory  /var/tmp/qemu-build/install/lib/qemu
libexec directory /var/tmp/qemu-build/install/libexec
include directory /var/tmp/qemu-build/install/include
config directory  /var/tmp/qemu-build/install/etc
local state directory   /var/tmp/qemu-build/install/var
Manual directory  /var/tmp/qemu-build/install/share/man
ELF interp prefix /usr/gnemul/qemu-%M
Source path   /tmp/qemu-test/src
C compilercc
Host C compiler   cc
C++ compiler  
Objective-C compiler cc
ARFLAGS   rv
CFLAGS-O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -g 
QEMU_CFLAGS   -I/usr/include/pixman-1   -I$(SRC_PATH)/dtc/libfdt -pthread 
-I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include   -fPIE -DPIE -m64 -mcx16 
-D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes 
-Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes 
-fno-strict-aliasing -fno-common -fwrapv  -Wendif-labels 
-Wno-missing-include-dirs -Wempty-body -Wnested-externs -Wformat-security 
-Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration 
-Wold-style-definition -Wtype-limits -fstack-protector-all
LDFLAGS   -Wl,--warn-common -Wl,-z,relro -Wl,-z,now -pie -m64 -g 
make  make
install   install
pythonpython -B
smbd  /usr/sbin/smbd
module supportno
host CPU  x86_64
host big endian   no
target list   x86_64-softmmu aarch64-softmmu
tcg debug enabled no
gprof enabled no
sparse enabledno
strip binariesyes
profiler  no
static build  no
pixmansystem
SDL support   yes (1.2.14)
GTK support   no 
GTK GL supportno
VTE support   no 
TLS priority  NORMAL
GNUTLS supportno
GNUTLS rndno
libgcrypt no
libgcrypt kdf no
nettleno 
nettle kdfno
libtasn1  no
curses supportno
virgl support no
curl support  no
mingw32 support   no
Audio drivers oss
Block whitelist (rw) 
Block whitelist (ro) 
VirtFS supportno
VNC support   yes
VNC SASL support  no
VNC JPEG support  no
VNC PNG support   no
xen support   no
brlapi supportno
bluez  supportno
Documentation no
PIE   yes
vde support   no
netmap supportno
Linux AIO support no
ATTR/XATTR support yes
Install blobs yes
KVM support   

[Qemu-devel] (no subject)

[John Bradley]

>From 836daaff38940535548043f2e8f2e3df7a62d473 Mon Sep 17 00:00:00 2001
From: John Bradley 
Date: Wed, 17 May 2017 18:57:21 +0100
Subject: [PATCH] [PATCH] Add code to connect with
 https://github.com/flypie/GDummyPanel The code uses GNU Sockets & Windows
 sockets as on MINGW GNU no available. This is inteded as a Demo for RFC.

Signed-off-by: John Bradley 
---
 hw/gpio/bcm2835_gpio.c | 330 +++--
 include/hw/gpio/bcm2835_gpio.h |   5 +
 include/qemu/PanelEmu.h|  54 +++
 util/Makefile.objs |   1 +
 util/PanelEmu.c| 329 
 5 files changed, 577 insertions(+), 142 deletions(-)
 create mode 100644 include/qemu/PanelEmu.h
 create mode 100644 util/PanelEmu.c

diff --git a/hw/gpio/bcm2835_gpio.c b/hw/gpio/bcm2835_gpio.c
index acc2e3cf9e..14bd059861 100644
--- a/hw/gpio/bcm2835_gpio.c
+++ b/hw/gpio/bcm2835_gpio.c
@@ -19,6 +19,8 @@
 #include "hw/sd/sd.h"
 #include "hw/gpio/bcm2835_gpio.h"
 
+
+
 #define GPFSEL0   0x00
 #define GPFSEL1   0x04
 #define GPFSEL2   0x08
@@ -53,9 +55,9 @@ static uint32_t gpfsel_get(BCM2835GpioState *s, uint8_t reg)
 {
 int i;
 uint32_t value = 0;
-for (i = 0; i < 10; i++) {
+for (i = 0; i < 10; i ++) {
 uint32_t index = 10 * reg + i;
-if (index < sizeof(s->fsel)) {
+if (index < sizeof (s->fsel)) {
 value |= (s->fsel[index] & 0x7) << (3 * i);
 }
 }
@@ -65,9 +67,9 @@ static uint32_t gpfsel_get(BCM2835GpioState *s, uint8_t reg)
 static void gpfsel_set(BCM2835GpioState *s, uint8_t reg, uint32_t value)
 {
 int i;
-for (i = 0; i < 10; i++) {
+for (i = 0; i < 10; i ++) {
 uint32_t index = 10 * reg + i;
-if (index < sizeof(s->fsel)) {
+if (index < sizeof (s->fsel)) {
 int fsel = (value >> (3 * i)) & 0x7;
 s->fsel[index] = fsel;
 }
@@ -75,24 +77,24 @@ static void gpfsel_set(BCM2835GpioState *s, uint8_t reg, 
uint32_t value)
 
 /* SD controller selection (48-53) */
 if (s->sd_fsel != 0
-&& (s->fsel[48] == 0) /* SD_CLK_R */
-&& (s->fsel[49] == 0) /* SD_CMD_R */
-&& (s->fsel[50] == 0) /* SD_DATA0_R */
-&& (s->fsel[51] == 0) /* SD_DATA1_R */
-&& (s->fsel[52] == 0) /* SD_DATA2_R */
-&& (s->fsel[53] == 0) /* SD_DATA3_R */
-) {
+&& (s->fsel[48] == 0) /* SD_CLK_R */
+&& (s->fsel[49] == 0) /* SD_CMD_R */
+&& (s->fsel[50] == 0) /* SD_DATA0_R */
+&& (s->fsel[51] == 0) /* SD_DATA1_R */
+&& (s->fsel[52] == 0) /* SD_DATA2_R */
+&& (s->fsel[53] == 0) /* SD_DATA3_R */
+) {
 /* SDHCI controller selected */
 sdbus_reparent_card(s->sdbus_sdhost, s->sdbus_sdhci);
 s->sd_fsel = 0;
 } else if (s->sd_fsel != 4
-&& (s->fsel[48] == 4) /* SD_CLK_R */
-&& (s->fsel[49] == 4) /* SD_CMD_R */
-&& (s->fsel[50] == 4) /* SD_DATA0_R */
-&& (s->fsel[51] == 4) /* SD_DATA1_R */
-&& (s->fsel[52] == 4) /* SD_DATA2_R */
-&& (s->fsel[53] == 4) /* SD_DATA3_R */
-) {
+   && (s->fsel[48] == 4) /* SD_CLK_R */
+   && (s->fsel[49] == 4) /* SD_CMD_R */
+   && (s->fsel[50] == 4) /* SD_DATA0_R */
+   && (s->fsel[51] == 4) /* SD_DATA1_R */
+   && (s->fsel[52] == 4) /* SD_DATA2_R */
+   && (s->fsel[53] == 4) /* SD_DATA3_R */
+   ) {
 /* SDHost controller selected */
 sdbus_reparent_card(s->sdbus_sdhci, s->sdbus_sdhost);
 s->sd_fsel = 4;
@@ -108,13 +110,13 @@ static int gpfsel_is_out(BCM2835GpioState *s, int index)
 }
 
 static void gpset(BCM2835GpioState *s,
-uint32_t val, uint8_t start, uint8_t count, uint32_t *lev)
+  uint32_t val, uint8_t start, uint8_t count, uint32_t *lev)
 {
-uint32_t changes = val & ~*lev;
+uint32_t changes = val & ~ *lev;
 uint32_t cur = 1;
 
 int i;
-for (i = 0; i < count; i++) {
+for (i = 0; i < count; i ++) {
 if ((changes & cur) && (gpfsel_is_out(s, start + i))) {
 qemu_set_irq(s->out[start + i], 1);
 }
@@ -125,132 +127,165 @@ static void gpset(BCM2835GpioState *s,
 }
 
 static void gpclr(BCM2835GpioState *s,
-uint32_t val, uint8_t start, uint8_t count, uint32_t *lev)
+  uint32_t val, uint8_t start, uint8_t count, uint32_t *lev)
 {
 uint32_t changes = val & *lev;
 uint32_t cur = 1;
 
 int i;
-for (i = 0; i < count; i++) {
+for (i = 0; i < count; i ++) {
 if ((changes & cur) && (gpfsel_is_out(s, start + i))) {
 qemu_set_irq(s->out[start + i], 0);
 }
 cur <<= 1;
 }
 
-*lev &= ~val;
+*lev &= ~ val;
 }
 
-static uint64_t bcm2835_gpio_read(void *opaque, hwaddr offset,
-unsigned size)
+static 

Re: [Qemu-devel] (no subject)

[gengdongjiu]

Dear James,
   Thanks a lot for your review and comments. I am very sorry for the
late response.


2017-05-04 23:42 GMT+08:00 gengdongjiu :
>  Hi Dongjiu Geng,
>
> On 30/04/17 06:37, Dongjiu Geng wrote:
>> when happen SEA, deliver signal bus and handle the ioctl that
>> inject SEA abort to guest, so that guest can handle the SEA error.
>
>> diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
>> index 105b6ab..a96594f 100644
>> --- a/arch/arm/kvm/mmu.c
>> +++ b/arch/arm/kvm/mmu.c
>> @@ -20,8 +20,10 @@
>> @@ -1238,6 +1240,36 @@ static void coherent_cache_guest_page(struct kvm_vcpu 
>> *vcpu, kvm_pfn_t pfn,
>>   __coherent_cache_guest_page(vcpu, pfn, size);
>>  }
>>
>> +static void kvm_send_signal(unsigned long address, bool hugetlb, bool 
>> hwpoison)
>> +{
>> + siginfo_t info;
>> +
>> + info.si_signo   = SIGBUS;
>> + info.si_errno   = 0;
>> + if (hwpoison)
>> + info.si_code= BUS_MCEERR_AR;
>> + else
>> + info.si_code= 0;
>> +
>> + info.si_addr= (void __user *)address;
>> + if (hugetlb)
>> + info.si_addr_lsb = PMD_SHIFT;
>> + else
>> + info.si_addr_lsb = PAGE_SHIFT;
>> +
>> + send_sig_info(SIGBUS, , current);
>> +}
>> +
> «  [hide part of quote]
>
> Punit reviewed the other version of this patch, this PMD_SHIFT is not the 
> right
> thing to do, it needs a more accurate set of calls and shifts as there may be
> hugetlbfs pages other than PMD_SIZE.
>
> https://www.spinics.net/lists/arm-kernel/msg568919.html
>
> I haven't posted a new version of that patch because I was still hunting a bug
> in the hugepage/hwpoison code, even with Punit's fixes series I see -EFAULT
> returned to userspace instead of this hwpoison code being invoked.

  Ok, got it, thanks for your information.
>
> Please avoid duplicating functionality between patches, it wastes reviewers
> time, especially when we know there are problems with this approach.
>
>
>> +static void kvm_handle_bad_page(unsigned long address,
>> + bool hugetlb, bool hwpoison)
>> +{
>> + /* handle both hwpoison and other synchronous external Abort */
>> + if (hwpoison)
>> + kvm_send_signal(address, hugetlb, true);
>> + else
>> + kvm_send_signal(address, hugetlb, false);
>> +}
>
> Why the extra level of indirection? We only want to signal userspace like this
> from KVM for hwpoison. Signals for RAS related reasons should come from the 
> bits
> of the kernel that decoded the error.

For the SEA, the are maily two types:
0b01 Synchronous External Abort on memory access.
0b0101xx Synchronous External Abort on page table walk. DFSC[1:0]
encode the level.

hwpoison should belong to the  "Synchronous External Abort on memory access"
if the SEA type is not hwpoison, such as page table walk, do you mean
KVM do not deliver the SIGBUS?
If so, how the KVM handle the SEA type other than hwpoison?

>
> (hwpoison for KVM is a corner case as Qemu's memory effectively has two users,
> Qemu and KVM. This isn't the example of how user-space gets signalled.)
>
>
>> diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
>> index b37446a..780e3c4 100644
>> --- a/arch/arm64/kvm/guest.c
>> +++ b/arch/arm64/kvm/guest.c
>> @@ -277,6 +277,13 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu,
>>   return -EINVAL;
>>  }
>>
>> +int kvm_vcpu_ioctl_sea(struct kvm_vcpu *vcpu)
>> +{
>> + kvm_inject_dabt(vcpu, kvm_vcpu_get_hfar(vcpu));
>> +
>> + return 0;
>> +}
>
>> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
>> index bb02909..1d2e2e7 100644
>> --- a/include/uapi/linux/kvm.h
>> +++ b/include/uapi/linux/kvm.h
>> @@ -1306,6 +1306,7 @@ struct kvm_s390_ucas_mapping {
>>  #define KVM_S390_GET_IRQ_STATE  _IOW(KVMIO, 0xb6, struct kvm_s390_irq_state)
>>  /* Available with KVM_CAP_X86_SMM */
>>  #define KVM_SMI   _IO(KVMIO,   0xb7)
>> +#define KVM_ARM_SEA   _IO(KVMIO,   0xb8)
>>
>>  #define KVM_DEV_ASSIGN_ENABLE_IOMMU (1 << 0)
>>  #define KVM_DEV_ASSIGN_PCI_2_3 (1 << 1)
>>
>
> Why do we need a userspace API for SEA? It can also be done by using
> KVM_{G,S}ET_ONE_REG to change the vcpu registers. The advantage of doing it 
> this
> way is you can choose which ESR value to use.
>
> Adding a new API call to do something you could do with an old one doesn't 
> look
> right.

James, I considered your suggestion before that use the
KVM_{G,S}ET_ONE_REG to change the vcpu registers. but I found it does
not have difference to use the alread existed KVM API.  so may be
changing the vcpu registers in qemu will duplicate with the KVM APIs.

injection a SEA is no more than setting some registers: elr_el1, PC,
PSTATE, SPSR_el1, far_el1, esr_el1
I seen this KVM API do the same thing as Qemu.  do you found call this
API will have issue and necessary to choose another ESR value?

I pasted the alread existed KVM API code:

static void inject_abt64(struct kvm_vcpu *vcpu, bool is_iabt, unsigned
long addr)
{
 unsigned long cpsr = *vcpu_cpsr(vcpu);
 bool is_aarch32 = vcpu_mode_is_32bit(vcpu);
 u32 esr = 0;
 *vcpu_elr_el1(vcpu) 

Re: [Qemu-devel] (no subject)

[Eric Blake]

On 03/16/2017 09:50 AM, Vinzenz 'evilissimo' Feenstra wrote:
> In this version:

When sending a v2, it's best to send it as a new top-level thread
instead of burying it in-reply-to an older thread. Also, don't forget
the subject line on the header message.

> 
> - Changed the use of strdup to g_strdup and the use of sprintf with a local
>   buffer to use g_strdup_printf instead.
> - Made the majority of fields in the GuestOSInfo optional to allow 0 values
> - Used the right target version in the schema (2.10 vs 2.8 before)
> - Refactored the code for deciding which release/version file to use to use a
>   configuration struct and a while loop to iterate over the options.
> 
> I was looking into the usage of uname, as suggested by eric, however after
> looking into this I realized that there's no additional information to be
> gained from this. Therefore I decided that this is still a feasible approach.
> In most cases the code will break out of the loop after accessing the second
> file. For older systems there are some supported fallbacks available, but
> /etc/os-release and /usr/lib/os-release are already quite established.
> 
> 

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

[Qemu-devel] (no subject)

[Vinzenz 'evilissimo' Feenstra]

In this version:

- Changed the use of strdup to g_strdup and the use of sprintf with a local
  buffer to use g_strdup_printf instead.
- Made the majority of fields in the GuestOSInfo optional to allow 0 values
- Used the right target version in the schema (2.10 vs 2.8 before)
- Refactored the code for deciding which release/version file to use to use a
  configuration struct and a while loop to iterate over the options.

I was looking into the usage of uname, as suggested by eric, however after
looking into this I realized that there's no additional information to be
gained from this. Therefore I decided that this is still a feasible approach.
In most cases the code will break out of the loop after accessing the second
file. For older systems there are some supported fallbacks available, but
/etc/os-release and /usr/lib/os-release are already quite established.

[Qemu-devel] (no subject)

[Eric Bischoff]

(forgot to CC the list, already sent to Richard Henderson and Alexander Graf)

Re: [Qemu-devel] (no subject)

[Stefan Hajnoczi]

On Mon, Jan 02, 2017 at 09:03:55PM +0900, morgenlette madeBy wrote:
> I got problem using QEMU.
> 
> when i turn on virtual machine,
> 
> this message was shown,
> 
> 
> virsh: error while loading shared libraries: libapparmor.so.1: cannot open
> shared object file: No such file or directory
> 
> I have no idea about libapparmor.
> 
> 
> What should I do?

Hi,
Looks like the libvirt packages do not have all dependencies installed.

If you are using Ubuntu try "apt-get install libapparmor1" to install
the missing library.  I looked up the package that provides the
"libapparmor.so.1" filename here:
http://packages.ubuntu.com/search?searchon=contents=libapparmor.so.1=exactfilename=xenial=any

If you have further questions please try asking for help from your Linux
distribution (e.g. #ubuntu on irc.freenode.net) since this question is
not directly related to QEMU.

Good luck,
Stefan


signature.asc
Description: PGP signature

[Qemu-devel] (no subject)

[morgenlette madeBy]

hello.

I got problem using QEMU.

when i turn on virtual machine,

this message was shown,


virsh: error while loading shared libraries: libapparmor.so.1: cannot open
shared object file: No such file or directory

I have no idea about libapparmor.


What should I do?

Re: [Qemu-devel] (no subject)

[Thomas Huth]

 Hi Christopher,

On 16.11.2016 20:41, Christopher Oliver wrote:
> This patch (hack?) works around the slowness in SEEK_HOLE for large dense 
> files
> on Linux tmpfs.  It may improve life elsewhere as well, and the penalty of 
> the checks
> should be vanishingly small where it is not needed.
> 
> If I'm subtly (or not so subtly) wrong, please fire back.

When submitting QEMU patches, there are some rules to be followed:
First, please have a look at
 http://qemu-project.org/Contribute/SubmitAPatch#Do_not_send_as_an_attachment
and the other paragraphs there.
Your mail should also have a proper subject, and the Signed-off-by line
should contain your e-mail address.

 Thanks,
  Thomas

[Qemu-devel] (no subject)

[Christopher Oliver]

This patch (hack?) works around the slowness in SEEK_HOLE for large dense files
on Linux tmpfs.  It may improve life elsewhere as well, and the penalty of the 
checks
should be vanishingly small where it is not needed.

If I'm subtly (or not so subtly) wrong, please fire back.

Sincerely,

-- 
Christopher Oliver 


qemu-patch
Description: Binary data

[Qemu-devel] (no subject)

[Pradeep Jagadeesh]

Date: Sun, 30 Oct 2016 10:53:16 -0400
Subject: [PATCH V8] fsdev: add IO throttle support to fsdev devices

Uses throttling APIs to limit I/O bandwidth and number of operations on the 
devices which use 9p-local driver.

This adds the support for the 9p-local driver.
For now this functionality can be enabled only through qemu cli options.
QMP interface and support to other drivers need further extensions.
To make it simple for other drivers, the throttle code has been put in
separate files.

Signed-off-by: Pradeep Jagadeesh 
---
 fsdev/Makefile.objs |   2 +-
 fsdev/file-op-9p.h  |   3 +
 fsdev/qemu-fsdev-opts.c |  76 
 fsdev/qemu-fsdev-throttle.c | 139 
 fsdev/qemu-fsdev-throttle.h |  39 +
 hw/9pfs/9p-local.c  |   2 +
 hw/9pfs/9p.c|  10 
 hw/9pfs/cofile.c|   2 +
 8 files changed, 272 insertions(+), 1 deletion(-)
 create mode 100644 fsdev/qemu-fsdev-throttle.c
 create mode 100644 fsdev/qemu-fsdev-throttle.h

v1 -> v2:

-Fixed FsContext redeclaration issue
-Removed couple of function declarations from 9p-throttle.h
-Fixed some of the .help messages

v2 -> v3:

-Addressed follwing comments by Claudio Fontana
 -Removed redundant memset calls in fsdev_throttle_configure_iolimits function
 -Checking throttle structure validity before initializing other structures
  in fsdev_throttle_configure_iolimits

-Addressed following comments by Greg Kurz
 -Moved the code from 9pfs directory to fsdev directory, because the throttling
  is for the fsdev devices.Renamed the files and functions to fsdev_ from 9pfs_
 -Renamed throttling cli options to throttling.*, as in QMP cli options
 -Removed some of the unwanted .h files from qemu-fsdev-throttle.[ch]
 -Using throttle_enabled() function to set the thottle enabled flag for fsdev.

v3 -> v4:

-Addressed following comments by Alberto Garcia
 -Removed the unwanted locking and other data structures in 
qemu-fsdev-throttle.[ch]

-Addressed following comments by Greg Kurz
 -Removed fsdev_iolimitsenable/disable functions, instead using 
throttle_enabled function

v4 -> V5:
 -Fixed the issue with the larger block size accounting.
 (i.e, when the 9pfs mounted using msize=xxx option)

V5 -> V6:
-Addressed the comments by Alberto Garcia
 -Removed the fsdev_throttle_timer_cb()
 -Simplified the  fsdev_throttle_schedule_next_request() as suggested

V6 -> V7:
-Addressed the comments by Alberto Garcia
 -changed the  fsdev_throttle_schedule_next_request() as suggested

v7 -> v8:
-Addressed comments by Alberto Garcia
 -Fixed some indentation issues and split the configure_io_limit function
 -Inlined throttle_timer_check code


diff --git a/fsdev/Makefile.objs b/fsdev/Makefile.objs
index 1b120a4..659df6e 100644
--- a/fsdev/Makefile.objs
+++ b/fsdev/Makefile.objs
@@ -5,7 +5,7 @@ common-obj-y = qemu-fsdev.o 9p-marshal.o 9p-iov-marshal.o
 else
 common-obj-y = qemu-fsdev-dummy.o
 endif
-common-obj-y += qemu-fsdev-opts.o
+common-obj-y += qemu-fsdev-opts.o qemu-fsdev-throttle.o
 
 # Toplevel always builds this; targets without virtio will put it in
 # common-obj-y
diff --git a/fsdev/file-op-9p.h b/fsdev/file-op-9p.h
index 6db9fea..33fe822 100644
--- a/fsdev/file-op-9p.h
+++ b/fsdev/file-op-9p.h
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include "qemu-fsdev-throttle.h"
 
 #define SM_LOCAL_MODE_BITS0600
 #define SM_LOCAL_DIR_MODE_BITS0700
@@ -74,6 +75,7 @@ typedef struct FsDriverEntry {
 char *path;
 int export_flags;
 FileOperations *ops;
+FsThrottle fst;
 } FsDriverEntry;
 
 typedef struct FsContext
@@ -83,6 +85,7 @@ typedef struct FsContext
 int export_flags;
 struct xattr_operations **xops;
 struct extended_ops exops;
+FsThrottle *fst;
 /* fs driver specific data */
 void *private;
 } FsContext;
diff --git a/fsdev/qemu-fsdev-opts.c b/fsdev/qemu-fsdev-opts.c
index 1dd8c7a..395d497 100644
--- a/fsdev/qemu-fsdev-opts.c
+++ b/fsdev/qemu-fsdev-opts.c
@@ -37,6 +37,82 @@ static QemuOptsList qemu_fsdev_opts = {
 }, {
 .name = "sock_fd",
 .type = QEMU_OPT_NUMBER,
+}, {
+.name = "throttling.iops-total",
+.type = QEMU_OPT_NUMBER,
+.help = "limit total I/O operations per second",
+},{
+.name = "throttling.iops-read",
+.type = QEMU_OPT_NUMBER,
+.help = "limit read operations per second",
+},{
+.name = "throttling.iops-write",
+.type = QEMU_OPT_NUMBER,
+.help = "limit write operations per second",
+},{
+.name = "throttling.bps-total",
+.type = QEMU_OPT_NUMBER,
+.help = "limit total bytes per second",
+},{
+.name = "throttling.bps-read",
+.type = QEMU_OPT_NUMBER,
+.help = "limit read bytes per second",
+},{
+.name = 

[Qemu-devel] (no subject)

[Nicholas Piggin]

Date: Thu, 20 Oct 2016 17:38:24 +1100
Subject: [PATCH 0/3] ppc: system reset interrupt fixes and new hcall IPI

Hi,

We are implementing this new unmaskable IPI hcall for crash dumping
and debugging. I had some issues with QEMU delivering system reset
interrupt to guests, which was caused by the HV bit being set. After
changing that, the interrupt was being handled okay. Should there be
a more general check to ensure the HV bit is not set in the guest?

I implemented Linux support for the new hcall in crashdump code, and
it works.

Thanks,
Nick

Nicholas Piggin (3):
  ppc: fix MSR_ME handling for system reset interrupt
  ppc: allow system reset interrupt to be delivered to guests
  ppc/spapr: implement H_SIGNAL_SYS_RESET

 hw/ppc/spapr_hcall.c | 42 ++
 include/hw/ppc/spapr.h   |  8 +++-
 target-ppc/excp_helper.c | 10 +++---
 3 files changed, 56 insertions(+), 4 deletions(-)

-- 
2.9.3

[Qemu-devel] (no subject)

[Neeraj Sharma]

Dear Sir/Ma'am

I want to ‘annotate’ the translation buffers - (adding a mechanism in the
translation buffers where we can store how many times they were executed,
and, for each one, add some ‘amount’ could be power, could be anything). I
need held to understand the translation buffer code in qemu, starts fom
cpu-exec.c.

Neeraj
Thanks

[Qemu-devel] (no subject)

[Shreya Shrivastava]

HI ,

I am interested in applying for Outreachy 2016 December- March round by
contributing to  VIRTIO 1.0 support in libqos project for Qemu.

Kindly let me know how to get started with this project.

Shreya Shrivastava

Re: [Qemu-devel] (no subject)

[Stephen Bates]

Hi Fam

Thanks! Yes gdb provides one approach but I was wondering if there was 
something built in to QEMU monitor.

Another application I can see for this would be to inject errors into the 
memory, This will be useful for testing new NVDIMM-P technology that builds 
NVDIMMs out of material that is less reliable than DRAM...

Cheers

Stephen

> On Sep 12, 2016, at 7:28 PM, Fam Zheng  wrote:
> 
>> On Mon, 09/12 16:23, Stephen Bates wrote:
>> Hi
> 
> Hi Stephen,
> 
>> 
>> I sent this to qemu-discuss with no success so resending to qemu-devel.
>> 
>> I am doing some very low level OS design work and wanted to be able to
>> alter some values in the physical memory of my QEMU guest. I can see quite
>> a few ways to print/dump both physical and virtual addresses but nothing
>> that can alter arbitrary physical/virtual addresses?
>> 
>> Does such a feature exist in Qemu and if it does are there pointers to
>> documentation for it?
> 
> Have you tried the builtin gdbstub in QEMU? You can add "-s" to the QEMU
> command line and then connect to it from gdb with "target remote :1234". There
> you can inspect or change memory more easily.
> 
> Fam
> 
>> 
>> I do see that we can use file backing for very large memory regions via
>> the memory-backing-file option but I am not really trying to alter massive
>> regions of memory in this case.
>> 
>> Cheers
>> 
>> Stephen Bates
>> 

Re: [Qemu-devel] (no subject)

[Fam Zheng]

On Mon, 09/12 16:23, Stephen Bates wrote:
> Hi

Hi Stephen,

> 
> I sent this to qemu-discuss with no success so resending to qemu-devel.
> 
> I am doing some very low level OS design work and wanted to be able to
> alter some values in the physical memory of my QEMU guest. I can see quite
> a few ways to print/dump both physical and virtual addresses but nothing
> that can alter arbitrary physical/virtual addresses?
> 
> Does such a feature exist in Qemu and if it does are there pointers to
> documentation for it?

Have you tried the builtin gdbstub in QEMU? You can add "-s" to the QEMU
command line and then connect to it from gdb with "target remote :1234". There
you can inspect or change memory more easily.

Fam

> 
> I do see that we can use file backing for very large memory regions via
> the memory-backing-file option but I am not really trying to alter massive
> regions of memory in this case.
> 
> Cheers
> 
> Stephen Bates
> 

[Qemu-devel] (no subject)

[Stephen Bates]

Hi

I sent this to qemu-discuss with no success so resending to qemu-devel.

I am doing some very low level OS design work and wanted to be able to
alter some values in the physical memory of my QEMU guest. I can see quite
a few ways to print/dump both physical and virtual addresses but nothing
that can alter arbitrary physical/virtual addresses?

Does such a feature exist in Qemu and if it does are there pointers to
documentation for it?

I do see that we can use file backing for very large memory regions via
the memory-backing-file option but I am not really trying to alter massive
regions of memory in this case.

Cheers

Stephen Bates

[Qemu-devel] (no subject)

[Kumud Bhat]

*Kumud Bhat*
Department of Computer and Information science
Purdue School of Science,IUPUI
Indianapolis-IN, United States

Re: [Qemu-devel] (no subject)

[John Snow]

On 03/21/2016 05:09 PM, Peter Maydell wrote:
> On 21 March 2016 at 18:00, John Snow  wrote:
>> Looks like one of your libraries is outdated, for me
>> 'IBV_LINK_LAYER_INFINIBAND' is defined in
>> /usr/include/infiniband/verbs.h; provided by
>> libibverbs-devel-1.1.8-3.fc22.x86_64.
>>
>> Maybe your libibverbs is too old.
> 
> We should probably add a suitable configure test.
> 
> thanks
> -- PMM
> 

Sure, I don't know formally what our minimum version requirement for
libibverbs is.

In this case at least,
http://git.kernel.org/cgit/libs/infiniband/libibverbs.git/commit/include/infiniband/verbs.h?id=e5df8c64df6877facc045608a25f4d4fecd5f2b0

committed 2011-07-26 20:15:33 (GMT),

so probably:
http://git.kernel.org/cgit/libs/infiniband/libibverbs.git/commit/?id=8b2ffc598bd7f8294f3653cab430146985040739

libibverbs 1.1.6 (December 2011) as a minimum, unless there's an even
newer requirement?

--js

Re: [Qemu-devel] (no subject)

[Peter Maydell]

On 21 March 2016 at 18:00, John Snow  wrote:
> Looks like one of your libraries is outdated, for me
> 'IBV_LINK_LAYER_INFINIBAND' is defined in
> /usr/include/infiniband/verbs.h; provided by
> libibverbs-devel-1.1.8-3.fc22.x86_64.
>
> Maybe your libibverbs is too old.

We should probably add a suitable configure test.

thanks
-- PMM

Re: [Qemu-devel] (no subject)

[John Snow]

On 03/21/2016 04:44 AM, Yunqiang Gao wrote:
> Hi,alls,
> 
>  I compile qemu on ubuntu 12.04,when "make",some error appears.the error:
> 
> migration/rdma.c: In function ‘qemu_rdma_dump_id’:
> migration/rdma.c:738:21: error: ‘struct ibv_port_attr’ has no member
> named ‘link_layer’
> migration/rdma.c:739:22: error: ‘struct ibv_port_attr’ has no member
> named ‘link_layer’
> migration/rdma.c:739:37: error: ‘IBV_LINK_LAYER_INFINIBAND’ undeclared
> (first use in this function)
> migration/rdma.c:739:37: note: each undeclared identifier is reported
> only once for each function it appears in
> migration/rdma.c:740:24: error: ‘struct ibv_port_attr’ has no member
> named ‘link_layer’
> migration/rdma.c:740:39: error: ‘IBV_LINK_LAYER_ETHERNET’ undeclared
> (first use in this function)
> migration/rdma.c: In function ‘qemu_rdma_broken_ipv6_kernel’:
> migration/rdma.c:839:26: error: ‘struct ibv_port_attr’ has no member
> named ‘link_layer’
> migration/rdma.c:839:41: error: ‘IBV_LINK_LAYER_INFINIBAND’ undeclared
> (first use in this function)
> migration/rdma.c:841:33: error: ‘struct ibv_port_attr’ has no member
> named ‘link_layer’
> migration/rdma.c:841:48: error: ‘IBV_LINK_LAYER_ETHERNET’ undeclared
> (first use in this function)
> migration/rdma.c:880:18: error: ‘struct ibv_port_attr’ has no member
> named ‘link_layer’
> make: *** [migration/rdma.o] Error 1
> 
> I have do that: apt-get build-dep qemu.
> 
> when I install Recommended additional packages,two packages can't be
> installed,these are libseccomp-dev,libvdeplug-dev.
> errpr information:
> Reading package lists... Done
> Building dependency tree   
> Reading state information... Done
> E: Unable to locate package libvdeplug-dev
> 
> my linux kernel is 4.4.1.
> 
> Could anybody know how to deal with it?
> 
> Thanks!
> 

If you don't need the RDMA feature, you could always just --disable-rdma
for now to see if you can get QEMU to build.

Looks like one of your libraries is outdated, for me
'IBV_LINK_LAYER_INFINIBAND' is defined in
/usr/include/infiniband/verbs.h; provided by
libibverbs-devel-1.1.8-3.fc22.x86_64.

Maybe your libibverbs is too old.

--js

[Qemu-devel] (no subject)

[Yunqiang Gao]

Hi,alls,

 I compile qemu on ubuntu 12.04,when "make",some error appears.the error:

migration/rdma.c: In function ‘qemu_rdma_dump_id’:
migration/rdma.c:738:21: error: ‘struct ibv_port_attr’ has no member named
‘link_layer’
migration/rdma.c:739:22: error: ‘struct ibv_port_attr’ has no member named
‘link_layer’
migration/rdma.c:739:37: error: ‘IBV_LINK_LAYER_INFINIBAND’ undeclared
(first use in this function)
migration/rdma.c:739:37: note: each undeclared identifier is reported only
once for each function it appears in
migration/rdma.c:740:24: error: ‘struct ibv_port_attr’ has no member named
‘link_layer’
migration/rdma.c:740:39: error: ‘IBV_LINK_LAYER_ETHERNET’ undeclared (first
use in this function)
migration/rdma.c: In function ‘qemu_rdma_broken_ipv6_kernel’:
migration/rdma.c:839:26: error: ‘struct ibv_port_attr’ has no member named
‘link_layer’
migration/rdma.c:839:41: error: ‘IBV_LINK_LAYER_INFINIBAND’ undeclared
(first use in this function)
migration/rdma.c:841:33: error: ‘struct ibv_port_attr’ has no member named
‘link_layer’
migration/rdma.c:841:48: error: ‘IBV_LINK_LAYER_ETHERNET’ undeclared (first
use in this function)
migration/rdma.c:880:18: error: ‘struct ibv_port_attr’ has no member named
‘link_layer’
make: *** [migration/rdma.o] Error 1

I have do that: apt-get build-dep qemu.

when I install Recommended additional packages,two packages can't be
installed,these are libseccomp-dev,libvdeplug-dev.
errpr information:
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package libvdeplug-dev

my linux kernel is 4.4.1.

Could anybody know how to deal with it?

Thanks!

[Qemu-devel] (no subject)

[Liang Li]

Subject: [PATCH RESEND v2 0/2] Fix flaw of qemu_put_compression_data

The implementation of qemu_put_compression_data only consider the case
QEMUFile is writable, it can't work with a writable QEMUFile and does
not provide any measure to prevent users from using it with a writable
QEMUFile. For safety, it should be improved to avoid some issues.

ram_save_compressed_page can be refined based on the change of
qemu_put_compression_data, very small improvement, but code looks better.

Liang Li (2):
  qemu-file: Fix qemu_put_compression_data flaw
  migration: refine ram_save_compressed_page

 migration/qemu-file.c | 23 +--
 migration/ram.c   | 20 
 2 files changed, 29 insertions(+), 14 deletions(-)

-- 
1.9.1

[Qemu-devel] (no subject)

[Christoph Hellwig]

From: Christoph Hellwig 
Subject: a nasty nvme fix
In-Reply-To: 

Hi all,

below is a fix for a bug in the qemu NVMe identify implementation that's
causing us some trouble with an updated Linux driver.  We'll have to
blacklist the existing Qemu device ID for it, so I wonder how we can
advertize a fixed controller.  Maybe a new PCI ID?  Or maybe just bump
the PCI revision, altough that would be a bit more complicated in the
driver.

Re: [Qemu-devel] (no subject)

[Paolo Bonzini]

On 17/11/2015 14:08, Christoph Hellwig wrote:
> below is a fix for a bug in the qemu NVMe identify implementation that's
> causing us some trouble with an updated Linux driver.  We'll have to
> blacklist the existing Qemu device ID for it, so I wonder how we can
> advertize a fixed controller.  Maybe a new PCI ID?  Or maybe just bump
> the PCI revision, altough that would be a bit more complicated in the
> driver.

Bumping the PCI revision would be ideal, but I guess the PCI ID would
work too if it's really that bad.

Paolo

[Qemu-devel] (no subject)

[Pankaj Gupta]

Subject: [PATCH 0/2 v2] virtio-rng: Avoid uncessary timer trigger to bump up 
quota value 

Timer was added in virtio-rng to rate limit the
entropy. It used to trigger at regular intervals to
bump up the quota value. The value of quota and timer
is used to ensure single guest should not use up all the 
entropy from the host.
This resulted in triggering of timer even when quota
is not exhausted at all and resulting in extra processing.

This series has two patches:

patch1 : Bump up quota value only when guest requests entropy.
patch2 : Serve pending request if any after timer bumps up quota.

Changes from v1:
Amit Shah : 
Serve pending request if any after timer bumps up quota.
Add testing details.

I tested this with '/dev/urandom' at host side. Below are the details:

* Quota+timer specified on command line, 
  Ran in Guest 'dd if=/dev/hwrng of=/dev/null'
  
  - Quota (4096 bytes), Time slice (1000 ms)

48152 bytes (49 KB) copied, 12.0005 s, 4.1 kB/s
48640 bytes (49 KB) copied, 12.0014 s, 4.1 kB/s

  - Quota (8192), Time slice (1000 ms)
65536 bytes  (66 KB) copied, 8.00088 s, 8.2 kB/s
146944 bytes (147 KB)copied, 18.0021 s, 8.2 kB/s

  - No quota/timer specified on command line, takes default values.
Quota (INT64_MAX), Time slice(65536 ms)
8050688 bytes (8.1 MB) copied, 93.1198 s, 86.5 kB/s
35568128 bytes (36 MB) copied, 408.823 s, 87.0 kB/s


 hw/virtio/virtio-rng.c |   51 +
 include/hw/virtio/virtio-rng.h |1 
 2 files changed, 33 insertions(+), 19 deletions(-)

[Qemu-devel] (no subject)

[Denis V. Lunev]

The monivation of this set is simple. Recently we have proposed patch
to monitor.c with specific x86 APIC HMP commands. The patchset was denied
with the main motivation No more arch specific code in monitor.c
This patchset is the first step to move arch specific code from
monitor.c targets.

So, monitor.c already contains a lot of generic code, as well as the target
specifics code and eventually monitor.c volume will only grow. This trend leads
to a variety of fouling code ifdeffery(and combinations thereof),
poor readability, and entanglement of architecture of the project.
If someone wants to improve processing logic commands at the monitor,
it isn't necessarily must differentiate amongst the implementation of some ARM
or x86_64 specific commands, because the project already has separation of
target specific code on directories.

The presented solution is not the best, but it is quite simple
(PATCH doesn't add more code!) and decides the above mentioned issue.
Subsequently it will not prevent the introduction of more advanced mechanism
that can more effectively resolve the issue.

There is a issue with the placement of code for multiple architectures
(isn't for everyone), but this code is very small. This patch is a step towards
solving the issue associated with maintaining the purity of the code and
structure of the project, which solves not all, but doing a little better
than it is.

Signed-off-by: Pavel Butsykin pbutsy...@virtuozzo.com
Signed-off-by: Denis V. Lunev d...@openvz.org
CC: Luiz Capitulino lcapitul...@redhat.com
CC: Paolo Bonzini pbonz...@redhat.com
CC: Peter Maydell peter.mayd...@linaro.org

Pavel Butsykin (3):
  hmp-commands-info: move info_cmds content out of monitor.c
  monitor: remove target-specific code from monitor.c
  monitor: added generation of documentation for  hmp-commands-info.hx

 .gitignore   |1 +
 Makefile |9 +-
 Makefile.target  |5 +-
 hmp-commands-info.hx |  715 ++
 hmp-commands.hx  |  120 
 include/monitor/monitor-common.h |   43 ++
 monitor.c| 1227 +-
 qemu-doc.texi|2 +
 target-i386/Makefile.objs|2 +-
 target-i386/monitor.c|  489 +++
 target-ppc/Makefile.objs |2 +-
 target-ppc/monitor.c |  250 
 target-sh4/Makefile.objs |1 +
 target-sh4/monitor.c |   52 ++
 target-sparc/Makefile.objs   |2 +-
 target-sparc/monitor.c   |  153 +
 target-xtensa/Makefile.objs  |1 +
 target-xtensa/monitor.c  |   34 ++
 18 files changed, 1762 insertions(+), 1346 deletions(-)
 create mode 100644 hmp-commands-info.hx
 create mode 100644 include/monitor/monitor-common.h
 create mode 100644 target-i386/monitor.c
 create mode 100644 target-ppc/monitor.c
 create mode 100644 target-sh4/monitor.c
 create mode 100644 target-sparc/monitor.c
 create mode 100644 target-xtensa/monitor.c

Re: [Qemu-devel] (no subject)

[Fam Zheng]

On Tue, 06/30 00:49, Scott Feldman wrote:
 Hi Fam, Stefan,
 
 I'm running a test with rocker device using UDP sockets connections
 and I'm seeing the socket s-read_poll stay disabled if the device
 receives a packet when the device's can_receive returns false.
 Receive is stuck after that; nothing ever re-enables s-read_poll.  I
 see the first packet queued on queue-packets and that's it.   No more
 receives.  If I modify the device to lie and always return
 can_receive=true, and drop the pkt in driver receive, then things work
 fine.
 
 I think this patch broke can_receive semantics for net/socket.c:

Yes. The semantics now is if .can_receive returns false, the NIC needs to flush
the queue explicitly when the conditions in .can_receive become true, because
net/{socket,tap,...} no longer polls .can_receive().
 
 commit 6e99c631f116221d169ea53953d91b8aa74d297a
 Author: Fam Zheng f...@redhat.com
 Date:   Thu Jun 4 14:45:16 2015 +0800
 
 net/socket: Drop net_socket_can_send
 
 Anything jump out?
 
 (In the test, rocker device is enabling the netdev port once the guest
 OS driver signals to enable the port based on STP process running on
 the guest.  The initial STP state is DISABLED, so the port is isolated
 from the network.  As STP algo progresses, the port is opened up and
 the netdev is enabled for Rx traffic).
 
 -scott
 

Does dropping .can_receive or forcing 1 work for you? Or maybe something like
this:

diff --git a/hw/net/rocker/rocker_fp.c b/hw/net/rocker/rocker_fp.c
index d8d934c..3209ccd 100644
--- a/hw/net/rocker/rocker_fp.c
+++ b/hw/net/rocker/rocker_fp.c
@@ -203,6 +203,7 @@ void fp_port_enable(FpPort *port)
 fp_port_set_link(port, true);
 port-enabled = true;
 DPRINTF(port %d enabled\n, port-index);
+qemu_flush_queued_packets(qemu_get_queue(port-nic));
 }
 
 void fp_port_disable(FpPort *port)

---

Fam

Re: [Qemu-devel] (no subject)

[Scott Feldman]

On Tue, Jun 30, 2015 at 3:18 AM, Fam Zheng f...@redhat.com wrote:
 On Tue, 06/30 00:49, Scott Feldman wrote:
 Hi Fam, Stefan,

 I'm running a test with rocker device using UDP sockets connections
 and I'm seeing the socket s-read_poll stay disabled if the device
 receives a packet when the device's can_receive returns false.
 Receive is stuck after that; nothing ever re-enables s-read_poll.  I
 see the first packet queued on queue-packets and that's it.   No more
 receives.  If I modify the device to lie and always return
 can_receive=true, and drop the pkt in driver receive, then things work
 fine.

 I think this patch broke can_receive semantics for net/socket.c:

 Yes. The semantics now is if .can_receive returns false, the NIC needs to 
 flush
 the queue explicitly when the conditions in .can_receive become true, because
 net/{socket,tap,...} no longer polls .can_receive().

Ah, that makes sense.

 commit 6e99c631f116221d169ea53953d91b8aa74d297a
 Author: Fam Zheng f...@redhat.com
 Date:   Thu Jun 4 14:45:16 2015 +0800

 net/socket: Drop net_socket_can_send

 Anything jump out?

 (In the test, rocker device is enabling the netdev port once the guest
 OS driver signals to enable the port based on STP process running on
 the guest.  The initial STP state is DISABLED, so the port is isolated
 from the network.  As STP algo progresses, the port is opened up and
 the netdev is enabled for Rx traffic).

 -scott


 Does dropping .can_receive or forcing 1 work for you? Or maybe something like
 this:

Dropping .can_receive works.  Actually, we really don't want any pkts
queued when the device port is disabled, otherwise when the port
transitions to enabled, we'll receive stale network pkts.  This would
be bad for a switch device.  So I think this is a happy outcome:
removing .can_receive prevents pkt queuing on the backend, and the
.receive handler can eat the pkt if the port is disabled.  I'll send a
rocker patch to fix this.  Thanks Fam.

-scott

[Qemu-devel] (no subject)

[Scott Feldman]

Hi Fam, Stefan,

I'm running a test with rocker device using UDP sockets connections
and I'm seeing the socket s-read_poll stay disabled if the device
receives a packet when the device's can_receive returns false.
Receive is stuck after that; nothing ever re-enables s-read_poll.  I
see the first packet queued on queue-packets and that's it.   No more
receives.  If I modify the device to lie and always return
can_receive=true, and drop the pkt in driver receive, then things work
fine.

I think this patch broke can_receive semantics for net/socket.c:

commit 6e99c631f116221d169ea53953d91b8aa74d297a
Author: Fam Zheng f...@redhat.com
Date:   Thu Jun 4 14:45:16 2015 +0800

net/socket: Drop net_socket_can_send

Anything jump out?

(In the test, rocker device is enabling the netdev port once the guest
OS driver signals to enable the port based on STP process running on
the guest.  The initial STP state is DISABLED, so the port is isolated
from the network.  As STP algo progresses, the port is opened up and
the netdev is enabled for Rx traffic).

-scott

[Qemu-devel] (no subject)

[yhindin]

Hi

Recently, I've submitted patches to QEMU mailing list, introducing
creation of Windows MSI installation package for Windows QEMU Guest Agent,
but received not replies. Please, look into the suggested changes.

The patches may be found in patchwork as
http://patchwork.ozlabs.org/patch/464618-464622

Regards,
Yossi Hindin

[Qemu-devel] (no subject)

[yhindin]

Hi

Recently, I've submitted patches to QEMU mailing list, introducing
creation of Windows MSI installation package for Windows QEMU Guest Agent,
but received not replies. Please, look into the suggested changes.

The patches may be found in patchwork as
http://patchwork.ozlabs.org/patch/464618-464622

Regards,
Yossi Hindin

[Qemu-devel] (no subject)

[yhindin]

Hi

Recently, I've submitted patches to QEMU mailing list, introducing
creation of Windows MSI installation package for Windows QEMU Guest Agent,
but received not replies. Please, look into the suggested changes.

The patches may be found in patchwork as
http://patchwork.ozlabs.org/patch/464618-464622

Regards,
Yossi Hindin

[Qemu-devel] (no subject)

[yhindin]

Hi

Recently, I've submitted patches to QEMU mailing list, introducing
creation of Windows MSI installation package for Windows QEMU Guest Agent,
but received not replies. Please, look into the suggested changes.

The patches may be found in patchwork as
http://patchwork.ozlabs.org/patch/464618-464622

Regards,
Yossi Hindin

[Qemu-devel] (no subject)

[yhindin]

Hi

Recently, I've submitted patches to QEMU mailing list, introducing
creation of Windows MSI installation package for Windows QEMU Guest Agent,
but received not replies. Please, look into the suggested changes.

The patches may be found in patchwork as
http://patchwork.ozlabs.org/patch/464618-464622

Regards,
Yossi Hindin

[Qemu-devel] (no subject)

[Sunil Kumar]

Hi,

I ran into an issue where the OVA created from the VMDK file created by 
qemu-img is rejected by vSphere with a message like Not a supported disk 
format (sparse VMDK too old). I was looking through the archives and found 
this:

http://lists.gnu.org/archive/html/qemu-devel/2014-08/msg01028.html

That's exactly my issue and the patch will resolve it. But this patch has not 
been merged yet and it does not apply on top of 2.2.0 cleanly. Any ideas what 
happened to the patch there?

I will appreciate any help.

-devsk 

[Qemu-devel] (no subject)

[Jun Li]

stefa...@redhat.com
Bcc: 
Subject: Re: [Qemu-devel] qcow2: Can create qcow2 image format on rbd server
Reply-To: 
In-Reply-To: 5481e4e7.9010...@redhat.com

On Fri, 12/05 18:01, Max Reitz wrote:
 On 2014-12-05 at 16:32, Jun Li wrote:
 Currently, qemu-img can not create qcow2 image format on rbd server. Analysis
 the code as followings:
 when create qcow2 format image:
 qcow2_create2
bdrv_create_file(filename, opts, local_err);  -- Here will create a 0 
  size
file(e.g: file1) on rbd server.
...
ret = bdrv_pwrite(bs, 0, header, cluster_size); -- So here can not write
qcow2 header into file1 due to the file1's length is 0. Seems
qemu_rbd_aio_writev can not write beyond EOF.
...
 
 As above analysis, there are two methods to solve the above bz as followings:
 1, When create file1, just create a fixed-size file1 on rbd server(not 0 
 size).
 
 Should be possible by using -o preallocation=falloc or -o
 preallocation=full.

Sure. If bdrv_create_file(filename, opts, local_err) create a fixed-size(not
0 size) just as using preallocation=falloc or preallocation=full, it will
create a fixed-size file on rbd server. So it won't exist above issue.

 
 I can't say a lot about making rbd growable because I know near to nothing
 about rbd; but there are protocols which really simply don't support writes
 beyond the end of file, and where that's intended (for instance, while nbd
 somehow does support it when using the qemu nbd server, normally (strictly
 according to the protocol) it does not); so for these protocols, you have to
 use a preallocated image file or an image format which does not grow on
 writes (such as raw).
 

Here just want to use rbd_resize to realize rbd growable.

 Of course, while that may be a solution for nbd, it doesn't sound like a
 good solution for rbd, so writes beyond the EOF should probably be supported
 there (although once again, I don't know rbd well enough to judge that).
 

Yes, you are right. Also talked with stefan. Here just want to ask Josh Durgin
whether it has other solutions or rbd can support asynchronous rbd_resize.

Regards,
Jun Li

 
 2, When write the qcow2 header into file1, just let qemu_rbd_aio_writev can
 enlarge the file1. So should add qemu_rbd_truncate inside 
 qemu_rbd_aio_writev.
 qemu_rbd_truncate will call rbd_resize, but seems rbd_resize is
 synchronous function. If so, when do bdrv_pwrite, guest will hang.This is not
 our expected.
 
 For method 1, maybe it's not corresponding to the original principle of 
 qcow2.
 Yes, it's very easy to solve the above bz. Nevertheless, I just want to use
 method 2 to solve above issue.
 
 For method 2, could anyone give some suggestions on howto realize a
 asynchronous rbd_resize. Thanks.
 
 Above analysis also based on stefan's hints. Thanks.
 
 Best Regards,
 Jun Li
 

[Qemu-devel] (no subject)

[xubin yan]

hello

[Qemu-devel] (no subject)

[Priyanka Ranjan]

Hello Experts,
I am using CentOS 6.5. I am getting an issue with libguestfs (qemu-kvm)

 #  /usr/libexec/qemu-kvm -nographic -machine accel=kvm:tcg -device \?

 open /dev/kvm: No such file or directory
 failed to initialize KVM: Operation not permitted
 Back to tcg accelerator.
 Could not allocate dynamic translator buffer

I saw this issue listed in libguestfs faq  
http://libguestfs.org/guestfs-faq.1.html;  and executed
 setsebool -P virt_use_execmem=on  as a solution but  that also did not
help. I confirmed this solution with libguestfs mailing list. They asked me
to to write to you. Could you please help me.

Thanks a lot in advance,

[Qemu-devel] (no subject)

[Puneet Bakshi]

Hi,

I want to be able to install RPM packages (available in host system at some
path) to the online guest VM and want this facility to be available as a
tool.

I am thinking of having a gemu guest agent (qemu-ga) running inside guest
VM. I did not find any available command (virsh qemu-agent-command
guest_vm ...) which can do the same.

I am planning to implement a command in qemu guest agent, which I can
invoke from virsh like below.

virsh qemu-agent-command vm_01  \
'{execute:guest-rpm-
install, \
  arguments:{path:/usr/local/bin/ABC.rpm}}

I am able to pass arguments from host to guest VM but how am I supposed to
pass the whole RPM image from host to guest (which the guest agent can
receive and install)?

Basically, I want to know how can we do following in QEMU environment.

1. take some bulky file from host to guest
2. perform some operation on that file
3. get the result of that operation.

Regards,
~Puneet

[Qemu-devel] (no subject)

[Alex Zuepke]

Put qemu-devel on CC

[Qemu-devel] (no subject)

[Michael S. Tsirkin]

On Thu, Nov 21, 2013 at 09:33:22PM +0200, Marcel Apfelbaum wrote:
 Ensure more then one instance of test_data may exist
 at a given time. It will help to compare different
 acpi table versions.
 
 Signed-off-by: Marcel Apfelbaum marce...@redhat.com

Applied, thanks.

 ---
  tests/acpi-test.c | 55 
 ---
  1 file changed, 32 insertions(+), 23 deletions(-)
 
 diff --git a/tests/acpi-test.c b/tests/acpi-test.c
 index 43775cd..ca83b1d 100644
 --- a/tests/acpi-test.c
 +++ b/tests/acpi-test.c
 @@ -34,7 +34,7 @@ typedef struct {
  uint32_t *rsdt_tables_addr;
  int rsdt_tables_nr;
  AcpiSdtTable dsdt_table;
 -AcpiSdtTable *ssdt_tables;
 +GArray *ssdt_tables;
  } test_data;
  
  #define LOW(x) ((x)  0xff)
 @@ -118,6 +118,18 @@ static uint8_t boot_sector[0x200] = {
  
  static const char *disk = tests/acpi-test-disk.raw;
  
 +static void free_test_data(test_data *data)
 +{
 +int i;
 +
 +g_free(data-rsdt_tables_addr);
 +for (i = 0; i  data-ssdt_tables-len; ++i) {
 +g_free(g_array_index(data-ssdt_tables, AcpiSdtTable, i).aml);
 +}
 +g_array_free(data-ssdt_tables, false);
 +g_free(data-dsdt_table.aml);
 +}
 +
  static uint8_t acpi_checksum(const uint8_t *data, int len)
  {
  int i;
 @@ -295,30 +307,30 @@ static void test_acpi_dsdt_table(test_data *data)
  
  static void test_acpi_ssdt_tables(test_data *data)
  {
 -AcpiSdtTable *ssdt_tables;
 +GArray *ssdt_tables;
  int ssdt_tables_nr = data-rsdt_tables_nr - 1; /* fadt is first */
  int i;
  
 -ssdt_tables = g_new0(AcpiSdtTable, ssdt_tables_nr);
 +ssdt_tables = g_array_sized_new(false, true, sizeof(AcpiSdtTable),
 +ssdt_tables_nr);
  for (i = 0; i  ssdt_tables_nr; i++) {
 -AcpiSdtTable *ssdt_table = ssdt_tables[i];
 +AcpiSdtTable ssdt_table;
  uint32_t addr = data-rsdt_tables_addr[i + 1]; /* fadt is first */
 -
 -test_dst_table(ssdt_table, addr);
 +test_dst_table(ssdt_table, addr);
 +g_array_append_val(ssdt_tables, ssdt_table);
  }
  data-ssdt_tables = ssdt_tables;
  }
  
 -static void test_acpi_one(const char *params)
 +static void test_acpi_one(const char *params, test_data *data)
  {
  char *args;
  uint8_t signature_low;
  uint8_t signature_high;
  uint16_t signature;
  int i;
 -test_data data;
  
 -memset(data, 0, sizeof(data));
 +memset(data, 0, sizeof(*data));
  args = g_strdup_printf(-net none -display none %s %s,
 params ? params : , disk);
  qtest_start(args);
 @@ -342,20 +354,13 @@ static void test_acpi_one(const char *params)
  }
  g_assert_cmphex(signature, ==, SIGNATURE);
  
 -test_acpi_rsdp_address(data);
 -test_acpi_rsdp_table(data);
 -test_acpi_rsdt_table(data);
 -test_acpi_fadt_table(data);
 +test_acpi_rsdp_address(data);
 +test_acpi_rsdp_table(data);
 +test_acpi_rsdt_table(data);
 +test_acpi_fadt_table(data);
  test_acpi_facs_table(data);
 -test_acpi_dsdt_table(data);
 -test_acpi_ssdt_tables(data);
 -
 -g_free(data.rsdt_tables_addr);
 -for (i = 0; i  (data.rsdt_tables_nr - 1); ++i) {
 -g_free(data.ssdt_tables[i].aml);
 -}
 -g_free(data.ssdt_tables);
 -g_free(data.dsdt_table.aml);
 +test_acpi_dsdt_table(data);
 +test_acpi_ssdt_tables(data);
  
  qtest_quit(global_qtest);
  g_free(args);
 @@ -363,10 +368,14 @@ static void test_acpi_one(const char *params)
  
  static void test_acpi_tcg(void)
  {
 +test_data data;
 +
  /* Supplying -machine accel argument overrides the default (qtest).
   * This is to make guest actually run.
   */
 -test_acpi_one(-machine accel=tcg);
 +test_acpi_one(-machine accel=tcg, data);
 +
 +free_test_data(data);
  }
  
  int main(int argc, char *argv[])
 -- 
 1.8.3.1

[Qemu-devel] (no subject)

[Liu, Jinsong]

From 1273f8b2e5464ec987facf9942fd3ccc0b69087e Mon Sep 17 00:00:00 2001
From: Liu Jinsong jinsong@intel.com
Date: Mon, 19 Aug 2013 09:33:30 +0800
Subject: [PATCH] qemu-kvm bugfix for IA32_FEATURE_CONTROL

This patch is to fix the bug https://bugs.launchpad.net/qemu-kvm/+bug/1207623

IA32_FEATURE_CONTROL is pointless if not expose VMX or SMX bits to
cpuid.1.ecx of vcpu. Current qemu-kvm will error return when kvm_put_msrs
or kvm_get_msrs.

Signed-off-by: Liu Jinsong jinsong@intel.com
---
 target-i386/kvm.c |   16 ++--
 1 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index 84ac00a..7facbfe 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -65,6 +65,7 @@ static bool has_msr_star;
 static bool has_msr_hsave_pa;
 static bool has_msr_tsc_adjust;
 static bool has_msr_tsc_deadline;
+static bool has_msr_feature_control;
 static bool has_msr_async_pf_en;
 static bool has_msr_pv_eoi_en;
 static bool has_msr_misc_enable;
@@ -644,6 +645,11 @@ int kvm_arch_init_vcpu(CPUState *cs)
 
 qemu_add_vm_change_state_handler(cpu_update_state, env);
 
+c = cpuid_find_entry(cpuid_data.cpuid, 1, 0);
+if (c)
+has_msr_feature_control = !!(c-ecx  CPUID_EXT_VMX) |
+  !!(c-ecx  CPUID_EXT_SMX);
+
 cpuid_data.cpuid.padding = 0;
 r = kvm_vcpu_ioctl(cs, KVM_SET_CPUID2, cpuid_data);
 if (r) {
@@ -1121,7 +1127,10 @@ static int kvm_put_msrs(X86CPU *cpu, int level)
 if (hyperv_vapic_recommended()) {
 kvm_msr_entry_set(msrs[n++], HV_X64_MSR_APIC_ASSIST_PAGE, 0);
 }
-kvm_msr_entry_set(msrs[n++], MSR_IA32_FEATURE_CONTROL, 
env-msr_ia32_feature_control);
+if (has_msr_feature_control) {
+kvm_msr_entry_set(msrs[n++], MSR_IA32_FEATURE_CONTROL,
+  env-msr_ia32_feature_control);
+}
 }
 if (env-mcg_cap) {
 int i;
@@ -1346,7 +1355,9 @@ static int kvm_get_msrs(X86CPU *cpu)
 if (has_msr_misc_enable) {
 msrs[n++].index = MSR_IA32_MISC_ENABLE;
 }
-msrs[n++].index = MSR_IA32_FEATURE_CONTROL;
+if (has_msr_feature_control) {
+msrs[n++].index = MSR_IA32_FEATURE_CONTROL;
+}
 
 if (!env-tsc_valid) {
 msrs[n++].index = MSR_IA32_TSC;
@@ -1447,6 +1458,7 @@ static int kvm_get_msrs(X86CPU *cpu)
 break;
 case MSR_IA32_FEATURE_CONTROL:
 env-msr_ia32_feature_control = msrs[i].data;
+break;
 default:
 if (msrs[i].index = MSR_MC0_CTL 
 msrs[i].index  MSR_MC0_CTL + (env-mcg_cap  0xff) * 4) {
-- 
1.7.1


0001-qemu-kvm-bugfix-for-IA32_FEATURE_CONTROL.patch
Description: 0001-qemu-kvm-bugfix-for-IA32_FEATURE_CONTROL.patch

[Qemu-devel] (no subject)

[John Baboval]

Thanks for the feedback. I've made the maxqdepth parameter optional as 
requested.

Re: [Qemu-devel] (no subject)

[Stefan Hajnoczi]

On Tue, Apr 02, 2013 at 12:02:52PM -0400, Elizabeth Brown wrote:
 I was wondering if anyone could help me by setting up a wiki account for me?

Done.

Stefan

[Qemu-devel] (no subject)

[Elizabeth Brown]

I was wondering if anyone could help me by setting up a wiki account for me?

thank you very much for your assistance!

Elizabeth Brown

[Qemu-devel] (no subject)

[Michael Tokarev]

---
v2: change __FUNCTION__ to __func__ according to qemu coding style

[Qemu-devel] (no subject)

[Stefan Priebe]

From Stefan Priebe s.pri...@profihost.ag # This line is ignored.
From: Stefan Priebe s.pri...@profihost.ag
Cc: pve-de...@pve.proxmox.com
Cc: pbonz...@redhat.com
Cc: ceph-de...@vger.kernel.org
Subject: QEMU/PATCH: rbd block driver: fix race between completition and cancel
In-Reply-To:


ve-de...@pve.proxmox.com
pbonz...@redhat.com
ceph-de...@vger.kernel.org

[Qemu-devel] (no subject)

[Guan Xuetao]

are available in the git repository at:

  git://github.com/gxt/QEMU.git unicore32

Andreas Färber (1):
  target-unicore32: Drop UC32_CPUID macros

Guan Xuetao (13):
  unicore32-softmmu: Add unicore32-softmmu build support
  unicore32-softmmu: Add coprocessor 0(sysctrl) and 1(ocd) instruction 
support
  unicore32-softmmu: Make UniCore32 cpuid  exceptions correct and runable
  unicore32-softmmu: Implement softmmu specific functions
  unicore32-softmmu: Make sure that kernel can access user space
  unicore32-softmmu: Add puv3 soc/board support
  unicore32-softmmu: Add puv3 interrupt support
  unicore32-softmmu: Add puv3 ostimer support
  unicore32-softmmu: Add puv3 gpio support
  unicore32-softmmu: Add puv3 pm support
  unicore32-softmmu: Add puv3 dma support
  unicore32-softmmu: Add ps2 support
  unicore32-softmmu: Add maintainer information for UniCore32 machine

 MAINTAINERS   |8 +
 arch_init.c   |2 +
 arch_init.h   |1 +
 configure |1 +
 cpu-exec.c|1 +
 default-configs/unicore32-softmmu.mak |4 +
 hw/Makefile.objs  |7 +
 hw/puv3.c |  130 
 hw/puv3.h |   49 ++
 hw/puv3_dma.c |  109 +
 hw/puv3_gpio.c|  141 +
 hw/puv3_intc.c|  135 +
 hw/puv3_ost.c |  151 +++
 hw/puv3_pm.c  |  149 ++
 hw/unicore32/Makefile.objs|6 +
 linux-user/main.c |3 +-
 target-unicore32/Makefile.objs|2 +-
 target-unicore32/cpu.c|   19 ++-
 target-unicore32/cpu.h|   18 +--
 target-unicore32/helper.c |  180 ++
 target-unicore32/helper.h |   17 +--
 target-unicore32/machine.c|   23 +++
 target-unicore32/op_helper.c  |   44 ++-
 target-unicore32/softmmu.c|  267 +
 target-unicore32/translate.c  |  116 +--
 25 files changed, 1509 insertions(+), 74 deletions(-)
 create mode 100644 default-configs/unicore32-softmmu.mak
 create mode 100644 hw/puv3.c
 create mode 100644 hw/puv3.h
 create mode 100644 hw/puv3_dma.c
 create mode 100644 hw/puv3_gpio.c
 create mode 100644 hw/puv3_intc.c
 create mode 100644 hw/puv3_ost.c
 create mode 100644 hw/puv3_pm.c
 create mode 100644 hw/unicore32/Makefile.objs
 create mode 100644 target-unicore32/machine.c
 create mode 100644 target-unicore32/softmmu.c

[Qemu-devel] (no subject)

[César]

Hello there,

Consider I`ve an apllication A executing in linux-user mode. How can
I monitor the execution of some instructions from A? For example, all
calls. I thought inserting an interrupt before all calls and creating
a new interrupt handler could do the job, but I can´t get it working.
Any ideas on this?

César.

[Qemu-devel] (no subject)

[David Gibson]

These are patches that I've sent in before but don't seem to have been
picked up by anybody yet.  Resending so they don't fall off the radar.
1, 2, and 3 of 4 in particular fix real, observed bugs on powerpc.

[Qemu-devel] (no subject)

[Fred Oliveira]

Re: [Qemu-devel] (no subject)

[Stefan Hajnoczi]

On Mon, Dec 12, 2011 at 08:50:39PM -0600, Erik Lotspeich wrote:
 Hi,
 
 I posted this on qemu-discuss and didn't receive any replies; sorry
 for posting it twice.
 
 I have OpenSUSE 12.1 and I have a 64-bit Windows 7 VM that recognizes
 the emulated ICH6 sound (HDA audio device).  Although Windows
 recognizes this sound device just fine, there is no sound from the
 Windows 7 VM.  Sound works fine in KDE and from all other applications
 on the Linux side.  I would appreciate any ideas or help?

Please post your QEMU command-line (you can find it with ps aux | grep
qemu).

If you are running through libvirt/virsh/virt-manager there may be
permission requirements since the guest can be set to run as an
unprivileged user without access to audio devices.   That's just a guess
but worth looking into.

Stefan

Re: [Qemu-devel] (no subject)

[Erik Lotspeich]

On Tue, Dec 13, 2011 at 2:06 AM, Stefan Hajnoczi stefa...@gmail.com wrote:
 Please post your QEMU command-line (you can find it with ps aux | grep
 qemu).

 If you are running through libvirt/virsh/virt-manager there may be
 permission requirements since the guest can be set to run as an
 unprivileged user without access to audio devices.   That's just a guess
 but worth looking into.

Here's my qemu command line:

qemu  5294 19.6 25.7 2444808 2101252 ? Sl   06:47   1:00
/usr/bin/qemu-kvm -S -M pc-0.14 -enable-kvm -m 2048 -smp
2,sockets=2,cores=1,threads=1 -name windowsvistax64-2 -uuid
9e05602e-6c56-ccdb-a8d6-551cf434a3f8 -nodefconfig -nodefaults -chardev
socket,id=charmonitor,path=/var/lib/libvirt/qemu/windowsvistax64-2.monitor,server,nowait
-mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime
-no-hpet -no-shutdown -drive
file=/var/lib/libvirt/images/win7.raw,if=none,id=drive-ide0-0-0,format=raw
-device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=2
-netdev tap,fd=22,id=hostnet0 -device
rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:98:e5:52,bus=pci.0,multifunction=on,addr=0x3.0x0
-netdev tap,fd=23,id=hostnet1 -device
rtl8139,netdev=hostnet1,id=net1,mac=52:54:00:71:a0:18,bus=pci.0,multifunction=on,addr=0x5.0x0
-usb -device usb-tablet,id=input0 -vnc 127.0.0.1:0 -vga cirrus -device
intel-hda,id=sound0,bus=pci.0,multifunction=on,addr=0x6.0x0 -device
hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device
virtio-balloon-pci,id=balloon0,bus=pci.0,multifunction=on,addr=0x4.0x0

I am running with virt-manager as root -- OpenSUSE 12.1 prompts me for
the root password if I start virt-manager as a regular user.
Normally, though, I just run it su'ed to root from a terminal window.

Thanks,

Erik

Re: [Qemu-devel] (no subject)

[Stefan Hajnoczi]

On Tue, Dec 13, 2011 at 12:55 PM, Erik Lotspeich
erik.lotspe...@gmail.com wrote:
 On Tue, Dec 13, 2011 at 2:06 AM, Stefan Hajnoczi stefa...@gmail.com wrote:
 Please post your QEMU command-line (you can find it with ps aux | grep
 qemu).

 If you are running through libvirt/virsh/virt-manager there may be
 permission requirements since the guest can be set to run as an
 unprivileged user without access to audio devices.   That's just a guess
 but worth looking into.

 Here's my qemu command line:

 qemu      5294 19.6 25.7 2444808 2101252 ?     Sl   06:47   1:00
  ^^
Libvirt is running the qemu-kvm process as user 'qemu'.  Does that
user have the necessary groups (e.g. 'audio')?

On my system the unprivileged user is called 'libvirt-qemu' and here's
what I get:

$ id libvirt-qemuuid=105(libvirt-qemu) gid=112(kvm) groups=112(kvm)

You may need to add 'qemu' to group 'audio' or whatever is necessary
to let it access ALSA devices or talk to a sound daemon.
Stefan

Re: [Qemu-devel] (no subject)

[Erik Lotspeich]

Thank you - I overlooked the obvious.

Regards,

Erik

On Tue, Dec 13, 2011 at 8:57 AM, Stefan Hajnoczi stefa...@gmail.com wrote:
 On Tue, Dec 13, 2011 at 12:55 PM, Erik Lotspeich
 erik.lotspe...@gmail.com wrote:
 On Tue, Dec 13, 2011 at 2:06 AM, Stefan Hajnoczi stefa...@gmail.com wrote:
 Please post your QEMU command-line (you can find it with ps aux | grep
 qemu).

 If you are running through libvirt/virsh/virt-manager there may be
 permission requirements since the guest can be set to run as an
 unprivileged user without access to audio devices.   That's just a guess
 but worth looking into.

 Here's my qemu command line:

 qemu      5294 19.6 25.7 2444808 2101252 ?     Sl   06:47   1:00
  ^^
 Libvirt is running the qemu-kvm process as user 'qemu'.  Does that
 user have the necessary groups (e.g. 'audio')?

 On my system the unprivileged user is called 'libvirt-qemu' and here's
 what I get:

 $ id libvirt-qemuuid=105(libvirt-qemu) gid=112(kvm) groups=112(kvm)

 You may need to add 'qemu' to group 'audio' or whatever is necessary
 to let it access ALSA devices or talk to a sound daemon.
 Stefan

Re: [Qemu-devel] (no subject)

[Paolo Bonzini]

On 12/13/2011 04:22 PM, Erik Lotspeich wrote:

Thank you - I overlooked the obvious.


Actually it may be a distro bug, I suggest you report it there.

Paolo

[Qemu-devel] (no subject)

[Erik Lotspeich]

Hi,

I posted this on qemu-discuss and didn't receive any replies; sorry
for posting it twice.

I have OpenSUSE 12.1 and I have a 64-bit Windows 7 VM that recognizes
the emulated ICH6 sound (HDA audio device).  Although Windows
recognizes this sound device just fine, there is no sound from the
Windows 7 VM.  Sound works fine in KDE and from all other applications
on the Linux side.  I would appreciate any ideas or help?

Thanks!

Regards,

Erik

[Qemu-devel] (no subject)

[wong]

...I suppose you won�t find the place more interesting than this site!
 http://www.spassvoegel-woellstein.de/page.december.php?uvpage=16t5

[Qemu-devel] (no subject)

[Ronnie Sahlberg]

List,

Please find a patch that adds a new section for iSCSI to qemu-doc.

This section provides much more verbose description of iSCSI and its use than
the manpage and also includes a short description on how to set up a
simple iSCSI target on loopback and then accessing it from QEMU.

The example on how to set up iSCSI Target uses the STGT iscsi target,
so the example would only work on a subset of linux/bsd systems.
I recognize also that this might be controversion, since why show how to 
configure xyz unrelated package in QEMU documentation.
My intention here is to provide a howto that describes how to quickly get iSCSI 
target up and running and to get QEMU to use it. As a quick howto for people 
that are not familiar with iSCSI but still want to test it out quickly.

Learning how to set up iSCSI target can often be somewhat complex and daunting
and could otherwise act as huge treshold for people that would just want to
get iSCSI running and experiment with QMEU, but would otherwise not want to
spend a lot of time learning about the target side of iscsi.


I think having examples like this is useful but see that it could be seen as
controversial.
Feel free to remove that part of the patch if you think this does not belong in 
the qemu docs.


regards
ronnie sahlberg

[Qemu-devel] (no subject)

[王永博]

ff

[Qemu-devel] (no subject)

[Benoît Canet]

These patches apply against akivity memory/master.
They convert syborg to memory API and various
arm related component to VMState.

Omap boards where not modified because Linaro is
currently refactoring them.

Xscale was left apart too.

This version fix coding style issues.

From Benoît Canet benoit.ca...@gmail.com # This line is ignored.
From: Benoît Canet benoit.ca...@gmail.com
Subject: 
In-Reply-To: 

[Qemu-devel] (no subject)

[Ottavio]

I wonder if it is possible to compile a newer version of qemu with
(the defunct) kqemu on Windows (XP)?

The winkvm project doesn't seem to be usable yet.

-- 
Ottavio

[Qemu-devel] (no subject)

[王永博]

ds

[Qemu-devel] (no subject)

[Michael Tokarev]

[Qemu-devel] (no subject)

[Ronnie Sahlberg]

Please find attached a patch to add built-in support for iSCSI into QEMU.
Please review and/or apply this patch.

This is the latest version of this patch and I think I have addressed all 
previous concerns and suggestions.


Using built-in iSCSI support has many advantages for certain use cases :

* if you have very many iSCSI devices it may be impractical to expose
all LUNs to the underlying host.

* the devices become private to the guest and are not visible to the host.
This automatically avoids polluting the page-cache on the host.

* security, the devices are private to the guest, which prevents other guests 
or the host itself from accessing the devices.

* security, it allows non-root users a secure way to get private and password 
protected access to the device by using CHAP authentication.

* migration, many other virtualization systems provide built-in iscsi clients 
like this. Also providing this as feature in QEMU may make it easier for such 
users to migrate over to QEMU/KVM.

* easier to maintain. For users with very many QEMU instances I think having 
guest-private iscsi targets and LUNs may be easier to manage than 'huge set of 
files in /dev/scsi/*'

* easier to maintain, when copying a QEMU instance from one host to another, 
this offers a more self-contained solution where the QEMU command line itself 
cotnains all required storage configuration, instead of also having to 
coordinate this move with setting up and tearing down open-iscsi logins on the 
underlying hosts.




The patch has been tested by installing and running several distributions such 
as RHEL6 and Ubuntu on devices, both system disk as well as the installer CDROM 
as being iscsi devices.

This testing has also been performed by running full QEMU under valgrind.

Performance is comparable to using open-iscsi devices.

[Qemu-devel] (no subject)

[maheen butt]

hi
I'm running MIPS user mode emulation with qemu. Whenever a memory reference 
instruction comes from MIPS ELF how this address is translated to host virtual 
address? or is there any mapping function which is used? my host machine is x86

Regards



  

[Qemu-devel] (no subject)

[Aurelien Jarno]

This patch series start by a cleanup to remove dead HPPA code and fix a
few inconsistencies. The following patch implement implement correct
NaN propagation rules for MIPS and PowerPC, following commit 3
54f211b1a49a7387929e22d6e63849fcba48f8a.

Changes from v1:
- Add softfloat: use bits32 instead of uint32 (missing in previous
  series)
- Add softfloat: rename *IsNaN variables to *IsQuietNaN as suggested
  by Peter Maydell.
- Update softfloat: fix float{32,64}_maybe_silence_nan() for MIPS and
  softfloat: add float{x80,128}_maybe_silence_nan() to issue a compile
  error on SNAN_BIT_IS_ONE targets other than MIPS.
- Update softfloat: use float{32,64,x80,128}_maybe_silence_nan() to 
  correctly compute aIsLargerSignificand.

Re: [Qemu-devel] (no subject)

[Peter Maydell]

On 4 January 2011 15:15, Aurelien Jarno aurel...@aurel32.net wrote:
 This patch series start by a cleanup to remove dead HPPA code and fix a
 few inconsistencies. The following patch implement implement correct
 NaN propagation rules for MIPS and PowerPC, following commit 3
 54f211b1a49a7387929e22d6e63849fcba48f8a.

I haven't given a Reviewed-by: for the MIPS and PPC patches in
this series (4,7,8) since I don't know either arch well enough to say
whether the behaviour is right, but they look OK.

-- PMM

Re: [Qemu-devel] (no subject)

[Aurelien Jarno]

On Tue, Jan 04, 2011 at 04:06:13PM +, Peter Maydell wrote:
 On 4 January 2011 15:15, Aurelien Jarno aurel...@aurel32.net wrote:
  This patch series start by a cleanup to remove dead HPPA code and fix a
  few inconsistencies. The following patch implement implement correct
  NaN propagation rules for MIPS and PowerPC, following commit 3
  54f211b1a49a7387929e22d6e63849fcba48f8a.
 
 I haven't given a Reviewed-by: for the MIPS and PPC patches in
 this series (4,7,8) since I don't know either arch well enough to say
 whether the behaviour is right, but they look OK.
 

Ok, thanks for the review.

-- 
Aurelien Jarno  GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net

[Qemu-devel] (no subject)

[Ronnie Sahlberg]

Please find a new block driver that IF libiscsi is present on the system
will link with this userspace client library and make qemu able to
access iscsi devices directly without exposing them to the host.

The library used is multiplatform and available from
git://github.com/sahlberg/libiscsi.git

[Qemu-devel] (no subject)

[Joao Francisco Medeiros Neto]

http://www.folhadeitapetininga.com.br/index0005.php


  

[Qemu-devel] (no subject)

[Joao Francisco Medeiros Neto]

http://serwis.avx.pl/index0005.php


  

[Qemu-devel] (no subject)

[Joao Francisco Medeiros Neto]

http://cuzzucoli.it/index000.php


  

[Qemu-devel] (no subject)

[Joao Francisco Medeiros Neto]

http://aigipe.it/index99.php


  

[Qemu-devel] (no subject)

[Joao Francisco Medeiros Neto]

http://www.tk-motorsport.at/thunder.php


  

[Qemu-devel] (no subject)

[Stefan Hajnoczi]

[Qemu-devel] (no subject)

[Michael Roth]

From Michael Roth mdr...@linux.vnet.ibm.com # This line is ignored.
From: Michael Roth mdr...@linux.vnet.ibm.com
Subject: [RFC][PATCH v3 00/11] virtagent: host/guest RPC communication agent
In-Reply-To: 

This set of patches is meant to be applied on top of the recently submitted 
Virtproxy v2 patchset. It can also be obtained at:

git://repo.or.cz/qemu/mdroth.git virtproxy_v2

OVERVIEW:

There are a wide range of use cases motivating the need for a guest agent of 
some sort to extend the functionality/usability/control offered by QEMU. Some 
examples include graceful guest shutdown/reboot and notifications thereof, 
copy/paste syncing between host/guest, guest statistics gathering, file access, 
etc.

Ideally these would all be served by a single, easilly extensible agent that 
can be deployed in a wide range of guests. Virtagent is an XMLRPC server 
integrated into the Virtproxy guest daemon and aimed at providing this type of 
functionality.

CHANGES IN V3:

 - Integrated virtagent invocation into virtproxy chardev. Usage examples below.
 - Consolidated RPC server/client setup into a pair of init routines
 - Fixed buffer overflow in agent_viewfile() and various memory leaks

CHANGES IN V2:

 - All RPC communication is now done using asynchronous/non-blocking read/write 
handlers
 - Previously fork()'d RPC server loop is now integrated into qemu-vp/virtproxy 
i/o loop
 - Cleanups/suggestions from previous RFC

DESIGN:

There are actually 2 RPC servers:

1) a server in the guest integrated into qemu-vp, the Virtproxy guest daemon, 
which handles RPC requests from QEMU
2) a server in the host, integrated into the virtproxy chardev, to handle RPC 
requests sent by the guest agent (mainly for handling asynchronous events 
reported by the agent).

At the Virtagent level, communication is done via standard RPCs (HTTP between 
host and guest). Virtproxy transparently handles transport over a network or 
isa/virtio serial channel, allowing the agent to be deployed on older guests 
which may not support virtio-serial.

Currently there are only 2 RPCs implemented for the guest server (getfile and 
getdmesg), and 0 for the host. Additional RPCs can be added fairly easily, but 
are dependent on feedback from here and elsewhere. ping/status, shutdown, and 
reboot are likely candidates (although the latter 2 will likely require 
asynchronous notifications to the host RPC server to implement reliably).

EXAMPLE USAGE:

The commandline options are a little convoluted right now; this will addressed 
in later revisions.

 - Configure guest agent to talk to host via virtio-serial
# start guest with virtio-serial/virtproxy/virtagent. for example 
(RHEL6rc1):
qemu \
-chardev virtproxy,id=test0,virtagent=on \
-device virtio-serial \
-device virtserialport,chardev=test0,name=virtagent0 \
-monitor stdio
...
# in the guest:
./qemu-vp -c virtserial-open:/dev/virtio-ports/virtagent0:- -g
...
# monitor commands
(qemu) agent_viewdmesg
[139311.710326] wlan0: deauthenticating from 00:30:bd:f7:12:d5 by local 
choice (reason=3)
[139323.469857] wlan0: deauthenticating from 00:21:29:cd:41:ee by local 
choice (reason=3)
...
[257683.375646] wlan0: authenticated
[257683.375684] wlan0: associate with AP 00:30:bd:f7:12:d5 (try 1)
[257683.377932] wlan0: RX AssocResp from 00:30:bd:f7:12:d5 (capab=0x411 
status=0 aid=4)
[257683.377940] wlan0: associated

(qemu) agent_viewfile /proc/meminfo
MemTotal:3985488 kB
MemFree:  400524 kB
Buffers:  220556 kB
Cached:  2073160 kB
SwapCached:0 kB
...
Hugepagesize:   2048 kB
DirectMap4k:8896 kB
DirectMap2M: 4110336 kB

KNOWN ISSUES/PLANS:
 - the client socket that qemu connects to send RPCs is a hardcoded filepath. 
This is unacceptable as the socket is channel/process specific and things will 
break when multiple guests are started.
 - capability negotiation will be needed to handle version/architecture 
differences.
 - proper channel negotiation is needed to avoid hung monitors and such when a 
guest reboots or the guest agent is stopped for whatever reason. additionally, 
a timeout may need to be imposed on the amount of time the http read handler 
can block the monitor.
 - additional host-to-guest RPCs as well as asynchronous notifications via 
guest-to-host RPCs for events such as shutdown/reboot/agent up/agent down

[Qemu-devel] (no subject)

[Stefan Hajnoczi]

QEMU Enhanced Disk format is a disk image format that forgoes features
found in qcow2 in favor of better levels of performance and data
integrity.  Due to its simpler on-disk layout, it is possible to safely
perform metadata updates more efficiently.

Installations, suspend-to-disk, and other allocation-heavy I/O workloads
will see increased performance due to fewer I/Os and syncs.  Workloads
that do not cause new clusters to be allocated will perform similar to
raw images due to in-memory metadata caching.

The format supports sparse disk images.  It does not rely on the host
filesystem holes feature, making it a good choice for sparse disk images
that need to be transferred over channels where holes are not supported.

Backing files are supported so only deltas against a base image can be
stored.  The base image may be smaller than the image file.

The file format is extensible so that additional features can be added
later with graceful compatibility handling.  A specification for the file
format is included in this patchset.

Internal snapshots are not supported.  This eliminates the need for
additional metadata to track copy-on-write clusters.

Compression and encryption are not supported.  They add complexity and can be
implemented at other layers in the stack (i.e. inside the guest or on the
host).  Encryption has been identified as a potential future extension and the
file format allows for this.

Signed-off-by: Anthony Liguori aligu...@us.ibm.com
Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
---
This code is also available from git:

http://repo.or.cz/w/qemu/stefanha.git/shortlog/refs/heads/qed-v3

I have preserved distinct commits against v2 for easier reviewing here:

http://repo.or.cz/w/qemu/stefanha.git/shortlog/refs/heads/qed-v3-presquash

v3:
 * Flush before L2 update when a backing file is used
 * Use QED_F_BACKING_FORMAT_NO_PROBE instead of backing_fmt header field
 * Allow non-cluster sized images
 * Implement autoclear feature bits
 * Implement backing image smaller size - reads from backing image should zero 
beyond EOF
 * Preserve errno in qed_find_cluster_cb() - don't dumb down to 
QED_CLUSTER_ERROR
 * Use ffs() instead of get_bits_from_size()
 * Remove l2_cache argument to qed_unref_l2_cache_entry
 * Eliminate L2TableAllocFunc function pointer
 * Split qed_aio_write in-place and allocating code path to make code clearer
 * Document how L2 cache is used
 * Document qed_find_cluster()
 * Update QED specification
 * Fix COPYING.LIB LGPL license file references
 * Add copyright header to qed-check.c
 * Avoid the bytes_to_str()/cvtstr()/sztostr() dependency until Jes' strtosz() 
goes in

v2:
 * Add QED format specification to documentation
 * Use __builtin_ctzl() for get_bits_from_size()
 * Fine-grained table locking to allow concurrent allocating write requests
 * Fix qemu_free() instead of qemu_vfree() in qed_unref_l2_cache_entry()
 * Comment clean-ups

[Qemu-devel] (no subject)

[Stephen Isard]

Hello,

I hope you will excuse a naive question here.  I'm not getting any 
response on the users' lists.


I'm wondering whether shutting down a guest machine with the quit 
command in the monitor can corrupt the snapshots saved with savevm.  As 
I understand it,  quit will have an effect on the virtual guest similar 
to pulling the plug on a physical machine, so could leave it in a funny 
state.  Since the snapshots appear to be stored on the guest's hard 
disk, it seems conceivable (in my state of ignorance) that they could be 
put at risk.  Is that in fact possible?


Thanks for your attention.

[Qemu-devel] (no subject)

[Jason McMullan]

From cc0481503722124f085d785637aeea9ea51fab9b Mon Sep 17 00:00:00 2001
From: Jason S. McMullan jason.mcmul...@gmail.com
Date: Wed, 28 Oct 2009 00:56:00 -0400
Subject: [PATCH] hw/sd: Support SDHC size cards

Signed-off-by: Jason S. McMullan jason.mcmul...@gmail.com
---
 hw/sd.c |  153 ++-
 1 files changed, 93 insertions(+), 60 deletions(-)

diff --git a/hw/sd.c b/hw/sd.c
index 9888547..4d306af 100644
--- a/hw/sd.c
+++ b/hw/sd.c
@@ -81,7 +81,7 @@ struct SDState {
 uint32_t vhs;
 int wp_switch;
 int *wp_groups;
-uint32_t size;
+uint64_t size;
 int blk_len;
 uint32_t erase_start;
 uint32_t erase_end;
@@ -92,7 +92,7 @@ struct SDState {
 int spi;
 int current_cmd;
 int blk_written;
-uint32_t data_start;
+uint64_t data_start;
 uint32_t data_offset;
 uint8_t data[512];
 qemu_irq readonly_cb;
@@ -249,37 +249,59 @@ static const uint8_t sd_csd_rw_mask[16] = {
 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xfc, 0xfe,
 };
 
-static void sd_set_csd(SDState *sd, uint32_t size)
+static void sd_set_csd(SDState *sd, uint64_t size)
 {
 uint32_t csize = (size  (CMULT_SHIFT + HWBLOCK_SHIFT)) - 1;
 uint32_t sectsize = (1  (SECTOR_SHIFT + 1)) - 1;
 uint32_t wpsize = (1  (WPGROUP_SHIFT + 1)) - 1;
 
-sd-csd[0] = 0x00; /* CSD structure */
-sd-csd[1] = 0x26; /* Data read access-time-1 */
-sd-csd[2] = 0x00; /* Data read access-time-2 */
-sd-csd[3] = 0x5a; /* Max. data transfer rate */
-sd-csd[4] = 0x5f; /* Card Command Classes */
-sd-csd[5] = 0x50 |/* Max. read data block length */
-HWBLOCK_SHIFT;
-sd-csd[6] = 0xe0 |/* Partial block for read allowed */
-((csize  10)  0x03);
-sd-csd[7] = 0x00 |/* Device size */
-((csize  2)  0xff);
-sd-csd[8] = 0x3f |/* Max. read current */
-((csize  6)  0xc0);
-sd-csd[9] = 0xfc |/* Max. write current */
-((CMULT_SHIFT - 2)  1);
-sd-csd[10] = 0x40 |   /* Erase sector size */
-(((CMULT_SHIFT - 2)  7)  0x80) | (sectsize  1);
-sd-csd[11] = 0x00 |   /* Write protect group size */
-((sectsize  7)  0x80) | wpsize;
-sd-csd[12] = 0x90 |   /* Write speed factor */
-(HWBLOCK_SHIFT  2);
-sd-csd[13] = 0x20 |   /* Max. write data block length */
-((HWBLOCK_SHIFT  6)  0xc0);
-sd-csd[14] = 0x00;/* File format group */
-sd-csd[15] = (sd_crc7(sd-csd, 15)  1) | 1;
+if (size = 0x4000) {
+   sd-csd[0] = 0x00;  /* CSD structure */
+   sd-csd[1] = 0x26;  /* Data read access-time-1 */
+   sd-csd[2] = 0x00;  /* Data read access-time-2 */
+   sd-csd[3] = 0x5a;  /* Max. data transfer rate */
+   sd-csd[4] = 0x5f;  /* Card Command Classes */
+   sd-csd[5] = 0x50 | /* Max. read data block length */
+   HWBLOCK_SHIFT;
+   sd-csd[6] = 0xe0 | /* Partial block for read allowed */
+   ((csize  10)  0x03);
+   sd-csd[7] = 0x00 | /* Device size */
+   ((csize  2)  0xff);
+   sd-csd[8] = 0x3f | /* Max. read current */
+   ((csize  6)  0xc0);
+   sd-csd[9] = 0xfc | /* Max. write current */
+   ((CMULT_SHIFT - 2)  1);
+   sd-csd[10] = 0x40 |/* Erase sector size */
+   (((CMULT_SHIFT - 2)  7)  0x80) | (sectsize  1);
+   sd-csd[11] = 0x00 |/* Write protect group size */
+   ((sectsize  7)  0x80) | wpsize;
+   sd-csd[12] = 0x90 |/* Write speed factor */
+   (HWBLOCK_SHIFT  2);
+   sd-csd[13] = 0x20 |/* Max. write data block length */
+   ((HWBLOCK_SHIFT  6)  0xc0);
+   sd-csd[14] = 0x00; /* File format group */
+   sd-csd[15] = (sd_crc7(sd-csd, 15)  1) | 1;
+} else {
+   size /= 512 * 1024;
+   size -= 1;
+   sd-csd[0] = 0x40;
+   sd-csd[1] = 0x0e;
+   sd-csd[2] = 0x00;
+   sd-csd[3] = 0x32;
+   sd-csd[4] = 0x5b;
+   sd-csd[5] = 0x59;
+   sd-csd[6] = 0x00;
+   sd-csd[7] = (size  16)  0xff;
+   sd-csd[8] = (size  8)  0xff;
+   sd-csd[9] = (size  0xff);
+   sd-csd[10] = 0x7f;
+   sd-csd[11] = 0x80;
+   sd-csd[12] = 0x0a;
+   sd-csd[13] = 0x40;
+   sd-csd[14] = 0x00;
+   sd-csd[15] = 0x00;
+   sd-ocr |= (1  30);
+}
 }
 
 static void sd_set_rca(SDState *sd)
@@ -362,7 +384,7 @@ static void sd_response_r7_make(SDState *sd, uint8_t 
*response)
 
 static void sd_reset(SDState *sd, BlockDriverState *bdrv)
 {
-uint32_t size;
+uint64_t size;
 uint64_t sect;
 
 if (bdrv) {
@@ -372,10 +394,7 @@ static void 

[Qemu-devel] (no subject)

[Stuart Anderson]

I'm trying to test my fixes to the linux-user emulation on some additonal
architectures now, but I'm running into problems. I can debug these some,
but any suggestions or guidence, especially from people more familiar
with the architecture core code, would be appreciated.

The environment is a Debian x86_64 server running Etch, with target
environments built using debootstrap.


MIPS:

Bash seems to start up ok, but when I run a command in it, it hangs
until I hit return a second time, and then bash exits w/ an uncaught
target signal.

projects:~/upstream/qemu# mips-linux-user/qemu-mips -L /mirror0/chroots/mips/ 
/mirror0/chroots/mips/bin/bash
projects:~/upstream/qemu# ps

  PID TTY  TIME CMD
  18786 pts/100:00:00 bash
  20057 pts/100:00:00 ps
  20058 pts/100:00:00 qemu-mips
qemu: uncaught target signal 25 (Continued) - exiting
projects:~/upstream/qemu#

PPC:

I am unable to get any executable to run.


projects:~/upstream/qemu# ./ppc-linux-user/qemu-ppc -L /mirror0/chroots/ppc/ 
/mirror0/chroots/ppc/bin/bash
init_ppc_proc: PVR 0008 mask  = 0008
Segmentation fault
projects:~/upstream/qemu#


Thanks,


Stuart

Stuart R. Anderson   [EMAIL PROTECTED]
Network  Software Engineering   http://www.netsweng.com/
1024D/37A79149:  0791 D3B8 9A4C 2CDC A31F
 BD03 0A62 E534 37A7 9149

Re: [Qemu-devel] (no subject)

[Ben Taylor]

 jeremy fenelon [EMAIL PROTECTED] wrote: 
 Hey guys thanks for a great product. I don't know if its been documented 
 already but I was able to install windows xp  on qemu with a HP Laptop 
 Restore disk.

Lucky. I think the last time I tried that, it didn't work because of the
way that HP locked the restore media to the BIOS identifier. Always
wanted to be able to have the Bochs bios have an idenfier setting
I coudl pass in so I could do something like that.

  I did need my key from the bottom.  I hope this meets the EULA . 

Can't tell you if it meets the EULA. I picked up a key when a company
trashed a laptop that still had the key on the bottom. 

 My laptop did die last year and I have been wondering what I could do with 
 that extra copy.

  Will Qemu boot a .iso file like ubuntu?

Yes, it's a whole lot easrier than shuffling CD's and DVD's about.




___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] (no subject)

[jeremy fenelon]

Hey guys thanks for a great product. I don't know if its been documented 
already but I was able to install windows xp  on qemu with a HP Laptop Restore 
disk.
 I did need my key from the bottom.  I hope this meets the EULA . My laptop did 
die last year and I have been wondering what I could do with that extra copy.
 
 Will Qemu boot a .iso file like ubuntu?
 Thank___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] (no subject)

[Torbjörn Andersson]

Hello qemu developers!I´m using QEMU for some ARM debugging and I have som questions regardning the CPSR register. I get the feeling that the CPSR condition code bits, representing the results from the ALU, are not maintained.What I want to do is to try to verify QEMU maintains the CPSR register and if not fix it. However, it is not trivial identify where the updates should be placed. The relationship between translate.c and op.c is not trival I must say :)I would be happy I anyone here could give me some pointers on how the updates of the CPSR register is done today and what the strategy is. I guess there are plenty of performance ideas here as in the rest of qemu.Does anyone have any reflection on this topic or can anyone give me some pointers?Torbjörn
Nätets roligaste filmer hittar du på Spray Crazy! Till Spray Crazy___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

RE: [Qemu-devel] (no subject)

[Blue Swirl]

For nearly 6 years on of the applications i wrote exhibited incorrect
behavior on the systems running X with MSB byte/bit order. And today
i finally nailed it down, all thanks to the work of Fabrice Bellard
and Blue Swirl.


Thanks. Out of curiosity, how did you debug the software with Qemu? What was 
Qemu's advantage compared to real hardware?


_
Don't just search. Find. Check out the new MSN Search! 
http://search.msn.com/




___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel