Re: [CFT][PATCH] Netfront fixes for FreeBSD-head
On Mon, 12 Sep 2011, Justin T. Gibbs wrote: I'm planning to ask RE for permission to merge the following netfront fixes (listed below) into 9.0/head. Excellent! I was already assuming that 9.0 is going to be as broken with Xen as 8.2. Before I do so, I'd appreciate some community testing on the proposed patch set (attached). The main areas of concern are: [..] o Compatibility with configurations enabling ioemu on an interface. Unfortunately I do not have the previous Xen setup available any more. I had it temporarily for evaluating virtualized FreeBSD and that evaluation ended with a conclusion that something else is a better solution in that particular case. However, after reading your patch, the MAC/ioemu/do something smart part of the patch looks good to me. Please go ahead. The other parts look sensible as well but I am not familiar enough with the code to really say so. -- Janne Snabb / EPIPE Communications sn...@epipe.com - http://epipe.com/ ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to freebsd-xen-unsubscr...@freebsd.org
Re: Clock drift issues
On Mon, 30 May 2011, Alex wrote: The clock is Sync'd though, it should *stay* correct, right? So there is a bug? My experience is also that the clock is not stable on FreeBSD 8.X guest on Xen and KVM HVM. It is unusable as a ntp server for other hosts and I need to run ntpd to prevent the guest clock from drifting and jumping. Some times I get syslog messages about the time going backwards, which is probably related: calcru: runtime went backwards from 41668 usec to 35093 usec for pid 96767 (bash) I have not tried this with the CURRENT kernel (which has new and configurable event timer infrastructure by mav@). (Linux guests are fine for running ntp server within Xen KVM.) -- Janne Snabb / EPIPE Communications sn...@epipe.com - http://epipe.com/ ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to freebsd-xen-unsubscr...@freebsd.org
Re: Some success, some questions
On Tue, 24 May 2011, Sean Bruno wrote: I've installed a netbsd-current dom0 and the 3.3.2 xen hypervisor on Why such an old version? Wouldn't it make sense to use 4.1? 1. How do I switch the networking vif entry to use the netfront xn0 driver instead of emulating a e1000? Change: builder='hvm' to: builder='linux' Note that you need to define the kernel also and load it from dom0 (unless you are using some PV capable loader which understands FreeBSD file systems... I don't know if such a thing exists works). -- Janne Snabb / EPIPE Communications sn...@epipe.com - http://epipe.com/ ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to freebsd-xen-unsubscr...@freebsd.org
Re: Some success, some questions
On Wed, 25 May 2011, Hugo Silva wrote: On 05/25/11 12:55, Janne Snabb wrote: builder='linux' [..] Does this work with 9-CURRENT/amd64? I'm under the impression you can't boot a 8.X/amd64 in full PV mode. Did it change in current? I thought that was the way I configured my Xen when I was recently trying out 8.2 and CURRENT with PV drivers before concluding that it is unusable for my needs. Now that you mentioned I am probably confused with the 32 bit (i386) config with XEN kernel. I have wiped my previous testing setup with something else, so I can not check any more. Sorry. -- Janne Snabb / EPIPE Communications sn...@epipe.com - http://epipe.com/ ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to freebsd-xen-unsubscr...@freebsd.org
Re: Panic XENHVM
On Sat, 21 May 2011, Sean Bruno wrote: xn0: Error 2 parsing device/vif/0/mac [..] panic: do something smart This is becoming a FAQ. It is a known bug which affects lots of people. Have a look at: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/154302 In summary: You need to remove ioemu from Xen vif definition (if possible) or you need to patch the kernel source. -- Janne Snabb / EPIPE Communications sn...@epipe.com - http://epipe.com/ ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to freebsd-xen-unsubscr...@freebsd.org
Re: [FreeBSD 8.2 amd64 XENHVM] DomU terrible network performance trought NAT
On Thu, 12 May 2011, Laurent Cligny wrote: All FreeBSD VM are 8.2 amd64 with XENHVM kernel anf the Linux VM is a Paravirtualized Debian amd64. My suggestion would be to try out the same setup with GENERIC kernel and the rtl driver (or even better e1000 if your Xen allows it) which is easy to do to make a simple comparison. In one of my recent benchmarks the FreeBSD Xen PV network driver performed very well in one direction, but very badly in the other. Using rtl or e1000 gave much better TCP throughput if you care equally about both directions. This benchmark was done only for internal TCP traffic between a Linux dom0 and FreeBSD dumU, the traffic never entered a real NIC. This might or might not help in your situation... -- Janne Snabb / EPIPE Communications sn...@epipe.com - http://epipe.com/ ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to freebsd-xen-unsubscr...@freebsd.org
Re: [FreeBSD 8.2 amd64 XENHVM] DomU terrible network performance trought NAT
On Thu, 12 May 2011, Justin T. Gibbs wrote: Do you recall which path was slow (rx or tx from the perspective of the FreeBSD driver) and what the relative difference in performance was between the two approaches? No, which is really stupid (that is why I haven't published these numbers before). The numbers are as follows, for simple iperf TCP test, with all networking, kernel, etc. settings on default values: input (Mbit/s) output (Mbit/s) Xen FreeBSD (rtl) 724 200 Xen FreeBSD (xn) 441700 Xen Linux (xn) 85702340 KVM FreeBSD (e1000) 475 495 KVM FreeBSD (rtl)1100 85 KVM Linux (e1000) 785 890 KVM Linux (virtio)585 715 dom0 - dom0 18500 18500 The table above will probably not render correctly, but hopefully it is somewhat readable. The first column indicates the hypervisor used, the guest OS and the network driver in the guest. dom0 was running Debian's 2.6.32-5-amd64 Linux kernel. Xen was Debian's 4.0.1. Linux guests were running Debian's 2.6.32-5-amd64. FreeBSD was 8.2 amd64 with the too many frags and panic: do something smart patches to make it usable with Xen at all. I did not test multiple concurrent connections, multiple virtual machines transferring data simultaneously, mixtures of different kinds of data, CPU load nor anything like that which is also relevant. Only the raw TCP speed was measured to figure out if there is any significant difference: and yes there was as can be seen from the numbers above. Unfortunately I have no recollection and forgot to write down if input was input from dom0's perspective or domU's perspective. They should be the same way around for all the tests though. My lesson was that it does make sense to select your network drivers carefully in a virtualized environment. I also tried two different virtio patches for FreeBSD with KVM, but one of them did not work at all and the another one gave worse results than any sensible emulated hardware. -- Janne Snabb / EPIPE Communications sn...@epipe.com - http://epipe.com/ ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to freebsd-xen-unsubscr...@freebsd.org
Re: kern/154302: Linux suffers from the same problem
The following reply was made to PR kern/154302; it has been noted by GNATS. From: Janne Snabb sn...@epipe.com To: bug-follo...@freebsd.org Cc: Subject: Re: kern/154302: Linux suffers from the same problem Date: Tue, 5 Apr 2011 08:47:26 + (UTC) Just an interesting note about this issue: I noticed that Linux suffers from the same problem. The Linux driver is somehow able to proceed even though getting the mac address fails. Therefore this Xen bug/feature does not cause headaches there, even though we need a workaround in FreeBSD driver. Have a look at Red Hat's virtualization guide: http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html/Virtualization/sect-Virtualization-Troubleshooting_the_Xen_para_virtualized_drivers-Verifying_the_para_virtualized_drivers_have_successfully_loaded.html There you will see the following line: vif vif-0: 2 parsing device/vif/0/mac ...which is an indication of this very same error condition. However according to the Red Hat documentation this just means that the PV drivers have successfully loaded :). -- Janne Snabb / EPIPE Communications sn...@epipe.com - http://epipe.com/ ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to freebsd-xen-unsubscr...@freebsd.org
Re: XENHVM amd64 mouse issue
On Sun, 30 Jan 2011, Nick Sayer wrote: I have 8.2-RC2 + the netfront patch and a XENHVM kernel. I note that I wind up with both ums0 and psm0, but it turns out neither appears to work. My VNC console works for text video and keyboard, but trying to run a moused for either device doesn't result in the text console mouse pointer moving. Mouse clicks do appear to do something, however. I don't ever see the psm device show up in the vmstat -i output, FWIW. I do not use a mouse much with Xen myself and have not had issues with it when I had to, but in the past people have reported a lot of issues with Xen and broken mouse. The solution for some people seems to be to use a tablet emulation instead of mouse. Google for xen tablet. I do not know if FreeBSD has the corresponding driver and moused support, but it might be worth checking out. -- Janne Snabb / EPIPE Communications sn...@epipe.com - http://epipe.com/ ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to freebsd-xen-unsubscr...@freebsd.org
HOWTO: xen tools within FreeBSD domU
I wanted to look at xenstore contents from my domU. domU does not have access to all data but the entries related to the domU instance in question are available. I am posting this in case it happens to be useful to someone else. It would be easy to make a xenstore-clients or xen-tools-domU port. Here is how to get a working xenstore-ls command and other xen tools for your FreeBSD domU: Building installation --- Prerequisites: gmake, XENHVM or XEN kernel (GENERIC will not work) 1. ftp http://bits.xensource.com/oss-xen/release/4.0.1/xen-4.0.1.tar.gz 2. tar xvfz xen-4.0.1.tar.gz 3. cd xen-4.0.1/tools 4. gmake -C include 5. cd misc 6. gmake xen-detect 7. install xen-detect /usr/local/bin 8. cd ../xenstore 9. Build client library and programs: gmake clients 10. Install client library and programs: install libxenstore.so.3.0 /usr/local/lib install xenstore xenstore-control /usr/local/bin cd /usr/local/bin ln xenstore xenstore-chmod ln xenstore xenstore-exists ln xenstore xenstore-list ln xenstore xenstore-ls ln xenstore xenstore-read ln xenstore xenstore-rm ln xenstore xenstore-write Usage - 1. Set required environment variable: export XENSTORED_PATH=/dev/xen/xenstore (Alternatively you could patch tools/xenstore/xs_lib.c function xs_domain_dev() before compiling.) 2. Now you can do things such as: xen-detect xenstore-ls device xenstore-ls -f /local/domain/0/backend/vif/11/0 xenstore-read name Best Regards, -- Janne Snabb / EPIPE Communications sn...@epipe.com - http://epipe.com/ ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to freebsd-xen-unsubscr...@freebsd.org
Re: HOWTO: xen tools within FreeBSD domU
On Sun, 30 Jan 2011, Nick Sayer wrote: If no one else is working on it, I might take a cut at a xen-domU-tools port that does what that page lists. I say give it a shot. It would be useful. Send me a message if you wish me to check/review the port before you send-pr it. In addition to patching the xenstore device name, I suppose that the shared library version numbering should be changed to match what it says in the Porters Handbook[1]: Try to keep shared library version numbers in the libfoo.so.0 format. Our runtime linker only cares for the major (first) number. This probably requires patching tools/xenstore/Makefile. [1]: http://www.freebsd.org/doc/en/books/porters-handbook/special.html#PORTING-SHLIBS -- Janne Snabb / EPIPE Communications sn...@epipe.com - http://epipe.com/ ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to freebsd-xen-unsubscr...@freebsd.org
Re: Issue with non-PAE enable i386 xen guest
On Mon, 24 Jan 2011, karim.allah.ah...@gmail.com wrote: Is the current non-PAE xen guest implementation broke intentionally, or is this a merge issue or something ? According to http://wiki.freebsd.org/FreeBSD/Xen it is not supposed to work: Para-virtualized i386 kernels require options PAE to be included in the kernel configuration. -- Janne Snabb / EPIPE Communications sn...@epipe.com - http://epipe.com/ ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to freebsd-xen-unsubscr...@freebsd.org
Re: I have a problem with iSCSI on AMD64 Xen HVM
On Mon, 24 Jan 2011, Grzegorz Rybicki wrote:
xennet_get_responses: too many frags 11 max 5
[..]
The following in sys/dev/xen/netfront/netfront.c xennet_get_responses()
looks a little bit suspicious:
int max = 5 /* MAX_TX_REQ_FRAGS + (rx-status = RX_COPY_THRESHOLD) */;
...together with the check at the end of the function (the only place
where max is used) which produces the error message you see:
if (unlikely(frags max)) {
if (net_ratelimit())
WPRINTK(Too many frags\n);
printf(%s: too many frags %d max %d\n, __func__, frags,
max);
err = E2BIG;
}
MAX_TX_REQ_FRAGS is defined as follows in the same file:
#define MAX_TX_REQ_FRAGS (65536 / PAGE_SIZE + 2)
...which produces already 18. Where does this max = 5 come from?
Either max is wrong or I do not understand the comment on the
line where it is defined.
There are some interesting and probably related comments in the
same file about the Linux netback driver's lacking capabilities of
handling many fragments. But why do we care about that when receiving?
I would guestimate that either max should be higher than what it
currently is (5) or the check which produces the error might be
unneeded.
--
Janne Snabb / EPIPE Communications
sn...@epipe.com - http://epipe.com/
___
freebsd-xen@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to freebsd-xen-unsubscr...@freebsd.org
Re: FreeBSD-amd64 in Xen 4.0?
On Thu, 20 Jan 2011, Janne Snabb wrote: I am not sure if this is the cause of your problem though, but your configuration might create an environment which is not suitable for the HVM kernel to run. Martin, I tried this out with Xen 4.0.1 and had the same effect as you: Xend died due to signal 11! if I attempted loading the XENHVM kernel with kernel = /within/dom0/path/to/freebsd/kernel in xen config. With kernel = /path/to/hvmloader things work fine (the FreeBSD kernel and boot loader residing within the virtual disk of the virtual machine, the same way as it would be on a physical machine). This is the proper way to use the amd64 XENHVM kernel. Best Regards, -- Janne Snabb / EPIPE Communications sn...@epipe.com - http://epipe.com/ ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to freebsd-xen-unsubscr...@freebsd.org
Re: xn0: Error 2 parsing device/vif/0/mac [PATCH]
On Sat, 15 Jan 2011, Janne Snabb wrote:
On Sat, 15 Jan 2011, Janne Snabb wrote:
It appears that that the netfront driver fails to get the vif mac
address which leads to panic shortly afterwards.
The patch at the bottom of this message solves the problem for me.
This patch might be a bit neater. I found out about
xenbus_get_otherend_path().
Best Regards,
--
Janne Snabb / EPIPE Communications
sn...@epipe.com - http://epipe.com/
--- sys/dev/xen/netfront/netfront.c.orig2010-12-21 17:09:25.0
+
+++ sys/dev/xen/netfront/netfront.c 2011-01-17 10:11:06.0 +
@@ -401,13 +401,14 @@
xen_net_read_mac(device_t dev, uint8_t mac[])
{
int error, i;
char *s, *e, *macstr;
- error = xs_read(XST_NIL, xenbus_get_node(dev), mac, NULL,
- (void **) macstr);
- if (error)
+ if ((error = xs_read(XST_NIL, xenbus_get_node(dev), mac, NULL,
+ (void **) macstr)) != 0
+ (error = xs_read(XST_NIL, xenbus_get_otherend_path(dev),
+ mac, NULL, (void **) macstr) != 0))
return (error);
s = macstr;
for (i = 0; i ETHER_ADDR_LEN; i++) {
mac[i] = strtoul(s, e, 16);
___
freebsd-xen@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to freebsd-xen-unsubscr...@freebsd.org
Re: xn0: Error 2 parsing device/vif/0/mac [PATCH]
On Sat, 15 Jan 2011, Janne Snabb wrote:
It appears that that the netfront driver fails to get the vif mac
address which leads to panic shortly afterwards.
The patch at the bottom of this message solves the problem for me.
After that the current 8.2RC2 system works fine on amd64 with XENHVM
kernel with Xen 4.0.1 (have not tested other versions).
If the mac node does not appear in the front-end vif directory
(does it ever appear there? in my experience no), we fetch a link
to the backend directory for the same vif and try to get the mac
node from there.
I am not sure if this is the proper way to fix this, but it works
for me.
I can send-pr this if desired.
Best Regards,
--
Janne Snabb / EPIPE Communications
sn...@epipe.com - http://epipe.com/
--- sys/dev/xen/netfront/netfront.c.orig2010-12-21 17:09:25.0
+
+++ sys/dev/xen/netfront/netfront.c 2011-01-15 10:01:12.0 +
@@ -399,16 +399,30 @@
*/
static int
xen_net_read_mac(device_t dev, uint8_t mac[])
{
int error, i;
- char *s, *e, *macstr;
+ char *s, *e, *macstr, *backend;
error = xs_read(XST_NIL, xenbus_get_node(dev), mac, NULL,
(void **) macstr);
- if (error)
- return (error);
+
+ if (error) {
+ error = xs_read(XST_NIL, xenbus_get_node(dev), backend, NULL,
+ (void **) backend);
+
+ if (error)
+ return (error);
+
+ error = xs_read(XST_NIL, backend, mac, NULL,
+ (void **) macstr);
+
+ free(backend, M_XENBUS);
+
+ if (error)
+ return (error);
+ }
s = macstr;
for (i = 0; i ETHER_ADDR_LEN; i++) {
mac[i] = strtoul(s, e, 16);
if (s == e || (e[0] != ':' e[0] != 0)) {
___
freebsd-xen@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to freebsd-xen-unsubscr...@freebsd.org
