Re: [Qemu-devel] [PATCH 2/2] Explicitly print out default vnc option in use

[Markus Armbruster]

Robert Hu  writes:

> On Wed, 2016-06-08 at 16:22 +0200, Markus Armbruster wrote:
>> Robert Hu  writes:
>> 
>> > On Mon, 2016-06-06 at 09:28 +0200, Markus Armbruster wrote:
>> >> Robert Hu  writes:
>> >> 
>> >> > On Tue, 2016-05-31 at 13:17 +0200, Markus Armbruster wrote:
>> >> >> Robert Hu  writes:
>> >> >> 
>> >> >> > On Tue, 2016-05-31 at 09:51 +0200, Markus Armbruster wrote:
>> > [trim...]
>> >> > I don't see a './configure' option related to this '-vnc to' param. Is
>> >> > there any?
>> >> > '--help', you mean 'qemu-system_x86-64 --help'? or './configure --help'?
>> > [seems repeated contents, trim...]
>> >> > I don't see a './configure' option related to this '-vnc to' param. Is
>> >> > there any?
>> >> > '--help', you mean 'qemu-system_x86-64 --help'? or './configure --help'?
>> >> 
>> >> The former.
>> >> 
>> >> The modern way to select a display is -display.  The older -nographic,
>> >> -curses, -sdl are retained for backward compatibility.
>> >> 
>> >> Relevant parts of -help:
>> >> 
>> >> Display options:
>> >> -display sdl[,frame=on|off][,alt_grab=on|off][,ctrl_grab=on|off]
>> >> [,window_close=on|off]|curses|none|
>> >> gtk[,grab_on_hover=on|off]|
>> >> vnc=[,]
>> >> select display type
>> >> -nographic  disable graphical output and redirect serial I/Os to 
>> >> console
>> >> -curses use a curses/ncurses interface instead of SDL
>> >> [...]
>> >> -sdlenable SDL
>> >> [...]
>> >> -vnc displaystart a VNC server on display
>> >> 
>> >> Issues:
>> >> 
>> >> * Help for -display is broken: the mutually exclusive option arguments
>> >>   are concatenated.  -display curses and -display none are undocumented.
>> >>   It should look more like this:
>> >> 
>> >> -display sdl[,frame=on|off][,alt_grab=on|off][,ctrl_grab=on|off]
>> >> [,window_close=on|off]|curses|none|
>> >> -display gtk[,grab_on_hover=on|off]|
>> >> -display vnc=[,]
>> >> -display curses
>> >> -display none
>> >> select display type
>> >> 
>> >> * -display sdl,gl=on|off and -display gtk,gl=on|off are undocumented
>> >>(missed in commit 0b71a5d5c and 97edf3b).
>> >> 
>> >> * There is no help on the  in -display vnc=.
>> >> 
>> >> * There is no help on the default.  main() picks the default depending
>> >>   on configure options:
>> >> 
>> >> #if defined(CONFIG_GTK)
>> >> display_type = DT_GTK;
>> >> #elif defined(CONFIG_SDL)
>> >> display_type = DT_SDL;
>> >> #elif defined(CONFIG_COCOA)
>> >> display_type = DT_COCOA;
>> >> #elif defined(CONFIG_VNC)
>> >> vnc_parse("localhost:0,to=99,id=default", _abort);
>> >> show_vnc_port = 1;
>> >> #else
>> >> display_type = DT_NONE;
>> >> #endif
>> >> 
>> >>   Help should show the default this binary will pick.  This is what I
>> >>   meant by "Ideally, --help output would show the defaults for this
>> >>   build's configuration."
>> >> 
>> >> * Help should explain syntacic sugar:
>> >>   -curses is sugar for -display curses
>> >>   -sdl is sugar for -display sdl
>> >>   -vnc display is sugar for -display vnc=display
>> >> 
>> >>   -nographic is also sugar, but too complicated to explain; I'd leave it
>> >>   as is.
>> >> 
>> >> Non-issue
>> >> 
>> >> * Help shows options even when they're not compiled in.  That's okay,
>> >>   because trying to use them fails with an "FOO support is disabled"
>> >>   error message.
>> >> 
>> >> >> If we decide users need more information than the current "VNC server
>> >> >> running on" line, perhaps it should be included right in that line.
>> >> 
>> >> This would complement, but not replace better -help ouput.
>> >> 
>> >> If you would like to work on these issues, let us know.
>> >
>> > OK, if not in a hurry and assuming this is not a huge amount of work.
>> > I also need to look into the build arch so that completely understand
>> > your 'the default this binary will pick', till now I don't.
>> >
>> > Another concern is that I'm not a native English speaker, so those
>> > description words may not be that apt and concise.
>> 
>> Imperfect English can be addressed in review.  Can be inefficient when
>> most of the work is English rather than code.  But if you want to try
>> anyway, go right ahead regardless.
>
> Hi Markus,
>
> After did some part-time investigation, I'd like to confirm with you:
> this change you required seems also just qemu-options.hx involved, am I
> right?
> If so, I'd like to do that.

Yes, because commmand line option help is defined there.

Re: [Qemu-devel] [RFC PATCH V4 0/4] Introduce COLO-compare

[Jason Wang]

On 2016年06月20日 11:27, Zhang Chen wrote:



On 06/20/2016 11:03 AM, Jason Wang wrote:



On 2016年06月17日 10:25, Zhang Chen wrote:

Hi~ jason.

I tried a lot of ways to make it run in compare thread, but it not 
work.


Because that:
void g_main_context_push_thread_default (GMainContext *context);
Acquires context and sets it as the thread-default context for the 
current thread.


So, this function g_main_context_push_thread_default() just can set 
thread-default context,
not the global default context. and I can't find a function to set 
global default context in glib.
The qemu's QIOChannel uses g_source_attach(source, NULL); to attach 
GSource.

g_source_attach (GSource *source,
 GMainContext *context);

context
a GMainContext (if NULL, the default context will be used).

But he not say "the default context" is global default context or 
thread-default context.

So I read glib codes find that:
guint
g_source_attach (GSource *source,
 GMainContext *context)
{
.
if (!context)
context = g_main_context_default ();
.
}

g_main_context_default ()
Returns the global default main context.

So...I think we can't make qemu_chr_add_handlers() run in colo 
thread in this way.
Do you have any comments about that? 


How about (like I suggest previously) just use

g_souce_attach(x, g_main_context_get_thread_default());

in qemu's QIOChannel code?





I feel it seems can work, and will try it.
but I don't know how this change in qemu's QIOChannel code
will affect the other code. needs other people confirm it?


Yes, we need convince them. I believe we don't do this in the past is 
because there's no users.



If no affect and works good,I will send a independent patch
for this.



Right, if it works, please send a RFC and explain why it is needed.

Thanks



Thanks
Zhang Chen

[Qemu-devel] [Bug 1594239] [NEW] After adding more scsi disks for Aarch64 virtual machine, start the VM and got Qemu Error

[Kevin Zhao]

Public bug reported:

Description
===
Using virt-manager to create a VM in Aarch64, Ubuntu 16.04.
Add scsi disk to the VM. After add four or more scsi disks, start the VM and 
will got Qemu error.

Steps to reproduce
==
1.Use virt-manager to create a VM.
2.After the VM is started, add scsi disk to the VM. They will be allocated to 
"sdb,sdc,sdd." .
3.If we got a disk name > sdg, virt-manager will also assign a virtio-scsi 
controller for this disk.And the VM will be shutdown.
4.Start the VM, will see the error log.


Expected result
===
Start the vm smoothly.The added disks can work.

Actual result
=
Got the error:
starting domain: internal error: process exited while connecting to monitor: 
qemu-system-aarch64: /build/qemu-zxCwKP/qemu-2.5+dfsg/migration/savevm.c:620: 
vmstate_register_with_alias_id: Assertion `!se->compat || se->instance_id == 0' 
failed.
details=Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 90, in cb_wrapper
callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 126, in tmpcb
callback(*args, **kwargs)
  File "/usr/share/virt-manager/virtManager/libvirtobject.py", line 83, in newfn
ret = fn(self, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/domain.py", line 1402, in startup
self._backend.create()
  File "/usr/local/lib/python2.7/dist-packages/libvirt.py", line 1035, in create
if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
libvirtError: internal error: process exited while connecting to monitor: 
qemu-system-aarch64: /build/qemu-zxCwKP/qemu-2.5+dfsg/migration/savevm.c:620: 
vmstate_register_with_alias_id: Assertion `!se->compat || se->instance_id == 0' 
failed.


Environment
===
1. virt-manager version is 1.3.2

2. Which hypervisor did you use?
Libvirt+KVM
$ kvm --version
QEMU emulator version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.1), Copyright (c) 
2003-2008 Fabrice Bellard
$ libvirtd --version
libvirtd (libvirt) 1.3.1

3. Which storage type did you use?
   In the host file system,all in one physics machine.
stack@u202154:/opt/stack/nova$ df -hl
Filesystem Size Used Avail Use% Mounted on
udev 7.8G 0 7.8G 0% /dev
tmpfs 1.6G 61M 1.6G 4% /run
/dev/sda2 917G 41G 830G 5% /
tmpfs 7.9G 0 7.9G 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 7.9G 0 7.9G 0% /sys/fs/cgroup
/dev/sda1 511M 888K 511M 1% /boot/efi
cgmfs 100K 0 100K 0% /run/cgmanager/fs
tmpfs 1.6G 0 1.6G 0% /run/user/1002
tmpfs 1.6G 0 1.6G 0% /run/user/1000
tmpfs 1.6G 0 1.6G 0% /run/user/0

4. Environment information:
   Architecture : AARCH64
   OS: Ubuntu 16.04

The Qemu commmand of libvirt is :
2016-06-20 02:39:46.561+: starting up libvirt version: 1.3.1, package: 
1ubuntu10 (William Grant  Fri, 15 Apr 2016 12:08:21 +1000), 
qemu version: 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.1), hostname: u202154
LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin 
QEMU_AUDIO_DRV=none /usr/bin/kvm -name cent7 -S -machine virt,accel=kvm,usb=off 
-cpu host -drive 
file=/usr/share/edk2.git/aarch64/QEMU_EFI-pflash.raw,if=pflash,format=raw,unit=0,readonly=on
 -drive 
file=/var/lib/libvirt/qemu/nvram/cent7_VARS.fd,if=pflash,format=raw,unit=1 -m 
2048 -realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 -uuid 
d5462bb6-159e-4dbd-9266-bf8c07fa1695 -nographic -no-user-config -nodefaults 
-chardev 
socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-cent7/monitor.sock,server,nowait
 -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown 
-boot strict=on -device i82801b11-bridge,id=pci.1,bus=pcie.0,addr=0x1 -device 
pci-bridge,chassis_nr=2,id=pci.2,bus=pci.1,addr=0x1 -device 
virtio-scsi-device,id=scsi0 -device lsi,id=scsi1 -device lsi,id=scsi2 -device 
virtio-scsi-device,id=scsi3 -usb -drive 
file=/var/lib/libvirt/images/cent7-2.img,format=qcow2,if=none,id=drive-scsi0-0-0-0
 -device 
scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1
 -drive if=none,id=drive-scsi0-0-0-1,readonly=on -device 
scsi-cd,bus=scsi0.0,channel=0,scsi-id=0,lun=1,drive=drive-scsi0-0-0-1,id=scsi0-0-0-1
 -drive 
file=/var/lib/libvirt/images/cent7-10.img,format=qcow2,if=none,id=drive-scsi0-0-0-2
 -device 
scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=2,drive=drive-scsi0-0-0-2,id=scsi0-0-0-2
 -drive 
file=/var/lib/libvirt/images/cent7-11.img,format=qcow2,if=none,id=drive-scsi0-0-0-3
 -device 
scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=3,drive=drive-scsi0-0-0-3,id=scsi0-0-0-3
 -drive 
file=/var/lib/libvirt/images/cent7-13.img,format=qcow2,if=none,id=drive-scsi3-0-0-0
 -device 
scsi-hd,bus=scsi3.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi3-0-0-0,id=scsi3-0-0-0
 -netdev tap,fd=33,id=hostnet0,vhost=on,vhostfd=35 -device 
virtio-net-device,netdev=hostnet0,id=net0,mac=52:54:00:a1:6e:75 -serial pty 
-msg timestamp=on
Domain id=11 is tainted: host-cpu

Re: [Qemu-devel] [PATCH v3 0/2] Let PKGVERSION include the "git describe" output

[Changlong Xie]

For this patch, i think you forget to add qemu-version.h and/or 
qemu-version.h.tmp in .gitignore


changlox ~/w/qemu/qemu% gs
On branch master
Your branch is up-to-date with 'origin/master'.

Untracked files:
  (use "git add ..." to include in what will be committed)

qemu-version.h
qemu-version.h.tmp

nothing added to commit but untracked files present (use "git add" to track)


On 06/01/2016 05:44 PM, Fam Zheng wrote:

v3: Use the "2.6.50 (v2.6.0-603-g684a494)" format. [Laszlo]
 printf '-dirty' -> printf -- '-dirty'.

v2: Address Eric's comments:
 "echo -n" -> "printf".
 "-unclean" -> "-dirty".

Makefile happened to be in my working set because of the docker test work, so I
went ahead to try this nice feature last evening before going to bed. My
apologies if we have duplicated work.

Please review, especially please comment on the redundant version string:

$ qemu-img --version
qemu-img version 2.6.50-v2.6.0-603-g684a494, Copyright (c) 2004-2008 Fabrice 
Bellard


Fam Zheng (2):
   Makefile: Add a "FORCE" target
   Makefile: Derive "PKGVERSION" from "git describe" by default

  Makefile  | 24 ++--
  linux-user/main.c |  1 +
  qemu-img.c|  1 +
  qmp.c |  1 +
  scripts/create_config |  4 
  vl.c  |  1 +
  6 files changed, 26 insertions(+), 6 deletions(-)

Re: [Qemu-devel] [PATCH 1/2] hw/misc: Add a model for the ASPEED System Control Unit

[Andrew Jeffery]

On Fri, 2016-06-17 at 15:22 +0100, Peter Maydell wrote:
On 16 June 2016 at 08:48, Andrew Jeffery  wrote:


The SCU is a collection of chip-level control registers that manage the
various functions supported by the AST2400. Typically the bits control
interactions with clocks, external hardware or reset behaviour, and we
can largly take a hands-off approach to reads and writes.


Firmware makes heavy use of the state to determine how to boot, but the
reset values vary from SoC to SoC. qdev properties are exposed so that
the integrating SoC model can configure the appropriate reset values.


Signed-off-by: Andrew Jeffery 
Reviewed-by: Cédric Le Goater 
Reviewed-by: Joel Stanley 
---
+static Property aspeed_scu_properties[] = {
+DEFINE_PROP_ARRAY("reset", AspeedSCUState, num_resets, reset,
+  qdev_prop_uint32, uint32_t),
+DEFINE_PROP_END_OF_LIST(),
+};
+
+#define ASPEED_SCU_NR_REGS (0x1A8 >> 2)
This seems like a very unwieldy way of specifying the reset values
for this device. Are they really all fully configurable in the
hardware? It seems unlikely. I'd much rather see something that
looks more like what you might plausibly be configuring when wiring
up the SoC, which might be some version/revision numbers and/or
some particular tweakable parameters.

Right. I left out some context which may clear things up: We are
working with two SoCs at the moment, the AST2400 and AST2500 (hopefully
the AST2500 patches will be sent to the list soon). I wanted to
abstract the configuration to cater for the differences in register
values between the SoCs, less so for wiring the one SoC up in a
different fashion. For what it's worth, out of 86 registers defined in
the IO space between the two SoCs, 37 take the same value and 49
differ.

I can rework the commit message to say as much.

Separately, the qdev array approach was lifted from your commit
9c7d489379c2 hw/vexpress: Set reset values for daughterboard
oscillators. Another approach would be to set the members of the SCU's
reset array directly as we know the type. That seems less convoluted
but my gut instinct was that wasn't how we should be configuring the
devices. Is qdev the right way to go in the SCU's case?

Cheers,

Andrew

signature.asc
Description: This is a digitally signed message part

Re: [Qemu-devel] [V11 2/4] hw/i386: ACPI IVRS table

[Peter Xu]

On Sat, Jun 18, 2016 at 02:34:26PM +0200, Jan Kiszka wrote:
> On 2016-06-18 14:32, Peter Xu wrote:
> > On Sat, Jun 18, 2016 at 11:18:29AM +0300, David Kiarie wrote:
[...]
> >> I missed this is the last version of the patch I should fix it in next 
> >> version.
> >>
> >> On taking a closer look at this there might be larger problem where
> >> with the advent of -device  users can possibly emulate two
> >> IOMMUs at the same time ? A proposed solution was to have
> >> pci_setup_iommu check that DMA hook as not been setup yet and fail if
> >> yes. I should send a fix for that too.
> > 
> > Currently we should only support single vIOMMU.  If you are going to
> > rebase to x86-iommu codes, there is a patch that includes the check:
> > 
> >   "[PATCH v9 02/25] x86-iommu: provide x86_iommu_get_default"
> > 
> > by:
> > 
> >   assert(x86_iommu_default == NULL);
> > 
> > Maybe we should print something more readable, like "multiple vIOMMUs
> > are not supported yet", rather than an assertion fail.
> 
> You need proper error handling and a readable error message because
> nothing else will stop the user from doing -device intel-iommu -device
> amd-iommu.

Will do.  Thanks.

-- peterx

Re: [Qemu-devel] [RFC PATCH V4 0/4] Introduce COLO-compare

[Zhang Chen]

On 06/20/2016 11:03 AM, Jason Wang wrote:



On 2016年06月17日 10:25, Zhang Chen wrote:

Hi~ jason.

I tried a lot of ways to make it run in compare thread, but it not work.

Because that:
void g_main_context_push_thread_default (GMainContext *context);
Acquires context and sets it as the thread-default context for the 
current thread.


So, this function g_main_context_push_thread_default() just can set 
thread-default context,
not the global default context. and I can't find a function to set 
global default context in glib.
The qemu's QIOChannel uses g_source_attach(source, NULL); to attach 
GSource.

g_source_attach (GSource *source,
 GMainContext *context);

context
a GMainContext (if NULL, the default context will be used).

But he not say "the default context" is global default context or 
thread-default context.

So I read glib codes find that:
guint
g_source_attach (GSource *source,
 GMainContext *context)
{
.
if (!context)
context = g_main_context_default ();
.
}

g_main_context_default ()
Returns the global default main context.

So...I think we can't make qemu_chr_add_handlers() run in colo thread 
in this way.
Do you have any comments about that? 


How about (like I suggest previously) just use

g_souce_attach(x, g_main_context_get_thread_default());

in qemu's QIOChannel code?





I feel it seems can work, and will try it.
but I don't know how this change in qemu's QIOChannel code
will affect the other code. needs other people confirm it?
If no affect and works good,I will send a independent patch
for this.


Thanks
Zhang Chen




.



--
Thanks
zhangchen

Re: [Qemu-devel] [PATCH] pci_register_bar: cleanup

[Cao jin]

Hi Michael,

Would you please take a look at this one? It has been forgotten for a 
long time.


On 05/18/2016 08:31 PM, Michael S. Tsirkin wrote:

On Wed, May 18, 2016 at 02:17:20PM +0200, Paolo Bonzini wrote:

On 18/05/2016 14:16, Cao jin wrote:

I guess maybe this one is more suitable for trivial.


No, it's not trivial.  I guess it missed soft freeze.  Michael Tsirkin
will pick it up.

Thanks,

Paolo


Yes - please repost whatever was posted before freeze.
I'll review and pick this one up.
Thanks!


diff --git a/hw/pci/pci.c b/hw/pci/pci.c
index e67664d..f0f41dc 100644
--- a/hw/pci/pci.c
+++ b/hw/pci/pci.c
@@ -974,7 +974,7 @@ void pci_register_bar(PCIDevice *pci_dev, int region_num,
 uint8_t type, MemoryRegion *memory)
   {
   PCIIORegion *r;
-uint32_t addr;
+uint32_t addr; /* offset in pci config space */
   uint64_t wmask;
   pcibus_t size = memory_region_size(memory);

@@ -990,15 +990,20 @@ void pci_register_bar(PCIDevice *pci_dev, int
region_num,
   r->addr = PCI_BAR_UNMAPPED;
   r->size = size;
   r->type = type;
-r->memory = NULL;
+r->memory = memory;
+r->address_space = type & PCI_BASE_ADDRESS_SPACE_IO
+? pci_dev->bus->address_space_io
+: pci_dev->bus->address_space_mem;

   wmask = ~(size - 1);
-addr = pci_bar(pci_dev, region_num);
   if (region_num == PCI_ROM_SLOT) {
   /* ROM enable bit is writable */
   wmask |= PCI_ROM_ADDRESS_ENABLE;
   }
+
+addr = pci_bar(pci_dev, region_num);
   pci_set_long(pci_dev->config + addr, type);
+
   if (!(r->type & PCI_BASE_ADDRESS_SPACE_IO) &&
   r->type & PCI_BASE_ADDRESS_MEM_TYPE_64) {
   pci_set_quad(pci_dev->wmask + addr, wmask);
@@ -1007,11 +1012,6 @@ void pci_register_bar(PCIDevice *pci_dev, int
region_num,
   pci_set_long(pci_dev->wmask + addr, wmask & 0x);
   pci_set_long(pci_dev->cmask + addr, 0x);
   }
-pci_dev->io_regions[region_num].memory = memory;
-pci_dev->io_regions[region_num].address_space
-= type & PCI_BASE_ADDRESS_SPACE_IO
-? pci_dev->bus->address_space_io
-: pci_dev->bus->address_space_mem;
   }

   static void pci_update_vga(PCIDevice *pci_dev)



Reviewed-by: Paolo Bonzini 



.



--
Yours Sincerely,

Cao jin

Re: [Qemu-devel] [QEMU 6/7] kvm: Add two new arch specific functions

[Li, Liang Z]

> > --- a/target-arm/kvm.c
> > +++ b/target-arm/kvm.c
> > @@ -627,3 +627,17 @@ int kvm_arch_msi_data_to_gsi(uint32_t data)  {
> >  return (data - 32) & 0x;
> >  }
> > +
> > +unsigned long get_guest_max_pfn(void) {
> > +/* To be done */
> > +
> > +return 0;
> > +}
> > +
> > +unsigned long *tighten_guest_free_page_bmap(unsigned long *bmap) {
> > +/* To be done */
> > +
> > +return bmap;
> > +}
> > diff --git a/target-i386/kvm.c b/target-i386/kvm.c index
> > abf50e6..0b394cb 100644
> > --- a/target-i386/kvm.c
> > +++ b/target-i386/kvm.c
> > @@ -3327,3 +3327,38 @@ int kvm_arch_msi_data_to_gsi(uint32_t data)  {
> >  abort();
> >  }
> > +
> > +unsigned long get_guest_max_pfn(void) {
> > +PCMachineState *pcms = PC_MACHINE(current_machine);
> > +ram_addr_t above_4g_mem = pcms->above_4g_mem_size;
> > +unsigned long max_pfn;
> > +
> > +if (above_4g_mem) {
> > +max_pfn = ((1ULL << 32) + above_4g_mem) >> TARGET_PAGE_BITS;
> > +} else {
> > +max_pfn = pcms->below_4g_mem_size >> TARGET_PAGE_BITS;
> > +}
> > +
> > +return max_pfn;
> > +}
> 
> Why is this in kvm?

I can't find a better place. Do you have any suggestion? 

> > +pos = (above_4g_mem + below_4g_mem) >> TARGET_PAGE_BITS;
> > +len = ((1ULL << 32) - below_4g_mem) >> TARGET_PAGE_BITS;
> > +bitmap_clear(bmap, pos, len);
> > +}
> > +
> > +return bmap;
> > +}
> 
> what does this do? External APIs should have documentation.

I will add the documentation. Thanks!

Liang

Re: [Qemu-devel] [PATCH v4 3/3] i386: publish advised value of MSR_IA32_FEATURE_CONTROL via fw_cfg

[Haozhong Zhang]

On 06/17/16 13:21, Raj, Ashok wrote:
> On Fri, Jun 17, 2016 at 07:31:08PM +0200, Laszlo Ersek wrote:
> > >>
> > >> On 16/06/2016 08:06, Haozhong Zhang wrote:
> > >>> It's a prerequisite that certain bits of MSR_IA32_FEATURE_CONTROL should
> > >>> be set before some features (e.g. VMX and LMCE) can be used, which is
> > >>> usually done by the firmware. This patch adds a fw_cfg file
> > >>> "etc/msr_feature_control" which contains the advised value of
> > >>> MSR_IA32_FEATURE_CONTROL and can be used by guest firmware (e.g. 
> > >>> SeaBIOS).
> > >>>
> 
> I'm sorry i'm joining this discussion a bit late returning from vacation. 
> In a real platform supporting LMCE, BIOS is responsible for setting the bits 
> for IA32_FEATURE_CONTROL correctly. There are good reasons why we want the 
> BIOS to play this role.
> 
> in a virtualized environment, do we really have to push the same requirement
> or would it suffice to just emulate it as we did in the early patches.
> 
> Not sure what exact problem is created by just simply supporting it within
> kvm/qemu and not needing the bios for the guest to also adapt these changes.
> 

In the current nested VMX implementation in QEMU, setup
MSR_IA32_FEATURE_CONTROL is left to guest. So I think, for LMCE which
is another feature involving MSR_IA32_FEATURE_CONTROL, we may follow
the existing code.

Paolo and Radim, is there any case that objects to setting
MSR_IA32_FEATURE_CONTROL in QEMU?

Thanks,
Haozhong

Re: [Qemu-devel] [RFC PATCH V4 0/4] Introduce COLO-compare

[Jason Wang]

On 2016年06月17日 10:25, Zhang Chen wrote:

