Re: [Qemu-devel] [PATCH 7/8] pseries: savevm support for PAPR virtual SCSI
On 05/31/2013 08:41 PM, Paolo Bonzini wrote:
Il 31/05/2013 12:25, Alexey Kardashevskiy ha scritto:
On 05/31/2013 08:07 PM, Benjamin Herrenschmidt wrote:
On Fri, 2013-05-31 at 15:58 +1000, Alexey Kardashevskiy wrote:
And another question (sorry I am not very familiar with terminology but
cc:Ben is :) ) - what happens with indirect requests if migration happened
in the middle of handling such a request? virtio-scsi does not seem to
handle this situation anyhow, it just reconstructs the whole request and
that's it.
So Paolo, the crux of the question here is really whether we have any
guarantee about the state of the request when this happens (by this I
mean a save happening with requests still in flight) ?
IE. Can the request can be at any stage of processing, with the data
transfer phase being half way through, or do we somewhat know for sure
that the request will *not* have started transferring any data ?
This is key, because in the latter case, all we really need to do is
save the request itself, and re-parse it on restore as if it was
new really (at least from a DMA descriptor perspective).
However, if the data transfer is already half way through, we need to
somewhat save the state of the data transfer machinery, ie. the position
of the cursor that follows the guest-provided DMA descriptor list,
etc... (which isn't *that* trivial since we have a concept of indirect
descriptors and we use pointers to follow them, so we'd probably have
to re-walk the whole user descriptors list until we reach the same
position).
It may be halfway through, but it is always restarted on the destination.
virtio-scsi parses the whole descriptor chain upfront and sends the
guest addresses in the migration stream.
Is not it the same QEMU thread which handles hcalls and QEMU console
commands so the migration cannot stop parsing/handling a vscsi_req?
The VM is paused and I/O is flushed at the point when the reqs are sent.
That's why you couldn't get a pending request. Only failed requests
remain in queue.
Ok. I implemented {save|load}_request for IBMVSCSI, started testing - the
destination system behaves very unstable, sometime it is a fault in
_raw_spin_lock or it looks okay but any attempt to read the filesystem
leads to 100% cpu load in qemu process and no response from the guest.
I tried virtio-scsi as well (as it was referred as a good example), it
fails in exactly the same way. So I started wondering - when did you try it
last time? :)
My test is:
1. create qcow2 image 8GB, put it to 2GB USB disk.
2. put 1.8GB dummy image onto the same USB disk.
3. run qemu with qcow2 image.
4. do mkfs.ext4 /dev/sda in the guest. It creates 300MB file when there
is enough space.
5. wait till the source qemu gets stopped due to io error (info status
confirms this).
6. migrate.
7. remove dummy.
8. continue in the destination guest.
Is it good/bad/ugly? What do I miss? Thanks!
--
Alexey
Re: [Qemu-devel] [PATCH 7/8] pseries: savevm support for PAPR virtual SCSI
Il 01/06/2013 02:01, Benjamin Herrenschmidt ha scritto: On Fri, 2013-05-31 at 12:41 +0200, Paolo Bonzini wrote: It may be halfway through, but it is always restarted on the destination. restarted as in the whole transfer is restarted if any right ? So we can essentially consider as a new request for which we just did scsi_req_enqueue() ? IE. We don't do direct DMA to guest pages just yet (we still do copies) so basically our process is: 1- Obtain request from guest 2- Queue it (scsi_req_enqueue) 3- No transfer - go away (completion is called) 4- Pre-process user descriptors (check desc type direct vs indirect, position our cursor walking them etc) 5- scsi_req_continue() .../... loop of callbacks transfer Now from what you say, I assume that regardless of the point where the request was, when we resume it will always be at step 4 ? IE. I can just pre-process the descriptors again ? (I actually need to transfer them again from the guest since I suspect I clobber them at the very least due to byteswap) and call scsi_req_continue() and assume the transfer (if any) started from the beginning ? Yes. Unless the spec somehow lets the guest figure out the point at which the whole chain has been pre-processed, and lets the guest modify the chain at this point. But if that's not the case, you can do that. Memory has already been loaded when load_request runs. Paolo
Re: [Qemu-devel] [PATCH 7/8] pseries: savevm support for PAPR virtual SCSI
Il 03/06/2013 07:46, Alexey Kardashevskiy ha scritto:
Ok. I implemented {save|load}_request for IBMVSCSI, started testing - the
destination system behaves very unstable, sometime it is a fault in
_raw_spin_lock or it looks okay but any attempt to read the filesystem
leads to 100% cpu load in qemu process and no response from the guest.
I tried virtio-scsi as well (as it was referred as a good example), it
fails in exactly the same way. So I started wondering - when did you try it
last time? :)
Perhaps a year ago. Gerd must have tested usb-storage later than that
though.
My test is:
1. create qcow2 image 8GB, put it to 2GB USB disk.
2. put 1.8GB dummy image onto the same USB disk.
3. run qemu with qcow2 image.
4. do mkfs.ext4 /dev/sda in the guest. It creates 300MB file when there
is enough space.
5. wait till the source qemu gets stopped due to io error (info status
confirms this).
6. migrate.
7. remove dummy.
8. continue in the destination guest.
Sounds good. We really need testcases for this. I'll take a look when
I come back from vacation.
Paolo
Re: [Qemu-devel] [SeaBIOS] KVM call agenda for 2013-05-28
Il 02/06/2013 17:05, Gleb Natapov ha scritto: Anthony requested that patches be made that generate the ACPI tables in QEMU for the upcoming hotplug work, so that they could be evaluated to see if they truly do need to live in QEMU or if the code could live in the firmware. There were no objections. I volunteered to implement this. Why hotplug should generate ACPI code? It does not do so on real HW. Hotplug can do a LoadTable and merge it into the existing ones. But then you do not need QEMU-time generation of tables to do the same thing for cold-plug. Paolo
Re: [Qemu-devel] fstrim and cache=none
Il 02/06/2013 22:21, Dusty Mabe ha scritto: Hi, Is it valid to have cache=none and discard=unmap together? I notice that when I have cache=none the fstrim operations inside of my guests gives me an error What error? Can you add an extra disk and try dd if=/dev/urandom of=/dev/sdc bs=1M count=32 sg_unmap -l0 -n64 /dev/sdc from within the guest? and i get this from the sys filesystem: [root@guest ~]# cat /sys/block/sdb/queue/discard* 4096 0 0 This is expected. It won't change between discard=unmap and discard=ignore, too. (Tip: Use grep . /sys/block/sdb/queue/discard* so that it shows the filename). This wasn't very obvious to me to begin with and just wanted to see if this is a bug or as designed. It should be. It may be a Linux bug, too. Paolo
Re: [Qemu-devel] [PATCH 14/15] memory: return MemoryRegion from qemu_ram_addr_from_host
Il 02/06/2013 18:04, Peter Maydell ha scritto: On 2 June 2013 16:43, Paolo Bonzini pbonz...@redhat.com wrote: -int qemu_ram_addr_from_host(void *ptr, ram_addr_t *ram_addr); +MemoryRegion *qemu_ram_addr_from_host(void *ptr, ram_addr_t *ram_addr); ram_addr_t qemu_ram_addr_from_host_nofail(void *ptr); This is weird, because now the _nofail and the standard versions of this function return different things. Why wouldn't a caller of the _nofail version potentially need the MemoryRegion* too? I'll adjust both functions. Paolo
Re: [Qemu-devel] [PATCH 00/15] Memory/IOMMU patches part 4: region ownership
Il 02/06/2013 18:12, Peter Maydell ha scritto: On 2 June 2013 16:43, Paolo Bonzini pbonz...@redhat.com wrote: Reference counting the region piggybacks on reference counting of a QOM object, the owner of the region. The owner API is designed so that it will be called as little as possible. Unowned subregions will get a region if memory_region_set_owner is called after the subregion is added. This is in general the common case already; often setting the owner can be delegated to a bus-specific API that already takes a DeviceState (for example pci_register_bar or sysbus_init_mmio). This feels a bit fragile to me -- there doesn't seem to be a clear rule for who has to set the owner of a region or when they have to do it, or for ensuring that it doesn't get forgotten altogether. The best rule would be who creates it. This would touch half the files in hw/, which I am trying to avoid. So I'm settling for: * in general, the bus sets the owner for regions that are managed by the bus (patches 5/6/9); * if the device plays directly with address_space_memory/io (shouldn't happen except in very special cases, such as patch 7) or if regions are added/deleted dynamically to a container (patches 8/10/11/12), then the device must set the owner itself. All stuff that should be in a comment, I guess... What happens if I take a MemoryRegion* that another device has exposed to me as a sysbus mmio region (and so claimed ownership of) and pass it to pci_register_bar()? You get an assertion failure. Who owns it at that point? [That's a legitimate thing to do, I think, though I don't suppose anybody does it at the moment. Sysbus MMIOs aren't only for mapping in the system address space, they're a general way for one device to expose a MemoryRegion * for use by another device.] I don't think it is legitimate, MMIO regions are just for use via sysbus_map_mmio. But the same scenario could apply without sysbus MMIO in the future (e.g. via QOM properties), so it is a good question. The right thing to do is to use a container or alias region, and put the 1st region inside it. Then the 1st region keeps its owner, and the container/alias gets a new one. Paolo
Re: [Qemu-devel] [PATCH 02/15] memory: add ref/unref
Il 02/06/2013 17:58, Peter Maydell ha scritto: + * memory_region_ref: Add 1 to a memory region's reference count + * + * Whenever memory regions are accessed outside the BQL, they need to be + * preserved against hot-unplug. MemoryRegions actually do not have their + * own reference count; they piggyback on a QOM object, their owner. + * This function adds a reference to the owner. It doesn't make much sense to describe the function as add 1 to a memory region's reference count and then say that memory regions don't have reference counts... The fact that the reference count is the owner's is really an implementation detail. The reference count is used entirely as if it were the region's. So the summary says it is the region's, the long description says what happens under the hood. Suggestions on rephrasing the comments are welcome. Paolo
Re: [Qemu-devel] [PATCH uq/master] fix double free the memslot in kvm_set_phys_mem
On Fri, May 31, 2013 at 04:52:18PM +0800, Xiao Guangrong wrote:
Luiz Capitulino reported that guest refused to boot and qemu
complained with:
kvm_set_phys_mem: error unregistering overlapping slot: Invalid argument
It is caused by commit 235e8982ad that did double free for the memslot
so that the second one raises the -EINVAL error
Fix it by reset memory size only if it is needed
Reported-by: Luiz Capitulino lcapitul...@redhat.com
Signed-off-by: Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com
Thanks, applied.
---
kvm-all.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/kvm-all.c b/kvm-all.c
index 8e7bbf8..405480e 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -206,7 +206,8 @@ static int kvm_set_user_memory_region(KVMState *s,
KVMSlot *slot)
if (s-migration_log) {
mem.flags |= KVM_MEM_LOG_DIRTY_PAGES;
}
-if (mem.flags KVM_MEM_READONLY) {
+
+if (slot-memory_size mem.flags KVM_MEM_READONLY) {
/* Set the slot size to 0 before setting the slot to the desired
* value. This is needed based on KVM commit 75d61fbc. */
mem.memory_size = 0;
--
1.7.7.6
--
Gleb.
Re: [Qemu-devel] [PATCH v2] virtio-rng: Fix crash with non-default backend
On (Fri) 31 May 2013 [14:12:48], Cole Robinson wrote: 'default_backend' isn't always set, but 'rng' is, so use that. $ ./x86_64-softmmu/qemu-system-x86_64 -object rng-random,id=rng0,filename=/dev/random -device virtio-rng-pci,rng=rng0 Segmentation fault (core dumped) Regressed with virtio refactoring in 59ccd20a9ac719cff82180429458728f03ec612f CC: qemu-sta...@nongnu.org Signed-off-by: Cole Robinson crobi...@redhat.com --- Notes: v2: Fix other instances in s390x code, pointed out by Frederic Acked-by: Amit Shah amit.s...@redhat.com Amit
Re: [Qemu-devel] KVM call agenda for 2013-05-28
On Sun, Jun 2, 2013 at 2:43 AM, Michael S. Tsirkin m...@redhat.com wrote: On Fri, May 31, 2013 at 01:45:55PM +0200, Laszlo Ersek wrote: On 05/31/13 09:09, Jordan Justen wrote: Why is updating the ACPI tables in seabios viewed as such a burden? Either qemu does it, or seabios... (And, OVMF too, but I don't think you guys are concerned with that. :) I am :) On the flip side, why is moving the ACPI tables to QEMU such an issue? It seems like Xen and virtualbox both already do this. Why is running iasl not an issue for them? I think something was mentioned about iasl having problems on BE machines? I could be easily wrong but I *guess* qemu's hosts x targets (emulate what on what) set is a proper superset of xen's and virtualbox's. Presumably if you want to run an x86 guest on a MIPS host, and also want to build qemu on the same MIPS (or SPARC) host, you'd have to run iasl there too. You guys should take a look at the patch series I posted. That's solved there by the means of keeping iasl output in qemu git tree. configure checks for a working iasl and enables/disables using this pre-processed output accordingly. Everyone developing ASL code would still need working iasl but that's already the case today. I'm sorry the I haven't had time to review your series yet. But, from what you saying about it in this thread, it sounds like a good plan. -Jordan
Re: [Qemu-devel] [PATCH 06/22] memory: dispatch unassigned accesses based on .valid.accepts
Il 01/06/2013 17:28, Blue Swirl ha scritto: This means that memory.c is getting knowledge about CPU types and it becomes more specific to current target. I think memory.c should be generic and target agnostic (maybe one day compiled just once) with exec.c implementing the target specific functionality. You're right, but the solution is simply to make cpu_unassigned_access a CPU method. Paolo
Re: [Qemu-devel] latest qemu with gdb remote not working
Hi Peter and Peter :) On Sun, Jun 2, 2013 at 7:27 PM, Peter Maydell peter.mayd...@linaro.org wrote: On 2 June 2013 06:46, Peter Cheung mcheun...@hotmail.com wrote: I just tried to compile the latest qemu on Fedora 18 64 bits, it is also fail. When i press c in gdb, the qemu won't start running. Good. This significantly increases the chances that somebody will investigate. I think I may have replicated as well. qemu-system-arm on Ubuntu 10.04 host. And it works again for me after a revert of: commit 87f25c12bfeaaa0c41fb857713bbc7e8a9b757dc Author: Paolo Bonzini pbonz...@redhat.com Date: Thu May 30 13:20:40 2013 +0200 gdbstub: do not restart crashed guest If a guest has crashed with an internal error or similar, detaching gdb (or any other debugger action) should not restart it. Cc: Jan Kiszka jan.kis...@siemens.com Signed-off-by: Paolo Bonzini pbonz...@redhat.com Reviewed-by: Laszlo Ersek ler...@redhat.com Message-id: 1369912840-18577-1-git-send-email-pbonz...@redhat.com Signed-off-by: Anthony Liguori aligu...@us.ibm.com Ill dig further before sending through minimal replication instructions (gotta run!) but Peter Cheung, can you please try your test case after reverting this commit, to see if its perhaps the same bug? $ git revert 87f25c12bfeaaa0c41fb857713bbc7e8a9b757dc Regards, Peter But one thing fedora is different than mac, when i connect gdb to qemu, it won't say warning: Error 268435459 getting port names from mach_port_names That looks like a Mac GDB specific issue. In my mac, i use gcc from mac port, here is the version detail: /Users/petergcc -v gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00) This is pretty ancient -- I'd suggest using clang to build QEMU instead. (It probably won't fix your problem here, though.) What command line are you using to configure and build QEMU? thanks -- PMM
Re: [Qemu-devel] latest qemu with gdb remote not working
Il 03/06/2013 09:42, Peter Crosthwaite ha scritto: Hi Peter and Peter :) On Sun, Jun 2, 2013 at 7:27 PM, Peter Maydell peter.mayd...@linaro.org wrote: On 2 June 2013 06:46, Peter Cheung mcheun...@hotmail.com wrote: I just tried to compile the latest qemu on Fedora 18 64 bits, it is also fail. When i press c in gdb, the qemu won't start running. Good. This significantly increases the chances that somebody will investigate. I think I may have replicated as well. qemu-system-arm on Ubuntu 10.04 host. And it works again for me after a revert of: commit 87f25c12bfeaaa0c41fb857713bbc7e8a9b757dc Author: Paolo Bonzini pbonz...@redhat.com Date: Thu May 30 13:20:40 2013 +0200 gdbstub: do not restart crashed guest If a guest has crashed with an internal error or similar, detaching gdb (or any other debugger action) should not restart it. Cc: Jan Kiszka jan.kis...@siemens.com Signed-off-by: Paolo Bonzini pbonz...@redhat.com Reviewed-by: Laszlo Ersek ler...@redhat.com Message-id: 1369912840-18577-1-git-send-email-pbonz...@redhat.com Signed-off-by: Anthony Liguori aligu...@us.ibm.com Oops, indeed you need to type cont in both gdb and the monitor after this patch. Funny I didn't notice; the fix should be to use !runstate_needs_reset() instead of runstate_check(RUN_STATE_DEBUG). But it is likely a different bug than the Mac OS X one. Paolo Ill dig further before sending through minimal replication instructions (gotta run!) but Peter Cheung, can you please try your test case after reverting this commit, to see if its perhaps the same bug? $ git revert 87f25c12bfeaaa0c41fb857713bbc7e8a9b757dc Regards, Peter But one thing fedora is different than mac, when i connect gdb to qemu, it won't say warning: Error 268435459 getting port names from mach_port_names That looks like a Mac GDB specific issue. In my mac, i use gcc from mac port, here is the version detail: /Users/petergcc -v gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00) This is pretty ancient -- I'd suggest using clang to build QEMU instead. (It probably won't fix your problem here, though.) What command line are you using to configure and build QEMU? thanks -- PMM
Re: [Qemu-devel] [PATCH] do not check pointers after dereferencing them
On Fri, May 31, 2013 at 06:46:21AM -0600, Eric Blake wrote: On 05/31/2013 06:00 AM, Paolo Bonzini wrote: Two instances, both spotted by Coverity. In one, two blocks were swapped. In the other, the check is not needed anymore. Cc: qemu-sta...@nongnu.org Cc: qemu-triv...@nongnu.org Signed-off-by: Paolo Bonzini pbonz...@redhat.com --- monitor.c | 2 +- savevm.c | 10 +- 2 files changed, 6 insertions(+), 6 deletions(-) This version of the savevm.c fix is nicer than Stefan's attempt: https://lists.gnu.org/archive/html/qemu-devel/2013-05/msg04506.html Reviewed-by: Eric Blake ebl...@redhat.com I'll drop mine. I didn't dare to swap the blocks just in case something dependend on doing the popen() and bailing out afterwards, but it's hard to imagine that. Stefan
Re: [Qemu-devel] [PATCH 7/8] pseries: savevm support for PAPR virtual SCSI
On Mon, 2013-06-03 at 15:46 +1000, Alexey Kardashevskiy wrote:
Ok. I implemented {save|load}_request for IBMVSCSI, started testing -
the
destination system behaves very unstable, sometime it is a fault in
_raw_spin_lock or it looks okay but any attempt to read the filesystem
leads to 100% cpu load in qemu process and no response from the guest.
I tried virtio-scsi as well (as it was referred as a good example), it
fails in exactly the same way. So I started wondering - when did you
try it
last time? :)
Did you try virtio-blk or even a ramdisk ? IE, Make sure the problem
isn't some kind of generic migration issue unrelated to storage ?
Cheers,
Ben.
Re: [Qemu-devel] [Qemu-stable] [QEMU PATCH v3] qdev: fix get_fw_dev_path to support to add nothing to fw_dev_path
Am 31.05.2013 13:02, schrieb Amos Kong: ... thanks for this great explanation. I've done what you sayd but it still does not work. Here is the output of the seabis debug log where you see the loop: http://pastebin.com/raw.php?i=e53rdW2b | found virtio-scsi at 0:5 | Searching bootorder for: /pci@i0cf8/*@5/*@0/*@0,0 | virtio-scsi vendor='QEMU' product='QEMU HARDDISK' rev='1.5.' type=0 removable=0 | virtio-scsi blksize=512 sectors=104857600 It mean the fixed fw_dev_path can be identified. You problem is a disrelated issue. I didn't see handle_18 before restart, it means guest succeses to boot from second nic. How does the resume be caused? No it def. does not succeed. Only the first nic gets a reply from a tftp server. It shows a menu and then does: localboot -1 which causes to go to the next boot device (pxelinux.cfg). It then tries to boot from the 2nd nic. But there it gets only an IP through DHCP but no tftp details or even an answer. PS: this was working fine with Qemu 1.4.2 Please only aasign two nics for guest, let's see if restart occurs. With one nic i see correctly - no bootable device restart in 1 sec. With only two nics the screen just turns black and nothing happens at all after trying PXE from 2nd nic. But no message and no restart. Did you config pxe+tftp service for second nic? did you set some rom that just reboot the system? DHCP yes tftp service no. Stefan
[Qemu-devel] [PATCH v2 2/2] ivshmem: add missing error exit(2)
If the user fails to specify 'chardev' or 'shm' then we cannot continue.
Exit right away so that we don't invoke shm_open(3) with a NULL pointer.
It would be nice to replace exit(1) with error returns in the PCI device
.init() function, but leave that for another patch since exit(1) is
currently used elsewhere.
Spotted by Coverity.
Cc: Cam Macdonell c...@cs.ualberta.ca
Cc: qemu-sta...@nongnu.org
Signed-off-by: Stefan Hajnoczi stefa...@redhat.com
---
hw/misc/ivshmem.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/hw/misc/ivshmem.c b/hw/misc/ivshmem.c
index a19a6d6..5658f73 100644
--- a/hw/misc/ivshmem.c
+++ b/hw/misc/ivshmem.c
@@ -735,6 +735,7 @@ static int pci_ivshmem_init(PCIDevice *dev)
if (s-shmobj == NULL) {
fprintf(stderr, Must specify 'chardev' or 'shm' to ivshmem\n);
+exit(1);
}
IVSHMEM_DPRINTF(using shm_open (shm object = %s)\n, s-shmobj);
--
1.8.1.4
[Qemu-devel] [PATCH v2 1/2] vhost-scsi: fix k-set_guest_notifiers() NULL dereference
Coverity picked up a copy-paste bug. In vhost_scsi_start() we check for
!k-set_guest_notifiers and error out. The check probably got copied
but instead of erroring we actually use the function pointer!
Cc: Nicholas Bellinger n...@linux-iscsi.org
Cc: Asias He as...@redhat.com
Cc: qemu-sta...@nongnu.org
Signed-off-by: Stefan Hajnoczi stefa...@redhat.com
---
hw/scsi/vhost-scsi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/scsi/vhost-scsi.c b/hw/scsi/vhost-scsi.c
index d7a1c33..785e93f 100644
--- a/hw/scsi/vhost-scsi.c
+++ b/hw/scsi/vhost-scsi.c
@@ -123,7 +123,7 @@ static void vhost_scsi_stop(VHostSCSI *s)
VirtioBusClass *k = VIRTIO_BUS_GET_CLASS(qbus);
int ret = 0;
-if (!k-set_guest_notifiers) {
+if (k-set_guest_notifiers) {
ret = k-set_guest_notifiers(qbus-parent, s-dev.nvqs, false);
if (ret 0) {
error_report(vhost guest notifier cleanup failed: %d\n, ret);
--
1.8.1.4
[Qemu-devel] [PATCH v2 0/2] vhost-scsi and ivshmem fixes for Coverity issues
The following fixes address NULL pointer dereferences spotted by Coverity. v2: * Dropped savevm.c popen(3) leak fix since Paolo has a better fix [eblake] Stefan Hajnoczi (2): vhost-scsi: fix k-set_guest_notifiers() NULL dereference ivshmem: add missing error exit(2) hw/misc/ivshmem.c| 1 + hw/scsi/vhost-scsi.c | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) -- 1.8.1.4
Re: [Qemu-devel] [PATCH v2 1/2] vhost-scsi: fix k-set_guest_notifiers() NULL dereference
Il 03/06/2013 10:58, Stefan Hajnoczi ha scritto:
Coverity picked up a copy-paste bug. In vhost_scsi_start() we check for
!k-set_guest_notifiers and error out. The check probably got copied
but instead of erroring we actually use the function pointer!
Exactly. :)
Applied to scsi branch, thanks.
Paolo
Cc: Nicholas Bellinger n...@linux-iscsi.org
Cc: Asias He as...@redhat.com
Cc: qemu-sta...@nongnu.org
Signed-off-by: Stefan Hajnoczi stefa...@redhat.com
---
hw/scsi/vhost-scsi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/scsi/vhost-scsi.c b/hw/scsi/vhost-scsi.c
index d7a1c33..785e93f 100644
--- a/hw/scsi/vhost-scsi.c
+++ b/hw/scsi/vhost-scsi.c
@@ -123,7 +123,7 @@ static void vhost_scsi_stop(VHostSCSI *s)
VirtioBusClass *k = VIRTIO_BUS_GET_CLASS(qbus);
int ret = 0;
-if (!k-set_guest_notifiers) {
+if (k-set_guest_notifiers) {
ret = k-set_guest_notifiers(qbus-parent, s-dev.nvqs, false);
if (ret 0) {
error_report(vhost guest notifier cleanup failed: %d\n,
ret);
Re: [Qemu-devel] [PATCH v5 01/11] notify: add NotiferWithReturn so notifier list can abort
On Thu, May 30, 2013 at 04:27:48PM -0600, Eric Blake wrote: On 05/30/2013 06:34 AM, Stefan Hajnoczi wrote: notifier_list_notify() has no return value. This is fine when we just want to invoke side-effects. Sometimes it's useful for notifiers to produce a return value. This allows notifiers to veto an operation and will be used by the block layer before-write notifier. Signed-off-by: Stefan Hajnoczi stefa...@redhat.com --- include/qemu/notify.h | 25 + util/notify.c | 30 ++ 2 files changed, 55 insertions(+) diff --git a/include/qemu/notify.h b/include/qemu/notify.h index 4e2e7f0..d3103e7 100644 --- a/include/qemu/notify.h +++ b/include/qemu/notify.h @@ -40,4 +40,29 @@ void notifier_remove(Notifier *notifier); void notifier_list_notify(NotifierList *list, void *data); +/* Same as Notifier but allows .notify() to return errors */ It's probably worth documenting that the callback must return 0 for success, and that the first non-zero return is passed back without further interpretation (thus allowing negative errno values if desired, vs. a simpler -1). You are right, let's improve the doc comments. Isn't this really just syntax sugar since existing notifiers could already use a member within the opaque *data argument as a way to short-circuit later notifiers on earlier errors? If so, how hard would it be to scrub the existing code base to always return 0 in existing notifiers, rather than adding a parallel naming scheme? I considered both approaches and decided on NotifierWithReturn because it neither touches existing users nor adds a side-effect for aborting. BTW adding a side-effect in the BdrvTrackedRequest case is ugly, the struct is used for more than just the pre-write notifier and the field would be useless in the other cases. Stefan
Re: [Qemu-devel] [RFC PATCH v3 00/11] qemu-ga: fsfreeze on Windows using VSS
Hi,
Thanks for your advice,it works well when using prefix=x86_64-w64-mingw32-.
The dlls may download from here: http://qemu.weilnetz.de/w64/dll/.
One more question:
Qemu-ga.exe can't run successfully under normal account which belongs to
Administration group.
Qemu-ga service can start successfully under this account after
Administrator installed.
The output is:
1370307591.689600:critical:error opening path
1370307591.705200:critical:error opening channel
1370307591.720800:critical:failed to create guest agent channel
1370307591.736400:critical:failed to initialize guest agent channel
Could you give me some advise to debug this problem ? I can provide more
information if need.
Regards,
baiqing
-Original Message-
From: Tomoki Sekiyama [mailto:tomoki.sekiy...@hds.com]
Sent: Friday, May 31, 2013 10:20 AM
To: Libaiqing; qemu-devel@nongnu.org
Cc: mdr...@linux.vnet.ibm.com; lcapitul...@redhat.com;
vroze...@redhat.com; pbonz...@redhat.com; Seiji Aguchi; ar...@redhat.com;
Haofeng
Subject: RE: [Qemu-devel] [RFC PATCH v3 00/11] qemu-ga: fsfreeze on Windows
using VSS
Hi Baiqing,
Provider.dll is built with --cross-prefix=i686-w64-mingw32-, does it support
64-bit system?
No. The DLL is dynamic-linked to the VSS system component, so it must be built
for the same architecture (32-bit (i686) or 64-bit (x86_64)) as the operating
system you run.
Thanks,
Tomoki Sekiyama
From: Libaiqing [libaiq...@huawei.com]
Sent: Thursday, May 30, 2013 9:30 PM
To: Tomoki Sekiyama; qemu-devel@nongnu.org
Cc: mdr...@linux.vnet.ibm.com; lcapitul...@redhat.com;
vroze...@redhat.com; pbonz...@redhat.com; Seiji Aguchi; ar...@redhat.com;
Haofeng
Subject: RE: [Qemu-devel] [RFC PATCH v3 00/11] qemu-ga: fsfreeze on Windows
using VSS
Hi,
When installing the guest-agent on windows2008R2, an error occurs.
Executing command qemu-ga.exe -s install,
the app popups a dialog box with the message:
CoCreateInstance(VSSCoordinator)failed.(Error:80010154)
the commandline output isFailed to
pCatalog-InstallComponent.(Error:80110401) ..
Provider.dll is built with --cross-prefix=i686-w64-mingw32-, does it support
64-bit system?
I also found some info from ms webstie:
http://msdn.microsoft.com/en-us/library/aa384627(v=vs.85).aspx
Could you give me some advise to debug this problem ? I can provide more
information if need.
Regards,
baiqing
-Original Message-
From: qemu-devel-bounces+libaiqing=huawei@nongnu.org
[mailto:qemu-devel-bounces+libaiqing=huawei@nongnu.org] On Behalf
Of
Tomoki Sekiyama
Sent: Tuesday, May 21, 2013 11:34 PM
To: qemu-devel@nongnu.org
Cc: mdr...@linux.vnet.ibm.com; lcapitul...@redhat.com;
vroze...@redhat.com; pbonz...@redhat.com; seiji.agu...@hds.com;
ar...@redhat.com
Subject: [Qemu-devel] [RFC PATCH v3 00/11] qemu-ga: fsfreeze on Windows
using VSS
Hi,
This patch series adds fsfreeze support for Windows qemu-guest-agent.
changes from v2:
- [06/11] Fix errors in Windows 7, reported by Li Baiqing
(see below for details).
changes from v1:
- Fix out-tree build by stop using recursive Makefile
- Added script to extract VSS SDK headers on POSIX systems using msitools
(thanks Paolo)
- Remove some unnecessary header files
v2: http://lists.gnu.org/archive/html/qemu-devel/2013-04/msg02518.html
* Description
In Windows, VSS (Volume Shadow Copy Service) provides a facility to
quiesce filesystems and applications before disk snapshots are taken.
This patch series implements fsfreeze command of qemu-ga using VSS.
* How to build run qemu-ga with VSS support
- Download Microsoft VSS SDK from:
http://www.microsoft.com/en-us/download/details.aspx?id=23490
- Setup the SDK
scripts/extract-vsssdk-headers setup.exe (on POSIX-systems)
- Specify installed SDK directory to configure option as:
./configure -with-vss-sdk=path/to/VSS SDK
--cross-prefix=i686-w64-mingw32-
- make qemu-ga.exe
- Install qemu-ga.exe, qga/vss-win32-provider/qga-provider.{dll,tlb}, and
the other required mingw libraries into the same directory in guests
- Run `qemu-ga.exe -s install' and `net start qemu-ga' in the guests
* About errors in Windows 7 with patch v2
VSS requires to write to snapshot volumes just before making them
read-only
at final commit phase. This feature is called `auto-recovery'
(See
http://msdn.microsoft.com/en-us/library/windows/desktop/aa384651(v=vs.85)
.aspx#base.vssgloss_auto_recoved_shadow_copy for details).
Since qemu and libvirt don't have feature to handle writable snapshots,
this patchset just disables auto-recovery by specifying
VSS_VOLSNAP_ATTR_NO_AUTORECOVERY flag to SetContext.
Unfortunately, this flag seems unsupported in Windows 7 or earlier.
It tries to look up the
[Qemu-devel] [PATCH] net: tap: fix NULL dereference when passing both fd and vhostfds to tap
This is because vhostfdname were passed as NULL to net_init_tap_one() when
vhostfd were not specified, but net_init_tap_one() will still pass it to
monitor_handle_fd_param() when tap-has_vhostfds is true. Since file descriptor
(fd, vhostfd) and file descriptor set (fds, vhostfds) were not compatible, so
this patch forbids passing them to tap in the same time.
This solve the segfault when passing the command line like:
./qemu-system-x86_64 -netdev tap,fd=2,vhost=on,vhostfds=baz,id=xyz
Cc: Paolo Bonzini pbonz...@redhat.com
Cc: Stefan Hajnoczi shajn...@redhat.com
Cc: Laszlo Ersek ler...@redhat.com
Cc: qemu-sta...@nongnu.org
Signed-off-by: Jason Wang jasow...@redhat.com
---
net/tap.c | 10 ++
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/net/tap.c b/net/tap.c
index e0b7a2a..477505f 100644
--- a/net/tap.c
+++ b/net/tap.c
@@ -698,9 +698,10 @@ int net_init_tap(const NetClientOptions *opts, const char
*name,
if (tap-has_fd) {
if (tap-has_ifname || tap-has_script || tap-has_downscript ||
tap-has_vnet_hdr || tap-has_helper || tap-has_queues ||
-tap-has_fds) {
+tap-has_fds || tap-has_vhostfds) {
error_report(ifname=, script=, downscript=, vnet_hdr=,
- helper=, queues=, and fds= are invalid with fd=);
+ helper=, queues=, fds=, and vhostfds=
+ are invalid with fd=);
return -1;
}
@@ -725,9 +726,10 @@ int net_init_tap(const NetClientOptions *opts, const char
*name,
if (tap-has_ifname || tap-has_script || tap-has_downscript ||
tap-has_vnet_hdr || tap-has_helper || tap-has_queues ||
-tap-has_fd) {
+tap-has_fd || tap-has_vhostfd) {
error_report(ifname=, script=, downscript=, vnet_hdr=,
- helper=, queues=, and fd= are invalid with fds=);
+ helper=, queues=, fd=, and vhostfd=
+ are invalid with fds=);
return -1;
}
--
1.7.1
Re: [Qemu-devel] [PATCH] softfloat: Fix shift128Right for shift counts 64..127
Il 02/06/2013 17:17, Peter Maydell ha scritto:
shift128Right would give the wrong result for a shift count
between 64 and 127. This was never noticed because all of
our uses of this function are guaranteed not to use shift
counts in this range.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
Found by code inspection. This contribution can be licensed
under either the softfloat-2a or -2b license.
fpu/softfloat-macros.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fpu/softfloat-macros.h b/fpu/softfloat-macros.h
index b5164af..9b09545 100644
--- a/fpu/softfloat-macros.h
+++ b/fpu/softfloat-macros.h
@@ -168,7 +168,7 @@ INLINE void
z0 = a0count;
}
else {
-z1 = ( count 64 ) ? ( a0( count 63 ) ) : 0;
+z1 = (count 128) ? (a0 (count 63)) : 0;
z0 = 0;
}
*z1Ptr = z1;
Reviewed-by: Paolo Bonzini pbonz...@redhat.com
Re: [Qemu-devel] [PATCH v5 08/11] blockdev: allow BdrvActionOps-commit() to be NULL
On Thu, May 30, 2013 at 04:57:21PM -0600, Eric Blake wrote: On 05/30/2013 06:34 AM, Stefan Hajnoczi wrote: Some QMP 'transaction' types don't need to do anything on .commit(). Make .commit() optional just like .abort(). The drive-backup action will take advantage of this, it only needs to cancel the block job on .abort(). Other block job actions will probably follow the same pattern, so allow .commit() to be NULL. Suggested-by: Eric Blake ebl...@redhat.com Signed-off-by: Stefan Hajnoczi stefa...@redhat.com --- blockdev.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) Reviewed-by: Eric Blake ebl...@redhat.com Is it worth enforcing that at least one of commit or abort is supplied (that is, assert if the user codes up an action that has neither callback)? Or is that just overkill? I left it out because it seems like overkill. The action types are small in number, statically defined in an array, and we test both the commit and abort code paths. So there's no convenience place to put a compile-time check and developers would stumble across their mistake when running their tests. Stefan
[Qemu-devel] [PATCH trivial] acpi: actually require either data= or file= for -acpitable
Initially the code ensured that we have exactly one of
data= or file= option for -acpitable. But after some
transformations, the condition becomes
if (has_data == has_file) { error }
to mean, probably, that both should not be set at the same
time. But this condition does not cover the case when
neither is set, and we generate bogus acpi table in this
case.
Instead, check if sum of the two is exactly 1.
Signed-off-by: Michael Tokarev m...@tls.msk.ru
---
hw/acpi/core.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/acpi/core.c b/hw/acpi/core.c
index 42eeace..2815d8c 100644
--- a/hw/acpi/core.c
+++ b/hw/acpi/core.c
@@ -249,7 +249,7 @@ void acpi_table_add(const QemuOpts *opts, Error **errp)
if (err) {
goto out;
}
-if (hdrs-has_file == hdrs-has_data) {
+if (!hdrs-has_file + !hdrs-has_data != 1) {
error_setg(err, '-acpitable' requires one of 'data' or 'file');
goto out;
}
--
1.7.10.4
Re: [Qemu-devel] [PATCH v5 10/11] blockdev: add Abort transaction
On Thu, May 30, 2013 at 07:11:25AM -0600, Eric Blake wrote: On 05/30/2013 06:34 AM, Stefan Hajnoczi wrote: The Abort action can be used to test QMP 'transaction' failure. Add it as the last action to exercise the .abort() and .cleanup() code paths for all previous actions. Another thread questioned whether we should name this action __org.qemu-debug-abort, if only to be clear that it is not a normal interface. kwolf: Do you want Abort to be namespaced as a debug-only action? I think it's perfectly supportable so there's no need to hide it. Granted it's rare that anyone would want to use this action. Stefan
Re: [Qemu-devel] [PATCH 00/15] Memory/IOMMU patches part 4: region ownership
On 3 June 2013 07:47, Paolo Bonzini pbonz...@redhat.com wrote: Il 02/06/2013 18:12, Peter Maydell ha scritto: What happens if I take a MemoryRegion* that another device has exposed to me as a sysbus mmio region (and so claimed ownership of) and pass it to pci_register_bar()? You get an assertion failure. Who owns it at that point? [That's a legitimate thing to do, I think, though I don't suppose anybody does it at the moment. Sysbus MMIOs aren't only for mapping in the system address space, they're a general way for one device to expose a MemoryRegion * for use by another device.] I don't think it is legitimate, MMIO regions are just for use via sysbus_map_mmio. This is definitely not true. We already make extensive use of MMIO regions other than simply directly via sysbus_map_mmio. Exposing a MemoryRegion* is just saying here is something I have which is some kind of memory mapped IO, do whatever you need to with it (which might be mapping it directly to the system address space, or might be passing it to some other device that wants a MemoryRegion*, or might be putting it in a container MR or otherwise managing it). For example, arm11mpcore.c does this: sysbus_init_mmio(dev, sysbus_mmio_get_region(s-priv, 0)); which I suspect will assert with your patches. (In general sysbus_mmio_get_region() callers are a good place to look for uses of sysbus MMIOs other than simple mapping.) The right thing to do is to use a container or alias region, and put the 1st region inside it. Then the 1st region keeps its owner, and the container/alias gets a new one. I think the actual right fix is to make the creator of the MR specify its owner. Anything else is just going to have holes in it. thanks -- PMM
Re: [Qemu-devel] [PATCH] kvm: add detail error message when fail to add ioeventfd
On Wed, May 22, 2013 at 12:57:35PM +0800, Amos Kong wrote:
I try to hotplug 28 * 8 multiple-function devices to guest with
old host kernel, ioeventfds in host kernel will be exhausted, then
qemu fails to allocate ioeventfds for blk/nic devices.
It's better to add detail error here.
Applied, thanks.
Signed-off-by: Amos Kong ak...@redhat.com
---
kvm-all.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/kvm-all.c b/kvm-all.c
index 8222729..3d5f7b7 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -813,6 +813,8 @@ static void kvm_mem_ioeventfd_add(MemoryListener
*listener,
r = kvm_set_ioeventfd_mmio(fd, section-offset_within_address_space,
data, true, section-size, match_data);
if (r 0) {
+fprintf(stderr, %s: error adding ioeventfd: %s\n,
+__func__, strerror(-r));
abort();
}
}
@@ -843,6 +845,8 @@ static void kvm_io_ioeventfd_add(MemoryListener *listener,
r = kvm_set_ioeventfd_pio(fd, section-offset_within_address_space,
data, true, section-size, match_data);
if (r 0) {
+fprintf(stderr, %s: error adding ioeventfd: %s\n,
+__func__, strerror(-r));
abort();
}
}
--
1.7.1
--
Gleb.
Re: [Qemu-devel] [PATCH 7/8] pseries: savevm support for PAPR virtual SCSI
On 06/03/2013 06:07 PM, Benjamin Herrenschmidt wrote:
On Mon, 2013-06-03 at 15:46 +1000, Alexey Kardashevskiy wrote:
Ok. I implemented {save|load}_request for IBMVSCSI, started testing -
the
destination system behaves very unstable, sometime it is a fault in
_raw_spin_lock or it looks okay but any attempt to read the filesystem
leads to 100% cpu load in qemu process and no response from the guest.
I tried virtio-scsi as well (as it was referred as a good example), it
fails in exactly the same way. So I started wondering - when did you
try it
last time? :)
Did you try virtio-blk or even a ramdisk ? IE, Make sure the problem
isn't some kind of generic migration issue unrelated to storage ?
False alarm. During multiple switches between different git branches, I
just lost my own patch which disables bulk migration (which we want to
revert anyway, just waiting for the author to do that himself) :)
At least my test does not fail any more. Sorry for confusing.
--
Alexey
Re: [Qemu-devel] [PATCH 00/15] Memory/IOMMU patches part 4: region ownership
Il 03/06/2013 11:22, Peter Maydell ha scritto: Who owns it at that point? [That's a legitimate thing to do, I think, though I don't suppose anybody does it at the moment. Sysbus MMIOs aren't only for mapping in the system address space, they're a general way for one device to expose a MemoryRegion * for use by another device.] I don't think it is legitimate, MMIO regions are just for use via sysbus_map_mmio. This is definitely not true. Indeed a wrong generalization. (Though it is becomes almost true if you replace sysbus_map_mmio with memory_region_add_subregion, for which sysbus_map_mmio is a simple wrapper). We already make extensive use of MMIO regions other than simply directly via sysbus_map_mmio. Exposing a MemoryRegion* is just saying here is something I have which is some kind of memory mapped IO, do whatever you need to with it (which might be mapping it directly to the system address space, or might be passing it to some other device that wants a MemoryRegion*, or might be putting it in a container MR or otherwise managing it). For example, arm11mpcore.c does this: sysbus_init_mmio(dev, sysbus_mmio_get_region(s-priv, 0)); which I suspect will assert with your patches. Thanks for the pointer. All other occurrences of sys_bus_mmio_get_region are either in non-qdevified OMAP code, or they do what I said in my patch. I'll fix a11mpcore to use an alias. The right thing to do is to use a container or alias region, and put the 1st region inside it. Then the 1st region keeps its owner, and the container/alias gets a new one. I think the actual right fix is to make the creator of the MR specify its owner. Anything else is just going to have holes in it. I think the rules I wrote down are easy to understand, and I'd really like to avoid touching 783 instances of memory_region_init*. The patches say that devices doing their own stuff with regions are the exception, not the rule. Thus the bus functions (which already take a DeviceState) are just as good a place to set ownership as memory_region_init*. Paolo
Re: [Qemu-devel] [PATCH 7/8] pseries: savevm support for PAPR virtual SCSI
Il 03/06/2013 11:37, Alexey Kardashevskiy ha scritto:
On 06/03/2013 06:07 PM, Benjamin Herrenschmidt wrote:
On Mon, 2013-06-03 at 15:46 +1000, Alexey Kardashevskiy wrote:
Ok. I implemented {save|load}_request for IBMVSCSI, started testing -
the
destination system behaves very unstable, sometime it is a fault in
_raw_spin_lock or it looks okay but any attempt to read the filesystem
leads to 100% cpu load in qemu process and no response from the guest.
I tried virtio-scsi as well (as it was referred as a good example), it
fails in exactly the same way. So I started wondering - when did you
try it
last time? :)
Did you try virtio-blk or even a ramdisk ? IE, Make sure the problem
isn't some kind of generic migration issue unrelated to storage ?
False alarm. During multiple switches between different git branches, I
just lost my own patch which disables bulk migration (which we want to
revert anyway, just waiting for the author to do that himself) :)
At least my test does not fail any more. Sorry for confusing.
Good, I was surprised. That area doesn't see much testing, but it
hasn't seen much change either.
Paolo
Re: [Qemu-devel] [PATCH 1/4] tcg/aarch64: more low level ops in preparation of tlb, lookup
On 31.05.2013 21:07, Richard Henderson wrote:
On 05/31/2013 10:57 AM, Jani Kokkonen wrote:
+ARITH_SUBS = 0x6b,
Any reason you're adding SUBS here, but not ANDS?
I also forgot ANDS, I'll add them and reorder.
+/* encode a logical immediate, mapping user parameter
+ M=set bits pattern length to S=M-1 */
+static inline unsigned int
+aarch64_limm(unsigned int m, unsigned int r)
+{
+assert(m 0);
+return r 16 | (m - 1) 10;
+}
+
+/* test a register against an immediate bit pattern made of
+ M set bits rotated right by R.
+ Examples:
+ to test a 32/64 reg against 0x0007, pass M = 3, R = 0.
+ to test a 32/64 reg against 0x00ff, pass M = 8, R = 0.
+ to test a 32bit reg against 0xff00, pass M = 8, R = 8.
+ to test a 32bit reg against 0xffff, pass M = 16, R = 8.
+ */
+static inline void tcg_out_tst(TCGContext *s, int ext, TCGReg rn,
+ unsigned int m, unsigned int r)
+{
+/* using TST alias of ANDS XZR, Xn,#bimm64 0x721f */
+unsigned int base = ext ? 0xf240001f : 0x721f;
+tcg_out32(s, base | aarch64_limm(m, r) | rn 5);
+}
+
+/* and a register with a bit pattern, similarly to TST, no flags change */
+static inline void tcg_out_andi(TCGContext *s, int ext, TCGReg rd, TCGReg
rn,
+unsigned int m, unsigned int r)
+{
+/* using AND 0x1200 */
+unsigned int base = ext ? 0x9240 : 0x1200;
+tcg_out32(s, base | aarch64_limm(m, r) | rn 5 | rd);
+}
+
This should be a separate patch, since it's not related to the tcg_out_arith
change.
Agreed.
Claudio
Re: [Qemu-devel] [PATCH 3/4] tcg/aarch64: implement sign/zero extend operations
On 31.05.2013 21:13, Richard Henderson wrote:
On 05/31/2013 11:05 AM, Jani Kokkonen wrote:
+static inline void tcg_out_uxt(TCGContext *s, int s_bits,
+ TCGReg rd, TCGReg rn)
+{
+/* using ALIASes UXTB 0x53001c00, UXTH 0x53003c00
+ of UBFM Wd, Wn, #0, #7|15 and mov */
+int bits = 8 * (1 s_bits) - 1;
+tcg_out_ubfm(s, 0, rd, rn, 0, bits);
+}
Err, ubfm never generates mov, does it?
No, the comment is a leftover, it's wrong.
Yes, you do that later,
+case INDEX_op_ext32u_i64:
+tcg_out_movr(s, 0, args[0], args[1]);
+break;
but the comment isn't actually correct in tcg_out_uxt, surely?
right.
I was think also about the
INDEX_op_ext16u_i64 and INDEX_op_ext16u_i32,
I think I can just use ext = 0 for both when doing the UXT,
consistently to what we discussed before about trying to use
ext=0 whenever possible.
CLaudio
Re: [Qemu-devel] [PATCH 00/15] Memory/IOMMU patches part 4: region ownership
On 3 June 2013 10:40, Paolo Bonzini pbonz...@redhat.com wrote: Il 03/06/2013 11:22, Peter Maydell ha scritto: arm11mpcore.c does this: sysbus_init_mmio(dev, sysbus_mmio_get_region(s-priv, 0)); which I suspect will assert with your patches. Thanks for the pointer. All other occurrences of sys_bus_mmio_get_region are either in non-qdevified OMAP code, or they do what I said in my patch. I'll fix a11mpcore to use an alias. Why? There is no need to -- this should be a perfectly reasonable use of MemoryRegion*s. If your reference counting code can't deal with it you need to fix the reference counting code. thanks -- PMM
Re: [Qemu-devel] [PATCH 2/4] tcg/aarch64: implement byte swap operations
On 31.05.2013 21:11, Richard Henderson wrote:
On 05/31/2013 11:01 AM, Jani Kokkonen wrote:
+static inline void tcg_out_rev(TCGContext *s, int ext, TCGReg rd, TCGReg rm)
+{
+/* using REV 0x5ac00800 */
+unsigned int base = ext ? 0xdac00c00 : 0x5ac00800;
+tcg_out32(s, base | rm 5 | rd);
+}
+
+static inline void tcg_out_rev16(TCGContext *s, int ext, TCGReg rd, TCGReg
rm)
+{
+/* using REV16 0x5ac00400 */
+unsigned int base = ext ? 0xdac00400 : 0x5ac00400;
+tcg_out32(s, base | rm 5 | rd);
+}
+
+static inline void tcg_out_rev32(TCGContext *s, TCGReg rd, TCGReg rm)
+{
+/* using REV32 0xdac00800 */
+unsigned int base = 0xdac00800;
+tcg_out32(s, base | rm 5 | rd);
+}
You don't actually need rev32.
* bswap32_i32/i64 t0, t1
32 bit byte swap on a 32/64 bit value. With a 64 bit value, it assumes that
the four high order bytes are set to zero.
The fact that the high order bytes are known to be zero means that you
can always use tcg_out_rev with ext=0.
case INDEX_op_bswap64_i64:
ext = 1;
/* FALLTHRU */
case INDEX_op_bswap32_i64:
case INDEX_op_bswap32_i32:
tcg_out_rev(s, ext, args[0], args[1]);
break;
case INDEX_op_bswap16_i64:
case INDEX_op_bswap16_i32:
tcg_out_rev16(s, 0, args[0], args[1]);
break;
r~
ACK.
Re: [Qemu-devel] broken incoming migration
On 05/31/2013 12:38 AM, Peter Lieven wrote: Am 30.05.2013 um 15:41 schrieb Paolo Bonzini pbonz...@redhat.com: Il 30/05/2013 11:08, Peter Lieven ha scritto: Am 30.05.2013 10:18, schrieb Alexey Kardashevskiy: On 05/30/2013 05:49 PM, Paolo Bonzini wrote: Il 30/05/2013 09:44, Alexey Kardashevskiy ha scritto: Hi! I found the migration broken on pseries platform, specifically, this patch broke it: f1c72795af573b24a7da5eb52375c9aba8a37972 migration: do not sent zero pages in bulk stage The idea is not to send zero pages to the destination guest which is expected to have 100% empty RAM. However on pseries plaftorm the guest always has some stuff in the RAM as a part of initialization (device tree, system firmware and rtas (?)) so it is not completely empty. As the source guest cannot detect this, it skips some pages during migration and we get a broken destination guest. Bug. While the idea is ok in general, I do not see any easy way to fix it as neither QEMUMachine::init nor QEMUMachine::reset callbacks has information about whether we are about to receive a migration or not (-incoming parameter) and we cannot move device-tree and system firmware initialization anywhere else. ram_bulk_stage is static and cannot be disabled from the platform initialization code. So what would the community suggest? Revert the patch. :) I'll wait for 24 hours (forgot to cc: the author) and then post a revert patch :) does this problem only occur on pseries emulation? Probably not. On a PC, it would occur if you had 4K of zeros in the source BIOS but not in the destination BIOS. When you reboot, the BIOS image is wrong. not sending zero pages is not only a performance benefit it also makes overcomitted memory usable. the madv_dontneed seems to kick in asynchronously and memory is not available immediately. You could also scan the page for nonzero values before writing it. i had this in mind, but then choosed the other approach turned out to be a bad idea. alexey: i will prepare a patch later today, could you then please verify it fixes your problem. Yes I can, where is the patch? :) paolo: would we still need the madvise or is it enough to not write the zeroes? Peter Paolo -- Alexey
[Qemu-devel] [PATCH 3/7] pci: add VMSTATE_MSIX
Using a trick cut+pasted from vmstate_scsi_device
to wind up msix_save and msix_load.
Signed-off-by: Gerd Hoffmann kra...@redhat.com
Acked-by: Michael S. Tsirkin m...@redhat.com
---
hw/pci/msix.c | 33 +
include/hw/pci/msix.h | 11 +++
2 files changed, 44 insertions(+)
diff --git a/hw/pci/msix.c b/hw/pci/msix.c
index e231a0d..6da75ec 100644
--- a/hw/pci/msix.c
+++ b/hw/pci/msix.c
@@ -569,3 +569,36 @@ void msix_unset_vector_notifiers(PCIDevice *dev)
dev-msix_vector_release_notifier = NULL;
dev-msix_vector_poll_notifier = NULL;
}
+
+static void put_msix_state(QEMUFile *f, void *pv, size_t size)
+{
+msix_save(pv, f);
+}
+
+static int get_msix_state(QEMUFile *f, void *pv, size_t size)
+{
+msix_load(pv, f);
+return 0;
+}
+
+static VMStateInfo vmstate_info_msix = {
+.name = msix state,
+.get = get_msix_state,
+.put = put_msix_state,
+};
+
+const VMStateDescription vmstate_msix = {
+.name = msix,
+.fields = (VMStateField[]) {
+{
+.name = msix,
+.version_id = 0,
+.field_exists = NULL,
+.size = 0, /* ouch */
+.info = vmstate_info_msix,
+.flags= VMS_SINGLE,
+.offset = 0,
+},
+VMSTATE_END_OF_LIST()
+}
+};
diff --git a/include/hw/pci/msix.h b/include/hw/pci/msix.h
index e648410..954d82b 100644
--- a/include/hw/pci/msix.h
+++ b/include/hw/pci/msix.h
@@ -43,4 +43,15 @@ int msix_set_vector_notifiers(PCIDevice *dev,
MSIVectorReleaseNotifier release_notifier,
MSIVectorPollNotifier poll_notifier);
void msix_unset_vector_notifiers(PCIDevice *dev);
+
+extern const VMStateDescription vmstate_msix;
+
+#define VMSTATE_MSIX(_field, _state) { \
+.name = (stringify(_field)), \
+.size = sizeof(PCIDevice), \
+.vmsd = vmstate_msix, \
+.flags = VMS_STRUCT,\
+.offset = vmstate_offset_value(_state, _field, PCIDevice), \
+}
+
#endif
--
1.7.9.7
[Qemu-devel] [PATCH 4/7] xhci: add XHCISlot-addressed
Preparing for live-migration support, post_load will need that.
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
hw/usb/hcd-xhci.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/hw/usb/hcd-xhci.c b/hw/usb/hcd-xhci.c
index 8813bdf..ac683ce 100644
--- a/hw/usb/hcd-xhci.c
+++ b/hw/usb/hcd-xhci.c
@@ -405,6 +405,7 @@ struct XHCIEPContext {
typedef struct XHCISlot {
bool enabled;
+bool addressed;
dma_addr_t ctx;
USBPort *uport;
XHCIEPContext * eps[31];
@@ -2041,6 +2042,7 @@ static TRBCCode xhci_disable_slot(XHCIState *xhci,
unsigned int slotid)
}
xhci-slots[slotid-1].enabled = 0;
+xhci-slots[slotid-1].addressed = 0;
return CC_SUCCESS;
}
@@ -2167,6 +2169,7 @@ static TRBCCode xhci_address_slot(XHCIState *xhci,
unsigned int slotid,
xhci_dma_write_u32s(xhci, octx, slot_ctx, sizeof(slot_ctx));
xhci_dma_write_u32s(xhci, octx+32, ep0_ctx, sizeof(ep0_ctx));
+xhci-slots[slotid-1].addressed = 1;
return res;
}
--
1.7.9.7
[Qemu-devel] [PULL 0/7] usb patch queue
Hi, Here is the usb patch queue, bringing two little bug fixes and live migration support for xhci. cheers, Gerd The following changes since commit f10acc8b38d65a66ffa0588a036489d7fa6a593e: tcx: Fix 24-bit display mode (2013-06-02 16:45:40 +) are available in the git repository at: git://git.kraxel.org/qemu usb.83 for you to fetch changes up to 37352df30fbc38d1de464db8927536d5e36cf52a: xhci: add live migration support (2013-06-03 11:38:03 +0200) Ed Maste (1): host-libusb: Correct test for USB packet state Gerd Hoffmann (5): pci: add VMSTATE_MSIX xhci: add XHCISlot-addressed xhci: add xhci_alloc_epctx xhci: add xhci_init_epctx xhci: add live migration support Michael Marineau (1): Fix usage of USB_DEV_FLAG_IS_HOST flag. hw/pci/msix.c | 33 +++ hw/usb/core.c |2 +- hw/usb/hcd-xhci.c | 228 - hw/usb/host-libusb.c |2 +- include/hw/pci/msix.h | 11 +++ 5 files changed, 251 insertions(+), 25 deletions(-)
[Qemu-devel] [PATCH 1/7] Fix usage of USB_DEV_FLAG_IS_HOST flag.
From: Michael Marineau m...@marineau.org
USB_DEV_FLAG_IS_HOST is the bit number, not value. Booting with a
Fitbit Base Station USB dongle was triggering this assert.
Signed-off-by: Michael Marineau m...@marineau.org
Cc: qemu-sta...@nongnu.org
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
hw/usb/core.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/usb/core.c b/hw/usb/core.c
index 15a150a..05948ca 100644
--- a/hw/usb/core.c
+++ b/hw/usb/core.c
@@ -410,7 +410,7 @@ void usb_handle_packet(USBDevice *dev, USBPacket *p)
assert(p-ep-type != USB_ENDPOINT_XFER_ISOC);
/* using async for interrupt packets breaks migration */
assert(p-ep-type != USB_ENDPOINT_XFER_INT ||
- (dev-flags USB_DEV_FLAG_IS_HOST));
+ (dev-flags (1 USB_DEV_FLAG_IS_HOST)));
usb_packet_set_state(p, USB_PACKET_ASYNC);
QTAILQ_INSERT_TAIL(p-ep-queue, p, queue);
} else if (p-status == USB_RET_ADD_TO_QUEUE) {
--
1.7.9.7
[Qemu-devel] [PATCH 5/7] xhci: add xhci_alloc_epctx
Factor out endpoint context allocation to a separate function.
xhci live migration will need that too, in post_load.
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
hw/usb/hcd-xhci.c | 32 +---
1 file changed, 21 insertions(+), 11 deletions(-)
diff --git a/hw/usb/hcd-xhci.c b/hw/usb/hcd-xhci.c
index ac683ce..5084e52 100644
--- a/hw/usb/hcd-xhci.c
+++ b/hw/usb/hcd-xhci.c
@@ -1198,6 +1198,26 @@ static void xhci_ep_kick_timer(void *opaque)
xhci_kick_ep(epctx-xhci, epctx-slotid, epctx-epid, 0);
}
+static XHCIEPContext *xhci_alloc_epctx(XHCIState *xhci,
+ unsigned int slotid,
+ unsigned int epid)
+{
+XHCIEPContext *epctx;
+int i;
+
+epctx = g_new0(XHCIEPContext, 1);
+epctx-xhci = xhci;
+epctx-slotid = slotid;
+epctx-epid = epid;
+
+for (i = 0; i ARRAY_SIZE(epctx-transfers); i++) {
+usb_packet_init(epctx-transfers[i].packet);
+}
+epctx-kick_timer = qemu_new_timer_ns(vm_clock, xhci_ep_kick_timer, epctx);
+
+return epctx;
+}
+
static TRBCCode xhci_enable_ep(XHCIState *xhci, unsigned int slotid,
unsigned int epid, dma_addr_t pctx,
uint32_t *ctx)
@@ -1205,7 +1225,6 @@ static TRBCCode xhci_enable_ep(XHCIState *xhci, unsigned
int slotid,
XHCISlot *slot;
XHCIEPContext *epctx;
dma_addr_t dequeue;
-int i;
trace_usb_xhci_ep_enable(slotid, epid);
assert(slotid = 1 slotid = xhci-numslots);
@@ -1216,12 +1235,7 @@ static TRBCCode xhci_enable_ep(XHCIState *xhci, unsigned
int slotid,
xhci_disable_ep(xhci, slotid, epid);
}
-epctx = g_malloc(sizeof(XHCIEPContext));
-memset(epctx, 0, sizeof(XHCIEPContext));
-epctx-xhci = xhci;
-epctx-slotid = slotid;
-epctx-epid = epid;
-
+epctx = xhci_alloc_epctx(xhci, slotid, epid);
slot-eps[epid-1] = epctx;
dequeue = xhci_addr64(ctx[2] ~0xf, ctx[3]);
@@ -1241,13 +1255,9 @@ static TRBCCode xhci_enable_ep(XHCIState *xhci, unsigned
int slotid,
xhci_ring_init(xhci, epctx-ring, dequeue);
epctx-ring.ccs = ctx[2] 1;
}
-for (i = 0; i ARRAY_SIZE(epctx-transfers); i++) {
-usb_packet_init(epctx-transfers[i].packet);
-}
epctx-interval = 1 (ctx[0] 16) 0xff;
epctx-mfindex_last = 0;
-epctx-kick_timer = qemu_new_timer_ns(vm_clock, xhci_ep_kick_timer, epctx);
epctx-state = EP_RUNNING;
ctx[0] = ~EP_STATE_MASK;
--
1.7.9.7
[Qemu-devel] [PATCH 2/7] host-libusb: Correct test for USB packet state
From: Ed Maste ema...@freebsd.org
USB_RET_ASYNC is -6, so inflight was always false.
Signed-off-by: Ed Maste ema...@freebsd.org
Cc: qemu-sta...@nongnu.org
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
hw/usb/host-libusb.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/usb/host-libusb.c b/hw/usb/host-libusb.c
index f3de459..3a582c5 100644
--- a/hw/usb/host-libusb.c
+++ b/hw/usb/host-libusb.c
@@ -385,7 +385,7 @@ out:
static void usb_host_req_abort(USBHostRequest *r)
{
USBHostDevice *s = r-host;
-bool inflight = (r-p r-p-state == USB_RET_ASYNC);
+bool inflight = (r-p r-p-state == USB_PACKET_ASYNC);
if (inflight) {
r-p-status = USB_RET_NODEV;
--
1.7.9.7
[Qemu-devel] [PATCH 6/7] xhci: add xhci_init_epctx
Factor out endpoint context initialization to a separate function.
xhci live migration will need that too, in post_load.
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
hw/usb/hcd-xhci.c | 43 +--
1 file changed, 25 insertions(+), 18 deletions(-)
diff --git a/hw/usb/hcd-xhci.c b/hw/usb/hcd-xhci.c
index 5084e52..9b90067 100644
--- a/hw/usb/hcd-xhci.c
+++ b/hw/usb/hcd-xhci.c
@@ -1218,26 +1218,11 @@ static XHCIEPContext *xhci_alloc_epctx(XHCIState *xhci,
return epctx;
}
-static TRBCCode xhci_enable_ep(XHCIState *xhci, unsigned int slotid,
- unsigned int epid, dma_addr_t pctx,
- uint32_t *ctx)
+static void xhci_init_epctx(XHCIEPContext *epctx,
+dma_addr_t pctx, uint32_t *ctx)
{
-XHCISlot *slot;
-XHCIEPContext *epctx;
dma_addr_t dequeue;
-trace_usb_xhci_ep_enable(slotid, epid);
-assert(slotid = 1 slotid = xhci-numslots);
-assert(epid = 1 epid = 31);
-
-slot = xhci-slots[slotid-1];
-if (slot-eps[epid-1]) {
-xhci_disable_ep(xhci, slotid, epid);
-}
-
-epctx = xhci_alloc_epctx(xhci, slotid, epid);
-slot-eps[epid-1] = epctx;
-
dequeue = xhci_addr64(ctx[2] ~0xf, ctx[3]);
epctx-type = (ctx[1] EP_TYPE_SHIFT) EP_TYPE_MASK;
@@ -1252,11 +1237,33 @@ static TRBCCode xhci_enable_ep(XHCIState *xhci,
unsigned int slotid,
if (epctx-max_pstreams) {
xhci_alloc_streams(epctx, dequeue);
} else {
-xhci_ring_init(xhci, epctx-ring, dequeue);
+xhci_ring_init(epctx-xhci, epctx-ring, dequeue);
epctx-ring.ccs = ctx[2] 1;
}
epctx-interval = 1 (ctx[0] 16) 0xff;
+}
+
+static TRBCCode xhci_enable_ep(XHCIState *xhci, unsigned int slotid,
+ unsigned int epid, dma_addr_t pctx,
+ uint32_t *ctx)
+{
+XHCISlot *slot;
+XHCIEPContext *epctx;
+
+trace_usb_xhci_ep_enable(slotid, epid);
+assert(slotid = 1 slotid = xhci-numslots);
+assert(epid = 1 epid = 31);
+
+slot = xhci-slots[slotid-1];
+if (slot-eps[epid-1]) {
+xhci_disable_ep(xhci, slotid, epid);
+}
+
+epctx = xhci_alloc_epctx(xhci, slotid, epid);
+slot-eps[epid-1] = epctx;
+xhci_init_epctx(epctx, pctx, ctx);
+
epctx-mfindex_last = 0;
epctx-state = EP_RUNNING;
--
1.7.9.7
[Qemu-devel] [PATCH 7/7] xhci: add live migration support
With all preparing pieces in place we can finally drop in
the vmstate structs and the postload function.
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
hw/usb/hcd-xhci.c | 164 -
1 file changed, 163 insertions(+), 1 deletion(-)
diff --git a/hw/usb/hcd-xhci.c b/hw/usb/hcd-xhci.c
index 9b90067..91633ed 100644
--- a/hw/usb/hcd-xhci.c
+++ b/hw/usb/hcd-xhci.c
@@ -3386,9 +3386,171 @@ static int usb_xhci_initfn(struct PCIDevice *dev)
return 0;
}
+static int usb_xhci_post_load(void *opaque, int version_id)
+{
+XHCIState *xhci = opaque;
+XHCISlot *slot;
+XHCIEPContext *epctx;
+dma_addr_t dcbaap, pctx;
+uint32_t slot_ctx[4];
+uint32_t ep_ctx[5];
+int slotid, epid, state, intr;
+
+dcbaap = xhci_addr64(xhci-dcbaap_low, xhci-dcbaap_high);
+
+for (slotid = 1; slotid = xhci-numslots; slotid++) {
+slot = xhci-slots[slotid-1];
+if (!slot-addressed) {
+continue;
+}
+slot-ctx =
+xhci_mask64(ldq_le_pci_dma(xhci-pci_dev, dcbaap + 8*slotid));
+xhci_dma_read_u32s(xhci, slot-ctx, slot_ctx, sizeof(slot_ctx));
+slot-uport = xhci_lookup_uport(xhci, slot_ctx);
+assert(slot-uport slot-uport-dev);
+
+for (epid = 1; epid = 32; epid++) {
+pctx = slot-ctx + 32 * epid;
+xhci_dma_read_u32s(xhci, pctx, ep_ctx, sizeof(ep_ctx));
+state = ep_ctx[0] EP_STATE_MASK;
+if (state == EP_DISABLED) {
+continue;
+}
+epctx = xhci_alloc_epctx(xhci, slotid, epid);
+slot-eps[epid-1] = epctx;
+xhci_init_epctx(epctx, pctx, ep_ctx);
+epctx-state = state;
+if (state == EP_RUNNING) {
+/* kick endpoint after vmload is finished */
+qemu_mod_timer(epctx-kick_timer, qemu_get_clock_ns(vm_clock));
+}
+}
+}
+
+for (intr = 0; intr xhci-numintrs; intr++) {
+if (xhci-intr[intr].msix_used) {
+msix_vector_use(xhci-pci_dev, intr);
+} else {
+msix_vector_unuse(xhci-pci_dev, intr);
+}
+}
+
+return 0;
+}
+
+static const VMStateDescription vmstate_xhci_ring = {
+.name = xhci-ring,
+.version_id = 1,
+.fields = (VMStateField[]) {
+VMSTATE_UINT64(dequeue, XHCIRing),
+VMSTATE_BOOL(ccs, XHCIRing),
+VMSTATE_END_OF_LIST()
+}
+};
+
+static const VMStateDescription vmstate_xhci_port = {
+.name = xhci-port,
+.version_id = 1,
+.fields = (VMStateField[]) {
+VMSTATE_UINT32(portsc, XHCIPort),
+VMSTATE_END_OF_LIST()
+}
+};
+
+static const VMStateDescription vmstate_xhci_slot = {
+.name = xhci-slot,
+.version_id = 1,
+.fields = (VMStateField[]) {
+VMSTATE_BOOL(enabled, XHCISlot),
+VMSTATE_BOOL(addressed, XHCISlot),
+VMSTATE_END_OF_LIST()
+}
+};
+
+static const VMStateDescription vmstate_xhci_event = {
+.name = xhci-event,
+.version_id = 1,
+.fields = (VMStateField[]) {
+VMSTATE_UINT32(type, XHCIEvent),
+VMSTATE_UINT32(ccode, XHCIEvent),
+VMSTATE_UINT64(ptr,XHCIEvent),
+VMSTATE_UINT32(length, XHCIEvent),
+VMSTATE_UINT32(flags, XHCIEvent),
+VMSTATE_UINT8(slotid, XHCIEvent),
+VMSTATE_UINT8(epid,XHCIEvent),
+}
+};
+
+static bool xhci_er_full(void *opaque, int version_id)
+{
+struct XHCIInterrupter *intr = opaque;
+return intr-er_full;
+}
+
+static const VMStateDescription vmstate_xhci_intr = {
+.name = xhci-intr,
+.version_id = 1,
+.fields = (VMStateField[]) {
+/* registers */
+VMSTATE_UINT32(iman, XHCIInterrupter),
+VMSTATE_UINT32(imod, XHCIInterrupter),
+VMSTATE_UINT32(erstsz,XHCIInterrupter),
+VMSTATE_UINT32(erstba_low,XHCIInterrupter),
+VMSTATE_UINT32(erstba_high, XHCIInterrupter),
+VMSTATE_UINT32(erdp_low, XHCIInterrupter),
+VMSTATE_UINT32(erdp_high, XHCIInterrupter),
+
+/* state */
+VMSTATE_BOOL(msix_used, XHCIInterrupter),
+VMSTATE_BOOL(er_pcs, XHCIInterrupter),
+VMSTATE_UINT64(er_start, XHCIInterrupter),
+VMSTATE_UINT32(er_size, XHCIInterrupter),
+VMSTATE_UINT32(er_ep_idx, XHCIInterrupter),
+
+/* event queue (used if ring is full) */
+VMSTATE_BOOL(er_full, XHCIInterrupter),
+VMSTATE_UINT32_TEST(ev_buffer_put, XHCIInterrupter, xhci_er_full),
+VMSTATE_UINT32_TEST(ev_buffer_get, XHCIInterrupter, xhci_er_full),
+VMSTATE_STRUCT_ARRAY_TEST(ev_buffer, XHCIInterrupter, EV_QUEUE,
+ xhci_er_full, 1,
+ vmstate_xhci_event, XHCIEvent),
+
+VMSTATE_END_OF_LIST()
+}
+};
+
static const VMStateDescription vmstate_xhci = {
.name = xhci,
-
Re: [Qemu-devel] [PATCH 00/15] Memory/IOMMU patches part 4: region ownership
Il 03/06/2013 11:58, Peter Maydell ha scritto: On 3 June 2013 10:40, Paolo Bonzini pbonz...@redhat.com wrote: Il 03/06/2013 11:22, Peter Maydell ha scritto: arm11mpcore.c does this: sysbus_init_mmio(dev, sysbus_mmio_get_region(s-priv, 0)); which I suspect will assert with your patches. Thanks for the pointer. All other occurrences of sys_bus_mmio_get_region are either in non-qdevified OMAP code, or they do what I said in my patch. I'll fix a11mpcore to use an alias. Why? There is no need to -- this should be a perfectly reasonable use of MemoryRegion*s. If your reference counting code can't deal with it you need to fix the reference counting code. It can: 1) I could set the owner to NULL before calling the sysbus_init_mmio; 2) I could add a variant of sysbus_init_mmio that doesn't set the owner; 3) I could skip setting the owner for sysbus altogether, since it is only strictly required for unpluggable devices. What I cannot do is having two owners, where each ref/unref pair will ref/unref both objects. I think you agree that it is overkill. However, I think there is worth in preserving the chain through either containment or aliasing. From the nesting point of view, realview_mpcore is exposing the region. From the implementor point of view, arm_gic is implementing the region (and arm_gic is the one that would be ref/unref'd at execution time). In either case, arm11mpcore_priv is not what you want to see. Its presence is just an implementation detail of realview_mpcore. Paolo
Re: [Qemu-devel] [PATCH 06/22] memory: dispatch unassigned accesses based on .valid.accepts
Am 03.06.2013 09:31, schrieb Paolo Bonzini: Il 01/06/2013 17:28, Blue Swirl ha scritto: This means that memory.c is getting knowledge about CPU types and it becomes more specific to current target. I think memory.c should be generic and target agnostic (maybe one day compiled just once) with exec.c implementing the target specific functionality. You're right, but the solution is simply to make cpu_unassigned_access a CPU method. I already have a patch queued to that effect on qom-cpu-10 branch that I needed to rebase after your merge. :) Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [PATCH 00/15] Memory/IOMMU patches part 4: region ownership
On 3 June 2013 11:12, Paolo Bonzini pbonz...@redhat.com wrote: 1) I could set the owner to NULL before calling the sysbus_init_mmio; 2) I could add a variant of sysbus_init_mmio that doesn't set the owner; 3) I could skip setting the owner for sysbus altogether, since it is only strictly required for unpluggable devices. 4) you could set the owner at the right place, ie when the memory region is created. However, I think there is worth in preserving the chain through either containment or aliasing. From the nesting point of view, realview_mpcore is exposing the region. From the implementor point of view, arm_gic is implementing the region (and arm_gic is the one that would be ref/unref'd at execution time). In either case, arm11mpcore_priv is not what you want to see. Its presence is just an implementation detail of realview_mpcore. I agree that the owner of the MR in this case should be arm_gic. For aliasing, surely you need to actually reference both devices? If the device that owns the container goes away then your MR* is toast anyway, and if the device doing the actual implementation goes away your MR* is also now invalid. So they have to both hang around long enough for you to finish whatever you were doing. thanks -- PMM
Re: [Qemu-devel] [PATCH] net: tap: fix NULL dereference when passing both fd and vhostfds to tap
comments below
On 06/03/13 11:04, Jason Wang wrote:
This is because vhostfdname were passed as NULL to net_init_tap_one() when
vhostfd were not specified, but net_init_tap_one() will still pass it to
monitor_handle_fd_param() when tap-has_vhostfds is true. Since file
descriptor
(fd, vhostfd) and file descriptor set (fds, vhostfds) were not compatible, so
this patch forbids passing them to tap in the same time.
This solve the segfault when passing the command line like:
./qemu-system-x86_64 -netdev tap,fd=2,vhost=on,vhostfds=baz,id=xyz
Cc: Paolo Bonzini pbonz...@redhat.com
Cc: Stefan Hajnoczi shajn...@redhat.com
Cc: Laszlo Ersek ler...@redhat.com
Cc: qemu-sta...@nongnu.org
Signed-off-by: Jason Wang jasow...@redhat.com
---
net/tap.c | 10 ++
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/net/tap.c b/net/tap.c
index e0b7a2a..477505f 100644
--- a/net/tap.c
+++ b/net/tap.c
@@ -698,9 +698,10 @@ int net_init_tap(const NetClientOptions *opts, const
char *name,
if (tap-has_fd) {
if (tap-has_ifname || tap-has_script || tap-has_downscript ||
tap-has_vnet_hdr || tap-has_helper || tap-has_queues ||
-tap-has_fds) {
+tap-has_fds || tap-has_vhostfds) {
error_report(ifname=, script=, downscript=, vnet_hdr=,
- helper=, queues=, and fds= are invalid with fd=);
+ helper=, queues=, fds=, and vhostfds=
+ are invalid with fd=);
return -1;
}
This seems OK, since
has_fd precludeshas_fds
- optional: has_vhostfd - optional: has_vhostfds
@@ -725,9 +726,10 @@ int net_init_tap(const NetClientOptions *opts, const
char *name,
if (tap-has_ifname || tap-has_script || tap-has_downscript ||
tap-has_vnet_hdr || tap-has_helper || tap-has_queues ||
-tap-has_fd) {
+tap-has_fd || tap-has_vhostfd) {
error_report(ifname=, script=, downscript=, vnet_hdr=,
- helper=, queues=, and fd= are invalid with fds=);
+ helper=, queues=, fd=, and vhostfd=
+ are invalid with fds=);
return -1;
}
I think this us OK too (implementing the above exclusion from the other
side), but in the second hunk tap-has_fd can never be true actually.
I think relying on that in both the condition and the error message here
would simplify them.
Finally, I think the has_helper, and the outermost else branch
should both be updated as well, for consistency with hunk #1 here. These
branches use vhostfdname too. In these branches,
- both has_fd and has_fds are false (should simplify check errmsg),
- has_vhostfds should be rejected.
Thanks
Laszlo
Re: [Qemu-devel] [PATCH 14/15] memory: return MemoryRegion from qemu_ram_addr_from_host
Il 03/06/2013 08:40, Paolo Bonzini ha scritto: Il 02/06/2013 18:04, Peter Maydell ha scritto: On 2 June 2013 16:43, Paolo Bonzini pbonz...@redhat.com wrote: -int qemu_ram_addr_from_host(void *ptr, ram_addr_t *ram_addr); +MemoryRegion *qemu_ram_addr_from_host(void *ptr, ram_addr_t *ram_addr); ram_addr_t qemu_ram_addr_from_host_nofail(void *ptr); This is weird, because now the _nofail and the standard versions of this function return different things. Ah, actually that's not a change. The function used to return 0/-1 and place the address in a by-reference argument. It's a somewhat weird decision made when the normal and _nofail version were split (commit e890261, Export qemu_ram_addr_from_host, 2010-10-11). Returning -1 to indicate failure would have been ok, since it's not a valid ram_addr_t. Why wouldn't a caller of the _nofail version potentially need the MemoryRegion* too? Because there are just a handful of calls, and all of them are in cputlb.c which is not very much MemoryRegion-aware. I'll just move it there and make it static. The right fix here would be to make all the MCE handling code not KVM-specific. Then it can be in exec.c and ram_addr_t can be private (eliminating a good deal of confusion between it and hwaddr). Paolo
Re: [Qemu-devel] [PATCH 00/15] Memory/IOMMU patches part 4: region ownership
Il 03/06/2013 12:25, Peter Maydell ha scritto: On 3 June 2013 11:12, Paolo Bonzini pbonz...@redhat.com wrote: 1) I could set the owner to NULL before calling the sysbus_init_mmio; 2) I could add a variant of sysbus_init_mmio that doesn't set the owner; 3) I could skip setting the owner for sysbus altogether, since it is only strictly required for unpluggable devices. 4) you could set the owner at the right place, ie when the memory region is created. However, I think there is worth in preserving the chain through either containment or aliasing. From the nesting point of view, realview_mpcore is exposing the region. From the implementor point of view, arm_gic is implementing the region (and arm_gic is the one that would be ref/unref'd at execution time). In either case, arm11mpcore_priv is not what you want to see. Its presence is just an implementation detail of realview_mpcore. I agree that the owner of the MR in this case should be arm_gic. The owner of the I/O region is arm_gic. It is set when arm_gic does sysbus_init_mmio. But container regions have an owner too. Here the owner is set initially to arm11mpcore_priv, and then it bombs when realview_mpcore tries to change it to itself. Make each level wrap the region with a container makes sense to me. But actually sysbus_pass_mmio would match nicely sysbus_pass_irq as an API, so (2) above would be a good choice too. What I'm definitely not going to do, is go through 800 calls and add owners to all of them. For aliasing, surely you need to actually reference both devices? If the device that owns the container goes away then your MR* is toast anyway, and if the device doing the actual implementation goes away your MR* is also now invalid. So they have to both hang around long enough for you to finish whatever you were doing. Container and alias regions are virtual, they are eliminated while creating the flat memory map; I/O goes straight to the contained/aliased region. Hence, containers and aliases in principle need no owner; it is still nice to have one, for symmetry and ease of debugging. A reference to the aliased region is added when: (1) the region is added to the flat memory map; (2) the alias is created. Both are done in patch 3. Paolo
Re: [Qemu-devel] [Qemu-trivial] [PATCH] fpu: Simplify floatx80ToCommonNaN function.
Hi! On Fri, 31 May 2013 15:45:55 +0100, Peter Maydell peter.mayd...@linaro.org wrote: On 31 May 2013 14:01, Thomas Schwinge tho...@codesourcery.com wrote: On Fri, 31 May 2013 13:34:12 +0100, Peter Maydell peter.mayd...@linaro.org wrote: That said, I think any new patches to fpu/ need to come with an explicit statement that they can be licensed under the softfloat-2a license or GPLv2 or BSD (etc etc) so they aren't an obstacle to the softfloat-2a-to-2b conversion that is in the works. [cc'd Anthony so he can correct me if I'm wrong.] I hereby place this one contribution (which I think wouldn't constitute a copyrightable change anyway) into the Public Domain, allowing any kind of usage. I think we'd generally suggest creative commons CC0 as being in less of a legally grey area internationally than public domain, if you're happy with that. Using Creative Commons' CC0 is likewise fine. Either way, Reviewed-by: Peter Maydell peter.mayd...@linaro.org Thanks. Oh, and as I saw you wondering in the QEMU IRC channel, why I had bothered with this change anyway, the reason is that I have some further SoftFloat changes forthcoming, and in the course of these stumbled over that oddity in the floatx80ToCommonNaN function, and already submitted that one separately asnot related to my other changes. Grüße, Thomas pgp_YcI3aZ4HT.pgp Description: PGP signature
Re: [Qemu-devel] [PATCH] linux-user: Allow getdents to be provided by getdents64
Tested on m68k on x86_64 as described in the patch comment, in a a debian-etch
linux container.
Works fine, except the drec_len differs between getdents() and getdents64().
See comment below.
Le 2 juin 2013 à 19:10, Peter Maydell peter.mayd...@linaro.org a écrit :
Newer architectures may only implement the getdents64 syscall, not
getdents. Provide an implementation of getdents in terms of getdents64
so that we can run getdents-using targets on a getdents64-only host.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
Guess which exciting new architecture doesn't have getdents :-)
Tested on i386 by temporarily nobbling the #ifdefs so we use the
via-getdents64 path rather than via-getdents, and with the test program
from the getdents(2) manpage as the guest binary.
linux-user/syscall.c | 60 +-
1 file changed, 59 insertions(+), 1 deletion(-)
diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index 053fa14..15c771a 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -208,8 +208,11 @@ static int gettid(void) {
return -ENOSYS;
}
#endif
+#ifdef __NR_getdents
_syscall3(int, sys_getdents, uint, fd, struct linux_dirent *, dirp, uint,
count);
-#if defined(TARGET_NR_getdents64) defined(__NR_getdents64)
+#endif
+#if !defined(__NR_getdents) || \
+ (defined(TARGET_NR_getdents64) defined(__NR_getdents64))
_syscall3(int, sys_getdents64, uint, fd, struct linux_dirent64 *, dirp, uint,
count);
#endif
#if defined(TARGET_NR__llseek) defined(__NR_llseek)
@@ -6963,6 +6966,7 @@ abi_long do_syscall(void *cpu_env, int num, abi_long
arg1,
break;
#endif
case TARGET_NR_getdents:
+#ifdef __NR_getdents
#if TARGET_ABI_BITS == 32 HOST_LONG_BITS == 64
{
struct target_dirent *target_dirp;
@@ -7035,6 +7039,60 @@ abi_long do_syscall(void *cpu_env, int num, abi_long
arg1,
unlock_user(dirp, arg2, ret);
}
#endif
+#else
+ /* Implement getdents in terms of getdents64 */
+ {
+ struct linux_dirent64 *dirp;
+ abi_long count = arg3;
+
+ dirp = lock_user(VERIFY_WRITE, arg2, count, 0);
+ if (!dirp) {
+ goto efault;
+ }
+ ret = get_errno(sys_getdents64(arg1, dirp, count));
+ if (!is_error(ret)) {
+ /* Convert the dirent64 structs to target dirent. We do this
+ * in-place, since we can guarantee that a target_dirent is no
+ * larger than a dirent64; however this means we have to be
+ * careful to read everything before writing in the new format.
+ */
+ struct linux_dirent64 *de;
+ struct target_dirent *tde;
+ int len = ret;
+ int tlen = 0;
+
+ de = dirp;
+ tde = (struct target_dirent *)dirp;
+ while (len 0) {
+ int namelen, treclen;
+ int reclen = de-d_reclen;
+ uint64_t ino = de-d_ino;
+ int64_t off = de-d_off;
+ uint8_t type = de-d_type;
+
+ namelen = strlen(de-d_name);
+ treclen = offsetof(struct target_dirent, d_name) + namelen + 2;
+ treclen = QEMU_ALIGN_UP(treclen, sizeof(abi_long));
You should use ABI_LONG_ALIGNMENT instead of sizeof(abi_long), as some targets
(at least m68k) don't align on long size.
+
+ tde-d_ino = tswapal(ino);
+ tde-d_off = tswapal(off);
+ tde-d_reclen = tswap16(treclen);
+ memmove(tde-d_name, de-d_name, namelen + 1);
+ /* The target_dirent type is in what was formerly a padding
+ * byte at the end of the structure:
+ */
+ *(((char *)tde) + treclen - 1) = type;
+
+ de = (struct linux_dirent64 *)((char *)de + reclen);
+ tde = (struct target_dirent *)((char *)tde + treclen);
+ len -= reclen;
+ tlen += treclen;
+ }
+ ret = tlen;
+ }
+ unlock_user(dirp, arg2, ret);
+ }
+#endif
break;
#if defined(TARGET_NR_getdents64) defined(__NR_getdents64)
case TARGET_NR_getdents64:
Re: [Qemu-devel] [PATCH 4/4] tcg/aarch64: implement tlb lookup fast path
On 5/31/2013 10:25 PM, Richard Henderson wrote:
On 05/31/2013 11:07 AM, Jani Kokkonen wrote:
+/* Load and compare a TLB entry, leaving the flags set. Leaves X2 pointing
+ to the tlb entry. Clobbers X0,X1,X2,X3 and TMP. */
+
+static void tcg_out_tlb_read(TCGContext *s, TCGReg addr_reg,
+ int s_bits, uint8_t **label_ptr, int
tlb_offset)
+{
You copied the comment from ARM, and it isn't correct. You generate branches.
I will fix the comment.
+TCGReg base = TCG_AREG0;
+
+tcg_out_shr(s, 1, TCG_REG_TMP, addr_reg, TARGET_PAGE_BITS);
+tcg_out_movi(s, TCG_TYPE_I64, TCG_REG_X1, tlb_offset);
+tcg_out_arith(s, ARITH_ADD, 1, TCG_REG_X2, base, TCG_REG_X1, 0);
+tcg_out_andi(s, 1, TCG_REG_X0, TCG_REG_TMP, CPU_TLB_BITS, 0);
+tcg_out_arith(s, ARITH_ADD, 1, TCG_REG_X2, TCG_REG_X2,
+ TCG_REG_X0, -CPU_TLB_ENTRY_BITS);
+#if TARGET_LONG_BITS == 64
+tcg_out_ldst(s, LDST_64, LDST_LD, TCG_REG_X3, TCG_REG_X2, 0);
+#else
+tcg_out_ldst(s, LDST_32, LDST_LD, TCG_REG_X3, TCG_REG_X2, 0);
+#endif
+/* check alignment */
+if (s_bits) {
+tcg_out_tst(s, 1, addr_reg, s_bits, 0);
+label_ptr[0] = s-code_ptr;
+tcg_out_goto_cond_noaddr(s, TCG_COND_NE);
+}
+tcg_out_cmp(s, 1, TCG_REG_X3, TCG_REG_TMP, -TARGET_PAGE_BITS);
+label_ptr[1] = s-code_ptr;
+tcg_out_goto_cond_noaddr(s, TCG_COND_NE);
I'm positive that the branch predictor would be happier with a single branch
rather than the two you generate here. It ought to be possible to use a
different set of insns to do this in one go.
How about something like
@ extract the tlb index from the address
ubfmw0, addr_reg, TARGET_PAGE_BITS, CPU_TLB_BITS
@ add any high bits from the tlb offset
@ noting that env will be much smaller than 24 bits.
add x1, env, tlb_offset 0xfff000
@ zap the tlb index from the address for compare
@ this is all high bits plus 0-3 low bits set, so this
@ should match a logical immediate.
and w/x2, addr_reg, TARGET_PAGE_MASK | ((1 s_bits) - 1)
@ merge the tlb index into the env+tlb_offset
add x1, x1, x0, lsl #3
@ load the tlb comparator. the 12-bit scaled offset
@ form will fit the bits remaining from above, given that
@ we're loading an aligned object, and so the low 2/3 bits
@ will be clear.
ldr w/x0, [x1, tlb_offset 0xfff]
@ load the tlb addend. do this early to avoid stalling.
@ the addend_offset differs from tlb_offset by 1-3 words.
@ given that we've got overlap between the scaled 12-bit
@ value and the 12-bit shifted value above, this also ought
@ to always be representable.
ldr x3, [x1, (tlb_offset 0xfff) + (addend_offset - tlb_offset)]
@ perform the comparison
cmp w/x0, w/x2
@ generate the complete host address in parallel with the cmp.
add x3, x3, addr_reg@ 64-bit guest
add x3, x3, addr_reg, uxtw @ 32-bit guest
bne miss_label
Note that the w/x above indicates the ext setting that ought to be used,
depending on the address size of the guest.
This is at least 2 insns shorter than your sequence.
Ok, thanks. ubfm instruction will be added and I will modify implementation
based on your comments.
Have you looked at doing the out-of-line tlb miss sequence right from the
very beginning? It's not that much more difficult to accomplish than the
inline tlb miss.
I have to look into this one.
See CONFIG_QEMU_LDST_OPTIMIZATION, and the implementation in tcg/arm.
You won't need two nops after the call; aarch64 can do all the required
extensions and data movement operations in a single insn.
I will take this also into account.
r~
-Jani
Re: [Qemu-devel] [PATCH] linux-user: Allow getdents to be provided by getdents64
On 3 June 2013 12:11, Laurent Vivier laur...@vivier.eu wrote: Tested on m68k on x86_64 as described in the patch comment, in a a debian-etch linux container. Works fine, except the drec_len differs between getdents() and getdents64(). Le 2 juin 2013 à 19:10, Peter Maydell peter.mayd...@linaro.org a écrit : + namelen = strlen(de-d_name); + treclen = offsetof(struct target_dirent, d_name) + namelen + 2; + treclen = QEMU_ALIGN_UP(treclen, sizeof(abi_long)); You should use ABI_LONG_ALIGNMENT instead of sizeof(abi_long), as some targets (at least m68k) don't align on long size. I'm following what the kernel source does: http://lxr.linux.no/#linux+v3.5/fs/readdir.c#L154 which if I'm not misreading it also aligns based on the size of the type, not its alignment requirements. (the C spec guarantees that the former is never less strict than the latter, so it's just unnecessary padding, not misaligning the next record). Looking at our code for 32-bit-guest-on-64-bit-host getdents-in-terms-of-getdents, I think it is actually the existing code which is not getting the record length correct, which is why you're seeing a difference between that and the code added in this patch. If you have access to the real hardware (or even just a system emulated QEMU I guess) I would expect to see that the record lengths it uses match this patch's results. getdents64() calculates the record length by aligning to a multiple of sizeof(u64), and getdents() does it by aligning to a multiple of sizeof(long). So if you work out the record length for target_dirent by back-calculating it from that of linux_dirent when the sizeof(long) is different between host and target, you'll end up with possibly a word of extra padding you didn't need. This won't hurt any guest code, since it shouldn't care, but it is why I chose in my code to determine the length of the filename via strlen(), so I could get the record length exactly correct. (The returned value, ie total number of bytes read into the buffer, will unavoidably differ, because the conversion process packs the results down into a smaller space. This shouldn't break guests either, fortunately.) thanks -- PMM
Re: [Qemu-devel] [PATCH] linux-user: Allow getdents to be provided by getdents64
I agree with all your comments. Tested-by: Laurent Vivier laur...@vivier.eu Reviewed-by: Laurent Vivier laur...@vivier.eu Le 3 juin 2013 à 13:28, Peter Maydell peter.mayd...@linaro.org a écrit : On 3 June 2013 12:11, Laurent Vivier laur...@vivier.eu wrote: Tested on m68k on x86_64 as described in the patch comment, in a a debian-etch linux container. Works fine, except the drec_len differs between getdents() and getdents64(). Le 2 juin 2013 à 19:10, Peter Maydell peter.mayd...@linaro.org a écrit : + namelen = strlen(de-d_name); + treclen = offsetof(struct target_dirent, d_name) + namelen + 2; + treclen = QEMU_ALIGN_UP(treclen, sizeof(abi_long)); You should use ABI_LONG_ALIGNMENT instead of sizeof(abi_long), as some targets (at least m68k) don't align on long size. I'm following what the kernel source does: http://lxr.linux.no/#linux+v3.5/fs/readdir.c#L154 which if I'm not misreading it also aligns based on the size of the type, not its alignment requirements. (the C spec guarantees that the former is never less strict than the latter, so it's just unnecessary padding, not misaligning the next record). Looking at our code for 32-bit-guest-on-64-bit-host getdents-in-terms-of-getdents, I think it is actually the existing code which is not getting the record length correct, which is why you're seeing a difference between that and the code added in this patch. If you have access to the real hardware (or even just a system emulated QEMU I guess) I would expect to see that the record lengths it uses match this patch's results. getdents64() calculates the record length by aligning to a multiple of sizeof(u64), and getdents() does it by aligning to a multiple of sizeof(long). So if you work out the record length for target_dirent by back-calculating it from that of linux_dirent when the sizeof(long) is different between host and target, you'll end up with possibly a word of extra padding you didn't need. This won't hurt any guest code, since it shouldn't care, but it is why I chose in my code to determine the length of the filename via strlen(), so I could get the record length exactly correct. (The returned value, ie total number of bytes read into the buffer, will unavoidably differ, because the conversion process packs the results down into a smaller space. This shouldn't break guests either, fortunately.) thanks -- PMM
Re: [Qemu-devel] [PATCH v2] virtio-rng: Fix crash with non-default backend
On Fri, May 31, 2013 at 02:12:48PM -0400, Cole Robinson wrote: 'default_backend' isn't always set, but 'rng' is, so use that. $ ./x86_64-softmmu/qemu-system-x86_64 -object rng-random,id=rng0,filename=/dev/random -device virtio-rng-pci,rng=rng0 Segmentation fault (core dumped) Regressed with virtio refactoring in 59ccd20a9ac719cff82180429458728f03ec612f CC: qemu-sta...@nongnu.org Signed-off-by: Cole Robinson crobi...@redhat.com Acked-by: Michael S. Tsirkin m...@redhat.com An unrelated comment: we have many instances if the literal rng string in code. They all must match otherwise things crash. So why not add a macro #define VIRTIO_RNG_BACKEND_LINK rng this way compiler checks that we don't make any typos. --- Notes: v2: Fix other instances in s390x code, pointed out by Frederic hw/s390x/s390-virtio-bus.c | 2 +- hw/s390x/virtio-ccw.c | 2 +- hw/virtio/virtio-pci.c | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/hw/s390x/s390-virtio-bus.c b/hw/s390x/s390-virtio-bus.c index a1cdfb0..207eb82 100644 --- a/hw/s390x/s390-virtio-bus.c +++ b/hw/s390x/s390-virtio-bus.c @@ -300,7 +300,7 @@ static int s390_virtio_rng_init(VirtIOS390Device *s390_dev) } object_property_set_link(OBJECT(dev), - OBJECT(dev-vdev.conf.default_backend), rng, + OBJECT(dev-vdev.conf.rng), rng, NULL); return s390_virtio_device_init(s390_dev, VIRTIO_DEVICE(vdev)); diff --git a/hw/s390x/virtio-ccw.c b/hw/s390x/virtio-ccw.c index 5f5e267..7dcd98d 100644 --- a/hw/s390x/virtio-ccw.c +++ b/hw/s390x/virtio-ccw.c @@ -744,7 +744,7 @@ static int virtio_ccw_rng_init(VirtioCcwDevice *ccw_dev) } object_property_set_link(OBJECT(dev), - OBJECT(dev-vdev.conf.default_backend), rng, + OBJECT(dev-vdev.conf.rng), rng, NULL); return virtio_ccw_device_init(ccw_dev, VIRTIO_DEVICE(vdev)); diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c index 444b71a..b070b64 100644 --- a/hw/virtio/virtio-pci.c +++ b/hw/virtio/virtio-pci.c @@ -1455,7 +1455,7 @@ static int virtio_rng_pci_init(VirtIOPCIProxy *vpci_dev) } object_property_set_link(OBJECT(vrng), - OBJECT(vrng-vdev.conf.default_backend), rng, + OBJECT(vrng-vdev.conf.rng), rng, NULL); return 0; -- 1.8.2.1
Re: [Qemu-devel] [PATCH] correct RTC_CHANGE_EVENT description
On Fri, 31 May 2013 15:24:03 -0300 Marcelo Tosatti mtosa...@redhat.com wrote: Fix RTC_CHANGE event description to match implementation. Signed-off-by: Marcelo Tosatti mtosa...@redhat.com Applied to the qmp branch, thanks. diff --git a/QMP/qmp-events.txt b/QMP/qmp-events.txt index 92fe5fb..00b4087 100644 --- a/QMP/qmp-events.txt +++ b/QMP/qmp-events.txt @@ -203,7 +203,8 @@ Emitted when the guest changes the RTC time. Data: -- offset: delta against the host UTC in seconds (json-number) +- offset: Offset between old RTC clock value and new one +in seconds (json-number) Example:
Re: [Qemu-devel] latest qemu with gdb remote not working
On 06/01/2013 02:09 PM, Peter Cheung wrote: i start my qemu by this ~/qemu/bin/qemu-system-x86_64 -hda hd10meg.img -gdb tcp::1234 -k en-us -S -m 256m it was working before, but not for the latest code. When i use GDB to connect to it, it show up a warning message and i was unable to start qemu. Please take a look the attachment. thanks Posting 1 megabyte screenshots is considered poor netiquette - your 1M incoming is multiplied to several hundred megabytes outgoing based on the large number of subscribers to this list, which puts a burden on the mail server. Then, not everyone has cheap fast internet connections, and downloading a megabyte message is not trivial. And several list readers prefer to see only plain text emails by default, where your screenshot requires lots of extra work to even see what you are talking about. Please, don't send images when a copy-and-paste of the terminal contents will do; or at a minimum consider posting the screenshot to a website then posting only the URL to that website in your mail message. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [RFC PATCH v3 00/11] qemu-ga: fsfreeze on Windows using VSS
On Mon, 3 Jun 2013 09:12:55 + Libaiqing libaiq...@huawei.com wrote: Hi, Thanks for your advice,it works well when using prefix=x86_64-w64-mingw32-. The dlls may download from here: http://qemu.weilnetz.de/w64/dll/. One more question: Qemu-ga.exe can't run successfully under normal account which belongs to Administration group. Qemu-ga service can start successfully under this account after Administrator installed. The output is: 1370307591.689600:critical:error opening path 1370307591.705200:critical:error opening channel 1370307591.720800:critical:failed to create guest agent channel 1370307591.736400:critical:failed to initialize guest agent channel Could you give me some advise to debug this problem ? I can provide more information if need. Maybe it's because it needs admin permissions to open the virtio device.
Re: [Qemu-devel] [PATCH 2/3] ivshmem: add missing error exit(2)
Stefan Hajnoczi stefa...@redhat.com writes:
If the user fails to specify 'chardev' or 'shm' then we cannot continue.
Exit right away so that we don't invoke shm_open(3) with a NULL pointer.
It would be nice to replace exit(1) with error returns in the PCI device
.init() function, but leave that for another patch since exit(1) is
currently used elsewhere.
Spotted by Coverity.
Cc: Cam Macdonell c...@cs.ualberta.ca
Cc: qemu-sta...@nongnu.org
Signed-off-by: Stefan Hajnoczi stefa...@redhat.com
---
hw/misc/ivshmem.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/hw/misc/ivshmem.c b/hw/misc/ivshmem.c
index a19a6d6..5658f73 100644
--- a/hw/misc/ivshmem.c
+++ b/hw/misc/ivshmem.c
@@ -735,6 +735,7 @@ static int pci_ivshmem_init(PCIDevice *dev)
if (s-shmobj == NULL) {
fprintf(stderr, Must specify 'chardev' or 'shm' to ivshmem\n);
+exit(1);
}
IVSHMEM_DPRINTF(using shm_open (shm object = %s)\n, s-shmobj);
Botching a hotplug of this device kills the VM. Nasty trap, but no
worse than before.
Re: [Qemu-devel] [PATCH v1 0/3] Memory: Trivial fixes
Il 03/06/2013 07:31, peter.crosthwa...@xilinx.com ha scritto: From: Peter Crosthwaite peter.crosthwa...@xilinx.com Some trivial fixes to memory API. Peter Crosthwaite (3): memory: Fix comment typo memory: as_update_topology_pass: Improve comments memory: render_memory_region: factor out fr constant setters memory.c | 19 --- 1 file changed, 8 insertions(+), 11 deletions(-) Thanks, applying to my iommu branch.
Re: [Qemu-devel] [PATCH v2 2/2] ivshmem: add missing error exit(2)
On 06/03/2013 02:58 AM, Stefan Hajnoczi wrote:
If the user fails to specify 'chardev' or 'shm' then we cannot continue.
Exit right away so that we don't invoke shm_open(3) with a NULL pointer.
It would be nice to replace exit(1) with error returns in the PCI device
.init() function, but leave that for another patch since exit(1) is
currently used elsewhere.
Spotted by Coverity.
Cc: Cam Macdonell c...@cs.ualberta.ca
Cc: qemu-sta...@nongnu.org
Signed-off-by: Stefan Hajnoczi stefa...@redhat.com
---
hw/misc/ivshmem.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/hw/misc/ivshmem.c b/hw/misc/ivshmem.c
index a19a6d6..5658f73 100644
--- a/hw/misc/ivshmem.c
+++ b/hw/misc/ivshmem.c
@@ -735,6 +735,7 @@ static int pci_ivshmem_init(PCIDevice *dev)
if (s-shmobj == NULL) {
fprintf(stderr, Must specify 'chardev' or 'shm' to ivshmem\n);
+exit(1);
Reviewed-by: Eric Blake ebl...@redhat.com
However, I prefer exit(EXIT_FAILURE) rather than exit(1), to make it a
bit easier to grep for known failure exits. Libvirt has a syntax
checker (taken from gnulib) that enforces such a style, if qemu would
like to adopt that style.
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH scsi-next] vhost-scsi: fix cut-and-paste typo
Paolo Bonzini pbonz...@redhat.com writes: The copied code comes from vhost_scsi_start. Spotted by Coverity. Cc: qemu-sta...@nongnu.org Signed-off-by: Paolo Bonzini pbonz...@redhat.com Same as Stefan's [PATCH 1/3] vhost-scsi: fix k-set_guest_notifiers() NULL dereference
Re: [Qemu-devel] [PATCH trivial] acpi: actually require either data= or file= for -acpitable
On 06/03/2013 03:20 AM, Michael Tokarev wrote:
Initially the code ensured that we have exactly one of
data= or file= option for -acpitable. But after some
transformations, the condition becomes
if (has_data == has_file) { error }
to mean, probably, that both should not be set at the same
time. But this condition does not cover the case when
neither is set, and we generate bogus acpi table in this
case.
Instead, check if sum of the two is exactly 1.
Signed-off-by: Michael Tokarev m...@tls.msk.ru
---
hw/acpi/core.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/acpi/core.c b/hw/acpi/core.c
index 42eeace..2815d8c 100644
--- a/hw/acpi/core.c
+++ b/hw/acpi/core.c
@@ -249,7 +249,7 @@ void acpi_table_add(const QemuOpts *opts, Error **errp)
if (err) {
goto out;
}
-if (hdrs-has_file == hdrs-has_data) {
NACK.
hdrs-has_file and hdrs-has_data are both bool. Pre-patch, the table
of possible combinations is:
false == false = error message, zero given
false == true = okay, exactly one given
true == false = okay, exactly one given
true == true = error message, two given
which is already what you want.
+if (!hdrs-has_file + !hdrs-has_data != 1) {
Meanwhile, the post-patch logic is harder to read, in my opinion.
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH trivial] acpi: actually require either data= or file= for -acpitable
03.06.2013 16:34, Eric Blake wrote:
On 06/03/2013 03:20 AM, Michael Tokarev wrote:
Initially the code ensured that we have exactly one of data= or file= option
for -acpitable. But after some transformations, the condition becomes
if (has_data == has_file) { error }
to mean, probably, that both should not be set at the same time. But this
condition does not cover the case when neither is set, and we generate bogus
acpi table in this case.
Instead, check if sum of the two is exactly 1.
Signed-off-by: Michael Tokarev m...@tls.msk.ru --- hw/acpi/core.c |2
+- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/acpi/core.c b/hw/acpi/core.c index 42eeace..2815d8c 100644
--- a/hw/acpi/core.c +++ b/hw/acpi/core.c @@ -249,7 +249,7 @@ void
acpi_table_add(const QemuOpts *opts, Error **errp) if (err) { goto out; } -
if (hdrs-has_file == hdrs-has_data) {
NACK.
hdrs-has_file and hdrs-has_data are both bool.
Yup.
Pre-patch, the table of possible combinations is:
false == false = error message, zero given false == true = okay, exactly
one given true == false = okay, exactly one given true == true = error
message, two given
which is already what you want.
Ok, you're right. Thank you for spotting this!
This function has another error -- if the file specified
(either for data= or file=) can't be read, it happily
continues instead of erroring out. _That_ is the bug
I tried to hunt but catched something else entirely ;)
Will send a real fix later today... :)
Thanks,
/mjt
[Qemu-devel] [PATCH] qemu-doc, help: update options/keys for GTK/SDL
The GTK display type has been introduced in 1.5, replacing SDL as default. Some
options only work with SDL and not GTK. This patch tries to address them.
The `-display` option is updated with the new `gtk` option.
The `-alt-grab` and `-ctrl-alt` options are not possible in GTK according to
commit 5104a1f65088285ddf870aa641b9061064e8757d, this is now mentioned
explicitly. Another related change is that only Ctrl-Alt-G can be used for
(un)grbabing.
Window scaling seems also to be a SDL-specific feature and has been marked as
such.
Signed-off-by: Peter Wu lekenst...@gmail.com
---
qemu-doc.texi | 18 --
qemu-options.hx | 28
2 files changed, 28 insertions(+), 18 deletions(-)
diff --git a/qemu-doc.texi b/qemu-doc.texi
index 8022890..76bb4cd 100644
--- a/qemu-doc.texi
+++ b/qemu-doc.texi
@@ -275,9 +275,10 @@ targets do not need a disk image.
@c man begin OPTIONS
During the graphical emulation, you can use special key combinations to change
-modes. The default key mappings are shown below, but if you use
@code{-alt-grab}
-then the modifier is Ctrl-Alt-Shift (instead of Ctrl-Alt) and if you use
-@code{-ctrl-grab} then the modifier is the right Ctrl key (instead of
Ctrl-Alt):
+modes. The default key mappings are shown below. If you are using SDL display
+mode instead of GTK, you can use @code{-alt-grab} to change the modifier to
+Ctrl-Alt-Shift (instead of Ctrl-Alt) and @code{-ctrl-grab} to change it to
right
+Ctrl key (instead of Ctrl-Alt):
@table @key
@item Ctrl-Alt-f
@@ -294,7 +295,8 @@ Shrink the screen
@item Ctrl-Alt-u
@kindex Ctrl-Alt-u
-Restore the screen's un-scaled dimensions
+Restore the screen's un-scaled dimensions (SDL windows only, GTK does not
+feature window scaling)
@item Ctrl-Alt-n
@kindex Ctrl-Alt-n
@@ -308,16 +310,20 @@ Monitor
Serial port
@end table
+@item Ctrl-Alt-G
+@kindex Ctrl-Alt-G
+Toggle mouse and keyboard grab in GTK mode.
+
@item Ctrl-Alt
@kindex Ctrl-Alt
-Toggle mouse and keyboard grab.
+Toggle mouse and keyboard grab in SDL windows.
@end table
@kindex Ctrl-Up
@kindex Ctrl-Down
@kindex Ctrl-PageUp
@kindex Ctrl-PageDown
-In the virtual consoles, you can use @key{Ctrl-Up}, @key{Ctrl-Down},
+In the virtual consoles of SDL, you can use @key{Ctrl-Up}, @key{Ctrl-Down},
@key{Ctrl-PageUp} and @key{Ctrl-PageDown} to move in the back log.
@kindex Ctrl-a h
diff --git a/qemu-options.hx b/qemu-options.hx
index bf94862..f7b0172 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -338,7 +338,7 @@ STEXI
@item -name @var{name}
@findex -name
Sets the @var{name} of the guest.
-This name will be displayed in the SDL window caption.
+This name will be displayed in the SDL and GTK window captions.
The @var{name} will also be used for the VNC server.
Also optionally set the top visible process name in Linux.
ETEXI
@@ -804,7 +804,7 @@ ETEXI
DEF(display, HAS_ARG, QEMU_OPTION_display,
-display sdl[,frame=on|off][,alt_grab=on|off][,ctrl_grab=on|off]\n
-[,window_close=on|off]|curses|none|\n
+[,window_close=on|off]|gtk|curses|none|\n
vnc=display[,optargs]\n
select display type\n, QEMU_ARCH_ALL)
STEXI
@@ -813,6 +813,8 @@ STEXI
Select type of display to use. This option is a replacement for the
old style -sdl/-curses/... options. Valid values for @var{type} are
@table @option
+@item gtk
+Display video output via GTK which includes a menu bar.
@item sdl
Display video output via SDL (usually in a separate graphics
window; see the SDL documentation for other possibilities).
@@ -839,7 +841,7 @@ DEF(nographic, 0, QEMU_OPTION_nographic,
STEXI
@item -nographic
@findex -nographic
-Normally, QEMU uses SDL to display the VGA output. With this option,
+Normally, QEMU uses GTK to display the VGA output. With this option,
you can totally disable graphical output so that QEMU is a simple
command line application. The emulated serial port is redirected on
the console. Therefore, you can still use QEMU to debug a Linux kernel
@@ -852,7 +854,7 @@ DEF(curses, 0, QEMU_OPTION_curses,
STEXI
@item -curses
@findex -curses
-Normally, QEMU uses SDL to display the VGA output. With this option,
+Normally, QEMU uses GTK to display the VGA output. With this option,
QEMU can display the VGA output when in text mode using a
curses/ncurses interface. Nothing is displayed in graphical mode.
ETEXI
@@ -869,27 +871,29 @@ workspace more convenient.
ETEXI
DEF(alt-grab, 0, QEMU_OPTION_alt_grab,
--alt-grab use Ctrl-Alt-Shift to grab mouse (instead of Ctrl-Alt)\n,
+-alt-grab use Ctrl-Alt-Shift to grab mouse in SDL (instead of
Ctrl-Alt)\n,
QEMU_ARCH_ALL)
STEXI
@item -alt-grab
@findex -alt-grab
-Use Ctrl-Alt-Shift to grab mouse (instead of Ctrl-Alt). Note that this also
-affects the special keys (for fullscreen, monitor-mode switching, etc).
+Use Ctrl-Alt-Shift to grab mouse in SDL windows (instead of Ctrl-Alt). Note
that
+this
[Qemu-devel] [Bug 1186935] [NEW] [1.5] QEMU monitor gets overlapped by GTK menu bar
Public bug reported: The QEMU minitor gets partially hidden by the menu bar which was introduced in QEMU version 1.5.0. Steps to reproduce: 1. Run `qemu-system-x86_64` 2. Press Ctrl + Alt + 2 (or use the menu bar) 3. Observe that the monitor output is partially shown, without the compat_monitor0 console and QEMU 1.5.0 monitor - type 'help' for more information lines. Attached is a screenshot of `qemu-system-x86_64` and `qemu-system-x86_64 -display sdl`. Version: 1.5.0 Distribution: Arch Linux 64-bit ** Affects: qemu Importance: Undecided Status: New ** Attachment added: screenshot of issue https://bugs.launchpad.net/bugs/1186935/+attachment/3693513/+files/screenshot1.png -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1186935 Title: [1.5] QEMU monitor gets overlapped by GTK menu bar Status in QEMU: New Bug description: The QEMU minitor gets partially hidden by the menu bar which was introduced in QEMU version 1.5.0. Steps to reproduce: 1. Run `qemu-system-x86_64` 2. Press Ctrl + Alt + 2 (or use the menu bar) 3. Observe that the monitor output is partially shown, without the compat_monitor0 console and QEMU 1.5.0 monitor - type 'help' for more information lines. Attached is a screenshot of `qemu-system-x86_64` and `qemu-system- x86_64 -display sdl`. Version: 1.5.0 Distribution: Arch Linux 64-bit To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1186935/+subscriptions
Re: [Qemu-devel] [PATCH v2 2/2] ivshmem: add missing error exit(2)
On Mon, Jun 03, 2013 at 06:26:22AM -0600, Eric Blake wrote:
On 06/03/2013 02:58 AM, Stefan Hajnoczi wrote:
If the user fails to specify 'chardev' or 'shm' then we cannot continue.
Exit right away so that we don't invoke shm_open(3) with a NULL pointer.
It would be nice to replace exit(1) with error returns in the PCI device
.init() function, but leave that for another patch since exit(1) is
currently used elsewhere.
Spotted by Coverity.
Cc: Cam Macdonell c...@cs.ualberta.ca
Cc: qemu-sta...@nongnu.org
Signed-off-by: Stefan Hajnoczi stefa...@redhat.com
---
hw/misc/ivshmem.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/hw/misc/ivshmem.c b/hw/misc/ivshmem.c
index a19a6d6..5658f73 100644
--- a/hw/misc/ivshmem.c
+++ b/hw/misc/ivshmem.c
@@ -735,6 +735,7 @@ static int pci_ivshmem_init(PCIDevice *dev)
if (s-shmobj == NULL) {
fprintf(stderr, Must specify 'chardev' or 'shm' to
ivshmem\n);
+exit(1);
Reviewed-by: Eric Blake ebl...@redhat.com
However, I prefer exit(EXIT_FAILURE) rather than exit(1), to make it a
bit easier to grep for known failure exits. Libvirt has a syntax
checker (taken from gnulib) that enforces such a style, if qemu would
like to adopt that style.
I like EXIT_FAILURE too but the rest of the file inconsistently uses
exit(1) and exit(-1). I decided exit(1) was the least evil but the
longer term fix is to return instead of exiting.
Re: [Qemu-devel] [Xen-devel] [PVSCSI]How to unplug scsi disk simulated by Qemu, just like unplug the ide disk?
On Thu, May 30, 2013 at 11:23:44AM +, Gonglei (Arei) wrote: Hi all, My environment is xen-4.1.2 + qemu-1.2.2 I made a pvscsi driver for Redhat guest, but I encountered a problem that I could see two scsi disks, one was simulated by QEMU, another was passthrough. Actually I want to unplug the scsi disk simulated. Any methods can solve the problem on the qemu upstream. Thanks! I would suggest you look at arch/x86/xen/platform-pci-unplug.c which tells QEMU to unplug the IDE driver. You could implement a similar mechanism in QEMU (and in the Linux kernel). ___ Xen-devel mailing list xen-de...@lists.xen.org http://lists.xen.org/xen-devel
Re: [Qemu-devel] [Xen-devel] [PVSCSI]How to unplug scsi disk simulated by Qemu, just like unplug the ide disk?
-Original Message- From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com] Sent: Monday, June 03, 2013 9:16 PM To: Gonglei (Arei) Cc: qemu-devel@nongnu.org; xen-de...@lists.xen.org; Luonengjun; Jinwenwu Subject: Re: [Xen-devel] [PVSCSI]How to unplug scsi disk simulated by Qemu, just like unplug the ide disk? On Thu, May 30, 2013 at 11:23:44AM +, Gonglei (Arei) wrote: Hi all, My environment is xen-4.1.2 + qemu-1.2.2 I made a pvscsi driver for Redhat guest, but I encountered a problem that I could see two scsi disks, one was simulated by QEMU, another was passthrough. Actually I want to unplug the scsi disk simulated. Any methods can solve the problem on the qemu upstream. Thanks! I would suggest you look at arch/x86/xen/platform-pci-unplug.c which tells QEMU to unplug the IDE driver. You could implement a similar mechanism in QEMU (and in the Linux kernel). Ok, thank you so much! -Gonglei
[Qemu-devel] [PATCH 0/4] aarch64 TCG tlb fast lookup prerequisites
This series is a split of: [PATCH 0/4] ARM aarch64 TCG tlb fast lookup http://lists.nongnu.org/archive/html/qemu-devel/2013-05/msg04803.html It implements the low level operations that are necessary in order to implement the tlb fast lookup, which will be a separate series. It requires the reviewed but not committed yet series [PATCH v4 0/3] ARM aarch64 TCG target at: http://lists.nongnu.org/archive/html/qemu-devel/2013-05/msg04200.html Tested running on a x86-64 physical machine running Foundation v8, running a linux 3.8.0-rc6+ minimal host system based on linaro v8 image 201301271620 for user space. Tested guests: arm v5, i386 FreeDOS, i386 linux, sparc images, all from the qemu testing page. Also tested on x86-64/linux built with buildroot. Changes from the original series: * added ADDS and ANDS to the shifted regs ops, reorder * split shifted regs ops and test/and immediate into 2 patches * for byte swapping, remove REV32, we can just use REV * fix broken comment in tcg_out_uxt Claudio Fontana (4): tcg/aarch64: improve arith shifted regs operations tcg/aarch64: implement AND/TEST immediate pattern tcg/aarch64: implement byte swap operations tcg/aarch64: implement sign/zero extend operations tcg/aarch64/tcg-target.c | 170 +-- tcg/aarch64/tcg-target.h | 30 - 2 files changed, 166 insertions(+), 34 deletions(-) -- 1.8.1
[Qemu-devel] [PATCH 1/4] tcg/aarch64: improve arith shifted regs operations
for arith operations, add SUBS, ANDS, ADDS and add a shift parameter
so that all arith instructions can make use of shifted registers.
Signed-off-by: Claudio Fontana claudio.font...@huawei.com
---
tcg/aarch64/tcg-target.c | 46 +-
1 file changed, 29 insertions(+), 17 deletions(-)
diff --git a/tcg/aarch64/tcg-target.c b/tcg/aarch64/tcg-target.c
index ff626eb..b944655 100644
--- a/tcg/aarch64/tcg-target.c
+++ b/tcg/aarch64/tcg-target.c
@@ -186,11 +186,14 @@ enum aarch64_ldst_op_type { /* type of operation */
};
enum aarch64_arith_opc {
-ARITH_ADD = 0x0b,
-ARITH_SUB = 0x4b,
ARITH_AND = 0x0a,
+ARITH_ADD = 0x0b,
ARITH_OR = 0x2a,
-ARITH_XOR = 0x4a
+ARITH_ADDS = 0x2b,
+ARITH_XOR = 0x4a,
+ARITH_SUB = 0x4b,
+ARITH_ANDS = 0x6a,
+ARITH_SUBS = 0x6b,
};
enum aarch64_srr_opc {
@@ -394,12 +397,20 @@ static inline void tcg_out_st(TCGContext *s, TCGType
type, TCGReg arg,
}
static inline void tcg_out_arith(TCGContext *s, enum aarch64_arith_opc opc,
- int ext, TCGReg rd, TCGReg rn, TCGReg rm)
+ int ext, TCGReg rd, TCGReg rn, TCGReg rm,
+ int shift_imm)
{
/* Using shifted register arithmetic operations */
/* if extended registry operation (64bit) just OR with 0x80 24 */
-unsigned int base = ext ? (0x80 | opc) 24 : opc 24;
-tcg_out32(s, base | rm 16 | rn 5 | rd);
+unsigned int shift, base = ext ? (0x80 | opc) 24 : opc 24;
+if (shift_imm == 0) {
+shift = 0;
+} else if (shift_imm 0) {
+shift = shift_imm 10 | 1 22;
+} else /* (shift_imm 0) */ {
+shift = (-shift_imm) 10;
+}
+tcg_out32(s, base | rm 16 | shift | rn 5 | rd);
}
static inline void tcg_out_mul(TCGContext *s, int ext,
@@ -482,11 +493,11 @@ static inline void tcg_out_rotl(TCGContext *s, int ext,
tcg_out_extr(s, ext, rd, rn, rn, bits - (m max));
}
-static inline void tcg_out_cmp(TCGContext *s, int ext, TCGReg rn, TCGReg rm)
+static inline void tcg_out_cmp(TCGContext *s, int ext, TCGReg rn, TCGReg rm,
+ int shift_imm)
{
/* Using CMP alias SUBS wzr, Wn, Wm */
-unsigned int base = ext ? 0xeb1f : 0x6b1f;
-tcg_out32(s, base | rm 16 | rn 5);
+tcg_out_arith(s, ARITH_SUBS, ext, TCG_REG_XZR, rn, rm, shift_imm);
}
static inline void tcg_out_cset(TCGContext *s, int ext, TCGReg rd, TCGCond c)
@@ -830,31 +841,31 @@ static void tcg_out_op(TCGContext *s, TCGOpcode opc,
case INDEX_op_add_i64:
ext = 1; /* fall through */
case INDEX_op_add_i32:
-tcg_out_arith(s, ARITH_ADD, ext, args[0], args[1], args[2]);
+tcg_out_arith(s, ARITH_ADD, ext, args[0], args[1], args[2], 0);
break;
case INDEX_op_sub_i64:
ext = 1; /* fall through */
case INDEX_op_sub_i32:
-tcg_out_arith(s, ARITH_SUB, ext, args[0], args[1], args[2]);
+tcg_out_arith(s, ARITH_SUB, ext, args[0], args[1], args[2], 0);
break;
case INDEX_op_and_i64:
ext = 1; /* fall through */
case INDEX_op_and_i32:
-tcg_out_arith(s, ARITH_AND, ext, args[0], args[1], args[2]);
+tcg_out_arith(s, ARITH_AND, ext, args[0], args[1], args[2], 0);
break;
case INDEX_op_or_i64:
ext = 1; /* fall through */
case INDEX_op_or_i32:
-tcg_out_arith(s, ARITH_OR, ext, args[0], args[1], args[2]);
+tcg_out_arith(s, ARITH_OR, ext, args[0], args[1], args[2], 0);
break;
case INDEX_op_xor_i64:
ext = 1; /* fall through */
case INDEX_op_xor_i32:
-tcg_out_arith(s, ARITH_XOR, ext, args[0], args[1], args[2]);
+tcg_out_arith(s, ARITH_XOR, ext, args[0], args[1], args[2], 0);
break;
case INDEX_op_mul_i64:
@@ -909,7 +920,8 @@ static void tcg_out_op(TCGContext *s, TCGOpcode opc,
if (const_args[2]) {/* ROR / EXTR Wd, Wm, Wm, 32 - m */
tcg_out_rotl(s, ext, args[0], args[1], args[2]);
} else {
-tcg_out_arith(s, ARITH_SUB, 0, TCG_REG_TMP, TCG_REG_XZR, args[2]);
+tcg_out_arith(s, ARITH_SUB, 0,
+ TCG_REG_TMP, TCG_REG_XZR, args[2], 0);
tcg_out_shiftrot_reg(s, SRR_ROR, ext,
args[0], args[1], TCG_REG_TMP);
}
@@ -918,14 +930,14 @@ static void tcg_out_op(TCGContext *s, TCGOpcode opc,
case INDEX_op_brcond_i64:
ext = 1; /* fall through */
case INDEX_op_brcond_i32: /* CMP 0, 1, cond(2), label 3 */
-tcg_out_cmp(s, ext, args[0], args[1]);
+tcg_out_cmp(s, ext, args[0], args[1], 0);
tcg_out_goto_label_cond(s, args[2], args[3]);
break;
case INDEX_op_setcond_i64:
ext = 1; /* fall through */
case INDEX_op_setcond_i32:
-tcg_out_cmp(s, ext, args[1], args[2]);
+tcg_out_cmp(s, ext, args[1], args[2], 0);
[Qemu-devel] [PATCH 3/4] tcg/aarch64: implement byte swap operations
implement the optional byte swap operations with the dedicated
aarch64 instructions.
Signed-off-by: Claudio Fontana claudio.font...@huawei.com
---
tcg/aarch64/tcg-target.c | 32
tcg/aarch64/tcg-target.h | 10 +-
2 files changed, 37 insertions(+), 5 deletions(-)
diff --git a/tcg/aarch64/tcg-target.c b/tcg/aarch64/tcg-target.c
index 3528aa1..aa19a17 100644
--- a/tcg/aarch64/tcg-target.c
+++ b/tcg/aarch64/tcg-target.c
@@ -660,6 +660,20 @@ static inline void tcg_out_goto_label_cond(TCGContext *s,
}
}
+static inline void tcg_out_rev(TCGContext *s, int ext, TCGReg rd, TCGReg rm)
+{
+/* using REV 0x5ac00800 */
+unsigned int base = ext ? 0xdac00c00 : 0x5ac00800;
+tcg_out32(s, base | rm 5 | rd);
+}
+
+static inline void tcg_out_rev16(TCGContext *s, int ext, TCGReg rd, TCGReg rm)
+{
+/* using REV16 0x5ac00400 */
+unsigned int base = ext ? 0xdac00400 : 0x5ac00400;
+tcg_out32(s, base | rm 5 | rd);
+}
+
#ifdef CONFIG_SOFTMMU
#include exec/softmmu_defs.h
@@ -1012,6 +1026,17 @@ static void tcg_out_op(TCGContext *s, TCGOpcode opc,
tcg_out_qemu_st(s, args, 3);
break;
+case INDEX_op_bswap64_i64:
+ext = 1; /* fall through */
+case INDEX_op_bswap32_i64:
+case INDEX_op_bswap32_i32:
+tcg_out_rev(s, ext, args[0], args[1]);
+break;
+case INDEX_op_bswap16_i64:
+case INDEX_op_bswap16_i32:
+tcg_out_rev16(s, 0, args[0], args[1]);
+break;
+
default:
tcg_abort(); /* opcode not implemented */
}
@@ -1093,6 +1118,13 @@ static const TCGTargetOpDef aarch64_op_defs[] = {
{ INDEX_op_qemu_st16, { l, l } },
{ INDEX_op_qemu_st32, { l, l } },
{ INDEX_op_qemu_st64, { l, l } },
+
+{ INDEX_op_bswap16_i32, { r, r } },
+{ INDEX_op_bswap32_i32, { r, r } },
+{ INDEX_op_bswap16_i64, { r, r } },
+{ INDEX_op_bswap32_i64, { r, r } },
+{ INDEX_op_bswap64_i64, { r, r } },
+
{ -1 },
};
diff --git a/tcg/aarch64/tcg-target.h b/tcg/aarch64/tcg-target.h
index 075ab2a..247ef43 100644
--- a/tcg/aarch64/tcg-target.h
+++ b/tcg/aarch64/tcg-target.h
@@ -44,8 +44,8 @@ typedef enum {
#define TCG_TARGET_HAS_ext16s_i32 0
#define TCG_TARGET_HAS_ext8u_i320
#define TCG_TARGET_HAS_ext16u_i32 0
-#define TCG_TARGET_HAS_bswap16_i32 0
-#define TCG_TARGET_HAS_bswap32_i32 0
+#define TCG_TARGET_HAS_bswap16_i32 1
+#define TCG_TARGET_HAS_bswap32_i32 1
#define TCG_TARGET_HAS_not_i32 0
#define TCG_TARGET_HAS_neg_i32 0
#define TCG_TARGET_HAS_rot_i32 1
@@ -68,9 +68,9 @@ typedef enum {
#define TCG_TARGET_HAS_ext8u_i640
#define TCG_TARGET_HAS_ext16u_i64 0
#define TCG_TARGET_HAS_ext32u_i64 0
-#define TCG_TARGET_HAS_bswap16_i64 0
-#define TCG_TARGET_HAS_bswap32_i64 0
-#define TCG_TARGET_HAS_bswap64_i64 0
+#define TCG_TARGET_HAS_bswap16_i64 1
+#define TCG_TARGET_HAS_bswap32_i64 1
+#define TCG_TARGET_HAS_bswap64_i64 1
#define TCG_TARGET_HAS_not_i64 0
#define TCG_TARGET_HAS_neg_i64 0
#define TCG_TARGET_HAS_rot_i64 1
--
1.8.1
[Qemu-devel] [PATCH 2/4] tcg/aarch64: implement AND/TEST immediate pattern
add functions to AND/TEST registers with immediate patterns.
Signed-off-by: Claudio Fontana claudio.font...@huawei.com
---
tcg/aarch64/tcg-target.c | 34 ++
1 file changed, 34 insertions(+)
diff --git a/tcg/aarch64/tcg-target.c b/tcg/aarch64/tcg-target.c
index b944655..3528aa1 100644
--- a/tcg/aarch64/tcg-target.c
+++ b/tcg/aarch64/tcg-target.c
@@ -580,6 +580,40 @@ static inline void tcg_out_call(TCGContext *s,
tcg_target_long target)
}
}
+/* encode a logical immediate, mapping user parameter
+ M=set bits pattern length to S=M-1 */
+static inline unsigned int
+aarch64_limm(unsigned int m, unsigned int r)
+{
+assert(m 0);
+return r 16 | (m - 1) 10;
+}
+
+/* test a register against an immediate bit pattern made of
+ M set bits rotated right by R.
+ Examples:
+ to test a 32/64 reg against 0x0007, pass M = 3, R = 0.
+ to test a 32/64 reg against 0x00ff, pass M = 8, R = 0.
+ to test a 32bit reg against 0xff00, pass M = 8, R = 8.
+ to test a 32bit reg against 0xffff, pass M = 16, R = 8.
+ */
+static inline void tcg_out_tst(TCGContext *s, int ext, TCGReg rn,
+ unsigned int m, unsigned int r)
+{
+/* using TST alias of ANDS XZR, Xn,#bimm64 0x721f */
+unsigned int base = ext ? 0xf240001f : 0x721f;
+tcg_out32(s, base | aarch64_limm(m, r) | rn 5);
+}
+
+/* and a register with a bit pattern, similarly to TST, no flags change */
+static inline void tcg_out_andi(TCGContext *s, int ext, TCGReg rd, TCGReg rn,
+unsigned int m, unsigned int r)
+{
+/* using AND 0x1200 */
+unsigned int base = ext ? 0x9240 : 0x1200;
+tcg_out32(s, base | aarch64_limm(m, r) | rn 5 | rd);
+}
+
static inline void tcg_out_ret(TCGContext *s)
{
/* emit RET { LR } */
--
1.8.1
[Qemu-devel] [PATCH 4/4] tcg/aarch64: implement sign/zero extend operations
implement the optional sign/zero extend operations with the dedicated
aarch64 instructions.
Signed-off-by: Claudio Fontana claudio.font...@huawei.com
---
tcg/aarch64/tcg-target.c | 58 ++--
tcg/aarch64/tcg-target.h | 20 -
2 files changed, 66 insertions(+), 12 deletions(-)
diff --git a/tcg/aarch64/tcg-target.c b/tcg/aarch64/tcg-target.c
index aa19a17..5d0f300 100644
--- a/tcg/aarch64/tcg-target.c
+++ b/tcg/aarch64/tcg-target.c
@@ -674,6 +674,24 @@ static inline void tcg_out_rev16(TCGContext *s, int ext,
TCGReg rd, TCGReg rm)
tcg_out32(s, base | rm 5 | rd);
}
+static inline void tcg_out_sxt(TCGContext *s, int ext, int s_bits,
+ TCGReg rd, TCGReg rn)
+{
+/* using ALIASes SXTB 0x13001c00, SXTH 0x13003c00, SXTW 0x93407c00
+ of SBFM Xd, Xn, #0, #7|15|31 */
+int bits = 8 * (1 s_bits) - 1;
+tcg_out_sbfm(s, ext, rd, rn, 0, bits);
+}
+
+static inline void tcg_out_uxt(TCGContext *s, int s_bits,
+ TCGReg rd, TCGReg rn)
+{
+/* using ALIASes UXTB 0x53001c00, UXTH 0x53003c00
+ of UBFM Wd, Wn, #0, #7|15 */
+int bits = 8 * (1 s_bits) - 1;
+tcg_out_ubfm(s, 0, rd, rn, 0, bits);
+}
+
#ifdef CONFIG_SOFTMMU
#include exec/softmmu_defs.h
@@ -721,8 +739,7 @@ static void tcg_out_qemu_ld(TCGContext *s, const TCGArg
*args, int opc)
tcg_out_callr(s, TCG_REG_TMP);
if (opc 0x04) { /* sign extend */
-unsigned int bits = 8 * (1 s_bits) - 1;
-tcg_out_sbfm(s, 1, data_reg, TCG_REG_X0, 0, bits); /* 7|15|31 */
+tcg_out_sxt(s, 1, s_bits, data_reg, TCG_REG_X0);
} else {
tcg_out_movr(s, 1, data_reg, TCG_REG_X0);
}
@@ -1037,6 +1054,31 @@ static void tcg_out_op(TCGContext *s, TCGOpcode opc,
tcg_out_rev16(s, 0, args[0], args[1]);
break;
+case INDEX_op_ext8s_i64:
+ext = 1; /* fall through */
+case INDEX_op_ext8s_i32:
+tcg_out_sxt(s, ext, 0, args[0], args[1]);
+break;
+case INDEX_op_ext16s_i64:
+ext = 1; /* fall through */
+case INDEX_op_ext16s_i32:
+tcg_out_sxt(s, ext, 1, args[0], args[1]);
+break;
+case INDEX_op_ext32s_i64:
+tcg_out_sxt(s, 1, 2, args[0], args[1]);
+break;
+case INDEX_op_ext8u_i64:
+case INDEX_op_ext8u_i32:
+tcg_out_uxt(s, 0, args[0], args[1]);
+break;
+case INDEX_op_ext16u_i64:
+case INDEX_op_ext16u_i32:
+tcg_out_uxt(s, 1, args[0], args[1]);
+break;
+case INDEX_op_ext32u_i64:
+tcg_out_movr(s, 0, args[0], args[1]);
+break;
+
default:
tcg_abort(); /* opcode not implemented */
}
@@ -1125,6 +1167,18 @@ static const TCGTargetOpDef aarch64_op_defs[] = {
{ INDEX_op_bswap32_i64, { r, r } },
{ INDEX_op_bswap64_i64, { r, r } },
+{ INDEX_op_ext8s_i32, { r, r } },
+{ INDEX_op_ext16s_i32, { r, r } },
+{ INDEX_op_ext8u_i32, { r, r } },
+{ INDEX_op_ext16u_i32, { r, r } },
+
+{ INDEX_op_ext8s_i64, { r, r } },
+{ INDEX_op_ext16s_i64, { r, r } },
+{ INDEX_op_ext32s_i64, { r, r } },
+{ INDEX_op_ext8u_i64, { r, r } },
+{ INDEX_op_ext16u_i64, { r, r } },
+{ INDEX_op_ext32u_i64, { r, r } },
+
{ -1 },
};
diff --git a/tcg/aarch64/tcg-target.h b/tcg/aarch64/tcg-target.h
index 247ef43..97e4a5b 100644
--- a/tcg/aarch64/tcg-target.h
+++ b/tcg/aarch64/tcg-target.h
@@ -40,10 +40,10 @@ typedef enum {
/* optional instructions */
#define TCG_TARGET_HAS_div_i32 0
-#define TCG_TARGET_HAS_ext8s_i320
-#define TCG_TARGET_HAS_ext16s_i32 0
-#define TCG_TARGET_HAS_ext8u_i320
-#define TCG_TARGET_HAS_ext16u_i32 0
+#define TCG_TARGET_HAS_ext8s_i321
+#define TCG_TARGET_HAS_ext16s_i32 1
+#define TCG_TARGET_HAS_ext8u_i321
+#define TCG_TARGET_HAS_ext16u_i32 1
#define TCG_TARGET_HAS_bswap16_i32 1
#define TCG_TARGET_HAS_bswap32_i32 1
#define TCG_TARGET_HAS_not_i32 0
@@ -62,12 +62,12 @@ typedef enum {
#define TCG_TARGET_HAS_muls2_i320
#define TCG_TARGET_HAS_div_i64 0
-#define TCG_TARGET_HAS_ext8s_i640
-#define TCG_TARGET_HAS_ext16s_i64 0
-#define TCG_TARGET_HAS_ext32s_i64 0
-#define TCG_TARGET_HAS_ext8u_i640
-#define TCG_TARGET_HAS_ext16u_i64 0
-#define TCG_TARGET_HAS_ext32u_i64 0
+#define TCG_TARGET_HAS_ext8s_i641
+#define TCG_TARGET_HAS_ext16s_i64 1
+#define TCG_TARGET_HAS_ext32s_i64 1
+#define TCG_TARGET_HAS_ext8u_i641
+#define TCG_TARGET_HAS_ext16u_i64 1
+#define TCG_TARGET_HAS_ext32u_i64 1
#define TCG_TARGET_HAS_bswap16_i64 1
#define TCG_TARGET_HAS_bswap32_i64 1
#define TCG_TARGET_HAS_bswap64_i64 1
--
1.8.1
[Qemu-devel] [Bug 1186984] Re: large -initrd crashes qemu
I'm using qemu from git (f10acc8b38d65a66ffa0588a036489d7fa6a593e). -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1186984 Title: large -initrd crashes qemu Status in QEMU: New Bug description: We don't use large -initrd in libguestfs any more, but I noticed that a large -initrd file now crashes qemu spectacularly: $ ls -lh /tmp/kernel /tmp/initrd -rw-r--r--. 1 rjones rjones 273M Jun 3 14:02 /tmp/initrd lrwxrwxrwx. 1 rjones rjones 35 Jun 3 14:02 /tmp/kernel - /boot/vmlinuz-3.9.4-200.fc18.x86_64 $ ./x86_64-softmmu/qemu-system-x86_64 -L pc-bios \ -kernel /tmp/kernel -initrd /tmp/initrd -hda /tmp/test1.img -serial stdio \ -append console=ttyS0 qemu crashes with one of several errors: PFLASH: Possible BUG - Write block confirm qemu: fatal: Trying to execute code outside RAM or ROM at 0x000b96cd If -enable-kvm is used: KVM: injection failed, MSI lost (Operation not permitted) In all cases the SDL display fills up with coloured blocks before the crash (see the attached screenshot). To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1186984/+subscriptions
[Qemu-devel] [Bug 1186984] [NEW] large -initrd crashes qemu
Public bug reported: We don't use large -initrd in libguestfs any more, but I noticed that a large -initrd file now crashes qemu spectacularly: $ ls -lh /tmp/kernel /tmp/initrd -rw-r--r--. 1 rjones rjones 273M Jun 3 14:02 /tmp/initrd lrwxrwxrwx. 1 rjones rjones 35 Jun 3 14:02 /tmp/kernel - /boot/vmlinuz-3.9.4-200.fc18.x86_64 $ ./x86_64-softmmu/qemu-system-x86_64 -L pc-bios \ -kernel /tmp/kernel -initrd /tmp/initrd -hda /tmp/test1.img -serial stdio \ -append console=ttyS0 qemu crashes with one of several errors: PFLASH: Possible BUG - Write block confirm qemu: fatal: Trying to execute code outside RAM or ROM at 0x000b96cd If -enable-kvm is used: KVM: injection failed, MSI lost (Operation not permitted) In all cases the SDL display fills up with coloured blocks before the crash (see the attached screenshot). ** Affects: qemu Importance: Undecided Status: New ** Attachment added: Coloured blocks screenshot https://bugs.launchpad.net/bugs/1186984/+attachment/3693623/+files/Screenshot%20-%20030613%20-%2014%3A11%3A25.png -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1186984 Title: large -initrd crashes qemu Status in QEMU: New Bug description: We don't use large -initrd in libguestfs any more, but I noticed that a large -initrd file now crashes qemu spectacularly: $ ls -lh /tmp/kernel /tmp/initrd -rw-r--r--. 1 rjones rjones 273M Jun 3 14:02 /tmp/initrd lrwxrwxrwx. 1 rjones rjones 35 Jun 3 14:02 /tmp/kernel - /boot/vmlinuz-3.9.4-200.fc18.x86_64 $ ./x86_64-softmmu/qemu-system-x86_64 -L pc-bios \ -kernel /tmp/kernel -initrd /tmp/initrd -hda /tmp/test1.img -serial stdio \ -append console=ttyS0 qemu crashes with one of several errors: PFLASH: Possible BUG - Write block confirm qemu: fatal: Trying to execute code outside RAM or ROM at 0x000b96cd If -enable-kvm is used: KVM: injection failed, MSI lost (Operation not permitted) In all cases the SDL display fills up with coloured blocks before the crash (see the attached screenshot). To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1186984/+subscriptions
Re: [Qemu-devel] [PATCH scsi-next] vhost-scsi: fix cut-and-paste typo
Il 03/06/2013 14:27, Markus Armbruster ha scritto: Paolo Bonzini pbonz...@redhat.com writes: The copied code comes from vhost_scsi_start. Spotted by Coverity. Cc: qemu-sta...@nongnu.org Signed-off-by: Paolo Bonzini pbonz...@redhat.com Same as Stefan's [PATCH 1/3] vhost-scsi: fix k-set_guest_notifiers() NULL dereference Yes, but his commit message makes more fun of the guy who wrote the code. Since I deserve it, I'm applying his version. Paolo
[Qemu-devel] [PATCH v2 0/7] target-arm: cpregs list for migration, kvm reset
This patch series overhauls how we handle ARM coprocessor registers, so that we use a consistent approach for migration, reset and QEMU-KVM synchronisation, driven by the kernel's list of supported registers. The basic principle here is that we trust the kernel's list of what registers it knows about, and that QEMU doesn't have to have specific knowledge of a coprocessor register to support running and migrating a KVM session on a kernel that does support that register. We maintain a list of cp registers, which is initialized either from the current cpreg hashtable (for TCG), or by querying the kernel (for KVM). For migration we simply send the lists of register indexes and values; migration fails if there's a register the destination kernel is unaware of, or if the value can't be set as required, but isn't gated on whether source or destination QEMU know about the register. We also use the register list to properly reset the vcpu by simply feeding it back the initial set of register values; this fixes a bug where we weren't resetting everything we should have (though Linux guests don't care about most reset values). Note that vm save/load with KVM requires that you run with -machine kernel_irqchip=off, because the kernel doesn't currently support save/load of either the VGIC or virtual timer state. It may also be necessary to nobble the device tree blob to remove the armv7-timer node so the guest doesn't try to use the vtimers. Migration between TCG and KVM is not supported at the moment (it would require us to add a lot of registers to TCG, which I may do at some point, but this is a bit of an obscure usecase IMHO). Changes v1-v2: * added raw write accessors for regs which do a tlb_flush() in their write function (CONTEXTIDR and others) * added kvm-stub.h accidentally omitted in v1 (Remembered to cc kvm list this time around...) Peter Maydell (7): target-arm: Allow special cpregs to have flags set target-arm: Add raw_readfn and raw_writefn to ARMCPRegInfo target-arm: mark up cpregs for no-migrate or raw access target-arm: Convert TCG to using (index,value) list for cp migration target-arm: Initialize cpreg list from KVM when using KVM target-arm: Reinitialize all KVM VCPU registers on reset target-arm: Use tuple list to sync cp regs with KVM target-arm/Makefile.objs |1 + target-arm/cpu-qom.h | 24 target-arm/cpu.c |2 + target-arm/cpu.h | 89 - target-arm/helper.c | 327 +++--- target-arm/kvm-stub.c| 23 target-arm/kvm.c | 292 +++-- target-arm/kvm_arm.h | 33 + target-arm/machine.c | 134 --- 9 files changed, 759 insertions(+), 166 deletions(-) create mode 100644 target-arm/kvm-stub.c -- 1.7.9.5
[Qemu-devel] [PATCH v2] MAINTAINERS: add tcg/aarch64 maintainer
Signed-off-by: Claudio Fontana claudio.font...@huawei.com --- MAINTAINERS | 6 ++ 1 file changed, 6 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index be02724..f4836f7 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -745,6 +745,12 @@ M: qemu-devel@nongnu.org S: Maintained F: tcg/ +AArch64 target +M: Claudio Fontana claudio.font...@huawei.com +M: Claudio Fontana claudio.font...@gmail.com +S: Maintained +F: tcg/aarch64/ + ARM target M: Andrzej Zaborowski balr...@gmail.com S: Maintained -- 1.8.1
[Qemu-devel] [PATCH v2 3/7] target-arm: mark up cpregs for no-migrate or raw access
Mark up coprocessor register definitions to add raw access
functions or mark the register as non-migratable where necessary.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
target-arm/helper.c | 140 ++-
1 file changed, 94 insertions(+), 46 deletions(-)
diff --git a/target-arm/helper.c b/target-arm/helper.c
index 2585d59..baf7576 100644
--- a/target-arm/helper.c
+++ b/target-arm/helper.c
@@ -64,6 +64,20 @@ static int vfp_gdb_set_reg(CPUARMState *env, uint8_t *buf,
int reg)
return 0;
}
+static int raw_read(CPUARMState *env, const ARMCPRegInfo *ri,
+uint64_t *value)
+{
+*value = CPREG_FIELD32(env, ri);
+return 0;
+}
+
+static int raw_write(CPUARMState *env, const ARMCPRegInfo *ri,
+ uint64_t value)
+{
+CPREG_FIELD32(env, ri) = value;
+return 0;
+}
+
static int dacr_write(CPUARMState *env, const ARMCPRegInfo *ri, uint64_t value)
{
env-cp15.c3 = value;
@@ -139,13 +153,13 @@ static const ARMCPRegInfo cp_reginfo[] = {
{ .name = DACR, .cp = 15,
.crn = 3, .crm = CP_ANY, .opc1 = CP_ANY, .opc2 = CP_ANY,
.access = PL1_RW, .fieldoffset = offsetof(CPUARMState, cp15.c3),
- .resetvalue = 0, .writefn = dacr_write },
+ .resetvalue = 0, .writefn = dacr_write, .raw_writefn = raw_write, },
{ .name = FCSEIDR, .cp = 15, .crn = 13, .crm = 0, .opc1 = 0, .opc2 = 0,
.access = PL1_RW, .fieldoffset = offsetof(CPUARMState, cp15.c13_fcse),
- .resetvalue = 0, .writefn = fcse_write },
+ .resetvalue = 0, .writefn = fcse_write, .raw_writefn = raw_write, },
{ .name = CONTEXTIDR, .cp = 15, .crn = 13, .crm = 0, .opc1 = 0, .opc2 =
1,
.access = PL1_RW, .fieldoffset = offsetof(CPUARMState, cp15.c13_fcse),
- .resetvalue = 0, .writefn = contextidr_write },
+ .resetvalue = 0, .writefn = contextidr_write, .raw_writefn = raw_write,
},
/* ??? This covers not just the impdef TLB lockdown registers but also
* some v7VMSA registers relating to TEX remap, so it is overly broad.
*/
@@ -155,13 +169,17 @@ static const ARMCPRegInfo cp_reginfo[] = {
* the unified TLB ops but also the dside/iside/inner-shareable variants.
*/
{ .name = TLBIALL, .cp = 15, .crn = 8, .crm = CP_ANY,
- .opc1 = CP_ANY, .opc2 = 0, .access = PL1_W, .writefn = tlbiall_write, },
+ .opc1 = CP_ANY, .opc2 = 0, .access = PL1_W, .writefn = tlbiall_write,
+ .type = ARM_CP_NO_MIGRATE },
{ .name = TLBIMVA, .cp = 15, .crn = 8, .crm = CP_ANY,
- .opc1 = CP_ANY, .opc2 = 1, .access = PL1_W, .writefn = tlbimva_write, },
+ .opc1 = CP_ANY, .opc2 = 1, .access = PL1_W, .writefn = tlbimva_write,
+ .type = ARM_CP_NO_MIGRATE },
{ .name = TLBIASID, .cp = 15, .crn = 8, .crm = CP_ANY,
- .opc1 = CP_ANY, .opc2 = 2, .access = PL1_W, .writefn = tlbiasid_write, },
+ .opc1 = CP_ANY, .opc2 = 2, .access = PL1_W, .writefn = tlbiasid_write,
+ .type = ARM_CP_NO_MIGRATE },
{ .name = TLBIMVAA, .cp = 15, .crn = 8, .crm = CP_ANY,
- .opc1 = CP_ANY, .opc2 = 3, .access = PL1_W, .writefn = tlbimvaa_write, },
+ .opc1 = CP_ANY, .opc2 = 3, .access = PL1_W, .writefn = tlbimvaa_write,
+ .type = ARM_CP_NO_MIGRATE },
/* Cache maintenance ops; some of this space may be overridden later. */
{ .name = CACHEMAINT, .cp = 15, .crn = 7, .crm = CP_ANY,
.opc1 = 0, .opc2 = CP_ANY, .access = PL1_W,
@@ -196,7 +214,8 @@ static const ARMCPRegInfo not_v7_cp_reginfo[] = {
.resetvalue = 0 },
/* v6 doesn't have the cache ID registers but Linux reads them anyway */
{ .name = DUMMY, .cp = 15, .crn = 0, .crm = 0, .opc1 = 1, .opc2 = CP_ANY,
- .access = PL1_R, .type = ARM_CP_CONST, .resetvalue = 0 },
+ .access = PL1_R, .type = ARM_CP_CONST | ARM_CP_NO_MIGRATE,
+ .resetvalue = 0 },
REGINFO_SENTINEL
};
@@ -235,6 +254,7 @@ static const ARMCPRegInfo v6_cp_reginfo[] = {
REGINFO_SENTINEL
};
+
static int pmreg_read(CPUARMState *env, const ARMCPRegInfo *ri,
uint64_t *value)
{
@@ -366,13 +386,16 @@ static const ARMCPRegInfo v7_cp_reginfo[] = {
{ .name = PMCNTENSET, .cp = 15, .crn = 9, .crm = 12, .opc1 = 0, .opc2 =
1,
.access = PL0_RW, .resetvalue = 0,
.fieldoffset = offsetof(CPUARMState, cp15.c9_pmcnten),
- .readfn = pmreg_read, .writefn = pmcntenset_write },
+ .readfn = pmreg_read, .writefn = pmcntenset_write,
+ .raw_readfn = raw_read, .raw_writefn = raw_write },
{ .name = PMCNTENCLR, .cp = 15, .crn = 9, .crm = 12, .opc1 = 0, .opc2 =
2,
.access = PL0_RW, .fieldoffset = offsetof(CPUARMState, cp15.c9_pmcnten),
- .readfn = pmreg_read, .writefn = pmcntenclr_write },
+ .readfn = pmreg_read, .writefn = pmcntenclr_write,
+ .type = ARM_CP_NO_MIGRATE },
{ .name = PMOVSR, .cp = 15, .crn = 9, .crm = 12, .opc1 = 0, .opc2 = 3,
.access = PL0_RW, .fieldoffset = offsetof(CPUARMState, cp15.c9_pmovsr),
-
[Qemu-devel] [PATCH v2 6/7] target-arm: Reinitialize all KVM VCPU registers on reset
Since the ARM KVM API doesn't include a reset this VCPU
ioctl, we have to capture the initial values of every
register it knows about so that we can reset the VCPU
by feeding those values back again.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
target-arm/cpu-qom.h |6 +-
target-arm/kvm.c | 16
2 files changed, 21 insertions(+), 1 deletion(-)
diff --git a/target-arm/cpu-qom.h b/target-arm/cpu-qom.h
index 2242eee..25239b8 100644
--- a/target-arm/cpu-qom.h
+++ b/target-arm/cpu-qom.h
@@ -72,7 +72,11 @@ typedef struct ARMCPU {
uint64_t *cpreg_indexes;
/* Values of the registers (cpreg_indexes[i]'s value is cpreg_values[i]) */
uint64_t *cpreg_values;
-/* Length of the indexes, values arrays */
+/* When using KVM, keeps a copy of the initial state of the VCPU,
+ * so that on reset we can feed the reset values back into the kernel.
+ */
+uint64_t *cpreg_reset_values;
+/* Length of the indexes, values, reset_values arrays */
int32_t cpreg_array_len;
/* These are used only for migration: incoming data arrives in
* these fields and is sanity checked in post_load before copying
diff --git a/target-arm/kvm.c b/target-arm/kvm.c
index 746ae02..f4a835d 100644
--- a/target-arm/kvm.c
+++ b/target-arm/kvm.c
@@ -162,6 +162,13 @@ int kvm_arch_init_vcpu(CPUState *cs)
goto out;
}
+/* Save a copy of the initial register values so that we can
+ * feed it back to the kernel on VCPU reset.
+ */
+cpu-cpreg_reset_values = g_memdup(cpu-cpreg_values,
+ cpu-cpreg_array_len *
+ sizeof(cpu-cpreg_values[0]));
+
out:
g_free(rlp);
return ret;
@@ -603,6 +610,15 @@ int kvm_arch_handle_exit(CPUState *cs, struct kvm_run *run)
void kvm_arch_reset_vcpu(CPUState *cs)
{
+/* Feed the kernel back its initial register state */
+ARMCPU *cpu = ARM_CPU(cs);
+
+memmove(cpu-cpreg_values, cpu-cpreg_reset_values,
+cpu-cpreg_array_len * sizeof(cpu-cpreg_values[0]));
+
+if (!write_list_to_kvmstate(cpu)) {
+abort();
+}
}
bool kvm_arch_stop_on_emulation_error(CPUState *cs)
--
1.7.9.5
[Qemu-devel] [PATCH] [slirp] fix -net user checks by reordering checks
reorder slirp config options. first check the dns-server-address,
then check the first-dhcp-address. the original code was comparing
the first-dhcp-address with the default dns-server-address, not
the configured dns-server-address.
Signed-off-by: Bas van Sisseren b...@quarantainenet.nl
---
net/slirp.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/net/slirp.c b/net/slirp.c
index b3f35d5..124e953 100644
--- a/net/slirp.c
+++ b/net/slirp.c
@@ -212,19 +212,19 @@ static int net_slirp_init(NetClientState *peer, const
char *model,
return -1;
}
-if (vdhcp_start !inet_aton(vdhcp_start, dhcp)) {
+if (vnameserver !inet_aton(vnameserver, dns)) {
return -1;
}
-if ((dhcp.s_addr mask.s_addr) != net.s_addr ||
-dhcp.s_addr == host.s_addr || dhcp.s_addr == dns.s_addr) {
+if ((dns.s_addr mask.s_addr) != net.s_addr ||
+dns.s_addr == host.s_addr) {
return -1;
}
-if (vnameserver !inet_aton(vnameserver, dns)) {
+if (vdhcp_start !inet_aton(vdhcp_start, dhcp)) {
return -1;
}
-if ((dns.s_addr mask.s_addr) != net.s_addr ||
-dns.s_addr == host.s_addr) {
+if ((dhcp.s_addr mask.s_addr) != net.s_addr ||
+dhcp.s_addr == host.s_addr || dhcp.s_addr == dns.s_addr) {
return -1;
}
--
1.7.10.4
[Qemu-devel] [PULL 1/1] Fix rfe instruction
From: Peter Chubb peter.ch...@nicta.com.au
The rfe instruction has been broken since patch
5a839c0d54fac9db0516904db873a4fe01f50f4b because of a typo.
Signed-off-by: Peter Chubb peter.ch...@nicta.com.au
Reviewed-by: Peter Maydell peter.mayd...@linaro.org
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
target-arm/translate.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target-arm/translate.c b/target-arm/translate.c
index 71135bd..b462f4b 100644
--- a/target-arm/translate.c
+++ b/target-arm/translate.c
@@ -6752,7 +6752,7 @@ static void disas_arm_insn(CPUARMState * env,
DisasContext *s)
tcg_gen_qemu_ld32u(tmp, addr, 0);
tcg_gen_addi_i32(addr, addr, 4);
tmp2 = tcg_temp_new_i32();
-tcg_gen_qemu_ld32u(tmp, addr, 0);
+tcg_gen_qemu_ld32u(tmp2, addr, 0);
if (insn (1 21)) {
/* Base writeback. */
switch (i) {
--
1.7.9.5
Re: [Qemu-devel] [PATCH 0/4] aarch64 TCG tlb fast lookup prerequisites
On 06/03/2013 06:23 AM, Claudio Fontana wrote: Changes from the original series: * added ADDS and ANDS to the shifted regs ops, reorder * split shifted regs ops and test/and immediate into 2 patches * for byte swapping, remove REV32, we can just use REV * fix broken comment in tcg_out_uxt Claudio Fontana (4): tcg/aarch64: improve arith shifted regs operations tcg/aarch64: implement AND/TEST immediate pattern tcg/aarch64: implement byte swap operations tcg/aarch64: implement sign/zero extend operations tcg/aarch64/tcg-target.c | 170 +-- tcg/aarch64/tcg-target.h | 30 - 2 files changed, 166 insertions(+), 34 deletions(-) Reviewed-by: Richard Henderson r...@twiddle.net r~
[Qemu-devel] [PATCH v2 1/7] target-arm: Allow special cpregs to have flags set
Relax the is this a valid ARMCPRegInfo type value? check to permit
special cpregs to have flags other than ARM_CP_SPECIAL set. At
the moment none of the other flags are relevant for special regs,
but the migration related flag we're about to introduce can apply
here too.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
target-arm/cpu.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target-arm/cpu.h b/target-arm/cpu.h
index 5438444..737c00c 100644
--- a/target-arm/cpu.h
+++ b/target-arm/cpu.h
@@ -456,7 +456,7 @@ static inline bool cptype_valid(int cptype)
{
return ((cptype ~ARM_CP_FLAG_MASK) == 0)
|| ((cptype ARM_CP_SPECIAL)
-(cptype = ARM_LAST_SPECIAL));
+((cptype ~ARM_CP_FLAG_MASK) = ARM_LAST_SPECIAL));
}
/* Access rights:
--
1.7.9.5
[Qemu-devel] [PATCH] MAINTAINERS: add tcg/aarch64 maintainer
Signed-off-by: Claudio Fontana claudio.font...@huawei.com --- MAINTAINERS | 6 ++ 1 file changed, 6 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index be02724..f4836f7 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -745,6 +745,12 @@ M: qemu-devel@nongnu.org S: Maintained F: tcg/ +AArch64 target +M: Claudio Fontana claudio.font...@huawei.com +M: Claudio Fontana claudio.font...@gmail.com +S: Maintained +F: tcg/aarch64 + ARM target M: Andrzej Zaborowski balr...@gmail.com S: Maintained -- 1.8.1
[Qemu-devel] [PATCH v2 7/7] target-arm: Use tuple list to sync cp regs with KVM
Use the tuple list of cp registers for syncing KVM state to QEMU,
rather than only syncing a very minimal set by hand.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
target-arm/kvm.c | 103 +-
1 file changed, 33 insertions(+), 70 deletions(-)
diff --git a/target-arm/kvm.c b/target-arm/kvm.c
index f4a835d..5c91ab7 100644
--- a/target-arm/kvm.c
+++ b/target-arm/kvm.c
@@ -344,17 +344,6 @@ typedef struct Reg {
offsetof(CPUARMState, QEMUFIELD) \
}
-#define CP15REG(CRN, CRM, OPC1, OPC2, QEMUFIELD) \
-{\
-KVM_REG_ARM | KVM_REG_SIZE_U32 | \
-(15 KVM_REG_ARM_COPROC_SHIFT) | \
-((CRN) KVM_REG_ARM_32_CRN_SHIFT) |\
-((CRM) KVM_REG_ARM_CRM_SHIFT) | \
-((OPC1) KVM_REG_ARM_OPC1_SHIFT) | \
-((OPC2) KVM_REG_ARM_32_OPC2_SHIFT), \
-offsetof(CPUARMState, QEMUFIELD) \
-}
-
#define VFPSYSREG(R) \
{ \
KVM_REG_ARM | KVM_REG_SIZE_U32 | KVM_REG_ARM_VFP | \
@@ -403,12 +392,6 @@ static const Reg regs[] = {
COREREG(fiq_regs[7], banked_spsr[5]),
/* R15 */
COREREG(usr_regs.uregs[15], regs[15]),
-/* A non-comprehensive set of cp15 registers.
- * TODO: drive this from the cp_regs hashtable instead.
- */
-CP15REG(1, 0, 0, 0, cp15.c1_sys), /* SCTLR */
-CP15REG(2, 0, 0, 2, cp15.c2_control), /* TTBCR */
-CP15REG(3, 0, 0, 0, cp15.c3), /* DACR */
/* VFP system registers */
VFPSYSREG(FPSID),
VFPSYSREG(MVFR1),
@@ -426,7 +409,6 @@ int kvm_arch_put_registers(CPUState *cs, int level)
int mode, bn;
int ret, i;
uint32_t cpsr, fpscr;
-uint64_t ttbr;
/* Make sure the banked regs are properly set */
mode = env-uncached_cpsr CPSR_M;
@@ -460,26 +442,6 @@ int kvm_arch_put_registers(CPUState *cs, int level)
return ret;
}
-/* TTBR0: cp15 crm=2 opc1=0 */
-ttbr = ((uint64_t)env-cp15.c2_base0_hi 32) | env-cp15.c2_base0;
-r.id = KVM_REG_ARM | KVM_REG_SIZE_U64 | (15 KVM_REG_ARM_COPROC_SHIFT) |
-(2 KVM_REG_ARM_CRM_SHIFT) | (0 KVM_REG_ARM_OPC1_SHIFT);
-r.addr = (uintptr_t)(ttbr);
-ret = kvm_vcpu_ioctl(cs, KVM_SET_ONE_REG, r);
-if (ret) {
-return ret;
-}
-
-/* TTBR1: cp15 crm=2 opc1=1 */
-ttbr = ((uint64_t)env-cp15.c2_base1_hi 32) | env-cp15.c2_base1;
-r.id = KVM_REG_ARM | KVM_REG_SIZE_U64 | (15 KVM_REG_ARM_COPROC_SHIFT) |
-(2 KVM_REG_ARM_CRM_SHIFT) | (1 KVM_REG_ARM_OPC1_SHIFT);
-r.addr = (uintptr_t)(ttbr);
-ret = kvm_vcpu_ioctl(cs, KVM_SET_ONE_REG, r);
-if (ret) {
-return ret;
-}
-
/* VFP registers */
r.id = KVM_REG_ARM | KVM_REG_SIZE_U64 | KVM_REG_ARM_VFP;
for (i = 0; i 32; i++) {
@@ -496,6 +458,31 @@ int kvm_arch_put_registers(CPUState *cs, int level)
fpscr = vfp_get_fpscr(env);
r.addr = (uintptr_t)fpscr;
ret = kvm_vcpu_ioctl(cs, KVM_SET_ONE_REG, r);
+if (ret) {
+return ret;
+}
+
+/* Note that we do not call write_cpustate_to_list()
+ * here, so we are only writing the tuple list back to
+ * KVM. This is safe because nothing can change the
+ * CPUARMState cp15 fields (in particular gdb accesses cannot)
+ * and so there are no changes to sync. In fact syncing would
+ * be wrong at this point: for a constant register where TCG and
+ * KVM disagree about its value, the preceding write_list_to_cpustate()
+ * would not have had any effect on the CPUARMState value (since the
+ * register is read-only), and a write_cpustate_to_list() here would
+ * then try to write the TCG value back into KVM -- this would either
+ * fail or incorrectly change the value the guest sees.
+ *
+ * If we ever want to allow the user to modify cp15 registers via
+ * the gdb stub, we would need to be more clever here (for instance
+ * tracking the set of registers kvm_arch_get_registers() successfully
+ * managed to update the CPUARMState with, and only allowing those
+ * to be written back up into the kernel).
+ */
+if (!write_list_to_kvmstate(cpu)) {
+return EINVAL;
+}
return ret;
}
@@ -508,7 +495,6 @@ int kvm_arch_get_registers(CPUState *cs)
int mode, bn;
int ret, i;
uint32_t cpsr, fpscr;
-uint64_t ttbr;
for (i = 0; i ARRAY_SIZE(regs); i++) {
r.id = regs[i].id;
@@ -529,28 +515,6 @@ int kvm_arch_get_registers(CPUState *cs)
}
cpsr_write(env, cpsr, 0x);
-/* TTBR0: cp15 crm=2 opc1=0 */
-r.id = KVM_REG_ARM | KVM_REG_SIZE_U64 | (15 KVM_REG_ARM_COPROC_SHIFT) |
-(2 KVM_REG_ARM_CRM_SHIFT) | (0 KVM_REG_ARM_OPC1_SHIFT);
-r.addr = (uintptr_t)(ttbr);
-ret = kvm_vcpu_ioctl(cs, KVM_GET_ONE_REG, r);
-if (ret) {
-return ret;
-
Re: [Qemu-devel] Could configure generate QEMU's linker scripts?
On 06/02/2013 10:15 AM, Peter Maydell wrote: So for a new architecture how do we determine whether we need to fiddle with the start address or not? (More specifically, is aarch64 going to need a linker script or just to go in the configure list of hosts which don't need one ?) Basically, for a non-PIE build, is there room to run the -linux-user guest binary? That means getting out of the way of the guest's default link location. If the host default link location is above 2G you may be good; above 4G is even better. r~
[Qemu-devel] [PULL 0/1] target-arm queue
Only one change in this pullreq, but I'm going away for a week and I think the bugfix is worth getting into master before then. Please pull. thanks -- PMM The following changes since commit f10acc8b38d65a66ffa0588a036489d7fa6a593e: tcx: Fix 24-bit display mode (2013-06-02 16:45:40 +) are available in the git repository at: git://git.linaro.org/people/pmaydell/qemu-arm.git target-arm.next for you to fetch changes up to 5866e078770cba631a33e6d3062afa7a4068adf8: Fix rfe instruction (2013-06-03 14:59:29 +0100) Peter Chubb (1): Fix rfe instruction target-arm/translate.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Re: [Qemu-devel] [PATCH 1/4] tcg-ppc64: Fix RLDCL opcode
On 06/02/2013 05:27 AM, Anton Blanchard wrote: The rldcl instruction doesn't have an sh field, so the minor opcode of 8 is actually 4 when using the XO30 macro. Cc: qemu-sta...@nongnu.org Signed-off-by: Anton Blanchard an...@samba.org --- Index: b/tcg/ppc64/tcg-target.c === --- a/tcg/ppc64/tcg-target.c +++ b/tcg/ppc64/tcg-target.c @@ -357,7 +357,7 @@ static int tcg_target_const_match (tcg_t #define RLDICL XO30( 0) #define RLDICR XO30( 1) #define RLDIMI XO30( 3) -#define RLDCL XO30( 8) +#define RLDCL XO30( 4) Oops. But that suggests then that we ought not be using XO30. Or at least adding a comment. r~
Re: [Qemu-devel] [PATCH 2/4] tcg-ppc64: bswap64 rotates output 32 bits
On 06/02/2013 05:28 AM, Anton Blanchard wrote: If our input and output is in the same register, bswap64 tries to undo a rotate of the input. This just ends up rotating the output. Cc: qemu-sta...@nongnu.org Signed-off-by: Anton Blanchard an...@samba.org Reviewed-by: Richard Henderson r...@twiddle.net r~
Re: [Qemu-devel] [PATCH 3/4] tcg-ppc64: Fix add2_i64
On 06/02/2013 05:29 AM, Anton Blanchard wrote: add2_i64 was adding the lower double word to the upper double word of each input. Fix this so we add the lower double words, then the upper double words with carry propagation. Cc: qemu-sta...@nongnu.org Signed-off-by: Anton Blanchard an...@samba.org Reviewed-by: Richard Henderson r...@twiddle.net r~
Re: [Qemu-devel] [PATCH 4/4] tcg-ppc64: rotr_i32 rotates wrong amount
On 06/02/2013 05:30 AM, Anton Blanchard wrote: rotr_i32 calculates the amount to left shift and puts it into a temporary, but then doesn't use it when doing the shift. Cc: qemu-sta...@nongnu.org Signed-off-by: Anton Blanchard an...@samba.org --- Reviewed-by: Richard Henderson r...@twiddle.net r~
[Qemu-devel] Biweekly upstream qemu-kvm test report (using autotest + manual) - June 3rd, 2013
Hi, Please find the result of upstream testing, we ran the test cases against following git versions: Host kernel 3.9.0+ (Upstream), Base Kernel is RHEL 7 Alpha 3 x86_64 v3.9-10518-gd7ab73 Branch master SHA1 d7ab7302f970a254997687a1cdede421a5635c68 uname -a Linux localhost.localdomain 3.9.0+ #1 SMP Tue May 7 05:32:40 EDT 2013 x86_64 x86_64 x86_64 GNU/Linux cat /etc/redhat-release Red Hat Enterprise Linux Server release 7.0 Alpha3 (Maipo) Qemu 1.5.0 Libvirt 1.0.5 v1.0.5-57-ga605b Branch master SHA1 a605b7e041a6702373c967f2735282288790ce39 Guest : RHEL.6.4 64bit GA Tests Status -- unattended_install.cdrom.extra_cdrom_ks PASS physical_resources_check PASS qemu_img.check PASS autotest.cpu_hotplugPASS boot PASS timedrift PASS shutdown PASS system_reset_bootable PASS stop_continue PASS numa_opts PASS Ballon PASS Ksm Parallel PASS Seabois (passed manually)PASS qemu_img.check PASS qemu_img.create PASS usb_storage PASS autotest.sleeptestPASS smbios_table PASS cgroup PASS qmp_basic PASS autotest.monotonic_time PASS autotest.disktest PASS autotest.tsc PASS autotest.hwclock PASS autotest.rtcPASS autotest.dbenchPASS Below are the failed test cases, we are analysing the failures for the same: 1. NMI Watchdog 2. NIC Bonding 3. NIC Hotplug 4. Perf KVM 5. VM Stop 6. Kernel IRQ chip on Feature List planning to cover in the next iteration: - Live Migration (with and without shared Storage) / Virt Storage Migration Virt Guest Suspend/Hibernate support CPU - Hotplug/ Memory Hotplug Virt Live Snapshots Thanks, Chandrashekar
[Qemu-devel] [PATCH v2 2/7] target-arm: Add raw_readfn and raw_writefn to ARMCPRegInfo
For reading and writing register values from the kernel for KVM,
we need to provide accessor functions which are guaranteed to succeed
and don't impose access checks, mask out unwritable bits, etc.
Define new fields raw_readfn and raw_writefn for this purpose;
these only need to be provided if there is a readfn or writefn
already and it is not suitable.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
target-arm/cpu.h| 18 +-
target-arm/helper.c | 13 +
2 files changed, 30 insertions(+), 1 deletion(-)
diff --git a/target-arm/cpu.h b/target-arm/cpu.h
index 737c00c..1d8eba5 100644
--- a/target-arm/cpu.h
+++ b/target-arm/cpu.h
@@ -434,19 +434,22 @@ void armv7m_nvic_complete_irq(void *opaque, int irq);
* a register definition to override a previous definition for the
* same (cp, is64, crn, crm, opc1, opc2) tuple: either the new or the
* old must have the OVERRIDE bit set.
+ * NO_MIGRATE indicates that this register should be ignored for migration;
+ * (eg because any state is accessed via some other coprocessor register).
*/
#define ARM_CP_SPECIAL 1
#define ARM_CP_CONST 2
#define ARM_CP_64BIT 4
#define ARM_CP_SUPPRESS_TB_END 8
#define ARM_CP_OVERRIDE 16
+#define ARM_CP_NO_MIGRATE 32
#define ARM_CP_NOP (ARM_CP_SPECIAL | (1 8))
#define ARM_CP_WFI (ARM_CP_SPECIAL | (2 8))
#define ARM_LAST_SPECIAL ARM_CP_WFI
/* Used only as a terminator for ARMCPRegInfo lists */
#define ARM_CP_SENTINEL 0x
/* Mask of only the flag bits in a type field */
-#define ARM_CP_FLAG_MASK 0x1f
+#define ARM_CP_FLAG_MASK 0x3f
/* Return true if cptype is a valid type field. This is used to try to
* catch errors where the sentinel has been accidentally left off the end
@@ -562,6 +565,19 @@ struct ARMCPRegInfo {
* by fieldoffset.
*/
CPWriteFn *writefn;
+/* Function for doing a raw read; used when we need to copy
+ * coprocessor state to the kernel for KVM or out for
+ * migration. This only needs to be provided if there is also a
+ * readfn and it makes an access permission check.
+ */
+CPReadFn *raw_readfn;
+/* Function for doing a raw write; used when we need to copy KVM
+ * kernel coprocessor state into userspace, or for inbound
+ * migration. This only needs to be provided if there is also a
+ * writefn and it makes an access permission check or masks out
+ * unwritable bits or has write-one-to-clear or similar behaviour.
+ */
+CPWriteFn *raw_writefn;
/* Function for resetting the register. If NULL, then reset will be done
* by writing resetvalue to the field specified in fieldoffset. If
* fieldoffset is 0 then no reset will be done.
diff --git a/target-arm/helper.c b/target-arm/helper.c
index fd055e8..2585d59 100644
--- a/target-arm/helper.c
+++ b/target-arm/helper.c
@@ -1392,6 +1392,19 @@ void define_one_arm_cp_reg_with_opaque(ARMCPU *cpu,
r2-crm = crm;
r2-opc1 = opc1;
r2-opc2 = opc2;
+/* By convention, for wildcarded registers only the first
+ * entry is used for migration; the others are marked as
+ * NO_MIGRATE so we don't try to transfer the register
+ * multiple times. Special registers (ie NOP/WFI) are
+ * never migratable.
+ */
+if ((r-type ARM_CP_SPECIAL) ||
+((r-crm == CP_ANY) crm != 0) ||
+((r-opc1 == CP_ANY) opc1 != 0) ||
+((r-opc2 == CP_ANY) opc2 != 0)) {
+r2-type |= ARM_CP_NO_MIGRATE;
+}
+
/* Overriding of an existing definition must be explicitly
* requested.
*/
--
1.7.9.5
[Qemu-devel] [PATCH v2 5/7] target-arm: Initialize cpreg list from KVM when using KVM
When using KVM, use the kernel's initial state to set up the
cpreg list, and sync to and from the kernel when doing
migration.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
target-arm/Makefile.objs |1 +
target-arm/kvm-stub.c| 23 +++
target-arm/kvm.c | 164 +-
target-arm/kvm_arm.h | 33 ++
target-arm/machine.c | 30 +++--
5 files changed, 245 insertions(+), 6 deletions(-)
create mode 100644 target-arm/kvm-stub.c
diff --git a/target-arm/Makefile.objs b/target-arm/Makefile.objs
index d89b57c..4a6e52e 100644
--- a/target-arm/Makefile.objs
+++ b/target-arm/Makefile.objs
@@ -1,5 +1,6 @@
obj-y += arm-semi.o
obj-$(CONFIG_SOFTMMU) += machine.o
obj-$(CONFIG_KVM) += kvm.o
+obj-$(CONFIG_NO_KVM) += kvm-stub.o
obj-y += translate.o op_helper.o helper.o cpu.o
obj-y += neon_helper.o iwmmxt_helper.o
diff --git a/target-arm/kvm-stub.c b/target-arm/kvm-stub.c
new file mode 100644
index 000..cd1849f
--- /dev/null
+++ b/target-arm/kvm-stub.c
@@ -0,0 +1,23 @@
+/*
+ * QEMU KVM ARM specific function stubs
+ *
+ * Copyright Linaro Limited 2013
+ *
+ * Author: Peter Maydell peter.mayd...@linaro.org
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ *
+ */
+#include qemu-common.h
+#include kvm_arm.h
+
+bool write_kvmstate_to_list(ARMCPU *cpu)
+{
+abort();
+}
+
+bool write_list_to_kvmstate(ARMCPU *cpu)
+{
+abort();
+}
diff --git a/target-arm/kvm.c b/target-arm/kvm.c
index 4aea7c3..746ae02 100644
--- a/target-arm/kvm.c
+++ b/target-arm/kvm.c
@@ -50,12 +50,35 @@ unsigned long kvm_arch_vcpu_id(CPUState *cpu)
return cpu-cpu_index;
}
+static bool reg_syncs_via_tuple_list(uint64_t regidx)
+{
+/* Return true if the regidx is a register we should synchronize
+ * via the cpreg_tuples array (ie is not a core reg we sync by
+ * hand in kvm_arch_get/put_registers())
+ */
+switch (regidx KVM_REG_ARM_COPROC_MASK) {
+case KVM_REG_ARM_CORE:
+case KVM_REG_ARM_VFP:
+return false;
+default:
+return true;
+}
+}
+
+static int compare_u64(const void *a, const void *b)
+{
+return *(uint64_t *)a - *(uint64_t *)b;
+}
+
int kvm_arch_init_vcpu(CPUState *cs)
{
struct kvm_vcpu_init init;
-int ret;
+int i, ret, arraylen;
uint64_t v;
struct kvm_one_reg r;
+struct kvm_reg_list rl;
+struct kvm_reg_list *rlp;
+ARMCPU *cpu = ARM_CPU(cs);
init.target = KVM_ARM_TARGET_CORTEX_A15;
memset(init.features, 0, sizeof(init.features));
@@ -74,6 +97,73 @@ int kvm_arch_init_vcpu(CPUState *cs)
if (ret == -ENOENT) {
return -EINVAL;
}
+
+/* Populate the cpreg list based on the kernel's idea
+ * of what registers exist (and throw away the TCG-created list).
+ */
+rl.n = 0;
+ret = kvm_vcpu_ioctl(cs, KVM_GET_REG_LIST, rl);
+if (ret != -E2BIG) {
+return ret;
+}
+rlp = g_malloc(sizeof(struct kvm_reg_list) + rl.n * sizeof(uint64_t));
+rlp-n = rl.n;
+ret = kvm_vcpu_ioctl(cs, KVM_GET_REG_LIST, rlp);
+if (ret) {
+goto out;
+}
+/* Sort the list we get back from the kernel, since cpreg_tuples
+ * must be in strictly ascending order.
+ */
+qsort(rlp-reg, rlp-n, sizeof(rlp-reg[0]), compare_u64);
+
+for (i = 0, arraylen = 0; i rlp-n; i++) {
+if (!reg_syncs_via_tuple_list(rlp-reg[i])) {
+continue;
+}
+switch (rlp-reg[i] KVM_REG_SIZE_MASK) {
+case KVM_REG_SIZE_U32:
+case KVM_REG_SIZE_U64:
+break;
+default:
+fprintf(stderr, Can't handle size of register in kernel list\n);
+ret = -EINVAL;
+goto out;
+}
+
+arraylen++;
+}
+
+cpu-cpreg_indexes = g_renew(uint64_t, cpu-cpreg_indexes, arraylen);
+cpu-cpreg_values = g_renew(uint64_t, cpu-cpreg_values, arraylen);
+cpu-cpreg_vmstate_indexes = g_renew(uint64_t, cpu-cpreg_vmstate_indexes,
+ arraylen);
+cpu-cpreg_vmstate_values = g_renew(uint64_t, cpu-cpreg_vmstate_values,
+arraylen);
+cpu-cpreg_array_len = arraylen;
+cpu-cpreg_vmstate_array_len = arraylen;
+
+for (i = 0, arraylen = 0; i rlp-n; i++) {
+uint64_t regidx = rlp-reg[i];
+if (!reg_syncs_via_tuple_list(regidx)) {
+continue;
+}
+cpu-cpreg_indexes[arraylen] = regidx;
+arraylen++;
+}
+assert(cpu-cpreg_array_len == arraylen);
+
+if (!write_kvmstate_to_list(cpu)) {
+/* Shouldn't happen unless kernel is inconsistent about
+ * what registers exist.
+ */
+fprintf(stderr, Initial read of kernel register state failed\n);
+ret = -EINVAL;
+goto out;
+}
+
+out:
+g_free(rlp);
return ret;
}
@@ -163,6 +253,78 @@ void
[Qemu-devel] [Bug 1186935] Re: [1.5] QEMU monitor gets overlapped by GTK menu bar
What version of gtk is this? -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1186935 Title: [1.5] QEMU monitor gets overlapped by GTK menu bar Status in QEMU: New Bug description: The QEMU minitor gets partially hidden by the menu bar which was introduced in QEMU version 1.5.0. Steps to reproduce: 1. Run `qemu-system-x86_64` 2. Press Ctrl + Alt + 2 (or use the menu bar) 3. Observe that the monitor output is partially shown, without the compat_monitor0 console and QEMU 1.5.0 monitor - type 'help' for more information lines. Attached is a screenshot of `qemu-system-x86_64` and `qemu-system- x86_64 -display sdl`. Version: 1.5.0 Distribution: Arch Linux 64-bit To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1186935/+subscriptions
