Re: [Qemu-devel] [PATCH v2 3/4] migration: disallow migrate_add_blocker during migration

[Greg Kurz]

Funny... this was v3 and now it is v2 :)

On Sun, 8 Jan 2017 13:04:47 +0530
Ashijeet Acharya  wrote:

> On Friday, January 6, 2017, Greg Kurz  wrote:
> 
> > Hi Ashijeet,
> >
> 
> Hello Greg,
> 
> 
> > I didn't think hard enough while reviewing the changes for hw/9pfs/9p.c...
> > I have
> > some more remarks, sorry... :-/
> >
> > No problem, I will send an updated v4 for these.
> 
> On Wed,  4 Jan 2017 18:02:28 +0530
> > Ashijeet Acharya > wrote:
> >
> > > If a migration is already in progress and somebody attempts
> > > to add a migration blocker, this should rightly fail.
> > >
> > > Add an errp parameter and a retcode return value to migrate_add_blocker.
> > >
> > > Signed-off-by: John Snow >
> > > Signed-off-by: Ashijeet Acharya  > >
> > > ---
> > >  block/qcow.c  |  6 +-
> > >  block/vdi.c   |  6 +-
> > >  block/vhdx.c  | 16 ++--
> > >  block/vmdk.c  |  7 ++-
> > >  block/vpc.c   | 10 +++---
> > >  block/vvfat.c | 20 
> > >  hw/9pfs/9p.c  | 20 +++-
> > >  hw/display/virtio-gpu.c   | 29 -
> > >  hw/intc/arm_gic_kvm.c | 16 ++--
> > >  hw/intc/arm_gicv3_its_kvm.c   | 18 +++---
> > >  hw/intc/arm_gicv3_kvm.c   | 19 ---
> > >  hw/misc/ivshmem.c | 11 +++
> > >  hw/scsi/vhost-scsi.c  | 25 +++--
> > >  hw/virtio/vhost.c |  8 +++-
> > >  include/migration/migration.h |  6 +-
> > >  migration/migration.c | 35 +--
> > >  stubs/migr-blocker.c  |  3 ++-
> > >  target-i386/kvm.c | 16 +---
> > >  18 files changed, 195 insertions(+), 76 deletions(-)
> > >
> > > diff --git a/block/qcow.c b/block/qcow.c
> > > index 7540f43..11526a1 100644
> > > --- a/block/qcow.c
> > > +++ b/block/qcow.c
> > > @@ -252,7 +252,11 @@ static int qcow_open(BlockDriverState *bs, QDict
> > *options, int flags,
> > >  error_setg(>migration_blocker, "The qcow format used by node
> > '%s' "
> > > "does not support live migration",
> > > bdrv_get_device_or_node_name(bs));
> > > -migrate_add_blocker(s->migration_blocker);
> > > +ret = migrate_add_blocker(s->migration_blocker, errp);
> > > +if (ret < 0) {
> > > +error_free(s->migration_blocker);
> > > +goto fail;
> > > +}
> > >
> > >  qemu_co_mutex_init(>lock);
> > >  return 0;
> > > diff --git a/block/vdi.c b/block/vdi.c
> > > index 96b78d5..2b56f52 100644
> > > --- a/block/vdi.c
> > > +++ b/block/vdi.c
> > > @@ -471,7 +471,11 @@ static int vdi_open(BlockDriverState *bs, QDict
> > *options, int flags,
> > >  error_setg(>migration_blocker, "The vdi format used by node
> > '%s' "
> > > "does not support live migration",
> > > bdrv_get_device_or_node_name(bs));
> > > -migrate_add_blocker(s->migration_blocker);
> > > +ret = migrate_add_blocker(s->migration_blocker, errp);
> > > +if (ret < 0) {
> > > +error_free(s->migration_blocker);
> > > +goto fail_free_bmap;
> > > +}
> > >
> > >  qemu_co_mutex_init(>write_lock);
> > >
> > > diff --git a/block/vhdx.c b/block/vhdx.c
> > > index 0ba2f0a..d81941b 100644
> > > --- a/block/vhdx.c
> > > +++ b/block/vhdx.c
> > > @@ -991,6 +991,16 @@ static int vhdx_open(BlockDriverState *bs, QDict
> > *options, int flags,
> > >  }
> > >  }
> > >
> > > +/* Disable migration when VHDX images are used */
> > > +error_setg(>migration_blocker, "The vhdx format used by node
> > '%s' "
> > > +   "does not support live migration",
> > > +   bdrv_get_device_or_node_name(bs));
> > > +ret = migrate_add_blocker(s->migration_blocker, errp);
> > > +if (ret < 0) {
> > > +error_free(s->migration_blocker);
> > > +goto fail;
> > > +}
> > > +
> > >  if (flags & BDRV_O_RDWR) {
> > >  ret = vhdx_update_headers(bs, s, false, NULL);
> > >  if (ret < 0) {
> > > @@ -1000,12 +1010,6 @@ static int vhdx_open(BlockDriverState *bs, QDict
> > *options, int flags,
> > >
> > >  /* TODO: differencing files */
> > >
> > > -/* Disable migration when VHDX images are used */
> > > -error_setg(>migration_blocker, "The vhdx format used by node
> > '%s' "
> > > -   "does not support live migration",
> > > -   bdrv_get_device_or_node_name(bs));
> > > -migrate_add_blocker(s->migration_blocker);
> > > -
> > >  return 0;
> > >  fail:
> > >  vhdx_close(bs);
> > > diff --git a/block/vmdk.c b/block/vmdk.c
> > > index a11c27a..4a45a83 100644
> > > --- a/block/vmdk.c
> > > +++ b/block/vmdk.c

[Qemu-devel] [Bug 1654826] Re: Holding key down using input-linux freezes guest

[Gerd Hoffmann]

quick workaround: drop "repeat=on".
some guests seem to have problems with that, not debugged yet why.

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

Title:
  Holding key down using input-linux freezes guest

Status in QEMU:
  New

Bug description:
  Qemu release version 2.8.0
  KVM, kernel 4.9.1

  When using the -object input-linux capability in qemu for passthrough
  of input/evdev devices, I found that when a key is held for a few
  seconds or more (such as ctrl key), the guest system freezes until the
  key is released. In some cases, mouse control is also lost following
  one of these "freezes". I also noticed that one of the four cpu cores
  I have the guest pinned to ramps to 100% during these freezes.

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

Re: [Qemu-devel] [PATCH 08/17] wctablet: drop debug code from wctablet_handler

[Gerd Hoffmann]

On Fr, 2017-01-06 at 07:17 -0600, Eric Blake wrote:
> On 01/06/2017 02:55 AM, Gerd Hoffmann wrote:
> > Signed-off-by: Gerd Hoffmann 
> > ---
> >  backends/wctablet.c | 6 --
> >  1 file changed, 6 deletions(-)
> 
> Why not just squash this into 1/17?

My intention is to keep the submission by Anatoli separate from the
cleanups and improvements I did.  Also in case I introduced any
regressions it is easier to figure which change broke things this way.

For the actual merge it probably makes sense to just squash the whole
series into a single patch.

cheers,
  Gerd

Re: [Qemu-devel] [Qemu-ppc] [PATCH v3 0/4] ppc: add a IBM 40p machine (RS/6000, PReP)

[Thomas Huth]

On 07.01.2017 16:23, Hervé Poussineau wrote:
> Hi,
> 
> This patchset adds the emulation of the IBM RS/6000 7020 (40p). The real 
> machine is
> able to run AIX (up to 4.3.3), Windows NT (up to 4.0 SP1), the beta of OS/2 
> PowerPC,
> Solaris, Linux, NetBSD/PReP ...
> 
> I've tested current emulation with Open Hack'Ware, OpenBIOS and official 
> firmware.
> 
> Linux kernel starts, and freezes during boot (seems like a problem with the 
> SCSI adapter).
> Windows NT starts up to the point where it wants to change endianness.
> Other OSes have not been tested.
> 
> This machine is a superset of the 'prep' one, because we know exactly what 
> is/should
> emulated, and that operating system list running on it is quite wide.
> I hope that 'prep' machine can be deprecated soon and then later removed.
> 
> Patch 1 is a cleanup, and can probably be committed first.
> Patches 2 to 4  are the real implementation of the IBM 40p.
> 
> Changes since v2:
> - patch 2: fix mismatch between read and write functions for port 92
> - patch 4: use error_report instead of fprintf/hw_error
> 
> Changes since v1:
> - removed patches related to display adapter:
>   Let's wait for an emulation of the real display adapter (an S3 Trio), as 
> current
>   VGA adapter already mostly works with Open Hack'Ware and OpenBIOS
> - various changes due to David Gibson's remarks
> 
> Hervé Poussineau (4):
>   prep: do not use global variable to access nvram
>   prep: add PReP System I/O
>   prep: add IBM RS/6000 7020 (40p) memory controller
>   prep: add IBM RS/6000 7020 (40p) machine emulation
> 
>  default-configs/ppc-softmmu.mak |   2 +
>  hw/ppc/Makefile.objs|   2 +
>  hw/ppc/prep.c   | 233 +-
>  hw/ppc/prep_systemio.c  | 303 
> 
>  hw/ppc/rs6000_mc.c  | 232 ++
>  hw/ppc/trace-events |  11 ++
>  6 files changed, 781 insertions(+), 2 deletions(-)
>  create mode 100644 hw/ppc/prep_systemio.c
>  create mode 100644 hw/ppc/rs6000_mc.c

By the way, the PReP machine currently does not have a proper maintainer
according to the MAINTAINERS file ... would you maybe volunteer to do
that job? If so, could you please send a patch for the MAINTAINERS file?

 Thomas

Re: [Qemu-devel] [PATCH] hw/pci: use-after-free in pci_nic_init_nofail when nic device fails to initialize

[Alex Kompel]

Looks like this line got wrapped: "@@ -1805,13 +1805,7 @@ PCIDevice
*pci_nic_init_nofail(NICInfo *nd, PCIBus *rootbus,"
Sorry about that. Could you unwrap it or use the attached text file?

Thanks,
-Alex

On Sun, Jan 8, 2017 at 8:06 PM, Jason Wang  wrote:
>
>
> On 2017年01月07日 07:48, Alex Kompel wrote:
>>
>> object_property_set_bool(OBJECT(dev), true, "realized", ) in
>> pci_nic_init_nofail may release the object if device fails to
>> initialize which leads to use-after-free in error handling block.
>> qdev_init_nofail does the same thing while holding the reference.
>>
>> (gdb) run -net nic
>> qemu-system-x86_64: failed to find romfile "efi-e1000.rom"
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> object_unparent (obj=0x7fffe96a0010) at qom/object.c:440
>> 440 in qom/object.c
>> (gdb) bt
>> #0  object_unparent (obj=0x7fffe96a0010) at qom/object.c:440
>> #1  0x5598c30d in pci_nic_init_nofail (nd=0x5616b460
>> , rootbus=0x567ed990, default_model=,
>> default_devaddr=) at hw/pci/pci.c:1812
>> #2  0x557ff52c in pc_nic_init (isa_bus=0x5733c610,
>> pci_bus=0x567ed990) at hw/i386/pc.c:1634
>> #3  0x558021ad in pc_init1 (machine=0x5661ee10,
>> pci_type=0x55c1a523 "i440FX", host_type=0x55ba564e
>> "i440FX-pcihost") at hw/i386/pc_piix.c:241
>> #4  0x557519cb in main (argc=, argv=> out>, envp=) at vl.c:4481
>>
>> Signed-off-by: Alex Kompel 
>> ---
>>   hw/pci/pci.c | 8 +---
>>   1 file changed, 1 insertion(+), 7 deletions(-)
>>
>> diff --git a/hw/pci/pci.c b/hw/pci/pci.c
>> index 24fae16..2fd1b9e 100644
>> --- a/hw/pci/pci.c
>> +++ b/hw/pci/pci.c
>> @@ -1805,13 +1805,7 @@ PCIDevice *pci_nic_init_nofail(NICInfo *nd,
>> PCIBus *rootbus,
>
>
> Hello, looks like the patch were corrupted possibly by your email client.
> Please check, we usually send patch through git send-email.
>
> Thanks
>
>
>>   pci_dev = pci_create(bus, devfn, pci_nic_names[i]);
>>   dev = _dev->qdev;
>>   qdev_set_nic_properties(dev, nd);
>> -
>> -object_property_set_bool(OBJECT(dev), true, "realized", );
>> -if (err) {
>> -error_report_err(err);
>> -object_unparent(OBJECT(dev));
>> -exit(1);
>> -}
>> +qdev_init_nofail(dev);
>>
>>   return pci_dev;
>>   }
>> --
>> 2.8.3
>>
>
Signed-off-by: Alex Kompel 
---
 hw/pci/pci.c | 8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/hw/pci/pci.c b/hw/pci/pci.c
index 24fae16..2fd1b9e 100644
--- a/hw/pci/pci.c
+++ b/hw/pci/pci.c
@@ -1805,13 +1805,7 @@ PCIDevice *pci_nic_init_nofail(NICInfo *nd, PCIBus 
*rootbus,
 pci_dev = pci_create(bus, devfn, pci_nic_names[i]);
 dev = _dev->qdev;
 qdev_set_nic_properties(dev, nd);
-
-object_property_set_bool(OBJECT(dev), true, "realized", );
-if (err) {
-error_report_err(err);
-object_unparent(OBJECT(dev));
-exit(1);
-}
+qdev_init_nofail(dev);
 
 return pci_dev;
 }
-- 
2.8.3

[Qemu-devel] Question about add AF_ALG backend for virtio-crypto

[Longpeng (Mike)]

Hi guys,

I'm one of Gonglei's virtio-crypto project members, and we plan to add a AF_ALG
backend for virtio-crypto(there's only builtin-backend currently).

I found that Catalin, Paolo and Stefan had discussed about this in 2015
(http://www.spinics.net/lists/kvm/msg115457.html), but it seems that Catalin
didn't do it, so I'm confuse about wether it is need to add a AF_ALG backend.

Do you have any suggestion? Thanks :)

-- 
Regards,
Longpeng(Mike)

Re: [Qemu-devel] [PATCH v1 00/14] POWER9 TCG enablements - part10

[Nikunj A Dadhania]

David Gibson  writes:

> [ Unknown signature status ]
> On Fri, Jan 06, 2017 at 11:44:42AM +0530, Nikunj A Dadhania wrote:
>> This series contains 11 new instructions for POWER9 ISA3.0
>>  VSX Vector Insert/Extract Word
>>  VSX Scalar Extract Exponent/Significand
>>  VSX Scalar Convert
>>  VSX Scalar Add QP
>>  Various float related improvements
>
> Applied to ppc-for-2.9, thanks.

Found issue in register numbering in 3 instructions.
xsaddqp
xscvdpqp
xscvqpdp

Please drop following:

  target-ppc: Add xsaddqp instructions
  target-ppc: Add xscvdpqp instruction
  target-ppc: Add xscvqpdp instruction

I will resend them.

Regards
Nikunj

Re: [Qemu-devel] [PATCH v5 3/4] Plumb the HAXM-based hardware acceleration support

[Yu Ning]

On 1/6/2017 5:38, Paolo Bonzini wrote:


On 05/01/2017 15:01, Paolo Bonzini wrote:


In fact there is a race anyway:

 if (cpu->exit_request) {
 ret = 1;
 break;
 }
cpu->exit_request
SuspendThread
ResumeThread
 hax_vcpu_interrupt(env);
 qemu_mutex_unlock_iothread();
 hax_ret = hax_vcpu_run(vcpu);

and the same race is true for QueueUserAPC.  It's rare enough that I
guess we can accept the patches with just a FIXME comment, but...  Yu
Ning, can you tell us what user_event_pending is for? :)  My hunch is
that we should call hax_raise_event after setting cpu->exit_request, like

hax_raise_event();
/* write user_event_pending before exit_request */
smp_wmb();
cpu->exit_request = 1;
SuspendThread/ResumeThread
(or QueueUserAPC)

and in the hax thread:

 if (cpu->exit_request) {
cpu->hax_vcpu->tunnel->user_event_pending = 0;
 ret = 1;
 break;
 }

 hax_vcpu_interrupt(env);
 qemu_mutex_unlock_iothread();

/* read exit_request before user_event_pending */
smp_rmb();
 hax_ret = hax_vcpu_run(vcpu);

but I would like some more official documentation than my own reverse
engineering of the brain of whoever wrote the interface (I have not
looked at the HAXM driver binary).


Unfortunately, user_event_pending was introduced in 2011 without proper 
documentation, so I guess even the original author might not have an 
answer now (even if I could find him).  I need more time to analyze the 
HAXM driver code to understand what it's about.  Please feel free to add 
a FIXME for now.


But one thing I've noticed is that the Darwin driver does not test or 
reset this flag properly - it will remain 1 after the first 
hax_raise_event() call.  So removing user_event_pending from the QEMU 
side should not affect Mac.

Re: [Qemu-devel] [PATCH] hw/pci: use-after-free in pci_nic_init_nofail when nic device fails to initialize

[Jason Wang]

On 2017年01月09日 13:26, Alex Kompel wrote:

Looks like this line got wrapped: "@@ -1805,13 +1805,7 @@ PCIDevice
*pci_nic_init_nofail(NICInfo *nd, PCIBus *rootbus,"
Sorry about that. Could you unwrap it or use the attached text file?

Thanks,
-Alex


Ok, applied. But please use git format-patch and git send-email for 
future submission of patches.


Thanks



On Sun, Jan 8, 2017 at 8:06 PM, Jason Wang  wrote:


On 2017年01月07日 07:48, Alex Kompel wrote:

object_property_set_bool(OBJECT(dev), true, "realized", ) in
pci_nic_init_nofail may release the object if device fails to
initialize which leads to use-after-free in error handling block.
qdev_init_nofail does the same thing while holding the reference.

(gdb) run -net nic
qemu-system-x86_64: failed to find romfile "efi-e1000.rom"

Program received signal SIGSEGV, Segmentation fault.
object_unparent (obj=0x7fffe96a0010) at qom/object.c:440
440 in qom/object.c
(gdb) bt
#0  object_unparent (obj=0x7fffe96a0010) at qom/object.c:440
#1  0x5598c30d in pci_nic_init_nofail (nd=0x5616b460
, rootbus=0x567ed990, default_model=,
default_devaddr=) at hw/pci/pci.c:1812
#2  0x557ff52c in pc_nic_init (isa_bus=0x5733c610,
pci_bus=0x567ed990) at hw/i386/pc.c:1634
#3  0x558021ad in pc_init1 (machine=0x5661ee10,
pci_type=0x55c1a523 "i440FX", host_type=0x55ba564e
"i440FX-pcihost") at hw/i386/pc_piix.c:241
#4  0x557519cb in main (argc=, argv=, envp=) at vl.c:4481

Signed-off-by: Alex Kompel 
---
   hw/pci/pci.c | 8 +---
   1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/hw/pci/pci.c b/hw/pci/pci.c
index 24fae16..2fd1b9e 100644
--- a/hw/pci/pci.c
+++ b/hw/pci/pci.c
@@ -1805,13 +1805,7 @@ PCIDevice *pci_nic_init_nofail(NICInfo *nd,
PCIBus *rootbus,


Hello, looks like the patch were corrupted possibly by your email client.
Please check, we usually send patch through git send-email.

Thanks



   pci_dev = pci_create(bus, devfn, pci_nic_names[i]);
   dev = _dev->qdev;
   qdev_set_nic_properties(dev, nd);
-
-object_property_set_bool(OBJECT(dev), true, "realized", );
-if (err) {
-error_report_err(err);
-object_unparent(OBJECT(dev));
-exit(1);
-}
+qdev_init_nofail(dev);

   return pci_dev;
   }
--
2.8.3

Re: [Qemu-devel] [RESEND Patch v1 00/37] Implementation of vhost-pci for inter-vm commucation

[Wei Wang]

Hi Marc-André,

Do you have any comments on the responses? Thanks.

On 12/20/2016 12:32 PM, Wei Wang wrote:

Hi Marc-André, thanks for the comments.

On 12/20/2016 12:43 AM, Marc-André Lureau wrote:

Hi Wei,

On Mon, Dec 19, 2016 at 7:00 AM Wei Wang > wrote:


This patch series implements vhost-pci, which is a point-to-point
based inter-vm
communication solution. The QEMU side implementation includes the
vhost-user
extension, vhost-pci device emulation and management. The current
device part
implementation is based on virtio 1.0, but it can be easily
upgraded to support
the upcoming virtio 1.1.

The current QEMU implementation supports the polling mode driver
on both sides
to receive packets. More features, such as interrupt support, live
migration
support, protected memory accesses will be added later.



I highly appreciate the effort you put in splitting the patch series 
and commenting each, although some are probably superfluous.


I will see if I can combine some of the unnecessary splits in the next 
version.


High level question, why do you need to create device dynamically? I 
would rather have the following qemu setup:


-chardev socket,id=chr,path=.. -device vhost-pci-net,chardev=chr

This would also avoid some global state (vp_slave etc)


With the above commands, the slave QEMU will create and plug in the 
vhost-pci-net device at the QEMU booting time. I think this won't 
work, because at the slave QEMU booting time, the master, in most 
cases, hasn't connected to the slave to transmit the info (e.g. memory 
info) that's required for the device setup - for example, the device 
bar can't be constructed without the memory info passed from the 
master, and if the device is created and plugged in the VM without a 
bar at the beginning, I think we don't have another chance to add a 
bar on the fly when the device is already driven in the guest. That's 
the reason that I get a global vp_slave to manage (dynamically 
create/destroy a device when requested by the master) the vhost-pci 
device.




Regarding the protocol changes to support slave request: I tried to 
explained that before, apprently I didn't manage to. It is not enough 
to support bidirectionnal communications to simply add chardev 
frontend handlers. Until now, qemu's code expects an immediate reply 
after a request. With your protocol change, it must now also consider 
that the slave may send a request before the master request reaches 
the slave handler. So all req/reply write()/read() must now handle in 
between requests from slave to be race-free (master can read back a 
request when it expects a reply). That's not really trivial change, 
that's why I proposed to have a secondary channel for slave->master 
communications in the past. Not only would this be easier to 
implement, but the protocol documentation would also be simpler, the 
cost is simply 1 additional unix socket (that I proposed to setup and 
pass with ancilliary data on the main channel).


I don't disagree with the second channel method. That implementation 
hasn't been in the upstream QEMU yet, are you planning to get it in 
first, so that we can upstream vhost-pci based on that?




RESEND change: Fixed some coding style issue


there are some spelling to be fixed, and perhaps some 
variables/fields to rename  (asyn -> async, crq -> ctrlq?) That can 
be addressed in a detailed review.


Sure, I will fix them.


Best,
Wei

[Qemu-devel] [Bug 597351] Re: Slow UDP performance with virtio device

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
   Status: Incomplete => Expired

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

Title:
  Slow UDP performance with virtio device

Status in QEMU:
  Expired

Bug description:
  I'm working on an app that is very sensitive to round-trip latency
  between the guest and host, and qemu/kvm seems to be significantly
  slower than it needs to be.

  The attached program is a ping/pong over UDP.  Call it with a single
  argument to start a listener/echo server on that port.  With three
  arguments it becomes a counted "pinger" that will exit after a
  specified number of round trips for performance measurements.  For
  example:

$ gcc -o udp-pong udp-pong.c
$ ./udp-pong 12345 &   # start a listener on port 12345
$ time ./udp-pong 127.0.0.1 12345 100  # time a million round trips

  When run on the loopback device on a single machine (true on the host
  or within a guest), I get about 100k/s.

  When run across a port forward using "user" networking on qemu (or
  kvm, the performance is the same) and the default rtl8139 driver (both
  the host and guest are Ubuntu Lucid), I get about 10k/s.  This seems
  very slow, but perhaps unavoidably so?

  When run in the same configuration using the "virtio" driver, I get
  only 2k/s.  This is almost certainly a bug in the virtio driver, given
  that it's a paravirtualized device that is 5x slower than the "slow"
  hardware emulation.

  I get no meaningful change in performance between kvm/qemu.

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

[Qemu-devel] [Bug 881637] Re: QEMU fails to build on OpenBSD/hppa

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
   Status: Incomplete => Expired

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

Title:
  QEMU fails to build on OpenBSD/hppa

Status in QEMU:
  Expired

Bug description:
  Trying to build previous QEMU releases as well as git code fails on
  OpenBSD/hppa...

  cc -I/home/hack/jasper/qemu/slirp -I. -I/home/hack/jasper/qemu 
-I/home/hack/jasper/qemu/fpu -I/home/hack/jasper/qemu/tcg 
-I/home/hack/jasper/qemu/tcg/hppa  -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE 
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes 
-Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes 
-fno-strict-aliasing -Wno-redundant-decls -I/usr/local/include 
-I/usr/X11R6/include -Wendif-labels -Wmissing-include-dirs -Wnested-externs 
-Wformat-security -Wformat-y2k -Winit-self -Wold-style-definition 
-I/usr/local/include/libpng -DHAS_AUDIO -DHAS_AUDIO_CHOICE  
-DTARGET_PHYS_ADDR_BITS=64 -I.. -I/home/hack/jasper/qemu/target-i386 
-DNEED_CPU_H -pthread -I/usr/local/include/glib-2.0 
-I/usr/local/lib/glib-2.0/include-I/usr/local/include/libpng -pthread 
-I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -MMD -MP -MT 
translate.o -MF ./translate.d -O2 -g  -c -o translate.o 
/home/hack/jasper/qemu/target-i386/translate.c
  /tmp//ccvNbj1U.s: Assembler messages:
  /tmp//ccvNbj1U.s:258792: Error: Field out of range [-262144..262143] 
(-262776).
  /tmp//ccvNbj1U.s:261989: Error: Field out of range [-262144..262143] 
(-267096).
  /tmp//ccvNbj1U.s:262006: Error: Field out of range [-262144..262143] 
(-267136).
  /tmp//ccvNbj1U.s:264184: Error: Field out of range [-262144..262143] 
(-270612).
  /tmp//ccvNbj1U.s:271893: Error: Field out of range [-262144..262143] 
(-281260).
  /tmp//ccvNbj1U.s:276623: Error: Field out of range [-262144..262143] 
(-288784).
  /tmp//ccvNbj1U.s:276906: Error: Field out of range [-262144..262143] 
(-289636).
  /tmp//ccvNbj1U.s:277122: Error: Field out of range [-262144..262143] 
(-290280).

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

[Qemu-devel] [Bug 680758] Re: balloon only resizes by 2M

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
   Status: Incomplete => Expired

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

Title:
  balloon only resizes by 2M

Status in QEMU:
  Expired

Bug description:
  when in monitor and running balloon 512 from a 1024M VM, the vm
  dropped the size to 1020 (this value changes), then every subsequent
  request to balloon 512 will drop it by another 2M.  The system was
  running at above 60% RAM free when these requests were made.  also
  requesting to up the ram results in no change above 1024 (I'm guessing
  this is intentional, but was unable to find any documentation)

  Versions:

  qemu-kvm 0.13.0
  qemu-kvm.git b377474e589e5a1fe2abc7b13fafa8bad802637a

  Qemu Command Line:

  ./x86_64-softmmu/qemu-system-x86_64 -drive
  file=/var/machines/seven.base,if=virtio -net
  nic,model=virtio,macaddr=02:00:00:00:00:01 -net tap,script=/etc/qemu
  /qemu-ifup,downscript=/etc/qemu/qemu-ifdown -vga std -usb -usbdevice
  tablet -rtc base=localtime,clock=host -watchdog i6300esb -balloon
  virtio -m 1024 -no-quit -smp 2 -monitor stdio

  Monitor Session:

  QEMU 0.13.50 monitor - type 'help' for more information
  (qemu) info balloon
  balloon: actual=1024
  (qemu) balloon 1536
  (qemu) info balloon
  balloon: actual=1024
  (qemu) balloon 512
  (qemu) info balloon
  balloon: actual=1020
  (qemu) info balloon
  balloon: actual=1020
  (qemu) balloon 512
  (qemu) info balloon
  balloon: actual=1018

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