Hi~ jason.

I tried a lot of ways to make it run in compare thread, but it not work.

Because that:
void g_main_context_push_thread_default (GMainContext *context);
Acquires context and sets it as the thread-default context for the 
current thread.


So, this function g_main_context_push_thread_default() just can set 
thread-default context,
not the global default context. and I can't find a function to set 
global default context in glib.
The qemu's QIOChannel uses g_source_attach(source, NULL); to attach 
GSource.

g_source_attach (GSource *source,
 GMainContext *context);

context
a GMainContext (if NULL, the default context will be used).

But he not say "the default context" is global default context or 
thread-default context.

So I read glib codes find that:
guint
g_source_attach (GSource *source,
 GMainContext *context)
{
.
if (!context)
context = g_main_context_default ();
.
}

g_main_context_default ()
Returns the global default main context.

So...I think we can't make qemu_chr_add_handlers() run in colo thread 
in this way.
Do you have any comments about that? 


How about (like I suggest previously) just use

g_souce_attach(x, g_main_context_get_thread_default());

in qemu's QIOChannel code?

Re: [Qemu-devel] [PATCH] vmxnet3: Fix reading/writing guest memory specially when behind an IOMMU

[Jason Wang]

On 2016年06月18日 18:24, KarimAllah Ahmed wrote:

When a PCI device lives behind an IOMMU, it should use 'pci_dma_*' family of
functions when any transfer from/to guest memory is required while
'cpu_physical_memory_*' family of functions completely bypass any MMU/IOMMU in
the system.

vmxnet3 was exclusively using 'cpu_physical_memory_*' family of functions which
works fine with the default QEMU setup where IOMMU is not enabled but fails
miserably when IOMMU is enabled. This commit converts all such instances in
favor of 'pci_dma_*'

Cc: Dmitry Fleytman
Cc: Jason Wang
Cc:qemu-devel@nongnu.org
Cc: Anthony Liguori
Signed-off-by: KarimAllah Ahmed
---
  hw/net/vmware_utils.h  |  55 +++--
  hw/net/vmxnet3.c   | 207 +++--
  hw/net/vmxnet_tx_pkt.c |  19 ++---
  hw/net/vmxnet_tx_pkt.h |   8 +-
  4 files changed, 161 insertions(+), 128 deletions(-)


Thanks for the patch, but could you pls rebase this on top of master?

Re: [Qemu-devel] [QEMU 7/7] migration: skip free pages during live migration

[Li, Liang Z]

> On Mon, Jun 13, 2016 at 06:16:49PM +0800, Liang Li wrote:
> > After sending out the request for free pages, live migration process
> > will start without waiting for the free page bitmap is ready. If the
> > free page bitmap is not ready when doing the 1st
> > migration_bitmap_sync() after ram_save_setup(), the free page bitmap
> > will be ignored, this means the free pages will not be filtered out in
> > this case.
> > The current implementation can not work with post copy, if post copy
> > is enabled, we simply ignore the free pages. Will make it work later.
> >
> > Signed-off-by: Liang Li 
> 
> Tying migration to balloon in this way seems rather ugly.
> So with request ID, the logic would basically be
> 
>   - add memory listener with high priority
>   - before sync bitmap, increment request id
>   - when we get response, if it has latest request id,
> clear qemu migration bitmap
> otherwise, ignore

Use the request ID is good. 
Could you elaborate the meaning of ' add memory listener with high priority ' ?

Thanks!
Liang

Re: [Qemu-devel] [QEMU 4/7] balloon: get free page info from guest

[Li, Liang Z]

> On Mon, Jun 13, 2016 at 06:16:46PM +0800, Liang Li wrote:
> > Add a new feature to get the free page information from guest, the
> > free page information is saved in a bitmap. Please note that 'free
> > page' only means these pages are free before the request, some of the
> > pages will become no free during the process of sending the free page
> > bitmap to QEMU.
> >
> > Signed-off-by: Liang Li 
> 
> 
> I don't much like this request interface.
> The meaning of free page is rather fuzzy too - so at what point are they free?
> 
> 
> My suggestion would be:
>   report free page request ID to guest
>   include request ID when guest sends free page list
> 
> the definition is then:
>   page was free sometime after host set this value of request
>   ID and before it received response with the same ID

That's better. I will change in next version.
And there is another issue similar as we solved to speed up the 
inflating/deflating process.
Should we use a large page bitmap or a small one ? I used a big one in the 
patch.

If we chose to use a small page bitmap, then we have to traverse the free page 
list for many times,
and the meaning of free page will be more fuzzy.

But if we use a big map bitmap, people may ask, why a small one here and a big 
one there?

Thanks!

Liang 

Re: [Qemu-devel] [PATCH 0/5] hw/net: Don't use cpu_to_*w() and *_to_cpup()

[Jason Wang]

On 2016年06月17日 01:17, Peter Maydell wrote:

This patchset converts a handful of network devices to use
ld*_p() and st*_p() instead of cpu_to_*w() and *_to_cpup().

This is the last lot of conversion patches; I have the "delete
the implementations from bswap.h" patch, and will send that out
once all of the in-flight patches have hit master.

thanks
-- PMM

Peter Maydell (5):
   hw/net/eepro100.c: Don't use cpu_to_*w() and *_to_cpup()
   hw/net/rtl8139.c: Don't use *_to_cpup()
   hw/net/rocker: Don't use *_to_cpup()
   hw/net/virtio-net.c: Don't use *_to_cpup()
   hw/net/e1000: Don't use *_to_cpup()

  hw/net/e1000.c | 18 +-
  hw/net/e1000e_core.c   |  6 +++---
  hw/net/e1000x_common.c |  2 +-
  hw/net/eepro100.c  |  8 
  hw/net/rocker/rocker_tlv.h |  6 +++---
  hw/net/rtl8139.c   |  9 -
  hw/net/virtio-net.c|  2 +-
  7 files changed, 25 insertions(+), 26 deletions(-)



Acked-by: Jason Wang 

[Qemu-devel] [Bug 1591628] Re: 2.6.0 hangs linux vm using vfio for pci passthrough of graphics card

[Alex Williamson]

Please test the patch in the link below and send your email address
(privately if preferred) so I can provide proper attributes for
Reported-by.  Thanks.

https://paste.fedoraproject.org/381971/46638926/

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

Title:
  2.6.0 hangs linux vm using vfio for pci passthrough of graphics card

Status in QEMU:
  New

Bug description:
  Not a duplicate of my old bug 1488363

  qemu version 2.5.1 works fine
  qemu version 2.6.0 fails

  seabios 1.9.2-1

  using kernel 4.5.5 with grsecurity

  I built using the arch packaging tools, but commented out all the
  patch code, so it should be vanilla.

  The problem is just that I start a Linux vm using either my radeon R7
  260x or radeon HD 6770, and with qemu 2.6.0, it looks normal until
  after the grub menu, and then the screen looks broken (with mostly
  black, and some pixely junk spread horizontally in a few places on the
  screen... first we thought maybe the monitor died). I'm not sure if
  it's before or only at the moment where the screen resolution changes
  (I could check that or record it on request). Also, the VM is not
  pingable and does not respond to "system_powerdown" on qemu monitor.

  However, the same setup works fine with windows 8. And it works fine
  without graphics cards passed through. A usb controller passed through
  works fine too.

  
  And then I ran a bisect...

  2d82f8a3cdb276bc3cb92d6f01bf8f66bf328d62 is the first bad commit
  commit 2d82f8a3cdb276bc3cb92d6f01bf8f66bf328d62
  Author: Alex Williamson 
  Date:   Thu Mar 10 09:39:08 2016 -0700

  vfio/pci: Convert all MemoryRegion to dynamic alloc and 
consistent functions
  
  Match common vfio code with setup, exit, and finalize functions 
for
  BAR, quirk, and VGA management.  VGA is also changed to dynamic
  allocation to match the other MemoryRegions.
  
  Signed-off-by: Alex Williamson 

  :04 04 0acfd49b6ecae780b6f52a34080ecec6b3ec3672 
e0cfdadede08f553463c0b23931eda81107f41b8 M  hw
  
  then confirm it by reverting that commit
  git checkout v2.6.0
  git revert 2d82f8a3cdb276bc3cb92d6f01bf8f66bf328d62
  git mergetool -t kdiff3
  "select all from C", save
  not sure if this is the right way to do this...but it compiles 
and works (bug fixed)
  git commit -m "revert 2d82f8a3cdb276bc3cb92d6f01bf8f66bf328d62 
resolve conflicts"

  And that 2.6.0 build with that one patch reverted works fine.

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

Re: [Qemu-devel] [Qemu-ppc] [PATCH 01/10] ppc: Fix rfi/rfid/hrfi/... emulation

[David Gibson]

On Mon, Jun 20, 2016 at 07:12:38AM +1000, Benjamin Herrenschmidt wrote:
> On Sun, 2016-06-19 at 19:23 +0200, Cédric Le Goater wrote:
> > > You can run a 32-bit OS or firmware on ppc64, but it needs to know that
> > > it's running on a 64-bit chip and do a few things differently.
> > 
> > yes sure but qemu would still allow rfi under 64bit CPUs, that is what 
> > I was concerned about. Is that ok ? 
> 
> Why ? A real CPU won't allow it, why should we ?

We shouldn't.  However, I'm inclined to in for now, until we have an
OpenBIOS fix actually committed.  I'd prefer to keep the existing
setup sorta-working when the current situation is unlikely to break
working code, even though it's definitely wrong.

BenH or Cédric, if you want to resend the hrfi fix patch with the
64-bit rfi support left in for no, that would be good.

-- 
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] target-ppc: Correct ppc3500_spin initial TLB size

[da...@gibson.dropbear.id.au]

On Fri, Jun 17, 2016 at 10:55:47PM +, Scott Wood wrote:
> On 06/17/2016 05:13 PM, Aaron Larson wrote:
> > When e500 PPC is booted multi-core, the non-boot cores are started via
> > the spin table.  ppce500_spin.c:spin_kick() calls
> > mmubooke_create_initial_mapping() to allocate a 64MB TLB entry, but
> > the created TLB entry is only 256KB.
> > 
> > The root cause is that the function computing the size of the TLB
> > entry, namely booke206_page_size_to_tlb assumes MAS1.TSIZE as defined
> > by latter PPC cores, specifically (n**4)KB. The result is then used by
> > mmubooke_create_initial_mapping using MAS1_TSIZE_SHIFT, but
> > MAS1_TSIZE_SHIFT is defined assuming TLB entries are (n**2)KB. I.e., a
> > difference of shift=7 or shift=8.
> > 
> > Simply changing MAS1_TSIZE_SHIFT from 7 to 8 is not appropriate since
> > the macro is used elsewhere.
> > 
> > Signed-off-by: Aaron Larson 
> > ---
> >  hw/ppc/ppce500_spin.c | 6 +-
> >  1 file changed, 5 insertions(+), 1 deletion(-)
> > 
> > diff --git a/hw/ppc/ppce500_spin.c b/hw/ppc/ppce500_spin.c
> > index 76bd78b..7e38f0c 100644
> > --- a/hw/ppc/ppce500_spin.c
> > +++ b/hw/ppc/ppce500_spin.c
> > @@ -75,7 +75,11 @@ static void spin_reset(void *opaque)
> >  /* Create -kernel TLB entries for BookE, linearly spanning 256MB.  */
> >  static inline hwaddr booke206_page_size_to_tlb(uint64_t size)
> >  {
> > -return ctz32(size >> 10) >> 1;
> > +/* The EREF indicates that TLB pages are (4 to the power of 2)KB, which
> > + * corresponds to MAS1_TSIZE_SHIFT=8, but to support legacy processors 
> > that
> > + * assume TLB pages are (2 to the power of 2)KB MAS1_TSIZE_SHIFT is
> > + * currently 7. */
> 
> This is backwards. It's the old processors that can only handle
> power-of-4 sizes.

To clarify, is this a problem in the code, or just in the comment?

> > +return ctz32(size >> 10) >> (MAS1_TSIZE_SHIFT - 7);
> 
> The patch that changed MAS1_TSIZE_SHIFT from 8 to 7 was around the same
> time as the patch that added this code, which is probably why adjusting
> it got missed.  Commit 2bd9543cd3 did update the equivalent code in
> ppce500_mpc8544ds.c, which now resides in hw/ppc/e500.c and has been
> changed to not assume a power-of-2 size.  The ppce500_spin version
> should be eliminated.

Sounds sensible.

Aaron, for some reason I got multiple copies of your patch mail - a
couple of full ones and then a couple more extras which had 0 size.
Was that just something going wrong with your mailer, or did you
attempt to send a couple of different versions?

-- 
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 v4 2/3] target-i386: add migration support for Intel LMCE

[Haozhong Zhang]

On 06/17/16 14:20, Eduardo Habkost wrote:
> On Fri, Jun 17, 2016 at 10:01:05AM +0800, Haozhong Zhang wrote:
> > On 06/16/16 14:58, Eduardo Habkost wrote:
> > > On Thu, Jun 16, 2016 at 07:40:20PM +0200, Paolo Bonzini wrote:
> > > > 
> > > > 
> > > > On 16/06/2016 19:36, Eduardo Habkost wrote:
> > > > >> > 
> > > > >> > Eduardo said nice for this part in previous version [1], so we may 
> > > > >> > wait
> > > > >> > for his comments?
> > > > >> > 
> > > > >> > [1] 
> > > > >> > http://lists.nongnu.org/archive/html/qemu-devel/2016-06/msg01992.html
> > > > > I agree we don't need this check, but I still believe it is a
> > > > > nice thing to have.
> > > > > 
> > > > > In addition to detecting user errors, they don't hurt and are
> > > > > useful for things like "-cpu host", that don't guarantee
> > > > > live-migration compatibility but still allow migration if you
> > > > > ensure host capabilities are the same on both sides.
> > > > 
> > > > On the other hand we don't check for this on any other property, either
> > > > CPU or device, do we?  Considering "lmce=on" always breaks on an old
> > > > kernel (i.e. there's no need for an explicit ",enforce" on the -cpu
> > > > flag), I think it's unnecessary and makes things inconsistent.
> > > 
> > > We don't check that because we normally can't: we usually don't
> > > send any configuration data (or anything that could be used to
> > > detect configuration mismatches) to the destination. When we do,
> > > it's often by accident.
> > > 
> > > In this case, it looks like we never needed to send mcg_cap in
> > > the migration stream. But we already send it, so let's use it for
> > > something useful.
> > > 
> > > I believe we should have more checks like these, when possible. I
> > > have been planning for a while to send CPUID data in the
> > > migration stream, to detect migration compatibility errors
> > > (either user errors or QEMU bugs).
> > > 
> > > In theory, those checks should never be necessary. In practice I
> > > believe they would be very useful.
> > >
> > 
> > Hi Eduardo and Paolo,
> > 
> > What will be the conclusion? Do we still need this check?
> > 
> > I'm fine to remove this check if we normally didn't make such kind of
> > checks and require users to avoid configuration mismatch.
> 
> I don't know yet if Paolo is convinced that the check is still
> useful. :)
> 
> I suggest doing it as a separate patch, so we can apply the rest
> of the series now and discuss/apply the check later.
>

Yes, I'll move the check to a separate patch so that we can easily
drop it if not necessary. Thanks for the suggestion!

> > 
> > > > 
> > > > > (I was going to suggest enabling lmce automatically on "-cpu
> > > > > host" as a follow-up patch, BTW.)
> > > > 
> > > > Interesting.  Technically it comes from the host kernel, not from the
> > > > host CPU.  But it does sounds like a good idea; -cpu host pretty much
> > > > implies the same kernel (in addition to the same processor) on both
> > > > sides of the migration.
> > > 
> > > "-cpu host" already means "whatever is allowed by the host [CPU
> > > and/or kernel]", not just "host CPU". It enables x2apic on all
> > > hosts, for example.
> > >
> > 
> > Does that mean we can automatically enable LMCE for "-cpu host"?
> 
> We can automatically enable LMCE for "-cpu host" if and only if
> the host kernel supports LMCE.
>

According to our discussion for KVM Patch 3, we may have to disable it
by default by -cpu host, so that pc-2.7 will not require new kernels
unless LMCE is required explicitly by users.

Thanks,
Haozhong

Re: [Qemu-devel] [PATCH v2] target-ppc: Fix rlwimi, rlwinm, rlwnm

[David Gibson]

On Sun, Jun 19, 2016 at 03:34:35AM +1000, Anton Blanchard wrote:
> Hi rth,
> 
> > In 63ae0915f8ec, I arranged to use a 32-bit rotate, without
> > considering the effect of a mask value that wraps around to
> > the high bits of the word.
> 
> Thanks, that passes my tests.
> 
> Tested-by: Anton Blanchard 

Unfortunately the earlier buggy version already got pulled upstream.
I've folded this new version with a revert of the earlier one and
merged to ppc-for-2.7.

