Re: svn commit: r345726 - head/sys/dev/xen/blkfront

2020-06-18 Thread Roger Pau Monné
On Sat, Mar 30, 2019 at 07:20:28AM +, Pawel Jakub Dawidek wrote:
> Author: pjd
> Date: Sat Mar 30 07:20:28 2019
> New Revision: 345726
> URL: https://svnweb.freebsd.org/changeset/base/345726
> 
> Log:
>   Implement support for online disk capacity changes.
>   
>   Obtained from:  Fudo Security
>   Tested in:  AWS

This breaks on i386 because the size of sectors is not wide enough and
the calculation of d_mediasize is truncated. The fix is in r361579.

Roger.
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r361580 - head/sys/dev/xen/control

2020-05-28 Thread Roger Pau Monné
Author: royger
Date: Thu May 28 08:20:16 2020
New Revision: 361580
URL: https://svnweb.freebsd.org/changeset/base/361580

Log:
  xen/control: short circuit xctrl_on_watch_event on spurious event
  
  If there's no data to read from xenstore short-circuit
  xctrl_on_watch_event to return early, there's no reason to continue
  since the lack of data would prevent matching against any known event
  type.
  
  Sponsored by: Citrix Systems R
  MFC with: r352925
  MFC after:1 week

Modified:
  head/sys/dev/xen/control/control.c