[Qemu-devel] [Bug 772275] Re: qemu-kvm-0.14.0 + kernel 2.6.35 : win2008r2 virtio nic hanging

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
   Status: Incomplete => Expired

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

Title:
  qemu-kvm-0.14.0 + kernel 2.6.35 : win2008r2 virtio nic hanging

Status in QEMU:
  Expired

Bug description:
  Hi,

  I'm a proxmox distrib user,

  I have network error with virtio nic cards in win2008r2sp1 server,
  only with qemu 0.14 and 2.6.35 kernel combination.

  after some network transferts (can be 2mb or 500mb), nic doesn't
  respond anymore. only way is to reboot.

  e1000 driver working fine.

  revert back to qemu 0.13+ 2.6.35 kernel works fine  or qemu 0.14 +
  2.6.32 kernel is working fine too.

  i'm using virtio nic drivers 1.1.16 from
  http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/

  i had also tried the virtio-win-prewhql-0.1-7-nic.tar.gz from
  https://bugzilla.redhat.com/show_bug.cgi?id=630830#c26

  i'm not the only proxmox user ,more users reports here :

  http://forum.proxmox.com/threads/6194-Troubles-with-latest-virtio-
  drivers-for-Windows-and-latest-PVE-1.8

  i've also see that a slackware user with winxp guest has the same
  problem

  http://www.spinics.net/lists/kvm/msg51089.html

  
  I can help to debug if it's possible to have logs somewhere .

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

Re: [Qemu-devel] [PATCH] hw/pci: use-after-free in pci_nic_init_nofail when nic device fails to initialize

[Jason Wang]

On 2017年01月07日 07:48, Alex Kompel wrote:

object_property_set_bool(OBJECT(dev), true, "realized", ) in
pci_nic_init_nofail may release the object if device fails to
initialize which leads to use-after-free in error handling block.
qdev_init_nofail does the same thing while holding the reference.

(gdb) run -net nic
qemu-system-x86_64: failed to find romfile "efi-e1000.rom"

Program received signal SIGSEGV, Segmentation fault.
object_unparent (obj=0x7fffe96a0010) at qom/object.c:440
440 in qom/object.c
(gdb) bt
#0  object_unparent (obj=0x7fffe96a0010) at qom/object.c:440
#1  0x5598c30d in pci_nic_init_nofail (nd=0x5616b460
, rootbus=0x567ed990, default_model=,
default_devaddr=) at hw/pci/pci.c:1812
#2  0x557ff52c in pc_nic_init (isa_bus=0x5733c610,
pci_bus=0x567ed990) at hw/i386/pc.c:1634
#3  0x558021ad in pc_init1 (machine=0x5661ee10,
pci_type=0x55c1a523 "i440FX", host_type=0x55ba564e
"i440FX-pcihost") at hw/i386/pc_piix.c:241
#4  0x557519cb in main (argc=, argv=, envp=) at vl.c:4481

Signed-off-by: Alex Kompel 
---
  hw/pci/pci.c | 8 +---
  1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/hw/pci/pci.c b/hw/pci/pci.c
index 24fae16..2fd1b9e 100644
--- a/hw/pci/pci.c
+++ b/hw/pci/pci.c
@@ -1805,13 +1805,7 @@ PCIDevice *pci_nic_init_nofail(NICInfo *nd,
PCIBus *rootbus,


Hello, looks like the patch were corrupted possibly by your email 
client. Please check, we usually send patch through git send-email.


Thanks


  pci_dev = pci_create(bus, devfn, pci_nic_names[i]);
  dev = _dev->qdev;
  qdev_set_nic_properties(dev, nd);
-
-object_property_set_bool(OBJECT(dev), true, "realized", );
-if (err) {
-error_report_err(err);
-object_unparent(OBJECT(dev));
-exit(1);
-}
+qdev_init_nofail(dev);

  return pci_dev;
  }
--
2.8.3

[Qemu-devel] [kvm-unit-tests PATCH v4 1/2] run_tests: put logs into per-test file

[Peter Xu]

We were using test.log before to keep all the test logs. This patch
creates one log file per test case under logs/ directory with name
"TESTNAME.log". Meanwhile, we will keep the last time log into
logs.old/.

Renaming scripts/functions.bash into scripts/common.bash to store some
more global variables.

Signed-off-by: Peter Xu 
---
 .gitignore  |  3 ++-
 Makefile|  4 ++--
 run_tests.sh| 22 +++---
 scripts/{functions.bash => common.bash} | 13 +++--
 scripts/mkstandalone.sh |  2 +-
 5 files changed, 31 insertions(+), 13 deletions(-)
 rename scripts/{functions.bash => common.bash} (75%)