> 
> Anton
> 
> > Signed-off-by: Richard Henderson 
> > ---
> >  target-ppc/translate.c | 73
> > +++--- 1 file changed, 51
> > insertions(+), 22 deletions(-)
> > 
> > diff --git a/target-ppc/translate.c b/target-ppc/translate.c
> > index b689475..23bc054 100644
> > --- a/target-ppc/translate.c
> > +++ b/target-ppc/translate.c
> > @@ -1636,7 +1636,6 @@ static void gen_rlwimi(DisasContext *ctx)
> >  tcg_gen_deposit_tl(t_ra, t_ra, t_rs, sh, me - mb + 1);
> >  } else {
> >  target_ulong mask;
> > -TCGv_i32 t0;
> >  TCGv t1;
> >  
> >  #if defined(TARGET_PPC64)
> > @@ -1645,12 +1644,21 @@ static void gen_rlwimi(DisasContext *ctx)
> >  #endif
> >  mask = MASK(mb, me);
> >  
> > -t0 = tcg_temp_new_i32();
> >  t1 = tcg_temp_new();
> > -tcg_gen_trunc_tl_i32(t0, t_rs);
> > -tcg_gen_rotli_i32(t0, t0, sh);
> > -tcg_gen_extu_i32_tl(t1, t0);
> > -tcg_temp_free_i32(t0);
> > +if (mask <= 0xu) {
> > +TCGv_i32 t0 = tcg_temp_new_i32();
> > +tcg_gen_trunc_tl_i32(t0, t_rs);
> > +tcg_gen_rotli_i32(t0, t0, sh);
> > +tcg_gen_extu_i32_tl(t1, t0);
> > +tcg_temp_free_i32(t0);
> > +} else {
> > +#if defined(TARGET_PPC64)
> > +tcg_gen_deposit_i64(t1, t_rs, t_rs, 32, 32);
> > +tcg_gen_rotli_i64(t1, t1, sh);
> > +#else
> > +g_assert_not_reached();
> > +#endif
> > +}
> >  
> >  tcg_gen_andi_tl(t1, t1, mask);
> >  tcg_gen_andi_tl(t_ra, t_ra, ~mask);
> > @@ -1678,20 +1686,28 @@ static void gen_rlwinm(DisasContext *ctx)
> >  tcg_gen_ext32u_tl(t_ra, t_rs);
> >  tcg_gen_shri_tl(t_ra, t_ra, mb);
> >  } else {
> > +target_ulong mask;
> >  #if defined(TARGET_PPC64)
> >  mb += 32;
> >  me += 32;
> >  #endif
> > -if (sh == 0) {
> > -tcg_gen_andi_tl(t_ra, t_rs, MASK(mb, me));
> > -} else {
> > -TCGv_i32 t0 = tcg_temp_new_i32();
> > +mask = MASK(mb, me);
> >  
> > +if (mask <= 0xu) {
> > +TCGv_i32 t0 = tcg_temp_new_i32();
> >  tcg_gen_trunc_tl_i32(t0, t_rs);
> >  tcg_gen_rotli_i32(t0, t0, sh);
> > -tcg_gen_andi_i32(t0, t0, MASK(mb, me));
> > +tcg_gen_andi_i32(t0, t0, mask);
> >  tcg_gen_extu_i32_tl(t_ra, t0);
> >  tcg_temp_free_i32(t0);
> > +} else {
> > +#if defined(TARGET_PPC64)
> > +tcg_gen_deposit_i64(t_ra, t_rs, t_rs, 32, 32);
> > +tcg_gen_rotli_i64(t_ra, t_ra, sh);
> > +tcg_gen_andi_i64(t_ra, t_ra, mask);
> > +#else
> > +g_assert_not_reached();
> > +#endif
> >  }
> >  }
> >  if (unlikely(Rc(ctx->opcode) != 0)) {
> > @@ -1707,24 +1723,37 @@ static void gen_rlwnm(DisasContext *ctx)
> >  TCGv t_rb = cpu_gpr[rB(ctx->opcode)];
> >  uint32_t mb = MB(ctx->opcode);
> >  uint32_t me = ME(ctx->opcode);
> > -TCGv_i32 t0, t1;
> > +target_ulong mask;
> >  
> >  #if defined(TARGET_PPC64)
> >  mb += 32;
> >  me += 32;
> >  #endif
> > +mask = MASK(mb, me);
> >  
> > -t0 = tcg_temp_new_i32();
> > -t1 = tcg_temp_new_i32();
> > -tcg_gen_trunc_tl_i32(t0, t_rb);
> > -tcg_gen_trunc_tl_i32(t1, t_rs);
> > -tcg_gen_andi_i32(t0, t0, 0x1f);
> > -tcg_gen_rotl_i32(t1, t1, t0);
> > -tcg_temp_free_i32(t0);
> > +if (mask <= 0xu) {
> > +TCGv_i32 t0 = tcg_temp_new_i32();
> > +TCGv_i32 t1 = tcg_temp_new_i32();
> > +tcg_gen_trunc_tl_i32(t0, t_rb);
> > +tcg_gen_trunc_tl_i32(t1, t_rs);
> > +tcg_gen_andi_i32(t0, t0, 0x1f);
> > +tcg_gen_rotl_i32(t1, t1, t0);
> > +tcg_gen_extu_i32_tl(t_ra, t1);
> > +tcg_temp_free_i32(t0);
> > +tcg_temp_free_i32(t1);
> > +} else {
> > +#if defined(TARGET_PPC64)
> > +TCGv_i64 t0 = tcg_temp_new_i64();
> > +tcg_gen_andi_i64(t0, t_rb, 0x1f);
> > +tcg_gen_deposit_i64(t_ra, t_rs, t_rs, 32, 32);
> > +tcg_gen_rotl_i64(t_ra, t_ra, t0);
> > +tcg_temp_free_i64(t0);
> > +#else
> > +g_assert_not_reached();
> > +#endif
> > +}
> >  
> > -tcg_gen_andi_i32(t1, t1, MASK(mb, me));
> > -tcg_gen_extu_i32_tl(t_ra, t1);
> > -tcg_temp_free_i32(t1);
> > +tcg_gen_andi_tl(t_ra, t_ra, mask);
> >  
> >  if (unlikely(Rc(ctx->opcode) != 0)) 

Re: [Qemu-devel] [QEMU 2/7] virtio-balloon: add drop cache support

[Li, Liang Z]

> On Mon, Jun 13, 2016 at 06:16:44PM +0800, Liang Li wrote:
> > virtio-balloon can make use of the amount of free memory to determine
> > the amount of memory to be filled in the balloon, but the amount of
> > free memory will be effected by the page cache, which can be reclaimed.
> > Drop the cache before getting the amount of free memory will be very
> > helpful to relect the exact amount of memroy that can be reclaimed.
> 
> Can't we just extend stats to report "reclaimable" memory?
> 

Yes, I noticed the VIRTIO_BALLOON_S_AVAIL is for this purpose.  

I summarized the possible solutions from others:
a. Drop the cache in guest agent instead of an obvious qmp command. (Paolo) 
b. Use a parameter as a hint to tell the guest live migration is going to 
happen, and let the guest do what it can do to make the host's life easier.  
(David)

What' your opinion about these two solutions?

Thanks!
Liang

Re: [Qemu-devel] [PATCH v4 1/3] target-i386: KVM: add basic Intel LMCE support

[Haozhong Zhang]

On 06/17/16 13:20, Eduardo Habkost wrote:
> On Fri, Jun 17, 2016 at 09:26:57AM +0800, Haozhong Zhang wrote:
> [...]
> > > >  static void mce_init(X86CPU *cpu)
> > > >  {
> > > >  CPUX86State *cenv = >env;
> > > >  unsigned int bank;
> > > > +Error *local_err = NULL;
> > > >  
> > > >  if (((cenv->cpuid_version >> 8) & 0xf) >= 6
> > > >  && (cenv->features[FEAT_1_EDX] & (CPUID_MCE | CPUID_MCA)) ==
> > > >  (CPUID_MCE | CPUID_MCA)) {
> > > >  cenv->mcg_cap = MCE_CAP_DEF | MCE_BANKS_DEF;
> > > > +
> > > > +if (cpu->enable_lmce) {
> > > > +if (!lmce_supported()) {
> > > > +error_setg(_err, "KVM unavailable or LMCE not 
> > > > supported");
> > > > +error_propagate(_abort, local_err);
> > > > +}
> > > > +cenv->mcg_cap |= MCG_LMCE_P;
> > > > +}
> > > > +
> > > 
> > > This duplicates the existing check in kvm_arch_init_vcpu(). The
> > > difference is that the existing code is KVM-specific and doesn't
> > > stop initialization when capabilities are missing. We can unify
> > > them into a single mcg_cap-checking function as a follow-up.
> > >
> > 
> > If I reuse the existing MCE capability check in kvm_arch_init_vcpu(),
> > is it reasonable to make change to stop initialization if missing
> > capabilities? Or should we stop only for missing newly added capabilities
> > (e.g. LMCE) in order to keep backwards compatibility?
> 
> Ideally, yes. But in practice we need to check if we won't break
> existing setups that were working. If all kernel versions we care
> about always MCG_CTL_P|MCG_SER_P + 10 banks as supported, we can
> make all bits mandatory.
>

Let's stop only for LMCE in this patch series. Other bits may be
changed in future after the kernel support is clarified.

Thanks,
Haozhong

> I need to re-read the thread were kvm_get_mce_cap_supported() was
> discussed, to refresh my memory.
>
> -- 
> Eduardo
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Qemu-devel] [PATCH] hw/intc/arm_gicv3: Add missing break

[Shannon Zhao]

From: Shannon Zhao 

These are spotted by coverity 1356936 and 1356937.

Signed-off-by: Shannon Zhao 
---
 hw/intc/arm_gicv3_cpuif.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/hw/intc/arm_gicv3_cpuif.c b/hw/intc/arm_gicv3_cpuif.c
index 5b2972e..4633172 100644
--- a/hw/intc/arm_gicv3_cpuif.c
+++ b/hw/intc/arm_gicv3_cpuif.c
@@ -975,6 +975,7 @@ static CPAccessResult gicv3_irqfiq_access(CPUARMState *env,
 if (!is_a64(env) && !arm_is_el3_or_mon(env)) {
 r = CP_ACCESS_TRAP_EL3;
 }
+break;
 default:
 g_assert_not_reached();
 }
@@ -1006,6 +1007,7 @@ static CPAccessResult gicv3_fiq_access(CPUARMState *env,
 if (!is_a64(env) && !arm_is_el3_or_mon(env)) {
 r = CP_ACCESS_TRAP_EL3;
 }
+break;
 default:
 g_assert_not_reached();
 }
-- 
2.0.4

Re: [Qemu-devel] [QEMU 1/7] balloon: speed up inflating & deflating process

[Li, Liang Z]

> >
> >  virtqueue_push(vq, elem, offset); @@ -374,6 +489,7 @@ static
> > uint64_t virtio_balloon_get_features(VirtIODevice *vdev, uint64_t f,
> >  VirtIOBalloon *dev = VIRTIO_BALLOON(vdev);
> >  f |= dev->host_features;
> >  virtio_add_feature(, VIRTIO_BALLOON_F_STATS_VQ);
> > +virtio_add_feature(, VIRTIO_BALLOON_F_PAGE_BITMAP);
> >  return f;
> >  }
> >
> 
> Pls add features to virtio_balloon_properties.
> You also need to handle compatibility by disabling for old machine types.
> 

I forgot that, will add in next version.

> > --- a/include/standard-headers/linux/virtio_balloon.h
> > +++ b/include/standard-headers/linux/virtio_balloon.h
> > @@ -34,6 +34,7 @@
> >  #define VIRTIO_BALLOON_F_MUST_TELL_HOST0 /* Tell before
> reclaiming pages */
> >  #define VIRTIO_BALLOON_F_STATS_VQ  1 /* Memory Stats virtqueue
> */
> >  #define VIRTIO_BALLOON_F_DEFLATE_ON_OOM2 /* Deflate balloon
> on OOM */
> > +#define VIRTIO_BALLOON_F_PAGE_BITMAP  3 /* Use page bitmap to
> send
> > +page info */
> >
> >  /* Size of a PFN in the balloon interface. */  #define
> > VIRTIO_BALLOON_PFN_SHIFT 12
> 
> We want to keep this in sync with Linux.
> Let's get a minimal patch to extend this header merged in linux, then update
> this one.

OK. Can this be independent of the virtio-balloon SPEC? As I understand it,
 it will not get merged before the SPEC is set?

Thanks!
Liang

Re: [Qemu-devel] [Qemu-ppc] [PATCH] ppc: Improve emulation of THRM registers

[David Gibson]

On Sun, Jun 19, 2016 at 02:14:12PM +0200, BALATON Zoltan wrote:
> On Sun, 19 Jun 2016, Benjamin Herrenschmidt wrote:
> > The 75x and 74xx processors have some thermal monitoring SPRs that
> > some OSes such as MacOS do use. Our current "dumb" implementation
> > isn't good enough and will cause some versions of MacOS to hang during
> > boot.
> > 
> > This lifts an improved emulation from MacOnLinux and adapts it to
> > qemu, thus fixing the problem.
> > 
> > Signed-off-by: Benjamin Herrenschmidt 
> > ---
> > target-ppc/helper.h |  1 +
> > target-ppc/misc_helper.c| 41 +
> > target-ppc/translate_init.c | 13 ++---
> > 3 files changed, 52 insertions(+), 3 deletions(-)
> > 
> > diff --git a/target-ppc/helper.h b/target-ppc/helper.h
> > index f4410a8..18eb52f 100644
> > --- a/target-ppc/helper.h
> > +++ b/target-ppc/helper.h
> > @@ -670,3 +670,4 @@ DEF_HELPER_4(dscli, void, env, fprp, fprp, i32)
> > DEF_HELPER_4(dscliq, void, env, fprp, fprp, i32)
> > 
> > DEF_HELPER_1(tbegin, void, env)
> > +DEF_HELPER_1(fixup_thrm, void, env)
> > diff --git a/target-ppc/misc_helper.c b/target-ppc/misc_helper.c
> > index 7d41b01..4315778 100644
> > --- a/target-ppc/misc_helper.c
> > +++ b/target-ppc/misc_helper.c
> > @@ -166,3 +166,44 @@ void ppc_store_msr(CPUPPCState *env, target_ulong 
> > value)
> > {
> > hreg_store_msr(env, value, 0);
> > }
> > +
> > +/* This code is lifted from MacOnLinux. It is called whenever
> > + * THRM1,2 or 3 is read an fixes up the values in such a way
> > + * that will mac MacOS not hang. These registers exist on some
> 
> Typo: mac -> make?

I've made this change, along with a number of checkpatch fixes as I've
merged this into my tree.


-- 
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 1/8] cpus: pass CPUState to run_on_cpu helpers

[David Gibson]

On Mon, Jun 20, 2016 at 01:28:26AM +0300, Sergey Fedorov wrote:
> From: Alex Bennée 
> 
> CPUState is a fairly common pointer to pass to these helpers. This means
> if you need other arguments for the async_run_on_cpu case you end up
> having to do a g_malloc to stuff additional data into the routine. For
> the current users this isn't a massive deal but for MTTCG this gets
> cumbersome when the only other parameter is often an address.
> 
> This adds the typedef run_on_cpu_func for helper functions which has an
> explicit CPUState * passed as the first parameter. All the users of
> run_on_cpu and async_run_on_cpu have had their helpers updated to use
> CPUState where available.
> 
> Signed-off-by: Alex Bennée 
> Signed-off-by: Sergey Fedorov 

[snip]

> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> index 778fa255a946..a427492c0310 100644
> --- a/hw/ppc/spapr.c
> +++ b/hw/ppc/spapr.c
> @@ -2159,10 +2159,8 @@ static void spapr_machine_finalizefn(Object *obj)
>  g_free(spapr->kvm_type);
>  }
>  
> -static void ppc_cpu_do_nmi_on_cpu(void *arg)
> +static void ppc_cpu_do_nmi_on_cpu(CPUState *cs, void *arg)
>  {
> -CPUState *cs = arg;
> -
>  cpu_synchronize_state(cs);
>  ppc_cpu_do_system_reset(cs);
>  }
> @@ -2172,7 +2170,7 @@ static void spapr_nmi(NMIState *n, int cpu_index, Error 
> **errp)
>  CPUState *cs;
>  
>  CPU_FOREACH(cs) {
> -async_run_on_cpu(cs, ppc_cpu_do_nmi_on_cpu, cs);
> +async_run_on_cpu(cs, ppc_cpu_do_nmi_on_cpu, NULL);
>  }
>  }
>  
> diff --git a/hw/ppc/spapr_hcall.c b/hw/ppc/spapr_hcall.c
> index 2ba5cbdb194a..22d57469b8a5 100644
> --- a/hw/ppc/spapr_hcall.c
> +++ b/hw/ppc/spapr_hcall.c
> @@ -13,19 +13,18 @@
>  #include "kvm_ppc.h"
>  
>  struct SPRSyncState {
> -CPUState *cs;
>  int spr;
>  target_ulong value;
>  target_ulong mask;
>  };
>  
> -static void do_spr_sync(void *arg)
> +static void do_spr_sync(CPUState *cs, void *arg)
>  {
>  struct SPRSyncState *s = arg;
> -PowerPCCPU *cpu = POWERPC_CPU(s->cs);
> +PowerPCCPU *cpu = POWERPC_CPU(cs);
>  CPUPPCState *env = >env;
>  
> -cpu_synchronize_state(s->cs);
> +cpu_synchronize_state(cs);
>  env->spr[s->spr] &= ~s->mask;
>  env->spr[s->spr] |= s->value;
>  }
> @@ -34,7 +33,6 @@ static void set_spr(CPUState *cs, int spr, target_ulong 
> value,
>  target_ulong mask)
>  {
>  struct SPRSyncState s = {
> -.cs = cs,
>  .spr = spr,
>  .value = value,
>  .mask = mask
> @@ -908,11 +906,11 @@ typedef struct {
>  Error *err;
>  } SetCompatState;

You've missed the opportunity here to remove the cpu field from
SetCompatState, as you did with SPRSyncState.

>  
> -static void do_set_compat(void *arg)
> +static void do_set_compat(CPUState *cs, void *arg)
>  {
>  SetCompatState *s = arg;
>  
> -cpu_synchronize_state(CPU(s->cpu));
> +cpu_synchronize_state(cs);
>  ppc_set_compat(s->cpu, s->cpu_version, >err);
>  }

-- 
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] [SeaBIOS] [PATCH v2] fw/msr_feature_control: add support to set MSR_IA32_FEATURE_CONTROL

[Haozhong Zhang]

On 06/17/16 11:26, Kevin O'Connor wrote:
> On Fri, Jun 17, 2016 at 03:20:10PM +0800, Haozhong Zhang wrote:
> > OS usually expects BIOS to set certain bits in MSR_IA32_FEATURE_CONTROL
> > for some features (e.g. VMX and LMCE). QEMU provides a fw_cfg file
> > "etc/msr_feature_control" to advise bits that should be set in
> > MSR_IA32_FEATURE_CONTROL. If this file exists, SeaBIOS will set the
> > advised bits in that MSR.
> 
> Thanks - see my comments below.
> 
> > --- /dev/null
> > +++ b/src/fw/msr_feature_control.c
> > @@ -0,0 +1,16 @@
> > +#include "util.h" // msr_feature_control_setup, wrmsr_smp
> > +#include "romfile.h" // romfile_find
> > +
> > +#define MSR_IA32_FEATURE_CONTROL 0x003a
> > +
> > +void msr_feature_control_setup(void)
> > +{
> > +struct romfile_s *f = romfile_find("etc/msr_feature_control");
> > +if (!f)
> > +return;
> > +
> > +u64 feature_control_bits;
> > +f->copy(f, _control_bits, sizeof(feature_control_bits));
> > +if (feature_control_bits)
> > +wrmsr_smp(MSR_IA32_FEATURE_CONTROL, feature_control_bits);
> > +}
> 
> Can you use romfile_loadint() instead?  Something like:
> 
> u64 feature_control_bits = romfile_loadint("etc/msr_feature_control", 0);
> if (feature_control_bits)
> wrmsr_smp(MSR_IA32_FEATURE_CONTROL, feature_control_bits);
> 
> That should avoid the need for the separate romfile_find() call and it
> has the added benefit of additional sanity checks.
> 
> Also, I think this code is small enough it can be placed directly in
> paravirt.c and does not need its own c file.
>

I'll use romfile_loadint and place the code in paravirt.c in the next version.

Thanks,
Haozhong

Re: [Qemu-devel] [PATCH] powerpc/mm: Update the WIMG check during H_ENTER

[David Gibson]

On Fri, Jun 17, 2016 at 04:07:20PM +0530, Aneesh Kumar K.V wrote:
> Support for 0 value for memeory coherence is optional and with ppc64
> we can always enable memory coherence. Linux kernel did that during
> the development of 4.7 kernel. But that resulted in failure in Qemu
> in H_ENTER hcall due to below check. The mentioned change was reverted
> in the kernel and kernel right now enable memory coherence only if
> cache inhibited is not set. Nevertheless update qemu WIMG flag check
> to cover the case where we enable memory coherence along with cache
> inhibited flag.
> 
> In order to handle older and newer kernel version consider both Cache
> inhibitted and (cache inhibitted | memory conference) as valid values
> for wimg flags.
> 
> Signed-off-by: Aneesh Kumar K.V 

Applied to ppc-for-2.7

> ---
>  hw/ppc/spapr_hcall.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/hw/ppc/spapr_hcall.c b/hw/ppc/spapr_hcall.c
> index 2ba5cbdb194a..e011ed4b664b 100644
> --- a/hw/ppc/spapr_hcall.c
> +++ b/hw/ppc/spapr_hcall.c
> @@ -102,11 +102,15 @@ static target_ulong h_enter(PowerPCCPU *cpu, 
> sPAPRMachineState *spapr,
>  return H_PARAMETER;
>  }
>  } else {
> +target_ulong wimg_flags;
>  /* Looks like an IO address */
>  /* FIXME: What WIMG combinations could be sensible for IO?
>   * For now we allow WIMG=010x, but are there others? */
>  /* FIXME: Should we check against registered IO addresses? */
> -if ((ptel & (HPTE64_R_W | HPTE64_R_I | HPTE64_R_M)) != HPTE64_R_I) {
> +wimg_flags = (ptel & (HPTE64_R_W | HPTE64_R_I | HPTE64_R_M));
> +
> +if (wimg_flags != HPTE64_R_I &&
> +wimg_flags != (HPTE64_R_I | HPTE64_R_M)) {
>  return H_PARAMETER;
>  }
>  }

-- 
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] tests: Use '+=' to add additional tests, not '='

[David Gibson]

On Fri, Jun 17, 2016 at 03:16:17PM +0200, Thomas Huth wrote:
> The recent commit that added the prom-env-test accidentially
> overwrote the check-qtest-ppc-y, check-qtest-ppc64-y and
> check-qtest-sparc-y variables instead of extending them.
> 
> Fixes: fcbf4a3c0c576eec1321f9cff4fa0dd8e0b1a82f
> Signed-off-by: Thomas Huth 

Applied to ppc-for-2.7

> ---
>  tests/Makefile.include | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/tests/Makefile.include b/tests/Makefile.include
> index a2ed83b..fd2dba4 100644
> --- a/tests/Makefile.include
> +++ b/tests/Makefile.include
> @@ -259,11 +259,11 @@ check-qtest-ppc-y += tests/boot-order-test$(EXESUF)
>  check-qtest-ppc64-y += tests/boot-order-test$(EXESUF)
>  check-qtest-ppc64-y += tests/spapr-phb-test$(EXESUF)
>  gcov-files-ppc64-y += ppc64-softmmu/hw/ppc/spapr_pci.c
> -check-qtest-ppc-y = tests/prom-env-test$(EXESUF)
> -check-qtest-ppc64-y = tests/prom-env-test$(EXESUF)
> -check-qtest-sparc-y = tests/prom-env-test$(EXESUF)
> +check-qtest-ppc-y += tests/prom-env-test$(EXESUF)
> +check-qtest-ppc64-y += tests/prom-env-test$(EXESUF)
> +check-qtest-sparc-y += tests/prom-env-test$(EXESUF)
>  #Disabled for now, triggers a TCG bug on 32-bit hosts
> -#check-qtest-sparc64-y = tests/prom-env-test$(EXESUF)
> +#check-qtest-sparc64-y += tests/prom-env-test$(EXESUF)
>  check-qtest-microblazeel-y = $(check-qtest-microblaze-y)
>  check-qtest-xtensaeb-y = $(check-qtest-xtensa-y)
>  

-- 
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] ppc64: disable gen_pause() for linux-user mode

[David Gibson]

On Sun, Jun 19, 2016 at 09:19:24PM +0200, Laurent Vivier wrote:
> While trying to install a fedora container with
> "lxc-create -t fedora -- -I qemu-ppc64" the installation abort with
> the following error:
> 
> qemu: fatal: Unknown exception 0x65537. Aborting
> 
> NIP 004000927924   LR 0040009e325c CTR 004000927480 XER 
>  CPU#0
> MSR 900102806000 HID0   HF 92806000 iidx 3 didx 3
> TB 00248932 1069155773327487
> GPR00 0040009e325c 0040007ff800 004000aba098 
> GPR04 0040007ff878 004000dcb588 004000dcb830 004000a7a098
> GPR08   0040007ff878 004000927960
> GPR12 22022448 004000e2aef0  
> GPR16   0002 0001
> GPR20    004000800699
> GPR24 004000e13320  004000ac9ad8 004000ac9ae0
> GPR28 0001 100210a0  0038
> CR 22022442  [ E  E  -  E  E  G  G  E  ] RES 
> FPR00    
> FPR04    
> FPR08    
> FPR12    
> FPR16    
> FPR20    
> FPR24    
> FPR28    
> FPSCR 
> /usr/share/lxc/templates/lxc-fedora: line 487: 26661 Aborted 
> (core dumped) chroot . yum -y --nogpgcheck --installroot /run/install install 
> python rpm yum
> 
> I've bisected until the commit:
> 
> commit b68e60e6f0d2865e961a800fb8db96a7fc6494c4
> Author: Benjamin Herrenschmidt 
> Date:   Tue May 3 18:03:33 2016 +0200
> 
> ppc: Get out of emulation on SMT "OR" ops
> 
> Otherwise tight loops at smt_low for example, which OPAL does,
> eat so much CPU that we can't boot a kernel anymore. With that,
> I can boot 8 CPUs just fine with powernv.
> 
> Signed-off-by: Benjamin Herrenschmidt 
> Reviewed-by: David Gibson 
> Signed-off-by: David Gibson 
> 
> We can fix that by preventing to send EXCP_HLT in the case of linux-user mode,
> as the main loop doesn't know how to manage it.

Applied to ppc-for-2.7

> 
> Signed-off-by: Laurent Vivier 
> ---
>  target-ppc/translate.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/target-ppc/translate.c b/target-ppc/translate.c
> index 30dc76a..07b7e64 100644
> --- a/target-ppc/translate.c
> +++ b/target-ppc/translate.c
> @@ -1393,7 +1393,7 @@ GEN_LOGICAL2(nand, tcg_gen_nand_tl, 0x0E, PPC_INTEGER);
>  /* nor & nor. */
>  GEN_LOGICAL2(nor, tcg_gen_nor_tl, 0x03, PPC_INTEGER);
>  
> -#if defined(TARGET_PPC64)
> +#if defined(TARGET_PPC64) && !defined(CONFIG_USER_ONLY)
>  static void gen_pause(DisasContext *ctx)
>  {
>  TCGv_i32 t0 = tcg_const_i32(0);
> @@ -1481,7 +1481,9 @@ static void gen_or(DisasContext *ctx)
>  /* Pause us out of TCG otherwise spin loops with smt_low
>   * eat too much CPU and the kernel hangs
>   */
> +#if !defined(CONFIG_USER_ONLY)
>  gen_pause(ctx);
> +#endif
>  }
>  #endif
>  }

-- 
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 1/2] tcg: Fix name for high-half register

[David Gibson]

On Fri, Jun 17, 2016 at 10:03:26PM -0700, Richard Henderson wrote:
> Signed-off-by: Richard Henderson 
Reviewed-by: David Gibson 

> ---
>  tcg/tcg.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tcg/tcg.c b/tcg/tcg.c
> index 254427b..154ffe8 100644
> --- a/tcg/tcg.c
> +++ b/tcg/tcg.c
> @@ -557,7 +557,7 @@ int tcg_global_mem_new_internal(TCGType type, TCGv_ptr 
> base,
>  ts2->mem_offset = offset + (1 - bigendian) * 4;
>  pstrcpy(buf, sizeof(buf), name);
>  pstrcat(buf, sizeof(buf), "_1");
> -ts->name = strdup(buf);
> +ts2->name = strdup(buf);
>  } else {
>  ts->base_type = type;
>  ts->type = type;

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

[Qemu-devel] [RFC 6/8] linux-user: Support CPU work queue

[Sergey Fedorov]

From: Sergey Fedorov 

Make CPU work core functions common between system and user-mode
emulation. User-mode does not have BQL, so flush_queued_work() is
protected by 'exclusive_lock'.

Signed-off-by: Sergey Fedorov 
Signed-off-by: Sergey Fedorov 
---
 cpu-exec-common.c   | 83 ++
 cpus.c  | 87 ++---
 include/exec/exec-all.h |  4 +++
 linux-user/main.c   | 13 
 4 files changed, 102 insertions(+), 85 deletions(-)

diff --git a/cpu-exec-common.c b/cpu-exec-common.c
index 0cb4ae60eff9..8184e0662cbd 100644
--- a/cpu-exec-common.c
+++ b/cpu-exec-common.c
@@ -77,3 +77,86 @@ void cpu_loop_exit_restore(CPUState *cpu, uintptr_t pc)
 }
 siglongjmp(cpu->jmp_env, 1);
 }
+
+static void queue_work_on_cpu(CPUState *cpu, struct qemu_work_item *wi)
+{
+qemu_mutex_lock(>work_mutex);
+if (cpu->queued_work_first == NULL) {
+cpu->queued_work_first = wi;
+} else {
+cpu->queued_work_last->next = wi;
+}
+cpu->queued_work_last = wi;
+wi->next = NULL;
+wi->done = false;
+qemu_mutex_unlock(>work_mutex);
+
+qemu_cpu_kick(cpu);
+}
+
+void run_on_cpu(CPUState *cpu, run_on_cpu_func func, void *data)
+{
+struct qemu_work_item wi;
+
+if (qemu_cpu_is_self(cpu)) {
+func(cpu, data);
+return;
+}
+
+wi.func = func;
+wi.data = data;
+wi.free = false;
+
+queue_work_on_cpu(cpu, );
+while (!atomic_mb_read()) {
+CPUState *self_cpu = current_cpu;
+
+wait_cpu_work();
+current_cpu = self_cpu;
+}
+}
+
+void async_run_on_cpu(CPUState *cpu, run_on_cpu_func func, void *data)
+{
+struct qemu_work_item *wi;
+
+if (qemu_cpu_is_self(cpu)) {
+func(cpu, data);
+return;
+}
+
+wi = g_malloc0(sizeof(struct qemu_work_item));
+wi->func = func;
+wi->data = data;
+wi->free = true;
+
+queue_work_on_cpu(cpu, wi);
+}
+
+void flush_queued_work(CPUState *cpu)
+{
+struct qemu_work_item *wi;
+
+if (cpu->queued_work_first == NULL) {
+return;
+}
+
+qemu_mutex_lock(>work_mutex);
+while (cpu->queued_work_first != NULL) {
+wi = cpu->queued_work_first;
+cpu->queued_work_first = wi->next;
+if (!cpu->queued_work_first) {
+cpu->queued_work_last = NULL;
+}
+qemu_mutex_unlock(>work_mutex);
+wi->func(cpu, wi->data);
+qemu_mutex_lock(>work_mutex);
+if (wi->free) {
+g_free(wi);
+} else {
+atomic_mb_set(>done, true);
+}
+}
+qemu_mutex_unlock(>work_mutex);
+signal_cpu_work();
+}
diff --git a/cpus.c b/cpus.c
index f123eb707cc6..98f60f6f98f5 100644
--- a/cpus.c
+++ b/cpus.c
@@ -910,71 +910,16 @@ void qemu_init_cpu_loop(void)
 qemu_thread_get_self(_thread);
 }
 
-static void wait_cpu_work(void)
+void wait_cpu_work(void)
 {
 qemu_cond_wait(_work_cond, _global_mutex);
 }
 
-static void signal_cpu_work(void)
+void signal_cpu_work(void)
 {
 qemu_cond_broadcast(_work_cond);
 }
 
