Re: Moving QEMU downloads to GitLab Releases?

[Anthony Liguori]

On Fri, Oct 1, 2021 at 12:20 AM Stefan Hajnoczi  wrote:

> On Thu, Sep 30, 2021 at 03:57:49PM +, Eldon Stegall wrote:
> > Hello!
> > I'd be happy to help with this. I'm mostly a consumer of QEMU, but
> > greatly appreciate all the work this community has done, and was able
> > to contribute a little by helping with QEMU advent this past year. I
> > would be happy to help streamline some of this activities if that would
> > be welcome, and would gratefully contribute time and resources. Hosting
> > and serving data like this has been core to my recent experience.
> >
> > I would be happy to suggest and build out a distribution strategy for
> > these packages, and believe I could cut some costs, and even convince a
> > small consultancy I am a part of here that uses QEMU to foot a
> > reasonable bill.
> >
> > A brief introduction, since I haven't had the pleasure of attending
> > FOSDEM or any other QEMU meetups: I am a startup-oriented Cloud Security
> > Architect, based out of Atlanta, previously with companies like
> > DataStax, but now working on AWS video pipelines for a startup here.
>
> Thanks for joining the discussion and for running last year's QEMU
> Advent Calendar, Eldon.
>
> Any ideas for moving download.qemu.org to a hosted service would be
> appreciated! We haven't compared CDN and cloud providers closely yet. If
> you have experience in this area or time to check them out, then that
> would be valuable.
>
> QEMU has funds if there is a cost for file hosting (probably less than
> $100/month). Some providers may be willing to support an open source
> project for free. Possible providers include CloudFlare, Akamai, Fastly,
> Microsoft Azure, Google Cloud Storage, etc.
>

https://aws.amazon.com/blogs/opensource/aws-promotional-credits-open-source-projects/

Let me know if ya'll apply and I'm happy to push it through.

Regards,

Anthony Liguori

Re: [Qemu-devel] HTTP access to QEMU Git repositories

[Anthony Liguori]

On Dec 9, 2015 6:14 PM, "Stefan Hajnoczi"  wrote:
>
> On Wed, Dec 09, 2015 at 06:07:07PM +0100, Paolo Bonzini wrote:
> > On 09/12/2015 17:37, Kai Noda wrote:
> > > Those auxiliary repositories referenced by git-submodule, such as
> > > dtc.git in my last email, are only available on git.qemu.org
> > > .
> >
> > Hmm, that should be fixed but I don't know who manages github.com/qemu.
> >  Is it still Anthony?
>
> ENOCONTEXT.  Where are you getting HTTP from?
>
> https://github.com/qemu/qemu/blob/master/.gitmodules has
> git://git.qemu-project.org/ URLs.
>
> I have push access to github.com/qemu/qemu.git but Anthony has the
> GitHub username/password needed to make account changes, new repos, etc.

qemu is an organization, not an account.  At least Paolo and Andreas are
owners of the org and can add more people.

Let me know if this I am missing anything here.  It's been a while and I
only half remember setting this up.

> Stefan

Re: [Qemu-devel] [Xen-devel] [PATCH 1/1] xen-hvm.c: Add support for Xen access to vmport

[Anthony Liguori]

On Wed, Oct 1, 2014 at 7:44 AM, Ian Campbell ian.campb...@citrix.com wrote:
 On Wed, 2014-10-01 at 10:20 +0100, Stefano Stabellini wrote:
 I wonder if we could send both ioreqs at once from Xen and back from
 QEMU. Or maybe append the registers to IOREQ_TYPE_VMWARE_PORT, changing
 the size of ioreq_t only for this ioreq type.

 Random idea: Why new add a IOREQ_TYPE_FULL_STATE which would be issued
 for these ports and let qemu decode the fact that it is vmware
 internally? That might be a more generically useful interface in the
 future?

 WRT to fitting all the register state in the current sized request, you
 could declare that this new thing takes multiple slots.

 Also, I may be wrong, but I thought most IOREQs were synchronous so only
 one slot was ever used? The buffered ioreq stuff has a separate ring (or
 uses a different part of the page, or something). I might be talking
 nonsense here though ;-)

There really isn't a concept of CPU associated with an IOREQ outside
of two very special cases, LAPIC emulation and vmport.  LAPIC
emulation really belongs closer to the CPU and given V-APIC, it's
gotten moved into hardware anyway.  vmport is just a hack VMware made.

I think it's better to think of it as a VMware specific hypercall and
terminate the IOREQ within the hypervisor.  Passing a decoded version
of the request to QEMU is fine but passing the full CPU state as part
of an IOREQ_TYPE_FULL_STATE is not very useful.  It's just an
IOREQ_TYPE_VMPORT with more information than is needed.

Regards,

Anthony Liguori

 Ian.



 ___
 Xen-devel mailing list
 xen-de...@lists.xen.org
 http://lists.xen.org/xen-devel

Re: [Qemu-devel] [PATCH] vnc: add additional key up event before repeated key down

[Anthony Liguori]

On Tue, Sep 9, 2014 at 8:31 PM, Chun Yan Liu cy...@suse.com wrote:


 On 9/10/2014 at 02:23 AM, in message 
 87tx4girg6@blackfin.pond.sub.org,
 Markus Armbruster arm...@redhat.com wrote:
 Chun Yan Liu cy...@suse.com writes:

 On 9/6/2014 at 05:23 AM, in message
  alpine.deb.2.02.1409052202451.2...@kaball.uk.xensource.com, Stefano
  Stabellini stefano.stabell...@eu.citrix.com wrote:
  On Fri, 5 Sep 2014, Chunyan Liu wrote:
   Using xen tools 'xl vncviewer' with tigervnc (default on SLE-12),
   found that: the display of the guest is unexpected while keep
   pressing a key. We expect the same character multiple times, but
   it prints only one time. This happens on a PV guest in text mode.
  
   After debugging, found that tigervnc sends repeated key down events
   in this case, to differentiate from user pressing the same key many
   times. Vnc server only prints the character when it finally receives
   key up event.
 
  Is this actually how a vnc client should behave?
  How do the vnc client and server from realvnc behave in this regard
  (they are the reference implementation)?
 
  VNC protocol doesn't specify how to handle key repetition. Tightvnc
  sends key-downkey-up repeatedly, but some example like RealVNC for
  Windows does the same thing - it sends only repeated key-down.
 
  Generally the VNC keyboard handling gives lot of space for interpretation
  and so the implementations differ.

 If implementations differ, and QEMU already behaves like some of them,
 then why change it?

 To change qemu side because we could not expect each VNC client behaves
 the same when holding key down, some sending key-down, key-up, key-down,
 key-up; but some sending key-down, key-down, key-down  Without change,
 client only sending key-down, key-up, key-down,key-up ... can get correct
 display.

The VNC keyboard handling is pretty straight forward.   The keys sent
are symbolic and correspond to input events (as interpreted by an
application).  Whether you get repeat events depends on a lot of
client side configuration.

  What exactly gets fixed and what gets broken by the
 proposed change?

 Holding the key down, only one character is printed, but repeated characters
 are expected. Happens on some vnc client. Either vnc client or vnc server
 should change some to match.

You should fix TigerVNC.  It's broken if it isn't sending repeat events.

Regards,

Anthony Liguori


 [...]

Re: [Qemu-devel] Cc'ing emails [

[Anthony Liguori]

On Aug 5, 2014 2:42 AM, Markus Armbruster arm...@redhat.com wrote:

 Michael Tokarev m...@tls.msk.ru writes:

  05.08.2014 08:41, Chen Gang wrote:
 
  Every members have their own tastes, and one working flow may be not
  suitable for all members. I can understand, and hope other members
  understand too.
 
  At least for me, next, I shall send patch to the members which I can
get
  from 'get_maintainers.pl' and only Cc to qemu-devel. And shall skip
  qemu-trivial and Michael Tokarev.
 
  Why skip both?  It's your call, but I'm curious.
 
  What I _think_ wrong is that get_maintainers.pl lists many random
  patchers for a given file by default.
 
  Besides, we should probably review role of Anthony Ligory, because
  he is returned as a sole contact for manu files, but apparently he
  does not reply to emails anymore.
 
  []
  I'm not sure how people treat these cases or deal with them.
  We are subscribed to, in particular, qemu-devel@, and active
  maintainers look there too, so receive more than one copy of
  many emails.
 
  I believe fighting the established convention to copy is futile.  I
  embrace it instead, and make it help me prioritize my reading.  Copy
me,
  and I'll at least skim cover letters and other thread-starters to
  determine whether I need to follow this thread.  Don't copy me, and
I'll
  at best glance at the subject in passing.
 
  We created some separate mailinglists - for example -trivial@ -
especially
  to get such attention.  This is what I'm talking about, in most part,
  because main qemu mailinglist traffic become quite a bit high to follow
  it closely, and it is a good idea indeed to Cc someone when sending mail
  to qemu-devel@.  But even there, Cc'ing random patchers as
get_maintainer.pl
  often suggests is _not_ a good idea.  I think.

 I don't disagree with you there.  I take get_maintainer.pl as advice,
 not gospel.

 Note that because --git is *off* by default, you get random patchers
 only when MAINTAINERS comes up empty.  Which it does far too often,
 because its coverage is lousy: some 1300 out of 3600 files.

 We could default --git-fallback to off to suppress random patchers
 unless you ask for them.

  Automatic filing into folders and marking copies so I don't have to
mark
  them read twice helps.
 
  The additional traffic is a drop in a bucket.
 
  Which traffic you refer to as additional?  The personal emails?

 The personal copies compared to the full list traffic.

 I count some 1200 messages to qemu-devel for the past week.  32 contain
 the string mjt@tls, which I take as a crude upper bound for you
 getting a copy.  I don't mean to say that's not annoying or a drain on
 your time (who am I to judge?), just that the additional network traffic
 over full qemu-devel delivery is negligible.

  At least in my case it is quite significant because of qemu, and qemu
  is _far_ from a single project where I actively contributed.  For
example,
  I contributed many things to postfix, but I don't have to worry about
  it in any way, and I don't receive random personal emails - if something
  is being Cc'ed to me it really is something important.  Ditto for linux
  kernel and other areas.

 I recommend to set up filters to file away list traffic and copies of
 list traffic separately from your private e-mail.

  In case of qemu, see -- for example, Anthony, who apparently stepped
  out from qemu.  Almost every email on qemu-devel@ is being Cc'ed to
  him nowadays, so he receives _whole_ qemu-devel@ in his personal
  mailbox.

 I'd be surprised if he received copies in his personal inbox.  I expect
 him to file them smartly.

Is it also a drop in (his) bucket?

 I guess it is: 125 of last week's messages contain aliguori@.

Good email clients can filter with complex rules.  Just filter
to:y...@mail.com and to:qemu-devel into a separate folder.

And yes, 15 emails a day is a drop in the bucket...

Re: [Qemu-devel] possible denial of service via VNC

[Anthony Liguori]

On Sun, Jun 29, 2014 at 5:16 AM, Peter Lieven p...@kamp.de wrote:
 Hi,

 while debugging a VNC issue I found this:

 case VNC_MSG_CLIENT_CUT_TEXT:
 if (len == 1)
 return 8;

 if (len == 8) {
 uint32_t dlen = read_u32(data, 4);
 if (dlen  0)
 return 8 + dlen;
 }

 client_cut_text(vs, read_u32(data, 4), data + 8);
 break;

 in protocol_client_msg().

 Is this really a good idea? This allows for letting the vs-input buffer to 
 grow
 up to 2^32 + 8 byte which will possibly result in an out of memory condition.

The spec allows cut operations of this size.  What would a reasonable limit be?

Regards,

Anthony Liguori

 PeterY

Re: [Qemu-devel] [PATCH] MAINTAINERS: addresses for responsible disclosure

[Anthony Liguori]

On Thu, Apr 17, 2014 at 6:54 AM, Michael S. Tsirkin m...@redhat.com wrote:
 People sometimes detect security issues in upstream
 QEMU and don't know where to report them in a non-public way.
 Of course whoever just wants full disclosure can just go public,
 but there's nothing specified for non-public - until recently Anthony
 was doing this informally.

 As I started doing this recently anyway, I can handle this on the QEMU side
 in a more formal way.

 Adding a secalert mailing list as well - they are the ones who is actually
 opening CVEs, communicating issues to all downstreams etc,
 and they are already handling this for upstream, not just Red Hat.

 Keeping Anthony's address around in case he wants to be informed.

 Signed-off-by: Michael S. Tsirkin m...@redhat.com

What about using qemu-secur...@nongnu.org and creating that as a
moderated mailing list with no public archive?

That way there's a single contact point and there can be many people
backing it up to make sure that disclosures are handled very quickly.

Regards,

Anthony Liguori

 ---
  MAINTAINERS | 6 ++
  1 file changed, 6 insertions(+)

 diff --git a/MAINTAINERS b/MAINTAINERS
 index 34b8c3f..713546f 100644
 --- a/MAINTAINERS
 +++ b/MAINTAINERS
 @@ -52,6 +52,12 @@ General Project Administration
  --
  M: Anthony Liguori aligu...@amazon.com

 +Responsible Disclosure, Reporting Security Issues
 +--
 +M: Michael S. Tsirkin m...@redhat.com
 +M: Anthony Liguori aligu...@amazon.com
 +L: secal...@redhat.com
 +
  Guest CPU cores (TCG):
  --
  Alpha
 --
 MST

Re: [Qemu-devel] Error propagation in generated visitors and command marshallers

[Anthony Liguori]

On Wed, Apr 9, 2014 at 8:48 AM, Markus Armbruster arm...@redhat.com wrote:
 I stumbled over this while trying to purge error_is_set() from the code.


 Here's how we commonly use the Error API:

 Error *err = NULL;

 foo(arg, err)
 if (err) {
 goto out;
 }
 bar(arg, err)
 if (err) {
 goto out;
 }

 This ensures that err is null on entry, both for foo() and for bar().
 Many functions rely on that, like this:

 void foo(ArgType arg, Error **errp)
 {
 if (frobnicate(arg)  0) {
 error_setg(errp, Can't frobnicate);
 // This asserts errp != NULL
 }
 }


 Here's how some of our visitor code uses the Error API (for real code,
 check out generated qmp-marshal.c):

 Error *err = NULL;
 QmpInputVisitor *mi = qmp_input_visitor_new_strict(QOBJECT(args));
 Visitor *v = qmp_input_get_visitor(mi);
 char *foo = NULL;
 char *bar = NULL;

 visit_type_str(v, foo, foo, err);
 visit_type_str(v, bar, bar, err);
 if (err) {
 goto out;
 }

 Unlike above, this may pass a non-null errp to the second
 visit_type_str(), namely when the first one fails.

 The visitor functions guard against that, like this:

 void visit_type_str(Visitor *v, char **obj, const char *name, Error 
 **errp)
 {
 if (!error_is_set(errp)) {
 v-type_str(v, obj, name, errp);
 }
 }

 As discussed before, error_is_set() is almost almost wrong, fragile or
 unclean.  What if errp is null?  Then we fail to stop visiting after an
 error.

 The function could be improved like this:

 void visit_type_str(Visitor *v, char **obj, const char *name, Error 
 **errp)
 {
 assert(errp);
 if (!*errp) {
 v-type_str(v, obj, name, errp);
 }
 }


 But: is it a good idea to have both patterns in the code?  Should we
 perhaps use the common pattern for visiting, too?  Like this:

 visit_type_str(v, foo, foo, err);
 if (err) {
 goto out;
 }
 visit_type_str(v, bar, bar, err);
 if (err) {
 goto out;
 }

 Then we can assume *errp is clear on function entry, like this:

 void visit_type_str(Visitor *v, char **obj, const char *name, Error 
 **errp)
 {
 v-type_str(v, obj, name, errp);
 }

 Should execute roughly the same number of conditional branches.

 Tedious repetition of if (err) goto out in the caller, but that's what
 we do elsewhere, and unlike elsewhere, these one's are generated.

 Opinions?

The original visiting code was loosely based on ASN1 marshaling code
from Samba which used the if error, bail out at the top style of
error handling.

As use of Error has evolved in QEMU, I agree that the paradigm of
bail out as soon as you see an error and fail fast is better so I'd
vote for changing the generated code to do that.

Regards,

Anthony Liguori

Re: [Qemu-devel] KVM call agenda for 2014-04-01

[Anthony Liguori]

On Mon, Mar 31, 2014 at 6:25 AM, Peter Maydell peter.mayd...@linaro.org wrote:
 On 31 March 2014 14:21, Christian Borntraeger borntrae...@de.ibm.com wrote:
 Another thing might be the release process in general. Currently it seems
 that everybody tries to push everything just before the hard freeze.  I had
 to debug some problems introduced _after_ soft freeze. Is there some
 interest in having a Linux-like process (merge window + stabilization)? This
 would require shorter release cycles of course.

 merge window has been suggested before. I think it would be
 a terrible idea for QEMU, personally. We're not the kernel in
 many ways, notably dev community size and a greater tendency
 to changes that have effects across the whole tree.

 Soft + hard freeze is our stabilization period currently.

Peter, are you willing to do the tagging and announcement for the 2.0
rcs?  I sent instructions privately and between stefanha and I we can
get your permissions sorted out.

Regards,

Anthony Liguori

 thanks
 -- PMM

Re: [Qemu-devel] KVM call agenda for 2014-04-01

[Anthony Liguori]

On Mon, Mar 31, 2014 at 7:46 AM, Andreas Färber afaer...@suse.de wrote:
 Am 31.03.2014 16:32, schrieb Peter Maydell:
 On 31 March 2014 15:28, Paolo Bonzini pbonz...@redhat.com wrote:
 I think it would be a good idea to separate the committer and release
 manager roles.  Peter is providing the community with a wonderful service,
 just like you were; putting too much work on his shoulders risks getting us
 in the same situation if anything were to affect his ability to provide it.

 Yes, I strongly agree with this. I think we'll do much better
 if we can manage to share out responsibilities among a wider
 group of people.

 May I propose Michael Roth, who is already experienced from the N-1
 stable releases?

 If we can enable him to upload the tarballs created from his tags that
 would also streamline the stable workflow while at it.

If mdroth is willing to take this on, I am very supportive.

Regards,

Anthony Liguori


 Regards,
 Andreas

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

Re: [Qemu-devel] please release qemu version 1.7.1

[Anthony Liguori]

On Tue, Mar 25, 2014 at 7:13 AM, Michael Roth mdr...@linux.vnet.ibm.com wrote:
 Quoting Stefan Hajnoczi (2014-03-25 07:38:38)
 On Mon, Mar 24, 2014 at 10:59:42PM +0100, Laszlo Ersek wrote:
  On 03/24/14 22:50, Andreas Färber wrote:
   Laszlo,
  
   Am 24.03.2014 20:23, schrieb Laszlo Ersek:
   http://wiki.qemu.org/Planning/1.7
  
   Thank you.
   Laszlo
  
   Since you're not addressing anyone in particular who could create the
   release for you, the tag already exists on Michael's branch:
   https://github.com/mdroth/qemu/commits/v1.7.1
  
   And you can use scripts/make-release as an interim solution for creating
   the tarball from it.
 
  Thank you. However, I don't need the release for myself. I'd like to
  submit an OVMF patch (ACPI table download). That patch causes an OVMF
  regression when running on v1.7.0, but works on v1.7.1 (and of course on
  2.0.0-rc0). I'd like the tarball to be available to users; both to
  people who download it from the upstream location, and to those who use
  1.7.x-based distro (eg. Debian) packages.
 
  In my OVMF patch I'd like to reference the v1.7.1 qemu release.
 
  (Side note, the patch is also fine on v1.6.x and earlier.)
 
   If you do, you might be interested in:
   http://patchwork.ozlabs.org/patch/331939/
  
   What's missing is someone who can upload the tarball and edit all
   relevant Wiki pages. And someone to push branch and tag to qemu.git.
 
  Can as in is willing, or as in is permitted?
 
  I didn't know whom to address specifically.

 Anthony is doing releases and is the right person to poke.

 I think all that's left is publishing the tarball and posting the
 release announcement.

 Yes, Anthony was tied up around release time and I was subsequently out for
 a couple weeks due to a family emergency so didn't have a chance to follow-up
 till late last week. I'll do the announce as soon as we get the tarball
 uploaded. I'm still used to being able to walk next door, need to coordinate
 in advance a bit better next time.

It's ready to go.

Regards,

Anthony Liguori


 Stefan

Re: [Qemu-devel] QEMU 2.0 release schedule proposal

[Anthony Liguori]

I'll tag and push a tarball right now.

Regards,

Anthony Liguori

On Thu, Mar 13, 2014 at 1:16 PM, Peter Maydell peter.mayd...@linaro.org wrote:
 On 13 March 2014 17:24, Peter Maydell peter.mayd...@linaro.org wrote:
 On 11 February 2014 14:34, Anthony Liguori anth...@codemonkey.ws wrote:
 Looks reasonable to me.  I'll handle the release logistics in terms of
 tarball releases and tagging.

 Ping! Yesterday was nominally rc0 tagging day (though there
 was a bunch of late-breaking stuff so just as well we didn't
 tag then in some ways).

 Current not-yet-applied pull requests:
  * chardev hotplug (Gerd)
  * input fixes (Gerd)

 Applied

  * gtk fixes (Gerd)

 Bounced for compile failure

 There is also Andreas' QOM CPU pull which unfortunately
 needs fixing up as it doesn't compile on 32 bit hosts.

 Applied fixed up version

 Currently working on applying the PPC and prep pulls, but they
 are small (2 patches each) so if they've missed the rc0 boat then
 they'll just have to go into rc1.

 thanks
 -- PMM

[Qemu-devel] [ANNOUNCE] QEMU 2.0.0-rc0 is now available

[Anthony Liguori]

Hi,

On behalf of the QEMU Team, I'd like to announce the availability of the
first release candidate for the QEMU 2.0 release.  This release is meant
for testing purposes and should not be used in a production environment.

http://wiki.qemu.org/download/qemu-2.0.0-rc0.tar.bz2

You can help improve the quality of the QEMU 2.0 release by testing this
release and reporting bugs on Launchpad:

https://bugs.launchpad.net/qemu/

The release plan for the 2.0 release is available at:

http://wiki.qemu.org/Planning/2.0

Please add entries to the ChangeLog for the 2.0 release below:

http://wiki.qemu.org/ChangeLog/Next

Regards,

Anthony Liguori

[Qemu-devel] [ANNOUNCE] QEMU 2.0.0-rc0 is now available

[Anthony Liguori]

Hi,

On behalf of the QEMU Team, I'd like to announce the availability of the
first release candidate for the QEMU 2.0 release.  This release is meant
for testing purposes and should not be used in a production environment.

http://wiki.qemu.org/download/qemu-2.0.0-rc0.tar.bz2

You can help improve the quality of the QEMU 2.0 release by testing this
release and reporting bugs on Launchpad:

https://bugs.launchpad.net/qemu/

The release plan for the 2.0 release is available at:

http://wiki.qemu.org/Planning/2.0

Please add entries to the ChangeLog for the 2.0 release below:

http://wiki.qemu.org/ChangeLog/Next

Regards,

Anthony Liguori

Re: [Qemu-devel] QOM vs QAPI for QMP APIs

[Anthony Liguori]

On Fri, Feb 21, 2014 at 1:16 AM, Stefan Hajnoczi stefa...@redhat.com wrote:
 I need to add a QMP API that lists dataplane threads.  This is similar
 to query-cpus where the thread IDs are reported.  It allows the client
 to bind threads to host CPUs.

 I'm inclined to add a query-iothreads QMP command:
  * It's easy to implement using QAPI
  * We've developed best practices for QMP APIs
  * We know how to version and make QMP APIs extensible
  * Clients (including libvirt) are used to QMP JSON RPC

 But maybe I should use QOM instead:
  * Add a qom-find-objects-by-class QMP command (Paolo's idea)
  * Client does qom-find-objects-by-class IOThread /objects
  * Client then uses qom-get to fetch the thread_id property on each
IOThread object
  * But we haven't really established how QOM APIs will work

I have no objection to introducing a QMP command.

I think qom-find-objects-by-class is a reasonable approach but I would
also consider just grouping all of the IOThreads in a well known path
instead of just having them live in /objects.  So something like
/objects/threads/thread0/pid.

It ends up being very similar to working with sysfs at that point.

Regards,

Anthony Liguori

 So my question is: should we use QOM as the external API or continue
 using QAPI?

 I don't think we gain much by switching to QOM other than opening a
 whole new design space that we've yet to master.  We'll make plenty of
 mistakes just like we did with QMP and QAPI.

 Although QOM eliminates the need to implement dedicated QMP commands, it
 exposes a more complex model to the client.  Instead of a JSON
 command/response model we now expose a general object-oriented namespace
 with properties, links, etc.  The client has to make sense of all that
 and has to perform multiple qom-list/qom-get/etc commands for something
 that would take a single dedicated QMP command.

 Maybe I just need some convincing but it seems that QAPI is the simplest
 and cleanest way to define external APIs.

 Disagree?  Tell me why :).

 Stefan

Re: [Qemu-devel] CPU models and feature probing (was Re: [PATCH qom-cpu 00/16 v10] target-i386: convert CPU) features into properties

[Anthony Liguori]

On Fri, Feb 7, 2014 at 2:55 AM, Paolo Bonzini pbonz...@redhat.com wrote:
 Il 07/02/2014 11:16, Eduardo Habkost ha scritto:

 You are not alone. I remember we spent lots of time trying to convince
 Anthony to allow global properties and compat_props affect dynamic
 properties not just static properties, and static properties were a big
 deal due to reasons I didn't understand completely. Now I am hearing the
 opposite message, and I don't understand the reasons for the change of
 plans. I am confused.


 Picture me confused as well, but at the same I think I understand the
 reasons for the change of plans.

There's no real convincing.  It's just a question of code.  There are
no defaults in classes for dynamic properties to modify.  compat_props
are a nice mechanism, making them work for all properties is a
reasonable thing to do.

Regards,

Anthony Liguori

Re: [Qemu-devel] QEMU 2.0 release schedule proposal

[Anthony Liguori]

Looks reasonable to me.  I'll handle the release logistics in terms of
tarball releases and tagging.

Regards,

Anthony Liguori

On Tue, Feb 11, 2014 at 4:48 AM, Stefan Hajnoczi stefa...@gmail.com wrote:
 It's time to agree on the QEMU 2.0 release schedule so we can make a
 release within the next 2-3 months.

 The following proposal is the output of IRC discussion.  Juan figured
 out the dates and got feedback from several of us.  Speak up if you
 have concerns about the dates.

 Anthony: Please confirm whether you will perform the release process,
 or if someone should be trained to run the scripts/tests and sign the
 tarball?

 Summary: Soft Freeze: Feb 26, RC0: March12, RC1 March19, RC2 March26,
 RC3: Aprl 2, Release April 4th

 ---

 == Release Schedule ==

 {| border=1
 | 2013-12-17
 | Beginning of 2.0 development phase
 |-
 | 2014-01-22
 | Mid-point of development cycle
 |-
 | 2014-02-26
 | [[Planning/SoftFeatureFreeze|Soft feature freeze]].  All features
 should have patches on the list by this date; major features should
 have initial code committed.
 |-
 | 2014-03-12
 | [[Planning/HardFeatureFreeze|Hard feature freeze]].  Tag v2.0.0-rc0,
 only bug fixes committed after this point
 |-
 | 2014-03-19
 | Tag v2.0.0-rc1
 |-
 | 2014-03-26
 | Tag v2.0.0-rc2
 |-
 | 2014-04-02
 | Tag v2.0.0-rc3
 |-
 | 2014-04-04
 | Tag v2.0.0
 |}

 == Known issues ==

 == Targeted Features ==

 See the [[ChangeLog/2.0]] for full details.

Re: [Qemu-devel] CPU models and feature probing (was Re: [PATCH qom-cpu 00/16 v10] target-i386: convert CPU) features into properties

[Anthony Liguori]

On Tue, Feb 11, 2014 at 7:25 AM, Eduardo Habkost ehabk...@redhat.com wrote:
 On Tue, Feb 11, 2014 at 06:31:35AM -0800, Anthony Liguori wrote:
 On Fri, Feb 7, 2014 at 2:55 AM, Paolo Bonzini pbonz...@redhat.com wrote:
  Il 07/02/2014 11:16, Eduardo Habkost ha scritto:
 
  You are not alone. I remember we spent lots of time trying to convince
  Anthony to allow global properties and compat_props affect dynamic
  properties not just static properties, and static properties were a big
  deal due to reasons I didn't understand completely. Now I am hearing the
  opposite message, and I don't understand the reasons for the change of
  plans. I am confused.
 
 
  Picture me confused as well, but at the same I think I understand the
  reasons for the change of plans.

 There's no real convincing.  It's just a question of code.

 I am sure there's a lot of convincing involved, even after the code is
 written (in this case, 15 months after the code was written).

N.B. the code you refer to doesn't make global propeties and
compat_props affect dynamic properties.  It converts CPU properties
to static properties which I'm pretty sure I said many times is a
perfectly reasonable thing to do.

 There are
 no defaults in classes for dynamic properties to modify.  compat_props
 are a nice mechanism, making them work for all properties is a
 reasonable thing to do.

 That's exactly the opposite of what you said before[1]. But that isn't
 supposed to be a problem, I understand there may be change of plans (we
 should be able to change our minds).

I think you're confusing a few things.  You cannot make dynamic
properties work with globals today.  Globals change class default
values and there are no class defaults for dynamic properties.[*]

There's a perfectly valid discussion to have about whether we should
even have dynamic properties.  It's certainly been a long time since
they were introduced and they haven't made their way into all that
many devices so it's reasonable to say that perhaps we'd be better off
without them.  I would not object to a patch series that moved
properties to classes entirely provided it removed existing uses of
dynamic properties and didn't just introduce yet another mechanism.

But compat properties as a concept could be made to work with dynamic
properties.  They would have to be evaluated after instance init.
There's quite a few places they would end up touching I suspect.

Another point of confusion worth mention is legacy properties since
this usually comes up in the discussion.  Legacy properties (the
properties that are set/get as strings) are something that we should
try to avoid.  They end up as strings on the wire and make it harder
to write client code.

* I recognize that compat_props are implemented as globals.  I'm
really talking about the current implementation of globals, not the
concept of -global which could be made with dynamic properties.

Regards,

Anthony Liguori

 What I don't understand is the rejection of code that works, matches the
 style used by 200+ other source files, adds more useful introspectable
 information, done in the way that was suggested 16 months ago, because
 we have some rough idea about how a new grand design will look like in
 the far future.

 [1] http://lists.gnu.org/archive/html/qemu-devel/2013-06/msg00990.html

 --
 Eduardo

Re: [Qemu-devel] CPU models and feature probing (was Re: [PATCH qom-cpu 00/16 v10] target-i386: convert CPU) features into properties

[Anthony Liguori]

On Tue, Feb 11, 2014 at 8:55 AM, Andreas Färber afaer...@suse.de wrote:
 Am 11.02.2014 16:58, schrieb Anthony Liguori:
 On Tue, Feb 11, 2014 at 7:25 AM, Eduardo Habkost ehabk...@redhat.com wrote:
 On Tue, Feb 11, 2014 at 06:31:35AM -0800, Anthony Liguori wrote:
 On Fri, Feb 7, 2014 at 2:55 AM, Paolo Bonzini pbonz...@redhat.com wrote:
 Il 07/02/2014 11:16, Eduardo Habkost ha scritto:

 You are not alone. I remember we spent lots of time trying to convince
 Anthony to allow global properties and compat_props affect dynamic
 properties not just static properties, and static properties were a big
 deal due to reasons I didn't understand completely. Now I am hearing the
 opposite message, and I don't understand the reasons for the change of
 plans. I am confused.


 Picture me confused as well, but at the same I think I understand the
 reasons for the change of plans.

 There's no real convincing.  It's just a question of code.

 I am sure there's a lot of convincing involved, even after the code is
 written (in this case, 15 months after the code was written).

 N.B. the code you refer to doesn't make global propeties and
 compat_props affect dynamic properties.  It converts CPU properties
 to static properties which I'm pretty sure I said many times is a
 perfectly reasonable thing to do.

 There are
 no defaults in classes for dynamic properties to modify.  compat_props
 are a nice mechanism, making them work for all properties is a
 reasonable thing to do.

 That's exactly the opposite of what you said before[1]. But that isn't
 supposed to be a problem, I understand there may be change of plans (we
 should be able to change our minds).

 I think you're confusing a few things.  You cannot make dynamic
 properties work with globals today.  Globals change class default
 values and there are no class defaults for dynamic properties.[*]

 There's a perfectly valid discussion to have about whether we should
 even have dynamic properties.  It's certainly been a long time since
 they were introduced and they haven't made their way into all that
 many devices so it's reasonable to say that perhaps we'd be better off
 without them.  I would not object to a patch series that moved
 properties to classes entirely provided it removed existing uses of
 dynamic properties and didn't just introduce yet another mechanism.

 But compat properties as a concept could be made to work with dynamic
 properties.  They would have to be evaluated after instance init.
 There's quite a few places they would end up touching I suspect.

 Erm, sorry, that is already implemented in qemu.git!? instance_post_init
 by Eduardo plus glue by me.