diff --git a/.gitignore b/.gitignore
index 3155418..0dc9a39 100644
--- a/.gitignore
+++ b/.gitignore
@@ -12,7 +12,8 @@ cscope.*
 /lib/asm
 /config.mak
 /*-run
-/test.log
 /msr.out
 /tests
 /build-head
+logs
+logs.old
diff --git a/Makefile b/Makefile
index a32333b..bd8843a 100644
--- a/Makefile
+++ b/Makefile
@@ -94,9 +94,9 @@ libfdt_clean:
$(LIBFDT_objdir)/.*.d
 
 distclean: clean libfdt_clean
-   $(RM) lib/asm config.mak $(TEST_DIR)-run test.log msr.out cscope.* \
+   $(RM) lib/asm config.mak $(TEST_DIR)-run msr.out cscope.* \
  build-head
-   $(RM) -r tests
+   $(RM) -r tests logs logs.old
 
 cscope: cscope_dirs = lib lib/libfdt lib/linux $(TEST_DIR) $(ARCH_LIBDIRS) 
lib/asm-generic
 cscope:
diff --git a/run_tests.sh b/run_tests.sh
index 254129d..1e36d66 100755
--- a/run_tests.sh
+++ b/run_tests.sh
@@ -7,7 +7,7 @@ if [ ! -f config.mak ]; then
 exit 1
 fi
 source config.mak
-source scripts/functions.bash
+source scripts/common.bash
 
 function usage()
 {
@@ -46,17 +46,25 @@ while getopts "g:hv" opt; do
 esac
 done
 
-RUNTIME_log_stderr () { cat >> test.log; }
+# RUNTIME_log_file will be configured later
+RUNTIME_log_stderr () { cat >> $RUNTIME_log_file; }
 RUNTIME_log_stdout () {
 if [ "$PRETTY_PRINT_STACKS" = "yes" ]; then
-./scripts/pretty_print_stacks.py $1 >> test.log
+./scripts/pretty_print_stacks.py $1 >> $RUNTIME_log_file
 else
-cat >> test.log
+cat >> $RUNTIME_log_file
 fi
 }
 
-
 config=$TEST_DIR/unittests.cfg
-rm -f test.log
-printf "BUILD_HEAD=$(cat build-head)\n\n" > test.log
+
+rm -rf $unittest_log_dir.old
+if ! mv $unittest_log_dir $unittest_log_dir.log; then
+echo "Failed to backup $unittest_log_dir"
+exit 2
+fi
+
+mkdir $unittest_log_dir
+echo "BUILD_HEAD=$(cat build-head)" > $unittest_log_dir/SUMMARY
+
 for_each_unittest $config run
diff --git a/scripts/functions.bash b/scripts/common.bash
similarity index 75%
rename from scripts/functions.bash
rename to scripts/common.bash
index ee9143c..2dd7360 100644
--- a/scripts/functions.bash
+++ b/scripts/common.bash
@@ -1,3 +1,12 @@
+: ${unittest_log_dir:=logs}
+
+function run_task()
+{
+   local testname="$2"
+
+   RUNTIME_log_file="${unittest_log_dir}/${testname}.log"
+   "$@"
+}
 
 function for_each_unittest()
 {
@@ -17,7 +26,7 @@ function for_each_unittest()
 
while read -u $fd line; do
if [[ "$line" =~ ^\[(.*)\]$ ]]; then
-   "$cmd" "$testname" "$groups" "$smp" "$kernel" "$opts" 
"$arch" "$check" "$accel" "$timeout"
+   run_task "$cmd" "$testname" "$groups" "$smp" "$kernel" 
"$opts" "$arch" "$check" "$accel" "$timeout"
testname=${BASH_REMATCH[1]}
smp=1
kernel=""
@@ -45,6 +54,6 @@ function for_each_unittest()
timeout=${BASH_REMATCH[1]}
fi
done
-   "$cmd" "$testname" "$groups" "$smp" "$kernel" "$opts" "$arch" "$check" 
"$accel" "$timeout"
+   run_task "$cmd" "$testname" "$groups" "$smp" "$kernel" "$opts" "$arch" 
"$check" "$accel" "$timeout"
exec {fd}<&-
 }
diff --git a/scripts/mkstandalone.sh b/scripts/mkstandalone.sh
index d2bae19..3c1938e 100755
--- a/scripts/mkstandalone.sh
+++ b/scripts/mkstandalone.sh
@@ -5,7 +5,7 @@ if [ ! -f config.mak ]; then
exit 1
 fi
 source config.mak
-source scripts/functions.bash
+source scripts/common.bash
 
 escape ()
 {
-- 
2.7.4

Re: [Qemu-devel] [PATCH] hw/pci: use-after-free in pci_nic_init_nofail when nic device fails to initialize

[Jason Wang]

On 2017年01月08日 12:00, Michael S. Tsirkin wrote:

On Fri, Jan 06, 2017 at 03:48:27PM -0800, Alex Kompel wrote:

object_property_set_bool(OBJECT(dev), true, "realized", ) in
pci_nic_init_nofail may release the object if device fails to
initialize which leads to use-after-free in error handling block.
qdev_init_nofail does the same thing while holding the reference.

(gdb) run -net nic
qemu-system-x86_64: failed to find romfile "efi-e1000.rom"

Program received signal SIGSEGV, Segmentation fault.
object_unparent (obj=0x7fffe96a0010) at qom/object.c:440
440 in qom/object.c
(gdb) bt
#0  object_unparent (obj=0x7fffe96a0010) at qom/object.c:440
#1  0x5598c30d in pci_nic_init_nofail (nd=0x5616b460
, rootbus=0x567ed990, default_model=,
default_devaddr=) at hw/pci/pci.c:1812
#2  0x557ff52c in pc_nic_init (isa_bus=0x5733c610,
pci_bus=0x567ed990) at hw/i386/pc.c:1634
#3  0x558021ad in pc_init1 (machine=0x5661ee10,
pci_type=0x55c1a523 "i440FX", host_type=0x55ba564e
"i440FX-pcihost") at hw/i386/pc_piix.c:241
#4  0x557519cb in main (argc=, argv=, envp=) at vl.c:4481

Signed-off-by: Alex Kompel 

More a nic thing than pci really ...

Jason, could you pls merge this?

Acked-by: Michael S. Tsirkin 



Ok, will pick.

Thanks

[Qemu-devel] [kvm-unit-tests PATCH v4 2/2] run_tests: allow run tests in parallel

[Peter Xu]

run_task.sh is getting slow. This patch is trying to make it faster by
running the tests concurrently.

We provide a new parameter "-j" for the run_tests.sh, which can be used
to specify how many run queues we want for the tests. Default queue
length is 1, which is the old behavior.

Quick test on my laptop (4 cores, 2 threads each) shows 3x speed boost:

   |-+---|
   | command | time used |
   |-+---|
   | run_test.sh | 75s   |
   | run_test.sh -j8 | 27s   |
   |-+---|

Signed-off-by: Peter Xu 
---
 run_tests.sh| 12 ++--
 scripts/common.bash | 16 +++-
 2 files changed, 25 insertions(+), 3 deletions(-)

diff --git a/run_tests.sh b/run_tests.sh
index 1e36d66..795cf73 100755
--- a/run_tests.sh
+++ b/run_tests.sh
@@ -13,10 +13,11 @@ function usage()
 {
 cat < 0 )); then
+echo "Invalid -j option: $unittest_run_queues"
+exit 1
+fi
+;;
 v)
 verbose="yes"
 ;;
diff --git a/scripts/common.bash b/scripts/common.bash
index 2dd7360..83aebf8 100644
--- a/scripts/common.bash
+++ b/scripts/common.bash
@@ -1,11 +1,19 @@
 : ${unittest_log_dir:=logs}
+: ${unittest_run_queues:=1}
 
 function run_task()
 {
local testname="$2"
 
+   while (( "$(jobs | wc -l)" == $unittest_run_queues )); do
+   # wait for any background test to finish
+   wait -n
+   done
+
RUNTIME_log_file="${unittest_log_dir}/${testname}.log"
-   "$@"
+
+   # start the testcase in the background
+   "$@" &
 }
 
 function for_each_unittest()
@@ -22,6 +30,8 @@ function for_each_unittest()
local accel
local timeout
 
+   trap "wait; exit 130" SIGINT
+
exec {fd}<"$unittests"
 
while read -u $fd line; do
@@ -55,5 +65,9 @@ function for_each_unittest()
fi
done
run_task "$cmd" "$testname" "$groups" "$smp" "$kernel" "$opts" "$arch" 
"$check" "$accel" "$timeout"
+
+   # wait all task finish
+   wait
+
exec {fd}<&-
 }
-- 
2.7.4

[Qemu-devel] [kvm-unit-tests PATCH v4 0/2] run_tests: support concurrent test execution

[Peter Xu]

v4:
- add .gitignore for logs/ [Drew]
- instead of create globals.bash, renaming function.bash into
  common.bash, put globals inside [Drew]
- instead of removing logs/ directly when start run_tests, move it
  into logs.old so we at least have the last time result cached [Drew]
- s/ut_/unittest_/ through the whole series [Drew]
- remove unittest_log_summary var [Drew]
- remove radim's s-b in patch 2 since it does not suite [Drew]
- tiny fix on the usage lines [Drew]
- use bash arithmetic where proper [Drew]
- remove ut_in_parallel since not used [Drew]

v3:
- better handling for ctrl-c during run_tests.sh [Radim]

v2:
- patch 1: do per-test logging in all cases
- patch 2: throw away task.bash, instead, take Radim's suggestion to
  use jobs

run_tests.sh is getting slower. Maybe it's time to let it run faster.
An obvious issue is that, we were running the tests sequentially in
the past.

This series provides another new "-j" parameter. "-j 8" means we run
the tests on 8 task queues. That'll fasten the script a lot. A very
quick test of mine shows 3x speed boost with 8 task queues.

Please review, thanks.

Peter Xu (2):
  run_tests: put logs into per-test file
  run_tests: allow run tests in parallel

 .gitignore  |  3 ++-
 Makefile|  4 ++--
 run_tests.sh| 34 -
 scripts/{functions.bash => common.bash} | 27 --
 scripts/mkstandalone.sh |  2 +-
 5 files changed, 55 insertions(+), 15 deletions(-)
 rename scripts/{functions.bash => common.bash} (63%)

-- 
2.7.4

Re: [Qemu-devel] [PATCH v2] m68k: QOMify the MCF Fast Ethernet Controller device

[Jason Wang]

On 2017年01月08日 19:51, Thomas Huth wrote:

When running qemu-system-m68k with the "-net" parameter (for example
simply "-net nic -net user"), there is currently a confusing warning
message saying:

  Warning: requested NIC (anonymous, model mcf_fec) was not created
  (not supported by this machine?)

This seems to happen because the MCF NIC has never been adapted to
the currently expected QEMU device behavior. Thus let's QOMify the
NIC now to get rid of the warning message.

Signed-off-by: Thomas Huth
---
  v2:
  - Add the mcf_fec.h header file for the shared #defines
  - Use qemu_check_nic_model() to verify the NIC model

  hw/m68k/mcf5208.c | 25 -
  hw/net/mcf_fec.c  | 71 +++
  include/hw/m68k/mcf.h |  4 ---
  include/hw/m68k/mcf_fec.h | 13 +
  4 files changed, 90 insertions(+), 23 deletions(-)
  create mode 100644 include/hw/m68k/mcf_fec.h


Looks good, applied to -net.

Thanks

Re: [Qemu-devel] [kvm-unit-tests PATCH v3 2/2] run_tests: allow run tests in parallel

[Peter Xu]

On Fri, Jan 06, 2017 at 03:40:41PM +0100, Andrew Jones wrote:
> On Fri, Jan 06, 2017 at 11:33:01AM +0800, Peter Xu wrote:
> > run_task.sh is getting slow. This patch is trying to make it faster by
> > running the tests concurrently.
> > 
> > We provide a new parameter "-j" for the run_tests.sh, which can be used
> > to specify how many run queues we want for the tests. Default queue
> > length is 1, which is the old behavior.
> > 
> > Quick test on my laptop (4 cores, 2 threads each) shows 3x speed boost:
> > 
> >|-+---|
> >| command | time used |
> >|-+---|
> >| run_test.sh | 75s   |
> >| run_test.sh -j8 | 27s   |
> >|-+---|
> > 
> > Suggested-by: Radim Krčmář 
> 
> Radim suggested how to implement this, but not the idea of implementing
> it. The suggested-by tag is for ideas, not the code, and the idea (which
> is a good one) was yours, not Radim's. So the above tag should be removed.
> It's hard to credit Radim for his help here. Adding a signed-off-by to
> indicate co-authorship is probably the best you can do. Of course he's
> the maintainer and will add that when he merges anyway though...

I see, thanks for the clarification. Then let me remove this line.

> 
> > Signed-off-by: Peter Xu 
> > ---
> >  run_tests.sh   | 12 ++--
> >  scripts/functions.bash | 17 -
> >  scripts/global.bash| 11 +++
> >  3 files changed, 37 insertions(+), 3 deletions(-)
> > 
> > diff --git a/run_tests.sh b/run_tests.sh
> > index e1bb3a6..a4fc895 100755
> > --- a/run_tests.sh
> > +++ b/run_tests.sh
> > @@ -14,10 +14,11 @@ function usage()
> >  {
> >  cat < >  
> > -Usage: $0 [-g group] [-h] [-v]
> > +Usage: $0 [-g group] [-h] [-v] [-j N]
> 
> s/N/num_run_queues/

Sure.

[...]

> > @@ -38,6 +39,13 @@ while getopts "g:hv" opt; do
> >  usage
> >  exit
> >  ;;
> > +j)
> > +ut_run_queues=$OPTARG
> > +if ! is_number "$ut_run_queues"; then
> > +echo "Invalid -j option: $ut_run_queues"
> > +exit 1
> > +fi
> 
> Instead of adding is_number() and just checking for numeric
> input, I'd check the input is > 0. A string input resolves
> as zero when treated as a number, so it'll fail too.

Wasn't familiar with shell arithmetic before. Your suggestion is much
simpler, thanks.

> 
> > +;;
> >  v)
> >  verbose="yes"
> >  ;;
> > diff --git a/scripts/functions.bash b/scripts/functions.bash
> > index d1d2e1c..c6281f4 100644
> > --- a/scripts/functions.bash
> > +++ b/scripts/functions.bash
> > @@ -1,9 +1,18 @@
> > +source scripts/global.bash
> > +
> >  function run_task()
> >  {
> > local testname="$2"
> >  
> > +   while [[ "$(jobs | wc -l)" == $ut_run_queues ]]; do
> 
> Bash arithmetic expressions should use (( ... )) instead
> of [[ ... ]]

Will do.

[...]

> > diff --git a/scripts/global.bash b/scripts/global.bash
> > index 77b0b29..52095bd 100644
> > --- a/scripts/global.bash
> > +++ b/scripts/global.bash
> > @@ -1,2 +1,13 @@
> >  : ${ut_log_dir:=logs}
> >  : ${ut_log_summary:=${ut_log_dir}/SUMMARY}
> > +: ${ut_run_queues:=1}
> > +
> > +function ut_in_parallel()
> > +{
> > +[[ $ut_run_queues != 1 ]]
> > +}
> 
> I don't see any users of ut_in_parallel. Anyway I'd drop it
> and open code the condition, with ((...)), when needed.

Yes, it should be removed.

Thanks!

-- peterx

Re: [Qemu-devel] [RFC] pxb: Restrict to x86

[David Gibson]

On Mon, Jan 09, 2017 at 03:58:03AM +0200, Michael S. Tsirkin wrote:
> On Mon, Jan 09, 2017 at 10:48:24AM +1100, David Gibson wrote:
> > On Sun, Jan 08, 2017 at 10:17:12AM +0200, Marcel Apfelbaum wrote:
> > > On 01/06/2017 09:41 PM, Michael S. Tsirkin wrote:
> > > > On Fri, Jan 06, 2017 at 08:13:11AM +0200, Marcel Apfelbaum wrote:
> > > > > On 01/06/2017 07:04 AM, David Gibson wrote:
> > > > > > The PCI Expander Bridge (PXB) device is essentially a hack to allow
> > > > > > different PCIe devices to be assigned to different NUMA nodes on 
> > > > > > x86.  Each
> > > > > > PXB is sort-of a separate PCI host bridge, except that its config 
> > > > > > space
> > > > > > is shared with the config space of the main PCI host bridge, rather 
> > > > > > than
> > > > > > being independent.
> > > > > > 
> > > > > 
> > > > > Hi David,
> > > > > 
> > > > > > This is only necessary if the platform doesn't (easily) allow truly
> > > > > > independent PCI host bridges.  AFAIK that's just x86.
> > > > > > 
> > > > > 
> > > > > Indeed, it is possible to support independent PCI host bridges on x86 
> > > > > by
> > > > > using a separate MMCONFIG space for each one and enable separate PCI 
> > > > > domains.
> > > > > We simply didn't need this until now, but maybe will be implemented 
> > > > > it in the future.
> > > > 
> > > > In fact I would say that's the cleanest way to do this on q35.
> > > 
> > > Message received :)
> > 
> > Just so I'm clear, these last two comments are essentially suggesting
> > a follow up cleanup on x86, rather than suggesting a different
> > approach for non-PC platforms, yes?
> > 
> > If there are no objections to my original patch do you want to take it
> > through your tree Michael, or should I take it through mine?
> > 
> 
> 
> 
> Go ahead and take it through  yours pls.
> 
> Acked-by: Michael S. Tsirkin 

Done, thanks.


-- 
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] net: optimize checksum computation

[Jason Wang]

On 2017年01月08日 17:03, Dmitry Fleytman wrote:

On 6 Jan 2017, at 10:08 AM, Ladi Prosek  wrote:

Very simple loop optimization with a significant performance impact.

Microbenchmark results, modern x86-64:

buffer size | speed up
+-
1500| 1.7x
64  | 1.5x
8   | 1.15x

Microbenchmark results, POWER7:

buffer size | speed up
+-
1500| 5x
64  | 3.3x
8   | 1.13x

There is a lot of room for further improvement at the expense of
code complexity - aligned multibyte reads, LE/BE considerations,
architecture-specific optimizations, etc. This patch still keeps
things simple and readable.

Reviewed-by: Dmitry Fleytman 



Applied to -net.

Thanks

Re: [Qemu-devel] [kvm-unit-tests PATCH v3 1/2] run_tests: put logs into per-test file

[Peter Xu]

On Fri, Jan 06, 2017 at 02:51:58PM +0100, Andrew Jones wrote:
> On Fri, Jan 06, 2017 at 11:33:00AM +0800, Peter Xu wrote:
> > We were using test.log before to keep all the test logs. This patch
> > creates one log file per test case under logs/ directory with name
> > "TESTNAME.log".
> > 
> > A new file global.bash is added to store global informations.
> > 
> > Signed-off-by: Peter Xu 
> > ---
> >  Makefile   |  4 ++--
> >  run_tests.sh   | 14 --
> >  scripts/functions.bash | 11 +--
> >  scripts/global.bash|  2 ++
> >  4 files changed, 21 insertions(+), 10 deletions(-)
> >  create mode 100644 scripts/global.bash
> > 
> > diff --git a/Makefile b/Makefile
> > index a32333b..f632c6c 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -94,9 +94,9 @@ libfdt_clean:
> > $(LIBFDT_objdir)/.*.d
> >  
> >  distclean: clean libfdt_clean
> > -   $(RM) lib/asm config.mak $(TEST_DIR)-run test.log msr.out cscope.* \
> > +   $(RM) lib/asm config.mak $(TEST_DIR)-run msr.out cscope.* \
> >   build-head
> > -   $(RM) -r tests
> > +   $(RM) -r tests logs
> 
> We need .gitignore changes for this.

Yep.

> 
> >  
> >  cscope: cscope_dirs = lib lib/libfdt lib/linux $(TEST_DIR) $(ARCH_LIBDIRS) 
> > lib/asm-generic
> >  cscope:
> > diff --git a/run_tests.sh b/run_tests.sh
> > index 254129d..e1bb3a6 100755
> > --- a/run_tests.sh
> > +++ b/run_tests.sh
> > @@ -7,6 +7,7 @@ if [ ! -f config.mak ]; then
> >  exit 1
> >  fi
> >  source config.mak
> > +source scripts/global.bash
> >  source scripts/functions.bash
> 
> Rather than add a new file, can't we just rename functions.bash to
> something less function specific (common.bash?) and then add the
> globals to that?

Sure, common.bash is a good one, will use that.

> 
> >  
> >  function usage()
> > @@ -46,17 +47,18 @@ while getopts "g:hv" opt; do
> >  esac
> >  done
> >  
> > -RUNTIME_log_stderr () { cat >> test.log; }
> > +# RUNTIME_log_file will be configured later
> > +RUNTIME_log_stderr () { cat >> $RUNTIME_log_file; }
> >  RUNTIME_log_stdout () {
> >  if [ "$PRETTY_PRINT_STACKS" = "yes" ]; then
> > -./scripts/pretty_print_stacks.py $1 >> test.log
> > +./scripts/pretty_print_stacks.py $1 >> $RUNTIME_log_file
> >  else
> > -cat >> test.log
> > +cat >> $RUNTIME_log_file
> >  fi
> >  }
> >  
> > -
> >  config=$TEST_DIR/unittests.cfg
> > -rm -f test.log
> > -printf "BUILD_HEAD=$(cat build-head)\n\n" > test.log
> > +rm -rf $ut_log_dir
> 
> Instead of the 'rm', let's do
>  'mv $ut_log_dir $ut_log_dir.old || { echo [...]; exit 2; }'
> as I never liked that test.log was silently overwritten.

"Move" is indeed a much better way than "remove", especially "rm -rf"
(I think I should avoid using "rm -rf" in the future scripts as
well...). Will fix it.

> 
> > +mkdir $ut_log_dir
> > +printf "BUILD_HEAD=$(cat build-head)\n\n" > $ut_log_summary
> 
> I'm not sure we need the ut_ prefix on these variables. If we
> do think we need to start prefixing variables, then I'd prefer
> not to abbreviate, i.e. 'unittest_'

Since I would prefer a prefix, I'll use "unittest_" then.

[...]

> > diff --git a/scripts/global.bash b/scripts/global.bash
> > new file mode 100644
> > index 000..77b0b29
> > --- /dev/null
> > +++ b/scripts/global.bash
> > @@ -0,0 +1,2 @@
> > +: ${ut_log_dir:=logs}
> > +: ${ut_log_summary:=${ut_log_dir}/SUMMARY}
> 
> Do we even need these variables? When/why would someone override these
> defaults?

I use variables when I write constant more than once. This suites the
case for log_dir. I can remove the latter log_summary, but I'll still
prefer keep the log_dir if you don't mind.

Thanks!

-- peterx

Re: [Qemu-devel] [PATCH qemu] target-ppc: kvm: make use of KVM_CREATE_SPAPR_TCE_64

[David Gibson]

On Mon, Jan 09, 2017 at 01:38:26PM +1100, Alexey Kardashevskiy wrote:
> On 03/01/17 13:26, David Gibson wrote:
> > On Thu, Dec 22, 2016 at 12:13:12PM +1100, Alexey Kardashevskiy wrote:
> >> KVM_CAP_SPAPR_TCE capability allows creating TCE tables in KVM which
> >> allows having in-kernel acceleration for H_PUT_TCE_xxx hypercalls.
> >> However it only supports 32bit DMA windows at zero bus offset.
> >>
> >> There is a new KVM_CAP_SPAPR_TCE_64 capability which supports 64bit
> >> window size, variable page size and bus offset.
> >>
> >> This makes use of the new capability. The kernel headers are already
> >> updated as the kernel support went in to v4.6.
> >>
> >> Signed-off-by: Alexey Kardashevskiy 
> >> ---
> >>  target-ppc/kvm_ppc.h | 12 +++-
> >>  hw/ppc/spapr_iommu.c |  8 +---
> >>  target-ppc/kvm.c | 48 +---
> >>  3 files changed, 49 insertions(+), 19 deletions(-)
> >>
> >> diff --git a/target-ppc/kvm_ppc.h b/target-ppc/kvm_ppc.h
> >> index bd1d78bfbe..14320c2378 100644
> >> --- a/target-ppc/kvm_ppc.h
> >> +++ b/target-ppc/kvm_ppc.h
> >> @@ -36,8 +36,9 @@ int kvmppc_booke_watchdog_enable(PowerPCCPU *cpu);
> >>  #ifndef CONFIG_USER_ONLY
> >>  off_t kvmppc_alloc_rma(void **rma);
> >>  bool kvmppc_spapr_use_multitce(void);
> >> -void *kvmppc_create_spapr_tce(uint32_t liobn, uint32_t window_size, int 
> >> *pfd,
> >> -  bool need_vfio);
> >> +void *kvmppc_create_spapr_tce(uint32_t liobn, uint32_t page_shift,
> >> +  uint64_t bus_offset, uint32_t nb_table,
> >> +  int *pfd, bool need_vfio);
> >>  int kvmppc_remove_spapr_tce(void *table, int pfd, uint32_t window_size);
> >>  int kvmppc_reset_htab(int shift_hint);
> >>  uint64_t kvmppc_rma_size(uint64_t current_size, unsigned int hash_shift);
> >> @@ -168,9 +169,10 @@ static inline bool kvmppc_spapr_use_multitce(void)
> >>  return false;
> >>  }
> >>  
> >> -static inline void *kvmppc_create_spapr_tce(uint32_t liobn,
> >> -uint32_t window_size, int *fd,
> >> -bool need_vfio)
> >> +static inline void *kvmppc_create_spapr_tce(uint32_t liobn, uint32_t 
> >> page_shift,
> >> +uint64_t bus_offset,
> >> +uint32_t nb_table,
> >> +int *pfd, bool need_vfio)
> >>  {
> >>  return NULL;
> >>  }
> >> diff --git a/hw/ppc/spapr_iommu.c b/hw/ppc/spapr_iommu.c
> >> index ae30bbe30f..29c80bb3c8 100644
> >> --- a/hw/ppc/spapr_iommu.c
> >> +++ b/hw/ppc/spapr_iommu.c
> >> @@ -79,15 +79,16 @@ static IOMMUAccessFlags 
> >> spapr_tce_iommu_access_flags(uint64_t tce)
> >>  
> >>  static uint64_t *spapr_tce_alloc_table(uint32_t liobn,
> >> uint32_t page_shift,
> >> +   uint64_t bus_offset,
> >> uint32_t nb_table,
> >> int *fd,
> >> bool need_vfio)
> >>  {
> >>  uint64_t *table = NULL;
> >> -uint64_t window_size = (uint64_t)nb_table << page_shift;
> >>  
> >> -if (kvm_enabled() && !(window_size >> 32)) {
> >> -table = kvmppc_create_spapr_tce(liobn, window_size, fd, 
> >> need_vfio);
> >> +if (kvm_enabled()) {
> > 
> > This is broken.  Previously, if we had a >4GiB window, we'd fall back
> > to managing it in userspace, which would work, albeit slowly.  Now, if
> > you have an older kernel which doesn't support KVM_CAP_SPAPR_TCE_64 it
> > will attempt to allocate it in the kernel, and fail completely.
> 
> 
> No, kvmppc_create_spapr_tce() would return NULL and right after that there
> is a "if (!table)" (it can be seen at the end of this chunk) to handle the
> failure.

Oh, yes, sorry.  For some reason I thought there was a return in that
if block.

> > 
> >> +table = kvmppc_create_spapr_tce(liobn, page_shift, bus_offset, 
> >> nb_table,
> >> +fd, need_vfio);
> >>  }
> >>  
> >>  if (!table) {
> >> @@ -342,6 +343,7 @@ void spapr_tce_table_enable(sPAPRTCETable *tcet,
> >>  tcet->nb_table = nb_table;
> >>  tcet->table = spapr_tce_alloc_table(tcet->liobn,
> >>  tcet->page_shift,
> >> +tcet->bus_offset,
> >>  tcet->nb_table,
> >>  >fd,
> >>  tcet->need_vfio);
> >> diff --git a/target-ppc/kvm.c b/target-ppc/kvm.c
> >> index 9c4834c4fc..6e91a4d8bb 100644
> >> --- a/target-ppc/kvm.c
> >> +++ b/target-ppc/kvm.c
> >> @@ -71,6 +71,7 @@ static int cap_booke_sregs;
> >>  static int cap_ppc_smt;
> >>  static int cap_ppc_rma;
> >>  static int 

Re: [Qemu-devel] [PATCH v1 00/14] POWER9 TCG enablements - part10

[David Gibson]

On Fri, Jan 06, 2017 at 11:44:42AM +0530, Nikunj A Dadhania wrote:
> This series contains 11 new instructions for POWER9 ISA3.0
>  VSX Vector Insert/Extract Word
>  VSX Scalar Extract Exponent/Significand
>  VSX Scalar Convert
>  VSX Scalar Add QP
>  Various float related improvements

Applied to ppc-for-2.9, thanks.

> 
> Changelog:
> v0:
>Rebase and update reviewed-by
> 
> Bharata B Rao (8):
>   target-ppc: Use float64 arg in helper_compute_fprf()
>   target-ppc: Replace isden by float64_is_zero_or_denormal
>   target-ppc: Rename helper_compute_fprf to helper_compute_fprf_float64
>   target-ppc: Add xsaddqp instructions
>   target-ppc: Add xscvdphp, xscvhpdp
>   target-ppc: Use correct precision for FPRF setting
>   target-ppc: Add xscvdpqp instruction
>   target-ppc: Add xscvqpdp instruction
> 
> Nikunj A Dadhania (6):
>   target-ppc: Add xxextractuw instruction
>   target-ppc: Add xxinsertw instruction
>   target-ppc: Add xsxexpdp instruction
>   target-ppc: Add xsxexpqp instruction
>   target-ppc: Add xsxsigdp instruction
>   target-ppc: Add xsxsigqp instructions
> 
>  include/fpu/softfloat.h |  20 +++
>  target/ppc/fpu_helper.c | 241 
> +---
>  target/ppc/helper.h |   9 +-
>  target/ppc/int_helper.c |  51 
>  target/ppc/internal.h   |   6 +
>  target/ppc/translate/fp-impl.inc.c  |  20 +--
>  target/ppc/translate/vsx-impl.inc.c | 122 ++
>  target/ppc/translate/vsx-ops.inc.c  |  18 +++
>  8 files changed, 405 insertions(+), 82 deletions(-)
> 

-- 
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 qemu] target-ppc: kvm: make use of KVM_CREATE_SPAPR_TCE_64

[Alexey Kardashevskiy]

On 03/01/17 13:26, David Gibson wrote:
> On Thu, Dec 22, 2016 at 12:13:12PM +1100, Alexey Kardashevskiy wrote:
>> KVM_CAP_SPAPR_TCE capability allows creating TCE tables in KVM which
>> allows having in-kernel acceleration for H_PUT_TCE_xxx hypercalls.
>> However it only supports 32bit DMA windows at zero bus offset.
>>
>> There is a new KVM_CAP_SPAPR_TCE_64 capability which supports 64bit
>> window size, variable page size and bus offset.
>>
>> This makes use of the new capability. The kernel headers are already
>> updated as the kernel support went in to v4.6.
>>
>> Signed-off-by: Alexey Kardashevskiy 
>> ---
>>  target-ppc/kvm_ppc.h | 12 +++-
>>  hw/ppc/spapr_iommu.c |  8 +---
>>  target-ppc/kvm.c | 48 +---
>>  3 files changed, 49 insertions(+), 19 deletions(-)
>>
>> diff --git a/target-ppc/kvm_ppc.h b/target-ppc/kvm_ppc.h
>> index bd1d78bfbe..14320c2378 100644
>> --- a/target-ppc/kvm_ppc.h
>> +++ b/target-ppc/kvm_ppc.h
>> @@ -36,8 +36,9 @@ int kvmppc_booke_watchdog_enable(PowerPCCPU *cpu);
>>  #ifndef CONFIG_USER_ONLY
>>  off_t kvmppc_alloc_rma(void **rma);
>>  bool kvmppc_spapr_use_multitce(void);
>> -void *kvmppc_create_spapr_tce(uint32_t liobn, uint32_t window_size, int 
>> *pfd,
>> -  bool need_vfio);
>> +void *kvmppc_create_spapr_tce(uint32_t liobn, uint32_t page_shift,
>> +  uint64_t bus_offset, uint32_t nb_table,
>> +  int *pfd, bool need_vfio);
>>  int kvmppc_remove_spapr_tce(void *table, int pfd, uint32_t window_size);
>>  int kvmppc_reset_htab(int shift_hint);
>>  uint64_t kvmppc_rma_size(uint64_t current_size, unsigned int hash_shift);
>> @@ -168,9 +169,10 @@ static inline bool kvmppc_spapr_use_multitce(void)
>>  return false;
>>  }
>>  
>> -static inline void *kvmppc_create_spapr_tce(uint32_t liobn,
>> -uint32_t window_size, int *fd,
>> -bool need_vfio)
>> +static inline void *kvmppc_create_spapr_tce(uint32_t liobn, uint32_t 
>> page_shift,
>> +uint64_t bus_offset,
>> +uint32_t nb_table,
>> +int *pfd, bool need_vfio)
>>  {
>>  return NULL;
>>  }
>> diff --git a/hw/ppc/spapr_iommu.c b/hw/ppc/spapr_iommu.c
>> index ae30bbe30f..29c80bb3c8 100644
>> --- a/hw/ppc/spapr_iommu.c
>> +++ b/hw/ppc/spapr_iommu.c
>> @@ -79,15 +79,16 @@ static IOMMUAccessFlags 
>> spapr_tce_iommu_access_flags(uint64_t tce)
>>  
>>  static uint64_t *spapr_tce_alloc_table(uint32_t liobn,
>> uint32_t page_shift,
>> +   uint64_t bus_offset,
>> uint32_t nb_table,
>> int *fd,
>> bool need_vfio)
>>  {
>>  uint64_t *table = NULL;
>> -uint64_t window_size = (uint64_t)nb_table << page_shift;
>>  
>> -if (kvm_enabled() && !(window_size >> 32)) {
>> -table = kvmppc_create_spapr_tce(liobn, window_size, fd, need_vfio);
>> +if (kvm_enabled()) {
> 
> This is broken.  Previously, if we had a >4GiB window, we'd fall back
> to managing it in userspace, which would work, albeit slowly.  Now, if
> you have an older kernel which doesn't support KVM_CAP_SPAPR_TCE_64 it
> will attempt to allocate it in the kernel, and fail completely.


No, kvmppc_create_spapr_tce() would return NULL and right after that there
is a "if (!table)" (it can be seen at the end of this chunk) to handle the
failure.


> 
>> +table = kvmppc_create_spapr_tce(liobn, page_shift, bus_offset, 
>> nb_table,
>> +fd, need_vfio);
>>  }
>>  
>>  if (!table) {
>> @@ -342,6 +343,7 @@ void spapr_tce_table_enable(sPAPRTCETable *tcet,
>>  tcet->nb_table = nb_table;
>>  tcet->table = spapr_tce_alloc_table(tcet->liobn,
>>  tcet->page_shift,
>> +tcet->bus_offset,
>>  tcet->nb_table,
>>  >fd,
>>  tcet->need_vfio);
>> diff --git a/target-ppc/kvm.c b/target-ppc/kvm.c
>> index 9c4834c4fc..6e91a4d8bb 100644
>> --- a/target-ppc/kvm.c
>> +++ b/target-ppc/kvm.c
>> @@ -71,6 +71,7 @@ static int cap_booke_sregs;
>>  static int cap_ppc_smt;
>>  static int cap_ppc_rma;
>>  static int cap_spapr_tce;
>> +static int cap_spapr_tce_64;
>>  static int cap_spapr_multitce;
>>  static int cap_spapr_vfio;
>>  static int cap_hior;
>> @@ -123,6 +124,7 @@ int kvm_arch_init(MachineState *ms, KVMState *s)
>>  cap_ppc_smt = kvm_check_extension(s, KVM_CAP_PPC_SMT);
>>  cap_ppc_rma = kvm_check_extension(s, KVM_CAP_PPC_RMA);
>>  cap_spapr_tce = 

Re: [Qemu-devel] [PATCH v3 0/2] VT-d migration support

[Peter Xu]

On Fri, Jan 06, 2017 at 01:27:38PM +, Dr. David Alan Gilbert wrote:

[...]

> > (P.S. I found that split irqchip cannot work well with migration. Is
> >  this an known issue?)
> 
> How did it fail?

The keyboard hangs after migration.

Command line for reference:

$qemu -M q35,kernel-irqchip=split -enable-kvm \
  -netdev user,id=net0 \
  -device e1000,netdev=net0 \
  -m 512M -monitor stdio \
  $incoming /var/lib/libvirt/images/vm1.qcow2

Here $incoming is "" for init vm, and "-incoming tcp:0:" for the
dest side. Not sure whether this is reproducable issue. Looks like
some EOI ack is missing.

Host: 4.10.0-rc1+ (I should also tried 4.6.4-301.fc24)
Qemu: latest master

Looking into it.

-- peterx

Re: [Qemu-devel] [PATCH] virtio-crypto: use the correct length for cipher operation

[Gonglei (Arei)]

Hi Michael,

Ping...



Regards,
-Gonglei


> -Original Message-
> From: Gonglei (Arei)
> Sent: Thursday, December 22, 2016 11:37 AM
> To: qemu-devel@nongnu.org
> Cc: m...@redhat.com; Gonglei (Arei)
> Subject: [PATCH] virtio-crypto: use the correct length for cipher operation
> 
> In some modes of cipher algorithms, the length of destination data
> maybe larger then source data, such as ciphertext stealing (CTS).
> 
> For symmetric algorithms, the length of ciphertext is definitly
> equal to the plaintext for each crypto operation. So we should
> use the src_len instead of dst_len avoid to pass the incorrect
> cryptographical results to the frontend driver.
> 
> Signed-off-by: Gonglei 
> ---
>  hw/virtio/virtio-crypto.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/hw/virtio/virtio-crypto.c b/hw/virtio/virtio-crypto.c
> index 4f11fee..978bb98 100644
> --- a/hw/virtio/virtio-crypto.c
> +++ b/hw/virtio/virtio-crypto.c
> @@ -355,7 +355,7 @@ virtio_crypto_sym_input_data_helper(VirtIODevice
> *vdev,
>  return;
>  }
> 
> -len = sym_op_info->dst_len;
> +len = sym_op_info->src_len;
>  /* Save the cipher result */
>  s = iov_from_buf(req->in_iov, req->in_num, 0, sym_op_info->dst, len);
>  if (s != len) {
> --
> 1.8.3.1
> 

Re: [Qemu-devel] [PATCH] virtio-crypto: fix possible integer and heap overflow

[Gonglei (Arei)]

Hi Michael,

Ping...



Regards,
-Gonglei


> -Original Message-
> From: Gonglei (Arei)
> Sent: Tuesday, January 03, 2017 2:50 PM
> To: qemu-devel@nongnu.org
> Cc: m...@redhat.com; liqiang...@360.cn; Gonglei (Arei);
> qemu-sta...@nongnu.org
> Subject: [PATCH] virtio-crypto: fix possible integer and heap overflow
> 
> Because the 'size_t' type is 4 bytes in 32-bit platform, which
> is the same with 'int'. It's easy to make 'max_len' to zero when
> integer overflow and then cause heap overflow if 'max_len' is zero.
> 
> Using uint_64 instead of size_t to avoid the integer overflow.
> 
> Cc: qemu-sta...@nongnu.org
> Reported-by: Li Qiang 
> Signed-off-by: Gonglei 
> Tested-by: Li Qiang 
> ---
>  hw/virtio/virtio-crypto.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/hw/virtio/virtio-crypto.c b/hw/virtio/virtio-crypto.c
> index 978bb98..fc30bc3 100644
> --- a/hw/virtio/virtio-crypto.c
> +++ b/hw/virtio/virtio-crypto.c
> @@ -416,7 +416,7 @@ virtio_crypto_sym_op_helper(VirtIODevice *vdev,
>  uint32_t hash_start_src_offset = 0, len_to_hash = 0;
>  uint32_t cipher_start_src_offset = 0, len_to_cipher = 0;
> 
> -size_t max_len, curr_size = 0;
> +uint64_t max_len, curr_size = 0;
>  size_t s;
> 
>  /* Plain cipher */
> @@ -441,7 +441,7 @@ virtio_crypto_sym_op_helper(VirtIODevice *vdev,
>  return NULL;
>  }
> 
> -max_len = iv_len + aad_len + src_len + dst_len + hash_result_len;
> +max_len = (uint64_t)iv_len + aad_len + src_len + dst_len +
> hash_result_len;
>  if (unlikely(max_len > vcrypto->conf.max_size)) {
>  virtio_error(vdev, "virtio-crypto too big length");
>  return NULL;
> --
> 1.8.3.1
> 

Re: [Qemu-devel] [PATCH v3] virtio-crypto: zeroize the key material before free

[Gonglei (Arei)]

Hi Michael,

Ping...


Regards,
-Gonglei


> -Original Message-
> From: Gonglei (Arei)
> Sent: Thursday, December 22, 2016 11:01 AM
> To: qemu-devel@nongnu.org
> Cc: m...@redhat.com; Gonglei (Arei)
> Subject: [PATCH v3] virtio-crypto: zeroize the key material before free
> 
> Common practice with sensitive information (key material, passwords,
> etc). Prevents sensitive information from being exposed by accident later in
> coredumps, memory disclosure bugs when heap memory is reused, etc.
> 
> Sensitive information is sometimes also held in mlocked pages to prevent
> it being swapped to disk but that's not being done here.
> 
> Let's zeroize the memory of CryptoDevBackendSymOpInfo structure pointed
> for key material security.
> 
> [Thanks to Stefan for help with crafting the commit message]
> 
> Signed-off-by: Gonglei 
> Reviewed-by: Stefan Hajnoczi 
> Reviewed-by: Eric Blake 
> ---
>  v3:
>  - rework the commit message [Eric]
>  - add Eric's R-by tag.
> 
>  hw/virtio/virtio-crypto.c | 13 -
>  1 file changed, 12 insertions(+), 1 deletion(-)
> 
> diff --git a/hw/virtio/virtio-crypto.c b/hw/virtio/virtio-crypto.c
> index 4f11fee..48288e8 100644
> --- a/hw/virtio/virtio-crypto.c
> +++ b/hw/virtio/virtio-crypto.c
> @@ -337,7 +337,18 @@ static void
> virtio_crypto_free_request(VirtIOCryptoReq *req)
>  {
>  if (req) {
>  if (req->flags == CRYPTODEV_BACKEND_ALG_SYM) {
> -g_free(req->u.sym_op_info);
> +size_t max_len;
> +CryptoDevBackendSymOpInfo *op_info = req->u.sym_op_info;
> +
> +max_len = op_info->iv_len +
> +  op_info->aad_len +
> +  op_info->src_len +
> +  op_info->dst_len +
> +  op_info->digest_result_len;
> +
> +/* Zeroize and free request data structure */
> +memset(op_info, 0, sizeof(*op_info) + max_len);
> +g_free(op_info);
>  }
>  g_free(req);
>  }
> --
> 1.8.3.1
> 

Re: [Qemu-devel] [PATCH RESEND 0/5] hotplugging support for both cryptdoev and virtio crypto device

[Gonglei (Arei)]

Hi Michael,

Ping...



Regards,
-Gonglei


> -Original Message-
> From: Gonglei (Arei)
> Sent: Thursday, December 22, 2016 11:13 AM
> To: qemu-devel@nongnu.org
> Cc: m...@redhat.com; Gonglei (Arei)
> Subject: [PATCH RESEND 0/5] hotplugging support for both cryptdoev and virtio
> crypto device
> 
> The patch set make the cryptodev object can be hot plugging
> in safety, and which are preparing works for virtio-crypto
> device hotplugging.
> 
> Patch 5 opens the hotplugging capability for virtio crypto
> device.
> 
> Gonglei (5):
>   cryptodev: introduce a new is_used property
>   cryptodev: wrap the ready flag
>   virtio-crypto-pci: add check for cryptodev object
>   virtio-crypto: avoid one cryptodev device is used by multiple virtio
> crypto devices
>   virtio-crypto-pci: tag virtio-crypto device hot pluggable
> 
>  backends/cryptodev-builtin.c  |  4 
>  backends/cryptodev.c  | 34
> ++
>  hw/virtio/virtio-crypto-pci.c |  6 +-
>  hw/virtio/virtio-crypto.c | 22 +++---
>  include/sysemu/cryptodev.h| 42
> ++
>  5 files changed, 100 insertions(+), 8 deletions(-)
> 
> --
> 1.8.3.1
> 

Re: [Qemu-devel] [PATCH for-2.8] qom: fix qemu_opts leak when hot unplug object

[Gonglei (Arei)]

Ping...

Anybody can pick it up? Thanks!

Regards,
-Gonglei


> -Original Message-
> From: Gonglei (Arei)
> Sent: Wednesday, November 23, 2016 7:50 PM
> To: qemu-devel@nongnu.org
> Cc: afaer...@suse.de; Gonglei (Arei)
> Subject: [PATCH for-2.8] qom: fix qemu_opts leak when hot unplug object
> 
> If we assign the user crateable object in QEMU command
> line, then the correspeonding qemu_opts for the object
> doesn't be deleted, which will produce a wrong result.
> 
> If we hot unplug the object by object_del, the qemu_opts
> will be leaked, ann then if we hot plug the object using
> the same id by object_add, we will get a error:
>  "Duplicate ID '' for object"
> 
> Let's del the qemu opts after the object created, just
> likes what the hmp_object_add function does.
> 
> Signed-off-by: Gonglei 
> ---
>  qom/object_interfaces.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/qom/object_interfaces.c b/qom/object_interfaces.c
> index ded4d84..b8fe9db 100644
> --- a/qom/object_interfaces.c
> +++ b/qom/object_interfaces.c
> @@ -189,6 +189,10 @@ int user_creatable_add_opts_foreach(void *opaque,
> QemuOpts *opts, Error **errp)
>  return -1;
>  }
>  object_unref(obj);
> +
> +qemu_opts_del(opts);
> +opts = NULL;
> +
>  return 0;
>  }
> 
> --
> 1.8.3.1
> 

Re: [Qemu-devel] [PATCH qemu 2/2] spapr_pci: Advertise 16M IOMMU pages when available

[Alexey Kardashevskiy]

On 03/01/17 10:41, David Gibson wrote:
> On Thu, Dec 22, 2016 at 04:22:12PM +1100, Alexey Kardashevskiy wrote:
>> On sPAPR, IOMMU page size varies and if QEMU is running with RAM
>> backed with hugepages, we can advertise this to the guest so does
>> this patch.
>>
>> Signed-off-by: Alexey Kardashevskiy 
>> ---
>>  hw/ppc/spapr_pci.c | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/hw/ppc/spapr_pci.c b/hw/ppc/spapr_pci.c
>> index fd6fc1d953..09244056fc 100644
>> --- a/hw/ppc/spapr_pci.c
>> +++ b/hw/ppc/spapr_pci.c
>> @@ -1505,6 +1505,9 @@ static void spapr_phb_realize(DeviceState *dev, Error 
>> **errp)
>>  }
>>  
>>  /* DMA setup */
>> +/* This allows huge pages for IOMMU when guest is backed with huge 
>> pages */
>> +sphb->page_size_mask |= qemu_getrampagesize();
> 
> This doesn't look right - you're unconditionally enabling the host ram
> page size, regardless of anything else.  Instead the backing page size
> should be used to filter out those sizes which are possible from the
> list of those supported by the guest hardware.  This patch will give
> particularly odd results if you ran it on x86 with hugepages for
> example: it would advertise a 2M IOMMU page size, which could never
> exist on native POWER.

Ok, I'll filter 16M out if passed to PHB and not supported by the host.


> Except... come to think of it, why is the backing RAM page size
> relevant at all? 

Because this is just an optimization/acceleration and I'd think the user
wants to know if it is actually accelerated or not. If I always allow 16M
pages, and QEMU is not backed with hugepages, then all H_PUT_TCE will go
via slow path and consume as much memory for TCE as without hugepages, and
it will only be visible to the user if TCE-tracepoints are enabled.

> Or rather.. I think VFIO should be able to cope with
> any guest IOMMU page size which is larger than the host ram page size

It could, I just do not see much benefit in it. pseries guest can negotiate
4k, 64k, 16m pages and this seems to cover everything we want, why would we
want to emulate IOMMU page size?

> (although if it's much larger it could get expensive in the host
> tables).  This case would already be routine for ppc64 on x86, where
> the guest IOMMU page size is 64kiB, but the host page size is 4 kiB.




-- 
Alexey



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [RFC] pxb: Restrict to x86

[Michael S. Tsirkin]

On Mon, Jan 09, 2017 at 10:48:24AM +1100, David Gibson wrote:
> On Sun, Jan 08, 2017 at 10:17:12AM +0200, Marcel Apfelbaum wrote:
> > On 01/06/2017 09:41 PM, Michael S. Tsirkin wrote:
> > > On Fri, Jan 06, 2017 at 08:13:11AM +0200, Marcel Apfelbaum wrote:
> > > > On 01/06/2017 07:04 AM, David Gibson wrote:
> > > > > The PCI Expander Bridge (PXB) device is essentially a hack to allow
> > > > > different PCIe devices to be assigned to different NUMA nodes on x86. 
> > > > >  Each
> > > > > PXB is sort-of a separate PCI host bridge, except that its config 
> > > > > space
> > > > > is shared with the config space of the main PCI host bridge, rather 
> > > > > than
> > > > > being independent.
> > > > > 
> > > > 
> > > > Hi David,
> > > > 
> > > > > This is only necessary if the platform doesn't (easily) allow truly
> > > > > independent PCI host bridges.  AFAIK that's just x86.
> > > > > 
> > > > 
> > > > Indeed, it is possible to support independent PCI host bridges on x86 by
> > > > using a separate MMCONFIG space for each one and enable separate PCI 
> > > > domains.
> > > > We simply didn't need this until now, but maybe will be implemented it 
> > > > in the future.
> > > 
> > > In fact I would say that's the cleanest way to do this on q35.
> > 
> > Message received :)
> 
> Just so I'm clear, these last two comments are essentially suggesting
> a follow up cleanup on x86, rather than suggesting a different
> approach for non-PC platforms, yes?
> 
> If there are no objections to my original patch do you want to take it
> through your tree Michael, or should I take it through mine?
> 
> -- 
> 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



Go ahead and take it through  yours pls.

Acked-by: Michael S. Tsirkin 

Re: [Qemu-devel] Proposal PCI/PCIe device placement on PAPR guests

[David Gibson]

On Fri, Jan 06, 2017 at 06:34:29PM +0100, Andrea Bolognani wrote:
> [Added Laine to CC, fixed qemu-devel address]
> 
> On Thu, 2017-01-05 at 16:46 +1100, David Gibson wrote:
> [...]
> >   * To allow for hotplugged devices, libvirt should also add a number
> > of additional, empty vPHBs (the PAPR spec allows for hotplug of
> > PHBs, but this is not yet implemented in qemu).
> 
> "A number" here will have to mean "one", same number of
> empty PCIe Root Ports libvirt will add to a newly-defined
> q35 guest.

Umm.. why?

> > When hotplugging
> > a new device (or PE) libvirt should locate a vPHB which doesn't
> > currently contain anything.
> 
> This will need to be a PHB-specific behavior, because at the
> moment libvirt will happily pick one of the empty slots in
> an existing PHB.