-static void queue_work_on_cpu(CPUState *cpu, struct qemu_work_item *wi)
-{
-qemu_mutex_lock(>work_mutex);
-if (cpu->queued_work_first == NULL) {
-cpu->queued_work_first = wi;
-} else {
-cpu->queued_work_last->next = wi;
-}
-cpu->queued_work_last = wi;
-wi->next = NULL;
-wi->done = false;
-qemu_mutex_unlock(>work_mutex);
-
-qemu_cpu_kick(cpu);
-}
-
-void run_on_cpu(CPUState *cpu, run_on_cpu_func func, void *data)
-{
-struct qemu_work_item wi;
-
-if (qemu_cpu_is_self(cpu)) {
-func(cpu, data);
-return;
-}
-
-wi.func = func;
-wi.data = data;
-wi.free = false;
-
-queue_work_on_cpu(cpu, );
-while (!atomic_mb_read()) {
-CPUState *self_cpu = current_cpu;
-
-wait_cpu_work();
-current_cpu = self_cpu;
-}
-}
-
-void async_run_on_cpu(CPUState *cpu, run_on_cpu_func func, void *data)
-{
-struct qemu_work_item *wi;
-
-if (qemu_cpu_is_self(cpu)) {
-func(cpu, data);
-return;
-}
-
-wi = g_malloc0(sizeof(struct qemu_work_item));
-wi->func = func;
-wi->data = data;
-wi->free = true;
-
-queue_work_on_cpu(cpu, wi);
-}
-
 static void qemu_kvm_destroy_vcpu(CPUState *cpu)
 {
 if (kvm_destroy_vcpu(cpu) < 0) {
@@ -987,34 +932,6 @@ static void qemu_tcg_destroy_vcpu(CPUState *cpu)
 {
 }
 
-static void flush_queued_work(CPUState *cpu)
-{
-struct qemu_work_item *wi;
-
-if (cpu->queued_work_first == NULL) {
-return;
-}
-
-qemu_mutex_lock(>work_mutex);
-while (cpu->queued_work_first != NULL) {
-wi = cpu->queued_work_first;
-cpu->queued_work_first = wi->next;
-if (!cpu->queued_work_first) {
-cpu->queued_work_last = NULL;
-}
-qemu_mutex_unlock(>work_mutex);
-

[Qemu-devel] [RFC 8/8] tcg: Make tb_flush() thread safe

[Sergey Fedorov]

From: Sergey Fedorov 

Use async_safe_run_on_cpu() to make tb_flush() thread safe.

Signed-off-by: Sergey Fedorov 
Signed-off-by: Sergey Fedorov 
---
 translate-all.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/translate-all.c b/translate-all.c
index 3f402dfe04f5..09b1d0b0efc3 100644
--- a/translate-all.c
+++ b/translate-all.c
@@ -832,7 +832,7 @@ static void page_flush_tb(void)
 
 /* flush all the translation blocks */
 /* XXX: tb_flush is currently not thread safe */
-void tb_flush(CPUState *cpu)
+static void do_tb_flush(CPUState *cpu, void *data)
 {
 #if defined(DEBUG_FLUSH)
 printf("qemu: flush code_size=%ld nb_tbs=%d avg_tb_size=%ld\n",
@@ -861,6 +861,11 @@ void tb_flush(CPUState *cpu)
 tcg_ctx.tb_ctx.tb_flush_count++;
 }
 
+void tb_flush(CPUState *cpu)
+{
+async_safe_run_on_cpu(cpu, do_tb_flush, NULL);
+}
+
 #ifdef DEBUG_TB_CHECK
 
 static void
@@ -1163,9 +1168,8 @@ TranslationBlock *tb_gen_code(CPUState *cpu,
  buffer_overflow:
 /* flush must be done */
 tb_flush(cpu);
-/* cannot fail at this point */
-tb = tb_alloc(pc);
-assert(tb != NULL);
+mmap_unlock();
+cpu_loop_exit(cpu);
 }
 
 gen_code_buf = tcg_ctx.code_gen_ptr;
-- 
1.9.1

Re: [Qemu-devel] [Qemu-ppc] [PATCH 01/10] ppc: Fix rfi/rfid/hrfi/... emulation

[Benjamin Herrenschmidt]

On Mon, 2016-06-20 at 08:15 +1000, Benjamin Herrenschmidt wrote:
> On Sun, 2016-06-19 at 19:21 +0200, Cédric Le Goater wrote:
> > But, I could not boot  ./darwinppc-602.cdr with on a 970. That
> > might
> > be another issue.
> 
> Right, the issue is that the kernel in Darwin 6.0.2 doesn't support
> the
> 970 :-)
> 
> I think the first MacOS X to support 970 was some special build of
> 10.2.8 or something along those lines, which is slightly after Darwin
> 6.0.2 was released.
> 
> Now that being said, Darwin 8.0.1 is also not booting in 970 and that
> is possible a real issue, but I don't think it's realted to those
> patches since that happens with current upstream7
> 
> I can look into it later (they both boot fine with a 7400).

Ok so Darwin uses some of the HSPRG etc... that we don't emulate on the
970 so I suspect it never worked. I've added them but something else
breaks, I'll dig, I have the kernel source so it shouldn't be too hard
;-)

Cheers,
Ben.

[Qemu-devel] [RFC 7/8] cpu-exec-common: Introduce async_safe_run_on_cpu()

[Sergey Fedorov]

From: Sergey Fedorov 

This patch is based on the ideas found in work of KONRAD Frederic [1],
Alex Bennée [2], and Alvise Rigo [3].

This mechanism allows to perform an operation safely in a quiescent
state. Quiescent state means: (1) no vCPU is running and (2) BQL in
system-mode or 'exclusive_lock' in user-mode emulation is held while
performing the operation. This functionality is required e.g. for
performing translation buffer flush safely in multi-threaded user-mode
emulation.

The existing CPU work queue is used to schedule such safe operations. A
new 'safe' flag is added into struct qemu_work_item to designate the
special requirements of the safe work. An operation in a quiescent sate
can be scheduled by using async_safe_run_on_cpu() function which is
actually the same as sync_run_on_cpu() except that it marks the queued
work item with the 'safe' flag set to true. Given this flag set
queue_work_on_cpu() atomically increments 'safe_work_pending' global
counter and kicks all the CPUs instead of just the target CPU as in case
of normal CPU work. This allows to force other CPUs to exit their
execution loops and wait in wait_safe_cpu_work() function for the safe
work to finish. When a CPU drains its work queue, if it encounters a
work item marked as safe, it first waits for other CPUs to exit their
execution loops, then called the work item function, and finally
decrements 'safe_work_pending' counter with signalling other CPUs to let
them continue execution as soon as all pending safe work items have been
processed. The 'tcg_pending_cpus' protected by 'exclusive_lock' in
user-mode or by 'qemu_global_mutex' in system-mode emulation is used to
determine if there is any CPU run and wait for it to exit the execution
loop. The fairness of all the CPU work queues is ensured by draining all
the pending safe work items before any CPU can run.

[1] http://lists.nongnu.org/archive/html/qemu-devel/2015-08/msg01128.html
[2] http://lists.nongnu.org/archive/html/qemu-devel/2016-04/msg02531.html
[3] http://lists.nongnu.org/archive/html/qemu-devel/2016-05/msg04792.html

Signed-off-by: Sergey Fedorov 
Signed-off-by: Sergey Fedorov 
---
 cpu-exec-common.c   | 45 -
 cpus.c  | 16 
 include/exec/exec-all.h |  2 ++
 include/qom/cpu.h   | 14 ++
 linux-user/main.c   |  2 +-
 5 files changed, 77 insertions(+), 2 deletions(-)

diff --git a/cpu-exec-common.c b/cpu-exec-common.c
index 8184e0662cbd..3056324738f8 100644
--- a/cpu-exec-common.c
+++ b/cpu-exec-common.c
@@ -25,6 +25,7 @@
 
 bool exit_request;
 CPUState *tcg_current_cpu;
+int tcg_pending_cpus;
 
 /* exit the current TB, but without causing any exception to be raised */
 void cpu_loop_exit_noexc(CPUState *cpu)
@@ -78,6 +79,15 @@ void cpu_loop_exit_restore(CPUState *cpu, uintptr_t pc)
 siglongjmp(cpu->jmp_env, 1);
 }
 
+static int safe_work_pending;
+
+void wait_safe_cpu_work(void)
+{
+while (atomic_mb_read(_work_pending) > 0) {
+wait_cpu_work();
+}
+}
+
 static void queue_work_on_cpu(CPUState *cpu, struct qemu_work_item *wi)
 {
 qemu_mutex_lock(>work_mutex);
@@ -89,9 +99,18 @@ static void queue_work_on_cpu(CPUState *cpu, struct 
qemu_work_item *wi)
 cpu->queued_work_last = wi;
 wi->next = NULL;
 wi->done = false;
+if (wi->safe) {
+atomic_inc(_work_pending);
+}
 qemu_mutex_unlock(>work_mutex);
 
-qemu_cpu_kick(cpu);
+if (!wi->safe) {
+qemu_cpu_kick(cpu);
+} else {
+CPU_FOREACH(cpu) {
+qemu_cpu_kick(cpu);
+}
+}
 }
 
 void run_on_cpu(CPUState *cpu, run_on_cpu_func func, void *data)
@@ -106,6 +125,7 @@ void run_on_cpu(CPUState *cpu, run_on_cpu_func func, void 
*data)
 wi.func = func;
 wi.data = data;
 wi.free = false;
+wi.safe = false;
 
 queue_work_on_cpu(cpu, );
 while (!atomic_mb_read()) {
@@ -129,6 +149,20 @@ void async_run_on_cpu(CPUState *cpu, run_on_cpu_func func, 
void *data)
 wi->func = func;
 wi->data = data;
 wi->free = true;
+wi->safe = false;
+
+queue_work_on_cpu(cpu, wi);
+}
+
+void async_safe_run_on_cpu(CPUState *cpu, run_on_cpu_func func, void *data)
+{
+struct qemu_work_item *wi;
+
+wi = g_malloc0(sizeof(struct qemu_work_item));
+wi->func = func;
+wi->data = data;
+wi->free = true;
+wi->safe = true;
 
 queue_work_on_cpu(cpu, wi);
 }
@@ -148,9 +182,18 @@ void flush_queued_work(CPUState *cpu)
 if (!cpu->queued_work_first) {
 cpu->queued_work_last = NULL;
 }
+if (wi->safe) {
+while (tcg_pending_cpus) {
+wait_cpu_work();
+}
+}
 qemu_mutex_unlock(>work_mutex);
 wi->func(cpu, wi->data);
 qemu_mutex_lock(>work_mutex);
+if (wi->safe) {
+atomic_dec(_work_pending);
+signal_cpu_work();
+  

[Qemu-devel] [RFC 2/8] cpus: Move common code out of {async_, }run_on_cpu()

[Sergey Fedorov]

From: Sergey Fedorov 

Move the code common between run_on_cpu() and async_run_on_cpu() into a
new function queue_work_on_cpu().

Signed-off-by: Sergey Fedorov 
Signed-off-by: Sergey Fedorov 
---
 cpus.c | 42 ++
 1 file changed, 18 insertions(+), 24 deletions(-)

diff --git a/cpus.c b/cpus.c
index 049c2d04e150..04687c85bcd4 100644
--- a/cpus.c
+++ b/cpus.c
@@ -910,6 +910,22 @@ void qemu_init_cpu_loop(void)
 qemu_thread_get_self(_thread);
 }
 
+static void queue_work_on_cpu(CPUState *cpu, struct qemu_work_item *wi)
+{
+qemu_mutex_lock(>work_mutex);
+if (cpu->queued_work_first == NULL) {
+cpu->queued_work_first = wi;
+} else {
+cpu->queued_work_last->next = wi;
+}
+cpu->queued_work_last = wi;
+wi->next = NULL;
+wi->done = false;
+qemu_mutex_unlock(>work_mutex);
+
+qemu_cpu_kick(cpu);
+}
+
 void run_on_cpu(CPUState *cpu, run_on_cpu_func func, void *data)
 {
 struct qemu_work_item wi;
@@ -923,18 +939,7 @@ void run_on_cpu(CPUState *cpu, run_on_cpu_func func, void 
*data)
 wi.data = data;
 wi.free = false;
 
-qemu_mutex_lock(>work_mutex);
-if (cpu->queued_work_first == NULL) {
-cpu->queued_work_first = 
-} else {
-cpu->queued_work_last->next = 
-}
-cpu->queued_work_last = 
-wi.next = NULL;
-wi.done = false;
-qemu_mutex_unlock(>work_mutex);
-
-qemu_cpu_kick(cpu);
+queue_work_on_cpu(cpu, );
 while (!atomic_mb_read()) {
 CPUState *self_cpu = current_cpu;
 
@@ -957,18 +962,7 @@ void async_run_on_cpu(CPUState *cpu, run_on_cpu_func func, 
void *data)
 wi->data = data;
 wi->free = true;
 
-qemu_mutex_lock(>work_mutex);
-if (cpu->queued_work_first == NULL) {
-cpu->queued_work_first = wi;
-} else {
-cpu->queued_work_last->next = wi;
-}
-cpu->queued_work_last = wi;
-wi->next = NULL;
-wi->done = false;
-qemu_mutex_unlock(>work_mutex);
-
-qemu_cpu_kick(cpu);
+queue_work_on_cpu(cpu, wi);
 }
 
 static void qemu_kvm_destroy_vcpu(CPUState *cpu)
-- 
1.9.1

[Qemu-devel] [RFC 3/8] cpus: Add 'qemu_work_cond' usage wrappers

[Sergey Fedorov]

From: Sergey Fedorov 

Introducing these wrappers is a step towards CPU work support in
user-mode emulation.

Signed-off-by: Sergey Fedorov 
Signed-off-by: Sergey Fedorov 
---
 cpus.c | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/cpus.c b/cpus.c
index 04687c85bcd4..f123eb707cc6 100644
--- a/cpus.c
+++ b/cpus.c
@@ -910,6 +910,16 @@ void qemu_init_cpu_loop(void)
 qemu_thread_get_self(_thread);
 }
 
+static void wait_cpu_work(void)
+{
+qemu_cond_wait(_work_cond, _global_mutex);
+}
+
+static void signal_cpu_work(void)
+{
+qemu_cond_broadcast(_work_cond);
+}
+
 static void queue_work_on_cpu(CPUState *cpu, struct qemu_work_item *wi)
 {
 qemu_mutex_lock(>work_mutex);
@@ -943,7 +953,7 @@ void run_on_cpu(CPUState *cpu, run_on_cpu_func func, void 
*data)
 while (!atomic_mb_read()) {
 CPUState *self_cpu = current_cpu;
 
-qemu_cond_wait(_work_cond, _global_mutex);
+wait_cpu_work();
 current_cpu = self_cpu;
 }
 }
@@ -1002,7 +1012,7 @@ static void flush_queued_work(CPUState *cpu)
 }
 }
 qemu_mutex_unlock(>work_mutex);
-qemu_cond_broadcast(_work_cond);
+signal_cpu_work();
 }
 
 static void qemu_wait_io_event_common(CPUState *cpu)
-- 
1.9.1

[Qemu-devel] [RFC 4/8] linux-user: Rework exclusive operation mechanism

[Sergey Fedorov]

From: Sergey Fedorov 

A single variable 'pending_cpus' was used for both counting currently
running CPUs and for signalling the pending exclusive operation request.

To prepare for supporting operations which requires a quiescent state,
like translation buffer flush, it is useful to keep a counter of
currently running CPUs always up to date.

Use a separate variable 'tcg_pending_cpus' to count for currently
running CPUs and a separate variable 'exclusive_pending' to indicate
that there's an exclusive operation pending.

Signed-off-by: Sergey Fedorov 
Signed-off-by: Sergey Fedorov 
---
 linux-user/main.c | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/linux-user/main.c b/linux-user/main.c
index b9a4e0ea45ac..485336f78b8f 100644
--- a/linux-user/main.c
+++ b/linux-user/main.c
@@ -111,7 +111,8 @@ static pthread_mutex_t cpu_list_mutex = 
PTHREAD_MUTEX_INITIALIZER;
 static pthread_mutex_t exclusive_lock = PTHREAD_MUTEX_INITIALIZER;
 static pthread_cond_t exclusive_cond = PTHREAD_COND_INITIALIZER;
 static pthread_cond_t exclusive_resume = PTHREAD_COND_INITIALIZER;
-static int pending_cpus;
+static bool exclusive_pending;
+static int tcg_pending_cpus;
 
 /* Make sure everything is in a consistent state for calling fork().  */
 void fork_start(void)
@@ -133,7 +134,8 @@ void fork_end(int child)
 QTAILQ_REMOVE(, cpu, node);
 }
 }
-pending_cpus = 0;
+tcg_pending_cpus = 0;
+exclusive_pending = false;
 pthread_mutex_init(_lock, NULL);
 pthread_mutex_init(_list_mutex, NULL);
 pthread_cond_init(_cond, NULL);
@@ -150,7 +152,7 @@ void fork_end(int child)
must be held.  */
 static inline void exclusive_idle(void)
 {
-while (pending_cpus) {
+while (exclusive_pending) {
 pthread_cond_wait(_resume, _lock);
 }
 }
@@ -164,15 +166,14 @@ static inline void start_exclusive(void)
 pthread_mutex_lock(_lock);
 exclusive_idle();
 
-pending_cpus = 1;
+exclusive_pending = true;
 /* Make all other cpus stop executing.  */
 CPU_FOREACH(other_cpu) {
 if (other_cpu->running) {
-pending_cpus++;
 cpu_exit(other_cpu);
 }
 }
-if (pending_cpus > 1) {
+while (tcg_pending_cpus) {
 pthread_cond_wait(_cond, _lock);
 }
 }
@@ -180,7 +181,7 @@ static inline void start_exclusive(void)
 /* Finish an exclusive operation.  */
 static inline void __attribute__((unused)) end_exclusive(void)
 {
-pending_cpus = 0;
+exclusive_pending = false;
 pthread_cond_broadcast(_resume);
 pthread_mutex_unlock(_lock);
 }
@@ -191,6 +192,7 @@ static inline void cpu_exec_start(CPUState *cpu)
 pthread_mutex_lock(_lock);
 exclusive_idle();
 cpu->running = true;
+tcg_pending_cpus++;
 pthread_mutex_unlock(_lock);
 }
 
@@ -199,11 +201,9 @@ static inline void cpu_exec_end(CPUState *cpu)
 {
 pthread_mutex_lock(_lock);
 cpu->running = false;
-if (pending_cpus > 1) {
-pending_cpus--;
-if (pending_cpus == 1) {
-pthread_cond_signal(_cond);
-}
+tcg_pending_cpus--;
+if (!tcg_pending_cpus) {
+pthread_cond_broadcast(_cond);
 }
 exclusive_idle();
 pthread_mutex_unlock(_lock);
-- 
1.9.1

[Qemu-devel] [RFC 5/8] linux-user: Add qemu_cpu_is_self() and qemu_cpu_kick()

[Sergey Fedorov]

From: Sergey Fedorov 

Signed-off-by: Sergey Fedorov 
Signed-off-by: Sergey Fedorov 
---
 linux-user/main.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/linux-user/main.c b/linux-user/main.c
index 485336f78b8f..0093a8008c8e 100644
--- a/linux-user/main.c
+++ b/linux-user/main.c
@@ -3775,6 +3775,16 @@ void cpu_loop(CPUTLGState *env)
 
 THREAD CPUState *thread_cpu;
 
+bool qemu_cpu_is_self(CPUState *cpu)
+{
+return thread_cpu == cpu;
+}
+
+void qemu_cpu_kick(CPUState *cpu)
+{
+cpu_exit(cpu);
+}
+
 void task_settid(TaskState *ts)
 {
 if (ts->ts_tid == 0) {
-- 
1.9.1

[Qemu-devel] [RFC 0/8] cpu-exec: Safe work in quiescent state

[Sergey Fedorov]

From: Sergey Fedorov 

Hi,

This RFC series is a follow-up for a discussion on the subject [1].

Basically, this series is intended to show a possible way to perform
operations on quiescent state, so that we can discuss if it a sane way
to do this. The goal is to implement such a mechanism which can be used
for safe translation buffer flush in multi-threaded user-mode emulation
(and later in MTTCG) and merge it into mainline in v2.7.

I tried to keep this series as small as possible so that would be easier
to focus on the main idea. Thus bsd-user part was simply skipped here.
Please note that this is just a kind of "proof of concept" series and
needs to be polished and refined.

The patch 1 is just a useful tweak from Alex's MTTCG tree, please don't
comment on it here if possible.

The patches 2 through 5 are arrangements for the patch 7 which adds
support for CPU work in linux-user. This wouldn't make any sense without
the patch 8 which is the subject matter of this series. Although there
is nothing special to do in case of single-threaded round-robin CPU loop
of current system-mode emulation to ensure quiescent state, that is
shown in the patch 7, how it would look like in MTTCG. The last patch
actually employs this new mechanism making translation buffer flush
thread safe.

Again for brevity, the considerations on expensiveness of work item
dynamic allocation [2] was not taken into account. I'll just mention
here that the desired effect can be achieved by either using dynamic
arrays for CPU work queues or making queue_work_on_cpu() from the
patch 2 a public interface thus allowing to use preallocated work items.

I would like your comments in order to produce something upstreamable
quickly!

This series is available at a public git repository:

https://github.com/sergefdrv/qemu.git safe-cpu-work

Kind regards,
Sergey

[1] http://thread.gmane.org/gmane.comp.emulators.qemu/417599
[2] http://thread.gmane.org/gmane.comp.emulators.qemu/407030/focus=407039

Alex Bennée (1):
  cpus: pass CPUState to run_on_cpu helpers

Sergey Fedorov (7):
  cpus: Move common code out of {async_,}run_on_cpu()
  cpus: Add 'qemu_work_cond' usage wrappers
  linux-user: Rework exclusive operation mechanism
  linux-user: Add qemu_cpu_is_self() and qemu_cpu_kick()
  linux-user: Support CPU work queue
  cpu-exec-common: Introduce async_safe_run_on_cpu()
  tcg: Make tb_flush() thread safe

 cpu-exec-common.c   | 126 
 cpus.c  |  98 +++--
 hw/i386/kvm/apic.c  |   3 +-
 hw/i386/kvmvapic.c  |   8 +--
 hw/ppc/ppce500_spin.c   |   3 +-
 hw/ppc/spapr.c  |   6 +--
 hw/ppc/spapr_hcall.c|  12 ++---
 include/exec/exec-all.h |   6 +++
 include/qom/cpu.h   |  22 +++--
 kvm-all.c   |  20 +++-
 linux-user/main.c   |  47 +-
 target-i386/helper.c|   3 +-
 target-i386/kvm.c   |   6 +--
 target-s390x/cpu.c  |   4 +-
 target-s390x/cpu.h  |   7 +--
 translate-all.c |  12 +++--
 16 files changed, 238 insertions(+), 145 deletions(-)

-- 
1.9.1

[Qemu-devel] [RFC 1/8] cpus: pass CPUState to run_on_cpu helpers

[Sergey Fedorov]

From: Alex Bennée 

CPUState is a fairly common pointer to pass to these helpers. This means
if you need other arguments for the async_run_on_cpu case you end up
having to do a g_malloc to stuff additional data into the routine. For
the current users this isn't a massive deal but for MTTCG this gets
cumbersome when the only other parameter is often an address.

This adds the typedef run_on_cpu_func for helper functions which has an
explicit CPUState * passed as the first parameter. All the users of
run_on_cpu and async_run_on_cpu have had their helpers updated to use
CPUState where available.

Signed-off-by: Alex Bennée 
Signed-off-by: Sergey Fedorov 
---
 cpus.c| 15 +++
 hw/i386/kvm/apic.c|  3 +--
 hw/i386/kvmvapic.c|  8 
 hw/ppc/ppce500_spin.c |  3 +--
 hw/ppc/spapr.c|  6 ++
 hw/ppc/spapr_hcall.c  | 12 +---
 include/qom/cpu.h |  8 +---
 kvm-all.c | 20 +++-
 target-i386/helper.c  |  3 +--
 target-i386/kvm.c |  6 ++
 target-s390x/cpu.c|  4 ++--
 target-s390x/cpu.h|  7 ++-
 12 files changed, 39 insertions(+), 56 deletions(-)

diff --git a/cpus.c b/cpus.c
index 84c3520d446f..049c2d04e150 100644
--- a/cpus.c
+++ b/cpus.c
@@ -551,9 +551,8 @@ static const VMStateDescription vmstate_timers = {
 }
 };
 
-static void cpu_throttle_thread(void *opaque)
+static void cpu_throttle_thread(CPUState *cpu, void *opaque)
 {
-CPUState *cpu = opaque;
 double pct;
 double throttle_ratio;
 long sleeptime_ns;
@@ -583,7 +582,7 @@ static void cpu_throttle_timer_tick(void *opaque)
 }
 CPU_FOREACH(cpu) {
 if (!atomic_xchg(>throttle_thread_scheduled, 1)) {
-async_run_on_cpu(cpu, cpu_throttle_thread, cpu);
+async_run_on_cpu(cpu, cpu_throttle_thread, NULL);
 }
 }
 
@@ -911,12 +910,12 @@ void qemu_init_cpu_loop(void)
 qemu_thread_get_self(_thread);
 }
 
-void run_on_cpu(CPUState *cpu, void (*func)(void *data), void *data)
+void run_on_cpu(CPUState *cpu, run_on_cpu_func func, void *data)
 {
 struct qemu_work_item wi;
 
 if (qemu_cpu_is_self(cpu)) {
-func(data);
+func(cpu, data);
 return;
 }
 
@@ -944,12 +943,12 @@ void run_on_cpu(CPUState *cpu, void (*func)(void *data), 
void *data)
 }
 }
 
-void async_run_on_cpu(CPUState *cpu, void (*func)(void *data), void *data)
+void async_run_on_cpu(CPUState *cpu, run_on_cpu_func func, void *data)
 {
 struct qemu_work_item *wi;
 
 if (qemu_cpu_is_self(cpu)) {
-func(data);
+func(cpu, data);
 return;
 }
 
@@ -1000,7 +999,7 @@ static void flush_queued_work(CPUState *cpu)
 cpu->queued_work_last = NULL;
 }
 qemu_mutex_unlock(>work_mutex);
-wi->func(wi->data);
+wi->func(cpu, wi->data);
 qemu_mutex_lock(>work_mutex);
 if (wi->free) {
 g_free(wi);
diff --git a/hw/i386/kvm/apic.c b/hw/i386/kvm/apic.c
index c5983c79be47..9b66e741d4b4 100644
--- a/hw/i386/kvm/apic.c
+++ b/hw/i386/kvm/apic.c
@@ -125,10 +125,9 @@ static void kvm_apic_vapic_base_update(APICCommonState *s)
 }
 }
 