Ah, even better then :-)

Regards,

Anthony Liguori

 Andreas


 Another point of confusion worth mention is legacy properties since
 this usually comes up in the discussion.  Legacy properties (the
 properties that are set/get as strings) are something that we should
 try to avoid.  They end up as strings on the wire and make it harder
 to write client code.

 * I recognize that compat_props are implemented as globals.  I'm
 really talking about the current implementation of globals, not the
 concept of -global which could be made with dynamic properties.

 Regards,

 Anthony Liguori

 What I don't understand is the rejection of code that works, matches the
 style used by 200+ other source files, adds more useful introspectable
 information, done in the way that was suggested 16 months ago, because
 we have some rough idea about how a new grand design will look like in
 the far future.

 [1] http://lists.gnu.org/archive/html/qemu-devel/2013-06/msg00990.html

 --
 Eduardo


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

Re: [Qemu-devel] [PATCH v3] Fix QEMU build on OpenBSD on x86 archs

[Anthony Liguori]

On Sun, Jan 26, 2014 at 1:40 PM, Brad Smith b...@comstyle.com wrote:
 On 26/01/14 1:06 PM, Paolo Bonzini wrote:

 Il 26/01/2014 02:37, Brad Smith ha scritto:



 Reviewed-by: Stefan Hajnoczi stefa...@redhat.com


 Is there some sort of process I am missing to have build fixes
 commited so that QEMU actually builds?


 Right now we have problems getting patches committed at all.

 This patch and the other NetBSD patch is not lost.


 I know it is not literally lost.

 I don't follow the list that closely.. what was the reason
 for there being two incidents over the last 2 months of there
 being no commits for over a week (at least from the perspective
 of git.qemu.org)?

Historically, having multiple committers has avoided this problem
because when one person gets bogged down, there's someone else to step
up.

Right now, it seems all current committers are in a bogged down state.

I've added another committer, Peter Maydell, to try to break the log
jam.  I'll try to devote more time to applying patches but hopefully
with Peter's help too, we can get things moving at the appropriate
speed again.

Regards,

Anthony Liguori


 --
 This message has been scanned for viruses and
 dangerous content by MailScanner, and is
 believed to be clean.

[Qemu-devel] Additional QEMU committer

[Anthony Liguori]

Hi,

Things have been moving a bit more slowly upstream than the should
recently.  I'm happy to announce though that Peter Maydell has agreed
to take on the responsibility of being a committer and will now be
able to apply pull requests and push patches.

I will continue to apply pull requests and patches when I can but
Peter will also be doing the same to make sure things move at a more
constant pace.

Big thanks to Peter for volunteering and for everyone for having
patience over the last couple months.

Regards,

Anthony Liguori

Re: [Qemu-devel] [PULL 00/18] Block patches

[Anthony Liguori]

I'm working through the backlog from the holidays.  I should be
through the full backlog today for PULL requests.

On Fri, Jan 10, 2014 at 10:06 AM, Paolo Bonzini pbonz...@redhat.com wrote:
 Il 10/01/2014 18:29, Stefan Weil ha scritto:
 Ping.

 QEMU compilation is broken on Debian hosts since several weeks now.
 These block patches include the fix. I'd appreciate if they could be pulled.

 And also all the other pull requests.  Seriously, if it was not for the
 few email messages on the disable TCG thread, I would have been worried
 about Anthony's health...

 Paolo

Re: [Qemu-devel] [PULL 00/50] migration queue

[Anthony Liguori]

I can't find the patches in my inbox but this breaks because
test-vmstate.c ignores ftruncate errors which are marked as
warn_unused_result on Ubuntu.

Regards,

Anthony Liguori

On Tue, Dec 24, 2013 at 8:06 AM, Juan Quintela quint...@redhat.com wrote:
 Hi Anthony

 This is the patches in the migration queue.  Please pull.

 This includes:

 - Eduardo refactorings  tests
 - Matthew rate limit fix
 - Zhanghaoyu CANCELLING fixes
 - My bitmap changes

 Integration work was done by Orit.

 Happy Christmas, Juan.


 The following changes since commit f976b09ea2493fd41c98aaf6512908db0bae:

   PPC: Fix compilation with TCG debug (2013-12-22 19:15:55 +0100)

 are available in the git repository at:

   git://github.com/juanquintela/qemu.git tags/migration/20131224

 for you to fetch changes up to bc864a4f0ce79a8f4c09bc479a81c5f919ee48f6:

   ram: align ram_addr_t's regions in multiples of 64 (2013-12-24 16:13:07 
 +0100)

 
 migration.next for 20131224

 
 Eduardo Habkost (9):
   qemu-file: Make a few functions non-static
   migration: Move QEMU_VM_* defines to migration/migration.h
   savevm: Convert all tabs to spaces
   savevm.c: Coding style fixes
   savevm.c: Coding style fix
   vmstate: Move VMState code to vmstate.c
   qemu-file: Move QEMUFile code to qemu-file.c
   savevm: Small comment about why timer QEMUFile/VMState code is in 
 savevm.c
   tests: Some unit tests for vmstate.c

 Juan Quintela (38):
   bitmap: use long as index
   memory: cpu_physical_memory_set_dirty_flags() result is never used
   memory: cpu_physical_memory_set_dirty_range() return void
   exec: use accessor function to know if memory is dirty
   memory: create function to set a single dirty bit
   exec: create function to get a single dirty bit
   memory: make cpu_physical_memory_is_dirty return bool
   memory: all users of cpu_physical_memory_get_dirty used only one flag
   memory: set single dirty flags when possible
   memory: cpu_physical_memory_set_dirty_range() always dirty all flags
   memory: cpu_physical_memory_mask_dirty_range() always clears a single 
 flag
   memory: use bit 2 for migration
   memory: make sure that client is always inside range
   memory: only resize dirty bitmap when memory size increases
   memory: cpu_physical_memory_clear_dirty_flag() result is never used
   bitmap: Add bitmap_zero_extend operation
   memory: split dirty bitmap into three
   memory: unfold cpu_physical_memory_clear_dirty_flag() in its only user
   memory: unfold cpu_physical_memory_set_dirty() in its only user
   memory: unfold cpu_physical_memory_set_dirty_flag()
   memory: make cpu_physical_memory_get_dirty() the main function
   memory: cpu_physical_memory_get_dirty() is used as returning a bool
   memory: s/mask/clear/ cpu_physical_memory_mask_dirty_range
   memory: use find_next_bit() to find dirty bits
   memory: cpu_physical_memory_set_dirty_range() now uses bitmap operations
   memory: cpu_physical_memory_clear_dirty_range() now uses bitmap 
 operations
   memory: s/dirty/clean/ in cpu_physical_memory_is_dirty()
   memory: make cpu_physical_memory_reset_dirty() take a length parameter
   memory: cpu_physical_memory_set_dirty_tracking() should return void
   memory: split cpu_physical_memory_* functions to its own include
   memory: unfold memory_region_test_and_clear()
   kvm: use directly cpu_physical_memory_* api for tracking dirty pages
   kvm: refactor start address calculation
   memory: move bitmap synchronization to its own function
   memory: syncronize kvm bitmap using bitmaps operations
   ram: split function that synchronizes a range
   migration: synchronize memory bitmap 64bits at a time
   ram: align ram_addr_t's regions in multiples of 64

 Matthew Garrett (1):
   migration: Fix rate limit

 Zhanghaoyu (A) (2):
   avoid a bogus COMPLETED-CANCELLED transition
   introduce MIG_STATE_CANCELLING state

  Makefile.objs  |2 +
  arch_init.c|   52 +-
  cputlb.c   |   11 +-
  exec.c |   78 +-
  include/exec/cpu-all.h |3 +-
  include/exec/memory-internal.h |   90 ---
  include/exec/memory.h  |   12 +-
  include/exec/ram_addr.h|  147 
  include/migration/migration.h  |   11 +
  include/migration/qemu-file.h  |4 +
  include/qemu/bitmap.h  |   86 ++-
  include/qemu/bitops.h  |   14 +-
  kvm-all.c  |   28 +-
  memory.c   |   17 +-
  migration.c|   33 +-
  qemu-file.c|  826 +
  savevm.c   | 1590 
 ++--
  tests

Re: [Qemu-devel] [Xen-devel] Project idea: make QEMU more flexible

[Anthony Liguori]

On Jan 6, 2014 6:23 AM, Peter Maydell peter.mayd...@linaro.org wrote:

 On 6 January 2014 14:17, Stefano Stabellini
 stefano.stabell...@eu.citrix.com wrote:
  It doesn't do any emulation so it is not specific to any architecture or
  any cpu.

 You presumably still care about the compiled in values of
 TARGET_WORDS_BIGENDIAN, TARGET_LONG_SIZE, and so on...

Yup.  It's still accel=xen just with no VCPUs.

Regards,

Anthony Liguori


 thanks
 -- PMM

Re: [Qemu-devel] [Xen-devel] Project idea: make QEMU more flexible

[Anthony Liguori]

On Jan 6, 2014 6:55 AM, Stefano Stabellini 
stefano.stabell...@eu.citrix.com wrote:

 On Mon, 6 Jan 2014, Anthony Liguori wrote:
  On Jan 6, 2014 6:23 AM, Peter Maydell peter.mayd...@linaro.org
wrote:
  
   On 6 January 2014 14:17, Stefano Stabellini
   stefano.stabell...@eu.citrix.com wrote:
It doesn't do any emulation so it is not specific to any
architecture or
any cpu.
  
   You presumably still care about the compiled in values of
   TARGET_WORDS_BIGENDIAN, TARGET_LONG_SIZE, and so on...

 Actually it only uses XC_PAGE_SIZE and the endianness is the host
 endianness.

If blkif in QEMU is relying on host endianness thats a bug.



  Yup.  It's still accel=xen just with no VCPUs.

 Are you talking about introducing accel=xen to Wei's target-null?
 I guess that would work OK.

We already have accel=xen.  I'm echoing Peter's suggestion of having the
ability to compile out accel=tcg.


 On the other hand if you are thinking of avoiding the introduction of a
 new target-null, how would you make xen_machine_pv.c available to
 multiple architectures?

Why does qdisk need a full machine?

How would you avoid the compilation of all the
 unnecessary emulated devices?

Device config files.

Regards,

Anthony Liguori

Re: [Qemu-devel] [Xen-devel] Project idea: make QEMU more flexible

[Anthony Liguori]

On Mon, Jan 6, 2014 at 7:57 AM, Stefano Stabellini
stefano.stabell...@eu.citrix.com wrote:
 On Mon, 6 Jan 2014, Anthony Liguori wrote:
 On Jan 6, 2014 6:55 AM, Stefano Stabellini 
 stefano.stabell...@eu.citrix.com wrote:
 
  On Mon, 6 Jan 2014, Anthony Liguori wrote:
   On Jan 6, 2014 6:23 AM, Peter Maydell peter.mayd...@linaro.org wrote:
   
On 6 January 2014 14:17, Stefano Stabellini
stefano.stabell...@eu.citrix.com wrote:
 It doesn't do any emulation so it is not specific to any 
 architecture or
 any cpu.
   
You presumably still care about the compiled in values of
TARGET_WORDS_BIGENDIAN, TARGET_LONG_SIZE, and so on...
 
  Actually it only uses XC_PAGE_SIZE and the endianness is the host
  endianness.

 If blkif in QEMU is relying on host endianness thats a bug.

 Why? Xen doesn't support a different guest/host endianness.

For the same reason that the virtio devices do not rely on host endianness.

It should be possible to use the Xen devices with TCG.  It isn't today
simply because the code wasn't structured that way but it could be
refactored to do this.

   Yup.  It's still accel=xen just with no VCPUs.
 
  Are you talking about introducing accel=xen to Wei's target-null?
  I guess that would work OK.

 We already have accel=xen.  I'm echoing Peter's suggestion of having the 
 ability to compile out accel=tcg.

 
  On the other hand if you are thinking of avoiding the introduction of a
  new target-null, how would you make xen_machine_pv.c available to
  multiple architectures?

 Why does qdisk need a full machine?

 qdisk is just one device, xen_machine_pv is the machine that initializes
 the backend infrastructure (one of the backends is qdisk).
 It doesn't make sense to use a full-blown machine like pc.c just to
 start few backends, right?

What prevents xen_machine_pv from being compiled for multiple targets?
 If there i386 specific things in it, they surely could be refactored
a bit, no?

Regards,

Anthony Liguori



 How would you avoid the compilation of all the
  unnecessary emulated devices?

 Device config files.

Re: [Qemu-devel] [PULL 0/8] s390 patch queue 2013-12-18

[Anthony Liguori]

Alexander Graf ag...@suse.de writes:

 Hi Blue / Aurelien / Anthony,

 This is my current patch queue for s390.  Please pull.

 Alex


 The following changes since commit f46e720a82ccdf1a521cf459448f3f96ed895d43:
   Laszlo Ersek (1):
 qemu_opts_parse(): always check return value

 are available in the git repository at:

   git://github.com/agraf/qemu.git s390-for-upstream

Are you requesting the pull of the tag or the branch?

You previously submitted signed tags.

Regards,

Anthony Liguori


 Cornelia Huck (1):
   s390x/kvm: Fix diagnose handling.

 Thomas Huth (7):
   s390x/kvm: Removed duplicated SIGP defines
   s390x/kvm: Removed s390_store_status stub
   s390x/kvm: Fix coding style in handle_sigp()
   s390x/kvm: Implemented SIGP START
   s390x/kvm: Simplified the calculation of the SIGP order code
   s390x/kvm: Fixed condition code for unknown SIGP orders
   s390x/ioinst: CHSC has to set a condition code

  target-s390x/cpu.h|3 +
  target-s390x/ioinst.c |1 +
  target-s390x/kvm.c|   98 
 +++--
  3 files changed, 50 insertions(+), 52 deletions(-)

Re: [Qemu-devel] [PULL 00/62] target-arm queue

[Anthony Liguori]

Peter Maydell peter.mayd...@linaro.org writes:

 Only took a week for the target-arm queue to fill up again :-)
 Please pull...

ubuntu@build:~/build/qemu$ make
  CCaarch64-softmmu/gdbstub-xml.o
  CCaarch64-softmmu/target-arm/cpu.o
/home/ubuntu/git/qemu/target-arm/cpu.c: In function ‘arm_cpu_post_init’:
/home/ubuntu/git/qemu/target-arm/cpu.c:260:9: error: implicit declaration of 
function ‘assert_no_error’ [-Werror=implicit-function-declaration]
/home/ubuntu/git/qemu/target-arm/cpu.c:260:9: error: nested extern declaration 
of ‘assert_no_error’ [-Werror=nested-externs]
cc1: all warnings being treated as errors
make[1]: *** [target-arm/cpu.o] Error 1
make: *** [subdir-aarch64-softmmu] Error 2

Regards,

Anthony Liguori


 thanks
 -- PMM

 The following changes since commit f46e720a82ccdf1a521cf459448f3f96ed895d43:

   qemu_opts_parse(): always check return value (2013-12-16 15:33:48 -0800)

 are available in the git repository at:

   git://git.linaro.org/people/pmaydell/qemu-arm.git 
 tags/pull-target-arm-20131217

 for you to fetch changes up to 84291fe7a34f8c2d595bcdb77ff506d1d60fcd7c:

   MAINTAINERS: add myself to maintain allwinner-a10 (2013-12-17 20:12:51 
 +)

 
 target-arm queue:
  * AES instruction support for 32 bit ARM
  * pflash01: much better emulation of 2x16bit and similar configs
where multiple flash devices are banked together
  * fixed CBAR handling on Zynq, Highbank
  * initial AArch64 KVM control support
  * first two chunks of patches for A64 instruction emulation
  * new board: canon-a1100 (Canon DIGIC SoC)
  * new board: cubieboard (Allwinner A10 SoC)

 
 Alexander Graf (14):
   target-arm: A64: add set_pc cpu method
   target-arm: A64: add stubs for a64 specific helpers
   target-arm: A64: add support for B and BL insns
   target-arm: A64: add support for BR, BLR and RET insns
   target-arm: A64: add support for conditional branches
   target-arm: A64: add support for 'test and branch' imm
   target-arm: A64: add support for compare and branch imm
   target-arm: A64: add support for logical (shifted register)
   target-arm: A64: add support for ADR and ADRP
   target-arm: A64: add support for EXTR
   target-arm: A64: add support for 2-src data processing and DIV
   target-arm: A64: add support for 2-src shift reg insns
   target-arm: A64: add support for 1-src RBIT insn
   target-arm: A64: add support for logical (immediate) insns

 Antony Pavlov (8):
   ARM: cpu: add reset_hivecs property
   ARM: arm_cpu_reset: make it possible to use high vectors for reset_exc
   hw/arm: add very initial support for Canon DIGIC SoC
   hw/arm/digic: prepare DIGIC-based boards support
   hw/arm/digic: add timer support
   hw/arm/digic: add UART support
   hw/arm/digic: add NOR ROM support
   MAINTAINERS: Document 'Canon DIGIC' machine

 Ard Biesheuvel (1):
   target-arm: add support for v8 AES instructions

 Claudio Fontana (8):
   target-arm: A64: provide skeleton for a64 insn decoding
   target-arm: A64: expand decoding skeleton for system instructions
   target-arm: A64: add support for conditional select
   target-arm: A64: add support for 1-src data processing and CLZ
   target-arm: A64: add support for 1-src REV insns
   target-arm: A64: add support for bitfield insns
   host-utils: add clrsb32/64 - count leading redundant sign bits
   target-arm: A64: add support for 1-src CLS insn

 Mian M. Hamayun (2):
   target-arm: Add minimal KVM AArch64 support
   hw/arm/boot: Add boot support for AArch64 processor

 Peter Crosthwaite (8):
   target-arm/helper.c: Allow cp15.c15 dummy override
   target-arm: Define and use ARM_FEATURE_CBAR
   target-arm/cpu: Convert reset CBAR to a property
   arm/highbank: Use object_new() rather than cpu_arm_init()
   arm/highbank: Fix CBAR initialisation
   arm/xilinx_zynq: Use object_new() rather than cpu_arm_init()
   arm/xilinx_zynq: Implement CBAR initialisation
   arm/highbank.c: Fix MPCore periphbase name

 Peter Maydell (9):
   target-arm/kvm: Split 32 bit only code into its own file
   target-arm: Clean up handling of AArch64 PSTATE
   configure: Enable KVM for aarch64 host/target combination
   hw/arm/boot: Allow easier swapping in of different loader code
   default-configs: Add config for aarch64-softmmu
   target-arm: Split A64 from A32/T32 gen_intermediate_code_internal()
   target-arm: A64: provide functions for accessing FPCR and FPSR
   target-arm: Support fp registers in gdb stub
   vmstate: Add support for an array of ptimer_state *

 Roy Franz (7):
   rename pflash_t member width to bank_width
   Add device-width property to pflash_cfi01
   return status for each NOR flash device
   Set proper

Re: [Qemu-devel] [PULL 00/13] QMP queue

[Anthony Liguori]

On Wed, Dec 18, 2013 at 8:59 AM, Luiz Capitulino lcapitul...@redhat.com wrote:
 The following changes since commit e157b8fdd412d48eacfbb8c67d3d58780154faa3:

   Merge remote-tracking branch 'bonzini/virtio' into staging (2013-12-13 
 11:10:33 -0800)

 are available in the git repository at:

Sorry, you lost the merge conflict to Peter.  Can you please rebase
and resubmit?

Regards,

Anthony Liguori



   git://repo.or.cz/qemu/qmp-unstable.git queue/qmp

 for you to fetch changes up to 2e89b6d1cd378602f2c8ea982145213aededf0f2:

   qemu-monitor: HMP cpu-add wrapper (2013-12-18 11:12:16 -0500)

 
 Jason J. Herne (1):
   qemu-monitor: HMP cpu-add wrapper

 Paolo Bonzini (6):
   vl: add missing transition debug-finish_migrate
   rng: initialize file descriptor to -1
   qom: fix leak for objects created with -object
   qom: catch errors in object_property_add_child
   monitor: add object-add (QMP) and object_add (HMP) command
   monitor: add object-del (QMP) and object_del (HMP) command

 Peter Crosthwaite (6):
   error: Add error_abort
   hw/core/qdev: Delete dead code
   hw: Remove assert_no_error usages
   target-i386: Remove assert_no_error usage
   qemu-option: Remove qemu_opts_create_nofail
   qerror: Remove assert_no_error()

  backends/rng-random.c|  4 +--
  block/blkdebug.c |  2 +-
  block/blkverify.c|  2 +-
  block/curl.c |  2 +-
  block/gluster.c  |  2 +-
  block/iscsi.c|  2 +-
  block/nbd.c  |  3 +-
  block/qcow2.c|  2 +-
  block/raw-posix.c|  2 +-
  block/raw-win32.c|  5 +--
  block/rbd.c  |  2 +-
  block/sheepdog.c |  2 +-
  block/vvfat.c|  2 +-
  blockdev.c   |  6 ++--
  hmp-commands.hx  | 41 +
  hmp.c| 77 
 
  hmp.h|  3 ++
  hw/core/qdev-properties-system.c |  8 ++---
  hw/core/qdev-properties.c| 40 ++---
  hw/core/qdev.c   | 28 ---
  hw/dma/xilinx_axidma.c   | 13 +++
  hw/net/xilinx_axienet.c  | 13 +++
  hw/watchdog/watchdog.c   |  3 +-
  include/hw/xilinx.h  | 14 +++-
  include/monitor/monitor.h|  3 ++
  include/qapi/error.h |  6 
  include/qapi/qmp/qerror.h|  1 -
  include/qapi/visitor.h   |  3 +-
  include/qemu/option.h|  1 -
  include/qemu/typedefs.h  |  2 ++
  qapi-schema.json | 34 ++
  qdev-monitor.c   |  2 +-
  qemu-img.c   |  2 +-
  qmp-commands.hx  | 51 ++
  qmp.c| 75 ++
  qobject/qerror.c |  8 -
  qom/object.c |  9 +++--
  target-i386/cpu.c|  4 +--
  util/error.c | 22 +++-
  util/qemu-config.c   |  2 +-
  util/qemu-option.c   |  9 -
  util/qemu-sockets.c  | 18 +-
  vl.c | 19 ++
  43 files changed, 400 insertions(+), 149 deletions(-)

 --
 1.8.1.4

Re: [Qemu-devel] [PATCH 00/11 v3] Refactor PCI/SHPC/PCIE hotplug to use a more generic hotplug API

[Anthony Liguori]

On Tue, Dec 17, 2013 at 4:38 AM, Paolo Bonzini pbonz...@redhat.com wrote:
 Il 17/12/2013 00:26, Anthony Liguori ha scritto:
 Sharing hot plug code is a good thing.  Making hotplug a qdev-level
 concept seems like a bad thing to me.

 Can you explain what you mean?

The question is whether hotpluggable as a property applies to all
devices or not.

But hotplug is strictly a bus level concept.  It's a sequence of
events that correspond to what happens when you add a new device to a
bus after power on.

 The series is a net add of code so I don't think we're winning anything
 by generalizing here.

 Any generalization that's used just once will be a net add of code (and
 this code will be reused by SCSI and x86 memory hotplug at least;
 perhaps x86 CPU hotplug too).

The question is whether there can be code sharing without touching the
base class.  You could certainly have a HotpluggableBusState and then
a HotpluggableDeviceState.

Interfaces would be another option too.

 Any generalization that requires some boilerplate code will be a net add
 of code, too.  QEMU being written in C, we unfortunately cannot avoid that.

 So I don't think that lines of code are a good metric.

The general concern is about polluting widely used base classes.  It's
better if we can avoid adding things to DeviceState and Object
whenever possible.

Regards,

Anthony Liguori

 Paolo

 Is there a use-case this enables that isn't possible today?

 Regards,

 Anthony Liguori


 Patches 8-11 are should be merged as one and are split only for
 simplifying review (they compile fine but PCI hotplug is broken
 until the last patch is applyed).

 git tree for testing:
 https://github.com/imammedo/qemu/commits/hotplug_dev_inf_v3

 tested only ACPI and PCIE hotplug.

 Hervé Poussineau (1):
   qom: detect bad reentrance during object_class_foreach

 Igor Mammedov (9):
   define hotplug interface
   qdev: add to BusState hotplug-handler link
   qdev: add hotpluggable property to Device
   hw/acpi: move typeinfo to the file end
   qdev:pci: refactor PCIDevice to use generic hotpluggable property
   acpi/piix4pm: convert ACPI PCI hotplug to use hotplug-handler API
   pci/shpc: convert SHPC hotplug to use hotplug-handler API
   pci/pcie: convert PCIE hotplug to use hotplug-handler API
   hw/pci: switch to a generic hotplug handling for PCIDevice

 Paolo Bonzini (1):
   qom: do not register interface types in the type table

  hw/acpi/piix4.c| 151 
 ++---
  hw/core/Makefile.objs  |   1 +
  hw/core/hotplug.c  |  48 +
  hw/core/qdev.c |  50 --
  hw/display/cirrus_vga.c|   2 +-
  hw/display/qxl.c   |   2 +-
  hw/display/vga-pci.c   |   2 +-
  hw/display/vmware_vga.c|   2 +-
  hw/i386/acpi-build.c   |   6 +-
  hw/ide/piix.c  |   4 +-
  hw/isa/piix4.c |   2 +-
  hw/pci-bridge/pci_bridge_dev.c |   9 +++
  hw/pci-host/piix.c |   6 +-
  hw/pci/pci.c   |  40 +--
  hw/pci/pcie.c  |  73 +---
  hw/pci/pcie_port.c |   8 +++
  hw/pci/shpc.c  | 133 +++-
  hw/usb/hcd-ehci-pci.c  |   2 +-
  hw/usb/hcd-ohci.c  |   2 +-
  hw/usb/hcd-uhci.c  |   2 +-
  hw/usb/hcd-xhci.c  |   2 +-
  include/hw/hotplug.h   |  75 
  include/hw/pci/pci.h   |  13 
  include/hw/pci/pci_bus.h   |   2 -
  include/hw/pci/pcie.h  |   5 ++
  include/hw/pci/shpc.h  |   8 +++
  include/hw/qdev-core.h |   8 +++
  qom/object.c   |  17 -
  28 files changed, 455 insertions(+), 220 deletions(-)
  create mode 100644 hw/core/hotplug.c
  create mode 100644 include/hw/hotplug.h

 --
 1.8.3.1

Re: [Qemu-devel] [PATCH RFC 1/2] rng-egd: improve egd backend performance

[Anthony Liguori]

On Mon, Dec 16, 2013 at 8:36 AM, Amit Shah amit.s...@redhat.com wrote:
 On (Mon) 09 Dec 2013 [22:10:12], Amos Kong wrote:
 Bugzilla: https://bugs.launchpad.net/qemu/+bug/1253563

 We have a requests queue to cache the random data, but the second
 will come in when the first request is returned, so we always
 only have one items in the queue. It effects the performance.

 This patch changes the IOthread to fill a fixed buffer with
 random data from egd socket, request_entropy() will return
 data to virtio queue if buffer has available data.

 (test with a fast source, disguised egd socket)
  # cat /dev/urandom | nc -l localhost 8003
  # qemu .. -chardev socket,host=localhost,port=8003,id=chr0 \
 -object rng-egd,chardev=chr0,id=rng0,buf_size=1024 \
 -device virtio-rng-pci,rng=rng0

 First thing I can think of is the egd protocol has a length field in
 the header, and if that isn't properly filled, the results are bound
 to be erratic.

The test is bogus.

egd is a protocol.  You can't just pipe /dev/urandom into it.

Regards,

Anthony Liguori


 I haven't been able to find a spec detailing the way egd API, perhaps
 Anthony knows how to best pass data to qemu via egd.

 Amit

Re: [Qemu-devel] [PATCH 05/11] qdev: add hotpluggable property to Device

[Anthony Liguori]

On Fri, Dec 13, 2013 at 4:44 AM, Igor Mammedov imamm...@redhat.com wrote:
 Currently it's possible to make PCIDevice not hotpluggable by using
 no_hotplug field of PCIDeviceClass. However it limits this
 only to PCI devices and prevents from generalizing hotplug code.

 So add similar field to DeviceClass so it could be reused with other
 Devices and would allow to replace PCI specific hotplug callbacks
 with generic implementation.

 In addition expose field as hotpluggable readonly property, to make
 it possible to get it via QOM interface.

 Make DeviceClass hotpluggable by default as it was assumed before.

 Signed-off-by: Igor Mammedov imamm...@redhat.com

Pushing stuff to a base class in order to reuse code isn't the right
way to model things.

hotplug is a bus concept.  It doesn't apply widely to all possible devices.

Regards,