Exactly.  Well, whether it's PHB model specific or machine type
specific is up to you really.  We can only have PAPR PHBs on a PAPR
machine type, so it's kind of arbitrary.

> 
> >   * libvirt should only (automatically) add PHBs - never root ports or
> > other PCI to PCI bridges
> > 
> > In order to handle migration, the vPHBs will need to be represented in
> > the domain XML, which will also allow the user to override this
> > topology if they want.
> 
> We'll have to decide how to represent them in the XML, but
> that's basically your average bikeshedding.

Right.  Maybe we'd best get started with it, in the hopes of finishing
it in the forseeable future.

> Overall, the plan seems entirely reasonable to me.
> 
> It's pretty clear at this point that pseries guest are
> different enough in their handling of PCI that none of
> the address allocation algorithms currently implemented
> in libvirt could be quite adapted to work with it, so
> a custom one is in order.

Yes, that was my conclusion as well.

-- 
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] pxb: Restrict to x86

[David Gibson]

On Sun, Jan 08, 2017 at 10:17:12AM +0200, Marcel Apfelbaum wrote:
> On 01/06/2017 09:41 PM, Michael S. Tsirkin wrote:
> > On Fri, Jan 06, 2017 at 08:13:11AM +0200, Marcel Apfelbaum wrote:
> > > On 01/06/2017 07:04 AM, David Gibson wrote:
> > > > The PCI Expander Bridge (PXB) device is essentially a hack to allow
> > > > different PCIe devices to be assigned to different NUMA nodes on x86.  
> > > > Each
> > > > PXB is sort-of a separate PCI host bridge, except that its config space
> > > > is shared with the config space of the main PCI host bridge, rather than
> > > > being independent.
> > > > 
> > > 
> > > Hi David,
> > > 
> > > > This is only necessary if the platform doesn't (easily) allow truly
> > > > independent PCI host bridges.  AFAIK that's just x86.
> > > > 
> > > 
> > > Indeed, it is possible to support independent PCI host bridges on x86 by
> > > using a separate MMCONFIG space for each one and enable separate PCI 
> > > domains.
> > > We simply didn't need this until now, but maybe will be implemented it in 
> > > the future.
> > 
> > In fact I would say that's the cleanest way to do this on q35.
> 
> Message received :)

Just so I'm clear, these last two comments are essentially suggesting
a follow up cleanup on x86, rather than suggesting a different
approach for non-PC platforms, yes?

If there are no objections to my original patch do you want to take it
through your tree Michael, or should I take it through mine?

-- 
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 v3 0/4] ppc: add a IBM 40p machine (RS/6000, PReP)

[David Gibson]

On Sat, Jan 07, 2017 at 04:23:39PM +0100, Hervé Poussineau wrote:
> Hi,
> 
> This patchset adds the emulation of the IBM RS/6000 7020 (40p). The real 
> machine is
> able to run AIX (up to 4.3.3), Windows NT (up to 4.0 SP1), the beta of OS/2 
> PowerPC,
> Solaris, Linux, NetBSD/PReP ...
> 
> I've tested current emulation with Open Hack'Ware, OpenBIOS and official 
> firmware.
> 
> Linux kernel starts, and freezes during boot (seems like a problem with the 
> SCSI adapter).
> Windows NT starts up to the point where it wants to change endianness.
> Other OSes have not been tested.
> 
> This machine is a superset of the 'prep' one, because we know exactly what 
> is/should
> emulated, and that operating system list running on it is quite wide.
> I hope that 'prep' machine can be deprecated soon and then later removed.
> 
> Patch 1 is a cleanup, and can probably be committed first.
> Patches 2 to 4  are the real implementation of the IBM 40p.

Applied to ppc-for-2.9, with a slight config tweak to 3/4 to avoid
breaking make check on ppc64.

> 
> Changes since v2:
> - patch 2: fix mismatch between read and write functions for port 92
> - patch 4: use error_report instead of fprintf/hw_error
> 
> Changes since v1:
> - removed patches related to display adapter:
>   Let's wait for an emulation of the real display adapter (an S3 Trio), as 
> current
>   VGA adapter already mostly works with Open Hack'Ware and OpenBIOS
> - various changes due to David Gibson's remarks
> 
> Hervé Poussineau (4):
>   prep: do not use global variable to access nvram
>   prep: add PReP System I/O
>   prep: add IBM RS/6000 7020 (40p) memory controller
>   prep: add IBM RS/6000 7020 (40p) machine emulation
> 
>  default-configs/ppc-softmmu.mak |   2 +
>  hw/ppc/Makefile.objs|   2 +
>  hw/ppc/prep.c   | 233 +-
>  hw/ppc/prep_systemio.c  | 303 
> 
>  hw/ppc/rs6000_mc.c  | 232 ++
>  hw/ppc/trace-events |  11 ++
>  6 files changed, 781 insertions(+), 2 deletions(-)
>  create mode 100644 hw/ppc/prep_systemio.c
>  create mode 100644 hw/ppc/rs6000_mc.c
> 

-- 
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 00/15] Postcopy: Hugepage support

[Fam Zheng]

On Fri, 01/06 18:59, Dr. David Alan Gilbert wrote:
> * no-re...@patchew.org (no-re...@patchew.org) wrote:
> > Hi,
> > Checking PATCH 14/15: postcopy: Check for userfault+hugepage feature...
> > ERROR: trailing whitespace
> > #21: FILE: migration/postcopy-ram.c:85:
> > +bool have_hp = false; $
> 
> I noticed that one but explicitly left it; the code really reads much
> more cleanly to me with it explicitly set.

It's not complaining about the variable being initialized, but rather the ending
whitespace before EOL.

Fam

[Qemu-devel] [PATCH] ui: fix format specifier in vnc_client_io_error() to avoid break in build.

[Rami Rosen]

