Re: Proper support for PCI-based option rom loading (was Re: [Qemu-devel] Re: qdev property bug?)
On Mon, Dec 14, 2009 at 08:37:44PM -0600, Anthony Liguori wrote:
> Okay, I think I've figured out how this is supposed to work. With these
> two patches to SeaBIOS and the patch to qemu, I can run:
I'm not sure why "Do not guard qemu shadow ram work around in
CONFIG_OPTIONROMS_DEPLOYED" patch is needed. The code today is:
if (CONFIG_OPTIONROMS_DEPLOYED) {
int reg = pci_config_readb(bdf, 0x5a + i);
if ((reg & 0x11) != 0x11) {
// Need to copy optionroms to work around qemu implementation
void *mem = (void*)(BUILD_ROM_START + i * 32*1024);
memcpy((void*)BUILD_BIOS_TMP_ADDR, mem, 32*1024);
pci_config_writeb(bdf, 0x5a + i, 0x33);
memcpy(mem, (void*)BUILD_BIOS_TMP_ADDR, 32*1024);
clear = 1;
} else {
pci_config_writeb(bdf, 0x5a + i, 0x33);
}
} else {
pci_config_writeb(bdf, 0x5a + i, 0x33);
}
So, in the non CONFIG_OPTIONROMS_DEPLOYED case, SeaBIOS will just do
the write enable call (pci_config_writeb(bdf, 0x5a + i, 0x33)). The
CONFIG_OPTIONROMS_DEPLOYED case should just be to copy the roms qemu
has deployed. If SeaBIOS is filling in the 0xc-0xf space, it
shouldn't matter if the contents of that space is lost during the
write enable.
Let me know if I've missed something.
-Kevin
Re: [Qemu-devel] Re: qdev property bug?
On Mon, Dec 14, 2009 at 03:05:22PM -0600, Anthony Liguori wrote: > I believe the way this works with real BIOSes is that the rom is > initially loaded somewhere outside of the 1M region and it's init is > executed. It's then the rom's job to execute it's initialization. > Afterwards, the bios copies the rom into the 1M region. This is how PMM > works. The option rom load is generally a little different. The BIOS enables the PCI rom bar, verifies the rom, copies the rom to the 0xa-0xf region, unmaps the PCI rom bar, and then jumps to the rom it just copied. The rom may reduce its reported rom size to effectively shrink its memory footprint. As you noted in another post, gPXE does this today by relocating itself into PMM allocated memory. The PCIv3 spec does define a feature where the bios can copy the rom to some random area of memory and execute it - the rom is then responsible for copying itself into the 0xa-0xf region. However, this support is optional for the BIOS to implement; SeaBIOS doesn't implement it. Having SeaBIOS copy the roms from PCI space enables a number of space optimizations. First, if SeaBIOS copies the roms, it can pack them so that rom shrinking actually works. As it is now, a rom can shrink itself, but because SeaBIOS doesn't deploy the roms, the saved space isn't utilized for other roms. Second, SeaBIOS right now is about 75K in size, but to satisfy qemu it fills itself to an even 128K. When SeaBIOS copies roms, it knows it can use the unused parts of the e-segment (another 50K). One idea I've been thinking about is to have SeaBIOS hoist it's 32bit code into high-memory (much like what gPXE does). This would make the remaining parts of the e-segment available for roms. It would also free up another 30K of the f-segment for roms (the PCIv3 spec permits roms to be located in the f-segment). However, implementing this doesn't seem like a high priority as most roms seem to fit okay today (when rom shrinking works). -Kevin
Re: Proper support for PCI-based option rom loading (was Re: [Qemu-devel] Re: qdev property bug?)
On Mon, Dec 14, 2009 at 08:37:44PM -0600, Anthony Liguori wrote: > Okay, I think I've figured out how this is supposed to work. With these > two patches to SeaBIOS and the patch to qemu, I can run: Yes - I think this is the best way to fix this. Space optimizations can be most easily done by allowing SeaBIOS to copy the option roms into the area between 0xc-0xf. This is also what a real BIOS would do, and it's what SeaBIOS does when it is run on real hardware. -Kevin
Re: [Qemu-devel] target-alpha: An approach to fp insn qualifiers
On 12/14/2009 04:31 PM, Richard Henderson wrote:
On 12/14/2009 12:11 PM, Laurent Desnogues wrote:
I'll take a closer look at your patch tomorrow.
For the record, I believe this finishes what I had in mind for the
exception handling there in op_handler.c.
Hmph. One more patch for correctness. With this 183.equake runs
correctly. I couldn't remember all the hoops to get runspec.pl to work,
to do the whole testsuite, but I did run this one by hand.
./quake-amd64: Done. Terminating the simulation.
real0m34.943s
user0m34.913s
sys 0m0.024s
./quake-axp: Done. Terminating the simulation.
real33m24.105s
user33m23.674s
sys 0m0.116s
with identical output.
r~
commit daf11ad5cd50c56d44e36e4ea334c660f8fe4c16
Author: Richard Henderson
Date: Mon Dec 14 19:46:57 2009 -0800
target-alpha: Don't ever saturate cvttq.
The previous patch tried allowing saturation if /S;
that doesn't match what the kernels generate.
diff --git a/target-alpha/op_helper.c b/target-alpha/op_helper.c
index d031f56..2d1c3d5 100644
--- a/target-alpha/op_helper.c
+++ b/target-alpha/op_helper.c
@@ -1220,120 +1220,106 @@ uint64_t helper_cvtqs (uint64_t a, uint32_t quals)
is used by the compiler to get unsigned conversion for free with
the same instruction. */
-static uint64_t cvttq_noqual_internal(uint64_t a, uint32_t rounding_mode)
+static uint64_t cvttq_internal(uint64_t a)
{
uint64_t frac, ret = 0;
-uint32_t exp, sign;
+uint32_t exp, sign, exc = 0;
int shift;
sign = (a >> 63);
exp = (uint32_t)(a >> 52) & 0x7ff;
frac = a & 0xfull;
-/* We already handled denormals in remap_ieee_input; infinities and
- nans are defined to return zero as per truncation. */
-if (exp == 0 || exp == 0x7ff)
-return 0;
-
-/* Restore implicit bit. */
-frac |= 0x10ull;
-
-/* Note that neither overflow exceptions nor inexact exceptions
- are desired. This lets us streamline the checks quite a bit. */
-shift = exp - 1023 - 52;
-if (shift >= 0) {
-/* In this case the number is so large that we must shift
- the fraction left. There is no rounding to do. */
-if (shift < 63) {
-ret = frac << shift;
-}
+if (exp == 0) {
+if (unlikely(frac != 0))
+goto do_underflow;
+} else if (exp == 0x7ff) {
+if (frac == 0)
+exc = float_flag_overflow;
+else
+exc = float_flag_invalid;
} else {
-uint64_t round;
-
-/* In this case the number is smaller than the fraction as
- represented by the 52 bit number. Here we must think
- about rounding the result. Handle this by shifting the
- fractional part of the number into the high bits of ROUND.
- This will let us efficiently handle round-to-nearest. */
-shift = -shift;
-if (shift < 63) {
-ret = frac >> shift;
-round = frac << (64 - shift);
+/* Restore implicit bit. */
+frac |= 0x10ull;
+
+/* Note that neither overflow exceptions nor inexact exceptions
+ are desired. This lets us streamline the checks quite a bit. */
+shift = exp - 1023 - 52;
+if (shift >= 0) {
+/* In this case the number is so large that we must shift
+ the fraction left. There is no rounding to do. */
+if (shift < 63) {
+ret = frac << shift;
+if ((ret >> shift) != frac)
+exc = float_flag_overflow;
+}
} else {
-/* The exponent is so small we shift out everything.
- Leave a sticky bit for proper rounding below. */
-round = 1;
-}
+uint64_t round;
+
+/* In this case the number is smaller than the fraction as
+ represented by the 52 bit number. Here we must think
+ about rounding the result. Handle this by shifting the
+ fractional part of the number into the high bits of ROUND.
+ This will let us efficiently handle round-to-nearest. */
+shift = -shift;
+if (shift < 63) {
+ret = frac >> shift;
+round = frac << (64 - shift);
+} else {
+/* The exponent is so small we shift out everything.
+ Leave a sticky bit for proper rounding below. */
+do_underflow:
+round = 1;
+}
-if (round) {
-switch (rounding_mode) {
-case float_round_nearest_even:
-if (round == (1ull << 63)) {
-/* Remaining fraction is exactly 0.5; round to even. */
-ret += (ret & 1);
-} else if (round > (1ull << 63)) {
-ret += 1;
+if (round) {
+
[Qemu-devel] [ANNOUNCE] SeaBIOS mailing list
There is now a mailing list for discussions on SeaBIOS. To join the mailing list, please visit: http://www.seabios.org/mailman/listinfo/seabios Mails can be sent to seab...@seabios.org. To reduce spam, non-member posts to the list will be moderated. -Kevin
Proper support for PCI-based option rom loading (was Re: [Qemu-devel] Re: qdev property bug?)
Michael S. Tsirkin wrote: On Mon, Dec 14, 2009 at 02:44:34PM -0600, Anthony Liguori wrote: Michael S. Tsirkin wrote: Or, we could have a very small ROM, that loads more actual code from card or from qemu directly when it is run. It's not as simple as it sounds but it's possible, in theory at least. But I think the question really is, what problem are we trying to solve? Support 256 devices on PCI bus seamlessly Okay, I think I've figured out how this is supposed to work. With these two patches to SeaBIOS and the patch to qemu, I can run: qemu -net nic,model=rtl8139 -net nic,model=virtio -net nic,model=e1000 -boot menu=on And all three option roms load. I can also select which NIC I want to boot from using the F12 menu. This works by not actually loading the option roms in the 1M space, but instead making them mappable through the PCI devices. With PMM and DDIM, the result is that we only have to copy in 2K for each option rom which means we can support up to 48 unique option roms. That should be plenty for now. These patches are very rough but I'll clean them up tomorrow. I'm not sure the best way to integrate with the rom infrastructure since we no longer have a physical address to map to. Any suggestions Gerd? Regards, Anthony Liguori 0001-Do-not-guard-qemu-shadow-ram-work-around-in-CONFIG_O.patch Description: application/mbox 0001-Support-PCI-based-option-rom-loading.patch Description: application/mbox 0002-Disable-CONFIG_OPTIONROMS_DEPLOYED-by-default.patch Description: application/mbox
Re: [Qemu-devel] [FOR 0.12][PATCH] target-i386: Fix evaluation of DR7 register
raise_exception() in op_helper.c should not be used outside op_helper.c because of tcg. This patch uses raise_exception2() instead of raise_exception(). target-i386-fix-raise_exception-for-hw-breakpoints.patch Description: Binary data
Re: [Qemu-devel] vmware vga + kvm interaction
On Tue, Dec 15, 2009 at 12:28 AM, Anthony Liguori wrote: > Dave Airlie wrote: >> >> I actually reinvented at least one of the patches locally and it >> didn't seem to help, >> but I'll try and take a closer look today, >> > > http://repo.or.cz/w/qemu/aliguori-queue.git vmware-vga-for-dave > > Is the local branch I have for vmware-vga work. I'm not sure why I never > pushed those patches, but I suspect it's because I was still tracking down a > bug. IIRC, this branch fixes things with -enable-kvm, but I'd usually see a > SEGV in qemu about 1-2 minutes after getting into X. I don't think that has > anything to do with kvm though. > Just to say me too, thats happening here alright, I just haven't had spare time to debug it yet. Dave.
[Qemu-devel] [PATCH] Fix TEXTREL in user targets when compiled with --enable-user-pie
We really need compile _all_ sources for user target with -fpie when use --enable-user-pie. It's regression introduced by commit add16157d72454. Please, do not break it any more. Signed-off-by: Kirill A. Shutemov Cc: Blue Swirl --- Makefile.user |4 ++-- configure |1 + 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/Makefile.user b/Makefile.user index 907e74b..0be73df 100644 --- a/Makefile.user +++ b/Makefile.user @@ -5,9 +5,9 @@ include $(SRC_PATH)/rules.mak .PHONY: all -VPATH=$(SRC_PATH) +vpath %.c $(SRC_PATH) -QEMU_CFLAGS+=-I.. +QEMU_CFLAGS+=-I$(SRC_PATH)/ $(CFLAGS_PIE) obj-y = obj-y += envlist.o path.o diff --git a/configure b/configure index 273b6b7..6200391 100755 --- a/configure +++ b/configure @@ -2555,6 +2555,7 @@ if test "$target_user_only" = "yes" -a "$static" = "no" -a \ "$user_pie" = "yes" ; then cflags="-fpie $cflags" ldflags="-pie $ldflags" + echo "CFLAGS_PIE=-fpie" >> $config_host_mak fi if test "$target_softmmu" = "yes" -a \( \ -- 1.6.5.6
Re: [Qemu-devel] target-alpha: An approach to fp insn qualifiers
On 12/14/2009 12:11 PM, Laurent Desnogues wrote:
I'll take a closer look at your patch tomorrow.
For the record, I believe this finishes what I had in mind for the
exception handling there in op_handler.c.
r~
commit ce6c2abc1d5d437dde980b4addc7da0f0f5de252
Author: Richard Henderson
Date: Mon Dec 14 16:27:39 2009 -0800
target-alpha: Implement arithmetic exceptions for IEEE fp.
diff --git a/target-alpha/cpu.h b/target-alpha/cpu.h
index c0dff4b..c1c0470 100644
--- a/target-alpha/cpu.h
+++ b/target-alpha/cpu.h
@@ -430,9 +430,13 @@ enum {
};
/* Arithmetic exception */
-enum {
-EXCP_ARITH_OVERFLOW,
-};
+#define EXC_M_IOV (1<<16) /* Integer Overflow */
+#define EXC_M_INE (1<<15) /* Inexact result */
+#define EXC_M_UNF (1<<14) /* Underflow */
+#define EXC_M_FOV (1<<13) /* Overflow */
+#define EXC_M_DZE (1<<12) /* Division by zero */
+#define EXC_M_INV (1<<11) /* Invalid operation */
+#define EXC_M_SWC (1<<10) /* Software completion */
enum {
IR_V0 = 0,
diff --git a/target-alpha/helper.c b/target-alpha/helper.c
index a658f97..a29f785 100644
--- a/target-alpha/helper.c
+++ b/target-alpha/helper.c
@@ -27,41 +27,13 @@
uint64_t cpu_alpha_load_fpcr (CPUState *env)
{
-uint64_t ret = 0;
-int flags, mask;
-
-flags = env->fp_status.float_exception_flags;
-ret |= (uint64_t) flags << 52;
-if (flags)
-ret |= FPCR_SUM;
-env->ipr[IPR_EXC_SUM] &= ~0x3E;
-env->ipr[IPR_EXC_SUM] |= flags << 1;
-
-mask = env->fp_status.float_exception_mask;
-if (mask & float_flag_invalid)
-ret |= FPCR_INVD;
-if (mask & float_flag_divbyzero)
-ret |= FPCR_DZED;
-if (mask & float_flag_overflow)
-ret |= FPCR_OVFD;
-if (mask & float_flag_underflow)
-ret |= FPCR_UNFD;
-if (mask & float_flag_inexact)
-ret |= FPCR_INED;
-
-switch (env->fp_status.float_rounding_mode) {
-case float_round_nearest_even:
-ret |= 2ULL << FPCR_DYN_SHIFT;
-break;
-case float_round_down:
-ret |= 1ULL << FPCR_DYN_SHIFT;
-break;
-case float_round_up:
-ret |= 3ULL << FPCR_DYN_SHIFT;
-break;
-case float_round_to_zero:
-break;
-}
+uint64_t ret = env->fp_status.float_exception_flags;
+
+if (ret)
+ ret = FPCR_SUM | (ret << 52);
+
+ret |= env->fpcr & ~(FPCR_SUM | FPCR_STATUS_MASK);
+
return ret;
}
@@ -69,6 +41,8 @@ void cpu_alpha_store_fpcr (CPUState *env, uint64_t val)
{
int round_mode, mask;
+env->fpcr = val;
+
set_float_exception_flags((val >> 52) & 0x3F, &env->fp_status);
mask = 0;
@@ -86,6 +60,7 @@ void cpu_alpha_store_fpcr (CPUState *env, uint64_t val)
switch ((val >> FPCR_DYN_SHIFT) & 3) {
case 0:
+default:
round_mode = float_round_to_zero;
break;
case 1:
@@ -99,6 +74,11 @@ void cpu_alpha_store_fpcr (CPUState *env, uint64_t val)
break;
}
set_float_rounding_mode(round_mode, &env->fp_status);
+
+mask = 0;
+if ((val & (FPCR_UNDZ|FPCR_UNFD)) == (FPCR_UNDZ|FPCR_UNFD))
+mask = 1;
+set_flush_to_zero(mask, &env->fp_status);
}
#if defined(CONFIG_USER_ONLY)
diff --git a/target-alpha/op_helper.c b/target-alpha/op_helper.c
index 3bb0020..d031f56 100644
--- a/target-alpha/op_helper.c
+++ b/target-alpha/op_helper.c
@@ -78,7 +78,7 @@ uint64_t helper_addqv (uint64_t op1, uint64_t op2)
uint64_t tmp = op1;
op1 += op2;
if (unlikely((tmp ^ op2 ^ (-1ULL)) & (tmp ^ op1) & (1ULL << 63))) {
-helper_excp(EXCP_ARITH, EXCP_ARITH_OVERFLOW);
+helper_excp(EXCP_ARITH, EXC_M_IOV);
}
return op1;
}
@@ -88,7 +88,7 @@ uint64_t helper_addlv (uint64_t op1, uint64_t op2)
uint64_t tmp = op1;
op1 = (uint32_t)(op1 + op2);
if (unlikely((tmp ^ op2 ^ (-1UL)) & (tmp ^ op1) & (1UL << 31))) {
-helper_excp(EXCP_ARITH, EXCP_ARITH_OVERFLOW);
+helper_excp(EXCP_ARITH, EXC_M_IOV);
}
return op1;
}
@@ -98,7 +98,7 @@ uint64_t helper_subqv (uint64_t op1, uint64_t op2)
uint64_t res;
res = op1 - op2;
if (unlikely((op1 ^ op2) & (res ^ op1) & (1ULL << 63))) {
-helper_excp(EXCP_ARITH, EXCP_ARITH_OVERFLOW);
+helper_excp(EXCP_ARITH, EXC_M_IOV);
}
return res;
}
@@ -108,7 +108,7 @@ uint64_t helper_sublv (uint64_t op1, uint64_t op2)
uint32_t res;
res = op1 - op2;
if (unlikely((op1 ^ op2) & (res ^ op1) & (1UL << 31))) {
-helper_excp(EXCP_ARITH, EXCP_ARITH_OVERFLOW);
+helper_excp(EXCP_ARITH, EXC_M_IOV);
}
return res;
}
@@ -118,7 +118,7 @@ uint64_t helper_mullv (uint64_t op1, uint64_t op2)
int64_t res = (int64_t)op1 * (int64_t)op2;
if (unlikely((int32_t)res != res)) {
-helper_excp(EXCP_ARITH, EXCP_ARITH_OVERFLOW);
+helper_excp(EXCP_ARITH, EXC_M_IOV);
}
return (int64_t)((int32_t)res);
}
@@ -130,7 +130,7 @@ uint64_t help
Re: [Qemu-devel] target-alpha: An approach to fp insn qualifiers
On 12/14/2009 12:11 PM, Laurent Desnogues wrote: I don't really like passing parts of opcodes to helpers, but as you say that prevents explosion of helpers. OTOH you could do lazy calls to helpers that set rounding modes with my approach of separating them from computation. I don't particularly like it either, I just thought it was a bit more efficient, given the current state of TCG. If it's not acceptable, I can try to do some macro magic in both op_helper.c and helper.h to do function replication on the /u,/su,/sui bits and then follow your lead on the lazy rounding mode setting. Can you give SPECint 2K equake a try? The symptom was the presence of many NaN's. If you don't have access to SPEC2K I'll try it. Yes, I can. I'll see about setting this up tonight. r~
Re: [Qemu-devel] Re: qdev property bug?
Anthony Liguori wrote: Sebastian Herbszt wrote: Anthony Liguori wrote: Michael S. Tsirkin wrote: On Mon, Dec 14, 2009 at 02:43:38PM -0600, Anthony Liguori wrote: Because it can be selected by the user via the menu and because it can be selected at runtime via the boot_set monitor command. Yes, but it's not like we have nowhere to store them. We could shadow ROM when it is actually needed. I believe the way this works with real BIOSes is that the rom is initially loaded somewhere outside of the 1M region and it's init is executed. It's then the rom's job to execute it's initialization. Afterwards, the bios copies the rom into the 1M region. This is how PMM works. The idea is that while outside of the 1M region, the rom can eliminate unnecessary code and update it's own header to reflect it's new, improved code size. It's more like the following (pci 2.2): - enable and map expansion rom bar - find rom and copy to ram (0xC000-0xD) - disable expansion rom bar - call rom init - rom might resize itself (DDIM) - write protect rom PMM doesn't have (anything?) to do with this and the rom doesn't have to be loaded outside of 1MB. Well PMM is used to do the resizing. You can shrink in-place with rom layout like [header, run-time code, init code]. The init code can then just be "truncated". You only need PMM if you can't manage with the allocated memory. But it sounds like the problem is that we should not be loading the roms into the rom space. Instead, seabios should be mapping them into that space, running the rom init, then moving to the next one. I suspect we need to either need to implement the proper pci interface for seabios to do this or we need to provide a pv channel. I suggested a proper pci interface before [1]; please no pv channel. [1] http://lists.gnu.org/archive/html/qemu-devel/2009-11/msg01823.html - Sebastian
[Qemu-devel] FreeBSD qemu-devel 0.12.0-rc2 port update available for testing
Hi! I updated my git head snapshot qemu-devel port update to 0.12.0-rc2 today (that was just announced: http://lists.gnu.org/archive/html/qemu-devel/2009-12/msg01514.html - the Subject says rc1 but in fact its rc2) so people can test that version on FreeBSD more easily: http://people.freebsd.org/~nox/qemu/qemu-devel-0.12.0-rc2.patch resp. http://people.freebsd.org/~nox/qemu/qemu-devel-0.12.0-rc2.shar (As mentioned before 0.11 was the last qemu branch that supported kqemu so this is probably only interesting for those FreeBSD users that want to emulate non-x86 guests or when performance doesn't matter. But the others are probably already moving to virtualbox now anyway... :) I have updated the FreeBSD pcap patch just enough so that it still runs (it probably will never be committed upstream anyway since Linux pcap doesn't have BIOCFEEDBACK i.e. can't talk to the host, only to other machines on the network) and I still see this weird issue here that packets `sometimes' are only processed with a delay (when the nic is otherwise idle?), i.e. pinging the host or another box on the lan with e.g. -i5 from the guest sees many packets with >5000ms roundtrip time. Can anyone else reproduce this or is that `just me'? This is on stable/8 now (amd64) but it also happened with earlier versions, tested with qemu 8.0-RELEASE-i386-dvd1.iso -m 256 -net nic,model=e1000 -net pcap,ifname=em0 via fixit->cdrom. And this is most likely pcap related, I don't see anything like it with tap networking. Cheers, Juergen
[Qemu-devel] [PATCH:] Fix a make -j race
Make libuser.a depend on $(GENERATED_HEADERS) too so make -j won't start building it before the headers exist. (There may be more bugs like this but at least this makes (g)make -j4 started from scratch on a quadcore now always complete here again.) Signed-off-by: Juergen Lock --- a/Makefile +++ b/Makefile @@ -79,7 +79,7 @@ $(filter %-softmmu,$(SUBDIR_RULES)): lib $(filter %-user,$(SUBDIR_RULES)): libuser.a -libuser.a: +libuser.a: $(GENERATED_HEADERS) $(call quiet-command,$(MAKE) $(SUBDIR_MAKEFLAGS) -C libuser V="$(V)" TARGET_DIR="libuser/" all,) ROMSUBDIR_RULES=$(patsubst %,romsubdir-%, $(ROMS))
[Qemu-devel] Re: [ANNOUNCE] qemu-kvm-0.12.0-rc2 released
On Mon, Dec 14, 2009 at 12:33 PM, Avi Kivity wrote: > qemu-kvm-0.12.0-rc2 is now available. This release is is based on the > upstream qemu 0.12.0-rc2, plus kvm-specific enhancements. Please see the > original qemu 0.12.0-rc2 release announcement for details. > > This release can be used with the kvm kernel modules provided by your > distribution kernel, or by the modules in the kvm-kmod package, such as > kvm-kmod-2.6.32. > > Please give test this release out so we can enjoy a stable 0.12.0 final > release. Hi Avi/Anthony- I'm working on the packaging updates for Ubuntu Lucid, and I'm having trouble with the BIOS bits of qemu-kvm. It seems that a fair amount of the BIOS submodules are missing. The roms/ tree is basically empty. I see some of the necessary bits in pc-bios/ and in kvm/vgabios/, but not enough here to build a usable qemu-kvm-0.12.0~rc2 package yet. :-Dustin
Re: [Qemu-devel] Re: qdev property bug?
Sebastian Herbszt wrote: Anthony Liguori wrote: Michael S. Tsirkin wrote: On Mon, Dec 14, 2009 at 02:43:38PM -0600, Anthony Liguori wrote: Because it can be selected by the user via the menu and because it can be selected at runtime via the boot_set monitor command. Yes, but it's not like we have nowhere to store them. We could shadow ROM when it is actually needed. I believe the way this works with real BIOSes is that the rom is initially loaded somewhere outside of the 1M region and it's init is executed. It's then the rom's job to execute it's initialization. Afterwards, the bios copies the rom into the 1M region. This is how PMM works. The idea is that while outside of the 1M region, the rom can eliminate unnecessary code and update it's own header to reflect it's new, improved code size. It's more like the following (pci 2.2): - enable and map expansion rom bar - find rom and copy to ram (0xC000-0xD) - disable expansion rom bar - call rom init - rom might resize itself (DDIM) - write protect rom PMM doesn't have (anything?) to do with this and the rom doesn't have to be loaded outside of 1MB. Well PMM is used to do the resizing. But it sounds like the problem is that we should not be loading the roms into the rom space. Instead, seabios should be mapping them into that space, running the rom init, then moving to the next one. I suspect we need to either need to implement the proper pci interface for seabios to do this or we need to provide a pv channel. Regards, Anthony Liguori
Re: [Qemu-devel] cpuid problem in upstream qemu with kvm
Michael S. Tsirkin wrote: On Mon, Dec 14, 2009 at 02:54:49PM -0600, Anthony Liguori wrote: Michael S. Tsirkin wrote: On Mon, Dec 14, 2009 at 02:18:33PM -0600, Anthony Liguori wrote: Michael S. Tsirkin wrote: This might help 32 bit guests, but not guests with 64 bit kernel and 32 bit userspace (my case) because all 64 bit CPUs advertise syscall bit in cpuid. Thus 64 bit guests do not seem to even bother checking this bit: AMD + 64 bit -> syscall. Okay, I don't see a great option other than migrating the vendor_id string. This won't help with kernels <2.6.32 though. I guess we can switch default vendor to Intel, this likely has some other side effects. That's a kernel bug. If we think it effects a lot of users, we should introduce a CAP such that we can detect this in userspace and fail gracefully. Not emulating feature host CPU does not have is a kernel bug? Okay ... Yes, almost no one runs 2.6.32 yet. The kernel has the ability to filter feature bits from cpuid. We assume it's going to filter out things it doesn't support. Regards, Anthony Liguori
Re: [Qemu-devel] Re: qdev property bug?
Anthony Liguori wrote: Michael S. Tsirkin wrote: On Mon, Dec 14, 2009 at 02:43:38PM -0600, Anthony Liguori wrote: Because it can be selected by the user via the menu and because it can be selected at runtime via the boot_set monitor command. Yes, but it's not like we have nowhere to store them. We could shadow ROM when it is actually needed. I believe the way this works with real BIOSes is that the rom is initially loaded somewhere outside of the 1M region and it's init is executed. It's then the rom's job to execute it's initialization. Afterwards, the bios copies the rom into the 1M region. This is how PMM works. The idea is that while outside of the 1M region, the rom can eliminate unnecessary code and update it's own header to reflect it's new, improved code size. It's more like the following (pci 2.2): - enable and map expansion rom bar - find rom and copy to ram (0xC000-0xD) - disable expansion rom bar - call rom init - rom might resize itself (DDIM) - write protect rom PMM doesn't have (anything?) to do with this and the rom doesn't have to be loaded outside of 1MB. I don't know whether gpxe will actually reduce it's size as part of this process so it may not matter. After running the option roms init vector, the rom must be relocated into the option rom space though so even this technique is not a solution unless gpxe is able to discard a lot of bits it doesn't need. gPXE supports DDIM. Also, the comment about "wasting memory" not quite accurate. The memory region in question is only used for roms. If we didn't put roms there, it would go to waste. Some BIOSes I saw have an option not to use the first 1M for rom shadowing :). Seriously as you see we are already running out of that 1M. I think that's just the first phase of rom loading. - Sebastian
Re: [Qemu-devel] [PATCH 09/11] Cocoa: Shutdown when window is closed
Hi,
Am 14.12.2009 um 08:04 schrieb >:
On Dec 13, 2009, at 04:55, ext Andreas Färber wrote:
The application is not very useful once the guest window is closed.
QEMU is not a document-based application; terminating it
automatically
saves the user another action and resembles SDL behavior.
Signed-off-by: Andreas Färber
Cc: Mike Kronenberg
Cc: Alexander Graf
---
cocoa.m |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/cocoa.m b/cocoa.m
index 70c249b..09ed3cd 100644
--- a/cocoa.m
+++ b/cocoa.m
@@ -835,6 +837,11 @@ static int cocoa_keycode_to_qemu(int keycode)
[[NSWorkspace sharedWorkspace] openFile:[NSString
stringWithFormat:@"%@/../doc/qemu/qemu-tech.html",
[[NSBundle mainBundle] resourcePath]] withApplication:@"Help
Viewer"];
}
+
+- (void)windowWillClose:(NSNotification *)notification
+{
+ [NSApp terminate:self];
+}
@end
Another way to achieve the same thing is to instead of the above
changes just introduce a new method for the QemuCocoaAppController
like:
- (BOOL)applicationShouldTerminateAfterLastWindowClosed:
(NSApplication *)theApplication
{
return YES;
}
That's ingenious. I had searched for something like this, but around
NSWindow... thanks!
Any other comments? Would you like to add an SoB to the now four
patches proposed by you?
Regards,
Andreas
[Qemu-devel] [PATCH v2 09/11] Cocoa: Shutdown when window is closed
The application is not very useful once the guest window is closed.
QEMU is not a document-based application; terminating it automatically
saves the user another action and resembles SDL behavior.
v2:
- Use delegate method, suggested by Juha Riihimäki.
Signed-off-by: Andreas Färber
Cc: Juha Riihimäki
---
cocoa.m |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/cocoa.m b/cocoa.m
index 70c249b..57dcff8 100644
--- a/cocoa.m
+++ b/cocoa.m
@@ -783,6 +783,11 @@ static int cocoa_keycode_to_qemu(int keycode)
exit(0);
}
+- (BOOL)applicationShouldTerminateAfterLastWindowClosed:(NSApplication
*)theApplication
+{
+return YES;
+}
+
- (void)startEmulationWithArgc:(int)argc argv:(char**)argv
{
COCOA_DEBUG("QemuCocoaAppController: startEmulationWithArgc\n");
--
1.6.5.3
Re: [Qemu-devel] Re: [PATCH RFC] virtio: add features qdev property
On 12/14/09 22:14, Michael S. Tsirkin wrote: On Mon, Dec 14, 2009 at 10:12:14PM +0100, Gerd Hoffmann wrote: On 12/14/09 21:43, Michael S. Tsirkin wrote: What do we put in e.g. 0.11 compat? Any features we enable there might not be supported by host. compat properties as usual? Sorry, I still fail to see your problem. You'll have a 'disable' bitmap. Fill it via 'features='. Or using separate properties for each feature. qemu goes figure host_features. When done it masks out the features disabled via properties. The result is used as final feature bitmap. -M pc-0.11 will disable hw_checksum management software can do it too via -device virtio-net-pci,... if some machines in the pool don't support it. And of course qemu will disable it on its own in case the host kernel doesn't support it. cheers, Gerd management is always behind :). Imagine a new and improved qemu. I run old management. I expect to see old properties, but old management can not disable new ones :) If management can't deal with 0.12 features it should use -M pc-0.11 cheers, Gerd
Re: [Qemu-devel] Re: [PATCH RFC] virtio: add features qdev property
On Mon, Dec 14, 2009 at 10:12:14PM +0100, Gerd Hoffmann wrote: > On 12/14/09 21:43, Michael S. Tsirkin wrote: >> What do we put in e.g. 0.11 compat? Any features we enable >> there might not be supported by host. > > compat properties as usual? > > Sorry, I still fail to see your problem. > > You'll have a 'disable' bitmap. Fill it via 'features='. > Or using separate properties for each feature. > qemu goes figure host_features. When done it masks out the features > disabled via properties. The result is used as final feature bitmap. > > -M pc-0.11 will disable hw_checksum > management software can do it too via -device virtio-net-pci,... if some > machines in the pool don't support it. And of course qemu will disable > it on its own in case the host kernel doesn't support it. > > cheers, > Gerd management is always behind :). Imagine a new and improved qemu. I run old management. I expect to see old properties, but old management can not disable new ones :) -- MST
Re: [Qemu-devel] cpuid problem in upstream qemu with kvm
On Mon, Dec 14, 2009 at 02:54:49PM -0600, Anthony Liguori wrote: > Michael S. Tsirkin wrote: >> On Mon, Dec 14, 2009 at 02:18:33PM -0600, Anthony Liguori wrote: >> >>> Michael S. Tsirkin wrote: >>> This might help 32 bit guests, but not guests with 64 bit kernel and 32 bit userspace (my case) because all 64 bit CPUs advertise syscall bit in cpuid. Thus 64 bit guests do not seem to even bother checking this bit: AMD + 64 bit -> syscall. >>> Okay, I don't see a great option other than migrating the vendor_id string. >>> >> >> This won't help with kernels <2.6.32 though. I guess we can switch >> default vendor to Intel, this likely has some other side effects. >> > > That's a kernel bug. If we think it effects a lot of users, we should > introduce a CAP such that we can detect this in userspace and fail > gracefully. Not emulating feature host CPU does not have is a kernel bug? Okay ... Yes, almost no one runs 2.6.32 yet. >>> Otherwise, cross vendor migration will not work by default. Maybe >>> that's not a problem but if so, we really should change the default >>> cpu model to be much more aggressive about exposing host features. >>> >> It's a tradeoff, but yes. We also need more sanity checks and >> management commands giving management tools to understand whether >> emulating guest CPU X on host CPU Y is safe/possible, and which guests >> this might break. >> > > I'd like to see Avi weigh in as historically, he's been one of the > strongest advocates of a default migration policy of maximum > compatibility. Personally, I think cross vendor migration is extremely > uncommon in production and I would strongly recommend against it. > > My own experience has been that hardware homogeneity is pretty common in > deployments, particularly in the processor space. There's such a > different between Nehalem and non-Nehalem class processors that you > really can't run the same workloads across the two without seeing a > significant impact. > > So I'd actually be in favor of changing the default cpu to something > that exposes a lot more of the underlying processor features. I think > increased performance would be better for most consumers vs. increased > migration flexibility. > > Then again, I'm certainly bias based on being employed by a hardware > vendor :-) > > Regards, > > Anthony Liguori
Re: [Qemu-devel] Re: [PATCH RFC] virtio: add features qdev property
On 12/14/09 21:43, Michael S. Tsirkin wrote: What do we put in e.g. 0.11 compat? Any features we enable there might not be supported by host. compat properties as usual? Sorry, I still fail to see your problem. You'll have a 'disable' bitmap. Fill it via 'features='. Or using separate properties for each feature. qemu goes figure host_features. When done it masks out the features disabled via properties. The result is used as final feature bitmap. -M pc-0.11 will disable hw_checksum management software can do it too via -device virtio-net-pci,... if some machines in the pool don't support it. And of course qemu will disable it on its own in case the host kernel doesn't support it. cheers, Gerd
Re: [Qemu-devel] Re: qdev property bug?
Michael S. Tsirkin wrote: On Mon, Dec 14, 2009 at 02:43:38PM -0600, Anthony Liguori wrote: Because it can be selected by the user via the menu and because it can be selected at runtime via the boot_set monitor command. Yes, but it's not like we have nowhere to store them. We could shadow ROM when it is actually needed. I believe the way this works with real BIOSes is that the rom is initially loaded somewhere outside of the 1M region and it's init is executed. It's then the rom's job to execute it's initialization. Afterwards, the bios copies the rom into the 1M region. This is how PMM works. The idea is that while outside of the 1M region, the rom can eliminate unnecessary code and update it's own header to reflect it's new, improved code size. I don't know whether gpxe will actually reduce it's size as part of this process so it may not matter. After running the option roms init vector, the rom must be relocated into the option rom space though so even this technique is not a solution unless gpxe is able to discard a lot of bits it doesn't need. Also, the comment about "wasting memory" not quite accurate. The memory region in question is only used for roms. If we didn't put roms there, it would go to waste. Some BIOSes I saw have an option not to use the first 1M for rom shadowing :). Seriously as you see we are already running out of that 1M. I think that's just the first phase of rom loading. Currently, the only roms we load are pxe roms or things specified by -option-rom. You could certainly argue that making -option-rom higher priority than implicit pxe roms is valuable but removing the pxe roms really serves no purpose. Regards, Anthony Liguori I am concerned about management. User selects "PXE support" when creating VM, and creationg succeeds, but in fact PXE can not work because we can not shadow the ROM. Sounds bad. If device creation failed, user would get feedback when it is expected. It's unfortunately much more complicated than this :-/ Ignore the case of one nic, that should Just Work today. If you have two nics, even if we are able to load both roms, we have no way of communicating to the bios that we want to use one BEV device vs. another. That means if you have two nics that are both capable of pxe booting, '-boot n' really cannot be used to determine which one actually gets to pxe boot. We'll have the same problem with BCV based extboot. We really need to improve -boot to support things other than the concept of "first disk" and "first nic". That's why I'm a fan of the intermediate solution of just stopping loading roms when we run out of room. It's just as well defined behavior as we have even if we could load more roms. Regards, Anthony Liguori
Re: [Qemu-devel] Re: qdev property bug?
Sebastian Herbszt wrote: Some DOS-based software might need the UMA (RAM UMB). I don't think that's the workload to optimize for in terms of the default settings. Certainly, it's important to allow such workloads to disable all unnecessary rom loading but I don't think it's justification for default settings. - Sebastian Regards, Anthony Liguori
Re: [Qemu-devel] cpuid problem in upstream qemu with kvm
Michael S. Tsirkin wrote: On Mon, Dec 14, 2009 at 02:18:33PM -0600, Anthony Liguori wrote: Michael S. Tsirkin wrote: This might help 32 bit guests, but not guests with 64 bit kernel and 32 bit userspace (my case) because all 64 bit CPUs advertise syscall bit in cpuid. Thus 64 bit guests do not seem to even bother checking this bit: AMD + 64 bit -> syscall. Okay, I don't see a great option other than migrating the vendor_id string. This won't help with kernels <2.6.32 though. I guess we can switch default vendor to Intel, this likely has some other side effects. That's a kernel bug. If we think it effects a lot of users, we should introduce a CAP such that we can detect this in userspace and fail gracefully. Otherwise, cross vendor migration will not work by default. Maybe that's not a problem but if so, we really should change the default cpu model to be much more aggressive about exposing host features. It's a tradeoff, but yes. We also need more sanity checks and management commands giving management tools to understand whether emulating guest CPU X on host CPU Y is safe/possible, and which guests this might break. I'd like to see Avi weigh in as historically, he's been one of the strongest advocates of a default migration policy of maximum compatibility. Personally, I think cross vendor migration is extremely uncommon in production and I would strongly recommend against it. My own experience has been that hardware homogeneity is pretty common in deployments, particularly in the processor space. There's such a different between Nehalem and non-Nehalem class processors that you really can't run the same workloads across the two without seeing a significant impact. So I'd actually be in favor of changing the default cpu to something that exposes a lot more of the underlying processor features. I think increased performance would be better for most consumers vs. increased migration flexibility. Then again, I'm certainly bias based on being employed by a hardware vendor :-) Regards, Anthony Liguori
Re: [Qemu-devel] Re: qdev property bug?
On Mon, Dec 14, 2009 at 02:44:34PM -0600, Anthony Liguori wrote: > Michael S. Tsirkin wrote: >> Or, we could have a very small ROM, that loads >> more actual code from card or from qemu directly >> when it is run. >> > > It's not as simple as it sounds but it's possible, in theory at least. > > But I think the question really is, what problem are we trying to solve? Support 256 devices on PCI bus seamlessly. > Regards, > > Anthony Liguori
[Qemu-devel] [PATCH 5/5] monitor: Catch printing to non-existent monitor
The monitor_vprintf() function now touches the 'mon' pointer
before calling monitor_puts(), this causes block migration
to segfault as its functions call monitor_printf() with a
NULL 'mon'.
To fix the problem this commit moves the 'mon' NULL check
from monitor_puts() to monitor_vprintf().
This can potentially hide bugs, but for some reason this has
been the behavior for a long time.
Signed-off-by: Luiz Capitulino
---
monitor.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/monitor.c b/monitor.c
index b518cc4..ebd0282 100644
--- a/monitor.c
+++ b/monitor.c
@@ -177,9 +177,6 @@ static void monitor_puts(Monitor *mon, const char *str)
{
char c;
-if (!mon)
-return;
-
for(;;) {
c = *str++;
if (c == '\0')
@@ -195,6 +192,9 @@ static void monitor_puts(Monitor *mon, const char *str)
void monitor_vprintf(Monitor *mon, const char *fmt, va_list ap)
{
+if (!mon)
+return;
+
if (mon->mc && !mon->mc->print_enabled) {
qemu_error_new(QERR_UNDEFINED_ERROR);
} else {
--
1.6.6.rc2.5.g49666
[Qemu-devel] [PATCH 4/5] monitor: Avoid readline functions in QMP
The monitor_read_command() function is readline specific
and should only be used when readline is available.
Signed-off-by: Luiz Capitulino
---
monitor.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/monitor.c b/monitor.c
index 920ccff..b518cc4 100644
--- a/monitor.c
+++ b/monitor.c
@@ -140,6 +140,9 @@ static inline int monitor_ctrl_mode(const Monitor *mon)
static void monitor_read_command(Monitor *mon, int show_prompt)
{
+if (!mon->rs)
+return;
+
readline_start(mon->rs, "(qemu) ", 0, monitor_command_cb, NULL);
if (show_prompt)
readline_show_prompt(mon->rs);
--
1.6.6.rc2.5.g49666
[Qemu-devel] [PATCH 3/5] monitor: do_balloon(): Check for errors
do_balloon() should check for ballooning availability as
do_info_balloon() does.
Noted by Daniel P. Berrange .
Signed-off-by: Luiz Capitulino
---
monitor.c | 35 ++-
1 files changed, 26 insertions(+), 9 deletions(-)
diff --git a/monitor.c b/monitor.c
index d5041dc..920ccff 100644
--- a/monitor.c
+++ b/monitor.c
@@ -2053,14 +2053,34 @@ static void do_info_status(Monitor *mon, QObject
**ret_data)
vm_running, singlestep);
}
+static ram_addr_t balloon_get_value(void)
+{
+ram_addr_t actual;
+
+if (kvm_enabled() && !kvm_has_sync_mmu()) {
+qemu_error_new(QERR_KVM_MISSING_CAP, "synchronous MMU", "balloon");
+return 0;
+}
+
+actual = qemu_balloon_status();
+if (actual == 0) {
+qemu_error_new(QERR_DEVICE_NOT_ACTIVE, "balloon");
+return 0;
+}
+
+return actual;
+}
+
/**
* do_balloon(): Request VM to change its memory allocation
*/
static void do_balloon(Monitor *mon, const QDict *qdict, QObject **ret_data)
{
-int value = qdict_get_int(qdict, "value");
-ram_addr_t target = value;
-qemu_balloon(target << 20);
+if (balloon_get_value()) {
+/* ballooning is active */
+ram_addr_t value = qdict_get_int(qdict, "value");
+qemu_balloon(value << 20);
+}
}
static void monitor_print_balloon(Monitor *mon, const QObject *data)
@@ -2088,14 +2108,11 @@ static void do_info_balloon(Monitor *mon, QObject
**ret_data)
{
ram_addr_t actual;
-actual = qemu_balloon_status();
-if (kvm_enabled() && !kvm_has_sync_mmu())
-qemu_error_new(QERR_KVM_MISSING_CAP, "synchronous MMU", "balloon");
-else if (actual == 0)
-qemu_error_new(QERR_DEVICE_NOT_ACTIVE, "balloon");
-else
+actual = balloon_get_value();
+if (actual != 0) {
*ret_data = qobject_from_jsonf("{ 'balloon': %" PRId64 "}",
(int64_t) actual);
+}
}
static qemu_acl *find_acl(Monitor *mon, const char *name)
--
1.6.6.rc2.5.g49666
[Qemu-devel] [PATCH 2/5] monitor: Use 'device' in eject
Monitor's eject command uses 'filename' for the device name
argument, but 'device' is a better name.
Signed-off-by: Luiz Capitulino
---
monitor.c |2 +-
qemu-monitor.hx |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/monitor.c b/monitor.c
index d97d529..d5041dc 100644
--- a/monitor.c
+++ b/monitor.c
@@ -864,7 +864,7 @@ static void do_eject(Monitor *mon, const QDict *qdict,
QObject **ret_data)
{
BlockDriverState *bs;
int force = qdict_get_int(qdict, "force");
-const char *filename = qdict_get_str(qdict, "filename");
+const char *filename = qdict_get_str(qdict, "device");
bs = bdrv_find(filename);
if (!bs) {
diff --git a/qemu-monitor.hx b/qemu-monitor.hx
index c788c73..338e30e 100644
--- a/qemu-monitor.hx
+++ b/qemu-monitor.hx
@@ -130,7 +130,7 @@ ETEXI
{
.name = "eject",
-.args_type = "force:-f,filename:B",
+.args_type = "force:-f,device:B",
.params = "[-f] device",
.help = "eject a removable medium (use -f to force it)",
.user_print = monitor_user_noop,
--
1.6.6.rc2.5.g49666
[Qemu-devel] [PATCH 1/5] QDict: Fix size update
Key replacement should not update the dictionary's size. This commit also adds a test for the bug. Signed-off-by: Luiz Capitulino --- check-qdict.c |2 ++ qdict.c |3 +-- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/check-qdict.c b/check-qdict.c index c37d448..f2b4826 100644 --- a/check-qdict.c +++ b/check-qdict.c @@ -205,6 +205,8 @@ START_TEST(qdict_put_exists_test) value = qdict_get_int(tests_dict, key); fail_unless(value == 2); + +fail_unless(qdict_size(tests_dict) == 1); } END_TEST diff --git a/qdict.c b/qdict.c index ef73265..ba8eef0 100644 --- a/qdict.c +++ b/qdict.c @@ -122,9 +122,8 @@ void qdict_put_obj(QDict *qdict, const char *key, QObject *value) /* allocate a new entry */ entry = alloc_entry(key, value); QLIST_INSERT_HEAD(&qdict->table[hash], entry, next); +qdict->size++; } - -qdict->size++; } /** -- 1.6.6.rc2.5.g49666
[Qemu-devel] [FOR 0.12 0/5]: Misc QMP related fixes
This small series contains some QMP related fixes. Thanks.
Re: [Qemu-devel] Re: qdev property bug?
On Mon, Dec 14, 2009 at 02:43:38PM -0600, Anthony Liguori wrote: > Michael S. Tsirkin wrote: >> On Mon, Dec 14, 2009 at 09:32:30PM +0100, Gerd Hoffmann wrote: >> >>> On 12/14/09 21:20, Michael S. Tsirkin wrote: >>> > So far, it's not clear to me that anyone has demonstrated how this is > harmful for people that don't want pxe booting. Assuming we fix the bug > about rom loading, then there's really no impact to users. > >>> Fix (v2) is on the list already. >>> >>> PXE booting might have security impact. You do not want to do this if you are on a hostile network. >>> Option rom loaded doesn't imply pxe boot will be tried. It only >>> means PXE boot can be selected, either via >>> >>> -boot order=[something with 'n' here] >>> >>> or via >>> >>> -boot menu=on + F12 + picking menu entry >>> >>> By default qemu doesn't try to PXE-boot, even if no other bootable >>> device is available. >>> >>> cheers, >>> Gerd >>> >> >> I guess so. But then, why are we loading it in BIOS >> and wasting memory? Let's only shadow the ROM >> when PXE is selected? >> > > Because it can be selected by the user via the menu and because it can > be selected at runtime via the boot_set monitor command. Yes, but it's not like we have nowhere to store them. We could shadow ROM when it is actually needed. > Also, the comment about "wasting memory" not quite accurate. The memory > region in question is only used for roms. If we didn't put roms there, > it would go to waste. Some BIOSes I saw have an option not to use the first 1M for rom shadowing :). Seriously as you see we are already running out of that 1M. > Currently, the only roms we load are pxe roms or things specified by > -option-rom. You could certainly argue that making -option-rom higher > priority than implicit pxe roms is valuable but removing the pxe roms > really serves no purpose. > > Regards, > > Anthony Liguori I am concerned about management. User selects "PXE support" when creating VM, and creationg succeeds, but in fact PXE can not work because we can not shadow the ROM. Sounds bad. If device creation failed, user would get feedback when it is expected. -- MST
Re: [Qemu-devel] Re: qdev property bug?
Michael S. Tsirkin wrote: On Mon, Dec 14, 2009 at 09:32:30PM +0100, Gerd Hoffmann wrote: On 12/14/09 21:20, Michael S. Tsirkin wrote: So far, it's not clear to me that anyone has demonstrated how this is harmful for people that don't want pxe booting. Assuming we fix the bug about rom loading, then there's really no impact to users. Fix (v2) is on the list already. PXE booting might have security impact. You do not want to do this if you are on a hostile network. Option rom loaded doesn't imply pxe boot will be tried. It only means PXE boot can be selected, either via -boot order=[something with 'n' here] or via -boot menu=on + F12 + picking menu entry By default qemu doesn't try to PXE-boot, even if no other bootable device is available. cheers, Gerd I guess so. But then, why are we loading it in BIOS and wasting memory? Let's only shadow the ROM when PXE is selected? Some DOS-based software might need the UMA (RAM UMB). - Sebastian
Re: [Qemu-devel] Re: [PATCH RFC] virtio: add features qdev property
On Mon, Dec 14, 2009 at 09:40:28PM +0100, Gerd Hoffmann wrote: > On 12/14/09 20:17, Michael S. Tsirkin wrote: >> On Mon, Dec 14, 2009 at 06:18:29PM +0100, Gerd Hoffmann wrote: >>> On 12/14/09 17:23, Michael S. Tsirkin wrote: On Mon, Dec 14, 2009 at 04:01:33PM +0100, Gerd Hoffmann wrote: So how do you do this? Assume we have -disable_hw_csum. We want new machine type to have it off, right? But now you run qemu on host which does not support hw_csum. With your suggestion it will not enable hw csum? >>> >>> I have trouble getting the setup you are talking about ... >>> >>> Sounds like hw_csum could be enabled/disabled depending on the hardware >>> capabilities on the host. Is that correct? >>> >>> cheers, >>>Gerd >> >> This currently depends on version of tun driver in the host. > > So this has nothing to do with -M pc-0.11 backward compatibility, right? Yes, this does. With 0.11 you must not expose this even if supported by host. Otherwise you wnt be able to migrate to 0.11. > You'll hit this when migrating 0.12 -> 0.12 with different host > kernels, right? And the common bit here is that both issues can be > handled by configuring virtio feature bits via properties, right? Yes. > What was the question again? > > cheers, > Gerd What do we put in e.g. 0.11 compat? Any features we enable there might not be supported by host. -- MST
Re: [Qemu-devel] Re: qdev property bug?
Michael S. Tsirkin wrote: Or, we could have a very small ROM, that loads more actual code from card or from qemu directly when it is run. It's not as simple as it sounds but it's possible, in theory at least. But I think the question really is, what problem are we trying to solve? Regards, Anthony Liguori
Re: [Qemu-devel] Re: qdev property bug?
Michael S. Tsirkin wrote: On Mon, Dec 14, 2009 at 09:32:30PM +0100, Gerd Hoffmann wrote: On 12/14/09 21:20, Michael S. Tsirkin wrote: So far, it's not clear to me that anyone has demonstrated how this is harmful for people that don't want pxe booting. Assuming we fix the bug about rom loading, then there's really no impact to users. Fix (v2) is on the list already. PXE booting might have security impact. You do not want to do this if you are on a hostile network. Option rom loaded doesn't imply pxe boot will be tried. It only means PXE boot can be selected, either via -boot order=[something with 'n' here] or via -boot menu=on + F12 + picking menu entry By default qemu doesn't try to PXE-boot, even if no other bootable device is available. cheers, Gerd I guess so. But then, why are we loading it in BIOS and wasting memory? Let's only shadow the ROM when PXE is selected? Because it can be selected by the user via the menu and because it can be selected at runtime via the boot_set monitor command. Also, the comment about "wasting memory" not quite accurate. The memory region in question is only used for roms. If we didn't put roms there, it would go to waste. Currently, the only roms we load are pxe roms or things specified by -option-rom. You could certainly argue that making -option-rom higher priority than implicit pxe roms is valuable but removing the pxe roms really serves no purpose. Regards, Anthony Liguori
[Qemu-devel] Re: [PATCH RFC] virtio: add features qdev property
-device 'virtio-blk-pci,disable=blk-identify|ring-indirect' The driver will just do 'vdev->host_features&= ~disable'. cheers, Gerd Is there an example of an existing property that is like this? No. A new property type is needed for this. cheers, Gerd
Re: [Qemu-devel] Re: [PATCH RFC] virtio: add features qdev property
On 12/14/09 20:17, Michael S. Tsirkin wrote: On Mon, Dec 14, 2009 at 06:18:29PM +0100, Gerd Hoffmann wrote: On 12/14/09 17:23, Michael S. Tsirkin wrote: On Mon, Dec 14, 2009 at 04:01:33PM +0100, Gerd Hoffmann wrote: So how do you do this? Assume we have -disable_hw_csum. We want new machine type to have it off, right? But now you run qemu on host which does not support hw_csum. With your suggestion it will not enable hw csum? I have trouble getting the setup you are talking about ... Sounds like hw_csum could be enabled/disabled depending on the hardware capabilities on the host. Is that correct? cheers, Gerd This currently depends on version of tun driver in the host. So this has nothing to do with -M pc-0.11 backward compatibility, right? You'll hit this when migrating 0.12 -> 0.12 with different host kernels, right? And the common bit here is that both issues can be handled by configuring virtio feature bits via properties, right? What was the question again? cheers, Gerd
Re: [Qemu-devel] Re: qdev property bug?
Gerd Hoffmann wrote: On 12/14/09 21:20, Michael S. Tsirkin wrote: So far, it's not clear to me that anyone has demonstrated how this is harmful for people that don't want pxe booting. Assuming we fix the bug about rom loading, then there's really no impact to users. Fix (v2) is on the list already. PXE booting might have security impact. You do not want to do this if you are on a hostile network. Option rom loaded doesn't imply pxe boot will be tried. It only means PXE boot can be selected, either via -boot order=[something with 'n' here] or via -boot menu=on + F12 + picking menu entry By default qemu doesn't try to PXE-boot, even if no other bootable device is available. Tho this depends on the option rom, e.g. Etherboot hooks INT 19h. - Sebastian
Re: [Qemu-devel] Re: qdev property bug?
On Mon, Dec 14, 2009 at 10:34:28PM +0200, Michael S. Tsirkin wrote: > On Mon, Dec 14, 2009 at 09:32:30PM +0100, Gerd Hoffmann wrote: > > On 12/14/09 21:20, Michael S. Tsirkin wrote: > >>> So far, it's not clear to me that anyone has demonstrated how this is > >>> harmful for people that don't want pxe booting. Assuming we fix the bug > >>> about rom loading, then there's really no impact to users. > > > > Fix (v2) is on the list already. > > > >> PXE booting might have security impact. You do not want to > >> do this if you are on a hostile network. > > > > Option rom loaded doesn't imply pxe boot will be tried. It only means > > PXE boot can be selected, either via > > > > -boot order=[something with 'n' here] > > > > or via > > > > -boot menu=on + F12 + picking menu entry > > > > By default qemu doesn't try to PXE-boot, even if no other bootable > > device is available. > > > > cheers, > > Gerd > > I guess so. But then, why are we loading it in BIOS > and wasting memory? Let's only shadow the ROM > when PXE is selected? Or, we could have a very small ROM, that loads more actual code from card or from qemu directly when it is run. > > -- > MST
Re: [Qemu-devel] Re: qdev property bug?
On Mon, Dec 14, 2009 at 09:32:30PM +0100, Gerd Hoffmann wrote: > On 12/14/09 21:20, Michael S. Tsirkin wrote: >>> So far, it's not clear to me that anyone has demonstrated how this is >>> harmful for people that don't want pxe booting. Assuming we fix the bug >>> about rom loading, then there's really no impact to users. > > Fix (v2) is on the list already. > >> PXE booting might have security impact. You do not want to >> do this if you are on a hostile network. > > Option rom loaded doesn't imply pxe boot will be tried. It only means > PXE boot can be selected, either via > > -boot order=[something with 'n' here] > > or via > > -boot menu=on + F12 + picking menu entry > > By default qemu doesn't try to PXE-boot, even if no other bootable > device is available. > > cheers, > Gerd I guess so. But then, why are we loading it in BIOS and wasting memory? Let's only shadow the ROM when PXE is selected? -- MST
Re: [Qemu-devel] cpuid problem in upstream qemu with kvm
On Mon, Dec 14, 2009 at 02:18:33PM -0600, Anthony Liguori wrote: > Michael S. Tsirkin wrote: >> This might help 32 bit guests, but not guests with 64 bit >> kernel and 32 bit userspace (my case) because all 64 bit >> CPUs advertise syscall bit in cpuid. Thus 64 bit guests >> do not seem to even bother checking this bit: >> AMD + 64 bit -> syscall. >> > > Okay, I don't see a great option other than migrating the vendor_id string. This won't help with kernels <2.6.32 though. I guess we can switch default vendor to Intel, this likely has some other side effects. > Otherwise, cross vendor migration will not work by default. Maybe > that's not a problem but if so, we really should change the default cpu > model to be much more aggressive about exposing host features. > > Regards, > > Anthony Liguori It's a tradeoff, but yes. We also need more sanity checks and management commands giving management tools to understand whether emulating guest CPU X on host CPU Y is safe/possible, and which guests this might break. -- MST
Re: [Qemu-devel] Re: qdev property bug?
On 12/14/09 21:20, Michael S. Tsirkin wrote: So far, it's not clear to me that anyone has demonstrated how this is harmful for people that don't want pxe booting. Assuming we fix the bug about rom loading, then there's really no impact to users. Fix (v2) is on the list already. PXE booting might have security impact. You do not want to do this if you are on a hostile network. Option rom loaded doesn't imply pxe boot will be tried. It only means PXE boot can be selected, either via -boot order=[something with 'n' here] or via -boot menu=on + F12 + picking menu entry By default qemu doesn't try to PXE-boot, even if no other bootable device is available. cheers, Gerd
Re: [Qemu-devel] Re: qdev property bug?
On Mon, Dec 14, 2009 at 01:59:47PM -0600, Anthony Liguori wrote: > Michael S. Tsirkin wrote: >> At some level this is wrong. ROM presence is a hardware feature and you >> definitely need to select your hardware when you create a VM. For real >> hardware, cards with PXE are sometimes more expensive than without as >> they need ROM memory. People do select hardware based on this. >> >> Even when PXE is present in hardware, most BIOS >> vendors will let you turn it on/off optionally, >> for security if not for other reasons. >> >> What the default should be depends on whether the >> majority of our users use PXE. I guess not, >> and if I am right default should be off. >> > > The real way to pose this question is, what is the impact to users by > keeping this on to those that don't use it vs. the cost of turning it > off by default for users that do need it. > > So far, it's not clear to me that anyone has demonstrated how this is > harmful for people that don't want pxe booting. Assuming we fix the bug > about rom loading, then there's really no impact to users. > > Regards, > > Anthony Liguori PXE booting might have security impact. You do not want to do this if you are on a hostile network. -- MST
[Qemu-devel] [PATCH] vnc: hextile: do not generate ForegroundSpecified and SubrectsColoured tiles
This violates the RFB specification (section 6.6.4). It happens to work with
most clients but it's still wrong.
Reported-by: Yaniv Kaul
Signed-off-by: Anthony Liguori
---
vnchextile.h |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/vnchextile.h b/vnchextile.h
index c96ede3..432ed89 100644
--- a/vnchextile.h
+++ b/vnchextile.h
@@ -73,7 +73,7 @@ static void CONCAT(send_hextile_tile_, NAME)(VncState *vs,
*last_bg = bg;
}
-if (!*has_fg || *last_fg != fg) {
+if (n_colors < 3 && (!*has_fg || *last_fg != fg)) {
flags |= 0x04;
*has_fg = 1;
*last_fg = fg;
@@ -165,8 +165,6 @@ static void CONCAT(send_hextile_tile_, NAME)(VncState *vs,
irow += ds_get_linesize(vs->ds) / sizeof(pixel_t);
}
- /* A SubrectsColoured subtile invalidates the foreground color */
- *has_fg = 0;
if (n_data > (w * h * sizeof(pixel_t))) {
n_colors = 4;
flags = 0x01;
--
1.6.2.5
Re: [Qemu-devel] cpuid problem in upstream qemu with kvm
Michael S. Tsirkin wrote: This might help 32 bit guests, but not guests with 64 bit kernel and 32 bit userspace (my case) because all 64 bit CPUs advertise syscall bit in cpuid. Thus 64 bit guests do not seem to even bother checking this bit: AMD + 64 bit -> syscall. Okay, I don't see a great option other than migrating the vendor_id string. Otherwise, cross vendor migration will not work by default. Maybe that's not a problem but if so, we really should change the default cpu model to be much more aggressive about exposing host features. Regards, Anthony Liguori
Re: [Qemu-devel] cpuid problem in upstream qemu with kvm
On Mon, Dec 14, 2009 at 10:08:38PM +0200, Gleb Natapov wrote: > On Mon, Dec 14, 2009 at 02:02:03PM -0600, Anthony Liguori wrote: > > Gleb Natapov wrote: > > >>I thought KVM emulates the syscall instruction? I swear I've seen > > >>patches for that. > > >> > > >It is. Starting from 2.6.32. > > > > Okay, so this is a performance vs. migration compatibility issue then? > > > > BTW, couldn't we just not advertise syscall in cpuid? That should > > fix it too without sacrificing migration compatibility. We get a > > slight slowdown on AMD hosts but that's probably minor compared to > > the cost of using emulated syscall on Intel hosts. > > > As far as I understand not advertising syscall for 64bit CPU is not a > valid option. Yes. 64 bit kernel 32 bit userpace crashes with -cpu qemu64,-syscall. > -- > Gleb.
Re: [Qemu-devel] cpuid problem in upstream qemu with kvm
On Mon, Dec 14, 2009 at 02:02:03PM -0600, Anthony Liguori wrote: > Gleb Natapov wrote: >>> I thought KVM emulates the syscall instruction? I swear I've seen >>> patches for that. >>> >>> >> It is. Starting from 2.6.32. >> > > Okay, so this is a performance vs. migration compatibility issue then? > > BTW, couldn't we just not advertise syscall in cpuid? That should fix > it too without sacrificing migration compatibility. We get a slight > slowdown on AMD hosts but that's probably minor compared to the cost of > using emulated syscall on Intel hosts. > > Regards, > > Anthony Liguori This might help 32 bit guests, but not guests with 64 bit kernel and 32 bit userspace (my case) because all 64 bit CPUs advertise syscall bit in cpuid. Thus 64 bit guests do not seem to even bother checking this bit: AMD + 64 bit -> syscall. -- MST
Re: [Qemu-devel] target-alpha: An approach to fp insn qualifiers
On Mon, Dec 14, 2009 at 7:02 PM, Richard Henderson wrote:
> One of the other folks here (I'm sorry, I've forgotten who as I misplaced
> the mail) passed me a preliminary patch to tackle the missing fp rounding
> mode support. That patch added helpers to change the rounding mode, and
> injected them before and after every fp insn that forced a rounding mode.
That was me.
> After some thought I decided not to pursue this method for the simple reason
> that TCG does not have native floating point code generation.
I have started implementing TCG FP, but lack the time and desire to
complete it. The speed up was pretty good when running on an ARM
host with a fast FPU.
> Given that we
> have to call one helper routine to perform the operation, we might as well
> arrange for that same routine to handle the rounding mode manipulation.
>
> Indeed, the patch below doesn't just pass the rounding mode to the helper,
> but all of the qualifier fields. Thus we can avoid a large explosion of
> helper routines for addt{,/u,/su,sui}{,/c,/m,/d}.
I don't really like passing parts of opcodes to helpers, but as you say
that prevents explosion of helpers. OTOH you could do lazy calls to
helpers that set rounding modes with my approach of separating them
from computation.
I'll take a closer look at your patch tomorrow.
> To complete the patch I should add some symbolic defines for /s, /u, etc to
> avoid magic constants cluttering the code. I should figure out what I
> should pass to helper_excp for each arithmetic exception. I should actually
> implement the arithmetic exceptions.
>
> That said, these two patches are enough to pass the gcc testsuite with no
> regressions over native hardware.
Can you give SPECint 2K equake a try? The symptom was the presence
of many NaN's. If you don't have access to SPEC2K I'll try it.
Laurent
Re: [Qemu-devel] cpuid problem in upstream qemu with kvm
On Mon, Dec 14, 2009 at 02:02:03PM -0600, Anthony Liguori wrote: > Gleb Natapov wrote: > >>I thought KVM emulates the syscall instruction? I swear I've seen > >>patches for that. > >> > >It is. Starting from 2.6.32. > > Okay, so this is a performance vs. migration compatibility issue then? > > BTW, couldn't we just not advertise syscall in cpuid? That should > fix it too without sacrificing migration compatibility. We get a > slight slowdown on AMD hosts but that's probably minor compared to > the cost of using emulated syscall on Intel hosts. > As far as I understand not advertising syscall for 64bit CPU is not a valid option. -- Gleb.
Re: [Qemu-devel] cpuid problem in upstream qemu with kvm
Gleb Natapov wrote: I thought KVM emulates the syscall instruction? I swear I've seen patches for that. It is. Starting from 2.6.32. Okay, so this is a performance vs. migration compatibility issue then? BTW, couldn't we just not advertise syscall in cpuid? That should fix it too without sacrificing migration compatibility. We get a slight slowdown on AMD hosts but that's probably minor compared to the cost of using emulated syscall on Intel hosts. Regards, Anthony Liguori
Re: [Qemu-devel] Re: qdev property bug?
Anthony Liguori wrote: Sebastian Herbszt wrote: Anthony Liguori wrote: Michael S. Tsirkin wrote: Further, we should error out when device is added. Doing this during boot is way too late, management won't be able to understand such errors and won't be able to recover. I don't quite understand this. In 0.11, we never loaded option roms unless a user specified -boot n. If a user specified -boot n and used more than one nic type, I'm fairly certain it would error out during start up because it would run out of option rom space. Maybe it required three types of nics, but the point still remains. I think it used to be possible to have two different nic types and only load one rom, e.g. -net nic,model=pcnet -net nic,model=e1000 -option-rom e1000.rom Then use the boot menu to select the e1000 nic. That's a super hack :-) The fact that works is pure luck. Super hack? Maybe. Pure luck - no. Even if, it's still a regression if that's no longer possible. In 0.12, we always load the option rom for a PCI device. An easy solution here would be to just gracefully handle the case where we ran out of option rom space and (silently) stop loading additional roms. With respect to -boot n, it makes the behavior buggy (you cannot boot from the second nic) but my original point is that that is not a regression from 0.11. Even if i repeat myself [1] i suggest putting an option-rom loading flag to the -net option: -net nic,model=e1000,rom=[on,off,e1000.bin] Well it ought to be a qdev property and it ought to be applicable to every PCI device. And ISA too. For 0.13, we should probably allow a user to suppress option rom loading for a given PCI device. The limited space is a pretty good justification for that. The default behaviour should be not loading option-roms; users should request those. I disagree. A user should not have to decide whether they want PXE boot or not when they create a VM. The less decisions a user has to make up front the easier qemu is to use. If i want PXE boot on my computer, i have to enter the BIOS and enable it. If qemu starts to automagically enable stuff people might want to use, some people will end up with long command lines just to disable it again. - Sebastian
Re: [Qemu-devel] cpuid problem in upstream qemu with kvm
On Mon, Dec 14, 2009 at 01:57:29PM -0600, Anthony Liguori wrote: > Michael S. Tsirkin wrote: > >On Mon, Dec 14, 2009 at 01:44:22PM -0600, Anthony Liguori wrote: > >>Michael S. Tsirkin wrote: > >>>Hi! > >>>I have a linux guest where init crashes during boot with invalid opcode > >>>error > >>>with kernel 2.6.31, but works fine with kernel 2.6.32. > >>>It also works fine even with 2.6.31 with qemu-kvm. > >>> > >>>With Gleb's help, we figured out that the opcode in question is syscall, > >>>which > >>>is unsupported by hardware on kvm with intel hosts, and is emulated in > >>>software > >>>with intel hosts in 2.6.32 and up. AMD hosts support this natively. > >>> > >>>The root cause: by default qemu with kvm enabled reports the following CPU > >>>ID: > >>> m...@robin:~$ less /proc/cpuinfo > >>> processor : 0 > >>> vendor_id : AuthenticAMD > >>> cpu family : 6 > >>> model : 2 > >>> model name : QEMU Virtual CPU version 0.11.50 > >>> stepping: 3 > >>> cpu MHz : 2493.679 > >>> cache size : 512 KB > >>> fdiv_bug: no > >>> hlt_bug : no > >>> f00f_bug: no > >>> coma_bug: no > >>> fpu : yes > >>> fpu_exception : yes > >>> cpuid level : 4 > >>> wp : yes > >>> flags : fpu de pse tsc msr pae mce cx8 apic sep > >>> mtrr pge mca cmov pat > >>> pse36 clflush mmx fxsr sse sse2 syscall lm up pni > >>> bogomips: 4987.35 > >>> clflush size: 64 > >>> power management: > >>> > >>>Problem is, guest sees syscall+AMD vendor and concludes that it is ok to > >>>use > >>>syscall opcode, which results in a crash (or at least, extra VMExits). > >>>I understand from Avi that qemu-kvm solves this problem by reporting > >>>the actual CPU vendor from host, to guest. > >>The bit that's ugly about that is that we do not save/restore > >>cpuid.vendor_id so that would break live migration. > >> > >>Regards, > >> > >>Anthony Liguori > > > >This is a feature. It would be very wrong to save/restore cpuid IMO. > >It must be part of machine config. > > You can already do -cpu qemu64,vendor_id=AuthenticAMD or > ,vendor_id=GenuineIntel. > > If you don't specify anything explicitly, we use AuthenticAMD as a > default. Detecting the host by default is problematic because then > the same invocation on a different host would change the visible > vendor_id. > > I thought KVM emulates the syscall instruction? I swear I've seen > patches for that. > It is. Starting from 2.6.32. -- Gleb.
Re: [Qemu-devel] Re: qdev property bug?
Michael S. Tsirkin wrote: At some level this is wrong. ROM presence is a hardware feature and you definitely need to select your hardware when you create a VM. For real hardware, cards with PXE are sometimes more expensive than without as they need ROM memory. People do select hardware based on this. Even when PXE is present in hardware, most BIOS vendors will let you turn it on/off optionally, for security if not for other reasons. What the default should be depends on whether the majority of our users use PXE. I guess not, and if I am right default should be off. The real way to pose this question is, what is the impact to users by keeping this on to those that don't use it vs. the cost of turning it off by default for users that do need it. So far, it's not clear to me that anyone has demonstrated how this is harmful for people that don't want pxe booting. Assuming we fix the bug about rom loading, then there's really no impact to users. Regards, Anthony Liguori
Re: [Qemu-devel] cpuid problem in upstream qemu with kvm
Michael S. Tsirkin wrote: On Mon, Dec 14, 2009 at 01:44:22PM -0600, Anthony Liguori wrote: Michael S. Tsirkin wrote: Hi! I have a linux guest where init crashes during boot with invalid opcode error with kernel 2.6.31, but works fine with kernel 2.6.32. It also works fine even with 2.6.31 with qemu-kvm. With Gleb's help, we figured out that the opcode in question is syscall, which is unsupported by hardware on kvm with intel hosts, and is emulated in software with intel hosts in 2.6.32 and up. AMD hosts support this natively. The root cause: by default qemu with kvm enabled reports the following CPU ID: m...@robin:~$ less /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 2 model name : QEMU Virtual CPU version 0.11.50 stepping: 3 cpu MHz : 2493.679 cache size : 512 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 4 wp : yes flags : fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall lm up pni bogomips: 4987.35 clflush size: 64 power management: Problem is, guest sees syscall+AMD vendor and concludes that it is ok to use syscall opcode, which results in a crash (or at least, extra VMExits). I understand from Avi that qemu-kvm solves this problem by reporting the actual CPU vendor from host, to guest. The bit that's ugly about that is that we do not save/restore cpuid.vendor_id so that would break live migration. Regards, Anthony Liguori This is a feature. It would be very wrong to save/restore cpuid IMO. It must be part of machine config. You can already do -cpu qemu64,vendor_id=AuthenticAMD or ,vendor_id=GenuineIntel. If you don't specify anything explicitly, we use AuthenticAMD as a default. Detecting the host by default is problematic because then the same invocation on a different host would change the visible vendor_id. I thought KVM emulates the syscall instruction? I swear I've seen patches for that. Regards, Anthony Liguori
Re: [Qemu-devel] cpuid problem in upstream qemu with kvm
On Mon, Dec 14, 2009 at 01:44:22PM -0600, Anthony Liguori wrote: > Michael S. Tsirkin wrote: >> Hi! >> I have a linux guest where init crashes during boot with invalid opcode error >> with kernel 2.6.31, but works fine with kernel 2.6.32. >> It also works fine even with 2.6.31 with qemu-kvm. >> >> With Gleb's help, we figured out that the opcode in question is syscall, >> which >> is unsupported by hardware on kvm with intel hosts, and is emulated in >> software >> with intel hosts in 2.6.32 and up. AMD hosts support this natively. >> >> The root cause: by default qemu with kvm enabled reports the following CPU >> ID: >>m...@robin:~$ less /proc/cpuinfo >>processor : 0 >>vendor_id : AuthenticAMD >>cpu family : 6 >>model : 2 >>model name : QEMU Virtual CPU version 0.11.50 >>stepping: 3 >>cpu MHz : 2493.679 >>cache size : 512 KB >>fdiv_bug: no >>hlt_bug : no >>f00f_bug: no >>coma_bug: no >>fpu : yes >>fpu_exception : yes >>cpuid level : 4 >>wp : yes >>flags : fpu de pse tsc msr pae mce cx8 apic sep >> mtrr pge mca cmov pat >>pse36 clflush mmx fxsr sse sse2 syscall lm up pni >>bogomips: 4987.35 >>clflush size: 64 >>power management: >> >> Problem is, guest sees syscall+AMD vendor and concludes that it is ok to use >> syscall opcode, which results in a crash (or at least, extra VMExits). >> I understand from Avi that qemu-kvm solves this problem by reporting >> the actual CPU vendor from host, to guest. >> > > The bit that's ugly about that is that we do not save/restore > cpuid.vendor_id so that would break live migration. > > Regards, > > Anthony Liguori This is a feature. It would be very wrong to save/restore cpuid IMO. It must be part of machine config. For example, if you want kvm to work with live migration you must either use least common denominator cpu id, or use hardware from the same vendor. -- MST
Re: [Qemu-devel] Re: qdev property bug?
On Mon, Dec 14, 2009 at 01:33:50PM -0600, Anthony Liguori wrote: > Sebastian Herbszt wrote: >> Anthony Liguori wrote: >>> Michael S. Tsirkin wrote: Further, we should error out when device is added. Doing this during boot is way too late, management won't be able to understand such errors and won't be able to recover. >>> >>> I don't quite understand this. >>> >>> In 0.11, we never loaded option roms unless a user specified -boot >>> n. If a user specified -boot n and used more than one nic type, I'm >>> fairly certain it would error out during start up because it would >>> run out of option rom space. Maybe it required three types of nics, >>> but the point still remains. >> >> I think it used to be possible to have two different nic types and >> only load >> one rom, e.g. -net nic,model=pcnet -net nic,model=e1000 -option-rom >> e1000.rom >> Then use the boot menu to select the e1000 nic. > > That's a super hack :-) The fact that works is pure luck. > >>> In 0.12, we always load the option rom for a PCI device. An easy >>> solution here would be to just gracefully handle the case where we >>> ran out of option rom space and (silently) stop loading additional >>> roms. With respect to -boot n, it makes the behavior buggy (you >>> cannot boot from the second nic) but my original point is that that >>> is not a regression from 0.11. >> >> Even if i repeat myself [1] i suggest putting an option-rom loading >> flag to the -net option: >> -net nic,model=e1000,rom=[on,off,e1000.bin] > > Well it ought to be a qdev property and it ought to be applicable to > every PCI device. > >>> For 0.13, we should probably allow a user to suppress option rom >>> loading for a given PCI device. The limited space is a pretty good >>> justification for that. >> >> The default behaviour should be not loading option-roms; users should >> request those. > > I disagree. A user should not have to decide whether they want PXE boot > or not when they create a VM. At some level this is wrong. ROM presence is a hardware feature and you definitely need to select your hardware when you create a VM. For real hardware, cards with PXE are sometimes more expensive than without as they need ROM memory. People do select hardware based on this. Even when PXE is present in hardware, most BIOS vendors will let you turn it on/off optionally, for security if not for other reasons. What the default should be depends on whether the majority of our users use PXE. I guess not, and if I am right default should be off. > The less decisions a user has to make up > front the easier qemu is to use. > > Regards, > > Anthony Liguori
Re: [Qemu-devel] cpuid problem in upstream qemu with kvm
Michael S. Tsirkin wrote: Hi! I have a linux guest where init crashes during boot with invalid opcode error with kernel 2.6.31, but works fine with kernel 2.6.32. It also works fine even with 2.6.31 with qemu-kvm. With Gleb's help, we figured out that the opcode in question is syscall, which is unsupported by hardware on kvm with intel hosts, and is emulated in software with intel hosts in 2.6.32 and up. AMD hosts support this natively. The root cause: by default qemu with kvm enabled reports the following CPU ID: m...@robin:~$ less /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 2 model name : QEMU Virtual CPU version 0.11.50 stepping: 3 cpu MHz : 2493.679 cache size : 512 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 4 wp : yes flags : fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall lm up pni bogomips: 4987.35 clflush size: 64 power management: Problem is, guest sees syscall+AMD vendor and concludes that it is ok to use syscall opcode, which results in a crash (or at least, extra VMExits). I understand from Avi that qemu-kvm solves this problem by reporting the actual CPU vendor from host, to guest. The bit that's ugly about that is that we do not save/restore cpuid.vendor_id so that would break live migration. Regards, Anthony Liguori
Re: [Qemu-devel] Re: qdev property bug?
Michael S. Tsirkin wrote: On Mon, Dec 14, 2009 at 08:12:48PM +0100, Sebastian Herbszt wrote: Anthony Liguori wrote: Michael S. Tsirkin wrote: Further, we should error out when device is added. Doing this during boot is way too late, management won't be able to understand such errors and won't be able to recover. I don't quite understand this. In 0.11, we never loaded option roms unless a user specified -boot n. If a user specified -boot n and used more than one nic type, I'm fairly certain it would error out during start up because it would run out of option rom space. Maybe it required three types of nics, but the point still remains. I think it used to be possible to have two different nic types and only load one rom, e.g. -net nic,model=pcnet -net nic,model=e1000 -option-rom e1000.rom Then use the boot menu to select the e1000 nic. In 0.12, we always load the option rom for a PCI device. An easy solution here would be to just gracefully handle the case where we ran out of option rom space and (silently) stop loading additional roms. With respect to -boot n, it makes the behavior buggy (you cannot boot from the second nic) but my original point is that that is not a regression from 0.11. Even if i repeat myself [1] i suggest putting an option-rom loading flag to the -net option: -net nic,model=e1000,rom=[on,off,e1000.bin] For 0.13, we should probably allow a user to suppress option rom loading for a given PCI device. The limited space is a pretty good justification for that. The default behaviour should be not loading option-roms; users should request those. [1] http://lists.gnu.org/archive/html/qemu-devel/2009-11/msg01095.html - Sebastian I am not sure I agree. This is common for PXE and I think makes sense there, but I think this might not make sense for VGA rom or e.g. scsi. I think it makes sense at least for nic and scsi. It might even be useful for vga, e.g. choose between pci/onboard and agp vga and only load one of both roms. - Sebastian
[Qemu-devel] cpuid problem in upstream qemu with kvm
Hi! I have a linux guest where init crashes during boot with invalid opcode error with kernel 2.6.31, but works fine with kernel 2.6.32. It also works fine even with 2.6.31 with qemu-kvm. With Gleb's help, we figured out that the opcode in question is syscall, which is unsupported by hardware on kvm with intel hosts, and is emulated in software with intel hosts in 2.6.32 and up. AMD hosts support this natively. The root cause: by default qemu with kvm enabled reports the following CPU ID: m...@robin:~$ less /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 2 model name : QEMU Virtual CPU version 0.11.50 stepping: 3 cpu MHz : 2493.679 cache size : 512 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 4 wp : yes flags : fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall lm up pni bogomips: 4987.35 clflush size: 64 power management: Problem is, guest sees syscall+AMD vendor and concludes that it is ok to use syscall opcode, which results in a crash (or at least, extra VMExits). I understand from Avi that qemu-kvm solves this problem by reporting the actual CPU vendor from host, to guest. -- MST
Re: [Qemu-devel] Re: qdev property bug?
Sebastian Herbszt wrote: Anthony Liguori wrote: Michael S. Tsirkin wrote: Further, we should error out when device is added. Doing this during boot is way too late, management won't be able to understand such errors and won't be able to recover. I don't quite understand this. In 0.11, we never loaded option roms unless a user specified -boot n. If a user specified -boot n and used more than one nic type, I'm fairly certain it would error out during start up because it would run out of option rom space. Maybe it required three types of nics, but the point still remains. I think it used to be possible to have two different nic types and only load one rom, e.g. -net nic,model=pcnet -net nic,model=e1000 -option-rom e1000.rom Then use the boot menu to select the e1000 nic. That's a super hack :-) The fact that works is pure luck. In 0.12, we always load the option rom for a PCI device. An easy solution here would be to just gracefully handle the case where we ran out of option rom space and (silently) stop loading additional roms. With respect to -boot n, it makes the behavior buggy (you cannot boot from the second nic) but my original point is that that is not a regression from 0.11. Even if i repeat myself [1] i suggest putting an option-rom loading flag to the -net option: -net nic,model=e1000,rom=[on,off,e1000.bin] Well it ought to be a qdev property and it ought to be applicable to every PCI device. For 0.13, we should probably allow a user to suppress option rom loading for a given PCI device. The limited space is a pretty good justification for that. The default behaviour should be not loading option-roms; users should request those. I disagree. A user should not have to decide whether they want PXE boot or not when they create a VM. The less decisions a user has to make up front the easier qemu is to use. Regards, Anthony Liguori
[Qemu-devel] Re: [PATCH RFC] virtio: add features qdev property
On Mon, Dec 14, 2009 at 12:37:29PM +0100, Gerd Hoffmann wrote:
> On 12/14/09 12:10, Michael S. Tsirkin wrote:
>> On Mon, Dec 14, 2009 at 11:24:41AM +0100, Gerd Hoffmann wrote:
>> for block:
>> if (strcmp(s->serial_str, "0"))
>> features |= 1<< VIRTIO_BLK_F_IDENTIFY;
>>
>> if (bdrv_is_read_only(s->bs))
>> features |= 1<< VIRTIO_BLK_F_RO;
>
> Sure you want these be configurable?
>
>> Also, I'd like these things to be saved in bits and not add a ton
>> of fields in device. Ideas how to do this?
>
> I guess you only want disable features?
>
> You could have a bitmap property then, which accepts names for the bits.
> It would need a table like this ...
>
>char *bitnames[] = {
> [ VIRTIO_BLK_F_IDENTIFY ] = "blk-identify",
> [ VIRTIO_BLK_F_RO [ = "blk-ro",
> [ ... ]
>};
>
> Then the property parser would accepts strings such as 'bit1|bit2' and
> you can have
>
> -device 'virtio-blk-pci,disable=blk-identify|ring-indirect'
>
> The driver will just do 'vdev->host_features &= ~disable'.
>
> cheers,
> Gerd
Is there an example of an existing property that is like this?
--
MST
Re: [Qemu-devel] Re: qdev property bug?
On Mon, Dec 14, 2009 at 08:12:48PM +0100, Sebastian Herbszt wrote: > Anthony Liguori wrote: >> Michael S. Tsirkin wrote: >>> >>> Further, we should error out when device is added. >>> Doing this during boot is way too late, management >>> won't be able to understand such errors and >>> won't be able to recover. >>> >> >> I don't quite understand this. >> >> In 0.11, we never loaded option roms unless a user specified -boot n. >> If a user specified -boot n and used more than one nic type, I'm fairly >> certain it would error out during start up because it would run out of >> option rom space. Maybe it required three types of nics, but the point >> still remains. > > I think it used to be possible to have two different nic types and only load > one rom, e.g. -net nic,model=pcnet -net nic,model=e1000 -option-rom e1000.rom > Then use the boot menu to select the e1000 nic. > >> In 0.12, we always load the option rom for a PCI device. An easy >> solution here would be to just gracefully handle the case where we ran >> out of option rom space and (silently) stop loading additional roms. >> With respect to -boot n, it makes the behavior buggy (you cannot boot >> from the second nic) but my original point is that that is not a >> regression from 0.11. > > Even if i repeat myself [1] i suggest putting an option-rom loading flag to > the -net option: > -net nic,model=e1000,rom=[on,off,e1000.bin] > >> For 0.13, we should probably allow a user to suppress option rom >> loading for a given PCI device. The limited space is a pretty good >> justification for that. > > The default behaviour should be not loading option-roms; users should request > those. > > [1] http://lists.gnu.org/archive/html/qemu-devel/2009-11/msg01095.html > > - Sebastian I am not sure I agree. This is common for PXE and I think makes sense there, but I think this might not make sense for VGA rom or e.g. scsi. -- MST
Re: [Qemu-devel] Re: [PATCH RFC] virtio: add features qdev property
On Mon, Dec 14, 2009 at 06:18:29PM +0100, Gerd Hoffmann wrote: > On 12/14/09 17:23, Michael S. Tsirkin wrote: >> On Mon, Dec 14, 2009 at 04:01:33PM +0100, Gerd Hoffmann wrote: >> So how do you do this? >> Assume we have -disable_hw_csum. >> We want new machine type to have it off, right? >> But now you run qemu on host which does >> not support hw_csum. With your suggestion >> it will not enable hw csum? > > I have trouble getting the setup you are talking about ... > > Sounds like hw_csum could be enabled/disabled depending on the hardware > capabilities on the host. Is that correct? > > cheers, > Gerd This currently depends on version of tun driver in the host. -- MST
Re: [Qemu-devel] Re: qdev property bug?
Anthony Liguori wrote: Michael S. Tsirkin wrote: Further, we should error out when device is added. Doing this during boot is way too late, management won't be able to understand such errors and won't be able to recover. I don't quite understand this. In 0.11, we never loaded option roms unless a user specified -boot n. If a user specified -boot n and used more than one nic type, I'm fairly certain it would error out during start up because it would run out of option rom space. Maybe it required three types of nics, but the point still remains. I think it used to be possible to have two different nic types and only load one rom, e.g. -net nic,model=pcnet -net nic,model=e1000 -option-rom e1000.rom Then use the boot menu to select the e1000 nic. In 0.12, we always load the option rom for a PCI device. An easy solution here would be to just gracefully handle the case where we ran out of option rom space and (silently) stop loading additional roms. With respect to -boot n, it makes the behavior buggy (you cannot boot from the second nic) but my original point is that that is not a regression from 0.11. Even if i repeat myself [1] i suggest putting an option-rom loading flag to the -net option: -net nic,model=e1000,rom=[on,off,e1000.bin] For 0.13, we should probably allow a user to suppress option rom loading for a given PCI device. The limited space is a pretty good justification for that. The default behaviour should be not loading option-roms; users should request those. [1] http://lists.gnu.org/archive/html/qemu-devel/2009-11/msg01095.html - Sebastian
Re: [Qemu-devel] RFC: exit on incoming exec migrate failure
On 11 Dec 2009, at 13:19, Daniel P. Berrange wrote: > On Wed, Dec 09, 2009 at 01:10:18PM -0800, Andrew Farmer wrote: >> Right now, if an incoming migrate through exec fails, the qemu process >> will end up chewing CPU indefinitely - it looks like it closes the >> migration FD but doesn't remove its IO handler properly. An easy way >> to reproduce this is to try launching with -incoming exec:/bin/false. >> This is obviously useless, but illustrates the issue handily. > > I've hit this in real life too, with restore from a file containing > the saved state which had got corrupted/truncated. I only discovered > the failure when I wondered by QEMU was chewing 100% cpu. Hrm... actually, if this also happens on state restore, the problem might not be in migration-exec at all (or there might be multiple bugs with similar symptoms), as the fix I identified was specific to exec failures.
[Qemu-devel] target-alpha: An approach to fp insn qualifiers
One of the other folks here (I'm sorry, I've forgotten who as I
misplaced the mail) passed me a preliminary patch to tackle the missing
fp rounding mode support. That patch added helpers to change the
rounding mode, and injected them before and after every fp insn that
forced a rounding mode.
After some thought I decided not to pursue this method for the simple
reason that TCG does not have native floating point code generation.
Given that we have to call one helper routine to perform the operation,
we might as well arrange for that same routine to handle the rounding
mode manipulation.
Indeed, the patch below doesn't just pass the rounding mode to the
helper, but all of the qualifier fields. Thus we can avoid a large
explosion of helper routines for addt{,/u,/su,sui}{,/c,/m,/d}.
To complete the patch I should add some symbolic defines for /s, /u, etc
to avoid magic constants cluttering the code. I should figure out what
I should pass to helper_excp for each arithmetic exception. I should
actually implement the arithmetic exceptions.
That said, these two patches are enough to pass the gcc testsuite with
no regressions over native hardware.
Comments?
r~
commit 14cb36374f15413abfafb4fc030dcab25a2e0d9a
Author: Richard Henderson
Date: Fri Dec 11 08:40:22 2009 -0800
Phase 1, adding a "Quals" argument to all of the fpu helpers.
diff --git a/target-alpha/helper.h b/target-alpha/helper.h
index bedd3c0..1521a84 100644
--- a/target-alpha/helper.h
+++ b/target-alpha/helper.h
@@ -41,33 +41,33 @@ DEF_HELPER_1(store_fpcr, void, i64)
DEF_HELPER_1(f_to_memory, i32, i64)
DEF_HELPER_1(memory_to_f, i64, i32)
-DEF_HELPER_2(addf, i64, i64, i64)
-DEF_HELPER_2(subf, i64, i64, i64)
-DEF_HELPER_2(mulf, i64, i64, i64)
-DEF_HELPER_2(divf, i64, i64, i64)
-DEF_HELPER_1(sqrtf, i64, i64)
+DEF_HELPER_3(addf, i64, i64, i64, i32)
+DEF_HELPER_3(subf, i64, i64, i64, i32)
+DEF_HELPER_3(mulf, i64, i64, i64, i32)
+DEF_HELPER_3(divf, i64, i64, i64, i32)
+DEF_HELPER_2(sqrtf, i64, i64, i32)
DEF_HELPER_1(g_to_memory, i64, i64)
DEF_HELPER_1(memory_to_g, i64, i64)
-DEF_HELPER_2(addg, i64, i64, i64)
-DEF_HELPER_2(subg, i64, i64, i64)
-DEF_HELPER_2(mulg, i64, i64, i64)
-DEF_HELPER_2(divg, i64, i64, i64)
-DEF_HELPER_1(sqrtg, i64, i64)
+DEF_HELPER_3(addg, i64, i64, i64, i32)
+DEF_HELPER_3(subg, i64, i64, i64, i32)
+DEF_HELPER_3(mulg, i64, i64, i64, i32)
+DEF_HELPER_3(divg, i64, i64, i64, i32)
+DEF_HELPER_2(sqrtg, i64, i64, i32)
DEF_HELPER_1(s_to_memory, i32, i64)
DEF_HELPER_1(memory_to_s, i64, i32)
-DEF_HELPER_2(adds, i64, i64, i64)
-DEF_HELPER_2(subs, i64, i64, i64)
-DEF_HELPER_2(muls, i64, i64, i64)
-DEF_HELPER_2(divs, i64, i64, i64)
-DEF_HELPER_1(sqrts, i64, i64)
-
-DEF_HELPER_2(addt, i64, i64, i64)
-DEF_HELPER_2(subt, i64, i64, i64)
-DEF_HELPER_2(mult, i64, i64, i64)
-DEF_HELPER_2(divt, i64, i64, i64)
-DEF_HELPER_1(sqrtt, i64, i64)
+DEF_HELPER_3(adds, i64, i64, i64, i32)
+DEF_HELPER_3(subs, i64, i64, i64, i32)
+DEF_HELPER_3(muls, i64, i64, i64, i32)
+DEF_HELPER_3(divs, i64, i64, i64, i32)
+DEF_HELPER_2(sqrts, i64, i64, i32)
+
+DEF_HELPER_3(addt, i64, i64, i64, i32)
+DEF_HELPER_3(subt, i64, i64, i64, i32)
+DEF_HELPER_3(mult, i64, i64, i64, i32)
+DEF_HELPER_3(divt, i64, i64, i64, i32)
+DEF_HELPER_2(sqrtt, i64, i64, i32)
DEF_HELPER_2(cmptun, i64, i64, i64)
DEF_HELPER_2(cmpteq, i64, i64, i64)
@@ -81,15 +81,15 @@ DEF_HELPER_2(cpys, i64, i64, i64)
DEF_HELPER_2(cpysn, i64, i64, i64)
DEF_HELPER_2(cpyse, i64, i64, i64)
-DEF_HELPER_1(cvtts, i64, i64)
-DEF_HELPER_1(cvtst, i64, i64)
-DEF_HELPER_1(cvttq, i64, i64)
-DEF_HELPER_1(cvtqs, i64, i64)
-DEF_HELPER_1(cvtqt, i64, i64)
-DEF_HELPER_1(cvtqf, i64, i64)
-DEF_HELPER_1(cvtgf, i64, i64)
-DEF_HELPER_1(cvtgq, i64, i64)
-DEF_HELPER_1(cvtqg, i64, i64)
+DEF_HELPER_2(cvtts, i64, i64, i32)
+DEF_HELPER_2(cvtst, i64, i64, i32)
+DEF_HELPER_2(cvttq, i64, i64, i32)
+DEF_HELPER_2(cvtqs, i64, i64, i32)
+DEF_HELPER_2(cvtqt, i64, i64, i32)
+DEF_HELPER_2(cvtqf, i64, i64, i32)
+DEF_HELPER_2(cvtgf, i64, i64, i32)
+DEF_HELPER_2(cvtgq, i64, i64, i32)
+DEF_HELPER_2(cvtqg, i64, i64, i32)
DEF_HELPER_1(cvtlq, i64, i64)
DEF_HELPER_1(cvtql, i64, i64)
DEF_HELPER_1(cvtqlv, i64, i64)
diff --git a/target-alpha/op_helper.c b/target-alpha/op_helper.c
index b2abf6c..b12c783 100644
--- a/target-alpha/op_helper.c
+++ b/target-alpha/op_helper.c
@@ -370,6 +370,85 @@ uint64_t helper_unpkbw (uint64_t op1)
/* Floating point helpers */
+/* If the floating-point qualifiers specified a rounding mode,
+ set that rounding mode and remember the original mode for
+ resetting at the end of the instruction. */
+static inline uint32_t begin_quals_roundmode(uint32_t qual)
+{
+uint32_t rm = FP_STATUS.float_rounding_mode, old_rm = rm;
+
+switch (qual & 0xc0) {
+case 0x80:
+rm = float_round_nearest_even;
+break;
+case 0x00:
+rm = float_round_to_zero;
+break;
+case 0x40:
+rm = float_round_down;
+break;
+case 0xc0:
+retu
Re: [Qemu-devel] Re: Spice project is now open
On Mon, 2009-12-14 at 15:10 +, Daniel P. Berrange wrote: > The model I had in mind was for the proxy to define a VNC extension that > allows the client to query what 'desktops' are available and request > switching between them at any time. The list of desktop would of course > be authorized per client, and strong authentication is a must for this. > > Any time a switch was made, the RFB protocol would return to the > 'ServerInit' state. The idea is that you should not assume a homogenous > environment, and you really don't want to fall down to the lowest common > denominator of extensions, nor have the proxy doing re-encoding on the FB > data updates. Returning to the ServerInit state allowing the client to > re-negotiate the set of encodings for the new desktop, and so the proxy > can be fairly stateless and while needing to understand the wire protocol, > it can just pass through the actual FB update data unchanged. > > The combo of the an extension for switching desktops on the fly and the > encryption state problem doesn't really seem to fit with passing the VNC > FD over with SCM_RIGHTS. I actually did a demo of this before, in a slightly different context. The idea was: - vnc client connects to gdm, which spawned a Xvnc(A) server with a gdm auth dialog - user logs in and if you've an Xvnc server already, it would move the client connection to the original Xvnc(B) server - first, gdm would tell the (A) to sync it's state; (A) would stop sending updates, flush its zlib/tls streams and pass gdm the current state of the connection - e.g. the protocol version, pixel format, supported encodings etc. - then gdm would pass the connection fd using SCM_RIGHTS to the existing Xvnc along with the connection state, and (B) would pick up the connection - from the users point of view, they were logged instantly back into their old session Simply flushing the encryption/compression state was the key, but AFAIR clients needed a trivial fix to allow them to properly handle the server flushing the stream. The alternative was to somehow get the server to dump its encryption/compression state and pass that to the existing server, but that seemed quite difficult when I looked. SCM_RIGHTS rule ... this was definitely one of the most fun hacks I've done :-) Cheers, Mark. p.s. - I'm sure I can dig up the code, here are some diffs that look like older than what I remember finishing: http://www.gnome.org/~markmc/code/gdm-vnc-support.patch http://www.gnome.org/~markmc/code/test-gnutls-client-close-restart.c http://www.gnome.org/~markmc/code/test-gnutls-server-close-restart.c http://www.gnome.org/~markmc/code/test-zlib.c http://www.gnome.org/~markmc/code/vnc-4.0b5-vncviewer-tls.diff http://www.gnome.org/~markmc/code/vnc-managed.patch http://www.gnome.org/~markmc/code/vnc-tls.patch
Re: [Qemu-devel] [ANNOUNCE][Call-For-Testing] Release 0.12.0-rc1 of QEMU
Avi Kivity wrote: On 12/14/2009 04:06 PM, Anthony Liguori wrote: The QEMU team is pleased to announce the availability of the 0.12.0-rc2 release. This is the second release candidate for the 0.12.0 release. This release is not intended for production use. I'm missing the tag for this release? Sorry, should be there now. Forgot to push the tag explicitly. -- Regards, Anthony Liguori
Re: [Qemu-devel] Re: [PATCH RFC] virtio: add features qdev property
On 12/14/09 17:23, Michael S. Tsirkin wrote: On Mon, Dec 14, 2009 at 04:01:33PM +0100, Gerd Hoffmann wrote: So how do you do this? Assume we have -disable_hw_csum. We want new machine type to have it off, right? But now you run qemu on host which does not support hw_csum. With your suggestion it will not enable hw csum? I have trouble getting the setup you are talking about ... Sounds like hw_csum could be enabled/disabled depending on the hardware capabilities on the host. Is that correct? cheers, Gerd
[Qemu-devel] Re: -serial stdio broken
It looks like vl.c was a poor place to do the mux choice. I just wonder why mux option can't be automatically enabled for stdio in qemu-char.c:qemu_chr_parse_compat() or somewhere nearby. The mux driver grabs the 'Ctrl-a' hotkey, so I wouldn't enable that unconditionally because the chardev isn't transparent any more with mux enabled. It also wouldn't really help with command line parsing. cheers, Gerd
Re: [Qemu-devel] Re: qdev property bug?
On Mon, Dec 14, 2009 at 08:22:12AM -0600, Anthony Liguori wrote: > Michael S. Tsirkin wrote: > >Well I am pretty sure that I used virtio + e1000 with 0.11 > >and apparently I can't now. > >So it does look like a regression to me ... > > That's what I said, we should make sure that we stop loading roms > when we run out of room as opposed to trampling over the bios space. Can't we first load the bios? Then we're pretty sure oproms will never trample it.
Re: [Qemu-devel] Re: qdev property bug?
On Mon, Dec 14, 2009 at 04:11:43PM +0200, Michael S. Tsirkin wrote: > On Mon, Dec 14, 2009 at 08:11:59AM -0600, Anthony Liguori wrote: > > Alexander Graf wrote: > >> Michael S. Tsirkin wrote: > >> > >>> On Mon, Dec 14, 2009 at 12:55:28PM +0100, Alexander Graf wrote: > >>> > Am 14.12.2009 um 11:59 schrieb "Michael S. Tsirkin" : > > > > On Mon, Dec 14, 2009 at 11:16:34AM +0100, Gerd Hoffmann wrote: > > > >> On 12/14/09 10:44, Michael S. Tsirkin wrote: > >> > >>> No, it did not even start booting the kernel. Just gave me > >>> blank screen. > >>> > >> [ testing ] > >> > >> Oh. That is something completely different. A bug in the rom > >> loader. > >> It fails to fit both e1000 (default nic) and virtio-net boot > >> roms into > >> the option rom area and bails out (before loading seabios). vl.c > >> doesn't check the return value and happily continues (without bios). > >> Which doesn't work out very well ... > >> > >> With two identical nics the (single) rom fits and qemu boots. > >> > >> Hmm. Of course vl.c must be fixed to check the return value. > >> > > Yes. > > > > > >> Not sure how to deal with the rom size issue. The gPXE roms > >> look quit > >> big compared to the older roms we had. > >> > > Hmm, it's a regression then ... > > > How does real hw handle this? I'm pretty sure most servers these > days use more option rom space than this. They usually have some > onboard raid bios, external storage, on-board nic, pci nic, ... > > >>> Real hardware might do several things I know about > >>> - option rom is typically small. > >>> - option rom is not loaded always (BIOS option), or not for all cards. > >>> There are might be other tricks. > >>> > >> > >> There are probably other tricks. I was booting up a machine that had > >> like 5 options roms going through their initialization that all weren't > >> exactly small. > >> > >> > So there must be some way to just have more option rom space. > > >>> What do you mean? > >>> > >> > >> Well, what's keeping us from having 5 MB of option roms? > >> > > > > For starters, option roms run in real mode when you only have 1MB of > > addressable memory :-) > > > Implementing anything else would just be a waste of time. It'd > break again when ppl do device assignment. > > Alex > > >>> We need some solution for 0.12 though IMO. > >>> This does not need to address device assignment, > >>> but it must be simple. > >>> > >> > >> Agreed. If there is a solution that gives us the chance to support an > >> arbitrary number of option roms that wouldn't take forever to implement, > >> I'd rather take that one though. > >> > > > > For 0.12, we just need to fail gracefully (meaning stop loading option > > roms when we run out of room). It's not a regression compared to 0.11. > > > > Regards, > > > > Anthony Liguori > > > Well I am pretty sure that I used virtio + e1000 with 0.11 > and apparently I can't now. > So it does look like a regression to me ... e1000 is the problem here, since it is by far the largest roms of them all.
Re: [Qemu-devel] Re: qdev property bug?
On Mon, Dec 14, 2009 at 04:01:43PM +0200, Michael S. Tsirkin wrote: > On Mon, Dec 14, 2009 at 02:35:31PM +0100, Alexander Graf wrote: > > Michael S. Tsirkin wrote: > > > On Mon, Dec 14, 2009 at 12:55:28PM +0100, Alexander Graf wrote: > > > > > >> Am 14.12.2009 um 11:59 schrieb "Michael S. Tsirkin" : > > >> > > >> > > >>> On Mon, Dec 14, 2009 at 11:16:34AM +0100, Gerd Hoffmann wrote: > > >>> > > On 12/14/09 10:44, Michael S. Tsirkin wrote: > > > > > No, it did not even start booting the kernel. Just gave me blank > > > screen. > > > > > [ testing ] > > > > Oh. That is something completely different. A bug in the rom > > loader. > > It fails to fit both e1000 (default nic) and virtio-net boot roms > > into > > the option rom area and bails out (before loading seabios). vl.c > > doesn't check the return value and happily continues (without bios). > > Which doesn't work out very well ... > > > > With two identical nics the (single) rom fits and qemu boots. > > > > Hmm. Of course vl.c must be fixed to check the return value. > > > > >>> Yes. > > >>> > > >>> > > Not sure how to deal with the rom size issue. The gPXE roms look > > quit > > big compared to the older roms we had. > > > > >>> Hmm, it's a regression then ... > > >>> > > >> How does real hw handle this? I'm pretty sure most servers these days > > >> use more option rom space than this. They usually have some onboard raid > > >> bios, external storage, on-board nic, pci nic, ... > > >> > > > > > > Real hardware might do several things I know about > > > - option rom is typically small. > > > - option rom is not loaded always (BIOS option), or not for all cards. > > > There are might be other tricks. > > > > > > > There are probably other tricks. I was booting up a machine that had > > like 5 options roms going through their initialization that all weren't > > exactly small. > > This might boil down to better ROMs. E.g. > maybe they request memory with PMM and then give it up > after initialization? That would be my guess. However, gpxe rom are also used in real hardware. Maybe there is some config trick we're missing?
Re: [Qemu-devel] [ANNOUNCE][Call-For-Testing] Release 0.12.0-rc1 of QEMU
On 12/14/2009 04:06 PM, Anthony Liguori wrote: The QEMU team is pleased to announce the availability of the 0.12.0-rc2 release. This is the second release candidate for the 0.12.0 release. This release is not intended for production use. I'm missing the tag for this release? -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [ANNOUNCE][Call-For-Testing] Release 0.12.0-rc1 of QEMU
On Mon, Dec 14, 2009 at 4:20 PM, Anthony Liguori wrote: > Artyom Tarasenko wrote: >> >> 2009/12/14 Anthony Liguori : >> >>> >>> The current plan is to release 0.12.0 on Friday, Dec 18th. Depending on >>> the >>> severity of bug fixes we get between now and then, we may do another >>> release >>> candidate in the middle of the week. >>> >> >> I see that the carry flag fix for sparc is included. Are you planning >> to include the rest of my sparc/scsi patches? They are not as drastic >> as the carry fix, so they shouldn't break something which isn't >> already broken. On the other hand, the ability to boot Solaris/sparc >> kernel may be important for some users. >> > > It's up to Blue Swirl to decide about the sparc patches. The SCSI Inquiry > fix is reasonable but it missed the -rc2 deadline. I'll queue it for final > release. The FDC fix should be OK. Technically AFX patch adds new functionality, but very limited.
[Qemu-devel] Re: -serial stdio broken
On Mon, Dec 14, 2009 at 10:55 AM, Gerd Hoffmann wrote: > On 12/13/09 10:38, Blue Swirl wrote: >> >> On Sun, Dec 13, 2009 at 8:24 AM, Blue Swirl wrote: >>> >>> I guess e1c09175bc00dd8dfb2ad1b26e1858dcdc109b59 or >>> 998bbd74b9d813b14a3a3b5009a5d5a48c7dce51 broke -serial stdio for all >>> targets: >>> qemu -serial stdio -monitor stdio > > Oh. It is actually used on the command line. Hmm. > > First, you can use '-serial mon:stdio' instead. > > Second, with 'qemu -nographic' you don't need to specify this at all because > that is the default. > > What is gone now is the automagic conversion of '-serial stdio -monitor > stdio' into '-serial mon:stdio' because I didn't expect people actually > using that on the command line (see commit message). Also this kind of > post-processing is pretty horrible thing for the command line parser code. > Thus I would pretty much prefer to not re-introduce this ... It looks like vl.c was a poor place to do the mux choice. I just wonder why mux option can't be automatically enabled for stdio in qemu-char.c:qemu_chr_parse_compat() or somewhere nearby. > Can you live with one of the alternatives outlined above? I removed -monitor stdio from all my tests, now they work.
Re: [Qemu-devel] Re: [PATCH RFC] virtio: add features qdev property
On Mon, Dec 14, 2009 at 04:01:33PM +0100, Gerd Hoffmann wrote: > On 12/14/09 14:59, Michael S. Tsirkin wrote: >> It's not an easy quesiton. >> If we do it as disable bits, then we get incompatible >> machines when running on different hosts. > > In case that one host supports feature which the other doesn't and the > feature isn't masked out? Well, management failure I'd say. The whole > point of the compat machine types (and properties used there) is to make > sure the vm's are compatible even in case the hosts run different > software versions. > > cheers, > Gerd So how do you do this? Assume we have -disable_hw_csum. We want new machine type to have it off, right? But now you run qemu on host which does not support hw_csum. With your suggestion it will not enable hw csum? -- MST
Re: [Qemu-devel] Re: qdev property bug?
On Mon, Dec 14, 2009 at 08:25:53AM -0600, Anthony Liguori wrote: > Michael S. Tsirkin wrote: >> >> Further, we should error out when device is added. >> Doing this during boot is way too late, management >> won't be able to understand such errors and >> won't be able to recover. >> > > I don't quite understand this. > > In 0.11, we never loaded option roms unless a user specified -boot n. > If a user specified -boot n and used more than one nic type, I'm fairly > certain it would error out during start up because it would run out of > option rom space. Maybe it required three types of nics, but the point > still remains. > > In 0.12, we always load the option rom for a PCI device. An easy > solution here would be to just gracefully handle the case where we ran > out of option rom space and (silently) stop loading additional roms. > With respect to -boot n, it makes the behavior buggy (you cannot boot > from the second nic) but my original point is that that is not a > regression from 0.11. Sorry, I misunderstood what you were saying. I thought you suggested handling it with exit(1) or something like that. Yes, this hack will work I think, unless we want to go back to 0.11 behaviour. > For 0.13, we should probably allow a user to suppress option rom loading > for a given PCI device. The limited space is a pretty good > justification for that. > > Regards, > > Anthony Liguori > >>> -- >>> MST >>>
[Qemu-devel] Re: [PATCH] Seabios: Fix PkgLength calculation for the SSDT.
On 12/13/2009 04:14 PM, Kevin O'Connor wrote:
- Forwarded message from Gleb Natapov -
From: Gleb Natapov
To: Kevin O'Connor
Date: Sun, 13 Dec 2009 15:18:08 +0200
Subject: Re: [...@virtutech.com: [coreboot] [PATCH] Seabios: Fix PkgLength
calculation for the SSDT.]
On Thu, Dec 10, 2009 at 08:55:30AM -0500, Kevin O'Connor wrote:
FYI.
- Forwarded message from Magnus Christensson -
From: Magnus Christensson
To: coreb...@coreboot.org
Date: Thu, 26 Nov 2009 13:22:14 +0100
Subject: [coreboot] [PATCH] Seabios: Fix PkgLength calculation for the SSDT.
See attached patch.
M.
> From d9dc0f50b2ce756e8a3b4ede0a8ecbe76f2afcb8 Mon Sep 17 00:00:00 2001
From: Magnus Christensson
Date: Wed, 25 Nov 2009 16:26:58 +0100
Subject: [PATCH 13/13] Fix PkgLength calculation for the SSDT.
Signed-off-by: Magnus Christensson
---
src/acpi.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/acpi.c b/src/acpi.c
index 843af69..88007ae 100644
--- a/src/acpi.c
+++ b/src/acpi.c
@@ -464,10 +464,12 @@ build_ssdt(void)
// build processor scope header
*(ssdt_ptr++) = 0x10; // ScopeOp
if (cpu_length<= 0x3e) {
+/* Handle 1-4 CPUs with one byte encoding */
*(ssdt_ptr++) = cpu_length + 1;
} else {
-*(ssdt_ptr++) = 0x7F;
-*(ssdt_ptr++) = (cpu_length + 2)>> 6;
+/* Handle 5-314 CPUs with two byte encoding */
+*(ssdt_ptr++) = 0x40 | ((cpu_length + 1)& 0xf);
+*(ssdt_ptr++) = (cpu_length + 1)>> 4;
Should be cpu_length + 2 as far as I can tell. The current code is
definitely broken.
Right. That should be cpu_length +2 in the else-part.
M.
[Qemu-devel] Re: Seabios: PCI interrupt routing question
On 12/13/2009 04:12 PM, Kevin O'Connor wrote: - Forwarded message from Gleb Natapov - From: Gleb Natapov To: Kevin O'Connor Date: Sun, 13 Dec 2009 17:07:48 +0200 Subject: Re: [...@virtutech.com: [coreboot] Seabios: PCI interrupt routing question] On Thu, Dec 10, 2009 at 08:55:11AM -0500, Kevin O'Connor wrote: FYI. - Forwarded message from Magnus Christensson - From: Magnus Christensson To: coreb...@coreboot.org Date: Fri, 27 Nov 2009 09:13:02 +0100 Subject: [coreboot] Seabios: PCI interrupt routing question Hi, I have a question about the PCI INTx pin interrupt routing in Seabios. Specifically, what does the pci_slot_get_pirq function do? It looks like it assigns different interrupt numbers to devices depending on their device number. This function implement the same logic as pci_swizzle_interrupt_pin() in Linux kernel. This logic defines how PCI bridge connects INTx of each devices behind it to system board interrupt line and it is part of PCI spec (page 30 of PCI3.0 spec). Note that the function return pin, not interrupt line. To get interrupt line we look into pci_irqs[] array. The swizzling of INTx-pins happens in PCI-to-PCI bridges. But it looks like the pci_slot_get_pirq function is applied to all devices, including those on the top-level bus that are not behind any PCI-to-PCI bridge. Further, the function only looks at device (slot) and doesn't care where the device is in the PCI hierarchy. But the interrupt routing in the southbridge maps a given INTx to the same interrupt number regardless of the device number (that mapping is initialized by the code with the "activate irq remapping in PIIX" comment). To me, this looks like the INTERRUPT_LINE would be set to a value that does not match the actual interrupt routing (if (dev& 3) != 0). The code is correct if QEMU does interrupt swizzling on PIIX3 chipset level. The code in incorrect if QEMU doesn't. Swizzling like this is done by PCI-to-PCI bridges according to PCI spec, root bridge doesn't do it AFAIK, so code looks suspicious, but not because of the reason stated above. Yes, if the QEMU emulation of PIIX3 does swizzling on bus #0 (which I don't think happens in hardware), then the code would be correct (for running on QEMU). M.
Re: [Qemu-devel] [ANNOUNCE][Call-For-Testing] Release 0.12.0-rc1 of QEMU
Artyom Tarasenko wrote: 2009/12/14 Anthony Liguori : The current plan is to release 0.12.0 on Friday, Dec 18th. Depending on the severity of bug fixes we get between now and then, we may do another release candidate in the middle of the week. I see that the carry flag fix for sparc is included. Are you planning to include the rest of my sparc/scsi patches? They are not as drastic as the carry fix, so they shouldn't break something which isn't already broken. On the other hand, the ability to boot Solaris/sparc kernel may be important for some users. It's up to Blue Swirl to decide about the sparc patches. The SCSI Inquiry fix is reasonable but it missed the -rc2 deadline. I'll queue it for final release. -- Regards, Anthony Liguori
Re: [Qemu-devel] Re: Spice project is now open
Avi Kivity wrote: You can still implement this with SCM_RIGHTS. Authenticate, select guest, drop tls, pass fd to qemu, authenticate, hack hack hack, drop tls, pass fd back to proxy, goto 10. Here's how I'd envision this working. Start qemu with: qemu -vnc proxy:/path/to/unix/domain/socket We connect to /path/to/unix/domain/socket and wait to recv file descriptors after telling the server it's name and what protocol version it supports. We treat each received file descriptor as a new connection. We use do full protocol with no specific authentication. The server runs and opens /path/to/unix/domain/socket. Whenever a client connects to the server socket, it does protocol negotiation using the least common denominator of protocol versions given it. We use a protocol extension to list and negotiate which client to connect to. Once that's been established, we send a socketpair() over the appropriate domain socket, and do appropriate negotiation to get us up to the ServerInit stage. We use a combination of DesktopResize and WMVi in the server to get the client at the appropriate state to match the ServerInit. We then (in the server) blindly proxy any data from the qemu instance to the client (encrypting it if necessary). We won't need to reencode any traffic in this model and it's pretty reasonable from a UI perspective. In fact, if we use a helper, we can probably have an even better command line for qemu. Regards, Anthony Liguori
Re: [Qemu-devel] Qemu terminating with SIGABRT
I'm using a variant of the KVM source from RHEL5 plus a few cherry-picked patches. Host OS is RHEL 5.3. The servers are using E5540 or E5504 processors. The host OS is running from a small USB key, and there is no place to write a core file. Other accommodations have to be made to get it. Hopefully by the end of the week I can get make to reproducing the abort and capturing a core. David Ahern On 12/14/2009 09:04 AM, Luiz Capitulino wrote: > On Sat, 12 Dec 2009 11:09:38 -0700 > "David S. Ahern" wrote: > >> Thanks for the responses. I had forgotten that SIGABRT==abort() which >> means I have to get the core file to get to the root cause. To date the >> only information I have is a shell exit status of 134 which from the >> bash man pages means it died due to SIGABRT. > > Are you using qemu-kvm or upstream qemu? Which version? Don't you > have any procedure which would make the bug more likely to happen? > > Thanks.
Re: [Qemu-devel] [ANNOUNCE][Call-For-Testing] Release 0.12.0-rc1 of QEMU
2009/12/14 Anthony Liguori : > The current plan is to release 0.12.0 on Friday, Dec 18th. Depending on the > severity of bug fixes we get between now and then, we may do another release > candidate in the middle of the week. I see that the carry flag fix for sparc is included. Are you planning to include the rest of my sparc/scsi patches? They are not as drastic as the carry fix, so they shouldn't break something which isn't already broken. On the other hand, the ability to boot Solaris/sparc kernel may be important for some users. -- Regards, Artyom Tarasenko solaris/sparc under qemu blog: http://tyom.blogspot.com/
Re: [Qemu-devel] Qemu terminating with SIGABRT
On Sat, 12 Dec 2009 11:09:38 -0700 "David S. Ahern" wrote: > Thanks for the responses. I had forgotten that SIGABRT==abort() which > means I have to get the core file to get to the root cause. To date the > only information I have is a shell exit status of 134 which from the > bash man pages means it died due to SIGABRT. Are you using qemu-kvm or upstream qemu? Which version? Don't you have any procedure which would make the bug more likely to happen? Thanks.
Re: [Qemu-devel] Re: Spice project is now open
On 12/14/2009 05:10 PM, Daniel P. Berrange wrote: The model I had in mind was for the proxy to define a VNC extension that allows the client to query what 'desktops' are available and request switching between them at any time. The list of desktop would of course be authorized per client, and strong authentication is a must for this. Any time a switch was made, the RFB protocol would return to the 'ServerInit' state. The idea is that you should not assume a homogenous environment, and you really don't want to fall down to the lowest common denominator of extensions, nor have the proxy doing re-encoding on the FB data updates. Returning to the ServerInit state allowing the client to re-negotiate the set of encodings for the new desktop, and so the proxy can be fairly stateless and while needing to understand the wire protocol, it can just pass through the actual FB update data unchanged. The combo of the an extension for switching desktops on the fly and the encryption state problem doesn't really seem to fit with passing the VNC FD over with SCM_RIGHTS. You can still implement this with SCM_RIGHTS. Authenticate, select guest, drop tls, pass fd to qemu, authenticate, hack hack hack, drop tls, pass fd back to proxy, goto 10. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [PATCH] A different way to ask for readonly drive
Naphtali Sprei schrieb: > Hi, > After feedback from Red Hat guys, I've decided to slightly modify the > approach to drive's readonly. > The new approach also addresses the silent fall-back to open the drives' file > as read-only when read-write fails > (permission denied) that causes unexpected behavior. > Instead of the 'readonly' boolean flag, another flag introduced (a > replacement), 'read_write' with three values [on|off|try]: > read_write=on : open with read and write permission, no fall-back to read-only > read_write=off: open with read-only permission > read_write=try: open with read and write permission and if fails, fall-back > to read-only (the default if nothing specified) > > Suggestions for better naming for flag/values welcomed. > > I've tried to explicitly pass the required flags for the bdrv_open function > in callers, but probably missed some. > > Naphtali > > ... > Instead of on/off, I'd prefer the common shortcuts rw/ro. "try" is ok, but maybe "rw-ro" is better. So here are my suggestions: read_write=rw read_write=ro read_write=rw-ro or access=rw access=ro access=rw-ro Regards, Stefan
Re: [Qemu-devel] Re: Spice project is now open
Daniel P. Berrange wrote: On Mon, Dec 14, 2009 at 08:42:12AM -0600, Anthony Liguori wrote: Avi Kivity wrote: On 12/13/2009 01:46 AM, Anthony Liguori wrote: Dan Berrange and I have been talking about being able to move VNC server into a central process such that all of the VMs can have a single VNC port that can be connected to. This greatly simplifies the firewalling logic that an administrator has to deal with. That's a problem I've already had to deal with for our management tools. We use a private network for management and we bridge the VNC traffic into the customers network so they can see the VGA session. But since that traffic can be a large range of ports and we have to tunnel the traffic through a central server to get into the customer network, it's very difficult to setup without opening up a mess of ports. I think we're currently opening a few thousand just for VNC. Seems to me the best way to handle this is to run an accept() in a server and hand the resulting fd to the vnc server in qemu using ... wait for it ... SCM_RIGHTS. I'm just happy every time someone lobs a question into the air that can be answered using SCM_RIGHTS. That's actually a great idea made even better by the use of SCM_RIGHTS :-) I think it's a bit trickier though because ideally you would want to use the vnc protocol to negotiate which vm you're connecting to. That implies that you actually need to hand over the fd in a setup state. It's complicated by any encryption protocol too. The model I had in mind was for the proxy to define a VNC extension that allows the client to query what 'desktops' are available and request switching between them at any time. The list of desktop would of course be authorized per client, and strong authentication is a must for this. Any time a switch was made, the RFB protocol would return to the 'ServerInit' state. I was thinking about it a bit differently. I was envisioning the switch to be a one time thing as opposed to being able to switch back and forth. A management app can see multiple guests by connecting repeatedly to the same port. They can implement switching in the client which allows for clever things like caching state of multiple clients while not sending updates for clients that aren't actively displayed. Regards, Anthony Liguori
Re: [Qemu-devel] Re: Spice project is now open
Avi Kivity wrote: On 12/14/2009 05:17 PM, Daniel P. Berrange wrote: Yes - need to pass the encryption state. Hopefully the crypto stacks support this. There's no mechanism for this in the SASL libraries. With GNUTLS there is the ability to preserve negotiated session state from one TLS conenection and used it upon opening the next connection to fast-track the handshake phase. This doesn't allow you to pass the state for an existing connection to a new process though and have it carry on This sucks. But we can ask the client to reauthenticate. Or instead of passing the socket file descriptor, pass over a socketpair and encrypt the traffic in the server. The encryption requires no knowledge of the protocol so it can be done easily enough in the server. You're already paying the cost for copying the data. Adding in one copy shouldn't be the end of the world. Regards, Anthony Liguori
Re: [Qemu-devel] Re: Spice project is now open
On 12/14/2009 05:17 PM, Daniel P. Berrange wrote: Yes - need to pass the encryption state. Hopefully the crypto stacks support this. There's no mechanism for this in the SASL libraries. With GNUTLS there is the ability to preserve negotiated session state from one TLS conenection and used it upon opening the next connection to fast-track the handshake phase. This doesn't allow you to pass the state for an existing connection to a new process though and have it carry on This sucks. But we can ask the client to reauthenticate. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] Re: Spice project is now open
On Mon, Dec 14, 2009 at 04:53:07PM +0200, Avi Kivity wrote: > On 12/14/2009 04:42 PM, Anthony Liguori wrote: > >I think it's a bit trickier though because ideally you would want to > >use the vnc protocol to negotiate which vm you're connecting to. > > Right, of course. If the client can no longer choose the target using > its port number, it has to select it in some other way. > > >That implies that you actually need to hand over the fd in a setup > >state. It's complicated by any encryption protocol too. > > Yes - need to pass the encryption state. Hopefully the crypto stacks > support this. There's no mechanism for this in the SASL libraries. With GNUTLS there is the ability to preserve negotiated session state from one TLS conenection and used it upon opening the next connection to fast-track the handshake phase. This doesn't allow you to pass the state for an existing connection to a new process though and have it carry on Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
Re: [Qemu-devel] Re: Spice project is now open
On Mon, Dec 14, 2009 at 08:42:12AM -0600, Anthony Liguori wrote: > Avi Kivity wrote: > >On 12/13/2009 01:46 AM, Anthony Liguori wrote: > >> > >>Dan Berrange and I have been talking about being able to move VNC > >>server into a central process such that all of the VMs can have a > >>single VNC port that can be connected to. This greatly simplifies > >>the firewalling logic that an administrator has to deal with. > >>That's a problem I've already had to deal with for our management > >>tools. We use a private network for management and we bridge the VNC > >>traffic into the customers network so they can see the VGA session. > >>But since that traffic can be a large range of ports and we have to > >>tunnel the traffic through a central server to get into the customer > >>network, it's very difficult to setup without opening up a mess of > >>ports. I think we're currently opening a few thousand just for VNC. > > > >Seems to me the best way to handle this is to run an accept() in a > >server and hand the resulting fd to the vnc server in qemu using ... > >wait for it ... SCM_RIGHTS. > > > >I'm just happy every time someone lobs a question into the air that > >can be answered using SCM_RIGHTS. > > That's actually a great idea made even better by the use of SCM_RIGHTS :-) > > I think it's a bit trickier though because ideally you would want to use > the vnc protocol to negotiate which vm you're connecting to. That > implies that you actually need to hand over the fd in a setup state. > It's complicated by any encryption protocol too. The model I had in mind was for the proxy to define a VNC extension that allows the client to query what 'desktops' are available and request switching between them at any time. The list of desktop would of course be authorized per client, and strong authentication is a must for this. Any time a switch was made, the RFB protocol would return to the 'ServerInit' state. The idea is that you should not assume a homogenous environment, and you really don't want to fall down to the lowest common denominator of extensions, nor have the proxy doing re-encoding on the FB data updates. Returning to the ServerInit state allowing the client to re-negotiate the set of encodings for the new desktop, and so the proxy can be fairly stateless and while needing to understand the wire protocol, it can just pass through the actual FB update data unchanged. The combo of the an extension for switching desktops on the fly and the encryption state problem doesn't really seem to fit with passing the VNC FD over with SCM_RIGHTS. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
[Qemu-devel] [FOR 0.12 PATCH v2] Check rom_load_all() return value.
Check rom_load_all() return value.
Also don't make option rom loading failure fatal.
Signed-off-by: Gerd Hoffmann
---
hw/loader.c |2 +-
vl.c|5 -
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/hw/loader.c b/hw/loader.c
index 2d7a2c4..89491a2 100644
--- a/hw/loader.c
+++ b/hw/loader.c
@@ -669,7 +669,7 @@ int rom_load_all(void)
"addr 0x" TARGET_FMT_plx
", size 0x%zx, max 0x" TARGET_FMT_plx ")\n",
rom->name, addr, rom->romsize, rom->max);
-return -1;
+continue;
}
} else {
/* fixed address requested */
diff --git a/vl.c b/vl.c
index fd70caa..fd93a94 100644
--- a/vl.c
+++ b/vl.c
@@ -6049,7 +6049,10 @@ int main(int argc, char **argv, char **envp)
qdev_machine_creation_done();
-rom_load_all();
+if (rom_load_all() != 0) {
+fprintf(stderr, "rom loading failed\n");
+exit(1);
+}
qemu_system_reset();
if (loadvm) {
--
1.6.5.2
Re: [Qemu-devel] Re: [PATCH RFC] virtio: add features qdev property
On 12/14/09 14:59, Michael S. Tsirkin wrote: It's not an easy quesiton. If we do it as disable bits, then we get incompatible machines when running on different hosts. In case that one host supports feature which the other doesn't and the feature isn't masked out? Well, management failure I'd say. The whole point of the compat machine types (and properties used there) is to make sure the vm's are compatible even in case the hosts run different software versions. cheers, Gerd
Re: [Qemu-devel] Re: [PATCH RFC] virtio: add features qdev property
On 12/14/09 14:30, Markus Armbruster wrote: Then the property parser would accepts strings such as 'bit1|bit2' and you can have -device 'virtio-blk-pci,disable=blk-identify|ring-indirect' The driver will just do 'vdev->host_features&= ~disable'. Use of '|' in option argument syntax is user-hostile, because it requires quoting in the shell. What about '+'? I don't care that much. I've picked '|' because it is 'or' in many programming languanges and thus sort of intuitive (at least to me). Using '+' is fine with me too. cheers, Gerd
Re: [Qemu-devel] Re: qdev property bug?
Gerd Hoffmann wrote: On 12/14/09 15:10, Anthony Liguori wrote: The old behavior with two different nic types and -boot n was "undefined". The old etherboot roms were quite large. To large to fit more than one (certainly not two). Two worked with the etherboot roms. Yes, they were 32k. Two did not work though if you were also using extboot (which was 2k). Still, etherboot was not a BEV rom so you couldn't make sense out of two of them anyway (since they hijack int19). Regards, Anthony Liguori
