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(&vcpu->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&m=158026852003182&w=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 202
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, &ptm) != -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, &ptm) != -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, &domain->vdisk_list, entry) - guest_add_vdisk(guest, i++, vdisk->path); + guest_add_vdisk(guest, i++, vdisk->path, + vdisk->devalias); i = 0; SIMPLEQ_FOREACH(vnet, &domain->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
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(&sc->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