Re: [Qemu-devel] qemu and kernel 2.6.18
Hello,
bringing up the tun/tap interface depends now on the capability CAP_NET_ADMIN,
which usually only root has.
This patch just removes this dependency, so normal user rights suffices again
to bring up the tun/tap interface.
diff -ruN linux-2.6.18-orig/drivers/net/tun.c linux-2.6.18/drivers/net/tun.c
--- linux-2.6.18-orig/drivers/net/tun.c 2006-09-20 05:42:06.0 +0200
+++ linux-2.6.18/drivers/net/tun.c 2006-10-02 09:21:52.0 +0200
@@ -489,9 +489,6 @@
err = -EINVAL;
- if (!capable(CAP_NET_ADMIN))
- return -EPERM;
-
/* Set dev type */
if (ifr-ifr_flags IFF_TUN) {
/* TUN device */
chris
##
On Fri, 13 Oct 2006 13:00:10 -0400
WaxDragon [EMAIL PROTECTED] wrote:
This came up in IRC a few days ago, it seems you need to use the UML
util 'tunctl' to assign permissions to the tap device. I found this
change annoying.
On 10/13/06, G Portokalidis [EMAIL PROTECTED] wrote:
Hello all,
I have recently installed the latest linux kernel, and i have been
having problems with the tap interface since.
I have been getting the following cryptic message:
warning: could not configure /dev/net/tun: no virtual network emulation
Could not initialize device 'tap'
The tun driver is loaded, and /dev/net/tun is 'rw'.
Any ideas what this is about? Could i have misconfigured something in
the kernel?
Cheers,
George
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
--
22:38 @WaxDragon false ^ true
22:39 false :(
22:39 false dont you think you can XOR me and get away with it! I
always return!
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Chris Friedhoff
[EMAIL PROTECTED]
2.6.18-tun-without-cap_net_admin-capability.patch.bz2
Description: Binary data
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu-system-sparc question?
There's no such think as an Ideal cpu. It's like picking the right religion :-) If you want a toy cpu, there are things like mmix. In general true. But the real and toy CPUs are designed with the hardware construction in mind, whereas the limitations deriving from HW (number of registers, number of instructions, instruction complexity) may be less relevant in the Qemu case. Also Qemu could benefit from getting information analysed from the source code that no real HW needs. For example, perhaps the TB state could be managed explicitly by the compiler. Though I doubt the near native speed performance with kqemu can ever be exceeded with a translator even with all compiler assistance tricks. For other goals (like enhancing security), different methods could be tried, for example it's hard for virus writers to target a dynamic or even encrypted instruction set. Or make stack exploits difficult by giving the CPU separate stack pointers for function arguments, return addresses and local variables. _ Don't just search. Find. Check out the new MSN Search! http://search.msn.com/ ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
RE: [Qemu-devel] SUNWqemu-0.8.2, REV=2006.10.14-sol8-sparc-opt.pkg released
A few comments on the patches: Is there some problem that can't be fixed with the sparc64.ld instead of disabling it for Solaris? The ARM/MIPS bits could be rewritten more generally with #ifdef AREG0 instead of _sparc_. Maybe these would be better handled once in dyngen-exec.h so that that the targets don't assume they get any asm registers. Why do you reorder the registers in Sparc? The int64_t issue could be checked with configure, resulting in HAS_INT64 #defined as needed. _ FREE pop-up blocking with the new MSN Toolbar - get it now! http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/ ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu-system-sparc question?
On Saturday 14 October 2006 09:14, Blue Swirl wrote: There's no such think as an Ideal cpu. It's like picking the right religion :-) If you want a toy cpu, there are things like mmix. In general true. But the real and toy CPUs are designed with the hardware construction in mind, whereas the limitations deriving from HW (number of registers, number of instructions, instruction complexity) may be less relevant in the Qemu case. Also Qemu could benefit from getting information analysed from the source code that no real HW needs. For example, perhaps the TB state could be managed explicitly by the compiler. There are plenty of pre-existing dynamic compilation targets, pretty much all of which have JIT compilers. eg. JVM, CIL and parrot. IMHO qemu probably isn't a particularly good base for this sort of thing, as it's more oriented towards emulating conventional CPUs. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] SUNWqemu-0.8.2,REV=2006.10.14-sol8-sparc-opt.pkg released
Blue Swirl wrote: Is there some problem that can't be fixed with the sparc64.ld instead of disabling it for Solaris? Yes and no. The problem is gnu-ld vs. sun-ld, rather than Linux vs. Solaris. I cannot find an equivalent option for sun-ld. 32bit sparc.ld is also disabled under Solaris for that reason, and has always been. OpenSolaris is still based on its own SUNW-toolchain, not on binutils. (though I'm not sure about Nextenda/GNU-Solaris) Even though OpenSolaris can optionally be compiled with SUNW's gcc 3.4.x now (/usr/sfw/bin/gcc), it still uses its own /usr/ccs/bin/as and ld. All gcc-packages offered on Solaris freeware sites are also built not to use gas or gnu-ld. If you simply make a dirty symlink to /usr/ccs/bin/[as|ld] small things may build and link just good enough. But qemu doesn't, because certain dependencies (like -lm) are skipped / not considered valid, for some reason. It all _might_ potentially work when one would build a complete toolchain only for the purpose of getting qemu built with sparc32: LDFLAGS+=-Wl,-T,$(SRC_PATH)/sparc.ld and sparc64: LDFLAGS+=-Wl,-T,$(SRC_PATH)/sparc64.ld But the resulting performance benefit may be zero, if not negative: SUNW's assembler and linker are not bad, especially on sparc. The ARM/MIPS bits could be rewritten more generally with #ifdef AREG0 instead of _sparc_. Maybe these would be better handled once in dyngen-exec.h so that that the targets don't assume they get any asm registers. Yes, of course. But I plan to use a faster method and to actually use as much as possible physical host registers (see sparc-target directly below). Why do you reorder the registers in Sparc? Dumb trying-out is sometimes the only wayout: I *tried* all possible combinations of registers in a systematic testing-approach (I only did this on the sparc-target so far, need to do the same for mips and arm). The assignments in the patch are the best I could get (as many as possible fast host registers, rather than slow main memory locations). Any other order of assignments resulted in segfaults. That's why everything appears to be out of order in target-sparc/exec.h. And if I would bring target-sparc/exec.h in order again, by changing the AREG assignments in dyngen-exec.h, I would mess up all the other targets like i386-softmmu and x86_64-softmmu. One odd observation: If I try to make use of AREG1 in target-sparc/exec.h, it would _always_ result in a segfault in gen_code_buffer(), no matter at all, which physical sparc host-register I would have assigned to AREG1 in dyngen-exec.h. There is something that makes AREG1 itself unusable on sparc hosts for all other emulation targets, except i386-softmmu, x86_64-softmmu (and maybe ppc-softmmu). The int64_t issue could be checked with configure, resulting in HAS_INT64 #defined as needed. Yep. Thanks for your feedback. And for your good work on the sparc target(s). The Solaris_sparc guest 32bit kernel still died a month ago, did you make progress? Are there ways to lern from the now open source sun4v's OBP to see, what SUNW's proprietary OBP handles differently, when compared to the public ieee1275-1994 standard or other implementations like SmartFirmware? (wasn't there a SUNW-compatibility #ifdef in SmartFirmware [I don't have that code] ? ) May it be possible, to employ SUNW's sun4v OBP in a potential future sun4v emulation target (i.e. as -M option of sparc64-softmmu)? ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Re: Hello
please ask Eric Lowe. I did not prepare the x64/x86 stuff. And the sdl amd64 bit patch is also from him. The SDL patch is from Juergen Zimmermann. I have not had any problems building 64-bit using --prefix /wherever/i/please to both QEMU and SDL's configure scripts; note that adding wherever libSDL winds up ($PFX/bin) to your PATH prior to configuring QEMU is a requirement so that QEMU will link to the right spot - Eric ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Re: Hello
Eric Lowe wrote: please ask Eric Lowe. I did not prepare the x64/x86 stuff. And the sdl amd64 bit patch is also from him. Before I finally go: I just learned, that the term stuff has a negative side-meaning: http://dict.tu-chemnitz.de/dings.cgi?lang=enservice=en-deopterrors=0optpro=0query=stuffdlink=selfcomment= That was by no means my intention ! Further: I didn't mention, that Eric Lowe is the guy, who ported the BSD-kqemu-wrapper to Solaris x86 and x64. Cool! Well done !! -martin The SDL patch is from Juergen Zimmermann. I have not had any problems building 64-bit using --prefix /wherever/i/please to both QEMU and SDL's configure scripts; note that adding wherever libSDL winds up ($PFX/bin) to your PATH prior to configuring QEMU is a requirement so that QEMU will link to the right spot - Eric ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] SUNWqemu-0.8.2, REV=2006.10.14-sol8-sparc-opt.pkg released
The problem is gnu-ld vs. sun-ld, rather than Linux vs. Solaris. I cannot find an equivalent option for sun-ld. 32bit sparc.ld is also disabled under Solaris for that reason, and has always been. Thanks for the long explanation, I asked because the script was a quick hack. One odd observation: If I try to make use of AREG1 in target-sparc/exec.h, it would _always_ result in a segfault in gen_code_buffer(), no matter at all, which physical sparc host-register I would have assigned to AREG1 in dyngen-exec.h. There is something that makes AREG1 itself unusable on sparc hosts for all other emulation targets, except i386-softmmu, x86_64-softmmu (and maybe ppc-softmmu). Linux libc uses %g1 without saving in setjmp, maybe Solaris has the same problem. I haven't found any free three global registers which would work. Using local registers would solve this problem, but then no functions outside the TB couldn't access T0-2. Maybe we could use global registers for T0 and T1 and env-T2 for T2? The Solaris_sparc guest 32bit kernel still died a month ago, did you make progress? Is there an installation disk somewhere for sparc32? I thought the last Solaris supporting V8 CPUs was Solaris 8, which was very much not free. Are there ways to lern from the now open source sun4v's OBP to see, what SUNW's proprietary OBP handles differently, when compared to the public ieee1275-1994 standard or other implementations like SmartFirmware? (wasn't there a SUNW-compatibility #ifdef in SmartFirmware [I don't have that code] ? ) Someone with advanced Forth skills could try to find the differences. The sun4v model is a bit different from sun4u and sun4m, OBP just talks to the hypervisor. May it be possible, to employ SUNW's sun4v OBP in a potential future sun4v emulation target (i.e. as -M option of sparc64-softmmu)? Sure. The existing unfinished sun4u code could be enhanced with the needed sun4v features. But there is still much to do with the common stuff, like adding VIS instructions, interrupt handling and PCI. Maybe you could try to add sparc_v8plus support for the Linux user emulator to polish the CPU? Or add emulation for Linux userland on Solaris? _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu-0.8.2 i386 -kernel hangs when gdt and idt are zero length
Hi, Under qemu-0.8.2 when emulating i386 -kernel in protected mode, and if both the idt and gdt have length zero, then trying to load a segment register loops for a very long time. cli lidtl empty_idt lgdtl empty_gdt # %cs info persists in internal registers movl $0x18,%eax movl %eax,%ds # qemu-0.8.2 hangs here .data empty_idt: .short 0 # length is zero .long 0 empty_gdt: .short 0 # length is zero .long 0 Because the gdt has length 0, then the descriptor for segment 0x183 does not exist in memory. The Intel manual claims the hardware gives #GP(selector) fault for loading the segment register when the selector index is not within limits, but delivery of the exception depends on the idt. When the idt also has zero length, then real hardware enters double-fault territory (perhaps triple-fault?) and shuts down. It would be nice if qemu emulation detected such a situation, then issued an informative message, in addition to looping forever as an emulation of hardware shutdown. -- John Reiser, [EMAIL PROTECTED] ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
