[Qemu-devel] Supplementary bug
Forgot to mention, the KQEMU installer seems to be lacking a check for what version of Windows is in use, this needs fixing too. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Documentation bug in QEMU/KQEMU
It is not mentioned that KQEMU is incompatible with Win98SE. Suggested fix: support Win98SE. Is there a good technical reason why it can't be supported? Temporary workaround: clearly state on the webpage and in documentation that KQEMU is not compatible with Win9x. (This has wasted a considerable amount of the time of myself and others on the forum trying to diagnose the problem.) Other notes: * QEMU still prints a message "Could not open \\.\kqemu" under Win98SE, though FILEMON indicates it is not looking *anywhere* for any KQEMU components. * Also, \\.\kqemu is not a legal pathname under any version of Windows. * Also, there should be an easier way to report bugs which does not require signing up to yet another mailing list. Regards. James Jacobs Amigan Software ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Some usb disk may cause the guest OS not response
I am using qemu-dm 0.8.2 of xen 3.0.3, and found that use "usb_add" command to enable some usb disks may cause the guest OS not responding, while enable other usb disks cause no problem. I searched the archive but didn't found a similar report. Has anyone met the same problem? Thanks Xiaoyang ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Patch: audio/ossaudio.c for OpenBSD
This is relative to the 20070319 snapshot. --- audio/ossaudio.c.orig Mon Feb 5 17:01:54 2007 +++ audio/ossaudio.cSat Mar 10 16:39:38 2007 @@ -21,10 +21,15 @@ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN * THE SOFTWARE. */ +#include #include #include #include +#ifdef __OpenBSD__ +#include +#else #include +#endif #include "vl.h" #define AUDIO_CAP "oss" -- Todd Fries .. [EMAIL PROTECTED] _ | \ 1.636.410.0632 (voice) | Free Daemon Consulting, LLC \ 1.405.227.9094 (voice) | http://FreeDaemonConsulting.com \ 1.866.792.3418 (FAX) | "..in support of free software solutions." \ 250797 (FWD) | \ \\ 37E7 D3EB 74D0 8D66 A68D B866 0326 204E 3F42 004A http://todd.fries.net/pgp.txt ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Guest mouse cursor drawing in SDL
andrzej zaborowski wrote: > (the pixel format of the cursor was the same as the pixel format of DisplayState). I'm not sure if we want to always use the same pixel format - for example with VMware SVGA and SDL in 16 bit mode, the cursor pixel format reported by guest Xorg was 8 bpp. This would mean two conversions instead of one: first VMware SVGA would have to convert 8 -> 16 bpp then SDL 16 -> 1 bpp. VNC expects the cursor data to be in the current pixel format. The nice thing about this approach is you don't need to pass a bunch of pixel info (for instance, you don't need to pass the depth, endianness, etc.). The Cirrus hardware cursor also has to be copied anyway and doing the conversion is really straight forward. One question in my mind is what the alpha mask should look like. All that VNC (and SDL) can use is a 1-bit alpha depth. That's all Cirrus supports too. VMware SVGA supports an 8-bit alpha channel though so it may make sense to design the interface now to support that. VMware SVGA without CAP_ALPHA_CURSOR also does only 1-bit alpha. Maybe we should keep two masks - if the frontend (e.g SDL) supports only 1-bit alpha it would use only this basic mask - if the emulated VGA supports only 1-bit alpha it would leave the other mask opaque. I thought about that. Right now with my patch, the cursor mask is always 1-bit deep. I was thinking that perhaps the right thing to do is to make it always 8-bits deep and then convert in VNC. Do you think using the SDL cursor is all that useful? As soon as gtk widgets get involved, the cursor becomes ARGB so in practice, I'm not sure that it's all that helpful. BTW, I've got the ALPHA_CURSOR working with VNC.. it's very sweet :-) Regards, Anthony Liguori Regards, Andrzej ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] fcntl64 fix
> Now that the dust has settled, I see where the change is probably a > no-op anyway. A quick little test program indicates that on x86_64, > l_start will have an offset of 8 wether the structure is packed or not, > and wether the __pad member is present or not. The unsigned long long is > always going to be aligned to a 8 byte boundary. The __pad member is essential. Your logic is wrong is two ways: a) The struct is packed. This overrides normal alignment and ensures the structure contains no padding. b) long long has whatever alignment the host feels like giving it. There's no guarantee it's going to be 8 byte aligned. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] fcntl64 fix
On [Tue, 20.03.2007 19:05], Stuart Anderson wrote: > Now that the dust has settled, I see where the change is probably a > no-op anyway. A quick little test program indicates that on x86_64, > l_start will have an offset of 8 wether the structure is packed or not, > and wether the __pad member is present or not. The unsigned long long is > always going to be aligned to a 8 byte boundary. Its' architecture specific I think. -- Regards, Kirill A. Shutemov + Belarus, Minsk + Velesys LLC, http://www.velesys.com/ + ALT Linux Team, http://www.altlinux.com/ signature.asc Description: Digital signature ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] fcntl64 fix
On [Tue, 20.03.2007 21:47], Thiemo Seufer wrote:
> Stuart Anderson wrote:
> [snip]
> > --- linux-user/syscall_defs.h.orig 2007-02-23 15:44:47.0 -0500
> > +++ linux-user/syscall_defs.h 2007-02-23 15:44:26.0 -0500
> > @@ -1414,7 +1414,9 @@
> > struct target_eabi_flock64 {
> > short l_type;
> > short l_whence;
> > +#if HOST_LONG_BITS == 32
> > int __pad;
> > +#endif
>
> Still, this part makes no sense to me since it is in a packed struct.
> Can you explain why this works better for you?
Primarily, I also thought that problem is in padding, because, without the
patch F_GETLK, on 32-bit target recognises as F_GETLK64 on 64-bit host.
It's happen because on 64-bit host and 32-bit target F_GETLK == F_GETLK64 ==
TARGET_F_GETLK. So if you're using qemu-arm on 64-bit host and a target eabi
program calls fcntl(fd,F_GETLK,...), target_eabi_flock64 will be used by
mistake. Disabling padding can helps in some trivial cases to pass
pseudo-correct args to fcntl. I guess this part of patch wrong.
Stuart, am I right?
--
Regards, Kirill A. Shutemov
+ Belarus, Minsk
+ Velesys LLC, http://www.velesys.com/
+ ALT Linux Team, http://www.altlinux.com/
signature.asc
Description: Digital signature
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] fcntl64 fix
On Tue, 20 Mar 2007, Thiemo Seufer wrote: Still, this part makes no sense to me since it is in a packed struct. Can you explain why this works better for you? It worked better, in that it fixed a problem that let me continue on to fix other issues. After revisiting fcntl() and coming up with the more comprehensive patch, this change now seems to have no effect, so I must conceed that it is not needed, please drop that part of the patch. Now that the dust has settled, I see where the change is probably a no-op anyway. A quick little test program indicates that on x86_64, l_start will have an offset of 8 wether the structure is packed or not, and wether the __pad member is present or not. The unsigned long long is always going to be aligned to a 8 byte boundary. Stuart Stuart R. Anderson [EMAIL PROTECTED] Network & Software Engineering http://www.netsweng.com/ 1024D/37A79149: 0791 D3B8 9A4C 2CDC A31F BD03 0A62 E534 37A7 9149 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu/fpu softfloat.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Jocelyn Mayer 07/03/20 22:25:37 Modified files: fpu: softfloat.c Log message: Ooops... Typo. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/fpu/softfloat.c?cvsroot=qemu&r1=1.5&r2=1.6 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] RFC: This project needs a stable branch
On Thursday 15 March 2007 14:53, Paul Brook wrote: > > Subsequent releases of the branch would contain no functionality > > enhancements, but just bug fixes, with the eventual aim of achieving > > 'it just works' status for any x86/x86_64 guest I try to install/run. > > I know that's a tall order, and that 0.9.0 may not be able to supply > > that for all guests. But it is an important goal to strive for. > > While I agree stability is a desirable goal, and there is obviously users > want a stable product, I'm not sure a qemu is mature enough to make a > stable branch worthwhile. Especially considering the very limited > technical resources we have available. Limited effort is always a problem, granted. So here's a broader question, which I'm surprised nobody has asked before (afaik). Think forward to a hypothetical QEMU 1.0 release. What criteria are required for such a release? J ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH] i386 return APIC ID with cpuid
Hi, cpuid(01H) on i386 does not return the initial APIC id. The following patch correct this. Bernhard Kauer Index: hw/apic.c === RCS file: /sources/qemu/qemu/hw/apic.c,v retrieving revision 1.12 diff -u -r1.12 apic.c --- hw/apic.c 31 Jan 2007 12:22:18 - 1.12 +++ hw/apic.c 20 Mar 2007 22:13:09 - @@ -816,6 +816,7 @@ env->apic_state = s; apic_init_ipi(s); s->id = last_apic_id++; +env->cpuid_apic_id = s->id; s->cpu_env = env; s->apicbase = 0xfee0 | (s->id ? 0 : MSR_IA32_APICBASE_BSP) | MSR_IA32_APICBASE_ENABLE; Index: target-i386/cpu.h === RCS file: /sources/qemu/qemu/target-i386/cpu.h,v retrieving revision 1.41 diff -u -r1.41 cpu.h --- target-i386/cpu.h 5 Feb 2007 22:06:27 - 1.41 +++ target-i386/cpu.h 20 Mar 2007 22:13:09 - @@ -529,6 +529,7 @@ uint32_t cpuid_xlevel; uint32_t cpuid_model[12]; uint32_t cpuid_ext2_features; +uint32_t cpuid_apic_id; #ifdef USE_KQEMU int kqemu_enabled; Index: target-i386/helper.c === RCS file: /sources/qemu/qemu/target-i386/helper.c,v retrieving revision 1.74 diff -u -r1.74 helper.c --- target-i386/helper.c1 Feb 2007 22:12:19 - 1.74 +++ target-i386/helper.c20 Mar 2007 22:13:10 - @@ -1614,7 +1614,7 @@ break; case 1: EAX = env->cpuid_version; -EBX = 8 << 8; /* CLFLUSH size in quad words, Linux wants it. */ +EBX = (env->cpuid_apic_id << 24) | 8 << 8; /* CLFLUSH size in quad words, Linux wants it. */ ECX = env->cpuid_ext_features; EDX = env->cpuid_features; break; ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu/target-ppc cpu.h exec.h op.c op_helper.c o...
CVSROOT:/sources/qemu Module name:qemu Changes by: Jocelyn Mayer 07/03/20 22:11:31 Modified files: target-ppc : cpu.h exec.h op.c op_helper.c op_helper.h op_mem.h op_template.h translate.c translate_init.c Log message: PowerPC 2.03 SPE extension - first pass. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/cpu.h?cvsroot=qemu&r1=1.27&r2=1.28 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/exec.h?cvsroot=qemu&r1=1.16&r2=1.17 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/op.c?cvsroot=qemu&r1=1.25&r2=1.26 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/op_helper.c?cvsroot=qemu&r1=1.20&r2=1.21 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/op_helper.h?cvsroot=qemu&r1=1.3&r2=1.4 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/op_mem.h?cvsroot=qemu&r1=1.10&r2=1.11 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/op_template.h?cvsroot=qemu&r1=1.6&r2=1.7 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/translate.c?cvsroot=qemu&r1=1.47&r2=1.48 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/translate_init.c?cvsroot=qemu&r1=1.4&r2=1.5 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu/fpu softfloat-native.c softfloat-native.h ...
CVSROOT:/sources/qemu Module name:qemu Changes by: Jocelyn Mayer 07/03/20 22:10:42 Modified files: fpu: softfloat-native.c softfloat-native.h softfloat.c softfloat.h Log message: Add missing softfloat helpers. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/fpu/softfloat-native.c?cvsroot=qemu&r1=1.7&r2=1.8 http://cvs.savannah.gnu.org/viewcvs/qemu/fpu/softfloat-native.h?cvsroot=qemu&r1=1.8&r2=1.9 http://cvs.savannah.gnu.org/viewcvs/qemu/fpu/softfloat.c?cvsroot=qemu&r1=1.4&r2=1.5 http://cvs.savannah.gnu.org/viewcvs/qemu/fpu/softfloat.h?cvsroot=qemu&r1=1.5&r2=1.6 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] fcntl64 fix
Stuart Anderson wrote:
[snip]
> --- linux-user/syscall_defs.h.orig2007-02-23 15:44:47.0 -0500
> +++ linux-user/syscall_defs.h 2007-02-23 15:44:26.0 -0500
> @@ -1414,7 +1414,9 @@
> struct target_eabi_flock64 {
> short l_type;
> short l_whence;
> +#if HOST_LONG_BITS == 32
> int __pad;
> +#endif
Still, this part makes no sense to me since it is in a packed struct.
Can you explain why this works better for you?
Thiemo
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu/linux-user syscall.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer 07/03/20 21:50:52 Modified files: linux-user : syscall.c Log message: fcntl64 fix, by Kirill A. Shutemov. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/syscall.c?cvsroot=qemu&r1=1.93&r2=1.94 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] fcntl64 fix
> struct target_eabi_flock64 {
> short l_type;
> short l_whence;
> +#if HOST_LONG_BITS == 32
> int __pad;
> +#endif
This change is definitely wrong. This is a target structure, and is packed, so
should be independent of the host.
Paul
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] fcntl64 fix
OK, I think I finally have it all sorted out. Sorry if I sounded dense
along the way.. there were multiple variable, which increases the number
of possible combinations quickly.
The patch from Kirill is needed, and makes things better. One thing I
notice with it is that we now handle TARGET_F_GETLK64 in two places,
first in the case for TARGET_NR_fcntl64 (around line 4300), and then
again in do_fcntl(), which is called in the default case of the first
location. Once difference between the two locations is wether or not
the case for EABI is handled.
In addition to Kirill's patch, my original patch for target_eabi_flock64
is still needed as well as an expanded version of the revised patch I
sent later that does target->host strcture mapping for the F_GETLK*
cases.
I have used the fcntl test sets out of the Linux Test Projects to
measure with an without the different parts of these patches. With
the entire set (Which is attached), 16 of the 18 test sets pass
completely, and a significant portion of test14 (one of the two that
don't pass completely) passes as well. The tests in test14 that fail
may be do to a problem with a syscall other than fcntl(), but I haven't
completely resulved it yet. Without my portion of the patch, the results
are much worse (maybe half-ish are passing).
There is something interesting about test18 (the other one that doesn't
pass). It intentionally passes in a bad value (-1) as the 3rd argument
to fcntl(). It is testing wether it will get EFAULT. With these fixes,
qemu will SEGV as it tries to convert the struct flock (or struct
flock64) from target->host, and encounters the bad address that was
passed in. The initial SEGV is caught, but the handler for it then
SEGVs again. Ideally, we could detect that we are inside an emulated
system call, and be able to just return the EFAULT.
I ran the LTP tests for both old ABI and EABI, and got the same results.
Attached is the combined patch for fcntl().
Stuart
Stuart R. Anderson [EMAIL PROTECTED]
Network & Software Engineering http://www.netsweng.com/
1024D/37A79149: 0791 D3B8 9A4C 2CDC A31F
BD03 0A62 E534 37A7 9149--- linux-user/syscall_defs.h.orig 2007-02-23 15:44:47.0 -0500
+++ linux-user/syscall_defs.h 2007-02-23 15:44:26.0 -0500
@@ -1414,7 +1414,9 @@
struct target_eabi_flock64 {
short l_type;
short l_whence;
+#if HOST_LONG_BITS == 32
int __pad;
+#endif
unsigned long long l_start;
unsigned long long l_len;
int l_pid;
Index: linux-user/syscall.c
===
--- linux-user/syscall.c.orig 2007-03-20 16:19:11.0 -0400
+++ linux-user/syscall.c2007-03-20 17:04:40.0 -0400
@@ -2107,6 +2107,13 @@
switch(cmd) {
case TARGET_F_GETLK:
+lock_user_struct(target_fl, arg, 1);
+fl.l_type = tswap16(target_fl->l_type);
+fl.l_whence = tswap16(target_fl->l_whence);
+fl.l_start = tswapl(target_fl->l_start);
+fl.l_len = tswapl(target_fl->l_len);
+fl.l_pid = tswapl(target_fl->l_pid);
+unlock_user_struct(target_fl, arg, 0);
ret = fcntl(fd, cmd, &fl);
if (ret == 0) {
lock_user_struct(target_fl, arg, 0);
@@ -2132,6 +2139,13 @@
break;
case TARGET_F_GETLK64:
+lock_user_struct(target_fl64, arg, 1);
+fl64.l_type = tswap16(target_fl64->l_type) >> 1;
+fl64.l_whence = tswap16(target_fl64->l_whence);
+fl64.l_start = tswapl(target_fl64->l_start);
+fl64.l_len = tswapl(target_fl64->l_len);
+fl64.l_pid = tswap16(target_fl64->l_pid);
+unlock_user_struct(target_fl64, arg, 0);
ret = fcntl(fd, cmd >> 1, &fl64);
if (ret == 0) {
lock_user_struct(target_fl64, arg, 0);
@@ -4201,15 +4215,47 @@
#if TARGET_LONG_BITS == 32
case TARGET_NR_fcntl64:
{
+ int cmd;
struct flock64 fl;
struct target_flock64 *target_fl;
#ifdef TARGET_ARM
struct target_eabi_flock64 *target_efl;
#endif
+ switch(arg2){
+ case TARGET_F_GETLK64:
+ cmd = F_GETLK64;
+ case TARGET_F_SETLK64:
+ cmd = F_SETLK64;
+ case TARGET_F_SETLKW64:
+ cmd = F_SETLKW64;
+ default:
+ cmd = arg2;
+ }
+
switch(arg2) {
-case F_GETLK64:
-ret = get_errno(fcntl(arg1, arg2, &fl));
+case TARGET_F_GETLK64:
+#ifdef TARGET_ARM
+if (((CPUARMState *)cpu_env)->eabi) {
+lock_user_struct(target_efl, arg3, 1);
+fl.l_type = tswap16(target_efl->l_type);
+fl.l_whence = tswap16(target_efl->l_whence);
+fl.l_start = tswap64(target_efl->l_start);
+fl.l_len = tswap64(target_efl->l_len)
Re: [Qemu-devel] [PATCH] fcntl64 fix
On Tue, 20 Mar 2007, Kirill A. Shutemov wrote: No. Remap is needed: $ uname -m; echo -e '#include \nF_GETLK64' | cpp | tail -1 x86_64 5 $ uname -m; echo -e '#include \nF_GETLK64' | cpp | tail -1 armv5l 12 Same for F_SETLK64 and F_SETLKW64. You are right. I had previously printed out the non-64 versions, and they are the same, but we not using those. TARGET_F_GETLK 5 F_GETLK 5 TARGET_F_GETLK64 12 F_GETLK64 5 My confusion... Stuart Stuart R. Anderson [EMAIL PROTECTED] Network & Software Engineering http://www.netsweng.com/ 1024D/37A79149: 0791 D3B8 9A4C 2CDC A31F BD03 0A62 E534 37A7 9149 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] fcntl64 fix
On [Tue, 20.03.2007 14:03], Stuart Anderson wrote: > On Tue, 20 Mar 2007, Kirill A. Shutemov wrote: > > >>What are you using as a test app? > > > >I got error when runing Debian's apt-get and tried to fix it. > > OK, that's what got me started on this one, but I switched to using the > ltp-kernel-test package for a more comprehensive set of tests once I got > past that first eabi structure change. > > >>I think that remapping the constants > >>is needed, but I'm just curious how we seem to be coming up with different > >>parts of the fix when we have the same target/host combination. > > > >I'm not sure that I understand you... > > On the arm/x86_64 combination, I think the host & target cmd values are > the same, so the remapping is a noop. No. Remap is needed: $ uname -m; echo -e '#include \nF_GETLK64' | cpp | tail -1 x86_64 5 $ uname -m; echo -e '#include \nF_GETLK64' | cpp | tail -1 armv5l 12 Same for F_SETLK64 and F_SETLKW64. > It may be needed for other > combinations though. Some architectures have very different values for > constants like this in their ABI. > > I was trying to understand how your fix made apt-get/dpkg happy, or if > you were just using a different app that was hitting a different case > for fcntl(). > > > Stuart > > Stuart R. Anderson [EMAIL PROTECTED] > Network & Software Engineering http://www.netsweng.com/ > 1024D/37A79149: 0791 D3B8 9A4C 2CDC A31F > BD03 0A62 E534 37A7 9149 > > > ___ > Qemu-devel mailing list > Qemu-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/qemu-devel > -- Regards, Kirill A. Shutemov + Belarus, Minsk + Velesys LLC, http://www.velesys.com/ + ALT Linux Team, http://www.altlinux.com/ signature.asc Description: Digital signature ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [Bug] [Patch] MIPS code fails at branch instruction
Hi,
here is the patch which adds a "4KEcR1" CPU (a 4KEc, processor revision 2.2,
with MIPS32 Release 1 (!) instruction set is the heart of the AR7 SoC).
See also include/asm-mips/cpu.h in the Linux kernel sources:
./include/asm-mips/cpu.h:#define PRID_IMP_4KEC 0x8400
./include/asm-mips/cpu.h:#define PRID_IMP_4KECR20x9000
Stefan
PS. Did anybody run my branch test code on other MIPS CPUs?
What was the result?
Sorry, because of trouble with the Savannah CVS server, the patch is not
against CVS.
--- ../branches/head/target-mips/translate_init.c 2007-03-18
01:30:29.0 +0100
+++ target-mips/translate_init.c2007-03-20 18:47:59.0 +0100
@@ -44,6 +44,12 @@
.CP0_Config1 = MIPS_CONFIG1,
},
{
+.name = "4KEcR1",
+.CP0_PRid = 0x00018448,
+.CP0_Config0 = MIPS_CONFIG0,
+.CP0_Config1 = MIPS_CONFIG1,
+},
+{
.name = "24Kf",
.CP0_PRid = 0x00019300,
.CP0_Config0 = MIPS_CONFIG0 | (0x1 << CP0C0_AR),
Thiemo Seufer schrieb:
> Thiemo Seufer wrote:
> [snip]
> I committed something which cover the rest of your patch, and throws
> now a RI exception for branch-in-branch-delay-slot.
>
> For the AR7 case, could you
> - add AR7 as a CPU type
> - handle the interesting cases for AR7 only, after verifying the
> cornercase behaviour of qemu and real hardware is consistent.
>
> The cornercases which come to mind:
> - conditional vs. unconditional branches
> - the various condition types
> - taken vs. non-taken branches
> - linked vs. non-linked branches
> - likely vs. non-likely branches
> - the side effects of j / jal in the delayslot
> - the value of PC/ra (if it changes)
>
> I don't ask for an exhaustive analysis, I just want to see the cases of
> interest covered, so we can be reasonably sure the qemu results will be
> useful for other AR7 users as well.
>
>
> Thiemo
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] fcntl64 fix
On Tue, 20 Mar 2007, Kirill A. Shutemov wrote: What are you using as a test app? I got error when runing Debian's apt-get and tried to fix it. OK, that's what got me started on this one, but I switched to using the ltp-kernel-test package for a more comprehensive set of tests once I got past that first eabi structure change. I think that remapping the constants is needed, but I'm just curious how we seem to be coming up with different parts of the fix when we have the same target/host combination. I'm not sure that I understand you... On the arm/x86_64 combination, I think the host & target cmd values are the same, so the remapping is a noop. It may be needed for other combinations though. Some architectures have very different values for constants like this in their ABI. I was trying to understand how your fix made apt-get/dpkg happy, or if you were just using a different app that was hitting a different case for fcntl(). Stuart Stuart R. Anderson [EMAIL PROTECTED] Network & Software Engineering http://www.netsweng.com/ 1024D/37A79149: 0791 D3B8 9A4C 2CDC A31F BD03 0A62 E534 37A7 9149 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] fcntl64 fix
On [Tue, 20.03.2007 12:53], Stuart Anderson wrote: > On Tue, 20 Mar 2007, Kirill A. Shutemov wrote: > > >>Kiril, > >>What 32 bit host and 64 bit host are you using? I'm working on > >>arm on x86_64, and I'm starting to think that perhaps all of the different > >>parts of the fix are needed to ensure it works correctly on all > >>target/host > >>combinations. > >> > > > >I'm using arm(little-endian) on x86_64. > > That blows that theory 8-). > :) > > What are you using as a test app? I got error when runing Debian's apt-get and tried to fix it. > I think that remapping the constants > is needed, but I'm just curious how we seem to be coming up with different > parts of the fix when we have the same target/host combination. I'm not sure that I understand you... -- Regards, Kirill A. Shutemov + Belarus, Minsk + Velesys LLC, http://www.velesys.com/ + ALT Linux Team, http://www.altlinux.com/ signature.asc Description: Digital signature ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] fcntl64 fix
On Tue, 20 Mar 2007, Kirill A. Shutemov wrote: Kiril, What 32 bit host and 64 bit host are you using? I'm working on arm on x86_64, and I'm starting to think that perhaps all of the different parts of the fix are needed to ensure it works correctly on all target/host combinations. I'm using arm(little-endian) on x86_64. That blows that theory 8-). What are you using as a test app? I think that remapping the constants is needed, but I'm just curious how we seem to be coming up with different parts of the fix when we have the same target/host combination. Stuart Stuart R. Anderson [EMAIL PROTECTED] Network & Software Engineering http://www.netsweng.com/ 1024D/37A79149: 0791 D3B8 9A4C 2CDC A31F BD03 0A62 E534 37A7 9149 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu/hw slavio_timer.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer 07/03/20 16:54:50 Modified files: hw : slavio_timer.c Log message: SlavIO Counter-Timers fix, by Aurelien Jarno. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/slavio_timer.c?cvsroot=qemu&r1=1.4&r2=1.5 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu/hw slavio_intctl.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer 07/03/20 16:52:54 Modified files: hw : slavio_intctl.c Log message: SlavIO interrupt controller fix, by Aurelien Jarno. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/slavio_intctl.c?cvsroot=qemu&r1=1.7&r2=1.8 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu Makefile.target vl.h hw/pckbd.c hw/ps2.c h...
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer 07/03/20 16:45:27 Modified files: . : Makefile.target vl.h hw : pckbd.c ps2.c Added files: hw : vmmouse.c Log message: VMMouse Emulation, by Anthony Liguori. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/Makefile.target?cvsroot=qemu&r1=1.151&r2=1.152 http://cvs.savannah.gnu.org/viewcvs/qemu/vl.h?cvsroot=qemu&r1=1.195&r2=1.196 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pckbd.c?cvsroot=qemu&r1=1.16&r2=1.17 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ps2.c?cvsroot=qemu&r1=1.5&r2=1.6 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/vmmouse.c?cvsroot=qemu&rev=1.1 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] KQEMU Darwin port status?
You may want to hit me with a brick :)
here is a draft not thested or whatever of kqemu-darwin.cpp before I
have to leave...
...just for some ideads.
/note to self
-open a folder in kju svn tonight, so that we don't have to spam
the list to much.
Mike
On 20.03.2007, at 12:58, Mike Kronenberg wrote:
Here we go:
www.kronenberg.org/qemu/qemu-devel-darwin-kqemu-20mar07.tar.bz2
- Made a new IOKit kext proj to match all the kqemu name requirements
- moved kext header inside kqemu-darwin.cpp to lessen stray darwin
related files
- added kqemu-kernel.h to the target
- added kqemu.h to the target
- added stubs from kqemu-kernel.h
- moved the test cases to the "playground"
The kqemuClient is updated to work with the kext and its playground.
Next I will start filling in the stubs and kqemu_open/close and
kqemu_ioctl based on Phils prototype.
- Wondering how to convert a physical address to a page index on...
feel free to be faster :)
Mike
On 20.03.2007, at 09:02, Mike Kronenberg wrote:
Cool :)
just dlded your tarball, and things work well.
I'm about to add the code to the "genuine" kqemu environment. With
kqemu Variables and function stubs.
I hope to post back soon.
Mike
On 20.03.2007, at 03:18, Philip Boulain wrote:
Mike Kronenberg wrote:
> So any suggestions on how to lock user pages in Darwin would be
very welcome.
Philip Boulain wrote:
Thanks; looking at this post, I'm probably barking up the right
tree
Right. I've cobbled up the aformentioned prototype, and it
working insofar that the modified and now-leaky version of Mike's
test client is allocating sequential lumps of memory when you
bash the EXEC button, and I'm getting plausible sequential
physical addresses out; I can also read/write to the memory via
the IOMemoryDescriptor (the client initialises the first uint8 of
the 'lump' to 23, which will appear in the system log/console;
the kext writes 42 to it, which will appear in the client).
http://www.ecs.soton.ac.uk/~prb/junk/qemu-devel-darwin-
kqemu-19mar07.tar.bz2 (1934KB)
Summary of changes to Mike's earlier example:
- 'transporter' struct now has a 'uint8_t* lump_of_ram;' member,
to act as some application-allocated memory (it mallocs (and
never frees, ahem) 2K each EXEC ioctl).
- I dropped Mike's KEXT code into the HelloIOKit example, so
that it does all the IO KEXT initialisation. I'm not convinced
that this is actually necessary.
A side effect is that 'kqemu.ext' is now called
'HelloIOKit.ext'. Please bear with the quick and nasty prototype. ;)
- The KQEMU_EXEC ioctl handling case now:
- Constructs a IOGeneralMemoryDescriptor and initialises it to
point to the lump_of_ram in the transporter struct
- 'Prepares' the Descriptor. I believe that this is performing
the required locking:
"This involves paging in the memory, if necessary, and
wiring it down for the duration of the transfer." [1]
- Prints the physical address to the system log, and does the
aformentioned read/write
- 'Completes' the Descriptor (unlocking)
- Destructs (pedantically: unreferences) the
IOGeneralMemoryDescriptor
[De]constructing a fresh IOGMD each time is rough-prototype-code
garbage. One can be recycled by just calling initWithAddress()
again on it---at a _glance_, it looks like the kqemu_instance
struct would be a sensible place to put it.
Phil
1. http://developer.apple.com/documentation/Darwin/Reference/
KernelIOKitFramework/IOMemoryDescriptor/Classes/
IOMemoryDescriptor/index.html
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
//header start - included to generate less clutter in the kqemu
repository :)
#include
class org_qemu_driver_kqemu : public IOService {
OSDeclareDefaultStructors(org_qemu_driver_kqemu)
public:
virtual bool init(OSDictionary* dictionary = 0);
virtual void free(void);
virtual IOService* probe(IOService* provider, SInt32* score);
virtual bool start(IOService* provider);
virtual void stop(IOService* provider);
};
//header end
#include
#include
#include
#include
#include
#include
#include
#import
//#include "kqemu-darwin.h" //we included the kext header
extern "C" {
#include /* Tutorial says for debug only */
}
#define super IOService
// Second argument must be literal (preprocessor limitation?)
OSDefineMetaClassAndStructors(org_qemu_driver_kqemu, IOService)
/*
*kqemu stuff below
***
*/
//#include
#import "kqemu-kernel.h" //this is the kqemu p
Re: [Qemu-devel] [PATCH] Guest mouse cursor drawing in SDL
On 20/03/07, Anthony Liguori <[EMAIL PROTECTED]> wrote: Thiemo Seufer wrote: > andrzej zaborowski wrote: > >> This should allow the emulated video cards that support hardware >> accelerated cursors to relay the cursor drawing to host, possibly >> using real hardware cursor. This way the guest and host effectively >> share one cursor. Only SDL support is included. Not tested with mice >> that report absolute coordinates. >> >> The cursor does not appear in the framebuffer seen by the guest, it's >> only drawn on the host. One funny effect is that it's not clipped to >> the size of the framebuffer and can stick out of the SDL window. >> >> I think the sdl.c could use a small rewrite to have all cursor hiding >> and showing in one place instead of spread across the file. >> >> VNC support would need employing an extension for this, according to >> Anthony Liguori. VMware made a documented VNC extension that does it. >> > > >> From 3cf77a8b3c80b0306a0e73677ac6faeb1f83e0a2 Mon Sep 17 00:00:00 2001 >> From: Andrzej Zaborowski <[EMAIL PROTECTED]> >> Date: Sun, 11 Mar 2007 15:31:12 +0100 >> Subject: [PATCH] Host-accelerated mouse cursor support in SDL. >> > > This patch breaks scrolling in the cirrus vga framebuffer. > I will try to see why it breaks scrolling after I fix the VMware SVGA. It shouldn't affect anything other than the mouse cursor, and only when enabled by the SVGA. I think we want to expose these functions via DisplayState. It would be nice if the semantics of too were similar to the rest of the functions Agreed. They should be accessed through ds->mouse_set. > (the pixel format of the cursor was the same as the pixel format of DisplayState). I'm not sure if we want to always use the same pixel format - for example with VMware SVGA and SDL in 16 bit mode, the cursor pixel format reported by guest Xorg was 8 bpp. This would mean two conversions instead of one: first VMware SVGA would have to convert 8 -> 16 bpp then SDL 16 -> 1 bpp. One question in my mind is what the alpha mask should look like. All that VNC (and SDL) can use is a 1-bit alpha depth. That's all Cirrus supports too. VMware SVGA supports an 8-bit alpha channel though so it may make sense to design the interface now to support that. VMware SVGA without CAP_ALPHA_CURSOR also does only 1-bit alpha. Maybe we should keep two masks - if the frontend (e.g SDL) supports only 1-bit alpha it would use only this basic mask - if the emulated VGA supports only 1-bit alpha it would leave the other mask opaque. Regards, Andrzej ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Guest mouse cursor drawing in SDL
Thiemo Seufer wrote: andrzej zaborowski wrote: This should allow the emulated video cards that support hardware accelerated cursors to relay the cursor drawing to host, possibly using real hardware cursor. This way the guest and host effectively share one cursor. Only SDL support is included. Not tested with mice that report absolute coordinates. The cursor does not appear in the framebuffer seen by the guest, it's only drawn on the host. One funny effect is that it's not clipped to the size of the framebuffer and can stick out of the SDL window. I think the sdl.c could use a small rewrite to have all cursor hiding and showing in one place instead of spread across the file. VNC support would need employing an extension for this, according to Anthony Liguori. VMware made a documented VNC extension that does it. From 3cf77a8b3c80b0306a0e73677ac6faeb1f83e0a2 Mon Sep 17 00:00:00 2001 From: Andrzej Zaborowski <[EMAIL PROTECTED]> Date: Sun, 11 Mar 2007 15:31:12 +0100 Subject: [PATCH] Host-accelerated mouse cursor support in SDL. This patch breaks scrolling in the cirrus vga framebuffer. I think we want to expose these functions via DisplayState. It would be nice if the semantics of too were similar to the rest of the functions (the pixel format of the cursor was the same as the pixel format of DisplayState). One question in my mind is what the alpha mask should look like. All that VNC (and SDL) can use is a 1-bit alpha depth. That's all Cirrus supports too. VMware SVGA supports an 8-bit alpha channel though so it may make sense to design the interface now to support that. Regards, Anthony Liguori Thiemo ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Guest mouse cursor drawing in SDL
andrzej zaborowski wrote: > This should allow the emulated video cards that support hardware > accelerated cursors to relay the cursor drawing to host, possibly > using real hardware cursor. This way the guest and host effectively > share one cursor. Only SDL support is included. Not tested with mice > that report absolute coordinates. > > The cursor does not appear in the framebuffer seen by the guest, it's > only drawn on the host. One funny effect is that it's not clipped to > the size of the framebuffer and can stick out of the SDL window. > > I think the sdl.c could use a small rewrite to have all cursor hiding > and showing in one place instead of spread across the file. > > VNC support would need employing an extension for this, according to > Anthony Liguori. VMware made a documented VNC extension that does it. > From 3cf77a8b3c80b0306a0e73677ac6faeb1f83e0a2 Mon Sep 17 00:00:00 2001 > From: Andrzej Zaborowski <[EMAIL PROTECTED]> > Date: Sun, 11 Mar 2007 15:31:12 +0100 > Subject: [PATCH] Host-accelerated mouse cursor support in SDL. This patch breaks scrolling in the cirrus vga framebuffer. Thiemo ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Add info commands for serial/parallel devices
"M. Warner Losh" <[EMAIL PROTECTED]> writes: > Const does *NOT* imply that you don't own the memory. Its narrow > meaning is just that the object won't be changed through this > pointer/reference. But free _does_ change the object. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Add info commands for serial/parallel devices
In message: <[EMAIL PROTECTED]> Anthony Liguori <[EMAIL PROTECTED]> writes: : To me, const char * always implies that you don't own the memory. This : is helped by the fact that free doesn't take a const void * and newer : GCC's will complain if you free() a const char *. Sadly, this is a bug, as it precludes the use pattern of initializing char * data, casting it to const char * (a valid cast) and then relying on the compiler to thereafter enforce its constness. Const does *NOT* imply that you don't own the memory. Its narrow meaning is just that the object won't be changed through this pointer/reference. Warner ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] [REPOST] Simplily linux-user/path.c
On [Fri, 23.02.2007 16:58], Thiemo Seufer wrote:
> Kirill A. Shutemov wrote:
> > Fixed version of the patch in the attacment. Please, comment.
> [snip]
> > /* Look for path in emulation dir, otherwise return name. */
> > const char *path(const char *name)
> > {
> > +char *newname = (char *) alloca(strlen(pref)+strlen(name)+1);
> > +struct stat buf;
> > /* Only do absolute paths: quick and dirty, but should mostly be OK.
> > Could do relative by tracking cwd. */
> > -if (!base || name[0] != '/')
> > - return name;
> > +if (!pref || name[0] != '/')
> > +return name;
> > +
> > +strcpy(newname,pref);
> > +strcat(newname,name);
> >
> > -return follow_path(base, name) ?: name;
> > +return stat(newname,&buf) ? name : strdup(newname);
> > }
>
> This leaks memory allocated by strdup(). Also, the old code tries to
> avoid syscalls by memorizing the paths. AFAICS we should do some
> caching here.
Rewritten patch with caching in the attachment. Please, review.
--
Regards, Kirill A. Shutemov
+ Belarus, Minsk
+ Velesys LLC, http://www.velesys.com/
+ ALT Linux Team, http://www.altlinux.com/
--- ../qemu/linux-user/path.c 2007-03-20 12:54:22 +0200
+++ qemu-0.9.0.cvs20070320/linux-user/path.c2007-03-20 16:02:43 +0200
@@ -1,147 +1,75 @@
/* Code to mangle pathnames into those matching a given prefix.
eg. open("/lib/foo.so") => open("/usr/gnemul/i386-linux/lib/foo.so");
-
- The assumption is that this area does not change.
-*/
+ */
#include
-#include
+#include
#include
-#include
#include
-#include
#include
#include "qemu.h"
-struct pathelem
-{
-/* Name of this, eg. lib */
-char *name;
-/* Full path name, eg. /usr/gnemul/x86-linux/lib. */
-char *pathname;
-struct pathelem *parent;
-/* Children */
-unsigned int num_entries;
-struct pathelem *entries[0];
-};
-
-static struct pathelem *base;
-
-/* First N chars of S1 match S2, and S2 is N chars long. */
-static int strneq(const char *s1, unsigned int n, const char *s2)
-{
-unsigned int i;
-
-for (i = 0; i < n; i++)
- if (s1[i] != s2[i])
- return 0;
-return s2[i] == 0;
-}
-
-static struct pathelem *add_entry(struct pathelem *root, const char *name);
-
-static struct pathelem *new_entry(const char *root,
- struct pathelem *parent,
- const char *name)
-{
-struct pathelem *new = malloc(sizeof(*new));
-new->name = strdup(name);
-asprintf(&new->pathname, "%s/%s", root, name);
-new->num_entries = 0;
-return new;
-}
-
-#define streq(a,b) (strcmp((a), (b)) == 0)
-
-static struct pathelem *add_dir_maybe(struct pathelem *path)
-{
-DIR *dir;
+struct path_list_head {
+ struct path_list_head *next;
-if ((dir = opendir(path->pathname)) != NULL) {
- struct dirent *dirent;
-
- while ((dirent = readdir(dir)) != NULL) {
- if (!streq(dirent->d_name,".") && !streq(dirent->d_name,"..")){
- path = add_entry(path, dirent->d_name);
- }
- }
-closedir(dir);
-}
-return path;
-}
-
-static struct pathelem *add_entry(struct pathelem *root, const char *name)
-{
-root->num_entries++;
-
-root = realloc(root, sizeof(*root)
- + sizeof(root->entries[0])*root->num_entries);
-
-root->entries[root->num_entries-1] = new_entry(root->pathname, root, name);
-root->entries[root->num_entries-1]
- = add_dir_maybe(root->entries[root->num_entries-1]);
-return root;
-}
-
-/* This needs to be done after tree is stabalized (ie. no more reallocs!). */
-static void set_parents(struct pathelem *child, struct pathelem *parent)
-{
-unsigned int i;
+ char* orig_path;
+ char* dest_path;
+};
-child->parent = parent;
-for (i = 0; i < child->num_entries; i++)
- set_parents(child->entries[i], child);
-}
+static struct path_list_head* list_head;
void init_paths(const char *prefix)
{
if (prefix[0] != '/' ||
-prefix[0] == '\0' ||
-!strcmp(prefix, "/"))
+prefix[0] == '\0' ||
+!strcmp(prefix, "/"))
return;
-base = new_entry("", NULL, prefix+1);
-base = add_dir_maybe(base);
-if (base->num_entries == 0) {
-free (base);
-base = NULL;
-} else {
-set_parents(base, base);
-}
-}
-
-/* FIXME: Doesn't handle DIR/.. where DIR is not in emulated dir. */
-static const char *
-follow_path(const struct pathelem *cursor, const char *name)
-{
-unsigned int i, namelen;
+ list_head = malloc(sizeof(struct path_list_head));
-name += strspn(name, "/");
-namelen = strcspn(name, "/");
-
-if (namelen == 0)
- return cursor->pathname;
-
-if (strneq(name, namelen, ".."))
- return follow_path(cursor->parent, name + namelen);
-
-if (strneq(name, namelen, "."))
- return follow_path(cursor, name + namelen);
-
-
Re: [Qemu-devel] [PATCH] Add info commands for serial/parallel devices
Thiemo Seufer wrote:
Anthony Liguori wrote:
Howdy,
The following patch adds an info serial and an info parallel command.
Besides providing useful information (especially for the serial port),
it provides a method for management tools to connect to a running VM and
what character devices the serial/parallel ports have been redirected to.
The format of the info is similar to that of info block.
[snip]
diff -r 18e99d1e8814 vl.c
--- a/vl.c Sat Mar 03 21:18:48 2007 -0600
+++ b/vl.c Sat Mar 03 21:33:07 2007 -0600
@@ -2884,66 +2884,73 @@ CharDriverState *qemu_chr_open(const cha
CharDriverState *qemu_chr_open(const char *filename)
{
const char *p;
+CharDriverState *chr;
if (!strcmp(filename, "vc")) {
-return text_console_init(&display_state);
+chr = text_console_init(&display_state);
} else if (!strcmp(filename, "null")) {
-return qemu_chr_open_null();
+chr = qemu_chr_open_null();
} else
if (strstart(filename, "tcp:", &p)) {
-return qemu_chr_open_tcp(p, 0, 0);
+chr = qemu_chr_open_tcp(p, 0, 0);
} else
if (strstart(filename, "telnet:", &p)) {
-return qemu_chr_open_tcp(p, 1, 0);
+chr = qemu_chr_open_tcp(p, 1, 0);
} else
if (strstart(filename, "udp:", &p)) {
-return qemu_chr_open_udp(p);
+chr = qemu_chr_open_udp(p);
} else
if (strstart(filename, "mon:", &p)) {
CharDriverState *drv = qemu_chr_open(p);
if (drv) {
drv = qemu_chr_open_mux(drv);
monitor_init(drv, !nographic);
-return drv;
-}
-printf("Unable to open driver: %s\n", p);
-return 0;
+chr = drv;
+} else {
+ printf("Unable to open driver: %s\n", p);
+ return 0;
+ }
} else
#ifndef _WIN32
if (strstart(filename, "unix:", &p)) {
- return qemu_chr_open_tcp(p, 0, 1);
+ chr = qemu_chr_open_tcp(p, 0, 1);
} else if (strstart(filename, "file:", &p)) {
-return qemu_chr_open_file_out(p);
+chr = qemu_chr_open_file_out(p);
} else if (strstart(filename, "pipe:", &p)) {
-return qemu_chr_open_pipe(p);
+chr = qemu_chr_open_pipe(p);
} else if (!strcmp(filename, "pty")) {
-return qemu_chr_open_pty();
+chr = qemu_chr_open_pty();
} else if (!strcmp(filename, "stdio")) {
-return qemu_chr_open_stdio();
+chr = qemu_chr_open_stdio();
} else
#endif
#if defined(__linux__)
if (strstart(filename, "/dev/parport", NULL)) {
-return qemu_chr_open_pp(filename);
+chr = qemu_chr_open_pp(filename);
} else
if (strstart(filename, "/dev/", NULL)) {
-return qemu_chr_open_tty(filename);
+chr = qemu_chr_open_tty(filename);
} else
#endif
#ifdef _WIN32
if (strstart(filename, "COM", NULL)) {
-return qemu_chr_open_win(filename);
+chr = qemu_chr_open_win(filename);
} else
if (strstart(filename, "pipe:", &p)) {
-return qemu_chr_open_win_pipe(p);
+chr = qemu_chr_open_win_pipe(p);
} else
if (strstart(filename, "file:", &p)) {
-return qemu_chr_open_win_file_out(p);
-}
+chr = qemu_chr_open_win_file_out(p);
+} else
#endif
{
return NULL;
}
+
+if (chr)
+ chr->filename = strdup(filename);
+
+return chr;
Why is this part needed?
So that info seral|parallel can spit out the name used to create open
the device.
It has to be strdup()'d b/c it's passed in as a const char. There's no
guarantee that memory will stay around.
}
void qemu_chr_close(CharDriverState *chr)
diff -r 18e99d1e8814 vl.h
--- a/vl.h Sat Mar 03 21:18:48 2007 -0600
+++ b/vl.h Sat Mar 03 21:33:07 2007 -0600
@@ -307,6 +307,7 @@ typedef struct CharDriverState {
void *opaque;
int focus;
QEMUBH *bh;
+char *filename;
} CharDriverState;
const char * ?
To me, const char * always implies that you don't own the memory. This
is helped by the fact that free doesn't take a const void * and newer
GCC's will complain if you free() a const char *.
Regards,
Anthony Liguori
Thiemo
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] fcntl64 fix
On [Tue, 20.03.2007 09:55], Stuart Anderson wrote: > > On Tue, 20 Mar 2007, Kirill A. Shutemov wrote: > > >Yep. You're right. Fixed patch in the attachment. > > Kiril, > What 32 bit host and 64 bit host are you using? I'm working on > arm on x86_64, and I'm starting to think that perhaps all of the different > parts of the fix are needed to ensure it works correctly on all target/host > combinations. > I'm using arm(little-endian) on x86_64. -- Regards, Kirill A. Shutemov + Belarus, Minsk + Velesys LLC, http://www.velesys.com/ + ALT Linux Team, http://www.altlinux.com/ signature.asc Description: Digital signature ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] KQEMU Darwin port status?
Here we go: www.kronenberg.org/qemu/qemu-devel-darwin-kqemu-20mar07.tar.bz2 - Made a new IOKit kext proj to match all the kqemu name requirements - moved kext header inside kqemu-darwin.cpp to lessen stray darwin related files - added kqemu-kernel.h to the target - added kqemu.h to the target - added stubs from kqemu-kernel.h - moved the test cases to the "playground" The kqemuClient is updated to work with the kext and its playground. Next I will start filling in the stubs and kqemu_open/close and kqemu_ioctl based on Phils prototype. - Wondering how to convert a physical address to a page index on... feel free to be faster :) Mike On 20.03.2007, at 09:02, Mike Kronenberg wrote: Cool :) just dlded your tarball, and things work well. I'm about to add the code to the "genuine" kqemu environment. With kqemu Variables and function stubs. I hope to post back soon. Mike On 20.03.2007, at 03:18, Philip Boulain wrote: Mike Kronenberg wrote: > So any suggestions on how to lock user pages in Darwin would be very welcome. Philip Boulain wrote: Thanks; looking at this post, I'm probably barking up the right tree Right. I've cobbled up the aformentioned prototype, and it working insofar that the modified and now-leaky version of Mike's test client is allocating sequential lumps of memory when you bash the EXEC button, and I'm getting plausible sequential physical addresses out; I can also read/write to the memory via the IOMemoryDescriptor (the client initialises the first uint8 of the 'lump' to 23, which will appear in the system log/console; the kext writes 42 to it, which will appear in the client). http://www.ecs.soton.ac.uk/~prb/junk/qemu-devel-darwin- kqemu-19mar07.tar.bz2 (1934KB) Summary of changes to Mike's earlier example: - 'transporter' struct now has a 'uint8_t* lump_of_ram;' member, to act as some application-allocated memory (it mallocs (and never frees, ahem) 2K each EXEC ioctl). - I dropped Mike's KEXT code into the HelloIOKit example, so that it does all the IO KEXT initialisation. I'm not convinced that this is actually necessary. A side effect is that 'kqemu.ext' is now called 'HelloIOKit.ext'. Please bear with the quick and nasty prototype. ;) - The KQEMU_EXEC ioctl handling case now: - Constructs a IOGeneralMemoryDescriptor and initialises it to point to the lump_of_ram in the transporter struct - 'Prepares' the Descriptor. I believe that this is performing the required locking: "This involves paging in the memory, if necessary, and wiring it down for the duration of the transfer." [1] - Prints the physical address to the system log, and does the aformentioned read/write - 'Completes' the Descriptor (unlocking) - Destructs (pedantically: unreferences) the IOGeneralMemoryDescriptor [De]constructing a fresh IOGMD each time is rough-prototype-code garbage. One can be recycled by just calling initWithAddress() again on it---at a _glance_, it looks like the kqemu_instance struct would be a sensible place to put it. Phil 1. http://developer.apple.com/documentation/Darwin/Reference/ KernelIOKitFramework/IOMemoryDescriptor/Classes/IOMemoryDescriptor/ index.html ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] fcntl64 fix
Yep. You're right. Fixed patch in the attachment.
On [Mon, 19.03.2007 17:12], Thiemo Seufer wrote:
> Kirill A. Shutemov wrote:
> > TARGET_F_*64 should be used instead of F_*64, because on 64-bit host
> > systems F_GETLK == F_GETLK64(same for SETLK and SETLKW), so we cannot
> > determinate if it's a long lock or not on a target 32-bit system.
> > Patch in the attachment.
> >
> > P.S. Please, review my privious patches, which I have added description
> > recently. Or should I repost it?
> >
>
> > diff -uNr qemu-0.9.0.cvs20070304.orig/linux-user/syscall.c
> > qemu-0.9.0.cvs20070304/linux-user/syscall.c
> > --- qemu-0.9.0.cvs20070304.orig/linux-user/syscall.c2007-03-09
> > 20:08:59 +0200
> > +++ qemu-0.9.0.cvs20070304/linux-user/syscall.c 2007-03-09 20:09:54
> > +0200
> > @@ -4063,7 +4063,7 @@
> > #endif
> >
> > switch(arg2) {
> > -case F_GETLK64:
> > +case TARGET_F_GETLK64:
> > ret = get_errno(fcntl(arg1, arg2, &fl));
>
> This changes the bug from checking the wrong flag to (potentially)
> passing down the wrong flag...
>
> > if (ret == 0) {
> > #ifdef TARGET_ARM
> > @@ -4089,8 +4089,8 @@
> > }
> > break;
> >
> > -case F_SETLK64:
> > -case F_SETLKW64:
> > +case TARGET_F_SETLK64:
> > +case TARGET_F_SETLKW64:
> > #ifdef TARGET_ARM
> > if (((CPUARMState *)cpu_env)->eabi) {
> > lock_user_struct(target_efl, arg3, 1);
>
> Likewise here. We should always check TARGET_* flags and pass down the
> corresponding host flag.
diff -uNr qemu-0.9.0.cvs20070320.orig/linux-user/syscall.c
qemu-0.9.0.cvs20070320/linux-user/syscall.c
--- qemu-0.9.0.cvs20070320.orig/linux-user/syscall.c2007-03-20 13:26:04
+0200
+++ qemu-0.9.0.cvs20070320/linux-user/syscall.c 2007-03-20 13:34:09 +0200
@@ -4058,15 +4058,27 @@
#if TARGET_LONG_BITS == 32
case TARGET_NR_fcntl64:
{
+ int cmd;
struct flock64 fl;
struct target_flock64 *target_fl;
#ifdef TARGET_ARM
struct target_eabi_flock64 *target_efl;
#endif
+switch(arg2){
+case TARGET_F_GETLK64:
+cmd = F_GETLK64;
+case TARGET_F_SETLK64:
+cmd = F_SETLK64;
+case TARGET_F_SETLKW64:
+cmd = F_SETLK64;
+default:
+cmd = arg2;
+}
+
switch(arg2) {
-case F_GETLK64:
-ret = get_errno(fcntl(arg1, arg2, &fl));
+case TARGET_F_GETLK64:
+ret = get_errno(fcntl(arg1, cmd, &fl));
if (ret == 0) {
#ifdef TARGET_ARM
if (((CPUARMState *)cpu_env)->eabi) {
@@ -4091,8 +4103,8 @@
}
break;
-case F_SETLK64:
-case F_SETLKW64:
+case TARGET_F_SETLK64:
+case TARGET_F_SETLKW64:
#ifdef TARGET_ARM
if (((CPUARMState *)cpu_env)->eabi) {
lock_user_struct(target_efl, arg3, 1);
@@ -4113,10 +4125,10 @@
fl.l_pid = tswapl(target_fl->l_pid);
unlock_user_struct(target_fl, arg3, 0);
}
-ret = get_errno(fcntl(arg1, arg2, &fl));
+ret = get_errno(fcntl(arg1, cmd, &fl));
break;
default:
-ret = get_errno(do_fcntl(arg1, arg2, arg3));
+ret = get_errno(do_fcntl(arg1, cmd, arg3));
break;
}
break;
signature.asc
Description: Digital signature
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [Bug] [Patch] MIPS code fails at branch instruction
Alexander Voropay wrote: > "Thiemo Seufer" <[EMAIL PROTECTED]> wrote: > > >For the AR7 case, could you > >- add AR7 as a CPU type > >- handle the interesting cases for AR7 only, after verifying the > > cornercase behaviour of qemu and real hardware is consistent. > > AFAIK, Texas Instrument AR7 isn't a CPU. It's a SoC which > combines well-known MIPS 4KEc synthesizable *core* and ADSL stuff. Other 4KEc behave differently (probably due to differences in the synthesizing technology used), so I figure AR7 becomes a special CPU for qemu's purposes. Thiemo ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [Bug] [Patch] MIPS code fails at branch instruction
"Thiemo Seufer" <[EMAIL PROTECTED]> wrote: For the AR7 case, could you - add AR7 as a CPU type - handle the interesting cases for AR7 only, after verifying the cornercase behaviour of qemu and real hardware is consistent. AFAIK, Texas Instrument AR7 isn't a CPU. It's a SoC which combines well-known MIPS 4KEc synthesizable *core* and ADSL stuff. http://www.linux-mips.org/wiki/AR7 -- -=AV=- ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] KQEMU Darwin port status?
Cool :) just dlded your tarball, and things work well. I'm about to add the code to the "genuine" kqemu environment. With kqemu Variables and function stubs. I hope to post back soon. Mike On 20.03.2007, at 03:18, Philip Boulain wrote: Mike Kronenberg wrote: > So any suggestions on how to lock user pages in Darwin would be very welcome. Philip Boulain wrote: Thanks; looking at this post, I'm probably barking up the right tree Right. I've cobbled up the aformentioned prototype, and it working insofar that the modified and now-leaky version of Mike's test client is allocating sequential lumps of memory when you bash the EXEC button, and I'm getting plausible sequential physical addresses out; I can also read/write to the memory via the IOMemoryDescriptor (the client initialises the first uint8 of the 'lump' to 23, which will appear in the system log/console; the kext writes 42 to it, which will appear in the client). http://www.ecs.soton.ac.uk/~prb/junk/qemu-devel-darwin- kqemu-19mar07.tar.bz2 (1934KB) Summary of changes to Mike's earlier example: - 'transporter' struct now has a 'uint8_t* lump_of_ram;' member, to act as some application-allocated memory (it mallocs (and never frees, ahem) 2K each EXEC ioctl). - I dropped Mike's KEXT code into the HelloIOKit example, so that it does all the IO KEXT initialisation. I'm not convinced that this is actually necessary. A side effect is that 'kqemu.ext' is now called 'HelloIOKit.ext'. Please bear with the quick and nasty prototype. ;) - The KQEMU_EXEC ioctl handling case now: - Constructs a IOGeneralMemoryDescriptor and initialises it to point to the lump_of_ram in the transporter struct - 'Prepares' the Descriptor. I believe that this is performing the required locking: "This involves paging in the memory, if necessary, and wiring it down for the duration of the transfer." [1] - Prints the physical address to the system log, and does the aformentioned read/write - 'Completes' the Descriptor (unlocking) - Destructs (pedantically: unreferences) the IOGeneralMemoryDescriptor [De]constructing a fresh IOGMD each time is rough-prototype-code garbage. One can be recycled by just calling initWithAddress() again on it---at a _glance_, it looks like the kqemu_instance struct would be a sensible place to put it. Phil 1. http://developer.apple.com/documentation/Darwin/Reference/ KernelIOKitFramework/IOMemoryDescriptor/Classes/IOMemoryDescriptor/ index.html ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
