[Qemu-devel] [PATCH 0/2] ARM: Exynos4210: Fix GIC initialization and Combiner operation.
First patch drops gic_cpu_write() after initialization and introduces Exynos4210-specific secondary CPU bootloader. Second patch drops excessive read/write access check in External Combiner read/write functions. Evgeny Voevodin (2): ARM: Exynos4210: Drop gic_cpu_write() after initialization. hw/exynos4210_combiner.c: Drop excessive read/write access check. hw/exynos4210.c | 30 ++ hw/exynos4210.h |3 +++ hw/exynos4210_combiner.c | 10 -- hw/exynos4210_gic.c |2 -- hw/exynos4_boards.c |1 + 5 files changed, 34 insertions(+), 12 deletions(-) -- 1.7.5.4
[Qemu-devel] [PATCH 2/2] hw/exynos4210_combiner.c: Drop excessive read/write access check.
Access to reserved area at offset higher than 0x3c is allowed in
External Combiner. Samsung Galaxy Kernel implements this. So, drop
excessive checks in read/write functions.
Signed-off-by: Evgeny Voevodin e.voevo...@samsung.com
---
hw/exynos4210_combiner.c | 10 --
1 files changed, 0 insertions(+), 10 deletions(-)
diff --git a/hw/exynos4210_combiner.c b/hw/exynos4210_combiner.c
index 6110c19..80af22c 100644
--- a/hw/exynos4210_combiner.c
+++ b/hw/exynos4210_combiner.c
@@ -184,11 +184,6 @@ exynos4210_combiner_read(void *opaque, target_phys_addr_t
offset, unsigned size)
uint32_t reg_n; /* Register number inside the quad */
uint32_t val;
-if (s-external (offset 0x3c offset != 0x100)) {
-hw_error(exynos4210.combiner: unallowed read access at offset 0x
-TARGET_FMT_plx \n, offset);
-}
-
req_quad_base_n = offset 4;
grp_quad_base_n = req_quad_base_n 2;
reg_n = (offset - (req_quad_base_n 4)) 2;
@@ -281,11 +276,6 @@ static void exynos4210_combiner_write(void *opaque,
target_phys_addr_t offset,
uint32_t grp_quad_base_n;/* Base of group quad */
uint32_t reg_n; /* Register number inside the quad */
-if (s-external (offset 0x3c offset != 0x100)) {
-hw_error(exynos4210.combiner: unallowed write access at offset 0x
-TARGET_FMT_plx \n, offset);
-}
-
req_quad_base_n = offset 4;
grp_quad_base_n = req_quad_base_n 2;
reg_n = (offset - (req_quad_base_n 4)) 2;
--
1.7.5.4
[Qemu-devel] [PATCH 1/2] ARM: Exynos4210: Drop gic_cpu_write() after initialization.
Remove gic_cpu_write() call after initialization that was emulating
functionality of earliest SOC bootloader which enables external
GIC CPU1 interface. Instead introduce Exynos4210-specific secondary
CPU bootloader, which enables both Internal and External GIC CPU1
interfaces.
Signed-off-by: Evgeny Voevodin e.voevo...@samsung.com
---
hw/exynos4210.c | 30 ++
hw/exynos4210.h |3 +++
hw/exynos4210_gic.c |2 --
hw/exynos4_boards.c |1 +
4 files changed, 34 insertions(+), 2 deletions(-)
diff --git a/hw/exynos4210.c b/hw/exynos4210.c
index f904370..afc4bdc 100644
--- a/hw/exynos4210.c
+++ b/hw/exynos4210.c
@@ -25,6 +25,7 @@
#include sysemu.h
#include sysbus.h
#include arm-misc.h
+#include loader.h
#include exynos4210.h
#define EXYNOS4210_CHIPID_ADDR 0x1000
@@ -64,6 +65,35 @@
static uint8_t chipid_and_omr[] = { 0x11, 0x02, 0x21, 0x43,
0x09, 0x00, 0x00, 0x00 };
+void exynos4210_write_secondary(CPUARMState *env,
+const struct arm_boot_info *info)
+{
+int n;
+uint32_t smpboot[] = {
+0xe59f3024, /* ldr r3, External gic_cpu_if */
+0xe59f2024, /* ldr r2, Internal gic_cpu_if */
+0xe59f0024, /* ldr r0, startaddr */
+0xe3a01001, /* mov r1, #1 */
+0xe5821000, /* str r1, [r2] */
+0xe5831000, /* str r1, [r3] */
+0xe320f003, /* wfi */
+0xe5901000, /* ldr r1, [r0] */
+0xe1110001, /* tst r1, r1 */
+0x0afb, /* beq wfi */
+0xe12fff11, /* bx r1 */
+EXYNOS4210_EXT_GIC_CPU_BASE_ADDR,
+0, /* gic_cpu_if: base address of Internal GIC CPU interface
*/
+0 /* bootreg: Boot register address is held here */
+};
+smpboot[ARRAY_SIZE(smpboot) - 1] = info-smp_bootreg_addr;
+smpboot[ARRAY_SIZE(smpboot) - 2] = info-gic_cpu_if_addr;
+for (n = 0; n ARRAY_SIZE(smpboot); n++) {
+smpboot[n] = tswap32(smpboot[n]);
+}
+rom_add_blob_fixed(smpboot, smpboot, sizeof(smpboot),
+ info-smp_loader_start);
+}
+
Exynos4210State *exynos4210_init(MemoryRegion *system_mem,
unsigned long ram_size)
{
diff --git a/hw/exynos4210.h b/hw/exynos4210.h
index c112e03..f7c7027 100644
--- a/hw/exynos4210.h
+++ b/hw/exynos4210.h
@@ -97,6 +97,9 @@ typedef struct Exynos4210State {
MemoryRegion bootreg_mem;
} Exynos4210State;
+void exynos4210_write_secondary(CPUARMState *env,
+const struct arm_boot_info *info);
+
Exynos4210State *exynos4210_init(MemoryRegion *system_mem,
unsigned long ram_size);
diff --git a/hw/exynos4210_gic.c b/hw/exynos4210_gic.c
index ec13140..3ba9063 100644
--- a/hw/exynos4210_gic.c
+++ b/hw/exynos4210_gic.c
@@ -321,8 +321,6 @@ static int exynos4210_gic_init(SysBusDevice *dev)
sysbus_init_mmio(dev, s-cpu_container);
sysbus_init_mmio(dev, s-dist_container);
-gic_cpu_write(s-gic, 1, 0, 1);
-
return 0;
}
diff --git a/hw/exynos4_boards.c b/hw/exynos4_boards.c
index 553a02b..ea32c51 100644
--- a/hw/exynos4_boards.c
+++ b/hw/exynos4_boards.c
@@ -70,6 +70,7 @@ static struct arm_boot_info exynos4_board_binfo = {
.loader_start = EXYNOS4210_BASE_BOOT_ADDR,
.smp_loader_start = EXYNOS4210_SMP_BOOT_ADDR,
.nb_cpus = EXYNOS4210_NCPUS,
+.write_secondary_boot = exynos4210_write_secondary,
};
static QEMUMachine exynos4_machines[EXYNOS4_NUM_OF_BOARDS];
--
1.7.5.4
Re: [Qemu-devel] KVM call minutes April 3
Il 04/04/2012 03:18, Michael Roth ha scritto: Attacking the IDL/schema side first is the more rationale approach. From there we can potentially generate ASN.1 BER/DER visitors for the protocol side, or potentially even just vmstate bindings as a start. I've recently started looking into the latter... it's completely feasible, the only downside is it complicates the IDL due requiring support for a lot of what are very much vmstate-specific items, but it should be possible to do this in a manner where those annotations are self-contained and ignorable if we opted to replace vmstate-style declarations. We can also keep the current vmstate descriptions, but access fields from the automatically-generated visitors instead of struct fields. This keeps the IDL simple. Paolo
Re: [Qemu-devel] [V6 PATCH] virtio-net: send gratuitous packets when needed
On Wed, Mar 28, 2012 at 01:44:28PM +0800, Jason Wang wrote:
As hypervior does not have the knowledge of guest network configuration, it's
better to ask guest to send gratuitous packets when needed.
Guest tests VIRTIO_NET_S_ANNOUNCE bit during config change interrupt and when
it
is set, a workqueue is scheduled to send gratuitous packet through
NETDEV_NOTIFY_PEERS. This feature is negotiated through bit
VIRTIO_NET_F_GUEST_ANNOUNCE.
Changes from v5:
- notify the chain before acking the link annoucement
- ack the link announcement notification through control vq
Changes from v4:
- typos
- handle workqueue unconditionally
- move VIRTIO_NET_S_ANNOUNCE to bit 8 to separate rw bits from ro bits
Changes from v3:
- cancel the workqueue during freeze
Changes from v2:
- fix the race between unregister_dev() and workqueue
Signed-off-by: Jason Wang jasow...@redhat.com
I think this needs some fixes. See below.
Thanks.
---
drivers/net/virtio_net.c | 32 +++-
include/linux/virtio_net.h | 13 +
2 files changed, 44 insertions(+), 1 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 4880aa8..0f60da7 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -72,6 +72,9 @@ struct virtnet_info {
/* Work struct for refilling if we run low on memory. */
struct delayed_work refill;
+ /* Work struct for sending gratuitous packets. */
A bit confusing: it does not send anything itself.
A better comment 'for announcing the existence of device
on the network'.
+ struct work_struct announce;
+
/* Chain pages by the private ptr. */
struct page *pages;
@@ -781,12 +784,30 @@ static bool virtnet_send_command(struct virtnet_info
*vi, u8 class, u8 cmd,
return status == VIRTIO_NET_OK;
}
+static void virtnet_ack_link_announce(struct virtnet_info *vi)
+{
+ if (!virtnet_send_command(vi, VIRTIO_NET_CTRL_ANNOUNCE,
+ VIRTIO_NET_CTRL_ANNOUNCE_ACK, NULL,
+ 0, 0)) {
This can run in parallel with other commands. That's pretty bad -
will corrupt the cvq.
Take rtnl lock around calls to this function?
+ dev_warn(vi-dev-dev, Failed to ack link nnounce.\n);
announce
+ }
Better to drop {} around a single statement.
+}
+
+static void announce_work(struct work_struct *work)
+{
+ struct virtnet_info *vi = container_of(work, struct virtnet_info,
+announce);
+ netif_notify_peers(vi-dev);
+ virtnet_ack_link_announce(vi);
+}
+
static int virtnet_close(struct net_device *dev)
{
struct virtnet_info *vi = netdev_priv(dev);
/* Make sure refill_work doesn't re-enable napi! */
cancel_delayed_work_sync(vi-refill);
+ cancel_work_sync(vi-announce);
I think that a config change event can trigger after this point,
so cancel here won't be effective. But why do it here?
virtnet_remove not a better place? We can do it
after remove_vq_common.
napi_disable(vi-napi);
return 0;
@@ -962,11 +983,17 @@ static void virtnet_update_status(struct virtnet_info
*vi)
return;
/* Ignore unknown (future) status bits */
- v = VIRTIO_NET_S_LINK_UP;
+ v = VIRTIO_NET_S_LINK_UP | VIRTIO_NET_S_ANNOUNCE;
The announce bit in vi-status is always clear,
so this is IMO confusing. I would do:
if (v VIRTIO_NET_S_ANNOUNCE) {
schedule
}
v = VIRTIO_NET_S_LINK_UP;
and the rest of the logic is not necessary then.
Also, this might run extra ack announce commands after
VIRTIO_NET_S_ANNOUNCE bit is clear. The spec
isn't clear on whether this is legal.
It would be very hard to fix this, so let's add a comment
stating that it's legal, and clarify the spec
in any case.
if (vi-status == v)
return;
+ if (v VIRTIO_NET_S_ANNOUNCE) {
+ v = ~VIRTIO_NET_S_ANNOUNCE;
+ if (v VIRTIO_NET_S_LINK_UP)
+ schedule_work(vi-announce);
I think we really want an nrt wq here - if this triggers
multiple times there's no good reason to try and run
the ack command many times in parallel.
+ }
+
vi-status = v;
if (vi-status VIRTIO_NET_S_LINK_UP) {
@@ -1076,6 +1103,7 @@ static int virtnet_probe(struct virtio_device *vdev)
goto free;
INIT_DELAYED_WORK(vi-refill, refill_work);
+ INIT_WORK(vi-announce, announce_work);
sg_init_table(vi-rx_sg, ARRAY_SIZE(vi-rx_sg));
sg_init_table(vi-tx_sg, ARRAY_SIZE(vi-tx_sg));
@@ -1187,6 +1215,7 @@ static int virtnet_freeze(struct virtio_device *vdev)
virtqueue_disable_cb(vi-svq);
if (virtio_has_feature(vi-vdev, VIRTIO_NET_F_CTRL_VQ))
virtqueue_disable_cb(vi-cvq);
+ cancel_work_sync(vi-announce);
A config change event can trigger after
Re: [Qemu-devel] [V6 PATCH] virtio-net: send gratuitous packets when needed
On Tue, Apr 03, 2012 at 05:49:05PM -0400, David Miller wrote: From: Jason Wang jasow...@redhat.com Date: Wed, 28 Mar 2012 13:44:28 +0800 As hypervior does not have the knowledge of guest network configuration, it's better to ask guest to send gratuitous packets when needed. Guest tests VIRTIO_NET_S_ANNOUNCE bit during config change interrupt and when it is set, a workqueue is scheduled to send gratuitous packet through NETDEV_NOTIFY_PEERS. This feature is negotiated through bit VIRTIO_NET_F_GUEST_ANNOUNCE. ... Signed-off-by: Jason Wang jasow...@redhat.com Michael and others, what's the story with this patch? It's a new feature so it will be 3.5 material when it's ready. Sent some comments for now. Thanks, MST ___ Virtualization mailing list virtualizat...@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [Qemu-devel] [RFC][PATCH v2 0/4] uq/master: Basic MSI support for in-kernel irqchip mode
On Tue, Apr 03, 2012 at 07:27:36PM +0200, Jan Kiszka wrote: On 2012-04-03 15:06, Michael S. Tsirkin wrote: On Tue, Apr 03, 2012 at 09:23:12AM +0200, Jan Kiszka wrote: This is v2 of the RFC, fixing a memory leak in kvm_flush_dynamic_msi_routes and adding support for the proposed KVM_SIGNAL_MSI IOCTL. This series depends on kvm: set gsi_bits and max_gsi correctly (http://thread.gmane.org/gmane.comp.emulators.kvm.devel/88906). Looks good to me. How hard would it be to add irqfd support? Shouldn't be, but the changes will be a bit bigger. I'm thinking about a revamped interface between the MSI core and affected devices for a while. Will try to put down in some lines of code what I have in mind - once the dynamic MSI injection topic has settled. Jan Yes it's not an objection - just a question. -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
Re: [Qemu-devel] [RFC][PATCH v2 0/4] uq/master: Basic MSI support for in-kernel irqchip mode
On Tue, Apr 03, 2012 at 09:17:30PM +0200, Jan Kiszka wrote: On 2012-04-03 09:23, Jan Kiszka wrote: This is v2 of the RFC, fixing a memory leak in kvm_flush_dynamic_msi_routes and adding support for the proposed KVM_SIGNAL_MSI IOCTL. This series depends on kvm: set gsi_bits and max_gsi correctly (http://thread.gmane.org/gmane.comp.emulators.kvm.devel/88906). Jan Kiszka (4): kvm: Refactor KVMState::max_gsi to gsi_count kvm: Introduce basic MSI support for in-kernel irqchips KVM: x86: Wire up MSI support for in-kernel irqchip kvm: Add support for direct MSI injections hw/apic.c |3 + hw/kvm/apic.c | 33 +- hw/pc.c |5 -- kvm-all.c | 195 +++-- kvm.h |1 + 5 files changed, 225 insertions(+), 12 deletions(-) As we obviously agreed on the general direction regarding an MSI injection interface, I think patches 1-3 can lose their RFC tags and are ready for uq/master (provided there are no further review comments). Patch 4 will be reworked once the kernel interface is finalized. Jan I agree. Acked-by: Michael S. Tsirkin m...@redhat.com -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
Re: [Qemu-devel] [PATCH, RESEND] kvm: Fix dirty tracking with large kernel page size
On 04/04/2012 04:15 AM, David Gibson wrote: If the kernel page size is larger than TARGET_PAGE_SIZE, which happens for example on ppc64 with kernels compiled for 64K pages, the dirty tracking doesn't work. Cc: Avi Kivity a...@redhat.com Cc: Marcelo Tosatti mtosa...@redhat.com Thanks, applied to uq/master. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.
Re: [Qemu-devel] [PATCH v5] sheepdog: implement SD_OP_FLUSH_VDI operation
Am 03.04.2012 22:03, schrieb Liu Yuan:
From: Liu Yuan tailai...@taobao.com
Flush operation is supposed to flush the write-back cache of
sheepdog cluster.
By issuing flush operation, we can assure the Guest of data
reaching the sheepdog cluster storage.
Cc: Kevin Wolf kw...@redhat.com
Cc: MORITA Kazutaka morita.kazut...@lab.ntt.co.jp
Signed-off-by: Liu Yuan tailai...@taobao.com
---
Hi Kevin,
Sorry, I found a problem in v4 patch, that s-{addr, port} isn't properly
initilized.
If you think it is inconvenient for you to update this patch, please let
me know and I'll submit a new patch.
I can update it in my queue, no problem there.
But I diffed this against v4 and it doesn't seem to have any changes,
except in the context of two hunks. Are you sure that you didn't do the
fixes in a separate commit or send the wrong patch or something like that?
Kevin
Re: [Qemu-devel] [PATCH v5] sheepdog: implement SD_OP_FLUSH_VDI operation
Hi kevin,
On 04/04/2012 04:53 PM, Kevin Wolf wrote:
I can update it in my queue, no problem there.
But I diffed this against v4 and it doesn't seem to have any changes,
except in the context of two hunks. Are you sure that you didn't do the
fixes in a separate commit or send the wrong patch or something like that?
V5 patch just reordered some of lines in sd_open() see below:
static int sd_open(BlockDriverState *bs, const char *filename, int flags)
@@ -1026,6 +1093,15 @@ static int sd_open(BlockDriverState *bs, const
char *filename, int flags)
goto out;
}
+if (flags BDRV_O_CACHE_WB) {
+s-cache_enabled = 1;
+s-flush_fd = connect_to_sdog(s-addr, s-port);
+if (s-flush_fd 0) {
+error_report(failed to connect);
+goto out;
+}
+}
+
if (snapid) {
dprintf(% PRIx32 snapshot inode was open.\n, vid);
s-is_snapshot = 1;
s-{addr,port} is initilized in find_vdi_name(), so flush_fd should be
initilized after it.
I checked the patch again, V5 patch is no problem.
Thanks,
Yuan
Re: [Qemu-devel] [PATCH v5] sheepdog: implement SD_OP_FLUSH_VDI operation
Am 04.04.2012 10:58, schrieb Liu Yuan:
Hi kevin,
On 04/04/2012 04:53 PM, Kevin Wolf wrote:
I can update it in my queue, no problem there.
But I diffed this against v4 and it doesn't seem to have any changes,
except in the context of two hunks. Are you sure that you didn't do the
fixes in a separate commit or send the wrong patch or something like that?
V5 patch just reordered some of lines in sd_open() see below:
[...]
s-{addr,port} is initilized in find_vdi_name(), so flush_fd should be
initilized after it.
Yes, of course. It seems to be still too early in the morning...
Thanks, I updated the patch in my queue.
Kevin
Re: [Qemu-devel] [PATCH 1/2] ARM: Exynos4210: Drop gic_cpu_write() after initialization.
On 4 April 2012 07:39, Evgeny Voevodin e.voevo...@samsung.com wrote: Remove gic_cpu_write() call after initialization that was emulating functionality of earliest SOC bootloader which enables external GIC CPU1 interface. Instead introduce Exynos4210-specific secondary CPU bootloader, which enables both Internal and External GIC CPU1 interfaces. Signed-off-by: Evgeny Voevodin e.voevo...@samsung.com Reviewed-by: Peter Maydell peter.mayd...@linaro.org Thanks for the quick patch; I've taken both these into arm-devs.next. -- PMM
Re: [Qemu-devel] [PATCH 2/2] hw/exynos4210_combiner.c: Drop excessive read/write access check.
On 4 April 2012 07:39, Evgeny Voevodin e.voevo...@samsung.com wrote: Access to reserved area at offset higher than 0x3c is allowed in External Combiner. Samsung Galaxy Kernel implements this. So, drop excessive checks in read/write functions. Signed-off-by: Evgeny Voevodin e.voevo...@samsung.com Reviewed-by: Peter Maydell peter.mayd...@linaro.org -- PMM
[Qemu-devel] [PATCH] Support system reset in Exynos4210
Reset the system when 1 is written to SWRESET register
Signed-off-by: Dmitry Zhurikhin z...@ispras.ru
---
hw/exynos4210_pmu.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/hw/exynos4210_pmu.c b/hw/exynos4210_pmu.c
index c12d750..edf6e34 100644
--- a/hw/exynos4210_pmu.c
+++ b/hw/exynos4210_pmu.c
@@ -25,6 +25,7 @@
*/
#include sysbus.h
+#include sysemu.h
#ifndef DEBUG_PMU
#define DEBUG_PMU 0
@@ -422,6 +423,16 @@ static void exynos4210_pmu_write(void *opaque,
target_phys_addr_t offset,
if (reg_p-offset == offset) {
PRINT_DEBUG_EXTEND(%s 0x%04x - 0x%04x\n, reg_p-name,
(uint32_t)offset, (uint32_t)val);
+switch (offset) {
+case SWRESET:
+if (val 1) {
+qemu_system_reset_request();
+}
+break;
+default:
+/* Nothing */
+break;
+}
s-reg[i] = val;
return;
}
--
1.7.4.1
Re: [Qemu-devel] KVM call minutes April 3
On Apr 4, 2012 2:42 AM, Paolo Bonzini pbonz...@redhat.com wrote: Il 04/04/2012 03:18, Michael Roth ha scritto: Attacking the IDL/schema side first is the more rationale approach. From there we can potentially generate ASN.1 BER/DER visitors for the protocol side, or potentially even just vmstate bindings as a start. I've recently started looking into the latter... it's completely feasible, the only downside is it complicates the IDL due requiring support for a lot of what are very much vmstate-specific items, but it should be possible to do this in a manner where those annotations are self-contained and ignorable if we opted to replace vmstate-style declarations. We can also keep the current vmstate descriptions, but access fields from the automatically-generated visitors instead of struct fields. This keeps the IDL simple. It may be worthwhile as an incremental step though, one nice thing about automatically generated bindings is that with the QIDL Anthony prototyped a while back we assume we serialize by default, so changes in annotated structs automatically trigger changes in the generated bindings unless you explicitly mark fields as immutable/derivable/etc, which we can tie into the build or make check to automatically detect and bring attention to changes in vmstate. This may be worth the effort if we adopt the proposed 4 year migration support cycle for pc-1.0, since that'll continue to rely on vmstate even after we move on to an IDL and newer protocol. Paolo
Re: [Qemu-devel] KVM call minutes April 3
On 04/04/2012 01:37 PM, Michael Roth wrote: On Apr 4, 2012 2:42 AM, Paolo Bonzini pbonz...@redhat.com mailto:pbonz...@redhat.com wrote: Il 04/04/2012 03:18, Michael Roth ha scritto: Attacking the IDL/schema side first is the more rationale approach. From there we can potentially generate ASN.1 BER/DER visitors for the protocol side, or potentially even just vmstate bindings as a start. I've recently started looking into the latter... it's completely feasible, the only downside is it complicates the IDL due requiring support for a lot of what are very much vmstate-specific items, but it should be possible to do this in a manner where those annotations are self-contained and ignorable if we opted to replace vmstate-style declarations. We can also keep the current vmstate descriptions, but access fields from the automatically-generated visitors instead of struct fields. This keeps the IDL simple. It may be worthwhile as an incremental step though, one nice thing about automatically generated bindings is that with the QIDL Anthony prototyped a while back we assume we serialize by default, so changes in annotated structs automatically trigger changes in the generated bindings unless you explicitly mark fields as immutable/derivable/etc, which we can tie into the build or make check to automatically detect and bring attention to changes in vmstate. This may be worth the effort if we adopt the proposed 4 year migration support cycle for pc-1.0, since that'll continue to rely on vmstate even after we move on to an IDL and newer protocol. Beyond ASL/IDL I like to be sure that we're not just translating one format to other representation but instead we introduce some new functionality like: - Ability to negotiate the protocol version - Bi-direction data exchange, the sender will send data as a function of the target release - Include the machine type too - Synchronize the entire qemu cmdline and don't relay on management to set it up. - Along the way, deal w/ hotplug events. Paolo
Re: [Qemu-devel] [PATCH, RESEND] kvm: Fix dirty tracking with large kernel page size
On 2012-04-04 03:12, David Gibson wrote: Also, what's about coalesced MMIO? I see that the ring definition depends on [TARGET_]PAGE_SIZE. What page size does the power kernel use for it, and does it make a relevant difference for space? Hr, so the HV variant of Power KVM doesn't do coalesced mmio. The PR variant does, but I don't know enough about it to easily answer that. If there's a bug there, it hasn't bitten yet, so how about we fix that another day. Not really a smart approach, specifically now that we are aware of a potential problem here. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
Re: [Qemu-devel] KVM call minutes April 3
On 04/03/2012 03:43 PM, Dor Laor wrote: On 04/03/2012 05:43 PM, Markus Armbruster wrote: I'm afraid my notes are rather rough... * 1.1 soft freeze apr 15th (less than two weeks) hard freeze may 1 three months cycle for 1.2 stable machine types only every few releases? pc-next * Maintainers, got distracted and my notes make no sense, sorry * MSI injection to KVM irqchips from userspace devices models * qemu-kvm tree: working towards upstream merge not much left, mostly device assignment * Migration: vmstate and visitors, decoupling the wire format why not ASN.1 Curiosity kills me of waiting for next week's meeting to get the answer ASN.1 is an IDL format. It's encoded in many ways including BER. I think there's wide spread agreement that the next migration wire format should be encoded with BER which means it could be described via ASN.1 but I don't think we intend on using ASN.1 within the code base. I don't think using ASN.1 to describe devices makes sense. There really aren't very good Open Source ASN.1 compilers. I also don't think the syntax is flexible enough to fully describe a device either. Regards, Anthony Liguori * qtest: test cases wanted
Re: [Qemu-devel] KVM call minutes April 3
On 04/04/2012 05:53 AM, Dor Laor wrote: On 04/04/2012 01:37 PM, Michael Roth wrote: On Apr 4, 2012 2:42 AM, Paolo Bonzini pbonz...@redhat.com mailto:pbonz...@redhat.com wrote: Il 04/04/2012 03:18, Michael Roth ha scritto: Attacking the IDL/schema side first is the more rationale approach. From there we can potentially generate ASN.1 BER/DER visitors for the protocol side, or potentially even just vmstate bindings as a start. I've recently started looking into the latter... it's completely feasible, the only downside is it complicates the IDL due requiring support for a lot of what are very much vmstate-specific items, but it should be possible to do this in a manner where those annotations are self-contained and ignorable if we opted to replace vmstate-style declarations. We can also keep the current vmstate descriptions, but access fields from the automatically-generated visitors instead of struct fields. This keeps the IDL simple. It may be worthwhile as an incremental step though, one nice thing about automatically generated bindings is that with the QIDL Anthony prototyped a while back we assume we serialize by default, so changes in annotated structs automatically trigger changes in the generated bindings unless you explicitly mark fields as immutable/derivable/etc, which we can tie into the build or make check to automatically detect and bring attention to changes in vmstate. This may be worth the effort if we adopt the proposed 4 year migration support cycle for pc-1.0, since that'll continue to rely on vmstate even after we move on to an IDL and newer protocol. Beyond ASL/IDL I like to be sure that we're not just translating one format to other representation but instead we introduce some new functionality like: - Ability to negotiate the protocol version Ack. - Bi-direction data exchange, the sender will send data as a function of the target release The reason bi-direction data exchange doesn't exist is because it would add latency to the critical path. I think we should avoid bi-directional data exchange unless there's an extremely compelling reason to do so. - Include the machine type too - Synchronize the entire qemu cmdline and don't relay on management to set it up. - Along the way, deal w/ hotplug events. This will be address via QOM. As we convert backends and machine types, we should be able to dump out the full configuration and send it over the wire. Regards, Anthony Liguori Paolo
Re: [Qemu-devel] [PATCH] Support system reset in Exynos4210
04.04.2012 14:08, Dmitry Zhurikhin пишет:
Reset the system when 1 is written to SWRESET register
Signed-off-by: Dmitry Zhurikhinz...@ispras.ru
---
hw/exynos4210_pmu.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/hw/exynos4210_pmu.c b/hw/exynos4210_pmu.c
index c12d750..edf6e34 100644
--- a/hw/exynos4210_pmu.c
+++ b/hw/exynos4210_pmu.c
@@ -25,6 +25,7 @@
*/
#include sysbus.h
+#include sysemu.h
#ifndef DEBUG_PMU
#define DEBUG_PMU 0
@@ -422,6 +423,16 @@ static void exynos4210_pmu_write(void *opaque,
target_phys_addr_t offset,
if (reg_p-offset == offset) {
PRINT_DEBUG_EXTEND(%s0x%04x - 0x%04x\n, reg_p-name,
(uint32_t)offset, (uint32_t)val);
+switch (offset) {
+case SWRESET:
+if (val 1) {
+qemu_system_reset_request();
+}
+break;
+default:
+/* Nothing */
+break;
+}
s-reg[i] = val;
return;
}
It's not quite well. At first, when you do reset, appropriate status
must be set in RST_STAT register. At second, not all registers in PMU
should be set in default value after reset, so you should change PMU
reset function for handling different resets (see spec) So, this
functionality should be wrote more carefully
And use #define for registers and fields of the registers. It's more
clearly, as for me.
Regards,
MK
Re: [Qemu-devel] KVM call minutes April 3
On 04/04/2012 02:52 PM, Anthony Liguori wrote: On 04/04/2012 05:53 AM, Dor Laor wrote: On 04/04/2012 01:37 PM, Michael Roth wrote: On Apr 4, 2012 2:42 AM, Paolo Bonzini pbonz...@redhat.com mailto:pbonz...@redhat.com wrote: Il 04/04/2012 03:18, Michael Roth ha scritto: Attacking the IDL/schema side first is the more rationale approach. From there we can potentially generate ASN.1 BER/DER visitors for the protocol side, or potentially even just vmstate bindings as a start. I've recently started looking into the latter... it's completely feasible, the only downside is it complicates the IDL due requiring support for a lot of what are very much vmstate-specific items, but it should be possible to do this in a manner where those annotations are self-contained and ignorable if we opted to replace vmstate-style declarations. We can also keep the current vmstate descriptions, but access fields from the automatically-generated visitors instead of struct fields. This keeps the IDL simple. It may be worthwhile as an incremental step though, one nice thing about automatically generated bindings is that with the QIDL Anthony prototyped a while back we assume we serialize by default, so changes in annotated structs automatically trigger changes in the generated bindings unless you explicitly mark fields as immutable/derivable/etc, which we can tie into the build or make check to automatically detect and bring attention to changes in vmstate. This may be worth the effort if we adopt the proposed 4 year migration support cycle for pc-1.0, since that'll continue to rely on vmstate even after we move on to an IDL and newer protocol. Beyond ASL/IDL I like to be sure that we're not just translating one format to other representation but instead we introduce some new functionality like: - Ability to negotiate the protocol version Ack. - Bi-direction data exchange, the sender will send data as a function of the target release The reason bi-direction data exchange doesn't exist is because it would add latency to the critical path. I think we should avoid bi-directional Not necessarily, there is not need to do the exchange on the down time, you can do it ahead of time during the initial connection and few additional msec or even a second won't change much. data exchange unless there's an extremely compelling reason to do so. The key advantage is that you'll be able to migrate to an old qemu that may not be compatible w/ the standard protocol and the source will be able to discover this and adjust. At the moment I don't have anything more concrete than that but I think that's happen in the past and will continue to happen and we can add the required hook into the protocol. - Include the machine type too - Synchronize the entire qemu cmdline and don't relay on management to set it up. - Along the way, deal w/ hotplug events. This will be address via QOM. As we convert backends and machine types, we should be able to dump out the full configuration and send it over the wire. Regards, Anthony Liguori Paolo
Re: [Qemu-devel] KVM call minutes April 3
On Wed, Apr 04, 2012 at 01:53:34PM +0300, Dor Laor wrote: On 04/04/2012 01:37 PM, Michael Roth wrote: On Apr 4, 2012 2:42 AM, Paolo Bonzini pbonz...@redhat.com mailto:pbonz...@redhat.com wrote: Il 04/04/2012 03:18, Michael Roth ha scritto: Attacking the IDL/schema side first is the more rationale approach. From there we can potentially generate ASN.1 BER/DER visitors for the protocol side, or potentially even just vmstate bindings as a start. I've recently started looking into the latter... it's completely feasible, the only downside is it complicates the IDL due requiring support for a lot of what are very much vmstate-specific items, but it should be possible to do this in a manner where those annotations are self-contained and ignorable if we opted to replace vmstate-style declarations. We can also keep the current vmstate descriptions, but access fields from the automatically-generated visitors instead of struct fields. This keeps the IDL simple. It may be worthwhile as an incremental step though, one nice thing about automatically generated bindings is that with the QIDL Anthony prototyped a while back we assume we serialize by default, so changes in annotated structs automatically trigger changes in the generated bindings unless you explicitly mark fields as immutable/derivable/etc, which we can tie into the build or make check to automatically detect and bring attention to changes in vmstate. This may be worth the effort if we adopt the proposed 4 year migration support cycle for pc-1.0, since that'll continue to rely on vmstate even after we move on to an IDL and newer protocol. Beyond ASL/IDL I like to be sure that we're not just translating one format to other representation but instead we introduce some new functionality like: - Ability to negotiate the protocol version - Bi-direction data exchange, the sender will send data as a function of the target release - Include the machine type too I've been toying with the notion of having the target start up a QMP limited server that the source talks to to orchestrate negotiation. We could potentially even send the device state by taking our QIDL-generated visitors and serializing state via QmpOutputVisitor. QMP can be made aware of the format of the device state input by taking the intermediate step of generating QAPI schemas via QIDL, and using the QAPI code generators to generate the visitors rather than QIDL directly. This would also address the protocol side: just use QMP rather than ASN.1.. It's not as compact, but device state is such a small amount of data compared to memory/disk that I don't think it's worth optimizing that aspect, though we could use compression at the protocol layer if we were inclined. Anything more suited to an out-of-band protocol, like memory/disk, could be orchestrated via this interface... source can ask target for a port to handle such things, negotiate stuff like XBZRLE, etc. - Synchronize the entire qemu cmdline and don't relay on management to set it up. - Along the way, deal w/ hotplug events. My initial plan for the QIDL-generated visitors is to associate a QOM property, state, with each device, and to serialize device state by walking the QOM composition tree, the main rationale being that if we extend that serialization to include other QOM properties, I believe we have everything we need to recreate all the devices on the target: parent-child relationships, types, properties set via cmdline, device state... A simpler alternative would be to leverage just send the cmdline options over to the target and assume that it results in the same underlying machine, then just send off the device state. Much simpler actually...but the above approach should work regardless of changes to the command-line options on the source... having an internally stable cmdline scheme might work as well... I'm not sure what the right approach is here but whatever we decide on I think being able to automatically generate visitors from annotations is a good first-step and should tie into any forseeable approaches. Paolo
[Qemu-devel] [PATCH, repost] qemu-keymaps: Finnish keyboard mapping broken
As mentioned in http://bugs.debian.org/660154 , finnish keyboard mapping is kind of broken. Fix it as Timo Sirainen suggests in #660154. index 2a4e0f0..4be7586 100644 --- a/pc-bios/keymaps/fi +++ b/pc-bios/keymaps/fi @@ -99,9 +99,7 @@ asterisk 0x2b shift acute 0x2b altgr multiply 0x2b shift altgr guillemotleft 0x2c altgr -less 0x2c shift altgr guillemotright 0x2d altgr -greater 0x2d shift altgr copyright 0x2e altgr leftdoublequotemark 0x2f altgr grave 0x2f shift altgr Thanks! /mjt
Re: [Qemu-devel] [PATCH] Support system reset in Exynos4210
On 2012-04-04 15:55, Maksim Kozlov wrote:
04.04.2012 14:08, Dmitry Zhurikhin пишет:
Reset the system when 1 is written to SWRESET register
Signed-off-by: Dmitry Zhurikhinz...@ispras.ru
---
hw/exynos4210_pmu.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/hw/exynos4210_pmu.c b/hw/exynos4210_pmu.c
index c12d750..edf6e34 100644
--- a/hw/exynos4210_pmu.c
+++ b/hw/exynos4210_pmu.c
@@ -25,6 +25,7 @@
*/
#include sysbus.h
+#include sysemu.h
#ifndef DEBUG_PMU
#define DEBUG_PMU 0
@@ -422,6 +423,16 @@ static void exynos4210_pmu_write(void *opaque,
target_phys_addr_t offset,
if (reg_p-offset == offset) {
PRINT_DEBUG_EXTEND(%s0x%04x - 0x%04x\n, reg_p-name,
(uint32_t)offset, (uint32_t)val);
+switch (offset) {
+case SWRESET:
+if (val 1) {
+qemu_system_reset_request();
+}
+break;
+default:
+/* Nothing */
+break;
+}
s-reg[i] = val;
return;
}
It's not quite well. At first, when you do reset, appropriate status
must be set in RST_STAT register. At second, not all registers in PMU
should be set in default value after reset, so you should change PMU
reset function for handling different resets (see spec) So, this
functionality should be wrote more carefully
Well, this is the case when there is a need to modify booting procedure
depending on the values of these registers. I haven't found any such
code in the current kernel. As I now remember saving their values was
indeed important when we were trying to use an U-Boot bootloader. But
as long as we are sticking with QEMU bootloader it doesn't matter.
Anyway this information is unfortunately absent in Exynos4210 public
documentation.
And use #define for registers and fields of the registers. It's more
clearly, as for me.
As you say.
Regards,
MK
Regards,
Dmitry
Re: [Qemu-devel] [RFC PATCH v1 2/4] m25p80: initial verion
Am 30.03.2012 08:37, schrieb Peter A. G. Crosthwaite: Added device model for m25p80 SPI flash Signed-off-by: Peter A. G. Crosthwaite peter.crosthwa...@petalogix.com --- Makefile.target |1 + hw/m25p80.c | 495 +++ 2 files changed, 496 insertions(+), 0 deletions(-) create mode 100644 hw/m25p80.c diff --git a/Makefile.target b/Makefile.target index 8fd3718..fcccf1b 100644 --- a/Makefile.target +++ b/Makefile.target @@ -321,6 +321,7 @@ obj-microblaze-y = petalogix_s3adsp1800_mmu.o obj-microblaze-y += petalogix_ml605_mmu.o obj-microblaze-y += microblaze_boot.o obj-microblaze-y += spi.o +obj-microblaze-y += m25p80.o obj-microblaze-y += microblaze_pic_cpu.o obj-microblaze-y += xilinx_intc.o diff --git a/hw/m25p80.c b/hw/m25p80.c new file mode 100644 index 000..2b67375 --- /dev/null +++ b/hw/m25p80.c @@ -0,0 +1,495 @@ +/* + * ST M25P80 emulator. [snip] A device by ST does not sound microblaze-specific and in that case, similar to the recent Atmel maxtouch device, should go into hw-obj-$(CONFIG_M25P80) instead so that it's compiled only once for microblaze-softmmu and microblazeel-softmmu. Same for spi.o since it implements a generic bus AFAIU. 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] KVM call minutes April 3
On 04/04/2012 02:14 PM, Michael Roth wrote: On Wed, Apr 04, 2012 at 01:53:34PM +0300, Dor Laor wrote: On 04/04/2012 01:37 PM, Michael Roth wrote: On Apr 4, 2012 2:42 AM, Paolo Bonzinipbonz...@redhat.com mailto:pbonz...@redhat.com wrote: Il 04/04/2012 03:18, Michael Roth ha scritto: Attacking the IDL/schema side first is the more rationale approach. From there we can potentially generate ASN.1 BER/DER visitors for the protocol side, or potentially even just vmstate bindings as a start. I've recently started looking into the latter... it's completely feasible, the only downside is it complicates the IDL due requiring support for a lot of what are very much vmstate-specific items, but it should be possible to do this in a manner where those annotations are self-contained and ignorable if we opted to replace vmstate-style declarations. We can also keep the current vmstate descriptions, but access fields from the automatically-generated visitors instead of struct fields. This keeps the IDL simple. It may be worthwhile as an incremental step though, one nice thing about automatically generated bindings is that with the QIDL Anthony prototyped a while back we assume we serialize by default, so changes in annotated structs automatically trigger changes in the generated bindings unless you explicitly mark fields as immutable/derivable/etc, which we can tie into the build or make check to automatically detect and bring attention to changes in vmstate. This may be worth the effort if we adopt the proposed 4 year migration support cycle for pc-1.0, since that'll continue to rely on vmstate even after we move on to an IDL and newer protocol. Beyond ASL/IDL I like to be sure that we're not just translating one format to other representation but instead we introduce some new functionality like: - Ability to negotiate the protocol version - Bi-direction data exchange, the sender will send data as a function of the target release - Include the machine type too I've been toying with the notion of having the target start up a QMP limited server that the source talks to to orchestrate negotiation. We could potentially even send the device state by taking our QIDL-generated visitors and serializing state via QmpOutputVisitor. QMP can be made aware of the format of the device state input by taking the intermediate step of generating QAPI schemas via QIDL, and using the QAPI code generators to generate the visitors rather than QIDL directly. This would also address the protocol side: just use QMP rather than ASN.1.. It's not as compact, but device state is such a small amount of data compared to memory/disk that I don't think it's worth optimizing that aspect, though we could use compression at the protocol layer if we were inclined. Anything more suited to an out-of-band protocol, like memory/disk, could be orchestrated via this interface... source can ask target for a port to handle such things, negotiate stuff like XBZRLE, etc. - Synchronize the entire qemu cmdline and don't relay on management to set it up. - Along the way, deal w/ hotplug events. My initial plan for the QIDL-generated visitors is to associate a QOM property, state, with each device, and to serialize device state by walking the QOM composition tree, the main rationale being that if we extend that serialization to include other QOM properties, I believe we have everything we need to recreate all the devices on the target: parent-child relationships, types, properties set via cmdline, device state... A simpler alternative would be to leverage just send the cmdline options over to the target and assume that it results in the same underlying machine, then just send off the device state. Much simpler actually...but the above approach should work regardless of changes to the command-line options on the source... having an internally stable cmdline scheme might work as well... Will command line take in account hot-plugged devices? I'm not sure what the right approach is here but whatever we decide on I think being able to automatically generate visitors from annotations is a good first-step and should tie into any forseeable approaches. Paolo -- - Igor
Re: [Qemu-devel] [PATCH] MSI / MSIX injection for Xen HVM
On Tue, 3 Apr 2012, Wei Liu (Intern) wrote:
On Thu, 2012-03-01 at 15:56 +, Paolo Bonzini wrote:
Il 01/03/2012 15:50, Stefano Stabellini ha scritto:
That is a good point actually: we already have lapic emulation in
Xen,
it makes sense to have apic-msi in Xen too.
We would still need the changes to msi_notify and msix_notify
though.
Why? The stores would just go to the Xen interrupt controller MMIO
area
which then does the xc_hvm_inject_msi.
Because msi(x)_notify is called by QEMU's emulated devices: it is not
possible from QEMU to cause an emulation trap in Xen on behalf of the
guest.
I'm not a QEMU expert, so following question may be dumb. However I do
care about a cleaner implementation. So please be patient with me. :-)
msi{x,}_notify doesn't have to go to Xen MMIO emulation, so in Wei's
patch you don't need anymore the msi{,x}_notify parts, only apic_send_msi.
I don't quite understand you don't need anymore the msi{,x}_notify
parts. Virtio PCI invokes msi_notify directly. If I don't hook up
msi{,x}_notify, how can I deal with devices like Virtio PCI?
msi_notify calls stl_le_phys that is internal to QEMU and goes to the
emulated local apic in QEMU. So you can just hook into the emulated
local apic like KVM, rather than adding a new hook in msi{,x}_notify.
The fact that the real emulated local apic is in Xen is very confusing
for the sake of this discussion. The emulated local apic in Xen is not
involved in Paolo's suggestion.
[Qemu-devel] [PATCH] memory: check address space when a listener is registered
This patch resolves a bug in memory listener registration.
range_add callback was called on each section of the both
address space (IO and memory space) even if it doesn't match
the address space filter.
Signed-off-by: Julien Grall julien.gr...@citrix.com
---
memory.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/memory.c b/memory.c
index 22b0352..a9d237d 100644
--- a/memory.c
+++ b/memory.c
@@ -1444,6 +1444,11 @@ static void listener_add_address_space(MemoryListener
*listener,
{
FlatRange *fr;
+if (listener-address_space_filter
+ listener-address_space_filter != as-root) {
+return;
+}
+
if (global_dirty_log) {
listener-log_global_start(listener);
}
--
Julien Grall
[Qemu-devel] Macvtap or tap+bridge
When I first started setting up qemu-kvm VMs for customers, I set up their internet-facing network with tap interfaces enslaved to a host bridge along with the physical network card of the host, something like ip tuntap add dev tapN mode tap brctl addif br0 tapN ip link set tapN up qemu-kvm ... -net nic,... -net tap,ifname=tapN,script=no,downscript=no More recently on my development boxes, I've been using macvtap in the form ip link add link eth0 name guestN address MAC type macvtap mode bridge ip link set guestN up qemu-kvm ... -net nic,macaddr=MAC,... -net tap,fd=3 3/dev/tap$( /sys/class/net/$1/ifindex) In the bridge-based setup, I use ebtables rules on the tapN port to prevent guests from receiving or emitting packets with the wrong MAC address, and also to prevent them from ARPing for or more generally receiving or emitting packets from IP addresses which don't belong to them. With macvtap, the setup and configuration is nicer and the MAC address restriction is built-in, but there doesn't appear to be a mechanism to apply any other filter, such as that which would be needed to restrict guests to particular IP addresses or from emitting non-IP protocols. On the other hand, the machines using the bridges appear to be much easier to DoS with packet floods than normal linux hosts, presumably because their public-facing interfaces run in promiscuous mode. Macvtap-based hosts with their simple, static configuration seem as immune as normal linux hosts with standard one-eth0-interface networking. Is there a way to get the best of both worlds? I'd love to have the static MAC setup and DoS resistance of macvtap but still be able to apply some basic filter rules, restricting VMs to the handful of ipv4/6 addresses they're entitled to. In the absence of ebtables for macvtap, is there some way I can send packets relating to a macvtap interface through netfilter, in the same way CONFIG_BRIDGE_NETFILTER would do for packets traversing a linux bridge? Best wishes, Chris.
Re: [Qemu-devel] KVM call minutes April 3
On Wed, Apr 04, 2012 at 03:21:26PM +0200, Igor Mammedov wrote: On 04/04/2012 02:14 PM, Michael Roth wrote: On Wed, Apr 04, 2012 at 01:53:34PM +0300, Dor Laor wrote: On 04/04/2012 01:37 PM, Michael Roth wrote: On Apr 4, 2012 2:42 AM, Paolo Bonzinipbonz...@redhat.com mailto:pbonz...@redhat.com wrote: Il 04/04/2012 03:18, Michael Roth ha scritto: Attacking the IDL/schema side first is the more rationale approach. From there we can potentially generate ASN.1 BER/DER visitors for the protocol side, or potentially even just vmstate bindings as a start. I've recently started looking into the latter... it's completely feasible, the only downside is it complicates the IDL due requiring support for a lot of what are very much vmstate-specific items, but it should be possible to do this in a manner where those annotations are self-contained and ignorable if we opted to replace vmstate-style declarations. We can also keep the current vmstate descriptions, but access fields from the automatically-generated visitors instead of struct fields. This keeps the IDL simple. It may be worthwhile as an incremental step though, one nice thing about automatically generated bindings is that with the QIDL Anthony prototyped a while back we assume we serialize by default, so changes in annotated structs automatically trigger changes in the generated bindings unless you explicitly mark fields as immutable/derivable/etc, which we can tie into the build or make check to automatically detect and bring attention to changes in vmstate. This may be worth the effort if we adopt the proposed 4 year migration support cycle for pc-1.0, since that'll continue to rely on vmstate even after we move on to an IDL and newer protocol. Beyond ASL/IDL I like to be sure that we're not just translating one format to other representation but instead we introduce some new functionality like: - Ability to negotiate the protocol version - Bi-direction data exchange, the sender will send data as a function of the target release - Include the machine type too I've been toying with the notion of having the target start up a QMP limited server that the source talks to to orchestrate negotiation. We could potentially even send the device state by taking our QIDL-generated visitors and serializing state via QmpOutputVisitor. QMP can be made aware of the format of the device state input by taking the intermediate step of generating QAPI schemas via QIDL, and using the QAPI code generators to generate the visitors rather than QIDL directly. This would also address the protocol side: just use QMP rather than ASN.1.. It's not as compact, but device state is such a small amount of data compared to memory/disk that I don't think it's worth optimizing that aspect, though we could use compression at the protocol layer if we were inclined. Anything more suited to an out-of-band protocol, like memory/disk, could be orchestrated via this interface... source can ask target for a port to handle such things, negotiate stuff like XBZRLE, etc. - Synchronize the entire qemu cmdline and don't relay on management to set it up. - Along the way, deal w/ hotplug events. My initial plan for the QIDL-generated visitors is to associate a QOM property, state, with each device, and to serialize device state by walking the QOM composition tree, the main rationale being that if we extend that serialization to include other QOM properties, I believe we have everything we need to recreate all the devices on the target: parent-child relationships, types, properties set via cmdline, device state... A simpler alternative would be to leverage just send the cmdline options over to the target and assume that it results in the same underlying machine, then just send off the device state. Much simpler actually...but the above approach should work regardless of changes to the command-line options on the source... having an internally stable cmdline scheme might work as well... Will command line take in account hot-plugged devices? No, that's a good point. We'd probably need to generate the options required to ensure the devices are created on the target, and we'd only be able to do that just before sending the device state. That means we need a way to create machines after we've completed tasks like memory migration, which probably has similar requirements to just being able to instantiate a machine from a serialized QOM composition tree. I'm not sure what the right approach is here but whatever we decide on I think being able to automatically generate visitors from annotations is a good first-step and should tie into any forseeable approaches. Paolo -- - Igor
[Qemu-devel] [PATCH 5/5] Switch compatfd to QEMU thread
qemu_thread_create already does signal blocking and detaching for us.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
compatfd.c | 16 +++-
1 files changed, 3 insertions(+), 13 deletions(-)
diff --git a/compatfd.c b/compatfd.c
index 42f81ca..8d5a63f 100644
--- a/compatfd.c
+++ b/compatfd.c
@@ -14,10 +14,10 @@
*/
#include qemu-common.h
+#include qemu-thread.h
#include compatfd.h
#include sys/syscall.h
-#include pthread.h
struct sigfd_compat_info
{
@@ -28,10 +28,6 @@ struct sigfd_compat_info
static void *sigwait_compat(void *opaque)
{
struct sigfd_compat_info *info = opaque;
-sigset_t all;
-
-sigfillset(all);
-pthread_sigmask(SIG_BLOCK, all, NULL);
while (1) {
int sig;
@@ -71,9 +67,8 @@ static void *sigwait_compat(void *opaque)
static int qemu_signalfd_compat(const sigset_t *mask)
{
-pthread_attr_t attr;
-pthread_t tid;
struct sigfd_compat_info *info;
+QemuThread thread;
int fds[2];
info = malloc(sizeof(*info));
@@ -93,12 +88,7 @@ static int qemu_signalfd_compat(const sigset_t *mask)
memcpy(info-mask, mask, sizeof(*mask));
info-fd = fds[1];
-pthread_attr_init(attr);
-pthread_attr_setdetachstate(attr, PTHREAD_CREATE_DETACHED);
-
-pthread_create(tid, attr, sigwait_compat, info);
-
-pthread_attr_destroy(attr);
+qemu_thread_create(thread, sigwait_compat, info, QEMU_THREAD_DETACHED);
return fds[0];
}
--
1.7.3.4
[Qemu-devel] [PATCH 1/5] Introduce qemu_cond_timedwait for POSIX
First user will be POSIX compat aio. Windows use cases aren't in sight,
so this remains a POSIX-only service for now.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
qemu-thread-posix.c | 23 +++
qemu-thread-posix.h |5 +
2 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/qemu-thread-posix.c b/qemu-thread-posix.c
index 9e1b5fb..cd65df2 100644
--- a/qemu-thread-posix.c
+++ b/qemu-thread-posix.c
@@ -17,6 +17,7 @@
#include signal.h
#include stdint.h
#include string.h
+#include sys/time.h
#include qemu-thread.h
static void error_exit(int err, const char *msg)
@@ -115,6 +116,28 @@ void qemu_cond_wait(QemuCond *cond, QemuMutex *mutex)
error_exit(err, __func__);
}
+/* Returns true if condition was signals, false if timed out. */
+bool qemu_cond_timedwait(QemuCond *cond, QemuMutex *mutex,
+ unsigned int timeout_ms)
+{
+struct timespec ts;
+struct timeval tv;
+int err;
+
+gettimeofday(tv, NULL);
+ts.tv_sec = tv.tv_sec + timeout_ms / 1000;
+ts.tv_nsec = tv.tv_usec * 1000 + timeout_ms % 1000;
+if (ts.tv_nsec 10) {
+ts.tv_sec++;
+ts.tv_nsec -= 10;
+}
+err = pthread_cond_timedwait(cond-cond, mutex-lock, ts);
+if (err err != ETIMEDOUT) {
+error_exit(err, __func__);
+}
+return err == 0;
+}
+
void qemu_thread_create(QemuThread *thread,
void *(*start_routine)(void*),
void *arg, int mode)
diff --git a/qemu-thread-posix.h b/qemu-thread-posix.h
index ee4618e..9f00524 100644
--- a/qemu-thread-posix.h
+++ b/qemu-thread-posix.h
@@ -1,5 +1,6 @@
#ifndef __QEMU_THREAD_POSIX_H
#define __QEMU_THREAD_POSIX_H 1
+#include stdbool.h
#include pthread.h
struct QemuMutex {
@@ -14,4 +15,8 @@ struct QemuThread {
pthread_t thread;
};
+/* only provided for posix so far */
+bool qemu_cond_timedwait(QemuCond *cond, QemuMutex *mutex,
+ unsigned int timeout_ms);
+
#endif
--
1.7.3.4
[Qemu-devel] [PATCH 3/5] Use qemu_eventfd for POSIX AIO
Use qemu_eventfd for signaling POSIX AIO completions. If native eventfd
suport is available, this avoids multiple read accesses to drain
multiple pending signals. As before we use a pipe if eventfd is not
supported.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
posix-aio-compat.c | 12
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/posix-aio-compat.c b/posix-aio-compat.c
index c9b8ebf..7c3ff6e 100644
--- a/posix-aio-compat.c
+++ b/posix-aio-compat.c
@@ -481,7 +481,7 @@ static void posix_aio_read(void *opaque)
PosixAioState *s = opaque;
ssize_t len;
-/* read all bytes from signal pipe */
+/* read all bytes from eventfd or signal pipe */
for (;;) {
char bytes[16];
@@ -506,10 +506,14 @@ static PosixAioState *posix_aio_state;
static void posix_aio_notify_event(void)
{
-char byte = 0;
+/* Write 8 bytes to be compatible with eventfd. */
+static const uint64_t val = 1;
ssize_t ret;
-ret = write(posix_aio_state-wfd, byte, sizeof(byte));
+do {
+ret = write(posix_aio_state-wfd, val, sizeof(val));
+} while (ret 0 errno == EINTR);
+
if (ret 0 errno != EAGAIN)
die(write());
}
@@ -623,7 +627,7 @@ int paio_init(void)
s = g_malloc(sizeof(PosixAioState));
s-first_aio = NULL;
-if (qemu_pipe(fds) == -1) {
+if (qemu_eventfd(fds) == -1) {
fprintf(stderr, failed to create pipe\n);
g_free(s);
return -1;
--
1.7.3.4
[Qemu-devel] [PATCH 2/5] Switch POSIX compat AIO to QEMU abstractions
Although there is nothing to wrap for non-POSIX here, redirecting thread
and synchronization services to our core simplifies managements jobs
like scheduling parameter adjustment. It also frees compat AIO from some
duplicate code (/wrt qemu-thread).
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
posix-aio-compat.c | 118 +++
1 files changed, 35 insertions(+), 83 deletions(-)
diff --git a/posix-aio-compat.c b/posix-aio-compat.c
index d311d13..c9b8ebf 100644
--- a/posix-aio-compat.c
+++ b/posix-aio-compat.c
@@ -15,7 +15,6 @@
#include sys/ioctl.h
#include sys/types.h
-#include pthread.h
#include unistd.h
#include errno.h
#include time.h
@@ -29,9 +28,12 @@
#include qemu-common.h
#include trace.h
#include block_int.h
+#include qemu-thread.h
#include block/raw-posix-aio.h
+#define AIO_THREAD_IDLE_TIMEOUT 1 /* 10 s */
+
static void do_spawn_thread(void);
struct qemu_paiocb {
@@ -59,10 +61,9 @@ typedef struct PosixAioState {
} PosixAioState;
-static pthread_mutex_t lock = PTHREAD_MUTEX_INITIALIZER;
-static pthread_cond_t cond = PTHREAD_COND_INITIALIZER;
-static pthread_t thread_id;
-static pthread_attr_t attr;
+static QemuMutex lock;
+static QemuCond cond;
+static QemuThread thread;
static int max_threads = 64;
static int cur_threads = 0;
static int idle_threads = 0;
@@ -88,39 +89,6 @@ static void die(const char *what)
die2(errno, what);
}
-static void mutex_lock(pthread_mutex_t *mutex)
-{
-int ret = pthread_mutex_lock(mutex);
-if (ret) die2(ret, pthread_mutex_lock);
-}
-
-static void mutex_unlock(pthread_mutex_t *mutex)
-{
-int ret = pthread_mutex_unlock(mutex);
-if (ret) die2(ret, pthread_mutex_unlock);
-}
-
-static int cond_timedwait(pthread_cond_t *cond, pthread_mutex_t *mutex,
- struct timespec *ts)
-{
-int ret = pthread_cond_timedwait(cond, mutex, ts);
-if (ret ret != ETIMEDOUT) die2(ret, pthread_cond_timedwait);
-return ret;
-}
-
-static void cond_signal(pthread_cond_t *cond)
-{
-int ret = pthread_cond_signal(cond);
-if (ret) die2(ret, pthread_cond_signal);
-}
-
-static void thread_create(pthread_t *thread, pthread_attr_t *attr,
- void *(*start_routine)(void*), void *arg)
-{
-int ret = pthread_create(thread, attr, start_routine, arg);
-if (ret) die2(ret, pthread_create);
-}
-
static ssize_t handle_aiocb_ioctl(struct qemu_paiocb *aiocb)
{
int ret;
@@ -313,28 +281,26 @@ static void posix_aio_notify_event(void);
static void *aio_thread(void *unused)
{
-mutex_lock(lock);
+qemu_mutex_lock(lock);
pending_threads--;
-mutex_unlock(lock);
+qemu_mutex_unlock(lock);
do_spawn_thread();
while (1) {
struct qemu_paiocb *aiocb;
-ssize_t ret = 0;
-qemu_timeval tv;
-struct timespec ts;
-
-qemu_gettimeofday(tv);
-ts.tv_sec = tv.tv_sec + 10;
-ts.tv_nsec = 0;
+bool timed_out;
+ssize_t ret;
-mutex_lock(lock);
+qemu_mutex_lock(lock);
-while (QTAILQ_EMPTY(request_list)
- !(ret == ETIMEDOUT)) {
+while (QTAILQ_EMPTY(request_list)) {
idle_threads++;
-ret = cond_timedwait(cond, lock, ts);
+timed_out = !qemu_cond_timedwait(cond, lock,
+ AIO_THREAD_IDLE_TIMEOUT);
idle_threads--;
+if (timed_out) {
+break;
+}
}
if (QTAILQ_EMPTY(request_list))
@@ -343,7 +309,7 @@ static void *aio_thread(void *unused)
aiocb = QTAILQ_FIRST(request_list);
QTAILQ_REMOVE(request_list, aiocb, node);
aiocb-active = 1;
-mutex_unlock(lock);
+qemu_mutex_unlock(lock);
switch (aiocb-aio_type QEMU_AIO_TYPE_MASK) {
case QEMU_AIO_READ:
@@ -375,41 +341,33 @@ static void *aio_thread(void *unused)
break;
}
-mutex_lock(lock);
+qemu_mutex_lock(lock);
aiocb-ret = ret;
-mutex_unlock(lock);
+qemu_mutex_unlock(lock);
posix_aio_notify_event();
}
cur_threads--;
-mutex_unlock(lock);
+qemu_mutex_unlock(lock);
return NULL;
}
static void do_spawn_thread(void)
{
-sigset_t set, oldset;
-
-mutex_lock(lock);
+qemu_mutex_lock(lock);
if (!new_threads) {
-mutex_unlock(lock);
+qemu_mutex_unlock(lock);
return;
}
new_threads--;
pending_threads++;
-mutex_unlock(lock);
+qemu_mutex_unlock(lock);
-/* block all signals */
-if (sigfillset(set)) die(sigfillset);
-if (sigprocmask(SIG_SETMASK, set, oldset)) die(sigprocmask);
-
-thread_create(thread_id, attr, aio_thread, NULL);
-
-if (sigprocmask(SIG_SETMASK, oldset, NULL)) die(sigprocmask restore);
+qemu_thread_create(thread, aio_thread, NULL, QEMU_THREAD_DETACHED);
}
static void
[Qemu-devel] [Xen-devel] [PATCH v2] qemu/configure: fix CFLAGS handling for i386
Olaf Hering writes ([Xen-devel] [PATCH v2] qemu/configure: fix CFLAGS handling for i386): configure will generate incorrect CFLAGS which will lead to compile errors due to unknown gcc options, iff CFLAGS was already in the environment during configure invocation. Don't do that then. In general, CFLAGS is not a variable you can safely set in your environment when invoking a nonconsenting build system. Ian.
Re: [Qemu-devel] [PATCH 0/5] Spread the use of QEMU threading locking API
Il 04/04/2012 17:08, Jan Kiszka ha scritto: Refreshed versions of some cleanups I already sent last year. See patches for details. Patches 1, 2 and 5 are fine. I had an alternative implementation using a counting semaphore instead of the condition variable (which would work on Windows too), but I can rebase later if ever. For patches 3 and 4, I'd rather use an EventNotifier... Paolo The series also helps using different scheduling policies for QEMU threads which includes hardening internal locks. Jan Kiszka (5): Introduce qemu_cond_timedwait for POSIX Switch POSIX compat AIO to QEMU abstractions Use qemu_eventfd for POSIX AIO Reorder POSIX compat AIO code Switch compatfd to QEMU thread compatfd.c | 16 + posix-aio-compat.c | 162 +-- qemu-thread-posix.c | 23 +++ qemu-thread-posix.h |5 ++ 4 files changed, 84 insertions(+), 122 deletions(-)
Re: [Qemu-devel] [Qemu-ppc] [PATCH 1/3] pseries: Clean up hcall_dprintf() debugging messages
Am 28.03.2012 23:39, schrieb David Gibson: The pseries machine code has a number of debug messages for debugging PAPR hypercalls, dependent on DEBUG_SPAPR_HCALLS. This patch cleans these messages up a bit, by adding __func__ to the hcall_dprintf() macro and simplifying up a number of the individual messages accordingly. Signed-off-by: David Gibson da...@gibson.dropbear.id.au Conflicts: hw/spapr_vio.c --- Thanks, that cleanup went beyond what I expected for what-is-now-2/3. Applied to ppc-next: http://repo.or.cz/w/qemu/agraf.git/shortlog/refs/heads/ppc-next Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [PATCH 00/14] configure: --with-confsuffix option
Il 30/03/2012 19:32, Eduardo Habkost ha scritto: This series is the third version of the --confsuffix/--confdir changes I have submitted before. Now it does two interface changes: - Changes --datadir meaning to match Autoconf convention (meaning that it should point to /usr/share, not /usr/share/qemu). NOTE: this breaks compatibility. I don't know of anybody who uses that option today. Neither Fedora, Debian, Arch Linux, Gentoo, or FreeBSD use it[1]. - Add --with-confsuffix option, to allow the /etc/qemu and /usr/share/qemu directories to have a different names. [1] http://article.gmane.org/gmane.comp.emulators.qemu/142924 Most of the patches are variable renames and cleanups. The actual changes are only on the last 2 patches. First, internal configure variables are renamed, without changing config-host.mak: configure: rename $datadir to $qemu_datadir configure: rename $docdir to $qemu_docdir configure: rename $confdir to $qemu_confdir Then create_config gets ready for config-host.mak variable renames (Qemu-specific directories will now have a qemu_ prefix): create_config: separate section for qemu_*dir variables Then, variables are renamed on config-host.mak and Makefiles: config-host.mak: rename datadir to qemu_datadir config-host.mak: rename confdir to qemu_confdir Makefile: use $(qemu_confdir) instead of $(sysconfdir)/qemu config-host.mak: rename docdir to qemu_docdir config-host.mak: remove CONFIG_QEMU_SHAREDIR config-host.mak: reorder variables a bit Then old code on create_config is removed: create_config: remove *dir block create_config: simplify prefix=* block, remove CONFIG_QEMU_PREFIX Finally, the user-visible changes: configure: change meaning of --datadir to Autoconf convention configure: add --confsuffix option Eduardo Habkost (14): configure: rename $datadir to $qemu_datadir configure: rename $docdir to $qemu_docdir configure: rename $confdir to $qemu_confdir create_config: separate section for qemu_*dir variables config-host.mak: rename datadir to qemu_datadir config-host.mak: rename confdir to qemu_confdir Makefile: use $(qemu_confdir) instead of $(sysconfdir)/qemu config-host.mak: rename docdir to qemu_docdir config-host.mak: remove CONFIG_QEMU_SHAREDIR config-host.mak: reorder variables a bit create_config: remove *dir block create_config: simplify prefix=* block, remove CONFIG_QEMU_PREFIX configure: change meaning of --datadir to Autoconf convention configure: add --confsuffix option Makefile | 16 Makefile.target |4 ++-- configure | 29 - scripts/create_config |8 ++-- 4 files changed, 32 insertions(+), 25 deletions(-) Reviewed-by: Paolo Bonzini pbonz...@redhat.com
Re: [Qemu-devel] [Xen-devel] [PATCH v2] qemu/configure: fix CFLAGS handling for i386
On 4 April 2012 16:16, Ian Jackson ian.jack...@eu.citrix.com wrote: Olaf Hering writes ([Xen-devel] [PATCH v2] qemu/configure: fix CFLAGS handling for i386): configure will generate incorrect CFLAGS which will lead to compile errors due to unknown gcc options, iff CFLAGS was already in the environment during configure invocation. Don't do that then. In general, CFLAGS is not a variable you can safely set in your environment when invoking a nonconsenting build system. Yes. You probably wanted configure's --extra-cflags option. However that doesn't mean the code in configure at the moment is actually right... Having looked at configure I'm pretty sure what we want here is QEMU_CFLAGS=-march=i486 $QEMU_CFLAGS because we're only doing this for the benefit of a particular bit of code in hw/vhost.c and so QEMU_CFLAGS is sufficient. Also this brings it into line with other places where we add a -march flag, which use QEMU_CFLAGS, not CFLAGS. -- PMM
Re: [Qemu-devel] [PATCH 0/5] Spread the use of QEMU threading locking API
On 2012-04-04 17:18, Paolo Bonzini wrote: Il 04/04/2012 17:08, Jan Kiszka ha scritto: Refreshed versions of some cleanups I already sent last year. See patches for details. Patches 1, 2 and 5 are fine. I had an alternative implementation using a counting semaphore instead of the condition variable (which would work on Windows too), but I can rebase later if ever. For patches 3 and 4, I'd rather use an EventNotifier... ...which still lacks support for non-eventfd systems. Hmm, I guess it's time to consolidate both. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
Re: [Qemu-devel] [PATCH] Memory: unify ioport registration
On 04/03/2012 08:51 AM, Avi Kivity wrote: On 04/02/2012 05:37 PM, Julien Grall wrote: s = g_malloc0(sizeof(SerialState)); @@ -820,8 +828,9 @@ SerialState *serial_init(int base, qemu_irq irq, int baudbase, vmstate_register(NULL, base,vmstate_serial, s); -register_ioport_write(base, 8, 1, serial_ioport_write, s); -register_ioport_read(base, 8, 1, serial_ioport_read, s); +portio_list_init(serial_port_list, serial_portio_list, s, serial-io); +portio_list_add(serial_port_list, get_system_io(), base); + Should we just remove serial_init() and replace it with the serial-isa QOM class? After few researchs, it's seems this function is not used in the source code. Is that right ?
[Qemu-devel] [PATCH 09/13] hw/arm11mpcore: Convert to using sysbus GIC device
Convert arm11mpcore to using the standalone sysbus GIC device.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
hw/arm11mpcore.c | 49 ++---
1 files changed, 30 insertions(+), 19 deletions(-)
diff --git a/hw/arm11mpcore.c b/hw/arm11mpcore.c
index e876a0e..c528d7a 100644
--- a/hw/arm11mpcore.c
+++ b/hw/arm11mpcore.c
@@ -10,21 +10,18 @@
#include sysbus.h
#include qemu-timer.h
-#define LEGACY_INCLUDED_GIC
-#include arm_gic.c
-
/* MPCore private memory region. */
typedef struct mpcore_priv_state {
-gic_state gic;
+SysBusDevice busdev;
uint32_t scu_control;
int iomemtype;
uint32_t old_timer_status[8];
uint32_t num_cpu;
-qemu_irq *timer_irq;
MemoryRegion iomem;
MemoryRegion container;
DeviceState *mptimer;
+DeviceState *gic;
uint32_t num_irq;
} mpcore_priv_state;
@@ -74,18 +71,16 @@ static const MemoryRegionOps mpcore_scu_ops = {
.endianness = DEVICE_NATIVE_ENDIAN,
};
-static void mpcore_timer_irq_handler(void *opaque, int irq, int level)
+static void mpcore_priv_set_irq(void *opaque, int irq, int level)
{
mpcore_priv_state *s = (mpcore_priv_state *)opaque;
-if (level !s-old_timer_status[irq]) {
-gic_set_pending_private(s-gic, irq 1, 29 + (irq 1));
-}
-s-old_timer_status[irq] = level;
+qemu_set_irq(qdev_get_gpio_in(s-gic, irq), level);
}
static void mpcore_priv_map_setup(mpcore_priv_state *s)
{
int i;
+SysBusDevice *gicbusdev = sysbus_from_qdev(s-gic);
SysBusDevice *busdev = sysbus_from_qdev(s-mptimer);
memory_region_init(s-container, mpcode-priv-container, 0x2000);
memory_region_init_io(s-iomem, mpcore_scu_ops, s, mpcore-scu, 0x100);
@@ -95,31 +90,47 @@ static void mpcore_priv_map_setup(mpcore_priv_state *s)
*/
for (i = 0; i (s-num_cpu + 1); i++) {
target_phys_addr_t offset = 0x100 + (i * 0x100);
-memory_region_add_subregion(s-container, offset,
s-gic.cpuiomem[i]);
+memory_region_add_subregion(s-container, offset,
+sysbus_mmio_get_region(gicbusdev, i + 1));
}
/* Add the regions for timer and watchdog for current CPU and
* for each specific CPU.
*/
-s-timer_irq = qemu_allocate_irqs(mpcore_timer_irq_handler,
- s, (s-num_cpu + 1) * 2);
for (i = 0; i (s-num_cpu + 1) * 2; i++) {
/* Timers at 0x600, 0x700, ...; watchdogs at 0x620, 0x720, ... */
target_phys_addr_t offset = 0x600 + (i 1) * 0x100 + (i 1) * 0x20;
memory_region_add_subregion(s-container, offset,
sysbus_mmio_get_region(busdev, i));
}
-memory_region_add_subregion(s-container, 0x1000, s-gic.iomem);
-/* Wire up the interrupt from each watchdog and timer. */
-for (i = 0; i s-num_cpu * 2; i++) {
-sysbus_connect_irq(busdev, i, s-timer_irq[i]);
+memory_region_add_subregion(s-container, 0x1000,
+sysbus_mmio_get_region(gicbusdev, 0));
+/* Wire up the interrupt from each watchdog and timer.
+ * For each core the timer is PPI 29 and the watchdog PPI 30.
+ */
+for (i = 0; i s-num_cpu; i++) {
+int ppibase = (s-num_irq - 32) + i * 32;
+sysbus_connect_irq(busdev, i * 2,
+ qdev_get_gpio_in(s-gic, ppibase + 29));
+sysbus_connect_irq(busdev, i * 2 + 1,
+ qdev_get_gpio_in(s-gic, ppibase + 30));
}
}
static int mpcore_priv_init(SysBusDevice *dev)
{
-mpcore_priv_state *s = FROM_SYSBUSGIC(mpcore_priv_state, dev);
+mpcore_priv_state *s = FROM_SYSBUS(mpcore_priv_state, dev);
+
+s-gic = qdev_create(NULL, arm_gic);
+qdev_prop_set_uint32(s-gic, num-cpu, s-num_cpu);
+qdev_prop_set_uint32(s-gic, num-irq, s-num_irq);
+qdev_init_nofail(s-gic);
+
+/* Pass through outbound IRQ lines from the GIC */
+sysbus_pass_irq(dev, sysbus_from_qdev(s-gic));
+
+/* Pass through inbound GPIO lines to the GIC */
+qdev_init_gpio_in(s-busdev.qdev, mpcore_priv_set_irq, s-num_irq - 32);
-gic_init(s-gic, s-num_cpu, s-num_irq);
s-mptimer = qdev_create(NULL, arm_mptimer);
qdev_prop_set_uint32(s-mptimer, num-cpu, s-num_cpu);
qdev_init_nofail(s-mptimer);
--
1.7.1
[Qemu-devel] [PATCH 03/13] hw/arm_gic.c: Expose PPI inputs as gpio inputs
Expose the Private Peripheral Interrupt inputs as GPIO inputs.
The layout of the GPIO array is thus:
[0..N-1] SPIs
[N..N+31] PPIs for CPU 0
[N+32..N+63] PPIs for CPU 1
...
Treating PPIs as being another kind of input line is in line with the
GIC architecture specification, where they are clearly described that
way. The 11MPCore TRM is a bit more ambiguous, but there is no practical
difference between set PPI X as pending and 0-1 transition on a
PPI input line configured as edge triggered, and PPIs are always
edge triggered, so this change won't affect behaviour.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
hw/arm_gic.c | 49 -
1 files changed, 40 insertions(+), 9 deletions(-)
diff --git a/hw/arm_gic.c b/hw/arm_gic.c
index df1a34b..fabbcc5 100644
--- a/hw/arm_gic.c
+++ b/hw/arm_gic.c
@@ -192,20 +192,40 @@ gic_set_pending_private(gic_state *s, int cpu, int irq)
/* Process a change in an external IRQ input. */
static void gic_set_irq(void *opaque, int irq, int level)
{
+/* Meaning of the 'irq' parameter:
+ * [0..N-1] : external interrupts
+ * [N..N+31] : PPI (internal) interrupts for CPU 0
+ * [N+32..N+63] : PPI (internal interrupts for CPU 1
+ * ...
+ */
gic_state *s = (gic_state *)opaque;
-/* The first external input line is internal interrupt 32. */
-irq += GIC_INTERNAL;
-if (level == GIC_TEST_LEVEL(irq, ALL_CPU_MASK))
+int cm, target;
+if (irq (s-num_irq - GIC_INTERNAL)) {
+/* The first external input line is internal interrupt 32. */
+cm = ALL_CPU_MASK;
+irq += GIC_INTERNAL;
+target = GIC_TARGET(irq);
+} else {
+int cpu;
+irq -= (s-num_irq - GIC_INTERNAL);
+cpu = irq / GIC_INTERNAL;
+irq %= GIC_INTERNAL;
+cm = 1 cpu;
+target = cm;
+}
+
+if (level == GIC_TEST_LEVEL(irq, cm)) {
return;
+}
if (level) {
-GIC_SET_LEVEL(irq, ALL_CPU_MASK);
-if (GIC_TEST_TRIGGER(irq) || GIC_TEST_ENABLED(irq, ALL_CPU_MASK)) {
-DPRINTF(Set %d pending mask %x\n, irq, GIC_TARGET(irq));
-GIC_SET_PENDING(irq, GIC_TARGET(irq));
+GIC_SET_LEVEL(irq, cm);
+if (GIC_TEST_TRIGGER(irq) || GIC_TEST_ENABLED(irq, cm)) {
+DPRINTF(Set %d pending mask %x\n, irq, target);
+GIC_SET_PENDING(irq, target);
}
} else {
-GIC_CLEAR_LEVEL(irq, ALL_CPU_MASK);
+GIC_CLEAR_LEVEL(irq, cm);
}
gic_update(s);
}
@@ -849,7 +869,18 @@ static void gic_init(gic_state *s, int num_irq)
num_irq);
}
-qdev_init_gpio_in(s-busdev.qdev, gic_set_irq, s-num_irq - GIC_INTERNAL);
+i = s-num_irq - GIC_INTERNAL;
+#ifndef NVIC
+/* For the GIC, also expose incoming GPIO lines for PPIs for each CPU.
+ * GPIO array layout is thus:
+ * [0..N-1] SPIs
+ * [N..N+31] PPIs for CPU 0
+ * [N+32..N+63] PPIs for CPU 1
+ * ...
+ */
+i += (GIC_INTERNAL * num_cpu);
+#endif
+qdev_init_gpio_in(s-busdev.qdev, gic_set_irq, i);
for (i = 0; i NUM_CPU(s); i++) {
sysbus_init_irq(s-busdev, s-parent_irq[i]);
}
--
1.7.1
[Qemu-devel] [PATCH 01/13] hw/arm_gic: Move NCPU definition to arm_gic.c
Move the NCPU definition to arm_gic.c: the maximum number
of CPU interfaces is defined by the GIC architecture specification
to be 8, so we don't need to have this #define in each of the
sources files which currently includes arm_gic.c.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
hw/a15mpcore.c |8 +---
hw/a9mpcore.c |8 +---
hw/arm11mpcore.c|2 --
hw/arm_gic.c| 13 -
hw/armv7m_nvic.c|1 -
hw/exynos4210_gic.c |9 -
hw/realview_gic.c |4 +---
7 files changed, 19 insertions(+), 26 deletions(-)
diff --git a/hw/a15mpcore.c b/hw/a15mpcore.c
index 71142e5..67206ec 100644
--- a/hw/a15mpcore.c
+++ b/hw/a15mpcore.c
@@ -21,10 +21,8 @@
#include sysbus.h
/* Configuration for arm_gic.c:
- * max number of CPUs, how to ID current CPU
+ * how to ID current CPU
*/
-#define NCPU 4
-
static inline int gic_get_current_cpu(void)
{
return cpu_single_env-cpu_index;
@@ -45,10 +43,6 @@ static int a15mp_priv_init(SysBusDevice *dev)
{
A15MPPrivState *s = FROM_SYSBUSGIC(A15MPPrivState, dev);
-if (s-num_cpu NCPU) {
-hw_error(a15mp_priv_init: num-cpu may not be more than %d\n, NCPU);
-}
-
gic_init(s-gic, s-num_cpu, s-num_irq);
/* Memory map (addresses are offsets from PERIPHBASE):
diff --git a/hw/a9mpcore.c b/hw/a9mpcore.c
index 03b128c..5bbe3c7 100644
--- a/hw/a9mpcore.c
+++ b/hw/a9mpcore.c
@@ -11,10 +11,8 @@
#include sysbus.h
/* Configuration for arm_gic.c:
- * max number of CPUs, how to ID current CPU
+ * how to ID current CPU
*/
-#define NCPU 4
-
static inline int
gic_get_current_cpu(void)
{
@@ -149,10 +147,6 @@ static int a9mp_priv_init(SysBusDevice *dev)
SysBusDevice *busdev;
int i;
-if (s-num_cpu NCPU) {
-hw_error(a9mp_priv_init: num-cpu may not be more than %d\n, NCPU);
-}
-
gic_init(s-gic, s-num_cpu, s-num_irq);
s-mptimer = qdev_create(NULL, arm_mptimer);
diff --git a/hw/arm11mpcore.c b/hw/arm11mpcore.c
index ba6a89d..99c1826 100644
--- a/hw/arm11mpcore.c
+++ b/hw/arm11mpcore.c
@@ -10,8 +10,6 @@
#include sysbus.h
#include qemu-timer.h
-#define NCPU 4
-
static inline int
gic_get_current_cpu(void)
{
diff --git a/hw/arm_gic.c b/hw/arm_gic.c
index 6b34c06..f64a001 100644
--- a/hw/arm_gic.c
+++ b/hw/arm_gic.c
@@ -15,6 +15,13 @@
#define GIC_MAXIRQ 1020
/* First 32 are private to each CPU (SGIs and PPIs). */
#define GIC_INTERNAL 32
+/* Maximum number of possible CPU interfaces, determined by GIC architecture */
+#ifdef NVIC
+#define NCPU 1
+#else
+#define NCPU 8
+#endif
+
//#define DEBUG_GIC
#ifdef DEBUG_GIC
@@ -50,7 +57,7 @@ typedef struct gic_irq_state
unsigned trigger:1; /* nonzero = edge triggered. */
} gic_irq_state;
-#define ALL_CPU_MASK ((1 NCPU) - 1)
+#define ALL_CPU_MASK ((unsigned)(((1 NCPU) - 1)))
#if NCPU 1
#define NUM_CPU(s) ((s)-num_cpu)
#else
@@ -813,6 +820,10 @@ static void gic_init(gic_state *s, int num_irq)
#if NCPU 1
s-num_cpu = num_cpu;
+if (s-num_cpu NCPU) {
+hw_error(requested %u CPUs exceeds GIC maximum %d\n,
+ num_cpu, NCPU);
+}
#endif
s-num_irq = num_irq + GIC_BASE_IRQ;
if (s-num_irq GIC_MAXIRQ) {
diff --git a/hw/armv7m_nvic.c b/hw/armv7m_nvic.c
index 3210129..bdab709 100644
--- a/hw/armv7m_nvic.c
+++ b/hw/armv7m_nvic.c
@@ -15,7 +15,6 @@
#include arm-misc.h
#include exec-memory.h
-#define NCPU 1
#define NVIC 1
/* Only a single CPU interface is present. */
diff --git a/hw/exynos4210_gic.c b/hw/exynos4210_gic.c
index 3ba9063..426f540 100644
--- a/hw/exynos4210_gic.c
+++ b/hw/exynos4210_gic.c
@@ -174,7 +174,6 @@
combiner_grp_to_gic_id[64-EXYNOS4210_MAX_EXT_COMBINER_OUT_IRQ][8] = {
};
#define EXYNOS4210_GIC_NIRQ 160
-#define NCPUEXYNOS4210_NCPUS
#define EXYNOS4210_EXT_GIC_CPU_REGION_SIZE 0x1
#define EXYNOS4210_EXT_GIC_DIST_REGION_SIZE0x1
@@ -275,8 +274,8 @@ typedef struct {
gic_state gic;
MemoryRegion cpu_container;
MemoryRegion dist_container;
-MemoryRegion cpu_alias[NCPU];
-MemoryRegion dist_alias[NCPU];
+MemoryRegion cpu_alias[EXYNOS4210_NCPUS];
+MemoryRegion dist_alias[EXYNOS4210_NCPUS];
uint32_t num_cpu;
} Exynos4210GicState;
@@ -359,7 +358,7 @@ type_init(exynos4210_gic_register_types)
typedef struct {
SysBusDevice busdev;
-qemu_irq pic_irq[NCPU]; /* output IRQs to PICs */
+qemu_irq pic_irq[EXYNOS4210_NCPUS]; /* output IRQs to PICs */
uint32_t gpio_level[EXYNOS4210_IRQ_GATE_NINPUTS]; /* Input levels */
} Exynos4210IRQGateState;
@@ -424,7 +423,7 @@ static int exynos4210_irq_gate_init(SysBusDevice *dev)
EXYNOS4210_IRQ_GATE_NINPUTS);
/* Connect SysBusDev irqs to device specific irqs */
-for (i = 0; i NCPU; i++) {
+for (i = 0; i EXYNOS4210_NCPUS; i++) {
sysbus_init_irq(dev, s-pic_irq[i]);
}
diff --git a/hw/realview_gic.c b/hw/realview_gic.c
index 071ef13..d114242 100644
---
[Qemu-devel] [PATCH] configure: Remove useless uses of ARCH_CFLAGS
Remove some useless uses of ARCH_CFLAGS -- this variable was never set so will always be empty. The uses were accidental: in commit 0c439cbf8 Juan Quintela removed ARCH_CFLAGS in favour of CFLAGS (which in turn became QEMU_CFLAGS). However in commit be17dc90 a use of it was reintroduced (apparently accidentally) by Michael S. Tsirkin, and then I subsequently cut-n-pasted that into a number of other configure feature tests. Signed-off-by: Peter Maydell peter.mayd...@linaro.org --- configure | 12 ++-- 1 files changed, 6 insertions(+), 6 deletions(-) diff --git a/configure b/configure index 4b3adc9..80a3e8d 100755 --- a/configure +++ b/configure @@ -2361,7 +2361,7 @@ int main(void) return 0; } EOF -if compile_prog $ARCH_CFLAGS ; then +if compile_prog ; then fallocate=yes fi @@ -2376,7 +2376,7 @@ int main(void) return 0; } EOF -if compile_prog $ARCH_CFLAGS ; then +if compile_prog ; then sync_file_range=yes fi @@ -2393,7 +2393,7 @@ int main(void) return 0; } EOF -if compile_prog $ARCH_CFLAGS ; then +if compile_prog ; then fiemap=yes fi @@ -2423,7 +2423,7 @@ int main(void) return 0; } EOF -if compile_prog $ARCH_CFLAGS ; then +if compile_prog ; then epoll=yes fi @@ -2446,7 +2446,7 @@ int main(void) return epoll_create1 == epoll_create1; } EOF -if compile_prog $ARCH_CFLAGS ; then +if compile_prog ; then epoll_create1=yes fi @@ -2460,7 +2460,7 @@ int main(void) return 0; } EOF -if compile_prog $ARCH_CFLAGS ; then +if compile_prog ; then epoll_pwait=yes fi -- 1.7.1
Re: [Qemu-devel] [PATCH 0/5] Spread the use of QEMU threading locking API
On 2012-04-04 17:29, Paolo Bonzini wrote: Il 04/04/2012 17:24, Jan Kiszka ha scritto: For patches 3 and 4, I'd rather use an EventNotifier... ...which still lacks support for non-eventfd systems. Hmm, I guess it's time to consolidate both. Perhaps you can take the relevant patches out of the thread-blocks branch at git://github.com/pbonzini/qemu.git? The iothread eventfd could also use an EventNotifier. Yep, this screams for something like QemuEvent which pleases all users of current qemu_eventfd and EventNotifier - and fit into the existing threading/synchronization abstraction layout. I retract patches 34, will be done on top of the event rework. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
Re: [Qemu-devel] [PATCH 14/14] configure: add --confsuffix option
Il 30/03/2012 19:33, Eduardo Habkost ha scritto: This will allow the user to make Qemu use a different subdirectory name inside $datadir and $sysconfdir, instead of /qemu. Signed-off-by: Eduardo Habkost ehabk...@redhat.com --- configure |9 ++--- 1 files changed, 6 insertions(+), 3 deletions(-) diff --git a/configure b/configure index b74efe2..e56c569 100755 --- a/configure +++ b/configure @@ -591,6 +591,8 @@ for opt do ;; --datadir=*) datadir=$optarg ;; + --with-confsuffix=*) confsuffix=$optarg + ;; --docdir=*) qemu_docdir=$optarg ;; --sysconfdir=*) sysconfdir=$optarg @@ -1007,10 +1009,11 @@ echo --python=PYTHON use specified python [$python] echo --smbd=SMBD use specified smbd [$smbd] echo --static enable static build [$static] echo --mandir=PATHinstall man pages in PATH -echo --datadir=PATH install firmware in PATH/qemu -echo --docdir=PATHinstall documentation in PATH +echo --datadir=PATH install firmware in PATH$confsuffix +echo --docdir=PATHinstall documentation in PATH$confsuffix echo --bindir=PATHinstall binaries in PATH -echo --sysconfdir=PATHinstall config in PATH/qemu +echo --sysconfdir=PATHinstall config in PATH$confsuffix +echo --with-confsuffix=SUFFIX suffix for Qemu data inside datadir and sysconfdir [$confsuffix] echo --enable-debug-tcg enable TCG debugging echo --disable-debug-tcg disable TCG debugging (default) echo --enable-debug enable common debug build options The subject was not adjusted, perhaps you can send a v2 of this patch only? Paolo
Re: [Qemu-devel] [Xen-devel] [PATCH v2] qemu/configure: fix CFLAGS handling for i386
On 4 April 2012 16:40, Peter Maydell peter.mayd...@linaro.org wrote: Having looked at configure I'm pretty sure what we want here is QEMU_CFLAGS=-march=i486 $QEMU_CFLAGS because we're only doing this for the benefit of a particular bit of code in hw/vhost.c and so QEMU_CFLAGS is sufficient. Also this brings it into line with other places where we add a -march flag, which use QEMU_CFLAGS, not CFLAGS. ...and having dug around in the git history we find that QEMU_CFLAGS were introduced in commit a558ee1, whose commit message defines the difference like this: QEMU_CFLAGS: flags without which we can't compile CFLAGS: -g -O2 -march=i486 is clearly flags without which we can't compile, so we should be setting it in QEMU_CFLAGS, not CFLAGS. Olaf, if you want to submit a fixed patch I think we should apply it to upstream qemu. PS: remarks like This patch is against the qemu-xen tree, but it should apply also to qemu.git since it has the same issue. Please apply to both trees. should go below the '---' in a patch email so they don't appear in the git commit message when the patch is applied. thanks -- PMM
Re: [Qemu-devel] [PATCH 14/14] configure: add --confsuffix option
On Wed, Apr 04, 2012 at 05:26:10PM +0200, Paolo Bonzini wrote: Il 30/03/2012 19:33, Eduardo Habkost ha scritto: [...] -echo --sysconfdir=PATHinstall config in PATH/qemu +echo --sysconfdir=PATHinstall config in PATH$confsuffix +echo --with-confsuffix=SUFFIX suffix for Qemu data inside datadir and sysconfdir [$confsuffix] echo --enable-debug-tcg enable TCG debugging echo --disable-debug-tcg disable TCG debugging (default) echo --enable-debug enable common debug build options The subject was not adjusted, perhaps you can send a v2 of this patch only? Yes, I will do. -- Eduardo
Re: [Qemu-devel] [PATCH 2/3] pseries: Fix bug with reset of VIO CRQs
Am 28.03.2012 23:39, schrieb David Gibson:
PAPR specifies a Command Response Queue (CRQ) mechanism used for virtual
IO, which we implement. However, we don't correctly clean up registered
CRQs when we reset the system.
This patch adds a reset handler to fix this bug. While we're at it, add
in some of the extra debug messages that were used to track the problem
down.
Signed-off-by: David Gibson da...@gibson.dropbear.id.au
---
As discussed on IRC, I've applied the following diff on my local branch
to drop the h_reg_crq that my __func__ comment was about:
diff --git a/hw/spapr_vio.c b/hw/spapr_vio.c
index 0bf2c31..97d029a 100644
--- a/hw/spapr_vio.c
+++ b/hw/spapr_vio.c
@@ -431,13 +431,13 @@ static target_ulong h_reg_crq(CPUPPCState *env,
sPAPREnvironment *spapr,
/* Check if device supports CRQs */
if (!dev-crq.SendFunc) {
-hcall_dprintf(Device does not support CRQ\n);
+hcall_dprintf(h_reg_crq, device does not support CRQ\n);
return H_NOT_FOUND;
}
/* Already a queue ? */
if (dev-crq.qsize) {
-hcall_dprintf(CRQ already registered\n);
+hcall_dprintf(h_reg_crq, CRQ already registered\n);
return H_RESOURCE;
}
dev-crq.qladdr = queue_addr;
However, I'm having trouble testing reset. Whether on vanilla master or
using this patch on top of ppc-next or this whole series on top of
ppc-next, using `ppc64-softmmu/qemu-system-ppc64 -M pseries -m 1G`:
a) 0 reset-all
results in: reboot not available Aborted
Do you need to update SLOF to actually use the newly added RTAS call?
b) (qemu) system_reset
results in:
exception 700
SRR0 = SRR1 = 80008008
SPRG2 = SPRG3 = 3DCD1AD4
Could you please look into the two above issues? How did you test?
Thanks,
Andreas
hw/spapr_vio.c | 33 +
1 files changed, 25 insertions(+), 8 deletions(-)
diff --git a/hw/spapr_vio.c b/hw/spapr_vio.c
index 1f67e64..97d029a 100644
--- a/hw/spapr_vio.c
+++ b/hw/spapr_vio.c
@@ -431,12 +431,13 @@ static target_ulong h_reg_crq(CPUPPCState *env,
sPAPREnvironment *spapr,
/* Check if device supports CRQs */
if (!dev-crq.SendFunc) {
+hcall_dprintf(h_reg_crq, device does not support CRQ\n);
return H_NOT_FOUND;
}
-
/* Already a queue ? */
if (dev-crq.qsize) {
+hcall_dprintf(h_reg_crq, CRQ already registered\n);
return H_RESOURCE;
}
dev-crq.qladdr = queue_addr;
@@ -449,6 +450,17 @@ static target_ulong h_reg_crq(CPUPPCState *env,
sPAPREnvironment *spapr,
return H_SUCCESS;
}
+static target_ulong free_crq(VIOsPAPRDevice *dev)
+{
+dev-crq.qladdr = 0;
+dev-crq.qsize = 0;
+dev-crq.qnext = 0;
+
+dprintf(CRQ for dev 0x% PRIx32 freed\n, dev-reg);
+
+return H_SUCCESS;
+}
+
static target_ulong h_free_crq(CPUPPCState *env, sPAPREnvironment *spapr,
target_ulong opcode, target_ulong *args)
{
@@ -460,13 +472,7 @@ static target_ulong h_free_crq(CPUPPCState *env,
sPAPREnvironment *spapr,
return H_PARAMETER;
}
-dev-crq.qladdr = 0;
-dev-crq.qsize = 0;
-dev-crq.qnext = 0;
-
-dprintf(CRQ for dev 0x TARGET_FMT_lx freed\n, reg);
-
-return H_SUCCESS;
+return free_crq(dev);
}
static target_ulong h_send_crq(CPUPPCState *env, sPAPREnvironment *spapr,
@@ -642,6 +648,15 @@ static int spapr_vio_check_reg(VIOsPAPRDevice *sdev)
return 0;
}
+static void spapr_vio_busdev_reset(void *opaque)
+{
+VIOsPAPRDevice *dev = (VIOsPAPRDevice *)opaque;
+
+if (dev-crq.qsize) {
+free_crq(dev);
+}
+}
+
static int spapr_vio_busdev_init(DeviceState *qdev)
{
VIOsPAPRDevice *dev = (VIOsPAPRDevice *)qdev;
@@ -670,6 +685,8 @@ static int spapr_vio_busdev_init(DeviceState *qdev)
rtce_init(dev);
+qemu_register_reset(spapr_vio_busdev_reset, dev);
+
return pc-init(dev);
}
--
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 V3 0/7] Make QED with live migration safe
I tested qed live migration as well as confirming that bs-open_flags BDRV_O_INCOMING works correctly in gdb. Reviewed-by: Stefan Hajnoczi stefa...@gmail.com ping. Kevin Wolf: will it be merged in your next for-anthony branch ?
Re: [Qemu-devel] [PATCH] Support system reset in Exynos4210
04.04.2012 16:35, Dmitry Zhurikhin пишет:
On 2012-04-04 15:55, Maksim Kozlov wrote:
04.04.2012 14:08, Dmitry Zhurikhin пишет:
Reset the system when 1 is written to SWRESET register
Signed-off-by: Dmitry Zhurikhinz...@ispras.ru
---
hw/exynos4210_pmu.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/hw/exynos4210_pmu.c b/hw/exynos4210_pmu.c
index c12d750..edf6e34 100644
--- a/hw/exynos4210_pmu.c
+++ b/hw/exynos4210_pmu.c
@@ -25,6 +25,7 @@
*/
#include sysbus.h
+#include sysemu.h
#ifndef DEBUG_PMU
#define DEBUG_PMU 0
@@ -422,6 +423,16 @@ static void exynos4210_pmu_write(void *opaque,
target_phys_addr_t offset,
if (reg_p-offset == offset) {
PRINT_DEBUG_EXTEND(%s0x%04x - 0x%04x\n, reg_p-name,
(uint32_t)offset, (uint32_t)val);
+switch (offset) {
+case SWRESET:
+if (val 1) {
+qemu_system_reset_request();
+}
+break;
+default:
+/* Nothing */
+break;
+}
s-reg[i] = val;
return;
}
It's not quite well. At first, when you do reset, appropriate status
must be set in RST_STAT register. At second, not all registers in PMU
should be set in default value after reset, so you should change PMU
reset function for handling different resets (see spec) So, this
functionality should be wrote more carefully
Well, this is the case when there is a need to modify booting procedure
depending on the values of these registers. I haven't found any such
code in the current kernel. As I now remember saving their values was
indeed important when we were trying to use an U-Boot bootloader. But
as long as we are sticking with QEMU bootloader it doesn't matter.
3.4-rc1 and 2.6.36 kernels use INFORM5 register which should keep his
value during sw reset. And U-Boot (which can be used instead of kernel
for some purposes) uses INFORM[456] registers which should be saved as well.
My opinion is we should not add code which describe incorrect behavior
of the device regardless of whether kernel uses some registers or no.
Anyway this information is unfortunately absent in Exynos4210 public
documentation.
Hm... Really, I've just found out that public specification doesn't
contain information about PMU
And use #define for registers and fields of the registers. It's more
clearly, as for me.
As you say.
:)
Regards,
MK
Regards,
Dmitry
Re: [Qemu-devel] [PATCH 13/14] configure: change meaning of --datadir to Autoconf convention
On Wed, Apr 04, 2012 at 05:25:14PM +0200, Paolo Bonzini wrote:
Il 30/03/2012 19:33, Eduardo Habkost ha scritto:
Autoconf uses --datadir for the /usr/share directory, not the
program-specific subdirectory inside /usr/share. This changes configure
to match autoconf behavior.
Note that this will break compatibility with existing build scripts.
Signed-off-by: Eduardo Habkost ehabk...@redhat.com
---
configure |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/configure b/configure
index 5de58cb..b74efe2 100755
--- a/configure
+++ b/configure
@@ -155,7 +155,7 @@ mingw32=no
EXESUF=
prefix=/usr/local
mandir=\${prefix}/share/man
-qemu_datadir=\${prefix}/share/qemu
+datadir=\${prefix}/share
qemu_docdir=\${prefix}/share/doc/qemu
bindir=\${prefix}/bin
libdir=\${prefix}/lib
@@ -521,7 +521,7 @@ EOF
fi
prefix=c:/Program Files/Qemu
mandir=\${prefix}
- qemu_datadir=\${prefix}
+ datadir=\${prefix}
qemu_docdir=\${prefix}
bindir=\${prefix}
sysconfdir=\${prefix}
This does not change anything because the next line is
confsuffix=
Nice. :)
Yes, in the case of mingw32 it does not change anything. The change
above is only necessary because qemu_datadir is now set later, at:
[...]
@@ -2831,6 +2831,7 @@ if test $mingw32 = yes ; then
fi
qemu_confdir=$sysconfdir$confsuffix
+qemu_datadir=$datadir$confsuffix
tools=
if test $softmmu = yes ; then
--
Eduardo
[Qemu-devel] automatic exit on memory errors
Hi, I just realized that on any out of memory conditions Qemu exit with an error. I found this thread on g_malloc http://comments.gmane.org/gmane.comp.emulators.qemu/128863 but nothing related to the exit conditions. I know that out of memory conditions is quite hard to handle but if somebody rely to a virtual machine and at least to a clean close I think this won't happen. Personally I think that managing this situation in a clean way where error is tried to be reported and cleans are tried. If some function try to allocate a large buffer the function should just return an error and program can report error and let use clean or try to recover (like powering off the machine) but calling g_malloc everywhere is not that fine. It would at least be fine if block drivers register some atexit function to flush every buffer they possible have. Anybody considered this problem? Frediano
Re: [Qemu-devel] [PATCH 0/5] Spread the use of QEMU threading locking API
Il 04/04/2012 18:05, Jan Kiszka ha scritto: Perhaps you can take the relevant patches out of the thread-blocks branch at git://github.com/pbonzini/qemu.git? The iothread eventfd could also use an EventNotifier. Yep, this screams for something like QemuEvent which pleases all users of current qemu_eventfd and EventNotifier - and fit into the existing threading/synchronization abstraction layout. Kind of, on Unix you cannot poll synchronization primitives so EventNotifier has to remain separate from qemu-thread. I retract patches 34, will be done on top of the event rework. Cool, thanks! Paolo
Re: [Qemu-devel] [PATCH v2 0/4] QOM'ify S/390 CPU
Am 03.04.2012 14:38, schrieb Christian Borntraeger: On 02/04/12 19:09, Andreas Färber wrote: Hello, This series breaks down my S/390 QOM'ification patch from the qom-cpu-others.v1 RFC series into better digestable pieces and reorders it next. s390x ignores any user-specified -cpu argument, thus needs only one CPU type. I've tested both TCG by running SLES installation and briefly KVM on SLES. Christian, could you please verify this doesn't break your test cases and add your Tested-by? (kvm-only) Tested-by: Christian Borntraeger borntrae...@de.ibm.com Thanks a lot, applied to s390-next: http://repo.or.cz/w/qemu/agraf.git/shortlog/refs/heads/s390-next Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
[Qemu-devel] [PATCH 11/13] hw/arm_gic.c: Use NVIC instead of LEGACY_INCLUDED_GIC define
Now all the A profile cores have been switched to use the standalone
sysbus GIC, the only remaining code which #includes arm_gic.c is
the v7M NVIC. The coupling is much closer here so it's not so
easily disentangled. For now, add a comment about how arm_gic.c
is compiled, and assume that the NVIC always includes arm_gic.c
and the non-NVIC GIC is always compiled standalone.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
hw/arm_gic.c | 13 ++---
hw/armv7m_nvic.c |1 -
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/hw/arm_gic.c b/hw/arm_gic.c
index e913fc5..a9da88a 100644
--- a/hw/arm_gic.c
+++ b/hw/arm_gic.c
@@ -8,8 +8,15 @@
*/
/* This file contains implementation code for the RealView EB interrupt
- controller, MPCore distributed interrupt controller and ARMv7-M
- Nested Vectored Interrupt Controller. */
+ * controller, MPCore distributed interrupt controller and ARMv7-M
+ * Nested Vectored Interrupt Controller.
+ * It is compiled in two ways:
+ * (1) as a standalone file to produce a sysbus device which is a GIC
+ * that can be used on the realview board and as one of the builtin
+ * private peripherals for the ARM MP CPUs (11MPCore, A9, etc)
+ * (2) by being directly #included into armv7m_nvic.c to produce the
+ * armv7m_nvic device.
+ */
#include sysbus.h
@@ -909,7 +916,7 @@ static void gic_init(gic_state *s, int num_irq)
register_savevm(NULL, arm_gic, -1, 2, gic_save, gic_load, s);
}
-#ifndef LEGACY_INCLUDED_GIC
+#ifndef NVIC
static int arm_gic_init(SysBusDevice *dev)
{
diff --git a/hw/armv7m_nvic.c b/hw/armv7m_nvic.c
index 5cfa971..986a6bb 100644
--- a/hw/armv7m_nvic.c
+++ b/hw/armv7m_nvic.c
@@ -16,7 +16,6 @@
#include exec-memory.h
#define NVIC 1
-#define LEGACY_INCLUDED_GIC
static uint32_t nvic_readl(void *opaque, uint32_t offset);
static void nvic_writel(void *opaque, uint32_t offset, uint32_t value);
--
1.7.1
[Qemu-devel] [PATCH 12/13] hw/arm_gic.c: gic_set_pending_private() is NVIC only
The function gic_set_pending_private() is now used by the NVIC
only (for the GIC we now set PPI interrupts via gpio lines and
gic_set_irq()). So make it #ifdef NVIC and remove the 'attribute
unused' annotation.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
hw/arm_gic.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/hw/arm_gic.c b/hw/arm_gic.c
index a9da88a..f395e4b 100644
--- a/hw/arm_gic.c
+++ b/hw/arm_gic.c
@@ -185,8 +185,8 @@ static void gic_update(gic_state *s)
}
}
-static void __attribute__((unused))
-gic_set_pending_private(gic_state *s, int cpu, int irq)
+#ifdef NVIC
+static void gic_set_pending_private(gic_state *s, int cpu, int irq)
{
int cm = 1 cpu;
@@ -197,6 +197,7 @@ gic_set_pending_private(gic_state *s, int cpu, int irq)
GIC_SET_PENDING(irq, cm);
gic_update(s);
}
+#endif
/* Process a change in an external IRQ input. */
static void gic_set_irq(void *opaque, int irq, int level)
--
1.7.1
Re: [Qemu-devel] [RFC PATCH v1 1/4] SPI: initial support
Hi Paul, Regarding using ssi, theres a few things that come to mind: Theres no sense of it being a multi-slave bus, its just a point to point link. SPI devices universally have the notion of the CS pin that tristates the device of the bus. Masters connect to a number of slaves and one-hot-decode the active slave. It would be tedious if all SPI controllers (of which i have two (only pushed one in this series), omap have theirs, Nokia may have something out of tree too), had to implement the\is common CS decoding behaviour. To that end, my SPI bus implementation has some infra-structure for managing this - spi_set_cs(). The spi_bus in this series is single master, multi-slave, where as ssi is point-to-point. Also as mentioned in earlier discussions with Peter, that api has no way of emulating the CS (sometimes called SS) pin. The m25p80 in this series (and potenitally other devices) has side effect associated with wiggling the cs pin, which can not be encapsulated by that ssi slave interface. It may be a case though that ssi is a superclass of spi - all SPI devices are SSI devices but not all SSI devices are SPI? To that end can we make SPI a child object of SSI with the desired extra behaviors mentioned in this thread? This kind of stuff is the whole reason for QOM. I don't believe there is any difference between SSI and SPI. It's the exact same thing - the same way that many devices support a two-wire interface that is actually just I2C with a different name. The behavior of the CS pin varies between devices. It sounds like you need a bit of extra logic not present in the current ssi code. You should fix that, not invent a whole new bus. Paul
Re: [Qemu-devel] [PATCH 0/5] Spread the use of QEMU threading locking API
On 2012-04-04 18:39, Paolo Bonzini wrote: Il 04/04/2012 18:05, Jan Kiszka ha scritto: Perhaps you can take the relevant patches out of the thread-blocks branch at git://github.com/pbonzini/qemu.git? The iothread eventfd could also use an EventNotifier. Yep, this screams for something like QemuEvent which pleases all users of current qemu_eventfd and EventNotifier - and fit into the existing threading/synchronization abstraction layout. Kind of, on Unix you cannot poll synchronization primitives so EventNotifier has to remain separate from qemu-thread. QemuEvent will be pollable as you can ask it for its read fd: void qemu_event_init(QemuEvent *event, bool signaled); void qemu_event_destroy(QemuEvent *event); int qemu_event_get_write_fd(QemuEvent *event); int qemu_event_get_read_fd(QemuEvent *event); void qemu_event_signal(QemuEvent *event); bool qemu_event_check(QemuEvent *event); I'm not yet convinced a qemu_event_set_handler buys us a lot, so I prefer the get_read_fd interface for now. This is just a matter of code organization, and I prefer to consolidate this under the hood of qemu-thread. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
[Qemu-devel] [PATCH 0/5] Spread the use of QEMU threading locking API
Refreshed versions of some cleanups I already sent last year. See patches for details. The series also helps using different scheduling policies for QEMU threads which includes hardening internal locks. Jan Kiszka (5): Introduce qemu_cond_timedwait for POSIX Switch POSIX compat AIO to QEMU abstractions Use qemu_eventfd for POSIX AIO Reorder POSIX compat AIO code Switch compatfd to QEMU thread compatfd.c | 16 + posix-aio-compat.c | 162 +-- qemu-thread-posix.c | 23 +++ qemu-thread-posix.h |5 ++ 4 files changed, 84 insertions(+), 122 deletions(-) -- 1.7.3.4
[Qemu-devel] [PATCH 1/4] target-s390x: QOM'ify CPU
Embed CPUS390XState as first member of S390CPU.
Since -cpu is being ignored, make TYPE_S390_CPU non-abstract.
Signed-off-by: Andreas Färber afaer...@suse.de
Tested-by: Christian Borntraeger borntrae...@de.ibm.com
---
Makefile.target|1 +
target-s390x/cpu-qom.h | 71
target-s390x/cpu.c | 60
target-s390x/cpu.h |2 +
target-s390x/helper.c |4 ++-
5 files changed, 137 insertions(+), 1 deletions(-)
create mode 100644 target-s390x/cpu-qom.h
create mode 100644 target-s390x/cpu.c
diff --git a/Makefile.target b/Makefile.target
index cff15f0..999a968 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -93,6 +93,7 @@ libobj-$(TARGET_SPARC64) += vis_helper.o
libobj-$(CONFIG_NEED_MMU) += mmu.o
libobj-$(TARGET_ARM) += neon_helper.o iwmmxt_helper.o
libobj-$(TARGET_ARM) += cpu.o
+libobj-$(TARGET_S390X) += cpu.o
ifeq ($(TARGET_BASE_ARCH), sparc)
libobj-y += fop_helper.o cc_helper.o win_helper.o mmu_helper.o ldst_helper.o
libobj-y += cpu_init.o
diff --git a/target-s390x/cpu-qom.h b/target-s390x/cpu-qom.h
new file mode 100644
index 000..6fa55a8
--- /dev/null
+++ b/target-s390x/cpu-qom.h
@@ -0,0 +1,71 @@
+/*
+ * QEMU S/390 CPU
+ *
+ * Copyright (c) 2012 SUSE LINUX Products GmbH
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see
+ * http://www.gnu.org/licenses/lgpl-2.1.html
+ */
+#ifndef QEMU_S390_CPU_QOM_H
+#define QEMU_S390_CPU_QOM_H
+
+#include qemu/cpu.h
+#include cpu.h
+
+#define TYPE_S390_CPU s390-cpu
+
+#define S390_CPU_CLASS(klass) \
+OBJECT_CLASS_CHECK(S390CPUClass, (klass), TYPE_S390_CPU)
+#define S390_CPU(obj) \
+OBJECT_CHECK(S390CPU, (obj), TYPE_S390_CPU)
+#define S390_CPU_GET_CLASS(obj) \
+OBJECT_GET_CLASS(S390CPUClass, (obj), TYPE_S390_CPU)
+
+/**
+ * S390CPUClass:
+ * @parent_reset: The parent class' reset handler.
+ *
+ * An S/390 CPU model.
+ */
+typedef struct S390CPUClass {
+/* private */
+CPUClass parent_class;
+/* public */
+
+void (*parent_reset)(CPUState *cpu);
+} S390CPUClass;
+
+/**
+ * S390CPU:
+ * @env: #CPUS390XState.
+ *
+ * An S/390 CPU.
+ */
+typedef struct S390CPU {
+/* private */
+CPUState parent_obj;
+/* public */
+
+CPUS390XState env;
+} S390CPU;
+
+static inline S390CPU *s390_env_get_cpu(CPUS390XState *env)
+{
+return S390_CPU(container_of(env, S390CPU, env));
+}
+
+#define ENV_GET_CPU(e) CPU(s390_env_get_cpu(e))
+
+
+#endif
diff --git a/target-s390x/cpu.c b/target-s390x/cpu.c
new file mode 100644
index 000..94320f2
--- /dev/null
+++ b/target-s390x/cpu.c
@@ -0,0 +1,60 @@
+/*
+ * QEMU S/390 CPU
+ *
+ * Copyright (c) 2012 SUSE LINUX Products GmbH
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see
+ * http://www.gnu.org/licenses/lgpl-2.1.html
+ */
+
+#include cpu-qom.h
+#include qemu-common.h
+#include qemu-timer.h
+
+
+static void s390_cpu_reset(CPUState *s)
+{
+S390CPU *cpu = S390_CPU(s);
+S390CPUClass *scc = S390_CPU_GET_CLASS(cpu);
+CPUS390XState *env = cpu-env;
+
+scc-parent_reset(s);
+
+cpu_state_reset(env);
+}
+
+static void s390_cpu_class_init(ObjectClass *oc, void *data)
+{
+S390CPUClass *scc = S390_CPU_CLASS(oc);
+CPUClass *cc = CPU_CLASS(scc);
+
+scc-parent_reset = cc-reset;
+cc-reset = s390_cpu_reset;
+}
+
+static const TypeInfo s390_cpu_type_info = {
+.name = TYPE_S390_CPU,
+.parent = TYPE_CPU,
+.instance_size = sizeof(S390CPU),
+.abstract = false,
+.class_size = sizeof(S390CPUClass),
+.class_init = s390_cpu_class_init,
+};
+
+static void s390_cpu_register_types(void)
+{
+type_register_static(s390_cpu_type_info);
+}
+
+type_init(s390_cpu_register_types)
diff --git a/target-s390x/cpu.h b/target-s390x/cpu.h
index ea849fc..c6ee959 100644
---
Re: [Qemu-devel] [PATCH] Support system reset in Exynos4210
On 2012-04-04 20:16, Maksim Kozlov wrote:
04.04.2012 16:35, Dmitry Zhurikhin пишет:
On 2012-04-04 15:55, Maksim Kozlov wrote:
04.04.2012 14:08, Dmitry Zhurikhin пишет:
Reset the system when 1 is written to SWRESET register
Signed-off-by: Dmitry Zhurikhinz...@ispras.ru
---
hw/exynos4210_pmu.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/hw/exynos4210_pmu.c b/hw/exynos4210_pmu.c
index c12d750..edf6e34 100644
--- a/hw/exynos4210_pmu.c
+++ b/hw/exynos4210_pmu.c
@@ -25,6 +25,7 @@
*/
#include sysbus.h
+#include sysemu.h
#ifndef DEBUG_PMU
#define DEBUG_PMU 0
@@ -422,6 +423,16 @@ static void exynos4210_pmu_write(void *opaque,
target_phys_addr_t offset,
if (reg_p-offset == offset) {
PRINT_DEBUG_EXTEND(%s0x%04x - 0x%04x\n,
reg_p-name,
(uint32_t)offset, (uint32_t)val);
+switch (offset) {
+case SWRESET:
+if (val 1) {
+qemu_system_reset_request();
+}
+break;
+default:
+/* Nothing */
+break;
+}
s-reg[i] = val;
return;
}
It's not quite well. At first, when you do reset, appropriate status
must be set in RST_STAT register. At second, not all registers in PMU
should be set in default value after reset, so you should change PMU
reset function for handling different resets (see spec) So, this
functionality should be wrote more carefully
Well, this is the case when there is a need to modify booting procedure
depending on the values of these registers. I haven't found any such
code in the current kernel. As I now remember saving their values was
indeed important when we were trying to use an U-Boot bootloader. But
as long as we are sticking with QEMU bootloader it doesn't matter.
3.4-rc1 and 2.6.36 kernels use INFORM5 register which should keep his
value during sw reset. And U-Boot (which can be used instead of kernel
for some purposes) uses INFORM[456] registers which should be saved as
well.
My opinion is we should not add code which describe incorrect behavior
of the device regardless of whether kernel uses some registers or no.
OK, this is a righteous position. Again, I think in this case
implementing what you propose won't be neither bad nor good. But since
you've asked, I'll try to do it.
Anyway this information is unfortunately absent in Exynos4210 public
documentation.
Hm... Really, I've just found out that public specification doesn't
contain information about PMU
I can make the changes according to Exynos3210 specification since they
are pretty close. But of course I'd prefer that you send me full
specifications. Dmitry, what you say?
And use #define for registers and fields of the registers. It's more
clearly, as for me.
As you say.
:)
Regards,
MK
Regards,
Dmitry
Regards,
Dmitry
[Qemu-devel] [PATCH 06/13] hw/a9mpcore.c: Switch to using sysbus GIC
Switch the a9mpcore to using the sysbus GIC device rather
than having the a9mp private memory region device subclass
the GIC.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
hw/a9mpcore.c | 60 +---
1 files changed, 35 insertions(+), 25 deletions(-)
diff --git a/hw/a9mpcore.c b/hw/a9mpcore.c
index 164a0d3..c2ff74d 100644
--- a/hw/a9mpcore.c
+++ b/hw/a9mpcore.c
@@ -10,22 +10,19 @@
#include sysbus.h
-#define LEGACY_INCLUDED_GIC
-#include arm_gic.c
-
/* A9MP private memory region. */
typedef struct a9mp_priv_state {
-gic_state gic;
+SysBusDevice busdev;
uint32_t scu_control;
uint32_t scu_status;
uint32_t old_timer_status[8];
uint32_t num_cpu;
-qemu_irq *timer_irq;
MemoryRegion scu_iomem;
MemoryRegion ptimer_iomem;
MemoryRegion container;
DeviceState *mptimer;
+DeviceState *gic;
uint32_t num_irq;
} a9mp_priv_state;
@@ -114,18 +111,9 @@ static const MemoryRegionOps a9_scu_ops = {
.endianness = DEVICE_NATIVE_ENDIAN,
};
-static void a9mpcore_timer_irq_handler(void *opaque, int irq, int level)
-{
-a9mp_priv_state *s = (a9mp_priv_state *)opaque;
-if (level !s-old_timer_status[irq]) {
-gic_set_pending_private(s-gic, irq 1, 29 + (irq 1));
-}
-s-old_timer_status[irq] = level;
-}
-
static void a9mp_priv_reset(DeviceState *dev)
{
-a9mp_priv_state *s = FROM_SYSBUSGIC(a9mp_priv_state,
sysbus_from_qdev(dev));
+a9mp_priv_state *s = FROM_SYSBUS(a9mp_priv_state, sysbus_from_qdev(dev));
int i;
s-scu_control = 0;
for (i = 0; i ARRAY_SIZE(s-old_timer_status); i++) {
@@ -133,13 +121,29 @@ static void a9mp_priv_reset(DeviceState *dev)
}
}
+static void a9mp_priv_set_irq(void *opaque, int irq, int level)
+{
+a9mp_priv_state *s = (a9mp_priv_state *)opaque;
+qemu_set_irq(qdev_get_gpio_in(s-gic, irq), level);
+}
+
static int a9mp_priv_init(SysBusDevice *dev)
{
-a9mp_priv_state *s = FROM_SYSBUSGIC(a9mp_priv_state, dev);
-SysBusDevice *busdev;
+a9mp_priv_state *s = FROM_SYSBUS(a9mp_priv_state, dev);
+SysBusDevice *busdev, *gicbusdev;
int i;
-gic_init(s-gic, s-num_cpu, s-num_irq);
+s-gic = qdev_create(NULL, arm_gic);
+qdev_prop_set_uint32(s-gic, num-cpu, s-num_cpu);
+qdev_prop_set_uint32(s-gic, num-irq, s-num_irq);
+qdev_init_nofail(s-gic);
+gicbusdev = sysbus_from_qdev(s-gic);
+
+/* Pass through outbound IRQ lines from the GIC */
+sysbus_pass_irq(dev, gicbusdev);
+
+/* Pass through inbound GPIO lines to the GIC */
+qdev_init_gpio_in(s-busdev.qdev, a9mp_priv_set_irq, s-num_irq - 32);
s-mptimer = qdev_create(NULL, arm_mptimer);
qdev_prop_set_uint32(s-mptimer, num-cpu, s-num_cpu);
@@ -161,7 +165,8 @@ static int a9mp_priv_init(SysBusDevice *dev)
memory_region_init_io(s-scu_iomem, a9_scu_ops, s, a9mp-scu, 0x100);
memory_region_add_subregion(s-container, 0, s-scu_iomem);
/* GIC CPU interface */
-memory_region_add_subregion(s-container, 0x100, s-gic.cpuiomem[0]);
+memory_region_add_subregion(s-container, 0x100,
+sysbus_mmio_get_region(gicbusdev, 1));
/* Note that the A9 exposes only the timer/watchdog for this core
* memory region, not the timer/watchdog for core X ones 11MPcore has.
*/
@@ -169,15 +174,20 @@ static int a9mp_priv_init(SysBusDevice *dev)
sysbus_mmio_get_region(busdev, 0));
memory_region_add_subregion(s-container, 0x620,
sysbus_mmio_get_region(busdev, 1));
-memory_region_add_subregion(s-container, 0x1000, s-gic.iomem);
+memory_region_add_subregion(s-container, 0x1000,
+sysbus_mmio_get_region(gicbusdev, 0));
sysbus_init_mmio(dev, s-container);
-/* Wire up the interrupt from each watchdog and timer. */
-s-timer_irq = qemu_allocate_irqs(a9mpcore_timer_irq_handler,
- s, (s-num_cpu + 1) * 2);
-for (i = 0; i s-num_cpu * 2; i++) {
-sysbus_connect_irq(busdev, i, s-timer_irq[i]);
+/* Wire up the interrupt from each watchdog and timer.
+ * For each core the timer is PPI 29 and the watchdog PPI 30.
+ */
+for (i = 0; i s-num_cpu; i++) {
+int ppibase = (s-num_irq - 32) + i * 32;
+sysbus_connect_irq(busdev, i * 2,
+ qdev_get_gpio_in(s-gic, ppibase + 29));
+sysbus_connect_irq(busdev, i * 2 + 1,
+ qdev_get_gpio_in(s-gic, ppibase + 30));
}
return 0;
}
--
1.7.1
Re: [Qemu-devel] [PATCH 0/5] Spread the use of QEMU threading locking API
On 2012-04-04 18:55, Jan Kiszka wrote: On 2012-04-04 18:39, Paolo Bonzini wrote: Il 04/04/2012 18:05, Jan Kiszka ha scritto: Perhaps you can take the relevant patches out of the thread-blocks branch at git://github.com/pbonzini/qemu.git? The iothread eventfd could also use an EventNotifier. Yep, this screams for something like QemuEvent which pleases all users of current qemu_eventfd and EventNotifier - and fit into the existing threading/synchronization abstraction layout. Kind of, on Unix you cannot poll synchronization primitives so Ah, you meant on Win32 you cannot poll! EventNotifier has to remain separate from qemu-thread. QemuEvent will be pollable as you can ask it for its read fd: void qemu_event_init(QemuEvent *event, bool signaled); void qemu_event_destroy(QemuEvent *event); int qemu_event_get_write_fd(QemuEvent *event); int qemu_event_get_read_fd(QemuEvent *event); void qemu_event_signal(QemuEvent *event); bool qemu_event_check(QemuEvent *event); I'm not yet convinced a qemu_event_set_handler buys us a lot, so I prefer the get_read_fd interface for now. I'm starting to understand your abstraction here - makes sense. :) Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
[Qemu-devel] [PATCH V2 0/7] memory: unify ioport registration
This is the second version of patch serie (the previous patch was not split) about ioport registration. For the moment some part of QEMU use register_ioport* functions to register ioport. These functions don't permit the logging of range with Memory Listener. Modifications between V1 and V2 : - Remove the use of get_system_io. Instead of use isa and pci IO address space. - Avoid allocation of PortioList. Use the different device structure. - Still remove register_ioport* (hw/dma.c, hw/apm.c, hw/acpi_piix4.c). - Use MemoryRegion when we have only a range of ioport. - For some functions, add IO address space as argument. - Add isa_address_space_io function I may not to be aware about some new modifications (hw/dma.c and hw/apm.c), any advice on its will be welcome. Julien Grall (7): isa: add isa_address_space_io hw/acpi_piix4.c: replace register_ioport* hw/cirrus_vga.c: replace register_ioport* hw/serial.c: replace register_ioport* hw/pc.c: replace register_ioport* hw/dma.c: replace register_ioport* hw/apm.c: replace register_ioport* hw/acpi_piix4.c | 78 ++ hw/apm.c| 24 +--- hw/apm.h|5 +++- hw/cirrus_vga.c | 38 +++--- hw/dma.c| 55 ++ hw/isa-bus.c|5 +++ hw/isa.h|1 + hw/pc.c | 37 -- hw/pc.h |2 +- hw/serial.c |8 +++-- hw/vt82c686.c |2 +- 11 files changed, 184 insertions(+), 71 deletions(-) -- Julien Grall
[Qemu-devel] [PATCH V2 2/7] hw/acpi_piix4.c: replace register_ioport*
This patch replaces all register_ioport* with portio_*. It permits to
use the new Memory stuff like listener.
Signed-off-by: Julien Grall julien.gr...@citrix.com
---
hw/acpi_piix4.c | 76 +++
1 files changed, 65 insertions(+), 11 deletions(-)
diff --git a/hw/acpi_piix4.c b/hw/acpi_piix4.c
index 797ed24..b9b195b 100644
--- a/hw/acpi_piix4.c
+++ b/hw/acpi_piix4.c
@@ -61,6 +61,13 @@ typedef struct PIIX4PMState {
PMSMBus smb;
uint32_t smb_io_base;
+PortioList port_list;
+PortioList acpi_port_list;
+PortioList acpi_hot_port_list;
+PortioList pci_hot_port_list;
+PortioList pciej_hot_port_list;
+PortioList pcirmv_hot_port_list;
+
qemu_irq irq;
qemu_irq smi_irq;
int kvm_enabled;
@@ -325,6 +332,17 @@ static void piix4_pm_machine_ready(Notifier *n, void
*opaque)
}
+static const MemoryRegionPortio piix4_portio_list[] = {
+{ 0x00, 64, 1, .read = smb_ioport_readb, }, /* s-smb_io_base */
+{ 0x00, 64, 1, .write = smb_ioport_writeb, }, /* s-smb_io_base */
+PORTIO_END_OF_LIST(),
+};
+
+static const MemoryRegionPortio acpi_portio_list[] = {
+{ 0x00, 4, 4, .write = acpi_dbg_writel, }, /* ACPI_DBG_IO_ADDR */
+PORTIO_END_OF_LIST(),
+};
+
static int piix4_pm_initfn(PCIDevice *dev)
{
PIIX4PMState *s = DO_UPCAST(PIIX4PMState, dev, dev);
@@ -341,7 +359,9 @@ static int piix4_pm_initfn(PCIDevice *dev)
/* APM */
apm_init(s-apm, apm_ctrl_changed, s);
-register_ioport_write(ACPI_DBG_IO_ADDR, 4, 4, acpi_dbg_writel, s);
+portio_list_init(s-acpi_port_list, acpi_portio_list, s, piix4-acpi);
+portio_list_add(s-acpi_port_list, pci_address_space_io(dev),
+ACPI_DBG_IO_ADDR);
if (s-kvm_enabled) {
/* Mark SMM as already inited to prevent SMM from running. KVM does
not
@@ -354,8 +374,10 @@ static int piix4_pm_initfn(PCIDevice *dev)
pci_conf[0x90] = s-smb_io_base | 1;
pci_conf[0x91] = s-smb_io_base 8;
pci_conf[0xd2] = 0x09;
-register_ioport_write(s-smb_io_base, 64, 1, smb_ioport_writeb, s-smb);
-register_ioport_read(s-smb_io_base, 64, 1, smb_ioport_readb, s-smb);
+
+portio_list_init(s-port_list, piix4_portio_list, s, piix4-acpi);
+portio_list_add(s-port_list, pci_address_space_io(dev),
+s-smb_io_base);
acpi_pm_tmr_init(s-ar, pm_tmr_timer);
acpi_gpe_init(s-ar, GPE_LEN);
@@ -521,22 +543,54 @@ static void pcirmv_write(void *opaque, uint32_t addr,
uint32_t val)
static int piix4_device_hotplug(DeviceState *qdev, PCIDevice *dev,
PCIHotplugState state);
+static const MemoryRegionPortio acpi_hot_portio_list[] = {
+{ 0x00, GPE_LEN, 1, .write = gpe_writeb,
+.read = gpe_readb, }, /* GPE_BASE */
+PORTIO_END_OF_LIST(),
+};
+
+/* IOport from PCI_BASE */
+static const MemoryRegionPortio pci_hot_portio_list[] = {
+{ 0x00, 8, 4, .write = pcihotplug_write, .read = pcihotplug_read, },
+PORTIO_END_OF_LIST(),
+};
+
+/* IOport from PCI_EJ_BASE */
+static const MemoryRegionPortio pciej_hot_portio_list[] = {
+{ 0x00, 4, 4, .write = pciej_write, .read = pciej_read, },
+PORTIO_END_OF_LIST(),
+};
+
+/* IOport form PCI_RMV_BASE */
+static const MemoryRegionPortio pcirmv_hot_portio_list[] = {
+{ 0x00, 4, 4, .write = pcirmv_write, .read = pcirmv_read, },
+PORTIO_END_OF_LIST(),
+};
+
static void piix4_acpi_system_hot_add_init(PCIBus *bus, PIIX4PMState *s)
{
struct pci_status *pci0_status = s-pci0_status;
-register_ioport_write(GPE_BASE, GPE_LEN, 1, gpe_writeb, s);
-register_ioport_read(GPE_BASE, GPE_LEN, 1, gpe_readb, s);
+portio_list_init(s-acpi_hot_port_list, acpi_hot_portio_list,
+ s, piix4-acpi-hot);
+portio_list_add(s-acpi_hot_port_list, pci_address_space_io(s-dev),
+GPE_BASE);
acpi_gpe_blk(s-ar, GPE_BASE);
-register_ioport_write(PCI_BASE, 8, 4, pcihotplug_write, pci0_status);
-register_ioport_read(PCI_BASE, 8, 4, pcihotplug_read, pci0_status);
+portio_list_init(s-pci_hot_port_list, pci_hot_portio_list,
+ pci0_status, piix4-pci-hot);
+portio_list_add(s-pci_hot_port_list, pci_address_space_io(s-dev),
+PCI_BASE);
-register_ioport_write(PCI_EJ_BASE, 4, 4, pciej_write, bus);
-register_ioport_read(PCI_EJ_BASE, 4, 4, pciej_read, bus);
+portio_list_init(s-pciej_hot_port_list, pciej_hot_portio_list,
+ bus, piix4-pciej-hot);
+portio_list_add(s-pciej_hot_port_list, pci_address_space_io(s-dev),
+PCI_EJ_BASE);
-register_ioport_write(PCI_RMV_BASE, 4, 4, pcirmv_write, s);
-register_ioport_read(PCI_RMV_BASE, 4, 4, pcirmv_read, s);
+portio_list_init(s-pcirmv_hot_port_list, pcirmv_hot_portio_list,
+ s, piix4-pcirmv-hot);
+portio_list_add(s-pcirmv_hot_port_list, pci_address_space_io(s-dev),
+PCI_RMV_BASE);
[Qemu-devel] [PATCH 4/4] target-s390x: Update s390x_{tod, cpu}_timer() to use S390CPU
In place of CPUS390XState pass S390CPU as opaque from the new initfn.
cpu_interrupt() is anticipated to take a CPUState in the future.
Signed-off-by: Andreas Färber afaer...@suse.de
Tested-by: Christian Borntraeger borntrae...@de.ibm.com
---
target-s390x/cpu.c|4 ++--
target-s390x/helper.c |6 --
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/target-s390x/cpu.c b/target-s390x/cpu.c
index 72ec349..f183213 100644
--- a/target-s390x/cpu.c
+++ b/target-s390x/cpu.c
@@ -60,8 +60,8 @@ static void s390_cpu_initfn(Object *obj)
env-tod_offset = TOD_UNIX_EPOCH +
(time2tod(mktimegm(tm)) * 10ULL);
env-tod_basetime = 0;
-env-tod_timer = qemu_new_timer_ns(vm_clock, s390x_tod_timer, env);
-env-cpu_timer = qemu_new_timer_ns(vm_clock, s390x_cpu_timer, env);
+env-tod_timer = qemu_new_timer_ns(vm_clock, s390x_tod_timer, cpu);
+env-cpu_timer = qemu_new_timer_ns(vm_clock, s390x_cpu_timer, cpu);
#endif
env-cpu_num = cpu_num++;
env-ext_index = -1;
diff --git a/target-s390x/helper.c b/target-s390x/helper.c
index 6233f9a..209a696 100644
--- a/target-s390x/helper.c
+++ b/target-s390x/helper.c
@@ -53,7 +53,8 @@
#ifndef CONFIG_USER_ONLY
void s390x_tod_timer(void *opaque)
{
-CPUS390XState *env = opaque;
+S390CPU *cpu = opaque;
+CPUS390XState *env = cpu-env;
env-pending_int |= INTERRUPT_TOD;
cpu_interrupt(env, CPU_INTERRUPT_HARD);
@@ -61,7 +62,8 @@ void s390x_tod_timer(void *opaque)
void s390x_cpu_timer(void *opaque)
{
-CPUS390XState *env = opaque;
+S390CPU *cpu = opaque;
+CPUS390XState *env = cpu-env;
env-pending_int |= INTERRUPT_CPUTIMER;
cpu_interrupt(env, CPU_INTERRUPT_HARD);
--
1.7.7
[Qemu-devel] [PATCH 08/13] hw/exynos4210_gic.c: Convert to using sysbus GIC
Convert the Exynos GIC code to use the standalone sysbus
GIC device.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
hw/exynos4210_gic.c | 32
1 files changed, 24 insertions(+), 8 deletions(-)
diff --git a/hw/exynos4210_gic.c b/hw/exynos4210_gic.c
index a05dab2..e1b215e 100644
--- a/hw/exynos4210_gic.c
+++ b/hw/exynos4210_gic.c
@@ -262,28 +262,44 @@ uint32_t exynos4210_get_irq(uint32_t grp, uint32_t bit)
/* GIC part */
-#define LEGACY_INCLUDED_GIC
-#include arm_gic.c
-
typedef struct {
-gic_state gic;
+SysBusDevice busdev;
MemoryRegion cpu_container;
MemoryRegion dist_container;
MemoryRegion cpu_alias[EXYNOS4210_NCPUS];
MemoryRegion dist_alias[EXYNOS4210_NCPUS];
uint32_t num_cpu;
+DeviceState *gic;
} Exynos4210GicState;
+static void exynos4210_gic_set_irq(void *opaque, int irq, int level)
+{
+Exynos4210GicState *s = (Exynos4210GicState *)opaque;
+qemu_set_irq(qdev_get_gpio_in(s-gic, irq), level);
+}
+
static int exynos4210_gic_init(SysBusDevice *dev)
{
-Exynos4210GicState *s = FROM_SYSBUSGIC(Exynos4210GicState, dev);
+Exynos4210GicState *s = FROM_SYSBUS(Exynos4210GicState, dev);
uint32_t i;
const char cpu_prefix[] = exynos4210-gic-alias_cpu;
const char dist_prefix[] = exynos4210-gic-alias_dist;
char cpu_alias_name[sizeof(cpu_prefix) + 3];
char dist_alias_name[sizeof(cpu_prefix) + 3];
+SysBusDevice *busdev;
+
+s-gic = qdev_create(NULL, arm_gic);
+qdev_prop_set_uint32(s-gic, num-cpu, s-num_cpu);
+qdev_prop_set_uint32(s-gic, num-irq, EXYNOS4210_GIC_NIRQ);
+qdev_init_nofail(s-gic);
+busdev = sysbus_from_qdev(s-gic);
+
+/* Pass through outbound IRQ lines from the GIC */
+sysbus_pass_irq(dev, busdev);
-gic_init(s-gic, s-num_cpu, EXYNOS4210_GIC_NIRQ);
+/* Pass through inbound GPIO lines to the GIC */
+qdev_init_gpio_in(s-busdev.qdev, exynos4210_gic_set_irq,
+ EXYNOS4210_GIC_NIRQ - 32);
memory_region_init(s-cpu_container, exynos4210-cpu-container,
EXYNOS4210_EXT_GIC_CPU_REGION_SIZE);
@@ -295,7 +311,7 @@ static int exynos4210_gic_init(SysBusDevice *dev)
sprintf(cpu_alias_name, %s%x, cpu_prefix, i);
memory_region_init_alias(s-cpu_alias[i],
cpu_alias_name,
- s-gic.cpuiomem[0],
+ sysbus_mmio_get_region(busdev, 1),
0,
EXYNOS4210_GIC_CPU_REGION_SIZE);
memory_region_add_subregion(s-cpu_container,
@@ -305,7 +321,7 @@ static int exynos4210_gic_init(SysBusDevice *dev)
sprintf(dist_alias_name, %s%x, dist_prefix, i);
memory_region_init_alias(s-dist_alias[i],
dist_alias_name,
- s-gic.iomem,
+ sysbus_mmio_get_region(busdev, 0),
0,
EXYNOS4210_GIC_DIST_REGION_SIZE);
memory_region_add_subregion(s-dist_container,
--
1.7.1
Re: [Qemu-devel] [PATCH 0/5] Spread the use of QEMU threading locking API
On 2012-04-04 17:29, Paolo Bonzini wrote: Il 04/04/2012 17:24, Jan Kiszka ha scritto: For patches 3 and 4, I'd rather use an EventNotifier... ...which still lacks support for non-eventfd systems. Hmm, I guess it's time to consolidate both. Perhaps you can take the relevant patches out of the thread-blocks branch at git://github.com/pbonzini/qemu.git? The iothread eventfd could also use an EventNotifier. Current EventNotifier code applies EFD_SEMAPHORE, which is not what we want for Posix AIO (otherwise we could just stick with the pipe). I cannot match the reasoning for EFD_SEM in event_notifier.c with the man page, need to dig deeper. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
[Qemu-devel] Switch off use of helper functions
Is there any way in QEMU to switch off the use of helper functions and make it translate target code to TCG code using only TCG micro-ops and not calls to helper functions? Rajat.
Re: [Qemu-devel] [PATCH 3/3] pseries: Add DPRINTF macros to spapr pci code
On Mon, Apr 2, 2012 at 04:17, David Gibson da...@gibson.dropbear.id.au wrote:
From: Alexey Kardashevskiy a...@ozlabs.ru
This adds DPRINTF() macros with the usual conventions to the spapr_pci
code.
Please use tracepoints instead of printf statements. Tracing is more
flexible, more efficient and does not suffer from bitrot.
Cc: Michael S. Tsirkin m...@redhat.com
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
Signed-off-by: David Gibson da...@gibson.dropbear.id.au
---
hw/spapr_pci.c | 8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/hw/spapr_pci.c b/hw/spapr_pci.c
index b8a0313..61a53d5 100644
--- a/hw/spapr_pci.c
+++ b/hw/spapr_pci.c
@@ -32,6 +32,14 @@
#include hw/pci_internals.h
+/*#define DEBUG_SPAPR_PCI*/
+
+#ifdef DEBUG_SPAPR_PCI
+# define DPRINTF(format, ...) fprintf(stderr, QEMU: format, ##
__VA_ARGS__)
+#else
+# define DPRINTF(format, ...) do { } while (0)
+#endif
+
static PCIDevice *find_dev(sPAPREnvironment *spapr,
uint64_t buid, uint32_t config_addr)
{
--
1.7.9.1
Re: [Qemu-devel] [PATCH 7/7 v5] VMXNET3 paravirtualized device implementation Interface type vmxnet3 added.
On Wed, Apr 04, 2012 at 02:44:01PM +0300, Izik Eidus wrote: Hi, What about this patch?, everything that was asked from Dmitry was accomplished... What prevent us from progressing with merging this patch? Thanks. Off the top of my head: issues with v5: polluting global namespace, must scope names appropriately with vmxnet_ VMXNET_ unless they have file scope. Don't use names with _ followed by an upper case letter or that star with two underscores. Don't mix underscores and mixed case. Don't stick any new types in net.c/pci.c - new devices should use -device not -net. Global stuff like ethernet header size should move to central place instead of copy paste. On 18/03/2012 11:27, Dmitry Fleytman wrote: Signed-off-by: Dmitry Fleytmandmi...@daynix.com Signed-off-by: Yan Vugenfirery...@daynix.com --- Makefile.objs |1 + default-configs/pci.mak |1 + hw/pci.c|2 + hw/pci.h|1 + hw/vmxnet3.c| 2454 +++ hw/vmxnet3.h| 757 +++ net.c |2 +- 7 files changed, 3217 insertions(+), 1 deletions(-) create mode 100644 hw/vmxnet3.c create mode 100644 hw/vmxnet3.h
[Qemu-devel] [PATCH 07/13] hw/realview_gic: switch to sysbus GIC
Switch the realview_gic device to the standalone sysbus GIC.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
hw/realview_gic.c | 38 ++
1 files changed, 26 insertions(+), 12 deletions(-)
diff --git a/hw/realview_gic.c b/hw/realview_gic.c
index a3b5a04..5bc37a7 100644
--- a/hw/realview_gic.c
+++ b/hw/realview_gic.c
@@ -9,31 +9,45 @@
#include sysbus.h
-#define LEGACY_INCLUDED_GIC
-#include arm_gic.c
-
typedef struct {
-gic_state gic;
+SysBusDevice busdev;
+DeviceState *gic;
MemoryRegion container;
} RealViewGICState;
-static void realview_gic_map_setup(RealViewGICState *s)
+static void realview_gic_set_irq(void *opaque, int irq, int level)
{
-memory_region_init(s-container, realview-gic-container, 0x2000);
-memory_region_add_subregion(s-container, 0, s-gic.cpuiomem[0]);
-memory_region_add_subregion(s-container, 0x1000, s-gic.iomem);
+RealViewGICState *s = (RealViewGICState *)opaque;
+qemu_set_irq(qdev_get_gpio_in(s-gic, irq), level);
}
static int realview_gic_init(SysBusDevice *dev)
{
-RealViewGICState *s = FROM_SYSBUSGIC(RealViewGICState, dev);
-
+RealViewGICState *s = FROM_SYSBUS(RealViewGICState, dev);
+SysBusDevice *busdev;
/* The GICs on the RealView boards have a fixed nonconfigurable
* number of interrupt lines, so we don't need to expose this as
* a qdev property.
*/
-gic_init(s-gic, 1, 96);
-realview_gic_map_setup(s);
+int numirq = 96;
+
+s-gic = qdev_create(NULL, arm_gic);
+qdev_prop_set_uint32(s-gic, num-cpu, 1);
+qdev_prop_set_uint32(s-gic, num-irq, numirq);
+qdev_init_nofail(s-gic);
+busdev = sysbus_from_qdev(s-gic);
+
+/* Pass through outbound IRQ lines from the GIC */
+sysbus_pass_irq(dev, busdev);
+
+/* Pass through inbound GPIO lines to the GIC */
+qdev_init_gpio_in(s-busdev.qdev, realview_gic_set_irq, numirq - 32);
+
+memory_region_init(s-container, realview-gic-container, 0x2000);
+memory_region_add_subregion(s-container, 0,
+sysbus_mmio_get_region(busdev, 1));
+memory_region_add_subregion(s-container, 0x1000,
+sysbus_mmio_get_region(busdev, 0));
sysbus_init_mmio(dev, s-container);
return 0;
}
--
1.7.1
[Qemu-devel] [PATCH 3/4] target-s390x: QOM'ify CPU init
Move code from cpu_s390x_init() into an initfn.
Signed-off-by: Andreas Färber afaer...@suse.de
Tested-by: Christian Borntraeger borntrae...@de.ibm.com
---
target-s390x/cpu.c| 25 +
target-s390x/cpu.h|3 +++
target-s390x/helper.c | 21 +++--
3 files changed, 31 insertions(+), 18 deletions(-)
diff --git a/target-s390x/cpu.c b/target-s390x/cpu.c
index cae0b18..72ec349 100644
--- a/target-s390x/cpu.c
+++ b/target-s390x/cpu.c
@@ -45,6 +45,30 @@ static void s390_cpu_reset(CPUState *s)
s390_add_running_cpu(env);
}
+static void s390_cpu_initfn(Object *obj)
+{
+S390CPU *cpu = S390_CPU(obj);
+CPUS390XState *env = cpu-env;
+static int cpu_num = 0;
+#if !defined(CONFIG_USER_ONLY)
+struct tm tm;
+#endif
+
+cpu_exec_init(env);
+#if !defined(CONFIG_USER_ONLY)
+qemu_get_timedate(tm, 0);
+env-tod_offset = TOD_UNIX_EPOCH +
+ (time2tod(mktimegm(tm)) * 10ULL);
+env-tod_basetime = 0;
+env-tod_timer = qemu_new_timer_ns(vm_clock, s390x_tod_timer, env);
+env-cpu_timer = qemu_new_timer_ns(vm_clock, s390x_cpu_timer, env);
+#endif
+env-cpu_num = cpu_num++;
+env-ext_index = -1;
+
+cpu_reset(CPU(cpu));
+}
+
static void s390_cpu_class_init(ObjectClass *oc, void *data)
{
S390CPUClass *scc = S390_CPU_CLASS(oc);
@@ -58,6 +82,7 @@ static const TypeInfo s390_cpu_type_info = {
.name = TYPE_S390_CPU,
.parent = TYPE_CPU,
.instance_size = sizeof(S390CPU),
+.instance_init = s390_cpu_initfn,
.abstract = false,
.class_size = sizeof(S390CPUClass),
.class_init = s390_cpu_class_init,
diff --git a/target-s390x/cpu.h b/target-s390x/cpu.h
index c6ee959..2f3f394 100644
--- a/target-s390x/cpu.h
+++ b/target-s390x/cpu.h
@@ -288,6 +288,9 @@ int cpu_s390x_handle_mmu_fault (CPUS390XState *env,
target_ulong address, int rw
#ifndef CONFIG_USER_ONLY
+void s390x_tod_timer(void *opaque);
+void s390x_cpu_timer(void *opaque);
+
int s390_virtio_hypercall(CPUS390XState *env, uint64_t mem, uint64_t
hypercall);
#ifdef CONFIG_KVM
diff --git a/target-s390x/helper.c b/target-s390x/helper.c
index cd3e8f5..6233f9a 100644
--- a/target-s390x/helper.c
+++ b/target-s390x/helper.c
@@ -51,7 +51,7 @@
#endif
#ifndef CONFIG_USER_ONLY
-static void s390x_tod_timer(void *opaque)
+void s390x_tod_timer(void *opaque)
{
CPUS390XState *env = opaque;
@@ -59,7 +59,7 @@ static void s390x_tod_timer(void *opaque)
cpu_interrupt(env, CPU_INTERRUPT_HARD);
}
-static void s390x_cpu_timer(void *opaque)
+void s390x_cpu_timer(void *opaque)
{
CPUS390XState *env = opaque;
@@ -72,32 +72,17 @@ CPUS390XState *cpu_s390x_init(const char *cpu_model)
{
S390CPU *cpu;
CPUS390XState *env;
-#if !defined (CONFIG_USER_ONLY)
-struct tm tm;
-#endif
static int inited = 0;
-static int cpu_num = 0;
cpu = S390_CPU(object_new(TYPE_S390_CPU));
env = cpu-env;
-cpu_exec_init(env);
+
if (tcg_enabled() !inited) {
inited = 1;
s390x_translate_init();
}
-#if !defined(CONFIG_USER_ONLY)
-qemu_get_timedate(tm, 0);
-env-tod_offset = TOD_UNIX_EPOCH +
- (time2tod(mktimegm(tm)) * 10ULL);
-env-tod_basetime = 0;
-env-tod_timer = qemu_new_timer_ns(vm_clock, s390x_tod_timer, env);
-env-cpu_timer = qemu_new_timer_ns(vm_clock, s390x_cpu_timer, env);
-#endif
env-cpu_model_str = cpu_model;
-env-cpu_num = cpu_num++;
-env-ext_index = -1;
-cpu_reset(CPU(cpu));
qemu_init_vcpu(env);
return env;
}
--
1.7.7
Re: [Qemu-devel] Using load_elf
On Mon, Apr 2, 2012 at 22:57, Brian Vandenberg phantall+qemude...@gmail.com wrote: I'm attempting to familiarize myself with the APIs used to add support for boards in qemu, and I have a few questions. * How does using load_elf differ from load_image_targphys? As an example, many of the boards I've looked at have a hard-coded entrypoint. In mpc8455, it looks as though it doesn't have a hard-coded entrypoint but rather it gets the entrypoint directly from the kernel module. However, I'm guessing in an actual mpc 8455 board, it would expect the image to be in ROM, which would be mapped at a particular address, and it would expect the entrypoint to be some fixed offset from the beginning of that ROM segment. So, in terms of how qemu will use the image (and any other related info), how do load_elf and load_image_targphys differ? ROM images are in form of binary blobs with no location information, they must be loaded to a known address. For boot ROMs, the address range would cover CPU hard reset entry vector. ELF images specify the load and entry address (as well as symbol tables, debugging info etc.), this is useful for kernel images but also for ROMs where we have the source, like OpenBIOS on Sparc and PPC. Depending on machine setup, it's also possible to load only a kernel and no ROM in QEMU. Of course on real machines, kernel images don't just magically appear in RAM, some kind of ROM or flash is always involved. * mpc8455 uses a device tree for describing a device-tree hierarchy to qemu. Where should I look to find useful documentation describing these .dtb files (where they come from, what is used to create them, etc)? The tool used is device tree compiler (http://jdl.com/software/ I think). * On a related note: I'm working on getting VxWorks to boot in qemu for a few different boards. VxWorks doesn't use libfdt (or anything similar) to describe the hardware; the BSP does that job. My assumption so far is that FDT is being used by qemu, but it's used to ease development in qemu; libfdt isn't being used to provide any information directly to the guest OS. Is this a correct assumption? The device tree is decorated by QEMU (for example memory size and host clock speed), but it's not used internally by QEMU otherwise. This tree is passed to the guest OS. If the guest doesn't use the tree, it could be useful to make the FDT use optional. -Brian
[Qemu-devel] [PATCH 13/14] configure: change meaning of --datadir to Autoconf convention
Autoconf uses --datadir for the /usr/share directory, not the
program-specific subdirectory inside /usr/share. This changes configure
to match autoconf behavior.
Note that this will break compatibility with existing build scripts.
Signed-off-by: Eduardo Habkost ehabk...@redhat.com
---
configure |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/configure b/configure
index 37f455c..521d233 100755
--- a/configure
+++ b/configure
@@ -155,7 +155,7 @@ mingw32=no
EXESUF=
prefix=/usr/local
mandir=\${prefix}/share/man
-qemu_datadir=\${prefix}/share/qemu
+datadir=\${prefix}/share
qemu_docdir=\${prefix}/share/doc/qemu
bindir=\${prefix}/bin
libdir=\${prefix}/lib
@@ -521,7 +521,7 @@ EOF
fi
prefix=c:/Program Files/Qemu
mandir=\${prefix}
- qemu_datadir=\${prefix}
+ datadir=\${prefix}
qemu_docdir=\${prefix}
bindir=\${prefix}
sysconfdir=\${prefix}
@@ -589,7 +589,7 @@ for opt do
;;
--includedir=*) includedir=$optarg
;;
- --datadir=*) qemu_datadir=$optarg
+ --datadir=*) datadir=$optarg
;;
--docdir=*) qemu_docdir=$optarg
;;
@@ -1007,7 +1007,7 @@ echo --python=PYTHON use specified python
[$python]
echo --smbd=SMBD use specified smbd [$smbd]
echo --static enable static build [$static]
echo --mandir=PATHinstall man pages in PATH
-echo --datadir=PATH install firmware in PATH
+echo --datadir=PATH install firmware in PATH/qemu
echo --docdir=PATHinstall documentation in PATH
echo --bindir=PATHinstall binaries in PATH
echo --sysconfdir=PATHinstall config in PATH/qemu
@@ -2838,6 +2838,7 @@ if test $mingw32 = yes ; then
fi
qemu_confdir=$sysconfdir$confsuffix
+qemu_datadir=$datadir$confsuffix
tools=
if test $softmmu = yes ; then
--
1.7.3.2
[Qemu-devel] [PATCH 04/13] arm_gic: Make the GIC its own sysbus device
Compile arm_gic.c as a standalone C file to produce a self contained
sysbus GIC device. Support the legacy usage by #include of the .c file
by making those users #define LEGACY_INCLUDED_GIC, so we can convert
them one by one.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
Makefile.target |1 +
hw/a15mpcore.c |1 +
hw/a9mpcore.c |1 +
hw/arm11mpcore.c|1 +
hw/arm_gic.c| 51 ++-
hw/armv7m_nvic.c|1 +
hw/exynos4210_gic.c |1 +
hw/realview_gic.c |1 +
8 files changed, 57 insertions(+), 1 deletions(-)
diff --git a/Makefile.target b/Makefile.target
index cff15f0..0d605d8 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -364,6 +364,7 @@ obj-arm-y += cadence_uart.o
obj-arm-y += cadence_ttc.o
obj-arm-y += cadence_gem.o
obj-arm-y += xilinx_zynq.o zynq_slcr.o
+obj-arm-y += arm_gic.o
obj-arm-y += realview_gic.o realview.o arm_sysctl.o arm11mpcore.o a9mpcore.o
obj-arm-y += exynos4210_gic.o exynos4210_combiner.o exynos4210.o
obj-arm-y += exynos4_boards.o exynos4210_uart.o exynos4210_pwm.o
diff --git a/hw/a15mpcore.c b/hw/a15mpcore.c
index 2e2ed42..54c0dbf 100644
--- a/hw/a15mpcore.c
+++ b/hw/a15mpcore.c
@@ -20,6 +20,7 @@
#include sysbus.h
+#define LEGACY_INCLUDED_GIC
#include arm_gic.c
/* A15MP private memory region. */
diff --git a/hw/a9mpcore.c b/hw/a9mpcore.c
index 1d83c37..164a0d3 100644
--- a/hw/a9mpcore.c
+++ b/hw/a9mpcore.c
@@ -10,6 +10,7 @@
#include sysbus.h
+#define LEGACY_INCLUDED_GIC
#include arm_gic.c
/* A9MP private memory region. */
diff --git a/hw/arm11mpcore.c b/hw/arm11mpcore.c
index c4829d8..e876a0e 100644
--- a/hw/arm11mpcore.c
+++ b/hw/arm11mpcore.c
@@ -10,6 +10,7 @@
#include sysbus.h
#include qemu-timer.h
+#define LEGACY_INCLUDED_GIC
#include arm_gic.c
/* MPCore private memory region. */
diff --git a/hw/arm_gic.c b/hw/arm_gic.c
index fabbcc5..b0b6ec5 100644
--- a/hw/arm_gic.c
+++ b/hw/arm_gic.c
@@ -11,6 +11,8 @@
controller, MPCore distributed interrupt controller and ARMv7-M
Nested Vectored Interrupt Controller. */
+#include sysbus.h
+
/* Maximum number of possible interrupts, determined by the GIC architecture */
#define GIC_MAXIRQ 1020
/* First 32 are private to each CPU (SGIs and PPIs). */
@@ -112,7 +114,7 @@ typedef struct gic_state
int current_pending[NCPU];
#if NCPU 1
-int num_cpu;
+uint32_t num_cpu;
#endif
MemoryRegion iomem; /* Distributor */
@@ -906,3 +908,50 @@ static void gic_init(gic_state *s, int num_irq)
gic_reset(s);
register_savevm(NULL, arm_gic, -1, 2, gic_save, gic_load, s);
}
+
+#ifndef LEGACY_INCLUDED_GIC
+
+static int arm_gic_init(SysBusDevice *dev)
+{
+/* Device instance init function for the GIC sysbus device */
+int i;
+gic_state *s = FROM_SYSBUS(gic_state, dev);
+gic_init(s, s-num_cpu, s-num_irq);
+/* Distributor */
+sysbus_init_mmio(dev, s-iomem);
+/* cpu interfaces (one for current cpu plus one per cpu) */
+for (i = 0; i = NUM_CPU(s); i++) {
+sysbus_init_mmio(dev, s-cpuiomem[i]);
+}
+return 0;
+}
+
+static Property arm_gic_properties[] = {
+DEFINE_PROP_UINT32(num-cpu, gic_state, num_cpu, 1),
+DEFINE_PROP_UINT32(num-irq, gic_state, num_irq, 32),
+};
+
+static void arm_gic_class_init(ObjectClass *klass, void *data)
+{
+DeviceClass *dc = DEVICE_CLASS(klass);
+SysBusDeviceClass *sbc = SYS_BUS_DEVICE_CLASS(klass);
+sbc-init = arm_gic_init;
+dc-props = arm_gic_properties;
+dc-no_user = 1;
+}
+
+static TypeInfo arm_gic_info = {
+.name = arm_gic,
+.parent = TYPE_SYS_BUS_DEVICE,
+.instance_size = sizeof(gic_state),
+.class_init = arm_gic_class_init,
+};
+
+static void arm_gic_register_types(void)
+{
+type_register_static(arm_gic_info);
+}
+
+type_init(arm_gic_register_types)
+
+#endif
diff --git a/hw/armv7m_nvic.c b/hw/armv7m_nvic.c
index 99ed85b..79cf448 100644
--- a/hw/armv7m_nvic.c
+++ b/hw/armv7m_nvic.c
@@ -16,6 +16,7 @@
#include exec-memory.h
#define NVIC 1
+#define LEGACY_INCLUDED_GIC
static uint32_t nvic_readl(void *opaque, uint32_t offset);
static void nvic_writel(void *opaque, uint32_t offset, uint32_t value);
diff --git a/hw/exynos4210_gic.c b/hw/exynos4210_gic.c
index ff7ab84..a05dab2 100644
--- a/hw/exynos4210_gic.c
+++ b/hw/exynos4210_gic.c
@@ -262,6 +262,7 @@ uint32_t exynos4210_get_irq(uint32_t grp, uint32_t bit)
/* GIC part */
+#define LEGACY_INCLUDED_GIC
#include arm_gic.c
typedef struct {
diff --git a/hw/realview_gic.c b/hw/realview_gic.c
index aa780fe..a3b5a04 100644
--- a/hw/realview_gic.c
+++ b/hw/realview_gic.c
@@ -9,6 +9,7 @@
#include sysbus.h
+#define LEGACY_INCLUDED_GIC
#include arm_gic.c
typedef struct {
--
1.7.1
[Qemu-devel] [PATCH 2/4] target-s390x: QOM'ify CPU reset
Move code from cpu_state_reset() to s390_cpu_reset().
Signed-off-by: Andreas Färber afaer...@suse.de
Tested-by: Christian Borntraeger borntrae...@de.ibm.com
---
target-s390x/cpu.c| 13 -
target-s390x/helper.c | 12 ++--
2 files changed, 14 insertions(+), 11 deletions(-)
diff --git a/target-s390x/cpu.c b/target-s390x/cpu.c
index 94320f2..cae0b18 100644
--- a/target-s390x/cpu.c
+++ b/target-s390x/cpu.c
@@ -1,6 +1,8 @@
/*
* QEMU S/390 CPU
*
+ * Copyright (c) 2009 Ulrich Hecht
+ * Copyright (c) 2011 Alexander Graf
* Copyright (c) 2012 SUSE LINUX Products GmbH
*
* This library is free software; you can redistribute it and/or
@@ -23,15 +25,24 @@
#include qemu-timer.h
+/* CPUClass::reset() */
static void s390_cpu_reset(CPUState *s)
{
S390CPU *cpu = S390_CPU(s);
S390CPUClass *scc = S390_CPU_GET_CLASS(cpu);
CPUS390XState *env = cpu-env;
+if (qemu_loglevel_mask(CPU_LOG_RESET)) {
+qemu_log(CPU Reset (CPU %d)\n, env-cpu_index);
+log_cpu_state(env, 0);
+}
+
scc-parent_reset(s);
-cpu_state_reset(env);
+memset(env, 0, offsetof(CPUS390XState, breakpoints));
+/* FIXME: reset vector? */
+tlb_flush(env, 1);
+s390_add_running_cpu(env);
}
static void s390_cpu_class_init(ObjectClass *oc, void *data)
diff --git a/target-s390x/helper.c b/target-s390x/helper.c
index ae57ab3..cd3e8f5 100644
--- a/target-s390x/helper.c
+++ b/target-s390x/helper.c
@@ -97,7 +97,7 @@ CPUS390XState *cpu_s390x_init(const char *cpu_model)
env-cpu_model_str = cpu_model;
env-cpu_num = cpu_num++;
env-ext_index = -1;
-cpu_state_reset(env);
+cpu_reset(CPU(cpu));
qemu_init_vcpu(env);
return env;
}
@@ -123,15 +123,7 @@ int cpu_s390x_handle_mmu_fault (CPUS390XState *env,
target_ulong address, int rw
void cpu_state_reset(CPUS390XState *env)
{
-if (qemu_loglevel_mask(CPU_LOG_RESET)) {
-qemu_log(CPU Reset (CPU %d)\n, env-cpu_index);
-log_cpu_state(env, 0);
-}
-
-memset(env, 0, offsetof(CPUS390XState, breakpoints));
-/* FIXME: reset vector? */
-tlb_flush(env, 1);
-s390_add_running_cpu(env);
+cpu_reset(ENV_GET_CPU(env));
}
#ifndef CONFIG_USER_ONLY
--
1.7.7
[Qemu-devel] [PATCH 07/14] Makefile: use $(qemu_confdir) instead of $(sysconfdir)/qemu
Instead of hardcoding the directory suffix, use the qemu-specific directory variable. Signed-off-by: Eduardo Habkost ehabk...@redhat.com --- Makefile |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index 1c9abec..795f9c4 100644 --- a/Makefile +++ b/Makefile @@ -280,8 +280,8 @@ ifdef CONFIG_VIRTFS $(INSTALL_DATA) fsdev/virtfs-proxy-helper.1 $(DESTDIR)$(mandir)/man1 endif install-sysconfig: - $(INSTALL_DIR) $(DESTDIR)$(sysconfdir)/qemu - $(INSTALL_DATA) $(SRC_PATH)/sysconfigs/target/target-x86_64.conf $(DESTDIR)$(sysconfdir)/qemu + $(INSTALL_DIR) $(DESTDIR)$(qemu_confdir) + $(INSTALL_DATA) $(SRC_PATH)/sysconfigs/target/target-x86_64.conf $(DESTDIR)$(qemu_confdir) install: all $(if $(BUILD_DOCS),install-doc) install-sysconfig $(INSTALL_DIR) $(DESTDIR)$(bindir) -- 1.7.3.2
Re: [Qemu-devel] [PATCH 3/3] pseries: Add DPRINTF macros to spapr pci code
On 4 April 2012 20:18, Blue Swirl blauwir...@gmail.com wrote: On Mon, Apr 2, 2012 at 04:17, David Gibson da...@gibson.dropbear.id.au wrote: From: Alexey Kardashevskiy a...@ozlabs.ru This adds DPRINTF() macros with the usual conventions to the spapr_pci code. Please use tracepoints instead of printf statements. Tracing is more flexible, more efficient and does not suffer from bitrot. I'd much rather enable a #define to turn on debugging than faff about with tracing. It's simple and straightforward, you can do it with a single obvious change and recompile, and nobody has to look up documentation to figure out how it works. If tracepoints were always-compiled-in and enabled at runtime I'd agree with you: then you could have linux-kernel-style enable debug tracing, enable warnings about odd guest behaviour, be silent, etc. But they're not, so they don't gain anything over a simple DPRINTF for programmer debugging. -- PMM
[Qemu-devel] [PATCH v4 00/14] configure: --with-confsuffix option
I was going to resend only patch 14/14 with a fixed description, but then I noticed the series had to be rebased, with small conflicts on patches 04/14 and 12/14, so I am submitting the whole series again. Changes v3 - v4: - Rebase against latest qemu.git - Changed patch 14/14 subject to match the code (--with-confsuffix instead of --confsuffix) Changes v2 - v3: - Changes --datadir meaning to match Autoconf convention (meaning that it should point to /usr/share, not /usr/share/qemu). NOTE: this breaks compatibility. I don't know of anybody who uses that option today. Neither Fedora, Debian, Arch Linux, Gentoo, or FreeBSD use it[1]. - Add --with-confsuffix option, to allow the /etc/qemu and /usr/share/qemu directories to have a different names. [1] http://article.gmane.org/gmane.comp.emulators.qemu/142924 Series description: Most of the patches are variable renames and cleanups. The actual changes are only on the last 2 patches. First, internal configure variables are renamed, without changing config-host.mak: configure: rename $datadir to $qemu_datadir configure: rename $docdir to $qemu_docdir configure: rename $confdir to $qemu_confdir Then create_config gets ready for config-host.mak variable renames (Qemu-specific directories will now have a qemu_ prefix): create_config: separate section for qemu_*dir variables (v2) Then, variables are renamed on config-host.mak and Makefiles: config-host.mak: rename datadir to qemu_datadir config-host.mak: rename confdir to qemu_confdir Makefile: use $(qemu_confdir) instead of $(sysconfdir)/qemu config-host.mak: rename docdir to qemu_docdir config-host.mak: remove CONFIG_QEMU_SHAREDIR config-host.mak: reorder variables a bit Then old code on create_config is removed: create_config: remove *dir block create_config: simplify prefix=* block, remove CONFIG_QEMU_PREFIX Finally, the user-visible changes: configure: change meaning of --datadir to Autoconf convention configure: add --with-confsuffix option Eduardo Habkost (14): configure: rename $datadir to $qemu_datadir configure: rename $docdir to $qemu_docdir configure: rename $confdir to $qemu_confdir create_config: separate section for qemu_*dir variables (v2) config-host.mak: rename datadir to qemu_datadir config-host.mak: rename confdir to qemu_confdir Makefile: use $(qemu_confdir) instead of $(sysconfdir)/qemu config-host.mak: rename docdir to qemu_docdir config-host.mak: remove CONFIG_QEMU_SHAREDIR config-host.mak: reorder variables a bit create_config: remove *dir block create_config: simplify prefix=* block, remove CONFIG_QEMU_PREFIX configure: change meaning of --datadir to Autoconf convention configure: add --with-confsuffix option Makefile | 16 Makefile.target |4 ++-- configure | 29 - scripts/create_config |8 ++-- 4 files changed, 32 insertions(+), 25 deletions(-) -- 1.7.3.2
Re: [Qemu-devel] [PATCH 3/3] pseries: Add DPRINTF macros to spapr pci code
On Wed, Apr 4, 2012 at 20:11, Peter Maydell peter.mayd...@linaro.org wrote: On 4 April 2012 20:18, Blue Swirl blauwir...@gmail.com wrote: On Mon, Apr 2, 2012 at 04:17, David Gibson da...@gibson.dropbear.id.au wrote: From: Alexey Kardashevskiy a...@ozlabs.ru This adds DPRINTF() macros with the usual conventions to the spapr_pci code. Please use tracepoints instead of printf statements. Tracing is more flexible, more efficient and does not suffer from bitrot. I'd much rather enable a #define to turn on debugging than faff about with tracing. It's simple and straightforward, you can do it with a single obvious change and recompile, and nobody has to look up documentation to figure out how it works. Laziness. Even the built in help should be sufficient to start using tracepoints. If tracepoints were always-compiled-in and enabled at runtime I'd agree with you: then you could have linux-kernel-style enable debug tracing, enable warnings about odd guest behaviour, be silent, etc. But they're not, so they don't gain anything over a simple DPRINTF for programmer debugging. False. It's easy to compile in tracepoints (--enable-trace-backend=simple) and the overhead is zero or marginal. It's not possible to enable or disable DPRINTFs at run time easily which is trivial with tracepoints. When the tracepoints are enabled, due to binary format they are faster than text output. There's no need to relink the files when triggering on and off tracepoints. Trace files are much more compact than text. Processing is offline. Delta timestamps are provided. Tracepoints do not suffer from bitrot. From programming standpoint, DPRINTF is changed to a function call and the format text is put to a different file, that's it. Have you ever waded through hundreds of megabytes of DPRINTF stuff or other logs, 99.9% (literally, only a few bytes were interesting!) of it not what you want, just because the interesting stuff happens to be near to end of it? Even 'vi' is slow when handling these kind of files. Just for fun, try also enabling all DPRINTFs (small sed script exercise left to reader) and see how many breakages there are due to bit rotted DPRINTFs. -- PMM
[Qemu-devel] [PATCH 13/13] hw/arm_gic.c: Remove stray hardcoded tab
Remove the single instance of a hardcoded tab from hw/arm_gic.c.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
hw/arm_gic.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/hw/arm_gic.c b/hw/arm_gic.c
index f395e4b..a2aee63 100644
--- a/hw/arm_gic.c
+++ b/hw/arm_gic.c
@@ -160,7 +160,7 @@ static void gic_update(gic_state *s)
cm = 1 cpu;
s-current_pending[cpu] = 1023;
if (!s-enabled || !s-cpu_enabled[cpu]) {
- qemu_irq_lower(s-parent_irq[cpu]);
+qemu_irq_lower(s-parent_irq[cpu]);
return;
}
best_prio = 0x100;
--
1.7.1
Re: [Qemu-devel] [PATCH 1/2][sparc64] Fix vector interrupt handling
Thanks, applied both.
On Tue, Apr 3, 2012 at 15:49, Artyom Tarasenko atar4q...@gmail.com wrote:
Don't produce stray irq 5, don't overwrite ivec_data if still busy with
processing of the previous interrupt.
Signed-off-by: Artyom Tarasenko atar4q...@gmail.com
---
hw/sun4u.c | 29 -
1 files changed, 16 insertions(+), 13 deletions(-)
diff --git a/hw/sun4u.c b/hw/sun4u.c
index 1d67691..9d28194 100644
--- a/hw/sun4u.c
+++ b/hw/sun4u.c
@@ -315,19 +315,22 @@ static void cpu_set_ivec_irq(void *opaque, int irq, int
level)
CPUSPARCState *env = opaque;
if (level) {
- CPUIRQ_DPRINTF(Raise IVEC IRQ %d\n, irq);
- env-interrupt_index = TT_IVEC;
- env-pil_in |= 1 5;
- env-ivec_status |= 0x20;
- env-ivec_data[0] = (0x1f 6) | irq;
- env-ivec_data[1] = 0;
- env-ivec_data[2] = 0;
- cpu_interrupt(env, CPU_INTERRUPT_HARD);
- } else {
- CPUIRQ_DPRINTF(Lower IVEC IRQ %d\n, irq);
- env-pil_in = ~(1 5);
- env-ivec_status = ~0x20;
- cpu_reset_interrupt(env, CPU_INTERRUPT_HARD);
+ if (!(env-ivec_status 0x20)) {
+ CPUIRQ_DPRINTF(Raise IVEC IRQ %d\n, irq);
+ env-halted = 0;
+ env-interrupt_index = TT_IVEC;
+ env-ivec_status |= 0x20;
+ env-ivec_data[0] = (0x1f 6) | irq;
+ env-ivec_data[1] = 0;
+ env-ivec_data[2] = 0;
+ cpu_interrupt(env, CPU_INTERRUPT_HARD);
+ }
+ } else {
+ if (env-ivec_status 0x20) {
+ CPUIRQ_DPRINTF(Lower IVEC IRQ %d\n, irq);
+ env-ivec_status = ~0x20;
+ cpu_reset_interrupt(env, CPU_INTERRUPT_HARD);
+ }
}
}
--
1.7.3.4
Re: [Qemu-devel] [PATCH 5/6] main-loop: replace WaitForMultipleObjects with g_poll
On Tue, Mar 20, 2012 at 09:49, Paolo Bonzini pbonz...@redhat.com wrote:
On w32, glib implements g_poll using WaitForMultipleObjects
or MsgWaitForMultipleObjects. This means that we can simplify
our code by switching to g_poll, and at the same time prepare for
adding back glib sources.
Unfortunately g_poll does not seem to be available in glib-2.0:
CCmain-loop.o
/src/qemu/main-loop.c: In function 'os_host_main_loop_wait':
/src/qemu/main-loop.c:438: warning: implicit declaration of function 'g_poll'
/src/qemu/main-loop.c:438: warning: nested extern declaration of 'g_poll'
LINK qemu-img.exe
main-loop.o: In function `os_host_main_loop_wait':
/src/qemu/main-loop.c:438: undefined reference to `_g_poll'
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
main-loop.c | 40 +---
1 files changed, 17 insertions(+), 23 deletions(-)
diff --git a/main-loop.c b/main-loop.c
index 7364074..4d02568 100644
--- a/main-loop.c
+++ b/main-loop.c
@@ -220,9 +220,9 @@ int main_loop_init(void)
static fd_set rfds, wfds, xfds;
static int nfds;
+static GPollFD poll_fds[1024 * 2]; /* this is probably overkill */
#ifndef _WIN32
-static GPollFD poll_fds[1024 * 2]; /* this is probably overkill */
static int n_poll_fds;
static int max_priority;
@@ -351,6 +351,7 @@ void qemu_del_polling_cb(PollingFunc *func, void *opaque)
/* Wait objects support */
typedef struct WaitObjects {
int num;
+ int revents[MAXIMUM_WAIT_OBJECTS + 1];
HANDLE events[MAXIMUM_WAIT_OBJECTS + 1];
WaitObjectFunc *func[MAXIMUM_WAIT_OBJECTS + 1];
void *opaque[MAXIMUM_WAIT_OBJECTS + 1];
@@ -367,6 +368,7 @@ int qemu_add_wait_object(HANDLE handle, WaitObjectFunc
*func, void *opaque)
w-events[w-num] = handle;
w-func[w-num] = func;
w-opaque[w-num] = opaque;
+ w-revents[w-num] = 0;
w-num++;
return 0;
}
@@ -385,6 +387,7 @@ void qemu_del_wait_object(HANDLE handle, WaitObjectFunc
*func, void *opaque)
w-events[i] = w-events[i + 1];
w-func[i] = w-func[i + 1];
w-opaque[i] = w-opaque[i + 1];
+ w-revents[i] = w-revents[i + 1];
}
}
if (found) {
@@ -400,9 +403,8 @@ void qemu_fd_register(int fd)
static int os_host_main_loop_wait(int timeout)
{
- int ret, ret2, i;
+ int ret, i;
PollingEntry *pe;
- int err;
WaitObjects *w = wait_objects;
static struct timeval tv0;
@@ -422,33 +424,25 @@ static int os_host_main_loop_wait(int timeout)
}
}
+ for (i = 0; i w-num; i++) {
+ poll_fds[i].fd = (DWORD) w-events[i];
+ poll_fds[i].events = G_IO_IN;
+ }
+
qemu_mutex_unlock_iothread();
- ret = WaitForMultipleObjects(w-num, w-events, FALSE, timeout);
+ ret = g_poll(poll_fds, w-num, timeout);
qemu_mutex_lock_iothread();
- if (WAIT_OBJECT_0 + 0 = ret ret = WAIT_OBJECT_0 + w-num - 1) {
- if (w-func[ret - WAIT_OBJECT_0]) {
- w-func[ret - WAIT_OBJECT_0](w-opaque[ret - WAIT_OBJECT_0]);
+ if (ret 0) {
+ for (i = 0; i w-num; i++) {
+ w-revents[i] = poll_fds[i].revents;
}
-
- /* Check for additional signaled events */
- for (i = (ret - WAIT_OBJECT_0 + 1); i w-num; i++) {
- /* Check if event is signaled */
- ret2 = WaitForSingleObject(w-events[i], 0);
- if (ret2 == WAIT_OBJECT_0) {
- if (w-func[i]) {
- w-func[i](w-opaque[i]);
- }
- } else if (ret2 != WAIT_TIMEOUT) {
- err = GetLastError();
- fprintf(stderr, WaitForSingleObject error %d %d\n, i, err);
+ for (i = 0; i w-num; i++) {
+ if (w-revents[i] w-func[i]) {
+ w-func[i](w-opaque[i]);
}
}
- } else if (ret != WAIT_TIMEOUT) {
- err = GetLastError();
- fprintf(stderr, WaitForMultipleObjects error %d %d\n, ret, err);
}
-
/* If an edge-triggered socket event occurred, select will return a
* positive result on the next iteration. We do not need to do anything
* here.
--
1.7.7.6
Re: [Qemu-devel] [PATCH 3/3] pseries: Add DPRINTF macros to spapr pci code
On 4 April 2012 21:34, Blue Swirl blauwir...@gmail.com wrote: On Wed, Apr 4, 2012 at 20:11, Peter Maydell peter.mayd...@linaro.org wrote: I'd much rather enable a #define to turn on debugging than faff about with tracing. It's simple and straightforward, you can do it with a single obvious change and recompile, and nobody has to look up documentation to figure out how it works. Laziness. Even the built in help should be sufficient to start using tracepoints. Well, I looked at the docs and said this gives me no benefit over DPRINTF, and why do I have to create a file that explicitly lists every single event the code I'm interested in has defined, and the quickstart seems to be recommending something that you have to postprocess, and generally I dunno what problem this is trying to solve but it doesn't look like it's trying to solve programmer debug tracing. If other people want to write trace events that's fine but for me at the moment it seems a definite step back from simple DPRINTF macros. If tracepoints were always-compiled-in and enabled at runtime I'd agree with you: then you could have linux-kernel-style enable debug tracing, enable warnings about odd guest behaviour, be silent, etc. But they're not, so they don't gain anything over a simple DPRINTF for programmer debugging. False. It's easy to compile in tracepoints (--enable-trace-backend=simple) and the overhead is zero or marginal. (a) that gives you a binary dump rather than something actually readable (and 'simple' can't even handle string output!) and (b) if it's that good why don't we enable it by default? Also I can't see anything in the docs about having sensible sets of levels of tracing or grouping trace events into coherent sets you can toggle on and off. Processing is offline. For debugging this is not a feature -- you want to see the output as you step through things in the debugger. -- PMM
Re: [Qemu-devel] [PATCH 5/6] main-loop: replace WaitForMultipleObjects with g_poll
On 4 April 2012 21:44, Blue Swirl blauwir...@gmail.com wrote: On Tue, Mar 20, 2012 at 09:49, Paolo Bonzini pbonz...@redhat.com wrote: On w32, glib implements g_poll using WaitForMultipleObjects or MsgWaitForMultipleObjects. This means that we can simplify our code by switching to g_poll, and at the same time prepare for adding back glib sources. Unfortunately g_poll does not seem to be available in glib-2.0: Looks like it appeared in glib 2.19. We could maybe use an autobuilder configured for whatever the lowest glib version we support is, given how high the API churn seems to be :-/ -- PMM
[Qemu-devel] [PATCH V2 5/7] hw/pc.c: replace register_ioport*
This patch replaces all register_ioport* with portio_* or
isa_register_portio_list. It permits to use the new Memory
stuff like listener.
Signed-off-by: Julien Grall julien.gr...@citrix.com
---
hw/pc.c | 37 +++--
1 files changed, 23 insertions(+), 14 deletions(-)
diff --git a/hw/pc.c b/hw/pc.c
index 83a1b5b..6036393 100644
--- a/hw/pc.c
+++ b/hw/pc.c
@@ -592,6 +592,17 @@ int e820_add_entry(uint64_t address, uint64_t length,
uint32_t type)
return index;
}
+static const MemoryRegionPortio bochs_bios_portio_list[] = {
+{ 0x400, 2, 2, .write = bochs_bios_write, }, /* 0x400 */
+{ 0x402, 2, 1, .write = bochs_bios_write, }, /* 0x402 */
+{ 0x500, 1, 1, .write = bochs_bios_write, }, /* 0x500 */
+{ 0x501, 1, 1, .write = bochs_bios_write, }, /* 0x501 */
+{ 0x501, 2, 2, .write = bochs_bios_write, }, /* 0x501 */
+{ 0x503, 1, 1, .write = bochs_bios_write, }, /* 0x503 */
+{ 0x8900, 1, 1, .write = bochs_bios_write, }, /* 0x8900 */
+PORTIO_END_OF_LIST(),
+};
+
static void *bochs_bios_init(void)
{
void *fw_cfg;
@@ -599,18 +610,11 @@ static void *bochs_bios_init(void)
size_t smbios_len;
uint64_t *numa_fw_cfg;
int i, j;
+PortioList *bochs_bios_port_list = g_new(PortioList, 1);
-register_ioport_write(0x400, 1, 2, bochs_bios_write, NULL);
-register_ioport_write(0x401, 1, 2, bochs_bios_write, NULL);
-register_ioport_write(0x402, 1, 1, bochs_bios_write, NULL);
-register_ioport_write(0x403, 1, 1, bochs_bios_write, NULL);
-register_ioport_write(0x8900, 1, 1, bochs_bios_write, NULL);
-
-register_ioport_write(0x501, 1, 1, bochs_bios_write, NULL);
-register_ioport_write(0x501, 1, 2, bochs_bios_write, NULL);
-register_ioport_write(0x502, 1, 2, bochs_bios_write, NULL);
-register_ioport_write(0x500, 1, 1, bochs_bios_write, NULL);
-register_ioport_write(0x503, 1, 1, bochs_bios_write, NULL);
+portio_list_init(bochs_bios_port_list, bochs_bios_portio_list,
+ NULL, bosch-bios);
+portio_list_add(bochs_bios_port_list, get_system_io(), 0x0);
fw_cfg = fw_cfg_init(BIOS_CFG_IOPORT, BIOS_CFG_IOPORT + 1, 0, 0);
@@ -1077,6 +1081,12 @@ static void cpu_request_exit(void *opaque, int irq, int
level)
}
}
+static const MemoryRegionPortio pc_basic_portio_list[] = {
+{ 0x00, 1, 1, .write = ioport80_write, }, /* 0x80 */
+{ 0x70, 1, 1, .write = ioportF0_write, }, /* 0xf0 */
+PORTIO_END_OF_LIST(),
+};
+
void pc_basic_device_init(ISABus *isa_bus, qemu_irq *gsi,
ISADevice **rtc_state,
ISADevice **floppy,
@@ -1092,9 +1102,8 @@ void pc_basic_device_init(ISABus *isa_bus, qemu_irq *gsi,
ISADevice *i8042, *port92, *vmmouse, *pit;
qemu_irq *cpu_exit_irq;
-register_ioport_write(0x80, 1, 1, ioport80_write, NULL);
-
-register_ioport_write(0xf0, 1, 1, ioportF0_write, NULL);
+isa_register_portio_list(NULL, 0x80, pc_basic_portio_list, NULL,
+ pc-basic);
/*
* Check if an HPET shall be created.
--
Julien Grall
[Qemu-devel] [PATCH 04/14] create_config: separate section for qemu_*dir variables (v2)
The generic *dir section will eventually go away and be replaced with
qemu_* section. By now, both sections will be kept, while the variables
get renamed on config-host.mak.
With this patch, a XXXdir variable will become a CONFIG_QEMU_XXXDIR
define, and a qemu_XXXdir variable will become CONFIG_QEMU_XXXDIR as
well (instead of becoming a CONFIG_QEMU_QEMU_XXXDIR define).
Changes v1 - v2:
- Rebase on top of newer qemu.git changes, that changed
tr '[:lower:]' '[:upper:]' to LC_ALL=C tr '[a-z]' '[A-Z]'.
Signed-off-by: Eduardo Habkost ehabk...@redhat.com
---
scripts/create_config |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/scripts/create_config b/scripts/create_config
index 470e05e..f9ba2f5 100755
--- a/scripts/create_config
+++ b/scripts/create_config
@@ -13,6 +13,15 @@ case $line in
pkgversion=${line#*=}
echo #define QEMU_PKGVERSION \$pkgversion\
;;
+ qemu_*dir=*) # qemu-specific directory configuration
+name=${line%=*}
+value=${line#*=}
+define_name=`echo $name | LC_ALL=C tr '[a-z]' '[A-Z]'`
+eval define_value=\$value\
+echo #define CONFIG_$define_name \$define_value\
+# save for the next definitions
+eval $name=\$define_value
+;;
prefix=* | [a-z]*dir=*) # directory configuration
name=${line%=*}
value=${line#*=}
--
1.7.3.2
[Qemu-devel] [PATCH 06/14] config-host.mak: rename confdir to qemu_confdir
$confdir is a confusing name, as it's not clear if it's the system
config dir or the Qemus-specific directory inside the config dir.
$qemu_confdir makes it more clear.
The current C code that uses CONFIG_QEMU_CONFDIR should be safe, as now
create_config generates the same #define name (CONFIG_QEMU_CONFDIR) for
both confdir and qemu_confdir variables.
Signed-off-by: Eduardo Habkost ehabk...@redhat.com
---
configure |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/configure b/configure
index 76144aa..7009030 100755
--- a/configure
+++ b/configure
@@ -2983,7 +2983,7 @@ echo mandir=$mandir $config_host_mak
echo qemu_datadir=$qemu_datadir $config_host_mak
echo sysconfdir=$sysconfdir $config_host_mak
echo docdir=$qemu_docdir $config_host_mak
-echo confdir=$qemu_confdir $config_host_mak
+echo qemu_confdir=$qemu_confdir $config_host_mak
echo libexecdir=\${prefix}/libexec $config_host_mak
echo CONFIG_QEMU_SHAREDIR=\$prefix$datasuffix\ $config_host_mak
echo CONFIG_QEMU_HELPERDIR=\$prefix/libexec\ $config_host_mak
--
1.7.3.2
Re: [Qemu-devel] Windows Virtio Issue
Vadim Rozenfeld vrozenfe at redhat.com writes: Hi Paul, Managed to reproduce this problem, thank you. Going to fix it in the build. Meanwhile, instead of writeback, could you try cache=off ? Best regards, Vadim. Any news? I have the same issue with cache=off, there isn't any fix? Best regards, Emilien
Re: [Qemu-devel] [PATCH 13/14] configure: change meaning of --datadir to Autoconf convention
Il 30/03/2012 19:33, Eduardo Habkost ha scritto:
Autoconf uses --datadir for the /usr/share directory, not the
program-specific subdirectory inside /usr/share. This changes configure
to match autoconf behavior.
Note that this will break compatibility with existing build scripts.
Signed-off-by: Eduardo Habkost ehabk...@redhat.com
---
configure |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/configure b/configure
index 5de58cb..b74efe2 100755
--- a/configure
+++ b/configure
@@ -155,7 +155,7 @@ mingw32=no
EXESUF=
prefix=/usr/local
mandir=\${prefix}/share/man
-qemu_datadir=\${prefix}/share/qemu
+datadir=\${prefix}/share
qemu_docdir=\${prefix}/share/doc/qemu
bindir=\${prefix}/bin
libdir=\${prefix}/lib
@@ -521,7 +521,7 @@ EOF
fi
prefix=c:/Program Files/Qemu
mandir=\${prefix}
- qemu_datadir=\${prefix}
+ datadir=\${prefix}
qemu_docdir=\${prefix}
bindir=\${prefix}
sysconfdir=\${prefix}
This does not change anything because the next line is
confsuffix=
Nice. :)
Paolo
@@ -589,7 +589,7 @@ for opt do
;;
--includedir=*) includedir=$optarg
;;
- --datadir=*) qemu_datadir=$optarg
+ --datadir=*) datadir=$optarg
;;
--docdir=*) qemu_docdir=$optarg
;;
@@ -1007,7 +1007,7 @@ echo --python=PYTHON use specified python
[$python]
echo --smbd=SMBD use specified smbd [$smbd]
echo --static enable static build [$static]
echo --mandir=PATHinstall man pages in PATH
-echo --datadir=PATH install firmware in PATH
+echo --datadir=PATH install firmware in PATH/qemu
echo --docdir=PATHinstall documentation in PATH
echo --bindir=PATHinstall binaries in PATH
echo --sysconfdir=PATHinstall config in PATH/qemu
@@ -2831,6 +2831,7 @@ if test $mingw32 = yes ; then
fi
qemu_confdir=$sysconfdir$confsuffix
+qemu_datadir=$datadir$confsuffix
tools=
if test $softmmu = yes ; then
Re: [Qemu-devel] [PATCH 0/5] Spread the use of QEMU threading locking API
Il 04/04/2012 17:24, Jan Kiszka ha scritto: For patches 3 and 4, I'd rather use an EventNotifier... ...which still lacks support for non-eventfd systems. Hmm, I guess it's time to consolidate both. Perhaps you can take the relevant patches out of the thread-blocks branch at git://github.com/pbonzini/qemu.git? The iothread eventfd could also use an EventNotifier. Paolo
[Qemu-devel] [PATCH V2 1/7] isa: add isa_address_space_io
This function permits to retrieve ISA IO address space.
It will be usefull when we need to pass IO address space as argument.
Signed-off-by: Julien Grall julien.gr...@citrix.com
---
hw/isa-bus.c |5 +
hw/isa.h |1 +
2 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/hw/isa-bus.c b/hw/isa-bus.c
index 5a43f03..043e1f7 100644
--- a/hw/isa-bus.c
+++ b/hw/isa-bus.c
@@ -235,4 +235,9 @@ MemoryRegion *isa_address_space(ISADevice *dev)
return get_system_memory();
}
+MemoryRegion *isa_address_space_io(ISADevice *dev)
+{
+return get_system_io();
+}
+
type_init(isabus_register_types)
diff --git a/hw/isa.h b/hw/isa.h
index 40373fb..a9bf65a 100644
--- a/hw/isa.h
+++ b/hw/isa.h
@@ -42,6 +42,7 @@ void isa_bus_irqs(ISABus *bus, qemu_irq *irqs);
qemu_irq isa_get_irq(ISADevice *dev, int isairq);
void isa_init_irq(ISADevice *dev, qemu_irq *p, int isairq);
MemoryRegion *isa_address_space(ISADevice *dev);
+MemoryRegion *isa_address_space_io(ISADevice *dev);
ISADevice *isa_create(ISABus *bus, const char *name);
ISADevice *isa_try_create(ISABus *bus, const char *name);
ISADevice *isa_create_simple(ISABus *bus, const char *name);
--
Julien Grall
[Qemu-devel] [PATCH v2 2/2] target-sparc: QOM'ify CPU
Embed CPUSPARCState as first member of SPARCCPU.
Drop cpu_sparc_close() in favor of object_delete() and a finalizer.
Let cpu_state_reset() call cpu_reset().
Make TYPE_SPARC_CPU non-abstract for now.
Distinguish between sparc-cpu and sparc64-cpu.
Signed-off-by: Andreas Färber afaer...@suse.de
---
target-sparc/cpu-qom.h | 75
target-sparc/cpu.c | 68 +--
target-sparc/cpu.h |1 +
3 files changed, 135 insertions(+), 9 deletions(-)
create mode 100644 target-sparc/cpu-qom.h
diff --git a/target-sparc/cpu-qom.h b/target-sparc/cpu-qom.h
new file mode 100644
index 000..3d3ac0f
--- /dev/null
+++ b/target-sparc/cpu-qom.h
@@ -0,0 +1,75 @@
+/*
+ * QEMU SPARC CPU
+ *
+ * Copyright (c) 2012 SUSE LINUX Products GmbH
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see
+ * http://www.gnu.org/licenses/lgpl-2.1.html
+ */
+#ifndef QEMU_SPARC_CPU_QOM_H
+#define QEMU_SPARC_CPU_QOM_H
+
+#include qemu/cpu.h
+#include cpu.h
+
+#ifdef TARGET_SPARC64
+#define TYPE_SPARC_CPU sparc64-cpu
+#else
+#define TYPE_SPARC_CPU sparc-cpu
+#endif
+
+#define SPARC_CPU_CLASS(klass) \
+OBJECT_CLASS_CHECK(SPARCCPUClass, (klass), TYPE_SPARC_CPU)
+#define SPARC_CPU(obj) \
+OBJECT_CHECK(SPARCCPU, (obj), TYPE_SPARC_CPU)
+#define SPARC_CPU_GET_CLASS(obj) \
+OBJECT_GET_CLASS(SPARCCPUClass, (obj), TYPE_SPARC_CPU)
+
+/**
+ * SPARCCPUClass:
+ * @parent_reset: The parent class' reset handler.
+ *
+ * A SPARC CPU model.
+ */
+typedef struct SPARCCPUClass {
+/* private */
+CPUClass parent_class;
+/* public */
+
+void (*parent_reset)(CPUState *cpu);
+} SPARCCPUClass;
+
+/**
+ * SPARCCPU:
+ * @env: #CPUSPARCState
+ *
+ * A SPARC CPU.
+ */
+typedef struct SPARCCPU {
+/* private */
+CPUState parent_obj;
+/* public */
+
+CPUSPARCState env;
+} SPARCCPU;
+
+static inline SPARCCPU *sparc_env_get_cpu(CPUSPARCState *env)
+{
+return SPARC_CPU(container_of(env, SPARCCPU, env));
+}
+
+#define ENV_GET_CPU(e) CPU(sparc_env_get_cpu(e))
+
+
+#endif
diff --git a/target-sparc/cpu.c b/target-sparc/cpu.c
index 5c03f0b..24f90f1 100644
--- a/target-sparc/cpu.c
+++ b/target-sparc/cpu.c
@@ -25,11 +25,23 @@ static int cpu_sparc_find_by_name(sparc_def_t *cpu_def,
const char *cpu_model);
void cpu_state_reset(CPUSPARCState *env)
{
+cpu_reset(ENV_GET_CPU(env));
+}
+
+/* CPUClass::reset() */
+static void sparc_cpu_reset(CPUState *s)
+{
+SPARCCPU *cpu = SPARC_CPU(s);
+SPARCCPUClass *scc = SPARC_CPU_GET_CLASS(cpu);
+CPUSPARCState *env = cpu-env;
+
if (qemu_loglevel_mask(CPU_LOG_RESET)) {
qemu_log(CPU Reset (CPU %d)\n, env-cpu_index);
log_cpu_state(env, 0);
}
+scc-parent_reset(s);
+
memset(env, 0, offsetof(CPUSPARCState, breakpoints));
tlb_flush(env, 1);
env-cwp = 0;
@@ -99,23 +111,18 @@ static int cpu_sparc_register(CPUSPARCState *env, const
char *cpu_model)
return 0;
}
-static void cpu_sparc_close(CPUSPARCState *env)
-{
-g_free(env-def);
-g_free(env);
-}
-
CPUSPARCState *cpu_sparc_init(const char *cpu_model)
{
+SPARCCPU *cpu;
CPUSPARCState *env;
-env = g_new0(CPUSPARCState, 1);
-cpu_exec_init(env);
+cpu = SPARC_CPU(object_new(TYPE_SPARC_CPU));
+env = cpu-env;
gen_intermediate_code_init(env);
if (cpu_sparc_register(env, cpu_model) 0) {
-cpu_sparc_close(env);
+object_delete(OBJECT(cpu));
return NULL;
}
qemu_init_vcpu(env);
@@ -847,3 +854,46 @@ void cpu_dump_state(CPUSPARCState *env, FILE *f,
fprintf_function cpu_fprintf,
env-fsr, env-y);
#endif
}
+
+static void sparc_cpu_initfn(Object *obj)
+{
+SPARCCPU *cpu = SPARC_CPU(obj);
+CPUSPARCState *env = cpu-env;
+
+cpu_exec_init(env);
+}
+
+static void sparc_cpu_uninitfn(Object *obj)
+{
+SPARCCPU *cpu = SPARC_CPU(obj);
+CPUSPARCState *env = cpu-env;
+
+g_free(env-def);
+}
+
+static void sparc_cpu_class_init(ObjectClass *oc, void *data)
+{
+SPARCCPUClass *scc = SPARC_CPU_CLASS(oc);
+CPUClass *cc = CPU_CLASS(oc);
+
+scc-parent_reset = cc-reset;
+cc-reset = sparc_cpu_reset;
+}
+
+static const TypeInfo sparc_cpu_type_info = {
+.name = TYPE_SPARC_CPU,
+.parent = TYPE_CPU,
+.instance_size = sizeof(SPARCCPU),
+.instance_init = sparc_cpu_initfn,
+.instance_finalize =
Re: [Qemu-devel] PL353 Device model
On Fri, Mar 30, 2012 at 5:13 PM, Peter Crosthwaite peter.crosthwa...@petalogix.com wrote: We currently have a somewhat hacky PL353 device model in our tree that we wish to refactor and ultimately push to mainline. Before I go about reworking it, I wish to discuss the architecture of this device model because its non-trivial. Ping.. We'd really appreciate some feedback on this to avoid the duplicated effort we are seeing in other areas such as SPI. Thanks, John -- John Williams, PhD, B. Eng, B. IT PetaLogix - Linux Solutions for a Reconfigurable World w: www.petalogix.com p: +61-7-30090663 f: +61-7-30090663
Re: [Qemu-devel] [PATCH v2 0/2] Xilinx Zynq PL330 support
On Fri, Mar 30, 2012 at 5:58 PM, Peter A. G. Crosthwaite peter.crosthwa...@petalogix.com wrote: These patches add support for the Primcell PL330 DMA controller and add it to the Xilinx Zynq machine model. Patch 1 is the device model. Patch 2 is the machine model update. The Device model was originally contributed by Kirill Batuzov / Samsung, as indicated by the (C) notice in hw/pl330.c. Ping... Any obstacles to this going in? Peter has revised according to all feedback received so far, and has sign-off from original authors etc. Thanks, John
Re: [Qemu-devel] PL353 Device model
Hello John, Am 05.04.2012 01:35, schrieb John Williams: On Fri, Mar 30, 2012 at 5:13 PM, Peter Crosthwaite peter.crosthwa...@petalogix.com wrote: We currently have a somewhat hacky PL353 device model in our tree that we wish to refactor and ultimately push to mainline. Before I go about reworking it, I wish to discuss the architecture of this device model because its non-trivial. Ping.. We'd really appreciate some feedback on this to avoid the duplicated effort we are seeing in other areas such as SPI. Generally speaking, the qdev busses (i.e., tree-style) are scheduled to die out in favor of DAG-style QOM. However that's not going to happen for 1.1 yet, so if there's a need for a new SPI bus it needs to be qdev. As for the desired cascading here, my idea would be to make both flash interfaces childs of the controller, arranging their MemoryRegions so that (if applicable) they become subregions and can be toggled by the controller. My .02 AUD, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