-static void do_inject_external_nmi(void *data)
+static void do_inject_external_nmi(CPUState *cpu, void *data)
 {
 APICCommonState *s = data;
-CPUState *cpu = CPU(s->cpu);
 uint32_t lvt;
 int ret;
 
diff --git a/hw/i386/kvmvapic.c b/hw/i386/kvmvapic.c
index 3bf1ddd97612..8063d695312e 100644
--- a/hw/i386/kvmvapic.c
+++ b/hw/i386/kvmvapic.c
@@ -483,7 +483,7 @@ typedef struct VAPICEnableTPRReporting {
 bool enable;
 } VAPICEnableTPRReporting;
 
-static void vapic_do_enable_tpr_reporting(void *data)
+static void vapic_do_enable_tpr_reporting(CPUState *cpu, void *data)
 {
 VAPICEnableTPRReporting *info = data;
 
@@ -734,15 +734,15 @@ static void vapic_realize(DeviceState *dev, Error **errp)
 nb_option_roms++;
 }
 
-static void do_vapic_enable(void *data)
+static void do_vapic_enable(CPUState *cpu, void *data)
 {
 VAPICROMState *s = data;
-X86CPU *cpu = X86_CPU(first_cpu);
+X86CPU *x86_cpu = X86_CPU(cpu);
 
 static const uint8_t enabled = 1;
 cpu_physical_memory_write(s->vapic_paddr + offsetof(VAPICState, enabled),
   , sizeof(enabled));
-apic_enable_vapic(cpu->apic_state, s->vapic_paddr);
+apic_enable_vapic(x86_cpu->apic_state, s->vapic_paddr);
 s->state = VAPIC_ACTIVE;
 }
 
diff --git a/hw/ppc/ppce500_spin.c b/hw/ppc/ppce500_spin.c
index 76bd78bfd7a6..e2aeef3701ec 100644
--- a/hw/ppc/ppce500_spin.c
+++ b/hw/ppc/ppce500_spin.c
@@ -94,10 +94,9 @@ static void mmubooke_create_initial_mapping(CPUPPCState *env,
 env->tlb_dirty = true;
 }
 
-static void spin_kick(void *data)
+static void spin_kick(CPUState *cpu, void *data)
 {
 SpinKick *kick = data;
-CPUState *cpu = CPU(kick->cpu);
 CPUPPCState *env = >cpu->env;
 SpinInfo 

Re: [Qemu-devel] [Qemu-ppc] [PATCH 01/10] ppc: Fix rfi/rfid/hrfi/... emulation

[Benjamin Herrenschmidt]

On Sun, 2016-06-19 at 19:21 +0200, Cédric Le Goater wrote:
> But, I could not boot  ./darwinppc-602.cdr with on a 970. That might
> be another issue.

Right, the issue is that the kernel in Darwin 6.0.2 doesn't support the
970 :-)

I think the first MacOS X to support 970 was some special build of
10.2.8 or something along those lines, which is slightly after Darwin
6.0.2 was released.

Now that being said, Darwin 8.0.1 is also not booting in 970 and that
is possible a real issue, but I don't think it's realted to those
patches since that happens with current upstream7

I can look into it later (they both boot fine with a 7400).

Cheers,
Ben.

[Qemu-devel] [PATCH] ppc: Improve emulation of THRM registers

[Programmingkid]

On Jun 19, 2016, at 12:12 AM, qemu-devel-requ...@nongnu.org wrote:

> Message: 5
> Date: Sun, 19 Jun 2016 10:54:13 +1000
> From: Benjamin Herrenschmidt 
> To: qemu-...@nongnu.org
> Cc: qemu-devel@nongnu.org, da...@gibson.dropbear.id.au, Mark
>   Cave-Ayland , Alexander Graf
>   
> Subject: [Qemu-devel] [PATCH] ppc: Improve emulation of THRM registers
> Message-ID: <1466297653.24271.101.ca...@kernel.crashing.org>
> Content-Type: text/plain; charset="UTF-8"
> 
> The 75x and 74xx processors have some thermal monitoring SPRs that
> some OSes such as MacOS do use. Our current "dumb" implementation
> isn't good enough and will cause some versions of MacOS to hang during
> boot.
> 
> This lifts an improved emulation from MacOnLinux and adapts it to
> qemu, thus fixing the problem.
> 
> Signed-off-by: Benjamin Herrenschmidt 
> ---
> target-ppc/helper.h |  1 +
> target-ppc/misc_helper.c| 41 +
> target-ppc/translate_init.c | 13 ++---
> 3 files changed, 52 insertions(+), 3 deletions(-)
> 
> diff --git a/target-ppc/helper.h b/target-ppc/helper.h
> index f4410a8..18eb52f 100644
> --- a/target-ppc/helper.h
> +++ b/target-ppc/helper.h
> @@ -670,3 +670,4 @@ DEF_HELPER_4(dscli, void, env, fprp, fprp, i32)
> DEF_HELPER_4(dscliq, void, env, fprp, fprp, i32)
> 
> DEF_HELPER_1(tbegin, void, env)
> +DEF_HELPER_1(fixup_thrm, void, env)
> diff --git a/target-ppc/misc_helper.c b/target-ppc/misc_helper.c
> index 7d41b01..4315778 100644
> --- a/target-ppc/misc_helper.c
> +++ b/target-ppc/misc_helper.c
> @@ -166,3 +166,44 @@ void ppc_store_msr(CPUPPCState *env, target_ulong value)
> {
> hreg_store_msr(env, value, 0);
> }
> +
> +/* This code is lifted from MacOnLinux. It is called whenever
> + * THRM1,2 or 3 is read an fixes up the values in such a way
> + * that will mac MacOS not hang. These registers exist on some
> + * 75x and 74xx processors.
> + */
> +void helper_fixup_thrm(CPUPPCState *env)
> +{
> +target_ulong v, t;
> +int i;
> +
> +#define THRM1_TIN   (1 << 31)
> +#define THRM1_TIV   (1 << 30)
> +#define THRM1_THRES(x)  ((x&0x7f)<<23)
> +#define THRM1_TID   (1<<2)
> +#define THRM1_TIE   (1<<1)
> +#define THRM1_V (1<<0)
> +#define THRM3_E (1<<0)
> +
> +if(!(env->spr[SPR_THRM3] & THRM3_E)) {
> +return;
> +}
> +
> +/* Note: Thermal interrupts are unimplemented */
> +for (i=SPR_THRM1 ; i<= SPR_THRM2 ; i++) {
> +v = env->spr[i];
> +if (!(v & THRM1_V)) {
> +continue;
> +}
> +v |= THRM1_TIV;
> +v &= ~THRM1_TIN;
> +t = v & THRM1_THRES(127);
> +if ((v & THRM1_TID) && t < THRM1_THRES(24)) {
> +v |= THRM1_TIN;
> +}
> +if (!(v & THRM1_TID) && t > THRM1_THRES(24)) {
> +v |= THRM1_TIN;
> +}
> +env->spr[i] = v;
> +}
> +}
> diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c
> index ca894ff..0f18abf 100644
> --- a/target-ppc/translate_init.c
> +++ b/target-ppc/translate_init.c
> @@ -1179,23 +1179,30 @@ static void gen_spr_amr(CPUPPCState *env, bool 
> has_iamr)
> }
> #endif /* TARGET_PPC64 */
> 
> +static void spr_read_thrm(DisasContext *ctx, int gprn, int sprn)
> +{
> +gen_helper_fixup_thrm(cpu_env);
> +gen_load_spr(cpu_gpr[gprn], sprn);
> +spr_load_dump_spr(sprn);
> +}
> +
> static void gen_spr_thrm (CPUPPCState *env)
> {
> /* Thermal management */
> /* XXX : not implemented */
> spr_register(env, SPR_THRM1, "THRM1",
>  SPR_NOACCESS, SPR_NOACCESS,
> - _read_generic, _write_generic,
> + _read_thrm, _write_generic,
>  0x);
> /* XXX : not implemented */
> spr_register(env, SPR_THRM2, "THRM2",
>  SPR_NOACCESS, SPR_NOACCESS,
> - _read_generic, _write_generic,
> + _read_thrm, _write_generic,
>  0x);
> /* XXX : not implemented */
> spr_register(env, SPR_THRM3, "THRM3",
>  SPR_NOACCESS, SPR_NOACCESS,
> - _read_generic, _write_generic,
> + _read_thrm, _write_generic,
>  0x);
> }
> 


I have test this patch using Mac OS 10.2.8, Mac OS 10.4.0, and Mac OS 9.2.2. 
They all worked. Mac OS 9.2.2 successfully booted with the multiprocessing 
folder in the Extensions folder. 

Excellent job.

Reviewed-by: John Arbuckle 

Re: [Qemu-devel] kvm_arch_put_registers and xsave

[Alex Bligh]

On 19 Jun 2016, at 21:54, Peter Maydell  wrote:

> The purpose of the get/put functions, broadly, is "copy
> state from the hypervisor into QEMU's cpu state struct
> and vice-versa". The specific details are down to KVM's ABI
> (and to historical details like some KVM ioctls being newer
> or optional). For a from-scratch hypervisor I think all
> you need to do is copy the state from env->regs,
> env->xmm_regs, etc etc into the hypervisor and back,
> however is best suited to the hypervisor's APIs.

Thanks.

Hypervisor.framework provides register by register access:

https://developer.apple.com/library/mac/documentation/Hypervisor/Reference/Hypervisor_Reference/index.html#//apple_ref/doc/uid/TP40016756-CH2-DontLinkElementID_22

so I guess I should do that with every register, and ignore the explicit xsave 
support.

XMM registers and FPState (for instance) appear to be in an opaque format:

https://developer.apple.com/library/mac/documentation/Hypervisor/Reference/Hypervisor_Reference/index.html#//apple_ref/c/func/hv_vcpu_read_fpstate

-- 
Alex Bligh

[Qemu-devel] [Bug 1585008] Re: Windows 7 guests hang on bootup when qxl video is used

[Anthony de Beus]

and doesn't exist in qemu-2.5.1-1; the next version I have in Arch is
qemu-2.6.0-1, which is the current one where the problem exists.  So,
something changed between 2.5 and 2.6

Sorry about the multiple posts.

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

Title:
  Windows 7 guests hang on bootup when qxl video is used

Status in QEMU:
  New
Status in qemu package in Ubuntu:
  Confirmed

Bug description:
  I installed libvirt-bin and virt-manager on Ubuntu 16.04.  I created a
  new VM for Windows 7, basically with default settings, which includes
  qxl video..  The Windows boot process hangs with the "Starting
  Windows" animation.  CPU and disk I/O drop to zero, and it continues
  animating forever and ever...  It never finishes booting.  But it
  doesn't fully "hang" either: the animation continues to animate.

  As a workaround, I set the video mode to "Cirrus" and then Windows
  boots but it is slow and limited.  And also apparently to be avoided:

  https://www.kraxel.org/blog/2014/10/qemu-using-cirrus-considered-
  harmful/

  I can confirm it's only when qxl is enabled, because if I switch from
  Cirrus back to qxl, it hangs again - and going back to Cirrus again
  "fixes" the problem.

  This issue is also reported elsewhere:

  http://serverfault.com/questions/776406/windows-7-setup-hangs-at-
  starting-windows-using-proxmox-4-2

  https://forum.proxmox.com/threads/win7-setup-hangs-in-proxmox-
  ve-4-2.27388/

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

[Qemu-devel] [Bug 1585008] Re: Windows 7 guests hang on bootup when qxl video is used

[Anthony de Beus]

Downgraded to qemu-2.4.0-1 (on Arch), problem doesn't exist there.

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

Title:
  Windows 7 guests hang on bootup when qxl video is used

Status in QEMU:
  New
Status in qemu package in Ubuntu:
  Confirmed

Bug description:
  I installed libvirt-bin and virt-manager on Ubuntu 16.04.  I created a
  new VM for Windows 7, basically with default settings, which includes
  qxl video..  The Windows boot process hangs with the "Starting
  Windows" animation.  CPU and disk I/O drop to zero, and it continues
  animating forever and ever...  It never finishes booting.  But it
  doesn't fully "hang" either: the animation continues to animate.

  As a workaround, I set the video mode to "Cirrus" and then Windows
  boots but it is slow and limited.  And also apparently to be avoided:

  https://www.kraxel.org/blog/2014/10/qemu-using-cirrus-considered-
  harmful/

  I can confirm it's only when qxl is enabled, because if I switch from
  Cirrus back to qxl, it hangs again - and going back to Cirrus again
  "fixes" the problem.

  This issue is also reported elsewhere:

  http://serverfault.com/questions/776406/windows-7-setup-hangs-at-
  starting-windows-using-proxmox-4-2

  https://forum.proxmox.com/threads/win7-setup-hangs-in-proxmox-
  ve-4-2.27388/

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

Re: [Qemu-devel] [Qemu-ppc] [PATCH 01/10] ppc: Fix rfi/rfid/hrfi/... emulation

[Benjamin Herrenschmidt]

On Sun, 2016-06-19 at 19:23 +0200, Cédric Le Goater wrote:
> > You can run a 32-bit OS or firmware on ppc64, but it needs to know that
> > it's running on a 64-bit chip and do a few things differently.
> 
> yes sure but qemu would still allow rfi under 64bit CPUs, that is what 
> I was concerned about. Is that ok ? 

Why ? A real CPU won't allow it, why should we ?

Cheers,
Ben.

[Qemu-devel] KVM VM hangs forever in R state within lock

[Andrey Korolyov]

Hi,

I`ve observed this issue previously on an old 3.10 branch but wrote it
off due to inability to reproduce in any meaningful way. Currently I
am seeing it on 3.10 branch where all KVM-related and RCU-related
issues are patched more or less for well-known issues.

Way to obtain a problematic state:
 - run a hypervisor for essentially long time, it took a year and half
previously for issue to come on the mentioned old branch, but for
newer kernel and probably due to higher load it took roughly a half of
a year,
 - suddenly a single VM obtains a lock and became unresponsive while
all threads displaying Running state, under this lock VM is neither
not killable via SIGKILL and not freezeable via freezer cgroup, the
only obvious symptoms is that it does not consume any cpu cycles
anymore (no counter inside sched info ) and of course it is
non-debuggable anymore. As it follows, it is quite impossible to say
at a glance where lock sits, as there is no distinctive processes
which are at least sleeping and could be moved out of sight.

It looks like I could have met pure scheduler issue, so if nothing
from attached recursive stack/status dump would click on an idea, I`d
CC scheduler folks. Timer/RCU configs are attached for the
convenience.

Thanks for looking into this!

stack:
http://xdel.ru/downloads/vm-sched-hang/stack.txt
status:
http://xdel.ru/downloads/vm-sched-hang/status.txt
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ_COMMON=y
# CONFIG_HZ_PERIODIC is not set
CONFIG_NO_HZ_IDLE=y
# CONFIG_NO_HZ_FULL is not set
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y

# RCU Subsystem
CONFIG_TREE_RCU=y
# CONFIG_PREEMPT_RCU is not set
CONFIG_RCU_STALL_COMMON=y
CONFIG_RCU_USER_QS=y
CONFIG_RCU_FANOUT=64
CONFIG_RCU_FANOUT_LEAF=16
# CONFIG_RCU_FANOUT_EXACT is not set
# CONFIG_RCU_FAST_NO_HZ is not set
# CONFIG_TREE_RCU_TRACE is not set
CONFIG_RCU_NOCB_CPU=y
# CONFIG_RCU_NOCB_CPU_NONE is not set
# CONFIG_RCU_NOCB_CPU_ZERO is not set
CONFIG_RCU_NOCB_CPU_ALL=y
# RCU Debugging
# CONFIG_SPARSE_RCU_POINTER is not set
# CONFIG_RCU_TORTURE_TEST is not set
CONFIG_RCU_CPU_STALL_TIMEOUT=21
# CONFIG_RCU_CPU_STALL_INFO is not set
# CONFIG_RCU_TRACE is not set

Re: [Qemu-devel] [PATCH] ppc: Improve emulation of THRM registers

[Benjamin Herrenschmidt]

On Sun, 2016-06-19 at 11:09 -0400, G 3 wrote:
>   On 6/19/16 12:12 AM, qemu-devel-requ...@nongnu.org wrote:
> > Message: 5
> > Date: Sun, 19 Jun 2016 10:54:13 +1000
> > From: Benjamin Herrenschmidt
> > To:qemu-...@nongnu.org
> > Cc:qemu-devel@nongnu.org,da...@gibson.dropbear.id.au, Mark
> > Cave-Ayland , Alexander
> > Graf
> > 
> > Subject: [Qemu-devel] [PATCH] ppc: Improve emulation of THRM
> > registers
> > Message-ID:<1466297653.24271.101.ca...@kernel.crashing.org>
> > Content-Type: text/plain; charset="UTF-8"
> > 
> > The 75x and 74xx processors have some thermal monitoring SPRs that
> > some OSes such as MacOS do use. Our current "dumb" implementation
> > isn't good enough and will cause some versions of MacOS to hang
> > during
> > boot.
> > 
> > This lifts an improved emulation from MacOnLinux and adapts it to
> > qemu, thus fixing the problem.
> > 
> Which versions of the Mac OS hang?

The Apple CPU Plugin in 9.2.x afaik (well 9.2.2 for sure).

Cheers,
Ben.

Re: [Qemu-devel] kvm_arch_put_registers and xsave

[Peter Maydell]

On 19 June 2016 at 20:36, Alex Bligh  wrote:
> Looking at kvm_arch_put_registers it appears to be pretty complicated.
> It appears to 'put' each individual register type, as well as putting
> an xsave region. I'm a bit confused why the ordinary registers 'put'
> are not then overwritten by the xsave put.
>
> Assuming I am only targeting processors supporting XSAVE (which I
> believe is reasonable given what Macs support Hypervisor.Framework),
> is there a reason I shouldn't merely XRSTOR (by writing the
> XSAVE region with the appropriate hv_ call) and ignore all the
> other register futzing? Or is it more complicated than that
> because (presumably) something sets up register states in the
> cpu->regs, cpu->sregs areas? I'm a bit confused as to how all
> this works to be honest. Any ideas / docs to point to?

The purpose of the get/put functions, broadly, is "copy
state from the hypervisor into QEMU's cpu state struct
and vice-versa". The specific details are down to KVM's ABI
(and to historical details like some KVM ioctls being newer
or optional). For a from-scratch hypervisor I think all
you need to do is copy the state from env->regs,
env->xmm_regs, etc etc into the hypervisor and back,
however is best suited to the hypervisor's APIs.

thanks
-- PMM

[Qemu-devel] kvm_arch_put_registers and xsave

[Alex Bligh]

I'm still plugging away at my Hypervisor.Framework port (now rewritten
to be another accelerator like kvm).

It appears to be setting up memory regions, and I'm now working on
the equivalent of kvm_cpu_exec. I see an exit code 33 on the first
call, which is an invalid VMCS. This is unsurprising as I haven't
yet implemented the equivalent of kvm_arch_put_registers so the
register contents will presumably be illegal.

Looking at kvm_arch_put_registers it appears to be pretty complicated.
It appears to 'put' each individual register type, as well as putting
an xsave region. I'm a bit confused why the ordinary registers 'put'
are not then overwritten by the xsave put.

Assuming I am only targeting processors supporting XSAVE (which I
believe is reasonable given what Macs support Hypervisor.Framework),
is there a reason I shouldn't merely XRSTOR (by writing the
XSAVE region with the appropriate hv_ call) and ignore all the
other register futzing? Or is it more complicated than that
because (presumably) something sets up register states in the
cpu->regs, cpu->sregs areas? I'm a bit confused as to how all
this works to be honest. Any ideas / docs to point to?

-- 
Alex Bligh

[Qemu-devel] [PATCH] ppc64: disable gen_pause() for linux-user mode

[Laurent Vivier]

While trying to install a fedora container with
"lxc-create -t fedora -- -I qemu-ppc64" the installation abort with
the following error:

qemu: fatal: Unknown exception 0x65537. Aborting

NIP 004000927924   LR 0040009e325c CTR 004000927480 XER 
 CPU#0
MSR 900102806000 HID0   HF 92806000 iidx 3 didx 3
TB 00248932 1069155773327487
GPR00 0040009e325c 0040007ff800 004000aba098 
GPR04 0040007ff878 004000dcb588 004000dcb830 004000a7a098
GPR08   0040007ff878 004000927960
GPR12 22022448 004000e2aef0  
GPR16   0002 0001
GPR20    004000800699
GPR24 004000e13320  004000ac9ad8 004000ac9ae0
GPR28 0001 100210a0  0038
CR 22022442  [ E  E  -  E  E  G  G  E  ] RES 
FPR00    
FPR04    
FPR08    
FPR12    
FPR16    
FPR20    
FPR24    
FPR28    
FPSCR 
/usr/share/lxc/templates/lxc-fedora: line 487: 26661 Aborted 
(core dumped) chroot . yum -y --nogpgcheck --installroot /run/install install 
python rpm yum

I've bisected until the commit:

commit b68e60e6f0d2865e961a800fb8db96a7fc6494c4
Author: Benjamin Herrenschmidt 
Date:   Tue May 3 18:03:33 2016 +0200

ppc: Get out of emulation on SMT "OR" ops

Otherwise tight loops at smt_low for example, which OPAL does,
eat so much CPU that we can't boot a kernel anymore. With that,
I can boot 8 CPUs just fine with powernv.

Signed-off-by: Benjamin Herrenschmidt 
Reviewed-by: David Gibson 
Signed-off-by: David Gibson 

We can fix that by preventing to send EXCP_HLT in the case of linux-user mode,
as the main loop doesn't know how to manage it.

Signed-off-by: Laurent Vivier 
---
 target-ppc/translate.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/target-ppc/translate.c b/target-ppc/translate.c
index 30dc76a..07b7e64 100644
--- a/target-ppc/translate.c
+++ b/target-ppc/translate.c
@@ -1393,7 +1393,7 @@ GEN_LOGICAL2(nand, tcg_gen_nand_tl, 0x0E, PPC_INTEGER);
 /* nor & nor. */
 GEN_LOGICAL2(nor, tcg_gen_nor_tl, 0x03, PPC_INTEGER);
 
-#if defined(TARGET_PPC64)
+#if defined(TARGET_PPC64) && !defined(CONFIG_USER_ONLY)
 static void gen_pause(DisasContext *ctx)
 {
 TCGv_i32 t0 = tcg_const_i32(0);
@@ -1481,7 +1481,9 @@ static void gen_or(DisasContext *ctx)
 /* Pause us out of TCG otherwise spin loops with smt_low
  * eat too much CPU and the kernel hangs
  */
+#if !defined(CONFIG_USER_ONLY)
 gen_pause(ctx);
+#endif
 }
 #endif
 }
-- 
2.5.5

Re: [Qemu-devel] [PATCH v8 00/12] 8bit AVR cores

[Richard Henderson]

On 06/19/2016 10:50 AM, Michael Rolnik wrote:

it did compile for me.
how do you compile? what machine?


Fedora 23, gcc 5.3.1.


r~

Re: [Qemu-devel] [PATCH 2/7] QEMU does not currently support host pages that are larger than guest pages, likely due to glibc using fixed mmap requests.

[Richard Henderson]

On 06/19/2016 02:46 AM, Peter Maydell wrote:

On 19 June 2016 at 01:11, Timothy Pearson
 wrote:

Attempting to use host pages larger than the guest leads to
alignment errors during ELF load in the best case, and an
initialization failure inside NPTL in the worst case, causing
all fork() requests inside the guest to fail.

Warn when thread space cannot be set up, and suggest reducing
host page size if applicable.


This is supposed to work -- for instance the linux-user/mmap.c
code has support for host pages and target pages not being the same.
In particular for ARM guests TARGET_PAGE_SIZE is 1K but the
host page size is 4K, so the config of "host page larger than
guest" isn't untested.


You're right, it isn't untested, it's completely broken.

The arm 1k example isn't really realistic, because the actual arm kernel doles 
out 4k units, and that's what userspace was built to expect.  Try running i386 
on aarch64 (or ppc64) with a 64k page kernel.  Maps fail very very quickly.


This is one of the reasons why I think there's no way to do such emulation 
without softmmu for linux-user.



r~

Re: [Qemu-devel] [PATCH v8 00/12] 8bit AVR cores

[Michael Rolnik]

I am building on MAC.
I just do
./configure --target-list=avr-softmmu
build

no errors

On Sun, Jun 19, 2016 at 8:50 PM, Michael Rolnik  wrote:

