bgpd fix duplicate network check
The check if a network is already present is slightly wrong since it does
not check the type. I triggered it with:
network inet static
network 0.0.0.0/0
Fix is trivial.
--
:wq Claudio
Index: parse.y
===
RCS file: /cvs/src/usr.sbin/bgpd/parse.y,v
retrieving revision 1.388
diff -u -p -r1.388 parse.y
--- parse.y 27 May 2019 09:14:32 - 1.388
+++ parse.y 29 May 2019 05:21:55 -
@@ -868,7 +868,8 @@ network : NETWORK prefix filter_set {
filterset_move($3, &n->net.attrset);
free($3);
TAILQ_FOREACH(m, netconf, entry) {
- if (n->net.prefixlen == m->net.prefixlen &&
+ if (n->net.type == m->net.type &&
+ n->net.prefixlen == m->net.prefixlen &&
prefix_compare(&n->net.prefix,
&m->net.prefix, n->net.prefixlen) == 0)
yyerror("duplicate prefix "
Re: ospfd: allow specifying area by number as well as id
Hi David,
are you going to commit this?
Remi
On Thu, May 16, 2019 at 11:14:55PM +0200, Remi Locherer wrote:
> On Thu, May 16, 2019 at 09:39:37AM +0200, Sebastian Benoit wrote:
> >
> >
> >
> > Remi Locherer(remi.loche...@relo.ch) on 2019.05.15 23:15:03 +0200:
> > > On Tue, Apr 30, 2019 at 11:10:37PM +0200, Remi Locherer wrote:
> > > > On Mon, Apr 29, 2019 at 11:10:31AM +0100, Stuart Henderson wrote:
> > > > > On 2019/04/29 11:58, Sebastian Benoit wrote:
> > > > > > David Gwynne(da...@gwynne.id.au) on 2019.04.29 19:36:51 +1000:
> > > > > > >
> > > > > > >
> > > > > > > > On 29 Apr 2019, at 4:59 pm, Remi Locherer
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > Hi David
> > > > > > > >
> > > > > > > > On Mon, Apr 29, 2019 at 11:53:27AM +1000, David Gwynne wrote:
> > > > > > > >> it's always bothered me that i config areas on a crisco using
> > > > > > > >> a number,
> > > > > > > >> but then have to think hard to convert that number to an
> > > > > > > >> address for use
> > > > > > > >> in openbsd. eg, i was given area 700 in one place, which is
> > > > > > > >> 0.0.2.188
> > > > > > > >> as an address. super annoying.
> > > > > > > >>
> > > > > > > >> so this changes the ospfd parser so it accepts both a number
> > > > > > > >> or address.
> > > > > > > >> i also changed it so it prints the number by default, which
> > > > > > > >> may be
> > > > > > > >> contentious. the manpage is slightly tweaked too.
> > > > > > > >>
> > > > > > > >> thoughts?
> > > > > > > >
> > > > > > > > I like it to be able to use a number instead of an address!
> > > > > > > >
> > > > > > > > It worked fine in my short test I performed.
> > > > > > > >
> > > > > > > > The output with the comment looks a bit strange to me.
> > > > > > >
> > > > > > > Are you sure it doesn't look... awesome?
> > > > > >
> > > > > > I like it!
> > > > >
> > > > > I don't really, but if we change this it needs to be displayed somehow
> > > > > and I don't have an idea to make it look nicer than this (cisco's
> > > > > method
> > > > > seems pretty horrible and wouldn't work for us anyway - looks like
> > > > > they
> > > > > remember which format was used to configure an area and use that as
> > > > > the output format...)
> > > > >
> > > >
> > > > Maybe it's better when we just allow both input formats but don't change
> > > > any output.
> > >
> > > Any opinions or comments on this? I think this would be a valuable
> > > addition
> > > to ospfd.
> >
> > Yes, and diff is ok benno@
> >
>
> David: ok remi@ for your diff without the printconf part.
>
> > What about ospf6d?
>
> I'll handle that.
>
> >
> > > >
> > > > Below diff changes ospfctl to accept the address and number format for
> > > > "ospfct show database area XXX".
> > > >
> > > >
> > > > Index: parser.c
> > > > ===
> > > > RCS file: /cvs/src/usr.sbin/ospfctl/parser.c,v
> > > > retrieving revision 1.20
> > > > diff -u -p -r1.20 parser.c
> > > > --- parser.c9 May 2011 12:25:35 - 1.20
> > > > +++ parser.c30 Apr 2019 20:28:18 -
> > > > @@ -39,7 +39,8 @@ enum token_type {
> > > > ADDRESS,
> > > > FLAG,
> > > > PREFIX,
> > > > - IFNAME
> > > > + IFNAME,
> > > > + AREA
> > > > };
> > > >
> > > > struct token {
> > > > @@ -107,7 +108,7 @@ static const struct token t_show_db[] =
> > > > };
> > > >
> > > > static const struct token t_show_area[] = {
> > > > - {ADDRESS, "", NONE, NULL},
> > > > + {AREA, "", NONE, NULL},
> > > > {ENDTOKEN, "", NONE, NULL}
> > > > };
> > > >
> > > > @@ -218,6 +219,14 @@ match_token(const char *word, const stru
> > > > res->action = t->value;
> > > > }
> > > > break;
> > > > + case AREA:
> > > > + if (parse_area(word, &res->addr)) {
> > > > + match++;
> > > > + t = &table[i];
> > > > + if (t->value)
> > > > + res->action = t->value;
> > > > + }
> > > > + break;
> > > > case PREFIX:
> > > > if (parse_prefix(word, &res->addr,
> > > > &res->prefixlen)) {
> > > > match++;
> > > > @@ -274,6 +283,9 @@ show_valid_args(const struct token *tabl
> > > > case ADDRESS:
> > > > fprintf(stderr, " \n");
> > > > break;
> > > > + case AREA:
> > > > + fprintf(stderr, " \n");
> > > > + break;
> > > > case PREFIX:
> > > > fprintf(stderr, " [/]\n");
> > > >
Add support for hex floats to *scanf
I noticed that OpenBSD's fscanf doesn't yet support hex float strings,
which are standardized in C99. I am using them in my application (which
I would like to support OpenBSD), since the "%a" format specifier is a
convenient way to preserve the exact floating point value.
strtod already supports parsing hex floats, so it is just the scanner
in __svfscanf that needed changes.
The implementation reuses the PFXOK and NZDIGITS flags from CT_INT
scanning and follows similar logic to CT_INT. This required allocating
new flag values for DPTOK and EXPOK.
I did my best to follow style(9), but since the indentation level of this
switch is so high, I found it difficult wrap lines nicely. I noticed that
several existing lines broke the "space around binary operators" rule if
the added space would require unnatural wrapping, so I did the same here.
I wasn't sure which comments I should carry over from the CT_INT case
(for example, above `case 'x':`), or if any of the other changes require
additional comments. Please let me know if they do.
diff --git lib/libc/stdio/vfscanf.c lib/libc/stdio/vfscanf.c
index 5fb55d99e61..87134a9ef86 100644
--- lib/libc/stdio/vfscanf.c
+++ lib/libc/stdio/vfscanf.c
@@ -66,19 +66,19 @@
/*
* The following are used in numeric conversions only:
- * SIGNOK, HAVESIGN, NDIGITS, DPTOK, and EXPOK are for floating point;
- * SIGNOK, HAVESIGN, NDIGITS, PFXOK, and NZDIGITS are for integral.
+ * DPTOK and EXPOK are for floating point;
+ * SIGNOK, HAVESIGN, NDIGITS, PFXOK, and NZDIGITS are for integral and floating
+ * point.
*/
#defineSIGNOK 0x01000 /* +/- is (still) legal */
#defineHAVESIGN0x02000 /* sign detected */
#defineNDIGITS 0x04000 /* no digits detected */
-
-#defineDPTOK 0x08000 /* (float) decimal point is still legal
*/
-#defineEXPOK 0x1 /* (float) exponent (e+3, etc) still
legal */
-
#definePFXOK 0x08000 /* 0x prefix is (still) legal */
#defineNZDIGITS0x1 /* no zero digits detected */
+#defineDPTOK 0x2 /* (float) decimal point is still legal
*/
+#defineEXPOK 0x4 /* (float) exponent (e+3, etc) still
legal */
+
/*
* Conversion types.
*/
@@ -770,7 +770,8 @@ literal:
width = sizeof(buf) - 2;
width++;
#endif
- flags |= SIGNOK | NDIGITS | DPTOK | EXPOK;
+ flags |= SIGNOK | NDIGITS | NZDIGITS | DPTOK | EXPOK;
+ base = 10;
for (p = buf; width; width--) {
c = *fp->_p;
/*
@@ -779,15 +780,36 @@ literal:
*/
switch (c) {
- case '0': case '1': case '2': case '3':
+ case '0':
+ if ((flags&(NZDIGITS|NDIGITS|DPTOK)) ==
+ (NZDIGITS|NDIGITS|DPTOK))
+ flags |= PFXOK;
+ else
+ flags &= ~PFXOK;
+ flags &=
+ ~(SIGNOK | NZDIGITS | NDIGITS);
+ goto fok;
+
+ case '1': case '2': case '3':
case '4': case '5': case '6': case '7':
case '8': case '9':
- flags &= ~(SIGNOK | NDIGITS);
+ flags &= ~(SIGNOK | PFXOK | NDIGITS);
+ goto fok;
+
+ /* letters ok iff hex */
+ case 'A': case 'B': case 'C':
+ case 'D': case 'F':
+ case 'a': case 'b': case 'c':
+ case 'd': case 'f':
+ if (base == 10)
+ break; /* not legal here */
+ flags &= ~(SIGNOK | PFXOK | NDIGITS);
goto fok;
case '+': case '-':
if (flags & SIGNOK) {
flags &= ~SIGNOK;
+ flags |= HAVESIGN;
goto fok;
}
break;
@@ -799,11 +821,35 @@ literal:
break;
case 'e': case 'E':
/* no exponent without some digits */
-
vmd(8) i8042 device implementation questions
I have my i8042 device for vmd(8) mostly implemented. It’s only missing a few commands, but since there are no PS/2 input devices yet, there isn’t very much in the way of testing I can do beyond ensuring that commands act as they should. I have a couple questions about expected behavior, mostly related to the 8042 output port. * The 8042 controls the CPU reset line, but I’m not sure what the behavior should be in terms of vmm/vmd. Send a reset command if the reset line gets pulled low? * The 8042 controls Gate A20, which doesn’t seem to exist in the VM. I just have the output line not hooked up to anything. That OK? * There is nothing hooked up to the PS/2 ports since adding input devices is out of scope for my current diff. * Commands F0-F3 pulse 8042 output port bits low for 6uS. How should such timing be implemented in a vmd device? Once I get these cleared up, I should have a diff ready by the weekend. The 8042 already gets detected in the OpenBSD boot process! Katherine
bgpd "export default-route" [Re: CVS: cvs.openbsd.org: src]
On 2019/05/13 07:47, Denis Fondras wrote: > CVSROOT: /cvs > Module name: src > Changes by: de...@cvs.openbsd.org 2019/05/13 07:47:36 > > Modified files: > usr.sbin/bgpd : rde_update.c > > Log message: > fix export default-route. > > OK claudio@ > I've just been updating some remaining 6.3-ish boxes and running into problems with this.. Does anyone have a config with "export default-route" that works OK on -current that I could take a look at and see if I can figure out what I've missed? I started with a working 6.3 config that has several peer groups (all ibgp in this case). For one group it passes a full table, for another (a couple of firewalls/VPN boxes etc) it uses "announce default-route" to just feed a default route. In preparation for the update I made sure I have explicit default "deny from/to any" rules at the top of the ruleset, "allow to group XX" for that peer group, and no other rules that should deny the default route being sent to them. After updating to 6.5, 0 routes are received at the peer. After spotting the above commit I updated bgpd to -current, same again - no routes received at the peer. -current$ bgpctl sh rib out flags: * = Valid, > = Selected, I = via IBGP, A = Announced, S = Stale, E = Error origin validation state: N = not-found, V = valid, ! = invalid origin: i = IGP, e = EGP, ? = Incomplete flags ovs destination gateway lpref med aspath origin I* N 0.0.0.0/00.0.0.0100 0 i * N 0.0.0.0/00.0.0.0100 0 i * N 0.0.0.0/00.0.0.0100 0 i I* N 0.0.0.0/00.0.0.0100 0 i I* N 0.0.0.0/00.0.0.0100 0 i I* N 0.0.0.0/00.0.0.0100 0 i I* N 0.0.0.0/00.0.0.0100 0 i I* N 0.0.0.0/00.0.0.0100 0 i I* N ::/0 :: 100 0 i -current$ bgpctl sh rib out nei somepeer flags: * = Valid, > = Selected, I = via IBGP, A = Announced, S = Stale, E = Error origin validation state: N = not-found, V = valid, ! = invalid origin: i = IGP, e = EGP, ? = Incomplete flags ovs destination gateway lpref med aspath origin I* N 0.0.0.0/00.0.0.0100 0 i ... I'm not sure about the 0.0.0.0 for gateway, it doesn't feel right, but I can't compare with 6.3 because I don't see anything from "sh rib out nei XX" and a plain "sh rib out" isn't available there. somepeer$ bgpctl sh Neighbor ASMsgRcvdMsgSent OutQ Up/Down State/PrfRcvd (-current) x 386398 386395 0 00:53:13 0 (6.3) x 386382 386368 0 00:00:02 1 .. I've backed out to 2018/06/12 so I can remove my hastily-added static defaults ;) but would be grateful for any clues ..
Re: [Patch] Driver for Keyspan USA-19HS
Hi,
Some feedback inline:
On Tue, 28 May 2019 at 18:42:51 -0400, Cody Cutler wrote:
> Hello tech, I'm submitting the following patch for inclusion. The patch
> implements a driver for the Keyspan USA-19HS USB-to-serial dongle.
>
> I've used it for a few months now without any problems. Please let me know if
> you spot any problems.
>
> Thanks!
>
> diff --git sys/arch/amd64/conf/GENERIC sys/arch/amd64/conf/GENERIC
> index ad192f4ea1d..052915d10e0 100644
> --- sys/arch/amd64/conf/GENERIC
> +++ sys/arch/amd64/conf/GENERIC
> @@ -224,6 +224,8 @@ uvscom* at uhub?# SUNTAC Slipper U
> VS-10U serial
> ucom*at uvscom?
> ubsa*at uhub?# Belkin serial adapter
> ucom*at ubsa?
> +ukspan* at uhub? # Keyspan USA19HS
Nit: maybe add "serial adapter" at the end
> +ucom*at ukspan?
> uftdi* at uhub?# FTDI FT8U100AX serial adapter
> ucom*at uftdi?
> uplcom* at uhub? # I/O DATA USB-RSAQ2 serial adapter
> diff --git sys/dev/usb/files.usb sys/dev/usb/files.usb
> index 1036cf36232..29bc1205540 100644
> --- sys/dev/usb/files.usb
> +++ sys/dev/usb/files.usb
> @@ -317,6 +317,11 @@ device ubsa: ucombus
> attach ubsa at uhub
> file dev/usb/ubsa.c ubsa
>
> +# Keyspan USA19HS serial
> +device ukspan: ucombus
> +attach ukspan at uhub
> +file dev/usb/ukspan.cukspan
> +
> # Silicon Laboratories CP210x serial
> device uslcom: ucombus
> attach uslcom at uhub
> diff --git sys/dev/usb/ukspan.c sys/dev/usb/ukspan.c
> new file mode 100644
> index 000..749144058a0
> --- /dev/null
> +++ sys/dev/usb/ukspan.c
> @@ -0,0 +1,567 @@
> +#include
Please add a copyright and license at the top of the file.
/usr/share/misc/license.template is a good one to use.
Also, is there any documentation for the device that you used? A
URL to it is always useful to include in the header.
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +#if 0
> + #define DBG(...) do { printf("ukspan " __VA_ARGS__); } while (0)
> +#else
> + #define DBG(...)
> +#endif
Can you put that behind an ifdef UKSPAN_DEBUG and leave a commented
out example? That is usually how drivers do it.
/* #define UKSPAN_DEBUG */
#ifdef UKSPAN_DEBUG
#define DPRINTF(x...) do { printf(x); } while (0);
#else
#define DPRINTF(x...)
#endif
> +#define UKSPAN_PARITY_NONE 0x0
> +#define UKSPAN_PARITY_ODD0x08
> +#define UKSPAN_PARITY_EVEN 0x18
> +
> +#define UKSPAN_DATA_50x0
> +#define UKSPAN_DATA_60x1
> +#define UKSPAN_DATA_70x2
> +#define UKSPAN_DATA_80x3
> +
> +#define UKSPAN_STOP_10x0
> +#define UKSPAN_STOP_20x4
> +
> +#define UKSPAN_MAGIC 0x2
> +
> +#define UKSPAN_CLOCK 14769231
> +
> +/*
> + * The following USB endpoint addresses may be specific to the Keyspan
> USA19HS
> + * device
> + */
> +#define UKSPAN_CONFIG_IDX1
> +#define UKSPAN_IFACE_IDX 0
> +
> +#define UKSPAN_EA_BULKIN (UE_DIR_IN | 1)
> +#define UKSPAN_EA_BULKOUT(UE_DIR_OUT | 1)
> +#define UKSPAN_EA_CONFIGIN (UE_DIR_IN | 2)
> +#define UKSPAN_EA_CONFIGOUT (UE_DIR_OUT | 2)
> +
> +/* Sent to device on control out endpoint */
> +struct ukspan_cmsg {
> + uint8_t setclock;
> + uint8_t baudlo;
> + uint8_t baudhi;
> + uint8_t setlcr;
> + uint8_t lcr;
> + uint8_t setrxmode;
> + uint8_t rxmode;
> + uint8_t settxmode;
> + uint8_t txmode;
> + uint8_t settxflowcontrol;
> + uint8_t txflowcontrol;
> + uint8_t setrxflowcontrol;
> + uint8_t rxflowcontrol;
> + uint8_t sendxoff;
> + uint8_t sendxon;
> + uint8_t xonchar;
> + uint8_t xoffchar;
> + uint8_t sendchar;
> + uint8_t txchar;
> + uint8_t setrts;
> + uint8_t rts;
> + uint8_t setdtr;
> + uint8_t dtr;
> +
> + uint8_t rxforwardingchars;
> + uint8_t rxforwardingtimeoutms;
> + uint8_t txacksetting;
> +
> + uint8_t portenabled;
> + uint8_t txflush;
> + uint8_t txbreak;
> + uint8_t loopbackmode;
> +
> + uint8_t rxflush;
> + uint8_t rxforward;
> + uint8_t cancelrxoff;
> + uint8_t returnstatus;
> +};
> +
> +/* Received from device on control in endpoint */
> +struct ukspan_smsg {
> + uint8_t msr;
> + uint8_t cts;
> + uint8_t dcd;
> + uint8_t dsr;
> + uint8_t ri;
> + uint8_t txxoff;
> + uint8_t rxbreak;
> + uint8_t rxoverrun;
> + uint8_t rxparity;
> + uint8_t rxframe;
> + uint8_t portstate;
> + uint8_t messageack;
> + uint8_t charack;
> + uint8_t controlresp;
> +};
If these structures are communicated directly with the device, it's
a good idea to make the structs have the __packed attribute.
struct ukspan_smsg {
...
} __packed;
> +
> +struct ukspan_softc {
> + stru
[Patch] Driver for Keyspan USA-19HS
Hello tech, I'm submitting the following patch for inclusion. The patch
implements a driver for the Keyspan USA-19HS USB-to-serial dongle.
I've used it for a few months now without any problems. Please let me know if
you spot any problems.
Thanks!
diff --git sys/arch/amd64/conf/GENERIC sys/arch/amd64/conf/GENERIC
index ad192f4ea1d..052915d10e0 100644
--- sys/arch/amd64/conf/GENERIC
+++ sys/arch/amd64/conf/GENERIC
@@ -224,6 +224,8 @@ uvscom* at uhub?# SUNTAC Slipper U
VS-10U serial
ucom* at uvscom?
ubsa* at uhub?# Belkin serial adapter
ucom* at ubsa?
+ukspan* at uhub? # Keyspan USA19HS
+ucom* at ukspan?
uftdi* at uhub?# FTDI FT8U100AX serial adapter
ucom* at uftdi?
uplcom* at uhub? # I/O DATA USB-RSAQ2 serial adapter
diff --git sys/dev/usb/files.usb sys/dev/usb/files.usb
index 1036cf36232..29bc1205540 100644
--- sys/dev/usb/files.usb
+++ sys/dev/usb/files.usb
@@ -317,6 +317,11 @@ device ubsa: ucombus
attach ubsa at uhub
file dev/usb/ubsa.c ubsa
+# Keyspan USA19HS serial
+device ukspan: ucombus
+attach ukspan at uhub
+file dev/usb/ukspan.cukspan
+
# Silicon Laboratories CP210x serial
device uslcom: ucombus
attach uslcom at uhub
diff --git sys/dev/usb/ukspan.c sys/dev/usb/ukspan.c
new file mode 100644
index 000..749144058a0
--- /dev/null
+++ sys/dev/usb/ukspan.c
@@ -0,0 +1,567 @@
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#include
+
+#if 0
+ #define DBG(...) do { printf("ukspan " __VA_ARGS__); } while (0)
+#else
+ #define DBG(...)
+#endif
+
+#define UKSPAN_PARITY_NONE 0x0
+#define UKSPAN_PARITY_ODD 0x08
+#define UKSPAN_PARITY_EVEN 0x18
+
+#define UKSPAN_DATA_5 0x0
+#define UKSPAN_DATA_6 0x1
+#define UKSPAN_DATA_7 0x2
+#define UKSPAN_DATA_8 0x3
+
+#define UKSPAN_STOP_1 0x0
+#define UKSPAN_STOP_2 0x4
+
+#define UKSPAN_MAGIC 0x2
+
+#define UKSPAN_CLOCK 14769231
+
+/*
+ * The following USB endpoint addresses may be specific to the Keyspan USA19HS
+ * device
+ */
+#define UKSPAN_CONFIG_IDX 1
+#define UKSPAN_IFACE_IDX 0
+
+#define UKSPAN_EA_BULKIN (UE_DIR_IN | 1)
+#define UKSPAN_EA_BULKOUT (UE_DIR_OUT | 1)
+#define UKSPAN_EA_CONFIGIN (UE_DIR_IN | 2)
+#define UKSPAN_EA_CONFIGOUT(UE_DIR_OUT | 2)
+
+/* Sent to device on control out endpoint */
+struct ukspan_cmsg {
+ uint8_t setclock;
+ uint8_t baudlo;
+ uint8_t baudhi;
+ uint8_t setlcr;
+ uint8_t lcr;
+ uint8_t setrxmode;
+ uint8_t rxmode;
+ uint8_t settxmode;
+ uint8_t txmode;
+ uint8_t settxflowcontrol;
+ uint8_t txflowcontrol;
+ uint8_t setrxflowcontrol;
+ uint8_t rxflowcontrol;
+ uint8_t sendxoff;
+ uint8_t sendxon;
+ uint8_t xonchar;
+ uint8_t xoffchar;
+ uint8_t sendchar;
+ uint8_t txchar;
+ uint8_t setrts;
+ uint8_t rts;
+ uint8_t setdtr;
+ uint8_t dtr;
+
+ uint8_t rxforwardingchars;
+ uint8_t rxforwardingtimeoutms;
+ uint8_t txacksetting;
+
+ uint8_t portenabled;
+ uint8_t txflush;
+ uint8_t txbreak;
+ uint8_t loopbackmode;
+
+ uint8_t rxflush;
+ uint8_t rxforward;
+ uint8_t cancelrxoff;
+ uint8_t returnstatus;
+};
+
+/* Received from device on control in endpoint */
+struct ukspan_smsg {
+ uint8_t msr;
+ uint8_t cts;
+ uint8_t dcd;
+ uint8_t dsr;
+ uint8_t ri;
+ uint8_t txxoff;
+ uint8_t rxbreak;
+ uint8_t rxoverrun;
+ uint8_t rxparity;
+ uint8_t rxframe;
+ uint8_t portstate;
+ uint8_t messageack;
+ uint8_t charack;
+ uint8_t controlresp;
+};
+
+struct ukspan_softc {
+ struct device sc_dev;
+ struct usbd_device *udev;
+ struct usbd_interface *iface;
+ struct usbd_pipe *cout_pipe;
+ struct usbd_pipe *cin_pipe;
+ struct usbd_xfer *ixfer;
+ struct usbd_xfer *oxfer;
+ struct device *ucom_dev;
+ struct ukspan_smsg smsg;
+ struct ukspan_cmsg cmsg;
+ u_char lsr;
+ u_char msr;
+};
+
+int ukspan_match(struct device *, void *, void *);
+void ukspan_attach(struct device *, struct device *, void *);
+int ukspan_detach(struct device *, int);
+
+void ukspan_close(void *, int);
+int ukspan_open(void *, int);
+int ukspan_param(void *, int, struct termios *);
+void ukspan_set(void *, int, int, int);
+void ukspan_get_status(void *, int, u_char *, u_char *);
+
+void kmsg_init(bool, struct ukspan_cmsg *);
+int send_cmsg(struct ukspan_softc *);
+void ukspan_incb(struct usbd_xfer *, void *, usbd_status);
+void ukspan_outcb(struct usbd_xfer *, void *, usbd_status);
+void ukspan_destroy(struct ukspan_softc *);
+
+struct cfdriver ukspan_cd = {
+ NULL, "ukspan", DV_DULL
+};
+
+const struct cfattach ukspa
[patch] rsync: fix for closing uninitialized file descriptor
Hi,
I noticed the following with the reproducable command:
openrsync -av rsync://127.0.0.1/ftp/ a
ktrace:
-> 99882 openrsync CALL close(1249939456)
-> 99882 openrsync RET close -1 errno 9 Bad file descriptor
99882 openrsync CALL kbind(0x7f7f7a50,24,0x281ae61c4bf1563c)
99882 openrsync RET kbind 0
99882 openrsync CALL socket(AF_INET,0x1,0)
99882 openrsync RET socket 3
rsync_connect is called with sd uninitialized, but in inet_connect() it checks
against sd:
if (*sd != -1)
close(*sd);
Patch below:
diff --git usr.bin/rsync/main.c usr.bin/rsync/main.c
index 967e6528bc2..fa0e749e642 100644
--- usr.bin/rsync/main.c
+++ usr.bin/rsync/main.c
@@ -271,7 +271,7 @@ main(int argc, char *argv[])
{
struct opts opts;
pid_tchild;
- int fds[2], sd, rc, c, st, i;
+ int fds[2], sd = -1, rc, c, st, i;
struct sess sess;
struct fargs*fargs;
char**args;
--
Kind regards,
Hiltjo
Re: bgpd set nexthop 198.51.100.42 clarifications
On Tue, May 28, 2019 at 05:17:08PM +0200, Claudio Jeker wrote: > On Tue, May 28, 2019 at 01:28:32PM +0200, Job Snijders wrote: > > On Mon, May 13, 2019 at 09:03:41PM +0200, Claudio Jeker wrote: > > > When using a rule forcing the nexthop to a specific address bgpd > > > currently does not mark that nexthop as no-modify. In other words > > > the default rules for nexthop propagation applies. This means that > > > for ebgp it only sends out the set nexthop when this nexthop is connected > > > and on the same network as the peer. So while the Adj-RIB-Out shows the > > > right nexthop it is actually not on the wire. > > > > > > This diff changes set nexthop 198.51.100.42 to also imply set nexthop > > > no-modify. This way the set nexthop is always on the wire. > > > The problem with that is that it will hand you a nice footgun ready to > > > blow of your big toe (but in the end the current behaviour is doing the > > > same just with a different angle of attack) . > > > > > > The set nexthop section in bgpd.conf.5 needs to be adjusted once a > > > decision is made on how to handle this. > > > > I think I'm not a big fan of this change. > > > > Section 5.1.3 of RFC 4271 (the core BGP spec) is very explicit on > > what NEXT_HOPs are valid to send over a non-multihop BGP session. > > Only addresses that are part of the linknet between the two routers > > are valid NEXT_HOP addresses on the wire. This changes makes it > > trivial to send not-valid NEXT_HOPs to a neighbor, this may result > > in very hard to debug troublecases. Feels like we'll be handing way > > too much rope to users, especially since it facilitates protocol > > violations. > > > > I am not aware of a real world BGP implementation that would allow > > you to send completely arbitrary NEXT_HOPs. > > I came to a similar conclusion and will send out a better diff. The > idea is that for the non-multihop BGP sessions we should require the > nexthop to be in the same network. With 'same network', you mean the NEXT_HOP IP address must be part of the router-to-router linknet, right? > The ebgp multihop case is currently always sticking to the local > address and should probably respect the nexthop if set explicitly > (that is also what the RFC suggests). Right. > ibgp seems to do the right thing. yup, in IBGP the NEXT_HOP can be anything. > The same rules need to be applied to "set nexthop no-modify" since > that is currently on massive hammer. Right. Thanks! Kind regards, Job
Re: usr.bin/getconf: Add reporting LONG_BIT
On 5/28/19 8:21 AM, Jeremie Courreges-Anglas wrote: On Mon, May 27 2019, Philip Guenther wrote: On Mon, May 27, 2019 at 3:43 PM Brian Callahan wrote: Below is a small diff in response to some configuration attempts found in ports land. lang/ponyc uses $(shell getconf LONG_BIT) in its Makefile to determine whether or not we're on a 64-bit platform. It needs to know that at the scripting level, outside of the C code itself where it can directly test LONG_BIT (or perhaps better, _LP64)? Huh. However, our getconf(1) doesn't support reporting LONG_BIT. This diff enables it. GNU/FreeBSD/DragonFly/MacOS getconf reports LONG_BIT, but NetBSD getconf does not. Desirable? OK? That's the way to do it, I just have this vague "what tempting lunacy has led them to this?" lurking in my mind. I'll let Brian confirm but this got me curious. Here's the dance I found in the Makefile for ponyc: --8<-- # Default settings (silent release build). config ?= release arch ?= native tune ?= generic cpu ?= $(arch) fpu ?= bits ?= $(shell getconf LONG_BIT) [...] # Determine pointer size in bits. BITS := $(bits) UNAME_M := $(shell uname -m) ifeq ($(BITS),64) ifeq ($(UNAME_M),x86_64) ifeq (,$(filter $(arch), armv8-a)) BUILD_FLAGS += -mcx16 LINKER_FLAGS += -mcx16 endif endif endif -->8-- So IIUC the build tries to use -mcx16 on amd64, except if the target architecture is armv8-a. This looks bogus, I guess what upstream wants is to use -mcx16 only when doing a build *targetting* amd64. The value of LONG_BIT on the build machine doesn't seem relevant to achieve that, but I may be missing something. Welcome to ports... I can confirm with upstream, but I read it as they want to avoid adding the flag if you're using the x32 ABI... but I agree with you in that using the build machine info to understand something about the target machine isn't the right way to go about it. ~Brian
Re: bgpd set nexthop 198.51.100.42 clarifications
On Tue, May 28, 2019 at 01:28:32PM +0200, Job Snijders wrote: > Hi, > > On Mon, May 13, 2019 at 09:03:41PM +0200, Claudio Jeker wrote: > > When using a rule forcing the nexthop to a specific address bgpd > > currently does not mark that nexthop as no-modify. In other words > > the default rules for nexthop propagation applies. This means that > > for ebgp it only sends out the set nexthop when this nexthop is connected > > and on the same network as the peer. So while the Adj-RIB-Out shows the > > right nexthop it is actually not on the wire. > > > > This diff changes set nexthop 198.51.100.42 to also imply set nexthop > > no-modify. This way the set nexthop is always on the wire. > > The problem with that is that it will hand you a nice footgun ready to > > blow of your big toe (but in the end the current behaviour is doing the > > same just with a different angle of attack) . > > > > The set nexthop section in bgpd.conf.5 needs to be adjusted once a > > decision is made on how to handle this. > > I think I'm not a big fan of this change. > > Section 5.1.3 of RFC 4271 (the core BGP spec) is very explicit on what > NEXT_HOPs are valid to send over a non-multihop BGP session. Only > addresses that are part of the linknet between the two routers are valid > NEXT_HOP addresses on the wire. This changes makes it trivial to send > not-valid NEXT_HOPs to a neighbor, this may result in very hard to debug > troublecases. Feels like we'll be handing way too much rope to users, > especially since it facilitates protocol violations. > > I am not aware of a real world BGP implementation that would allow you > to send completely arbitrary NEXT_HOPs. > I came to a similar conclusion and will send out a better diff. The idea is that for the non-multihop BGP sessions we should require the nexthop to be in the same network. The ebgp multihop case is currently always sticking to the local address and should probably respect the nexthop if set explicitly (that is also what the RFC suggests). ibgp seems to do the right thing. The same rules need to be applied to "set nexthop no-modify" since that is currently on massive hammer. -- :wq Claudio
Re: bgpd communities rewrite
On Tue, May 14, 2019 at 12:37:25AM +0200, Claudio Jeker wrote:
> This diff changes the way communites are stored and modified in bgpd.
> The current implementation was showing that community_*_delete() consumed
> a lot of CPU time because of the way rde_attr was used.
> Communities are extensivly used by filters (e.g. arouteserver) and
> therefor they are stored in an own special datastructure that allows fast
> changes especially during filtering. The communities are now a special
> part of the filterstate and because of this set and delete of a community
> is much simpler.
>
> This seems to make my test setup a fair bit snappier and quicker at
> processing UPDATEs.
While the old diff got us to warp speed this diff goes to warp 5 or 6.
It optimizes the filter functions community_match, community_delete and
community_set to be as quick as possible since those functions are in the
hot path. As a side-effect the filter specific community struct got removed
and everything uses the unified one (which is where I wanted to end up).
Please test (especially the ext. community cases since extended
communities are just painful)
--
:wq Claudio
Index: usr.sbin/bgpctl/bgpctl.c
===
RCS file: /cvs/src/usr.sbin/bgpctl/bgpctl.c,v
retrieving revision 1.238
diff -u -p -r1.238 bgpctl.c
--- usr.sbin/bgpctl/bgpctl.c23 May 2019 14:12:06 - 1.238
+++ usr.sbin/bgpctl/bgpctl.c28 May 2019 13:24:30 -
@@ -81,6 +81,7 @@ intshow_rib_detail_msg(struct imsg *,
voidshow_rib_brief(struct ctl_show_rib *, u_char *);
voidshow_rib_detail(struct ctl_show_rib *, u_char *, int, int);
voidshow_attr(void *, u_int16_t, int);
+voidshow_communities(u_char *, size_t, int);
voidshow_community(u_char *, u_int16_t);
voidshow_large_community(u_char *, u_int16_t);
voidshow_ext_community(u_char *, u_int16_t);
@@ -282,7 +283,7 @@ main(int argc, char *argv[])
}
if (res->as.type != AS_UNDEF)
ribreq.as = res->as;
- if (res->community.type != COMMUNITY_TYPE_NONE)
+ if (res->community.flags != 0)
ribreq.community = res->community;
ribreq.neighbor = neighbor;
strlcpy(ribreq.rib, res->rib, sizeof(ribreq.rib));
@@ -1252,6 +1253,12 @@ show_rib_detail_msg(struct imsg *imsg, i
asdata += sizeof(struct ctl_show_rib);
show_rib_detail(&rib, asdata, nodescr, flag0);
break;
+ case IMSG_CTL_SHOW_RIB_COMMUNITIES:
+ ilen = imsg->hdr.len - IMSG_HEADER_SIZE;
+ if (ilen % sizeof(struct community))
+ errx(1, "bad IMSG_CTL_SHOW_RIB_COMMUNITIES received");
+ show_communities(imsg->data, ilen, flag0);
+ break;
case IMSG_CTL_SHOW_RIB_ATTR:
ilen = imsg->hdr.len - IMSG_HEADER_SIZE;
if (ilen < 3)
@@ -1632,6 +1639,154 @@ show_attr(void *b, u_int16_t len, int fl
printf("%c", EOL0(flag0));
}
+static void
+print_community(u_int16_t a, u_int16_t v)
+{
+ if (a == COMMUNITY_WELLKNOWN)
+ switch (v) {
+ case COMMUNITY_GRACEFUL_SHUTDOWN:
+ printf("GRACEFUL_SHUTDOWN");
+ break;
+ case COMMUNITY_NO_EXPORT:
+ printf("NO_EXPORT");
+ break;
+ case COMMUNITY_NO_ADVERTISE:
+ printf("NO_ADVERTISE");
+ break;
+ case COMMUNITY_NO_EXPSUBCONFED:
+ printf("NO_EXPORT_SUBCONFED");
+ break;
+ case COMMUNITY_NO_PEER:
+ printf("NO_PEER");
+ break;
+ case COMMUNITY_BLACKHOLE:
+ printf("BLACKHOLE");
+ break;
+ default:
+ printf("%hu:%hu", a, v);
+ break;
+ }
+ else
+ printf("%hu:%hu", a, v);
+}
+
+static void
+print_ext_community(u_int8_t *data)
+{
+ u_int64_t ext;
+ struct in_addr ip;
+ u_int32_t as4, u32;
+ u_int16_t as2, u16;
+ u_int8_ttype, subtype;
+
+ type = data[0];
+ subtype = data[1];
+
+ printf("%s ", log_ext_subtype(type, subtype));
+
+ switch (type) {
+ case EXT_COMMUNITY_TRANS_TWO_AS:
+ memcpy(&as2, data + 2, sizeof(as2));
+ memcpy(&u32, data + 4, sizeof(u32));
+ printf("%s:%u", log_as(ntohs(as2)), ntohl(u32));
+ break;
+ case EXT_COMMUNITY_TRANS_IPV4:
+ memcpy(&ip, data + 2, sizeof(ip));
+ memcpy(&u16, data + 6, sizeof(u16));
+ printf("%s:%hu", inet_ntoa(ip), ntoh
Re: bgpd: better tcp md5sig handling
On Tue, May 21, 2019 at 05:59:18PM +0200, Claudio Jeker wrote:
> Hi,
>
> The last refactor of the pfkey handling uncovered an issue deep down in
> the pfkey handling. Some long time ago henning@ added a sleep(1) into
> pfkey_md5sig_establish(). This is now hunting us back because bgpd ends up
> with no tcp md5sig flow for 1 sec while a connection is established.
> Because of that writes failed with "Operation not permitted"
> semi-frequently. Now a lot of the dance around pfkey is rather annoying,
> it is not possible to do atomic updates of SADB_X_SATYPE_TCPSIGNATURE
> entries. So instead I decided to insert new flows and then remove the old
> ones in a second step. Since this is done now all the time it is no longer
> needed to pfkey_remove(p) before calling pfkey_establish(p).
> pfkey_establish(p) will do that now itself when needed.
>
> While checking the code I noticed that we leave keys behind when removing
> peers in the config. I added the needed pfkey_remove(p) call in
> merge_config() for that. This could be commited independently.
>
> With this in the regress test works a lot better and my basic testing
> seems to be good as well. Please test if you are using tcp md5sum or ipsec
> in your bgpd config.
>
Guess nobody is using and suffering of tcp md5sum. Should I just commit
and wait for bug reports?
--
:wq Claudio
Index: bgpd.c
===
RCS file: /cvs/src/usr.sbin/bgpd/bgpd.c,v
retrieving revision 1.217
diff -u -p -r1.217 bgpd.c
--- bgpd.c 8 May 2019 18:48:34 - 1.217
+++ bgpd.c 21 May 2019 12:30:00 -
@@ -799,11 +799,9 @@ dispatch_imsg(struct imsgbuf *ibuf, int
log_warnx("pfkey reload: no such peer: id=%u",
imsg.hdr.peerid);
else {
- pfkey_remove(p);
- if (pfkey_establish(p) == -1) {
+ if (pfkey_establish(p) == -1)
log_peer_warnx(&p->conf,
"pfkey setup failed");
- }
}
break;
case IMSG_CTL_RELOAD:
Index: config.c
===
RCS file: /cvs/src/usr.sbin/bgpd/config.c,v
retrieving revision 1.88
diff -u -p -r1.88 config.c
--- config.c8 May 2019 12:41:55 - 1.88
+++ config.c21 May 2019 13:44:50 -
@@ -322,6 +322,9 @@ merge_config(struct bgpd_config *xconf,
np->reconf_action = RECONF_KEEP;
/* copy the auth state since parent uses it */
np->auth = p->auth;
+ } else {
+ /* peer no longer exists, clear pfkey state */
+ pfkey_remove(p);
}
TAILQ_REMOVE(&xconf->peers, p, entry);
Index: pfkey.c
===
RCS file: /cvs/src/usr.sbin/bgpd/pfkey.c,v
retrieving revision 1.55
diff -u -p -r1.55 pfkey.c
--- pfkey.c 8 May 2019 12:41:55 - 1.55
+++ pfkey.c 21 May 2019 15:27:53 -
@@ -50,13 +50,6 @@ int pfkey_send(int, uint8_t, uint8_t, ui
struct bgpd_addr *, struct bgpd_addr *,
u_int32_t, uint8_t, int, char *, uint8_t, int, char *,
uint16_t, uint16_t);
-intpfkey_sa_add(struct bgpd_addr *, struct bgpd_addr *, u_int8_t, char *,
- u_int32_t *);
-intpfkey_sa_remove(struct bgpd_addr *, struct bgpd_addr *, u_int32_t *);
-intpfkey_md5sig_establish(struct peer *);
-intpfkey_md5sig_remove(struct peer *);
-intpfkey_ipsec_establish(struct peer *);
-intpfkey_ipsec_remove(struct peer *);
#define pfkey_flow(fd, satype, cmd, dir, from, to, sport, dport) \
pfkey_send(fd, satype, cmd, dir, from, to, \
@@ -404,7 +397,7 @@ pfkey_send(int sd, uint8_t satype, uint8
} while (n == -1 && (errno == EAGAIN || errno == EINTR));
if (n == -1) {
- log_warn("writev (%d/%d)", iov_cnt, len);
+ log_warn("%s: writev (%d/%d)", __func__, iov_cnt, len);
return (-1);
}
@@ -502,7 +495,7 @@ pfkey_reply(int sd, u_int32_t *spi)
return (0);
}
-int
+static int
pfkey_sa_add(struct bgpd_addr *src, struct bgpd_addr *dst, u_int8_t keylen,
char *key, u_int32_t *spi)
{
@@ -519,7 +512,7 @@ pfkey_sa_add(struct bgpd_addr *src, stru
return (0);
}
-int
+static int
pfkey_sa_remove(struct bgpd_addr *src, struct bgpd_addr *dst, u_int32_t *spi)
{
if (pfkey_send(pfkey_fd, SADB_X_SATYPE_TCPSIGNATURE, SADB_DELETE, 0,
@@ -531,47 +524,71 @@ pfkey_sa_remove(struct bgpd_addr *src, s
return (0);
}
-int
+static int
pfkey_md5sig_establish(struct peer *p)
{
- sleep(1);
+ u_int32_t spi_out = 0;
+ u_int32_t spi_in
Re: usr.bin/getconf: Add reporting LONG_BIT
On Mon, May 27 2019, Philip Guenther wrote: > On Mon, May 27, 2019 at 3:43 PM Brian Callahan wrote: > >> Below is a small diff in response to some configuration attempts >> found in ports land. >> lang/ponyc uses $(shell getconf LONG_BIT) in its Makefile to >> determine whether or not we're on a 64-bit platform. >> > > It needs to know that at the scripting level, outside of the C code itself > where it can directly test LONG_BIT (or perhaps better, _LP64)? Huh. > > > >> However, our getconf(1) doesn't support reporting LONG_BIT. >> This diff enables it. GNU/FreeBSD/DragonFly/MacOS getconf reports >> LONG_BIT, but NetBSD getconf does not. >> Desirable? OK? >> > > That's the way to do it, I just have this vague "what tempting lunacy has > led them to this?" lurking in my mind. I'll let Brian confirm but this got me curious. Here's the dance I found in the Makefile for ponyc: --8<-- # Default settings (silent release build). config ?= release arch ?= native tune ?= generic cpu ?= $(arch) fpu ?= bits ?= $(shell getconf LONG_BIT) [...] # Determine pointer size in bits. BITS := $(bits) UNAME_M := $(shell uname -m) ifeq ($(BITS),64) ifeq ($(UNAME_M),x86_64) ifeq (,$(filter $(arch), armv8-a)) BUILD_FLAGS += -mcx16 LINKER_FLAGS += -mcx16 endif endif endif -->8-- So IIUC the build tries to use -mcx16 on amd64, except if the target architecture is armv8-a. This looks bogus, I guess what upstream wants is to use -mcx16 only when doing a build *targetting* amd64. The value of LONG_BIT on the build machine doesn't seem relevant to achieve that, but I may be missing something. Welcome to ports... -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: usr.bin/getconf: Add reporting LONG_BIT
On 5/28/19 7:24 AM, Christian Weisgerber wrote: Brian Callahan: lang/ponyc uses $(shell getconf LONG_BIT) in its Makefile to determine whether or not we're on a 64-bit platform. However, our getconf(1) doesn't support reporting LONG_BIT. This diff enables it. GNU/FreeBSD/DragonFly/MacOS getconf reports LONG_BIT, but NetBSD getconf does not. It appears to be part of a larger extension that adds all numerical limits from POSIX : $ ssh freebsd-box $ getconf LONG_MIN -9223372036854775808 $ getconf LONG_MAX 9223372036854775807 $ getconf LONG_BIT 64 If we add any of this, shouldn't we add all of it? Sure; I cherry picked what I needed since I wasn't sure if this was a direction we wanted to go in but I can make it more complete. Or, if there's a better way to do what I need (get a GNU Makefile to figure out whether or not its on a 64-bit or 32-bit platform) then I'll just withdraw this diff in favor of amending the port. ~Brian
Re: bgpd set nexthop 198.51.100.42 clarifications
Hi, On Mon, May 13, 2019 at 09:03:41PM +0200, Claudio Jeker wrote: > When using a rule forcing the nexthop to a specific address bgpd > currently does not mark that nexthop as no-modify. In other words > the default rules for nexthop propagation applies. This means that > for ebgp it only sends out the set nexthop when this nexthop is connected > and on the same network as the peer. So while the Adj-RIB-Out shows the > right nexthop it is actually not on the wire. > > This diff changes set nexthop 198.51.100.42 to also imply set nexthop > no-modify. This way the set nexthop is always on the wire. > The problem with that is that it will hand you a nice footgun ready to > blow of your big toe (but in the end the current behaviour is doing the > same just with a different angle of attack) . > > The set nexthop section in bgpd.conf.5 needs to be adjusted once a > decision is made on how to handle this. I think I'm not a big fan of this change. Section 5.1.3 of RFC 4271 (the core BGP spec) is very explicit on what NEXT_HOPs are valid to send over a non-multihop BGP session. Only addresses that are part of the linknet between the two routers are valid NEXT_HOP addresses on the wire. This changes makes it trivial to send not-valid NEXT_HOPs to a neighbor, this may result in very hard to debug troublecases. Feels like we'll be handing way too much rope to users, especially since it facilitates protocol violations. I am not aware of a real world BGP implementation that would allow you to send completely arbitrary NEXT_HOPs. Kind regards, Job
Re: usr.bin/getconf: Add reporting LONG_BIT
Brian Callahan: > lang/ponyc uses $(shell getconf LONG_BIT) in its Makefile to > determine whether or not we're on a 64-bit platform. > However, our getconf(1) doesn't support reporting LONG_BIT. > This diff enables it. GNU/FreeBSD/DragonFly/MacOS getconf reports > LONG_BIT, but NetBSD getconf does not. It appears to be part of a larger extension that adds all numerical limits from POSIX : $ ssh freebsd-box $ getconf LONG_MIN -9223372036854775808 $ getconf LONG_MAX 9223372036854775807 $ getconf LONG_BIT 64 If we add any of this, shouldn't we add all of it? -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: Attach kvm-clock to Linux guests on VMM
On Mon, May 27 2019, Pratik Vyas wrote: * Renato Aguiar [2019-05-27 03:53:11 -0700]: Hi, The following patch makes Linux guests use kvm-clock by setting KVM's CPUID signature on VMM: I think the right thing is to make linux attach pvclock if it's on OpenBSD vmm. You want to send them a patch? It makes sense. I checked Linux's source code again and it seems to share the same pvclock implementation with KVM and Xen already. It shouldn't be hard to include VMM too. I'll try that out. Otherwise, does vmm pvclock keep good time on linux from your experiments? I didn't do long term testing, but from what I could see it keeps the clock in sync with the host. -- Renato Aguiar
Re: Attach kvm-clock to Linux guests on VMM
On Mon, May 27 2019, Mike Larkin wrote:
On Mon, May 27, 2019 at 03:53:11AM -0700, Renato Aguiar wrote:
Hi,
The following patch makes Linux guests use kvm-clock by setting
KVM's CPUID
signature on VMM:
By saying the hypervisor is KVM to all guests, does this cause
the guests
to make other assumptions we don't want?
I'm not sure. Linux seems to be fine with it, but it may cause
issues with other OSs.
I'll try implementing it on the Linux side instead.
Index: sys/arch/amd64/amd64/vmm.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/vmm.c,v
retrieving revision 1.245
diff -u -p -r1.245 vmm.c
--- sys/arch/amd64/amd64/vmm.c 17 May 2019 19:07:15 -
1.245
+++ sys/arch/amd64/amd64/vmm.c 27 May 2019 09:44:07 -
@@ -238,6 +238,7 @@ extern uint64_t tsc_frequency;
extern int tsc_is_invariant;
const char *vmm_hv_signature = VMM_HV_SIGNATURE;
+const char *kvm_hv_signature = KVM_HV_SIGNATURE;
const struct kmem_pa_mode vmm_kp_contig = {
.kp_constraint = &no_constraint,
@@ -6433,7 +6434,14 @@ vmm_handle_cpuid(struct vcpu *vcpu)
*rcx = *((uint32_t *)&vmm_hv_signature[4]);
*rdx = *((uint32_t *)&vmm_hv_signature[8]);
break;
+ case 0x4100:/* KVM CPUID signature */
+ *rax = 0;
+ *rbx = *((uint32_t *)&kvm_hv_signature[0]);
+ *rcx = *((uint32_t *)&kvm_hv_signature[4]);
+ *rdx = *((uint32_t *)&kvm_hv_signature[8]);
+ break;
case 0x4001:/* KVM hypervisor features */
+ case 0x4101:
*rax = (1 << KVM_FEATURE_CLOCKSOURCE2) |
(1 << KVM_FEATURE_CLOCKSOURCE_STABLE_BIT);
*rbx = 0;
Index: sys/arch/amd64/include/vmmvar.h
===
RCS file: /cvs/src/sys/arch/amd64/include/vmmvar.h,v
retrieving revision 1.66
diff -u -p -r1.66 vmmvar.h
--- sys/arch/amd64/include/vmmvar.h 17 May 2019 19:07:16 -
1.66
+++ sys/arch/amd64/include/vmmvar.h 27 May 2019 09:44:07 -
@@ -22,6 +22,7 @@
#define _MACHINE_VMMVAR_H_
#define VMM_HV_SIGNATURE"OpenBSDVMM58"
+#define KVM_HV_SIGNATURE "KVMKVMKVM\0\0\0"
#define VMM_MAX_MEM_RANGES 16
#define VMM_MAX_DISKS_PER_VM4
Index: sys/arch/i386/include/vmmvar.h
===
RCS file: /cvs/src/sys/arch/i386/include/vmmvar.h,v
retrieving revision 1.19
diff -u -p -r1.19 vmmvar.h
--- sys/arch/i386/include/vmmvar.h 18 Jan 2019 01:34:50 -
1.19
+++ sys/arch/i386/include/vmmvar.h 27 May 2019 09:44:07 -
@@ -15,3 +15,4 @@
*/
#define VMM_HV_SIGNATURE"OpenBSDVMM58"
+#define KVM_HV_SIGNATURE "KVMKVMKVM\0\0\0"
Index: sys/dev/pv/pvbus.c
===
RCS file: /cvs/src/sys/dev/pv/pvbus.c,v
retrieving revision 1.19
diff -u -p -r1.19 pvbus.c
--- sys/dev/pv/pvbus.c 13 May 2019 15:40:34 -
1.19
+++ sys/dev/pv/pvbus.c 27 May 2019 09:44:08 -
@@ -85,7 +85,7 @@ struct pvbus_type {
void(*init)(struct pvbus_hv *);
void(*print)(struct pvbus_hv *);
} pvbus_types[PVBUS_MAX] = {
- { "KVMKVMKVM\0\0\0", "KVM",pvbus_kvm },
+ { KVM_HV_SIGNATURE, "KVM",pvbus_kvm },
{ "Microsoft Hv", "Hyper-V", pvbus_hyperv,
pvbus_hyperv_print },
{ "VMwareVMware", "VMware" },
{ "XenVMMXenVMM", "Xen", pvbus_xen, pvbus_xen_print
},
--
Renato Aguiar
--
Renato Aguiar
