Jeremie,
On Tue, Jan 14, 2014 at 08:26:21AM +0100, Jeremie Le Hen wrote:
J Hi,
J
J I have a FreeBSD -CURRENT in Virtualbox (running on Linux). I have been
J unable to buildworld for a while.
J
J I suspect this is not a problem with the source because I didn't see any
J report so far, whereas
I was recently talking to someone about how one would backup / restore
ACLs reliably. I didn't see any mention of ACLs in the mtree man page
and after a quick google I came upon this old mailing list post:
http://lists.freebsd.org/pipermail/freebsd-hackers/2008-April/024173.html
patch in list is
This should not introduce any functional change, and makes the
functions suitable to be called before we have actually mapped the
vcpu_info struct on a per-cpu basis.
---
sys/dev/xen/timer/timer.c | 29 -
1 files changed, 20 insertions(+), 9 deletions(-)
diff --git
---
sys/xen/xen-os.h |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/sys/xen/xen-os.h b/sys/xen/xen-os.h
index c7474d8..e8a5a99 100644
--- a/sys/xen/xen-os.h
+++ b/sys/xen/xen-os.h
@@ -82,6 +82,13 @@ xen_hvm_domain(void)
return (xen_domain_type ==
---
sys/amd64/amd64/machdep.c | 50 ++
sys/amd64/include/pc/bios.h |2 +
sys/amd64/include/sysarch.h |1 +
sys/x86/xen/pv.c| 25 +
4 files changed, 59 insertions(+), 19 deletions(-)
diff --git
When running as a PVH guest, there's no emulated i8254, so we need to
use the Xen PV timer as the early source for DELAY. This change allows
for different implementations of the early DELAY function and
implements a Xen variant for it.
---
sys/amd64/amd64/machdep.c |6 ++-
Add the PV/PVH entry point and the low level functions for PVH
initialization.
---
sys/amd64/amd64/locore.S |1 +
sys/amd64/amd64/xen-locore.S | 83 +
sys/amd64/include/asmacros.h | 26 +
sys/conf/files.amd64 |2 +
This series is a split of the previous patch Xen x86 DomU PVH
support, with the aim to make the review of the code easier.
The series can also be found on my git repo:
git://xenbits.xen.org/people/royger/freebsd.git pvh_v10
or
This adds and enables the console used on XEN kernels.
---
sys/conf/files |4 +-
sys/dev/xen/console/console.c | 37 +--
sys/dev/xen/console/xencons_ring.c | 15 +
sys/i386/include/xen/xen-os.h |1 -
---
sys/amd64/include/xen/hypercall.h |7 ---
sys/i386/i386/locore.s|9 +
sys/i386/include/xen/hypercall.h |8
sys/x86/xen/hvm.c | 24 ++--
4 files changed, 19 insertions(+), 29 deletions(-)
diff --git
---
sys/conf/files.amd64 |1 +
sys/x86/xen/pvcpu_enum.c | 136 ++
2 files changed, 137 insertions(+), 0 deletions(-)
create mode 100644 sys/x86/xen/pvcpu_enum.c
diff --git a/sys/conf/files.amd64 b/sys/conf/files.amd64
index 109a796..a3491da
---
sys/amd64/amd64/machdep.c | 41 --
sys/amd64/include/sysarch.h | 12 ++
sys/x86/xen/pv.c| 82 +++
3 files changed, 124 insertions(+), 11 deletions(-)
diff --git a/sys/amd64/amd64/machdep.c
I have found out that when I use 2 AR9580 mini PCIe board
some irq (namely in that case irq18 is shared over 3 devices)
I wonder why it is done like this and if this could be something to fix ?
Kernel is 30/12/2014 CURRENT ( FreeBSD/amd64) with :
options mptable
vmstat -i
interrupt
AP startup on PVH follows the PV method, so we need to add a hook in
order to diverge from bare metal.
---
sys/amd64/amd64/mp_machdep.c | 14 +++---
sys/amd64/include/cpu.h |1 +
sys/amd64/include/smp.h |1 +
sys/x86/xen/hvm.c| 12 +-
sys/x86/xen/pv.c
---
sys/x86/isa/isa.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/sys/x86/isa/isa.c b/sys/x86/isa/isa.c
index 1a57137..9287ff2 100644
--- a/sys/x86/isa/isa.c
+++ b/sys/x86/isa/isa.c
@@ -241,3 +241,6 @@ isa_release_resource(device_t bus, device_t child, int
type,
Since there's no ACPI on PVH guests, we need to create a dummy CPU
device in order to fill the pcpu-pc_device field.
---
sys/conf/files|1 +
sys/dev/xen/pvcpu/pvcpu.c | 101 +
2 files changed, 102 insertions(+), 0 deletions(-)
create
Introduce a Xen specific nexus that is going to be in charge for
attaching Xen specific devices.
---
sys/conf/files.amd64 |1 +
sys/conf/files.i386 |1 +
sys/dev/xen/console/console.c |2 +-
sys/dev/xen/timer/timer.c |4 +-
sys/dev/xen/xenpci/xenpci.c |
PVH guests don't have an emulated lapic.
---
sys/amd64/amd64/mp_machdep.c | 10 ++
sys/amd64/include/apicvar.h |1 +
sys/i386/include/apicvar.h |1 +
sys/i386/xen/xen_machdep.c |2 ++
sys/x86/x86/local_apic.c |8 +---
sys/x86/xen/pv.c |3 +++
Since Xen PVH guests doesn't have ACPI, we need to create a dummy
bus so top level Xen devices can attach to it (instead of
attaching directly to the nexus) and a pvcpu device that will be used
to fill the pcpu-pc_device field.
---
sys/conf/files.amd64 |1 +
sys/conf/files.i386 |1 +
---
sys/xen/gnttab.c | 26 +-
1 files changed, 21 insertions(+), 5 deletions(-)
diff --git a/sys/xen/gnttab.c b/sys/xen/gnttab.c
index 03c32b7..6949be5 100644
--- a/sys/xen/gnttab.c
+++ b/sys/xen/gnttab.c
@@ -25,6 +25,7 @@ __FBSDID($FreeBSD$);
#include sys/lock.h
Add the PV shutdown hook to PVH.
---
sys/dev/xen/control/control.c | 37 ++---
1 files changed, 18 insertions(+), 19 deletions(-)
diff --git a/sys/dev/xen/control/control.c b/sys/dev/xen/control/control.c
index bc0609d..78894ba 100644
---
On PVH we don't need to init the shared info page, or disable emulated
devices. Also, make sure PV IPIs are set before starting the APs.
---
sys/x86/xen/hvm.c | 17 -
1 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/sys/x86/xen/hvm.c b/sys/x86/xen/hvm.c
index
This hook will only be implemented for bare metal, Xen doesn't require
any bootstrap code since APs are started in long mode with paging
enabled.
---
sys/amd64/amd64/machdep.c |6 +-
sys/amd64/include/sysarch.h |1 +
2 files changed, 6 insertions(+), 1 deletions(-)
diff --git
---
sys/xen/xenstore/xenstore.c | 18 +-
1 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/sys/xen/xenstore/xenstore.c b/sys/xen/xenstore/xenstore.c
index b5cf413..7fa08cc 100644
--- a/sys/xen/xenstore/xenstore.c
+++ b/sys/xen/xenstore/xenstore.c
@@ -229,13 +229,11
On 01/14/2014 02:59 PM, Roger Pau Monne wrote:
+static int
+xenpv_attach(device_t dev)
+{
+ device_t child;
+
+ if (xen_hvm_domain()) {
+ device_t xenpci;
+ devclass_t dc;
+
+ /* Make sure xenpci has been attached */
+ dc =
On 14/01/14 16:41, Julien Grall wrote:
On 01/14/2014 02:59 PM, Roger Pau Monne wrote:
+static int
+xenpv_attach(device_t dev)
+{
+device_t child;
+
+if (xen_hvm_domain()) {
+device_t xenpci;
+devclass_t dc;
+
+/* Make sure xenpci has been
On 14/01/14 17:14, Julien Grall wrote:
On 01/14/2014 04:08 PM, Roger Pau Monné wrote:
On 14/01/14 16:41, Julien Grall wrote:
On 01/14/2014 02:59 PM, Roger Pau Monne wrote:
+static int
+xenpv_attach(device_t dev)
+{
+ device_t child;
+
+ if (xen_hvm_domain()) {
+ device_t
On 01/14/2014 04:08 PM, Roger Pau Monné wrote:
On 14/01/14 16:41, Julien Grall wrote:
On 01/14/2014 02:59 PM, Roger Pau Monne wrote:
+static int
+xenpv_attach(device_t dev)
+{
+ device_t child;
+
+ if (xen_hvm_domain()) {
+ device_t xenpci;
+ devclass_t dc;
+
+
On 01/14/2014 04:20 PM, Roger Pau Monné wrote:
On 14/01/14 17:14, Julien Grall wrote:
On 01/14/2014 04:08 PM, Roger Pau Monné wrote:
On 14/01/14 16:41, Julien Grall wrote:
On 01/14/2014 02:59 PM, Roger Pau Monne wrote:
+static int
+xenpv_attach(device_t dev)
+{
+ device_t child;
+
+ if
Hi all,
I'm trying to port a PIM sparse-mode daemon (
https://github.com/troglobit/pimd/) and I've meet a problem:
This daemon compile and run fine on FreeBSD 9.2 but on 10-RC5 this daemon
can't understand received multicast packets (received from other PIM
neighbors) and display this kind of
On Mon, Jan 13, 2014 at 8:22 PM, Glen Barber g...@freebsd.org wrote:
On Mon, Jan 13, 2014 at 08:15:34PM -0800, John-Mark Gurney wrote:
So, now when I run pkg I get the following:
pkg: Ignoring bad configuration entry in
/usr/local/etc/pkg/repos/FreeBSD.conf: URL:
Dear FreeBSD Community,
Please note that the submission date for the October to December
Quarterly Status Reports is, January 14th, 2014, today. Please
consult my earlier message for the details:
On Sat, Dec 14, 2013 at 2:05 PM, Gabor Pali p...@freebsd.org wrote:
Dear FreeBSD Community,
On Tuesday, January 14, 2014 10:03:46 am Christophe Prevotaux wrote:
I have found out that when I use 2 AR9580 mini PCIe board
some irq (namely in that case irq18 is shared over 3 devices)
I wonder why it is done like this and if this could be something to fix ?
You can't fix it. This is
on 14/01/2014 07:27 Vladimir Sharun said the following:
Dear Andriy and FreeBSD community,
I am not sure if the buffers are leaked somehow or if they are actually in
use.
It's one of the very few places where data buffers are allocated without
charging ARC. In all other places it's quite
All,
I work with Jack on FreeBSD network drivers, and we have a patch that we
think might fix this problem. It re-implements the header pull-up code that
was in the driver pre-2.4.0, but with IPv6 support. Alexandre, could you
apply this patch to the igb version in HEAD and try it out on your
On Tue, Jan 14, 2014 at 12:58:18PM +0400, Gleb Smirnoff wrote:
Jeremie,
On Tue, Jan 14, 2014 at 08:26:21AM +0100, Jeremie Le Hen wrote:
J Hi,
J
J I have a FreeBSD -CURRENT in Virtualbox (running on Linux). I have been
J unable to buildworld for a while.
J
J I suspect this is not a
36 matches
Mail list logo
