Re: [Qemu-devel] [RESEND] [PATCH] Make use of temporaries as registers conditional (fixes gcc4 i386 host)
Alexander Graf wrote:
> Hi,
>
> this is a mostly a resend of the very same patch I sent to the list a
> few days ago. I believe I fixed most issues (wrong endif, gcc3
> breakage). Please tell me if this patch breaks already working setups,
> as it should only make _more_ things work than before.
>
> If anybody has a really valid point for this to not be included into
> qemu, please tell me. I don't really see "I don't like fixing gcc
> dependencies" as such, as that's what had to be done for gcc3 too already.
>
> Regards,
>
> Alex
>
Oops, wrong version :-)
Here we go again...
Alex
Index: qemu/softmmu_header.h
===
--- qemu.orig/softmmu_header.h
+++ qemu/softmmu_header.h
@@ -189,9 +189,15 @@ static inline void glue(glue(st, SUFFIX)
#else
#error unsupported size
#endif
+#ifdef GCC_BREAKS_T_REGISTER
+ "pushl %%ecx\n"
+#endif
"pushl %6\n"
"call %7\n"
"popl %%eax\n"
+#ifdef GCC_BREAKS_T_REGISTER
+ "popl %%ecx\n"
+#endif
"jmp 2f\n"
"1:\n"
"addl 8(%%edx), %%eax\n"
@@ -209,14 +215,22 @@ static inline void glue(glue(st, SUFFIX)
: "r" (ptr),
/* NOTE: 'q' would be needed as constraint, but we could not use it
with T1 ! */
+#if (DATA_SIZE == 1 || DATA_SIZE == 2) && defined(GCC_BREAKS_T_REGISTER)
+ "q" (v),
+#else
"r" (v),
+#endif
"i" ((CPU_TLB_SIZE - 1) << CPU_TLB_ENTRY_BITS),
"i" (TARGET_PAGE_BITS - CPU_TLB_ENTRY_BITS),
"i" (TARGET_PAGE_MASK | (DATA_SIZE - 1)),
"m" (*(uint32_t *)offsetof(CPUState, tlb_table[CPU_MMU_INDEX][0].addr_write)),
"i" (CPU_MMU_INDEX),
"m" (*(uint8_t *)&glue(glue(__st, SUFFIX), MMUSUFFIX))
+#ifdef GCC_BREAKS_T_REGISTER
+ : "%eax", "%edx", "memory", "cc");
+#else
: "%eax", "%ecx", "%edx", "memory", "cc");
+#endif
}
#else
Index: qemu/target-alpha/cpu.h
===
--- qemu.orig/target-alpha/cpu.h
+++ qemu/target-alpha/cpu.h
@@ -275,6 +275,8 @@ struct CPUAlphaState {
* used to emulate 64 bits target on 32 bits hosts
*/
target_ulong t0, t1, t2;
+#elif defined(GCC_BREAKS_T_REGISTER)
+target_ulong t2;
#endif
/* */
double ft0, ft1, ft2;
Index: qemu/target-alpha/exec.h
===
--- qemu.orig/target-alpha/exec.h
+++ qemu/target-alpha/exec.h
@@ -36,6 +36,12 @@ register struct CPUAlphaState *env asm(A
#define T1 (env->t1)
#define T2 (env->t2)
+#elif defined(GCC_BREAKS_T_REGISTER)
+
+register uint64_t T0 asm(AREG1);
+register uint64_t T1 asm(AREG2);
+#define T2 (env->t2)
+
#else
register uint64_t T0 asm(AREG1);
Index: qemu/target-arm/cpu.h
===
--- qemu.orig/target-arm/cpu.h
+++ qemu/target-arm/cpu.h
@@ -66,6 +66,9 @@ typedef uint32_t ARMReadCPFunc(void *opa
*/
typedef struct CPUARMState {
+#if defined(GCC_BREAKS_T_REGISTER)
+uint32_t t2;
+#endif
/* Regs for current mode. */
uint32_t regs[16];
/* Frequently accessed CPSR bits are stored separately for efficiently.
Index: qemu/target-arm/exec.h
===
--- qemu.orig/target-arm/exec.h
+++ qemu/target-arm/exec.h
@@ -23,7 +23,12 @@
register struct CPUARMState *env asm(AREG0);
register uint32_t T0 asm(AREG1);
register uint32_t T1 asm(AREG2);
+#if defined(GCC_BREAKS_T_REGISTER)
+#define T2 (env->t2)
+#else
register uint32_t T2 asm(AREG3);
+#endif
+
/* TODO: Put these in FP regs on targets that have such things. */
/* It is ok for FT0s and FT0d to overlap. Likewise FT1s and FT1d. */
Index: qemu/target-i386/cpu.h
===
--- qemu.orig/target-i386/cpu.h
+++ qemu/target-i386/cpu.h
@@ -470,6 +470,8 @@ typedef struct CPUX86State {
#if TARGET_LONG_BITS > HOST_LONG_BITS
/* temporaries if we cannot store them in host registers */
target_ulong t0, t1, t2;
+#elif defined(GCC_BREAKS_T_REGISTER)
+target_ulong t1;
#endif
/* standard registers */
Index: qemu/target-i386/exec.h
===
--- qemu.orig/target-i386/exec.h
+++ qemu/target-i386/exec.h
@@ -39,6 +39,12 @@ register struct CPUX86State *env asm(ARE
#define T1 (env->t1)
#define T2 (env->t2)
+#elif defined(GCC_BREAKS_T_REGISTER)
+
+register target_ulong T0 asm(AREG1);
+#define T1 (env->t1)
+register target_ulong T2 asm(AREG3);
+
#else
/* XXX: use unsigned long instead of target_ulong - better code will
Index: qemu/target-mips/cpu.h
===
--- qemu.orig/target-mips/cpu.h
+++ qemu/tar
[Qemu-devel] [RESEND] [PATCH] Make use of temporaries as registers conditional (fixes gcc4 i386 host)
Hi,
this is a mostly a resend of the very same patch I sent to the list a
few days ago. I believe I fixed most issues (wrong endif, gcc3
breakage). Please tell me if this patch breaks already working setups,
as it should only make _more_ things work than before.
If anybody has a really valid point for this to not be included into
qemu, please tell me. I don't really see "I don't like fixing gcc
dependencies" as such, as that's what had to be done for gcc3 too already.
Regards,
Alex
Index: qemu/softmmu_header.h
===
--- qemu.orig/softmmu_header.h
+++ qemu/softmmu_header.h
@@ -189,9 +189,15 @@ static inline void glue(glue(st, SUFFIX)
#else
#error unsupported size
#endif
+#ifdef GCC_BREAKS_T_REGISTER
+ "pushl %%ecx\n"
+#endif
"pushl %6\n"
"call %7\n"
"popl %%eax\n"
+#ifdef GCC_BREAKS_T_REGISTER
+ "popl %%ecx\n"
+#endif
"jmp 2f\n"
"1:\n"
"addl 8(%%edx), %%eax\n"
@@ -209,14 +215,22 @@ static inline void glue(glue(st, SUFFIX)
: "r" (ptr),
/* NOTE: 'q' would be needed as constraint, but we could not use it
with T1 ! */
+#if (DATA_SIZE == 1 || DATA_SIZE == 2) && GCC_BREAKS_T_REGISTER
+ "q" (v),
+#else
"r" (v),
+#endif
"i" ((CPU_TLB_SIZE - 1) << CPU_TLB_ENTRY_BITS),
"i" (TARGET_PAGE_BITS - CPU_TLB_ENTRY_BITS),
"i" (TARGET_PAGE_MASK | (DATA_SIZE - 1)),
"m" (*(uint32_t *)offsetof(CPUState, tlb_table[CPU_MMU_INDEX][0].addr_write)),
"i" (CPU_MMU_INDEX),
"m" (*(uint8_t *)&glue(glue(__st, SUFFIX), MMUSUFFIX))
+#ifdef GCC_BREAKS_T_REGISTER
+ : "%eax", "%edx", "memory", "cc");
+#else
: "%eax", "%ecx", "%edx", "memory", "cc");
+#endif
}
#else
Index: qemu/target-alpha/cpu.h
===
--- qemu.orig/target-alpha/cpu.h
+++ qemu/target-alpha/cpu.h
@@ -275,6 +275,8 @@ struct CPUAlphaState {
* used to emulate 64 bits target on 32 bits hosts
*/
target_ulong t0, t1, t2;
+#elif defined(GCC_BREAKS_T_REGISTER)
+target_ulong t2;
#endif
/* */
double ft0, ft1, ft2;
Index: qemu/target-alpha/exec.h
===
--- qemu.orig/target-alpha/exec.h
+++ qemu/target-alpha/exec.h
@@ -36,6 +36,12 @@ register struct CPUAlphaState *env asm(A
#define T1 (env->t1)
#define T2 (env->t2)
+#elif defined(GCC_BREAKS_T_REGISTER)
+
+register uint64_t T0 asm(AREG1);
+register uint64_t T1 asm(AREG2);
+#define T2 (env->t2)
+
#else
register uint64_t T0 asm(AREG1);
Index: qemu/target-arm/cpu.h
===
--- qemu.orig/target-arm/cpu.h
+++ qemu/target-arm/cpu.h
@@ -66,6 +66,9 @@ typedef uint32_t ARMReadCPFunc(void *opa
*/
typedef struct CPUARMState {
+#if defined(GCC_BREAKS_T_REGISTER)
+uint32_t t2;
+#endif
/* Regs for current mode. */
uint32_t regs[16];
/* Frequently accessed CPSR bits are stored separately for efficiently.
Index: qemu/target-arm/exec.h
===
--- qemu.orig/target-arm/exec.h
+++ qemu/target-arm/exec.h
@@ -23,7 +23,12 @@
register struct CPUARMState *env asm(AREG0);
register uint32_t T0 asm(AREG1);
register uint32_t T1 asm(AREG2);
+#if defined(GCC_BREAKS_T_REGISTER)
+#define T2 (env->t2)
+#else
register uint32_t T2 asm(AREG3);
+#endif
+
/* TODO: Put these in FP regs on targets that have such things. */
/* It is ok for FT0s and FT0d to overlap. Likewise FT1s and FT1d. */
Index: qemu/target-i386/cpu.h
===
--- qemu.orig/target-i386/cpu.h
+++ qemu/target-i386/cpu.h
@@ -470,6 +470,8 @@ typedef struct CPUX86State {
#if TARGET_LONG_BITS > HOST_LONG_BITS
/* temporaries if we cannot store them in host registers */
target_ulong t0, t1, t2;
+#elif defined(GCC_BREAKS_T_REGISTER)
+target_ulong t1;
#endif
/* standard registers */
Index: qemu/target-i386/exec.h
===
--- qemu.orig/target-i386/exec.h
+++ qemu/target-i386/exec.h
@@ -39,6 +39,12 @@ register struct CPUX86State *env asm(ARE
#define T1 (env->t1)
#define T2 (env->t2)
+#elif defined(GCC_BREAKS_T_REGISTER)
+
+register target_ulong T0 asm(AREG1);
+#define T1 (env->t1)
+register target_ulong T2 asm(AREG3);
+
#else
/* XXX: use unsigned long instead of target_ulong - better code will
Index: qemu/target-mips/cpu.h
===
--- qemu.orig/target-mips/cpu.h
+++ qemu/target-mips/cpu.h
@@ -149,6 +149,8 @@ struct CPUMIPSState {
target_ulong t0;
target_ulong t1;
targe
Re: [Qemu-devel] WE NEED GCC 4 please
On Jan 21, 2008, at 4:39 AM, Mulyadi Santosa wrote: Hi... If I may jump into the pool... I plan to work around the MinGW issue by guarding the offending part by "#ifdef GCC...", even if I have been told that it works only by chance (but it works, whereas any other option I tried does not). Ehm, should we better wait a bit for fabrice to complete his code code generator? then we can be freed (totally?) from gcc version dependency? it's not that I ignore people's effort to make qemu gcc4 compatible...but I just think it will save us from more work in the future (making it always gcc 3 compatible) and thus progress to more demanding area like truly support SVM/VT, better SMP and so on. Fabrice's code generator works for x86 and x86_64 only. In the second step it _will_ break existing miniops, so all the work put into those will be in vain. I really don't see any valid point not to implement code that makes everything work for gcc4 if it doesn't break existing setups. Actually everyone benefits if there are alternatives. Imagine you could use qemu with gcc3, gcc4 or Fabrice's new approach (probably tcc). This way nobody needs to have a specific version of their compiler suite installed and ppc, s390 etc. will still be supported. Support for SVM/VT is something KVM is about. I completely agree that qemu and kvm should be merged someday, but if I look at the length of discussions and amount of patches actually getting applied to qemu, I rather think it's not the right time to do it. You also get full SMP support from KVM too, so I don't see any valid point in complaining about that in qemu. Regards, Alex
Re: AW: Re: [Qemu-devel] VMport patch
On Jan 21, 2008, at 3:41 AM, Anthony Liguori wrote: Mark Williamson wrote: I think it would be great to maintain compatibility with the binary-only versions of the vm tools though. But you're changing the semantics of the x86 instruction set. You potentially break a real operating system. It also eliminates the possibility of nesting with something like kqemu because you can't trap all PIO operations. Maybe have a commandline flag, and have it switched off by default? Or, even better, would be to detect valid vmware tools behaviour and switch it on iff that happened; the default being to behave normally for OSes that aren't running the VMware tools.. There is no way to know for sure that it's vm-tools running. You would have to make use of the cpu option to support it I reckon. I completely agree with the point of breaking x86 semantics is bad. Yes, it is. What is the point in emulating the VMWare interface though, if the only program actually requiring that interface does not work, namely vmware tools, especially the windows version. So as far as I know VMWare uses VMX to run 64-bit code on Intel as well, so there has to be a way to forcefully break the checks. Regards, Alex Regards, Anthony Liguori Cheers, Mark Regards, Anthony Liguori Regards, Alex - Ursprüngliche Nachricht - Von: Anthony Liguori <[EMAIL PROTECTED]> Gesendet: Sonntag, 20. Januar 2008 22:40 An: qemu-devel@nongnu.org Betreff: Re: [Qemu-devel] VMport patch Filip Navara wrote: Hello, the current version of QEMU emulates the VMware backdoor I/O port and it works quite well. Unfortunately it doesn't emulate the VMware behavior of ignoring the I/O permissions when accessing this special port. The attached patch corrects it. It's important to ignore the permissions, so that user mode VMware tools can communicate to the backdoor. = I really dislike that VMware relies on this. It's very hard to implement in kqemu or KVM. I think it would be better to modify open-vm-tools than to modify QEMU. Regards, Anthony Liguori Best regards, Filip Navara
Re: [Qemu-devel] emulate the Intel-VT behavior on any type of CPU
On Jan 20, 2008, at 8:52 PM, andrzej zaborowski wrote: On 20/01/2008, Alexander Graf <[EMAIL PROTECTED]> wrote: He was talking about running SVM code in KQemu/KVM. It might work with kqemu (I honestly have not tested it, but see no reason it shouldn't), but definitely not with KVM. Simply said, you can not run KVM inside of a KVM virtualized machine. What would be the problem with supporting that in KVM? The host SVM should just report that the guest is trying to execute an SVM insn and generate an Illegal Operation which would be handled by qemu. Regards Yes, you're completely right about this. The main reason it isn't implemented in kvm is that nobody did it yet. It is actually one of the things on my "would like to do"-list, so if things stay the way they are, maybe you will see this feature in kvm someday. Regards, Alex
Re: [Qemu-devel] WE NEED GCC 4 please
Hi... If I may jump into the pool... > I plan to work around the MinGW issue by guarding the offending part by > "#ifdef GCC...", even if I have been told that it works only by chance > (but it works, whereas any other option I tried does not). Ehm, should we better wait a bit for fabrice to complete his code code generator? then we can be freed (totally?) from gcc version dependency? it's not that I ignore people's effort to make qemu gcc4 compatible...but I just think it will save us from more work in the future (making it always gcc 3 compatible) and thus progress to more demanding area like truly support SVM/VT, better SMP and so on. just 2 cents opinion... regards, Mulyadi.
Re: AW: Re: [Qemu-devel] VMport patch
Mark Williamson wrote: I think it would be great to maintain compatibility with the binary-only versions of the vm tools though. But you're changing the semantics of the x86 instruction set. You potentially break a real operating system. It also eliminates the possibility of nesting with something like kqemu because you can't trap all PIO operations. Maybe have a commandline flag, and have it switched off by default? Or, even better, would be to detect valid vmware tools behaviour and switch it on iff that happened; the default being to behave normally for OSes that aren't running the VMware tools.. There is no way to know for sure that it's vm-tools running. You would have to make use of the cpu option to support it I reckon. Regards, Anthony Liguori Cheers, Mark Regards, Anthony Liguori Regards, Alex - Ursprüngliche Nachricht - Von: Anthony Liguori <[EMAIL PROTECTED]> Gesendet: Sonntag, 20. Januar 2008 22:40 An: qemu-devel@nongnu.org Betreff: Re: [Qemu-devel] VMport patch Filip Navara wrote: Hello, the current version of QEMU emulates the VMware backdoor I/O port and it works quite well. Unfortunately it doesn't emulate the VMware behavior of ignoring the I/O permissions when accessing this special port. The attached patch corrects it. It's important to ignore the permissions, so that user mode VMware tools can communicate to the backdoor. = I really dislike that VMware relies on this. It's very hard to implement in kqemu or KVM. I think it would be better to modify open-vm-tools than to modify QEMU. Regards, Anthony Liguori Best regards, Filip Navara
Re: [Qemu-devel] PS/2 mouse support for FC4 guest broken in QEMU 0.9.1
Hi, On Sun, 20 Jan 2008, Even Rouault wrote: > After quite a lot of CVS bisection, [...] Not wanting to advertise git, but to help other people needing to bisect efficiently: here is a recipe how to do this with git. 1. get git (obviously) 2. $ git clone git://repo.or.cz/qemu.git/ (it is a git mirror of git://git.kernel.dk/data/git/qemu.git, so if you do not want to be nice to Jens' server, you can go there directly) 3. Find out what was the last good revision. If you have an approximate date take the first "commit" of the output of $ cd qemu/ $ git log --until="2007/09/07" (It would show a line beginning with "commit " and followed by a 40-character hex sequence; copy that sequence) 4. Start the bisection $ git bisect start $ git bisect bad HEAD $ git bisect good 85f8a4e8bae4df3983a5f1efd62b7942417bb89b Obviously, you have to use the sequence you copied in 3. 5. Compile, test, and call $ git bisect good or $ git bisect bad after the test, depending if the tested revision is good or -- you guessed it -- bad. 6. Repeat 5. until git tells you which is probably the bad commit. Then scrap this clone, or go back to the CVS HEAD with $ git bisect reset You are literally guaranteed to test the minimal amount of revisions with this procedure. Hth, Dscho
Re: [Qemu-devel] WE NEED GCC 4 please
Hi, On Sun, 20 Jan 2008, Andreas Färber wrote: > Am 20.01.2008 um 23:38 schrieb Sunil Amitkumar Janki: > > > Ignoring the fact that the original poster wrote in all caps and can't > > contribute much to qemu development, what is being done or who can > > give directions on what would have to be done to make qemu build using > > gcc4. I'd prefer it too that I wouldn't have to keep an old gcc 3.x > > compiler around specifically to build qemu, so what can we do about > > that? > > I have some more reading to catch up but the last I heard was that > virtually everything worked except for gcc 4.3 and MinGW 3.4.2 and in my > case sh4*-softmmu on OSX/ppc gcc 4.0.1... What to do about any of that I > don't know either. All of sh4-*, in fact. I plan to work around the MinGW issue by guarding the offending part by "#ifdef GCC...", even if I have been told that it works only by chance (but it works, whereas any other option I tried does not). Ciao, Dscho
Re: AW: Re: [Qemu-devel] VMport patch
> > I think it would be great to maintain compatibility with the binary-only > > versions of the vm tools though. > > But you're changing the semantics of the x86 instruction set. You > potentially break a real operating system. It also eliminates the > possibility of nesting with something like kqemu because you can't trap > all PIO operations. Maybe have a commandline flag, and have it switched off by default? Or, even better, would be to detect valid vmware tools behaviour and switch it on iff that happened; the default being to behave normally for OSes that aren't running the VMware tools.. Cheers, Mark > Regards, > > Anthony Liguori > > > Regards, > > > > Alex > > > > - Ursprüngliche Nachricht - > > Von: Anthony Liguori <[EMAIL PROTECTED]> > > Gesendet: Sonntag, 20. Januar 2008 22:40 > > An: qemu-devel@nongnu.org > > Betreff: Re: [Qemu-devel] VMport patch > > > > Filip Navara wrote: > >> Hello, > >> > >> the current version of QEMU emulates the VMware backdoor I/O port and > >> it works quite well. Unfortunately it doesn't emulate the VMware > >> behavior of ignoring the I/O permissions when accessing this special > >> port. The attached patch corrects it. It's important to ignore the > >> permissions, so that user mode VMware tools can communicate to the > >> backdoor. = > > > > I really dislike that VMware relies on this. It's very hard to > > implement in kqemu or KVM. I think it would be better to modify > > open-vm-tools than to modify QEMU. > > > > Regards, > > > > Anthony Liguori > > > >> Best regards, > >> Filip Navara -- Push Me Pull You - Distributed SCM tool (http://www.cl.cam.ac.uk/~maw48/pmpu/)
Re: AW: Re: [Qemu-devel] VMport patch
Alexander Graf wrote: I think it would be great to maintain compatibility with the binary-only versions of the vm tools though. But you're changing the semantics of the x86 instruction set. You potentially break a real operating system. It also eliminates the possibility of nesting with something like kqemu because you can't trap all PIO operations. Regards, Anthony Liguori Regards, Alex - Ursprüngliche Nachricht - Von: Anthony Liguori <[EMAIL PROTECTED]> Gesendet: Sonntag, 20. Januar 2008 22:40 An: qemu-devel@nongnu.org Betreff: Re: [Qemu-devel] VMport patch Filip Navara wrote: Hello, the current version of QEMU emulates the VMware backdoor I/O port and it works quite well. Unfortunately it doesn't emulate the VMware behavior of ignoring the I/O permissions when accessing this special port. The attached patch corrects it. It's important to ignore the permissions, so that user mode VMware tools can communicate to the backdoor. = I really dislike that VMware relies on this. It's very hard to implement in kqemu or KVM. I think it would be better to modify open-vm-tools than to modify QEMU. Regards, Anthony Liguori Best regards, Filip Navara
Re: [Qemu-devel] WE NEED GCC 4 please
On 20 Jan 2008, at 22:56, Mike Frysinger wrote: On Sunday 20 January 2008, Sunil Amitkumar Janki wrote: ...what is being done or who can give directions on what would have to be done to make qemu build using gcc4. as i said, review the archives and you'll find many discussions with real information on the topic http://lists.gnu.org/archive/html/qemu-devel/2008-01/msg00380.html Work forward (by date) from here. Now please stop this pointless thread. *Useful* gcc4 discussion belongs in critique of those patches. (Thanks to Alex et. al., while I'm posting---hopefully this'll be a great boon for getting Q (kju) to build against SVN qemu some day soon!) LionsPhil
Re: [Qemu-devel] emulate the Intel-VT behavior on any type of CPU
> So, as qemu emulates CPU, does it emulates [pacifica|VT] > extensions too? > With a patch? Yes, Qemu 0.91, can emulate AMD Pacifica/SVM, according to: http://fabrice.bellard.free.fr/qemu/changelog.html So yes, theoretically KVM should work inside Qemu, but don't expect real-hardware performance. -- -Alexey Eremenko "Technologov"
Re: [Qemu-devel] WE NEED GCC 4 please
Am 20.01.2008 um 23:38 schrieb Sunil Amitkumar Janki: Ignoring the fact that the original poster wrote in all caps and can't contribute much to qemu development, what is being done or who can give directions on what would have to be done to make qemu build using gcc4. I'd prefer it too that I wouldn't have to keep an old gcc 3.x compiler around specifically to build qemu, so what can we do about that? I have some more reading to catch up but the last I heard was that virtually everything worked except for gcc 4.3 and MinGW 3.4.2 and in my case sh4*-softmmu on OSX/ppc gcc 4.0.1... What to do about any of that I don't know either. Andreas
Re: [Qemu-devel] WE NEED GCC 4 please
On Sunday 20 January 2008, Sunil Amitkumar Janki wrote: > Ignoring the fact that the original poster wrote in all caps and can't > contribute much to qemu development, what is being done or who can > give directions on what would have to be done to make qemu build using > gcc4. I'd prefer it too that I wouldn't have to keep an old gcc 3.x > compiler around specifically to build qemu, so what can we do about > that? as i said, review the archives and you'll find many discussions with real information on the topic -mike signature.asc Description: This is a digitally signed message part.
Re: [Qemu-devel] emulate the Intel-VT behavior on any type of CPU
En réponse à Alexander Graf <[EMAIL PROTECTED]> : > He was talking about running SVM code in KQemu/KVM. It might > work with > kqemu (I honestly have not tested it, but see no reason it > shouldn't), > but definitely not with KVM. Simply said, you can not run KVM > inside > of a KVM virtualized machine. > I just want to run KVM in a non VT machine. And I want to test a lot of things. So if qemu can emulate it, it's really good for me. I need to test hvm-Xen too. So, as qemu emulates CPU, does it emulates [pacifica|VT] extensions too? With a patch? Do you have a link to some docs? thanks Eurolines : Voyagez au meilleur prix : http://www.alinto.com/pub/
Re: [Qemu-devel] WE NEED GCC 4 please
On Jan 20, 2008 11:26 PM, Mike Frysinger <[EMAIL PROTECTED]> wrote: > > On Sunday 20 January 2008, Johannes Schindelin wrote: > > On Sun, 20 Jan 2008, Mike Frysinger wrote: > > > having people type all caps e-mails contributes nothing. > > > > I disagree: it makes it easier to spot whom to ignore. Unless you know > > that person, of course, and respect her, too. > > yes, the caps flags people to ignore, but that isnt what i meant. people who > write all caps e-mails contribute nothing to the problem they're complaining > about. > -mike > Ignoring the fact that the original poster wrote in all caps and can't contribute much to qemu development, what is being done or who can give directions on what would have to be done to make qemu build using gcc4. I'd prefer it too that I wouldn't have to keep an old gcc 3.x compiler around specifically to build qemu, so what can we do about that? Sunil
AW: Re: [Qemu-devel] VMport patch
I think it would be great to maintain compatibility with the binary-only versions of the vm tools though. Regards, Alex - Ursprüngliche Nachricht - Von: Anthony Liguori <[EMAIL PROTECTED]> Gesendet: Sonntag, 20. Januar 2008 22:40 An: qemu-devel@nongnu.org Betreff: Re: [Qemu-devel] VMport patch Filip Navara wrote: > Hello, > > the current version of QEMU emulates the VMware backdoor I/O port and > it works quite well. Unfortunately it doesn't emulate the VMware > behavior of ignoring the I/O permissions when accessing this special > port. The attached patch corrects it. It's important to ignore the > permissions, so that user mode VMware tools can communicate to the > backdoor. = I really dislike that VMware relies on this. It's very hard to implement in kqemu or KVM. I think it would be better to modify open-vm-tools than to modify QEMU. Regards, Anthony Liguori > Best regards, > Filip Navara
Re: [Qemu-devel] PS/2 mouse support for FC4 guest broken in QEMU 0.9.1
After quite a lot of CVS bisection, I've identified revision 1.24 of
hw/pckbd.c ("QEMU keyboard issue with Gujin-2.2") to be responsible for the
regression with the PS/2 mouse for FC4 guests.
With r1.24, I can read in the log of the kernel boot sequence :
"PNP: PS/2 Controller [PNP0303:KBD,PNP0f13:MOU@ at 0x60,0x64 irq 1,12"
Failed to disable AUX port, but continuing anyway... Is this a Sis?
If AUX port is really absent please use the 'i8042.noaux' option.
serio: i8042 KBD PORT at 0x60,0x64 irq 1"
With r1.23, I only get :
"PNP: PS/2 Controller [PNP0303:KBD,PNP0f13:MOU@ at 0x60,0x64 irq 1,12"
serio: i8042 KBD PORT at 0x60,0x64 irq 1"
Le Sunday 20 January 2008 21:58:05 Even Rouault, vous avez écrit :
> Hi,
>
> I've tried QEMU 0.9.1 and PS/2 mouse support for FC4 guest seems to be
> broken. I was using previously a CVS version dating back to 2007/09/07 and
> it works fine with it.
>
> It can be tested by simply running qemu on the FC4-i386-DVD.iso
> installation ISO DVD. Anaconda doesn't manage to find the mouse and fall
> back to text mode. On an already installed image, the mouse doesn't work in
> X or in text mode.
>
> Best regards.
Re: [Qemu-devel] WE NEED GCC 4 please
On Sunday 20 January 2008, Johannes Schindelin wrote: > On Sun, 20 Jan 2008, Mike Frysinger wrote: > > having people type all caps e-mails contributes nothing. > > I disagree: it makes it easier to spot whom to ignore. Unless you know > that person, of course, and respect her, too. yes, the caps flags people to ignore, but that isnt what i meant. people who write all caps e-mails contribute nothing to the problem they're complaining about. -mike signature.asc Description: This is a digitally signed message part.
Re: [Qemu-devel] VMport patch
Filip Navara wrote: Hello, the current version of QEMU emulates the VMware backdoor I/O port and it works quite well. Unfortunately it doesn't emulate the VMware behavior of ignoring the I/O permissions when accessing this special port. The attached patch corrects it. It's important to ignore the permissions, so that user mode VMware tools can communicate to the backdoor. = I really dislike that VMware relies on this. It's very hard to implement in kqemu or KVM. I think it would be better to modify open-vm-tools than to modify QEMU. Regards, Anthony Liguori Best regards, Filip Navara
Re: [Qemu-devel] WE NEED GCC 4 please
Hi, On Sun, 20 Jan 2008, Mike Frysinger wrote: > having people type all caps e-mails contributes nothing. I disagree: it makes it easier to spot whom to ignore. Unless you know that person, of course, and respect her, too. Ciao, Dscho
[Qemu-devel] PS/2 mouse support for FC4 guest broken in QEMU 0.9.1
Hi, I've tried QEMU 0.9.1 and PS/2 mouse support for FC4 guest seems to be broken. I was using previously a CVS version dating back to 2007/09/07 and it works fine with it. It can be tested by simply running qemu on the FC4-i386-DVD.iso installation ISO DVD. Anaconda doesn't manage to find the mouse and fall back to text mode. On an already installed image, the mouse doesn't work in X or in text mode. Best regards.
Re: [Qemu-devel] emulate the Intel-VT behavior on any type of CPU
andrzej zaborowski wrote: On 20/01/2008, Alexander Graf <[EMAIL PROTECTED]> wrote: He was talking about running SVM code in KQemu/KVM. It might work with kqemu (I honestly have not tested it, but see no reason it shouldn't), but definitely not with KVM. Simply said, you can not run KVM inside of a KVM virtualized machine. What would be the problem with supporting that in KVM? The host SVM should just report that the guest is trying to execute an SVM insn and generate an Illegal Operation which would be handled by qemu. Regards right now kvm never call to qemu for cpu emulation, qemu is used just for the devices, if kvm have something that it need to emulate it have a small emulator inside the kernel, (ofcruse with modification what you just said is possible)
Re: [Qemu-devel] WE NEED GCC 4 please
On Sunday 20 January 2008, Sylvain Petreolle wrote: > I think you dont answer his question. ;) his question is bogus. if he spent 5 seconds reading the archives, it isnt like people arent "considering supporting gcc 4". having people type all caps e-mails contributes nothing. either put up and assist the effort or shut it. -mike signature.asc Description: This is a digitally signed message part.
Re: [Qemu-devel] emulate the Intel-VT behavior on any type of CPU
On 20/01/2008, Alexander Graf <[EMAIL PROTECTED]> wrote: > He was talking about running SVM code in KQemu/KVM. It might work with > kqemu (I honestly have not tested it, but see no reason it shouldn't), > but definitely not with KVM. Simply said, you can not run KVM inside > of a KVM virtualized machine. What would be the problem with supporting that in KVM? The host SVM should just report that the guest is trying to execute an SVM insn and generate an Illegal Operation which would be handled by qemu. Regards
Re: [Qemu-devel] emulate the Intel-VT behavior on any type of CPU
Opps, me wrong this time, it should have been private. Didn't notice the reply address is different. Sorry. On Sun, 2008-01-20 at 21:21 +0200, Dor Laor wrote: > Alexey, you're wrong again. > > > svm is supported. > > On Sun, 2008-01-20 at 20:59 +0200, Alexey Eremenko wrote: > > Note however, that as far as I know, all the Qemu accelerators - KQemu > > and KVM do not support this. > > > > >
Re : [Qemu-devel] WE NEED GCC 4 please
I think you dont answer his question. ;) Kind regards, Sylvain Petreolle (aka Usurp) - Message d'origine De : Jérôme PRIOR <[EMAIL PROTECTED]> À : qemu-devel@nongnu.org Envoyé le : Dimanche, 20 Janvier 2008, 19h40mn 29s Objet : Re: [Qemu-devel] WE NEED GCC 4 please > could you please consider supporting gcc 4 ? you can install gcc-3 in other directory and use the --cc= option. On Slackware I just installpkg -root /tmp/gcc3-just-for-qemu gcc-3*tgz ./configure --cc=/tmp/gcc3-just-for-qemu/usr/bin/gcc make ... works fine.
Re: [Qemu-devel] emulate the Intel-VT behavior on any type of CPU
He was talking about running SVM code in KQemu/KVM. It might work with kqemu (I honestly have not tested it, but see no reason it shouldn't), but definitely not with KVM. Simply said, you can not run KVM inside of a KVM virtualized machine. Regards, Alex On Jan 20, 2008, at 8:21 PM, Dor Laor wrote: Alexey, you're wrong again. svm is supported. On Sun, 2008-01-20 at 20:59 +0200, Alexey Eremenko wrote: Note however, that as far as I know, all the Qemu accelerators - KQemu and KVM do not support this.
Re: [Qemu-devel] emulate the Intel-VT behavior on any type of CPU
Alexey, you're wrong again. svm is supported. On Sun, 2008-01-20 at 20:59 +0200, Alexey Eremenko wrote: > Note however, that as far as I know, all the Qemu accelerators - KQemu > and KVM do not support this. >
Re: [Qemu-devel] emulate the Intel-VT behavior on any type of CPU
Note however, that as far as I know, all the Qemu accelerators - KQemu and KVM do not support this. -- -Alexey Eremenko "Technologov"
[Qemu-devel] VMport patch
Hello, the current version of QEMU emulates the VMware backdoor I/O port and it works quite well. Unfortunately it doesn't emulate the VMware behavior of ignoring the I/O permissions when accessing this special port. The attached patch corrects it. It's important to ignore the permissions, so that user mode VMware tools can communicate to the backdoor. Best regards, Filip Navara vmport.patch Description: Binary data
[Qemu-devel] qemu new is release, changelog ?
Hi, qemu 0.9.1 is released, but the changelog is complete ? On irc I read : use -disc ... so I launch my new qemu and I see lot of news options ! Is there other corrections done, not writting on che ChangeLog on the site, like better usage of qcow2 ? thx -- aster
Re: [Qemu-devel] WE NEED GCC 4 please
> could you please consider supporting gcc 4 ? you can install gcc-3 in other directory and use the --cc= option. On Slackware I just installpkg -root /tmp/gcc3-just-for-qemu gcc-3*tgz ./configure --cc=/tmp/gcc3-just-for-qemu/usr/bin/gcc make ... works fine.
Re: [Qemu-devel] emulate the Intel-VT behavior on any type of CPU
Hi, On Jan 20, 2008, at 7:29 PM, octane indice wrote: Hello I'm using qemu a lot for testing. I have to test some scenarios involving intel-VT machines. Can qemu emulates the intel-VT (or AMD pacifica) behavior on any type of machine? SVM (AMD pacifica) is party integrated. You don't have an IOMMU and high SVM exit codes don't work (mostly unused anyway), but apart from that it should be mostly feature-identical to what you get from a real K9 CPU. You are welcome to implement VMX as well ;-). Regards, Alex
[Qemu-devel] emulate the Intel-VT behavior on any type of CPU
Hello I'm using qemu a lot for testing. I have to test some scenarios involving intel-VT machines. Can qemu emulates the intel-VT (or AMD pacifica) behavior on any type of machine? Is it possible? Is it planned? Thank you Eurolines : Voyagez au meilleur prix : http://www.alinto.com/pub/
Re: [kvm-devel] [Qemu-devel] [PATCH 2 of 3] Optionally link against libuuid if present
On Jan 20, 2008 5:53 PM, Alexander Graf <[EMAIL PROTECTED]> wrote: > > On Jan 20, 2008, at 5:37 PM, Filip Navara wrote: > > The specific VMware backdoor call isn't implemented, but the framework is > there and it wouldn't be hard to add support for it. The BIOS can fallback > to some "reasonable" value if the backdoor isn't available. > > > +memset(bios_uuid, 0, 16); > > This value? Why not put something more "reasonable" in there? Does a uuid > have to meet specific criteria (checksums)? If not, why not simply put > something like "QEMU" in here? If I remember correctly OSX needs a value in > the uuid or it fails to boot, so it might be a good idea to give it > something better than an empty string. > Yes, this value. All zeroes means that UUID is not present in the system. The value has to follow the criteria of SMBIOS specification, section 3.3.2.1, namely it has to be formatted like this: DWORD time_low; WORD time_mid; WORD time_high_and_version; BYTE clock_seq_hi_and_reserved; BYTE clock_seq_low; BYTE node_number[6]; I doubt any driver really checks the value, except maybe for the all-0xFF or all-0x00 case. - Filip
Re: [kvm-devel] [Qemu-devel] [PATCH 2 of 3] Optionally link against libuuid if present
On Jan 20, 2008, at 5:37 PM, Filip Navara wrote: The specific VMware backdoor call isn't implemented, but the framework is there and it wouldn't be hard to add support for it. The BIOS can fallback to some "reasonable" value if the backdoor isn't available. +memset(bios_uuid, 0, 16); This value? Why not put something more "reasonable" in there? Does a uuid have to meet specific criteria (checksums)? If not, why not simply put something like "QEMU" in here? If I remember correctly OSX needs a value in the uuid or it fails to boot, so it might be a good idea to give it something better than an empty string. Best regards, Filip Navara On Jan 20, 2008 5:20 PM, Alexander Graf <[EMAIL PROTECTED]> wrote: On Jan 20, 2008, at 2:17 PM, Filip Navara wrote: > Hello, > > attached is a patch that implements the SMBIOS within the Bochs BIOS > code. Complete list of changes: > > - Added generation of SSDT ACPI table that contains definitions for > available processors. > - Added basic implementation of SMBIOS. > - Added querying of BIOS UUID using VMware backdoor I/O port (enable > only if BX_QEMU is defined). > - Added RTC device to ACPI DSDT table. > This is great news. I was eagerly waiting for this. It looks like this fixes most problems I had with running Mac OS X as a guest OS. I will definitely try this tomorrow and tell you the results. Is the VMWare I/O backdoor implemented already or is this patch meant to be applied on top of another patch? Regards, Alex
Re: [kvm-devel] [Qemu-devel] [PATCH 2 of 3] Optionally link against libuuid if present
The specific VMware backdoor call isn't implemented, but the framework is there and it wouldn't be hard to add support for it. The BIOS can fallback to some "reasonable" value if the backdoor isn't available. Best regards, Filip Navara On Jan 20, 2008 5:20 PM, Alexander Graf <[EMAIL PROTECTED]> wrote: > > On Jan 20, 2008, at 2:17 PM, Filip Navara wrote: > > > Hello, > > > > attached is a patch that implements the SMBIOS within the Bochs BIOS > > code. Complete list of changes: > > > > - Added generation of SSDT ACPI table that contains definitions for > > available processors. > > - Added basic implementation of SMBIOS. > > - Added querying of BIOS UUID using VMware backdoor I/O port (enable > > only if BX_QEMU is defined). > > - Added RTC device to ACPI DSDT table. > > > > This is great news. I was eagerly waiting for this. It looks like this > fixes most problems I had with running Mac OS X as a guest OS. I will > definitely try this tomorrow and tell you the results. > > Is the VMWare I/O backdoor implemented already or is this patch meant > to be applied on top of another patch? > > Regards, > > Alex > >
Re: [kvm-devel] [Qemu-devel] [PATCH 2 of 3] Optionally link against libuuid if present
On Jan 20, 2008, at 2:17 PM, Filip Navara wrote: Hello, attached is a patch that implements the SMBIOS within the Bochs BIOS code. Complete list of changes: - Added generation of SSDT ACPI table that contains definitions for available processors. - Added basic implementation of SMBIOS. - Added querying of BIOS UUID using VMware backdoor I/O port (enable only if BX_QEMU is defined). - Added RTC device to ACPI DSDT table. This is great news. I was eagerly waiting for this. It looks like this fixes most problems I had with running Mac OS X as a guest OS. I will definitely try this tomorrow and tell you the results. Is the VMWare I/O backdoor implemented already or is this patch meant to be applied on top of another patch? Regards, Alex
Re: [Qemu-devel] [PATCH 2 of 3] Optionally link against libuuid if present
http://sourceforge.net/tracker/index.php?func=detail&aid=1864692&group_id=12580&atid=312580 - Filip On Jan 20, 2008 3:25 PM, Paul Brook <[EMAIL PROTECTED]> wrote: > On Sunday 20 January 2008, Filip Navara wrote: > > Hello, > > > > attached is a patch that implements the SMBIOS within the Bochs BIOS > code. > > Complete list of changes: > > This should be submitted to the Bochs list. > > Paul > > >
Re: [Qemu-devel] [PATCH 2 of 3] Optionally link against libuuid if present
On Sunday 20 January 2008, Filip Navara wrote: > Hello, > > attached is a patch that implements the SMBIOS within the Bochs BIOS code. > Complete list of changes: This should be submitted to the Bochs list. Paul
Re: [Qemu-devel] [kqemu] BR and presentation
> > > If I'm not mistaken, the 0.9.0 release had an issue with corrupting > > the qcow2 image when it was around 2GB. > > > > Why not using the newest version, 0.9.1? Tom
[Qemu-devel] DSC timeout with a CD as ide1 slave / Lost interrupts without -no-acpi
Returning to an old topic... Christian MICHON wrote: On 8/19/06, J M Cerqueira Esteves <[EMAIL PROTECTED]> wrote: So the "culprit" of the cdrom timeouts seems to be -hdd ... but why? I saw the same things few weeks ago. Since then, I do not use hdd anymore (my qemu host is winXP). My previous issue on this was with QEMU 0.8.2 and kqemu 1.3.0pre9 (in fact the subject was misleading, since I really used -hda .. -hdb .. -hdd .. -cdrom .. -boot d). Now with QEMU 0.9.1 and kqemu 1.3.0pre11 (host: Debian Etch on a Pentium M 1400MHz) I got DSC timeout again when trying to use a cdrom as a slave of ide1 (CD image: Debian netinst CD for i386: debian-40r2-i386-netinst.iso), invoking qemu with vdeq qemu \ -kernel-kqemu -no-acpi \ -m 256 \ -net nic,vlan=0,model=rtl8139,macaddr=$MAC_ADDR_0 \ -net vde,vlan=0,sock=/var/run/vde2/tap-vde-1.ctl \ -drive file=/dev/sda,if=ide,index=2,media=disk \ -drive file=/tmp/debian-40r2-i386-netinst.iso,if=ide,index=3,media=cdrom \ -boot d But if I put the cdrom device as a slave of ide0, file=...,if=ide,index=1,media=cdrom I get no DSC timeouts. By the way, in the few tests I made until now in this Pentium M host (mostly with Debian guest systems) I had to use -no-acpi since otherwise the boot process gets stuck or at least very slow and the guest reports hdc: lost interrupt (or "hda:" or "hdb:" depending on what was the first existing IDE device in the specific guest). This happens also with a Debian virtual machine which was previously running in a P4 host with QEMU 0.8.2 and kqemu 1.3.0pre9 not requiring the -no-acpi option... I'll test a bit more, but apparently I also get *no* such 'lost interrupt' messages with 32-bit guests in a 64-bit host (AMD Athlon 64 3500+, also with Debian Etch and QEMU 0.9.1). Best regards J Esteves
Re: [Qemu-devel] Modding an Arch
On 1/20/08, William Pearson <[EMAIL PROTECTED]> wrote: > I'm hoping to do some research on a slightly odd form of resource > allocation in an arch. Not sure which yet, hoping for some advise. My > only real world assembler practice has been 68K (a while ago), but I > have coded in my own assembler before on another homebrew very limited > odd VM. > > I'm going to be changing these things, whilst keeping the rest constant, > > - how IRQs are assigned to handlers > - how memory is protected > - boot sequence > - security levels > - what the bios does when it finds devices > - possibly adding a few instructions to the arch to facillitate the above > - Paging in some fashion (might be removed) Some of these are handled at OS or bios level, not at hardware level. With Qemu you can change the HW side to whatever you want. > These will be added > > - security in interactions with a special persistant memory (hard > disk alike) which will be what is booted Special flash-like memory is not difficult to emulate. > - a device handled by the arch (rather than software) What arch, host or emulated target? > My goal is to get a demo that works up quickly-ish (a year or two > while learning the arch, doing research and writing a very minimal > demo OS probably in asm), but can also be extended nicely into a > proper working system sometime down the line. I don't care about > backwards compatibility. But easy porting tools across would be nice. > > So my questions are, > > 1) Is qemu a sensible thing to do this in. For most cases yes. Qemu is aiming for fast emulation and therefore takes some shortcuts. That breaks security devices that are based on counting instruction cycles. You also have to consider the BIOS issue, most probably you want to change the BIOS to match the changes, unless you are aiming for a very small embedded system. > 2) If so which arch should I mod Totally biased opinion: Sparc32. The instruction set is very minimal and easy to learn, likewise for MMU and IOMMU. The system architecture is very nice compared to baroque constructions like PC, though documentation can be bit sparse. You have full source for OpenBIOS (Open Firmware), and it also isolates the HW side from OS. That makes adapting Linux to the new HW a bit easier if you want to try an incremental approach. Many university OS projects in the 90s used Sparc. > 3) What should I look at apart from stuff referenced in this thread > > http://lists.gnu.org/archive/html/qemu-devel/2005-12/msg00157.html http://www.openbios.org
[Qemu-devel] How to run gpe on qemu
I want run gpe-image on qemuarm. and I have got a gpe-image through openembedded,like this: [EMAIL PROTECTED]:~/stuff$ bitbake gpe-image NOTE: Handling BitBake files: - (5018/5018) [100 %] NOTE: Parsing finished. 4783 cached, 0 parsed, 235 skipped, 0 masked. NOTE: build 200801181833: started OE Build Configuration: BB_VERSION = "1.89" OE_REVISION= "6c8738ab25503f1d21271ec5f6abc1950ace" TARGET_ARCH= "arm" TARGET_OS = "linux-gnueabi" MACHINE= "qemuarm" DISTRO = "angstrom" The files gpe-image-qemuarm.jffs2 and zImage-qemuarm.bin are created in the path /home/zhjw/stuff/tmp/deploy/glibc/images. The website give me a hit:qemu gpe-image-qemuarm.jffs2 -M versatilepb -m 128 -mtdblock -kernel zImage-qemuarm.bin -no-kqemu -usb it cann't work and error: Kernel Panic - no syncing:VFS: Unable to mount root fs on unknown-block the next is that how I can make it work with qemu command.Such as selecting the parameters "-M" . looking forward for your replay! Zhao Jingwei
