Re: [Qemu-devel] [RFC 00/20] Do away with TB retranslation

[Artyom Tarasenko]

On Thu, Sep 10, 2015 at 8:07 AM, Dennis Luehring  wrote:
> Am 08.09.2015 um 21:00 schrieb Richard Henderson:
>>
>> Anyway, I've just fixed the sparc problem and re-pushed the tree to
>>
>>git://github.com/rth7680/qemu.git  tcg-search-2
>>
>> for anyone who wants to do any more testing.
>
>
> strangly your branch doesn't changed anything for pure SPARC64 in my tests -
> i've always completely removed the qemu folder and cleanly rebuild
> (all based on stable shell-scripts)

Can you please show "perf top" of the qemu-system-sparc64 process on
the host, when your g++ compilation is running?

Artyom

> and now even qemu git master stream results degrated to the worst results
> from my former tests
>
> last result from stream on an 3-4 week old git master - best of all test
> FunctionBest Rate MB/s  Avg time Min time Max time
> Copy: 771.5 0.214717 0.207377 0.244214
> Scale:288.1 0.573320 0.555401 0.660161
> Add:  423.5 0.633523 0.51 1.092067
> Triad:242.9 1.053032 0.987970 1.499563
>
> are parts of your patches already includes in the master?
>
> ~/qemu/sparc64-softmmu/qemu-system-sparc64 \
>   -m 1G \
>   -nographic \
>   -serial mon:telnet::3000,server,wait \
>   -monitor telnet::4440,server,nowait \
>   -netdev user,id=mynet0 \
>   -device ne2k_pci,netdev=mynet0 \
>   -hda ~/ramdisk/netbsd-615-sparc64.qcow2 \
>   -cdrom ~/netbsd/NetBSD-6.1.5-sparc64.iso -boot c \
>
> NetBSD SPARC64 (pure 64Bit)
>
> file /usr/bin/gcc
> /usr/bin/gcc: ELF 64-bit MSB executable, SPARC V9, relaxed memory ordering,
> (SYSV), dynamically linked (uses shared libs), for NetBSD 6.1.5, not
> stripped
>
> gcc prime.c -o prime.out -lm
> file prime.out
> prime.out: ELF 64-bit MSB executable, SPARC V9, relaxed memory ordering,
> (SYSV), dynamically linked (uses shared libs), for NetBSD 6.1.5, not
> stripped
>
> gcc stream.c -o stream.out -lm
> file stream.out
> stream.out: ELF 64-bit MSB executable, SPARC V9, relaxed memory ordering,
> (SYSV), dynamically linked (uses shared libs), for NetBSD 6.1.5, not
> stripped
>
> qemu rth7680 tcg-search-2
>
> cd ~/
> rm -rf qemu
> git clone git://github.com/rth7680/qemu.git
> git checkout tcg-search-2
> cd qemu
> ./configure --target-list=sparc64-softmmu
> make
>
> prime.out runtimes
>
> 11.22 real 11.19 user 0.00 sys
>  8.99 real  8.96 user 0.01 sys
>  9.03 real  8.99 user 0.01 sys
>  8.98 real  8.92 user 0.02 sys
>
> stream benchmark results
>
> #1
> FunctionBest Rate MB/s  Avg time Min time Max time
> Copy: 277.5 0.584221 0.576543 0.599850
> Scale:178.4 0.915691 0.896731 0.973512
> Add:  215.3 1.136872 1.114746 1.185749
> Triad:166.5 1.473816 1.441169 1.525007
>
> #2
> FunctionBest Rate MB/s  Avg time Min time Max time
> Copy: 278.1 0.577109 0.575259 0.583267
> Scale:179.3 0.901238 0.892399 0.911371
> Add:  215.2 1.124701 1.115341 1.176286
> Triad:167.0 1.448070 1.437424 1.457319
>
> #3
> FunctionBest Rate MB/s  Avg time Min time Max time
> Copy: 276.5 0.580420 0.578757 0.583966
> Scale:179.8 0.898168 0.889899 0.903530
> Add:  212.7 1.130851 1.128318 1.136284
> Triad:164.1 1.464667 1.462173 1.467856
>
> #4
> FunctionBest Rate MB/s  Avg time Min time Max time
> Copy: 276.0 0.580713 0.579757 0.583575
> Scale:177.8 0.906521 0.899661 0.910353
> Add:  213.9 1.124599 1.19 1.128944
> Triad:166.0 1.450210 1.446169 1.457350
>
> g++ src/pugixml.cpp -g -Wall -Wextra -Werror -pedantic -std=c++0x -c -MMD
> -MP
>
> compile times
> 156.49 real 149.09 user 6.97 sys
> 156.54 real 149.01 user 6.86 sys
> 155.91 real 148.71 user 6.93 sys
> 156.51 real 149.12 user 6.83 sys
>
> qemu git master
>
> cd ~/
> rm -rf qemu
> git clone git://git.qemu-project.org/qemu.git
> cd qemu
> ./configure --target-list=sparc64-softmmu
> make
>
> prime.out runtimes
>
> 9.32 real 9.26 user 0.03 sys
> 8.98 real 8.92 user 0.04 sys
> 8.97 real 8.93 user 0.02 sys
> 9.00 real 8.97 user 0.02 sys
>
> stream benchmark results
>
> #1
> FunctionBest Rate MB/s  Avg time Min time Max time
> Copy: 276.6 0.584092 0.578538 0.592748
> Scale:179.0 0.908465 0.893868 0.924004
> Add:  215.5 1.122398 1.113689 1.128655
> Triad:167.6 1.449198 1.432321 1.457774
>
> #2
> FunctionBest Rate MB/s  Avg time Min time Max time
> Copy: 276.8 0.579905 0.577936 0.585222
> Scale:177.6 0.916502 0.900911 0.924964
> Add:  213.0 1.128311 1.126591 

Re: [Qemu-devel] [PATCH 5/7] vhost_net: move vhost_net_set_vq_index ahead at vhost_net_init

[Yuanhan Liu]

