Re: [Qemu-devel] [PATCH] Remote console access though socket
On Sat, Mar 11, 2006 at 11:22:29PM +0100, Oliver Gerlich wrote: > Daniel Veillard schrieb: > > I need first to find the ports of the > > QEmu instances (plural, if you limit to one per box, then you can block the > > default port number and there would be no problem) on a local machine. I > > don't think that "Multicast DNS"/RendezVous works with random port numbers, > > all it does over normal TCP is scan for local hosts without using DNS > > resolution. Again I don't think it's really the problem I'm trying to solve, > > maybe I just didn't expressed myself clearly :-) > > After experimenting with the avahi apps a bit, I think mDNS can indeed > advertise several services on the same host with different ports! I ran > "avahi-publish -s -H localhost myserver1 _http._tcp 80" in one terminal, > then "avahi-publish -s -H localhost myserver2 _http._tcp 12345" in > another terminal. This advertised two HTTP servers which were running on > my local host, on ports 80 and 12345, under the names myserver1 and > myserver2. > avahi-discover then displayed these two services, with their names and > the correct port numbers. And in konqueror, browsing to "zeroconf:/" > also showed the two "WWW servers" correctly. > > So, this could provide the functionality you were looking for... But it > still has the drawback that zeroconf seems to be quite a big framework, > and it requires multicast DNS in the kernel and such stuff... Ah, okay, well basically once you run you own DNS like service locally this kind of things becomes possible. But yes this is quite a big framework, adding this as a dependency sounds a bit extreme, and I assume it won't work if you don't have an avahi or zeroconf server running. One of the main advantage of QEmu is that its requirement at the system level are very low, I'm not sure we can put gracefully such requirement there :-) But thanks for updating me on this, that's good to know ! Daniel -- Daniel Veillard | Red Hat http://redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu/target-i386 op.c
CVSROOT:/sources/qemu Module name:qemu Branch: Changes by: Paul Brook <[EMAIL PROTECTED]> 06/03/11 14:46:59 Modified files: target-i386: op.c Log message: Add missing FORCE_RET() CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/target-i386/op.c.diff?tr1=1.41&tr2=1.42&r1=text&r2=text ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] reduce magic numbers length to 16 bytes (qemu-binfmt-conf.sh)
> To not make this thread completely useless: I find > /usr/share/misc/file/magic very useful to get machine patterns (as > detected by "file"). Search there for "magic for ELF executables" and > you will find a fairly complete list of machine magic numbers. Or you could just use the official list in the gABI spec: http://www.thescogroup.com/developers/gabi/latest/ch4.eheader.html Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu regression 0.7.2 -> 0.8.0 (ARM user emulation)
On Monday 06 March 2006 14:03, Ulrich Hecht wrote:
> Hi!
>
> On Wednesday 01 March 2006 23:18, Anderson Lizardo wrote:
> > I was having some issues with the latest qemu (ARM user emulation),
> > which I tracked down to the following reduced test case:
> >
> > #include
> > int main(void)
> > {
> > float a, b;
> > a = 0.1f;
> > b = 0.8f;
> > printf("a < b: %d\n", (a < b));
> > return 0;
> > }
>
> This fails because of a bug in the glue code between NWFPE and QEMU. (It
> relies on a specific layout of the CPUARMState structure.)
>...
> +cpsr_write(user_registers,x,~CPSR_M);
This should be CPSR_NZCV. Applied with that change.
Paul
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] reduce magic numbers length to 16 bytes (qemu-binfmt-conf.sh)
Hi, On Sat, 11 Mar 2006, Paul Brook wrote: > > To not make this thread completely useless: I find > > /usr/share/misc/file/magic very useful to get machine patterns (as > > detected by "file"). Search there for "magic for ELF executables" and > > you will find a fairly complete list of machine magic numbers. > > Or you could just use the official list in the gABI spec: > > http://www.thescogroup.com/developers/gabi/latest/ch4.eheader.html ... but be aware they might sue you for using it ;-) Ciao, Dscho ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Set hostname in DHCP response
On 3/11/06, Paul Brook <[EMAIL PROTECTED]> wrote:
> This should be set via -net user,hostname=foo. No need for a separate option.
I agree, since the hostname is relevant only for user-net interfaces.
An updated patch is attached.
The only issue is that there's just a single, global hostname, not a
hostname per user-net interface. On the other hand, I'm not sure if
qemu supports multiple user-net interfaces in the first place. Does
the following configuration make sense?
-net nic,vlan=0 -net user,vlan=0 -net nic,vlan=1 -net user,vlan=1
--Ed
diff -BurN qemu-snapshot-2006-03-06_23.orig/slirp/bootp.c qemu-snapshot-2006-03-06_23/slirp/bootp.c
--- qemu-snapshot-2006-03-06_23.orig/slirp/bootp.c 2005-06-05 17:11:42.0 +
+++ qemu-snapshot-2006-03-06_23/slirp/bootp.c 2006-03-10 07:11:19.0 +
@@ -228,6 +228,16 @@
val = htonl(LEASE_TIME);
memcpy(q, &val, 4);
q += 4;
+
+if (slirp_hostname && *slirp_hostname) {
+val = strlen(slirp_hostname);
+if (val > 32)
+val = 32;
+*q++ = RFC1533_HOSTNAME;
+*q++ = val;
+memcpy(q, slirp_hostname, val);
+q += val;
+}
}
*q++ = RFC1533_END;
diff -BurN qemu-snapshot-2006-03-06_23.orig/slirp/libslirp.h qemu-snapshot-2006-03-06_23/slirp/libslirp.h
--- qemu-snapshot-2006-03-06_23.orig/slirp/libslirp.h 2005-06-05 17:11:42.0 +
+++ qemu-snapshot-2006-03-06_23/slirp/libslirp.h 2006-03-10 06:47:32.0 +
@@ -32,6 +32,7 @@
int guest_port);
extern const char *tftp_prefix;
+extern const char *slirp_hostname;
#ifdef __cplusplus
}
diff -BurN qemu-snapshot-2006-03-06_23.orig/slirp/slirp.c qemu-snapshot-2006-03-06_23/slirp/slirp.c
--- qemu-snapshot-2006-03-06_23.orig/slirp/slirp.c 2005-09-03 10:45:09.0 +
+++ qemu-snapshot-2006-03-06_23/slirp/slirp.c 2006-03-10 06:46:28.0 +
@@ -25,6 +25,8 @@
/* XXX: suppress those select globals */
fd_set *global_readfds, *global_writefds, *global_xfds;
+const char *slirp_hostname = NULL;
+
#ifdef _WIN32
static int get_dns_addr(struct in_addr *pdns_addr)
diff -BurN qemu-snapshot-2006-03-06_23.orig/vl.c qemu-snapshot-2006-03-06_23/vl.c
--- qemu-snapshot-2006-03-06_23.orig/vl.c 2006-02-20 00:33:36.0 +
+++ qemu-snapshot-2006-03-06_23/vl.c 2006-03-13 01:35:45.0 +
@@ -2758,6 +2758,12 @@
} else
#ifdef CONFIG_SLIRP
if (!strcmp(device, "user")) {
+if (get_param_value(buf, sizeof(buf), "hostname", p)) {
+if (slirp_hostname)
+fprintf(stderr, "hostname already set; ignoring hostname=%s\n", buf);
+else
+slirp_hostname = strdup(buf);
+}
ret = net_slirp_init(vlan);
} else
#endif
@@ -4157,8 +4163,9 @@
"-net nic[,vlan=n][,macaddr=addr][,model=type]\n"
"create a new Network Interface Card and connect it to VLAN 'n'\n"
#ifdef CONFIG_SLIRP
- "-net user[,vlan=n]\n"
- "connect the user mode network stack to VLAN 'n'\n"
+ "-net user[,vlan=n][,hostname=host]\n"
+ "connect the user mode network stack to VLAN 'n' and send\n"
+ "hostname 'host' to DHCP clients\n"
#endif
#ifdef _WIN32
"-net tap[,vlan=n],ifname=name\n"
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Set hostname in DHCP response
QEMU doesn't do a great job of supporting multiple user-net interfaces right now. I was testing this the other day and getting some rather odd behavior (unexpected segfaults, etc.) I didn't debug deep enough to figure out the specifics, but having a global state (like slirp is today) for multiple network providers is probably not a good idea. I am contemplating writing a patch that will change the global state in slirp to an actual "opaque" state, even letting various slirp instances be configured to serve different subnets, etc. This would be useful if for example you wanted to have 1 slirp interface access only "special" services, like smb, etc., and another act as a NAT to the internet. In that case, in theory, stuff like VPN software in the guest OS should work without disrupting access to "special" services. But for something like this to truly work, you need to have the ability to configure the subnet that slirp sets up _per NIC_, and that would of course mean removing the global state as the most obvious (and correct IMHO) solution. Others will probably argue that you can use a combination of a single slirp NIC and a NAT tun/tap set up to accomplish the same basic thing today, without any modifications. Still, the "zero" host configuration of slirp makes it very attractive on its own, so I still think the patch I'm referring to would be valuable. I'd also implement an option to make slirp return the DNS/gateway in the DHCP packet for only 1 interface, since guest OS's would probably not like having multiple default gateways. This patch would be useful in a slightly different way even if you were trying to combine slirp with tun/tap, and having the guest OS configured for DHCP on all interfaces. For example, you may want the guest OS to use the tun/tap interface as the default route, so telling the slirp interface to not return a gateway/DNS would probably still be a good idea even if you were only using 1 -net user. That patch by itself would be trivial versus the global->local state patch I mentioned above, so I can see posting that one much sooner, if it even works as I'm expecting it to ;) Regards, Leo Reiter Ed Swierk wrote: I agree, since the hostname is relevant only for user-net interfaces. An updated patch is attached. The only issue is that there's just a single, global hostname, not a hostname per user-net interface. On the other hand, I'm not sure if qemu supports multiple user-net interfaces in the first place. Does the following configuration make sense? -net nic,vlan=0 -net user,vlan=0 -net nic,vlan=1 -net user,vlan=1 --Ed -- Leonardo E. Reiter Vice President of Product Development, CTO Win4Lin, Inc. Virtual Computing from Desktop to Data Center Main: +1 512 339 7979 Fax: +1 512 532 6501 http://www.win4lin.com ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
