vmm(4) patch - iniatialise eptp to zero for vmx like svm
Hi
Again while working on a larger patch i noticed that the eptp for vmx
was not getting initialised to zero like the svm code path, as part of
a VMM_IOC_RESETCPU ioctl call.
please see the attach patch to initialise eptp to zero
cheers
Adam
? div
Index: sys/arch/amd64/amd64/vmm.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/vmm.c,v
retrieving revision 1.258
diff -u -p -u -p -r1.258 vmm.c
--- sys/arch/amd64/amd64/vmm.c 31 Jan 2020 01:51:27 - 1.258
+++ sys/arch/amd64/amd64/vmm.c 6 Feb 2020 02:18:30 -
@@ -2895,6 +2895,8 @@ vcpu_reset_regs_vmx(struct vcpu *vcpu, s
/* xcr0 power on default sets bit 0 (x87 state) */
vcpu->vc_gueststate.vg_xcr0 = XCR0_X87 & xsave_mask;
+ vcpu->vc_parent->vm_map->pmap->eptp = 0;
+
exit:
/* Flush the VMCS */
if (vmclear(>vc_control_pa)) {
Re: macppc base-clang -msvr4-struct-return
Hi George,
On Tue, Feb 04, 2020 at 08:39:12PM -0500, George Koehler wrote:
> Hello tech list,
>
> This is a diff for base-clang. It would change the powerpc target to
> return small structs in registers r3 and r4. This would fix an
> incompatibility with gcc in OpenBSD macppc. I fear that if I commit
> the diff, I might break snapshot builds. I am looking for help.
The diff looks sane to me. I don't see anything that would obviously
break snaps, and the option is limited to only the ppc platform.
I am running it through a release build here (amd64) and will know how
that turned out tomorrow after work, so will be able to confirm that you
won't break snaps on that arch. I don't expect there to be any problem
there. I should be able to test it on macppc over the weekend, so if
you're paranoid you can wait to see how that goes.
Cheers,
Todd
>
> I posted the diff upstream: https://reviews.llvm.org/D73290
> Then backported it to ports-clang and mailed it to ports@:
> https://marc.info/?l=openbsd-ports=158026852003182=2
> This is the same diff for base-clang.
>
> Apply diff in /usr/src/gnu/llvm, then build clang like
>
> # cd /usr/src/gnu/usr.bin/clang
> # make obj
> # make
> # make install
>
> My macppc machine, an iMac G3 with 512M RAM, is too slow to build llvm
> and clang. The iMac is now in the 11th day of building ports-clang
> (but I turned it off overnight), and within the last 200 of over 4400
> targets. After a .cpp file got stuck while using over 800M swap (on
> hard disk), I set vm.swapencrypt.enable=0 and switched to swap on NFS.
> (For contrast, my amd64 desktop built ports-clang in about 2 hours.)
>
> cwen@ built ports-clang with my diff on a G4 in "29 hours".
> rgc built base-clang with the diff in this mail.
> Both got good results from my small test programs in the attachment
> (sret-examples.tar.gz) to my ports@ mail.
>
> The diff affects all platforms (if they build clang), so if the diff
> would break clang, it might break arches other than macppc. I built
> and installed base-clang with this diff on amd64 (using make -j4 to
> speed up the build). Then, with the patched clang, I built an amd64
> release(8) of base and xenocara. I used my new install66.iso
> to install a new amd64 virtual machine, including the patched clang.
>
> We build most of OpenBSD macppc with base-gcc, but we use base-clang
> for at least clang itself. I don't know whether the patched
> base-clang can still build base-clang, whether the patch would break
> the base build on macppc.
>
> The patch adds -maix-struct-return and -msvr4-struct-return:
>
> $ clang -msvr-struct-return -x c /dev/null
> clang: error: unknown argument '-msvr-struct-return', did you mean
> '-msvr4-struct-return'?
> $ clang -msvr4-struct-return -x c /dev/null
> clang: error: unsupported option '-msvr4-struct-return' for target
> 'amd64-unknown-openbsd6.6'
>
> On OpenBSD macppc, gcc defaults to -msvr4-struct-return (to return
> small structs in registers r3 and r4), but clang without the patch
> always acts like gcc -maix-struct-return (to return small structs in
> memory through a sret pointer). The patch adds the options and
> changes the default to -msvr4-struct-return on OpenBSD (and other
> ELF except Linux). The options work only on 32-bit powerpc.
>
> When the patch returns a struct in registers, it coerces the struct
> to an integer; this changes the LLVM IR from clang to not use a sret
> pointer. The option handling for -m{aix,svr4}-struct-return is mostly
> a copy of that for -f{pcc,reg}-struct-return on i386.
>
> --George
>
> Index: tools/clang/include/clang/Driver/Options.td
> ===
> RCS file: /cvs/src/gnu/llvm/tools/clang/include/clang/Driver/Options.td,v
> retrieving revision 1.11
> diff -u -p -r1.11 Options.td
> --- tools/clang/include/clang/Driver/Options.td 23 Jun 2019 22:05:15
> - 1.11
> +++ tools/clang/include/clang/Driver/Options.td 30 Jan 2020 01:13:29
> -
> @@ -2238,6 +2238,12 @@ def mlongcall: Flag<["-"], "mlongcall">,
> Group;
> def mno_longcall : Flag<["-"], "mno-longcall">,
> Group;
> +def maix_struct_return : Flag<["-"], "maix-struct-return">,
> + Group, Flags<[CC1Option]>,
> + HelpText<"Return all structs in memory (PPC32 only)">;
> +def msvr4_struct_return : Flag<["-"], "msvr4-struct-return">,
> + Group, Flags<[CC1Option]>,
> + HelpText<"Return small structs in registers (PPC32 only)">;
>
> def mvx : Flag<["-"], "mvx">, Group;
> def mno_vx : Flag<["-"], "mno-vx">, Group;
> Index: tools/clang/lib/CodeGen/TargetInfo.cpp
> ===
> RCS file: /cvs/src/gnu/llvm/tools/clang/lib/CodeGen/TargetInfo.cpp,v
> retrieving revision 1.1.1.7
> diff -u -p -r1.1.1.7 TargetInfo.cpp
> --- tools/clang/lib/CodeGen/TargetInfo.cpp23 Jun 2019 21:37:39 -
> 1.1.1.7
> +++ tools/clang/lib/CodeGen/TargetInfo.cpp30 Jan 2020
Re: posix_openpt: allow O_CLOEXEC
On Wed, Feb 05, 2020 at 05:48:41PM -0700, Todd C. Miller wrote: > On Wed, 05 Feb 2020 15:47:37 -0600, joshua stein wrote: > > > The spec says the behavior of anything other than O_RDWR and > > O_NOCTTY is unspecified, but FreeBSD allows passing O_CLOEXEC. > > OK, but the manual needs to specify that O_CLOEXEC support is an > extension. E.g., under STANDARDS: > > The ability to use > .Dv O_CLOEXEC > is an extension to that standard. > > - todd FWIW, it looks like a future standard version/revision will add O_CLOEXEC to posix_openpt. See https://www.austingroupbugs.net/view.php?id=411 (grep for posix_openpt, which is included among many other similar modifications). I haven't yet figured out the rules for that group and how things wind up in the published standard; what counts as a defect and what counts as a new feature. I'm a little surprised it's not already in the -2017 revision. IIRC, some other changes related to O_CLOEXEC/FD_CLOEXEC consistency made it into -2017 and earlier revisions.
Re: posix_openpt: allow O_CLOEXEC
On Wed, 05 Feb 2020 15:47:37 -0600, joshua stein wrote: > The spec says the behavior of anything other than O_RDWR and > O_NOCTTY is unspecified, but FreeBSD allows passing O_CLOEXEC. OK, but the manual needs to specify that O_CLOEXEC support is an extension. E.g., under STANDARDS: The ability to use .Dv O_CLOEXEC is an extension to that standard. - todd
Re: sched_steal_proc(): steal from highest loaded CPU
> > 'ci' changes after we proceed to another cpu, and cost will be different > > for each cpu+proc combination. > > Look at at line 516 of kern/kern_sched.c doest the first argument of > sched_proc_to_cpu_cost() change? Aaaargh, you are absolutely right! My fault, I was blinded by looking at the sched_proc_to_cpu_cost() in sched_choosecpu(), where the ci changes while iterating on the cpus, and mentally transferred that to sched_steal_proc(). > > Actually, in the steal case, if there is a large difference in > > spc_curpriority and p_usrpri between running proc which is SONPROC vs the > > current proc, then the cost will be skewed towards an outlier, but this > > will happen for all procs for that ci as you analyzed. > > You missed the point above, the CPU is trying to steal a thread because > it has nothing to execute, so no SONPROC. > > > To summarize: currently, if a cpu is running 1-2 procs with large > > differences in priority, there is a high possibility that this function > > will go steal a proc from it for the just idled cpu. Whereas at the same > > time, another cpu is running 5-7 procs with exact same priorities, that > > will be ignored in the above calculation! We should have stolen from the > > cpu with 5-7 procs. > > Is it speculation based on your understanding of what you read or can > you reproduce this? > > > I hope this is a correct interpretation? Is there something wrong in this > > analysis? > > Why do you ask? Are you interested in changing the actual code? If so > why? Are you interested in understanding what does it do? > > > Another small optimization is [...] > > How do you know it's an optimization? How did you test it? What is > your workload? How did you prove your reasoning? > > I don't know why you're sending such emails, but if your goal is to > contribute may I suggest you to pick a simpler place to start and to > really understand it before sending diffs? Maybe test your changes, > gather data, look at facts instead of guesses... :o) My apologies, I will base it on facts and testing. :( Thanks
ipsecctl udp encap
Hi,
I would like to test IPsec with NAT-T. For that it would be useful
to set the udpencap flag and port of a SA. I added that to
ipseectl(8).
ok?
bluhm
Index: sbin/ipsecctl/ipsec.conf.5
===
RCS file: /data/mirror/openbsd/cvs/src/sbin/ipsecctl/ipsec.conf.5,v
retrieving revision 1.156
diff -u -p -r1.156 ipsec.conf.5
--- sbin/ipsecctl/ipsec.conf.5 10 Nov 2019 20:51:52 - 1.156
+++ sbin/ipsecctl/ipsec.conf.5 6 Feb 2020 00:00:06 -
@@ -890,6 +890,10 @@ and
The SPI identifies a specific SA.
.Ar number
is a 32-bit value and needs to be unique.
+.It Ic udpencap Op Ic port Ar dport
+For NAT-Traversal encapsulate the IPsec traffic in UDP.
+The port number of the peer can be set to
+.Ar dport .
.It Ic auth Ar algorithm
For ESP and AH
an authentication algorithm can be specified.
Index: sbin/ipsecctl/ipsecctl.h
===
RCS file: /data/mirror/openbsd/cvs/src/sbin/ipsecctl/ipsecctl.h,v
retrieving revision 1.73
diff -u -p -r1.73 ipsecctl.h
--- sbin/ipsecctl/ipsecctl.h20 Nov 2017 10:51:24 - 1.73
+++ sbin/ipsecctl/ipsecctl.h5 Feb 2020 20:42:45 -
@@ -208,6 +208,8 @@ struct ipsec_rule {
u_int8_t ikemode;
u_int8_t p1ie;
u_int8_t p2ie;
+ u_int8_t udpencap;
+ u_int16_tudpdport;
u_int16_tsport;
u_int16_tdport;
u_int32_tspi;
Index: sbin/ipsecctl/parse.y
===
RCS file: /data/mirror/openbsd/cvs/src/sbin/ipsecctl/parse.y,v
retrieving revision 1.177
diff -u -p -r1.177 parse.y
--- sbin/ipsecctl/parse.y 26 Aug 2019 18:53:58 - 1.177
+++ sbin/ipsecctl/parse.y 5 Feb 2020 20:46:00 -
@@ -205,7 +205,8 @@ int validate_sa(u_int32_t, u_int8_t,
struct ipsec_transforms *, struct ipsec_key *,
struct ipsec_key *, u_int8_t);
struct ipsec_rule *create_sa(u_int8_t, u_int8_t, struct ipsec_hosts *,
-u_int32_t, struct ipsec_transforms *,
+u_int32_t, u_int8_t, u_int16_t,
+struct ipsec_transforms *,
struct ipsec_key *, struct ipsec_key *);
struct ipsec_rule *reverse_sa(struct ipsec_rule *, u_int32_t,
struct ipsec_key *, struct ipsec_key *);
@@ -257,6 +258,10 @@ typedef struct {
u_int32_t spiin;
} spis;
struct {
+ u_int8_tencap;
+ u_int16_t port;
+ } udpencap;
+ struct {
struct ipsec_key *keyout;
struct ipsec_key *keyin;
} authkeys;
@@ -281,7 +286,7 @@ typedef struct {
%token AUTHKEY ENCKEY FILENAME AUTHXF ENCXF ERROR IKE MAIN QUICK AGGRESSIVE
%token PASSIVE ACTIVE ANY IPIP IPCOMP COMPXF TUNNEL TRANSPORT DYNAMIC LIFETIME
%token TYPE DENY BYPASS LOCAL PROTO USE ACQUIRE REQUIRE DONTACQ GROUP PORT TAG
-%token INCLUDE BUNDLE
+%token INCLUDE BUNDLE UDPENCAP
%token STRING
%token NUMBER
%typestring
@@ -300,6 +305,7 @@ typedef struct {
%type ids
%typeid
%type spispec
+%type udpencap
%type authkeyspec
%type enckeyspec
%typebundlestring
@@ -347,7 +353,7 @@ tcpmd5rule : TCPMD5 hosts spispec authke
struct ipsec_rule *r;
r = create_sa(IPSEC_TCPMD5, IPSEC_TRANSPORT, &$2,
- $3.spiout, NULL, $4.keyout, NULL);
+ $3.spiout, 0, 0, NULL, $4.keyout, NULL);
if (r == NULL)
YYERROR;
@@ -357,17 +363,17 @@ tcpmd5rule: TCPMD5 hosts spispec authke
}
;
-sarule : satype tmode hosts spispec transforms authkeyspec
+sarule : satype tmode hosts spispec udpencap transforms authkeyspec
enckeyspec bundlestring {
struct ipsec_rule *r;
- r = create_sa($1, $2, &$3, $4.spiout, $5, $6.keyout,
- $7.keyout);
+ r = create_sa($1, $2, &$3, $4.spiout, $5.encap, $5.port,
+ $6, $7.keyout, $8.keyout);
if (r == NULL)
YYERROR;
- if (expand_rule(r, NULL, 0, $4.spiin, $6.keyin,
- $7.keyin, $8))
+ if (expand_rule(r, NULL, 0, $4.spiin, $7.keyin,
+ $8.keyin, $9))
errx(1, "sarule: expand_rule");
Re: posix_openpt: allow O_CLOEXEC
Seems very reasonable.
joshua stein wrote:
> The spec says the behavior of anything other than O_RDWR and
> O_NOCTTY is unspecified, but FreeBSD allows passing O_CLOEXEC.
>
>
> Index: lib/libc/stdlib/posix_openpt.3
> ===
> RCS file: /cvs/src/lib/libc/stdlib/posix_openpt.3,v
> retrieving revision 1.4
> diff -u -p -u -p -r1.4 posix_openpt.3
> --- lib/libc/stdlib/posix_openpt.325 Jan 2019 00:19:25 - 1.4
> +++ lib/libc/stdlib/posix_openpt.35 Feb 2020 21:41:00 -
> @@ -45,7 +45,7 @@ argument is formed by bitwise-inclusive
> .Tn OR Ns 'ing
> the following values defined in
> .In fcntl.h :
> -.Bl -tag -width O_NOCTTY -offset indent
> +.Bl -tag -width O_CLOEXEC -offset indent
> .It Dv O_RDWR
> Open for reading and writing.
> .It Dv O_NOCTTY
> @@ -53,6 +53,8 @@ Prevent the device from being made the c
> This flag has no effect on
> .Ox
> and is included for compatibility with other systems.
> +.It Dv O_CLOEXEC
> +Set the close-on-exec flag for the new file descriptor.
> .El
> .Pp
> The
> Index: lib/libc/stdlib/posix_pty.c
> ===
> RCS file: /cvs/src/lib/libc/stdlib/posix_pty.c,v
> retrieving revision 1.3
> diff -u -p -u -p -r1.3 posix_pty.c
> --- lib/libc/stdlib/posix_pty.c 25 Jan 2019 00:19:25 - 1.3
> +++ lib/libc/stdlib/posix_pty.c 5 Feb 2020 21:41:00 -
> @@ -36,13 +36,13 @@ posix_openpt(int oflag)
>
> /* User must specify O_RDWR in oflag. */
> if ((oflag & O_ACCMODE) != O_RDWR ||
> - (oflag & ~(O_ACCMODE | O_NOCTTY)) != 0) {
> + (oflag & ~(O_ACCMODE | O_NOCTTY | O_CLOEXEC)) != 0) {
> errno = EINVAL;
> return -1;
> }
>
> /* Get pty master and slave (this API only uses the master). */
> - fd = open(PATH_PTMDEV, O_RDWR);
> + fd = open(PATH_PTMDEV, oflag);
> if (fd != -1) {
> if (ioctl(fd, PTMGET, ) != -1) {
> close(ptm.sfd);
>
posix_openpt: allow O_CLOEXEC
The spec says the behavior of anything other than O_RDWR and
O_NOCTTY is unspecified, but FreeBSD allows passing O_CLOEXEC.
Index: lib/libc/stdlib/posix_openpt.3
===
RCS file: /cvs/src/lib/libc/stdlib/posix_openpt.3,v
retrieving revision 1.4
diff -u -p -u -p -r1.4 posix_openpt.3
--- lib/libc/stdlib/posix_openpt.3 25 Jan 2019 00:19:25 - 1.4
+++ lib/libc/stdlib/posix_openpt.3 5 Feb 2020 21:41:00 -
@@ -45,7 +45,7 @@ argument is formed by bitwise-inclusive
.Tn OR Ns 'ing
the following values defined in
.In fcntl.h :
-.Bl -tag -width O_NOCTTY -offset indent
+.Bl -tag -width O_CLOEXEC -offset indent
.It Dv O_RDWR
Open for reading and writing.
.It Dv O_NOCTTY
@@ -53,6 +53,8 @@ Prevent the device from being made the c
This flag has no effect on
.Ox
and is included for compatibility with other systems.
+.It Dv O_CLOEXEC
+Set the close-on-exec flag for the new file descriptor.
.El
.Pp
The
Index: lib/libc/stdlib/posix_pty.c
===
RCS file: /cvs/src/lib/libc/stdlib/posix_pty.c,v
retrieving revision 1.3
diff -u -p -u -p -r1.3 posix_pty.c
--- lib/libc/stdlib/posix_pty.c 25 Jan 2019 00:19:25 - 1.3
+++ lib/libc/stdlib/posix_pty.c 5 Feb 2020 21:41:00 -
@@ -36,13 +36,13 @@ posix_openpt(int oflag)
/* User must specify O_RDWR in oflag. */
if ((oflag & O_ACCMODE) != O_RDWR ||
- (oflag & ~(O_ACCMODE | O_NOCTTY)) != 0) {
+ (oflag & ~(O_ACCMODE | O_NOCTTY | O_CLOEXEC)) != 0) {
errno = EINVAL;
return -1;
}
/* Get pty master and slave (this API only uses the master). */
- fd = open(PATH_PTMDEV, O_RDWR);
+ fd = open(PATH_PTMDEV, oflag);
if (fd != -1) {
if (ioctl(fd, PTMGET, ) != -1) {
close(ptm.sfd);
Re: ldom.conf: Support devlias keyword for vdisk
On Wed, Feb 05, 2020 at 09:35:25PM +0100, Klemens Nanni wrote:
> Straight forward diff to allow calling disks names:
>
> $ cat ldom.conf
> domain guest {
> vcpu 4
> memory 8G
> vnet
> vdisk "/var/ldom/guest.img"
> vdisk "/var/ldom/miniroot.fs" devalias=miniroot
> }
The same for network would be trivially to add:
vnet devalias=netboot
I have a few domains with two or more vnets, one of them is for
diskless(8) so the following can be as handy; it's little change for
notable convenience:
{ok} boot netboot
ldom.conf: Support devlias keyword for vdisk
Straight forward diff to allow calling disks names:
$ cat ldom.conf
domain guest {
vcpu 4
memory 8G
vnet
vdisk "/var/ldom/guest.img"
vdisk "/var/ldom/miniroot.fs" devalias=miniroot
}
$ doas ldomctl start -c guest
{ok} devalias
...
miniroot /virtual-devices@100/channel-devices@200/disk@1
disk1/virtual-devices@100/channel-devices@200/disk@1
disk0/virtual-devices@100/channel-devices@200/disk@0
disk /virtual-devices@100/channel-devices@200/disk@0
...
{ok} boot miniroot
Boot device: /virtual-devices@100/channel-devices@200/disk@1 File and
args:
OpenBSD IEEE 1275 Bootblock 1.4
...
This helps me to navigate inside guests as I no longer have to remember
in which order I specified the `vdisk' lines in ldom.conf(5).
parse.y code is simply copied from existing vnet code and adapted with
s/vnet/vdisk/.
It would need the previously sent ldom.conf.5 vnet, although for
correctness and consistency only.
Feedback? OK?
Index: config.c
===
RCS file: /cvs/src/usr.sbin/ldomctl/config.c,v
retrieving revision 1.32
diff -u -p -r1.32 config.c
--- config.c22 Jan 2020 07:52:38 - 1.32
+++ config.c5 Feb 2020 20:24:12 -
@@ -2557,7 +2557,8 @@ guest_add_memory(struct guest *guest, ui
}
void
-guest_add_vdisk(struct guest *guest, uint64_t id, const char *path)
+guest_add_vdisk(struct guest *guest, uint64_t id, const char *path,
+const char *user_devalias)
{
struct guest *primary;
struct ldc_channel *lc;
@@ -2577,6 +2578,8 @@ guest_add_vdisk(struct guest *guest, uin
if (id == 0)
guest_add_devalias(guest, "disk", devpath);
guest_add_devalias(guest, devalias, devpath);
+ if (user_devalias != NULL)
+ guest_add_devalias(guest, user_devalias, devpath);
free(devalias);
free(devpath);
}
@@ -2849,7 +2852,8 @@ build_config(const char *filename, int n
guest_add_memory(guest, -1, domain->memory);
i = 0;
SIMPLEQ_FOREACH(vdisk, >vdisk_list, entry)
- guest_add_vdisk(guest, i++, vdisk->path);
+ guest_add_vdisk(guest, i++, vdisk->path,
+ vdisk->devalias);
i = 0;
SIMPLEQ_FOREACH(vnet, >vnet_list, entry)
guest_add_vnetwork(guest, i++, vnet->mac_addr,
Index: ldom.conf.5
===
RCS file: /cvs/src/usr.sbin/ldomctl/ldom.conf.5,v
retrieving revision 1.10
diff -u -p -r1.10 ldom.conf.5
--- ldom.conf.5 13 Jan 2020 09:29:41 - 1.10
+++ ldom.conf.5 5 Feb 2020 20:20:21 -
@@ -56,7 +56,7 @@ See
.Xr eeprom 8
for a list of OpenPROM variables.
This keyword can be used multiple times.
-.It Ic vdisk Ar file
+.It Ic vdisk Ar file Op Ar keyword Ns = Ns Ar value ...
The specified file is used to back a virtual disk of the guest
domain.
.Ar file
@@ -64,6 +64,12 @@ can be a block device node or a disk ima
.Cm create-vdisk
command.
This keyword can be used multiple times.
+Valid options are:
+.Bl -tag -width Ds
+.It Ic devalias Ns = Ns Ar name
+Alias the virtual disk as
+.Ar name .
+.El
.It Ic vnet Op Brq Ar keyword Ns = Ns Ar value ...
Assign a
.Xr vnet 4
Index: ldomctl.h
===
RCS file: /cvs/src/usr.sbin/ldomctl/ldomctl.h,v
retrieving revision 1.12
diff -u -p -r1.12 ldomctl.h
--- ldomctl.h 4 Jan 2020 15:45:46 - 1.12
+++ ldomctl.h 5 Feb 2020 20:18:43 -
@@ -158,6 +158,7 @@ extern uint64_t hv_memsize;
struct vdisk {
SIMPLEQ_ENTRY(vdisk)entry;
const char *path;
+ const char *devalias;
};
struct vnet {
Index: parse.y
===
RCS file: /cvs/src/usr.sbin/ldomctl/parse.y,v
retrieving revision 1.15
diff -u -p -r1.15 parse.y
--- parse.y 9 Jan 2020 22:06:23 - 1.15
+++ parse.y 5 Feb 2020 20:18:48 -
@@ -70,12 +70,17 @@ struct vcpu_opts {
uint64_tstride;
} vcpu_opts;
+struct vdisk_opts {
+ const char *devalias;
+} vdisk_opts;
+
struct vnet_opts {
uint64_tmac_addr;
uint64_tmtu;
} vnet_opts;
void vcput_opts_default(void);
+void vdisk_opts_default(void);
void vnet_opts_default(void);
typedef struct {
@@ -83,6 +88,7 @@ typedef struct {
int64_t number;
char*string;
struct vcpu_opts vcpu_opts;
+ struct vdisk_optsvdisk_opts;
struct vnet_opts
Re: ldom.conf: curly braces in vnet block
On Sun, Feb 02, 2020 at 12:08:56PM +0100, Klemens Nanni wrote:
> ldom.conf(5) says
>
> vnet [{keyword=value ...}]
> Assign a vnet(4) network interface to the guest domain. This
> keyword can be used multiple times. The curly braces are
> optional and can contain the following keywords:
>
> But curly braces must not exist:
>
> $ cat -n vnet.conf
> 1 domain guest {
> 2 vcpu 1
> 3 memory 1G
> 4 vnet { mtu=1500 }
> 5 }
> $ ldomctl init-system -n vnet.conf
> vnet.conf:4 syntax error
> $ sed -i /vnet/s,[{}],,g vnet.conf
> $ ldomctl init-system -n vnet.conf ; echo $?
> 0
I've tried converting parse.y to mandatory curly braces with space
separated (incl. optional newlines) keyword=value pairs, but I got lost
in yacc errors, consistency flaws, etc.
Unless I find more motiviation for this or some other parse.y hacker
wants to help, here's a diff to update ldom.conf(5) to reflect working
syntax.
I'd like to commit this soon in order to continue with my actual diff
for introducing vdisk options.
OK?
Index: ldom.conf.5
===
RCS file: /cvs/src/usr.sbin/ldomctl/ldom.conf.5,v
retrieving revision 1.10
diff -u -p -r1.10 ldom.conf.5
--- ldom.conf.5 13 Jan 2020 09:29:41 - 1.10
+++ ldom.conf.5 5 Feb 2020 20:06:21 -
@@ -64,12 +64,12 @@ can be a block device node or a disk ima
.Cm create-vdisk
command.
This keyword can be used multiple times.
-.It Ic vnet Op Brq Ar keyword Ns = Ns Ar value ...
+.It Ic vnet Op Ar keyword Ns = Ns Ar value ...
Assign a
.Xr vnet 4
network interface to the guest domain.
This keyword can be used multiple times.
-The curly braces are optional and can contain the following keywords:
+Valid options are:
.Bl -tag -width Ds
.It Ic mac-addr Ns = Ns Ar address
Configure the MAC address of the interface.
em(4) reset I210 wake status
When I boot an APU2 using wake-on-lan and then attempt to power off with
shutdown -hp it wakes itself up again. To prevent this it is necessary to
clear the I210 PME_STATUS flag. This is described in section 5.6.2 of the
I210 datasheet:
The PE_WAKE_N remains asserted until the operating system either writes
a 1b to the PMCSR.PME_Status bit or writes a 0b to the PMCSR.PME_En bit.
In addition the WUS (wake up status) register is not automatically cleared,
as described in section 8.2.13 of the i210 datasheet:
This register is not cleared when PE_RST_N is asserted. It is only
cleared when LAN_PWR_GOOD is deasserted or when cleared by the software
device driver.
Nathanael
Index: sys/dev/pci/if_em.c
===
RCS file: /cvs/src/sys/dev/pci/if_em.c,v
retrieving revision 1.344
diff -u -p -r1.344 if_em.c
--- sys/dev/pci/if_em.c 4 Feb 2020 10:59:23 - 1.344
+++ sys/dev/pci/if_em.c 5 Feb 2020 14:01:34 -
@@ -561,6 +561,9 @@ em_attach(struct device *parent, struct
#endif
printf(", address %s\n", ether_sprintf(sc->sc_ac.ac_enaddr));
+ if (sc->hw.wus)
+ printf("%s wakeup: %d\n", sc->sc_dev.dv_xname, sc->hw.wus);
+
/* Indicate SOL/IDER usage */
if (em_check_phy_reset_block(>hw))
printf("%s: PHY reset is blocked due to SOL/IDER session.\n",
Index: sys/dev/pci/if_em_hw.c
===
RCS file: /cvs/src/sys/dev/pci/if_em_hw.c,v
retrieving revision 1.106
diff -u -p -r1.106 if_em_hw.c
--- sys/dev/pci/if_em_hw.c 4 Feb 2020 10:59:23 - 1.106
+++ sys/dev/pci/if_em_hw.c 5 Feb 2020 14:01:34 -
@@ -1678,6 +1678,12 @@ em_init_hw(struct em_hw *hw)
ctrl = (ctrl & ~E1000_TXDCTL_WTHRESH) |
E1000_TXDCTL_FULL_TX_DESC_WB;
E1000_WRITE_REG(hw, TXDCTL(1), ctrl);
+ hw->wus = E1000_READ_REG(hw, WUS);
+ if (hw->wus)
+ E1000_WRITE_REG(hw, WUS, reg_data);
+ reg_data = E1000_READ_REG(hw, WUC);
+ if (reg_data & E1000_WUC_PME_STATUS)
+ E1000_WRITE_REG(hw, WUC, reg_data);
break;
}
Index: sys/dev/pci/if_em_hw.h
===
RCS file: /cvs/src/sys/dev/pci/if_em_hw.h,v
retrieving revision 1.80
diff -u -p -r1.80 if_em_hw.h
--- sys/dev/pci/if_em_hw.h 4 Feb 2020 10:59:23 - 1.80
+++ sys/dev/pci/if_em_hw.h 5 Feb 2020 14:01:34 -
@@ -1482,6 +1482,7 @@ struct em_hw {
uint16_t swfw;
boolean_t eee_enable;
int sw_flag;
+int wus;
};
#define E1000_EEPROM_SWDPIN0 0x0001 /* SWDPIN 0 EEPROM Value */
Re: Document that openlog's first paramater must continue to point to valid data
Hi, Laurence Tratt wrote on Wed, Feb 05, 2020 at 09:38:28AM +: > On Mon, Feb 03, 2020 at 09:28:15PM +0100, Ingo Schwarze wrote: >> The parameter >> .Fa ident >> -is a string that will be prepended to every message. >> +points to a string that will be prepended to every message; >> +its storage must persist until >> +.Fn closelog >> +or the corresponding >> +.Fn closelog_r . >> +If the content of the string is changed, behaviour is unspecified. > This works well for me and would, I think, have stopped me making the > mistake that started this whole thread -- thanks! Committed. Thanks for bringing it up a for the cross-check, and to everybody for the feedback. Yours, Ingo
Re: sched_steal_proc(): steal from highest loaded CPU
On 04/02/20(Tue) 13:13, Amit Kulkarni wrote: > [...] > 'ci' changes after we proceed to another cpu, and cost will be different for > each cpu+proc combination. Look at at line 516 of kern/kern_sched.c doest the first argument of sched_proc_to_cpu_cost() change? > Actually, in the steal case, if there is a large difference in > spc_curpriority and p_usrpri between running proc which is SONPROC vs the > current proc, then the cost will be skewed towards an outlier, but this will > happen for all procs for that ci as you analyzed. You missed the point above, the CPU is trying to steal a thread because it has nothing to execute, so no SONPROC. > To summarize: currently, if a cpu is running 1-2 procs with large differences > in priority, there is a high possibility that this function will go steal a > proc from it for the just idled cpu. Whereas at the same time, another cpu is > running 5-7 procs with exact same priorities, that will be ignored in the > above calculation! We should have stolen from the cpu with 5-7 procs. Is it speculation based on your understanding of what you read or can you reproduce this? > I hope this is a correct interpretation? Is there something wrong in this > analysis? Why do you ask? Are you interested in changing the actual code? If so why? Are you interested in understanding what does it do? > Another small optimization is [...] How do you know it's an optimization? How did you test it? What is your workload? How did you prove your reasoning? I don't know why you're sending such emails, but if your goal is to contribute may I suggest you to pick a simpler place to start and to really understand it before sending diffs? Maybe test your changes, gather data, look at facts instead of guesses... :o)
Re: Document that openlog's first paramater must continue to point to valid data
On Mon, Feb 03, 2020 at 09:28:15PM +0100, Ingo Schwarze wrote: Hello Ingo, > The parameter > .Fa ident > -is a string that will be prepended to every message. > +points to a string that will be prepended to every message; > +its storage must persist until > +.Fn closelog > +or the corresponding > +.Fn closelog_r . > +If the content of the string is changed, behaviour is unspecified. This works well for me and would, I think, have stopped me making the mistake that started this whole thread -- thanks! Laurie
Re: [PATCH] Gemini Lake SoC pcidevs and eMMC
On 2/4/20, Patrick Wildt wrote: > On Wed, Jan 02, 2019 at 08:11:25PM -0500, James Hastings wrote: >> Hello tech@ >> >> I would like to add PCI devices for latest Intel SoC (Gemini Lake). >> >> Included a patch for sdhc(4) too that depends on this to enable eMMC. >> The Intel eMMC controller does not like bus power going to 0V. There >> may be other systems (Apollo Lake) that need this quirk too. >> >> With both patches I am booting from internal eMMC on HP Stream 14. >> >> Comments? ok? > > Looks like we forgot this one year old diff. I think the pcidevs > change is probably fine. I will cross-check it and put it in. > > For the sdhc change the diff doesn't apply anymore since we added > the same if-condition for 100series and apollo lake already. I > guess it's time to add gemini lake there as well. > Thanks patrick@ for picking this up. sdhc(4) changes for gemini lake have already been made. Rebased diff with additional I2C devices. Index: dev/pci/pcidevs === RCS file: /cvs/src/sys/dev/pci/pcidevs,v retrieving revision 1.1915 diff -u -p -r1.1915 pcidevs --- dev/pci/pcidevs 23 Jan 2020 04:33:54 - 1.1915 +++ dev/pci/pcidevs 5 Feb 2020 04:48:02 - @@ -4587,9 +4587,40 @@ product INTEL WL_3165_1 0x3165 Dual Ban product INTEL WL_3165_20x3166 Dual Band Wireless AC 3165 product INTEL GLK_UHD_605 0x3184 UHD Graphics 605 product INTEL GLK_UHD_600 0x3185 UHD Graphics 600 +product INTEL GLK_DPTF 0x318c Gemini Lake DPTF +product INTEL GLK_GNA 0x3190 Gemini Lake GNA +product INTEL GLK_PMC 0x3194 Gemini Lake PMC +product INTEL GLK_HDA 0x3198 Gemini Lake HD Audio +product INTEL GLK_XHCI 0x31a8 Gemini Lake xHCI +product INTEL GLK_I2C_10x31ac Gemini Lake I2C +product INTEL GLK_I2C_20x31ae Gemini Lake I2C +product INTEL GLK_I2C_30x31b0 Gemini Lake I2C +product INTEL GLK_I2C_40x31b2 Gemini Lake I2C +product INTEL GLK_I2C_50x31b4 Gemini Lake I2C +product INTEL GLK_I2C_60x31b6 Gemini Lake I2C +product INTEL GLK_I2C_70x31b8 Gemini Lake I2C +product INTEL GLK_I2C_80x31ba Gemini Lake I2C +product INTEL GLK_UART_1 0x31bc Gemini Lake HSUART +product INTEL GLK_UART_2 0x31be Gemini Lake HSUART +product INTEL GLK_UART_3 0x31c0 Gemini Lake HSUART +product INTEL GLK_SPI_10x31c2 Gemini Lake SPI +product INTEL GLK_SPI_20x31c4 Gemini Lake SPI +product INTEL GLK_SPI_30x31c6 Gemini Lake SPI product INTEL GLK_SDMMC0x31ca Gemini Lake SD/MMC product INTEL GLK_EMMC 0x31cc Gemini Lake eMMC product INTEL GLK_SDIO 0x31d0 Gemini Lake SDIO +product INTEL GLK_SMB 0x31d4 Gemini Lake SMBus +product INTEL GLK_PCIE_1 0x31d6 Gemini Lake PCIE +product INTEL GLK_PCIE_2 0x31d7 Gemini Lake PCIE +product INTEL GLK_PCIE_3 0x31d8 Gemini Lake PCIE +product INTEL GLK_PCIE_4 0x31d9 Gemini Lake PCIE +product INTEL GLK_PCIE_5 0x31da Gemini Lake PCIE +product INTEL GLK_PCIE_6 0x31db Gemini Lake PCIE +product INTEL GLK_WL 0x31dc Gemini Lake CNVi +product INTEL GLK_AHCI 0x31e3 Gemini Lake AHCI +product INTEL GLK_LPC 0x31e8 Gemini Lake LPC +product INTEL GLK_UART_4 0x31ee Gemini Lake HSUART +product INTEL GLK_PCI_HB 0x31f0 Gemini Lake Host product INTEL 312440x3200 31244 SATA product INTEL 82855PM_HB 0x3340 82855PM Host product INTEL 82855PM_AGP 0x3341 82855PM AGP