Anthony Liguori

 ---
 v4:
 * s/hotplugable/hotpluggable/

 v3:
 * make DeviceClass hotpluggable by default
   Since PCIDevice still uses internal no_hotlpug checks it shouldn't
   reggress. And follow up patch that converts PCIDevices to use
   hotpluggable property will take care about not hotpluggable PCI
   devices explicitly setting hotpluggable to false in their class_init().

 * move generic hotplug checks from
   7/11 qdev:pci: refactor PCIDevice to use generic hotplugable property
   to this patch
 ---
  hw/core/qdev.c | 29 +
  include/hw/qdev-core.h |  3 +++
  2 files changed, 32 insertions(+)

 diff --git a/hw/core/qdev.c b/hw/core/qdev.c
 index 25c2d2c..9418fea 100644
 --- a/hw/core/qdev.c
 +++ b/hw/core/qdev.c
 @@ -215,6 +215,12 @@ void qdev_unplug(DeviceState *dev, Error **errp)
  }
  assert(dc-unplug != NULL);

 +if (!dc-hotpluggable) {
 +error_set(errp, QERR_DEVICE_NO_HOTPLUG,
 +  object_get_typename(OBJECT(dev)));
 +return;
 +}
 +
  qdev_hot_removed = true;

  if (dc-unplug(dev)  0) {
 @@ -679,6 +685,11 @@ static void device_set_realized(Object *obj, bool value, 
 Error **err)
  DeviceClass *dc = DEVICE_GET_CLASS(dev);
  Error *local_err = NULL;

 +if (dev-hotplugged  !dc-hotpluggable) {
 +error_set(err, QERR_DEVICE_NO_HOTPLUG, object_get_typename(obj));
 +return;
 +}
 +
  if (value  !dev-realized) {
  if (!obj-parent  local_err == NULL) {
  static int unattached_count;
 @@ -719,6 +730,14 @@ static void device_set_realized(Object *obj, bool value, 
 Error **err)
  dev-realized = value;
  }

 +static bool device_get_hotpluggable(Object *obj, Error **err)
 +{
 +DeviceClass *dc = DEVICE_GET_CLASS(obj);
 +DeviceState *dev = DEVICE(obj);
 +
 +return dc-hotpluggable  dev-parent_bus-allow_hotplug;
 +}
 +
  static void device_initfn(Object *obj)
  {
  DeviceState *dev = DEVICE(obj);
 @@ -736,6 +755,8 @@ static void device_initfn(Object *obj)

  object_property_add_bool(obj, realized,
   device_get_realized, device_set_realized, NULL);
 +object_property_add_bool(obj, hotpluggable,
 + device_get_hotpluggable, NULL, NULL);

  class = object_get_class(OBJECT(dev));
  do {
 @@ -784,6 +805,14 @@ static void device_class_base_init(ObjectClass *class, 
 void *data)
   * so do not propagate them to the subclasses.
   */
  klass-props = NULL;
 +
 +/* by default all devices were considered as hotpluggable,
 + * so with intent to check it in generic qdev_unplug() /
 + * device_set_realized() functions make every device
 + * hotpluggable. Devices that shouldn't be hoplugable,
 + * should override it in their class_init()
 + */
 +klass-hotpluggable = true;
  }

  static void device_unparent(Object *obj)
 diff --git a/include/hw/qdev-core.h b/include/hw/qdev-core.h
 index 684a5da..04bbef4 100644
 --- a/include/hw/qdev-core.h
 +++ b/include/hw/qdev-core.h
 @@ -50,6 +50,8 @@ struct VMStateDescription;
   * is changed to %true. Deprecated, new types inheriting directly from
   * TYPE_DEVICE should use @realize instead, new leaf types should consult
   * their respective parent type.
 + * @hotpluggable: booleean indicating if #DeviceClass is hotpluggable, 
 available
 + * as readonly hotpluggable property of #DeviceState instance
   *
   * # Realization #
   * Devices are constructed in two stages,
 @@ -99,6 +101,7 @@ typedef struct DeviceClass {
  const char *desc;
  Property *props;
  int no_user;
 +bool hotpluggable;

  /* callbacks */
  void (*reset)(DeviceState *dev);
 --
 1.8.3.1

Re: [Qemu-devel] [PATCH 00/11 v3] Refactor PCI/SHPC/PCIE hotplug to use a more generic hotplug API

[Anthony Liguori]

Igor Mammedov imamm...@redhat.com writes:

 changes since v2:
 * s/hotplugable/hotpluggable/
 * move hotplug check to an earlier patch:
   qdev: add hotpluggable property to Device
 --
 Refactor PCI specific hotplug API to a more generic/reusable one.
 Model it after SCSI-BUS like hotplug API replacing single hotplug
 callback with hotplug/hot_unplug pair of callbacks as suggested by
 Paolo.
 Difference between SCSI-BUS and this approach is that the former
 is BUS centric while the latter is device centred. Which is evolved
 from the fact that hotplug callbacks used by ACPI/SHPC/PCIE are
 implemented by devices rather than by bus and bus serves only as
 a proxy to forward event to hotplug device.
 Memory hotplug also exposes tha same usage pattern hence an attempt
 to generalize hotplug API.

 Refactoring also simplifies wiring of a hotplug device with a bus,
 all it needs is to set hotplug-device link on bus, which
 would potentially allow to do it from configuration file,
 there is not need to setup hotplug device callbacks on bus
 synce it can get them via HOTPLUG_DEVICE API of hotplug-device
 target.

 In addition device centred hotplug API may be used by bus-less
 hotplug implementations as well if it's decided to use
 linkfoo... instead of bus.

I'm having a hard time parsing this description.

Sharing hot plug code is a good thing.  Making hotplug a qdev-level
concept seems like a bad thing to me.

The series is a net add of code so I don't think we're winning anything
by generalizing here.

Is there a use-case this enables that isn't possible today?

Regards,

Anthony Liguori


 Patches 8-11 are should be merged as one and are split only for
 simplifying review (they compile fine but PCI hotplug is broken
 until the last patch is applyed).

 git tree for testing:
 https://github.com/imammedo/qemu/commits/hotplug_dev_inf_v3

 tested only ACPI and PCIE hotplug.

 Hervé Poussineau (1):
   qom: detect bad reentrance during object_class_foreach

 Igor Mammedov (9):
   define hotplug interface
   qdev: add to BusState hotplug-handler link
   qdev: add hotpluggable property to Device
   hw/acpi: move typeinfo to the file end
   qdev:pci: refactor PCIDevice to use generic hotpluggable property
   acpi/piix4pm: convert ACPI PCI hotplug to use hotplug-handler API
   pci/shpc: convert SHPC hotplug to use hotplug-handler API
   pci/pcie: convert PCIE hotplug to use hotplug-handler API
   hw/pci: switch to a generic hotplug handling for PCIDevice

 Paolo Bonzini (1):
   qom: do not register interface types in the type table

  hw/acpi/piix4.c| 151 
 ++---
  hw/core/Makefile.objs  |   1 +
  hw/core/hotplug.c  |  48 +
  hw/core/qdev.c |  50 --
  hw/display/cirrus_vga.c|   2 +-
  hw/display/qxl.c   |   2 +-
  hw/display/vga-pci.c   |   2 +-
  hw/display/vmware_vga.c|   2 +-
  hw/i386/acpi-build.c   |   6 +-
  hw/ide/piix.c  |   4 +-
  hw/isa/piix4.c |   2 +-
  hw/pci-bridge/pci_bridge_dev.c |   9 +++
  hw/pci-host/piix.c |   6 +-
  hw/pci/pci.c   |  40 +--
  hw/pci/pcie.c  |  73 +---
  hw/pci/pcie_port.c |   8 +++
  hw/pci/shpc.c  | 133 +++-
  hw/usb/hcd-ehci-pci.c  |   2 +-
  hw/usb/hcd-ohci.c  |   2 +-
  hw/usb/hcd-uhci.c  |   2 +-
  hw/usb/hcd-xhci.c  |   2 +-
  include/hw/hotplug.h   |  75 
  include/hw/pci/pci.h   |  13 
  include/hw/pci/pci_bus.h   |   2 -
  include/hw/pci/pcie.h  |   5 ++
  include/hw/pci/shpc.h  |   8 +++
  include/hw/qdev-core.h |   8 +++
  qom/object.c   |  17 -
  28 files changed, 455 insertions(+), 220 deletions(-)
  create mode 100644 hw/core/hotplug.c
  create mode 100644 include/hw/hotplug.h

 -- 
 1.8.3.1

Re: [Qemu-devel] [PATCH] Python-lang gdb script to extract x86_64 guest vmcore from qemu coredump

[Anthony Liguori]

:15.904289203 +0200
 @@ -22,11 +22,11 @@
  This GDB was configured as x86_64-unknown-linux-gnu...

   KERNEL: /usr/lib/debug/lib/modules/2.6.32-358.el6.x86_64/vmlinux
 -DUMPFILE: /home/lacos/tmp/guest.vmcore
 +DUMPFILE: /home/lacos/tmp/example.dump
  CPUS: 4
 -DATE: Thu Sep 12 17:16:11 2013
 -  UPTIME: 00:01:09
 -LOAD AVERAGE: 0.07, 0.03, 0.00
 +DATE: Thu Sep 12 17:17:41 2013
 +  UPTIME: 00:00:38
 +LOAD AVERAGE: 0.18, 0.05, 0.01
 TASKS: 130
  NODENAME: localhost.localdomain
   RELEASE: 2.6.32-358.el6.x86_64
 @@ -38,12 +38,12 @@
   COMMAND: swapper
  TASK: 81a8d020  (1 of 4)  [THREAD_INFO: 81a0]
   CPU: 0
 -   STATE: TASK_RUNNING (PANIC)
 +   STATE: TASK_RUNNING (ACTIVE)
 + WARNING: panic task not found

  crash bt
  PID: 0  TASK: 81a8d020  CPU: 0   COMMAND: swapper
 - #0 [81a01ed0] default_idle at 8101495d
 - #1 [81a01ef0] cpu_idle at 81009fc6
 + #0 [81a01ef0] cpu_idle at 81009fc6
  crash task 81a8d020
  PID: 0  TASK: 81a8d020  CPU: 0   COMMAND: swapper
  struct task_struct {
 @@ -75,7 +75,7 @@
prev = 0x81a8d080
  },
  on_rq = 0,
 -exec_start = 8618466836,
 +exec_start = 7469214014,
  sum_exec_runtime = 0,
  vruntime = 0,
  prev_sum_exec_runtime = 0,
 @@ -149,7 +149,7 @@
},
tasks = {
  next = 0x88002d621948,
 -prev = 0x880029618f28
 +prev = 0x880023b74488
},
pushable_tasks = {
  prio = 140,
 @@ -165,7 +165,7 @@
  }
},
mm = 0x0,
 -  active_mm = 0x88002929b780,
 +  active_mm = 0x8800297eb980,
exit_state = 0,
exit_code = 0,
exit_signal = 0,
 @@ -177,7 +177,7 @@
sched_reset_on_fork = 0,
pid = 0,
tgid = 0,
 -  stack_canary = 2483693585637059287,
 +  stack_canary = 7266362296181431986,
real_parent = 0x81a8d020,
parent = 0x81a8d020,
children = {
 @@ -224,14 +224,14 @@
set_child_tid = 0x0,
clear_child_tid = 0x0,
utime = 0,
 -  stime = 3,
 +  stime = 2,
utimescaled = 0,
 -  stimescaled = 3,
 +  stimescaled = 2,
gtime = 0,
prev_utime = 0,
prev_stime = 0,
nvcsw = 0,
 -  nivcsw = 1000,
 +  nivcsw = 1764,
start_time = {
  tv_sec = 0,
  tv_nsec = 0

 - name_droppingI asked for Dave Anderson's help with verifying the
   extracted vmcore, and his comments make me think I should post
   this./name_dropping

 Signed-off-by: Laszlo Ersek ler...@redhat.com
 ---
  scripts/dump-guest-memory.py |  336 
 ++
  1 files changed, 336 insertions(+), 0 deletions(-)
  create mode 100644 scripts/dump-guest-memory.py

 diff --git a/scripts/dump-guest-memory.py b/scripts/dump-guest-memory.py
 new file mode 100644
 index 000..e66315a
 --- /dev/null
 +++ b/scripts/dump-guest-memory.py
 @@ -0,0 +1,336 @@
 +# This python script adds a new gdb command, dump-guest-memory. It
 +# should be loaded with source dump-guest-memory.py at the (gdb)
 +# prompt.
 +#
 +# Copyright (C) 2013, Red Hat, Inc.
 +#
 +# Authors:
 +#   Laszlo Ersek ler...@redhat.com
 +#
 +# The leading docstring doesn't have idiomatic Python formatting. It is
 +# printed by gdb's help command (the first line is printed in the
 +# help data summary), and it should match how other help texts look in
 +# gdb.

You need to add a license to this file.

Regards,

Anthony Liguori

 +
 +import struct
 +
 +class DumpGuestMemory(gdb.Command):
 +Extract guest vmcore from qemu process coredump.
 +
 +The sole argument is FILE, identifying the target file to write the
 +guest vmcore to.
 +
 +This GDB command reimplements the dump-guest-memory QMP command in
 +python, using the representation of guest memory as captured in the qemu
 +coredump. The qemu process that has been dumped must have had the
 +command line option -machine dump-guest-core=on.
 +
 +For simplicity, the paging, begin and end parameters of the QMP
 +command are not supported -- no attempt is made to get the guest's
 +internal paging structures (ie. paging=false is hard-wired), and guest
 +memory is always fully dumped.
 +
 +Only x86_64 guests are supported.
 +
 +The CORE/NT_PRSTATUS and QEMU notes (that is, the VCPUs' statuses) are
 +not written to the vmcore. Preparing these would require context that is
 +only present in the KVM host kernel module when the guest is alive. A
 +fake ELF note is written instead, only to keep the ELF parser of crash
 +happy.
 +
 +Dependent on how busted the qemu process was at the time of the
 +coredump, this command might produce unpredictable results. If qemu
 +deliberately called abort(), or it was dumped in response to a signal at
 +a halfway fortunate point, then its coredump should be in reasonable
 +shape and this command should mostly work.
 +
 +TARGET_PAGE_SIZE = 0x1000
 +TARGET_PAGE_MASK = 0xF000
 +
 +# Various ELF constants

Re: [Qemu-devel] [PULL 00/30] virtio conversion to realize and hotplug/unplug fixes

[Anthony Liguori]

On Dec 13, 2013 7:50 AM, Paolo Bonzini pbonz...@redhat.com wrote:

 Il 11/12/2013 08:45, Paolo Bonzini ha scritto:
   Anthony,
  
   the following changes since commit
7dc65c02fe3fb8f3146ce0b9ff5fec5945329f0e:
  
 Open 2.0 development tree (2013-11-27 14:02:45 -0800)
  
   This also conflicts badly.
  This doesn't conflict here either.  What files are conflicting exactly?

 FWIW, I tried again merging and it all went smoothly:

I'll try again.


 $ git pull  git://github.com/bonzini/qemu.git virtio
 Da git://github.com/bonzini/qemu
  * branchvirtio - FETCH_HEAD
 Auto-merging hw/net/virtio-net.c
 Merge made by the 'recursive' strategy.
  hw/9pfs/virtio-9p-device.c  |  43 +++---
  hw/block/dataplane/virtio-blk.c |  30 +-
  hw/block/dataplane/virtio-blk.h |   5 +-
  hw/block/virtio-blk.c   |  47 ++--
  hw/char/virtio-serial-bus.c |  33 +--
  hw/net/virtio-net.c |  36 ++--
  hw/s390x/virtio-ccw.c   |  83 +++
  hw/s390x/virtio-ccw.h   |   1 -
  hw/scsi/vhost-scsi.c|  45 +++
  hw/scsi/virtio-scsi.c   |  57 +--
  hw/virtio/virtio-balloon.c  |  32 +--
  hw/virtio/virtio-bus.c  |  80 +++---
  hw/virtio/virtio-mmio.c |   9 +--
  hw/virtio/virtio-pci.c  | 122

  hw/virtio/virtio-pci.h  |   1 -
  hw/virtio/virtio-rng.c  |  43 +++---
  hw/virtio/virtio.c  |  40 -
  include/hw/virtio/virtio-bus.h  |  22 +---
  include/hw/virtio/virtio-rng.h  |   2 +
  include/hw/virtio/virtio-scsi.h |   4 +-
  include/hw/virtio/virtio.h  |   8 ++-
  tests/qdev-monitor-test.c   |   4 +-
  22 files changed, 413 insertions(+), 334 deletions(-)

 $ git pull  git://github.com/bonzini/qemu.git scsi-next
 Da git://github.com/bonzini/qemu
  * branchscsi-next  - FETCH_HEAD
 Auto-merging qemu-options.hx
 Auto-merging hw/scsi/scsi-bus.c
 Auto-merging configure
 Merge made by the 'recursive' strategy.
  block/iscsi.c   | 401
++--
  configure   |   6 +-
  hw/scsi/scsi-bus.c  |  14 +-
  hw/scsi/scsi-disk.c |  29 ++--
  qemu-options.hx |   2 +-
  5 files changed, 143 insertions(+), 309 deletions(-)

 So I'm not going to resend these series.  In particular the beginning of
 the virtio series needs to be backported to 1.7.1 (it fixes a crash),
which
 is why I based it on an earlier commit than usual.

 The SCSI patches might conflict with Kevin's 512-on-4K changes so I might
 have to resend that one anyway, but that's a different story and I'll get
 there when it happens. :)

 Please confirm that it works for you, or describe your breakage.  I'm
using
 git 1.8.4.2 in case that matters.

 Paolo

Re: [Qemu-devel] KVM call agenda for 2013-12-10

[Anthony Liguori]

On Tue, Dec 10, 2013 at 4:54 AM, Markus Armbruster arm...@redhat.com wrote
 Paolo Bonzini pbonz...@redhat.com writes:

 Il 10/12/2013 12:42, Juan Quintela ha scritto:

 Hi

 Please, send any topic that you are interested in covering.

 May not need a phone call, but I'll drop it here: what happened to
 acknowledgement emails from the patches script?

 Also, Anthony, it looks like you're still adjusting to the new job.  If
 you need help with anything, I guess today's call could be a good place
 to discuss it.

 And someone needs to send out the email saying that 1.7.0 is out and
 that the next version will be 2.0!

 Speaking of sending out e-mail: did I miss the promised followup to the
 key signing party?

I need to find the papers from KVM Forum which are somewhere among the
stacks of boxes here :-/

Regards,

Anthony Liguori

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

[Qemu-devel] [ANNOUNCE] QEMU 1.7.0 is now available

[Anthony Liguori]

Hi,

On behalf of the QEMU Team, I'd like to announce the availability of the
the QEMU 1.7 release. This release consists of 1300+ changesets from
126 authors.

http://wiki.qemu.org/download/qemu-1.7.0.tar.bz2

The full list of changes are available at:

http://wiki.qemu.org/ChangeLog/1.7

Highlights include:

 * Configurable MSI-X affinity with VFIO
 * USB 3.0 emulation improvements
 * Generation of ACPI tables within QEMU
 * S3 support for Xen HVM
 * New throttling algorithm for block devices
 * Support for filesystem freeze/thaw on Windows guests
 * TCG host support for x32
 * And much more...

Regards,

Anthony Liguori

Re: [Qemu-devel] KVM call agenda for 2013-12-10

[Anthony Liguori]

On Tue, Dec 10, 2013 at 4:37 AM, Paolo Bonzini pbonz...@redhat.com wrote:
 Il 10/12/2013 12:42, Juan Quintela ha scritto:

 Hi

 Please, send any topic that you are interested in covering.

 May not need a phone call, but I'll drop it here:

Could we move the time on this phone call?  7am conflicts with my
daily commute.  I could do 6am or 9am.  I think it would be very
useful to be able to attend this call.

 what happened to
 acknowledgement emails from the patches script?

It's buggy and I haven't had a chance to rewrite it yet.

 Also, Anthony, it looks like you're still adjusting to the new job.  If
 you need help with anything, I guess today's call could be a good place
 to discuss it.

 And someone needs to send out the email saying that 1.7.0 is out and
 that the next version will be 2.0!

Mail is out now, sorry for the delay.

Pull requests should be getting processed in a reasonable time.  I am
not yet spending enough time doing patch review but that should
improve in the very near future.

It's not so much the new job as it is relocating and moving all at the
same time.  I'm hoping the holiday break is a good way to catch up
things.  Of course, we should revisit again soon.

Regards,

Anthony Liguori


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

Re: [Qemu-devel] [PATCH] fix build regression in qxl-render.c caused by ac86048

[Anthony Liguori]

I'll commit in a few hours

Regards,

Anthony Liguori
On Dec 10, 2013 4:37 AM, Markus Armbruster arm...@redhat.com wrote:

 Igor Mammedov imamm...@redhat.com writes:

  fixes regression caused by commit
ac86048 trace: Remove trace.h from console.h (less dependencies)
  which makes build fail with:
 
  hw/display/qxl-render.c: In function ‘qxl_blit’:
  hw/display/qxl-render.c:34:5: error: implicit declaration of function
 ‘trace_qxl_render_blit’ [-Werror=implicit-function-declaration]
   trace_qxl_render_blit(qxl-guest_primary.qxl_stride,
 
  Signed-off-by: Igor Mammedov imamm...@redhat.com
  ---
   hw/display/qxl-render.c | 1 +
   1 file changed, 1 insertion(+)
 
  diff --git a/hw/display/qxl-render.c b/hw/display/qxl-render.c
  index d34b0c4..84f1367 100644
  --- a/hw/display/qxl-render.c
  +++ b/hw/display/qxl-render.c
  @@ -20,6 +20,7 @@
*/
 
   #include qxl.h
  +#include trace.h
 
   static void qxl_blit(PCIQXLDevice *qxl, QXLRect *rect)
   {

 Fix is pending already:
 https://lists.nongnu.org/archive/html/qemu-devel/2013-12/msg01314.html

Re: [Qemu-devel] [PULL 0/5] SCSI patches for 2013-12-09

[Anthony Liguori]

Paolo Bonzini pbonz...@redhat.com writes:

 Anthony,

 The following changes since commit ac9524dc55dc32e492ac3e6fbc9785be7168f8a2:

   qemu-iotests: filter QEMU monitor \r\n (2013-12-06 16:53:51 +0100)

 are available in the git repository at:

   git://github.com/bonzini/qemu.git scsi-next

What tree is this against?  It looks like the block tree.

It conflicts badly with current master.

Regards,

Anthony Liguori


 for you to fetch changes up to 2fe3798cd5fab65ee7c86758b1b7701d7fe3709f:

   help: add id suboption to -iscsi (2013-12-09 13:47:24 +0100)

 
 Paolo Bonzini (4):
   scsi-bus: fix transfer length and direction for VERIFY command
   scsi-disk: fix VERIFY emulation
   scsi-disk: fix WRITE SAME with large non-zero payload
   help: add id suboption to -iscsi

 Peter Lieven (1):
   block/iscsi: introduce bdrv_co_{readv, writev, flush_to_disk}

  block/iscsi.c   | 401 
 ++--
  configure   |   6 +-
  hw/scsi/scsi-bus.c  |  14 +-
  hw/scsi/scsi-disk.c |  29 ++--
  qemu-options.hx |   2 +-
  5 files changed, 143 insertions(+), 309 deletions(-)
 -- 
 1.8.4.2

Re: [Qemu-devel] [PULL 00/30] virtio conversion to realize and hotplug/unplug fixes

[Anthony Liguori]

Paolo Bonzini pbonz...@redhat.com writes:

 Anthony,

 the following changes since commit 7dc65c02fe3fb8f3146ce0b9ff5fec5945329f0e:

   Open 2.0 development tree (2013-11-27 14:02:45 -0800)

This also conflicts badly.

Regards,

Anthony Liguori


 are available in the git repository at:

   git://github.com/bonzini/qemu.git virtio

 for you to fetch changes up to 306ec6c3cece7004429c79c1ac93d49919f1f1cc:

   virtio: Convert exit to unrealize (2013-12-09 21:46:49 +0100)

 The patches were acked by Andreas.
 
 Andreas Färber (18):
   virtio-blk-dataplane: Improve error reporting
   virtio-9p: QOM realize preparations
   virtio-blk: QOM realize preparations
   virtio-serial: QOM realize preparations
   virtio-net: QOM realize preparations
   virtio-balloon: QOM realize preparations
   virtio-rng: QOM realize preparations
   virtio-scsi: QOM realize preparations
   virtio: Start converting VirtioDevice to QOM realize
   virtio-9p: Convert to QOM realize
   virtio-blk: Convert to QOM realize
   virtio-serial: Convert to QOM realize
   virtio-net: Convert to QOM realize
   virtio-balloon: Convert to QOM realize
   virtio-rng: Convert to QOM realize
   virtio-scsi: Convert to QOM realize
   virtio: Complete converting VirtioDevice to QOM realize
   virtio: Convert exit to unrealize

 Paolo Bonzini (12):
   virtio-ccw: move virtio_ccw_stop_ioeventfd to virtio_ccw_busdev_unplug
   virtio-bus: remove vdev field
   virtio-ccw: remove vdev field
   virtio-pci: remove vdev field
   virtio-bus: cleanup plug/unplug interface
   virtio-blk: switch exit callback to VirtioDeviceClass
   virtio-serial: switch exit callback to VirtioDeviceClass
   virtio-net: switch exit callback to VirtioDeviceClass
   virtio-scsi: switch exit callback to VirtioDeviceClass
   virtio-balloon: switch exit callback to VirtioDeviceClass
   virtio-rng: switch exit callback to VirtioDeviceClass
   virtio-pci: add device_unplugged callback

  hw/9pfs/virtio-9p-device.c  |  43 +++---
  hw/block/dataplane/virtio-blk.c |  30 +-
  hw/block/dataplane/virtio-blk.h |   5 +-
  hw/block/virtio-blk.c   |  47 ++--
  hw/char/virtio-serial-bus.c |  33 +--
  hw/net/virtio-net.c |  36 ++--
  hw/s390x/virtio-ccw.c   |  83 +++
  hw/s390x/virtio-ccw.h   |   1 -
  hw/scsi/vhost-scsi.c|  45 +++
  hw/scsi/virtio-scsi.c   |  57 +--
  hw/virtio/virtio-balloon.c  |  32 +--
  hw/virtio/virtio-bus.c  |  80 +++---
  hw/virtio/virtio-mmio.c |   9 +--
  hw/virtio/virtio-pci.c  | 122 
 
  hw/virtio/virtio-pci.h  |   1 -
  hw/virtio/virtio-rng.c  |  43 +++---
  hw/virtio/virtio.c  |  40 -
  include/hw/virtio/virtio-bus.h  |  22 +---
  include/hw/virtio/virtio-rng.h  |   2 +
  include/hw/virtio/virtio-scsi.h |   4 +-
  include/hw/virtio/virtio.h  |   8 ++-
  tests/qdev-monitor-test.c   |   4 +-
  22 files changed, 413 insertions(+), 334 deletions(-)
 -- 
 1.8.4.2

Re: [Qemu-devel] [PATCH] Fix QEMU build on OpenBSD on x86 archs

[Anthony Liguori]

Please repost a proper v2.

Regards,

Anthony Liguori

On Sun, Dec 8, 2013 at 7:28 PM, Brad Smith b...@comstyle.com wrote:
 On 27/11/13 6:15 PM, Brad Smith wrote:

 This resolves the build issue with building the ROMs on OpenBSD on x86
 archs.
 As of OpenBSD 5.3 the compiler builds PIE binaries by default and thus the
 whole OS/packages and so forth. The ROMs need to have PIE disabled. This
 is my initial attempt at trying to get somehting upstream so that QEMU
 both builds out of the box and to resolve the build issue with the
 buildbots that has been around for awhile. We have a patch in our ports
 tree but it is just the flags hardcoded into the Makefile which obviously
 is not appropriate for upstream.

  From the OpenBSD buildbots..
Building optionrom/multiboot.img
 ld: multiboot.o: relocation R_X86_64_16 can not be used when making a
 shared object; recompile with -fPIC


 Signed-off by: Brad Smith b...@comstyle.com


 ping.


 diff --git a/configure b/configure
 index 508f6a5..6d84885 100755
 --- a/configure
 +++ b/configure
 @@ -1342,6 +1342,10 @@ EOF
 if compile_prog -fPIE -DPIE -pie; then
   QEMU_CFLAGS=-fPIE -DPIE $QEMU_CFLAGS
   LDFLAGS=-pie $LDFLAGS
 +if test $targetos = OpenBSD; then
 +  CC_NOPIE=-fno-pie
 +  LD_NOPIE=-nopie
 +fi
   pie=yes
   if compile_prog  -Wl,-z,relro -Wl,-z,now ; then
 LDFLAGS=-Wl,-z,relro -Wl,-z,now $LDFLAGS
 @@ -4307,6 +4311,8 @@ if test $gcov = yes ; then
 echo CONFIG_GCOV=y  $config_host_mak
 echo GCOV=$gcov_tool  $config_host_mak
   fi
 +echo CC_NOPIE=$CC_NOPIE  $config_host_mak
 +echo LD_NOPIE=$LD_NOPIE  $config_host_mak

   # use included Linux headers
   if test $linux = yes ; then
 diff --git a/pc-bios/optionrom/Makefile b/pc-bios/optionrom/Makefile
 index 57d8bd0..0b35000 100644
 --- a/pc-bios/optionrom/Makefile
 +++ b/pc-bios/optionrom/Makefile
 @@ -12,6 +12,7 @@ $(call set-vpath, $(SRC_PATH)/pc-bios/optionrom)
   CFLAGS := -Wall -Wstrict-prototypes -Werror -fomit-frame-pointer
 -fno-builtin
   CFLAGS += -I$(SRC_PATH)
   CFLAGS += $(call cc-option, $(CFLAGS), -fno-stack-protector)
 +CFLAGS += $(CC_NOPIE)
   QEMU_CFLAGS = $(CFLAGS)

   build-all: multiboot.bin linuxboot.bin kvmvapic.bin
 @@ -20,7 +21,7 @@ build-all: multiboot.bin linuxboot.bin kvmvapic.bin
   .SECONDARY:

   %.img: %.o
 -   $(call quiet-command,$(LD) -Ttext 0 -e _start -s -o $@ $,
 Building $(TARGET_DIR)$@)
 +   $(call quiet-command,$(LD) $(LD_NOPIE) -Ttext 0 -e _start -s -o $@
 $,  Building $(TARGET_DIR)$@)

   %.raw: %.img
 $(call quiet-command,$(OBJCOPY) -O binary -j .text $ $@,
 Building $(TARGET_DIR)$@)



 --
 This message has been scanned for viruses and
 dangerous content by MailScanner, and is
 believed to be clean.

Re: [Qemu-devel] [PATCH for-1.7] Fix QEMU build on OpenBSD on x86 archs

[Anthony Liguori]

Brad Smith b...@comstyle.com writes:

 This resolves the build issue with building the ROMs on OpenBSD on x86 archs.
 As of OpenBSD 5.3 the compiler builds PIE binaries by default and thus the
 whole OS/packages and so forth. The ROMs need to have PIE disabled. This
 is my initial attempt at trying to get somehting upstream so that QEMU
 both builds out of the box and to resolve the build issue with the
 buildbots that has been around for awhile. We have a patch in our ports
 tree but it is just the flags hardcoded into the Makefile which obviously
 is not appropriate for upstream.

 From the OpenBSD buildbots..
   Building optionrom/multiboot.img
 ld: multiboot.o: relocation R_X86_64_16 can not be used when making a shared 
 object; recompile with -fPIC


 Signed-off by: Brad Smith b...@comstyle.com

 diff --git a/configure b/configure
 index 508f6a5..7f060a4 100755
 --- a/configure
 +++ b/configure
 @@ -1342,6 +1342,10 @@ EOF
if compile_prog -fPIE -DPIE -pie; then
  QEMU_CFLAGS=-fPIE -DPIE $QEMU_CFLAGS
  LDFLAGS=-pie $LDFLAGS
 +if test $targetos == OpenBSD; then

'==' is not portable syntax.  You need to use '='.

Regards,

Anthony Liguori

 +  CC_NOPIE=-fno-pie
 +  LD_NOPIE=-nopie
 +fi
  pie=yes
  if compile_prog  -Wl,-z,relro -Wl,-z,now ; then
LDFLAGS=-Wl,-z,relro -Wl,-z,now $LDFLAGS
 @@ -4307,6 +4311,8 @@ if test $gcov = yes ; then
echo CONFIG_GCOV=y  $config_host_mak
echo GCOV=$gcov_tool  $config_host_mak
  fi
 +echo CC_NOPIE=$CC_NOPIE  $config_host_mak
 +echo LD_NOPIE=$LD_NOPIE  $config_host_mak
  
  # use included Linux headers
  if test $linux = yes ; then
 diff --git a/pc-bios/optionrom/Makefile b/pc-bios/optionrom/Makefile
 index 57d8bd0..0b35000 100644
 --- a/pc-bios/optionrom/Makefile
 +++ b/pc-bios/optionrom/Makefile
 @@ -12,6 +12,7 @@ $(call set-vpath, $(SRC_PATH)/pc-bios/optionrom)
  CFLAGS := -Wall -Wstrict-prototypes -Werror -fomit-frame-pointer -fno-builtin
  CFLAGS += -I$(SRC_PATH)
  CFLAGS += $(call cc-option, $(CFLAGS), -fno-stack-protector)
 +CFLAGS += $(CC_NOPIE)
  QEMU_CFLAGS = $(CFLAGS)
  
  build-all: multiboot.bin linuxboot.bin kvmvapic.bin
 @@ -20,7 +21,7 @@ build-all: multiboot.bin linuxboot.bin kvmvapic.bin
  .SECONDARY:
  
  %.img: %.o
 - $(call quiet-command,$(LD) -Ttext 0 -e _start -s -o $@ $,  Building 
 $(TARGET_DIR)$@)
 + $(call quiet-command,$(LD) $(LD_NOPIE) -Ttext 0 -e _start -s -o $@ $, 
  Building $(TARGET_DIR)$@)
  
  %.raw: %.img
   $(call quiet-command,$(OBJCOPY) -O binary -j .text $ $@,  Building 
 $(TARGET_DIR)$@)

 -- 
 This message has been scanned for viruses and
 dangerous content by MailScanner, and is
 believed to be clean.

Re: [Qemu-devel] [PATCH for-1.7 0/2] block/drive-mirror: Reuse backing HD for sync=none

[Anthony Liguori]

Kevin Wolf kw...@redhat.com writes:

 Am 26.11.2013 um 19:02 hat Anthony Liguori geschrieben:
 Max Reitz mre...@redhat.com writes:
 
  This series fixes the drive-mirror blockjob in case of none sync mode
  to always use the old (current) image file as the backing file of the
  newly created mirrored file (in case of absolute-paths mode).
 
  It is rather important to get this into 1.7, as we will introduce an at
  least pretty strange API in case the original file is unbacked
  otherwise.
 
 Kevin/Stefan?  Do we need this for 1.7?

 Yes, it would be good to pick it up in order to avoid changing the API
 in 1.8 (I guess we would do it anyway because the current behaviour
 doesn't make any sense and we'd call it bug fix, but libvirt would have
 to deal with it and better to do it right in the first release.)

 Do you want to pick it up yourself or should I send a pull request?

I'll pick it up.

Regards,

Anthony Liguori


 Reviewed-by: Kevin Wolf kw...@redhat.com

 Kevin

[Qemu-devel] [ANNOUNCE] QEMU 1.7.0-rc2 is now available

[Anthony Liguori]

Hi,

On behalf of the QEMU Team, I'd like to announce the availability of the
third release candidate for the QEMU 1.7 release.  This release is meant
for testing purposes and should not be used in a production environment.

http://wiki.qemu.org/download/qemu-1.7.0-rc2.tar.bz2

You can help improve the quality of the QEMU 1.7 release by testing this
release and reporting bugs on Launchpad:

https://bugs.launchpad.net/qemu/

The release plan for the 1.7 release is available at:

http://wiki.qemu.org/Planning/1.7

Please add entries to the ChangeLog for the 1.7 release below:

http://wiki.qemu.org/ChangeLog/Next

The following changes have been made since v1.7.0-rc1:

 - curses: fixup SIGWINCH handler mess (Gerd Hoffmann)
 - qga: Fix two format strings for MinGW (Stefan Weil)
 - PPC: BookE: Make FIT/WDT timers at best millisecond grained (Alexander Graf)
 - PPC: Make BookE FIT/WDT timers more lazy (Alexander Graf)
 - acpi-build: fix support for glib  2.22 (Michael S. Tsirkin)
 - configure: make --iasl option actually work (Michael S. Tsirkin)
 - qemu-ga: vss-win32: Install VSS provider COM+ application service (Tomoki 
Sekiyama)
 - qdev-properties-system.c: Allow vlan or netdev for -device, not both (Vlad 
Yasevich)
 - qga: Fix compiler warnings (missing format attribute, wrong format strings) 
(Stefan Weil)
 - mips jazz: do not raise data bus exception when accessing invalid addresses 
(Hervé Poussineau)
 - target-i386: yield to another VCPU on PAUSE (Paolo Bonzini)
 - rng-egd: offset the point when repeatedly read from the buffer (Amos Kong)
 - rng-egd: remove redundant free (Amos Kong)
 - target-i386: Fix build by providing stub kvm_arch_get_supported_cpuid() 
(Peter Maydell)
 - vfio-pci: Fix multifunction=on (Alex Williamson)
 - atomic.h: Fix build with clang (Peter Maydell)
 - pc: get rid of builtin pvpanic for -M pc-1.5 (Paolo Bonzini)
 - configure: Explicitly set ARFLAGS so we can build with GNU Make 4.0 (Peter 
Maydell)
 - sun4m: Add FCode ROM for TCX framebuffer (Mark Cave-Ayland)
 - Revert e1000/rtl8139: update HMP NIC when every bit is written (Michael S. 
Tsirkin)
 - acpi-build: fix build on glib  2.14 (Michael S. Tsirkin)
 - acpi-build: fix build on glib  2.22 (Michael S. Tsirkin)
 - pci: unregister vmstate_pcibus on unplug (Bandan Das)
 - s390x: fix flat file load on 32 bit systems (Michael S. Tsirkin)

Regards,

Anthony Liguori

Re: [Qemu-devel] [PATCH for-1.7 0/2] block/drive-mirror: Reuse backing HD for sync=none

[Anthony Liguori]

Max Reitz mre...@redhat.com writes:

 This series fixes the drive-mirror blockjob in case of none sync mode
 to always use the old (current) image file as the backing file of the
 newly created mirrored file (in case of absolute-paths mode).

 It is rather important to get this into 1.7, as we will introduce an at
 least pretty strange API in case the original file is unbacked
 otherwise.

Kevin/Stefan?  Do we need this for 1.7?

Regards,

Anthony Liguori



 Max Reitz (2):
   block/drive-mirror: Reuse backing HD for sync=none
   qemu-iotests: Fix test 041

  blockdev.c |  3 +++
  tests/qemu-iotests/041 | 32 
  tests/qemu-iotests/041.out |  4 ++--
  3 files changed, 29 insertions(+), 10 deletions(-)

 -- 
 1.8.4.2

[Qemu-devel] [ANNOUNCE] QEMU 1.7.0-rc1 is now available

[Anthony Liguori]

)
 - MAINTAINERS: add git tree info for HMP, QMP and QAPI (Luiz Capitulino)
 - Adjust qapi-visit for python-2.4.3 (Richard Henderson)
 - Revert exec: limit system memory size (Michael S. Tsirkin)
 - Revert hw/pci: partially handle pci master abort (Marcel Apfelbaum)
 - loader: drop return value for rom_add_blob_fixed (Michael S. Tsirkin)
 - acpi-build: disable with -no-acpi (Michael S. Tsirkin)
 - virtio-net: only delete bh that existed (Jason Wang)
 - Fix pc migration from qemu = 1.5 (Cole Robinson)
 - virtio-net: broken RX filtering logic fixed (Dmitry Fleytman)
 - net: fix qemu_flush_queued_packets() in presence of a hub (Sergey Fedorov)
 - net: disallow to specify multicast MAC address (Dmitry Krivenok)
 - block: Round up total_sectors (Fam Zheng)
 - target-xtensa: add missing DEBUG section to dc233c config (Max Filippov)
 - exec: fix breakpoint_invalidate when pc may not be translated (Max Filippov)
 - pseries: Update SLOF firmware image (Alexey Kardashevskiy)
 - spapr: add vio-bus devices to categories (Alexey Kardashevskiy)
 - block: vhdx qemu-iotest - log replay of data sector (Jeff Cody)
 - block: qemu-iotests for vhdx, add write test support (Jeff Cody)
 - block: vhdx - update _make_test_img() to filter out vhdx options (Jeff Cody)
 - block: vhdx - add .bdrv_create() support (Jeff Cody)
 - block: vhdx - fix comment typos in header, fix incorrect struct fields (Jeff 
Cody)
 - block: vhdx - break out code operations to functions (Jeff Cody)
 - block: vhdx - move more endian translations to vhdx-endian.c (Jeff Cody)
 - block: vhdx - remove BAT file offset bit shifting (Jeff Cody)
 - block: vhdx write support (Jeff Cody)
 - block: vhdx - add log write support (Jeff Cody)
 - block: vhdx - add region overlap detection for image files (Jeff Cody)
 - block: vhdx - log parsing, replay, and flush support (Jeff Cody)
 - block: vhdx code movement - move vhdx_close() above vhdx_open() (Jeff Cody)
 - block: vhdx - update log guid in header, and first write tracker (Jeff Cody)
 - block: vhdx - break endian translation functions out (Jeff Cody)
 - block: vhdx - log support struct and defines (Jeff Cody)
 - block: vhdx code movement - VHDXMetadataEntries and BDRVVHDXState to header. 
(Jeff Cody)
 - block: vhdx - add header update capability. (Jeff Cody)
 - block: vhdx - minor comments and typo correction. (Jeff Cody)
 - block/vpc: fix virtual size for images created with disk2vhd (Peter Lieven)
 - block: Save errno before error_setg_errno (Max Reitz)
 - qdev-monitor-test: add device_add leak test cases (Stefan Hajnoczi)
 - blockdev-test: add test case for drive_add duplicate IDs (Stefan Hajnoczi)
 - libqtest: add qmp(fmt, ...) - QDict* function (Stefan Hajnoczi)
 - libqtest: rename qmp() to qmp_discard_response() (Stefan Hajnoczi)
 - blockdev: fix drive_init() opts and bs_opts leaks (Stefan Hajnoczi)
 - block: qemu-iotests, add quotes to $TEST_IMG usage in 061 (Jeff Cody)
 - block: qemu-iotests, add quotes to $TEST_IMG usage for 051 (Jeff Cody)
 - block: qemu-iotests, removes duplicate double quotes in 039 (Jeff Cody)
 - block: qemu-iotests, add quotes to $TEST_IMG usage in 019 (Jeff Cody)
 - block: qemu-iotests, add quotes to $TEST_IMG.base usage in 017 (Jeff Cody)
 - block: qemu-iotests, fix _make_test_img() to work with spaced pathnames 
(Jeff Cody)
 - block: qemu-iotests, add quotes to $TEST_IMG usage io pattern tests (Jeff 
Cody)
 - block/raw-posix: fix FreeBSD compilation (Andreas Tobler)
 - qemu-iotests: Filter out actual image size in 067 (Max Reitz)
 - qapi: Fix comment for create-type to match code. (Fam Zheng)
 - ossaudio: check for oss support in oss_audio_init (Gerd Hoffmann)
 - Revert ossaudio: do not enable by default (Gerd Hoffmann)
 - kvm: Fix uninitialized cpuid_data (Stefan Weil)
 - pci-assign: Remove dead code for direct I/O region access from userspace 
(Jan Kiszka)
 - linux-user: Fix stat64 syscall for SPARC64 (Stefan Weil)
 - configure: Add config.status to recreate the current configuration (Stefan 
Weil)
 - nsis: Improved support for parallel installation of 32 and 64 bit code 
(Stefan Weil)
 - KVM: x86: fix typo in KVM_GET_XCRS (Paolo Bonzini)

Regards,

Anthony Liguori

Re: [Qemu-devel] [ANNOUNCE] QEMU 1.7.0-rc1 is now available

[Anthony Liguori]

Sorry for the delays around this release.  I finally have proper
internet access at home.

I've updated the wiki and compressed the schedule for 1.7.0 should go
out on Wednesday.  I went through patches this morning and believe I
have everything committed that was targeted for 1.7 (minus Paolo's
pull request).

Please confirm and ping anything that isn't committed as appropriate.

Regards,

Anthony Liguori

On Thu, Nov 21, 2013 at 10:42 AM, Anthony Liguori anth...@codemonkey.ws wrote:
 Hi,

 On behalf of the QEMU Team, I'd like to announce the availability of the
 second release candidate for the QEMU 1.7 release.  This release is meant
 for testing purposes and should not be used in a production environment.

 http://wiki.qemu.org/download/qemu-1.7.0-rc1.tar.bz2

 You can help improve the quality of the QEMU 1.7 release by testing this
 release and reporting bugs on Launchpad:

 https://bugs.launchpad.net/qemu/

 The release plan for the 1.7 release is available at:

 http://wiki.qemu.org/Planning/1.7

 Please add entries to the ChangeLog for the 1.7 release below:

 http://wiki.qemu.org/ChangeLog/Next

 The following changes have been made since v1.7.0-rc0:

  - vfio-pci: Fix multifunction=on (Alex Williamson)
  - target-i386: Fix addr32 prefix in gen_lea_modrm (Richard Henderson)
  - atomic.h: Fix build with clang (Peter Maydell)
  - target-i386: do not override nr_cores for -cpu host (Paolo Bonzini)
  - mips jazz: do not raise data bus exception when accessing invalid 
 addresses (Hervé Poussineau)
  - target-i386: yield to another VCPU on PAUSE (Paolo Bonzini)
  - rng-egd: offset the point when repeatedly read from the buffer (Amos Kong)
  - rng-egd: remove redundant free (Amos Kong)
  - virtio-rng: add check of period (Amos Kong)
  - s390x: fix flat file load on 32 bit systems (Michael S. Tsirkin)
  - acpi-build: fix build on glib  2.14 (Michael S. Tsirkin)
  - acpi-build: fix build on glib  2.22 (Michael S. Tsirkin)
  - target-openrisc: Correct carry flag check of l.addc and l.addic test cases 
 (Sebastian Macke)
  - target-openrisc: Correct memory bounds checking for the tlb buffers 
 (Sebastian Macke)
  - openrisc-timer: Reduce overhead, Separate clock update functions 
 (Sebastian Macke)
  - target-openrisc: Correct wrong epcr register in interrupt handler 
 (Sebastian Macke)
  - target-openrisc: Remove executable flag for every page (Sebastian Macke)
  - target-openrisc: Remove unnecessary code generated by jump instructions 
 (Sebastian Macke)
  - target-openrisc: Speed up move instruction (Sebastian Macke)
  - The calculation of bytes_xfer in qemu_put_buffer() is wrong (Wangting 
 (Kathy))
  - migration: drop MADVISE_DONT_NEED for incoming zero pages (Peter Lieven)
  - qom: Fix memory leak in object_property_set_link() (Vlad Yasevich)
  - qtest: Use -display none by default (Andreas Färber)
  - virtio-net: fix the memory leak in rxfilter_notify() (Amos Kong)
  - doc: fix hardcoded helper path (Amos Kong)
  - tcg-ia64: Introduce tcg_opc_bswap64_i (Richard Henderson)
  - tcg-ia64: Introduce tcg_opc_ext_i (Richard Henderson)
  - tcg-ia64: Introduce tcg_opc_movi_a (Richard Henderson)
  - tcg-ia64: Introduce tcg_opc_mov_a (Richard Henderson)
  - tcg-ia64: Use A3 form of logical operations (Richard Henderson)
  - tcg-ia64: Use SUB_A3 and ADDS_A4 for subtraction (Richard Henderson)
  - tcg-ia64: Use ADDS for small addition (Richard Henderson)
  - tcg-ia64: Avoid unnecessary stop bit in tcg_out_alu (Richard Henderson)
  - tcg-ia64: Move AREG0 to R32 (Richard Henderson)
  - tcg-ia64: Simplify brcond (Richard Henderson)
  - tcg-ia64: Handle constant calls (Richard Henderson)
  - tcg-ia64: Use shortcuts for nop insns (Richard Henderson)
  - tcg-ia64: Use TCGMemOp within qemu_ldst routines (Richard Henderson)
  - hw/i386/Makefile.obj: use $(PYTHON) to run .py scripts consistently 
 (Michael Tokarev)
  - configure: Use -B switch only for Python versions which support it (Stefan 
 Weil)
  - qga: Fix shutdown command of guest agent to work with SysV (whitearchey)
  - block: Fail if requested driver is not available (Kevin Wolf)
  - MAINTAINERS: add block driver sub-maintainers (Stefan Hajnoczi)
  - qemu-img: Fix overwriting 'ret' before using (Fam Zheng)
  - qemu-iotests: Test qcow2 count_contiguous_clusters() (Kevin Wolf)
  - smc91c111: Fix receive starvation (Sebastian Huber)
  - qcow2: fix possible corruption when reading multiple clusters (Peter 
 Lieven)
  - qmp: access the local QemuOptsLists for drive option (Amos Kong)
  - MAINTAINERS: add block tree repo URLs (Stefan Hajnoczi)
  - qemu-iotests: Extend 041 for unbacked mirroring (Max Reitz)
  - block/drive-mirror: Check for NULL backing_hd (Max Reitz)
  - qapi-schema: Update description for NewImageMode (Max Reitz)
  - block: Print its file name if backing file opening failed (Fam Zheng)
  - pc: disable pci-info (Igor Mammedov)
  - console: Remove unused debug code (Stefan Weil)
  - qga: Fix compilation for old versions of MinGW (Stefan Weil

Re: [Qemu-devel] [PATCH 0/4] tpm: Provide a software vTPM

[Anthony Liguori]

On Wed, Nov 20, 2013 at 2:01 PM, Stefan Berger
stef...@linux.vnet.ibm.com wrote:
 On 11/19/2013 06:03 PM, Anthony Liguori wrote:

 On Tue, Nov 19, 2013 at 1:32 PM, Corey Bryant cor...@linux.vnet.ibm.com
 wrote:

 On 11/19/2013 02:50 PM, Anthony Liguori wrote:

 On Wed, Nov 6, 2013 at 6:38 AM, Corey Bryant cor...@linux.vnet.ibm.com
 wrote:

 This patch series provides support for a software Trusted Platform
 Module (otherwise known as a vTPM).  This support is provided via a
 new backend that works with the existing QEMU tpm-tis front end.


 We do device emulation within QEMU.  This is fundamentally what QEMU
 does.

 Why should we link against an external library instead of providing
 TPM emulation within QEMU itself?  What makes TPM so special here?


 Because 70k+ LOC *definitely* doesn't have a chance of getting into QEMU,
 so
 it makes more sense to link against a library.

 That's not because we're terrible people who institute horribly
 bureaucratic procedures for getting code merged.

 It's because we have a high standard of quality and work hard to do
 things in a minimal yet robust fashion.

 That is a large blob of untested and untrustworthy code.  That's
 nothing against the authors but that's simple a fact of life.


 That this code is 'untested' is simply not true.

As far as QEMU is concerned, it's untested.

 There are 7 different function calls used in the patches that call into
 libtpms.

 res = TPMLIB_GetTPMProperty(prop, result);
 res = TPMLIB_Process(out, resp_size, out_len, in, in_len);
 res = TPMLIB_Terminate();
 res =  TPMLIB_MainInit();
 TPMLIB_RegisterCallbacks(callbacks);
 TPM_Realloc(entry-buffer, length);
 TPM_Free((unsigned char *)*entry);


 The TPM library's most critical function call is TPMLIB_Process(). It takes
 a byte array containing a TPM command and processes it and returns a byte
 array with the command's response. Any kind of testing will concentrate on
 this function call since this function implements the TPM's core
 functionality.

None of this matters.

Let me put it in simple terms.  If anyone wants TPM (or any device)
emulation, the path forward is simple.  Break it up into small
reviewable chunks, submit on qemu-devel, address review feedback, and
repeat.

There are no back doors to merging large chunks of code.

 Any implementation of a software TPM will need this. I can
 now point you to the following:

 - the TSS test suite that exercises the TSS and with it it the TPM; the
 tests will ultimately run TPM commands, thus exercising this function call

 - a test suite that is part of a package at sourceforge and will also
 exercise this function call
 http://sourceforge.net/projects/ibmswtpm/files/?source=navbar

 - there is a test suite for TCG members that can be used for testing
 hardware TPMs and this software TPM; however, it's not open-source, but we
 could probably get some feedback about how well this software TPM passes
 this test suite

 So libtpms would be one of many (using ldd we counted more than 90)
 libraries that QEMU links against already today.

The vast majority are subdependencies of GTK or SDL most likely.  But
this is also irrelevant.  None of those libraries are directly guest
facing (spice being a notable exception).

Regards,

Anthony Liguori


 Regards,
 Stefan





 I know the answer to these questions of course.  There isn't a good
 reason but there exists vTPM as an external tool for historical
 reasons.  I don't think that's a good justification for doing this.
 libtpms has had no review by anyone and does not have a community
 around it.  Once we link against it, we are responsible for resolving


 The source is now more readily available on github and while the
 community
 is small, there is a community.  Besides, QEMU uses other libraries that
 have very small communities doesn't it?

 The repo has 4 commits with 1 contributor.  It's a code dump.  There
 is no community.

 We are extremely careful in the dependencies we carry.

 any security issue around it and fixing any bug within it.


 Is this really true?

 Yes.

   Is QEMU responsible for fixing every bug in glibc?

 If a guest can trigger an exploit from QEMU, then during the embargo
 period you can bet on the fact that QEMU developers would be working
 to resolve it along with the glibc developers.

 glibc isn't guest facing.  Neither is glib.  libtpms is making it a
 massive security exposure surface.

 TPMs aren't that complex of a device compared to other things on the
 platform.  There's no reason for it to be 70k of code other than it
 was someone's playground.

 If someone wrote a concise implementation of TPM within QEMU, I'd be
 more than eager to merge it.  libtpms is not that.

 Regards,

 Anthony Liguori

 --
 Regards,
 Corey Bryant


 That's essentially asking us to merge 70k+ LOCS without any review or
 validation ahead of time.  That's an unreasonable request.

 Regards,

 Anthony Liguori

 With this patch series, multiple guests can run

Re: [Qemu-devel] [PATCH 0/4] tpm: Provide a software vTPM

[Anthony Liguori]

On Wed, Nov 6, 2013 at 6:38 AM, Corey Bryant cor...@linux.vnet.ibm.com wrote:
 This patch series provides support for a software Trusted Platform
 Module (otherwise known as a vTPM).  This support is provided via a
 new backend that works with the existing QEMU tpm-tis front end.

We do device emulation within QEMU.  This is fundamentally what QEMU does.

Why should we link against an external library instead of providing
TPM emulation within QEMU itself?  What makes TPM so special here?

I know the answer to these questions of course.  There isn't a good
reason but there exists vTPM as an external tool for historical
reasons.  I don't think that's a good justification for doing this.
libtpms has had no review by anyone and does not have a community
around it.  Once we link against it, we are responsible for resolving
any security issue around it and fixing any bug within it.

That's essentially asking us to merge 70k+ LOCS without any review or
validation ahead of time.  That's an unreasonable request.

Regards,

Anthony Liguori

 With this patch series, multiple guests can run with their own vTPM.
 In comparison, the existing passthrough vTPM does not allow this
 because the host TPM cannot be shared.

 Note: There is seabios code that is not yet upstream that is
 required to run with this support.  It provides support such as
 initialization, ACPI table updates, and menu updates.  If anyone
 would like to run with that support, let me know and I can send you
 a bios.bin.

 Following is a sample command line:

 qemu-img create -f qcow2 /home/qemu/images/nvram.qcow2 500K

 qemu-system-x86_64 ... \
 -drive file=/home/qemu/images/nvram.qcow2,if=none,id=nvram0-0-0,format=qcow2 \
 -device tpm-tis,tpmdev=tpm-tpm0,id=tpm0 \
 -tpmdev libtpms,id=tpm-tpm0,nvram=nvram0-0-0

 Corey Bryant (4):
   tpm: Add TPM NVRAM implementation
   tpm: Share tpm_write_fatal_error_response
   tpm: QMP/HMP support for libtpms TPM backend
   tpm: Provide libtpms software TPM backend

  configure|   24 ++
  hmp.c|5 +
  hw/tpm/Makefile.objs |2 +
  hw/tpm/tpm_libtpms.c |  885 
 ++
  hw/tpm/tpm_nvram.c   |  340 
  hw/tpm/tpm_nvram.h   |   25 ++
  hw/tpm/tpm_passthrough.c |   14 -
  hw/tpm/tpm_tis.h |1 +
  include/sysemu/tpm_backend.h |3 +
  qapi-schema.json |   18 +-
  qemu-options.hx  |   31 ++-
  tpm.c|   28 ++-
  12 files changed, 1357 insertions(+), 19 deletions(-)
  create mode 100644 hw/tpm/tpm_libtpms.c
  create mode 100644 hw/tpm/tpm_nvram.c
  create mode 100644 hw/tpm/tpm_nvram.h

Re: [Qemu-devel] [PATCH 0/4] tpm: Provide a software vTPM

[Anthony Liguori]

On Tue, Nov 19, 2013 at 1:32 PM, Corey Bryant cor...@linux.vnet.ibm.com wrote:

 On 11/19/2013 02:50 PM, Anthony Liguori wrote:

 On Wed, Nov 6, 2013 at 6:38 AM, Corey Bryant cor...@linux.vnet.ibm.com
 wrote:

 This patch series provides support for a software Trusted Platform
 Module (otherwise known as a vTPM).  This support is provided via a
 new backend that works with the existing QEMU tpm-tis front end.


 We do device emulation within QEMU.  This is fundamentally what QEMU does.

 Why should we link against an external library instead of providing
 TPM emulation within QEMU itself?  What makes TPM so special here?


 Because 70k+ LOC *definitely* doesn't have a chance of getting into QEMU, so
 it makes more sense to link against a library.

That's not because we're terrible people who institute horribly
bureaucratic procedures for getting code merged.

It's because we have a high standard of quality and work hard to do
things in a minimal yet robust fashion.

That is a large blob of untested and untrustworthy code.  That's
nothing against the authors but that's simple a fact of life.

 I know the answer to these questions of course.  There isn't a good
 reason but there exists vTPM as an external tool for historical
 reasons.  I don't think that's a good justification for doing this.
 libtpms has had no review by anyone and does not have a community
 around it.  Once we link against it, we are responsible for resolving


 The source is now more readily available on github and while the community
 is small, there is a community.  Besides, QEMU uses other libraries that
 have very small communities doesn't it?

The repo has 4 commits with 1 contributor.  It's a code dump.  There
is no community.

We are extremely careful in the dependencies we carry.

 any security issue around it and fixing any bug within it.


 Is this really true?

Yes.

  Is QEMU responsible for fixing every bug in glibc?

If a guest can trigger an exploit from QEMU, then during the embargo
period you can bet on the fact that QEMU developers would be working
to resolve it along with the glibc developers.

glibc isn't guest facing.  Neither is glib.  libtpms is making it a
massive security exposure surface.

TPMs aren't that complex of a device compared to other things on the
platform.  There's no reason for it to be 70k of code other than it
was someone's playground.

If someone wrote a concise implementation of TPM within QEMU, I'd be
more than eager to merge it.  libtpms is not that.

Regards,

Anthony Liguori


 --
 Regards,
 Corey Bryant



 That's essentially asking us to merge 70k+ LOCS without any review or
 validation ahead of time.  That's an unreasonable request.

 Regards,

 Anthony Liguori

 With this patch series, multiple guests can run with their own vTPM.
 In comparison, the existing passthrough vTPM does not allow this
 because the host TPM cannot be shared.

 Note: There is seabios code that is not yet upstream that is
 required to run with this support.  It provides support such as
 initialization, ACPI table updates, and menu updates.  If anyone
 would like to run with that support, let me know and I can send you
 a bios.bin.

 Following is a sample command line:

 qemu-img create -f qcow2 /home/qemu/images/nvram.qcow2 500K

 qemu-system-x86_64 ... \
 -drive
 file=/home/qemu/images/nvram.qcow2,if=none,id=nvram0-0-0,format=qcow2 \
 -device tpm-tis,tpmdev=tpm-tpm0,id=tpm0 \
 -tpmdev libtpms,id=tpm-tpm0,nvram=nvram0-0-0

 Corey Bryant (4):
tpm: Add TPM NVRAM implementation
tpm: Share tpm_write_fatal_error_response
tpm: QMP/HMP support for libtpms TPM backend
tpm: Provide libtpms software TPM backend

   configure|   24 ++
   hmp.c|5 +
   hw/tpm/Makefile.objs |2 +
   hw/tpm/tpm_libtpms.c |  885
 ++
   hw/tpm/tpm_nvram.c   |  340 
   hw/tpm/tpm_nvram.h   |   25 ++
   hw/tpm/tpm_passthrough.c |   14 -
   hw/tpm/tpm_tis.h |1 +
   include/sysemu/tpm_backend.h |3 +
   qapi-schema.json |   18 +-
   qemu-options.hx  |   31 ++-
   tpm.c|   28 ++-
   12 files changed, 1357 insertions(+), 19 deletions(-)
   create mode 100644 hw/tpm/tpm_libtpms.c
   create mode 100644 hw/tpm/tpm_nvram.c
   create mode 100644 hw/tpm/tpm_nvram.h

Re: [Qemu-devel] dataplane, thread and gpu stuff

[Anthony Liguori]

On Nov 18, 2013 7:05 AM, Stefan Hajnoczi stefa...@gmail.com wrote:

 On Mon, Nov 18, 2013 at 02:52:53PM +1000, Dave Airlie wrote:
  So after talking to a few people at kvm forum I think the GPU code
  should probably use the dataplane stuff from the outset,
 
  The main advantages I think this gives me is being able to dequeue
  objects from the vq from a thread and send irq vectors from there as
  well.
 
  Though since it appears the dataplane stuff is kvm specific (at least
  the irq handling), I was wondering how I should deal with fallbacks
  for non-kvm operation, and quite how much falling back I need to do.
 
  Can I still use the dataplane/vring code from the normal bottom half
  handlers or do I have to write separate code for both situations.

 As of today, there are still two vring implementations in
 hw/virtio/virtio.c and hw/virtio/dataplane/vring.c.  This means it isn't
 clean and easy to integrate into a new device yet.  Existing dataplane
 devices basically take advantage of the fact that the non-dataplane
 version sets up the device before I/O.

I think we also need some form of mdroth's GContext prior to introducing
more dataplane devices.  Sticking every device in a seperate thread with no
way to control who is where can actually hurt performance.  I think we
really need to have a M-N device thread model too.

Regards,

Anthony Liguori


 Paolo can give you details on the latest thread-safe memory API stuff
 and whether it's already usable for virtio.

 Regarding irqfd, we could emulate it in TCG using an EventNotifier
 (eventfd).  At that point I think it's no longer kvm-specific.

 Stefan

Re: [Qemu-devel] [PATCH 2/3] ui/vnc: optimize dirty bitmap tracking

[Anthony Liguori]

On Nov 18, 2013 12:20 AM, Peter Lieven p...@kamp.de wrote:

 vnc_update_client currently scans the dirty bitmap of each client
 bitwise which is a very costly operation if only few bits are dirty.
 vnc_refresh_server_surface does almost the same.
 this patch optimizes both by utilizing the heavily optimized
 function find_next_bit to find the offset of the next dirty
 bit in the dirty bitmaps.

 Signed-off-by: Peter Lieven p...@kamp.de

Can you include performance data?

Regards,

Anthony Liguori

 ---
  ui/vnc.c |  146
++
  ui/vnc.h |3 ++
  2 files changed, 92 insertions(+), 57 deletions(-)

 diff --git a/ui/vnc.c b/ui/vnc.c
 index 67b1f75..edf33be 100644
 --- a/ui/vnc.c
 +++ b/ui/vnc.c
 @@ -572,6 +572,16 @@ void *vnc_server_fb_ptr(VncDisplay *vd, int x, int y)
  ptr += x * VNC_SERVER_FB_BYTES;
  return ptr;
  }
 +/* this sets only the visible pixels of a dirty bitmap */
 +#define VNC_SET_VISIBLE_PIXELS_DIRTY(bitmap, w, h) {\
 +int x, y;\
 +memset(bitmap, 0x00, sizeof(bitmap));\
 +for (y = 0; y  h; y++) {\
 +for (x = 0; x  w / VNC_DIRTY_PIXELS_PER_BIT; x++) {\
 +set_bit(x, bitmap[y]);\
 +} \
 +} \
 +}

  static void vnc_dpy_switch(DisplayChangeListener *dcl,
 DisplaySurface *surface)
 @@ -597,7 +607,9 @@ static void vnc_dpy_switch(DisplayChangeListener *dcl,
  qemu_pixman_image_unref(vd-guest.fb);
  vd-guest.fb = pixman_image_ref(surface-image);
  vd-guest.format = surface-format;
 -memset(vd-guest.dirty, 0xFF, sizeof(vd-guest.dirty));
 +VNC_SET_VISIBLE_PIXELS_DIRTY(vd-guest.dirty,
 + surface_width(vd-ds),
 + surface_height(vd-ds));

  QTAILQ_FOREACH(vs, vd-clients, next) {
  vnc_colordepth(vs);
 @@ -605,7 +617,9 @@ static void vnc_dpy_switch(DisplayChangeListener *dcl,
  if (vs-vd-cursor) {
  vnc_cursor_define(vs);
  }
 -memset(vs-dirty, 0xFF, sizeof(vs-dirty));
 +VNC_SET_VISIBLE_PIXELS_DIRTY(vs-dirty,
 + surface_width(vd-ds),
 + surface_height(vd-ds));
  }
  }

 @@ -882,6 +896,14 @@ static int vnc_update_client_sync(VncState *vs, int
has_dirty)
  return ret;
  }

 +#define VNC_CLIENT_UPDATE_RECT() \
 +if (last_x != -1) {\
 +int h = find_and_clear_dirty_height(vs, y, last_x, x, height);\
 +n += vnc_job_add_rect(job,\
 +  last_x * VNC_DIRTY_PIXELS_PER_BIT, y,\
 +  (x - last_x) * VNC_DIRTY_PIXELS_PER_BIT, h);\
 +}
 +
  static int vnc_update_client(VncState *vs, int has_dirty)
  {
  if (vs-need_update  vs-csock != -1) {
 @@ -910,35 +932,32 @@ static int vnc_update_client(VncState *vs, int
has_dirty)
  width = MIN(pixman_image_get_width(vd-server),
vs-client_width);
  height = MIN(pixman_image_get_height(vd-server),
vs-client_height);

 -for (y = 0; y  height; y++) {
 +y = 0;
 +for (;;) {
  int x;
  int last_x = -1;
 -for (x = 0; x  width / VNC_DIRTY_PIXELS_PER_BIT; x++) {
 +unsigned long offset = find_next_bit((unsigned long *)
vs-dirty,
 + height *
VNC_DIRTY_BITS_PER_LINE(vs),
 + y *
VNC_DIRTY_BITS_PER_LINE(vs));
 +if (offset == height * VNC_DIRTY_BITS_PER_LINE(vs)) {
 +/* no more dirty bits */
 +break;
 +}
 +y = offset / VNC_DIRTY_BITS_PER_LINE(vs);
 +
 +for (x = offset % VNC_DIRTY_BITS_PER_LINE(vs);
 + x  width / VNC_DIRTY_PIXELS_PER_BIT; x++) {
  if (test_and_clear_bit(x, vs-dirty[y])) {
  if (last_x == -1) {
  last_x = x;
  }
  } else {
 -if (last_x != -1) {
 -int h = find_and_clear_dirty_height(vs, y,
last_x, x,
 -height);
 -
 -n += vnc_job_add_rect(job,
 -  last_x *
VNC_DIRTY_PIXELS_PER_BIT,
 -  y,
 -  (x - last_x) *
VNC_DIRTY_PIXELS_PER_BIT,
 -  h);
 -}
 +VNC_CLIENT_UPDATE_RECT();
  last_x = -1;
  }
  }
 -if (last_x != -1) {
 -int h = find_and_clear_dirty_height(vs, y, last_x, x,
height);
 -n += vnc_job_add_rect(job, last_x *
VNC_DIRTY_PIXELS_PER_BIT,
 -  y,
 -  (x - last_x

Re: [Qemu-devel] -vga std vs. -device VGA

[Anthony Liguori]

On Thu, Nov 14, 2013 at 2:41 PM, Alexander Graf ag...@suse.de wrote:


 Am 14.11.2013 um 17:32 schrieb Benjamin Herrenschmidt 
 b...@kernel.crashing.org:

 On Thu, 2013-11-14 at 17:23 -0500, Alexander Graf wrote:
 Yes. But I think it's the correct thing to do in this case. X86 also
 doesn't create a USB controller like we would have to. Our pseries
 platform just doesn't have a legacy PC/AT keyboard controller.

 Sure, but that implies that -nodefaults -device VGA creates a working
 usable machine on x86 and not on pseries...

 There is a set of devices that is always part of your machine. For the PC, 
 this is the PCI complex and SuperIO (including the keyboard controller).

 For pseries, we don't have that chip. We could simulate similar behavior 
 through a usb controller and keyboard. But those are devices that not every 
 pseries VM will want to have.

 So it really is libvirt's or the xml's job to add these.

 Even on x86 there are Atom chips out now that run without SuperIO, so we 
 might eventually have an x86 machine type without keyboard too, who knows.

As long as it's x86, there will always be a keyboard controller if you
ever want to support more than 1MB of RAM properly since the keyboard
controller is used to enable the a20 bit.

Regards,

Anthony Liguori


 Alex

Re: [Qemu-devel] -vga std vs. -device VGA

[Anthony Liguori]

On Thu, Nov 14, 2013 at 2:32 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
 On Thu, 2013-11-14 at 17:23 -0500, Alexander Graf wrote:
 Yes. But I think it's the correct thing to do in this case. X86 also
 doesn't create a USB controller like we would have to. Our pseries
 platform just doesn't have a legacy PC/AT keyboard controller.

 Sure, but that implies that -nodefaults -device VGA creates a working
 usable machine on x86 and not on pseries...

Because pseries is not x86.  This is expected and okay.

Regards,

Anthony Liguori

 Cheers,
 Ben.

Re: [Qemu-devel] [PATCH for-1.7] target-i386: Fix build by providing stub kvm_arch_get_supported_cpuid()

[Anthony Liguori]

On Tue, Nov 12, 2013 at 8:08 AM, Peter Maydell peter.mayd...@linaro.org wrote:
 On 12 November 2013 15:58, Paolo Bonzini pbonz...@redhat.com wrote:
 I don't really see a reason why QEMU should give clang more weight than
 Windows or Mac OS X.

 I'm not asking for more weight (and actually my main
 reason for caring about clang is exactly MacOSX). I'm
 just asking that when a bug is reported whose underlying
 cause is we don't work on clang because we're relying on
 undocumented behaviour of gcc with an attached patch that
 fixes this by not relying on the undocumented behaviour,
 that we apply the patch rather than saying why do we
 care about clang...

QEMU has always been intimately tied to GCC.  Heck, it all started as
a giant GCC hack relying on entirely undocumented behavior (dyngen's
disassembly of functions).

There's nothing intrinsically bad about being tied to GCC.  If you
were making argument that we could do it a different way and the
result would be as nice or nicer, then it wouldn't be a discussion.

But if supporting clang means we have to remove useful things, then
it's always going to be an uphill battle.

In this case, the whole discussion is a bit silly.  Have you actually
tried -O1 under a debugger with clang?  Is it noticably worse than
-O0?

I find QEMU extremely difficult to use an interactive debugger on
anyway.  I doubt the difference between -O0 and -O1 is even close to
the breaking point between usability under a debugger...

Regards,

Anthony Liguori

 This seems to me to be a win-win situation:
  * we improve our code by not relying on undocumented
implentation specifics
  * we work on a platform that, while not a primary
platform, is at least supported in the codebase and
has people who fix it when it breaks

 -- PMM

Re: [Qemu-devel] [PATCH] ui/sdl2 : initial port to SDL 2.0

[Anthony Liguori]

On Nov 11, 2013 1:10 AM, Dave Airlie airl...@gmail.com wrote:

 On Mon, Nov 11, 2013 at 2:02 PM, Anthony Liguori anth...@codemonkey.ws
wrote:
  On Sun, Nov 10, 2013 at 3:15 PM, Dave Airlie airl...@gmail.com wrote:
  From: Dave Airlie airl...@redhat.com
 
  I've ported the SDL1.2 code over, and rewritten it to use the SDL2
interface.
 
  The biggest changes were in the input handling, where SDL2 has done a
major
  overhaul, and I've had to include a generated translation file to get
from
  SDL2 codes back to qemu compatible ones. I'm still not sure how the
keyboard
  layout code works in qemu, so there may be further work if someone can
point
  me a test case that works with SDL1.2 and doesn't with SDL2.
 
  Some SDL env vars we used to set are no longer used by SDL2,
  Windows, OSX support is untested,
 
  I don't think we can link to SDL1.2 and SDL2 at the same time, so I
felt
  using --with-sdlabi=2.0 to select the new code should be fine, like how
  gtk does it.
 
  Signed-off-by: Dave Airlie airl...@redhat.com
  ---
   configure|  23 +-
   ui/Makefile.objs |   4 +-
   ui/sdl.c |   3 +
   ui/sdl2.c| 889
+++
 
  Can we refactor this to not duplicate everything and instead have
  function hooks or even #ifdefs for the things that are different?  We
  try to guess the right SDL to use in configure.  See how we handle
  GTK2 vs. GTK3.
 
  It's very hard to review ATM due to the split.

 No I talked to enough people at kvmforum and everyone said I should
 split this into a separate file, please don't make me undo that now, I
 originally did it with ifdefs and just spent a few days redoing it the
 other way!

Perhaps whoever you spoke with should speal up then.  Forking sdl.c seems
like a pretty bad idea to me.


 
  Regarding the keycodes, danpb has a great write up on his blog:
 
 
https://www.berrange.com/posts/2010/07/04/a-summary-of-scan-code-key-codes-sets-used-in-the-pc-virtualization-stack/

 Okay I'll read that later,

 
  Internally, we use a variant of raw XT scancodes.  We have a
  keymapping routine that translates from a symbolic key (i.e. capital
  A) to the appropriate XT scancode.
 
  SDL 1.x at least lets you get at raw X11 scancodes which are either
  evdev or PS/2 codes depending on the version of X11.  So for SDL 1.x
  we have two translations mechanisms 1) X11 scancodes to XT scancodes
  and 2) SDL keysyms to internal QEMU keysyms.
 
  From what I can tell, SDL2 has moved from just passing through raw X11
  scancodes (which like I said, can be different depending on your X
  configuration) to having an intermediate translation layer.  See
  comments inline:
 
   ui/sdl2_scancode_translate.h | 260 +
   ui/sdl_keysym.h  |   3 +-
   6 files changed, 1175 insertions(+), 7 deletions(-)
   create mode 100644 ui/sdl2.c
   create mode 100644 ui/sdl2_scancode_translate.h
 
  diff --git a/configure b/configure
  index 9addff1..bf3be37 100755
  --- a/configure
  +++ b/configure
  @@ -158,6 +158,7 @@ docs=
   fdt=
   pixman=
   sdl=
  +sdlabi=1.2
   virtfs=
   vnc=yes
   sparse=no
  @@ -310,6 +311,7 @@ query_pkg_config() {
   }
   pkg_config=query_pkg_config
   sdl_config=${SDL_CONFIG-${cross_prefix}sdl-config}
  +sdl2_config=${SDL2_CONFIG-${cross_prefix}sdl2-config}
 
   # default flags for all hosts
   QEMU_CFLAGS=-fno-strict-aliasing $QEMU_CFLAGS
  @@ -710,6 +712,8 @@ for opt do
 ;;
 --enable-sdl) sdl=yes
 ;;
  +  --with-sdlabi=*) sdlabi=$optarg
  +  ;;
 --disable-qom-cast-debug) qom_cast_debug=no
 ;;
 --enable-qom-cast-debug) qom_cast_debug=yes
  @@ -1092,6 +1096,7 @@ echo   --disable-strip  disable
stripping binaries
   echo   --disable-werror disable compilation abort on warning
   echo   --disable-sdldisable SDL
   echo   --enable-sdl enable SDL
  +echo   --with-sdlabiselect preferred SDL ABI 1.2 or 2.0
   echo   --disable-gtkdisable gtk UI
   echo   --enable-gtk enable gtk UI
   echo   --disable-virtfs disable VirtFS
  @@ -1751,12 +1756,22 @@ fi
 
   # Look for sdl configuration program (pkg-config or sdl-config).  Try
   # sdl-config even without cross prefix, and favour pkg-config over
sdl-config.
  -if test `basename $sdl_config` != sdl-config  ! has
${sdl_config}; then
  -  sdl_config=sdl-config
  +
  +if test $sdlabi == 2.0; then
  +sdl_config=$sdl2_config
  +sdlname=sdl2
  +sdlconfigname=sdl2_config
  +else
  +sdlname=sdl
  +sdlconfigname=sdl_config
  +fi
  +
  +if test `basename $sdl_config` != $sdlconfigname  ! has
${sdl_config}; then
  +  sdl_config=$sdlconfigname
   fi
 
  -if $pkg_config sdl --exists; then
  -  sdlconfig=$pkg_config sdl
  +if $pkg_config $sdlname --exists; then
  +  sdlconfig=$pkg_config $sdlname
 _sdlversion=`$sdlconfig --modversion 2/dev/null | sed
's/[^0-9]//g'`
   elif has ${sdl_config

Re: [Qemu-devel] audit needed for signal handlers

[Anthony Liguori]

On Mon, Nov 11, 2013 at 8:50 AM, Eric Blake ebl...@redhat.com wrote:
 Quick - identify the bug in this code (from ui/curses.c):

 static void curses_winch_handler(int signum)
 {
 struct winsize {
 unsigned short ws_row;
 unsigned short ws_col;
 unsigned short ws_xpixel;   /* unused */
 unsigned short ws_ypixel;   /* unused */
 } ws;

 /* terminal size changed */
 if (ioctl(1, TIOCGWINSZ, ws) == -1)
 return;

 resize_term(ws.ws_row, ws.ws_col);
 curses_calc_pad();
 invalidate = 1;

 /* some systems require this */
 signal(SIGWINCH, curses_winch_handler);
 }

 Here's a hint: ioctl() can clobber errno.  But if a signal handler is
 called in the middle of other code that is using errno, then the handler
 MUST restore the value of errno before returning, if it is to guarantee
 that the interrupted context won't be corrupted.

Isn't this precisely why EINTR exists?

Regards,

Anthony Liguori


 More reading on the topic:
 https://plus.google.com/+LennartPoetteringTheOneAndOnly/posts/gHSscCJkakd

 I have not done a full audit of qemu's signal handlers, so much as a
 quick look to see if I could find violations; it was surprisingly easy
 to find a bad example.  A signal handler that resets the signal to
 SIG_DFL then calls raise() is exempt from caring about errno, but any
 signal handler that can fall through to the end and return execution to
 the caller MUST ensure that errno is left unchanged, for errno to be
 useful in the remaining body of code.  Which is why the best signal
 handlers tend to be the one that only flag a volatile variable that is
 later checked at safe points of execution, rather than trying to make
 complex calls from within the handler context.

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

Re: [Qemu-devel] [PATCH] A hexdump function that also displays UTF-8 strings contained in the dumped buffer.

[Anthony Liguori]

On Mon, Nov 11, 2013 at 10:29 AM, Mike Day ncm...@ncultra.org wrote:
 This function is used by a forthcomingQemu monitor command that dumps
 contents of OpenFirmware Device Trees. It dumps contents of a buffer
 as hex in the same format as the existing function but also also
 appends any UTF-8 strings in human-readable format.

 Like the existing hexdump function, this function may be used
 elsewhere in Qemu, and it shares the same prototype as the existing
 function.

 In both functions, check for a NULL prefix parameter and omit printing
 the prefix if it is null.

 Here is a sample of the output of both functions with no prefix string:

 :  61 62 33 64  62 65 65 66  65 62 34 64  66 62 65 03
 0010:  67 62 35 64  68 01 05 03  69 62 36 64  6a 01 06 03
 0020:  6b 62 37 64  6c 01 07 03  6d 62 38 64  6e 01 08 03
 0030:  6f 62 39 64  70 01 09 03  71 62 78 64

 :  61 62 33 64  62 65 65 66  65 62 34 64  66 62 65 03   ab3dbeefeb4dfbe.
 0010:  67 62 35 64  68 01 05 03  69 62 36 64  6a 01 06 03   gb5dh...ib6dj...
 0020:  6b 62 37 64  6c 01 07 03  6d 62 38 64  6e 01 08 03   kb7dl...mb8dn...
 0030:  6f 62 39 64  70 01 09 03  71 62 78 64ob9dp...qbxd

 Signed-off-by: Mike Day ncm...@ncultra.org
 ---
  include/qemu-common.h |  2 ++
  util/hexdump.c| 48 +++-
  2 files changed, 49 insertions(+), 1 deletion(-)

 diff --git a/include/qemu-common.h b/include/qemu-common.h
 index 5054836..7b8e2b9 100644
 --- a/include/qemu-common.h
 +++ b/include/qemu-common.h
 @@ -435,6 +435,8 @@ int mod_utf8_codepoint(const char *s, size_t n, char 
 **end);
   */

  void qemu_hexdump(const char *buf, FILE *fp, const char *prefix, size_t 
 size);
 +/* include any strings alongside the hex output */
 +void qemu_hexdump_str(gchar *buf, FILE *fp, const gchar *prefix, size_t len);

  /* vector definitions */
  #ifdef __ALTIVEC__
 diff --git a/util/hexdump.c b/util/hexdump.c
 index 969b340..a920c81 100644
 --- a/util/hexdump.c
 +++ b/util/hexdump.c
 @@ -21,7 +21,11 @@ void qemu_hexdump(const char *buf, FILE *fp, const char 
 *prefix, size_t size)

  for (b = 0; b  size; b++) {
  if ((b % 16) == 0) {
 -fprintf(fp, %s: %04x:, prefix, b);
 +if (prefix) {
 +fprintf(fp, %s: %04x:, prefix, b);
 +} else {
 +fprintf(fp, %04x:, b);
 +}
  }
  if ((b % 4) == 0) {
  fprintf(fp,  );
 @@ -35,3 +39,45 @@ void qemu_hexdump(const char *buf, FILE *fp, const char 
 *prefix, size_t size)
  fprintf(fp, \n);
  }
  }
 +
 +/* print any strings along side the hex dump */
 +void qemu_hexdump_str(gchar *buf, FILE *fp, const gchar *prefix, size_t len)
 +{
 +
 +gchar *inp, *linep;
 +int i, offset = 0;
 +inp = linep = buf;
 +
 +do {
 +if (prefix) {
 +fprintf(fp, %s: %04x:  , prefix, offset);
 +} else {
 +fprintf(fp, %04x:  , offset);
 +}
 +for (i = 0; i  16  len  0; i++, len--, offset++, inp++) {
 +if (i  !(i % 4)) {
 +fprintf(fp,  );
 +}
 +fprintf(fp, %02hx , *inp);
 +}
 +int j;
 +if (i  16) {
 +for (j = 16 - i; j; --j) {
 +fprintf(fp,);
 +if (j  (!(j % 4))) {
 +fprintf(fp,  );
 +}
 +}
 +}
 +fprintf(fp,   );
 +for (j = 0; j  i; j++) {
 +if (*(linep + j)  0x20 || *(linep + j)  0x7e) {

You can use qemu_isprint() for this.

 +fprintf(fp, %c, '.');
 +} else {
 +fprintf(fp, %c, *(linep + j));

Even though the comment says UTF-8, this isn't actually handling
UTF-8. Just ascii.

You should fold this into whatever forthcoming patch you are submitting.

Regards,

Anthony Liguori

 +}
 +}
 +fprintf(fp, \n);
 +linep = inp;
 +} while (len);
 +}

Re: [Qemu-devel] [PATCH for-1.7] target-i386: Fix build by providing stub kvm_arch_get_supported_cpuid()

[Anthony Liguori]

On Mon, Nov 11, 2013 at 3:11 PM, Paolo Bonzini pbonz...@redhat.com wrote:
 Il 11/11/2013 23:38, Peter Maydell ha scritto:
 If we have other places where we're relying on dead code elimination
 to not provide a function definition, please point them out, because
 they're bugs we need to fix, ideally before they cause compilation
 failures.

 I'm not sure, there are probably a few others.  Linux also relies on the
 idiom (at least KVM does on x86).

And they are there because it's a useful tool.

 Huh? The point of stub functions is to provide versions of functions
 which either need to return an always fails code, or which will never
 be called, but in either case this is so we can avoid peppering the
 code with #ifdefs. The latter category is why we have stubs which
 do nothing but call abort().

 There are very few stubs that call abort():

 int kvm_cpu_exec(CPUState *cpu)
 {
 abort();
 }

 int kvm_set_signal_mask(CPUState *cpu, const sigset_t *sigset)
 {
 abort();
 }

 Calling abort() would be marginally better than returning 0, but why
 defer checks to runtime when you can let the linker do them?

Exactly.

 I wouldn't be surprised if this also affected debug gcc
 builds with KVM disabled, but I haven't checked.

 No, it doesn't affect GCC.  See Andreas's bug report.  Is it a bug or a
 feature?  Having some kind of -O0 dead-code elimination is definitely a
 feature (http://gcc.gnu.org/ml/gcc-patches/2003-03/msg02443.html).

 That patch says it is to speed up these RTL optimizers and by allocating
 less memory, reduce the compiler footprint and possible memory
 fragmentation. So they might investigate it as a performance
 regression, but it's only a make compilation faster feature, not
 correctness. Code which relies on dead-code-elimination is broken.

 There's plenty of tests in the GCC testsuite that rely on DCE to test
 that an optimization happened; some of them at -O0 too.  So it's become
 a GCC feature in the end.

 Code which relies on dead-code-elimination is not broken, it's relying
 on the full power of the toolchain to ensure bugs are detected as soon
 as possible, i.e. at build time.

 I am okay with Andreas's patch of course, but it would also be fine with
 me to split the if in two, each with its own separate break statement.

 I think Andreas's patch is a bad idea and am against it being
 applied. It's very obviously a random tweak aimed at a specific
 compiler's implementation of dead-code elimination, and it's the
 wrong way to fix the problem.

 It's very obviously a random tweak aimed at a specific compiler's bug in
 dead-code elimination, I'm not denying that.  But the same compiler
 feature is being exploited elsewhere.

We're not talking about something obscure here.  It's eliminating an
if(0) block.  There's no reason to leave an if (0) block around.  The
code is never reachable.

 Since it only affects debug builds, there is no hurry to fix this in 1.7
 if the approach cannot be agreed with.

 ??  Debug builds should absolutely work out of the box -- if
 debug build fails that is IMHO a release critical bug.

 Debug builds for qemu-system-{i386,x86_64} with clang on systems other
 than x86/Linux.

Honestly, it's hard to treat clang as a first class target.  We don't
have much infrastructure around so it's not getting that much testing.

We really need to figure out how we're going to do CI.

FWIW, I'd rather just add -O1 for debug builds than add more stub functions.

Regards,

Anthony Liguori


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

Re: [Qemu-devel] [PATCH] ui/sdl2 : initial port to SDL 2.0

[Anthony Liguori]

 = SDL_PIXELFORMAT_RGB565;
 +else if (surface_bits_per_pixel(surface) == 32)
 +format = SDL_PIXELFORMAT_ARGB;
 +
 +if (!format)
 +exit(1);
 +guest_texture = SDL_CreateTexture(real_renderer, format,
 +  SDL_TEXTUREACCESS_STREAMING,
 +  surface_width(surface), 
 surface_height(surface));
 +SDL_RenderSetLogicalSize(real_renderer, surface_width(surface), 
 surface_height(surface));
 +}
 +
 +/* generic keyboard conversion */
 +
 +#include sdl_keysym.h
 +
 +static kbd_layout_t *kbd_layout = NULL;
 +
 +static uint8_t sdl_keyevent_to_keycode_generic(const SDL_KeyboardEvent *ev)
 +{
 +int keysym;
 +/* workaround for X11+SDL bug with AltGR */
 +keysym = ev-keysym.sym;
 +if (keysym == 0  ev-keysym.scancode == 113)
 +keysym = SDLK_MODE;
 +/* For Japanese key '\' and '|' */
 +if (keysym == 92  ev-keysym.scancode == 133) {
 +keysym = 0xa5;
 +}
 +return keysym2scancode(kbd_layout, keysym)  SCANCODE_KEYMASK;
 +}
 +
 +/* specific keyboard conversions from scan codes */
 +
 +#if defined(_WIN32)
 +
 +static uint8_t sdl_keyevent_to_keycode(const SDL_KeyboardEvent *ev)
 +{
 +int keycode;
 +
 +keycode = ev-keysym.scancode;
 +keycode = sdl2_scancode_to_keycode[keycode];
 +return keycode;
 +}
 +
 +#else
 +
 +static uint8_t sdl_keyevent_to_keycode(const SDL_KeyboardEvent *ev)
 +{
 +int keycode;
 +
 +keycode = ev-keysym.scancode;
 +
 +keycode = sdl2_scancode_to_keycode[keycode];
 +if (keycode = 89  keycode  150) {
 +keycode = translate_evdev_keycode(keycode - 89);
 +}

This doesn't seem right to me.  It just so happened that the low value
scan codes are the same for both X11, evdev, and SDL 1.x.  That's why
we only used the evdev/x11 translation tables for higher codes.  It
was just a table size optimization.

Presumably, sdl2 doesn't do this though, or does it?  If it does,
don't we need to probe for evdev instead of assuming it's there?

Regards,

Anthony Liguori

 +return keycode;
 +}
 +
 +#endif
 +
 +static void reset_keys(void)
 +{
 +int i;
 +for(i = 0; i  256; i++) {
 +if (modifiers_state[i]) {
 +if (i  SCANCODE_GREY)
 +kbd_put_keycode(SCANCODE_EMUL0);
 +kbd_put_keycode(i | SCANCODE_UP);
 +modifiers_state[i] = 0;
 +}
 +}
 +}
 +
 +static void sdl_process_key(SDL_KeyboardEvent *ev)
 +{
 +int keycode, v;
 +
 +if (ev-keysym.sym == SDLK_PAUSE) {
 +/* specific case */
 +v = 0;
 +if (ev-type == SDL_KEYUP)
 +v |= SCANCODE_UP;
 +kbd_put_keycode(0xe1);
 +kbd_put_keycode(0x1d | v);
 +kbd_put_keycode(0x45 | v);
 +return;
 +}
 +
 +if (kbd_layout) {
 +keycode = sdl_keyevent_to_keycode_generic(ev);
 +} else {
 +keycode = sdl_keyevent_to_keycode(ev);
 +}
 +
 +switch(keycode) {
 +case 0x00:
 +/* sent when leaving window: reset the modifiers state */
 +reset_keys();
 +return;
 +case 0x2a:  /* Left Shift */
 +case 0x36:  /* Right Shift */
 +case 0x1d:  /* Left CTRL */
 +case 0x9d:  /* Right CTRL */
 +case 0x38:  /* Left ALT */
 +case 0xb8: /* Right ALT */
 +if (ev-type == SDL_KEYUP)
 +modifiers_state[keycode] = 0;
 +else
 +modifiers_state[keycode] = 1;
 +break;
 +#define QEMU_SDL_VERSION ((SDL_MAJOR_VERSION  8) + SDL_MINOR_VERSION)
 +#if QEMU_SDL_VERSION  0x102 || QEMU_SDL_VERSION == 0x102  SDL_PATCHLEVEL 
  14
 +/* SDL versions before 1.2.14 don't support key up for caps/num 
 lock. */
 +case 0x45: /* num lock */
 +case 0x3a: /* caps lock */
 +/* SDL does not send the key up event, so we generate it */
 +kbd_put_keycode(keycode);
 +kbd_put_keycode(keycode | SCANCODE_UP);
 +return;
 +#endif
 +}
 +
 +/* now send the key code */
 +if (keycode  SCANCODE_GREY)
 +kbd_put_keycode(SCANCODE_EMUL0);
 +if (ev-type == SDL_KEYUP)
 +kbd_put_keycode(keycode | SCANCODE_UP);
 +else
 +kbd_put_keycode(keycode  SCANCODE_KEYCODEMASK);
 +}
 +
 +static void sdl_update_caption(void)
 +{
 +char win_title[1024];
 +char icon_title[1024];
 +const char *status = ;
 +
 +if (!runstate_is_running())
 +status =  [Stopped];
 +else if (gui_grab) {
 +if (alt_grab)
 +status =  - Press Ctrl-Alt-Shift to exit mouse grab;
 +else if (ctrl_grab)
 +status =  - Press Right-Ctrl to exit mouse grab;
 +else
 +status =  - Press Ctrl-Alt to exit mouse grab;
 +}
 +
 +if (qemu_name) {
 +snprintf(win_title, sizeof(win_title), QEMU (%s)%s, qemu_name, 
 status);
 +snprintf

Re: [Qemu-devel] [PATCH] ossaudio: do not enable by default

[Anthony Liguori]

On Wed, Nov 6, 2013 at 3:15 AM, Gerd Hoffmann kra...@redhat.com wrote:
 On Mi, 2013-11-06 at 10:48 +, Peter Maydell wrote:

  That is clearly 1.8 material though.  I think for 1.7 we should simply
  leave things as-is.

 Do you mean as-is with Anthony's patch applied, or as it was
 before that patch was applied ?

 Oh, it is in?

  I would suggest the latter
 (ie revert this patch), because that's the safest choice this
 close to release.

 Agree.

I don't think you guys understand what is happening.

As ossaudio is able to be default, it *will be selected* as the audio
output backend unconditionally.  You aren't seeing errors during
probing, you're seeing errors post-initialization.

The ossaudio init function is simply:

static void *oss_audio_init (void)
{
return conf;
}

It never fails.  So audio is broken on Linux by default today.  This
patch unbreaks it.  If you compare this to the pulseaudio backend
where init can actually fail, you can see why it can be default but
ossaudio really can't.

Regards,

Anthony Liguori

 cheers,
   Gerd

Re: [Qemu-devel] [PATCH] ossaudio: do not enable by default

[Anthony Liguori]

On Wed, Nov 6, 2013 at 7:20 AM, Gerd Hoffmann kra...@redhat.com wrote:
   Hi,

  static void *oss_audio_init (void)
  {
  return conf;
  }
 
  It never fails.

 OK, that's a bug. (I'd misread the calling function
 audio_driver_init() as also checking that the init_in
 and init_out functions succeeded, which it does not.)

  So audio is broken on Linux by default today.  This
  patch unbreaks it.

 No, this patch is papering over the problem by giving us
 a default config where audio works for nobody.

 If you want to fix that problem you need to do it by
 making the oss_audio_init() function return failure
 on init.

 And that is actually simple enough that we can consider it for 1.7:

  static void *oss_audio_init (void)
  {
 +if (access(conf.devpath_in, R_OK | W_OK)  0 ||
 +access(conf.devpath_out, R_OK | W_OK)  0) {
 +return NULL;

That would be reasonable.  Can you add a SoB and submit as a patch?

Regards,

Anthony Liguori

 +}
  return conf;
  }

 cheers,
   Gerd

Re: [Qemu-devel] [PATCH] ossaudio: do not enable by default

[Anthony Liguori]

Gerd Hoffmann kra...@redhat.com writes:

 On So, 2013-11-03 at 08:45 -0800, Anthony Liguori wrote:
 Modern Linux's no longer support /dev/dsp so enabling it by
 default causes audio failures on newer Linux distros.

 That will break sound on BSD.

 I think we should do something like this instead:

 --- a/configure
 +++ b/configure
 @@ -554,7 +554,7 @@ Haiku)
LIBS=-lposix_error_mapper -lnetwork $LIBS
  ;;
  *)
 -  audio_drv_list=oss
 +  audio_drv_list=pa alsa oss
audio_possible_drivers=oss alsa sdl esd pa
linux=yes
linux_user=yes

 i.e. build pulseaudio and alsa by default on linux and prioritize them
 over oss.

This patch just requires that you explicitly select oss so it's not
breaking audio on BSD.

Since the oss code can fail to initialize without handling it
gracefully, it really cannot be default on any platform.

Same problem would occur on BSD if the permissions on /dev/dsp were
restrictive.

Regards,

Anthony Liguori


 cheers,
   Gerd

Re: [Qemu-devel] [PATCH 1.7] pc: get rid of builtin pvpanic for -M pc-1.5

[Anthony Liguori]

Paolo Bonzini pbonz...@redhat.com writes:

 This causes two slight backwards-incompatibilities between -M pc-1.5
 and 1.5's -M pc:

Can you rebase this?  It no longer applies because of the acpi building
changes.

Regards,

Anthony Liguori


 (1) a fw_cfg file is removed with this patch.  This is only a problem
 if migration stops the virtual machine exactly during fw_cfg enumeration.

 (2) after migration, a VM created without an explicit -device pvpanic
 will stop reporting panics to management.

 The first problem only occurs if migration is done at a very, very
 early point (and I'm not sure it can happen in practice for reasonable-size
 VMs, since it will likely take more time to send the RAM to destination,
 than it will take for BIOS to scan fw_cfg).

 The second problem only occurs if the guest panics _and_ has a guest
 driver _and_ management knows to look at the crash event, so it is
 mostly theoretical at this point in time.

 Thus keep the code simple, and pretend it was never broken.

 Signed-off-by: Paolo Bonzini pbonz...@redhat.com
 ---
  hw/i386/pc_piix.c| 7 ---
  hw/i386/pc_q35.c | 7 ---
  hw/misc/pvpanic.c| 5 -
  include/hw/i386/pc.h | 3 ---
  4 files changed, 22 deletions(-)

 diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
 index c6042c7..a041e53 100644
 --- a/hw/i386/pc_piix.c
 +++ b/hw/i386/pc_piix.c
 @@ -57,7 +57,6 @@ static const int ide_iobase[MAX_IDE_BUS] = { 0x1f0, 0x170 };
  static const int ide_iobase2[MAX_IDE_BUS] = { 0x3f6, 0x376 };
  static const int ide_irq[MAX_IDE_BUS] = { 14, 15 };
  
 -static bool has_pvpanic;
  static bool has_pci_info = true;
  
  /* PC hardware initialisation */
 @@ -225,10 +224,6 @@ static void pc_init1(QEMUMachineInitArgs *args,
  if (pci_enabled) {
  pc_pci_device_init(pci_bus);
  }
 -
 -if (has_pvpanic) {
 -pvpanic_init(isa_bus);
 -}
  }
  
  static void pc_init_pci(QEMUMachineInitArgs *args)
 @@ -245,13 +240,11 @@ static void pc_compat_1_6(QEMUMachineInitArgs *args)
  static void pc_compat_1_5(QEMUMachineInitArgs *args)
  {
  pc_compat_1_6(args);
 -has_pvpanic = true;
  }
  
  static void pc_compat_1_4(QEMUMachineInitArgs *args)
  {
  pc_compat_1_5(args);
 -has_pvpanic = false;
  x86_cpu_compat_set_features(n270, FEAT_1_ECX, 0, CPUID_EXT_MOVBE);
  x86_cpu_compat_set_features(Westmere, FEAT_1_ECX, 0, 
 CPUID_EXT_PCLMULQDQ);
  }
 diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
 index ca84e1c..593ed2a 100644
 --- a/hw/i386/pc_q35.c
 +++ b/hw/i386/pc_q35.c
 @@ -47,7 +47,6 @@
  /* ICH9 AHCI has 6 ports */
  #define MAX_SATA_PORTS 6
  
 -static bool has_pvpanic;
  static bool has_pci_info = true;
  
  /* PC hardware initialisation */
 @@ -214,10 +213,6 @@ static void pc_q35_init(QEMUMachineInitArgs *args)
  if (pci_enabled) {
  pc_pci_device_init(host_bus);
  }
 -
 -if (has_pvpanic) {
 -pvpanic_init(isa_bus);
 -}
  }
  
  static void pc_compat_1_6(QEMUMachineInitArgs *args)
 @@ -229,13 +224,11 @@ static void pc_compat_1_6(QEMUMachineInitArgs *args)
  static void pc_compat_1_5(QEMUMachineInitArgs *args)
  {
  pc_compat_1_6(args);
 -has_pvpanic = true;
  }
  
  static void pc_compat_1_4(QEMUMachineInitArgs *args)
  {
  pc_compat_1_5(args);
 -has_pvpanic = false;
  x86_cpu_compat_set_features(n270, FEAT_1_ECX, 0, CPUID_EXT_MOVBE);
  x86_cpu_compat_set_features(Westmere, FEAT_1_ECX, 0, 
 CPUID_EXT_PCLMULQDQ);
  }
 diff --git a/hw/misc/pvpanic.c b/hw/misc/pvpanic.c
 index b64e3bb..4c85906 100644
 --- a/hw/misc/pvpanic.c
 +++ b/hw/misc/pvpanic.c
 @@ -112,11 +112,6 @@ static void pvpanic_isa_realizefn(DeviceState *dev, 
 Error **errp)
  isa_register_ioport(d, s-io, s-ioport);
  }
  
 -void pvpanic_init(ISABus *bus)
 -{
 -isa_create_simple(bus, TYPE_ISA_PVPANIC_DEVICE);
 -}
 -
  static Property pvpanic_isa_properties[] = {
  DEFINE_PROP_UINT16(ioport, PVPanicState, ioport, 0x505),
  DEFINE_PROP_END_OF_LIST(),
 diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
 index 6083839..f6313b2 100644
 --- a/include/hw/i386/pc.h
 +++ b/include/hw/i386/pc.h
 @@ -213,9 +213,6 @@ static inline bool isa_ne2000_init(ISABus *bus, int base, 
 int irq, NICInfo *nd)
  void pc_system_firmware_init(MemoryRegion *rom_memory,
   bool isapc_ram_fw);
  
 -/* pvpanic.c */
 -void pvpanic_init(ISABus *bus);
 -
  /* e820 types */
  #define E820_RAM1
  #define E820_RESERVED   2
 -- 
 1.8.3.1

Re: [Qemu-devel] [PATCH v3] net: Adding netmap network backend

[Anthony Liguori]

On Tue, Oct 29, 2013 at 3:12 AM, Vincenzo Maffione v.maffi...@gmail.com wrote:
 This patch adds support for a network backend based on netmap.
 netmap is a framework for high speed packet I/O. You can use it
 to build extremely fast traffic generators, monitors, software
 switches or network middleboxes. Its companion software switch
 VALE lets you interconnect virtual machines.
 netmap and VALE are implemented as a non intrusive kernel module,
 support NICs from multiple vendors, are part of standard FreeBSD
 distributions and available in source format for Linux too.

I don't think it's a good idea to support this on Linux hosts.  This
is an out of tree module that most likely will never go upstream.

I don't want to live through another kqemu with this if it eventually
starts to bit-rot.

Regards,

Anthony Liguori


 To compile QEMU with netmap support, use the following configure
 options:
 ./configure [...] --enable-netmap --extra-cflags=-I/path/to/netmap/sys
 where /path/to/netmap contains the netmap source code, available at
 http://info.iet.unipi.it/~luigi/netmap/

 The same webpage contains more information about the netmap project
 (together with papers and presentations).

 Signed-off-by: Vincenzo Maffione v.maffi...@gmail.com
 ---
 This patch follows a previous thread (whose subject was netmap backend),
 in which a previous version was already revised. All the review comments
 have been taken into consideration or applied.

 This patch only contains the simplest netmap backend for QEMU.
 In particular, this backend implementation is still not
 able to make use of batching on the TX side (frontend - backend),
 which is where most of the TX performance gain comes from.
 As you can see from the code, there is an ioctl(NIOCTXSYNC) for each
 packet, instead of an ioctl(NIOCTXSYNC) for a batch of packets.
 In order to make TX batching possible, we would need to do some
 modifications to the generic net/net.c code, adding to the
 frontend/backend datapath interface a way to send a batch (this can
 be done using a QEMU_NET_PACKET_FLAG_MORE, without changing too
 much the existing interface).
 We will propose these features in future patches.

  configure |  31 
  hmp-commands.hx   |   4 +-
  net/Makefile.objs |   1 +
  net/clients.h |   5 +
  net/net.c |   6 +
  net/netmap.c  | 423 
 ++
  qapi-schema.json  |  19 ++-
  qemu-options.hx   |   8 ++
  8 files changed, 494 insertions(+), 3 deletions(-)
  create mode 100644 net/netmap.c

 diff --git a/configure b/configure
 index 57ee62a..4046fe5 100755
 --- a/configure
 +++ b/configure
 @@ -155,6 +155,7 @@ curl=
  curses=
  docs=
  fdt=
 +netmap=
  pixman=
  sdl=
  virtfs=
 @@ -777,6 +778,10 @@ for opt do
;;
--enable-vde) vde=yes
;;
 +  --disable-netmap) netmap=no
 +  ;;
 +  --enable-netmap) netmap=yes
 +  ;;
--disable-xen) xen=no
;;
--enable-xen) xen=yes
 @@ -1157,6 +1162,8 @@ echo   --disable-uuid   disable uuid support
  echo   --enable-uuidenable uuid support
  echo   --disable-vdedisable support for vde network
  echo   --enable-vde enable support for vde network
 +echo   --disable-netmap disable support for netmap network
 +echo   --enable-netmap  enable support for netmap network
  echo   --disable-linux-aio  disable Linux AIO support
  echo   --enable-linux-aio   enable Linux AIO support
  echo   --disable-cap-ng disable libcap-ng support
 @@ -2061,6 +2068,26 @@ EOF
  fi

  ##
 +# netmap headers probe
 +if test $netmap != no ; then
 +  cat  $TMPC  EOF
 +#include inttypes.h
 +#include net/if.h
 +#include net/netmap.h
 +#include net/netmap_user.h
 +int main(void) { return 0; }
 +EOF
 +  if compile_prog   ; then
 +netmap=yes
 +  else
 +if test $netmap = yes ; then
 +  feature_not_found netmap
 +fi
 +netmap=no
 +  fi
 +fi
 +
 +##
  # libcap-ng library probe
  if test $cap_ng != no ; then
