Re: [Qemu-devel] [PATCH v4 0/9] VMXNET3 paravirtual NIC device implementation
On 20.03.2012 09:00, Dmitry Fleytman wrote: Hello, Gerhard I've tested telnet connections on Knoppix running on QEMU-KVM with patch V5. Everything works fine on my setup. What is your network setup? How do you connect tap1 interface to the outer world? Hello Dmitry , Did you also test with tap? As patch V2 (i think it was that version) worked well but was not stable I'm guessing that there might be some other problems: 1.) tap interface? 2.) TCP offload checksumming (as far as I saw I think there were some changes). Same command line with pcnet is also ok (changed only interface card). My network setup for testing several adapters is stable since about one year. /root/download/qemu/git/qemu-kvm/x86_64-softmmu/qemu-system-x86_64 -drive if=ide,index=3,media=cdrom,file=ISO/KNOPPIX_V6.7.1CD-2011-09-14-DE.iso -boot order=cad,menu=on -m 2048 -k de -vga vmware -vnc :0 -bios /root/download/seabios/git/seabios/out/bios.bin -chardev stdio,id=seabios -device isa-debugcon,iobase=0x402,chardev=seabios -device pcnet,mac=1a:46:0b:ca:bc:7e,vlan=1,romfile= -net tap,ifname=tap1,script=no,downscript=no,vlan=1 I use a bridge on eth0 and connect the tap interfaces: brctl show bridge name bridge id STP enabled interfaces br0 8000.001fc689da45 no eth0 tap0 tap1 Also, since you have ping failure to init MSI-X is not related to the problem - device just falls back to MSI interrupts, but anyway, why does it fail? Could it be some QEMU/KVM versions incompartibility? Don't know why it fails. I'm using latest git QEMU/KVM version. Will try it on qemu only today in the evening. Thnx. Ciao, Gerhard Best regards, Dmitry Fleytman. On Mon, Mar 19, 2012 at 9:24 PM, Gerhard Wiesinger wrote: Hello Dmitry, Tried also v5 patch without success: /root/download/qemu/git/qemu-kvm/x86_64-softmmu/qemu-system-x86_64 -drive if=ide,index=3,media=cdrom,file=ISO/KNOPPIX_V6.7.1CD-2011-09-14-DE.iso -boot order=cad,menu=on -m 2048 -k de -vga vmware -vnc :0 -bios /root/download/seabios/git/seabios/out/bios.bin -chardev stdio,id=seabios -device isa-debugcon,iobase=0x402,chardev=seabios -device vmxnet3,mac=1a:46:0b:ca:bc:7e,vlan=1,romfile= -net tap,ifname=tap1,script=no,downscript=no,vlan=1 ping ok, but outside tcp communication fails: # timeout Knoppix => outside telnet 192.168.0.2 22 # timeout outside => Knoppix failes telnet 192.168.0.30 22 RTL8139 with same command line is ok. Maybe that helps directly at startup: kvm_msix_vector_add: kvm_add_msix failed: No space left on device [vmxnet3][WR][vmxnet3_use_msix_vectors]: Failed to use MSI-X vector 9, error -28 [vmxnet3][WR][vmxnet3_init_msix]: Failed to use MSI-X vectors, error 0 [vmxnet3][WR][vmxnet3_pci_init]: Failed to initialize MSI-X, configuration is inconsistent. [vmxnet3][WR][vmxnet3_peer_has_vnet_hdr]: Peer has no virtio extension. Task offloads will be emulated. I'm using git qemu-kvm and not git qemu. Thnx. Ciao, Gerhard On 18.03.2012 16:30, Dmitry Fleytman wrote: Hello, Gerhard I've rechecked SSH connection both incoming and outgoing with patch v5. Everything works fine. If you still see problems, please, provide your exact configuration. Thanking you for your support, Dmitry Fleytman. On Sun, Mar 18, 2012 at 10:29 AM, Gerhard Wiesinger wrote: Hello, I'm still having problems with v4 patch: ping works well, even with large packet sizes but ssh doesn't work at all. Tested with Knoppix 6.7 and Fedora 16. Thnx. Ciao, Gerhard On 15.03.2012 22:08, Dmitry Fleytman wrote: This set of patches implements VMWare VMXNET3 paravirtual NIC device. The device supports of all the device features including offload capabilties, VLANs and etc. The device is tested on different OSes: Fedora 15 Ubuntu 10.4 Centos 6.2 Windows 2008R2 Windows 2008 64bit Windows 2008 32bit Windows 2003 64bit Windows 2003 32bit Changes in V4: Fixed a few problems uncovered by NETIO test suit Assertion on failure to initialize MSI/MSI-X replaced with warning message and fallback to Legacy/MSI respectively Reported-by: Gerhard Wiesinger Various coding style adjustments and patch split-up as suggested by Anthony Liguori Reported-by: Anthony Liguori Live migration support added Changes in V3: Fixed crash when net device that is used as network fronted has no virtio HDR support. Task offloads emulation for cases when net device that is used as network fronted has no virtio HDR support. Reported-by: Gerhard Wiesinger Changes in V2: License text changed accoring to community suggestions Standard license header from GPLv2+ - licensed QEMU files used Dmitry Fleytman (9): Adding missing flag VIRTIO_NET_HDR_F_DATA_VALID from Linux kernel source tre Reformatting comments according to checkpatch.pl requi
Re: [Qemu-devel] [PATCH v4 2/7] RTC: Update the RTC clock only when reading it
> -Original Message- > From: Stefano Stabellini [mailto:stefano.stabell...@eu.citrix.com] > Sent: Tuesday, March 20, 2012 10:16 PM > To: Zhang, Yang Z > Cc: qemu-devel@nongnu.org; Paolo Bonzini; aligu...@us.ibm.com; > k...@vger.kernel.org > Subject: Re: [Qemu-devel] [PATCH v4 2/7] RTC: Update the RTC clock only when > reading it > > On Mon, 19 Mar 2012, Zhang, Yang Z wrote: > > There has no need to use two periodic timer to update RTC time. In this > > patch, > we only update it when guest reading it. > > So the basic idea here is that we don't need to two periodic timers > because we are going to calculate the RTC guest time from QEMU's > host_clock. > > I only have a couple of observations: > > - shouldn't we use QEMU rtc_clock, rather than host_clock? Right. It should be rtc_clock not host_clock > - it would be better to use shifts rather than divisions whenever > possible, they are much cheaper; Agree. > - rtc_calibrate_time seems to be the new functions that updates the > guest rtc time based on QEMU host_clock. Are you sure we are calling > it all the times we need to call it? Could we just call it at the > beginning of cmos_ioport_write and cmos_ioport_read? No. If the RTC_B_SET is set or divider reset is held, we should not call the rtc_calibrate_time. best regards yang
Re: [Qemu-devel] [PATCH v4 4/7] RTC: Set internal millisecond register to 500ms when reset divider
> -Original Message-
> From: Stefano Stabellini [mailto:stefano.stabell...@eu.citrix.com]
> Sent: Wednesday, March 21, 2012 1:39 AM
> To: Zhang, Yang Z
> Cc: qemu-devel@nongnu.org; Paolo Bonzini; aligu...@us.ibm.com;
> k...@vger.kernel.org
> Subject: Re: [Qemu-devel] [PATCH v4 4/7] RTC: Set internal millisecond
> register to
> 500ms when reset divider
>
> On Mon, 19 Mar 2012, Zhang, Yang Z wrote:
> > The first update cycle begins one - half seconds later when divider reset is
> removing.
> >
> > Signed-off-by: Yang Zhang
> > ---
> > hw/mc146818rtc.c | 38 +-
> > 1 files changed, 33 insertions(+), 5 deletions(-)
> >
> > diff --git a/hw/mc146818rtc.c b/hw/mc146818rtc.c
> > index 6ebb8f6..5e7fbb5 100644
> > --- a/hw/mc146818rtc.c
> > +++ b/hw/mc146818rtc.c
> > @@ -110,6 +110,8 @@ static void rtc_set_time(RTCState *s);
> > static void rtc_calibrate_time(RTCState *s);
> > static void rtc_set_cmos(RTCState *s);
> >
> > +static int32_t divider_reset;
>
> this should be part of RTCState
>
>
> > static uint64_t get_guest_rtc_us(RTCState *s)
> > {
> > int64_t host_usec, offset_usec, guest_usec;
> > @@ -220,16 +222,24 @@ static void rtc_periodic_timer(void *opaque)
> > }
> > }
> >
> > -static void rtc_set_offset(RTCState *s)
> > +static void rtc_set_offset(RTCState *s, int32_t start_usec)
>
> I noticed that you are always passing a positive number or 0 as
> start_usec: it might be worth turning start_usec into a uint32_t or
> uint64_t to avoid integer signedness errors.
Agree.
> Also it is not clear to me what this start_usec is supposed to be: if it
> is a delay to be added to the guest time, then it is best to rename it
> to "delay_usec" and add a comment on top to explain what it is for.
Actually, the start_usec only used when divider is changed from reset to an
valid time base. When the changing happened, the first update cycle is 500ms
later, so the start_usec equals to 500ms. When pass 0 as start_usec, it means
the rtc internal millisecond is not changed, it is synchronized with host's
time.
>
> > struct tm *tm = &s->current_tm;
> > -int64_t host_usec, guest_sec, guest_usec;
> > +int64_t host_usec, guest_sec, guest_usec, offset_usec, old_guest_usec;
> >
> > host_usec = qemu_get_clock_ns(host_clock) / NS_PER_USEC;
> > +offset_usec = s->offset_sec * USEC_PER_SEC + s->offset_usec;
> > +old_guest_usec = (host_usec + offset_usec) % USEC_PER_SEC;
> >
> > guest_sec = mktimegm(tm);
> > -guest_usec = guest_sec * USEC_PER_SEC;
> >
> > +/* start_usec equal 0 means rtc internal millisecond is
> > + * same with before */
> > +if (start_usec == 0) {
> > +guest_usec = guest_sec * USEC_PER_SEC + old_guest_usec;
> > +} else {
> > +guest_usec = guest_sec * USEC_PER_SEC + start_usec;
> > +}
>
> This looks like a mistake to me: before guest_usec was derived
> exclusively from mktimegm (take or leave USEC_PER_SEC), while now
> guest_usec is the sum of the value returned by mktimegm and
> old_guest_usec, even when start_usec is 0.
> Are you sure that this is correct?
The logic is right. Before this patch, we assume the rtc internal millisecond
register is same with host time, so we don't need to consider it and using
mktimeis enough. Now, the rtc internal millisecond can be changed, so I use the
old_guest_usec to record the current internal millisecond. When start_usec is
0, it means we don't need to change the internal millisecond register and the
offset_sec is same as before.
best regards
yang
Re: [Qemu-devel] [PATCH v4 5/7] RTC:Add RTC update-ended interrupt support
Il 20/03/2012 19:35, Stefano Stabellini ha scritto: > This is the function that is used to figure out whether we need the > timers or not, the condition seems to be: > > (Not (REG_C_UF | REG_C_AF)) And (Not (REG_B_SET)) > > Shouldn't actually check for UIE being enabled? No, you need to set UF in case the code observes it without actually enabling interrupt delivery on the ISA bus. Paolo
Re: [Qemu-devel] [PATCH 1/4] add MIPS DSP helpers define
Am 12.03.2012 09:32, schrieb Jia Liu: This patch is the helper define of MIPS ASE DSP. Signed-off-by: Jia Liu --- target-mips/helper.h | 152 ++ 1 files changed, 152 insertions(+), 0 deletions(-) diff --git a/target-mips/helper.h b/target-mips/helper.h index 442f684..1abf582 100644 --- a/target-mips/helper.h +++ b/target-mips/helper.h @@ -297,4 +297,156 @@ DEF_HELPER_0(rdhwr_ccres, tl) DEF_HELPER_1(pmon, void, int) DEF_HELPER_0(wait, void) +/* MIPS32 DSP */ +DEF_HELPER_1(absqsph, i32, i32) +DEF_HELPER_1(absqsw, i32, i32) +DEF_HELPER_2(addqph, i32, i32, i32) +DEF_HELPER_2(addqsph, i32, i32, i32) [snip] Hi, I know that a lot of people love such tabulated code, but I personally would prefer to see those DEF_HELPER lines using the style which is used in the existing code (one space after comma). Regards, Stefan Weil
Re: [Qemu-devel] [PATCH 2/4] add MIPS DSP helpers implement
Am 12.03.2012 09:32, schrieb Jia Liu:
This patch is the helper implementation of MIPS ASE DSP.
Signed-off-by: Jia Liu
---
target-mips/op_helper.c | 3936 +++
1 files changed, 3936 insertions(+), 0 deletions(-)
diff --git a/target-mips/op_helper.c b/target-mips/op_helper.c
index 87e9799..e6ff3c9 100644
--- a/target-mips/op_helper.c
+++ b/target-mips/op_helper.c
@@ -3409,3 +3409,3939 @@ FOP_COND_PS(le, float32_le(fst0,
fst1,&env->active_fpu.fp_status),
float32_le(fsth0, fsth1,&env->active_fpu.fp_status))
FOP_COND_PS(ngt, float32_unordered(fst1, fst0,&env->active_fpu.fp_status)||
float32_le(fst0, fst1,&env->active_fpu.fp_status),
float32_unordered(fsth1, fsth0,&env->active_fpu.fp_status) ||
float32_le(fsth0, fsth1,&env->active_fpu.fp_status))
+
+/* MIPS DSP functions begin */
+static inline void set_DSPControl_overflow_flag (uint32_t flag, int position)
Please check your patches using scripts/checkpatch.pl.
There should be no space between function name and argument list
for new functions (some old functions still have that space,
but that's accepted).
+{
+env->active_tc.DSPControl |= (target_ulong)flag<< position;
+}
+
Re: [Qemu-devel] [PATCH 3/4] add MIPS DSP translation
Please see my inline comments.
Regards,
Stefan Weil
Am 12.03.2012 09:32, schrieb Jia Liu:
This patch is the translation of MIPS ASE DSP.
Signed-off-by: Jia Liu
---
target-mips/translate.c | 1114 +--
1 files changed, 1088 insertions(+), 26 deletions(-)
diff --git a/target-mips/translate.c b/target-mips/translate.c
index 8361d88..1fa5b28 100644
--- a/target-mips/translate.c
+++ b/target-mips/translate.c
@@ -249,6 +249,11 @@ enum {
OPC_SYNCI= (0x1F<< 16) | OPC_REGIMM,
};
+/* REGIMM mipsdsp opcodes */
+enum {
+OPC_BPOSGE32 = (0x1C<< 16) | OPC_REGIMM,
+};
+
/* Special2 opcodes */
#define MASK_SPECIAL2(op) MASK_OP_MAJOR(op) | (op& 0x3F)
@@ -312,6 +317,21 @@ enum {
OPC_MODU_G_2E = 0x23 | OPC_SPECIAL3,
OPC_DMOD_G_2E = 0x26 | OPC_SPECIAL3,
OPC_DMODU_G_2E = 0x27 | OPC_SPECIAL3,
+
+/* MIPS DSP */
+OPC_ABSQ_S_PH_DSP = 0x12 | OPC_SPECIAL3,
+OPC_ADDU_QB_DSP= 0x10 | OPC_SPECIAL3,
+/* OPC_ADDUH_QB_DSP is same as OPC_MULT_G_2E. */
+/* OPC_ADDUH_QB_DSP = 0x18 | OPC_SPECIAL3, */
+OPC_APPEND_DSP = 0x31 | OPC_SPECIAL3,
+OPC_CMPU_EQ_QB_DSP = 0x11 | OPC_SPECIAL3,
+OPC_DPA_W_PH_DSP = 0x30 | OPC_SPECIAL3,
+OPC_EXTR_W_DSP = 0x38 | OPC_SPECIAL3,
+OPC_INSV_DSP = 0x0C | OPC_SPECIAL3,
+OPC_LX_DSP = 0x0A | OPC_SPECIAL3,
+/* OPC_MUL_PH_DSP is same as OPC_ADDUH_QB_DSP. */
+/* OPC_MUL_PH_DSP = 0x18 | OPC_SPECIAL3, */
+OPC_SHLL_QB_DSP= 0x13 | OPC_SPECIAL3,
};
/* BSHFL opcodes */
@@ -331,6 +351,231 @@ enum {
OPC_DSHD = (0x05<< 6) | OPC_DBSHFL,
};
+#define MASK_ABSQ_S_PH(op) MASK_SPECIAL3(op) | (op& (0x1F<< 6))
+/* MIPS DSP */
+enum {
+OPC_ABSQ_S_PH = (0x09<< 6) | OPC_ABSQ_S_PH_DSP,
+OPC_ABSQ_S_W= (0x11<< 6) | OPC_ABSQ_S_PH_DSP,
+OPC_BITREV = (0x1B<< 6) | OPC_ABSQ_S_PH_DSP,
+OPC_PRECEQ_W_PHL= (0x0C<< 6) | OPC_ABSQ_S_PH_DSP,
+OPC_PRECEQ_W_PHR= (0x0D<< 6) | OPC_ABSQ_S_PH_DSP,
+OPC_PRECEQU_PH_QBL = (0x04<< 6) | OPC_ABSQ_S_PH_DSP,
+OPC_PRECEQU_PH_QBLA = (0x06<< 6) | OPC_ABSQ_S_PH_DSP,
+OPC_PRECEQU_PH_QBR = (0x05<< 6) | OPC_ABSQ_S_PH_DSP,
+OPC_PRECEQU_PH_QBRA = (0x07<< 6) | OPC_ABSQ_S_PH_DSP,
+OPC_PRECEU_PH_QBL = (0x1C<< 6) | OPC_ABSQ_S_PH_DSP,
+OPC_PRECEU_PH_QBLA = (0x1E<< 6) | OPC_ABSQ_S_PH_DSP,
+OPC_PRECEU_PH_QBR = (0x1D<< 6) | OPC_ABSQ_S_PH_DSP,
+OPC_PRECEU_PH_QBRA = (0x1F<< 6) | OPC_ABSQ_S_PH_DSP,
+OPC_REPL_PH = (0x0A<< 6) | OPC_ABSQ_S_PH_DSP,
+OPC_REPL_QB = (0x02<< 6) | OPC_ABSQ_S_PH_DSP,
+OPC_REPLV_PH= (0x0B<< 6) | OPC_ABSQ_S_PH_DSP,
+OPC_REPLV_QB= (0x03<< 6) | OPC_ABSQ_S_PH_DSP,
+};
+
+/* MIPS DSPR2 */
+enum {
+OPC_ABSQ_S_QB = (0x01<< 6) | OPC_ABSQ_S_PH_DSP,
+};
+
+#define MASK_ADDU_QB(op) MASK_SPECIAL3(op) | (op& (0x1F<< 6))
+/* MIPS DSP */
+enum {
+OPC_ADDQ_PH= (0x0A<< 6) | OPC_ADDU_QB_DSP,
+OPC_ADDQ_S_PH = (0x0E<< 6) | OPC_ADDU_QB_DSP,
+OPC_ADDQ_S_W = (0x16<< 6) | OPC_ADDU_QB_DSP,
+OPC_ADDSC = (0x10<< 6) | OPC_ADDU_QB_DSP,
+OPC_ADDU_QB= (0x00<< 6) | OPC_ADDU_QB_DSP,
+OPC_ADDU_S_QB = (0x04<< 6) | OPC_ADDU_QB_DSP,
+OPC_ADDWC = (0x11<< 6) | OPC_ADDU_QB_DSP,
+OPC_MODSUB = (0x12<< 6) | OPC_ADDU_QB_DSP,
+OPC_MULEQ_S_W_PHL = (0x1C<< 6) | OPC_ADDU_QB_DSP,
+OPC_MULEQ_S_W_PHR = (0x1D<< 6) | OPC_ADDU_QB_DSP,
+OPC_MULEU_S_PH_QBL = (0x06<< 6) | OPC_ADDU_QB_DSP,
+OPC_MULEU_S_PH_QBR = (0x07<< 6) | OPC_ADDU_QB_DSP,
+OPC_MULQ_RS_PH = (0x1F<< 6) | OPC_ADDU_QB_DSP,
+OPC_RADDU_W_QB = (0x14<< 6) | OPC_ADDU_QB_DSP,
+OPC_SUBQ_PH= (0x0B<< 6) | OPC_ADDU_QB_DSP,
+OPC_SUBQ_S_PH = (0x0F<< 6) | OPC_ADDU_QB_DSP,
+OPC_SUBQ_S_W = (0x17<< 6) | OPC_ADDU_QB_DSP,
+OPC_SUBU_QB= (0x01<< 6) | OPC_ADDU_QB_DSP,
+OPC_SUBU_S_QB = (0x05<< 6) | OPC_ADDU_QB_DSP,
+};
+
+/* MIPS DSPR2 */
+enum {
+OPC_ADDU_PH = (0x08<< 6) | OPC_ADDU_QB_DSP,
+OPC_ADDU_S_PH = (0x0C<< 6) | OPC_ADDU_QB_DSP,
+OPC_MULQ_S_PH = (0x1E<< 6) | OPC_ADDU_QB_DSP,
+OPC_SUBU_PH = (0x09<< 6) | OPC_ADDU_QB_DSP,
+OPC_SUBU_S_PH = (0x0D<< 6) | OPC_ADDU_QB_DSP,
+};
+
+#define OPC_ADDUH_QB_DSP OPC_MULT_G_2E
+#define MASK_ADDUH_QB(op) MASK_SPECIAL3(op) | (op& (0x1F<< 6))
+/* MIPS DSPR2 */
+enum {
+OPC_ADDQH_PH = (0x08<< 6) | OPC_ADDUH_QB_DSP,
+OPC_ADDQH_R_PH = (0x0A<< 6) | OPC_ADDUH_QB_DSP,
+OPC_ADDQH_W= (0x10<< 6) | OPC_ADDUH_QB_DSP,
+OPC_ADDQH_R_W = (0x12<< 6) | OPC_ADDUH_QB_DSP,
+OPC_ADDUH_QB = (0x00<< 6) | OPC_ADDUH_QB_DSP,
+OPC_ADDUH_R_QB = (0x02<< 6) | OPC_ADDUH_QB_DSP,
+OPC_MUL_PH = (0x0C<< 6) | OPC_ADDUH_QB_DSP,
+OPC_MUL_S_PH = (0x0E<< 6) | OPC_ADDUH_QB_DSP,
+OPC_SUBQH_PH = (0x09<< 6) | OPC_ADDUH_QB_DSP,
+OPC_SUBQH_R_PH = (0x0B<< 6) | OPC_ADDUH_QB_DSP
Re: [Qemu-devel] [PATCH 4/4] add MIPS DSP testcase
Am 12.03.2012 09:32, schrieb Jia Liu: This patch is the testcases of MIPS ASE DSP. Signed-off-by: Jia Liu --- tests/tcg/mips/mips32-dsp/Makefile | 133 tests/tcg/mips/mips32-dsp/absq_s_ph.c | 28 + tests/tcg/mips/mips32-dsp/absq_s_w.c | 35 ++ tests/tcg/mips/mips32-dsp/addq_ph.c | 29 + tests/tcg/mips/mips32-dsp/addq_s_ph.c | 29 + tests/tcg/mips/mips32-dsp/addsc.c | 28 + tests/tcg/mips/mips32-dsp/addu_qb.c | 28 + tests/tcg/mips/mips32-dsp/addu_s_qb.c | 28 + tests/tcg/mips/mips32-dsp/addwc.c | 28 + tests/tcg/mips/mips32-dsp/bitrev.c | 18 +++ tests/tcg/mips/mips32-dsp/bposge32.c | 42 tests/tcg/mips/mips32-dsp/cmp_eq_ph.c | 33 ++ tests/tcg/mips/mips32-dsp/cmp_le_ph.c | 33 ++ tests/tcg/mips/mips32-dsp/cmp_lt_ph.c | 33 ++ tests/tcg/mips/mips32-dsp/cmpgu_eq_qb.c | 29 + tests/tcg/mips/mips32-dsp/cmpgu_le_qb.c | 29 + tests/tcg/mips/mips32-dsp/cmpgu_lt_qb.c | 29 + tests/tcg/mips/mips32-dsp/cmpu_eq_qb.c | 33 ++ tests/tcg/mips/mips32-dsp/cmpu_le_qb.c | 33 ++ tests/tcg/mips/mips32-dsp/cmpu_lt_qb.c | 33 ++ tests/tcg/mips/mips32-dsp/dpaq_s_w_ph.c | 29 + tests/tcg/mips/mips32-dsp/dpaq_sa_l_w.c | 29 + tests/tcg/mips/mips32-dsp/dpau_h_qbl.c | 25 + tests/tcg/mips/mips32-dsp/dpau_h_qbr.c | 25 + tests/tcg/mips/mips32-dsp/dpsq_s_w_ph.c | 25 + tests/tcg/mips/mips32-dsp/dpsq_sa_l_w.c | 29 + tests/tcg/mips/mips32-dsp/dpsu_h_qbl.c | 25 + tests/tcg/mips/mips32-dsp/dpsu_h_qbr.c | 25 + tests/tcg/mips/mips32-dsp/extp.c | 42 tests/tcg/mips/mips32-dsp/extpdp.c | 44 tests/tcg/mips/mips32-dsp/extpdpv.c | 45 tests/tcg/mips/mips32-dsp/extpv.c | 43 tests/tcg/mips/mips32-dsp/extr_r_w.c | 23 tests/tcg/mips/mips32-dsp/extr_rs_w.c | 23 tests/tcg/mips/mips32-dsp/extr_s_h.c | 23 tests/tcg/mips/mips32-dsp/extr_w.c | 23 tests/tcg/mips/mips32-dsp/extrv_r_w.c | 27 + tests/tcg/mips/mips32-dsp/extrv_rs_w.c | 27 + tests/tcg/mips/mips32-dsp/extrv_s_h.c | 27 + tests/tcg/mips/mips32-dsp/extrv_w.c | 27 + tests/tcg/mips/mips32-dsp/insv.c | 21 tests/tcg/mips/mips32-dsp/lbux.c | 21 tests/tcg/mips/mips32-dsp/lhx.c | 21 tests/tcg/mips/mips32-dsp/lwx.c | 21 tests/tcg/mips/mips32-dsp/madd.c | 29 + tests/tcg/mips/mips32-dsp/maddu.c | 29 + tests/tcg/mips/mips32-dsp/maq_s_w_phl.c | 29 + tests/tcg/mips/mips32-dsp/maq_s_w_phr.c | 29 + tests/tcg/mips/mips32-dsp/maq_sa_w_phl.c | 29 + tests/tcg/mips/mips32-dsp/maq_sa_w_phr.c | 29 + tests/tcg/mips/mips32-dsp/mfhi.c | 19 tests/tcg/mips/mips32-dsp/mflo.c | 19 tests/tcg/mips/mips32-dsp/modsub.c | 28 + tests/tcg/mips/mips32-dsp/msub.c | 28 + tests/tcg/mips/mips32-dsp/msubu.c | 28 + tests/tcg/mips/mips32-dsp/mthi.c | 19 tests/tcg/mips/mips32-dsp/mthlip.c | 32 ++ tests/tcg/mips/mips32-dsp/mtlo.c | 19 tests/tcg/mips/mips32-dsp/muleq_s_w_phr.c | 38 +++ tests/tcg/mips/mips32-dsp/muleu_s_ph_qbl.c | 23 tests/tcg/mips/mips32-dsp/muleu_s_ph_qbr.c | 23 tests/tcg/mips/mips32-dsp/mulq_rs_ph.c | 23 tests/tcg/mips/mips32-dsp/mult.c | 22 tests/tcg/mips/mips32-dsp/multu.c | 22 tests/tcg/mips/mips32-dsp/packrl_ph.c | 19 tests/tcg/mips/mips32-dsp/pick_ph.c | 21 tests/tcg/mips/mips32-dsp/pick_qb.c | 21 tests/tcg/mips/mips32-dsp/preceq_w_phl.c | 18 +++ tests/tcg/mips/mips32-dsp/preceq_w_phr.c | 18 +++ tests/tcg/mips/mips32-dsp/precequ_ph_qbl.c | 18 +++ tests/tcg/mips/mips32-dsp/precequ_ph_qbla.c | 18 +++ tests/tcg/mips/mips32-dsp/precequ_ph_qbr.c | 18 +++ tests/tcg/mips/mips32-dsp/precequ_ph_qbra.c | 18 +++ tests/tcg/mips/mips32-dsp/preceu_ph_qbl.c | 18 +++ tests/tcg/mips/mips32-dsp/preceu_ph_qbla.c | 18 +++ tests/tcg/mips/mips32-dsp/preceu_ph_qbr.c | 18 +++ tests/tcg/mips/mips32-dsp/preceu_ph_qbra.c | 18 +++ tests/tcg/mips/mips32-dsp/precrq_ph_w.c | 19 tests/tcg/mips/mips32-dsp/precrq_qb_ph.c | 19 tests/tcg/mips/mips32-dsp/precrq_rs_ph_w.c | 19 tests/tcg/mips/mips32-dsp/precrqu_s_qb_ph.c | 19 tests/tcg/mips/mips32-dsp/raddu_w_qb.c | 18 +++ tests/tcg/mips/mips32-dsp/rddsp.c | 52 + tests/tcg/mips/mips32-dsp/repl_ph.c | 21 tests/tcg/mips/mips32-dsp/repl_qb.c | 14 +++ tests/tcg/mips/mips32-dsp/replv_ph.c | 17 +++ tests/tcg/mips/mips32-dsp/replv_qb.c | 17 +++ tests/tcg/mips/mips32-dsp/shilo.c | 25 + tests/tcg/mips/mips32-dsp/shilov.c | 27 + tests/tcg/mips/mips32-dsp/shll_ph.c | 22 tests/tcg/mips/mips32-dsp/shll_qb.c | 21 tests/tcg/mips/mips32-dsp/shll_s_ph.c | 22 tests/tcg/mips/mips32-dsp/shll_s_w.c | 22 tests/tcg/mips/mips32-dsp/shllv_ph.c | 23 tests/tcg/mips/mips32-dsp/shllv_qb.c | 22 tests/tcg/mips/mips32-dsp/shllv_s_ph.c | 23 tests/tcg/mips/mips32-dsp/shllv_s_w.c | 23 tests/tcg/mips/mips32-dsp/shra_ph.c | 18 +++ tests/tcg/mips/mips32-dsp/shra_r_ph.c | 18 +++ tests/tcg/mips/mips32-dsp/shra_r_w.c | 18 +++ tests/tcg/mips/mips32-dsp/shrav_ph.c | 1
Re: [Qemu-devel] qemu prompt comes up instead of all the kernel stuff
Hi.. On Tue, Mar 20, 2012 at 18:17, Krishna Pavan wrote: > > Hi, > I have tried a kernel to be loaded. > I get QEMU prompt and not any kernel text. > Please tell me why it is happening so. Here's the screenshot. care to tell us the exact command line you used to execute Qemu? And what OS did you try to boot ? -- regards, Mulyadi Santosa Freelance Linux trainer and consultant blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com
Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked
On Wed, Mar 21, 2012 at 08:56:03AM +0800, Wen Congyang wrote: > At 03/20/2012 11:45 PM, Gleb Natapov Wrote: > > On Tue, Mar 20, 2012 at 05:59:16PM +0800, Wen Congyang wrote: > >> At 03/19/2012 03:33 PM, Wen Congyang Wrote: > >>> At 03/08/2012 03:57 PM, Wen Congyang Wrote: > We can know the guest is paniced when the guest runs on xen. > But we do not have such feature on kvm. > > Another purpose of this feature is: management app(for example: > libvirt) can do auto dump when the guest is crashed. If management > app does not do auto dump, the guest's user can do dump by hand if > he sees the guest is paniced. > > I touch the hypervisor instead of using virtio-serial, because > 1. it is simple > 2. the virtio-serial is an optional device, and the guest may > not have such device. > > Changes from v2 to v3: > 1. correct spelling > > Changes from v1 to v2: > 1. split up host and guest-side changes > 2. introduce new request flag to avoid changing return values. > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" > in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > > >>> > >>> > >>> Hi all: > >>> > >>> we neet this feature, but we don't decide how to implement it. > >>> We have two solution: > >>> 1. use vmcall > >>> 2. use virtio-serial. > >>> > >>> I will not change this patch set before we decide how to do it. > >>> Can we make a decision recent days? > >> > >> Anybody can decide which solution to use? > >> > > To make an informed decision we need to have at least raw idea how > > virtio-serial variant will look. > > Hmm, I think we can do this: > 1. reset the virtio-serial device or reset the port we use to notice >the host that guest is panicked. > 2. write some specific messages to the port > > So the port should have fixed name. If this port is opened by the userspace > before the guest is paniced, I am not sure whether we can use it(because a > port only can be opened once at the same time). Yes, IMO we should dedicate one virtio-serial port for panic notifications. Just like we dedicate one for a console. > We cannot call any function in the module, so we may need to write a simple > driver for virtio-serial(like diskdump's disk driver). > netconsole uses standard NIC drivers in polling mode to send OOPSes over the network and it mostly works. So I think using virtio-serial driver is not out of question, but with IRQ disabled of course. > I donot know how to implement it now. But I guess that it may be complicated. > Look at drivers/char/ipmi/ipmi_msghandler.c. It has code to send panic event over IMPI. The code is pretty complex. Of course if we a going to implement something more complex than simple hypercall for panic notification we better do something more interesting with it than just saying "panic happened", like sending stack traces on all cpus for instance. -- Gleb.
Re: [Qemu-devel] [PATCH 10/12] trace: [tracetool] Automatically establish available backends and formats
2012/3/20 Lluís Vilanova : > Stefan Hajnoczi writes: > >> 2012/3/20 Lluís Vilanova : >>> Stefan Hajnoczi writes: >>> 2012/3/13 Lluís Vilanova : > Adds decorators to establish which backend and/or format each routine is > meant > to process. > > With this, tables enumerating format and backend routines can be > eliminated and > part of the usage message can be computed in a more generic way. > > Signed-off-by: Lluís Vilanova > Signed-off-by: Harsh Prateek Bora > --- > Makefile.objs | 6 - > Makefile.target | 3 > scripts/tracetool.py | 320 > -- > 3 files changed, 211 insertions(+), 118 deletions(-) >>> I find the decorators are overkill and we miss the chance to use more straightforward approaches that Python supports. The decorators build structures behind the scenes instead of using classes in an open coded way. I think this makes it more difficult for people to modify the code - they will need to dig in to what exactly the decorators do - what they do is pretty similar to what you get from a class. >>> I've tried out an alternative approach which works very nicely for formats. For backends it's not a perfect fit because it creates instances when we don't really need them, but I think it's still an overall cleaner approach: >>> https://github.com/stefanha/qemu/commit/3500eb43f80f3c9200107aa0ca19a1b57300ef8a >>> What do you think? >>> >>> I don't like it: >>> >>> 1) Format and backend tables must be manually filled. >>> >>> 2) The base Backend class has empty methods for each possible format. >>> >>> 3) There is no control on format/backend compatibility. >>> >>> But I do like the idea of having a single per-backend class having methods >>> for >>> each possible format. >>> >>> The main reason for automatically establishing formats, backends and their >>> compatibility is that the instrumentation patches add some extra formats and >>> backends, which makes the process much more tedious if it's not automated. >>> >>> Whether you use decorators or classes is not that important. >>> >>> Auto-registration can be accomplished using metaclasses and special >>> per-format/backend "special" attributes the metaclasses will look for (e.g. >>> NAME >>> to set the commandline-visible name of a format/backend.). >>> >>> Format/backend compatibility can be established by introspecting into the >>> methods on each backend child class, matched against the NAMEs of the >>> registered >>> formats. >>> >>> But going this way does not sound to me like it will be much clearer than >>> decorators. >>> >>> Do you agree? (I'll wait on solving this before fixing the rest of your >>> concerns >>> in this series). Do you still prefer classes over decorators? > >> For formats the Format class plus a dict approach is much nicer than >> decorators. The code is short and easy to understand. > > Well, I prefer to automate this kind of things so that new features get > automatically registered and the changes are localized; but it really doesn't > matter that much :) Formats seem so simple to me that the cost of any infrastructure is higher than throwing a Format() instance in a dict. > Maybe this would work nice for everybody: > > tracetool.py # main program (just parse cmdline opts and > call tracetool module) > tracetool/__init__.py # common boilerplate code (e.g., event parsing > and call dispatching) > tracetool/format/__init__.py # format auto-registration/lookup code > tracetool/format/h.py # code for the 'h' format > # __doc__ [mandatory, format > description] > # def begin(events) [optional] > # def end(events) [optional] > tracetool/backend/__init__.py # backend auto-registration/lookup code > tracetool/backend/simple.py # code for the 'simple' backend > # __doc__ [mandatory, backend > description] > # PUBLIC = [True|False] [optional, > # defaults to False, > # indicates it's listed > on --list-backends] > # def format(events) [optional, > # backend-specific code for > given format, > # implicitly indicates > format compatibility] Let's call this function backend.generate(events) instead of "format" since we already use that term and it's a Python builtin too. This is a code generation function. > > Note that new formats will need to add new format routines in > 'tracetool/backend/nop.py' to accomodate whatever action has to be taken on > disabled events. I think it's more convenien
Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked
At 03/21/2012 05:11 PM, Gleb Natapov Wrote: > On Wed, Mar 21, 2012 at 08:56:03AM +0800, Wen Congyang wrote: >> At 03/20/2012 11:45 PM, Gleb Natapov Wrote: >>> On Tue, Mar 20, 2012 at 05:59:16PM +0800, Wen Congyang wrote: At 03/19/2012 03:33 PM, Wen Congyang Wrote: > At 03/08/2012 03:57 PM, Wen Congyang Wrote: >> We can know the guest is paniced when the guest runs on xen. >> But we do not have such feature on kvm. >> >> Another purpose of this feature is: management app(for example: >> libvirt) can do auto dump when the guest is crashed. If management >> app does not do auto dump, the guest's user can do dump by hand if >> he sees the guest is paniced. >> >> I touch the hypervisor instead of using virtio-serial, because >> 1. it is simple >> 2. the virtio-serial is an optional device, and the guest may >>not have such device. >> >> Changes from v2 to v3: >> 1. correct spelling >> >> Changes from v1 to v2: >> 1. split up host and guest-side changes >> 2. introduce new request flag to avoid changing return values. >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-kernel" >> in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> Please read the FAQ at http://www.tux.org/lkml/ >> > > > Hi all: > > we neet this feature, but we don't decide how to implement it. > We have two solution: > 1. use vmcall > 2. use virtio-serial. > > I will not change this patch set before we decide how to do it. > Can we make a decision recent days? Anybody can decide which solution to use? >>> To make an informed decision we need to have at least raw idea how >>> virtio-serial variant will look. >> >> Hmm, I think we can do this: >> 1. reset the virtio-serial device or reset the port we use to notice >>the host that guest is panicked. >> 2. write some specific messages to the port >> >> So the port should have fixed name. If this port is opened by the userspace >> before the guest is paniced, I am not sure whether we can use it(because a >> port only can be opened once at the same time). > Yes, IMO we should dedicate one virtio-serial port for panic > notifications. Just like we dedicate one for a console. > >> We cannot call any function in the module, so we may need to write a simple >> driver for virtio-serial(like diskdump's disk driver). >> > netconsole uses standard NIC drivers in polling mode to send OOPSes > over the network and it mostly works. So I think using virtio-serial > driver is not out of question, but with IRQ disabled of course. The code for netconsole is in which file? Another question: we cannot call the function in the module directly in the kernel. > >> I donot know how to implement it now. But I guess that it may be complicated. >> > Look at drivers/char/ipmi/ipmi_msghandler.c. It has code to send panic > event over IMPI. The code is pretty complex. Of course if we a going to > implement something more complex than simple hypercall for panic > notification we better do something more interesting with it than just > saying "panic happened", like sending stack traces on all cpus for > instance. If we implement it by virtio-serial, I agree with passing more useful message to host. Thanks Wen Congyang > > -- > Gleb. >
Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked
On Wed, Mar 21, 2012 at 05:35:49PM +0800, Wen Congyang wrote: > At 03/21/2012 05:11 PM, Gleb Natapov Wrote: > > On Wed, Mar 21, 2012 at 08:56:03AM +0800, Wen Congyang wrote: > >> At 03/20/2012 11:45 PM, Gleb Natapov Wrote: > >>> On Tue, Mar 20, 2012 at 05:59:16PM +0800, Wen Congyang wrote: > At 03/19/2012 03:33 PM, Wen Congyang Wrote: > > At 03/08/2012 03:57 PM, Wen Congyang Wrote: > >> We can know the guest is paniced when the guest runs on xen. > >> But we do not have such feature on kvm. > >> > >> Another purpose of this feature is: management app(for example: > >> libvirt) can do auto dump when the guest is crashed. If management > >> app does not do auto dump, the guest's user can do dump by hand if > >> he sees the guest is paniced. > >> > >> I touch the hypervisor instead of using virtio-serial, because > >> 1. it is simple > >> 2. the virtio-serial is an optional device, and the guest may > >>not have such device. > >> > >> Changes from v2 to v3: > >> 1. correct spelling > >> > >> Changes from v1 to v2: > >> 1. split up host and guest-side changes > >> 2. introduce new request flag to avoid changing return values. > >> -- > >> To unsubscribe from this list: send the line "unsubscribe > >> linux-kernel" in > >> the body of a message to majord...@vger.kernel.org > >> More majordomo info at http://vger.kernel.org/majordomo-info.html > >> Please read the FAQ at http://www.tux.org/lkml/ > >> > > > > > > Hi all: > > > > we neet this feature, but we don't decide how to implement it. > > We have two solution: > > 1. use vmcall > > 2. use virtio-serial. > > > > I will not change this patch set before we decide how to do it. > > Can we make a decision recent days? > > Anybody can decide which solution to use? > > >>> To make an informed decision we need to have at least raw idea how > >>> virtio-serial variant will look. > >> > >> Hmm, I think we can do this: > >> 1. reset the virtio-serial device or reset the port we use to notice > >>the host that guest is panicked. > >> 2. write some specific messages to the port > >> > >> So the port should have fixed name. If this port is opened by the userspace > >> before the guest is paniced, I am not sure whether we can use it(because a > >> port only can be opened once at the same time). > > Yes, IMO we should dedicate one virtio-serial port for panic > > notifications. Just like we dedicate one for a console. > > > >> We cannot call any function in the module, so we may need to write a simple > >> driver for virtio-serial(like diskdump's disk driver). > >> > > netconsole uses standard NIC drivers in polling mode to send OOPSes > > over the network and it mostly works. So I think using virtio-serial > > driver is not out of question, but with IRQ disabled of course. > > The code for netconsole is in which file? drivers/net/netconsole.c naturally. > Another question: we cannot call the function in the module directly in the > kernel. True I think. netconsole and actual NIC driver have a layer of abstraction between them. Modules can call functions from other modules. Your module can register to panic_notifier_list (like IPMI does) and call functions from virtio-serial. Or panic handling can be added directly to virtio-serial since it will have to be modified anyway. Something like netpoll API will have to be added to it. > > > >> I donot know how to implement it now. But I guess that it may be > >> complicated. > >> > > Look at drivers/char/ipmi/ipmi_msghandler.c. It has code to send panic > > event over IMPI. The code is pretty complex. Of course if we a going to > > implement something more complex than simple hypercall for panic > > notification we better do something more interesting with it than just > > saying "panic happened", like sending stack traces on all cpus for > > instance. > > If we implement it by virtio-serial, I agree with passing more useful message > to host. > -- Gleb.
Re: [Qemu-devel] [PATCH] fix incorrect bracket in tracetool
On Tue, Mar 20, 2012 at 5:11 PM, Lee Essen wrote: > On 20/03/2012 16:59, Stefan Hajnoczi wrote: >> >> On Mon, Mar 19, 2012 at 1:35 PM, Lee Essen >> wrote: >>> >>> On 19 Mar 2012, at 12:32, Andreas Färber wrote: >>> Am 19.03.2012 13:05, schrieb Lee Essen: In my original (way-too-long) patch for Illumos I included fixes for both of the above, the approach I took was to map "bool" to "int" and "self" to "_self" in the dtrace part of tracetool. So it should have had no impact on any non-dtrace stuff. If that seems like a sensible approach I will look again, and at the linking issues. >> >> That sounds like it can work. >> >> Stefan > > There are only 5 bool's and 4 self's in the whole of the trace-events file > ... is it easier to "fix" in there, or do you think a change to tracetool is > the most appropriate way? Folks will add more bool and maybe "self" in the future, so updating ./trace-events is not a permanent solution. tracetool has the ability to do two things: 1. It can reject invalid trace-events input. 2. It can fudge the generated trace backend code so that "self" gets turned into "self_", for example. #2 is nice when we can do it without confusing users. I suggest modifying tracetool. You may wish to hold off on this for a week because we're about to merge the Python version of tracetool, which makes it much more portable. Stefan
[Qemu-devel] Thoughts around dtrace linking...
Hi, I've been trying to find a sensible way to solve the Solaris/Illumos dtrace requirement to pass all the objs to the dtrace command so that the resultant object file contains all the symbols needed to properly link the relevant binary. The easiest way to do this is just prior to linking the binary, so something like this (in rules.mak): LINK = $(call quiet-command,$(CC) $(QEMU_CFLAGS) $(CFLAGS) $(LDFLAGS) -o $@ $(sort $(1)) $(LIBS)," LINK $(TARGET_DIR)$@") DTRACE = $(call quiet-command,dtrace $(CONFIG_DTRACE_FLAGS) -o $(1)-dtrace.o -G -s $(2) $(3), " GEN $(TARGET_DIR)$(1)-dtrace.o") %$(EXESUF): %.o $(call DTRACE,$*,trace-dtrace.dtrace,$^) $(call LINK,$^ $*-dtrace.o) Obviously with the relevant tests around it to check the trace backend, and also an adjustment in Makefile.target to cause the right thing to happen for each target. Or, is there a better way? How compatible is this with FreeBSD - it doesn't sound like it's needed at all? Regards, Lee.
Re: [Qemu-devel] [PATCH v2] tracetool dtrace disabled-events fix
On Tue, Mar 20, 2012 at 05:02:40PM +, Lee Essen wrote: > If there are "disabled" entries in the trace-events file then > linetod_nop() is called if the backend is dtrace, it's currently > not present. Also equivalent fix for stap. > > Signed-off-by: Lee Essen > > -- Thanks, applied to the tracing patches tree: https://github.com/stefanha/qemu/commits/tracing Note that this patch has whitespace damage. I hat to apply it manually because git-am(1) would not accept it. Please check your patch sending process - using git-send-email(1) works best and shouldn't mangle whitespace. Also please use "Lee Essen " with a space between the name and email address. I'm not sure if any parsers have problems when the space is missing, but it normally needs to be there. Stefan
Re: [Qemu-devel] [PATCH] Remove PCI class code from virtio balloon device
On Tue, Mar 20, 2012 at 09:19:47PM +1100, David Gibson wrote: > On Tue, Mar 20, 2012 at 09:54:20AM +, Stefan Hajnoczi wrote: > > On Tue, Mar 20, 2012 at 12:42 AM, David Gibson > > wrote: > > > On Mon, Mar 19, 2012 at 11:33:10AM +, Stefan Hajnoczi wrote: > > >> On Mon, Mar 19, 2012 at 03:59:23PM +1100, David Gibson wrote: > > >> > Currently the virtio balloon device, when using the virtio-pci > > >> > interface > > >> > advertises itself with PCI class code MEMORY_RAM. This is wrong; the > > >> > balloon is vaguely related to memory, but is nothing like a PCI memory > > >> > device in the meaning of the class code, and this code is not required > > >> > or > > >> > suggested by the virtio PCI specification. > > >> > > > >> > Worse, this patch causes problems on the pseries machine, because the > > >> > firmware, seeing this class code, advertises the device as memory in > > >> > the > > >> > device tree, and then a guest kernel bug causes it to see this "memory" > > >> > before the real system memory, leading to a crash in early boot. > > >> > > > >> > This patch fixes the problem by removing the bogus PCI class code on > > >> > the > > >> > balloon device. > > >> > > > >> > Cc: Michael S. Tsirkin > > >> > Cc: Rusty Russell > > >> > > > >> > Signed-off-by: David Gibson > > >> > --- > > >> > hw/virtio-pci.c | 2 +- > > >> > 1 files changed, 1 insertions(+), 1 deletions(-) > > >> > > >> Since this is a guest-visible change we might need to be careful about > > >> how it's introduced. > > >> > > >> Do we need to keep the old class code for existing machine types? The > > >> new class code could be introduced only for 1.1 and later machine types > > >> if we want to be extra careful about introducing guest-visible > > >> changes. > > > > > > So as a general rule, I like to be very careful about user-visible > > > changes. But in this case, I don't think we want to be too hesitant. > > > In particular, it's not just a question of the machine type, but also > > > of how the guest OS will deal with the PCI class code. > > > > > > The class code we were using was Just Plain Wrong. It was not > > > suggetsed by the virtio spec, and it makes no sense. It happens that > > > so far this caused problems only for a guest on a particular machine > > > type, but there's no reason it couldn't cause (different) problems for > > > guests on any machine type. > > > > > > More to the point, it seems reasonably unlikely for existing guests to > > > rely on the broken behaviour: again, there's no reason they'd think > > > they need to based on the spec, and the usual way of matching drivers > > > to PCI devices is with the vendor/device IDs which are correct and not > > > changed by this patch. > > > > > > So, unless we have a known example of an existing guest that would be > > > broken by this change, I think we should implement it ASAP for all > > > machine types. > > > > I agree that in practice the risk is low because working guests are > > probably not using the class code. On the other hand I don't see a > > downside to making this part of the 1.1 machine type, > > Well.. there's the fact that I can't what mechanism we would use to > make this per-machine... Not sure I parsed this correctly, but I think you're asking how to do it. Looking at hw/pc_piix.c there are QEMUMachine types for each QEMU release. Legacy machine types (e.g. pc_machine_v0_14) have a .compat_props array that can override qdev properties. Perhaps Michael Tsirkin or someone else can comment on how to wire up hw/virtio-pci.c so that the class code can be overridden. Stefan
Re: [Qemu-devel] [PATCH] Remove PCI class code from virtio balloon device
Hi, It seems your Mail-Followup-To: header causes my client to drop you from the To: list. On Wed, Mar 21, 2012 at 11:26 AM, Stefan Hajnoczi wrote: > On Tue, Mar 20, 2012 at 09:19:47PM +1100, David Gibson wrote: >> On Tue, Mar 20, 2012 at 09:54:20AM +, Stefan Hajnoczi wrote: >> > On Tue, Mar 20, 2012 at 12:42 AM, David Gibson >> > wrote: >> > > On Mon, Mar 19, 2012 at 11:33:10AM +, Stefan Hajnoczi wrote: >> > >> On Mon, Mar 19, 2012 at 03:59:23PM +1100, David Gibson wrote: >> > >> > Currently the virtio balloon device, when using the virtio-pci >> > >> > interface >> > >> > advertises itself with PCI class code MEMORY_RAM. This is wrong; the >> > >> > balloon is vaguely related to memory, but is nothing like a PCI memory >> > >> > device in the meaning of the class code, and this code is not >> > >> > required or >> > >> > suggested by the virtio PCI specification. >> > >> > >> > >> > Worse, this patch causes problems on the pseries machine, because the >> > >> > firmware, seeing this class code, advertises the device as memory in >> > >> > the >> > >> > device tree, and then a guest kernel bug causes it to see this >> > >> > "memory" >> > >> > before the real system memory, leading to a crash in early boot. >> > >> > >> > >> > This patch fixes the problem by removing the bogus PCI class code on >> > >> > the >> > >> > balloon device. >> > >> > >> > >> > Cc: Michael S. Tsirkin >> > >> > Cc: Rusty Russell >> > >> > >> > >> > Signed-off-by: David Gibson >> > >> > --- >> > >> > hw/virtio-pci.c | 2 +- >> > >> > 1 files changed, 1 insertions(+), 1 deletions(-) >> > >> >> > >> Since this is a guest-visible change we might need to be careful about >> > >> how it's introduced. >> > >> >> > >> Do we need to keep the old class code for existing machine types? The >> > >> new class code could be introduced only for 1.1 and later machine types >> > >> if we want to be extra careful about introducing guest-visible >> > >> changes. >> > > >> > > So as a general rule, I like to be very careful about user-visible >> > > changes. But in this case, I don't think we want to be too hesitant. >> > > In particular, it's not just a question of the machine type, but also >> > > of how the guest OS will deal with the PCI class code. >> > > >> > > The class code we were using was Just Plain Wrong. It was not >> > > suggetsed by the virtio spec, and it makes no sense. It happens that >> > > so far this caused problems only for a guest on a particular machine >> > > type, but there's no reason it couldn't cause (different) problems for >> > > guests on any machine type. >> > > >> > > More to the point, it seems reasonably unlikely for existing guests to >> > > rely on the broken behaviour: again, there's no reason they'd think >> > > they need to based on the spec, and the usual way of matching drivers >> > > to PCI devices is with the vendor/device IDs which are correct and not >> > > changed by this patch. >> > > >> > > So, unless we have a known example of an existing guest that would be >> > > broken by this change, I think we should implement it ASAP for all >> > > machine types. >> > >> > I agree that in practice the risk is low because working guests are >> > probably not using the class code. On the other hand I don't see a >> > downside to making this part of the 1.1 machine type, >> >> Well.. there's the fact that I can't what mechanism we would use to >> make this per-machine... > > Not sure I parsed this correctly, but I think you're asking how to do > it. > > Looking at hw/pc_piix.c there are QEMUMachine types for each QEMU > release. Legacy machine types (e.g. pc_machine_v0_14) have a > .compat_props array that can override qdev properties. > > Perhaps Michael Tsirkin or someone else can comment on how to wire up > hw/virtio-pci.c so that the class code can be overridden. > > Stefan
Re: [Qemu-devel] [PATCH 1/3] test: remove qemu-ga reference
On Tue, Mar 20, 2012 at 12:18 AM, Michael Roth wrote: > This was added by mistake a while back. > > Signed-off-by: Michael Roth > --- > tests/Makefile | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) After applying your series and rebuilding, I get the following error. I checked that there are no auto-generated files left around after make distclean. $ make distclean $ ./configure --target-list=x86_64-softmmu --disable-werror $ make GEN x86_64-softmmu/config-devices.mak GEN config-all-devices.mak GEN qemu-options.texi GEN qemu-monitor.texi GEN qemu-img-cmds.texi GEN qemu-doc.html GEN qemu-tech.html GEN qemu.1 GEN qemu-img.1 GEN qemu-nbd.8 GEN QMP/qmp-commands.txt GEN config-host.h GEN trace.h GEN qemu-options.def GEN qmp-commands.h GEN qapi-types.h GEN qapi-visit.h GEN /home/stefanha/qemu/qapi-generated/qga-qapi-types.h GEN /home/stefanha/qemu/qapi-generated/qga-qapi-visit.h GEN /home/stefanha/qemu/qapi-generated/qga-qmp-commands.h CCqemu-ga.o CCqga/commands.o qga/commands.c:15:30: fatal error: qga-qmp-commands.h: No such file or directory compilation terminated. make: *** [qga/commands.o] Error 1
Re: [Qemu-devel] [PATCH V2 1/3] exynos4210: add Exynos4210 i2c implementation
On 15 March 2012 07:35, Igor Mitsyanko wrote: > Create 9 exynos4210 i2c interfaces. > > Signed-off-by: Igor Mitsyanko Mostly this looks OK but I still find the i2c slave stuff odd -- should the controller really register itself as a slave on its own bus? Doesn't this mean that the controller can effectively try to talk to itself? Does the hardware let you do that? I suspect that what's happening here is that the hardware lets you put the i2c controller into slave mode so some other device on the bus can be a master. But QEMU's i2c bus abstraction doesn't cover that use case at all... Anyway, I don't know enough about i2c to really be able to review this patch properly in that area. Anybody? -- PMM
Re: [Qemu-devel] [PATCH v3] Man page: Add -global description
Miroslav Rezanina writes:
> There's only TODO information in qemu man page for -global option. This is a
> basic description of this option with simple example.
>
> Signed-off-by: Miroslav Rezanina
>
> Patch:
> --
> diff --git a/qemu-options.hx b/qemu-options.hx
> index daefce3..db8be37 100644
> --- a/qemu-options.hx
> +++ b/qemu-options.hx
> @@ -288,13 +288,19 @@ TODO
> ETEXI
>
> DEF("global", HAS_ARG, QEMU_OPTION_global,
> -"-global driver.property=value\n"
> +"-global driver.prop=value\n"
> "set a global default for a driver property\n",
> QEMU_ARCH_ALL)
> STEXI
> -@item -global
> +@item -global @var{driver}.@var{prop}=@var{value}
> @findex -global
> -TODO
> +Set default value of @var{driver}'s property @var{prop} to @var{value}, e.g.:
> +
> +@example
> +qemu -global ide-drive.physical_block_size=4096 -drive
> file=file,if=ide,index=0,media=disk
> +@end example
> +
> +In particular, you can use this to set driver properties for devices which
> are created automatically by the machine model. To create a device which is
> not created automatically and set properties on it, use -@option{device}.
Long line, please wrap.
> ETEXI
>
> DEF("mtdblock", HAS_ARG, QEMU_OPTION_mtdblock,
Re: [Qemu-devel] [PATCH] Fix typo in i400FX chipset init code
Alexey Korolev writes:
>> Hi,
>>
>> There is a typo in i440FX init code. This is causing problems when
>> somebody wants to access 64bit PCI range.
>>
>>
>> Signed-off-by: Alexey Korolev
>> ---
>>
>> hw/piix_pci.c |2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/hw/piix_pci.c b/hw/piix_pci.c
>> index 3ed3d90..aab8188 100644
>> --- a/hw/piix_pci.c
>> +++ b/hw/piix_pci.c
>> @@ -353,7 +353,7 @@ PCIBus *i440fx_init(PCII440FXState **pi440fx_state, int
>> *piix3_devfn,
>> b = i440fx_common_init("i440FX", pi440fx_state, piix3_devfn, isa_bus,
>> pic,
>> address_space_mem, address_space_io, ram_size,
>> pci_hole_start, pci_hole_size,
>> - pci_hole64_size, pci_hole64_size,
>> + pci_hole64_start, pci_hole64_size,
>> pci_memory, ram_memory);
>> return b;
>> }
>>
>>
>>
> Hi there,
>
> Any chance that someone could have a look and commit this?
Stefan, would you like to take this through your trivial queue?
Re: [Qemu-devel] [PATCH] Fix typo in i400FX chipset init code
Hi,
Am 21.03.2012 06:26, schrieb Alexey Korolev:
>> Hi,
>>
>> There is a typo in i440FX init code. This is causing problems when
>> somebody wants to access 64bit PCI range.
>>
>>
>> Signed-off-by: Alexey Korolev
>> ---
>>
>> hw/piix_pci.c |2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/hw/piix_pci.c b/hw/piix_pci.c
>> index 3ed3d90..aab8188 100644
>> --- a/hw/piix_pci.c
>> +++ b/hw/piix_pci.c
>> @@ -353,7 +353,7 @@ PCIBus *i440fx_init(PCII440FXState **pi440fx_state, int
>> *piix3_devfn,
>> b = i440fx_common_init("i440FX", pi440fx_state, piix3_devfn, isa_bus,
>> pic,
>> address_space_mem, address_space_io, ram_size,
>> pci_hole_start, pci_hole_size,
>> - pci_hole64_size, pci_hole64_size,
>> + pci_hole64_start, pci_hole64_size,
>> pci_memory, ram_memory);
>> return b;
>> }
>>
>>
>>
> Hi there,
>
> Any chance that someone could have a look and commit this?
A patch should never start with "Hi,", it should have a commit message
that can be applied unmodified to git, describing what area it touches,
what it changes and why. So, the the subject should start with, e.g.,
"i440fx: Fix start of 64-bit hole" and go on to explain where exactly
that is and what it affects (does this resolve some guest-visible bug?
when was it introduced? i.e., does it need to be backported?). Repeating
"typo" again and again is not helpful to understand the impact of a
commit when bisecting later on without seeing the code.
You forgot to cc the PCI maintainer.
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] fix '-cpu ?' Segfault
Fix stupid copy&paste mistake at commit
ecf40beae7dcbb057d4f115207f9d8276832a774: I moved code around but kept
"optarg" on the cpu_list() call.
Reported-by: Jiri Denemark
Signed-off-by: Eduardo Habkost
---
vl.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/vl.c b/vl.c
index 112b0e0..0fccf50 100644
--- a/vl.c
+++ b/vl.c
@@ -3196,7 +3196,7 @@ int main(int argc, char **argv, char **envp)
cpudef_init();
if (cpu_model && *cpu_model == '?') {
-list_cpus(stdout, &fprintf, optarg);
+list_cpus(stdout, &fprintf, cpu_model);
exit(0);
}
--
1.7.3.2
Re: [Qemu-devel] [PATCH] Fix typo in i400FX chipset init code
Am 21.03.2012 13:28, schrieb Markus Armbruster:
> Alexey Korolev writes:
>
>>> Hi,
>>>
>>> There is a typo in i440FX init code. This is causing problems when
>>> somebody wants to access 64bit PCI range.
>>>
>>>
>>> Signed-off-by: Alexey Korolev
>>> ---
>>>
>>> hw/piix_pci.c |2 +-
>>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/hw/piix_pci.c b/hw/piix_pci.c
>>> index 3ed3d90..aab8188 100644
>>> --- a/hw/piix_pci.c
>>> +++ b/hw/piix_pci.c
>>> @@ -353,7 +353,7 @@ PCIBus *i440fx_init(PCII440FXState **pi440fx_state, int
>>> *piix3_devfn,
>>> b = i440fx_common_init("i440FX", pi440fx_state, piix3_devfn, isa_bus,
>>> pic,
>>> address_space_mem, address_space_io, ram_size,
>>> pci_hole_start, pci_hole_size,
>>> - pci_hole64_size, pci_hole64_size,
>>> + pci_hole64_start, pci_hole64_size,
>>> pci_memory, ram_memory);
>>> return b;
>>> }
>>>
>>>
>>>
>> Hi there,
>>
>> Any chance that someone could have a look and commit this?
>
> Stefan, would you like to take this through your trivial queue?
Not without fixing up the commit message, please. CC'ing mst since this
is a PCI issue and not some random unmaintained area of code.
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 uq/master] kvm: Drop redundant kvm_enabled from cpu_thread_is_idle
This is now implied by kvm_irqchip_in_kernel.
Signed-off-by: Jan Kiszka
---
cpus.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/cpus.c b/cpus.c
index 17b055f..cf732b4 100644
--- a/cpus.c
+++ b/cpus.c
@@ -421,8 +421,7 @@ static bool cpu_thread_is_idle(CPUState *env)
if (env->stopped || !runstate_is_running()) {
return true;
}
-if (!env->halted || qemu_cpu_has_work(env) ||
-(kvm_enabled() && kvm_irqchip_in_kernel())) {
+if (!env->halted || qemu_cpu_has_work(env) || kvm_irqchip_in_kernel()) {
return false;
}
return true;
--
1.7.3.4
[Qemu-devel] [PATCH uq/master] kvm: Drop unused kvm_pit_in_kernel
This is now implied by kvm_irqchip_in_kernel.
Signed-off-by: Jan Kiszka
---
kvm-all.c |6 --
kvm-stub.c |6 --
kvm.h |2 --
3 files changed, 0 insertions(+), 14 deletions(-)
diff --git a/kvm-all.c b/kvm-all.c
index 21c7dd2..7f8c188 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -75,7 +75,6 @@ struct KVMState
#ifdef KVM_CAP_SET_GUEST_DEBUG
struct kvm_sw_breakpoint_head kvm_sw_breakpoints;
#endif
-int pit_in_kernel;
int pit_state2;
int xsave, xcrs;
int many_ioeventfds;
@@ -195,11 +194,6 @@ static void kvm_reset_vcpu(void *opaque)
kvm_arch_reset_vcpu(env);
}
-int kvm_pit_in_kernel(void)
-{
-return kvm_state->pit_in_kernel;
-}
-
int kvm_init_vcpu(CPUState *env)
{
KVMState *s = kvm_state;
diff --git a/kvm-stub.c b/kvm-stub.c
index 1f1c686..fab3ab1 100644
--- a/kvm-stub.c
+++ b/kvm-stub.c
@@ -16,12 +16,6 @@
#include "gdbstub.h"
#include "kvm.h"
-int kvm_pit_in_kernel(void)
-{
-return 0;
-}
-
-
int kvm_init_vcpu(CPUState *env)
{
return -ENOSYS;
diff --git a/kvm.h b/kvm.h
index 8ef4476..128cc8f 100644
--- a/kvm.h
+++ b/kvm.h
@@ -83,8 +83,6 @@ int kvm_update_guest_debug(CPUState *env, unsigned long
reinject_trap);
int kvm_set_signal_mask(CPUState *env, const sigset_t *sigset);
#endif
-int kvm_pit_in_kernel(void);
-
int kvm_on_sigbus_vcpu(CPUState *env, int code, void *addr);
int kvm_on_sigbus(int code, void *addr);
--
1.7.3.4
Re: [Qemu-devel] [PATCH 3/3] configure: add --confsuffix option
Il 20/03/2012 21:15, Eduardo Habkost ha scritto:
> This way we can choose a configuration file path different from
> ${sysconfdir}/PACKAGE.
>
> This also changes the configure output to show the full configuration
> dir path (including $confsuffix), instead of just $sysconfdir.
Can you please apply this to datadir too? (i.e. set the datadir default
to just $prefix/share, and later add $confsuffix).
Paolo
Re: [Qemu-devel] [PATCH 1/3] Makefile: use $(confdir) instead of hardcoding $(sysconfdir)/qemu
Il 20/03/2012 21:15, Eduardo Habkost ha scritto: > Signed-off-by: Eduardo Habkost > --- > Makefile |4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/Makefile b/Makefile > index 1bc3cb0..9d583c4 100644 > --- a/Makefile > +++ b/Makefile > @@ -279,8 +279,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)$(confdir)" > + $(INSTALL_DATA) $(SRC_PATH)/sysconfigs/target/target-x86_64.conf > "$(DESTDIR)$(confdir)" > > install: all $(if $(BUILD_DOCS),install-doc) install-sysconfig > $(INSTALL_DIR) "$(DESTDIR)$(bindir)" Reviewed-by: Paolo Bonzini
Re: [Qemu-devel] [PATCH 2/3] qemu-options.hx: refer to confdir instead of sysconfdir on docs
Il 20/03/2012 21:15, Eduardo Habkost ha scritto:
> The current docs are wrong: ${sysconfdir} is (by default) /etc,
> ${confdir} is (by default) /etc/qemu, that's where the config files are
> stored.
>
> Signed-off-by: Eduardo Habkost
> ---
> qemu-options.hx |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/qemu-options.hx b/qemu-options.hx
> index daefce3..39578f1 100644
> --- a/qemu-options.hx
> +++ b/qemu-options.hx
> @@ -2676,8 +2676,8 @@ DEF("nodefconfig", 0, QEMU_OPTION_nodefconfig,
> STEXI
> @item -nodefconfig
> @findex -nodefconfig
> -Normally QEMU loads a configuration file from @var{sysconfdir}/qemu.conf and
> -@var{sysconfdir}/target-@var{ARCH}.conf on startup. The @code{-nodefconfig}
> +Normally QEMU loads a configuration file from @var{confdir}/qemu.conf and
> +@var{confdir}/target-@var{ARCH}.conf on startup. The @code{-nodefconfig}
> option will prevent QEMU from loading these configuration files at startup.
> ETEXI
> DEF("trace", HAS_ARG, QEMU_OPTION_trace,
There's no definition of confdir and sysconfdir in the documentation.
Perhaps writing @var{sysconfdir}/qemu/qemu.conf is better for now?
Paolo
[Qemu-devel] [PATCH v4] Man page: Add -global description
There's only TODO information in qemu man page for -global option. This is a
basic description of this option with simple example.
Signed-off-by: Miroslav Rezanina
v4:
- break long line
v3:
- add use case description
- use prop instead of property
v2:
- Use better value in example
Patch:
--
diff --git a/qemu-options.hx b/qemu-options.hx
index daefce3..662f571 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -288,13 +288,21 @@ TODO
ETEXI
DEF("global", HAS_ARG, QEMU_OPTION_global,
-"-global driver.property=value\n"
+"-global driver.prop=value\n"
"set a global default for a driver property\n",
QEMU_ARCH_ALL)
STEXI
-@item -global
+@item -global @var{driver}.@var{prop}=@var{value}
@findex -global
-TODO
+Set default value of @var{driver}'s property @var{prop} to @var{value}, e.g.:
+
+@example
+qemu -global ide-drive.physical_block_size=4096 -drive
file=file,if=ide,index=0,media=disk
+@end example
+
+In particular, you can use this to set driver properties for devices which are
+created automatically by the machine model. To create a device which is not
+created automatically and set properties on it, use -@option{device}.
ETEXI
DEF("mtdblock", HAS_ARG, QEMU_OPTION_mtdblock,
Re: [Qemu-devel] [PATCH] Fix typo in i400FX chipset init code
On Wed, Feb 29, 2012 at 02:35:14PM +1300, Alexey Korolev wrote:
> Hi,
>
> There is a typo in i440FX init code. This is causing problems when
> somebody wants to access 64bit PCI range.
>
>
> Signed-off-by: Alexey Korolev
I've fixed the commit message and applied.
How does one trigger the problem?
I'd like to know so I can test for it.
> ---
>
> hw/piix_pci.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/hw/piix_pci.c b/hw/piix_pci.c
> index 3ed3d90..aab8188 100644
> --- a/hw/piix_pci.c
> +++ b/hw/piix_pci.c
> @@ -353,7 +353,7 @@ PCIBus *i440fx_init(PCII440FXState **pi440fx_state, int
> *piix3_devfn,
> b = i440fx_common_init("i440FX", pi440fx_state, piix3_devfn, isa_bus,
> pic,
> address_space_mem, address_space_io, ram_size,
> pci_hole_start, pci_hole_size,
> - pci_hole64_size, pci_hole64_size,
> + pci_hole64_start, pci_hole64_size,
> pci_memory, ram_memory);
> return b;
> }
>
>
>
>
Re: [Qemu-devel] Thoughts around dtrace linking...
Hi, Am 21.03.2012 11:45, schrieb Lee Essen: > I've been trying to find a sensible way to solve the Solaris/Illumos > dtrace requirement to pass all the objs to the dtrace command so that > the resultant object file contains all the symbols needed to properly > link the relevant binary. > > The easiest way to do this is just prior to linking the binary, so > something like this (in rules.mak): > > LINK = $(call quiet-command,$(CC) $(QEMU_CFLAGS) $(CFLAGS) > $(LDFLAGS) -o $@ $(sort $(1)) $(LIBS)," LINK $(TARGET_DIR)$@") > > DTRACE = $(call quiet-command,dtrace $(CONFIG_DTRACE_FLAGS) -o > $(1)-dtrace.o -G -s $(2) $(3), " GEN $(TARGET_DIR)$(1)-dtrace.o") > > %$(EXESUF): %.o > $(call DTRACE,$*,trace-dtrace.dtrace,$^) > $(call LINK,$^ $*-dtrace.o) > > Obviously with the relevant tests around it to check the trace backend, > and also an adjustment in Makefile.target to cause the right thing to > happen for each target. > Or, is there a better way? The two issues I see (as info for Stefan et al.) are a) compiling DTrace probes into .o files requires linking those objects with that additional .o file to avoid linker errors (even for tools where using DTrace probes does not seem to make much sense), b) the additional .o file depends on its input .o files, so must be unique per executable. This seems to be guaranteed when doing it at rules.mak level. Haven't checked all the variables being passed back and forth here yet though; I really am not comfortable reviewing code that's HTML-formatted in my mailer. ;) > How compatible is this with FreeBSD - it doesn't sound like it's needed > at all? Don't know about FreeBSD but on Darwin that step is indeed not needed or supported, so needs to be guarded. 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] Fix typo in i400FX chipset init code
On Wed, Mar 21, 2012 at 01:32:44PM +0100, Andreas Färber wrote:
> Hi,
>
> Am 21.03.2012 06:26, schrieb Alexey Korolev:
> >> Hi,
> >>
> >> There is a typo in i440FX init code. This is causing problems when
> >> somebody wants to access 64bit PCI range.
> >>
> >>
> >> Signed-off-by: Alexey Korolev
> >> ---
> >>
> >> hw/piix_pci.c |2 +-
> >> 1 files changed, 1 insertions(+), 1 deletions(-)
> >>
> >> diff --git a/hw/piix_pci.c b/hw/piix_pci.c
> >> index 3ed3d90..aab8188 100644
> >> --- a/hw/piix_pci.c
> >> +++ b/hw/piix_pci.c
> >> @@ -353,7 +353,7 @@ PCIBus *i440fx_init(PCII440FXState **pi440fx_state,
> >> int *piix3_devfn,
> >> b = i440fx_common_init("i440FX", pi440fx_state, piix3_devfn, isa_bus,
> >> pic,
> >> address_space_mem, address_space_io, ram_size,
> >> pci_hole_start, pci_hole_size,
> >> - pci_hole64_size, pci_hole64_size,
> >> + pci_hole64_start, pci_hole64_size,
> >> pci_memory, ram_memory);
> >> return b;
> >> }
> >>
> >>
> >>
> > Hi there,
> >
> > Any chance that someone could have a look and commit this?
>
> A patch should never start with "Hi,", it should have a commit message
> that can be applied unmodified to git, describing what area it touches,
> what it changes and why. So, the the subject should start with, e.g.,
> "i440fx: Fix start of 64-bit hole" and go on to explain where exactly
> that is and what it affects (does this resolve some guest-visible bug?
> when was it introduced? i.e., does it need to be backported?). Repeating
> "typo" again and again is not helpful to understand the impact of a
> commit when bisecting later on without seeing the code.
>
> You forgot to cc the PCI maintainer.
>
> Andreas
Yes I'd like to see an explanation on how to trigger a bug too.
OTOH the fix is clearly right, and it's not submitter's
work to dig through history to find where was the bug
added, that is too much to ask IMO.
> --
> 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] Remove PCI class code from virtio balloon device
On Wed, Mar 21, 2012 at 11:26:15AM +, Stefan Hajnoczi wrote: > On Tue, Mar 20, 2012 at 09:19:47PM +1100, David Gibson wrote: > > On Tue, Mar 20, 2012 at 09:54:20AM +, Stefan Hajnoczi wrote: > > > On Tue, Mar 20, 2012 at 12:42 AM, David Gibson > > > wrote: > > > > On Mon, Mar 19, 2012 at 11:33:10AM +, Stefan Hajnoczi wrote: > > > >> On Mon, Mar 19, 2012 at 03:59:23PM +1100, David Gibson wrote: > > > >> > Currently the virtio balloon device, when using the virtio-pci > > > >> > interface > > > >> > advertises itself with PCI class code MEMORY_RAM. This is wrong; the > > > >> > balloon is vaguely related to memory, but is nothing like a PCI > > > >> > memory > > > >> > device in the meaning of the class code, and this code is not > > > >> > required or > > > >> > suggested by the virtio PCI specification. > > > >> > > > > >> > Worse, this patch causes problems on the pseries machine, because the > > > >> > firmware, seeing this class code, advertises the device as memory in > > > >> > the > > > >> > device tree, and then a guest kernel bug causes it to see this > > > >> > "memory" > > > >> > before the real system memory, leading to a crash in early boot. > > > >> > > > > >> > This patch fixes the problem by removing the bogus PCI class code on > > > >> > the > > > >> > balloon device. > > > >> > > > > >> > Cc: Michael S. Tsirkin > > > >> > Cc: Rusty Russell > > > >> > > > > >> > Signed-off-by: David Gibson > > > >> > --- > > > >> > hw/virtio-pci.c | 2 +- > > > >> > 1 files changed, 1 insertions(+), 1 deletions(-) > > > >> > > > >> Since this is a guest-visible change we might need to be careful about > > > >> how it's introduced. > > > >> > > > >> Do we need to keep the old class code for existing machine types? The > > > >> new class code could be introduced only for 1.1 and later machine types > > > >> if we want to be extra careful about introducing guest-visible > > > >> changes. > > > > > > > > So as a general rule, I like to be very careful about user-visible > > > > changes. But in this case, I don't think we want to be too hesitant. > > > > In particular, it's not just a question of the machine type, but also > > > > of how the guest OS will deal with the PCI class code. > > > > > > > > The class code we were using was Just Plain Wrong. It was not > > > > suggetsed by the virtio spec, and it makes no sense. It happens that > > > > so far this caused problems only for a guest on a particular machine > > > > type, but there's no reason it couldn't cause (different) problems for > > > > guests on any machine type. > > > > > > > > More to the point, it seems reasonably unlikely for existing guests to > > > > rely on the broken behaviour: again, there's no reason they'd think > > > > they need to based on the spec, and the usual way of matching drivers > > > > to PCI devices is with the vendor/device IDs which are correct and not > > > > changed by this patch. > > > > > > > > So, unless we have a known example of an existing guest that would be > > > > broken by this change, I think we should implement it ASAP for all > > > > machine types. > > > > > > I agree that in practice the risk is low because working guests are > > > probably not using the class code. On the other hand I don't see a > > > downside to making this part of the 1.1 machine type, > > > > Well.. there's the fact that I can't what mechanism we would use to > > make this per-machine... > > Not sure I parsed this correctly, but I think you're asking how to do > it. > > Looking at hw/pc_piix.c there are QEMUMachine types for each QEMU > release. Legacy machine types (e.g. pc_machine_v0_14) have a > .compat_props array that can override qdev properties. > > Perhaps Michael Tsirkin or someone else can comment on how to wire up > hw/virtio-pci.c so that the class code can be overridden. > > Stefan afaik we already let users over-write it for some other pci devices, look there for examples.
Re: [Qemu-devel] [PATCH V2 1/3] exynos4210: add Exynos4210 i2c implementation
On 21 March 2012 13:07, Igor Mitsyanko wrote: > On 03/21/2012 03:55 PM, Peter Maydell wrote: >> I suspect that what's happening here is that the hardware >> lets you put the i2c controller into slave mode so some >> other device on the bus can be a master. But QEMU's >> i2c bus abstraction doesn't cover that use case at all... > Yes, I saw this statement in hw/i2c.h (and probably cpu i2c controller will > never be used as i2c slave device by anyone), but I think we still have to > implement devices exactly like they described in documentation. I agree with the sentiment, I'm just not sure if the code you've written is actually doing that. The right way to model this would be if our i2c bus implementation provided an interface so you could register as a device which is a master but can switch into slave mode. Failing that, maybe we should just not support switching into slave mode at all. Registering as two separate devices on the i2c bus doesn't sound right to me. -- PMM
Re: [Qemu-devel] [PATCH] fix '-cpu ?' Segfault
On Wed, Mar 21, 2012 at 09:33:40AM -0300, Eduardo Habkost wrote: > Fix stupid copy&paste mistake at commit > ecf40beae7dcbb057d4f115207f9d8276832a774: I moved code around but kept > "optarg" on the cpu_list() call. > > Reported-by: Jiri Denemark > Signed-off-by: Eduardo Habkost > --- > vl.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) Thanks, applied to the trivial patches tree: https://github.com/stefanha/qemu/commits/trivial-patches Stefan
Re: [Qemu-devel] [PATCH] Remove PCI class code from virtio balloon device
On Wed, Mar 21, 2012 at 11:28:47AM +, Stefan Hajnoczi wrote: > Hi, > It seems your Mail-Followup-To: header causes my client to drop you > from the To: list. Not mine, it's added by the list AFAICT. And it's frickin' annoying. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson
Re: [Qemu-devel] [PATCH 2/3] qemu-options.hx: refer to confdir instead of sysconfdir on docs
On Wed, Mar 21, 2012 at 01:43:58PM +0100, Paolo Bonzini wrote:
> Il 20/03/2012 21:15, Eduardo Habkost ha scritto:
> > The current docs are wrong: ${sysconfdir} is (by default) /etc,
> > ${confdir} is (by default) /etc/qemu, that's where the config files are
> > stored.
> >
> > Signed-off-by: Eduardo Habkost
> > ---
> > qemu-options.hx |4 ++--
> > 1 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/qemu-options.hx b/qemu-options.hx
> > index daefce3..39578f1 100644
> > --- a/qemu-options.hx
> > +++ b/qemu-options.hx
> > @@ -2676,8 +2676,8 @@ DEF("nodefconfig", 0, QEMU_OPTION_nodefconfig,
> > STEXI
> > @item -nodefconfig
> > @findex -nodefconfig
> > -Normally QEMU loads a configuration file from @var{sysconfdir}/qemu.conf
> > and
> > -@var{sysconfdir}/target-@var{ARCH}.conf on startup. The
> > @code{-nodefconfig}
> > +Normally QEMU loads a configuration file from @var{confdir}/qemu.conf and
> > +@var{confdir}/target-@var{ARCH}.conf on startup. The @code{-nodefconfig}
> > option will prevent QEMU from loading these configuration files at startup.
> > ETEXI
> > DEF("trace", HAS_ARG, QEMU_OPTION_trace,
>
> There's no definition of confdir and sysconfdir in the documentation.
> Perhaps writing @var{sysconfdir}/qemu/qemu.conf is better for now?
Maybe it would be better, yes, as it gives a better hint for the user of
where the config directory may be.
But it's still not very clear for the user. Is it possible to expand
build-time config variables inside the documentation so they show the
full path? I have zero knowledge about texinfo, and even less about the
texinfo conversion scripts Qemu uses (do they support the full texinfo
language, or just a subset of it?).
--
Eduardo
Re: [Qemu-devel] [PATCH uq/master] kvm: Drop redundant kvm_enabled from cpu_thread_is_idle
On 03/21/2012 02:36 PM, Jan Kiszka wrote: > This is now implied by kvm_irqchip_in_kernel. > > Applied, thanks. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [PATCH uq/master] kvm: Drop unused kvm_pit_in_kernel
On 03/21/2012 02:36 PM, Jan Kiszka wrote: > This is now implied by kvm_irqchip_in_kernel. > > So we can't have -no-kvm-pit? No huge loss, but unexpected. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] Thoughts around dtrace linking...
On 21/03/2012 13:01, Andreas Färber wrote: Hi, Am 21.03.2012 11:45, schrieb Lee Essen: I've been trying to find a sensible way to solve the Solaris/Illumos dtrace requirement to pass all the objs to the dtrace command so that the resultant object file contains all the symbols needed to properly link the relevant binary. The two issues I see (as info for Stefan et al.) are a) compiling DTrace probes into .o files requires linking those objects with that additional .o file to avoid linker errors (even for tools where using DTrace probes does not seem to make much sense), b) the additional .o file depends on its input .o files, so must be unique per executable. This seems to be guaranteed when doing it at rules.mak level. Haven't checked all the variables being passed back and forth here yet though; I really am not comfortable reviewing code that's HTML-formatted in my mailer. ;) Sorry ... I've been jumping between machines and I'd thought I'd switched them all to plaintext, but obviously not. Hopefully this is done now. New version below ... How compatible is this with FreeBSD - it doesn't sound like it's needed at all? Don't know about FreeBSD but on Darwin that step is indeed not needed or supported, so needs to be guarded. Andreas Ok, so perhaps the easiest way to guard would be a new variable that matches both a backend of dtrace and OS of Solaris established via configure, for the moment I've just put a backend check, but clearly this wouldn't be enough. LINK = $(call quiet-command,$(CC) $(QEMU_CFLAGS) $(CFLAGS) $(LDFLAGS) -o $@ $(sort $(1)) $(LIBS)," LINK $(TARGET_DIR)$@") DTRACE = $(call quiet-command,dtrace $(CONFIG_DTRACE_FLAGS) -o $(1)-dtrace.o -G -s $(2) $(3), " GEN $(TARGET_DIR)$(1)-dtrace.o") %$(EXESUF): %.o ifeq ($(TRACE_BACKEND),dtrace) $(call DTRACE,$*,trace-dtrace.dtrace,$^) $(call LINK,$^ $*-dtrace.o) else $(call LINK,$^) endif If you're happy that this is a sensible approach I'll put together a proper patch. Regards, Lee.
Re: [Qemu-devel] [PATCH uq/master] kvm: Drop unused kvm_pit_in_kernel
On 2012-03-21 14:36, Avi Kivity wrote: > On 03/21/2012 02:36 PM, Jan Kiszka wrote: >> This is now implied by kvm_irqchip_in_kernel. >> >> > > So we can't have -no-kvm-pit? > > No huge loss, but unexpected. See e81dda195556e72f8cd294998296c1051aab30a8. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
Re: [Qemu-devel] Can VMX provide real mode support?
On 2012-03-21 13:38, GaoYi wrote: > Hi Jan, > > Since the newest Intel-VT supports the guest OS under the real mode, > which was already supported in AMD-V, can the VMX in the latest KVM support > that case? Yes, both with our without that "unrestricted guest" support (as Intel called it), real mode will generally work. Without that CPU feature, I think to recall that there were some limitations for big real mode, not sure. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
Re: [Qemu-devel] [PATCH uq/master] kvm: Drop unused kvm_pit_in_kernel
On Wed, Mar 21, 2012 at 02:39:47PM +0100, Jan Kiszka wrote: > On 2012-03-21 14:36, Avi Kivity wrote: > > On 03/21/2012 02:36 PM, Jan Kiszka wrote: > >> This is now implied by kvm_irqchip_in_kernel. > >> > >> > > > > So we can't have -no-kvm-pit? > > > > No huge loss, but unexpected. > > See e81dda195556e72f8cd294998296c1051aab30a8. > I am curious what is the reason for upstream to not supporting disabling the in-kernel PIT separately? -- Gleb.
Re: [Qemu-devel] Can VMX provide real mode support?
On 03/21/2012 03:40 PM, Jan Kiszka wrote: > On 2012-03-21 13:38, GaoYi wrote: > > Hi Jan, > > > > Since the newest Intel-VT supports the guest OS under the real mode, > > which was already supported in AMD-V, can the VMX in the latest KVM support > > that case? > > Yes, both with our without that "unrestricted guest" support (as Intel > called it), real mode will generally work. Without that CPU feature, I > think to recall that there were some limitations for big real mode, not > sure. > Yes, big real mode will not work without "unrestricted guest". There was some work to emulate it (module option emulate_invalid_guest_state), but it is not complete. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [PATCH uq/master] kvm: Drop unused kvm_pit_in_kernel
On 2012-03-21 14:41, Gleb Natapov wrote: > On Wed, Mar 21, 2012 at 02:39:47PM +0100, Jan Kiszka wrote: >> On 2012-03-21 14:36, Avi Kivity wrote: >>> On 03/21/2012 02:36 PM, Jan Kiszka wrote: This is now implied by kvm_irqchip_in_kernel. >>> >>> So we can't have -no-kvm-pit? >>> >>> No huge loss, but unexpected. >> >> See e81dda195556e72f8cd294998296c1051aab30a8. >> > I am curious what is the reason for upstream to not supporting disabling the > in-kernel PIT separately? It was considered no longer relevant: http://thread.gmane.org/gmane.comp.emulators.kvm.devel/85393 Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
Re: [Qemu-devel] [PATCH 10/12] trace: [tracetool] Automatically establish available backends and formats
Stefan Hajnoczi writes:
[...]
>> Maybe this would work nice for everybody:
>>
>> tracetool.py # main program (just parse cmdline opts and
>> call tracetool module)
>> tracetool/__init__.py # common boilerplate code (e.g., event parsing
>> and call dispatching)
>> tracetool/format/__init__.py # format auto-registration/lookup code
>> tracetool/format/h.py # code for the 'h' format
>> # __doc__ [mandatory, format
>> description]
>> # def begin(events) [optional]
>> # def end(events) [optional]
>> tracetool/backend/__init__.py # backend auto-registration/lookup code
>> tracetool/backend/simple.py # code for the 'simple' backend
>> # __doc__ [mandatory, backend
>> description]
>> # PUBLIC = [True|False] [optional,
>> # defaults to False,
>> # indicates it's listed
>> on --list-backends]
>> # def format(events) [optional,
>> # backend-specific code for
>> given format,
>> # implicitly indicates
>> format compatibility]
> Let's call this function backend.generate(events) instead of "format"
> since we already use that term and it's a Python builtin too. This is
> a code generation function.
Maybe I wasn't clear. I meant that for tracetool/backend/simple.py to work with
the format 'h', it must have the following routine:
def h (events):
...
That is, there must exist a routine with the same name of the format (with '-'
replaced with '_', when necessary) for the backend to be compatible with that
format.
>> Note that new formats will need to add new format routines in
>> 'tracetool/backend/nop.py' to accomodate whatever action has to be taken on
>> disabled events.
> I think it's more convenient to drop the nop backend and introduce a
> nop() code generation function for each format.
> The .h format would nop() function would emit a static inline empty C
> function that does nothing.
> The other formats could probably do nothing in nop().
Sounds good:
tracetool/format/f.py:
def begin (events):
...
def nop (events):
...
def end (events):
...
tracetool/__init__.py:
def generate (events, format, backend, force_nop = False):
if force_nop:
events = [ e.properties.add("disabled") for e in events ]
tracetool.format.begin(events)
tracetool.backend..(non-disabled events events)
tracetool.format..nop(disabled events events)
tracetool.format.end(events)
>>> As the next step with this patch series we could drop this patch. It
>>> doesn't make an external difference. Then we can continue to discuss
>>> how to best handle backends as a separate patch.
>>
>> WDYT of the organization above? Given the current code it's pretty simple to
>> split it into different modules. If everybody agrees on the above, I can
>> make it
>> happen.
> I like the organization you have proposed.
> In order to avoid rebasing and porting too many fixes from tracetool
> to tracetool.py I suggest you resend this series without the
> format/backend consolidation code. I can merge this series quickly
> and we can handle the format/backend consolidation code in a separate
> patch series.
Sure, I'll try to do it later today or tomorrow otherwise.
Lluis
--
"And it's much the same thing with knowledge, for whenever you learn
something new, the whole world becomes that much richer."
-- The Princess of Pure Reason, as told by Norton Juster in The Phantom
Tollbooth
Re: [Qemu-devel] [PATCH V2 2/3] exynos4210: add exynos4210 GPIO implementation
On 03/20/2012 05:27 PM, Peter Maydell wrote:
On 15 March 2012 07:35, Igor Mitsyanko wrote:
Now that we have GPIO emulation for exynos4210 SoC we can use it to
properly hook up IRQ line to lan9215 controller on SMDK board.
+#elif EXYNOS4210_GPIO_DEBUG == 1
+#define DPRINT_L1(fmt, args...) \
+do {fprintf(stderr, "QEMU GPIO: "fmt, ## args); } while (0)
Space after the closing quote in these macros (this patch and
others), please.
+
+DPRINT_L1("Input pin GPIO%s_PIN%u %s by external device\n",
+g->ports[group_num].name, pin, (level ? "set" : "cleared"));
+/* Set new value on corresponding gpio pin */
+(level) ? (g->ports[group_num].dat |= (1<< pin)) :
+(g->ports[group_num].dat&= ~(1<< pin));
Don't use ?: like this please, just write it out as an if statement.
OK
+static void exynos4_gpio_write(void *opaque, target_phys_addr_t off,
+ uint64_t value, unsigned size)
+{
I find these read and write functions quite hard to read. I'm
wondering if it would work better to split them up into smaller
memory regions which get registered at the right addresses, rather
than effectively doing the decode into different subsections based
on address and g->part here?
Initially I implemented these functions splitted like you suggest, but
that left me with three basically identical long switch statements, so I
decided to combine them into one to achieve better code reuse. If you
think code reuse is not an issue here, I'll gladly return it back to
splitted implementation.
+Exynos4GpioState *g = (Exynos4GpioState *)opaque;
+unsigned int port_end, extint_con_start, extint_con_end;
+unsigned int extint_flt_start, extint_flt_end;
+unsigned int extint_mask_start, extint_mask_end;
+unsigned int extint_pend_start, extint_pend_end;
+unsigned int etcp_start_addr, etcp_start_idx, extint_pri_end;
+unsigned idx;
+
+DPRINT_L2("GPIO%u write off 0x%x = %u(0x%x)\n", g->part,
+(uint32_t)off, (uint32_t)value, (uint32_t)value);
+
+switch (g->part) {
+case GPIO_PART2X:
+port_end = GPIO2_XPORT_END;
+extint_con_start = GPIO2_WKPINT_CON_START;
+extint_con_end = GPIO2_WKPINT_CON_END;
+extint_flt_start = GPIO2_WKPINT_FLT_START;
+extint_flt_end = GPIO2_WKPINT_FLT_END;
+extint_mask_start = GPIO2_WKPINT_MASK_START;
+extint_mask_end = GPIO2_WKPINT_MASK_END;
+extint_pend_start = GPIO2_WKPINT_PEND_START;
+extint_pend_end = GPIO2_WKPINT_PEND_END;
+etcp_start_addr = etcp_start_idx = extint_pri_end = 0;
+break;
+case GPIO_PART1: default:
+port_end = GPIO_NORM_PORT_END;
+extint_con_start = GPIO_EXTINT_CON_START;
+extint_con_end = GPIO1_EXTINT_CON_END;
+extint_flt_start = GPIO_EXTINT_FLT_START;
+extint_flt_end = GPIO1_EXTINT_FLT_END;
+extint_mask_start = GPIO_EXTINT_MASK_START;
+extint_mask_end = GPIO1_EXTINT_MASK_END;
+extint_pend_start = GPIO_EXTINT_PEND_START;
+extint_pend_end = GPIO1_EXTINT_PEND_END;
+etcp_start_addr = GPIO1_ETCPORT_START;
+etcp_start_idx = GPIO1_NORM_PORT_NUM;
+extint_pri_end = GPIO1_EXTINT_FIXPRI_END;
+break;
+case GPIO_PART2:
+port_end = GPIO_NORM_PORT_END;
+extint_con_start = GPIO_EXTINT_CON_START;
+extint_con_end = GPIO2_EXTINT_CON_END;
+extint_flt_start = GPIO_EXTINT_FLT_START;
+extint_flt_end = GPIO2_EXTINT_FLT_END;
+extint_mask_start = GPIO_EXTINT_MASK_START;
+extint_mask_end = GPIO2_EXTINT_MASK_END;
+extint_pend_start = GPIO_EXTINT_PEND_START;
+extint_pend_end = GPIO2_EXTINT_PEND_END;
+etcp_start_addr = GPIO2_ETCPORT_START;
+etcp_start_idx = GPIO2_NORM_PORT_NUM;
+extint_pri_end = GPIO2_EXTINT_FIXPRI_END;
+break;
+case GPIO_PART3:
+if (off< GPIO3_NORM_PORT_END) {
+idx = DIV_BY_PORTGR_SIZE(off);
+exynos4_gpio_portgr_write(g, idx, MOD_PORTGR_SIZE(off), value);
+} else {
+DPRINT_ERROR("GPIO3 bad write off 0x%x = %u(0x%x)\n",
+(uint32_t)off, (uint32_t)value, (uint32_t)value);
+}
+return;
+}
+
+if (off< port_end) {
+idx = DIV_BY_PORTGR_SIZE(off);
+exynos4_gpio_portgr_write(g, idx, MOD_PORTGR_SIZE(off), value);
+} else if (off>= extint_mask_start&& off< extint_mask_end) {
+idx = (off - extint_mask_start)>> 2;
+DPRINT_L1("GPIO%u EXTINT%u_MASK register write = %u(0x%x)\n", g->part,
+g->port_ints[idx].int_line_num, (uint32_t)value, (uint32_t)value);
+g->port_ints[idx].mask = value;
+} else if (off>= extint_pend_start&& off< extint_pend_end) {
+idx = (off - extint_pend_start)>> 2;
+DPRINT_L1("GPIO%u EXTINT%u_PEND register write = %u(0x%x)\n", g->part,
+g->port_ints[idx].int_line_num, (uint32_t)value,
[Qemu-devel] Can VMX provide real mode support?
Hi Jan, Since the newest Intel-VT supports the guest OS under the real mode, which was already supported in AMD-V, can the VMX in the latest KVM support that case? Thanks, Yi
Re: [Qemu-devel] [PATCH V2 1/3] exynos4210: add Exynos4210 i2c implementation
On 03/21/2012 03:55 PM, Peter Maydell wrote: On 15 March 2012 07:35, Igor Mitsyanko wrote: Create 9 exynos4210 i2c interfaces. Signed-off-by: Igor Mitsyanko Mostly this looks OK but I still find the i2c slave stuff odd -- should the controller really register itself as a slave on its own bus? Doesn't this mean that the controller can effectively try to talk to itself? Does the hardware let you do that? Controller's master and slave i2c interfaces operate on the same single bus, so I think it should. It can't talk to itself because controller's two modes of operation are mutually exclusive. As I said, I took this approach from pxa i2c implementation, the only difference is that they register slave interface on a separate bus, but I think it's not right to do that. I suspect that what's happening here is that the hardware lets you put the i2c controller into slave mode so some other device on the bus can be a master. But QEMU's i2c bus abstraction doesn't cover that use case at all... Yes, I saw this statement in hw/i2c.h (and probably cpu i2c controller will never be used as i2c slave device by anyone), but I think we still have to implement devices exactly like they described in documentation. -- Mitsyanko Igor ASWG, Moscow R&D center, Samsung Electronics email: i.mitsya...@samsung.com
Re: [Qemu-devel] [PATCH V2 1/3] exynos4210: add Exynos4210 i2c implementation
On 03/21/2012 05:09 PM, Peter Maydell wrote: On 21 March 2012 13:07, Igor Mitsyanko wrote: On 03/21/2012 03:55 PM, Peter Maydell wrote: I suspect that what's happening here is that the hardware lets you put the i2c controller into slave mode so some other device on the bus can be a master. But QEMU's i2c bus abstraction doesn't cover that use case at all... Yes, I saw this statement in hw/i2c.h (and probably cpu i2c controller will never be used as i2c slave device by anyone), but I think we still have to implement devices exactly like they described in documentation. I agree with the sentiment, I'm just not sure if the code you've written is actually doing that. The right way to model this would be if our i2c bus implementation provided an interface so you could register as a device which is a master but can switch into slave mode. I don't think we can do that without multiple inheritance, and it wouldn't worth an effort for a feature that never going to be used. Failing that, maybe we should just not support switching into slave mode at all. Do you mean we shouldn't register EXYNOS4_I2C_SLAVE at all so some hypothetical bus master wouldn't even find EXYNOS4_I2C_SLAVE on a bus? Maybe the best solution is to make exynos4210_i2c_slave_send() and exynos4210_i2c_slave_recv() always return -1, so a hypothetical bus master will treat EXYNOS4_I2C_SLAVE as a broken device. But that seems to behave exactly like "not register at all" approach.. And are we really sure that slave interface wouldn't work correctly in a current implementation? For example, emulated Exynos CPU issues some command to a device A on SPI line and device A in turn issues data on i2c line connected to Exynos i2c controller configured as slave. EXYNOS4_I2C_SLAVE receives a data and raises interrupt flag. Registering as two separate devices on the i2c bus doesn't sound right to me. Why? That's how it's done in hardware, I think we can roughly consider it to be two separate devices multiplexing single bus. -- Mitsyanko Igor ASWG, Moscow R&D center, Samsung Electronics email: i.mitsya...@samsung.com
Re: [Qemu-devel] [PATCH V2 1/3] exynos4210: add Exynos4210 i2c implementation
On 21 March 2012 14:18, Igor Mitsyanko wrote: > Do you mean we shouldn't register EXYNOS4_I2C_SLAVE at all so some > hypothetical bus master wouldn't even find EXYNOS4_I2C_SLAVE on a bus? > Maybe the best solution is to make exynos4210_i2c_slave_send() and > exynos4210_i2c_slave_recv() always return -1, so a hypothetical bus master > will treat EXYNOS4_I2C_SLAVE as a broken device. But that seems to behave > exactly like "not register at all" approach.. > And are we really sure that slave interface wouldn't work correctly in a > current implementation? For example, emulated Exynos CPU issues some command > to a device A on SPI line and device A in turn issues data on i2c line > connected to Exynos i2c controller configured as slave. EXYNOS4_I2C_SLAVE > receives a data and raises interrupt flag. If there's a valid configuration that works in the existing code where we can end up receiving data correctly to the EXYNOS4_I2C_SLAVE from some other device on the i2c bus, that's fine: we can test that the code you have works OK. If there is no valid configuration that will do that (because we don't have any support for any other device being a bus master) then the code is completely useless, untested and untestable and we shouldn't put it in. -- PMM
[Qemu-devel] Can VMX support real mode?
Hi Avi, According to your reply if the CPU supports the real mode, the KVM can support the real mode guest and there is still work to be done for CPU without real mode support (i.e., software emulation)? Thanks again, Yi
Re: [Qemu-devel] [PATCH 3/3] configure: add --confsuffix option
On Wed, Mar 21, 2012 at 01:39:39PM +0100, Paolo Bonzini wrote:
> Il 20/03/2012 21:15, Eduardo Habkost ha scritto:
> > This way we can choose a configuration file path different from
> > ${sysconfdir}/PACKAGE.
> >
> > This also changes the configure output to show the full configuration
> > dir path (including $confsuffix), instead of just $sysconfdir.
>
> Can you please apply this to datadir too? (i.e. set the datadir default
> to just $prefix/share, and later add $confsuffix).
I will do it, and send v3 of the series.
I guess we don't want to change the meaning of
'./configure --datadir=PATH' (that currently expects the full path), to
keep compatibility, right?
To make sure the expected semantics are clear:
This is straightforward:
./configure
qemu data dir: /usr/share/qemu
qemu conf dir: /etc/qemu
For this one, we would have compatibility issues to take care of:
./configure --datadir=FOO --sysconfdir=SYS
qemu data dir: FOO
(it would be better if it was FOO/qemu, but needed for compatibility)
qemu conf dir: SYS/qemu
On the following cases, I don't know what would be the best behavior:
./configure --datadir=FOO --confsuffix=/BAR
qemu data dir: FOO/BAR
(maybe it should be just FOO, to keep the rules easier to understand?)
qemu conf dir: /etc/BAR
./configure --datadir=FOO --confsuffix=/BAR --sysconfdir=SYS
qemu data dir: FOO/BAR
(maybe it should be just FOO, to keep the rules easier to understand?)
qemu conf dir: SYS/BAR
--
Eduardo
Re: [Qemu-devel] [PATCH] Remove PCI class code from virtio balloon device
On 03/21/2012 08:08 AM, Michael S. Tsirkin wrote:
On Wed, Mar 21, 2012 at 11:26:15AM +, Stefan Hajnoczi wrote:
On Tue, Mar 20, 2012 at 09:19:47PM +1100, David Gibson wrote:
Looking at hw/pc_piix.c there are QEMUMachine types for each QEMU
release. Legacy machine types (e.g. pc_machine_v0_14) have a
.compat_props array that can override qdev properties.
Perhaps Michael Tsirkin or someone else can comment on how to wire up
hw/virtio-pci.c so that the class code can be overridden.
Stefan
afaik we already let users over-write it for some other pci devices,
look there for examples.
From hw/pc_piix.c:
.name = "pc-0.10",
.desc = "Standard PC, qemu 0.10",
.init = pc_init_pci_no_kvmclock,
.max_cpus = 255,
.compat_props = (GlobalProperty[]) {
{
.driver = "virtio-blk-pci",
.property = "class",
.value= stringify(PCI_CLASS_STORAGE_OTHER),
},{
And from the earlier part of the thread, yes, it's imperative that we do not
change anything in the PCI configuration space for older pc versions regardless
of whether it may or may not work.
Certain guests (like Windows) use a complex fingerprinting algorithm to
determine when hardware changes. It can be hard to detect in simple testing
because it's based on a threshold.
Regards,
Anthony Liguori
Re: [Qemu-devel] Can VMX provide real mode support?
Hi, Thanks for your prompt response. So if the CPU supports the real mode, the KVM can support the real mode guest and there is still work to be done for CPU without real mode support, namely software emulation? Again 在 2012年3月21日 下午9:48，Avi Kivity 写道： > On 03/21/2012 03:40 PM, Jan Kiszka wrote: > > On 2012-03-21 13:38, GaoYi wrote: > > > Hi Jan, > > > > > > Since the newest Intel-VT supports the guest OS under the real > mode, which was already supported in AMD-V, can the VMX in the latest KVM > support that case? > > > > Yes, both with our without that "unrestricted guest" support (as Intel > > called it), real mode will generally work. Without that CPU feature, I > > think to recall that there were some limitations for big real mode, not > > sure. > > > > Yes, big real mode will not work without "unrestricted guest". There > was some work to emulate it (module option emulate_invalid_guest_state), > but it is not complete. > > -- > error compiling committee.c: too many arguments to function > >
Re: [Qemu-devel] [PATCH 1/3] test: remove qemu-ga reference
On Wed, Mar 21, 2012 at 11:37:10AM +, Stefan Hajnoczi wrote: > On Tue, Mar 20, 2012 at 12:18 AM, Michael Roth > wrote: > > This was added by mistake a while back. > > > > Signed-off-by: Michael Roth > > --- > > tests/Makefile | 2 +- > > 1 files changed, 1 insertions(+), 1 deletions(-) > > After applying your series and rebuilding, I get the following error. > I checked that there are no auto-generated files left around after > make distclean. Shoot, sorry, I must've only tested make check after the change. It looks like qemu-ga target is relying on that dependency being sourced from tests/Makefile. I'll send an updated 1/3 that moves it to top-level Makefile where it should be. > > $ make distclean > $ ./configure --target-list=x86_64-softmmu --disable-werror > $ make > GEN x86_64-softmmu/config-devices.mak > GEN config-all-devices.mak > GEN qemu-options.texi > GEN qemu-monitor.texi > GEN qemu-img-cmds.texi > GEN qemu-doc.html > GEN qemu-tech.html > GEN qemu.1 > GEN qemu-img.1 > GEN qemu-nbd.8 > GEN QMP/qmp-commands.txt > GEN config-host.h > GEN trace.h > GEN qemu-options.def > GEN qmp-commands.h > GEN qapi-types.h > GEN qapi-visit.h > GEN /home/stefanha/qemu/qapi-generated/qga-qapi-types.h > GEN /home/stefanha/qemu/qapi-generated/qga-qapi-visit.h > GEN /home/stefanha/qemu/qapi-generated/qga-qmp-commands.h > CCqemu-ga.o > CCqga/commands.o > qga/commands.c:15:30: fatal error: qga-qmp-commands.h: No such file or > directory > compilation terminated. > make: *** [qga/commands.o] Error 1 >
Re: [Qemu-devel] [PATCH] Remove PCI class code from virtio balloon device
On Wed, Mar 21, 2012 at 09:42:41AM -0500, Anthony Liguori wrote:
> On 03/21/2012 08:08 AM, Michael S. Tsirkin wrote:
> >On Wed, Mar 21, 2012 at 11:26:15AM +, Stefan Hajnoczi wrote:
> >>On Tue, Mar 20, 2012 at 09:19:47PM +1100, David Gibson wrote:
> >>Looking at hw/pc_piix.c there are QEMUMachine types for each QEMU
> >>release. Legacy machine types (e.g. pc_machine_v0_14) have a
> >>.compat_props array that can override qdev properties.
> >>
> >>Perhaps Michael Tsirkin or someone else can comment on how to wire up
> >>hw/virtio-pci.c so that the class code can be overridden.
> >>
> >>Stefan
> >
> >afaik we already let users over-write it for some other pci devices,
> >look there for examples.
>
> From hw/pc_piix.c:
>
> .name = "pc-0.10",
> .desc = "Standard PC, qemu 0.10",
> .init = pc_init_pci_no_kvmclock,
> .max_cpus = 255,
> .compat_props = (GlobalProperty[]) {
> {
> .driver = "virtio-blk-pci",
> .property = "class",
> .value= stringify(PCI_CLASS_STORAGE_OTHER),
> },{
>
> And from the earlier part of the thread, yes, it's imperative that
> we do not change anything in the PCI configuration space for older
> pc versions regardless of whether it may or may not work.
>
> Certain guests (like Windows) use a complex fingerprinting algorithm
> to determine when hardware changes. It can be hard to detect in
> simple testing because it's based on a threshold.
>
> Regards,
>
> Anthony Liguori
Which reminds me - qemu sticks the release version in
guest visible places like CPU version.
This is wrong and causes windows guests to print messages
about driver updates when you switch.
We should find all these places and stop doing this.
> >
> >
[Qemu-devel] [PATCH v2] test: remove qemu-ga reference
This was added by mistake a while back. Signed-off-by: Michael Roth --- Makefile |1 + tests/Makefile |2 +- 2 files changed, 2 insertions(+), 1 deletions(-) diff --git a/Makefile b/Makefile index 1bc3cb0..cab7c74 100644 --- a/Makefile +++ b/Makefile @@ -173,6 +173,7 @@ qemu-img-cmds.h: $(SRC_PATH)/qemu-img-cmds.hx $(qapi-obj-y): $(GENERATED_HEADERS) qapi-dir := $(BUILD_DIR)/qapi-generated qemu-ga$(EXESUF): LIBS = $(LIBS_QGA) +qemu-ga$(EXESUF): QEMU_CFLAGS += -I $(qapi-dir) gen-out-type = $(subst .,-,$(suffix $@)) diff --git a/tests/Makefile b/tests/Makefile index c78ade1..354fdbb 100644 --- a/tests/Makefile +++ b/tests/Makefile @@ -17,7 +17,7 @@ test-coroutine: test-coroutine.o qemu-timer-common.o async.o $(coroutine-obj-y) test-qmp-input-visitor.o test-qmp-output-visitor.o \ test-string-input-visitor.o test-string-output-visitor.o \ - test-qmp-commands.o qemu-ga$(EXESUF): QEMU_CFLAGS += -I $(qapi-dir) + test-qmp-commands.o: QEMU_CFLAGS += -I $(qapi-dir) $(qapi-dir)/test-qapi-types.c $(qapi-dir)/test-qapi-types.h :\ $(SRC_PATH)/qapi-schema-test.json $(SRC_PATH)/scripts/qapi-types.py -- 1.7.4.1
Re: [Qemu-devel] [PATCH 0/2] linux-user: Support prctl PR_GET/SET_NAME
Hi, looks like I'll be busy for the rest of the of the month :/ Riku On Tue, Mar 20, 2012 at 11:47:01AM +, Peter Maydell wrote: > Ping^3 (past the six-week mark now...) > > -- PMM > > On 8 March 2012 14:20, Peter Maydell wrote: > > Ping^2 ? > > > > -- PMM > > > > On 22 February 2012 22:55, Peter Maydell wrote: > >> Ping? > >> > >> On 3 February 2012 13:53, Peter Maydell wrote: > >>> These patches add support for the prctl options PR_GET_NAME > >>> and PR_SET_NAME. In particular, perl 5.14 will use PR_SET_NAME > >>> if you change the value of $0, which means that adduser will > >>> fail if run under qemu with a sufficiently modern perl. > >>> > >>> Patch one is just indentation cleanup, the meat is patch 2. > >>> > >>> The only other prctl options which take pointer arguments are > >>> all architecture specific, so there didn't seem much point in > >>> adding them (they all work like PR_GET_PDEATHSIG in that they > >>> pass an int* to be filled in); we'd have to actually emulate them > >>> if we cared about them. > >>> > >>> Peter Maydell (2): > >>> linux-user/syscall.c: Fix indentation in prctl handling > >>> linux-user: Add support for prctl PR_GET_NAME and PR_SET_NAME > >>> > >>> linux-user/syscall.c | 53 > >>> - > >>> 1 files changed, 39 insertions(+), 14 deletions(-) > >>> > >>> > >
Re: [Qemu-devel] [PATCH] Remove PCI class code from virtio balloon device
On 03/21/2012 10:10 AM, Michael S. Tsirkin wrote:
On Wed, Mar 21, 2012 at 09:42:41AM -0500, Anthony Liguori wrote:
On 03/21/2012 08:08 AM, Michael S. Tsirkin wrote:
On Wed, Mar 21, 2012 at 11:26:15AM +, Stefan Hajnoczi wrote:
On Tue, Mar 20, 2012 at 09:19:47PM +1100, David Gibson wrote:
Looking at hw/pc_piix.c there are QEMUMachine types for each QEMU
release. Legacy machine types (e.g. pc_machine_v0_14) have a
.compat_props array that can override qdev properties.
Perhaps Michael Tsirkin or someone else can comment on how to wire up
hw/virtio-pci.c so that the class code can be overridden.
Stefan
afaik we already let users over-write it for some other pci devices,
look there for examples.
From hw/pc_piix.c:
.name = "pc-0.10",
.desc = "Standard PC, qemu 0.10",
.init = pc_init_pci_no_kvmclock,
.max_cpus = 255,
.compat_props = (GlobalProperty[]) {
{
.driver = "virtio-blk-pci",
.property = "class",
.value= stringify(PCI_CLASS_STORAGE_OTHER),
},{
And from the earlier part of the thread, yes, it's imperative that
we do not change anything in the PCI configuration space for older
pc versions regardless of whether it may or may not work.
Certain guests (like Windows) use a complex fingerprinting algorithm
to determine when hardware changes. It can be hard to detect in
simple testing because it's based on a threshold.
Regards,
Anthony Liguori
Which reminds me - qemu sticks the release version in
guest visible places like CPU version.
This is wrong and causes windows guests to print messages
about driver updates when you switch.
We should find all these places and stop doing this.
We could probably get away with doing a query/replace of QEMU_VERSION with
qemu_get_version(), make version a static variable that defaults to
QEMU_VERSION, and then provide a way for machines to override it.
Then pc-0.10 could report a version of 0.10.
Regards,
Anthony Liguori
[Qemu-devel] [PATCH V2 1/7] block: Add new BDRV_O_INCOMING flag to notice incoming live migration
>From original patch with Patchwork-id: 31110 by
Stefan Hajnoczi
"Add a flag to indicate that incoming migration is pending and care needs
to be taken for data consistency. Block drivers should not modify the
image file before incoming migration is complete since the migration
source host is still using the image file."
The rationale for not using bdrv->read_only is the following.
"Unfortunately this is not possible because too many other places in QEMU
test bdrv_is_read_only() and use it for their own evil purposes. For
example, ide_init_drive() will error out because read-only harddisks are
not supported. We're mixing guest and host side read-only concepts so
this simpler alternative does not work."
Signed-off-by: Benoit Canet
---
block.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/block.h b/block.h
index 415bb17..b3b18d6 100644
--- a/block.h
+++ b/block.h
@@ -71,6 +71,7 @@ typedef struct BlockDevOps {
#define BDRV_O_NO_BACKING 0x0100 /* don't open the backing file */
#define BDRV_O_NO_FLUSH0x0200 /* disable flushing on this disk */
#define BDRV_O_COPY_ON_READ 0x0400 /* copy read backing sectors into image */
+#define BDRV_O_INCOMING0x0800 /* consistency hint for incoming migration
*/
#define BDRV_O_CACHE_MASK (BDRV_O_NOCACHE | BDRV_O_CACHE_WB | BDRV_O_NO_FLUSH)
--
1.7.7.6
[Qemu-devel] [PATCH V2 2/7] block: add a function to clear incoming live migration flags
This function will clear all BDRV_O_INCOMING flags.
Signed-off-by: Benoit Canet
---
block.c |9 +
block.h |2 ++
2 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/block.c b/block.c
index b88ee90..45085e7 100644
--- a/block.c
+++ b/block.c
@@ -3584,6 +3584,15 @@ void bdrv_invalidate_cache_all(void)
}
}
+void bdrv_clear_incoming_migration_all(void)
+{
+BlockDriverState *bs;
+
+QTAILQ_FOREACH(bs, &bdrv_states, list) {
+bs->open_flags = bs->open_flags & ~(BDRV_O_INCOMING);
+}
+}
+
int bdrv_flush(BlockDriverState *bs)
{
Coroutine *co;
diff --git a/block.h b/block.h
index b3b18d6..951b476 100644
--- a/block.h
+++ b/block.h
@@ -223,6 +223,8 @@ BlockDriverAIOCB *bdrv_aio_ioctl(BlockDriverState *bs,
void bdrv_invalidate_cache(BlockDriverState *bs);
void bdrv_invalidate_cache_all(void);
+void bdrv_clear_incoming_migration_all(void);
+
/* Ensure contents are flushed to disk. */
int bdrv_flush(BlockDriverState *bs);
int coroutine_fn bdrv_co_flush(BlockDriverState *bs);
--
1.7.7.6
[Qemu-devel] [PATCH V2 3/7] blockdev: open images with BDRV_O_INCOMING on incoming live migration
Open images with BDRV_O_INCOMING in order to inform block drivers
that an incoming live migration is coming.
Signed-off-by: Benoit Canet
---
blockdev.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/blockdev.c b/blockdev.c
index 1a500b8..9b57133 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -591,6 +591,10 @@ DriveInfo *drive_init(QemuOpts *opts, int default_to_scsi)
bdrv_flags |= BDRV_O_COPY_ON_READ;
}
+if (runstate_check(RUN_STATE_INMIGRATE)) {
+bdrv_flags |= BDRV_O_INCOMING;
+}
+
if (media == MEDIA_CDROM) {
/* CDROM is fine for any interface, don't check. */
ro = 1;
--
1.7.7.6
[Qemu-devel] [PATCH V2 4/7] qed: add bdrv_invalidate_cache to be called after incoming live migration
The QED image is reopened to flush metadata and check consistency.
Signed-off-by: Benoit Canet
---
block/qed.c | 15 +++
block/qed.h |1 +
2 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/block/qed.c b/block/qed.c
index a041d31..c47272c 100644
--- a/block/qed.c
+++ b/block/qed.c
@@ -375,6 +375,10 @@ static int bdrv_qed_open(BlockDriverState *bs, int flags)
int ret;
s->bs = bs;
+
+/* backup flags for bdrv_qed_invalidate_cache */
+s->flags = flags;
+
QSIMPLEQ_INIT(&s->allocating_write_reqs);
ret = bdrv_pread(bs->file, 0, &le_header, sizeof(le_header));
@@ -1516,6 +1520,16 @@ static int bdrv_qed_change_backing_file(BlockDriverState
*bs,
return ret;
}
+static void bdrv_qed_invalidate_cache(BlockDriverState *bs)
+{
+BDRVQEDState *s = bs->opaque;
+int flags = s->flags;
+
+bdrv_qed_close(bs);
+memset(s, 0, sizeof(BDRVQEDState));
+bdrv_qed_open(bs, flags);
+}
+
static int bdrv_qed_check(BlockDriverState *bs, BdrvCheckResult *result)
{
BDRVQEDState *s = bs->opaque;
@@ -1568,6 +1582,7 @@ static BlockDriver bdrv_qed = {
.bdrv_getlength = bdrv_qed_getlength,
.bdrv_get_info= bdrv_qed_get_info,
.bdrv_change_backing_file = bdrv_qed_change_backing_file,
+.bdrv_invalidate_cache= bdrv_qed_invalidate_cache,
.bdrv_check = bdrv_qed_check,
};
diff --git a/block/qed.h b/block/qed.h
index 62624a1..cb1ebd8 100644
--- a/block/qed.h
+++ b/block/qed.h
@@ -153,6 +153,7 @@ typedef struct QEDAIOCB {
typedef struct {
BlockDriverState *bs; /* device */
+int flags; /* open flags */
uint64_t file_size; /* length of image file, in bytes */
QEDHeader header; /* always cpu-endian */
--
1.7.7.6
[Qemu-devel] [PATCH V2 7/7] qed: remove incoming live migration blocker
Signed-off-by: Benoit Canet
---
block/qed.c |9 -
block/qed.h |2 --
2 files changed, 0 insertions(+), 11 deletions(-)
diff --git a/block/qed.c b/block/qed.c
index 4c04bc9..803a6c2 100644
--- a/block/qed.c
+++ b/block/qed.c
@@ -502,12 +502,6 @@ static int bdrv_qed_open(BlockDriverState *bs, int flags)
s->need_check_timer = qemu_new_timer_ns(vm_clock,
qed_need_check_timer_cb, s);
-error_set(&s->migration_blocker,
- QERR_BLOCK_FORMAT_FEATURE_NOT_SUPPORTED,
- "qed", bs->device_name, "live migration");
-migrate_add_blocker(s->migration_blocker);
-
-
out:
if (ret) {
qed_free_l2_cache(&s->l2_cache);
@@ -520,9 +514,6 @@ static void bdrv_qed_close(BlockDriverState *bs)
{
BDRVQEDState *s = bs->opaque;
-migrate_del_blocker(s->migration_blocker);
-error_free(s->migration_blocker);
-
qed_cancel_need_check_timer(s);
qemu_free_timer(s->need_check_timer);
diff --git a/block/qed.h b/block/qed.h
index cb1ebd8..9fac300 100644
--- a/block/qed.h
+++ b/block/qed.h
@@ -170,8 +170,6 @@ typedef struct {
/* Periodic flush and clear need check flag */
QEMUTimer *need_check_timer;
-
-Error *migration_blocker;
} BDRVQEDState;
enum {
--
1.7.7.6
[Qemu-devel] [PATCH v3 2/2] Change timedrift default value to slew
Windows 2008+ is very sensitive to missed ticks. The RTC is used by default as
the time source. If time drift is not enabled, Windows is prone to
blue screening.
Signed-off-by: Crístian Viana
---
hw/mc146818rtc.c |2 +-
vl.c | 10 +-
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/hw/mc146818rtc.c b/hw/mc146818rtc.c
index 2b59c36..2b31587 100644
--- a/hw/mc146818rtc.c
+++ b/hw/mc146818rtc.c
@@ -726,7 +726,7 @@ ISADevice *rtc_init(ISABus *bus, int base_year, qemu_irq
intercept_irq)
static Property mc146818rtc_properties[] = {
DEFINE_PROP_INT32("base_year", RTCState, base_year, 1980),
DEFINE_PROP_LOSTTICKPOLICY("lost_tick_policy", RTCState,
- lost_tick_policy, LOST_TICK_DISCARD),
+ lost_tick_policy, LOST_TICK_SLEW),
DEFINE_PROP_END_OF_LIST(),
};
diff --git a/vl.c b/vl.c
index 112b0e0..11817e5 100644
--- a/vl.c
+++ b/vl.c
@@ -539,18 +539,18 @@ static void configure_rtc(QemuOpts *opts)
value = qemu_opt_get(opts, "driftfix");
if (value) {
if (!strcmp(value, "slew")) {
-static GlobalProperty slew_lost_ticks[] = {
+/* slew is default */
+} else if (!strcmp(value, "none")) {
+static GlobalProperty discard_lost_ticks[] = {
{
.driver = "mc146818rtc",
.property = "lost_tick_policy",
-.value= "slew",
+.value= "discard",
},
{ /* end of list */ }
};
-qdev_prop_register_global_list(slew_lost_ticks);
-} else if (!strcmp(value, "none")) {
-/* discard is default */
+qdev_prop_register_global_list(discard_lost_ticks);
} else {
fprintf(stderr, "qemu: invalid option value '%s'\n", value);
exit(1);
--
1.7.8.5
[Qemu-devel] [PATCH v3 1/2] Force timedrift=none on previous machines
The current value for the -rtc timedrift option is none. This patch
makes sure that the old machines configuration will work the same way
even after that option changes its default value.
Signed-off-by: Crístian Viana
---
hw/pc_piix.c | 39 +++
1 files changed, 39 insertions(+), 0 deletions(-)
diff --git a/hw/pc_piix.c b/hw/pc_piix.c
index 3f99f9a..08255b5 100644
--- a/hw/pc_piix.c
+++ b/hw/pc_piix.c
@@ -386,6 +386,10 @@ static QEMUMachine pc_machine_v1_0 = {
.driver = "isa-fdc",
.property = "check_media_rate",
.value= "off",
+}, {
+.driver = "mc146818rtc",
+.property = "lost_tick_policy",
+.value= "none",
},
{ /* end of list */ }
},
@@ -405,6 +409,10 @@ static QEMUMachine pc_machine_v0_15 = {
.driver = "isa-fdc",
.property = "check_media_rate",
.value= "off",
+}, {
+.driver = "mc146818rtc",
+.property = "lost_tick_policy",
+.value= "none",
},
{ /* end of list */ }
},
@@ -449,6 +457,10 @@ static QEMUMachine pc_machine_v0_14 = {
.driver = "pc-sysfw",
.property = "rom_only",
.value= stringify(1),
+}, {
+.driver = "mc146818rtc",
+.property = "lost_tick_policy",
+.value= "none",
},
{ /* end of list */ }
},
@@ -505,6 +517,10 @@ static QEMUMachine pc_machine_v0_13 = {
.driver = "pc-sysfw",
.property = "rom_only",
.value= stringify(1),
+}, {
+.driver = "mc146818rtc",
+.property = "lost_tick_policy",
+.value= "none",
},
{ /* end of list */ }
},
@@ -565,6 +581,10 @@ static QEMUMachine pc_machine_v0_12 = {
.driver = "pc-sysfw",
.property = "rom_only",
.value= stringify(1),
+}, {
+.driver = "mc146818rtc",
+.property = "lost_tick_policy",
+.value= "none",
},
{ /* end of list */ }
}
@@ -633,6 +653,10 @@ static QEMUMachine pc_machine_v0_11 = {
.driver = "pc-sysfw",
.property = "rom_only",
.value= stringify(1),
+}, {
+.driver = "mc146818rtc",
+.property = "lost_tick_policy",
+.value= "none",
},
{ /* end of list */ }
}
@@ -713,6 +737,10 @@ static QEMUMachine pc_machine_v0_10 = {
.driver = "pc-sysfw",
.property = "rom_only",
.value= stringify(1),
+}, {
+.driver = "mc146818rtc",
+.property = "lost_tick_policy",
+.value= "none",
},
{ /* end of list */ }
},
@@ -728,6 +756,10 @@ static QEMUMachine isapc_machine = {
.driver = "pc-sysfw",
.property = "rom_only",
.value= stringify(1),
+}, {
+.driver = "mc146818rtc",
+.property = "lost_tick_policy",
+.value= "none",
},
{ /* end of list */ }
},
@@ -740,6 +772,13 @@ static QEMUMachine xenfv_machine = {
.init = pc_xen_hvm_init,
.max_cpus = HVM_MAX_VCPUS,
.default_machine_opts = "accel=xen",
+.compat_props = (GlobalProperty[]) {
+{
+.driver = "mc146818rtc",
+.property = "lost_tick_policy",
+.value= "none",
+},
+{ /* end of list */ }
};
#endif
--
1.7.8.5
[Qemu-devel] [PATCH V2 6/7] qed: honor BDRV_O_INCOMING for incoming live migration
>From original commit with Patchwork-id: 31108 by
Stefan Hajnoczi
"The QED image format includes a file header bit to mark images dirty.
QED normally checks dirty images on open and fixes inconsistent
metadata. This is undesirable during live migration since the dirty bit
may be set if the source host is modifying the image file. The check
should be postponed until migration completes.
Skip operations that modify the image file if the BDRV_O_INCOMING flag
is set."
Signed-off-by: Benoit Canet
---
block/qed.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/block/qed.c b/block/qed.c
index c47272c..4c04bc9 100644
--- a/block/qed.c
+++ b/block/qed.c
@@ -454,7 +454,7 @@ static int bdrv_qed_open(BlockDriverState *bs, int flags)
* feature is no longer valid.
*/
if ((s->header.autoclear_features & ~QED_AUTOCLEAR_FEATURE_MASK) != 0 &&
-!bdrv_is_read_only(bs->file)) {
+!bdrv_is_read_only(bs->file) && !(bs->open_flags & BDRV_O_INCOMING)) {
s->header.autoclear_features &= QED_AUTOCLEAR_FEATURE_MASK;
ret = qed_write_header_sync(s);
@@ -481,7 +481,8 @@ static int bdrv_qed_open(BlockDriverState *bs, int flags)
* potentially inconsistent images to be opened read-only. This can
* aid data recovery from an otherwise inconsistent image.
*/
-if (!bdrv_is_read_only(bs->file)) {
+if (!bdrv_is_read_only(bs->file) &&
+!(bs->open_flags & BDRV_O_INCOMING)) {
BdrvCheckResult result = {0};
ret = qed_check(s, &result, true);
--
1.7.7.6
[Qemu-devel] [PATCH V2 0/7] Make QED with live migration safe
This is the second version of a patchset aiming at making the combined usage of QED and live migration safe. Since v1: -The block layer is not aware anymore of the migration state. (stefanha) -No bdrv_invalidate_cache renaming since the semantic do not change. (stefanha) -The qed bdrv_invalidate_cache function does a reopening of the image to flush metadata and to do the image integrity check. (stefanha) note: In "qed: honor BDRV_O_INCOMING for incoming live migration" I choose to honor bs->open_flags and not s->flags in order to keep the bdrv_qed_invalidate_cache function intact of any migration related operation. This way bdrv_qed_invalidate_cache semantic is not changed. Benoît Canet (7): block: Add new BDRV_O_INCOMING flag to notice incoming live migration block: add a function to clear incoming live migration flags blockdev: open images with BDRV_O_INCOMING on incoming live migration qed: add bdrv_invalidate_cache to be called after incoming live migration migration: clear BDRV_O_INCOMING flags on end of incoming live migration qed: honor BDRV_O_INCOMING for incoming live migration qed: remove incoming live migration blocker block.c |9 + block.h |3 +++ block/qed.c | 29 ++--- block/qed.h |3 +-- blockdev.c |4 migration.c |1 + 6 files changed, 36 insertions(+), 13 deletions(-) -- 1.7.7.6
Re: [Qemu-devel] [PATCH] Remove PCI class code from virtio balloon device
On Wed, Mar 21, 2012 at 10:14:35AM -0500, Anthony Liguori wrote:
> On 03/21/2012 10:10 AM, Michael S. Tsirkin wrote:
> >On Wed, Mar 21, 2012 at 09:42:41AM -0500, Anthony Liguori wrote:
> >>On 03/21/2012 08:08 AM, Michael S. Tsirkin wrote:
> >>>On Wed, Mar 21, 2012 at 11:26:15AM +, Stefan Hajnoczi wrote:
> On Tue, Mar 20, 2012 at 09:19:47PM +1100, David Gibson wrote:
> Looking at hw/pc_piix.c there are QEMUMachine types for each QEMU
> release. Legacy machine types (e.g. pc_machine_v0_14) have a
> .compat_props array that can override qdev properties.
>
> Perhaps Michael Tsirkin or someone else can comment on how to wire up
> hw/virtio-pci.c so that the class code can be overridden.
>
> Stefan
> >>>
> >>>afaik we already let users over-write it for some other pci devices,
> >>>look there for examples.
> >>
> >> From hw/pc_piix.c:
> >>
> >> .name = "pc-0.10",
> >> .desc = "Standard PC, qemu 0.10",
> >> .init = pc_init_pci_no_kvmclock,
> >> .max_cpus = 255,
> >> .compat_props = (GlobalProperty[]) {
> >> {
> >> .driver = "virtio-blk-pci",
> >> .property = "class",
> >> .value= stringify(PCI_CLASS_STORAGE_OTHER),
> >> },{
> >>
> >>And from the earlier part of the thread, yes, it's imperative that
> >>we do not change anything in the PCI configuration space for older
> >>pc versions regardless of whether it may or may not work.
> >>
> >>Certain guests (like Windows) use a complex fingerprinting algorithm
> >>to determine when hardware changes. It can be hard to detect in
> >>simple testing because it's based on a threshold.
> >>
> >>Regards,
> >>
> >>Anthony Liguori
> >
> >Which reminds me - qemu sticks the release version in
> >guest visible places like CPU version.
> >This is wrong and causes windows guests to print messages
> >about driver updates when you switch.
> >We should find all these places and stop doing this.
>
> We could probably get away with doing a query/replace of
> QEMU_VERSION with qemu_get_version(), make version a static variable
> that defaults to QEMU_VERSION, and then provide a way for machines
> to override it.
>
> Then pc-0.10 could report a version of 0.10.
>
> Regards,
>
> Anthony Liguori
Frankly I don't see value in making it visible to the user,
at all. We are just triggering windows reactivations
without any user benefit. Why not return a fixed value there
to avoid that?
> >>>
> >>>
[Qemu-devel] [PATCH] ui/spice-display: use uintptr_t when casting qxl physical addresses
The current intptr_t casts are a problem when the address's highest bit is 1, and it is cast to a intptr_t and then to uint64_t, such as at: surface.mem= (intptr_t)ssd->buf; This causes the sign bit to be extended which causes a wrong address to be passed on to spice, which then complains when it gets the wrong slot_id number, since the slot_id is taken from the higher bits. The assertion happens early - during the first primary surface creation. This fixes running "-vga qxl -spice" with 32 bit compiled qemu-system-i386. Signed-off-by: Alon Levy --- ui/spice-display.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/ui/spice-display.c b/ui/spice-display.c index 35499e2..f5764e9 100644 --- a/ui/spice-display.c +++ b/ui/spice-display.c @@ -158,7 +158,7 @@ static SimpleSpiceUpdate *qemu_spice_create_update(SimpleSpiceDisplay *ssd) drawable->bbox= ssd->dirty; drawable->clip.type = SPICE_CLIP_TYPE_NONE; drawable->effect = QXL_EFFECT_OPAQUE; -drawable->release_info.id = (intptr_t)update; +drawable->release_info.id = (uintptr_t)update; drawable->type= QXL_DRAW_COPY; drawable->surfaces_dest[0] = -1; drawable->surfaces_dest[1] = -1; @@ -169,7 +169,7 @@ static SimpleSpiceUpdate *qemu_spice_create_update(SimpleSpiceDisplay *ssd) + time_space.tv_nsec / 1000 / 1000; drawable->u.copy.rop_descriptor = SPICE_ROPD_OP_PUT; -drawable->u.copy.src_bitmap = (intptr_t)image; +drawable->u.copy.src_bitmap = (uintptr_t)image; drawable->u.copy.src_area.right = bw; drawable->u.copy.src_area.bottom = bh; @@ -179,7 +179,7 @@ static SimpleSpiceUpdate *qemu_spice_create_update(SimpleSpiceDisplay *ssd) image->bitmap.stride = bw * 4; image->descriptor.width = image->bitmap.x = bw; image->descriptor.height = image->bitmap.y = bh; -image->bitmap.data = (intptr_t)(update->bitmap); +image->bitmap.data = (uintptr_t)(update->bitmap); image->bitmap.palette = 0; image->bitmap.format = SPICE_BITMAP_FMT_32BIT; @@ -200,7 +200,7 @@ static SimpleSpiceUpdate *qemu_spice_create_update(SimpleSpiceDisplay *ssd) } cmd->type = QXL_CMD_DRAW; -cmd->data = (intptr_t)drawable; +cmd->data = (uintptr_t)drawable; memset(&ssd->dirty, 0, sizeof(ssd->dirty)); return update; @@ -244,7 +244,7 @@ void qemu_spice_create_host_primary(SimpleSpiceDisplay *ssd) surface.mouse_mode = true; surface.flags = 0; surface.type = 0; -surface.mem= (intptr_t)ssd->buf; +surface.mem= (uintptr_t)ssd->buf; surface.group_id = MEMSLOT_GROUP_HOST; qemu_spice_create_primary_surface(ssd, 0, &surface, QXL_SYNC); -- 1.7.9.3
Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked
On Wed, Mar 21, 2012 at 11:18:16AM -0500, Corey Minyard wrote: > > >Look at drivers/char/ipmi/ipmi_msghandler.c. It has code to send panic > >event over IMPI. The code is pretty complex. Of course if we a going to > >implement something more complex than simple hypercall for panic > >notification we better do something more interesting with it than just > >saying "panic happened", like sending stack traces on all cpus for > >instance. > > I doubt that's the best example, unfortunately. The IPMI event log > has limited space and it has to be send a little piece at a time > since each log entry is 14 bytes. It just prints the panic string, > nothing else. Not that it isn't useful, it has saved my butt > before. > I gave ipmi example just to show that others do complex things on panic, not as an example of what we should do on a guest panic. > You have lots of interesting options with paravirtualization. You > could, for instance, create a console driver that delivered all > console output efficiently through a hypercall. That would be > really easy. Or, as you mention, a custom way to deliver panic > information. Collecting information like stack traces would be > harder to accomplish, as I don't think there is currently a way to > get it except by sending it to printk. > Why using hypercall for that though? You can do that with virtio-console. Make it zero config: virtio-console detected -> send console output there. -- Gleb.
Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked
On 03/21/2012 06:18 PM, Corey Minyard wrote: > >> Look at drivers/char/ipmi/ipmi_msghandler.c. It has code to send panic >> event over IMPI. The code is pretty complex. Of course if we a going to >> implement something more complex than simple hypercall for panic >> notification we better do something more interesting with it than just >> saying "panic happened", like sending stack traces on all cpus for >> instance. > > I doubt that's the best example, unfortunately. The IPMI event log > has limited space and it has to be send a little piece at a time since > each log entry is 14 bytes. It just prints the panic string, nothing > else. Not that it isn't useful, it has saved my butt before. > > You have lots of interesting options with paravirtualization. You > could, for instance, create a console driver that delivered all > console output efficiently through a hypercall. That would be really > easy. Or, as you mention, a custom way to deliver panic information. > Collecting information like stack traces would be harder to > accomplish, as I don't think there is currently a way to get it except > by sending it to printk. That already exists; virtio-console (or serial console emulation) can do the job. In fact the feature can be implemented 100% host side by searching for a panic string signature in the console logs. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [PATCH] Remove PCI class code from virtio balloon device
On 03/21/2012 11:11 AM, Michael S. Tsirkin wrote:
On Wed, Mar 21, 2012 at 10:14:35AM -0500, Anthony Liguori wrote:
On 03/21/2012 10:10 AM, Michael S. Tsirkin wrote:
On Wed, Mar 21, 2012 at 09:42:41AM -0500, Anthony Liguori wrote:
On 03/21/2012 08:08 AM, Michael S. Tsirkin wrote:
On Wed, Mar 21, 2012 at 11:26:15AM +, Stefan Hajnoczi wrote:
On Tue, Mar 20, 2012 at 09:19:47PM +1100, David Gibson wrote:
Looking at hw/pc_piix.c there are QEMUMachine types for each QEMU
release. Legacy machine types (e.g. pc_machine_v0_14) have a
.compat_props array that can override qdev properties.
Perhaps Michael Tsirkin or someone else can comment on how to wire up
hw/virtio-pci.c so that the class code can be overridden.
Stefan
afaik we already let users over-write it for some other pci devices,
look there for examples.
From hw/pc_piix.c:
.name = "pc-0.10",
.desc = "Standard PC, qemu 0.10",
.init = pc_init_pci_no_kvmclock,
.max_cpus = 255,
.compat_props = (GlobalProperty[]) {
{
.driver = "virtio-blk-pci",
.property = "class",
.value= stringify(PCI_CLASS_STORAGE_OTHER),
},{
And from the earlier part of the thread, yes, it's imperative that
we do not change anything in the PCI configuration space for older
pc versions regardless of whether it may or may not work.
Certain guests (like Windows) use a complex fingerprinting algorithm
to determine when hardware changes. It can be hard to detect in
simple testing because it's based on a threshold.
Regards,
Anthony Liguori
Which reminds me - qemu sticks the release version in
guest visible places like CPU version.
This is wrong and causes windows guests to print messages
about driver updates when you switch.
We should find all these places and stop doing this.
We could probably get away with doing a query/replace of
QEMU_VERSION with qemu_get_version(), make version a static variable
that defaults to QEMU_VERSION, and then provide a way for machines
to override it.
Then pc-0.10 could report a version of 0.10.
Regards,
Anthony Liguori
Frankly I don't see value in making it visible to the user,
at all. We are just triggering windows reactivations
without any user benefit. Why not return a fixed value there
to avoid that?
I don't see a problem making it fixed for 1.1, but for 1.0 and older, we should
expose what we were supposed to expose.
We need to fix the bug first, then we can change the behavior.
Regards,
Anthony Liguori
Re: [Qemu-devel] [PATCH 24/36] vmstate: port arm cpu
Am 19.03.2012 23:57, schrieb Juan Quintela: > Use one subsection for each feature. This means that we don't need to > bump the version field each time that a new feature gets introduced. > > Introduce cpsr_vmstate field, as I am not sure if I can "use" > uncached_cpsr for saving state. > > Signed-off-by: Juan Quintela As stated previously, I still think we should hold off converting the ARM CPU to VMState until the cp15 rework by Peter takes on shape. On another matter, had you prefixed this patch with "target-arm: " rather than hiding that essential keyword where my mailer cuts it off, it would be much easier to find in this series than amidst lots of "vmstate: " patches. 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] Remove PCI class code from virtio balloon device
On 03/21/2012 11:26 AM, Anthony Liguori wrote: On 03/21/2012 11:11 AM, Michael S. Tsirkin wrote: Frankly I don't see value in making it visible to the user, at all. We are just triggering windows reactivations without any user benefit. Why not return a fixed value there to avoid that? I don't see a problem making it fixed for 1.1, but for 1.0 and older, we should expose what we were supposed to expose. We need to fix the bug first, then we can change the behavior. In some cases, like USB, we really do want to expose a version, but we should probably only expose the major version, for instance, QEMU 1.x or 2.x. This would only be exposed by the appropriate machine types. Regards, Anthony Liguori Regards, Anthony Liguori
Re: [Qemu-devel] [PATCH v4 4/7] RTC: Set internal millisecond register to 500ms when reset divider
On Wed, 21 Mar 2012, Zhang, Yang Z wrote:
> > > struct tm *tm = &s->current_tm;
> > > -int64_t host_usec, guest_sec, guest_usec;
> > > +int64_t host_usec, guest_sec, guest_usec, offset_usec,
> > > old_guest_usec;
> > >
> > > host_usec = qemu_get_clock_ns(host_clock) / NS_PER_USEC;
> > > +offset_usec = s->offset_sec * USEC_PER_SEC + s->offset_usec;
> > > +old_guest_usec = (host_usec + offset_usec) % USEC_PER_SEC;
> > >
> > > guest_sec = mktimegm(tm);
> > > -guest_usec = guest_sec * USEC_PER_SEC;
> > >
> > > +/* start_usec equal 0 means rtc internal millisecond is
> > > + * same with before */
> > > +if (start_usec == 0) {
> > > +guest_usec = guest_sec * USEC_PER_SEC + old_guest_usec;
> > > +} else {
> > > +guest_usec = guest_sec * USEC_PER_SEC + start_usec;
> > > +}
> >
> > This looks like a mistake to me: before guest_usec was derived
> > exclusively from mktimegm (take or leave USEC_PER_SEC), while now
> > guest_usec is the sum of the value returned by mktimegm and
> > old_guest_usec, even when start_usec is 0.
> > Are you sure that this is correct?
> The logic is right. Before this patch, we assume the rtc internal millisecond
> register is same with host time, so we don't need to consider it and using
> mktimeis enough. Now, the rtc internal millisecond can be changed, so I use
> the old_guest_usec to record the current internal millisecond. When
> start_usec is 0, it means we don't need to change the internal millisecond
> register and the offset_sec is same as before.
I am starting to understand the intention of this code, but I am still
unconvinced that the start_usec == 0 case is correct.
If I am not mistaken you are calculating:
offset = guest + old_guest - host
while it should be:
offset = guest + old_start - host
where old_start is start_usec as it was set last time, correct? Am I
missing something? In any case please add a comment to explain what the
change is trying to accomplish.
[Qemu-devel] [PATCH V2 5/7] migration: clear BDRV_O_INCOMING flags on end of incoming live migration
Signed-off-by: Benoît Canet
---
migration.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/migration.c b/migration.c
index 8c119ba..94f7839 100644
--- a/migration.c
+++ b/migration.c
@@ -91,6 +91,7 @@ void process_incoming_migration(QEMUFile *f)
qemu_announce_self();
DPRINTF("successfully loaded vm state\n");
+bdrv_clear_incoming_migration_all();
/* Make sure all file formats flush their mutable metadata */
bdrv_invalidate_cache_all();
--
1.7.7.6
Re: [Qemu-devel] [PATCH 24/36] vmstate: port arm cpu
On 21 March 2012 16:29, Andreas Färber wrote: > Am 19.03.2012 23:57, schrieb Juan Quintela: >> Use one subsection for each feature. This means that we don't need to >> bump the version field each time that a new feature gets introduced. >> >> Introduce cpsr_vmstate field, as I am not sure if I can "use" >> uncached_cpsr for saving state. You could, I guess, but you'd need a 'post-save' hook to reset the bits not stored in uncached_cpsr normally, and it's a bit ugly. On the other hand having a field in CPUARMState just for save load is also pretty ugly. VMState should support a way to mark a migration state field as "not actually stored in a field in the struct, use these functions to save and load it", and we should use that. > As stated previously, I still think we should hold off converting the > ARM CPU to VMState until the cp15 rework by Peter takes on shape. I don't think this code actually clashes with what I've done so far, and I think switching to a lot of separate subsections is probably a step in the right direction even if the details might not be quite what they'll end up eventually. So I don't think we need to block it until the cp15 stuff lands. (Plus I know I've been taking forever on cp15 so I feel bad about blocking other peoples' patches on it.) -- PMM
Re: [Qemu-devel] [PATCH v4 5/7] RTC:Add RTC update-ended interrupt support
On Wed, 21 Mar 2012, Paolo Bonzini wrote: > Il 20/03/2012 19:35, Stefano Stabellini ha scritto: > > This is the function that is used to figure out whether we need the > > timers or not, the condition seems to be: > > > > (Not (REG_C_UF | REG_C_AF)) And (Not (REG_B_SET)) > > > > Shouldn't actually check for UIE being enabled? > > No, you need to set UF in case the code observes it without actually > enabling interrupt delivery on the ISA bus. Well, if it is just about updating UF, can we do it only when the user reads REG_C? I am just trying to limit the need for the update_timers...
Re: [Qemu-devel] [PATCH] ui/spice-display: use uintptr_t when casting qxl physical addresses
On 03/21/12 17:17, Alon Levy wrote: > This fixes running "-vga qxl -spice" with 32 bit compiled > qemu-system-i386. Patch added to spice patch queue. thanks, Gerd
[Qemu-devel] tracetool: cast const types to avoid compile time warnings
On Solaris/Illumos dtrace will remove the "const" qualifier from any arguments when producing the header file, this results in hundreds of compile-time warnings. I have put together a patch to tracetool to cast any const argument appropriately to remove the warnings, but I don't know how it behaves on any other dtrace platform. If the "const" isn't removed then this patch will actually create warnings. Do you see these warnings on any other dtrace platform? If not, then I'll need to make sure the patch is solaris-specific. Thanks, Lee.
Re: [Qemu-devel] [PATCH v4 00/36] VMState port of all cpus
Am 19.03.2012 23:57, schrieb Juan Quintela:
> This repository contains all the changes:
>
> git://repo.or.cz/qemu/quintela.git vmstate-cpus-v4
>
> [v4]
> - rebase to top
> - adapt to vmstate.h change
> - adapt to CPUState -> CPU$archState rename
> - integrate arm changes in the meantime
> - add QEMU contributors to the copyright notice of ppc & sparc
>
> [v3]
> - rebase to top
> - fix sparc/arm/i386 changes in upstream
> - all reviews were positive, Anthony, please pull
>
> [v2] Changes since v1
>
> - preserve arm comment that was missing (pbrook)
> - add copyright notice to the files that were empty
> - new patches:
> * fix formating for i386
> * remove unneeded includes
> * rename machine.c to vmstate.c
>
> Later, Juan.
>
> [v1]
>
> This series port all cpus to use vmstate.
> - 1st patch is a fix of vmstate.
> - I discussed the arm changes over irc with Peter, he agreed that some
> simplification could be good, but he didn't saw the patches O:-)
> - mips: no pci chipset has been ported, so migration don't work there.
> I have embedded a couple of structs to improve vmstate checking. Notice
> that they were always allocated, so there shouldn't be any problem.
> - sparc: I changed the format a little bit to be able to use normal arrays.
> - sparc: If we always send the whole register windows, we don't need
> VMSTATE_VARRAY_MULTIPLY. As that array is quite big (520 elements), I am
> not
> sure what is best.
> - cpsr_vmstate on arm: I am not sure if I could "abuse" uncached_cpsr for that
> purpose?
>
> I have only tested on x86, for the rest, I double checked, but it is
> possible that I missed something. I expect all patches to be
> integrated by Anthony in one go. Architecture maintainers are CC'd
> for an ACK/NACK/comments.
>
> Please, review.
>
> PD. Is there an easy way of creating this "CC" list of mail addresses,
> or the only way is to edit comments and write it by hand as I did?
Actually I don't see any CCs at all in this series. Which makes me think
this is v1 rubbish in the new cover letter. :/
--cc-cmd="scripts/get_maintainer.pl --nogit-fallback" should work.
A general comment:
With regards to the ongoing CPU QOM'ification, if we ever arrive in a
scenario where we can have multiple targets in one machine, I guess the
VMState .name "cpu" would cause problems? In that case it might be
better to use the proposed QOM type names, i.e. "arm-cpu", etc. from the
start.
Andreas
>
> Juan Quintela (36):
> vmstate: Simplify test for CPU_SAVE_VERSION
> vmstate: make all architectures export a way to migrate cpu's
> vmstate: unicore32 don't support cpu migration
> vmstate: use new cpu style for x86
> vmstate: use new style for lm32 cpus
> vmstate: make microblaze cpus not migrateable
> vmstate: port cris cpu to vmstate
> vmstate: machine.c is only compiled for !CONFIG_USER_ONLY
> vmstate: introduce float32 arrays
> vmstate: introduce float64 arrays
> vmstate: introduce CPU_DoubleU arrays
> vmstate: Introduce VMSTATE_STRUCT_VARRAY_INT32_TEST
> vmstate: port ppc cpu
> vmstate: introduce VMSTATE_VARRAY_MULTIPLY
> vmstate: define vmstate_info_uinttls
> vmstate: port sparc cpu
> vmstate: make incompatible change for sparc
> mips_fulong2e: cpu vmstate already registered in cpu_exec_init
> mips: make mvp an embedded struct instead of a pointer
> mips: make tlb an embedded struct instead of a pointer
> mips: bump migration version to 4
> vmstate: port mips cpu
> arm: save always 32 fpu registers
> vmstate: port arm cpu
> vmstate: all cpus converted
> vmstate: fix vmstate formating for i386
> vmstate: remove unneeded includes from target-*/machine.c
> vmstate: rename machine.c to vmstate-cpu.c
> vmstate: Add copyright info for alpha processor
> vmstate: Add copyright info for lm32 processor
> vmstate: Add copyright info for cris processor
> vmstate: Add copyright info for arm processor
> vmstate: Add copyright info for i386 processor
> vmstate: Add copyright info for mips processor
> vmstate: Add copyright info for ppc processor
> vmstate: Add copyright info for sparc processor
>
> Makefile.target|3 +-
> exec.c |7 +-
> hw/hw.h|2 +
> hw/mips_fulong2e.c |1 -
> hw/mips_malta.c|4 +-
> hw/mips_timer.c|2 +-
> hw/sun4u.c | 20 --
> qemu-common.h |4 -
> savevm.c | 90
> target-alpha/{machine.c => vmstate-cpu.c} | 28 ++-
> target-arm/cpu.h |5 +-
> target-arm/machine.c | 233 -
> target-arm/vmstate-cpu.c | 191 +
> target-cris/cpu.h | 13 +-
> target-cris/m
Re: [Qemu-devel] [PATCH v2 2/2] Change timedrift default value to slew
On 21-03-2012 03:02, Paolo Bonzini wrote:
> This piece of code from the previous if:
>
> if (!strcmp(value, "slew")) {
> static GlobalProperty slew_lost_ticks[] = {
> {
> .driver = "mc146818rtc",
> .property = "lost_tick_policy",
> .value= "slew",
> },
> { /* end of list */ }
> };
>
> qdev_prop_register_global_list(slew_lost_ticks);
>
> needs to be adjusted and moved to the "if (!strmp(value, "none"))" branch.
Thanks, Paolo! I sent a version 3 of these patches with the changes you
suggested.
--
Best regards,
Crístian.
Re: [Qemu-devel] [PATCH v4] Man page: Add -global description
Miroslav Rezanina writes:
> There's only TODO information in qemu man page for -global option. This is a
> basic description of this option with simple example.
>
> Signed-off-by: Miroslav Rezanina
>
> v4:
> - break long line
>
> v3:
> - add use case description
> - use prop instead of property
>
> v2:
> - Use better value in example
> Patch:
> --
> diff --git a/qemu-options.hx b/qemu-options.hx
> index daefce3..662f571 100644
> --- a/qemu-options.hx
> +++ b/qemu-options.hx
> @@ -288,13 +288,21 @@ TODO
> ETEXI
>
> DEF("global", HAS_ARG, QEMU_OPTION_global,
> -"-global driver.property=value\n"
> +"-global driver.prop=value\n"
> "set a global default for a driver property\n",
> QEMU_ARCH_ALL)
> STEXI
> -@item -global
> +@item -global @var{driver}.@var{prop}=@var{value}
> @findex -global
> -TODO
> +Set default value of @var{driver}'s property @var{prop} to @var{value}, e.g.:
> +
> +@example
> +qemu -global ide-drive.physical_block_size=4096 -drive
> file=file,if=ide,index=0,media=disk
> +@end example
> +
> +In particular, you can use this to set driver properties for devices which
> are
> +created automatically by the machine model. To create a device which is not
> +created automatically and set properties on it, use -@option{device}.
> ETEXI
>
> DEF("mtdblock", HAS_ARG, QEMU_OPTION_mtdblock,
This is a clear improvement. Cc'ing Anthony, the qdev maintainer in all
but name ;)
Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked
On Wed, Mar 21, 2012 at 06:25:16PM +0200, Avi Kivity wrote: > On 03/21/2012 06:18 PM, Corey Minyard wrote: > > > >> Look at drivers/char/ipmi/ipmi_msghandler.c. It has code to send panic > >> event over IMPI. The code is pretty complex. Of course if we a going to > >> implement something more complex than simple hypercall for panic > >> notification we better do something more interesting with it than just > >> saying "panic happened", like sending stack traces on all cpus for > >> instance. > > > > I doubt that's the best example, unfortunately. The IPMI event log > > has limited space and it has to be send a little piece at a time since > > each log entry is 14 bytes. It just prints the panic string, nothing > > else. Not that it isn't useful, it has saved my butt before. > > > > You have lots of interesting options with paravirtualization. You > > could, for instance, create a console driver that delivered all > > console output efficiently through a hypercall. That would be really > > easy. Or, as you mention, a custom way to deliver panic information. > > Collecting information like stack traces would be harder to > > accomplish, as I don't think there is currently a way to get it except > > by sending it to printk. > > That already exists; virtio-console (or serial console emulation) can do > the job. > > In fact the feature can be implemented 100% host side by searching for a > panic string signature in the console logs. You can even go one better and search for the panic string in the guest memory directly, which is what virt-dmesg does :-) http://people.redhat.com/~rjones/virt-dmesg/ Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
[Qemu-devel] [PATCH] uhci: stop queue filling when we find a in-flight td
Not only QHs can form rings, but TDs too. With the new
queuing/pipelining support we are following TD chains and
can actually walk in circles. An assert() prevents us from
entering an endless loop then.
Fix is easy: Just stop queuing when we figure the TD we are
about to queue up is in flight already.
Signed-off-by: Gerd Hoffmann
---
hw/usb/hcd-uhci.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/hw/usb/hcd-uhci.c b/hw/usb/hcd-uhci.c
index e55dad9..2be564b 100644
--- a/hw/usb/hcd-uhci.c
+++ b/hw/usb/hcd-uhci.c
@@ -965,6 +965,9 @@ static void uhci_fill_queue(UHCIState *s, UHCI_TD *td)
}
trace_usb_uhci_td_queue(plink & ~0xf, ptd.ctrl, ptd.token);
ret = uhci_handle_td(s, plink, &ptd, &int_mask);
+if (ret == TD_RESULT_ASYNC_CONT) {
+break;
+}
assert(ret == TD_RESULT_ASYNC_START);
assert(int_mask == 0);
plink = ptd.link;
--
1.7.1
Re: [Qemu-devel] [PATCH v4 00/36] VMState port of all cpus
Andreas Färber wrote: > Am 19.03.2012 23:57, schrieb Juan Quintela: >> This repository contains all the changes: >> >> git://repo.or.cz/qemu/quintela.git vmstate-cpus-v4 >> >> [v4] >> - rebase to top >> - adapt to vmstate.h change >> - adapt to CPUState -> CPU$archState rename >> - integrate arm changes in the meantime >> - add QEMU contributors to the copyright notice of ppc & sparc [...] > > Actually I don't see any CCs at all in this series. Which makes me think > this is v1 rubbish in the new cover letter. :/ see the changelog for v4. All patches were already reviewed, only changes were: copyright stuff that Blaw didn't liked (and he was cc'd), and rebasing (move of stuff from hw/hw.h to vmstate.h and s/CPUState/CPU$archState/). Idea here was not to resend to everybody that already reviewed the patches another copy. > > --cc-cmd="scripts/get_maintainer.pl --nogit-fallback" should work. nice trick. > A general comment: > With regards to the ongoing CPU QOM'ification, if we ever arrive in a > scenario where we can have multiple targets in one machine, I guess the > VMState .name "cpu" would cause problems? In that case it might be > better to use the proposed QOM type names, i.e. "arm-cpu", etc. from the > start. At least for x86 we need to maintain backward compatibility. For the cest of architectures, we can change it after this series. It is more, it would be better to have: "sparc32-cpu" and "sparc64-cpu", so we could be able to read the vmstate section without more external info. I would preffer to do this changes after this series goes in. [note to all, I am sending a v5 with the changes suggested yesterday by peter on float32/64 handling ] Thanks, Juan.
Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked
On 03/21/2012 07:04 PM, Daniel P. Berrange wrote: > > > > In fact the feature can be implemented 100% host side by searching for a > > panic string signature in the console logs. > > You can even go one better and search for the panic string in the > guest memory directly, which is what virt-dmesg does :-) > > http://people.redhat.com/~rjones/virt-dmesg/ > -ETOOHACKY Any guest change will break this, no? -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [PATCH 4/6] fdc: Parametrize ISA base, IRQ and DMA
Hervé Poussineau writes: > Keep the PC values as defaults but allow to override them for PReP. > > Signed-off-by: Hervé Poussineau > Cc: Markus Armbruster > Signed-off-by: Andreas Färber Reviewed-by: Markus Armbruster
Re: [Qemu-devel] [PATCH 08/36] vmstate: machine.c is only compiled for !CONFIG_USER_ONLY
Confirmed, in Makefile.target machine.o is confined to ifdef CONFIG_SOFTMMU. Am 19.03.2012 23:57, schrieb Juan Quintela: > Signed-off-by: Juan Quintela I verified that the right #endifs were removed and compile-tested it. Acked-by: Andreas Färber 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] Remove PCI class code from virtio balloon device
On Wed, Mar 21, 2012 at 11:26:50AM -0500, Anthony Liguori wrote:
> On 03/21/2012 11:11 AM, Michael S. Tsirkin wrote:
> >On Wed, Mar 21, 2012 at 10:14:35AM -0500, Anthony Liguori wrote:
> >>On 03/21/2012 10:10 AM, Michael S. Tsirkin wrote:
> >>>On Wed, Mar 21, 2012 at 09:42:41AM -0500, Anthony Liguori wrote:
> On 03/21/2012 08:08 AM, Michael S. Tsirkin wrote:
> >On Wed, Mar 21, 2012 at 11:26:15AM +, Stefan Hajnoczi wrote:
> >>On Tue, Mar 20, 2012 at 09:19:47PM +1100, David Gibson wrote:
> >>Looking at hw/pc_piix.c there are QEMUMachine types for each QEMU
> >>release. Legacy machine types (e.g. pc_machine_v0_14) have a
> >>.compat_props array that can override qdev properties.
> >>
> >>Perhaps Michael Tsirkin or someone else can comment on how to wire up
> >>hw/virtio-pci.c so that the class code can be overridden.
> >>
> >>Stefan
> >
> >afaik we already let users over-write it for some other pci devices,
> >look there for examples.
>
> From hw/pc_piix.c:
>
> .name = "pc-0.10",
> .desc = "Standard PC, qemu 0.10",
> .init = pc_init_pci_no_kvmclock,
> .max_cpus = 255,
> .compat_props = (GlobalProperty[]) {
> {
> .driver = "virtio-blk-pci",
> .property = "class",
> .value= stringify(PCI_CLASS_STORAGE_OTHER),
> },{
>
> And from the earlier part of the thread, yes, it's imperative that
> we do not change anything in the PCI configuration space for older
> pc versions regardless of whether it may or may not work.
>
> Certain guests (like Windows) use a complex fingerprinting algorithm
> to determine when hardware changes. It can be hard to detect in
> simple testing because it's based on a threshold.
>
> Regards,
>
> Anthony Liguori
> >>>
> >>>Which reminds me - qemu sticks the release version in
> >>>guest visible places like CPU version.
> >>>This is wrong and causes windows guests to print messages
> >>>about driver updates when you switch.
> >>>We should find all these places and stop doing this.
> >>
> >>We could probably get away with doing a query/replace of
> >>QEMU_VERSION with qemu_get_version(), make version a static variable
> >>that defaults to QEMU_VERSION, and then provide a way for machines
> >>to override it.
> >>
> >>Then pc-0.10 could report a version of 0.10.
> >>
> >>Regards,
> >>
> >>Anthony Liguori
> >
> >Frankly I don't see value in making it visible to the user,
> >at all. We are just triggering windows reactivations
> >without any user benefit. Why not return a fixed value there
> >to avoid that?
>
> I don't see a problem making it fixed for 1.1, but for 1.0 and
> older, we should expose what we were supposed to expose.
> We need to fix the bug first, then we can change the behavior.
>
> Regards,
>
> Anthony Liguori
>
> >
> >
> >
Makes sense to me.
Re: [Qemu-devel] [PATCH] ui/spice-display: use uintptr_t when casting qxl physical addresses
On Wed, Mar 21, 2012 at 05:42:25PM +0100, Gerd Hoffmann wrote: > On 03/21/12 17:17, Alon Levy wrote: > > This fixes running "-vga qxl -spice" with 32 bit compiled > > qemu-system-i386. > > Patch added to spice patch queue. So perhaps you can also ack those: http://patchwork.freedesktop.org/patch/9597/ http://patchwork.freedesktop.org/patch/9598/ http://patchwork.freedesktop.org/patch/9599/ http://patchwork.freedesktop.org/patch/9600/ http://patchwork.freedesktop.org/patch/9601/ > > thanks, > Gerd
Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked
On 2012-03-21 18:34, Avi Kivity wrote: > On 03/21/2012 07:04 PM, Daniel P. Berrange wrote: >>> >>> In fact the feature can be implemented 100% host side by searching for a >>> panic string signature in the console logs. >> >> You can even go one better and search for the panic string in the >> guest memory directly, which is what virt-dmesg does :-) >> >> http://people.redhat.com/~rjones/virt-dmesg/ >> > > -ETOOHACKY > > Any guest change will break this, no? /me has a simple python script (a few ten lines) to do this during runtime (kgdb, qemu gdbstub) or post-portem (gdb -c vmcore). Ideally, that will once come with the Linux sources where it can be kept in sync with the kernel data structures. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
Re: [Qemu-devel] [PATCH] Remove PCI class code from virtio balloon device
On Wed, Mar 21, 2012 at 11:33:21AM -0500, Anthony Liguori wrote: > On 03/21/2012 11:26 AM, Anthony Liguori wrote: > >On 03/21/2012 11:11 AM, Michael S. Tsirkin wrote: > >>Frankly I don't see value in making it visible to the user, > >>at all. We are just triggering windows reactivations > >>without any user benefit. Why not return a fixed value there > >>to avoid that? > > > >I don't see a problem making it fixed for 1.1, but for 1.0 and older, we > >should > >expose what we were supposed to expose. > > > >We need to fix the bug first, then we can change the behavior. > > In some cases, like USB, we really do want to expose a version, why, exactly? > but > we should probably only expose the major version, for instance, QEMU > 1.x or 2.x. This would only be exposed by the appropriate machine > types. > > Regards, > > Anthony Liguori > > > > >Regards, > > > >Anthony Liguori > > > >> > >> > >> > > > >
[Qemu-devel] [PATCH V9 7/8] Introduce apic-msidef.h
This patch move the msi definition from apic.c to apic-msidef.h. So it can be used also by other .c files. Signed-off-by: Anthony PERARD Acked-by: Stefano Stabellini --- hw/apic-msidef.h | 30 ++ hw/apic.c| 11 +-- 2 files changed, 31 insertions(+), 10 deletions(-) create mode 100644 hw/apic-msidef.h diff --git a/hw/apic-msidef.h b/hw/apic-msidef.h new file mode 100644 index 000..6e2eb71 --- /dev/null +++ b/hw/apic-msidef.h @@ -0,0 +1,30 @@ +#ifndef HW_APIC_MSIDEF_H +#define HW_APIC_MSIDEF_H + +/* + * Intel APIC constants: from include/asm/msidef.h + */ + +/* + * Shifts for MSI data + */ + +#define MSI_DATA_VECTOR_SHIFT 0 +#define MSI_DATA_VECTOR_MASK 0x00ff + +#define MSI_DATA_DELIVERY_MODE_SHIFT8 +#define MSI_DATA_LEVEL_SHIFT14 +#define MSI_DATA_TRIGGER_SHIFT 15 + +/* + * Shift/mask fields for msi address + */ + +#define MSI_ADDR_DEST_MODE_SHIFT2 + +#define MSI_ADDR_REDIRECTION_SHIFT 3 + +#define MSI_ADDR_DEST_ID_SHIFT 12 +#define MSI_ADDR_DEST_ID_MASK 0x000 + +#endif /* HW_APIC_MSIDEF_H */ diff --git a/hw/apic.c b/hw/apic.c index 4eeaf88..a8da2f1 100644 --- a/hw/apic.c +++ b/hw/apic.c @@ -22,19 +22,10 @@ #include "host-utils.h" #include "trace.h" #include "pc.h" +#include "apic-msidef.h" #define MAX_APIC_WORDS 8 -/* Intel APIC constants: from include/asm/msidef.h */ -#define MSI_DATA_VECTOR_SHIFT 0 -#define MSI_DATA_VECTOR_MASK 0x00ff -#define MSI_DATA_DELIVERY_MODE_SHIFT 8 -#define MSI_DATA_TRIGGER_SHIFT 15 -#define MSI_DATA_LEVEL_SHIFT 14 -#define MSI_ADDR_DEST_MODE_SHIFT 2 -#define MSI_ADDR_DEST_ID_SHIFT 12 -#defineMSI_ADDR_DEST_ID_MASK 0x000 - #define SYNC_FROM_VAPIC 0x1 #define SYNC_TO_VAPIC 0x2 #define SYNC_ISR_IRR_TO_VAPIC 0x4 -- Anthony PERARD
[Qemu-devel] [PATCH V9 3/8] Introduce HostPCIDevice to access a pci device on the host.
Signed-off-by: Anthony PERARD
Acked-by: Stefano Stabellini
---
Makefile.target |3 +
hw/host-pci-device.c | 278 ++
hw/host-pci-device.h | 75 ++
3 files changed, 356 insertions(+), 0 deletions(-)
create mode 100644 hw/host-pci-device.c
create mode 100644 hw/host-pci-device.h
diff --git a/Makefile.target b/Makefile.target
index 63cf769..0ccfd5b 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -232,6 +232,9 @@ obj-$(CONFIG_NO_XEN) += xen-stub.o
obj-i386-$(CONFIG_XEN) += xen_platform.o
+# Xen PCI Passthrough
+obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += host-pci-device.o
+
# Inter-VM PCI shared memory
CONFIG_IVSHMEM =
ifeq ($(CONFIG_KVM), y)
diff --git a/hw/host-pci-device.c b/hw/host-pci-device.c
new file mode 100644
index 000..3dacb30
--- /dev/null
+++ b/hw/host-pci-device.c
@@ -0,0 +1,278 @@
+/*
+ * Copyright (C) 2011 Citrix Ltd.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2. See
+ * the COPYING file in the top-level directory.
+ *
+ */
+
+#include "qemu-common.h"
+#include "host-pci-device.h"
+
+#define PCI_MAX_EXT_CAP \
+((PCIE_CONFIG_SPACE_SIZE - PCI_CONFIG_SPACE_SIZE) / (PCI_CAP_SIZEOF + 4))
+
+enum error_code {
+ERROR_SYNTAX = 1,
+};
+
+static int path_to(const HostPCIDevice *d,
+ const char *name, char *buf, ssize_t size)
+{
+return snprintf(buf, size, "/sys/bus/pci/devices/%04x:%02x:%02x.%x/%s",
+d->domain, d->bus, d->dev, d->func, name);
+}
+
+static int get_resource(HostPCIDevice *d)
+{
+int i, rc = 0;
+FILE *f;
+char path[PATH_MAX];
+unsigned long long start, end, flags, size;
+
+path_to(d, "resource", path, sizeof (path));
+f = fopen(path, "r");
+if (!f) {
+fprintf(stderr, "Error: Can't open %s: %s\n", path, strerror(errno));
+return -errno;
+}
+
+for (i = 0; i < PCI_NUM_REGIONS; i++) {
+if (fscanf(f, "%llx %llx %llx", &start, &end, &flags) != 3) {
+fprintf(stderr, "Error: Syntax error in %s\n", path);
+rc = ERROR_SYNTAX;
+break;
+}
+if (start) {
+size = end - start + 1;
+} else {
+size = 0;
+}
+
+if (i < PCI_ROM_SLOT) {
+d->io_regions[i].base_addr = start;
+d->io_regions[i].size = size;
+d->io_regions[i].flags = flags;
+} else {
+d->rom.base_addr = start;
+d->rom.size = size;
+d->rom.flags = flags;
+}
+}
+
+fclose(f);
+return rc;
+}
+
+static int get_hex_value(HostPCIDevice *d, const char *name,
+ unsigned long *pvalue)
+{
+char path[PATH_MAX];
+FILE *f;
+unsigned long value;
+
+path_to(d, name, path, sizeof (path));
+f = fopen(path, "r");
+if (!f) {
+fprintf(stderr, "Error: Can't open %s: %s\n", path, strerror(errno));
+return -errno;
+}
+if (fscanf(f, "%lx\n", &value) != 1) {
+fprintf(stderr, "Error: Syntax error in %s\n", path);
+fclose(f);
+return ERROR_SYNTAX;
+}
+fclose(f);
+*pvalue = value;
+return 0;
+}
+
+static bool pci_dev_is_virtfn(HostPCIDevice *d)
+{
+char path[PATH_MAX];
+struct stat buf;
+
+path_to(d, "physfn", path, sizeof (path));
+return !stat(path, &buf);
+}
+
+static int host_pci_config_fd(HostPCIDevice *d)
+{
+char path[PATH_MAX];
+
+if (d->config_fd < 0) {
+path_to(d, "config", path, sizeof (path));
+d->config_fd = open(path, O_RDWR);
+if (d->config_fd < 0) {
+fprintf(stderr, "HostPCIDevice: Can not open '%s': %s\n",
+path, strerror(errno));
+}
+}
+return d->config_fd;
+}
+static int host_pci_config_read(HostPCIDevice *d, int pos, void *buf, int len)
+{
+int fd = host_pci_config_fd(d);
+int res = 0;
+
+again:
+res = pread(fd, buf, len, pos);
+if (res != len) {
+if (res < 0 && (errno == EINTR || errno == EAGAIN)) {
+goto again;
+}
+fprintf(stderr, "%s: read failed: %s (fd: %i)\n",
+__func__, strerror(errno), fd);
+return -errno;
+}
+return 0;
+}
+static int host_pci_config_write(HostPCIDevice *d,
+ int pos, const void *buf, int len)
+{
+int fd = host_pci_config_fd(d);
+int res = 0;
+
+again:
+res = pwrite(fd, buf, len, pos);
+if (res != len) {
+if (res < 0 && (errno == EINTR || errno == EAGAIN)) {
+goto again;
+}
+fprintf(stderr, "%s: write failed: %s\n",
+__func__, strerror(errno));
+return -errno;
+}
+return 0;
+}
+
+int host_pci_get_byte(HostPCIDevice *d, int pos, uint8_t *p)
+{
+uint8_t buf;
+int rc = host_pci_config_read(d, pos, &buf, 1);
+if (rc == 0) {
+*p = buf;
+}
+return rc;
+}
+int host_pci_get_word(HostPCI
[Qemu-devel] [PATCH V9 2/8] configure: Introduce --enable-xen-pci-passthrough.
Signed-off-by: Anthony PERARD Acked-by: Stefano Stabellini --- configure | 25 + 1 files changed, 25 insertions(+), 0 deletions(-) diff --git a/configure b/configure index 8b4e3c1..f61bd48 100755 --- a/configure +++ b/configure @@ -136,6 +136,7 @@ vnc_png="" vnc_thread="no" xen="" xen_ctrl_version="" +xen_pci_passthrough="" linux_aio="" cap_ng="" attr="" @@ -682,6 +683,10 @@ for opt do ;; --enable-xen) xen="yes" ;; + --disable-xen-pci-passthrough) xen_pci_passthrough="no" + ;; + --enable-xen-pci-passthrough) xen_pci_passthrough="yes" + ;; --disable-brlapi) brlapi="no" ;; --enable-brlapi) brlapi="yes" @@ -1034,6 +1039,8 @@ echo " (affects only QEMU, not qemu-img)" echo " --enable-mixemu enable mixer emulation" echo " --disable-xendisable xen backend driver support" echo " --enable-xen enable xen backend driver support" +echo " --disable-xen-pci-passthrough" +echo " --enable-xen-pci-passthrough" echo " --disable-brlapi disable BrlAPI" echo " --enable-brlapi enable BrlAPI" echo " --disable-vnc-tlsdisable TLS encryption for VNC server" @@ -1478,6 +1485,21 @@ EOF fi fi +if test "$xen_pci_passthrough" != "no"; then + if test "$xen" = "yes" && test "$linux" = "yes"; then +xen_pci_passthrough=yes + else +if test "$xen_pci_passthrough" = "yes"; then + echo "ERROR" + echo "ERROR: User requested feature Xen PCI Passthrough" + echo "ERROR: but this feature require /sys from Linux" + echo "ERROR" + exit 1; +fi +xen_pci_passthrough=no + fi +fi + ## # pkg-config probe @@ -3635,6 +3657,9 @@ case "$target_arch2" in if test "$xen" = "yes" -a "$target_softmmu" = "yes" ; then target_phys_bits=64 echo "CONFIG_XEN=y" >> $config_target_mak + if test "$xen_pci_passthrough" = yes; then +echo "CONFIG_XEN_PCI_PASSTHROUGH=y" >> "$config_target_mak" + fi else echo "CONFIG_NO_XEN=y" >> $config_target_mak fi -- Anthony PERARD
