Re: [patch] switchd(8) on sparc64: panic: trap type 0x34
On Mon, 20 Aug 2018 11:05:08 -0700
Ori Bernstein wrote:
> On Mon, 20 Aug 2018 23:38:28 +0900 (JST), YASUOKA Masahiko
> wrote:
>> As far as I know, switch(4) assumes it receives packets located at 64
>> bit aligned memory. So if the code like below
>>
>> *(uint64_t *)oxm->oxm_value = htobe64(val);
>>
>> cause alignment faults, the assumption may be broken. If so, the
>> place we should fix may not be here.
>
> The reason we are suspicious here is because oxm_value comes from struct
> ofp_ox_match, which is defined like this:
>
> struct ofp_ox_match {
> uint16_toxm_class;
> uint8_t oxm_fh;
> uint8_t oxm_length;
> uint8_t oxm_value[0];
> } __packed;
>
> While the packet may be aligned to 8 bytes, my reading is that the oxm_value
> itself is not at the start of the packet, and is not aligned within the
> ofp_ox_match. I'm not familiar enough with the open flowz to know if
> ofp_ox_match is guaranteed to start at a 4-byte alignment (which would
> push oxm_value out to an 8 byte alignment), but I suspect that's not the
> case.
You are right. I'm sorry. My understanding was wrong.
Overall flow match structures is designed to align to 64-bits, but as
for each fields, there is no such care. So the diff seems ok.
--yasuoka
Re: libtls: tls_config_set_ocsp_staple_file(3) wrong parameter type
Hi Mario, Mario Campos wrote on Mon, Aug 20, 2018 at 07:16:21PM -0500: > This is my first contribution. > If I'm doing something wrong here, please let me know. No, your patch is completely correct (it's likely a copy-paste oversight introduced when adding these functions to the manual page), and sending bugfix patches to tech@ is also OK. I just committed your patch. > I came across this "bug" as I was going through > Bob Beck's libtls tutorial. That's a cool one, right? :-) Thanks, Ingo > Index: lib/libtls/man/tls_load_file.3 > === > RCS file: /cvs/src/lib/libtls/man/tls_load_file.3,v > retrieving revision 1.9 > diff -u -p -u -r1.9 tls_load_file.3 > --- lib/libtls/man/tls_load_file.3 8 Oct 2017 06:56:36 - 1.9 > +++ lib/libtls/man/tls_load_file.3 19 Aug 2018 14:00:42 - > @@ -118,7 +118,7 @@ > .Ft int > .Fo tls_config_set_ocsp_staple_file > .Fa "struct tls_config *config" > -.Fa "const uint8_t *staple_file" > +.Fa "const char *staple_file" > .Fc > .Ft int > .Fo tls_config_set_keypair_file >
libtls: tls_config_set_ocsp_staple_file(3) wrong parameter type
Hi tech@ This is my first contribution. If I'm doing something wrong here, please let me know. I came across this "bug" as I was going through Bob Beck's libtls tutorial. Index: lib/libtls/man/tls_load_file.3 === RCS file: /cvs/src/lib/libtls/man/tls_load_file.3,v retrieving revision 1.9 diff -u -p -u -r1.9 tls_load_file.3 --- lib/libtls/man/tls_load_file.3 8 Oct 2017 06:56:36 - 1.9 +++ lib/libtls/man/tls_load_file.3 19 Aug 2018 14:00:42 - @@ -118,7 +118,7 @@ .Ft int .Fo tls_config_set_ocsp_staple_file .Fa "struct tls_config *config" -.Fa "const uint8_t *staple_file" +.Fa "const char *staple_file" .Fc .Ft int .Fo tls_config_set_keypair_file
openssl s_time: merge duplicate GET & SSL_shutdown code
These two chunks of benchmark() are almost identical. We can merge
them into the end of doConnection() with no change in behavior.
We need to drop a shadow `i' when we do this. While we're at it we
can move retval's declaration to the beginning of the function.
As doConnection is now doing more than connecting I want to rename it
"run_test". I think s_time resembles a benchmark with a single test.
ok?
Index: s_time.c
===
RCS file: /cvs/src/usr.bin/openssl/s_time.c,v
retrieving revision 1.27
diff -u -p -r1.27 s_time.c
--- s_time.c18 Aug 2018 16:51:33 - 1.27
+++ s_time.c20 Aug 2018 23:22:58 -
@@ -90,7 +90,7 @@
extern int verify_depth;
static void s_time_usage(void);
-static int doConnection(SSL *);
+static int run_test(SSL *);
static int benchmark(int);
static SSL_CTX *tm_ctx = NULL;
@@ -343,19 +343,21 @@ s_time_main(int argc, char **argv)
}
/***
- * doConnection - make a connection
+ * run_test - make a connection, get a file, and shut down the connection
+ *
* Args:
* scon= SSL connection
* Returns:
* 1 on success, 0 on error
*/
static int
-doConnection(SSL *scon)
+run_test(SSL *scon)
{
+ char buf[1024 * 8];
struct pollfd pfd[1];
BIO *conn;
long verify_error;
- int i;
+ int i, retval;
if ((conn = BIO_new(BIO_s_connect())) == NULL)
return 0;
@@ -383,6 +385,22 @@ doConnection(SSL *scon)
ERR_print_errors(bio_err);
return 0;
}
+ if (s_time_config.www_path != NULL) {
+ retval = snprintf(buf, sizeof buf,
+ "GET %s HTTP/1.0\r\n\r\n", s_time_config.www_path);
+ if ((size_t)retval >= sizeof buf) {
+ fprintf(stderr, "URL too long\n");
+ return 0;
+ }
+ SSL_write(scon, buf, strlen(buf));
+ while ((i = SSL_read(scon, buf, sizeof(buf))) > 0)
+ bytes_read += i;
+ }
+ if (s_time_config.no_shutdown)
+ SSL_set_shutdown(scon, SSL_SENT_SHUTDOWN |
+ SSL_RECEIVED_SHUTDOWN);
+ else
+ SSL_shutdown(scon);
return 1;
}
@@ -394,32 +412,16 @@ benchmark(int reuse_session)
SSL *scon = NULL;
time_t finishtime;
int ret = 1;
- char buf[1024 * 8];
int ver;
if (reuse_session) {
/* Get an SSL object so we can reuse the session id */
if ((scon = SSL_new(tm_ctx)) == NULL)
goto end;
- if (!doConnection(scon)) {
+ if (!run_test(scon)) {
fprintf(stderr, "Unable to get connection\n");
goto end;
}
- if (s_time_config.www_path != NULL) {
- int retval = snprintf(buf, sizeof buf,
- "GET %s HTTP/1.0\r\n\r\n", s_time_config.www_path);
- if ((size_t)retval >= sizeof buf) {
- fprintf(stderr, "URL too long\n");
- goto end;
- }
- SSL_write(scon, buf, strlen(buf));
- while (SSL_read(scon, buf, sizeof(buf)) > 0);
- }
- if (s_time_config.no_shutdown)
- SSL_set_shutdown(scon, SSL_SENT_SHUTDOWN |
- SSL_RECEIVED_SHUTDOWN);
- else
- SSL_shutdown(scon);
printf("starting\n");
}
@@ -438,26 +440,8 @@ benchmark(int reuse_session)
if ((scon = SSL_new(tm_ctx)) == NULL)
goto end;
}
- if (!doConnection(scon))
+ if (!run_test(scon))
goto end;
-
- if (s_time_config.www_path != NULL) {
- int i, retval = snprintf(buf, sizeof buf,
- "GET %s HTTP/1.0\r\n\r\n", s_time_config.www_path);
- if ((size_t)retval >= sizeof buf) {
- fprintf(stderr, "URL too long\n");
- goto end;
- }
- SSL_write(scon, buf, strlen(buf));
- while ((i = SSL_read(scon, buf, sizeof(buf))) > 0)
- bytes_read += i;
- }
- if (s_time_config.no_shutdown)
- SSL_set_shutdown(scon, SSL_SENT_SHUTDOWN |
- SSL_RECEIVED_SHUTDOWN);
- else
- SSL_shutdown(scon);
-
nConn += 1;
if (SSL_session_reused(scon))
ver =
Re: rasops(9) cursor drawing code
> Date: Mon, 20 Aug 2018 15:46:57 +0200
> From: Frederic Cambus
>
> There is an issue when moving the cursor backwards with the left arrow
> key, characters disappear and only reappear when moving back forward
> with the right arrow key.
>
> I also noticed some similar artefacts when using interactive programs
> with wsmoused enabled.
Ah, I didn't take the scrollback offset into account. Here is a
better diff.
Index: dev/rasops/rasops.c
===
RCS file: /cvs/src/sys/dev/rasops/rasops.c,v
retrieving revision 1.54
diff -u -p -r1.54 rasops.c
--- dev/rasops/rasops.c 3 May 2018 10:05:47 - 1.54
+++ dev/rasops/rasops.c 20 Aug 2018 10:25:15 -
@@ -130,6 +130,22 @@ const u_char rasops_isgray[16] = {
0, 0, 0, 1
};
+struct rasops_screen {
+ LIST_ENTRY(rasops_screen) rs_next;
+ struct rasops_info *rs_ri;
+
+ struct wsdisplay_charcell *rs_bs;
+ int rs_visible;
+ int rs_crow;
+ int rs_ccol;
+ long rs_defattr;
+
+ int rs_sbscreens;
+#define RS_SCROLLBACK_SCREENS 5
+ int rs_dispoffset; /* rs_bs index, start of our actual screen */
+ int rs_visibleoffset; /* rs_bs index, current scrollback screen */
+};
+
/* Generic functions */
intrasops_copycols(void *, int, int, int, int);
intrasops_copyrows(void *, int, int, int);
@@ -179,6 +195,7 @@ int rasops_wronly_copycols(void *, int,
intrasops_wronly_erasecols(void *, int, int, int, long);
intrasops_wronly_copyrows(void *, int, int, int);
intrasops_wronly_eraserows(void *, int, int, long);
+intrasops_wronly_do_cursor(struct rasops_info *);
intrasops_add_font(struct rasops_info *, struct wsdisplay_font *);
intrasops_use_font(struct rasops_info *, struct wsdisplay_font *);
@@ -268,6 +285,7 @@ rasops_init(struct rasops_info *ri, int
return (-1);
ri->ri_active = cookie;
+ ri->ri_bs = ri->ri_active->rs_bs;
ri->ri_ops.cursor = rasops_vcons_cursor;
ri->ri_ops.mapchar = rasops_vcons_mapchar;
@@ -278,6 +296,7 @@ rasops_init(struct rasops_info *ri, int
ri->ri_ops.eraserows = rasops_vcons_eraserows;
ri->ri_ops.alloc_attr = rasops_vcons_alloc_attr;
ri->ri_ops.unpack_attr = rasops_vcons_unpack_attr;
+ ri->ri_do_cursor = rasops_wronly_do_cursor;
} else if ((ri->ri_flg & RI_WRONLY) && ri->ri_bs != NULL) {
long attr;
int i;
@@ -287,6 +306,7 @@ rasops_init(struct rasops_info *ri, int
ri->ri_ops.erasecols = rasops_wronly_erasecols;
ri->ri_ops.copyrows = rasops_wronly_copyrows;
ri->ri_ops.eraserows = rasops_wronly_eraserows;
+ ri->ri_do_cursor = rasops_wronly_do_cursor;
ri->ri_alloc_attr(ri, 0, 0, 0, );
for (i = 0; i < ri->ri_rows * ri->ri_cols; i++) {
@@ -1365,22 +1385,6 @@ slow_bcopy(void *s, void *d, size_t len)
}
#endif /* NRASOPS_BSWAP */
-struct rasops_screen {
- LIST_ENTRY(rasops_screen) rs_next;
- struct rasops_info *rs_ri;
-
- struct wsdisplay_charcell *rs_bs;
- int rs_visible;
- int rs_crow;
- int rs_ccol;
- long rs_defattr;
-
- int rs_sbscreens;
-#define RS_SCROLLBACK_SCREENS 5
- int rs_dispoffset; /* rs_bs index, start of our actual screen */
- int rs_visibleoffset; /* rs_bs index, current scrollback screen */
-};
-
int
rasops_alloc_screen(void *v, void **cookiep,
int *curxp, int *curyp, long *attrp)
@@ -1482,6 +1486,7 @@ rasops_doswitch(void *v)
ri->ri_active->rs_visible = 0;
ri->ri_eraserows(ri, 0, ri->ri_rows, scr->rs_defattr);
ri->ri_active = scr;
+ ri->ri_bs = ri->ri_active->rs_bs;
ri->ri_active->rs_visible = 1;
ri->ri_active->rs_visibleoffset = ri->ri_active->rs_dispoffset;
for (row = 0; row < ri->ri_rows; row++) {
@@ -1767,6 +1772,27 @@ rasops_wronly_eraserows(void *cookie, in
}
return ri->ri_eraserows(ri, row, num, attr);
+}
+
+int
+rasops_wronly_do_cursor(struct rasops_info *ri)
+{
+ int off = ri->ri_crow * ri->ri_cols + ri->ri_ccol;
+ u_int uc;
+ long attr;
+ int fg, bg;
+
+ uc = ri->ri_bs[off].uc;
+ attr = ri->ri_bs[off].attr;
+
+ if ((ri->ri_flg & RI_CURSOR) == 0) {
+ fg = ((u_int)attr >> 24) & 0xf;
+ bg = ((u_int)attr >> 16) & 0xf;
+ attr &= ~0x0;
+ attr |= (fg << 16) | (bg << 24);
+ }
+
+ return ri->ri_putchar(ri, ri->ri_crow, ri->ri_ccol, uc, attr);
}
/*
Re: [patch] switchd(8) on sparc64: panic: trap type 0x34
> Date: Mon, 20 Aug 2018 11:05:08 -0700
> From: Ori Bernstein
>
> > As far as I know, switch(4) assumes it receives packets located at 64
> > bit aligned memory. So if the code like below
> >
> > *(uint64_t *)oxm->oxm_value = htobe64(val);
> >
> > cause alignment faults, the assumption may be broken. If so, the
> > place we should fix may not be here.
>
> The reason we are suspicious here is because oxm_value comes from struct
> ofp_ox_match, which is defined like this:
>
> struct ofp_ox_match {
> uint16_toxm_class;
> uint8_t oxm_fh;
> uint8_t oxm_length;
> uint8_t oxm_value[0];
> } __packed;
This means that unless ofp_ox_match is by some magic aligned on an odd
32-bit boundary, oxm_value is not aligned on a 64-bit boundary. So a cast to
quint64_t * is broken.
Re: [patch] switchd(8) on sparc64: panic: trap type 0x34
On Mon, 20 Aug 2018 23:38:28 +0900 (JST), YASUOKA Masahiko
wrote:
> Hi,
Heyho.
> > panic: trap type 0x34 (mem address not aligned): pc=15864ec
> > npc=15864f0 pstate=99820006
> (snip)
> > o...@eigenstate.org and I put together the following diff. I haven't been
> > able
> > to check with the original reporter, and I don't have a machine to test it
> > on,
> > so comments and/or tests would be appreciated!
>
> Do you have a test case of this?
You're responding to a request for a test case. The initial reporter
disappeared after providing a stack trace, so we couldn't confirm if this
makes a difference at all.
Right now, this is an untested stab in the dark. It would be unsurprising if
the fix is wrong.
> As far as I know, switch(4) assumes it receives packets located at 64
> bit aligned memory. So if the code like below
>
> *(uint64_t *)oxm->oxm_value = htobe64(val);
>
> cause alignment faults, the assumption may be broken. If so, the
> place we should fix may not be here.
The reason we are suspicious here is because oxm_value comes from struct
ofp_ox_match, which is defined like this:
struct ofp_ox_match {
uint16_toxm_class;
uint8_t oxm_fh;
uint8_t oxm_length;
uint8_t oxm_value[0];
} __packed;
While the packet may be aligned to 8 bytes, my reading is that the oxm_value
itself is not at the start of the packet, and is not aligned within the
ofp_ox_match. I'm not familiar enough with the open flowz to know if
ofp_ox_match is guaranteed to start at a 4-byte alignment (which would
push oxm_value out to an 8 byte alignment), but I suspect that's not the
case.
--
Ori Bernstein
Re: [patch] switchd(8) on sparc64: panic: trap type 0x34
Hi, > panic: trap type 0x34 (mem address not aligned): pc=15864ec > npc=15864f0 pstate=99820006 (snip) > o...@eigenstate.org and I put together the following diff. I haven't been able > to check with the original reporter, and I don't have a machine to test it on, > so comments and/or tests would be appreciated! Do you have a test case of this? As far as I know, switch(4) assumes it receives packets located at 64 bit aligned memory. So if the code like below *(uint64_t *)oxm->oxm_value = htobe64(val); cause alignment faults, the assumption may be broken. If so, the place we should fix may not be here. On Sun, 19 Aug 2018 14:28:06 -0700 Ayaka Koshibe wrote: > Hi, > > At BSDCan, someone reported that a sparc64 machine would panic if it was > receiving any traffic on a member interface of a switch(4) during reboot. We > got as far as getting this trace: > > panic: trap type 0x34 (mem address not aligned): pc=15864ec > npc=15864f0 pstate=99820006 > Stopped at db_enter+0x8: nop > TIDPIDUID PRFLAGS PFLAGS CPU COMMAND > 1 86809 00x12 01 ld > 22929608 490x100012 08 switchd > *136438 67954 0 0x14000 0x2003K softnet > trap(404f9b994f0, 34, 15864ec, 99820006, 14, 0) at trap+0x2e0 > Lslowtrap_reenter(4000d9c9b88, 4c, 1, 0, 4000d9c9b70, 0) at > Lslowtrap_reenter+0xf8 > swofp_action_output_controller(4000d135000, 4000d13d100, 4000c2db5e0, , > 0, 3b9ac800) at swofp_action_output_controller+0x1f4 > swofp_action_output(4000d135000, 4000d425400, 4000c2db5e0, 4000cd300a8, > 4000c2db5e0, 6) at swofp_action_output+0x228 > swofp_execute_action(4000d135000, 4000d425400, 4000c2db5e0, 4000cd300a8, 0, > 1c289c0) at swofp_execute_action+0x34 > swofp_apply_actions(4000d135000, 4000d425400, 4000c2db5e0, 4000cd300a0, > 404f9b99ae8, 40079ac8000) at swofp_apply_actions+0x78 > swofp_forward_ofs(4000c2db5e0, 4000d0a0d40, 4000d425400, 0, 404f9b99ae8, > 40079ac8000) at swofp_forward_ofs+0xd8 > switch_process(4000d128000, 4000d425400, 0, 2, 4000d128590, 16c8710) at > switch_process+0x118 > switchintr(1cb5560, 3c4, 20, 0, 0, 6) at switchintr+0x94 > if_netisr(1c00, 404f9b99de0, 1c2ad38, 800, 4000, 2000) at > if_netisr+0x1f0 > taskq_thread(4000cd3c040, 4000cd04000, 17de528, 165f968, 0, 3b9ac800) at > taskq_thread+0x6c > proc_trampoline(0, 0, 0, 0, 0, 0) at proc_trampoline+0x14 > > > o...@eigenstate.org and I put together the following diff. I haven't been able > to check with the original reporter, and I don't have a machine to test it on, > so comments and/or tests would be appreciated! > > > Thanks, > Ayaka > > > Index: switchofp.c > === > RCS file: /cvs/src/sys/net/switchofp.c,v > retrieving revision 1.70 > diff -u -p -u -r1.70 switchofp.c > --- switchofp.c 19 Feb 2018 08:59:52 - 1.70 > +++ switchofp.c 19 Jun 2018 04:14:04 - > @@ -2455,12 +2455,12 @@ swofp_ox_match_put_uint32(struct ofp_mat > int off = ntohs(om->om_length); > struct ofp_ox_match *oxm; > > + val = htonl(val); > oxm = (struct ofp_ox_match *)((caddr_t)om + off); > oxm->oxm_class = htons(OFP_OXM_C_OPENFLOW_BASIC); > OFP_OXM_SET_FIELD(oxm, type); > oxm->oxm_length = sizeof(uint32_t); > - *(uint32_t *)oxm->oxm_value = htonl(val); > - > + memcpy(oxm->oxm_value, , sizeof(val)); > om->om_length = htons(ntohs(om->om_length) + > sizeof(*oxm) + sizeof(uint32_t)); > > @@ -2473,12 +2473,12 @@ swofp_ox_match_put_uint64(struct ofp_mat > struct ofp_ox_match *oxm; > int off = ntohs(om->om_length); > > + val = htobe64(val); > oxm = (struct ofp_ox_match *)((caddr_t)om + off); > oxm->oxm_class = htons(OFP_OXM_C_OPENFLOW_BASIC); > OFP_OXM_SET_FIELD(oxm, type); > oxm->oxm_length = sizeof(uint64_t); > - *(uint64_t *)oxm->oxm_value = htobe64(val); > - > + memcpy(oxm->oxm_value, , sizeof(val)); > om->om_length = htons(ntohs(om->om_length) + > sizeof(*oxm) + sizeof(uint64_t)); > >
Re: rasops(9) cursor drawing code
On Mon, Aug 20, 2018 at 02:05:15PM +0200, Mark Kettenis wrote: > So even when you set the RI_WRONLY or RI_VCONS flag, the rasops code > still does framebuffer reads when it draws the cursor. This causes > problems on a particular (somewhat broken) machine I have. But since > we know that framebuffer reads are quite expensive on other machines, > I think it makes sense to fix this. > > The existing code would xor the cursor position with 0x. This > implementation instead redraws the character at the cursor position > with foreground and background color reversed. That isn't the same > thing, but I think it is a sensible approach and for most cases you > wouldn't be able to tell the difference. There is an issue when moving the cursor backwards with the left arrow key, characters disappear and only reappear when moving back forward with the right arrow key. I also noticed some similar artefacts when using interactive programs with wsmoused enabled.
rasops(9) cursor drawing code
So even when you set the RI_WRONLY or RI_VCONS flag, the rasops code
still does framebuffer reads when it draws the cursor. This causes
problems on a particular (somewhat broken) machine I have. But since
we know that framebuffer reads are quite expensive on other machines,
I think it makes sense to fix this.
The existing code would xor the cursor position with 0x. This
implementation instead redraws the character at the cursor position
with foreground and background color reversed. That isn't the same
thing, but I think it is a sensible approach and for most cases you
wouldn't be able to tell the difference.
ok?
Index: dev/rasops/rasops.c
===
RCS file: /cvs/src/sys/dev/rasops/rasops.c,v
retrieving revision 1.54
diff -u -p -r1.54 rasops.c
--- dev/rasops/rasops.c 3 May 2018 10:05:47 - 1.54
+++ dev/rasops/rasops.c 20 Aug 2018 10:25:15 -
@@ -130,6 +130,22 @@ const u_char rasops_isgray[16] = {
0, 0, 0, 1
};
+struct rasops_screen {
+ LIST_ENTRY(rasops_screen) rs_next;
+ struct rasops_info *rs_ri;
+
+ struct wsdisplay_charcell *rs_bs;
+ int rs_visible;
+ int rs_crow;
+ int rs_ccol;
+ long rs_defattr;
+
+ int rs_sbscreens;
+#define RS_SCROLLBACK_SCREENS 5
+ int rs_dispoffset; /* rs_bs index, start of our actual screen */
+ int rs_visibleoffset; /* rs_bs index, current scrollback screen */
+};
+
/* Generic functions */
intrasops_copycols(void *, int, int, int, int);
intrasops_copyrows(void *, int, int, int);
@@ -179,6 +195,7 @@ int rasops_wronly_copycols(void *, int,
intrasops_wronly_erasecols(void *, int, int, int, long);
intrasops_wronly_copyrows(void *, int, int, int);
intrasops_wronly_eraserows(void *, int, int, long);
+intrasops_wronly_do_cursor(struct rasops_info *);
intrasops_add_font(struct rasops_info *, struct wsdisplay_font *);
intrasops_use_font(struct rasops_info *, struct wsdisplay_font *);
@@ -268,6 +285,7 @@ rasops_init(struct rasops_info *ri, int
return (-1);
ri->ri_active = cookie;
+ ri->ri_bs = ri->ri_active->rs_bs;
ri->ri_ops.cursor = rasops_vcons_cursor;
ri->ri_ops.mapchar = rasops_vcons_mapchar;
@@ -278,6 +296,7 @@ rasops_init(struct rasops_info *ri, int
ri->ri_ops.eraserows = rasops_vcons_eraserows;
ri->ri_ops.alloc_attr = rasops_vcons_alloc_attr;
ri->ri_ops.unpack_attr = rasops_vcons_unpack_attr;
+ ri->ri_do_cursor = rasops_wronly_do_cursor;
} else if ((ri->ri_flg & RI_WRONLY) && ri->ri_bs != NULL) {
long attr;
int i;
@@ -287,6 +306,7 @@ rasops_init(struct rasops_info *ri, int
ri->ri_ops.erasecols = rasops_wronly_erasecols;
ri->ri_ops.copyrows = rasops_wronly_copyrows;
ri->ri_ops.eraserows = rasops_wronly_eraserows;
+ ri->ri_do_cursor = rasops_wronly_do_cursor;
ri->ri_alloc_attr(ri, 0, 0, 0, );
for (i = 0; i < ri->ri_rows * ri->ri_cols; i++) {
@@ -1365,22 +1385,6 @@ slow_bcopy(void *s, void *d, size_t len)
}
#endif /* NRASOPS_BSWAP */
-struct rasops_screen {
- LIST_ENTRY(rasops_screen) rs_next;
- struct rasops_info *rs_ri;
-
- struct wsdisplay_charcell *rs_bs;
- int rs_visible;
- int rs_crow;
- int rs_ccol;
- long rs_defattr;
-
- int rs_sbscreens;
-#define RS_SCROLLBACK_SCREENS 5
- int rs_dispoffset; /* rs_bs index, start of our actual screen */
- int rs_visibleoffset; /* rs_bs index, current scrollback screen */
-};
-
int
rasops_alloc_screen(void *v, void **cookiep,
int *curxp, int *curyp, long *attrp)
@@ -1482,6 +1486,7 @@ rasops_doswitch(void *v)
ri->ri_active->rs_visible = 0;
ri->ri_eraserows(ri, 0, ri->ri_rows, scr->rs_defattr);
ri->ri_active = scr;
+ ri->ri_bs = ri->ri_active->rs_bs;
ri->ri_active->rs_visible = 1;
ri->ri_active->rs_visibleoffset = ri->ri_active->rs_dispoffset;
for (row = 0; row < ri->ri_rows; row++) {
@@ -1767,6 +1772,27 @@ rasops_wronly_eraserows(void *cookie, in
}
return ri->ri_eraserows(ri, row, num, attr);
+}
+
+int
+rasops_wronly_do_cursor(struct rasops_info *ri)
+{
+ int off = ri->ri_crow * ri->ri_cols + ri->ri_ccol;
+ u_int uc;
+ long attr;
+ int fg, bg;
+
+ uc = ri->ri_bs[off].uc;
+ attr = ri->ri_bs[off].attr;
+
+ if ((ri->ri_flg & RI_CURSOR) == 0) {
+ fg = ((u_int)attr >> 24) & 0xf;
+ bg = ((u_int)attr >> 16) & 0xf;
+ attr &= ~0x0;
+ attr |= (fg << 16) | (bg << 24);
+ }
+
+ return ri->ri_putchar(ri, ri->ri_crow, ri->ri_ccol, uc, attr);
}
/*
Re: Using shift on external keyboards in softraid passphrases from efiboot
On Thu, Aug 16, 2018 at 09:51:32PM +0200, Frank Groeneveld wrote: > Hello all, > > I haven't been able to type the passphrase of my softraid device on > boot when using an external keyboard on my Thinkpad X260. Finally I > had some time to debug this problem and this is what I discovered. > > On a different laptop with EFI, the ReadKeyStroke call will not return > a packet when shift is pressed on the external keyboard. On the > Thinkpad however, a packet is returned with UnicodeChar == 0, which > results in a wrong passphrase being used. > > This seems like a bug in the firmware to me, because according to some > EFI specifications I found online, this should not return a packet. > I've attached a simple patch that fixes this, but I'm not sure whether > this might break things on different systems. I can't comment on the technical side of this patch but I can confirm that it allows me to enter the password from an external keyboard with my x280.
urndis(4) ++ RAMDISKs
Hi, these have been missing for some reason, but i'm guessing i wouldn't be the only user using urndis, rather than messing around with firmwares when rushing into reinstall having forgotten about some necessary fw.. (arm64 RAMDISK has urndis(4) already.) -Artturi diff --git sys/arch/amd64/conf/RAMDISK_CD sys/arch/amd64/conf/RAMDISK_CD index 6a50c8dd2d3..2b4d2bd7611 100644 --- sys/arch/amd64/conf/RAMDISK_CD +++ sys/arch/amd64/conf/RAMDISK_CD @@ -109,6 +109,7 @@ cue*at uhub?# CATC USB-EL1201A based Ethernet kue* at uhub?# Kawasaki KL5KUSB101B based Ethernet smsc* at uhub?# SMSC LAN95xx Ethernet cdce* at uhub?# CDC Ethernet +urndis*at uhub?# Remote NDIS Ethernet udav* at uhub?# Davicom DM9601 based Ethernet mos* at uhub?# MOSCHIP MCS7730/7830 10/100 Ethernet mue* at uhub?# Microchip LAN75xx/LAN78xx Ethernet diff --git sys/arch/armv7/conf/RAMDISK sys/arch/armv7/conf/RAMDISK index f1d6c191500..277bf55d011 100644 --- sys/arch/armv7/conf/RAMDISK +++ sys/arch/armv7/conf/RAMDISK @@ -235,6 +235,7 @@ cue*at uhub?# CATC USB-EL1201A based Ethernet kue* at uhub?# Kawasaki KL5KUSB101B based Ethernet smsc* at uhub?# SMSC LAN95xx Ethernet cdce* at uhub?# CDC Ethernet +urndis*at uhub?# Remote NDIS Ethernet udav* at uhub?# Davicom DM9601 based Ethernet mos* at uhub?# MOSCHIP MCS7730/7830 10/100 Ethernet mue* at uhub?# Microchip LAN75xx/LAN78xx Ethernet
[patch] Use API to get params in lib/libtls/tls.c
Hi tech@,
This patch uses API to get params, sorry if I am wrong, thanks!
Index: tls.c
===
RCS file: /cvs/src/lib/libtls/tls.c,v
retrieving revision 1.80
diff -u -p -r1.80 tls.c
--- tls.c 7 Apr 2018 16:30:59 - 1.80
+++ tls.c 20 Aug 2018 10:50:20 -
@@ -437,7 +437,7 @@ tls_configure_ssl(struct tls *ctx, SSL_C
}
if (ctx->config->verify_time == 0) {
- X509_VERIFY_PARAM_set_flags(ssl_ctx->param,
+ X509_VERIFY_PARAM_set_flags(SSL_CTX_get0_param(ssl_ctx),
X509_V_FLAG_NO_CHECK_TIME);
}
@@ -547,7 +547,7 @@ tls_configure_ssl_verify(struct tls *ctx
}
xi->crl = NULL;
}
- X509_VERIFY_PARAM_set_flags(store->param,
+ X509_VERIFY_PARAM_set_flags(X509_STORE_get0_param(store),
X509_V_FLAG_CRL_CHECK | X509_V_FLAG_CRL_CHECK_ALL);
}
--
Best Regards
Nan Xiao
Re: umsm(4) and umb(4) separate loading for the same composite USB modem device
I've done USB descriptors dump for MC7304 with two firmware variants: - modem SWI9X15C_05.05.67.00 - voice enambled SWI9X15C_06.03.32.02 as well as descriptors for EM/MC7455 modem firmware. Denis On 8/15/2018 5:41 PM, Mark Kettenis wrote: >> Date: Wed, 15 Aug 2018 09:56:50 +0100 >> From: Stuart Henderson >> >> On 2018/08/14 18:43, Bryan Vyhmeister wrote: >>> On Tue, Aug 14, 2018 at 05:53:43PM +0300, Denis wrote: Most of modern modems have serial discipline ports and USB Mobile Broadband Interface Model (MBIM) interface in some port compositions simultaneously. It seems very useful to have different disciplines supported by umsm(4) and umb(4) drivers on the same device. >>> Does it possible to have simultaneously operated AT + NMEA ports by umsm(4)driver and MBIM interface by umb(4) driver on the same MC7304 device in 6.3? >>> >>> What is the advantage in having a device attach to both umsm(4) and >>> umb(4)? What are you trying to accomplish? The EM7455 worked perfectly >>> with umb(4) until your previous umsm(4) diff and now it only attaches as >>> umsm(4). Are you wanting to send SMS messages or something like that >>> with your devices? >>> >>> Bryan >>> >> >> Denis has a good point because umsm is needed for GPS and as you >> suggest SMS. >> >> What determines which driver attaches when a device is supported by >> multiple drivers? Perhaps the simplest option without more complex work >> to support different interfaces on different drivers would be to have >> the device attach to umb by default but attach to umsm instead if umb is >> disabled in the kernel. Then at least a standard kernel could be used >> with "disable umb" from boot config. > > The return value from the "match" function determines which driver > attaches. The driver that returns the highest value wins. > > However, matching for USB devices is complicated. Drivers already use > different return values (the UMATCH_* constants). On top of that > drivers can claim a whole device or claim just a particular interface > of a device. This requires some careful though to make sure the right > driver attaches. > > What we really need is a full dump of the usb device descriptors, > preferably in all the different UDUSBCOMP modes. >
move more code under UAUDIO_DEBUG
Hello,
In uaudio_add_mixer() the number of input channels (ichs) is
only used in a DPRINTF statement so the code to set its value
can be excluded unless we're building a debug kernel. In my
understanding uaudio_get_cluster_nchan() has no side effects.
- Michael
Index: uaudio.c
===
RCS file: /cvs/src/sys/dev/usb/uaudio.c,v
retrieving revision 1.132
diff -u -p -u -r1.132 uaudio.c
--- uaudio.c8 Aug 2018 14:25:50 - 1.132
+++ uaudio.c20 Aug 2018 09:16:45 -
@@ -750,17 +750,21 @@ uaudio_add_mixer(struct uaudio_softc *sc
{
const struct usb_audio_mixer_unit *d = iot[id].d.mu;
struct usb_audio_mixer_unit_1 *d1;
- int c, chs, ichs, ochs, i, o, bno, p, mo, mc, k;
+ int c, chs, ochs, i, o, bno, p, mo, mc, k;
+#ifdef UAUDIO_DEBUG
+ int ichs = 0;
+#endif
uByte *bm;
struct mixerctl mix;
DPRINTFN(2,("%s: bUnitId=%d bNrInPins=%d\n", __func__,
d->bUnitId, d->bNrInPins));
+#ifdef UAUDIO_DEBUG
/* Compute the number of input channels */
- ichs = 0;
for (i = 0; i < d->bNrInPins; i++)
ichs += uaudio_get_cluster_nchan(d->baSourceId[i], iot);
+#endif
/* and the number of output channels */
d1 = (struct usb_audio_mixer_unit_1 *)>baSourceId[d->bNrInPins];
Re: [PATCH] qcow2 disk format
On Sun, 12 Aug 2018 22:51:24 -0700, Ori Bernstein wrote:
>
This patch adds preliminary support for creating qcow2 disk images. It gives
the 'vmctl create' command an option '-f', which can be given arguments of
either 'raw' (defualt) or 'qcow2', and it creates a disk of the appropriate
format.
The qcow2 header is duplicated inline, since it seemed better than the other
options (putting it into a header and messing around with include/source paths
so
that we could share it with vmd, or creating a libqcow2)
That decision may get revisited when I find time to implement snapshotting,
since creating a snapshot will involve relatively deep modifications to the
disk (adjusting refcounts, rewriting L1/L2 tables, etc).
---
usr.sbin/vmctl/main.c | 18 +--
usr.sbin/vmctl/vmctl.8 | 7 ++-
usr.sbin/vmctl/vmctl.c | 124 -
usr.sbin/vmctl/vmctl.h | 3 +-
4 files changed, 143 insertions(+), 9 deletions(-)
diff --git usr.sbin/vmctl/main.c usr.sbin/vmctl/main.c
index b7674d0c980..f39ccbdbc1f 100644
--- usr.sbin/vmctl/main.c
+++ usr.sbin/vmctl/main.c
@@ -63,7 +63,8 @@ intctl_receive(struct parse_result *, int, char
*[]);
struct ctl_command ctl_commands[] = {
{ "console",CMD_CONSOLE,ctl_console,"id" },
- { "create", CMD_CREATE, ctl_create, "\"path\" -s size", 1 },
+ { "create", CMD_CREATE, ctl_create,
+ "\"path\" -s size [-f fmt]", 1 },
{ "load", CMD_LOAD, ctl_load, "\"path\"" },
{ "log",CMD_LOG,ctl_log,"(verbose|brief)" },
{ "reload", CMD_RELOAD, ctl_reload, "" },
@@ -470,24 +471,28 @@ int
ctl_create(struct parse_result *res, int argc, char *argv[])
{
int ch, ret;
- const char *paths[2];
+ const char *paths[2], *format;
if (argc < 2)
ctl_usage(res->ctl);
paths[0] = argv[1];
paths[1] = NULL;
+ format = "raw";
if (pledge("stdio rpath wpath cpath", NULL) == -1)
err(1, "pledge");
argc--;
argv++;
- while ((ch = getopt(argc, argv, "s:")) != -1) {
+ while ((ch = getopt(argc, argv, "s:f:")) != -1) {
switch (ch) {
case 's':
if (parse_size(res, optarg, 0) != 0)
errx(1, "invalid size: %s", optarg);
break;
+ case 'f':
+ format = optarg;
+ break;
default:
ctl_usage(res->ctl);
/* NOTREACHED */
@@ -498,7 +503,12 @@ ctl_create(struct parse_result *res, int argc, char
*argv[])
fprintf(stderr, "missing size argument\n");
ctl_usage(res->ctl);
}
- ret = create_imagefile(paths[0], res->size);
+ if (strcmp(format, "raw") == 0)
+ ret = create_raw_imagefile(paths[0], res->size);
+ else if (strcmp(format, "qcow2") == 0)
+ ret = create_qc2_imagefile(paths[0], res->size);
+ else
+ errx(1, "unknown image format %s", format);
if (ret != 0) {
errno = ret;
err(1, "create imagefile operation failed");
diff --git usr.sbin/vmctl/vmctl.8 usr.sbin/vmctl/vmctl.8
index 81ecbeb6c1d..358928c7ff6 100644
--- usr.sbin/vmctl/vmctl.8
+++ usr.sbin/vmctl/vmctl.8
@@ -50,12 +50,15 @@ Using
.Xr cu 1
connect to the console of the VM with the specified
.Ar id .
-.It Cm create Ar path Fl s Ar size
+.It Cm create Ar path Fl s Ar size Op Fl f Ar format
Creates a VM disk image file with the specified
.Ar path
and
.Ar size ,
-rounded to megabytes.
+rounded to megabytes. The disk
+.Ar format
+may be specified as either 'raw' or 'qcow2', defaulting to 'raw'
+if left unspecified.
.It Cm load Ar filename
Load additional configuration from the specified file.
.It Cm log brief
diff --git usr.sbin/vmctl/vmctl.c usr.sbin/vmctl/vmctl.c
index 7ab9a9bc60c..b3a4e6d7b14 100644
--- usr.sbin/vmctl/vmctl.c
+++ usr.sbin/vmctl/vmctl.c
@@ -735,7 +735,7 @@ vm_console(struct vmop_info_result *list, size_t ct)
}
/*
- * create_imagefile
+ * create_raw_imagefile
*
* Create an empty imagefile with the specified path and size.
*
@@ -749,7 +749,7 @@ vm_console(struct vmop_info_result *list, size_t ct)
* E : Various other E errno codes due to other I/O errors
*/
int
-create_imagefile(const char *imgfile_path, long imgsize)
+create_raw_imagefile(const char *imgfile_path, long imgsize)
{
int fd, ret;
@@ -770,3 +770,123 @@ create_imagefile(const char *imgfile_path, long imgsize)
ret = close(fd);
return (ret);
}
+
+/*
+ * create_imagefile
+ *
+ * Create an empty qcow2 imagefile with the specified path and size.
+ *
+ * Parameters:
+ * imgfile_path: path to the image file to create
+ * imgsize :
Re: [PATCH] qcow2 disk format
On Sun, 12 Aug 2018 22:51:24 -0700, Ori Bernstein wrote:
> On Sun, 5 Aug 2018 00:52:32 -0700, Ori Bernstein wrote:
>
> And, now something that actually appears to work. You can create a
> disk on OpenBSD using qemu:
>
> qemu-img create foo.qc2 16G
>
> add it to your vm.conf:
>
> disk "/path/to/foo.qc2"
>
> boot and install OpenBSD on it as normal, and if you decide you don't like
> hardware virtualization, you can point qemu at it and run using that:
>
> qemu-system-x86_64 -m 1024 -hda foo.qc2
>
> Snapshots haven't been tested yet, and tools need to be added, incompatible
> extensions are silently ignored, and there could stand to be a bit more sanity
> checking.
>
> vioscribble.c should also probably be extracted into a regress test, rather
> than just something that sits beside the I/O code.
>
> Patch below:
One more update, with some significant differences:
- External snapshots will work if you comment out the chroot and add rpath
to the pledges. This is a bad idea, so external snapshots will return a
clean error until I can figure out a good way to plumb the fds, shuffle
around the pledges, or do something else to make it possible to open the
backing files from the vm process.
- Internal snapshots seem to work, but you will need qemu to manage them.
qemu-img snapshot -c snapname disk.qc2 # create
qemu-img snapshot -a snapname disk.qc2 # revert
These have only been tested lightly, so I wouldn't trust them fully yet.
- vioscribble has been turned into a regress test, and grew license
information.
- A somewhat embarrassing bug, where I malloced the wrong type, was fixed.
---
regress/usr.sbin/vmd/diskfmt/Makefile | 28 ++
regress/usr.sbin/vmd/diskfmt/vioscribble.c | 165 +
usr.sbin/vmd/Makefile | 2 +-
usr.sbin/vmd/vioqcow2.c| 574 +
usr.sbin/vmd/virtio.c | 10 +-
usr.sbin/vmd/virtio.h | 1 +
6 files changed, 776 insertions(+), 4 deletions(-)
create mode 100644 regress/usr.sbin/vmd/diskfmt/Makefile
create mode 100644 regress/usr.sbin/vmd/diskfmt/vioscribble.c
create mode 100644 usr.sbin/vmd/vioqcow2.c
diff --git regress/usr.sbin/vmd/diskfmt/Makefile
regress/usr.sbin/vmd/diskfmt/Makefile
new file mode 100644
index 000..71bb2b8ce52
--- /dev/null
+++ regress/usr.sbin/vmd/diskfmt/Makefile
@@ -0,0 +1,28 @@
+# $OpenBSD: Makefile,v 1.5 2018/07/20 22:18:49 bluhm Exp $
+
+# This regression test creates a raw disk image and a
+# qcow disk image, and scribbles the same data to both
+# of them. It verifies that they both have the same
+# result.
+#
+# In order for this test to work, qemu must be installed
+# in order to create the disk images.
+
+VMD_DIR=$(BSDSRCDIR)/usr.sbin/vmd/
+
+PROG=vioscribble
+SRCS=vioscribble.c $(VMD_DIR)/vioqcow2.c $(VMD_DIR)/vioraw.c
+CFLAGS+=-I$(VMD_DIR) -pthread
+LDFLAGS+=-pthread
+
+run-regress-vioscribble: scribble-images
+
+scribble-images:
+ rm -f scribble.raw scribble.qc2
+ vmctl create scribble.raw -s 4G
+ qemu-img create -f qcow2 scribble.qc2 4G
+
+
+.PHONY: ${REGRESS_TARGETS} scribble-images
+
+.include
diff --git regress/usr.sbin/vmd/diskfmt/vioscribble.c
regress/usr.sbin/vmd/diskfmt/vioscribble.c
new file mode 100644
index 000..3821c3b277b
--- /dev/null
+++ regress/usr.sbin/vmd/diskfmt/vioscribble.c
@@ -0,0 +1,165 @@
+/* $OpenBSD: $ */
+
+/*
+ * Copyright (c) 2018 Ori Bernstein
+ *
+ * Permission to use, copy, modify, and distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+/*
+ * Quick hack of a program to try to test vioqcow2.c against
+ * vioraw.c.
+ *
+ * Compile with:
+ *
+ * cc -pthread -o scribble vioscribble.c vioqcow2.c vioraw.c
+ */
+#include /* PAGE_SIZE */
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "pci.h"
+#include "vmd.h"
+#include "vmm.h"
+#include "virtio.h"
+
+#define CLUSTERSZ 65536
+
+int verbose;
+struct virtio_backing qcowfile;
+struct virtio_backing rawfile;
+
+/* We expect the scribble disks to be 4g in size */
+#define
Re: [PATCH] Pluggable disk formats for vmd (qcow2 preparation)
One more minor update to this patch:
- Remove unused enum
- Remove unused function prototype
- Move some qcow2-specific headers into the qcow2 patch.
---
usr.sbin/vmd/Makefile | 2 +-
usr.sbin/vmd/vioraw.c | 73 ++
usr.sbin/vmd/vioscsi.c | 7 +++--
usr.sbin/vmd/virtio.c | 55 -
usr.sbin/vmd/virtio.h | 17 +---
5 files changed, 124 insertions(+), 30 deletions(-)
create mode 100644 usr.sbin/vmd/vioraw.c
diff --git usr.sbin/vmd/Makefile usr.sbin/vmd/Makefile
index 7ea090f8886..24c1d1b1d4a 100644
--- usr.sbin/vmd/Makefile
+++ usr.sbin/vmd/Makefile
@@ -6,7 +6,7 @@ PROG= vmd
SRCS= vmd.c control.c log.c priv.c proc.c config.c vmm.c
SRCS+= vm.c loadfile_elf.c pci.c virtio.c i8259.c mc146818.c
SRCS+= ns8250.c i8253.c vmboot.c ufs.c disklabel.c dhcp.c packet.c
-SRCS+= parse.y atomicio.c vioscsi.c
+SRCS+= parse.y atomicio.c vioscsi.c vioraw.c
CFLAGS+= -Wall -I${.CURDIR}
CFLAGS+= -Wstrict-prototypes -Wmissing-prototypes
diff --git usr.sbin/vmd/vioraw.c usr.sbin/vmd/vioraw.c
new file mode 100644
index 000..d377546de67
--- /dev/null
+++ usr.sbin/vmd/vioraw.c
@@ -0,0 +1,73 @@
+/* $OpenBSD: $ */
+/*
+ * Copyright (c) 2018 Ori Bernstein
+ *
+ * Permission to use, copy, modify, and distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+#include
+
+#include
+#include
+
+#include
+#include
+
+#include "vmd.h"
+#include "vmm.h"
+#include "virtio.h"
+
+static ssize_t
+raw_pread(void *file, char *buf, size_t len, off_t off)
+{
+ return pread(*(int *)file, buf, len, off);
+}
+
+static ssize_t
+raw_pwrite(void *file, char *buf, size_t len, off_t off)
+{
+ return pwrite(*(int *)file, buf, len, off);
+}
+
+static void
+raw_close(void *file)
+{
+ close(*(int *)file);
+ free(file);
+}
+
+/*
+ * Initializes a raw disk image backing file from an fd.
+ * Stores the number of 512 byte sectors in *szp,
+ * returning -1 for error, 0 for success.
+ */
+int
+virtio_init_raw(struct virtio_backing *file, off_t *szp, int fd)
+{
+ off_t sz;
+ int *fdp;
+
+ sz = lseek(fd, 0, SEEK_END);
+ if (sz == -1)
+ return -1;
+
+ fdp = malloc(sizeof(int));
+ *fdp = fd;
+ file->p = fdp;
+ file->pread = raw_pread;
+ file->pwrite = raw_pwrite;
+ file->close = raw_close;
+ *szp = sz / 512;
+ return 0;
+}
+
diff --git usr.sbin/vmd/vioscsi.c usr.sbin/vmd/vioscsi.c
index 93867887598..af504f0550d 100644
--- usr.sbin/vmd/vioscsi.c
+++ usr.sbin/vmd/vioscsi.c
@@ -197,7 +197,7 @@ vioscsi_start_read(struct vioscsi_dev *dev, off_t block,
ssize_t n_blocks)
goto nomem;
info->len = n_blocks * VIOSCSI_BLOCK_SIZE_CDROM;
info->offset = block * VIOSCSI_BLOCK_SIZE_CDROM;
- info->fd = dev->fd;
+ info->file = >file;
return info;
@@ -210,7 +210,10 @@ nomem:
static const uint8_t *
vioscsi_finish_read(struct ioinfo *info)
{
- if (pread(info->fd, info->buf, info->len, info->offset) != info->len) {
+ struct virtio_backing *f;
+
+ f = info->file;
+ if (f->pread(f->p, info->buf, info->len, info->offset) != info->len) {
info->error = errno;
log_warn("vioscsi read error");
return NULL;
diff --git usr.sbin/vmd/virtio.c usr.sbin/vmd/virtio.c
index 4622ef4943f..099f1df6a7e 100644
--- usr.sbin/vmd/virtio.c
+++ usr.sbin/vmd/virtio.c
@@ -361,7 +361,7 @@ vioblk_start_read(struct vioblk_dev *dev, off_t sector,
ssize_t sz)
goto nomem;
info->len = sz;
info->offset = sector * VIRTIO_BLK_SECTOR_SIZE;
- info->fd = dev->fd;
+ info->file = >file;
return info;
@@ -375,7 +375,10 @@ nomem:
static const uint8_t *
vioblk_finish_read(struct ioinfo *info)
{
- if (pread(info->fd, info->buf, info->len, info->offset) != info->len) {
+ struct virtio_backing *file;
+
+ file = info->file;
+ if (file->pread(file->p, info->buf, info->len, info->offset) !=
info->len) {
info->error = errno;
log_warn("vioblk read error");
return NULL;
@@ -398,7 +401,7 @@ vioblk_start_write(struct vioblk_dev *dev, off_t
Re: radeondrm(4) fix
> Date: Mon, 20 Aug 2018 11:43:31 +1000
> From: Jonathan Gray
>
> On Sun, Aug 19, 2018 at 07:38:44PM +0200, Mark Kettenis wrote:
> > If memory is supposed to be cached, we should make it so. Matches
> > what the Linux version of this code does.
> >
> > ok?
>
> Sure, I had something similiar in a tree here.
> Could you keep the comment in the original code as well?
Can you just commit your version?
> Index: ttm_bo_util.c
> ===
> RCS file: /cvs/src/sys/dev/pci/drm/ttm/ttm_bo_util.c,v
> retrieving revision 1.19
> diff -u -p -r1.19 ttm_bo_util.c
> --- ttm_bo_util.c 25 Apr 2018 01:27:46 - 1.19
> +++ ttm_bo_util.c 20 Aug 2018 01:32:45 -
> @@ -514,6 +514,9 @@ EXPORT_SYMBOL(ttm_io_prot);
>
> pgprot_t ttm_io_prot(uint32_t caching_flags, pgprot_t tmp)
> {
> + /* Cached mappings need no adjustment */
> + if (caching_flags & TTM_PL_FLAG_CACHED)
> + return tmp;
> #ifdef PMAP_WC
> if (caching_flags & TTM_PL_FLAG_WC)
> return PMAP_WC;
>