cap_libs=-lcap-ng
 @@ -3716,6 +3743,7 @@ echo uname -r  $uname_release
  echo GUEST_BASE$guest_base
  echo PIE   $pie
  echo vde support   $vde
 +echo netmap support$netmap
  echo Linux AIO support $linux_aio
  echo ATTR/XATTR support $attr
  echo Install blobs $blobs
 @@ -3854,6 +3882,9 @@ fi
  if test $vde = yes ; then
echo CONFIG_VDE=y  $config_host_mak
  fi
 +if test $netmap = yes ; then
 +  echo CONFIG_NETMAP=y  $config_host_mak
 +fi
  if test $cap_ng = yes ; then
echo CONFIG_LIBCAP=y  $config_host_mak
  fi
 diff --git a/hmp-commands.hx b/hmp-commands.hx
 index caae5ad..ebe8e78 100644
 --- a/hmp-commands.hx
 +++ b/hmp-commands.hx
 @@ -1190,7 +1190,7 @@ ETEXI
  {
  .name   = host_net_add,
  .args_type  = device:s,opts:s?,
 -.params = tap|user|socket|vde|dump [options],
 +.params = tap

Re: [Qemu-devel] [PATCH v3] net: Adding netmap network backend

[Anthony Liguori]

On Mon, Nov 4, 2013 at 10:08 AM, Luigi Rizzo ri...@iet.unipi.it wrote:



 On Mon, Nov 4, 2013 at 9:41 AM, Anthony Liguori anth...@codemonkey.ws
 wrote:

 On Tue, Oct 29, 2013 at 3:12 AM, Vincenzo Maffione v.maffi...@gmail.com
 wrote:
  This patch adds support for a network backend based on netmap.
  netmap is a framework for high speed packet I/O. You can use it
  to build extremely fast traffic generators, monitors, software
  switches or network middleboxes. Its companion software switch
  VALE lets you interconnect virtual machines.
  netmap and VALE are implemented as a non intrusive kernel module,
  support NICs from multiple vendors, are part of standard FreeBSD
  distributions and available in source format for Linux too.

 I don't think it's a good idea to support this on Linux hosts.  This
 is an out of tree module that most likely will never go upstream.

 I don't want to live through another kqemu with this if it eventually
 starts to bit-rot.


 I believe this is very different from kqemu.

 For first, it is just a one-file backend (the patches
 to other files are just because there is not yet a way
 to automatically generate them; but i am sure qemu
 will get there). Getting rid of it, should the code
 bit-rot, is completely trivial.

 Second, there is nothing linux specific here. Unless configure
 determines that the (possibly out of tree, as in Linux,
 or in-tree, as in FreeBSD) netmap headers are
 installed, it just won't build the backend.

Without being in upstream Linux, we have no guarantee that the API/ABI
will be stable over time.  I suspect it's also very unlikely that any
many stream distro will include these patches meaning that the number
of users that will test this is very low.

I don't think just adding another backend because we can helps us out
in the long term.  Either this is the Right Approach to networking and
we should focus on getting proper kernel support or if that's not
worth it, then there's no reason to include this in QEMU either.

Regards,

Anthony Liguori

 I am not sure if you do not want to support netmap _in general_
 (despite it is already upstream in FreeBSD),
 or you'd like to put extra checks in ./configure to actually
 prevent its use on linux hosts.

 Both cases it seems to me a loss of a useful feature with no
 real return


 configure |  31 

  hmp-commands.hx   |   4 +-

  net/Makefile.objs |   1 +

  net/clients.h |   5 +

  net/net.c |   6 +

  net/netmap.c  | 423
 ++

  qapi-schema.json  |  19 ++-

  qemu-options.hx   |   8 ++

  8 files changed, 494 insertions(+), 3 deletions(-)

  create mode 100644 net/netmap.c

 cheers
 luigi

Re: [Qemu-devel] [PATCH v3] net: Adding netmap network backend

[Anthony Liguori]

On Mon, Nov 4, 2013 at 11:51 AM, Luigi Rizzo ri...@iet.unipi.it wrote:
 On Mon, Nov 04, 2013 at 10:20:12AM -0800, Anthony Liguori wrote:
 On Mon, Nov 4, 2013 at 10:08 AM, Luigi Rizzo ri...@iet.unipi.it wrote:
 ...
  On Tue, Oct 29, 2013 at 3:12 AM, Vincenzo Maffione v.maffi...@gmail.com
  wrote:
   This patch adds support for a network backend based on netmap.
   netmap is a framework for high speed packet I/O. You can use it
   to build extremely fast traffic generators, monitors, software
   switches or network middleboxes. Its companion software switch
   VALE lets you interconnect virtual machines.
   netmap and VALE are implemented as a non intrusive kernel module,
   support NICs from multiple vendors, are part of standard FreeBSD
   distributions and available in source format for Linux too.
 
  I don't think it's a good idea to support this on Linux hosts.  This
  is an out of tree module that most likely will never go upstream.
 
  I don't want to live through another kqemu with this if it eventually
  starts to bit-rot.
 
 
  I believe this is very different from kqemu.
 
  For first, it is just a one-file backend (the patches
  to other files are just because there is not yet a way
  to automatically generate them; but i am sure qemu
  will get there). Getting rid of it, should the code
  bit-rot, is completely trivial.
 
  Second, there is nothing linux specific here. Unless configure
  determines that the (possibly out of tree, as in Linux,
  or in-tree, as in FreeBSD) netmap headers are
  installed, it just won't build the backend.

 Without being in upstream Linux, we have no guarantee that the API/ABI
 will be stable over time.  I suspect it's also very unlikely that any
 many stream distro will include these patches meaning that the number
 of users that will test this is very low.

 I don't think just adding another backend because we can helps us out
 in the long term.  Either this is the Right Approach to networking and
 we should focus on getting proper kernel support or if that's not
 worth it, then there's no reason to include this in QEMU either.

 anthony,
 i'd still like you to answer the question that i asked before:

 are you opposed to netmap support just for linux, or you
 oppose to it in general (despite netmap being already
 upstream in FreeBSD) ?

 Your reasoning seems along the lines if feature X is not upstream
 in linux we do not want to support it.

Yes.  This is the historic policy we have taken for any feature.  I
have no problem with netmap being used on FreeBSD hosts but I think it
should not be enabled on Linux hosts.

Regards,

Anthony Liguori

Re: [Qemu-devel] [PATCH v3] net: Adding netmap network backend

[Anthony Liguori]

On Mon, Nov 4, 2013 at 1:08 PM, Luigi Rizzo ri...@iet.unipi.it wrote:



 On Mon, Nov 4, 2013 at 12:54 PM, Anthony Liguori anth...@codemonkey.ws
 wrote:

 On Mon, Nov 4, 2013 at 11:51 AM, Luigi Rizzo ri...@iet.unipi.it wrote:
  On Mon, Nov 04, 2013 at 10:20:12AM -0800, Anthony Liguori wrote:
  On Mon, Nov 4, 2013 at 10:08 AM, Luigi Rizzo ri...@iet.unipi.it
  wrote:
  ...
   On Tue, Oct 29, 2013 at 3:12 AM, Vincenzo Maffione
   v.maffi...@gmail.com
   wrote:
This patch adds support for a network backend based on netmap.
netmap is a framework for high speed packet I/O. You can use it
to build extremely fast traffic generators, monitors, software
switches or network middleboxes. Its companion software switch
VALE lets you interconnect virtual machines.
netmap and VALE are implemented as a non intrusive kernel module,
support NICs from multiple vendors, are part of standard FreeBSD
distributions and available in source format for Linux too.
  
   I don't think it's a good idea to support this on Linux hosts.  This
   is an out of tree module that most likely will never go upstream.
  
   I don't want to live through another kqemu with this if it
   eventually
   starts to bit-rot.
  
  
   I believe this is very different from kqemu.
  
   For first, it is just a one-file backend (the patches
   to other files are just because there is not yet a way
   to automatically generate them; but i am sure qemu
   will get there). Getting rid of it, should the code
   bit-rot, is completely trivial.
  
   Second, there is nothing linux specific here. Unless configure
   determines that the (possibly out of tree, as in Linux,
   or in-tree, as in FreeBSD) netmap headers are
   installed, it just won't build the backend.
 
  Without being in upstream Linux, we have no guarantee that the API/ABI
  will be stable over time.  I suspect it's also very unlikely that any
  many stream distro will include these patches meaning that the number
  of users that will test this is very low.
 
  I don't think just adding another backend because we can helps us out
  in the long term.  Either this is the Right Approach to networking and
  we should focus on getting proper kernel support or if that's not
  worth it, then there's no reason to include this in QEMU either.
 
  anthony,
  i'd still like you to answer the question that i asked before:
 
  are you opposed to netmap support just for linux, or you
  oppose to it in general (despite netmap being already
  upstream in FreeBSD) ?
 
  Your reasoning seems along the lines if feature X is not upstream
  in linux we do not want to support it.

 Yes.  This is the historic policy we have taken for any feature.  I
 have no problem with netmap being used on FreeBSD hosts but I think it
 should not be enabled on Linux hosts.


 ok thanks for the clarification.
 S
 o I misunderstood
 ,
  the policy is
 if not upstream in linux, we do not want to support it _on linux_.
 A fundamental difference :)

 So in ./configure we must change to 'netmap=no' in the initial
 section to disable it by default, and add a line 'netmap=' in the
 FreeBSD section to enable autodetect there.

