[Qemu-devel] [PATCH] gtk: Remove unused include statements which are not portable
These include files don't exist for MinGW and are not needed for Linux (and hopefully for other hosts as well), so remove them. Signed-off-by: Stefan Weil s...@weilnetz.de --- ui/gtk.c |4 1 file changed, 4 deletions(-) diff --git a/ui/gtk.c b/ui/gtk.c index c38146f..b5f4f0b 100644 --- a/ui/gtk.c +++ b/ui/gtk.c @@ -51,10 +51,6 @@ #include glib/gi18n.h #include locale.h #include vte/vte.h -#include sys/types.h -#include sys/socket.h -#include sys/un.h -#include sys/wait.h #include math.h #include ui/console.h -- 1.7.10.4
[Qemu-devel] How to write a backend receiving routine
Hi, all I'm a beginner with QEMU. I'm trying to write a CAN device and also a backend. However while I try to write a backend receiving routine, some thing confuse me. I hope I can get some help here. Actually, I try to figure out how backend udp works at first, also a serial pci acts as a frontend. The functions qemu_set_fd_handler2() and qemu_chr_add_handlers() are used for backend udp and frontend serial pci seperatly to register the necessary routines. In the function main_loop_wait() in main-loop.c will check whether we need to receive some data, if needed, data will be read from backend. Following is the question. I change serial_can_receive1()-hw/serial.c which is registered to test if we need data to return 1 always. So that means we always need data. In main_loop_wait() which actually call main_loop_wait()-os_host_main_loop_wait()-select(), I have checked that before select() called the udp file descriptor has set in rfds. So, if we send some data to the udp backend, the bit in rfds should be set and finally the receive routine we register though qemu_chr_add_handlers() should be called. However, the receiving routine has never been called. I do not know why? And then I try to start QEMU with the following commands, -serial none -chardev udp,id=UDPserial,port=3334 -device pci-serial,chardev=UDPserial and connect it with nc -u -l -p 3334. Before I insert the linux driver, I try to send some data to qemu, the receiving routine still never be called. After the driver has been inserted, input command echo test/dev/ttyS0 then the receiving routine is called. Why? When input cat /dev/ttyS0 and input some characters in host, the receiving routine is also called. I think this is correct. So what is the correct routine to receive some data from backend? How does this work? Can anyone help me with that. I will appreciate it very much. Thanks, Jin Yang
Re: [Qemu-devel] [PATCH v3 0/2] future proof rom loading for cross versiom migration
On Tue, Aug 13, 2013 at 01:43:29AM +0300, Michael S. Tsirkin wrote: Changes from v2: address comments on v2 by Peter Maydell - switch from global constant to function - use memory_region_init_ram instead of _ram_ptr - disable for 1.6 Changes from v1: address comments by Peter Maydell - drop useless data=data line - rename target_page_size to migration_page_size to make use clear Peter, you also suggested somehow hiding this within memory core. I don't see a clean way to do this without lots of code changes, I think what I propose here is acceptable for now and we can always rework APIs without wire format changes. Please review, and consider for merging. Ping. Any more comments? Also - which tree can this go in through? Mine? Original cover letter below. ROM files that are put in FW CFG are copied to guest ram, by BIOS, but they are not backed by RAM so they don't get migrated. Each time we'll change at least two bytes in such a ROM this will break cross-version migration: since we can migrate after BIOS has read the first byte but before it has read the second one, getting an inconsistent state. This patchset makes QEMU future-proof against such changes. Naturally, this only helps for -M 1.6 and up, older machine types will still have the cross-version migration bug. I think this should be applied for 1.6, this way we won't have this problem from 1.7 and on. Michael S. Tsirkin (2): memory: export migration page size loader: put FW CFG ROM files into RAM arch_init.c | 6 ++ hw/core/loader.c | 54 --- hw/i386/pc_piix.c | 2 ++ hw/i386/pc_q35.c | 2 ++ include/exec/memory.h | 1 + include/hw/loader.h | 1 + 6 files changed, 63 insertions(+), 3 deletions(-) -- MST
[Qemu-devel] [PATCH] pc: cleanup 1.4 compat support
Make 1.4 compat code call the 1.6 one, reducing
code duplication. Add comment explaining why we can't
make 1.4 call 1.5 as usual.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
hw/i386/pc_piix.c | 4 ++--
hw/i386/pc_q35.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 15c932e..86cfadc 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -272,8 +272,8 @@ static void pc_init_pci_1_4(QEMUMachineInitArgs *args)
{
x86_cpu_compat_set_features(n270, FEAT_1_ECX, 0, CPUID_EXT_MOVBE);
x86_cpu_compat_set_features(Westmere, FEAT_1_ECX, 0,
CPUID_EXT_PCLMULQDQ);
-has_pci_info = false;
-pc_init_pci(args);
+/* 1.5 was special - it enabled pvpanic in builtin machine */
+pc_init_pci_1_6(args);
}
static void pc_init_pci_1_3(QEMUMachineInitArgs *args)
diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index 09d8183..8d62700 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -239,8 +239,8 @@ static void pc_q35_init_1_4(QEMUMachineInitArgs *args)
{
x86_cpu_compat_set_features(n270, FEAT_1_ECX, 0, CPUID_EXT_MOVBE);
x86_cpu_compat_set_features(Westmere, FEAT_1_ECX, 0,
CPUID_EXT_PCLMULQDQ);
-has_pci_info = false;
-pc_q35_init(args);
+/* 1.5 was special - it enabled pvpanic in builtin machine */
+pc_q35_init_1_6(args);
}
static QEMUMachine pc_q35_machine_v1_6 = {
--
MST
Re: [Qemu-devel] minimal linux distribution for qemu
good to know. I was working back in 2005-2006 with a company that had a 4MB kernel. At that time I was too inexperienced to work at that level but I thought now I could reproduce their work with some help. Anyhow for the moment I'll go for 256 MB of ram board just so that I don't worry too much about things that are not yet relevant for me. But thanks again for the warning. But since you helped me soo much I have another question. Is it fisible to change the emulator so that I may visualize the following aspects: _ address of the currently executed instruction from the guest system _ if this instruction is a form of jump like call return conditional jump. _ the address or range of addresses read by this instruction _ the address or range of addresses written by this instruction I read some things about the emulator and if I understood it correctly the emulator breaks the instructions of the gurest platform in micro ops which are then executed on the host operation system. So I'm asking the question above in the idea that maybe there is also somekind of reordering of these micro instructions. best regards, dacian From: Rob Landley r...@landley.net To: Herbei Dacian dacian_her...@yahoo.fr Cc: Peter Maydell peter.mayd...@linaro.org; QEmu Devel qemu-devel@nongnu.org Sent: Sunday, 18 August 2013, 8:00 Subject: Re: [Qemu-devel] minimal linux distribution for qemu On 08/16/2013 11:17:06 AM, Herbei Dacian wrote: my system should run in far less memory. something like 2-4MB. but first I need to have a system running so that I can monitor with qemu the addresses accessed for read execute and write by the code run by the emulator. if I reach that is a real big deal. dacian Linux 2.6 and later won't run in 2 megs at all. You can trim it down to 4 megs on a nommu system (the page tables take up too much ram otherwise), but won't be able to do much. Really, things like kobjects in the modern kernel take up too much space. Getting anything to work in 4 megs requires diabling all the printk strings at compile time. (The last time I saw somebody do a 4 meg system was CELF in 2006. 32 bit x86.) Look at the uClinux project. Or try to bolt your app onto uboot and run it on the bare metal. Rob
Re: [Qemu-devel] [PATCH] pc: cleanup 1.4 compat support
Am 18.08.2013 15:50, schrieb Michael S. Tsirkin: Make 1.4 compat code call the 1.6 one, reducing code duplication. Add comment explaining why we can't make 1.4 call 1.5 as usual. Signed-off-by: Michael S. Tsirkin m...@redhat.com --- hw/i386/pc_piix.c | 4 ++-- hw/i386/pc_q35.c | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) Reviewed-by: Andreas Färber afaer...@suse.de 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 0/7] introduce BSD-licensed block driver for raw
Il 16/08/2013 16:59, Anthony Liguori ha scritto: Laszlo Ersek ler...@redhat.com writes: Paolo asked me to write such a driver based on his textual specification alone. The first patch captures his email in full, the rest re-quotes parts that are being implemented. The tree compiles at each patch. The series passes make check-block. block/raw.c is not removed because I wanted to keep it out of my series and out of my brain. Disclaimer: I couldn't care less if the raw block driver was public domain or AGPLv3+, as long as it qualifies as free software. I'm only trying to do what Paolo asked of me. Generally speaking, rewriting parts of QEMU to be !GPL is something I would strongly, strongly oppose. I believe that Paolo had a good reason for this though. The reason is that Christoph said his original version of block/raw.c was meant to be GPLv2-only. I don't care if the file is BSD or LGPLv2+, but most of the block layer is BSD, which is why I went for BSD. It's been a while since I audited the files that would go into libqemublock, but I remember the only problematic files were block/raw.c (unlicensed) and block/vdi.c (GPLv2+). Not having VirtualBox support wouldn't be a big deal. Paolo
Re: [Qemu-devel] [PATCH 7/7] switch raw block driver from raw.o to raw_bsd.o
Il 16/08/2013 16:15, Laszlo Ersek ha scritto:
+static int raw_reopen_prepare(BDRVReopenState *reopen_state,
+ BlockReopenQueue *queue, Error **errp)
{
-return bdrv_reopen_prepare(bs-file);
+BDRVReopenState tmp = *reopen_state;
+
+tmp.bs = tmp.bs-file;
+return bdrv_reopen_prepare(tmp, queue, errp);
}
This should just return zero, my fault.
Paolo
Re: [Qemu-devel] [PATCH 1/1] mc146818rtc: correct UIP hold length
Il 14/08/2013 16:10, James Hogan ha scritto:
The UIP (update in progress) hold time was set to 8 32.768KHz clock
cycles (around 244uS). However the timing diagram in the datasheet
(Figure 16) shows that the UIP bit is held for both the update cycle
time (either 248uS or 1984uS depending on the clock source), and the
minimum time before update cycle (244uS).
It's clear from periodic_timer_update() that only a 32.768KHz clock
source is expected, so correct the hold time to 244uS + 1984uS = 73
32.768KHz clock cycles.
I am not sure if this time would actually go from t-244us to t+1984us on
real hardware? You could measure this using a divider reset and
sampling PF and UF.
The emulation right now does instant updates, which elegantly
sidesteps the problem. :)
Signed-off-by: James Hogan james.ho...@imgtec.com
Cc: Andreas Färber afaer...@suse.de
Cc: Anthony Liguori aligu...@us.ibm.com
Cc: Igor Mammedov imamm...@redhat.com
Cc: Paolo Bonzini pbonz...@redhat.com
Cc: Yang Zhang yang.z.zh...@intel.com
---
hw/timer/mc146818rtc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/timer/mc146818rtc.c b/hw/timer/mc146818rtc.c
index 3c3baac..6000feb 100644
--- a/hw/timer/mc146818rtc.c
+++ b/hw/timer/mc146818rtc.c
@@ -55,7 +55,7 @@
#define RTC_REINJECT_ON_ACK_COUNT 20
#define RTC_CLOCK_RATE32768
-#define UIP_HOLD_LENGTH (8 * NSEC_PER_SEC / 32768)
+#define UIP_HOLD_LENGTH (73 * NSEC_PER_SEC / 32768)
#define MC146818_RTC(obj) OBJECT_CHECK(RTCState, (obj), TYPE_MC146818_RTC)
@@ -597,7 +597,7 @@ static int update_in_progress(RTCState *s)
}
guest_nsec = get_guest_rtc_ns(s);
-/* UIP bit will be set at last 244us of every second. */
+/* UIP bit will be set at last 1984us + 244us of every second. */
if ((guest_nsec % NSEC_PER_SEC) = (NSEC_PER_SEC - UIP_HOLD_LENGTH)) {
return 1;
}
Re: [Qemu-devel] [PATCH for-1.6] pc: fix up pc initialization
Il 13/08/2013 17:57, Andreas Färber ha scritto: Am 13.08.2013 17:27, schrieb Paolo Bonzini: All that should happen is that after migration you will not get panic notifications on the destination. Well, how does the Linux driver cope with pvpanic device present on boot but not present on panic? ISA PIO is not usually expected to be hot-unplugged. ;) On panic, the driver does a single outb. That outb will simply go to the bitbucket. Paolo
Re: [Qemu-devel] [PATCH v2 4/4] timer: make qemu_clock_enable sync between disable and timer's cb
Il 14/08/2013 02:34, liu ping fan ha scritto:
On Tue, Aug 13, 2013 at 10:53 PM, Paolo Bonzini pbonz...@redhat.com wrote:
Il 13/08/2013 07:43, Liu Ping Fan ha scritto:
After disabling the QemuClock, we should make sure that no QemuTimers
are still in flight. To implement that with light overhead, we resort
to QemuEvent. The caller of disabling will wait on QemuEvent of each
timerlist.
Note, qemu_clock_enable(foo,false) can _not_ be called from timer's cb.
And the callers of qemu_clock_enable() should be sync by themselves,
not protected by this patch.
Signed-off-by: Liu Ping Fan pingf...@linux.vnet.ibm.com
---
include/qemu/timer.h | 4
qemu-timer.c | 53
+++-
2 files changed, 56 insertions(+), 1 deletion(-)
diff --git a/include/qemu/timer.h b/include/qemu/timer.h
index 829c005..2b755c9 100644
--- a/include/qemu/timer.h
+++ b/include/qemu/timer.h
@@ -184,6 +184,10 @@ void qemu_clock_notify(QEMUClockType type);
* @enabled: true to enable, false to disable
*
* Enable or disable a clock
+ * Disabling the clock will wait for related timerlists to stop
+ * executing qemu_run_timers. Thus, this functions should not
+ * be used from the callback of a timer that is based on @clock.
+ * Doing so would cause a deadlock.
*/
void qemu_clock_enable(QEMUClockType type, bool enabled);
diff --git a/qemu-timer.c b/qemu-timer.c
index 5b9a722..8b32e92 100644
--- a/qemu-timer.c
+++ b/qemu-timer.c
@@ -48,6 +48,12 @@ typedef struct QEMUClock {
QLIST_HEAD(, QEMUTimerList) timerlists;
NotifierList reset_notifiers;
+/* While the reader holds this lock, it may block on events_list.
+ * So the modifier should be carefuly not to reset the event before
+ * holding this lock. Otherwise, deadlock.
+ */
+QemuMutex events_list_lock;
+GList *events_list;
No need for a separate list. Just use the timerlists list; if
events_list needs a lock, timerlists needs one too.
Here is a ugly pattern issue, we hold events_list_lock and wait for
QemuEvent set. If the modifier reset the QemuEvent and then try to
hold the events_list_lock, then _deadlock_. To eliminate the
possibility, using @events_list_lock, and you can see the modifier
can not reset QemuEvent while trying to own the lock. On the other
handle, if using lock on timerlists, since many entrance to access the
lock, we are not sure of avoiding deadlock
But does timerlists need a lock, or does the BQL suffice? If it
doesn't, there is no need for events_list_lock either. Is
qemu_clock_enable called outside the BQL?
Paolo
Regards,
Pingfan
int64_t last;
QEMUClockType type;
@@ -70,6 +76,8 @@ struct QEMUTimerList {
QLIST_ENTRY(QEMUTimerList) list;
QEMUTimerListNotifyCB *notify_cb;
void *notify_opaque;
+/* light weight method to mark the end of timerlist's running */
+QemuEvent *ev;
Also no need to malloc this one.
Paolo
};
/**
@@ -90,6 +98,25 @@ static bool timer_expired_ns(QEMUTimer *timer_head,
int64_t current_time)
return timer_head (timer_head-expire_time = current_time);
}
+static QemuEvent *qemu_clock_new_qemu_event(QEMUClock *clock)
+{
+QemuEvent *ev = g_malloc(sizeof(QemuEvent));
+
+qemu_event_init(ev, true);
+qemu_mutex_lock(clock-events_list_lock);
+clock-events_list = g_list_append(clock-events_list, ev);
+qemu_mutex_unlock(clock-events_list_lock);
+return ev;
+}
+
+static void qemu_clock_free_qemu_event(QEMUClock *clock, QemuEvent *ev)
+{
+qemu_mutex_lock(clock-events_list_lock);
+clock-events_list = g_list_remove(clock-events_list, ev);
+qemu_mutex_unlock(clock-events_list_lock);
+qemu_event_destroy(ev);
+}
+
QEMUTimerList *timerlist_new(QEMUClockType type,
QEMUTimerListNotifyCB *cb,
void *opaque)
@@ -98,6 +125,7 @@ QEMUTimerList *timerlist_new(QEMUClockType type,
QEMUClock *clock = qemu_clock_ptr(type);
timer_list = g_malloc0(sizeof(QEMUTimerList));
+timer_list-ev = qemu_clock_new_qemu_event(clock);
timer_list-clock = clock;
timer_list-notify_cb = cb;
timer_list-notify_opaque = opaque;
@@ -109,6 +137,7 @@ void timerlist_free(QEMUTimerList *timer_list)
{
assert(!timerlist_has_timers(timer_list));
if (timer_list-clock) {
+qemu_clock_free_qemu_event(timer_list-clock, timer_list-ev);
QLIST_REMOVE(timer_list, list);
}
g_free(timer_list);
@@ -122,6 +151,7 @@ static void qemu_clock_init(QEMUClockType type)
clock-enabled = true;
clock-last = INT64_MIN;
QLIST_INIT(clock-timerlists);
+qemu_mutex_init(clock-events_list_lock);
notifier_list_init(clock-reset_notifiers);
main_loop_tlg.tl[type] = timerlist_new(type, NULL, NULL);
}
@@ -140,6 +170,17 @@ void qemu_clock_notify(QEMUClockType type)
}
}
+static void
Re: [Qemu-devel] [PATCH v2 1/4] vmdk: fix L1 and L2 table size in vmdk3 open
Il 13/08/2013 03:21, Fam Zheng ha scritto: VMDK3 header has the field l1dir_size, but vmdk_open_vmdk3 hardcoded the value. This patch honors the header field. And the L2 table size is 4096 according to VMDK spec[1], instead of 1 9 (512). I'm not sure from the VMDK spec that _only_ 4096 is supported for VMDK3 files. The way I read it, VMDK3 files in hosted products are supposed to have 2K grain tables (as specified by vmdk_open_vmdk3). Perhaps we can check if L1size * 64 is enough to cover the whole file, and if not use 4096? Paolo [1]: http://www.vmware.com/support/developer/vddk/vmdk_50_technote.pdf?src=vmdk
Re: [Qemu-devel] [PATCH] powerpc iommu: enable multiple TCE requests
Il 16/08/2013 11:49, Alexey Kardashevskiy ha scritto:
With KVM, we could fall back to the qemu implementation
+ * when KVM doesn't support them, but that would be much slower
+ * than just using the KVM implementations of the single TCE
+ * hypercalls. */
+if (kvmppc_spapr_use_multitce()) {
+_FDT((fdt_property(fdt, ibm,hypertas-functions, hypertas_propm,
+ sizeof(hypertas_propm;
+} else {
+_FDT((fdt_property(fdt, ibm,hypertas-functions, hypertas_prop,
+ sizeof(hypertas_prop;
+}
This prevents migration from newer kernel to older kernel. Can you
ensure that the fallback to the QEMU implementation works, even though
it is not used in practice?
Paolo
[Qemu-devel] [PATCH] misc: Fix some typos in names and comments
Most typos were found using a modified version of codespell:
accross - across
issueing - issuing
TICNT_THRESHHOLD - TICNT_THRESHOLD
bandwith - bandwidth
VCARD_7816_PROPIETARY - VCARD_7816_PROPRIETARY
occured - occurred
gaurantee - guarantee
sofware - software
Signed-off-by: Stefan Weil s...@weilnetz.de
---
Existing violations of the QEMU coding style (tabulators)
were not fixed, so checkpatch.pl reports six errors.
Regards,
Stefan
block/backup.c |2 +-
hw/s390x/css.c |2 +-
hw/timer/exynos4210_rtc.c|4 ++--
include/hw/bt.h |8
libcacard/card_7816.c|2 +-
libcacard/card_7816t.h |2 +-
linux-headers/asm-powerpc/epapr_hcalls.h |4 ++--
migration-rdma.c |6 +++---
8 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/block/backup.c b/block/backup.c
index 6ae8a05..a55a960 100644
--- a/block/backup.c
+++ b/block/backup.c
@@ -290,7 +290,7 @@ static void coroutine_fn backup_run(void *opaque)
for (i = 0; i BACKUP_SECTORS_PER_CLUSTER;) {
/* bdrv_co_is_allocated() only returns true/false based
- * on the first set of sectors it comes accross that
+ * on the first set of sectors it comes across that
* are are all in the same state.
* For that reason we must verify each sector in the
* backup cluster length. We end up copying more than
diff --git a/hw/s390x/css.c b/hw/s390x/css.c
index 93b0b97..101da63 100644
--- a/hw/s390x/css.c
+++ b/hw/s390x/css.c
@@ -124,7 +124,7 @@ static void sch_handle_clear_func(SubchDev *sch)
/* Path management: In our simple css, we always choose the only path. */
path = 0x80;
-/* Reset values prior to 'issueing the clear signal'. */
+/* Reset values prior to 'issuing the clear signal'. */
p-lpum = 0;
p-pom = 0xff;
s-flags = ~SCSW_FLAGS_MASK_PNO;
diff --git a/hw/timer/exynos4210_rtc.c b/hw/timer/exynos4210_rtc.c
index 3f2c8c5..026f81a 100644
--- a/hw/timer/exynos4210_rtc.c
+++ b/hw/timer/exynos4210_rtc.c
@@ -67,7 +67,7 @@
#define CURTICNT0x0090
#define TICK_TIMER_ENABLE 0x0100
-#define TICNT_THRESHHOLD2
+#define TICNT_THRESHOLD 2
#define RTC_ENABLE 0x0001
@@ -429,7 +429,7 @@ static void exynos4210_rtc_write(void *opaque, hwaddr
offset,
s-reg_rtccon = value;
break;
case TICCNT:
-if (value TICNT_THRESHHOLD) {
+if (value TICNT_THRESHOLD) {
s-reg_ticcnt = value;
} else {
fprintf(stderr,
diff --git a/include/hw/bt.h b/include/hw/bt.h
index 830af94..3f365bc 100644
--- a/include/hw/bt.h
+++ b/include/hw/bt.h
@@ -640,8 +640,8 @@ typedef struct {
#define OCF_SETUP_SYNC_CONN0x0028
typedef struct {
uint16_t handle;
-uint32_t tx_bandwith;
-uint32_t rx_bandwith;
+uint32_t tx_bandwidth;
+uint32_t rx_bandwidth;
uint16_t max_latency;
uint16_t voice_setting;
uint8_tretrans_effort;
@@ -652,8 +652,8 @@ typedef struct {
#define OCF_ACCEPT_SYNC_CONN_REQ 0x0029
typedef struct {
bdaddr_t bdaddr;
-uint32_t tx_bandwith;
-uint32_t rx_bandwith;
+uint32_t tx_bandwidth;
+uint32_t rx_bandwidth;
uint16_t max_latency;
uint16_t voice_setting;
uint8_tretrans_effort;
diff --git a/libcacard/card_7816.c b/libcacard/card_7816.c
index 8d06326..c28bb60 100644
--- a/libcacard/card_7816.c
+++ b/libcacard/card_7816.c
@@ -232,7 +232,7 @@ vcard_apdu_set_class(VCardAPDU *apdu) {
case 0xf0:
default:
apdu-a_gen_type =
-(apdu-a_cla == 0xff) ? VCARD_7816_PTS : VCARD_7816_PROPIETARY;
+(apdu-a_cla == 0xff) ? VCARD_7816_PTS : VCARD_7816_PROPRIETARY;
break;
}
return VCARD7816_STATUS_SUCCESS;
diff --git a/libcacard/card_7816t.h b/libcacard/card_7816t.h
index 9333285..8eef0ce 100644
--- a/libcacard/card_7816t.h
+++ b/libcacard/card_7816t.h
@@ -43,7 +43,7 @@ typedef enum {
VCARD_7816_ISO,
VCARD_7816_RFU,
VCARD_7816_PTS,
-VCARD_7816_PROPIETARY
+VCARD_7816_PROPRIETARY
} VCardAPDUType;
diff --git a/linux-headers/asm-powerpc/epapr_hcalls.h
b/linux-headers/asm-powerpc/epapr_hcalls.h
index 06f7247..33b3f89 100644
--- a/linux-headers/asm-powerpc/epapr_hcalls.h
+++ b/linux-headers/asm-powerpc/epapr_hcalls.h
@@ -78,7 +78,7 @@
#define EV_SUCCESS 0
#define EV_EPERM 1 /* Operation not permitted */
#define EV_ENOENT 2 /* Entry Not Found */
-#define EV_EIO 3 /* I/O error occured */
+#define EV_EIO 3 /* I/O error occurred */
#define EV_EAGAIN 4 /* The operation had insufficient
[Qemu-devel] (no subject)
From 1273f8b2e5464ec987facf9942fd3ccc0b69087e Mon Sep 17 00:00:00 2001
From: Liu Jinsong jinsong@intel.com
Date: Mon, 19 Aug 2013 09:33:30 +0800
Subject: [PATCH] qemu-kvm bugfix for IA32_FEATURE_CONTROL
This patch is to fix the bug https://bugs.launchpad.net/qemu-kvm/+bug/1207623
IA32_FEATURE_CONTROL is pointless if not expose VMX or SMX bits to
cpuid.1.ecx of vcpu. Current qemu-kvm will error return when kvm_put_msrs
or kvm_get_msrs.
Signed-off-by: Liu Jinsong jinsong@intel.com
---
target-i386/kvm.c | 16 ++--
1 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index 84ac00a..7facbfe 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -65,6 +65,7 @@ static bool has_msr_star;
static bool has_msr_hsave_pa;
static bool has_msr_tsc_adjust;
static bool has_msr_tsc_deadline;
+static bool has_msr_feature_control;
static bool has_msr_async_pf_en;
static bool has_msr_pv_eoi_en;
static bool has_msr_misc_enable;
@@ -644,6 +645,11 @@ int kvm_arch_init_vcpu(CPUState *cs)
qemu_add_vm_change_state_handler(cpu_update_state, env);
+c = cpuid_find_entry(cpuid_data.cpuid, 1, 0);
+if (c)
+has_msr_feature_control = !!(c-ecx CPUID_EXT_VMX) |
+ !!(c-ecx CPUID_EXT_SMX);
+
cpuid_data.cpuid.padding = 0;
r = kvm_vcpu_ioctl(cs, KVM_SET_CPUID2, cpuid_data);
if (r) {
@@ -1121,7 +1127,10 @@ static int kvm_put_msrs(X86CPU *cpu, int level)
if (hyperv_vapic_recommended()) {
kvm_msr_entry_set(msrs[n++], HV_X64_MSR_APIC_ASSIST_PAGE, 0);
}
-kvm_msr_entry_set(msrs[n++], MSR_IA32_FEATURE_CONTROL,
env-msr_ia32_feature_control);
+if (has_msr_feature_control) {
+kvm_msr_entry_set(msrs[n++], MSR_IA32_FEATURE_CONTROL,
+ env-msr_ia32_feature_control);
+}
}
if (env-mcg_cap) {
int i;
@@ -1346,7 +1355,9 @@ static int kvm_get_msrs(X86CPU *cpu)
if (has_msr_misc_enable) {
msrs[n++].index = MSR_IA32_MISC_ENABLE;
}
-msrs[n++].index = MSR_IA32_FEATURE_CONTROL;
+if (has_msr_feature_control) {
+msrs[n++].index = MSR_IA32_FEATURE_CONTROL;
+}
if (!env-tsc_valid) {
msrs[n++].index = MSR_IA32_TSC;
@@ -1447,6 +1458,7 @@ static int kvm_get_msrs(X86CPU *cpu)
break;
case MSR_IA32_FEATURE_CONTROL:
env-msr_ia32_feature_control = msrs[i].data;
+break;
default:
if (msrs[i].index = MSR_MC0_CTL
msrs[i].index MSR_MC0_CTL + (env-mcg_cap 0xff) * 4) {
--
1.7.1
0001-qemu-kvm-bugfix-for-IA32_FEATURE_CONTROL.patch
Description: 0001-qemu-kvm-bugfix-for-IA32_FEATURE_CONTROL.patch
[Qemu-devel] [PATCH] qemu-kvm bugfix for IA32_FEATURE_CONTROL
From 1273f8b2e5464ec987facf9942fd3ccc0b69087e Mon Sep 17 00:00:00 2001
From: Liu Jinsong jinsong@intel.com
Date: Mon, 19 Aug 2013 09:33:30 +0800
Subject: [PATCH] qemu-kvm bugfix for IA32_FEATURE_CONTROL
This patch is to fix the bug https://bugs.launchpad.net/qemu-kvm/+bug/1207623
IA32_FEATURE_CONTROL is pointless if not expose VMX or SMX bits to
cpuid.1.ecx of vcpu. Current qemu-kvm will error return when kvm_put_msrs
or kvm_get_msrs.
Signed-off-by: Liu Jinsong jinsong@intel.com
---
target-i386/kvm.c | 16 ++--
1 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index 84ac00a..7facbfe 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -65,6 +65,7 @@ static bool has_msr_star;
static bool has_msr_hsave_pa;
static bool has_msr_tsc_adjust;
static bool has_msr_tsc_deadline;
+static bool has_msr_feature_control;
static bool has_msr_async_pf_en;
static bool has_msr_pv_eoi_en;
static bool has_msr_misc_enable;
@@ -644,6 +645,11 @@ int kvm_arch_init_vcpu(CPUState *cs)
qemu_add_vm_change_state_handler(cpu_update_state, env);
+c = cpuid_find_entry(cpuid_data.cpuid, 1, 0);
+if (c)
+has_msr_feature_control = !!(c-ecx CPUID_EXT_VMX) |
+ !!(c-ecx CPUID_EXT_SMX);
+
cpuid_data.cpuid.padding = 0;
r = kvm_vcpu_ioctl(cs, KVM_SET_CPUID2, cpuid_data);
if (r) {
@@ -1121,7 +1127,10 @@ static int kvm_put_msrs(X86CPU *cpu, int level)
if (hyperv_vapic_recommended()) {
kvm_msr_entry_set(msrs[n++], HV_X64_MSR_APIC_ASSIST_PAGE, 0);
}
-kvm_msr_entry_set(msrs[n++], MSR_IA32_FEATURE_CONTROL,
env-msr_ia32_feature_control);
+if (has_msr_feature_control) {
+kvm_msr_entry_set(msrs[n++], MSR_IA32_FEATURE_CONTROL,
+ env-msr_ia32_feature_control);
+}
}
if (env-mcg_cap) {
int i;
@@ -1346,7 +1355,9 @@ static int kvm_get_msrs(X86CPU *cpu)
if (has_msr_misc_enable) {
msrs[n++].index = MSR_IA32_MISC_ENABLE;
}
-msrs[n++].index = MSR_IA32_FEATURE_CONTROL;
+if (has_msr_feature_control) {
+msrs[n++].index = MSR_IA32_FEATURE_CONTROL;
+}
if (!env-tsc_valid) {
msrs[n++].index = MSR_IA32_TSC;
@@ -1447,6 +1458,7 @@ static int kvm_get_msrs(X86CPU *cpu)
break;
case MSR_IA32_FEATURE_CONTROL:
env-msr_ia32_feature_control = msrs[i].data;
+break;
default:
if (msrs[i].index = MSR_MC0_CTL
msrs[i].index MSR_MC0_CTL + (env-mcg_cap 0xff) * 4) {
--
1.7.1
0001-qemu-kvm-bugfix-for-IA32_FEATURE_CONTROL.patch
Description: 0001-qemu-kvm-bugfix-for-IA32_FEATURE_CONTROL.patch
Re: [Qemu-devel] [PATCH] qemu-kvm bugfix for IA32_FEATURE_CONTROL
Am 18.08.2013 20:23, schrieb Liu, Jinsong: From 1273f8b2e5464ec987facf9942fd3ccc0b69087e Mon Sep 17 00:00:00 2001 From: Liu Jinsong jinsong@intel.com Date: Mon, 19 Aug 2013 09:33:30 +0800 Subject: [PATCH] qemu-kvm bugfix for IA32_FEATURE_CONTROL This patch is to fix the bug https://bugs.launchpad.net/qemu-kvm/+bug/1207623 IA32_FEATURE_CONTROL is pointless if not expose VMX or SMX bits to cpuid.1.ecx of vcpu. Current qemu-kvm will error return when kvm_put_msrs or kvm_get_msrs. Signed-off-by: Liu Jinsong jinsong@intel.com --- target-i386/kvm.c | 16 ++-- 1 files changed, 14 insertions(+), 2 deletions(-) Hello, please check your patch with scripts/checkpatch.pl before sending it to the list. For boolean operands, the boolean or (||) is better than the bitwise or (|). Regards, Stefan
Re: [Qemu-devel] [PATCH for-1.6] isa: fix documentation of isa_register_portio_list
Ping. Hervé Poussineau a écrit : Signed-off-by: Hervé Poussineau hpous...@reactos.org --- include/hw/isa/isa.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/hw/isa/isa.h b/include/hw/isa/isa.h index 495bcf3..fa45a5b 100644 --- a/include/hw/isa/isa.h +++ b/include/hw/isa/isa.h @@ -78,7 +78,7 @@ void isa_register_ioport(ISADevice *dev, MemoryRegion *io, uint16_t start); * @dev: the ISADevice against which these are registered; may be NULL. * @start: the base I/O port against which the portio-offset is applied. * @portio: the ports, sorted by offset. - * @opaque: passed into the old_portio callbacks. + * @opaque: passed into the portio callbacks. * @name: passed into memory_region_init_io. */ void isa_register_portio_list(ISADevice *dev, uint16_t start,
Re: [Qemu-devel] [PATCH for-1.6] adlib: sort offsets in portio registration
Ping.
CCing stable too.
Hervé
Hervé Poussineau a écrit :
This fixes the following assert when -device adlib is used:
ioport.c:240: portio_list_add: Assertion `pio-offset = off_last' failed.
Signed-off-by: Hervé Poussineau hpous...@reactos.org
---
hw/audio/adlib.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/audio/adlib.c b/hw/audio/adlib.c
index 0421d47..db4a953 100644
--- a/hw/audio/adlib.c
+++ b/hw/audio/adlib.c
@@ -284,9 +284,9 @@ static void Adlib_fini (AdlibState *s)
}
static MemoryRegionPortio adlib_portio_list[] = {
-{ 0x388, 4, 1, .read = adlib_read, .write = adlib_write, },
{ 0, 4, 1, .read = adlib_read, .write = adlib_write, },
{ 0, 2, 1, .read = adlib_read, .write = adlib_write, },
+{ 0x388, 4, 1, .read = adlib_read, .write = adlib_write, },
PORTIO_END_OF_LIST(),
};
[Qemu-devel] [Bug 688085] Re: Guest kernel hang during boot when KVM is active on i386 host
This release has reached end-of-life [0]. [0] https://wiki.ubuntu.com/Releases ** Changed in: linux (Ubuntu Maverick) Status: New = Invalid -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/688085 Title: Guest kernel hang during boot when KVM is active on i386 host Status in meego project: Fix Released Status in QEMU: Fix Released Status in qemu-kvm: Fix Released Status in “kvm” package in Ubuntu: Invalid Status in “linux” package in Ubuntu: Fix Released Status in “qemu” package in Ubuntu: Invalid Status in “qemu-kvm” package in Ubuntu: Invalid Status in “kvm” source package in Maverick: New Status in “linux” source package in Maverick: Invalid Status in “qemu” source package in Maverick: New Status in “qemu-kvm” source package in Maverick: New Bug description: Binary package hint: qemu Guest kernel hang during boot when KVM is active on i386 host See the patch. http://www.spinics.net/lists/kvm/msg40800.html How to reproduce: 1. install Maversick x86 (not amd64) 2. ensure you have kvm support in processor 3. kvm -kernel /boot/initrd.img-2.6.35-24-generic-pae 4. kvm -no-kvm -kernel /boot/initrd.img-2.6.35-24-generic-pae works OK. SRU Justification: Impact: Users cannot boot KVM guests on i386 hosts 2. How bug addressed: The upstream commit at http://www.spinics.net/lists/kvm/msg40800.html fixed it 3. Patch: A kernel patch is attached to this bug. 4. Reproduce: boot an i386 kernel on a kvm-capable host. Try to boot a kvm guest. 5. Regression potential: since this is cherrypicking a commit from a future upstream which had already been changed, regression is possible. However if there is a regression, it should only affect users of KVM on i386 hosts, which currently fail anyway. To manage notifications about this bug go to: https://bugs.launchpad.net/meego/+bug/688085/+subscriptions
[Qemu-devel] [PATCH] kvm: shoten the parameter list for get_real_device()
get_real_device() has 5 parameters with the last 4 is contained in the first
structure.
This patch removes the last 4 parameters and directly use them from the first
parameter.
Signed-off-by: Wei Yang weiy...@linux.vnet.ibm.com
---
hw/i386/kvm/pci-assign.c |9 -
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/hw/i386/kvm/pci-assign.c b/hw/i386/kvm/pci-assign.c
index 5618173..011764f 100644
--- a/hw/i386/kvm/pci-assign.c
+++ b/hw/i386/kvm/pci-assign.c
@@ -568,8 +568,7 @@ static int get_real_device_id(const char *devpath, uint16_t
*val)
return get_real_id(devpath, device, val);
}
-static int get_real_device(AssignedDevice *pci_dev, uint16_t r_seg,
- uint8_t r_bus, uint8_t r_dev, uint8_t r_func)
+static int get_real_device(AssignedDevice *pci_dev)
{
char dir[128], name[128];
int fd, r = 0, v;
@@ -582,7 +581,8 @@ static int get_real_device(AssignedDevice *pci_dev,
uint16_t r_seg,
dev-region_number = 0;
snprintf(dir, sizeof(dir), /sys/bus/pci/devices/%04x:%02x:%02x.%x/,
- r_seg, r_bus, r_dev, r_func);
+ pci_dev-host.domain, pci_dev-host.bus,
+ pci_dev-host.slot, pci_dev-host.function);
snprintf(name, sizeof(name), %sconfig, dir);
@@ -1769,8 +1769,7 @@ static int assigned_initfn(struct PCIDevice *pci_dev)
memcpy(dev-emulate_config_write, dev-emulate_config_read,
sizeof(dev-emulate_config_read));
-if (get_real_device(dev, dev-host.domain, dev-host.bus,
-dev-host.slot, dev-host.function)) {
+if (get_real_device(dev)) {
error_report(pci-assign: Error: Couldn't get real device (%s)!,
dev-dev.qdev.id);
goto out;
--
1.7.5.4
Re: [Qemu-devel] [PATCH v2 1/4] vmdk: fix L1 and L2 table size in vmdk3 open
On Sun, 08/18 17:19, Paolo Bonzini wrote: Il 13/08/2013 03:21, Fam Zheng ha scritto: VMDK3 header has the field l1dir_size, but vmdk_open_vmdk3 hardcoded the value. This patch honors the header field. And the L2 table size is 4096 according to VMDK spec[1], instead of 1 9 (512). I'm not sure from the VMDK spec that _only_ 4096 is supported for VMDK3 files. The way I read it, VMDK3 files in hosted products are supposed to have 2K grain tables (as specified by vmdk_open_vmdk3). I presume COWD is only specified in ESXi Host Sparse Extents section, which is also in practice the only known use case to me. There it says Grain tables have 4096 entries. I think you meant 2KB grain table specified in section Hosted Sparse Extent Metadata, with 512 entries. If so, it should be for VMDK4 with KDMV magic bytes, so doesn't affect COWD. Fam Perhaps we can check if L1size * 64 is enough to cover the whole file, and if not use 4096? Paolo [1]: http://www.vmware.com/support/developer/vddk/vmdk_50_technote.pdf?src=vmdk
[Qemu-devel] [Bug 1180777] Re: Windows 7 VM freeze on Ubuntu 12.04 KVM
Hi, I reported the #1212051 (https://bugs.launchpad.net/ubuntu/+source/qemu- kvm/+bug/1212051) bug with Windows XP, but reading this case i think it could be the same issue. I connect via RDP to my windows XP VM and after a while it seems to freeze, then, I connect via VNC an without doing anything the communications are restored between the VM and the outside world. So i can connect again with RDP. Even more, if i leave an open connection with VNC (minimized because is more slow than RDP), connecting via RDP has no trouble and no problem of freeze (lost of communications) occurs. f3a97, Could you do this test and tell if you have the same experience than i?, If so, my bug is the same of this. Thanks. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1180777 Title: Windows 7 VM freeze on Ubuntu 12.04 KVM Status in QEMU: New Status in “qemu-kvm” package in Ubuntu: Confirmed Bug description: Hi, I have recently setup a Windows 7 VM on KVM and started using it through remote desktop. What happens is that, after some hours of usage, the remote desktop connection freezes. I thought it was a remmina bug, as the it was enough to kill and restart it to successfully connect again to the VM. However, today I've switched to a different RDP client (2X Client chromium app) and the freeze just happened again! Some information: - the host and the VM are completely idle when the freeze occurs - I've tried sniffing the network packets toward the RDP port during the freeze and found that the client is sending packets but no packet is sent back Could this be a KVM issue? How can I further debug this one (I expect the freeze to happen again...)? ProblemType: Bug DistroRelease: Ubuntu 12.04 Package: kvm 1:84+dfsg-0ubuntu16+1.0+noroms+0ubuntu14.8 ProcVersionSignature: Ubuntu 3.2.0-41.66-generic 3.2.42 Uname: Linux 3.2.0-41-generic x86_64 ApportVersion: 2.0.1-0ubuntu17.2 Architecture: amd64 Date: Thu May 16 14:12:40 2013 MachineType: Hewlett-Packard HP ProBook 4520s MarkForUpload: True ProcEnviron: TERM=xterm PATH=(custom, no user) LANG=en_US.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.2.0-41-generic root=UUID=D2E20BC3E20BAAB5 loop=/hostname/disks/root.disk ro quiet splash vt.handoff=7 SourcePackage: qemu-kvm UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 08/26/2010 dmi.bios.vendor: Hewlett-Packard dmi.bios.version: 68AZZ Ver. F.0A dmi.board.name: 1411 dmi.board.vendor: Hewlett-Packard dmi.board.version: KBC Version 57.30 dmi.chassis.type: 10 dmi.chassis.vendor: Hewlett-Packard dmi.modalias: dmi:bvnHewlett-Packard:bvr68AZZVer.F.0A:bd08/26/2010:svnHewlett-Packard:pnHPProBook4520s:pvr:rvnHewlett-Packard:rn1411:rvrKBCVersion57.30:cvnHewlett-Packard:ct10:cvr: dmi.product.name: HP ProBook 4520s dmi.sys.vendor: Hewlett-Packard To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1180777/+subscriptions
[Qemu-devel] [PATCH v3] spapr-pci: fix config space access to support bridges
spapr-pci config space accessors use find_dev() to find a PCI device.
However find_dev() only searched on a primary bus and did not do
recursive search through secondary buses so config space access was not
possible for devices other that on a primary bus.
This fixed find_dev() by using the PCI API pci_find_device() function.
This effectively enabled pci bridges on spapr.
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
Changes:
v3:
* added temporary variable for bus number
v2:
* fixed coding style
* config space access traces moved out
---
hw/ppc/spapr_pci.c | 12 ++--
1 file changed, 2 insertions(+), 10 deletions(-)
diff --git a/hw/ppc/spapr_pci.c b/hw/ppc/spapr_pci.c
index 1ca35a0..65be265 100644
--- a/hw/ppc/spapr_pci.c
+++ b/hw/ppc/spapr_pci.c
@@ -65,22 +65,14 @@ static PCIDevice *find_dev(sPAPREnvironment *spapr,
uint64_t buid,
{
sPAPRPHBState *sphb = find_phb(spapr, buid);
PCIHostState *phb = PCI_HOST_BRIDGE(sphb);
-BusState *bus = BUS(phb-bus);
-BusChild *kid;
+int bus_num = (config_addr 16) 0xFF;
int devfn = (config_addr 8) 0xFF;
if (!phb) {
return NULL;
}
-QTAILQ_FOREACH(kid, bus-children, sibling) {
-PCIDevice *dev = (PCIDevice *)kid-child;
-if (dev-devfn == devfn) {
-return dev;
-}
-}
-
-return NULL;
+return pci_find_device(phb-bus, bus_num, devfn);
}
static uint32_t rtas_pci_cfgaddr(uint32_t arg)
--
1.8.3.2
[Qemu-devel] [RFC PATCH v4] powerpc: add PVR mask support
IBM POWERPC processors encode PVR as a CPU family in higher 16 bits and
a CPU version in lower 16 bits. Since there is no significant change
in behavior between versions, there is no point to add every single CPU
version in QEMU's CPU list. Also, new CPU versions of already supported
CPU won't break the existing code.
This does the following:
1. add a PVR mask support for a CPU family (in this patch for POWER7 only);
2. make CPU family not abstract;
3. add a @pvr_default (probably bad name) - the idea when QEMU instantiates
POWERPC CPU from a CPU family class, this value will be written to PVR
before the guest starts; KVM uses this to pass the actual PVR value to
the guest if QEMU was started with -cpu host.
As CPU family class name for POWER7 is POWER7-family, there is no need
to touch aliases.
Cc: Andreas Färber afaer...@suse.de
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
This does not pretend to be the final valid patch which can go to any tree
(at least because it does need a POWER7+ family difinition and some bits
for POWER8 family), it is me again asking stupid question in order to
reduce my ignorance and get some understanding if anyone going to care of
the PVR masks problem. Thank you for comments.
ps. :)
---
Changes:
v4:
* removed bogus layer from hierarchy
v3:
* renamed macros to describe the functionality better
* added default PVR value for the powerpc cpu family (what alias used to do)
v2:
* aliases are replaced with another level in class hierarchy
---
target-ppc/cpu-models.c | 2 ++
target-ppc/cpu-models.h | 7 +++
target-ppc/cpu-qom.h| 2 ++
target-ppc/kvm.c| 2 ++
target-ppc/translate_init.c | 9 +++--
5 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/target-ppc/cpu-models.c b/target-ppc/cpu-models.c
index 8dea560..5ae88a5 100644
--- a/target-ppc/cpu-models.c
+++ b/target-ppc/cpu-models.c
@@ -44,6 +44,8 @@
PowerPCCPUClass *pcc = POWERPC_CPU_CLASS(oc); \
\
pcc-pvr = _pvr; \
+pcc-pvr_default = 0; \
+pcc-pvr_mask = CPU_POWERPC_DEFAULT_MASK; \
pcc-svr = _svr; \
dc-desc = _desc; \
} \
diff --git a/target-ppc/cpu-models.h b/target-ppc/cpu-models.h
index d9145d1..2233053 100644
--- a/target-ppc/cpu-models.h
+++ b/target-ppc/cpu-models.h
@@ -39,6 +39,7 @@ extern PowerPCCPUAlias ppc_cpu_aliases[];
/*/
/* PVR definitions for most known PowerPC*/
enum {
+CPU_POWERPC_DEFAULT_MASK = 0x,
/* PowerPC 401 family */
/* Generic PowerPC 401 */
#define CPU_POWERPC_401 CPU_POWERPC_401G2
@@ -557,6 +558,12 @@ enum {
CPU_POWERPC_POWER7_v23 = 0x003F0203,
CPU_POWERPC_POWER7P_v21= 0x004A0201,
CPU_POWERPC_POWER8_v10 = 0x004B0100,
+CPU_POWERPC_POWER7 = 0x003F,
+CPU_POWERPC_POWER7_MASK= 0x,
+CPU_POWERPC_POWER7P= 0x004A,
+CPU_POWERPC_POWER7P_MASK = 0x,
+CPU_POWERPC_POWER8 = 0x004B,
+CPU_POWERPC_POWER8_MASK= 0x,
CPU_POWERPC_970= 0x00390202,
CPU_POWERPC_970FX_v10 = 0x00391100,
CPU_POWERPC_970FX_v20 = 0x003C0200,
diff --git a/target-ppc/cpu-qom.h b/target-ppc/cpu-qom.h
index f3c710a..a1a712c 100644
--- a/target-ppc/cpu-qom.h
+++ b/target-ppc/cpu-qom.h
@@ -54,6 +54,8 @@ typedef struct PowerPCCPUClass {
void (*parent_reset)(CPUState *cpu);
uint32_t pvr;
+uint32_t pvr_default;
+uint32_t pvr_mask;
uint32_t svr;
uint64_t insns_flags;
uint64_t insns_flags2;
diff --git a/target-ppc/kvm.c b/target-ppc/kvm.c
index 30a870e..315e499 100644
--- a/target-ppc/kvm.c
+++ b/target-ppc/kvm.c
@@ -1731,6 +1731,8 @@ static void kvmppc_host_cpu_class_init(ObjectClass *oc,
void *data)
uint32_t dcache_size = kvmppc_read_int_cpu_dt(d-cache-size);
uint32_t icache_size = kvmppc_read_int_cpu_dt(i-cache-size);
+pcc-pvr_default = mfpvr();
+
/* Now fix up the class with information we can query from the host */
if (vmx != -1) {
diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c
index 13b290c..dfe398d 100644
--- a/target-ppc/translate_init.c
+++ b/target-ppc/translate_init.c
@@ -3104,7 +3104,6 @@ static int check_pow_hid0_74xx (CPUPPCState *env)
glue(glue(ppc_, _name), _cpu_family_type_info) = { \
.name = stringify(_name) -family- TYPE_POWERPC_CPU, \
Re: [Qemu-devel] [PATCH 0/2 v4] kvm irqfd: support msimessage to irq translation in PHB
On 08/07/2013 06:51 PM, Alexey Kardashevskiy wrote: Yet another try to push IRQFD support for sPAPR. This includes rework for QEMU and enablement for sPAPR PCI. Ping, anyone, please? Alexey Kardashevskiy (2): kvm irqfd: support msimessage to irq translation in PHB pseries: enable irqfd for pci hw/i386/kvm/pci-assign.c | 4 ++-- hw/intc/xics_kvm.c | 5 + hw/misc/vfio.c | 4 ++-- hw/pci/pci.c | 9 + hw/ppc/spapr_pci.c | 6 ++ hw/virtio/virtio-pci.c | 2 +- include/hw/pci/pci.h | 2 ++ include/hw/pci/pci_bus.h | 1 + kvm-all.c| 3 +++ 9 files changed, 31 insertions(+), 5 deletions(-) -- Alexey
[Qemu-devel] [PATCH v3 0/8] xics: reworks and in-kernel support
Yet another try with XICS-KVM. v2-v3: Addressed multiple comments from Andreas; Added 2 patches for XICS from Ben - I included them into the series as they are about XICS and they won't rebase automatically if moved before XICS rework so it seemed to me that it would be better to carry them toghether. If it is wrong, please let me know, I'll repost them separately. v1-v2: The main change is this adds xics-common parent for emulated XICS and XICS-KVM. And many, many small changes, mostly to address Andreas comments. Migration from XICS to XICS-KVM and vice versa still works. Alexey Kardashevskiy (4): xics: add pre_save/post_load/cpu_setup dispatchers xics: move registration of global state to realize() xics: minor changes and cleanups xics: split to xics and xics-common Benjamin Herrenschmidt (2): xics: Add H_IPOLL implementation xics: Implement H_XIRR_X David Gibson (2): target-ppc: Add helper for KVM_PPC_RTAS_DEFINE_TOKEN xics-kvm: Support for in-kernel XICS interrupt controller default-configs/ppc64-softmmu.mak | 1 + hw/intc/Makefile.objs | 1 + hw/intc/xics.c| 358 +-- hw/intc/xics_kvm.c| 492 ++ hw/ppc/spapr.c| 27 ++- include/hw/ppc/spapr.h| 3 +- include/hw/ppc/xics.h | 68 +- target-ppc/kvm.c | 14 ++ target-ppc/kvm_ppc.h | 7 + 9 files changed, 894 insertions(+), 77 deletions(-) create mode 100644 hw/intc/xics_kvm.c -- 1.8.3.2
[Qemu-devel] [PATCH v3 1/8] target-ppc: Add helper for KVM_PPC_RTAS_DEFINE_TOKEN
From: David Gibson da...@gibson.dropbear.id.au
Recent PowerKVM allows the kernel to intercept some RTAS calls from the
guest directly. This is used to implement the more efficient in-kernel
XICS for example. qemu is still responsible for assigning the RTAS token
numbers however, and needs to tell the kernel which RTAS function name is
assigned to a given token value. This patch adds a convenience wrapper for
the KVM_PPC_RTAS_DEFINE_TOKEN ioctl() which is used for this purpose.
Signed-off-by: David Gibson da...@gibson.dropbear.id.au
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
target-ppc/kvm.c | 14 ++
target-ppc/kvm_ppc.h | 7 +++
2 files changed, 21 insertions(+)
diff --git a/target-ppc/kvm.c b/target-ppc/kvm.c
index eea8c09..ab46aaa 100644
--- a/target-ppc/kvm.c
+++ b/target-ppc/kvm.c
@@ -1792,6 +1792,20 @@ static int kvm_ppc_register_host_cpu_type(void)
return 0;
}
+int kvmppc_define_rtas_token(uint32_t token, const char *function)
+{
+struct kvm_rtas_token_args args = {
+.token = token,
+};
+
+if (!kvm_check_extension(kvm_state, KVM_CAP_PPC_RTAS)) {
+return -ENOENT;
+}
+
+strncpy(args.name, function, sizeof(args.name));
+
+return kvm_vm_ioctl(kvm_state, KVM_PPC_RTAS_DEFINE_TOKEN, args);
+}
int kvmppc_get_htab_fd(bool write)
{
diff --git a/target-ppc/kvm_ppc.h b/target-ppc/kvm_ppc.h
index 4ae7bf2..12564ef 100644
--- a/target-ppc/kvm_ppc.h
+++ b/target-ppc/kvm_ppc.h
@@ -38,6 +38,7 @@ uint64_t kvmppc_rma_size(uint64_t current_size, unsigned int
hash_shift);
#endif /* !CONFIG_USER_ONLY */
int kvmppc_fixup_cpu(PowerPCCPU *cpu);
bool kvmppc_has_cap_epr(void);
+int kvmppc_define_rtas_token(uint32_t token, const char *function);
int kvmppc_get_htab_fd(bool write);
int kvmppc_save_htab(QEMUFile *f, int fd, size_t bufsize, int64_t max_ns);
int kvmppc_load_htab_chunk(QEMUFile *f, int fd, uint32_t index,
@@ -164,6 +165,12 @@ static inline bool kvmppc_has_cap_epr(void)
return false;
}
+static inline int kvmppc_define_rtas_token(uint32_t token,
+ const char *function)
+{
+return -1;
+}
+
static inline int kvmppc_get_htab_fd(bool write)
{
return -1;
--
1.8.3.2
[Qemu-devel] [PATCH v3 4/8] xics: minor changes and cleanups
Before XICS-KVM comes, it makes sense to clean up the emulated XICS a bit.
This does:
1. add assert in ics_realize()
2. change variable names from k to more informative ones
3. add const to every TypeInfo
4. replace fprintf(stderr, ...\n) with error_report
5. replace old style qdev_init_nofail() with new style
object_property_set_bool().
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
Changes:
v3:
* ics_realize() fixed to be actual realize callback rather than initfn
* asserts replaced with Error**
---
hw/intc/xics.c | 42 ++
1 file changed, 30 insertions(+), 12 deletions(-)
diff --git a/hw/intc/xics.c b/hw/intc/xics.c
index c80fa80..4d08c58 100644
--- a/hw/intc/xics.c
+++ b/hw/intc/xics.c
@@ -29,6 +29,7 @@
#include trace.h
#include hw/ppc/spapr.h
#include hw/ppc/xics.h
+#include qemu/error-report.h
/*
* ICP: Presentation layer
@@ -211,7 +212,7 @@ static void icp_class_init(ObjectClass *klass, void *data)
dc-vmsd = vmstate_icp_server;
}
-static TypeInfo icp_info = {
+static const TypeInfo icp_info = {
.name = TYPE_ICP,
.parent = TYPE_DEVICE,
.instance_size = sizeof(ICPState),
@@ -442,15 +443,17 @@ static const VMStateDescription vmstate_ics = {
},
};
-static int ics_realize(DeviceState *dev)
+static void ics_realize(DeviceState *dev, Error **errp)
{
ICSState *ics = ICS(dev);
+if (!ics-nr_irqs) {
+error_setg(errp, Number of interrupts needs to be greater 0);
+return;
+}
ics-irqs = g_malloc0(ics-nr_irqs * sizeof(ICSIRQState));
ics-islsi = g_malloc0(ics-nr_irqs * sizeof(bool));
ics-qirqs = qemu_allocate_irqs(ics_set_irq, ics, ics-nr_irqs);
-
-return 0;
}
static void ics_class_init(ObjectClass *klass, void *data)
@@ -458,13 +461,14 @@ static void ics_class_init(ObjectClass *klass, void *data)
DeviceClass *dc = DEVICE_CLASS(klass);
ICSStateClass *isc = ICS_CLASS(klass);
-dc-init = ics_realize;
+dc-realize = ics_realize;
dc-vmsd = vmstate_ics;
dc-reset = ics_reset;
isc-post_load = ics_post_load;
+isc-post_load = ics_post_load;
}
-static TypeInfo ics_info = {
+static const TypeInfo ics_info = {
.name = TYPE_ICS,
.parent = TYPE_DEVICE,
.instance_size = sizeof(ICSState),
@@ -680,8 +684,8 @@ static void xics_cpu_setup(XICSState *icp, PowerPCCPU *cpu)
break;
default:
-fprintf(stderr, XICS interrupt controller does not support this CPU
-bus model\n);
+error_report(XICS interrupt controller does not support this CPU
+bus model);
abort();
}
}
@@ -690,8 +694,14 @@ static void xics_realize(DeviceState *dev, Error **errp)
{
XICSState *icp = XICS(dev);
ICSState *ics = icp-ics;
+Error *error = NULL;
int i;
+if (!icp-nr_servers) {
+error_setg(errp, Number of servers needs to be greater 0);
+return;
+}
+
/* Registration of global state belongs into realize */
spapr_rtas_register(ibm,set-xive, rtas_set_xive);
spapr_rtas_register(ibm,get-xive, rtas_get_xive);
@@ -706,7 +716,11 @@ static void xics_realize(DeviceState *dev, Error **errp)
ics-nr_irqs = icp-nr_irqs;
ics-offset = XICS_IRQ_BASE;
ics-icp = icp;
-qdev_init_nofail(DEVICE(ics));
+object_property_set_bool(OBJECT(icp-ics), true, realized, error);
+if (error) {
+error_propagate(errp, error);
+return;
+}
icp-ss = g_malloc0(icp-nr_servers*sizeof(ICPState));
for (i = 0; i icp-nr_servers; i++) {
@@ -714,7 +728,11 @@ static void xics_realize(DeviceState *dev, Error **errp)
object_initialize(icp-ss[i], TYPE_ICP);
snprintf(buffer, sizeof(buffer), icp[%d], i);
object_property_add_child(OBJECT(icp), buffer, OBJECT(icp-ss[i]),
NULL);
-qdev_init_nofail(DEVICE(icp-ss[i]));
+object_property_set_bool(OBJECT(icp-ss[i]), true, realized,
error);
+if (error) {
+error_propagate(errp, error);
+return;
+}
}
}
@@ -735,12 +753,12 @@ static Property xics_properties[] = {
static void xics_class_init(ObjectClass *oc, void *data)
{
DeviceClass *dc = DEVICE_CLASS(oc);
-XICSStateClass *k = XICS_CLASS(oc);
+XICSStateClass *xsc = XICS_CLASS(oc);
dc-realize = xics_realize;
dc-props = xics_properties;
dc-reset = xics_reset;
-k-cpu_setup = xics_cpu_setup;
+xsc-cpu_setup = xics_cpu_setup;
}
static const TypeInfo xics_info = {
--
1.8.3.2
[Qemu-devel] [PATCH v3 3/8] xics: move registration of global state to realize()
Registration of global state belongs into realize so move it there.
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
Reviewed-by: Andreas Färber afaer...@suse.de
---
hw/intc/xics.c | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/hw/intc/xics.c b/hw/intc/xics.c
index e3a957d..c80fa80 100644
--- a/hw/intc/xics.c
+++ b/hw/intc/xics.c
@@ -692,6 +692,17 @@ static void xics_realize(DeviceState *dev, Error **errp)
ICSState *ics = icp-ics;
int i;
+/* Registration of global state belongs into realize */
+spapr_rtas_register(ibm,set-xive, rtas_set_xive);
+spapr_rtas_register(ibm,get-xive, rtas_get_xive);
+spapr_rtas_register(ibm,int-off, rtas_int_off);
+spapr_rtas_register(ibm,int-on, rtas_int_on);
+
+spapr_register_hypercall(H_CPPR, h_cppr);
+spapr_register_hypercall(H_IPI, h_ipi);
+spapr_register_hypercall(H_XIRR, h_xirr);
+spapr_register_hypercall(H_EOI, h_eoi);
+
ics-nr_irqs = icp-nr_irqs;
ics-offset = XICS_IRQ_BASE;
ics-icp = icp;
@@ -730,16 +741,6 @@ static void xics_class_init(ObjectClass *oc, void *data)
dc-props = xics_properties;
dc-reset = xics_reset;
k-cpu_setup = xics_cpu_setup;
-
-spapr_rtas_register(ibm,set-xive, rtas_set_xive);
-spapr_rtas_register(ibm,get-xive, rtas_get_xive);
-spapr_rtas_register(ibm,int-off, rtas_int_off);
-spapr_rtas_register(ibm,int-on, rtas_int_on);
-
-spapr_register_hypercall(H_CPPR, h_cppr);
-spapr_register_hypercall(H_IPI, h_ipi);
-spapr_register_hypercall(H_XIRR, h_xirr);
-spapr_register_hypercall(H_EOI, h_eoi);
}
static const TypeInfo xics_info = {
--
1.8.3.2
[Qemu-devel] [PATCH v3 2/8] xics: add pre_save/post_load/cpu_setup dispatchers
The upcoming support of in-kernel XICS will redefine migration callbacks
for both ICS and ICP so classes and callback pointers are added.
This adds a cpu_setup callback to the XICS device class (as XICS-KVM
will do it different) and xics_dispatch_cpu_setup(). This also moves
the place where xics_dispatch_cpu_setup() is called a bit further to
have VCPU initialized (required for XICS-KVM).
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
Changes:
v3:
* fixed local variables names
---
hw/intc/xics.c| 61 +++
hw/ppc/spapr.c| 4 ++--
include/hw/ppc/xics.h | 46 +-
3 files changed, 104 insertions(+), 7 deletions(-)
diff --git a/hw/intc/xics.c b/hw/intc/xics.c
index 6b3c071..e3a957d 100644
--- a/hw/intc/xics.c
+++ b/hw/intc/xics.c
@@ -153,11 +153,35 @@ static void icp_irq(XICSState *icp, int server, int nr,
uint8_t priority)
}
}
+static void icp_dispatch_pre_save(void *opaque)
+{
+ICPState *ss = opaque;
+ICPStateClass *info = ICP_GET_CLASS(ss);
+
+if (info-pre_save) {
+info-pre_save(ss);
+}
+}
+
+static int icp_dispatch_post_load(void *opaque, int version_id)
+{
+ICPState *ss = opaque;
+ICPStateClass *info = ICP_GET_CLASS(ss);
+
+if (info-post_load) {
+return info-post_load(ss, version_id);
+}
+
+return 0;
+}
+
static const VMStateDescription vmstate_icp_server = {
.name = icp/server,
.version_id = 1,
.minimum_version_id = 1,
.minimum_version_id_old = 1,
+.pre_save = icp_dispatch_pre_save,
+.post_load = icp_dispatch_post_load,
.fields = (VMStateField []) {
/* Sanity check */
VMSTATE_UINT32(xirr, ICPState),
@@ -192,6 +216,7 @@ static TypeInfo icp_info = {
.parent = TYPE_DEVICE,
.instance_size = sizeof(ICPState),
.class_init = icp_class_init,
+.class_size = sizeof(ICPStateClass),
};
/*
@@ -353,10 +378,9 @@ static void ics_reset(DeviceState *dev)
}
}
-static int ics_post_load(void *opaque, int version_id)
+static int ics_post_load(ICSState *ics, int version_id)
{
int i;
-ICSState *ics = opaque;
for (i = 0; i ics-icp-nr_servers; i++) {
icp_resend(ics-icp, i);
@@ -365,6 +389,28 @@ static int ics_post_load(void *opaque, int version_id)
return 0;
}
+static void ics_dispatch_pre_save(void *opaque)
+{
+ICSState *ics = opaque;
+ICSStateClass *info = ICS_GET_CLASS(ics);
+
+if (info-pre_save) {
+info-pre_save(ics);
+}
+}
+
+static int ics_dispatch_post_load(void *opaque, int version_id)
+{
+ICSState *ics = opaque;
+ICSStateClass *info = ICS_GET_CLASS(ics);
+
+if (info-post_load) {
+return info-post_load(ics, version_id);
+}
+
+return 0;
+}
+
static const VMStateDescription vmstate_ics_irq = {
.name = ics/irq,
.version_id = 1,
@@ -384,7 +430,8 @@ static const VMStateDescription vmstate_ics = {
.version_id = 1,
.minimum_version_id = 1,
.minimum_version_id_old = 1,
-.post_load = ics_post_load,
+.pre_save = ics_dispatch_pre_save,
+.post_load = ics_dispatch_post_load,
.fields = (VMStateField []) {
/* Sanity check */
VMSTATE_UINT32_EQUAL(nr_irqs, ICSState),
@@ -409,10 +456,12 @@ static int ics_realize(DeviceState *dev)
static void ics_class_init(ObjectClass *klass, void *data)
{
DeviceClass *dc = DEVICE_CLASS(klass);
+ICSStateClass *isc = ICS_CLASS(klass);
dc-init = ics_realize;
dc-vmsd = vmstate_ics;
dc-reset = ics_reset;
+isc-post_load = ics_post_load;
}
static TypeInfo ics_info = {
@@ -420,6 +469,7 @@ static TypeInfo ics_info = {
.parent = TYPE_DEVICE,
.instance_size = sizeof(ICSState),
.class_init = ics_class_init,
+.class_size = sizeof(ICSStateClass),
};
/*
@@ -612,7 +662,7 @@ static void xics_reset(DeviceState *d)
device_reset(DEVICE(icp-ics));
}
-void xics_cpu_setup(XICSState *icp, PowerPCCPU *cpu)
+static void xics_cpu_setup(XICSState *icp, PowerPCCPU *cpu)
{
CPUState *cs = CPU(cpu);
CPUPPCState *env = cpu-env;
@@ -674,10 +724,12 @@ static Property xics_properties[] = {
static void xics_class_init(ObjectClass *oc, void *data)
{
DeviceClass *dc = DEVICE_CLASS(oc);
+XICSStateClass *k = XICS_CLASS(oc);
dc-realize = xics_realize;
dc-props = xics_properties;
dc-reset = xics_reset;
+k-cpu_setup = xics_cpu_setup;
spapr_rtas_register(ibm,set-xive, rtas_set_xive);
spapr_rtas_register(ibm,get-xive, rtas_get_xive);
@@ -694,6 +746,7 @@ static const TypeInfo xics_info = {
.name = TYPE_XICS,
.parent= TYPE_SYS_BUS_DEVICE,
.instance_size = sizeof(XICSState),
+.class_size = sizeof(XICSStateClass),
.class_init= xics_class_init,
.instance_init = xics_initfn,
};
diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index 16bfab9..432f0d2 100644
--- a/hw/ppc/spapr.c
+++
[Qemu-devel] [PATCH v3 5/8] xics: split to xics and xics-common
The upcoming XICS-KVM support will use bits of emulated XICS code.
So this introduces new level of hierarchy - xics-common class. Both
emulated XICS and XICS-KVM will inherit from it and override class
callbacks when required.
The new xics-common class implements:
1. replaces static nr_irqs and nr_servers properties with
the dynamic ones and adds callbacks to be executed when properties
are set.
2. xics_cpu_setup() callback renamed to xics_common_cpu_setup() as
it is a common part for both XICS'es
3. xics_reset() renamed to xics_common_reset() for the same reason.
The emulated XICS changes:
1. the part of xics_realize() which creates ICPs is moved to
the nr_servers property callback as realize() is too late to
create/initialize devices and instance_init() is too early to create
devices as the number of child devices comes via the nr_servers
property.
2. added ics_initfn() which does a little part of what xics_realize() did.
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
Changes:
v3:
* added getters for dynamic properties
* fixed some indentations, added some comments
* moved ICS allocation from the nr_irqs property setter to XICS initfn
(where it was initially after Anthony's rework)
---
hw/intc/xics.c| 213 ++
include/hw/ppc/xics.h | 11 ++-
2 files changed, 175 insertions(+), 49 deletions(-)
diff --git a/hw/intc/xics.c b/hw/intc/xics.c
index 4d08c58..f439e8d 100644
--- a/hw/intc/xics.c
+++ b/hw/intc/xics.c
@@ -30,6 +30,143 @@
#include hw/ppc/spapr.h
#include hw/ppc/xics.h
#include qemu/error-report.h
+#include qapi/visitor.h
+
+/*
+ * XICS Common class - parent for emulated XICS and KVM-XICS
+ */
+
+static void xics_common_cpu_setup(XICSState *icp, PowerPCCPU *cpu)
+{
+CPUState *cs = CPU(cpu);
+CPUPPCState *env = cpu-env;
+ICPState *ss = icp-ss[cs-cpu_index];
+
+assert(cs-cpu_index icp-nr_servers);
+
+switch (PPC_INPUT(env)) {
+case PPC_FLAGS_INPUT_POWER7:
+ss-output = env-irq_inputs[POWER7_INPUT_INT];
+break;
+
+case PPC_FLAGS_INPUT_970:
+ss-output = env-irq_inputs[PPC970_INPUT_INT];
+break;
+
+default:
+error_report(XICS interrupt controller does not support this CPU
+ bus model);
+/* Called from machine_init only so no point in Error**, just abort */
+abort();
+}
+}
+
+static void xics_prop_get_nr_irqs(Object *obj, Visitor *v,
+ void *opaque, const char *name, Error **errp)
+{
+XICSState *icp = XICS_COMMON(obj);
+int64_t value = icp-nr_irqs;
+
+visit_type_int(v, value, name, errp);
+}
+
+static void xics_prop_set_nr_irqs(Object *obj, Visitor *v,
+ void *opaque, const char *name, Error **errp)
+{
+XICSState *icp = XICS_COMMON(obj);
+XICSStateClass *info = XICS_COMMON_GET_CLASS(icp);
+Error *error = NULL;
+int64_t value;
+
+visit_type_int(v, value, name, error);
+if (error) {
+error_propagate(errp, error);
+return;
+}
+if (icp-nr_irqs) {
+error_setg(errp, Number of interrupts is already set to %u,
+ icp-nr_irqs);
+return;
+}
+
+assert(info-set_nr_irqs);
+assert(icp-ics);
+info-set_nr_irqs(icp, value, errp);
+}
+
+static void xics_prop_get_nr_servers(Object *obj, Visitor *v,
+ void *opaque, const char *name,
+ Error **errp)
+{
+XICSState *icp = XICS_COMMON(obj);
+int64_t value = icp-nr_servers;
+
+visit_type_int(v, value, name, errp);
+}
+
+static void xics_prop_set_nr_servers(Object *obj, Visitor *v,
+ void *opaque, const char *name,
+ Error **errp)
+{
+XICSState *icp = XICS_COMMON(obj);
+XICSStateClass *info = XICS_COMMON_GET_CLASS(icp);
+Error *error = NULL;
+int64_t value;
+
+visit_type_int(v, value, name, error);
+if (error) {
+error_propagate(errp, error);
+return;
+}
+if (icp-nr_servers) {
+error_setg(errp, Number of servers is already set to %u,
+ icp-nr_servers);
+return;
+}
+
+assert(info-set_nr_servers);
+info-set_nr_servers(icp, value, errp);
+}
+
+static void xics_common_initfn(Object *obj)
+{
+object_property_add(obj, nr_irqs, int,
+xics_prop_get_nr_irqs, xics_prop_set_nr_irqs,
+NULL, NULL, NULL);
+object_property_add(obj, nr_servers, int,
+xics_prop_get_nr_servers, xics_prop_set_nr_servers,
+NULL, NULL, NULL);
+}
+
+static void xics_common_reset(DeviceState *d)
+{
+XICSState *icp = XICS_COMMON(d);
+int i;
+
+for (i = 0; i icp-nr_servers; i++) {
+device_reset(DEVICE(icp-ss[i]));
+}
+
+device_reset(DEVICE(icp-ics));
+}
+
+static void