On Thu, Sep 10, 2015 at 02:54:02PM +0800, Jason Wang wrote:
> 
> 
> On 09/10/2015 02:18 PM, Yuanhan Liu wrote:
> > On Thu, Sep 10, 2015 at 01:52:30PM +0800, Jason Wang wrote:
> >>
> >> On 09/10/2015 01:17 PM, Yuanhan Liu wrote:
> >>> On Thu, Sep 10, 2015 at 12:46:00PM +0800, Jason Wang wrote:
> >
> > On 09/10/2015 11:57 AM, Yuanhan Liu wrote:
> >>> On Thu, Sep 10, 2015 at 11:14:27AM +0800, Jason Wang wrote:
> > On 09/08/2015 03:38 PM, Yuanhan Liu wrote:
> >>> So that we could use the `vq_index' as well in the vhost_net_init
> >>> stage, which is required when adding vhost-user multiple-queue 
> >>> support,
> >>> where we need the vq_index to indicate which queue pair we are 
> >>> gonna
> >>> initiate.
> >>>
> >>> vhost-user has no multiple queue support yet, hence no 
> >>> queue_index set
> >>> before. Here is a quick set to 0 at net_vhost_user_init() stage, 
> >>> and it
> >>> will be set properly soon in the next patch.
> >>>
> >>> Signed-off-by: Yuanhan Liu 
> >>> ---
> >>>  hw/net/vhost_net.c | 16 +++-
> >>>  net/vhost-user.c   |  1 +
> >>>  2 files changed, 8 insertions(+), 9 deletions(-)
> >>>
> >>> diff --git a/hw/net/vhost_net.c b/hw/net/vhost_net.c
> >>> index f9441e9..141b557 100644
> >>> --- a/hw/net/vhost_net.c
> >>> +++ b/hw/net/vhost_net.c
> >>> @@ -138,6 +138,11 @@ static int vhost_net_get_fd(NetClientState 
> >>> *backend)
> >>>  }
> >>>  }
> >>>  
> >>> +static void vhost_net_set_vq_index(struct vhost_net *net, int 
> >>> vq_index)
> >>> +{
> >>> +net->dev.vq_index = vq_index;
> >>> +}
> >>> +
> >>>  struct vhost_net *vhost_net_init(VhostNetOptions *options)
> >>>  {
> >>>  int r;
> >>> @@ -167,6 +172,8 @@ struct vhost_net 
> >>> *vhost_net_init(VhostNetOptions *options)
> >>>  }
> >>>  net->nc = options->net_backend;
> >>>  
> >>> +vhost_net_set_vq_index(net, net->nc->queue_index * 2);
> >>> +
> > This breaks vhost kernel multiqueue since queue_index was not
> > initialized at this time.
> >>> Right, thanks for pointing it out.
> >>>
> > We do this in set_netdev() instead of setting
> > it in each kind of netdev.
> >>> Can we move it to net_init_tap() for setting the right queue_index
> >>> for each nc?
> >>>
> >>> Or, can we call vhost_net_set_vq_index twice, one at 
> >>> vhost_net_init(for
> >>> vhost-user mq support), another one at vhost_net_start(for vhost 
> >>> kernel
> >>> mq support)?
> >>>
> >>> Or, do you have better ideas?
> > I think setting queue_index in net_init_tap() looks ok.
> >>> Good to know.
> >>>
> > But a question
> > is that why need we do this at so early stage? ( Even before its peers
> > is connected.)
> >>> For vhost-user multiple queues support, we will invoke vhost_net_init()
> >>> N times for each queue pair, and hence we need to distinguish which
> >>> queue it is while sending messages like VHOST_SET_VRING_CALL for
> >>> initializing corresponding queue pair.
> >>>
> >>> Does that make sense to you?
> >>>
> >> Not sure. Since current codes works for vhost-kernel. (vhost_net_init()
> >> was also called N times). We don't want to break existed vhost-kernel
> >> API when developing multiqueue. For each virtqueue TX/RX pair, we have
> >> one vhost net device and it has no knowledge for the others (which was
> >> hide by qemu). So VHOST_SET_VRING_CALL works without any change here.
> >>
> >> For the case here, since you still have multiple instances of vhost_net
> >> structure. Maybe the vhost-user backend can distinguish form this?
> > Yeah, I guess that's the difference between vhost-user and vhost-kernel.
> > Vhost-kernel opens a char device(/dev/vhost-net) for each vhost_dev,
> > hence it's distinguishable. But for vhost-user, all vhost_dev share one
> > char device(a socket) for communication, hence, it's not distinguishable.
> 
> How about using individual socket in this case? This seems can also
> minimize the changes of backend.

I doubt that will work, for the socket is given at cmd line by "-chardev"
option. You can image that it's not flexible when you want to have 10
queues, or more.

> 
> >
> > I was thinking maybe we could export vhost_net_set_vq_index() and invoke
> > it at net/vhost-user.c, so that we break nothing, and in the meantime,
> > it keeps the logic inside vhost-user.
> >
> > What do you think?
> >
> > --yliu
> >
> 
> Sounds work.

Good.

> Then I believe you will need to set queue_index in
> vhost_user initialization code?

Yes. I then will go this way if no objection.

--yliu 

Re: [Qemu-devel] [PATCH] ui/cocoa.m: Add Mount image file menu item

[Markus Armbruster]

Programmingkid  writes:

> On Sep 9, 2015, at 6:25 PM, Eric Blake wrote:
>
>> On 09/09/2015 03:37 PM, Programmingkid wrote:
>> 
>>> 
>>> Thank you very much for caring. I appreciate all the help I can
>>> receive. I so like my idea of
>>> sending a command to QEMU as if the user typed it himself. It is so
>>> easy to maintain. So
>>> easy to use. So expandable. But given that two maintainers have
>>> told me that I can't do this,
>>> the idea has to be abandoned. 
>> 
>> Even emulating typing into the QMP interface is a non-starter.  Just
>> call the same functions that QMP would eventually call.
>
> That is a lot easier said than done. 

Most of the time, it's actually a lot easier than creating a monitor,
constructing a command safely (mind the quoting rules), feeding it to
the monitor, receiving the reply, parsing the reply, and having fun with
manual memory management along the way.

For an exception, see below.

>>> The C interface idea sounds good, but trying to figure out how to
>>> make any of the handler
>>> functions work is very difficult. Just trying to make the QDict and
>>> QObject variables is just
>>> too much. It needs to be a lot easier than this.
>>> 
>>> That leaves QMP. I am trying to figure it out. This is my attempt so far:
>>> 
>>> Error **errp;
>>> char *commandBuffer;
>>> commandBuffer = g_strdup_printf("{ \"execute\": \"quit\" }");
>>> qmp_query_command_line_options(false, commandBuffer, errp);
>>> printf("Program should quit now\n");
>>> 
>> 
>> If you type the QMP command:
>> 
>> { "execute": "query-command-line-options", "arguments": { "option":
>> "quit" } }
>> 
>> then that will result in calling:
>> 
>> Error *err;
>> qmp_query_command_line_options(true, "quit", &err);
>> 
>> which will set err (because '-quit' is not a command line option).
>> 
>> But if you are worried about constructing a QDict (which is a subset of
>> QObject), you are probably trying to call the wrong interface.
>
> That may be so. I need to do the equivalent of "device_add" and "device_del". 
> You have any ideas how to do it in C? 

That's the exception.  See further below.

>> In qmp-commands.hx, the command 'query-command-line-options' is tied to
>> qmp_marshal_query_command_line_options (well, after Markus' latest
>> patches are applied; in current qemu.git it is still named
>> qmp_marshal_input_query_command_line_options).  That is the generated
>> function that takes QDict, and then calls into the much nicer interface
>> of qmp_query_command_line_options() that has already broken out all the
>> arguments into straight-forward parameters.
>
> I just wish it was as easy as qmp("{ \"execute\" : \" \"}"); 

What's difficult about any of the following?

qmp_system_reset(&err);

qmp_query_command_line_options(false, NULL, &err);

qmp_device_del("my-dev-id", &err);

Each of them is about as simple as it gets.

The sad exceptions are the QMP commands defined with 'gen': false.  For
these, you have to use a much less convenient interface, of the form

void qmp_FOO(QDict *qdict, QObject **ret_data, Error **errp);

Matches the QMP wire format closely.  qdict corrsponds to the
"arguments" JSON object, ret_data corresponds to the success response's
"return" JSON value, and errp corresponds do the error response.

There are only a few such commands, and we're working on reducing their
number further.  The hardest nut, however, is device_add.

> If you know a way to execute a qmp command by using a function that
> takes a string,
> please let me know.

If there was one, it wouldn't be the C interface you should use.

Re: [Qemu-devel] [PATCH] ui/cocoa.m: Add Mount image file menu item

[Markus Armbruster]

Programmingkid  writes:

> Does this look about right?
>
> QDict *qdict;
> Error *errp;
> QObject **ret_data;
> static int counter;
> char *idString, *fileName;
>
>   // The file variable is objective-c, left that code out
>
> fileName = g_strdup_printf("%s",
> [file cStringUsingEncoding: 
> NSASCIIStringEncoding]);
> 
> /* Create an unique id */
> idString = g_strdup_printf("USB%d", counter++);
>
> /* Create the QDICT object */
> qdict = qdict_new();
> qdict_put_obj(qdict, "id", qstring_from_str(idString));
> qdict_put_obj(qdict, "device", qstring_from_str(idString));
> qdict_put_obj(qdict, "if", qstring_from_str("none"));
> qdict_put_obj(qdict, "file", qstring_from_str(fileName));
> qdict_put_obj(qdict, "driver", qstring_from_str("usb-storage"));
> drive_add(IF_DEFAULT, 0, fileName, "none");
> qmp_device_add(qdict, ret_data, &errp);
> handleAnyDeviceErrors(errp);
> g_free(fileName);
> g_free(idString);
>
> This is a sample of what I am working on. For some reason, it crashes QEMU. 
> Any clues why? I think it might be because of qdict_put_obj(). 

My crystal ball is down for maintenance today, so you'll have to gives
us the clues yourself: a stack backtrace, for starters :)

Re: [Qemu-devel] [PATCH v2 2/2] target-i386: move asm-x86/hyperv.h to standard-headers

[Cornelia Huck]

On Wed,  9 Sep 2015 18:34:01 +0200
Paolo Bonzini  wrote:

> The Hyper-V definitions are an industry standard and can be used
> from code that is not KVM-specific.
> 
> The changes to scripts/update-linux-headers.sh are required because there
> is both an asm-x86/hyperv.h and a linux/hyperv.h file.  linux/hyperv.h
> introduces dependencies on additional Linux uapi headers, so we only
> want the former.
> 
> The solution is to make cp_virtio (now renamed to cp_portable) copy
> one file only, instead of using the "find" command, and call it multiple
> times.  The new function is really just a reindentation of the old one.
> 
> Signed-off-by: Paolo Bonzini 
> ---
>  .../standard-headers}/asm-x86/hyperv.h|  10 +-
>  linux-headers/asm-x86/hyperv.h| 253 
> +-
>  scripts/update-linux-headers.sh   |  79 +-
>  target-i386/kvm.c |   2 +-
>  4 files changed, 52 insertions(+), 295 deletions(-)
>  copy {linux-headers => include/standard-headers}/asm-x86/hyperv.h (98%)
 
Reviewed-by: Cornelia Huck 

Re: [Qemu-devel] [PATCH v2 1/2] update Linux headers to 4.2

[Michael S. Tsirkin]

On Wed, Sep 09, 2015 at 06:34:00PM +0200, Paolo Bonzini wrote:
> Signed-off-by: Paolo Bonzini 
> ---
>  hw/pci/pcie_aer.c|   4 +-
>  include/standard-headers/linux/pci_regs.h| 381 
> ---
>  include/standard-headers/linux/virtio_ring.h |   3 +-
>  linux-headers/asm-x86/hyperv.h   |   2 +
>  linux-headers/asm-x86/kvm.h  |   4 +-
>  scripts/update-linux-headers.sh  |   1 +
>  6 files changed, 294 insertions(+), 101 deletions(-)
> 
> diff --git a/hw/pci/pcie_aer.c b/hw/pci/pcie_aer.c
> index f1847ac..8e4bd56 100644
> --- a/hw/pci/pcie_aer.c
> +++ b/hw/pci/pcie_aer.c
> @@ -827,8 +827,8 @@ typedef struct PCIEAERErrorName {
>   */
>  static const struct PCIEAERErrorName pcie_aer_error_list[] = {
>  {
> -.name = "TRAIN",
> -.val = PCI_ERR_UNC_TRAIN,
> +.name = "UND",
> +.val = PCI_ERR_UNC_UND,
>  .correctable = false,
>  }, {
>  .name = "DLP",

I think we should drop this entry.
The spec says:

Undefined – The value read from this bit is
undefined. In previous versions of this
specification, this bit was used to indicate a Link
Training Error. System software must ignore the
value read from this bit. System software is
permitted to write any value to this bit.

In other words, this bit should be ignored.


-- 
MST

Re: [Qemu-devel] [Qemu-ppc] [PATCH v2 1/2] spapr: Add support for hwrng when available

[Thomas Huth]

On 09/09/15 23:10, Thomas Huth wrote:
> On 08/09/15 07:15, David Gibson wrote:
...
>> At this point rather than just implementing them as discrete machine
>> options, I suspect it will be more maintainable to split out the
>> h-random implementation as a pseudo-device with its own qdev and so
>> forth.  We already do similarly for the RTAS time of day functions
>> (spapr-rtc).
> 
> I gave that I try, but it does not work as expected. To be able to
> specify the options, I'd need to instantiate this device with the
> "-device" option, right? Something like:
> 
>   -device spapr-rng,backend=rng0,usekvm=0
> 
> Now this does not work when I use TYPE_SYS_BUS_DEVICE as parent class
> like it is done for spapr-rtc, since the user apparently can not plug
> device to this bus on machine spapr (you can also not plug an spapr-rtc
> device this way!).
> 
> The spapr-vlan, spapr-vty, etc. devices are TYPE_VIO_SPAPR_DEVICE, so I
> also tried that instead, but then the rng device suddenly shows up under
> /vdevice in the device tree - that's also not what we want, I guess.

I did some more tests, and I think I can get this working with one small
modification to spapr_vio.c:

diff --git a/hw/ppc/spapr_vio.c b/hw/ppc/spapr_vio.c
index c51eb8e..8e7f6b4 100644
--- a/hw/ppc/spapr_vio.c
+++ b/hw/ppc/spapr_vio.c
@@ -99,6 +99,14 @@ static int vio_make_devnode(VIOsPAPRDevice *dev,
 int vdevice_off, node_off, ret;
 char *dt_name;

+if (!pc->dt_name) {
+ret = 0;
+if (pc->devnode) {
+ret = (pc->devnode)(dev, fdt, -1);
+}
+return ret;
+}
+
 vdevice_off = fdt_path_offset(fdt, "/vdevice");
 if (vdevice_off < 0) {
 return vdevice_off;

i.e. when the dt_name has not been set, the device won't be added to the
/vdevice device tree node. If that's acceptable, I'll continue with this
approach.

 Thomas




signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH v2 2/2] target-i386: move asm-x86/hyperv.h to standard-headers

[Michael S. Tsirkin]

On Wed, Sep 09, 2015 at 06:34:01PM +0200, Paolo Bonzini wrote:
> The Hyper-V definitions are an industry standard and can be used
> from code that is not KVM-specific.
> 
> The changes to scripts/update-linux-headers.sh are required because there
> is both an asm-x86/hyperv.h and a linux/hyperv.h file.  linux/hyperv.h
> introduces dependencies on additional Linux uapi headers, so we only
> want the former.
> 
> The solution is to make cp_virtio (now renamed to cp_portable) copy
> one file only, instead of using the "find" command, and call it multiple
> times.  The new function is really just a reindentation of the old one.
> 
> Signed-off-by: Paolo Bonzini 

I'd rather see a script update, then result of running it
in a separate patch.

> ---
>  .../standard-headers}/asm-x86/hyperv.h|  10 +-
>  linux-headers/asm-x86/hyperv.h| 253 
> +-
>  scripts/update-linux-headers.sh   |  79 +-
>  target-i386/kvm.c |   2 +-
>  4 files changed, 52 insertions(+), 295 deletions(-)
>  copy {linux-headers => include/standard-headers}/asm-x86/hyperv.h (98%)
> 
> diff --git a/include/standard-headers/asm-x86/hyperv.h 
> b/include/standard-headers/asm-x86/hyperv.h
> similarity index 98%
> copy from linux-headers/asm-x86/hyperv.h
> copy to include/standard-headers/asm-x86/hyperv.h
> index f36d56b..a2123ca 100644
> --- a/linux-headers/asm-x86/hyperv.h
> +++ b/include/standard-headers/asm-x86/hyperv.h
> @@ -1,7 +1,7 @@
>  #ifndef _ASM_X86_HYPERV_H
>  #define _ASM_X86_HYPERV_H
>  
> -#include 
> +#include "standard-headers/linux/types.h"
>  
>  /*
>   * The below CPUID leaves are present if VersionAndFeatures.HypervisorPresent
> @@ -243,10 +243,10 @@
>  #define HV_STATUS_INSUFFICIENT_BUFFERS 19
>  
>  typedef struct _HV_REFERENCE_TSC_PAGE {
> -   __u32 tsc_sequence;
> -   __u32 res1;
> -   __u64 tsc_scale;
> -   __s64 tsc_offset;
> +   uint32_t tsc_sequence;
> +   uint32_t res1;
> +   uint64_t tsc_scale;
> +   int64_t tsc_offset;
>  } HV_REFERENCE_TSC_PAGE, *PHV_REFERENCE_TSC_PAGE;
>  
>  #endif
> diff --git a/linux-headers/asm-x86/hyperv.h b/linux-headers/asm-x86/hyperv.h
> index f36d56b..01af4d8 100644
> --- a/linux-headers/asm-x86/hyperv.h
> +++ b/linux-headers/asm-x86/hyperv.h
> @@ -1,252 +1 @@
> -#ifndef _ASM_X86_HYPERV_H
> -#define _ASM_X86_HYPERV_H
> -
> -#include 
> -
> -/*
> - * The below CPUID leaves are present if VersionAndFeatures.HypervisorPresent
> - * is set by CPUID(HvCpuIdFunctionVersionAndFeatures).
> - */
> -#define HYPERV_CPUID_VENDOR_AND_MAX_FUNCTIONS0x4000
> -#define HYPERV_CPUID_INTERFACE   0x4001
> -#define HYPERV_CPUID_VERSION 0x4002
> -#define HYPERV_CPUID_FEATURES0x4003
> -#define HYPERV_CPUID_ENLIGHTMENT_INFO0x4004
> -#define HYPERV_CPUID_IMPLEMENT_LIMITS0x4005
> -
> -#define HYPERV_HYPERVISOR_PRESENT_BIT0x8000
> -#define HYPERV_CPUID_MIN 0x4005
> -#define HYPERV_CPUID_MAX 0x4000
> -
> -/*
> - * Feature identification. EAX indicates which features are available
> - * to the partition based upon the current partition privileges.
> - */
> -
> -/* VP Runtime (HV_X64_MSR_VP_RUNTIME) available */
> -#define HV_X64_MSR_VP_RUNTIME_AVAILABLE  (1 << 0)
> -/* Partition Reference Counter (HV_X64_MSR_TIME_REF_COUNT) available*/
> -#define HV_X64_MSR_TIME_REF_COUNT_AVAILABLE  (1 << 1)
> -
> -/* A partition's reference time stamp counter (TSC) page */
> -#define HV_X64_MSR_REFERENCE_TSC 0x4021
> -
> -/*
> - * There is a single feature flag that signifies the presence of the MSR
> - * that can be used to retrieve both the local APIC Timer frequency as
> - * well as the TSC frequency.
> - */
> -
> -/* Local APIC timer frequency MSR (HV_X64_MSR_APIC_FREQUENCY) is available */
> -#define HV_X64_MSR_APIC_FREQUENCY_AVAILABLE (1 << 11)
> -
> -/* TSC frequency MSR (HV_X64_MSR_TSC_FREQUENCY) is available */
> -#define HV_X64_MSR_TSC_FREQUENCY_AVAILABLE (1 << 11)
> -
> -/*
> - * Basic SynIC MSRs (HV_X64_MSR_SCONTROL through HV_X64_MSR_EOM
> - * and HV_X64_MSR_SINT0 through HV_X64_MSR_SINT15) available
> - */
> -#define HV_X64_MSR_SYNIC_AVAILABLE   (1 << 2)
> -/*
> - * Synthetic Timer MSRs (HV_X64_MSR_STIMER0_CONFIG through
> - * HV_X64_MSR_STIMER3_COUNT) available
> - */
> -#define HV_X64_MSR_SYNTIMER_AVAILABLE(1 << 3)
> -/*
> - * APIC access MSRs (HV_X64_MSR_EOI, HV_X64_MSR_ICR and HV_X64_MSR_TPR)
> - * are available
> - */
> -#define HV_X64_MSR_APIC_ACCESS_AVAILABLE (1 << 4)
> -/* Hypercall MSRs (HV_X64_MSR_GUEST_OS_ID and HV_X64_MSR_HYPERCALL) 
> available*/
> -#define HV_X64_MSR_HYPERCALL_AVAILABLE   (1 << 5)
> -/* Access virtual processor index MSR (HV_X64_MSR_VP_INDEX) available*/
> -#define HV_X64_MSR_VP_INDEX_AVAILABLE(1 << 6

Re: [Qemu-devel] [PATCH] linux-user/main.c: Always set QEMU_LD_PREFIX when interp_prefix is changed

[Chen Gang]

Oh, this issue may be for all command lines (e.g. -d option), I  guess, we need
process them all in main() when process command line options.


> Subject: Re: [PATCH] linux-user/main.c: Always set QEMU_LD_PREFIX when 
> interp_prefix is changed
> To: riku.voi...@iki.fi
> CC: r...@twiddle.net; peter.mayd...@linaro.org; qemu-devel@nongnu.org
> From: xili_gchen_5...@hotmail.com
> Date: Thu, 10 Sep 2015 13:49:18 +0800
>
> On 2015年09月10日 13:43, gang.chen.5...@gmail.com wrote:
>> From: Chen Gang 
>>
>> If qemu sets interp_prfix via command line '-L' instead of environments
>> variable QEMU_LD_PREFIX, it will cause syscall execve() failed. Because
>> the 2nd qemu has no command line '-L'.
>>
>
> Oh, sorry for typo, "the 2nd" -> "the second".
>
>> So qemu need always set QEMU_LD_PREFIX when interp_prefix is changed.
>>
>> Signed-off-by: Chen Gang 
>
>
> Thanks.
> --
> Chen Gang
>
> Open, share, and attitude like air, water, and life which God blessed
  

[Qemu-devel] [PATCH] cutils: work around platform differences in strto{l, ul, ll, ull}

[Paolo Bonzini]

Linux returns 0 if no conversion was made, while OS X and presumably
the BSDs return EINVAL.  The OS X convention rejects more invalid
inputs, so convert to it and adjust the test case.

Windows returns 1 from strtoul and strtoull (instead of -1) for
negative out-of-range input; fix it up.

Reported-by: Peter Maydell 
Signed-off-by: Paolo Bonzini 
---
 tests/test-cutils.c | 57 +++--
 util/cutils.c   | 24 +-
 2 files changed, 35 insertions(+), 46 deletions(-)

diff --git a/tests/test-cutils.c b/tests/test-cutils.c
index a7a15a5..0046c61 100644
--- a/tests/test-cutils.c
+++ b/tests/test-cutils.c
@@ -264,9 +264,7 @@ static void test_qemu_strtol_empty(void)
 
 err = qemu_strtol(str, &endptr, 0, &res);
 
-g_assert_cmpint(err, ==, 0);
-g_assert_cmpint(res, ==, 0);
-g_assert(endptr == str);
+g_assert_cmpint(err, ==, -EINVAL);
 }
 
 static void test_qemu_strtol_whitespace(void)
@@ -279,9 +277,7 @@ static void test_qemu_strtol_whitespace(void)
 
 err = qemu_strtol(str, &endptr, 0, &res);
 
-g_assert_cmpint(err, ==, 0);
-g_assert_cmpint(res, ==, 0);
-g_assert(endptr == str);
+g_assert_cmpint(err, ==, -EINVAL);
 }
 
 static void test_qemu_strtol_invalid(void)
@@ -294,9 +290,7 @@ static void test_qemu_strtol_invalid(void)
 
 err = qemu_strtol(str, &endptr, 0, &res);
 
-g_assert_cmpint(err, ==, 0);
-g_assert_cmpint(res, ==, 0);
-g_assert(endptr == str);
+g_assert_cmpint(err, ==, -EINVAL);
 }
 
 static void test_qemu_strtol_trailing(void)
@@ -478,8 +472,7 @@ static void test_qemu_strtol_full_empty(void)
 
 err =  qemu_strtol(str, NULL, 0, &res);
 
-g_assert_cmpint(err, ==, 0);
-g_assert_cmpint(res, ==, 0);
+g_assert_cmpint(err, ==, -EINVAL);
 }
 
 static void test_qemu_strtol_full_negative(void)
@@ -555,9 +548,7 @@ static void test_qemu_strtoul_empty(void)
 
 err = qemu_strtoul(str, &endptr, 0, &res);
 
-g_assert_cmpint(err, ==, 0);
-g_assert_cmpint(res, ==, 0);
-g_assert(endptr == str);
+g_assert_cmpint(err, ==, -EINVAL);
 }
 
 static void test_qemu_strtoul_whitespace(void)
@@ -570,9 +561,7 @@ static void test_qemu_strtoul_whitespace(void)
 
 err = qemu_strtoul(str, &endptr, 0, &res);
 
-g_assert_cmpint(err, ==, 0);
-g_assert_cmpint(res, ==, 0);
-g_assert(endptr == str);
+g_assert_cmpint(err, ==, -EINVAL);
 }
 
 static void test_qemu_strtoul_invalid(void)
@@ -585,8 +574,7 @@ static void test_qemu_strtoul_invalid(void)
 
 err = qemu_strtoul(str, &endptr, 0, &res);
 
-g_assert_cmpint(err, ==, 0);
-g_assert(endptr == str);
+g_assert_cmpint(err, ==, -EINVAL);
 }
 
 static void test_qemu_strtoul_trailing(void)
@@ -765,8 +753,7 @@ static void test_qemu_strtoul_full_empty(void)
 
 err = qemu_strtoul(str, NULL, 0, &res);
 
-g_assert_cmpint(err, ==, 0);
-g_assert_cmpint(res, ==, 0);
+g_assert_cmpint(err, ==, -EINVAL);
 }
 static void test_qemu_strtoul_full_negative(void)
 {
@@ -840,9 +827,7 @@ static void test_qemu_strtoll_empty(void)
 
 err = qemu_strtoll(str, &endptr, 0, &res);
 
-g_assert_cmpint(err, ==, 0);
-g_assert_cmpint(res, ==, 0);
-g_assert(endptr == str);
+g_assert_cmpint(err, ==, -EINVAL);
 }
 
 static void test_qemu_strtoll_whitespace(void)
@@ -855,9 +840,7 @@ static void test_qemu_strtoll_whitespace(void)
 
 err = qemu_strtoll(str, &endptr, 0, &res);
 
-g_assert_cmpint(err, ==, 0);
-g_assert_cmpint(res, ==, 0);
-g_assert(endptr == str);
+g_assert_cmpint(err, ==, -EINVAL);
 }
 
 static void test_qemu_strtoll_invalid(void)
@@ -870,8 +853,7 @@ static void test_qemu_strtoll_invalid(void)
 
 err = qemu_strtoll(str, &endptr, 0, &res);
 
-g_assert_cmpint(err, ==, 0);
-g_assert(endptr == str);
+g_assert_cmpint(err, ==, -EINVAL);
 }
 
 static void test_qemu_strtoll_trailing(void)
@@ -1050,8 +1032,7 @@ static void test_qemu_strtoll_full_empty(void)
 
 err = qemu_strtoll(str, NULL, 0, &res);
 
-g_assert_cmpint(err, ==, 0);
-g_assert_cmpint(res, ==, 0);
+g_assert_cmpint(err, ==, -EINVAL);
 }
 
 static void test_qemu_strtoll_full_negative(void)
@@ -1128,9 +1109,7 @@ static void test_qemu_strtoull_empty(void)
 
 err = qemu_strtoull(str, &endptr, 0, &res);
 
-g_assert_cmpint(err, ==, 0);
-g_assert_cmpint(res, ==, 0);
-g_assert(endptr == str);
+g_assert_cmpint(err, ==, -EINVAL);
 }
 
 static void test_qemu_strtoull_whitespace(void)
@@ -1143,9 +1122,7 @@ static void test_qemu_strtoull_whitespace(void)
 
 err = qemu_strtoull(str, &endptr, 0, &res);
 
-g_assert_cmpint(err, ==, 0);
-g_assert_cmpint(res, ==, 0);
-g_assert(endptr == str);
+g_assert_cmpint(err, ==, -EINVAL);
 }
 
 static void test_qemu_strtoull_invalid(void)
@@ -1158,8 +1135,7 @@ static void test_qemu_strtoull_invalid(void)
 
 err = qemu_strtoull(str, &endptr, 0, &res);
 
-g_assert_cmpint(err, ==, 0);
-g_assert(endptr == str);
+

Re: [Qemu-devel] [Qemu-trivial] [PATCH] qemu-char: Do not disconnect when there's data for reading

[Michael S. Tsirkin]

On Wed, Sep 24, 2014 at 11:52:37AM +0400, Michael Tokarev wrote:
> 16.09.2014 09:31, Zifei Tong wrote:
> > Friendly ping.
> > 
> > Also CC to qemu-trivial.
> 
> There was at least 2 subsequent versions of this down the line,
> a v2 and a v3.  (Just to show why I haven't applied it to -trivial).
> 
> Thanks,
> 
> /mjt

It's also far from trivial.
I don't see why it applies there.

> > On Sun, Sep 7, 2014 at 8:24 PM, Zifei Tong  wrote:
> >> After commit 812c1057f6175ac9a9829fa2920a2b5783814193 (Handle G_IO_HUP
> >> in tcp_chr_read for tcp chardev), the connection is disconnected when in
> >> G_IO_HUP condition.
> >>
> >> However, it's possible that the channel is in G_IO_IN condition at the
> >> same time, meaning there is data for reading. In that case, the
> >> remaining data is not handled.
> >>
> >> I saw a related bug when running socat in write-only mode, with
> >>
> >>   $ echo "quit" | socat -u - UNIX-CONNECT:qemu-monitor
> >>
> >> the monitor won't not run the 'quit' command.
> >>
> >> CC: Kirill Batuzov 
> >> CC: Nikolay Nikolaev 
> >> CC: Anthony Liguori 
> >> Signed-off-by: Zifei Tong 
> >> ---
> >>  qemu-char.c | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/qemu-char.c b/qemu-char.c
> >> index 1a8d9aa..5018c3a 100644
> >> --- a/qemu-char.c
> >> +++ b/qemu-char.c
> >> @@ -2706,7 +2706,7 @@ static gboolean tcp_chr_read(GIOChannel *chan, 
> >> GIOCondition cond, void *opaque)
> >>  uint8_t buf[READ_BUF_LEN];
> >>  int len, size;
> >>
> >> -if (cond & G_IO_HUP) {
> >> +if (!(cond & G_IO_IN) && (cond & G_IO_HUP)) {
> >>  /* connection closed */
> >>  tcp_chr_disconnect(chr);
> >>  return TRUE;
> >> --
> >> 2.1.0
> >>
> > 
> 

Re: [Qemu-devel] [PATCH v3] qemu-char: Do not disconnect when there's data for reading

[Michael S. Tsirkin]

On Mon, Oct 20, 2014 at 10:24:44AM +0200, Markus Armbruster wrote:
> MAINTAINERS points to Anthony, and you duly cc'ed him, but he's
> effectively retired.  Cc'ing recent committers include Paolo and Peter.
> 
> Zifei Tong  writes:

I merged the patch that broke this, so I'll merge the fix too.


> > After commit 812c1057f6175ac9a9829fa2920a2b5783814193 (Handle G_IO_HUP
> > in tcp_chr_read for tcp chardev), connections are disconnected when in
> > G_IO_HUP condition.
> >
> > However, it's possible that there is still data for reading in the channel.
> > In that case, the remaining data is not handled.
> >
> > I saw a related bug when running socat in write-only mode, after
> >
> >   $ echo "quit" | socat -u - UNIX-CONNECT:qemu-monitor
> >
> > the monitor won't not run the 'quit' command.
> >
> > Instead of GIOCondition, this patch uses the return value of tcp_chr_recv()
> > to check the state of connection as suggested by Kirill.
> >
> > Cc: Kirill Batuzov 
> > Cc: Nikolay Nikolaev 
> > Cc: Markus Armbruster 
> > Cc: Anthony Liguori 
> > Signed-off-by: Zifei Tong 
> > ---
> > Changes in v3: handle EWOULDBLOCK, remove inaccurate comment
> >
> >  qemu-char.c | 10 ++
> >  1 file changed, 2 insertions(+), 8 deletions(-)
> >
> > diff --git a/qemu-char.c b/qemu-char.c
> > index 2a3cb9f..d1893a0 100644
> > --- a/qemu-char.c
> > +++ b/qemu-char.c
> > @@ -2692,12 +2692,6 @@ static gboolean tcp_chr_read(GIOChannel *chan, 
> > GIOCondition cond, void *opaque)
> >  uint8_t buf[READ_BUF_LEN];
> >  int len, size;
> >  
> > -if (cond & G_IO_HUP) {
> > -/* connection closed */
> > -tcp_chr_disconnect(chr);
> > -return TRUE;
> > -}
> > -
> >  if (!s->connected || s->max_size <= 0) {
> >  return TRUE;
> >  }
> > @@ -2705,8 +2699,8 @@ static gboolean tcp_chr_read(GIOChannel *chan, 
> > GIOCondition cond, void *opaque)
> >  if (len > s->max_size)
> >  len = s->max_size;
> >  size = tcp_chr_recv(chr, (void *)buf, len);
> > -if (size == 0) {
> > -/* connection closed */
> > +if (size == 0 ||
> > +(size < 0 && !(errno == EAGAIN || errno == EWOULDBLOCK || errno == 
> > EINTR))) {
> >  tcp_chr_disconnect(chr);
> >  } else if (size > 0) {
> >  if (s->do_telnetopt)

[Qemu-devel] [PATCH v2] linux-user/main.c: Set environments variables from command line options

[gang . chen . 5i5j]

From: Chen Gang 

When qemu execute execve() system call, the related command line options
can not be passed to the second qemu process, which causes the second
process fail.

Signed-off-by: Chen Gang 
---
 linux-user/main.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/linux-user/main.c b/linux-user/main.c
index 06dd296..f1f5496 100644
--- a/linux-user/main.c
+++ b/linux-user/main.c
@@ -3767,6 +3767,7 @@ static void usage(void)
 static int parse_args(int argc, char **argv)
 {
 const char *r;
+char *buf;
 int optind;
 const struct qemu_argument *arginfo;
 
@@ -3802,6 +3803,9 @@ static int parse_args(int argc, char **argv)
 if (optind >= argc) {
 usage();
 }
+buf = g_strdup_printf("%s=%s", arginfo->env, argv[optind]);
+(void) envlist_setenv(envlist, buf);
+g_free(buf);
 arginfo->handle_opt(argv[optind]);
 optind++;
 } else {
-- 
1.9.1

Re: [Qemu-devel] [PATCH v3] qemu-char: Do not disconnect when there's data for reading

[Michael S. Tsirkin]

On Thu, Sep 10, 2015 at 11:04:05AM +0300, Michael S. Tsirkin wrote:
> On Mon, Oct 20, 2014 at 10:24:44AM +0200, Markus Armbruster wrote:
> > MAINTAINERS points to Anthony, and you duly cc'ed him, but he's
> > effectively retired.  Cc'ing recent committers include Paolo and Peter.
> > 
> > Zifei Tong  writes:
> 
> I merged the patch that broke this, so I'll merge the fix too.

Oh, Paolo merged it already. Thanks Paolo!

> 
> > > After commit 812c1057f6175ac9a9829fa2920a2b5783814193 (Handle G_IO_HUP
> > > in tcp_chr_read for tcp chardev), connections are disconnected when in
> > > G_IO_HUP condition.
> > >
> > > However, it's possible that there is still data for reading in the 
> > > channel.
> > > In that case, the remaining data is not handled.
> > >
> > > I saw a related bug when running socat in write-only mode, after
> > >
> > >   $ echo "quit" | socat -u - UNIX-CONNECT:qemu-monitor
> > >
> > > the monitor won't not run the 'quit' command.
> > >
> > > Instead of GIOCondition, this patch uses the return value of 
> > > tcp_chr_recv()
> > > to check the state of connection as suggested by Kirill.
> > >
> > > Cc: Kirill Batuzov 
> > > Cc: Nikolay Nikolaev 
> > > Cc: Markus Armbruster 
> > > Cc: Anthony Liguori 
> > > Signed-off-by: Zifei Tong 
> > > ---
> > > Changes in v3: handle EWOULDBLOCK, remove inaccurate comment
> > >
> > >  qemu-char.c | 10 ++
> > >  1 file changed, 2 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/qemu-char.c b/qemu-char.c
> > > index 2a3cb9f..d1893a0 100644
> > > --- a/qemu-char.c
> > > +++ b/qemu-char.c
> > > @@ -2692,12 +2692,6 @@ static gboolean tcp_chr_read(GIOChannel *chan, 
> > > GIOCondition cond, void *opaque)
> > >  uint8_t buf[READ_BUF_LEN];
> > >  int len, size;
> > >  
> > > -if (cond & G_IO_HUP) {
> > > -/* connection closed */
> > > -tcp_chr_disconnect(chr);
> > > -return TRUE;
> > > -}
> > > -
> > >  if (!s->connected || s->max_size <= 0) {
> > >  return TRUE;
> > >  }
> > > @@ -2705,8 +2699,8 @@ static gboolean tcp_chr_read(GIOChannel *chan, 
> > > GIOCondition cond, void *opaque)
> > >  if (len > s->max_size)
> > >  len = s->max_size;
> > >  size = tcp_chr_recv(chr, (void *)buf, len);
> > > -if (size == 0) {
> > > -/* connection closed */
> > > +if (size == 0 ||
> > > +(size < 0 && !(errno == EAGAIN || errno == EWOULDBLOCK || errno 
> > > == EINTR))) {
> > >  tcp_chr_disconnect(chr);
> > >  } else if (size > 0) {
> > >  if (s->do_telnetopt)

Re: [Qemu-devel] [PATCH v2 2/2] target-i386: move asm-x86/hyperv.h to standard-headers

[Cornelia Huck]

On Thu, 10 Sep 2015 10:42:31 +0300
"Michael S. Tsirkin"  wrote:

> On Wed, Sep 09, 2015 at 06:34:01PM +0200, Paolo Bonzini wrote:
> > The Hyper-V definitions are an industry standard and can be used
> > from code that is not KVM-specific.
> > 
> > The changes to scripts/update-linux-headers.sh are required because there
> > is both an asm-x86/hyperv.h and a linux/hyperv.h file.  linux/hyperv.h
> > introduces dependencies on additional Linux uapi headers, so we only
> > want the former.
> > 
> > The solution is to make cp_virtio (now renamed to cp_portable) copy
> > one file only, instead of using the "find" command, and call it multiple
> > times.  The new function is really just a reindentation of the old one.
> > 
> > Signed-off-by: Paolo Bonzini 
> 
> I'd rather see a script update, then result of running it
> in a separate patch.
> 
> > ---
> >  .../standard-headers}/asm-x86/hyperv.h|  10 +-
> >  linux-headers/asm-x86/hyperv.h| 253 
> > +-
> >  scripts/update-linux-headers.sh   |  79 +-
> >  target-i386/kvm.c |   2 +-
> >  4 files changed, 52 insertions(+), 295 deletions(-)
> >  copy {linux-headers => include/standard-headers}/asm-x86/hyperv.h (98%)

> > diff --git a/scripts/update-linux-headers.sh 
> > b/scripts/update-linux-headers.sh
> > index 7f7b592..2f25e84 100755
> > --- a/scripts/update-linux-headers.sh
> > +++ b/scripts/update-linux-headers.sh
> > @@ -28,39 +28,32 @@ if [ -z "$output" ]; then
> >  output="$PWD"
> >  fi
> >  
> > -cp_virtio() {
> > -from=$1
> > +cp_portable() {
> > +f=$1
> >  to=$2
> > -virtio=$(find "$from" -name '*virtio*h' -o -name "input.h" -o -name 
> > "pci_regs.h")
> > -if [ "$virtio" ]; then
> > -rm -rf "$to"
> > -mkdir -p "$to"
> > -for f in $virtio; do
> > -if
> > -grep '#include' "$f" | grep -v -e 'linux/virtio' \
> > - -e 'linux/types' \
> > - -e 'stdint' \
> > - -e 'linux/if_ether' \
> > - -e 'sys/' \
> > - > /dev/null
> > -then
> > -echo "Unexpected #include in input file $f".
> > -exit 2
> > -fi
> > -
> > -header=$(basename "$f");
> > -sed -e 's/__u\([0-9][0-9]*\)/uint\1_t/g' \
> > --e 's/__s\([0-9][0-9]*\)/int\1_t/g' \
> > --e 's/__le\([0-9][0-9]*\)/uint\1_t/g' \
> > --e 's/__be\([0-9][0-9]*\)/uint\1_t/g' \
> > --e 's/]*\)>/"standard-headers\/linux\/\1"/' \
> > --e 's/__bitwise__//' \
> > --e 's/__attribute__((packed))/QEMU_PACKED/' \
> > --e 's/__inline__/inline/' \
> > --e '/sys\/ioctl.h/d' \
> > -"$f" > "$to/$header";
> > -done
> > +if
> > +grep '#include' "$f" | grep -v -e 'linux/virtio' \
> > + -e 'linux/types' \
> > + -e 'stdint' \
> > + -e 'linux/if_ether' \
> > + -e 'sys/' \
> > + > /dev/null
> > +then
> > +echo "Unexpected #include in input file $f".
> > +exit 2
> >  fi
> > +
> > +header=$(basename "$f");
> > +sed -e 's/__u\([0-9][0-9]*\)/uint\1_t/g' \
> > +-e 's/__s\([0-9][0-9]*\)/int\1_t/g' \
> > +-e 's/__le\([0-9][0-9]*\)/uint\1_t/g' \
> > +-e 's/__be\([0-9][0-9]*\)/uint\1_t/g' \
> > +-e 's/]*\)>/"standard-headers\/linux\/\1"/' \
> > +-e 's/__bitwise__//' \
> > +-e 's/__attribute__((packed))/QEMU_PACKED/' \
> > +-e 's/__inline__/inline/' \
> > +-e '/sys\/ioctl.h/d' \
> > +"$f" > "$to/$header";
> >  }
> >  
> >  # This will pick up non-directories too (eg "Kconfig") but we will
> > @@ -68,6 +61,7 @@ cp_virtio() {
> >  ARCHLIST=$(cd "$linux/arch" && echo *)
> >  
> >  for arch in $ARCHLIST; do
> > +
> >  # Discard anything which isn't a KVM-supporting architecture
> >  if ! [ -e "$linux/arch/$arch/include/asm/kvm.h" ] &&
> >  ! [ -e "$linux/arch/$arch/include/uapi/asm/kvm.h" ] ; then
> 
> This empty line looks ugly imho.
> 
> > @@ -86,14 +80,19 @@ for arch in $ARCHLIST; do
> >  for header in kvm.h kvm_para.h; do
> >  cp "$tmpdir/include/asm/$header" "$output/linux-headers/asm-$arch"
> >  done
> > -if [ $arch = x86 ]; then
> > -cp "$tmpdir/include/asm/hyperv.h" "$output/linux-headers/asm-x86"
> > -fi
> >  if [ $arch = powerpc ]; then
> >  cp "$tmpdir/include/asm/epapr_hcalls.h" 
> > "$output/linux-headers/asm-powerpc/"
> >  fi
> >  
> > -cp_virtio "$tmpdir/include/asm" 
> > "$output/include/stand

Re: [Qemu-devel] [PATCH 1/2] ACPI: Add definitions for the DBG2 table

[Michael S. Tsirkin]

On Mon, Sep 07, 2015 at 05:51:50PM +0200, Andrew Jones wrote:
> On Mon, Sep 07, 2015 at 03:23:45PM +0100, Leif Lindholm wrote:
> > The DBG2 table can be considered a "companion" to SPCR - it points out
> > debug consoles available in the system.
> > 
> > Signed-off-by: Leif Lindholm 
> > ---
> >  include/hw/acpi/acpi-defs.h | 37 +++--
> >  1 file changed, 35 insertions(+), 2 deletions(-)
> > 
> > diff --git a/include/hw/acpi/acpi-defs.h b/include/hw/acpi/acpi-defs.h
> > index 2b431e6..af062a7 100644
> > --- a/include/hw/acpi/acpi-defs.h
> > +++ b/include/hw/acpi/acpi-defs.h
> > @@ -197,10 +197,43 @@ enum {
> >  };
> >  
> >  /*
> > - * Serial Port Console Redirection Table (SPCR), Rev. 1.02
> > + * Debug Port Table 2 (DBG2)
> >   *
> >   * For .interface_type see Debug Port Table 2 (DBG2) serial port
> > - * subtypes in Table 3, Rev. May 22, 2012
> > + * subtypes in Table 3, Rev. Aug 10, 2015
> > + *
> > + * The specification permits multiple ports with multiple addresses, but 
> > this
> > + * implementation is limited to one port with one address.
> > + */
> > +struct AcpiDebugPort2 {
> > +ACPI_TABLE_HEADER_DEF
> > +uint32_t debug_devices_offset;
> > +uint32_t number_debug_devices;
> > +struct {
> > +  uint8_t  revision;
> > +  uint16_t length;
> > +  uint8_t  number_generic_address_registers;
> > +  uint16_t namespace_string_length;
> > +  uint16_t namespace_string_offset;
> > +  uint16_t oem_data_length;
> > +  uint16_t oem_data_offset;
> > +  uint16_t port_type;
> > +  uint16_t port_subtype;
> > +  uint8_t  reserved1[2];
> > +  uint16_t base_address_register_offset;
> > +  uint16_t address_size_offset;
> > +  struct AcpiGenericAddress base_address[1];
> 
> Not sure we want to limit the number of addresses. Non ARM (non PL011)
> users of this table may not find one address sufficient.
> 
> > +  uint32_t address_size[1];
> > +  uint8_t  namespace_string[2];
> > +} QEMU_PACKED debug_devices[1];
> 
> I'm guessing it's unlikely we'll ever want more than one debug port. So
> can we just drop the debug_devices array, flatting the table? OTOH, this
> is generic acpi table generation code here, and maybe x86 will want to
> use more than one port? In that case we should pull the debug device
> structure definition out, and then properly handle the variable length
> array. But this is where Igor and mst will suggest just using aml_appends,
> instead of defining these structures at all :-)

Yes - structures are fine when they are static, but for dynamic
stuff, aml_append wins hands down.
You simply add comments in code documenting each field as
it's added.




Igor actually likes aml_append for static things as well
but it's a matter of taste.

> > +} QEMU_PACKED;
> > +typedef struct AcpiDebugPort2
> > +   AcpiDebugPort2;
> > +
> > +/*
> > + * Serial Port Console Redirection Table (SPCR), Rev. 1.03
> > + *
> > + * .interface_type format same as for DBG2.
> >   */
> >  struct AcpiSerialPortConsoleRedirection {
> >  ACPI_TABLE_HEADER_DEF
> > -- 
> > 2.1.4
> > 

Re: [Qemu-devel] [PATCH 1/5] add QEMU style defines for __sync_add_and_fetch

[Stefan Hajnoczi]

On Tue, Sep 08, 2015 at 11:00:24AM +0300, Denis V. Lunev wrote:
> From: Raushaniya Maksudova 
> 
> Signed-off-by: Raushaniya Maksudova 
> Signed-off-by: Denis V. Lunev 
> CC: Stefan Hajnoczi 
> CC: Kevin Wolf 
> CC: Paolo Bonzini 
> ---
>  include/qemu/atomic.h | 3 +++
>  1 file changed, 3 insertions(+)

Reviewed-by: Stefan Hajnoczi 

Re: [Qemu-devel] [PATCH v2] linux-user/main.c: Set environments variables from command line options

[Chen Gang]

Oh, very sorry! The patch v2 did not process simple options (e.g. -strace).

I should send patch v3 for it.

Thanks.


> From: gang.chen.5...@gmail.com
> To: riku.voi...@iki.fi
> CC: r...@twiddle.net; peter.mayd...@linaro.org; xili_gchen_5...@hotmail.com; 
> qemu-devel@nongnu.org; gang.chen.5...@gmail.com
> Subject: [PATCH v2] linux-user/main.c: Set environments variables from 
> command line options
> Date: Thu, 10 Sep 2015 16:10:22 +0800
>
> From: Chen Gang 
>
> When qemu execute execve() system call, the related command line options
> can not be passed to the second qemu process, which causes the second
> process fail.
>
> Signed-off-by: Chen Gang 
> ---
> linux-user/main.c | 4 
> 1 file changed, 4 insertions(+)
>
> diff --git a/linux-user/main.c b/linux-user/main.c
> index 06dd296..f1f5496 100644
> --- a/linux-user/main.c
> +++ b/linux-user/main.c
> @@ -3767,6 +3767,7 @@ static void usage(void)
> static int parse_args(int argc, char **argv)
> {
> const char *r;
> + char *buf;
> int optind;
> const struct qemu_argument *arginfo;
>
> @@ -3802,6 +3803,9 @@ static int parse_args(int argc, char **argv)
> if (optind>= argc) {
> usage();
> }
> + buf = g_strdup_printf("%s=%s", arginfo->env, argv[optind]);
> + (void) envlist_setenv(envlist, buf);
> + g_free(buf);
> arginfo->handle_opt(argv[optind]);
> optind++;
> } else {
> --
> 1.9.1
>
>
  

[Qemu-devel] [PATCH v3] linux-user/main.c: Set environments variables from command line options

[gang . chen . 5i5j]

From: Chen Gang 

When qemu execute execve() system call, the related command line options
can not be passed to the second qemu process, which causes the second
process fail.

Signed-off-by: Chen Gang 
---
 linux-user/main.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/linux-user/main.c b/linux-user/main.c
index 06dd296..dfbccbe 100644
--- a/linux-user/main.c
+++ b/linux-user/main.c
@@ -3767,6 +3767,7 @@ static void usage(void)
 static int parse_args(int argc, char **argv)
 {
 const char *r;
+char *buf;
 int optind;
 const struct qemu_argument *arginfo;
 
@@ -3802,11 +3803,15 @@ static int parse_args(int argc, char **argv)
 if (optind >= argc) {
 usage();
 }
+buf = g_strdup_printf("%s=%s", arginfo->env, argv[optind]);
 arginfo->handle_opt(argv[optind]);
 optind++;
 } else {
+buf = g_strdup_printf("%s=", arginfo->env);
 arginfo->handle_opt(NULL);
 }
+(void) envlist_setenv(envlist, buf);
+g_free(buf);
 break;
 }
 }
-- 
1.9.1

Re: [Qemu-devel] [PATCH 1/3] monitor: split MonitorQAPIEventState

[Daniel P. Berrange]

On Wed, Sep 02, 2015 at 01:09:41PM +0200, marcandre.lur...@redhat.com wrote:
> From: Marc-André Lureau 
> 
> Create a separate pending event structure MonitorQAPIEventPending.
> Use a MonitorQAPIEventDelay callback to handle the delaying. This
> allows other implementations of throttling.
> 
> Signed-off-by: Marc-André Lureau 
> ---
>  monitor.c| 124 
> +--
>  trace-events |   2 +-
>  2 files changed, 79 insertions(+), 47 deletions(-)

Reviewed-by: Daniel P. Berrange 


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

Re: [Qemu-devel] [PATCH 2/3] monitor: throttle QAPI_EVENT_VSERPORT_CHANGE by "id"

[Daniel P. Berrange]

On Wed, Sep 02, 2015 at 01:09:42PM +0200, marcandre.lur...@redhat.com wrote:
> From: Marc-André Lureau 
> 
> Use a hash table to lookup the pending event corresponding to the "id"
> field. The hash table may grow without limit here, the following patch
> will add some cleaning.
> 
> Signed-off-by: Marc-André Lureau 
> Reviewed-by: Eric Blake 
> ---
>  monitor.c | 104 
> ++
>  1 file changed, 78 insertions(+), 26 deletions(-)

Reviewed-by: Daniel P. Berrange 


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

Re: [Qemu-devel] [PATCH 3/3] monitor: remove old entries from event hash table

[Daniel P. Berrange]

On Wed, Sep 02, 2015 at 01:09:43PM +0200, marcandre.lur...@redhat.com wrote:
> From: Marc-André Lureau 
> 
> Do not let the hash table grow without limit, schedule a cleanup for
> outdated event.
> 
> Signed-off-by: Marc-André Lureau 
> ---
>  monitor.c | 47 ++-
>  1 file changed, 46 insertions(+), 1 deletion(-)

Reviewed-by: Daniel P. Berrange 

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

Re: [Qemu-devel] [RFC PATCH] spapr: Reduce creation of LMB DR connectors from O(n^3) to O(n^2)

[Peter Crosthwaite]

On Wed, Sep 9, 2015 at 11:28 PM, David Gibson
 wrote:
> The dynamic reconfiguration (hotplug) code for the pseries machine type
> uses a "DR connector" QOM object for each resource it will be possible
> to hotplug.  Each of these is added to its owner using
> object_property_add_child(owner, "dr-connector[*], ...);
>

> This works ok for most cases, but gets ugly when allowing large amounts of
> hotplugged RAM.  For RAM, there's a DR connector object for every 256MB of
> potential memory.  So if maxmem=2T, for example, there are >250,000 objects
> under the same parent.
>
> The QOM interfaces aren't really designed for this.  In particular
> object_property_add() has O(n^2) time complexity (in the number of existing
> children) for the [*] case.  First it has a linear search through array
> indices to find a free slot, each of which is attempted to a recursive call
> to object_property_add() with a specific [N].  Those calls are O(n) because
> there's a linear search through all properties to check for duplicates.
>

Does this help? I think it's already queued:

http://lists.nongnu.org/archive/html/qemu-devel/2015-07/msg05790.html

Regards,
Peter

> For the specific case of DR connectors, we already have a sufficiently
> unique index, so we don't need to use the [*] special behaviour.  That lets
> us reduce the total time for creating the DR objects from O(n^3) to O(n^2).
>
> O(n^2) is still kind of crappy, but it's enough to reduce the startup time
> of qemu with maxmem=2T from ~20 minutes to ~4 seconds.
>
> Signed-off-by: David Gibson 
> Cc: Bharata B Rao 
> ---
>  hw/ppc/spapr_drc.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/hw/ppc/spapr_drc.c b/hw/ppc/spapr_drc.c
> index c1f664f..4cf3a9b 100644
> --- a/hw/ppc/spapr_drc.c
> +++ b/hw/ppc/spapr_drc.c
> @@ -463,14 +463,16 @@ sPAPRDRConnector *spapr_dr_connector_new(Object *owner,
>  {
>  sPAPRDRConnector *drc =
>  SPAPR_DR_CONNECTOR(object_new(TYPE_SPAPR_DR_CONNECTOR));
> +char *prop_name = g_strdup_printf("dr-connector[%"PRIu32"]", id);
>
>  g_assert(type);
>
>  drc->type = type;
>  drc->id = id;
>  drc->owner = owner;
> -object_property_add_child(owner, "dr-connector[*]", OBJECT(drc), NULL);
> +object_property_add_child(owner, prop_name, OBJECT(drc), NULL);
>  object_property_set_bool(OBJECT(drc), true, "realized", NULL);
> +g_free(prop_name);
>
>  /* human-readable name for a DRC to encode into the DT
>   * description. this is mainly only used within a guest in place
> --
> 2.4.3
>
>

Re: [Qemu-devel] [PATCH 2/5] disk_deadlines: add request to resume Virtual Machine

[Stefan Hajnoczi]

On Tue, Sep 08, 2015 at 11:00:25AM +0300, Denis V. Lunev wrote:
> From: Raushaniya Maksudova 
> 
> In some cases one needs to pause and resume a Virtual Machine from inside
> of Qemu. Currently there are request functions to pause VM (vmstop), but
> there are no respective ones to resume VM.
> 
> Signed-off-by: Raushaniya Maksudova 
> Signed-off-by: Denis V. Lunev 
> CC: Stefan Hajnoczi 
> CC: Kevin Wolf 
> CC: Paolo Bonzini 
> ---
>  include/sysemu/sysemu.h |  1 +
>  stubs/vm-stop.c |  5 +
>  vl.c| 18 ++
>  3 files changed, 24 insertions(+)

Why can't vm_start() be used?

> diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h
> index 44570d1..a382ae1 100644
> --- a/include/sysemu/sysemu.h
> +++ b/include/sysemu/sysemu.h
> @@ -62,6 +62,7 @@ void qemu_system_shutdown_request(void);
>  void qemu_system_powerdown_request(void);
>  void qemu_register_powerdown_notifier(Notifier *notifier);
>  void qemu_system_debug_request(void);
> +void qemu_system_vmstart_request(void);
>  void qemu_system_vmstop_request(RunState reason);
>  void qemu_system_vmstop_request_prepare(void);
>  int qemu_shutdown_requested_get(void);
> diff --git a/stubs/vm-stop.c b/stubs/vm-stop.c
> index 69fd86b..c8e2cdd 100644
> --- a/stubs/vm-stop.c
> +++ b/stubs/vm-stop.c
> @@ -10,3 +10,8 @@ void qemu_system_vmstop_request(RunState state)
>  {
>  abort();
>  }
> +
> +void qemu_system_vmstart_request(void)
> +{
> +abort();
> +}
> diff --git a/vl.c b/vl.c
> index 584ca88..63f10d3 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -563,6 +563,7 @@ static RunState current_run_state = RUN_STATE_PRELAUNCH;
>  /* We use RUN_STATE_MAX but any invalid value will do */
>  static RunState vmstop_requested = RUN_STATE_MAX;
>  static QemuMutex vmstop_lock;
> +static bool vmstart_requested;
>  
>  typedef struct {
>  RunState from;
> @@ -723,6 +724,19 @@ void qemu_system_vmstop_request(RunState state)
>  qemu_notify_event();
>  }
>  
> +static bool qemu_vmstart_requested(void)
> +{
> +bool r = vmstart_requested;
> +vmstart_requested = false;
> +return r;
> +}
> +
> +void qemu_system_vmstart_request(void)
> +{
> +vmstart_requested = true;
> +qemu_notify_event();
> +}
> +
>  void vm_start(void)
>  {
>  RunState requested;
> @@ -1884,6 +1898,10 @@ static bool main_loop_should_exit(void)
>  if (qemu_vmstop_requested(&r)) {
>  vm_stop(r);
>  }
> +if (qemu_vmstart_requested()) {
> +vm_start();
> +}
> +
>  return false;
>  }
>  
> -- 
> 2.1.4
> 
> 

Re: [Qemu-devel] Confused by QOM: /machine/unattached/device[5]/dr-connector[255]/fdt

[Markus Armbruster]

TL;DR: Andreas, there's one question specifically for you, search for
"QOM:".

Andreas Färber  writes:

> Am 09.09.2015 um 17:22 schrieb Markus Armbruster:
>> Andreas Färber  writes:
>>> Am 09.09.2015 um 16:38 schrieb Markus Armbruster:
 I ran into this:

 $ qemu-system-ppc64 -nodefaults -S -display none -monitor stdio
 -machine pseries-2.4
 QEMU 2.4.50 monitor - type 'help' for more information
 (qemu) qom-list /machine/unattached/device[5]/dr-connector[255]
 fdt (struct)
 entity-sense (uint32)
 name (string)
 connector_type (uint32)
 index (uint32)
 id (uint32)
 allocation-state (uint32)
 indicator-state (uint32)
 isolation-state (uint32)
 parent_bus (link)
 hotplugged (bool)
 hotpluggable (bool)
 realized (bool)
 type (string)
 (qemu) qom-list /machine/unattached/device[5]/dr-connector[255]/fdt
 Device '/machine/unattached/device[5]/dr-connector[255]/fdt' not found

 According to the first qom-list, .../fdt exists.  According to the
 second, it doesn't.
>>>
>>> Actually this is fully expected: qom-list operates on QOM objects. The
>>> fdt property returns a struct, which is considered a value QOM-wise, so
>>> to read it you need to use qom-get, not qom-list.
>>>
>>> Now, it may well be that visiting a struct does not work as expected, I
>>> remember we ran into issues there, that held up the qom-tree stuff...
>> 
>> Okay, switching to QMP, because there's no qom-get in HMP (is that
>> intentional?).
>> 
>> QMP> { "execute": "qom-list", "arguments": { "path":
>> QMP> "/machine/unattached/device[5]/dr-connector[255]" } }
>> {"return": [{"name": "fdt", "type": "struct"}, {"name":
>> "entity-sense", "type": "uint32"}, {"name": "name", "type":
>> "string"}, {"name": "connector_type", "type": "uint32"}, {"name":
>> "index", "type": "uint32"}, {"name": "id", "type": "uint32"},
>> {"name": "allocation-state", "type": "uint32"}, {"name":
>> "indicator-state", "type": "uint32"}, {"name": "isolation-state",
>> "type": "uint32"}, {"name": "parent_bus", "type": "link"},
>> {"name": "hotplugged", "type": "bool"}, {"name": "hotpluggable",
>> "type": "bool"}, {"name": "realized", "type": "bool"}, {"name":
>> "type", "type": "string"}]}
>> QMP> { "execute": "qom-list", "arguments": { "path":
>> QMP> "/machine/unattached/device[5]/dr-connector[255]/fdt" } }
>> {"error": {"class": "DeviceNotFound", "desc": "Device
>> '/machine/unattached/device[5]/dr-connector[255]/fdt' not found"}}
>> 
>> Should qom-list really fail DeviceNotFound?  I find it rather confusing.
>> For what it's worth, attempting to read a directory fails with EISDIR,
>> not ENOENT.
>
> Listing a non-existing directory on my system results in:
>
>   ls: cannot access foo: No such file or directory

As Paolo remarked, we're listing an existing non-directory here, which
fails ENOTDIR.  I used the wrong example (file-only op on directory
instead of directory-only op on file).

> As for the DeviceNotFound, I merely implemented the HMP glue, so you
> should rather direct such questions at Eric or Luiz (or Anthony).
> I believe that an ObjectNotFound is out of the question, as any new code
> would just use the Generic class.

Yes.

My (badly worded) question was about the misleading error *message*.  I
don't care for the error *class*.

>> 
>> Moving on to my next confusion: qom-get.
>> 
>> QMP> { "execute": "qom-get", "arguments": { "path":
>> QMP> "/machine/unattached/device[5]/dr-connector[255]",
>> QMP> "property": "fdt" } }
>> {"return": {}}
>> 
>> The return value {} is weird.  Let's see where it comes from.
>> 
>> qmp_qom_get() first calls object_resolve_path() on the path, then
>> object_property_get_qobject() on the property.  For our test case,
>> object_resolve_path() succeeds.  Now have a closer look at
>> object_property_get_qobject()'s behavior:
>> 
>> QObject *object_property_get_qobject(Object *obj, const char *name,
>>  Error **errp)
>> {
>> QObject *ret = NULL;
>> Error *local_err = NULL;
>> QmpOutputVisitor *mo;
>> 
>> mo = qmp_output_visitor_new();
>> object_property_get(obj, qmp_output_get_visitor(mo), name, 
>> &local_err);
>> 
>> This call succeeds, and we enter the conditional.
>> 
>> if (!local_err) {
>> ret = qmp_output_get_qobject(mo);
>> 
>> This call returns NULL.
>> 
>> }
>> error_propagate(errp, local_err);
>> 
>> This sets *errp = NULL.
>> 
>> qmp_output_visitor_cleanup(mo);
>> return ret;
>> }
>> 
>> Function returns NULL without setting an error.  Its function comment:
>> 
>> /*
>>  * object_property_get_qobject:
>>  * @obj: the object
>>  * @name: the name of the property
>>  * @errp: returns an error if this function fails
>>  *
>>  * Returns: the value of the property, con

Re: [Qemu-devel] [PULL 0/19] xen-2015-09-08-tag

[Peter Maydell]

On 10 September 2015 at 02:21, Chen, Tiejun  wrote:
> On 9/10/2015 12:10 AM, Stefano Stabellini wrote:
>> I found another issue introduced by the gfx passthrough series on
>> Windows:
>>
>> ../hw/pci-host/piix.o: In function `host_pci_config_read':
>> /root/qemu/hw/pci-host/piix.c:778: undefined reference to `_pread'
>>
>> It is introduced by:
>>
>> commit fdb70721ba0496a767137e5505dd27627d19c4a8
>> Author: Tiejun Chen 
>> Date:   Wed Jul 15 13:37:43 2015 +0800
>>
>>  piix: create host bridge to passthrough
>>
>>
>> You might have to replace the pread call with lseek and read.
>>
>
> This is also surprising to me. Just see xen_host_pci_config_() inside
> /hw/xen/xen-host-pci-device.c, there are so many this pread usage(). So I
> really don't understand what's difference between these two files.

xen-host-pci-device.c is only compiled if CONFIG_XEN_PCI_PASSTHROUGH
was set by configure. That won't be the case on OSX or Windows, where
the Xen headers don't exist.

thanks
-- PMM

Re: [Qemu-devel] [PULL 0/19] xen-2015-09-08-tag

[Peter Maydell]

On 10 September 2015 at 02:12, Chen, Tiejun  wrote:
> On 9/9/2015 9:06 PM, Stefano Stabellini wrote:
>>
>> On Tue, 8 Sep 2015, Peter Maydell wrote:
>>>
>>> On 8 September 2015 at 18:21, Stefano Stabellini
>>>  wrote:
>>> > The following changes since commit
>>> > 8611280505119e296757a60711a881341603fa5a:
>>> >
>>> >   target-microblaze: Use setcond for pcmp* (2015-09-08 08:49:33 +0200)
>>> >
>>> > are available in the git repository at:
>>> >
>>> >   git://xenbits.xen.org/people/sstabellini/qemu-dm.git
>>> > tags/xen-2015-09-08-tag
>>> >
>>> > for you to fetch changes up to
>>> > ba2250ad148997b1352aba976aac66b55410e7e4:
>>> >
>>> >   xen/pt: Use XEN_PT_LOG properly to guard against compiler warnings.
>>> > (2015-09-08 15:21:56 +)
>>> >
>>> > 
>>> > Xen branch xen-2015-09-08
>>> >
>>> > 
>>>
>>> Hi. I'm afraid this fails to build on OSX (and probably Windows too,
>>> though that build hasn't run yet):
>>>
>>>   CCi386-softmmu/hw/i386/pci-assign-load-rom.o
>>> /Users/pm215/src/qemu/hw/i386/pci-assign-load-rom.c:6:10: fatal error:
>>>   'sys/io.h' file not found
>>> #include 
>>>  ^
>>>   CCalpha-softmmu/hw/alpha/pci.o
>>> 1 error generated.
>>
>>
>> Tiejun,
>>
>> this is caused by 33d33242b7d802e6c994f3d56ecba96a66465dc3,
>> "hw/pci-assign: split pci-assign.c". Could you please double-check
>> non-Linux builds?
>
>
> Its interesting.
>
> As you see this short log, "hw/pci-assign: split pci-assign.c", so this
> means I just extract something from the original hw/i386/kvm/pci-assign.c,
> and here so I just keep those original head files residing
> hw/i386/kvm/pci-assign.c, and I didn't introduce anything new.

hw/i386/kvm/pci-assign.c is only built if configure set CONFIG_KVM,
which it won't do on Windows or OSX builds.

It sounds like your patch has incorrectly moved code out of files
which are compiled only if KVM is present, or only if we're doing
Xen PCI passthrough, and into compiled-for-everything files.

> So its very probably that you still can't compile successfully even without
> my commit on OSX/Windows, right?

OSX and Windows build fine on master at the moment; I check this
for every pull request.

thanks
-- PMM

Re: [Qemu-devel] qmp_device_add() ret_data argument

[Markus Armbruster]

Programmingkid  writes:

> What does the function qmp_device_add() have a ret_data argument if it
> isn't used? This function is located in qdev-monitor.c.

QMP command handlers all implement the same interface:

void (*cmd_new)(QDict *params, QObject **ret_data, Error **errp);

Handlers of commands returning a value store the value to *ret_data.
Handlers of commands not returning a value (such as device_add) leave
ret_data alone.

We could require them to store NULL, but that would be easy to forget,
and usually catastrophic, so we don't.

Re: [Qemu-devel] [PATCH] linux-user/main.c: Always set QEMU_LD_PREFIX when interp_prefix is changed

[Peter Maydell]

On 10 September 2015 at 06:43,   wrote:
> From: Chen Gang 
>
> If qemu sets interp_prfix via command line '-L' instead of environments
> variable QEMU_LD_PREFIX, it will cause syscall execve() failed. Because
> the 2nd qemu has no command line '-L'.
>
> So qemu need always set QEMU_LD_PREFIX when interp_prefix is changed.

I think this is user error. If you want exec to work automatically
onto a second QEMU then you need to set up binfmt misc with a
wrapper and probably the environment variables. I don't
think we need to turn all our command line switches into
environment variables: they're not supposed to be somehow
magically inherited by child QEMU processes.

thanks
-- PMM

Re: [Qemu-devel] [PATCH 1/4] virtio: ring sizes vs. reset

[Michael S. Tsirkin]

On Fri, Sep 04, 2015 at 10:54:26AM +0200, Cornelia Huck wrote:
> We allow guests to change the size of the virtqueue rings by supplying
> a number of buffers that is different from the number of buffers the
> device was initialized with. Current code has some problems, however,
> since reset does not reset the ringsizes to the default values (as this
> is not saved anywhere).
> 
> Let's extend the core code to keep track of the default ringsizes and
> migrate them once the guest changed them for any of the virtqueues
> for a device.
> 
> Signed-off-by: Cornelia Huck 
> ---
>  hw/virtio/virtio.c | 63 
> ++
>  include/hw/virtio/virtio.h |  1 +
>  2 files changed, 64 insertions(+)
> 
> diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
> index 788b556..687116e 100644
> --- a/hw/virtio/virtio.c
> +++ b/hw/virtio/virtio.c
> @@ -60,6 +60,7 @@ typedef struct VRingUsed
>  typedef struct VRing
>  {
>  unsigned int num;
> +unsigned int num_default;
>  unsigned int align;
>  hwaddr desc;
>  hwaddr avail;
> @@ -633,7 +634,9 @@ void virtio_reset(void *opaque)
>  vdev->vq[i].signalled_used = 0;
>  vdev->vq[i].signalled_used_valid = false;
>  vdev->vq[i].notification = true;
> +vdev->vq[i].vring.num = vdev->vq[i].vring.num_default;
>  }
> +vdev->non_default_ringsizes = false;
>  }
>  
>  uint32_t virtio_config_readb(VirtIODevice *vdev, uint32_t addr)
> @@ -855,6 +858,10 @@ void virtio_queue_set_num(VirtIODevice *vdev, int n, int 
> num)
>  return;
>  }
>  vdev->vq[n].vring.num = num;
> +if (num != vdev->vq[n].vring.num_default) {
> +/* save ringsizes once one of them has been changed */
> +vdev->non_default_ringsizes = true;
> +}
>  }
>  
>  VirtQueue *virtio_vector_first_queue(VirtIODevice *vdev, uint16_t vector)
> @@ -964,6 +971,7 @@ VirtQueue *virtio_add_queue(VirtIODevice *vdev, int 
> queue_size,
>  abort();
>  
>  vdev->vq[i].vring.num = queue_size;
> +vdev->vq[i].vring.num_default = queue_size;
>  vdev->vq[i].vring.align = VIRTIO_PCI_VRING_ALIGN;
>  vdev->vq[i].handle_output = handle_output;
>  
> @@ -977,6 +985,7 @@ void virtio_del_queue(VirtIODevice *vdev, int n)
>  }
>  
>  vdev->vq[n].vring.num = 0;
> +vdev->vq[n].vring.num_default = 0;
>  }
>  
>  void virtio_irq(VirtQueue *vq)
> @@ -1056,6 +1065,13 @@ static bool virtio_virtqueue_needed(void *opaque)
>  return virtio_host_has_feature(vdev, VIRTIO_F_VERSION_1);
>  }
>  
> +static bool virtio_ringsize_needed(void *opaque)
> +{
> +VirtIODevice *vdev = opaque;
> +
> +return vdev->non_default_ringsizes;
> +}
> +
>  static void put_virtqueue_state(QEMUFile *f, void *pv, size_t size)
>  {
>  VirtIODevice *vdev = pv;
> @@ -1104,6 +1120,52 @@ static const VMStateDescription 
> vmstate_virtio_virtqueues = {
>  }
>  };
>  
> +static void put_ringsize_state(QEMUFile *f, void *pv, size_t size)
> +{
> +VirtIODevice *vdev = pv;
> +int i;
> +
> +for (i = 0; i < VIRTIO_QUEUE_MAX; i++) {
> +qemu_put_be32(f, vdev->vq[i].vring.num_default);
> +}
> +}
> +
> +static int get_ringsize_state(QEMUFile *f, void *pv, size_t size)
> +{
> +VirtIODevice *vdev = pv;
> +int i;
> +
> +for (i = 0; i < VIRTIO_QUEUE_MAX; i++) {
> +vdev->vq[i].vring.num_default = qemu_get_be32(f);
> +}
> +return 0;
> +}
> +
> +static VMStateInfo vmstate_info_ringsize = {
> +.name = "ringsize_state",
> +.get = get_ringsize_state,
> +.put = put_ringsize_state,
> +};
> +
> +static const VMStateDescription vmstate_virtio_ringsize = {
> +.name = "virtio/ringsize",
> +.version_id = 1,
> +.minimum_version_id = 1,
> +.needed = &virtio_ringsize_needed,
> +.fields = (VMStateField[]) {
> +{
> +.name = "ringsize",
> +.version_id   = 0,
> +.field_exists = NULL,
> +.size = 0,
> +.info = &vmstate_info_ringsize,
> +.flags= VMS_SINGLE,
> +.offset   = 0,
> +},
> +VMSTATE_END_OF_LIST()
> +}
> +};
> +
>  static const VMStateDescription vmstate_virtio_device_endian = {
>  .name = "virtio/device_endian",
>  .version_id = 1,
> @@ -1138,6 +1200,7 @@ static const VMStateDescription vmstate_virtio = {
>  &vmstate_virtio_device_endian,
>  &vmstate_virtio_64bit_features,
>  &vmstate_virtio_virtqueues,
> +&vmstate_virtio_ringsize,
>  NULL
>  }
>  };
> diff --git a/include/hw/virtio/virtio.h b/include/hw/virtio/virtio.h
> index cccae89..29870c8 100644
> --- a/include/hw/virtio/virtio.h
> +++ b/include/hw/virtio/virtio.h
> @@ -90,6 +90,7 @@ struct VirtIODevice
>  VMChangeStateEntry *vmstate;
>  char *bus_name;
>  uint8_t device_endian;
> +bool non_default_ringsizes;


Let's not try to track this separately. Just go over
rings before migration

Re: [Qemu-devel] [PATCH 4/4] virtio-ccw: enable virtio-1

[Michael S. Tsirkin]

On Fri, Sep 04, 2015 at 10:54:29AM +0200, Cornelia Huck wrote:
> Let's enable revision 1 for virtio-ccw devices. We can always offer
> VERSION_1 as drivers in legacy mode won't be able to see it anyway.
> 
> We have to introduce a way to set a lower maximum revision for a device
> to accommodate the following cases:
> - compat machines (to enforce legacy only)

But you don't actually set this for any compat machines.
If you don't, this seems a bit pointless.

> - virtio-blk with scsi support (version 1 + scsi is fenced by common
>   code, with a user-configured max revision of 0 we can allow scsi
>   via not offering VERSION_1)

For this use, for pci users need to do disable_modern=true.
I find it unfortunate that for ccw one needs to do max_revision=0.

Revision numbers generally are a ccw specific concept. I'm not sure it
is wise to expose it to users.

> Signed-off-by: Cornelia Huck 
> ---
>  hw/s390x/s390-virtio-ccw.c |  4 
>  hw/s390x/virtio-ccw.c  | 30 --
>  hw/s390x/virtio-ccw.h  |  6 --
>  3 files changed, 36 insertions(+), 4 deletions(-)
> 
> diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
> index e2a26e9..fb6e45c 100644
> --- a/hw/s390x/s390-virtio-ccw.c
> +++ b/hw/s390x/s390-virtio-ccw.c
> @@ -287,6 +287,10 @@ static const TypeInfo ccw_machine_info = {
>  .driver   = TYPE_S390_SKEYS,\
>  .property = "migration-enabled",\
>  .value= "off",\
> +},{\
> +.driver = TYPE_VIRTIO_CCW_DEVICE,\
> +.property = "max_revision",\
> +.value = 0,\
>  },
>  
>  static void ccw_machine_2_4_class_init(ObjectClass *oc, void *data)
> diff --git a/hw/s390x/virtio-ccw.c b/hw/s390x/virtio-ccw.c
> index eed7b3e..fb103b7 100644
> --- a/hw/s390x/virtio-ccw.c
> +++ b/hw/s390x/virtio-ccw.c
> @@ -467,7 +467,13 @@ static int virtio_ccw_cb(SubchDev *sch, CCW1 ccw)
>  MEMTXATTRS_UNSPECIFIED,
>  NULL);
>  if (features.index == 0) {
> -features.features = (uint32_t)vdev->host_features;
> +if (dev->revision >= 1) {
> +/* Don't offer legacy features for modern devices. */
> +features.features = (uint32_t)
> +(vdev->host_features & ~VIRTIO_LEGACY_FEATURES);
> +} else {
> +features.features = (uint32_t)vdev->host_features;
> +}
>  } else if ((features.index == 1) && (dev->revision >= 1)) {
>  /*
>   * Only offer feature bits beyond 31 if the guest has
> @@ -768,7 +774,7 @@ static int virtio_ccw_cb(SubchDev *sch, CCW1 ccw)
>   * need to fetch it here. Nothing to do for now, though.
>   */
>  if (dev->revision >= 0 ||
> -revinfo.revision > virtio_ccw_rev_max(vdev)) {
> +revinfo.revision > virtio_ccw_rev_max(dev)) {
>  ret = -ENOSYS;
>  break;
>  }
> @@ -1541,6 +1547,10 @@ static void virtio_ccw_device_plugged(DeviceState *d, 
> Error **errp)
>  
>  sch->id.cu_model = virtio_bus_get_vdev_id(&dev->bus);
>  
> +if (dev->max_rev >= 1) {
> +virtio_add_feature(&vdev->host_features, VIRTIO_F_VERSION_1);
> +}
> +
>  css_generate_sch_crws(sch->cssid, sch->ssid, sch->schid,
>d->hotplugged, 1);
>  }
> @@ -1557,6 +1567,8 @@ static Property virtio_ccw_net_properties[] = {
>  DEFINE_PROP_STRING("devno", VirtioCcwDevice, bus_id),
>  DEFINE_PROP_BIT("ioeventfd", VirtioCcwDevice, flags,
>  VIRTIO_CCW_FLAG_USE_IOEVENTFD_BIT, true),
> +DEFINE_PROP_UINT32("max_revision", VirtioCcwDevice, max_rev,
> +   VIRTIO_CCW_MAX_REV),
>  DEFINE_PROP_END_OF_LIST(),
>  };
>  
> @@ -1584,6 +1596,8 @@ static Property virtio_ccw_blk_properties[] = {
>  DEFINE_PROP_STRING("devno", VirtioCcwDevice, bus_id),
>  DEFINE_PROP_BIT("ioeventfd", VirtioCcwDevice, flags,
>  VIRTIO_CCW_FLAG_USE_IOEVENTFD_BIT, true),
> +DEFINE_PROP_UINT32("max_revision", VirtioCcwDevice, max_rev,
> +   VIRTIO_CCW_MAX_REV),
>  DEFINE_PROP_END_OF_LIST(),
>  };
>  
> @@ -1611,6 +1625,8 @@ static Property virtio_ccw_serial_properties[] = {
>  DEFINE_PROP_STRING("devno", VirtioCcwDevice, bus_id),
>  DEFINE_PROP_BIT("ioeventfd", VirtioCcwDevice, flags,
>  VIRTIO_CCW_FLAG_USE_IOEVENTFD_BIT, true),
> +DEFINE_PROP_UINT32("max_revision", VirtioCcwDevice, max_rev,
> +   VIRTIO_CCW_MAX_REV),
>  DEFINE_PROP_END_OF_LIST(),
>  };
>  
> @@ -1638,6 +1654,8 @@ static Property virtio_ccw_balloon_properties[] = {
>  DEFINE_PROP_STRING("devno", VirtioCcwDevice, bus_id),
>  DEFINE_PROP_BIT("ioeventfd", VirtioCcwDevice, flags,
>  VIRTIO_CCW_FLAG_USE_IOEV

Re: [Qemu-devel] [edk2] EDK II & GPL - Re: OVMF BoF @ KVM Forum 2015

[Paolo Bonzini]

On 10/09/2015 08:57, Sharma Bhupesh wrote:
> So based on my limited understanding, can't the OVMF driver which
> uses features from some GPL based code, carry a dual license (GPL +
> x11 [MIT]),

No, that would require agreement from the original copyright holder,
which you are not going to get.

> like most device trees in Linux do now (including the
> Freescale ARMv8 DTS, see [1] for reference), thus allowing its usage 
> across both GPL and BSD based projects (like EDK2).
> 
> We already have examples of such dual-licensed code (libfdt) being
> used in BSD-licensed EDK2 (see [2] for details).

The dual BSD/GPL license is pointless, since you can already take
BSD-licensed code and distribute it under the GPL.  It just makes the
picture murkier without changing anything in practice.

Paolo

> In such a case we might not be required to create a separate GIT repo
> for the same.

Re: [Qemu-devel] [PATCH 3/5] disk_deadlines: add disk-deadlines option per drive

[Stefan Hajnoczi]

On Tue, Sep 08, 2015 at 11:00:26AM +0300, Denis V. Lunev wrote:
> diff --git a/blockdev.c b/blockdev.c
> index 6b48be6..6cd9c6e 100644
> --- a/blockdev.c
> +++ b/blockdev.c
> @@ -361,6 +361,7 @@ static BlockBackend *blockdev_init(const char *file, 
> QDict *bs_opts,
>  ThrottleConfig cfg;
>  int snapshot = 0;
>  bool copy_on_read;
> +bool disk_deadlines;
>  Error *error = NULL;
>  QemuOpts *opts;
>  const char *id;
> @@ -394,6 +395,11 @@ static BlockBackend *blockdev_init(const char *file, 
> QDict *bs_opts,
>  ro = qemu_opt_get_bool(opts, "read-only", 0);
>  copy_on_read = qemu_opt_get_bool(opts, "copy-on-read", false);
>  
> +disk_deadlines = qdict_get_try_bool(bs_opts, "disk-deadlines", false);
> +if (disk_deadlines) {
> +qdict_del(bs_opts, "disk-deadlines");

qdict_del() should be unconditional so that -drive disk-deadlines=off
works.  qdict_del() is a nop if the key cannot be found in the dict, so
it is always safe to call it.

> +}
> +
>  if ((buf = qemu_opt_get(opts, "discard")) != NULL) {
>  if (bdrv_parse_discard_flags(buf, &bdrv_flags) != 0) {
>  error_setg(errp, "invalid discard option");
> @@ -555,6 +561,8 @@ static BlockBackend *blockdev_init(const char *file, 
> QDict *bs_opts,
>  
>  bs->detect_zeroes = detect_zeroes;
>  
> +disk_deadlines_init(&bs->stats.disk_deadlines, disk_deadlines);
> +
>  bdrv_set_on_error(bs, on_read_error, on_write_error);
>  
>  /* disk I/O throttling */
> @@ -658,6 +666,10 @@ QemuOptsList qemu_legacy_drive_opts = {
>  .name = "file",
>  .type = QEMU_OPT_STRING,
>  .help = "file name",
> +},{
> +.name = "disk-deadlines",
> +.type = QEMU_OPT_BOOL,
> +.help = "control of disk requests' time execution",

It would be nice to mention that the guest will be paused:

"pause guest if disk request timeout expires"

> diff --git a/include/block/accounting.h b/include/block/accounting.h
> index 4c406cf..4e2b345 100644
> --- a/include/block/accounting.h
> +++ b/include/block/accounting.h
> @@ -27,6 +27,7 @@
>  #include 
>  
>  #include "qemu/typedefs.h"
> +#include "block/disk-deadlines.h"
>  
>  enum BlockAcctType {
>  BLOCK_ACCT_READ,
> @@ -41,6 +42,7 @@ typedef struct BlockAcctStats {
>  uint64_t total_time_ns[BLOCK_MAX_IOTYPE];
>  uint64_t merged[BLOCK_MAX_IOTYPE];
>  uint64_t wr_highest_sector;
> +DiskDeadlines disk_deadlines;

I'm not sure that BlockAcctStats is the most appropriate place for
DiskDeadlines.  BlockAcctStats holds accounting information which can be
queried on the QEMU monitor.  It is for reporting disk statistics.

Please add the DiskDeadlines field to BlockDriverState instead.

Re: [Qemu-devel] [PATCH v4 2/4] iotests: Add dependency info to groups list

[Fam Zheng]

On Wed, 09/09 12:35, John Snow wrote:
> Ping -- Fam?

Well, it's not a particularly interesting patch to review, but since you caught
me ...

> 
> On 08/25/2015 07:02 PM, John Snow wrote:
> > Add a few external dependency groups to the iotests groups list,
> > such as "qemu", "nbd", and "scm".
> > 
> > This will assist us in knowing which tests need to be re-run
> > when those dependencies are updated, or by helping us to avoid
> > tests that we know are broken for a certain file.
> > 
> > qemu-img and qemu-io are so ubiquitous that it's not worth
> > amending this information to the groups file.
> > 
> > Signed-off-by: John Snow 

Reviewed-by: Fam Zheng 

> > ---
> >  tests/qemu-iotests/group | 76 
> > +---
> >  1 file changed, 40 insertions(+), 36 deletions(-)
> > 
> > diff --git a/tests/qemu-iotests/group b/tests/qemu-iotests/group
> > index c430b6c..20866af 100644
> > --- a/tests/qemu-iotests/group
> > +++ b/tests/qemu-iotests/group
> > @@ -3,9 +3,13 @@
> >  # Defines test groups
> >  # - do not start group names with a digit
> >  #
> > -
> > +# External dependency groups:
> > +# qemu Relies on the qemu binary.
> > +# nbd  Relies on the qemu-nbd binary.
> > +# scm  Relies on the socket scm helper binary.
> >  #
> > -# test-group association ... one line per test
> > +# Format, one line per test:
> > +# nnn [GROUP]...
> >  #
> >  001 rw auto quick
> >  002 rw auto quick
> > @@ -13,7 +17,7 @@
> >  004 rw auto quick
> >  005 img auto quick
> >  # 006 was removed, do not reuse
> > -007 snapshot auto
> > +007 snapshot auto qemu
> >  008 rw auto quick
> >  009 rw auto quick
> >  010 rw auto quick
> > @@ -34,9 +38,9 @@
> >  025 rw auto quick
> >  026 rw blkdbg auto
> >  027 rw auto quick
> > -028 rw backing auto quick
> > +028 rw backing auto quick qemu
> >  029 rw auto quick
> > -030 rw auto backing
> > +030 rw auto backing qemu
> >  031 rw auto quick
> >  032 rw auto quick
> >  033 rw auto quick
> > @@ -46,38 +50,38 @@
> >  037 rw auto backing quick
> >  038 rw auto backing quick
> >  039 rw auto quick
> > -040 rw auto
> > -041 rw auto backing
> > +040 rw auto qemu
> > +041 rw auto backing qemu
> >  042 rw auto quick
> >  043 rw auto backing
> >  044 rw auto
> > -045 rw auto quick
> > +045 rw auto quick scm qemu
> >  046 rw auto aio quick
> >  047 rw auto quick
> >  048 img auto quick
> >  049 rw auto
> >  050 rw auto backing quick
> > -051 rw auto
> > +051 rw auto qemu
> >  052 rw auto backing quick
> >  053 rw auto quick
> >  054 rw auto quick
> > -055 rw auto
> > -056 rw auto backing
> > -057 rw auto
> > -058 rw auto quick
> > +055 rw auto qemu
> > +056 rw auto backing qemu
> > +057 rw auto qemu
> > +058 rw auto quick nbd
> >  059 rw auto quick
> >  060 rw auto quick
> >  061 rw auto
> >  062 rw auto quick
> >  063 rw auto quick
> >  064 rw auto quick
> > -065 rw auto quick
> > +065 rw auto quick qemu
> >  066 rw auto quick
> > -067 rw auto quick
> > -068 rw auto quick
> > +067 rw auto quick qemu
> > +068 rw auto quick qemu
> >  069 rw auto quick
> >  070 rw auto quick
> > -071 rw auto quick
> > +071 rw auto quick qemu
> >  072 rw auto quick
> >  073 rw auto quick
> >  074 rw auto quick
> > @@ -87,50 +91,50 @@
> >  078 rw auto quick
> >  079 rw auto
> >  080 rw auto
> > -081 rw auto quick
> > +081 rw auto quick qemu
> >  082 rw auto quick
> > -083 rw auto
> > +083 rw auto nbd
> >  084 img auto quick
> > -085 rw auto
> > +085 rw auto qemu
> >  086 rw auto quick
> > -087 rw auto quick
> > +087 rw auto quick qemu
> >  088 rw auto quick
> >  089 rw auto quick
> >  090 rw auto quick
> > -091 rw auto
> > +091 rw auto qemu
> >  092 rw auto quick
> > -093 auto
> > -094 rw auto quick
> > -095 rw auto quick
> > +093 auto qemu
> > +094 rw auto quick qemu nbd
> > +095 rw auto quick qemu
> >  097 rw auto backing
> >  098 rw auto backing quick
> > -099 rw auto quick
> > +099 rw auto quick qemu
> >  100 rw auto quick
> >  101 rw auto quick
> > -102 rw auto quick
> > +102 rw auto quick qemu
> >  103 rw auto quick
> >  104 rw auto
> >  105 rw auto quick
> >  107 rw auto quick
> >  108 rw auto quick
> > -109 rw auto
> > +109 rw auto qemu
> >  110 rw auto backing quick
> >  111 rw auto quick
> >  112 rw auto
> > -113 rw auto quick
> > +113 rw auto quick nbd
> >  114 rw auto quick
> >  115 rw auto
> >  116 rw auto quick
> > -119 rw auto quick
> > -120 rw auto quick
> > +119 rw auto quick qemu
> > +120 rw auto quick qemu
> >  121 rw auto
> >  122 rw auto
> > -123 rw auto quick
> > -124 rw auto backing
> > +123 rw auto quick nbd
> > +124 rw auto backing qemu
> >  128 rw auto quick
> > -129 rw auto quick
> > -130 rw auto quick
> > +129 rw auto quick qemu
> > +130 rw auto quick qemu
> >  131 rw auto quick
> > -132 rw auto quick
> > +132 rw auto quick qemu
> >  134 rw auto quick
> >  135 rw auto
> > 
> 
> -- 
> —js
> 

Re: [Qemu-devel] [PATCH 4/4] virtio-ccw: enable virtio-1

[Cornelia Huck]

On Thu, 10 Sep 2015 12:07:18 +0300
"Michael S. Tsirkin"  wrote:

> On Fri, Sep 04, 2015 at 10:54:29AM +0200, Cornelia Huck wrote:
> > Let's enable revision 1 for virtio-ccw devices. We can always offer
> > VERSION_1 as drivers in legacy mode won't be able to see it anyway.
> > 
> > We have to introduce a way to set a lower maximum revision for a device
> > to accommodate the following cases:
> > - compat machines (to enforce legacy only)
> 
> But you don't actually set this for any compat machines.
> If you don't, this seems a bit pointless.

Huh? The first hunk of this patch does this.

> 
> > - virtio-blk with scsi support (version 1 + scsi is fenced by common
> >   code, with a user-configured max revision of 0 we can allow scsi
> >   via not offering VERSION_1)
> 
> For this use, for pci users need to do disable_modern=true.
> I find it unfortunate that for ccw one needs to do max_revision=0.

I don't like the pci concept: much too coarse-grained and not very
future proof.

> 
> Revision numbers generally are a ccw specific concept. I'm not sure it
> is wise to expose it to users.

What is wrong about exposing transport-specific concepts?

> 
> > Signed-off-by: Cornelia Huck 
> > ---
> >  hw/s390x/s390-virtio-ccw.c |  4 
> >  hw/s390x/virtio-ccw.c  | 30 --
> >  hw/s390x/virtio-ccw.h  |  6 --
> >  3 files changed, 36 insertions(+), 4 deletions(-)
> > 
> > diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
> > index e2a26e9..fb6e45c 100644
> > --- a/hw/s390x/s390-virtio-ccw.c
> > +++ b/hw/s390x/s390-virtio-ccw.c
> > @@ -287,6 +287,10 @@ static const TypeInfo ccw_machine_info = {
> >  .driver   = TYPE_S390_SKEYS,\
> >  .property = "migration-enabled",\
> >  .value= "off",\
> > +},{\
> > +.driver = TYPE_VIRTIO_CCW_DEVICE,\
> > +.property = "max_revision",\
> > +.value = 0,\
> >  },
> >  
> >  static void ccw_machine_2_4_class_init(ObjectClass *oc, void *data)
> > diff --git a/hw/s390x/virtio-ccw.c b/hw/s390x/virtio-ccw.c
> > index eed7b3e..fb103b7 100644
> > --- a/hw/s390x/virtio-ccw.c
> > +++ b/hw/s390x/virtio-ccw.c
> > @@ -467,7 +467,13 @@ static int virtio_ccw_cb(SubchDev *sch, CCW1 ccw)
> >  MEMTXATTRS_UNSPECIFIED,
> >  NULL);
> >  if (features.index == 0) {
> > -features.features = (uint32_t)vdev->host_features;
> > +if (dev->revision >= 1) {
> > +/* Don't offer legacy features for modern devices. */
> > +features.features = (uint32_t)
> > +(vdev->host_features & ~VIRTIO_LEGACY_FEATURES);
> > +} else {
> > +features.features = (uint32_t)vdev->host_features;
> > +}
> >  } else if ((features.index == 1) && (dev->revision >= 1)) {
> >  /*
> >   * Only offer feature bits beyond 31 if the guest has
> > @@ -768,7 +774,7 @@ static int virtio_ccw_cb(SubchDev *sch, CCW1 ccw)
> >   * need to fetch it here. Nothing to do for now, though.
> >   */
> >  if (dev->revision >= 0 ||
> > -revinfo.revision > virtio_ccw_rev_max(vdev)) {
> > +revinfo.revision > virtio_ccw_rev_max(dev)) {
> >  ret = -ENOSYS;
> >  break;
> >  }
> > @@ -1541,6 +1547,10 @@ static void virtio_ccw_device_plugged(DeviceState 
> > *d, Error **errp)
> >  
> >  sch->id.cu_model = virtio_bus_get_vdev_id(&dev->bus);
> >  
> > +if (dev->max_rev >= 1) {
> > +virtio_add_feature(&vdev->host_features, VIRTIO_F_VERSION_1);
> > +}
> > +
> >  css_generate_sch_crws(sch->cssid, sch->ssid, sch->schid,
> >d->hotplugged, 1);
> >  }
> > @@ -1557,6 +1567,8 @@ static Property virtio_ccw_net_properties[] = {
> >  DEFINE_PROP_STRING("devno", VirtioCcwDevice, bus_id),
> >  DEFINE_PROP_BIT("ioeventfd", VirtioCcwDevice, flags,
> >  VIRTIO_CCW_FLAG_USE_IOEVENTFD_BIT, true),
> > +DEFINE_PROP_UINT32("max_revision", VirtioCcwDevice, max_rev,
> > +   VIRTIO_CCW_MAX_REV),
> >  DEFINE_PROP_END_OF_LIST(),
> >  };
> >  
> > @@ -1584,6 +1596,8 @@ static Property virtio_ccw_blk_properties[] = {
> >  DEFINE_PROP_STRING("devno", VirtioCcwDevice, bus_id),
> >  DEFINE_PROP_BIT("ioeventfd", VirtioCcwDevice, flags,
> >  VIRTIO_CCW_FLAG_USE_IOEVENTFD_BIT, true),
> > +DEFINE_PROP_UINT32("max_revision", VirtioCcwDevice, max_rev,
> > +   VIRTIO_CCW_MAX_REV),
> >  DEFINE_PROP_END_OF_LIST(),
> >  };
> >  
> > @@ -1611,6 +1625,8 @@ static Property virtio_ccw_serial_properties[] = {
> >  DEFINE_PROP_STRING("devno", VirtioCcwDevice, bus_id),
> >  DEFINE_PROP_BIT("ioeventfd", VirtioCcwDevice, flags,
> >  

[Qemu-devel] [PULL 0/7] virtio,pc,acpi fixes, cleanups

[Michael S. Tsirkin]

The following changes since commit fc04a730b7e60f4a62d6260d4eb9c537d1d3643f:

  Merge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20150908' 
into staging (2015-09-08 18:02:36 +0100)

are available in the git repository at:

  git://git.kernel.org/pub/scm/virt/kvm/mst/qemu.git tags/for_upstream

for you to fetch changes up to 0f288f854b96f56247e38f4207f71647133f0184:

  hw/pci: fix pci_update_mappings() trace events (2015-09-10 12:15:30 +0300)


virtio,pc,acpi fixes, cleanups

Fixes all over the place.

Signed-off-by: Michael S. Tsirkin 


Benjamin Herrenschmidt (1):
  pci: Fix pci_device_iommu_address_space() bus propagation

Cornelia Huck (1):
  virtio: avoid leading underscores for helpers

Eduardo Habkost (1):
  pc: Remove redundant arguments from xen_hvm_init()

Igor Mammedov (2):
  pc: memhotplug: fix incorrectly set reserved-memory-end
  pc: memhotplug: keep reserved-memory-end broken on 2.4 and earlier 
machines

Laszlo Ersek (1):
  hw/pci: fix pci_update_mappings() trace events

Richard W.M. Jones (1):
  acpi: Remove unused definition.

 include/hw/acpi/aml-build.h   |  1 -
 include/hw/i386/pc.h  |  1 +
 include/hw/virtio/virtio-access.h |  2 +-
 include/hw/virtio/virtio.h| 11 ++-
 include/hw/xen/xen.h  |  4 ++--
 hw/block/virtio-blk.c |  7 ---
 hw/char/virtio-serial-bus.c   |  2 +-
 hw/i386/pc.c  |  8 +++-
 hw/i386/pc_piix.c |  6 +++---
 hw/i386/pc_q35.c  |  6 +++---
 hw/net/vhost_net.c|  2 +-
 hw/net/virtio-net.c   | 31 ---
 hw/pci/pci.c  | 17 +++--
 hw/scsi/virtio-scsi.c |  8 
 hw/virtio/dataplane/vring.c   | 10 +-
 hw/virtio/vhost.c |  4 ++--
 hw/virtio/virtio-balloon.c|  2 +-
 hw/virtio/virtio.c| 14 +++---
 xen-hvm-stub.c|  3 +--
 xen-hvm.c | 25 -
 trace-events  |  4 ++--
 21 files changed, 86 insertions(+), 82 deletions(-)

[Qemu-devel] [PULL 1/7] pci: Fix pci_device_iommu_address_space() bus propagation

[Michael S. Tsirkin]

From: Benjamin Herrenschmidt 

he current code walks up the bus tree for an iommu, however it passes
to the iommu_fn() callback the bus/devfn of the immediate child of
the level where the callback was found, rather than the original
bus/devfn where the search started from.

This prevents iommu's like POWER8 (and in fact also Q35) to properly
provide an address space for a subset of devices that aren't immediate
children of the iommu.

PCIe carries the originator bdfn acccross to the iommu on all DMA
transactions, so we must be able to properly identify devices at all
levels.

This changes the function pci_device_iommu_address_space() to pass
the original pointers to the iommu_fn() callback instead.

Signed-off-by: Benjamin Herrenschmidt 
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
---
 hw/pci/pci.c | 13 +
 1 file changed, 5 insertions(+), 8 deletions(-)

diff --git a/hw/pci/pci.c b/hw/pci/pci.c
index 4700e95..eba7ca2 100644
--- a/hw/pci/pci.c
+++ b/hw/pci/pci.c
@@ -2383,17 +2383,14 @@ static void pci_device_class_init(ObjectClass *klass, 
void *data)
 AddressSpace *pci_device_iommu_address_space(PCIDevice *dev)
 {
 PCIBus *bus = PCI_BUS(dev->bus);
+PCIBus *iommu_bus = bus;
 
-if (bus->iommu_fn) {
-return bus->iommu_fn(bus, bus->iommu_opaque, dev->devfn);
+while(iommu_bus && !iommu_bus->iommu_fn && iommu_bus->parent_dev) {
+iommu_bus = PCI_BUS(iommu_bus->parent_dev->bus);
 }
-
-if (bus->parent_dev) {
-/** We are ignoring the bus master DMA bit of the bridge
- *  as it would complicate things such as VFIO for no good reason */
-return pci_device_iommu_address_space(bus->parent_dev);
+if (iommu_bus && iommu_bus->iommu_fn) {
+return iommu_bus->iommu_fn(bus, iommu_bus->iommu_opaque, dev->devfn);
 }
-
 return &address_space_memory;
 }
 
-- 
MST

[Qemu-devel] [PULL 2/7] pc: Remove redundant arguments from xen_hvm_init()

[Michael S. Tsirkin]

From: Eduardo Habkost 

Remove arguments that can be found in PCMachineState.

Signed-off-by: Eduardo Habkost 
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
---
 include/hw/xen/xen.h |  4 ++--
 hw/i386/pc_piix.c|  4 +---
 hw/i386/pc_q35.c |  4 +---
 xen-hvm-stub.c   |  3 +--
 xen-hvm.c| 25 -
 5 files changed, 17 insertions(+), 23 deletions(-)

diff --git a/include/hw/xen/xen.h b/include/hw/xen/xen.h
index 4356af4..e90931a 100644
--- a/include/hw/xen/xen.h
+++ b/include/hw/xen/xen.h
@@ -10,6 +10,7 @@
 
 #include "hw/irq.h"
 #include "qemu-common.h"
+#include "qemu/typedefs.h"
 
 /* xen-machine.c */
 enum xen_mode {
@@ -38,8 +39,7 @@ qemu_irq *xen_interrupt_controller_init(void);
 void xenstore_store_pv_console_info(int i, struct CharDriverState *chr);
 
 #if defined(NEED_CPU_H) && !defined(CONFIG_USER_ONLY)
-int xen_hvm_init(ram_addr_t *below_4g_mem_size, ram_addr_t *above_4g_mem_size,
- MemoryRegion **ram_memory);
+int xen_hvm_init(PCMachineState *pcms, MemoryRegion **ram_memory);
 void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size,
struct MemoryRegion *mr);
 void xen_modified_memory(ram_addr_t start, ram_addr_t length);
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index b82921d..117f8dc 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -134,9 +134,7 @@ static void pc_init1(MachineState *machine)
 pcms->below_4g_mem_size = machine->ram_size;
 }
 
-if (xen_enabled() && xen_hvm_init(&pcms->below_4g_mem_size,
-  &pcms->above_4g_mem_size,
-  &ram_memory) != 0) {
+if (xen_enabled() && xen_hvm_init(pcms, &ram_memory) != 0) {
 fprintf(stderr, "xen hardware virtual machine initialisation 
failed\n");
 exit(1);
 }
diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index 7217cbf..4b38dee 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -125,9 +125,7 @@ static void pc_q35_init(MachineState *machine)
 pcms->below_4g_mem_size = machine->ram_size;
 }
 
-if (xen_enabled() && xen_hvm_init(&pcms->below_4g_mem_size,
-  &pcms->above_4g_mem_size,
-  &ram_memory) != 0) {
+if (xen_enabled() && xen_hvm_init(pcms, &ram_memory) != 0) {
 fprintf(stderr, "xen hardware virtual machine initialisation 
failed\n");
 exit(1);
 }
diff --git a/xen-hvm-stub.c b/xen-hvm-stub.c
index 46867d8..6a39425 100644
--- a/xen-hvm-stub.c
+++ b/xen-hvm-stub.c
@@ -47,8 +47,7 @@ void xen_modified_memory(ram_addr_t start, ram_addr_t length)
 {
 }
 
-int xen_hvm_init(ram_addr_t *below_4g_mem_size, ram_addr_t *above_4g_mem_size,
- MemoryRegion **ram_memory)
+int xen_hvm_init(PCMachineState *pcms, MemoryRegion **ram_memory)
 {
 return 0;
 }
diff --git a/xen-hvm.c b/xen-hvm.c
index 0408462..55bce3a 100644
--- a/xen-hvm.c
+++ b/xen-hvm.c
@@ -180,8 +180,7 @@ qemu_irq *xen_interrupt_controller_init(void)
 
 /* Memory Ops */
 
-static void xen_ram_init(ram_addr_t *below_4g_mem_size,
- ram_addr_t *above_4g_mem_size,
+static void xen_ram_init(PCMachineState *pcms,
  ram_addr_t ram_size, MemoryRegion **ram_memory_p)
 {
 MemoryRegion *sysmem = get_system_memory();
@@ -198,20 +197,20 @@ static void xen_ram_init(ram_addr_t *below_4g_mem_size,
 }
 
 if (ram_size >= user_lowmem) {
-*above_4g_mem_size = ram_size - user_lowmem;
-*below_4g_mem_size = user_lowmem;
+pcms->above_4g_mem_size = ram_size - user_lowmem;
+pcms->below_4g_mem_size = user_lowmem;
 } else {
-*above_4g_mem_size = 0;
-*below_4g_mem_size = ram_size;
+pcms->above_4g_mem_size = 0;
+pcms->below_4g_mem_size = ram_size;
 }
-if (!*above_4g_mem_size) {
+if (!pcms->above_4g_mem_size) {
 block_len = ram_size;
 } else {
 /*
  * Xen does not allocate the memory continuously, it keeps a
  * hole of the size computed above or passed in.
  */
-block_len = (1ULL << 32) + *above_4g_mem_size;
+block_len = (1ULL << 32) + pcms->above_4g_mem_size;
 }
 memory_region_init_ram(&ram_memory, NULL, "xen.ram", block_len,
&error_abort);
@@ -229,12 +228,12 @@ static void xen_ram_init(ram_addr_t *below_4g_mem_size,
  */
 memory_region_init_alias(&ram_lo, NULL, "xen.ram.lo",
  &ram_memory, 0xc,
- *below_4g_mem_size - 0xc);
+ pcms->below_4g_mem_size - 0xc);
 memory_region_add_subregion(sysmem, 0xc, &ram_lo);
-if (*above_4g_mem_size > 0) {
+if (pcms->above_4g_mem_size > 0) {
 memory_region_init_alias(&ram_hi, NULL, "xen.ram.hi",
  &ram_memory, 0x1ULL,
-   

Re: [Qemu-devel] [PATCH V2 0/8] virtio 1.0 pci optimizations and fixes

[Michael S. Tsirkin]

On Wed, Sep 02, 2015 at 11:25:17AM +0800, Jason Wang wrote:
> Hi all:
> 
> This series tries to fix the following issues:
> 
> - qemu abort when trying to adjust endianness for zero length eventfd,
>   this prevent fast mmio eventfd from being used in ppc. Fixing by
>   skip the endianness adjustment for zero length eventfd.
> - 1.0 mmio is slow since it was using datamatch eventfd. Fixing this
>   by usinng wildcard mmio eventfd, then we could get speed up through
>   kernel fast mmio bus on ept capable machine.
> - 1.0 mmio is slow compared to pio (at least on some
>   archs/setups). Fixing this by re-introducing pio notification
>   capability. This will be useful for the arch/setups that fast mmio
>   does not work.
> - Some virtio pci 1.0 fields were not migrated. This will cause
>   unexpected behaviour if migrate during driver initialization. Fixing
>   this by introduce a transport specific callback and get/put
>   transport specific fields for virtio 1.0.
> - queue_enable read was broken. Fixing by set the queue_enable to true
>   during guest write and clear it during reset.
> 
> Please review.
> Thanks

Wanted to merge this, but it needs to be rebased to latest master.
Pls do, and repost.

> Changes from V1:
> - skip zero length eventfd endianness adjustment
> - don't use pci specific name ("modern") in virtio core, using "extra"
>   instead and in virtio pci callback, using subsections which could
>   allow us to extend the future improvement without changing the core.
> - don't check virtio_virtqueue_needed() in virtio_extra_state_needed()
> - drop the ppc 2.5 machine type patch
> - squash Eduardo's 2.5 machine type patches into this series
> 
> Eduardo Habkost (3):
>   q35: Move options common to all classes to pc_q35_machine_options()
>   q35: Move options common to all classes to pc_i440fx_machine_options()
>   pc: Introduce pc-*-2.5 machine classes
> 
> Jason Wang (5):
>   virtio-pci: fix 1.0 virtqueue migration
>   memory: don't try to adjust endianness for zero length eventfd
>   virtio-pci: use wildcard mmio eventfd for 1.0 notification cap
>   virtio-pci: introduce pio notification capability for modern device
>   virtio-pci: unbreak queue_enable read
> 
>  hw/i386/pc_piix.c  |  18 ++-
>  hw/i386/pc_q35.c   |  20 +++-
>  hw/virtio/virtio-pci.c | 266 
> +
>  hw/virtio/virtio-pci.h |  30 +++--
>  hw/virtio/virtio.c |  57 +
>  include/hw/compat.h|   7 ++
>  include/hw/i386/pc.h   |   4 +
>  include/hw/virtio/virtio-bus.h |   3 +
>  memory.c   |   8 +-
>  9 files changed, 375 insertions(+), 38 deletions(-)
> 
> -- 
> 2.1.4

[Qemu-devel] [PULL 5/7] pc: memhotplug: fix incorrectly set reserved-memory-end

[Michael S. Tsirkin]

From: Igor Mammedov 

reserved-memory-end tells firmware address from which
it could start treating memory as PCI address space
and map PCI BARs after it to avoid collisions with
RAM.
Currently it is incorrectly pointing to address where
hotplugged memory range starts which could redirect
hotplugged RAM accesses to PCI BARs when firmware
maps them over RAM or viceverse.
Fix this by pointing reserved-memory-end to the end
of memory hotplug area.

Signed-off-by: Igor Mammedov 
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
Reviewed-by: Eduardo Habkost 
---
 hw/i386/pc.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 9f2924e..354e1b3 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1412,7 +1412,9 @@ FWCfgState *pc_memory_init(PCMachineState *pcms,
 
 if (guest_info->has_reserved_memory && pcms->hotplug_memory.base) {
 uint64_t *val = g_malloc(sizeof(*val));
-*val = cpu_to_le64(ROUND_UP(pcms->hotplug_memory.base, 0x1ULL << 30));
+uint64_t res_mem_end = pcms->hotplug_memory.base +
+   memory_region_size(&pcms->hotplug_memory.mr);
+*val = cpu_to_le64(ROUND_UP(res_mem_end, 0x1ULL << 30));
 fw_cfg_add_file(fw_cfg, "etc/reserved-memory-end", val, sizeof(*val));
 }
 
-- 
MST

[Qemu-devel] [PULL 3/7] virtio: avoid leading underscores for helpers

[Michael S. Tsirkin]

From: Cornelia Huck 

Commit ef546f1275f6563e8934dd5e338d29d9f9909ca6 ("virtio: add
feature checking helpers") introduced a helper __virtio_has_feature.
We don't want to use reserved identifiers, though, so let's
rename __virtio_has_feature to virtio_has_feature and virtio_has_feature
to virtio_vdev_has_feature.

Signed-off-by: Cornelia Huck 
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
---
 include/hw/virtio/virtio-access.h |  2 +-
 include/hw/virtio/virtio.h| 11 ++-
 hw/block/virtio-blk.c |  7 ---
 hw/char/virtio-serial-bus.c   |  2 +-
 hw/net/vhost_net.c|  2 +-
 hw/net/virtio-net.c   | 31 ---
 hw/scsi/virtio-scsi.c |  8 
 hw/virtio/dataplane/vring.c   | 10 +-
 hw/virtio/vhost.c |  4 ++--
 hw/virtio/virtio-balloon.c|  2 +-
 hw/virtio/virtio.c| 14 +++---
 11 files changed, 48 insertions(+), 45 deletions(-)

diff --git a/include/hw/virtio/virtio-access.h 
b/include/hw/virtio/virtio-access.h
index 1ec1dfd..8aec843 100644
--- a/include/hw/virtio/virtio-access.h
+++ b/include/hw/virtio/virtio-access.h
@@ -19,7 +19,7 @@
 
 static inline bool virtio_access_is_big_endian(VirtIODevice *vdev)
 {
-if (virtio_has_feature(vdev, VIRTIO_F_VERSION_1)) {
+if (virtio_vdev_has_feature(vdev, VIRTIO_F_VERSION_1)) {
 /* Devices conforming to VIRTIO 1.0 or later are always LE. */
 return false;
 }
diff --git a/include/hw/virtio/virtio.h b/include/hw/virtio/virtio.h
index cccae89..6201ee8 100644
--- a/include/hw/virtio/virtio.h
+++ b/include/hw/virtio/virtio.h
@@ -261,26 +261,27 @@ static inline void virtio_clear_feature(uint64_t 
*features, unsigned int fbit)
 *features &= ~(1ULL << fbit);
 }
 
-static inline bool __virtio_has_feature(uint64_t features, unsigned int fbit)
+static inline bool virtio_has_feature(uint64_t features, unsigned int fbit)
 {
 assert(fbit < 64);
 return !!(features & (1ULL << fbit));
 }
 
-static inline bool virtio_has_feature(VirtIODevice *vdev, unsigned int fbit)
+static inline bool virtio_vdev_has_feature(VirtIODevice *vdev,
+   unsigned int fbit)
 {
-return __virtio_has_feature(vdev->guest_features, fbit);
+return virtio_has_feature(vdev->guest_features, fbit);
 }
 
 static inline bool virtio_host_has_feature(VirtIODevice *vdev,
unsigned int fbit)
 {
-return __virtio_has_feature(vdev->host_features, fbit);
+return virtio_has_feature(vdev->host_features, fbit);
 }
 
 static inline bool virtio_is_big_endian(VirtIODevice *vdev)
 {
-if (!virtio_has_feature(vdev, VIRTIO_F_VERSION_1)) {
+if (!virtio_vdev_has_feature(vdev, VIRTIO_F_VERSION_1)) {
 assert(vdev->device_endian != VIRTIO_DEVICE_ENDIAN_UNKNOWN);
 return vdev->device_endian == VIRTIO_DEVICE_ENDIAN_BIG;
 }
diff --git a/hw/block/virtio-blk.c b/hw/block/virtio-blk.c
index 1556c9c..f9301ae 100644
--- a/hw/block/virtio-blk.c
+++ b/hw/block/virtio-blk.c
@@ -731,7 +731,7 @@ static uint64_t virtio_blk_get_features(VirtIODevice *vdev, 
uint64_t features,
 virtio_add_feature(&features, VIRTIO_BLK_F_GEOMETRY);
 virtio_add_feature(&features, VIRTIO_BLK_F_TOPOLOGY);
 virtio_add_feature(&features, VIRTIO_BLK_F_BLK_SIZE);
-if (__virtio_has_feature(features, VIRTIO_F_VERSION_1)) {
+if (virtio_has_feature(features, VIRTIO_F_VERSION_1)) {
 if (s->conf.scsi) {
 error_setg(errp, "Please set scsi=off for virtio-blk devices in 
order to use virtio 1.0");
 return 0;
@@ -782,10 +782,11 @@ static void virtio_blk_set_status(VirtIODevice *vdev, 
uint8_t status)
  *
  * s->blk would erroneously be placed in writethrough mode.
  */
-if (!virtio_has_feature(vdev, VIRTIO_BLK_F_CONFIG_WCE)) {
+if (!virtio_vdev_has_feature(vdev, VIRTIO_BLK_F_CONFIG_WCE)) {
 aio_context_acquire(blk_get_aio_context(s->blk));
 blk_set_enable_write_cache(s->blk,
-   virtio_has_feature(vdev, VIRTIO_BLK_F_WCE));
+   virtio_vdev_has_feature(vdev,
+   VIRTIO_BLK_F_WCE));
 aio_context_release(blk_get_aio_context(s->blk));
 }
 }
diff --git a/hw/char/virtio-serial-bus.c b/hw/char/virtio-serial-bus.c
index bc56f5d..be97058 100644
--- a/hw/char/virtio-serial-bus.c
+++ b/hw/char/virtio-serial-bus.c
@@ -76,7 +76,7 @@ static VirtIOSerialPort *find_port_by_name(char *name)
 static bool use_multiport(VirtIOSerial *vser)
 {
 VirtIODevice *vdev = VIRTIO_DEVICE(vser);
-return virtio_has_feature(vdev, VIRTIO_CONSOLE_F_MULTIPORT);
+return virtio_vdev_has_feature(vdev, VIRTIO_CONSOLE_F_MULTIPORT);
 }
 
 static size_t write_to_port(VirtIOSerialPort *port,
diff --git a/hw/net/vhost_net.c b/hw/net/vhost_net.c
index 5c1d11f..1d76b94 10064

[Qemu-devel] [PULL 4/7] acpi: Remove unused definition.

[Michael S. Tsirkin]

From: "Richard W.M. Jones" 

Signed-off-by: Richard W.M. Jones 
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
---
 include/hw/acpi/aml-build.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/include/hw/acpi/aml-build.h b/include/hw/acpi/aml-build.h
index e3afa13..1b632dc 100644
--- a/include/hw/acpi/aml-build.h
+++ b/include/hw/acpi/aml-build.h
@@ -9,7 +9,6 @@
 /* Reserve RAM space for tables: add another order of magnitude. */
 #define ACPI_BUILD_TABLE_MAX_SIZE 0x20
 
-#define ACPI_BUILD_APPNAME  "Bochs"
 #define ACPI_BUILD_APPNAME6 "BOCHS "
 #define ACPI_BUILD_APPNAME4 "BXPC"
 
-- 
MST

Re: [Qemu-devel] [PATCH v2 2/2] target-i386: move asm-x86/hyperv.h to standard-headers

[Paolo Bonzini]

On 10/09/2015 09:42, Michael S. Tsirkin wrote:
> On Wed, Sep 09, 2015 at 06:34:01PM +0200, Paolo Bonzini wrote:
>> The Hyper-V definitions are an industry standard and can be used
>> from code that is not KVM-specific.
>>
>> The changes to scripts/update-linux-headers.sh are required because there
>> is both an asm-x86/hyperv.h and a linux/hyperv.h file.  linux/hyperv.h
>> introduces dependencies on additional Linux uapi headers, so we only
>> want the former.
>>
>> The solution is to make cp_virtio (now renamed to cp_portable) copy
>> one file only, instead of using the "find" command, and call it multiple
>> times.  The new function is really just a reindentation of the old one.
>>
>> Signed-off-by: Paolo Bonzini 
> 
> I'd rather see a script update, then result of running it
> in a separate patch.

Okay, I'll split the patch in two.

>> @@ -68,6 +61,7 @@ cp_virtio() {
>>  ARCHLIST=$(cd "$linux/arch" && echo *)
>>  
>>  for arch in $ARCHLIST; do
>> +
>>  # Discard anything which isn't a KVM-supporting architecture
>>  if ! [ -e "$linux/arch/$arch/include/asm/kvm.h" ] &&
>>  ! [ -e "$linux/arch/$arch/include/uapi/asm/kvm.h" ] ; then
> 
> This empty line looks ugly imho.

Right.

>> +cat <$output/linux-headers/asm-x86/hyperv.h
>> +#include "standard-headers/asm-x86/hyperv.h"
>> +EOF
> 
> I don't think this is needed. We only did this for
> virtio_config to avoid the code churn. Hyperv has
> a single user, so no issue.

It is needed because kvm headers include  and you don't
want to pick the system version.

>>  cat <$output/linux-headers/linux/virtio_config.h
>>  #include "standard-headers/linux/virtio_config.h"
>>  EOF
>> @@ -120,7 +122,12 @@ cat <$output/linux-headers/linux/virtio_ring.h
>>  #include "standard-headers/linux/virtio_ring.h"
>>  EOF
>>  
>> -cp_virtio "$tmpdir/include/linux/" "$output/include/standard-headers/linux"
>> +rm -rf "$output/include/standard-headers/linux"
>> +mkdir -p "$output/include/standard-headers/linux"
>> +for i in "$tmpdir"/include/linux/*virtio*.h "$tmpdir/include/linux/input.h" 
>> \
>> + "$tmpdir/include/linux/pci_regs.h"; do
>> +cp_portable "$i" "$output/include/standard-headers/linux"
>> +done
> 
> How about we move the above loop into cp_virtio?

I disagree, because input.h and pci_regs.h make no sense for s390.

Paolo

> Then we can reuse it for asm like we did.
> hyperv can use cp_portable if it wants to.
> 
>>  
>>  cat <$output/include/standard-headers/linux/types.h
>>  #include 
>> diff --git a/target-i386/kvm.c b/target-i386/kvm.c
>> index 066d03d..d8a11be 100644
>> --- a/target-i386/kvm.c
>> +++ b/target-i386/kvm.c
>> @@ -33,7 +33,7 @@
>>  #include "hw/i386/apic_internal.h"
>>  #include "hw/i386/apic-msidef.h"
>>  #include "exec/ioport.h"
>> -#include 
>> +#include "standard-headers/asm-x86/hyperv.h"
>>  #include "hw/pci/pci.h"
>>  #include "migration/migration.h"
>>  #include "exec/memattrs.h"
>> -- 
>> 2.4.3

[Qemu-devel] [PULL 6/7] pc: memhotplug: keep reserved-memory-end broken on 2.4 and earlier machines

[Michael S. Tsirkin]

From: Igor Mammedov 

it will prevent guests on old machines from seeing
inconsistent memory mapping in firmware/ACPI views.

Signed-off-by: Igor Mammedov 
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
Reviewed-by: Eduardo Habkost 
---
 include/hw/i386/pc.h | 1 +
 hw/i386/pc.c | 8 ++--
 hw/i386/pc_piix.c| 2 ++
 hw/i386/pc_q35.c | 2 ++
 4 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index d0cad87..ff0b48b 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -59,6 +59,7 @@ struct PCMachineClass {
 MachineClass parent_class;
 
 /*< public >*/
+bool broken_reserved_end;
 HotplugHandler *(*get_hotplug_handler)(MachineState *machine,
DeviceState *dev);
 };
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 354e1b3..b5107f7 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1412,8 +1412,12 @@ FWCfgState *pc_memory_init(PCMachineState *pcms,
 
 if (guest_info->has_reserved_memory && pcms->hotplug_memory.base) {
 uint64_t *val = g_malloc(sizeof(*val));
-uint64_t res_mem_end = pcms->hotplug_memory.base +
-   memory_region_size(&pcms->hotplug_memory.mr);
+PCMachineClass *pcmc = PC_MACHINE_GET_CLASS(pcms);
+uint64_t res_mem_end = pcms->hotplug_memory.base;
+
+if (!pcmc->broken_reserved_end) {
+res_mem_end += memory_region_size(&pcms->hotplug_memory.mr);
+}
 *val = cpu_to_le64(ROUND_UP(res_mem_end, 0x1ULL << 30));
 fw_cfg_add_file(fw_cfg, "etc/reserved-memory-end", val, sizeof(*val));
 }
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 117f8dc..eab39fc 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -449,7 +449,9 @@ static void pc_i440fx_machine_options(MachineClass *m)
 
 static void pc_i440fx_2_4_machine_options(MachineClass *m)
 {
+PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
 pc_i440fx_machine_options(m);
+pcmc->broken_reserved_end = true;
 m->default_machine_opts = "firmware=bios-256k.bin";
 m->default_display = "std";
 m->alias = "pc";
diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index 4b38dee..11601ab 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -368,7 +368,9 @@ static void pc_q35_machine_options(MachineClass *m)
 
 static void pc_q35_2_4_machine_options(MachineClass *m)
 {
+PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
 pc_q35_machine_options(m);
+pcmc->broken_reserved_end = true;
 m->default_machine_opts = "firmware=bios-256k.bin";
 m->default_display = "std";
 m->no_floppy = 1;
-- 
MST

[Qemu-devel] [PULL 7/7] hw/pci: fix pci_update_mappings() trace events

[Michael S. Tsirkin]

From: Laszlo Ersek 

The current trace prototypes and (matching) trace calls lead to
"unorthodox" PCI BDF notation in at least the stderr trace backend. For
example, the four BARs of a QXL video card at 00:01.0 (bus 0, slot 1,
function 0) are traced like this (PID and timestamps removed):

  pci_update_mappings_add d=0x7f14a73bf890 00:00.1 0,0x8400+0x400
  pci_update_mappings_add d=0x7f14a73bf890 00:00.1 1,0x8000+0x400
  pci_update_mappings_add d=0x7f14a73bf890 00:00.1 2,0x8820+0x2000
  pci_update_mappings_add d=0x7f14a73bf890 00:00.1 3,0xd060+0x20

The slot and function values are in reverse order.

Stick with the conventional BDF notation.

Cc: "Michael S. Tsirkin" 
Cc: Don Koch 
Cc: qemu-triv...@nongnu.org
Fixes: 7828d75045
Signed-off-by: Laszlo Ersek 
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
---
 hw/pci/pci.c | 4 ++--
 trace-events | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/hw/pci/pci.c b/hw/pci/pci.c
index eba7ca2..ccea628 100644
--- a/hw/pci/pci.c
+++ b/hw/pci/pci.c
@@ -1154,16 +1154,16 @@ static void pci_update_mappings(PCIDevice *d)
 /* now do the real mapping */
 if (r->addr != PCI_BAR_UNMAPPED) {
 trace_pci_update_mappings_del(d, pci_bus_num(d->bus),
-  PCI_FUNC(d->devfn),
   PCI_SLOT(d->devfn),
+  PCI_FUNC(d->devfn),
   i, r->addr, r->size);
 memory_region_del_subregion(r->address_space, r->memory);
 }
 r->addr = new_addr;
 if (r->addr != PCI_BAR_UNMAPPED) {
 trace_pci_update_mappings_add(d, pci_bus_num(d->bus),
-  PCI_FUNC(d->devfn),
   PCI_SLOT(d->devfn),
+  PCI_FUNC(d->devfn),
   i, r->addr, r->size);
 memory_region_add_subregion_overlap(r->address_space,
 r->addr, r->memory, 1);
diff --git a/trace-events b/trace-events
index 0a82f0c..1684a95 100644
--- a/trace-events
+++ b/trace-events
@@ -1303,8 +1303,8 @@ spapr_pci_lsi_set(const char *busname, int pin, uint32_t 
irq) "%s PIN%d IRQ %u"
 spapr_pci_msi_retry(unsigned config_addr, unsigned req_num, unsigned max_irqs) 
"Guest device at %x asked %u, have only %u"
 
 # hw/pci/pci.c
-pci_update_mappings_del(void *d, uint32_t bus, uint32_t func, uint32_t slot, 
int bar, uint64_t addr, uint64_t size) "d=%p %02x:%02x.%x 
%d,%#"PRIx64"+%#"PRIx64
-pci_update_mappings_add(void *d, uint32_t bus, uint32_t func, uint32_t slot, 
int bar, uint64_t addr, uint64_t size) "d=%p %02x:%02x.%x 
%d,%#"PRIx64"+%#"PRIx64
+pci_update_mappings_del(void *d, uint32_t bus, uint32_t slot, uint32_t func, 
int bar, uint64_t addr, uint64_t size) "d=%p %02x:%02x.%x 
%d,%#"PRIx64"+%#"PRIx64
+pci_update_mappings_add(void *d, uint32_t bus, uint32_t slot, uint32_t func, 
int bar, uint64_t addr, uint64_t size) "d=%p %02x:%02x.%x 
%d,%#"PRIx64"+%#"PRIx64
 
 # hw/net/pcnet.c
 pcnet_s_reset(void *s) "s=%p"
-- 
MST

Re: [Qemu-devel] [PULL 0/19] xen-2015-09-08-tag

[Chen, Tiejun]

As you see this short log, "hw/pci-assign: split pci-assign.c", so this
means I just extract something from the original hw/i386/kvm/pci-assign.c,
and here so I just keep those original head files residing
hw/i386/kvm/pci-assign.c, and I didn't introduce anything new.


hw/i386/kvm/pci-assign.c is only built if configure set CONFIG_KVM,
which it won't do on Windows or OSX builds.

It sounds like your patch has incorrectly moved code out of files
which are compiled only if KVM is present, or only if we're doing
Xen PCI passthrough, and into compiled-for-everything files.



Yes, we want to share this chunk of codes between Xen and Kvm. Just to 
this error, could we remove #include ? As I mentioned I still 
can compile this file without this head file.


Thanks
Tiejun

Re: [Qemu-devel] [PATCH 2/4] qtest/ahci: export generate_pattern

[Markus Armbruster]

John Snow  writes:

> Share the pattern function for ide and ahci test.
>
> Signed-off-by: John Snow 
> ---
>  tests/ahci-test.c | 26 --
>  tests/libqos/libqos.c | 26 ++
>  tests/libqos/libqos.h |  1 +
>  3 files changed, 27 insertions(+), 26 deletions(-)
>
> diff --git a/tests/ahci-test.c b/tests/ahci-test.c
> index b1a785c..59d387c 100644
> --- a/tests/ahci-test.c
> +++ b/tests/ahci-test.c
> @@ -71,32 +71,6 @@ static void string_bswap16(uint16_t *s, size_t bytes)
>  }
>  }
>  
> -static void generate_pattern(void *buffer, size_t len, size_t cycle_len)
> -{
> -int i, j;
> -unsigned char *tx = (unsigned char *)buffer;
> -unsigned char p;
> -size_t *sx;
> -
> -/* Write an indicative pattern that varies and is unique per-cycle */
> -p = rand() % 256;
> -for (i = 0; i < len; i++) {
> -tx[i] = p++ % 256;
> -if (i % cycle_len == 0) {
> -p = rand() % 256;
> -}
> -}
> -
> -/* force uniqueness by writing an id per-cycle */
> -for (i = 0; i < len / cycle_len; i++) {
> -j = i * cycle_len;
> -if (j + sizeof(*sx) <= len) {
> -sx = (size_t *)&tx[j];
> -*sx = i;
> -}
> -}
> -}
> -
>  /**
>   * Verify that the transfer did not corrupt our state at all.
>   */
> diff --git a/tests/libqos/libqos.c b/tests/libqos/libqos.c
> index fce625b..8d7c5a9 100644
> --- a/tests/libqos/libqos.c
> +++ b/tests/libqos/libqos.c
> @@ -212,3 +212,29 @@ void prepare_blkdebug_script(const char *debug_fn, const 
> char *event)
>  ret = fclose(debug_file);
>  g_assert(ret == 0);
>  }
> +
> +void generate_pattern(void *buffer, size_t len, size_t cycle_len)
> +{
> +int i, j;
> +unsigned char *tx = (unsigned char *)buffer;
> +unsigned char p;
> +size_t *sx;
> +
> +/* Write an indicative pattern that varies and is unique per-cycle */
> +p = rand() % 256;
> +for (i = 0; i < len; i++) {
> +tx[i] = p++ % 256;
> +if (i % cycle_len == 0) {
> +p = rand() % 256;
> +}
> +}
> +
> +/* force uniqueness by writing an id per-cycle */
> +for (i = 0; i < len / cycle_len; i++) {
> +j = i * cycle_len;
> +if (j + sizeof(*sx) <= len) {
> +sx = (size_t *)&tx[j];

Relies on cycle_len being a multiple of size_t's alignment.  So far,
it's always AHCI_SECTOR_SIZE, which should do.

> +*sx = i;
> +}
> +}
> +}

Looks like overkill to me, but since it's working code... :)

> diff --git a/tests/libqos/libqos.h b/tests/libqos/libqos.h
> index e1f14ea..492a651 100644
> --- a/tests/libqos/libqos.h
> +++ b/tests/libqos/libqos.h
> @@ -24,6 +24,7 @@ void mkqcow2(const char *file, unsigned size_mb);
>  void set_context(QOSState *s);
>  void migrate(QOSState *from, QOSState *to, const char *uri);
>  void prepare_blkdebug_script(const char *debug_fn, const char *event);
> +void generate_pattern(void *buffer, size_t len, size_t cycle_len);
>  
>  static inline uint64_t qmalloc(QOSState *q, size_t bytes)
>  {

Re: [Qemu-devel] [PATCH 4/4] virtio-ccw: enable virtio-1

[Michael S. Tsirkin]

On Thu, Sep 10, 2015 at 11:11:20AM +0200, Cornelia Huck wrote:
> On Thu, 10 Sep 2015 12:07:18 +0300
> "Michael S. Tsirkin"  wrote:
> 
> > On Fri, Sep 04, 2015 at 10:54:29AM +0200, Cornelia Huck wrote:
> > > Let's enable revision 1 for virtio-ccw devices. We can always offer
> > > VERSION_1 as drivers in legacy mode won't be able to see it anyway.
> > > 
> > > We have to introduce a way to set a lower maximum revision for a device
> > > to accommodate the following cases:
> > > - compat machines (to enforce legacy only)
> > 
> > But you don't actually set this for any compat machines.
> > If you don't, this seems a bit pointless.
> 
> Huh? The first hunk of this patch does this.

Sure. Donnu how I could miss it, sorry.

> > 
> > > - virtio-blk with scsi support (version 1 + scsi is fenced by common
> > >   code, with a user-configured max revision of 0 we can allow scsi
> > >   via not offering VERSION_1)
> > 
> > For this use, for pci users need to do disable_modern=true.
> > I find it unfortunate that for ccw one needs to do max_revision=0.
> 
> I don't like the pci concept: much too coarse-grained and not very
> future proof.
> 
> > 
> > Revision numbers generally are a ccw specific concept. I'm not sure it
> > is wise to expose it to users.
> 
> What is wrong about exposing transport-specific concepts?

Nothing. Go ahead and expose as much of the low level as
makes sense.

But it would be nice if there was also a portable way for people
that just want "virtio" and don't care about the low level details
of which transport it is.

OTOH a conservative estimate of the # of people that will want
to play with this is pretty close to 0, so maybe it does not matter
much.

> > 
> > > Signed-off-by: Cornelia Huck 
> > > ---
> > >  hw/s390x/s390-virtio-ccw.c |  4 
> > >  hw/s390x/virtio-ccw.c  | 30 --
> > >  hw/s390x/virtio-ccw.h  |  6 --
> > >  3 files changed, 36 insertions(+), 4 deletions(-)
> > > 
> > > diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
> > > index e2a26e9..fb6e45c 100644
> > > --- a/hw/s390x/s390-virtio-ccw.c
> > > +++ b/hw/s390x/s390-virtio-ccw.c
> > > @@ -287,6 +287,10 @@ static const TypeInfo ccw_machine_info = {
> > >  .driver   = TYPE_S390_SKEYS,\
> > >  .property = "migration-enabled",\
> > >  .value= "off",\
> > > +},{\
> > > +.driver = TYPE_VIRTIO_CCW_DEVICE,\
> > > +.property = "max_revision",\
> > > +.value = 0,\
> > >  },
> > >  
> > >  static void ccw_machine_2_4_class_init(ObjectClass *oc, void *data)
> > > diff --git a/hw/s390x/virtio-ccw.c b/hw/s390x/virtio-ccw.c
> > > index eed7b3e..fb103b7 100644
> > > --- a/hw/s390x/virtio-ccw.c
> > > +++ b/hw/s390x/virtio-ccw.c
> > > @@ -467,7 +467,13 @@ static int virtio_ccw_cb(SubchDev *sch, CCW1 ccw)
> > >  MEMTXATTRS_UNSPECIFIED,
> > >  NULL);
> > >  if (features.index == 0) {
> > > -features.features = (uint32_t)vdev->host_features;
> > > +if (dev->revision >= 1) {
> > > +/* Don't offer legacy features for modern devices. */
> > > +features.features = (uint32_t)
> > > +(vdev->host_features & ~VIRTIO_LEGACY_FEATURES);
> > > +} else {
> > > +features.features = (uint32_t)vdev->host_features;
> > > +}
> > >  } else if ((features.index == 1) && (dev->revision >= 1)) {
> > >  /*
> > >   * Only offer feature bits beyond 31 if the guest has
> > > @@ -768,7 +774,7 @@ static int virtio_ccw_cb(SubchDev *sch, CCW1 ccw)
> > >   * need to fetch it here. Nothing to do for now, though.
> > >   */
> > >  if (dev->revision >= 0 ||
> > > -revinfo.revision > virtio_ccw_rev_max(vdev)) {
> > > +revinfo.revision > virtio_ccw_rev_max(dev)) {
> > >  ret = -ENOSYS;
> > >  break;
> > >  }
> > > @@ -1541,6 +1547,10 @@ static void virtio_ccw_device_plugged(DeviceState 
> > > *d, Error **errp)
> > >  
> > >  sch->id.cu_model = virtio_bus_get_vdev_id(&dev->bus);
> > >  
> > > +if (dev->max_rev >= 1) {
> > > +virtio_add_feature(&vdev->host_features, VIRTIO_F_VERSION_1);
> > > +}
> > > +
> > >  css_generate_sch_crws(sch->cssid, sch->ssid, sch->schid,
> > >d->hotplugged, 1);
> > >  }
> > > @@ -1557,6 +1567,8 @@ static Property virtio_ccw_net_properties[] = {
> > >  DEFINE_PROP_STRING("devno", VirtioCcwDevice, bus_id),
> > >  DEFINE_PROP_BIT("ioeventfd", VirtioCcwDevice, flags,
> > >  VIRTIO_CCW_FLAG_USE_IOEVENTFD_BIT, true),
> > > +DEFINE_PROP_UINT32("max_revision", VirtioCcwDevice, max_rev,
> > > +   VIRTIO_CCW_MAX_REV),
> > >  DEFINE_PR

Re: [Qemu-devel] [PATCH v2 2/2] target-i386: move asm-x86/hyperv.h to standard-headers

[Michael S. Tsirkin]

On Thu, Sep 10, 2015 at 11:19:48AM +0200, Paolo Bonzini wrote:
> 
> 
> On 10/09/2015 09:42, Michael S. Tsirkin wrote:
> > On Wed, Sep 09, 2015 at 06:34:01PM +0200, Paolo Bonzini wrote:
> >> The Hyper-V definitions are an industry standard and can be used
> >> from code that is not KVM-specific.
> >>
> >> The changes to scripts/update-linux-headers.sh are required because there
> >> is both an asm-x86/hyperv.h and a linux/hyperv.h file.  linux/hyperv.h
> >> introduces dependencies on additional Linux uapi headers, so we only
> >> want the former.
> >>
> >> The solution is to make cp_virtio (now renamed to cp_portable) copy
> >> one file only, instead of using the "find" command, and call it multiple
> >> times.  The new function is really just a reindentation of the old one.
> >>
> >> Signed-off-by: Paolo Bonzini 
> > 
> > I'd rather see a script update, then result of running it
> > in a separate patch.
> 
> Okay, I'll split the patch in two.
> 
> >> @@ -68,6 +61,7 @@ cp_virtio() {
> >>  ARCHLIST=$(cd "$linux/arch" && echo *)
> >>  
> >>  for arch in $ARCHLIST; do
> >> +
> >>  # Discard anything which isn't a KVM-supporting architecture
> >>  if ! [ -e "$linux/arch/$arch/include/asm/kvm.h" ] &&
> >>  ! [ -e "$linux/arch/$arch/include/uapi/asm/kvm.h" ] ; then
> > 
> > This empty line looks ugly imho.
> 
> Right.
> 
> >> +cat <$output/linux-headers/asm-x86/hyperv.h
> >> +#include "standard-headers/asm-x86/hyperv.h"
> >> +EOF
> > 
> > I don't think this is needed. We only did this for
> > virtio_config to avoid the code churn. Hyperv has
> > a single user, so no issue.
> 
> It is needed because kvm headers include  and you don't
> want to pick the system version.

I see. Makes sense. Then maybe don't bother with kvm.c either?
Keeps it consistent ...

> >>  cat <$output/linux-headers/linux/virtio_config.h
> >>  #include "standard-headers/linux/virtio_config.h"
> >>  EOF
> >> @@ -120,7 +122,12 @@ cat <$output/linux-headers/linux/virtio_ring.h
> >>  #include "standard-headers/linux/virtio_ring.h"
> >>  EOF
> >>  
> >> -cp_virtio "$tmpdir/include/linux/" 
> >> "$output/include/standard-headers/linux"
> >> +rm -rf "$output/include/standard-headers/linux"
> >> +mkdir -p "$output/include/standard-headers/linux"
> >> +for i in "$tmpdir"/include/linux/*virtio*.h 
> >> "$tmpdir/include/linux/input.h" \
> >> + "$tmpdir/include/linux/pci_regs.h"; do
> >> +cp_portable "$i" "$output/include/standard-headers/linux"
> >> +done
> > 
> > How about we move the above loop into cp_virtio?
> 
> I disagree, because input.h and pci_regs.h make no sense for s390.
> 
> Paolo

And Cornelia thinks s390 won't need anything new ever, either.
OK then.

> > Then we can reuse it for asm like we did.
> > hyperv can use cp_portable if it wants to.
> > 
> >>  
> >>  cat <$output/include/standard-headers/linux/types.h
> >>  #include 
> >> diff --git a/target-i386/kvm.c b/target-i386/kvm.c
> >> index 066d03d..d8a11be 100644
> >> --- a/target-i386/kvm.c
> >> +++ b/target-i386/kvm.c
> >> @@ -33,7 +33,7 @@
> >>  #include "hw/i386/apic_internal.h"
> >>  #include "hw/i386/apic-msidef.h"
> >>  #include "exec/ioport.h"
> >> -#include 
> >> +#include "standard-headers/asm-x86/hyperv.h"
> >>  #include "hw/pci/pci.h"
> >>  #include "migration/migration.h"
> >>  #include "exec/memattrs.h"
> >> -- 
> >> 2.4.3

Re: [Qemu-devel] [edk2] EDK II & GPL - Re: OVMF BoF @ KVM Forum 2015

[Daniel P. Berrange]

On Wed, Sep 09, 2015 at 05:41:59PM -0700, Jordan Justen wrote:
> On 2015-09-09 16:05:20, Andrew Fish wrote:
> > 
> > > On Sep 9, 2015, at 3:24 PM, Jordan Justen  
> > > wrot> > > FWIW, I don't mind if the consensus is that GplDriverPkg must 
> > > live in
> > > a separate repo. But, it would be nice to hear a good reason why it
> > > must live elsewhere.
> > 
> > Because GPL is not a permissive license. An accidental git grep and
> > copying some code can change the license of the code that gets the
> > GPL code pasted into it.
> 
> I like this argument. It is slightly tempered by the fact that git
> grep always shows the source path, and thus 'GplDriverPkg' would be
> obviously visible.

Plenty of projects have a scenario in which different parts of their
codebase are under different licenses, without there being undue
problems. If you make it clear by having a separate directory, then
I think you can ultimately credit the developers with having enough
intelligence to do the right thing here. If not, then I'd probably
question whether you can trust them to submit any code at all, as
they could equally have blindly copied it from a 3rd party project
under an incompatible license.

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

Re: [Qemu-devel] [PATCH V2 4/8] virtio-pci: fix 1.0 virtqueue migration

[Michael S. Tsirkin]

On Tue, Sep 08, 2015 at 03:27:59PM +0800, Jason Wang wrote:
> 
> 
> On 09/07/2015 04:21 PM, Cornelia Huck wrote:
> > On Mon, 7 Sep 2015 15:39:59 +0800
> > Jason Wang  wrote:
> >
> >> > On 09/02/2015 07:06 PM, Cornelia Huck wrote:
> >>> > > On Wed,  2 Sep 2015 11:25:21 +0800
> >>> > > Jason Wang  wrote:
>  > >> +static int get_extra_state(QEMUFile *f, void *pv, size_t size)
>  > >> +{
>  > >> +VirtIODevice *vdev = pv;
>  > >> +BusState *qbus = qdev_get_parent_bus(DEVICE(vdev));
>  > >> +VirtioBusClass *k = VIRTIO_BUS_GET_CLASS(qbus);
>  > >> +int ret = 0;
>  > >> +
>  > >> +ret = k->load_extra_state(qbus->parent, f);
> >>> > > Should we check for ->load_extra_state() and return failure if it does
> >>> > > not exist?
> >> > 
> >> > I think checking the existence of has_extra_state() in
> >> > virtio_extra_state_needed() is enough for this? Or is there anything I 
> >> > miss?
> > The has_extra_state() callback is called by the sender, not by the
> > receiver.
> >
> > If the other side sent the extra state but we can't handle it, I think
> > it would be better to fail the migration than to crash. Still broken
> > code, but probably easier to debug :)
> >
> 
> I see so it only happen when transport provides save_extra_state() but
> not get_extra_sate(). I'm ok to add the check in next version .
> 
> Thanks

This seems minor enough. I think I'll merge this as is,
we can tweak things using patches on top.

Re: [Qemu-devel] [PATCH 1/1] block/gluster: add support for multiple gluster backup volfile servers

[Daniel P. Berrange]

On Thu, Sep 10, 2015 at 11:12:46AM +0530, Deepak Shetty wrote:
> [snip]
> 
> On Wed, Sep 9, 2015 at 10:37 PM, Raghavendra Talur 
> wrote:
> 
> >
> >
> > From QEMU's perspective, it would be better to use separate fields
> >
> >> (that have type information) than to encode everything in an opaque
> >> URI string.  Fields can do input validation in common code so that
> >> block drivers don't need to check whether something is a valid number,
> >> for example.  Fields can also be listed and their type information can
> >> be displayed so the user knows the expected range of inputs
> >> (self-documenting).
> >>
> >
> > Coming from Gluster side of things,  the variable/option here is tuple of
> > three
> > transport-type
> > server
> > port
> >
> > volname and file name should be the same in all the URIs. Just pointing
> > out here so that implementation can ensure that all URIs have the same
> > volname and filename;
> > which are testvol and a.img in the above example.
> >
> > By fields if you mean something like
> > -drive
> > file=gluster[+transport]://[server[:port]]/volname/image[?socket=...],\
> >file.backup-volfile-server=[tcp:|rdma:|unix:]server2[:port],
> >file.backup-volfile-server=[tcp:|rdma:|unix:]server2[:port]
> >
> 
> Raghavendra,
>   Thanks for pitching in.
> 
> So are you saying that its possible to have different transport types (tcp,
> rdma etc)
> for different gluster server nodes, all of which are part of the same
> cluster ?
> 
> If that is true then in the above suggestion of yours, gluster
> [+transport]://
> doesn't make sense, since it gives a feeling that the transport mentioned
> before :// applies to whole URI, only to be overridden by the later
> file.backup-volfile-server= option
> 
> Maybe then as kwolf mentioned in prev thread of this mail ...
> 
>   -drive 
> driver=gluster,uri[0]=gluster[+transport-type]://server1:24007/testvol/a.img,
> 
> uri[1]=gluster[+transport-type]://server2:24008/testvol/a.img,
> 
> uri[2]=gluster[+transport-type]://server3:24009/testvol/a.img
> 
> seems like a better way of representing things, as then we can
> 
> change transport:server:port for each server

Yep, if you want to be able to control transport, server & port for
each, then that really suggests using a single URI is no longer
appropriate. So I'd concur, that something like Kevin's / Stefan's
suggestions are better bets. This example you give above looks fine
for example.


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

Re: [Qemu-devel] [PATCH] linux-user/main.c: Always set QEMU_LD_PREFIX when interp_prefix is changed

[Chen Gang]

From: peter.mayd...@linaro.org
> Date: Thu, 10 Sep 2015 10:02:27 +0100
>
> On 10 September 2015 at 06:43,  wrote:
>> From: Chen Gang 
>>
>> If qemu sets interp_prfix via command line '-L' instead of environments
>> variable QEMU_LD_PREFIX, it will cause syscall execve() failed. Because
>> the 2nd qemu has no command line '-L'.
>>
>> So qemu need always set QEMU_LD_PREFIX when interp_prefix is changed.
>
> I think this is user error. If you want exec to work automatically
> onto a second QEMU then you need to set up binfmt misc with a
> wrapper and probably the environment variables. I don't
> think we need to turn all our command line switches into
> environment variables: they're not supposed to be somehow
> magically inherited by child QEMU processes.
>

For me, when users type a command line under Linux shell, they always
assume all related executions will know about their commands, they need
not set the environments again (at least, in one process, they assume so).

execve() will not change the pid, so the users will 'feel': they are using only
one process.

I guess all 'users' will support me (this patch will let them a little easier). 
;-)


Thanks.
--
Chen Gang

Open, share, and attitude like air, water, and life which God blessed


  

Re: [Qemu-devel] [PATCH v2 2/2] target-i386: move asm-x86/hyperv.h to standard-headers

[Paolo Bonzini]

On 10/09/2015 11:25, Michael S. Tsirkin wrote:
> > It is needed because kvm headers include  and you don't
> > want to pick the system version.
> 
> I see. Makes sense. Then maybe don't bother with kvm.c either?
> Keeps it consistent ...

kvm.c keeps it consistent between target-i386/kvm.c and
target-i386/cpu.h (which will include standard-headers/asm-x86/hyperv.h
in Denis's patch).

Paolo

Re: [Qemu-devel] [PATCH v2 2/2] target-i386: move asm-x86/hyperv.h to standard-headers

[Michael S. Tsirkin]

On Thu, Sep 10, 2015 at 11:28:03AM +0200, Paolo Bonzini wrote:
> 
> 
> On 10/09/2015 11:25, Michael S. Tsirkin wrote:
> > > It is needed because kvm headers include  and you don't
> > > want to pick the system version.
> > 
> > I see. Makes sense. Then maybe don't bother with kvm.c either?
> > Keeps it consistent ...
> 
> kvm.c keeps it consistent between target-i386/kvm.c and
> target-i386/cpu.h (which will include standard-headers/asm-x86/hyperv.h
> in Denis's patch).
> 
> Paolo

Yes but kvm_para.h uses asm/hyperv.h
MAybe do the same everywhere?

Seems marginally prettier, but you decide, I'm not interested
in pushing this point.

-- 
MST

Re: [Qemu-devel] [PULL 0/19] xen-2015-09-08-tag

[Chen, Tiejun]

xen-host-pci-device.c is only compiled if CONFIG_XEN_PCI_PASSTHROUGH
was set by configure. That won't be the case on OSX or Windows, where
the Xen headers don't exist.



Okay. This actually shouldn't be enabled on Windows so what about this?

diff --git a/hw/pci-host/piix.c b/hw/pci-host/piix.c
index 58a33fb..9a1fcb9 100644
--- a/hw/pci-host/piix.c
+++ b/hw/pci-host/piix.c
@@ -739,6 +739,7 @@ static const TypeInfo i440fx_info = {
 .class_init= i440fx_class_init,
 };

+#ifndef _WIN32
 /* IGD Passthrough Host Bridge. */
 typedef struct {
 uint8_t offset;
@@ -819,6 +820,7 @@ static const TypeInfo igd_passthrough_i440fx_info = {
 .instance_size = sizeof(PCII440FXState),
 .class_init= igd_passthrough_i440fx_class_init,
 };
+#endif

 static const char *i440fx_pcihost_root_bus_path(PCIHostState *host_bridge,
 PCIBus *rootbus)
@@ -861,7 +863,9 @@ static const TypeInfo i440fx_pcihost_info = {
 static void i440fx_register_types(void)
 {
 type_register_static(&i440fx_info);
+#ifndef _WIN32
 type_register_static(&igd_passthrough_i440fx_info);
+#endif
 type_register_static(&piix3_pci_type_info);
 type_register_static(&piix3_info);
 type_register_static(&piix3_xen_info);

Thanks
Tiejun

Re: [Qemu-devel] [RFC 00/20] Do away with TB retranslation

[Dennis Luehring]

Am 10.09.2015 um 09:00 schrieb Artyom Tarasenko:

>strangly your branch doesn't changed anything for pure SPARC64 in my tests -
>i've always completely removed the qemu folder and cleanly rebuild
>(all based on stable shell-scripts)

Can you please show "perf top" of the qemu-system-sparc64 process on
the host, when your g++ compilation is running?


http://pastebin.com/nUkhWTj4

[Qemu-devel] [PATCH v3 3/4] update-linux-headers: copy standard-headers files one by one

[Paolo Bonzini]

cp_virtio is called for both the asm-s390/ and linux/ directories,
so it looks for pci_regs.h and input.h files in asm-s390/ too.  This
makes little sense.  In the next patch we will have the opposite
problem; we want to add asm-x86/hyperv.h, and there's also a
linux/hyperv.h file with unwanted dependencies on additional Linux
uapi headers.  We do not want to copy linux/hyperv.h.

The solution is to make cp_virtio (now renamed to cp_portable) copy
one file only, instead of using the "find" command, and call it multiple
times.  The new function is really just a reindentation of the old one.

Signed-off-by: Paolo Bonzini 
---
 scripts/update-linux-headers.sh | 69 +
 1 file changed, 36 insertions(+), 33 deletions(-)

diff --git a/scripts/update-linux-headers.sh b/scripts/update-linux-headers.sh
index 7f7b592..6a75678 100755
--- a/scripts/update-linux-headers.sh
+++ b/scripts/update-linux-headers.sh
@@ -28,39 +28,32 @@ if [ -z "$output" ]; then
 output="$PWD"
 fi
 
-cp_virtio() {
-from=$1
+cp_portable() {
+f=$1
 to=$2
-virtio=$(find "$from" -name '*virtio*h' -o -name "input.h" -o -name 
"pci_regs.h")
-if [ "$virtio" ]; then
-rm -rf "$to"
-mkdir -p "$to"
-for f in $virtio; do
-if
-grep '#include' "$f" | grep -v -e 'linux/virtio' \
- -e 'linux/types' \
- -e 'stdint' \
- -e 'linux/if_ether' \
- -e 'sys/' \
- > /dev/null
-then
-echo "Unexpected #include in input file $f".
-exit 2
-fi
-
-header=$(basename "$f");
-sed -e 's/__u\([0-9][0-9]*\)/uint\1_t/g' \
--e 's/__s\([0-9][0-9]*\)/int\1_t/g' \
--e 's/__le\([0-9][0-9]*\)/uint\1_t/g' \
--e 's/__be\([0-9][0-9]*\)/uint\1_t/g' \
--e 's/]*\)>/"standard-headers\/linux\/\1"/' \
--e 's/__bitwise__//' \
--e 's/__attribute__((packed))/QEMU_PACKED/' \
--e 's/__inline__/inline/' \
--e '/sys\/ioctl.h/d' \
-"$f" > "$to/$header";
-done
+if
+grep '#include' "$f" | grep -v -e 'linux/virtio' \
+ -e 'linux/types' \
+ -e 'stdint' \
+ -e 'linux/if_ether' \
+ -e 'sys/' \
+ > /dev/null
+then
+echo "Unexpected #include in input file $f".
+exit 2
 fi
+
+header=$(basename "$f");
+sed -e 's/__u\([0-9][0-9]*\)/uint\1_t/g' \
+-e 's/__s\([0-9][0-9]*\)/int\1_t/g' \
+-e 's/__le\([0-9][0-9]*\)/uint\1_t/g' \
+-e 's/__be\([0-9][0-9]*\)/uint\1_t/g' \
+-e 's/]*\)>/"standard-headers\/linux\/\1"/' \
+-e 's/__bitwise__//' \
+-e 's/__attribute__((packed))/QEMU_PACKED/' \
+-e 's/__inline__/inline/' \
+-e '/sys\/ioctl.h/d' \
+"$f" > "$to/$header";
 }
 
 # This will pick up non-directories too (eg "Kconfig") but we will
@@ -93,7 +86,12 @@ for arch in $ARCHLIST; do
 cp "$tmpdir/include/asm/epapr_hcalls.h" 
"$output/linux-headers/asm-powerpc/"
 fi
 
-cp_virtio "$tmpdir/include/asm" 
"$output/include/standard-headers/asm-$arch"
+rm -rf "$output/include/standard-headers/asm-$arch"
+mkdir -p "$output/include/standard-headers/asm-$arch"
+if [ $arch = s390 ]; then
+cp_portable "$tmpdir/include/asm/kvm_virtio.h" 
"$output/include/standard-headers/asm-s390/"
+cp_portable "$tmpdir/include/asm/virtio-ccw.h" 
"$output/include/standard-headers/asm-s390/"
+fi
 done
 
 rm -rf "$output/linux-headers/linux"
@@ -120,7 +118,12 @@ cat <$output/linux-headers/linux/virtio_ring.h
 #include "standard-headers/linux/virtio_ring.h"
 EOF
 
-cp_virtio "$tmpdir/include/linux/" "$output/include/standard-headers/linux"
+rm -rf "$output/include/standard-headers/linux"
+mkdir -p "$output/include/standard-headers/linux"
+for i in "$tmpdir"/include/linux/*virtio*.h "$tmpdir/include/linux/input.h" \
+ "$tmpdir/include/linux/pci_regs.h"; do
+cp_portable "$i" "$output/include/standard-headers/linux"
+done
 
 cat <$output/include/standard-headers/linux/types.h
 #include 
-- 
2.4.3

[Qemu-devel] [PATCH v3 4/4] target-i386: move asm-x86/hyperv.h to standard-headers

[Paolo Bonzini]

The Hyper-V definitions are an industry standard and can be used
from code that is not KVM-specific.

Signed-off-by: Paolo Bonzini 
---
 .../standard-headers}/asm-x86/hyperv.h |  10 +-
 linux-headers/asm-x86/hyperv.h | 253 +
 scripts/update-linux-headers.sh|   9 +-
 target-i386/kvm.c  |   2 +-
 4 files changed, 13 insertions(+), 261 deletions(-)
 copy {linux-headers => include/standard-headers}/asm-x86/hyperv.h (98%)

diff --git a/linux-headers/asm-x86/hyperv.h 
b/include/standard-headers/asm-x86/hyperv.h
similarity index 98%
copy from linux-headers/asm-x86/hyperv.h
copy to include/standard-headers/asm-x86/hyperv.h
index f36d56b..a2123ca 100644
--- a/linux-headers/asm-x86/hyperv.h
+++ b/include/standard-headers/asm-x86/hyperv.h
@@ -1,7 +1,7 @@
 #ifndef _ASM_X86_HYPERV_H
 #define _ASM_X86_HYPERV_H
 
-#include 
+#include "standard-headers/linux/types.h"
 
 /*
  * The below CPUID leaves are present if VersionAndFeatures.HypervisorPresent
@@ -243,10 +243,10 @@
 #define HV_STATUS_INSUFFICIENT_BUFFERS 19
 
 typedef struct _HV_REFERENCE_TSC_PAGE {
-   __u32 tsc_sequence;
-   __u32 res1;
-   __u64 tsc_scale;
-   __s64 tsc_offset;
+   uint32_t tsc_sequence;
+   uint32_t res1;
+   uint64_t tsc_scale;
+   int64_t tsc_offset;
 } HV_REFERENCE_TSC_PAGE, *PHV_REFERENCE_TSC_PAGE;
 
 #endif
diff --git a/linux-headers/asm-x86/hyperv.h b/linux-headers/asm-x86/hyperv.h
index f36d56b..01af4d8 100644
--- a/linux-headers/asm-x86/hyperv.h
+++ b/linux-headers/asm-x86/hyperv.h
@@ -1,252 +1 @@
-#ifndef _ASM_X86_HYPERV_H
-#define _ASM_X86_HYPERV_H
-
-#include 
-
-/*
- * The below CPUID leaves are present if VersionAndFeatures.HypervisorPresent
- * is set by CPUID(HvCpuIdFunctionVersionAndFeatures).
- */
-#define HYPERV_CPUID_VENDOR_AND_MAX_FUNCTIONS  0x4000
-#define HYPERV_CPUID_INTERFACE 0x4001
-#define HYPERV_CPUID_VERSION   0x4002
-#define HYPERV_CPUID_FEATURES  0x4003
-#define HYPERV_CPUID_ENLIGHTMENT_INFO  0x4004
-#define HYPERV_CPUID_IMPLEMENT_LIMITS  0x4005
-
-#define HYPERV_HYPERVISOR_PRESENT_BIT  0x8000
-#define HYPERV_CPUID_MIN   0x4005
-#define HYPERV_CPUID_MAX   0x4000
-
-/*
- * Feature identification. EAX indicates which features are available
- * to the partition based upon the current partition privileges.
- */
-
-/* VP Runtime (HV_X64_MSR_VP_RUNTIME) available */
-#define HV_X64_MSR_VP_RUNTIME_AVAILABLE(1 << 0)
-/* Partition Reference Counter (HV_X64_MSR_TIME_REF_COUNT) available*/
-#define HV_X64_MSR_TIME_REF_COUNT_AVAILABLE(1 << 1)
-
-/* A partition's reference time stamp counter (TSC) page */
-#define HV_X64_MSR_REFERENCE_TSC   0x4021
-
-/*
- * There is a single feature flag that signifies the presence of the MSR
- * that can be used to retrieve both the local APIC Timer frequency as
- * well as the TSC frequency.
- */
-
-/* Local APIC timer frequency MSR (HV_X64_MSR_APIC_FREQUENCY) is available */
-#define HV_X64_MSR_APIC_FREQUENCY_AVAILABLE (1 << 11)
-
-/* TSC frequency MSR (HV_X64_MSR_TSC_FREQUENCY) is available */
-#define HV_X64_MSR_TSC_FREQUENCY_AVAILABLE (1 << 11)
-
-/*
- * Basic SynIC MSRs (HV_X64_MSR_SCONTROL through HV_X64_MSR_EOM
- * and HV_X64_MSR_SINT0 through HV_X64_MSR_SINT15) available
- */
-#define HV_X64_MSR_SYNIC_AVAILABLE (1 << 2)
-/*
- * Synthetic Timer MSRs (HV_X64_MSR_STIMER0_CONFIG through
- * HV_X64_MSR_STIMER3_COUNT) available
- */
-#define HV_X64_MSR_SYNTIMER_AVAILABLE  (1 << 3)
-/*
- * APIC access MSRs (HV_X64_MSR_EOI, HV_X64_MSR_ICR and HV_X64_MSR_TPR)
- * are available
- */
-#define HV_X64_MSR_APIC_ACCESS_AVAILABLE   (1 << 4)
-/* Hypercall MSRs (HV_X64_MSR_GUEST_OS_ID and HV_X64_MSR_HYPERCALL) available*/
-#define HV_X64_MSR_HYPERCALL_AVAILABLE (1 << 5)
-/* Access virtual processor index MSR (HV_X64_MSR_VP_INDEX) available*/
-#define HV_X64_MSR_VP_INDEX_AVAILABLE  (1 << 6)
-/* Virtual system reset MSR (HV_X64_MSR_RESET) is available*/
-#define HV_X64_MSR_RESET_AVAILABLE (1 << 7)
- /*
-  * Access statistics pages MSRs (HV_X64_MSR_STATS_PARTITION_RETAIL_PAGE,
-  * HV_X64_MSR_STATS_PARTITION_INTERNAL_PAGE, HV_X64_MSR_STATS_VP_RETAIL_PAGE,
-  * HV_X64_MSR_STATS_VP_INTERNAL_PAGE) available
-  */
-#define HV_X64_MSR_STAT_PAGES_AVAILABLE(1 << 8)
-
-/*
- * Feature identification: EBX indicates which flags were specified at
- * partition creation. The format is the same as the partition creation
- * flag structure defined in section Partition Creation Flags.
- */
-#define HV_X64_CREATE_PARTITIONS   (1 << 0)
-#define HV_X64_ACCESS_PARTITION_ID (1 << 1)
-#define HV_X64_ACCESS_MEMORY_POOL  (1 << 2)
-#define HV_X64_ADJUST_MESSAGE_BUFFERS  (1 << 3)
-#define HV_X64_POS

[Qemu-devel] [PATCH v3 1/4] pci: remove Link Training error from AER error list

[Paolo Bonzini]

The spec says:

Undefined – The value read from this bit is
undefined. In previous versions of this
specification, this bit was used to indicate a Link
Training Error. System software must ignore the
value read from this bit. System software is
permitted to write any value to this bit.

Do not allow injecting it.

Suggested-by: Michael S. Tsirkin 
Signed-off-by: Paolo Bonzini 
---
 hw/pci/pcie_aer.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/hw/pci/pcie_aer.c b/hw/pci/pcie_aer.c
index f1847ac..46e0ad8 100644
--- a/hw/pci/pcie_aer.c
+++ b/hw/pci/pcie_aer.c
@@ -827,10 +827,6 @@ typedef struct PCIEAERErrorName {
  */
 static const struct PCIEAERErrorName pcie_aer_error_list[] = {
 {
-.name = "TRAIN",
-.val = PCI_ERR_UNC_TRAIN,
-.correctable = false,
-}, {
 .name = "DLP",
 .val = PCI_ERR_UNC_DLP,
 .correctable = false,
-- 
2.4.3

[Qemu-devel] [PATCH v3 0/2] update-linux-headers changes

[Paolo Bonzini]

Patches 1 and 2 updates the Linux headers, which required an unexpected change
to hw/pci/pcie_aer.c.

Patches 3 and 4 modify the update-linux-headers script so that asm-x86/hyperv.h
can be moved to standard-headers.  This is required by the Hyper-V crash
MSR patches, which use a Hyper-V define in cpu.h.

Please Ack so that I can include it together with the Hyper-V crash MSR
patches.

Paolo

v1->v2: Drop unwanted hunk from patch 1 [Cornelia]
Suggested cleanups to patch 2 [Cornelia]

v2->v3: Separate the hyperv.h and cp_portable changes [mst]
Drop TRAIN entry from list of AER errors [mst]
Drop empty line [mst]

v2->v3 diff comes below.

Paolo Bonzini (4):
  pci: remove Link Training error from AER error list
  update Linux headers to 4.2
  update-linux-headers: copy standard-headers files one by one
  target-i386: move asm-x86/hyperv.h to standard-headers

 hw/pci/pcie_aer.c  |   4 -
 .../standard-headers}/asm-x86/hyperv.h |  12 +-
 include/standard-headers/linux/pci_regs.h  | 381 +++--
 include/standard-headers/linux/virtio_ring.h   |   3 +-
 linux-headers/asm-x86/hyperv.h | 251 +-
 linux-headers/asm-x86/kvm.h|   4 +-
 scripts/update-linux-headers.sh|  77 +++--
 target-i386/kvm.c  |   2 +-
 8 files changed, 340 insertions(+), 394 deletions(-)
 copy {linux-headers => include/standard-headers}/asm-x86/hyperv.h (97%)

diff --git a/hw/pci/pcie_aer.c b/hw/pci/pcie_aer.c
index 8e4bd56..46e0ad8 100644
--- a/hw/pci/pcie_aer.c
+++ b/hw/pci/pcie_aer.c
@@ -827,10 +827,6 @@ typedef struct PCIEAERErrorName {
  */
 static const struct PCIEAERErrorName pcie_aer_error_list[] = {
 {
-.name = "UND",
-.val = PCI_ERR_UNC_UND,
-.correctable = false,
-}, {
 .name = "DLP",
 .val = PCI_ERR_UNC_DLP,
 .correctable = false,
diff --git a/scripts/update-linux-headers.sh b/scripts/update-linux-headers.sh
index 2f25e84..11076191 100755
--- a/scripts/update-linux-headers.sh
+++ b/scripts/update-linux-headers.sh
@@ -61,7 +61,6 @@ cp_portable() {
 ARCHLIST=$(cd "$linux/arch" && echo *)
 
 for arch in $ARCHLIST; do
-
 # Discard anything which isn't a KVM-supporting architecture
 if ! [ -e "$linux/arch/$arch/include/asm/kvm.h" ] &&
 ! [ -e "$linux/arch/$arch/include/uapi/asm/kvm.h" ] ; then
-- 
2.4.3

Re: [Qemu-devel] [PATCH v3 1/4] pci: remove Link Training error from AER error list

[Michael S. Tsirkin]

On Thu, Sep 10, 2015 at 11:39:35AM +0200, Paolo Bonzini wrote:
> The spec says:
> 
> Undefined – The value read from this bit is
> undefined. In previous versions of this
> specification, this bit was used to indicate a Link
> Training Error. System software must ignore the
> value read from this bit. System software is
> permitted to write any value to this bit.
> 
> Do not allow injecting it.
> 
> Suggested-by: Michael S. Tsirkin 
> Signed-off-by: Paolo Bonzini 

Reviewed-by: Michael S. Tsirkin 

> ---
>  hw/pci/pcie_aer.c | 4 
>  1 file changed, 4 deletions(-)
> 
> diff --git a/hw/pci/pcie_aer.c b/hw/pci/pcie_aer.c
> index f1847ac..46e0ad8 100644
> --- a/hw/pci/pcie_aer.c
> +++ b/hw/pci/pcie_aer.c
> @@ -827,10 +827,6 @@ typedef struct PCIEAERErrorName {
>   */
>  static const struct PCIEAERErrorName pcie_aer_error_list[] = {
>  {
> -.name = "TRAIN",
> -.val = PCI_ERR_UNC_TRAIN,
> -.correctable = false,
> -}, {
>  .name = "DLP",
>  .val = PCI_ERR_UNC_DLP,
>  .correctable = false,
> -- 
> 2.4.3
> 

Re: [Qemu-devel] [PATCH v2 2/2] target-i386: move asm-x86/hyperv.h to standard-headers

[Paolo Bonzini]

On 10/09/2015 11:32, Michael S. Tsirkin wrote:
> > kvm.c keeps it consistent between target-i386/kvm.c and
> > target-i386/cpu.h (which will include standard-headers/asm-x86/hyperv.h
> > in Denis's patch).
> 
> Yes but kvm_para.h uses asm/hyperv.h
> MAybe do the same everywhere?

Unfortunately you cannot use asm/hyperv.h in target-i386/cpu.h, because
Win32 builds do not have -Ilinux-headers.  That's the reason why I
needed to move it to standard-headers. :(

Paolo

> Seems marginally prettier, but you decide, I'm not interested
> in pushing this point.

[Qemu-devel] [PATCH v3 2/4] update Linux headers to 4.2

[Paolo Bonzini]

Signed-off-by: Paolo Bonzini 
---
 include/standard-headers/linux/pci_regs.h| 381 ---
 include/standard-headers/linux/virtio_ring.h |   3 +-
 linux-headers/asm-x86/hyperv.h   |   2 +
 linux-headers/asm-x86/kvm.h  |   4 +-
 scripts/update-linux-headers.sh  |   1 +
 5 files changed, 292 insertions(+), 99 deletions(-)

diff --git a/include/standard-headers/linux/pci_regs.h 
b/include/standard-headers/linux/pci_regs.h
index 57e8c80..413417f 100644
--- a/include/standard-headers/linux/pci_regs.h
+++ b/include/standard-headers/linux/pci_regs.h
@@ -13,10 +13,10 @@
  * PCI to PCI Bridge Specification
  * PCI System Design Guide
  *
- * For hypertransport information, please consult the following manuals
- * from http://www.hypertransport.org
+ * For HyperTransport information, please consult the following manuals
+ * from http://www.hypertransport.org
  *
- * The Hypertransport I/O Link Specification
+ * The HyperTransport I/O Link Specification
  */
 
 #ifndef LINUX_PCI_REGS_H
@@ -26,6 +26,7 @@
  * Under PCI, each device has 256 bytes of configuration address space,
  * of which the first 64 bytes are standardized as follows:
  */
+#define PCI_STD_HEADER_SIZEOF  64
 #define PCI_VENDOR_ID  0x00/* 16 bits */
 #define PCI_DEVICE_ID  0x02/* 16 bits */
 #define PCI_COMMAND0x04/* 16 bits */
@@ -36,7 +37,7 @@
 #define  PCI_COMMAND_INVALIDATE0x10/* Use memory write and 
invalidate */
 #define  PCI_COMMAND_VGA_PALETTE 0x20  /* Enable palette snooping */
 #define  PCI_COMMAND_PARITY0x40/* Enable parity checking */
-#define  PCI_COMMAND_WAIT  0x80/* Enable address/data stepping */
+#define  PCI_COMMAND_WAIT  0x80/* Enable address/data stepping */
 #define  PCI_COMMAND_SERR  0x100   /* Enable SERR */
 #define  PCI_COMMAND_FAST_BACK 0x200   /* Enable back-to-back writes */
 #define  PCI_COMMAND_INTX_DISABLE 0x400 /* INTx Emulation Disable */
@@ -44,7 +45,7 @@
 #define PCI_STATUS 0x06/* 16 bits */
 #define  PCI_STATUS_INTERRUPT  0x08/* Interrupt status */
 #define  PCI_STATUS_CAP_LIST   0x10/* Support Capability List */
-#define  PCI_STATUS_66MHZ  0x20/* Support 66 Mhz PCI 2.1 bus */
+#define  PCI_STATUS_66MHZ  0x20/* Support 66 MHz PCI 2.1 bus */
 #define  PCI_STATUS_UDF0x40/* Support User Definable 
Features [obsolete] */
 #define  PCI_STATUS_FAST_BACK  0x80/* Accept fast-back to back */
 #define  PCI_STATUS_PARITY 0x100   /* Detected parity error */
@@ -125,7 +126,8 @@
 #define  PCI_IO_RANGE_TYPE_MASK0x0fUL  /* I/O bridging type */
 #define  PCI_IO_RANGE_TYPE_16  0x00
 #define  PCI_IO_RANGE_TYPE_32  0x01
-#define  PCI_IO_RANGE_MASK (~0x0fUL)
+#define  PCI_IO_RANGE_MASK (~0x0fUL) /* Standard 4K I/O windows */
+#define  PCI_IO_1K_RANGE_MASK  (~0x03UL) /* Intel 1K I/O windows */
 #define PCI_SEC_STATUS 0x1e/* Secondary status register, only bit 
14 used */
 #define PCI_MEMORY_BASE0x20/* Memory range behind */
 #define PCI_MEMORY_LIMIT   0x22
@@ -203,16 +205,18 @@
 #define  PCI_CAP_ID_CHSWP  0x06/* CompactPCI HotSwap */
 #define  PCI_CAP_ID_PCIX   0x07/* PCI-X */
 #define  PCI_CAP_ID_HT 0x08/* HyperTransport */
-#define  PCI_CAP_ID_VNDR   0x09/* Vendor specific */
+#define  PCI_CAP_ID_VNDR   0x09/* Vendor-Specific */
 #define  PCI_CAP_ID_DBG0x0A/* Debug port */
 #define  PCI_CAP_ID_CCRC   0x0B/* CompactPCI Central Resource Control 
*/
-#define  PCI_CAP_ID_SHPC   0x0C/* PCI Standard Hot-Plug Controller */
+#define  PCI_CAP_ID_SHPC   0x0C/* PCI Standard Hot-Plug Controller */
 #define  PCI_CAP_ID_SSVID  0x0D/* Bridge subsystem vendor/device ID */
 #define  PCI_CAP_ID_AGP3   0x0E/* AGP Target PCI-PCI bridge */
-#define  PCI_CAP_ID_EXP0x10/* PCI Express */
+#define  PCI_CAP_ID_SECDEV 0x0F/* Secure Device */
+#define  PCI_CAP_ID_EXP0x10/* PCI Express */
 #define  PCI_CAP_ID_MSIX   0x11/* MSI-X */
-#define  PCI_CAP_ID_SATA   0x12/* Serial ATA */
+#define  PCI_CAP_ID_SATA   0x12/* SATA Data/Index Conf. */
 #define  PCI_CAP_ID_AF 0x13/* PCI Advanced Features */
+#define  PCI_CAP_ID_MAXPCI_CAP_ID_AF
 #define PCI_CAP_LIST_NEXT  1   /* Next capability in the list */
 #define PCI_CAP_FLAGS  2   /* Capability defined flags (16 bits) */
 #define PCI_CAP_SIZEOF 4
@@ -264,8 +268,8 @@
 #define  PCI_AGP_COMMAND_RQ_MASK 0xff00  /* Master: Maximum number of 
requests */
 #define  PCI_AGP_COMMAND_SBA   0x0200  /* Sideband addressing enabled */
 #define  PCI_AGP_COMMAND_AGP   0x0100  /* Allow processing of AGP transactions 
*/
-#define  PCI_AGP_COMMAND_64BIT 0x0020  /* Allow processing of 64-bit addresses 
*/
-#define  PCI_AGP_COMM

Re: [Qemu-devel] [PATCH v3 3/4] update-linux-headers: copy standard-headers files one by one

[Michael S. Tsirkin]

On Thu, Sep 10, 2015 at 11:39:37AM +0200, Paolo Bonzini wrote:
> cp_virtio is called for both the asm-s390/ and linux/ directories,
> so it looks for pci_regs.h and input.h files in asm-s390/ too.  This
> makes little sense.  In the next patch we will have the opposite
> problem; we want to add asm-x86/hyperv.h, and there's also a
> linux/hyperv.h file with unwanted dependencies on additional Linux
> uapi headers.  We do not want to copy linux/hyperv.h.
> 
> The solution is to make cp_virtio (now renamed to cp_portable) copy
> one file only, instead of using the "find" command, and call it multiple
> times.  The new function is really just a reindentation of the old one.
> 
> Signed-off-by: Paolo Bonzini 

Reviewed-by: Michael S. Tsirkin 

> ---
>  scripts/update-linux-headers.sh | 69 
> +
>  1 file changed, 36 insertions(+), 33 deletions(-)
> 
> diff --git a/scripts/update-linux-headers.sh b/scripts/update-linux-headers.sh
> index 7f7b592..6a75678 100755
> --- a/scripts/update-linux-headers.sh
> +++ b/scripts/update-linux-headers.sh
> @@ -28,39 +28,32 @@ if [ -z "$output" ]; then
>  output="$PWD"
>  fi
>  
> -cp_virtio() {
> -from=$1
> +cp_portable() {
> +f=$1
>  to=$2
> -virtio=$(find "$from" -name '*virtio*h' -o -name "input.h" -o -name 
> "pci_regs.h")
> -if [ "$virtio" ]; then
> -rm -rf "$to"
> -mkdir -p "$to"
> -for f in $virtio; do
> -if
> -grep '#include' "$f" | grep -v -e 'linux/virtio' \
> - -e 'linux/types' \
> - -e 'stdint' \
> - -e 'linux/if_ether' \
> - -e 'sys/' \
> - > /dev/null
> -then
> -echo "Unexpected #include in input file $f".
> -exit 2
> -fi
> -
> -header=$(basename "$f");
> -sed -e 's/__u\([0-9][0-9]*\)/uint\1_t/g' \
> --e 's/__s\([0-9][0-9]*\)/int\1_t/g' \
> --e 's/__le\([0-9][0-9]*\)/uint\1_t/g' \
> --e 's/__be\([0-9][0-9]*\)/uint\1_t/g' \
> --e 's/]*\)>/"standard-headers\/linux\/\1"/' \
> --e 's/__bitwise__//' \
> --e 's/__attribute__((packed))/QEMU_PACKED/' \
> --e 's/__inline__/inline/' \
> --e '/sys\/ioctl.h/d' \
> -"$f" > "$to/$header";
> -done
> +if
> +grep '#include' "$f" | grep -v -e 'linux/virtio' \
> + -e 'linux/types' \
> + -e 'stdint' \
> + -e 'linux/if_ether' \
> + -e 'sys/' \
> + > /dev/null
> +then
> +echo "Unexpected #include in input file $f".
> +exit 2
>  fi
> +
> +header=$(basename "$f");
> +sed -e 's/__u\([0-9][0-9]*\)/uint\1_t/g' \
> +-e 's/__s\([0-9][0-9]*\)/int\1_t/g' \
> +-e 's/__le\([0-9][0-9]*\)/uint\1_t/g' \
> +-e 's/__be\([0-9][0-9]*\)/uint\1_t/g' \
> +-e 's/]*\)>/"standard-headers\/linux\/\1"/' \
> +-e 's/__bitwise__//' \
> +-e 's/__attribute__((packed))/QEMU_PACKED/' \
> +-e 's/__inline__/inline/' \
> +-e '/sys\/ioctl.h/d' \
> +"$f" > "$to/$header";
>  }
>  
>  # This will pick up non-directories too (eg "Kconfig") but we will
> @@ -93,7 +86,12 @@ for arch in $ARCHLIST; do
>  cp "$tmpdir/include/asm/epapr_hcalls.h" 
> "$output/linux-headers/asm-powerpc/"
>  fi
>  
> -cp_virtio "$tmpdir/include/asm" 
> "$output/include/standard-headers/asm-$arch"
> +rm -rf "$output/include/standard-headers/asm-$arch"
> +mkdir -p "$output/include/standard-headers/asm-$arch"
> +if [ $arch = s390 ]; then
> +cp_portable "$tmpdir/include/asm/kvm_virtio.h" 
> "$output/include/standard-headers/asm-s390/"
> +cp_portable "$tmpdir/include/asm/virtio-ccw.h" 
> "$output/include/standard-headers/asm-s390/"
> +fi
>  done
>  
>  rm -rf "$output/linux-headers/linux"
> @@ -120,7 +118,12 @@ cat <$output/linux-headers/linux/virtio_ring.h
>  #include "standard-headers/linux/virtio_ring.h"
>  EOF
>  
> -cp_virtio "$tmpdir/include/linux/" "$output/include/standard-headers/linux"
> +rm -rf "$output/include/standard-headers/linux"
> +mkdir -p "$output/include/standard-headers/linux"
> +for i in "$tmpdir"/include/linux/*virtio*.h "$tmpdir/include/linux/input.h" \
> + "$tmpdir/include/linux/pci_regs.h"; do
> +cp_portable "$i" "$output/include/standard-headers/linux"
> +done
>  
>  cat <$output/include/standard-headers/linux/types.h
>  #include 
> -- 
> 2.4.3
> 

Re: [Qemu-devel] [PATCH v3 2/4] update Linux headers to 4.2

[Michael S. Tsirkin]

On Thu, Sep 10, 2015 at 11:39:36AM +0200, Paolo Bonzini wrote:
> Signed-off-by: Paolo Bonzini 

Reviewed-by: Michael S. Tsirkin 

> ---
>  include/standard-headers/linux/pci_regs.h| 381 
> ---
>  include/standard-headers/linux/virtio_ring.h |   3 +-
>  linux-headers/asm-x86/hyperv.h   |   2 +
>  linux-headers/asm-x86/kvm.h  |   4 +-
>  scripts/update-linux-headers.sh  |   1 +
>  5 files changed, 292 insertions(+), 99 deletions(-)
> 
> diff --git a/include/standard-headers/linux/pci_regs.h 
> b/include/standard-headers/linux/pci_regs.h
> index 57e8c80..413417f 100644
> --- a/include/standard-headers/linux/pci_regs.h
> +++ b/include/standard-headers/linux/pci_regs.h
> @@ -13,10 +13,10 @@
>   *   PCI to PCI Bridge Specification
>   *   PCI System Design Guide
>   *
> - *   For hypertransport information, please consult the following manuals
> - *   from http://www.hypertransport.org
> + *   For HyperTransport information, please consult the following manuals
> + *   from http://www.hypertransport.org
>   *
> - *   The Hypertransport I/O Link Specification
> + *   The HyperTransport I/O Link Specification
>   */
>  
>  #ifndef LINUX_PCI_REGS_H
> @@ -26,6 +26,7 @@
>   * Under PCI, each device has 256 bytes of configuration address space,
>   * of which the first 64 bytes are standardized as follows:
>   */
> +#define PCI_STD_HEADER_SIZEOF64
>  #define PCI_VENDOR_ID0x00/* 16 bits */
>  #define PCI_DEVICE_ID0x02/* 16 bits */
>  #define PCI_COMMAND  0x04/* 16 bits */
> @@ -36,7 +37,7 @@
>  #define  PCI_COMMAND_INVALIDATE  0x10/* Use memory write and 
> invalidate */
>  #define  PCI_COMMAND_VGA_PALETTE 0x20/* Enable palette snooping */
>  #define  PCI_COMMAND_PARITY  0x40/* Enable parity checking */
> -#define  PCI_COMMAND_WAIT0x80/* Enable address/data stepping */
> +#define  PCI_COMMAND_WAIT0x80/* Enable address/data stepping */
>  #define  PCI_COMMAND_SERR0x100   /* Enable SERR */
>  #define  PCI_COMMAND_FAST_BACK   0x200   /* Enable back-to-back writes */
>  #define  PCI_COMMAND_INTX_DISABLE 0x400 /* INTx Emulation Disable */
> @@ -44,7 +45,7 @@
>  #define PCI_STATUS   0x06/* 16 bits */
>  #define  PCI_STATUS_INTERRUPT0x08/* Interrupt status */
>  #define  PCI_STATUS_CAP_LIST 0x10/* Support Capability List */
> -#define  PCI_STATUS_66MHZ0x20/* Support 66 Mhz PCI 2.1 bus */
> +#define  PCI_STATUS_66MHZ0x20/* Support 66 MHz PCI 2.1 bus */
>  #define  PCI_STATUS_UDF  0x40/* Support User Definable 
> Features [obsolete] */
>  #define  PCI_STATUS_FAST_BACK0x80/* Accept fast-back to back */
>  #define  PCI_STATUS_PARITY   0x100   /* Detected parity error */
> @@ -125,7 +126,8 @@
>  #define  PCI_IO_RANGE_TYPE_MASK  0x0fUL  /* I/O bridging type */
>  #define  PCI_IO_RANGE_TYPE_160x00
>  #define  PCI_IO_RANGE_TYPE_320x01
> -#define  PCI_IO_RANGE_MASK   (~0x0fUL)
> +#define  PCI_IO_RANGE_MASK   (~0x0fUL) /* Standard 4K I/O windows */
> +#define  PCI_IO_1K_RANGE_MASK(~0x03UL) /* Intel 1K I/O windows */
>  #define PCI_SEC_STATUS   0x1e/* Secondary status register, 
> only bit 14 used */
>  #define PCI_MEMORY_BASE  0x20/* Memory range behind */
>  #define PCI_MEMORY_LIMIT 0x22
> @@ -203,16 +205,18 @@
>  #define  PCI_CAP_ID_CHSWP0x06/* CompactPCI HotSwap */
>  #define  PCI_CAP_ID_PCIX 0x07/* PCI-X */
>  #define  PCI_CAP_ID_HT   0x08/* HyperTransport */
> -#define  PCI_CAP_ID_VNDR 0x09/* Vendor specific */
> +#define  PCI_CAP_ID_VNDR 0x09/* Vendor-Specific */
>  #define  PCI_CAP_ID_DBG  0x0A/* Debug port */
>  #define  PCI_CAP_ID_CCRC 0x0B/* CompactPCI Central Resource Control 
> */
> -#define  PCI_CAP_ID_SHPC 0x0C/* PCI Standard Hot-Plug Controller */
> +#define  PCI_CAP_ID_SHPC 0x0C/* PCI Standard Hot-Plug Controller */
>  #define  PCI_CAP_ID_SSVID0x0D/* Bridge subsystem vendor/device ID */
>  #define  PCI_CAP_ID_AGP3 0x0E/* AGP Target PCI-PCI bridge */
> -#define  PCI_CAP_ID_EXP  0x10/* PCI Express */
> +#define  PCI_CAP_ID_SECDEV   0x0F/* Secure Device */
> +#define  PCI_CAP_ID_EXP  0x10/* PCI Express */
>  #define  PCI_CAP_ID_MSIX 0x11/* MSI-X */
> -#define  PCI_CAP_ID_SATA 0x12/* Serial ATA */
> +#define  PCI_CAP_ID_SATA 0x12/* SATA Data/Index Conf. */
>  #define  PCI_CAP_ID_AF   0x13/* PCI Advanced Features */
> +#define  PCI_CAP_ID_MAX  PCI_CAP_ID_AF
>  #define PCI_CAP_LIST_NEXT1   /* Next capability in the list */
>  #define PCI_CAP_FLAGS2   /* Capability defined flags (16 
> bits) */
>  #define PCI_CAP_SIZEOF   4
> @@ -264,8 +268,8 @@
>  #define  PCI_AGP_COMMAND_RQ_MASK 0xff00  /* Master: M

Re: [Qemu-devel] [PATCH 3/4] ide-test: add cdrom pio test

[Markus Armbruster]

John Snow  writes:

> Add a simple read test for ATAPI devices,
> using the PIO mechanism.
>
> Signed-off-by: John Snow 
> ---
>  tests/ide-test.c | 144 
> +++
>  1 file changed, 144 insertions(+)
>
> diff --git a/tests/ide-test.c b/tests/ide-test.c
> index 4a07e3a..90524e3 100644
> --- a/tests/ide-test.c
> +++ b/tests/ide-test.c
> @@ -45,6 +45,12 @@
>  #define IDE_BASE 0x1f0
>  #define IDE_PRIMARY_IRQ 14
>  
> +#define ATAPI_BLOCK_SIZE 2048
> +
> +/* How many bytes to receive via ATAPI PIO at one time.
> + * Must be less than 0x. */
> +#define BYTE_COUNT_LIMIT 5120
> +
>  enum {
>  reg_data= 0x0,
>  reg_nsectors= 0x2,
> @@ -80,6 +86,7 @@ enum {
>  CMD_WRITE_DMA   = 0xca,
>  CMD_FLUSH_CACHE = 0xe7,
>  CMD_IDENTIFY= 0xec,
> +CMD_PACKET  = 0xa0,
>  
>  CMDF_ABORT  = 0x100,
>  CMDF_NO_BM  = 0x200,
> @@ -585,6 +592,140 @@ static void test_isa_retry_flush(const char *machine)
>  test_retry_flush("isapc");
>  }
>  
> +typedef struct Read10CDB {
> +uint8_t opcode;
> +uint8_t flags;
> +uint32_t lba;
> +uint8_t reserved;
> +uint16_t nblocks;
> +uint8_t control;
> +uint16_t padding;
> +} __attribute__((__packed__)) Read10CDB;
> +
> +static void send_scsi_cdb_read10(uint32_t lba, uint16_t nblocks)
> +{
> +Read10CDB pkt = { .padding = 0 };
> +int i;
> +
> +/* Construct SCSI CDB packet */
> +pkt.opcode = 0x28;
> +pkt.lba = cpu_to_be32(lba);
> +pkt.nblocks = cpu_to_be16(nblocks);
> +
> +/* Send Packet */
> +for (i = 0; i < sizeof(Read10CDB)/2; i++) {
> +outw(IDE_BASE + reg_data, ((uint16_t *)&pkt)[i]);

Requires pkt to be suitable aligned.  It is.

> +}
> +}
> +
> +static void nsleep(int64_t nsecs)
> +{
> +const struct timespec val = { .tv_nsec = nsecs };
> +nanosleep(&val, NULL);
> +clock_set(nsecs);
> +}
> +
> +static uint8_t ide_wait_clear(uint8_t flag)
> +{
> +int i;
> +uint8_t data;
> +
> +/* Wait with a 5 second timeout */
> +for (i = 0; i <= 1250; i++) {
> +data = inb(IDE_BASE + reg_status);
> +if (!(data & flag)) {
> +return data;
> +}
> +nsleep(400);
> +}
> +g_assert_not_reached();
> +return 0xff;

Unreachable code, not needed as long as g_assert_not_reached() is
properly annotated noreturn.

> +}
> +
> +static void cdrom_pio_impl(int nblocks)
> +{
> +FILE *fh;
> +size_t patt_len = ATAPI_BLOCK_SIZE * MAX(16, nblocks);
> +char *pattern = g_malloc(patt_len);
> +size_t rxsize = ATAPI_BLOCK_SIZE * nblocks;
> +char *rx = g_malloc0(rxsize);
> +int i, j;
> +uint8_t data;
> +uint16_t limit;
> +
> +/* Prepopulate the CDROM with an interesting pattern */
> +generate_pattern(pattern, patt_len, ATAPI_BLOCK_SIZE);
> +fh = fopen(tmp_path, "w+");
> +fwrite(pattern, ATAPI_BLOCK_SIZE, MAX(16, nblocks), fh);

I guess I would've avoided repeating MAX(16, nblocks), but it'll do.

> +fclose(fh);
> +
> +ide_test_start(
> +  "-drive file=%s,if=ide,media=cdrom,cache=writeback,format=raw", 
> tmp_path);

Legacy syntax.  Okay.

> +qtest_irq_intercept_in(global_qtest, "ioapic");
> +
> +/* PACKET command on device 0 */
> +outb(IDE_BASE + reg_device, 0);
> +outb(IDE_BASE + reg_lba_middle, BYTE_COUNT_LIMIT & 0xFF);
> +outb(IDE_BASE + reg_lba_high, (BYTE_COUNT_LIMIT >> 8 & 0xFF));
> +outb(IDE_BASE + reg_command, CMD_PACKET);

Ignorant question: why no reg_lba_low?

> +/* HPD0: Check_Status_A State */
> +nsleep(400);
> +data = ide_wait_clear(BSY);

Ignorant question: why do you need to wait 400ns before you wait?

> +/* HPD1: Send_Packet State */
> +assert_bit_set(data, DRQ | DRDY);
> +assert_bit_clear(data, ERR | DF | BSY);
> +
> +/* SCSI CDB (READ10) -- read n*2048 bytes from block 0 */
> +send_scsi_cdb_read10(0, nblocks);
> +
> +/* HPD3: INTRQ_Wait */
> +i = 0;
> +do {
> +data = get_irq(IDE_PRIMARY_IRQ);
> +nsleep(400);
> +i++;
> +g_assert_cmpint(i, <=, 1250);
> +} while (!data);

Similar to ide_wait_clear().  Why do you need to nsleep() after
get_irq() returned non-zero?

> +
> +/* HPD2: Check_Status_B */
> +data = ide_wait_clear(BSY);
> +assert_bit_set(data, DRQ | DRDY);
> +assert_bit_clear(data, ERR | DF | BSY);
> +
> +/* Read data back: occurs in bursts of 'BYTE_COUNT_LIMIT' bytes.
> + * If BYTE_COUNT_LIMIT is odd, we transfer BYTE_COUNT_LIMIT - 1 bytes.
> + * We allow an odd limit only when the remaining transfer size is
> + * less than BYTE_COUNT_LIMIT.
> + * For our purposes, we can only request even multiples, so do not
> + * attempt to read remainders. */
> +limit = BYTE_COUNT_LIMIT & ~1;

Does nothing, BYTE_COUNT_LIMIT is 5120.  Build-time assertion
!(BYTE_COUNT_LIMIT & 1) would do.

> +for (i = 0; i < DIV_ROUND_UP(rxsize, limit); i++) {
> +  

Re: [Qemu-devel] [PATCH v3 4/4] target-i386: move asm-x86/hyperv.h to standard-headers

[Michael S. Tsirkin]

On Thu, Sep 10, 2015 at 11:39:38AM +0200, Paolo Bonzini wrote:
> The Hyper-V definitions are an industry standard and can be used
> from code that is not KVM-specific.
> 
> Signed-off-by: Paolo Bonzini 

Reviewed-by: Michael S. Tsirkin 

> ---
>  .../standard-headers}/asm-x86/hyperv.h |  10 +-
>  linux-headers/asm-x86/hyperv.h | 253 
> +
>  scripts/update-linux-headers.sh|   9 +-
>  target-i386/kvm.c  |   2 +-
>  4 files changed, 13 insertions(+), 261 deletions(-)
>  copy {linux-headers => include/standard-headers}/asm-x86/hyperv.h (98%)
> 
> diff --git a/linux-headers/asm-x86/hyperv.h 
> b/include/standard-headers/asm-x86/hyperv.h
> similarity index 98%
> copy from linux-headers/asm-x86/hyperv.h
> copy to include/standard-headers/asm-x86/hyperv.h
> index f36d56b..a2123ca 100644
> --- a/linux-headers/asm-x86/hyperv.h
> +++ b/include/standard-headers/asm-x86/hyperv.h
> @@ -1,7 +1,7 @@
>  #ifndef _ASM_X86_HYPERV_H
>  #define _ASM_X86_HYPERV_H
>  
> -#include 
> +#include "standard-headers/linux/types.h"
>  
>  /*
>   * The below CPUID leaves are present if VersionAndFeatures.HypervisorPresent
> @@ -243,10 +243,10 @@
>  #define HV_STATUS_INSUFFICIENT_BUFFERS   19
>  
>  typedef struct _HV_REFERENCE_TSC_PAGE {
> - __u32 tsc_sequence;
> - __u32 res1;
> - __u64 tsc_scale;
> - __s64 tsc_offset;
> + uint32_t tsc_sequence;
> + uint32_t res1;
> + uint64_t tsc_scale;
> + int64_t tsc_offset;
>  } HV_REFERENCE_TSC_PAGE, *PHV_REFERENCE_TSC_PAGE;
>  
>  #endif
> diff --git a/linux-headers/asm-x86/hyperv.h b/linux-headers/asm-x86/hyperv.h
> index f36d56b..01af4d8 100644
> --- a/linux-headers/asm-x86/hyperv.h
> +++ b/linux-headers/asm-x86/hyperv.h
> @@ -1,252 +1 @@
> -#ifndef _ASM_X86_HYPERV_H
> -#define _ASM_X86_HYPERV_H
> -
> -#include 
> -
> -/*
> - * The below CPUID leaves are present if VersionAndFeatures.HypervisorPresent
> - * is set by CPUID(HvCpuIdFunctionVersionAndFeatures).
> - */
> -#define HYPERV_CPUID_VENDOR_AND_MAX_FUNCTIONS0x4000
> -#define HYPERV_CPUID_INTERFACE   0x4001
> -#define HYPERV_CPUID_VERSION 0x4002
> -#define HYPERV_CPUID_FEATURES0x4003
> -#define HYPERV_CPUID_ENLIGHTMENT_INFO0x4004
> -#define HYPERV_CPUID_IMPLEMENT_LIMITS0x4005
> -
> -#define HYPERV_HYPERVISOR_PRESENT_BIT0x8000
> -#define HYPERV_CPUID_MIN 0x4005
> -#define HYPERV_CPUID_MAX 0x4000
> -
> -/*
> - * Feature identification. EAX indicates which features are available
> - * to the partition based upon the current partition privileges.
> - */
> -
> -/* VP Runtime (HV_X64_MSR_VP_RUNTIME) available */
> -#define HV_X64_MSR_VP_RUNTIME_AVAILABLE  (1 << 0)
> -/* Partition Reference Counter (HV_X64_MSR_TIME_REF_COUNT) available*/
> -#define HV_X64_MSR_TIME_REF_COUNT_AVAILABLE  (1 << 1)
> -
> -/* A partition's reference time stamp counter (TSC) page */
> -#define HV_X64_MSR_REFERENCE_TSC 0x4021
> -
> -/*
> - * There is a single feature flag that signifies the presence of the MSR
> - * that can be used to retrieve both the local APIC Timer frequency as
> - * well as the TSC frequency.
> - */
> -
> -/* Local APIC timer frequency MSR (HV_X64_MSR_APIC_FREQUENCY) is available */
> -#define HV_X64_MSR_APIC_FREQUENCY_AVAILABLE (1 << 11)
> -
> -/* TSC frequency MSR (HV_X64_MSR_TSC_FREQUENCY) is available */
> -#define HV_X64_MSR_TSC_FREQUENCY_AVAILABLE (1 << 11)
> -
> -/*
> - * Basic SynIC MSRs (HV_X64_MSR_SCONTROL through HV_X64_MSR_EOM
> - * and HV_X64_MSR_SINT0 through HV_X64_MSR_SINT15) available
> - */
> -#define HV_X64_MSR_SYNIC_AVAILABLE   (1 << 2)
> -/*
> - * Synthetic Timer MSRs (HV_X64_MSR_STIMER0_CONFIG through
> - * HV_X64_MSR_STIMER3_COUNT) available
> - */
> -#define HV_X64_MSR_SYNTIMER_AVAILABLE(1 << 3)
> -/*
> - * APIC access MSRs (HV_X64_MSR_EOI, HV_X64_MSR_ICR and HV_X64_MSR_TPR)
> - * are available
> - */
> -#define HV_X64_MSR_APIC_ACCESS_AVAILABLE (1 << 4)
> -/* Hypercall MSRs (HV_X64_MSR_GUEST_OS_ID and HV_X64_MSR_HYPERCALL) 
> available*/
> -#define HV_X64_MSR_HYPERCALL_AVAILABLE   (1 << 5)
> -/* Access virtual processor index MSR (HV_X64_MSR_VP_INDEX) available*/
> -#define HV_X64_MSR_VP_INDEX_AVAILABLE(1 << 6)
> -/* Virtual system reset MSR (HV_X64_MSR_RESET) is available*/
> -#define HV_X64_MSR_RESET_AVAILABLE   (1 << 7)
> - /*
> -  * Access statistics pages MSRs (HV_X64_MSR_STATS_PARTITION_RETAIL_PAGE,
> -  * HV_X64_MSR_STATS_PARTITION_INTERNAL_PAGE, 
> HV_X64_MSR_STATS_VP_RETAIL_PAGE,
> -  * HV_X64_MSR_STATS_VP_INTERNAL_PAGE) available
> -  */
> -#define HV_X64_MSR_STAT_PAGES_AVAILABLE  (1 << 8)
> -
> -/*
> - * Feature identification: EBX indicates which flags were specified at
> - * part

Re: [Qemu-devel] [PULL 0/19] xen-2015-09-08-tag

[Stefano Stabellini]

On Thu, 10 Sep 2015, Chen, Tiejun wrote:
> > xen-host-pci-device.c is only compiled if CONFIG_XEN_PCI_PASSTHROUGH
> > was set by configure. That won't be the case on OSX or Windows, where
> > the Xen headers don't exist.
> > 
> 
> Okay. This actually shouldn't be enabled on Windows so what about this?

I think it would be nicer to replace the pread than introducing ifdefs.


> diff --git a/hw/pci-host/piix.c b/hw/pci-host/piix.c
> index 58a33fb..9a1fcb9 100644
> --- a/hw/pci-host/piix.c
> +++ b/hw/pci-host/piix.c
> @@ -739,6 +739,7 @@ static const TypeInfo i440fx_info = {
>  .class_init= i440fx_class_init,
>  };
> 
> +#ifndef _WIN32
>  /* IGD Passthrough Host Bridge. */
>  typedef struct {
>  uint8_t offset;
> @@ -819,6 +820,7 @@ static const TypeInfo igd_passthrough_i440fx_info = {
>  .instance_size = sizeof(PCII440FXState),
>  .class_init= igd_passthrough_i440fx_class_init,
>  };
> +#endif
> 
>  static const char *i440fx_pcihost_root_bus_path(PCIHostState *host_bridge,
>  PCIBus *rootbus)
> @@ -861,7 +863,9 @@ static const TypeInfo i440fx_pcihost_info = {
>  static void i440fx_register_types(void)
>  {
>  type_register_static(&i440fx_info);
> +#ifndef _WIN32
>  type_register_static(&igd_passthrough_i440fx_info);
> +#endif
>  type_register_static(&piix3_pci_type_info);
>  type_register_static(&piix3_info);
>  type_register_static(&piix3_xen_info);
> 
> Thanks
> Tiejun
> 

Re: [Qemu-devel] [PULL 7/7] hw/pci: fix pci_update_mappings() trace events

[Laszlo Ersek]

Hi,

On 09/10/15 11:27, Michael S. Tsirkin wrote:
> From: Laszlo Ersek 
> 
> The current trace prototypes and (matching) trace calls lead to
> "unorthodox" PCI BDF notation in at least the stderr trace backend. For
> example, the four BARs of a QXL video card at 00:01.0 (bus 0, slot 1,
> function 0) are traced like this (PID and timestamps removed):
> 
>   pci_update_mappings_add d=0x7f14a73bf890 00:00.1 0,0x8400+0x400
>   pci_update_mappings_add d=0x7f14a73bf890 00:00.1 1,0x8000+0x400
>   pci_update_mappings_add d=0x7f14a73bf890 00:00.1 2,0x8820+0x2000
>   pci_update_mappings_add d=0x7f14a73bf890 00:00.1 3,0xd060+0x20
> 
> The slot and function values are in reverse order.
> 
> Stick with the conventional BDF notation.
> 
> Cc: "Michael S. Tsirkin" 
> Cc: Don Koch 
> Cc: qemu-triv...@nongnu.org
> Fixes: 7828d75045
> Signed-off-by: Laszlo Ersek 
> Reviewed-by: Michael S. Tsirkin 
> Signed-off-by: Michael S. Tsirkin 

can you please add Marcel's R-b too? From
.

Also, the patch has been picked up by Michael Tokarev for qemu-trivial,
.
I apologize for the confusion, but I really couldn't figure out myself
if this should go "only" to trivial, or to PCI "only". I guess the patch
could be dropped from exactly one of the two queues, but I also expect
that whenever the chronologically second one is going to be merged, git
will simply realize that the patch is already present.

So, my point is that please add *both* R-b tags, regardless of which
tree this is going to be pulled from first.

Also: any guidance for the next time I have a trivial patch for PCI?
Should I Cc qemu-trivial, or not?

Thanks!
Laszlo


> ---
>  hw/pci/pci.c | 4 ++--
>  trace-events | 4 ++--
>  2 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/hw/pci/pci.c b/hw/pci/pci.c
> index eba7ca2..ccea628 100644
> --- a/hw/pci/pci.c
> +++ b/hw/pci/pci.c
> @@ -1154,16 +1154,16 @@ static void pci_update_mappings(PCIDevice *d)
>  /* now do the real mapping */
>  if (r->addr != PCI_BAR_UNMAPPED) {
>  trace_pci_update_mappings_del(d, pci_bus_num(d->bus),
> -  PCI_FUNC(d->devfn),
>PCI_SLOT(d->devfn),
> +  PCI_FUNC(d->devfn),
>i, r->addr, r->size);
>  memory_region_del_subregion(r->address_space, r->memory);
>  }
>  r->addr = new_addr;
>  if (r->addr != PCI_BAR_UNMAPPED) {
>  trace_pci_update_mappings_add(d, pci_bus_num(d->bus),
> -  PCI_FUNC(d->devfn),
>PCI_SLOT(d->devfn),
> +  PCI_FUNC(d->devfn),
>i, r->addr, r->size);
>  memory_region_add_subregion_overlap(r->address_space,
>  r->addr, r->memory, 1);
> diff --git a/trace-events b/trace-events
> index 0a82f0c..1684a95 100644
> --- a/trace-events
> +++ b/trace-events
> @@ -1303,8 +1303,8 @@ spapr_pci_lsi_set(const char *busname, int pin, 
> uint32_t irq) "%s PIN%d IRQ %u"
>  spapr_pci_msi_retry(unsigned config_addr, unsigned req_num, unsigned 
> max_irqs) "Guest device at %x asked %u, have only %u"
>  
>  # hw/pci/pci.c
> -pci_update_mappings_del(void *d, uint32_t bus, uint32_t func, uint32_t slot, 
> int bar, uint64_t addr, uint64_t size) "d=%p %02x:%02x.%x 
> %d,%#"PRIx64"+%#"PRIx64
> -pci_update_mappings_add(void *d, uint32_t bus, uint32_t func, uint32_t slot, 
> int bar, uint64_t addr, uint64_t size) "d=%p %02x:%02x.%x 
> %d,%#"PRIx64"+%#"PRIx64
> +pci_update_mappings_del(void *d, uint32_t bus, uint32_t slot, uint32_t func, 
> int bar, uint64_t addr, uint64_t size) "d=%p %02x:%02x.%x 
> %d,%#"PRIx64"+%#"PRIx64
> +pci_update_mappings_add(void *d, uint32_t bus, uint32_t slot, uint32_t func, 
> int bar, uint64_t addr, uint64_t size) "d=%p %02x:%02x.%x 
> %d,%#"PRIx64"+%#"PRIx64
>  
>  # hw/net/pcnet.c
>  pcnet_s_reset(void *s) "s=%p"
> 

Re: [Qemu-devel] [PATCH v2 06/18] pc: implement NVDIMM device abstract

[Igor Mammedov]

On Tue, 8 Sep 2015 22:03:01 +0800
Xiao Guangrong  wrote:

> 
> 
> On 09/07/2015 09:40 PM, Igor Mammedov wrote:
> > On Sun, 6 Sep 2015 14:07:21 +0800
> > Xiao Guangrong  wrote:
> >
> >>
> >>
> >> On 09/02/2015 07:31 PM, Igor Mammedov wrote:
> >>> On Wed, 2 Sep 2015 18:36:43 +0800
> >>> Xiao Guangrong  wrote:
> >>>
> 
> 
>  On 09/02/2015 05:58 PM, Igor Mammedov wrote:
> > On Fri, 14 Aug 2015 22:51:59 +0800
> > Xiao Guangrong  wrote:
> >
> >> Introduce "pc-nvdimm" device and it has two parameters:
> > Why do you use prefix "pc-", I suppose we potentially
> > could use this device not only with x86 targets but with
> > other targets as well.
> > I'd just drop 'pc' prefix through out patchset.
> 
>  Yeah, the prefix is stolen from pc-dimm, will drop this
>  prefix as your suggestion.
> 
> >
> >> - @file, which is the backed memory file for NVDIMM device
> > Could you try to split device into backend/frontend parts,
> > like it's done with pc-dimm. As I understand it's preferred
> > way to implement this kind of devices.
> > Then you could reuse memory backends that we already have
> > including file backend.
> 
>  I considered it too and Stefan, Paolo got the some idea in
>  V1's review, however:
> 
>  | However, file-based memory used by NVDIMM is special, it divides the 
>  file
>  | to two parts, one part is used as PMEM and another part is used to 
>  store
>  | NVDIMM's configure data.
>  |
>  | Maybe we can introduce "end-reserved" property to reserve specified 
>  size
>  | at the end of the file. Or create a new class type based on
>  | memory-backend-file (named nvdimm-backend-file) class to hide this 
>  magic
>  | thing?
> >>> I'd go with separate backend/frontend idea.
> >>>
> >>> Question is if this config area is part backend or frontend?
> >>
> >> Configdata area is used to store nvdimm device's configuration, normally, 
> >> it's
> >> namespace info.
> >>
> >> Currently, we chosen configdata located at the end of nvdimm's 
> >> backend-memory
> >> as it's easy to configure / use and configdata is naturally non-volatile 
> >> and it
> >> is like the layout on physical device.
> >>
> >> However, using two separated backed-memory is okay, for example:
> >> -object memory-backend-file,id=mem0,file=/storage/foo
> >> -object memory-backend-file,id=mem1,file=/storage/bar
> >> -device nvdimm,memdev=mem0,configdata=mem1
> >> then configdata is written to a single backend.
> >>
> >> Which one is better for you? :)
> >>
> >>> If we pass-through NVDIMM device do we need to set configdata=true
> >>> and QEMU would skip building config structures and use structures
> >>> that are already present on passed-through device in that place?
> >>>
> >>
> >> The file specified by @file is something like a normal disk, like 
> >> /dev/sda/,
> >> host process can use whole space on it. If we want to directly pass it to 
> >> guest,
> >> we can specify 'configdata=false'. If we allow guest to 'partition' (create
> >> namespace on) it then we use 'configdata=true' to reserve some space to 
> >> store
> >> its partition info (namesapce info).
> > As far as I understand currently linux provides to userspace only one 
> > interface
> > which is block device i.e. /dev/sdX and on top of it userspace can put
> > PM/DAX aware filesystem and use files from it. In either cases kernel
> > just provides access to separate namespaces and not to a whole NVDIMM which
> > includes 'labels area'. Hence /dev/sdX is not passed-though NVDIMM,
> > so we could consider it as just a file/storage that could be used by 
> > userspace.
> >
> 
> Yes, it is.
> 
> > Lets assume that NVDIMM should always have 'labels area'.
> > In that case I'd always reserve space for it and
> >   * format it (build a new one) if backend doesn't have a
> > valid labels area dropping configdata parameter along the way
On a second glance, qemu probably shouldn't 'format/build' labels
in this case and only supply non configured NVDIMM to guest.
It probably should be guest responsibility to configure namespaces
on bare NVDIMM. Also it would allow to seamlessly introduce separate labels
backend as described below to cover 'configdata = false' case.

> >   * or if backing-file already has valid labels area I'd just use it.
> 
> Yes.
> 
> >
> > If you need to make labels area readonly you can introduce 
> > 'NVDIMM.readonly_labels'
> > option and just use labels backend's without allowing changes writeback.
> > IT would be better to make it another series on top of basic NVDIMM 
> > implementation
> > if there is an actual usecase for it.
> 
> I'd prefer the way that discards not only its label data but also the whole 
> nvdimm device,
> that is, open(, RDONLY) + mmap(, MAP_PRIVATE), the idea was raised by Stefan.
Yes, we can do this but it's not related to NVDIMM at all, it's backend's 
feature
that also could be (re)

Re: [Qemu-devel] [PULL 7/7] hw/pci: fix pci_update_mappings() trace events

[Michael S. Tsirkin]

On Thu, Sep 10, 2015 at 11:45:01AM +0200, Laszlo Ersek wrote:
> Hi,
> 
> On 09/10/15 11:27, Michael S. Tsirkin wrote:
> > From: Laszlo Ersek 
> > 
> > The current trace prototypes and (matching) trace calls lead to
> > "unorthodox" PCI BDF notation in at least the stderr trace backend. For
> > example, the four BARs of a QXL video card at 00:01.0 (bus 0, slot 1,
> > function 0) are traced like this (PID and timestamps removed):
> > 
> >   pci_update_mappings_add d=0x7f14a73bf890 00:00.1 0,0x8400+0x400
> >   pci_update_mappings_add d=0x7f14a73bf890 00:00.1 1,0x8000+0x400
> >   pci_update_mappings_add d=0x7f14a73bf890 00:00.1 2,0x8820+0x2000
> >   pci_update_mappings_add d=0x7f14a73bf890 00:00.1 3,0xd060+0x20
> > 
> > The slot and function values are in reverse order.
> > 
> > Stick with the conventional BDF notation.
> > 
> > Cc: "Michael S. Tsirkin" 
> > Cc: Don Koch 
> > Cc: qemu-triv...@nongnu.org
> > Fixes: 7828d75045
> > Signed-off-by: Laszlo Ersek 
> > Reviewed-by: Michael S. Tsirkin 
> > Signed-off-by: Michael S. Tsirkin 
> 
> can you please add Marcel's R-b too? From
> .
> 
> Also, the patch has been picked up by Michael Tokarev for qemu-trivial,
> .
> I apologize for the confusion, but I really couldn't figure out myself
> if this should go "only" to trivial, or to PCI "only". I guess the patch
> could be dropped from exactly one of the two queues, but I also expect
> that whenever the chronologically second one is going to be merged, git
> will simply realize that the patch is already present.
> 
> So, my point is that please add *both* R-b tags, regardless of which
> tree this is going to be pulled from first.
> 
> Also: any guidance for the next time I have a trivial patch for PCI?
> Should I Cc qemu-trivial, or not?
> 
> Thanks!
> Laszlo

I dropped it from the tag, thanks.

I think you did everything right, but [trivial PATCH] confused
my scripts. Better would be [PATCH ].

For pci, best to Cc just me - I can handle trivial patches there with no
problems.


> 
> > ---
> >  hw/pci/pci.c | 4 ++--
> >  trace-events | 4 ++--
> >  2 files changed, 4 insertions(+), 4 deletions(-)
> > 
> > diff --git a/hw/pci/pci.c b/hw/pci/pci.c
> > index eba7ca2..ccea628 100644
> > --- a/hw/pci/pci.c
> > +++ b/hw/pci/pci.c
> > @@ -1154,16 +1154,16 @@ static void pci_update_mappings(PCIDevice *d)
> >  /* now do the real mapping */
> >  if (r->addr != PCI_BAR_UNMAPPED) {
> >  trace_pci_update_mappings_del(d, pci_bus_num(d->bus),
> > -  PCI_FUNC(d->devfn),
> >PCI_SLOT(d->devfn),
> > +  PCI_FUNC(d->devfn),
> >i, r->addr, r->size);
> >  memory_region_del_subregion(r->address_space, r->memory);
> >  }
> >  r->addr = new_addr;
> >  if (r->addr != PCI_BAR_UNMAPPED) {
> >  trace_pci_update_mappings_add(d, pci_bus_num(d->bus),
> > -  PCI_FUNC(d->devfn),
> >PCI_SLOT(d->devfn),
> > +  PCI_FUNC(d->devfn),
> >i, r->addr, r->size);
> >  memory_region_add_subregion_overlap(r->address_space,
> >  r->addr, r->memory, 1);
> > diff --git a/trace-events b/trace-events
> > index 0a82f0c..1684a95 100644
> > --- a/trace-events
> > +++ b/trace-events
> > @@ -1303,8 +1303,8 @@ spapr_pci_lsi_set(const char *busname, int pin, 
> > uint32_t irq) "%s PIN%d IRQ %u"
> >  spapr_pci_msi_retry(unsigned config_addr, unsigned req_num, unsigned 
> > max_irqs) "Guest device at %x asked %u, have only %u"
> >  
> >  # hw/pci/pci.c
> > -pci_update_mappings_del(void *d, uint32_t bus, uint32_t func, uint32_t 
> > slot, int bar, uint64_t addr, uint64_t size) "d=%p %02x:%02x.%x 
> > %d,%#"PRIx64"+%#"PRIx64
> > -pci_update_mappings_add(void *d, uint32_t bus, uint32_t func, uint32_t 
> > slot, int bar, uint64_t addr, uint64_t size) "d=%p %02x:%02x.%x 
> > %d,%#"PRIx64"+%#"PRIx64
> > +pci_update_mappings_del(void *d, uint32_t bus, uint32_t slot, uint32_t 
> > func, int bar, uint64_t addr, uint64_t size) "d=%p %02x:%02x.%x 
> > %d,%#"PRIx64"+%#"PRIx64
> > +pci_update_mappings_add(void *d, uint32_t bus, uint32_t slot, uint32_t 
> > func, int bar, uint64_t addr, uint64_t size) "d=%p %02x:%02x.%x 
> > %d,%#"PRIx64"+%#"PRIx64
> >  
> >  # hw/net/pcnet.c
> >  pcnet_s_reset(void *s) "s=%p"
> > 
> 
> 
> 

Re: [Qemu-devel] [RFC 00/20] Do away with TB retranslation

[Artyom Tarasenko]

On Thu, Sep 10, 2015 at 11:32 AM, Dennis Luehring  wrote:
> Am 10.09.2015 um 09:00 schrieb Artyom Tarasenko:
>>>
>>> >strangly your branch doesn't changed anything for pure SPARC64 in my
>>> > tests -
>>> >i've always completely removed the qemu folder and cleanly rebuild
>>> >(all based on stable shell-scripts)
>>
>> Can you please show "perf top" of the qemu-system-sparc64 process on
>> the host, when your g++ compilation is running?
>
>
> http://pastebin.com/nUkhWTj4

Thanks.
1.94%  qemu-system-sparc64  [.] gen_intermediate_code_pc

I suppose this was done on master? Richard's patch 5e3407a removes the
gen_intermediate_code_pc.

Can you also show the perf top of the tcg-search-2 branch run?

Artyom

-- 
Regards,
Artyom Tarasenko

SPARC and PPC PReP under qemu blog: http://tyom.blogspot.com/search/label/qemu

[Qemu-devel] [PATCH v3 1/5] support nbd driver in blockdev-add

[Wen Congyang]

The NBD driver needs: filename, path or (host, port, exportname).
It checks which key exists and decides use unix or inet socket.
It doesn't recognize the key type, so we can't use union, and
can't reuse InetSocketAddress.

Signed-off-by: Wen Congyang 
Signed-off-by: zhanghailiang 
Signed-off-by: Gonglei 
---
 qapi/block-core.json | 42 --
 1 file changed, 40 insertions(+), 2 deletions(-)

diff --git a/qapi/block-core.json b/qapi/block-core.json
index 11134a8..e68a59f 100644
--- a/qapi/block-core.json
+++ b/qapi/block-core.json
@@ -1376,12 +1376,14 @@
 #
 # @host_device, @host_cdrom: Since 2.1
 #
+# @nbd: Since 2.5
+#
 # Since: 2.0
 ##
 { 'enum': 'BlockdevDriver',
   'data': [ 'archipelago', 'blkdebug', 'blkverify', 'bochs', 'cloop',
 'dmg', 'file', 'ftp', 'ftps', 'host_cdrom', 'host_device',
-'http', 'https', 'null-aio', 'null-co', 'parallels',
+'http', 'https', 'nbd', 'null-aio', 'null-co', 'parallels',
 'qcow', 'qcow2', 'qed', 'quorum', 'raw', 'tftp', 'vdi', 'vhdx',
 'vmdk', 'vpc', 'vvfat' ] }
 
@@ -1797,6 +1799,42 @@
 '*read-pattern': 'QuorumReadPattern' } }
 
 ##
+# @BlockdevOptionsNBD
+#
+# Driver specific block device options for NBD
+#
+# @filename: #optional unix or inet path. The format is:
+#unix: nbd+unix:///export?socket=path or
+#  nbd:unix:path:exportname=export
+#inet: nbd[+tcp]://host[:port]/export or
+#  nbd:host[:port]:exportname=export
+#
+# @path: #optional filesystem path to use
+#
+# @host: #optional host part of the address
+#
+# @port: #optional port part of the address
+#
+# @ipv4: #optional whether to accept IPv4 addresses, default try both IPv4
+#and IPv6
+#
+# @ipv6: #optional whether to accept IPv6 addresses, default try both IPv4
+#and IPv6
+#
+# @export: #optional the NBD export name
+#
+# Since: 2.5
+##
+{ 'struct': 'BlockdevOptionsNBD',
+  'data': { '*filename': 'str',
+'*path': 'str',
+'*host': 'str',
+'*port': 'str',
+'*ipv4': 'bool',
+'*ipv6': 'bool',
+'*export':   'str' } }
+
+##
 # @BlockdevOptions
 #
 # Options for creating a block device.
@@ -1822,7 +1860,7 @@
   'http':   'BlockdevOptionsFile',
   'https':  'BlockdevOptionsFile',
 # TODO iscsi: Wait for structured options
-# TODO nbd: Should take InetSocketAddress for 'host'?
+  'nbd':'BlockdevOptionsNBD',
 # TODO nfs: Wait for structured options
   'null-aio':   'BlockdevOptionsNull',
   'null-co':'BlockdevOptionsNull',
-- 
2.4.3

[Qemu-devel] [PATCH v3 4/5] qmp: add monitor command to add/remove a child

[Wen Congyang]

Signed-off-by: Wen Congyang 
Signed-off-by: zhanghailiang 
Signed-off-by: Gonglei 
---
 blockdev.c   | 47 ++
 qapi/block-core.json | 34 +
 qmp-commands.hx  | 53 
 3 files changed, 134 insertions(+)

diff --git a/blockdev.c b/blockdev.c
index bd47756..0a40607 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -3413,6 +3413,53 @@ fail:
 qmp_output_visitor_cleanup(ov);
 }
 
+void qmp_x_child_add(const char *parent, const char *child,
+ Error **errp)
+{
+BlockDriverState *parent_bs, *child_bs;
+Error *local_err = NULL;
+
+parent_bs = bdrv_lookup_bs(parent, parent, &local_err);
+if (!parent_bs) {
+error_propagate(errp, local_err);
+return;
+}
+
+child_bs = bdrv_find_node(child);
+if (!child_bs) {
+error_setg(errp, "Node '%s' not found", child);
+return;
+}
+
+bdrv_add_child(parent_bs, child_bs, &local_err);
+if (local_err) {
+error_propagate(errp, local_err);
+}
+}
+
+void qmp_child_del(const char *parent, const char *child, Error **errp)
+{
+BlockDriverState *parent_bs, *child_bs;
+Error *local_err = NULL;
+
+parent_bs = bdrv_lookup_bs(parent, parent, &local_err);
+if (!parent_bs) {
+error_propagate(errp, local_err);
+return;
+}
+
+child_bs = bdrv_find_node(child);
+if (!child_bs) {
+error_setg(errp, "Node '%s' not found", child);
+return;
+}
+
+bdrv_del_child(parent_bs, child_bs, &local_err);
+if (local_err) {
+error_propagate(errp, local_err);
+}
+}
+
 BlockJobInfoList *qmp_query_block_jobs(Error **errp)
 {
 BlockJobInfoList *head = NULL, **p_next = &head;
diff --git a/qapi/block-core.json b/qapi/block-core.json
index e68a59f..b959577 100644
--- a/qapi/block-core.json
+++ b/qapi/block-core.json
@@ -2272,3 +2272,37 @@
 ##
 { 'command': 'block-set-write-threshold',
   'data': { 'node-name': 'str', 'write-threshold': 'uint64' } }
+
+##
+# @x-child-add
+#
+# Add a new child to the parent BDS. Currently only the Quorum driver
+# implements this feature. This is useful to fix a broken quorum child.
+#
+# @parent: graph node name or id which the child will be added to.
+#
+# @child: graph node name that will be added.
+#
+# Note: this command is experimental, and not a stable API.
+#
+# Since: 2.5
+##
+{ 'command': 'x-child-add',
+  'data' : { 'parent': 'str', 'child': 'str' } }
+
+##
+# @child-del
+#
+# Remove a child from the parent BDS. Currently only the Quorum driver
+# implements this feature. This is useful to fix a broken quorum child.
+# Note, you can't remove a child if it would bring the quorum below its
+# threshold.
+#
+# @parent: graph node name or id from which the child will removed.
+#
+# @child: graph node name that will be removed.
+#
+# Since: 2.5
+##
+{ 'command': 'child-del',
+  'data' : { 'parent': 'str', 'child': 'str' } }
diff --git a/qmp-commands.hx b/qmp-commands.hx
index 495670b..139a23b 100644
--- a/qmp-commands.hx
+++ b/qmp-commands.hx
@@ -4053,6 +4053,59 @@ Example:
 EQMP
 
 {
+.name   = "x-child-add",
+.args_type  = "parent:B,child:B",
+.mhandler.cmd_new = qmp_marshal_input_x_child_add,
+},
+
+SQMP
+x-child-add
+
+
+Add a child to a quorum node.
+
+Arguments:
+
+- "parent": the quorum's id or node name
+- "child": the child node-name which will be added
+
+Note: this command is experimental, and not a stable API.
+
+Example:
+
+-> { "execute": "x-child-add",
+"arguments": { "parent": "disk1", "child": "new_node" } }
+<- { "return": {} }
+
+EQMP
+
+{
+.name= "child-del",
+.args_type   = "parent:B,child:B",
+.mhandler.cmd_new = qmp_marshal_input_child_del,
+},
+
+SQMP
+child-del
+
+
+Delete a child from a quorum node. It can be used to remove a broken
+quorum child.
+
+Arguments:
+
+- "parent": the quorum's id or node name
+- "child": the child node-name which will be removed
+
+Example:
+
+-> { "execute": "child-del",
+"arguments": { "parent": "disk1", "child": "new_node" } }
+<- { "return": {} }
+
+EQMP
+
+{
 .name   = "query-named-block-nodes",
 .args_type  = "",
 .mhandler.cmd_new = qmp_marshal_input_query_named_block_nodes,
-- 
2.4.3

[Qemu-devel] [PATCH v3 5/5] hmp: add monitor command to add/remove a child

[Wen Congyang]

Signed-off-by: Wen Congyang 
Signed-off-by: zhanghailiang 
Signed-off-by: Gonglei 
Cc: Luiz Capitulino 
---
 hmp-commands.hx | 28 
 hmp.c   | 20 
 hmp.h   |  2 ++
 3 files changed, 50 insertions(+)

diff --git a/hmp-commands.hx b/hmp-commands.hx
index fece64f..bd365bb 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -193,6 +193,34 @@ actions (drive options rerror, werror).
 ETEXI
 
 {
+.name   = "child_add",
+.args_type  = "id:B,child:B",
+.params = "parent child",
+.help   = "add a child to a BDS",
+.mhandler.cmd = hmp_child_add,
+},
+
+STEXI
+@item child_add @var{parent device} @var{child device}
+@findex child_add
+Add a child to the block device.
+ETEXI
+
+{
+.name   = "child_del",
+.args_type  = "id:B,child:B",
+.params = "parent child",
+.help   = "remove a child from a BDS",
+.mhandler.cmd = hmp_child_del,
+},
+
+STEXI
+@item child_del @var{parent device} @var{child device}
+@findex child_del
+Remove a child from the parent device.
+ETEXI
+
+{
 .name   = "change",
 .args_type  = "device:B,target:F,arg:s?,read-only-mode:s?",
 .params = "device filename [format [read-only-mode]]",
diff --git a/hmp.c b/hmp.c
index 6e2bbc8..0d6f6c9 100644
--- a/hmp.c
+++ b/hmp.c
@@ -2348,3 +2348,23 @@ void hmp_rocker_of_dpa_groups(Monitor *mon, const QDict 
*qdict)
 
 qapi_free_RockerOfDpaGroupList(list);
 }
+
+void hmp_child_add(Monitor *mon, const QDict *qdict)
+{
+const char *id = qdict_get_str(qdict, "id");
+const char *child_id = qdict_get_str(qdict, "child");
+Error *local_err = NULL;
+
+qmp_x_child_add(id, child_id, &local_err);
+hmp_handle_error(mon, &local_err);
+}
+
+void hmp_child_del(Monitor *mon, const QDict *qdict)
+{
+const char *id = qdict_get_str(qdict, "id");
+const char *child_id = qdict_get_str(qdict, "child");
+Error *local_err = NULL;
+
+qmp_child_del(id, child_id, &local_err);
+hmp_handle_error(mon, &local_err);
+}
diff --git a/hmp.h b/hmp.h
index 81656c3..5bd780c 100644
--- a/hmp.h
+++ b/hmp.h
@@ -130,5 +130,7 @@ void hmp_rocker(Monitor *mon, const QDict *qdict);
 void hmp_rocker_ports(Monitor *mon, const QDict *qdict);
 void hmp_rocker_of_dpa_flows(Monitor *mon, const QDict *qdict);
 void hmp_rocker_of_dpa_groups(Monitor *mon, const QDict *qdict);
+void hmp_child_add(Monitor *mon, const QDict *qdict);
+void hmp_child_del(Monitor *mon, const QDict *qdict);
 
 #endif
-- 
2.4.3

[Qemu-devel] [PATCH v3 2/5] Add new block driver interface to add/delete a BDS's child

[Wen Congyang]

In some cases, we want to take a quorum child offline, and take
another child online.

Signed-off-by: Wen Congyang 
Signed-off-by: zhanghailiang 
Signed-off-by: Gonglei 
---
 block.c   | 52 +++
 include/block/block.h |  5 +
 include/block/block_int.h |  5 +
 3 files changed, 62 insertions(+)

diff --git a/block.c b/block.c
index d004bd0..682d2ec 100644
--- a/block.c
+++ b/block.c
@@ -4115,3 +4115,55 @@ void bdrv_refresh_filename(BlockDriverState *bs)
 QDECREF(json);
 }
 }
+
+/*
+ * Hot add/remove a BDS's child. So the user can take a child offline when
+ * it is broken and take a new child online
+ */
+void bdrv_add_child(BlockDriverState *parent_bs, BlockDriverState *child_bs,
+Error **errp)
+{
+
+if (!parent_bs->drv || !parent_bs->drv->bdrv_add_child) {
+error_setg(errp, "The BDS %s doesn't support adding a child",
+   bdrv_get_device_or_node_name(parent_bs));
+return;
+}
+
+if (child_bs->blk) {
+error_setg(errp, "The BDS %s is used by the block device %s",
+   child_bs->node_name, blk_name(child_bs->blk));
+return;
+}
+
+/* TODO: check if the child bs has parent */
+
+parent_bs->drv->bdrv_add_child(parent_bs, child_bs, errp);
+}
+
+void bdrv_del_child(BlockDriverState *parent_bs, BlockDriverState *child_bs,
+Error **errp)
+{
+BdrvChild *child;
+
+if (!parent_bs->drv || !parent_bs->drv->bdrv_del_child) {
+error_setg(errp, "The BDS %s doesn't support removing a child",
+   bdrv_get_device_or_node_name(parent_bs));
+return;
+}
+
+QLIST_FOREACH(child, &parent_bs->children, next) {
+if (child->bs == child_bs) {
+break;
+}
+}
+
+if (!child) {
+error_setg(errp, "The BDS %s is not the BDS %s's child",
+   bdrv_get_device_or_node_name(child_bs),
+   bdrv_get_device_or_node_name(parent_bs));
+return;
+}
+
+parent_bs->drv->bdrv_del_child(parent_bs, child_bs, errp);
+}
diff --git a/include/block/block.h b/include/block/block.h
index a4e31af..8480af7 100644
--- a/include/block/block.h
+++ b/include/block/block.h
@@ -603,4 +603,9 @@ void bdrv_io_plug(BlockDriverState *bs);
 void bdrv_io_unplug(BlockDriverState *bs);
 void bdrv_flush_io_queue(BlockDriverState *bs);
 
+void bdrv_add_child(BlockDriverState *parent, BlockDriverState *child,
+Error **errp);
+void bdrv_del_child(BlockDriverState *parent, BlockDriverState *child,
+Error **errp);
+
 #endif
diff --git a/include/block/block_int.h b/include/block/block_int.h
index ca1eefa..b4d5250 100644
--- a/include/block/block_int.h
+++ b/include/block/block_int.h
@@ -288,6 +288,11 @@ struct BlockDriver {
  */
 int (*bdrv_probe_geometry)(BlockDriverState *bs, HDGeometry *geo);
 
+void (*bdrv_add_child)(BlockDriverState *parent, BlockDriverState *child,
+   Error **errp);
+void (*bdrv_del_child)(BlockDriverState *parent, BlockDriverState *child,
+   Error **errp);
+
 QLIST_ENTRY(BlockDriver) list;
 };
 
-- 
2.4.3

[Qemu-devel] [PATCH v3 0/5] qapi: child add/delete support

[Wen Congyang]

If quorum's child is broken, we can use mirror job to replace it.
But sometimes, the user only need to remove the broken child, and
add it later when the problem is fixed.

ChangLog:
v3:
1. Don't open BDS in bdrv_add_child(). Use the existing BDS which is
   created by the QMP command blockdev-add.
2. The driver NBD can support filename, path, host:port now.
v2:
1. Use bdrv_get_device_or_node_name() instead of new function
   bdrv_get_id_or_node_name()
2. Update the error message
3. Update the documents in block-core.json

Wen Congyang (5):
  support nbd driver in blockdev-add
  Add new block driver interface to add/delete a BDS's child
  quorum: implement bdrv_add_child() and bdrv_del_child()
  qmp: add monitor command to add/remove a child
  hmp: add monitor command to add/remove a child

 block.c   | 58 ++--
 block/quorum.c| 72 ++--
 blockdev.c| 47 +
 hmp-commands.hx   | 28 +
 hmp.c | 20 +
 hmp.h |  2 ++
 include/block/block.h |  8 +
 include/block/block_int.h |  5 
 qapi/block-core.json  | 76 +--
 qmp-commands.hx   | 53 +
 10 files changed, 362 insertions(+), 7 deletions(-)

-- 
2.4.3

Re: [Qemu-devel] [PATCH 1/2] pc: memhotplug: fix incorrectly set reserved-memory-end

[Igor Mammedov]

On Wed, 9 Sep 2015 17:03:56 -0300
Eduardo Habkost  wrote:

> On Mon, Sep 07, 2015 at 01:55:31PM +0200, Igor Mammedov wrote:
> > reserved-memory-end tells firmware address from which
> > it could start treating memory as PCI address space
> > and map PCI BARs after it to avoid collisions with
> > RAM.
> > Currently it is incorrectly pointing to address where
> > hotplugged memory range starts which could redirect
> > hotplugged RAM accesses to PCI BARs when firmware
> > maps them over RAM or viceverse.
> > Fix this by pointing reserved-memory-end to the end
> > of memory hotplug area.
> > 
> > Signed-off-by: Igor Mammedov 
> 
> Reviewed-by: Eduardo Habkost 
> 
> But I would like to see this squashed into patch 2/2 (or the rebased
> version of patch 2/2) to keep bisectability.

Eduardo, thanks for review.
It's ok squash 2/2, could you handle it and take it through your tree?

[Qemu-devel] [PATCH v3 3/5] quorum: implement bdrv_add_child() and bdrv_del_child()

[Wen Congyang]

Signed-off-by: Wen Congyang 
Signed-off-by: zhanghailiang 
Signed-off-by: Gonglei 
---
 block.c   |  6 ++---
 block/quorum.c| 72 +--
 include/block/block.h |  3 +++
 3 files changed, 76 insertions(+), 5 deletions(-)

diff --git a/block.c b/block.c
index 682d2ec..6ffd27b 100644
--- a/block.c
+++ b/block.c
@@ -1100,9 +1100,9 @@ static int bdrv_fill_options(QDict **options, const char 
**pfilename,
 return 0;
 }
 
-static BdrvChild *bdrv_attach_child(BlockDriverState *parent_bs,
-BlockDriverState *child_bs,
-const BdrvChildRole *child_role)
+BdrvChild *bdrv_attach_child(BlockDriverState *parent_bs,
+ BlockDriverState *child_bs,
+ const BdrvChildRole *child_role)
 {
 BdrvChild *child = g_new(BdrvChild, 1);
 *child = (BdrvChild) {
diff --git a/block/quorum.c b/block/quorum.c
index 72183d6..13e33ad 100644
--- a/block/quorum.c
+++ b/block/quorum.c
@@ -66,6 +66,9 @@ typedef struct QuorumVotes {
 typedef struct BDRVQuorumState {
 BlockDriverState **bs; /* children BlockDriverStates */
 int num_children;  /* children count */
+int max_children;  /* The maximum children count, we need to reallocate
+* bs if num_children grows larger than maximum.
+*/
 int threshold; /* if less than threshold children reads gave the
 * same result a quorum error occurs.
 */
@@ -874,9 +877,9 @@ static int quorum_open(BlockDriverState *bs, QDict 
*options, int flags,
 ret = -EINVAL;
 goto exit;
 }
-if (s->num_children < 2) {
+if (s->num_children < 1) {
 error_setg(&local_err,
-   "Number of provided children must be greater than 1");
+   "Number of provided children must be 1 or more");
 ret = -EINVAL;
 goto exit;
 }
@@ -925,6 +928,7 @@ static int quorum_open(BlockDriverState *bs, QDict 
*options, int flags,
 /* allocate the children BlockDriverState array */
 s->bs = g_new0(BlockDriverState *, s->num_children);
 opened = g_new0(bool, s->num_children);
+s->max_children = s->num_children;
 
 for (i = 0; i < s->num_children; i++) {
 char indexstr[32];
@@ -995,6 +999,67 @@ static void quorum_attach_aio_context(BlockDriverState *bs,
 }
 }
 
+static void quorum_add_child(BlockDriverState *bs, BlockDriverState *child_bs,
+ Error **errp)
+{
+BDRVQuorumState *s = bs->opaque;
+
+bdrv_drain(bs);
+
+if (s->num_children == s->max_children) {
+if (s->max_children >= INT_MAX) {
+error_setg(errp, "Too many children");
+return;
+}
+
+s->bs = g_renew(BlockDriverState *, s->bs, s->max_children + 1);
+s->bs[s->num_children] = NULL;
+s->max_children++;
+}
+
+bdrv_ref(child_bs);
+bdrv_attach_child(bs, child_bs, &child_format);
+s->bs[s->num_children++] = child_bs;
+}
+
+static void quorum_del_child(BlockDriverState *bs, BlockDriverState *child_bs,
+ Error **errp)
+{
+BDRVQuorumState *s = bs->opaque;
+BdrvChild *child;
+int i;
+
+for (i = 0; i < s->num_children; i++) {
+if (s->bs[i] == child_bs) {
+break;
+}
+}
+
+QLIST_FOREACH(child, &bs->children, next) {
+if (child->bs == child_bs) {
+break;
+}
+}
+
+/* we have checked it in bdrv_del_child() */
+assert(i < s->num_children && child);
+
+if (s->num_children <= s->threshold) {
+error_setg(errp,
+"The number of children cannot be lower than the vote threshold 
%d",
+s->threshold);
+return;
+}
+
+bdrv_drain(bs);
+/* We can safely remove this child now */
+memmove(&s->bs[i], &s->bs[i + 1],
+(s->num_children - i - 1) * sizeof(void *));
+s->num_children--;
+s->bs[s->num_children] = NULL;
+bdrv_unref_child(bs, child);
+}
+
 static void quorum_refresh_filename(BlockDriverState *bs)
 {
 BDRVQuorumState *s = bs->opaque;
@@ -1063,6 +1128,9 @@ static BlockDriver bdrv_quorum = {
 .bdrv_detach_aio_context= quorum_detach_aio_context,
 .bdrv_attach_aio_context= quorum_attach_aio_context,
 
+.bdrv_add_child = quorum_add_child,
+.bdrv_del_child = quorum_del_child,
+
 .is_filter  = true,
 .bdrv_recurse_is_first_non_filter   = quorum_recurse_is_first_non_filter,
 
diff --git a/include/block/block.h b/include/block/block.h
index 8480af7..97188b1 100644
--- a/include/block/block.h
+++ b/include/block/block.h
@@ -503,6 +503,9 @@ void bdrv_disable_copy_on_read(BlockDriverState *bs);
 void bdrv_ref(BlockDriverState *bs);
 void bdrv_unref

Re: [Qemu-devel] [PATCH 0/4] ide: simple ATAPI tests

[Markus Armbruster]

John Snow  writes:

> On 09/09/2015 01:00 PM, Paolo Bonzini wrote:
>> 
>> 
>> On 09/09/2015 18:37, John Snow wrote:
>>> Ping -- apologies. :)
>>>
>>> I'll take a simple ACK before I merge it into my tree.
>> 
>> I don't think you need one. :)
>> 
>> Paolo
>> 
>
> I guess technically not, but I like when somebody at least takes a peek
> before I just brazenly send pullreqs.
>
> I haven't achieved the level of ATA COWBOY yet.

I like the prudent attitude.  For tests, however, you can lower the bar
a bit.  Anyway, it looks sane to me.

Re: [Qemu-devel] [PULL 0/19] xen-2015-09-08-tag

[Stefano Stabellini]

On Thu, 10 Sep 2015, Chen, Tiejun wrote:
> > > As you see this short log, "hw/pci-assign: split pci-assign.c", so this
> > > means I just extract something from the original hw/i386/kvm/pci-assign.c,
> > > and here so I just keep those original head files residing
> > > hw/i386/kvm/pci-assign.c, and I didn't introduce anything new.
> > 
> > hw/i386/kvm/pci-assign.c is only built if configure set CONFIG_KVM,
> > which it won't do on Windows or OSX builds.
> > 
> > It sounds like your patch has incorrectly moved code out of files
> > which are compiled only if KVM is present, or only if we're doing
> > Xen PCI passthrough, and into compiled-for-everything files.
> > 
> 
> Yes, we want to share this chunk of codes between Xen and Kvm. Just to this
> error, could we remove #include ? As I mentioned I still can compile
> this file without this head file.

And #include , but it does seem to still work on Linux after
removing them

Re: [Qemu-devel] [edk2] EDK II & GPL - Re: OVMF BoF @ KVM Forum 2015

[Laszlo Ersek]

On 09/10/15 08:19, Alexander Graf wrote:
> 
> 
>> Am 10.09.2015 um 07:32 schrieb Jordan Justen :

>> Laszlo's email raised the GPL question, but I was not sure what the
>> EDK II community would accept with regards to GPL. Thus ... I asked. I
>> guess I'm getting a better idea with regards to Apple and HP. :)
>>
>> In your opinion, would we be able to discuss patches for a *separate*
>> repo with GplDriverPkg on edk2-devel?
> 
> In fact, could we just make the non-free FAT source and GPL FAT
> source both be git submodules?

We've discussed submodules in the past (for other purposes). The
consensus seemed to be that most people dislike them (me included).

UEFI drivers are supposed to be modular / well separable (for one, they
can be shipped by third parties in binary-only form; which was a design
goal of UEFI). And specifically in the FAT driver's case, the source
doesn't even live inside the main repo at the moment, so turning it into
a source submodule might not be a step back.

But... I just don't like it. We should be moving towards a grand unified
repo, where cross-module changes and dependencies are possible to
implement with carefully segmented patch sets. The FAT driver's source
lives outside for non-technical reasons. Rather than codifying that
situation forever with a git submodule, I'd prefer some solution that
leaves us with a standalone repo.

I think I'm fuzzy on the details of the earlier git-submodule
discussion. In any case here's the link (I hope this is the right one):

http://thread.gmane.org/gmane.comp.bios.tianocore.devel/15168

> Then whoever clones the repo can get
> the license flavor he's least scared about.

I think for many companies it is important that a developer of theirs
who is "blissfully ignorant" of licensing questions simply *cannot* make
a mistake (eg. by copying code from the "wrong" directory, or by using
the "wrong" submodule). It should be foolproof.

> Or alternatively instead
> of pulling in a GPL licensed FAT driver we use a BSD licensed one.
> I'm sure someone has one of those too ;).

I'm not sure at all. Do you have a pointer? :)

> Also for the record, the FAT driver problem is that the source
> license states that it can not be used in certain circumstances,
> which by common interpretation makes it non-free.

I agree. The restriction on use conflicts both the FSF's defintion of
Free Software, and the OSI's definition of Open Source Software.

> The fact that there
> is a binary or source doesn't matter fwiw.

Right.

Laszlo

Re: [Qemu-devel] [PATCH v3 4/5] qmp: add monitor command to add/remove a child

[Daniel P. Berrange]

On Thu, Sep 10, 2015 at 05:55:04PM +0800, Wen Congyang wrote:
> Signed-off-by: Wen Congyang 
> Signed-off-by: zhanghailiang 
> Signed-off-by: Gonglei 
> ---
>  blockdev.c   | 47 ++
>  qapi/block-core.json | 34 +
>  qmp-commands.hx  | 53 
> 
>  3 files changed, 134 insertions(+)
> 
> diff --git a/qapi/block-core.json b/qapi/block-core.json
> index e68a59f..b959577 100644
> --- a/qapi/block-core.json
> +++ b/qapi/block-core.json
> @@ -2272,3 +2272,37 @@
>  ##
>  { 'command': 'block-set-write-threshold',
>'data': { 'node-name': 'str', 'write-threshold': 'uint64' } }
> +
> +##
> +# @x-child-add
> +#
> +# Add a new child to the parent BDS. Currently only the Quorum driver
> +# implements this feature. This is useful to fix a broken quorum child.
> +#
> +# @parent: graph node name or id which the child will be added to.
> +#
> +# @child: graph node name that will be added.
> +#
> +# Note: this command is experimental, and not a stable API.
> +#
> +# Since: 2.5
> +##
> +{ 'command': 'x-child-add',
> +  'data' : { 'parent': 'str', 'child': 'str' } }
> +
> +##
> +# @child-del
> +#
> +# Remove a child from the parent BDS. Currently only the Quorum driver
> +# implements this feature. This is useful to fix a broken quorum child.
> +# Note, you can't remove a child if it would bring the quorum below its
> +# threshold.
> +#
> +# @parent: graph node name or id from which the child will removed.
> +#
> +# @child: graph node name that will be removed.
> +#
> +# Since: 2.5
> +##
> +{ 'command': 'child-del',
> +  'data' : { 'parent': 'str', 'child': 'str' } }

These command names are fr too generic. If this only applies to
block devices, then I'd expect something like 'block' as a prefix for
the command names. Likewise with your next hmp patch

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

Re: [Qemu-devel] [PATCH 1/2] ACPI: Add definitions for the DBG2 table

[Igor Mammedov]

On Thu, 10 Sep 2015 11:19:09 +0300
"Michael S. Tsirkin"  wrote:

> On Mon, Sep 07, 2015 at 05:51:50PM +0200, Andrew Jones wrote:
> > On Mon, Sep 07, 2015 at 03:23:45PM +0100, Leif Lindholm wrote:
> > > The DBG2 table can be considered a "companion" to SPCR - it points out
> > > debug consoles available in the system.
> > > 
> > > Signed-off-by: Leif Lindholm 
> > > ---
> > >  include/hw/acpi/acpi-defs.h | 37 +++--
> > >  1 file changed, 35 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/include/hw/acpi/acpi-defs.h b/include/hw/acpi/acpi-defs.h
> > > index 2b431e6..af062a7 100644
> > > --- a/include/hw/acpi/acpi-defs.h
> > > +++ b/include/hw/acpi/acpi-defs.h
> > > @@ -197,10 +197,43 @@ enum {
> > >  };
> > >  
> > >  /*
> > > - * Serial Port Console Redirection Table (SPCR), Rev. 1.02
> > > + * Debug Port Table 2 (DBG2)
> > >   *
> > >   * For .interface_type see Debug Port Table 2 (DBG2) serial port
> > > - * subtypes in Table 3, Rev. May 22, 2012
> > > + * subtypes in Table 3, Rev. Aug 10, 2015
> > > + *
> > > + * The specification permits multiple ports with multiple addresses, but 
> > > this
> > > + * implementation is limited to one port with one address.
> > > + */
> > > +struct AcpiDebugPort2 {
> > > +ACPI_TABLE_HEADER_DEF
> > > +uint32_t debug_devices_offset;
> > > +uint32_t number_debug_devices;
> > > +struct {
> > > +  uint8_t  revision;
> > > +  uint16_t length;
> > > +  uint8_t  number_generic_address_registers;
> > > +  uint16_t namespace_string_length;
> > > +  uint16_t namespace_string_offset;
> > > +  uint16_t oem_data_length;
> > > +  uint16_t oem_data_offset;
> > > +  uint16_t port_type;
> > > +  uint16_t port_subtype;
> > > +  uint8_t  reserved1[2];
> > > +  uint16_t base_address_register_offset;
> > > +  uint16_t address_size_offset;
> > > +  struct AcpiGenericAddress base_address[1];
> > 
> > Not sure we want to limit the number of addresses. Non ARM (non PL011)
> > users of this table may not find one address sufficient.
> > 
> > > +  uint32_t address_size[1];
> > > +  uint8_t  namespace_string[2];
> > > +} QEMU_PACKED debug_devices[1];
> > 
> > I'm guessing it's unlikely we'll ever want more than one debug port. So
> > can we just drop the debug_devices array, flatting the table? OTOH, this
> > is generic acpi table generation code here, and maybe x86 will want to
> > use more than one port? In that case we should pull the debug device
> > structure definition out, and then properly handle the variable length
> > array. But this is where Igor and mst will suggest just using aml_appends,
> > instead of defining these structures at all :-)
> 
> Yes - structures are fine when they are static, but for dynamic
> stuff, aml_append wins hands down.
> You simply add comments in code documenting each field as
> it's added.
> 
> 
> 
> 
> Igor actually likes aml_append for static things as well
> but it's a matter of taste.
Yep, I won't fight over static tables described as structs,
only we have to take a special care so that field would be
in right endiannes which is broken in this patch as Drew noticed.
With aml_append() it's done automatically for user +
a better table description including explicit fields size.

> 
> > > +} QEMU_PACKED;
> > > +typedef struct AcpiDebugPort2
> > > +   AcpiDebugPort2;
> > > +
> > > +/*
> > > + * Serial Port Console Redirection Table (SPCR), Rev. 1.03
> > > + *
> > > + * .interface_type format same as for DBG2.
> > >   */
> > >  struct AcpiSerialPortConsoleRedirection {
> > >  ACPI_TABLE_HEADER_DEF
> > > -- 
> > > 2.1.4
> > > 

Re: [Qemu-devel] [PATCH v11 0/5] remove icc bus/bridge

[Zhu Guihua]

ping ...

On 09/02/2015 05:36 PM, Zhu Guihua wrote:

ICC Bus was used for providing a hotpluggable bus for APIC and CPU, but now we
use HotplugHandler to make hotplug. So ICC Bus is unnecessary.

This code has passed the new pc-cpu-test.
And I have tested with kvm along with kernel_irqchip=on/off, it works fine.

This patch series is based on the latest master and
'[PATCH v3] i386: keep cpu_model field in MachineState uptodate'
https://lists.nongnu.org/archive/html/qemu-devel/2015-08/msg03375.html
which has been reviewed but not been merged.

v11:
  -improve commit messages
  -split per CPU AS change into a separate patch

v10:
  -improve commit messages in patch 1 and 2
  -make the check of cpu->cpu_as_root simplier

v9:
  -use a callback to correct reset sequence for x86
  -update apic mmio mapping

Chen Fan (2):
   apic: move APIC's MMIO region mapping into APIC
   cpu/apic: drop icc bus/bridge

Zhu Guihua (3):
   apic: use per CPU AS to map APIC MMIO for TCG
   x86: use new method to correct reset sequence
   icc_bus: drop the unused files

  default-configs/i386-softmmu.mak   |   1 -
  default-configs/x86_64-softmmu.mak |   1 -
  hw/cpu/Makefile.objs   |   1 -
  hw/cpu/icc_bus.c   | 118 -
  hw/i386/pc.c   |  46 ---
  hw/i386/pc_piix.c  |   9 +--
  hw/i386/pc_q35.c   |   9 +--
  hw/intc/apic_common.c  |  11 +---
  include/hw/cpu/icc_bus.h   |  82 --
  include/hw/i386/apic_internal.h|   7 ++-
  include/hw/i386/pc.h   |   2 +-
  target-i386/cpu.c  |  33 ---
  12 files changed, 58 insertions(+), 262 deletions(-)
  delete mode 100644 hw/cpu/icc_bus.c
  delete mode 100644 include/hw/cpu/icc_bus.h

Re: [Qemu-devel] [PATCH 1/4] virtio: ring sizes vs. reset

[Cornelia Huck]

On Thu, 10 Sep 2015 12:02:44 +0300
"Michael S. Tsirkin"  wrote:

> On Fri, Sep 04, 2015 at 10:54:26AM +0200, Cornelia Huck wrote:
> > We allow guests to change the size of the virtqueue rings by supplying
> > a number of buffers that is different from the number of buffers the
> > device was initialized with. Current code has some problems, however,
> > since reset does not reset the ringsizes to the default values (as this
> > is not saved anywhere).
> > 
> > Let's extend the core code to keep track of the default ringsizes and
> > migrate them once the guest changed them for any of the virtqueues
> > for a device.
> > 
> > Signed-off-by: Cornelia Huck 
> > ---
> >  hw/virtio/virtio.c | 63 
> > ++
> >  include/hw/virtio/virtio.h |  1 +
> >  2 files changed, 64 insertions(+)
> > 

> > diff --git a/include/hw/virtio/virtio.h b/include/hw/virtio/virtio.h
> > index cccae89..29870c8 100644
> > --- a/include/hw/virtio/virtio.h
> > +++ b/include/hw/virtio/virtio.h
> > @@ -90,6 +90,7 @@ struct VirtIODevice
> >  VMChangeStateEntry *vmstate;
> >  char *bus_name;
> >  uint8_t device_endian;
> > +bool non_default_ringsizes;
> 
> 
> Let's not try to track this separately. Just go over
> rings before migration, and check whether guest changed
> anything.

I dunno. If we try to figure this out while doing migration, we'll need
to go over the rings and check whether any of them has changed, then go
over the rings again to save the values - while here, we just set this
bool once when the driver changes the value, check once to find out
whether we need to migrate the values and reset once.

> 
> >  QLIST_HEAD(, VirtQueue) *vector_queues;
> >  };
> >  
> > -- 
> > 2.3.8
> 

Re: [Qemu-devel] [PATCH 4/5] disk_deadlines: add control of requests time expiration

[Stefan Hajnoczi]

On Tue, Sep 08, 2015 at 04:48:24PM +0200, Kevin Wolf wrote:
> Am 08.09.2015 um 16:23 hat Denis V. Lunev geschrieben:
> > On 09/08/2015 04:05 PM, Kevin Wolf wrote:
> > >Am 08.09.2015 um 13:27 hat Denis V. Lunev geschrieben:
> > >>interesting point. Yes, it flushes all requests and most likely
> > >>hangs inside waiting requests to complete. But fortunately
> > >>this happens after the switch to paused state thus
> > >>the guest becomes paused. That's why I have missed this
> > >>fact.
> > >>
> > >>This (could) be considered as a problem but I have no (good)
> > >>solution at the moment. Should think a bit on.
> > >Let me suggest a radically different design. Note that I don't say this
> > >is necessarily how things should be done, I'm just trying to introduce
> > >some new ideas and broaden the discussion, so that we have a larger set
> > >of ideas from which we can pick the right solution(s).
> > >
> > >The core of my idea would be a new filter block driver 'timeout' that
> > >can be added on top of each BDS that could potentially fail, like a
> > >raw-posix BDS pointing to a file on NFS. This way most pieces of the
> > >solution are nicely modularised and don't touch the block layer core.
> > >
> > >During normal operation the driver would just be passing through
> > >requests to the lower layer. When it detects a timeout, however, it
> > >completes the request it received with -ETIMEDOUT. It also completes any
> > >new request it receives with -ETIMEDOUT without passing the request on
> > >until the request that originally timed out returns. This is our safety
> > >measure against anyone seeing whether or how the timed out request
> > >modified data.
> > >
> > >We need to make sure that bdrv_drain() doesn't wait for this request.
> > >Possibly we need to introduce a .bdrv_drain callback that replaces the
> > >default handling, because bdrv_requests_pending() in the default
> > >handling considers bs->file, which would still have the timed out
> > >request. We don't want to see this; bdrv_drain_all() should complete
> > >even though that request is still pending internally (externally, we
> > >returned -ETIMEDOUT, so we can consider it completed). This way the
> > >monitor stays responsive and background jobs can go on if they don't use
> > >the failing block device.
> > >
> > >And then we essentially reuse the rerror/werror mechanism that we
> > >already have to stop the VM. The device models would be extended to
> > >always stop the VM on -ETIMEDOUT, regardless of the error policy. In
> > >this state, the VM would even be migratable if you make sure that the
> > >pending request can't modify the image on the destination host any more.
> > >
> > >Do you think this could work, or did I miss something important?
> > >
> > >Kevin
> > could I propose even more radical solution then?
> > 
> > My original approach was based on the fact that
> > this could should be maintainable out-of-stream.
> > If the patch will be merged - this boundary condition
> > could be dropped.
> > 
> > Why not to invent 'terror' field on BdrvOptions
> > and process things in core block layer without
> > a filter? RB Tree entry will just not created if
> > the policy will be set to 'ignore'.
> 
> 'terror' might not be the most fortunate name... ;-)
> 
> The reason why I would prefer a filter driver is so the code and the
> associated data structures are cleanly modularised and we can keep the
> actual block layer core small and clean. The same is true for some other
> functions that I would rather move out of the core into filter drivers
> than add new cases (e.g. I/O throttling, backup notifiers, etc.), but
> which are a bit harder to actually move because we already have old
> interfaces that we can't break (we'll probably do it anyway eventually,
> even if it needs a bit more compatibility code).
> 
> However, it seems that you are mostly touching code that is maintained
> by Stefan, and Stefan used to be a bit more open to adding functionality
> to the core, so my opinion might not be the last word.

I've been thinking more about the correctness of this feature:

QEMU cannot cancel I/O because there is no Linux userspace API for doing
so.  Linux AIO's io_cancel(2) syscall is a nop since file systems don't
implement a kiocb_cancel_fn.  Sending a signal to a task blocked in
O_DIRECT preadv(2)/pwritev(2) doesn't work either because the task is in
uninterruptible sleep.

The only way to make sure a request has finished is to wait for
completion.  If we treat a request as failed/cancelled but it's actually
still pending at a layer of the storage stack:
1. Read requests may modify guest memory.
2. Write requests may modify disk sectors.

Today the guest times out and tries to do IDE/ATA recovery, for example.
This causes QEMU to eventually call the synchronous bdrv_drain_all()
function and the guest hangs.  Also, if the guest mounts the file system
read-only in response to the timeout, then game over.

The disk-deadlines feature lets Q

Re: [Qemu-devel] [PATCH] spapr: Reduce advertised max LUNs for spapr_vscsi

[David Gibson]

On Thu, Sep 10, 2015 at 08:12:47AM +0200, Thomas Huth wrote:
> On 10/09/15 03:24, David Gibson wrote:
> > On Wed, Sep 09, 2015 at 09:29:18AM +0200, Thomas Huth wrote:
> >> On 09/09/15 09:19, David Gibson wrote:
> >>> On Wed, Sep 09, 2015 at 08:25:34AM +0200, Thomas Huth wrote:
>  On 09/09/15 03:22, David Gibson wrote:
> > The implementation of the PAPR paravirtual SCSI adapter currently
> > allows up to 32 LUNs (max_lun == 31).  However the adapter isn't really
> > designed to support lots of devices - the PowerVM implementation only
> > ever puts one disk per vSCSI controller.
> 
>  Do you know how many LUNs are advertised by PowerVM?
> >>>
> >>> Well, what do you mean by "advertised".  AFAIK from the point of view
> >>> of the guest, the number of LUNs is advertised per-target, not per
> >>> controller.
> >>
> >> I mean, what's the highest LUN number that can be seen by a guest under
> >> PowerVM? Is it always using only one LUN per controller, or is there a
> >> way to change the amount of LUNs? (Sorry if I ask dumb questions ... I
> >> do not have much experience with PowerVM yet)
> > 
> > Um.. I'm not sure, I have very little experience with PowerVM too.  I
> > think with PowerVM it's usually real SCSI devices being passed
> > through, rather than disk images, so presumably the SCSI target itself
> > reports however many LUNs it has.  There may be a limitation in
> > PowerVM, or in the AIX VIO server I think it typically backends onto,
> > but I don't know what it is.
> > 
> > Since that limit has been in the guest side driver forever, presumbly
> > no-one has hit LUNs > 8 in practice.
> > 
> > More specifically, the Linux guest side vscsi driver (the only one we
> > really care about) is hardcoded to allow a maximum of 8 LUNs.
> 
>  So what about changing the vscsi driver in Linux instead to support more
>  LUNs?
> >>>
> >>> Doesn't help for existing guests.  Basically what I'm trying to
> >>> achieve is for qemu to reject up-front configurations that are
> >>> unlikely to actually work in the guest.
> >>
> >> I just wonder whether it makes sense to change the guest instead. In the
> >> future, if we ever have guests that support more LUNs than 8 (maybe some
> >> non-Linux guests like FreeBSD?), we've got to change QEMU back again...
> >> OTOH, since this is just a one-line fix, it's likely ok to limit this to
> >> 8 now - it's easy to revert if we ever need to, so I'm fine with that
> >> change, I just wanted to discuss the other possibilites.
> > 
> > Remember that the spapr-vscsi device exists pretty much entirely to
> > make transition simpler for existing PowerVM guests.  New guests
> > (Linux or otherwise) intended to run under KVM should be using
> > virtio-blk or virtio-scsi.
> 
> FWIW, I had a quick look at FreeBSD sources here:
> 
> https://svnweb.freebsd.org/base/stable/10/sys/powerpc/pseries/phyp_vscsi.c?revision=259204&view=markup
> 
> ... and as far as I can see, they do not limit the LUNs to 8.
> (I only spotted a "cpi->max_lun = ~(lun_id_t)(0);" in there).
> So there indeed might also be older guests that support more than 8 LUNs.

Fair enough, you've convinced me.

I still think it makes sense downstream only, though.

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


pgpEPCHuf3W6z.pgp
Description: PGP signature

Re: [Qemu-devel] [PATCH 4/4] virtio-ccw: enable virtio-1

[Cornelia Huck]

On Thu, 10 Sep 2015 12:22:42 +0300
"Michael S. Tsirkin"  wrote:

> On Thu, Sep 10, 2015 at 11:11:20AM +0200, Cornelia Huck wrote:
> > On Thu, 10 Sep 2015 12:07:18 +0300
> > "Michael S. Tsirkin"  wrote:
> > 
> > > On Fri, Sep 04, 2015 at 10:54:29AM +0200, Cornelia Huck wrote:
> > > > Let's enable revision 1 for virtio-ccw devices. We can always offer
> > > > VERSION_1 as drivers in legacy mode won't be able to see it anyway.
> > > > 
> > > > We have to introduce a way to set a lower maximum revision for a device
> > > > to accommodate the following cases:
> > > > - compat machines (to enforce legacy only)
> > > 
> > > But you don't actually set this for any compat machines.
> > > If you don't, this seems a bit pointless.
> > 
> > Huh? The first hunk of this patch does this.
> 
> Sure. Donnu how I could miss it, sorry.
> 
> > > 
> > > > - virtio-blk with scsi support (version 1 + scsi is fenced by common
> > > >   code, with a user-configured max revision of 0 we can allow scsi
> > > >   via not offering VERSION_1)
> > > 
> > > For this use, for pci users need to do disable_modern=true.
> > > I find it unfortunate that for ccw one needs to do max_revision=0.
> > 
> > I don't like the pci concept: much too coarse-grained and not very
> > future proof.
> > 
> > > 
> > > Revision numbers generally are a ccw specific concept. I'm not sure it
> > > is wise to expose it to users.
> > 
> > What is wrong about exposing transport-specific concepts?
> 
> Nothing. Go ahead and expose as much of the low level as
> makes sense.
> 
> But it would be nice if there was also a portable way for people
> that just want "virtio" and don't care about the low level details
> of which transport it is.

Proxy devices already look different depending on what transport you
use, so I don't think it really matters.

(And for most users, I'd expect they let a management layer take care
of it anyway.)

> 
> OTOH a conservative estimate of the # of people that will want
> to play with this is pretty close to 0, so maybe it does not matter
> much.

The scsi vs. virtio-1 on ccw handling? Not very many (if anyone), yes.

> 
> > > 
> > > > Signed-off-by: Cornelia Huck 
> > > > ---
> > > >  hw/s390x/s390-virtio-ccw.c |  4 
> > > >  hw/s390x/virtio-ccw.c  | 30 --
> > > >  hw/s390x/virtio-ccw.h  |  6 --
> > > >  3 files changed, 36 insertions(+), 4 deletions(-)

Re: [Qemu-devel] [PULL 7/7] hw/pci: fix pci_update_mappings() trace events

[Laszlo Ersek]

On 09/10/15 11:54, Michael S. Tsirkin wrote:
> On Thu, Sep 10, 2015 at 11:45:01AM +0200, Laszlo Ersek wrote:
>> Hi,
>>
>> On 09/10/15 11:27, Michael S. Tsirkin wrote:
>>> From: Laszlo Ersek 
>>>
>>> The current trace prototypes and (matching) trace calls lead to
>>> "unorthodox" PCI BDF notation in at least the stderr trace backend. For
>>> example, the four BARs of a QXL video card at 00:01.0 (bus 0, slot 1,
>>> function 0) are traced like this (PID and timestamps removed):
>>>
>>>   pci_update_mappings_add d=0x7f14a73bf890 00:00.1 0,0x8400+0x400
>>>   pci_update_mappings_add d=0x7f14a73bf890 00:00.1 1,0x8000+0x400
>>>   pci_update_mappings_add d=0x7f14a73bf890 00:00.1 2,0x8820+0x2000
>>>   pci_update_mappings_add d=0x7f14a73bf890 00:00.1 3,0xd060+0x20
>>>
>>> The slot and function values are in reverse order.
>>>
>>> Stick with the conventional BDF notation.
>>>
>>> Cc: "Michael S. Tsirkin" 
>>> Cc: Don Koch 
>>> Cc: qemu-triv...@nongnu.org
>>> Fixes: 7828d75045
>>> Signed-off-by: Laszlo Ersek 
>>> Reviewed-by: Michael S. Tsirkin 
>>> Signed-off-by: Michael S. Tsirkin 
>>
>> can you please add Marcel's R-b too? From
>> .
>>
>> Also, the patch has been picked up by Michael Tokarev for qemu-trivial,
>> .
>> I apologize for the confusion, but I really couldn't figure out myself
>> if this should go "only" to trivial, or to PCI "only". I guess the patch
>> could be dropped from exactly one of the two queues, but I also expect
>> that whenever the chronologically second one is going to be merged, git
>> will simply realize that the patch is already present.
>>
>> So, my point is that please add *both* R-b tags, regardless of which
>> tree this is going to be pulled from first.
>>
>> Also: any guidance for the next time I have a trivial patch for PCI?
>> Should I Cc qemu-trivial, or not?
>>
>> Thanks!
>> Laszlo
> 
> I dropped it from the tag, thanks.
> 
> I think you did everything right, but [trivial PATCH] confused
> my scripts. Better would be [PATCH ].
> 
> For pci, best to Cc just me - I can handle trivial patches there with no
> problems.

Thanks, I'll try to remember both of these points.

Laszlo

> 
> 
>>
>>> ---
>>>  hw/pci/pci.c | 4 ++--
>>>  trace-events | 4 ++--
>>>  2 files changed, 4 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/hw/pci/pci.c b/hw/pci/pci.c
>>> index eba7ca2..ccea628 100644
>>> --- a/hw/pci/pci.c
>>> +++ b/hw/pci/pci.c
>>> @@ -1154,16 +1154,16 @@ static void pci_update_mappings(PCIDevice *d)
>>>  /* now do the real mapping */
>>>  if (r->addr != PCI_BAR_UNMAPPED) {
>>>  trace_pci_update_mappings_del(d, pci_bus_num(d->bus),
>>> -  PCI_FUNC(d->devfn),
>>>PCI_SLOT(d->devfn),
>>> +  PCI_FUNC(d->devfn),
>>>i, r->addr, r->size);
>>>  memory_region_del_subregion(r->address_space, r->memory);
>>>  }
>>>  r->addr = new_addr;
>>>  if (r->addr != PCI_BAR_UNMAPPED) {
>>>  trace_pci_update_mappings_add(d, pci_bus_num(d->bus),
>>> -  PCI_FUNC(d->devfn),
>>>PCI_SLOT(d->devfn),
>>> +  PCI_FUNC(d->devfn),
>>>i, r->addr, r->size);
>>>  memory_region_add_subregion_overlap(r->address_space,
>>>  r->addr, r->memory, 1);
>>> diff --git a/trace-events b/trace-events
>>> index 0a82f0c..1684a95 100644
>>> --- a/trace-events
>>> +++ b/trace-events
>>> @@ -1303,8 +1303,8 @@ spapr_pci_lsi_set(const char *busname, int pin, 
>>> uint32_t irq) "%s PIN%d IRQ %u"
>>>  spapr_pci_msi_retry(unsigned config_addr, unsigned req_num, unsigned 
>>> max_irqs) "Guest device at %x asked %u, have only %u"
>>>  
>>>  # hw/pci/pci.c
>>> -pci_update_mappings_del(void *d, uint32_t bus, uint32_t func, uint32_t 
>>> slot, int bar, uint64_t addr, uint64_t size) "d=%p %02x:%02x.%x 
>>> %d,%#"PRIx64"+%#"PRIx64
>>> -pci_update_mappings_add(void *d, uint32_t bus, uint32_t func, uint32_t 
>>> slot, int bar, uint64_t addr, uint64_t size) "d=%p %02x:%02x.%x 
>>> %d,%#"PRIx64"+%#"PRIx64
>>> +pci_update_mappings_del(void *d, uint32_t bus, uint32_t slot, uint32_t 
>>> func, int bar, uint64_t addr, uint64_t size) "d=%p %02x:%02x.%x 
>>> %d,%#"PRIx64"+%#"PRIx64
>>> +pci_update_mappings_add(void *d, uint32_t bus, uint32_t slot, uint32_t 
>>> func, int bar, uint64_t addr, uint64_t size) "d=%p %02x:%02x.%x 
>>> %d,%#"PRIx64"+%#"PRIx64
>>>  
>>>  # hw/net/pcnet.c
>>>  pcnet_s_reset(void *s) "s=%p"
>>>
>>
>>
>>

Re: [Qemu-devel] [PULL 0/19] xen-2015-09-08-tag

[Stefano Stabellini]

CC Michael

On Thu, 10 Sep 2015, Stefano Stabellini wrote:
> On Thu, 10 Sep 2015, Chen, Tiejun wrote:
> > > xen-host-pci-device.c is only compiled if CONFIG_XEN_PCI_PASSTHROUGH
> > > was set by configure. That won't be the case on OSX or Windows, where
> > > the Xen headers don't exist.
> > > 
> > 
> > Okay. This actually shouldn't be enabled on Windows so what about this?
> 
> I think it would be nicer to replace the pread than introducing ifdefs.

Something like:

---
Replace pread with read to avoid build breakages on Windows

Signed-off-by: Stefano Stabellini 

diff --git a/hw/pci-host/piix.c b/hw/pci-host/piix.c
index 58a33fb..9a40429 100644
--- a/hw/pci-host/piix.c
+++ b/hw/pci-host/piix.c
@@ -774,8 +774,11 @@ static int host_pci_config_read(int pos, int len, uint32_t 
val)
 return -ENODEV;
 }
 
+if (lseek(config_fd, pos, SEEK_SET) != pos) {
+return -errno;
+}
 do {
-rc = pread(config_fd, (uint8_t *)&val, len, pos);
+rc = read(config_fd, (uint8_t *)&val, len);
 } while (rc < 0 && (errno == EINTR || errno == EAGAIN));
 if (rc != len) {
 return -errno;

Re: [Qemu-devel] [PATCH] spapr: Reduce advertised max LUNs for spapr_vscsi

[Laurent Vivier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On 10/09/2015 08:48, David Gibson wrote:
> On Thu, Sep 10, 2015 at 08:12:47AM +0200, Thomas Huth wrote:
>> On 10/09/15 03:24, David Gibson wrote:
>>> On Wed, Sep 09, 2015 at 09:29:18AM +0200, Thomas Huth wrote:
 On 09/09/15 09:19, David Gibson wrote:
> On Wed, Sep 09, 2015 at 08:25:34AM +0200, Thomas Huth
> wrote:
>> On 09/09/15 03:22, David Gibson wrote:
>>> The implementation of the PAPR paravirtual SCSI adapter
>>> currently allows up to 32 LUNs (max_lun == 31).
>>> However the adapter isn't really designed to support
>>> lots of devices - the PowerVM implementation only ever
>>> puts one disk per vSCSI controller.
>> 
>> Do you know how many LUNs are advertised by PowerVM?
> 
> Well, what do you mean by "advertised".  AFAIK from the
> point of view of the guest, the number of LUNs is
> advertised per-target, not per controller.
 
 I mean, what's the highest LUN number that can be seen by a
 guest under PowerVM? Is it always using only one LUN per
 controller, or is there a way to change the amount of LUNs?
 (Sorry if I ask dumb questions ... I do not have much
 experience with PowerVM yet)
>>> 
>>> Um.. I'm not sure, I have very little experience with PowerVM
>>> too.  I think with PowerVM it's usually real SCSI devices being
>>> passed through, rather than disk images, so presumably the SCSI
>>> target itself reports however many LUNs it has.  There may be a
>>> limitation in PowerVM, or in the AIX VIO server I think it
>>> typically backends onto, but I don't know what it is.
>>> 
>>> Since that limit has been in the guest side driver forever,
>>> presumbly no-one has hit LUNs > 8 in practice.
>>> 
>>> More specifically, the Linux guest side vscsi driver
>>> (the only one we really care about) is hardcoded to
>>> allow a maximum of 8 LUNs.
>> 
>> So what about changing the vscsi driver in Linux instead
>> to support more LUNs?
> 
> Doesn't help for existing guests.  Basically what I'm
> trying to achieve is for qemu to reject up-front
> configurations that are unlikely to actually work in the
> guest.
 
 I just wonder whether it makes sense to change the guest
 instead. In the future, if we ever have guests that support
 more LUNs than 8 (maybe some non-Linux guests like FreeBSD?),
 we've got to change QEMU back again... OTOH, since this is
 just a one-line fix, it's likely ok to limit this to 8 now -
 it's easy to revert if we ever need to, so I'm fine with
 that change, I just wanted to discuss the other
 possibilites.
>>> 
>>> Remember that the spapr-vscsi device exists pretty much
>>> entirely to make transition simpler for existing PowerVM
>>> guests.  New guests (Linux or otherwise) intended to run under
>>> KVM should be using virtio-blk or virtio-scsi.
>> 
>> FWIW, I had a quick look at FreeBSD sources here:
>> 
>> https://svnweb.freebsd.org/base/stable/10/sys/powerpc/pseries/phyp_vs
csi.c?revision=259204&view=markup
>>
>>
>> 
... and as far as I can see, they do not limit the LUNs to 8.
>> (I only spotted a "cpi->max_lun = ~(lun_id_t)(0);" in there). So
>> there indeed might also be older guests that support more than 8
>> LUNs.
> 
> Fair enough, you've convinced me.
> 
> I still think it makes sense downstream only, though.
> 

I agree with that. I've sent a patch series to the kernel ML to
display current limits and to allow to change max_lun.

Laurent
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iEYEARECAAYFAlXxXB0ACgkQNKT2yavzbFPcNwCg8nyxLkZWx4MInpRTi2U98u3e
YgsAoNUsTQBAUXkdS5Cu1u5HINh8FEa8
=AaRF
-END PGP SIGNATURE-

Re: [Qemu-devel] [PATCH v3 4/5] qmp: add monitor command to add/remove a child

[Wen Congyang]

On 09/10/2015 06:04 PM, Daniel P. Berrange wrote:
> On Thu, Sep 10, 2015 at 05:55:04PM +0800, Wen Congyang wrote:
>> Signed-off-by: Wen Congyang 
>> Signed-off-by: zhanghailiang 
>> Signed-off-by: Gonglei 
>> ---
>>  blockdev.c   | 47 ++
>>  qapi/block-core.json | 34 +
>>  qmp-commands.hx  | 53 
>> 
>>  3 files changed, 134 insertions(+)
>>
>> diff --git a/qapi/block-core.json b/qapi/block-core.json
>> index e68a59f..b959577 100644
>> --- a/qapi/block-core.json
>> +++ b/qapi/block-core.json
>> @@ -2272,3 +2272,37 @@
>>  ##
>>  { 'command': 'block-set-write-threshold',
>>'data': { 'node-name': 'str', 'write-threshold': 'uint64' } }
>> +
>> +##
>> +# @x-child-add
>> +#
>> +# Add a new child to the parent BDS. Currently only the Quorum driver
>> +# implements this feature. This is useful to fix a broken quorum child.
>> +#
>> +# @parent: graph node name or id which the child will be added to.
>> +#
>> +# @child: graph node name that will be added.
>> +#
>> +# Note: this command is experimental, and not a stable API.
>> +#
>> +# Since: 2.5
>> +##
>> +{ 'command': 'x-child-add',
>> +  'data' : { 'parent': 'str', 'child': 'str' } }
>> +
>> +##
>> +# @child-del
>> +#
>> +# Remove a child from the parent BDS. Currently only the Quorum driver
>> +# implements this feature. This is useful to fix a broken quorum child.
>> +# Note, you can't remove a child if it would bring the quorum below its
>> +# threshold.
>> +#
>> +# @parent: graph node name or id from which the child will removed.
>> +#
>> +# @child: graph node name that will be removed.
>> +#
>> +# Since: 2.5
>> +##
>> +{ 'command': 'child-del',
>> +  'data' : { 'parent': 'str', 'child': 'str' } }
> 
> These command names are fr too generic. If this only applies to
> block devices, then I'd expect something like 'block' as a prefix for
> the command names. Likewise with your next hmp patch

OK, I will fix it in the next version. I guess blockdev may be better.

Thanks
Wen Congyang

> 
> Regards,
> Daniel
> 

Re: [Qemu-devel] [PATCH v3 4/4] target-i386: move asm-x86/hyperv.h to standard-headers

[Cornelia Huck]

On Thu, 10 Sep 2015 11:39:38 +0200
Paolo Bonzini  wrote:

> The Hyper-V definitions are an industry standard and can be used
> from code that is not KVM-specific.
> 
> Signed-off-by: Paolo Bonzini 
> ---
>  .../standard-headers}/asm-x86/hyperv.h |  10 +-
>  linux-headers/asm-x86/hyperv.h | 253 
> +
>  scripts/update-linux-headers.sh|   9 +-
>  target-i386/kvm.c  |   2 +-
>  4 files changed, 13 insertions(+), 261 deletions(-)
>  copy {linux-headers => include/standard-headers}/asm-x86/hyperv.h (98%)

Reviewed-by: Cornelia Huck 

Re: [Qemu-devel] [PATCH v2 08/18] nvdimm: init backend memory mapping and config data area

[Igor Mammedov]

On Tue, 8 Sep 2015 21:38:17 +0800
Xiao Guangrong  wrote:

> 
> 
> On 09/07/2015 10:11 PM, Igor Mammedov wrote:
> > On Fri, 14 Aug 2015 22:52:01 +0800
> > Xiao Guangrong  wrote:
> >
> >> The parameter @file is used as backed memory for NVDIMM which is
> >> divided into two parts if @dataconfig is true:
> >> - first parts is (0, size - 128K], which is used as PMEM (Persistent
> >>Memory)
> >> - 128K at the end of the file, which is used as Config Data Area, it's
> >>used to store Label namespace data
> >>
> >> The @file supports both regular file and block device, of course we
> >> can assign any these two kinds of files for test and emulation, however,
> >> in the real word for performance reason, we usually used these files as
> >> NVDIMM backed file:
> >> - the regular file in the filesystem with DAX enabled created on NVDIMM
> >>device on host
> >> - the raw PMEM device on host, e,g /dev/pmem0
> >
> > A lot of code in this series could reuse what QEMU already
> > uses for implementing pc-dimm devices.
> >
> > here is common concepts that could be reused.
> >- on physical system both DIMM and NVDIMM devices use
> >  the same slots. We could share QEMU's '-m slots' option between
> >  both devices. An alternative to not sharing would be to introduce
> >  '-machine nvdimm_slots' option.
> >  And yes, we need to know number of NVDIMMs to describe
> >  them all in ACPI table (taking in amount future hotplug
> >  include in this possible NVDIMM devices)
> >  I'd go the same way as on real hardware on make them share the same 
> > slots.
> 
> I'd prefer sharing slots for pc-dimm and nvdimm, it's easier to reuse the
> logic of slot-assignment and plug/unplug.
> 
> >- they share the same physical address space and limits
> >  on how much memory system can handle. So I'd suggest sharing existing
> >  '-m maxmem' option and reuse hotplug_memory address space.
> 
> Sounds good to me.
> 
> >
> > Essentially what I'm suggesting is to inherit NVDIMM's implementation
> > from pc-dimm reusing all of its code/backends and
> > just override parts that do memory mapping into guest's address space to
> > accommodate NVDIMM's requirements.
> 
> Good idea!
> 
> We have to differentiate pc-dimm and nvdimm in the common code and nvdimm
> has different points with pc-dimm (for example, its has reserved-region, and
> need support live migration of label data). How about rename 'pc-nvdimm' to
> 'memory-device' and make it as a common device type, then build pc-dimm and
> nvdimm on top of it?
sound good, only I'd call it just 'dimm' as 'memory-device' is too broad.
Also I'd make base class abstract.

> 
> Something like:
> static TypeInfo memory_device_info = {
>  .name  = TYPE_MEM_DEV,
>  .parent= TYPE_DEVICE,
> };
> 
> static TypeInfo memory_device_info = {
> .name = TYPE_PC_DIMM,
> .parent = TYPE_MEM_DEV,
> };
> 
> static TypeInfo memory_device_info = {
> .name = TYPE_NVDIMM,
> .parent = TYPE_MEM_DEV,
> };
> 
> It also make CONIFG_NVDIMM and CONFIG_HOT_PLUG be independent.
> 
> >
> >>
> >> Signed-off-by: Xiao Guangrong 
> >> ---
> >>   hw/mem/nvdimm/pc-nvdimm.c  | 109 
> >> -
> >>   include/hw/mem/pc-nvdimm.h |   7 +++
> >>   2 files changed, 115 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/hw/mem/nvdimm/pc-nvdimm.c b/hw/mem/nvdimm/pc-nvdimm.c
> >> index 7a270a8..97710d1 100644
> >> --- a/hw/mem/nvdimm/pc-nvdimm.c
> >> +++ b/hw/mem/nvdimm/pc-nvdimm.c
> >> @@ -22,12 +22,20 @@
> >>* License along with this library; if not, see 
> >> 
> >>*/
> >>
> >> +#include 
> >> +#include 
> >> +#include 
> >> +
> >> +#include "exec/address-spaces.h"
> >>   #include "hw/mem/pc-nvdimm.h"
> >>
> >> -#define PAGE_SIZE  (1UL << 12)
> >> +#define PAGE_SIZE   (1UL << 12)
> >> +
> >> +#define MIN_CONFIG_DATA_SIZE(128 << 10)
> >>
> >>   static struct nvdimms_info {
> >>   ram_addr_t current_addr;
> >> +int device_index;
> >>   } nvdimms_info;
> >>
> >>   /* the address range [offset, ~0ULL) is reserved for NVDIMM. */
> >> @@ -37,6 +45,26 @@ void pc_nvdimm_reserve_range(ram_addr_t offset)
> >>   nvdimms_info.current_addr = offset;
> >>   }
> >>
> >> +static ram_addr_t reserved_range_push(uint64_t size)
> >> +{
> >> +uint64_t current;
> >> +
> >> +current = ROUND_UP(nvdimms_info.current_addr, PAGE_SIZE);
> >> +
> >> +/* do not have enough space? */
> >> +if (current + size < current) {
> >> +return 0;
> >> +}
> >> +
> >> +nvdimms_info.current_addr = current + size;
> >> +return current;
> >> +}
> > You can't use all memory above hotplug_memory area since
> > we have to tell guest where 64-bit PCI window starts,
> > and currently it should start at reserved-memory-end
> > (but it isn't due to a bug: I've just posted fix to qemu-devel
> >   "[PATCH 0/2] pc: fix 64-bit PCI window clashing with memory hotplug 
> > region"
> >

Re: [Qemu-devel] [PATCH v3 2/4] update Linux headers to 4.2

[Cornelia Huck]

On Thu, 10 Sep 2015 11:39:36 +0200
Paolo Bonzini  wrote:

> Signed-off-by: Paolo Bonzini 
> ---
>  include/standard-headers/linux/pci_regs.h| 381 
> ---
>  include/standard-headers/linux/virtio_ring.h |   3 +-
>  linux-headers/asm-x86/hyperv.h   |   2 +
>  linux-headers/asm-x86/kvm.h  |   4 +-
>  scripts/update-linux-headers.sh  |   1 +
>  5 files changed, 292 insertions(+), 99 deletions(-)

Reviewed-by: Cornelia Huck 

Re: [Qemu-devel] [PATCH v3 3/4] update-linux-headers: copy standard-headers files one by one

[Cornelia Huck]

On Thu, 10 Sep 2015 11:39:37 +0200
Paolo Bonzini  wrote:

> cp_virtio is called for both the asm-s390/ and linux/ directories,
> so it looks for pci_regs.h and input.h files in asm-s390/ too.  This
> makes little sense.  In the next patch we will have the opposite
> problem; we want to add asm-x86/hyperv.h, and there's also a
> linux/hyperv.h file with unwanted dependencies on additional Linux
> uapi headers.  We do not want to copy linux/hyperv.h.
> 
> The solution is to make cp_virtio (now renamed to cp_portable) copy
> one file only, instead of using the "find" command, and call it multiple
> times.  The new function is really just a reindentation of the old one.
> 
> Signed-off-by: Paolo Bonzini 
> ---
>  scripts/update-linux-headers.sh | 69 
> +
>  1 file changed, 36 insertions(+), 33 deletions(-)

Reviewed-by: Cornelia Huck 

Re: [Qemu-devel] [RFC 00/20] Do away with TB retranslation

[Dennis Luehring]

Am 10.09.2015 um 11:54 schrieb Artyom Tarasenko:

On Thu, Sep 10, 2015 at 11:32 AM, Dennis Luehring  wrote:

>Am 10.09.2015 um 09:00 schrieb Artyom Tarasenko:

>>>

>>> >strangly your branch doesn't changed anything for pure SPARC64 in my
>>> >tests -
>>> >i've always completely removed the qemu folder and cleanly rebuild
>>> >(all based on stable shell-scripts)

>>
>>Can you please show "perf top" of the qemu-system-sparc64 process on
>>the host, when your g++ compilation is running?

>
>
>http://pastebin.com/nUkhWTj4

Thanks.
1.94%  qemu-system-sparc64  [.] gen_intermediate_code_pc

I suppose this was done on master? Richard's patch 5e3407a removes the
gen_intermediate_code_pc.


i didn't include the patches - just git-master and tcg-search-2 branch



Can you also show the perf top of the tcg-search-2 branch run?


perf top from tcg-search-2 branch

http://pastebin.com/AtASpQvk

Re: [Qemu-devel] [RFC PATCH] spapr: Reduce creation of LMB DR connectors from O(n^3) to O(n^2)

[David Gibson]

On Thu, Sep 10, 2015 at 01:42:57AM -0700, Peter Crosthwaite wrote:
> On Wed, Sep 9, 2015 at 11:28 PM, David Gibson
>  wrote:
> > The dynamic reconfiguration (hotplug) code for the pseries machine type
> > uses a "DR connector" QOM object for each resource it will be possible
> > to hotplug.  Each of these is added to its owner using
> > object_property_add_child(owner, "dr-connector[*], ...);
> >
> 
> > This works ok for most cases, but gets ugly when allowing large amounts of
> > hotplugged RAM.  For RAM, there's a DR connector object for every 256MB of
> > potential memory.  So if maxmem=2T, for example, there are >250,000 objects
> > under the same parent.
> >
> > The QOM interfaces aren't really designed for this.  In particular
> > object_property_add() has O(n^2) time complexity (in the number of existing
> > children) for the [*] case.  First it has a linear search through array
> > indices to find a free slot, each of which is attempted to a recursive call
> > to object_property_add() with a specific [N].  Those calls are O(n) because
> > there's a linear search through all properties to check for duplicates.
> >
> 
> Does this help? I think it's already queued:
> 
>
>http://lists.nongnu.org/archive/html/qemu-devel/2015-07/msg05790.html


It doesn't help our case; it's basically a fix for a different
instance of the same problem.

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


pgpLtokSOqyqB.pgp
Description: PGP signature