Correct.  Sorry for the confusion.

Regards,

Anthony Liguori


 cheers
 luigi

Re: [Qemu-devel] [PULL v2 00/56] QOM devices patch queue 2013-10-31

[Anthony Liguori]

On Sun, Nov 3, 2013 at 5:28 AM, Andreas Färber afaer...@suse.de wrote:
 Anthony,

 The errors are the exact same as before.  Install some VMs and
 reproduce the problem.  I just checked and it fails under 64-bit
 Fedora 19.

 I have successfully booted up openSUSE 12.3 x86_64 and SLES 11 SP3
 x86_64 without any issue. You really need to explain the problem!

Andreas,

I told you how to reproduce the problem.  If you choose not to
investigate, fine, but don't spam me with resends of a pull request
with a known breakage.

Regards,

Anthony Liguori

 Regards,
 Andreas


 Regards,

 Anthony Liguori

 v2 is rebased, dropping two ARM patches, and the observed SD segfault had 
 been
 fixed in 794cbc26eb94ce13c75d105eea9ff0afff56e2c2.
 Patches are not manually changed, thus intentionally not resent.

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

Re: [Qemu-devel] [PULL v2 00/56] QOM devices patch queue 2013-10-31

[Anthony Liguori]

On Sun, Nov 3, 2013 at 7:12 AM, Andreas Färber afaer...@suse.de wrote:
 Anthony,

 Am 03.11.2013 14:58, schrieb Anthony Liguori:
 On Sun, Nov 3, 2013 at 5:28 AM, Andreas Färber afaer...@suse.de wrote:
 Anthony,

 The errors are the exact same as before.  Install some VMs and
 reproduce the problem.  I just checked and it fails under 64-bit
 Fedora 19.

 I have successfully booted up openSUSE 12.3 x86_64 and SLES 11 SP3
 x86_64 without any issue. You really need to explain the problem!

 Andreas,

 I told you how to reproduce the problem.

 No, you didn't, that's the problem! See below.

  If you choose not to
 investigate, fine, but don't spam me with resends of a pull request
 with a known breakage.

 This is v2 so that's hardly spamming anyone. And may I remind you that
 you have not bothered to send even a single email reply to v1.

 Here's my IRC excerpt:

 Okt 10 18:42:37 aliguori  afaerber_, ping
 Okt 10 18:44:01 aliguori  afaerber_, http://pastie.org/8392810

 --8--
 [40d09bdc65bab245439ac85b60e26b90212d5f06] qtest: Prepare QOM machine tests
 running ./bisect-qemu-test.sh
 ~/build/qemu ~/git/qemu
 audio: Failed to create voice `lm4549.out'
 audio: Failed to create voice `lm4549.out'
 audio: Failed to create voice `lm4549.out'
 audio: Failed to create voice `lm4549.out'
 audio: Failed to create voice `lm4549.out'
 audio: Failed to create voice `lm4549.out'
 audio: Failed to create voice `lm4549.out'
 audio: Failed to create voice `lm4549.out'
 audio: Failed to create voice `mm_ac97.in'
 audio: Failed to create voice `mm_ac97.out'
 40d09bdc65bab245439ac85b60e26b90212d5f06 is the first bad commit
 commit 40d09bdc65bab245439ac85b60e26b90212d5f06
 Author: Andreas Färber afaer...@suse.de
 Date:   Mon Jul 29 05:44:47 2013 +0200

 qtest: Prepare QOM machine tests

 Instantiate all [*] machines per target, so that they get a bit of test
 coverage at all. This has proven helpful during QOM refactorings.

 [*] ppcemb target contains some non-working non-embedded machines, and
 ppc405 CPUs are not available there either.
 i386 and x86_64 do not cover pc*-x.y or xenfv.

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

 :04 04 f2bbe30467a164608ca9d8be20b0d689b607c396
 673e5111dc8d23d7c00a76ba6ea613b8c6724235 M  tests
 bisect run success
 --8--

 Okt 14 18:14:20 aliguori  afaerber, ping
 Okt 14 18:14:48 afaerber  aliguori, pong - I already started writing to
 you, my output looks different
 Okt 14 18:14:55 aliguori  okay, cool
 Okt 14 18:15:02 aliguori  afaerber, just wanted to make sure you saw my
 note
 Okt 14 18:15:34 afaerber  aliguori, yeah I did but I was away on Friday
 and most of the weekend
 Okt 14 18:16:02 afaerber  aliguori, do you have any QEMU_AUDIO_DRV set
 in your environment?
 Okt 14 18:16:35 afaerber  I usually unset that since openSUSE sets it
 to alsa but I usually don't enable alsa support in configure
 Okt 14 18:16:37 aliguori  afaerber, no
 Okt 14 18:20:04 afaerber  s/alsa/pulseaudio/g
 Okt 14 18:21:37 afaerber  aliguori, http://paste.opensuse.org/760f8573
 Okt 14 18:22:06 afaerber  there is an oss error for lm32 but no test
 failures
 Okt 14 18:22:24 afaerber  similarly as mentioned before if pa driver is
 requested but not built in there are errors, too

 Okt 15 19:05:03 afaerber  aliguori, any new insights into the qtest 
 issue?
 Okt 15 19:05:28 *   afaerber has rebased and getting broken pipe now,
 re-checking master

 (NB the broken pipe after rebasing was the SD block breakage.)

 That's all I had from you.

 And for me asking you to look into it with me during Hackathon there
 will surely be several witnesses from QEMU Summit.

