Re: Bhyve infos about a vm
Is this thread moving to a try and guess? :-) Btw, this one doesn't work either. [root@environment-rm-01 ~]# ps -ax | grep bhyve 7942 0 R+ 2:49.28 bhyve: lin1 (bhyve) 7980 2 S+ 0:00.00 grep bhyve [root@environment-rm-01 ~]# mdconfig -lv [root@environment-rm-01 ~]# On Tue, Jan 14, 2014 at 8:25 PM, dte...@freebsd.org wrote: -Original Message- From: Andrea Brancatelli [mailto:abrancate...@schema31.it] Sent: Tuesday, January 14, 2014 9:27 AM To: Markiyan Kushnir Cc: freebsd-virtualization@freebsd.org Subject: Re: Bhyve infos about a vm I don't think so. I'm interested in seeing what ISO or IMG are attached i dont' see any such info here... mdconfig -lv ? -- Devin [root@environment-rm-01 /repository]# fstat -p `pgrep bhyve` USER CMD PID FD MOUNT INUM MODE SZ|DV R/W root bhyve 4212 text /1044852 -r-xr-xr-x 318469 r root bhyve 4212 ctty /dev132 crw--w pts/3 rw root bhyve 4212 wd /repository 14 drwxr-xr-x 6 r root bhyve 4212 root / 2 drwxr-xr-x1024 r root bhyve 42120 /dev132 crw--w pts/3 rw root bhyve 42121 /dev132 crw--w pts/3 rw root bhyve 42122 /dev132 crw--w pts/3 rw root bhyve 42123 /dev138 crw--- vmm/lin1 rw root bhyve 42124 /repository 34 -rw-r--r-- 10737418240 rw root bhyve 42125 /dev140 crw---tap1 rw root bhyve 42126 /repository 45 -rw-r--r-- 652214272 rw root bhyve 42127 root bhyve 42128* pipe f80021dbf000 - f80021dbf160 0 rw root bhyve 42129* pipe f80021dbf160 - f80021dbf000 0 rw On Tue, Jan 14, 2014 at 5:54 PM, Markiyan Kushnir markiyan.kush...@gmail.com wrote: may be fstat -p `pgrep bhyve` would give you some info? -- Markiyan 2014/1/14 Andrea Brancatelli abrancate...@schema31.it: How should I see it with ps? [root@environment-rm-01 ~]# ps -aux | grep bhyve root 88142.4 0.0 4221912 60804 3 D+1:15PM 3:11.43 bhyve: lin3 (bhyve) root 61870.0 0.0 4221784 34900 0 D+ 11:09AM 0:52.81 bhyve: FreeBSD10.5RC5.img (bhyve) root 88630.0 0.0 18724 2156 4 S+1:22PM 0:00.00 grep bhyve root 80080.0 0.0 4221912 54324 2 D+ 12:50PM 0:48.50 bhyve: lin1 (bhyve) [root@environment-rm-01 ~]# cat /proc/6187/cmdline bhyve: FreeBSD10.5RC5.img I'm out of ideas... :) On Mon, Jan 13, 2014 at 8:29 PM, Peter Grehan gre...@freebsd.org wrote: Hi Andrea, Whats the command to list all the attached devices to a vm? The only way currently is to list the bhyve command line using ps. Any preferences for how you'd like to see this ? later, Peter. -- *Andrea BrancatelliSchema 31 S.r.l. - Socio UnicoResponsabile ITROMA - FIRENZE - PALERMO ITALYTel: +39. 06.98.358.472* *Cell: +39 331.2488468Fax: +39. 055.71.880.466Società del Gruppo SC31 ITALIA* ___ 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 -- *Andrea BrancatelliSchema 31 S.r.l. - Socio UnicoResponsabile ITROMA - FIRENZE - PALERMO ITALYTel: +39. 06.98.358.472* *Cell: +39 331.2488468Fax: +39. 055.71.880.466Società del Gruppo SC31 ITALIA* ___ 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 _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. -- *Andrea BrancatelliSchema 31 S.r.l. - Socio UnicoResponsabile ITROMA - FIRENZE - PALERMO ITALYTel: +39. 06.98.358.472* *Cell: +39 331.2488468Fax: +39. 055.71.880.466Società del Gruppo SC31 ITALIA* ___ 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: KVM Clock
On 15/01/14 13:05, Julian Stecklina wrote: On 01/14/2014 05:13 PM, Peter Grehan wrote: Hi Julian, is anyone working on KVM clock support for FreeBSD? If not, I might take a shot at it. None I know of: go for it :) Works for me so far: https://github.com/blitz/freebsd/commit/cdc5f872b3e48cc0dda031fc7d6bdedc65c3148f Looking at the code it seems some common routines could be shared between the KVM PV clock and the Xen PV clock (sys/dev/xen/timer/timer.c). The data passed from the hypervisor to the guest has exactly the same format (see struct vcpu_time_info in Xen public headers). At a first sight the KVM clock can benefit from using scale_delta (which is going to be faster than the C version implemented in kvmclock_get_timecount), and xen_fetch_vcpu_tinfo is exactly the same as kvmclock_fetch. Roger. ___ 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: KVM Clock
On Mi, 2014-01-15 at 14:08 +0100, Roger Pau Monné wrote:
On 15/01/14 13:05, Julian Stecklina wrote:
On 01/14/2014 05:13 PM, Peter Grehan wrote:
Hi Julian,
is anyone working on KVM clock support for FreeBSD? If not, I
might take a shot at it.
None I know of: go for it :)
Works for me so far:
https://github.com/blitz/freebsd/commit/cdc5f872b3e48cc0dda031fc7d6bdedc65c3148f
Looking
at the code it seems some common routines could be shared
between the KVM PV clock and the Xen PV clock
(sys/dev/xen/timer/timer.c). The data passed from the hypervisor to
the guest has exactly the same format (see struct vcpu_time_info in
Xen public headers).
Yes, I know. Didn't get around to making it pretty yesterday evening. ;)
I'll post an updated patch, when I have some time. Any suggestions where
to put the two common functions?
At a first sight the KVM clock can benefit from using scale_delta
(which is going to be faster than the C version implemented in
kvmclock_get_timecount),
At least somewhat on amd64. 32-bit looks pretty identical.
and xen_fetch_vcpu_tinfo is exactly the same
as kvmclock_fetch.
I think xen_fetch_vcpu_tinfo has a subtle bug:
217 do {
218 dst-version = src-version;
219 rmb();
220 dst-tsc_timestamp = src-tsc_timestamp;
221 dst-system_time = src-system_time;
222 dst-tsc_to_system_mul = src-tsc_to_system_mul;
223 dst-tsc_shift = src-tsc_shift;
224 rmb();
225 } while ((src-version 1) | (dst-version ^
src-version));
In line 225 src-version is potentially read twice. If you consider the
following schedule:
host starts updating data, sets src-version to 1
guest reads src-version (1) and stores it into dst-version.
guest copies inconsistent data
guest reads src-version (1) and computes xor with dst-version.
host finishes updating data and sets src-version to 2
guest reads src-version (2) and checks whether lower bit is not set.
while loop exits with inconsistent data!
I think the C standard (at least C11) permits this as it does not
specify in which order the two reads in line 225 need to happen.
Julian
___
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: KVM Clock
On 15/01/14 14:45, Julian Stecklina wrote:
On Mi, 2014-01-15 at 14:08 +0100, Roger Pau Monné wrote:
On 15/01/14 13:05, Julian Stecklina wrote:
On 01/14/2014 05:13 PM, Peter Grehan wrote:
Hi Julian,
is anyone working on KVM clock support for FreeBSD? If not, I
might take a shot at it.
None I know of: go for it :)
Works for me so far:
https://github.com/blitz/freebsd/commit/cdc5f872b3e48cc0dda031fc7d6bdedc65c3148f
Looking
at the code it seems some common routines could be shared
between the KVM PV clock and the Xen PV clock
(sys/dev/xen/timer/timer.c). The data passed from the hypervisor to
the guest has exactly the same format (see struct vcpu_time_info in
Xen public headers).
Yes, I know. Didn't get around to making it pretty yesterday evening. ;)
I'll post an updated patch, when I have some time. Any suggestions where
to put the two common functions?
At a first sight the KVM clock can benefit from using scale_delta
(which is going to be faster than the C version implemented in
kvmclock_get_timecount),
At least somewhat on amd64. 32-bit looks pretty identical.
and xen_fetch_vcpu_tinfo is exactly the same
as kvmclock_fetch.
I think xen_fetch_vcpu_tinfo has a subtle bug:
217 do {
218 dst-version = src-version;
219 rmb();
220 dst-tsc_timestamp = src-tsc_timestamp;
221 dst-system_time = src-system_time;
222 dst-tsc_to_system_mul = src-tsc_to_system_mul;
223 dst-tsc_shift = src-tsc_shift;
224 rmb();
225 } while ((src-version 1) | (dst-version ^
src-version));
In line 225 src-version is potentially read twice. If you consider the
following schedule:
host starts updating data, sets src-version to 1
guest reads src-version (1) and stores it into dst-version.
guest copies inconsistent data
guest reads src-version (1) and computes xor with dst-version.
host finishes updating data and sets src-version to 2
guest reads src-version (2) and checks whether lower bit is not set.
while loop exits with inconsistent data!
I think the C standard (at least C11) permits this as it does not
specify in which order the two reads in line 225 need to happen.
According to the operator precedence and associativity in C
(http://en.wikipedia.org/wiki/Operators_in_C_and_C%2B%2B#Operator_precedence),
if I'm reading it right, the condition in the while line will be
evaluated as follows (because of the left-to-right associativity of the
| operator):
1. (src-version 1)
2. (dst-version ^ src-version)
3. result of 1 | result of 2
So AFAICT the flow that you describe could never happen, because
(src-version 1) is always done before (dst-version ^ src-version).
Roger.
___
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: KVM Clock
On Mi, 2014-01-15 at 17:04 +0100, Roger Pau Monné wrote:
On 15/01/14 14:45, Julian Stecklina wrote:
On Mi, 2014-01-15 at 14:08 +0100, Roger Pau Monné wrote:
On 15/01/14 13:05, Julian Stecklina wrote:
On 01/14/2014 05:13 PM, Peter Grehan wrote:
Hi Julian,
is anyone working on KVM clock support for FreeBSD? If not, I
might take a shot at it.
None I know of: go for it :)
Works for me so far:
https://github.com/blitz/freebsd/commit/cdc5f872b3e48cc0dda031fc7d6bdedc65c3148f
Looking
at the code it seems some common routines could be shared
between the KVM PV clock and the Xen PV clock
(sys/dev/xen/timer/timer.c). The data passed from the hypervisor to
the guest has exactly the same format (see struct vcpu_time_info in
Xen public headers).
Yes, I know. Didn't get around to making it pretty yesterday evening. ;)
I'll post an updated patch, when I have some time. Any suggestions where
to put the two common functions?
At a first sight the KVM clock can benefit from using scale_delta
(which is going to be faster than the C version implemented in
kvmclock_get_timecount),
At least somewhat on amd64. 32-bit looks pretty identical.
and xen_fetch_vcpu_tinfo is exactly the same
as kvmclock_fetch.
I think xen_fetch_vcpu_tinfo has a subtle bug:
217 do {
218 dst-version = src-version;
219 rmb();
220 dst-tsc_timestamp = src-tsc_timestamp;
221 dst-system_time = src-system_time;
222 dst-tsc_to_system_mul = src-tsc_to_system_mul;
223 dst-tsc_shift = src-tsc_shift;
224 rmb();
225 } while ((src-version 1) | (dst-version ^
src-version));
In line 225 src-version is potentially read twice. If you consider the
following schedule:
host starts updating data, sets src-version to 1
guest reads src-version (1) and stores it into dst-version.
guest copies inconsistent data
guest reads src-version (1) and computes xor with dst-version.
host finishes updating data and sets src-version to 2
guest reads src-version (2) and checks whether lower bit is not set.
while loop exits with inconsistent data!
I think the C standard (at least C11) permits this as it does not
specify in which order the two reads in line 225 need to happen.
According to the operator precedence and associativity in C
(http://en.wikipedia.org/wiki/Operators_in_C_and_C%2B%2B#Operator_precedence),
if I'm reading it right, the condition in the while line will be
evaluated as follows (because of the left-to-right associativity of the
| operator):
1. (src-version 1)
2. (dst-version ^ src-version)
3. result of 1 | result of 2
So AFAICT the flow that you describe could never happen, because
(src-version 1) is always done before (dst-version ^ src-version).
Operator precedence doesn't matter. Consider it written like this:
or(and(src-version, 1), xor(dst-version, src-version))
C gives you no guarantees whether the and or the xor will be executed
first. There is no sequence point in between. And even with a sequence
point, the C11 memory model gives you no guarantees about how the reads
are ordered.
This discussion is somewhat theoretical, because
a) the hypervisor will probably update the data structure in the
current vCPU context (making memory consistency issues go away).
b) the compiler will likely not be an asshole. ;)
Pseudocode for a better fetch could be:
dst-version = src-version;
rmb();
... read data ...
rmb();
version_post = src-version;
rmb(); - keeps the compiler from reading src-version multiple times
and then doing the test with version_post and dst-version.
Unfortunately, rmb() expands into lfence, even if there is no need for
that here.
Regards,
Julian
___
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