Modified: head/sys/dev/xen/control/control.c
==
--- head/sys/dev/xen/control/control.c  Thu May 28 08:19:13 2020
(r361579)
+++ head/sys/dev/xen/control/control.c  Thu May 28 08:20:16 2020
(r361580)
@@ -360,7 +360,7 @@ xctrl_on_watch_event(struct xs_watch *watch, const cha

error = xs_read(XST_NIL, "control", "shutdown",
_len, (void **));
-   if (error != 0)
+   if (error != 0 || result_len == 0)
return;
 
/* Acknowledge the request by writing back an empty string. */
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r361579 - head/sys/dev/xen/blkfront

2020-05-28 Thread Roger Pau Monné
Author: royger
Date: Thu May 28 08:19:13 2020
New Revision: 361579
URL: https://svnweb.freebsd.org/changeset/base/361579

Log:
  xen/blkfront: use the correct type for disk sectors
  
  The correct type to use to represent disk sectors is blkif_sector_t
  (which is an uint64_t underneath). This avoid truncation of the disk
  size calculation when resizing on i386, as otherwise the calculation
  of d_mediasize in xbd_connect is truncated to the size of unsigned
  long, which is 32bits on i386.
  
  Note this issue didn't affect amd64, because the size of unsigned long
  is 64bits there.
  
  Sponsored by: Citrix Systems R
  MFC after:1 week

Modified:
  head/sys/dev/xen/blkfront/blkfront.c

Modified: head/sys/dev/xen/blkfront/blkfront.c
==
--- head/sys/dev/xen/blkfront/blkfront.cThu May 28 08:18:34 2020
(r361578)
+++ head/sys/dev/xen/blkfront/blkfront.cThu May 28 08:19:13 2020
(r361579)
@@ -1225,7 +1225,8 @@ static void 
 xbd_connect(struct xbd_softc *sc)
 {
device_t dev = sc->xbd_dev;
-   unsigned long sectors, sector_size, phys_sector_size;
+   blkif_sector_t sectors;
+   unsigned long sector_size, phys_sector_size;
unsigned int binfo;
int err, feature_barrier, feature_flush;
int i, j;
@@ -1244,7 +1245,7 @@ xbd_connect(struct xbd_softc *sc)
return;
}
err = xs_gather(XST_NIL, xenbus_get_otherend_path(dev),
-   "sectors", "%lu", , NULL);
+   "sectors", "%"PRIu64, , NULL);
if (err != 0) {
xenbus_dev_error(dev, err,
"reading sectors at %s",
@@ -1266,7 +1267,7 @@ xbd_connect(struct xbd_softc *sc)
}
 
err = xs_gather(XST_NIL, xenbus_get_otherend_path(dev),
-   "sectors", "%lu", ,
+   "sectors", "%"PRIu64, ,
"info", "%u", ,
"sector-size", "%lu", _size,
NULL);
@@ -1279,7 +1280,7 @@ xbd_connect(struct xbd_softc *sc)
if ((sectors == 0) || (sector_size == 0)) {
xenbus_dev_fatal(dev, 0,
"invalid parameters from %s:"
-   " sectors = %lu, sector_size = %lu",
+   " sectors = %"PRIu64", sector_size = %lu",
xenbus_get_otherend_path(dev),
sectors, sector_size);
return;
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r361578 - head/sys/x86/xen

2020-05-28 Thread Roger Pau Monné
Author: royger
Date: Thu May 28 08:18:34 2020
New Revision: 361578
URL: https://svnweb.freebsd.org/changeset/base/361578

Log:
  xenpv: do not use low 1MB for Xen mappings on i386
  
  On amd64 we already avoid using memory below 4GB in order to prevent
  clashes with MMIO regions, but i386 was allowed to use any hole in
  the physical memory map in order to map Xen pages.
  
  Limit this to memory above the 1MB boundary on i386 in order to avoid
  clashes with the MMIO holes in that area.
  
  Sponsored by: Citrix Systems R
  MFC after:1 week

Modified:
  head/sys/x86/xen/xenpv.c

Modified: head/sys/x86/xen/xenpv.c
==
--- head/sys/x86/xen/xenpv.cThu May 28 08:05:46 2020(r361577)
+++ head/sys/x86/xen/xenpv.cThu May 28 08:18:34 2020(r361578)
@@ -54,12 +54,14 @@ __FBSDID("$FreeBSD$");
  * prevent clashes with MMIO/ACPI regions.
  *
  * Since this is not possible on i386 just use any available memory
- * chunk and hope we don't clash with anything else.
+ * chunk above 1MB and hope we don't clash with anything else.
  */
 #ifdef __amd64__
 #define LOW_MEM_LIMIT  0x1ul
+#elif defined(__i386__)
+#define LOW_MEM_LIMIT  0x10ul
 #else
-#define LOW_MEM_LIMIT  0
+#error "Unsupported architecture"
 #endif
 
 static devclass_t xenpv_devclass;
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r361500 - head/sys/amd64/amd64

2020-05-26 Thread Roger Pau Monné
Author: royger
Date: Tue May 26 10:24:06 2020
New Revision: 361500
URL: https://svnweb.freebsd.org/changeset/base/361500

Log:
  xen-locore: fix size in GDT descriptor
  
  There was an off-by-one in the GDT descriptor size field used by the
  early Xen boot code. The GDT descriptor size should be the size of the
  GDT minus one. No functional change expected as a result of this
  change.
  
  Sponsored by: Citrix Systems R

Modified:
  head/sys/amd64/amd64/xen-locore.S

Modified: head/sys/amd64/amd64/xen-locore.S
==
--- head/sys/amd64/amd64/xen-locore.S   Tue May 26 08:25:24 2020
(r361499)
+++ head/sys/amd64/amd64/xen-locore.S   Tue May 26 10:24:06 2020
(r361500)
@@ -207,7 +207,7 @@ PT2:
 
 /* 64bit GDT */
 gdtdesc:
-   .word   gdtend - gdt
+   .word   gdtend - gdt - 1
.long   VTOP(gdt)   # low
.long   0   # high
 gdt:
@@ -221,7 +221,7 @@ gdtend:
 
 /* 32bit GDT */
 gdtdesc32:
-   .word   gdt32end - gdt32
+   .word   gdt32end - gdt32 - 1
.long   VTOP(gdt32)
.long   0
 gdt32:
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r361274 - head/sys/dev/xen/evtchn

2020-05-20 Thread Roger Pau Monné
Author: royger
Date: Wed May 20 11:01:10 2020
New Revision: 361274
URL: https://svnweb.freebsd.org/changeset/base/361274

Log:
  dev/xenstore: fix return with locks held
  
  Fix returning from xenstore device with locks held, which triggers the
  following panic:
  
  # cat /dev/xen/xenstore
  ^C
  userret: returning with the following locks held:
  exclusive sx evtchn_ringc_sx (evtchn_ringc_sx) r = 0 (0xf8000650be40) 
locked @ /usr/src/sys/dev/xen/evtchn/evtchn_dev.c:262
  
  Note this is not a security issue since access to the device is
  limited to root by default.
  
  Sponsored by: Citrix Systems R
  MFC after:1 week

Modified:
  head/sys/dev/xen/evtchn/evtchn_dev.c

Modified: head/sys/dev/xen/evtchn/evtchn_dev.c
==
--- head/sys/dev/xen/evtchn/evtchn_dev.cWed May 20 08:15:09 2020
(r361273)
+++ head/sys/dev/xen/evtchn/evtchn_dev.cWed May 20 11:01:10 2020
(r361274)
@@ -261,9 +261,10 @@ evtchn_read(struct cdev *dev, struct uio *uio, int iof
 
sx_xlock(>ring_cons_mutex);
for (;;) {
-   error = EFBIG;
-   if (u->ring_overflow)
+   if (u->ring_overflow) {
+   error = EFBIG;
goto unlock_out;
+   }
 
c = u->ring_cons;
p = u->ring_prod;
@@ -271,13 +272,13 @@ evtchn_read(struct cdev *dev, struct uio *uio, int iof
break;
 
if (ioflag & IO_NDELAY) {
-   sx_xunlock(>ring_cons_mutex);
-   return (EWOULDBLOCK);
+   error = EWOULDBLOCK;
+   goto unlock_out;
}
 
error = sx_sleep(u, >ring_cons_mutex, PCATCH, "evtchw", 0);
if ((error != 0) && (error != EWOULDBLOCK))
-   return (error);
+   goto unlock_out;
}
 
/* Byte lengths of two chunks. Chunk split (if any) is at ring wrap. */
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r357616 - head/sys/dev/xen/console

2020-02-06 Thread Roger Pau Monné
Author: royger
Date: Thu Feb  6 14:02:47 2020
New Revision: 357616
URL: https://svnweb.freebsd.org/changeset/base/357616

Log:
  xen/console: fix priority of Xen console
  
  Currently the Xen console is always attached with priority CN_REMOTE
  (highest), which means that when booting with a single console the Xen
  console will take preference over the VGA for example, and that's not
  intended unless the user has also selected to use a serial console.
  
  Fix this by lowering the priority of the Xen console to NORMAL unless
  the user has selected to use a serial console. This keeps the usual
  FreeBSD behavior of outputting to the internal consoles (ie: VGA) when
  booted as a Xen dom0.
  
  MFC after:3 days
  Sponsored by: Citrix Systems R

Modified:
  head/sys/dev/xen/console/xen_console.c

Modified: head/sys/dev/xen/console/xen_console.c
==
--- head/sys/dev/xen/console/xen_console.c  Thu Feb  6 13:21:59 2020
(r357615)
+++ head/sys/dev/xen/console/xen_console.c  Thu Feb  6 14:02:47 2020
(r357616)
@@ -44,6 +44,7 @@ __FBSDID("$FreeBSD$");
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -590,7 +591,7 @@ xencons_cnprobe(struct consdev *cp)
if (!xen_domain())
return;
 
-   cp->cn_pri = CN_REMOTE;
+   cp->cn_pri = (boothowto & RB_SERIAL) ? CN_REMOTE : CN_NORMAL;
sprintf(cp->cn_name, "%s0", driver_name);
 }
 
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r354637 - head/sys/x86/xen

2019-11-12 Thread Roger Pau Monné
Author: royger
Date: Tue Nov 12 10:31:28 2019
New Revision: 354637
URL: https://svnweb.freebsd.org/changeset/base/354637

Log:
  xen: fix dispatching of NMIs
  
  Currently NMIs are sent over event channels, but that defeats the
  purpose of NMIs since event channels can be masked. Fix this by
  issuing NMIs using a hypercall, which injects a NMI (vector #2) to the
  desired vCPU.
  
  Note that NMIs could also be triggered using the emulated local APIC,
  but using a hypercall is better from a performance point of view
  since it doesn't involve instruction decoding when not using x2APIC
  mode.
  
  Reported and Tested by:   avg
  Sponsored by: Citrix Systems R

Modified:
  head/sys/x86/xen/xen_apic.c

Modified: head/sys/x86/xen/xen_apic.c
==
--- head/sys/x86/xen/xen_apic.c Tue Nov 12 10:22:48 2019(r354636)
+++ head/sys/x86/xen/xen_apic.c Tue Nov 12 10:31:28 2019(r354637)
@@ -72,7 +72,6 @@ static driver_filter_t xen_invlcache;
 static driver_filter_t xen_ipi_bitmap_handler;
 static driver_filter_t xen_cpustop_handler;
 static driver_filter_t xen_cpususpend_handler;
-static driver_filter_t xen_cpustophard_handler;
 #endif
 
 /*-- Macros 
--*/
@@ -96,7 +95,6 @@ static struct xen_ipi_handler xen_ipis[] = 
[IPI_TO_IDX(IPI_BITMAP_VECTOR)] = { xen_ipi_bitmap_handler, "b"   },
[IPI_TO_IDX(IPI_STOP)]  = { xen_cpustop_handler,"st"  },
[IPI_TO_IDX(IPI_SUSPEND)]   = { xen_cpususpend_handler, "sp"  },
-   [IPI_TO_IDX(IPI_STOP_HARD)] = { xen_cpustophard_handler,"sth" },
 };
 #endif
 
@@ -259,12 +257,52 @@ xen_pv_lapic_ipi_raw(register_t icrlo, u_int dest)
XEN_APIC_UNSUPPORTED;
 }
 
+#define PCPU_ID_GET(id, field) (pcpu_find(id)->pc_##field)
 static void
+send_nmi(int dest)
+{
+   unsigned int cpu;
+
+   /*
+* NMIs are not routed over event channels, and instead delivered as on
+* native using the exception vector (#2). Triggering them can be done
+* using the local APIC, or an hypercall as a shortcut like it's done
+* below.
+*/
+   switch(dest) {
+   case APIC_IPI_DEST_SELF:
+   HYPERVISOR_vcpu_op(VCPUOP_send_nmi, PCPU_GET(vcpu_id), NULL);
+   break;
+   case APIC_IPI_DEST_ALL:
+   CPU_FOREACH(cpu)
+   HYPERVISOR_vcpu_op(VCPUOP_send_nmi,
+   PCPU_ID_GET(cpu, vcpu_id), NULL);
+   break;
+   case APIC_IPI_DEST_OTHERS:
+   CPU_FOREACH(cpu)
+   if (cpu != PCPU_GET(cpuid))
+   HYPERVISOR_vcpu_op(VCPUOP_send_nmi,
+   PCPU_ID_GET(cpu, vcpu_id), NULL);
+   break;
+   default:
+   HYPERVISOR_vcpu_op(VCPUOP_send_nmi,
+   PCPU_ID_GET(apic_cpuid(dest), vcpu_id), NULL);
+   break;
+   }
+}
+#undef PCPU_ID_GET
+
+static void
 xen_pv_lapic_ipi_vectored(u_int vector, int dest)
 {
xen_intr_handle_t *ipi_handle;
int ipi_idx, to_cpu, self;
 
+   if (vector >= IPI_NMI_FIRST) {
+   send_nmi(dest);
+   return;
+   }
+
ipi_idx = IPI_TO_IDX(vector);
if (ipi_idx >= nitems(xen_ipis))
panic("IPI out of range");
@@ -519,14 +557,6 @@ xen_cpususpend_handler(void *arg)
 {
 
cpususpend_handler();
-   return (FILTER_HANDLED);
-}
-
-static int
-xen_cpustophard_handler(void *arg)
-{
-
-   ipi_nmi_handler();
return (FILTER_HANDLED);
 }
 
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r352925 - head/sys/dev/xen/control

2019-10-02 Thread Roger Pau Monné
On Tue, Oct 01, 2019 at 06:42:14PM -0700, Ravi Pokala wrote:
> Hi Roger,
> 
> If I'm understanding this diff correctly, all of (poweroff, reboot, suspend) 
> will use the common string "shutdown", rather than an event-specific string. 
> Is that what we want?

I think there's some misunderstanding here. All power control events
use the same xenstore node (~/control/shutdown), but the command read
from it is different depending on the requested action (poweroff,
reboot, halt...).

See [0] for a slightly more detailed description of the xenstore node.

Note that this commit doesn't change any of this logic, it just clears
the contents of ~/control/shutdown (by writing "") so the toolstack
knows FreeBSD has acknowledged the request and it's processing it.

Roger.

[0] 
http://xenbits.xen.org/docs/4.12-testing/misc/xenstore-paths.html#platform-feature-and-control-paths
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r352925 - head/sys/dev/xen/control

2019-10-01 Thread Roger Pau Monné
Author: royger
Date: Tue Oct  1 08:21:41 2019
New Revision: 352925
URL: https://svnweb.freebsd.org/changeset/base/352925

Log:
  xen/ctrl: acknowledge all control requests
  
  Currently only suspend requests are acknowledged by writing an empty
  string back to the xenstore control node, but poweroff or reboot
  requests are not acknowledged and FreeBSD simply proceeds to perform
  the desired action.
  
  Fix this by acknowledging all requests, and remove the suspend specific
  ack done in the handler.
  
  Sponsored by: Citrix Systems R
  MFC after:3 days

Modified:
  head/sys/dev/xen/control/control.c

Modified: head/sys/dev/xen/control/control.c
==
--- head/sys/dev/xen/control/control.c  Tue Oct  1 03:35:54 2019
(r352924)
+++ head/sys/dev/xen/control/control.c  Tue Oct  1 08:21:41 2019
(r352925)
@@ -221,12 +221,6 @@ xctrl_suspend()
KASSERT((PCPU_GET(cpuid) == 0), ("Not running on CPU#0"));
 
/*
-* Clear our XenStore node so the toolstack knows we are
-* responding to the suspend request.
-*/
-   xs_write(XST_NIL, "control", "shutdown", "");
-
-   /*
 * Be sure to hold Giant across DEVICE_SUSPEND/RESUME since non-MPSAFE
 * drivers need this.
 */
@@ -368,6 +362,11 @@ xctrl_on_watch_event(struct xs_watch *watch, const cha
_len, (void **));
if (error != 0)
return;
+
+   /* Acknowledge the request by writing back an empty string. */
+   error = xs_write(XST_NIL, "control", "shutdown", "");
+   if (error != 0)
+   printf("unable to ack shutdown request, proceeding anyway\n");
 
reason = xctrl_shutdown_reasons;
last_reason = reason + nitems(xctrl_shutdown_reasons);
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r349423 - head/contrib/elftoolchain/elfcopy

2019-07-04 Thread Roger Pau Monné
On Wed, Jun 26, 2019 at 04:35:37PM +, Mark Johnston wrote:
> Author: markj
> Date: Wed Jun 26 16:35:37 2019
> New Revision: 349423
> URL: https://svnweb.freebsd.org/changeset/base/349423
> 
> Log:
>   elfcopy: Provide a size hint when creating the section string table.
>   
>   Use the input file's .shstrtab size as the hint if it exists.  This
>   gives a small performance improvement when processing files with
>   many sections.

This change breaks the Xen build using objcopy. I have a very simple
test case, pick the file from:

https://people.freebsd.org/~royger/buildid.ihex

Then do:

$ objcopy -I ihex -O binary buildid.ihex buildid.o
objcopy: elf_nextscn failed: Invalid argument

This used to work before this change, and now fails.

Thanks, Roger.
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r347183 - head/sys/geom

2019-05-06 Thread Roger Pau Monné
Author: royger
Date: Mon May  6 09:48:34 2019
New Revision: 347183
URL: https://svnweb.freebsd.org/changeset/base/347183

Log:
  geom: fix initialization order
  
  There's a race between the initialization of devsoftc.mtx (by devinit)
  and the creation of the geom worker thread g_run_events, which calls
  devctl_queue_data_f. Both of those are initialized at SI_SUB_DRIVERS
  and SI_ORDER_FIRST, which means the geom worked thread can be created
  before the mutex has been initialized, leading to the panic below:
  
   wpanic: mtx_lock() of spin mutex (null) @ 
/usr/home/osstest/build.135317.build-amd64-freebsd/freebsd/sys/kern/subr_bus.c:620
   cpuid = 3
   time = 1
   KDB: stack backtrace:
   db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 
0xfe003b968710
   vpanic() at vpanic+0x19d/frame 0xfe003b968760
   panic() at panic+0x43/frame 0xfe003b9687c0
   __mtx_lock_flags() at __mtx_lock_flags+0x145/frame 0xfe003b968810
   devctl_queue_data_f() at devctl_queue_data_f+0x6a/frame 0xfe003b968840
   g_dev_taste() at g_dev_taste+0x463/frame 0xfe003b968a00
   g_load_class() at g_load_class+0x1bc/frame 0xfe003b968a30
   g_run_events() at g_run_events+0x197/frame 0xfe003b968a70
   fork_exit() at fork_exit+0x84/frame 0xfe003b968ab0
   fork_trampoline() at fork_trampoline+0xe/frame 0xfe003b968ab0
   --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
   KDB: enter: panic
   [ thread pid 13 tid 100029 ]
   Stopped at  kdb_enter+0x3b: movq$0,kdb_why
  
  Fix this by initializing geom at SI_ORDER_SECOND instead of
  SI_ORDER_FIRST.
  
  Sponsored by: Citrix Systems R
  Reviewed by:  kevans, markj
  Differential revision:https://reviews.freebsd.org/D20148

Modified:
  head/sys/geom/geom.h

Modified: head/sys/geom/geom.h
==
--- head/sys/geom/geom.hMon May  6 08:55:23 2019(r347182)
+++ head/sys/geom/geom.hMon May  6 09:48:34 2019(r347183)
@@ -415,7 +415,7 @@ g_free(void *ptr)
static moduledata_t name##_mod = {  \
#name, g_modevent,\
};  \
-   DECLARE_MODULE(name, name##_mod, SI_SUB_DRIVERS, SI_ORDER_FIRST);
+   DECLARE_MODULE(name, name##_mod, SI_SUB_DRIVERS, SI_ORDER_SECOND);
 
 int g_is_geom_thread(struct thread *td);
 
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r346670 - head/sys/net

2019-05-02 Thread Roger Pau Monné
On Thu, May 02, 2019 at 08:14:08AM -0500, Kyle Evans wrote:
> On Thu, May 2, 2019 at 7:54 AM Roger Pau Monné  wrote:
> >
> > On Thu, May 02, 2019 at 04:58:39AM -0700, Cy Schubert wrote:
> > > In message <2019050206.pfosaq73kgo6g...@air-de-roger.citrite.net>,
> > > Roger Pa
> > > u =?utf-8?B?TW9ubsOp?= writes:
> > > > On Thu, Apr 25, 2019 at 12:44:08PM +, Kyle Evans wrote:
> > > > Apr 26 16:23:57.662653 panic: mtx_lock() of spin mutex (null) @ 
> > > > /usr/home/oss
> > > > test/build.135317.build-amd64-freebsd/freebsd/sys/kern/subr_bus.c:620
> > > > Apr 26 16:23:57.674650 cpuid = 2
> > > > Apr 26 16:23:57.686653 time = 1
> > > > Apr 26 16:23:57.686720 KDB: stack backtrace:
> > > > Apr 26 16:23:57.686797 db_trace_self_wrapper() at 
> > > > db_trace_self_wrapper+0x2b/
> > > > frame 0xfe003abe8710
> > > > Apr 26 16:23:57.686879 vpanic() at vpanic+0x19d/frame 0xfe003abe8760
> > > > Apr 26 16:23:57.698637 panic() at panic+0x43/frame 0xfe003abe87c0
> > > > Apr 26 16:23:57.698700 __mtx_lock_flags() at 
> > > > __mtx_lock_flags+0x145/frame 0xf
> > > > e003abe8810
> > > > Apr 26 16:23:57.710640 devctl_queue_data_f() at 
> > > > devctl_queue_data_f+0x6a/fram
> > > > e 0xfe003abe8840
> > > > Apr 26 16:23:57.722625 g_dev_taste() at g_dev_taste+0x463/frame 
> > > > 0xfe003ab
> > > > e8a00
> > > > Apr 26 16:23:57.722690 g_load_class() at g_load_class+0x1bc/frame 
> > > > 0xfe003
> > > > abe8a30
> > > > Apr 26 16:23:57.734638 g_run_events() at g_run_events+0x197/frame 
> > > > 0xfe003
> > > > abe8a70
> > > > Apr 26 16:23:57.734704 fork_exit() at fork_exit+0x84/frame 
> > > > 0xfe003abe8ab0
> > > > Apr 26 16:23:57.746655 fork_trampoline() at fork_trampoline+0xe/frame 
> > > > 0xf
> > > > e003abe8ab0
> > > > Apr 26 16:23:57.746721 --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
> > > > Apr 26 16:23:57.758797 KDB: enter: panic
> > > > Apr 26 16:23:57.758913 [ thread pid 13 tid 100029 ]
> > > > Apr 26 16:23:57.758943 Stopped at  kdb_enter+0x3b: movq
> > > > $0,kdb_why
> > > > Apr 26 16:23:57.770557 db>
> > > >
> > > > The automatic bisector has pointed as this commit as the culprit, you
> > > > can see the full bisection at:
> > > >
> > > > https://lists.xenproject.org/archives/html/xen-devel/2019-04/msg02061.html
> > > >
> > > > And an example of a failed test at:
> > > >
> > > > https://lists.xenproject.org/archives/html/xen-devel/2019-05/msg00104.html
> > > > http://logs.test-lab.xenproject.org/osstest/logs/135458/
> > > >
> > > > Thanks, Roger.
> > > >
> > > >
> > >
> > > It made a strange connection to this commit. The panic has geom written
> > > all over it.
> >
> > I agree it's a strange connection, but the results from the bisection
> > are quite clear, the previous commit which is 070cf1ede1850d8c
> > (r346664) works fine and d61e108233bfdb3 (r346670) this commit
> > fails.
> >
> > The bisection looks reliable as there are no skipped revisions or
> > spurious failures.
> >
> 
> This panic seems to make sense, generally if I read things right, but
> I'm not immediately sure how my commit triggered it. The mutex in
> question is initialized in devinit, invoked by the root_bus_mod at
> SI_SUB_DRIVERS + SI_ORDER_FIRST [0]. geom classes are also declared at
> SI_SUB_DRIVERS + SI_ORDER_FIRST [1], which takes us on a trip through
> g_modevent -> g_init. g_init creates the g_event thread [2] ->
> g_event_procbody -> g_run_events -> ... -> (boom). I guess the
> timing/ordering of these things normally works out so that devinit
> gets the mutex ready before the g_event thread does any
> loading/tasting, but not here.

My bet is that your usage of SX_SYSINIT somehow changed the order of
the geom stuff and now it's exploding.

I think I might have a fix for this, but I need to reproduce on the
CI test boxes, my test box doesn't trigger the issue.

Roger.
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r346670 - head/sys/net

2019-05-02 Thread Roger Pau Monné
On Thu, May 02, 2019 at 04:58:39AM -0700, Cy Schubert wrote:
> In message <2019050206.pfosaq73kgo6g...@air-de-roger.citrite.net>, 
> Roger Pa
> u =?utf-8?B?TW9ubsOp?= writes:
> > On Thu, Apr 25, 2019 at 12:44:08PM +, Kyle Evans wrote:
> > Apr 26 16:23:57.662653 panic: mtx_lock() of spin mutex (null) @ 
> > /usr/home/oss
> > test/build.135317.build-amd64-freebsd/freebsd/sys/kern/subr_bus.c:620
> > Apr 26 16:23:57.674650 cpuid = 2
> > Apr 26 16:23:57.686653 time = 1
> > Apr 26 16:23:57.686720 KDB: stack backtrace:
> > Apr 26 16:23:57.686797 db_trace_self_wrapper() at 
> > db_trace_self_wrapper+0x2b/
> > frame 0xfe003abe8710
> > Apr 26 16:23:57.686879 vpanic() at vpanic+0x19d/frame 0xfe003abe8760
> > Apr 26 16:23:57.698637 panic() at panic+0x43/frame 0xfe003abe87c0
> > Apr 26 16:23:57.698700 __mtx_lock_flags() at __mtx_lock_flags+0x145/frame 
> > 0xf
> > e003abe8810
> > Apr 26 16:23:57.710640 devctl_queue_data_f() at 
> > devctl_queue_data_f+0x6a/fram
> > e 0xfe003abe8840
> > Apr 26 16:23:57.722625 g_dev_taste() at g_dev_taste+0x463/frame 
> > 0xfe003ab
> > e8a00
> > Apr 26 16:23:57.722690 g_load_class() at g_load_class+0x1bc/frame 
> > 0xfe003
> > abe8a30
> > Apr 26 16:23:57.734638 g_run_events() at g_run_events+0x197/frame 
> > 0xfe003
> > abe8a70
> > Apr 26 16:23:57.734704 fork_exit() at fork_exit+0x84/frame 
> > 0xfe003abe8ab0
> > Apr 26 16:23:57.746655 fork_trampoline() at fork_trampoline+0xe/frame 
> > 0xf
> > e003abe8ab0
> > Apr 26 16:23:57.746721 --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
> > Apr 26 16:23:57.758797 KDB: enter: panic
> > Apr 26 16:23:57.758913 [ thread pid 13 tid 100029 ]
> > Apr 26 16:23:57.758943 Stopped at  kdb_enter+0x3b: movq$0,kdb_why
> > Apr 26 16:23:57.770557 db> 
> >
> > The automatic bisector has pointed as this commit as the culprit, you
> > can see the full bisection at:
> >
> > https://lists.xenproject.org/archives/html/xen-devel/2019-04/msg02061.html
> >
> > And an example of a failed test at:
> >
> > https://lists.xenproject.org/archives/html/xen-devel/2019-05/msg00104.html
> > http://logs.test-lab.xenproject.org/osstest/logs/135458/
> >
> > Thanks, Roger.
> >
> >
> 
> It made a strange connection to this commit. The panic has geom written 
> all over it.

I agree it's a strange connection, but the results from the bisection
are quite clear, the previous commit which is 070cf1ede1850d8c
(r346664) works fine and d61e108233bfdb3 (r346670) this commit
fails.

The bisection looks reliable as there are no skipped revisions or
spurious failures.

Roger.
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r346670 - head/sys/net

2019-05-02 Thread Roger Pau Monné
On Thu, Apr 25, 2019 at 12:44:08PM +, Kyle Evans wrote:
> Author: kevans
> Date: Thu Apr 25 12:44:08 2019
> New Revision: 346670
> URL: https://svnweb.freebsd.org/changeset/base/346670
> 
> Log:
>   tun/tap: close race between destroy/ioctl handler
>   
>   It seems that there should be a better way to handle this, but this seems to
>   be the more common approach and it should likely get replaced in all of the
>   places it happens... Basically, thread 1 is in the process of destroying the
>   tun/tap while thread 2 is executing one of the ioctls that requires the
>   tun/tap mutex and the mutex is destroyed before the ioctl handler can
>   acquire it.
>   
>   This is only one of the races described/found in PR 233955.
>   
>   PR: 233955
>   Reviewed by:ae
>   MFC after:  2 weeks
>   Differential Revision:  https://reviews.freebsd.org/D20027

This has caused a regression when booting. I reliably get the
following panic when booting on several different boxes:

Apr 26 16:23:57.662653 panic: mtx_lock() of spin mutex (null) @ 
/usr/home/osstest/build.135317.build-amd64-freebsd/freebsd/sys/kern/subr_bus.c:620
Apr 26 16:23:57.674650 cpuid = 2
Apr 26 16:23:57.686653 time = 1
Apr 26 16:23:57.686720 KDB: stack backtrace:
Apr 26 16:23:57.686797 db_trace_self_wrapper() at 
db_trace_self_wrapper+0x2b/frame 0xfe003abe8710
Apr 26 16:23:57.686879 vpanic() at vpanic+0x19d/frame 0xfe003abe8760
Apr 26 16:23:57.698637 panic() at panic+0x43/frame 0xfe003abe87c0
Apr 26 16:23:57.698700 __mtx_lock_flags() at __mtx_lock_flags+0x145/frame 
0xfe003abe8810
Apr 26 16:23:57.710640 devctl_queue_data_f() at devctl_queue_data_f+0x6a/frame 
0xfe003abe8840
Apr 26 16:23:57.722625 g_dev_taste() at g_dev_taste+0x463/frame 
0xfe003abe8a00
Apr 26 16:23:57.722690 g_load_class() at g_load_class+0x1bc/frame 
0xfe003abe8a30
Apr 26 16:23:57.734638 g_run_events() at g_run_events+0x197/frame 
0xfe003abe8a70
Apr 26 16:23:57.734704 fork_exit() at fork_exit+0x84/frame 0xfe003abe8ab0
Apr 26 16:23:57.746655 fork_trampoline() at fork_trampoline+0xe/frame 
0xfe003abe8ab0
Apr 26 16:23:57.746721 --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
Apr 26 16:23:57.758797 KDB: enter: panic
Apr 26 16:23:57.758913 [ thread pid 13 tid 100029 ]
Apr 26 16:23:57.758943 Stopped at  kdb_enter+0x3b: movq$0,kdb_why
Apr 26 16:23:57.770557 db> 

The full serial log of the host booting:

e820: 95fff000 0`000/boot/config: -hn 
-S115200/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\Consoles:
 serial port  
Apr 26 16:23:50.318505 BIOS drive C: is disk0
Apr 26 16:23:50.318505 BIOS drive D: is disk1
Apr 26 16:23:50.330486 |/BIOS 632kB/2316028kB available memory
Apr 26 16:23:50.366512 
Apr 26 16:23:50.366512 FreeBSD/x86 bootstrap loader, Revision 1.1
Apr 26 16:23:50.366512 
-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|Loading
 /boot/defaults/loader.conf
Apr 26 16:23:50.414528 Loading /boot/device.hints
Apr 26 16:23:50.426510 /-\|/-Loading /boot/loader.conf
Apr 26 16:23:50.426510 \|/-Loading /boot/loader.conf.local
Apr 26 16:23:50.438526 
\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\Loading 
kernel...
Apr 26 16:23:50.450532 
|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|//boot/kernel/kernel
 text=0x16e4c29 
-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|data=0x1d65a8+0x819948
 
/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-syms=[0x8+0x183c48\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/+0x8+0x1a1479-\|]
Apr 26 16:23:51.626609 Loading configured modules...
Apr 26 16:23:51.638619 /-\|/-\|/-\|/-\|can't find 
'/boot/entropy'
Apr 26 16:23:51.638679 /-\|/-\|/-\|/-\/mfsroot 
|/-\|/-\|/-\|/-800 2   

svn commit: r343573 - in head/sys: x86/xen xen

2019-01-30 Thread Roger Pau Monné
Author: royger
Date: Wed Jan 30 11:34:52 2019
New Revision: 343573
URL: https://svnweb.freebsd.org/changeset/base/343573

Log:
  xen: introduce a new way to setup event channel upcall
  
  The main differences with the currently implemented method are:
  
   - Requires a local APIC EOI, since it doesn't bypass the local APIC
 as the previous method used to do.
   - Can be set to use different IDT vectors on each vCPU. Note that
 FreeBSD doesn't make use of this feature since the event channel
 IDT vector is reserved system wide.
  
  Note that the old method of setting the event channel upcall is
  not removed, and will be used as a fallback if this newly introduced
  method is not available.
  
  MFC after:1 month
  Sponsored by: Citrix Systems R

Modified:
  head/sys/x86/xen/hvm.c
  head/sys/x86/xen/xen_intr.c
  head/sys/xen/hvm.h

Modified: head/sys/x86/xen/hvm.c
==
--- head/sys/x86/xen/hvm.c  Wed Jan 30 09:44:54 2019(r343572)
+++ head/sys/x86/xen/hvm.c  Wed Jan 30 11:34:52 2019(r343573)
@@ -51,6 +51,7 @@ __FBSDID("$FreeBSD$");
 #include 
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -88,6 +89,12 @@ int xen_vector_callback_enabled;
  */
 uint32_t hvm_start_flags;
 
+/**
+ * Signal whether the vector injected for the event channel upcall requires to
+ * be EOI'ed on the local APIC.
+ */
+bool xen_evtchn_needs_ack;
+
 /*--- Per-CPU Data 
---*/
 DPCPU_DEFINE(struct vcpu_info, vcpu_local_info);
 DPCPU_DEFINE(struct vcpu_info *, vcpu_info);
@@ -223,6 +230,19 @@ xen_hvm_init_shared_info_page(void)
panic("HYPERVISOR_memory_op failed");
 }
 
+static int
+set_percpu_callback(unsigned int vcpu)
+{
+   struct xen_hvm_evtchn_upcall_vector vec;
+   int error;
+
+   vec.vcpu = vcpu;
+   vec.vector = IDT_EVTCHN;
+   error = HYPERVISOR_hvm_op(HVMOP_set_evtchn_upcall_vector, );
+
+   return (error != 0 ? xen_translate_error(error) : 0);
+}
+
 /*
  * Tell the hypervisor how to contact us for event channel callbacks.
  */
@@ -240,12 +260,20 @@ xen_hvm_set_callback(device_t dev)
if (xen_feature(XENFEAT_hvm_callback_vector) != 0) {
int error;
 
-   xhp.value = HVM_CALLBACK_VECTOR(IDT_EVTCHN);
+   error = set_percpu_callback(0);
+   if (error == 0) {
+   xen_evtchn_needs_ack = true;
+   /* Trick toolstack to think we are enlightened */
+   xhp.value = 1;
+   } else
+   xhp.value = HVM_CALLBACK_VECTOR(IDT_EVTCHN);
error = HYPERVISOR_hvm_op(HVMOP_set_param, );
if (error == 0) {
xen_vector_callback_enabled = 1;
return;
-   }
+   } else if (xen_evtchn_needs_ack)
+   panic("Unable to setup fake HVM param: %d", error);
+
printf("Xen HVM callback vector registration failed (%d). "
"Falling back to emulated device interrupt\n", error);
}
@@ -360,6 +388,7 @@ xen_hvm_init(enum xen_hvm_init_type init_type)
}
 
xen_vector_callback_enabled = 0;
+   xen_evtchn_needs_ack = false;
xen_hvm_set_callback(NULL);
 
/*
@@ -426,6 +455,20 @@ xen_hvm_cpu_init(void)
("Xen PV domain without vcpu_id in cpuid"));
PCPU_SET(vcpu_id, (regs[0] & XEN_HVM_CPUID_VCPU_ID_PRESENT) ?
regs[1] : PCPU_GET(acpi_id));
+
+   if (xen_evtchn_needs_ack && !IS_BSP()) {
+   /*
+* Setup the per-vpcu event channel upcall vector. This is only
+* required when using the new HVMOP_set_evtchn_upcall_vector
+* hypercall, which allows using a different vector for each
+* vCPU. Note that FreeBSD uses the same vector for all vCPUs
+* because it's not dynamically allocated.
+*/
+   rc = set_percpu_callback(PCPU_GET(vcpu_id));
+   if (rc != 0)
+   panic("Event channel upcall vector setup failed: %d",
+   rc);
+   }
 
/*
 * Set the vCPU info.

Modified: head/sys/x86/xen/xen_intr.c
==
--- head/sys/x86/xen/xen_intr.c Wed Jan 30 09:44:54 2019(r343572)
+++ head/sys/x86/xen/xen_intr.c Wed Jan 30 11:34:52 2019(r343573)
@@ -60,6 +60,7 @@ __FBSDID("$FreeBSD$");
 #include 
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -620,6 +621,10 @@ xen_intr_handle_upcall(struct trapframe *trap_frame)
l1 &= ~(1UL << l1i);
}
}
+
+   if (xen_evtchn_needs_ack)
+   lapic_eoi();
+
critical_exit();
 }
 

Modified: head/sys/xen/hvm.h

svn commit: r338632 - head/sys/dev/xen/privcmd

2018-09-13 Thread Roger Pau Monné
Author: royger
Date: Thu Sep 13 07:15:02 2018
New Revision: 338632
URL: https://svnweb.freebsd.org/changeset/base/338632

Log:
  xen: temporary disable SMAP when forwarding hypercalls from user-space
  
  The Xen page-table walker used to resolve the virtual addresses in the
  hypercalls will refuse to access user-space pages when SMAP is enabled
  unless the AC flag in EFLAGS is set (just like normal hardware with
  SMAP support would do).
  
  Since privcmd allows forwarding hypercalls (and buffers) from
  user-space into Xen make sure SMAP is temporary disabled for the
  duration of the hypercall from user-space.
  
  Approved by:  re (gjb)
  Sponsored by: Citrix Systems R

Modified:
  head/sys/dev/xen/privcmd/privcmd.c

Modified: head/sys/dev/xen/privcmd/privcmd.c
==
--- head/sys/dev/xen/privcmd/privcmd.c  Thu Sep 13 07:14:11 2018
(r338631)
+++ head/sys/dev/xen/privcmd/privcmd.c  Thu Sep 13 07:15:02 2018
(r338632)
@@ -232,9 +232,21 @@ privcmd_ioctl(struct cdev *dev, unsigned long cmd, cad
struct ioctl_privcmd_hypercall *hcall;
 
hcall = (struct ioctl_privcmd_hypercall *)arg;
-
+#ifdef __amd64__
+   /*
+* The hypervisor page table walker will refuse to access
+* user-space pages if SMAP is enabled, so temporary disable it
+* while performing the hypercall.
+*/
+   if (cpu_stdext_feature & CPUID_STDEXT_SMAP)
+   stac();
+#endif
error = privcmd_hypercall(hcall->op, hcall->arg[0],
hcall->arg[1], hcall->arg[2], hcall->arg[3], hcall->arg[4]);
+#ifdef __amd64__
+   if (cpu_stdext_feature & CPUID_STDEXT_SMAP)
+   clac();
+#endif
if (error >= 0) {
hcall->retval = error;
error = 0;
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r338631 - in head/sys: x86/xen xen

2018-09-13 Thread Roger Pau Monné
Author: royger
Date: Thu Sep 13 07:14:11 2018
New Revision: 338631
URL: https://svnweb.freebsd.org/changeset/base/338631

Log:
  xen: legacy PVH fixes for the new interrupt count
  
  Register interrupts using the PIC pic_register_sources method instead
  of doing it in apic_setup_io. This is now required, since the internal
  interrupt structures are not yet setup when calling apic_setup_io.
  
  Approved by:  re (gjb)
  Sponsored by: Citrix Systems R

Modified:
  head/sys/x86/xen/pvcpu_enum.c
  head/sys/x86/xen/xen_intr.c
  head/sys/xen/xen_intr.h

Modified: head/sys/x86/xen/pvcpu_enum.c
==
--- head/sys/x86/xen/pvcpu_enum.c   Thu Sep 13 07:13:13 2018
(r338630)
+++ head/sys/x86/xen/pvcpu_enum.c   Thu Sep 13 07:14:11 2018
(r338631)
@@ -193,52 +193,65 @@ xenpv_setup_io(void)
 {
 
if (xen_initial_domain()) {
-   int i, ret;
+   /*
+* NB: we could iterate over the MADT IOAPIC entries in order
+* to figure out the exact number of IOAPIC interrupts, but
+* this is legacy code so just keep using the previous
+* behaviour and assume a maximum of 256 interrupts.
+*/
+   num_io_irqs = max(MINIMUM_MSI_INT - 1, num_io_irqs);
 
-   /* Map MADT */
-   madt_physaddr = acpi_find_table(ACPI_SIG_MADT);
-   madt = acpi_map_table(madt_physaddr, ACPI_SIG_MADT);
-   madt_length = madt->Header.Length;
+   acpi_SetDefaultIntrModel(ACPI_INTR_APIC);
+   }
+   return (0);
+}
 
-   /* Try to initialize ACPI so that we can access the FADT. */
-   i = acpi_Startup();
-   if (ACPI_FAILURE(i)) {
-   printf("MADT: ACPI Startup failed with %s\n",
-   AcpiFormatException(i));
-   printf("Try disabling either ACPI or apic support.\n");
-   panic("Using MADT but ACPI doesn't work");
-   }
+void
+xenpv_register_pirqs(struct pic *pic __unused)
+{
+   unsigned int i;
+   int ret;
 
-   /* Run through the table to see if there are any overrides. */
-   madt_walk_table(madt_parse_ints, NULL);
+   /* Map MADT */
+   madt_physaddr = acpi_find_table(ACPI_SIG_MADT);
+   madt = acpi_map_table(madt_physaddr, ACPI_SIG_MADT);
+   madt_length = madt->Header.Length;
 
-   /*
-* If there was not an explicit override entry for the SCI,
-* force it to use level trigger and active-low polarity.
-*/
-   if (!madt_found_sci_override) {
-   printf(
-   "MADT: Forcing active-low polarity and level trigger for SCI\n");
-   ret = xen_register_pirq(AcpiGbl_FADT.SciInterrupt,
-   INTR_TRIGGER_LEVEL, INTR_POLARITY_LOW);
-   if (ret != 0)
-   panic("Unable to register SCI IRQ");
-   }
+   /* Try to initialize ACPI so that we can access the FADT. */
+   ret = acpi_Startup();
+   if (ACPI_FAILURE(ret)) {
+   printf("MADT: ACPI Startup failed with %s\n",
+   AcpiFormatException(ret));
+   printf("Try disabling either ACPI or apic support.\n");
+   panic("Using MADT but ACPI doesn't work");
+   }
 
-   /* Register legacy ISA IRQs */
-   for (i = 1; i < 16; i++) {
-   if (intr_lookup_source(i) != NULL)
-   continue;
-   ret = xen_register_pirq(i, INTR_TRIGGER_EDGE,
-   INTR_POLARITY_LOW);
-   if (ret != 0 && bootverbose)
-   printf("Unable to register legacy IRQ#%d: %d\n",
-   i, ret);
-   }
+   /* Run through the table to see if there are any overrides. */
+   madt_walk_table(madt_parse_ints, NULL);
 
-   acpi_SetDefaultIntrModel(ACPI_INTR_APIC);
+   /*
+* If there was not an explicit override entry for the SCI,
+* force it to use level trigger and active-low polarity.
+*/
+   if (!madt_found_sci_override) {
+   printf(
+"MADT: Forcing active-low polarity and level trigger for SCI\n");
+   ret = xen_register_pirq(AcpiGbl_FADT.SciInterrupt,
+   INTR_TRIGGER_LEVEL, INTR_POLARITY_LOW);
+   if (ret != 0)
+   panic("Unable to register SCI IRQ");
}
-   return (0);
+
+   /* Register legacy ISA IRQs */
+   for (i = 1; i < 16; i++) {
+   if (intr_lookup_source(i) != NULL)
+   continue;
+   ret = xen_register_pirq(i, INTR_TRIGGER_EDGE,
+ 

svn commit: r338630 - head/sys/x86/x86

2018-09-13 Thread Roger Pau Monné
Author: royger
Date: Thu Sep 13 07:13:13 2018
New Revision: 338630
URL: https://svnweb.freebsd.org/changeset/base/338630

Log:
  lapic: skip setting intrcnt if lapic is not present
  
  Instead of panicking. Legacy PVH mode doesn't provide a lapic, and
  since native_lapic_intrcnt is called unconditionally this would cause
  the assert to trigger. Change the assert into a continue in order to
  take into account the possibility of systems without a lapic.
  
  Reviewed by:  jhb
  Approved by:  re (gjb)
  Sponsored by: Citrix Systems R
  Differential revision:https://reviews.freebsd.org/D17015

Modified:
  head/sys/x86/x86/local_apic.c

Modified: head/sys/x86/x86/local_apic.c
==
--- head/sys/x86/x86/local_apic.c   Thu Sep 13 07:12:16 2018
(r338629)
+++ head/sys/x86/x86/local_apic.c   Thu Sep 13 07:13:13 2018
(r338630)
@@ -855,7 +855,8 @@ native_lapic_intrcnt(void *dummy __unused)
 
STAILQ_FOREACH(pc, , pc_allcpu) {
la = [pc->pc_apic_id];
-   KASSERT(la->la_present, ("missing APIC structure"));
+   if (!la->la_present)
+   continue;
 
snprintf(buf, sizeof(buf), "cpu%d:timer", pc->pc_cpuid);
intrcnt_add(buf, >la_timer_count);
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r338629 - head/sys/x86/xen

2018-09-13 Thread Roger Pau Monné
Author: royger
Date: Thu Sep 13 07:12:16 2018
New Revision: 338629
URL: https://svnweb.freebsd.org/changeset/base/338629

Log:
  xen: fix setting legacy PVH vcpu id
  
  The recommended way to obtain the vcpu id is using the cpuid
  instruction with a specific leaf value. This leaf value must be
  obtained at runtime, and it's done when populating the hypercall page.
  
  Legacy PVH however will get the hypercall page populated by the
  hypervisor itself before booting, so the cpuid leaf was not actually
  set, thus preventing setting the vcpu id value from cpuid.
  
  Fix this by making sure the cpuid leaf has been probed before
  attempting to set the vcpu id.
  
  Approved by:  re (gjb)
  Sponsored by: Citrix Systems R

Modified:
  head/sys/x86/xen/hvm.c

Modified: head/sys/x86/xen/hvm.c
==
--- head/sys/x86/xen/hvm.c  Thu Sep 13 07:11:11 2018(r338628)
+++ head/sys/x86/xen/hvm.c  Thu Sep 13 07:12:16 2018(r338629)
@@ -163,6 +163,12 @@ xen_hvm_init_hypercall_stubs(enum xen_hvm_init_type in
 {
uint32_t regs[4];
 
+   /* Legacy PVH will get here without the cpuid leaf being set. */
+   if (cpuid_base == 0)
+   cpuid_base = xen_hvm_cpuid_base();
+   if (cpuid_base == 0)
+   return (ENXIO);
+
if (xen_domain() && init_type == XEN_HVM_INIT_LATE) {
/*
 * If the domain type is already set we can assume that the
@@ -172,10 +178,6 @@ xen_hvm_init_hypercall_stubs(enum xen_hvm_init_type in
hypervisor_version();
return 0;
}
-
-   cpuid_base = xen_hvm_cpuid_base();
-   if (cpuid_base == 0)
-   return (ENXIO);
 
if (init_type == XEN_HVM_INIT_LATE)
hypervisor_version();
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r338628 - head/sys/x86/xen

2018-09-13 Thread Roger Pau Monné
Author: royger
Date: Thu Sep 13 07:11:11 2018
New Revision: 338628
URL: https://svnweb.freebsd.org/changeset/base/338628

Log:
  xen: limit the usage of PIRQs to a legacy PVH Dom0
  
  That's the only mode in FreeBSD that requires the usage of PIRQs, so
  there's no need to attach the PIRQ PIC when running in other modes.
  
  Approved by:  re (gjb)
  Sponsored by: Citrix Systems R

Modified:
  head/sys/x86/xen/xen_intr.c

Modified: head/sys/x86/xen/xen_intr.c
==
--- head/sys/x86/xen/xen_intr.c Thu Sep 13 07:09:41 2018(r338627)
+++ head/sys/x86/xen/xen_intr.c Thu Sep 13 07:11:11 2018(r338628)
@@ -656,7 +656,8 @@ xen_intr_init(void *dummy __unused)
xen_intr_pirq_eoi_map_enabled = true;
 
intr_register_pic(_intr_pic);
-   intr_register_pic(_intr_pirq_pic);
+   if (xen_pv_domain() && xen_initial_domain())
+   intr_register_pic(_intr_pirq_pic);
 
if (bootverbose)
printf("Xen interrupt system initialized\n");
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r338627 - head/sys/x86/xen

2018-09-13 Thread Roger Pau Monné
Author: royger
Date: Thu Sep 13 07:09:41 2018
New Revision: 338627
URL: https://svnweb.freebsd.org/changeset/base/338627

Log:
  xen: fix initial kenv setup for legacy PVH
  
  When adding support for the new PVH mode the kenv handling was
  switched to use a boot time allocated scratch space, however the
  legacy PVH early boot code was not modified to allocate such space.
  
  Approved by:  re (gjb)
  Sponsored by: Citrix Systems R

Modified:
  head/sys/x86/xen/pv.c

Modified: head/sys/x86/xen/pv.c
==
--- head/sys/x86/xen/pv.c   Thu Sep 13 07:08:31 2018(r338626)
+++ head/sys/x86/xen/pv.c   Thu Sep 13 07:09:41 2018(r338627)
@@ -204,6 +204,7 @@ hammer_time_xen_legacy(start_info_t *si, uint64_t xens
uint64_t *PT3 = (u_int64_t *)(xenstack + PAGE_SIZE);
uint64_t *PT2 = (u_int64_t *)(xenstack + 2 * PAGE_SIZE);
int i;
+   char *kenv;
 
xen_domain_type = XEN_PV_DOMAIN;
vm_guest = VM_GUEST_XEN;
@@ -251,6 +252,15 @@ hammer_time_xen_legacy(start_info_t *si, uint64_t xens
PT2[i] |= PG_V | PG_RW | PG_PS | PG_U;
}
load_cr3(((uint64_t)[0]) - KERNBASE);
+
+   /*
+* Init an empty static kenv using a free page. The contents will be
+* filled from the parse_preload_data hook.
+*/
+   kenv = (void *)(physfree + KERNBASE);
+   physfree += PAGE_SIZE;
+   bzero(kenv, PAGE_SIZE);
+   init_static_kenv(kenv, PAGE_SIZE);
 
/* Set the hooks for early functions that diverge from bare metal */
init_ops = xen_legacy_init_ops;
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r338626 - head/sys/x86/xen

2018-09-13 Thread Roger Pau Monné
Author: royger
Date: Thu Sep 13 07:08:31 2018
New Revision: 338626
URL: https://svnweb.freebsd.org/changeset/base/338626

Log:
   xen: remove xenpv_set_ids
  
  The vcpu_id for legacy PVH mode can be set from the output of cpuid,
  so there's no need to have a special function to set it.
  
  Also note that xenpv_set_ids should have been executed only for PV
  guests, but was executed for all guests types and vcpu_id was later
  fixed up for HVM guests.
  
  Reported by:  cperciva
  Approved by:  re (gjb)
  Sponsored by: Citrix Systems R

Modified:
  head/sys/x86/xen/hvm.c
  head/sys/x86/xen/pvcpu_enum.c

Modified: head/sys/x86/xen/hvm.c
==
--- head/sys/x86/xen/hvm.c  Thu Sep 13 07:07:13 2018(r338625)
+++ head/sys/x86/xen/hvm.c  Thu Sep 13 07:08:31 2018(r338626)
@@ -419,6 +419,9 @@ xen_hvm_cpu_init(void)
 */
KASSERT(cpuid_base != 0, ("Invalid base Xen CPUID leaf"));
cpuid_count(cpuid_base + 4, 0, regs);
+   KASSERT((regs[0] & XEN_HVM_CPUID_VCPU_ID_PRESENT) ||
+   !xen_pv_domain(),
+   ("Xen PV domain without vcpu_id in cpuid"));
PCPU_SET(vcpu_id, (regs[0] & XEN_HVM_CPUID_VCPU_ID_PRESENT) ?
regs[1] : PCPU_GET(acpi_id));
 

Modified: head/sys/x86/xen/pvcpu_enum.c
==
--- head/sys/x86/xen/pvcpu_enum.c   Thu Sep 13 07:07:13 2018
(r338625)
+++ head/sys/x86/xen/pvcpu_enum.c   Thu Sep 13 07:08:31 2018
(r338626)
@@ -249,19 +249,3 @@ xenpv_register(void *dummy __unused)
}
 }
 SYSINIT(xenpv_register, SI_SUB_TUNABLES - 1, SI_ORDER_FIRST, xenpv_register, 
NULL);
-
-/*
- * Setup per-CPU vCPU IDs
- */
-static void
-xenpv_set_ids(void *dummy)
-{
-   struct pcpu *pc;
-   int i;
-
-   CPU_FOREACH(i) {
-   pc = pcpu_find(i);
-   pc->pc_vcpu_id = i;
-   }
-}
-SYSINIT(xenpv_set_ids, SI_SUB_CPU, SI_ORDER_MIDDLE, xenpv_set_ids, NULL);
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r338625 - head/sys/x86/xen

2018-09-13 Thread Roger Pau Monné
Author: royger
Date: Thu Sep 13 07:07:13 2018
New Revision: 338625
URL: https://svnweb.freebsd.org/changeset/base/338625

Log:
  xen: fix PV IPI setup
  
  So that it's done when the vcpu_id has been set. For the BSP the
  vcpu_id is set at SUB_INTR, while for the APs it's done in
  init_secondary_tail that's called at SUB_SMP order FIRST.
  
  Reported and tested by:   cperciva
  Approved by:  re (gjb)
  Sponsored by: Citrix Systems R
  Differential revision:https://reviews.freebsd.org/D17013

Modified:
  head/sys/x86/xen/xen_apic.c

Modified: head/sys/x86/xen/xen_apic.c
==
--- head/sys/x86/xen/xen_apic.c Thu Sep 13 07:05:51 2018(r338624)
+++ head/sys/x86/xen/xen_apic.c Thu Sep 13 07:07:13 2018(r338625)
@@ -592,6 +592,6 @@ xen_setup_cpus(void)
apic_ops.ipi_vectored = xen_pv_lapic_ipi_vectored;
 }
 
-/* We need to setup IPIs before APs are started */
-SYSINIT(xen_setup_cpus, SI_SUB_SMP-1, SI_ORDER_FIRST, xen_setup_cpus, NULL);
+/* Switch to using PV IPIs as soon as the vcpu_id is set. */
+SYSINIT(xen_setup_cpus, SI_SUB_SMP, SI_ORDER_SECOND, xen_setup_cpus, NULL);
 #endif /* SMP */
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r338624 - head/sys/x86/x86

2018-09-13 Thread Roger Pau Monné
Author: royger
Date: Thu Sep 13 07:05:51 2018
New Revision: 338624
URL: https://svnweb.freebsd.org/changeset/base/338624

Log:
  msi: remove the check that interrupt sources have been added
  
  When running as a specific type of Xen guest the hypervisor won't
  provide any emulated IO-APICs or legacy PICs at all, thus hitting the
  following assert in the MSI code:
  
  panic: Assertion num_io_irqs > 0 failed at /usr/src/sys/x86/x86/msi.c:334
  cpuid = 0
  time = 1
  KDB: stack backtrace:
  db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0x826ffa70
  vpanic() at vpanic+0x1a3/frame 0x826ffad0
  panic() at panic+0x43/frame 0x826ffb30
  msi_init() at msi_init+0xed/frame 0x826ffb40
  apic_setup_io() at apic_setup_io+0x72/frame 0x826ffb50
  mi_startup() at mi_startup+0x118/frame 0x826ffb70
  start_kernel() at start_kernel+0x10
  
  Fix this by removing the assert in the MSI code, since it's possible
  to get to the MSI initialization without having registered any other
  interrupt sources.
  
  Reviewed by:  jhb
  Approved by:  re (gjb)
  Sponsored by: Citrix Systems R
  Differential revision:https://reviews.freebsd.org/D17001

Modified:
  head/sys/x86/x86/msi.c

Modified: head/sys/x86/x86/msi.c
==
--- head/sys/x86/x86/msi.c  Thu Sep 13 07:04:00 2018(r338623)
+++ head/sys/x86/x86/msi.c  Thu Sep 13 07:05:51 2018(r338624)
@@ -331,7 +331,6 @@ msi_init(void)
}
 #endif
 
-   MPASS(num_io_irqs > 0);
first_msi_irq = max(MINIMUM_MSI_INT, num_io_irqs);
num_io_irqs = first_msi_irq + NUM_MSI_INTS;
 
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r338623 - head/sys/compat/x86bios

2018-09-13 Thread Roger Pau Monné
Author: royger
Date: Thu Sep 13 07:04:00 2018
New Revision: 338623
URL: https://svnweb.freebsd.org/changeset/base/338623

Log:
  x86bios: use M_NOWAIT with mallocs
  
  Or else it triggers the following bug:
  
  APIC: CPU 6 has ACPI ID 6
  APIC: CPU 7 has ACPI ID 7
  panic: vm_wait in early boot
  cpuid = 0
  time = 1
  KDB: stack backtrace:
  db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0x826ff8d0
  vpanic() at vpanic+0x1a3/frame 0x826ff930
  panic() at panic+0x43/frame 0x826ff990
  vm_wait_domain() at vm_wait_domain+0xf9/frame 0x826ff9c0
  kmem_alloc_contig_domain() at kmem_alloc_contig_domain+0x252/frame 
0x826ffa50
  kmem_alloc_contig() at kmem_alloc_contig+0x6c/frame 0x826ffad0
  contigmalloc() at contigmalloc+0x2e/frame 0x826ffb00
  x86bios_modevent() at x86bios_modevent+0x225/frame 0x826ffb20
  module_register_init() at module_register_init+0xc0/frame 0x826ffb50
  mi_startup() at mi_startup+0x118/frame 0x826ffb70
  start_kernel() at start_kernel+0x10
  
  While there also make x86bios_unmap_mem idempotent.
  
  Reviewed by:  kib
  Approved by:  re (gjb)
  Sponsored by: Citrix Systems R
  Differential revision:https://reviews.freebsd.org/D17000

Modified:
  head/sys/compat/x86bios/x86bios.c

Modified: head/sys/compat/x86bios/x86bios.c
==
--- head/sys/compat/x86bios/x86bios.c   Thu Sep 13 06:21:07 2018
(r338622)
+++ head/sys/compat/x86bios/x86bios.c   Thu Sep 13 07:04:00 2018
(r338623)
@@ -656,17 +656,24 @@ static __inline void
 x86bios_unmap_mem(void)
 {
 
-   free(x86bios_map, M_DEVBUF);
-   if (x86bios_ivt != NULL)
+   if (x86bios_map != NULL) {
+   free(x86bios_map, M_DEVBUF);
+   x86bios_map = NULL;
+   }
+   if (x86bios_ivt != NULL) {
 #ifdef X86BIOS_NATIVE_ARCH
pmap_unmapbios((vm_offset_t)x86bios_ivt, X86BIOS_IVT_SIZE);
 #else
free(x86bios_ivt, M_DEVBUF);
+   x86bios_ivt = NULL;
 #endif
+   }
if (x86bios_rom != NULL)
pmap_unmapdev((vm_offset_t)x86bios_rom, X86BIOS_ROM_SIZE);
-   if (x86bios_seg != NULL)
+   if (x86bios_seg != NULL) {
contigfree(x86bios_seg, X86BIOS_SEG_SIZE, M_DEVBUF);
+   x86bios_seg = NULL;
+   }
 }
 
 static __inline int
@@ -674,7 +681,9 @@ x86bios_map_mem(void)
 {
 
x86bios_map = malloc(sizeof(*x86bios_map) * X86BIOS_PAGES, M_DEVBUF,
-   M_WAITOK | M_ZERO);
+   M_NOWAIT | M_ZERO);
+   if (x86bios_map == NULL)
+   goto fail;
 
 #ifdef X86BIOS_NATIVE_ARCH
x86bios_ivt = pmap_mapbios(X86BIOS_IVT_BASE, X86BIOS_IVT_SIZE);
@@ -688,7 +697,9 @@ x86bios_map_mem(void)
rounddown(x86bios_rom_phys, X86BIOS_PAGE_SIZE);
else
 #else
-   x86bios_ivt = malloc(X86BIOS_IVT_SIZE, M_DEVBUF, M_ZERO | M_WAITOK);
+   x86bios_ivt = malloc(X86BIOS_IVT_SIZE, M_DEVBUF, M_NOWAIT | M_ZERO);
+   if (x86bios_ivt == NULL)
+   goto fail;
 #endif
 
x86bios_rom_phys = X86BIOS_ROM_BASE;
@@ -703,8 +714,10 @@ x86bios_map_mem(void)
goto fail;
 #endif
 
-   x86bios_seg = contigmalloc(X86BIOS_SEG_SIZE, M_DEVBUF, M_WAITOK,
+   x86bios_seg = contigmalloc(X86BIOS_SEG_SIZE, M_DEVBUF, M_NOWAIT,
X86BIOS_RAM_BASE, x86bios_rom_phys, X86BIOS_PAGE_SIZE, 0);
+   if (x86bios_seg == NULL)
+   goto fail;
x86bios_seg_phys = vtophys(x86bios_seg);
 
x86bios_set_pages((vm_offset_t)x86bios_ivt, X86BIOS_IVT_BASE,
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r337960 - in head: . release release/scripts

2018-08-17 Thread Roger Pau Monné
Author: royger
Date: Fri Aug 17 07:27:15 2018
New Revision: 337960
URL: https://svnweb.freebsd.org/changeset/base/337960

Log:
  build: skip the database check when generating install media
  
  There are several scripts and targets solely used to generate install
  media, make sure DB_FROM_SRC is used in that case in order to prevent
  checking the host database, which is irrelevant when generating
  install binaries.
  
  Sponsored by: Citrix Systems R
  PR:   230459
  Reviewed by:  gjb
  Differential revision:https://reviews.freebsd.org/D16638

Modified:
  head/Makefile.inc1
  head/release/Makefile
  head/release/scripts/mm-mtree.sh

Modified: head/Makefile.inc1
==
--- head/Makefile.inc1  Fri Aug 17 06:31:30 2018(r337959)
+++ head/Makefile.inc1  Fri Aug 17 07:27:15 2018(r337960)
@@ -833,7 +833,7 @@ IMAKEENV+=  PATH=${TMPPATH}:${INSTALLTMP}
 
 # When generating install media, do not allow user and group information from
 # the build host to affect the contents of the distribution.
-.if make(distributeworld)
+.if make(distributeworld) || make(distrib-dirs) || make(distribution)
 DB_FROM_SRC=   yes
 .endif
 

Modified: head/release/Makefile
==
--- head/release/Makefile   Fri Aug 17 06:31:30 2018(r337959)
+++ head/release/Makefile   Fri Aug 17 07:27:15 2018(r337960)
@@ -185,7 +185,8 @@ disc1: packagesystem
MK_INSTALLLIB=no MK_LIB32=no MK_MAIL=no \
MK_NCP=no MK_TOOLCHAIN=no MK_PROFILE=no \
MK_RESCUE=no MK_DICT=no \
-   MK_KERNEL_SYMBOLS=no MK_TESTS=no MK_DEBUG_FILES=no
+   MK_KERNEL_SYMBOLS=no MK_TESTS=no MK_DEBUG_FILES=no \
+   -DDB_FROM_SRC
 # Copy distfiles
mkdir -p ${.TARGET}/usr/freebsd-dist
for dist in MANIFEST $$(ls *.txz | grep -vE -- '(base|lib32)-dbg'); \
@@ -213,7 +214,8 @@ bootonly: packagesystem
MK_INSTALLLIB=no MK_LIB32=no MK_MAIL=no \
MK_NCP=no MK_TOOLCHAIN=no MK_PROFILE=no \
MK_RESCUE=no MK_DICT=no \
-   MK_KERNEL_SYMBOLS=no MK_TESTS=no MK_DEBUG_FILES=no
+   MK_KERNEL_SYMBOLS=no MK_TESTS=no MK_DEBUG_FILES=no \
+   -DDB_FROM_SRC
 # Copy manifest only (no distfiles) to get checksums
mkdir -p ${.TARGET}/usr/freebsd-dist
cp MANIFEST ${.TARGET}/usr/freebsd-dist
@@ -234,7 +236,8 @@ dvd: packagesystem
mkdir -p ${.TARGET}
cd ${WORLDDIR} && ${IMAKE} installkernel installworld distribution \
DESTDIR=${.OBJDIR}/${.TARGET} MK_RESCUE=no MK_KERNEL_SYMBOLS=no 
\
-   MK_TESTS=no MK_DEBUG_FILES=no
+   MK_TESTS=no MK_DEBUG_FILES=no \
+   -DDB_FROM_SRC
 # Copy distfiles
mkdir -p ${.TARGET}/usr/freebsd-dist
for dist in MANIFEST $$(ls *.txz | grep -v -- '(base|lib32)-dbg'); \

Modified: head/release/scripts/mm-mtree.sh
==
--- head/release/scripts/mm-mtree.shFri Aug 17 06:31:30 2018
(r337959)
+++ head/release/scripts/mm-mtree.shFri Aug 17 07:27:15 2018
(r337960)
@@ -81,7 +81,7 @@ if [ ! -f ${SOURCEDIR}/Makefile.inc1 -a \
 fi
 
 # Setup make to use system files from SOURCEDIR
-MM_MAKE="make ${ARCHSTRING} ${MM_MAKE_ARGS} -m ${SOURCEDIR}/share/mk"
+MM_MAKE="make ${ARCHSTRING} ${MM_MAKE_ARGS} -m ${SOURCEDIR}/share/mk 
-DDB_FROM_SRC"
 
 delete_temproot () {
   rm -rf "${TEMPROOT}" 2>/dev/null
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r336526 - head

2018-08-08 Thread Roger Pau Monné
On Thu, Jul 26, 2018 at 05:41:46PM +, Brooks Davis wrote:
> On Thu, Jul 26, 2018 at 06:15:46PM +0200, Roger Pau Monn?? wrote:
> > On Thu, Jul 26, 2018 at 09:05:18AM -0600, Ian Lepore wrote:
> > > On Thu, 2018-07-26 at 16:54 +0200, Roger Pau Monn? wrote:
> > > > On Thu, Jul 26, 2018 at 08:49:12AM -0600, Ian Lepore wrote:
> > > > > 
> > > > > On Thu, 2018-07-26 at 15:58 +0200, Roger Pau Monn? wrote:
> > > > > > 
> > > > > > On Fri, Jul 20, 2018 at 12:44:04AM +, Ian Lepore wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > Author: ian
> > > > > > > Date: Fri Jul 20 00:44:04 2018
> > > > > > > New Revision: 336526
> > > > > > > URL: https://svnweb.freebsd.org/changeset/base/336526
> > > > > > > 
> > > > > > > Log:
> > > > > > > ? Add ntpd to the list of users/groups to check before
> > > > > > > installing.
> > > > > > The Xen CI loop is getting this when trying to create dist media
> > > > > > for HEAD FreeBSD (`make -C release ftp`):
> > > > > > 
> > > > > > + LC_ALL=C
> > > > > > + export LC_ALL
> > > > > > +
> > > > > > PATH=/usr/lib/ccache:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbi
> > > > > > n:/u
> > > > > > sr/local/bin:/root/bin:/usr/lib/git-core
> > > > > > + http_proxy=http://cache:3128/
> > > > > > + export http_proxy
> > > > > > + https_proxy=http://cache:3128/
> > > > > > + export https_proxy
> > > > > > + exec
> > > > > > + cd /home/osstest/build.125515.build-amd64-freebsd
> > > > > > + rm -f build-ok-stamp
> > > > > > + cd freebsd
> > > > > > + export 'MAKEOBJDIRPREFIX=/home/osstest/build.125515.build-
> > > > > > amd64-
> > > > > > freebsd/obj'
> > > > > > + export 'TARGET=amd64'
> > > > > > + make -C release ftp -DWITHOUT_AUTO_OBJ
> > > > > > + tee ../release-ftp-log
> > > > > > mkdir -p dist
> > > > > > cd /usr/home/osstest/build.125515.build-amd64-
> > > > > > freebsd/freebsd/release/.. && make TARGET_ARCH=amd64 TARGET=amd64
> > > > > > distributeworld DISTDIR=/usr/home/osstest/build.125515.build-
> > > > > > amd64-
> > > > > > freebsd/freebsd/release/dist
> > > > > > make[2]: "/usr/home/osstest/build.125515.build-amd64-
> > > > > > freebsd/obj/usr/home/osstest/build.125515.build-amd64-
> > > > > > freebsd/freebsd/amd64.amd64/toolchain-metadata.mk" line 1: Using
> > > > > > cached toolchain metadata from build at??on Mon Jul 23 10:29:23
> > > > > > UTC
> > > > > > 2018
> > > > > > ERROR: Required ntpd user is missing, see /usr/src/UPDATING.
> > > > > > *** Error code 1
> > > > > > 
> > > > > > Stop.
> > > > > > make[2]: stopped in /usr/home/osstest/build.125515.build-amd64-
> > > > > > freebsd/freebsd
> > > > > > *** Error code 1
> > > > > > 
> > > > > > Stop.
> > > > > > make[1]: stopped in /usr/home/osstest/build.125515.build-amd64-
> > > > > > freebsd/freebsd
> > > > > > *** Error code 1
> > > > > > 
> > > > > > Stop.
> > > > > > make: stopped in /usr/home/osstest/build.125515.build-amd64-
> > > > > > freebsd/freebsd/release
> > > > > > 
> > > > > > The full build log can be found at:
> > > > > > 
> > > > > > http://logs.test-lab.xenproject.org/osstest/logs/125569/build-amd
> > > > > > 64-f
> > > > > > reebsd/7.ts-freebsd-build.log
> > > > > > 
> > > > > > Note that it's ~100MB.
> > > > > > 
> > > > > > Thanks, Roger.
> > > > > > 
> > > > > If the script is creating a new distribution image from scratch, it
> > > > > should be using -DDB_FROM_SRC on all distrib* and install* make
> > > > > targets, to avoid using (and verifying against) the passwd database
> > > > > on
> > > > > the build system.
> > > > Shouldn't then that be set by default for the ftp release target?
> > > > The sole purpose of that target is to create the sets that go to the
> > > > servers AFAICT.
> > > > 
> > > > Or maybe it's the distributeworld target the one missing the
> > > > DB_FROM_SRC?
> > > > 
> > > > Roger.
> > > > 
> > > 
> > > I don't know anything about the release scripts or how they work.
> > > 
> > > I started down the path of trying to make the build system
> > > automatically set DB_FROM_SRC if DESTDIR is anything other than "/",
> > > but I realized that's wrong too... I occasionally mount an sdcard from
> > > some embedded system on my build machine and update it from a
> > > crossbuild using DESTDIR=/mnt, and in a case like that, using the
> > > passwd database from the system being updated is the right thing to do
> > > and DB_FROM_SRC isn't right (although it would work most of the time
> > > for most people).
> > > 
> > > Right now there's no way to even properly use the passwd data from the
> > > target system, and when I tried to do that, I ran into other bugs. The
> > > only options now are to use the running system even when it's not
> > > what's being installed (clearly wrong) or use DB_FROM_SRC to bypass the
> > > checks, but also bypass using the passwd data from the target system
> > > (but it works okay as long as none of the names/uids < 1024 have been
> > > changed on the target system/image).
> > 
> > But when executing something like the distributeworld target there's

svn commit: r337452 - head

2018-08-08 Thread Roger Pau Monné
Author: royger
Date: Wed Aug  8 07:58:29 2018
New Revision: 337452
URL: https://svnweb.freebsd.org/changeset/base/337452

Log:
  build: skip the database check for the distributeworld target
  
  distributeworld is used to generate install media, so it makes no
  sense to check the host database since the install media can be
  generated from any box, regardless of the version of FreeBSD it's
  running.
  
  Sponsored by: Citrix Systems R
  Reviewed by:  ian, gjb
  Differential revision:https://reviews.freebsd.org/D16507

Modified:
  head/Makefile.inc1

Modified: head/Makefile.inc1
==
--- head/Makefile.inc1  Wed Aug  8 07:32:14 2018(r337451)
+++ head/Makefile.inc1  Wed Aug  8 07:58:29 2018(r337452)
@@ -830,6 +830,13 @@ IMAKE+=__MAKE_SHELL=${INSTALLTMP}/sh
 .else
 IMAKEENV+= PATH=${TMPPATH}:${INSTALLTMP}
 .endif
+
+# When generating install media, do not allow user and group information from
+# the build host to affect the contents of the distribution.
+.if make(distributeworld)
+DB_FROM_SRC=   yes
+.endif
+
 .if defined(DB_FROM_SRC)
 INSTALLFLAGS+= -N ${.CURDIR}/etc
 MTREEFLAGS+=   -N ${.CURDIR}/etc
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r336897 - head/sys/dev/xen/grant_table

2018-07-30 Thread Roger Pau Monné
Author: royger
Date: Mon Jul 30 11:41:51 2018
New Revision: 336897
URL: https://svnweb.freebsd.org/changeset/base/336897

Log:
  xen/grants: fix deadlocks in the free callbacks
  
  This fixes the panic caused by deadlocking when grant-table free
  callbacks are used.
  
  The cause of the recursion is: check_free_callbacks() is always called
  with the lock gnttab_list_lock held. In turn the callback function is
  also called with the lock held. Then when the client uses any of the grant
  reference methods which also attempt the lock the gnttab_list_lock
  mutex from within the free callback a deadlock happens.
  
  Fix this by making the gnttab_list_lock recursive.
  
  Submitted by: Pratyush Yadav 
  Differential Revision:https://reviews.freebsd.org/D16505

Modified:
  head/sys/dev/xen/grant_table/grant_table.c

Modified: head/sys/dev/xen/grant_table/grant_table.c
==
--- head/sys/dev/xen/grant_table/grant_table.c  Mon Jul 30 11:27:51 2018
(r336896)
+++ head/sys/dev/xen/grant_table/grant_table.c  Mon Jul 30 11:41:51 2018
(r336897)
@@ -585,7 +585,7 @@ gnttab_expand(unsigned int req_entries)
return (error);
 }
 
-MTX_SYSINIT(gnttab, _list_lock, "GNTTAB LOCK", MTX_DEF); 
+MTX_SYSINIT(gnttab, _list_lock, "GNTTAB LOCK", MTX_DEF | MTX_RECURSE);
 
 /*-- Private Device Attachment Functions  
*/
 /**
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r336896 - head/sys/dev/xen/blkfront

2018-07-30 Thread Roger Pau Monné
Author: royger
Date: Mon Jul 30 11:27:51 2018
New Revision: 336896
URL: https://svnweb.freebsd.org/changeset/base/336896

Log:
  xen-blkfront: fix memory leak in xbd_connect error path
  
  If gnttab_grant_foreign_access() fails for any of the indirection
  pages, the code breaks out of both the loops without freeing the local
  variable indirectpages, causing a memory leak.
  
  Submitted by: Pratyush Yadav 
  Differential Review:  https://reviews.freebsd.org/D16136

Modified:
  head/sys/dev/xen/blkfront/blkfront.c

Modified: head/sys/dev/xen/blkfront/blkfront.c
==
--- head/sys/dev/xen/blkfront/blkfront.cMon Jul 30 11:15:20 2018
(r336895)
+++ head/sys/dev/xen/blkfront/blkfront.cMon Jul 30 11:27:51 2018
(r336896)
@@ -1333,7 +1333,10 @@ xbd_connect(struct xbd_softc *sc)
if (sc->xbd_max_request_indirectpages > 0) {
indirectpages = contigmalloc(
PAGE_SIZE * sc->xbd_max_request_indirectpages,
-   M_XENBLOCKFRONT, M_ZERO, 0, ~0, PAGE_SIZE, 0);
+   M_XENBLOCKFRONT, M_ZERO | M_NOWAIT, 0, ~0,
+   PAGE_SIZE, 0);
+   if (indirectpages == NULL)
+   sc->xbd_max_request_indirectpages = 0;
} else {
indirectpages = NULL;
}
@@ -1345,8 +1348,12 @@ xbd_connect(struct xbd_softc *sc)
>cm_indirectionrefs[j]))
break;
}
-   if (j < sc->xbd_max_request_indirectpages)
+   if (j < sc->xbd_max_request_indirectpages) {
+   contigfree(indirectpages,
+   PAGE_SIZE * sc->xbd_max_request_indirectpages,
+   M_XENBLOCKFRONT);
break;
+   }
cm->cm_indirectionpages = indirectpages;
xbd_free_command(cm);
}
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r336895 - head/sys/dev/xen/blkfront

2018-07-30 Thread Roger Pau Monné
Author: royger
Date: Mon Jul 30 11:15:20 2018
New Revision: 336895
URL: https://svnweb.freebsd.org/changeset/base/336895

Log:
  xen-blkfront: fix length check
  
  Length is an unsigned integer, so checking against < 0 doesn't make
  sense. While there also make clear that a length of 0 always succeeds.
  
  Submitted by: Pratyush Yadav 
  Differential Review:  https://reviews.freebsd.org/D16045

Modified:
  head/sys/dev/xen/blkfront/blkfront.c

Modified: head/sys/dev/xen/blkfront/blkfront.c
==
--- head/sys/dev/xen/blkfront/blkfront.cMon Jul 30 10:55:02 2018
(r336894)
+++ head/sys/dev/xen/blkfront/blkfront.cMon Jul 30 11:15:20 2018
(r336895)
@@ -602,8 +602,8 @@ xbd_dump(void *arg, void *virtual, vm_offset_t physica
int sbp;
int rc = 0;
 
-   if (length <= 0)
-   return (rc);
+   if (length == 0)
+   return (0);
 
xbd_quiesce(sc);/* All quiet on the western front. */
 
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r336526 - head

2018-07-26 Thread Roger Pau Monné
On Thu, Jul 26, 2018 at 09:05:18AM -0600, Ian Lepore wrote:
> On Thu, 2018-07-26 at 16:54 +0200, Roger Pau Monné wrote:
> > On Thu, Jul 26, 2018 at 08:49:12AM -0600, Ian Lepore wrote:
> > > 
> > > On Thu, 2018-07-26 at 15:58 +0200, Roger Pau Monné wrote:
> > > > 
> > > > On Fri, Jul 20, 2018 at 12:44:04AM +, Ian Lepore wrote:
> > > > > 
> > > > > 
> > > > > Author: ian
> > > > > Date: Fri Jul 20 00:44:04 2018
> > > > > New Revision: 336526
> > > > > URL: https://svnweb.freebsd.org/changeset/base/336526
> > > > > 
> > > > > Log:
> > > > >   Add ntpd to the list of users/groups to check before
> > > > > installing.
> > > > The Xen CI loop is getting this when trying to create dist media
> > > > for HEAD FreeBSD (`make -C release ftp`):
> > > > 
> > > > + LC_ALL=C
> > > > + export LC_ALL
> > > > +
> > > > PATH=/usr/lib/ccache:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbi
> > > > n:/u
> > > > sr/local/bin:/root/bin:/usr/lib/git-core
> > > > + http_proxy=http://cache:3128/
> > > > + export http_proxy
> > > > + https_proxy=http://cache:3128/
> > > > + export https_proxy
> > > > + exec
> > > > + cd /home/osstest/build.125515.build-amd64-freebsd
> > > > + rm -f build-ok-stamp
> > > > + cd freebsd
> > > > + export 'MAKEOBJDIRPREFIX=/home/osstest/build.125515.build-
> > > > amd64-
> > > > freebsd/obj'
> > > > + export 'TARGET=amd64'
> > > > + make -C release ftp -DWITHOUT_AUTO_OBJ
> > > > + tee ../release-ftp-log
> > > > mkdir -p dist
> > > > cd /usr/home/osstest/build.125515.build-amd64-
> > > > freebsd/freebsd/release/.. && make TARGET_ARCH=amd64 TARGET=amd64
> > > > distributeworld DISTDIR=/usr/home/osstest/build.125515.build-
> > > > amd64-
> > > > freebsd/freebsd/release/dist
> > > > make[2]: "/usr/home/osstest/build.125515.build-amd64-
> > > > freebsd/obj/usr/home/osstest/build.125515.build-amd64-
> > > > freebsd/freebsd/amd64.amd64/toolchain-metadata.mk" line 1: Using
> > > > cached toolchain metadata from build at  on Mon Jul 23 10:29:23
> > > > UTC
> > > > 2018
> > > > ERROR: Required ntpd user is missing, see /usr/src/UPDATING.
> > > > *** Error code 1
> > > > 
> > > > Stop.
> > > > make[2]: stopped in /usr/home/osstest/build.125515.build-amd64-
> > > > freebsd/freebsd
> > > > *** Error code 1
> > > > 
> > > > Stop.
> > > > make[1]: stopped in /usr/home/osstest/build.125515.build-amd64-
> > > > freebsd/freebsd
> > > > *** Error code 1
> > > > 
> > > > Stop.
> > > > make: stopped in /usr/home/osstest/build.125515.build-amd64-
> > > > freebsd/freebsd/release
> > > > 
> > > > The full build log can be found at:
> > > > 
> > > > http://logs.test-lab.xenproject.org/osstest/logs/125569/build-amd
> > > > 64-f
> > > > reebsd/7.ts-freebsd-build.log
> > > > 
> > > > Note that it's ~100MB.
> > > > 
> > > > Thanks, Roger.
> > > > 
> > > If the script is creating a new distribution image from scratch, it
> > > should be using -DDB_FROM_SRC on all distrib* and install* make
> > > targets, to avoid using (and verifying against) the passwd database
> > > on
> > > the build system.
> > Shouldn't then that be set by default for the ftp release target?
> > The sole purpose of that target is to create the sets that go to the
> > servers AFAICT.
> > 
> > Or maybe it's the distributeworld target the one missing the
> > DB_FROM_SRC?
> > 
> > Roger.
> > 
> 
> I don't know anything about the release scripts or how they work.
> 
> I started down the path of trying to make the build system
> automatically set DB_FROM_SRC if DESTDIR is anything other than "/",
> but I realized that's wrong too... I occasionally mount an sdcard from
> some embedded system on my build machine and update it from a
> crossbuild using DESTDIR=/mnt, and in a case like that, using the
> passwd database from the system being updated is the right thing to do
> and DB_FROM_SRC isn't right (although it would work most of the time
> for most people).
> 
> Right now there's no way to even properly use the passwd data from the
> target system, and when I tried to do that, I ran into other bugs. The
> only options now are to use the running system even when it's not
> what's being installed (clearly wrong) or use DB_FROM_SRC to bypass the
> checks, but also bypass using the passwd data from the target system
> (but it works okay as long as none of the names/uids < 1024 have been
> changed on the target system/image).

But when executing something like the distributeworld target there's
nothing to check. You cannot check against the current DB, and there's
no destination DB since you are just generating install sets. Hence I
think that at least for distributeworld and maybe other targets
DB_FROM_SRC should be set by default in order to restore previous
behavior.

Thanks, Roger.
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r336526 - head

2018-07-26 Thread Roger Pau Monné
On Thu, Jul 26, 2018 at 08:49:12AM -0600, Ian Lepore wrote:
> On Thu, 2018-07-26 at 15:58 +0200, Roger Pau Monné wrote:
> > On Fri, Jul 20, 2018 at 12:44:04AM +, Ian Lepore wrote:
> > > 
> > > Author: ian
> > > Date: Fri Jul 20 00:44:04 2018
> > > New Revision: 336526
> > > URL: https://svnweb.freebsd.org/changeset/base/336526
> > > 
> > > Log:
> > >   Add ntpd to the list of users/groups to check before installing.
> > The Xen CI loop is getting this when trying to create dist media
> > for HEAD FreeBSD (`make -C release ftp`):
> > 
> > + LC_ALL=C
> > + export LC_ALL
> > +
> > PATH=/usr/lib/ccache:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/u
> > sr/local/bin:/root/bin:/usr/lib/git-core
> > + http_proxy=http://cache:3128/
> > + export http_proxy
> > + https_proxy=http://cache:3128/
> > + export https_proxy
> > + exec
> > + cd /home/osstest/build.125515.build-amd64-freebsd
> > + rm -f build-ok-stamp
> > + cd freebsd
> > + export 'MAKEOBJDIRPREFIX=/home/osstest/build.125515.build-amd64-
> > freebsd/obj'
> > + export 'TARGET=amd64'
> > + make -C release ftp -DWITHOUT_AUTO_OBJ
> > + tee ../release-ftp-log
> > mkdir -p dist
> > cd /usr/home/osstest/build.125515.build-amd64-
> > freebsd/freebsd/release/.. && make TARGET_ARCH=amd64 TARGET=amd64
> > distributeworld DISTDIR=/usr/home/osstest/build.125515.build-amd64-
> > freebsd/freebsd/release/dist
> > make[2]: "/usr/home/osstest/build.125515.build-amd64-
> > freebsd/obj/usr/home/osstest/build.125515.build-amd64-
> > freebsd/freebsd/amd64.amd64/toolchain-metadata.mk" line 1: Using
> > cached toolchain metadata from build at  on Mon Jul 23 10:29:23 UTC
> > 2018
> > ERROR: Required ntpd user is missing, see /usr/src/UPDATING.
> > *** Error code 1
> > 
> > Stop.
> > make[2]: stopped in /usr/home/osstest/build.125515.build-amd64-
> > freebsd/freebsd
> > *** Error code 1
> > 
> > Stop.
> > make[1]: stopped in /usr/home/osstest/build.125515.build-amd64-
> > freebsd/freebsd
> > *** Error code 1
> > 
> > Stop.
> > make: stopped in /usr/home/osstest/build.125515.build-amd64-
> > freebsd/freebsd/release
> > 
> > The full build log can be found at:
> > 
> > http://logs.test-lab.xenproject.org/osstest/logs/125569/build-amd64-f
> > reebsd/7.ts-freebsd-build.log
> > 
> > Note that it's ~100MB.
> > 
> > Thanks, Roger.
> > 
> 
> If the script is creating a new distribution image from scratch, it
> should be using -DDB_FROM_SRC on all distrib* and install* make
> targets, to avoid using (and verifying against) the passwd database on
> the build system.

Shouldn't then that be set by default for the ftp release target?
The sole purpose of that target is to create the sets that go to the
servers AFAICT.

Or maybe it's the distributeworld target the one missing the
DB_FROM_SRC?

Roger.
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r336526 - head

2018-07-26 Thread Roger Pau Monné
On Fri, Jul 20, 2018 at 12:44:04AM +, Ian Lepore wrote:
> Author: ian
> Date: Fri Jul 20 00:44:04 2018
> New Revision: 336526
> URL: https://svnweb.freebsd.org/changeset/base/336526
> 
> Log:
>   Add ntpd to the list of users/groups to check before installing.

The Xen CI loop is getting this when trying to create dist media
for HEAD FreeBSD (`make -C release ftp`):

+ LC_ALL=C
+ export LC_ALL
+ 
PATH=/usr/lib/ccache:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/root/bin:/usr/lib/git-core
+ http_proxy=http://cache:3128/
+ export http_proxy
+ https_proxy=http://cache:3128/
+ export https_proxy
+ exec
+ cd /home/osstest/build.125515.build-amd64-freebsd
+ rm -f build-ok-stamp
+ cd freebsd
+ export 'MAKEOBJDIRPREFIX=/home/osstest/build.125515.build-amd64-freebsd/obj'
+ export 'TARGET=amd64'
+ make -C release ftp -DWITHOUT_AUTO_OBJ
+ tee ../release-ftp-log
mkdir -p dist
cd /usr/home/osstest/build.125515.build-amd64-freebsd/freebsd/release/.. && 
make TARGET_ARCH=amd64 TARGET=amd64 distributeworld 
DISTDIR=/usr/home/osstest/build.125515.build-amd64-freebsd/freebsd/release/dist
make[2]: 
"/usr/home/osstest/build.125515.build-amd64-freebsd/obj/usr/home/osstest/build.125515.build-amd64-freebsd/freebsd/amd64.amd64/toolchain-metadata.mk"
 line 1: Using cached toolchain metadata from build at  on Mon Jul 23 10:29:23 
UTC 2018
ERROR: Required ntpd user is missing, see /usr/src/UPDATING.
*** Error code 1

Stop.
make[2]: stopped in /usr/home/osstest/build.125515.build-amd64-freebsd/freebsd
*** Error code 1

Stop.
make[1]: stopped in /usr/home/osstest/build.125515.build-amd64-freebsd/freebsd
*** Error code 1

Stop.
make: stopped in 
/usr/home/osstest/build.125515.build-amd64-freebsd/freebsd/release

The full build log can be found at:

http://logs.test-lab.xenproject.org/osstest/logs/125569/build-amd64-freebsd/7.ts-freebsd-build.log

Note that it's ~100MB.

Thanks, Roger.
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r336475 - head/sys/xen/interface/arch-x86/hvm

2018-07-19 Thread Roger Pau Monné
On Thu, Jul 19, 2018 at 07:02:08AM -0700, Rodney W. Grimes wrote:
> > Author: royger
> > Date: Thu Jul 19 10:14:52 2018
> > New Revision: 336475
> > URL: https://svnweb.freebsd.org/changeset/base/336475
> > 
> > Log:
> >   xen: add missing file from r336474
> > 
> > Added:
> >   head/sys/xen/interface/arch-x86/hvm/start_info.h   (contents, props 
> > changed)
> > 
> > Added: head/sys/xen/interface/arch-x86/hvm/start_info.h
> > ==
> > --- /dev/null   00:00:00 1970   (empty, because file is newly added)
> > +++ head/sys/xen/interface/arch-x86/hvm/start_info.hThu Jul 19 
> > 10:14:52 2018(r336475)
> > @@ -0,0 +1,159 @@
> > +/*
> > + * Permission is hereby granted, free of charge, to any person obtaining a 
> > copy
> > + * of this software and associated documentation files (the "Software"), to
> > + * deal in the Software without restriction, including without limitation 
> > the
> > + * rights to use, copy, modify, merge, publish, distribute, sublicense, 
> > and/or
> > + * sell copies of the Software, and to permit persons to whom the Software 
> > is
> > + * furnished to do so, subject to the following conditions:
> > + *
> > + * The above copyright notice and this permission notice shall be included 
> > in
> 
> There is no copyright above.
> 
> > + * all copies or substantial portions of the Software.
> > + *
> > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS 
> > OR
> > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL 
> > THE
> > + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> > + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> > + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> > + * DEALINGS IN THE SOFTWARE.
> > + *
> > + * Copyright (c) 2016, Citrix Systems, Inc.
> 
> The copyright is below.

This is a verbatim copy of:

http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/include/public/arch-x86/hvm/start_info.h

And I'm not intending to modify it locally in the FreeBSD tree, but
patches can be submitted upstream :).

Roger.
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r336475 - head/sys/xen/interface/arch-x86/hvm

2018-07-19 Thread Roger Pau Monné
Author: royger
Date: Thu Jul 19 10:14:52 2018
New Revision: 336475
URL: https://svnweb.freebsd.org/changeset/base/336475

Log:
  xen: add missing file from r336474

Added:
  head/sys/xen/interface/arch-x86/hvm/start_info.h   (contents, props changed)

Added: head/sys/xen/interface/arch-x86/hvm/start_info.h
==
--- /dev/null   00:00:00 1970   (empty, because file is newly added)
+++ head/sys/xen/interface/arch-x86/hvm/start_info.hThu Jul 19 10:14:52 
2018(r336475)
@@ -0,0 +1,159 @@
+/*
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
+ * deal in the Software without restriction, including without limitation the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Copyright (c) 2016, Citrix Systems, Inc.
+ */
+
+#ifndef __XEN_PUBLIC_ARCH_X86_HVM_START_INFO_H__
+#define __XEN_PUBLIC_ARCH_X86_HVM_START_INFO_H__
+
+/*
+ * Start of day structure passed to PVH guests and to HVM guests in %ebx.
+ *
+ * NOTE: nothing will be loaded at physical address 0, so a 0 value in any
+ * of the address fields should be treated as not present.
+ *
+ *  0 ++
+ *| magic  | Contains the magic value XEN_HVM_START_MAGIC_VALUE
+ *|| ("xEn3" with the 0x80 bit of the "E" set).
+ *  4 ++
+ *| version| Version of this structure. Current version is 1. New
+ *|| versions are guaranteed to be backwards-compatible.
+ *  8 ++
+ *| flags  | SIF_xxx flags.
+ * 12 ++
+ *| nr_modules | Number of modules passed to the kernel.
+ * 16 ++
+ *| modlist_paddr  | Physical address of an array of modules
+ *|| (layout of the structure below).
+ * 24 ++
+ *| cmdline_paddr  | Physical address of the command line,
+ *|| a zero-terminated ASCII string.
+ * 32 ++
+ *| rsdp_paddr | Physical address of the RSDP ACPI data structure.
+ * 40 ++
+ *| memmap_paddr   | Physical address of the (optional) memory map. Only
+ *|| present in version 1 and newer of the structure.
+ * 48 ++
+ *| memmap_entries | Number of entries in the memory map table. Zero
+ *|| if there is no memory map being provided. Only
+ *|| present in version 1 and newer of the structure.
+ * 52 ++
+ *| reserved   | Version 1 and newer only.
+ * 56 ++
+ *
+ * The layout of each entry in the module structure is the following:
+ *
+ *  0 ++
+ *| paddr  | Physical address of the module.
+ *  8 ++
+ *| size   | Size of the module in bytes.
+ * 16 ++
+ *| cmdline_paddr  | Physical address of the command line,
+ *|| a zero-terminated ASCII string.
+ * 24 ++
+ *| reserved   |
+ * 32 ++
+ *
+ * The layout of each entry in the memory map table is as follows:
+ *
+ *  0 ++
+ *| addr   | Base address
+ *  8 ++
+ *| size   | Size of mapping in bytes
+ * 16 ++
+ *| type   | Type of mapping as defined between the hypervisor
+ *|| and guest. See XEN_HVM_MEMMAP_TYPE_* values below.
+ * 20 +|
+ *| reserved   |
+ * 24 ++
+ *
+ * The address and sizes are always a 64bit little endian unsigned integer.
+ *
+ * NB: Xen on x86 will always try to place all the data below the 4GiB
+ * boundary.
+ *
+ * Version numbers of the hvm_start_info structure have evolved like this:
+ *
+ * Version 0:  Initial implementation.
+ *
+ * Version 1:  Added the memmap_paddr/memmap_entries fields (plus 4 bytes of
+ * padding) to the end of the hvm_start_info struct. These new
+ * fields can be used to pass a memory map to the guest. The
+ * memory map is 

svn commit: r336474 - in head/sys: amd64/amd64 x86/xen xen

2018-07-19 Thread Roger Pau Monné
Author: royger
Date: Thu Jul 19 08:44:52 2018
New Revision: 336474
URL: https://svnweb.freebsd.org/changeset/base/336474

Log:
  xen: implement early init helper for PVHv2
  
  In order to setup an initial environment and jump into the generic
  hammer_time initialization function. Some of the code is shared with
  PVHv1, while other code is PVHv2 specific.
  
  This allows booting FreeBSD as a PVHv2 DomU and Dom0.
  
  Sponsored by: Citrix Systems R

Modified:
  head/sys/amd64/amd64/xen-locore.S
  head/sys/x86/xen/hvm.c
  head/sys/x86/xen/pv.c
  head/sys/xen/hvm.h

Modified: head/sys/amd64/amd64/xen-locore.S
==
--- head/sys/amd64/amd64/xen-locore.S   Thu Jul 19 08:13:41 2018
(r336473)
+++ head/sys/amd64/amd64/xen-locore.S   Thu Jul 19 08:44:52 2018
(r336474)
@@ -87,7 +87,7 @@ NON_GPROF_ENTRY(xen_start)
xorl%ebp, %ebp
 
/* u_int64_t hammer_time_xen(start_info_t *si, u_int64_t xenstack); */
-   callhammer_time_xen
+   callhammer_time_xen_legacy
movq%rax, %rsp  /* set up kstack for mi_startup() */
callmi_startup  /* autoconfiguration, mountroot etc */
 

Modified: head/sys/x86/xen/hvm.c
==
--- head/sys/x86/xen/hvm.c  Thu Jul 19 08:13:41 2018(r336473)
+++ head/sys/x86/xen/hvm.c  Thu Jul 19 08:44:52 2018(r336474)
@@ -82,6 +82,12 @@ static MALLOC_DEFINE(M_XENHVM, "xen_hvm", "Xen HVM PV 
  */
 int xen_vector_callback_enabled;
 
+/**
+ * Start info flags. ATM this only used to store the initial domain flag for
+ * PVHv2, and it's always empty for HVM guests.
+ */
+uint32_t hvm_start_flags;
+
 /*--- Per-CPU Data 
---*/
 DPCPU_DEFINE(struct vcpu_info, vcpu_local_info);
 DPCPU_DEFINE(struct vcpu_info *, vcpu_info);
@@ -469,7 +475,7 @@ static uint32_t
 hvm_get_start_flags(void)
 {
 
-   return (0);
+   return (hvm_start_flags);
 }
 
 struct hypervisor_info hypervisor_info = {

Modified: head/sys/x86/xen/pv.c
==
--- head/sys/x86/xen/pv.c   Thu Jul 19 08:13:41 2018(r336473)
+++ head/sys/x86/xen/pv.c   Thu Jul 19 08:44:52 2018(r336474)
@@ -58,6 +58,7 @@ __FBSDID("$FreeBSD$");
 #include 
 #include 
 
+#include 
 #include 
 #include 
 #include 
@@ -67,11 +68,13 @@ __FBSDID("$FreeBSD$");
 #include 
 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 
+#include 
 #include 
 
 #include 
@@ -83,13 +86,15 @@ __FBSDID("$FreeBSD$");
 /* Native initial function */
 extern u_int64_t hammer_time(u_int64_t, u_int64_t);
 /* Xen initial function */
-uint64_t hammer_time_xen(start_info_t *, uint64_t);
+uint64_t hammer_time_xen_legacy(start_info_t *, uint64_t);
+uint64_t hammer_time_xen(vm_paddr_t);
 
 #define MAX_E820_ENTRIES   128
 
 /*--- Forward Declarations 
---*/
-static caddr_t xen_pv_parse_preload_data(u_int64_t);
-static void xen_pv_parse_memmap(caddr_t, vm_paddr_t *, int *);
+static caddr_t xen_legacy_pvh_parse_preload_data(uint64_t);
+static caddr_t xen_pvh_parse_preload_data(uint64_t);
+static void xen_pvh_parse_memmap(caddr_t, vm_paddr_t *, int *);
 
 #ifdef SMP
 static int xen_pv_start_all_aps(void);
@@ -112,20 +117,33 @@ extern uint32_t end;
 
 /* Global Data 
---*/
 /* Xen init_ops implementation. */
-struct init_ops xen_init_ops = {
-   .parse_preload_data = xen_pv_parse_preload_data,
+struct init_ops xen_legacy_init_ops = {
+   .parse_preload_data = xen_legacy_pvh_parse_preload_data,
.early_clock_source_init= xen_clock_init,
.early_delay= xen_delay,
-   .parse_memmap   = xen_pv_parse_memmap,
+   .parse_memmap   = xen_pvh_parse_memmap,
 #ifdef SMP
.start_all_aps  = xen_pv_start_all_aps,
 #endif
.msi_init   = xen_msi_init,
 };
 
+struct init_ops xen_pvh_init_ops = {
+   .parse_preload_data = xen_pvh_parse_preload_data,
+   .early_clock_source_init= xen_clock_init,
+   .early_delay= xen_delay,
+   .parse_memmap   = xen_pvh_parse_memmap,
+#ifdef SMP
+   .mp_bootaddress = mp_bootaddress,
+   .start_all_aps  = native_start_all_aps,
+#endif
+   .msi_init   = msi_init,
+};
+
 static struct bios_smap xen_smap[MAX_E820_ENTRIES];
 
 static start_info_t *legacy_start_info;
+static struct hvm_start_info *start_info;
 
 /*--- Legacy PVH start_info accessors 
*/
 static vm_paddr_t
@@ -179,7 +197,7 @@ struct hypervisor_info legacy_info = 

svn commit: r336473 - in head/sys: x86/xen xen

2018-07-19 Thread Roger Pau Monné
Author: royger
Date: Thu Jul 19 08:13:41 2018
New Revision: 336473
URL: https://svnweb.freebsd.org/changeset/base/336473

Log:
  xen: allow very early initialization of the hypercall page
  
  Allow the hypercall page to be initialized very early, even before
  vtophys is functional. Also make the function global so it can be
  called by other files.
  
  This will be needed in order to perform the early bringup on PVHv2
  guests.
  
  Sponsored by: Citrix Systems R

Modified:
  head/sys/x86/xen/hvm.c
  head/sys/xen/hvm.h

Modified: head/sys/x86/xen/hvm.c
==
--- head/sys/x86/xen/hvm.c  Thu Jul 19 08:00:52 2018(r336472)
+++ head/sys/x86/xen/hvm.c  Thu Jul 19 08:13:41 2018(r336473)
@@ -40,6 +40,7 @@ __FBSDID("$FreeBSD$");
 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -63,13 +64,6 @@ __FBSDID("$FreeBSD$");
 /*--- Forward Declarations 
---*/
 static void xen_hvm_cpu_init(void);
 
-/* Local Types 
---*/
-enum xen_hvm_init_type {
-   XEN_HVM_INIT_COLD,
-   XEN_HVM_INIT_CANCELLED_SUSPEND,
-   XEN_HVM_INIT_RESUME
-};
-
 /* Global Data 
---*/
 enum xen_domain_type xen_domain_type = XEN_NATIVE;
 
@@ -119,51 +113,67 @@ xen_hvm_cpuid_base(void)
return (0);
 }
 
+static void
+hypervisor_quirks(unsigned int major, unsigned int minor)
+{
+#ifdef SMP
+   if (((major < 4) || (major == 4 && minor <= 5)) &&
+   msix_disable_migration == -1) {
+   /*
+* Xen hypervisors prior to 4.6.0 do not properly
+* handle updates to enabled MSI-X table entries,
+* so disable MSI-X interrupt migration in that
+* case.
+*/
+   if (bootverbose)
+   printf(
+"Disabling MSI-X interrupt migration due to Xen hypervisor bug.\n"
+"Set machdep.msix_disable_migration=0 to forcefully enable it.\n");
+   msix_disable_migration = 1;
+   }
+#endif
+}
+
+static void
+hypervisor_version(void)
+{
+   uint32_t regs[4];
+   int major, minor;
+
+   do_cpuid(cpuid_base + 1, regs);
+
+   major = regs[0] >> 16;
+   minor = regs[0] & 0x;
+   printf("XEN: Hypervisor version %d.%d detected.\n", major, minor);
+
+   hypervisor_quirks(major, minor);
+}
+
 /*
  * Allocate and fill in the hypcall page.
  */
-static int
+int
 xen_hvm_init_hypercall_stubs(enum xen_hvm_init_type init_type)
 {
uint32_t regs[4];
 
-   if (xen_pv_domain()) {
-   /* hypercall page is already set in the PV case */
-   return (0);
+   if (xen_domain() && init_type == XEN_HVM_INIT_LATE) {
+   /*
+* If the domain type is already set we can assume that the
+* hypercall page has been populated too, so just print the
+* version (and apply any quirks) and exit.
+*/
+   hypervisor_version();
+   return 0;
}
 
cpuid_base = xen_hvm_cpuid_base();
if (cpuid_base == 0)
return (ENXIO);
 
-   if (init_type == XEN_HVM_INIT_COLD) {
-   int major, minor;
+   if (init_type == XEN_HVM_INIT_LATE)
+   hypervisor_version();
 
-   do_cpuid(cpuid_base + 1, regs);
-
-   major = regs[0] >> 16;
-   minor = regs[0] & 0x;
-   printf("XEN: Hypervisor version %d.%d detected.\n", major,
-   minor);
-
-#ifdef SMP
-   if (((major < 4) || (major == 4 && minor <= 5)) &&
-   msix_disable_migration == -1) {
-   /*
-* Xen hypervisors prior to 4.6.0 do not properly
-* handle updates to enabled MSI-X table entries,
-* so disable MSI-X interrupt migration in that
-* case.
-*/
-   if (bootverbose)
-   printf(
-"Disabling MSI-X interrupt migration due to Xen hypervisor bug.\n"
-"Set machdep.msix_disable_migration=0 to forcefully enable it.\n");
-   msix_disable_migration = 1;
-   }
-#endif
-   }
-
/*
 * Find the hypercall pages.
 */
@@ -171,7 +181,9 @@ xen_hvm_init_hypercall_stubs(enum xen_hvm_init_type in
if (regs[0] != 1)
return (EINVAL);
 
-   wrmsr(regs[1], vtophys(_page));
+   wrmsr(regs[1], (init_type == XEN_HVM_INIT_EARLY)
+   ? ((vm_paddr_t)_page - KERNBASE)
+   : vtophys(_page));
 
return (0);
 }
@@ -307,7 +319,7 @@ xen_hvm_init(enum xen_hvm_init_type init_type)
error = xen_hvm_init_hypercall_stubs(init_type);
 
switch (init_type) {
- 

svn commit: r336472 - head/sys/dev/xen/pvcpu

2018-07-19 Thread Roger Pau Monné
Author: royger
Date: Thu Jul 19 08:00:52 2018
New Revision: 336472
URL: https://svnweb.freebsd.org/changeset/base/336472

Log:
  xen: attach the PV CPU if no CPU device is present
  
  When booted as PVHv2, there's no ACPI CPU object, so attach the PV CPU
  device in order to take it's place.
  
  This is required in case some device or driver tries to poke at the
  PCPU device field.
  
  Sponsored by: Citrix Systems R

Modified:
  head/sys/dev/xen/pvcpu/pvcpu.c

Modified: head/sys/dev/xen/pvcpu/pvcpu.c
==
--- head/sys/dev/xen/pvcpu/pvcpu.c  Thu Jul 19 07:58:24 2018
(r336471)
+++ head/sys/dev/xen/pvcpu/pvcpu.c  Thu Jul 19 08:00:52 2018
(r336472)
@@ -49,8 +49,8 @@ xenpvcpu_identify(driver_t *driver, device_t parent)
 {
int i;
 
-   /* Only attach to PV guests, HVM guests use the ACPI CPU devices */
-   if (!xen_pv_domain())
+   /* Only attach in case the per-CPU device is not set. */
+   if (!xen_domain() || PCPU_GET(device) != NULL)
return;
 
CPU_FOREACH(i) {
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r336471 - head/sys/dev/xen/console

2018-07-19 Thread Roger Pau Monné
Author: royger
Date: Thu Jul 19 07:58:24 2018
New Revision: 336471
URL: https://svnweb.freebsd.org/changeset/base/336471

Log:
  xen: do not limit PV console usage to PV guests
  
  The Xen PV console is also available to HVM and PVHv2 guests, so don't
  limit the console usage to PV guests only.
  
  Sponsored by: Citrix Systems R

Modified:
  head/sys/dev/xen/console/xen_console.c

Modified: head/sys/dev/xen/console/xen_console.c
==
--- head/sys/dev/xen/console/xen_console.c  Thu Jul 19 07:54:45 2018
(r336470)
+++ head/sys/dev/xen/console/xen_console.c  Thu Jul 19 07:58:24 2018
(r336471)
@@ -397,7 +397,7 @@ xencons_early_init(void)
 
mtx_init(_cons.mtx, "XCONS LOCK", NULL, MTX_SPIN);
 
-   if (xen_initial_domain())
+   if (xen_get_console_evtchn() == 0)
main_cons.ops = _hypervisor_ops;
else
main_cons.ops = _ring_ops;
@@ -586,7 +586,7 @@ static void
 xencons_cnprobe(struct consdev *cp)
 {
 
-   if (!xen_pv_domain())
+   if (!xen_domain())
return;
 
cp->cn_pri = CN_REMOTE;
@@ -701,13 +701,8 @@ xencons_identify(driver_t *driver, device_t parent)
 {
device_t child;
 
-#if defined(__arm__) || defined(__aarch64__)
-   if (!xen_domain())
+   if (main_cons.ops == NULL)
return;
-#else
-   if (!xen_pv_domain())
-   return;
-#endif
 
child = BUS_ADD_CHILD(parent, 0, driver_name, 0);
 }
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r336470 - in head/sys: dev/xen/balloon dev/xen/console dev/xen/xenstore x86/xen xen xen/xenstore

2018-07-19 Thread Roger Pau Monné
Author: royger
Date: Thu Jul 19 07:54:45 2018
New Revision: 336470
URL: https://svnweb.freebsd.org/changeset/base/336470

Log:
  xen: remove direct usage of HYPERVISOR_start_info
  
  HYPERVISOR_start_info is only available to PV and PVHv1 guests, HVM
  and PVHv2 guests get this data from HVM parameters that are fetched
  using a hypercall.
  
  Instead provide a set of helper functions that should be used to fetch
  this data. The helper functions have different implementations
  depending on whether FreeBSD is running as PVHv1 or HVM/PVHv2 guest
  type.
  
  This helps to cleanup generic Xen code by removing quite a lot of
  xen_pv_domain and xen_hvm_domain macro usages.
  
  Sponsored by: Citrix Systems R

Modified:
  head/sys/dev/xen/balloon/balloon.c
  head/sys/dev/xen/console/xen_console.c
  head/sys/dev/xen/xenstore/xenstore.c
  head/sys/dev/xen/xenstore/xenstored_dev.c
  head/sys/x86/xen/hvm.c
  head/sys/x86/xen/pv.c
  head/sys/xen/xen-os.h
  head/sys/xen/xenstore/xenstorevar.h

Modified: head/sys/dev/xen/balloon/balloon.c
==
--- head/sys/dev/xen/balloon/balloon.c  Thu Jul 19 07:39:35 2018
(r336469)
+++ head/sys/dev/xen/balloon/balloon.c  Thu Jul 19 07:54:45 2018
(r336470)
@@ -382,8 +382,7 @@ xenballoon_attach(device_t dev)
 
mtx_init(_mutex, "balloon_mutex", NULL, MTX_DEF);
 
-   bs.current_pages = xen_pv_domain() ?
-   HYPERVISOR_start_info->nr_pages : realmem;
+   bs.current_pages = realmem;
bs.target_pages  = bs.current_pages;
bs.balloon_low   = 0;
bs.balloon_high  = 0;

Modified: head/sys/dev/xen/console/xen_console.c
==
--- head/sys/dev/xen/console/xen_console.c  Thu Jul 19 07:39:35 2018
(r336469)
+++ head/sys/dev/xen/console/xen_console.c  Thu Jul 19 07:54:45 2018
(r336470)
@@ -46,6 +46,9 @@ __FBSDID("$FreeBSD$");
 
 #include 
 
+#include 
+#include 
+
 #include 
 #include 
 #include 
@@ -129,12 +132,6 @@ static struct xencons_priv main_cons;
 
 #define XC_POLLTIME(hz/10)
 
-/*
- * Virtual address of the shared console page (only for PV guest)
- * TODO: Introduce a function to set it
- */
-char *console_page;
-
 /*- Debug function --*/
 struct putchar_arg {
char*buf;
@@ -273,9 +270,9 @@ static const struct xencons_ops xencons_hypervisor_ops
 static void
 xencons_early_init_ring(struct xencons_priv *cons)
 {
-   /* The shared page for PV is already mapped by the boot code */
-   cons->intf = (struct xencons_interface *)console_page;
-   cons->evtchn = HYPERVISOR_start_info->console.domU.evtchn;
+   cons->intf = pmap_mapdev_attr(ptoa(xen_get_console_mfn()), PAGE_SIZE,
+   PAT_WRITE_BACK);
+   cons->evtchn = xen_get_console_evtchn();
 }
 
 static int

Modified: head/sys/dev/xen/xenstore/xenstore.c
==
--- head/sys/dev/xen/xenstore/xenstore.cThu Jul 19 07:39:35 2018
(r336469)
+++ head/sys/dev/xen/xenstore/xenstore.cThu Jul 19 07:54:45 2018
(r336470)
@@ -115,7 +115,7 @@ MALLOC_DEFINE(M_XENSTORE, "xenstore", "XenStore data a
  * to get the guest frame number for the shared page and then map it
  * into kva.  See xs_init() for details.
  */
-struct xenstore_domain_interface *xen_store;
+static struct xenstore_domain_interface *xen_store;
 
 /*-- Private Data Structures */
 
@@ -1103,38 +1103,30 @@ xs_attach(device_t dev)
struct proc *p;
 
xs.initialized = false;
-   if (xen_hvm_domain()) {
-   xs.evtchn = hvm_get_parameter(HVM_PARAM_STORE_EVTCHN);
-   xs.gpfn = hvm_get_parameter(HVM_PARAM_STORE_PFN);
-   xen_store = pmap_mapdev(xs.gpfn * PAGE_SIZE, PAGE_SIZE);
-   xs.initialized = true;
-   } else if (xen_pv_domain()) {
-   if (HYPERVISOR_start_info->store_evtchn == 0) {
-   struct evtchn_alloc_unbound alloc_unbound;
+   xs.evtchn = xen_get_xenstore_evtchn();
+   if (xs.evtchn == 0) {
+   struct evtchn_alloc_unbound alloc_unbound;
 
-   /* Allocate a local event channel for xenstore */
-   alloc_unbound.dom = DOMID_SELF;
-   alloc_unbound.remote_dom = DOMID_SELF;
-   error = HYPERVISOR_event_channel_op(
-   EVTCHNOP_alloc_unbound, _unbound);
-   if (error != 0)
-   panic(
-  "unable to alloc event channel for Dom0: %d",
-   error);
+   /* Allocate a local event channel for xenstore */
+   alloc_unbound.dom = DOMID_SELF;
+   

svn commit: r336469 - in head/sys: amd64/amd64 xen/interface

2018-07-19 Thread Roger Pau Monné
Author: royger
Date: Thu Jul 19 07:39:35 2018
New Revision: 336469
URL: https://svnweb.freebsd.org/changeset/base/336469

Log:
  xen: add PVHv2 entry point
  
  The PVHv2 entry point is fairly similar to the multiboot1 one. The
  kernel is started in protected mode with paging disabled. More
  information about the exact BSP state can be found in the pvh.markdown
  document on the Xen tree.
  
  This entry point is going to be joined with the native entry point at
  hammer_time, and in order to do so the BSP needs to be bootstrapped
  into long mode with the same set of page tables as used on bare metal.
  
  Sponsored by: Citrix Systems R

Modified:
  head/sys/amd64/amd64/xen-locore.S
  head/sys/xen/interface/elfnote.h

Modified: head/sys/amd64/amd64/xen-locore.S
==
--- head/sys/amd64/amd64/xen-locore.S   Thu Jul 19 07:30:18 2018
(r336468)
+++ head/sys/amd64/amd64/xen-locore.S   Thu Jul 19 07:39:35 2018
(r336469)
@@ -42,6 +42,12 @@
 
 #include "assym.inc"
 
+#defineVTOP(x) ((x) - KERNBASE)
+#defineENTRY_SIZE  8 /* sizeof(uint64_t) */
+
+#defineGDT_CODE0x08
+#defineGDT_DATA0x10
+
 .section __xen_guest
ELFNOTE(Xen, XEN_ELFNOTE_GUEST_OS,   .asciz, "FreeBSD")
ELFNOTE(Xen, XEN_ELFNOTE_GUEST_VERSION,  .asciz, 
__XSTRING(__FreeBSD_version))
@@ -57,6 +63,8 @@
ELFNOTE(Xen, XEN_ELFNOTE_LOADER, .asciz, "generic")
ELFNOTE(Xen, XEN_ELFNOTE_SUSPEND_CANCEL, .long,  0)
ELFNOTE(Xen, XEN_ELFNOTE_BSD_SYMTAB, .asciz, "yes")
+   /* For PVHv2 support. */
+   ELFNOTE(Xen, XEN_ELFNOTE_PHYS32_ENTRY,   .long,  VTOP(xen_start32))
 
.text
 .p2align PAGE_SHIFT, 0x90  /* Hypercall_page needs to be PAGE aligned */
@@ -64,6 +72,7 @@
 NON_GPROF_ENTRY(hypercall_page)
.skip   0x1000, 0x90/* Fill with "nop"s */
 
+/* Legacy PVH entry point, to be removed. */
 NON_GPROF_ENTRY(xen_start)
/* Don't trust what the loader gives for rflags. */
pushq   $PSL_KERNEL
@@ -85,3 +94,141 @@ NON_GPROF_ENTRY(xen_start)
/* NOTREACHED */
 0: hlt
jmp 0b
+
+/* PVH entry point. */
+   .code32
+NON_GPROF_ENTRY(xen_start32)
+
+   /* Load flat GDT */
+   movl$VTOP(gdtdesc32), %eax
+   lgdt(%eax)
+   jmp $GDT_CODE, $VTOP(reload_cs)
+
+reload_cs:
+   movw$GDT_DATA, %ax
+   movw%ax, %ds
+   movw%ax, %es
+   movw%ax, %ss
+
+   movl$VTOP(bootstack), %esp
+
+   /* Don't trust what the loader gives for eflags. */
+   pushl   $PSL_KERNEL
+   popfl
+
+   /*
+* Create the page tables.
+* The first 1GB is mapped using 2MB entries.
+*/
+   movl$0, %eax
+pgbuild:
+   cmp $(PAGE_SIZE/ENTRY_SIZE), %eax
+   jae pgbuild_done
+
+   /* PT4[i] = VTOP([0]) | PG_V | PG_RW | PG_U */
+   movl$VTOP(PT4), %ecx
+   movl$VTOP(PT3), %edx
+   orl $(PG_V | PG_RW | PG_U), %edx
+   movl%edx, (%ecx,%eax,ENTRY_SIZE)
+
+   /* PT3[i] = VTOP([0]) | PG_V | PG_RW | PG_U */
+   movl$VTOP(PT3), %ecx
+   movl$VTOP(PT2), %edx
+   orl $(PG_V | PG_RW | PG_U), %edx
+   movl%edx, (%ecx,%eax,ENTRY_SIZE)
+
+   /* PT2[i] = i * 2MiB | PG_V | PG_RW | PG_PS | PG_U */
+   movl$VTOP(PT2), %ecx
+   movl%eax, %edx
+   shll$PDRSHIFT, %edx
+   orl $(PG_V | PG_RW | PG_PS | PG_U), %edx
+   movl%edx, (%ecx,%eax,ENTRY_SIZE)
+
+   inc %eax
+   jmp pgbuild
+
+pgbuild_done:
+   /* Turn on EFER.LME */
+   movl$MSR_EFER, %ecx
+   rdmsr
+   orl $EFER_LME, %eax
+   wrmsr
+
+   /* Turn on PAE */
+   movl%cr4, %eax
+   orl $CR4_PAE, %eax
+   movl%eax, %cr4
+
+   /* Set %cr3 for PT4 */
+   movl$VTOP(PT4), %eax
+   movl%eax, %cr3
+
+   /* Turn on paging (implicitly sets EFER.LMA) */
+   movl%cr0, %eax
+   orl $CR0_PG, %eax
+   movl%eax, %cr0
+
+   /* Now we're in compatibility mode. Set %cs for long mode */
+   movl$VTOP(gdtdesc), %eax
+   lgdt(%eax)
+   ljmp$GDT_CODE, $VTOP(longmode)
+
+   .code64
+longmode:
+   /* We're still running V=P, jump to entry point */
+   movq$bootstack, %rsp
+   movq$start_kernel, %rax
+   pushq   %rax
+   ret
+
+start_kernel:
+   /*
+* Pass %ebx as the argument to hammer_time_xen, it contains
+* the startup info.
+*/
+   movq%rbx, %rdi
+   callhammer_time_xen
+   movq%rax, %rsp
+   callmi_startup
+
+   /* NOTREACHED */
+0: hlt
+   jmp 0b
+
+/* Space for initial page tables */
+   .data
+   .p2align 12,0x40
+PT4:
+   .space  0x1000
+PT3:
+   .space  0x1000
+PT2:
+   .space  0x1000
+
+/* 64bit GDT */
+gdtdesc:
+  

Re: svn commit: r335629 - in head: share/man/man4 sys/dev/vt/hw/vga

2018-06-28 Thread Roger Pau Monné
On Tue, Jun 26, 2018 at 10:18:39AM -0600, Ian Lepore wrote:
> On Tue, 2018-06-26 at 08:55 -0700, Rodney W. Grimes wrote:
> > > 
> > > On Tue, Jun 26, 2018 at 05:21:27AM +, Alexey Dokuchaev wrote:
> > > > 
> > > > On Mon, Jun 25, 2018 at 08:43:51AM -0700, Rodney W. Grimes wrote:
> > > > > 
> > > > > > 
> > > > > > New Revision: 335629
> > > > > > URL: https://svnweb.freebsd.org/changeset/base/335629
> > > > > > 
> > > > > > Log:
> > > > > >   vt: add option to ignore NO_VGA flag in ACPI
> > > > > >   
> > > > > >   To workaround buggy firmware that sets this flag when
> > > > > > there's actually
> > > > > >   a VGA present.
> > > > > >   
> > > > > >   Reported and tested by:   Yasuhiro KIMURA  > > > > > e.org>
> > > > > >   Sponsored by: Citrix Systems R
> > > > > >   Reviewed by:  kib
> > > > > >   Differential revision:https://reviews.freebsd.org/D
> > > > > > 16003
> > > > > It is generally best to avoid double negatives,
> > > > > couldnt this of been better named? (hw.vga.acpi_force_vga)
> > > > Yes please; I get constantly confused when calculating negatives
> > > > and
> > > > often get them wrong.
> > > This is specifically done to workaround a firmware bug where some
> > > buggy firmwares set the NO_VGA flag in ACPI.
> > We are not conflicted about working around the buggy ACPI.
> > 
> > > 
> > > So the option does
> > > exactly what the name says, it ignores the NO_VGA flag in ACPI. IMO
> > > acpi_force_vga is not as descriptive as the current name.
> > Interestingly that is the text you use to describe it in the man
> > page, so it seems as if it is good for the description, but not
> > good for the name of the flag itself?
> > 
> > .It Va hw.vga.acpi_ignore_no_vga
> > Set to 1 to force the usage of the VGA driver regardless of whether
> > ACPI IAPC_BOOT_ARCH signals no VGA support.
> > Can be used to workaround firmware bugs in the ACPI tables.
> > 
> > This does not mention the ACPI table entry being over ridden,
> >  if (flags & ACPI_FADT_NO_VGA)
> > 
> > Further digging I believe you have placed this in the wrong
> > part of the hierarchy.  You put it in hw.vga, and it really
> > should be in hw.acpi.
> > Maybe hw.acpi.bootflags.ignore.no_vga.
> > 
> > Are there any other bootflags we may want to ignore?
> > 
> > Regards,
> 
> 
> There is ACPI_FADT_NO_CMOS_RTC, with an associated tunable
> hw.atrtc.enabled (default is -1), which can be:
> 
>   -1 - enabled unless acpi says ACPI_FADT_NO_CMOS_RTC
>    0 - unconditionally disabled
>    1 - unconditionally enabled
> 
> The idea was that if RTC is provided by EFI runtime services, this flag
> would indicate that old-school CMOS RTC drivers should not be used.
>  But, predictably, it turns out there are bioses that set this flag
> even when booting in legacy non-efi mode, leading to a need to ignore
> the flag and force use of the old driver.

I could take this approach for vt and add hw.vt.enabled = { -1, 0, 1 }
if that seems better.

Roger.
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r335668 - head/sys/x86/xen

2018-06-26 Thread Roger Pau Monné
Author: royger
Date: Tue Jun 26 15:00:54 2018
New Revision: 335668
URL: https://svnweb.freebsd.org/changeset/base/335668

Log:
  xen: obtain vCPU ID from CPUID
  
  The Xen vCPU ID can be fetched from the cpuid instead of inferring it
  from the ACPI ID.
  
  Sponsored by: Citrix Systems R

Modified:
  head/sys/x86/xen/hvm.c

Modified: head/sys/x86/xen/hvm.c
==
--- head/sys/x86/xen/hvm.c  Tue Jun 26 14:48:23 2018(r335667)
+++ head/sys/x86/xen/hvm.c  Tue Jun 26 15:00:54 2018(r335668)
@@ -56,6 +56,7 @@ __FBSDID("$FreeBSD$");
 #include 
 #include 
 
+#include 
 #include 
 #include 
 
@@ -103,6 +104,9 @@ TUNABLE_INT("hw.xen.disable_pv_disks", _disable_pv
 TUNABLE_INT("hw.xen.disable_pv_nics", _disable_pv_nics);
 
 /*-- XEN Hypervisor Probe and Setup 
--*/
+
+static uint32_t cpuid_base;
+
 static uint32_t
 xen_hvm_cpuid_base(void)
 {
@@ -123,21 +127,21 @@ xen_hvm_cpuid_base(void)
 static int
 xen_hvm_init_hypercall_stubs(enum xen_hvm_init_type init_type)
 {
-   uint32_t base, regs[4];
+   uint32_t regs[4];
 
if (xen_pv_domain()) {
/* hypercall page is already set in the PV case */
return (0);
}
 
-   base = xen_hvm_cpuid_base();
-   if (base == 0)
+   cpuid_base = xen_hvm_cpuid_base();
+   if (cpuid_base == 0)
return (ENXIO);
 
if (init_type == XEN_HVM_INIT_COLD) {
int major, minor;
 
-   do_cpuid(base + 1, regs);
+   do_cpuid(cpuid_base + 1, regs);
 
major = regs[0] >> 16;
minor = regs[0] & 0x;
@@ -165,7 +169,7 @@ xen_hvm_init_hypercall_stubs(enum xen_hvm_init_type in
/*
 * Find the hypercall pages.
 */
-   do_cpuid(base + 2, regs);
+   do_cpuid(cpuid_base + 2, regs);
if (regs[0] != 1)
return (EINVAL);
 
@@ -371,31 +375,14 @@ xen_hvm_sysinit(void *arg __unused)
 {
xen_hvm_init(XEN_HVM_INIT_COLD);
 }
+SYSINIT(xen_hvm_init, SI_SUB_HYPERVISOR, SI_ORDER_FIRST, xen_hvm_sysinit, 
NULL);
 
 static void
-xen_set_vcpu_id(void)
-{
-   struct pcpu *pc;
-   int i;
-
-   if (!xen_hvm_domain())
-   return;
-
-   /* Set vcpu_id to acpi_id */
-   CPU_FOREACH(i) {
-   pc = pcpu_find(i);
-   pc->pc_vcpu_id = pc->pc_acpi_id;
-   if (bootverbose)
-   printf("XEN: CPU %u has VCPU ID %u\n",
-  i, pc->pc_vcpu_id);
-   }
-}
-
-static void
 xen_hvm_cpu_init(void)
 {
struct vcpu_register_vcpu_info info;
struct vcpu_info *vcpu_info;
+   uint32_t regs[4];
int cpu, rc;
 
if (!xen_domain())
@@ -410,6 +397,22 @@ xen_hvm_cpu_init(void)
return;
}
 
+   /*
+* Set vCPU ID. If available fetch the ID from CPUID, if not just use
+* the ACPI ID.
+*/
+   KASSERT(cpuid_base != 0, ("Invalid base Xen CPUID leaf"));
+   cpuid_count(cpuid_base + 4, 0, regs);
+   PCPU_SET(vcpu_id, (regs[0] & XEN_HVM_CPUID_VCPU_ID_PRESENT) ?
+   regs[1] : PCPU_GET(acpi_id));
+
+   /*
+* Set the vCPU info.
+*
+* NB: the vCPU info for vCPUs < 32 can be fetched from the shared info
+* page, but in order to make sure the mapping code is correct always
+* attempt to map the vCPU info at a custom place.
+*/
vcpu_info = DPCPU_PTR(vcpu_local_info);
cpu = PCPU_GET(vcpu_id);
info.mfn = vtophys(vcpu_info) >> PAGE_SHIFT;
@@ -421,7 +424,4 @@ xen_hvm_cpu_init(void)
else
DPCPU_SET(vcpu_info, vcpu_info);
 }
-
-SYSINIT(xen_hvm_init, SI_SUB_HYPERVISOR, SI_ORDER_FIRST, xen_hvm_sysinit, 
NULL);
 SYSINIT(xen_hvm_cpu_init, SI_SUB_INTR, SI_ORDER_FIRST, xen_hvm_cpu_init, NULL);
-SYSINIT(xen_set_vcpu_id, SI_SUB_CPU, SI_ORDER_ANY, xen_set_vcpu_id, NULL);
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r335666 - head/sys/x86/xen

2018-06-26 Thread Roger Pau Monné
Author: royger
Date: Tue Jun 26 14:39:27 2018
New Revision: 335666
URL: https://svnweb.freebsd.org/changeset/base/335666

Log:
  xen: limit the number of hypercall pages to 1
  
  The interface already guarantees that the number of hypercall pages is
  always going to be 1, see the comment in interface/arch-x86/cpuid.h
  
  Sponsored by: Citrix Systems R

Modified:
  head/sys/x86/xen/hvm.c

Modified: head/sys/x86/xen/hvm.c
==
--- head/sys/x86/xen/hvm.c  Tue Jun 26 14:30:33 2018(r335665)
+++ head/sys/x86/xen/hvm.c  Tue Jun 26 14:39:27 2018(r335666)
@@ -124,7 +124,6 @@ static int
 xen_hvm_init_hypercall_stubs(enum xen_hvm_init_type init_type)
 {
uint32_t base, regs[4];
-   int i;
 
if (xen_pv_domain()) {
/* hypercall page is already set in the PV case */
@@ -167,9 +166,10 @@ xen_hvm_init_hypercall_stubs(enum xen_hvm_init_type in
 * Find the hypercall pages.
 */
do_cpuid(base + 2, regs);
+   if (regs[0] != 1)
+   return (EINVAL);
 
-   for (i = 0; i < regs[0]; i++)
-   wrmsr(regs[1], vtophys(_page + i * PAGE_SIZE) + i);
+   wrmsr(regs[1], vtophys(_page));
 
return (0);
 }
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r335664 - head/sys/dev/xen/netback

2018-06-26 Thread Roger Pau Monné
Author: royger
Date: Tue Jun 26 14:07:11 2018
New Revision: 335664
URL: https://svnweb.freebsd.org/changeset/base/335664

Log:
  xen-netback: fix LOR
  
  lock order reversal: (sleepable after non-sleepable)
   1st 0xfe00357ff538 xnb_softc (xen netback softc lock) @ 
/usr/src/sys/dev/xen/netback/netback.c:1069
   2nd 0x81fdccb0 intrsrc (intrsrc) @ 
/usr/src/sys/x86/x86/intr_machdep.c:224
  
  There's no need to hold the lock since the cleaning of the interrupt
  cannot happen in parallel due to the XNBF_IN_SHUTDOWN flag being set.
  Note that the locking in netback needs some improvement or
  clarification.
  
  While there also remove a double newline.
  
  Sponsored by:   Citrix Systems R

Modified:
  head/sys/dev/xen/netback/netback.c

Modified: head/sys/dev/xen/netback/netback.c
==
--- head/sys/dev/xen/netback/netback.c  Tue Jun 26 14:01:03 2018
(r335663)
+++ head/sys/dev/xen/netback/netback.c  Tue Jun 26 14:07:11 2018
(r335664)
@@ -662,6 +662,7 @@ xnb_disconnect(struct xnb_softc *xnb)
mtx_lock(>rx_lock);
mtx_unlock(>rx_lock);
 
+   mtx_lock(>sc_lock);
/* Free malloc'd softc member variables */
if (xnb->bridge != NULL) {
free(xnb->bridge, M_XENSTORE);
@@ -689,6 +690,8 @@ xnb_disconnect(struct xnb_softc *xnb)
sizeof(struct xnb_ring_config));
 
xnb->flags &= ~XNBF_RING_CONNECTED;
+   mtx_unlock(>sc_lock);
+
return (0);
 }
 
@@ -1066,17 +1069,14 @@ xnb_shutdown(struct xnb_softc *xnb)
if_free(xnb->xnb_ifp);
xnb->xnb_ifp = NULL;
}
-   mtx_lock(>sc_lock);
 
xnb_disconnect(xnb);
 
-   mtx_unlock(>sc_lock);
if (xenbus_get_state(xnb->dev) < XenbusStateClosing)
xenbus_set_state(xnb->dev, XenbusStateClosing);
mtx_lock(>sc_lock);
 
xnb->flags &= ~XNBF_IN_SHUTDOWN;
-
 
/* Indicate to xnb_detach() that is it safe to proceed. */
wakeup(xnb);
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r335629 - in head: share/man/man4 sys/dev/vt/hw/vga

2018-06-26 Thread Roger Pau Monné
On Tue, Jun 26, 2018 at 05:21:27AM +, Alexey Dokuchaev wrote:
> On Mon, Jun 25, 2018 at 08:43:51AM -0700, Rodney W. Grimes wrote:
> > > New Revision: 335629
> > > URL: https://svnweb.freebsd.org/changeset/base/335629
> > > 
> > > Log:
> > >   vt: add option to ignore NO_VGA flag in ACPI
> > >   
> > >   To workaround buggy firmware that sets this flag when there's actually
> > >   a VGA present.
> > >   
> > >   Reported and tested by: Yasuhiro KIMURA 
> > >   Sponsored by:   Citrix Systems R
> > >   Reviewed by:kib
> > >   Differential revision:  https://reviews.freebsd.org/D16003
> > 
> > It is generally best to avoid double negatives,
> > couldnt this of been better named? (hw.vga.acpi_force_vga)
> 
> Yes please; I get constantly confused when calculating negatives and
> often get them wrong.

This is specifically done to workaround a firmware bug where some
buggy firmwares set the NO_VGA flag in ACPI. So the option does
exactly what the name says, it ignores the NO_VGA flag in ACPI. IMO
acpi_force_vga is not as descriptive as the current name.

Roger.
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r335629 - in head: share/man/man4 sys/dev/vt/hw/vga

2018-06-25 Thread Roger Pau Monné
Author: royger
Date: Mon Jun 25 09:39:16 2018
New Revision: 335629
URL: https://svnweb.freebsd.org/changeset/base/335629

Log:
  vt: add option to ignore NO_VGA flag in ACPI
  
  To workaround buggy firmware that sets this flag when there's actually
  a VGA present.
  
  Reported and tested by:   Yasuhiro KIMURA 
  Sponsored by: Citrix Systems R
  Reviewed by:  kib
  Differential revision:https://reviews.freebsd.org/D16003

Modified:
  head/share/man/man4/vt.4
  head/sys/dev/vt/hw/vga/vt_vga.c

Modified: head/share/man/man4/vt.4
==
--- head/share/man/man4/vt.4Mon Jun 25 09:19:50 2018(r335628)
+++ head/share/man/man4/vt.4Mon Jun 25 09:39:16 2018(r335629)
@@ -44,6 +44,7 @@
 In
 .Xr loader.conf 5 :
 .Cd hw.vga.textmode=1
+.Cd hw.vga.acpi_ignore_no_vga=1
 .Cd kern.vty=vt
 .Cd kern.vt.color..rgb=""
 .Cd kern.vt.fb.default_mode="x"
@@ -196,6 +197,10 @@ prompt or in
 Set to 1 to use virtual terminals in text mode instead of graphics mode.
 Features that require graphics mode, like loadable fonts, will be
 disabled.
+.It Va hw.vga.acpi_ignore_no_vga
+Set to 1 to force the usage of the VGA driver regardless of whether
+ACPI IAPC_BOOT_ARCH signals no VGA support.
+Can be used to workaround firmware bugs in the ACPI tables.
 .It Va kern.vty
 Set this value to
 .Ql vt

Modified: head/sys/dev/vt/hw/vga/vt_vga.c
==
--- head/sys/dev/vt/hw/vga/vt_vga.c Mon Jun 25 09:19:50 2018
(r335628)
+++ head/sys/dev/vt/hw/vga/vt_vga.c Mon Jun 25 09:39:16 2018
(r335629)
@@ -1217,6 +1217,12 @@ vga_acpi_disabled(void)
ACPI_TABLE_FADT *fadt;
vm_paddr_t physaddr;
uint16_t flags;
+   int ignore;
+
+   TUNABLE_INT_FETCH("hw.vga.acpi_ignore_no_vga", );
+
+   if (ignore)
+   return (false);
 
physaddr = acpi_find_table(ACPI_SIG_FADT);
if (physaddr == 0)
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r335490 - head/sys/dev/xen/grant_table

2018-06-21 Thread Roger Pau Monné
Author: royger
Date: Thu Jun 21 15:47:47 2018
New Revision: 335490
URL: https://svnweb.freebsd.org/changeset/base/335490

Log:
  xen: check if there are clients waiting in 
gnttab_end_foreign_access_references
  
  Without a call to check_free_callbacks() clients waiting for grant
  references would not be woken up even when there are sufficient grant
  references available.
  
  The check was likely left out as a mistake when the function was first
  added.
  
  Note that other functions used to free grant references already call
  check_free_callbacks.
  
  Submitted by: pratyush
  Reviewed by:  royger
  Differential review:  https://reviews.freebsd.org/D15899

Modified:
  head/sys/dev/xen/grant_table/grant_table.c

Modified: head/sys/dev/xen/grant_table/grant_table.c
==
--- head/sys/dev/xen/grant_table/grant_table.c  Thu Jun 21 15:21:17 2018
(r335489)
+++ head/sys/dev/xen/grant_table/grant_table.c  Thu Jun 21 15:47:47 2018
(r335490)
@@ -245,6 +245,7 @@ gnttab_end_foreign_access_references(u_int count, gran
gnttab_free_count += count;
gnttab_entry(tail) = gnttab_free_head;
gnttab_free_head = head;
+   check_free_callbacks();
mtx_unlock(_list_lock);
}
 }
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r334205 - head/sys/xen

2018-05-25 Thread Roger Pau Monné
Author: royger
Date: Fri May 25 08:44:00 2018
New Revision: 334205
URL: https://svnweb.freebsd.org/changeset/base/334205

Log:
  xen: remove dead code from gnttab.h
  
  This code was left over when it was imported from Linux. The original
  committer thought that those functions would be implemented, so the
  prototypes where left in place. Delete them at once.
  
  Submitted by: pratyush
  Reviewed by:  royger
  Differential Review:  https://reviews.freebsd.org/D15553

Modified:
  head/sys/xen/gnttab.h

Modified: head/sys/xen/gnttab.h
==
--- head/sys/xen/gnttab.h   Fri May 25 07:33:20 2018(r334204)
+++ head/sys/xen/gnttab.h   Fri May 25 08:44:00 2018(r334205)
@@ -117,46 +117,4 @@ void gnttab_grant_foreign_transfer_ref(grant_ref_t, do
 int gnttab_suspend(void);
 int gnttab_resume(device_t);
 
-#if 0
-
-#include 
-
-static inline void
-gnttab_set_map_op(struct gnttab_map_grant_ref *map, vm_paddr_t addr,
- uint32_t flags, grant_ref_t ref, domid_t domid)
-{
-   if (flags & GNTMAP_contains_pte)
-   map->host_addr = addr;
-   else
-   map->host_addr = vtophys(addr);
-
-   map->flags = flags;
-   map->ref = ref;
-   map->dom = domid;
-}
-
-static inline void
-gnttab_set_unmap_op(struct gnttab_unmap_grant_ref *unmap, vm_paddr_t addr,
-   uint32_t flags, grant_handle_t handle)
-{
-   if (flags & GNTMAP_contains_pte)
-   unmap->host_addr = addr;
-   else
-   unmap->host_addr = vtophys(addr);
-
-   unmap->handle = handle;
-   unmap->dev_bus_addr = 0;
-}
-
-static inline void
-gnttab_set_replace_op(struct gnttab_unmap_and_replace *unmap, vm_paddr_t addr,
- vm_paddr_t new_addr, grant_handle_t handle)
-{
-   unmap->host_addr = vtophys(addr);
-   unmap->new_addr = vtophys(new_addr);
-
-   unmap->handle = handle;
-}
-#endif
-
 #endif /* __ASM_GNTTAB_H__ */
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r334147 - head/sys/x86/xen

2018-05-24 Thread Roger Pau Monné
Author: royger
Date: Thu May 24 10:22:57 2018
New Revision: 334147
URL: https://svnweb.freebsd.org/changeset/base/334147

Log:
  xen/pvh: allocate dbg_stack
  
  Or else init_secondary will hit a page fault (or write garbage
  somewhere).
  
  Sponsored by: Citrix Systems R

Modified:
  head/sys/x86/xen/pv.c

Modified: head/sys/x86/xen/pv.c
==
--- head/sys/x86/xen/pv.c   Thu May 24 10:20:42 2018(r334146)
+++ head/sys/x86/xen/pv.c   Thu May 24 10:22:57 2018(r334147)
@@ -101,6 +101,7 @@ static int xen_pv_start_all_aps(void);
 extern char *doublefault_stack;
 extern char *mce_stack;
 extern char *nmi_stack;
+extern char *dbg_stack;
 #endif
 
 /*
@@ -224,6 +225,8 @@ start_xen_ap(int cpu)
(char *)kmem_malloc(kernel_arena, PAGE_SIZE, M_WAITOK | M_ZERO);
nmi_stack =
(char *)kmem_malloc(kernel_arena, PAGE_SIZE, M_WAITOK | M_ZERO);
+   dbg_stack =
+   (void *)kmem_malloc(kernel_arena, PAGE_SIZE, M_WAITOK | M_ZERO);
dpcpu =
(void *)kmem_malloc(kernel_arena, DPCPU_SIZE, M_WAITOK | M_ZERO);
 
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r334146 - head/sys/dev/xen/evtchn

2018-05-24 Thread Roger Pau Monné
Author: royger
Date: Thu May 24 10:20:42 2018
New Revision: 334146
URL: https://svnweb.freebsd.org/changeset/base/334146

Log:
  xen/evtchn: fix LOR in evtchn device
  
  Remove the device from the list before unbinding it. Doing it in this
  order allows calling xen_intr_unbind without holding the bind_mutex
  lock.
  
  Sponsored by: Citrix Systems R

Modified:
  head/sys/dev/xen/evtchn/evtchn_dev.c

Modified: head/sys/dev/xen/evtchn/evtchn_dev.c
==
--- head/sys/dev/xen/evtchn/evtchn_dev.cThu May 24 10:19:54 2018
(r334145)
+++ head/sys/dev/xen/evtchn/evtchn_dev.cThu May 24 10:20:42 2018
(r334146)
@@ -474,10 +474,10 @@ evtchn_ioctl(struct cdev *dev, unsigned long cmd, cadd
error = ENOTCONN;
break;
}
-
-   xen_intr_unbind(>handle);
RB_REMOVE(evtchn_tree, >evtchns, evtchn);
mtx_unlock(>bind_mutex);
+
+   xen_intr_unbind(>handle);
free(evtchn, M_EVTCHN);
error = 0;
break;
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r334145 - head/sys/dev/xen/blkback

2018-05-24 Thread Roger Pau Monné
Author: royger
Date: Thu May 24 10:19:54 2018
New Revision: 334145
URL: https://svnweb.freebsd.org/changeset/base/334145

Log:
  xen-blkback: don't unbind the interrupt while holding the lock
  
  There's no need to perform the interrupt unbind while holding the
  blkback lock, and doing so leads to the following LOR:
  
  lock order reversal: (sleepable after non-sleepable)
   1st 0xf8000802fe90 xbbd1 (xbbd1) @ 
/usr/src/sys/dev/xen/blkback/blkback.c:3423
   2nd 0x81fdf890 intrsrc (intrsrc) @ 
/usr/src/sys/x86/x86/intr_machdep.c:224
  stack backtrace:
  #0 0x80bdd993 at witness_debugger+0x73
  #1 0x80bdd814 at witness_checkorder+0xe34
  #2 0x80b7d798 at _sx_xlock+0x68
  #3 0x811b3913 at intr_remove_handler+0x43
  #4 0x811c63ef at xen_intr_unbind+0x10f
  #5 0x80a12ecf at xbb_disconnect+0x2f
  #6 0x80a12e54 at xbb_shutdown+0x1e4
  #7 0x80a10be4 at xbb_frontend_changed+0x54
  #8 0x80ed66a4 at xenbusb_back_otherend_changed+0x14
  #9 0x80a2a382 at xenwatch_thread+0x182
  #10 0x80b34164 at fork_exit+0x84
  #11 0x8101ec9e at fork_trampoline+0xe
  
  Reported by:Nathan Friess 
  Sponsored by:   Citrix Systems R

Modified:
  head/sys/dev/xen/blkback/blkback.c

Modified: head/sys/dev/xen/blkback/blkback.c
==
--- head/sys/dev/xen/blkback/blkback.c  Thu May 24 10:18:31 2018
(r334144)
+++ head/sys/dev/xen/blkback/blkback.c  Thu May 24 10:19:54 2018
(r334145)
@@ -2803,9 +2803,8 @@ xbb_disconnect(struct xbb_softc *xbb)
if ((xbb->flags & XBBF_RING_CONNECTED) == 0)
return (0);
 
-   xen_intr_unbind(>xen_intr_handle);
-
mtx_unlock(>lock);
+   xen_intr_unbind(>xen_intr_handle);
taskqueue_drain(xbb->io_taskqueue, >io_task); 
mtx_lock(>lock);
 
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r334144 - head/sys/dev/xen/xenstore

2018-05-24 Thread Roger Pau Monné
Author: royger
Date: Thu May 24 10:18:31 2018
New Revision: 334144
URL: https://svnweb.freebsd.org/changeset/base/334144

Log:
  dev/xenstore: prevent transaction hijacking
  
  The user-space xenstore device is currently lacking a check to make
  sure that the caller is only using transaction ids currently assigned
  to it. This allows users of the xenstore device to hijack transactions
  not started by them, although the scope is limited to transactions
  started by the same domain.
  
  Tested by:  Nathan Friess 
  Sponsored by:   Citrix Systems R

Modified:
  head/sys/dev/xen/xenstore/xenstore_dev.c

Modified: head/sys/dev/xen/xenstore/xenstore_dev.c
==
--- head/sys/dev/xen/xenstore/xenstore_dev.cThu May 24 10:18:14 2018
(r334143)
+++ head/sys/dev/xen/xenstore/xenstore_dev.cThu May 24 10:18:31 2018
(r334144)
@@ -214,6 +214,18 @@ xs_dev_watch_cb(struct xs_watch *watch, const char **v
free(payload, M_XENSTORE);
 }
 
+static struct xs_dev_transaction *
+xs_dev_find_transaction(struct xs_dev_data *u, uint32_t tx_id)
+{
+   struct xs_dev_transaction *trans;
+
+   LIST_FOREACH(trans, >transactions, list)
+   if (trans->handle.id == tx_id)
+   return (trans);
+
+   return (NULL);
+}
+
 static int 
 xs_dev_read(struct cdev *dev, struct uio *uio, int ioflag)
 {
@@ -281,6 +293,12 @@ xs_dev_write(struct cdev *dev, struct uio *uio, int io
case XS_MKDIR:
case XS_RM:
case XS_SET_PERMS:
+   /* Check that this transaction id is not hijacked. */
+   if (u->u.msg.tx_id != 0 &&
+   xs_dev_find_transaction(u, u->u.msg.tx_id) == NULL) {
+   error = EINVAL;
+   break;
+   }
error = xs_dev_request_and_reply(>u.msg, );
if (!error) {
if (u->u.msg.type == XS_TRANSACTION_START) {
@@ -289,12 +307,10 @@ xs_dev_write(struct cdev *dev, struct uio *uio, int io
trans->handle.id = strtoul(reply, NULL, 0);
LIST_INSERT_HEAD(>transactions, trans, list);
} else if (u->u.msg.type == XS_TRANSACTION_END) {
-   LIST_FOREACH(trans, >transactions, list)
-   if (trans->handle.id == u->u.msg.tx_id)
-   break;
-#if 0 /* XXX does this mean the list is empty? */
-   BUG_ON(>list == >transactions);
-#endif
+   trans = xs_dev_find_transaction(u,
+   u->u.msg.tx_id);
+   KASSERT(trans != NULL,
+   ("Unable to find transaction"));
LIST_REMOVE(trans, list);
free(trans, M_XENSTORE);
}
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r334142 - head/sys/dev/xen/xenstore

2018-05-24 Thread Roger Pau Monné
Author: royger
Date: Thu May 24 10:17:49 2018
New Revision: 334142
URL: https://svnweb.freebsd.org/changeset/base/334142

Log:
  dev/xenstore: add support for watches
  
  Allow user-space applications to register watches using the xenstore
  device.  This is needed in order to run toolstack operations on
  domains different than the one where xenstore is running (in which
  case the device is not used, since the connection to xenstore is done
  using a plain socket).
  
  Tested by:  Nathan Friess 
  Sponsored by:   Citrix Systems R

Modified:
  head/sys/dev/xen/xenstore/xenstore_dev.c

Modified: head/sys/dev/xen/xenstore/xenstore_dev.c
==
--- head/sys/dev/xen/xenstore/xenstore_dev.cThu May 24 10:17:03 2018
(r334141)
+++ head/sys/dev/xen/xenstore/xenstore_dev.cThu May 24 10:17:49 2018
(r334142)
@@ -44,6 +44,8 @@ __FBSDID("$FreeBSD$");
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include 
 
@@ -56,10 +58,20 @@ struct xs_dev_transaction {
struct xs_transaction handle;
 };
 
+struct xs_dev_watch {
+   LIST_ENTRY(xs_dev_watch) list;
+   struct xs_watch watch;
+   char *token;
+   struct xs_dev_data *user;
+};
+
 struct xs_dev_data {
/* In-progress transaction. */
-   LIST_HEAD(xdd_list_head, xs_dev_transaction) transactions;
+   LIST_HEAD(, xs_dev_transaction) transactions;
 
+   /* Active watches. */
+   LIST_HEAD(, xs_dev_watch) watches;
+
/* Partial request. */
unsigned int len;
union {
@@ -71,8 +83,137 @@ struct xs_dev_data {
 #define MASK_READ_IDX(idx) ((idx)&(PAGE_SIZE-1))
char read_buffer[PAGE_SIZE];
unsigned int read_cons, read_prod;
+
+   /* Serializes writes to the read buffer. */
+   struct mtx lock;
+
+   /* Polling structure (for reads only ATM). */
+   struct selinfo ev_rsel;
 };
 
+static void
+xs_queue_reply(struct xs_dev_data *u, const char *data, unsigned int len)
+{
+   unsigned int i;
+
+   for (i = 0; i < len; i++, u->read_prod++)
+   u->read_buffer[MASK_READ_IDX(u->read_prod)] = data[i];
+
+   KASSERT((u->read_prod - u->read_cons) <= sizeof(u->read_buffer),
+   ("xenstore reply too big"));
+
+   wakeup(u);
+   selwakeup(>ev_rsel);
+}
+
+static const char *
+xs_dev_error_to_string(int error)
+{
+   unsigned int i;
+
+   for (i = 0; i < nitems(xsd_errors); i++)
+   if (xsd_errors[i].errnum == error)
+   return (xsd_errors[i].errstring);
+
+   return (NULL);
+}
+
+static void
+xs_dev_return_error(struct xs_dev_data *u, int error, int req_id, int tx_id)
+{
+   struct xsd_sockmsg msg;
+   const char *payload;
+
+   msg.type = XS_ERROR;
+   msg.req_id = req_id;
+   msg.tx_id = tx_id;
+   payload = NULL;
+
+
+   payload = xs_dev_error_to_string(error);
+   if (payload == NULL)
+   payload = xs_dev_error_to_string(EINVAL);
+   KASSERT(payload != NULL, ("Unable to find string for EINVAL errno"));
+
+   msg.len = strlen(payload) + 1;
+
+   mtx_lock(>lock);
+   xs_queue_reply(u, (char *), sizeof(msg));
+   xs_queue_reply(u, payload, msg.len);
+   mtx_unlock(>lock);
+}
+
+static int
+xs_dev_watch_message_parse_string(const char **p, const char *end,
+const char **string_r)
+{
+   const char *nul;
+
+   nul = memchr(*p, 0, end - *p);
+   if (!nul)
+   return (EINVAL);
+
+   *string_r = *p;
+   *p = nul+1;
+
+   return (0);
+}
+
+static int
+xs_dev_watch_message_parse(const struct xsd_sockmsg *msg, const char **path_r,
+const char **token_r)
+{
+   const char *p, *end;
+   int error;
+
+   p = (const char *)msg + sizeof(*msg);
+   end = p + msg->len;
+   KASSERT(p <= end, ("payload overflow"));
+
+   error = xs_dev_watch_message_parse_string(, end, path_r);
+   if (error)
+   return (error);
+   error = xs_dev_watch_message_parse_string(, end, token_r);
+   if (error)
+   return (error);
+
+   return (0);
+}
+
+static struct xs_dev_watch *
+xs_dev_find_watch(struct xs_dev_data *u, const char *token)
+{
+   struct xs_dev_watch *watch;
+
+   LIST_FOREACH(watch, >watches, list)
+   if (strcmp(watch->token, token) == 0)
+   return (watch);
+
+   return (NULL);
+}
+
+static void
+xs_dev_watch_cb(struct xs_watch *watch, const char **vec, unsigned int len)
+{
+   struct xs_dev_watch *dwatch;
+   struct xsd_sockmsg msg;
+   char *payload;
+
+   dwatch = (struct xs_dev_watch *)watch->callback_data;
+   msg.type = XS_WATCH_EVENT;
+   msg.req_id = msg.tx_id = 0;
+   msg.len = strlen(vec[XS_WATCH_PATH]) + strlen(dwatch->token) + 2;
+
+   payload = malloc(msg.len, M_XENSTORE, M_WAITOK);
+   strcpy(payload, vec[XS_WATCH_PATH]);
+   

svn commit: r334141 - head/sys/dev/xen/xenstore

2018-05-24 Thread Roger Pau Monné
Author: royger
Date: Thu May 24 10:17:03 2018
New Revision: 334141
URL: https://svnweb.freebsd.org/changeset/base/334141

Log:
  xenstore: don't wait with the PCATCH flag
  
  Due to the current synchronous xenstore implementation in FreeBSD, we
  cannot return from xs_read_reply without reading a reply, or else the
  ring gets out of sync and the next request will read the previous
  reply and crash due to the type mismatch. A proper solution involves
  making use of the req_id field in the message and allowing multiple
  in-flight messages at the same time on the ring.
  
  Remove the PCATCH flag so that signals don't interrupt the wait.
  
  Tested by:  Nathan Friess 
  Sponsored by:   Citrix Systems R

Modified:
  head/sys/dev/xen/xenstore/xenstore.c

Modified: head/sys/dev/xen/xenstore/xenstore.c
==
--- head/sys/dev/xen/xenstore/xenstore.cThu May 24 10:16:11 2018
(r334140)
+++ head/sys/dev/xen/xenstore/xenstore.cThu May 24 10:17:03 2018
(r334141)
@@ -742,8 +742,8 @@ xs_read_reply(enum xsd_sockmsg_type *type, u_int *len,
 
mtx_lock(_lock);
while (TAILQ_EMPTY(_list)) {
-   error = mtx_sleep(_list, _lock,
-   PCATCH, "xswait", hz/10);
+   error = mtx_sleep(_list, _lock, 0, "xswait",
+   hz/10);
if (error && error != EWOULDBLOCK) {
mtx_unlock(_lock);
return (error);
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r334140 - head/sys/dev/xen/xenstore

2018-05-24 Thread Roger Pau Monné
Author: royger
Date: Thu May 24 10:16:11 2018
New Revision: 334140
URL: https://svnweb.freebsd.org/changeset/base/334140

Log:
  xenstore: remove the suspend sx lock
  
  There's no need to prevent suspend while doing xenstore transactions,
  callers of transactions are supposed to be prepared for a transaction
  to fail.
  
  This fixes a bug that could be triggered from the xenstore user-space
  device, since starting a transaction from user-space would result in
  returning there with a sx lock held, that causes a WITNESS check to
  trigger.
  
  Tested by:  Nathan Friess 
  Sponsored by:   Citrix Systems R

Modified:
  head/sys/dev/xen/xenstore/xenstore.c

Modified: head/sys/dev/xen/xenstore/xenstore.c
==
--- head/sys/dev/xen/xenstore/xenstore.cThu May 24 08:32:02 2018
(r334139)
+++ head/sys/dev/xen/xenstore/xenstore.cThu May 24 10:16:11 2018
(r334140)
@@ -202,18 +202,6 @@ struct xs_softc {
struct mtx watch_events_lock;
 
/**
-* Sleepable lock used to prevent VM suspension while a
-* xenstore transaction is outstanding.
-*
-* Each active transaction holds a shared lock on the
-* suspend mutex.  Our suspend method blocks waiting
-* to acquire an exclusive lock.  This guarantees that
-* suspend processing will only proceed once all active
-* transactions have been retired.
-*/
-   struct sx suspend_mutex;
-
-   /**
 * The processid of the xenwatch thread.
 */
pid_t xenwatch_pid;
@@ -710,50 +698,6 @@ xs_rcv_thread(void *arg __unused)
 }
 
 /* XenStore Message Request/Reply Processing 
-*/
-/**
- * Filter invoked before transmitting any message to the XenStore service.
- *
- * The role of the filter may expand, but currently serves to manage
- * the interactions of messages with transaction state.
- *
- * \param request_msg_type  The message type for the request.
- */
-static inline void
-xs_request_filter(uint32_t request_msg_type)
-{
-   if (request_msg_type == XS_TRANSACTION_START)
-   sx_slock(_mutex);
-}
-
-/**
- * Filter invoked after transmitting any message to the XenStore service.
- *
- * The role of the filter may expand, but currently serves to manage
- * the interactions of messages with transaction state.
- *
- * \param request_msg_type The message type for the original request.
- * \param reply_msg_type   The message type for any received reply.
- * \param request_reply_error  The error status from the attempt to send
- * the request or retrieve the reply.
- */
-static inline void
-xs_reply_filter(uint32_t request_msg_type,
-uint32_t reply_msg_type, int request_reply_error)
-{
-   /*
-* The count of transactions drops if we attempted
-* to end a transaction (even if that attempt fails
-* in error), we receive a transaction end acknowledgement,
-* or if our attempt to begin a transaction fails.
-*/
-   if (request_msg_type == XS_TRANSACTION_END
-|| (request_reply_error == 0 && reply_msg_type == XS_TRANSACTION_END)
-|| (request_msg_type == XS_TRANSACTION_START
- && (request_reply_error != 0 || reply_msg_type == XS_ERROR)))
-   sx_sunlock(_mutex);
-
-}
-
 #define xsd_error_count(sizeof(xsd_errors) / sizeof(xsd_errors[0]))
 
 /**
@@ -843,15 +787,12 @@ xs_dev_request_and_reply(struct xsd_sockmsg *msg, void
int error;
 
request_type = msg->type;
-   xs_request_filter(request_type);
 
sx_xlock(_mutex);
if ((error = xs_write_store(msg, sizeof(*msg) + msg->len)) == 0)
error = xs_read_reply(>type, >len, result);
sx_xunlock(_mutex);
 
-   xs_reply_filter(request_type, msg->type, error);
-
return (error);
 }
 
@@ -887,8 +828,6 @@ xs_talkv(struct xs_transaction t, enum xsd_sockmsg_typ
for (i = 0; i < num_vecs; i++)
msg.len += iovec[i].iov_len;
 
-   xs_request_filter(request_type);
-
sx_xlock(_mutex);
error = xs_write_store(, sizeof(msg));
if (error) {
@@ -908,7 +847,6 @@ xs_talkv(struct xs_transaction t, enum xsd_sockmsg_typ
 
 error_lock_held:
sx_xunlock(_mutex);
-   xs_reply_filter(request_type, msg.type, error);
if (error)
return (error);
 
@@ -1206,7 +1144,6 @@ xs_attach(device_t dev)
mtx_init(_lock, "reply lock", NULL, MTX_DEF);
sx_init(_mutex, "xenwatch");
sx_init(_mutex, "xenstore request");
-   sx_init(_mutex, "xenstore suspend");
mtx_init(_watches_lock, "watches", NULL, MTX_DEF);
mtx_init(_events_lock, "watch events", NULL, MTX_DEF);
 
@@ -1249,7 +1186,6 @@ xs_suspend(device_t dev)
if (error != 0)
return (error);
 
-   sx_xlock(_mutex);
  

svn commit: r334027 - head/sys/dev/xen/blkback

2018-05-22 Thread Roger Pau Monné
Author: royger
Date: Tue May 22 08:51:16 2018
New Revision: 334027
URL: https://svnweb.freebsd.org/changeset/base/334027

Log:
  xen-blkback: do not use state 3 (XenbusStateInitialised)
  
  Linux will not connect to a backend that's in state 3
  (XenbusStateInitialised), it needs to be in state 2
  (XenbusStateInitWait) for Linux to attempt to connect to the backend.
  
  The protocol seems to suggest that the backend should indeed wait in
  state 2 for the frontend to connect, which makes state 3 unusable for
  disk backends.
  
  Also make sure blkback will connect to the frontend if the frontend
  reaches state 3 (XenbusStateInitialised) before blkback has processed
  the results from the hotplug script (Submitted by Nathan Friess).
  
  MFC after:1 week

Modified:
  head/sys/dev/xen/blkback/blkback.c

Modified: head/sys/dev/xen/blkback/blkback.c
==
--- head/sys/dev/xen/blkback/blkback.c  Tue May 22 08:27:33 2018
(r334026)
+++ head/sys/dev/xen/blkback/blkback.c  Tue May 22 08:51:16 2018
(r334027)
@@ -806,6 +806,9 @@ struct xbb_softc {
 
/** Watch to wait for hotplug script execution */
struct xs_watch   hotplug_watch;
+
+   /** Got the needed data from hotplug scripts? */
+   bool  hotplug_done;
 };
 
 /* Request Processing 
*/
@@ -3310,12 +3313,11 @@ xbb_connect(struct xbb_softc *xbb)
 {
int error;
 
-   if (xenbus_get_state(xbb->dev) != XenbusStateInitialised)
+   if (!xbb->hotplug_done ||
+   (xenbus_get_state(xbb->dev) != XenbusStateInitWait) ||
+   (xbb_collect_frontend_info(xbb) != 0))
return;
 
-   if (xbb_collect_frontend_info(xbb) != 0)
-   return;
-
xbb->flags &= ~XBBF_SHUTDOWN;
 
/*
@@ -3412,6 +3414,7 @@ xbb_shutdown(struct xbb_softc *xbb)
free(xbb->hotplug_watch.node, M_XENBLOCKBACK);
xbb->hotplug_watch.node = NULL;
}
+   xbb->hotplug_done = false;
 
if (xenbus_get_state(xbb->dev) < XenbusStateClosing)
xenbus_set_state(xbb->dev, XenbusStateClosing);
@@ -3692,8 +3695,11 @@ xbb_attach_disk(struct xs_watch *watch, const char **v
return;
}
 
-   /* Tell the front end that we are ready to connect. */
-   xenbus_set_state(dev, XenbusStateInitialised);
+   xbb->hotplug_done = true;
+
+   /* The front end might be waiting for the backend, attach if so. */
+   if (xenbus_get_otherend_state(xbb->dev) == XenbusStateInitialised)
+   xbb_connect(xbb);
 }
 
 /**
@@ -3757,6 +3763,7 @@ xbb_attach(device_t dev)
 * We need to wait for hotplug script execution before
 * moving forward.
 */
+   KASSERT(!xbb->hotplug_done, ("Hotplug scripts already executed"));
watch_path = xs_join(xenbus_get_node(xbb->dev), "physical-device-path");
xbb->hotplug_watch.callback_data = (uintptr_t)dev;
xbb->hotplug_watch.callback = xbb_attach_disk;
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r333170 - head/sys/x86/xen

2018-05-02 Thread Roger Pau Monné
Author: royger
Date: Wed May  2 10:20:55 2018
New Revision: 333170
URL: https://svnweb.freebsd.org/changeset/base/333170

Log:
  xen: fix formatting of xen_init_ops
  
  No functional change
  
  Sponsored by: Citrix Systems R

Modified:
  head/sys/x86/xen/pv.c

Modified: head/sys/x86/xen/pv.c
==
--- head/sys/x86/xen/pv.c   Wed May  2 10:19:17 2018(r333169)
+++ head/sys/x86/xen/pv.c   Wed May  2 10:20:55 2018(r333170)
@@ -119,7 +119,7 @@ struct init_ops xen_init_ops = {
 #ifdef SMP
.start_all_aps  = xen_pv_start_all_aps,
 #endif
-   .msi_init = xen_msi_init,
+   .msi_init   = xen_msi_init,
 };
 
 static struct bios_smap xen_smap[MAX_E820_ENTRIES];
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r333169 - in head/sys: dev/xen/gntdev xen

2018-05-02 Thread Roger Pau Monné
Author: royger
Date: Wed May  2 10:19:17 2018
New Revision: 333169
URL: https://svnweb.freebsd.org/changeset/base/333169

Log:
  xen: fix gntdev
  
  Current interface to the gntdev in FreeBSD is wrong, and mostly worked
  out of luck before the PTI FreeBSD fixes, when kernel and user-space
  where sharing the same page tables.
  
  On FreeBSD ioctls have the size of the passed struct encoded in the
  ioctl number, because the generic ioctl handler in the OS takes care
  of copying the data from user-space to kernel space, and then calls
  the device specific ioctl handler. Thus using ioctl structs with
  variable sizes is not possible.
  
  The fix is to turn the array of structs at the end of
  ioctl_gntdev_alloc_gref and ioctl_gntdev_map_grant_ref into pointers,
  that can be properly accessed from the kernel gntdev driver using the
  copyin/copyout functions. Note that this is exactly how it's done for
  the privcmd driver.
  
  Sponsored by:   Citrix Systems R

Modified:
  head/sys/dev/xen/gntdev/gntdev.c
  head/sys/xen/gntdev.h

Modified: head/sys/dev/xen/gntdev/gntdev.c
==
--- head/sys/dev/xen/gntdev/gntdev.cWed May  2 08:26:59 2018
(r333168)
+++ head/sys/dev/xen/gntdev/gntdev.cWed May  2 10:19:17 2018
(r333169)
@@ -414,7 +414,7 @@ gntdev_alloc_gref(struct ioctl_gntdev_alloc_gref *arg)
/* Copy the output values. */
arg->index = file_offset;
for (i = 0; i < arg->count; i++)
-   arg->gref_ids[i] = grefs[i].gref_id;
+   suword32(>gref_ids[i], grefs[i].gref_id);
 
/* Modify the per user private data. */
mtx_lock(_user->user_data_lock);
@@ -659,16 +659,27 @@ gntdev_map_grant_ref(struct ioctl_gntdev_map_grant_ref
gmap->grant_map_ops =
malloc(sizeof(struct gnttab_map_grant_ref) * arg->count,
M_GNTDEV, M_WAITOK | M_ZERO);
-   
-   error = get_file_offset(priv_user, arg->count, >file_index);
-   if (error != 0)
-   return (error);
 
for (i = 0; i < arg->count; i++) {
-   gmap->grant_map_ops[i].dom = arg->refs[i].domid;
-   gmap->grant_map_ops[i].ref = arg->refs[i].ref;
+   struct ioctl_gntdev_grant_ref ref;
+
+   error = copyin(>refs[i], , sizeof(ref));
+   if (error != 0) {
+   free(gmap->grant_map_ops, M_GNTDEV);
+   free(gmap, M_GNTDEV);
+   return (error);
+   }
+   gmap->grant_map_ops[i].dom = ref.domid;
+   gmap->grant_map_ops[i].ref = ref.ref;
gmap->grant_map_ops[i].handle = -1;
gmap->grant_map_ops[i].flags = GNTMAP_host_map;
+   }
+
+   error = get_file_offset(priv_user, arg->count, >file_index);
+   if (error != 0) {
+   free(gmap->grant_map_ops, M_GNTDEV);
+   free(gmap, M_GNTDEV);
+   return (error);
}
 
mtx_lock(_user->user_data_lock);

Modified: head/sys/xen/gntdev.h
==
--- head/sys/xen/gntdev.h   Wed May  2 08:26:59 2018(r333168)
+++ head/sys/xen/gntdev.h   Wed May  2 10:19:17 2018(r333169)
@@ -139,7 +139,7 @@ struct ioctl_gntdev_alloc_gref {
 /* OUT parameters */
 uint64_t index;
 /* Variable OUT parameter */
-uint32_t gref_ids[1];
+uint32_t *gref_ids;
 };
 
 #define GNTDEV_ALLOC_FLAG_WRITABLE 1
@@ -168,7 +168,7 @@ struct ioctl_gntdev_map_grant_ref {
 /* OUT parameters */
 uint64_t index;
 /* Variable IN parameter */
-struct ioctl_gntdev_grant_ref refs[1];
+struct ioctl_gntdev_grant_ref *refs;
 };
 
 #define IOCTL_GNTDEV_UNMAP_GRANT_REF   \
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r332092 - in head/sys: amd64/amd64 sys x86/x86

2018-04-09 Thread Roger Pau Monné
On Fri, Apr 06, 2018 at 09:17:09AM -0700, Rodney W. Grimes wrote:
> [ Charset UTF-8 unsupported, converting... ]
> > Author: royger
> > Date: Fri Apr  6 11:20:06 2018
> > New Revision: 332092
> > URL: https://svnweb.freebsd.org/changeset/base/332092
> > 
> > Log:
> >   remove GiB/MiB macros from param.h
> >   
> >   And instead define them in the files where they are used.
> 
> It would of been better to "revert" your prior change and
> make a seperate new commit.  It is rarely desireable to combine
> a revert of a change with anything.

A plain revert of r332072 would have left the tree in a broken state,
because r332073 depends on those macros. IMO it's better to have a
buildable tree at all times in order for it to be bisectable.

Roger.
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r332109 - in head/sys: amd64/amd64 x86/x86

2018-04-06 Thread Roger Pau Monné
Author: royger
Date: Fri Apr  6 16:22:14 2018
New Revision: 332109
URL: https://svnweb.freebsd.org/changeset/base/332109

Log:
  x86: fix trampoline memory allocation after r332073
  
  Add the missing breaks in the for loops, in order to exit the loop
  when a suitable entry is found.
  
  Also switch amd64 native_start_all_aps to use PHYS_TO_DMAP in order to
  find the virtual address of the boot_trampoline and the initial page
  tables.
  
  Reported and tested by:   pho
  Sponsored by: Citrix Systems R

Modified:
  head/sys/amd64/amd64/mp_machdep.c
  head/sys/x86/x86/mp_x86.c

Modified: head/sys/amd64/amd64/mp_machdep.c
==
--- head/sys/amd64/amd64/mp_machdep.c   Fri Apr  6 15:57:20 2018
(r332108)
+++ head/sys/amd64/amd64/mp_machdep.c   Fri Apr  6 16:22:14 2018
(r332109)
@@ -128,6 +128,7 @@ mp_bootaddress(vm_paddr_t *physmap, unsigned int *phys
sizeof(*physmap) * (*physmap_idx - i + 2));
*physmap_idx -= 2;
}
+   break;
}
 
if (!allocated) {
@@ -336,7 +337,6 @@ init_secondary(void)
 int
 native_start_all_aps(void)
 {
-   vm_offset_t va = boot_address + KERNBASE;
u_int64_t *pt4, *pt3, *pt2;
u_int32_t mpbioswarmvec;
int apic_id, cpu, i;
@@ -344,13 +344,11 @@ native_start_all_aps(void)
 
mtx_init(_boot_mtx, "ap boot", NULL, MTX_SPIN);
 
-   /* install the AP 1st level boot code */
-   pmap_kenter(va, boot_address);
-   pmap_invalidate_page(kernel_pmap, va);
-   bcopy(mptramp_start, (void *)va, bootMP_size);
+   /* copy the AP 1st level boot code */
+   bcopy(mptramp_start, (void *)PHYS_TO_DMAP(boot_address), bootMP_size);
 
/* Locate the page tables, they'll be below the trampoline */
-   pt4 = (u_int64_t *)(uintptr_t)(mptramp_pagetables + KERNBASE);
+   pt4 = (uint64_t *)PHYS_TO_DMAP(mptramp_pagetables);
pt3 = pt4 + (PAGE_SIZE) / sizeof(u_int64_t);
pt2 = pt3 + (PAGE_SIZE) / sizeof(u_int64_t);
 

Modified: head/sys/x86/x86/mp_x86.c
==
--- head/sys/x86/x86/mp_x86.c   Fri Apr  6 15:57:20 2018(r332108)
+++ head/sys/x86/x86/mp_x86.c   Fri Apr  6 16:22:14 2018(r332109)
@@ -947,6 +947,7 @@ alloc_ap_trampoline(vm_paddr_t *physmap, unsigned int 
sizeof(*physmap) * (*physmap_idx - i + 2));
*physmap_idx -= 2;
}
+   break;
}
 
if (!allocated) {
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r332092 - in head/sys: amd64/amd64 sys x86/x86

2018-04-06 Thread Roger Pau Monné
Author: royger
Date: Fri Apr  6 11:20:06 2018
New Revision: 332092
URL: https://svnweb.freebsd.org/changeset/base/332092

Log:
  remove GiB/MiB macros from param.h
  
  And instead define them in the files where they are used.
  
  Requested by: bde

Modified:
  head/sys/amd64/amd64/mp_machdep.c
  head/sys/sys/param.h
  head/sys/x86/x86/mp_x86.c

Modified: head/sys/amd64/amd64/mp_machdep.c
==
--- head/sys/amd64/amd64/mp_machdep.c   Fri Apr  6 09:25:08 2018
(r332091)
+++ head/sys/amd64/amd64/mp_machdep.c   Fri Apr  6 11:20:06 2018
(r332092)
@@ -83,6 +83,8 @@ __FBSDID("$FreeBSD$");
 #define BIOS_RESET (0x0f)
 #define BIOS_WARM  (0x0a)
 
+#define GiB(v) (v ## ULL << 30)
+
 extern struct pcpu __pcpu[];
 
 /* Temporary variables for init_secondary()  */

Modified: head/sys/sys/param.h
==
--- head/sys/sys/param.hFri Apr  6 09:25:08 2018(r332091)
+++ head/sys/sys/param.hFri Apr  6 11:20:06 2018(r332092)
@@ -362,8 +362,4 @@ __END_DECLS
  */
 #define __PAST_END(array, offset) (((__typeof__(*(array)) *)(array))[offset])
 
-/* Unit conversion macros. */
-#define GiB(v) (v ## ULL << 30)
-#define MiB(v) (v ## ULL << 20)
-
 #endif /* _SYS_PARAM_H_ */

Modified: head/sys/x86/x86/mp_x86.c
==
--- head/sys/x86/x86/mp_x86.c   Fri Apr  6 09:25:08 2018(r332091)
+++ head/sys/x86/x86/mp_x86.c   Fri Apr  6 11:20:06 2018(r332092)
@@ -160,6 +160,8 @@ struct cache_info {
 
 unsigned int boot_address;
 
+#define MiB(v) (v ## ULL << 20)
+
 void
 mem_range_AP_init(void)
 {
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r332072 - head/sys/sys

2018-04-06 Thread Roger Pau Monné
On Fri, Apr 06, 2018 at 03:12:08AM +1000, Bruce Evans wrote:
> On Thu, 5 Apr 2018, Warner Losh wrote:
> 
> > On Thu, Apr 5, 2018 at 9:46 AM, Roger Pau Monné <roy...@freebsd.org> wrote:
> > 
> > > On Thu, Apr 05, 2018 at 09:32:57AM -0600, Ian Lepore wrote:
> > > > On Thu, 2018-04-05 at 14:31 +, Roger Pau Monné wrote:
> > > > > Log:
> > > > >   introduce GiB and MiB macros
> > > > > ...
> > > > > +/* Unit conversion macros. */
> > > > > +#define GiB(v) (v ## ULL << 30)
> > > > > +#define MiB(v) (v ## ULL << 20)
> > > > > +
> > > > >  #endif /* _SYS_PARAM_H_ */
> > > > 
> > > > These names don't make it clear whether the conversion is bytes->GiB or
> > > > GiB->bytes.  The names seem way too generic for a public namespace in a
> > > > file as heavily included behind your back as param.h is.
> > > > 
> > > > Also, this completely reasonable usage won't work, likely with
> > > > confusing compile error messages:
> > > > 
> > > >   int bytes, gibytes;
> > > >   ...
> > > >   bytes = GiB(gibytes);
> > > 
> > > I find those helpful for their specific usage. I could introduce
> > > static inline functions like:
> > > 
> > > size_t gb_to_bytes(size_t)...
> > > 
> > > But I assume this is also going to cause further discussion.
> 
> Yes, it gives even more namespace pollution and type errors.  Macros
> at least don't expose their internals if they are not used.
> 
> size_t is actually already part of the undocumented namespace pollution
> in .
> 
> The type errors are restriction to just one type in another way.  Type-
> generic APIs that avoid such restrictions are much harder to implement
> using inline functions than macros.
> 
> > Yea, traditional macro names would be "gibtob" and "btogib" but I didn't
> > just reply to bikeshed a name:
> > 
> > But you don't need to specify a type, consider the current btodb macro:
> > #define btodb(bytes)/* calculates (bytes / DEV_BSIZE)
> > */ \
> >(sizeof (bytes) > sizeof(long) \
> > ? (daddr_t)((unsigned long long)(bytes) >> DEV_BSHIFT) \
> > : (daddr_t)((unsigned long)(bytes) >> DEV_BSHIFT))
> > 
> > which shows how to do this in a macro, which is orthogonal to any name you
> > may choose. I can also bikeshed function vs macro :)
> 
> This macro is mostly my mistake in 1995-1996.  The long long abominations
> in it were supposed to be temporary (until C99 standardized something
> better).  It was originally MD for i386 only and then the sizes of almost
> all types are known and fixed so it is easier to hard-code minimal sizes
> that work.  The optimization of avoiding using 64-bit types was more needed
> in 1995-1996 since CPUs were slower and compilers did less strength reduction.
> 
> btodb() is much easier than dbtob() since it shifts right, so it can't
> overflow unless the cast of 'bytes' is wrong so that it truncations.
> dbtob() doesn't try hard to be optimal.  It just always upcasts to
> off_t.
> 
> jake later convinced me (in connection with his PAE and sparc64 work) that
> it should be the caller's responsibility to avoid overflow.  Any casts in
> the macro limits it to the types in it.  This is why the page to byte
> conversion macros don't have any casts in them.  PAE usually needs 64-bit
> results, but this would just be a pessimization for normal i386, and
> deciding the casts in the macro as above is complicated.
> 
> So correct GB() macros would look like ((v) << 30), where the caller must
> cast v to a large enough type.  E.g., for variable v which might be larger
> than 4, on 32-bit systems, the caller must write something like
> GB((uintmax_t)v).  But it is easier for writing to just multiply v by 1G.
> This is also easier for reading since it is unclear that GB() is even a
> conversion or which direction it goes in.  A longer descriptive name would
> be about as clear and long as an explicit multiplication.
> 
> I usually write 1G as ((type)1024 * 1024 * 1024) since the decimal and
> even hex values of 1G have too many digits to be clear, and
> multiplication is clearer than shifting and allows the type to be in
> the factor.
> 
> Disk block size conversions need to use macros since the DEV_BSIZE = 512
> was variable in theory (in practice this is now a fixed virtual size).
> Conversions to G don't need macros since the magic number in them is no
> more magic than the G in their name.

I personally find the following chunk:

if (addr < GiB(4))
...

Much more easier to read and parse than:

if (addr < (4 * 1024 * 1024 * 1024))
...

But I won't insist anymore.

I will revert this and introduce the macros locally where I need them.

Roger.
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r332072 - head/sys/sys

2018-04-05 Thread Roger Pau Monné
On Thu, Apr 05, 2018 at 09:58:36AM -0600, Warner Losh wrote:
> On Thu, Apr 5, 2018 at 9:46 AM, Roger Pau Monné <roy...@freebsd.org> wrote:
> 
> > On Thu, Apr 05, 2018 at 09:32:57AM -0600, Ian Lepore wrote:
> > > On Thu, 2018-04-05 at 14:31 +, Roger Pau Monné wrote:
> > > > Author: royger
> > > > Date: Thu Apr  5 14:31:54 2018
> > > > New Revision: 332072
> > > > URL: https://svnweb.freebsd.org/changeset/base/332072
> > > >
> > > > Log:
> > > >   introduce GiB and MiB macros
> > > >
> > > >   This macros convert from GiB or MiB into bytes.
> > > >
> > > >   Sponsored by: Citrix Systems R
> > > >
> > > > Modified:
> > > >   head/sys/sys/param.h
> > > >
> > > > Modified: head/sys/sys/param.h
> > > > 
> > ==
> > > > --- head/sys/sys/param.hThu Apr  5 14:25:39 2018(r332071)
> > > > +++ head/sys/sys/param.hThu Apr  5 14:31:54 2018(r332072)
> > > > @@ -362,4 +362,8 @@ __END_DECLS
> > > >   */
> > > >  #define __PAST_END(array, offset) (((__typeof__(*(array))
> > *)(array))[offset])
> > > >
> > > > +/* Unit conversion macros. */
> > > > +#define GiB(v) (v ## ULL << 30)
> > > > +#define MiB(v) (v ## ULL << 20)
> > > > +
> > > >  #endif /* _SYS_PARAM_H_ */
> > > >
> > >
> > > These names don't make it clear whether the conversion is bytes->GiB or
> > > GiB->bytes.  The names seem way too generic for a public namespace in a
> > > file as heavily included behind your back as param.h is.
> > >
> > > Also, this completely reasonable usage won't work, likely with
> > > confusing compile error messages:
> > >
> > >   int bytes, gibytes;
> > >   ...
> > >   bytes = GiB(gibytes);
> >
> > I find those helpful for their specific usage. I could introduce
> > static inline functions like:
> >
> > size_t gb_to_bytes(size_t)...
> >
> > But I assume this is also going to cause further discussion.
> >
> 
> Yea, traditional macro names would be "gibtob" and "btogib" but I didn't
> just reply to bikeshed a name:
> 
> But you don't need to specify a type, consider the current btodb macro:
> #define btodb(bytes)/* calculates (bytes / DEV_BSIZE)
> */ \
> (sizeof (bytes) > sizeof(long) \
>  ? (daddr_t)((unsigned long long)(bytes) >> DEV_BSHIFT) \
>  : (daddr_t)((unsigned long)(bytes) >> DEV_BSHIFT))
> 
> which shows how to do this in a macro, which is orthogonal to any name you
> may choose. I can also bikeshed function vs macro :)

I was just going to remove those from here and place them in the files
where I use them, but I can also change them to:

#define gibtob(gib) ((unsigned long long)(gib) << 30)
#define mibtob(mib) ((unsigned long long)(mib) << 20)

If it's not going to start a bikeshed.

Thanks, Roger.
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r332072 - head/sys/sys

2018-04-05 Thread Roger Pau Monné
On Thu, Apr 05, 2018 at 09:32:57AM -0600, Ian Lepore wrote:
> On Thu, 2018-04-05 at 14:31 +0000, Roger Pau Monné wrote:
> > Author: royger
> > Date: Thu Apr  5 14:31:54 2018
> > New Revision: 332072
> > URL: https://svnweb.freebsd.org/changeset/base/332072
> > 
> > Log:
> >   introduce GiB and MiB macros
> >   
> >   This macros convert from GiB or MiB into bytes.
> >   
> >   Sponsored by: Citrix Systems R
> > 
> > Modified:
> >   head/sys/sys/param.h
> > 
> > Modified: head/sys/sys/param.h
> > ==
> > --- head/sys/sys/param.hThu Apr  5 14:25:39 2018(r332071)
> > +++ head/sys/sys/param.hThu Apr  5 14:31:54 2018(r332072)
> > @@ -362,4 +362,8 @@ __END_DECLS
> >   */
> >  #define __PAST_END(array, offset) (((__typeof__(*(array)) 
> > *)(array))[offset])
> >  
> > +/* Unit conversion macros. */
> > +#define GiB(v) (v ## ULL << 30)
> > +#define MiB(v) (v ## ULL << 20)
> > +
> >  #endif /* _SYS_PARAM_H_ */
> > 
> 
> These names don't make it clear whether the conversion is bytes->GiB or
> GiB->bytes.  The names seem way too generic for a public namespace in a
> file as heavily included behind your back as param.h is.
> 
> Also, this completely reasonable usage won't work, likely with
> confusing compile error messages:
> 
>   int bytes, gibytes;
>   ...
>   bytes = GiB(gibytes);

I find those helpful for their specific usage. I could introduce
static inline functions like:

size_t gb_to_bytes(size_t)...

But I assume this is also going to cause further discussion.

Roger.
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r332073 - in head/sys: amd64/amd64 amd64/include i386/i386 i386/include x86/include x86/x86

2018-04-05 Thread Roger Pau Monné
Author: royger
Date: Thu Apr  5 14:39:51 2018
New Revision: 332073
URL: https://svnweb.freebsd.org/changeset/base/332073

Log:
  x86: improve reservation of AP trampoline memory
  
  So that it doesn't rely on physmap[1] containing an address below
  1MiB. Instead scan the full physmap and search for a suitable address
  to place the trampoline code (below 1MiB) and the initial memory pages
  (below 4GiB).
  
  Sponsored by: Citrix Systems R
  Reviewed by:  kib
  Differential Revision:https://reviews.freebsd.org/D14878

Modified:
  head/sys/amd64/amd64/machdep.c
  head/sys/amd64/amd64/mp_machdep.c
  head/sys/amd64/amd64/mpboot.S
  head/sys/amd64/include/smp.h
  head/sys/i386/i386/machdep.c
  head/sys/i386/i386/mp_machdep.c
  head/sys/i386/include/smp.h
  head/sys/x86/include/init.h
  head/sys/x86/include/x86_smp.h
  head/sys/x86/x86/mp_x86.c

Modified: head/sys/amd64/amd64/machdep.c
==
--- head/sys/amd64/amd64/machdep.c  Thu Apr  5 14:31:54 2018
(r332072)
+++ head/sys/amd64/amd64/machdep.c  Thu Apr  5 14:39:51 2018
(r332073)
@@ -1246,14 +1246,10 @@ getmemsize(caddr_t kmdp, u_int64_t first)
 * Make hole for "AP -> long mode" bootstrap code.  The
 * mp_bootaddress vector is only available when the kernel
 * is configured to support APs and APs for the system start
-* in 32bit mode (e.g. SMP bare metal).
+* in real mode mode (e.g. SMP bare metal).
 */
-   if (init_ops.mp_bootaddress) {
-   if (physmap[1] >= 0x1)
-   panic(
-   "Basemem segment is not suitable for AP bootstrap code!");
-   physmap[1] = init_ops.mp_bootaddress(physmap[1] / 1024);
-   }
+   if (init_ops.mp_bootaddress)
+   init_ops.mp_bootaddress(physmap, _idx);
 
/*
 * Maxmem isn't the "maximum memory", it's one larger than the

Modified: head/sys/amd64/amd64/mp_machdep.c
==
--- head/sys/amd64/amd64/mp_machdep.c   Thu Apr  5 14:31:54 2018
(r332072)
+++ head/sys/amd64/amd64/mp_machdep.c   Thu Apr  5 14:39:51 2018
(r332073)
@@ -96,24 +96,45 @@ char *nmi_stack;
 
 static int start_ap(int apic_id);
 
-static u_int   bootMP_size;
-static u_int   boot_address;
-
 /*
  * Calculate usable address in base memory for AP trampoline code.
  */
-u_int
-mp_bootaddress(u_int basemem)
+void
+mp_bootaddress(vm_paddr_t *physmap, unsigned int *physmap_idx)
 {
+   unsigned int i;
+   bool allocated;
 
-   bootMP_size = mptramp_end - mptramp_start;
-   boot_address = trunc_page(basemem * 1024); /* round down to 4k boundary 
*/
-   if (((basemem * 1024) - boot_address) < bootMP_size)
-   boot_address -= PAGE_SIZE;  /* not enough, lower by 4k */
-   /* 3 levels of page table pages */
-   mptramp_pagetables = boot_address - (PAGE_SIZE * 3);
+   alloc_ap_trampoline(physmap, physmap_idx);
 
-   return mptramp_pagetables;
+   allocated = false;
+   for (i = *physmap_idx; i <= *physmap_idx; i -= 2) {
+   /*
+* Find a memory region big enough below the 4GB boundary to
+* store the initial page tables. Note that it needs to be
+* aligned to a page boundary.
+*/
+   if (physmap[i] >= GiB(4) ||
+   (physmap[i + 1] - round_page(physmap[i])) < (PAGE_SIZE * 3))
+   continue;
+
+   allocated = true;
+   mptramp_pagetables = round_page(physmap[i]);
+   physmap[i] = round_page(physmap[i]) + (PAGE_SIZE * 3);
+   if (physmap[i] == physmap[i + 1] && *physmap_idx != 0) {
+   memmove([i], [i + 2],
+   sizeof(*physmap) * (*physmap_idx - i + 2));
+   *physmap_idx -= 2;
+   }
+   }
+
+   if (!allocated) {
+   mptramp_pagetables = trunc_page(boot_address) - (PAGE_SIZE * 3);
+   if (bootverbose)
+   printf(
+"Cannot find enough space for the initial AP page tables, placing them at %#x",
+   mptramp_pagetables);
+   }
 }
 
 /*

Modified: head/sys/amd64/amd64/mpboot.S
==
--- head/sys/amd64/amd64/mpboot.S   Thu Apr  5 14:31:54 2018
(r332072)
+++ head/sys/amd64/amd64/mpboot.S   Thu Apr  5 14:39:51 2018
(r332073)
@@ -216,8 +216,14 @@ lgdt_desc: 
.word   gdtend-gdt  /* Length */
.long   gdt-mptramp_start   /* Offset plus %ds << 4 */
 
-   .globl  mptramp_end
 mptramp_end:
+   /*
+* The size of the trampoline code that needs to be relocated
+* below the 1MiB boundary.
+*/
+   .globl  bootMP_size

svn commit: r332072 - head/sys/sys

2018-04-05 Thread Roger Pau Monné
Author: royger
Date: Thu Apr  5 14:31:54 2018
New Revision: 332072
URL: https://svnweb.freebsd.org/changeset/base/332072

Log:
  introduce GiB and MiB macros
  
  This macros convert from GiB or MiB into bytes.
  
  Sponsored by: Citrix Systems R

Modified:
  head/sys/sys/param.h

Modified: head/sys/sys/param.h
==
--- head/sys/sys/param.hThu Apr  5 14:25:39 2018(r332071)
+++ head/sys/sys/param.hThu Apr  5 14:31:54 2018(r332072)
@@ -362,4 +362,8 @@ __END_DECLS
  */
 #define __PAST_END(array, offset) (((__typeof__(*(array)) *)(array))[offset])
 
+/* Unit conversion macros. */
+#define GiB(v) (v ## ULL << 30)
+#define MiB(v) (v ## ULL << 20)
+
 #endif /* _SYS_PARAM_H_ */
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r330835 - in head: share/man/man4 sys/x86/isa

2018-03-13 Thread Roger Pau Monné
Author: royger
Date: Tue Mar 13 09:42:33 2018
New Revision: 330835
URL: https://svnweb.freebsd.org/changeset/base/330835

Log:
  at_rtc: check in ACPI FADT boot flags if the RTC is present
  
  Or else disable the device. Note that the detection can be bypassed by
  setting the hw.atrtc.enable option in the loader configuration file.
  More information can be found on atrtc(4).
  
  Sponsored by: Citrix Systems R
  Reviewed by:  ian
  Differential revision:https://reviews.freebsd.org/D14399

Modified:
  head/share/man/man4/atrtc.4
  head/sys/x86/isa/atrtc.c

Modified: head/share/man/man4/atrtc.4
==
--- head/share/man/man4/atrtc.4 Tue Mar 13 09:38:53 2018(r330834)
+++ head/share/man/man4/atrtc.4 Tue Mar 13 09:42:33 2018(r330835)
@@ -33,13 +33,18 @@
 .Sh SYNOPSIS
 This driver is a mandatory part of i386/amd64 kernels.
 .Pp
-The following tunable is settable from the
+The following tunables are settable from the
 .Xr loader 8 :
 .Bl -ohang
 .It Va hint.atrtc. Ns Ar X Ns Va .clock
 controls event timers functionality support.
 Setting to 0, disables it.
 Default value is 1.
+.It Va hw.atrtc.enable
+Forces enabling or disabling of the device(s).
+Setting to 0 disables it, setting to 1 enables it, bypassing any platform
+configuration hints.
+Default value is -1 (autodetect).
 .El
 .Sh DESCRIPTION
 This driver uses RTC hardware to supply kernel with time-of-day clock

Modified: head/sys/x86/isa/atrtc.c
==
--- head/sys/x86/isa/atrtc.cTue Mar 13 09:38:53 2018(r330834)
+++ head/sys/x86/isa/atrtc.cTue Mar 13 09:42:33 2018(r330835)
@@ -32,6 +32,7 @@
 #include 
 __FBSDID("$FreeBSD$");
 
+#include "opt_acpi.h"
 #include "opt_isa.h"
 
 #include 
@@ -55,6 +56,10 @@ __FBSDID("$FreeBSD$");
 #include 
 #include "clock_if.h"
 
+#ifdef DEV_ACPI
+#include 
+#endif
+
 /*
  * atrtc_lock protects low-level access to individual hardware registers.
  * atrtc_time_lock protects the entire sequence of accessing multiple registers
@@ -63,6 +68,10 @@ __FBSDID("$FreeBSD$");
 static struct mtx atrtc_lock;
 MTX_SYSINIT(atrtc_lock_init, _lock, "atrtc", MTX_SPIN);
 
+/* Force RTC enabled/disabled. */
+static int atrtc_enabled = -1;
+TUNABLE_INT("hw.atrtc.enabled", _enabled);
+
 struct mtx atrtc_time_lock;
 MTX_SYSINIT(atrtc_time_lock_init, _time_lock, "atrtc_time", MTX_DEF);
 
@@ -249,11 +258,43 @@ static struct isa_pnp_id atrtc_ids[] = {
{ 0 }
 };
 
+static bool
+atrtc_acpi_disabled(void)
+{
+#ifdef DEV_ACPI
+   ACPI_TABLE_FADT *fadt;
+   vm_paddr_t physaddr;
+   uint16_t flags;
+
+   physaddr = acpi_find_table(ACPI_SIG_FADT);
+   if (physaddr == 0)
+   return (false);
+
+   fadt = acpi_map_table(physaddr, ACPI_SIG_FADT);
+   if (fadt == NULL) {
+   printf("at_rtc: unable to map FADT ACPI table\n");
+   return (false);
+   }
+
+   flags = fadt->BootFlags;
+   acpi_unmap_table(fadt);
+
+   if (flags & ACPI_FADT_NO_CMOS_RTC)
+   return (true);
+#endif
+
+   return (false);
+}
+
 static int
 atrtc_probe(device_t dev)
 {
int result;
-   
+
+   if ((atrtc_enabled == -1 && atrtc_acpi_disabled()) ||
+   (atrtc_enabled == 0))
+   return (ENXIO);
+
result = ISA_PNP_PROBE(device_get_parent(dev), dev, atrtc_ids);
/* ENOENT means no PnP-ID, device is hinted. */
if (result == ENOENT) {
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r330834 - head/sys/dev/vt/hw/vga

2018-03-13 Thread Roger Pau Monné
Author: royger
Date: Tue Mar 13 09:38:53 2018
New Revision: 330834
URL: https://svnweb.freebsd.org/changeset/base/330834

Log:
  vt_vga: check if VGA is available from ACPI FADT table
  
  On x86 the IA-PC Boot Flags in the FADT can signal whether VGA is
  available or not.
  
  Sponsored by: Citrix systems R
  Reviewed by:  marcel
  Differential revision:https://reviews.freebsd.org/D14397

Modified:
  head/sys/dev/vt/hw/vga/vt_vga.c

Modified: head/sys/dev/vt/hw/vga/vt_vga.c
==
--- head/sys/dev/vt/hw/vga/vt_vga.c Tue Mar 13 09:29:56 2018
(r330833)
+++ head/sys/dev/vt/hw/vga/vt_vga.c Tue Mar 13 09:38:53 2018
(r330834)
@@ -30,6 +30,8 @@
  * SUCH DAMAGE.
  */
 
+#include "opt_acpi.h"
+
 #include 
 __FBSDID("$FreeBSD$");
 
@@ -46,6 +48,10 @@ __FBSDID("$FreeBSD$");
 
 #include 
 
+#if ((defined(__amd64__) || defined(__i386__)) && defined(DEV_ACPI))
+#include 
+#endif
+
 struct vga_softc {
bus_space_tag_t  vga_fb_tag;
bus_space_handle_t   vga_fb_handle;
@@ -1196,11 +1202,39 @@ vga_initialize(struct vt_device *vd, int textmode)
return (0);
 }
 
+static bool
+vga_acpi_disabled(void)
+{
+#if ((defined(__amd64__) || defined(__i386__)) && defined(DEV_ACPI))
+   ACPI_TABLE_FADT *fadt;
+   vm_paddr_t physaddr;
+   uint16_t flags;
+
+   physaddr = acpi_find_table(ACPI_SIG_FADT);
+   if (physaddr == 0)
+   return (false);
+
+   fadt = acpi_map_table(physaddr, ACPI_SIG_FADT);
+   if (fadt == NULL) {
+   printf("vt_vga: unable to map FADT ACPI table\n");
+   return (false);
+   }
+
+   flags = fadt->BootFlags;
+   acpi_unmap_table(fadt);
+
+   if (flags & ACPI_FADT_NO_VGA)
+   return (true);
+#endif
+
+   return (false);
+}
+
 static int
 vga_probe(struct vt_device *vd)
 {
 
-   return (CN_INTERNAL);
+   return (vga_acpi_disabled() ? CN_DEAD : CN_INTERNAL);
 }
 
 static int
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r329389 - head/sys/x86/xen

2018-02-16 Thread Roger Pau Monné
Author: royger
Date: Fri Feb 16 18:04:27 2018
New Revision: 329389
URL: https://svnweb.freebsd.org/changeset/base/329389

Log:
  xen/pv: remove the attach of the ISA bus from the Xen PV bus
  
  There's no need to attach the ISA bus from the Xen PV one.
  
  Sponsored by:   Citrix Systems R

Modified:
  head/sys/x86/xen/xenpv.c

Modified: head/sys/x86/xen/xenpv.c
==
--- head/sys/x86/xen/xenpv.cFri Feb 16 17:50:06 2018(r329388)
+++ head/sys/x86/xen/xenpv.cFri Feb 16 18:04:27 2018(r329389)
@@ -93,24 +93,20 @@ xenpv_probe(device_t dev)
 static int
 xenpv_attach(device_t dev)
 {
-   device_t child;
+   int error;
 
/*
 * Let our child drivers identify any child devices that they
 * can find.  Once that is done attach any devices that we
 * found.
 */
-   bus_generic_probe(dev);
-   bus_generic_attach(dev);
+   error = bus_generic_probe(dev);
+   if (error)
+   return (error);
 
-   if (!devclass_get_device(devclass_find("isa"), 0)) {
-   child = BUS_ADD_CHILD(dev, 0, "isa", 0);
-   if (child == NULL)
-   panic("Failed to attach ISA bus.");
-   device_probe_and_attach(child);
-   }
+   error = bus_generic_attach(dev);
 
-   return (0);
+   return (error);
 }
 
 static struct resource *
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r329219 - head

2018-02-13 Thread Roger Pau Monné
Author: royger
Date: Tue Feb 13 16:25:43 2018
New Revision: 329219
URL: https://svnweb.freebsd.org/changeset/base/329219

Log:
  list myself in the MAINTAINERS file for Xen bits

Modified:
  head/MAINTAINERS

Modified: head/MAINTAINERS
==
--- head/MAINTAINERSTue Feb 13 16:07:39 2018(r329218)
+++ head/MAINTAINERSTue Feb 13 16:25:43 2018(r329219)
@@ -92,8 +92,11 @@ sys/dev/ixgbeerj Pre-commit phabricator review 
reques
 sys/dev/ixlerj Pre-commit phabricator review requested.
 sys/dev/sound/usb  hselaskyIf in doubt, ask.
 sys/dev/usbhselaskyIf in doubt, ask.
+sys/dev/xenroyger  Pre-commit review recommended.
 sys/netinet/ip_carp.c  glebius Pre-commit review recommended.
 sys/netpfil/pf kp,glebius  Pre-commit review recommended.
+sys/x86/xenroyger  Pre-commit review recommended.
+sys/xenroyger  Pre-commit review recommended.
 tests  freebsd-testing,ngiePre-commit review requested.
 usr.sbin/bsdconfig dteske  Pre-commit phabricator review requested.
 usr.sbin/dpv   dteske  Pre-commit review requested. Keep in sync with libdpv.
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r329060 - head/stand/common

2018-02-09 Thread Roger Pau Monné
Author: royger
Date: Fri Feb  9 10:20:16 2018
New Revision: 329060
URL: https://svnweb.freebsd.org/changeset/base/329060

Log:
  loader: fix endianness conversion
  
  r328536 broke symbol loading on amd64 at least (and probably other
  arches). r328826 contained the problem to ppc only by adding
  pre-processors guards.
  
  Fix this properly by moving the endianness conversion to separate
  helper functions, and make the conversion more robust by using sizeof
  instead of having to manually code the size of each field.
  
  Finally list the fields in each structure in a macro in order to avoid
  code repetition.
  
  Sponsored by: Citrix Systems R
  Reviewed by:  kib emaste wma
  Differential revision:https://reviews.freebsd.org/D14267

Modified:
  head/stand/common/load_elf.c

Modified: head/stand/common/load_elf.c
==
--- head/stand/common/load_elf.cFri Feb  9 09:15:43 2018
(r329059)
+++ head/stand/common/load_elf.cFri Feb  9 10:20:16 2018
(r329060)
@@ -87,6 +87,112 @@ const char  *__elfN(moduletype) = "elf module";
 
 u_int64_t  __elfN(relocation_offset) = 0;
 
+extern void elf_wrong_field_size(void);
+#define CONVERT_FIELD(b, f, e) \
+   switch (sizeof((b)->f)) {   \
+   case 2: \
+   (b)->f = e ## 16toh((b)->f);\
+   break;  \
+   case 4: \
+   (b)->f = e ## 32toh((b)->f);\
+   break;  \
+   case 8: \
+   (b)->f = e ## 64toh((b)->f);\
+   break;  \
+   default:\
+   /* Force a link time error. */  \
+   elf_wrong_field_size(); \
+   break;  \
+   }
+
+#define CONVERT_SWITCH(h, d, f)\
+   switch ((h)->e_ident[EI_DATA]) {\
+   case ELFDATA2MSB:   \
+   f(d, be);   \
+   break;  \
+   case ELFDATA2LSB:   \
+   f(d, le);   \
+   break;  \
+   default:\
+   return (EINVAL);\
+   }
+
+
+static int elf_header_convert(Elf_Ehdr *ehdr)
+{
+   /*
+* Fixup ELF header endianness.
+*
+* The Xhdr structure was loaded using block read call to optimize file
+* accesses. It might happen, that the endianness of the system memory
+* is different that endianness of the ELF header.  Swap fields here to
+* guarantee that Xhdr always contain valid data regardless of
+* architecture.
+*/
+#define HEADER_FIELDS(b, e)\
+   CONVERT_FIELD(b, e_type, e);\
+   CONVERT_FIELD(b, e_machine, e); \
+   CONVERT_FIELD(b, e_version, e); \
+   CONVERT_FIELD(b, e_entry, e);   \
+   CONVERT_FIELD(b, e_phoff, e);   \
+   CONVERT_FIELD(b, e_shoff, e);   \
+   CONVERT_FIELD(b, e_flags, e);   \
+   CONVERT_FIELD(b, e_ehsize, e);  \
+   CONVERT_FIELD(b, e_phentsize, e);   \
+   CONVERT_FIELD(b, e_phnum, e);   \
+   CONVERT_FIELD(b, e_shentsize, e);   \
+   CONVERT_FIELD(b, e_shnum, e);   \
+   CONVERT_FIELD(b, e_shstrndx, e)
+
+   CONVERT_SWITCH(ehdr, ehdr, HEADER_FIELDS);
+
+#undef HEADER_FIELDS
+
+   return (0);
+}
+
+static int elf_program_header_convert(const Elf_Ehdr *ehdr, Elf_Phdr *phdr)
+{
+#define PROGRAM_HEADER_FIELDS(b, e)\
+   CONVERT_FIELD(b, p_type, e);\
+   CONVERT_FIELD(b, p_flags, e);   \
+   CONVERT_FIELD(b, p_offset, e);  \
+   CONVERT_FIELD(b, p_vaddr, e);   \
+   CONVERT_FIELD(b, p_paddr, e);   \
+   CONVERT_FIELD(b, p_filesz, e);  \
+   CONVERT_FIELD(b, p_memsz, e);   \
+   CONVERT_FIELD(b, p_align, e)
+
+   CONVERT_SWITCH(ehdr, phdr, PROGRAM_HEADER_FIELDS);
+
+#undef PROGRAM_HEADER_FIELDS
+
+   return (0);
+}
+
+static int elf_section_header_convert(const Elf_Ehdr *ehdr, Elf_Shdr *shdr)
+{
+#define SECTION_HEADER_FIELDS(b, e)\
+   CONVERT_FIELD(b, sh_name, e);   \
+   CONVERT_FIELD(b, sh_type, e);   \
+   CONVERT_FIELD(b, sh_link, e);   \
+   CONVERT_FIELD(b, sh_info, e);   \
+   CONVERT_FIELD(b, sh_flags, e);  \
+   CONVERT_FIELD(b, sh_addr, e);   \
+   CONVERT_FIELD(b, sh_offset, e); \
+   CONVERT_FIELD(b, sh_size, e);   \
+   CONVERT_FIELD(b, 

Re: svn commit: r328536 - in head/stand: common powerpc/kboot

2018-02-08 Thread Roger Pau Monné
Ping?

Ed committed a band-aid, but we need to get this fixed.

On Wed, Jan 31, 2018 at 03:20:46PM +, Roger Pau Monné wrote:
> On Mon, Jan 29, 2018 at 09:24:28AM +, Wojciech Macek wrote:
> > Modified: head/stand/common/load_elf.c
> > ==
> > --- head/stand/common/load_elf.cMon Jan 29 09:21:08 2018
> > (r328535)
> > +++ head/stand/common/load_elf.cMon Jan 29 09:24:28 2018
> > (r328536)
> > @@ -29,6 +29,7 @@
> >  __FBSDID("$FreeBSD$");
> >  
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -118,15 +119,72 @@ __elfN(load_elf_header)(char *filename, elf_file_t ef)
> > err = EFTYPE;
> > goto error;
> > }
> > +
> > if (ehdr->e_ident[EI_CLASS] != ELF_TARG_CLASS || /* Layout ? */
> > ehdr->e_ident[EI_DATA] != ELF_TARG_DATA ||
> 
> So here you force EI_DATA == ELF_TARG_DATA in order to continue...
> 
> > -   ehdr->e_ident[EI_VERSION] != EV_CURRENT || /* Version ? */
> > -   ehdr->e_version != EV_CURRENT ||
> > -   ehdr->e_machine != ELF_TARG_MACH) { /* Machine ? */
> > +   ehdr->e_ident[EI_VERSION] != EV_CURRENT) /* Version ? */ {
> > err = EFTYPE;
> > goto error;
> > }
> >  
> > +   /*
> > +* Fixup ELF endianness.
> > +*
> > +* The Xhdr structure was loaded using block read call to
> > +* optimize file accesses. It might happen, that the endianness
> > +* of the system memory is different that endianness of
> > +* the ELF header.
> > +* Swap fields here to guarantee that Xhdr always contain
> > +* valid data regardless of architecture.
> > +*/
> > +   if (ehdr->e_ident[EI_DATA] == ELFDATA2MSB) {
> > +   ehdr->e_type = be16toh(ehdr->e_type);
> 
> ... yet here you check for EI_DATA == ELFDATA2MSB which AFAICT it's not
> possible given the check above, so the following if branch is dead
> code.
> 
> > +   ehdr->e_machine = be16toh(ehdr->e_machine);
> > +   ehdr->e_version = be32toh(ehdr->e_version);
> > +   if (ehdr->e_ident[EI_CLASS] == ELFCLASS64) {
> > +   ehdr->e_entry = be64toh(ehdr->e_entry);
> > +   ehdr->e_phoff = be64toh(ehdr->e_phoff);
> > +   ehdr->e_shoff = be64toh(ehdr->e_shoff);
> > +   } else {
> > +   ehdr->e_entry = be32toh(ehdr->e_entry);
> > +   ehdr->e_phoff = be32toh(ehdr->e_phoff);
> > +   ehdr->e_shoff = be32toh(ehdr->e_shoff);
> > +   }
> > +   ehdr->e_flags = be32toh(ehdr->e_flags);
> > +   ehdr->e_ehsize = be16toh(ehdr->e_ehsize);
> > +   ehdr->e_phentsize = be16toh(ehdr->e_phentsize);
> > +   ehdr->e_phnum = be16toh(ehdr->e_phnum);
> > +   ehdr->e_shentsize = be16toh(ehdr->e_shentsize);
> > +   ehdr->e_shnum = be16toh(ehdr->e_shnum);
> > +   ehdr->e_shstrndx = be16toh(ehdr->e_shstrndx);
> > +
> > +   } else {
> > +   ehdr->e_type = le16toh(ehdr->e_type);
> > +   ehdr->e_machine = le16toh(ehdr->e_machine);
> > +   ehdr->e_version = le32toh(ehdr->e_version);
> > +   if (ehdr->e_ident[EI_CLASS] == ELFCLASS64) {
> > +   ehdr->e_entry = le64toh(ehdr->e_entry);
> > +   ehdr->e_phoff = le64toh(ehdr->e_phoff);
> > +   ehdr->e_shoff = le64toh(ehdr->e_shoff);
> > +   } else {
> > +   ehdr->e_entry = le32toh(ehdr->e_entry);
> > +   ehdr->e_phoff = le32toh(ehdr->e_phoff);
> > +   ehdr->e_shoff = le32toh(ehdr->e_shoff);
> > +   }
> > +   ehdr->e_flags = le32toh(ehdr->e_flags);
> > +   ehdr->e_ehsize = le16toh(ehdr->e_ehsize);
> > +   ehdr->e_phentsize = le16toh(ehdr->e_phentsize);
> > +   ehdr->e_phnum = le16toh(ehdr->e_phnum);
> > +   ehdr->e_shentsize = le16toh(ehdr->e_shentsize);
> > +   ehdr->e_shnum = le16toh(ehdr->e_shnum);
> > +   ehdr->e_shstrndx = le16toh(ehdr->e_shstrndx);
> > +   }
> 
> I think this chunk (and all the similar ones below) should be put on a
> macro in order to avoid such big chunks of code repetition. It's also
> fairly easy to forget to change one of the branches in the future.
> 
> Roger.
> 
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r328536 - in head/stand: common powerpc/kboot

2018-01-31 Thread Roger Pau Monné
On Mon, Jan 29, 2018 at 09:24:28AM +, Wojciech Macek wrote:
> Modified: head/stand/common/load_elf.c
> ==
> --- head/stand/common/load_elf.c  Mon Jan 29 09:21:08 2018
> (r328535)
> +++ head/stand/common/load_elf.c  Mon Jan 29 09:24:28 2018
> (r328536)
> @@ -29,6 +29,7 @@
>  __FBSDID("$FreeBSD$");
>  
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -118,15 +119,72 @@ __elfN(load_elf_header)(char *filename, elf_file_t ef)
>   err = EFTYPE;
>   goto error;
>   }
> +
>   if (ehdr->e_ident[EI_CLASS] != ELF_TARG_CLASS || /* Layout ? */
>   ehdr->e_ident[EI_DATA] != ELF_TARG_DATA ||

So here you force EI_DATA == ELF_TARG_DATA in order to continue...

> - ehdr->e_ident[EI_VERSION] != EV_CURRENT || /* Version ? */
> - ehdr->e_version != EV_CURRENT ||
> - ehdr->e_machine != ELF_TARG_MACH) { /* Machine ? */
> + ehdr->e_ident[EI_VERSION] != EV_CURRENT) /* Version ? */ {
>   err = EFTYPE;
>   goto error;
>   }
>  
> + /*
> +  * Fixup ELF endianness.
> +  *
> +  * The Xhdr structure was loaded using block read call to
> +  * optimize file accesses. It might happen, that the endianness
> +  * of the system memory is different that endianness of
> +  * the ELF header.
> +  * Swap fields here to guarantee that Xhdr always contain
> +  * valid data regardless of architecture.
> +  */
> + if (ehdr->e_ident[EI_DATA] == ELFDATA2MSB) {
> + ehdr->e_type = be16toh(ehdr->e_type);

... yet here you check for EI_DATA == ELFDATA2MSB which AFAICT it's not
possible given the check above, so the following if branch is dead
code.

> + ehdr->e_machine = be16toh(ehdr->e_machine);
> + ehdr->e_version = be32toh(ehdr->e_version);
> + if (ehdr->e_ident[EI_CLASS] == ELFCLASS64) {
> + ehdr->e_entry = be64toh(ehdr->e_entry);
> + ehdr->e_phoff = be64toh(ehdr->e_phoff);
> + ehdr->e_shoff = be64toh(ehdr->e_shoff);
> + } else {
> + ehdr->e_entry = be32toh(ehdr->e_entry);
> + ehdr->e_phoff = be32toh(ehdr->e_phoff);
> + ehdr->e_shoff = be32toh(ehdr->e_shoff);
> + }
> + ehdr->e_flags = be32toh(ehdr->e_flags);
> + ehdr->e_ehsize = be16toh(ehdr->e_ehsize);
> + ehdr->e_phentsize = be16toh(ehdr->e_phentsize);
> + ehdr->e_phnum = be16toh(ehdr->e_phnum);
> + ehdr->e_shentsize = be16toh(ehdr->e_shentsize);
> + ehdr->e_shnum = be16toh(ehdr->e_shnum);
> + ehdr->e_shstrndx = be16toh(ehdr->e_shstrndx);
> +
> + } else {
> + ehdr->e_type = le16toh(ehdr->e_type);
> + ehdr->e_machine = le16toh(ehdr->e_machine);
> + ehdr->e_version = le32toh(ehdr->e_version);
> + if (ehdr->e_ident[EI_CLASS] == ELFCLASS64) {
> + ehdr->e_entry = le64toh(ehdr->e_entry);
> + ehdr->e_phoff = le64toh(ehdr->e_phoff);
> + ehdr->e_shoff = le64toh(ehdr->e_shoff);
> + } else {
> + ehdr->e_entry = le32toh(ehdr->e_entry);
> + ehdr->e_phoff = le32toh(ehdr->e_phoff);
> + ehdr->e_shoff = le32toh(ehdr->e_shoff);
> + }
> + ehdr->e_flags = le32toh(ehdr->e_flags);
> + ehdr->e_ehsize = le16toh(ehdr->e_ehsize);
> + ehdr->e_phentsize = le16toh(ehdr->e_phentsize);
> + ehdr->e_phnum = le16toh(ehdr->e_phnum);
> + ehdr->e_shentsize = le16toh(ehdr->e_shentsize);
> + ehdr->e_shnum = le16toh(ehdr->e_shnum);
> + ehdr->e_shstrndx = le16toh(ehdr->e_shstrndx);
> + }

I think this chunk (and all the similar ones below) should be put on a
macro in order to avoid such big chunks of code repetition. It's also
fairly easy to forget to change one of the branches in the future.

Roger.
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r328536 - in head/stand: common powerpc/kboot

2018-01-31 Thread Roger Pau Monné
On Mon, Jan 29, 2018 at 09:24:28AM +, Wojciech Macek wrote:
> Modified: head/stand/common/load_elf.c
> ==
> --- head/stand/common/load_elf.c  Mon Jan 29 09:21:08 2018
> (r328535)
> +++ head/stand/common/load_elf.c  Mon Jan 29 09:24:28 2018
> (r328536)
> @@ -29,6 +29,7 @@
>  __FBSDID("$FreeBSD$");
>  
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -118,15 +119,72 @@ __elfN(load_elf_header)(char *filename, elf_file_t ef)
>   err = EFTYPE;
>   goto error;
>   }
> +
>   if (ehdr->e_ident[EI_CLASS] != ELF_TARG_CLASS || /* Layout ? */
>   ehdr->e_ident[EI_DATA] != ELF_TARG_DATA ||

So here you force EI_DATA == ELF_TARG_DATA in order to continue...

> - ehdr->e_ident[EI_VERSION] != EV_CURRENT || /* Version ? */
> - ehdr->e_version != EV_CURRENT ||
> - ehdr->e_machine != ELF_TARG_MACH) { /* Machine ? */
> + ehdr->e_ident[EI_VERSION] != EV_CURRENT) /* Version ? */ {
>   err = EFTYPE;
>   goto error;
>   }
>  
> + /*
> +  * Fixup ELF endianness.
> +  *
> +  * The Xhdr structure was loaded using block read call to
> +  * optimize file accesses. It might happen, that the endianness
> +  * of the system memory is different that endianness of
> +  * the ELF header.
> +  * Swap fields here to guarantee that Xhdr always contain
> +  * valid data regardless of architecture.
> +  */
> + if (ehdr->e_ident[EI_DATA] == ELFDATA2MSB) {
> + ehdr->e_type = be16toh(ehdr->e_type);

... yet here you check for EI_DATA == ELFDATA2MSB which AFAICT it's not
possible given the check above, so the following if branch is dead
code.

> + ehdr->e_machine = be16toh(ehdr->e_machine);
> + ehdr->e_version = be32toh(ehdr->e_version);
> + if (ehdr->e_ident[EI_CLASS] == ELFCLASS64) {
> + ehdr->e_entry = be64toh(ehdr->e_entry);
> + ehdr->e_phoff = be64toh(ehdr->e_phoff);
> + ehdr->e_shoff = be64toh(ehdr->e_shoff);
> + } else {
> + ehdr->e_entry = be32toh(ehdr->e_entry);
> + ehdr->e_phoff = be32toh(ehdr->e_phoff);
> + ehdr->e_shoff = be32toh(ehdr->e_shoff);
> + }
> + ehdr->e_flags = be32toh(ehdr->e_flags);
> + ehdr->e_ehsize = be16toh(ehdr->e_ehsize);
> + ehdr->e_phentsize = be16toh(ehdr->e_phentsize);
> + ehdr->e_phnum = be16toh(ehdr->e_phnum);
> + ehdr->e_shentsize = be16toh(ehdr->e_shentsize);
> + ehdr->e_shnum = be16toh(ehdr->e_shnum);
> + ehdr->e_shstrndx = be16toh(ehdr->e_shstrndx);
> +
> + } else {
> + ehdr->e_type = le16toh(ehdr->e_type);
> + ehdr->e_machine = le16toh(ehdr->e_machine);
> + ehdr->e_version = le32toh(ehdr->e_version);
> + if (ehdr->e_ident[EI_CLASS] == ELFCLASS64) {
> + ehdr->e_entry = le64toh(ehdr->e_entry);
> + ehdr->e_phoff = le64toh(ehdr->e_phoff);
> + ehdr->e_shoff = le64toh(ehdr->e_shoff);
> + } else {
> + ehdr->e_entry = le32toh(ehdr->e_entry);
> + ehdr->e_phoff = le32toh(ehdr->e_phoff);
> + ehdr->e_shoff = le32toh(ehdr->e_shoff);
> + }
> + ehdr->e_flags = le32toh(ehdr->e_flags);
> + ehdr->e_ehsize = le16toh(ehdr->e_ehsize);
> + ehdr->e_phentsize = le16toh(ehdr->e_phentsize);
> + ehdr->e_phnum = le16toh(ehdr->e_phnum);
> + ehdr->e_shentsize = le16toh(ehdr->e_shentsize);
> + ehdr->e_shnum = le16toh(ehdr->e_shnum);
> + ehdr->e_shstrndx = le16toh(ehdr->e_shstrndx);
> + }

I think this chunk (and all the similar ones below) should be put on a
macro in order to avoid such big chunks of code repetition. It's also
fairly easy to forget to change one of the branches in the future.

Roger.
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r328199 - in head/sys: amd64/amd64 i386/i386

2018-01-20 Thread Roger Pau Monné
Author: royger
Date: Sat Jan 20 14:59:37 2018
New Revision: 328199
URL: https://svnweb.freebsd.org/changeset/base/328199

Log:
  xen: fix IDT setup after PTI
  
  On amd64 the IDT handler was not set correctly when using PTI.
  
  While there also fix the selectors to SEL_KPL.
  
  Obtained from:kib
  MFC with: r328083

Modified:
  head/sys/amd64/amd64/machdep.c
  head/sys/i386/i386/machdep.c

Modified: head/sys/amd64/amd64/machdep.c
==
--- head/sys/amd64/amd64/machdep.c  Sat Jan 20 14:47:27 2018
(r328198)
+++ head/sys/amd64/amd64/machdep.c  Sat Jan 20 14:59:37 2018
(r328199)
@@ -1667,7 +1667,8 @@ hammer_time(u_int64_t modulep, u_int64_t physfree)
(dtrace_ret), SDT_SYSIGT, SEL_UPL, 0);
 #endif
 #ifdef XENHVM
-   setidt(IDT_EVTCHN, (xen_intr_upcall), SDT_SYSIGT, SEL_UPL, 0);
+   setidt(IDT_EVTCHN, pti ? (xen_intr_upcall_pti) :
+   (xen_intr_upcall), SDT_SYSIGT, SEL_KPL, 0);
 #endif
r_idt.rd_limit = sizeof(idt0) - 1;
r_idt.rd_base = (long) idt;

Modified: head/sys/i386/i386/machdep.c
==
--- head/sys/i386/i386/machdep.cSat Jan 20 14:47:27 2018
(r328198)
+++ head/sys/i386/i386/machdep.cSat Jan 20 14:59:37 2018
(r328199)
@@ -2268,7 +2268,7 @@ init386(int first)
GSEL(GCODE_SEL, SEL_KPL));
 #endif
 #ifdef XENHVM
-   setidt(IDT_EVTCHN, (xen_intr_upcall), SDT_SYS386IGT, SEL_UPL,
+   setidt(IDT_EVTCHN, (xen_intr_upcall), SDT_SYS386IGT, SEL_KPL,
GSEL(GCODE_SEL, SEL_KPL));
 #endif
 
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r325556 - in head/sys/boot: arm/uboot efi/loader i386/loader i386/zfsloader mips/beri/loader mips/uboot powerpc/kboot powerpc/ofw powerpc/ps3 powerpc/uboot sparc64/loader userboot/userboot

2017-11-08 Thread Roger Pau Monné
Author: royger
Date: Wed Nov  8 14:44:45 2017
New Revision: 325556
URL: https://svnweb.freebsd.org/changeset/base/325556

Log:
  loader: set options before including bsd.init.mk
  
  bsd.init.mk ends up including defs.mk so the per-arch options must be
  set before including defs.mk, or else the global defaults will be
  used and the per-arch ones will be ignored.
  
  Although better, note that the usage of MK_FDT before the inclusion of
  bsd.init.mk is incorrect but doesn't lead to build errors. This
  circular dependency must be broken in order for this to work
  correctly.
  
  Reviewed by:  imp
  Sponsored by: Citrix Systems R

Modified:
  head/sys/boot/arm/uboot/Makefile
  head/sys/boot/efi/loader/Makefile
  head/sys/boot/i386/loader/Makefile
  head/sys/boot/i386/zfsloader/Makefile
  head/sys/boot/mips/beri/loader/Makefile
  head/sys/boot/mips/uboot/Makefile
  head/sys/boot/powerpc/kboot/Makefile
  head/sys/boot/powerpc/ofw/Makefile
  head/sys/boot/powerpc/ps3/Makefile
  head/sys/boot/powerpc/uboot/Makefile
  head/sys/boot/sparc64/loader/Makefile
  head/sys/boot/userboot/userboot/Makefile

Modified: head/sys/boot/arm/uboot/Makefile
==
--- head/sys/boot/arm/uboot/MakefileWed Nov  8 14:21:52 2017
(r32)
+++ head/sys/boot/arm/uboot/MakefileWed Nov  8 14:44:45 2017
(r325556)
@@ -1,5 +1,16 @@
 # $FreeBSD$
 
+LOADER_UFS_SUPPORT?=   yes
+LOADER_CD9660_SUPPORT?=no
+LOADER_MSDOS_SUPPORT?= no
+LOADER_EXT2FS_SUPPORT?=no
+LOADER_NET_SUPPORT?=   yes
+LOADER_NFS_SUPPORT?=   yes
+LOADER_TFTP_SUPPORT?=  no
+LOADER_GZIP_SUPPORT?=  no
+LOADER_BZIP2_SUPPORT?= no
+LOADER_FDT_SUPPORT=${MK_FDT}
+
 .include 
 
 FILES= ubldr ubldr.bin
@@ -17,17 +28,6 @@ SRCS=start.S conf.c self_reloc.c vers.c
 .if ${COMPILER_TYPE} == "gcc" && ${COMPILER_VERSION} > 40201
 CWARNFLAGS.self_reloc.c+=  -Wno-error=maybe-uninitialized
 .endif
-
-LOADER_UFS_SUPPORT?=   yes
-LOADER_CD9660_SUPPORT?=no
-LOADER_MSDOS_SUPPORT?= no
-LOADER_EXT2FS_SUPPORT?=no
-LOADER_NET_SUPPORT?=   yes
-LOADER_NFS_SUPPORT?=   yes
-LOADER_TFTP_SUPPORT?=  no
-LOADER_GZIP_SUPPORT?=  no
-LOADER_BZIP2_SUPPORT?= no
-LOADER_FDT_SUPPORT=${MK_FDT}
 
 # Always add MI sources
 .include   "${BOOTSRC}/loader.mk"

Modified: head/sys/boot/efi/loader/Makefile
==
--- head/sys/boot/efi/loader/Makefile   Wed Nov  8 14:21:52 2017
(r32)
+++ head/sys/boot/efi/loader/Makefile   Wed Nov  8 14:44:45 2017
(r325556)
@@ -2,6 +2,12 @@
 
 MAN=
 
+LOADER_NET_SUPPORT?=   yes
+LOADER_MSDOS_SUPPORT?= yes
+LOADER_UFS_SUPPORT?=   yes
+LOADER_CD9660_SUPPORT?=no
+LOADER_EXT2FS_SUPPORT?=no
+
 .include 
 
 MK_SSP=no
@@ -9,12 +15,6 @@ MK_SSP=   no
 PROG=  loader.sym
 INTERNALPROG=
 WARNS?=3
-LOADER_NET_SUPPORT?=   yes
-
-LOADER_MSDOS_SUPPORT?= yes
-LOADER_UFS_SUPPORT?=   yes
-LOADER_CD9660_SUPPORT?=no
-LOADER_EXT2FS_SUPPORT?=no
 
 # architecture-specific loader code
 SRCS=  autoload.c \

Modified: head/sys/boot/i386/loader/Makefile
==
--- head/sys/boot/i386/loader/Makefile  Wed Nov  8 14:21:52 2017
(r32)
+++ head/sys/boot/i386/loader/Makefile  Wed Nov  8 14:44:45 2017
(r325556)
@@ -1,5 +1,15 @@
 # $FreeBSD$
 
+LOADER_NET_SUPPORT?=   yes
+LOADER_NFS_SUPPORT?=   yes
+LOADER_TFTP_SUPPORT?=  yes
+LOADER_CD9660_SUPPORT?=no
+LOADER_EXT2FS_SUPPORT?=no
+LOADER_MSDOS_SUPPORT?= no
+LOADER_UFS_SUPPORT?=   yes
+LOADER_GZIP_SUPPORT?=  yes
+LOADER_BZIP2_SUPPORT?= yes
+
 .include 
 
 MK_SSP=no
@@ -10,16 +20,6 @@ MAN= 
 INTERNALPROG=
 NEWVERSWHAT?=  "bootstrap loader" x86
 VERSION_FILE=  ${.CURDIR}/../loader/version
-LOADER_NET_SUPPORT?=   yes
-LOADER_NFS_SUPPORT?=   yes
-LOADER_TFTP_SUPPORT?=  yes
-
-LOADER_CD9660_SUPPORT?=no
-LOADER_EXT2FS_SUPPORT?=no
-LOADER_MSDOS_SUPPORT?= no
-LOADER_UFS_SUPPORT?=   yes
-LOADER_GZIP_SUPPORT?=  yes
-LOADER_BZIP2_SUPPORT?= yes
 
 # architecture-specific loader code
 SRCS=  main.c conf.c vers.c chain.c

Modified: head/sys/boot/i386/zfsloader/Makefile
==
--- head/sys/boot/i386/zfsloader/Makefile   Wed Nov  8 14:21:52 2017
(r32)
+++ head/sys/boot/i386/zfsloader/Makefile   Wed Nov  8 14:44:45 2017
(r325556)
@@ -1,12 +1,13 @@
 # $FreeBSD$
 
+LOADER_ZFS_SUPPORT=yes
+
 .include 
 
 .PATH: ${BOOTSRC}/i386/loader
 
 LOADER=zfsloader
 NEWVERSWHAT=   "ZFS enabled bootstrap loader" x86
-LOADER_ZFS_SUPPORT=yes
 LOADER_ONLY=   yes
 MAN=
 

Modified: head/sys/boot/mips/beri/loader/Makefile
==
--- 

svn commit: r325332 - head/sys/boot/i386/loader

2017-11-02 Thread Roger Pau Monné
Author: royger
Date: Thu Nov  2 18:13:26 2017
New Revision: 325332
URL: https://svnweb.freebsd.org/changeset/base/325332

Log:
  loader: re-enable gzip support for x86
  
  r324653 inadvertently disabled default gzip support on x86, re-enable.
  
  Sponsored by: Citrix System R
  Reviewed by:  imp
  Differential revision:https://reviews.freebsd.org/D12913

Modified:
  head/sys/boot/i386/loader/Makefile

Modified: head/sys/boot/i386/loader/Makefile
==
--- head/sys/boot/i386/loader/Makefile  Thu Nov  2 18:09:10 2017
(r325331)
+++ head/sys/boot/i386/loader/Makefile  Thu Nov  2 18:13:26 2017
(r325332)
@@ -18,6 +18,7 @@ LOADER_CD9660_SUPPORT?=   no
 LOADER_EXT2FS_SUPPORT?=no
 LOADER_MSDOS_SUPPORT?= no
 LOADER_UFS_SUPPORT?=   yes
+LOADER_GZIP_SUPPORT?=  yes
 
 # architecture-specific loader code
 SRCS=  main.c conf.c vers.c chain.c
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r323154 - head/sys/x86/acpica

2017-09-04 Thread Roger Pau Monné
Author: royger
Date: Mon Sep  4 10:08:42 2017
New Revision: 323154
URL: https://svnweb.freebsd.org/changeset/base/323154

Log:
  acpi/srat: zero the SRAT cpu array
  
  Fix from fallout introduced in r322348 that moved the cpus array to a
  dynamic allocation without zeroing the area.
  
  Reported by:  mjg
  MFC with: r322348
  Reviewed by:  mjg
  Differential revision:https://reviews.freebsd.org/D12220

Modified:
  head/sys/x86/acpica/srat.c

Modified: head/sys/x86/acpica/srat.c
==
--- head/sys/x86/acpica/srat.c  Mon Sep  4 08:41:51 2017(r323153)
+++ head/sys/x86/acpica/srat.c  Mon Sep  4 10:08:42 2017(r323154)
@@ -449,6 +449,7 @@ parse_srat(void)
 * the default memory attribute (WB), and the DMAP when available.
 */
cpus = (struct cpu_info *)pmap_mapbios(addr, size);
+   bzero(cpus, size);
 
/*
 * Make a pass over the table to populate the cpus[] and
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r322457 - head/sys/x86/acpica

2017-08-13 Thread Roger Pau Monné
Author: royger
Date: Sun Aug 13 14:50:38 2017
New Revision: 322457
URL: https://svnweb.freebsd.org/changeset/base/322457

Log:
  srat: use pmap_unmapbios
  
  To match the pmap_mapbios.
  
  Reported by:  jhb
  MFC with: r322403

Modified:
  head/sys/x86/acpica/srat.c

Modified: head/sys/x86/acpica/srat.c
==
--- head/sys/x86/acpica/srat.c  Sun Aug 13 14:42:23 2017(r322456)
+++ head/sys/x86/acpica/srat.c  Sun Aug 13 14:50:38 2017(r322457)
@@ -536,7 +536,7 @@ srat_set_cpus(void *dummy)
}
 
/* Last usage of the cpus array, unmap it. */
-   pmap_unmapdev((vm_offset_t)cpus, sizeof(*cpus) * (max_apic_id + 1));
+   pmap_unmapbios((vm_offset_t)cpus, sizeof(*cpus) * (max_apic_id + 1));
cpus = NULL;
 }
 SYSINIT(srat_set_cpus, SI_SUB_CPU, SI_ORDER_ANY, srat_set_cpus, NULL);
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r322403 - head/sys/x86/acpica

2017-08-11 Thread Roger Pau Monné
Author: royger
Date: Fri Aug 11 14:19:55 2017
New Revision: 322403
URL: https://svnweb.freebsd.org/changeset/base/322403

Log:
  acpi/srat: fix build without DMAP
  
  Use pmap_mapbios to map memory used to store the cpus array.
  
  Reported by:  lwhsu
  X-MFC-with:   r322348

Modified:
  head/sys/x86/acpica/srat.c

Modified: head/sys/x86/acpica/srat.c
==
--- head/sys/x86/acpica/srat.c  Fri Aug 11 14:19:31 2017(r322402)
+++ head/sys/x86/acpica/srat.c  Fri Aug 11 14:19:55 2017(r322403)
@@ -443,7 +443,12 @@ parse_srat(void)
("Not enough memory for SRAT table items"));
phys_avail[idx + 1] = addr - 1;
 
-   cpus = (struct cpu_info *)PHYS_TO_DMAP(addr);
+   /*
+* We cannot rely on PHYS_TO_DMAP because this code is also used in
+* i386, so use pmap_mapbios to map the memory, this will end up using
+* the default memory attribute (WB), and the DMAP when available.
+*/
+   cpus = (struct cpu_info *)pmap_mapbios(addr, size);
 
/*
 * Make a pass over the table to populate the cpus[] and
@@ -529,6 +534,10 @@ srat_set_cpus(void *dummy)
printf("SRAT: CPU %u has memory domain %d\n", i,
cpu->domain);
}
+
+   /* Last usage of the cpus array, unmap it. */
+   pmap_unmapdev((vm_offset_t)cpus, sizeof(*cpus) * (max_apic_id + 1));
+   cpus = NULL;
 }
 SYSINIT(srat_set_cpus, SI_SUB_CPU, SI_ORDER_ANY, srat_set_cpus, NULL);
 
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r322347 - in head/sys/x86: acpica include x86 xen

2017-08-10 Thread Roger Pau Monné
On Thu, Aug 10, 2017 at 10:20:59AM -0400, Ed Maste wrote:
> On 10 August 2017 at 05:15, Roger Pau Monné <roy...@freebsd.org> wrote:
> > Author: royger
> > Date: Thu Aug 10 09:15:18 2017
> > New Revision: 322347
> > URL: https://svnweb.freebsd.org/changeset/base/322347
> >
> > Log:
> >   apic_enumerator: only set mp_ncpus and mp_maxid at probe cpus phase
> 
> i386 is failing with:

Thanks for the heads up! Should be fixed in r322372, will keep an eye on
the CI.

Roger.
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r322372 - in head/sys/x86: acpica x86

2017-08-10 Thread Roger Pau Monné
Author: royger
Date: Thu Aug 10 17:46:57 2017
New Revision: 322372
URL: https://svnweb.freebsd.org/changeset/base/322372

Log:
  mptable: fix i386 build failure
  
  Reported by:  emaste
  X-MFC-with:   r322347

Modified:
  head/sys/x86/acpica/madt.c
  head/sys/x86/x86/mptable.c

Modified: head/sys/x86/acpica/madt.c
==
--- head/sys/x86/acpica/madt.c  Thu Aug 10 17:03:46 2017(r322371)
+++ head/sys/x86/acpica/madt.c  Thu Aug 10 17:46:57 2017(r322372)
@@ -325,12 +325,17 @@ static void
 madt_parse_cpu(unsigned int apic_id, unsigned int flags)
 {
 
-   if (!(flags & ACPI_MADT_ENABLED) || mp_ncpus == MAXCPU ||
+   if (!(flags & ACPI_MADT_ENABLED) ||
+#ifdef SMP
+   mp_ncpus == MAXCPU ||
+#endif
apic_id > MAX_APIC_ID)
return;
 
+#ifdef SMP
mp_ncpus++;
mp_maxid = mp_ncpus - 1;
+#endif
max_apic_id = max(apic_id, max_apic_id);
 }
 

Modified: head/sys/x86/x86/mptable.c
==
--- head/sys/x86/x86/mptable.c  Thu Aug 10 17:03:46 2017(r322371)
+++ head/sys/x86/x86/mptable.c  Thu Aug 10 17:46:57 2017(r322372)
@@ -34,6 +34,7 @@ __FBSDID("$FreeBSD$");
 #include 
 #include 
 #include 
+#include 
 #ifdef NEW_PCIB
 #include 
 #endif
@@ -330,8 +331,10 @@ mptable_probe_cpus(void)
 
/* Is this a pre-defined config? */
if (mpfps->config_type != 0) {
+#ifdef SMP
mp_ncpus = 2;
mp_maxid = 1;
+#endif
max_apic_id = 1;
} else {
mptable_walk_table(mptable_probe_cpus_handler, _mask);
@@ -346,6 +349,7 @@ static int
 mptable_setup_local(void)
 {
vm_paddr_t addr;
+   u_int cpu_mask;
 
/* Is this a pre-defined config? */
printf("MPTable: <");
@@ -478,8 +482,10 @@ mptable_probe_cpus_handler(u_char *entry, void *arg)
proc = (proc_entry_ptr)entry;
if (proc->cpu_flags & PROCENTRY_FLAG_EN &&
proc->apic_id < MAX_LAPIC_ID && mp_ncpus < MAXCPU) {
+#ifdef SMP
mp_ncpus++;
mp_maxid = mp_ncpus - 1;
+#endif
max_apic_id = max(max_apic_id, proc->apic_id);
}
break;
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r322350 - head/usr.bin/calendar/calendars

2017-08-10 Thread Roger Pau Monné
Author: royger
Date: Thu Aug 10 09:17:16 2017
New Revision: 322350
URL: https://svnweb.freebsd.org/changeset/base/322350

Log:
  calendars: add myself to the FreeBSD calendar
  
  Reported by:  mckusick

Modified:
  head/usr.bin/calendar/calendars/calendar.freebsd

Modified: head/usr.bin/calendar/calendars/calendar.freebsd
==
--- head/usr.bin/calendar/calendars/calendar.freebsdThu Aug 10 09:16:40 
2017(r322349)
+++ head/usr.bin/calendar/calendars/calendar.freebsdThu Aug 10 09:17:16 
2017(r322350)
@@ -223,6 +223,7 @@
 06/06  Alan Eldridge  died in Denver, Colorado, 2003
 06/07  Jimmy Olgeni  born in Milano, Italy, 1976
 06/07  Benjamin Close  born in Adelaide, Australia, 1978
+06/07  Roger Pau Monne  born in Reus, Catalunya, Spain, 
1986
 06/08  Ravi Pokala  born in Royal Oak, Michigan, United 
States, 1980
 06/09  Stanislav Galabov  born in Sofia, Bulgaria 1978
 06/11  Alonso Cardenas Marquez  born in Arequipa, Peru, 1979
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r322349 - in head/sys/x86: acpica include x86

2017-08-10 Thread Roger Pau Monné
Author: royger
Date: Thu Aug 10 09:16:40 2017
New Revision: 322349
URL: https://svnweb.freebsd.org/changeset/base/322349

Log:
  x86: bump MAX_APIC_ID to 512
  
  Introduce a new define to take int account the xAPIC ID limit, for
  systems where x2APIC is not available/reliable.
  
  Also change some of the usages of the APIC ID to use an unsigned int
  (which is the correct storage type to deal with x2APIC IDs as found in
  x2APIC MADT entries).
  
  This allows booting FreeBSD on a box with 256 CPUs and APIC IDs up to
  295:
  
  FreeBSD/SMP: Multiprocessor System Detected: 256 CPUs
  FreeBSD/SMP: 1 package(s) x 64 core(s) x 4 hardware threads
  Package HW ID = 0
Core HW ID = 0
CPU0 (BSP): APIC ID: 0
CPU1 (AP/HT): APIC ID: 1
CPU2 (AP/HT): APIC ID: 2
CPU3 (AP/HT): APIC ID: 3
  [...]
Core HW ID = 73
CPU252 (AP): APIC ID: 292
CPU253 (AP/HT): APIC ID: 293
CPU254 (AP/HT): APIC ID: 294
CPU255 (AP/HT): APIC ID: 295
  
  Submitted by: kib (previous version)
  Relnotes: yes
  MFC after:1 month
  Reviewed by:  kib
  Differential revision:https://reviews.freebsd.org/D11913

Modified:
  head/sys/x86/acpica/madt.c
  head/sys/x86/include/apicvar.h
  head/sys/x86/x86/mp_x86.c
  head/sys/x86/x86/mptable.c

Modified: head/sys/x86/acpica/madt.c
==
--- head/sys/x86/acpica/madt.c  Thu Aug 10 09:16:03 2017(r322348)
+++ head/sys/x86/acpica/madt.c  Thu Aug 10 09:16:40 2017(r322349)
@@ -212,6 +212,14 @@ madt_setup_local(void)
}
}
 
+   /*
+* Truncate max_apic_id if not in x2APIC mode. Some structures
+* will already be allocated with the previous max_apic_id, but
+* at least we can prevent wasting more memory elsewhere.
+*/
+   if (!x2apic_mode)
+   max_apic_id = min(max_apic_id, xAPIC_MAX_APIC_ID);
+
madt = pmap_mapbios(madt_physaddr, madt_length);
lapics = malloc(sizeof(*lapics) * (max_apic_id + 1), M_MADT,
M_WAITOK | M_ZERO);
@@ -250,7 +258,7 @@ madt_setup_io(void)
panic("Using MADT but ACPI doesn't work");
}
 
-   ioapics = malloc(sizeof(*ioapics) * (MAX_APIC_ID + 1), M_MADT,
+   ioapics = malloc(sizeof(*ioapics) * (IOAPIC_MAX_ID + 1), M_MADT,
M_WAITOK | M_ZERO);
 
/* First, we run through adding I/O APIC's. */
@@ -277,7 +285,7 @@ madt_setup_io(void)
}
 
/* Third, we register all the I/O APIC's. */
-   for (i = 0; i <= MAX_APIC_ID; i++)
+   for (i = 0; i <= IOAPIC_MAX_ID; i++)
if (ioapics[i].io_apic != NULL)
ioapic_register(ioapics[i].io_apic);
 
@@ -408,7 +416,7 @@ madt_parse_apics(ACPI_SUBTABLE_HEADER *entry, void *ar
"MADT: Found IO APIC ID %u, Interrupt %u at %p\n",
apic->Id, apic->GlobalIrqBase,
(void *)(uintptr_t)apic->Address);
-   if (apic->Id > MAX_APIC_ID)
+   if (apic->Id > IOAPIC_MAX_ID)
panic("%s: I/O APIC ID %u too high", __func__,
apic->Id);
if (ioapics[apic->Id].io_apic != NULL)
@@ -501,7 +509,7 @@ madt_find_interrupt(int intr, void **apic, u_int *pin)
int i, best;
 
best = -1;
-   for (i = 0; i <= MAX_APIC_ID; i++) {
+   for (i = 0; i <= IOAPIC_MAX_ID; i++) {
if (ioapics[i].io_apic == NULL ||
ioapics[i].io_vector > intr)
continue;

Modified: head/sys/x86/include/apicvar.h
==
--- head/sys/x86/include/apicvar.h  Thu Aug 10 09:16:03 2017
(r322348)
+++ head/sys/x86/include/apicvar.h  Thu Aug 10 09:16:40 2017
(r322349)
@@ -74,8 +74,12 @@
  * I/O device!
  */
 
-#defineMAX_APIC_ID 0xfe
-#defineAPIC_ID_ALL 0xff
+#definexAPIC_MAX_APIC_ID   0xfe
+#definexAPIC_ID_ALL0xff
+#defineMAX_APIC_ID 0x200
+#defineAPIC_ID_ALL 0x
+
+#defineIOAPIC_MAX_ID   xAPIC_MAX_APIC_ID
 
 /* I/O Interrupts are used for external devices such as ISA, PCI, etc. */
 #defineAPIC_IO_INTS(IDT_IO_INTS + 16)

Modified: head/sys/x86/x86/mp_x86.c
==
--- head/sys/x86/x86/mp_x86.c   Thu Aug 10 09:16:03 2017(r322348)
+++ head/sys/x86/x86/mp_x86.c   Thu Aug 10 09:16:40 2017(r322349)
@@ -137,6 +137,10 @@ volatile int aps_ready = 0;
 struct cpu_info *cpu_info;
 int *apic_cpuids;
 int cpu_apic_ids[MAXCPU];
+_Static_assert(MAXCPU <= MAX_APIC_ID,
+"MAXCPU cannot be larger that 

svn commit: r322348 - in head/sys/x86: acpica include x86

2017-08-10 Thread Roger Pau Monné
Author: royger
Date: Thu Aug 10 09:16:03 2017
New Revision: 322348
URL: https://svnweb.freebsd.org/changeset/base/322348

Log:
  x86: make the arrays that depend on MAX_APIC_ID dynamic
  
  So that MAX_APIC_ID can be bumped without wasting memory.
  
  Note that the usage of MAX_APIC_ID in the SRAT parsing forces the
  parser to allocate memory directly from the phys_avail physical memory
  array, which is not the best approach probably, but I haven't found
  any other way to allocate memory so early in boot. This memory is not
  returned to the system afterwards, but at least it's sized according
  to the maximum APIC ID found in the MADT table.
  
  Sponsored by: Citrix Systems R
  MFC after:1 month
  Reviewed by:  kib
  Differential revision:https://reviews.freebsd.org/D11912

Modified:
  head/sys/x86/acpica/madt.c
  head/sys/x86/acpica/srat.c
  head/sys/x86/include/apicvar.h
  head/sys/x86/include/x86_smp.h
  head/sys/x86/x86/local_apic.c
  head/sys/x86/x86/mp_x86.c

Modified: head/sys/x86/acpica/madt.c
==
--- head/sys/x86/acpica/madt.c  Thu Aug 10 09:15:18 2017(r322347)
+++ head/sys/x86/acpica/madt.c  Thu Aug 10 09:16:03 2017(r322348)
@@ -59,7 +59,7 @@ static struct {
 static struct lapic_info {
u_int la_enabled;
u_int la_acpi_id;
-} lapics[MAX_APIC_ID + 1];
+} *lapics;
 
 int madt_found_sci_override;
 static ACPI_TABLE_MADT *madt;
@@ -141,8 +141,6 @@ madt_setup_local(void)
int user_x2apic;
bool bios_x2apic;
 
-   madt = pmap_mapbios(madt_physaddr, madt_length);
-   madt_walk_table(madt_setup_cpus_handler, NULL);
if ((cpu_feature2 & CPUID2_X2APIC) != 0) {
reason = NULL;
 
@@ -214,6 +212,11 @@ madt_setup_local(void)
}
}
 
+   madt = pmap_mapbios(madt_physaddr, madt_length);
+   lapics = malloc(sizeof(*lapics) * (max_apic_id + 1), M_MADT,
+   M_WAITOK | M_ZERO);
+   madt_walk_table(madt_setup_cpus_handler, NULL);
+
lapic_init(madt->Address);
printf("ACPI APIC Table: <%.*s %.*s>\n",
(int)sizeof(madt->Header.OemId), madt->Header.OemId,
@@ -236,6 +239,8 @@ madt_setup_io(void)
u_int pin;
int i;
 
+   KASSERT(lapics != NULL, ("local APICs not initialized"));
+
/* Try to initialize ACPI so that we can access the FADT. */
i = acpi_Startup();
if (ACPI_FAILURE(i)) {
@@ -282,6 +287,10 @@ madt_setup_io(void)
free(ioapics, M_MADT);
ioapics = NULL;
 
+   /* NB: this is the last use of the lapics array. */
+   free(lapics, M_MADT);
+   lapics = NULL;
+
return (0);
 }
 
@@ -332,7 +341,7 @@ madt_add_cpu(u_int acpi_id, u_int apic_id, u_int flags
"enabled" : "disabled");
if (!(flags & ACPI_MADT_ENABLED))
return;
-   if (apic_id > MAX_APIC_ID) {
+   if (apic_id > max_apic_id) {
printf("MADT: Ignoring local APIC ID %u (too high)\n",
apic_id);
return;
@@ -471,7 +480,7 @@ madt_find_cpu(u_int acpi_id, u_int *apic_id)
 {
int i;
 
-   for (i = 0; i <= MAX_APIC_ID; i++) {
+   for (i = 0; i <= max_apic_id; i++) {
if (!lapics[i].la_enabled)
continue;
if (lapics[i].la_acpi_id != acpi_id)
@@ -723,6 +732,9 @@ madt_set_ids(void *dummy)
 
if (madt == NULL)
return;
+
+   KASSERT(lapics != NULL, ("local APICs not initialized"));
+
CPU_FOREACH(i) {
pc = pcpu_find(i);
KASSERT(pc != NULL, ("no pcpu data for CPU %u", i));

Modified: head/sys/x86/acpica/srat.c
==
--- head/sys/x86/acpica/srat.c  Thu Aug 10 09:15:18 2017(r322347)
+++ head/sys/x86/acpica/srat.c  Thu Aug 10 09:16:03 2017(r322348)
@@ -55,11 +55,11 @@ __FBSDID("$FreeBSD$");
 #include 
 
 #if MAXMEMDOM > 1
-struct cpu_info {
+static struct cpu_info {
int enabled:1;
int has_memory:1;
int domain;
-} cpus[MAX_APIC_ID + 1];
+} *cpus;
 
 struct mem_affinity mem_info[VM_PHYSSEG_MAX + 1];
 int num_mem;
@@ -204,7 +204,7 @@ srat_parse_entry(ACPI_SUBTABLE_HEADER *entry, void *ar
"enabled" : "disabled");
if (!(cpu->Flags & ACPI_SRAT_CPU_ENABLED))
break;
-   if (cpu->ApicId > MAX_APIC_ID) {
+   if (cpu->ApicId > max_apic_id) {
printf("SRAT: Ignoring local APIC ID %u (too high)\n",
cpu->ApicId);
break;
@@ -228,7 +228,7 @@ srat_parse_entry(ACPI_SUBTABLE_HEADER *entry, void *ar
"enabled" : "disabled");
if (!(x2apic->Flags & ACPI_SRAT_CPU_ENABLED))
break;
-   if 

svn commit: r322347 - in head/sys/x86: acpica include x86 xen

2017-08-10 Thread Roger Pau Monné
Author: royger
Date: Thu Aug 10 09:15:18 2017
New Revision: 322347
URL: https://svnweb.freebsd.org/changeset/base/322347

Log:
  apic_enumerator: only set mp_ncpus and mp_maxid at probe cpus phase
  
  Populate the lapics arrays and call cpu_add/lapic_create in the setup
  phase instead. Also store the max APIC ID found in the newly
  introduced max_apic_id global variable.
  
  This is a requirement in order to make the static arrays currently
  using MAX_LAPIC_ID dynamic.
  
  Sponsored by: Citrix Systems R
  MFC after:1 month
  Reviewed by:  kib
  Differential revision:https://reviews.freebsd.org/D11911

Modified:
  head/sys/x86/acpica/madt.c
  head/sys/x86/acpica/srat.c
  head/sys/x86/include/x86_var.h
  head/sys/x86/x86/local_apic.c
  head/sys/x86/x86/mp_x86.c
  head/sys/x86/x86/mptable.c
  head/sys/x86/xen/pvcpu_enum.c

Modified: head/sys/x86/acpica/madt.c
==
--- head/sys/x86/acpica/madt.c  Thu Aug 10 09:02:44 2017(r322346)
+++ head/sys/x86/acpica/madt.c  Thu Aug 10 09:15:18 2017(r322347)
@@ -83,6 +83,8 @@ static intmadt_probe(void);
 static int madt_probe_cpus(void);
 static voidmadt_probe_cpus_handler(ACPI_SUBTABLE_HEADER *entry,
void *arg __unused);
+static voidmadt_setup_cpus_handler(ACPI_SUBTABLE_HEADER *entry,
+   void *arg __unused);
 static voidmadt_register(void *dummy);
 static int madt_setup_local(void);
 static int madt_setup_io(void);
@@ -140,6 +142,7 @@ madt_setup_local(void)
bool bios_x2apic;
 
madt = pmap_mapbios(madt_physaddr, madt_length);
+   madt_walk_table(madt_setup_cpus_handler, NULL);
if ((cpu_feature2 & CPUID2_X2APIC) != 0) {
reason = NULL;
 
@@ -302,6 +305,19 @@ madt_walk_table(acpi_subtable_handler *handler, void *
 }
 
 static void
+madt_parse_cpu(unsigned int apic_id, unsigned int flags)
+{
+
+   if (!(flags & ACPI_MADT_ENABLED) || mp_ncpus == MAXCPU ||
+   apic_id > MAX_APIC_ID)
+   return;
+
+   mp_ncpus++;
+   mp_maxid = mp_ncpus - 1;
+   max_apic_id = max(apic_id, max_apic_id);
+}
+
+static void
 madt_add_cpu(u_int acpi_id, u_int apic_id, u_int flags)
 {
struct lapic_info *la;
@@ -331,6 +347,24 @@ madt_add_cpu(u_int acpi_id, u_int apic_id, u_int flags
 
 static void
 madt_probe_cpus_handler(ACPI_SUBTABLE_HEADER *entry, void *arg)
+{
+   ACPI_MADT_LOCAL_APIC *proc;
+   ACPI_MADT_LOCAL_X2APIC *x2apic;
+
+   switch (entry->Type) {
+   case ACPI_MADT_TYPE_LOCAL_APIC:
+   proc = (ACPI_MADT_LOCAL_APIC *)entry;
+   madt_parse_cpu(proc->Id, proc->LapicFlags);
+   break;
+   case ACPI_MADT_TYPE_LOCAL_X2APIC:
+   x2apic = (ACPI_MADT_LOCAL_X2APIC *)entry;
+   madt_parse_cpu(x2apic->LocalApicId, x2apic->LapicFlags);
+   break;
+   }
+}
+
+static void
+madt_setup_cpus_handler(ACPI_SUBTABLE_HEADER *entry, void *arg)
 {
ACPI_MADT_LOCAL_APIC *proc;
ACPI_MADT_LOCAL_X2APIC *x2apic;

Modified: head/sys/x86/acpica/srat.c
==
--- head/sys/x86/acpica/srat.c  Thu Aug 10 09:02:44 2017(r322346)
+++ head/sys/x86/acpica/srat.c  Thu Aug 10 09:15:18 2017(r322347)
@@ -49,6 +49,7 @@ __FBSDID("$FreeBSD$");
 #include 
 
 #include 
+#include 
 #include 
 
 #include 

Modified: head/sys/x86/include/x86_var.h
==
--- head/sys/x86/include/x86_var.h  Thu Aug 10 09:02:44 2017
(r322346)
+++ head/sys/x86/include/x86_var.h  Thu Aug 10 09:15:18 2017
(r322347)
@@ -78,6 +78,7 @@ externint _ufssel;
 extern int _ugssel;
 extern int use_xsave;
 extern uint64_t xsave_mask;
+extern u_int   max_apic_id;
 
 struct pcb;
 struct thread;

Modified: head/sys/x86/x86/local_apic.c
==
--- head/sys/x86/x86/local_apic.c   Thu Aug 10 09:02:44 2017
(r322346)
+++ head/sys/x86/x86/local_apic.c   Thu Aug 10 09:15:18 2017
(r322347)
@@ -184,6 +184,7 @@ static struct eventtimer lapic_et;
 #ifdef SMP
 static uint64_t lapic_ipi_wait_mult;
 #endif
+unsigned int max_apic_id;
 
 SYSCTL_NODE(_hw, OID_AUTO, apic, CTLFLAG_RD, 0, "APIC options");
 SYSCTL_INT(_hw_apic, OID_AUTO, x2apic_mode, CTLFLAG_RD, _mode, 0, "");

Modified: head/sys/x86/x86/mp_x86.c
==
--- head/sys/x86/x86/mp_x86.c   Thu Aug 10 09:02:44 2017(r322346)
+++ head/sys/x86/x86/mp_x86.c   Thu Aug 10 09:15:18 2017(r322347)
@@ -825,10 +825,6 @@ cpu_add(u_int apic_id, char boot_cpu)
boot_cpu_id = apic_id;
cpu_info[apic_id].cpu_bsp = 1;
}
-   if (mp_ncpus < 

svn commit: r321863 - head/sys/dev/pci

2017-08-01 Thread Roger Pau Monné
Author: royger
Date: Tue Aug  1 10:47:44 2017
New Revision: 321863
URL: https://svnweb.freebsd.org/changeset/base/321863

Log:
  pci: fix write order when sizing BARs
  
  According to the PCI Local Specification rev. 3.0 in case of a 64-bit
  BAR both the low and the high parts of the register should be set to
  ~0 before attempting to read back the size.
  
  So far I have found no single device that has problems with the
  previous approach, but I think it's better to stay on the safe size.
  
  This commit should not introduce any functional change.
  
  MFC after:3 weeks
  Sponsored by: Citrix Systems R
  Reviewed by:  jhb
  Differential revision:https://reviews.freebsd.org/D11750

Modified:
  head/sys/dev/pci/pci.c

Modified: head/sys/dev/pci/pci.c
==
--- head/sys/dev/pci/pci.c  Tue Aug  1 10:46:47 2017(r321862)
+++ head/sys/dev/pci/pci.c  Tue Aug  1 10:47:44 2017(r321863)
@@ -2902,13 +2902,21 @@ pci_read_bar(device_t dev, int reg, pci_addr_t *mapp, 
 * Determine the BAR's length by writing all 1's.  The bottom
 * log_2(size) bits of the BAR will stick as 0 when we read
 * the value back.
+*
+* NB: according to the PCI Local Bus Specification, rev. 3.0:
+* "Software writes 0h to both registers, reads them back,
+* and combines the result into a 64-bit value." (section 6.2.5.1)
+*
+* Writes to both registers must be performed before attempting to
+* read back the size value.
 */
+   testval = 0;
pci_write_config(dev, reg, 0x, 4);
-   testval = pci_read_config(dev, reg, 4);
if (ln2range == 64) {
pci_write_config(dev, reg + 4, 0x, 4);
testval |= (pci_addr_t)pci_read_config(dev, reg + 4, 4) << 32;
}
+   testval |= pci_read_config(dev, reg, 4);
 
/*
 * Restore the original value of the BAR.  We may have reprogrammed
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r319491 - head/sys/dev/xen/netfront

2017-06-02 Thread Roger Pau Monné
On Fri, Jun 02, 2017 at 07:03:31AM +, Colin Percival wrote:
> Author: cperciva
> Date: Fri Jun  2 07:03:31 2017
> New Revision: 319491
> URL: https://svnweb.freebsd.org/changeset/base/319491
> 
> Log:
>   Skip setting the MTU in the netfront driver (xn# devices) if the new MTU
>   is the same as the old MTU.  In particular, on Amazon EC2 "T2" instances
>   without this change, the network interface is reinitialized every 30
>   minutes due to the MTU being (re)set when a new DHCP lease is obtained,
>   causing packets to be dropped, along with annoying syslog messages about
>   the link state changing.
>   
>   As a side note, the behaviour this commit fixes was responsible for
>   exposing the locking problems fixed via r318523 and r318631.
>   
>   Maintainers of other network interface drivers may wish to consider making
>   the corresponding change; the handling of SIOCSIFMTU does not seem to
>   exhibit a great deal of consistency between drivers.

Is there any reason this check (ifp->if_mtu == ifr->ifr_mtu) is not
done at a higher level for all the drivers? It seems pointless to add
this chunk everywhere.

Roger.
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r318633 - head/usr.sbin/bsdinstall/scripts

2017-05-22 Thread Roger Pau Monné
Author: royger
Date: Mon May 22 11:41:17 2017
New Revision: 318633
URL: https://svnweb.freebsd.org/changeset/base/318633

Log:
  bsdinstall: do not use distextract in scripted mode
  
  It requires a tty, which might not be available in scripted installs. Instead
  extract the sets manually using tar.
  
  Reviewed by:  tsoome
  Sponsored by: Citrix Systems R
  MFC after:1 week
  Differential revision:https://reviews.freebsd.org/D10736

Modified:
  head/usr.sbin/bsdinstall/scripts/script

Modified: head/usr.sbin/bsdinstall/scripts/script
==
--- head/usr.sbin/bsdinstall/scripts/script Mon May 22 11:38:39 2017
(r318632)
+++ head/usr.sbin/bsdinstall/scripts/script Mon May 22 11:41:17 2017
(r318633)
@@ -114,7 +114,10 @@ fi
 
 # Unpack distributions
 bsdinstall checksum
-bsdinstall distextract
+for set in $DISTRIBUTIONS; do
+   f_dprintf "Extracting $BSDINSTALL_DISTDIR/$set"
+   tar -xf "$BSDINSTALL_DISTDIR/$set" -C $BSDINSTALL_CHROOT
+done
 
 # Finalize install
 bsdinstall config
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r318632 - head/usr.sbin/bsdinstall/scripts

2017-05-22 Thread Roger Pau Monné
Author: royger
Date: Mon May 22 11:38:39 2017
New Revision: 318632
URL: https://svnweb.freebsd.org/changeset/base/318632

Log:
  bsdinstall: mount is not needed for the ZFS install case
  
  Because the datasets are already mounted by zfsboot, and the mount script
  doesn't know anything about ZFS. Also do not execute the "umount" script for
  ZFS for the same reasons.
  
  Reviewed by:  dteske, tsoome
  Sponsored by: Citrix Systems R
  MFC after:1 week
  Differential revision:https://reviews.freebsd.org/D10738

Modified:
  head/usr.sbin/bsdinstall/scripts/script

Modified: head/usr.sbin/bsdinstall/scripts/script
==
--- head/usr.sbin/bsdinstall/scripts/script Mon May 22 11:33:44 2017
(r318631)
+++ head/usr.sbin/bsdinstall/scripts/script Mon May 22 11:38:39 2017
(r318632)
@@ -42,6 +42,11 @@ f_include $BSDCFG_SHARE/variable.subr
 # DISTRIBUTIONS
 # BSDINSTALL_DISTDIR
 
+#
+# Default name of the ZFS boot-pool
+#
+: ${ZFSBOOT_POOL_NAME:=zroot}
+
  GLOBALS
 
 #
@@ -53,8 +58,6 @@ msg_installation_error="Installation Err
 
 error()
 {
-   [ -f "$PATH_FSTAB" ] && bsdinstall umount
-   
local file
f_getvar "$VAR_DEBUG_FILE#+" file
if [ "$file" ]; then
@@ -63,6 +66,13 @@ error()
# No need to restore title, pining for the fjords
fi
 
+   [ -f "$PATH_FSTAB" ] || exit
+   if [ "$ZFSBOOT_DISKS" ]; then
+   zpool export $ZFSBOOT_POOL_NAME
+   else
+   bsdinstall umount
+   fi
+
exit 1
 }
 
@@ -99,8 +109,8 @@ if [ "$ZFSBOOT_DISKS" ]; then
bsdinstall zfsboot
 else
bsdinstall scriptedpart "$PARTITIONS"
+   bsdinstall mount
 fi
-bsdinstall mount
 
 # Unpack distributions
 bsdinstall checksum
@@ -125,7 +135,11 @@ if [ -f /tmp/bsdinstall-installscript-ab
 fi
 
 bsdinstall entropy
-bsdinstall umount
+if [ "$ZFSBOOT_DISKS" ]; then
+   zpool export $ZFSBOOT_POOL_NAME
+else
+   bsdinstall umount
+fi
 
 f_dprintf "Installation Completed at %s" "$( date )"
 
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r318631 - head/sys/dev/xen/netfront

2017-05-22 Thread Roger Pau Monné
Author: royger
Date: Mon May 22 11:33:44 2017
New Revision: 318631
URL: https://svnweb.freebsd.org/changeset/base/318631

Log:
  xen/netfront: don't drop the RX lock in xn_rxeof
  
  Since netfront uses different locks for the RX and TX paths there's no need to
  drop the RX lock before calling if_input.
  
  Suggested by: jhb
  Tested by:cperciva
  Sponsored by: Citrix Systems R
  MFC with: r318523

Modified:
  head/sys/dev/xen/netfront/netfront.c

Modified: head/sys/dev/xen/netfront/netfront.c
==
--- head/sys/dev/xen/netfront/netfront.cMon May 22 10:28:17 2017
(r318630)
+++ head/sys/dev/xen/netfront/netfront.cMon May 22 11:33:44 2017
(r318631)
@@ -1224,7 +1224,6 @@ xn_rxeof(struct netfront_rxq *rxq)
RING_FINAL_CHECK_FOR_RESPONSES(>ring, work_to_do);
} while (work_to_do);
 
-   XN_RX_UNLOCK(rxq);
mbufq_drain(_errq);
/*
 * Process all the mbufs after the remapping is complete.
@@ -1253,7 +1252,6 @@ xn_rxeof(struct netfront_rxq *rxq)
 */
tcp_lro_flush_all(lro);
 #endif
-   XN_RX_LOCK(rxq);
 }
 
 static void
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r318523 - head/sys/dev/xen/netfront

2017-05-19 Thread Roger Pau Monné
Author: royger
Date: Fri May 19 08:19:51 2017
New Revision: 318523
URL: https://svnweb.freebsd.org/changeset/base/318523

Log:
  xen/netfront: don't drop the ring RX lock with inconsistent ring state
  
  Make sure the RX ring lock is only released when the state of the ring is
  consistent, or else concurrent calls to xn_rxeof might get an inconsistent 
ring
  state and thus some packets might be processed twice.
  
  Note that this is not very common, and could only happen when an interrupt is
  delivered while in xn_ifinit.
  
  Reported by:  cperciva
  Tested by:cperciva
  MFC after:1 week
  Sponsored by: Citrix Systems R

Modified:
  head/sys/dev/xen/netfront/netfront.c

Modified: head/sys/dev/xen/netfront/netfront.c
==
--- head/sys/dev/xen/netfront/netfront.cFri May 19 08:19:39 2017
(r318522)
+++ head/sys/dev/xen/netfront/netfront.cFri May 19 08:19:51 2017
(r318523)
@@ -1161,17 +1161,18 @@ xn_rxeof(struct netfront_rxq *rxq)
struct mbufq mbufq_rxq, mbufq_errq;
int err, work_to_do;
 
-   do {
-   XN_RX_LOCK_ASSERT(rxq);
-   if (!netfront_carrier_ok(np))
-   return;
-
-   /* XXX: there should be some sane limit. */
-   mbufq_init(_errq, INT_MAX);
-   mbufq_init(_rxq, INT_MAX);
+   XN_RX_LOCK_ASSERT(rxq);
+
+   if (!netfront_carrier_ok(np))
+   return;
+
+   /* XXX: there should be some sane limit. */
+   mbufq_init(_errq, INT_MAX);
+   mbufq_init(_rxq, INT_MAX);
 
-   ifp = np->xn_ifp;
+   ifp = np->xn_ifp;
 
+   do {
rp = rxq->ring.sring->rsp_prod;
rmb();  /* Ensure we see queued responses up to 'rp'. */
 
@@ -1191,7 +1192,7 @@ xn_rxeof(struct netfront_rxq *rxq)
}
 
m->m_pkthdr.rcvif = ifp;
-   if ( rx->flags & NETRXF_data_validated ) {
+   if (rx->flags & NETRXF_data_validated) {
/*
 * According to mbuf(9) the correct way to tell
 * the stack that the checksum of an inbound
@@ -1214,50 +1215,45 @@ xn_rxeof(struct netfront_rxq *rxq)
}
 
(void )mbufq_enqueue(_rxq, m);
-   rxq->ring.rsp_cons = i;
}
 
-   mbufq_drain(_errq);
+   rxq->ring.rsp_cons = i;
 
-   /*
-* Process all the mbufs after the remapping is complete.
-* Break the mbuf chain first though.
-*/
-   while ((m = mbufq_dequeue(_rxq)) != NULL) {
-   if_inc_counter(ifp, IFCOUNTER_IPACKETS, 1);
+   xn_alloc_rx_buffers(rxq);
 
-   /* XXX: Do we really need to drop the rx lock? */
-   XN_RX_UNLOCK(rxq);
+   RING_FINAL_CHECK_FOR_RESPONSES(>ring, work_to_do);
+   } while (work_to_do);
+
+   XN_RX_UNLOCK(rxq);
+   mbufq_drain(_errq);
+   /*
+* Process all the mbufs after the remapping is complete.
+* Break the mbuf chain first though.
+*/
+   while ((m = mbufq_dequeue(_rxq)) != NULL) {
+   if_inc_counter(ifp, IFCOUNTER_IPACKETS, 1);
 #if (defined(INET) || defined(INET6))
-   /* Use LRO if possible */
-   if ((ifp->if_capenable & IFCAP_LRO) == 0 ||
-   lro->lro_cnt == 0 || tcp_lro_rx(lro, m, 0)) {
-   /*
-* If LRO fails, pass up to the stack
-* directly.
-*/
-   (*ifp->if_input)(ifp, m);
-   }
-#else
+   /* Use LRO if possible */
+   if ((ifp->if_capenable & IFCAP_LRO) == 0 ||
+   lro->lro_cnt == 0 || tcp_lro_rx(lro, m, 0)) {
+   /*
+* If LRO fails, pass up to the stack
+* directly.
+*/
(*ifp->if_input)(ifp, m);
-#endif
-
-   XN_RX_LOCK(rxq);
}
-
-   rxq->ring.rsp_cons = i;
+#else
+   (*ifp->if_input)(ifp, m);
+#endif
+   }
 
 #if (defined(INET) || defined(INET6))
-   /*
-* Flush any outstanding LRO work
-*/
-   tcp_lro_flush_all(lro);
+   /*
+* Flush any outstanding LRO work
+*/
+   tcp_lro_flush_all(lro);
 #endif
-
-   xn_alloc_rx_buffers(rxq);
-
-   RING_FINAL_CHECK_FOR_RESPONSES(>ring, work_to_do);
-   } while (work_to_do);
+   XN_RX_LOCK(rxq);
 }
 
 static void

svn commit: r318520 - head/sys/dev/xen/blkfront

2017-05-19 Thread Roger Pau Monné
Author: royger
Date: Fri May 19 08:11:15 2017
New Revision: 318520
URL: https://svnweb.freebsd.org/changeset/base/318520

Log:
  xen/blkfront: correctly detach a disk with active users
  
  Call disk_gone when the backend switches to the "Closing" state and blkfront
  still has pending users. This allows the disk to be detached, and will call
  into xbd_closing by itself when the geom layout cleanup has finished.
  
  Reported by:  bapt
  Tested by:manu
  Reviewed by:  bapt
  Sponsored by: Citrix Systems R
  MFC after:1 week
  Differential revision:https://reviews.freebsd.org/D10772

Modified:
  head/sys/dev/xen/blkfront/blkfront.c

Modified: head/sys/dev/xen/blkfront/blkfront.c
==
--- head/sys/dev/xen/blkfront/blkfront.cFri May 19 07:31:48 2017
(r318519)
+++ head/sys/dev/xen/blkfront/blkfront.cFri May 19 08:11:15 2017
(r318520)
@@ -1578,11 +1578,14 @@ xbd_backend_changed(device_t dev, Xenbus
break;
 
case XenbusStateClosing:
-   if (sc->xbd_users > 0)
-   xenbus_dev_error(dev, -EBUSY,
-   "Device in use; refusing to close");
-   else
+   if (sc->xbd_users > 0) {
+   device_printf(dev, "detaching with pending users\n");
+   KASSERT(sc->xbd_disk != NULL,
+   ("NULL disk with pending users\n"));
+   disk_gone(sc->xbd_disk);
+   } else {
xbd_closing(dev);
+   }
break;  
}
 }
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r301198 - head/sys/dev/xen/netfront

2017-05-10 Thread Roger Pau Monné
On Tue, May 09, 2017 at 08:36:13PM +, Colin Percival wrote:
> On 05/09/17 03:09, Roger Pau Monn� wrote:
> > On Wed, May 03, 2017 at 05:13:40AM +, Colin Percival wrote:
> >> On 06/02/16 04:16, Roger Pau Monn� wrote:
> >>> Author: royger
> >>> Date: Thu Jun  2 11:16:35 2016
> >>> New Revision: 301198
> >>> URL: https://svnweb.freebsd.org/changeset/base/301198
> >>
> >> I think this commit is responsible for panics I'm seeing in EC2 on T2 
> >> family
> >> instances.  [...]
> >> but under high traffic volumes I think a separate thread can already be
> >> running in xn_rxeof, having dropped the RX lock while it passes a packet
> >> up the stack.  This would result in two different threads trying to process
> >> the same set of responses from the ring, with (unsurprisingly) bad results.
> > 
> > Hm, right, xn_rxeof drops the lock while pushing the packet up the stack.
> > There's a "XXX" comment on top of that, could you try to remove the lock
> > dripping and see what happens?
> > 
> > I'm not sure there's any reason to drop the lock here, I very much doubt
> > if_input is going to sleep.
> 
> Judging by
> $ grep -R -B 1 -A 1 if_input /usr/src/sys/dev
> I'm pretty sure that we do indeed need to drop the lock.  If it's possible
> to enter if_input while holding locks, there are a *lot* of network interface
> drivers which are dropping locks unnecessarily...
> 
> >> 3. Why xn_ifinit_locked is consuming ring responses.
> > 
> > There might be pending RX packets on the ring, so netfront consumes them and
> > signals netback. In the unlikely event that the RX ring was full when
> > xn_ifinit_locked is called, not doing this would mean the RX queue would get
> > stuck forever, since there's no guarantee netfront will receive event 
> > channel
> > notifications.
> 
> In that case, I'm guessing it would be safe to skip this if another thread is
> already running xn_rxeof and chewing through the packets on the ring?  It
> would be easy to set a flag in xn_rxeof before we drop locks.

Hm, I think it would be better to fix xn_rxeof so that netfront doesn't drop
the lock while poking at the ring, what about the following patch?

It should also prevent needlessly dropping and acquiring the lock for each
packet netfront pushes up the stack.

NB: I've only compile-tested this.

---8<---
diff --git a/sys/dev/xen/netfront/netfront.c b/sys/dev/xen/netfront/netfront.c
index 99ccdaaf5000..482b9e948fde 100644
--- a/sys/dev/xen/netfront/netfront.c
+++ b/sys/dev/xen/netfront/netfront.c
@@ -1161,17 +1161,18 @@ xn_rxeof(struct netfront_rxq *rxq)
struct mbufq mbufq_rxq, mbufq_errq;
int err, work_to_do;
 
-   do {
-   XN_RX_LOCK_ASSERT(rxq);
-   if (!netfront_carrier_ok(np))
-   return;
+   XN_RX_LOCK_ASSERT(rxq);
+
+   if (!netfront_carrier_ok(np))
+   return;
 
-   /* XXX: there should be some sane limit. */
-   mbufq_init(_errq, INT_MAX);
-   mbufq_init(_rxq, INT_MAX);
+   /* XXX: there should be some sane limit. */
+   mbufq_init(_errq, INT_MAX);
+   mbufq_init(_rxq, INT_MAX);
 
-   ifp = np->xn_ifp;
+   ifp = np->xn_ifp;
 
+   do {
rp = rxq->ring.sring->rsp_prod;
rmb();  /* Ensure we see queued responses up to 'rp'. */
 
@@ -1191,7 +1192,7 @@ xn_rxeof(struct netfront_rxq *rxq)
}
 
m->m_pkthdr.rcvif = ifp;
-   if ( rx->flags & NETRXF_data_validated ) {
+   if (rx->flags & NETRXF_data_validated) {
/*
 * According to mbuf(9) the correct way to tell
 * the stack that the checksum of an inbound
@@ -1214,50 +1215,45 @@ xn_rxeof(struct netfront_rxq *rxq)
}
 
(void )mbufq_enqueue(_rxq, m);
-   rxq->ring.rsp_cons = i;
}
 
-   mbufq_drain(_errq);
+   rxq->ring.rsp_cons = i;
 
-   /*
-* Process all the mbufs after the remapping is complete.
-* Break the mbuf chain first though.
-*/
-   while ((m = mbufq_dequeue(_rxq)) != NULL) {
-   if_inc_counter(ifp, IFCOUNTER_IPACKETS, 1);
+   xn_alloc_rx_buffers(rxq);
 
-   /* XXX: Do we really need to drop the rx lock? */
-   XN_RX_UNLOCK(rxq);
+   RING_FINAL_CHECK_FOR_RESPONSES(>ring, work_to_do);
+   } while (work_to_do);
+
+   XN_RX_UNLOCK(rxq);
+   mbufq_drain(_errq);
+   /*
+* Process all the mbufs after the remapping is complete.
+* Break the mbuf chain first though.
+*/
+   while ((m = mbufq_dequeue(_rxq)) != NULL) {
+   if_inc_counter(ifp, IFCOUNTER_IPACKETS, 1);
 #if (defined(INET) || defined(INET6))
-  

Re: svn commit: r301198 - head/sys/dev/xen/netfront

2017-05-09 Thread Roger Pau Monné
On Wed, May 03, 2017 at 05:13:40AM +, Colin Percival wrote:
> On 06/02/16 04:16, Roger Pau Monné wrote:
> > Author: royger
> > Date: Thu Jun  2 11:16:35 2016
> > New Revision: 301198
> > URL: https://svnweb.freebsd.org/changeset/base/301198
> 
> I think this commit is responsible for panics I'm seeing in EC2 on T2 family
> instances.  Every time a DHCP request is made, we call into xn_ifinit_locked
> (not sure why -- something to do with making the interface promiscuous?) and
> hit this code
> 
> > @@ -1760,7 +1715,7 @@ xn_ifinit_locked(struct netfront_info *n
> > xn_alloc_rx_buffers(rxq);
> > rxq->ring.sring->rsp_event = rxq->ring.rsp_cons + 1;
> > if (RING_HAS_UNCONSUMED_RESPONSES(>ring))
> > -   taskqueue_enqueue(rxq->tq, >intrtask);
> > +   xn_rxeof(rxq);
> > XN_RX_UNLOCK(rxq);
> > }
> 
> but under high traffic volumes I think a separate thread can already be
> running in xn_rxeof, having dropped the RX lock while it passes a packet
> up the stack.  This would result in two different threads trying to process
> the same set of responses from the ring, with (unsurprisingly) bad results.

Hm, right, xn_rxeof drops the lock while pushing the packet up the stack.
There's a "XXX" comment on top of that, could you try to remove the lock
dripping and see what happens?

I'm not sure there's any reason to drop the lock here, I very much doubt
if_input is going to sleep.

> I'm not 100% sure that this is what's causing the panic, but it's definitely
> happening under high traffic conditions immediately after xn_ifinit_locked is
> called, so I think my speculation is well-founded.
> 
> There are a few things I don't understand here:
> 1. Why DHCP requests are resulting in calls into xn_ifinit_locked.

Maybe DHCP flaps the interface up and down? TBH I have no idea.
Enabling/disabling certain features (CSUM, TSO) will also cause the interface
to reconnect, which might cause incoming packets to get stuck in the RX ring.

> 2. Why the calls into xn_ifinit_locked are only happening on T2 instances
> and not on any of the other EC2 instances I've tried.

Maybe T2 instances are on a more noisy environment? That I'm afraid I have no
idea.

> 3. Why xn_ifinit_locked is consuming ring responses.

There might be pending RX packets on the ring, so netfront consumes them and
signals netback. In the unlikely event that the RX ring was full when
xn_ifinit_locked is called, not doing this would mean the RX queue would get
stuck forever, since there's no guarantee netfront will receive event channel
notifications.

> so I'm not sure what the solution is, but hopefully someone who knows this
> code better will be able to help...

My first try would be to disable dropping the lock in xn_rxeof, I think that is
utterly incorrect. That should prevent multiple consumers from pocking at the
ring at the same time.

Roger.
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r316754 - in head/sys/boot: common i386/libi386

2017-04-13 Thread Roger Pau Monné
Author: royger
Date: Thu Apr 13 09:59:12 2017
New Revision: 316754
URL: https://svnweb.freebsd.org/changeset/base/316754

Log:
  loader/multiboot: fix multiboot loading
  
  The current multiboot loader code doesn't clean the metadata added to the
  kernel after the bi_load64 dry run, which breaks accounting of the required
  memory for the metadata.
  
  This issue didn't show itself before because all the metadata items where 
small
  (8bytes), but after r316343 there's a big blob in the metadata, which triggers
  this. Fix it by cleaning the metadata added to the kernel after the bi_load64
  dry run. Also add a comment describing the memory layout when booting using
  multiboot (Xen Dom0).
  
  This unbreaks booting a FreeBSD/Xen Dom0 after r316343.
  
  MFC after:3 weeks
  Sponsored by: Citrix Systems R

Modified:
  head/sys/boot/common/bootstrap.h
  head/sys/boot/common/module.c
  head/sys/boot/i386/libi386/multiboot.c

Modified: head/sys/boot/common/bootstrap.h
==
--- head/sys/boot/common/bootstrap.hThu Apr 13 08:21:29 2017
(r316753)
+++ head/sys/boot/common/bootstrap.hThu Apr 13 09:59:12 2017
(r316754)
@@ -228,6 +228,7 @@ void file_discard(struct preloaded_file 
 void file_addmetadata(struct preloaded_file *fp, int type, size_t size, void 
*p);
 int  file_addmodule(struct preloaded_file *fp, char *modname, int version,
struct kernel_module **newmp);
+void file_removemetadata(struct preloaded_file *fp);
 
 /* MI module loaders */
 #ifdef __elfN

Modified: head/sys/boot/common/module.c
==
--- head/sys/boot/common/module.c   Thu Apr 13 08:21:29 2017
(r316753)
+++ head/sys/boot/common/module.c   Thu Apr 13 09:59:12 2017
(r316754)
@@ -663,6 +663,22 @@ file_findmetadata(struct preloaded_file 
 return(md);
 }
 
+/*
+ * Remove all metadata from the file.
+ */
+void
+file_removemetadata(struct preloaded_file *fp)
+{
+struct file_metadata *md, *next;
+
+for (md = fp->f_metadata; md != NULL; md = next)
+{
+   next = md->md_next;
+   free(md);
+}
+fp->f_metadata = NULL;
+}
+
 struct file_metadata *
 metadata_next(struct file_metadata *md, int type)
 {

Modified: head/sys/boot/i386/libi386/multiboot.c
==
--- head/sys/boot/i386/libi386/multiboot.c  Thu Apr 13 08:21:29 2017
(r316753)
+++ head/sys/boot/i386/libi386/multiboot.c  Thu Apr 13 09:59:12 2017
(r316754)
@@ -267,7 +267,39 @@ multiboot_exec(struct preloaded_file *fp
 * information is placed at the start of the second module and
 * the original modulep value is saved together with the other
 * metadata, so we can relocate everything.
+*
+* Native layout:
+*   fp->f_addr + fp->f_size
+* +-+++
+* | |||
+* | Kernel  |Modules |  Metadata  |
+* | |||
+* +-+++
+* fp->f_addr modulep  kernend
+*
+* Xen layout:
+*
+* Initial:
+*  fp->f_addr + fp->f_size
+* +-+--+++
+* | |  |||
+* | Kernel  | Reserved |Modules |  Metadata  |
+* | |  ||  dry run   |
+* +-+--+++
+* fp->f_addr
+*
+* After metadata polacement (ie: final):
+*  fp->f_addr + fp->f_size
+* +---+-+--++
+* |   | |  ||
+* |  Kernel   |  Free   | Metadata |Modules |
+* |   | |  ||
+* +---+-+--++
+* fp->f_addrmodulep kernend
+* \__/  \__/
+*  Multiboot module 0Multiboot module 1
 */
+
fp = file_findfile(NULL, "elf kernel");
if (fp == NULL) {
printf("No FreeBSD kernel provided, aborting\n");
@@ -275,6 +307,13 @@ multiboot_exec(struct preloaded_file *fp
goto error;
}
 
+   if (fp->f_metadata != NULL) {
+   printf("FreeBSD kernel already contains metadata, aborting\n");
+   error = EINVAL;
+   goto error;
+   }
+
+
mb_mod = malloc(sizeof(struct multiboot_mod_list) * NUM_MODULES);
if (mb_mod == NULL) {
error = ENOMEM;
@@ -312,6 +351,9 @@ 

Re: svn commit: r316106 - head/sys/boot/zfs

2017-03-29 Thread Roger Pau Monné
On Tue, Mar 28, 2017 at 08:39:24PM +, Ngie Cooper wrote:
> Author: ngie
> Date: Tue Mar 28 20:39:24 2017
> New Revision: 316106
> URL: https://svnweb.freebsd.org/changeset/base/316106
> 
> Log:
>   Don't shadow read(2) definition with `read` argument in vdev_{create,probe}
>   
>   This fixes several -Wshadow warnings introduced in r192194, but now errors
>   with gcc 6.3.0.
>   
>   MFC after:  3 days
>   Reported by:amd64-gcc-6.3.0 (devel/amd64-xtoolchain-gcc)
>   Sponsored by:   Dell EMC Isilon
> 
> Modified:
>   head/sys/boot/zfs/zfsimpl.c
> 
> Modified: head/sys/boot/zfs/zfsimpl.c
> ==
> --- head/sys/boot/zfs/zfsimpl.c   Tue Mar 28 20:34:02 2017
> (r316105)
> +++ head/sys/boot/zfs/zfsimpl.c   Tue Mar 28 20:39:24 2017
> (r316106)
> @@ -494,7 +494,7 @@ vdev_find(uint64_t guid)
>  }
>  
>  static vdev_t *
> -vdev_create(uint64_t guid, vdev_read_t *read)
> +vdev_create(uint64_t guid, vdev_read_t *_read)

Just a nit, but IMHO it would be clearer to use read_func, read_helper or some
more descriptive name since you where already changing this.

Roger.
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


  1   2   3   4   >