Andreas,

I don't know what you're trying to prove here but you're wasting your breathe.

There is only one thing that matters here--don't send known broken
pull requests.  There is nothing you can say or do that will every
justify sending something that you know is broken.  Period.

Everything else is excuses.  If you need more help from me to trouble
shoot the problem, ask.  If you have trouble getting in touch with me,
complain loudly and publicly.  Don't send me broken pull requests.
That's unacceptable from a submaintainer.

The problem here is that we have broken boards and your patch is
blindly enabling qtest on them.  We shouldn't do that.

In particular, the problem is that the lm4549 is bit-rotted which is
spawned by pl041 which is pulled in by certain boards like the
vexpress-a15 on arm-softmmu.  My guess is that your config doesn't
have audio enabled so this device is being hidden or something like
that.

Regards,

Anthony Liguori

[Qemu-devel] [PATCH] ossaudio: do not enable by default

[Anthony Liguori]

Modern Linux's no longer support /dev/dsp so enabling it by
default causes audio failures on newer Linux distros.

Signed-off-by: Anthony Liguori aligu...@amazon.com
---
 audio/ossaudio.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/audio/ossaudio.c b/audio/ossaudio.c
index 007c641..3e04a58 100644
--- a/audio/ossaudio.c
+++ b/audio/ossaudio.c
@@ -932,7 +932,7 @@ struct audio_driver oss_audio_driver = {
 .init   = oss_audio_init,
 .fini   = oss_audio_fini,
 .pcm_ops= oss_pcm_ops,
-.can_be_default = 1,
+.can_be_default = 0,
 .max_voices_out = INT_MAX,
 .max_voices_in  = INT_MAX,
 .voice_size_out = sizeof (OSSVoiceOut),
-- 
1.8.3.1

Re: [Qemu-devel] [PATCH] ossaudio: do not enable by default

[Anthony Liguori]

On Sun, Nov 3, 2013 at 9:12 AM, Andreas Färber afaer...@suse.de wrote:
 Am 03.11.2013 17:45, schrieb Anthony Liguori:
 Modern Linux's no longer support /dev/dsp so enabling it by
 default causes audio failures on newer Linux distros.

 Signed-off-by: Anthony Liguori aligu...@amazon.com
 ---
  audio/ossaudio.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 With my current config, this patch is not making a change. make
 check-qtest-arm succeeds on qom-next branch with and without it without
 any annoying output. So FWIW

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

 Note that author and Sob differ, probably not intentionally.

Nope, thanks.

Regards,

Anthony Liguori

 Regards,
 Andreas

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

Re: [Qemu-devel] [PULL v2 00/30] Block patches

[Anthony Liguori]

On Thu, Oct 31, 2013 at 10:52 PM, Paolo Bonzini pbonz...@redhat.com wrote:
 Il 31/10/2013 21:50, Anthony Liguori ha scritto:
   /x86_64/ide/bmdma/setup: OK
   /x86_64/ide/bmdma/simple_rw: OK
   /x86_64/ide/bmdma/short_prdt:OK
   /x86_64/ide/bmdma/long_prdt: OK
   /x86_64/ide/bmdma/no_busmaster:
 Broken pipe
 FAIL
 GTester: last random seed: R02Sc1c266d6688697d47a58af063ff343c5
 (pid=720)
   /x86_64/ide/bmdma/teardown:  FAIL
 GTester: last random seed: R02S2c481529260b1d513b7a498b45a5b420
 (pid=736)
 FAIL: tests/ide-test

 It might not help, but I suggest that you merge [PATCH 1.7] timers: fix
 stop/cont with -icount before anything else.

It appears to help actually.  I'll do some more testing and push if I
don't find anything else.  Thanks Paolo!

Regards,

Anthony Liguori

 Paolo

Re: [Qemu-devel] [PATCH] import kvm-unittest in QEMU source tree

[Anthony Liguori]

On Thu, Oct 31, 2013 at 8:48 AM, Gleb Natapov g...@redhat.com wrote:
 On Wed, Oct 30, 2013 at 04:06:19PM -0700, Andrew Jones wrote:
 On Wed, Oct 16, 2013 at 10:03:37PM +0300, Michael S. Tsirkin wrote:
  This simply imports kvm-unittest git into qemu source tree.
 
  We can next work on making make check run it
  automatically.
 
  Squashed 'kvm-unittest/' content from commit 2bc0e29
 
  git-subtree-dir: kvm-unittest
  git-subtree-split: 2bc0e29ee4447bebcd3b90053881f59265306adc
 
  Signed-off-by: Michael S. Tsirkin m...@redhat.com
 
  ---
 
  Gleb, Paolo, any objections to this?  I really want a small guest for
  running ACPI tests during make check, and kvm-unittest seems to fit the
  bill.
 
  Ability to test e.g. PCI with this in-tree would be very benefitial.
 

 Sorry for slow reply, I just noticed this mail now.

 So far qemu is a dependency for kvm-unit-tests (both x86 and arm use it),
 but at some point that could change (if another arch doesn't want to use
 qemu). So if that happens, then it won't make much sense for the tests to
 live in qemu. Thus I'm not 100% in favor of moving them. However, if the
 consensus is to move them, then I have two comments on this patch.

 Do not worry, we are far from such consensus :)

I don't think kvm-unit-tests belong in QEMU either.  They are tied to
the kernel side of things, not QEMU and many of the tests don't make
sense for TCG.

If you want to execute guest code within QEMU's make check, we can
copy the basic infrastructure in kvm-unit-tests.  It's so simple that
a fork isn't really much of a concern to me.

Regards,

Anthony Liguori

 1) There are a couple pendings patches on the kvm list that tidy up the
 kvm-unit-tests repo - removing lots of the files. That should be
 committed first to avoid importing a bunch of files right before deleting
 them.

 2) The name shouldn't change from kvm-unit-tests to kvm-unittest.

 drew

 --
 Gleb.

Re: [Qemu-devel] [PULL 0/6] target-arm queue

[Anthony Liguori]

On Thu, Oct 31, 2013 at 3:18 PM, Andreas Färber afaer...@suse.de wrote:
 Hi,

 Am 31.10.2013 15:02, schrieb Edgar E. Iglesias:
 On Fri, Oct 25, 2013 at 07:07:23PM +0100, Peter Maydell wrote:
 The following changes since commit fc8ead74674b7129e8f31c2595c76658e5622197:

   Merge remote-tracking branch 'qemu-kvm/uq/master' into staging 
 (2013-10-18 10:03:24 -0700)

 are available in the git repository at:


   git://git.linaro.org/people/pmaydell/qemu-arm.git 
 tags/pull-target-arm-20131025

 for you to fetch changes up to 71c903cc3b78fc563122fe40c5cadd050068b91a:

   integrator: fix Linux boot failure by emulating dbg region (2013-10-25 
 18:27:07 +0100)


 Applied, thanks all.

 Edgar, there is no merge commit in qemu.git despite this being a signed
 pull. Do you maybe need to upgrade your version of git?

Need to add:

[merge]
 ff = false

To your git config to prevent fast forwards on merging.

Regards,

Anthony Liguori

 Peter, since I had picked up the first two patches into my still pending
 qom-next pull, as per the QEMU Summit discussion those patches should've
 gotten an Acked-by.

 Regards,
 Andreas

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

Re: [Qemu-devel] pvpanic plans?

[Anthony Liguori]

On Thu, Oct 31, 2013 at 3:32 PM, Eric Blake ebl...@redhat.com wrote:
 On 10/31/2013 08:30 AM, Michael S. Tsirkin wrote:
 On Thu, Oct 24, 2013 at 10:39:03AM +0800, Hu Tao wrote:
 Hi All,

 I know it's been a long time since this thread. But qemu 1.7 is
 releasing, do you have any consensus on this?

 Thanks.


 I think the biggest issue is the new PANICKED state.
 Guests already have simple ways to halt the CPU,
 and actually do.  I think a new state was a mistake.
 So how about the following? Does it break anything?
 (Untested).

 Signed-off-by: Michael S. Tsirkin m...@redhat.com

 diff --git a/hw/misc/pvpanic.c b/hw/misc/pvpanic.c
 index 226e298..2055afc 100644
 --- a/hw/misc/pvpanic.c
 +++ b/hw/misc/pvpanic.c
 @@ -51,7 +51,6 @@ static void handle_event(int event)

  if (event  PVPANIC_PANICKED) {
  panicked_mon_event(pause);
 -vm_stop(RUN_STATE_GUEST_PANICKED);

 Don't you still need to halt the guest on a panic event, for management
 to have a chance to choose what to do about the panic?  I'm suspecting
 this patch does break things.

I would be happy to apply a patch that just reverted the whole dang
mess of this device.

Regards,

Anthony Liguori

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

Re: [Qemu-devel] [PULL 0/6] target-arm queue

[Anthony Liguori]

On Thu, Oct 31, 2013 at 3:36 PM, Andreas Färber afaer...@suse.de wrote:
 Am 31.10.2013 15:31, schrieb Peter Maydell:
 On 31 October 2013 14:18, Andreas Färber afaer...@suse.de wrote:
 Peter, since I had picked up the first two patches into my still pending
 qom-next pull, as per the QEMU Summit discussion those patches should've
 gotten an Acked-by.

 Hmm? I don't recall this part of the discussion. If you want the
 patches to have an Acked-by from you you need to send mail
 to the list with an Acked-by line.

 No, I added a Signed-off-by. It was clearly stated that a Reviewed-by
 needs to be explicitly sent as reply but that looks okay should in
 exactly such a case where sender=submaintainer should be recorded as
 Acked-by, and Sob is certainly stronger than Acked-by. Cf. minutes.

Nope.  If you want there to be an Acked-by, say Acked-by:.  Don't
make people infer your Acked-bys.

And adding tags is a nice-to-have.  There is no rule stating that
you must include everyone that appears on the mailing list.  But I
expect that maintainers try to

Regards,

Anthony Liguori

 Andreas

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

Re: [Qemu-devel] [PULL 0/6] target-arm queue

[Anthony Liguori]

On Thu, Oct 31, 2013 at 3:45 PM, Andreas Färber afaer...@suse.de wrote:
 Am 31.10.2013 15:39, schrieb Anthony Liguori:
 On Thu, Oct 31, 2013 at 3:36 PM, Andreas Färber afaer...@suse.de wrote:
 Am 31.10.2013 15:31, schrieb Peter Maydell:
 On 31 October 2013 14:18, Andreas Färber afaer...@suse.de wrote:
 Peter, since I had picked up the first two patches into my still pending
 qom-next pull, as per the QEMU Summit discussion those patches should've
 gotten an Acked-by.

 Hmm? I don't recall this part of the discussion. If you want the
 patches to have an Acked-by from you you need to send mail
 to the list with an Acked-by line.

 No, I added a Signed-off-by. It was clearly stated that a Reviewed-by
 needs to be explicitly sent as reply but that looks okay should in
 exactly such a case where sender=submaintainer should be recorded as
 Acked-by, and Sob is certainly stronger than Acked-by. Cf. minutes.

 Nope.  If you want there to be an Acked-by, say Acked-by:.  Don't
 make people infer your Acked-bys.

 Yes, that's in the minutes. And yes, that's what I got as answer there.
 Please reply to the minutes if you think otherwise.

I

 I brought up exactly this situation where I am contributor to CPU and
 submaintainer of CPU and often not getting Reviewed-bys but if at all,
 such as from Paolo recently, some verbal looks OK for a series. I was
 told that that should be turned into an Acked-by on the patches to
 satisfy your criteria that contributors may not just send patches as
 pull without Reviewed-by.

 And adding tags is a nice-to-have.  There is no rule stating that
 you must include everyone that appears on the mailing list.  But I
 expect that maintainers try to

 Again, at QEMU Summit you pushed for making Reviewed-by a must-have and
 we discussed whether a submaintainer must add a Reviewed-by then and
 what to do if author==submaintainer. If you dropped that thought, then
 fine with me.

 Regards,
 Andreas

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

Re: [Qemu-devel] [PULL 0/6] target-arm queue

[Anthony Liguori]

On Thu, Oct 31, 2013 at 3:45 PM, Andreas Färber afaer...@suse.de wrote:
 Am 31.10.2013 15:39, schrieb Anthony Liguori:
 On Thu, Oct 31, 2013 at 3:36 PM, Andreas Färber afaer...@suse.de wrote:
 Am 31.10.2013 15:31, schrieb Peter Maydell:
 On 31 October 2013 14:18, Andreas Färber afaer...@suse.de wrote:
 Peter, since I had picked up the first two patches into my still pending
 qom-next pull, as per the QEMU Summit discussion those patches should've
 gotten an Acked-by.

 Hmm? I don't recall this part of the discussion. If you want the
 patches to have an Acked-by from you you need to send mail
 to the list with an Acked-by line.

 No, I added a Signed-off-by. It was clearly stated that a Reviewed-by
 needs to be explicitly sent as reply but that looks okay should in
 exactly such a case where sender=submaintainer should be recorded as
 Acked-by, and Sob is certainly stronger than Acked-by. Cf. minutes.

 Nope.  If you want there to be an Acked-by, say Acked-by:.  Don't
 make people infer your Acked-bys.

 Yes, that's in the minutes. And yes, that's what I got as answer there.
 Please reply to the minutes if you think otherwise.

I explicitly said that Acked-bys are useless too.

The minutes say that you said the kernel treats Acked-bys as looks
good.  You did say that.  At no point did a rule get made though.

 I brought up exactly this situation where I am contributor to CPU and
 submaintainer of CPU and often not getting Reviewed-bys but if at all,
 such as from Paolo recently, some verbal looks OK for a series. I was
 told that that should be turned into an Acked-by on the patches to
 satisfy your criteria that contributors may not just send patches as
 pull without Reviewed-by.

I think you misunderstood.

I don't care about Acked-bys.  They are useless.

A third of patches are being committed with Reviewed-bys.  There are
certainly many cases where patches are going in from submaintainers
that have been reviewed which comes implicitly with Signed-off-by.

But I worry that we're not reviewing enough on list and that there are
patches from maintainers going in through maintainer trees that aren't
getting outside review.

There's no immediate action for this other than we should all try to
review more patches on list to prevent the above situation.

 And adding tags is a nice-to-have.  There is no rule stating that
 you must include everyone that appears on the mailing list.  But I
 expect that maintainers try to

 Again, at QEMU Summit you pushed for making Reviewed-by a must-have and
 we discussed whether a submaintainer must add a Reviewed-by then and
 what to do if author==submaintainer. If you dropped that thought, then
 fine with me.

Yes, patches should get reviewed.  I hope this is obvious to all of us :-)

