Re: [Qemu-devel] [Xen-devel] [PATCH v4] igd-passthrough-i440FX: convert to realize()

[Hao, Xudong]

> -Original Message-
> From: qemu-devel-bounces+xudong.hao=intel@nongnu.org [mailto:qemu-
> devel-bounces+xudong.hao=intel@nongnu.org] On Behalf Of Gerd
> Hoffmann
> Sent: Tuesday, January 12, 2016 6:25 PM
> To: Hao, Xudong 
> Cc: Lars Kurth ; xen-de...@lists.xensource.com; Stefano
> Stabellini ; Lars Kurth
> ; Michael S. Tsirkin ; qemu-
> de...@nongnu.org; Cao jin ; Stefano Stabellini
> 
> Subject: Re: [Qemu-devel] [Xen-devel] [PATCH v4] igd-passthrough-i440FX:
> convert to realize()
> 
> On Di, 2016-01-12 at 09:50 +, Hao, Xudong wrote:
> > With latest qemu 7b8a354d4716, RHEL7.2 (with default kernel) VM still can't
> boot up with IGD.
> 
> There is another bug, using pci_default_write_config() doesn't fly as this 
> checks
> writes against wmask and the registers in question are not whitelisted ...
> 
> I've just rebased my igd patch series which (among other stuff) fixes that 
> bug:
>   https://www.kraxel.org/cgit/qemu/log/?h=work/igd
>   git://git.kraxel.org/qemu work/igd
> 
> Can you give it a spin?

The issue persist on this branch of tree (commit 1a0d06ce6), the VM kernel log 
attached in another mail while answered the following question.

> 
> Also: what does "can't boot up" mean exactly?  Guest doesn't boot at all?  
> Guest
> boots, but igd/console/Xorg doesn't work?  In case of the
> latter:  Any chance to login via network and get a kernel log?
> 
> thanks,
>   Gerd
> 

Re: [Qemu-devel] [Avocado-devel] [PATCH] net/slirp: Tell the users when they are using deprecated options

[Thomas Huth]

On 13.01.2016 04:13, Jason Wang wrote:
> 
> 
> On 01/13/2016 10:58 AM, Jason Wang wrote:
>>
>> On 01/12/2016 07:45 PM, Cleber Rosa wrote:
>>> - Original Message -
 From: "Thomas Huth" 
 To: "Jason Wang" , "Jan Kiszka" 
 , qemu-devel@nongnu.org
 Cc: "Paolo Bonzini" , avocado-de...@redhat.com, 
 "Markus Armbruster" 
 Sent: Tuesday, January 12, 2016 5:26:36 AM
 Subject: Re: [Qemu-devel] [PATCH] net/slirp: Tell the users when they are 
 using deprecated options

 On 12.01.2016 04:42, Jason Wang wrote:
> On 01/11/2016 11:55 PM, Thomas Huth wrote:
>> On 15.12.2015 09:35, Thomas Huth wrote:
>>> We don't want to support the legacy -tftp, -bootp, -smb and
>>> -net channel options forever. So let's start telling the users
>>> that they will go away in a future version.
>>>
>>> Signed-off-by: Thomas Huth 
>>> ---
>>>  net/slirp.c | 3 +++
>>>  os-posix.c  | 3 +++
>>>  vl.c| 6 ++
>>>  3 files changed, 12 insertions(+)
>>>
>>> diff --git a/net/slirp.c b/net/slirp.c
>>> index f505570..65e3766 100644
>>> --- a/net/slirp.c
>>> +++ b/net/slirp.c
>>> @@ -784,6 +784,9 @@ int net_slirp_parse_legacy(QemuOptsList *opts_list,
>>> const char *optarg, int *ret
>>>  return 0;
>>>  }
>>>  
>>> +error_report("The -net channel option is deprecated and "
>>> + "will be removed in a future version.");
>>> +
>>>  /* handle legacy -net channel,port:chr */
>>>  optarg += strlen("channel,");
>>>  
>>> diff --git a/os-posix.c b/os-posix.c
>>> index e4da406..3f62f7c 100644
>>> --- a/os-posix.c
>>> +++ b/os-posix.c
>>> @@ -40,6 +40,7 @@
>>>  #include "net/slirp.h"
>>>  #include "qemu-options.h"
>>>  #include "qemu/rcu.h"
>>> +#include "qemu/error-report.h"
>>>  
>>>  #ifdef CONFIG_LINUX
>>>  #include 
>>> @@ -139,6 +140,8 @@ void os_parse_cmd_args(int index, const char 
>>> *optarg)
>>>  switch (index) {
>>>  #ifdef CONFIG_SLIRP
>>>  case QEMU_OPTION_smb:
>>> +error_report("The -smb option is deprecated and "
>>> + "will be removed in a future version.");
>>>  if (net_slirp_smb(optarg) < 0)
>>>  exit(1);
>>>  break;
>>> diff --git a/vl.c b/vl.c
>>> index 4211ff1..fa829c0 100644
>>> --- a/vl.c
>>> +++ b/vl.c
>>> @@ -3314,12 +3314,18 @@ int main(int argc, char **argv, char **envp)
>>>  #endif
>>>  #ifdef CONFIG_SLIRP
>>>  case QEMU_OPTION_tftp:
>>> +error_report("The -tftp option is deprecated and "
>>> + "will be removed in a future version.");
>>>  legacy_tftp_prefix = optarg;
>>>  break;
>>>  case QEMU_OPTION_bootp:
>>> +error_report("The -bootp option is deprecated and "
>>> + "will be removed in a future version.");
>>>  legacy_bootp_filename = optarg;
>>>  break;
>>>  case QEMU_OPTION_redir:
>>> +error_report("The -redir option is deprecated and "
>>> + "will be removed in a future version.");
>>>  if (net_slirp_redir(optarg) < 0)
>>>  exit(1);
>>>  break;
>> *ping*
>>
>> Any comments on these old options? I hope Paolo does not want to keep
>> them, too, forever ;-)
> I vaguely remember autotest use those options in the past for guest os
> installation. May need input from autotest guys.
 Looking at
  
 https://github.com/avocado-framework/avocado-vt/blob/master/virttest/qemu_vm.py
 it seems like that latest incarnation of autotest is doing it
 right already:
 ...
 def add_tftp(devices, filename):
 # If the new syntax is supported, don't add -tftp
 if "[,tftp=" in devices.get_help_text():
 return ""
 else:
 return " -tftp '%s'" % filename
 ...
 def add_net(devices, vlan, nettype, ifname=None, tftp=None,
 bootfile=None, hostfwd=[], netdev_id=None,
 netdev_extra_params=None, tapfds=None, script=None,
 downscript=None, vhost=None, queues=None, 
 vhostfds=None,
 add_queues=None, helper=None, add_tapfd=None,
 add_vhostfd=None, vhostforce=None):
 ...
elif mode == "user":
 if tftp and "[,tftp=" in devices.get_help_text():
 cmd += ",tftp='%s'" % tftp
 cmd_nd = cmd
 ... etc ...

 So I think that avocado should be fine already.
>>> It should.
>

Re: [Qemu-devel] [Avocado-devel] [PATCH] net/slirp: Tell the users when they are using deprecated options

[Paolo Bonzini]

On 13/01/2016 04:13, Jason Wang wrote:
> Rethinking about this.  I'm not quite sure we can remove those
> especially "-net user". Google qemu "-net user" gives about 15,900
> results (and the first link is qemu wiki). Maybe we can replace "will be
> removed in a future version." with something like "was suggested to use
> -netdev user,XXX" instead?

-net vs. -netdev was a completely separate topic, and I was very much
against removing -net or even listing it as deprecated.

"-net channel"  seems to be an old version of guestfwd, and I can hardly
find any mention of it on the net.

Paolo

Re: [Qemu-devel] [Avocado-devel] [PATCH] net/slirp: Tell the users when they are using deprecated options

[Markus Armbruster]

Jason Wang  writes:

> On 01/13/2016 10:58 AM, Jason Wang wrote:
>>
>> On 01/12/2016 07:45 PM, Cleber Rosa wrote:
>>> - Original Message -
 From: "Thomas Huth" 
 To: "Jason Wang" , "Jan Kiszka"
 , qemu-devel@nongnu.org
 Cc: "Paolo Bonzini" ,
 avocado-de...@redhat.com, "Markus Armbruster" 
 Sent: Tuesday, January 12, 2016 5:26:36 AM
 Subject: Re: [Qemu-devel] [PATCH] net/slirp: Tell the users when
 they are using deprecated options

 On 12.01.2016 04:42, Jason Wang wrote:
> On 01/11/2016 11:55 PM, Thomas Huth wrote:
>> On 15.12.2015 09:35, Thomas Huth wrote:
>>> We don't want to support the legacy -tftp, -bootp, -smb and
>>> -net channel options forever. So let's start telling the users
>>> that they will go away in a future version.
>>>
>>> Signed-off-by: Thomas Huth 
[...]
> Rethinking about this.  I'm not quite sure we can remove those
> especially "-net user". Google qemu "-net user" gives about 15,900
> results (and the first link is qemu wiki). Maybe we can replace "will be
> removed in a future version." with something like "was suggested to use
> -netdev user,XXX" instead?

A message like "FOO is deprecated" should always accompanied by advice
on preferred usage".  Example:

$ qemu-img create -e
qemu-img: option -e is deprecated, please use '-o encryption' instead!

Nice and helpful (apart from the uncalled-for exclamation mark).

Re: [Qemu-devel] [PATCH v6 11/11] spapr: CPU hot unplug support

[Bharata B Rao]

On Wed, Jan 13, 2016 at 03:57:00PM +1100, David Gibson wrote:
> On Wed, Jan 13, 2016 at 09:40:54AM +0530, Bharata B Rao wrote:
> > On Tue, Jan 12, 2016 at 05:06:34PM +1100, David Gibson wrote:
> > > On Fri, Jan 08, 2016 at 12:25:19PM +0530, Bharata B Rao wrote:
> > > > Remove the CPU core device by removing the underlying CPU thread 
> > > > devices.
> > > > Support hot removal of CPU for sPAPR guests by sending the hot unplug
> > > > notification to the guest via EPOW interrupt. Release the vCPU object
> > > > after CPU hot unplug so that vCPU fd can be parked and reused.
> > > > 
> > > > Signed-off-by: Bharata B Rao 
> > > > ---
> > > >  hw/ppc/spapr.c | 113 
> > > > +
> > > >  include/hw/ppc/spapr.h |   6 +++
> > > >  2 files changed, 119 insertions(+)
> > > > 
> > > > diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> > > > index c2af9ca..43cb726 100644
> > > > --- a/hw/ppc/spapr.c
> > > > +++ b/hw/ppc/spapr.c
> > > > @@ -93,6 +93,9 @@
> > > >  
> > > >  #define HTAB_SIZE(spapr)(1ULL << ((spapr)->htab_shift))
> > > >  
> > > > +static QLIST_HEAD(cpu_unplug_list, sPAPRCPUUnplug) cpu_unplug_list
> > > > +  = QLIST_HEAD_INITIALIZER(cpu_unplug_list);
> > > > +
> > > >  static XICSState *try_create_xics(const char *type, int nr_servers,
> > > >int nr_irqs, Error **errp)
> > > >  {
> > > > @@ -2432,11 +2435,121 @@ static void 
> > > > spapr_machine_device_plug(HotplugHandler *hotplug_dev,
> > > >  }
> > > >  }
> > > >  
> > > > +static void spapr_cpu_destroy(PowerPCCPU *cpu)
> > > > +{
> > > > +sPAPRMachineState *spapr = SPAPR_MACHINE(qdev_get_machine());
> > > > +
> > > > +xics_cpu_destroy(spapr->icp, cpu);
> > > > +qemu_unregister_reset(spapr_cpu_reset, cpu);
> > > > +}
> > > > +
> > > > +static void spapr_cpu_core_cleanup(void)
> > > > +{
> > > > +sPAPRCPUUnplug *unplug, *next;
> > > > +Object *cpu;
> > > > +
> > > > +QLIST_FOREACH_SAFE(unplug, &cpu_unplug_list, node, next) {
> > > > +cpu = unplug->cpu;
> > > > +object_unparent(cpu);
> > > > +QLIST_REMOVE(unplug, node);
> > > > +g_free(unplug);
> > > > +}
> > > > +}
> > > > +
> > > > +static void spapr_add_cpu_to_unplug_list(Object *cpu)
> > > > +{
> > > > +sPAPRCPUUnplug *unplug = g_malloc(sizeof(*unplug));
> > > > +
> > > > +unplug->cpu = cpu;
> > > > +QLIST_INSERT_HEAD(&cpu_unplug_list, unplug, node);
> > > > +}
> > > > +
> > > > +static int spapr_cpu_release(Object *obj, void *opaque)
> > > > +{
> > > > +DeviceState *dev = DEVICE(obj);
> > > > +CPUState *cs = CPU(dev);
> > > > +PowerPCCPU *cpu = POWERPC_CPU(cs);
> > > > +
> > > > +spapr_cpu_destroy(cpu);
> > > > +cpu_remove_sync(cs);
> > > > +
> > > > +/*
> > > > + * We are still walking the core object's children list, and
> > > > + * hence can't cleanup this CPU thread object just yet. Put
> > > > + * it on a list for later removal.
> > > > + */
> > > > +spapr_add_cpu_to_unplug_list(obj);
> > > > +return 0;
> > > > +}
> > > > +
> > > > +static void spapr_core_release(DeviceState *dev, void *opaque)
> > > > +{
> > > > +object_child_foreach(OBJECT(dev), spapr_cpu_release, opaque);
> > > > +spapr_cpu_core_cleanup();
> > > > +object_unparent(OBJECT(dev));
> > > 
> > > I'd prefer to see the unplug_list as a local to this function (passed
> > > to spapr_cpu_release via opaque) rather than using a new global.
> > 
> > Will try that in the next iteration.
> > 
> > > 
> > > > +}
> > > > +
> > > > +static int spapr_core_detach(Object *obj, void *opaque)
> > > > +{
> > > > +sPAPRCoreState *core = opaque;
> > > > +DeviceState *dev = DEVICE(obj);
> > > > +CPUState *cs = CPU(dev);
> > > > +PowerPCCPU *cpu = POWERPC_CPU(cs);
> > > > +int id = ppc_get_vcpu_dt_id(cpu);
> > > > +int smt = kvmppc_smt_threads();
> > > > +sPAPRDRConnector *drc =
> > > > +spapr_dr_connector_by_id(SPAPR_DR_CONNECTOR_TYPE_CPU, id);
> > > > +sPAPRDRConnectorClass *drck;
> > > > +Error *local_err = NULL;
> > > > +
> > > > +/*
> > > > + * SMT threads return from here, only main thread (thread 0) will
> > > > + * continue and signal hot unplug event to the guest.
> > > > + */
> > > 
> > > This seems silly.  spapr_core_unplug() iterates through all the
> > > children only to have all of them except thread 0 ignore the call..
> > > 
> > > Can't you just grab the first thread and do this logic directly from
> > > spapr_core_unplug()?
> > 
> > If I purely rely on the children list of the core object like I am doing
> > here, I don't see how to grab the first thread object from the list w/o
> > doing what I am doing here. However I can store the first thread object
> > in the core object during the core object's instance_init and use it here.
> > Will give it a try in the next iteration.
> 
> It should be accessible by name as "thread[0]" no?

Ye

[Qemu-devel] [Bug 1490611] Re: Using qemu >=2.2.1 to convert raw->VHD (fixed) adds extra padding to the result file, which Microsoft Azure rejects as invalid

[Jan]

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

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

Title:
  Using qemu >=2.2.1 to convert raw->VHD (fixed) adds extra padding to
  the result file, which Microsoft Azure rejects as invalid

Status in QEMU:
  Fix Released

Bug description:
  Starting with a raw disk image, using "qemu-img convert" to convert
  from raw to VHD results in the output VHD file's virtual size being
  aligned to the nearest 516096 bytes (16 heads x 63 sectors per head x
  512 bytes per sector), instead of preserving the input file's size as
  the output VHD's virtual disk size.

  Microsoft Azure requires that disk images (VHDs) submitted for upload
  have virtual sizes aligned to a megabyte boundary. (Ex. 4096MB,
  4097MB, 4098MB, etc. are OK, 4096.5MB is rejected with an error.) This
  is reflected in Microsoft's documentation: https://azure.microsoft.com
  /en-us/documentation/articles/virtual-machines-linux-create-upload-
  vhd-generic/

  This is reproducible with the following set of commands (including the
  Azure command line tools from https://github.com/Azure/azure-xplat-
  cli). For the following example, I used qemu version 2.2.1:

  $ dd if=/dev/zero of=source-disk.img bs=1M count=4096

  $ stat source-disk.img 
File: ‘source-disk.img’
Size: 4294967296  Blocks: 798656 IO Block: 4096   regular file
  Device: fc01h/64513dInode: 13247963Links: 1
  Access: (0644/-rw-r--r--)  Uid: ( 1000/  smkent)   Gid: ( 1000/  smkent)
  Access: 2015-08-18 09:48:02.613988480 -0700
  Modify: 2015-08-18 09:48:02.825985646 -0700
  Change: 2015-08-18 09:48:02.825985646 -0700
   Birth: -

  $ qemu-img convert -f raw -o subformat=fixed -O vpc source-disk.img
  dest-disk.vhd

  $ stat dest-disk.vhd 
File: ‘dest-disk.vhd’
Size: 4296499712  Blocks: 535216 IO Block: 4096   regular file
  Device: fc01h/64513dInode: 13247964Links: 1
  Access: (0644/-rw-r--r--)  Uid: ( 1000/  smkent)   Gid: ( 1000/  smkent)
  Access: 2015-08-18 09:50:22.252077624 -0700
  Modify: 2015-08-18 09:49:24.424868868 -0700
  Change: 2015-08-18 09:49:24.424868868 -0700
   Birth: -

  $ azure vm image create testimage1 dest-disk.vhd -o linux -l "West US"
  info:Executing command vm image create
  + Retrieving storage accounts 
 
  info:VHD size : 4097 MB
  info:Uploading 4195800.5 KB
  Requested:100.0% Completed:100.0% Running:   0 Time: 1m 0s Speed:  6744 KB/s 
  info:https://[redacted].blob.core.windows.net/vm-images/dest-disk.vhd was 
uploaded successfully
  error:   The VHD 
https://[redacted].blob.core.windows.net/vm-images/dest-disk.vhd has an 
unsupported virtual size of 4296499200 bytes.  The size must be a whole number 
(in MBs).
  info:Error information has been recorded to /home/smkent/.azure/azure.err
  error:   vm image create command failed

  I also ran the above commands using qemu 2.4.0, which resulted in the
  same error as the conversion behavior is the same.

  However, qemu 2.1.1 and earlier (including qemu 2.0.0 installed by
  Ubuntu 14.04) does not pad the virtual disk size during conversion.
  Using qemu-img convert from qemu versions <=2.1.1 results in a VHD
  that is exactly the size of the raw input file plus 512 bytes (for the
  VHD footer). Those qemu versions do not attempt to realign the disk.
  As a result, Azure accepts VHD files created using those versions of
  qemu-img convert for upload.

  Is there a reason why newer qemu realigns the converted VHD file? It
  would be useful if an option were added to disable this feature, as
  current versions of qemu cannot be used to create VHD files for Azure
  using Microsoft's official instructions.

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

Re: [Qemu-devel] [PATCH v6 11/11] spapr: CPU hot unplug support

[David Gibson]

On Wed, Jan 13, 2016 at 09:40:54AM +0530, Bharata B Rao wrote:
> On Tue, Jan 12, 2016 at 05:06:34PM +1100, David Gibson wrote:
> > On Fri, Jan 08, 2016 at 12:25:19PM +0530, Bharata B Rao wrote:
> > > Remove the CPU core device by removing the underlying CPU thread devices.
> > > Support hot removal of CPU for sPAPR guests by sending the hot unplug
> > > notification to the guest via EPOW interrupt. Release the vCPU object
> > > after CPU hot unplug so that vCPU fd can be parked and reused.
> > > 
> > > Signed-off-by: Bharata B Rao 
> > > ---
> > >  hw/ppc/spapr.c | 113 
> > > +
> > >  include/hw/ppc/spapr.h |   6 +++
> > >  2 files changed, 119 insertions(+)
> > > 
> > > diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> > > index c2af9ca..43cb726 100644
> > > --- a/hw/ppc/spapr.c
> > > +++ b/hw/ppc/spapr.c
> > > @@ -93,6 +93,9 @@
> > >  
> > >  #define HTAB_SIZE(spapr)(1ULL << ((spapr)->htab_shift))
> > >  
> > > +static QLIST_HEAD(cpu_unplug_list, sPAPRCPUUnplug) cpu_unplug_list
> > > +  = QLIST_HEAD_INITIALIZER(cpu_unplug_list);
> > > +
> > >  static XICSState *try_create_xics(const char *type, int nr_servers,
> > >int nr_irqs, Error **errp)
> > >  {
> > > @@ -2432,11 +2435,121 @@ static void 
> > > spapr_machine_device_plug(HotplugHandler *hotplug_dev,
> > >  }
> > >  }
> > >  
> > > +static void spapr_cpu_destroy(PowerPCCPU *cpu)
> > > +{
> > > +sPAPRMachineState *spapr = SPAPR_MACHINE(qdev_get_machine());
> > > +
> > > +xics_cpu_destroy(spapr->icp, cpu);
> > > +qemu_unregister_reset(spapr_cpu_reset, cpu);
> > > +}
> > > +
> > > +static void spapr_cpu_core_cleanup(void)
> > > +{
> > > +sPAPRCPUUnplug *unplug, *next;
> > > +Object *cpu;
> > > +
> > > +QLIST_FOREACH_SAFE(unplug, &cpu_unplug_list, node, next) {
> > > +cpu = unplug->cpu;
> > > +object_unparent(cpu);
> > > +QLIST_REMOVE(unplug, node);
> > > +g_free(unplug);
> > > +}
> > > +}
> > > +
> > > +static void spapr_add_cpu_to_unplug_list(Object *cpu)
> > > +{
> > > +sPAPRCPUUnplug *unplug = g_malloc(sizeof(*unplug));
> > > +
> > > +unplug->cpu = cpu;
> > > +QLIST_INSERT_HEAD(&cpu_unplug_list, unplug, node);
> > > +}
> > > +
> > > +static int spapr_cpu_release(Object *obj, void *opaque)
> > > +{
> > > +DeviceState *dev = DEVICE(obj);
> > > +CPUState *cs = CPU(dev);
> > > +PowerPCCPU *cpu = POWERPC_CPU(cs);
> > > +
> > > +spapr_cpu_destroy(cpu);
> > > +cpu_remove_sync(cs);
> > > +
> > > +/*
> > > + * We are still walking the core object's children list, and
> > > + * hence can't cleanup this CPU thread object just yet. Put
> > > + * it on a list for later removal.
> > > + */
> > > +spapr_add_cpu_to_unplug_list(obj);
> > > +return 0;
> > > +}
> > > +
> > > +static void spapr_core_release(DeviceState *dev, void *opaque)
> > > +{
> > > +object_child_foreach(OBJECT(dev), spapr_cpu_release, opaque);
> > > +spapr_cpu_core_cleanup();
> > > +object_unparent(OBJECT(dev));
> > 
> > I'd prefer to see the unplug_list as a local to this function (passed
> > to spapr_cpu_release via opaque) rather than using a new global.
> 
> Will try that in the next iteration.
> 
> > 
> > > +}
> > > +
> > > +static int spapr_core_detach(Object *obj, void *opaque)
> > > +{
> > > +sPAPRCoreState *core = opaque;
> > > +DeviceState *dev = DEVICE(obj);
> > > +CPUState *cs = CPU(dev);
> > > +PowerPCCPU *cpu = POWERPC_CPU(cs);
> > > +int id = ppc_get_vcpu_dt_id(cpu);
> > > +int smt = kvmppc_smt_threads();
> > > +sPAPRDRConnector *drc =
> > > +spapr_dr_connector_by_id(SPAPR_DR_CONNECTOR_TYPE_CPU, id);
> > > +sPAPRDRConnectorClass *drck;
> > > +Error *local_err = NULL;
> > > +
> > > +/*
> > > + * SMT threads return from here, only main thread (thread 0) will
> > > + * continue and signal hot unplug event to the guest.
> > > + */
> > 
> > This seems silly.  spapr_core_unplug() iterates through all the
> > children only to have all of them except thread 0 ignore the call..
> > 
> > Can't you just grab the first thread and do this logic directly from
> > spapr_core_unplug()?
> 
> If I purely rely on the children list of the core object like I am doing
> here, I don't see how to grab the first thread object from the list w/o
> doing what I am doing here. However I can store the first thread object
> in the core object during the core object's instance_init and use it here.
> Will give it a try in the next iteration.

It should be accessible by name as "thread[0]" no?

-- 
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


signature.asc
Description: PGP signature

Re: [Qemu-devel] [PATCH v1 02/15] crypto: add support for PBKDF2 algorithm

[Fam Zheng]

On Tue, 01/12 18:56, Daniel P. Berrange wrote:
> +#if defined CONFIG_NETTLE
> +#include "crypto/pbkdf-nettle.c"
> +#elif defined CONFIG_GCRYPT
> +#include "crypto/pbkdf-gcrypt.c"
> +#else /* ! CONFIG_GCRYPT */
> +#include "crypto/pbkdf-stub.c"
> +#endif /* ! CONFIG_GCRYPT */

I think the convention in QEMU is in crypto/Makefile.objs:

crypto-obj-$(CONFIG_NETTLE) += pbkdf-nettle.o
crypto-obj-$(if $(CONFIG_NETTLE),n,$(CONFIG_GCRYPT)) += pbkdf-gcrypt.o

And move pbkdf-stub.c to stub/pbkdf.c.

Re: [Qemu-devel] [PATCH v6 06/11] cpu: Add a sync version of cpu_remove()

[David Gibson]

On Tue, Jan 12, 2016 at 12:23:03PM +0530, Bharata B Rao wrote:
> On Tue, Jan 12, 2016 at 03:16:15PM +1100, David Gibson wrote:
> > On Fri, Jan 08, 2016 at 12:25:14PM +0530, Bharata B Rao wrote:
> > > This sync API will be used by the CPU hotplug code to wait for the CPU to
> > > completely get removed before flagging the failure to the device_add
> > > command.
> > > 
> > > Sync version of this call is needed to correctly recover from CPU
> > > realization failures when ->plug() handler fails.
> > > 
> > > Signed-off-by: Bharata B Rao 
> > > Reviewed-by: David Gibson 
> > > ---
> > >  cpus.c| 12 
> > >  include/qom/cpu.h |  8 
> > >  2 files changed, 20 insertions(+)
> > > 
> > > diff --git a/cpus.c b/cpus.c
> > > index 12374af..c829bd6 100644
> > > --- a/cpus.c
> > > +++ b/cpus.c
> > > @@ -1067,6 +1067,8 @@ static void *qemu_kvm_cpu_thread_fn(void *arg)
> > >  qemu_kvm_wait_io_event(cpu);
> > >  if (cpu->exit && !cpu_can_run(cpu)) {
> > >  qemu_kvm_destroy_vcpu(cpu);
> > > +cpu->created = false;
> > > +qemu_cond_signal(&qemu_cpu_cond);
> > 
> > I know I reviewed this earlier, but I suspect this needs to be
> > qemu_cond_broadcast.  qemu_cpu_cond is global, so there could (at
> > least in theory) be multiple things waiting on it, and we don't know
> > which one is waiting on *this* cpu, rather than another one (or on any
> > other condition handled by this qemu_cpu_cond).
> 
> qemu_cpu_cond condition variable is currently handling the CPU creation
> condition where qemu_cond_signal() is being used. From what I understand,
> only main thread will be waiting on this condition.

> In this patch, I am using the same condition variable to track CPU
> deletion condition too. After this too, I think only main thread will be
> waiting for the deletion to get completed. So using qemu_cond_signal()
> should be ok isn't ?

Ok, if it's just waking the main thread, qemu_cond_signal() should be
fine (in fact, equivalent to qemu_cond_broadcast()).

-- 
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


signature.asc
Description: PGP signature

Re: [Qemu-devel] [RFC PATCH 0/5] Introduce Intel 82574 GbE Controller Emulation (e1000e)

[Prem Mallappa]

On 10/25/2015 10:30 PM, Leonid Bloch wrote:

Hello qemu-devel,

This patch series is an RFC for the new networking device emulation
we're developing for QEMU.


Thanks for the patch

/Prem

Tested By: Prem Mallappa 

Re: [Qemu-devel] [PATCH v6 08/11] target-ppc: Introduce PowerPC specific CPU core device

[Bharata B Rao]

On Wed, Jan 13, 2016 at 10:44:07AM +1100, Alexey Kardashevskiy wrote:
> On 01/08/2016 05:55 PM, Bharata B Rao wrote:
> >CPU core device is a container of CPU thread devices.  CPU hotplug is
> >performed at the granularity of CPU core device. When hotplugged, CPU core
> >creates CPU thread devices.
> >
> >Signed-off-by: Bharata B Rao 
> >---
> >  hw/ppc/Makefile.objs  |  1 +
> >  hw/ppc/cpu-core.c | 69 
> > +++
> >  include/hw/ppc/cpu-core.h | 22 +++
> >  3 files changed, 92 insertions(+)
> >  create mode 100644 hw/ppc/cpu-core.c
> >  create mode 100644 include/hw/ppc/cpu-core.h
> >
> >diff --git a/hw/ppc/Makefile.objs b/hw/ppc/Makefile.objs
> >index c1ffc77..a6b7cfb 100644
> >--- a/hw/ppc/Makefile.objs
> >+++ b/hw/ppc/Makefile.objs
> >@@ -21,3 +21,4 @@ obj-$(CONFIG_E500) += e500.o mpc8544ds.o e500plat.o
> >  obj-$(CONFIG_E500) += mpc8544_guts.o ppce500_spin.o
> >  # PowerPC 440 Xilinx ML507 reference board.
> >  obj-$(CONFIG_XILINX) += virtex_ml507.o
> >+obj-y += cpu-core.o
> >diff --git a/hw/ppc/cpu-core.c b/hw/ppc/cpu-core.c
> >new file mode 100644
> >index 000..c5c6188
> >--- /dev/null
> >+++ b/hw/ppc/cpu-core.c
> >@@ -0,0 +1,69 @@
> >+/*
> >+ * CPU core device, acts as container of CPU thread devices.
> >+ *
> >+ * Copyright (C) 2015 Bharata B Rao 
> >+ *
> >+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
> >+ * See the COPYING file in the top-level directory.
> >+ */
> >+#include "hw/ppc/cpu-core.h"
> >+#include "hw/boards.h"
> >+#include 
> >+#include "qemu/error-report.h"
> >+
> >+static int ppc_cpu_core_realize_child(Object *child, void *opaque)
> >+{
> >+Error **errp = opaque;
> >+
> >+object_property_set_bool(child, true, "realized", errp);
> >+if (*errp) {
> >+return 1;
> >+}
> >+
> >+return 0;
> >+}
> >+
> >+static void ppc_cpu_core_realize(DeviceState *dev, Error **errp)
> >+{
> >+object_child_foreach(OBJECT(dev), ppc_cpu_core_realize_child, errp);
> >+}
> >+
> >+static void ppc_cpu_core_class_init(ObjectClass *oc, void *data)
> >+{
> >+DeviceClass *dc = DEVICE_CLASS(oc);
> >+
> >+dc->realize = ppc_cpu_core_realize;
> >+}
> >+
> >+static void ppc_cpu_core_instance_init(Object *obj)
> >+{
> >+int i;
> >+CPUState *cpu;
> >+MachineState *machine = MACHINE(qdev_get_machine());
> >+
> >+/* Create as many CPU threads as specified in the topology */
> >+for (i = 0; i < smp_threads; i++) {
> >+cpu = cpu_generic_init(TYPE_POWERPC_CPU, machine->cpu_model);
> >+if (!cpu) {
> >+error_report("Unable to find CPU definition: %s\n",
> >+  machine->cpu_model);
> >+exit(EXIT_FAILURE);
> >+}
> >+object_property_add_child(obj, "thread[*]", OBJECT(cpu), 
> >&error_abort);
> >+object_unref(OBJECT(cpu));
> >+}
> >+}
> >+
> >+static const TypeInfo ppc_cpu_core_type_info = {
> >+.name = TYPE_POWERPC_CPU_CORE,
> >+.parent = TYPE_DEVICE,
> >+.class_init = ppc_cpu_core_class_init,
> >+.instance_init = ppc_cpu_core_instance_init,
> 
> 
> Out of curiosity - why not .realize (and return Error instead of exit())?
> I'd think this is the recommended approach now for QOM.

This is an error during object creation and hence we don't have any
other option but to exit. I guess I should use error_setg(&error_fatal, )
instead of exit().

Note that realize time errors are being handled in
.realize (ppc_cpu_core_realize) already.

Regards,
Bharata.

Re: [Qemu-devel] [PATCH v6 11/11] spapr: CPU hot unplug support

[Bharata B Rao]

On Tue, Jan 12, 2016 at 05:06:34PM +1100, David Gibson wrote:
> On Fri, Jan 08, 2016 at 12:25:19PM +0530, Bharata B Rao wrote:
> > Remove the CPU core device by removing the underlying CPU thread devices.
> > Support hot removal of CPU for sPAPR guests by sending the hot unplug
> > notification to the guest via EPOW interrupt. Release the vCPU object
> > after CPU hot unplug so that vCPU fd can be parked and reused.
> > 
> > Signed-off-by: Bharata B Rao 
> > ---
> >  hw/ppc/spapr.c | 113 
> > +
> >  include/hw/ppc/spapr.h |   6 +++
> >  2 files changed, 119 insertions(+)
> > 
> > diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> > index c2af9ca..43cb726 100644
> > --- a/hw/ppc/spapr.c
> > +++ b/hw/ppc/spapr.c
> > @@ -93,6 +93,9 @@
> >  
> >  #define HTAB_SIZE(spapr)(1ULL << ((spapr)->htab_shift))
> >  
> > +static QLIST_HEAD(cpu_unplug_list, sPAPRCPUUnplug) cpu_unplug_list
> > +  = QLIST_HEAD_INITIALIZER(cpu_unplug_list);
> > +
> >  static XICSState *try_create_xics(const char *type, int nr_servers,
> >int nr_irqs, Error **errp)
> >  {
> > @@ -2432,11 +2435,121 @@ static void 
> > spapr_machine_device_plug(HotplugHandler *hotplug_dev,
> >  }
> >  }
> >  
> > +static void spapr_cpu_destroy(PowerPCCPU *cpu)
> > +{
> > +sPAPRMachineState *spapr = SPAPR_MACHINE(qdev_get_machine());
> > +
> > +xics_cpu_destroy(spapr->icp, cpu);
> > +qemu_unregister_reset(spapr_cpu_reset, cpu);
> > +}
> > +
> > +static void spapr_cpu_core_cleanup(void)
> > +{
> > +sPAPRCPUUnplug *unplug, *next;
> > +Object *cpu;
> > +
> > +QLIST_FOREACH_SAFE(unplug, &cpu_unplug_list, node, next) {
> > +cpu = unplug->cpu;
> > +object_unparent(cpu);
> > +QLIST_REMOVE(unplug, node);
> > +g_free(unplug);
> > +}
> > +}
> > +
> > +static void spapr_add_cpu_to_unplug_list(Object *cpu)
> > +{
> > +sPAPRCPUUnplug *unplug = g_malloc(sizeof(*unplug));
> > +
> > +unplug->cpu = cpu;
> > +QLIST_INSERT_HEAD(&cpu_unplug_list, unplug, node);
> > +}
> > +
> > +static int spapr_cpu_release(Object *obj, void *opaque)
> > +{
> > +DeviceState *dev = DEVICE(obj);
> > +CPUState *cs = CPU(dev);
> > +PowerPCCPU *cpu = POWERPC_CPU(cs);
> > +
> > +spapr_cpu_destroy(cpu);
> > +cpu_remove_sync(cs);
> > +
> > +/*
> > + * We are still walking the core object's children list, and
> > + * hence can't cleanup this CPU thread object just yet. Put
> > + * it on a list for later removal.
> > + */
> > +spapr_add_cpu_to_unplug_list(obj);
> > +return 0;
> > +}
> > +
> > +static void spapr_core_release(DeviceState *dev, void *opaque)
> > +{
> > +object_child_foreach(OBJECT(dev), spapr_cpu_release, opaque);
> > +spapr_cpu_core_cleanup();
> > +object_unparent(OBJECT(dev));
> 
> I'd prefer to see the unplug_list as a local to this function (passed
> to spapr_cpu_release via opaque) rather than using a new global.

Will try that in the next iteration.

> 
> > +}
> > +
> > +static int spapr_core_detach(Object *obj, void *opaque)
> > +{
> > +sPAPRCoreState *core = opaque;
> > +DeviceState *dev = DEVICE(obj);
> > +CPUState *cs = CPU(dev);
> > +PowerPCCPU *cpu = POWERPC_CPU(cs);
> > +int id = ppc_get_vcpu_dt_id(cpu);
> > +int smt = kvmppc_smt_threads();
> > +sPAPRDRConnector *drc =
> > +spapr_dr_connector_by_id(SPAPR_DR_CONNECTOR_TYPE_CPU, id);
> > +sPAPRDRConnectorClass *drck;
> > +Error *local_err = NULL;
> > +
> > +/*
> > + * SMT threads return from here, only main thread (thread 0) will
> > + * continue and signal hot unplug event to the guest.
> > + */
> 
> This seems silly.  spapr_core_unplug() iterates through all the
> children only to have all of them except thread 0 ignore the call..
> 
> Can't you just grab the first thread and do this logic directly from
> spapr_core_unplug()?

If I purely rely on the children list of the core object like I am doing
here, I don't see how to grab the first thread object from the list w/o
doing what I am doing here. However I can store the first thread object
in the core object during the core object's instance_init and use it here.
Will give it a try in the next iteration.

Regards,
Bharata.

Re: [Qemu-devel] [PATCH v6 10/11] spapr: CPU hotplug support

[Bharata B Rao]

On Wed, Jan 13, 2016 at 10:58:06AM +1100, Alexey Kardashevskiy wrote:
> On 01/08/2016 05:55 PM, Bharata B Rao wrote:
> >Support CPU hotplug via device-add command like this:
> >
> >(qemu) device_add powerpc64-cpu-core,id=core2
> >
> >In response to device_add, CPU core device will be created. CPU core
> >device creates and realizes CPU thread devices. If the machine type
> >supports CPU hotplug, boot-time CPUs are created as CPU core devices
> >otherwise they continue to be created as individual CPU devices.
> >
> >Set up device tree entries for the hotplugged CPU core and use the
> >exising EPOW event infrastructure to send CPU hotplug notification to
> >the guest.
> >
> >Signed-off-by: Bharata B Rao 
> >---
> >  hw/ppc/spapr.c  | 183 
> > ++--
> >  hw/ppc/spapr_events.c   |   3 +
> >  hw/ppc/spapr_rtas.c |  24 ++
> >  include/hw/ppc/spapr.h  |   5 ++
> >  target-ppc/translate_init.c |   8 ++
> >  5 files changed, 216 insertions(+), 7 deletions(-)
> >
> >diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> >index a3ce1db..c2af9ca 100644
> >--- a/hw/ppc/spapr.c
> >+++ b/hw/ppc/spapr.c
> >@@ -63,6 +63,7 @@
> >
> >  #include "hw/compat.h"
> >  #include "qemu-common.h"
> >+#include "hw/ppc/cpu-core.h"
> >
> >  #include 
> >
> >@@ -600,6 +601,18 @@ static void spapr_populate_cpu_dt(CPUState *cs, void 
> >*fdt, int offset,
> >  size_t page_sizes_prop_size;
> >  uint32_t vcpus_per_socket = smp_threads * smp_cores;
> >  uint32_t pft_size_prop[] = {0, cpu_to_be32(spapr->htab_shift)};
> >+sPAPRMachineClass *smc = SPAPR_MACHINE_GET_CLASS(qdev_get_machine());
> >+sPAPRDRConnector *drc;
> >+sPAPRDRConnectorClass *drck;
> >+int drc_index;
> >+
> >+if (smc->dr_cpu_enabled) {
> >+drc = spapr_dr_connector_by_id(SPAPR_DR_CONNECTOR_TYPE_CPU, index);
> >+g_assert(drc);
> >+drck = SPAPR_DR_CONNECTOR_GET_CLASS(drc);
> >+drc_index = drck->get_index(drc);
> >+_FDT((fdt_setprop_cell(fdt, offset, "ibm,my-drc-index", 
> >drc_index)));
> >+}
> >
> >  /* Note: we keep CI large pages off for now because a 64K capable guest
> >   * provisioned with large pages might otherwise try to map a qemu
> >@@ -1743,6 +1756,8 @@ static void ppc_spapr_init(MachineState *machine)
> >  char *filename;
> >  int smt = kvmppc_smt_threads();
> >  int smp_max_cores = max_cpus/smp_threads;
> >+int spapr_smp_cores = smp_cpus/smp_threads;
> >+Object *core;
> >
> >  msi_supported = true;
> >
> >@@ -1822,13 +1837,22 @@ static void ppc_spapr_init(MachineState *machine)
> >  if (machine->cpu_model == NULL) {
> >  machine->cpu_model = kvm_enabled() ? "host" : "POWER7";
> >  }
> >-for (i = 0; i < smp_cpus; i++) {
> >-cpu = cpu_ppc_init(machine->cpu_model);
> >-if (cpu == NULL) {
> >-fprintf(stderr, "Unable to find PowerPC CPU definition\n");
> >-exit(1);
> >+
> >+if (smc->dr_cpu_enabled) {
> >+for (i = 0; i < spapr_smp_cores; i++) {
> >+core = object_new(TYPE_POWERPC_CPU_CORE);
> >+object_property_set_bool(core, true, "realized", &error_abort);
> >+}
> >+} else {
> >+for (i = 0; i < smp_cpus; i++) {
> >+cpu = cpu_ppc_init(machine->cpu_model);
> >+if (cpu == NULL) {
> >+fprintf(stderr, "Unable to find PowerPC CPU definition\n");
> >+exit(1);
> >+}
> >+object_property_set_bool(OBJECT(cpu), true, "realized",
> >+ &error_abort);
> >  }
> >-spapr_cpu_init(spapr, cpu);
> >  }
> >
> >  if (kvm_enabled()) {
> >@@ -,10 +2246,125 @@ out:
> >  error_propagate(errp, local_err);
> >  }
> >
> >+static void *spapr_populate_hotplug_cpu_dt(DeviceState *dev, CPUState *cs,
> >+   int *fdt_offset,
> >+   sPAPRMachineState *spapr)
> >+{
> >+PowerPCCPU *cpu = POWERPC_CPU(cs);
> >+DeviceClass *dc = DEVICE_GET_CLASS(cs);
> >+int id = ppc_get_vcpu_dt_id(cpu);
> >+void *fdt;
> >+int offset, fdt_size;
> >+char *nodename;
> >+
> >+fdt = create_device_tree(&fdt_size);
> >+nodename = g_strdup_printf("%s@%x", dc->fw_name, id);
> >+offset = fdt_add_subnode(fdt, 0, nodename);
> >+
> >+spapr_populate_cpu_dt(cs, fdt, offset, spapr);
> >+g_free(nodename);
> >+
> >+*fdt_offset = offset;
> >+return fdt;
> >+}
> >+
> >+static int spapr_core_attach(Object *obj, void *opaque)
> >+{
> >+sPAPRMachineClass *smc = SPAPR_MACHINE_GET_CLASS(qdev_get_machine());
> >+sPAPRMachineState *ms = SPAPR_MACHINE(qdev_get_machine());
> >+sPAPRCoreState *core = opaque;
> >+DeviceState *dev = DEVICE(obj);
> >+CPUState *cs = CPU(dev);
> >+PowerPCCPU *cpu = POWERPC_CPU(cs);
> >+int id = ppc_get_vcpu_dt_id(cpu);
> >+sPAPRDRConnector *d

Re: [Qemu-devel] [PATCH v6 10/11] spapr: CPU hotplug support

[Bharata B Rao]

On Tue, Jan 12, 2016 at 04:58:44PM +1100, David Gibson wrote:
> On Fri, Jan 08, 2016 at 12:25:18PM +0530, Bharata B Rao wrote:
> > 
> > +static int spapr_core_attach(Object *obj, void *opaque)
> > +{
> > +sPAPRMachineClass *smc = SPAPR_MACHINE_GET_CLASS(qdev_get_machine());
> > +sPAPRMachineState *ms = SPAPR_MACHINE(qdev_get_machine());
> > +sPAPRCoreState *core = opaque;
> > +DeviceState *dev = DEVICE(obj);
> > +CPUState *cs = CPU(dev);
> > +PowerPCCPU *cpu = POWERPC_CPU(cs);
> > +int id = ppc_get_vcpu_dt_id(cpu);
> > +sPAPRDRConnector *drc =
> > +spapr_dr_connector_by_id(SPAPR_DR_CONNECTOR_TYPE_CPU, id);
> > +sPAPRDRConnectorClass *drck;
> > +int smt = kvmppc_smt_threads();
> > +Error *local_err = NULL;
> > +void *fdt = NULL;
> > +int fdt_offset = 0;
> > +
> > +/*
> > + * Only main SMT thread (thread 0) will continue and signal the
> > + * hotplug event to the guest. Other threads of the core will
> > + * return from here.
> > + */
> > +if ((id % smt) != 0) {
> > +return 0;
> > +}
> > +
> > +if (!smc->dr_cpu_enabled) {
> > +/*
> > + * This is a cold plugged CPU but the machine doesn't support
> > + * DR. So skip the hotplug path ensuring that the CPU is brought
> > + * up online with out an associated DR connector.
> > + */
> > +return 0;
> > +}
> > +
> > +g_assert(drc);
> > +
> > +/*
> > + * Setup CPU DT entries only for hotplugged CPUs. For boot time or
> > + * coldplugged CPUs DT entries are setup in spapr_finalize_fdt().
> > + */
> > +if (dev->hotplugged) {
> > +fdt = spapr_populate_hotplug_cpu_dt(dev, cs, &fdt_offset, ms);
> > +}
> > +
> > +drck = SPAPR_DR_CONNECTOR_GET_CLASS(drc);
> > +drck->attach(drc, core->dev, fdt, fdt_offset, !dev->hotplugged, 
> > &local_err);
> > +if (local_err) {
> > +g_free(fdt);
> > +error_propagate(core->errp, local_err);
> > +return 1;
> > +}
> > +
> > +/*
> > + * We send hotplug notification interrupt to the guest only in case
> > + * of hotplugged CPUs.
> > + */
> > +if (dev->hotplugged) {
> > +spapr_hotplug_req_add_by_index(drc);
> > +} else {
> > +/*
> > + * HACK to support removal of hotplugged CPU after VM migration:
> > + *
> > + * Since we want to be able to hot-remove those coldplugged CPUs
> > + * started at boot time using -device option at the target VM, we 
> > set
> > + * the right allocation_state and isolation_state for them, which 
> > for
> > + * the hotplugged CPUs would be set via RTAS calls done from the
> > + * guest during hotplug.
> > + *
> > + * This allows the coldplugged CPUs started using -device option to
> > + * have the right isolation and allocation states as expected by 
> > the
> > + * CPU hot removal code.
> > + *
> > + * This hack will be removed once we have DRC states migrated as 
> > part
> > + * of VM migration.
> > + */
> > +drck->set_allocation_state(drc, SPAPR_DR_ALLOCATION_STATE_USABLE);
> > +drck->set_isolation_state(drc, 
> > SPAPR_DR_ISOLATION_STATE_UNISOLATED);
> 
> I'm not fully understanding why this is a hack.  Aren't those the
> right allocation and isolation states for a cpu that was present at
> boot?

Those comments are already old, will remove them. I remember Michael Roth
confirming that setting the initial DRC states like this for cold plugged
CPUs should be alright.

> 
> > +}
> > +return 0;
> > +}
> > +
> > +static void spapr_core_plug(HotplugHandler *hotplug_dev, DeviceState *dev,
> > +Error **errp)
> > +{
> > +sPAPRCoreState core;
> > +
> > +core.dev = dev;
> > +core.errp = errp;
> > +object_child_foreach(OBJECT(dev), spapr_core_attach, &core);
> > +}
> > +
> >  static void spapr_machine_device_plug(HotplugHandler *hotplug_dev,
> >DeviceState *dev, Error **errp)
> >  {
> >  sPAPRMachineClass *smc = SPAPR_MACHINE_GET_CLASS(qdev_get_machine());
> > +sPAPRMachineState *ms = SPAPR_MACHINE(hotplug_dev);
> >  
> >  if (object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM)) {
> >  int node;
> > @@ -2262,6 +2401,34 @@ static void spapr_machine_device_plug(HotplugHandler 
> > *hotplug_dev,
> >  }
> >  
> >  spapr_memory_plug(hotplug_dev, dev, node, errp);
> > +} else if (object_dynamic_cast(OBJECT(dev), TYPE_CPU)) {
> > +CPUState *cs = CPU(dev);
> > +PowerPCCPU *cpu = POWERPC_CPU(cs);
> > +int i;
> > +
> > +/* Set NUMA node for the added CPUs  */
> > +for (i = 0; i < nb_numa_nodes; i++) {
> > +if (test_bit(cs->cpu_index, numa_info[i].node_cpu)) {
> > +cs->numa_node = i;
> > +break;
> > +}
> > +}
>

Re: [Qemu-devel] [Avocado-devel] [PATCH] net/slirp: Tell the users when they are using deprecated options

[Jason Wang]

On 01/13/2016 10:58 AM, Jason Wang wrote:
>
> On 01/12/2016 07:45 PM, Cleber Rosa wrote:
>> - Original Message -
>>> From: "Thomas Huth" 
>>> To: "Jason Wang" , "Jan Kiszka" 
>>> , qemu-devel@nongnu.org
>>> Cc: "Paolo Bonzini" , avocado-de...@redhat.com, 
>>> "Markus Armbruster" 
>>> Sent: Tuesday, January 12, 2016 5:26:36 AM
>>> Subject: Re: [Qemu-devel] [PATCH] net/slirp: Tell the users when they are 
>>> using deprecated options
>>>
>>> On 12.01.2016 04:42, Jason Wang wrote:
 On 01/11/2016 11:55 PM, Thomas Huth wrote:
> On 15.12.2015 09:35, Thomas Huth wrote:
>> We don't want to support the legacy -tftp, -bootp, -smb and
>> -net channel options forever. So let's start telling the users
>> that they will go away in a future version.
>>
>> Signed-off-by: Thomas Huth 
>> ---
>>  net/slirp.c | 3 +++
>>  os-posix.c  | 3 +++
>>  vl.c| 6 ++
>>  3 files changed, 12 insertions(+)
>>
>> diff --git a/net/slirp.c b/net/slirp.c
>> index f505570..65e3766 100644
>> --- a/net/slirp.c
>> +++ b/net/slirp.c
>> @@ -784,6 +784,9 @@ int net_slirp_parse_legacy(QemuOptsList *opts_list,
>> const char *optarg, int *ret
>>  return 0;
>>  }
>>  
>> +error_report("The -net channel option is deprecated and "
>> + "will be removed in a future version.");
>> +
>>  /* handle legacy -net channel,port:chr */
>>  optarg += strlen("channel,");
>>  
>> diff --git a/os-posix.c b/os-posix.c
>> index e4da406..3f62f7c 100644
>> --- a/os-posix.c
>> +++ b/os-posix.c
>> @@ -40,6 +40,7 @@
>>  #include "net/slirp.h"
>>  #include "qemu-options.h"
>>  #include "qemu/rcu.h"
>> +#include "qemu/error-report.h"
>>  
>>  #ifdef CONFIG_LINUX
>>  #include 
>> @@ -139,6 +140,8 @@ void os_parse_cmd_args(int index, const char *optarg)
>>  switch (index) {
>>  #ifdef CONFIG_SLIRP
>>  case QEMU_OPTION_smb:
>> +error_report("The -smb option is deprecated and "
>> + "will be removed in a future version.");
>>  if (net_slirp_smb(optarg) < 0)
>>  exit(1);
>>  break;
>> diff --git a/vl.c b/vl.c
>> index 4211ff1..fa829c0 100644
>> --- a/vl.c
>> +++ b/vl.c
>> @@ -3314,12 +3314,18 @@ int main(int argc, char **argv, char **envp)
>>  #endif
>>  #ifdef CONFIG_SLIRP
>>  case QEMU_OPTION_tftp:
>> +error_report("The -tftp option is deprecated and "
>> + "will be removed in a future version.");
>>  legacy_tftp_prefix = optarg;
>>  break;
>>  case QEMU_OPTION_bootp:
>> +error_report("The -bootp option is deprecated and "
>> + "will be removed in a future version.");
>>  legacy_bootp_filename = optarg;
>>  break;
>>  case QEMU_OPTION_redir:
>> +error_report("The -redir option is deprecated and "
>> + "will be removed in a future version.");
>>  if (net_slirp_redir(optarg) < 0)
>>  exit(1);
>>  break;
> *ping*
>
> Any comments on these old options? I hope Paolo does not want to keep
> them, too, forever ;-)
 I vaguely remember autotest use those options in the past for guest os
 installation. May need input from autotest guys.
>>> Looking at
>>>  
>>> https://github.com/avocado-framework/avocado-vt/blob/master/virttest/qemu_vm.py
>>> it seems like that latest incarnation of autotest is doing it
>>> right already:
>>> ...
>>> def add_tftp(devices, filename):
>>> # If the new syntax is supported, don't add -tftp
>>> if "[,tftp=" in devices.get_help_text():
>>> return ""
>>> else:
>>> return " -tftp '%s'" % filename
>>> ...
>>> def add_net(devices, vlan, nettype, ifname=None, tftp=None,
>>> bootfile=None, hostfwd=[], netdev_id=None,
>>> netdev_extra_params=None, tapfds=None, script=None,
>>> downscript=None, vhost=None, queues=None, vhostfds=None,
>>> add_queues=None, helper=None, add_tapfd=None,
>>> add_vhostfd=None, vhostforce=None):
>>> ...
>>>elif mode == "user":
>>> if tftp and "[,tftp=" in devices.get_help_text():
>>> cmd += ",tftp='%s'" % tftp
>>> cmd_nd = cmd
>>> ... etc ...
>>>
>>> So I think that avocado should be fine already.
>> It should.
>>
>> Avocado-VT can usually handle whatever version of QEMU is thrown at it
>> because it usually checks for specific features and command syntax.
>>
>> So, if a feature is remove

Re: [Qemu-devel] [PATCH] net/slirp: Tell the users when they are using deprecated options

[Jason Wang]

On 01/12/2016 07:45 PM, Cleber Rosa wrote:
>
> - Original Message -
>> From: "Thomas Huth" 
>> To: "Jason Wang" , "Jan Kiszka" 
>> , qemu-devel@nongnu.org
>> Cc: "Paolo Bonzini" , avocado-de...@redhat.com, "Markus 
>> Armbruster" 
>> Sent: Tuesday, January 12, 2016 5:26:36 AM
>> Subject: Re: [Qemu-devel] [PATCH] net/slirp: Tell the users when they are 
>> using deprecated options
>>
>> On 12.01.2016 04:42, Jason Wang wrote:
>>> On 01/11/2016 11:55 PM, Thomas Huth wrote:
 On 15.12.2015 09:35, Thomas Huth wrote:
> We don't want to support the legacy -tftp, -bootp, -smb and
> -net channel options forever. So let's start telling the users
> that they will go away in a future version.
>
> Signed-off-by: Thomas Huth 
> ---
>  net/slirp.c | 3 +++
>  os-posix.c  | 3 +++
>  vl.c| 6 ++
>  3 files changed, 12 insertions(+)
>
> diff --git a/net/slirp.c b/net/slirp.c
> index f505570..65e3766 100644
> --- a/net/slirp.c
> +++ b/net/slirp.c
> @@ -784,6 +784,9 @@ int net_slirp_parse_legacy(QemuOptsList *opts_list,
> const char *optarg, int *ret
>  return 0;
>  }
>  
> +error_report("The -net channel option is deprecated and "
> + "will be removed in a future version.");
> +
>  /* handle legacy -net channel,port:chr */
>  optarg += strlen("channel,");
>  
> diff --git a/os-posix.c b/os-posix.c
> index e4da406..3f62f7c 100644
> --- a/os-posix.c
> +++ b/os-posix.c
> @@ -40,6 +40,7 @@
>  #include "net/slirp.h"
>  #include "qemu-options.h"
>  #include "qemu/rcu.h"
> +#include "qemu/error-report.h"
>  
>  #ifdef CONFIG_LINUX
>  #include 
> @@ -139,6 +140,8 @@ void os_parse_cmd_args(int index, const char *optarg)
>  switch (index) {
>  #ifdef CONFIG_SLIRP
>  case QEMU_OPTION_smb:
> +error_report("The -smb option is deprecated and "
> + "will be removed in a future version.");
>  if (net_slirp_smb(optarg) < 0)
>  exit(1);
>  break;
> diff --git a/vl.c b/vl.c
> index 4211ff1..fa829c0 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -3314,12 +3314,18 @@ int main(int argc, char **argv, char **envp)
>  #endif
>  #ifdef CONFIG_SLIRP
>  case QEMU_OPTION_tftp:
> +error_report("The -tftp option is deprecated and "
> + "will be removed in a future version.");
>  legacy_tftp_prefix = optarg;
>  break;
>  case QEMU_OPTION_bootp:
> +error_report("The -bootp option is deprecated and "
> + "will be removed in a future version.");
>  legacy_bootp_filename = optarg;
>  break;
>  case QEMU_OPTION_redir:
> +error_report("The -redir option is deprecated and "
> + "will be removed in a future version.");
>  if (net_slirp_redir(optarg) < 0)
>  exit(1);
>  break;
 *ping*

 Any comments on these old options? I hope Paolo does not want to keep
 them, too, forever ;-)
>>> I vaguely remember autotest use those options in the past for guest os
>>> installation. May need input from autotest guys.
>> Looking at
>>  
>> https://github.com/avocado-framework/avocado-vt/blob/master/virttest/qemu_vm.py
>> it seems like that latest incarnation of autotest is doing it
>> right already:
>> ...
>> def add_tftp(devices, filename):
>> # If the new syntax is supported, don't add -tftp
>> if "[,tftp=" in devices.get_help_text():
>> return ""
>> else:
>> return " -tftp '%s'" % filename
>> ...
>> def add_net(devices, vlan, nettype, ifname=None, tftp=None,
>> bootfile=None, hostfwd=[], netdev_id=None,
>> netdev_extra_params=None, tapfds=None, script=None,
>> downscript=None, vhost=None, queues=None, vhostfds=None,
>> add_queues=None, helper=None, add_tapfd=None,
>> add_vhostfd=None, vhostforce=None):
>> ...
>>elif mode == "user":
>> if tftp and "[,tftp=" in devices.get_help_text():
>> cmd += ",tftp='%s'" % tftp
>> cmd_nd = cmd
>> ... etc ...
>>
>> So I think that avocado should be fine already.
> It should.
>
> Avocado-VT can usually handle whatever version of QEMU is thrown at it
> because it usually checks for specific features and command syntax.
>
> So, if a feature is removed and Avocado-VT is not handling that properly,
> then it's a bug on "our" side.
>
> Cleber.

Sounds very cool.

Apply this to my -net.

Thanks everyone.

>
>>  Thoma

[Qemu-devel] [PATCH v10 1/2] mirror: Rewrite mirror_iteration

[Fam Zheng]

The "pnum < nb_sectors" condition in deciding whether to actually copy
data is unnecessarily strict, and the qiov initialization is
unnecessarily for bdrv_aio_write_zeroes and bdrv_aio_discard.

Rewrite mirror_iteration to fix both flaws.

The output of iotests 109 is updated because we now report the offset
and len slightly differently in mirroring progress.

Signed-off-by: Fam Zheng 
---
 block/mirror.c | 333 +++--
 tests/qemu-iotests/109.out |  80 +--
 trace-events   |   1 -
 3 files changed, 242 insertions(+), 172 deletions(-)

diff --git a/block/mirror.c b/block/mirror.c
index f201f2b..7606aea 100644
--- a/block/mirror.c
+++ b/block/mirror.c
@@ -46,7 +46,6 @@ typedef struct MirrorBlockJob {
 BlockdevOnError on_source_error, on_target_error;
 bool synced;
 bool should_complete;
-int64_t sector_num;
 int64_t granularity;
 size_t buf_size;
 int64_t bdev_length;
@@ -63,6 +62,8 @@ typedef struct MirrorBlockJob {
 int ret;
 bool unmap;
 bool waiting_for_io;
+int target_cluster_sectors;
+int max_iov;
 } MirrorBlockJob;
 
 typedef struct MirrorOp {
@@ -158,115 +159,79 @@ static void mirror_read_complete(void *opaque, int ret)
 mirror_write_complete, op);
 }
 
-static uint64_t coroutine_fn mirror_iteration(MirrorBlockJob *s)
+/* Round sector_num and/or nb_sectors to target cluster if COW is needed, and
+ * return the offset of the adjusted tail sector against original. */
+static int mirror_cow_align(MirrorBlockJob *s,
+int64_t *sector_num,
+int *nb_sectors)
+{
+bool need_cow;
+int ret = 0;
+int chunk_sectors = s->granularity >> BDRV_SECTOR_BITS;
+int64_t align_sector_num = *sector_num;
+int align_nb_sectors = *nb_sectors;
+int max_sectors = chunk_sectors * s->max_iov;
+
+need_cow = !test_bit(*sector_num / chunk_sectors, s->cow_bitmap);
+need_cow |= !test_bit((*sector_num + *nb_sectors - 1) / chunk_sectors,
+  s->cow_bitmap);
+if (need_cow) {
+bdrv_round_to_clusters(s->target, *sector_num, *nb_sectors,
+   &align_sector_num, &align_nb_sectors);
+}
+
+if (align_nb_sectors > max_sectors) {
+align_nb_sectors = max_sectors;
+if (need_cow) {
+align_nb_sectors = QEMU_ALIGN_DOWN(align_nb_sectors,
+   s->target_cluster_sectors);
+}
+}
+
+ret = align_sector_num + align_nb_sectors - (*sector_num + *nb_sectors);
+*sector_num = align_sector_num;
+*nb_sectors = align_nb_sectors;
+assert(ret >= 0);
+return ret;
+}
+
+/* Submit async read while handling COW.
+ * Returns: nb_sectors if no alignment is necessary, or
+ *  (new_end - sector_num) if tail is rounded up or down due to
+ *  alignment or buffer limit.
+ */
+static int mirror_do_read(MirrorBlockJob *s, int64_t sector_num,
+  int nb_sectors)
 {
 BlockDriverState *source = s->common.bs;
-int nb_sectors, sectors_per_chunk, nb_chunks, max_iov;
-int64_t end, sector_num, next_chunk, next_sector, hbitmap_next_sector;
-uint64_t delay_ns = 0;
+int sectors_per_chunk, nb_chunks;
+int ret = nb_sectors;
 MirrorOp *op;
-int pnum;
-int64_t ret;
 
-max_iov = MIN(source->bl.max_iov, s->target->bl.max_iov);
-
-s->sector_num = hbitmap_iter_next(&s->hbi);
-if (s->sector_num < 0) {
-bdrv_dirty_iter_init(s->dirty_bitmap, &s->hbi);
-s->sector_num = hbitmap_iter_next(&s->hbi);
-trace_mirror_restart_iter(s, bdrv_get_dirty_count(s->dirty_bitmap));
-assert(s->sector_num >= 0);
-}
-
-hbitmap_next_sector = s->sector_num;
-sector_num = s->sector_num;
 sectors_per_chunk = s->granularity >> BDRV_SECTOR_BITS;
-end = s->bdev_length / BDRV_SECTOR_SIZE;
 
-/* Extend the QEMUIOVector to include all adjacent blocks that will
- * be copied in this operation.
- *
- * We have to do this if we have no backing file yet in the destination,
- * and the cluster size is very large.  Then we need to do COW ourselves.
- * The first time a cluster is copied, copy it entirely.  Note that,
- * because both the granularity and the cluster size are powers of two,
- * the number of sectors to copy cannot exceed one cluster.
- *
- * We also want to extend the QEMUIOVector to include more adjacent
- * dirty blocks if possible, to limit the number of I/O operations and
- * run efficiently even with a small granularity.
- */
-nb_chunks = 0;
-nb_sectors = 0;
-next_sector = sector_num;
-next_chunk = sector_num / sectors_per_chunk;
+/* We can only handle as much as buf_size at a time. */
+nb_sectors = MIN(s->buf_size >> BDRV_SECTOR_BITS, nb_sectors);
+assert(nb_sectors);
 
-/* Wait for I/O to this cluster (from a

[Qemu-devel] [PATCH v10 2/2] mirror: Add mirror_wait_for_io

[Fam Zheng]

The three lines are duplicated a number of times now, refactor a
function.

Signed-off-by: Fam Zheng 
Reviewed-by: Max Reitz 
---
 block/mirror.c | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/block/mirror.c b/block/mirror.c
index 7606aea..a411e02 100644
--- a/block/mirror.c
+++ b/block/mirror.c
@@ -195,6 +195,14 @@ static int mirror_cow_align(MirrorBlockJob *s,
 return ret;
 }
 
+static inline void mirror_wait_for_io(MirrorBlockJob *s)
+{
+assert(!s->waiting_for_io);
+s->waiting_for_io = true;
+qemu_coroutine_yield();
+s->waiting_for_io = false;
+}
+
 /* Submit async read while handling COW.
  * Returns: nb_sectors if no alignment is necessary, or
  *  (new_end - sector_num) if tail is rounded up or down due to
@@ -227,9 +235,7 @@ static int mirror_do_read(MirrorBlockJob *s, int64_t 
sector_num,
 
 while (s->buf_free_count < nb_chunks) {
 trace_mirror_yield_in_flight(s, sector_num, s->in_flight);
-s->waiting_for_io = true;
-qemu_coroutine_yield();
-s->waiting_for_io = false;
+mirror_wait_for_io(s);
 }
 
 /* Allocate a MirrorOp that is used as an AIO callback.  */
@@ -320,9 +326,7 @@ static uint64_t coroutine_fn 
mirror_iteration(MirrorBlockJob *s)
 break;
 }
 trace_mirror_yield_in_flight(s, next_sector, s->in_flight);
-s->waiting_for_io = true;
-qemu_coroutine_yield();
-s->waiting_for_io = false;
+mirror_wait_for_io(s);
 /* Now retry.  */
 } else {
 hbitmap_next = hbitmap_iter_next(&s->hbi);
@@ -412,9 +416,7 @@ static void mirror_free_init(MirrorBlockJob *s)
 static void mirror_drain(MirrorBlockJob *s)
 {
 while (s->in_flight > 0) {
-s->waiting_for_io = true;
-qemu_coroutine_yield();
-s->waiting_for_io = false;
+mirror_wait_for_io(s);
 }
 }
 
@@ -602,9 +604,7 @@ static void coroutine_fn mirror_run(void *opaque)
 if (s->in_flight == MAX_IN_FLIGHT || s->buf_free_count == 0 ||
 (cnt == 0 && s->in_flight > 0)) {
 trace_mirror_yield(s, s->in_flight, s->buf_free_count, cnt);
-s->waiting_for_io = true;
-qemu_coroutine_yield();
-s->waiting_for_io = false;
+mirror_wait_for_io(s);
 continue;
 } else if (cnt != 0) {
 delay_ns = mirror_iteration(s);
-- 
2.4.3

[Qemu-devel] [PATCH v10 0/2] mirror: Improve zero write and discard

[Fam Zheng]

v10: Fix and simplify mirror_cow_align. [Max]

v9: Fix the one bug Max found:
"shrink *= chunk_sectors".

v8: Rebase onto master (didn't pick up Max's rev-by due to non-trivial code
change).

The conflict is around removed lines about "max_iov" and "IOV_MAX" due to
commit 3515727f3, but this also reveals this series forgot that check. So
this revision adds it back:
- Two new fields in MirrorBlockJob are added to cache size info:
  target_cluster_sectors and max_iov.
- mirror_align_cow compares nb_chunks and max_iov, and cut the tail
  appropriately.
- The orphan trace point is removed from trace-events.

Patch 1 rewrites mirror_iteration. Patch 2 is a small DRY cleaning up.

The main benefit is copying unallocated sectors (both zeroed and discarded)
doesn't go through the iov setup loop, as they don't need it.


Fam Zheng (2):
  mirror: Rewrite mirror_iteration
  mirror: Add mirror_wait_for_io

 block/mirror.c | 351 +++--
 tests/qemu-iotests/109.out |  80 +--
 trace-events   |   1 -
 3 files changed, 251 insertions(+), 181 deletions(-)

-- 
2.4.3

Re: [Qemu-devel] [PATCH v1 01/15] crypto: add cryptographic random byte source

[Fam Zheng]

On Tue, 01/12 18:56, Daniel P. Berrange wrote:
> Signed-off-by: Daniel P. Berrange 
> ---
>  crypto/Makefile.objs|  1 +
>  crypto/random.c | 50 
> +
>  include/crypto/random.h | 43 ++
>  3 files changed, 94 insertions(+)
>  create mode 100644 crypto/random.c
>  create mode 100644 include/crypto/random.h
> 
> diff --git a/crypto/Makefile.objs b/crypto/Makefile.objs
> index a3135f1..5f38d2d 100644
> --- a/crypto/Makefile.objs
> +++ b/crypto/Makefile.objs
> @@ -8,6 +8,7 @@ crypto-obj-y += tlscredsanon.o
>  crypto-obj-y += tlscredsx509.o
>  crypto-obj-y += tlssession.o
>  crypto-obj-y += secret.o
> +crypto-obj-y += random.o
>  
>  # Let the userspace emulators avoid linking gnutls/etc
>  crypto-aes-obj-y = aes.o
> diff --git a/crypto/random.c b/crypto/random.c
> new file mode 100644
> index 000..8257d24
> --- /dev/null
> +++ b/crypto/random.c
> @@ -0,0 +1,50 @@
> +/*
> + * QEMU Crypto random number provider
> + *
> + * Copyright (c) 2015 Red Hat, Inc.

s/2015/2016/

> + *
> + * This library is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2 of the License, or (at your option) any later version.
> + *
> + * This library is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with this library; if not, see 
> .
> + *
> + */
> +
> +#include 
> +
> +#include "crypto/random.h"
> +
> +int qcrypto_random_bytes(uint8_t *buf,
> + size_t buflen,
> + Error **errp)
> +{
> +ssize_t ret;
> +int fd = open("/dev/random", O_RDONLY);
> +if (fd < 0) {
> +error_setg_errno(errp, errno,
> + "Unable to open /dev/random");
> +return -1;
> +}
> +
> +while (buflen) {
> +ret = read(fd, buf, buflen);
> +if (ret < 0) {
> +error_setg_errno(errp, errno,
> + "Unable to read random bytes");
> +close(fd);
> +return -1;
> +}
> +buflen -= ret;
> +}
> +
> +close(fd);
> +return 0;
> +}
> diff --git a/include/crypto/random.h b/include/crypto/random.h
> new file mode 100644
> index 000..ce1626b
> --- /dev/null
> +++ b/include/crypto/random.h
> @@ -0,0 +1,43 @@
> +/*
> + * QEMU Crypto random number provider
> + *
> + * Copyright (c) 2015 Red Hat, Inc.

s/2015/2016/

> + *
> + * This library is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2 of the License, or (at your option) any later version.
> + *
> + * This library is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with this library; if not, see 
> .
> + *
> + */
> +
> +#ifndef QCRYPTO_RANDOM_H__
> +#define QCRYPTO_RANDOM_H__
> +
> +#include "qemu-common.h"
> +#include "qapi/error.h"
> +
> +
> +/**
> + * qcrypto_random_bytes:
> + * @buf: the buffer to fill
> + * @buflen: length of @buf in bytes
> + * @errp: pointer to uninitialized error objet

s/objet/object/, but more importantly @errp must be NULL, so it's not exact to
say it "uninitialized".

> + *
> + * Fill @buf with @buflen bytes of random data
> + *
> + * Returns 0 on sucess, -1 on error
> + */
> +int qcrypto_random_bytes(uint8_t *buf,
> + size_t buflen,
> + Error **errp);
> +
> +
> +#endif /* QCRYPTO_RANDOM_H__ */
> -- 
> 2.5.0
> 
> 

Re: [Qemu-devel] [PATCH v2 3/7] device_tree: introduce qemu_fdt_node_path

[David Gibson]

On Tue, Jan 12, 2016 at 06:02:00PM +0100, Eric Auger wrote:
> Hi David,
> On 01/12/2016 05:28 AM, David Gibson wrote:
> > On Mon, Jan 11, 2016 at 11:35:50AM +0100, Eric Auger wrote:
> >> Hi David,
> >> On 01/11/2016 03:38 AM, David Gibson wrote:
> >>> On Wed, Jan 06, 2016 at 03:13:21PM +, Eric Auger wrote:
>  This new helper routine returns the node path of a device
>  referred to by its node name and compat string.
> >>>
> >>> What if there are multiple nodes matching the name and compat?
> >> The function would return the first one. I can improve the doc comment.
> >> Do you think it is a problem stopping at the first one? Is it a real
> >> life test case I have to handle here?
> > 
> > Well, I don't know of a specific system which will have this, but it's
> > absolutely possible to get this situation:  e.g. two different PCI
> > busses, both of which have their own slot 0 populated with different
> > instances of the same device.
> > 
> > Whether it's possible for platform devices will depend on the
> > platform's specific bus toplogies, but you certainly can't rule it out
> > in general.
> OK I will handle that case then. I hope I will be able to test it.

One case where this might occur in practice for platform devices is if
you have a system built with multiple instances of a SoC.  A
peripheral on SoC 0 is likely to have the same name and compatible as
the same peripheral on Soc 1, just inside a different parent node.

> > I could consider adding a new libfdt function like
> > fdt_node_offset_by_compatible() that searches by name as well.  It's
> > just I'm not sure that matching by name and compatible isn't a sign of
> > a poor approach in the caller.
> well I can't really comment. That looked the most straightforward to me
> given the current libfdt API. But not sure it's worth to invest in a new
> function in libfdt
> 
> Thanks!
> 
> Eric
> > 
> 

-- 
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


signature.asc
Description: PGP signature

Re: [Qemu-devel] [PATCH] sheepdog: allow to delete snapshot

[Hitoshi Mitake]

On Wed, Dec 23, 2015 at 9:22 PM, Hitoshi Mitake <
mitake.hito...@lab.ntt.co.jp> wrote:

> From: Vasiliy Tolstov 
>
> This patch implements a blockdriver function bdrv_snapshot_delete() in
> the sheepdog driver. With the new function, snapshots of sheepdog can
> be deleted from libvirt.
>
> Cc: Jeff Cody 
> Signed-off-by: Hitoshi Mitake 
> Signed-off-by: Vasiliy Tolstov 
>

ping, Jeff?

Thanks,
Hitoshi


> ---
>  block/sheepdog.c | 125
> ++-
>  1 file changed, 123 insertions(+), 2 deletions(-)
>
> diff --git a/block/sheepdog.c b/block/sheepdog.c
> index d80e4ed..0a4f2fc 100644
> --- a/block/sheepdog.c
> +++ b/block/sheepdog.c
> @@ -283,6 +283,12 @@ static inline bool is_snapshot(struct SheepdogInode
> *inode)
>  return !!inode->snap_ctime;
>  }
>
> +static inline size_t count_data_objs(const struct SheepdogInode *inode)
> +{
> +return DIV_ROUND_UP(inode->vdi_size,
> +(1UL << inode->block_size_shift));
> +}
> +
>  #undef DPRINTF
>  #ifdef DEBUG_SDOG
>  #define DPRINTF(fmt, args...)   \
> @@ -2479,13 +2485,128 @@ out:
>  return ret;
>  }
>
> +#define NR_BATCHED_DISCARD 128
> +
> +static bool remove_objects(BDRVSheepdogState *s)
> +{
> +int fd, i = 0, nr_objs = 0;
> +Error *local_err = NULL;
> +int ret = 0;
> +bool result = true;
> +SheepdogInode *inode = &s->inode;
> +
> +fd = connect_to_sdog(s, &local_err);
> +if (fd < 0) {
> +error_report_err(local_err);
> +return false;
> +}
> +
> +nr_objs = count_data_objs(inode);
> +while (i < nr_objs) {
> +int start_idx, nr_filled_idx;
> +
> +while (i < nr_objs && !inode->data_vdi_id[i]) {
> +i++;
> +}
> +start_idx = i;
> +
> +nr_filled_idx = 0;
> +while (i < nr_objs && nr_filled_idx < NR_BATCHED_DISCARD) {
> +if (inode->data_vdi_id[i]) {
> +inode->data_vdi_id[i] = 0;
> +nr_filled_idx++;
> +}
> +
> +i++;
> +}
> +
> +ret = write_object(fd, s->aio_context,
> +   (char *)&inode->data_vdi_id[start_idx],
> +   vid_to_vdi_oid(s->inode.vdi_id),
> inode->nr_copies,
> +   (i - start_idx) * sizeof(uint32_t),
> +   offsetof(struct SheepdogInode,
> +data_vdi_id[start_idx]),
> +   false, s->cache_flags);
> +if (ret < 0) {
> +error_report("failed to discard snapshot inode.");
> +result = false;
> +goto out;
> +}
> +}
> +
> +out:
> +closesocket(fd);
> +return result;
> +}
> +
>  static int sd_snapshot_delete(BlockDriverState *bs,
>const char *snapshot_id,
>const char *name,
>Error **errp)
>  {
> -/* FIXME: Delete specified snapshot id.  */
> -return 0;
> +uint32_t snap_id = 0;
> +char snap_tag[SD_MAX_VDI_TAG_LEN];
> +Error *local_err = NULL;
> +int fd, ret;
> +char buf[SD_MAX_VDI_LEN + SD_MAX_VDI_TAG_LEN];
> +BDRVSheepdogState *s = bs->opaque;
> +unsigned int wlen = SD_MAX_VDI_LEN + SD_MAX_VDI_TAG_LEN, rlen = 0;
> +uint32_t vid;
> +SheepdogVdiReq hdr = {
> +.opcode = SD_OP_DEL_VDI,
> +.data_length = wlen,
> +.flags = SD_FLAG_CMD_WRITE,
> +};
> +SheepdogVdiRsp *rsp = (SheepdogVdiRsp *)&hdr;
> +
> +if (!remove_objects(s)) {
> +return -1;
> +}
> +
> +memset(buf, 0, sizeof(buf));
> +memset(snap_tag, 0, sizeof(snap_tag));
> +pstrcpy(buf, SD_MAX_VDI_LEN, s->name);
> +if (qemu_strtoul(snapshot_id, NULL, 10, (unsigned long *)&snap_id)) {
> +return -1;
> +}
> +
> +if (snap_id) {
> +hdr.snapid = snap_id;
> +} else {
> +pstrcpy(snap_tag, sizeof(snap_tag), snapshot_id);
> +pstrcpy(buf + SD_MAX_VDI_LEN, SD_MAX_VDI_TAG_LEN, snap_tag);
> +}
> +
> +ret = find_vdi_name(s, s->name, snap_id, snap_tag, &vid, true,
> +&local_err);
> +if (ret) {
> +return ret;
> +}
> +
> +fd = connect_to_sdog(s, &local_err);
> +if (fd < 0) {
> +error_report_err(local_err);
> +return -1;
> +}
> +
> +ret = do_req(fd, s->aio_context, (SheepdogReq *)&hdr,
> + buf, &wlen, &rlen);
> +closesocket(fd);
> +if (ret) {
> +return ret;
> +}
> +
> +switch (rsp->result) {
> +case SD_RES_NO_VDI:
> +error_report("%s was already deleted", s->name);
> +case SD_RES_SUCCESS:
> +break;
> +default:
> +error_report("%s, %s", sd_strerror(rsp->result), s->name);
> +return -1;
> +}
> +
> +return ret;
>  }
>
>  static int sd_snapshot_list(BlockDriverState *bs, QEMUSnapshotInfo
> **psn_tab)
> --
> 1.9.1
>

Re: [Qemu-devel] [Xen-devel] [PATCH v4] igd-passthrough-i440FX: convert to realize()

[Hao, Xudong]

"can't boot up" means guest doesn't boot at all, guest will stop to booting 
after adding vga device, detail log in attachment.

Thanks,
-Xudong


> -Original Message-
> From: qemu-devel-bounces+xudong.hao=intel@nongnu.org [mailto:qemu-
> devel-bounces+xudong.hao=intel@nongnu.org] On Behalf Of Gerd
> Hoffmann
> Sent: Tuesday, January 12, 2016 6:25 PM
> To: Hao, Xudong 
> Cc: Lars Kurth ; xen-de...@lists.xensource.com; Stefano
> Stabellini ; Lars Kurth
> ; Michael S. Tsirkin ; qemu-
> de...@nongnu.org; Cao jin ; Stefano Stabellini
> 
> Subject: Re: [Qemu-devel] [Xen-devel] [PATCH v4] igd-passthrough-i440FX:
> convert to realize()
> 
> On Di, 2016-01-12 at 09:50 +, Hao, Xudong wrote:
> > With latest qemu 7b8a354d4716, RHEL7.2 (with default kernel) VM still can't
> boot up with IGD.
> 
> There is another bug, using pci_default_write_config() doesn't fly as this 
> checks
> writes against wmask and the registers in question are not whitelisted ...
> 
> I've just rebased my igd patch series which (among other stuff) fixes that 
> bug:
>   https://www.kraxel.org/cgit/qemu/log/?h=work/igd
>   git://git.kraxel.org/qemu work/igd
> 
> Can you give it a spin?
> 
> Also: what does "can't boot up" mean exactly?  Guest doesn't boot at all?  
> Guest
> boots, but igd/console/Xorg doesn't work?  In case of the
> latter:  Any chance to login via network and get a kernel log?
> 
> thanks,
>   Gerd
> 



rhel7-default-kernel-boot.log
Description: rhel7-default-kernel-boot.log

Re: [Qemu-devel] [PATCH] ARM: Virt: Don't generate RTC ACPI node when using UEFI

[Shannon Zhao]

On 2016/1/12 23:30, Peter Maydell wrote:
> On 12 January 2016 at 15:24, Shannon Zhao  wrote:
>> > When booting VM through UEFI, UEFI takes ownership of the RTC hardware.
>> > To DTB UEFI could call libfdt api to disable the RTC device node, but to
>> > ACPI it couldn't do that. Therefore, we don't generate the RTC ACPI
>> > device in QEMU when using UEFI.
> I don't really understand this. I thought that if we were
> using ACPI then we would always be doing it via UEFI?
> 
Currently this is true and maybe for a long time this is also true.

> Also I think if UEFI wants to take command of some of the
> hardware it ought to be UEFI's job to adjust the tables
> accordingly before it passes them on to the guest OS.
Yes, the ideal method is adjusting the DSDT table in UEFI. But there is
almost no way to parse the DSDT table in UEFI. If we want to support
that it will introduce ACPI interpreter. This makes it more complex.

There is a discussion [1] about this on the edk2 list.

[1]https://www.mail-archive.com/edk2-devel@lists.01.org/msg06301.html

Thanks,
-- 
Shannon

[Qemu-devel] [PATCH v2 1/2] blockdev: Error out on negative throttling option values

[Fam Zheng]

The implicit casting from unsigned int to double changes negative values
into large positive numbers and accepts them.  We should instead print
an error.

Check the number range so this case is catched and reported.

Signed-off-by: Fam Zheng 
---
 blockdev.c  |  3 ++-
 include/qemu/throttle.h |  2 ++
 util/throttle.c | 16 ++--
 3 files changed, 10 insertions(+), 11 deletions(-)

diff --git a/blockdev.c b/blockdev.c
index 2df0c6d..1afef87 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -348,7 +348,8 @@ static bool check_throttle_config(ThrottleConfig *cfg, 
Error **errp)
 }
 
 if (!throttle_is_valid(cfg)) {
-error_setg(errp, "bps/iops/maxs values must be 0 or greater");
+error_setg(errp, "bps/iops/maxs values must be within [0, %" PRId64
+ ")", (int64_t)THROTTLE_VALUE_MAX);
 return false;
 }
 
diff --git a/include/qemu/throttle.h b/include/qemu/throttle.h
index 12faaad..b5d 100644
--- a/include/qemu/throttle.h
+++ b/include/qemu/throttle.h
@@ -29,6 +29,8 @@
 #include "qemu-common.h"
 #include "qemu/timer.h"
 
+#define THROTTLE_VALUE_MAX 1000L
+
 typedef enum {
 THROTTLE_BPS_TOTAL,
 THROTTLE_BPS_READ,
diff --git a/util/throttle.c b/util/throttle.c
index 1113671..af4bc95 100644
--- a/util/throttle.c
+++ b/util/throttle.c
@@ -282,22 +282,18 @@ bool throttle_conflicting(ThrottleConfig *cfg)
  */
 bool throttle_is_valid(ThrottleConfig *cfg)
 {
-bool invalid = false;
 int i;
 
 for (i = 0; i < BUCKETS_COUNT; i++) {
-if (cfg->buckets[i].avg < 0) {
-invalid = true;
+if (cfg->buckets[i].avg < 0 ||
+cfg->buckets[i].max < 0 ||
+cfg->buckets[i].avg > THROTTLE_VALUE_MAX ||
+cfg->buckets[i].max > THROTTLE_VALUE_MAX) {
+return false;
 }
 }
 
-for (i = 0; i < BUCKETS_COUNT; i++) {
-if (cfg->buckets[i].max < 0) {
-invalid = true;
-}
-}
-
-return !invalid;
+return true;
 }
 
 /* check if bps_max/iops_max is used without bps/iops
-- 
2.4.3

[Qemu-devel] [PATCH v2 2/2] iotests: Test that negative throttle values are rejected

[Fam Zheng]

Signed-off-by: Fam Zheng 
---
 tests/qemu-iotests/051| 11 +++
 tests/qemu-iotests/051.out| 21 +
 tests/qemu-iotests/051.pc.out | 21 +
 3 files changed, 53 insertions(+)

diff --git a/tests/qemu-iotests/051 b/tests/qemu-iotests/051
index d91f80b..2c9b07e 100755
--- a/tests/qemu-iotests/051
+++ b/tests/qemu-iotests/051
@@ -263,6 +263,17 @@ run_qemu -drive 
file="$TEST_IMG",iops_size=1234,throttling.iops-size=5678
 run_qemu -drive file="$TEST_IMG",readonly=on,read-only=off
 
 echo
+echo === Catching nagative throttling values ===
+echo
+
+run_qemu -drive file="$TEST_IMG",iops=-1
+run_qemu -drive file="$TEST_IMG",bps=-2
+run_qemu -drive file="$TEST_IMG",bps_rd=-3
+run_qemu -drive file="$TEST_IMG",bps_rd_max=-3
+run_qemu -drive file="$TEST_IMG",throttling.iops-total=-4
+run_qemu -drive file="$TEST_IMG",throttling.bps-total=-5
+
+echo
 echo === Parsing protocol from file name ===
 echo
 
diff --git a/tests/qemu-iotests/051.out b/tests/qemu-iotests/051.out
index bf886ce..82d2121 100644
--- a/tests/qemu-iotests/051.out
+++ b/tests/qemu-iotests/051.out
@@ -285,6 +285,27 @@ Testing: -drive 
file=TEST_DIR/t.qcow2,readonly=on,read-only=off
 QEMU_PROG: -drive file=TEST_DIR/t.qcow2,readonly=on,read-only=off: 'read-only' 
and its alias 'readonly' can't be used at the same time
 
 
+=== Catching nagative throttling values ===
+
+Testing: -drive file=TEST_DIR/t.qcow2,iops=-1
+QEMU_PROG: -drive file=TEST_DIR/t.qcow2,iops=-1: bps/iops/maxs values must be 
within [0, 1000)
+
+Testing: -drive file=TEST_DIR/t.qcow2,bps=-2
+QEMU_PROG: -drive file=TEST_DIR/t.qcow2,bps=-2: bps/iops/maxs values must be 
within [0, 1000)
+
+Testing: -drive file=TEST_DIR/t.qcow2,bps_rd=-3
+QEMU_PROG: -drive file=TEST_DIR/t.qcow2,bps_rd=-3: bps/iops/maxs values must 
be within [0, 1000)
+
+Testing: -drive file=TEST_DIR/t.qcow2,bps_rd_max=-3
+QEMU_PROG: -drive file=TEST_DIR/t.qcow2,bps_rd_max=-3: bps/iops/maxs values 
must be within [0, 1000)
+
+Testing: -drive file=TEST_DIR/t.qcow2,throttling.iops-total=-4
+QEMU_PROG: -drive file=TEST_DIR/t.qcow2,throttling.iops-total=-4: 
bps/iops/maxs values must be within [0, 1000)
+
+Testing: -drive file=TEST_DIR/t.qcow2,throttling.bps-total=-5
+QEMU_PROG: -drive file=TEST_DIR/t.qcow2,throttling.bps-total=-5: bps/iops/maxs 
values must be within [0, 1000)
+
+
 === Parsing protocol from file name ===
 
 Testing: -hda foo:bar
diff --git a/tests/qemu-iotests/051.pc.out b/tests/qemu-iotests/051.pc.out
index a5dfc33..4b29289 100644
--- a/tests/qemu-iotests/051.pc.out
+++ b/tests/qemu-iotests/051.pc.out
@@ -379,6 +379,27 @@ Testing: -drive 
file=TEST_DIR/t.qcow2,readonly=on,read-only=off
 QEMU_PROG: -drive file=TEST_DIR/t.qcow2,readonly=on,read-only=off: 'read-only' 
and its alias 'readonly' can't be used at the same time
 
 
+=== Catching nagative throttling values ===
+
+Testing: -drive file=TEST_DIR/t.qcow2,iops=-1
+QEMU_PROG: -drive file=TEST_DIR/t.qcow2,iops=-1: bps/iops/maxs values must be 
within [0, 1000)
+
+Testing: -drive file=TEST_DIR/t.qcow2,bps=-2
+QEMU_PROG: -drive file=TEST_DIR/t.qcow2,bps=-2: bps/iops/maxs values must be 
within [0, 1000)
+
+Testing: -drive file=TEST_DIR/t.qcow2,bps_rd=-3
+QEMU_PROG: -drive file=TEST_DIR/t.qcow2,bps_rd=-3: bps/iops/maxs values must 
be within [0, 1000)
+
+Testing: -drive file=TEST_DIR/t.qcow2,bps_rd_max=-3
+QEMU_PROG: -drive file=TEST_DIR/t.qcow2,bps_rd_max=-3: bps/iops/maxs values 
must be within [0, 1000)
+
+Testing: -drive file=TEST_DIR/t.qcow2,throttling.iops-total=-4
+QEMU_PROG: -drive file=TEST_DIR/t.qcow2,throttling.iops-total=-4: 
bps/iops/maxs values must be within [0, 1000)
+
+Testing: -drive file=TEST_DIR/t.qcow2,throttling.bps-total=-5
+QEMU_PROG: -drive file=TEST_DIR/t.qcow2,throttling.bps-total=-5: bps/iops/maxs 
values must be within [0, 1000)
+
+
 === Parsing protocol from file name ===
 
 Testing: -hda foo:bar
-- 
2.4.3

[Qemu-devel] [PATCH v2 0/2] block: Reject negative values for throttling options

[Fam Zheng]

v2: Check the value range and report an appropriate error. [Berto]

Now the negative values are silently converted to a huge positive number
because we are doing implicit casting from uint64_t to double. Fix it and add a
test case (this was once fixed in 7d81c1413c9 but regressed when the block
device option parsing code was changed).


Fam Zheng (2):
  blockdev: Error out on negative throttling option values
  iotests: Test that negative throttle values are rejected

 blockdev.c|  3 ++-
 include/qemu/throttle.h   |  2 ++
 tests/qemu-iotests/051| 11 +++
 tests/qemu-iotests/051.out| 21 +
 tests/qemu-iotests/051.pc.out | 21 +
 util/throttle.c   | 16 ++--
 6 files changed, 63 insertions(+), 11 deletions(-)

-- 
2.4.3

Re: [Qemu-devel] [PATCH v3 7/7] raspi: add raspberry pi 2 machine

[Peter Crosthwaite]

On Tue, Jan 12, 2016 at 3:53 PM, Andrew Baumann
 wrote:
>> From: Peter Crosthwaite [mailto:crosthwaitepe...@gmail.com]
>> Sent: Monday, 11 January 2016 19:58
> [...]
>> > +static void write_board_setup(ARMCPU *cpu, const struct arm_boot_info
>> *info)
>>
>> This is almost identical to Highbank, I'm guessing you are stubbing monitor
>> firmware where you get away with nopping all the SMCs? Maybe we should
>> split
>> Highbanks version off to common code, and parameterise the few
>> differences.
>>
>> write_board_setup_dummy_monitior(ARMCPU *cpu ..., uint32_t scr_flags);
>>
>> or something like it. Makes sense to be in arm/boot.c .
>
> Actually, I added this only to make Linux happy (and yes, it was derived from 
> highbank). Without it, I was seeing complaints about:
> Ignoring attempt to switch CPSR_A flag from non-secure world with SCR.AW bit 
> clear
> Ignoring attempt to switch CPSR_F flag from non-secure world with SCR.FW bit 
> clear
>
> I don't believe anything actually uses the SMC handler after boot. I think 
> it's just an architectural requirement to flush the change to non-secure mode.
>
> I would prefer not to touch highbank, because I don't know how to test it. Is 
> it better to submit this patch without the board setup?
>

I can test Highbank for you, or you can use this project:

https://lists.gnu.org/archive/html/qemu-devel/2015-10/msg00755.html

The build takes a while and costs about 50GB of disk space, but the
amount of setup needed should be pretty low.

FWIW, that was the test system that found the need for this FW in HB.

>>
>> > +{
>> > +static const uint32_t board_setup[] = {
>> > +/* MVBAR_ADDR: secure monitor vectors */
>> > +0xEAFE, /* (spin) */
>> > +0xEAFE, /* (spin) */
>> > +0xE1B0F00E, /* movs pc, lr ;SMC exception return */
>> > +0xEAFE, /* (spin) */
>> > +0xEAFE, /* (spin) */
>> > +0xEAFE, /* (spin) */
>> > +0xEAFE, /* (spin) */
>> > +0xEAFE, /* (spin) */
>> > +/* BOARDSETUP_ADDR */
>> > +0xE3A00B01, /* mov r0, #0x400 ;MVBAR_ADDR */
>> > +0xEE0C0F30, /* mcr p15, 0, r0, c12, c0, 1 ;set MVBAR */
>> > +0xE3A00031, /* mov r0, #0x31  ;enable AW, FW, NS 
>> > */
>> > +0xEE010F11, /* mcr p15, 0, r0, c1, c1, 0  ;write SCR */
>>
>> If combining with HB, could you do this as read-modify-write?
>>
>> > +0xE1A0100E, /* mov r1, lr ;save LR across SMC 
>> > */
>> > +0xE1600070, /* smc #0 ;monitor call */
>> > +0xE1A0F001, /* mov pc, r1 ;return */
>>
>> I'm looking at the Highbank version which doesn't save lr across the SMC and
>> wondering why it doesn't. Is this banked by CPU mode and do you get from
>> already-in-monitor-mode? Or simply, that Highbank code may have a bug?
>
> I think it's needed because I call the board setup blob on each core (from 
> the smpboot blob), but highbank doesn't. I found that I needed to do this to 
> avoid the above warnings on an SMP boot; I don't know why highbank doesn't.
>
> [...]
>> > +/* Allocate and map RAM */
>> > +memory_region_allocate_system_memory(&s->ram,
>> OBJECT(machine), "ram",
>> > + machine->ram_size);
>> > +memory_region_add_subregion_overlap(get_system_memory(), 0,
>> &s->ram, 0);
>>
>> I thought the SoC handled this now? Why do you need to add to
>> system_memory?
>
> If I don't map it here, how do RAM accesses from the CPUs work?
>

Do the CPUs not have their AS'es connected to your custom ASes by the SoC layer?

> Or are you saying that I should still do this, but do it in the SoC not the 
> board level?
>

I was hoping we could get away with 0 use of system_memory.

Regards,
Peter

> [...]
>> > +static void raspi2_machine_init(MachineClass *mc)
>> > +{
>> > +mc->desc = "Raspberry Pi 2";
>> > +mc->init = raspi2_init;
>> > +mc->block_default_type = IF_SD;
>>
>> > +mc->no_parallel = 1;
>> > +mc->no_floppy = 1;
>> > +mc->no_cdrom = 1;
>>
>> Curious, what do these do from a user-visible point of view? Maybe we
>> should
>> add them to more ARM boards as they certainly make sense.
>
> I think they turn off some redundant stuff in the UI (e.g., there's no 
> View->Parallel menu option). I'm guessing they also disable the -cdrom and  
> -fd* options, but didn't test that.
>
> Cheers,
> Andrew

Re: [Qemu-devel] [Qemu-block] [PATCH 1/2] blockdev: Error out on negative throttling option values

[Fam Zheng]

On Tue, 01/12 16:00, Alberto Garcia wrote:
> On Mon 11 Jan 2016 06:42:38 AM CET, Fam Zheng  wrote:
> 
> > The implicit casting from unsigned int to double changes negative
> > values into large positive numbers, whereas explicitly casting to
> > signed integer first will let us catch the invalid value and report
> > error correctly:
> >
> > $ qemu-system-x86_64 -drive file=null-co://,iops=-1
> > qemu-system-x86_64: -drive file=null-co://,iops=-1: bps/iops/maxs
> > values must be 0 or greater
> >
> 
> >  throttle_cfg->buckets[THROTTLE_BPS_TOTAL].avg =
> > -qemu_opt_get_number(opts, "throttling.bps-total", 0);
> > +(int64_t)qemu_opt_get_number(opts, "throttling.bps-total", 0);
> 
> It seems to me that the problem is that qemu_opt_get_number() returns a
> value different from the one specified in the comand-line.
> 
> How do we even tell the difference between a negative number and its
> bit-to-bit positive equivalent?

We can't. :(

> 
> If we are going to reject very large numbers I would rather check that
> the throtting values are within a sane range and throw an error
> otherwise.

Yes, that is probably more accurate to the user.

Fam

Re: [Qemu-devel] [PATCH 1/5] block: added lock image option and callback

[Fam Zheng]

On Tue, 01/12 18:59, Denis V. Lunev wrote:
> On 01/12/2016 02:33 PM, Fam Zheng wrote:
> >On Tue, 01/12 11:10, Kevin Wolf wrote:
> >>The problem is that libvirt already takes a lock, as Dan mentioned in
> >>another reply in this thread, so we can't enable locking in qemu by
> >>default. It would always fail when run under libvirt.
> >>
> >>Unless I'm seriously mistaken, this means that flock() inside qemu is
> >>dead.
> >Yes, I see the problem with libvirt, but can we instead do these?
> >
> >   1) Do a soft flock() in QEMU invocation. If it fails, sliently ignore.
> >   2) Do a hard flock() in qemu-img invocation. If it fails, report and exit.
> >
> >This way, if libvirt is holding flock, we can assume libvirt is actually
> >"using" the image: 1) just works as before, but 2) will not break the qcow2.
> >That is still a slight improvement, and does solve the reckless "qemu-img
> >snapshot create" user's problem.
> >
> >Fam
> There is a better way though.
> 
> If we will switch default in my patch from 'nolock' to 'lock' then
> pour guys which are calling qemu-img etc stuff will see the lock
> as necessary while 'proper management software' aka libvirt
> will be able to call qemu/qemu-img etc with proper 'nolock'
> flag as they do care about the locking.

That is wrong because then we break old libvirt with the new qemu-img (acquires
lock by default), which is IMO a breakage of backward compatibility.

Fam

> 
> Though from my POW all locks should be taken in the responsible
> entity, i.e. qemu or qemu-img as if locks are held by libvirt then
> they should be re-taken on f.e. daemon restart, which could happen.
> This is not that convenient.
> 
> Den

Re: [Qemu-devel] [PATCH v3 6/7] bcm2836: add bcm2836 soc device

[Andrew Baumann]

> From: Peter Crosthwaite [mailto:crosthwaitepe...@gmail.com]
> Sent: Tuesday, 12 January 2016 15:15
> On Tue, Jan 12, 2016 at 2:56 PM, Andrew Baumann
>  wrote:
> >> From: Peter Crosthwaite [mailto:crosthwaitepe...@gmail.com]
> >> Sent: Monday, 11 January 2016 19:57
> >> On Thu, Dec 31, 2015 at 04:31:33PM -0800, Andrew Baumann wrote:
> >> > +/* TODO: probably shouldn't be using smp_cpus here */
> >>
> >> I agree. I have started ignoring smp_cpus completely for new ARM SoCs,
> >> as if you change the number of CPUs for a SoC, it is not that SoC
> >> anymore. The virt platform is suitable for CPU scalability, whereas
> >> with ARM SoCs, cpu # variation is invalid.
> >>
> >> > +assert(smp_cpus <= BCM2836_NCPUS);
> >> > +for (n = 0; n < smp_cpus; n++) {
> >>
> >> So can we just use BCM2836_NCPUS here as the loop bound? Any
> >> conditionals out there check the existance of CPUs can be removed or
> >> promoted to assert() as a BCM2836 must always have 4 CPUs.
> >
> > I'd love to do that, but there's at least one good reason to respect the 
> > -smp
> parameter and not start all the CPUs: with full-system emulation, qemu is
> noticeably faster emulating a single-core target than multi-core. E.g., Linux
> boots fine with -smp 1 (it fails to start the other CPUs but proceeds with 
> just
> one), and many users will be better off running it this way, so I definitely
> don't want to break that.
> >
> 
> What are the secondary CPUs doing in this case? In most systems they
> end up penning on a WFI/WFE. Is Linux actually trying to do the SMP
> bringup - are you are getting a secondary entry point?
> 
> If not and it is just a busy wait killing perf, start-powered-off
> property might help. Is the firmware responsible for secondary-penning
> an actual busy-wait or does it involve power-control periphs etc?

Yes, it is a busy-wait in my smpboot blob. (I suppose I could figure out how to 
replace it with an interrupt-driven version, but it seemed like a lot of 
pointless work compared to not starting the CPU.) On a first quick test, that 
property seems to do the trick, thanks.

Andrew

Re: [Qemu-devel] [PATCH 1/5] block: added lock image option and callback

[Fam Zheng]

On Tue, 01/12 13:24, Daniel P. Berrange wrote:
> On Tue, Jan 12, 2016 at 09:17:51PM +0800, Fam Zheng wrote:
> > On Tue, 01/12 13:28, Kevin Wolf wrote:
> > > Am 12.01.2016 um 12:33 hat Fam Zheng geschrieben:
> > > > On Tue, 01/12 11:10, Kevin Wolf wrote:
> > > > > 
> > > > > The problem is that libvirt already takes a lock, as Dan mentioned in
> > > > > another reply in this thread, so we can't enable locking in qemu by
> > > > > default. It would always fail when run under libvirt.
> > > > > 
> > > > > Unless I'm seriously mistaken, this means that flock() inside qemu is
> > > > > dead.
> > > > 
> > > > Yes, I see the problem with libvirt, but can we instead do these?
> > > > 
> > > >   1) Do a soft flock() in QEMU invocation. If it fails, sliently ignore.
> > > >   2) Do a hard flock() in qemu-img invocation. If it fails, report and 
> > > > exit.
> > > > 
> > > > This way, if libvirt is holding flock, we can assume libvirt is actually
> > > > "using" the image: 1) just works as before, but 2) will not break the 
> > > > qcow2.
> > > > That is still a slight improvement, and does solve the reckless 
> > > > "qemu-img
> > > > snapshot create" user's problem.
> > > 
> > > This makes two assumptions:
> > > 
> > > 1. qemu is only ever invoked by libvirt
> > > 2. qemu-img is only ever invoked by human users
> > > 
> > > Both of them are wrong. 1. just means that manually started QEMUs are
> > > unprotected (which is already bad), but 2. means that qemu-img called by
> > > libvirt fails (which is obviously not acceptable).
> > 
> > No, my assumptions are:
> > 
> > a. libvirt calls flock() when invoking qemu;
> > b. libvirt doesn't call flock() when invoking qemu-img; (if I read the 
> > libvirt
> >code correctly, input from libvirt folks needed);
> 
> b. is /currently/ true, but I wouldn't guarantee that will always be
> true, because we've (vague) plans to extend our locking infrastructure
> to cover our storage pools APIs too, at which point we'd likely be
> have locking around qemu-img based API calls too. There's also likelihood
> we'll make our locking API public, in which case it is possible that
> an app using libvirt could have acquired locks on the file.
> 

This is not a problem. When you extend that in libvirt, you can at meanwhile
modify it to always specify "nolock=on" when invoking the new qemu-img so that
it doesn't check flock().

Fam

Re: [Qemu-devel] [PATCH v6 10/11] spapr: CPU hotplug support

[Alexey Kardashevskiy]

On 01/08/2016 05:55 PM, Bharata B Rao wrote:

Support CPU hotplug via device-add command like this:

(qemu) device_add powerpc64-cpu-core,id=core2

In response to device_add, CPU core device will be created. CPU core
device creates and realizes CPU thread devices. If the machine type
supports CPU hotplug, boot-time CPUs are created as CPU core devices
otherwise they continue to be created as individual CPU devices.

Set up device tree entries for the hotplugged CPU core and use the
exising EPOW event infrastructure to send CPU hotplug notification to
the guest.

Signed-off-by: Bharata B Rao 
---
  hw/ppc/spapr.c  | 183 ++--
  hw/ppc/spapr_events.c   |   3 +
  hw/ppc/spapr_rtas.c |  24 ++
  include/hw/ppc/spapr.h  |   5 ++
  target-ppc/translate_init.c |   8 ++
  5 files changed, 216 insertions(+), 7 deletions(-)

diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index a3ce1db..c2af9ca 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -63,6 +63,7 @@

  #include "hw/compat.h"
  #include "qemu-common.h"
+#include "hw/ppc/cpu-core.h"

  #include 

@@ -600,6 +601,18 @@ static void spapr_populate_cpu_dt(CPUState *cs, void *fdt, 
int offset,
  size_t page_sizes_prop_size;
  uint32_t vcpus_per_socket = smp_threads * smp_cores;
  uint32_t pft_size_prop[] = {0, cpu_to_be32(spapr->htab_shift)};
+sPAPRMachineClass *smc = SPAPR_MACHINE_GET_CLASS(qdev_get_machine());
+sPAPRDRConnector *drc;
+sPAPRDRConnectorClass *drck;
+int drc_index;
+
+if (smc->dr_cpu_enabled) {
+drc = spapr_dr_connector_by_id(SPAPR_DR_CONNECTOR_TYPE_CPU, index);
+g_assert(drc);
+drck = SPAPR_DR_CONNECTOR_GET_CLASS(drc);
+drc_index = drck->get_index(drc);
+_FDT((fdt_setprop_cell(fdt, offset, "ibm,my-drc-index", drc_index)));
+}

  /* Note: we keep CI large pages off for now because a 64K capable guest
   * provisioned with large pages might otherwise try to map a qemu
@@ -1743,6 +1756,8 @@ static void ppc_spapr_init(MachineState *machine)
  char *filename;
  int smt = kvmppc_smt_threads();
  int smp_max_cores = max_cpus/smp_threads;
+int spapr_smp_cores = smp_cpus/smp_threads;
+Object *core;

  msi_supported = true;

@@ -1822,13 +1837,22 @@ static void ppc_spapr_init(MachineState *machine)
  if (machine->cpu_model == NULL) {
  machine->cpu_model = kvm_enabled() ? "host" : "POWER7";
  }
-for (i = 0; i < smp_cpus; i++) {
-cpu = cpu_ppc_init(machine->cpu_model);
-if (cpu == NULL) {
-fprintf(stderr, "Unable to find PowerPC CPU definition\n");
-exit(1);
+
+if (smc->dr_cpu_enabled) {
+for (i = 0; i < spapr_smp_cores; i++) {
+core = object_new(TYPE_POWERPC_CPU_CORE);
+object_property_set_bool(core, true, "realized", &error_abort);
+}
+} else {
+for (i = 0; i < smp_cpus; i++) {
+cpu = cpu_ppc_init(machine->cpu_model);
+if (cpu == NULL) {
+fprintf(stderr, "Unable to find PowerPC CPU definition\n");
+exit(1);
+}
+object_property_set_bool(OBJECT(cpu), true, "realized",
+ &error_abort);
  }
-spapr_cpu_init(spapr, cpu);
  }

  if (kvm_enabled()) {
@@ -,10 +2246,125 @@ out:
  error_propagate(errp, local_err);
  }

+static void *spapr_populate_hotplug_cpu_dt(DeviceState *dev, CPUState *cs,
+   int *fdt_offset,
+   sPAPRMachineState *spapr)
+{
+PowerPCCPU *cpu = POWERPC_CPU(cs);
+DeviceClass *dc = DEVICE_GET_CLASS(cs);
+int id = ppc_get_vcpu_dt_id(cpu);
+void *fdt;
+int offset, fdt_size;
+char *nodename;
+
+fdt = create_device_tree(&fdt_size);
+nodename = g_strdup_printf("%s@%x", dc->fw_name, id);
+offset = fdt_add_subnode(fdt, 0, nodename);
+
+spapr_populate_cpu_dt(cs, fdt, offset, spapr);
+g_free(nodename);
+
+*fdt_offset = offset;
+return fdt;
+}
+
+static int spapr_core_attach(Object *obj, void *opaque)
+{
+sPAPRMachineClass *smc = SPAPR_MACHINE_GET_CLASS(qdev_get_machine());
+sPAPRMachineState *ms = SPAPR_MACHINE(qdev_get_machine());
+sPAPRCoreState *core = opaque;
+DeviceState *dev = DEVICE(obj);
+CPUState *cs = CPU(dev);
+PowerPCCPU *cpu = POWERPC_CPU(cs);
+int id = ppc_get_vcpu_dt_id(cpu);
+sPAPRDRConnector *drc =
+spapr_dr_connector_by_id(SPAPR_DR_CONNECTOR_TYPE_CPU, id);
+sPAPRDRConnectorClass *drck;
+int smt = kvmppc_smt_threads();
+Error *local_err = NULL;
+void *fdt = NULL;
+int fdt_offset = 0;
+
+/*
+ * Only main SMT thread (thread 0) will continue and signal the
+ * hotplug event to the guest. Other threads of the core will
+ * return from here.
+ */
+if ((id % smt) != 0) {
+return 0;
+}
+
+   

Re: [Qemu-devel] [PATCH v3 7/7] raspi: add raspberry pi 2 machine

[Andrew Baumann]

> From: Peter Crosthwaite [mailto:crosthwaitepe...@gmail.com]
> Sent: Monday, 11 January 2016 19:58
[...]
> > +static void write_board_setup(ARMCPU *cpu, const struct arm_boot_info
> *info)
> 
> This is almost identical to Highbank, I'm guessing you are stubbing monitor
> firmware where you get away with nopping all the SMCs? Maybe we should
> split
> Highbanks version off to common code, and parameterise the few
> differences.
> 
> write_board_setup_dummy_monitior(ARMCPU *cpu ..., uint32_t scr_flags);
> 
> or something like it. Makes sense to be in arm/boot.c .

Actually, I added this only to make Linux happy (and yes, it was derived from 
highbank). Without it, I was seeing complaints about:
Ignoring attempt to switch CPSR_A flag from non-secure world with SCR.AW bit 
clear
Ignoring attempt to switch CPSR_F flag from non-secure world with SCR.FW bit 
clear

I don't believe anything actually uses the SMC handler after boot. I think it's 
just an architectural requirement to flush the change to non-secure mode.

I would prefer not to touch highbank, because I don't know how to test it. Is 
it better to submit this patch without the board setup?

> 
> > +{
> > +static const uint32_t board_setup[] = {
> > +/* MVBAR_ADDR: secure monitor vectors */
> > +0xEAFE, /* (spin) */
> > +0xEAFE, /* (spin) */
> > +0xE1B0F00E, /* movs pc, lr ;SMC exception return */
> > +0xEAFE, /* (spin) */
> > +0xEAFE, /* (spin) */
> > +0xEAFE, /* (spin) */
> > +0xEAFE, /* (spin) */
> > +0xEAFE, /* (spin) */
> > +/* BOARDSETUP_ADDR */
> > +0xE3A00B01, /* mov r0, #0x400 ;MVBAR_ADDR */
> > +0xEE0C0F30, /* mcr p15, 0, r0, c12, c0, 1 ;set MVBAR */
> > +0xE3A00031, /* mov r0, #0x31  ;enable AW, FW, NS */
> > +0xEE010F11, /* mcr p15, 0, r0, c1, c1, 0  ;write SCR */
> 
> If combining with HB, could you do this as read-modify-write?
> 
> > +0xE1A0100E, /* mov r1, lr ;save LR across SMC 
> > */
> > +0xE1600070, /* smc #0 ;monitor call */
> > +0xE1A0F001, /* mov pc, r1 ;return */
> 
> I'm looking at the Highbank version which doesn't save lr across the SMC and
> wondering why it doesn't. Is this banked by CPU mode and do you get from
> already-in-monitor-mode? Or simply, that Highbank code may have a bug?

I think it's needed because I call the board setup blob on each core (from the 
smpboot blob), but highbank doesn't. I found that I needed to do this to avoid 
the above warnings on an SMP boot; I don't know why highbank doesn't.

[...]
> > +/* Allocate and map RAM */
> > +memory_region_allocate_system_memory(&s->ram,
> OBJECT(machine), "ram",
> > + machine->ram_size);
> > +memory_region_add_subregion_overlap(get_system_memory(), 0,
> &s->ram, 0);
> 
> I thought the SoC handled this now? Why do you need to add to
> system_memory?

If I don't map it here, how do RAM accesses from the CPUs work?

Or are you saying that I should still do this, but do it in the SoC not the 
board level?

[...]
> > +static void raspi2_machine_init(MachineClass *mc)
> > +{
> > +mc->desc = "Raspberry Pi 2";
> > +mc->init = raspi2_init;
> > +mc->block_default_type = IF_SD;
> 
> > +mc->no_parallel = 1;
> > +mc->no_floppy = 1;
> > +mc->no_cdrom = 1;
> 
> Curious, what do these do from a user-visible point of view? Maybe we
> should
> add them to more ARM boards as they certainly make sense.

I think they turn off some redundant stuff in the UI (e.g., there's no 
View->Parallel menu option). I'm guessing they also disable the -cdrom and  
-fd* options, but didn't test that.

Cheers,
Andrew

Re: [Qemu-devel] [PATCH v6 08/11] target-ppc: Introduce PowerPC specific CPU core device

[Alexey Kardashevskiy]

On 01/08/2016 05:55 PM, Bharata B Rao wrote:

CPU core device is a container of CPU thread devices.  CPU hotplug is
performed at the granularity of CPU core device. When hotplugged, CPU core
creates CPU thread devices.

Signed-off-by: Bharata B Rao 
---
  hw/ppc/Makefile.objs  |  1 +
  hw/ppc/cpu-core.c | 69 +++
  include/hw/ppc/cpu-core.h | 22 +++
  3 files changed, 92 insertions(+)
  create mode 100644 hw/ppc/cpu-core.c
  create mode 100644 include/hw/ppc/cpu-core.h

diff --git a/hw/ppc/Makefile.objs b/hw/ppc/Makefile.objs
index c1ffc77..a6b7cfb 100644
--- a/hw/ppc/Makefile.objs
+++ b/hw/ppc/Makefile.objs
@@ -21,3 +21,4 @@ obj-$(CONFIG_E500) += e500.o mpc8544ds.o e500plat.o
  obj-$(CONFIG_E500) += mpc8544_guts.o ppce500_spin.o
  # PowerPC 440 Xilinx ML507 reference board.
  obj-$(CONFIG_XILINX) += virtex_ml507.o
+obj-y += cpu-core.o
diff --git a/hw/ppc/cpu-core.c b/hw/ppc/cpu-core.c
new file mode 100644
index 000..c5c6188
--- /dev/null
+++ b/hw/ppc/cpu-core.c
@@ -0,0 +1,69 @@
+/*
+ * CPU core device, acts as container of CPU thread devices.
+ *
+ * Copyright (C) 2015 Bharata B Rao 
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ */
+#include "hw/ppc/cpu-core.h"
+#include "hw/boards.h"
+#include 
+#include "qemu/error-report.h"
+
+static int ppc_cpu_core_realize_child(Object *child, void *opaque)
+{
+Error **errp = opaque;
+
+object_property_set_bool(child, true, "realized", errp);
+if (*errp) {
+return 1;
+}
+
+return 0;
+}
+
+static void ppc_cpu_core_realize(DeviceState *dev, Error **errp)
+{
+object_child_foreach(OBJECT(dev), ppc_cpu_core_realize_child, errp);
+}
+
+static void ppc_cpu_core_class_init(ObjectClass *oc, void *data)
+{
+DeviceClass *dc = DEVICE_CLASS(oc);
+
+dc->realize = ppc_cpu_core_realize;
+}
+
+static void ppc_cpu_core_instance_init(Object *obj)
+{
+int i;
+CPUState *cpu;
+MachineState *machine = MACHINE(qdev_get_machine());
+
+/* Create as many CPU threads as specified in the topology */
+for (i = 0; i < smp_threads; i++) {
+cpu = cpu_generic_init(TYPE_POWERPC_CPU, machine->cpu_model);
+if (!cpu) {
+error_report("Unable to find CPU definition: %s\n",
+  machine->cpu_model);
+exit(EXIT_FAILURE);
+}
+object_property_add_child(obj, "thread[*]", OBJECT(cpu), &error_abort);
+object_unref(OBJECT(cpu));
+}
+}
+
+static const TypeInfo ppc_cpu_core_type_info = {
+.name = TYPE_POWERPC_CPU_CORE,
+.parent = TYPE_DEVICE,
+.class_init = ppc_cpu_core_class_init,
+.instance_init = ppc_cpu_core_instance_init,



Out of curiosity - why not .realize (and return Error instead of exit())? 
I'd think this is the recommended approach now for QOM.




--
Alexey

Re: [Qemu-devel] [PATCH v6 08/11] target-ppc: Introduce PowerPC specific CPU core device

[Alexey Kardashevskiy]

On 01/08/2016 05:55 PM, Bharata B Rao wrote:

CPU core device is a container of CPU thread devices.  CPU hotplug is
performed at the granularity of CPU core device. When hotplugged, CPU core
creates CPU thread devices.

Signed-off-by: Bharata B Rao 
---
  hw/ppc/Makefile.objs  |  1 +
  hw/ppc/cpu-core.c | 69 +++
  include/hw/ppc/cpu-core.h | 22 +++
  3 files changed, 92 insertions(+)
  create mode 100644 hw/ppc/cpu-core.c
  create mode 100644 include/hw/ppc/cpu-core.h

diff --git a/hw/ppc/Makefile.objs b/hw/ppc/Makefile.objs
index c1ffc77..a6b7cfb 100644
--- a/hw/ppc/Makefile.objs
+++ b/hw/ppc/Makefile.objs
@@ -21,3 +21,4 @@ obj-$(CONFIG_E500) += e500.o mpc8544ds.o e500plat.o
  obj-$(CONFIG_E500) += mpc8544_guts.o ppce500_spin.o
  # PowerPC 440 Xilinx ML507 reference board.
  obj-$(CONFIG_XILINX) += virtex_ml507.o
+obj-y += cpu-core.o
diff --git a/hw/ppc/cpu-core.c b/hw/ppc/cpu-core.c
new file mode 100644
index 000..c5c6188
--- /dev/null
+++ b/hw/ppc/cpu-core.c
@@ -0,0 +1,69 @@
+/*
+ * CPU core device, acts as container of CPU thread devices.
+ *
+ * Copyright (C) 2015 Bharata B Rao 



2016? :)



+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ */
+#include "hw/ppc/cpu-core.h"
+#include "hw/boards.h"
+#include 
+#include "qemu/error-report.h"
+
+static int ppc_cpu_core_realize_child(Object *child, void *opaque)
+{
+Error **errp = opaque;
+
+object_property_set_bool(child, true, "realized", errp);
+if (*errp) {
+return 1;
+}
+
+return 0;
+}
+
+static void ppc_cpu_core_realize(DeviceState *dev, Error **errp)
+{
+object_child_foreach(OBJECT(dev), ppc_cpu_core_realize_child, errp);
+}
+
+static void ppc_cpu_core_class_init(ObjectClass *oc, void *data)
+{
+DeviceClass *dc = DEVICE_CLASS(oc);
+
+dc->realize = ppc_cpu_core_realize;
+}
+
+static void ppc_cpu_core_instance_init(Object *obj)
+{
+int i;
+CPUState *cpu;
+MachineState *machine = MACHINE(qdev_get_machine());
+
+/* Create as many CPU threads as specified in the topology */
+for (i = 0; i < smp_threads; i++) {
+cpu = cpu_generic_init(TYPE_POWERPC_CPU, machine->cpu_model);
+if (!cpu) {
+error_report("Unable to find CPU definition: %s\n",
+  machine->cpu_model);
+exit(EXIT_FAILURE);
+}
+object_property_add_child(obj, "thread[*]", OBJECT(cpu), &error_abort);
+object_unref(OBJECT(cpu));
+}
+}
+
+static const TypeInfo ppc_cpu_core_type_info = {
+.name = TYPE_POWERPC_CPU_CORE,
+.parent = TYPE_DEVICE,
+.class_init = ppc_cpu_core_class_init,
+.instance_init = ppc_cpu_core_instance_init,
+};
+
+static void cpu_core_register_types(void)
+{
+type_register_static(&ppc_cpu_core_type_info);
+}
+
+type_init(cpu_core_register_types)
diff --git a/include/hw/ppc/cpu-core.h b/include/hw/ppc/cpu-core.h
new file mode 100644
index 000..91e31ef
--- /dev/null
+++ b/include/hw/ppc/cpu-core.h
@@ -0,0 +1,22 @@
+/*
+ * CPU core device.
+ *
+ * Copyright (C) 2015 Bharata B Rao 
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ */
+#ifndef HW_PPC_CPU_CORE_H
+#define HW_PPC_CPU_CORE_H
+
+#include "hw/qdev.h"
+
+#ifdef TARGET_PPC64
+#define TYPE_POWERPC_CPU_CORE "powerpc64-cpu-core"
+#elif defined(TARGET_PPCEMB)
+#define TYPE_POWERPC_CPU_CORE "embedded-powerpc-cpu-core"
+#else
+#define TYPE_POWERPC_CPU_CORE "powerpc-cpu-core"
+#endif
+
+#endif




--
Alexey

Re: [Qemu-devel] [PATCH v6 01/11] machine: Don't allow CPU toplogies with partially filled cores

[Alexey Kardashevskiy]

On 01/08/2016 05:55 PM, Bharata B Rao wrote:

Prevent guests from booting with CPU topologies that have partially
filled CPU cores or can result in partially filled CPU cores after
CPU hotplug like

-smp 15,sockets=1,cores=4,threads=4,maxcpus=16 or
-smp 15,sockets=1,cores=4,threads=4,maxcpus=17.

This is enforced by introducing MachineClass::validate_smp_config()
that gets called from generic SMP parsing code. Machine type versions
that don't want to enforce this can override this method.

TODO: Only sPAPR and PC changes are done in this patch, other archs
will be touched after there is agreement on this approach.

Signed-off-by: Bharata B Rao 
---
  hw/core/machine.c   | 20 
  hw/i386/pc_piix.c   |  7 +++
  hw/i386/pc_q35.c|  7 +++
  hw/ppc/spapr.c  |  7 +++
  include/hw/boards.h |  1 +
  vl.c|  4 
  6 files changed, 46 insertions(+)

diff --git a/hw/core/machine.c b/hw/core/machine.c
index c46ddc7..b66c101 100644
--- a/hw/core/machine.c
+++ b/hw/core/machine.c
@@ -336,6 +336,25 @@ static void machine_init_notify(Notifier *notifier, void 
*data)
  foreach_dynamic_sysbus_device(error_on_sysbus_device, NULL);
  }

+static int validate_smp_config_generic(int smp_cpus, int max_cpus,
+   int smp_threads)
+{
+if (smp_cpus % smp_threads) {
+error_report("cpu topology: "
+ "smp_cpus (%u) should be multiple of threads (%u) ",
+ smp_cpus, smp_threads);
+return 1;
+}
+
+if (max_cpus % smp_threads) {
+error_report("cpu topology: "
+ "max_cpus (%u) should be multiple of threads (%u) ",
+ max_cpus, smp_threads);
+return 1;
+}
+return 0;
+}



If you decide to repost - here is incorrect indent.



+
  static void machine_class_init(ObjectClass *oc, void *data)
  {
  MachineClass *mc = MACHINE_CLASS(oc);
@@ -343,6 +362,7 @@ static void machine_class_init(ObjectClass *oc, void *data)
  /* Default 128 MB as guest ram size */
  mc->default_ram_size = 128 * M_BYTE;
  mc->rom_file_has_mr = true;
+mc->validate_smp_config = validate_smp_config_generic;
  }

  static void machine_class_base_init(ObjectClass *oc, void *data)
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 438cdae..dd4bba1 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -397,6 +397,12 @@ static void pc_xen_hvm_init(MachineState *machine)
  }
  #endif

+static int pc_validate_smp_config_default(int smp_cpus, int max_cpus,
+  int smp_threads)
+{
+return 0;
+}
+
  #define DEFINE_I440FX_MACHINE(suffix, name, compatfn, optionfn) \
  static void pc_init_##suffix(MachineState *machine) \
  { \
@@ -434,6 +440,7 @@ static void pc_i440fx_2_5_machine_options(MachineClass *m)
  pc_i440fx_2_6_machine_options(m);
  m->alias = NULL;
  m->is_default = 0;
+m->validate_smp_config = pc_validate_smp_config_default;
  SET_MACHINE_COMPAT(m, PC_COMPAT_2_5);
  }

diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index 412b3cd..80ce9e8 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -325,6 +325,12 @@ static void pc_compat_1_4(MachineState *machine)
  pc_compat_1_5(machine);
  }

+static int pc_q35_validate_smp_config_default(int smp_cpus, int max_cpus,
+  int smp_threads)
+{
+return 0;
+}
+
  #define DEFINE_Q35_MACHINE(suffix, name, compatfn, optionfn) \
  static void pc_init_##suffix(MachineState *machine) \
  { \
@@ -362,6 +368,7 @@ static void pc_q35_2_5_machine_options(MachineClass *m)
  {
  pc_q35_2_6_machine_options(m);
  m->alias = NULL;
+m->validate_smp_config = pc_q35_validate_smp_config_default;
  SET_MACHINE_COMPAT(m, PC_COMPAT_2_5);
  }

diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index 414e0f9b..a330169 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -2320,6 +2320,12 @@ static const TypeInfo spapr_machine_info = {
  },
  };

+static int spapr_validate_smp_config_default(int smp_cpus, int max_cpus,
+  int smp_threads)



and here.



+{
+return 0;
+}
+
  #define DEFINE_SPAPR_MACHINE(suffix, verstr, latest) \
  static void spapr_machine_##suffix##_class_init(ObjectClass *oc, \
  void *data)  \
@@ -2379,6 +2385,7 @@ static void spapr_machine_2_5_class_options(MachineClass 
*mc)
  spapr_machine_2_6_class_options(mc);
  smc->use_ohci_by_default = true;
  SET_MACHINE_COMPAT(mc, SPAPR_COMPAT_2_5);
+mc->validate_smp_config = spapr_validate_smp_config_default;
  }

  DEFINE_SPAPR_MACHINE(2_5, "2.5", false);
diff --git a/include/hw/boards.h b/include/hw/boards.h
index 0f30959..39091bf 100644
--- a/include/hw/boards.h
+++ b/include/hw/boards.h
@@ -99,6 +99,7 @@ struct Machin

[Qemu-devel] [Bug 1508405] Re: qemu 2.4.0 with --enable-kvm hangs, takes 100% CPU

[pranith]

*** This bug is a duplicate of bug 1505062 ***
https://bugs.launchpad.net/bugs/1505062

** This bug has been marked a duplicate of bug 1505062
   Regression: QEMU 2.4 on Linux 4.2 fails to init display with SMM enabled

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

Title:
  qemu 2.4.0 with --enable-kvm hangs, takes 100% CPU

Status in QEMU:
  New

Bug description:
  When starting qemu-system-x86_64 from version 2.4.0 with --enable-kvm,
  it hangs and takes 100% CPU. The graphical display (SeaBIOS output) is
  not initialized.

  There have been multiple reports of this issue in the following thread:
  https://bbs.archlinux.org/viewtopic.php?pid=1572405

  There is no need to load a certain image, it already hangs with the following 
command:
  qemu-system-x86_64 --enable-kvm

  There are three workarounds:
  - Downgrading the kernel form 4.2.2 to 4.1.6 (according to the forum thread, 
have not tested this myself)
  - Downgrading qemu to 2.3 (tested personally, works)
  - passing -machine pc-i440fx-2.3 to qemu 2.4 (have not tested this myself, I 
will try that shortly)

  modules kvm and kvm_intel are loaded and rmmod && modprobing them does
  not change the situation

  I have an nvidia card and switching from official binary drivers to
  nouveau and back does not change the situation.

  
  qemu is installed from Arch package. From the PKGBUILD you can see that is is 
built with the following configuration:
  
  export ARFLAGS="rv"
export CFLAGS+=' -fPIC'
./configure --prefix=/usr --sysconfdir=/etc --audio-drv-list='pa alsa sdl' \
--python=/usr/bin/python2 --smbd=/usr/bin/smbd \
--enable-docs --libexecdir=/usr/lib/qemu \
--disable-gtk --enable-linux-aio --enable-seccomp \
--enable-spice --localstatedir=/var \
--enable-tpm \
--enable-modules --enable-{rbd,glusterfs,libiscsi,curl}
make V=99
  

  cpuinfo on my machine (for the first core only):

  
  processor   : 0
  vendor_id   : GenuineIntel
  cpu family  : 6
  model   : 30
  model name  : Intel(R) Core(TM) i7 CPU   Q 820  @ 1.73GHz
  stepping: 5
  microcode   : 0x7
  cpu MHz : 1333.000
  cache size  : 8192 KB
  physical id : 0
  siblings: 8
  core id : 0
  cpu cores   : 4
  apicid  : 0
  initial apicid  : 0
  fpu : yes
  fpu_exception   : yes
  cpuid level : 11
  wp  : yes
  flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca 
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx 
rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology 
nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 
xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida dtherm tpr_shadow vnmi flexpriority 
ept vpid
  bugs:
  bogomips: 3459.21
  clflush size: 64
  cache_alignment : 64
  address sizes   : 36 bits physical, 48 bits virtual
  

  Is there more information I can provide you with to help debug this
  problem?

  Thanks,

  cptG

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

Re: [Qemu-devel] [PATCH v3 6/7] bcm2836: add bcm2836 soc device

[Peter Crosthwaite]

On Tue, Jan 12, 2016 at 2:56 PM, Andrew Baumann
 wrote:
> Hi Peter,
>
> Thanks again for the reviews.
>
>> From: Peter Crosthwaite [mailto:crosthwaitepe...@gmail.com]
>> Sent: Monday, 11 January 2016 19:57
>> On Thu, Dec 31, 2015 at 04:31:33PM -0800, Andrew Baumann wrote:
>> > +/* TODO: probably shouldn't be using smp_cpus here */
>>
>> I agree. I have started ignoring smp_cpus completely for new ARM SoCs,
>> as if you change the number of CPUs for a SoC, it is not that SoC
>> anymore. The virt platform is suitable for CPU scalability, whereas
>> with ARM SoCs, cpu # variation is invalid.
>>
>> > +assert(smp_cpus <= BCM2836_NCPUS);
>> > +for (n = 0; n < smp_cpus; n++) {
>>
>> So can we just use BCM2836_NCPUS here as the loop bound? Any
>> conditionals out there check the existance of CPUs can be removed or
>> promoted to assert() as a BCM2836 must always have 4 CPUs.
>
> I'd love to do that, but there's at least one good reason to respect the -smp 
> parameter and not start all the CPUs: with full-system emulation, qemu is 
> noticeably faster emulating a single-core target than multi-core. E.g., Linux 
> boots fine with -smp 1 (it fails to start the other CPUs but proceeds with 
> just one), and many users will be better off running it this way, so I 
> definitely don't want to break that.
>

What are the secondary CPUs doing in this case? In most systems they
end up penning on a WFI/WFE. Is Linux actually trying to do the SMP
bringup - are you are getting a secondary entry point?

If not and it is just a busy wait killing perf, start-powered-off
property might help. Is the firmware responsible for secondary-penning
an actual busy-wait or does it involve power-control periphs etc?

Regards,
Peter

> I tried always initing all 4 CPUs in bcm2836_init, and only starting a 
> configurable number (based on a property) in realize. However, arm 
> cpu_exec_init already adds the cpu to the global list of all CPUs, and if you 
> try to start the system in this state it quickly segfaults on uninitialized 
> state in the CPU, so it seems we shouldn't even init CPUs that won't later be 
> started. However, I can't refer to properties in the _init method, which is 
> why I'm stuck using the smp_cpus global.
>
> If you have a better suggestion, I'm all ears :) Would it make sense to defer 
> calling init() until the realize method, when we can access a property?
>
> Cheers,
> Andrew

[Qemu-devel] [Bug 697197] Re: Empty password allows access to VNC in libvirt

[pranith]

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

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

Title:
  Empty password allows access to VNC in libvirt

Status in libvirt:
  Unknown
Status in QEMU:
  Fix Released
Status in qemu-kvm:
  Unknown
Status in libvirt package in Ubuntu:
  Invalid
Status in qemu-kvm package in Ubuntu:
  Fix Released
Status in libvirt source package in Lucid:
  Invalid
Status in qemu-kvm source package in Lucid:
  Fix Released
Status in libvirt source package in Maverick:
  Invalid
Status in qemu-kvm source package in Maverick:
  Fix Released
Status in libvirt source package in Natty:
  Invalid
Status in qemu-kvm source package in Natty:
  Fix Released
Status in libvirt source package in Karmic:
  Invalid
Status in qemu-kvm source package in Karmic:
  Fix Released
Status in qemu-kvm package in Debian:
  Fix Released

Bug description:
  The help in the /etc/libvirt/qemu.conf states

  "To allow access without passwords, leave this commented out. An empty
  string will still enable passwords, but be rejected by QEMU
  effectively preventing any use of VNC."

  yet setting:

  vnc_password=""

  allows access to the vnc console without any password prompt just as
  if it is hashed out completely.

  ProblemType: Bug
  DistroRelease: Ubuntu 10.10
  Package: libvirt-bin 0.8.3-1ubuntu14
  ProcVersionSignature: Ubuntu 2.6.35-24.42-server 2.6.35.8
  Uname: Linux 2.6.35-24-server x86_64
  Architecture: amd64
  Date: Tue Jan  4 12:18:35 2011
  InstallationMedia: Ubuntu-Server 10.04.1 LTS "Lucid Lynx" - Release amd64 
(20100816.2)
  ProcEnviron:
   LANG=en_GB.UTF-8
   SHELL=/bin/bash
  SourcePackage: libvirt

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

Re: [Qemu-devel] [PATCH v3 6/7] bcm2836: add bcm2836 soc device

[Andrew Baumann]

Hi Peter,

Thanks again for the reviews.

> From: Peter Crosthwaite [mailto:crosthwaitepe...@gmail.com]
> Sent: Monday, 11 January 2016 19:57
> On Thu, Dec 31, 2015 at 04:31:33PM -0800, Andrew Baumann wrote:
> > +/* TODO: probably shouldn't be using smp_cpus here */
> 
> I agree. I have started ignoring smp_cpus completely for new ARM SoCs,
> as if you change the number of CPUs for a SoC, it is not that SoC
> anymore. The virt platform is suitable for CPU scalability, whereas
> with ARM SoCs, cpu # variation is invalid.
> 
> > +assert(smp_cpus <= BCM2836_NCPUS);
> > +for (n = 0; n < smp_cpus; n++) {
> 
> So can we just use BCM2836_NCPUS here as the loop bound? Any
> conditionals out there check the existance of CPUs can be removed or
> promoted to assert() as a BCM2836 must always have 4 CPUs.

I'd love to do that, but there's at least one good reason to respect the -smp 
parameter and not start all the CPUs: with full-system emulation, qemu is 
noticeably faster emulating a single-core target than multi-core. E.g., Linux 
boots fine with -smp 1 (it fails to start the other CPUs but proceeds with just 
one), and many users will be better off running it this way, so I definitely 
don't want to break that.

I tried always initing all 4 CPUs in bcm2836_init, and only starting a 
configurable number (based on a property) in realize. However, arm 
cpu_exec_init already adds the cpu to the global list of all CPUs, and if you 
try to start the system in this state it quickly segfaults on uninitialized 
state in the CPU, so it seems we shouldn't even init CPUs that won't later be 
started. However, I can't refer to properties in the _init method, which is why 
I'm stuck using the smp_cpus global.

If you have a better suggestion, I'm all ears :) Would it make sense to defer 
calling init() until the realize method, when we can access a property?

Cheers,
Andrew

[Qemu-devel] [PATCH v5 1/1] xlnx-zynqmp: Add support for high DDR memory regions

[Alistair Francis]

The Xilinx ZynqMP SoC and EP108 board supports three memory regions:
 - A 2GB region starting at 0
 - A 32GB region starting at 32GB
 - A 256GB region starting at 768GB

This patch adds support for the first two memory regions, which is
automatically created based on the size specified by the QEMU memory
command line argument.

On hardware the physical memory region is one continuous region, it is then
mapped into the three different regions by the DDRC. As we don't model the
DDRC this is done at startup by QEMU. The board creates the memory region and
then passes that memory region to the SoC. The SoC then maps the memory
regions.

Signed-off-by: Alistair Francis 
Reviewed-by: Peter Crosthwaite 
---
V5:
 - Fix compilation on 32-bit host issue
V4:
 - Small fixes
 - Localisation of ram_size
V3:
 - Assert on the RAM sizes
 - Remove ram_size property
 - General fixes
V2:
 - Create one continuous memory region and pass it to the SoC

Also, the Xilinx ZynqMP TRM is avaliable at:
http://www.xilinx.com/products/silicon-devices/soc/zynq-ultrascale-mpsoc.html?resultsTablePreSelect=documenttype:User%20Guides#documentation

 hw/arm/xlnx-ep108.c  | 40 +---
 hw/arm/xlnx-zynqmp.c | 37 +
 include/hw/arm/xlnx-zynqmp.h | 12 
 3 files changed, 70 insertions(+), 19 deletions(-)

diff --git a/hw/arm/xlnx-ep108.c b/hw/arm/xlnx-ep108.c
index 85b978f..93c1fb1 100644
--- a/hw/arm/xlnx-ep108.c
+++ b/hw/arm/xlnx-ep108.c
@@ -25,42 +25,44 @@ typedef struct XlnxEP108 {
 MemoryRegion ddr_ram;
 } XlnxEP108;
 
-/* Max 2GB RAM */
-#define EP108_MAX_RAM_SIZE 0x8000ull
-
 static struct arm_boot_info xlnx_ep108_binfo;
 
 static void xlnx_ep108_init(MachineState *machine)
 {
 XlnxEP108 *s = g_new0(XlnxEP108, 1);
 Error *err = NULL;
+uint64_t ram_size = machine->ram_size;
+
+/* Create the memory region to pass to the SoC */
+if (ram_size > XLNX_ZYNQMP_MAX_RAM_SIZE) {
+error_report("ERROR: RAM size 0x%" PRIx64 " above max supported of "
+ "0x%llx", ram_size,
+ XLNX_ZYNQMP_MAX_RAM_SIZE);
+exit(1);
+}
+
+if (ram_size < 0x0800) {
+qemu_log("WARNING: RAM size 0x%" PRIx64 " is small for EP108",
+ ram_size);
+}
+
+memory_region_allocate_system_memory(&s->ddr_ram, NULL, "ddr-ram",
+ ram_size);
 
 object_initialize(&s->soc, sizeof(s->soc), TYPE_XLNX_ZYNQMP);
 object_property_add_child(OBJECT(machine), "soc", OBJECT(&s->soc),
   &error_abort);
 
+object_property_set_link(OBJECT(&s->soc), OBJECT(&s->ddr_ram),
+ "ddr-ram", &error_abort);
+
 object_property_set_bool(OBJECT(&s->soc), true, "realized", &err);
 if (err) {
 error_report("%s", error_get_pretty(err));
 exit(1);
 }
 
-if (machine->ram_size > EP108_MAX_RAM_SIZE) {
-error_report("WARNING: RAM size " RAM_ADDR_FMT " above max supported, "
- "reduced to %llx", machine->ram_size, EP108_MAX_RAM_SIZE);
-machine->ram_size = EP108_MAX_RAM_SIZE;
-}
-
-if (machine->ram_size < 0x0800) {
-qemu_log("WARNING: RAM size " RAM_ADDR_FMT " is small for EP108",
- machine->ram_size);
-}
-
-memory_region_allocate_system_memory(&s->ddr_ram, NULL, "ddr-ram",
- machine->ram_size);
-memory_region_add_subregion(get_system_memory(), 0, &s->ddr_ram);
-
-xlnx_ep108_binfo.ram_size = machine->ram_size;
+xlnx_ep108_binfo.ram_size = ram_size;
 xlnx_ep108_binfo.kernel_filename = machine->kernel_filename;
 xlnx_ep108_binfo.kernel_cmdline = machine->kernel_cmdline;
 xlnx_ep108_binfo.initrd_filename = machine->initrd_filename;
diff --git a/hw/arm/xlnx-zynqmp.c b/hw/arm/xlnx-zynqmp.c
index 87553bb..ccbdda5 100644
--- a/hw/arm/xlnx-zynqmp.c
+++ b/hw/arm/xlnx-zynqmp.c
@@ -90,6 +90,11 @@ static void xlnx_zynqmp_init(Object *obj)
   &error_abort);
 }
 
+object_property_add_link(obj, "ddr-ram", TYPE_MEMORY_REGION,
+ (Object **)&s->ddr_ram,
+ qdev_prop_allow_set_link_before_realize,
+ OBJ_PROP_LINK_UNREF_ON_RELEASE, &error_abort);
+
 object_initialize(&s->gic, sizeof(s->gic), TYPE_ARM_GIC);
 qdev_set_parent_bus(DEVICE(&s->gic), sysbus_get_default());
 
@@ -119,10 +124,42 @@ static void xlnx_zynqmp_realize(DeviceState *dev, Error 
**errp)
 XlnxZynqMPState *s = XLNX_ZYNQMP(dev);
 MemoryRegion *system_memory = get_system_memory();
 uint8_t i;
+uint64_t ram_size;
 const char *boot_cpu = s->boot_cpu ? s->boot_cpu : "apu-cpu[0]";
+ram_addr_t ddr_low_size, ddr_high_size;
 qemu_irq gic_spi[GIC_NUM_SPI_INTR];
 Error *err = NULL;
 
+ram_size = memory_region_size(s->ddr_ram);
+
+/* Crea

[Qemu-devel] [Bug 1406016] Re: qemu-system-arm hangs at start on OS X

[pranith]

** Changed in: qemu
   Status: New => Invalid

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

Title:
  qemu-system-arm hangs at start on OS X

Status in QEMU:
  Invalid

Bug description:
  Both from release 2.1.2 and built from a recent source, qemu-system-
  arm seems to hang immediately after starting up, never getting to the
  point of actually booting.

  I've tried qemu-system-mipsel with another image and it worked fine,
  so this seems to be specific to the ARM runtime. I've tried two
  different ARM kernels, and I also ran into this with QEMU 2.1.2
  release, installed from a bottle using homebrew.

  Host: Mac OS X 10.9.5 (Darwin Kernel Version 13.4.0)
  QEMU version: built from HEAD@ab0302ee76
  Build command: ./configure --enable-cocoa 
--target-list=arm-softmmu,mipsel-softmmu && make
  Run command:

  qemu-system-arm -M vexpress-a9 -cpu cortex-a9 -m 256 -sd disk.img -net
  nic,macaddr=52:54:00:fa:ce:13 -kernel vmlinuz-3.2.0-4-vexpress -initrd
  initrd.gz -append "root=/dev/ram" -display vnc=localhost:17 -net
  user,hostfwd=tcp::5022-:22 -append "console=ttyS0"

  I also tried this, with a different kernel & root:

  qemu-system-arm -kernel zImage -cpu arm1176 -m 256 -M versatilepb -no-
  reboot -serial stdio -hda rootfs-chromium.ext2 -append "root=/dev/sda"

  Thread dump:

  (lldb) thread list
  Process 34364 stopped
  * thread #1: tid = 0x135966, 0x7fff89f4a746 
libsystem_kernel.dylib`__psynch_mutexwait + 10, queue = 
'com.apple.main-thread', stop reason = signal SIGSTOP
    thread #2: tid = 0x13598b, 0x7fff89f4ae6a 
libsystem_kernel.dylib`__workq_kernreturn + 10
    thread #3: tid = 0x13598c, 0x7fff89f4b662 
libsystem_kernel.dylib`kevent64 + 10, queue = 'com.apple.libdispatch-manager'
    thread #7: tid = 0x1359b2, 0x7fff89f4acc2 
libsystem_kernel.dylib`__sigwait + 10
    thread #9: tid = 0x1359c1, 0x0001091bc5d9
    thread #11: tid = 0x1359cc, 0x7fff89f4a716 
libsystem_kernel.dylib`__psynch_cvwait + 10
    thread #12: tid = 0x1359da, 0x7fff89f46a1a 
libsystem_kernel.dylib`mach_msg_trap + 10, name = 
'com.apple.audio.IOThread.client'

  ---
  * thread #1: tid = 0x135966, 0x7fff89f4a746 
libsystem_kernel.dylib`__psynch_mutexwait + 10, queue = 
'com.apple.main-thread', stop reason = signal SIGSTOP
    * frame #0: 0x7fff89f4a746 libsystem_kernel.dylib`__psynch_mutexwait + 
10
  frame #1: 0x7fff8e05f779 libsystem_pthread.dylib`_pthread_mutex_lock 
+ 372
  frame #2: 0x00010033e8e9 
qemu-system-arm`qemu_mutex_lock(mutex=) + 25 at 
qemu-thread-posix.c:76
  frame #3: 0x00010002d742 qemu-system-arm`qemu_mutex_lock_iothread + 
98 at cpus.c:1137
  frame #4: 0x0001002c84b5 qemu-system-arm`main_loop_wait [inlined] 
os_host_main_loop_wait(timeout=) + 191 at main-loop.c:242
  frame #5: 0x0001002c83f6 
qemu-system-arm`main_loop_wait(nonblocking=) + 278 at 
main-loop.c:494
  frame #6: 0x00010014961a qemu-system-arm`qemu_main [inlined] 
main_loop + 73 at vl.c:1789
  frame #7: 0x0001001495d1 
qemu-system-arm`qemu_main(argc=, argv=, 
envp=) + 17057 at vl.c:4353
  frame #8: 0x00010029b45e qemu-system-arm`-[QemuCocoaAppController 
startEmulationWithArgc:argv:](self=, _cmd=, 
argc=, argv=) + 30 at cocoa.m:897

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

[Qemu-devel] [Bug 1410288] Re: qemu-img conversion to qcow2 hangs with blank image less than 100kiB

[pranith]

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

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

Title:
  qemu-img conversion to qcow2 hangs with blank image less than 100kiB

Status in QEMU:
  Fix Released
Status in qemu package in Ubuntu:
  Triaged

Bug description:
  If you try to convert a blank image to qcow2 that is less than 100kiB
  in size then qemu-img hangs trying to seek to the end of the file.

  $ truncate --size 102399 /tmp/temp
  $ qemu-img convert -p -O qcow2 /tmp/temp /tmp/temp2.qcow2

  I'm finding this on all versions of qemu-img v2.

  strace shows a seek loop.

  ioctl(6, FS_IOC_FIEMAP, 0xb5e68dc4) = 0
  _llseek(6, 0, [10], SEEK_END)   = 0
  ioctl(6, FS_IOC_FIEMAP, 0xb5e68dc4) = 0
  _llseek(6, 0, [10], SEEK_END)   = 0
  ioctl(6, FS_IOC_FIEMAP, 0xb5e68dc4) = 0
  _llseek(6, 0, [10], SEEK_END)   = 0
  ioctl(6, FS_IOC_FIEMAP, 0xb5e68dc4) = 0
  _llseek(6, 0, [10], SEEK_END)   = 0
  ioctl(6, FS_IOC_FIEMAP, 0xb5e68dc4) = 0
  _llseek(6, 0, [10], SEEK_END)   = 0
  ioctl(6, FS_IOC_FIEMAP, 0xb5e68dc4) = 0
  _llseek(6, 0, [10], SEEK_END)   = 0
  ioctl(6, FS_IOC_FIEMAP, 0xb5e68dc4) = 0
  _llseek(6, 0, [10], SEEK_END)   = 0
  ioctl(6, FS_IOC_FIEMAP, 0xb5e68dc4) = 0
  _llseek(6, 0, [10], SEEK_END)   = 0

  ProblemType: Bug
  DistroRelease: Ubuntu 14.04
  Package: qemu-utils 2.0.0+dfsg-2ubuntu1.10
  ProcVersionSignature: User Name 3.13.0-43.72-generic 3.13.11.11
  Uname: Linux 3.13.0-43-generic i686
  ApportVersion: 2.14.1-0ubuntu3.6
  Architecture: i386
  Date: Tue Jan 13 14:30:39 2015
  SourcePackage: qemu
  UpgradeStatus: No upgrade log present (probably fresh install)

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

[Qemu-devel] [Bug 1414222] Re: qemu-system-i386: -vnc localhost:0, to=99, id=default: Invalid parameter 'to'

[pranith]

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

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

Title:
  qemu-system-i386: -vnc localhost:0,to=99,id=default: Invalid parameter
  'to'

Status in QEMU:
  Fix Released

Bug description:
  git bisect points to:

  4db14629c38611061fc19ec6927405923de84f08 is the first bad commit
  commit 4db14629c38611061fc19ec6927405923de84f08
  Author: Gerd Hoffmann 
  Date:   Tue Sep 16 12:33:03 2014 +0200

  vnc: switch to QemuOpts, allow multiple servers

  This patch switches vnc over to QemuOpts, and it (more or less
  as side effect) allows multiple vnc server instances.

  Signed-off-by: Gerd Hoffmann 

  :04 04 70020c79b463eaff4b91c8c7f985240d1d1914f0 
354a3a125e7b82a1699ce4e0cfc5055662bd3466 M  include
  :100644 100644 0b4f131936052ed6062ba4b2b9434da0c2cce959 
963305c26917a930f37d916df66b319d6558d281 M  qmp.c
  :04 04 e7933d52124ae48100893eed8e14cbe46f80b936 
30fa5966f5c8362d6db6730a7091bbde7780d4d8 M  ui
  :100644 100644 9fb32c13df1c14daf8304184c6503d16bff7afce 
983259bc9f7064b446da358a316a31a31731a223 M  vl.c

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

[Qemu-devel] [Bug 1416988] Re: Wrong signal handling in qemu-aarch64.

[pranith]

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

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

Title:
  Wrong signal handling in qemu-aarch64.

Status in QEMU:
  Fix Released

Bug description:
  Running GCC 5.0 testsuite under qemu-aarch64, I noticed that tests
  connected with stack unwinding fail with:

  qemu: uncaught target signal 11 (Segmentation fault) - core dumped

  or run into infinite loop.

  Here is one example:

  $ /home/max/build/gcc-aarch64/gcc/xgcc -B/home/max/build/gcc-
  aarch64/gcc/
  /home/max/src/toolchain/gcc/gcc/testsuite/gcc.dg/cleanup-11.c
  -fexceptions -fnon-call-exceptions -O2 -lm -o ./cleanup-11.exe

  $ qemu-aarch64 -L /home/max/install/aarch64/aarch64-linux/sys-root/ -R 0 
-/cleanup-11.exe
  qemu: uncaught target signal 11 (Segmentation fault) - core dumped.

  Actually, this caused by ABI incompatibility between Linux Kernel
  (trunk) and qemu-aarch64. In fact, size of siginfo structure in Linux
  and target_siginfo structure in qemu-aarch64 differ:

  sizeof (struct target_siginfo) = 136  // QEMU
  sizeof (struct siginfo) = 128   // Linux Kernel

  
  This caused by wrong TARGET_SI_PAD_SIZE defined in  linux-user/syscall_defs.h:

  #define TARGET_SI_PAD_SIZE  ((TARGET_SI_MAX_SIZE/sizeof(int)) - 3)

  In Kernel respective value is:

  #define SI_PAD_SIZE ((SI_MAX_SIZE - __ARCH_SI_PREAMBLE_SIZE) / 
sizeof(int))
  .
  #define __ARCH_SI_PREAMBLE_SIZE (4 * sizeof(int))  // for Aarch64

  Trivial fix, changing TARGET_SI_PAD_SIZE to right value, is attached.

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

[Qemu-devel] [Bug 1412098] Re: qemu crashes when ctrl-alt-u is pressed

[pranith]

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

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

Title:
  qemu crashes when ctrl-alt-u is pressed

Status in QEMU:
  Fix Released

Bug description:
  Qemu version: 2.2.0 release, compiled from source
  Host OS: Windows 7 Ultimate x64
  Guest OS: not applicable, crash occurs even without OS and occurs with all OSs
  Executable: qemu-system-i386.exe or qemu-system-i386w.exe

  To reproduce:
  Start qemu-system-i386 or qemu-system-i386w without any options. Press 
CTRL-ALT-U, which is supposed to rescale the window. Instead, qemu just crashes.

  Compilation:
  Qemu 2.2.0 release compiled from sources under MinGW on the host.
  Configure options used:
  '../qemu-2.2.0/configure' '--python=C:/Python27/python' 
'--prefix=/mingw/build/qemu-2.2.0-bin' '--target-list=i386-softmmu'

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

[Qemu-devel] [Bug 1478360] Re: Cant compile on ubuntu 14.04 x64

[pranith]

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

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

Title:
  Cant compile on ubuntu 14.04 x64

Status in QEMU:
  Fix Released

Bug description:
  ./configure --static
  Install prefix/usr/local
  BIOS directory/usr/local/share/qemu
  binary directory  /usr/local/bin
  library directory /usr/local/lib
  module directory  /usr/local/lib/qemu
  libexec directory /usr/local/libexec
  include directory /usr/local/include
  config directory  /usr/local/etc
  local state directory   /usr/local/var
  Manual directory  /usr/local/share/man
  ELF interp prefix /usr/gnemul/qemu-%M
  Source path   /home/slobodan/qemu
  C compilercc
  Host C compiler   cc
  C++ compiler  c++
  Objective-C compiler cc
  ARFLAGS   rv
  CFLAGS-O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -pthread 
-I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include   -g 
  QEMU_CFLAGS   -I/usr/include/pixman-1-Werror -m64 -D_GNU_SOURCE 
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes 
-Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes 
-fno-strict-aliasing -fno-common  -Wendif-labels -Wmissing-include-dirs 
-Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self 
-Wignored-qualifiers -Wold-style-declaration -Wold-style-definition 
-Wtype-limits -fstack-protector-all -I/usr/include/p11-kit-1 
-I/usr/include/libpng12  
  LDFLAGS   -Wl,--warn-common -m64 -static -g 
  make  make
  install   install
  pythonpython -B
  smbd  /usr/sbin/smbd
  module supportno
  host CPU  x86_64
  host big endian   no
  target listaarch64-softmmu alpha-softmmu arm-softmmu cris-softmmu 
i386-softmmu lm32-softmmu m68k-softmmu microblaze-softmmu microblazeel-softmmu 
mips-softmmu mips64-softmmu mips64el-softmmu mipsel-softmmu moxie-softmmu 
or32-softmmu ppc-softmmu ppc64-softmmu ppcemb-softmmu s390x-softmmu sh4-softmmu 
sh4eb-softmmu sparc-softmmu sparc64-softmmu tricore-softmmu unicore32-softmmu 
x86_64-softmmu xtensa-softmmu xtensaeb-softmmu aarch64-linux-user 
alpha-linux-user arm-linux-user armeb-linux-user cris-linux-user 
i386-linux-user m68k-linux-user microblaze-linux-user microblazeel-linux-user 
mips-linux-user mips64-linux-user mips64el-linux-user mipsel-linux-user 
mipsn32-linux-user mipsn32el-linux-user or32-linux-user ppc-linux-user 
ppc64-linux-user ppc64abi32-linux-user ppc64le-linux-user s390x-linux-user 
sh4-linux-user sh4eb-linux-user sparc-linux-user sparc32plus-linux-user 
sparc64-linux-user unicore32-linux-user x86_64-linux-user
  tcg debug enabled no
  gprof enabled no
  sparse enabledno
  strip binariesyes
  profiler  no
  static build  yes
  pixmansystem
  SDL support   no
  GTK support   yes
  GNUTLS supportyes
  GNUTLS hash   yes
  GNUTLS gcrypt yes
  GNUTLS nettle no ()
  VTE support   no
  curses supportno
  curl support  no
  mingw32 support   no
  Audio drivers oss
  Block whitelist (rw) 
  Block whitelist (ro) 
  VirtFS supportno
  VNC support   yes
  VNC TLS support   no
  VNC SASL support  no
  VNC JPEG support  yes
  VNC PNG support   yes
  xen support   no
  brlapi supportno
  bluez  supportyes
  Documentation no
  GUEST_BASEyes
  PIE   no
  vde support   no
  netmap supportno
  Linux AIO support no
  ATTR/XATTR support yes
  Install blobs yes
  KVM support   yes
  RDMA support  no
  TCG interpreter   no
  fdt support   yes
  preadv supportyes
  fdatasync yes
  madvise   yes
  posix_madvise yes
  sigev_thread_id   yes
  uuid support  yes
  libcap-ng support no
  vhost-net support yes
  vhost-scsi support yes
  Trace backendsnop
  spice support no
  rbd support   no
  xfsctl supportno
  nss used  no
  libusbno
  usb net redir no
  OpenGL supportno
  libiscsi support  no
  libnfs supportno
  build guest agent yes
  QGA VSS support   no
  QGA w32 disk info no
  seccomp support   no
  coroutine backend ucontext
  coroutine poolyes
  GlusterFS support no
  Archipelago support no
  gcov  gcov
  gcov enabled  no
  TPM support   yes
  libssh2 support   no
  TPM passthrough   yes
  QOM debugging yes
  vhdx  yes
  lzo support   no
  snappy supportno
  bzip2 support no
  NUMA host support no
  tcmalloc support  no

  :~/qemu$ make
GEN   config-host.h
GEN   qemu-options.def
GEN   qmp-commands.h
GEN   qapi-types.h
GEN   qapi-visit.h
GEN   qapi-event.h
GEN   trace/generated-events.h
GEN   trace/generated-tracers.h
GEN   trace/generated-tcg-tracers.h
GEN   trace/generated-helpers-wrappers.h
GEN   tr

[Qemu-devel] [Bug 1481990] Re: 2.3.0 build fails on Ubuntu 12.04

[pranith]

This does not happend anymore with the upstream git. Closing. Please
reopen if you still see this.

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

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

Title:
  2.3.0 build fails on Ubuntu 12.04

Status in QEMU:
  Fix Released

Bug description:
  Build of 2.3.0 fails on Ubuntu 12.04:

  sudo make clean
  sudo ./configure --prefix=/usr/local 
--target-list=i386-softmmu,arm-softmmu,x86_64-softmmu
  sudo make

GEN   config-host.h
GEN   qemu-options.def
GEN   qmp-commands.h
GEN   qapi-types.h
GEN   qapi-visit.h
GEN   qapi-event.h
GEN   trace/generated-events.h
GEN   trace/generated-tracers.h
 ...

   CCmigration/qemu-file-stdio.o
CCmigration/xbzrle.o
CCmigration/rdma.o
  migration/rdma.c: In function ‘qemu_rdma_dump_id’:
  migration/rdma.c:706:21: error: ‘struct ibv_port_attr’ has no member named 
‘link_layer’
  migration/rdma.c:707:22: error: ‘struct ibv_port_attr’ has no member named 
‘link_layer’
  migration/rdma.c:707:37: error: ‘IBV_LINK_LAYER_INFINIBAND’ undeclared (first 
use in this function)
  migration/rdma.c:707:37: note: each undeclared identifier is reported only 
once for each function it appears in
  migration/rdma.c:708:24: error: ‘struct ibv_port_attr’ has no member named 
‘link_layer’
  migration/rdma.c:708:39: error: ‘IBV_LINK_LAYER_ETHERNET’ undeclared (first 
use in this function)
  migration/rdma.c: In function ‘qemu_rdma_broken_ipv6_kernel’:
  migration/rdma.c:800:26: error: ‘struct ibv_port_attr’ has no member named 
‘link_layer’
  migration/rdma.c:800:41: error: ‘IBV_LINK_LAYER_INFINIBAND’ undeclared (first 
use in this function)
  migration/rdma.c:802:33: error: ‘struct ibv_port_attr’ has no member named 
‘link_layer’
  migration/rdma.c:802:48: error: ‘IBV_LINK_LAYER_ETHERNET’ undeclared (first 
use in this function)
  migration/rdma.c:841:18: error: ‘struct ibv_port_attr’ has no member named 
‘link_layer’
  make: *** [migration/rdma.o] Error 1

  Build succeeds with

  sudo ./configure --prefix=/usr/local --target-list=i386-softmmu,arm-
  softmmu,x86_64-softmmu --disable-rdma

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

[Qemu-devel] [Bug 1486911] Re: Error compilation qemu 2.3.1 on raspberry pi (RASPBIAN(debian))

[pranith]

Can you try the latest upstream git version from:
https://github.com/qemu/qemu?

Also can you post your configure command line?

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

Title:
  Error compilation qemu 2.3.1 on raspberry pi (RASPBIAN(debian))

Status in QEMU:
  New

Bug description:
  When compiling from source occurs to me incomprehensible error.
  Operation ./configure runs without problems, but among the logs make see this:
    CP i386-softmmu / hw / i386 / acpi-dsdt.hex
    CP i386-softmmu / hw / i386 / q35-acpi-dsdt.hex
    CP i386-softmmu / hw / i386 / ssdt-tpm.hex
    CC i386-softmmu / target-i386 / translate.o
    CC m68k-softmmu / tcg / tcg-op.o
    CC m68k-softmmu / tcg / optimize.o
  In file included from /home/pi/Zagruzki/qemu-2.3.1/include/qapi/error.h:16:0,
   from /home/pi/Zagruzki/qemu-2.3.1/include/qemu/option.h:31,
   from /home/pi/Zagruzki/qemu-2.3.1/include/qemu-common.h:44,
   from /home/pi/Zagruzki/qemu-2.3.1/tcg/optimize.c:31:
  /home/pi/Zagruzki/qemu-2.3.1/qapi-types.h:196:8: error: unknown type name '$ 
uint64_t'
  /home/pi/Zagruzki/qemu-2.3.1/rules.mak:57: Error the recipe for the purpose 
of «tcg / optimize.o»
  make [1]: *** [tcg / optimize.o] Error 1
  Makefile: 173: error is the recipe for the purpose of «subdir-m68k-softmmu»
  make: *** [subdir-m68k-softmmu] Error 2
  make: *** Waiting for jobs ...

  When you try to create a package using checkinstall is such error:
  /home/pi/Zagruzki/qemu-2.3.1/target-mips/msa_helper.c: In function 
'helper_msa_copy_s_df':
  /home/pi/Zagruzki/qemu-2.3.1/target-mips/msa_helper.c:1269:1: error: 
unrecognizable insn:
  (insn 123 122 124 3 (set (subreg: SI (reg: DI 169) 0)
  (sign_extend: SI (mem / s / j: QI (plus: SI (reg: SI 167)
  (const_int 440 [0x1b8])) [0 env_8 (D) -> active_fpu.fpr 
[ws_9 (D)]. wr.b S1 A8]))) /home/pi/Zagruzki/qemu-2.3.1/target- mips / 
msa_helper.c: 1253 -1
   (nil))
  /home/pi/Zagruzki/qemu-2.3.1/target-mips/msa_helper.c:1269:1: internal 
compiler error: in extract_insn, at recog.c: 2109
  Please submit a full bug report,
  with preprocessed source if appropriate.
  See  for instructions.
  Preprocessed source stored into /tmp/cc1quRqL.out file, please attach this to 
your bugreport.
  /home/pi/Zagruzki/qemu-2.3.1/rules.mak:57: Error the recipe for the purpose 
of «target-mips / msa_helper.o»
  make [1]: *** [target-mips / msa_helper.o] Error 1
  Makefile: 173: error is the recipe for the purpose of «subdir-mips64-softmmu»
  make: *** [subdir-mips64-softmmu] Error 2

   Installation unsuccessful. It cancels the creation of the
  package.

  Cleared ... OK

  Good luck.

  Log make, checkinstall from the terminal http://rghost.ru/7SK6y4bs6
  cc1quRqL.out applications

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

Re: [Qemu-devel] [PATCH v4 1/1] xlnx-zynqmp: Add support for high DDR memory regions

[Alistair Francis]

On Tue, Jan 12, 2016 at 2:15 PM, Peter Crosthwaite
 wrote:
> On Tue, Jan 12, 2016 at 2:07 PM, Alistair Francis
>  wrote:
>> On Tue, Jan 12, 2016 at 2:00 PM, Peter Crosthwaite
>>  wrote:
>>> On Tue, Jan 12, 2016 at 1:59 PM, Alistair Francis
>>>  wrote:
 On Tue, Jan 12, 2016 at 1:01 AM, Peter Maydell  
 wrote:
> On 12 January 2016 at 00:24, Alistair Francis
>  wrote:
>> On Mon, Jan 11, 2016 at 8:04 AM, Peter Maydell 
>>  wrote:
>>> There are a couple of problems you're running into:
>>>
>>> (1) machine->ram_size is a ram_addr_t so might be 32 bit; you
>>> can do what virt.c does to avoid the warning and use a local
>>> uin64_t variable for the comparison
>>
>> Ok, I now create a uint64_t variable to store the value.
>>
>>>
>>> (2) complaint about reassigning back to ram_size. this is spurious
>>> but you can avoid it by making this board behave the same way as
>>> virt.c, vexpress.c etc do if presented with an unsupported
>>> ram_size -- you should fail, rather than truncating and continuing.
>>
>> If I'm using a 64-bit variable to store the value won't this no longer
>> be a problem?
>
> I think you should do the same thing the other boards do anyway.

 Ok, I have changed it to exit instead of resize.

>
>>> (3) %llx is not the correct format string for a ram_addr_t:
>>> use RAM_ADDR_FMT. (This isn't making the compiler complain,
>>> but I noticed it looking at the code.)
>>
>> Again, isn't this fixed by changing to a variable?
>
> %llx isn't right for uint64_t either :-)

 I still have a %llx for the macro as it isn't a ram_addr_t.

>>>
>>> Should be PRIx64 though.
>>
>> Then I get a compiler warning as the macro is a long long unsigned int.
>>
>
> Ahh, the llx is for printing the constant, which hasn't really changed
> from original code anyway (other than a rename). I think the
> RAM_ADDR_FMT  goes to uint64_t and the llx stays?

Yep, that sounds good to me.

Thanks,

Alistair

>
> Regards,
> Peter
>
>> Thanks,
>>
>> Alistair
>>
>>>
>>> Regards,
>>> Peter
>>>
 Re sending now.

 Thanks,

 Alistair

>
> thanks
> -- PMM
>
>>>
>

Re: [Qemu-devel] [PATCH ipxe] build: Enable IPv6 for qemu

[Cole Robinson]

On 11/17/2015 12:25 PM, Cole Robinson wrote:
> ---
> I assume it's fine to enable...
> 
> A fedora user requested it here:
> https://bugzilla.redhat.com/show_bug.cgi?id=1280318
> 
>  src/config/qemu/general.h | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/src/config/qemu/general.h b/src/config/qemu/general.h
> index 30f60d3..61d0ad4 100644
> --- a/src/config/qemu/general.h
> +++ b/src/config/qemu/general.h
> @@ -8,3 +8,6 @@
>  
>  /* Work around missing EFI_PXE_BASE_CODE_PROTOCOL */
>  #define EFI_DOWNGRADE_UX
> +
> +/* Enable IPv6 */
> +#define NET_PROTO_IPV6
> 

ping, is there any reason IPv6 shouldn't be enabled for qemu?

Thanks,
Cole

Re: [Qemu-devel] [PATCH v4 1/1] xlnx-zynqmp: Add support for high DDR memory regions

[Peter Crosthwaite]

On Tue, Jan 12, 2016 at 2:07 PM, Alistair Francis
 wrote:
> On Tue, Jan 12, 2016 at 2:00 PM, Peter Crosthwaite
>  wrote:
>> On Tue, Jan 12, 2016 at 1:59 PM, Alistair Francis
>>  wrote:
>>> On Tue, Jan 12, 2016 at 1:01 AM, Peter Maydell  
>>> wrote:
 On 12 January 2016 at 00:24, Alistair Francis
  wrote:
> On Mon, Jan 11, 2016 at 8:04 AM, Peter Maydell  
> wrote:
>> There are a couple of problems you're running into:
>>
>> (1) machine->ram_size is a ram_addr_t so might be 32 bit; you
>> can do what virt.c does to avoid the warning and use a local
>> uin64_t variable for the comparison
>
> Ok, I now create a uint64_t variable to store the value.
>
>>
>> (2) complaint about reassigning back to ram_size. this is spurious
>> but you can avoid it by making this board behave the same way as
>> virt.c, vexpress.c etc do if presented with an unsupported
>> ram_size -- you should fail, rather than truncating and continuing.
>
> If I'm using a 64-bit variable to store the value won't this no longer
> be a problem?

 I think you should do the same thing the other boards do anyway.
>>>
>>> Ok, I have changed it to exit instead of resize.
>>>

>> (3) %llx is not the correct format string for a ram_addr_t:
>> use RAM_ADDR_FMT. (This isn't making the compiler complain,
>> but I noticed it looking at the code.)
>
> Again, isn't this fixed by changing to a variable?

 %llx isn't right for uint64_t either :-)
>>>
>>> I still have a %llx for the macro as it isn't a ram_addr_t.
>>>
>>
>> Should be PRIx64 though.
>
> Then I get a compiler warning as the macro is a long long unsigned int.
>

Ahh, the llx is for printing the constant, which hasn't really changed
from original code anyway (other than a rename). I think the
RAM_ADDR_FMT  goes to uint64_t and the llx stays?

Regards,
Peter

> Thanks,
>
> Alistair
>
>>
>> Regards,
>> Peter
>>
>>> Re sending now.
>>>
>>> Thanks,
>>>
>>> Alistair
>>>

 thanks
 -- PMM

>>

[Qemu-devel] [Bug 1470170] Re: Unsupported syscalls 370 and 355

[pranith]

Fix has been committed upstream.

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

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

Title:
  Unsupported syscalls 370 and 355

Status in QEMU:
  Fix Released

Bug description:
  Qemu seems to be missing syscalls 370 and 355 when running qemu
  usermode arm. These are used by systemd or some similar new package.
  This can be detected by creating an debian sid armhf with qemu
  debootstrap. When the system is launched with "systemd-nspawn -bD sid-
  arm" this happens (newest git as of today):

  pawning container sid-arm on /home/jpakkane/qemutest/sid-arm. 
  Press ^] three times within 1s to kill container. 
  Failed to create directory /home/jpakkane/qemutest/sid-arm//sys/fs/selinux: 
Read-only file system 
  Failed to create directory /home/jpakkane/qemutest/sid-arm//sys/fs/selinux: 
Read-only file system 
  /etc/localtime is not a symlink, not updating container timezone. 
  qemu: Unsupported syscall: 370 
  qemu: Unsupported syscall: 370 
  qemu: Unsupported syscall: 370 
  qemu: Unsupported syscall: 370 
  qemu: Unsupported syscall: 370 
  qemu: Unsupported syscall: 370 
  qemu: Unsupported syscall: 370 
  qemu: Unsupported syscall: 370 
  qemu: Unsupported syscall: 370 
  qemu: Unsupported syscall: 370 
  qemu: Unsupported syscall: 370 
  qemu: Unsupported syscall: 384 
  qemu: Unsupported syscall: 370 
  qemu: Unsupported syscall: 370 
  qemu: Unsupported syscall: 370 
  qemu: Unsupported syscall: 370 
  qemu: Unsupported syscall: 370 
  qemu: Unsupported syscall: 370 
  qemu: Unsupported syscall: 370 
  qemu: Unsupported syscall: 370 
  qemu: Unsupported syscall: 370 
  systemd 221 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR 
+SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT -GNUTLS +ACL +XZ -LZ4 +SECCOMP 
+BLKID -ELFUTILS +KMOD -IDN) 
  Detected virtualization systemd-nspawn. 
  Detected architecture arm. 

  Welcome to Debian GNU/Linux stretch/sid!

  Set hostname to . 
  qemu: Unsupported syscall: 355 
  Failed to allocate manager object: Function not implemented 
  [!!] Failed to allocate manager object, freezing.

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

Re: [Qemu-devel] [PATCH v4 1/1] xlnx-zynqmp: Add support for high DDR memory regions

[Alistair Francis]

On Tue, Jan 12, 2016 at 2:00 PM, Peter Crosthwaite
 wrote:
> On Tue, Jan 12, 2016 at 1:59 PM, Alistair Francis
>  wrote:
>> On Tue, Jan 12, 2016 at 1:01 AM, Peter Maydell  
>> wrote:
>>> On 12 January 2016 at 00:24, Alistair Francis
>>>  wrote:
 On Mon, Jan 11, 2016 at 8:04 AM, Peter Maydell  
 wrote:
> There are a couple of problems you're running into:
>
> (1) machine->ram_size is a ram_addr_t so might be 32 bit; you
> can do what virt.c does to avoid the warning and use a local
> uin64_t variable for the comparison

 Ok, I now create a uint64_t variable to store the value.

>
> (2) complaint about reassigning back to ram_size. this is spurious
> but you can avoid it by making this board behave the same way as
> virt.c, vexpress.c etc do if presented with an unsupported
> ram_size -- you should fail, rather than truncating and continuing.

 If I'm using a 64-bit variable to store the value won't this no longer
 be a problem?
>>>
>>> I think you should do the same thing the other boards do anyway.
>>
>> Ok, I have changed it to exit instead of resize.
>>
>>>
> (3) %llx is not the correct format string for a ram_addr_t:
> use RAM_ADDR_FMT. (This isn't making the compiler complain,
> but I noticed it looking at the code.)

 Again, isn't this fixed by changing to a variable?
>>>
>>> %llx isn't right for uint64_t either :-)
>>
>> I still have a %llx for the macro as it isn't a ram_addr_t.
>>
>
> Should be PRIx64 though.

Then I get a compiler warning as the macro is a long long unsigned int.

Thanks,

Alistair

>
> Regards,
> Peter
>
>> Re sending now.
>>
>> Thanks,
>>
>> Alistair
>>
>>>
>>> thanks
>>> -- PMM
>>>
>

[Qemu-devel] [Bug 893208] Re: qemu on ARM hosts can't boot i386 image

[pranith]

** Changed in: qemu
   Status: New => Confirmed

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

Title:
  qemu on ARM hosts can't boot i386 image

Status in QEMU:
  Confirmed
Status in Linaro QEMU:
  New

Bug description:
  If you apply some workarounds for bug 870990, bug 883133 and bug
  883136 QEMU still cannot boot the i386
  debian_squeeze_i386_standard.qcow2 image from
  http://people.debian.org/~aurel32/qemu/i386/ -- grub starts to boot
  but something causes the system to reset just before display of the
  blue-background grub menu, so we go round in a loop forever. This
  image boots OK on i386 hosted qemu so this indicates some kind of ARM-
  host specific bug.

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

Re: [Qemu-devel] [PATCH v4 1/1] xlnx-zynqmp: Add support for high DDR memory regions

[Peter Crosthwaite]

On Tue, Jan 12, 2016 at 1:59 PM, Alistair Francis
 wrote:
> On Tue, Jan 12, 2016 at 1:01 AM, Peter Maydell  
> wrote:
>> On 12 January 2016 at 00:24, Alistair Francis
>>  wrote:
>>> On Mon, Jan 11, 2016 at 8:04 AM, Peter Maydell  
>>> wrote:
 There are a couple of problems you're running into:

 (1) machine->ram_size is a ram_addr_t so might be 32 bit; you
 can do what virt.c does to avoid the warning and use a local
 uin64_t variable for the comparison
>>>
>>> Ok, I now create a uint64_t variable to store the value.
>>>

 (2) complaint about reassigning back to ram_size. this is spurious
 but you can avoid it by making this board behave the same way as
 virt.c, vexpress.c etc do if presented with an unsupported
 ram_size -- you should fail, rather than truncating and continuing.
>>>
>>> If I'm using a 64-bit variable to store the value won't this no longer
>>> be a problem?
>>
>> I think you should do the same thing the other boards do anyway.
>
> Ok, I have changed it to exit instead of resize.
>
>>
 (3) %llx is not the correct format string for a ram_addr_t:
 use RAM_ADDR_FMT. (This isn't making the compiler complain,
 but I noticed it looking at the code.)
>>>
>>> Again, isn't this fixed by changing to a variable?
>>
>> %llx isn't right for uint64_t either :-)
>
> I still have a %llx for the macro as it isn't a ram_addr_t.
>

Should be PRIx64 though.

Regards,
Peter

> Re sending now.
>
> Thanks,
>
> Alistair
>
>>
>> thanks
>> -- PMM
>>

Re: [Qemu-devel] [PATCH v4 1/1] xlnx-zynqmp: Add support for high DDR memory regions

[Alistair Francis]

On Tue, Jan 12, 2016 at 1:01 AM, Peter Maydell  wrote:
> On 12 January 2016 at 00:24, Alistair Francis
>  wrote:
>> On Mon, Jan 11, 2016 at 8:04 AM, Peter Maydell  
>> wrote:
>>> There are a couple of problems you're running into:
>>>
>>> (1) machine->ram_size is a ram_addr_t so might be 32 bit; you
>>> can do what virt.c does to avoid the warning and use a local
>>> uin64_t variable for the comparison
>>
>> Ok, I now create a uint64_t variable to store the value.
>>
>>>
>>> (2) complaint about reassigning back to ram_size. this is spurious
>>> but you can avoid it by making this board behave the same way as
>>> virt.c, vexpress.c etc do if presented with an unsupported
>>> ram_size -- you should fail, rather than truncating and continuing.
>>
>> If I'm using a 64-bit variable to store the value won't this no longer
>> be a problem?
>
> I think you should do the same thing the other boards do anyway.

Ok, I have changed it to exit instead of resize.

>
>>> (3) %llx is not the correct format string for a ram_addr_t:
>>> use RAM_ADDR_FMT. (This isn't making the compiler complain,
>>> but I noticed it looking at the code.)
>>
>> Again, isn't this fixed by changing to a variable?
>
> %llx isn't right for uint64_t either :-)

I still have a %llx for the macro as it isn't a ram_addr_t.

Re sending now.

Thanks,

Alistair

>
> thanks
> -- PMM
>

[Qemu-devel] [Bug 1531632] Re: Can't compile qemu because of errors in the Xen code

[pranith]

Can you post the `configure` command line you used when you try to
compile?

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

Title:
  Can't compile qemu because of errors in the Xen code

Status in QEMU:
  New

Bug description:
  I'm using Arch Linux, with all needed libs packages installed via ABS 
(compiled from source).
  I tried to clone the master repository, the v2.5.0 and the stable-2.4.0, all 
I had the same problems:

  First I have to disable -Werror, because it claims about some
  uninitialized variables.

  Trying to compile the code, it stops when compiling the xen code
  (hw/block/xendisk.o), complaining that ioservid_t is declared twice,
  first as 16bit and then as 32bit.

  Output of make:

CChw/block/xen_disk.o
  In file included from /home/leo/qemu/include/hw/xen/xen_backend.h:4:0,
   from /home/leo/qemu/hw/block/xen_disk.c:39:
  /home/leo/qemu/include/hw/xen/xen_common.h:198:18: error: conflicting types 
for ‘ioservid_t’
   typedef uint16_t ioservid_t;
^
  In file included from /usr/include/xenctrl.h:37:0,
   from /home/leo/qemu/include/hw/xen/xen_common.h:9,
   from /home/leo/qemu/include/hw/xen/xen_backend.h:4,
   from /home/leo/qemu/hw/block/xen_disk.c:39:
  /usr/include/xen/xen.h:353:18: note: previous declaration of ‘ioservid_t’ was 
here
   typedef uint32_t ioservid_t;
^
  In file included from /home/leo/qemu/include/hw/xen/xen_backend.h:4:0,
   from /home/leo/qemu/hw/block/xen_disk.c:39:
  /home/leo/qemu/include/hw/xen/xen_common.h: In function 
‘xen_get_ioreq_server_info’:
  /home/leo/qemu/include/hw/xen/xen_common.h:256:36: error: 
‘HVM_PARAM_IOREQ_PFN’ undeclared (first use in this function)
   rc = xc_get_hvm_param(xc, dom, HVM_PARAM_IOREQ_PFN, ¶m);
  ^
  /home/leo/qemu/include/hw/xen/xen_common.h:256:36: note: each undeclared 
identifier is reported only once for each function it appears in
  In file included from /home/leo/qemu/include/hw/xen/xen_backend.h:4:0,
   from /home/leo/qemu/hw/block/xen_disk.c:39:
  /home/leo/qemu/include/hw/xen/xen_common.h:264:36: error: 
‘HVM_PARAM_BUFIOREQ_PFN’ undeclared (first use in this function)
   rc = xc_get_hvm_param(xc, dom, HVM_PARAM_BUFIOREQ_PFN, ¶m);
  ^
  /home/leo/qemu/rules.mak:57: recipe for target 'hw/block/xen_disk.o' failed
  make: *** [hw/block/xen_disk.o] Error 1
  [leo@AlphaArch build]$ make
CChw/block/xen_disk.o
  In file included from /home/leo/qemu/include/hw/xen/xen_backend.h:4:0,
   from /home/leo/qemu/hw/block/xen_disk.c:39:
  /home/leo/qemu/include/hw/xen/xen_common.h:198:18: error: conflicting types 
for ‘ioservid_t’
   typedef uint16_t ioservid_t;
^
  In file included from /usr/include/xenctrl.h:37:0,
   from /home/leo/qemu/include/hw/xen/xen_common.h:9,
   from /home/leo/qemu/include/hw/xen/xen_backend.h:4,
   from /home/leo/qemu/hw/block/xen_disk.c:39:
  /usr/include/xen/xen.h:353:18: note: previous declaration of ‘ioservid_t’ was 
here
   typedef uint32_t ioservid_t;
^
  In file included from /home/leo/qemu/include/hw/xen/xen_backend.h:4:0,
   from /home/leo/qemu/hw/block/xen_disk.c:39:
  /home/leo/qemu/include/hw/xen/xen_common.h: In function 
‘xen_get_ioreq_server_info’:
  /home/leo/qemu/include/hw/xen/xen_common.h:256:36: error: 
‘HVM_PARAM_IOREQ_PFN’ undeclared (first use in this function)
   rc = xc_get_hvm_param(xc, dom, HVM_PARAM_IOREQ_PFN, ¶m);
  ^
  /home/leo/qemu/include/hw/xen/xen_common.h:256:36: note: each undeclared 
identifier is reported only once for each function it appears in
  In file included from /home/leo/qemu/include/hw/xen/xen_backend.h:4:0,
   from /home/leo/qemu/hw/block/xen_disk.c:39:
  /home/leo/qemu/include/hw/xen/xen_common.h:264:36: error: 
‘HVM_PARAM_BUFIOREQ_PFN’ undeclared (first use in this function)
   rc = xc_get_hvm_param(xc, dom, HVM_PARAM_BUFIOREQ_PFN, ¶m);
  ^
  /home/leo/qemu/rules.mak:57: recipe for target 'hw/block/xen_disk.o' failed
  make: *** [hw/block/xen_disk.o] Error 1
  [leo@AlphaArch build]$ make
CChw/block/xen_disk.o
  In file included from /home/leo/qemu/include/hw/xen/xen_backend.h:4:0,
   from /home/leo/qemu/hw/block/xen_disk.c:39:
  /home/leo/qemu/include/hw/xen/xen_common.h:198:18: error: conflicting types 
for ‘ioservid_t’
   typedef uint16_t ioservid_t;
^
  In file included from /usr/include/xenctrl.h:37:0,
   from /home/leo/qemu/include/hw/xen/xen_common.h:9,
   from /home/leo/qemu/include/hw/xen/xen_backend.h:4,
   

Re: [Qemu-devel] Status of my hacks on the MTTCG WIP branch

[Pranith Kumar]

Hi Alex,

On Tue, Jan 12, 2016 at 12:29 PM, Alex Bennée 
wrote:

>
https://github.com/stsquad/qemu/tree/mttcg/multi_tcg_v8_wip_ajb_fix_locks
>

I built this branch and ran an arm64 guest. It seems to be failing
similarly to what I reported earlier:

#0  0x72211cc9 in __GI_raise (sig=sig@entry=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x722150d8 in __GI_abort () at abort.c:89
#2  0x5572014c in qemu_ram_addr_from_host_nofail
(ptr=0xffc000187863) at /home/pranith/devops/code/qemu/cputlb.c:357
#3  0x557209dd in get_page_addr_code (env1=0x56702058,
addr=18446743798833248356) at /home/pranith/devops/code/qemu/cputlb.c:568
#4  0x556db98c in tb_find_physical (cpu=0x566f9dd0,
pc=18446743798833248356, cs_base=0, flags=18446744071830503424) at
/home/pranith/devops/code/qemu/cpu-exec.c:224
#5  0x556dbaf4 in tb_find_slow (cpu=0x566f9dd0,
pc=18446743798833248356, cs_base=0, flags=18446744071830503424) at
/home/pranith/devops/code/qemu/cpu-exec.c:268
#6  0x556dbc77 in tb_find_fast (cpu=0x566f9dd0) at
/home/pranith/devops/code/qemu/cpu-exec.c:311
#7  0x556dc0f1 in cpu_arm_exec (cpu=0x566f9dd0) at
/home/pranith/devops/code/qemu/cpu-exec.c:492
#8  0x557050ee in tcg_cpu_exec (cpu=0x566f9dd0) at
/home/pranith/devops/code/qemu/cpus.c:1486
#9  0x557051af in tcg_exec_all (cpu=0x566f9dd0) at
/home/pranith/devops/code/qemu/cpus.c:1515
#10 0x55704800 in qemu_tcg_cpu_thread_fn (arg=0x566f9dd0) at
/home/pranith/devops/code/qemu/cpus.c:1187
#11 0x725a8182 in start_thread (arg=0x7fffd20c8700) at
pthread_create.c:312
#12 0x722d547d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:111

The arguments I used are as follows:

(gdb) show args

Argument list to give program being debugged when it is started is "-m
1024M -M virt -cpu cortex-a57 -global virtio-blk-device.scsi=off -device
virtio-scsi-device,id=scsi -drive
file=arm64disk.qcow2,id=coreimg,cache=unsafe,if=none -device
scsi-hd,drive=coreimg -netdev user,id=unet -device
virtio-net-device,netdev=unet -kernel vmlinuz -initrd initrd.img -append
root=/dev/sda2 -display sdl -redir tcp:::22 -smp 2".

Does something look obviously wrong to you in the arg list?

Thanks!
-- 
Pranith

Re: [Qemu-devel] [PATCH] disas/libvixl: Suppress gcc 4.6.3 sign-compare warnings

[Peter Maydell]

On 12 January 2016 at 17:36, Peter Maydell  wrote:
> On 12 January 2016 at 16:35, Alex Bennée  wrote:
>>
>> Peter Maydell  writes:
>>
>>> The VIXL code includes some equality comparisons between signed
>>> and unsigned types. Modern gcc and clang do not complain about
>>> these, but older versions of gcc such as gcc 4.6.3 do. Since
>>> libvixl is an upstream library, the simplest approach is to
>>> suppress the warnings by applying -Wno-sign-compare to the
>>> relevant files.
>>>
>>> (GCC 4.6 is not quite yet irrelevant for us; it is the gcc
>>> shipped with Ubuntu Precise, for example, which is an LTS
>>> release not yet out of its support period.)
>>>
>>> Signed-off-by: Peter Maydell 
>>> ---
>>> I had mistakenly thought these warnings only happened with
>>> the totally ancient mingw gcc, but it turns out they're a
>>> bit more widespread. In particular this is causing our
>>> Travis builds to fail:
>>>   https://travis-ci.org/qemu/qemu/jobs/101813358
>>>
>>> If somebody could review this then I'll apply it to master
>>> as a buildfix.
>>
>> Reviewed-by: Alex Bennée 
>
> Thanks; applied to master.

Unfortunately it doesn't seem to actually fix the travis
build; not sure why...
https://travis-ci.org/qemu/qemu/jobs/101902544

-- PMM

Re: [Qemu-devel] [PATCH] sdl: shorten the GUI refresh interval when mouse or keyboard is active

[Jindřich Makovička]

Hi Gerd,

On Mon, 11 Jan 2016 14:10:16 +0100
Gerd Hoffmann  wrote:

>   Hi,
> 
> For SDL2 this ...
> 
> > > +static int idle_counter;  
> 
> ... should be store in ...
> 
> > >  void sdl2_poll_events(struct sdl2_console *scon)  
> 
> ... sdl2_console, otherwise it will not work as intended in case
> multiple windows are present.
> 
> Otherwise looks fine to me.

Updated patch attached.

Regards,
-- 
Jindrich Makovicka
From 7f01ec81210ea16af33ebacf6a348618570131e8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jind=C5=99ich=20Makovi=C4=8Dka?= 
Date: Tue, 12 Jan 2016 20:18:24 +0100
Subject: [PATCH] sdl: shorten the GUI refresh interval when mouse or keyboard
 is active
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Signed-off-by: Jindřich Makovička 
---
 include/ui/sdl2.h |  1 +
 ui/sdl.c  | 22 ++
 ui/sdl2.c | 23 +++
 3 files changed, 46 insertions(+)

diff --git a/include/ui/sdl2.h b/include/ui/sdl2.h
index b7ac38f..3f0b57b 100644
--- a/include/ui/sdl2.h
+++ b/include/ui/sdl2.h
@@ -19,6 +19,7 @@ struct sdl2_console {
 int hidden;
 int opengl;
 int updates;
+int idle_counter;
 SDL_GLContext winctx;
 #ifdef CONFIG_OPENGL
 ConsoleGLState *gls;
diff --git a/ui/sdl.c b/ui/sdl.c
index c837436..f215fe1 100644
--- a/ui/sdl.c
+++ b/ui/sdl.c
@@ -60,6 +60,11 @@ static SDL_Cursor *guest_sprite = NULL;
 static SDL_PixelFormat host_format;
 static int scaling_active = 0;
 static Notifier mouse_mode_notifier;
+static int idle_counter;
+
+#define SDL_REFRESH_INTERVAL_BUSY 10
+#define SDL_MAX_IDLE_COUNT (2 * GUI_REFRESH_INTERVAL_DEFAULT \
+/ SDL_REFRESH_INTERVAL_BUSY + 1)
 
 #if 0
 #define DEBUG_SDL
@@ -802,6 +807,7 @@ static void handle_activation(SDL_Event *ev)
 static void sdl_refresh(DisplayChangeListener *dcl)
 {
 SDL_Event ev1, *ev = &ev1;
+int idle = 1;
 
 if (last_vm_running != runstate_is_running()) {
 last_vm_running = runstate_is_running();
@@ -817,9 +823,11 @@ static void sdl_refresh(DisplayChangeListener *dcl)
 sdl_update(dcl, 0, 0, real_screen->w, real_screen->h);
 break;
 case SDL_KEYDOWN:
+idle = 0;
 handle_keydown(ev);
 break;
 case SDL_KEYUP:
+idle = 0;
 handle_keyup(ev);
 break;
 case SDL_QUIT:
@@ -829,10 +837,12 @@ static void sdl_refresh(DisplayChangeListener *dcl)
 }
 break;
 case SDL_MOUSEMOTION:
+idle = 0;
 handle_mousemotion(ev);
 break;
 case SDL_MOUSEBUTTONDOWN:
 case SDL_MOUSEBUTTONUP:
+idle = 0;
 handle_mousebutton(ev);
 break;
 case SDL_ACTIVEEVENT:
@@ -847,6 +857,18 @@ static void sdl_refresh(DisplayChangeListener *dcl)
 break;
 }
 }
+
+if (idle) {
+if (idle_counter < SDL_MAX_IDLE_COUNT) {
+idle_counter++;
+if (idle_counter >= SDL_MAX_IDLE_COUNT) {
+dcl->update_interval = GUI_REFRESH_INTERVAL_DEFAULT;
+}
+}
+} else {
+idle_counter = 0;
+dcl->update_interval = SDL_REFRESH_INTERVAL_BUSY;
+}
 }
 
 static void sdl_mouse_warp(DisplayChangeListener *dcl,
diff --git a/ui/sdl2.c b/ui/sdl2.c
index 46270f4..c0a76d7 100644
--- a/ui/sdl2.c
+++ b/ui/sdl2.c
@@ -49,6 +49,10 @@ static int guest_x, guest_y;
 static SDL_Cursor *guest_sprite;
 static Notifier mouse_mode_notifier;
 
+#define SDL2_REFRESH_INTERVAL_BUSY 10
+#define SDL2_MAX_IDLE_COUNT (2 * GUI_REFRESH_INTERVAL_DEFAULT \
+ / SDL2_REFRESH_INTERVAL_BUSY + 1)
+
 static void sdl_update_caption(struct sdl2_console *scon);
 
 static struct sdl2_console *get_scon_from_window(uint32_t window_id)
@@ -578,6 +582,7 @@ static void handle_windowevent(SDL_Event *ev)
 void sdl2_poll_events(struct sdl2_console *scon)
 {
 SDL_Event ev1, *ev = &ev1;
+int idle = 1;
 
 if (scon->last_vm_running != runstate_is_running()) {
 scon->last_vm_running = runstate_is_running();
@@ -587,12 +592,15 @@ void sdl2_poll_events(struct sdl2_console *scon)
 while (SDL_PollEvent(ev)) {
 switch (ev->type) {
 case SDL_KEYDOWN:
+idle = 0;
 handle_keydown(ev);
 break;
 case SDL_KEYUP:
+idle = 0;
 handle_keyup(ev);
 break;
 case SDL_TEXTINPUT:
+idle = 0;
 handle_textinput(ev);
 break;
 case SDL_QUIT:
@@ -602,13 +610,16 @@ void sdl2_poll_events(struct sdl2_console *scon)
 }
 break;
 case SDL_MOUSEMOTION:
+idle = 0;
 handle_mousemotion(ev);
 break;
 case SDL_MOUSEBUTTONDOWN:
 case SDL_MOUSEBUTTONUP:
+idle = 0;
 handle_mousebutton(ev);
 break;
 cas

Re: [Qemu-devel] [PATCH 0/6] NVDIMM ACPI: introduce the framework of QEMU emulated DSM

[Xiao Guangrong]

On 01/07/2016 10:13 PM, Igor Mammedov wrote:

On Tue,  5 Jan 2016 02:52:02 +0800
Xiao Guangrong  wrote:


This patchset is against commit 5530427f0ca (acpi: extend aml_and() to
accept target argument) on pci branch of Michael's git tree
and can be found at:
   https://github.com/xiaogr/qemu.git nvdimm-acpi-v1

This is the second part of vNVDIMM implementation which implements the
BIOS patched dsm memory and introduces the framework that allows QEMU
to emulate DSM method

Thanks to Michael's idea, we do not reserve any memory for NVDIMM ACPI,
instead we let BIOS allocate the memory and patch the address to the
offset we want

IO port is still enabled as it plays as the way to notify QEMU and pass
the patched dsm memory address, so that IO port region, 0x0a18 - 0xa20,
is reserved and it is divided into two 32 bits ports and used to pass
the low 32 bits and high 32 bits of dsm memory address to QEMU

Thanks Igor's idea, this patchset also extends DSDT/SSDT to revision 2
to apply 64 bit operations, in order to keeping compatibility, old
version (<= 2.5) still uses revision 1. Since 64 bit operations breaks
old guests (such as windows XP), we should keep the 64 bits stuff in
the private place where common ACPI operation does not touch it



general notes:
1. could you split out AML API additions/changes into separate patches?
even if series nvdims patches couldn't be accepted on next respin,
AML API patches could be good and we could pick them up just
for API completeness. That also would make them easier to review
and reduces count of patches you'd need to respin.


Yes, it is definitely better. Have done it in the v2.


2. add test case for NVDIMM table blob, see tests/bios-tables-test.c
at the beginning of series.
3. make V=1 check would show you ASL diff your patches are introducing,
it will save you from booting real guest and dumping/decompiling
tables manually.
4. at the end of series add NVDIMM table test blob with new table.
you can use tests/acpi-test-data/rebuild-expected-aml.sh to make it
5. if make check by some miracle passes with these patches,
dump NVDIMM table in guest and try to decompile and then compile it
back with IASL, it will show you what needs to be fixed.


Igor, really appreciate the tips you shared to me, that helped me a lot
in the development of the new version.

BTW, i did not touch the core bios_linker_loader_add_pointer() API as
i think it can be changed in a separated patchset. In the new version
we zeroed the offset by nvdimm itself and dropped aml_int64().

The new version has been posted out, please review.

Thank you!

[Qemu-devel] [PATCH v2 11/11] tests: acpi: update nvdimm ssdt table

[Xiao Guangrong]

update the nvdimm ssdt table as its acpi code has been updated

Signed-off-by: Xiao Guangrong 
---
 tests/acpi-test-data/pc/SSDT-NVDIMM | Bin 134 -> 403 bytes
 tests/acpi-test-data/pc/SSDT-NVDIMM.bridge  | Bin 134 -> 403 bytes
 tests/acpi-test-data/q35/SSDT-NVDIMM| Bin 134 -> 403 bytes
 tests/acpi-test-data/q35/SSDT-NVDIMM.bridge | Bin 134 -> 403 bytes
 4 files changed, 0 insertions(+), 0 deletions(-)

diff --git a/tests/acpi-test-data/pc/SSDT-NVDIMM 
b/tests/acpi-test-data/pc/SSDT-NVDIMM
index 
22265278c3a4df9e9fee0ea9e04b37f2c80baa29..eaf816003b6ba60248aa28d54726fef5d1cc3cb0
 100644
GIT binary patch
literal 403
zcmZ8b!A`Ou1j55dJxky
z5{_cuf9OJsoaj(U%VMI}ZQk3R&l>>OEC;K1D2k#Y4S*GVp~<#c%=I5VXJn=`7BPao
zHv|V7*!)1q(XZBg6eosrYumMw3&H>gN}t*|D4BfRk3F^Npk@x}F!Dq+m0o|sLyw5Z
z-ukDmHkXwuh7tD?O2+F$y~U1sNQUmdy~9A*pY9frH%+4gBLj@e=9rZ&FswQhmt`1}
zW~eM=K6jQ^sA2e|NE)PDig
CC}#lx

delta 59
zcmbQt+{VZi9PAR(#=yY9cxNJ)G`AyLOnk6Yd~}ls>qG+)QBglOu1j55dJxky
z5{_cuf9OJsoaj(U%VMI}ZQk3R&l>>OEC;K1D2k#Y4S*GVp~<#c%=I5VXJn=`7BPao
zHv|V7*!)1q(XZBg6eosrYumMw3&H>gN}t*|D4BfRk3F^Npk@x}F!Dq+m0o|sLyw5Z
z-ukDmHkXwuh7tD?O2+F$y~U1sNQUmdy~9A*pY9frH%+4gBLj@e=9rZ&FswQhmt`1}
zW~eM=K6jQ^sA2e|NE)PDig
CC}#lx

delta 59
zcmbQt+{VZi9PAR(#=yY9cxNJ)G`AyLOnk6Yd~}ls>qG+)QBglOu1j55dJxky
z5{_cuf9OJsoaj(U%VMI}ZQk3R&l>>OEC;K1D2k#Y4S*GVp~<#c%=I5VXJn=`7BPao
zHv|V7*!)1q(XZBg6eosrYumMw3&H>gN}t*|D4BfRk3F^Npk@x}F!Dq+m0o|sLyw5Z
z-ukDmHkXwuh7tD?O2+F$y~U1sNQUmdy~9A*pY9frH%+4gBLj@e=9rZ&FswQhmt`1}
zW~eM=K6jQ^sA2e|NE)PDig
CC}#lx

delta 59
zcmbQt+{VZi9PAR(#=yY9cxNJ)G`AyLOnk6Yd~}ls>qG+)QBglOu1j55dJxky
z5{_cuf9OJsoaj(U%VMI}ZQk3R&l>>OEC;K1D2k#Y4S*GVp~<#c%=I5VXJn=`7BPao
zHv|V7*!)1q(XZBg6eosrYumMw3&H>gN}t*|D4BfRk3F^Npk@x}F!Dq+m0o|sLyw5Z
z-ukDmHkXwuh7tD?O2+F$y~U1sNQUmdy~9A*pY9frH%+4gBLj@e=9rZ&FswQhmt`1}
zW~eM=K6jQ^sA2e|NE)PDig
CC}#lx

delta 59
zcmbQt+{VZi9PAR(#=yY9cxNJ)G`AyLOnk6Yd~}ls>qG+)QBgl

[Qemu-devel] [PATCH v2 08/11] nvdimm acpi: let qemu handle _DSM method

[Xiao Guangrong]

If dsm memory is successfully patched, we let qemu fully emulate
the dsm method

This patch saves _DSM input parameters into dsm memory, tell dsm
memory address to QEMU, then fetch the result from the dsm memory

Signed-off-by: Xiao Guangrong 
---
 hw/acpi/nvdimm.c | 117 ---
 1 file changed, 112 insertions(+), 5 deletions(-)

diff --git a/hw/acpi/nvdimm.c b/hw/acpi/nvdimm.c
index e7acc98..358e340 100644
--- a/hw/acpi/nvdimm.c
+++ b/hw/acpi/nvdimm.c
@@ -371,6 +371,24 @@ static void nvdimm_build_nfit(GSList *device_list, GArray 
*table_offsets,
 g_array_free(structures, true);
 }
 
+struct NvdimmDsmIn {
+uint32_t handle;
+uint32_t revision;
+uint32_t function;
+   /* the remaining size in the page is used by arg3. */
+union {
+uint8_t arg3[0];
+};
+} QEMU_PACKED;
+typedef struct NvdimmDsmIn NvdimmDsmIn;
+
+struct NvdimmDsmOut {
+/* the size of buffer filled by QEMU. */
+uint32_t len;
+uint8_t data[0];
+} QEMU_PACKED;
+typedef struct NvdimmDsmOut NvdimmDsmOut;
+
 static uint64_t
 nvdimm_dsm_read(void *opaque, hwaddr addr, unsigned size)
 {
@@ -410,11 +428,18 @@ void nvdimm_init_acpi_state(AcpiNVDIMMState *state, 
MemoryRegion *io,
 
 static void nvdimm_build_common_dsm(Aml *dev)
 {
-Aml *method, *ifctx, *function;
+Aml *method, *ifctx, *function, *dsm_mem, *unpatched, *result_size;
 uint8_t byte_list[1];
 
-method = aml_method(NVDIMM_COMMON_DSM, 4, AML_NOTSERIALIZED);
+method = aml_method(NVDIMM_COMMON_DSM, 4, AML_SERIALIZED);
 function = aml_arg(2);
+dsm_mem = aml_name(NVDIMM_ACPI_MEM_ADDR);
+
+/*
+ * do not support any method if DSM memory address has not been
+ * patched.
+ */
+unpatched = aml_if(aml_equal(dsm_mem, aml_int(0x0)));
 
 /*
  * function 0 is called to inquire what functions are supported by
@@ -423,12 +448,36 @@ static void nvdimm_build_common_dsm(Aml *dev)
 ifctx = aml_if(aml_equal(function, aml_int(0)));
 byte_list[0] = 0 /* No function Supported */;
 aml_append(ifctx, aml_return(aml_buffer(1, byte_list)));
-aml_append(method, ifctx);
+aml_append(unpatched, ifctx);
 
 /* No function is supported yet. */
 byte_list[0] = 1 /* Not Supported */;
-aml_append(method, aml_return(aml_buffer(1, byte_list)));
+aml_append(unpatched, aml_return(aml_buffer(1, byte_list)));
+aml_append(method, unpatched);
+
+/*
+ * Currently no function is supported for both root device and NVDIMM
+ * devices, let's temporarily set handle to 0x0 at this time.
+ */
+aml_append(method, aml_store(aml_int(0x0), aml_name("HDLE")));
+aml_append(method, aml_store(aml_arg(1), aml_name("REVS")));
+aml_append(method, aml_store(aml_arg(2), aml_name("FUNC")));
 
+/*
+ * tell QEMU about the real address of DSM memory, then QEMU begins
+ * to emulate the method and fills the result to DSM memory.
+ */
+aml_append(method, aml_store(dsm_mem, aml_name("NTFI")));
+
+result_size = aml_local(1);
+aml_append(method, aml_store(aml_name("RLEN"), result_size));
+aml_append(method, aml_store(aml_shiftleft(result_size, aml_int(3)),
+ result_size));
+aml_append(method, aml_create_field(aml_name("ODAT"), aml_int(0),
+result_size, "OBUF"));
+aml_append(method, aml_concatenate(aml_buffer(0, NULL), aml_name("OBUF"),
+   aml_arg(6)));
+aml_append(method, aml_return(aml_arg(6)));
 aml_append(dev, method);
 }
 
@@ -471,7 +520,7 @@ static void nvdimm_build_nvdimm_devices(GSList 
*device_list, Aml *root_dev)
 static void nvdimm_build_ssdt(GSList *device_list, GArray *table_offsets,
   GArray *table_data, GArray *linker)
 {
-Aml *ssdt, *sb_scope, *dev, *mem_addr;
+Aml *ssdt, *sb_scope, *dev, *field, *mem_addr;
 uint32_t zero_offset = 0;
 int offset;
 
@@ -497,6 +546,64 @@ static void nvdimm_build_ssdt(GSList *device_list, GArray 
*table_offsets,
  */
 aml_append(dev, aml_name_decl("_HID", aml_string("ACPI0012")));
 
+/* map DSM memory and IO into ACPI namespace. */
+aml_append(dev, aml_operation_region("NPIO", AML_SYSTEM_IO,
+   aml_int(NVDIMM_ACPI_IO_BASE), NVDIMM_ACPI_IO_LEN));
+aml_append(dev, aml_operation_region("NRAM", AML_SYSTEM_MEMORY,
+   aml_name(NVDIMM_ACPI_MEM_ADDR), TARGET_PAGE_SIZE));
+
+/*
+ * DSM notifier:
+ * NTFI: write the address of DSM memory and notify QEMU to emulate
+ *   the access.
+ *
+ * It is the IO port so that accessing them will cause VM-exit, the
+ * control will be transferred to QEMU.
+ */
+field = aml_field("NPIO", AML_DWORD_ACC, AML_NOLOCK, AML_PRESERVE);
+aml_append(field, aml_named_field("NTFI",
+   sizeof(uint32_t) * BITS_PER_BYTE));
+aml_append(dev, field);
+
+/*
+ * DSM input:
+ * @HDLE: sto

[Qemu-devel] [PATCH v2 04/11] acpi: add aml_concatenate()

[Xiao Guangrong]

It will be used by nvdimm acpi

Signed-off-by: Xiao Guangrong 
---
 hw/acpi/aml-build.c | 14 ++
 include/hw/acpi/aml-build.h |  1 +
 2 files changed, 15 insertions(+)

diff --git a/hw/acpi/aml-build.c b/hw/acpi/aml-build.c
index 97c9efb..421dd84 100644
--- a/hw/acpi/aml-build.c
+++ b/hw/acpi/aml-build.c
@@ -1440,6 +1440,20 @@ Aml *aml_alias(const char *source_object, const char 
*alias_object)
 return var;
 }
 
+/* ACPI 1.0b: 16.2.5.4 Type 2 Opcodes Encoding: DefConcat */
+Aml *aml_concatenate(Aml *source1, Aml *source2, Aml *target)
+{
+Aml *var = aml_opcode(0x73 /* ConcatOp */);
+aml_append(var, source1);
+aml_append(var, source2);
+
+if (target) {
+aml_append(var, target);
+}
+
+return var;
+}
+
 void
 build_header(GArray *linker, GArray *table_data,
  AcpiTableHeader *h, const char *sig, int len, uint8_t rev,
diff --git a/include/hw/acpi/aml-build.h b/include/hw/acpi/aml-build.h
index e1ba534..4a5168a 100644
--- a/include/hw/acpi/aml-build.h
+++ b/include/hw/acpi/aml-build.h
@@ -354,6 +354,7 @@ Aml *aml_touuid(const char *uuid);
 Aml *aml_unicode(const char *str);
 Aml *aml_derefof(Aml *arg);
 Aml *aml_sizeof(Aml *arg);
+Aml *aml_concatenate(Aml *source1, Aml *source2, Aml *target);
 
 void
 build_header(GArray *linker, GArray *table_data,
-- 
1.8.3.1

[Qemu-devel] [PATCH v2 02/11] tests: acpi: test NVDIMM tables

[Xiao Guangrong]

Add nvdimm test, two tables are created which are NFIT and
SSDT

Max memory size and multiple slots are needed to enable NVDIMM which
cause the primal SSDT table is also updated

Signed-off-by: Xiao Guangrong 
---
 tests/acpi-test-data/pc/NFIT| Bin 0 -> 224 bytes
 tests/acpi-test-data/pc/NFIT.bridge | Bin 0 -> 224 bytes
 tests/acpi-test-data/pc/SSDT| Bin 2486 -> 2885 bytes
 tests/acpi-test-data/pc/SSDT-NVDIMM | Bin 0 -> 134 bytes
 tests/acpi-test-data/pc/SSDT-NVDIMM.bridge  | Bin 0 -> 134 bytes
 tests/acpi-test-data/pc/SSDT.bridge | Bin 4345 -> 4745 bytes
 tests/acpi-test-data/q35/NFIT   | Bin 0 -> 224 bytes
 tests/acpi-test-data/q35/NFIT.bridge| Bin 0 -> 224 bytes
 tests/acpi-test-data/q35/SSDT   | Bin 691 -> 1090 bytes
 tests/acpi-test-data/q35/SSDT-NVDIMM| Bin 0 -> 134 bytes
 tests/acpi-test-data/q35/SSDT-NVDIMM.bridge | Bin 0 -> 134 bytes
 tests/acpi-test-data/q35/SSDT.bridge| Bin 708 -> 1107 bytes
 tests/bios-tables-test.c|  15 ++-
 13 files changed, 10 insertions(+), 5 deletions(-)
 create mode 100644 tests/acpi-test-data/pc/NFIT
 create mode 100644 tests/acpi-test-data/pc/NFIT.bridge
 create mode 100644 tests/acpi-test-data/pc/SSDT-NVDIMM
 create mode 100644 tests/acpi-test-data/pc/SSDT-NVDIMM.bridge
 create mode 100644 tests/acpi-test-data/q35/NFIT
 create mode 100644 tests/acpi-test-data/q35/NFIT.bridge
 create mode 100644 tests/acpi-test-data/q35/SSDT-NVDIMM
 create mode 100644 tests/acpi-test-data/q35/SSDT-NVDIMM.bridge

diff --git a/tests/acpi-test-data/pc/NFIT b/tests/acpi-test-data/pc/NFIT
new file mode 100644
index 
..2d2a190bd0a603dac228177428f4884e23393a7c
GIT binary patch
literal 224
zcmeZs^9*^wz`($m?Bwt45v<@85#a0x6k`O6f!H7#0xTGq7?@!khRVwy(mrn~aaiNb
zYb>$7=Qc$7=Qc_4hm*i5~I(8tlt+X
z2vQD|4i0g|lnx3Gfl3EN_+m-}1;Nsa@&3W}A>JQ7?_k>f>Vd_&wMBAFI&P0nCw1I0lmh{*_I8fI?Z!Ss&}0M+w@
Ae*gdg

delta 67
zcmX>qwoRBTIM^j*8z%z;HZMy8JSrk^6{=-28$7=Qc$7=Qc3~-0_B_I=&v$c_g@=BFBr!_=dPiL^3Vlnw-JV28x4B5R(zaG|Zfw!{iPClKFy&

delta 66
zcmX@av6+=CIM^j*GZO;?W9>#RenuuQ$;r};d&PY@V)U8ggPr07oIMSEJpx=fd|mv4
W7$$#UEMpg8^9^x}WSab&*&P5k77>a7

diff --git a/tests/acpi-test-data/q35/SSDT-NVDIMM 
b/tests/acpi-test-data/q35/SSDT-NVDIMM
new file mode 100644
index 
..22265278c3a4df9e9fee0ea9e04b37f2c80baa29
GIT binary patch
literal 134
zcmWFzb_r=?U|?XpWu@nmVny%K&LG5XB$!A|i3&YlLo9sw>KzAk=2
zTuhVSGnUmyH+gaU1{fG{#D{vi@ETMY7%*_edw9C=I9}js5Rr>_4hm*i5~I(8tlt+X
z2vQD|4i0g|lnx3Gfl3EN_+m-}1;Nsa@&3W}A>JQ7?_k>f>Vd_&wMBAFI&P0nCw1I0lmh{*_I8fH$;VTu3%NXmk4

delta 66
zcmcc2afFpCIM^lR2onPXqwGd5enuv5smaoed&PY@V)U8ggPr07oIMSEJpx=fd|mv4
W7$$#UEMpg8^9^x}WSab&IRXGMZ4qz)

diff --git a/tests/bios-tables-test.c b/tests/bios-tables-test.c
index fc01cce..87cf2e5 100644
--- a/tests/bios-tables-test.c
+++ b/tests/bios-tables-test.c
@@ -157,6 +157,10 @@ static const char *iasl = stringify(CONFIG_IASL);
 static const char *iasl;
 #endif
 
+#define NVDIMM_PARAMS   " -m 128M,maxmem=5G,slots=2 "   \
+"-object memory-backend-ram,id=mem1,size=128M " \
+"-device nvdimm,memdev=mem1"
+
 static void free_test_data(test_data *data)
 {
 AcpiSdtTable *temp;
@@ -823,7 +827,7 @@ static void test_acpi_piix4_tcg(void)
  */
 memset(&data, 0, sizeof(data));
 data.machine = MACHINE_PC;
-test_acpi_one("-machine accel=tcg", &data);
+test_acpi_one("-machine accel=tcg,nvdimm" NVDIMM_PARAMS, &data);
 free_test_data(&data);
 }
 
@@ -834,7 +838,8 @@ static void test_acpi_piix4_tcg_bridge(void)
 memset(&data, 0, sizeof(data));
 data.machine = MACHINE_PC;
 data.variant = ".bridge";
-test_acpi_one("-machine accel=tcg -device pci-bridge,chassis_nr=1", &data);
+test_acpi_one("-machine accel=tcg,nvdimm -device pci-bridge,chassis_nr=1"
+  NVDIMM_PARAMS, &data);
 free_test_data(&data);
 }
 
@@ -844,7 +849,7 @@ static void test_acpi_q35_tcg(void)
 
 memset(&data, 0, sizeof(data));
 data.machine = MACHINE_Q35;
-test_acpi_one("-machine q35,accel=tcg", &data);
+test_acpi_one("-machine q35,accel=tcg,nvdimm" NVDIMM_PARAMS, &data);
 free_test_data(&data);
 }
 
@@ -855,8 +860,8 @@ static void test_acpi_q35_tcg_bridge(void)
 memset(&data, 0, sizeof(data));
 data.machine = MACHINE_Q35;
 data.variant = ".bridge";
-test_acpi_one("-machine q35,accel=tcg -device pci-bridge,chassis_nr=1",
-  &data);
+test_acpi_one("-machine q35,accel=tcg,nvdimm "
+  "-device pci-bridge,chassis_nr=1" NVDIMM_PARAMS, &data);
 free_test_data(&data);
 }
 
-- 
1.8.3.1

[Qemu-devel] [PATCH v1 10/15] qcow2: convert QCow2 to use QCryptoBlock for encryption

[Daniel P. Berrange]

This converts the qcow2 driver to make use of the QCryptoBlock
APIs for encrypting image content. As well as continued support
for the legacy QCow2 encryption format, the appealing benefit
is that it enables support for the LUKS format inside qcow2.

With the LUKS format it is neccessary to store the LUKS
partition header and key material in the QCow2 file. This
data can be many MB in size, so cannot go into the QCow2
header region directly. Thus the spec is defines a FDE
(Full Disk Encryption) header extension that specifies
the offset of a set of clusters to hold the FDE headers,
as well as the length of that region. The LUKS header is
thus stored in these extra allocated clusters before the
main image payload.

With this change it is now required to use the QCryptoSecret
object for providing passwords, instead of the current block
password APIs / interactive prompting.

  $QEMU \
-object secret,id=sec0,filename=/home/berrange/encrypted.pw \
-drive file=/home/berrange/encrypted.qcow2,key-id=sec0

The new LUKS format is set as the new default format when
creating encrypted images. ie

  # qemu-img create --object secret,data=123456,id=sec0 \
   -f qcow2 -o encryption,key-id=sec0 \
   test.qcow2 10G

Results in creation of an image using the LUKS format.

For compatibility the old qcow2 AES format can still be used
via the 'encryption-format' parameter which accepts the
values 'luks' or 'qcowaes'.

  # qemu-img create --object secret,data=123456,id=sec0 \
   -f qcow2 -o encryption,key-id=sec0,encryption-format=qcowaes \
   test.qcow2 10G

Signed-off-by: Daniel P. Berrange 
---
 block/qcow2-cluster.c |  46 +
 block/qcow2.c | 502 +++---
 block/qcow2.h |  21 ++-
 docs/specs/qcow2.txt  |  71 +++
 qapi/block-core.json  |   6 +-
 5 files changed, 529 insertions(+), 117 deletions(-)

diff --git a/block/qcow2-cluster.c b/block/qcow2-cluster.c
index f5bc4f2..33297f8 100644
--- a/block/qcow2-cluster.c
+++ b/block/qcow2-cluster.c
@@ -341,45 +341,6 @@ static int count_contiguous_clusters_by_type(int 
nb_clusters,
 return i;
 }
 
-int qcow2_encrypt_sectors(BDRVQcow2State *s, int64_t sector_num,
-  uint8_t *buf, int nb_sectors, bool enc,
-  Error **errp)
-{
-union {
-uint64_t ll[2];
-uint8_t b[16];
-} ivec;
-int i;
-int ret;
-
-for(i = 0; i < nb_sectors; i++) {
-ivec.ll[0] = cpu_to_le64(sector_num);
-ivec.ll[1] = 0;
-if (qcrypto_cipher_setiv(s->cipher,
- ivec.b, G_N_ELEMENTS(ivec.b),
- errp) < 0) {
-return -1;
-}
-if (enc) {
-ret = qcrypto_cipher_encrypt(s->cipher,
- buf, buf,
- 512,
- errp);
-} else {
-ret = qcrypto_cipher_decrypt(s->cipher,
- buf, buf,
- 512,
- errp);
-}
-if (ret < 0) {
-return -1;
-}
-sector_num++;
-buf += 512;
-}
-return 0;
-}
-
 static int coroutine_fn copy_sectors(BlockDriverState *bs,
  uint64_t start_sect,
  uint64_t cluster_offset,
@@ -421,10 +382,11 @@ static int coroutine_fn copy_sectors(BlockDriverState *bs,
 
 if (bs->encrypted) {
 Error *err = NULL;
-assert(s->cipher);
-if (qcow2_encrypt_sectors(s, start_sect + n_start,
+assert(s->fde);
+if (qcrypto_block_encrypt(s->fde,
+  start_sect + n_start,
   iov.iov_base, n,
-  true, &err) < 0) {
+  &err) < 0) {
 ret = -EIO;
 error_free(err);
 goto out;
diff --git a/block/qcow2.c b/block/qcow2.c
index c0fc259..288aada 100644
--- a/block/qcow2.c
+++ b/block/qcow2.c
@@ -34,6 +34,8 @@
 #include "qapi-event.h"
 #include "trace.h"
 #include "qemu/option_int.h"
+#include "qapi/opts-visitor.h"
+#include "qapi-visit.h"
 
 /*
   Differences with QCOW:
@@ -60,6 +62,7 @@ typedef struct {
 #define  QCOW2_EXT_MAGIC_END 0
 #define  QCOW2_EXT_MAGIC_BACKING_FORMAT 0xE2792ACA
 #define  QCOW2_EXT_MAGIC_FEATURE_TABLE 0x6803f857
+#define  QCOW2_EXT_MAGIC_FDE_HEADER 0x4c554b53
 
 static int qcow2_probe(const uint8_t *buf, int buf_size, const char *filename)
 {
@@ -74,6 +77,83 @@ static int qcow2_probe(const uint8_t *buf, int buf_size, 
const char *filename)
 }
 
 
+static ssize_t qcow2_fde_header_read_func(QCryptoBlock *block,
+  size_t offset,
+  uint8_t *buf,
+   

[Qemu-devel] [PATCH v1 04/15] crypto: add support for anti-forensic split algorithm

[Daniel P. Berrange]

The LUKS format specifies an anti-forensic split algorithm which
is used to artificially expand the size of the key material on
disk. This is an implementation of that algorithm.

Signed-off-by: Daniel P. Berrange 
---
 crypto/Makefile.objs|   1 +
 crypto/afsplit.c| 194 
 include/crypto/afsplit.h| 133 ++
 tests/.gitignore|   1 +
 tests/Makefile  |   2 +
 tests/test-crypto-afsplit.c | 176 
 6 files changed, 507 insertions(+)
 create mode 100644 crypto/afsplit.c
 create mode 100644 include/crypto/afsplit.h
 create mode 100644 tests/test-crypto-afsplit.c

diff --git a/crypto/Makefile.objs b/crypto/Makefile.objs
index a973483..1e08a3a 100644
--- a/crypto/Makefile.objs
+++ b/crypto/Makefile.objs
@@ -14,6 +14,7 @@ crypto-obj-y += ivgen.o
 crypto-obj-y += ivgen-essiv.o
 crypto-obj-y += ivgen-plain.o
 crypto-obj-y += ivgen-plain64.o
+crypto-obj-y += afsplit.o
 
 # Let the userspace emulators avoid linking gnutls/etc
 crypto-aes-obj-y = aes.o
diff --git a/crypto/afsplit.c b/crypto/afsplit.c
new file mode 100644
index 000..7131622
--- /dev/null
+++ b/crypto/afsplit.c
@@ -0,0 +1,194 @@
+/*
+ * QEMU Crypto anti forensic information splitter
+ *
+ * Copyright (c) 2015 Red Hat, Inc.
+ *
+ * Derived from cryptsetup package lib/lusk1/af.c
+ *
+ * Copyright (C) 2004, Clemens Fruhwirth 
+ * Copyright (C) 2009-2012, Red Hat, Inc. All rights reserved.
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see .
+ *
+ */
+
+#include "crypto/afsplit.h"
+#include "crypto/random.h"
+
+
+static void qcrypto_afsplit_xor(size_t blocklen,
+const uint8_t *in1,
+const uint8_t *in2,
+uint8_t *out)
+{
+size_t i;
+for (i = 0; i < blocklen; i++) {
+out[i] = in1[i] ^ in2[i];
+}
+}
+
+
+static int qcrypto_afsplit_hash(QCryptoHashAlgorithm hash,
+size_t blocklen,
+uint8_t *block,
+Error **errp)
+{
+size_t digestlen = qcrypto_hash_digest_len(hash);
+
+size_t hashcount = blocklen / digestlen;
+size_t finallen = blocklen % digestlen;
+uint32_t i;
+
+if (finallen) {
+hashcount++;
+} else {
+finallen = blocklen;
+}
+
+for (i = 0; i < hashcount; i++) {
+uint8_t *out = NULL;
+size_t outlen = 0;
+uint32_t iv = cpu_to_be32(i);
+struct iovec in[] = {
+{ .iov_base = &iv,
+  .iov_len = sizeof(iv) },
+{ .iov_base = block + (i * digestlen),
+  .iov_len = (i == (hashcount - 1)) ? finallen : digestlen },
+};
+
+if (qcrypto_hash_bytesv(hash,
+in,
+G_N_ELEMENTS(in),
+&out, &outlen,
+errp) < 0) {
+return -1;
+}
+
+if (outlen != digestlen) {
+error_setg(errp, "Hash output %zu not %zu",
+   outlen, digestlen);
+g_free(out);
+return -1;
+}
+memcpy(block + (i * digestlen), out,
+   (i == (hashcount - 1)) ? finallen : digestlen);
+g_free(out);
+}
+
+return 0;
+}
+
+
+/**
+ * qcrypto_afsplit_encode:
+ * @hash: the hash function to use when splitting
+ * @blocklen: the length of @in in bytes
+ * @stripes: the number of stripes to split @in into
+ * @in: the input data, @blocklen bytes
+ * @out: the output data, @blocklen * @stripes bytes
+ * @errp: pointer to an uninitialized error object
+ *
+ * Transform the data (key material) in @in which is @blocklen
+ * bytes long, into data that is (@blocklen * @stripes)  bytes
+ * long. The caller is responsible for allocating @out with
+ * @blocklen * @stripes bytes of memory.
+ *
+ * Returns: 0 on success, -1 on error
+ */
+int qcrypto_afsplit_encode(QCryptoHashAlgorithm hash,
+   size_t blocklen,
+   uint32_t stripes,
+   const uint8_t *in,
+   uint8_t *out,
+   Error **errp)
+{
+uint8_t *block = g_new0(uint8_t, blocklen);
+size_t i;
+

[Qemu-devel] [PATCH v2 10/11] nvdimm acpi: add _CRS

[Xiao Guangrong]

As Igor suggested that we can report the BIOS patched operation region
so that OSPM could see that particular range is in use and be able to
notice conflicts if it happens some day

Signed-off-by: Xiao Guangrong 
---
 hw/acpi/nvdimm.c | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/hw/acpi/nvdimm.c b/hw/acpi/nvdimm.c
index d298da6..5e36bbd 100644
--- a/hw/acpi/nvdimm.c
+++ b/hw/acpi/nvdimm.c
@@ -565,6 +565,7 @@ static void nvdimm_build_ssdt(GSList *device_list, GArray 
*table_offsets,
   GArray *table_data, GArray *linker)
 {
 Aml *ssdt, *sb_scope, *dev, *field, *mem_addr;
+Aml *min_addr, *max_addr, *mr32, *method, *crs;
 uint32_t zero_offset = 0;
 int offset;
 
@@ -590,6 +591,32 @@ static void nvdimm_build_ssdt(GSList *device_list, GArray 
*table_offsets,
  */
 aml_append(dev, aml_name_decl("_HID", aml_string("ACPI0012")));
 
+/*
+ * report the dsm memory so that OSPM could see that particular range is
+ * in use and be able to notice conflicts if it happens some day.
+ */
+method = aml_method("_CRS", 0, AML_SERIALIZED);
+crs = aml_resource_template();
+aml_append(crs, aml_dword_memory(AML_POS_DECODE, AML_MIN_FIXED,
+ AML_MAX_FIXED, AML_CACHEABLE,
+ AML_READ_WRITE,
+ 0, 0x0, 0xFFFE, 0,
+ TARGET_PAGE_SIZE));
+aml_append(method, aml_name_decl("MR32", crs));
+mr32 = aml_name("MR32");
+aml_append(method, aml_create_dword_field(mr32, aml_int(10), "MIN"));
+aml_append(method, aml_create_dword_field(mr32, aml_int(14), "MAX"));
+
+min_addr = aml_name("MIN");
+max_addr = aml_name("MAX");
+
+aml_append(method, aml_store(aml_name(NVDIMM_ACPI_MEM_ADDR), min_addr));
+aml_append(method, aml_add(min_addr, aml_int(TARGET_PAGE_SIZE),
+   max_addr));
+aml_append(method, aml_decrement(max_addr));
+aml_append(method, aml_return(mr32));
+aml_append(dev, method);
+
 /* map DSM memory and IO into ACPI namespace. */
 aml_append(dev, aml_operation_region("NPIO", AML_SYSTEM_IO,
aml_int(NVDIMM_ACPI_IO_BASE), NVDIMM_ACPI_IO_LEN));
-- 
1.8.3.1

[Qemu-devel] [PATCH v2 06/11] nvdimm acpi: initialize the resource used by NVDIMM ACPI

[Xiao Guangrong]

32 bits IO port starting from 0x0a18 in guest is reserved for NVDIMM
ACPI emulation. The table, NVDIMM_DSM_MEM_FILE, will be patched into
NVDIMM ACPI binary code

OSPM uses this port to tell QEMU the final address of the DSM memory
and notify QEMU to emulate the DSM method

Signed-off-by: Xiao Guangrong 
---
 hw/acpi/Makefile.objs   |  2 +-
 hw/acpi/nvdimm.c| 35 +++
 hw/i386/acpi-build.c| 10 +-
 hw/i386/pc.c|  8 +---
 hw/i386/pc_piix.c   |  5 +
 hw/i386/pc_q35.c|  8 +++-
 include/hw/i386/pc.h|  5 -
 include/hw/mem/nvdimm.h | 28 +++-
 8 files changed, 85 insertions(+), 16 deletions(-)

diff --git a/hw/acpi/Makefile.objs b/hw/acpi/Makefile.objs
index f3ade9a..faee86c 100644
--- a/hw/acpi/Makefile.objs
+++ b/hw/acpi/Makefile.objs
@@ -2,7 +2,7 @@ common-obj-$(CONFIG_ACPI_X86) += core.o piix4.o pcihp.o
 common-obj-$(CONFIG_ACPI_X86_ICH) += ich9.o tco.o
 common-obj-$(CONFIG_ACPI_CPU_HOTPLUG) += cpu_hotplug.o cpu_hotplug_acpi_table.o
 common-obj-$(CONFIG_ACPI_MEMORY_HOTPLUG) += memory_hotplug.o 
memory_hotplug_acpi_table.o
-common-obj-$(CONFIG_ACPI_NVDIMM) += nvdimm.o
+obj-$(CONFIG_ACPI_NVDIMM) += nvdimm.o
 common-obj-$(CONFIG_ACPI) += acpi_interface.o
 common-obj-$(CONFIG_ACPI) += bios-linker-loader.o
 common-obj-$(CONFIG_ACPI) += aml-build.o
diff --git a/hw/acpi/nvdimm.c b/hw/acpi/nvdimm.c
index df1b176..256cedd 100644
--- a/hw/acpi/nvdimm.c
+++ b/hw/acpi/nvdimm.c
@@ -28,6 +28,7 @@
 
 #include "hw/acpi/acpi.h"
 #include "hw/acpi/aml-build.h"
+#include "hw/nvram/fw_cfg.h"
 #include "hw/mem/nvdimm.h"
 
 static int nvdimm_plugged_device_list(Object *obj, void *opaque)
@@ -369,6 +370,40 @@ static void nvdimm_build_nfit(GSList *device_list, GArray 
*table_offsets,
 g_array_free(structures, true);
 }
 
+static uint64_t
+nvdimm_dsm_read(void *opaque, hwaddr addr, unsigned size)
+{
+return 0;
+}
+
+static void
+nvdimm_dsm_write(void *opaque, hwaddr addr, uint64_t val, unsigned size)
+{
+}
+
+static const MemoryRegionOps nvdimm_dsm_ops = {
+.read = nvdimm_dsm_read,
+.write = nvdimm_dsm_write,
+.endianness = DEVICE_LITTLE_ENDIAN,
+.valid = {
+.min_access_size = 4,
+.max_access_size = 4,
+},
+};
+
+void nvdimm_init_acpi_state(AcpiNVDIMMState *state, MemoryRegion *io,
+FWCfgState *fw_cfg, Object *owner)
+{
+memory_region_init_io(&state->io_mr, owner, &nvdimm_dsm_ops, state,
+  "nvdimm-acpi-io", NVDIMM_ACPI_IO_LEN);
+memory_region_add_subregion(io, NVDIMM_ACPI_IO_BASE, &state->io_mr);
+
+state->dsm_mem = g_array_new(false, true /* clear */, 1);
+acpi_data_push(state->dsm_mem, TARGET_PAGE_SIZE);
+fw_cfg_add_file(fw_cfg, NVDIMM_DSM_MEM_FILE, state->dsm_mem->data,
+state->dsm_mem->len);
+}
+
 #define NVDIMM_COMMON_DSM  "NCAL"
 
 static void nvdimm_build_common_dsm(Aml *dev)
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index 1ca044f..c68cfb8 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -39,7 +39,6 @@
 #include "hw/loader.h"
 #include "hw/isa/isa.h"
 #include "hw/acpi/memory_hotplug.h"
-#include "hw/mem/nvdimm.h"
 #include "sysemu/tpm.h"
 #include "hw/acpi/tpm.h"
 #include "sysemu/tpm_backend.h"
@@ -2602,13 +2601,6 @@ static bool acpi_has_iommu(void)
 return intel_iommu && !ambiguous;
 }
 
-static bool acpi_has_nvdimm(void)
-{
-PCMachineState *pcms = PC_MACHINE(qdev_get_machine());
-
-return pcms->nvdimm;
-}
-
 static
 void acpi_build(PcGuestInfo *guest_info, AcpiBuildTables *tables)
 {
@@ -2692,7 +2684,7 @@ void acpi_build(PcGuestInfo *guest_info, AcpiBuildTables 
*tables)
 build_dmar_q35(tables_blob, tables->linker);
 }
 
-if (acpi_has_nvdimm()) {
+if (guest_info->has_nvdimm) {
 nvdimm_build_acpi(table_offsets, tables_blob, tables->linker);
 }
 
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index c36b8cf..397de28 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1228,6 +1228,8 @@ PcGuestInfo *pc_guest_info_init(PCMachineState *pcms)
 }
 }
 
+guest_info->has_nvdimm = pcms->acpi_nvdimm_state.is_enabled;
+
 guest_info_state->machine_done.notify = pc_guest_info_machine_done;
 qemu_add_machine_init_done_notifier(&guest_info_state->machine_done);
 return guest_info;
@@ -1877,14 +1879,14 @@ static bool pc_machine_get_nvdimm(Object *obj, Error 
**errp)
 {
 PCMachineState *pcms = PC_MACHINE(obj);
 
-return pcms->nvdimm;
+return pcms->acpi_nvdimm_state.is_enabled;
 }
 
 static void pc_machine_set_nvdimm(Object *obj, bool value, Error **errp)
 {
 PCMachineState *pcms = PC_MACHINE(obj);
 
-pcms->nvdimm = value;
+pcms->acpi_nvdimm_state.is_enabled = value;
 }
 
 static void pc_machine_initfn(Object *obj)
@@ -1923,7 +1925,7 @@ static void pc_machine_initfn(Object *obj)
 &error_abort);
 
 /* nvdimm is disabled on default. */
-  

[Qemu-devel] [PATCH v2 09/11] nvdimm acpi: emulate dsm method

[Xiao Guangrong]

Emulate dsm method after IO VM-exit

Currently, we only introduce the framework and no function is actually
supported

Signed-off-by: Xiao Guangrong 
---
 hw/acpi/aml-build.c |  2 +-
 hw/acpi/nvdimm.c| 44 
 include/hw/acpi/aml-build.h |  1 +
 include/hw/mem/nvdimm.h |  8 
 4 files changed, 54 insertions(+), 1 deletion(-)

diff --git a/hw/acpi/aml-build.c b/hw/acpi/aml-build.c
index 208f22e..e9841be 100644
--- a/hw/acpi/aml-build.c
+++ b/hw/acpi/aml-build.c
@@ -231,7 +231,7 @@ static void build_extop_package(GArray *package, uint8_t op)
 build_prepend_byte(package, 0x5B); /* ExtOpPrefix */
 }
 
-static void build_append_int_noprefix(GArray *table, uint64_t value, int size)
+void build_append_int_noprefix(GArray *table, uint64_t value, int size)
 {
 int i;
 
diff --git a/hw/acpi/nvdimm.c b/hw/acpi/nvdimm.c
index 358e340..d298da6 100644
--- a/hw/acpi/nvdimm.c
+++ b/hw/acpi/nvdimm.c
@@ -392,12 +392,56 @@ typedef struct NvdimmDsmOut NvdimmDsmOut;
 static uint64_t
 nvdimm_dsm_read(void *opaque, hwaddr addr, unsigned size)
 {
+fprintf(stderr, "BUG: we never read _DSM IO Port.\n");
 return 0;
 }
 
 static void
 nvdimm_dsm_write(void *opaque, hwaddr addr, uint64_t val, unsigned size)
 {
+NvdimmDsmIn *in;
+GArray *out;
+uint32_t buf_size;
+hwaddr dsm_mem_addr = val;
+
+nvdimm_debug("dsm memory address %#lx.\n", dsm_mem_addr);
+
+/*
+ * The DSM memory is mapped to guest address space so an evil guest
+ * can change its content while we are doing DSM emulation. Avoid
+ * this by copying DSM memory to QEMU local memory.
+ */
+in = g_malloc(TARGET_PAGE_SIZE);
+cpu_physical_memory_read(dsm_mem_addr, in, TARGET_PAGE_SIZE);
+
+le32_to_cpus(&in->revision);
+le32_to_cpus(&in->function);
+le32_to_cpus(&in->handle);
+
+nvdimm_debug("Revision %#x Handler %#x Function %#x.\n", in->revision,
+ in->handle, in->function);
+
+out = g_array_new(false, true /* clear */, 1);
+
+/*
+ * function 0 is called to inquire what functions are supported by
+ * OSPM
+ */
+if (in->function == 0) {
+build_append_int_noprefix(out, 0 /* No function Supported */,
+  sizeof(uint8_t));
+} else {
+/* No function is supported yet. */
+build_append_int_noprefix(out, 1 /* Not Supported */,
+  sizeof(uint8_t));
+}
+
+buf_size = cpu_to_le32(out->len);
+cpu_physical_memory_write(dsm_mem_addr, &buf_size, sizeof(buf_size));
+cpu_physical_memory_write(dsm_mem_addr + sizeof(buf_size), out->data,
+  out->len);
+g_free(in);
+g_array_free(out, true);
 }
 
 static const MemoryRegionOps nvdimm_dsm_ops = {
diff --git a/include/hw/acpi/aml-build.h b/include/hw/acpi/aml-build.h
index 7c8db8f..c5715c4 100644
--- a/include/hw/acpi/aml-build.h
+++ b/include/hw/acpi/aml-build.h
@@ -356,6 +356,7 @@ Aml *aml_derefof(Aml *arg);
 Aml *aml_sizeof(Aml *arg);
 Aml *aml_concatenate(Aml *source1, Aml *source2, Aml *target);
 
+void build_append_int_noprefix(GArray *table, uint64_t value, int size);
 void
 build_header(GArray *linker, GArray *table_data,
  AcpiTableHeader *h, const char *sig, int len, uint8_t rev,
diff --git a/include/hw/mem/nvdimm.h b/include/hw/mem/nvdimm.h
index 634c60b..aaa2608 100644
--- a/include/hw/mem/nvdimm.h
+++ b/include/hw/mem/nvdimm.h
@@ -25,6 +25,14 @@
 
 #include "hw/mem/pc-dimm.h"
 
+#define NVDIMM_DEBUG 0
+#define nvdimm_debug(fmt, ...)\
+do {  \
+if (NVDIMM_DEBUG) {   \
+fprintf(stderr, "nvdimm: " fmt, ## __VA_ARGS__);  \
+} \
+} while (0)
+
 #define TYPE_NVDIMM "nvdimm"
 
 #define NVDIMM_DSM_MEM_FILE "etc/acpi/nvdimm-mem"
-- 
1.8.3.1

[Qemu-devel] [PATCH v1 15/15] block: remove support for legecy AES qcow/qcow2 encryption

[Daniel P. Berrange]

Refuse to use images with the legacy AES-CBC encryption
format in the system emulators. They are still fully
supported in the qemu-img, qemu-io & qemu-nbd tools in
order to allow data to be liberated and for compatibility
with older QEMU versions. Continued support in these tools
is not a notable burden with the new FDE framework.

Signed-off-by: Daniel P. Berrange 
---
 block.c| 12 +---
 block/qcow.c   |  8 
 block/qcow2.c  |  8 
 include/block/block.h  |  1 +
 tests/qemu-iotests/087.out | 18 --
 tests/qemu-iotests/134.out | 18 --
 6 files changed, 22 insertions(+), 43 deletions(-)

diff --git a/block.c b/block.c
index d123cbc..ebf2fec 100644
--- a/block.c
+++ b/block.c
@@ -312,6 +312,11 @@ static int bdrv_is_whitelisted(BlockDriver *drv, bool 
read_only)
 return 0;
 }
 
+bool bdrv_uses_whitelist(void)
+{
+return use_bdrv_whitelist;
+}
+
 typedef struct CreateCo {
 BlockDriver *drv;
 char *filename;
@@ -1020,13 +1025,6 @@ static int bdrv_open_common(BlockDriverState *bs, 
BdrvChild *file,
 goto free_and_fail;
 }
 
-if (bs->encrypted) {
-error_report("Encrypted images are deprecated");
-error_printf("Support for them will be removed in a future release.\n"
- "You can use 'qemu-img convert' to convert your image"
- " to an unencrypted one.\n");
-}
-
 ret = refresh_total_sectors(bs, bs->total_sectors);
 if (ret < 0) {
 error_setg_errno(errp, -ret, "Could not refresh total sector count");
diff --git a/block/qcow.c b/block/qcow.c
index a17531f..cda187a 100644
--- a/block/qcow.c
+++ b/block/qcow.c
@@ -180,6 +180,14 @@ static int qcow_open(BlockDriverState *bs, QDict *options, 
int flags,
 s->crypt_method_header = header.crypt_method;
 if (s->crypt_method_header) {
 if (s->crypt_method_header == QCOW_CRYPT_AES) {
+if (bdrv_uses_whitelist()) {
+error_setg(errp,
+   "Use of AES-CBC encrypted qcow images is no longer "
+   "supported. Please use the qcow2 LUKS format 
instead.");
+ret = -ENOSYS;
+goto fail;
+}
+
 ov = opts_visitor_new(opts);
 
 fde_opts = g_new0(QCryptoBlockOpenOptions, 1);
diff --git a/block/qcow2.c b/block/qcow2.c
index 288aada..f0efc0f 100644
--- a/block/qcow2.c
+++ b/block/qcow2.c
@@ -1221,6 +1221,14 @@ static int qcow2_open(BlockDriverState *bs, QDict 
*options, int flags,
 
 s->crypt_method_header = header.crypt_method;
 if (s->crypt_method_header) {
+if (bdrv_uses_whitelist() &&
+s->crypt_method_header == QCOW_CRYPT_AES) {
+error_setg(errp,
+   "Use of AES-CBC encrypted qcow2 images is no longer "
+   "supported. Please use the qcow2 LUKS format instead.");
+ret = -ENOSYS;
+goto fail;
+}
 bs->encrypted = 1;
 }
 
diff --git a/include/block/block.h b/include/block/block.h
index 379a24c..58006d2 100644
--- a/include/block/block.h
+++ b/include/block/block.h
@@ -190,6 +190,7 @@ void bdrv_io_limits_update_group(BlockDriverState *bs, 
const char *group);
 
 void bdrv_init(void);
 void bdrv_init_with_whitelist(void);
+bool bdrv_uses_whitelist(void);
 BlockDriver *bdrv_find_protocol(const char *filename,
 bool allow_protocol_prefix,
 Error **errp);
diff --git a/tests/qemu-iotests/087.out b/tests/qemu-iotests/087.out
index 2b55b1b..19a54c5 100644
--- a/tests/qemu-iotests/087.out
+++ b/tests/qemu-iotests/087.out
@@ -38,20 +38,11 @@ QMP_VERSION
 
 === Encrypted image ===
 
-qemu-img: Encrypted images are deprecated
-Support for them will be removed in a future release.
-You can use 'qemu-img convert' to convert your image to an unencrypted one.
-qemu-img: Encrypted images are deprecated
-Support for them will be removed in a future release.
-You can use 'qemu-img convert' to convert your image to an unencrypted one.
 Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=134217728 encryption=on
 Testing: -S
 QMP_VERSION
 {"return": {}}
 {"return": {}}
-Encrypted images are deprecated
-Support for them will be removed in a future release.
-You can use 'qemu-img convert' to convert your image to an unencrypted one.
 {"return": {}}
 {"return": {}}
 {"timestamp": {"seconds":  TIMESTAMP, "microseconds":  TIMESTAMP}, "event": 
"SHUTDOWN"}
@@ -60,9 +51,6 @@ Testing:
 QMP_VERSION
 {"return": {}}
 {"return": {}}
-Encrypted images are deprecated
-Support for them will be removed in a future release.
-You can use 'qemu-img convert' to convert your image to an unencrypted one.
 {"return": {}}
 {"return": {}}
 {"timestamp": {"seconds":  TIMESTAMP, "microseconds":  TIMESTAMP}, "event": 
"SHUTDOWN"}
@@ -70,12 +58,6 @@ You can use 'qemu-img convert' to convert your image to a

[Qemu-devel] [PATCH v2 03/11] acpi: add aml_create_field()

[Xiao Guangrong]

It will be used by nvdimm acpi

Signed-off-by: Xiao Guangrong 
---
 hw/acpi/aml-build.c | 13 +
 include/hw/acpi/aml-build.h |  1 +
 2 files changed, 14 insertions(+)

diff --git a/hw/acpi/aml-build.c b/hw/acpi/aml-build.c
index 78e1290..97c9efb 100644
--- a/hw/acpi/aml-build.c
+++ b/hw/acpi/aml-build.c
@@ -1001,6 +1001,19 @@ Aml *create_field_common(int opcode, Aml *srcbuf, Aml 
*index, const char *name)
 return var;
 }
 
+/* ACPI 1.0b: 16.2.5.2 Named Objects Encoding: DefCreateField */
+Aml *aml_create_field(Aml *srcbuf, Aml *index, Aml *len, const char *name)
+{
+Aml *var = aml_alloc();
+build_append_byte(var->buf, 0x5B); /* ExtOpPrefix */
+build_append_byte(var->buf, 0x13); /* CreateFieldOp */
+aml_append(var, srcbuf);
+aml_append(var, index);
+aml_append(var, len);
+build_append_namestring(var->buf, "%s", name);
+return var;
+}
+
 /* ACPI 1.0b: 16.2.5.2 Named Objects Encoding: DefCreateDWordField */
 Aml *aml_create_dword_field(Aml *srcbuf, Aml *index, const char *name)
 {
diff --git a/include/hw/acpi/aml-build.h b/include/hw/acpi/aml-build.h
index 6d6f705..e1ba534 100644
--- a/include/hw/acpi/aml-build.h
+++ b/include/hw/acpi/aml-build.h
@@ -346,6 +346,7 @@ Aml *aml_mutex(const char *name, uint8_t sync_level);
 Aml *aml_acquire(Aml *mutex, uint16_t timeout);
 Aml *aml_release(Aml *mutex);
 Aml *aml_alias(const char *source_object, const char *alias_object);
+Aml *aml_create_field(Aml *srcbuf, Aml *index, Aml *len, const char *name);
 Aml *aml_create_dword_field(Aml *srcbuf, Aml *index, const char *name);
 Aml *aml_create_qword_field(Aml *srcbuf, Aml *index, const char *name);
 Aml *aml_varpackage(uint32_t num_elements);
-- 
1.8.3.1

[Qemu-devel] [PATCH v2 07/11] nvdimm acpi: introduce patched dsm memory

[Xiao Guangrong]

The dsm memory is used to save the input parameters and store
the dsm result which is filled by QEMU.

The address of dsm memory is decided by bios and patched into
int32 object named "MEMA"

Signed-off-by: Xiao Guangrong 
---
 hw/acpi/nvdimm.c | 34 +-
 1 file changed, 33 insertions(+), 1 deletion(-)

diff --git a/hw/acpi/nvdimm.c b/hw/acpi/nvdimm.c
index 256cedd..e7acc98 100644
--- a/hw/acpi/nvdimm.c
+++ b/hw/acpi/nvdimm.c
@@ -28,6 +28,7 @@
 
 #include "hw/acpi/acpi.h"
 #include "hw/acpi/aml-build.h"
+#include "hw/acpi/bios-linker-loader.h"
 #include "hw/nvram/fw_cfg.h"
 #include "hw/mem/nvdimm.h"
 
@@ -405,6 +406,7 @@ void nvdimm_init_acpi_state(AcpiNVDIMMState *state, 
MemoryRegion *io,
 }
 
 #define NVDIMM_COMMON_DSM  "NCAL"
+#define NVDIMM_ACPI_MEM_ADDR   "MEMA"
 
 static void nvdimm_build_common_dsm(Aml *dev)
 {
@@ -469,7 +471,9 @@ static void nvdimm_build_nvdimm_devices(GSList 
*device_list, Aml *root_dev)
 static void nvdimm_build_ssdt(GSList *device_list, GArray *table_offsets,
   GArray *table_data, GArray *linker)
 {
-Aml *ssdt, *sb_scope, *dev;
+Aml *ssdt, *sb_scope, *dev, *mem_addr;
+uint32_t zero_offset = 0;
+int offset;
 
 acpi_add_table(table_offsets, table_data);
 
@@ -500,9 +504,37 @@ static void nvdimm_build_ssdt(GSList *device_list, GArray 
*table_offsets,
 
 aml_append(sb_scope, dev);
 
+/*
+ * leave it at the end of ssdt so that we can conveniently get the
+ * offset of int32 object which will be patched with the real address
+ * of the dsm memory by BIOS.
+ *
+ * 0x3200 is the magic number to let aml_int() create int32 object.
+ * It will be zeroed later to make bios_linker_loader_add_pointer()
+ * happy.
+ */
+mem_addr = aml_name_decl(NVDIMM_ACPI_MEM_ADDR, aml_int(0x3200));
+
+aml_append(sb_scope, mem_addr);
 aml_append(ssdt, sb_scope);
 /* copy AML table into ACPI tables blob and patch header there */
 g_array_append_vals(table_data, ssdt->buf->data, ssdt->buf->len);
+
+offset = table_data->len - 4;
+
+/*
+ * zero the last 4 bytes, i.e, it is the offset of
+ * NVDIMM_ACPI_MEM_ADDR object.
+ */
+g_array_remove_range(table_data, offset, 4);
+g_array_append_vals(table_data, &zero_offset, 4);
+
+bios_linker_loader_alloc(linker, NVDIMM_DSM_MEM_FILE, TARGET_PAGE_SIZE,
+ false /* high memory */);
+bios_linker_loader_add_pointer(linker, ACPI_BUILD_TABLE_FILE,
+   NVDIMM_DSM_MEM_FILE, table_data,
+   table_data->data + offset,
+   sizeof(uint32_t));
 build_header(linker, table_data,
 (void *)(table_data->data + table_data->len - ssdt->buf->len),
 "SSDT", ssdt->buf->len, 1, "NVDIMM");
-- 
1.8.3.1

[Qemu-devel] [PATCH v1 12/15] qcow: convert QCow to use QCryptoBlock for encryption

[Daniel P. Berrange]

This converts the qcow2 driver to make use of the QCryptoBlock
APIs for encrypting image content. This is only wired up to
permit use of the legacy QCow encryption format. Users who wish
to have the strong LUKS format should switch to qcow2 instead.

With this change it is now required to use the QCryptoSecret
object for providing passwords, instead of the current block
password APIs / interactive prompting.

  $QEMU \
-object secret,id=sec0,filename=/home/berrange/encrypted.pw \
-drive file=/home/berrange/encrypted.qcow,key-id=sec0

Signed-off-by: Daniel P. Berrange 
---
 block/qcow.c | 176 +++
 qapi/block-core.json |  17 -
 2 files changed, 96 insertions(+), 97 deletions(-)

diff --git a/block/qcow.c b/block/qcow.c
index 5a4f310..a17531f 100644
--- a/block/qcow.c
+++ b/block/qcow.c
@@ -26,7 +26,9 @@
 #include "qemu/module.h"
 #include 
 #include "qapi/qmp/qerror.h"
-#include "crypto/cipher.h"
+#include "crypto/block.h"
+#include "qapi/opts-visitor.h"
+#include "qapi-visit.h"
 #include "migration/migration.h"
 
 /**/
@@ -40,6 +42,8 @@
 
 #define QCOW_OFLAG_COMPRESSED (1LL << 63)
 
+#define QCOW_OPT_KEY_ID "key-id"
+
 typedef struct QCowHeader {
 uint32_t magic;
 uint32_t version;
@@ -72,7 +76,7 @@ typedef struct BDRVQcowState {
 uint8_t *cluster_cache;
 uint8_t *cluster_data;
 uint64_t cluster_cache_offset;
-QCryptoCipher *cipher; /* NULL if no key yet */
+QCryptoBlock *fde; /* Disk encryption format driver */
 uint32_t crypt_method_header;
 CoMutex lock;
 Error *migration_blocker;
@@ -92,6 +96,19 @@ static int qcow_probe(const uint8_t *buf, int buf_size, 
const char *filename)
 return 0;
 }
 
+static QemuOptsList qcow_runtime_opts = {
+.name = "qcow",
+.head = QTAILQ_HEAD_INITIALIZER(qcow_runtime_opts.head),
+.desc = {
+{
+.name = QCOW_OPT_KEY_ID,
+.type = QEMU_OPT_STRING,
+.help = "ID of the secret that provides the encryption key",
+},
+{ /* end of list */ }
+},
+};
+
 static int qcow_open(BlockDriverState *bs, QDict *options, int flags,
  Error **errp)
 {
@@ -99,6 +116,11 @@ static int qcow_open(BlockDriverState *bs, QDict *options, 
int flags,
 unsigned int len, i, shift;
 int ret;
 QCowHeader header;
+QemuOpts *opts = NULL;
+Error *local_err = NULL;
+QCryptoBlockOpenOptions *fde_opts = NULL;
+unsigned int cflags = 0;
+OptsVisitor *ov;
 
 ret = bdrv_pread(bs->file->bs, 0, &header, sizeof(header));
 if (ret < 0) {
@@ -147,18 +169,50 @@ static int qcow_open(BlockDriverState *bs, QDict 
*options, int flags,
 goto fail;
 }
 
-if (header.crypt_method > QCOW_CRYPT_AES) {
-error_setg(errp, "invalid encryption method in qcow header");
-ret = -EINVAL;
-goto fail;
-}
-if (!qcrypto_cipher_supports(QCRYPTO_CIPHER_ALG_AES_128)) {
-error_setg(errp, "AES cipher not available");
+opts = qemu_opts_create(&qcow_runtime_opts, NULL, 0, &error_abort);
+qemu_opts_absorb_qdict(opts, options, &local_err);
+if (local_err) {
+error_propagate(errp, local_err);
 ret = -EINVAL;
 goto fail;
 }
+
 s->crypt_method_header = header.crypt_method;
 if (s->crypt_method_header) {
+if (s->crypt_method_header == QCOW_CRYPT_AES) {
+ov = opts_visitor_new(opts);
+
+fde_opts = g_new0(QCryptoBlockOpenOptions, 1);
+fde_opts->format = Q_CRYPTO_BLOCK_FORMAT_QCOWAES;
+fde_opts->u.qcowaes = g_new0(QCryptoBlockOptionsQCowAES, 1);
+visit_type_QCryptoBlockOptionsQCowAES(opts_get_visitor(ov),
+  &fde_opts->u.qcowaes,
+  "qcowaes", &local_err);
+if (local_err) {
+error_propagate(errp, local_err);
+opts_visitor_cleanup(ov);
+ret = -EINVAL;
+goto fail;
+}
+opts_visitor_cleanup(ov);
+
+if (flags & BDRV_O_NO_IO) {
+cflags |= QCRYPTO_BLOCK_OPEN_NO_IO;
+}
+s->fde = qcrypto_block_open(fde_opts,
+NULL, NULL,
+cflags,
+errp);
+if (!s->fde) {
+error_setg(errp, "Could not setup encryption layer");
+ret = -EINVAL;
+goto fail;
+}
+} else {
+error_setg(errp, "invalid encryption method in qcow header");
+ret = -EINVAL;
+goto fail;
+}
 bs->encrypted = 1;
 }
 s->cluster_bits = header.cluster_bits;
@@ -238,6 +292,7 @@ static int qcow_open(BlockDriverState *bs, QDict *options, 
int flags,
   

[Qemu-devel] [PATCH v2 05/11] acpi: allow using object as offset for OperationRegion

[Xiao Guangrong]

Extend aml_operation_region() to use object as offset

Signed-off-by: Xiao Guangrong 
---
 hw/acpi/aml-build.c |  4 ++--
 hw/i386/acpi-build.c| 31 ---
 include/hw/acpi/aml-build.h |  2 +-
 3 files changed, 19 insertions(+), 18 deletions(-)

diff --git a/hw/acpi/aml-build.c b/hw/acpi/aml-build.c
index 421dd84..208f22e 100644
--- a/hw/acpi/aml-build.c
+++ b/hw/acpi/aml-build.c
@@ -946,14 +946,14 @@ Aml *aml_package(uint8_t num_elements)
 
 /* ACPI 1.0b: 16.2.5.2 Named Objects Encoding: DefOpRegion */
 Aml *aml_operation_region(const char *name, AmlRegionSpace rs,
-  uint32_t offset, uint32_t len)
+  Aml *offset, uint32_t len)
 {
 Aml *var = aml_alloc();
 build_append_byte(var->buf, 0x5B); /* ExtOpPrefix */
 build_append_byte(var->buf, 0x80); /* OpRegionOp */
 build_append_namestring(var->buf, "%s", name);
 build_append_byte(var->buf, rs);
-build_append_int(var->buf, offset);
+aml_append(var, offset);
 build_append_int(var->buf, len);
 return var;
 }
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index 78758e2..1ca044f 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -993,7 +993,7 @@ static void build_processor_devices(Aml *sb_scope, unsigned 
acpi_cpus,
 aml_append(sb_scope, dev);
 /* declare CPU hotplug MMIO region and PRS field to access it */
 aml_append(sb_scope, aml_operation_region(
-"PRST", AML_SYSTEM_IO, pm->cpu_hp_io_base, pm->cpu_hp_io_len));
+"PRST", AML_SYSTEM_IO, aml_int(pm->cpu_hp_io_base), 
pm->cpu_hp_io_len));
 field = aml_field("PRST", AML_BYTE_ACC, AML_NOLOCK, AML_PRESERVE);
 aml_append(field, aml_named_field("PRS", 256));
 aml_append(sb_scope, field);
@@ -1078,7 +1078,7 @@ static void build_memory_devices(Aml *sb_scope, int 
nr_mem,
 
 aml_append(scope, aml_operation_region(
 MEMORY_HOTPLUG_IO_REGION, AML_SYSTEM_IO,
-io_base, io_len)
+aml_int(io_base), io_len)
 );
 
 field = aml_field(MEMORY_HOTPLUG_IO_REGION, AML_DWORD_ACC,
@@ -1192,7 +1192,8 @@ static void build_hpet_aml(Aml *table)
 aml_append(dev, aml_name_decl("_UID", zero));
 
 aml_append(dev,
-aml_operation_region("HPTM", AML_SYSTEM_MEMORY, HPET_BASE, HPET_LEN));
+aml_operation_region("HPTM", AML_SYSTEM_MEMORY, aml_int(HPET_BASE),
+ HPET_LEN));
 field = aml_field("HPTM", AML_DWORD_ACC, AML_LOCK, AML_PRESERVE);
 aml_append(field, aml_named_field("VEND", 32));
 aml_append(field, aml_named_field("PRD", 32));
@@ -1430,7 +1431,7 @@ static void build_dbg_aml(Aml *table)
 Aml *idx = aml_local(2);
 
 aml_append(scope,
-   aml_operation_region("DBG", AML_SYSTEM_IO, 0x0402, 0x01));
+   aml_operation_region("DBG", AML_SYSTEM_IO, aml_int(0x0402), 0x01));
 field = aml_field("DBG", AML_BYTE_ACC, AML_NOLOCK, AML_PRESERVE);
 aml_append(field, aml_named_field("DBGB", 8));
 aml_append(scope, field);
@@ -1770,10 +1771,10 @@ static void build_q35_isa_bridge(Aml *table)
 
 /* ICH9 PCI to ISA irq remapping */
 aml_append(dev, aml_operation_region("PIRQ", AML_PCI_CONFIG,
- 0x60, 0x0C));
+ aml_int(0x60), 0x0C));
 
 aml_append(dev, aml_operation_region("LPCD", AML_PCI_CONFIG,
- 0x80, 0x02));
+ aml_int(0x80), 0x02));
 field = aml_field("LPCD", AML_ANY_ACC, AML_NOLOCK, AML_PRESERVE);
 aml_append(field, aml_named_field("COMA", 3));
 aml_append(field, aml_reserved_field(1));
@@ -1785,7 +1786,7 @@ static void build_q35_isa_bridge(Aml *table)
 aml_append(dev, field);
 
 aml_append(dev, aml_operation_region("LPCE", AML_PCI_CONFIG,
- 0x82, 0x02));
+ aml_int(0x82), 0x02));
 /* enable bits */
 field = aml_field("LPCE", AML_ANY_ACC, AML_NOLOCK, AML_PRESERVE);
 aml_append(field, aml_named_field("CAEN", 1));
@@ -1808,7 +1809,7 @@ static void build_piix4_pm(Aml *table)
 aml_append(dev, aml_name_decl("_ADR", aml_int(0x00010003)));
 
 aml_append(dev, aml_operation_region("P13C", AML_PCI_CONFIG,
- 0x00, 0xff));
+ aml_int(0x00), 0xff));
 aml_append(scope, dev);
 aml_append(table, scope);
 }
@@ -1825,7 +1826,7 @@ static void build_piix4_isa_bridge(Aml *table)
 
 /* PIIX PCI to ISA irq remapping */
 aml_append(dev, aml_operation_region("P40C", AML_PCI_CONFIG,
- 0x60, 0x04));
+ aml_int(0x60), 0x04));
 /* enable bits */
 field = aml_field("^PX13.P13C", AML_ANY_ACC, AML_NOLOCK, AML_PRESERVE);
 /* Offset(0x5f),, 7, */
@@ -1854,20 +1855,20 @@ static void build_piix4_pci_hotplug(Aml *table)
 s

[Qemu-devel] [PATCH v1 05/15] crypto: add block encryption framework

[Daniel P. Berrange]

Add a generic framework for support different block encryption
formats. Upon instantiating a QCryptoBlock object, it will read
the encryption header and extract the encryption keys. It is
then possible to call methods to encrypt/decrypt data buffers.

There is also a mode whereby it will create/initialize a new
encryption header on a previously unformatted volume.

The initial framework comes with support for the legacy QCow
AES based encryption. This enables code in the QCow driver to
be consolidated later.

Signed-off-by: Daniel P. Berrange 
---
 crypto/Makefile.objs   |   2 +
 crypto/block-qcowaes.c | 165 
 crypto/block-qcowaes.h |  28 ++
 crypto/block.c | 254 +
 crypto/blockpriv.h |  89 +
 include/crypto/block.h | 222 ++
 qapi/crypto.json   |  65 +
 7 files changed, 825 insertions(+)
 create mode 100644 crypto/block-qcowaes.c
 create mode 100644 crypto/block-qcowaes.h
 create mode 100644 crypto/block.c
 create mode 100644 crypto/blockpriv.h
 create mode 100644 include/crypto/block.h

diff --git a/crypto/Makefile.objs b/crypto/Makefile.objs
index 1e08a3a..b5b32a6 100644
--- a/crypto/Makefile.objs
+++ b/crypto/Makefile.objs
@@ -15,6 +15,8 @@ crypto-obj-y += ivgen-essiv.o
 crypto-obj-y += ivgen-plain.o
 crypto-obj-y += ivgen-plain64.o
 crypto-obj-y += afsplit.o
+crypto-obj-y += block.o
+crypto-obj-y += block-qcowaes.o
 
 # Let the userspace emulators avoid linking gnutls/etc
 crypto-aes-obj-y = aes.o
diff --git a/crypto/block-qcowaes.c b/crypto/block-qcowaes.c
new file mode 100644
index 000..cf8ff50
--- /dev/null
+++ b/crypto/block-qcowaes.c
@@ -0,0 +1,165 @@
+/*
+ * QEMU Crypto block device encryption QCOWAES format
+ *
+ * Copyright (c) 2015 Red Hat, Inc.
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see .
+ *
+ */
+
+#include "config-host.h"
+
+#include "crypto/block-qcowaes.h"
+#include "crypto/secret.h"
+
+static gboolean
+qcrypto_block_qcowaes_has_format(const uint8_t *buf G_GNUC_UNUSED,
+ size_t buf_size G_GNUC_UNUSED)
+{
+return false;
+}
+
+
+static int
+qcrypto_block_qcowaes_init(QCryptoBlock *block,
+   const char *keyid,
+   Error **errp)
+{
+char *password;
+int ret;
+uint8_t keybuf[16];
+int len, i;
+
+memset(keybuf, 0, 16);
+
+password = qcrypto_secret_lookup_as_utf8(keyid, errp);
+if (!password) {
+return -1;
+}
+
+len = strlen(password);
+if (len > 16) {
+len = 16;
+}
+for (i = 0; i < len; i++) {
+keybuf[i] = password[i];
+}
+g_free(password);
+
+block->niv = qcrypto_cipher_get_iv_len(QCRYPTO_CIPHER_ALG_AES_128,
+   QCRYPTO_CIPHER_MODE_CBC);
+block->ivgen = qcrypto_ivgen_new(QCRYPTO_IVGEN_ALG_PLAIN64,
+ 0, 0, NULL, 0, errp);
+if (!block->ivgen) {
+ret = -ENOTSUP;
+goto fail;
+}
+
+block->cipher = qcrypto_cipher_new(QCRYPTO_CIPHER_ALG_AES_128,
+   QCRYPTO_CIPHER_MODE_CBC,
+   keybuf, G_N_ELEMENTS(keybuf),
+   errp);
+if (!block->cipher) {
+ret = -ENOTSUP;
+goto fail;
+}
+
+block->payload_offset = 0;
+
+return 0;
+
+ fail:
+qcrypto_cipher_free(block->cipher);
+qcrypto_ivgen_free(block->ivgen);
+return ret;
+}
+
+
+static int
+qcrypto_block_qcowaes_open(QCryptoBlock *block,
+   QCryptoBlockOpenOptions *options,
+   QCryptoBlockReadFunc readfunc G_GNUC_UNUSED,
+   void *opaque G_GNUC_UNUSED,
+   unsigned int flags,
+   Error **errp)
+{
+if (flags & QCRYPTO_BLOCK_OPEN_NO_IO) {
+return 0;
+} else {
+if (!options->u.qcowaes->key_id) {
+error_setg(errp, "Parameter 'key-id' is required to initialize 
cipher");
+return -1;
+}
+return qcrypto_block_qcowaes_init(block, options->u.qcowaes->key_id, 
errp);
+}
+}
+
+
+static int
+qcrypto_block_qcowaes_create(QCryptoBlock *block,
+ QCry

[Qemu-devel] [PATCH v1 11/15] qcow: make encrypt_sectors encrypt in place

[Daniel P. Berrange]

Instead of requiring separate input/output buffers for
encrypting data, change encrypt_sectors() to assume
use of a single buffer, encrypting in place. One current
caller all uses the same buffer for input/output already
and the other two callers are easily converted todo so.

Signed-off-by: Daniel P. Berrange 
---
 block/qcow.c | 31 ++-
 1 file changed, 10 insertions(+), 21 deletions(-)

diff --git a/block/qcow.c b/block/qcow.c
index 635085e..5a4f310 100644
--- a/block/qcow.c
+++ b/block/qcow.c
@@ -293,12 +293,9 @@ static int qcow_set_key(BlockDriverState *bs, const char 
*key)
 return 0;
 }
 
-/* The crypt function is compatible with the linux cryptoloop
-   algorithm for < 4 GB images. NOTE: out_buf == in_buf is
-   supported */
 static int encrypt_sectors(BDRVQcowState *s, int64_t sector_num,
-   uint8_t *out_buf, const uint8_t *in_buf,
-   int nb_sectors, bool enc, Error **errp)
+   uint8_t *buf, int nb_sectors, bool enc,
+   Error **errp)
 {
 union {
 uint64_t ll[2];
@@ -317,14 +314,12 @@ static int encrypt_sectors(BDRVQcowState *s, int64_t 
sector_num,
 }
 if (enc) {
 ret = qcrypto_cipher_encrypt(s->cipher,
- in_buf,
- out_buf,
+ buf, buf,
  512,
  errp);
 } else {
 ret = qcrypto_cipher_decrypt(s->cipher,
- in_buf,
- out_buf,
+ buf, buf,
  512,
  errp);
 }
@@ -332,8 +327,7 @@ static int encrypt_sectors(BDRVQcowState *s, int64_t 
sector_num,
 return -1;
 }
 sector_num++;
-in_buf += 512;
-out_buf += 512;
+buf += 512;
 }
 return 0;
 }
@@ -453,13 +447,12 @@ static uint64_t get_cluster_offset(BlockDriverState *bs,
 uint64_t start_sect;
 assert(s->cipher);
 start_sect = (offset & ~(s->cluster_size - 1)) >> 9;
-memset(s->cluster_data + 512, 0x00, 512);
+memset(s->cluster_data, 0x00, 512);
 for(i = 0; i < s->cluster_sectors; i++) {
 if (i < n_start || i >= n_end) {
 Error *err = NULL;
 if (encrypt_sectors(s, start_sect + i,
-s->cluster_data,
-s->cluster_data + 512, 1,
+s->cluster_data, 1,
 true, &err) < 0) {
 error_free(err);
 errno = EIO;
@@ -637,7 +630,7 @@ static coroutine_fn int qcow_co_readv(BlockDriverState *bs, 
int64_t sector_num,
 }
 if (bs->encrypted) {
 assert(s->cipher);
-if (encrypt_sectors(s, sector_num, buf, buf,
+if (encrypt_sectors(s, sector_num, buf,
 n, false, &err) < 0) {
 goto fail;
 }
@@ -672,7 +665,6 @@ static coroutine_fn int qcow_co_writev(BlockDriverState 
*bs, int64_t sector_num,
 BDRVQcowState *s = bs->opaque;
 int index_in_cluster;
 uint64_t cluster_offset;
-const uint8_t *src_buf;
 int ret = 0, n;
 uint8_t *cluster_data = NULL;
 struct iovec hd_iov;
@@ -715,18 +707,15 @@ static coroutine_fn int qcow_co_writev(BlockDriverState 
*bs, int64_t sector_num,
 if (!cluster_data) {
 cluster_data = g_malloc0(s->cluster_size);
 }
-if (encrypt_sectors(s, sector_num, cluster_data, buf,
+if (encrypt_sectors(s, sector_num, buf,
 n, true, &err) < 0) {
 error_free(err);
 ret = -EIO;
 break;
 }
-src_buf = cluster_data;
-} else {
-src_buf = buf;
 }
 
-hd_iov.iov_base = (void *)src_buf;
+hd_iov.iov_base = (void *)buf;
 hd_iov.iov_len = n * 512;
 qemu_iovec_init_external(&hd_qiov, &hd_iov, 1);
 qemu_co_mutex_unlock(&s->lock);
-- 
2.5.0

[Qemu-devel] [PATCH v1 06/15] crypto: implement the LUKS block encryption format

[Daniel P. Berrange]

Provide a block encryption implementation that follows the
LUKS/dm-crypt specification.

This supports all combinations of hash, cipher algorithm,
cipher mode and iv generator that are implemented by the
current crypto layer.

The notable missing feature is support for the 'xts'
cipher mode, which is commonly used for disk encryption
instead of 'cbc'. This is because it is not provided by
either nettle or libgcrypt. A suitable implementation
will be identified & integrated later.

There is support for opening existing volumes formatted
by dm-crypt, and for formatting new volumes. In the latter
case it will only use key slot 0.

Signed-off-by: Daniel P. Berrange 
---
 crypto/Makefile.objs |1 +
 crypto/block-luks.c  | 1092 ++
 crypto/block-luks.h  |   28 ++
 crypto/block.c   |2 +
 qapi/crypto.json |   42 +-
 5 files changed, 1162 insertions(+), 3 deletions(-)
 create mode 100644 crypto/block-luks.c
 create mode 100644 crypto/block-luks.h

diff --git a/crypto/Makefile.objs b/crypto/Makefile.objs
index b5b32a6..c65880f 100644
--- a/crypto/Makefile.objs
+++ b/crypto/Makefile.objs
@@ -17,6 +17,7 @@ crypto-obj-y += ivgen-plain64.o
 crypto-obj-y += afsplit.o
 crypto-obj-y += block.o
 crypto-obj-y += block-qcowaes.o
+crypto-obj-y += block-luks.o
 
 # Let the userspace emulators avoid linking gnutls/etc
 crypto-aes-obj-y = aes.o
diff --git a/crypto/block-luks.c b/crypto/block-luks.c
new file mode 100644
index 000..dbe107c
--- /dev/null
+++ b/crypto/block-luks.c
@@ -0,0 +1,1092 @@
+/*
+ * QEMU Crypto block device encryption LUKS format
+ *
+ * Copyright (c) 2015 Red Hat, Inc.
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see .
+ *
+ */
+
+#include "config-host.h"
+
+#include "crypto/block-luks.h"
+
+#include "crypto/hash.h"
+#include "crypto/afsplit.h"
+#include "crypto/pbkdf.h"
+#include "crypto/secret.h"
+#include "crypto/random.h"
+
+#ifdef CONFIG_UUID
+#include 
+#endif
+
+#include "qemu/coroutine.h"
+
+/*
+ * Reference for format is
+ *
+ * docs/on-disk-format.pdf
+ *
+ * In 'cryptsetup' package source code
+ *
+ */
+
+typedef struct QCryptoBlockLUKS QCryptoBlockLUKS;
+typedef struct QCryptoBlockLUKSHeader QCryptoBlockLUKSHeader;
+typedef struct QCryptoBlockLUKSKeySlot QCryptoBlockLUKSKeySlot;
+
+#define QCRYPTO_BLOCK_LUKS_VERSION 1
+
+#define QCRYPTO_BLOCK_LUKS_MAGIC_LEN 6
+#define QCRYPTO_BLOCK_LUKS_CIPHER_NAME_LEN 32
+#define QCRYPTO_BLOCK_LUKS_CIPHER_MODE_LEN 32
+#define QCRYPTO_BLOCK_LUKS_HASH_SPEC_LEN 32
+#define QCRYPTO_BLOCK_LUKS_DIGEST_LEN 20
+#define QCRYPTO_BLOCK_LUKS_SALT_LEN 32
+#define QCRYPTO_BLOCK_LUKS_UUID_LEN 40
+#define QCRYPTO_BLOCK_LUKS_NUM_KEY_SLOTS 8
+#define QCRYPTO_BLOCK_LUKS_STRIPES 4000
+#define QCRYPTO_BLOCK_LUKS_MIN_SLOT_KEY_ITERS 1000
+#define QCRYPTO_BLOCK_LUKS_MIN_MASTER_KEY_ITERS 1000
+#define QCRYPTO_BLOCK_LUKS_KEY_SLOT_OFFSET 4096
+
+#define QCRYPTO_BLOCK_LUKS_KEY_SLOT_DISABLED 0xDEAD
+#define QCRYPTO_BLOCK_LUKS_KEY_SLOT_ENABLED 0x00AC71F3
+
+static const char qcrypto_block_luks_magic[QCRYPTO_BLOCK_LUKS_MAGIC_LEN] = {
+'L', 'U', 'K', 'S', 0xBA, 0xBE
+};
+
+typedef struct QCryptoBlockLUKSNameMap QCryptoBlockLUKSNameMap;
+struct QCryptoBlockLUKSNameMap {
+const char *name;
+int id;
+};
+
+typedef struct QCryptoBlockLUKSCipherSizeMap QCryptoBlockLUKSCipherSizeMap;
+struct QCryptoBlockLUKSCipherSizeMap {
+uint32_t key_bytes;
+int id;
+};
+typedef struct QCryptoBlockLUKSCipherNameMap QCryptoBlockLUKSCipherNameMap;
+struct QCryptoBlockLUKSCipherNameMap {
+const char *name;
+const QCryptoBlockLUKSCipherSizeMap *sizes;
+};
+
+
+static const QCryptoBlockLUKSCipherSizeMap
+qcrypto_block_luks_cipher_size_map_aes[] = {
+{ 16, QCRYPTO_CIPHER_ALG_AES_128 },
+{ 24, QCRYPTO_CIPHER_ALG_AES_192 },
+{ 32, QCRYPTO_CIPHER_ALG_AES_256 },
+{ 0, 0 },
+};
+
+static const QCryptoBlockLUKSCipherNameMap
+qcrypto_block_luks_cipher_name_map[] = {
+{ "aes", qcrypto_block_luks_cipher_size_map_aes, },
+};
+
+
+struct QCryptoBlockLUKSKeySlot {
+/* state of keyslot, enabled/disable */
+uint32_t active;
+/* iterations for PBKDF2 */
+uint32_t iterations;
+/* salt for PBKDF2 */
+uint8_t salt[QCRYPTO_BLOCK_LUKS_SALT_LEN];
+/* start sector of key material */
+uint32_t key_offset;
+/* number of anti-forensic stripes */
+uint32_t stripes;
+} QE

[Qemu-devel] [PATCH v2 01/11] tests: acpi: test multiple SSDT tables

[Xiao Guangrong]

Currently, only one SSDT with default oem-table-id can be tested,
this patch extents it to test all SSDT tables

Other tables except the default one will be named as SSDT-$oem-table-id

Signed-off-by: Xiao Guangrong 
---
 tests/bios-tables-test.c | 43 ---
 1 file changed, 32 insertions(+), 11 deletions(-)

diff --git a/tests/bios-tables-test.c b/tests/bios-tables-test.c
index 75ec330..fc01cce 100644
--- a/tests/bios-tables-test.c
+++ b/tests/bios-tables-test.c
@@ -18,6 +18,7 @@
 #include "libqtest.h"
 #include "qemu/compiler.h"
 #include "hw/acpi/acpi-defs.h"
+#include "hw/acpi/aml-build.h"
 #include "hw/smbios/smbios.h"
 #include "qemu/bitmap.h"
 
@@ -379,6 +380,33 @@ static void test_acpi_tables(test_data *data)
 }
 }
 
+static gchar *get_sdt_aml_file_name(test_data *data, AcpiSdtTable *sdt,
+bool skip_variant)
+{
+gchar *aml_file, *def_oem_table_id, *oem_table_id, *sig_oem;
+uint32_t signature = cpu_to_le32(sdt->header.signature);
+const char *ext = data->variant && !skip_variant ? data->variant : "";
+
+def_oem_table_id = g_strdup_printf("%s%s", ACPI_BUILD_APPNAME4,
+   (gchar *)&signature);
+oem_table_id = g_strndup((char *)sdt->header.oem_table_id,
+ sizeof(sdt->header.oem_table_id));
+
+if (strcmp(oem_table_id, def_oem_table_id)) {
+sig_oem = g_strdup_printf("%.4s-%s", (gchar *)&signature,
+  oem_table_id);
+} else {
+sig_oem = g_strdup_printf("%.4s", (gchar *)&signature);
+}
+
+aml_file = g_strdup_printf("%s/%s/%s%s", data_dir, data->machine,
+   sig_oem, ext);
+g_free(sig_oem);
+g_free(oem_table_id);
+g_free(def_oem_table_id);
+return aml_file;
+}
+
 static void dump_aml_files(test_data *data, bool rebuild)
 {
 AcpiSdtTable *sdt;
@@ -389,14 +417,11 @@ static void dump_aml_files(test_data *data, bool rebuild)
 int i;
 
 for (i = 0; i < data->tables->len; ++i) {
-const char *ext = data->variant ? data->variant : "";
 sdt = &g_array_index(data->tables, AcpiSdtTable, i);
 g_assert(sdt->aml);
 
 if (rebuild) {
-uint32_t signature = cpu_to_le32(sdt->header.signature);
-aml_file = g_strdup_printf("%s/%s/%.4s%s", data_dir, data->machine,
-   (gchar *)&signature, ext);
+aml_file = get_sdt_aml_file_name(data, sdt, false);
 fd = g_open(aml_file, O_WRONLY|O_TRUNC|O_CREAT,
 S_IRUSR|S_IWUSR|S_IRGRP|S_IWGRP|S_IROTH);
 } else {
@@ -508,22 +533,18 @@ static GArray *load_expected_aml(test_data *data)
 GArray *exp_tables = g_array_new(false, true, sizeof(AcpiSdtTable));
 for (i = 0; i < data->tables->len; ++i) {
 AcpiSdtTable exp_sdt;
-uint32_t signature;
-const char *ext = data->variant ? data->variant : "";
+bool skip_variant = false;
 
 sdt = &g_array_index(data->tables, AcpiSdtTable, i);
 
 memset(&exp_sdt, 0, sizeof(exp_sdt));
 exp_sdt.header.signature = sdt->header.signature;
 
-signature = cpu_to_le32(sdt->header.signature);
-
 try_again:
-aml_file = g_strdup_printf("%s/%s/%.4s%s", data_dir, data->machine,
-   (gchar *)&signature, ext);
+aml_file = get_sdt_aml_file_name(data, sdt, skip_variant);
 if (data->variant && !g_file_test(aml_file, G_FILE_TEST_EXISTS)) {
 g_free(aml_file);
-ext = "";
+skip_variant = true;
 goto try_again;
 }
 exp_sdt.aml_file = aml_file;
-- 
1.8.3.1

[Qemu-devel] [PATCH v1 13/15] block: rip out all traces of password prompting

[Daniel P. Berrange]

Now that qcow & qcow2 are wired up to get encryption keys
via the QCryptoSecret object, nothing is relying on the
interactive prompting for passwords. All the code related
to password prompting can thus be ripped out.

Signed-off-by: Daniel P. Berrange 
---
 hmp.c| 31 
 hw/usb/dev-storage.c | 34 --
 include/monitor/monitor.h|  7 -
 include/qemu/osdep.h |  2 --
 monitor.c| 69 
 qemu-img.c   | 14 -
 qemu-io.c| 21 --
 qmp.c|  9 --
 tests/qemu-iotests/087   | 20 +
 tests/qemu-iotests/087.out   |  2 ++
 tests/qemu-iotests/134   | 17 +++
 tests/qemu-iotests/134.out   |  8 -
 tests/qemu-iotests/common.rc |  4 +--
 util/oslib-posix.c   | 66 --
 util/oslib-win32.c   | 24 ---
 15 files changed, 36 insertions(+), 292 deletions(-)

diff --git a/hmp.c b/hmp.c
index 6a9c51d..4d7543d 100644
--- a/hmp.c
+++ b/hmp.c
@@ -970,37 +970,12 @@ void hmp_ringbuf_read(Monitor *mon, const QDict *qdict)
 g_free(data);
 }
 
-static void hmp_cont_cb(void *opaque, int err)
-{
-if (!err) {
-qmp_cont(NULL);
-}
-}
-
-static bool key_is_missing(const BlockInfo *bdev)
-{
-return (bdev->inserted && bdev->inserted->encryption_key_missing);
-}
-
 void hmp_cont(Monitor *mon, const QDict *qdict)
 {
-BlockInfoList *bdev_list, *bdev;
 Error *err = NULL;
 
-bdev_list = qmp_query_block(NULL);
-for (bdev = bdev_list; bdev; bdev = bdev->next) {
-if (key_is_missing(bdev->value)) {
-monitor_read_block_device_key(mon, bdev->value->device,
-  hmp_cont_cb, NULL);
-goto out;
-}
-}
-
 qmp_cont(&err);
 hmp_handle_error(mon, &err);
-
-out:
-qapi_free_BlockInfoList(bdev_list);
 }
 
 void hmp_system_wakeup(Monitor *mon, const QDict *qdict)
@@ -1387,12 +1362,6 @@ void hmp_change(Monitor *mon, const QDict *qdict)
 
 qmp_blockdev_change_medium(device, target, !!arg, arg,
!!read_only, read_only_mode, &err);
-if (err &&
-error_get_class(err) == ERROR_CLASS_DEVICE_ENCRYPTED) {
-error_free(err);
-monitor_read_block_device_key(mon, device, NULL, NULL);
-return;
-}
 }
 
 hmp_handle_error(mon, &err);
diff --git a/hw/usb/dev-storage.c b/hw/usb/dev-storage.c
index 597d8fd..2122f4f 100644
--- a/hw/usb/dev-storage.c
+++ b/hw/usb/dev-storage.c
@@ -553,21 +553,6 @@ static void usb_msd_handle_data(USBDevice *dev, USBPacket 
*p)
 }
 }
 
-static void usb_msd_password_cb(void *opaque, int err)
-{
-MSDState *s = opaque;
-Error *local_err = NULL;
-
-if (!err) {
-usb_device_attach(&s->dev, &local_err);
-}
-
-if (local_err) {
-error_report_err(local_err);
-qdev_unplug(&s->dev.qdev, NULL);
-}
-}
-
 static void *usb_msd_load_request(QEMUFile *f, SCSIRequest *req)
 {
 MSDState *s = DO_UPCAST(MSDState, dev.qdev, req->bus->qbus.parent);
@@ -613,25 +598,6 @@ static void usb_msd_realize_storage(USBDevice *dev, Error 
**errp)
 return;
 }
 
-if (blk_bs(blk)) {
-bdrv_add_key(blk_bs(blk), NULL, &err);
-if (err) {
-if (monitor_cur_is_qmp()) {
-error_propagate(errp, err);
-return;
-}
-error_free(err);
-err = NULL;
-if (cur_mon) {
-monitor_read_bdrv_key_start(cur_mon, blk_bs(blk),
-usb_msd_password_cb, s);
-s->dev.auto_attach = 0;
-} else {
-autostart = 0;
-}
-}
-}
-
 blkconf_serial(&s->conf, &dev->serial);
 blkconf_blocksizes(&s->conf);
 
diff --git a/include/monitor/monitor.h b/include/monitor/monitor.h
index aa0f373..cd38020 100644
--- a/include/monitor/monitor.h
+++ b/include/monitor/monitor.h
@@ -21,13 +21,6 @@ void monitor_init(CharDriverState *chr, int flags);
 int monitor_suspend(Monitor *mon);
 void monitor_resume(Monitor *mon);
 
-int monitor_read_bdrv_key_start(Monitor *mon, BlockDriverState *bs,
-BlockCompletionFunc *completion_cb,
-void *opaque);
-int monitor_read_block_device_key(Monitor *mon, const char *device,
-  BlockCompletionFunc *completion_cb,
-  void *opaque);
-
 int monitor_get_fd(Monitor *mon, const char *fdname, Error **errp);
 int monitor_fd_param(Monitor *mon, const char *fdname, Error **errp);
 
diff --git a/include/qemu/osdep.h b/include/qemu/osdep.h
index 84e84ac..a95b85d 100644
--- a/include/qemu/osdep.h
+++ b/include/qemu/osdep.h
@@ -299,8 +299,6 @@ void q

[Qemu-devel] [PATCH v1 09/15] qcow2: make qcow2_encrypt_sectors encrypt in place

[Daniel P. Berrange]

Instead of requiring separate input/output buffers for
encrypting data, change qcow2_encrypt_sectors() to assume
use of a single buffer, encrypting in place. The current
callers all used the same buffer for input/output already.

Signed-off-by: Daniel P. Berrange 
---
 block/qcow2-cluster.c | 17 +
 block/qcow2.c |  5 ++---
 block/qcow2.h |  3 +--
 3 files changed, 8 insertions(+), 17 deletions(-)

diff --git a/block/qcow2-cluster.c b/block/qcow2-cluster.c
index 34112c3..f5bc4f2 100644
--- a/block/qcow2-cluster.c
+++ b/block/qcow2-cluster.c
@@ -341,12 +341,8 @@ static int count_contiguous_clusters_by_type(int 
nb_clusters,
 return i;
 }
 
-/* The crypt function is compatible with the linux cryptoloop
-   algorithm for < 4 GB images. NOTE: out_buf == in_buf is
-   supported */
 int qcow2_encrypt_sectors(BDRVQcow2State *s, int64_t sector_num,
-  uint8_t *out_buf, const uint8_t *in_buf,
-  int nb_sectors, bool enc,
+  uint8_t *buf, int nb_sectors, bool enc,
   Error **errp)
 {
 union {
@@ -366,14 +362,12 @@ int qcow2_encrypt_sectors(BDRVQcow2State *s, int64_t 
sector_num,
 }
 if (enc) {
 ret = qcrypto_cipher_encrypt(s->cipher,
- in_buf,
- out_buf,
+ buf, buf,
  512,
  errp);
 } else {
 ret = qcrypto_cipher_decrypt(s->cipher,
- in_buf,
- out_buf,
+ buf, buf,
  512,
  errp);
 }
@@ -381,8 +375,7 @@ int qcow2_encrypt_sectors(BDRVQcow2State *s, int64_t 
sector_num,
 return -1;
 }
 sector_num++;
-in_buf += 512;
-out_buf += 512;
+buf += 512;
 }
 return 0;
 }
@@ -430,7 +423,7 @@ static int coroutine_fn copy_sectors(BlockDriverState *bs,
 Error *err = NULL;
 assert(s->cipher);
 if (qcow2_encrypt_sectors(s, start_sect + n_start,
-  iov.iov_base, iov.iov_base, n,
+  iov.iov_base, n,
   true, &err) < 0) {
 ret = -EIO;
 error_free(err);
diff --git a/block/qcow2.c b/block/qcow2.c
index 1789af4..c0fc259 100644
--- a/block/qcow2.c
+++ b/block/qcow2.c
@@ -1504,7 +1504,7 @@ static coroutine_fn int qcow2_co_readv(BlockDriverState 
*bs, int64_t sector_num,
 assert(s->cipher);
 Error *err = NULL;
 if (qcow2_encrypt_sectors(s, sector_num,  cluster_data,
-  cluster_data, cur_nr_sectors, false,
+  cur_nr_sectors, false,
   &err) < 0) {
 error_free(err);
 ret = -EIO;
@@ -1604,8 +1604,7 @@ static coroutine_fn int qcow2_co_writev(BlockDriverState 
*bs,
 qemu_iovec_to_buf(&hd_qiov, 0, cluster_data, hd_qiov.size);
 
 if (qcow2_encrypt_sectors(s, sector_num, cluster_data,
-  cluster_data, cur_nr_sectors,
-  true, &err) < 0) {
+  cur_nr_sectors, true, &err) < 0) {
 error_free(err);
 ret = -EIO;
 goto fail;
diff --git a/block/qcow2.h b/block/qcow2.h
index a063a3c..ae04285 100644
--- a/block/qcow2.h
+++ b/block/qcow2.h
@@ -540,8 +540,7 @@ int qcow2_write_l1_entry(BlockDriverState *bs, int 
l1_index);
 void qcow2_l2_cache_reset(BlockDriverState *bs);
 int qcow2_decompress_cluster(BlockDriverState *bs, uint64_t cluster_offset);
 int qcow2_encrypt_sectors(BDRVQcow2State *s, int64_t sector_num,
-  uint8_t *out_buf, const uint8_t *in_buf,
-  int nb_sectors, bool enc, Error **errp);
+  uint8_t *buf, int nb_sectors, bool enc, Error 
**errp);
 
 int qcow2_get_cluster_offset(BlockDriverState *bs, uint64_t offset,
 int *num, uint64_t *cluster_offset);
-- 
2.5.0

[Qemu-devel] [PATCH v2 00/11] NVDIMM ACPI: introduce the framework of QEMU emulated

[Xiao Guangrong]

This patchset is against commit 8a1be662a69 (virtio: fix error message for 
number of queues) on pci branch of Michael's git tree
and can be found at:
  https://github.com/xiaogr/qemu.git nvdimm-acpi-v2

Changelog:
These changes are based on Igor's comments:
- drop ssdt.rev2 support as the memory address allocated by BIOS/OVMF
  are always 32 bits
- support to test NVDIMM tables (NFIT and NVDIMM SSDT)
- add _CRS to report its operation region
- make AML APIs change be the separated patches

This is the second part of vNVDIMM implementation which implements the
BIOS patched dsm memory and introduces the framework that allows QEMU
to emulate DSM method

Thanks to Michael's idea, we do not reserve any memory for NVDIMM ACPI,
instead we let BIOS allocate the memory and patch the address to the
offset we want

IO port is still enabled as it plays as the way to notify QEMU and pass
the patched dsm memory address, so that IO port region, 0x0a18 - 0xa20,
is reserved and it is divided into two 32 bits ports and used to pass
the low 32 bits and high 32 bits of dsm memory address to QEMU

Thanks Igor's idea, this patchset also extends DSDT/SSDT to revision 2
to apply 64 bit operations, in order to keeping compatibility, old
version (<= 2.5) still uses revision 1. Since 64 bit operations breaks
old guests (such as windows XP), we should keep the 64 bits stuff in
the private place where common ACPI operation does not touch it

Xiao Guangrong (11):
  tests: acpi: test multiple SSDT tables
  tests: acpi: test NVDIMM tables
  acpi: add aml_create_field()
  acpi: add aml_concatenate()
  acpi: allow using object as offset for OperationRegion
  nvdimm acpi: initialize the resource used by NVDIMM ACPI
  nvdimm acpi: introduce patched dsm memory
  nvdimm acpi: let qemu handle _DSM method
  nvdimm acpi: emulate dsm method
  nvdimm acpi: add _CRS
  tests: acpi: update nvdimm ssdt table

 hw/acpi/Makefile.objs   |   2 +-
 hw/acpi/aml-build.c |  33 +++-
 hw/acpi/nvdimm.c| 255 +++-
 hw/i386/acpi-build.c|  41 ++---
 hw/i386/pc.c|   8 +-
 hw/i386/pc_piix.c   |   5 +
 hw/i386/pc_q35.c|   8 +-
 include/hw/acpi/aml-build.h |   5 +-
 include/hw/i386/pc.h|   5 +-
 include/hw/mem/nvdimm.h |  36 +++-
 tests/acpi-test-data/pc/NFIT| Bin 0 -> 224 bytes
 tests/acpi-test-data/pc/NFIT.bridge | Bin 0 -> 224 bytes
 tests/acpi-test-data/pc/SSDT| Bin 2486 -> 2885 bytes
 tests/acpi-test-data/pc/SSDT-NVDIMM | Bin 0 -> 403 bytes
 tests/acpi-test-data/pc/SSDT-NVDIMM.bridge  | Bin 0 -> 403 bytes
 tests/acpi-test-data/pc/SSDT.bridge | Bin 4345 -> 4745 bytes
 tests/acpi-test-data/q35/NFIT   | Bin 0 -> 224 bytes
 tests/acpi-test-data/q35/NFIT.bridge| Bin 0 -> 224 bytes
 tests/acpi-test-data/q35/SSDT   | Bin 691 -> 1090 bytes
 tests/acpi-test-data/q35/SSDT-NVDIMM| Bin 0 -> 403 bytes
 tests/acpi-test-data/q35/SSDT-NVDIMM.bridge | Bin 0 -> 403 bytes
 tests/acpi-test-data/q35/SSDT.bridge| Bin 708 -> 1107 bytes
 tests/bios-tables-test.c|  58 +--
 23 files changed, 400 insertions(+), 56 deletions(-)
 create mode 100644 tests/acpi-test-data/pc/NFIT
 create mode 100644 tests/acpi-test-data/pc/NFIT.bridge
 create mode 100644 tests/acpi-test-data/pc/SSDT-NVDIMM
 create mode 100644 tests/acpi-test-data/pc/SSDT-NVDIMM.bridge
 create mode 100644 tests/acpi-test-data/q35/NFIT
 create mode 100644 tests/acpi-test-data/q35/NFIT.bridge
 create mode 100644 tests/acpi-test-data/q35/SSDT-NVDIMM
 create mode 100644 tests/acpi-test-data/q35/SSDT-NVDIMM.bridge

-- 
1.8.3.1

[Qemu-devel] [PATCH v1 14/15] block: remove all encryption handling APIs

[Daniel P. Berrange]

Now that all encryption keys must be provided upfront via
the QCryptoSecret API and associated block driver properties
there is no need for any explicit encryption handling APIs
in the block layer. Encryption can be handled transparently
within the block driver. We only retain an API for querying
whether an image is encrypted or not, since that is a
potentially useful piece of metadata to report to the user.

Signed-off-by: Daniel P. Berrange 
---
 block.c| 82 ++
 block/qapi.c   |  2 +-
 blockdev.c | 40 ++
 include/block/block.h  |  4 ---
 include/block/block_int.h  |  1 -
 tests/qemu-iotests/087.out |  4 +--
 6 files changed, 7 insertions(+), 126 deletions(-)

diff --git a/block.c b/block.c
index 01655de..d123cbc 100644
--- a/block.c
+++ b/block.c
@@ -1696,17 +1696,8 @@ static int bdrv_open_inherit(BlockDriverState **pbs, 
const char *filename,
 goto close_and_fail;
 }
 
-if (!bdrv_key_required(bs)) {
-if (bs->blk) {
-blk_dev_change_media_cb(bs->blk, true);
-}
-} else if (!runstate_check(RUN_STATE_PRELAUNCH)
-   && !runstate_check(RUN_STATE_INMIGRATE)
-   && !runstate_check(RUN_STATE_PAUSED)) { /* HACK */
-error_setg(errp,
-   "Guest must be stopped for opening of encrypted image");
-ret = -EBUSY;
-goto close_and_fail;
+if (bs->blk) {
+blk_dev_change_media_cb(bs->blk, true);
 }
 
 QDECREF(options);
@@ -2193,7 +2184,6 @@ void bdrv_close(BlockDriverState *bs)
 bs->backing_format[0] = '\0';
 bs->total_sectors = 0;
 bs->encrypted = 0;
-bs->valid_key = 0;
 bs->sg = 0;
 bs->zero_beyond_eof = false;
 QDECREF(bs->options);
@@ -2777,74 +2767,6 @@ int bdrv_is_encrypted(BlockDriverState *bs)
 return bs->encrypted;
 }
 
-int bdrv_key_required(BlockDriverState *bs)
-{
-BdrvChild *backing = bs->backing;
-
-if (backing && backing->bs->encrypted && !backing->bs->valid_key) {
-return 1;
-}
-return (bs->encrypted && !bs->valid_key);
-}
-
-int bdrv_set_key(BlockDriverState *bs, const char *key)
-{
-int ret;
-if (bs->backing && bs->backing->bs->encrypted) {
-ret = bdrv_set_key(bs->backing->bs, key);
-if (ret < 0)
-return ret;
-if (!bs->encrypted)
-return 0;
-}
-if (!bs->encrypted) {
-return -EINVAL;
-} else if (!bs->drv || !bs->drv->bdrv_set_key) {
-return -ENOMEDIUM;
-}
-ret = bs->drv->bdrv_set_key(bs, key);
-if (ret < 0) {
-bs->valid_key = 0;
-} else if (!bs->valid_key) {
-bs->valid_key = 1;
-if (bs->blk) {
-/* call the change callback now, we skipped it on open */
-blk_dev_change_media_cb(bs->blk, true);
-}
-}
-return ret;
-}
-
-/*
- * Provide an encryption key for @bs.
- * If @key is non-null:
- * If @bs is not encrypted, fail.
- * Else if the key is invalid, fail.
- * Else set @bs's key to @key, replacing the existing key, if any.
- * If @key is null:
- * If @bs is encrypted and still lacks a key, fail.
- * Else do nothing.
- * On failure, store an error object through @errp if non-null.
- */
-void bdrv_add_key(BlockDriverState *bs, const char *key, Error **errp)
-{
-if (key) {
-if (!bdrv_is_encrypted(bs)) {
-error_setg(errp, "Node '%s' is not encrypted",
-  bdrv_get_device_or_node_name(bs));
-} else if (bdrv_set_key(bs, key) < 0) {
-error_setg(errp, QERR_INVALID_PASSWORD);
-}
-} else {
-if (bdrv_key_required(bs)) {
-error_set(errp, ERROR_CLASS_DEVICE_ENCRYPTED,
-  "'%s' (%s) is encrypted",
-  bdrv_get_device_or_node_name(bs),
-  bdrv_get_encrypted_filename(bs));
-}
-}
-}
-
 const char *bdrv_get_format_name(BlockDriverState *bs)
 {
 return bs->drv ? bs->drv->format_name : NULL;
diff --git a/block/qapi.c b/block/qapi.c
index 58d3975..639b231 100644
--- a/block/qapi.c
+++ b/block/qapi.c
@@ -42,7 +42,7 @@ BlockDeviceInfo *bdrv_block_device_info(BlockDriverState *bs, 
Error **errp)
 info->ro = bs->read_only;
 info->drv= g_strdup(bs->drv->format_name);
 info->encrypted  = bs->encrypted;
-info->encryption_key_missing = bdrv_key_required(bs);
+info->encryption_key_missing = false;
 
 info->cache = g_new(BlockdevCacheInfo, 1);
 *info->cache = (BlockdevCacheInfo) {
diff --git a/blockdev.c b/blockdev.c
index 2df0c6d..85e436a 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -623,10 +623,6 @@ static BlockBackend *blockdev_init(const char *file, QDict 
*bs_opts,
 bdrv_set_io_limits(bs, &cfg);
 }
 
-if (bdrv_key_required(bs)) {
-autostart = 0;
- 

[Qemu-devel] [PATCH v1 08/15] block: add generic full disk encryption driver

[Daniel P. Berrange]

Add a block driver that is capable of supporting any full disk
encryption format. This utilizes the previously added block
encryption code, and at this time supports the LUKS format.

The driver code is capable of supporting any format supported
by the QCryptoBlock module, so it registers one block driver
for each format.

At this time, the "luks" driver is registered. New LUKS
compatible volume can be formatted using qemu-img

$ qemu-img create --object secret,data=123456,id=sec0 \
  -f luks -o key-id=sec0,cipher-alg=aes-256,\
  cipher-mode=cbc,ivgen-alg=plain64,hash-alg=sha256 \
  demo.luks 10G

And query its size

$ qemu-img info --object secret,data=123456,id=sec0  --source 
demo.luks,driver=luks,keyid=sec0
image: json:{"key-id": "sec0", "driver": "luks", "file": {"driver": "file", 
"filename": "demo.luks"}}
file format: luks
virtual size: 10.0G (10737416192 bytes)
disk size: 132K

All volumes created by this new 'luks' driver should be
capable of being opened by the kernel dm-crypt driver.
With this initial impl, not all volumes created with
dm-crypt can be opened by the QEMU 'luks' driver. This
is due to lack of support for certain algorithms, in
particular the 'xts' cipher mode. These limitations will
be addressed in a later series of patches, with the
intent that QEMU should be able to open anything that
dm-crypt LUKS supports.

Signed-off-by: Daniel P. Berrange 
---
 block/Makefile.objs  |   2 +
 block/fde.c  | 538 +++
 qapi/block-core.json |  18 +-
 3 files changed, 557 insertions(+), 1 deletion(-)
 create mode 100644 block/fde.c

diff --git a/block/Makefile.objs b/block/Makefile.objs
index 58ef2ef..4f997c9 100644
--- a/block/Makefile.objs
+++ b/block/Makefile.objs
@@ -23,6 +23,8 @@ block-obj-$(CONFIG_LIBSSH2) += ssh.o
 block-obj-y += accounting.o
 block-obj-y += write-threshold.o
 
+block-obj-y += fde.o
+
 common-obj-y += stream.o
 common-obj-y += commit.o
 common-obj-y += backup.o
diff --git a/block/fde.c b/block/fde.c
new file mode 100644
index 000..ec588a6
--- /dev/null
+++ b/block/fde.c
@@ -0,0 +1,538 @@
+/*
+ * QEMU block full disk encryption
+ *
+ * Copyright (c) 2015 Red Hat, Inc.
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see .
+ *
+ */
+
+#include "config-host.h"
+
+#include "block/block_int.h"
+#include "crypto/block.h"
+#include "qapi/opts-visitor.h"
+#include "qapi-visit.h"
+
+#define FDE_OPT_LUKS_KEY_ID "key-id"
+#define FDE_OPT_LUKS_CIPHER_ALG "cipher-alg"
+#define FDE_OPT_LUKS_CIPHER_MODE "cipher-mode"
+#define FDE_OPT_LUKS_IVGEN_ALG "ivgen-alg"
+#define FDE_OPT_LUKS_IVGEN_HASH_ALG "ivgen-hash-alg"
+#define FDE_OPT_LUKS_HASH_ALG "hash-alg"
+
+typedef struct QBlockFDE QBlockFDE;
+
+struct QBlockFDE {
+QCryptoBlock *block;
+CoMutex lock;
+};
+
+
+static int qblock_fde_probe_generic(QCryptoBlockFormat format,
+const uint8_t *buf,
+int buf_size,
+const char *filename)
+{
+if (qcrypto_block_has_format(format,
+ buf, buf_size)) {
+return 100;
+} else {
+return 0;
+}
+}
+
+
+static ssize_t qblock_fde_read_func(QCryptoBlock *block,
+size_t offset,
+uint8_t *buf,
+size_t buflen,
+Error **errp,
+void *opaque)
+{
+BlockDriverState *bs = opaque;
+ssize_t ret;
+
+ret = bdrv_pread(bs->file->bs, offset, buf, buflen);
+if (ret < 0) {
+error_setg_errno(errp, -ret, "Could not read encryption header");
+return ret;
+}
+return ret;
+}
+
+
+static ssize_t qblock_fde_write_func(QCryptoBlock *block,
+ size_t offset,
+ const uint8_t *buf,
+ size_t buflen,
+ Error **errp,
+ void *opaque)
+{
+BlockDriverState *bs = opaque;
+ssize_t ret;
+
+ret = bdrv_pwrite(bs, offset, buf, buflen);
+if (ret < 0) {
+error_setg_errno(errp, -ret, "Could not write encryption header");
+return ret;
+}
+return ret;
+}
+
+
+stati

[Qemu-devel] [PATCH v1 03/15] crypto: add support for generating initialization vectors

[Daniel P. Berrange]

There are a number of different algorithms that can be used
to generate initialization vectors for disk encryption. This
introduces a simple internal QCryptoBlockIV object to provide
a consistent internal API to the different algorithms. The
initially implemented algorithms are 'plain', 'plain64' and
'essiv', each matching the same named algorithm provided
by the Linux kernel dm-crypt driver.

Signed-off-by: Daniel P. Berrange 
---
 crypto/Makefile.objs  |   4 ++
 crypto/ivgen-essiv.c  | 116 
 crypto/ivgen-essiv.h  |  28 
 crypto/ivgen-plain.c  |  60 +
 crypto/ivgen-plain.h  |  28 
 crypto/ivgen-plain64.c|  60 +
 crypto/ivgen-plain64.h|  28 
 crypto/ivgen.c| 117 
 crypto/ivgenpriv.h|  47 +
 include/crypto/ivgen.h| 167 +
 qapi/crypto.json  |  16 +
 tests/.gitignore  |   1 +
 tests/Makefile|   2 +
 tests/test-crypto-ivgen.c | 168 ++
 14 files changed, 842 insertions(+)
 create mode 100644 crypto/ivgen-essiv.c
 create mode 100644 crypto/ivgen-essiv.h
 create mode 100644 crypto/ivgen-plain.c
 create mode 100644 crypto/ivgen-plain.h
 create mode 100644 crypto/ivgen-plain64.c
 create mode 100644 crypto/ivgen-plain64.h
 create mode 100644 crypto/ivgen.c
 create mode 100644 crypto/ivgenpriv.h
 create mode 100644 include/crypto/ivgen.h
 create mode 100644 tests/test-crypto-ivgen.c

diff --git a/crypto/Makefile.objs b/crypto/Makefile.objs
index c1cf45c..a973483 100644
--- a/crypto/Makefile.objs
+++ b/crypto/Makefile.objs
@@ -10,6 +10,10 @@ crypto-obj-y += tlssession.o
 crypto-obj-y += secret.o
 crypto-obj-y += random.o
 crypto-obj-y += pbkdf.o
+crypto-obj-y += ivgen.o
+crypto-obj-y += ivgen-essiv.o
+crypto-obj-y += ivgen-plain.o
+crypto-obj-y += ivgen-plain64.o
 
 # Let the userspace emulators avoid linking gnutls/etc
 crypto-aes-obj-y = aes.o
diff --git a/crypto/ivgen-essiv.c b/crypto/ivgen-essiv.c
new file mode 100644
index 000..fad8f95
--- /dev/null
+++ b/crypto/ivgen-essiv.c
@@ -0,0 +1,116 @@
+/*
+ * QEMU Crypto block IV generator - essiv
+ *
+ * Copyright (c) 2015 Red Hat, Inc.
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see .
+ *
+ */
+
+#include "crypto/ivgen-essiv.h"
+
+typedef struct QCryptoIVGenESSIV QCryptoIVGenESSIV;
+struct QCryptoIVGenESSIV {
+QCryptoCipher *cipher;
+QCryptoCipherAlgorithm cipheralg;
+};
+
+static int qcrypto_ivgen_essiv_init(QCryptoIVGen *ivgen,
+QCryptoCipherAlgorithm cipheralg,
+QCryptoHashAlgorithm hash,
+const uint8_t *key, size_t nkey,
+Error **errp)
+{
+uint8_t *salt;
+size_t nhash;
+QCryptoIVGenESSIV *essiv = g_new0(QCryptoIVGenESSIV, 1);
+
+nhash = qcrypto_hash_digest_len(hash);
+/* Salt must be larger of hash size or key size */
+salt = g_new0(uint8_t, nhash > nkey ? nhash : nkey);
+
+if (qcrypto_hash_bytes(hash, (const gchar*)key, nkey,
+   &salt, &nhash,
+   errp) < 0) {
+g_free(essiv);
+return -1;
+}
+
+essiv->cipheralg = cipheralg;
+essiv->cipher = qcrypto_cipher_new(cipheralg,
+   QCRYPTO_CIPHER_MODE_ECB,
+   salt, nkey,
+   errp);
+if (!essiv->cipher) {
+g_free(essiv);
+g_free(salt);
+return -1;
+}
+
+g_free(salt);
+ivgen->private = essiv;
+
+return 0;
+}
+
+static int qcrypto_ivgen_essiv_calculate(QCryptoIVGen *ivgen,
+ uint64_t sector,
+ uint8_t *iv, size_t niv,
+ Error **errp)
+{
+QCryptoIVGenESSIV *essiv = ivgen->private;
+size_t ndata = qcrypto_cipher_get_block_len(essiv->cipheralg);
+uint8_t *data = g_new(uint8_t, ndata);
+
+sector = cpu_to_le64((uint32_t)sector);
+memcpy(data, (uint8_t *)§or, ndata);
+if (sizeof(sector) < ndata) {
+memset(data + sizeof(sector), 0, ndata - sizeof(sector));
+  

[Qemu-devel] [PATCH v1 02/15] crypto: add support for PBKDF2 algorithm

[Daniel P. Berrange]

The LUKS data format includes use of PBKDF2 (Password-Based
Key Derivation Function). The Nettle library can provide
an implementation of this, but we don't want code directly
depending on a specific crypto library backend. Introduce
a include/crypto/pbkdf.h header which defines a QEMU
API for invoking PBKDK2. The initial implementations are
backed by nettle & gcrypt, which are commonly available
with distros shipping GNUTLS.

The test suite data is taken from the cryptsetup codebase
under the LGPLv2.1+ license. This merely aims to verify
that whatever backend we provide for this function in QEMU
will comply with the spec.

Signed-off-by: Daniel P. Berrange 
---
 crypto/Makefile.objs  |   1 +
 crypto/pbkdf-gcrypt.c |  64 
 crypto/pbkdf-nettle.c |  63 
 crypto/pbkdf-stub.c   |  39 +
 crypto/pbkdf.c|  76 ++
 include/crypto/pbkdf.h| 152 +++
 tests/.gitignore  |   1 +
 tests/Makefile|   2 +
 tests/test-crypto-pbkdf.c | 378 ++
 9 files changed, 776 insertions(+)
 create mode 100644 crypto/pbkdf-gcrypt.c
 create mode 100644 crypto/pbkdf-nettle.c
 create mode 100644 crypto/pbkdf-stub.c
 create mode 100644 crypto/pbkdf.c
 create mode 100644 include/crypto/pbkdf.h
 create mode 100644 tests/test-crypto-pbkdf.c

diff --git a/crypto/Makefile.objs b/crypto/Makefile.objs
index 5f38d2d..c1cf45c 100644
--- a/crypto/Makefile.objs
+++ b/crypto/Makefile.objs
@@ -9,6 +9,7 @@ crypto-obj-y += tlscredsx509.o
 crypto-obj-y += tlssession.o
 crypto-obj-y += secret.o
 crypto-obj-y += random.o
+crypto-obj-y += pbkdf.o
 
 # Let the userspace emulators avoid linking gnutls/etc
 crypto-aes-obj-y = aes.o
diff --git a/crypto/pbkdf-gcrypt.c b/crypto/pbkdf-gcrypt.c
new file mode 100644
index 000..2e494ce
--- /dev/null
+++ b/crypto/pbkdf-gcrypt.c
@@ -0,0 +1,64 @@
+/*
+ * QEMU Crypto PBKDF support (Password-Based Key Derivation Function)
+ *
+ * Copyright (c) 2015 Red Hat, Inc.
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see .
+ *
+ */
+
+#include "gcrypt.h"
+
+bool qcrypto_pbkdf2_supports(QCryptoHashAlgorithm hash)
+{
+switch (hash) {
+case QCRYPTO_HASH_ALG_SHA1:
+case QCRYPTO_HASH_ALG_SHA256:
+return true;
+default:
+return false;
+}
+}
+
+int qcrypto_pbkdf2(QCryptoHashAlgorithm hash,
+   const uint8_t *key, size_t nkey,
+   const uint8_t *salt, size_t nsalt,
+   unsigned int iterations,
+   uint8_t *out, size_t nout,
+   Error **errp)
+{
+static const int hash_map[QCRYPTO_HASH_ALG_LAST] = {
+[QCRYPTO_HASH_ALG_MD5] = GCRY_MD_MD5,
+[QCRYPTO_HASH_ALG_SHA1] = GCRY_MD_SHA1,
+[QCRYPTO_HASH_ALG_SHA256] = GCRY_MD_SHA256,
+};
+int ret;
+
+if (hash > G_N_ELEMENTS(hash_map)) {
+error_setg(errp, "Unexpected hash algorithm %d", hash);
+return -1;
+}
+
+ret = gcry_kdf_derive(key, nkey, GCRY_KDF_PBKDF2,
+  hash_map[hash],
+  salt, nsalt, iterations,
+  nout, out);
+if (ret != 0) {
+error_setg(errp, "Cannot derive password: %s",
+   gcry_strerror(ret));
+return -1;
+}
+
+return 0;
+}
diff --git a/crypto/pbkdf-nettle.c b/crypto/pbkdf-nettle.c
new file mode 100644
index 000..d86cd58
--- /dev/null
+++ b/crypto/pbkdf-nettle.c
@@ -0,0 +1,63 @@
+/*
+ * QEMU Crypto PBKDF support (Password-Based Key Derivation Function)
+ *
+ * Copyright (c) 2015 Red Hat, Inc.
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see .
+ *
+ */
+
+#include "nettle/pbkdf2.h"
+
+
+bool qcrypto_pbkdf2_supports(QCrypto

[Qemu-devel] [PATCH v1 07/15] block: add flag to indicate that no I/O will be performed

[Daniel P. Berrange]

When opening an image it is useful to know whether the caller
intends to perform I/O on the image or not. In the case of
encrypted images this will allow the block driver to avoid
having to prompt for decryption keys when we merely want to
query header metadata about the image. eg qemu-img info

Signed-off-by: Daniel P. Berrange 
---
 include/block/block.h |  1 +
 qemu-img.c| 33 +
 2 files changed, 18 insertions(+), 16 deletions(-)

diff --git a/include/block/block.h b/include/block/block.h
index c96923d..73ffbd5 100644
--- a/include/block/block.h
+++ b/include/block/block.h
@@ -91,6 +91,7 @@ typedef struct HDGeometry {
 #define BDRV_O_PROTOCOL0x8000  /* if no block driver is explicitly given:
   select an appropriate protocol driver,
   ignoring the format layer */
+#define BDRV_O_NO_IO   0x1 /* don't initialize for I/O */
 
 #define BDRV_O_CACHE_MASK  (BDRV_O_NOCACHE | BDRV_O_CACHE_WB | BDRV_O_NO_FLUSH)
 
diff --git a/qemu-img.c b/qemu-img.c
index afe88ed..e965e7d 100644
--- a/qemu-img.c
+++ b/qemu-img.c
@@ -267,7 +267,7 @@ static BlockBackend *img_open_opts(const char *id,
 
 static BlockBackend *img_open_file(const char *id, const char *filename,
const char *fmt, int flags,
-   bool require_io, bool quiet)
+   bool quiet)
 {
 BlockBackend *blk;
 BlockDriverState *bs;
@@ -289,7 +289,7 @@ static BlockBackend *img_open_file(const char *id, const 
char *filename,
 }
 
 bs = blk_bs(blk);
-if (bdrv_is_encrypted(bs) && require_io) {
+if (bdrv_is_encrypted(bs) && !(flags & BDRV_O_NO_IO)) {
 qprintf(quiet, "Disk image '%s' is encrypted.\n", filename);
 if (qemu_read_password(password, sizeof(password)) < 0) {
 error_report("No password given");
@@ -683,7 +683,7 @@ static int img_check(int argc, char **argv)
 }
 blk = img_open_opts("image", opts, flags);
 } else {
-blk = img_open_file("image", filename, fmt, flags, true, quiet);
+blk = img_open_file("image", filename, fmt, flags, quiet);
 }
 if (!blk) {
 return 1;
@@ -888,7 +888,7 @@ static int img_commit(int argc, char **argv)
 }
 blk = img_open_opts("image", opts, flags);
 } else {
-blk = img_open_file("image", filename, fmt, flags, true, quiet);
+blk = img_open_file("image", filename, fmt, flags, quiet);
 }
 if (!blk) {
 return 1;
@@ -1250,13 +1250,13 @@ static int img_compare(int argc, char **argv)
 goto out3;
 }
 } else {
-blk1 = img_open_file("image_1", filename1, fmt1, flags, true, quiet);
+blk1 = img_open_file("image_1", filename1, fmt1, flags, quiet);
 if (!blk1) {
 ret = 2;
 goto out3;
 }
 
-blk2 = img_open_file("image_2", filename2, fmt2, flags, true, quiet);
+blk2 = img_open_file("image_2", filename2, fmt2, flags, quiet);
 if (!blk2) {
 ret = 2;
 goto out2;
@@ -1936,7 +1936,7 @@ static int img_convert(int argc, char **argv)
 blk[bs_i] = img_open_opts(id, opts, src_flags);
 } else {
 blk[bs_i] = img_open_file(id, argv[optind + bs_i], fmt, src_flags,
-  true, quiet);
+  quiet);
 }
 g_free(id);
 if (!blk[bs_i]) {
@@ -2086,7 +2086,7 @@ static int img_convert(int argc, char **argv)
  * the bdrv_create() call which takes different params
  */
 out_blk = img_open_file("target", out_filename,
-out_fmt, flags, true, quiet);
+out_fmt, flags, quiet);
 if (!out_blk) {
 ret = -1;
 goto out;
@@ -2290,12 +2290,13 @@ static ImageInfoList *collect_image_info_list(bool 
image_opts,
 goto err;
 }
 blk = img_open_opts("image", opts,
-BDRV_O_FLAGS | BDRV_O_NO_BACKING);
+BDRV_O_FLAGS | BDRV_O_NO_BACKING |
+BDRV_O_NO_IO);
 opts = NULL;
 } else {
 blk = img_open_file("image", filename, fmt,
-BDRV_O_FLAGS | BDRV_O_NO_BACKING,
-false, false);
+BDRV_O_FLAGS | BDRV_O_NO_BACKING |
+BDRV_O_NO_IO, false);
 }
 if (!blk) {
 goto err;
@@ -2612,7 +2613,7 @@ static int img_map(int argc, char **argv)
 }
 blk = img_open_opts("image", opts, BDRV_O_FLAGS);
 } else {
-blk = img_open_file("image", filename, fmt, BDRV_O_FLAGS, true, false);
+blk = img_open_file("image", filename, fmt, BDRV_O_FLAGS, false);
 }
 if (!bl

[Qemu-devel] [PATCH v1 00/15] Support LUKS encryption in block devices

[Daniel P. Berrange]

This is a posting of the previously submitted work in progress
code:

  https://lists.gnu.org/archive/html/qemu-devel/2015-11/msg04748.html

This series depends on these previously submitted
patches to the block tools:

  https://lists.gnu.org/archive/html/qemu-devel/2015-12/msg04354.html

As can be guessed from the subject, the primary goal of this
patch series is to support LUKS encryption in the QEMU block
layer. QEMU has increasingly been adding native clients for
network block protocols (RBD, gluster, NFS, iSCSI, etc) and
apps like OpenStack are embracing them as it is much easier
to deal with this from a management POV than to deal with the
kernel block layer & userspace tools. Unfortunately when using
QEMU native clients, apps are locked out of using dm-crypt
and LUKS which is undesirable.

This series introduces two new features to the block layer.
First there is a general purpose 'luks' format driver which
can be layered over any other existing block driver. eg it
can be layed above RBD, iSCSI, etc. Second the qcow2 file
format is extended so that its embedded encryption can be
replaced with the LUKS data format. While you could just
layer the general purpose luks driver over qcow2, this is
slightly less desirable, as it removes the ability to
reliably auto-detect that LUKS is used by QEMU, as opposed
to used by the guest OS. Having use of LUKS encoded in the
qcow2 header addresses this.

The code is designed such that there is a strict separation
between the full disk encryption format and the block I/O
layer. Thus there is an generic API for dealing with full
disk encryption added to the crypto/ subsystem. The block
layer merely calls this FDE API when required, which serves
to minimize the code present in the already complex block
layer.

The first 4 patches add some supporting APIs to the crypto
subsystem.

The 5-6 patches introduce the general full disk encryption
API to the crypto subsystem and LUKS implementation

Patches 7-12 add the new 'luks' block driver format and
convert qcow & qcow2 to the new FDE APIs, enabling LUKS
in qcow2 (but not qcow) at the same time.

Patches 13-14 clean up the horrible password handling
cruft in the block layer and monitor.

Patch 15 blocks use of the legacy qcow[2] encryption
from the system emulators.

Some notable things since the original WIP posting

 - QAPI parameters defined for the encryption key ID
 - The qcow2 integration of LUKS is working, using
   extra allocated clusters to store LUKS header
   instead of trying to expand the main qcow2 header
   region to > 1 cluster
 - qemu-img info now works without prompting for
   decryption password
 - Unit testing of pbkdf2, afsplit and ivgen APis.

Still to do

 - Unit testing coverage of the full disk encryption
   APIs
 - Functional testing of LUKS driver via the
   qemu-iotests for the block layer
 - Use GNUTLS random API for the random byte source
 - Add support for XTS cipher mode for dm-crypt compat

Daniel P. Berrange (15):
  crypto: add cryptographic random byte source
  crypto: add support for PBKDF2 algorithm
  crypto: add support for generating initialization vectors
  crypto: add support for anti-forensic split algorithm
  crypto: add block encryption framework
  crypto: implement the LUKS block encryption format
  block: add flag to indicate that no I/O will be performed
  block: add generic full disk encryption driver
  qcow2: make qcow2_encrypt_sectors encrypt in place
  qcow2: convert QCow2 to use QCryptoBlock for encryption
  qcow: make encrypt_sectors encrypt in place
  qcow: convert QCow to use QCryptoBlock for encryption
  block: rip out all traces of password prompting
  block: remove all encryption handling APIs
  block: remove support for legecy AES qcow/qcow2 encryption

 block.c  |   94 +---
 block/Makefile.objs  |2 +
 block/fde.c  |  538 +
 block/qapi.c |2 +-
 block/qcow.c |  199 
 block/qcow2-cluster.c|   55 +--
 block/qcow2.c|  511 +---
 block/qcow2.h|   24 +-
 blockdev.c   |   40 +-
 crypto/Makefile.objs |   10 +
 crypto/afsplit.c |  194 
 crypto/block-luks.c  | 1092 ++
 crypto/block-luks.h  |   28 ++
 crypto/block-qcowaes.c   |  165 +++
 crypto/block-qcowaes.h   |   28 ++
 crypto/block.c   |  256 ++
 crypto/blockpriv.h   |   89 
 crypto/ivgen-essiv.c |  116 +
 crypto/ivgen-essiv.h |   28 ++
 crypto/ivgen-plain.c |   60 +++
 crypto/ivgen-plain.h |   28 ++
 crypto/ivgen-plain64.c   |   60 +++
 crypto/ivgen-plain64.h   |   28 ++
 crypto/ivgen.c   |  117 +
 crypto/ivgenpriv.h   |   47 ++
 crypto/pbkdf-gcrypt.c|   64 +++
 crypto/pbkdf-nettle.c|   63 +++
 crypto/pbkdf-stub.c  |   39 

[Qemu-devel] [PATCH v1 01/15] crypto: add cryptographic random byte source

[Daniel P. Berrange]

Signed-off-by: Daniel P. Berrange 
---
 crypto/Makefile.objs|  1 +
 crypto/random.c | 50 +
 include/crypto/random.h | 43 ++
 3 files changed, 94 insertions(+)
 create mode 100644 crypto/random.c
 create mode 100644 include/crypto/random.h

diff --git a/crypto/Makefile.objs b/crypto/Makefile.objs
index a3135f1..5f38d2d 100644
--- a/crypto/Makefile.objs
+++ b/crypto/Makefile.objs
@@ -8,6 +8,7 @@ crypto-obj-y += tlscredsanon.o
 crypto-obj-y += tlscredsx509.o
 crypto-obj-y += tlssession.o
 crypto-obj-y += secret.o
+crypto-obj-y += random.o
 
 # Let the userspace emulators avoid linking gnutls/etc
 crypto-aes-obj-y = aes.o
diff --git a/crypto/random.c b/crypto/random.c
new file mode 100644
index 000..8257d24
--- /dev/null
+++ b/crypto/random.c
@@ -0,0 +1,50 @@
+/*
+ * QEMU Crypto random number provider
+ *
+ * Copyright (c) 2015 Red Hat, Inc.
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see .
+ *
+ */
+
+#include 
+
+#include "crypto/random.h"
+
+int qcrypto_random_bytes(uint8_t *buf,
+ size_t buflen,
+ Error **errp)
+{
+ssize_t ret;
+int fd = open("/dev/random", O_RDONLY);
+if (fd < 0) {
+error_setg_errno(errp, errno,
+ "Unable to open /dev/random");
+return -1;
+}
+
+while (buflen) {
+ret = read(fd, buf, buflen);
+if (ret < 0) {
+error_setg_errno(errp, errno,
+ "Unable to read random bytes");
+close(fd);
+return -1;
+}
+buflen -= ret;
+}
+
+close(fd);
+return 0;
+}
diff --git a/include/crypto/random.h b/include/crypto/random.h
new file mode 100644
index 000..ce1626b
--- /dev/null
+++ b/include/crypto/random.h
@@ -0,0 +1,43 @@
+/*
+ * QEMU Crypto random number provider
+ *
+ * Copyright (c) 2015 Red Hat, Inc.
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see .
+ *
+ */
+
+#ifndef QCRYPTO_RANDOM_H__
+#define QCRYPTO_RANDOM_H__
+
+#include "qemu-common.h"
+#include "qapi/error.h"
+
+
+/**
+ * qcrypto_random_bytes:
+ * @buf: the buffer to fill
+ * @buflen: length of @buf in bytes
+ * @errp: pointer to uninitialized error objet
+ *
+ * Fill @buf with @buflen bytes of random data
+ *
+ * Returns 0 on sucess, -1 on error
+ */
+int qcrypto_random_bytes(uint8_t *buf,
+ size_t buflen,
+ Error **errp);
+
+
+#endif /* QCRYPTO_RANDOM_H__ */
-- 
2.5.0

Re: [Qemu-devel] [PATCH v3] vfio/common: Check iova with limit not with size

[Alex Williamson]

On Tue, 2016-01-12 at 16:11 +0100, Pierre Morel wrote:
> In vfio_listener_region_add(), we try to validate that the region is
> not
> zero sized and hasn't overflowed the addresses space.
> 
> But the calculation uses the size of the region instead of
> using the region's limit (size - 1).
> 
> This leads to Int128 overflow when the region has
> been initialized to UINT64_MAX because in this case
> memory_region_init() transform the size from UINT64_MAX
> to int128_2_64().
> 
> Let's really use the limit by sustracting one to the size
> and take care to use the limit for functions using limit
> and size to call functions which need size.
> 
> Signed-off-by: Pierre Morel 
> ---
> 
> Changes from v2:
> - all, just ignore v2, sorry about this,
>   this is build after v1
> 
> Changes from v1:
> - adjust the tests by knowing we already substracted one to end.
> 
>  hw/vfio/common.c |   14 +++---
>  1 files changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/hw/vfio/common.c b/hw/vfio/common.c
> index 6797208..a5f6643 100644
> --- a/hw/vfio/common.c
> +++ b/hw/vfio/common.c
> @@ -348,12 +348,12 @@ static void
> vfio_listener_region_add(MemoryListener *listener,
>  if (int128_ge(int128_make64(iova), llend)) {
>  return;
>  }
> -end = int128_get64(llend);
> +end = int128_get64(int128_sub(llend, int128_one()));
>  
> -if ((iova < container->min_iova) || ((end - 1) > container-
> >max_iova)) {
> +if ((iova < container->min_iova) || (end  > container-
> >max_iova)) {
>  error_report("vfio: IOMMU container %p can't map guest IOVA
> region"
>   " 0x%"HWADDR_PRIx"..0x%"HWADDR_PRIx,
> - container, iova, end - 1);
> + container, iova, end);
>  ret = -EFAULT;
>  goto fail;
>  }
> @@ -363,7 +363,7 @@ static void
> vfio_listener_region_add(MemoryListener *listener,
>  if (memory_region_is_iommu(section->mr)) {
>  VFIOGuestIOMMU *giommu;
>  
> -trace_vfio_listener_region_add_iommu(iova, end - 1);
> +trace_vfio_listener_region_add_iommu(iova, end);
>  /*
>   * FIXME: We should do some checking to see if the
>   * capabilities of the host VFIO IOMMU are adequate to model
> @@ -394,13 +394,13 @@ static void
> vfio_listener_region_add(MemoryListener *listener,
>  section->offset_within_region +
>  (iova - section->offset_within_address_space);
>  
> -trace_vfio_listener_region_add_ram(iova, end - 1, vaddr);
> +trace_vfio_listener_region_add_ram(iova, end, vaddr);
>  
> -ret = vfio_dma_map(container, iova, end - iova, vaddr, section-
> >readonly);
> +ret = vfio_dma_map(container, iova, end - iova + 1, vaddr,
> section->readonly);
>  if (ret) {
>  error_report("vfio_dma_map(%p, 0x%"HWADDR_PRIx", "
>   "0x%"HWADDR_PRIx", %p) = %d (%m)",
> - container, iova, end - iova, vaddr, ret);
> + container, iova, end - iova + 1, vaddr, ret);
>  goto fail;
>  }
>  

Hmm, did we just push the overflow from one place to another?  If we're
mapping a full region of size int128_2_64() starting at iova zero, then
this becomes (0x___ - 0 + 1) = 0.  So I think we need
to calculate size with 128bit arithmetic too and let it assert if we
overflow, ie:

diff --git a/hw/vfio/common.c b/hw/vfio/common.c
index a5f6643..13ad90b 100644
--- a/hw/vfio/common.c
+++ b/hw/vfio/common.c
@@ -321,7 +321,7 @@ static void vfio_listener_region_add(MemoryListener 
*listener,
  MemoryRegionSection *section)
 {
 VFIOContainer *container = container_of(listener, VFIOContainer, listener);
-hwaddr iova, end;
+hwaddr iova, end, size;
 Int128 llend;
 void *vaddr;
 int ret;
@@ -348,7 +348,9 @@ static void vfio_listener_region_add(MemoryListener 
*listener,
 if (int128_ge(int128_make64(iova), llend)) {
 return;
 }
+
 end = int128_get64(int128_sub(llend, int128_one()));
+size = int128_get64(int128_sub(llend, int128_make64(iova)));
 
 if ((iova < container->min_iova) || (end  > container->max_iova)) {
 error_report("vfio: IOMMU container %p can't map guest IOVA region"
@@ -396,11 +398,11 @@ static void vfio_listener_region_add(MemoryListener 
*listener,
 
 trace_vfio_listener_region_add_ram(iova, end, vaddr);
 
-ret = vfio_dma_map(container, iova, end - iova + 1, vaddr, 
section->readonly);
+ret = vfio_dma_map(container, iova, size, vaddr, section->readonly);
 if (ret) {
 error_report("vfio_dma_map(%p, 0x%"HWADDR_PRIx", "
  "0x%"HWADDR_PRIx", %p) = %d (%m)",
- container, iova, end - iova + 1, vaddr, ret);
+ container, iova, size, vaddr, ret);
 goto fail;
 }
 

Does that still solve your scenario?  Perhaps vfio-iommu-type1 should
have used first/last rather than 

Re: [Qemu-devel] [PATCH v10 5/7] hw/ptimer: Legalize running with delta = load = 0

[Dmitry Osipenko]

12.01.2016 06:58, Peter Crosthwaite пишет:

On Sat, Jan 09, 2016 at 08:39:53PM +0300, Dmitry Osipenko wrote:

Currently ptimer would print error message and clear enable flag for an
arming timer that has delta = load = 0. That actually could be a valid case
for some hardware, like instant IRQ trigger for oneshot timer or continuous
in periodic mode. Support those cases by printing error message only when
period = 0.



Isn't the continuous-periodic the same as period = 0, so if we were to really
support this, there should be no error message. This would simplify as we
can remove the conditionals of 0 period completely and rely only on the
too-fast clamps you add in previous patches.



I don't think that clamping is needed. Instead doing the ptimer_tick might be 
necessary, so ptimer user could handle that case on it own.


BTW, that printf isn't quite reliable, hw_error or other way of execution abort 
should been used instead.


Thanks for the comment.

--
Dmitry

Re: [Qemu-devel] [PULL 00/25] VirtFS update

[Peter Maydell]

On 12 January 2016 at 06:08, Aneesh Kumar K.V
 wrote:
> The following changes since commit a7e00e2536941a6e570b45b7ab4afec4505ff67e:
>
>   petalogix-ml605: Set the MicroBlaze CPU version to 8.10.a (2016-01-07 
> 14:57:26 +0100)
>
> are available in the git repository at:
>
>   https://github.com/kvaneesh/qemu.git tags/for-upstream-signed
>
> for you to fetch changes up to 00588a0aa2ade2e32a552633bbbefdc6ae5e32a2:
>
>   9pfs: introduce V9fsVirtioState (2016-01-12 11:04:14 +0530)
>
> 
> VirtFS update:
>
> Cleanups mostly isolating virtio related details into separate files. This
> is done to enable easy addition of Xen transport for VirtFS.
>
> The changes include:
>
> 1. Rename a bunch of files and functions to make clear they are generic.
> 2. disentangle virtio transport code and generic 9pfs code.
> 3. Some function name clean-up.
>
> 

Applied, thanks.

-- PMM

Re: [Qemu-devel] [PATCH 4/5] block/backup: Add subclassed notifier

[John Snow]

On 01/12/2016 01:01 PM, Paolo Bonzini wrote:
> 
> 
> On 12/01/2016 18:57, John Snow wrote:
>>
>>
>> On 01/12/2016 03:46 AM, Paolo Bonzini wrote:
>>>
>>>
>>> On 12/01/2016 01:36, John Snow wrote:
 Instead of relying on peeking at bs->job, we want to explicitly get
 a reference to the job that was involved in this notifier callback.

 Extend the Notifier to include a job pointer, and include a reference
 to the job registering the callback. This cuts out a few more cases
 where we have to rely on bs->job.

 Signed-off-by: John Snow 
>>>
>>> Why don't you just put the NotifierWithReturn inside the BackupBlockJob
>>> struct, and use container_of to get from NWR to BackupBlockJob?
>>>
>>> Paolo
>>>
>>
>> That's another way (including the notifier within the job vs. including
>> the job within the notifier.) This one simply occurred to me first. Any
>> strong benefit to that method, or just a matter of style?
> 
> It's usually the one that is used with notifiers, no other reason.
> 
> 
> Paolo
> 

I'll follow convention, I just didn't bump into an example to model.

--js

Re: [Qemu-devel] [PATCH 4/5] block/backup: Add subclassed notifier

[Paolo Bonzini]

On 12/01/2016 18:57, John Snow wrote:
> 
> 
> On 01/12/2016 03:46 AM, Paolo Bonzini wrote:
>>
>>
>> On 12/01/2016 01:36, John Snow wrote:
>>> Instead of relying on peeking at bs->job, we want to explicitly get
>>> a reference to the job that was involved in this notifier callback.
>>>
>>> Extend the Notifier to include a job pointer, and include a reference
>>> to the job registering the callback. This cuts out a few more cases
>>> where we have to rely on bs->job.
>>>
>>> Signed-off-by: John Snow 
>>
>> Why don't you just put the NotifierWithReturn inside the BackupBlockJob
>> struct, and use container_of to get from NWR to BackupBlockJob?
>>
>> Paolo
>>
> 
> That's another way (including the notifier within the job vs. including
> the job within the notifier.) This one simply occurred to me first. Any
> strong benefit to that method, or just a matter of style?

It's usually the one that is used with notifiers, no other reason.


Paolo

Re: [Qemu-devel] [PATCH 1/1] blk: do not select PFLASH device for internal snapshot

[Denis V. Lunev]

On 01/12/2016 08:50 PM, Kevin Wolf wrote:

Am 12.01.2016 um 18:40 hat Markus Armbruster geschrieben:

Kevin Wolf  writes:


Am 12.01.2016 um 17:35 hat Denis V. Lunev geschrieben:

On 01/12/2016 06:47 PM, Denis V. Lunev wrote:

On 01/12/2016 06:20 PM, Kevin Wolf wrote:

Am 12.01.2016 um 15:59 hat Paolo Bonzini geschrieben:

On 12/01/2016 15:16, Kevin Wolf wrote:

Thus we should avoid selection of "pflash" drives for VM
state saving.

For now "pflash" is read-write raw image as it configured by libvirt.
Thus there are no such images in the field and we could
safely disable
ability to save state to those images inside QEMU.

This is obviously broken. If you write to the pflash, then it needs to
be snapshotted in order to keep a consistent state.

If you want to avoid snapshotting the image, make it read-only and it
will be skipped even today.

Sort of.  The point of having flash is to _not_ make it read-only, so
that is not a solution.

Flash is already being snapshotted as part of saving RAM state.  In
fact, for this reason the device (at least the one used with OVMF; I
haven't checked other pflash devices) can simply save it back to disk
on the migration destination, without the need to use "migrate -b" or
shared storage.
[...]
I don't like very much using IF_PFLASH this way, which is why I hadn't
replied to the patch so far---I hadn't made up my mind about *what* to
suggest instead, or whether to just accept it.  However, it does work.

Perhaps a separate "I know what I am doing" skip-snapshot option?  Or
a device callback saying "not snapshotting this is fine"?

Boy, is this ugly...

What do you do with disk-only snapshots? The recovery only works as long
as you have VM state.

Kevin

actually I am in a bit of trouble :(

I understand that this is ugly, but I would like to make working
'virsh snapshot' for OVFM VMs. This is necessary for us to make
a release.

Currently libvirt guys generate XML in the following way:

  
hvm
/usr/share/OVMF/OVMF_CODE_new.fd
/var/lib/libvirt/qemu/nvram/f20efi_VARS.fd
  

This results in:

qemu -drive 
file=/usr/share/OVMF/OVMF_CODE_new.fd,if=pflash,format=raw,unit=0,readonly=on
\
 -drive 
file=/var/lib/libvirt/qemu/nvram/f20efi_VARS.fd,if=pflash,format=raw,unit=1

This obviously can not pass check in bdrv_all_can_snapshot()
as 'pflash' is RW and raw, i.e. can not be snapshoted.

They have discussed the switch to the following command line:

qemu -drive 
file=/usr/share/OVMF/OVMF_CODE_new.fd,if=pflash,format=raw,unit=0,readonly=on
\
 -drive 
file=/var/lib/libvirt/qemu/nvram/f20efi_VARS.fd.qcow2,if=pflash,format=qcow2,unit=1

and say that in this case VM state could fall into PFLASH
drive which is should not be big as the location of the
file is different. This means that I am doomed here.

Either we should force libvirt people to forget about their
opinion that pflash should be small which I am unable to
do or I should invent a way to ban VM state saving into
pflash.

OK. There are 2 options.

1) Ban pflash as it was done.
2) Add 'no-vmstate' flag to -drive (invented just now).


something like this:

diff --git a/block.c b/block.c
index 3e1877d..8900589 100644
--- a/block.c
+++ b/block.c
@@ -881,6 +881,11 @@ static QemuOptsList bdrv_runtime_opts = {
  .help = "Block driver to use for the node",
  },
  {
+.name = "novmstate",
+.type = QEMU_OPT_BOOL,
+.help = "Ignore for selecting to save VM state",
+},
+{
  .name = BDRV_OPT_CACHE_WB,
  .type = QEMU_OPT_BOOL,
  .help = "Enable writeback mode",
@@ -957,6 +962,7 @@ static int bdrv_open_common(BlockDriverState
*bs, BdrvChild *file,
  bs->request_alignment = 512;
  bs->zero_beyond_eof = true;
  bs->read_only = !(bs->open_flags & BDRV_O_RDWR);
+bs->disable_vmstate_save = qemu_opt_get_bool(opts, "novmstate", false);

  if (use_bdrv_whitelist && !bdrv_is_whitelisted(drv, bs->read_only)) {
  error_setg(errp,
diff --git a/block/snapshot.c b/block/snapshot.c
index 2d86b88..33cdd86 100644
--- a/block/snapshot.c
+++ b/block/snapshot.c
@@ -483,6 +483,10 @@ BlockDriverState *bdrv_all_find_vmstate_bs(void)
  while (not_found && (bs = bdrv_next(bs))) {
  AioContext *ctx = bdrv_get_aio_context(bs);

+if (bs->disable_vmstate_save) {
+continue;
+}
+
  aio_context_acquire(ctx);
  not_found = !bdrv_can_snapshot(bs);
  aio_context_release(ctx);
diff --git a/include/block/block_int.h b/include/block/block_int.h
index 256609d..855a209 100644
--- a/include/block/block_int.h
+++ b/include/block/block_int.h
@@ -438,6 +438,9 @@ struct BlockDriverState {
  /* do we need to tell the quest if we have a volatile write cache? */
  int enable_write_cache;

+/* skip this BDS searching for one to save VM state */
+bool disable_vmstate_save;
+
  /* the following member gives a name to every node on the bs graph. */
 

Re: [Qemu-devel] [PATCH 4/5] block/backup: Add subclassed notifier

[John Snow]

On 01/12/2016 03:46 AM, Paolo Bonzini wrote:
> 
> 
> On 12/01/2016 01:36, John Snow wrote:
>> Instead of relying on peeking at bs->job, we want to explicitly get
>> a reference to the job that was involved in this notifier callback.
>>
>> Extend the Notifier to include a job pointer, and include a reference
>> to the job registering the callback. This cuts out a few more cases
>> where we have to rely on bs->job.
>>
>> Signed-off-by: John Snow 
> 
> Why don't you just put the NotifierWithReturn inside the BackupBlockJob
> struct, and use container_of to get from NWR to BackupBlockJob?
> 
> Paolo
> 

That's another way (including the notifier within the job vs. including
the job within the notifier.) This one simply occurred to me first. Any
strong benefit to that method, or just a matter of style?

--js

Re: [Qemu-devel] [PATCH 1/1] blk: do not select PFLASH device for internal snapshot

[Denis V. Lunev]

On 01/12/2016 08:40 PM, Markus Armbruster wrote:

Kevin Wolf  writes:


Am 12.01.2016 um 17:35 hat Denis V. Lunev geschrieben:

On 01/12/2016 06:47 PM, Denis V. Lunev wrote:

On 01/12/2016 06:20 PM, Kevin Wolf wrote:

Am 12.01.2016 um 15:59 hat Paolo Bonzini geschrieben:

On 12/01/2016 15:16, Kevin Wolf wrote:

Thus we should avoid selection of "pflash" drives for VM
state saving.

For now "pflash" is read-write raw image as it configured by libvirt.
Thus there are no such images in the field and we could
safely disable
ability to save state to those images inside QEMU.

This is obviously broken. If you write to the pflash, then it needs to
be snapshotted in order to keep a consistent state.

If you want to avoid snapshotting the image, make it read-only and it
will be skipped even today.

Sort of.  The point of having flash is to _not_ make it read-only, so
that is not a solution.

Flash is already being snapshotted as part of saving RAM state.  In
fact, for this reason the device (at least the one used with OVMF; I
haven't checked other pflash devices) can simply save it back to disk
on the migration destination, without the need to use "migrate -b" or
shared storage.
[...]
I don't like very much using IF_PFLASH this way, which is why I hadn't
replied to the patch so far---I hadn't made up my mind about *what* to
suggest instead, or whether to just accept it.  However, it does work.

Perhaps a separate "I know what I am doing" skip-snapshot option?  Or
a device callback saying "not snapshotting this is fine"?

Boy, is this ugly...

What do you do with disk-only snapshots? The recovery only works as long
as you have VM state.

Kevin

actually I am in a bit of trouble :(

I understand that this is ugly, but I would like to make working
'virsh snapshot' for OVFM VMs. This is necessary for us to make
a release.

Currently libvirt guys generate XML in the following way:

  
hvm
/usr/share/OVMF/OVMF_CODE_new.fd
/var/lib/libvirt/qemu/nvram/f20efi_VARS.fd
  

This results in:

qemu -drive 
file=/usr/share/OVMF/OVMF_CODE_new.fd,if=pflash,format=raw,unit=0,readonly=on
\
 -drive 
file=/var/lib/libvirt/qemu/nvram/f20efi_VARS.fd,if=pflash,format=raw,unit=1

This obviously can not pass check in bdrv_all_can_snapshot()
as 'pflash' is RW and raw, i.e. can not be snapshoted.

They have discussed the switch to the following command line:

qemu -drive 
file=/usr/share/OVMF/OVMF_CODE_new.fd,if=pflash,format=raw,unit=0,readonly=on
\
 -drive 
file=/var/lib/libvirt/qemu/nvram/f20efi_VARS.fd.qcow2,if=pflash,format=qcow2,unit=1

and say that in this case VM state could fall into PFLASH
drive which is should not be big as the location of the
file is different. This means that I am doomed here.

Either we should force libvirt people to forget about their
opinion that pflash should be small which I am unable to
do or I should invent a way to ban VM state saving into
pflash.

OK. There are 2 options.

1) Ban pflash as it was done.
2) Add 'no-vmstate' flag to -drive (invented just now).


something like this:

diff --git a/block.c b/block.c
index 3e1877d..8900589 100644
--- a/block.c
+++ b/block.c
@@ -881,6 +881,11 @@ static QemuOptsList bdrv_runtime_opts = {
  .help = "Block driver to use for the node",
  },
  {
+.name = "novmstate",
+.type = QEMU_OPT_BOOL,
+.help = "Ignore for selecting to save VM state",
+},
+{
  .name = BDRV_OPT_CACHE_WB,
  .type = QEMU_OPT_BOOL,
  .help = "Enable writeback mode",
@@ -957,6 +962,7 @@ static int bdrv_open_common(BlockDriverState
*bs, BdrvChild *file,
  bs->request_alignment = 512;
  bs->zero_beyond_eof = true;
  bs->read_only = !(bs->open_flags & BDRV_O_RDWR);
+bs->disable_vmstate_save = qemu_opt_get_bool(opts, "novmstate", false);

  if (use_bdrv_whitelist && !bdrv_is_whitelisted(drv, bs->read_only)) {
  error_setg(errp,
diff --git a/block/snapshot.c b/block/snapshot.c
index 2d86b88..33cdd86 100644
--- a/block/snapshot.c
+++ b/block/snapshot.c
@@ -483,6 +483,10 @@ BlockDriverState *bdrv_all_find_vmstate_bs(void)
  while (not_found && (bs = bdrv_next(bs))) {
  AioContext *ctx = bdrv_get_aio_context(bs);

+if (bs->disable_vmstate_save) {
+continue;
+}
+
  aio_context_acquire(ctx);
  not_found = !bdrv_can_snapshot(bs);
  aio_context_release(ctx);
diff --git a/include/block/block_int.h b/include/block/block_int.h
index 256609d..855a209 100644
--- a/include/block/block_int.h
+++ b/include/block/block_int.h
@@ -438,6 +438,9 @@ struct BlockDriverState {
  /* do we need to tell the quest if we have a volatile write cache? */
  int enable_write_cache;

+/* skip this BDS searching for one to save VM state */
+bool disable_vmstate_save;
+
  /* the following member gives a name to every node on the bs graph. */
  char node_name[32];
  /* element of the list of

Re: [Qemu-devel] [PATCH 1/1] blk: do not select PFLASH device for internal snapshot

[Kevin Wolf]

Am 12.01.2016 um 18:40 hat Markus Armbruster geschrieben:
> Kevin Wolf  writes:
> 
> > Am 12.01.2016 um 17:35 hat Denis V. Lunev geschrieben:
> >> On 01/12/2016 06:47 PM, Denis V. Lunev wrote:
> >> >On 01/12/2016 06:20 PM, Kevin Wolf wrote:
> >> >>Am 12.01.2016 um 15:59 hat Paolo Bonzini geschrieben:
> >> >>>
> >> >>>On 12/01/2016 15:16, Kevin Wolf wrote:
> >> >Thus we should avoid selection of "pflash" drives for VM
> >> >state saving.
> >> >
> >> >For now "pflash" is read-write raw image as it configured by libvirt.
> >> >Thus there are no such images in the field and we could
> >> >safely disable
> >> >ability to save state to those images inside QEMU.
> >> This is obviously broken. If you write to the pflash, then it needs to
> >> be snapshotted in order to keep a consistent state.
> >> 
> >> If you want to avoid snapshotting the image, make it read-only and it
> >> will be skipped even today.
> >> >>>Sort of.  The point of having flash is to _not_ make it read-only, so
> >> >>>that is not a solution.
> >> >>>
> >> >>>Flash is already being snapshotted as part of saving RAM state.  In
> >> >>>fact, for this reason the device (at least the one used with OVMF; I
> >> >>>haven't checked other pflash devices) can simply save it back to disk
> >> >>>on the migration destination, without the need to use "migrate -b" or
> >> >>>shared storage.
> >> >>>[...]
> >> >>>I don't like very much using IF_PFLASH this way, which is why I hadn't
> >> >>>replied to the patch so far---I hadn't made up my mind about *what* to
> >> >>>suggest instead, or whether to just accept it.  However, it does work.
> >> >>>
> >> >>>Perhaps a separate "I know what I am doing" skip-snapshot option?  Or
> >> >>>a device callback saying "not snapshotting this is fine"?
> >> >>Boy, is this ugly...
> >> >>
> >> >>What do you do with disk-only snapshots? The recovery only works as long
> >> >>as you have VM state.
> >> >>
> >> >>Kevin
> >> >actually I am in a bit of trouble :(
> >> >
> >> >I understand that this is ugly, but I would like to make working
> >> >'virsh snapshot' for OVFM VMs. This is necessary for us to make
> >> >a release.
> >> >
> >> >Currently libvirt guys generate XML in the following way:
> >> >
> >> >  
> >> >hvm
> >> > >> >type='pflash'>/usr/share/OVMF/OVMF_CODE_new.fd
> >> >/var/lib/libvirt/qemu/nvram/f20efi_VARS.fd
> >> >  
> >> >
> >> >This results in:
> >> >
> >> >qemu -drive 
> >> >file=/usr/share/OVMF/OVMF_CODE_new.fd,if=pflash,format=raw,unit=0,readonly=on
> >> >\
> >> > -drive 
> >> > file=/var/lib/libvirt/qemu/nvram/f20efi_VARS.fd,if=pflash,format=raw,unit=1
> >> >
> >> >This obviously can not pass check in bdrv_all_can_snapshot()
> >> >as 'pflash' is RW and raw, i.e. can not be snapshoted.
> >> >
> >> >They have discussed the switch to the following command line:
> >> >
> >> >qemu -drive 
> >> >file=/usr/share/OVMF/OVMF_CODE_new.fd,if=pflash,format=raw,unit=0,readonly=on
> >> >\
> >> > -drive 
> >> > file=/var/lib/libvirt/qemu/nvram/f20efi_VARS.fd.qcow2,if=pflash,format=qcow2,unit=1
> >> >
> >> >and say that in this case VM state could fall into PFLASH
> >> >drive which is should not be big as the location of the
> >> >file is different. This means that I am doomed here.
> >> >
> >> >Either we should force libvirt people to forget about their
> >> >opinion that pflash should be small which I am unable to
> >> >do or I should invent a way to ban VM state saving into
> >> >pflash.
> >> >
> >> >OK. There are 2 options.
> >> >
> >> >1) Ban pflash as it was done.
> >> >2) Add 'no-vmstate' flag to -drive (invented just now).
> >> >
> >> something like this:
> >> 
> >> diff --git a/block.c b/block.c
> >> index 3e1877d..8900589 100644
> >> --- a/block.c
> >> +++ b/block.c
> >> @@ -881,6 +881,11 @@ static QemuOptsList bdrv_runtime_opts = {
> >>  .help = "Block driver to use for the node",
> >>  },
> >>  {
> >> +.name = "novmstate",
> >> +.type = QEMU_OPT_BOOL,
> >> +.help = "Ignore for selecting to save VM state",
> >> +},
> >> +{
> >>  .name = BDRV_OPT_CACHE_WB,
> >>  .type = QEMU_OPT_BOOL,
> >>  .help = "Enable writeback mode",
> >> @@ -957,6 +962,7 @@ static int bdrv_open_common(BlockDriverState
> >> *bs, BdrvChild *file,
> >>  bs->request_alignment = 512;
> >>  bs->zero_beyond_eof = true;
> >>  bs->read_only = !(bs->open_flags & BDRV_O_RDWR);
> >> +bs->disable_vmstate_save = qemu_opt_get_bool(opts, "novmstate", 
> >> false);
> >> 
> >>  if (use_bdrv_whitelist && !bdrv_is_whitelisted(drv, bs->read_only)) {
> >>  error_setg(errp,
> >> diff --git a/block/snapshot.c b/block/snapshot.c
> >> index 2d86b88..33cdd86 100644
> >> --- a/block/snapshot.c
> >> +++ b/block/snapshot.c
> >> @@ -483,6 +483,10 @@ BlockDriverState *bdrv_all_find_vmstate_bs(void)
> >>  while (not_found && (bs = bdrv_next(bs))) {
> >>