When building qemu after setting _VNC_DEBUG to 1 (see ui/vnc.h),
we get the following error and the build breaks:
...
ui/vnc.c: In function ‘vnc_client_io_error’:
ui/vnc.c:1262:13: error: format ‘%d’ expects argument of type ‘int’, but 
argument 3 has type ‘ssize_t’ [-Werror=format=]
 VNC_DEBUG("Closing down client sock: ret %d (%s)\n",
 ^
cc1: all warnings being treated as errors
make: *** [ui/vnc.o] Error 1
...

This patch solves this issue by fixing the print format specifier
in vnc_client_io_error() to be %ld, which corresponds to the type
of the "ret" variable.

Signed-off-by: Rami Rosen 
---
 ui/vnc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ui/vnc.c b/ui/vnc.c
index 2c28a59..4b0a89c 100644
--- a/ui/vnc.c
+++ b/ui/vnc.c
@@ -1259,7 +1259,7 @@ ssize_t vnc_client_io_error(VncState *vs, ssize_t ret, 
Error **errp)
 if (ret == 0) {
 VNC_DEBUG("Closing down client sock: EOF\n");
 } else if (ret != QIO_CHANNEL_ERR_BLOCK) {
-VNC_DEBUG("Closing down client sock: ret %d (%s)\n",
+VNC_DEBUG("Closing down client sock: ret %ld (%s)\n",
   ret, errp ? error_get_pretty(*errp) : "Unknown");
 }
 
-- 
1.9.1

[Qemu-devel] Exporting kvm_max_guest_tsc_khz to userspace (was Re: [PATCH 4/4] kvm: Allow migration with invtsc)

[Eduardo Habkost]

On Fri, Jan 06, 2017 at 08:31:27AM -0200, Marcelo Tosatti wrote:
[...]
> > > 
> > > > Maybe your use case just needs a explicit "invtsc-migration=on"
> > > > command-line flag without a mechanism to abort migration on
> > > > mismatch? I can't tell.
> > > 
> > > Again, there is no special case.
> > > 
> > > > Note that even if we follow your suggestion and implement an
> > > > alternative version of patch 4/4 to cover your use case, I will
> > > > strongly recommend libvirt developers to support configuring TSC
> > > > frequency if they want to support invtsc + migration without
> > > > surprising/unpredictable restrictions on migratability.
> > > 
> > > Well, alright. If you make the TSC frequency of the host
> > > available to mgmt software as you describe, and write the steps mgmt
> > > software should take, i'm good.
> > 
> > I plan to. The problem is that the mechanism to query the host
> > frequency may be unavailable in the first version.
> 
> Well just export KVM_GET_TSC_KHZ in a QMP command right? Its pretty
> easy.
> 
> Let me know if you need any help coding or testing.

I just found out that KVM doesn't provide something that QEMU and
libvirt need: the value of kvm_max_guest_tsc_khz. Without it, we
have no way to know if a given VM is really migratable to a host.

Could we add a KVM_CAP_MAX_TSC_KHZ capability for that?

-- 
Eduardo

Re: [Qemu-devel] [PATCH 0/5] Use non-blacklisted family/model/stepping for Haswell CPU model

[Eduardo Habkost]

Oops, there are 3 actual mistakes I missed among the false
positives, below:

On Sun, Jan 08, 2017 at 11:47:21AM -0800, no-re...@patchew.org wrote:
[...]
> === OUTPUT BEGIN ===
> Checking PATCH 1/5: i386: Add explicit array size to 
> x86_cpu_vendor_words2str()...
> ERROR: line over 90 characters
> #27: FILE: target/i386/cpu.c:172:
> +static void x86_cpu_vendor_words2str(char dst[static (CPUID_VENDOR_SZ + 1)], 
> uint32_t vendor1,

False positive.

> 
> ERROR: space prohibited between function name and open parenthesis '('
> #27: FILE: target/i386/cpu.c:172:
> +static void x86_cpu_vendor_words2str(char dst[static (CPUID_VENDOR_SZ + 1)], 
> uint32_t vendor1,

False positive.

> 
> total: 2 errors, 0 warnings, 8 lines checked
> 
> Your patch has style problems, please review.  If any of these errors
> are false positives report them to the maintainer, see
> CHECKPATCH in MAINTAINERS.
> 
> Checking PATCH 2/5: i386: host_vendor_fms() helper function...
> ERROR: line over 90 characters
> #20: FILE: target/i386/cpu.c:685:
> +void host_vendor_fms(char vendor[static (CPUID_VENDOR_SZ + 1)], int *family, 
> int *model, int *stepping)

Oops, will fix it.

> 
> ERROR: space prohibited between function name and open parenthesis '('
> #20: FILE: target/i386/cpu.c:685:
> +void host_vendor_fms(char vendor[static (CPUID_VENDOR_SZ + 1)], int *family, 
> int *model, int *stepping)

False positive.

> 
> ERROR: storage class should be at the beginning of the declaration
> #20: FILE: target/i386/cpu.c:685:
> +void host_vendor_fms(char vendor[static (CPUID_VENDOR_SZ + 1)], int *family, 
> int *model, int *stepping)
> 

False positive.

> ERROR: line over 90 characters
> #57: FILE: target/i386/cpu.c:1599:
> +host_vendor_fms(host_cpudef.vendor, _cpudef.family, 
> _cpudef.model, _cpudef.stepping);

Will fix it.

> 
> ERROR: line over 90 characters
> #69: FILE: target/i386/cpu.h:1426:
> +void host_vendor_fms(char vendor[static (CPUID_VENDOR_SZ + 1)], int *family, 
> int *model, int *stepping);

Will fix it.

> 
> ERROR: space prohibited between function name and open parenthesis '('
> #69: FILE: target/i386/cpu.h:1426:
> +void host_vendor_fms(char vendor[static (CPUID_VENDOR_SZ + 1)], int *family, 
> int *model, int *stepping);

False positive.

> 
> ERROR: storage class should be at the beginning of the declaration
> #69: FILE: target/i386/cpu.h:1426:
> +void host_vendor_fms(char vendor[static (CPUID_VENDOR_SZ + 1)], int *family, 
> int *model, int *stepping);

False positive.

> 
> total: 7 errors, 0 warnings, 50 lines checked
> 
> Your patch has style problems, please review.  If any of these errors
> are false positives report them to the maintainer, see
> CHECKPATCH in MAINTAINERS.
> 
> Checking PATCH 3/5: i386/kvm: Blacklist TSX on known broken hosts...
> Checking PATCH 4/5: pc: Add 2.9 machine-types...
> Checking PATCH 5/5: i386: Change stepping of Haswell to non-blacklisted 
> value...
> === OUTPUT END ===
> 
> Test command exited with code: 1
> 
> 
> ---
> Email generated automatically by Patchew [http://patchew.org/].
> Please send your feedback to patchew-de...@freelists.org

-- 
Eduardo

Re: [Qemu-devel] [PATCH 0/5] Use non-blacklisted family/model/stepping for Haswell CPU model

[no-reply]

Hi,

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

Message-id: 20170108194041.10908-1-ehabk...@redhat.com
Subject: [Qemu-devel] [PATCH 0/5] Use non-blacklisted family/model/stepping for 
Haswell CPU model
Type: series

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

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

# Useful git options
git config --local diff.renamelimit 0
git config --local diff.renames True

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

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

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
 * [new tag] patchew/20170108194041.10908-1-ehabk...@redhat.com -> 
patchew/20170108194041.10908-1-ehabk...@redhat.com
Switched to a new branch 'test'
d179b85 i386: Change stepping of Haswell to non-blacklisted value
d1e2a1c pc: Add 2.9 machine-types
fd67612 i386/kvm: Blacklist TSX on known broken hosts
2639996 i386: host_vendor_fms() helper function
06c2fb0 i386: Add explicit array size to x86_cpu_vendor_words2str()

=== OUTPUT BEGIN ===
Checking PATCH 1/5: i386: Add explicit array size to 
x86_cpu_vendor_words2str()...
ERROR: line over 90 characters
#27: FILE: target/i386/cpu.c:172:
+static void x86_cpu_vendor_words2str(char dst[static (CPUID_VENDOR_SZ + 1)], 
uint32_t vendor1,

ERROR: space prohibited between function name and open parenthesis '('
#27: FILE: target/i386/cpu.c:172:
+static void x86_cpu_vendor_words2str(char dst[static (CPUID_VENDOR_SZ + 1)], 
uint32_t vendor1,

total: 2 errors, 0 warnings, 8 lines checked

Your patch has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.

Checking PATCH 2/5: i386: host_vendor_fms() helper function...
ERROR: line over 90 characters
#20: FILE: target/i386/cpu.c:685:
+void host_vendor_fms(char vendor[static (CPUID_VENDOR_SZ + 1)], int *family, 
int *model, int *stepping)

ERROR: space prohibited between function name and open parenthesis '('
#20: FILE: target/i386/cpu.c:685:
+void host_vendor_fms(char vendor[static (CPUID_VENDOR_SZ + 1)], int *family, 
int *model, int *stepping)

ERROR: storage class should be at the beginning of the declaration
#20: FILE: target/i386/cpu.c:685:
+void host_vendor_fms(char vendor[static (CPUID_VENDOR_SZ + 1)], int *family, 
int *model, int *stepping)

ERROR: line over 90 characters
#57: FILE: target/i386/cpu.c:1599:
+host_vendor_fms(host_cpudef.vendor, _cpudef.family, 
_cpudef.model, _cpudef.stepping);

ERROR: line over 90 characters
#69: FILE: target/i386/cpu.h:1426:
+void host_vendor_fms(char vendor[static (CPUID_VENDOR_SZ + 1)], int *family, 
int *model, int *stepping);

ERROR: space prohibited between function name and open parenthesis '('
#69: FILE: target/i386/cpu.h:1426:
+void host_vendor_fms(char vendor[static (CPUID_VENDOR_SZ + 1)], int *family, 
int *model, int *stepping);

ERROR: storage class should be at the beginning of the declaration
#69: FILE: target/i386/cpu.h:1426:
+void host_vendor_fms(char vendor[static (CPUID_VENDOR_SZ + 1)], int *family, 
int *model, int *stepping);

total: 7 errors, 0 warnings, 50 lines checked

Your patch has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.

Checking PATCH 3/5: i386/kvm: Blacklist TSX on known broken hosts...
Checking PATCH 4/5: pc: Add 2.9 machine-types...
Checking PATCH 5/5: i386: Change stepping of Haswell to non-blacklisted value...
=== OUTPUT END ===

Test command exited with code: 1


---
Email generated automatically by Patchew [http://patchew.org/].
Please send your feedback to patchew-de...@freelists.org

[Qemu-devel] [PATCH 3/5] i386/kvm: Blacklist TSX on known broken hosts

[Eduardo Habkost]

Some Intel CPUs are known to have a broken TSX implementation. A
microcode update from Intel disabled TSX on those CPUs, but
GET_SUPPORTED_CPUID might be reporting it as supported if the
hosts were not updated yet.

Manually fixup the GET_SUPPORTED_CPUID data to ensure we will
never enable TSX when running on those hosts.

Reference:
* glibc commit 2702856bf45c82cf8e69f2064f5aa15c0ceb6359:
  
https://sourceware.org/git/?p=glibc.git;a=commit;h=2702856bf45c82cf8e69f2064f5aa15c0ceb6359

Signed-off-by: Eduardo Habkost 
---
 target/i386/kvm.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/target/i386/kvm.c b/target/i386/kvm.c
index 10a9cd8f7f..3e99512640 100644
--- a/target/i386/kvm.c
+++ b/target/i386/kvm.c
@@ -272,6 +272,19 @@ static int get_para_features(KVMState *s)
 return features;
 }
 
+static bool host_tsx_blacklisted(void)
+{
+int family, model, stepping;\
+char vendor[CPUID_VENDOR_SZ + 1];
+
+host_vendor_fms(vendor, , , );
+
+/* Check if we are running on a Haswell host known to have broken TSX */
+return !strcmp(vendor, CPUID_VENDOR_INTEL) &&
+   (family == 6) &&
+   ((model == 63 && stepping < 4) ||
+model == 60 || model == 69 || model == 70);
+}
 
 /* Returns the value for a specific register on the cpuid entry
  */
@@ -355,6 +368,10 @@ uint32_t kvm_arch_get_supported_cpuid(KVMState *s, 
uint32_t function,
 }
 } else if (function == 6 && reg == R_EAX) {
 ret |= CPUID_6_EAX_ARAT; /* safe to allow because of emulated APIC */
+} else if (function == 7 && index == 0 && reg == R_EBX) {
+if (host_tsx_blacklisted()) {
+ret &= ~(CPUID_7_0_EBX_RTM | CPUID_7_0_EBX_HLE);
+}
 } else if (function == 0x8001 && reg == R_EDX) {
 /* On Intel, kvm returns cpuid according to the Intel spec,
  * so add missing bits according to the AMD spec:
-- 
2.11.0.259.g40922b1

[Qemu-devel] [PATCH 4/5] pc: Add 2.9 machine-types

[Eduardo Habkost]

Cc: "Michael S. Tsirkin" 
Cc: Laszlo Ersek 
Cc: Igor Mammedov 
Signed-off-by: Eduardo Habkost 
---
Changes v1 -> v2:
* Added extra backslash to PC_COMPAT_2_8 definition
  * Suggested-by: Laszlo Ersek 
---
 include/hw/i386/pc.h |  2 ++
 hw/i386/pc_piix.c| 15 ---
 hw/i386/pc_q35.c | 13 +++--
 3 files changed, 25 insertions(+), 5 deletions(-)

diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index b22e699c46..230e9e70c5 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -375,6 +375,8 @@ int e820_get_num_entries(void);
 bool e820_get_entry(int, uint32_t, uint64_t *, uint64_t *);
 
 #define PC_COMPAT_2_8 \
+HW_COMPAT_2_8 \
+
 
 #define PC_COMPAT_2_7 \
 HW_COMPAT_2_7 \
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 5e1adbe53c..9f102aa388 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -437,13 +437,24 @@ static void pc_i440fx_machine_options(MachineClass *m)
 m->default_display = "std";
 }
 
-static void pc_i440fx_2_8_machine_options(MachineClass *m)
+static void pc_i440fx_2_9_machine_options(MachineClass *m)
 {
 pc_i440fx_machine_options(m);
 m->alias = "pc";
 m->is_default = 1;
 }
 
+DEFINE_I440FX_MACHINE(v2_9, "pc-i440fx-2.9", NULL,
+  pc_i440fx_2_9_machine_options);
+
+static void pc_i440fx_2_8_machine_options(MachineClass *m)
+{
+pc_i440fx_2_9_machine_options(m);
+m->is_default = 0;
+m->alias = NULL;
+SET_MACHINE_COMPAT(m, PC_COMPAT_2_8);
+}
+
 DEFINE_I440FX_MACHINE(v2_8, "pc-i440fx-2.8", NULL,
   pc_i440fx_2_8_machine_options);
 
@@ -451,8 +462,6 @@ DEFINE_I440FX_MACHINE(v2_8, "pc-i440fx-2.8", NULL,
 static void pc_i440fx_2_7_machine_options(MachineClass *m)
 {
 pc_i440fx_2_8_machine_options(m);
-m->is_default = 0;
-m->alias = NULL;
 SET_MACHINE_COMPAT(m, PC_COMPAT_2_7);
 }
 
diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index d042fe0843..dd792a8547 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -301,19 +301,28 @@ static void pc_q35_machine_options(MachineClass *m)
 m->max_cpus = 288;
 }
 
-static void pc_q35_2_8_machine_options(MachineClass *m)
+static void pc_q35_2_9_machine_options(MachineClass *m)
 {
 pc_q35_machine_options(m);
 m->alias = "q35";
 }
 
+DEFINE_Q35_MACHINE(v2_9, "pc-q35-2.9", NULL,
+   pc_q35_2_9_machine_options);
+
+static void pc_q35_2_8_machine_options(MachineClass *m)
+{
+pc_q35_2_9_machine_options(m);
+m->alias = NULL;
+SET_MACHINE_COMPAT(m, PC_COMPAT_2_8);
+}
+
 DEFINE_Q35_MACHINE(v2_8, "pc-q35-2.8", NULL,
pc_q35_2_8_machine_options);
 
 static void pc_q35_2_7_machine_options(MachineClass *m)
 {
 pc_q35_2_8_machine_options(m);
-m->alias = NULL;
 m->max_cpus = 255;
 SET_MACHINE_COMPAT(m, PC_COMPAT_2_7);
 }
-- 
2.11.0.259.g40922b1

[Qemu-devel] [PATCH 5/5] i386: Change stepping of Haswell to non-blacklisted value

[Eduardo Habkost]

glibc blacklists TSX on Haswell CPUs with model==60 and
stepping < 4. To make the Haswell CPU model more useful, make
those guests actually use TSX by changing CPU stepping to 4.

References:
* glibc commit 2702856bf45c82cf8e69f2064f5aa15c0ceb6359
  
https://sourceware.org/git/?p=glibc.git;a=commit;h=2702856bf45c82cf8e69f2064f5aa15c0ceb6359

Signed-off-by: Eduardo Habkost 
---
 include/hw/i386/pc.h | 6 +-
 target/i386/cpu.c| 2 +-
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index 230e9e70c5..fcd9b4f541 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -376,7 +376,11 @@ bool e820_get_entry(int, uint32_t, uint64_t *, uint64_t *);
 
 #define PC_COMPAT_2_8 \
 HW_COMPAT_2_8 \
-
+{\
+.driver   = "Haswell-" TYPE_X86_CPU,\
+.property = "stepping",\
+.value= "1",\
+},
 
 #define PC_COMPAT_2_7 \
 HW_COMPAT_2_7 \
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 9dbb2d98da..003de7e74f 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -1190,7 +1190,7 @@ static X86CPUDefinition builtin_x86_defs[] = {
 .vendor = CPUID_VENDOR_INTEL,
 .family = 6,
 .model = 60,
-.stepping = 1,
+.stepping = 4,
 .features[FEAT_1_EDX] =
 CPUID_VME | CPUID_SSE2 | CPUID_SSE | CPUID_FXSR | CPUID_MMX |
 CPUID_CLFLUSH | CPUID_PSE36 | CPUID_PAT | CPUID_CMOV | CPUID_MCA |
-- 
2.11.0.259.g40922b1

[Qemu-devel] [PATCH 2/5] i386: host_vendor_fms() helper function

[Eduardo Habkost]

Helper function for code that needs to check the host CPU
vendor/family/model/stepping values.

Signed-off-by: Eduardo Habkost 
---
 target/i386/cpu.h |  1 +
 target/i386/cpu.c | 28 
 2 files changed, 21 insertions(+), 8 deletions(-)

diff --git a/target/i386/cpu.h b/target/i386/cpu.h
index a7f2f6099d..0f4a9d412b 100644
--- a/target/i386/cpu.h
+++ b/target/i386/cpu.h
@@ -1423,6 +1423,7 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index, 
uint32_t count,
 void cpu_clear_apic_feature(CPUX86State *env);
 void host_cpuid(uint32_t function, uint32_t count,
 uint32_t *eax, uint32_t *ebx, uint32_t *ecx, uint32_t *edx);
+void host_vendor_fms(char vendor[static (CPUID_VENDOR_SZ + 1)], int *family, 
int *model, int *stepping);
 
 /* helper.c */
 int x86_cpu_handle_mmu_fault(CPUState *cpu, vaddr addr,
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 25b802bb06..9dbb2d98da 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -682,6 +682,25 @@ void host_cpuid(uint32_t function, uint32_t count,
 *edx = vec[3];
 }
 
+void host_vendor_fms(char vendor[static (CPUID_VENDOR_SZ + 1)], int *family, 
int *model, int *stepping)
+{
+uint32_t eax, ebx, ecx, edx;
+
+host_cpuid(0x0, 0, , , , );
+x86_cpu_vendor_words2str(vendor, ebx, edx, ecx);
+
+host_cpuid(0x1, 0, , , , );
+if (family) {
+*family = ((eax >> 8) & 0x0F) + ((eax >> 20) & 0xFF);
+}
+if (model) {
+*model = ((eax >> 4) & 0x0F) | ((eax & 0xF) >> 12);
+}
+if (stepping) {
+*stepping = eax & 0x0F;
+}
+}
+
 /* CPU class name definitions: */
 
 #define X86_CPU_TYPE_SUFFIX "-" TYPE_X86_CPU
@@ -1574,17 +1593,10 @@ static void host_x86_cpu_class_init(ObjectClass *oc, 
void *data)
 {
 DeviceClass *dc = DEVICE_CLASS(oc);
 X86CPUClass *xcc = X86_CPU_CLASS(oc);
-uint32_t eax = 0, ebx = 0, ecx = 0, edx = 0;
 
 xcc->kvm_required = true;
 
-host_cpuid(0x0, 0, , , , );
-x86_cpu_vendor_words2str(host_cpudef.vendor, ebx, edx, ecx);
-
-host_cpuid(0x1, 0, , , , );
-host_cpudef.family = ((eax >> 8) & 0x0F) + ((eax >> 20) & 0xFF);
-host_cpudef.model = ((eax >> 4) & 0x0F) | ((eax & 0xF) >> 12);
-host_cpudef.stepping = eax & 0x0F;
+host_vendor_fms(host_cpudef.vendor, _cpudef.family, 
_cpudef.model, _cpudef.stepping);
 
 cpu_x86_fill_model_id(host_cpudef.model_id);
 
-- 
2.11.0.259.g40922b1

[Qemu-devel] [PATCH 1/5] i386: Add explicit array size to x86_cpu_vendor_words2str()

[Eduardo Habkost]

Add explicit array size to x86_cpu_vendor_words2str() to let the
compiler check if we are really passing an array of the right
size.

GCC still doesn't print a warning when the array is too small[1],
but clang already does.

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50584

Signed-off-by: Eduardo Habkost 
---
 target/i386/cpu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index a149c8dc42..25b802bb06 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -169,7 +169,7 @@
 
 
 
-static void x86_cpu_vendor_words2str(char *dst, uint32_t vendor1,
+static void x86_cpu_vendor_words2str(char dst[static (CPUID_VENDOR_SZ + 1)], 
uint32_t vendor1,
  uint32_t vendor2, uint32_t vendor3)
 {
 int i;
-- 
2.11.0.259.g40922b1

[Qemu-devel] [PATCH 0/5] Use non-blacklisted family/model/stepping for Haswell CPU model

[Eduardo Habkost]

A recent glibc commit[1] added a blacklist to ensure it won't use
TSX on hosts that are known to have a broken TSX implementation.

Our existing Haswell CPU model has a blacklisted
family/model/stepping combination, so it has to be updated to
make sure guests will really use TSX. This is done by patch 5/5.

However, to do this safely we need to ensure the host CPU is not
a blacklisted one, so we won't mislead guests by exposing
known-to-be-good FMS values on a known-to-be-broken host. This is
done by patch 3/5.

[1] 
https://sourceware.org/git/?p=glibc.git;a=commit;h=2702856bf45c82cf8e69f2064f5aa15c0ceb6359

---
Cc: dgilb...@redhat.com
Cc: fwei...@redhat.com
Cc: car...@redhat.com
Cc: trie...@redhat.com
Cc: berra...@redhat.com
Cc: jdene...@redhat.com
Cc: pbonz...@redhat.com

Eduardo Habkost (5):
  i386: Add explicit array size to x86_cpu_vendor_words2str()
  i386: host_vendor_fms() helper function
  i386/kvm: Blacklist TSX on known broken hosts
  pc: Add 2.9 machine-types
  i386: Change stepping of Haswell to non-blacklisted value

 include/hw/i386/pc.h |  6 ++
 target/i386/cpu.h|  1 +
 hw/i386/pc_piix.c| 15 ---
 hw/i386/pc_q35.c | 13 +++--
 target/i386/cpu.c| 32 ++--
 target/i386/kvm.c| 17 +
 6 files changed, 69 insertions(+), 15 deletions(-)

-- 
2.11.0.259.g40922b1

[Qemu-devel] [PULL 09/11] tcg-mips: Adjust calling conventions for mips64

[Richard Henderson]

From: Jin Guojie 

Tested-by: Aurelien Jarno 
Tested-by: James Hogan 
Tested-by: YunQiang Su 
Signed-off-by: Richard Henderson 
Signed-off-by: Jin Guojie 
Message-Id: <1483592275-4496-10-git-send-email-jinguo...@loongson.cn>
---
 tcg/mips/tcg-target.h | 19 +++
 tcg/mips/tcg-target.inc.c | 21 +++--
 2 files changed, 30 insertions(+), 10 deletions(-)

diff --git a/tcg/mips/tcg-target.h b/tcg/mips/tcg-target.h
index 4b7d3ae..d352c97 100644
--- a/tcg/mips/tcg-target.h
+++ b/tcg/mips/tcg-target.h
@@ -27,7 +27,14 @@
 #ifndef MIPS_TCG_TARGET_H
 #define MIPS_TCG_TARGET_H
 
-#define TCG_TARGET_REG_BITS 32
+#if _MIPS_SIM == _ABIO32
+# define TCG_TARGET_REG_BITS 32
+#elif _MIPS_SIM == _ABIN32 || _MIPS_SIM == _ABI64
+# define TCG_TARGET_REG_BITS 64
+#else
+# error "Unknown ABI"
+#endif
+
 #define TCG_TARGET_INSN_UNIT_SIZE 4
 #define TCG_TARGET_TLB_DISPLACEMENT_BITS 16
 #define TCG_TARGET_NB_REGS 32
@@ -71,9 +78,13 @@ typedef enum {
 } TCGReg;
 
 /* used for function call generation */
-#define TCG_TARGET_STACK_ALIGN 8
-#define TCG_TARGET_CALL_STACK_OFFSET 16
-#define TCG_TARGET_CALL_ALIGN_ARGS 1
+#define TCG_TARGET_STACK_ALIGN16
+#if _MIPS_SIM == _ABIO32
+# define TCG_TARGET_CALL_STACK_OFFSET 16
+#else
+# define TCG_TARGET_CALL_STACK_OFFSET 0
+#endif
+#define TCG_TARGET_CALL_ALIGN_ARGS1
 
 /* MOVN/MOVZ instructions detection */
 #if (defined(__mips_isa_rev) && (__mips_isa_rev >= 1)) || \
diff --git a/tcg/mips/tcg-target.inc.c b/tcg/mips/tcg-target.inc.c
index b7e2586..7282a4a 100644
--- a/tcg/mips/tcg-target.inc.c
+++ b/tcg/mips/tcg-target.inc.c
@@ -91,10 +91,6 @@ static const int tcg_target_reg_alloc_order[] = {
 TCG_REG_S8,
 
 /* Call clobbered registers.  */
-TCG_REG_T0,
-TCG_REG_T1,
-TCG_REG_T2,
-TCG_REG_T3,
 TCG_REG_T4,
 TCG_REG_T5,
 TCG_REG_T6,
@@ -105,17 +101,27 @@ static const int tcg_target_reg_alloc_order[] = {
 TCG_REG_V0,
 
 /* Argument registers, opposite order of allocation.  */
+TCG_REG_T3,
+TCG_REG_T2,
+TCG_REG_T1,
+TCG_REG_T0,
 TCG_REG_A3,
 TCG_REG_A2,
 TCG_REG_A1,
 TCG_REG_A0,
 };
 
-static const TCGReg tcg_target_call_iarg_regs[4] = {
+static const TCGReg tcg_target_call_iarg_regs[] = {
 TCG_REG_A0,
 TCG_REG_A1,
 TCG_REG_A2,
-TCG_REG_A3
+TCG_REG_A3,
+#if _MIPS_SIM == _ABIN32 || _MIPS_SIM == _ABI64
+TCG_REG_T0,
+TCG_REG_T1,
+TCG_REG_T2,
+TCG_REG_T3,
+#endif
 };
 
 static const TCGReg tcg_target_call_oarg_regs[2] = {
@@ -2427,6 +2433,9 @@ static void tcg_target_init(TCGContext *s)
 {
 tcg_target_detect_isa();
 tcg_regset_set(tcg_target_available_regs[TCG_TYPE_I32], 0x);
+if (TCG_TARGET_REG_BITS == 64) {
+tcg_regset_set(tcg_target_available_regs[TCG_TYPE_I64], 0x);
+}
 tcg_regset_set(tcg_target_call_clobber_regs,
(1 << TCG_REG_V0) |
(1 << TCG_REG_V1) |
-- 
2.9.3

[Qemu-devel] [PULL 10/11] tcg-mips: Adjust qemu_ld/st for mips64

[Richard Henderson]

From: Jin Guojie 

Tested-by: Aurelien Jarno 
Tested-by: James Hogan 
Tested-by: YunQiang Su 
Signed-off-by: Richard Henderson 
Signed-off-by: Jin Guojie 
Message-Id: <1483592275-4496-11-git-send-email-jinguo...@loongson.cn>
---
 tcg/mips/tcg-target.inc.c | 203 +-
 1 file changed, 146 insertions(+), 57 deletions(-)

diff --git a/tcg/mips/tcg-target.inc.c b/tcg/mips/tcg-target.inc.c
index 7282a4a..5b2fe98 100644
--- a/tcg/mips/tcg-target.inc.c
+++ b/tcg/mips/tcg-target.inc.c
@@ -32,8 +32,16 @@
 # define MIPS_BE  0
 #endif
 
-#define LO_OFF(MIPS_BE * 4)
-#define HI_OFF(4 - LO_OFF)
+#if TCG_TARGET_REG_BITS == 32
+# define LO_OFF  (MIPS_BE * 4)
+# define HI_OFF  (4 - LO_OFF)
+#else
+/* To assert at compile-time that these values are never used
+   for TCG_TARGET_REG_BITS == 64.  */
+/* extern */ int link_error(void);
+# define LO_OFF  link_error()
+# define HI_OFF  link_error()
+#endif
 
 #ifdef CONFIG_DEBUG_TCG
 static const char * const tcg_target_reg_names[TCG_TARGET_NB_REGS] = {
@@ -193,7 +201,7 @@ static int target_parse_constraint(TCGArgConstraint *ct, 
const char **pct_str)
 tcg_regset_set(ct->u.regs, 0x);
 tcg_regset_reset_reg(ct->u.regs, TCG_REG_A0);
 #if defined(CONFIG_SOFTMMU)
-if (TARGET_LONG_BITS == 64) {
+if (TCG_TARGET_REG_BITS < TARGET_LONG_BITS) {
 tcg_regset_reset_reg(ct->u.regs, TCG_REG_A2);
 }
 #endif
@@ -203,11 +211,11 @@ static int target_parse_constraint(TCGArgConstraint *ct, 
const char **pct_str)
 tcg_regset_set(ct->u.regs, 0x);
 tcg_regset_reset_reg(ct->u.regs, TCG_REG_A0);
 #if defined(CONFIG_SOFTMMU)
-if (TARGET_LONG_BITS == 32) {
-tcg_regset_reset_reg(ct->u.regs, TCG_REG_A1);
-} else {
+if (TCG_TARGET_REG_BITS < TARGET_LONG_BITS) {
 tcg_regset_reset_reg(ct->u.regs, TCG_REG_A2);
 tcg_regset_reset_reg(ct->u.regs, TCG_REG_A3);
+} else {
+tcg_regset_reset_reg(ct->u.regs, TCG_REG_A1);
 }
 #endif
 break;
@@ -1104,6 +1112,10 @@ static void * const qemu_ld_helpers[16] = {
 [MO_BESW] = helper_be_ldsw_mmu,
 [MO_BEUL] = helper_be_ldul_mmu,
 [MO_BEQ]  = helper_be_ldq_mmu,
+#if TCG_TARGET_REG_BITS == 64
+[MO_LESL] = helper_le_ldsl_mmu,
+[MO_BESL] = helper_be_ldsl_mmu,
+#endif
 };
 
 static void * const qemu_st_helpers[16] = {
@@ -1131,6 +1143,9 @@ static int tcg_out_call_iarg_reg(TCGContext *s, int i, 
TCGReg arg)
 if (i < ARRAY_SIZE(tcg_target_call_iarg_regs)) {
 tcg_out_mov(s, TCG_TYPE_REG, tcg_target_call_iarg_regs[i], arg);
 } else {
+/* For N32 and N64, the initial offset is different.  But there
+   we also have 8 argument register so we don't run out here.  */
+tcg_debug_assert(TCG_TARGET_REG_BITS == 32);
 tcg_out_st(s, TCG_TYPE_REG, arg, TCG_REG_SP, 4 * i);
 }
 return i + 1;
@@ -1172,6 +1187,7 @@ static int tcg_out_call_iarg_imm(TCGContext *s, int i, 
TCGArg arg)
 
 static int tcg_out_call_iarg_reg2(TCGContext *s, int i, TCGReg al, TCGReg ah)
 {
+tcg_debug_assert(TCG_TARGET_REG_BITS == 32);
 i = (i + 1) & ~1;
 i = tcg_out_call_iarg_reg(s, i, (MIPS_BE ? ah : al));
 i = tcg_out_call_iarg_reg(s, i, (MIPS_BE ? al : ah));
@@ -1179,7 +1195,7 @@ static int tcg_out_call_iarg_reg2(TCGContext *s, int i, 
TCGReg al, TCGReg ah)
 }
 
 /* Perform the tlb comparison operation.  The complete host address is
-   placed in BASE.  Clobbers TMP0, TMP1, A0.  */
+   placed in BASE.  Clobbers TMP0, TMP1, TMP2, A0.  */
 static void tcg_out_tlb_load(TCGContext *s, TCGReg base, TCGReg addrl,
  TCGReg addrh, TCGMemOpIdx oi,
  tcg_insn_unit *label_ptr[2], bool is_load)
@@ -1187,6 +1203,7 @@ static void tcg_out_tlb_load(TCGContext *s, TCGReg base, 
TCGReg addrl,
 TCGMemOp opc = get_memop(oi);
 unsigned s_bits = opc & MO_SIZE;
 unsigned a_bits = get_alignment_bits(opc);
+target_ulong mask;
 int mem_index = get_mmuidx(oi);
 int cmp_off
 = (is_load
@@ -1194,11 +1211,11 @@ static void tcg_out_tlb_load(TCGContext *s, TCGReg 
base, TCGReg addrl,
: offsetof(CPUArchState, tlb_table[mem_index][0].addr_write));
 int add_off = offsetof(CPUArchState, tlb_table[mem_index][0].addend);
 
-tcg_out_opc_sa(s, OPC_SRL, TCG_REG_A0, addrl,
+tcg_out_opc_sa(s, ALIAS_TSRL, TCG_REG_A0, addrl,
TARGET_PAGE_BITS - CPU_TLB_ENTRY_BITS);
 tcg_out_opc_imm(s, OPC_ANDI, TCG_REG_A0, TCG_REG_A0,
 (CPU_TLB_SIZE - 1) << CPU_TLB_ENTRY_BITS);
-tcg_out_opc_reg(s, OPC_ADDU, TCG_REG_A0, TCG_REG_A0, TCG_AREG0);
+tcg_out_opc_reg(s, ALIAS_PADD, TCG_REG_A0, TCG_REG_A0, TCG_AREG0);
 
 /* Compensate for very large offsets.  */
 if (add_off >= 

[Qemu-devel] [PULL 11/11] translate-all: Avoid -Werror=switch-bool

[Richard Henderson]

gcc 5.3.0 diagnoses

translate-all.c: In function ‘alloc_code_gen_buffer’:
translate-all.c:756:17: error: switch condition has boolean value
 switch (buf2 != MAP_FAILED) {
 ^

Signed-off-by: Richard Henderson 
---
 translate-all.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/translate-all.c b/translate-all.c
index 3dd9214..2026293 100644
--- a/translate-all.c
+++ b/translate-all.c
@@ -753,7 +753,7 @@ static inline void *alloc_code_gen_buffer(void)
 size_t size2;
 void *buf2 = mmap(NULL, size + qemu_real_host_page_size,
   PROT_NONE, flags, -1, 0);
-switch (buf2 != MAP_FAILED) {
+switch ((int)(buf2 != MAP_FAILED)) {
 case 1:
 if (!cross_256mb(buf2, size)) {
 /* Success!  Use the new buffer.  */
-- 
2.9.3

[Qemu-devel] [PULL 08/11] tcg-mips: Add tcg unwind info

[Richard Henderson]

From: Jin Guojie 

Tested-by: Aurelien Jarno 
Tested-by: James Hogan 
Tested-by: YunQiang Su 
Signed-off-by: Richard Henderson 
Signed-off-by: Jin Guojie 
Message-Id: <1483592275-4496-9-git-send-email-jinguo...@loongson.cn>
---
 tcg/mips/tcg-target.inc.c | 44 
 1 file changed, 44 insertions(+)

diff --git a/tcg/mips/tcg-target.inc.c b/tcg/mips/tcg-target.inc.c
index 9e24662..b7e2586 100644
--- a/tcg/mips/tcg-target.inc.c
+++ b/tcg/mips/tcg-target.inc.c
@@ -2465,3 +2465,47 @@ void tb_set_jmp_target1(uintptr_t jmp_addr, uintptr_t 
addr)
 atomic_set((uint32_t *)jmp_addr, deposit32(OPC_J, 0, 26, addr >> 2));
 flush_icache_range(jmp_addr, jmp_addr + 4);
 }
+
+typedef struct {
+DebugFrameHeader h;
+uint8_t fde_def_cfa[4];
+uint8_t fde_reg_ofs[ARRAY_SIZE(tcg_target_callee_save_regs) * 2];
+} DebugFrame;
+
+#define ELF_HOST_MACHINE EM_MIPS
+/* GDB doesn't appear to require proper setting of ELF_HOST_FLAGS,
+   which is good because they're really quite complicated for MIPS.  */
+
+static const DebugFrame debug_frame = {
+.h.cie.len = sizeof(DebugFrameCIE) - 4, /* length after .len member */
+.h.cie.id = -1,
+.h.cie.version = 1,
+.h.cie.code_align = 1,
+.h.cie.data_align = -(TCG_TARGET_REG_BITS / 8) & 0x7f, /* sleb128 */
+.h.cie.return_column = TCG_REG_RA,
+
+/* Total FDE size does not include the "len" member.  */
+.h.fde.len = sizeof(DebugFrame) - offsetof(DebugFrame, h.fde.cie_offset),
+
+.fde_def_cfa = {
+12, TCG_REG_SP, /* DW_CFA_def_cfa sp, ... */
+(FRAME_SIZE & 0x7f) | 0x80, /* ... uleb128 FRAME_SIZE */
+(FRAME_SIZE >> 7)
+},
+.fde_reg_ofs = {
+0x80 + 16, 9,   /* DW_CFA_offset, s0, -72 */
+0x80 + 17, 8,   /* DW_CFA_offset, s2, -64 */
+0x80 + 18, 7,   /* DW_CFA_offset, s3, -56 */
+0x80 + 19, 6,   /* DW_CFA_offset, s4, -48 */
+0x80 + 20, 5,   /* DW_CFA_offset, s5, -40 */
+0x80 + 21, 4,   /* DW_CFA_offset, s6, -32 */
+0x80 + 22, 3,   /* DW_CFA_offset, s7, -24 */
+0x80 + 30, 2,   /* DW_CFA_offset, s8, -16 */
+0x80 + 31, 1,   /* DW_CFA_offset, ra,  -8 */
+}
+};
+
+void tcg_register_jit(void *buf, size_t buf_size)
+{
+tcg_register_jit_int(buf, buf_size, _frame, sizeof(debug_frame));
+}
-- 
2.9.3

[Qemu-devel] [PULL 07/11] tcg-mips: Adjust prologue for mips64

[Richard Henderson]

From: Jin Guojie 

Take stack frame parameters out from the function body.

Tested-by: Aurelien Jarno 
Tested-by: James Hogan 
Tested-by: YunQiang Su 
Signed-off-by: Richard Henderson 
Signed-off-by: Jin Guojie 
Message-Id: <1483592275-4496-8-git-send-email-jinguo...@loongson.cn>
---
 tcg/mips/tcg-target.inc.c | 54 ++-
 1 file changed, 25 insertions(+), 29 deletions(-)

diff --git a/tcg/mips/tcg-target.inc.c b/tcg/mips/tcg-target.inc.c
index 5cc8df3..9e24662 100644
--- a/tcg/mips/tcg-target.inc.c
+++ b/tcg/mips/tcg-target.inc.c
@@ -734,16 +734,6 @@ static inline bool tcg_out_sti(TCGContext *s, TCGType 
type, TCGArg val,
 return false;
 }
 
-static inline void tcg_out_addi(TCGContext *s, TCGReg reg, TCGArg val)
-{
-if (val == (int16_t)val) {
-tcg_out_opc_imm(s, OPC_ADDIU, reg, reg, val);
-} else {
-tcg_out_movi(s, TCG_TYPE_PTR, TCG_TMP0, val);
-tcg_out_opc_reg(s, OPC_ADDU, reg, reg, TCG_TMP0);
-}
-}
-
 static void tcg_out_addsub2(TCGContext *s, TCGReg rl, TCGReg rh, TCGReg al,
 TCGReg ah, TCGArg bl, TCGArg bh, bool cbl,
 bool cbh, bool is_sub)
@@ -2270,42 +2260,48 @@ static tcg_insn_unit *align_code_ptr(TCGContext *s)
 return s->code_ptr;
 }
 
+/* Stack frame parameters.  */
+#define REG_SIZE   (TCG_TARGET_REG_BITS / 8)
+#define SAVE_SIZE  ((int)ARRAY_SIZE(tcg_target_callee_save_regs) * REG_SIZE)
+#define TEMP_SIZE  (CPU_TEMP_BUF_NLONGS * (int)sizeof(long))
+
+#define FRAME_SIZE ((TCG_STATIC_CALL_ARGS_SIZE + TEMP_SIZE + SAVE_SIZE \
+ + TCG_TARGET_STACK_ALIGN - 1) \
+& -TCG_TARGET_STACK_ALIGN)
+#define SAVE_OFS   (TCG_STATIC_CALL_ARGS_SIZE + TEMP_SIZE)
+
+/* We're expecting to be able to use an immediate for frame allocation.  */
+QEMU_BUILD_BUG_ON(FRAME_SIZE > 0x7fff);
+
 /* Generate global QEMU prologue and epilogue code */
 static void tcg_target_qemu_prologue(TCGContext *s)
 {
-int i, frame_size;
+int i;
 
-/* reserve some stack space, also for TCG temps. */
-frame_size = ARRAY_SIZE(tcg_target_callee_save_regs) * 4
- + TCG_STATIC_CALL_ARGS_SIZE
- + CPU_TEMP_BUF_NLONGS * sizeof(long);
-frame_size = (frame_size + TCG_TARGET_STACK_ALIGN - 1) &
- ~(TCG_TARGET_STACK_ALIGN - 1);
-tcg_set_frame(s, TCG_REG_SP, ARRAY_SIZE(tcg_target_callee_save_regs) * 4
-  + TCG_STATIC_CALL_ARGS_SIZE,
-  CPU_TEMP_BUF_NLONGS * sizeof(long));
+tcg_set_frame(s, TCG_REG_SP, TCG_STATIC_CALL_ARGS_SIZE, TEMP_SIZE);
 
 /* TB prologue */
-tcg_out_addi(s, TCG_REG_SP, -frame_size);
-for(i = 0 ; i < ARRAY_SIZE(tcg_target_callee_save_regs) ; i++) {
-tcg_out_st(s, TCG_TYPE_I32, tcg_target_callee_save_regs[i],
-   TCG_REG_SP, TCG_STATIC_CALL_ARGS_SIZE + i * 4);
+tcg_out_opc_imm(s, ALIAS_PADDI, TCG_REG_SP, TCG_REG_SP, -FRAME_SIZE);
+for (i = 0; i < ARRAY_SIZE(tcg_target_callee_save_regs); i++) {
+tcg_out_st(s, TCG_TYPE_REG, tcg_target_callee_save_regs[i],
+   TCG_REG_SP, SAVE_OFS + i * REG_SIZE);
 }
 
 /* Call generated code */
 tcg_out_opc_reg(s, OPC_JR, 0, tcg_target_call_iarg_regs[1], 0);
+/* delay slot */
 tcg_out_mov(s, TCG_TYPE_PTR, TCG_AREG0, tcg_target_call_iarg_regs[0]);
-tb_ret_addr = s->code_ptr;
 
 /* TB epilogue */
-for(i = 0 ; i < ARRAY_SIZE(tcg_target_callee_save_regs) ; i++) {
-tcg_out_ld(s, TCG_TYPE_I32, tcg_target_callee_save_regs[i],
-   TCG_REG_SP, TCG_STATIC_CALL_ARGS_SIZE + i * 4);
+tb_ret_addr = s->code_ptr;
+for (i = 0; i < ARRAY_SIZE(tcg_target_callee_save_regs); i++) {
+tcg_out_ld(s, TCG_TYPE_REG, tcg_target_callee_save_regs[i],
+   TCG_REG_SP, SAVE_OFS + i * REG_SIZE);
 }
 
 tcg_out_opc_reg(s, OPC_JR, 0, TCG_REG_RA, 0);
 /* delay slot */
-tcg_out_addi(s, TCG_REG_SP, frame_size);
+tcg_out_opc_imm(s, ALIAS_PADDI, TCG_REG_SP, TCG_REG_SP, FRAME_SIZE);
 
 if (use_mips32r2_instructions) {
 return;
-- 
2.9.3

[Qemu-devel] [PULL 06/11] tcg-mips: Adjust load/store functions for mips64

[Richard Henderson]

From: Jin Guojie 

tcg_out_ldst: using a generic ALIAS_PADD to avoid ifdefs
tcg_out_ld: generates LD or LW
tcg_out_st: generates SD or SW

Tested-by: Aurelien Jarno 
Tested-by: James Hogan 
Tested-by: YunQiang Su 
Signed-off-by: Richard Henderson 
Signed-off-by: Jin Guojie 
Message-Id: <1483592275-4496-7-git-send-email-jinguo...@loongson.cn>
---
 tcg/mips/tcg-target.inc.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/tcg/mips/tcg-target.inc.c b/tcg/mips/tcg-target.inc.c
index 18368f0..5cc8df3 100644
--- a/tcg/mips/tcg-target.inc.c
+++ b/tcg/mips/tcg-target.inc.c
@@ -697,7 +697,7 @@ static void tcg_out_ldst(TCGContext *s, MIPSInsn opc, 
TCGReg data,
 if (ofs != lo) {
 tcg_out_movi(s, TCG_TYPE_PTR, TCG_TMP0, ofs - lo);
 if (addr != TCG_REG_ZERO) {
-tcg_out_opc_reg(s, OPC_ADDU, TCG_TMP0, TCG_TMP0, addr);
+tcg_out_opc_reg(s, ALIAS_PADD, TCG_TMP0, TCG_TMP0, addr);
 }
 addr = TCG_TMP0;
 }
@@ -707,13 +707,21 @@ static void tcg_out_ldst(TCGContext *s, MIPSInsn opc, 
TCGReg data,
 static inline void tcg_out_ld(TCGContext *s, TCGType type, TCGReg arg,
   TCGReg arg1, intptr_t arg2)
 {
-tcg_out_ldst(s, OPC_LW, arg, arg1, arg2);
+MIPSInsn opc = OPC_LD;
+if (TCG_TARGET_REG_BITS == 32 || type == TCG_TYPE_I32) {
+opc = OPC_LW;
+}
+tcg_out_ldst(s, opc, arg, arg1, arg2);
 }
 
 static inline void tcg_out_st(TCGContext *s, TCGType type, TCGReg arg,
   TCGReg arg1, intptr_t arg2)
 {
-tcg_out_ldst(s, OPC_SW, arg, arg1, arg2);
+MIPSInsn opc = OPC_SD;
+if (TCG_TARGET_REG_BITS == 32 || type == TCG_TYPE_I32) {
+opc = OPC_SW;
+}
+tcg_out_ldst(s, opc, arg, arg1, arg2);
 }
 
 static inline bool tcg_out_sti(TCGContext *s, TCGType type, TCGArg val,
-- 
2.9.3

[Qemu-devel] [PULL 01/11] tcg-mips: Move bswap code to a subroutine

[Richard Henderson]

From: Jin Guojie 

Without the mips32r2 instructions to perform swapping, bswap is quite large,
dominating the size of each reverse-endian qemu_ld/qemu_st operation.

Create a subroutine in the prologue block.  The subroutine requires extra
reserved registers (TCG_TMP[2, 3]).  Using these within qemu_ld means that
we need not place additional restrictions on the qemu_ld outputs.

Tested-by: Aurelien Jarno 
Tested-by: James Hogan 
Tested-by: YunQiang Su 
Signed-off-by: Richard Henderson 
Signed-off-by: Jin Guojie 
Message-Id: <1483592275-4496-2-git-send-email-jinguo...@loongson.cn>
---
 tcg/mips/tcg-target.h |   2 +-
 tcg/mips/tcg-target.inc.c | 207 ++
 2 files changed, 139 insertions(+), 70 deletions(-)

diff --git a/tcg/mips/tcg-target.h b/tcg/mips/tcg-target.h
index 3aeac87..a6871fb 100644
--- a/tcg/mips/tcg-target.h
+++ b/tcg/mips/tcg-target.h
@@ -117,11 +117,11 @@ extern bool use_mips32r2_instructions;
 #define TCG_TARGET_HAS_muls2_i32(!use_mips32r6_instructions)
 #define TCG_TARGET_HAS_muluh_i321
 #define TCG_TARGET_HAS_mulsh_i321
+#define TCG_TARGET_HAS_bswap32_i32  1
 
 /* optional instructions detected at runtime */
 #define TCG_TARGET_HAS_movcond_i32  use_movnz_instructions
 #define TCG_TARGET_HAS_bswap16_i32  use_mips32r2_instructions
-#define TCG_TARGET_HAS_bswap32_i32  use_mips32r2_instructions
 #define TCG_TARGET_HAS_deposit_i32  use_mips32r2_instructions
 #define TCG_TARGET_HAS_ext8s_i32use_mips32r2_instructions
 #define TCG_TARGET_HAS_ext16s_i32   use_mips32r2_instructions
diff --git a/tcg/mips/tcg-target.inc.c b/tcg/mips/tcg-target.inc.c
index abce602..2b116ea 100644
--- a/tcg/mips/tcg-target.inc.c
+++ b/tcg/mips/tcg-target.inc.c
@@ -74,6 +74,8 @@ static const char * const 
tcg_target_reg_names[TCG_TARGET_NB_REGS] = {
 
 #define TCG_TMP0  TCG_REG_AT
 #define TCG_TMP1  TCG_REG_T9
+#define TCG_TMP2  TCG_REG_T8
+#define TCG_TMP3  TCG_REG_T7
 
 /* check if we really need so many registers :P */
 static const int tcg_target_reg_alloc_order[] = {
@@ -122,6 +124,7 @@ static const TCGReg tcg_target_call_oarg_regs[2] = {
 };
 
 static tcg_insn_unit *tb_ret_addr;
+static tcg_insn_unit *bswap32_addr;
 
 static inline uint32_t reloc_pc16_val(tcg_insn_unit *pc, tcg_insn_unit *target)
 {
@@ -177,12 +180,7 @@ static int target_parse_constraint(TCGArgConstraint *ct, 
const char **pct_str)
 ct->ct |= TCG_CT_REG;
 tcg_regset_set(ct->u.regs, 0x);
 break;
-case 'L': /* qemu_ld output arg constraint */
-ct->ct |= TCG_CT_REG;
-tcg_regset_set(ct->u.regs, 0x);
-tcg_regset_reset_reg(ct->u.regs, TCG_REG_V0);
-break;
-case 'l': /* qemu_ld input arg constraint */
+case 'L': /* qemu_ld input arg constraint */
 ct->ct |= TCG_CT_REG;
 tcg_regset_set(ct->u.regs, 0x);
 tcg_regset_reset_reg(ct->u.regs, TCG_REG_A0);
@@ -513,29 +511,22 @@ static inline void tcg_out_bswap16s(TCGContext *s, TCGReg 
ret, TCGReg arg)
 }
 }
 
-static inline void tcg_out_bswap32(TCGContext *s, TCGReg ret, TCGReg arg)
+static void tcg_out_bswap_subr(TCGContext *s, tcg_insn_unit *sub)
+{
+bool ok = tcg_out_opc_jmp(s, OPC_JAL, sub);
+tcg_debug_assert(ok);
+}
+
+static void tcg_out_bswap32(TCGContext *s, TCGReg ret, TCGReg arg)
 {
 if (use_mips32r2_instructions) {
 tcg_out_opc_reg(s, OPC_WSBH, ret, 0, arg);
 tcg_out_opc_sa(s, OPC_ROTR, ret, ret, 16);
 } else {
-/* ret and arg must be different and can't be register at */
-if (ret == arg || ret == TCG_TMP0 || arg == TCG_TMP0) {
-tcg_abort();
-}
-
-tcg_out_opc_sa(s, OPC_SLL, ret, arg, 24);
-
-tcg_out_opc_sa(s, OPC_SRL, TCG_TMP0, arg, 24);
-tcg_out_opc_reg(s, OPC_OR, ret, ret, TCG_TMP0);
-
-tcg_out_opc_imm(s, OPC_ANDI, TCG_TMP0, arg, 0xff00);
-tcg_out_opc_sa(s, OPC_SLL, TCG_TMP0, TCG_TMP0, 8);
-tcg_out_opc_reg(s, OPC_OR, ret, ret, TCG_TMP0);
-
-tcg_out_opc_sa(s, OPC_SRL, TCG_TMP0, arg, 8);
-tcg_out_opc_imm(s, OPC_ANDI, TCG_TMP0, TCG_TMP0, 0xff00);
-tcg_out_opc_reg(s, OPC_OR, ret, ret, TCG_TMP0);
+tcg_out_bswap_subr(s, bswap32_addr);
+/* delay slot -- never omit the insn, like tcg_out_mov might.  */
+tcg_out_opc_reg(s, OPC_OR, TCG_TMP0, arg, TCG_REG_ZERO);
+tcg_out_mov(s, TCG_TYPE_I32, ret, TCG_TMP3);
 }
 }
 
@@ -1044,7 +1035,7 @@ static int tcg_out_call_iarg_reg2(TCGContext *s, int i, 
TCGReg al, TCGReg ah)
 }
 
 /* Perform the tlb comparison operation.  The complete host address is
-   placed in BASE.  Clobbers AT, T0, A0.  */
+   placed in BASE.  Clobbers TMP0, TMP1, A0.  */
 static void tcg_out_tlb_load(TCGContext *s, TCGReg base, TCGReg addrl,
  TCGReg 

[Qemu-devel] [PULL 05/11] tcg-mips: Adjust move functions for mips64

[Richard Henderson]

From: Jin Guojie 

tcg_out_mov: using OPC_OR as most mips assemblers do;
tcg_out_movi: extended to 64-bit immediate.

Tested-by: Aurelien Jarno 
Tested-by: James Hogan 
Tested-by: YunQiang Su 
Signed-off-by: Richard Henderson 
Signed-off-by: Jin Guojie 
Message-Id: <1483592275-4496-6-git-send-email-jinguo...@loongson.cn>
---
 tcg/mips/tcg-target.inc.c | 34 +-
 1 file changed, 25 insertions(+), 9 deletions(-)

diff --git a/tcg/mips/tcg-target.inc.c b/tcg/mips/tcg-target.inc.c
index ec139cd..18368f0 100644
--- a/tcg/mips/tcg-target.inc.c
+++ b/tcg/mips/tcg-target.inc.c
@@ -544,23 +544,39 @@ static inline void tcg_out_mov(TCGContext *s, TCGType 
type,
 {
 /* Simple reg-reg move, optimising out the 'do nothing' case */
 if (ret != arg) {
-tcg_out_opc_reg(s, OPC_ADDU, ret, arg, TCG_REG_ZERO);
+tcg_out_opc_reg(s, OPC_OR, ret, arg, TCG_REG_ZERO);
 }
 }
 
-static inline void tcg_out_movi(TCGContext *s, TCGType type,
-TCGReg reg, tcg_target_long arg)
+static void tcg_out_movi(TCGContext *s, TCGType type,
+ TCGReg ret, tcg_target_long arg)
 {
+if (TCG_TARGET_REG_BITS == 64 && type == TCG_TYPE_I32) {
+arg = (int32_t)arg;
+}
 if (arg == (int16_t)arg) {
-tcg_out_opc_imm(s, OPC_ADDIU, reg, TCG_REG_ZERO, arg);
-} else if (arg == (uint16_t)arg) {
-tcg_out_opc_imm(s, OPC_ORI, reg, TCG_REG_ZERO, arg);
+tcg_out_opc_imm(s, OPC_ADDIU, ret, TCG_REG_ZERO, arg);
+return;
+}
+if (arg == (uint16_t)arg) {
+tcg_out_opc_imm(s, OPC_ORI, ret, TCG_REG_ZERO, arg);
+return;
+}
+if (TCG_TARGET_REG_BITS == 32 || arg == (int32_t)arg) {
+tcg_out_opc_imm(s, OPC_LUI, ret, TCG_REG_ZERO, arg >> 16);
 } else {
-tcg_out_opc_imm(s, OPC_LUI, reg, TCG_REG_ZERO, arg >> 16);
-if (arg & 0x) {
-tcg_out_opc_imm(s, OPC_ORI, reg, reg, arg & 0x);
+tcg_out_movi(s, TCG_TYPE_I32, ret, arg >> 31 >> 1);
+if (arg & 0xull) {
+tcg_out_dsll(s, ret, ret, 16);
+tcg_out_opc_imm(s, OPC_ORI, ret, ret, arg >> 16);
+tcg_out_dsll(s, ret, ret, 16);
+} else {
+tcg_out_dsll(s, ret, ret, 32);
 }
 }
+if (arg & 0x) {
+tcg_out_opc_imm(s, OPC_ORI, ret, ret, arg & 0x);
+}
 }
 
 static inline void tcg_out_bswap16(TCGContext *s, TCGReg ret, TCGReg arg)
-- 
2.9.3

[Qemu-devel] [PULL 03/11] tcg-mips: Support 64-bit opcodes

[Richard Henderson]

From: Jin Guojie 

Bulk patch adding 64-bit opcodes into tcg_out_op.  Note that
mips64 is as yet neither complete nor enabled.

Tested-by: Aurelien Jarno 
Tested-by: James Hogan 
Tested-by: YunQiang Su 
Signed-off-by: Richard Henderson 
Signed-off-by: Jin Guojie 
Message-Id: <1483592275-4496-4-git-send-email-jinguo...@loongson.cn>
---
 tcg/mips/tcg-target.h |  41 ++
 tcg/mips/tcg-target.inc.c | 322 --
 2 files changed, 353 insertions(+), 10 deletions(-)

diff --git a/tcg/mips/tcg-target.h b/tcg/mips/tcg-target.h
index a6871fb..4b7d3ae 100644
--- a/tcg/mips/tcg-target.h
+++ b/tcg/mips/tcg-target.h
@@ -27,6 +27,7 @@
 #ifndef MIPS_TCG_TARGET_H
 #define MIPS_TCG_TARGET_H
 
+#define TCG_TARGET_REG_BITS 32
 #define TCG_TARGET_INSN_UNIT_SIZE 4
 #define TCG_TARGET_TLB_DISPLACEMENT_BITS 16
 #define TCG_TARGET_NB_REGS 32
@@ -119,6 +120,29 @@ extern bool use_mips32r2_instructions;
 #define TCG_TARGET_HAS_mulsh_i321
 #define TCG_TARGET_HAS_bswap32_i32  1
 
+#if TCG_TARGET_REG_BITS == 64
+#define TCG_TARGET_HAS_add2_i32 0
+#define TCG_TARGET_HAS_sub2_i32 0
+#define TCG_TARGET_HAS_extrl_i64_i321
+#define TCG_TARGET_HAS_extrh_i64_i321
+#define TCG_TARGET_HAS_div_i64  1
+#define TCG_TARGET_HAS_rem_i64  1
+#define TCG_TARGET_HAS_not_i64  1
+#define TCG_TARGET_HAS_nor_i64  1
+#define TCG_TARGET_HAS_andc_i64 0
+#define TCG_TARGET_HAS_orc_i64  0
+#define TCG_TARGET_HAS_eqv_i64  0
+#define TCG_TARGET_HAS_nand_i64 0
+#define TCG_TARGET_HAS_add2_i64 0
+#define TCG_TARGET_HAS_sub2_i64 0
+#define TCG_TARGET_HAS_mulu2_i64(!use_mips32r6_instructions)
+#define TCG_TARGET_HAS_muls2_i64(!use_mips32r6_instructions)
+#define TCG_TARGET_HAS_muluh_i641
+#define TCG_TARGET_HAS_mulsh_i641
+#define TCG_TARGET_HAS_ext32s_i64   1
+#define TCG_TARGET_HAS_ext32u_i64   1
+#endif
+
 /* optional instructions detected at runtime */
 #define TCG_TARGET_HAS_movcond_i32  use_movnz_instructions
 #define TCG_TARGET_HAS_bswap16_i32  use_mips32r2_instructions
@@ -127,11 +151,28 @@ extern bool use_mips32r2_instructions;
 #define TCG_TARGET_HAS_ext16s_i32   use_mips32r2_instructions
 #define TCG_TARGET_HAS_rot_i32  use_mips32r2_instructions
 
+#if TCG_TARGET_REG_BITS == 64
+#define TCG_TARGET_HAS_movcond_i64  use_movnz_instructions
+#define TCG_TARGET_HAS_bswap16_i64  use_mips32r2_instructions
+#define TCG_TARGET_HAS_bswap32_i64  use_mips32r2_instructions
+#define TCG_TARGET_HAS_bswap64_i64  use_mips32r2_instructions
+#define TCG_TARGET_HAS_deposit_i64  use_mips32r2_instructions
+#define TCG_TARGET_HAS_ext8s_i64use_mips32r2_instructions
+#define TCG_TARGET_HAS_ext16s_i64   use_mips32r2_instructions
+#define TCG_TARGET_HAS_rot_i64  use_mips32r2_instructions
+#endif
+
 /* optional instructions automatically implemented */
 #define TCG_TARGET_HAS_neg_i32  0 /* sub  rd, zero, rt   */
 #define TCG_TARGET_HAS_ext8u_i320 /* andi rt, rs, 0xff   */
 #define TCG_TARGET_HAS_ext16u_i32   0 /* andi rt, rs, 0x */
 
+#if TCG_TARGET_REG_BITS == 64
+#define TCG_TARGET_HAS_neg_i64  0 /* sub  rd, zero, rt   */
+#define TCG_TARGET_HAS_ext8u_i640 /* andi rt, rs, 0xff   */
+#define TCG_TARGET_HAS_ext16u_i64   0 /* andi rt, rs, 0x */
+#endif
+
 #ifdef __OpenBSD__
 #include 
 #else
diff --git a/tcg/mips/tcg-target.inc.c b/tcg/mips/tcg-target.inc.c
index fb84ea5..2d91d0c 100644
--- a/tcg/mips/tcg-target.inc.c
+++ b/tcg/mips/tcg-target.inc.c
@@ -437,6 +437,21 @@ static inline void tcg_out_opc_bf(TCGContext *s, MIPSInsn 
opc, TCGReg rt,
 tcg_out32(s, inst);
 }
 
+static inline void tcg_out_opc_bf64(TCGContext *s, MIPSInsn opc, MIPSInsn opm,
+MIPSInsn oph, TCGReg rt, TCGReg rs,
+int msb, int lsb)
+{
+if (lsb >= 32) {
+opc = oph;
+msb -= 32;
+lsb -= 32;
+} else if (msb >= 32) {
+opc = opm;
+msb -= 32;
+}
+tcg_out_opc_bf(s, opc, rt, rs, msb, lsb);
+}
+
 /*
  * Type branch
  */
@@ -467,6 +482,18 @@ static inline void tcg_out_opc_sa(TCGContext *s, MIPSInsn 
opc,
 
 }
 
+static void tcg_out_opc_sa64(TCGContext *s, MIPSInsn opc1, MIPSInsn opc2,
+ TCGReg rd, TCGReg rt, TCGArg sa)
+{
+int32_t inst;
+
+inst = (sa & 32 ? opc2 : opc1);
+inst |= (rt & 0x1F) << 16;
+inst |= (rd & 0x1F) << 11;
+inst |= (sa & 0x1F) <<  6;
+tcg_out32(s, inst);
+}
+
 /*
  * Type jump.
  * Returns true if the branch was in range and the insn was emitted.
@@ -495,6 +522,21 @@ static inline void tcg_out_nop(TCGContext *s)
 tcg_out32(s, 0);
 }
 
+static inline void tcg_out_dsll(TCGContext *s, TCGReg 

[Qemu-devel] [PULL 04/11] tcg-mips: Add bswap32u and bswap64

[Richard Henderson]

From: Jin Guojie 

Without the mips32r2 instructions to perform swapping, bswap is quite large,
dominating the size of each reverse-endian qemu_ld/qemu_st operation.

Create two subroutines in the prologue block.  The subroutines require extra
reserved registers (TCG_TMP[2, 3]).  Using these within qemu_ld means that
we need not place additional restrictions on the qemu_ld outputs.

Tested-by: Aurelien Jarno 
Tested-by: James Hogan 
Tested-by: YunQiang Su 
Signed-off-by: Richard Henderson 
Signed-off-by: Jin Guojie 
Message-Id: <1483592275-4496-5-git-send-email-jinguo...@loongson.cn>
---
 tcg/mips/tcg-target.inc.c | 102 --
 1 file changed, 99 insertions(+), 3 deletions(-)

diff --git a/tcg/mips/tcg-target.inc.c b/tcg/mips/tcg-target.inc.c
index 2d91d0c..ec139cd 100644
--- a/tcg/mips/tcg-target.inc.c
+++ b/tcg/mips/tcg-target.inc.c
@@ -125,6 +125,8 @@ static const TCGReg tcg_target_call_oarg_regs[2] = {
 
 static tcg_insn_unit *tb_ret_addr;
 static tcg_insn_unit *bswap32_addr;
+static tcg_insn_unit *bswap32u_addr;
+static tcg_insn_unit *bswap64_addr;
 
 static inline uint32_t reloc_pc16_val(tcg_insn_unit *pc, tcg_insn_unit *target)
 {
@@ -622,7 +624,10 @@ static void tcg_out_bswap32u(TCGContext *s, TCGReg ret, 
TCGReg arg)
 tcg_out_opc_reg(s, OPC_DSHD, ret, 0, ret);
 tcg_out_dsrl(s, ret, ret, 32);
 } else {
-abort();
+tcg_out_bswap_subr(s, bswap32u_addr);
+/* delay slot -- never omit the insn, like tcg_out_mov might.  */
+tcg_out_opc_reg(s, OPC_OR, TCG_TMP0, arg, TCG_REG_ZERO);
+tcg_out_mov(s, TCG_TYPE_I32, ret, TCG_TMP3);
 }
 }
 
@@ -632,7 +637,10 @@ static void tcg_out_bswap64(TCGContext *s, TCGReg ret, 
TCGReg arg)
 tcg_out_opc_reg(s, OPC_DSBH, ret, 0, arg);
 tcg_out_opc_reg(s, OPC_DSHD, ret, 0, ret);
 } else {
-abort();
+tcg_out_bswap_subr(s, bswap64_addr);
+/* delay slot -- never omit the insn, like tcg_out_mov might.  */
+tcg_out_opc_reg(s, OPC_OR, TCG_TMP0, arg, TCG_REG_ZERO);
+tcg_out_mov(s, TCG_TYPE_I32, ret, TCG_TMP3);
 }
 }
 
@@ -2279,7 +2287,7 @@ static void tcg_target_qemu_prologue(TCGContext *s)
 return;
 }
 
-/* Bswap subroutine: Input in TCG_TMP0, output in TCG_TMP3;
+/* Bswap subroutines: Input in TCG_TMP0, output in TCG_TMP3;
clobbers TCG_TMP1, TCG_TMP2.  */
 
 /*
@@ -2305,6 +2313,94 @@ static void tcg_target_qemu_prologue(TCGContext *s)
 tcg_out_opc_reg(s, OPC_JR, 0, TCG_REG_RA, 0);
 /* t3 = dcba -- delay slot */
 tcg_out_opc_reg(s, OPC_OR, TCG_TMP3, TCG_TMP3, TCG_TMP1);
+
+if (TCG_TARGET_REG_BITS == 32) {
+return;
+}
+
+/*
+ * bswap32u -- unsigned 32-bit swap.  a0 = abcd.
+ */
+bswap32u_addr = align_code_ptr(s);
+/* t1 = ()000d */
+tcg_out_opc_imm(s, OPC_ANDI, TCG_TMP1, TCG_TMP0, 0xff);
+/* t3 = 000a */
+tcg_out_opc_sa(s, OPC_SRL, TCG_TMP3, TCG_TMP0, 24);
+/* t1 = ()d000 */
+tcg_out_dsll(s, TCG_TMP1, TCG_TMP1, 24);
+/* t2 = 00c0 */
+tcg_out_opc_imm(s, OPC_ANDI, TCG_TMP2, TCG_TMP0, 0xff00);
+/* t3 = d00a */
+tcg_out_opc_reg(s, OPC_OR, TCG_TMP3, TCG_TMP3, TCG_TMP1);
+/* t1 = 0abc */
+tcg_out_opc_sa(s, OPC_SRL, TCG_TMP1, TCG_TMP0, 8);
+/* t2 = 0c00 */
+tcg_out_opc_sa(s, OPC_SLL, TCG_TMP2, TCG_TMP2, 8);
+/* t1 = 00b0 */
+tcg_out_opc_imm(s, OPC_ANDI, TCG_TMP1, TCG_TMP1, 0xff00);
+/* t3 = dc0a */
+tcg_out_opc_reg(s, OPC_OR, TCG_TMP3, TCG_TMP3, TCG_TMP2);
+tcg_out_opc_reg(s, OPC_JR, 0, TCG_REG_RA, 0);
+/* t3 = dcba -- delay slot */
+tcg_out_opc_reg(s, OPC_OR, TCG_TMP3, TCG_TMP3, TCG_TMP1);
+
+/*
+ * bswap64 -- 64-bit swap.  a0 = abcdefgh
+ */
+bswap64_addr = align_code_ptr(s);
+/* t3 = h000 */
+tcg_out_dsll(s, TCG_TMP3, TCG_TMP0, 56);
+/* t1 = 000a */
+tcg_out_dsrl(s, TCG_TMP1, TCG_TMP0, 56);
+
+/* t2 = 00g0 */
+tcg_out_opc_imm(s, OPC_ANDI, TCG_TMP2, TCG_TMP0, 0xff00);
+/* t3 = h00a */
+tcg_out_opc_reg(s, OPC_OR, TCG_TMP3, TCG_TMP3, TCG_TMP1);
+/* t1 = 0abc */
+tcg_out_dsrl(s, TCG_TMP1, TCG_TMP0, 40);
+/* t2 = 0g00 */
+tcg_out_dsll(s, TCG_TMP2, TCG_TMP2, 40);
+/* t1 = 00b0 */
+tcg_out_opc_imm(s, OPC_ANDI, TCG_TMP1, TCG_TMP1, 0xff00);
+
+/* t3 = hg0a */
+tcg_out_opc_reg(s, OPC_OR, TCG_TMP3, TCG_TMP3, TCG_TMP2);
+/* t2 = abcd */
+tcg_out_dsrl(s, TCG_TMP2, TCG_TMP0, 32);
+/* t3 = hgba */
+tcg_out_opc_reg(s, OPC_OR, TCG_TMP3, TCG_TMP3, TCG_TMP1);
+
+/* t1 = 00c0 */
+tcg_out_opc_imm(s, OPC_ANDI, TCG_TMP1, TCG_TMP2, 0xff00);
+/* t2 = 000d */
+tcg_out_opc_imm(s, OPC_ANDI, TCG_TMP2, TCG_TMP2, 0x00ff);
+/* t1 = 0c00 */
+tcg_out_dsll(s, TCG_TMP1, TCG_TMP1, 8);
+/* t2 

[Qemu-devel] [PULL 00/11] tcg host mips64 support

[Richard Henderson]

This is v6 of Jin Guojie's patch set, as tested by Aurelien Jarno,
James Hogan, and Yun Qiang Su.  Plus one more patch from me to fix
a trival Werror in mips specific code with gcc 5.3.


r~


Jin Guojie (10):
  tcg-mips: Move bswap code to a subroutine
  tcg-mips: Add mips64 opcodes
  tcg-mips: Support 64-bit opcodes
  tcg-mips: Add bswap32u and bswap64
  tcg-mips: Adjust move functions for mips64
  tcg-mips: Adjust load/store functions for mips64
  tcg-mips: Adjust prologue for mips64
  tcg-mips: Add tcg unwind info
  tcg-mips: Adjust calling conventions for mips64
  tcg-mips: Adjust qemu_ld/st for mips64

Richard Henderson (1):
  translate-all: Avoid -Werror=switch-bool

 tcg/mips/tcg-target.h |   60 ++-
 tcg/mips/tcg-target.inc.c | 1170 +++--
 translate-all.c   |2 +-
 3 files changed, 978 insertions(+), 254 deletions(-)

-- 
2.9.3

[Qemu-devel] [PULL 02/11] tcg-mips: Add mips64 opcodes

[Richard Henderson]

From: Jin Guojie 

Since the mips manual tables are in octal, reorg all of the opcodes
into that format for clarity.  Note that the 64-bit opcodes are as
yet unused.

Tested-by: Aurelien Jarno 
Tested-by: James Hogan 
Tested-by: YunQiang Su 
Signed-off-by: Richard Henderson 
Signed-off-by: Jin Guojie 
Message-Id: <1483592275-4496-3-git-send-email-jinguo...@loongson.cn>
---
 tcg/mips/tcg-target.inc.c | 193 --
 1 file changed, 118 insertions(+), 75 deletions(-)

diff --git a/tcg/mips/tcg-target.inc.c b/tcg/mips/tcg-target.inc.c
index 2b116ea..fb84ea5 100644
--- a/tcg/mips/tcg-target.inc.c
+++ b/tcg/mips/tcg-target.inc.c
@@ -254,81 +254,118 @@ static inline int tcg_target_const_match(tcg_target_long 
val, TCGType type,
 
 /* instruction opcodes */
 typedef enum {
-OPC_J= 0x02 << 26,
-OPC_JAL  = 0x03 << 26,
-OPC_BEQ  = 0x04 << 26,
-OPC_BNE  = 0x05 << 26,
-OPC_BLEZ = 0x06 << 26,
-OPC_BGTZ = 0x07 << 26,
-OPC_ADDIU= 0x09 << 26,
-OPC_SLTI = 0x0A << 26,
-OPC_SLTIU= 0x0B << 26,
-OPC_ANDI = 0x0C << 26,
-OPC_ORI  = 0x0D << 26,
-OPC_XORI = 0x0E << 26,
-OPC_LUI  = 0x0F << 26,
-OPC_LB   = 0x20 << 26,
-OPC_LH   = 0x21 << 26,
-OPC_LW   = 0x23 << 26,
-OPC_LBU  = 0x24 << 26,
-OPC_LHU  = 0x25 << 26,
-OPC_LWU  = 0x27 << 26,
-OPC_SB   = 0x28 << 26,
-OPC_SH   = 0x29 << 26,
-OPC_SW   = 0x2B << 26,
-
-OPC_SPECIAL  = 0x00 << 26,
-OPC_SLL  = OPC_SPECIAL | 0x00,
-OPC_SRL  = OPC_SPECIAL | 0x02,
-OPC_ROTR = OPC_SPECIAL | (0x01 << 21) | 0x02,
-OPC_SRA  = OPC_SPECIAL | 0x03,
-OPC_SLLV = OPC_SPECIAL | 0x04,
-OPC_SRLV = OPC_SPECIAL | 0x06,
-OPC_ROTRV= OPC_SPECIAL | (0x01 <<  6) | 0x06,
-OPC_SRAV = OPC_SPECIAL | 0x07,
-OPC_JR_R5= OPC_SPECIAL | 0x08,
-OPC_JALR = OPC_SPECIAL | 0x09,
-OPC_MOVZ = OPC_SPECIAL | 0x0A,
-OPC_MOVN = OPC_SPECIAL | 0x0B,
-OPC_SYNC = OPC_SPECIAL | 0x0F,
-OPC_MFHI = OPC_SPECIAL | 0x10,
-OPC_MFLO = OPC_SPECIAL | 0x12,
-OPC_MULT = OPC_SPECIAL | 0x18,
-OPC_MUL_R6   = OPC_SPECIAL | (0x02 <<  6) | 0x18,
-OPC_MUH  = OPC_SPECIAL | (0x03 <<  6) | 0x18,
-OPC_MULTU= OPC_SPECIAL | 0x19,
-OPC_MULU = OPC_SPECIAL | (0x02 <<  6) | 0x19,
-OPC_MUHU = OPC_SPECIAL | (0x03 <<  6) | 0x19,
-OPC_DIV  = OPC_SPECIAL | 0x1A,
-OPC_DIV_R6   = OPC_SPECIAL | (0x02 <<  6) | 0x1A,
-OPC_MOD  = OPC_SPECIAL | (0x03 <<  6) | 0x1A,
-OPC_DIVU = OPC_SPECIAL | 0x1B,
-OPC_DIVU_R6  = OPC_SPECIAL | (0x02 <<  6) | 0x1B,
-OPC_MODU = OPC_SPECIAL | (0x03 <<  6) | 0x1B,
-OPC_ADDU = OPC_SPECIAL | 0x21,
-OPC_SUBU = OPC_SPECIAL | 0x23,
-OPC_AND  = OPC_SPECIAL | 0x24,
-OPC_OR   = OPC_SPECIAL | 0x25,
-OPC_XOR  = OPC_SPECIAL | 0x26,
-OPC_NOR  = OPC_SPECIAL | 0x27,
-OPC_SLT  = OPC_SPECIAL | 0x2A,
-OPC_SLTU = OPC_SPECIAL | 0x2B,
-OPC_SELEQZ   = OPC_SPECIAL | 0x35,
-OPC_SELNEZ   = OPC_SPECIAL | 0x37,
-
-OPC_REGIMM   = 0x01 << 26,
-OPC_BLTZ = OPC_REGIMM | (0x00 << 16),
-OPC_BGEZ = OPC_REGIMM | (0x01 << 16),
-
-OPC_SPECIAL2 = 0x1c << 26,
-OPC_MUL_R5   = OPC_SPECIAL2 | 0x002,
-
-OPC_SPECIAL3 = 0x1f << 26,
-OPC_EXT  = OPC_SPECIAL3 | 0x000,
-OPC_INS  = OPC_SPECIAL3 | 0x004,
-OPC_WSBH = OPC_SPECIAL3 | 0x0a0,
-OPC_SEB  = OPC_SPECIAL3 | 0x420,
-OPC_SEH  = OPC_SPECIAL3 | 0x620,
+OPC_J= 002 << 26,
+OPC_JAL  = 003 << 26,
+OPC_BEQ  = 004 << 26,
+OPC_BNE  = 005 << 26,
+OPC_BLEZ = 006 << 26,
+OPC_BGTZ = 007 << 26,
+OPC_ADDIU= 011 << 26,
+OPC_SLTI = 012 << 26,
+OPC_SLTIU= 013 << 26,
+OPC_ANDI = 014 << 26,
+OPC_ORI  = 015 << 26,
+OPC_XORI = 016 << 26,
+OPC_LUI  = 017 << 26,
+OPC_DADDIU   = 031 << 26,
+OPC_LB   = 040 << 26,
+OPC_LH   = 041 << 26,
+OPC_LW   = 043 << 26,
+OPC_LBU  = 044 << 26,
+OPC_LHU  = 045 << 26,
+OPC_LWU  = 047 << 26,
+OPC_SB   = 050 << 26,
+OPC_SH   = 051 << 26,
+OPC_SW   = 053 << 26,
+OPC_LD   = 067 << 26,
+OPC_SD   = 077 << 26,
+
+OPC_SPECIAL  = 000 << 26,
+OPC_SLL  = OPC_SPECIAL | 000,
+OPC_SRL  = OPC_SPECIAL | 002,
+OPC_ROTR = OPC_SPECIAL | 002 | (1 << 21),
+OPC_SRA  = OPC_SPECIAL | 003,
+OPC_SLLV = OPC_SPECIAL | 004,
+OPC_SRLV = OPC_SPECIAL | 006,
+OPC_ROTRV= OPC_SPECIAL | 006 | 0100,
+OPC_SRAV = OPC_SPECIAL | 007,
+OPC_JR_R5= OPC_SPECIAL | 010,
+OPC_JALR = OPC_SPECIAL | 011,
+OPC_MOVZ = 

[Qemu-devel] [PATCH v3 0/2] Allow migration with invtsc if TSC frequency is explicitly set

[Eduardo Habkost]

This series makes QEMU accept migration if tsc-frequency is
explicitly set on configuration. As management software is
required to keep device configuration the same on migration
source or destination, explicit tsc-frequency will ensure that
either:

* The destination host has a matching TSC frequency; or
* The destination host has TSC scaling available.

Changelog
=

v2 -> v3:
* Fix build failure ((missing closing braces)

v1 -> v2:
* v1 series subject was:
  * [PATCH 0/4] Allow migration with invtsc if there's no
frequency mismatch
* Removed patches 3/4 and 4/4, that allowed migration
  if no explicit tsc-frequency was set. Implementing the check on
  post_load or post_init is not enough to make migration abort,
  so we will need a more complex solution to implement that
  feature.

Plans for future work
=

1) Querying host TSC frequency/scaling capability
-

I plan to include TSC frequency/scaling information on
query-cpu-model-expansion model="host" in a future series. Then
management software will be able to automatically configure TSC
frequency when invtsc is enabled, instead of requiring the user
to configure it explicitly. While we don't implement that, invtsc
migration will be possible only if the user configures TSC
frequency manually.

2) invtsc migration with no explicit TSC frequency
--

A future series can implement migration when TSC frequency is not
specified explicitly. It will be a bit more complex because it
requires either letting the destination abort the migration, or
sending TSC frequency/scaling information from destination to
source.

---
Cc: Marcelo Tosatti 
Cc: "Daniel P. Berrange" 
Cc: Paolo Bonzini 
Cc: k...@vger.kernel.org
Cc: Haozhong Zhang 
Cc: "Michael S. Tsirkin" 
Cc: Igor Mammedov 
Cc: libvir-l...@redhat.com
Cc: Jiri Denemark 

Eduardo Habkost (2):
  kvm: Simplify invtsc check
  kvm: Allow invtsc migration if tsc-khz is set explicitly

 target/i386/kvm.c | 20 +++-
 1 file changed, 11 insertions(+), 9 deletions(-)

-- 
2.11.0.259.g40922b1

[Qemu-devel] [PATCH v3 2/2] kvm: Allow invtsc migration if tsc-khz is set explicitly

[Eduardo Habkost]

We can safely allow a VM to be migrated with invtsc enabled if
tsc-khz is set explicitly, because:
* QEMU already refuses to start if it can't set the TSC frequency
  to the configured value.
* Management software is already required to keep device
  configuration (including CPU configuration) the same on
  migration source and destination.

Signed-off-by: Eduardo Habkost 
---
Changes v1 -> v2:
* Reworded commit message

Changes v2 -> v3:
* Fixed build failure
---
 target/i386/kvm.c | 20 +++-
 1 file changed, 11 insertions(+), 9 deletions(-)

diff --git a/target/i386/kvm.c b/target/i386/kvm.c
index a26290fdc1..abb5a41983 100644
--- a/target/i386/kvm.c
+++ b/target/i386/kvm.c
@@ -962,15 +962,17 @@ int kvm_arch_init_vcpu(CPUState *cs)
 has_msr_mcg_ext_ctl = has_msr_feature_control = true;
 }
 
-if ((env->features[FEAT_8000_0007_EDX] & CPUID_APM_INVTSC) &&
-invtsc_mig_blocker == NULL) {
-/* for migration */
-error_setg(_mig_blocker,
-   "State blocked by non-migratable CPU device"
-   " (invtsc flag)");
-migrate_add_blocker(invtsc_mig_blocker);
-/* for savevm */
-vmstate_x86_cpu.unmigratable = 1;
+if (!env->user_tsc_khz) {
+if ((env->features[FEAT_8000_0007_EDX] & CPUID_APM_INVTSC) &&
+invtsc_mig_blocker == NULL) {
+/* for migration */
+error_setg(_mig_blocker,
+   "State blocked by non-migratable CPU device"
+   " (invtsc flag)");
+migrate_add_blocker(invtsc_mig_blocker);
+/* for savevm */
+vmstate_x86_cpu.unmigratable = 1;
+}
 }
 
 cpuid_data.cpuid.padding = 0;
-- 
2.11.0.259.g40922b1

[Qemu-devel] [PATCH v3 1/2] kvm: Simplify invtsc check

[Eduardo Habkost]

Instead of searching the table we have just built, we can check
the env->features field directly.

Reviewed-by: Marcelo Tosatti 
Signed-off-by: Eduardo Habkost 
---
 target/i386/kvm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/target/i386/kvm.c b/target/i386/kvm.c
index 10a9cd8f7f..a26290fdc1 100644
--- a/target/i386/kvm.c
+++ b/target/i386/kvm.c
@@ -962,8 +962,8 @@ int kvm_arch_init_vcpu(CPUState *cs)
 has_msr_mcg_ext_ctl = has_msr_feature_control = true;
 }
 
-c = cpuid_find_entry(_data.cpuid, 0x8007, 0);
-if (c && (c->edx & 1<<8) && invtsc_mig_blocker == NULL) {
+if ((env->features[FEAT_8000_0007_EDX] & CPUID_APM_INVTSC) &&
+invtsc_mig_blocker == NULL) {
 /* for migration */
 error_setg(_mig_blocker,
"State blocked by non-migratable CPU device"
-- 
2.11.0.259.g40922b1

Re: [Qemu-devel] [PATCH v2 0/2] Allow migration with invtsc if TSC frequency is explicitly set

[Eduardo Habkost]

On Sun, Jan 08, 2017 at 09:19:49AM -0800, no-re...@patchew.org wrote:
> Hi,
> 
> Your series failed automatic build test. Please find the testing commands and
> their output below. If you have docker installed, you can probably reproduce 
> it
> locally.
> 
> Type: series
> Message-id: 20170108171330.11129-1-ehabk...@redhat.com
> Subject: [Qemu-devel] [PATCH v2 0/2] Allow migration with invtsc if TSC 
> frequency is explicitly set

Ouch. I simply removed patches 3/4 and 4/4 from the series, and
didn't notice there was a mistake in patch 1/2 corrected by patch
4/4 in v1. I will fix it and send v3, sorry for the noise.

-- 
Eduardo

Re: [Qemu-devel] [PATCH v2 0/2] Allow migration with invtsc if TSC frequency is explicitly set

[no-reply]

Hi,

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

Type: series
Message-id: 20170108171330.11129-1-ehabk...@redhat.com
Subject: [Qemu-devel] [PATCH v2 0/2] Allow migration with invtsc if TSC 
frequency is explicitly set

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

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
Switched to a new branch 'test'
3063255 kvm: Allow invtsc migration if tsc-khz is set explicitly
9e64420 kvm: Simplify invtsc check

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

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

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

[Qemu-devel] [PATCH v2 2/2] kvm: Allow invtsc migration if tsc-khz is set explicitly

[Eduardo Habkost]

We can safely allow a VM to be migrated with invtsc enabled if
tsc-khz is set explicitly, because:
* QEMU already refuses to start if it can't set the TSC frequency
  to the configured value.
* Management software is already required to keep device
  configuration (including CPU configuration) the same on
  migration source and destination.

Signed-off-by: Eduardo Habkost 
---
Changes v1 -> v2:
* Reworded commit message
---
 target/i386/kvm.c | 19 ++-
 1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/target/i386/kvm.c b/target/i386/kvm.c
index a26290fdc1..6a51399945 100644
--- a/target/i386/kvm.c
+++ b/target/i386/kvm.c
@@ -962,15 +962,16 @@ int kvm_arch_init_vcpu(CPUState *cs)
 has_msr_mcg_ext_ctl = has_msr_feature_control = true;
 }
 
-if ((env->features[FEAT_8000_0007_EDX] & CPUID_APM_INVTSC) &&
-invtsc_mig_blocker == NULL) {
-/* for migration */
-error_setg(_mig_blocker,
-   "State blocked by non-migratable CPU device"
-   " (invtsc flag)");
-migrate_add_blocker(invtsc_mig_blocker);
-/* for savevm */
-vmstate_x86_cpu.unmigratable = 1;
+if (!env->user_tsc_khz) {
+if ((env->features[FEAT_8000_0007_EDX] & CPUID_APM_INVTSC) &&
+invtsc_mig_blocker == NULL) {
+/* for migration */
+error_setg(_mig_blocker,
+   "State blocked by non-migratable CPU device"
+   " (invtsc flag)");
+migrate_add_blocker(invtsc_mig_blocker);
+/* for savevm */
+vmstate_x86_cpu.unmigratable = 1;
 }
 
 cpuid_data.cpuid.padding = 0;
-- 
2.11.0.259.g40922b1

[Qemu-devel] [PATCH v2 0/2] Allow migration with invtsc if TSC frequency is explicitly set

[Eduardo Habkost]

This series makes QEMU accept migration if tsc-frequency is
explicitly set on configuration. As management software is
required to keep device configuration the same on migration
source or destination, explicit tsc-frequency will ensure that
either:

* The destination host has a matching TSC frequency; or
* The destination host has TSC scaling available.

Changes series v1 -> v2
===

* v1 series subject was:
  * [PATCH 0/4] Allow migration with invtsc if there's no
frequency mismatch
* Removed patches 3/4 and 4/4, that allowed migration
  if no explicit tsc-frequency was set. Implementing the check on
  post_load or post_init is not enough to make migration abort,
  so we will need a more complex solution to implement that
  feature.

Plans for future work
=

1) Querying host TSC frequency/scaling capability
-

I plan to include TSC frequency/scaling information on
query-cpu-model-expansion model="host" in a future series. Then
management software will be able to automatically configure TSC
frequency when invtsc is enabled, instead of requiring the user
to configure it explicitly. While we don't implement that, invtsc
migration will be possible only if the user configures TSC
frequency manually.

2) invtsc migration with no explicit TSC frequency
--

A future series can implement migration when TSC frequency is not
specified explicitly. It will be a bit more complex because it
requires either letting the destination abort the migration, or
sending TSC frequency/scaling information from destination to
source.

---
Cc: Marcelo Tosatti 
Cc: "Daniel P. Berrange" 
Cc: Paolo Bonzini 
Cc: k...@vger.kernel.org
Cc: Haozhong Zhang 
Cc: "Michael S. Tsirkin" 
Cc: Igor Mammedov 
Cc: libvir-l...@redhat.com
Cc: Jiri Denemark 

Eduardo Habkost (2):
  kvm: Simplify invtsc check
  kvm: Allow invtsc migration if tsc-khz is set explicitly

 target/i386/kvm.c | 19 ++-
 1 file changed, 10 insertions(+), 9 deletions(-)

-- 
2.11.0.259.g40922b1

[Qemu-devel] [PATCH v2 1/2] kvm: Simplify invtsc check

[Eduardo Habkost]

Instead of searching the table we have just built, we can check
the env->features field directly.

Reviewed-by: Marcelo Tosatti 
Signed-off-by: Eduardo Habkost 
---
 target/i386/kvm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/target/i386/kvm.c b/target/i386/kvm.c
index 10a9cd8f7f..a26290fdc1 100644
--- a/target/i386/kvm.c
+++ b/target/i386/kvm.c
@@ -962,8 +962,8 @@ int kvm_arch_init_vcpu(CPUState *cs)
 has_msr_mcg_ext_ctl = has_msr_feature_control = true;
 }
 
-c = cpuid_find_entry(_data.cpuid, 0x8007, 0);
-if (c && (c->edx & 1<<8) && invtsc_mig_blocker == NULL) {
+if ((env->features[FEAT_8000_0007_EDX] & CPUID_APM_INVTSC) &&
+invtsc_mig_blocker == NULL) {
 /* for migration */
 error_setg(_mig_blocker,
"State blocked by non-migratable CPU device"
-- 
2.11.0.259.g40922b1

[Qemu-devel] How to make dest host abort migration safely (was Re: [PATCH 4/4] kvm: Allow migration with invtsc)

[Eduardo Habkost]

On Fri, Jan 06, 2017 at 08:31:27AM -0200, Marcelo Tosatti wrote:
> On Thu, Jan 05, 2017 at 10:19:50AM -0200, Eduardo Habkost wrote:
> > On Thu, Jan 05, 2017 at 08:48:32AM -0200, Marcelo Tosatti wrote:
> > > On Wed, Jan 04, 2017 at 11:36:31PM -0200, Eduardo Habkost wrote:
> > > > On Wed, Jan 04, 2017 at 08:26:27PM -0200, Marcelo Tosatti wrote:
> > > > > On Wed, Jan 04, 2017 at 05:59:17PM -0200, Eduardo Habkost wrote:
> > > > > > On Wed, Jan 04, 2017 at 11:39:16AM -0200, Eduardo Habkost wrote:
> > > > > > > On Wed, Jan 04, 2017 at 09:56:56AM -0200, Marcelo Tosatti wrote:
> > > > > > > > On Tue, Dec 27, 2016 at 05:21:20PM -0200, Eduardo Habkost wrote:
[...]
> > > > > Can't this be fixed in QEMU? Just check that destination host supports
> > > > > TSC scaling before migration (or that KVM_GET_TSC_KHZ return value
> > > > > matches on source and destination).
> > > > > 
> > > > 
> > > > This solves only one use case: where you want to expose the
> > > > starting host TSC frequency to the guest. It doesn't cover any
> > > > scenario where the TSC frequency of the starting host isn't the
> > > > best one. (See the two scenarios I described above)
> > > 
> > > True.
> > > 
> > > > You seem to have a specific use case in mind. If you describe it,
> > > > we could decide if it's worth the extra migration code complexity
> > > > to deal with invtsc migration without explicit tsc-frequency. By
> > > > now, I am not convinced yet.
> > > 
> > > I don't have any specific use case in mind. I'm just trying to
> > > avoid moving complexity to libvirt which in my experience is a
> > > the best thing to do.
> > 
> > I think both our proposals make things harder for libvirt in
> > different ways. I just want to make the complexity explicit for
> > libvirt, instead of giving them the illusion of safety (making
> > migration break in ways libvirt can't detect).
> > 
> > Anyway, your points are still valid and it would be still useful
> > to do what you propose. I will give it a try on a new version of
> > patch 4/4 that can abort migration earlier. But note that I
> > expect some pushback from other maintainers because of the
> > complexity of the code. If that happens, be aware that I won't be
> > able to justify the added complexity because I would still think
> > it's not worth it.

I tried to move the destination TSC-scaling check to post_load,
and the bad news is that post_load is also too late to abort
migration (destination aborts, but source shows migration as
completed).

I'm CCing Juan, Amit and David to see if they have any
suggestion.

Summarizing the problem for them: on some cases we want to allow
migration only if the destination host has a matching TSC
frequency or if TSC scaling is supported by the destination host.
I don't know what's the best way to implement that check. We
could either:

* Send TSC frequency/scaling info from the the source host, and
  make the source host abort migration. Is there a good mechanism
  for that?
* Make the destination host abort migration. I don't know if
  there's a safe mechanism for that.



While we figure that out, I will submit v2 without patches 3/4
and 4/4, because patch 2/2 (allowing migration if tsc-freq is
explicitly set) is simple and useful. After that, we can add:

* The mechanism to query the host TSC frequency (see below)
* The mechanism you asked for, to allow migration without
  explicit TSC frequency if we know the destination host supports
  TSC scaling or has a matching TSC frequency (more complex, and
  maybe unnecessary if we implement the previous item)


> > 
> > > 
> > > > Maybe your use case just needs a explicit "invtsc-migration=on"
> > > > command-line flag without a mechanism to abort migration on
> > > > mismatch? I can't tell.
> > > 
> > > Again, there is no special case.
> > > 
> > > > Note that even if we follow your suggestion and implement an
> > > > alternative version of patch 4/4 to cover your use case, I will
> > > > strongly recommend libvirt developers to support configuring TSC
> > > > frequency if they want to support invtsc + migration without
> > > > surprising/unpredictable restrictions on migratability.
> > > 
> > > Well, alright. If you make the TSC frequency of the host
> > > available to mgmt software as you describe, and write the steps mgmt
> > > software should take, i'm good.
> > 
> > I plan to. The problem is that the mechanism to query the host
> > frequency may be unavailable in the first version.
> 
> Well just export KVM_GET_TSC_KHZ in a QMP command right? Its pretty
> easy.

I plan to expose it as part of query-cpu-model-expansion (work in
progress, right now) when querying the "host" CPU model.

> 
> Let me know if you need any help coding or testing.

Thanks!

-- 
Eduardo

[Qemu-devel] [PATCH] Add DOS support for RTL8139

[Gerhard Wiesinger]

Signed-off-by: Gerhard Wiesinger 
---
 hw/net/rtl8139.c | 288 
++-

 1 file changed, 264 insertions(+), 24 deletions(-)

diff --git a/hw/net/rtl8139.c b/hw/net/rtl8139.c
index f05e59c..5241fea 100644
--- a/hw/net/rtl8139.c
+++ b/hw/net/rtl8139.c
@@ -48,6 +48,17 @@
  *  2011-Mar-22  Benjamin Poirier:  Implemented VLAN offloading
  */
 +/*
+ * Testcases and successful regression tests:
+ * 1.) DOS RSET8139.EXE: EEPROM Test successful
+ * 2.) DOS RSET8139.EXE: Local loopback Test (Run Diagnostics On Board)
+ * 3.) DOS RSET8139.EXE: Remote loopback Test as Initiator (Run 
Diagnostics On Network)
+ * 4.) DOS RSET8139.EXE: Remote loopback Test as Responder (Run 
Diagnostics On Network)

+ * 5.) DOS driver: Loads and works
+ * 6.) Linux tests
+ * 7.) Windows tests
+ */
+
 /* For crc32 */
 #include "qemu/osdep.h"
 #include 
@@ -130,6 +141,7 @@ enum RTL8139_registers {
 NWayExpansion = 0x6A,
 /* Undocumented registers, but required for proper operation. */
 FIFOTMS = 0x70,/* FIFO Control and test. */
+RX_ER = 0x72,   /* RX_ER Counter */
 CSCR = 0x74,/* Chip Status and Configuration Register. */
 PARA78 = 0x78,
 PARA7c = 0x7c,/* Magic transceiver parameter register. */
@@ -472,6 +484,8 @@ typedef struct RTL8139State {
 uint16_t NWayLPAR;
 uint16_t NWayExpansion;
 +uint16_t Fifo_TMS;
+
 uint16_t CpCmd;
 uint8_t  TxThresh;
 @@ -757,15 +771,27 @@ static void rtl8139_write_buffer(RTL8139State 
*s, const void *buf, int size)

  if (size > wrapped)
 {
+DPRINTF(">>> rx packet pci dma write "
+"RxBuf=0x%x, RxBufAddr=0x%x, 
RxBuf+RxBufAddr=0x%x, "

+"buf=%p, size=%i, wrapped=%i, size-wrapped=%i\n",
+s->RxBuf, s->RxBufAddr, s->RxBuf + s->RxBufAddr,
+buf, size, wrapped, size - wrapped
+   );
 pci_dma_write(d, s->RxBuf + s->RxBufAddr,
-  buf, size-wrapped);
+  buf, size - wrapped);
 }
  /* reset buffer pointer */
 s->RxBufAddr = 0;
 +DPRINTF(">>> rx packet pci dma write "
+"RxBuf=0x%x, RxBufAddr=0x%x, RxBuf+RxBufAddr=0x%x, "
+"buf=%p, size=%i, wrapped=%i, size-wrapped=%i\n",
+s->RxBuf, s->RxBufAddr, s->RxBuf + s->RxBufAddr,
+buf, size, wrapped, size - wrapped
+   );
 pci_dma_write(d, s->RxBuf + s->RxBufAddr,
-  buf + (size-wrapped), wrapped);
+  buf + (size - wrapped), wrapped);
  s->RxBufAddr = wrapped;
 @@ -774,6 +800,13 @@ static void rtl8139_write_buffer(RTL8139State *s, 
const void *buf, int size)

 }
  /* non-wrapping path or overwrapping enabled */
+DPRINTF(">>> rx packet pci dma write "
+"RxBuf=0x%x, RxBufAddr=0x%x, RxBuf+RxBufAddr=0x%x, "
+"buf=%p, size=%i\n",
+s->RxBuf, s->RxBufAddr, s->RxBuf + s->RxBufAddr,
+buf, size
+   );
+
 pci_dma_write(d, s->RxBuf + s->RxBufAddr, buf, size);
  s->RxBufAddr += size;
@@ -1201,15 +1234,18 @@ static ssize_t rtl8139_receive(NetClientState 
*nc, const uint8_t *buf, size_t si

 static void rtl8139_reset_rxring(RTL8139State *s, uint32_t bufferSize)
 {
 s->RxBufferSize = bufferSize;
+/* Why not 0xFFF0? */
 s->RxBufPtr  = 0;
 s->RxBufAddr = 0;
 }
 -static void rtl8139_reset(DeviceState *d)
+static void rtl8139_reset_delegate(DeviceState *d, int hard_reset)
 {
 RTL8139State *s = RTL8139(d);
 int i;
 +DPRINTF("rtl8139_reset_delegate, hard_reset=%i\n", hard_reset);
+
 /* restore MAC address */
 memcpy(s->phys, s->conf.macaddr.a, 6);
 qemu_format_nic_info_str(qemu_get_queue(s->nic), s->phys);
@@ -1233,7 +1269,19 @@ static void rtl8139_reset(DeviceState *d)
 s->RxRingAddrLO = 0;
 s->RxRingAddrHI = 0;
 -s->RxBuf = 0;
+/*
+ * DOS driver sets the RxBuf and then resets again.
+ * Afterwards RxBuf is not set anymore. Looks like real hardware
+ * also doesn't reset RxBuf on reset.
+ * When set to 0 DOS OS crashed because of adress 0 is overwritten ...
+ *
+ * On the other hand this must be done on a hardware triggered
+ * reset (a DMA enabled receiver might overwrite some areas!).
+ */
+
+if (hard_reset) {
+s->RxBuf = 0;
+}
  rtl8139_reset_rxring(s, 8192);
 @@ -1264,7 +1312,8 @@ static void rtl8139_reset(DeviceState *d)
  //s->BasicModeCtrl = 0x3100; // 100Mbps, full duplex, autonegotiation
 //s->BasicModeCtrl = 0x2100; // 100Mbps, full duplex
-s->BasicModeCtrl = 0x1000; // autonegotiation
+//s->BasicModeCtrl = 0x1000; // autonegotiation
+s->BasicModeCtrl = 0x3100; // 100Mbps, full duplex, autonegotiation
  

[Qemu-devel] [PATCH v2] m68k: QOMify the MCF Fast Ethernet Controller device

[Thomas Huth]

When running qemu-system-m68k with the "-net" parameter (for example
simply "-net nic -net user"), there is currently a confusing warning
message saying:

 Warning: requested NIC (anonymous, model mcf_fec) was not created
 (not supported by this machine?)

This seems to happen because the MCF NIC has never been adapted to
the currently expected QEMU device behavior. Thus let's QOMify the
NIC now to get rid of the warning message.

Signed-off-by: Thomas Huth 
---
 v2:
 - Add the mcf_fec.h header file for the shared #defines
 - Use qemu_check_nic_model() to verify the NIC model

 hw/m68k/mcf5208.c | 25 -
 hw/net/mcf_fec.c  | 71 +++
 include/hw/m68k/mcf.h |  4 ---
 include/hw/m68k/mcf_fec.h | 13 +
 4 files changed, 90 insertions(+), 23 deletions(-)
 create mode 100644 include/hw/m68k/mcf_fec.h

diff --git a/hw/m68k/mcf5208.c b/hw/m68k/mcf5208.c
index 3438314..bad1d33 100644
--- a/hw/m68k/mcf5208.c
+++ b/hw/m68k/mcf5208.c
@@ -11,6 +11,7 @@
 #include "cpu.h"
 #include "hw/hw.h"
 #include "hw/m68k/mcf.h"
+#include "hw/m68k/mcf_fec.h"
 #include "qemu/timer.h"
 #include "hw/ptimer.h"
 #include "sysemu/sysemu.h"
@@ -18,6 +19,7 @@
 #include "net/net.h"
 #include "hw/boards.h"
 #include "hw/loader.h"
+#include "hw/sysbus.h"
 #include "elf.h"
 #include "exec/address-spaces.h"
 
@@ -192,6 +194,26 @@ static void mcf5208_sys_init(MemoryRegion *address_space, 
qemu_irq *pic)
 }
 }
 
+static void mcf_fec_init(MemoryRegion *sysmem, NICInfo *nd, hwaddr base,
+ qemu_irq *irqs)
+{
+DeviceState *dev;
+SysBusDevice *s;
+int i;
+
+qemu_check_nic_model(nd, TYPE_MCF_FEC_NET);
+dev = qdev_create(NULL, TYPE_MCF_FEC_NET);
+qdev_set_nic_properties(dev, nd);
+qdev_init_nofail(dev);
+
+s = SYS_BUS_DEVICE(dev);
+for (i = 0; i < FEC_NUM_IRQ; i++) {
+sysbus_connect_irq(s, i, irqs[i]);
+}
+
+memory_region_add_subregion(sysmem, base, sysbus_mmio_get_region(s, 0));
+}
+
 static void mcf5208evb_init(MachineState *machine)
 {
 ram_addr_t ram_size = machine->ram_size;
@@ -243,9 +265,10 @@ static void mcf5208evb_init(MachineState *machine)
 fprintf(stderr, "Too many NICs\n");
 exit(1);
 }
-if (nd_table[0].used)
+if (nd_table[0].used) {
 mcf_fec_init(address_space_mem, _table[0],
  0xfc03, pic + 36);
+}
 
 /*  0xfc00 SCM.  */
 /*  0xfc004000 XBS.  */
diff --git a/hw/net/mcf_fec.c b/hw/net/mcf_fec.c
index 4025eb3..a3eca7e 100644
--- a/hw/net/mcf_fec.c
+++ b/hw/net/mcf_fec.c
@@ -9,7 +9,9 @@
 #include "hw/hw.h"
 #include "net/net.h"
 #include "hw/m68k/mcf.h"
+#include "hw/m68k/mcf_fec.h"
 #include "hw/net/mii.h"
+#include "hw/sysbus.h"
 /* For crc32 */
 #include 
 #include "exec/address-spaces.h"
@@ -27,9 +29,10 @@ do { printf("mcf_fec: " fmt , ## __VA_ARGS__); } while (0)
 #define FEC_MAX_FRAME_SIZE 2032
 
 typedef struct {
-MemoryRegion *sysmem;
+SysBusDevice parent_obj;
+
 MemoryRegion iomem;
-qemu_irq *irq;
+qemu_irq irq[FEC_NUM_IRQ];
 NICState *nic;
 NICConf conf;
 uint32_t irq_state;
@@ -68,7 +71,6 @@ typedef struct {
 #define FEC_RESET   1
 
 /* Map interrupt flags onto IRQ lines.  */
-#define FEC_NUM_IRQ 13
 static const uint32_t mcf_fec_irq_map[FEC_NUM_IRQ] = {
 FEC_INT_TXF,
 FEC_INT_TXB,
@@ -208,8 +210,10 @@ static void mcf_fec_enable_rx(mcf_fec_state *s)
 }
 }
 
-static void mcf_fec_reset(mcf_fec_state *s)
+static void mcf_fec_reset(DeviceState *dev)
 {
+mcf_fec_state *s = MCF_FEC_NET(dev);
+
 s->eir = 0;
 s->eimr = 0;
 s->rx_enabled = 0;
@@ -330,7 +334,7 @@ static void mcf_fec_write(void *opaque, hwaddr addr,
 s->ecr = value;
 if (value & FEC_RESET) {
 DPRINTF("Reset\n");
-mcf_fec_reset(s);
+mcf_fec_reset(opaque);
 }
 if ((s->ecr & FEC_EN) == 0) {
 s->rx_enabled = 0;
@@ -513,24 +517,55 @@ static NetClientInfo net_mcf_fec_info = {
 .receive = mcf_fec_receive,
 };
 
-void mcf_fec_init(MemoryRegion *sysmem, NICInfo *nd,
-  hwaddr base, qemu_irq *irq)
+static void mcf_fec_realize(DeviceState *dev, Error **errp)
 {
-mcf_fec_state *s;
+mcf_fec_state *s = MCF_FEC_NET(dev);
+
+s->nic = qemu_new_nic(_mcf_fec_info, >conf,
+  object_get_typename(OBJECT(dev)), dev->id, s);
+qemu_format_nic_info_str(qemu_get_queue(s->nic), s->conf.macaddr.a);
+}
 
-qemu_check_nic_model(nd, "mcf_fec");
+static void mcf_fec_instance_init(Object *obj)
+{
+SysBusDevice *sbd = SYS_BUS_DEVICE(obj);
+mcf_fec_state *s = MCF_FEC_NET(obj);
+int i;
+
+memory_region_init_io(>iomem, obj, _fec_ops, s, "fec", 0x400);
+sysbus_init_mmio(sbd, >iomem);
+for (i = 0; i < FEC_NUM_IRQ; i++) {
+sysbus_init_irq(sbd, >irq[i]);
+}
+}
 
-s = (mcf_fec_state *)g_malloc0(sizeof(mcf_fec_state));
- 

[Qemu-devel] [Bug 1654826] Re: Holding key down using input-linux freezes guest

[mutedbytes]

Thought I might add:

The qemu command line option equivalents for mouse and keyboard:

-object 
input-linux,id=kbd,evdev=/dev/input/by-path/platform-i8042-serio-0-event-kbd,repeat=on,grab_all=on
 \
-object 
input-linux,id=ms1,evdev=/dev/input/by-id/usb-ROCCAT_ROCCAT_Kone_Pure-event-mouse

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

Title:
  Holding key down using input-linux freezes guest

Status in QEMU:
  New

Bug description:
  Qemu release version 2.8.0
  KVM, kernel 4.9.1

  When using the -object input-linux capability in qemu for passthrough
  of input/evdev devices, I found that when a key is held for a few
  seconds or more (such as ctrl key), the guest system freezes until the
  key is released. In some cases, mouse control is also lost following
  one of these "freezes". I also noticed that one of the four cpu cores
  I have the guest pinned to ramps to 100% during these freezes.

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

[Qemu-devel] [Bug 1654826] [NEW] Holding key down using input-linux freezes guest

[mutedbytes]

Public bug reported:

Qemu release version 2.8.0
KVM, kernel 4.9.1

When using the -object input-linux capability in qemu for passthrough of
input/evdev devices, I found that when a key is held for a few seconds
or more (such as ctrl key), the guest system freezes until the key is
released. In some cases, mouse control is also lost following one of
these "freezes". I also noticed that one of the four cpu cores I have
the guest pinned to ramps to 100% during these freezes.

** Affects: qemu
 Importance: Undecided
 Status: New

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

Title:
  Holding key down using input-linux freezes guest

Status in QEMU:
  New

Bug description:
  Qemu release version 2.8.0
  KVM, kernel 4.9.1

  When using the -object input-linux capability in qemu for passthrough
  of input/evdev devices, I found that when a key is held for a few
  seconds or more (such as ctrl key), the guest system freezes until the
  key is released. In some cases, mouse control is also lost following
  one of these "freezes". I also noticed that one of the four cpu cores
  I have the guest pinned to ramps to 100% during these freezes.

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

[Qemu-devel] [Bug 888016] Re: RHEL 6.1 guest fails to boot with vhost

[Thomas Huth]

Can you still reproduce this problem with the latest version of QEMU
from http://qemu-project.org/Download and recent host and guest Linux
kernels?

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

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

Title:
  RHEL 6.1 guest fails to boot with vhost

Status in QEMU:
  Incomplete

Bug description:
  Tried to boot 6.1 guest on hs22 blade with/without  vhost enabled.

  With vhost enabled,  guest aborted with core dump.

  installed guest with autotest.
  Command : 
  /usr/local/bin/qemu-system-x86_64 -name 'vm1' -nodefaults -vga std -monitor 
unix:'/tmp/monitor-humanmonitor1-2008-193209-fc6O',server,nowait -serial 
unix:'/tmp/serial-2008-193209-fc6O',server,nowait -drive 
file='/home/pradeep/autotest/client/tests/kvm/images/rhel6.1-64.qed',index=0,if=virtio,cache=none
 -device virtio-net-pci,netdev=idQhUaOc,mac='9a:b7:ea:c9:0e:0d',id='idVR6XQz' 
-netdev tap,id=idQhUaOc,vhost=on,script=/home/pradeep/qemu-ifup-latest -m 1024 
-smp 8 -vnc :0 -monitor stdio
  QEMU 0.15.91 monitor - type 'help' for more information
  (qemu) Aborted (core dumped)

  
  host:

  2.6.32-214
  m/c: hs22
  vhost modules are loaded.

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

Re: [Qemu-devel] [PATCH] m68k: QOMify the MCF Fast Ethernet Controller device

[Thomas Huth]

On 06.01.2017 10:58, Thomas Huth wrote:
> When running qemu-system-m68k with the "-net" parameter (for example
> simply "-net nic -net user"), there is currently a confusing warning
> message saying:
> 
>  Warning: requested NIC (anonymous, model mcf_fec) was not created
>  (not supported by this machine?)
> 
> This seems to happen because the MCF NIC has never been adapted to
> the currently expected QEMU device behavior. Thus let's QOMify the
> NIC now to get rid of the warning message.
> 
> Signed-off-by: Thomas Huth 
> ---
>  hw/m68k/mcf5208.c | 20 ++
>  hw/net/mcf_fec.c  | 75 
> ++-
>  include/hw/m68k/mcf.h |  4 ---
>  3 files changed, 77 insertions(+), 22 deletions(-)
> 
> diff --git a/hw/m68k/mcf5208.c b/hw/m68k/mcf5208.c
> index 3438314..f9e1adb 100644
> --- a/hw/m68k/mcf5208.c
> +++ b/hw/m68k/mcf5208.c
> @@ -18,6 +18,7 @@
>  #include "net/net.h"
>  #include "hw/boards.h"
>  #include "hw/loader.h"
> +#include "hw/sysbus.h"
>  #include "elf.h"
>  #include "exec/address-spaces.h"
>  
> @@ -192,6 +193,25 @@ static void mcf5208_sys_init(MemoryRegion 
> *address_space, qemu_irq *pic)
>  }
>  }
>  
> +static void mcf_fec_init(MemoryRegion *sysmem, NICInfo *nd, hwaddr base,
> + qemu_irq *irqs)
> +{
> +DeviceState *dev;
> +SysBusDevice *s;
> +int i;
> +
> +dev = qdev_create(NULL, "mcf-fec");

I just read on http://wiki.qemu.org/Documentation/QOMConventions:

 "DO use TYPE_FOO constants, defined in a header if used in other parts
  of code"

... so I guess I should rather declare the TYPE_MCF_FEC_NET in a header
file instead. I'll send a v2 of this patch...

 Thomas

[Qemu-devel] [Bug 884401] Re: PCI Passthrough for Digium TCE400P Codec Card Not working

[Thomas Huth]

Oh, I meant "comment from Alex", not "comment to Alex", sorry!

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

Title:
  PCI Passthrough for Digium TCE400P Codec Card Not working

Status in QEMU:
  Fix Released

Bug description:
  trying to use a Digium TCE400P Codec card on a Virtual instance using
  the following information:

  lspci 

  02:08.0 Ethernet controller: Digium, Inc. Wildcard TCE400P transcoder
  base card (rev 11)

  lspci -n 

  02:08.0 0200: d161:8004 (rev 11)

  virsh nodedev-list | grep pci

  pci__02_08_0

  printf %x 02
  2

  printf %x 08
  8

  printf %x 0
  0

  bus='0x02'
  slot='0x08'
  function='0x0'

  # virsh edit vmanager
  



  

  I have SELINUX disabled at this time.

  virsh start vmanager I get the following error message:

  [root@twins qemu]# virsh start vmanager
  error: Failed to start domain vmanager
  error: internal error Process exited while reading console log output: char 
device redirected to /dev/pts/2
  Unable to assign device: PCI region 1 at address 0xdf1fe000 has size 0x400,  
which is not a multiple of 4K
  qemu-kvm: -device 
pci-assign,host=02:08.0,id=hostdev0,configfd=23,bus=pci.0,addr=0x6: Device 
'pci-assign' could not be initialized


  Version Numbers:

  [root@twins qemu]# yum list | grep qemu
  gpxe-roms-qemu.noarch  0.9.7-6.3.el6_0.1
@updates
  qemu-img.x86_642:0.12.1.2-2.113.el6_0.8 
@updates
  qemu-kvm.x86_642:0.12.1.2-2.113.el6_0.8 
@updates
  qemu-kvm-tools.x86_64  2:0.12.1.2-2.113.el6_0.8 
updates

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

[Qemu-devel] [Bug 884401] Re: PCI Passthrough for Digium TCE400P Codec Card Not working

[Thomas Huth]

According to the comment to Alex, this should have been fixed in newer
versions, so setting status to "Fix Released" now.

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

Title:
  PCI Passthrough for Digium TCE400P Codec Card Not working

Status in QEMU:
  Fix Released

Bug description:
  trying to use a Digium TCE400P Codec card on a Virtual instance using
  the following information:

  lspci 

  02:08.0 Ethernet controller: Digium, Inc. Wildcard TCE400P transcoder
  base card (rev 11)

  lspci -n 

  02:08.0 0200: d161:8004 (rev 11)

  virsh nodedev-list | grep pci

  pci__02_08_0

  printf %x 02
  2

  printf %x 08
  8

  printf %x 0
  0

  bus='0x02'
  slot='0x08'
  function='0x0'

  # virsh edit vmanager
  



  

  I have SELINUX disabled at this time.

  virsh start vmanager I get the following error message:

  [root@twins qemu]# virsh start vmanager
  error: Failed to start domain vmanager
  error: internal error Process exited while reading console log output: char 
device redirected to /dev/pts/2
  Unable to assign device: PCI region 1 at address 0xdf1fe000 has size 0x400,  
which is not a multiple of 4K
  qemu-kvm: -device 
pci-assign,host=02:08.0,id=hostdev0,configfd=23,bus=pci.0,addr=0x6: Device 
'pci-assign' could not be initialized


  Version Numbers:

  [root@twins qemu]# yum list | grep qemu
  gpxe-roms-qemu.noarch  0.9.7-6.3.el6_0.1
@updates
  qemu-img.x86_642:0.12.1.2-2.113.el6_0.8 
@updates
  qemu-kvm.x86_642:0.12.1.2-2.113.el6_0.8 
@updates
  qemu-kvm-tools.x86_64  2:0.12.1.2-2.113.el6_0.8 
updates

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

[Qemu-devel] [Bug 887883] Re: Coverity scan revealed defects

[Thomas Huth]

AFAIK a lot of issues reported by coverity have been addressed in the
recent versions of QEMU ... is there still anything left here that needs
special attention?

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

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

Title:
  Coverity scan revealed defects

Status in QEMU:
  Incomplete

Bug description:
  Coverity scan detected some issues such as  RESOURCE_LEAK and
  REVERSE_INULL etc on qemu-1.0rc1:

  Analysis summary report:
  
  Files analyzed : 830
  Total LoC input to cov-analyze : 576549
  Functions analyzed : 20721
  Paths analyzed : 858376
  New defects found  : 428 Total
 2 ARRAY_VS_SINGLETON
 9 CHECKED_RETURN
19 CONSTANT_EXPRESSION_RESULT
60 DEADCODE
43 FORWARD_NULL
14 INFINITE_LOOP
36 MISSING_BREAK
 3 MISSING_LOCK
47 NEGATIVE_RETURNS
 1 NO_EFFECT
11 NULL_RETURNS
51 OVERRUN_STATIC
 1 RESOURCE_LEAK
79 REVERSE_INULL
20 SIGN_EXTENSION
 7 SIZEOF_MISMATCH
15 UNINIT
 5 UNREACHABLE
 2 UNUSED_VALUE
 3 USE_AFTER_FREE

  For details, please see attachment.

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

Re: [Qemu-devel] [PATCH] net: optimize checksum computation

[Dmitry Fleytman]

> On 6 Jan 2017, at 10:08 AM, Ladi Prosek  wrote:
> 
> Very simple loop optimization with a significant performance impact.
> 
> Microbenchmark results, modern x86-64:
> 
> buffer size | speed up
> +-
> 1500| 1.7x
> 64  | 1.5x
> 8   | 1.15x
> 
> Microbenchmark results, POWER7:
> 
> buffer size | speed up
> +-
> 1500| 5x
> 64  | 3.3x
> 8   | 1.13x
> 
> There is a lot of room for further improvement at the expense of
> code complexity - aligned multibyte reads, LE/BE considerations,
> architecture-specific optimizations, etc. This patch still keeps
> things simple and readable.

Reviewed-by: Dmitry Fleytman 

> 
> Signed-off-by: Ladi Prosek 
> ---
> net/checksum.c | 21 +
> 1 file changed, 13 insertions(+), 8 deletions(-)
> 
> diff --git a/net/checksum.c b/net/checksum.c
> index 23323b0..4da72a6 100644
> --- a/net/checksum.c
> +++ b/net/checksum.c
> @@ -22,17 +22,22 @@
> 
> uint32_t net_checksum_add_cont(int len, uint8_t *buf, int seq)
> {
> -uint32_t sum = 0;
> +uint32_t sum1 = 0, sum2 = 0;
> int i;
> 
> -for (i = seq; i < seq + len; i++) {
> -if (i & 1) {
> -sum += (uint32_t)buf[i - seq];
> -} else {
> -sum += (uint32_t)buf[i - seq] << 8;
> -}
> +for (i = 0; i < len - 1; i += 2) {
> +sum1 += (uint32_t)buf[i];
> +sum2 += (uint32_t)buf[i + 1];
> +}
> +if (i < len) {
> +sum1 += (uint32_t)buf[i];
> +}
> +
> +if (seq & 1) {
> +return sum1 + (sum2 << 8);
> +} else {
> +return sum2 + (sum1 << 8);
> }
> -return sum;
> }
> 
> uint16_t net_checksum_finish(uint32_t sum)
> -- 
> 2.7.4
> 

[Qemu-devel] [Bug 839790] Re: -usbdevice tablet broken on win XP client

[Thomas Huth]

Can you reproduce this problem with the latest version of QEMU from http
://qemu-project.org/Download ?

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

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

Title:
  -usbdevice tablet broken on win XP client

Status in QEMU:
  Incomplete

Bug description:
  I'm using the qemu-kvm package from arch (not the qemu package), and
  on prior versions of qemu-kvm I was able to use -usbdevide tablet
  without problems.  The absolute mouse position is great...  With
  current version of qemu-kvm, when I use -usbdevice tablet, I got no
  mouse at all.  As my client is windows XP, it's not good to try do
  anything without mouse, :-)

  I searched in current bugs, and didn't find any bug which subject
  included "tablet", so I'm submitting this bug...

  Current qemu-kvm package in arch I'm using is:

  % pacman -Ss qemu-kvm
  extra/qemu-kvm 0.15.0-2 [installed]
  Latest KVM QEMU is a generic and open source processor emulator which 
achieves a good emulation speed by using dynamic translation.

  Please notice I do not get any error, just the mouse broken...

  thanks,

  Javier.

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

[Qemu-devel] [Bug 864490] Re: Windows 2008 x64 (SBS Server) freezes randomly when using more than 1 CPU core

[Thomas Huth]

Since nobody replied here within the last years: I think you should
rather report problems with XEN / Proxmox to the XEN or Proxmox
bugtracker instead.

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

Title:
  Windows 2008 x64 (SBS Server) freezes randomly when using more than 1
  CPU core

Status in QEMU:
  Invalid

Bug description:
  This issue has been giving headache to us since a long time.
  Difficult to reproduce as it happens randomly.
  We had this issue when we ran Windows 2008 x64 or Windows SBS Server guests 
in either XEN 3.3 or Proxmox environments.
  When only one CPU core is assigned to the guest, everything is fine. If 2 or 
more cores are assigned, the guest stops responding after several hours - and 
in the host machine one of the cores is using 100%. The only thing that helps 
is resetting the guest.

  I am ready to provide logs/crashdumps if needed, because we want to
  help resolve this issue. I saw some posts on the web of people having
  the same problems - for some of the workaround was to fix some BIOS
  settings, but we did not have success with those (e.g. disabling C1E
  Support and Intel C-State )

  Server is running on Intel® Core™ i7-920 Quad-Core, 24 Gig RAM.

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

[Qemu-devel] [PATCH v3 2/3] block: m25p80: Introduce die erase command

[Marcin Krzeminski]

Modern big flash nor devices consist from more than one die.
Some of them do not support chip erase and instead have die
erase command that can erase one die only. This commit adds
possibility to define number of dies in the chip and adds
support for die erase command. Nor flash model is not strict
thus option to disable chip eras was not added.

Signed-off-by: Marcin Krzeminski 
---
 hw/block/m25p80.c | 41 -
 1 file changed, 40 insertions(+), 1 deletion(-)

diff --git a/hw/block/m25p80.c b/hw/block/m25p80.c
index 6dff81b..a9b025b 100644
--- a/hw/block/m25p80.c
+++ b/hw/block/m25p80.c
@@ -73,6 +73,12 @@ typedef struct FlashPartInfo {
 uint32_t n_sectors;
 uint32_t page_size;
 uint16_t flags;
+/*
+ * Big sized spi nor are often stacked devices, thus sometime
+ * replace chip erase with die erase.
+ * This field inform how many die is in the chip.
+ */
+uint8_t die_cnt;
 } FlashPartInfo;
 
 /* adapted from linux */
@@ -90,7 +96,8 @@ typedef struct FlashPartInfo {
 .sector_size = (_sector_size),\
 .n_sectors = (_n_sectors),\
 .page_size = 256,\
-.flags = (_flags),
+.flags = (_flags),\
+.die_cnt = 0
 
 #define INFO6(_part_name, _jedec_id, _ext_id, _sector_size, _n_sectors, 
_flags)\
 .part_name = _part_name,\
@@ -107,6 +114,24 @@ typedef struct FlashPartInfo {
 .n_sectors = (_n_sectors),\
 .page_size = 256,\
 .flags = (_flags),\
+.die_cnt = 0
+
+#define INFO_STACKED(_part_name, _jedec_id, _ext_id, _sector_size, _n_sectors,\
+_flags, _die_cnt)\
+.part_name = _part_name,\
+.id = {\
+((_jedec_id) >> 16) & 0xff,\
+((_jedec_id) >> 8) & 0xff,\
+(_jedec_id) & 0xff,\
+((_ext_id) >> 8) & 0xff,\
+(_ext_id) & 0xff,\
+  },\
+.id_len = (!(_jedec_id) ? 0 : (3 + ((_ext_id) ? 2 : 0))),\
+.sector_size = (_sector_size),\
+.n_sectors = (_n_sectors),\
+.page_size = 256,\
+.flags = (_flags),\
+.die_cnt = _die_cnt
 
 #define JEDEC_NUMONYX 0x20
 #define JEDEC_WINBOND 0xEF
@@ -359,6 +384,8 @@ typedef enum {
 
 REVCR = 0x65,
 WEVCR = 0x61,
+
+DIE_ERASE = 0xC4,
 } FlashCMD;
 
 typedef enum {
@@ -514,6 +541,16 @@ static void flash_erase(Flash *s, int offset, FlashCMD cmd)
 case BULK_ERASE:
 len = s->size;
 break;
+case DIE_ERASE:
+if (s->pi->die_cnt) {
+len = s->size / s->pi->die_cnt;
+offset = offset & (~(len - 1));
+} else {
+qemu_log_mask(LOG_GUEST_ERROR, "M25P80: die erase is not supported"
+  " by device\n");
+return;
+}
+break;
 default:
 abort();
 }
@@ -635,6 +672,7 @@ static void complete_collecting_data(Flash *s)
 case ERASE4_32K:
 case ERASE_SECTOR:
 case ERASE4_SECTOR:
+case DIE_ERASE:
 flash_erase(s, s->cur_addr, s->cmd_in_progress);
 break;
 case WRSR:
@@ -881,6 +919,7 @@ static void decode_new_cmd(Flash *s, uint32_t value)
 case PP:
 case PP4:
 case PP4_4:
+case DIE_ERASE:
 s->needed_bytes = get_addr_length(s);
 s->pos = 0;
 s->len = 0;
-- 
2.9.3

[Qemu-devel] [PATCH v3 1/3] block: m25p80: Add Quad Page Program 4byte

[Marcin Krzeminski]

Some flash chips have additional page program opcode that
takes only 4 byte address. This commit adds support
for such command in Qemu.

Signed-off-by: Marcin Krzeminski 
Reviewed-by: Edgar E. Iglesias 
---
 hw/block/m25p80.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/hw/block/m25p80.c b/hw/block/m25p80.c
index e3c1166..6dff81b 100644
--- a/hw/block/m25p80.c
+++ b/hw/block/m25p80.c
@@ -326,6 +326,7 @@ typedef enum {
 PP4_4 = 0x3e,
 DPP = 0xa2,
 QPP = 0x32,
+QPP_4 = 0x34,
 
 ERASE_4K = 0x20,
 ERASE4_4K = 0x21,
@@ -574,6 +575,7 @@ static inline int get_addr_length(Flash *s)
switch (s->cmd_in_progress) {
case PP4:
case PP4_4:
+   case QPP_4:
case READ4:
case QIOR4:
case ERASE4_4K:
@@ -607,6 +609,7 @@ static void complete_collecting_data(Flash *s)
 switch (s->cmd_in_progress) {
 case DPP:
 case QPP:
+case QPP_4:
 case PP:
 case PP4:
 case PP4_4:
@@ -874,6 +877,7 @@ static void decode_new_cmd(Flash *s, uint32_t value)
 case READ4:
 case DPP:
 case QPP:
+case QPP_4:
 case PP:
 case PP4:
 case PP4_4:
-- 
2.9.3

[Qemu-devel] [PATCH v3 0/3] block: m25p80: Improve mt25qu01g chip model

[Marcin Krzeminski]

This series introduce some improvememnt targeting mt25qu01g and adds
support for n25q00 device.

v3:
* Removed debug printf
v2:
* Rework die erase command functionality. Since the number of dies
is constant per chip, new field to flash description structure has
been added (instead of dynamic code from v1).
* Add definition for n25q00.

Marcin Krzeminski (3):
  block: m25p80: Add Quad Page Program 4byte
  block: m25p80: Introduce die erase command
  block: m25p80: Improve 1GiB Micron flash definition

 hw/block/m25p80.c | 51 ---
 1 file changed, 48 insertions(+), 3 deletions(-)

-- 
2.9.3

[Qemu-devel] [PATCH v3 3/3] block: m25p80: Improve 1GiB Micron flash definition

[Marcin Krzeminski]

n25q00 and mt25q01 devices share the same JEDEC ID. The difference
between those two devices is number of dies and one bit in extended
JEDEC bytes. This commit adds proper entry for both devices by
introduction the number of dies and and new 25q00 entries.

Signed-off-by: Marcin Krzeminski 
---
 hw/block/m25p80.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/hw/block/m25p80.c b/hw/block/m25p80.c
index a9b025b..fb5cef3 100644
--- a/hw/block/m25p80.c
+++ b/hw/block/m25p80.c
@@ -242,8 +242,10 @@ static const FlashPartInfo known_devices[] = {
 { INFO("n25q128", 0x20ba18,  0,  64 << 10, 256, 0) },
 { INFO("n25q256a",0x20ba19,  0,  64 << 10, 512, ER_4K) },
 { INFO("n25q512a",0x20ba20,  0,  64 << 10, 1024, ER_4K) },
-{ INFO("mt25ql01g",   0x20ba21,  0,  64 << 10, 2048, ER_4K) },
-{ INFO("mt25qu01g",   0x20bb21,  0,  64 << 10, 2048, ER_4K) },
+{ INFO_STACKED("n25q00",0x20ba21, 0x1000, 64 << 10, 2048, ER_4K, 4) },
+{ INFO_STACKED("n25q00a",   0x20bb21, 0x1000, 64 << 10, 2048, ER_4K, 4) },
+{ INFO_STACKED("mt25ql01g", 0x20ba21, 0x1040, 64 << 10, 2048, ER_4K, 2) },
+{ INFO_STACKED("mt25qu01g", 0x20bb21, 0x1040, 64 << 10, 2048, ER_4K, 2) },
 
 /* Spansion -- single (large) sector size only, at least
  * for the chips listed here (without boot sectors).
-- 
2.9.3

Re: [Qemu-devel] [RFC] pxb: Restrict to x86

[Marcel Apfelbaum]

On 01/06/2017 09:41 PM, Michael S. Tsirkin wrote:

On Fri, Jan 06, 2017 at 08:13:11AM +0200, Marcel Apfelbaum wrote:

On 01/06/2017 07:04 AM, David Gibson wrote:

The PCI Expander Bridge (PXB) device is essentially a hack to allow
different PCIe devices to be assigned to different NUMA nodes on x86.  Each
PXB is sort-of a separate PCI host bridge, except that its config space
is shared with the config space of the main PCI host bridge, rather than
being independent.



Hi David,


This is only necessary if the platform doesn't (easily) allow truly
independent PCI host bridges.  AFAIK that's just x86.



Indeed, it is possible to support independent PCI host bridges on x86 by
using a separate MMCONFIG space for each one and enable separate PCI domains.
We simply didn't need this until now, but maybe will be implemented it in the 
future.


In fact I would say that's the cleanest way to do this on q35.



Message received :)

Thanks,
Marcel



This patch makes it possible to configure PXB out of the build, and adjusts
the default configs so it's only included on x86 targets.





[...]