I also suggested that I have tooling that people can use to simplify
adding collected Reviewed-bys on the list.

But none of this has anything to do with inferred Acked-bys.  I'll go
a step further and say that I would be very unhappy if anyone every
added any kind of tag to a patch with my name on it that I didn't send
myself.

Regards,

Anthony Liguori


 Regards,
 Andreas

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

Re: [Qemu-devel] [PULL 0/6] target-arm queue

[Anthony Liguori]

On Thu, Oct 31, 2013 at 5:52 PM, Andreas Färber afaer...@suse.de wrote:
 Am 31.10.2013 16:04, schrieb Anthony Liguori:
 On Thu, Oct 31, 2013 at 3:45 PM, Andreas Färber afaer...@suse.de wrote:
 Am 31.10.2013 15:39, schrieb Anthony Liguori:
 On Thu, Oct 31, 2013 at 3:36 PM, Andreas Färber afaer...@suse.de wrote:
 Am 31.10.2013 15:31, schrieb Peter Maydell:
 On 31 October 2013 14:18, Andreas Färber afaer...@suse.de wrote:
 Peter, since I had picked up the first two patches into my still pending
 qom-next pull, as per the QEMU Summit discussion those patches should've
 gotten an Acked-by.

 Hmm? I don't recall this part of the discussion. If you want the
 patches to have an Acked-by from you you need to send mail
 to the list with an Acked-by line.

 No, I added a Signed-off-by. It was clearly stated that a Reviewed-by
 needs to be explicitly sent as reply but that looks okay should in
 exactly such a case where sender=submaintainer should be recorded as
 Acked-by, and Sob is certainly stronger than Acked-by. Cf. minutes.

 Nope.  If you want there to be an Acked-by, say Acked-by:.  Don't
 make people infer your Acked-bys.

 Yes, that's in the minutes. And yes, that's what I got as answer there.
 Please reply to the minutes if you think otherwise.

 I explicitly said that Acked-bys are useless too.

 The minutes say that you said the kernel treats Acked-bys as looks
 good.  You did say that.

 I *asked* about what to do with my QEMU CPU patches that only get a
 looks okay and got only positive answers for whether that should be an
 Acked-by and no objection, including none from you.
 I certainly said nothing at all about the kernel.

  At no point did a rule get made though.

 The new rule you made was: no patch without Reviewed-by.
 Peter sending that PULL and Edgar merging it both violate that rule.

I never said anything like that.

Regards,

Anthony Liguori

 No objection against a particular patch function-wise.

 Point is, had Peter ping'ed me before sending out that pull, he would've
 actually gotten a Reviewed-by from me, thereby satisfying your rule! He
 didn't, ignoring that he himself had actually told me to queue the
 patches before his vacation, for which obviously I reviewed and tested them.

 Maybe there's no obligation for picking up tags, but then again you
 can't go ahead and do statistics over incompletely recorded tags.

 Regards,
 Andreas

 I brought up exactly this situation where I am contributor to CPU and
 submaintainer of CPU and often not getting Reviewed-bys but if at all,
 such as from Paolo recently, some verbal looks OK for a series. I was
 told that that should be turned into an Acked-by on the patches to
 satisfy your criteria that contributors may not just send patches as
 pull without Reviewed-by.

 I think you misunderstood.

 I don't care about Acked-bys.  They are useless.

 A third of patches are being committed with Reviewed-bys.  There are
 certainly many cases where patches are going in from submaintainers
 that have been reviewed which comes implicitly with Signed-off-by.

 But I worry that we're not reviewing enough on list and that there are
 patches from maintainers going in through maintainer trees that aren't
 getting outside review.

 There's no immediate action for this other than we should all try to
 review more patches on list to prevent the above situation.

 And adding tags is a nice-to-have.  There is no rule stating that
 you must include everyone that appears on the mailing list.  But I
 expect that maintainers try to

 Again, at QEMU Summit you pushed for making Reviewed-by a must-have and
 we discussed whether a submaintainer must add a Reviewed-by then and
 what to do if author==submaintainer. If you dropped that thought, then
 fine with me.

 Yes, patches should get reviewed.  I hope this is obvious to all of us :-)

 I also suggested that I have tooling that people can use to simplify
 adding collected Reviewed-bys on the list.

 But none of this has anything to do with inferred Acked-bys.  I'll go
 a step further and say that I would be very unhappy if anyone every
 added any kind of tag to a patch with my name on it that I didn't send
 myself.

 Regards,

 Anthony Liguori


 Regards,
 Andreas

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


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

Re: [Qemu-devel] [PULL 0/6] target-arm queue

[Anthony Liguori]

On Thu, Oct 31, 2013 at 5:52 PM, Andreas Färber afaer...@suse.de wrote:
 Am 31.10.2013 16:04, schrieb Anthony Liguori:
 On Thu, Oct 31, 2013 at 3:45 PM, Andreas Färber afaer...@suse.de wrote:
 Am 31.10.2013 15:39, schrieb Anthony Liguori:
 On Thu, Oct 31, 2013 at 3:36 PM, Andreas Färber afaer...@suse.de wrote:
 Am 31.10.2013 15:31, schrieb Peter Maydell:
 On 31 October 2013 14:18, Andreas Färber afaer...@suse.de wrote:
 Peter, since I had picked up the first two patches into my still pending
 qom-next pull, as per the QEMU Summit discussion those patches should've
 gotten an Acked-by.

 Hmm? I don't recall this part of the discussion. If you want the
 patches to have an Acked-by from you you need to send mail
 to the list with an Acked-by line.

 No, I added a Signed-off-by. It was clearly stated that a Reviewed-by
 needs to be explicitly sent as reply but that looks okay should in
 exactly such a case where sender=submaintainer should be recorded as
 Acked-by, and Sob is certainly stronger than Acked-by. Cf. minutes.

 Nope.  If you want there to be an Acked-by, say Acked-by:.  Don't
 make people infer your Acked-bys.

 Yes, that's in the minutes. And yes, that's what I got as answer there.
 Please reply to the minutes if you think otherwise.

 I explicitly said that Acked-bys are useless too.

 The minutes say that you said the kernel treats Acked-bys as looks
 good.  You did say that.

 I *asked* about what to do with my QEMU CPU patches that only get a
 looks okay and got only positive answers for whether that should be an
 Acked-by and no objection, including none from you.
 I certainly said nothing at all about the kernel.

  At no point did a rule get made though.

 The new rule you made was: no patch without Reviewed-by.

Andreas, I have no idea where you're getting this from.  I think you
misunderstood what was discussed at the QEMU Summit.  Again, there are
no new rules.  I spoke about encouraging more reviews on list because
it's something we need to focus on as a community.

I think you need to step back a bit and give folks the benefit of the
doubt.  No one is doing anything malicious here.

Regards,

Anthony Liguori

 Peter sending that PULL and Edgar merging it both violate that rule.
 No objection against a particular patch function-wise.

 Point is, had Peter ping'ed me before sending out that pull, he would've
 actually gotten a Reviewed-by from me, thereby satisfying your rule! He
 didn't, ignoring that he himself had actually told me to queue the
 patches before his vacation, for which obviously I reviewed and tested them.

 Maybe there's no obligation for picking up tags, but then again you
 can't go ahead and do statistics over incompletely recorded tags.

 Regards,
 Andreas

 I brought up exactly this situation where I am contributor to CPU and
 submaintainer of CPU and often not getting Reviewed-bys but if at all,
 such as from Paolo recently, some verbal looks OK for a series. I was
 told that that should be turned into an Acked-by on the patches to
 satisfy your criteria that contributors may not just send patches as
 pull without Reviewed-by.

 I think you misunderstood.

 I don't care about Acked-bys.  They are useless.

 A third of patches are being committed with Reviewed-bys.  There are
 certainly many cases where patches are going in from submaintainers
 that have been reviewed which comes implicitly with Signed-off-by.

 But I worry that we're not reviewing enough on list and that there are
 patches from maintainers going in through maintainer trees that aren't
 getting outside review.

 There's no immediate action for this other than we should all try to
 review more patches on list to prevent the above situation.

 And adding tags is a nice-to-have.  There is no rule stating that
 you must include everyone that appears on the mailing list.  But I
 expect that maintainers try to

 Again, at QEMU Summit you pushed for making Reviewed-by a must-have and
 we discussed whether a submaintainer must add a Reviewed-by then and
 what to do if author==submaintainer. If you dropped that thought, then
 fine with me.

 Yes, patches should get reviewed.  I hope this is obvious to all of us :-)

 I also suggested that I have tooling that people can use to simplify
 adding collected Reviewed-bys on the list.

 But none of this has anything to do with inferred Acked-bys.  I'll go
 a step further and say that I would be very unhappy if anyone every
 added any kind of tag to a patch with my name on it that I didn't send
 myself.

 Regards,

 Anthony Liguori


 Regards,
 Andreas

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


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

Re: [Qemu-devel] [PULL 0/6] target-arm queue

[Anthony Liguori]

On Thu, Oct 31, 2013 at 6:14 PM, Andreas Färber afaer...@suse.de wrote:
 Am 31.10.2013 16:16, schrieb Peter Maydell:
 On 31 October 2013 14:36, Andreas Färber afaer...@suse.de wrote:
 Am 31.10.2013 15:31, schrieb Peter Maydell:
 On 31 October 2013 14:18, Andreas Färber afaer...@suse.de wrote:
 Peter, since I had picked up the first two patches into my still pending
 qom-next pull, as per the QEMU Summit discussion those patches should've
 gotten an Acked-by.

 Hmm? I don't recall this part of the discussion. If you want the
 patches to have an Acked-by from you you need to send mail
 to the list with an Acked-by line.

 No, I added a Signed-off-by.

 I checked my mail and the only thing I can find in reply to those
 patches is a note from you saying you added them to your queue.

 Right, and as such they got a Signed-off-by, which should've been
 visible in the link I usually add. Here's the pull messages you
 should've been cc'ed on:

 http://patchwork.ozlabs.org/patch/281630/
 http://patchwork.ozlabs.org/patch/281575/

 I don't see why I should reply with a Reviewed-by when I pick up patches
 - again, same discussion as at QEMU Summit.

 It was clearly stated that a Reviewed-by
 needs to be explicitly sent as reply but that looks okay should in
 exactly such a case where sender=submaintainer should be recorded as
 Acked-by, and Sob is certainly stronger than Acked-by. Cf. minutes.

 ...but you're not the submaintainer here so I don't think this applies.

 It does, because you are the patch author and the ARM submaintainer
 sending the pull.

 The point about the kernel practice as I understood it was that
 the kernel folks treat acked-by at about the same level of review as
 looks ok to me (ie, very little), not that there's some obligation to
 treat any informal 'looks ok' note as an acked-by. I'm in full agreement
 with Anthony that if you want a tag to appear you should send it
 properly.

 If Anthony had been and would be more responsive as to why he didn't
 pull the queue containing these patches with two different Sobs, we
 wouldn't be having this conversation in the first place. Or had you not
 gone on vacation or sent another pull before etc. etc.

Your tree is broken.  I gave you the errors that it produced.  You
were able to produce your own errors.  It's your responsibility, as a
subsystem maintainer, to test (and fix) your own tree.

Regards,

Anthony Liguori

 Andreas

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

Re: [Qemu-devel] [PULL v2 00/30] Block patches

[Anthony Liguori]

On Thu, Oct 31, 2013 at 4:48 PM, Kevin Wolf kw...@redhat.com wrote:
 The following changes since commit fc8ead74674b7129e8f31c2595c76658e5622197:

   Merge remote-tracking branch 'qemu-kvm/uq/master' into staging (2013-10-18 
 10:03:24 -0700)

 are available in the git repository at:

make check is failing for me.  It's very consistent.  See below:

  /x86_64/ide/bmdma/setup: OK
  /x86_64/ide/bmdma/simple_rw: OK
  /x86_64/ide/bmdma/short_prdt:OK
  /x86_64/ide/bmdma/long_prdt: OK
  /x86_64/ide/bmdma/no_busmaster:
Broken pipe
FAIL
GTester: last random seed: R02Sc1c266d6688697d47a58af063ff343c5
(pid=720)
  /x86_64/ide/bmdma/teardown:  FAIL
GTester: last random seed: R02S2c481529260b1d513b7a498b45a5b420
(pid=736)
FAIL: tests/ide-test

Regards,

Anthony Liguori


   git://repo.or.cz/qemu/kevin.git tags/for-anthony

 for you to fetch changes up to f4c129a38a5430b7342a7a23f53a22831154612f:

   vmdk: Implment bdrv_get_specific_info (2013-10-31 14:44:43 +0100)

 
 Block patches for 1.7.0-rc0 (v2)

 
 Alexander Graf (1):
   ahci: fix win7 hang on boot

 Eric Blake (1):
   qapi: fix documentation example

 Fam Zheng (4):
   qemu-iotests: drop duplicated create_image
   qemu-iotests: prefill some data to test image
   qapi: Add optional field 'compressed' to ImageInfo
   vmdk: Implment bdrv_get_specific_info

 Kevin Wolf (5):
   exec: Fix bounce buffer allocation in address_space_map()
   ide-test: Check what happens with bus mastering disabled
   tests: Multiboot mmap test case
   block: Avoid unecessary drv-bdrv_getlength() calls
   qemu-iotests: Fix 051 reference output

 Liu Yuan (2):
   sheepdog: explicitly set copies as type uint8_t
   sheepdog: pass copy_policy in the request

 MORITA Kazutaka (8):
   sheepdog: check return values of qemu_co_recv/send correctly
   sheepdog: handle vdi objects in resend_aio_req
   sheepdog: reload inode outside of resend_aioreq
   coroutine: add co_aio_sleep_ns() to allow sleep in block drivers
   sheepdog: try to reconnect to sheepdog after network error
   sheepdog: make add_aio_request and send_aioreq void functions
   sheepdog: cancel aio requests if possible
   sheepdog: check simultaneous create in resend_aioreq

 Max Reitz (6):
   qcow2: Restore total_sectors value in save_vmstate
   qcow2: Unset zero_beyond_eof in save_vmstate
   qemu-iotests: Test for loading VM state from qcow2
   qcow2: Flush image after creation
   block: Don't copy backing file name on error
   qemu-iotests: Test case for backing file deletion

 Peter Lieven (2):
   qemu-img: add special exit code if bdrv_check is not supported
   block/vpc: check that the image has not been truncated

 Thibaut LAURENT (1):
   block: Disable BDRV_O_COPY_ON_READ for the backing file

  block.c |  14 +-
  block/qcow2.c   |  19 +++
  block/raw-posix.c   |   9 +-
  block/raw-win32.c   |   4 +-
  block/raw_bsd.c |   1 +
  block/sheepdog.c| 352 
 
  block/vmdk.c|  68 -
  block/vpc.c |   7 +
  docs/qapi-code-gen.txt  |   2 +-
  exec.c  |   4 +-
  hw/ide/ahci.c   |   3 +-
  include/block/block_int.h   |   3 +
  include/block/coroutine.h   |   9 ++
  qapi-schema.json|  28 +++-
  qemu-coroutine-sleep.c  |  14 ++
  qemu-img.c  |   2 +-
  tests/ide-test.c|  26 
  tests/multiboot/Makefile|  18 +++
  tests/multiboot/libc.c  | 139 +
  tests/multiboot/libc.h  |  61 
  tests/multiboot/link.ld |  19 +++
  tests/multiboot/mmap.c  |  56 +++
  tests/multiboot/mmap.out|  93 
  tests/multiboot/multiboot.h |  66 +
  tests/multiboot/run_test.sh |  81 ++
  tests/multiboot/start.S |  51 +++
  tests/qemu-iotests/030  |   4 +
  tests/qemu-iotests/040  |  14 +-
  tests/qemu-iotests/051.out  |   2 +-
  tests/qemu-iotests/059  |   2 +-
  tests/qemu-iotests/059.out  |   5 +-
  tests/qemu-iotests/068  |  65 
  tests/qemu-iotests/068.out  |  11 ++
  tests/qemu-iotests/069  |  59 
  tests/qemu-iotests/069.out  |   8 +
  tests/qemu-iotests/group|   2 +
  36 files changed, 1157 insertions(+), 164 deletions(-)
  create mode 100644 tests/multiboot/Makefile
  create mode 100644 tests/multiboot/libc.c
  create mode 100644 tests/multiboot/libc.h
  create mode 100644 tests/multiboot/link.ld
  create mode 100644 tests/multiboot/mmap.c
  create mode 100644

Re: [Qemu-devel] [PULL v2 00/56] QOM devices patch queue 2013-10-31

[Anthony Liguori]

On Thu, Oct 31, 2013 at 3:37 PM, Andreas Färber afaer...@suse.de wrote:
 Hello Anthony,

 This is my updated QOM devices patch queue. Please pull or provide more 
 details
 of what is not working in your build environment.

Andreas,

If you cannot be bothered to adequately test your pull requests, then
don't bother sending them.

make check fails spectacularly.  I've confirmed this on multiple
platforms on different distros.

The errors are the exact same as before.  Install some VMs and
reproduce the problem.  I just checked and it fails under 64-bit
Fedora 19.

Regards,

Anthony Liguori

 v2 is rebased, dropping two ARM patches, and the observed SD segfault had been
 fixed in 794cbc26eb94ce13c75d105eea9ff0afff56e2c2.
 Patches are not manually changed, thus intentionally not resent.

 Thanks,
 Andreas

 Cc: Anthony Liguori anth...@codemonkey.ws

 Cc: Peter Maydell peter.mayd...@linaro.org
 Cc: Mian M. Hamayun m.hama...@virtualopensystems.com
 Cc: Paolo Bonzini pbonz...@redhat.com
 Cc: Michael S. Tsirkin m...@redhat.com
 Cc: Stefan Hajnoczi stefa...@redhat.com
 Cc: Edgar E. Iglesias edgar.igles...@gmail.com

 The following changes since commit b86160555f8d1fe11d6bcec393e08e645d7e1e8d:

   integrator: fix Linux boot failure by emulating dbg region (2013-10-31 
 14:00:16 +0100)

 are available in the git repository at:

   git://github.com/afaerber/qemu-cpu.git tags/qom-devices-for-anthony

 for you to fetch changes up to 30a423024ffaa28920c7e36c17855d7bd0061f09:

   pcmcia/pxa2xx: QOM'ify PXA2xxPCMCIAState (2013-10-31 15:12:30 +0100)

 
 QOM device refactorings

 * QTest coverage for all machines
 * QOM realize for Milkymist UART
 * QOM realize for ARM MPCore
 * device_add bug fixes and cleanups
 * QOM API extensions and cleanups
 * QOM for PCMCIA/MicroDrive (last legacy IDE device)

 
 Andreas Färber (49):
   mips_mipssim: Silence BIOS loading warning for qtest
   puv3: Turn puv3_load_kernel() into a no-op for qtest without -kernel
   mainstone: Don't enforce use of -pflash for qtest
   gumstix: Don't enforce use of -pflash for qtest
   z2: Don't enforce use of -pflash for qtest
   palm: Don't enforce loading ROM or kernel for qtest
   omap_sx1: Don't enforce use of kernel or flash for qtest
   exynos4_boards: Silence lack of -smp 2 warning for qtest
   armv7m: Don't enforce use of kernel for qtest
   axis_dev88: Don't enforce use of kernel for qtest
   mcf5208: Don't enforce use of kernel for qtest
   an5206: Don't enforce use of kernel for qtest
   milkymist: Suppress -kernel/-bios/-drive error for qtest
   shix: Drop debug output
   shix: Don't require firmware presence for qtest
   leon3: Don't enforce use of -bios with qtest
   qtest: Prepare QOM machine tests
   a9mpcore: Split off instance_init
   arm_gic: Extract headers hw/intc/arm_gic{,_common}.h
   a9mpcore: Embed GICState
   a9scu: QOM cleanups
   a9mpcore: Embed A9SCUState
   arm_mptimer: Convert to QOM realize
   a9mpcore: Embed ARMMPTimerState
   a9mpcore: Convert to QOM realize
   a9mpcore: Prepare for QOM embedding
   a15mpcore: Split off instance_init
   a15mpcore: Embed GICState
   a15mpcore: Convert to QOM realize
   a15mpcore: Prepare for QOM embedding
   a9scu: Build only once
   arm11mpcore: Fix typo in MemoryRegion name
   arm11mpcore: Drop unused fields
   arm11mpcore: Create container MemoryRegion in instance_init
   arm11mpcore: Split off SCU device
   arm11mpcore: Convert ARM11MPCorePriveState to QOM realize
   realview_gic: Convert to QOM realize
   realview_gic: Prepare for QOM embedding
   arm11mpcore: Convert mpcore_rirq_state to QOM realize
   arm11mpcore: Prepare for QOM embedding
   arm11mpcore: Split off RealView MPCore
   qdev-monitor: Clean up qdev_device_add() variable naming
   qdev-monitor: Avoid qdev as variable name
   qdev-monitor: Inline qdev_init() for device_add
   pxa: Fix typo dettach
   pcmcia: QOM'ify PCMCIACardState and MicroDriveState
   microdrive: Coding Style cleanups
   ide: Drop ide_init2_with_non_qdev_drives()
   pcmcia/pxa2xx: QOM'ify PXA2xxPCMCIAState

 Antony Pavlov (1):
   milkymist-uart: Use Device::realize instead of SysBusDevice::init

 Igor Mammedov (2):
   qdev-monitor: Fix crash when device_add is called with abstract driver
   qom: Include error.h directly in object.h

 Michael S. Tsirkin (2):
   qom: Clean up struct Error references
   qom: Add pointer to int property helpers

 Stefan Hajnoczi (2):
   qdev-monitor: Unref device when device_add fails
   qdev: Drop misleading qdev_free() function

  default-configs/arm-softmmu.mak  |   1 +
  hw/Makefile.objs |   1 +
  hw/acpi/piix4.c

Re: [Qemu-devel] [PATCH 0/17 v2] Localhost migration with side channel for ram

[Anthony Liguori]

On Oct 25, 2013 8:30 AM, Paolo Bonzini pbonz...@redhat.com wrote:

 Il 25/10/2013 06:58, Lei Li ha scritto:
  Right now just has inaccurate numbers without the new vmsplice, which
  based on
  the result from info migrate, as the guest ram size increases, although
the
  'total time' is number of times less compared with the current live
  migration, but the 'downtime' performs badly.

 Of course.
 
  For a 1GB ram guest,
 
  total time: 702 milliseconds
  downtime: 692 milliseconds
 
  And when the ram size of guest increasesexponentially, those numbers are
  proportional to it.
 
  I will make a list of the performance with the new vmsplice later, I am
  sure it'd be much better than this at least.

 Yes, please.  Is the memory usage is still 2x without vmsplice?

 I think you have a nice proof of concept, but on the other hand this
 probably needs to be coupled with some kind of postcopy live migration,
 that is:

 * the source starts sending data

 * but the destination starts running immediately

 * if the machine needs a page that is missing, the destination asks the
 source to send it

 * as soon as it arrives, the destination can restart

 Using postcopy is problematic for reliability: if the destination fails,
 the virtual machine is lost because the source doesn't have the latest
 content of memory.  However, this is a much, much smaller problem for
 live QEMU upgrade where the network cannot fail.

 If you do this, you can achieve pretty much instantaneous live upgrade,
 well within your original 200 ms goals.

This is actually a very nice justification for post copy.

Regards,

Anthony Liguori

But the flipping code with
 vmsplice should be needed anyway to avoid doubling memory usage, and
 it's looking pretty good in this version already!  I'm relieved that the
 RDMA code was designed right!

 Paolo

[Qemu-devel] [REMINDER] Key Signing Party at KVM Forum

[Anthony Liguori]

Hi,

We'll be hosting a key signing party at KVM Forum on Wednesday during
the Hackathon.

More information is at:

http://wiki.qemu.org/KeySigningParty2013

Here is the set of people who have sent me their fingerprints so far:

http://wiki.qemu.org/download/keysigning.txt

If you plan on participating, please make sure you key is in this list
and if it is not, send me the output of gpg --fingerprint for the key
you wish to use.  I may have missed your mail so even if you sent me
something, please check again.

Make sure you bring proper ID too.  Passports are the best form of ID.

Please note that the key server on the wiki is currently down so
please ignore that part of the howto.

Regards,

Anthony Liguori

Re: [Qemu-devel] [REMINDER] Key Signing Party at KVM Forum

[Anthony Liguori]

You must bring a physical copy of your own key fingerprint.  I will
not allow folks to use their laptops during the key signing.

There are pens and pads of paper in the conference rooms.  If you
don't already have a print out, write your fingerprint on a piece of
paper before tomorrow and bring that with you.

Do not trust that I have reproduced your key accurately.

Regards,

Anthony Liguori

On Tue, Oct 22, 2013 at 10:56 AM, Anthony Liguori anth...@codemonkey.ws wrote:
 Hi,

 We'll be hosting a key signing party at KVM Forum on Wednesday during
 the Hackathon.

 More information is at:

 http://wiki.qemu.org/KeySigningParty2013

 Here is the set of people who have sent me their fingerprints so far:

 http://wiki.qemu.org/download/keysigning.txt

 If you plan on participating, please make sure you key is in this list
 and if it is not, send me the output of gpg --fingerprint for the key
 you wish to use.  I may have missed your mail so even if you sent me
 something, please check again.

 Make sure you bring proper ID too.  Passports are the best form of ID.

 Please note that the key server on the wiki is currently down so
 please ignore that part of the howto.

 Regards,

 Anthony Liguori

Re: [Qemu-devel] [PATCH for-1.7] seccomp: setting -sandbox on by default

[Anthony Liguori]

On Tue, Oct 22, 2013 at 12:21 PM, Eduardo Otubo
ot...@linux.vnet.ibm.com wrote:
 Inverting the way sandbox handles arguments, making possible to have no
 argument and still have '-sandbox on' enabled.

 Signed-off-by: Eduardo Otubo ot...@linux.vnet.ibm.com
 ---

 The option '-sandbox on' is now used by default by virt-test[0] -- it has been
 merged into the 'next' branch and will be available in the next release,
 meaning we have a back support for regression tests if anything breaks because
 of some missing system call not listed in the whitelist.

 This being said, I think it makes sense to have this option set to 'on' by
 default in the next Qemu version. It's been a while since no missing syscall 
 is
 reported and at this point the whitelist seems to be pretty mature.

 [0] - 
 https://github.com/autotest/virt-test/commit/50e1f7d47a94f4c770880cd8ec0f18365dcba714

This breaks hot_add of a network device that uses a script= argument, correct?

If so, this cannot be made default.

Regards,