> it did compile for me.
> how do you compile? what machine?
>
> On Sun, Jun 19, 2016 at 8:45 PM, Richard Henderson 
> wrote:
>
>> On 06/18/2016 12:55 PM, Michael Rolnik wrote:
>>
>>> This series of patches adds 8bit AVR cores to QEMU.
>>> All instruction, except BREAK/DES/SPM/SPMX, are implemented. Not fully
>>> tested yet.
>>> However I was able to execute simple code with functions. e.g fibonacci
>>> calculation.
>>> This series of patches include a non real, sample board.
>>> No fuses support yet. PC is set to 0 at reset.
>>>
>>> the patches include the following
>>> 1. just a basic 8bit AVR CPU, without instruction decoding or translation
>>> 2. CPU features which allow define the following 8bit AVR cores
>>>  avr1
>>>  avr2 avr25
>>>  avr3 avr31 avr35
>>>  avr4
>>>  avr5 avr51
>>>  avr6
>>>  xmega2 xmega4 xmega5 xmega6 xmega7
>>> 3. a definition of sample machine with SRAM, FLASH and CPU which allows
>>> to execute simple code
>>> 4. encoding for all AVR instructions
>>> 5. interrupt handling
>>> 6. helpers for IN, OUT, SLEEP, WBR & unsupported instructions
>>> 7. a decoder which given an opcode decides what istruction it is
>>> 8. translation of AVR instruction into TCG
>>> 9. all features together
>>>
>>> changes since v3
>>> 1. rampD/X/Y/Z registers are encoded as 0x00ff (instead of
>>> 0x00ff) for faster address manipulaton
>>> 2. ffs changed to ctz32
>>> 3. duplicate code removed at avr_cpu_do_interrupt
>>> 4. using andc instead of not + and
>>> 5. fixing V flag calculation in varios instructions
>>> 6. freeing local variables in PUSH
>>> 7. tcg_const_local_i32 -> tcg_const_i32
>>> 8. using sextract32 instead of my implementation
>>> 9. fixing BLD instruction
>>> 10.xor(r) instead of 0xff - r at COM
>>> 11.fixing MULS/MULSU not to modify inputs' content
>>> 12.using SUB for NEG
>>> 13.fixing tcg_gen_qemu_ld/st call in XCH
>>>
>>> changes since v4
>>> 1. target is now defined as big endian in order to optimize
>>> push_ret/pop_ret
>>> 2. all style warnings are fixed
>>> 3. adding cpu_set/get_sreg functions
>>> 4. simplifying gen_goto_tb as there is no real paging
>>> 5. env->pc -> env->pc_w
>>> 6. making flag dump more compact
>>> 7. more spacing
>>> 8. renaming CODE/DATA_INDEX -> MMU_CODE/DATA_IDX
>>> 9. removing avr_set_feature
>>> 10. SPL/SPH set bug fix
>>> 11. switching stb_phys to cpu_stb_data
>>> 12. cleaning up avr_decode
>>> 13. saving sreg, rampD/X/Y/Z, eind in HW format (savevm)
>>> 14. saving CPU features (savevm)
>>>
>>> changes since v5
>>> 1. BLD bug fix
>>> 2. decoder generator is added
>>>
>>> chages since v6
>>> 1. using cpu_get_sreg/cpu_set_sreg in
>>> avr_cpu_gdb_read_register/avr_cpu_gdb_write_register
>>> 2. configure the target as little endian because otherwise GDB does not
>>> work
>>> 3. fixing and testing gen_push_ret/gen_pop_ret
>>>
>>> changes since v7
>>> 1. folding back v6
>>> 2. logging at helper_outb and helper_inb are done for non supported yet
>>> registers only
>>> 3. MAINTAINERS updated
>>>
>>
>> Problems:
>>
>> (1) This doesn't compile.
>>
>>  qemu/hw/avr/sample.c:66:13: error: variable ‘cpu_avr’ set but not used
>> [-Werror=unused-but-set-variable]
>>  qemu/hw/avr/sample-io.c:121:30: error: comparison of unsigned expression
>> >= 0 is always true [-Werror=type-limits]
>>  qemu/hw/avr/sample-io.c:148:30: error: comparison of unsigned expression
>> >= 0 is always true [-Werror=type-limits]
>>  qemu/target-avr/translate-inst.c:199:6: error: old-style function
>> definition [-Werror=old-style-definition]
>>  qemu/target-avr/translate-inst.c:206:6: error: old-style function
>> definition [-Werror=old-style-definition]
>>  qemu/target-avr/translate-inst.c:248:6: error: old-style function
>> definition [-Werror=old-style-definition]
>>  qemu/target-avr/translate-inst.c:253:6: error: old-style function
>> definition [-Werror=old-style-definition]
>>  qemu/target-avr/translate-inst.c:258:6: error: old-style function
>> definition [-Werror=old-style-definition]
>>  qemu/include/migration/qemu-file.h:204:5: error: ‘temp’ is used
>> uninitialized in this function [-Werror=uninitialized]
>>
>> The last is particularly egregious since the code is completely broken.
>>
>> (2) There are still patches not folded back into the originals.
>> (3) There are still unheeded changes that were asked for in v4 with
>> respect to the sample-io device, and the simulator board.
>>
>>
>> r~
>>
>
>
>
> --
> Best Regards,
> Michael Rolnik
>



-- 
Best Regards,
Michael Rolnik

Re: [Qemu-devel] [PATCH v8 00/12] 8bit AVR cores

[Michael Rolnik]

it did compile for me.
how do you compile? what machine?

On Sun, Jun 19, 2016 at 8:45 PM, Richard Henderson  wrote:

> On 06/18/2016 12:55 PM, Michael Rolnik wrote:
>
>> This series of patches adds 8bit AVR cores to QEMU.
>> All instruction, except BREAK/DES/SPM/SPMX, are implemented. Not fully
>> tested yet.
>> However I was able to execute simple code with functions. e.g fibonacci
>> calculation.
>> This series of patches include a non real, sample board.
>> No fuses support yet. PC is set to 0 at reset.
>>
>> the patches include the following
>> 1. just a basic 8bit AVR CPU, without instruction decoding or translation
>> 2. CPU features which allow define the following 8bit AVR cores
>>  avr1
>>  avr2 avr25
>>  avr3 avr31 avr35
>>  avr4
>>  avr5 avr51
>>  avr6
>>  xmega2 xmega4 xmega5 xmega6 xmega7
>> 3. a definition of sample machine with SRAM, FLASH and CPU which allows
>> to execute simple code
>> 4. encoding for all AVR instructions
>> 5. interrupt handling
>> 6. helpers for IN, OUT, SLEEP, WBR & unsupported instructions
>> 7. a decoder which given an opcode decides what istruction it is
>> 8. translation of AVR instruction into TCG
>> 9. all features together
>>
>> changes since v3
>> 1. rampD/X/Y/Z registers are encoded as 0x00ff (instead of
>> 0x00ff) for faster address manipulaton
>> 2. ffs changed to ctz32
>> 3. duplicate code removed at avr_cpu_do_interrupt
>> 4. using andc instead of not + and
>> 5. fixing V flag calculation in varios instructions
>> 6. freeing local variables in PUSH
>> 7. tcg_const_local_i32 -> tcg_const_i32
>> 8. using sextract32 instead of my implementation
>> 9. fixing BLD instruction
>> 10.xor(r) instead of 0xff - r at COM
>> 11.fixing MULS/MULSU not to modify inputs' content
>> 12.using SUB for NEG
>> 13.fixing tcg_gen_qemu_ld/st call in XCH
>>
>> changes since v4
>> 1. target is now defined as big endian in order to optimize
>> push_ret/pop_ret
>> 2. all style warnings are fixed
>> 3. adding cpu_set/get_sreg functions
>> 4. simplifying gen_goto_tb as there is no real paging
>> 5. env->pc -> env->pc_w
>> 6. making flag dump more compact
>> 7. more spacing
>> 8. renaming CODE/DATA_INDEX -> MMU_CODE/DATA_IDX
>> 9. removing avr_set_feature
>> 10. SPL/SPH set bug fix
>> 11. switching stb_phys to cpu_stb_data
>> 12. cleaning up avr_decode
>> 13. saving sreg, rampD/X/Y/Z, eind in HW format (savevm)
>> 14. saving CPU features (savevm)
>>
>> changes since v5
>> 1. BLD bug fix
>> 2. decoder generator is added
>>
>> chages since v6
>> 1. using cpu_get_sreg/cpu_set_sreg in
>> avr_cpu_gdb_read_register/avr_cpu_gdb_write_register
>> 2. configure the target as little endian because otherwise GDB does not
>> work
>> 3. fixing and testing gen_push_ret/gen_pop_ret
>>
>> changes since v7
>> 1. folding back v6
>> 2. logging at helper_outb and helper_inb are done for non supported yet
>> registers only
>> 3. MAINTAINERS updated
>>
>
> Problems:
>
> (1) This doesn't compile.
>
>  qemu/hw/avr/sample.c:66:13: error: variable ‘cpu_avr’ set but not used
> [-Werror=unused-but-set-variable]
>  qemu/hw/avr/sample-io.c:121:30: error: comparison of unsigned expression
> >= 0 is always true [-Werror=type-limits]
>  qemu/hw/avr/sample-io.c:148:30: error: comparison of unsigned expression
> >= 0 is always true [-Werror=type-limits]
>  qemu/target-avr/translate-inst.c:199:6: error: old-style function
> definition [-Werror=old-style-definition]
>  qemu/target-avr/translate-inst.c:206:6: error: old-style function
> definition [-Werror=old-style-definition]
>  qemu/target-avr/translate-inst.c:248:6: error: old-style function
> definition [-Werror=old-style-definition]
>  qemu/target-avr/translate-inst.c:253:6: error: old-style function
> definition [-Werror=old-style-definition]
>  qemu/target-avr/translate-inst.c:258:6: error: old-style function
> definition [-Werror=old-style-definition]
>  qemu/include/migration/qemu-file.h:204:5: error: ‘temp’ is used
> uninitialized in this function [-Werror=uninitialized]
>
> The last is particularly egregious since the code is completely broken.
>
> (2) There are still patches not folded back into the originals.
> (3) There are still unheeded changes that were asked for in v4 with
> respect to the sample-io device, and the simulator board.
>
>
> r~
>



-- 
Best Regards,
Michael Rolnik

[Qemu-devel] [Bug 1585008] Re: Windows 7 guests hang on bootup when qxl video is used

[Serge Hallyn]

Thanks.

** Also 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/1585008

Title:
  Windows 7 guests hang on bootup when qxl video is used

Status in QEMU:
  New
Status in qemu package in Ubuntu:
  Confirmed

Bug description:
  I installed libvirt-bin and virt-manager on Ubuntu 16.04.  I created a
  new VM for Windows 7, basically with default settings, which includes
  qxl video..  The Windows boot process hangs with the "Starting
  Windows" animation.  CPU and disk I/O drop to zero, and it continues
  animating forever and ever...  It never finishes booting.  But it
  doesn't fully "hang" either: the animation continues to animate.

  As a workaround, I set the video mode to "Cirrus" and then Windows
  boots but it is slow and limited.  And also apparently to be avoided:

  https://www.kraxel.org/blog/2014/10/qemu-using-cirrus-considered-
  harmful/

  I can confirm it's only when qxl is enabled, because if I switch from
  Cirrus back to qxl, it hangs again - and going back to Cirrus again
  "fixes" the problem.

  This issue is also reported elsewhere:

  http://serverfault.com/questions/776406/windows-7-setup-hangs-at-
  starting-windows-using-proxmox-4-2

  https://forum.proxmox.com/threads/win7-setup-hangs-in-proxmox-
  ve-4-2.27388/

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

Re: [Qemu-devel] [PATCH v8 00/12] 8bit AVR cores

[Richard Henderson]

On 06/18/2016 12:55 PM, Michael Rolnik wrote:

This series of patches adds 8bit AVR cores to QEMU.
All instruction, except BREAK/DES/SPM/SPMX, are implemented. Not fully tested 
yet.
However I was able to execute simple code with functions. e.g fibonacci 
calculation.
This series of patches include a non real, sample board.
No fuses support yet. PC is set to 0 at reset.

the patches include the following
1. just a basic 8bit AVR CPU, without instruction decoding or translation
2. CPU features which allow define the following 8bit AVR cores
 avr1
 avr2 avr25
 avr3 avr31 avr35
 avr4
 avr5 avr51
 avr6
 xmega2 xmega4 xmega5 xmega6 xmega7
3. a definition of sample machine with SRAM, FLASH and CPU which allows to 
execute simple code
4. encoding for all AVR instructions
5. interrupt handling
6. helpers for IN, OUT, SLEEP, WBR & unsupported instructions
7. a decoder which given an opcode decides what istruction it is
8. translation of AVR instruction into TCG
9. all features together

changes since v3
1. rampD/X/Y/Z registers are encoded as 0x00ff (instead of 0x00ff) for 
faster address manipulaton
2. ffs changed to ctz32
3. duplicate code removed at avr_cpu_do_interrupt
4. using andc instead of not + and
5. fixing V flag calculation in varios instructions
6. freeing local variables in PUSH
7. tcg_const_local_i32 -> tcg_const_i32
8. using sextract32 instead of my implementation
9. fixing BLD instruction
10.xor(r) instead of 0xff - r at COM
11.fixing MULS/MULSU not to modify inputs' content
12.using SUB for NEG
13.fixing tcg_gen_qemu_ld/st call in XCH

changes since v4
1. target is now defined as big endian in order to optimize push_ret/pop_ret
2. all style warnings are fixed
3. adding cpu_set/get_sreg functions
4. simplifying gen_goto_tb as there is no real paging
5. env->pc -> env->pc_w
6. making flag dump more compact
7. more spacing
8. renaming CODE/DATA_INDEX -> MMU_CODE/DATA_IDX
9. removing avr_set_feature
10. SPL/SPH set bug fix
11. switching stb_phys to cpu_stb_data
12. cleaning up avr_decode
13. saving sreg, rampD/X/Y/Z, eind in HW format (savevm)
14. saving CPU features (savevm)

changes since v5
1. BLD bug fix
2. decoder generator is added

chages since v6
1. using cpu_get_sreg/cpu_set_sreg in 
avr_cpu_gdb_read_register/avr_cpu_gdb_write_register
2. configure the target as little endian because otherwise GDB does not work
3. fixing and testing gen_push_ret/gen_pop_ret

changes since v7
1. folding back v6
2. logging at helper_outb and helper_inb are done for non supported yet 
registers only
3. MAINTAINERS updated


Problems:

(1) This doesn't compile.

 qemu/hw/avr/sample.c:66:13: error: variable ‘cpu_avr’ set but not used 
[-Werror=unused-but-set-variable]
 qemu/hw/avr/sample-io.c:121:30: error: comparison of unsigned expression >= 0 
is always true [-Werror=type-limits]
 qemu/hw/avr/sample-io.c:148:30: error: comparison of unsigned expression >= 0 
is always true [-Werror=type-limits]
 qemu/target-avr/translate-inst.c:199:6: error: old-style function definition 
[-Werror=old-style-definition]
 qemu/target-avr/translate-inst.c:206:6: error: old-style function definition 
[-Werror=old-style-definition]
 qemu/target-avr/translate-inst.c:248:6: error: old-style function definition 
[-Werror=old-style-definition]
 qemu/target-avr/translate-inst.c:253:6: error: old-style function definition 
[-Werror=old-style-definition]
 qemu/target-avr/translate-inst.c:258:6: error: old-style function definition 
[-Werror=old-style-definition]
 qemu/include/migration/qemu-file.h:204:5: error: ‘temp’ is used uninitialized 
in this function [-Werror=uninitialized]


The last is particularly egregious since the code is completely broken.

(2) There are still patches not folded back into the originals.
(3) There are still unheeded changes that were asked for in v4 with respect to 
the sample-io device, and the simulator board.



r~

Re: [Qemu-devel] [PATCH v2] ppc / sparc: Add a tester for checking whether OpenBIOS runs successfully

[Richard Henderson]

On 06/19/2016 08:26 AM, Artyom Tarasenko wrote:

On Fri, Jun 17, 2016 at 3:56 PM, Mark Cave-Ayland
 wrote:

Since the mac99 and g3beige PowerPC machines recently broke without
being noticed, it would be good to have a tester for "make check"
that detects such issues immediately. A simple way to test the firmware
of these machines is to use the "-prom-env" parameter of QEMU. This
parameter can be used to put some Forth code into the 'boot-command'
firmware variable which then can signal success to the tester by
writing a magic value to a known memory location. And since some of the
Sparc machines are also using OpenBIOS, they are now tested with this
prom-env-tester, too.

Reviewed-by: Markus Armbruster 
Signed-off-by: Thomas Huth 
---
 v2: Removed unnecessary include statements (as suggested by Markus)


Beautiful, I've applied this to ppc-for-2.7, assuming I don't get an
objection to taking this through my tree.


Ugh.. turns out this fails on sparc64 target on a 32-bit x86 host.
Specifically it trips the tcg_abort() at the end of tcg_reg_alloc()
(tcg/tcg.c).

I'm reasonably confident this is a pre-existing bug, just triggered by
this test, but in the interests of getting this up and running on the
platforms where it is working, I've disabled the testcase on sparc64
for now.

Mark, if you could debug the sparc64-on-i386 failure at some point,
that would be helpful.


I'm a little tied up until next week, however I was able to reproduce on
a local i386 VM and get a stack trace:


$ gdb --args ./qemu-system-sparc64 -nographic
GNU gdb (Debian 7.10-1.1) 7.10
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./qemu-system-sparc64...done.
(gdb) r
Starting program: /home/build/rel-qemu-git/bin/qemu-system-sparc64
-nographic
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
[New Thread 0xb7989b40 (LWP 27497)]
[New Thread 0xb4af1b40 (LWP 27498)]
OpenBIOS for Sparc64
Configuration device id QEMU version 1 machine id 0
kernel cmdline
CPUs: 1 x SUNW,UltraSPARC-IIi
UUID: ----
/home/build/src/qemu/tcg/tcg.c:1743: tcg fatal error

Program received signal SIGABRT, Aborted.
[Switching to Thread 0xb4af1b40 (LWP 27498)]
0xb7fdadad in __kernel_vsyscall ()
(gdb) bt
#0  0xb7fdadad in __kernel_vsyscall ()
#1  0xb7a2ee26 in __GI_raise (sig=6) at
../sysdeps/unix/sysv/linux/raise.c:55
#2  0xb7a303f7 in __GI_abort () at abort.c:89
#3  0x08061776 in tcg_reg_alloc (s=0x8637780 ,
desired_regs=255, allocated_regs=255, rev=true) at
/home/build/src/qemu/tcg/tcg.c:1743
#4  0x0806181a in temp_load (s=0x8637780 , ts=0x8637978
, desired_regs=255, allocated_regs=255) at
/home/build/src/qemu/tcg/tcg.c:1762
#5  0x080615e0 in tcg_reg_sync (s=0x8637780 , reg=TCG_REG_EAX,
allocated_regs=255) at /home/build/src/qemu/tcg/tcg.c:1694
#6  0x08061653 in tcg_reg_free (s=0x8637780 , reg=TCG_REG_EAX,
allocated_regs=254) at /home/build/src/qemu/tcg/tcg.c:1709
#7  0x08061740 in tcg_reg_alloc (s=0x8637780 ,
desired_regs=255, allocated_regs=254, rev=true) at
/home/build/src/qemu/tcg/tcg.c:1738
#8  0x0806181a in temp_load (s=0x8637780 , ts=0x8637978
, desired_regs=255, allocated_regs=254) at
/home/build/src/qemu/tcg/tcg.c:1762
#9  0x080615e0 in tcg_reg_sync (s=0x8637780 , reg=TCG_REG_ECX,
allocated_regs=254) at /home/build/src/qemu/tcg/tcg.c:1694
#10 0x08061653 in tcg_reg_free (s=0x8637780 , reg=TCG_REG_ECX,
allocated_regs=252) at /home/build/src/qemu/tcg/tcg.c:1709
#11 0x08061740 in tcg_reg_alloc (s=0x8637780 ,
desired_regs=255, allocated_regs=252, rev=true) at
/home/build/src/qemu/tcg/tcg.c:1738
#12 0x0806181a in temp_load (s=0x8637780 , ts=0x8637978
, desired_regs=255, allocated_regs=252) at
/home/build/src/qemu/tcg/tcg.c:1762
#13 0x08061858 in temp_load (s=0x8637780 , ts=0x8637f48
, desired_regs=255, allocated_regs=252) at
/home/build/src/qemu/tcg/tcg.c:1765
#14 0x0806220f in tcg_reg_alloc_op (s=0x8637780 , def=0x859c150
, opc=INDEX_op_sub2_i32, args=0x863be54
, dead_args=60, sync_args=0 '\000') at
/home/build/src/qemu/tcg/tcg.c:2050
#15 0x08063156 in tcg_gen_code (s=0x8637780 , tb=0xb4b14d90) at
/home/build/src/qemu/tcg/tcg.c:2454
#16 0x08058cb4 in 

Re: [Qemu-devel] [Qemu-ppc] [PATCH 01/10] ppc: Fix rfi/rfid/hrfi/... emulation

[Cédric Le Goater]

On 06/19/2016 04:08 PM, Benjamin Herrenschmidt wrote:
> On Sun, 2016-06-19 at 14:49 +0200, Cédric Le Goater wrote:
>>> So my test is correct in the context of what we emulate today.
>>
>> OK. so this is an openbios issue when run under a ppc64. shouldn't we 
>> be using an openbios-ppc64 in that case ?  
>>
>>
>> We could be more strict with the rfi instruction. 
> 
> Well, ppc64 isn't backward compatible with ppc32 at the supervisor
> level, at least not on server chips (it is on bookE chips). So yes it's
> an OpenBIOS problem but that doesn't mean we have to use openbios-ppc64 
> :-) 
> 
> You can run a 32-bit OS or firmware on ppc64, but it needs to know that
> it's running on a 64-bit chip and do a few things differently.

yes sure but qemu would still allow rfi under 64bit CPUs, that is what 
I was concerned about. Is that ok ? 

C.

Re: [Qemu-devel] [Qemu-ppc] [PATCH 01/10] ppc: Fix rfi/rfid/hrfi/... emulation

[Cédric Le Goater]

On 06/19/2016 03:00 PM, Alexander Graf wrote:
> 
> 
>> Am 19.06.2016 um 14:49 schrieb Cédric Le Goater :
>>
>>> On 06/19/2016 01:35 AM, Benjamin Herrenschmidt wrote:
 On Fri, 2016-06-17 at 16:32 +0200, Cédric Le Goater wrote:
 The instruction set PPC_POWER_BR contains nearly all the deleted 
 instructions from isa2. rfi is not part of it and should. Also, only 
 the cpus "PowerPC 601*" make a use of it in their insns_flags.
>>>
>>> Are you sure those arent the old POWER instructions as in pre-powerPC
>>> architecture that 601 (and only 601) supports ?
>>
>> OK. I get it now.  
>>
>> All the deleted instructions from POWER are/should be under the set 
>> PPC_POWER.
>>
>> All the deleted instructions from POWER2 are under the set PPC_POWER2.
>>
>> None of these sets are in use.
>>
>>
>> For the  "PowerPC 601*" cpus, we moved a couple from set PPC_POWER to 
>> subset PPC_POWER_BR.
>>
>> rfi is special. it is under PPC_FLOW and all CPUs can use it
>>
 So, we would want this set to be in all the "PowerPC {6,7}*" cpus. 
 Are there more ?
>>>
>>> All 32-bit hash based CPUs are arch 1.x and support rfi
>>>
>>> All 64-bit hash based CPUs we support (ie, POWER4 and later) are
>>> architecture 2.x and later.
>>>
>>> So my test is correct in the context of what we emulate today.
>>
>> OK. so this is an openbios issue when run under a ppc64. shouldn't we 
>> be using an openbios-ppc64 in that case ?  
> 
> No, openbios can run on both. Just add a runtime check in openbios for 
> rfi/rfid.


OK. 

How's that for a start ? Seems to work. 

But, I could not boot  ./darwinppc-602.cdr with on a 970. That might
be another issue.

Thanks,

C.

From: Cédric Le Goater 
Subject: [PATCH] ppc: use rfid when running under a CPU from the 970 family.
Date: Sun, 19 Jun 2016 15:48:41 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Signed-off-by: Cédric Le Goater 
---
 arch/ppc/qemu/start.S |   15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

Index: openbios.git/arch/ppc/qemu/start.S
===
--- openbios.git.orig/arch/ppc/qemu/start.S
+++ openbios.git/arch/ppc/qemu/start.S
@@ -148,7 +148,20 @@
ll  r31,(35 * ULONG_SIZE)(r1) ; \
 .endif ; \
ll  r1,(1 * ULONG_SIZE)(r1) ;   /* restore stack at last */ \
-   rfi
+   mtsprg1 r3 ; \
+   mfpvr r3 ; \
+   rlwinm  r3,r3,16,16,31 ; \
+   cmplwi  cr1,r3,0x0039 ; /* 970 CPUs */ \
+   beq- cr1,0f ; \
+   cmplwi  cr1,r3,0x003C ; /* 970fx CPUs */ \
+   beq- cr1,0f ; \
+   cmplwi  cr1,r3,0x0044 ; /* 970mp CPUs */ \
+   beq- cr1,0f ; \
+   mfsprg1 r3 ; \
+   rfi ; \
+0: ; \
+   mfsprg1 r3 ; \
+   rfid
 
 // PPC32
 

Re: [Qemu-devel] [PATCH 10/10] machine: Skip global registration for non-existing classes

[Marcel Apfelbaum]

On 06/19/2016 07:39 PM, Marcel Apfelbaum wrote:

On 06/15/2016 11:32 PM, Eduardo Habkost wrote:

MachineClass::compat_props may point to class names that are not
compiled into the QEMU binary. Skip registering those as global
properties. This will allow the qdev global property code to
implement stricter checks on the global property values in the
future.

Signed-off-by: Eduardo Habkost 
---
  hw/core/machine.c | 9 +
  1 file changed, 9 insertions(+)

diff --git a/hw/core/machine.c b/hw/core/machine.c
index d6f6be4..51697cb 100644
--- a/hw/core/machine.c
+++ b/hw/core/machine.c
@@ -583,6 +583,7 @@ static void machine_class_finalize(ObjectClass *klass, void 
*data)
  void machine_register_compat_props(MachineState *machine)
  {
  MachineClass *mc = MACHINE_GET_CLASS(machine);
+ObjectClass *oc;
  int i;
  GlobalProperty *p;

@@ -592,6 +593,14 @@ void machine_register_compat_props(MachineState *machine)

  for (i = 0; i < mc->compat_props->len; i++) {
  p = g_array_index(mc->compat_props, GlobalProperty *, i);


Hi Eduardo,


+
+/* Skip registering globals for non-existing device classes */
+oc = object_class_by_name(p->driver);


This I understand. It ensure a corresponding class is in QEMU binary.
But even so, if such property is not available should we silently continue?
Maybe the user things the property is set...


Please forgive the spelling errors and disregard the above question.





+oc = object_class_dynamic_cast(oc, TYPE_DEVICE);


This I don't understand. Do we check here?



Regarding my last question, it seems you followed an existing pattern
here, however I don't quite understand, we found the class,
why do we need to ensure is a TYPE_DEVICE?

What error case do we want to prevent?

Thanks,
Marcel


Thanks,
Marcel


+if (!oc) {
+continue;
+}
+
  /* Machine compat_props must never cause errors: */
  p->errp = _abort;
  qdev_prop_register_global(p);

Re: [Qemu-devel] [PATCH 01/10] qdev: Don't stop applying globals on first error

[Marcel Apfelbaum]

On 06/15/2016 11:32 PM, Eduardo Habkost wrote:

qdev_prop_set_globals_for_type() stops applying global properties
on the first error. It is a leftover from when QEMU exited on any
error when applying global property. Now we print a warning about
the first error, bug ignore all other global properties after it.

For example, the following command-line will not set CPUID level
to 3, but will warn only about "x86_64-cpu.vendor" being ignored.

   $ ./x86_64-softmmu/qemu-system-x86_64 \
   -global x86_64-cpu.vendor=x \
   -global x86_64-cpu.level=3
   qemu-system-x86_64: Warning: global x86_64-cpu.vendor=x ignored: Property 
'.vendor' doesn't take value 'x'

Fix this by not returning from qdev_prop_set_globals_for_type()
on the first error.

Cc: Markus Armbruster 
Signed-off-by: Eduardo Habkost 
---
  hw/core/qdev-properties.c | 1 -
  1 file changed, 1 deletion(-)

diff --git a/hw/core/qdev-properties.c b/hw/core/qdev-properties.c
index e3b2184..c10edee 100644
--- a/hw/core/qdev-properties.c
+++ b/hw/core/qdev-properties.c
@@ -1088,7 +1088,6 @@ static void qdev_prop_set_globals_for_type(DeviceState 
*dev,
  assert(prop->user_provided);
  error_reportf_err(err, "Warning: global %s.%s=%s ignored: ",
prop->driver, prop->property, prop->value);
-return;
  }
  }
  }



