Re: [PATCH] Flexible vcpu pinning configuration
Neel Natu wrote:
Hi Roman,
On Sun, Apr 27, 2014 at 3:45 AM, Roman Bogorodskiy no...@freebsd.org wrote:
I've created an initial version of the patch which allows more flexible
vcpu pinning configuration.
Current schema is:
bhyve -p N
pins vcpu i to hostcpu N + i.
The propsed extension is:
bhyve -p N:M -p 0:1 -p 3:5
which pins vcpu N to host pcpu M. Option needs to be specified
individually for each vcpu.
So it works like that for me:
sudo /usr/sbin/bhyve -p 0:0 -p 1:3 -c 2 ...
# sudo cpuset -g -t 100262
tid 100262 mask: 0
# sudo cpuset -g -t 100264
tid 100264 mask: 3
PS I used cpumat_t* array to store these values instead of int, because
if the idea is OK, I'll extend it to support ranges like e.g. cpuset(1)
supports, e.g.: 1:2-5.
The questions are:
- Is it OK to chance '-p' arg syntax or it's better to introduce a new
one?
I think we can reuse the -p option unless anybody objects vociferously.
- Is the syntax OK (currently: 'vcpu:pcpu', later
'vcpu:pcpuN-pcpuM,pcpuX)?
Yup, I think that works fine.
The patch looks good in general but I have a few comments:
- Scope of 'vcpupmap[]' should be restricted to 'static'.
- usage() and man page need to be updated.
- pincpu_parse():
The option parsing can be made much easier by using:
if (sscanf(str, %d:%d, vcpu, pcpu) == 2) {
/* success */
} else {
return (-1);
}
If the same vcpu is specified multiple times then we should
malloc(sizeof(cpuset_t)) only the first time:
if (vcpumap[vcpu] != NULL)
mask = vcpumap[vcpu];
else
mask = malloc(sizeof(cpuset_t));
We need to range-check 'vcpu' before using it as an index into the
'vcpumap[]' array.
best
Neel
Attached an updated patch.
I'm still inclined to use something like parselist() from
usr.bin/cpuset/cpuset.c, but I don't want to copy/paste and I don't know
where it'd make sense to move it so it was usable outside of cpuset?
PS While reading bhyverun.c, I think I spotted a typo: in fbsdrun_deletecpu()
error message says fprintf(stderr, addcpu: Should it be deletecpu:
instead?
Roman Bogorodskiy
Index: bhyve.8
===
--- bhyve.8 (revision 264921)
+++ bhyve.8 (working copy)
@@ -78,12 +78,14 @@
allow a remote kernel kgdb to be relayed to the guest kernel gdb stub
via a local IPv4 address and this port.
This option will be deprecated in a future version.
-.It Fl p Ar pinnedcpu
+.It Fl p Ar n:m
Force guest virtual CPUs to be pinned to host CPUs.
Virtual CPU
.Em n
is pinned to host CPU
-.Em pinnedcpu+n .
+.Em m .
+This option could be specified multiple times to set pinning for each
+Virtual CPU and to pin Virtual CPU to more than one host CPU.
.It Fl P
Force the guest virtual CPU to exit when a PAUSE instruction is detected.
.It Fl W
Index: bhyverun.c
===
--- bhyverun.c (revision 264921)
+++ bhyverun.c (working copy)
@@ -83,7 +83,6 @@
int guest_ncpus;
-static int pincpu = -1;
static int guest_vmexit_on_hlt, guest_vmexit_on_pause, disable_x2apic;
static int virtio_msix = 1;
@@ -119,6 +118,8 @@
int mt_vcpu;
} mt_vmm_info[VM_MAXCPU];
+static cpuset_t *vcpumap[VM_MAXCPU] = { NULL };
+
static void
usage(int code)
{
@@ -125,12 +126,12 @@
fprintf(stderr,
Usage: %s [-aehwAHIPW] [-g gdb port] [-s pci] [-S pci]\n
- %*s [-c vcpus] [-p pincpu] [-m mem] [-l lpc] vm\n
+ %*s [-c vcpus] [-p vcpu:hostcpu] [-m mem] [-l lpc] vm\n
-a: local apic is in XAPIC mode (default is X2APIC)\n
-A: create an ACPI table\n
-g: gdb port\n
-c: # cpus (default 1)\n
- -p: pin vcpu 'n' to host cpu 'pincpu + n'\n
+ -p: n:m pin vcpu 'n' to host cpu 'm'\n
-H: vmexit from the guest on hlt\n
-P: vmexit from the guest on pause\n
-W: force virtio to use single-vector MSI\n
@@ -146,6 +147,53 @@
exit(code);
}
+static int
+pincpu_parse(const char *cpupin)
+{
+char *string;
+int vcpu = -1, pcpu = -1, ret = -1;
+
+if ((string = strdup(cpupin)) == NULL) {
+fprintf(stderr, strdup failed: %d\n, errno);
+return -1;
+}
+
+if (sscanf(string, %d:%d, vcpu, pcpu) != 2) {
+fprintf(stderr, invalid format: %s\n, string);
+goto cleanup;
+}
+
+if (vcpu 0 || vcpu VM_MAXCPU - 1) {
+fprintf(stderr, invalid vcpu value '%d',
+should be from 0 to %d\n,
+vcpu, VM_MAXCPU - 1);
+goto cleanup;
+}
+
+if (pcpu 0 || pcpu CPU_SETSIZE) {
+fprintf(stderr, invalid pcpu value '%d',
+should be from 0 to %d\n,
+pcpu, CPU_SETSIZE);
+goto cleanup;
+}
+
+if (vcpumap[vcpu] == NULL) {
+if ((vcpumap[vcpu] = malloc(sizeof(cpuset_t))) == NULL) {
+
Kernel Panic on FreeBSD guests with libvirt 1.2.2 and qemu 1.7.91
Hello, I'm running libvirt 1.2.2 and QEMU 1.7.91 on an Ubuntu 12.04LTS host. Prior to a recent upgrade, I've been able to run FreeBSD guests (both 10.0 and 9.2) perfectly fine without issue. Now, this the aforementioned versions, I'm running into a kernel panic almost immediately after booting, same message with both 10.0 9.2: Fatal trap 12: page fault while in kernel mode. To ensure that it had nothing to do with my configuration [of the guest OS] I've tried installing the guest from guest using virt-install, however I still run into the same kernel panic. It'll be hard for me to post the output of the panic, so I'll try to show as much info as possible via images[1]. Upon researching, I've come across a few threads (e.g., this one[2]) that appear to be related, but none have helped. Any information that you can provide to help me get to the root of this issue would be greatly appreciated! [1]http://www.drenet.net/images/panic1.png http://www.drenet.net/images/panic2.png http://www.drenet.net/images/panic_noacpi1.png http://www.drenet.net/images/panic_noacpi2.png [2]http://forums.freebsd.org/viewtopic.php?t=36761 -- Andre Goree -=-=-=-=-=- Email - andre at drenet.net Website - http://www.drenet.net PGP key - http://www.drenet.net/pubkey.txt -=-=-=-=-=- ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Re: Kernel Panic on FreeBSD guests with libvirt 1.2.2 and qemu 1.7.91
On 05/01/2014 11:00 am, Andre Goree wrote: Hello, I'm running libvirt 1.2.2 and QEMU 1.7.91 on an Ubuntu 12.04LTS host. Prior to a recent upgrade, I've been able to run FreeBSD guests (both 10.0 and 9.2) perfectly fine without issue. Now, this the aforementioned versions, I'm running into a kernel panic almost immediately after booting, same message with both 10.0 9.2: Fatal trap 12: page fault while in kernel mode. To ensure that it had nothing to do with my configuration [of the guest OS] I've tried installing the guest from guest using virt-install, however I still run into the same kernel panic. It'll be hard for me to post the output of the panic, so I'll try to show as much info as possible via images[1]. Upon researching, I've come across a few threads (e.g., this one[2]) that appear to be related, but none have helped. Any information that you can provide to help me get to the root of this issue would be greatly appreciated! [1]http://www.drenet.net/images/panic1.png http://www.drenet.net/images/panic2.png http://www.drenet.net/images/panic_noacpi1.png http://www.drenet.net/images/panic_noacpi2.png [2]http://forums.freebsd.org/viewtopic.php?t=36761 After using my noggin a bit, I've determine the culprit to be atkbd. If I disable it via the bootloader with set hint.atkbd.0.disabled=1, the vm will boot fine. HOWEVER, my problem then is that I cannot use the keyboard via VNC. I'm trying to figure out ways around this...any help would be much appreciated. I've already tried setting different flags for atkbd, but no matter which flag I set, I get the kernel panic -- ostensibly because atkbd is enabled (as it must be for a flag to be set for it). -- Andre Goree -=-=-=-=-=- Email - andre at drenet.net Website - http://www.drenet.net PGP key - http://www.drenet.net/pubkey.txt -=-=-=-=-=- ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Re: bhyve and serial port emulation problem
Hi Olivier, On Wed, Apr 30, 2014 at 3:28 PM, Olivier Cochard-Labbé oliv...@cochard.me wrote: On Wed, Apr 30, 2014 at 7:33 PM, Neel Natu neeln...@gmail.com wrote: Hi Olivier, Can you share the command line options you pass the bhyve(8)? Hi Neel, sure, here it is: bhyveload -m 256M -d /tmp/BSDRP/BSDRP_1 -c /dev/nmdm1A BSDRP_1 bhyve -c 1 -m 256M -A -H -P -s 0:0,hostbridge -s 0:1,lpc -s 2:0,virtio-net,tap0,mac=58:9c:fc:01:00:01 -s 1:0,virtio-blk,/tmp/BSDRP/BSDRP_1 -l com1,/dev/nmdm1A BSDRP_1 The UPDATING entry in r264175 describes how to fix this: http://svnweb.freebsd.org/base?view=revisionrevision=264175 Briefly, you will now need to change your /etc/ttys to look like this: ttyu0 /usr/libexec/getty 3wire vt100 on secure If your virtual machine has an older world then your /etc/gettytab will not have the entry for 3wire and you may want to use 3wire.9600 instead. best Neel Regards, Olivier ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
