Re: [Qemu-devel] general question
My code calls the following macro, but nothing happens.
#define invlpg_asm(pageaddr) do{\ asm volatile("invlpg %0\n\t" \
:\ :"m"(pageaddr)); \}while(0)
pageaddr is the virtual address that needs to be invalidated.
It is said that cup before i486 does not support "invlpg", how can I know the
cupmodel of my emulator.
Does my code go wrong, or the cpu of my emulator fail to support this
instruction?
--- 12年5月31日，周四, 陳韋任 (Wei-Ren Chen) 写道：
发件人: 陳韋任 (Wei-Ren Chen)
主题: Re: [Qemu-devel] general question
收件人: "Max Filippov"
抄送: "���f任 (Wei-Ren Chen)" , "吴晓琳"
, qemu-devel@nongnu.org
日期: 2012年5月31日,周四,下午5:21
> Hmmm, does it?
>
> void helper_invlpg(target_ulong addr)
> {
> helper_svm_check_intercept_param(SVM_EXIT_INVLPG, 0);
> tlb_flush_page(env, addr);
> }
I would be wrong, so let the code speak. ;)
---
void tlb_flush_page(CPUArchState *env, target_ulong addr)
{
if ((addr & env->tlb_flush_mask) == env->tlb_flush_addr) {
tlb_flush(env, 1); --- (1)
return;
}
... snip ...
addr &= TARGET_PAGE_MASK;
i = (addr >> TARGET_PAGE_BITS) & (CPU_TLB_SIZE - 1);
for (mmu_idx = 0; mmu_idx < NB_MMU_MODES; mmu_idx++) {
tlb_flush_entry(&env->tlb_table[mmu_idx][i], addr);
}
tb_flush_jmp_cache(env, addr);
}
---
The comment of tlb_flush (1) says,
QEMU doesn't currently implement a global/not-global flag
for tlb entries, at the moment tlb_flush() will also flush all
tlb entries in the flush_global == false case.
That's why I get impression on QEMU flush the entire tlb. So it could flush
particular tlb entry in tlb_flush_entry?
Regards,
chenwj
--
Wei-Ren Chen (陳韋任)
Computer Systems Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667
Homepage: http://people.cs.nctu.edu.tw/~chenwj
[Qemu-devel] 转发: Re: general question
--- 12年6月1日，周五, 吴晓琳 写道：
发件人: 吴晓琳
主题: Re: [Qemu-devel] general question
收件人: che...@iis.sinica.edu.tw
抄送: jcmvb...@gmail.com, qemu-devel@nongnu.org
日期: 2012年6月1日,周五,下午3:11
My code calls the following macro, but nothing happens.
#define invlpg_asm(pageaddr) do{\ asm volatile("invlpg %0\n\t" \
:\ :"m"(pageaddr)); \}while(0)
pageaddr is the virtual address that needs to be invalidated.
It is said that cup before i486 does not support "invlpg", how can I know the
cupmodel of my emulator.
Does my code go wrong, or the cpu of my emulator fail to support this
instruction?
--- 12年5月31日，周四, 陳韋任 (Wei-Ren Chen)
写道：
发件人: 陳韋任 (Wei-Ren Chen)
主题: Re: [Qemu-devel] general question
收件人: "Max Filippov"
抄送: "���f任 (Wei-Ren Chen)" , "吴晓琳"
, qemu-devel@nongnu.org
日期: 2012年5月31日,周四,下午5:21
> Hmmm, does it?
>
> void helper_invlpg(target_ulong addr)
> {
> helper_svm_check_intercept_param(SVM_EXIT_INVLPG, 0);
> tlb_flush_page(env, addr);
> }
I would be wrong, so let the code speak. ;)
---
void tlb_flush_page(CPUArchState *env, target_ulong addr)
{
if ((addr &
env->tlb_flush_mask) == env->tlb_flush_addr) {
tlb_flush(env, 1); --- (1)
return;
}
... snip ...
addr &= TARGET_PAGE_MASK;
i = (addr >> TARGET_PAGE_BITS) & (CPU_TLB_SIZE - 1);
for (mmu_idx = 0; mmu_idx < NB_MMU_MODES; mmu_idx++) {
tlb_flush_entry(&env->tlb_table[mmu_idx][i], addr);
}
tb_flush_jmp_cache(env, addr);
}
---
The comment of tlb_flush (1) says,
QEMU doesn't currently implement a global/not-global flag
for tlb entries, at the moment tlb_flush() will also flush all
tlb entries in the flush_global == false case.
That's why I get impression on QEMU flush the entire tlb. So it could flush
particular tlb entry in
tlb_flush_entry?
Regards,
chenwj
--
Wei-Ren Chen (陳韋任)
Computer Systems Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667
Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] [PATCH block-next 0/3] qemu-img check/qcow2: Allow fixing refcounts
On Fri, Jun 1, 2012 at 6:22 AM, Zhi Yong Wu wrote: > On Thu, May 31, 2012 at 5:26 PM, Stefan Hajnoczi wrote: >> On Wed, May 30, 2012 at 9:31 AM, Zhi Yong Wu wrote: >>> On Sat, May 12, 2012 at 12:48 AM, Kevin Wolf wrote: A prerequisite for a "QED mode" in qcow2, which doesn't update the refcount >>> Recently some new concepts such as "QED mode" in qcow2 are seen >>> frequencely, can anyone explain what it means? thanks. >> >> qcow2 has more metadata than qed. More metadata means more write >> operations when allocating new clusters. >> >> In order to overcome this performance issue qcow2 has a metadata >> cache. But when QEMU is launched with -drive ...,cache=writethrough >> (the default) the metadata cache *must* be in writethrough mode > Why must i be? If the option with -drive ..,cache=writethrough is > specified. it means that host page cache is on while guest disk cache > is off. Since the metadata cache exists in host page cache, not guest, > i think that it is in writeback mode. Since the emulated disk write cache is off, we must ensure that guest writes are on disk before completing them. Therefore we cannot cache metadata updates in host RAM - it would be lost on power failure but we promised the guest its writes reached the disk! >> instead of writeback mode. In other words, every metadata update >> needs to be written to the image file before we complete the guest's > What will mean one guest's wirte request is completed? For example, virtio-blk fills in the success status code and raises an interrupt. This notifies the guest that the write is done. >> write request. This means the metadata cache only hides the metadata >> performance issue when -drive ...,cache=direct|writeback are used >> because there we can keep metadata changes buffered in memory until >> the guest flushes the emulated disk write cache. >> >> "QED mode" is a solution for -drive ...,cache=writethrough|directsync. >> It simply doesn't update refcount metadata in the qcow2 image file >> immediately in exchange for a refcount fixup step that is introduced > Can you say this with more details? Why is this step need only when > image file is opened? After image file is opened, and some guest's > write requests are completed, maybe the refcount fixup step need to be > done once. If we don't update refcounts on disk then they become outdated and no longer reflect the true allocation information. It's not safe to rely on outdated refcount information since we could allocate the same cluster multiple times - this means data corruption. By running a consistency check when opening a dirty image file we guarantee that we have accurate refcount information again. As an optimization we will commit refcount information to disk when closing the image file and mark it clean. This means a clean QEMU shutdown does not require a consistency check on startup - but in the worst case (power failure or crash) we will have a dirty image file. Stefan
Re: [Qemu-devel] Any approach to log the file read/write (I/O data flow) like the "-d in_asm" option?
On Fri, Jun 1, 2012 at 4:11 AM, Yue Chen wrote: > Any approach to log all the file read/write (I/O data flow) in order, > together with the instruction traces in QEMU? Thanks. It sounds like you may be running a *-user target because softmmu (system emulation) has no knowledge of file I/O inside the guest. Please give more details of what you're trying to do if this is incorrect. It sounds like you want strace together with -d in_asm output. Have you seen linux-user/strace.c? Stefan
Re: [Qemu-devel] Can we improve virtio data structures with QOM?
On 06/01/2012 12:48 AM, Markus Armbruster wrote: Anthony Liguori writes: [On how to model virtio devices in QOM:] Basically, it should look like: VirtioPCIDevice is-a PCIDevice VirtioPCIDevice has-a link Could you explain why this is link<> and not child<>? So you can do: qemu -device virtio-pci,id=foo,vdev=bar -device virtio-blk,id=bar,bus=foo The alternative would be: qemu -device virtio-pci,id=foo,child_type=virtio-blk But that feels ugly to me. If you want to have a variable type of device, a link is the right tool. BTW, I make no mention of BusState here. That's intentional. There's no need to involve buses IMHO. Regards, Anthony Liguori VirtioDevice is-a DeviceState VirtioBlk is-a VirtioDevice VirtioNet is-a VirtioDevice ... VirtioPCIBlk is-a VirtioPCIDevice VirtioPCIBlk has-a child This gives us backwards compat while also providing a cleaner model. VirtioPCIBlk et al would be deprecated eventually (but not any time soon).
Re: [Qemu-devel] Can't convert to vmdk with the streamOptimized subformat
On Thu, May 31, 2012 at 11:25 AM, Sebastien Douche wrote: > On Thu, May 31, 2012 at 11:10 AM, Stefan Hajnoczi wrote: >> Hi Sebastien, > > Hi Stephan > >> It won't be possible for QEMU 1.1 since the release is imminent. > > Sad news. This bug impose Virtualbox for the conversion :(. > > BTW, thanks Stephan for your quick reponse. If you have some spare time and C programming knowledge you could try to write a fix for QEMU 1.2. The problem is that qemu-img convert is writing to the same cluster twice but streamOptimized is a write-once format. We need to find a way to handle this case gracefully, either by avoiding the double write or by relaxing this constraint in block/vmdk.c. Stefan
Re: [Qemu-devel] Proposed patch: huge RX speedup for hw/e1000.c
Works me. I can now receive at 1.15 Mpps, slightly
faster than my previous patch which generated unnecessary
writes to the signalling socket.
Tested-by: Luigi Rizzo
On Thu, May 31, 2012 at 12:03 PM, Paolo Bonzini wrote:
> Il 31/05/2012 10:23, Jan Kiszka ha scritto:
> >> > @@ -922,6 +923,7 @@ set_rdt(E1000State *s, int index, uint32_t val)
> >> > {
> >> > s->check_rxov = 0;
> >> > s->mac_reg[index] = val & 0x;
> >> > +qemu_notify_event();
> > This still looks like the wrong tool: Packets that can't be delivered
> > are queued.
>
> Packets that are read from the tap but can't be delivered are queued;
> packets that are left on the tap need qemu_notify_event to be flushed.
>
> > So we need to flush the queue and clear the blocked delivery
> > there. qemu_flush_queued_packets appears more appropriate for this.
>
> Right, and qemu_flush_queued_packets needs to call qemu_notify_event
> which makes the call in virtio-net unnecessary.
>
> Paolo
>
> diff --git a/hw/e1000.c b/hw/e1000.c
> index 4573f13..43d933a 100644
> --- a/hw/e1000.c
> +++ b/hw/e1000.c
> @@ -295,6 +295,7 @@ set_rx_control(E1000State *s, int index, uint32_t val)
> s->rxbuf_min_shift = ((val / E1000_RCTL_RDMTS_QUAT) & 3) + 1;
> DBGOUT(RX, "RCTL: %d, mac_reg[RCTL] = 0x%x\n", s->mac_reg[RDT],
>s->mac_reg[RCTL]);
> +qemu_flush_queued_packets(&s->nic->nc);
> }
>
> static void
> @@ -926,6 +927,9 @@ set_rdt(E1000State *s, int index, uint32_t val)
> {
> s->check_rxov = 0;
> s->mac_reg[index] = val & 0x;
> +if (e1000_has_rxbufs(s, 1)) {
> +qemu_flush_queued_packets(&s->nic->nc);
> +}
> }
>
> static void
> diff --git a/hw/virtio-net.c b/hw/virtio-net.c
> index 3f190d4..0974945 100644
> --- a/hw/virtio-net.c
> +++ b/hw/virtio-net.c
> @@ -447,10 +447,6 @@ static void virtio_net_handle_rx(VirtIODevice *vdev,
> VirtQueue *vq)
> VirtIONet *n = to_virtio_net(vdev);
>
> qemu_flush_queued_packets(&n->nic->nc);
> -
> -/* We now have RX buffers, signal to the IO thread to break out of the
> - * select to re-poll the tap file descriptor */
> -qemu_notify_event();
> }
>
> static int virtio_net_can_receive(VLANClientState *nc)
> diff --git a/net.c b/net.c
> index 1922d8a..fa846ae 100644
> --- a/net.c
> +++ b/net.c
> @@ -491,7 +491,12 @@ void qemu_flush_queued_packets(VLANClientState *vc)
> queue = vc->send_queue;
> }
>
> -qemu_net_queue_flush(queue);
> +if (qemu_net_queue_flush(queue)) {
> +/* We emptied the queue successfully, signal to the IO thread to
> repoll
> + * the file descriptor (for tap, for example).
> + */
> +qemu_notify_event();
> +}
> }
>
> static ssize_t qemu_send_packet_async_with_flags(VLANClientState *sender,
> diff --git a/net/queue.c b/net/queue.c
> index 1ab5247..fd1c7e6 100644
> --- a/net/queue.c
> +++ b/net/queue.c
> @@ -232,7 +232,7 @@ void qemu_net_queue_purge(NetQueue *queue,
> VLANClientState *from)
> }
> }
>
> -void qemu_net_queue_flush(NetQueue *queue)
> +bool qemu_net_queue_flush(NetQueue *queue)
> {
> while (!QTAILQ_EMPTY(&queue->packets)) {
> NetPacket *packet;
> @@ -248,7 +248,7 @@ void qemu_net_queue_flush(NetQueue *queue)
> packet->size);
> if (ret == 0) {
> QTAILQ_INSERT_HEAD(&queue->packets, packet, entry);
> -break;
> +return 0;
> }
>
> if (packet->sent_cb) {
> @@ -257,4 +257,5 @@ void qemu_net_queue_flush(NetQueue *queue)
>
> g_free(packet);
> }
> +return 1;
> }
> diff --git a/net/queue.h b/net/queue.h
> index a31958e..4bf6d3c 100644
> --- a/net/queue.h
> +++ b/net/queue.h
> @@ -66,6 +66,6 @@ ssize_t qemu_net_queue_send_iov(NetQueue *queue,
> NetPacketSent *sent_cb);
>
> void qemu_net_queue_purge(NetQueue *queue, VLANClientState *from);
> -void qemu_net_queue_flush(NetQueue *queue);
> +bool qemu_net_queue_flush(NetQueue *queue);
>
> #endif /* QEMU_NET_QUEUE_H */
>
--
-+---
Prof. Luigi RIZZO, ri...@iet.unipi.it . Dip. di Ing. dell'Informazione
http://www.iet.unipi.it/~luigi/. Universita` di Pisa
TEL +39-050-2211611 . via Diotisalvi 2
Mobile +39-338-6809875 . 56122 PISA (Italy)
-+---
Re: [Qemu-devel] [PATCH block-next 0/3] qemu-img check/qcow2: Allow fixing refcounts
On Fri, Jun 1, 2012 at 4:06 PM, Stefan Hajnoczi wrote: > On Fri, Jun 1, 2012 at 6:22 AM, Zhi Yong Wu wrote: >> On Thu, May 31, 2012 at 5:26 PM, Stefan Hajnoczi wrote: >>> On Wed, May 30, 2012 at 9:31 AM, Zhi Yong Wu wrote: On Sat, May 12, 2012 at 12:48 AM, Kevin Wolf wrote: > A prerequisite for a "QED mode" in qcow2, which doesn't update the > refcount Recently some new concepts such as "QED mode" in qcow2 are seen frequencely, can anyone explain what it means? thanks. >>> >>> qcow2 has more metadata than qed. More metadata means more write >>> operations when allocating new clusters. >>> >>> In order to overcome this performance issue qcow2 has a metadata >>> cache. But when QEMU is launched with -drive ...,cache=writethrough >>> (the default) the metadata cache *must* be in writethrough mode >> Why must i be? If the option with -drive ..,cache=writethrough is >> specified. it means that host page cache is on while guest disk cache >> is off. Since the metadata cache exists in host page cache, not guest, >> i think that it is in writeback mode. > > Since the emulated disk write cache is off, we must ensure that guest > writes are on disk before completing them. Therefore we cannot cache > metadata updates in host RAM - it would be lost on power failure but But host page cache is *on* in this mode, which means that metadata should be cached in host RAM. how do you explain this? > we promised the guest its writes reached the disk! > >>> instead of writeback mode. In other words, every metadata update >>> needs to be written to the image file before we complete the guest's >> What will mean one guest's wirte request is completed? > > For example, virtio-blk fills in the success status code and raises an > interrupt. This notifies the guest that the write is done. Great, thanks. > >>> write request. This means the metadata cache only hides the metadata >>> performance issue when -drive ...,cache=direct|writeback are used >>> because there we can keep metadata changes buffered in memory until >>> the guest flushes the emulated disk write cache. >>> >>> "QED mode" is a solution for -drive ...,cache=writethrough|directsync. >>> It simply doesn't update refcount metadata in the qcow2 image file l1/l2 info need to be updated to qcow2 image file? >>> immediately in exchange for a refcount fixup step that is introduced >> Can you say this with more details? Why is this step need only when >> image file is opened? After image file is opened, and some guest's >> write requests are completed, maybe the refcount fixup step need to be >> done once. > > If we don't update refcounts on disk then they become outdated and no > longer reflect the true allocation information. It's not safe to rely > on outdated refcount information since we could allocate the same > cluster multiple times - this means data corruption. By running a > consistency check when opening a dirty image file we guarantee that we > have accurate refcount information again. ah, i got it now. > > As an optimization we will commit refcount information to disk when > closing the image file and mark it clean. This means a clean QEMU > shutdown does not require a consistency check on startup - but in the > worst case (power failure or crash) we will have a dirty image file. Yeah, a consistency check on startup is good, i think. thanks. > > Stefan -- Regards, Zhi Yong Wu
Re: [Qemu-devel] Can we improve virtio data structures with QOM?
Anthony Liguori writes: > On 06/01/2012 12:48 AM, Markus Armbruster wrote: >> Anthony Liguori writes: >> >> [On how to model virtio devices in QOM:] >>> Basically, it should look like: >>> >>> VirtioPCIDevice is-a PCIDevice >>> >>> VirtioPCIDevice has-a link >> >> Could you explain why this is link<> and not child<>? > > So you can do: > > qemu -device virtio-pci,id=foo,vdev=bar -device virtio-blk,id=bar,bus=foo This lets folks specify both directions of the virtio-pci <-> virtio-blk connection independently. What if $dev->bus->vdev != $dev, i.e. the backlink doesn't point back? Easiest way to avoid that is to deny access to the backlink, and set it automatically instead. Wouldn't be surprised if such bi-directional links turned out to be a pretty common pattern. In qdev, we've always called the property naming the parent "bus", because it's always been a qbus. Doesn't make sense here: the property refers to a device, not a bus. Should we call it something else? > The alternative would be: > > qemu -device virtio-pci,id=foo,child_type=virtio-blk > > But that feels ugly to me. If you want to have a variable type of > device, a link is the right tool. Okay, that's a general rule (I was hoping you'd state one). Do we have a place for such rules, or do we expect people to learn them by osmosis? > BTW, I make no mention of BusState here. That's intentional. There's > no need to involve buses IMHO. I never liked qbus anyway.
Re: [Qemu-devel] [RFC PATCH V1 1/2] arm_boot: added linux switch
Am 01.06.2012 03:16, schrieb Peter A. G. Crosthwaite:
> Added a switch to tell the bootloader that the image is linux and should be
> bootstrapped as such. This is needed to boot an elf that is linux.
>
> Syntax would be:
>
> qemu-system-arm ... -kernel linux.elf -machine linux=on
>
> Signed-off-by: Peter A. G. Crosthwaite
> ---
> hw/arm_boot.c |1 +
> qemu-config.c |4
> 2 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/hw/arm_boot.c b/hw/arm_boot.c
> index 7447f5c..8e25873b 100644
> --- a/hw/arm_boot.c
> +++ b/hw/arm_boot.c
> @@ -320,6 +320,7 @@ void arm_load_kernel(CPUARMState *env, struct
> arm_boot_info *info)
Beware that this signature has changed on qom-next branch, but I don't
see a conflict here.
Andreas
> machine_opts = qemu_opts_find(qemu_find_opts("machine"), 0);
> if (machine_opts) {
> info->dtb_filename = qemu_opt_get(machine_opts, "dtb");
> +is_linux = qemu_opt_get_bool(machine_opts, "linux", 0) ? 1 : 0;
> } else {
> info->dtb_filename = NULL;
> }
> diff --git a/qemu-config.c b/qemu-config.c
> index be84a03..0ee781c 100644
> --- a/qemu-config.c
> +++ b/qemu-config.c
> @@ -582,6 +582,10 @@ static QemuOptsList qemu_machine_opts = {
> .name = "dtb",
> .type = QEMU_OPT_STRING,
> .help = "Linux kernel device tree file",
> +}, {
> +.name = "linux",
> +.type = QEMU_OPT_BOOL,
> +.help = "Bootstrap Linux",
> },
> { /* End of list */ }
> },
--
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] [Qemu-discuss] ARM7TDMI support
I have not much idea and have not worked for that processor. But there seems to be patches available for ARM7TDMI http://www.mail-archive.com/qemu-devel@nongnu.org/msg11154.html On Fri, Jun 1, 2012 at 2:42 AM, Vinicius Sanches wrote: > Actually I already did it. It does not have any indication about that > core. I was looking for inside the source code and it is not listed inside > cpu.h file. I'm asking about it becuase of some differences in some > behaviors in BLX, BX, CP15 and pop operations related to Thumb mode. The V5 > and V4T are different on it. Do you know some patch to enable these > feautures probperly? > > Thanks and regards, > > 2012/5/31 peeyush Agrawal > >> you can install the ubuntu (either by apt-get or by "$./configure && make >> && make install") >> then check whether the require core is supported by qemu using following >> command: >> qemu-system-arm -M ? >> It will list all the emulated machine by qemu. >> In case you are doubtful about which machine is use, you can hit-n-trial >> each machine. >> >> good luck.. >> >> >> >> On Wed, May 30, 2012 at 7:57 AM, Vinicius Sanches < >> viniciusrsanc...@gmail.com> wrote: >> >>> Hello All! >>> >>> I'm new QEMU user and I was wondering if it is possible to emulate an >>> ARM7TDMI/ARM7TDMI-S core properly with that new 1.0.1 version released. Is >>> that possible, or do I have to apply some patch to do it? >>> >>> Thanks and regards! >>> >> >> >> >> -- >> >> o >> | _ o|_ o __ _| >> _| (_| || | | | |(_| >> >> Peeyush Agrawal. >> >> > -- o | _ o|_ o __ _| _| (_| || | | | |(_| Peeyush Agrawal.
[Qemu-devel] [Bug 1007269] [NEW] Can’t install or boot up 32bit win8 guest.
Public bug reported: Environment: Host OS (ia32/ia32e/IA64):ia32e Guest OS (ia32/ia32e/IA64):ia32e Guest OS Type (Linux/Windows):Linux(rhel6u1) kvm.git Commit:51bfd2998113e1f8ce8dcf853407b76a04b5f2a0 qemu-kvm Commit:3fd9fedb9fae4517d93d76e93a2924559cacf2f6 Host Kernel Version:3.4.0-rc7 Hardware:WSM-EP,Romley-EP Bug detailed description: -- it can't install or boot up 32bit Win8(Consumer Preview Update 2) guest. The guest will crash with the following error, while 64bit Win8 and 32bit Win7 guest work fine. -Win8 Error--- Your computer needs to restart. Please hold down the power button. Error code: 0x005D Parameters: 0x03060D03 0x756E6547 0x49656E69 0x6C65746E -Win8 Error--- "0x005D" code means "UNSUPPORTED_PROCESSOR" in Windows. BTW, you can get 32bit Win8 ISO from the following website. http://windows.microsoft.com/en-US/windows-8/iso Reproduce steps: 1. get 32 bit win8 ISO 2. prepare a disk image: dd if=/dev/zero of=/root/win8-32.img bs=1M count=16384 3. start a guest to install 32bit win8: qemu-system –m 4096 –smp 4 –hda /root/win8-32.img –cdrom /media/32bit-Win8.iso 4. if you have a 32bit win8 image,try to boot it up Current result: 32bit Win8 guest crash Expected result: 32bit win8 guest boot up correctly ** Affects: qemu Importance: Undecided Status: New -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1007269 Title: Can’t install or boot up 32bit win8 guest. Status in QEMU: New Bug description: Environment: Host OS (ia32/ia32e/IA64):ia32e Guest OS (ia32/ia32e/IA64):ia32e Guest OS Type (Linux/Windows):Linux(rhel6u1) kvm.git Commit:51bfd2998113e1f8ce8dcf853407b76a04b5f2a0 qemu-kvm Commit:3fd9fedb9fae4517d93d76e93a2924559cacf2f6 Host Kernel Version:3.4.0-rc7 Hardware:WSM-EP,Romley-EP Bug detailed description: -- it can't install or boot up 32bit Win8(Consumer Preview Update 2) guest. The guest will crash with the following error, while 64bit Win8 and 32bit Win7 guest work fine. -Win8 Error--- Your computer needs to restart. Please hold down the power button. Error code: 0x005D Parameters: 0x03060D03 0x756E6547 0x49656E69 0x6C65746E -Win8 Error--- "0x005D" code means "UNSUPPORTED_PROCESSOR" in Windows. BTW, you can get 32bit Win8 ISO from the following website. http://windows.microsoft.com/en-US/windows-8/iso Reproduce steps: 1. get 32 bit win8 ISO 2. prepare a disk image: dd if=/dev/zero of=/root/win8-32.img bs=1M count=16384 3. start a guest to install 32bit win8: qemu-system –m 4096 –smp 4 –hda /root/win8-32.img –cdrom /media/32bit-Win8.iso 4. if you have a 32bit win8 image,try to boot it up Current result: 32bit Win8 guest crash Expected result: 32bit win8 guest boot up correctly To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1007269/+subscriptions
Re: [Qemu-devel] Can we improve virtio data structures with QOM?
On 06/01/2012 05:25 PM, Markus Armbruster wrote: Anthony Liguori writes: On 06/01/2012 12:48 AM, Markus Armbruster wrote: Anthony Liguori writes: [On how to model virtio devices in QOM:] Basically, it should look like: VirtioPCIDevice is-a PCIDevice VirtioPCIDevice has-a link Could you explain why this is link<> and not child<>? So you can do: qemu -device virtio-pci,id=foo,vdev=bar -device virtio-blk,id=bar,bus=foo This lets folks specify both directions of the virtio-pci<-> virtio-blk connection independently. What if $dev->bus->vdev != $dev, i.e. the backlink doesn't point back? Then the user did something silly. If you're really asking, should we expect a user to use a command line like this? Absolutely not! A user should use something like -drive file=foo.img,if=virtio Heck, I still think we should do -vda foo.img. Easiest way to avoid that is to deny access to the backlink, and set it automatically instead. Wouldn't be surprised if such bi-directional links turned out to be a pretty common pattern. Most likely they will. But I don't think users should be setting any links in the first place. In qdev, we've always called the property naming the parent "bus", because it's always been a qbus. Doesn't make sense here: the property refers to a device, not a bus. Should we call it something else? Actually, in qdev it's called parent_bus. The alternative would be: qemu -device virtio-pci,id=foo,child_type=virtio-blk But that feels ugly to me. If you want to have a variable type of device, a link is the right tool. Okay, that's a general rule (I was hoping you'd state one). Do we have a place for such rules, or do we expect people to learn them by osmosis? I actually just did a tutorial session out here walking through how to write device emulation from scratch. I would thinking of making a QOM Style Guide based on that. I'm pretty short on free time for the next week but I'll try to queue it up. If anyone wants to take a first pass, I'd happily review it and contribute. BTW, I make no mention of BusState here. That's intentional. There's no need to involve buses IMHO. I never liked qbus anyway. qbus never liked any of us too FWIW. It was a real jerk that way. Regards, Anthony Liguori
Re: [Qemu-devel] [PATCH qom-next] qom: make object cast assert if NULL object is passed as argument
Am 31.05.2012 13:17, schrieb Igor Mammedov: > On 05/31/2012 12:16 PM, Paolo Bonzini wrote: >> Il 31/05/2012 10:30, Markus Armbruster ha scritto: > Makes much sense, but maybe it should be done in OBJECT() cast? Assert > when we do OBJECT(NULL). >>> In my opinion, OBJECT(p) where p is a null pointer is perfectly valid >>> and should yield a null pointer. >> >> Perhaps object_dynamic_cast and object_dynamic_cast_assert should do the >> same? >> > > or better object_dynamic_cast should return NULL if obj is NULL, > after all it's expected that it may return NULL That's what I was suggesting: I think that we should define "NULL is not of type TYPE_FOO" and thus have the ..._is_... functions return false, and have the ..._cast_assert assert. So I still think this patch is correct. It could be accompanied by further patches adding error handling in the remaining functions. 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 qom-next] qom: make object cast assert if NULL object is passed as argument
Am 31.05.2012 10:30, schrieb Markus Armbruster:
> Igor Mitsyanko writes:
>
>> On 05/30/2012 08:19 PM, Igor Mammedov wrote:
>>> without assert it will crash at following point:
>>> OBJECT_CHECK(type, obj, name) \
>>> ((type *)object_dynamic_cast_assert(OBJECT(obj), (name)))
>>>=> object_dynamic_cast(obj, typename)
>>> => object_is_type(obj, target_type)
>>>=> type_is_ancestor(obj->class->type, target_type);
>>> ^^^
>>> so abort earlier and print nice message instead of SIGSEGV
>>>
>>> Signed-off-by: Igor Mammedov
>>> ---
>>> qom/object.c |2 ++
>>> 1 files changed, 2 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/qom/object.c b/qom/object.c
>>> index 00bb3b0..444e2fc 100644
>>> --- a/qom/object.c
>>> +++ b/qom/object.c
>>> @@ -481,6 +481,8 @@ Object *object_dynamic_cast_assert(Object *obj, const
>>> char *typename)
>>> {
>>> Object *inst;
>>>
>>> +g_assert(obj != NULL);
>>> +
>>> inst = object_dynamic_cast(obj, typename);
>>>
>>> if (!inst) {
>> Makes much sense, but maybe it should be done in OBJECT() cast? Assert
>> when we do OBJECT(NULL).
>
> In my opinion, OBJECT(p) where p is a null pointer is perfectly valid
> and should yield a null pointer.
Paolo, today OBJECT(p) is a pure C cast. I wonder if that was due to
TYPE_OBJECT being NULL at the time. Should we reconsider that on
qom-next with your patches to turn TYPE_OBJECT into a regular type?
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] linux-user: fix multi-threaded /proc/self/maps
On 01.06.2012, at 04:17, Peter Maydell wrote: > On 1 June 2012 02:45, Alexander Graf wrote: >> On 01.06.2012, at 03:39, Peter Maydell wrote: >>> On 1 June 2012 02:16, Alexander Graf wrote: On 01.06.2012, at 02:44, Peter Maydell wrote: > So in the multithreaded case do all the thread stacks live > in this one mapping, or do the non-primary thread stacks > live in a standard mmap'd mapping? I thought /proc/self/maps always shows the initial stack map as [stack]? >>> >>> I dunno, I asked because I'm too lazy to check myself :-) >> >> Same here. Mind to check? Your time zone fits this better atm ;) > > So none of the processes on my system have more than one [stack] > mapping, even the multithreaded ones. OTOH the kernel sources: > http://lxr.free-electrons.com/source/fs/proc/task_mmu.c#L262 > indicate that it is possible for them to print [stack:TID] for > a thread stack in some cases... > > However, I think your change is right, because the secondary > threads ought to see the main process /proc/self/maps and > that should show the main stack. > > Q: I think the reason for the > #if defined(TARGET_ARM) || defined(TARGET_M68K) || defined(TARGET_UNICORE32) > is because linux-user/main.c only sets up ts->stack_base > on those targets. If we're not using ts->stack_base > any more can we drop the #if here? > > (more generally I wonder if we can drop ts->stack_base completely > in favour of ts->info->start_stack...) Good point. Maybe? Alex
Re: [Qemu-devel] [PATCH v11 1/9] Add MigrationParams structure
Orit Wasserman wrote:
> From: Isaku Yamahata
>
> Signed-off-by: Isaku Yamahata
Reviewed-by: Juan Quintela
> @@ -1570,7 +1571,7 @@ int qemu_savevm_state_begin(QEMUFile *f, int
> blk_enable, int shared)
> if(se->set_params == NULL) {
> continue;
> }
> - se->set_params(blk_enable, shared, se->opaque);
> +se->set_params(params, se->opaque);
Extra spaces here.
Later, Juan.
Re: [Qemu-devel] [PATCH v11 2/9] Add migration capabilites
Orit Wasserman wrote:
> Add migration capabiltes that can be queried by the management.
> The managment can query the source QEMU and the destination QEMU in order to
> verify both support some migration capability (currently only XBZRLE).
> The managment can enable a capabilty for the next migration by using
> migrate_set_parameter command.
>
> Signed-off-by: Orit Wasserman
> +void qmp_migrate_set_parameter(const char *parameter, Error **errp)
> +{
> +MigrationState *s = migrate_get_current();
> +int i;
> +
> +if (s->state == MIG_STATE_ACTIVE) {
> +error_set(errp, QERR_MIGRATION_ACTIVE);
> +return;
> +}
> +
> +for (i = 0; i < MIGRATION_CAPABILITY_MAX; i++) {
> +if (strcmp(parameter, MigrationCapability_lookup[i]) == 0) {
> +s->enabled_capabilities[i] = true;
> +return;
> +}
> +}
> +
> +error_set(errp, QERR_INVALID_PARAMETER, parameter);
> +}
Two things here:
- Is there a way to disable capabilities? it seems no.
- Would we want in the future capabilities that are not "bool"? Just
asking loud, I haven't thought a lot about this. Fixing it as a
paramenter, it would make trivial to fix previous comment: cap:true vs
cap:false, or whatever syntax we want.
> memset(s, 0, sizeof(*s));
> s->bandwidth_limit = bandwidth_limit;
> s->params = *params;
> +memcpy(s->enabled_capabilities, enabled_capabilities,
> + sizeof(enabled_capabilities));
>
> -s->bandwidth_limit = bandwidth_limit;
> s->state = MIG_STATE_SETUP;
Nice catch/cleanup.
> diff --git a/savevm.c b/savevm.c
> index dd66f2c..42937a0 100644
> --- a/savevm.c
> +++ b/savevm.c
> @@ -1711,7 +1711,7 @@ static int qemu_savevm_state(QEMUFile *f)
> int ret;
> MigrationParams params = {
> .blk = 0,
> -.shared = 0
> +.shared = 0,
> };
>
> if (qemu_savevm_state_blocked(NULL)) {
This belongs to previous patch?
Later, Juan.
Re: [Qemu-devel] [PATCH v11 3/9] Add XBZRLE documentation
> +This work was originally based on research results published checkpatch complains about this space. Rest of patch looks nice.
Re: [Qemu-devel] [PATCH v11 4/9] Add cache handling functions
Orit Wasserman wrote: > Add LRU page cache mechanism. > The page are accessed by their address. > > Signed-off-by: Benoit Hudzia > Signed-off-by: Petter Svard > Signed-off-by: Aidan Shribman > Signed-off-by: Orit Wasserman Reviewed-by: Juan Quintela
Re: [Qemu-devel] [PATCH v11 5/9] Add uleb encoding/decoding functions
Orit Wasserman wrote: > Implement Unsigned Little Endian Base 128. > > Signed-off-by: Orit Wasserman Reviewed-by: Juan Quintela
Re: [Qemu-devel] [PATCH v11 6/9] Add save_block_hdr function
Orit Wasserman wrote: > Signed-off-by: Benoit Hudzia > Signed-off-by: Petter Svard > Signed-off-by: Aidan Shribman > Signed-off-by: Orit Wasserman Reviewed-by: Juan Quintela
Re: [Qemu-devel] [PATCH v11 9/9] Add XBZRLE statistics
Orit Wasserman wrote: > Signed-off-by: Benoit Hudzia > Signed-off-by: Petter Svard > Signed-off-by: Aidan Shribman > Signed-off-by: Orit Wasserman Reviewed-by: Juan Quintela
[Qemu-devel] arm return
In arm user mode, where does qemu exit? Where is last qemu's instruction?
I.E.
int main (){return 0;}
in what file does qemu run "return 0"??
Re: [Qemu-devel] [PATCH qom-next] qom: make object cast assert if NULL object is passed as argument
Andreas Färber writes: > Am 31.05.2012 13:17, schrieb Igor Mammedov: >> On 05/31/2012 12:16 PM, Paolo Bonzini wrote: >>> Il 31/05/2012 10:30, Markus Armbruster ha scritto: >> Makes much sense, but maybe it should be done in OBJECT() cast? Assert >> when we do OBJECT(NULL). In my opinion, OBJECT(p) where p is a null pointer is perfectly valid and should yield a null pointer. >>> >>> Perhaps object_dynamic_cast and object_dynamic_cast_assert should do the >>> same? >>> >> >> or better object_dynamic_cast should return NULL if obj is NULL, >> after all it's expected that it may return NULL > > That's what I was suggesting: I think that we should define "NULL is not > of type TYPE_FOO" and thus have the ..._is_... functions return false, > and have the ..._cast_assert assert. Is it? Igor: object_dynamic_cast should return NULL if obj is NULL, You: have the ..._cast_assert assert [on null argument, I presume] Doesn't sound like the same suggestion to me :) If I understood you correctly: what do such assertions buy us other than silliness like p ? some_cast(p) : NULL ? > So I still think this patch is correct. It could be accompanied by > further patches adding error handling in the remaining functions. I'm not convinced.
Re: [Qemu-devel] [PATCH v11 8/9] Add set_cachesize command
Orit Wasserman wrote:
> Change XBZRLE cache size in bytes (the size should be a power of 2).
> If XBZRLE cache size is too small there will be many cache miss.
>
> Signed-off-by: Benoit Hudzia
> Signed-off-by: Petter Svard
> Signed-off-by: Aidan Shribman
> Signed-off-by: Orit Wasserman
> +void qmp_migrate_set_cachesize(int64_t value, Error **errp)
> +{
> +MigrationState *s = migrate_get_current();
> +
> +/* Check for truncation */
> +if (value != (size_t)value) {
> +error_set(errp, QERR_INVALID_PARAMETER_VALUE, "cache size",
> + "exceeding address space");
> +return;
> +}
> +
> +value = MIN(UINT64_MAX, value);
This looks fishy to say the least. value is signed. Is there any way
that UINT64_MAX is going to be smaller than value?
Re: [Qemu-devel] [PATCH v11 7/9] Add XBZRLE to ram_save_block and ram_save_live
Orit Wasserman wrote:
> In the outgoing migration check to see if the page is cached and
> changed than send compressed page by using save_xbrle_page function.
> In the incoming migration check to see if RAM_SAVE_FLAG_XBRLE is set
> and decompress the page (by using load_xbrle function).
This patch can be split to easy review.
> --- a/arch_init.c
> +++ b/arch_init.c
> @@ -43,6 +43,15 @@
> #include "hw/smbios.h"
> #include "exec-memory.h"
> #include "hw/pcspk.h"
> +#include "qemu/cache.h"
> +
> +#ifdef DEBUG_ARCH_INIT
> +#define DPRINTF(fmt, ...) \
> +do { fprintf(stdout, "arch_init: " fmt, ## __VA_ARGS__); } while (0)
> +#else
> +#define DPRINTF(fmt, ...) \
> +do { } while (0)
> +#endif
Independent of xbzrle.
>
> #ifdef TARGET_SPARC
> int graphic_width = 1024;
> @@ -94,6 +103,7 @@ const uint32_t arch_type = QEMU_ARCH;
> #define RAM_SAVE_FLAG_PAGE 0x08
> #define RAM_SAVE_FLAG_EOS 0x10
> #define RAM_SAVE_FLAG_CONTINUE 0x20
> +#define RAM_SAVE_FLAG_XBZRLE 0x40
>
> #ifdef __ALTIVEC__
> #include
> @@ -157,6 +167,22 @@ static int is_dup_page(uint8_t *page)
> return 1;
> }
>
> +/* XBZRLE (Xor Based Zero Length Encoding */
> +typedef struct XBZRLEHeader {
> +uint32_t xh_cksum;
We are still not using this value, and we are sending it anyway (with a
value of zero). What happens when we start using if for a checksum, and
we migration to a new version that "expects" it to be valid? I would
preffer not to sent it, or sent the correct value.
> +uint16_t xh_len;
> +uint8_t xh_flags;
> +} XBZRLEHeader;
> +
> +/* struct contains XBZRLE cache and a static page
> + used by the compression */
> +static struct {
> +/* buffer used for XBZRLE encoding */
> +uint8_t *encoded_buf;
> +/* Cache for XBZRLE */
> +Cache *cache;
> +} XBZRLE = {0};
Use c99 initializers, please.
{ .encoded_buf = NULL,
.cache = NULL,
}
More instances in other parts.
> +
> static void save_block_hdr(QEMUFile *f, RAMBlock *block, ram_addr_t offset,
> int cont, int flag)
> {
> @@ -169,19 +195,78 @@ static void save_block_hdr(QEMUFile *f, RAMBlock
> *block, ram_addr_t offset,
>
> }
>
> +#define ENCODING_FLAG_XBZRLE 0x1
> +
> +static int save_xbzrle_page(QEMUFile *f, uint8_t *current_data,
> +ram_addr_t current_addr, RAMBlock *block,
> +ram_addr_t offset, int cont)
> +{
> +int encoded_len = 0, bytes_sent = -1, ret = -1;
> +XBZRLEHeader hdr = {0};
> +uint8_t *prev_cached_page;
> +
> +/* check to see if page is cached , if not cache and return */
> +if (!cache_is_cached(XBZRLE.cache, current_addr)) {
> +cache_insert(XBZRLE.cache, current_addr, g_memdup(current_data,
> + TARGET_PAGE_SIZE));
> +goto done;
> +}
> +
> +prev_cached_page = get_cached_data(XBZRLE.cache, current_addr);
> +
> +/* XBZRLE encoding (if there is no overflow) */
> +encoded_len = xbzrle_encode_buffer(prev_cached_page, current_data,
> + TARGET_PAGE_SIZE, XBZRLE.encoded_buf,
> + TARGET_PAGE_SIZE);
> +if (encoded_len == 0) {
> +bytes_sent = 0;
> +DPRINTF("Unmodifed page or overflow skipping\n");
> +goto done;
> +} else if (encoded_len == -1) {
> +bytes_sent = -1;
> +DPRINTF("Overflow\n");
> +/* update data in the cache */
> +memcpy(prev_cached_page, current_data, TARGET_PAGE_SIZE);
> +goto done;
> +}
> +
> +/* we need to update the data in the cache, in order to get the same data
> + we cached we decode the encoded page on the cached data */
> +ret = xbzrle_decode_buffer(XBZRLE.encoded_buf, encoded_len,
> + prev_cached_page, TARGET_PAGE_SIZE);
> +g_assert(ret != -1);
> +
> +hdr.xh_len = encoded_len;
> +hdr.xh_flags |= ENCODING_FLAG_XBZRLE;
> +
> +/* Send XBZRLE based compressed page */
> +save_block_hdr(f, block, offset, cont, RAM_SAVE_FLAG_XBZRLE);
> +qemu_put_byte(f, hdr.xh_flags);
> +qemu_put_be16(f, hdr.xh_len);
> +qemu_put_be32(f, hdr.xh_cksum);
> +qemu_put_buffer(f, XBZRLE.encoded_buf, encoded_len);
> +bytes_sent = encoded_len + sizeof(hdr);
> +
> +done:
> +return bytes_sent;
> +}
> +
> static RAMBlock *last_block;
> static ram_addr_t last_offset;
>
> -static int ram_save_block(QEMUFile *f)
> +static int ram_save_block(QEMUFile *f, int stage)
> {
> RAMBlock *block = last_block;
> ram_addr_t offset = last_offset;
> -int bytes_sent = 0;
> +int bytes_sent = -1;
> MemoryRegion *mr;
> +ram_addr_t current_addr;
>
> if (!block)
> block = QLIST_FIRST(&ram_list.blocks);
>
> +current_addr = block->offset + offset;
> +
> do {
> mr = block->mr;
> if (memory_region_get_dirty(mr, offset, TARGET_PAGE_SIZE,
> @@ -198,7 +283,24 @@
Re: [Qemu-devel] arm return
On Fri, Jun 1, 2012 at 3:16 PM, Davide Ferraretto
wrote:
> In arm user mode, where does qemu exit? Where is last qemu's instruction?
>
> I.E.
> int main (){return 0;}
> in what file does qemu run "return 0"??
Simulated code reaches the point where libc calls 'exit' or 'exit_group' syscall
and then QEMU goes to the do_syscall in the linux-user/syscall.c to terminate
the process.
--
Thanks.
-- Max
Re: [Qemu-devel] Can we improve virtio data structures with QOM?
Anthony Liguori writes: > On 06/01/2012 05:25 PM, Markus Armbruster wrote: >> Anthony Liguori writes: >> >>> On 06/01/2012 12:48 AM, Markus Armbruster wrote: Anthony Liguori writes: [On how to model virtio devices in QOM:] > Basically, it should look like: > > VirtioPCIDevice is-a PCIDevice > > VirtioPCIDevice has-a link Could you explain why this is link<> and not child<>? >>> >>> So you can do: >>> >>> qemu -device virtio-pci,id=foo,vdev=bar -device virtio-blk,id=bar,bus=foo >> >> This lets folks specify both directions of the virtio-pci<-> virtio-blk >> connection independently. What if $dev->bus->vdev != $dev, i.e. the >> backlink doesn't point back? > > Then the user did something silly. > > If you're really asking, should we expect a user to use a command line > like this? Absolutely not! > > A user should use something like -drive file=foo.img,if=virtio No, a user should use what solves his problem nicely. Most of the time, the problem is simple. I quite agree we should provide simple ways to solve the known simple problems. Occasionally, you run into a non-simple problem, and then you'll really appreciate a discoverable bridge from the simple way to the general way. You'll also appreciate when the general way still satisfies basic usability criteria. A mandatory parameter that must have the one right value, or else things break, doesn't satisfy. "Experts/tools only" is no excuse for shoddy interfaces. -drive isn't such a good example for "simple"; it's a bloody mess, in my opinion. > Heck, I still think we should do -vda foo.img. > >> Easiest way to avoid that is to deny access to the backlink, and set it >> automatically instead. Wouldn't be surprised if such bi-directional >> links turned out to be a pretty common pattern. > > Most likely they will. But I don't think users should be setting any > links in the first place. Real tools aren't built around ideas on what users shouldn't be doing with them. >> In qdev, we've always called the property naming the parent "bus", >> because it's always been a qbus. Doesn't make sense here: the property >> refers to a device, not a bus. Should we call it something else? > > Actually, in qdev it's called parent_bus. Still got that bogus "bus" in there :) >>> The alternative would be: >>> >>> qemu -device virtio-pci,id=foo,child_type=virtio-blk >>> >>> But that feels ugly to me. If you want to have a variable type of >>> device, a link is the right tool. >> >> Okay, that's a general rule (I was hoping you'd state one). Do we have >> a place for such rules, or do we expect people to learn them by osmosis? > > I actually just did a tutorial session out here walking through how to > write device emulation from scratch. I would thinking of making a QOM > Style Guide based on that. That should be really useful. > I'm pretty short on free time for the next > week but I'll try to queue it up. If anyone wants to take a first > pass, I'd happily review it and contribute. > >>> BTW, I make no mention of BusState here. That's intentional. There's >>> no need to involve buses IMHO. >> >> I never liked qbus anyway. > > qbus never liked any of us too FWIW. It was a real jerk that way. Heh.
[Qemu-devel] arm return
I tried to insert " printf("exit\n"); ", but qemu dosen't write to monitor.
On 06/01/12 13:43, Max Filippov wrote:
On Fri, Jun 1, 2012 at 3:16 PM, Davide Ferraretto
wrote:
In arm user mode, where does qemu exit? Where is last qemu's instruction?
I.E.
int main (){return 0;}
in what file does qemu run "return 0"??
Simulated code reaches the point where libc calls 'exit' or 'exit_group' syscall
and then QEMU goes to the do_syscall in the linux-user/syscall.c to terminate
the process.
Re: [Qemu-devel] arm return
On Fri, Jun 1, 2012 at 3:57 PM, Davide Ferraretto
wrote:
> I tried to insert " printf("exit\n"); ", but qemu dosen't write to monitor.
printf should not write to monitor (if you mean QEMU monitor), it
should go to stdout.
I don't have ARM compiler set up ATM, but x86_64 with the following
patch does what I describe:
$ git diff
diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index 20d2a74..ccb71dc 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -5052,6 +5052,7 @@ abi_long do_syscall(void *cpu_env, int num, abi_long arg1,
switch(num) {
case TARGET_NR_exit:
+fprintf(stderr, "TARGET_NR_exit\n");
#ifdef CONFIG_USE_NPTL
/* In old applications this may be used to implement _exit(2).
However in threaded applictions it is used for thread termination,
@@ -6833,6 +6834,7 @@ abi_long do_syscall(void *cpu_env, int num, abi_long arg1,
#ifdef __NR_exit_group
/* new thread calls */
case TARGET_NR_exit_group:
+fprintf(stderr, "TARGET_NR_exit_group\n");
#ifdef TARGET_GPROF
_mcleanup();
#endif
$ cat a.c
#include
int main()
{
printf("Hello, world\n");
return 0;
}
$ gcc -static a.c -o a
$ qemu-all/root/bin/qemu-x86_64 ./a
Hello, world
TARGET_NR_exit_group
> On 06/01/12 13:43, Max Filippov wrote:
>>
>> On Fri, Jun 1, 2012 at 3:16 PM, Davide Ferraretto
>> wrote:
>>>
>>> In arm user mode, where does qemu exit? Where is last qemu's instruction?
>>>
>>> I.E.
>>> int main (){return 0;}
>>> in what file does qemu run "return 0"??
>>
>> Simulated code reaches the point where libc calls 'exit' or 'exit_group'
>> syscall
>> and then QEMU goes to the do_syscall in the linux-user/syscall.c to
>> terminate
>> the process.
>>
>
--
Thanks.
-- Max
Re: [Qemu-devel] arm return
I'm in "arm user space" with "sigle step mode". I want write "exit\n" in
linux shell (no QEMU monitor) when emulate code arrives to "return 0"
On 06/01/12 14:23, Max Filippov wrote:
On Fri, Jun 1, 2012 at 3:57 PM, Davide Ferraretto
wrote:
I tried to insert " printf("exit\n"); ", but qemu dosen't write to monitor.
printf should not write to monitor (if you mean QEMU monitor), it
should go to stdout.
I don't have ARM compiler set up ATM, but x86_64 with the following
patch does what I describe:
$ git diff
diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index 20d2a74..ccb71dc 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -5052,6 +5052,7 @@ abi_long do_syscall(void *cpu_env, int num, abi_long arg1,
switch(num) {
case TARGET_NR_exit:
+fprintf(stderr, "TARGET_NR_exit\n");
#ifdef CONFIG_USE_NPTL
/* In old applications this may be used to implement _exit(2).
However in threaded applictions it is used for thread termination,
@@ -6833,6 +6834,7 @@ abi_long do_syscall(void *cpu_env, int num, abi_long arg1,
#ifdef __NR_exit_group
/* new thread calls */
case TARGET_NR_exit_group:
+fprintf(stderr, "TARGET_NR_exit_group\n");
#ifdef TARGET_GPROF
_mcleanup();
#endif
$ cat a.c
#include
int main()
{
printf("Hello, world\n");
return 0;
}
$ gcc -static a.c -o a
$ qemu-all/root/bin/qemu-x86_64 ./a
Hello, world
TARGET_NR_exit_group
On 06/01/12 13:43, Max Filippov wrote:
On Fri, Jun 1, 2012 at 3:16 PM, Davide Ferraretto
wrote:
In arm user mode, where does qemu exit? Where is last qemu's instruction?
I.E.
int main (){return 0;}
in what file does qemu run "return 0"??
Simulated code reaches the point where libc calls 'exit' or 'exit_group'
syscall
and then QEMU goes to the do_syscall in the linux-user/syscall.c to
terminate
the process.
Re: [Qemu-devel] [PATCH 02/14] qerror: add new errors
Am 31.05.2012 18:08, schrieb Luiz Capitulino:
> On Thu, 31 May 2012 17:49:42 +0200
> Paolo Bonzini wrote:
>
>> Il 31/05/2012 17:44, Luiz Capitulino ha scritto:
One is "do not shoehorn errors into errno values". So for QOM invalid
values we
have PropertyValueBad, not a generic InvalidArgument value. We convert
everything
to Error rather than returning negative errno values and then returning
generic
error codes, because those would be ugly and non-descriptive. I agree
with that.
The other is "when errors come straight from the OS, _do_ use errno
values".
This is for OpenFileFailed, for the new socket errors and so on. This is
what
I am proposing.
These two rules together match what most other programs do.
$ echo | sed p > /dev/full
sed: couldn't flush stdout: No space left on device
^^ error type
^^ ^^^ arguments
That would become, in JSON:
{ 'error': 'FlushFailed',
'file': 'stdout',
'os_error': 'enospc' }
>>>
>>> Actually, I did propose something similar in the past but Anthony objected.
>>
>> Looks like in the meanwhile we moved closer to this mechanism
>> (OpenFileFailed, Sock*, etc.), except we have no clear way to identify
>> _what_ error actually happened rather than _where_.
>
> In fact, it's the other way around. OpenFileFailed, for example, is an old
> error. We thought it would be ok to have it that way (also because of shallow
> QMP conversion, as it would take ages to convert all possible errors). But
> today
> it's clear it's bad and we're trying to move away from it.
It's not all that clear for me. Or actually, it is rather clear that
it's basically the right thing, but some additional information is required.
> The socket ones repeat this, but it's probably because people usually go
> for the generic error first because having detailed errors with qerror is
> cumbersome. I have some ideas to improve it that could _mitigate_ that
> problem,
> like having a schema file qapi-errors.json:
>
> { 'error': 'InvalidParameter', 'data': { 'name': 'str' } }
Errors that are as simple as that are useless if they are all you get.
Even for InvalidParameter this is true when you have more than a flat
arguments dict.
Maybe what is required in order to fully describe an error is a whole
chain of error objects that describe which error caused which other
action to fail:
{ 'error': 'TransactionCommandFailed', 'data': {
'command': 'blockdev-snapshot-sync',
'cause': {
'error': 'FileOpenFailed', 'data' : {
'filename': '/tmp/foo.img',
'cause': {
'error': 'PermissionDenied', 'data': {}
}
}
}
}
Not sure if that would be easy to process for a QMP client, though...
Kevin
[Qemu-devel] [Bug 1007269] Re: Can’t install or boot up 32bit win8 guest.
I use Virtualbox latest and same problem. Try 64 edition Windows... -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1007269 Title: Can’t install or boot up 32bit win8 guest. Status in QEMU: New Bug description: Environment: Host OS (ia32/ia32e/IA64):ia32e Guest OS (ia32/ia32e/IA64):ia32e Guest OS Type (Linux/Windows):Linux(rhel6u1) kvm.git Commit:51bfd2998113e1f8ce8dcf853407b76a04b5f2a0 qemu-kvm Commit:3fd9fedb9fae4517d93d76e93a2924559cacf2f6 Host Kernel Version:3.4.0-rc7 Hardware:WSM-EP,Romley-EP Bug detailed description: -- it can't install or boot up 32bit Win8(Consumer Preview Update 2) guest. The guest will crash with the following error, while 64bit Win8 and 32bit Win7 guest work fine. -Win8 Error--- Your computer needs to restart. Please hold down the power button. Error code: 0x005D Parameters: 0x03060D03 0x756E6547 0x49656E69 0x6C65746E -Win8 Error--- "0x005D" code means "UNSUPPORTED_PROCESSOR" in Windows. BTW, you can get 32bit Win8 ISO from the following website. http://windows.microsoft.com/en-US/windows-8/iso Reproduce steps: 1. get 32 bit win8 ISO 2. prepare a disk image: dd if=/dev/zero of=/root/win8-32.img bs=1M count=16384 3. start a guest to install 32bit win8: qemu-system –m 4096 –smp 4 –hda /root/win8-32.img –cdrom /media/32bit-Win8.iso 4. if you have a 32bit win8 image,try to boot it up Current result: 32bit Win8 guest crash Expected result: 32bit win8 guest boot up correctly To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1007269/+subscriptions
Re: [Qemu-devel] arm return
On Fri, Jun 1, 2012 at 4:30 PM, Davide Ferraretto wrote: > I'm in "arm user space" with "sigle step mode". I want write "exit\n" in > linux shell (no QEMU monitor) when emulate code arrives to "return 0" Ok, what do you execute and where? Is it qemu-arm or qemu-system-arm? In the latter case do you use -semihosting? What is "ARM user space"? How is it all related to single step mode? Which linux shell do you mean, guest or host? Please, don't top-post. -- Thanks. -- Max
Re: [Qemu-devel] [PATCH 1/2] pci: Add pci_device_get_host_irq
On 2012-05-30 22:31, Michael S. Tsirkin wrote: >>> So we'll just have PIIX_NUM_PIC_IRQS entries there and use >>> irq_count instead of the pic_levels bitmap. >> >> Just that this affects generic PCI code, not only PIIX-specific things. > > Yes but it's not a problem - pci_bus_irqs sets the map function and nirqs. > >> And that we need to save/restore some irq_count field according to the >> old semantics. > > Well, it's a bug: this is redundant info we should not have exposed it. > > Anyway, let's make the rest work properly and cleanly first, add a FIXME > for now, then we'll find a hack making it work for migration. It remains non-trivial: I got your patch working (a minor init issue), but yet without changing the number of IRQs for PIIX3, so keeping the irq_count semantics for this host bridge. Now I'm facing three possibilities of how to proceed: 1. Give up on the (currently broken) feature to write a vmstate for older QEMU versions. This will allow to declare the irq_count field in vmstate_pcibus unused, and we would have to restore it on vmload step-wise via the PCI devices. It would also allow to change its semantics for PIIX3, mapping directly to PIC IRQs. 2. Keep writing a legacy irq_count field. This will require quite a few new APIs so that host bridges that want to change their nirq can still generate a compatible irq_count vmstate field. Namely: - A function to set up vmstate_irq_count and define a callback that the core will invoke to prepare the vmstate_irq_count before vmsave. - A function to obtain the IRQ mapping /without/ the final host bridge step. This is required so that the callback above can calculate the old state like in the PIIX3 case. 3. Keep irq_count and nirq as is, introduce additional map_host_irq. This is simpler than 2 and more compatible than 1. It would also allow to introduce the polarity and masking information more smoothly as we won't have to add it to existing map_irq callbacks then. Any other suggestions? Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
Re: [Qemu-devel] [PATCH qom-next] qom: make object cast assert if NULL object is passed as argument
Am 01.06.2012 13:18, schrieb Markus Armbruster: > Andreas Färber writes: > >> Am 31.05.2012 13:17, schrieb Igor Mammedov: >>> On 05/31/2012 12:16 PM, Paolo Bonzini wrote: Il 31/05/2012 10:30, Markus Armbruster ha scritto: >>> Makes much sense, but maybe it should be done in OBJECT() cast? Assert >>> when we do OBJECT(NULL). > In my opinion, OBJECT(p) where p is a null pointer is perfectly valid > and should yield a null pointer. Perhaps object_dynamic_cast and object_dynamic_cast_assert should do the same? >>> >>> or better object_dynamic_cast should return NULL if obj is NULL, >>> after all it's expected that it may return NULL >> >> That's what I was suggesting: I think that we should define "NULL is not >> of type TYPE_FOO" and thus have the ..._is_... functions return false, >> and have the ..._cast_assert assert. > > Is it? See http://www.mail-archive.com/qemu-devel@nongnu.org/msg113922.html > Igor: object_dynamic_cast should return NULL if obj is NULL, > > You: have the ..._cast_assert assert [on null argument, I presume] > > Doesn't sound like the same suggestion to me :) I'll let you to your opinion. :) However, my opinion is that object_dynamic_cast_assert() should assert (its name should be program), not segfault, and that object_dynamic_cast()/object_is_type()/type_is_ancestor() should not assert but return false / NULL. So as to the effects and usability that pretty much aligns with Igor M., no? > If I understood you correctly: what do such assertions buy us other than > silliness like > > p ? some_cast(p) : NULL > > ? Nack. The point is that currently deployed MY_TYPE(x) should assert (because nobody expects it to return NULL) and he who does want to handle NULL can use object_dynamic_cast(p). There's no real change to what we have except that an error case that was unhandled now is handled. >> So I still think this patch is correct. It could be accompanied by >> further patches adding error handling in the remaining functions. > > I'm not convinced. Shed any light? 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] arm return
On Fri, Jun 1, 2012 at 5:01 PM, Davide Ferraretto wrote: > I run qemu-arm -singlestep prog > > Linux shell --> host. Ok, and you build 'prog' as a static linux ELF for ARM? What does qemu-arm -strace prog print? -- Thanks. -- Max
Re: [Qemu-devel] arm return
On Fri, Jun 1, 2012 at 5:14 PM, Davide Ferraretto wrote: > I compile so: > arm-elf-gcc-4.0.2 prog -o prog As its name suggests, arm-elf-gcc builds bare-metal ELF that wouldn't run on linux, doesn't it? And what about the other question, what does qemu-arm -strace prog print? -- Thanks. -- Max
Re: [Qemu-devel] [PATCH 1/2] pci: Add pci_device_get_host_irq
On Fri, Jun 01, 2012 at 02:52:56PM +0200, Jan Kiszka wrote: > On 2012-05-30 22:31, Michael S. Tsirkin wrote: > >>> So we'll just have PIIX_NUM_PIC_IRQS entries there and use > >>> irq_count instead of the pic_levels bitmap. > >> > >> Just that this affects generic PCI code, not only PIIX-specific things. > > > > Yes but it's not a problem - pci_bus_irqs sets the map function and nirqs. > > > >> And that we need to save/restore some irq_count field according to the > >> old semantics. > > > > Well, it's a bug: this is redundant info we should not have exposed it. > > > > Anyway, let's make the rest work properly and cleanly first, add a FIXME > > for now, then we'll find a hack making it work for migration. > > It remains non-trivial: I got your patch working (a minor init issue), > but yet without changing the number of IRQs for PIIX3, so keeping the > irq_count semantics for this host bridge. > > Now I'm facing three possibilities of how to proceed: They all look OK I think :) Some comments below. > 1. Give up on the (currently broken) feature to write a vmstate for >older QEMU versions. > >This will allow to declare the irq_count field in vmstate_pcibus >unused, and we would have to restore it on vmload step-wise via the >PCI devices. It would also allow to change its semantics for PIIX3, >mapping directly to PIC IRQs. I think that's okay too simply because these things are usually easy to fix after the fact when the rest of the issues are addressed. > 2. Keep writing a legacy irq_count field. > >This will require quite a few new APIs so that host bridges that >want to change their nirq can still generate a compatible irq_count >vmstate field. Namely: > - A function to set up vmstate_irq_count and define a callback that > the core will invoke to prepare the vmstate_irq_count before > vmsave. > - A function to obtain the IRQ mapping /without/ the final host > bridge step. This is required so that the callback above can > calculate the old state like in the PIIX3 case. Does this really need to be so complex? It seems that we just need pci_get_irq_count(bus, irq) which can use the existing map_irq API, no? Then invoke that before save. > 3. Keep irq_count and nirq as is, introduce additional map_host_irq. > >This is simpler than 2 and more compatible than 1. It would also >allow to introduce the polarity and masking information more >smoothly as we won't have to add it to existing map_irq callbacks >then. So what does it map, and to what? Maybe we can make the name imply that somehow. > Any other suggestions? > > Jan > -- > Siemens AG, Corporate Technology, CT T DE IT 1 > Corporate Competence Center Embedded Linux
Re: [Qemu-devel] [PATCH 1/2] pci: Add pci_device_get_host_irq
On Fri, Jun 01, 2012 at 02:52:56PM +0200, Jan Kiszka wrote: > On 2012-05-30 22:31, Michael S. Tsirkin wrote: > >>> So we'll just have PIIX_NUM_PIC_IRQS entries there and use > >>> irq_count instead of the pic_levels bitmap. > >> > >> Just that this affects generic PCI code, not only PIIX-specific things. > > > > Yes but it's not a problem - pci_bus_irqs sets the map function and nirqs. > > > >> And that we need to save/restore some irq_count field according to the > >> old semantics. > > > > Well, it's a bug: this is redundant info we should not have exposed it. > > > > Anyway, let's make the rest work properly and cleanly first, add a FIXME > > for now, then we'll find a hack making it work for migration. > > It remains non-trivial: I got your patch working (a minor init issue), > but yet without changing the number of IRQs for PIIX3, so keeping the > irq_count semantics for this host bridge. BTW can you post the fixed version please in case others want to play with it?
Re: [Qemu-devel] [PATCH 1/2] pci: Add pci_device_get_host_irq
On 2012-06-01 15:28, Michael S. Tsirkin wrote: > On Fri, Jun 01, 2012 at 02:52:56PM +0200, Jan Kiszka wrote: >> On 2012-05-30 22:31, Michael S. Tsirkin wrote: > So we'll just have PIIX_NUM_PIC_IRQS entries there and use > irq_count instead of the pic_levels bitmap. Just that this affects generic PCI code, not only PIIX-specific things. >>> >>> Yes but it's not a problem - pci_bus_irqs sets the map function and nirqs. >>> And that we need to save/restore some irq_count field according to the old semantics. >>> >>> Well, it's a bug: this is redundant info we should not have exposed it. >>> >>> Anyway, let's make the rest work properly and cleanly first, add a FIXME >>> for now, then we'll find a hack making it work for migration. >> >> It remains non-trivial: I got your patch working (a minor init issue), >> but yet without changing the number of IRQs for PIIX3, so keeping the >> irq_count semantics for this host bridge. > > BTW can you post the fixed version please in case > others want to play with it? Pushed a snapshot to git://git.kiszka.org/qemu.git queues/pci. That version survived simple tests. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
Re: [Qemu-devel] [PATCH v4] target-microblaze: lwx/swx: first implementation
Am 01.06.2012 05:23, schrieb Peter A. G. Crosthwaite: > Signed-off-by: Peter A. G. Crosthwaite > --- > changed from v3: > simplified tcg local variable usage aqcross branch > changed from v2: > fixed tcg local variable usage across branch > reworked carry logic (with new write_carryi() function) > made LOG_DIS show lwx swx properly > changed from v1: > implemented reservation address checking > created new cpu state variable specifically for reservation address/flag state > > target-microblaze/cpu.c |1 + > target-microblaze/cpu.h |4 ++ > target-microblaze/helper.c|2 + > target-microblaze/translate.c | 62 +--- > 4 files changed, 64 insertions(+), 5 deletions(-) > > diff --git a/target-microblaze/cpu.c b/target-microblaze/cpu.c > index 9c3b74e..34b3a9b 100644 > --- a/target-microblaze/cpu.c > +++ b/target-microblaze/cpu.c > @@ -39,6 +39,7 @@ static void mb_cpu_reset(CPUState *s) > mcc->parent_reset(s); > > memset(env, 0, offsetof(CPUMBState, breakpoints)); > +env->res_addr = RES_ADDR_NONE; > tlb_flush(env, 1); > > /* Disable stack protector. */ Note that my idea for structuring mb_cpu_reset() was to group the "duplicated common" functionality there that would get moved into the base class' reset function once no longer dependent on "env". Not a blocker for this patch but if you have to send a v2 anyway. 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 1/2] pci: Add pci_device_get_host_irq
On 2012-06-01 15:27, Michael S. Tsirkin wrote: > On Fri, Jun 01, 2012 at 02:52:56PM +0200, Jan Kiszka wrote: >> On 2012-05-30 22:31, Michael S. Tsirkin wrote: > So we'll just have PIIX_NUM_PIC_IRQS entries there and use > irq_count instead of the pic_levels bitmap. Just that this affects generic PCI code, not only PIIX-specific things. >>> >>> Yes but it's not a problem - pci_bus_irqs sets the map function and nirqs. >>> And that we need to save/restore some irq_count field according to the old semantics. >>> >>> Well, it's a bug: this is redundant info we should not have exposed it. >>> >>> Anyway, let's make the rest work properly and cleanly first, add a FIXME >>> for now, then we'll find a hack making it work for migration. >> >> It remains non-trivial: I got your patch working (a minor init issue), >> but yet without changing the number of IRQs for PIIX3, so keeping the >> irq_count semantics for this host bridge. >> >> Now I'm facing three possibilities of how to proceed: > > They all look OK I think :) Some comments below. > >> 1. Give up on the (currently broken) feature to write a vmstate for >>older QEMU versions. >> >>This will allow to declare the irq_count field in vmstate_pcibus >>unused, and we would have to restore it on vmload step-wise via the >>PCI devices. It would also allow to change its semantics for PIIX3, >>mapping directly to PIC IRQs. > > I think that's okay too simply because these things are usually > easy to fix after the fact when the rest of the issues are addressed. Don't get what you mean with "fixed". If we fix the vmstate generation in making it backward-compatible again, we enter option 2. Option 1 is explicitly about giving this up. > >> 2. Keep writing a legacy irq_count field. >> >>This will require quite a few new APIs so that host bridges that >>want to change their nirq can still generate a compatible irq_count >>vmstate field. Namely: >> - A function to set up vmstate_irq_count and define a callback that >> the core will invoke to prepare the vmstate_irq_count before >> vmsave. >> - A function to obtain the IRQ mapping /without/ the final host >> bridge step. This is required so that the callback above can >> calculate the old state like in the PIIX3 case. > > Does this really need to be so complex? It seems that we just need > pci_get_irq_count(bus, irq) which can use the existing map_irq API, no? > Then invoke that before save. No, because the new map_irq of the PIIX3 bridge will also include the host bridge routing (or masking) according to the PIRQx routoing registers of the PIIX3. Moreover, the fixup of the written legacy irq_count state has to happen in the PCI layer, which therefore has to query the host bridge for fixup information, not the other way around (because the PCI bus vmstate is separate from the PIIX3 host bridge). > >> 3. Keep irq_count and nirq as is, introduce additional map_host_irq. >> >>This is simpler than 2 and more compatible than 1. It would also >>allow to introduce the polarity and masking information more >>smoothly as we won't have to add it to existing map_irq callbacks >>then. > > So what does it map, and to what? PCI bus IRQ to *host* IRQ. It is supposed to explore the routing of the host bridge between the root bus and the host's interrupt controller (i.e. the step that is currently missing the cached chain). > Maybe we can make the name imply that somehow. Better suggestions for this handler and maybe also the existing map_irq are welcome to make the difference clearer. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
Re: [Qemu-devel] [PATCH 0/6] prep: some fixes and Super I/O emulation
On 3/17/12, Hervé Poussineau wrote: > First two patches repair some functionality broken since 2009! > Debian install root floppy can now be started again. Can you give the qemu command line for this? > Patches 4 to 6 implement the pc87312 Super I/O chip. > Some versions by me or by Andreas Färber have already been sent on > mailing list. This patch has been tested on PReP emulation and on > IBM 40p (not yet committed). > > Hervé Poussineau (6): > i82378/i82374: do not create DMA controller twice > prep: change default cpu to '7448' > isa: add isa_bus_from_device() method > fdc: Parametrize ISA base, IRQ and DMA > prep: add pc87312 Super I/O emulation > prep: use pc87312 Super I/O chip instead of collection of random ISA > devices -- Regards, Artyom Tarasenko solaris/sparc under qemu blog: http://tyom.blogspot.com/search/label/qemu
Re: [Qemu-devel] [PATCH 1/2] pci: Add pci_device_get_host_irq
On Fri, Jun 01, 2012 at 03:57:01PM +0200, Jan Kiszka wrote: > On 2012-06-01 15:27, Michael S. Tsirkin wrote: > > On Fri, Jun 01, 2012 at 02:52:56PM +0200, Jan Kiszka wrote: > >> On 2012-05-30 22:31, Michael S. Tsirkin wrote: > > So we'll just have PIIX_NUM_PIC_IRQS entries there and use > > irq_count instead of the pic_levels bitmap. > > Just that this affects generic PCI code, not only PIIX-specific things. > >>> > >>> Yes but it's not a problem - pci_bus_irqs sets the map function and nirqs. > >>> > And that we need to save/restore some irq_count field according to the > old semantics. > >>> > >>> Well, it's a bug: this is redundant info we should not have exposed it. > >>> > >>> Anyway, let's make the rest work properly and cleanly first, add a FIXME > >>> for now, then we'll find a hack making it work for migration. > >> > >> It remains non-trivial: I got your patch working (a minor init issue), > >> but yet without changing the number of IRQs for PIIX3, so keeping the > >> irq_count semantics for this host bridge. > >> > >> Now I'm facing three possibilities of how to proceed: > > > > They all look OK I think :) Some comments below. > > > >> 1. Give up on the (currently broken) feature to write a vmstate for > >>older QEMU versions. > >> > >>This will allow to declare the irq_count field in vmstate_pcibus > >>unused, and we would have to restore it on vmload step-wise via the > >>PCI devices. It would also allow to change its semantics for PIIX3, > >>mapping directly to PIC IRQs. > > > > I think that's okay too simply because these things are usually > > easy to fix after the fact when the rest of the issues are addressed. > > Don't get what you mean with "fixed". If we fix the vmstate generation > in making it backward-compatible again, we enter option 2. Option 1 is > explicitly about giving this up. What I really mean is I think I see how 2 can be added without much pain. So let's focus on 1 for now and worst case we break migration. > > > >> 2. Keep writing a legacy irq_count field. > >> > >>This will require quite a few new APIs so that host bridges that > >>want to change their nirq can still generate a compatible irq_count > >>vmstate field. Namely: > >> - A function to set up vmstate_irq_count and define a callback that > >> the core will invoke to prepare the vmstate_irq_count before > >> vmsave. > >> - A function to obtain the IRQ mapping /without/ the final host > >> bridge step. This is required so that the callback above can > >> calculate the old state like in the PIIX3 case. > > > > Does this really need to be so complex? It seems that we just need > > pci_get_irq_count(bus, irq) which can use the existing map_irq API, no? > > Then invoke that before save. > > No, because the new map_irq of the PIIX3 bridge will also include the > host bridge routing (or masking) according to the PIRQx routoing > registers of the PIIX3. Moreover, the fixup of the written legacy > irq_count state has to happen in the PCI layer, which therefore has to > query the host bridge for fixup information, not the other way around > (because the PCI bus vmstate is separate from the PIIX3 host bridge). > > > > >> 3. Keep irq_count and nirq as is, introduce additional map_host_irq. > >> > >>This is simpler than 2 and more compatible than 1. It would also > >>allow to introduce the polarity and masking information more > >>smoothly as we won't have to add it to existing map_irq callbacks > >>then. > > > > So what does it map, and to what? > > PCI bus IRQ to *host* IRQ. It is supposed to explore the routing of the > host bridge between the root bus and the host's interrupt controller > (i.e. the step that is currently missing the cached chain). > > > Maybe we can make the name imply that somehow. > > Better suggestions for this handler and maybe also the existing map_irq > are welcome to make the difference clearer. > > Jan So I won't object to adding a new API but if we do it properly this won't help compatibility :( Let's formulate what these do exactly, this will also help us come up with sensible names. 1. The difference is that pci bridges route interrupt pins. So it gets interrupt pin on device and returns interrupt pin on connector. All attributes are standard PCI. We should remove all mentions of "irq" really. 2. The pci root (yes it's a host bridge but let's not use the term host if we can) routes an interrupt pin on device to a host irq. It can also do more things like invert polarity. So yes we can add 2 to piix but we really should remove 1 from it. Wrt names - do you object to long names? How about route_interrupt_pin for 1 and route_interrupt_pin_to_irq for 2? > -- > Siemens AG, Corporate Technology, CT T DE IT 1 > Corporate Competence Center Embedded Linux
Re: [Qemu-devel] [PATCH 1/2] pci: Add pci_device_get_host_irq
On 2012-06-01 16:34, Michael S. Tsirkin wrote: > On Fri, Jun 01, 2012 at 03:57:01PM +0200, Jan Kiszka wrote: >> On 2012-06-01 15:27, Michael S. Tsirkin wrote: >>> On Fri, Jun 01, 2012 at 02:52:56PM +0200, Jan Kiszka wrote: On 2012-05-30 22:31, Michael S. Tsirkin wrote: >>> So we'll just have PIIX_NUM_PIC_IRQS entries there and use >>> irq_count instead of the pic_levels bitmap. >> >> Just that this affects generic PCI code, not only PIIX-specific things. > > Yes but it's not a problem - pci_bus_irqs sets the map function and nirqs. > >> And that we need to save/restore some irq_count field according to the >> old semantics. > > Well, it's a bug: this is redundant info we should not have exposed it. > > Anyway, let's make the rest work properly and cleanly first, add a FIXME > for now, then we'll find a hack making it work for migration. It remains non-trivial: I got your patch working (a minor init issue), but yet without changing the number of IRQs for PIIX3, so keeping the irq_count semantics for this host bridge. Now I'm facing three possibilities of how to proceed: >>> >>> They all look OK I think :) Some comments below. >>> 1. Give up on the (currently broken) feature to write a vmstate for older QEMU versions. This will allow to declare the irq_count field in vmstate_pcibus unused, and we would have to restore it on vmload step-wise via the PCI devices. It would also allow to change its semantics for PIIX3, mapping directly to PIC IRQs. >>> >>> I think that's okay too simply because these things are usually >>> easy to fix after the fact when the rest of the issues are addressed. >> >> Don't get what you mean with "fixed". If we fix the vmstate generation >> in making it backward-compatible again, we enter option 2. Option 1 is >> explicitly about giving this up. > > What I really mean is I think I see how 2 can be added without much > pain. So let's focus on 1 for now and worst case we break migration. I'd like to avoid planing for this worst case as long as there are also statements [1] that this is not acceptable for QEMU in general. It doesn't to create a beautiful architecture initially about which we already know that it will become more complex than alternatives in the end. > >>> 2. Keep writing a legacy irq_count field. This will require quite a few new APIs so that host bridges that want to change their nirq can still generate a compatible irq_count vmstate field. Namely: - A function to set up vmstate_irq_count and define a callback that the core will invoke to prepare the vmstate_irq_count before vmsave. - A function to obtain the IRQ mapping /without/ the final host bridge step. This is required so that the callback above can calculate the old state like in the PIIX3 case. >>> >>> Does this really need to be so complex? It seems that we just need >>> pci_get_irq_count(bus, irq) which can use the existing map_irq API, no? >>> Then invoke that before save. >> >> No, because the new map_irq of the PIIX3 bridge will also include the >> host bridge routing (or masking) according to the PIRQx routoing >> registers of the PIIX3. Moreover, the fixup of the written legacy >> irq_count state has to happen in the PCI layer, which therefore has to >> query the host bridge for fixup information, not the other way around >> (because the PCI bus vmstate is separate from the PIIX3 host bridge). >> >>> 3. Keep irq_count and nirq as is, introduce additional map_host_irq. This is simpler than 2 and more compatible than 1. It would also allow to introduce the polarity and masking information more smoothly as we won't have to add it to existing map_irq callbacks then. >>> >>> So what does it map, and to what? >> >> PCI bus IRQ to *host* IRQ. It is supposed to explore the routing of the >> host bridge between the root bus and the host's interrupt controller >> (i.e. the step that is currently missing the cached chain). >> >>> Maybe we can make the name imply that somehow. >> >> Better suggestions for this handler and maybe also the existing map_irq >> are welcome to make the difference clearer. >> >> Jan > > So I won't object to adding a new API but if we do > it properly this won't help compatibility :( It will as this API does not touch the parts that affect the vmstate (ie. semantics of irq_count won't change). > > Let's formulate what these do exactly, this will > also help us come up with sensible names. > > 1. The difference is that pci bridges route interrupt pins. So it gets > interrupt pin on device and returns interrupt pin on connector. All > attributes are standard PCI. We should remove all mentions of "irq" > really. > > > 2. The pci root (yes it's a host bridge but let's > not use the term host if we can) route
Re: [Qemu-devel] [Qemu-ppc] [PATCH] e500-pci: Factor into distinct mpc8540 and p4080 PCI Hosts
Am 31.05.2012 01:25, schrieb Ben Collins: > In order to provide a closer virtualization, factor out e500-pci into seperate > PCI hosts, namely fsl,mpc8540-pci and fsl,p4080-pcie (to match the device-tree > node naming). > > Make use of the mpc8540 variant (basically a NOP) for ppce500_mpc8544 machine > type. The p4080-pcie variant can be used later for a P4080DS specific machine > description. > > The major differences between the two are the host-bridge PCI device ID and > the > difference in starting slot number. Eventually I'd like to get the p4080 > variant > to support any valid slot number, and actually move the bus behind the host > bridge as is done in the physical hardware. > > Signed-off-by: Ben Collins Please always cc qemu-devel on patches and the respective maintainers, here ppc and pci. Thanks, 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 1/2] pci: Add pci_device_get_host_irq
On Fri, Jun 01, 2012 at 05:15:42PM +0200, Jan Kiszka wrote: > On 2012-06-01 16:34, Michael S. Tsirkin wrote: > > On Fri, Jun 01, 2012 at 03:57:01PM +0200, Jan Kiszka wrote: > >> On 2012-06-01 15:27, Michael S. Tsirkin wrote: > >>> On Fri, Jun 01, 2012 at 02:52:56PM +0200, Jan Kiszka wrote: > On 2012-05-30 22:31, Michael S. Tsirkin wrote: > >>> So we'll just have PIIX_NUM_PIC_IRQS entries there and use > >>> irq_count instead of the pic_levels bitmap. > >> > >> Just that this affects generic PCI code, not only PIIX-specific things. > > > > Yes but it's not a problem - pci_bus_irqs sets the map function and > > nirqs. > > > >> And that we need to save/restore some irq_count field according to the > >> old semantics. > > > > Well, it's a bug: this is redundant info we should not have exposed it. > > > > Anyway, let's make the rest work properly and cleanly first, add a FIXME > > for now, then we'll find a hack making it work for migration. > > It remains non-trivial: I got your patch working (a minor init issue), > but yet without changing the number of IRQs for PIIX3, so keeping the > irq_count semantics for this host bridge. > > Now I'm facing three possibilities of how to proceed: > >>> > >>> They all look OK I think :) Some comments below. > >>> > 1. Give up on the (currently broken) feature to write a vmstate for > older QEMU versions. > > This will allow to declare the irq_count field in vmstate_pcibus > unused, and we would have to restore it on vmload step-wise via the > PCI devices. It would also allow to change its semantics for PIIX3, > mapping directly to PIC IRQs. > >>> > >>> I think that's okay too simply because these things are usually > >>> easy to fix after the fact when the rest of the issues are addressed. > >> > >> Don't get what you mean with "fixed". If we fix the vmstate generation > >> in making it backward-compatible again, we enter option 2. Option 1 is > >> explicitly about giving this up. > > > > What I really mean is I think I see how 2 can be added without much > > pain. So let's focus on 1 for now and worst case we break migration. > > I'd like to avoid planing for this worst case as long as there are also > statements [1] that this is not acceptable for QEMU in general. It > doesn't to create a beautiful architecture initially about which we > already know that it will become more complex than alternatives in the end. > > > > >>> > 2. Keep writing a legacy irq_count field. > > This will require quite a few new APIs so that host bridges that > want to change their nirq can still generate a compatible irq_count > vmstate field. Namely: > - A function to set up vmstate_irq_count and define a callback that > the core will invoke to prepare the vmstate_irq_count before > vmsave. > - A function to obtain the IRQ mapping /without/ the final host > bridge step. This is required so that the callback above can > calculate the old state like in the PIIX3 case. > >>> > >>> Does this really need to be so complex? It seems that we just need > >>> pci_get_irq_count(bus, irq) which can use the existing map_irq API, no? > >>> Then invoke that before save. > >> > >> No, because the new map_irq of the PIIX3 bridge will also include the > >> host bridge routing (or masking) according to the PIRQx routoing > >> registers of the PIIX3. Moreover, the fixup of the written legacy > >> irq_count state has to happen in the PCI layer, which therefore has to > >> query the host bridge for fixup information, not the other way around > >> (because the PCI bus vmstate is separate from the PIIX3 host bridge). > >> > >>> > 3. Keep irq_count and nirq as is, introduce additional map_host_irq. > > This is simpler than 2 and more compatible than 1. It would also > allow to introduce the polarity and masking information more > smoothly as we won't have to add it to existing map_irq callbacks > then. > >>> > >>> So what does it map, and to what? > >> > >> PCI bus IRQ to *host* IRQ. It is supposed to explore the routing of the > >> host bridge between the root bus and the host's interrupt controller > >> (i.e. the step that is currently missing the cached chain). > >> > >>> Maybe we can make the name imply that somehow. > >> > >> Better suggestions for this handler and maybe also the existing map_irq > >> are welcome to make the difference clearer. > >> > >> Jan > > > > So I won't object to adding a new API but if we do > > it properly this won't help compatibility :( > > It will as this API does not touch the parts that affect the vmstate > (ie. semantics of irq_count won't change). Yes but irq_count in vmstate is a bug. IMO even if we do not change anything we should ignore irq_count on load and recalculate it from what the devic
Re: [Qemu-devel] [PATCH 1/2] pci: Add pci_device_get_host_irq
On Fri, Jun 01, 2012 at 05:15:42PM +0200, Jan Kiszka wrote: > On 2012-06-01 16:34, Michael S. Tsirkin wrote: > > On Fri, Jun 01, 2012 at 03:57:01PM +0200, Jan Kiszka wrote: > >> On 2012-06-01 15:27, Michael S. Tsirkin wrote: > >>> On Fri, Jun 01, 2012 at 02:52:56PM +0200, Jan Kiszka wrote: > On 2012-05-30 22:31, Michael S. Tsirkin wrote: > >>> So we'll just have PIIX_NUM_PIC_IRQS entries there and use > >>> irq_count instead of the pic_levels bitmap. > >> > >> Just that this affects generic PCI code, not only PIIX-specific things. > > > > Yes but it's not a problem - pci_bus_irqs sets the map function and > > nirqs. > > > >> And that we need to save/restore some irq_count field according to the > >> old semantics. > > > > Well, it's a bug: this is redundant info we should not have exposed it. > > > > Anyway, let's make the rest work properly and cleanly first, add a FIXME > > for now, then we'll find a hack making it work for migration. > > It remains non-trivial: I got your patch working (a minor init issue), > but yet without changing the number of IRQs for PIIX3, so keeping the > irq_count semantics for this host bridge. > > Now I'm facing three possibilities of how to proceed: > >>> > >>> They all look OK I think :) Some comments below. > >>> > 1. Give up on the (currently broken) feature to write a vmstate for > older QEMU versions. > > This will allow to declare the irq_count field in vmstate_pcibus > unused, and we would have to restore it on vmload step-wise via the > PCI devices. It would also allow to change its semantics for PIIX3, > mapping directly to PIC IRQs. > >>> > >>> I think that's okay too simply because these things are usually > >>> easy to fix after the fact when the rest of the issues are addressed. > >> > >> Don't get what you mean with "fixed". If we fix the vmstate generation > >> in making it backward-compatible again, we enter option 2. Option 1 is > >> explicitly about giving this up. > > > > What I really mean is I think I see how 2 can be added without much > > pain. So let's focus on 1 for now and worst case we break migration. > > I'd like to avoid planing for this worst case as long as there are also > statements [1] that this is not acceptable for QEMU in general. It > doesn't to create a beautiful architecture initially about which we > already know that it will become more complex than alternatives in the end. 1 and 2 are same really except 2 adds a hack for compatibility, no?
Re: [Qemu-devel] [PATCH 1/2] pci: Add pci_device_get_host_irq
On 2012-06-01 17:28, Michael S. Tsirkin wrote: >>> So I won't object to adding a new API but if we do >>> it properly this won't help compatibility :( >> >> It will as this API does not touch the parts that affect the vmstate >> (ie. semantics of irq_count won't change). > > Yes but irq_count in vmstate is a bug. IMO even if we do > not change anything we should ignore irq_count on > load and recalculate it from what the devices supply. I don't disagree. But this will only allow keeping backward migration support if we preserve the semantics of current map_irq somewhere - to keep the chance of calculating the legacy values for vmsave as well. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
Re: [Qemu-devel] [PATCH 1/2] pci: Add pci_device_get_host_irq
On 2012-06-01 17:30, Michael S. Tsirkin wrote: > On Fri, Jun 01, 2012 at 05:15:42PM +0200, Jan Kiszka wrote: >> On 2012-06-01 16:34, Michael S. Tsirkin wrote: >>> On Fri, Jun 01, 2012 at 03:57:01PM +0200, Jan Kiszka wrote: On 2012-06-01 15:27, Michael S. Tsirkin wrote: > On Fri, Jun 01, 2012 at 02:52:56PM +0200, Jan Kiszka wrote: >> On 2012-05-30 22:31, Michael S. Tsirkin wrote: > So we'll just have PIIX_NUM_PIC_IRQS entries there and use > irq_count instead of the pic_levels bitmap. Just that this affects generic PCI code, not only PIIX-specific things. >>> >>> Yes but it's not a problem - pci_bus_irqs sets the map function and >>> nirqs. >>> And that we need to save/restore some irq_count field according to the old semantics. >>> >>> Well, it's a bug: this is redundant info we should not have exposed it. >>> >>> Anyway, let's make the rest work properly and cleanly first, add a FIXME >>> for now, then we'll find a hack making it work for migration. >> >> It remains non-trivial: I got your patch working (a minor init issue), >> but yet without changing the number of IRQs for PIIX3, so keeping the >> irq_count semantics for this host bridge. >> >> Now I'm facing three possibilities of how to proceed: > > They all look OK I think :) Some comments below. > >> 1. Give up on the (currently broken) feature to write a vmstate for >>older QEMU versions. >> >>This will allow to declare the irq_count field in vmstate_pcibus >>unused, and we would have to restore it on vmload step-wise via the >>PCI devices. It would also allow to change its semantics for PIIX3, >>mapping directly to PIC IRQs. > > I think that's okay too simply because these things are usually > easy to fix after the fact when the rest of the issues are addressed. Don't get what you mean with "fixed". If we fix the vmstate generation in making it backward-compatible again, we enter option 2. Option 1 is explicitly about giving this up. >>> >>> What I really mean is I think I see how 2 can be added without much >>> pain. So let's focus on 1 for now and worst case we break migration. >> >> I'd like to avoid planing for this worst case as long as there are also >> statements [1] that this is not acceptable for QEMU in general. It >> doesn't to create a beautiful architecture initially about which we >> already know that it will become more complex than alternatives in the end. > > 1 and 2 are same really except 2 adds a hack for compatibility, no? Yes, 2 would allow us to maintain irq_count in different ways as well, specifically using it calculate shared output IRQ lines before reporting them to the PIC generically. This approach has both a charming and an ugly face. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
Re: [Qemu-devel] [PATCH 1/2] pci: Add pci_device_get_host_irq
On Fri, Jun 01, 2012 at 05:54:15PM +0200, Jan Kiszka wrote: > On 2012-06-01 17:28, Michael S. Tsirkin wrote: > >>> So I won't object to adding a new API but if we do > >>> it properly this won't help compatibility :( > >> > >> It will as this API does not touch the parts that affect the vmstate > >> (ie. semantics of irq_count won't change). > > > > Yes but irq_count in vmstate is a bug. IMO even if we do > > not change anything we should ignore irq_count on > > load and recalculate it from what the devices supply. > > I don't disagree. But this will only allow keeping backward migration > support if we preserve the semantics of current map_irq somewhere - to > keep the chance of calculating the legacy values for vmsave as well. > > Jan We don't need to preserve it, right? We can calculate it before savevm. > -- > Siemens AG, Corporate Technology, CT T DE IT 1 > Corporate Competence Center Embedded Linux
Re: [Qemu-devel] [PATCH 1/2] pci: Add pci_device_get_host_irq
On Fri, Jun 01, 2012 at 05:34:14PM +0300, Michael S. Tsirkin wrote: > On Fri, Jun 01, 2012 at 03:57:01PM +0200, Jan Kiszka wrote: > > On 2012-06-01 15:27, Michael S. Tsirkin wrote: > > > On Fri, Jun 01, 2012 at 02:52:56PM +0200, Jan Kiszka wrote: > > >> On 2012-05-30 22:31, Michael S. Tsirkin wrote: > > > So we'll just have PIIX_NUM_PIC_IRQS entries there and use > > > irq_count instead of the pic_levels bitmap. > > > > Just that this affects generic PCI code, not only PIIX-specific things. > > >>> > > >>> Yes but it's not a problem - pci_bus_irqs sets the map function and > > >>> nirqs. > > >>> > > And that we need to save/restore some irq_count field according to the > > old semantics. > > >>> > > >>> Well, it's a bug: this is redundant info we should not have exposed it. > > >>> > > >>> Anyway, let's make the rest work properly and cleanly first, add a FIXME > > >>> for now, then we'll find a hack making it work for migration. > > >> > > >> It remains non-trivial: I got your patch working (a minor init issue), > > >> but yet without changing the number of IRQs for PIIX3, so keeping the > > >> irq_count semantics for this host bridge. > > >> > > >> Now I'm facing three possibilities of how to proceed: > > > > > > They all look OK I think :) Some comments below. > > > > > >> 1. Give up on the (currently broken) feature to write a vmstate for > > >>older QEMU versions. > > >> > > >>This will allow to declare the irq_count field in vmstate_pcibus > > >>unused, and we would have to restore it on vmload step-wise via the > > >>PCI devices. It would also allow to change its semantics for PIIX3, > > >>mapping directly to PIC IRQs. > > > > > > I think that's okay too simply because these things are usually > > > easy to fix after the fact when the rest of the issues are addressed. > > > > Don't get what you mean with "fixed". If we fix the vmstate generation > > in making it backward-compatible again, we enter option 2. Option 1 is > > explicitly about giving this up. > > What I really mean is I think I see how 2 can be added without much > pain. So let's focus on 1 for now and worst case we break migration. > > > > > > >> 2. Keep writing a legacy irq_count field. > > >> > > >>This will require quite a few new APIs so that host bridges that > > >>want to change their nirq can still generate a compatible irq_count > > >>vmstate field. Namely: > > >> - A function to set up vmstate_irq_count and define a callback that > > >> the core will invoke to prepare the vmstate_irq_count before > > >> vmsave. > > >> - A function to obtain the IRQ mapping /without/ the final host > > >> bridge step. This is required so that the callback above can > > >> calculate the old state like in the PIIX3 case. > > > > > > Does this really need to be so complex? It seems that we just need > > > pci_get_irq_count(bus, irq) which can use the existing map_irq API, no? > > > Then invoke that before save. > > > > No, because the new map_irq of the PIIX3 bridge will also include the > > host bridge routing (or masking) according to the PIRQx routoing > > registers of the PIIX3. Moreover, the fixup of the written legacy > > irq_count state has to happen in the PCI layer, which therefore has to > > query the host bridge for fixup information, not the other way around > > (because the PCI bus vmstate is separate from the PIIX3 host bridge). > > > > > > > >> 3. Keep irq_count and nirq as is, introduce additional map_host_irq. > > >> > > >>This is simpler than 2 and more compatible than 1. It would also > > >>allow to introduce the polarity and masking information more > > >>smoothly as we won't have to add it to existing map_irq callbacks > > >>then. > > > > > > So what does it map, and to what? > > > > PCI bus IRQ to *host* IRQ. It is supposed to explore the routing of the > > host bridge between the root bus and the host's interrupt controller > > (i.e. the step that is currently missing the cached chain). > > > > > Maybe we can make the name imply that somehow. > > > > Better suggestions for this handler and maybe also the existing map_irq > > are welcome to make the difference clearer. > > > > Jan > > So I won't object to adding a new API but if we do > it properly this won't help compatibility :( > > Let's formulate what these do exactly, this will > also help us come up with sensible names. > > 1. The difference is that pci bridges route interrupt pins. So it gets > interrupt pin on device and returns interrupt pin on connector. All > attributes are standard PCI. We should remove all mentions of "irq" > really. > > > 2. The pci root (yes it's a host bridge but let's > not use the term host if we can) routes > an interrupt pin on device to a host irq. It can also > do more things like invert polarity. > > So yes we can add 2 to piix but we really should > remove 1 from it. > > Wrt names - do you object to long
Re: [Qemu-devel] [PATCH 1/2] pci: Add pci_device_get_host_irq
On 2012-06-01 18:05, Michael S. Tsirkin wrote: > On Fri, Jun 01, 2012 at 05:54:15PM +0200, Jan Kiszka wrote: >> On 2012-06-01 17:28, Michael S. Tsirkin wrote: > So I won't object to adding a new API but if we do > it properly this won't help compatibility :( It will as this API does not touch the parts that affect the vmstate (ie. semantics of irq_count won't change). >>> >>> Yes but irq_count in vmstate is a bug. IMO even if we do >>> not change anything we should ignore irq_count on >>> load and recalculate it from what the devices supply. >> >> I don't disagree. But this will only allow keeping backward migration >> support if we preserve the semantics of current map_irq somewhere - to >> keep the chance of calculating the legacy values for vmsave as well. >> >> Jan > > We don't need to preserve it, right? We can calculate it before > savevm. We can't calculate it without something like the additional infrastructure I listed. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
[Qemu-devel] [Bug 1007490] [NEW] Missing binfmt string for init script.
Public bug reported: ./scripts/qemu-binfmt-conf.sh needs echo ':armCompiler:M::\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x08\x00\x02\x00\x28\x00:\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff:/usr/bin /qemu-static-arm-binfmt:P' > /proc/sys/fs/binfmt_misc/register Some executables (specifically compilers like /usr/libexec/gcc/armv7a- unknown-linux-gnueabi/4.5.3/cc1 on gentoo) have unusual headers, and don't get recognized as arm binaries. Bug also mentioned on my blog: http://mirage335.dyndns.org/forums/viewtopic.php?f=4&t=11&sid=01f0ca9cc76c78b6f600fa25cc99d62b ** Affects: qemu Importance: Undecided Status: New -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1007490 Title: Missing binfmt string for init script. Status in QEMU: New Bug description: ./scripts/qemu-binfmt-conf.sh needs echo ':armCompiler:M::\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x08\x00\x02\x00\x28\x00:\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff:/usr/bin /qemu-static-arm-binfmt:P' > /proc/sys/fs/binfmt_misc/register Some executables (specifically compilers like /usr/libexec/gcc/armv7a- unknown-linux-gnueabi/4.5.3/cc1 on gentoo) have unusual headers, and don't get recognized as arm binaries. Bug also mentioned on my blog: http://mirage335.dyndns.org/forums/viewtopic.php?f=4&t=11&sid=01f0ca9cc76c78b6f600fa25cc99d62b To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1007490/+subscriptions
Re: [Qemu-devel] Trying to add usermode support for signalfd (but failing)
for the sake of archive (maybe someone does the same mistake and finds
this old thread).
My fault. The syscall numbers changes between PPC and i386. And I did
not think about it and was using some i386 kernel headers to check the
syscalls. Yes, very n00b :(
Sorry for necromancing a thread.
On Thu, Jan 26, 2012 at 7:32 PM, Alex Barcelo wrote:
> I was trying to add signalfd support on qemu-ppc (specifically, I'm
> doing a configure with "--enable-debug-tcg --enable-debug
> --disable-strip --disable-kvm --disable-bsd-user --disable-darwin-user
> --enable-profiler --target-list=ppc-linux-user --disable-curl
> --enable-nptl").
>
> At first I thought that it should be straightforward, so I simply
> added the syscall to the "do_syscall" code. See the patch at the end.
>
> The test program used is the example that can be found on the
> signalfd(2) manpage.
>
> It fails with a "qemu: Unsupported syscall: 313"... but the syscall
> 313 IS supported (it's the splice syscall, which the configure detects
> and enables the CONFIG_SPLICE and it seems correct). I checked with a
> splice-specific test --it worked as it should. I debugged a bit and it
> seems that the switch ignores this syscall, but only when this 313
> syscall is called from inside the signalfd syscall (it seems that
> internally signalfd calls a splice). I am completely lost, I was
> hoping that somebody could point me some directions.
>
> diff --git a/linux-user/syscall.c b/linux-user/syscall.c
> index 2bf9e7e..bcf527f 100644
> --- a/linux-user/syscall.c
> +++ b/linux-user/syscall.c
> @@ -57,6 +57,7 @@ int __clone2(int (*fn)(void *), void *child_stack_base,
> #include
> #include
> //#include
> +#include
> #include
> #include
> #include
> @@ -198,12 +199,14 @@ static type name (type1 arg1,type2 arg2,type3
> arg3,type4 arg4,type5 arg5, \
> #define __NR_sys_inotify_init __NR_inotify_init
> #define __NR_sys_inotify_add_watch __NR_inotify_add_watch
> #define __NR_sys_inotify_rm_watch __NR_inotify_rm_watch
> +#define __NR_sys_signalfd __NR_signalfd
>
> #if defined(__alpha__) || defined (__ia64__) || defined(__x86_64__) || \
> defined(__s390x__)
> #define __NR__llseek __NR_lseek
> #endif
>
> +_syscall3(int, sys_signalfd, int, fd, const sigset_t * , mask , int, flags);
> #ifdef __NR_gettid
> _syscall0(int, gettid)
> #else
> @@ -8141,6 +8144,17 @@ abi_long do_syscall(void *cpu_env, int num,
> abi_long arg1,
> break;
> }
> #endif
> + case TARGET_NR_signalfd:
> + {
> + sigset_t set, *set_ptr;
> +
> + if (!(p = lock_user(VERIFY_READ, arg2, sizeof(target_sigset_t), 1)))
> + goto efault;
> + target_to_host_old_sigset(&set, p);
> + set_ptr = &set;
> + ret = get_errno(sys_signalfd(arg1,set_ptr,arg3) );
> + break;
> + }
> default:
> unimplemented:
> gemu_log("qemu: Unsupported syscall: %d\n", num);
[Qemu-devel] [Bug 1007269] Re: Can’t install or boot up 32bit win8 guest.
Vmware player 4.0.2 is ok. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1007269 Title: Can’t install or boot up 32bit win8 guest. Status in QEMU: New Bug description: Environment: Host OS (ia32/ia32e/IA64):ia32e Guest OS (ia32/ia32e/IA64):ia32e Guest OS Type (Linux/Windows):Linux(rhel6u1) kvm.git Commit:51bfd2998113e1f8ce8dcf853407b76a04b5f2a0 qemu-kvm Commit:3fd9fedb9fae4517d93d76e93a2924559cacf2f6 Host Kernel Version:3.4.0-rc7 Hardware:WSM-EP,Romley-EP Bug detailed description: -- it can't install or boot up 32bit Win8(Consumer Preview Update 2) guest. The guest will crash with the following error, while 64bit Win8 and 32bit Win7 guest work fine. -Win8 Error--- Your computer needs to restart. Please hold down the power button. Error code: 0x005D Parameters: 0x03060D03 0x756E6547 0x49656E69 0x6C65746E -Win8 Error--- "0x005D" code means "UNSUPPORTED_PROCESSOR" in Windows. BTW, you can get 32bit Win8 ISO from the following website. http://windows.microsoft.com/en-US/windows-8/iso Reproduce steps: 1. get 32 bit win8 ISO 2. prepare a disk image: dd if=/dev/zero of=/root/win8-32.img bs=1M count=16384 3. start a guest to install 32bit win8: qemu-system –m 4096 –smp 4 –hda /root/win8-32.img –cdrom /media/32bit-Win8.iso 4. if you have a 32bit win8 image,try to boot it up Current result: 32bit Win8 guest crash Expected result: 32bit win8 guest boot up correctly To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1007269/+subscriptions
Re: [Qemu-devel] [PATCH 0/6] prep: some fixes and Super I/O emulation
Hi, Artyom Tarasenko a écrit : On 3/17/12, Hervé Poussineau wrote: First two patches repair some functionality broken since 2009! Debian install root floppy can now be started again. Can you give the qemu command line for this? The command line is qemu-system-ppc -kernel zImage.prep -fda debian_install_root.bin -M prep You can find kernel and floppy image in archive http://www.h6.dion.ne.jp/~kazuw/qemu-win/qemu-0.9.0-ppc.zip You can find other floppy images required for install at http://archive.debian.org/debian/dists/woody/main/disks-powerpc/current/prep/images-1.44/ Patches 4 to 6 implement the pc87312 Super I/O chip. Some versions by me or by Andreas Färber have already been sent on mailing list. This patch has been tested on PReP emulation and on IBM 40p (not yet committed). Hervé Poussineau (6): i82378/i82374: do not create DMA controller twice prep: change default cpu to '7448' isa: add isa_bus_from_device() method fdc: Parametrize ISA base, IRQ and DMA prep: add pc87312 Super I/O emulation prep: use pc87312 Super I/O chip instead of collection of random ISA devices Hervé
[Qemu-devel] PReP emulation
On Fri, Jun 1, 2012 at 9:38 PM, Hervé Poussineau wrote: > Hi, > > Artyom Tarasenko a écrit : > >> On 3/17/12, Hervé Poussineau wrote: >>> >>> First two patches repair some functionality broken since 2009! >>> Debian install root floppy can now be started again. >> >> >> Can you give the qemu command line for this? > > > The command line is > qemu-system-ppc -kernel zImage.prep -fda debian_install_root.bin -M prep Thanks! I guess -cpu 603 is needed as well. Should it also be possible to boot from a cd image? Or there weren't any CD Linux distributions for PReP? ... rtc: I/O resource 70 is not free. Generic RTC Driver v1.07 Could it be that m48t59 needs to be connected differently (at least on sun4u machines it's wired differently than implemented in qemu)? Artyom > You can find kernel and floppy image in archive > http://www.h6.dion.ne.jp/~kazuw/qemu-win/qemu-0.9.0-ppc.zip > > You can find other floppy images required for install at > http://archive.debian.org/debian/dists/woody/main/disks-powerpc/current/prep/images-1.44/ > > Hervé -- Regards, Artyom Tarasenko solaris/sparc under qemu blog: http://tyom.blogspot.com/search/label/qemu
[Qemu-devel] [PATCH v2 0/6] convert sendkey to qapi
This series converted 'sendkey' command to qapi. Amos Kong (6): qerror: add QERR_OVERFLOW fix doc of using raw values with sendkey rename keyname '<' to 'less' hmp: rename arguments qapi: generate list struct and visit_list for enum qapi: convert sendkey hmp-commands.hx |8 +++--- hmp.c | 56 + hmp.h |1 + monitor.c | 67 ++--- qapi-schema.json | 47 ++ qerror.c |4 +++ qerror.h |3 ++ qmp-commands.hx | 27 +++ scripts/qapi-types.py | 33 +--- scripts/qapi-visit.py | 14 ++--- 10 files changed, 199 insertions(+), 61 deletions(-)
[Qemu-devel] [PATCH v2 1/6] qerror: add QERR_OVERFLOW
Signed-off-by: Amos Kong
---
qerror.c |4
qerror.h |3 +++
2 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/qerror.c b/qerror.c
index 5092fe7..b66af09 100644
--- a/qerror.c
+++ b/qerror.c
@@ -172,6 +172,10 @@ static const QErrorStringTable qerror_table[] = {
.desc = "Parameter '%(name)' expects %(expected)",
},
{
+.error_fmt = QERR_OVERFLOW,
+.desc = "Input is overflow",
+},
+{
.error_fmt = QERR_INVALID_PASSWORD,
.desc = "Password incorrect",
},
diff --git a/qerror.h b/qerror.h
index 4cbba48..dfe9c89 100644
--- a/qerror.h
+++ b/qerror.h
@@ -151,6 +151,9 @@ QError *qobject_to_qerror(const QObject *obj);
#define QERR_INVALID_PARAMETER_VALUE \
"{ 'class': 'InvalidParameterValue', 'data': { 'name': %s, 'expected': %s
} }"
+#define QERR_OVERFLOW \
+"{ 'class': 'Overflow', 'data': {} }"
+
#define QERR_INVALID_PASSWORD \
"{ 'class': 'InvalidPassword', 'data': {} }"
--
1.7.1
Re: [Qemu-devel] [PATCH v2 0/6] convert sendkey to qapi
- Original Message - > This series converted 'sendkey' command to qapi. > > Amos Kong (6): > qerror: add QERR_OVERFLOW > fix doc of using raw values with sendkey > rename keyname '<' to 'less' > hmp: rename arguments > qapi: generate list struct and visit_list for enum > qapi: convert sendkey Changes from v1: - using a JSON array for the key names - rename new error to 'QERR_OVERFLOW' - fix command descriptions - qapi: generate list struct for enum - add '<' fixing > hmp-commands.hx |8 +++--- > hmp.c | 56 > + > hmp.h |1 + > monitor.c | 67 > ++--- > qapi-schema.json | 47 ++ > qerror.c |4 +++ > qerror.h |3 ++ > qmp-commands.hx | 27 +++ > scripts/qapi-types.py | 33 +--- > scripts/qapi-visit.py | 14 ++--- > 10 files changed, 199 insertions(+), 61 deletions(-) > >
[Qemu-devel] [PATCH v2 4/6] hmp: rename arguments
Rename 'string' to 'keys', rename 'hold_time' to 'hold-time'
Signed-off-by: Amos Kong
---
hmp-commands.hx |2 +-
monitor.c | 14 +++---
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/hmp-commands.hx b/hmp-commands.hx
index af18156..18b8e31 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -502,7 +502,7 @@ ETEXI
{
.name = "sendkey",
-.args_type = "string:s,hold_time:i?",
+.args_type = "keys:s,hold-time:i?",
.params = "keys [hold_ms]",
.help = "send keys to the VM (e.g. 'sendkey ctrl-alt-f1',
default hold time=100 ms)",
.mhandler.cmd = do_sendkey,
diff --git a/monitor.c b/monitor.c
index ecfcaa4..536d9dd 100644
--- a/monitor.c
+++ b/monitor.c
@@ -1382,9 +1382,9 @@ static void do_sendkey(Monitor *mon, const QDict *qdict)
char keyname_buf[16];
char *separator;
int keyname_len, keycode, i;
-const char *string = qdict_get_str(qdict, "string");
-int has_hold_time = qdict_haskey(qdict, "hold_time");
-int hold_time = qdict_get_try_int(qdict, "hold_time", -1);
+const char *keys = qdict_get_str(qdict, "keys");
+int has_hold_time = qdict_haskey(qdict, "hold-time");
+int hold_time = qdict_get_try_int(qdict, "hold-time", -1);
if (nb_pending_keycodes > 0) {
qemu_del_timer(key_timer);
@@ -1394,10 +1394,10 @@ static void do_sendkey(Monitor *mon, const QDict *qdict)
hold_time = 100;
i = 0;
while (1) {
-separator = strchr(string, '-');
-keyname_len = separator ? separator - string : strlen(string);
+separator = strchr(keys, '-');
+keyname_len = separator ? separator - keys : strlen(keys);
if (keyname_len > 0) {
-pstrcpy(keyname_buf, sizeof(keyname_buf), string);
+pstrcpy(keyname_buf, sizeof(keyname_buf), keys);
if (keyname_len > sizeof(keyname_buf) - 1) {
monitor_printf(mon, "invalid key: '%s...'\n", keyname_buf);
return;
@@ -1423,7 +1423,7 @@ static void do_sendkey(Monitor *mon, const QDict *qdict)
}
if (!separator)
break;
-string = separator + 1;
+keys = separator + 1;
}
nb_pending_keycodes = i;
/* key down events */
--
1.7.1
[Qemu-devel] [PATCH v2 3/6] rename keyname '<' to 'less'
There are many maps of keycode 0x56 in pc-bios/keymaps/*
pc-bios/keymaps/common:less 0x56
pc-bios/keymaps/common:greater 0x56 shift
pc-bios/keymaps/common:bar 0x56 altgr
pc-bios/keymaps/common:brokenbar 0x56 shift altgr
This patch just rename '<' to 'less', QAPI might add new
variable by adding a prefix to keyname, '$PREFIX_<' is not
available, '$PREFIX_less' is ok.
For compatibility, convert user inputted '<' to 'less'.
Signed-off-by: Amos Kong
---
monitor.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/monitor.c b/monitor.c
index 12a6fe2..ecfcaa4 100644
--- a/monitor.c
+++ b/monitor.c
@@ -1302,7 +1302,7 @@ static const KeyDef key_defs[] = {
{ 0x48, "kp_8" },
{ 0x49, "kp_9" },
-{ 0x56, "<" },
+{ 0x56, "less" },
{ 0x57, "f11" },
{ 0x58, "f12" },
@@ -1406,6 +1406,13 @@ static void do_sendkey(Monitor *mon, const QDict *qdict)
monitor_printf(mon, "too many keys\n");
return;
}
+
+/* Be compatible with old interface, convert user inputted "<" */
+if (!strcmp(keyname_buf, "<")) {
+pstrcpy(keyname_buf, sizeof(keyname_buf), "less");
+keyname_len = 4;
+}
+
keyname_buf[keyname_len] = 0;
keycode = get_keycode(keyname_buf);
if (keycode < 0) {
--
1.7.1
[Qemu-devel] [PATCH v2 6/6] qapi: convert sendkey
Convert 'sendkey' to use QAPI. do_sendkey() depends on some
variables/functions in monitor.c, so reserve qmp_sendkey()
to monitor.c
key_defs[] in monitor.c is the mapping of key name to keycode,
Keys' order in the enmu and key_defs[] is same.
Signed-off-by: Amos Kong
---
hmp-commands.hx |2 +-
hmp.c| 56 +++
hmp.h|1 +
monitor.c| 70 +
qapi-schema.json | 47
qmp-commands.hx | 27
6 files changed, 149 insertions(+), 54 deletions(-)
diff --git a/hmp-commands.hx b/hmp-commands.hx
index 18b8e31..afbfa61 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -505,7 +505,7 @@ ETEXI
.args_type = "keys:s,hold-time:i?",
.params = "keys [hold_ms]",
.help = "send keys to the VM (e.g. 'sendkey ctrl-alt-f1',
default hold time=100 ms)",
-.mhandler.cmd = do_sendkey,
+.mhandler.cmd = hmp_sendkey,
},
STEXI
diff --git a/hmp.c b/hmp.c
index bb0952e..06a6686 100644
--- a/hmp.c
+++ b/hmp.c
@@ -16,6 +16,7 @@
#include "hmp.h"
#include "qemu-timer.h"
#include "qmp-commands.h"
+#include "qapi-types.h"
static void hmp_handle_error(Monitor *mon, Error **errp)
{
@@ -947,3 +948,58 @@ void hmp_device_del(Monitor *mon, const QDict *qdict)
qmp_device_del(id, &err);
hmp_handle_error(mon, &err);
}
+
+static int get_index(const char *key)
+{
+int i;
+
+for (i = 0; KeyCodes_lookup[i] != NULL; i++) {
+if (!strcmp(key, KeyCodes_lookup[i]))
+return i;
+}
+return -1;
+}
+
+void hmp_sendkey(Monitor *mon, const QDict *qdict)
+{
+const char *keys = qdict_get_str(qdict, "keys");
+KeyCodesList *keylist, *head = NULL, *tmp = NULL;
+int has_hold_time = qdict_haskey(qdict, "hold-time");
+int hold_time = qdict_get_try_int(qdict, "hold-time", -1);
+Error *err = NULL;
+char keyname_buf[16];
+
+char *separator;
+int keyname_len;
+
+while (1) {
+separator = strchr(keys, '-');
+keyname_len = separator ? separator - keys : strlen(keys);
+pstrcpy(keyname_buf, sizeof(keyname_buf), keys);
+
+/* Be compatible with old interface, convert user inputted "<" */
+if (!strcmp(keyname_buf, "<")) {
+pstrcpy(keyname_buf, sizeof(keyname_buf), "less");
+keyname_len = 4;
+}
+keyname_buf[keyname_len] = 0;
+
+keylist = g_malloc0(sizeof(*keylist));
+keylist->value = get_index(keyname_buf);
+keylist->next = NULL;
+
+if (tmp)
+tmp->next = keylist;
+tmp = keylist;
+if (!head)
+head = keylist;
+
+if (!separator)
+break;
+keys = separator + 1;
+}
+
+qmp_sendkey(head, has_hold_time, hold_time, &err);
+qapi_free_KeyCodesList(keylist);
+hmp_handle_error(mon, &err);
+}
diff --git a/hmp.h b/hmp.h
index 443b812..40de72c 100644
--- a/hmp.h
+++ b/hmp.h
@@ -61,5 +61,6 @@ void hmp_block_job_set_speed(Monitor *mon, const QDict
*qdict);
void hmp_block_job_cancel(Monitor *mon, const QDict *qdict);
void hmp_migrate(Monitor *mon, const QDict *qdict);
void hmp_device_del(Monitor *mon, const QDict *qdict);
+void hmp_sendkey(Monitor *mon, const QDict *qdict);
#endif
diff --git a/monitor.c b/monitor.c
index 536d9dd..2858ac0 100644
--- a/monitor.c
+++ b/monitor.c
@@ -1341,24 +1341,6 @@ static const KeyDef key_defs[] = {
{ 0, NULL },
};
-static int get_keycode(const char *key)
-{
-const KeyDef *p;
-char *endp;
-int ret;
-
-for(p = key_defs; p->name != NULL; p++) {
-if (!strcmp(key, p->name))
-return p->keycode;
-}
-if (strstart(key, "0x", NULL)) {
-ret = strtoul(key, &endp, 0);
-if (*endp == '\0' && ret >= 0x01 && ret <= 0xff)
-return ret;
-}
-return -1;
-}
-
#define MAX_KEYCODES 16
static uint8_t keycodes[MAX_KEYCODES];
static int nb_pending_keycodes;
@@ -1377,14 +1359,12 @@ static void release_keys(void *opaque)
}
}
-static void do_sendkey(Monitor *mon, const QDict *qdict)
+void qmp_sendkey(KeyCodesList *keys, bool has_hold_time, int64_t hold_time,
+ Error **errp)
{
char keyname_buf[16];
-char *separator;
-int keyname_len, keycode, i;
-const char *keys = qdict_get_str(qdict, "keys");
-int has_hold_time = qdict_haskey(qdict, "hold-time");
-int hold_time = qdict_get_try_int(qdict, "hold-time", -1);
+int keycode, i;
+KeyCodesList *entry = keys;
if (nb_pending_keycodes > 0) {
qemu_del_timer(key_timer);
@@ -1392,39 +1372,23 @@ static void do_sendkey(Monitor *mon, const QDict *qdict)
}
if (!has_hold_time)
hold_time = 100;
-i = 0;
-while (1) {
-separator = strchr(keys, '-');
-keyname_len = separator ? separator - keys : strlen(keys);
-if (keyname_l
[Qemu-devel] [PATCH v2 2/6] fix doc of using raw values with sendkey
(qemu) sendkey a
(qemu) sendkey 0x1e
(qemu) sendkey #0x1e
unknown key: '#0x1e'
The last command doesn't work, '#' is not request before raw values.
Signed-off-by: Amos Kong
---
hmp-commands.hx |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/hmp-commands.hx b/hmp-commands.hx
index 18cb415..af18156 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -513,8 +513,8 @@ STEXI
@findex sendkey
Send @var{keys} to the emulator. @var{keys} could be the name of the
-key or @code{#} followed by the raw value in either decimal or hexadecimal
-format. Use @code{-} to press several keys simultaneously. Example:
+key or the raw value in either decimal or hexadecimal format. Use
+@code{-} to press several keys simultaneously. Example:
@example
sendkey ctrl-alt-f1
@end example
--
1.7.1
[Qemu-devel] [PATCH v2 5/6] qapi: generate list struct and visit_list for enum
Currently, if define an 'enum' and use it in one command's data,
List struct for enum could not be generated, but it's used in
qmp function.
For example: KeyCodesList could not be generated.
>>> qapi-schema.json:
{ 'enum': 'KeyCodes',
'data': [ 'shift', 'alt' ... ] }
{ 'command': 'sendkey',
'data': { 'keys': ['KeyCodes'], '*hold-time': 'int' } }
>>> qmp-command.h:
void qmp_sendkey(KeyCodesList * keys, bool has_hold_time, int64_t
hold_time, Error **errp);
This patch makes qapi can generate List struct for enum.
Signed-off-by: Amos Kong
---
scripts/qapi-types.py | 33 +
scripts/qapi-visit.py | 14 +-
2 files changed, 38 insertions(+), 9 deletions(-)
diff --git a/scripts/qapi-types.py b/scripts/qapi-types.py
index 4a734f5..c9641fb 100644
--- a/scripts/qapi-types.py
+++ b/scripts/qapi-types.py
@@ -16,17 +16,36 @@ import os
import getopt
import errno
-def generate_fwd_struct(name, members):
-return mcgen('''
+def generate_fwd_struct(name, members, enum=False):
+ret = ""
+if not enum:
+ret += mcgen('''
typedef struct %(name)s %(name)s;
+''',
+ name=name)
+ret += mcgen('''
typedef struct %(name)sList
{
-%(name)s *value;
+''',
+ name=name)
+if enum:
+ret += mcgen('''
+ %(name)s value;
+''',
+ name=name)
+else:
+ret += mcgen('''
+ %(name)s * value;
+''',
+ name=name)
+
+ret += mcgen('''
struct %(name)sList *next;
} %(name)sList;
''',
name=name)
+return ret
def generate_struct(structname, fieldname, members):
ret = mcgen('''
@@ -265,7 +284,8 @@ for expr in exprs:
if expr.has_key('type'):
ret += generate_fwd_struct(expr['type'], expr['data'])
elif expr.has_key('enum'):
-ret += generate_enum(expr['enum'], expr['data'])
+ret += generate_enum(expr['enum'], expr['data']) + "\n"
+ret += generate_fwd_struct(expr['enum'], expr['data'], True)
fdef.write(generate_enum_lookup(expr['enum'], expr['data']))
elif expr.has_key('union'):
ret += generate_fwd_struct(expr['union'], expr['data']) + "\n"
@@ -289,6 +309,11 @@ for expr in exprs:
fdef.write(generate_type_cleanup(expr['union'] + "List") + "\n")
ret += generate_type_cleanup_decl(expr['union'])
fdef.write(generate_type_cleanup(expr['union']) + "\n")
+elif expr.has_key('enum'):
+ret += generate_type_cleanup_decl(expr['enum'] + "List")
+fdef.write(generate_type_cleanup(expr['enum'] + "List") + "\n")
+ret += generate_type_cleanup_decl(expr['enum'])
+fdef.write(generate_type_cleanup(expr['enum']) + "\n")
else:
continue
fdecl.write(ret)
diff --git a/scripts/qapi-visit.py b/scripts/qapi-visit.py
index 8d4e94a..e44edfa 100644
--- a/scripts/qapi-visit.py
+++ b/scripts/qapi-visit.py
@@ -81,7 +81,7 @@ end:
''')
return ret
-def generate_visit_list(name, members):
+def generate_visit_list(name, members, enum=False):
return mcgen('''
void visit_type_%(name)sList(Visitor *m, %(name)sList ** obj, const char
*name, Error **errp)
@@ -160,12 +160,14 @@ end:
return ret
-def generate_declaration(name, members, genlist=True):
-ret = mcgen('''
+def generate_declaration(name, members, genlist=True, enum=False):
+ret = ""
+if not enum:
+ret = mcgen('''
void visit_type_%(name)s(Visitor *m, %(name)s ** obj, const char *name, Error
**errp);
''',
-name=name)
+name=name)
if genlist:
ret += mcgen('''
@@ -293,10 +295,12 @@ for expr in exprs:
ret += generate_declaration(expr['union'], expr['data'])
fdecl.write(ret)
elif expr.has_key('enum'):
-ret = generate_visit_enum(expr['enum'], expr['data'])
+ret = generate_visit_list(expr['enum'], expr['data'], True)
+ret += generate_visit_enum(expr['enum'], expr['data'])
fdef.write(ret)
ret = generate_decl_enum(expr['enum'], expr['data'])
+ret += generate_declaration(expr['enum'], expr['data'], enum=True)
fdecl.write(ret)
fdecl.write('''
--
1.7.1
[Qemu-devel] how can i take a snapshot for running system
i want take a snap for running system,how do i? now i can use qemu-img.exe to take a snapshot. and it not save the running memeory info.