Is always nice to have more warnings.

Reviewed-by: Marcel Apfelbaum 

Thanks,
Marcel

Re: [Qemu-devel] [PATCH 10/10] machine: Skip global registration for non-existing classes

[Marcel Apfelbaum]

On 06/15/2016 11:32 PM, Eduardo Habkost wrote:

MachineClass::compat_props may point to class names that are not
compiled into the QEMU binary. Skip registering those as global
properties. This will allow the qdev global property code to
implement stricter checks on the global property values in the
future.

Signed-off-by: Eduardo Habkost 
---
  hw/core/machine.c | 9 +
  1 file changed, 9 insertions(+)

diff --git a/hw/core/machine.c b/hw/core/machine.c
index d6f6be4..51697cb 100644
--- a/hw/core/machine.c
+++ b/hw/core/machine.c
@@ -583,6 +583,7 @@ static void machine_class_finalize(ObjectClass *klass, void 
*data)
  void machine_register_compat_props(MachineState *machine)
  {
  MachineClass *mc = MACHINE_GET_CLASS(machine);
+ObjectClass *oc;
  int i;
  GlobalProperty *p;

@@ -592,6 +593,14 @@ void machine_register_compat_props(MachineState *machine)

  for (i = 0; i < mc->compat_props->len; i++) {
  p = g_array_index(mc->compat_props, GlobalProperty *, i);


Hi Eduardo,


+
+/* Skip registering globals for non-existing device classes */
+oc = object_class_by_name(p->driver);


This I understand. It ensure a corresponding class is in QEMU binary.
But even so, if such property is not available should we silently continue?
Maybe the user things the property is set...



+oc = object_class_dynamic_cast(oc, TYPE_DEVICE);


This I don't understand. Do we check here?

Thanks,
Marcel


+if (!oc) {
+continue;
+}
+
  /* Machine compat_props must never cause errors: */
  p->errp = _abort;
  qdev_prop_register_global(p);

Re: [Qemu-devel] [PATCH 07/10] vl: Set errp to _abort on machine compat_props

[Marcel Apfelbaum]

On 06/15/2016 11:32 PM, Eduardo Habkost wrote:

Use the new GlobalProperty.errp field to handle compat_props
errors.

Example output before this change:
(with an intentionally broken entry added to PC_COMPAT_1_3 just
for testing)

   $ qemu-system-x86_64 -machine pc-1.3
   qemu-system-x86_64: hw/core/qdev-properties.c:1091: 
qdev_prop_set_globals_for_type: Assertion `prop->user_provided' failed.
   Aborted (core dumped)

After:

   $ qemu-system-x86_64 -machine pc-1.3
   Unexpected error in x86_cpuid_set_vendor() at 
/home/ehabkost/rh/proj/virt/qemu/target-i386/cpu.c:1688:
   qemu-system-x86_64: can't apply global cpu.vendor=x: Property '.vendor' 
doesn't take value 'x'
   Aborted (core dumped)

Suggested-by: Paolo Bonzini 
Signed-off-by: Eduardo Habkost 
---
  hw/core/machine.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/hw/core/machine.c b/hw/core/machine.c
index 754a054..d6f6be4 100644
--- a/hw/core/machine.c
+++ b/hw/core/machine.c
@@ -592,6 +592,8 @@ void machine_register_compat_props(MachineState *machine)

  for (i = 0; i < mc->compat_props->len; i++) {
  p = g_array_index(mc->compat_props, GlobalProperty *, i);
+/* Machine compat_props must never cause errors: */
+p->errp = _abort;
  qdev_prop_register_global(p);
  }
  }



Reviewed-by: Marcel Apfelbaum 

Thanks,
Marcel

Re: [Qemu-devel] [PATCH 06/10] machine: Add machine_register_compat_props() function

[Marcel Apfelbaum]

On 06/15/2016 11:32 PM, Eduardo Habkost wrote:

Move the compat_props handling to core machine code.

Signed-off-by: Eduardo Habkost 
---
  hw/core/machine.c   | 16 
  include/hw/boards.h |  1 +
  vl.c|  9 ++---
  3 files changed, 19 insertions(+), 7 deletions(-)

diff --git a/hw/core/machine.c b/hw/core/machine.c
index ccdd5fa..754a054 100644
--- a/hw/core/machine.c
+++ b/hw/core/machine.c
@@ -580,6 +580,22 @@ static void machine_class_finalize(ObjectClass *klass, 
void *data)
  }
  }

+void machine_register_compat_props(MachineState *machine)
+{
+MachineClass *mc = MACHINE_GET_CLASS(machine);
+int i;
+GlobalProperty *p;
+
+if (!mc->compat_props) {
+return;
+}
+
+for (i = 0; i < mc->compat_props->len; i++) {
+p = g_array_index(mc->compat_props, GlobalProperty *, i);
+qdev_prop_register_global(p);
+}
+}
+
  static const TypeInfo machine_info = {
  .name = TYPE_MACHINE,
  .parent = TYPE_OBJECT,
diff --git a/include/hw/boards.h b/include/hw/boards.h
index d268bd0..ee71dc0 100644
--- a/include/hw/boards.h
+++ b/include/hw/boards.h
@@ -40,6 +40,7 @@ int machine_kvm_shadow_mem(MachineState *machine);
  int machine_phandle_start(MachineState *machine);
  bool machine_dump_guest_core(MachineState *machine);
  bool machine_mem_merge(MachineState *machine);
+void machine_register_compat_props(MachineState *machine);

  /**
   * CPUArchId:
diff --git a/vl.c b/vl.c
index d88ddba..86d53ca 100644
--- a/vl.c
+++ b/vl.c
@@ -4483,13 +4483,8 @@ int main(int argc, char **argv, char **envp)
  exit (i == 1 ? 1 : 0);
  }

-if (machine_class->compat_props) {
-GlobalProperty *p;
-for (i = 0; i < machine_class->compat_props->len; i++) {
-p = g_array_index(machine_class->compat_props, GlobalProperty *, 
i);
-qdev_prop_register_global(p);
-}
-}
+machine_register_compat_props(current_machine);
+
  qemu_opts_foreach(qemu_find_opts("global"),
global_init_func, NULL, );
  if (err) {



Reviewed-by: Marcel Apfelbaum 

Thanks,
Marcel

Re: [Qemu-devel] [PATCH 4/5] x86: Allow physical address bits to be set

[Marcel Apfelbaum]

On 06/17/2016 07:07 PM, Laszlo Ersek wrote:

On 06/17/16 11:52, Igor Mammedov wrote:

On Fri, 17 Jun 2016 11:17:54 +0200
Gerd Hoffmann  wrote:


On Fr, 2016-06-17 at 10:43 +0200, Paolo Bonzini wrote:


On 17/06/2016 10:15, Dr. David Alan Gilbert wrote:

Larger is a problem if the guest tries to map something to a high
address that's not addressable.


Right.  It's not a problem for most emulated PCI devices (it would be a
problem for those that have large RAM BARs, but even our emulated video
cards do not have 64-bit RAM BARs, I think;


qxl can be configured to have one, try "-device
qxl-vga,vram64_size_mb=1024"


2) While we have maxmem settings to tell us the top of VM RAM, do
   we have anything that tells us the top of IO space? What happens
   when we hotplug a PCI card?



(arch/x86/kernel/setup.c) but I agree that (2) is a blocker.


seabios maps stuff right above ram (possibly with a hole due to
alignment requirements).

ovmf maps stuff into a 32G-aligned 32G hole.  Which lands at 32G and
therefore is addressable with 36 bits, unless you have tons of ram (>
30G) assigned to your guest.  A physical host machine where you can plug
in enough ram for such a configuration likely has more than 36 physical
address lines too ...

qemu checks where the firmware mapped 64bit bars, then adds those ranges
to the root bus pci resources in the acpi tables (see /proc/iomem).


You don't know how the guest will assign PCI BAR addresses, and as you
said there's hotplug too.


Not sure whenever qemu adds some extra space for hotplug to the 64bit
hole and if so how it calculates the size then.  But the guest os should
stick to those ranges when configuring hotplugged devices.

currently firmware would assign 64-bit BARs after reserved-memory-end
(not sure about ovmf though)


OVMF does the same as well. It makes sure that the 64-bit PCI MMIO
aperture is located above "etc/reserved-memory-end", if the latter exists.


but QEMU on ACPI side will add 64-bit _CRS only
for firmware mapped devices (i.e. no space reserved for hotplug).
And is I recall correctly ovmf won't map BARs if it doesn't have
a driver for it


Yes, that's correct, generally for all UEFI firmware.

More precisely, BARs will be allocated and programmed, but the MMIO
space decoding bit will not be set (permanently) in the device's command
register, if there is no matching driver in the firmware (or in the
device's own oprom).


so ACPI tables won't even have a space for not mapped
64-bit BARs.


This used to be true, but that's not the case since
.

Namely, specifically for conforming to QEMU's ACPI generator, OVMF
*temporarily* enables, as a platform quirk, all PCI devices present in
the system, before triggering QEMU to generate the ACPI payload.

Thus, nowadays 64-bit BARs work fine with OVMF, both for virtio-modern
devices, and assigned physical devices. (This is very easy to test,
because, unlike SeaBIOS, the edk2 stuff built into OVMF prefers to
allocate 64-bit BARs outside of the 32-bit address space.)

Devices behind PXBs are a different story, but Marcel's been looking
into that, see .


There was another attempt to reserve more space in _CRS
   https://lists.nongnu.org/archive/html/qemu-devel/2016-05/msg00090.html


That's actually Marcel's first own patch set for addressing RHBZ#1323976
that I mentioned above (see it linked in
).

It might have wider effects, but it is entirely motivated, to my
knowledge, by PXB. If you don't have extra root bridges, and/or you plug
all your devices with 64-bit MMIO BARs into the "main" (default) root
bridge, then (I believe) that patch set is not supposed to make any
difference. (I could be wrong, it's been a while since I looked at
Marcel's work!)



Patch 3 and 4 indeed are for PXB only. but patch 'pci: reserve 64 bit MMIO 
range for PCI hotplug'
(see https://lists.nongnu.org/archive/html/qemu-devel/2016-05/msg00091.html) 
tries
to reserve [above_4g_mem_size, max_addressable_cpu_bits] range for PCI hotplug.

The implementation is not good enough because the number of addressable bits is 
hard-coded.
However, we have now David's wrapper I can use.


Thanks,
Marcel








Thanks
Laszlo

Re: [Qemu-devel] [PATCH v2] ppc / sparc: Add a tester for checking whether OpenBIOS runs successfully

[Artyom Tarasenko]

On Fri, Jun 17, 2016 at 3:56 PM, Mark Cave-Ayland
 wrote:
 Since the mac99 and g3beige PowerPC machines recently broke without
 being noticed, it would be good to have a tester for "make check"
 that detects such issues immediately. A simple way to test the firmware
 of these machines is to use the "-prom-env" parameter of QEMU. This
 parameter can be used to put some Forth code into the 'boot-command'
 firmware variable which then can signal success to the tester by
 writing a magic value to a known memory location. And since some of the
 Sparc machines are also using OpenBIOS, they are now tested with this
 prom-env-tester, too.

 Reviewed-by: Markus Armbruster 
 Signed-off-by: Thomas Huth 
 ---
  v2: Removed unnecessary include statements (as suggested by Markus)
>>>
>>> Beautiful, I've applied this to ppc-for-2.7, assuming I don't get an
>>> objection to taking this through my tree.
>>
>> Ugh.. turns out this fails on sparc64 target on a 32-bit x86 host.
>> Specifically it trips the tcg_abort() at the end of tcg_reg_alloc()
>> (tcg/tcg.c).
>>
>> I'm reasonably confident this is a pre-existing bug, just triggered by
>> this test, but in the interests of getting this up and running on the
>> platforms where it is working, I've disabled the testcase on sparc64
>> for now.
>>
>> Mark, if you could debug the sparc64-on-i386 failure at some point,
>> that would be helpful.
>
> I'm a little tied up until next week, however I was able to reproduce on
> a local i386 VM and get a stack trace:
>
>
> $ gdb --args ./qemu-system-sparc64 -nographic
> GNU gdb (Debian 7.10-1.1) 7.10
> Copyright (C) 2015 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "i686-linux-gnu".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> .
> Find the GDB manual and other documentation resources online at:
> .
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from ./qemu-system-sparc64...done.
> (gdb) r
> Starting program: /home/build/rel-qemu-git/bin/qemu-system-sparc64
> -nographic
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
> [New Thread 0xb7989b40 (LWP 27497)]
> [New Thread 0xb4af1b40 (LWP 27498)]
> OpenBIOS for Sparc64
> Configuration device id QEMU version 1 machine id 0
> kernel cmdline
> CPUs: 1 x SUNW,UltraSPARC-IIi
> UUID: ----
> /home/build/src/qemu/tcg/tcg.c:1743: tcg fatal error
>
> Program received signal SIGABRT, Aborted.
> [Switching to Thread 0xb4af1b40 (LWP 27498)]
> 0xb7fdadad in __kernel_vsyscall ()
> (gdb) bt
> #0  0xb7fdadad in __kernel_vsyscall ()
> #1  0xb7a2ee26 in __GI_raise (sig=6) at
> ../sysdeps/unix/sysv/linux/raise.c:55
> #2  0xb7a303f7 in __GI_abort () at abort.c:89
> #3  0x08061776 in tcg_reg_alloc (s=0x8637780 ,
> desired_regs=255, allocated_regs=255, rev=true) at
> /home/build/src/qemu/tcg/tcg.c:1743
> #4  0x0806181a in temp_load (s=0x8637780 , ts=0x8637978
> , desired_regs=255, allocated_regs=255) at
> /home/build/src/qemu/tcg/tcg.c:1762
> #5  0x080615e0 in tcg_reg_sync (s=0x8637780 , reg=TCG_REG_EAX,
> allocated_regs=255) at /home/build/src/qemu/tcg/tcg.c:1694
> #6  0x08061653 in tcg_reg_free (s=0x8637780 , reg=TCG_REG_EAX,
> allocated_regs=254) at /home/build/src/qemu/tcg/tcg.c:1709
> #7  0x08061740 in tcg_reg_alloc (s=0x8637780 ,
> desired_regs=255, allocated_regs=254, rev=true) at
> /home/build/src/qemu/tcg/tcg.c:1738
> #8  0x0806181a in temp_load (s=0x8637780 , ts=0x8637978
> , desired_regs=255, allocated_regs=254) at
> /home/build/src/qemu/tcg/tcg.c:1762
> #9  0x080615e0 in tcg_reg_sync (s=0x8637780 , reg=TCG_REG_ECX,
> allocated_regs=254) at /home/build/src/qemu/tcg/tcg.c:1694
> #10 0x08061653 in tcg_reg_free (s=0x8637780 , reg=TCG_REG_ECX,
> allocated_regs=252) at /home/build/src/qemu/tcg/tcg.c:1709
> #11 0x08061740 in tcg_reg_alloc (s=0x8637780 ,
> desired_regs=255, allocated_regs=252, rev=true) at
> /home/build/src/qemu/tcg/tcg.c:1738
> #12 0x0806181a in temp_load (s=0x8637780 , ts=0x8637978

[Qemu-devel] [PATCH] ppc: Improve emulation of THRM registers

[G 3]

 On 6/19/16 12:12 AM, qemu-devel-requ...@nongnu.org wrote:

Message: 5
Date: Sun, 19 Jun 2016 10:54:13 +1000
From: Benjamin Herrenschmidt
To:qemu-...@nongnu.org
Cc:qemu-devel@nongnu.org,da...@gibson.dropbear.id.au, Mark
Cave-Ayland , Alexander Graf

Subject: [Qemu-devel] [PATCH] ppc: Improve emulation of THRM registers
Message-ID:<1466297653.24271.101.ca...@kernel.crashing.org>
Content-Type: text/plain; charset="UTF-8"

The 75x and 74xx processors have some thermal monitoring SPRs that
some OSes such as MacOS do use. Our current "dumb" implementation
isn't good enough and will cause some versions of MacOS to hang during
boot.

This lifts an improved emulation from MacOnLinux and adapts it to
qemu, thus fixing the problem.


Which versions of the Mac OS hang?

Re: [Qemu-devel] [Qemu-ppc] [PATCH 01/10] ppc: Fix rfi/rfid/hrfi/... emulation

[Benjamin Herrenschmidt]

On Sun, 2016-06-19 at 14:49 +0200, Cédric Le Goater wrote:
> > So my test is correct in the context of what we emulate today.
> 
> OK. so this is an openbios issue when run under a ppc64. shouldn't we 
> be using an openbios-ppc64 in that case ?  
> 
> 
> We could be more strict with the rfi instruction. 

Well, ppc64 isn't backward compatible with ppc32 at the supervisor
level, at least not on server chips (it is on bookE chips). So yes it's
an OpenBIOS problem but that doesn't mean we have to use openbios-ppc64 
:-) 

You can run a 32-bit OS or firmware on ppc64, but it needs to know that
it's running on a 64-bit chip and do a few things differently.

Cheers,
Ben.

Re: [Qemu-devel] [Bug 1594069] [NEW] SIMD instructions translated to scalar host instructions

[Peter Maydell]

On 19 June 2016 at 06:33, Timothy Pearson  wrote:
> Public bug reported:
>
> SIMD instructions inside the guest (NEON, MMX, SSE, SSE2, AVX) are
> translated to scalar instructions on the host instead of SIMD
> instructions.  It appears that there have been a few efforts to rectify
> this [1], and even a submitted patch series, but all discussion has
> effectively died out [2].
>
> I would like to see better SIMD performance on qemu, especially as
> non-x86 architectures are becoming widely used (e.g. ARM).

I agree it would be nice, but I'm not sure there's much benefit
from filing a bug about it. Bug reports don't magically become
code changes, and doing SIMD-to-SIMD is very difficult when
you need to support multiple host and guest architectures and
get all the details and corner cases correct. QEMU as it stands
isn't behaving wrongly.

thanks
-- PMM

Re: [Qemu-devel] [Qemu-ppc] [PATCH 01/10] ppc: Fix rfi/rfid/hrfi/... emulation

[Alexander Graf]

> Am 19.06.2016 um 14:49 schrieb Cédric Le Goater :
> 
>> On 06/19/2016 01:35 AM, Benjamin Herrenschmidt wrote:
>>> On Fri, 2016-06-17 at 16:32 +0200, Cédric Le Goater wrote:
>>> The instruction set PPC_POWER_BR contains nearly all the deleted 
>>> instructions from isa2. rfi is not part of it and should. Also, only 
>>> the cpus "PowerPC 601*" make a use of it in their insns_flags.
>> 
>> Are you sure those arent the old POWER instructions as in pre-powerPC
>> architecture that 601 (and only 601) supports ?
> 
> OK. I get it now.  
> 
> All the deleted instructions from POWER are/should be under the set 
> PPC_POWER.
> 
> All the deleted instructions from POWER2 are under the set PPC_POWER2.
> 
> None of these sets are in use.
> 
> 
> For the  "PowerPC 601*" cpus, we moved a couple from set PPC_POWER to 
> subset PPC_POWER_BR.
> 
> rfi is special. it is under PPC_FLOW and all CPUs can use it
> 
>>> So, we would want this set to be in all the "PowerPC {6,7}*" cpus. 
>>> Are there more ?
>> 
>> All 32-bit hash based CPUs are arch 1.x and support rfi
>> 
>> All 64-bit hash based CPUs we support (ie, POWER4 and later) are
>> architecture 2.x and later.
>> 
>> So my test is correct in the context of what we emulate today.
> 
> OK. so this is an openbios issue when run under a ppc64. shouldn't we 
> be using an openbios-ppc64 in that case ?  

No, openbios can run on both. Just add a runtime check in openbios for rfi/rfid.

Alex

> 
> 
> We could be more strict with the rfi instruction. 
> 
> 
> C.
> 

Re: [Qemu-devel] [Qemu-ppc] [PATCH 01/10] ppc: Fix rfi/rfid/hrfi/... emulation

[Cédric Le Goater]

On 06/19/2016 01:35 AM, Benjamin Herrenschmidt wrote:
> On Fri, 2016-06-17 at 16:32 +0200, Cédric Le Goater wrote:
>> The instruction set PPC_POWER_BR contains nearly all the deleted 
>> instructions from isa2. rfi is not part of it and should. Also, only 
>> the cpus "PowerPC 601*" make a use of it in their insns_flags.
> 
> Are you sure those arent the old POWER instructions as in pre-powerPC
> architecture that 601 (and only 601) supports ?

OK. I get it now.  

All the deleted instructions from POWER are/should be under the set 
PPC_POWER.

All the deleted instructions from POWER2 are under the set PPC_POWER2.

None of these sets are in use.


For the  "PowerPC 601*" cpus, we moved a couple from set PPC_POWER to 
subset PPC_POWER_BR.

rfi is special. it is under PPC_FLOW and all CPUs can use it

>> So, we would want this set to be in all the "PowerPC {6,7}*" cpus. 
>> Are there more ? 
> 
> All 32-bit hash based CPUs are arch 1.x and support rfi
> 
> All 64-bit hash based CPUs we support (ie, POWER4 and later) are
> architecture 2.x and later.
> 
> So my test is correct in the context of what we emulate today.

OK. so this is an openbios issue when run under a ppc64. shouldn't we 
be using an openbios-ppc64 in that case ?  


We could be more strict with the rfi instruction. 


C.

[Qemu-devel] [Bug 1594069] Re: SIMD instructions translated to scalar host instructions

[pranith]

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

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

Title:
  SIMD instructions translated to scalar host instructions

Status in QEMU:
  Confirmed

Bug description:
  SIMD instructions inside the guest (NEON, MMX, SSE, SSE2, AVX) are
  translated to scalar instructions on the host instead of SIMD
  instructions.  It appears that there have been a few efforts to
  rectify this [1], and even a submitted patch series, but all
  discussion has effectively died out [2].

  I would like to see better SIMD performance on qemu, especially as
  non-x86 architectures are becoming widely used (e.g. ARM).

  [1] 
http://dl.acm.org/citation.cfm?id=2757098=ACM=DL=633095244=12352103
  [2] https://lists.nongnu.org/archive/html/qemu-devel/2014-10/msg01720.html

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

Re: [Qemu-devel] [Qemu-ppc] [PATCH] ppc: Improve emulation of THRM registers

[BALATON Zoltan]

On Sun, 19 Jun 2016, Benjamin Herrenschmidt wrote:

The 75x and 74xx processors have some thermal monitoring SPRs that
some OSes such as MacOS do use. Our current "dumb" implementation
isn't good enough and will cause some versions of MacOS to hang during
boot.

This lifts an improved emulation from MacOnLinux and adapts it to
qemu, thus fixing the problem.

Signed-off-by: Benjamin Herrenschmidt 
---
target-ppc/helper.h |  1 +
target-ppc/misc_helper.c| 41 +
target-ppc/translate_init.c | 13 ++---
3 files changed, 52 insertions(+), 3 deletions(-)

diff --git a/target-ppc/helper.h b/target-ppc/helper.h
index f4410a8..18eb52f 100644
--- a/target-ppc/helper.h
+++ b/target-ppc/helper.h
@@ -670,3 +670,4 @@ DEF_HELPER_4(dscli, void, env, fprp, fprp, i32)
DEF_HELPER_4(dscliq, void, env, fprp, fprp, i32)

DEF_HELPER_1(tbegin, void, env)
+DEF_HELPER_1(fixup_thrm, void, env)
diff --git a/target-ppc/misc_helper.c b/target-ppc/misc_helper.c
index 7d41b01..4315778 100644
--- a/target-ppc/misc_helper.c
+++ b/target-ppc/misc_helper.c
@@ -166,3 +166,44 @@ void ppc_store_msr(CPUPPCState *env, target_ulong value)
{
hreg_store_msr(env, value, 0);
}
+
+/* This code is lifted from MacOnLinux. It is called whenever
+ * THRM1,2 or 3 is read an fixes up the values in such a way
+ * that will mac MacOS not hang. These registers exist on some


Typo: mac -> make?

Re: [Qemu-devel] [PATCH 2/2] configure: Make AVX2 test robust to non-ELF systems

[Stefan Weil]

Am 19.06.2016 um 11:41 schrieb Peter Maydell:
> On 19 June 2016 at 06:53, Stefan Weil  wrote:
>> Am 19.06.2016 um 00:05 schrieb Peter Maydell:
>>> From: Peter Maydell 
>>>
>>> The AVX2 optimization test assumes that the object format
>>> is ELF and the system has the readelf utility. If this isn't
>>> true then configure might fail or emit a warning (since in
>>> a pipe "foo | bar >/dev/null 2>&1" does not redirect the
>>> stderr of foo, only of bar). Adjust the check so that if
>>> we don't have readelf or don't have an ELF object then we
>>> just don't enable the AVX2 optimization.
>>>
>>> Reported-by: Stefan Weil 
>>> Signed-off-by: Peter Maydell 
>>> ---
>>>  configure | 6 --
>>>  1 file changed, 4 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/configure b/configure
>>> index 7beefcd..30bca55 100755
>>> --- a/configure
>>> +++ b/configure
>>> @@ -1792,8 +1792,10 @@ int foo(void *a) __attribute__((ifunc("bar_ifunc")));
>>>  int main(int argc, char *argv[]) { return foo(argv[0]);}
>>>  EOF
>>>  if compile_object "" ; then
>>> -if readelf --syms $TMPO |grep "IFUNC.*foo" >/dev/null 2>&1; then
>>> -avx2_opt="yes"
>>> +if has readelf; then
>>> +if readelf --syms $TMPO 2>/dev/null |grep -q "IFUNC.*foo"; then
>>> +avx2_opt="yes"
>>> +fi
>>>  fi
>>>  fi
>>>
>>>
>>
>> You could check "has readelf" earlier and avoid the compile test
>> if there is no readelf (saves a little time).
> 
> I guess so, though there's not much in it.
> 
>> The final I/O redirection is still needed (otherwise Linux users will
>> see the grep output).
> 
> I added -q which should suppress that, no ?
> 
> thanks
> -- PMM
> 

Sorry, I missed that detail.

Reviewed-by: Stefan Weil 

Re: [Qemu-devel] [PATCH 5/7] TIOCGPTN and related terminal control ioctls were not converted to the guest ioctl format on x86_64 targets. Convert these ioctls to enable terminal functionality on x86_6

[Peter Maydell]

On 19 June 2016 at 01:15, Timothy Pearson
 wrote:
> Signed-off-by: Timothy Pearson 
> ---
>  linux-user/x86_64/termbits.h | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/linux-user/x86_64/termbits.h b/linux-user/x86_64/termbits.h
> index 1c3445c..5fc4639 100644
> --- a/linux-user/x86_64/termbits.h
> +++ b/linux-user/x86_64/termbits.h
> @@ -209,12 +209,12 @@ struct target_termios {
>  #define TARGET_TIOCSBRK0x5427  /* BSD compatibility */
>  #define TARGET_TIOCCBRK0x5428  /* BSD compatibility */
>  #define TARGET_TIOCGSID0x5429  /* Return the session ID of FD */
> -#define TARGET_TCGETS2 _IOR('T',0x2A, struct termios2)
> -#define TARGET_TCSETS2 _IOW('T',0x2B, struct termios2)
> -#define TARGET_TCSETSW2_IOW('T',0x2C, struct termios2)
> -#define TARGET_TCSETSF2_IOW('T',0x2D, struct termios2)
> -#define TARGET_TIOCGPTN_IOR('T',0x30, unsigned int) /* Get Pty 
> Number (of pty-mux device) */
> -#define TARGET_TIOCSPTLCK  _IOW('T',0x31, int)  /* Lock/unlock Pty */
> +#define TARGET_TCGETS2 TARGET_IOR('T',0x2A, struct termios2)
> +#define TARGET_TCSETS2 TARGET_IOW('T',0x2B, struct termios2)
> +#define TARGET_TCSETSW2TARGET_IOW('T',0x2C, struct termios2)
> +#define TARGET_TCSETSF2TARGET_IOW('T',0x2D, struct termios2)
> +#define TARGET_TIOCGPTNTARGET_IOR('T',0x30, unsigned int) /* 
> Get Pty Number (of pty-mux device) */
> +#define TARGET_TIOCSPTLCK  TARGET_IOW('T',0x31, int)  /* Lock/unlock Pty 
> */
>
>  #define TARGET_FIONCLEX0x5450  /* these numbers need to be adjusted. 
> */
>  #define TARGET_FIOCLEX 0x5451

Reviewed-by: Peter Maydell 

(though the spacing looks a little odd -- make sure you're
using spaces only and run through scripts/checkpatch.pl.)

thanks
-- PMM

Re: [Qemu-devel] [PATCH 3/7] Pass select() arguments directly to do_select() on x86 platforms

[Peter Maydell]

On 19 June 2016 at 01:15, Timothy Pearson
 wrote:
> This matches the calling conventions in the Linux kernel and
> resolves select() hangs on i386/x86_64 guests.
>
> Signed-off-by: Timothy Pearson 
> ---
>  linux-user/syscall.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/linux-user/syscall.c b/linux-user/syscall.c
> index 2968b57..644a490 100644
> --- a/linux-user/syscall.c
> +++ b/linux-user/syscall.c
> @@ -4785,6 +4785,7 @@ static abi_long do_ioctl(int fd, int cmd, abi_long arg)
>  void *argptr;
>
>  ie = ioctl_entries;
> +
>  for(;;) {
>  if (ie->target_cmd == 0) {
>  gemu_log("Unsupported ioctl: cmd=0x%04lx\n", (long)cmd);
> @@ -7899,7 +7900,7 @@ abi_long do_syscall(void *cpu_env, int num, abi_long 
> arg1,
>  break;
>  #if defined(TARGET_NR_select)
>  case TARGET_NR_select:
> -#if defined(TARGET_S390X) || defined(TARGET_ALPHA)
> +#if defined(TARGET_S390X) || defined(TARGET_ALPHA) || defined(TARGET_I386) 
> || defined(TARGET_X86_64)
>  ret = do_select(arg1, arg2, arg3, arg4, arg5);
>  #else
>  {

I think we can fix this in a cleaner way. This is actually
the result of there being two select syscalls:
 * the one which takes a struct with the params, which
   the kernel calls 'old_select' and which we seem to have
   decided to call TARGET_NR_select
 * the one which takes the arguments separately, which the
   kernel calls 'select' and which we seem to use
   TARGET_NR__newselect for

So I think we should fix this by:
 (1) making sure all archs (including x86, alpha and s390)
 define TARGET_NR_select and TARGET_NR__newselect
 correctly
 (2) removing this ifdef entirely (so TARGET_NR_select is always
 "use the struct" for any arch that defines it, and
 TARGET_NR__newselect is always "direct args"), and
 similarly for the equivalent ifdef in linux-user/syscall.c

I think we should also change our naming to TARGET_NR_oldselect
and TARGET_NR_select to match the kernel.

thanks
-- PMM

Re: [Qemu-devel] [PATCH 2/7] QEMU does not currently support host pages that are larger than guest pages, likely due to glibc using fixed mmap requests.

[Peter Maydell]

On 19 June 2016 at 01:11, Timothy Pearson
 wrote:
> Attempting to use host pages larger than the guest leads to
> alignment errors during ELF load in the best case, and an
> initialization failure inside NPTL in the worst case, causing
> all fork() requests inside the guest to fail.
>
> Warn when thread space cannot be set up, and suggest reducing
> host page size if applicable.

This is supposed to work -- for instance the linux-user/mmap.c
code has support for host pages and target pages not being the same.
In particular for ARM guests TARGET_PAGE_SIZE is 1K but the
host page size is 4K, so the config of "host page larger than
guest" isn't untested.

> --- a/linux-user/syscall.c
> +++ b/linux-user/syscall.c
> @@ -5482,8 +5482,13 @@ static int do_fork(CPUArchState *env, unsigned
> int flags, abi_ulong newsp,
>  /* Wait for the child to initialize.  */
>  pthread_cond_wait(, );
>  ret = info.tid;
> -if (flags & CLONE_PARENT_SETTID)
> -put_user_u32(ret, parent_tidptr);
> +if (flags & CLONE_PARENT_SETTID) {
> +if (put_user_u32(ret, parent_tidptr)) {
> +fprintf(stderr, "do_fork: put_user_u32() failed,
> child process state invalid\n");
> +if (qemu_real_host_page_size > TARGET_PAGE_SIZE)
> +fprintf(stderr, "do_fork: host page size >
> target page size; reduce host page size and try again\n");
> +}
> +}

I think we should figure out why these put_user_u32() calls
are failing and fix them.

thanks
-- PMM

Re: [Qemu-devel] [PATCH 2/2] configure: Make AVX2 test robust to non-ELF systems

[Peter Maydell]

On 19 June 2016 at 06:53, Stefan Weil  wrote:
> Am 19.06.2016 um 00:05 schrieb Peter Maydell:
>> From: Peter Maydell 
>>
>> The AVX2 optimization test assumes that the object format
>> is ELF and the system has the readelf utility. If this isn't
>> true then configure might fail or emit a warning (since in
>> a pipe "foo | bar >/dev/null 2>&1" does not redirect the
>> stderr of foo, only of bar). Adjust the check so that if
>> we don't have readelf or don't have an ELF object then we
>> just don't enable the AVX2 optimization.
>>
>> Reported-by: Stefan Weil 
>> Signed-off-by: Peter Maydell 
>> ---
>>  configure | 6 --
>>  1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/configure b/configure
>> index 7beefcd..30bca55 100755
>> --- a/configure
>> +++ b/configure
>> @@ -1792,8 +1792,10 @@ int foo(void *a) __attribute__((ifunc("bar_ifunc")));
>>  int main(int argc, char *argv[]) { return foo(argv[0]);}
>>  EOF
>>  if compile_object "" ; then
>> -if readelf --syms $TMPO |grep "IFUNC.*foo" >/dev/null 2>&1; then
>> -avx2_opt="yes"
>> +if has readelf; then
>> +if readelf --syms $TMPO 2>/dev/null |grep -q "IFUNC.*foo"; then
>> +avx2_opt="yes"
>> +fi
>>  fi
>>  fi
>>
>>
>
> You could check "has readelf" earlier and avoid the compile test
> if there is no readelf (saves a little time).

I guess so, though there's not much in it.

> The final I/O redirection is still needed (otherwise Linux users will
> see the grep output).

I added -q which should suppress that, no ?

thanks
-- PMM

Re: [Qemu-devel] [RFC 0/9] Introduce light weight PC platform pc-lite

[Claudio Fontana]

Hi,

On 17.06.2016 10:14, Chao Peng wrote:
> This patchset is against commit 585fcd4 (Merge remote-tracking branch
> 'remotes/bonzini/tags/for-upstream' into staging) on master branch. I
> also put it on github:
> 
> https://github.com/chao-p/qemu pc-lite-v1
>  
> Although we have run the patchset internally for a while but it is still
> considered as RFC. Any comments (coding style or design issue) are
> welcome.
> 
> Introduction
> 
> The patch series introduces a new platform pc-lite, which is designed to
> be a virtual and light weight x86 PC platform. It is not designed to be
> compatible with old hardware and system. Instead, It removes the burden
> of legacy devices and emulates new fast hardware as much as possible. It
> is expected to be used together with optimized guest (though unoptimized
> guest works as well) to gain fast booting and small footprint benefits
> that are difficult to achieve for traditional hardware-emulated
> platform.
> 
> Basically:
> - it removes old ISA devices and support only PCI devices;
> - it removes 8259, instead use MSI as much as possible. IOAPIC and PCI
>   PIN are still kept to support ACPI SCI;
> - it supports PCIE ( you can use MMFG instead of 0xcf8/0xcfc port
>   access);
> - it gets rid of legacy firmware interfaces and supports ACPI tables;
> - it loads guest kernel directly, no BIOS, no bootloader, no realmode
>   code;
> - it supports CPU/memory/PCI hotplug;
> - it is FAST;
> 
> However:
> - it supports KVM-host only at present;
> - it supports Linux-guest only at present;
> - You may need carefully configure guest kernel;
> - You are forced to use virtio-serial-pci, old 8250/16550 is not there;
> 
> Want to have a try?
> ===

The combination of devices removed/supported seems a bit arbitrary to me.
The use in this text of "legacy" and non-"legacy" is also arbitrary if not 
given a definition.

What is the use case of this new platform?

Care to share your numbers about how FAST is FAST? Like how much time you need 
to boot from qemu launch to the guest being booted, and on which hardware, and 
which guest kernel configuration?

Ciao,

Claudio

> 
> Please follow https://github.com/chao-p/qemu-lite-tools.
> 
> Thanks,
> Chao
> 
> Chao Peng (6):
>   acpi: introduce light weight ACPI PM emulation pm-lite
>   pci: introduce light weight PCIE Host emulation pci-lite
>   acpi: add support for pc-lite platform
>   pc: skip setting CMOS data when RTC device is unavailable
>   pc: support direct loading protected/long mode kernel
>   pc: introduce light weight PC board pc-lite
> 
> Haozhong Zhang (3):
>   acpi: expose data structurs and functions of BIOS linker loader
>   acpi: expose acpi_checksum()
>   acpi: patch guest ACPI for pc-lite
> 
>  default-configs/i386-softmmu.mak |   1 +
>  default-configs/x86_64-softmmu.mak   |   1 +
>  docs/specs/acpi_cpu_hotplug.txt  |   1 +
>  hw/acpi/Makefile.objs|   2 +-
>  hw/acpi/bios-linker-loader.c |  83 +--
>  hw/acpi/core.c   |   2 +-
>  hw/acpi/nvdimm.c |   6 +-
>  hw/acpi/pm_lite.c| 446 
> +++
>  hw/i386/Makefile.objs|   2 +-
>  hw/i386/acpi-build.c | 180 +-
>  hw/i386/pc.c | 263 ++---
>  hw/i386/pc_lite.c| 205 
>  hw/i386/pc_lite_acpi.c   | 299 +++
>  hw/i386/pc_piix.c|   2 +
>  hw/i386/pc_q35.c |   2 +
>  hw/pci-host/Makefile.objs|   1 +
>  hw/pci-host/pci_lite.c   | 259 
>  include/hw/acpi/acpi.h   |   2 +
>  include/hw/acpi/bios-linker-loader.h |  85 +++
>  include/hw/acpi/pc-hotplug.h |   1 +
>  include/hw/acpi/pm_lite.h|   6 +
>  include/hw/i386/pc.h |  17 ++
>  include/hw/i386/pc_lite_acpi.h   |  10 +
>  23 files changed, 1697 insertions(+), 179 deletions(-)
>  create mode 100644 hw/acpi/pm_lite.c
>  create mode 100644 hw/i386/pc_lite.c
>  create mode 100644 hw/i386/pc_lite_acpi.c
>  create mode 100644 hw/pci-host/pci_lite.c
>  create mode 100644 include/hw/acpi/pm_lite.h
>  create mode 100644 include/hw/i386/pc_lite_acpi.h
> 

[Qemu-devel] [PATCH] hw/sh4: Add dtb support

[Yoshinori Sato]

New SH kernel use dtb.
This patch add dtb support for R2D board emulation.

Signed-off-by: Yoshinori Sato 
---
 hw/sh4/r2d.c | 52 +++-
 1 file changed, 43 insertions(+), 9 deletions(-)

diff --git a/hw/sh4/r2d.c b/hw/sh4/r2d.c
index f2547ed..203c117 100644
--- a/hw/sh4/r2d.c
+++ b/hw/sh4/r2d.c
@@ -41,6 +41,7 @@
 #include "hw/usb.h"
 #include "hw/block/flash.h"
 #include "sysemu/block-backend.h"
+#include "sysemu/device_tree.h"
 #include "exec/address-spaces.h"
 
 #define FLASH_BASE 0x
@@ -51,7 +52,7 @@
 
 #define SM501_VRAM_SIZE 0x80
 
-#define BOOT_PARAMS_OFFSET 0x0001000
+#define BOOT_PARAMS_OFFSET 0x001
 /* CONFIG_BOOT_LINK_OFFSET of Linux kernel */
 #define LINUX_LOAD_OFFSET  0x080
 #define INITRD_LOAD_OFFSET 0x180
@@ -198,6 +199,7 @@ static qemu_irq *r2d_fpga_init(MemoryRegion *sysmem,
 typedef struct ResetData {
 SuperHCPU *cpu;
 uint32_t vector;
+uint32_t dtb;
 } ResetData;
 
 static void main_cpu_reset(void *opaque)
@@ -207,6 +209,8 @@ static void main_cpu_reset(void *opaque)
 
 cpu_reset(CPU(s->cpu));
 env->pc = s->vector;
+/* r4_bank1 is DTB address */
+env->gregs[4 + 16] = s->dtb;
 }
 
 static struct QEMU_PACKED
@@ -225,10 +229,12 @@ static struct QEMU_PACKED
 
 static void r2d_init(MachineState *machine)
 {
+QemuOpts *machine_opts;
 const char *cpu_model = machine->cpu_model;
-const char *kernel_filename = machine->kernel_filename;
-const char *kernel_cmdline = machine->kernel_cmdline;
-const char *initrd_filename = machine->initrd_filename;
+const char *kernel_filename;
+const char *kernel_cmdline;
+const char *initrd_filename;
+const char *dtb_filename;
 SuperHCPU *cpu;
 CPUSH4State *env;
 ResetData *reset_info;
@@ -258,6 +264,12 @@ static void r2d_init(MachineState *machine)
 reset_info->vector = env->pc;
 qemu_register_reset(main_cpu_reset, reset_info);
 
+machine_opts = qemu_get_machine_opts();
+kernel_filename = qemu_opt_get(machine_opts, "kernel");
+kernel_cmdline = qemu_opt_get(machine_opts, "append");
+initrd_filename = qemu_opt_get(machine_opts, "initrd");
+dtb_filename = qemu_opt_get(machine_opts, "dtb");
+
 /* Allocate memory space */
 memory_region_init_ram(sdram, NULL, "r2d.sdram", SDRAM_SIZE, _fatal);
 vmstate_register_ram_global(sdram);
@@ -347,11 +359,33 @@ static void r2d_init(MachineState *machine)
 boot_params.initrd_size = tswap32(initrd_size);
 }
 
-if (kernel_cmdline) {
-/* I see no evidence that this .kernel_cmdline buffer requires
-   NUL-termination, so using strncpy should be ok. */
-strncpy(boot_params.kernel_cmdline, kernel_cmdline,
-sizeof(boot_params.kernel_cmdline));
+if (!dtb_filename) {
+if (kernel_cmdline) {
+/* I see no evidence that this .kernel_cmdline buffer requires
+   NUL-termination, so using strncpy should be ok. */
+strncpy(boot_params.kernel_cmdline, kernel_cmdline,
+sizeof(boot_params.kernel_cmdline));
+}
+} else {
+void *fdt;
+int r = 0;
+uint32_t addr;
+int fdt_size;
+
+fdt = load_device_tree(dtb_filename, _size);
+if (!fdt) {
+return;
+}
+if (kernel_cmdline) {
+r = qemu_fdt_setprop_string(fdt, "/chosen", "bootargs",
+kernel_cmdline);
+if (r < 0) {
+fprintf(stderr, "couldn't set /chosen/bootargs\n");
+}
+}
+addr = (SDRAM_BASE + SDRAM_SIZE - fdt_size) & ~0xfff;
+cpu_physical_memory_write(addr, fdt, fdt_size);
+reset_info->dtb = addr;
 }
 
 rom_add_blob_fixed("boot_params", _params, sizeof(boot_params),
-- 
2.7.0

[Qemu-devel] [PATCH] *** Vhost-pci RFC v2 ***

[Wei Wang]

This RFC proposes a design of vhost-pci, which is a new virtio device type.
The vhost-pci device is used for inter-VM communication.

Changes in v2:
1. changed the vhost-pci driver to use a controlq to send acknowledgement
   messages to the vhost-pci server rather than writing to the device
   configuration space;

2. re-organized all the data structures and the description layout;

3. removed the VHOST_PCI_CONTROLQ_UPDATE_DONE socket message, which is 
redundant;

4. added a message sequence number to the msg info structure to identify socket
   messages, and the socket message exchange does not need to be blocking;

5. changed to used uuid to identify each VM rather than using the QEMU process
   id

Wei Wang (1):
  Vhost-pci RFC v2: a new virtio device for inter-VM communication

 vhost-pci.patch | 341 
 1 file changed, 341 insertions(+)
 create mode 100755 vhost-pci.patch

-- 
1.8.3.1

[Qemu-devel] [PATCH] Vhost-pci RFC v2: a new virtio device for inter-VM communication

[Wei Wang]

We introduce the vhost-pci design in the virtio specification format.
To follow the naming conventions in the virtio specification, we call
the VM who sends packets to the destination VM the device VM, and the
VM who provides the vring and receives packets the driver VM.

Signed-off-by: Wei Wang 
---
 vhost-pci.patch | 341 
 1 file changed, 341 insertions(+)
 create mode 100755 vhost-pci.patch

diff --git a/vhost-pci.patch b/vhost-pci.patch
new file mode 100755
index 000..341ba07
--- /dev/null
+++ b/vhost-pci.patch
@@ -0,0 +1,341 @@
+1. Vhost-pci Device
+
+1.1 Device ID
+TBD
+
+1.2 Virtqueues
+0 control receiveq
+1 control transmitq
+
+1.3 Feature Bits
+
+1.3.1 Local Feature Bits
+Currently no local feature bits are defined, so the standard virtio feature
+bits negation will always be successful and complete.
+
+1.3.2 Remote Feature Bits
+The remote feature bits are obtained from the frontend device and negotiated
+with the vhost-pci driver via the control transmitq. The negotiation steps
+are described in 1.5 Device Initialization.
+
+1.4 Device Configuration Layout
+None currently defined
+
+1.5 Device Initialization
+When a device VM boots, it creates a vhost-pci server socket.
+
+When a virtio device on the driver VM is created with specifying the use of
+a vhost-pci device as a backend, a client socket is created and connected to
+the server for message exchanges.
+
+The server and client communicate via socket messages. The server and the
+vhost-pci driver communicate via controlq messages. The server updates the
+driver via a control transmitq. The driver acknowledges the server via a
+control receiveq.
+
+Both the socket message and controlq message headers can be constructed using
+the following message info structure:
+struct vhost_pci_msg_info {
+#define VHOST_PCI_MSG_TYPE_MEMORY_INFO 0
+#define VHOST_PCI_MSG_TYPE_MEMORY_INFO_ACK 1
+#define VHOST_PCI_MSG_TYPE_DEVICE_INFO 2
+#define VHOST_PCI_MSG_TYPE_DEVICE_INFO_ACK 3
+#define VHOST_PCI_MSG_TYPE_FEATURE_BITS 4
+#define VHOST_PCI_MSG_TYPE_FEATURE_BITS_ACK 5
+   u16 msg_type;
+   u16 msg_version;
+   u32 msg_len;
+   u64 msg_seq;
+};
+The msg_seq field stores the message sequence number. Each client maintains
+its own message sequence number.
+
+The socket messages are preceded by the following header:
+struct vhost_pci_socket_hdr {
+   struct vhost_pci_msg_info msg_info;
+   u64 client_uuid;
+};
+The client_uuid field is generated by the client for the client identification
+purpose.
+
+The controlq messages are preceded by the following header:
+struct vhost_pci_controlq_hdr {
+   struct vhost_pci_msg_info msg_info;
+#define VHOST_PCI_FRONTEND_DEVICE_NET 1
+#define VHOST_PCI_FRONTEND_DEVICE_BLK 2
+#define VHOST_PCI_FRONTEND_DEVICE_CONSOLE 3
+#define VHOST_PCI_FRONTEND_DEVICE_ENTROPY 4
+#define VHOST_PCI_FRONTEND_DEVICE_BALLOON 5
+#define VHOST_PCI_FRONTEND_DEVICE_SCSI 8
+   u32 device_type;
+   u64 device_id;
+};
+The device_type and device_id fields identify the frontend device (client).
+
+The payload of a VHOST_PCI_MSG_TYPE_MEMORY_INFO socket message can be
+constructed using the following structure:
+/* socket message: VHOST_PCI_MSG_TYPE_MEMORY_INFO */
+struct vhost_pci_socket_memory_info {
+#define VHOST_PCI_ADD_MEMORY 0
+#define VHOST_PCI_DEL_MEMORY 1
+   u16 ops;
+   u32 nregions;
+   struct vhost_pci_memory_region {
+   int fd;
+   u64 guest_phys_addr;
+   u64 memory_size;
+   u64 mmap_offset;
+   } regions[VHOST_PCI_MAX_NREGIONS];
+};
+
+The payload of a VHOST_PCI_MSG_TYPE_MEMORY_INFO controlq message can be
+constructed using the following structure:
+/* controlq message: VHOST_PCI_MSG_TYPE_MEMORY_INFO */
+struct vhost_pci_controlq_memory_info {
+#define VHOST_PCI_ADD_MEMORY 0
+#define VHOST_PCI_DEL_MEMORY 1
+   u16  ops;
+   u32 nregion;
+   struct exotic_memory_region {
+   u64   region_base_xgpa;
+   u64   size;
+   u64   offset_in_bar_area;
+   } region[VHOST_PCI_MAX_NREGIONS];
+};
+
+The payload of VHOST_PCI_MSG_TYPE_DEVICE_INFO and
+VHOST_PCI_MSG_TYPE_FEATURE_BITS socket/controlq messages can be constructed
+using the following vhost_pci_device_info structure and
+the vhost_pci_feature_bits structure respectively.
+
+/* socket/controlq message: VHOST_PCI_DEVICE_INFO */
+struct vhost_pci_device_info {
+#define VHOST_PCI_ADD_FRONTEND_DEVICE 0
+#define VHOST_PCI_DEL_FRONTEND_DEVICE 1
+   u16ops;
+   u32nvirtq;
+   u32device_type;
+   u64device_id;
+   struct virtq exotic_virtq[VHOST_PCI_MAX_NVIRTQ];
+};
+
+/* socket/controlq message: VHOST_PCI_MSG_TYPE_FEATURE_BITS */
+struct vhost_pci_feature_bits {
+   u64 feature_bits;
+};
+
+The payload of all the ACK socket/controlq messages can be constructed using
+the following structure:
+/* socket/controlq message: ACK