Anthony Liguori


  qemu-options.hx |  4 ++--
  vl.c| 47 ---
  2 files changed, 30 insertions(+), 21 deletions(-)

 diff --git a/qemu-options.hx b/qemu-options.hx
 index 5dc8b75..315a86d 100644
 --- a/qemu-options.hx
 +++ b/qemu-options.hx
 @@ -2982,13 +2982,13 @@ Old param mode (ARM only).
  ETEXI

  DEF(sandbox, HAS_ARG, QEMU_OPTION_sandbox, \
 --sandbox arg  Enable seccomp mode 2 system call filter (default 
 'off').\n,
 +-sandbox arg  Enable seccomp mode 2 system call filter (default 
 'on').\n,
  QEMU_ARCH_ALL)
  STEXI
  @item -sandbox @var{arg}
  @findex -sandbox
  Enable Seccomp mode 2 system call filter. 'on' will enable syscall filtering 
 and 'off' will
 -disable it.  The default is 'off'.
 +disable it.  The default is 'on'.
  ETEXI

  DEF(readconfig, HAS_ARG, QEMU_OPTION_readconfig,
 diff --git a/vl.c b/vl.c
 index b42ac67..ae3bdc9 100644
 --- a/vl.c
 +++ b/vl.c
 @@ -529,6 +529,20 @@ static QemuOptsList qemu_msg_opts = {
  },
  };

 +static QemuOpts *qemu_get_sandbox_opts(void)
 +{
 +QemuOptsList *list;
 +QemuOpts *opts;
 +
 +list = qemu_find_opts(sandbox);
 +assert(list);
 +opts = qemu_opts_find(list, NULL);
 +if (!opts) {
 +opts = qemu_opts_create_nofail(list);
 +}
 +return opts;
 +}
 +
  /**
   * Get machine options
   *
 @@ -960,24 +974,9 @@ static int bt_parse(const char *opt)
  return 1;
  }

 -static int parse_sandbox(QemuOpts *opts, void *opaque)
 +static bool sandbox_enabled(bool default_usb)
  {
 -/* FIXME: change this to true for 1.3 */
 -if (qemu_opt_get_bool(opts, enable, false)) {
 -#ifdef CONFIG_SECCOMP
 -if (seccomp_start()  0) {
 -qerror_report(ERROR_CLASS_GENERIC_ERROR,
 -  failed to install seccomp syscall filter in the 
 kernel);
 -return -1;
 -}
 -#else
 -qerror_report(ERROR_CLASS_GENERIC_ERROR,
 -  sandboxing request but seccomp is not compiled into 
 this build);
 -return -1;
 -#endif
 -}
 -
 -return 0;
 +return qemu_opt_get_bool(qemu_get_sandbox_opts(), sandbox, 
 default_usb);
  }

  bool usb_enabled(bool default_usb)
 @@ -3806,8 +3805,18 @@ int main(int argc, char **argv, char **envp)
  exit(1);
  }

 -if (qemu_opts_foreach(qemu_find_opts(sandbox), parse_sandbox, NULL, 
 0)) {
 -exit(1);
 +if (sandbox_enabled(true)) {
 +#ifdef CONFIG_SECCOMP
 +if (seccomp_start()  0) {
 +qerror_report(ERROR_CLASS_GENERIC_ERROR,
 +  failed to install seccomp syscall filter in the 
 kernel);
 +return -1;
 +}
 +#else
 +qerror_report(ERROR_CLASS_GENERIC_ERROR,
 +  sandboxing request but seccomp is not compiled into 
 this build);
 +return -1;
 +#endif
  }

  #ifndef _WIN32
 --
 1.8.3.1

Re: [Qemu-devel] [PATCH] MAINTAINERS: add block driver sub-maintainers

[Anthony Liguori]

On Mon, Oct 21, 2013 at 2:26 PM, Stefan Hajnoczi stefa...@redhat.com wrote:
 There are a number of contributors who maintain block drivers (image
 formats and protocols).  They should be listed in the MAINTAINERS file
 so that get_maintainer.pl lists them.

 Note that commits are still merged through Kevin or Stefan's block tree
 but the block driver sub-maintainers are usually the ones to review
 patches.

 Acked-by: Kevin Wolf kw...@redhat.com
 Signed-off-by: Stefan Hajnoczi stefa...@redhat.com

Acked-by: Anthony Liguori aligu...@amazon.com

Although you certainly don't need it.  I assume everything is still
going to flow through the block tree or are you guys looking for these
folks to submit their own pull requests to me?

Regards,

Anthony Liguori

 ---
  MAINTAINERS | 38 ++
  1 file changed, 38 insertions(+)

 diff --git a/MAINTAINERS b/MAINTAINERS
 index 77edacf..da18a23 100644
 --- a/MAINTAINERS
 +++ b/MAINTAINERS
 @@ -857,3 +857,41 @@ Stable 0.10
  L: qemu-sta...@nongnu.org
  T: git git://git.qemu-project.org/qemu-stable-0.10.git
  S: Orphan
 +
 +Block drivers
 +-
 +VMDK
 +M: Fam Zheng f...@redhat.com
 +S: Supported
 +F: block/vmdk.c
 +
 +RBD
 +M: Josh Durgin josh.dur...@dreamhost.com
 +S: Supported
 +F: block/rbd.c
 +
 +Sheepdog
 +M: MORITA Kazutaka morita.kazut...@lab.ntt.co.jp
 +S: Supported
 +F: block/sheepdog.c
 +
 +VHDX
 +M: Jeff Cody jc...@redhat.com
 +S: Supported
 +F: block/vhdx.c
 +
 +VDI
 +M: Stefan Weil s...@weilnetz.de
 +S: Maintained
 +F: block/vdi.c
 +
 +iSCSI
 +M: Ronnie Sahlberg ronniesahlb...@gmail.com
 +M: Paolo Bonzini pbonz...@redhat.com
 +S: Supported
 +F: block/iscsi.c
 +
 +SSH
 +M: Richard W.M. Jones rjo...@redhat.com
 +S: Supported
 +F: block/ssh.c
 --
 1.8.3.1

Re: [Qemu-devel] [PATCH 2/2] acpi-test: basic acpi unit-test

[Anthony Liguori]

On Fri, Oct 18, 2013 at 5:13 PM, Andreas Färber afaer...@suse.de wrote:
 Am 17.10.2013 23:52, schrieb Michael S. Tsirkin:
 diff --git a/tests/acpi-test.c b/tests/acpi-test.c
 new file mode 100644
 index 000..42de248
 --- /dev/null
 +++ b/tests/acpi-test.c
 [...]
 +static void test_acpi_one(const char *params)
 +{
 +char *args;
 +uint8_t signature_low;
 +uint8_t signature_high;
 +uint16_t signature;
 +int i;
 +uint32_t off;
 +
 +
 +args = g_strdup_printf(-net none -display none %s %s,
 +   params ? params : , disk);
 +qtest_start(args);
 +
 +   /* Wait at most 1 minute */
 +#define TEST_DELAY (1 * G_USEC_PER_SEC / 10)
 +#define TEST_CYCLES (60 * G_USEC_PER_SEC / TEST_DELAY)
 +
 +for (i = 0; i  TEST_CYCLES; ++i) {
 +signature_low = readb(BOOT_SECTOR_ADDRESS + SIGNATURE_OFFSET);
 +signature_high = readb(BOOT_SECTOR_ADDRESS + SIGNATURE_OFFSET + 1);
 +signature = (signature_high  8) | signature_low;
 +if (signature == SIGNATURE) {
 +break;
 +}
 +g_usleep(TEST_DELAY);
 +}
 +g_assert_cmphex(signature, ==, SIGNATURE);

 Might be a good safety precaution to use QEMU_BUG_ON() or MIN(..., 1)
 for TEST_CYCLES to assure signature gets initialized before comparison.

 +
 +/* OK, now find RSDP */
 +for (off = 0xf; off  0x10; off += 0x10)
 +{
 +uint8_t sig[] = RSD PTR ;
 +int i;
 +
 +for (i = 0; i  sizeof sig - 1; ++i) {
 +sig[i] = readb(off + i);
 +}
 +
 +if (!memcmp(sig, RSD PTR , sizeof sig)) {
 +break;
 +}
 +}
 +
 +g_assert_cmphex(off, , 0x10);
 +
 +qtest_quit(global_qtest);
 +g_free(args);
 +}
 +
 +static void test_acpi_tcg(void)
 +{
 +test_acpi_one(-machine accel=tcg);
 +}
 +
 +static void test_acpi_kvm(void)
 +{
 +test_acpi_one(-enable-kvm -machine accel=kvm);
 +}
 +
 +int main(int argc, char *argv[])
 +{
 +const char *arch = qtest_get_arch();
 +FILE *f = fopen(disk, w);
 +fwrite(boot_sector, 1, sizeof boot_sector, f);
 +fclose(f);
 +
 +g_test_init(argc, argv, NULL);
 +
 +if (strcmp(arch, i386) == 0 || strcmp(arch, x86_64) == 0) {
 +qtest_add_func(acpi/tcg, test_acpi_tcg);
 +qtest_add_func(acpi/kvm, test_acpi_kvm);

 Sorry, while the intention is good, this is a no-go. Not only will make
 check fail on KVM-incompatible x86 hosts (including insufficient
 permissions for /dev/kvm), it will also fail on ppc or arm hosts since
 we are testing the target architecture here.

I think it would be possible to call query-kvm and dynamically add the
test when it's possible.

Regards,

Anthony Liguori


 Regards,
 Andreas

 +}
 +return g_test_run();
 +}
 [snip]

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

Re: [Qemu-devel] [PULL 42/43] piix4: add acpi pci hotplug support

[Anthony Liguori]

On Tue, Oct 15, 2013 at 1:17 PM, Michael S. Tsirkin m...@redhat.com wrote:
 On Tue, Oct 15, 2013 at 09:27:33AM -0700, Anthony Liguori wrote:
 Paolo Bonzini pbonz...@redhat.com writes:

  Il 15/10/2013 16:35, Michael S. Tsirkin ha scritto:
  On Tue, Oct 15, 2013 at 04:31:31PM +0200, Paolo Bonzini wrote:
  Il 14/10/2013 17:01, Michael S. Tsirkin ha scritto:
  -VMSTATE_STRUCT(pci0_status, PIIX4PMState, 2, 
  vmstate_pci_status,
  -   struct pci_status),
  +VMSTATE_STRUCT_TEST(pci0_status, PIIX4PMState,
  +vmstate_test_no_use_acpi_pci_hotplug,
  +2, vmstate_pci_status,
  +struct pci_status),
 
  There's no reason to remove this from the stream when a new machine type
  is in use.  You'll just send out zeroes.
 
  Seemed cleaner not to.
 
  It certainly would be if we had a self-descriptive migration stream
  format.

 Yes, removing tests is always a good thing.

 But I think subsections should always be used when they can.  We should
 not break compatibility (even if we technical don't guarantee it) unless
 we absolutely have to.

 Regards,

 Anthony Liguori

 OK so I can interpret this in 2 ways wrt bridge hotplug:
 - it's in shape for 1.7 except the migration which should use
   subsections (and needs cross-version testing)
 - it's not in shape for 1.7

 Can you tell me which it is please?

The code is not in shape.  Forget about the existence of 1.7.  Focus
on getting the code right and it will make whatever release it is
ready for.  If that's 1.7, great, but the fact that 1.7 is around the
corner does not mean we're going to merge something that isn't ready
just so it makes the release.

Migration is one issue.  As I said before, testing is another.  There
really should be some test automation for this.

Regards,

Anthony Liguori

 If it's 1 I'll repost a version with tweaked
 migration format and cross-version testing report, tomorrow.

 If it's 2 I'd rather work on this after the forum, I still
 need to make some travel arrangements.

 Paolo? Anthony?

 --
 MST

Re: [Qemu-devel] Which functions of southbridges should be no-user?

[Anthony Liguori]

On Wed, Oct 16, 2013 at 3:00 AM, Markus Armbruster arm...@redhat.com wrote:
 Anthony Liguori anth...@codemonkey.ws writes:

 On Tue, Oct 15, 2013 at 7:41 AM, Kevin Wolf kw...@redhat.com wrote:
 Am 15.10.2013 um 15:31 hat Andreas Färber geschrieben:
 Am 15.10.2013 15:21, schrieb Markus Armbruster:
  Andreas,
 
  To go beyond RFC with this series, I need to explain why the IDE
  controller functions of southbridges piix3-ide, piix3-ide-xen, piix4-ide
  and via-ide cannot_instantiate_with_device_add_yet, or drop that.  I'd
  appreciate your help.
 
  Our modelling of PCI devices is weird, to put it politely.  One of many
  weird things is that we don't distinguish between a function and a
  complete device: our function models are actually PCI device models,
  and can be used as such, even though they only exist as functions of a
  multifunction device in the real world.  We permit collecting aribitrary
  PCI devices into multifunction devices.
 
  One instance of multifunction PCI devices are southbridges.  For
  example, the ICH9 southbridge's PCI device 00:1F consists of ISA bridge
  (ICH9 LPC), IDE controller (ich9-ahci), SMB controller (ICH9 SMB),
  and Thermal Subsystem (which we don't implement).  The PIIX3 southbridge
  consists of ISA bridge (PIIX3, IDE controller (piix3-ide), USB
  controller (piix3-usb-uhci, can be suppressed), and SMB controller
  (PIIX4_PM, can be suppressed).
 
  Some functions of southbridges still need to be wired up in code (ICH9
  LPC, ICH9 SMB, PIIX4_PM, PIIX4, PIIX3, PIIX3-xen, see PATCH
  5-6/9), thus cannot_instantiate_with_device_add_yet.
 
  The IDE controller functions have always been
  cannot_instantiate_with_device_add_yet, but it's not obvious to me why.
 
  The other functions are available with device-add.  Users device-add'ing
  them would of course be odd, but if it works...  I don't actually know
  whether it works for all of them.
 
  Should all southbridge functions be made unavailable with device-add for
  consistency, at least for now?
 
  Or should all functions be made available, except for the ones that
  cannot possibly work with device-add?
 
  If the latter, can you think of any specific reason why the IDE
  controllers couldn't work?

 I would've thought you and Kevin know more about IDE than me. ;)
 No idea why it is how it is.

 Two aspects:
 1) PCI devices/functions can technically be hotplugged.
 2) Drivers might not expect such devices to be hot-added/removed.

 I would tend for the latter proposal.

 I'm not sure how IDE hardware really works, but I don't think you can
 handle it as a pure PCI device. On PCs, the IDE controller still provides
 the good old IDE registers on the I/O ports that were already used in
 ISA times, and they are not described in any BARs, for example.

 Legacy IDE and VGA accesses are positively decoded in the i440fx and
 dispatched to the first PCI device with the appropriate class code.

 From a
 software point of view, the PCI device is just for configuring Busmaster
 DMA. Perhaps in reality it should be two devices, one for DMA on the PCI
 bus and another one for the core on sysbus or ISA?

 It's definitely all a PCI device.  It could realistically be a
 discrete device too that's plugged into a PCI bus that lacks a super
 I/O chipset.


 Anyway, having two IDE controllers using the same I/O ports won't work,
 obviously. So if you would allow -device or device-add for them, you'd
 need options to configure the ports at least.

 It's allowed but the PCI bus will only route the legacy requests to one of 
 them.

 Any objections to dropping cannot_instantiate_with_device_add_yet from
 all IDE controller southbridge functions?  These are: piix3-ide,
 piix3-ide-xen, piix4-ide and via-ide.

No, I don't object.  As Andreas points out, we may have problems today
if you try to add two IDE controllers but those are bugs that should
be fixed.

It used to be possible to buy secondary PCI IDE controllers to add
more than 4 disks.  You could only access them with proper drivers (so
you couldn't boot from the 5th disk) but otherwise it worked.

Regards,

Anthony Liguori

Re: [Qemu-devel] [PULL 42/43] piix4: add acpi pci hotplug support

[Anthony Liguori]

On Wed, Oct 16, 2013 at 11:18 AM, Michael S. Tsirkin m...@redhat.com wrote:
 On Wed, Oct 16, 2013 at 09:38:29AM -0700, Anthony Liguori wrote:
 On Tue, Oct 15, 2013 at 1:17 PM, Michael S. Tsirkin m...@redhat.com wrote:
  On Tue, Oct 15, 2013 at 09:27:33AM -0700, Anthony Liguori wrote:
  Paolo Bonzini pbonz...@redhat.com writes:
 
   Il 15/10/2013 16:35, Michael S. Tsirkin ha scritto:
   On Tue, Oct 15, 2013 at 04:31:31PM +0200, Paolo Bonzini wrote:
   Il 14/10/2013 17:01, Michael S. Tsirkin ha scritto:
   -VMSTATE_STRUCT(pci0_status, PIIX4PMState, 2, 
   vmstate_pci_status,
   -   struct pci_status),
   +VMSTATE_STRUCT_TEST(pci0_status, PIIX4PMState,
   +vmstate_test_no_use_acpi_pci_hotplug,
   +2, vmstate_pci_status,
   +struct pci_status),
  
   There's no reason to remove this from the stream when a new machine 
   type
   is in use.  You'll just send out zeroes.
  
   Seemed cleaner not to.
  
   It certainly would be if we had a self-descriptive migration stream
   format.
 
  Yes, removing tests is always a good thing.
 
  But I think subsections should always be used when they can.  We should
  not break compatibility (even if we technical don't guarantee it) unless
  we absolutely have to.
 
  Regards,
 
  Anthony Liguori
 
  OK so I can interpret this in 2 ways wrt bridge hotplug:
  - it's in shape for 1.7 except the migration which should use
subsections (and needs cross-version testing)
  - it's not in shape for 1.7
 
  Can you tell me which it is please?

 The code is not in shape.  Forget about the existence of 1.7.  Focus
 on getting the code right and it will make whatever release it is
 ready for.  If that's 1.7, great, but the fact that 1.7 is around the
 corner does not mean we're going to merge something that isn't ready
 just so it makes the release.

 OK. Apropos 1.7, how about moving soft freeze and the release out
 by a couple of weeks?

No.

There is always some reason to delay releases.  We have a release
every quarter.  It's not a big deal to just wait for a feature for the
next release.  That's the whole point of doing frequent releases.

 What with you moving over and the kvm forum, people
 didn't have time to focus on it properly IMO.
 In particular it's harder than usual to get reviews.

 Migration is one issue.

 Right but what's special about this feature?
 Almost anything we do affects migration in some way.

There is nothing special and the feedback you are getting is no
different than any other series.


 As I said before, testing is another.  There
 really should be some test automation for this.

 Regards,

 Anthony Liguori

 I'm not sure I understand what you are saying here.

 If you just want testing hotplug, automation is there.

Unit level testing.  IOW, something that gets run during 'make check'
to verify that we're generating proper ACPI tables.

Regards,

Anthony Liguori

 Automated testing for cross-version migration? that's not easy since you
 need two versions around. I'll talk to autotest guys but don't hold your
 breath.  But a bigger issue is that migration and hotplug don't work
 well together in qemu ATM.

 --
 MST

Re: [Qemu-devel] [PULL 42/43] piix4: add acpi pci hotplug support

[Anthony Liguori]

On Wed, Oct 16, 2013 at 3:25 PM, Paolo Bonzini pbonz...@redhat.com wrote:
 Il 17/10/2013 00:03, Michael S. Tsirkin ha scritto:
 On Wed, Oct 16, 2013 at 11:26:11PM +0200, Paolo Bonzini wrote:
 Il 16/10/2013 20:37, Michael S. Tsirkin ha scritto:
 Gleb, Paolo, what do you think? OK to merge kvm unit test
 into qemu? It depends on qemu anyway, in-tree will make it easier.
 Maybe someone's looking at this already?

 I think merging KVM unit tests doesn't make much sense because, with
 some small exceptions, it is mostly a test or a benchmark for KVM.

 But why keep them separate? They need qemu to work, don't they?

 Not necessarily.  They need a userspace component of course, but most of
 them do not need something as big as QEMU.  Most tests, perhaps all,
 only write to a handful of ports and use no BIOS services.

 What
 may make sense is to have a quick way to run autotest on a QEMU tree,
 with a subset of testcases that doesn't take too much time (let's say 4
 hours)

 That's not really reasonable for make check though.

 Why not?  When I was working on GCC I usually ran a subset of the
 testsuite manually and then did a full run overnight.  I said 4 hours
 because it lets you do 2 runs (baseline and patched) while you sleep.

 However I agree it's more than we're used to, so I'd not put it under
 make check.  Still, having it available from make would be nice.

 and is more or less guaranteed to pass.

 That's still the main challenge.

 Yep. :(

 qtest could at best host some sanity checks on the ACPI tables, which
 would catch the MCFG problems that Gerd reported on v5.

 Depends on how deep the test understands ACPI - the signature
 was wrong I think.

 Note I was testing this too - comparing tables between
 revisions. I just didn't notice that list of tables
 to test included was generated by me on piix, so
 MCFG wasn't tested.

 So we could have a qtest for sanity checking ACPI tables.  At least
 fw_cfg is one of the few components that has qtest infrastructure...  I
 don't think we need to do more than that though.  The set of sanity
 checks can start with a simple list of tables that have to be there
 for a given machine type.

I think we could reasonably attempt to validate ACPI tables across
machine versions.

Since this is qtest, we can even do things like use iasl to
disassemble the blobs on the host.  This could be pretty handy for
detecting compatibility issues across machine versions.

Regards,

Anthony Liguori


 Paolo

Re: [Qemu-devel] [PULL 00/43] pci, pc, acpi fixes, enhancements

[Anthony Liguori]

On Mon, Oct 14, 2013 at 10:28 PM, Michael S. Tsirkin m...@redhat.com wrote:
 On Mon, Oct 14, 2013 at 03:42:37PM -0700, Anthony Liguori wrote:
 Michael S. Tsirkin m...@redhat.com writes:

  Anthony, I know you wanted to review some of the patches,
  since you didn't respond either all's well or you
  could not find the time.
  I think we are better off merging them for 1.7 and then - worst case,
  if major issues surface - disabling the functionality at the last minute
  than delaying the merge even more.

 There is no way I'll pull this for 1.7.  Changes like this aren't going
 to get merged at the last minute.

 Last minute?  This has been on list for months.

It doesn't matter how long the patches have been on the list.  We have
a very short testing cycle for releases.

This pull request lacks any automated testing.  Something like this
really should come with at least some qtest validation that we are
still generating the right ACPI tables but certainly could have
simpler unit tests too.

There is no statement about what manual testing you actually did.
Have you run kvm autotest?  Have you tested a variety of Windows
guests?

The pull request has a patch with a binary diff and a comment of:

update generated file, not sure what changed

And that didn't concern you prior to sending the pull request?

This series is not ready to merge.

  A good chunk of the series lacks
 any Reviewed-bys including the actual hotplug behind a pci bridge bits
 which is the whole point of the series.

 It isn't. The point is getting ACPI out of seabios.
 OK what if I drop the bridge hotplug part?

How does that address the above?

 This is a huge series and I still am not convinced this is the right
 path forward.  The alternative to this series is a small set of changes
 to SeaBIOS to support PCI bridge hotplug, no?

 No, we also get alternative firmwares working correctly with QEMU.

 Or 10k SLOC of code into QEMU that includes breaking migration
 compatibility.

 AFAIK it doesn't break migration compatibility.

From 41/43:

The interface is actually backwards-compatible with
 existing PIIX4 ACPI (though not migration compatible).

And does AFAIK translate to, I have tested migration from new and
old and old and new with this series?  I suspect the answer is no.

Regards,

Anthony Liguori

 Regards,

 Anthony Liguori

  The following changes since commit 
  e26d3e734650640fabd7d95ace4f3a6f88725e0b:
 
smbios: Factor out smbios_maybe_add_str() (2013-09-28 23:49:39 +0300)
 
  are available in the git repository at:
 
git://git.kernel.org/pub/scm/virt/kvm/mst/qemu.git tags/for_anthony
 
  for you to fetch changes up to 6cab1e721fa6a487f67e1dba986f68fee30d:
 
acpi-build: enable hotplug for PCI bridges (2013-10-14 17:48:58 +0300)
 
  
  pci, pc, acpi fixes, enhancements
 
  This includes some pretty big changes:
  - pci master abort support by Marcel
  - pci IRQ API rework by Marcel
  - acpi generation and pci bridge hotplug support by myself
 
  Everything has gone through several revisions, latest versions have been on
  list for a while without any more comments, tested by several
  people.
 
  Please pull for 1.7.
 
  Signed-off-by: Michael S. Tsirkin m...@redhat.com
 
  
  Igor Mammedov (1):
cleanup object.h: include error.h directly
 
  Marcel Apfelbaum (11):
memory: Change MemoryRegion priorities from unsigned to signed
docs/memory: Explictly state that MemoryRegion priority is signed
hw/pci: partially handle pci master abort
hw/core: Add interface to allocate and free a single IRQ
hw/pci: add pci wrappers for allocating and asserting irqs
hw/pci-bridge: set PCI_INTERRUPT_PIN register before shpc init
hw/vmxnet3: set interrupts using pci irq wrappers
hw/vfio: set interrupts using pci irq wrappers
hw: set interrupts using pci irq wrappers
hw/pcie: AER and hot-plug events must use device's interrupt
hw/pci: removed irq field from PCIDevice
 
  Michael S. Tsirkin (31):
qom: cleanup struct Error references
qom: add pointer to int property helpers
pci: fix up w64 size calculation helper
fw_cfg: interface to trigger callback on read
loader: support for unmapped ROM blobs
pcie_host: expose UNMAPPED macro
pcie_host: expose address format
q35: use macro for MCFG property name
q35: expose mmcfg size as a property
i386: add ACPI table files from seabios
acpi: add rules to compile ASL source
acpi: pre-compiled ASL files
acpi: ssdt pcihp: updat generated file
loader: use file path size from fw_cfg.h
i386: add bios linker/loader
loader: allow adding ROMs in done callbacks
i386: define pc guest info
acpi/piix: add macros for acpi property names
piix

Re: [Qemu-devel] [PULL 00/43] pci, pc, acpi fixes, enhancements

[Anthony Liguori]

On Tue, Oct 15, 2013 at 6:43 AM, Gerd Hoffmann kra...@redhat.com wrote:
 On Mo, 2013-10-14 at 15:42 -0700, Anthony Liguori wrote:
 Michael S. Tsirkin m...@redhat.com writes:

  Anthony, I know you wanted to review some of the patches,
  since you didn't respond either all's well or you
  could not find the time.
  I think we are better off merging them for 1.7 and then - worst case,
  if major issues surface - disabling the functionality at the last minute
  than delaying the merge even more.

 There is no way I'll pull this for 1.7.  Changes like this aren't going
 to get merged at the last minute.

 Hmm?  Patches are discussed and tested for months, with the core not
 having seen no big changes since weeks.  Recent revisions of the series
 are only fixing the bugs which showed up in testing and some finishing
 touches.  It certainly isn't something new poping out of the blue the
 last minute.

 Why do you ignore the patches and discussions until things are settled
 and the pull request comes in?

Sorry, I shouldn't mix in general complaining with why I am not happy
with this pull request.  I already said I would take this change given
a clear use-case and I would have merged it if the series was in a
better state.  I am sympathetic to not wanting to maintain this stuff
in SeaBIOS.

But I am not happy with the state of the pull request for reasons I
explained in another note.

Regards,

Anthony Liguori


 A good chunk of the series lacks
 any Reviewed-bys including the actual hotplug behind a pci bridge bits
 which is the whole point of the series.

 pci bridge hotplug is only a part of the whole picture.

 It is about using an existing standard (ACPI) to communicate hardware
 config information between qemu and the guest OS.  Without requiring the
 middle man (seabios or other firmware) knowing details it doesn't need
 to know for its own job.  And avoid creating one paravirtual interface
 after the other to give the firmware the information it needs to
 generate the acpi tables.

 It is also about having *one* instance (qemu) generates the acpi tables
 instead of expecting each firmware duplicate that functionality.  It
 makes live a lot easier for alternative firmwares such as ovmf and
 coreboot.  For coreboot the patch series (with the complementary
 coreboot patches to load the tables from qemu) is a big step forward to
 feature parity with seabios.

 And, yes, implementing features like pci bridge hotplug and memory
 hotplug (oh, and lets not forget pvpanic) on top of the acpi generation
 series is alot easier:

  * You implement it in qemu, and you are done.

 This is a huge series and I still am not convinced this is the right
 path forward.  The alternative to this series is a small set of changes
 to SeaBIOS to support PCI bridge hotplug, no?

 No.  The alternative is:

  * You create a paravirt interface to communicate the
config information for $newfeature.
  * You implement that in qemu.
  * You implement that in seabios.
  * You implement that in OVMF.
  * You implement that in coreboot.

 Or 10k SLOC of code into QEMU that includes breaking migration
 compatibility.

 On the plus side we can stop maintaining those 10k SLOC in seabios.

 The bits will stay there for a while for compatibility with older qemu
 versions, but don't need much care any more as all new stuff will go
 into qemu instead.

 cheers,
   Gerd

Re: [Qemu-devel] [PULL 00/43] pci, pc, acpi fixes, enhancements

[Anthony Liguori]

On Tue, Oct 15, 2013 at 7:01 AM, Paolo Bonzini pbonz...@redhat.com wrote:
 Il 15/10/2013 15:51, Anthony Liguori ha scritto:
 From 41/43:

 The interface is actually backwards-compatible with
  existing PIIX4 ACPI (though not migration compatible).

 And does AFAIK translate to, I have tested migration from new and
 old and old and new with this series?  I suspect the answer is no.

 Since when do we support migration from new to old?

We allow it to break because we only send the newest version of things
but we should try our best to avoid that from happening.  That's why
we have things like subsections.

Regards,

Anthony Liguori

 Paolo

Re: [Qemu-devel] [PULL 00/43] pci, pc, acpi fixes, enhancements

[Anthony Liguori]

On Tue, Oct 15, 2013 at 7:20 AM, Michael S. Tsirkin m...@redhat.com wrote:
 On Tue, Oct 15, 2013 at 06:51:30AM -0700, Anthony Liguori wrote:
 On Mon, Oct 14, 2013 at 10:28 PM, Michael S. Tsirkin m...@redhat.com wrote:
  On Mon, Oct 14, 2013 at 03:42:37PM -0700, Anthony Liguori wrote:
  Michael S. Tsirkin m...@redhat.com writes:
 
   Anthony, I know you wanted to review some of the patches,
   since you didn't respond either all's well or you
   could not find the time.
   I think we are better off merging them for 1.7 and then - worst case,
   if major issues surface - disabling the functionality at the last minute
   than delaying the merge even more.
 
  There is no way I'll pull this for 1.7.  Changes like this aren't going
  to get merged at the last minute.
 
  Last minute?  This has been on list for months.

 It doesn't matter how long the patches have been on the list.  We have
 a very short testing cycle for releases.

 This pull request lacks any automated testing.  Something like this
 really should come with at least some qtest validation that we are
 still generating the right ACPI tables but certainly could have
 simpler unit tests too.

 It did go through autotest testing though.

This specific tree or some previous version of the series?  A full run
or just a restricted run?

 There is no statement about what manual testing you actually did.

 Manually I loaded tables and verified that they match
 the bios bit for bit except pointer values.

 Have you run kvm autotest?  Have you tested a variety of Windows
 guests?

 Yes, both.

 The pull request has a patch with a binary diff and a comment of:

 update generated file, not sure what changed

 And that didn't concern you prior to sending the pull request?


 Sorry, I forgot to update the description. V2 has it right:
 IASL sticks its own version when it builds tables,
 this is what changed.

 This series is not ready to merge.

 Because a single commit message was out of date?

   A good chunk of the series lacks
  any Reviewed-bys including the actual hotplug behind a pci bridge bits
  which is the whole point of the series.
 
  It isn't. The point is getting ACPI out of seabios.
  OK what if I drop the bridge hotplug part?

 How does that address the above?

 It addresses the issues you have raised which was with
 the bridge.

  This is a huge series and I still am not convinced this is the right
  path forward.  The alternative to this series is a small set of changes
  to SeaBIOS to support PCI bridge hotplug, no?
 
  No, we also get alternative firmwares working correctly with QEMU.
 
  Or 10k SLOC of code into QEMU that includes breaking migration
  compatibility.
 
  AFAIK it doesn't break migration compatibility.

 From 41/43:

 The interface is actually backwards-compatible with
  existing PIIX4 ACPI (though not migration compatible).

 And does AFAIK translate to, I have tested migration from new and
 old and old and new with this series?  I suspect the answer is no.

 Regards,

 Anthony Liguori

 But the code to handle it is there, at least.
 I will test it but I think minor fixes like this can go
 in after soft freeze.

I cannot reasonable revert a series like this before we cut GA.  We
would have to delay the release until everything was fixed.   The
release is a month away and most of us will lose at least a week to
KVM Forum so our ducks need to be in a row here.

Please put together a summary of the testing this series has gone
through.  I still think there should be automated testing as part of
this but if the manual testing is sufficiently thorough I'll
reconsider for 1.7.

Regards,

Anthony Liguori


 --
 MST

Re: [Qemu-devel] Which functions of southbridges should be no-user?

[Anthony Liguori]

On Tue, Oct 15, 2013 at 7:41 AM, Kevin Wolf kw...@redhat.com wrote:
 Am 15.10.2013 um 15:31 hat Andreas Färber geschrieben:
 Am 15.10.2013 15:21, schrieb Markus Armbruster:
  Andreas,
 
  To go beyond RFC with this series, I need to explain why the IDE
  controller functions of southbridges piix3-ide, piix3-ide-xen, piix4-ide
  and via-ide cannot_instantiate_with_device_add_yet, or drop that.  I'd
  appreciate your help.
 
  Our modelling of PCI devices is weird, to put it politely.  One of many
  weird things is that we don't distinguish between a function and a
  complete device: our function models are actually PCI device models,
  and can be used as such, even though they only exist as functions of a
  multifunction device in the real world.  We permit collecting aribitrary
  PCI devices into multifunction devices.
 
  One instance of multifunction PCI devices are southbridges.  For
  example, the ICH9 southbridge's PCI device 00:1F consists of ISA bridge
  (ICH9 LPC), IDE controller (ich9-ahci), SMB controller (ICH9 SMB),
  and Thermal Subsystem (which we don't implement).  The PIIX3 southbridge
  consists of ISA bridge (PIIX3, IDE controller (piix3-ide), USB
  controller (piix3-usb-uhci, can be suppressed), and SMB controller
  (PIIX4_PM, can be suppressed).
 
  Some functions of southbridges still need to be wired up in code (ICH9
  LPC, ICH9 SMB, PIIX4_PM, PIIX4, PIIX3, PIIX3-xen, see PATCH
  5-6/9), thus cannot_instantiate_with_device_add_yet.
 
  The IDE controller functions have always been
  cannot_instantiate_with_device_add_yet, but it's not obvious to me why.
 
  The other functions are available with device-add.  Users device-add'ing
  them would of course be odd, but if it works...  I don't actually know
  whether it works for all of them.
 
  Should all southbridge functions be made unavailable with device-add for
  consistency, at least for now?
 
  Or should all functions be made available, except for the ones that
  cannot possibly work with device-add?
 
  If the latter, can you think of any specific reason why the IDE
  controllers couldn't work?

 I would've thought you and Kevin know more about IDE than me. ;)
 No idea why it is how it is.

 Two aspects:
 1) PCI devices/functions can technically be hotplugged.
 2) Drivers might not expect such devices to be hot-added/removed.

 I would tend for the latter proposal.

 I'm not sure how IDE hardware really works, but I don't think you can
 handle it as a pure PCI device. On PCs, the IDE controller still provides
 the good old IDE registers on the I/O ports that were already used in
 ISA times, and they are not described in any BARs, for example.

Legacy IDE and VGA accesses are positively decoded in the i440fx and
dispatched to the first PCI device with the appropriate class code.

 From a
 software point of view, the PCI device is just for configuring Busmaster
 DMA. Perhaps in reality it should be two devices, one for DMA on the PCI
 bus and another one for the core on sysbus or ISA?

It's definitely all a PCI device.  It could realistically be a
discrete device too that's plugged into a PCI bus that lacks a super
I/O chipset.


 Anyway, having two IDE controllers using the same I/O ports won't work,
 obviously. So if you would allow -device or device-add for them, you'd
 need options to configure the ports at least.

It's allowed but the PCI bus will only route the legacy requests to one of them.

Regards,

Anthony Liguori

 Kevin