Re: Xen performance on FreeBSD vs Linux

[Roger Pau Monné]

On Mon, Jan 13, 2020 at 02:51:16PM +0100, Juergen Gotteswinter wrote:
> Am So., 12. Jan. 2020 um 20:07 Uhr schrieb Stefan Parvu <
> spa...@kronometrix.org>:
> 
> > >
> > > Also a FreeBSD dom0 can only work in PVH mode, which is faster for
> > > certain operations like page table modifications, but it's slower for
> > > others, like issuing hypercalls, when compared to a PV dom0.
> > >
> > > I don't have figures at hand now, but guest creation is likely slower
> > > on a FreeBSD PVH dom0 than on a Linux PV dom0, and that's because
> > > hypercalls are more expensive on PVH than on PV (has nothing to do
> > > whether Linux or FreeBSD is used).
> >
> > right. thanks a lot for pointers. A bit confusing is that I see mentioned
> > around that Xen of FreeBSD is experimental. Is this true ?
> >
> > I will have 2 servers to test Xen and Bhyve on FreeBSD 12.1 and check how
> > well the hypervisors work for different guest from Linux, BSD and Windows.
> >
> > Im more interested on bhyve vs Xen on FreeBSd than Linux. We will keep
> > FreeBSD as our main virtualization platform.
> >
> > Stefan
> 
> 
> FreeBSD as Dom0 feels (at least ~6 month ago) really somehow experimental
> compared to my linux experience.

Hello,

Can you give us more details regarding this comment, and what did you
feel was missing or could be improved compared to Linux?

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

Re: Xen performance on FreeBSD vs Linux

[Roger Pau Monné]

On Sun, Jan 12, 2020 at 09:07:32PM +0200, Stefan Parvu wrote:
> > 
> > Also a FreeBSD dom0 can only work in PVH mode, which is faster for
> > certain operations like page table modifications, but it's slower for
> > others, like issuing hypercalls, when compared to a PV dom0.
> > 
> > I don't have figures at hand now, but guest creation is likely slower
> > on a FreeBSD PVH dom0 than on a Linux PV dom0, and that's because
> > hypercalls are more expensive on PVH than on PV (has nothing to do
> > whether Linux or FreeBSD is used).
> 
> right. thanks a lot for pointers. A bit confusing is that I see mentioned 
> around that Xen of FreeBSD is experimental. Is this true ? 

PVH dom0 support in Xen is experimental, the FreeBSD PVH bits are
mostly stable and I wouldn't expect many changes there except from
bug fixes. The PVH guest ABI is also stable since quite some time
ago.

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

Re: Xen performance on FreeBSD vs Linux

[Juergen Gotteswinter]

Am So., 12. Jan. 2020 um 20:07 Uhr schrieb Stefan Parvu <
spa...@kronometrix.org>:

> >
> > Also a FreeBSD dom0 can only work in PVH mode, which is faster for
> > certain operations like page table modifications, but it's slower for
> > others, like issuing hypercalls, when compared to a PV dom0.
> >
> > I don't have figures at hand now, but guest creation is likely slower
> > on a FreeBSD PVH dom0 than on a Linux PV dom0, and that's because
> > hypercalls are more expensive on PVH than on PV (has nothing to do
> > whether Linux or FreeBSD is used).
>
> right. thanks a lot for pointers. A bit confusing is that I see mentioned
> around that Xen of FreeBSD is experimental. Is this true ?
>
> I will have 2 servers to test Xen and Bhyve on FreeBSD 12.1 and check how
> well the hypervisors work for different guest from Linux, BSD and Windows.
>
> Im more interested on bhyve vs Xen on FreeBSd than Linux. We will keep
> FreeBSD as our main virtualization platform.
>
> Stefan


FreeBSD as Dom0 feels (at least ~6 month ago) really somehow experimental
compared to my linux experience. i would go the bhyve route if your
hardware supports the required cpu features.
___
freebsd-xen@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"

Re: Xen performance on FreeBSD vs Linux

[Roger Pau Monné]

On Mon, Jan 06, 2020 at 12:43:51PM +0200, Stefan Parvu wrote:
> Hi,
> 
> How Xen hypervisor compares in terms of performance (guest) on FreeBSD vs 
> Linux
> , using ZFS or UFS ?

There are several factors to take into account here.

On FreeBSD the hypervisor is built with clang, while on Linux it's
usually built with gcc, and hence different optimizations will be
used.

Also a FreeBSD dom0 can only work in PVH mode, which is faster for
certain operations like page table modifications, but it's slower for
others, like issuing hypercalls, when compared to a PV dom0.

I don't have figures at hand now, but guest creation is likely slower
on a FreeBSD PVH dom0 than on a Linux PV dom0, and that's because
hypercalls are more expensive on PVH than on PV (has nothing to do
whether Linux or FreeBSD is used).

> Are there any benchmarks or tests regarding this ?

I don't think so, but I think they will be useful if someone has the
time to perform them :).

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

Re: xen-kernel 4.12.1 unsupported amd family !? FreeBSD

[Roger Pau Monné]

On Fri, Dec 06, 2019 at 09:33:44AM +0100, davidheinrichplanner wrote:
> Hi Royger,
> 
> i want to inform you by freshports page but i forgett my pw and reset doesnt
> work :(.
> 
> first one i don't know which one must be informed about this problem (you or
> direct xen project, xen team by freebsd?). I have a amd epyc system with two
> cpus. And xen tell me its a unsupported amd family. How can be fix this
> problem?

I'm not sure I understand the problem. Does Xen refuse to boot on such
system?

Can you please paste the Xen boot log showing the issue?

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

Re: xen-kernel 4.12.1 unsupported amd family !? FreeBSD

[davidheinrichplanner via freebsd-xen]

On 2019-12-06 09:33, davidheinrichplanner wrote:

Hi Royger,

i want to inform you by freshports page but i forgett my pw and reset 
doesnt work :(.


first one i don't know which one must be informed about this problem 
(you or direct xen project, xen team by freebsd?). I have a amd epyc 
system with two cpus. And xen tell me its a unsupported amd family. 
How can be fix this problem?


its a supermicro board H11DSi-NT. (infos about it see attachment).

Best

 David



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

Re: Xen (HVM) and NMI

[Roger Pau Monné]

On Fri, Nov 08, 2019 at 03:15:40PM +0200, Andriy Gapon wrote:
> On 08/11/2019 11:57, Roger Pau Monné wrote:
> > On Fri, Nov 08, 2019 at 10:19:01AM +0200, Andriy Gapon wrote:
> >>> I found this in Linux code:
> >>> HYPERVISOR_vcpu_op(VCPUOP_send_nmi, xen_vcpu_nr(cpu), NULL);
> >>> It's in xen_send_IPI_one().
> >>> I wonder if that's that or if there is more to this than meets the eye.
> > 
> > Yes, something along this lines should work, we could even use the
> > native NMI signaling using the local APIC, but the hypercall shortcut
> > should be faster in most cases.
> > 
> >> I also found this in an old post.
> >> Ian Campbell wrote:
> >>> You need to register a callback with CALLBACKOP_register
> >>> CALLBACKTYPE_nmi. You also need to write the code in entry.S to receive
> >>> that callback. IIRC you also need to arrange that returning from an NMI
> >>> is always done with HYPERVISOR_iret and not optimised to a direct iret
> >>> as it can be otherwise. This is to allow the hypervisor to implement NMI
> >>> masking correctly.
> > 
> > That's AFAIK for PV guests which use a completely different mechanism
> > in order to receive interrupts. None of this is needed for FreeBSD
> > because there's no classic PV support.
> 
> Perhaps HYPERVISOR_iret is still needed even for us?

No, that's just for classic PV.

> This is said with zero knowledge of the topic.
> 
> > Can you try the patch below?
> 
> I tried it and, unfortunately, it was not a success.  And I don't have much
> diagnostic.

My bad, that's what happens when you send untested patches, the
previous patch was missing an apic_cpuid and was hitting a page-fault
in the kernel. Patch below should work fine.

Roger.
---8<---
diff --git a/sys/x86/xen/xen_apic.c b/sys/x86/xen/xen_apic.c
index 7d254ef3f734..8bf2158dbec2 100644
--- a/sys/x86/xen/xen_apic.c
+++ b/sys/x86/xen/xen_apic.c
@@ -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");
@@ -522,14 +560,6 @@ xen_cpususpend_handler(void *arg)
return (FILTER_HANDLED);
 }
 
-static int
-xen_cpustophard_handler(void *arg)
-{
-
-   ipi_nmi_handler();
-   return (FILTER_HANDLED);
-}
-
 /*- XEN PV IPI setup 
-*/
 /*
  * Those functions are provided outside of the Xen PV APIC implementation
___
freebsd-xen@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"

Re: Xen (HVM) and NMI

[Roger Pau Monné]

On Fri, Nov 08, 2019 at 10:19:01AM +0200, Andriy Gapon wrote:
> On 08/11/2019 10:03, Andriy Gapon wrote:
> > On 07/11/2019 20:08, Andriy Gapon wrote:
> >> For CPUs that do get interrupted I see stack traces like:
> >> cpustop_handler+0x28 ipi_nmi_handler+0x44 xen_cpustophard_handler+0x9
> >> intr_event_handle+0x8b intr_execute_handlers+0x58 
> >> xen_intr_handle_upcall+0x15a
> >> xen_intr_upcall_u+0x96 ...
> >> So, it looks like the NMI is delivered by the same mechanism as normal
> >> interrupts.  If a processor has interrupts disabled then the NMI would not 
> >> get
> >> delivered?

Yes, sorry, I certainly didn't code this correctly regarding NMI
handling.

> >> Is there anything we could do to improve this?
> > 
> > I found this in Linux code:
> > HYPERVISOR_vcpu_op(VCPUOP_send_nmi, xen_vcpu_nr(cpu), NULL);
> > It's in xen_send_IPI_one().
> > I wonder if that's that or if there is more to this than meets the eye.

Yes, something along this lines should work, we could even use the
native NMI signaling using the local APIC, but the hypercall shortcut
should be faster in most cases.

> I also found this in an old post.
> Ian Campbell wrote:
> > You need to register a callback with CALLBACKOP_register
> > CALLBACKTYPE_nmi. You also need to write the code in entry.S to receive
> > that callback. IIRC you also need to arrange that returning from an NMI
> > is always done with HYPERVISOR_iret and not optimised to a direct iret
> > as it can be otherwise. This is to allow the hypervisor to implement NMI
> > masking correctly.

That's AFAIK for PV guests which use a completely different mechanism
in order to receive interrupts. None of this is needed for FreeBSD
because there's no classic PV support.

Can you try the patch below?

Roger.
---8<---
diff --git a/sys/x86/xen/xen_apic.c b/sys/x86/xen/xen_apic.c
index 7d254ef3f734..7a6964d60cdb 100644
--- a/sys/x86/xen/xen_apic.c
+++ b/sys/x86/xen/xen_apic.c
@@ -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(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");
@@ -522,14 +560,6 @@ xen_cpususpend_handler(void *arg)
return (FILTER_HANDLED);
 }
 
-static int
-xen_cpustophard_handler(void *arg)
-{
-
-   ipi_nmi_handler();
-   return (FILTER_HANDLED);
-}
-
 /*- XEN PV IPI setup 
-*/
 /*
  * Those functions are provided outside of the Xen PV APIC implementation

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

Re: Xen (HVM) and NMI

[Andriy Gapon]

On 08/11/2019 10:03, Andriy Gapon wrote:
> On 07/11/2019 20:08, Andriy Gapon wrote:
>> For CPUs that do get interrupted I see stack traces like:
>> cpustop_handler+0x28 ipi_nmi_handler+0x44 xen_cpustophard_handler+0x9
>> intr_event_handle+0x8b intr_execute_handlers+0x58 
>> xen_intr_handle_upcall+0x15a
>> xen_intr_upcall_u+0x96 ...
>> So, it looks like the NMI is delivered by the same mechanism as normal
>> interrupts.  If a processor has interrupts disabled then the NMI would not 
>> get
>> delivered?
>>
>> Is there anything we could do to improve this?
> 
> I found this in Linux code:
> HYPERVISOR_vcpu_op(VCPUOP_send_nmi, xen_vcpu_nr(cpu), NULL);
> It's in xen_send_IPI_one().
> I wonder if that's that or if there is more to this than meets the eye.

I also found this in an old post.
Ian Campbell wrote:
> You need to register a callback with CALLBACKOP_register
> CALLBACKTYPE_nmi. You also need to write the code in entry.S to receive
> that callback. IIRC you also need to arrange that returning from an NMI
> is always done with HYPERVISOR_iret and not optimised to a direct iret
> as it can be otherwise. This is to allow the hypervisor to implement NMI
> masking correctly.

But I could not find a single use of CALLBACKTYPE_nmi in the Linux code (it's
defined but not referenced).
I did find this:
hypercall_iret = hypercall_page + __HYPERVISOR_iret * 32
ENTRY(xen_iret)
pushq $0
jmp hypercall_iret


-- 
Andriy Gapon
___
freebsd-xen@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"

Re: Xen (HVM) and NMI

[Andriy Gapon]

On 07/11/2019 20:08, Andriy Gapon wrote:
> For CPUs that do get interrupted I see stack traces like:
> cpustop_handler+0x28 ipi_nmi_handler+0x44 xen_cpustophard_handler+0x9
> intr_event_handle+0x8b intr_execute_handlers+0x58 xen_intr_handle_upcall+0x15a
> xen_intr_upcall_u+0x96 ...
> So, it looks like the NMI is delivered by the same mechanism as normal
> interrupts.  If a processor has interrupts disabled then the NMI would not get
> delivered?
> 
> Is there anything we could do to improve this?

I found this in Linux code:
HYPERVISOR_vcpu_op(VCPUOP_send_nmi, xen_vcpu_nr(cpu), NULL);
It's in xen_send_IPI_one().
I wonder if that's that or if there is more to this than meets the eye.
Any help and advice is appreciated!

-- 
Andriy Gapon
___
freebsd-xen@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"

Re: Xen 4.12 - systemrescuecd-6.0.3.iso - Baremetal reboots

[R0me0 ***]

Hello Roger,

First of all thank you very much. xen-kernel 4.12.0_4 had the issue fixed,
At least I was able to boot for example a debian 10 without any issue.

I am going to deploy some machines. You r0x as always :)

One more time.  Thank you for everything.

Kind regards,



Em ter, 30 de jul de 2019 às 19:12, R0me0 *** 
escreveu:

> Hello Roger,
>
> Thank you very much, I will update it and reboot the server in a couple of
> hours.
>
>
> Thank you !
>
> Em ter, 30 de jul de 2019 às 17:25, Roger Pau Monné 
> escreveu:
>
>> On Wed, Jul 24, 2019 at 06:49:28PM +, R0me0 *** wrote:
>> > Roger, I got a machine,  I will perform a fresh install and try to
>> > reproduce the bug. If possible I will send you
>>
>> I've just committed a fix to xen-kernel yesterday which I think could
>> solve your issue. Can you update to xen-kernel 4.12.0_4?
>>
>> Note you will likely need to build this from the ports tree, since
>> it's quite likely pkg hasn't got a binary package for this yet.
>>
>> Roger.
>>
>
___
freebsd-xen@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"

Re: Xen 4.12 - systemrescuecd-6.0.3.iso - Baremetal reboots

[R0me0 ***]

Hello Roger,

Thank you very much, I will update it and reboot the server in a couple of
hours.


Thank you !

Em ter, 30 de jul de 2019 às 17:25, Roger Pau Monné 
escreveu:

> On Wed, Jul 24, 2019 at 06:49:28PM +, R0me0 *** wrote:
> > Roger, I got a machine,  I will perform a fresh install and try to
> > reproduce the bug. If possible I will send you
>
> I've just committed a fix to xen-kernel yesterday which I think could
> solve your issue. Can you update to xen-kernel 4.12.0_4?
>
> Note you will likely need to build this from the ports tree, since
> it's quite likely pkg hasn't got a binary package for this yet.
>
> Roger.
>
___
freebsd-xen@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"

Re: Xen 4.12 - systemrescuecd-6.0.3.iso - Baremetal reboots

[Roger Pau Monné]

On Wed, Jul 24, 2019 at 06:49:28PM +, R0me0 *** wrote:
> Roger, I got a machine,  I will perform a fresh install and try to
> reproduce the bug. If possible I will send you

I've just committed a fix to xen-kernel yesterday which I think could
solve your issue. Can you update to xen-kernel 4.12.0_4?

Note you will likely need to build this from the ports tree, since
it's quite likely pkg hasn't got a binary package for this yet.

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

Re: Xen 4.12 - systemrescuecd-6.0.3.iso - Baremetal reboots

[R0me0 ***]

Roger, I got a machine,  I will perform a fresh install and try to
reproduce the bug. If possible I will send you

One more time, thank you very much

Kind regards,



Em ter, 23 de jul de 2019 às 16:13, R0me0 *** 
escreveu:

> I will ask. Count on me
>
> Em ter, 23 de jul de 2019 às 16:12, Roger Pau Monné 
> escreveu:
>
>> Hello,
>>
>> Could you please try to avoid top-posting.
>>
>> On Tue, Jul 23, 2019 at 04:07:31PM +, R0me0 *** wrote:
>> > Sorry, but this host is hosted on another country which I do not have
>> > access to. ( Hetzner )
>> >
>> > So, I think I can't  help.
>>
>> Can you ask them to provide a serial console for you?
>>
>> This is quite common practice for servers, since it's the most
>> reliable way to get backtraces and debug info when something goes
>> wrong. I'm sure your hosting provider should be able to help you.
>>
>> Roger.
>>
>
___
freebsd-xen@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"

Re: Xen 4.12 - systemrescuecd-6.0.3.iso - Baremetal reboots

[R0me0 ***]

I will ask. Count on me

Em ter, 23 de jul de 2019 às 16:12, Roger Pau Monné 
escreveu:

> Hello,
>
> Could you please try to avoid top-posting.
>
> On Tue, Jul 23, 2019 at 04:07:31PM +, R0me0 *** wrote:
> > Sorry, but this host is hosted on another country which I do not have
> > access to. ( Hetzner )
> >
> > So, I think I can't  help.
>
> Can you ask them to provide a serial console for you?
>
> This is quite common practice for servers, since it's the most
> reliable way to get backtraces and debug info when something goes
> wrong. I'm sure your hosting provider should be able to help you.
>
> Roger.
>
___
freebsd-xen@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"

Re: Xen 4.12 - systemrescuecd-6.0.3.iso - Baremetal reboots

[Roger Pau Monné]

Hello,

Could you please try to avoid top-posting.

On Tue, Jul 23, 2019 at 04:07:31PM +, R0me0 *** wrote:
> Sorry, but this host is hosted on another country which I do not have
> access to. ( Hetzner )
> 
> So, I think I can't  help.

Can you ask them to provide a serial console for you?

This is quite common practice for servers, since it's the most
reliable way to get backtraces and debug info when something goes
wrong. I'm sure your hosting provider should be able to help you.

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

Re: Xen 4.12 - systemrescuecd-6.0.3.iso - Baremetal reboots

[R0me0 ***]

Sorry, but this host is hosted on another country which I do not have
access to. ( Hetzner )

So, I think I can't  help.





Em ter, 23 de jul de 2019 às 15:54, Roger Pau Monné 
escreveu:

> On Tue, Jul 23, 2019 at 03:45:49PM +, R0me0 *** wrote:
> > Yes the DOM0, the XEN hypervisor completely hangs and the host
> > automatically reboots.
>
> You will have to setup a serial console in order to debug then. You
> need to find the serial port of your box and hook a null modem [0] to it,
> and then plug the other side into another computer and use cu, minicom
> or some other program in order to get the serial output.
>
> There's a section on the handbook about how to use the serial console:
>
>
> https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/serialconsole-setup.html
>
> You will need to add something like:
>
> console=com1,vga com1=115200,8n1
>
> to your xen_cmdline if you don't have it yet in order to get the
> output.
>
> > It seems related with Linux guests using kernel 4.x
>
> Does then same happen if you use a disk line like:
>
> 'format=raw, vdev=hda, access=rw, backendtype=qdisk,
> target=/dev/zvol/fbroot/SAND/disk'
>
> Note the 'backendtype' option is set to qdisk.
>
> Roger.
>
> [0] https://en.wikipedia.org/wiki/Null_modem
>
___
freebsd-xen@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"

Re: Xen 4.12 - systemrescuecd-6.0.3.iso - Baremetal reboots

[Roger Pau Monné]

On Tue, Jul 23, 2019 at 03:45:49PM +, R0me0 *** wrote:
> Yes the DOM0, the XEN hypervisor completely hangs and the host
> automatically reboots.

You will have to setup a serial console in order to debug then. You
need to find the serial port of your box and hook a null modem [0] to it,
and then plug the other side into another computer and use cu, minicom
or some other program in order to get the serial output.

There's a section on the handbook about how to use the serial console:

https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/serialconsole-setup.html

You will need to add something like:

console=com1,vga com1=115200,8n1

to your xen_cmdline if you don't have it yet in order to get the
output.

> It seems related with Linux guests using kernel 4.x

Does then same happen if you use a disk line like:

'format=raw, vdev=hda, access=rw, backendtype=qdisk, 
target=/dev/zvol/fbroot/SAND/disk'

Note the 'backendtype' option is set to qdisk.

Roger.

[0] https://en.wikipedia.org/wiki/Null_modem
___
freebsd-xen@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"

Re: Xen 4.12 - systemrescuecd-6.0.3.iso - Baremetal reboots

[R0me0 ***]

>Can you try with:

> 'format=raw, vdev=hda, access=rw, backendtype=qdisk,
target=/dev/zvol/fbroot/SAND/disk'

I need to test on another time, because I have some services running on
this box and this bug bring me some headache on my job

Thank you for your patience and attention,

Kind regards,



Em ter, 23 de jul de 2019 às 15:45, R0me0 *** 
escreveu:

> Yes the DOM0, the XEN hypervisor completely hangs and the host
> automatically reboots.
>
> It seems related with Linux guests using kernel 4.x
>
> I'am using FreeBSD 12.0-RELEASE-p7 FreeBSD 12.0-RELEASE-p6 GENERIC  amd64
>
> # pkg info | cut -f1 -d' '
> argp-standalone-1.3_3
> bareos17-client-17.2.7_3
> ca_root_nss-3.45
> curl-7.65.2
> doas-6.0p3
> gettext-runtime-0.20.1
> glib-2.56.3_5,1
> indexinfo-0.3.1
> jansson-2.12
> libffi-3.2.1_3
> libiconv-1.14_11
> libnghttp2-1.39.1
> libxml2-2.9.9
> lzo2-2.10_1
> mtr-nox11-0.92_1
> p5-Path-Tiny-0.108
> pcre-8.43_1
> perl5-5.28.2
> pixman-0.38.4
> pkg-1.11.1
> python27-2.7.16_1
> python36-3.6.9
> qemu-utils-3.0.1_2
> readline-8.0.0
> seabios-1.11.0_2
> strongswan-5.8.0
> vim-console-8.1.1439
> xen-kernel-4.12.0_3
> xen-tools-4.12.0_2
> yajl-2.1.0
>
> Em ter, 23 de jul de 2019 às 13:13, Roger Pau Monné 
> escreveu:
>
>> On Tue, Jul 23, 2019 at 11:51:51AM +, R0me0 *** wrote:
>> > I tried to boot kali linux (
>> > https://cdimage.kali.org/kali-2019.2/kali-linux-2019.2-amd64.iso ) as
>> guest.
>> >
>> > The machine freezes on the same way I am using the latest xen 4.12 on
>> > freebsd
>>
>> I think I'm confused by this sentence. When you write the machine
>> freezes, I assume you mean that the guest freezes, but the host is
>> responsive?
>>
>> > here is the screenshot of console:
>> >
>> > [image: 2019-07-23-084718_853x193_scrot.png]
>> >
>> > and here is the xl dmesg
>> >
>> > (d12) Detected Xen v4.12.0
>> > (d12) xen: copy BIOS tables...
>> > (d12) Copying SMBIOS entry point from 0x00010020 to 0x000f5e60
>> > (d12) Copying MPTABLE from 0xfc0011e0/fc0011f0 to 0x000f5d40
>> > (d12) Copying PIR from 0x00010040 to 0x000f5cc0
>> > (d12) Copying ACPI RSDP from 0x000100c0 to 0x000f5c90
>> > (d12) Using pmtimer, ioport 0xb008
>> > (d12) Scan for VGA option rom
>> > (d12) Running option rom at c000:0003
>> > (d12) pmm call arg1=0
>> > (d12) Turning on vga text mode console
>> > (d12) SeaBIOS (version 1.11.0-20190516_220714-120amd64-default-job-06)
>> > (d12) Machine UUID 2e347e67-ad3f-11e9-9209-0cc47a4dbca8
>> > (d12) ATA controller 1 at 1f0/3f4/0 (irq 14 dev 9)
>> > (d12) ATA controller 2 at 170/374/0 (irq 15 dev 9)
>> > (d12) Found 0 lpt ports
>> > (d12) Found 1 serial ports
>> > (d12) ata0-0: QEMU HARDDISK ATA-7 Hard-Disk (80 GiBytes)
>> > (d12) Searching bootorder for: /pci@i0cf8/*@1,1/drive@0/disk@0
>> > (d12) DVD/CD [ata0-1: QEMU DVD-ROM ATAPI-4 DVD/CD]
>> > (d12) Searching bootorder for: /pci@i0cf8/*@1,1/drive@0/disk@1
>> > (d12) PS2 keyboard initialized
>> > (d12) All threads complete.
>> > (d12) Scan for option roms
>> > (d12) Running option rom at c980:0003
>> > (d12) pmm call arg1=1
>> > (d12) pmm call arg1=0
>> > (d12) pmm call arg1=1
>> > (d12) pmm call arg1=0
>> > (d12) Searching bootorder for: /pci@i0cf8/*@4
>> > (d12)
>> > (d12) Press ESC for boot menu.
>> > (d12)
>> > (d12) Searching bootorder for: HALT
>> > (d12) drive 0x000f5c20: PCHS=16383/16/63 translation=lba
>> LCHS=1024/255/63
>> > s=167772160
>> > (d12) Space available for UMB: ca800-eb000, f5680-f5bc0
>> > (d12) Returned 258048 bytes of ZoneHigh
>> > (d12) e820 map has 7 items:
>> > (d12)   0:  - 0009fc00 = 1 RAM
>> > (d12)   1: 0009fc00 - 000a = 2 RESERVED
>> > (d12)   2: 000f - 0010 = 2 RESERVED
>> > (d12)   3: 0010 - e000 = 1 RAM
>> > (d12)   4: e000 - f000 = 2 RESERVED
>> > (d12)   5: fc00 - 0001 = 2 RESERVED
>> > (d12)   6: 0001 - 00010f80 = 1 RAM
>> > (d12) enter handle_19:
>> > (d12)   NULL
>> > (d12) Booting from Hard Disk...
>> > (d12) Boot failed: not a bootable disk
>> > (d12)
>> > (d12) enter handle_18:
>> > (d12)   NULL
>> > (d12) Booting from DVD/CD...
>> > (d12) Booting from :7c00
>> >
>> >
>> >
>> > Em qui, 11 de jul de 2019 às 21:02, R0me0 *** 
>> > escreveu:
>> >
>> > > Hello Roger,
>> > >
>> > > >So you are trying to boot systemrescuecd as a guest on the Xen host?
>> > > Yes.
>> > >
>> > > Here is the config I have used:
>> > >
>> > > # cat livecd.cfg
>> > >
>> > > builder = "hvm"
>> > > name = "livecd"
>> > > memory = 2048
>> > > cpus="all,^0-1"
>> > > vcpus = 2
>> > > vif = [ 'type=vif,bridge=sandbox' ]
>> > > disk = [ '/dev/zvol/fbroot/SAND/disk,raw,xvda,w' ,
>>
>> Can you try with:
>>
>> 'format=raw, vdev=hda, access=rw, backendtype=qdisk,
>> target=/dev/zvol/fbroot/SAND/disk'
>>
>> Which version of FreeBSD are you running?
>>
>> Can you also paste the output of `dmesg` when this happens?
>>
>> Thanks, Roger.
>>
>

Re: Xen 4.12 - systemrescuecd-6.0.3.iso - Baremetal reboots

[R0me0 ***]

Yes the DOM0, the XEN hypervisor completely hangs and the host
automatically reboots.

It seems related with Linux guests using kernel 4.x

I'am using FreeBSD 12.0-RELEASE-p7 FreeBSD 12.0-RELEASE-p6 GENERIC  amd64

# pkg info | cut -f1 -d' '
argp-standalone-1.3_3
bareos17-client-17.2.7_3
ca_root_nss-3.45
curl-7.65.2
doas-6.0p3
gettext-runtime-0.20.1
glib-2.56.3_5,1
indexinfo-0.3.1
jansson-2.12
libffi-3.2.1_3
libiconv-1.14_11
libnghttp2-1.39.1
libxml2-2.9.9
lzo2-2.10_1
mtr-nox11-0.92_1
p5-Path-Tiny-0.108
pcre-8.43_1
perl5-5.28.2
pixman-0.38.4
pkg-1.11.1
python27-2.7.16_1
python36-3.6.9
qemu-utils-3.0.1_2
readline-8.0.0
seabios-1.11.0_2
strongswan-5.8.0
vim-console-8.1.1439
xen-kernel-4.12.0_3
xen-tools-4.12.0_2
yajl-2.1.0

Em ter, 23 de jul de 2019 às 13:13, Roger Pau Monné 
escreveu:

> On Tue, Jul 23, 2019 at 11:51:51AM +, R0me0 *** wrote:
> > I tried to boot kali linux (
> > https://cdimage.kali.org/kali-2019.2/kali-linux-2019.2-amd64.iso ) as
> guest.
> >
> > The machine freezes on the same way I am using the latest xen 4.12 on
> > freebsd
>
> I think I'm confused by this sentence. When you write the machine
> freezes, I assume you mean that the guest freezes, but the host is
> responsive?
>
> > here is the screenshot of console:
> >
> > [image: 2019-07-23-084718_853x193_scrot.png]
> >
> > and here is the xl dmesg
> >
> > (d12) Detected Xen v4.12.0
> > (d12) xen: copy BIOS tables...
> > (d12) Copying SMBIOS entry point from 0x00010020 to 0x000f5e60
> > (d12) Copying MPTABLE from 0xfc0011e0/fc0011f0 to 0x000f5d40
> > (d12) Copying PIR from 0x00010040 to 0x000f5cc0
> > (d12) Copying ACPI RSDP from 0x000100c0 to 0x000f5c90
> > (d12) Using pmtimer, ioport 0xb008
> > (d12) Scan for VGA option rom
> > (d12) Running option rom at c000:0003
> > (d12) pmm call arg1=0
> > (d12) Turning on vga text mode console
> > (d12) SeaBIOS (version 1.11.0-20190516_220714-120amd64-default-job-06)
> > (d12) Machine UUID 2e347e67-ad3f-11e9-9209-0cc47a4dbca8
> > (d12) ATA controller 1 at 1f0/3f4/0 (irq 14 dev 9)
> > (d12) ATA controller 2 at 170/374/0 (irq 15 dev 9)
> > (d12) Found 0 lpt ports
> > (d12) Found 1 serial ports
> > (d12) ata0-0: QEMU HARDDISK ATA-7 Hard-Disk (80 GiBytes)
> > (d12) Searching bootorder for: /pci@i0cf8/*@1,1/drive@0/disk@0
> > (d12) DVD/CD [ata0-1: QEMU DVD-ROM ATAPI-4 DVD/CD]
> > (d12) Searching bootorder for: /pci@i0cf8/*@1,1/drive@0/disk@1
> > (d12) PS2 keyboard initialized
> > (d12) All threads complete.
> > (d12) Scan for option roms
> > (d12) Running option rom at c980:0003
> > (d12) pmm call arg1=1
> > (d12) pmm call arg1=0
> > (d12) pmm call arg1=1
> > (d12) pmm call arg1=0
> > (d12) Searching bootorder for: /pci@i0cf8/*@4
> > (d12)
> > (d12) Press ESC for boot menu.
> > (d12)
> > (d12) Searching bootorder for: HALT
> > (d12) drive 0x000f5c20: PCHS=16383/16/63 translation=lba LCHS=1024/255/63
> > s=167772160
> > (d12) Space available for UMB: ca800-eb000, f5680-f5bc0
> > (d12) Returned 258048 bytes of ZoneHigh
> > (d12) e820 map has 7 items:
> > (d12)   0:  - 0009fc00 = 1 RAM
> > (d12)   1: 0009fc00 - 000a = 2 RESERVED
> > (d12)   2: 000f - 0010 = 2 RESERVED
> > (d12)   3: 0010 - e000 = 1 RAM
> > (d12)   4: e000 - f000 = 2 RESERVED
> > (d12)   5: fc00 - 0001 = 2 RESERVED
> > (d12)   6: 0001 - 00010f80 = 1 RAM
> > (d12) enter handle_19:
> > (d12)   NULL
> > (d12) Booting from Hard Disk...
> > (d12) Boot failed: not a bootable disk
> > (d12)
> > (d12) enter handle_18:
> > (d12)   NULL
> > (d12) Booting from DVD/CD...
> > (d12) Booting from :7c00
> >
> >
> >
> > Em qui, 11 de jul de 2019 às 21:02, R0me0 *** 
> > escreveu:
> >
> > > Hello Roger,
> > >
> > > >So you are trying to boot systemrescuecd as a guest on the Xen host?
> > > Yes.
> > >
> > > Here is the config I have used:
> > >
> > > # cat livecd.cfg
> > >
> > > builder = "hvm"
> > > name = "livecd"
> > > memory = 2048
> > > cpus="all,^0-1"
> > > vcpus = 2
> > > vif = [ 'type=vif,bridge=sandbox' ]
> > > disk = [ '/dev/zvol/fbroot/SAND/disk,raw,xvda,w' ,
>
> Can you try with:
>
> 'format=raw, vdev=hda, access=rw, backendtype=qdisk,
> target=/dev/zvol/fbroot/SAND/disk'
>
> Which version of FreeBSD are you running?
>
> Can you also paste the output of `dmesg` when this happens?
>
> Thanks, Roger.
>
___
freebsd-xen@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"

Re: Xen 4.12 - systemrescuecd-6.0.3.iso - Baremetal reboots

[R0me0 ***]

Yes DOM0, the XEN hypervisor completely hangs and the host automatically
reboots.

It seems related with Linux guests using kernel 4.x

I'am using FreeBSD 12.0-RELEASE-p7 FreeBSD 12.0-RELEASE-p6 GENERIC  amd64

# pkg info
argp-standalone-1.3_3  Standalone version of arguments parsing
functions from GLIBC
bareos17-client-17.2.7_3   Backup archiving recovery open sourced
(client)
ca_root_nss-3.45   Root certificate bundle from the Mozilla
Project
curl-7.65.2Command line tool and library for
transferring data with URLs
doas-6.0p3 Simple sudo alternative to run commands as
another user
gettext-runtime-0.20.1 GNU gettext runtime libraries and programs
glib-2.56.3_5,1Some useful routines of C programming
(current stable version)
indexinfo-0.3.1Utility to regenerate the GNU info page index
jansson-2.12   C library for encoding, decoding, and
manipulating JSON data
libffi-3.2.1_3 Foreign Function Interface
libiconv-1.14_11   Character set conversion library
libnghttp2-1.39.1  HTTP/2.0 C Library
libxml2-2.9.9  XML parser library for GNOME
lzo2-2.10_1Portable speedy, lossless data compression
library
mtr-nox11-0.92_1   Traceroute and ping in a single network
diagnostic tool
p5-Path-Tiny-0.108 File path utility
pcre-8.43_1Perl Compatible Regular Expressions library
perl5-5.28.2   Practical Extraction and Report Language
pixman-0.38.4  Low-level pixel manipulation library
pkg-1.11.1 Package manager
python27-2.7.16_1  Interpreted object-oriented programming
language
python36-3.6.9 Interpreted object-oriented programming
language
qemu-utils-3.0.1_2 QEMU userland utilities
readline-8.0.0 Library for editing command lines as they
are typed
seabios-1.11.0_2   Open source implementation of a 16bit X86
BIOS
strongswan-5.8.0   Open Source IKEv2 IPsec-based VPN solution
vim-console-8.1.1439   Improved version of the vi editor (console
only)
xen-kernel-4.12.0_3Hypervisor using a microkernel design
xen-tools-4.12.0_2 Xen management tools
yajl-2.1.0 Portable JSON parsing and serialization
library in ANSI C




Em ter, 23 de jul de 2019 às 13:13, Roger Pau Monné 
escreveu:

> On Tue, Jul 23, 2019 at 11:51:51AM +, R0me0 *** wrote:
> > I tried to boot kali linux (
> > https://cdimage.kali.org/kali-2019.2/kali-linux-2019.2-amd64.iso ) as
> guest.
> >
> > The machine freezes on the same way I am using the latest xen 4.12 on
> > freebsd
>
> I think I'm confused by this sentence. When you write the machine
> freezes, I assume you mean that the guest freezes, but the host is
> responsive?
>
> > here is the screenshot of console:
> >
> > [image: 2019-07-23-084718_853x193_scrot.png]
> >
> > and here is the xl dmesg
> >
> > (d12) Detected Xen v4.12.0
> > (d12) xen: copy BIOS tables...
> > (d12) Copying SMBIOS entry point from 0x00010020 to 0x000f5e60
> > (d12) Copying MPTABLE from 0xfc0011e0/fc0011f0 to 0x000f5d40
> > (d12) Copying PIR from 0x00010040 to 0x000f5cc0
> > (d12) Copying ACPI RSDP from 0x000100c0 to 0x000f5c90
> > (d12) Using pmtimer, ioport 0xb008
> > (d12) Scan for VGA option rom
> > (d12) Running option rom at c000:0003
> > (d12) pmm call arg1=0
> > (d12) Turning on vga text mode console
> > (d12) SeaBIOS (version 1.11.0-20190516_220714-120amd64-default-job-06)
> > (d12) Machine UUID 2e347e67-ad3f-11e9-9209-0cc47a4dbca8
> > (d12) ATA controller 1 at 1f0/3f4/0 (irq 14 dev 9)
> > (d12) ATA controller 2 at 170/374/0 (irq 15 dev 9)
> > (d12) Found 0 lpt ports
> > (d12) Found 1 serial ports
> > (d12) ata0-0: QEMU HARDDISK ATA-7 Hard-Disk (80 GiBytes)
> > (d12) Searching bootorder for: /pci@i0cf8/*@1,1/drive@0/disk@0
> > (d12) DVD/CD [ata0-1: QEMU DVD-ROM ATAPI-4 DVD/CD]
> > (d12) Searching bootorder for: /pci@i0cf8/*@1,1/drive@0/disk@1
> > (d12) PS2 keyboard initialized
> > (d12) All threads complete.
> > (d12) Scan for option roms
> > (d12) Running option rom at c980:0003
> > (d12) pmm call arg1=1
> > (d12) pmm call arg1=0
> > (d12) pmm call arg1=1
> > (d12) pmm call arg1=0
> > (d12) Searching bootorder for: /pci@i0cf8/*@4
> > (d12)
> > (d12) Press ESC for boot menu.
> > (d12)
> > (d12) Searching bootorder for: HALT
> > (d12) drive 0x000f5c20: PCHS=16383/16/63 translation=lba LCHS=1024/255/63
> > s=167772160
> > (d12) Space available for UMB: ca800-eb000, f5680-f5bc0
> > (d12) Returned 258048 bytes of ZoneHigh
> > (d12) e820 map has 7 items:
> > (d12)   0:  - 0009fc00 = 1 RAM
> > (d12)   1: 0009fc00 - 000a = 2 RESERVED
> > (d12)   2: 000f - 0010 = 2 RESERVED
> > (d12)   3: 0010 - e000 = 1 RAM
> > (d12)   4: 

Re: Xen 4.12 - systemrescuecd-6.0.3.iso - Baremetal reboots

[Roger Pau Monné]

On Tue, Jul 23, 2019 at 11:51:51AM +, R0me0 *** wrote:
> I tried to boot kali linux (
> https://cdimage.kali.org/kali-2019.2/kali-linux-2019.2-amd64.iso ) as guest.
> 
> The machine freezes on the same way I am using the latest xen 4.12 on
> freebsd

I think I'm confused by this sentence. When you write the machine
freezes, I assume you mean that the guest freezes, but the host is
responsive?

> here is the screenshot of console:
> 
> [image: 2019-07-23-084718_853x193_scrot.png]
> 
> and here is the xl dmesg
> 
> (d12) Detected Xen v4.12.0
> (d12) xen: copy BIOS tables...
> (d12) Copying SMBIOS entry point from 0x00010020 to 0x000f5e60
> (d12) Copying MPTABLE from 0xfc0011e0/fc0011f0 to 0x000f5d40
> (d12) Copying PIR from 0x00010040 to 0x000f5cc0
> (d12) Copying ACPI RSDP from 0x000100c0 to 0x000f5c90
> (d12) Using pmtimer, ioport 0xb008
> (d12) Scan for VGA option rom
> (d12) Running option rom at c000:0003
> (d12) pmm call arg1=0
> (d12) Turning on vga text mode console
> (d12) SeaBIOS (version 1.11.0-20190516_220714-120amd64-default-job-06)
> (d12) Machine UUID 2e347e67-ad3f-11e9-9209-0cc47a4dbca8
> (d12) ATA controller 1 at 1f0/3f4/0 (irq 14 dev 9)
> (d12) ATA controller 2 at 170/374/0 (irq 15 dev 9)
> (d12) Found 0 lpt ports
> (d12) Found 1 serial ports
> (d12) ata0-0: QEMU HARDDISK ATA-7 Hard-Disk (80 GiBytes)
> (d12) Searching bootorder for: /pci@i0cf8/*@1,1/drive@0/disk@0
> (d12) DVD/CD [ata0-1: QEMU DVD-ROM ATAPI-4 DVD/CD]
> (d12) Searching bootorder for: /pci@i0cf8/*@1,1/drive@0/disk@1
> (d12) PS2 keyboard initialized
> (d12) All threads complete.
> (d12) Scan for option roms
> (d12) Running option rom at c980:0003
> (d12) pmm call arg1=1
> (d12) pmm call arg1=0
> (d12) pmm call arg1=1
> (d12) pmm call arg1=0
> (d12) Searching bootorder for: /pci@i0cf8/*@4
> (d12)
> (d12) Press ESC for boot menu.
> (d12)
> (d12) Searching bootorder for: HALT
> (d12) drive 0x000f5c20: PCHS=16383/16/63 translation=lba LCHS=1024/255/63
> s=167772160
> (d12) Space available for UMB: ca800-eb000, f5680-f5bc0
> (d12) Returned 258048 bytes of ZoneHigh
> (d12) e820 map has 7 items:
> (d12)   0:  - 0009fc00 = 1 RAM
> (d12)   1: 0009fc00 - 000a = 2 RESERVED
> (d12)   2: 000f - 0010 = 2 RESERVED
> (d12)   3: 0010 - e000 = 1 RAM
> (d12)   4: e000 - f000 = 2 RESERVED
> (d12)   5: fc00 - 0001 = 2 RESERVED
> (d12)   6: 0001 - 00010f80 = 1 RAM
> (d12) enter handle_19:
> (d12)   NULL
> (d12) Booting from Hard Disk...
> (d12) Boot failed: not a bootable disk
> (d12)
> (d12) enter handle_18:
> (d12)   NULL
> (d12) Booting from DVD/CD...
> (d12) Booting from :7c00
> 
> 
> 
> Em qui, 11 de jul de 2019 às 21:02, R0me0 *** 
> escreveu:
> 
> > Hello Roger,
> >
> > >So you are trying to boot systemrescuecd as a guest on the Xen host?
> > Yes.
> >
> > Here is the config I have used:
> >
> > # cat livecd.cfg
> >
> > builder = "hvm"
> > name = "livecd"
> > memory = 2048
> > cpus="all,^0-1"
> > vcpus = 2
> > vif = [ 'type=vif,bridge=sandbox' ]
> > disk = [ '/dev/zvol/fbroot/SAND/disk,raw,xvda,w' ,

Can you try with:

'format=raw, vdev=hda, access=rw, backendtype=qdisk, 
target=/dev/zvol/fbroot/SAND/disk'

Which version of FreeBSD are you running?

Can you also paste the output of `dmesg` when this happens?

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

Re: Xen 4.12 - systemrescuecd-6.0.3.iso - Baremetal reboots

[R0me0 ***]

Just boot Debian 10 e Machine freezes completely.

Seems to be related to Linux Kernel 4.X

Em ter, 23 de jul de 2019 às 11:51, R0me0 *** 
escreveu:

> I tried to boot kali linux (
> https://cdimage.kali.org/kali-2019.2/kali-linux-2019.2-amd64.iso ) as
> guest.
>
> The machine freezes on the same way I am using the latest xen 4.12 on
> freebsd
>
> here is the screenshot of console:
>
> [image: 2019-07-23-084718_853x193_scrot.png]
>
> and here is the xl dmesg
>
> (d12) Detected Xen v4.12.0
> (d12) xen: copy BIOS tables...
> (d12) Copying SMBIOS entry point from 0x00010020 to 0x000f5e60
> (d12) Copying MPTABLE from 0xfc0011e0/fc0011f0 to 0x000f5d40
> (d12) Copying PIR from 0x00010040 to 0x000f5cc0
> (d12) Copying ACPI RSDP from 0x000100c0 to 0x000f5c90
> (d12) Using pmtimer, ioport 0xb008
> (d12) Scan for VGA option rom
> (d12) Running option rom at c000:0003
> (d12) pmm call arg1=0
> (d12) Turning on vga text mode console
> (d12) SeaBIOS (version 1.11.0-20190516_220714-120amd64-default-job-06)
> (d12) Machine UUID 2e347e67-ad3f-11e9-9209-0cc47a4dbca8
> (d12) ATA controller 1 at 1f0/3f4/0 (irq 14 dev 9)
> (d12) ATA controller 2 at 170/374/0 (irq 15 dev 9)
> (d12) Found 0 lpt ports
> (d12) Found 1 serial ports
> (d12) ata0-0: QEMU HARDDISK ATA-7 Hard-Disk (80 GiBytes)
> (d12) Searching bootorder for: /pci@i0cf8/*@1,1/drive@0/disk@0
> (d12) DVD/CD [ata0-1: QEMU DVD-ROM ATAPI-4 DVD/CD]
> (d12) Searching bootorder for: /pci@i0cf8/*@1,1/drive@0/disk@1
> (d12) PS2 keyboard initialized
> (d12) All threads complete.
> (d12) Scan for option roms
> (d12) Running option rom at c980:0003
> (d12) pmm call arg1=1
> (d12) pmm call arg1=0
> (d12) pmm call arg1=1
> (d12) pmm call arg1=0
> (d12) Searching bootorder for: /pci@i0cf8/*@4
> (d12)
> (d12) Press ESC for boot menu.
> (d12)
> (d12) Searching bootorder for: HALT
> (d12) drive 0x000f5c20: PCHS=16383/16/63 translation=lba LCHS=1024/255/63
> s=167772160
> (d12) Space available for UMB: ca800-eb000, f5680-f5bc0
> (d12) Returned 258048 bytes of ZoneHigh
> (d12) e820 map has 7 items:
> (d12)   0:  - 0009fc00 = 1 RAM
> (d12)   1: 0009fc00 - 000a = 2 RESERVED
> (d12)   2: 000f - 0010 = 2 RESERVED
> (d12)   3: 0010 - e000 = 1 RAM
> (d12)   4: e000 - f000 = 2 RESERVED
> (d12)   5: fc00 - 0001 = 2 RESERVED
> (d12)   6: 0001 - 00010f80 = 1 RAM
> (d12) enter handle_19:
> (d12)   NULL
> (d12) Booting from Hard Disk...
> (d12) Boot failed: not a bootable disk
> (d12)
> (d12) enter handle_18:
> (d12)   NULL
> (d12) Booting from DVD/CD...
> (d12) Booting from :7c00
>
>
>
> Em qui, 11 de jul de 2019 às 21:02, R0me0 *** 
> escreveu:
>
>> Hello Roger,
>>
>> >So you are trying to boot systemrescuecd as a guest on the Xen host?
>> Yes.
>>
>> Here is the config I have used:
>>
>> # cat livecd.cfg
>>
>> builder = "hvm"
>> name = "livecd"
>> memory = 2048
>> cpus="all,^0-1"
>> vcpus = 2
>> vif = [ 'type=vif,bridge=sandbox' ]
>> disk = [ '/dev/zvol/fbroot/SAND/disk,raw,xvda,w' ,
>> '/home/iso/systemrescuecd-6.0.3.iso,raw,xvdb:cdrom,r' ]
>> boot = 'd'
>> vnc = 1
>> vnclisten = '127.0.0.1'
>> serial = 'pty'
>>
>> Regarding this:
>>
>> > Could you get a serial hooked up to that box so we can get the trace?
>>
>> Could you help me to provide the information you asked.
>>
>> Thank you .
>>
>> Kind regards,
>>
>>
>>
>>
>> Em qui, 4 de jul de 2019 às 07:26, Roger Pau Monné 
>> escreveu:
>>
>>> On Fri, Jun 28, 2019 at 12:02:37PM +, R0me0 *** wrote:
>>> > Guys,
>>> >
>>> > I'am using FreeBSD 12.0-RELEASE-p6 FreeBSD 12.0-RELEASE-p6 GENERIC
>>> amd64
>>>
>>> I guess this is on the host?
>>>
>>> > When booting systemrescuecd-6.0.3.iso (
>>> http://www.system-rescue-cd.org )
>>> > ,  my system just hangs and reboot.
>>>
>>> So you are trying to boot systemrescuecd as a guest on the Xen host?
>>>
>>> Can you paste your guest config file?
>>>
>>> > Just tried an older version and it's ok.
>>> >
>>> > I don't have any log to help. If you guys want and some help, I can
>>> provide
>>> > more information.
>>>
>>> Could you get a serial hooked up to that box so we can get the trace?
>>>
>>> Without some kind of trace it's going to be hard to debug this.
>>>
>>> Thanks, Roger.
>>>
>>
___
freebsd-xen@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"

Re: Xen 4.12 - systemrescuecd-6.0.3.iso - Baremetal reboots

[R0me0 ***]

I tried to boot kali linux (
https://cdimage.kali.org/kali-2019.2/kali-linux-2019.2-amd64.iso ) as guest.

The machine freezes on the same way I am using the latest xen 4.12 on
freebsd

here is the screenshot of console:

[image: 2019-07-23-084718_853x193_scrot.png]

and here is the xl dmesg

(d12) Detected Xen v4.12.0
(d12) xen: copy BIOS tables...
(d12) Copying SMBIOS entry point from 0x00010020 to 0x000f5e60
(d12) Copying MPTABLE from 0xfc0011e0/fc0011f0 to 0x000f5d40
(d12) Copying PIR from 0x00010040 to 0x000f5cc0
(d12) Copying ACPI RSDP from 0x000100c0 to 0x000f5c90
(d12) Using pmtimer, ioport 0xb008
(d12) Scan for VGA option rom
(d12) Running option rom at c000:0003
(d12) pmm call arg1=0
(d12) Turning on vga text mode console
(d12) SeaBIOS (version 1.11.0-20190516_220714-120amd64-default-job-06)
(d12) Machine UUID 2e347e67-ad3f-11e9-9209-0cc47a4dbca8
(d12) ATA controller 1 at 1f0/3f4/0 (irq 14 dev 9)
(d12) ATA controller 2 at 170/374/0 (irq 15 dev 9)
(d12) Found 0 lpt ports
(d12) Found 1 serial ports
(d12) ata0-0: QEMU HARDDISK ATA-7 Hard-Disk (80 GiBytes)
(d12) Searching bootorder for: /pci@i0cf8/*@1,1/drive@0/disk@0
(d12) DVD/CD [ata0-1: QEMU DVD-ROM ATAPI-4 DVD/CD]
(d12) Searching bootorder for: /pci@i0cf8/*@1,1/drive@0/disk@1
(d12) PS2 keyboard initialized
(d12) All threads complete.
(d12) Scan for option roms
(d12) Running option rom at c980:0003
(d12) pmm call arg1=1
(d12) pmm call arg1=0
(d12) pmm call arg1=1
(d12) pmm call arg1=0
(d12) Searching bootorder for: /pci@i0cf8/*@4
(d12)
(d12) Press ESC for boot menu.
(d12)
(d12) Searching bootorder for: HALT
(d12) drive 0x000f5c20: PCHS=16383/16/63 translation=lba LCHS=1024/255/63
s=167772160
(d12) Space available for UMB: ca800-eb000, f5680-f5bc0
(d12) Returned 258048 bytes of ZoneHigh
(d12) e820 map has 7 items:
(d12)   0:  - 0009fc00 = 1 RAM
(d12)   1: 0009fc00 - 000a = 2 RESERVED
(d12)   2: 000f - 0010 = 2 RESERVED
(d12)   3: 0010 - e000 = 1 RAM
(d12)   4: e000 - f000 = 2 RESERVED
(d12)   5: fc00 - 0001 = 2 RESERVED
(d12)   6: 0001 - 00010f80 = 1 RAM
(d12) enter handle_19:
(d12)   NULL
(d12) Booting from Hard Disk...
(d12) Boot failed: not a bootable disk
(d12)
(d12) enter handle_18:
(d12)   NULL
(d12) Booting from DVD/CD...
(d12) Booting from :7c00



Em qui, 11 de jul de 2019 às 21:02, R0me0 *** 
escreveu:

> Hello Roger,
>
> >So you are trying to boot systemrescuecd as a guest on the Xen host?
> Yes.
>
> Here is the config I have used:
>
> # cat livecd.cfg
>
> builder = "hvm"
> name = "livecd"
> memory = 2048
> cpus="all,^0-1"
> vcpus = 2
> vif = [ 'type=vif,bridge=sandbox' ]
> disk = [ '/dev/zvol/fbroot/SAND/disk,raw,xvda,w' ,
> '/home/iso/systemrescuecd-6.0.3.iso,raw,xvdb:cdrom,r' ]
> boot = 'd'
> vnc = 1
> vnclisten = '127.0.0.1'
> serial = 'pty'
>
> Regarding this:
>
> > Could you get a serial hooked up to that box so we can get the trace?
>
> Could you help me to provide the information you asked.
>
> Thank you .
>
> Kind regards,
>
>
>
>
> Em qui, 4 de jul de 2019 às 07:26, Roger Pau Monné 
> escreveu:
>
>> On Fri, Jun 28, 2019 at 12:02:37PM +, R0me0 *** wrote:
>> > Guys,
>> >
>> > I'am using FreeBSD 12.0-RELEASE-p6 FreeBSD 12.0-RELEASE-p6 GENERIC
>> amd64
>>
>> I guess this is on the host?
>>
>> > When booting systemrescuecd-6.0.3.iso ( http://www.system-rescue-cd.org
>> )
>> > ,  my system just hangs and reboot.
>>
>> So you are trying to boot systemrescuecd as a guest on the Xen host?
>>
>> Can you paste your guest config file?
>>
>> > Just tried an older version and it's ok.
>> >
>> > I don't have any log to help. If you guys want and some help, I can
>> provide
>> > more information.
>>
>> Could you get a serial hooked up to that box so we can get the trace?
>>
>> Without some kind of trace it's going to be hard to debug this.
>>
>> Thanks, Roger.
>>
>
___
freebsd-xen@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"

Re: Xen 4.12 - systemrescuecd-6.0.3.iso - Baremetal reboots

[R0me0 ***]

Hello Roger,

>So you are trying to boot systemrescuecd as a guest on the Xen host?
Yes.

Here is the config I have used:

# cat livecd.cfg

builder = "hvm"
name = "livecd"
memory = 2048
cpus="all,^0-1"
vcpus = 2
vif = [ 'type=vif,bridge=sandbox' ]
disk = [ '/dev/zvol/fbroot/SAND/disk,raw,xvda,w' ,
'/home/iso/systemrescuecd-6.0.3.iso,raw,xvdb:cdrom,r' ]
boot = 'd'
vnc = 1
vnclisten = '127.0.0.1'
serial = 'pty'

Regarding this:

> Could you get a serial hooked up to that box so we can get the trace?

Could you help me to provide the information you asked.

Thank you .

Kind regards,




Em qui, 4 de jul de 2019 às 07:26, Roger Pau Monné 
escreveu:

> On Fri, Jun 28, 2019 at 12:02:37PM +, R0me0 *** wrote:
> > Guys,
> >
> > I'am using FreeBSD 12.0-RELEASE-p6 FreeBSD 12.0-RELEASE-p6 GENERIC  amd64
>
> I guess this is on the host?
>
> > When booting systemrescuecd-6.0.3.iso ( http://www.system-rescue-cd.org
> )
> > ,  my system just hangs and reboot.
>
> So you are trying to boot systemrescuecd as a guest on the Xen host?
>
> Can you paste your guest config file?
>
> > Just tried an older version and it's ok.
> >
> > I don't have any log to help. If you guys want and some help, I can
> provide
> > more information.
>
> Could you get a serial hooked up to that box so we can get the trace?
>
> Without some kind of trace it's going to be hard to debug this.
>
> Thanks, Roger.
>
___
freebsd-xen@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"

Re: Xen 4.12 - systemrescuecd-6.0.3.iso - Baremetal reboots

[Roger Pau Monné]

On Fri, Jun 28, 2019 at 12:02:37PM +, R0me0 *** wrote:
> Guys,
> 
> I'am using FreeBSD 12.0-RELEASE-p6 FreeBSD 12.0-RELEASE-p6 GENERIC  amd64

I guess this is on the host?

> When booting systemrescuecd-6.0.3.iso ( http://www.system-rescue-cd.org )
> ,  my system just hangs and reboot.

So you are trying to boot systemrescuecd as a guest on the Xen host?

Can you paste your guest config file?

> Just tried an older version and it's ok.
> 
> I don't have any log to help. If you guys want and some help, I can provide
> more information.

Could you get a serial hooked up to that box so we can get the trace?

Without some kind of trace it's going to be hard to debug this.

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

Re: xen+vimage kernel panic

[Nathan Friess]

On 2018-08-20 03:49 AM, Roger Pau Monné wrote:

Are there any thoughts on why the xn interface would cause a panic
there?


The xn driver calls arp_ifinit() without setting the vnet context
first.  Perhaps the attached patch could help (not even compile
tested...)


I know nothing about VNET, so is this initialization required now that
VNET is enabled? Is this an existing bug in netfront that was harmless
before VNET was activated?

Can you please file a bug report and attach the patch?


Hi Roger and everyone,

My apologies for not opening the bug report earlier this week.  I tested 
the patch this weekend and it indeed does fix the panic in my domUs.


Cheers,

Nathan
___
freebsd-xen@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"

Re: xen+vimage kernel panic

[Roger Pau Monné]

On Sun, Aug 19, 2018 at 10:48:52PM +0200, Marko Zec wrote:
> On Sun, 19 Aug 2018 12:50:55 -0600
> Nathan Friess  wrote:
> 
> > Hi,
> > 
> > While testing out the new PVH support in a domU (which is running 
> > great!), I discovered a kernel panic related to xen and vimage
> > support when trying to add an xn interface into a bridge.
> > 
> > I'm running r337024 from svn.  Removing vimage (which seems to be
> > turned on in 12-CURRENT now) allows using the bridge with no panics.
> > As part of attempting to debug this I enabled vimage in my 11.2 domU
> > and that also panics in the same code.
> > 
> > I'm not sure if the problem is a xen issue or a vimage issue so I 
> > haven't submitted a PR yet.  The kernel output is listed below.
> > 
> > It looks like netfront_backend_changed() calls
> > netfront_send_fake_arp(), which calls arp_ifinit() on the interface.
> > The first line of the call stack with arprequest+0x454 corresponds to
> > a call to ARPSTAT_INC(txrequests) at the end of arprequest, which
> > expands to VNET_PCPUSTAT_ADD().  I tried to debug further and I got a
> > little lost, but that's where I figured out that vimage is involved
> > somehow.
> > 
> > Are there any thoughts on why the xn interface would cause a panic
> > there?
> 
> The xn driver calls arp_ifinit() without setting the vnet context
> first.  Perhaps the attached patch could help (not even compile
> tested...)

I know nothing about VNET, so is this initialization required now that
VNET is enabled? Is this an existing bug in netfront that was harmless
before VNET was activated?

Can you please file a bug report and attach the patch?

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

Re: xen+vimage kernel panic

[Marko Zec]

On Sun, 19 Aug 2018 12:50:55 -0600
Nathan Friess  wrote:

> Hi,
> 
> While testing out the new PVH support in a domU (which is running 
> great!), I discovered a kernel panic related to xen and vimage
> support when trying to add an xn interface into a bridge.
> 
> I'm running r337024 from svn.  Removing vimage (which seems to be
> turned on in 12-CURRENT now) allows using the bridge with no panics.
> As part of attempting to debug this I enabled vimage in my 11.2 domU
> and that also panics in the same code.
> 
> I'm not sure if the problem is a xen issue or a vimage issue so I 
> haven't submitted a PR yet.  The kernel output is listed below.
> 
> It looks like netfront_backend_changed() calls
> netfront_send_fake_arp(), which calls arp_ifinit() on the interface.
> The first line of the call stack with arprequest+0x454 corresponds to
> a call to ARPSTAT_INC(txrequests) at the end of arprequest, which
> expands to VNET_PCPUSTAT_ADD().  I tried to debug further and I got a
> little lost, but that's where I figured out that vimage is involved
> somehow.
> 
> Are there any thoughts on why the xn interface would cause a panic
> there?

The xn driver calls arp_ifinit() without setting the vnet context
first.  Perhaps the attached patch could help (not even compile
tested...)

Marko


> 
> Thanks,
> 
> Nathan
> 
> 
> 
> 
> ===
> 
> Steps to reproduce:
> 
> # ifconfig bridge create
> bridge0
> # ifconfig bridge0 addm xn0
> (panic...)
> 
> 
> ==
> 
> Kernel output:
> 
> xn0: performing interface reset due to feature change
> (... lock reversal)
> xn0: backend features: feature-sg feature-gso-tcp4
> 
> 
> Fatal trap 12: page fault while in kernel mode
> cpuid = 1; apic id = 02
> fault virtual address = 0x28
> fault code= supervisor read data, page not present
> instruction pointer   = 0x20:0x80d15db4
> stack pointer = 0x0:0xfe483840
> frame pointer = 0x0:0xfe483940
> code segment  = base 0x0, limit 0xf, type 0x1b
>   = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags  = interrupt enabled, resume, IOPL = 0
> current process   = 14 (xenwatch)
> [ thread pid 14 tid 100033 ]
> Stopped at  arprequest+0x454:   movqll+0x7(%rax),%rax
> 
> db> bt  
> Tracing pid 14 tid 100033 td 0xf800032f5000
> arprequest() at arprequest+0x454/frame 0xfe483940
> arp_ifinit() at arp_ifinit+0x58/frame 0xfe483980
> netfront_backend_changed() at netfront_backend_changed+0x144/frame 
> 0xfe483a40
> xenwatch_thread() at xenwatch_thread+0x182/frame 0xfe483a70
> fork_exit() at fork_exit+0x84/frame 0xfe483ab0
> fork_trampoline() at fork_trampoline+0xe/frame 0xfe483ab0
> 
> ==
> 
> ___
> freebsd-xen@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-xen
> To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"

Index: sys/dev/xen/netfront/netfront.c
===
--- sys/dev/xen/netfront/netfront.c	(revision 335557)
+++ sys/dev/xen/netfront/netfront.c	(working copy)
@@ -942,11 +942,13 @@
 	struct ifaddr *ifa;
 
 	ifp = info->xn_ifp;
+	CURVNET_SET(ifp->if_vnet);
 	TAILQ_FOREACH(ifa, >if_addrhead, ifa_link) {
 		if (ifa->ifa_addr->sa_family == AF_INET) {
 			arp_ifinit(ifp, ifa);
 		}
 	}
+	CURVNET_RESTORE();
 }
 #endif
 
___
freebsd-xen@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"

Re: Xen kernel fails to boot, d0v1 triple fault looks like the cuplrit

[Roger Pau Monné]

On Wed, May 23, 2018 at 08:27:29PM +0530, Pratyush Yadav wrote:
> Hi,
> 
> On Wed, May 23, 2018 at 1:45 PM, Roger Pau Monné  wrote:
> > It's too early for the logs to be stored anywhere. The point where you
> > get the crash is when the APs are started, which is way before FreeBSD
> > starts proving for disk devices.
> >
> > Can you please try the patch below?
> >
> > Thanks, Roger.
> > ---8<---
> > diff --git a/sys/x86/xen/pv.c b/sys/x86/xen/pv.c
> > index 54184898e9bf..52391e2e7c08 100644
> > --- a/sys/x86/xen/pv.c
> > +++ b/sys/x86/xen/pv.c
> > @@ -113,6 +113,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
> >
> >  /*
> > @@ -329,6 +330,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);
> >
> 
> I think we have different pv.c files. For me, line 113 is:
> /* Xen init_ops implementation. */
> 
> The declarations of doublefault_stach, mce_stack, etc are in line 101.
> 
> Similarly, line 329 for me is:
> {
> 
> in function xen_pv_parse_symtab(void). The declarations your diff
> mentions in line 329 are in line 224.
> 
> This is in sync with the official repository [0]. Maybe you have
> modifications that are not yet upstream?

Sorry, I did indeed have other changes in pv.c. I'm appending the
patch on top of current HEAD.

> Anyway, I manually made the changes. It still does not boot (I used
> make kernel -DKERNFAST, but I don't think that should make a
> difference).

FWIW, I think the recommended way is KERNFAST=1.

Can you paste the error? I think you should no longer get a triple
page fault in mp_machdep.c:307.

Thanks, Roger.
---8<---
diff --git a/sys/x86/xen/pv.c b/sys/x86/xen/pv.c
index c7e97c5b2b63..27e98012302b 100644
--- a/sys/x86/xen/pv.c
+++ b/sys/x86/xen/pv.c
@@ -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);
 

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

Re: Xen kernel fails to boot, d0v1 triple fault looks like the cuplrit

[Roger Pau Monné]

On Wed, May 23, 2018 at 12:57:59PM +0530, Pratyush Yadav wrote:
> On Mon, May 21, 2018 at 2:33 PM, Roger Pau Monné 
> wrote:
> > Please try to avoid top posting.
> 
> Sorry, I didn't know. I Googled top posting just now, and realized it is
> inconvenient for the reader.
> 
> > Hm, it seems like dbg_stack is not properly allocated. Can you please
> > try the above debug patch and paste the boot log?
> >
> > ---8<---
> > diff --git a/sys/amd64/amd64/mp_machdep.c b/sys/amd64/amd64/mp_machdep.c
> > index 301461420874..8854242b4bf5 100644
> > --- a/sys/amd64/amd64/mp_machdep.c
> > +++ b/sys/amd64/amd64/mp_machdep.c
> > @@ -304,6 +304,7 @@ init_secondary(void)
> >
> > /* Save the per-cpu pointer for use by the DB# handler. */
> > np = ((struct nmi_pcpu *) _stack[PAGE_SIZE]) - 1;
> > +printf("ID %d dbg_stack: %p per-cpu: %p\n", cpu, dbg_stack, np);
> > np->np_pcpu = (register_t) pc;
> >
> > wrmsr(MSR_FSBASE, 0);   /* User value */
> > @@ -403,6 +404,7 @@ native_start_all_aps(void)
> > M_WAITOK | M_ZERO);
> > dbg_stack = (char *)kmem_malloc(kernel_arena, PAGE_SIZE,
> > M_WAITOK | M_ZERO);
> > +printf("allocated dbg_stack: %p\n", dbg_stack);
> > dpcpu = (void *)kmem_malloc(kernel_arena, DPCPU_SIZE,
> > M_WAITOK | M_ZERO);
> >
> 
> I applied your patch. The boot stops at the same spot. Also, I can't see
> any of the two print messages added in the patch. I booted from a Live CD
> to look at the logs, but they are not stored. I checked dmesg.boot and
> messages, and /var/log/xen/ none of them have the logs. They all have logs
> of the previous boot.

It's too early for the logs to be stored anywhere. The point where you
get the crash is when the APs are started, which is way before FreeBSD
starts proving for disk devices.

Can you please try the patch below?

Thanks, Roger.
---8<---
diff --git a/sys/x86/xen/pv.c b/sys/x86/xen/pv.c
index 54184898e9bf..52391e2e7c08 100644
--- a/sys/x86/xen/pv.c
+++ b/sys/x86/xen/pv.c
@@ -113,6 +113,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
 
 /*
@@ -329,6 +330,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);
 
___
freebsd-xen@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"

Re: Xen kernel fails to boot, d0v1 triple fault looks like the cuplrit

[Roger Pau Monné]

Please try to avoid top posting.

On Sat, May 19, 2018 at 03:45:41PM +0530, Pratyush Yadav wrote:
> Hi,
> 
> The line is
> 
> /usr/src/sys/amd64/amd64/mp_machdep.c:307

Hm, it seems like dbg_stack is not properly allocated. Can you please
try the above debug patch and paste the boot log?

---8<---
diff --git a/sys/amd64/amd64/mp_machdep.c b/sys/amd64/amd64/mp_machdep.c
index 301461420874..8854242b4bf5 100644
--- a/sys/amd64/amd64/mp_machdep.c
+++ b/sys/amd64/amd64/mp_machdep.c
@@ -304,6 +304,7 @@ init_secondary(void)
 
/* Save the per-cpu pointer for use by the DB# handler. */
np = ((struct nmi_pcpu *) _stack[PAGE_SIZE]) - 1;
+printf("ID %d dbg_stack: %p per-cpu: %p\n", cpu, dbg_stack, np);
np->np_pcpu = (register_t) pc;
 
wrmsr(MSR_FSBASE, 0);   /* User value */
@@ -403,6 +404,7 @@ native_start_all_aps(void)
M_WAITOK | M_ZERO);
dbg_stack = (char *)kmem_malloc(kernel_arena, PAGE_SIZE,
M_WAITOK | M_ZERO);
+printf("allocated dbg_stack: %p\n", dbg_stack);
dpcpu = (void *)kmem_malloc(kernel_arena, DPCPU_SIZE,
M_WAITOK | M_ZERO);
 
___
freebsd-xen@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"

Re: Xen kernel fails to boot, d0v1 triple fault looks like the cuplrit

[Pratyush Yadav]

On Sat, May 19, 2018 at 3:45 PM, Pratyush Yadav  wrote:
> Hi,
>
> The line is
>
> /usr/src/sys/amd64/amd64/mp_machdep.c:307
>
> Also, I tried with dom0_max_vcpus=1 but it keeps rebooting (despite noreboot
> in the xen command line)

Correction: It boots with dom0_max_vcpus=1. It did not boot for me
earlier because I was trying to fix it by trying to make Xen from
source so I had actually deinstalled it when I tested with
max_vcpus=1. Now I reinstalled Xen and it works.

Thanks for the temporary workaround! Let me know if you want more info
about the panic.

>
> On Sat 19 May, 2018, 1:40 PM Roger Pau Monné,  wrote:
>>
>> On Fri, May 18, 2018 at 05:29:06PM +0530, Pratyush Yadav wrote:
>> > Hi,
>> >
>> > So I have been trying to get Xen to boot on my laptop. It is getting
>> > stuck with the following error messages:
>> >
>> > (XEN) Scrubbing free RAM on 1 nodes using 4 CPUs
>> > (XEN) [VT-D] DMAR: [DMA Read} Request device [:00:1a.0] fault addr
>> > 9ce13000. iommu reg - 82c000203000
>> > (XEN) [VT-D] DMAR: reason 06 - PTE read access is not set
>> > (XEN) ... done
>> > (XEN) initial low memory virq threshold set at 0x200 pages.
>> > (XEN) Std. Loglevel: All
>> > (XEN) Guest Loglevel: All
>> > (XEN) Xen is keeping VGA console
>> > (XEN) Boot video device 00:02.0
>> > (XEN) ***Serial input -> DOM0 (type 'CTRL-a' three times to switch input
>> > to Xen)
>> > (XEN) Freed 320 kB init memory
>> > FreeBSD PVH running on xen-3.0-x86_64p
>> > Copyright (c) 1992-2018 The FreeBSD Project.
>> > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993,
>> > 1994 The regents of the University of California. All rights reserved.
>> > FreeBSD is a registered trademark of The FreeBSD Foundation.
>> > FreeBSD 12.0-CURRENT #0 r333606: Mon May 14 19:59:08 UTC 2018
>> >
>> > r...@releng3.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64
>> > WARNING: WITNESS option enabled, expect reduced performance.
>> > VT(vga): text 80x25
>> > CPU: Intel(R) Core(TM) i7-4710HQ CPU @ 2.50GHz (2494.22-MHz K8-class
>> > CPU)
>> > Origin="GenuineIntel" Id=0x306c3 Family=0x6 Model=0x3c Stepping=3
>> >
>> > Features=0x17c1cbf5> > FXSR,SSE,SSE2,HTT>
>> >
>> > Features2=0xf6f83203> > POPCNT,AESNI,XSAVE,AVX,F16C,RDRAND,HV>
>> > AMD Features=0x20101800
>> > AMD Features2=0x21<
>> > Structured Extended
>> > Features=0x2329
>> > Hypervisor: Origin = "XenVMMXenVMM"
>> > real memory  = 9991770112 (9528 MB)
>> > avail memory = 7936724992 (7569 MB)
>> > (XEN) d0v1 Triple fault - invoking HVM shutdown action 0
>> > (XEN) *** Dumping Dom0 vcpu#1 state: ***
>> > (XEN) [ Xen-4.7.2 x86_64 debug=n Not tainted ]
>> > (XEN) CPU:1
>> > (XEN) RIP:0020:[]
>> > (XEN) RFLAGS:  00010016CONTEXT: hvm guest (d0v1)
>> > (XEN) rax:    rbx: 8201c100   rcx:
>> > 0001
>> > (XEN) rdx: 3078   rsi: 81b992f8   rdi:
>> > fe0003bb6078
>> > (XEN) rbp: fe90   rsp: fe9fffa0   r8:
>> > 
>> > (XEN) r15: 0400   cr0: 0011   cr4:
>> > 0020
>> > (XEN) cr3: 035a4000   cr2: 0ff0
>> > (XEN) ds: 0028   es: 0028   fs: 0028   gs: 0028   ss: 0028   cs: 0020
>> > (XEN) Guest stack trace from rsp=fe9fffa0:
>> > (XEN)   Fault while accessing guest memory.
>> > (XEN) Hardware Dom0 halted: halting machine
>> >
>> > Any idea why this is happening and how can I fix this?
>>
>> Can you execute:
>>
>> addr2line -e /usr/lib/debug/boot/kernel/kernel.debug 8102042b
>>
>> This should print a file and line number that would help in order to
>> debug what's going on.
>>
>> Since it seems like the crash is caused by a triple fault on an AP,
>> you can try to boot with dom0_max_vcpus=1 on the xen_cmdline, that
>> might prevent the panic from happening.
>>
>> We need however to figure out what's going on and fix it.
>>
>> Thanks, Roger.



-- 
Regards,
Pratyush Yadav
___
freebsd-xen@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"

Re: Xen kernel fails to boot, d0v1 triple fault looks like the cuplrit

[Pratyush Yadav]

Hi,

On Fri 18 May, 2018, 6:55 PM Akshay Jaggi,  wrote:

> Looks to me like a configuration error. Worst case, incompatible hardware.
> Iirc, you mentioned Xen and Freebsd were on a USB drive. Can you try using
> a hard drive partition?
> Also, there was an option to enable verbose logging.
>

I installed on my HDD, but it makes no difference. Also, I have set log
level to all, still the logs are not being saved.

Regards,
> Akshay
>
> On Fri 18 May, 2018, 2:13 PM Edward Tomasz Napierała, 
> wrote:
>
>>
>> > On 18 May 2018, at 12:59, Pratyush Yadav  wrote:
>> >
>> > Hi,
>> >
>> > So I have been trying to get Xen to boot on my laptop. It is getting
>> > stuck with the following error messages:
>> >
>> > (XEN) Scrubbing free RAM on 1 nodes using 4 CPUs
>> > (XEN) [VT-D] DMAR: [DMA Read} Request device [:00:1a.0] fault addr
>> > 9ce13000. iommu reg - 82c000203000
>> > (XEN) [VT-D] DMAR: reason 06 - PTE read access is not set
>> > (XEN) ... done
>> > (XEN) initial low memory virq threshold set at 0x200 pages.
>> > (XEN) Std. Loglevel: All
>> > (XEN) Guest Loglevel: All
>> > (XEN) Xen is keeping VGA console
>> > (XEN) Boot video device 00:02.0
>> > (XEN) ***Serial input -> DOM0 (type 'CTRL-a' three times to switch
>> input to Xen)
>> > (XEN) Freed 320 kB init memory
>> > FreeBSD PVH running on xen-3.0-x86_64p
>> > Copyright (c) 1992-2018 The FreeBSD Project.
>> > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993,
>> > 1994 The regents of the University of California. All rights reserved.
>> > FreeBSD is a registered trademark of The FreeBSD Foundation.
>> > FreeBSD 12.0-CURRENT #0 r333606: Mon May 14 19:59:08 UTC 2018
>> >r...@releng3.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC
>> amd64
>> > WARNING: WITNESS option enabled, expect reduced performance.
>> > VT(vga): text 80x25
>> > CPU: Intel(R) Core(TM) i7-4710HQ CPU @ 2.50GHz (2494.22-MHz K8-class
>> CPU)
>> >Origin="GenuineIntel" Id=0x306c3 Family=0x6 Model=0x3c Stepping=3
>> >
>> Features=0x17c1cbf5> > FXSR,SSE,SSE2,HTT>
>> >
>> Features2=0xf6f83203> > POPCNT,AESNI,XSAVE,AVX,F16C,RDRAND,HV>
>> >AMD Features=0x20101800
>> >AMD Features2=0x21<
>> >Structured Extended
>> Features=0x2329
>> > Hypervisor: Origin = "XenVMMXenVMM"
>> > real memory  = 9991770112 (9528 MB)
>> > avail memory = 7936724992 (7569 MB)
>> > (XEN) d0v1 Triple fault - invoking HVM shutdown action 0
>> > (XEN) *** Dumping Dom0 vcpu#1 state: ***
>> > (XEN) [ Xen-4.7.2 x86_64 debug=n Not tainted ]
>> > (XEN) CPU:1
>> > (XEN) RIP:0020:[]
>> > (XEN) RFLAGS:  00010016CONTEXT: hvm guest (d0v1)
>> > (XEN) rax:    rbx: 8201c100   rcx:
>> 0001
>> > (XEN) rdx: 3078   rsi: 81b992f8   rdi:
>> fe0003bb6078
>> > (XEN) rbp: fe90   rsp: fe9fffa0   r8:
>> 
>> > (XEN) r15: 0400   cr0: 0011   cr4:
>> 0020
>> > (XEN) cr3: 035a4000   cr2: 0ff0
>> > (XEN) ds: 0028   es: 0028   fs: 0028   gs: 0028   ss: 0028   cs: 0020
>> > (XEN) Guest stack trace from rsp=fe9fffa0:
>> > (XEN)   Fault while accessing guest memory.
>> > (XEN) Hardware Dom0 halted: halting machine
>> >
>> > Any idea why this is happening and how can I fix this?
>>
>> First thing I’d try is to checkout an earlier version - eg from three
>> months ago) and see if it persist.  Another thing to do (in parallel) is to
>> file a PR (http://bugs.freebsd.org).
>>
>>
___
freebsd-xen@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"

Re: Xen kernel fails to boot, d0v1 triple fault looks like the cuplrit

[Pratyush Yadav]

Hi,

The line is

/usr/src/sys/amd64/amd64/mp_machdep.c:307

Also, I tried with dom0_max_vcpus=1 but it keeps rebooting (despite
noreboot in the xen command line)

On Sat 19 May, 2018, 1:40 PM Roger Pau Monné,  wrote:

> On Fri, May 18, 2018 at 05:29:06PM +0530, Pratyush Yadav wrote:
> > Hi,
> >
> > So I have been trying to get Xen to boot on my laptop. It is getting
> > stuck with the following error messages:
> >
> > (XEN) Scrubbing free RAM on 1 nodes using 4 CPUs
> > (XEN) [VT-D] DMAR: [DMA Read} Request device [:00:1a.0] fault addr
> > 9ce13000. iommu reg - 82c000203000
> > (XEN) [VT-D] DMAR: reason 06 - PTE read access is not set
> > (XEN) ... done
> > (XEN) initial low memory virq threshold set at 0x200 pages.
> > (XEN) Std. Loglevel: All
> > (XEN) Guest Loglevel: All
> > (XEN) Xen is keeping VGA console
> > (XEN) Boot video device 00:02.0
> > (XEN) ***Serial input -> DOM0 (type 'CTRL-a' three times to switch input
> to Xen)
> > (XEN) Freed 320 kB init memory
> > FreeBSD PVH running on xen-3.0-x86_64p
> > Copyright (c) 1992-2018 The FreeBSD Project.
> > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993,
> > 1994 The regents of the University of California. All rights reserved.
> > FreeBSD is a registered trademark of The FreeBSD Foundation.
> > FreeBSD 12.0-CURRENT #0 r333606: Mon May 14 19:59:08 UTC 2018
> > r...@releng3.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC
> amd64
> > WARNING: WITNESS option enabled, expect reduced performance.
> > VT(vga): text 80x25
> > CPU: Intel(R) Core(TM) i7-4710HQ CPU @ 2.50GHz (2494.22-MHz K8-class CPU)
> > Origin="GenuineIntel" Id=0x306c3 Family=0x6 Model=0x3c Stepping=3
> >
>  Features=0x17c1cbf5 > FXSR,SSE,SSE2,HTT>
> >
>  Features2=0xf6f83203 > POPCNT,AESNI,XSAVE,AVX,F16C,RDRAND,HV>
> > AMD Features=0x20101800
> > AMD Features2=0x21<
> > Structured Extended
> Features=0x2329
> > Hypervisor: Origin = "XenVMMXenVMM"
> > real memory  = 9991770112 (9528 MB)
> > avail memory = 7936724992 (7569 MB)
> > (XEN) d0v1 Triple fault - invoking HVM shutdown action 0
> > (XEN) *** Dumping Dom0 vcpu#1 state: ***
> > (XEN) [ Xen-4.7.2 x86_64 debug=n Not tainted ]
> > (XEN) CPU:1
> > (XEN) RIP:0020:[]
> > (XEN) RFLAGS:  00010016CONTEXT: hvm guest (d0v1)
> > (XEN) rax:    rbx: 8201c100   rcx:
> 0001
> > (XEN) rdx: 3078   rsi: 81b992f8   rdi:
> fe0003bb6078
> > (XEN) rbp: fe90   rsp: fe9fffa0   r8:
> 
> > (XEN) r15: 0400   cr0: 0011   cr4:
> 0020
> > (XEN) cr3: 035a4000   cr2: 0ff0
> > (XEN) ds: 0028   es: 0028   fs: 0028   gs: 0028   ss: 0028   cs: 0020
> > (XEN) Guest stack trace from rsp=fe9fffa0:
> > (XEN)   Fault while accessing guest memory.
> > (XEN) Hardware Dom0 halted: halting machine
> >
> > Any idea why this is happening and how can I fix this?
>
> Can you execute:
>
> addr2line -e /usr/lib/debug/boot/kernel/kernel.debug 8102042b
>
> This should print a file and line number that would help in order to
> debug what's going on.
>
> Since it seems like the crash is caused by a triple fault on an AP,
> you can try to boot with dom0_max_vcpus=1 on the xen_cmdline, that
> might prevent the panic from happening.
>
> We need however to figure out what's going on and fix it.
>
> Thanks, Roger.
>
___
freebsd-xen@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"

Re: Xen kernel fails to boot, d0v1 triple fault looks like the cuplrit

[Roger Pau Monné]

On Fri, May 18, 2018 at 05:29:06PM +0530, Pratyush Yadav wrote:
> Hi,
> 
> So I have been trying to get Xen to boot on my laptop. It is getting
> stuck with the following error messages:
> 
> (XEN) Scrubbing free RAM on 1 nodes using 4 CPUs
> (XEN) [VT-D] DMAR: [DMA Read} Request device [:00:1a.0] fault addr
> 9ce13000. iommu reg - 82c000203000
> (XEN) [VT-D] DMAR: reason 06 - PTE read access is not set
> (XEN) ... done
> (XEN) initial low memory virq threshold set at 0x200 pages.
> (XEN) Std. Loglevel: All
> (XEN) Guest Loglevel: All
> (XEN) Xen is keeping VGA console
> (XEN) Boot video device 00:02.0
> (XEN) ***Serial input -> DOM0 (type 'CTRL-a' three times to switch input to 
> Xen)
> (XEN) Freed 320 kB init memory
> FreeBSD PVH running on xen-3.0-x86_64p
> Copyright (c) 1992-2018 The FreeBSD Project.
> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993,
> 1994 The regents of the University of California. All rights reserved.
> FreeBSD is a registered trademark of The FreeBSD Foundation.
> FreeBSD 12.0-CURRENT #0 r333606: Mon May 14 19:59:08 UTC 2018
> r...@releng3.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC 
> amd64
> WARNING: WITNESS option enabled, expect reduced performance.
> VT(vga): text 80x25
> CPU: Intel(R) Core(TM) i7-4710HQ CPU @ 2.50GHz (2494.22-MHz K8-class CPU)
> Origin="GenuineIntel" Id=0x306c3 Family=0x6 Model=0x3c Stepping=3
> 
> Features=0x17c1cbf5 FXSR,SSE,SSE2,HTT>
> 
> Features2=0xf6f83203 POPCNT,AESNI,XSAVE,AVX,F16C,RDRAND,HV>
> AMD Features=0x20101800
> AMD Features2=0x21<
> Structured Extended Features=0x2329
> Hypervisor: Origin = "XenVMMXenVMM"
> real memory  = 9991770112 (9528 MB)
> avail memory = 7936724992 (7569 MB)
> (XEN) d0v1 Triple fault - invoking HVM shutdown action 0
> (XEN) *** Dumping Dom0 vcpu#1 state: ***
> (XEN) [ Xen-4.7.2 x86_64 debug=n Not tainted ]
> (XEN) CPU:1
> (XEN) RIP:0020:[]
> (XEN) RFLAGS:  00010016CONTEXT: hvm guest (d0v1)
> (XEN) rax:    rbx: 8201c100   rcx: 0001
> (XEN) rdx: 3078   rsi: 81b992f8   rdi: fe0003bb6078
> (XEN) rbp: fe90   rsp: fe9fffa0   r8: 
> (XEN) r15: 0400   cr0: 0011   cr4: 0020
> (XEN) cr3: 035a4000   cr2: 0ff0
> (XEN) ds: 0028   es: 0028   fs: 0028   gs: 0028   ss: 0028   cs: 0020
> (XEN) Guest stack trace from rsp=fe9fffa0:
> (XEN)   Fault while accessing guest memory.
> (XEN) Hardware Dom0 halted: halting machine
> 
> Any idea why this is happening and how can I fix this?

Can you execute:

addr2line -e /usr/lib/debug/boot/kernel/kernel.debug 8102042b

This should print a file and line number that would help in order to
debug what's going on.

Since it seems like the crash is caused by a triple fault on an AP,
you can try to boot with dom0_max_vcpus=1 on the xen_cmdline, that
might prevent the panic from happening.

We need however to figure out what's going on and fix it.

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

Re: Xen kernel fails to boot, d0v1 triple fault looks like the cuplrit

[Edward Tomasz Napierała]

> On 18 May 2018, at 12:59, Pratyush Yadav  wrote:
> 
> Hi,
> 
> So I have been trying to get Xen to boot on my laptop. It is getting
> stuck with the following error messages:
> 
> (XEN) Scrubbing free RAM on 1 nodes using 4 CPUs
> (XEN) [VT-D] DMAR: [DMA Read} Request device [:00:1a.0] fault addr
> 9ce13000. iommu reg - 82c000203000
> (XEN) [VT-D] DMAR: reason 06 - PTE read access is not set
> (XEN) ... done
> (XEN) initial low memory virq threshold set at 0x200 pages.
> (XEN) Std. Loglevel: All
> (XEN) Guest Loglevel: All
> (XEN) Xen is keeping VGA console
> (XEN) Boot video device 00:02.0
> (XEN) ***Serial input -> DOM0 (type 'CTRL-a' three times to switch input to 
> Xen)
> (XEN) Freed 320 kB init memory
> FreeBSD PVH running on xen-3.0-x86_64p
> Copyright (c) 1992-2018 The FreeBSD Project.
> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993,
> 1994 The regents of the University of California. All rights reserved.
> FreeBSD is a registered trademark of The FreeBSD Foundation.
> FreeBSD 12.0-CURRENT #0 r333606: Mon May 14 19:59:08 UTC 2018
>r...@releng3.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64
> WARNING: WITNESS option enabled, expect reduced performance.
> VT(vga): text 80x25
> CPU: Intel(R) Core(TM) i7-4710HQ CPU @ 2.50GHz (2494.22-MHz K8-class CPU)
>Origin="GenuineIntel" Id=0x306c3 Family=0x6 Model=0x3c Stepping=3
>
> Features=0x17c1cbf5 FXSR,SSE,SSE2,HTT>
>
> Features2=0xf6f83203 POPCNT,AESNI,XSAVE,AVX,F16C,RDRAND,HV>
>AMD Features=0x20101800
>AMD Features2=0x21<
>Structured Extended Features=0x2329
> Hypervisor: Origin = "XenVMMXenVMM"
> real memory  = 9991770112 (9528 MB)
> avail memory = 7936724992 (7569 MB)
> (XEN) d0v1 Triple fault - invoking HVM shutdown action 0
> (XEN) *** Dumping Dom0 vcpu#1 state: ***
> (XEN) [ Xen-4.7.2 x86_64 debug=n Not tainted ]
> (XEN) CPU:1
> (XEN) RIP:0020:[]
> (XEN) RFLAGS:  00010016CONTEXT: hvm guest (d0v1)
> (XEN) rax:    rbx: 8201c100   rcx: 0001
> (XEN) rdx: 3078   rsi: 81b992f8   rdi: fe0003bb6078
> (XEN) rbp: fe90   rsp: fe9fffa0   r8: 
> (XEN) r15: 0400   cr0: 0011   cr4: 0020
> (XEN) cr3: 035a4000   cr2: 0ff0
> (XEN) ds: 0028   es: 0028   fs: 0028   gs: 0028   ss: 0028   cs: 0020
> (XEN) Guest stack trace from rsp=fe9fffa0:
> (XEN)   Fault while accessing guest memory.
> (XEN) Hardware Dom0 halted: halting machine
> 
> Any idea why this is happening and how can I fix this?

First thing I’d try is to checkout an earlier version - eg from three months 
ago) and see if it persist.  Another thing to do (in parallel) is to file a PR 
(http://bugs.freebsd.org).

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

Re: Xen on FreeBSD 11: Cannot boot from QCOW2 properly (waiting for XENBUS, xenbusb_nop_confighook_cb)

[Roger Pau Monné]

On Tue, Aug 08, 2017 at 07:55:16PM +0300, Alexander Nusov wrote:
> Hello,
> 
> tried booting from qcow2 on FreeBSD 11.1-RELEASE, the issue still exists.

Hm, great. Now it's too late to fix 11.1 :(. Have you tried with HEAD?

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

Re: Xen on FreeBSD 11: Cannot boot from QCOW2 properly (waiting for XENBUS, xenbusb_nop_confighook_cb)

[Alexander Nusov]

Hello,

tried booting from qcow2 on FreeBSD 11.1-RELEASE, the issue still exists.



--

thanks,

alex




 On Mon, 27 Feb 2017 18:45:38 +0300 Alexander Nusov 
alexander.nu...@nfvexpress.com wrote 




Not yet,

I’ll try the HEAD this week.



—

alex





 On Feb 27, 2017, at 6:34 PM, Roger Pau Monné roger@citrix.com 
wrote:

 

 On Mon, Feb 27, 2017 at 06:30:12PM +0300, Alexander Nusov wrote:

 Hi, 

 Sorry for top posting.

 

 Any update on the issue?

 Please let me know if I need open a bug in Bugzilla.

 

 Sadly it seems like there are still some loose ends on the VM subsystem. I 
hope

 those will be fixed soon. Have you tried with HEAD recently?

 

 Roger.





___

freebsd-xen@freebsd.org mailing list

https://lists.freebsd.org/mailman/listinfo/freebsd-xen

To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"






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

Re: Xen Grant table

[Roger Pau Monné]

On Sun, Jul 02, 2017 at 07:39:39PM +0530, VAIBHAV GAUTAM wrote:
> Hello all,
> 
> I am new here. I want to work on *Xen bus_dma Grant Table Handler* and have
> started with some initial prototype. It would be grateful if someone can
> agree to help me and mentor me on this project.

Hello,

I'm happy to continue to mentor you on that project, outside of GSoC
and at your own peace. The first step would be to get a test
environment that you can use properly, so let's start by that before
getting into any coding.

First of all, you already said that you are more comfortable using
Ubuntu as your development environment, and that's fine for this
project. What I would like you to do now is setup Ubuntu, install Xen
and create a FreeBSD VM in order to test your changes. You can install
Xen from the Ubuntu packages, since you don't have to modify Xen code
it's probably going to be easier to just use the distro packages, at
least as a start.

Then you should create a FreeBSD HVM. You can do so by downloading one
of the FreeBSD VM snapshots that can be found at:

ftp://ftp.nl.freebsd.org/pub/FreeBSD/snapshots/VM-IMAGES/12.0-CURRENT/amd64/Latest/

I would like to make sure that you have the serial console enabled
[0][1] on the VM, and that you can see the output of FreeBSD booting
when you do a `xl console ` or `xl create -c
`. It's very important that you have a proper setup
before starting coding.

Once you have the snapshot image setup, I would like you to update
FreeBSD to the latest HEAD version [2] (ie: you will have to checkout
the sources and do a full buildworld + buildkernel + install).

Please let me know once that's finished :).

Roger.

[0] https://www.freebsd.org/doc/handbook/serialconsole-setup.html
[1] 
https://wiki.xenproject.org/wiki/Xen_FAQ_Console#How_do_I_run_xl_console_to_an_HVM_DomU.3F
[2] https://www.freebsd.org/doc/handbook/makeworld.html
___
freebsd-xen@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"

Re: Xen on FreeBSD 11: Cannot boot from QCOW2 properly (waiting for XENBUS, xenbusb_nop_confighook_cb)

[Alexander Nusov]

Not yet,
I’ll try the HEAD this week.

—
alex


> On Feb 27, 2017, at 6:34 PM, Roger Pau Monné  wrote:
> 
> On Mon, Feb 27, 2017 at 06:30:12PM +0300, Alexander Nusov wrote:
>> Hi, 
>> Sorry for top posting.
>> 
>> Any update on the issue?
>> Please let me know if I need open a bug in Bugzilla.
> 
> Sadly it seems like there are still some loose ends on the VM subsystem. I 
> hope
> those will be fixed soon. Have you tried with HEAD recently?
> 
> Roger.


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

Re: Xen on FreeBSD 11: Cannot boot from QCOW2 properly (waiting for XENBUS, xenbusb_nop_confighook_cb)

[Roger Pau Monné]

On Mon, Feb 27, 2017 at 06:30:12PM +0300, Alexander Nusov wrote:
> Hi, 
> Sorry for top posting.
> 
> Any update on the issue?
> Please let me know if I need open a bug in Bugzilla.

Sadly it seems like there are still some loose ends on the VM subsystem. I hope
those will be fixed soon. Have you tried with HEAD recently?

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

Re: Xen on FreeBSD 11: Cannot boot from QCOW2 properly (waiting for XENBUS, xenbusb_nop_confighook_cb)

[Alexander Nusov]

Hi!

Please notify me when the issue will be fixed so I could start backporting 
patches to 11.0 to test qcow backend.

 On Fri, 03 Feb 2017 13:14:02 +0300 roger@citrix.com wrote 

On Thu, Feb 02, 2017 at 11:37:02PM +, Akshay Jaggi wrote: 
> [-Alex] 
> 
> Hi Roger, 
> 
> Did this get solved with the change you submitted to Xen? 

This issue is cased by a bug in the VM subsystem, kib is currently looking into 
it, and patches will be committed soon hopefully. The Xen patch I've sent is 
the FreeBSD handlers for the gnttab lib, with that everything is already 
upstream :). I will backport the Xen patch to your Xen package once the VM 
issue is solved. 

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

Re: Xen on FreeBSD 11: Cannot boot from QCOW2 properly (waiting for XENBUS, xenbusb_nop_confighook_cb)

[Roger Pau Monné]

On Thu, Feb 02, 2017 at 11:37:02PM +, Akshay Jaggi wrote:
> [-Alex]
> 
> Hi Roger,
> 
> Did this get solved with the change you submitted to Xen?

This issue is cased by a bug in the VM subsystem, kib is currently looking into
it, and patches will be committed soon hopefully. The Xen patch I've sent is
the FreeBSD handlers for the gnttab lib, with that everything is already
upstream :). I will backport the Xen patch to your Xen package once the VM
issue is solved.

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

Re: Xen on FreeBSD 11: Cannot boot from QCOW2 properly (waiting for XENBUS, xenbusb_nop_confighook_cb)

[Akshay Jaggi]

[-Alex]

Hi Roger,

Did this get solved with the change you submitted to Xen?

On 25 January 2017 at 11:58, Alexander Nusov  wrote:

> Cool, many thanks!
>
> --
> Alex
>
>  On Wed, 25 Jan 2017 14:50:51 +0300 *Roger Pau Monné
> >* wrote 
>
> On Wed, Jan 25, 2017 at 02:20:55PM +0300, Alexander Nusov wrote:
> > Got it, thanks.
> >
> >
> >
> > I found a workaround to avoid XENBUS delay in Linux DomUs by adding
> xen_platform_pci = 0 to the configuration file.
> >
> > So FreeBSD 11.0 Dom0 can boot Linux guests and Windows Server (FreeBSD
> DomU still stuck on xenbusb_nop_confighook_cb) from QCOW2 images (also
> works with QCOW2 overlay images)
> >
>
> On FreeBSD you can boot with QCOW2 by not setting "xen_platform_pci = 0"
> on the
> guest config file and adding "hw.xen.disable_pv_disks=1" to the
> /boot/loader.conf file of the guest. This will prevent FreeBSD from using
> the
> PV disk, but you will still get the PV network interfaces.
>
> >
> > Can you tell me please what is the disadvantage of not using
> /dev/xen/vbd devices and drivers in guests? like slow I/O?
>
> Slow IO only.
>
> > May it lead to data corruption?
>
> No.
>
>
>
___
freebsd-xen@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"

Re: Xen on FreeBSD 11: Cannot boot from QCOW2 properly (waiting for XENBUS, xenbusb_nop_confighook_cb)

[Alexander Nusov]

Cool, many thanks!



--

Alex


 On Wed, 25 Jan 2017 14:50:51 +0300 Roger Pau Monné 
roger@citrix.com wrote 




On Wed, Jan 25, 2017 at 02:20:55PM +0300, Alexander Nusov wrote: 

 Got it, thanks. 

 

 

 

 I found a workaround to avoid XENBUS delay in Linux DomUs by adding 
xen_platform_pci = 0 to the configuration file. 

 

 So FreeBSD 11.0 Dom0 can boot Linux guests and Windows Server (FreeBSD 
DomU still stuck on xenbusb_nop_confighook_cb) from QCOW2 images (also works 
with QCOW2 overlay images) 

 

 

On FreeBSD you can boot with QCOW2 by not setting "xen_platform_pci = 0" on the 

guest config file and adding "hw.xen.disable_pv_disks=1" to the 

/boot/loader.conf file of the guest. This will prevent FreeBSD from using the 

PV disk, but you will still get the PV network interfaces. 

 

 

 Can you tell me please what is the disadvantage of not using /dev/xen/vbd 
devices and drivers in guests? like slow I/O? 

 

Slow IO only. 

 

 May it lead to data corruption? 

 

No. 






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

Re: Xen on FreeBSD 11: Cannot boot from QCOW2 properly (waiting for XENBUS, xenbusb_nop_confighook_cb)

[Roger Pau Monné]

On Wed, Jan 25, 2017 at 02:20:55PM +0300, Alexander Nusov wrote:
> Got it, thanks.
> 
> 
> 
> I found a workaround to avoid XENBUS delay in Linux DomUs by adding 
> xen_platform_pci = 0 to the configuration file.
> 
> So FreeBSD 11.0 Dom0 can boot Linux guests and Windows Server (FreeBSD DomU 
> still stuck on xenbusb_nop_confighook_cb) from QCOW2 images (also works with 
> QCOW2 overlay images)
> 

On FreeBSD you can boot with QCOW2 by not setting "xen_platform_pci = 0" on the
guest config file and adding "hw.xen.disable_pv_disks=1" to the
/boot/loader.conf file of the guest. This will prevent FreeBSD from using the
PV disk, but you will still get the PV network interfaces.

> 
> Can you tell me please what is the disadvantage of not using /dev/xen/vbd 
> devices and drivers in guests? like slow I/O? 

Slow IO only.

> May it lead to data corruption?

No.
___
freebsd-xen@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"

Re: Xen on FreeBSD 11: Cannot boot from QCOW2 properly (waiting for XENBUS, xenbusb_nop_confighook_cb)

[Alexander Nusov]

Got it, thanks.



I found a workaround to avoid XENBUS delay in Linux DomUs by adding 
xen_platform_pci = 0 to the configuration file.

So FreeBSD 11.0 Dom0 can boot Linux guests and Windows Server (FreeBSD DomU 
still stuck on xenbusb_nop_confighook_cb) from QCOW2 images (also works with 
QCOW2 overlay images)



Can you tell me please what is the disadvantage of not using /dev/xen/vbd 
devices and drivers in guests? like slow I/O? 

May it lead to data corruption?


--

Alex




 On Wed, 25 Jan 2017 12:35:14 +0300 Akshay Jaggi ja...@freebsd.org 
wrote 




Hi Alex and Roger,



Without the patch and FreeBSD 12, qcow2 doesn't actually work. We were thinking 
of adding code to warn against this, but then thought gntdev implementation is 
in process anyway.

With the patch, the crash needs to be investigated (because I did run one of 
the gntdev based image, most probably qcow2, iirc).

Sadly, I'm still searching for housing in Dublin, and hence won't be able to 
look at this immediately. Two weeks, to find and then move in, if I'm lucky. 
Meanwhile, I'll start hunting for a development machine in office.



Regards,

Akshay






On Jan 24, 2017 16:56, Roger Pau Monné roger@citrix.com wrote:






On Tue, Jan 24, 2017 at 05:45:25PM +0300, Alexander Nusov wrote:

 Yes, it was FreeBSD 11.0-STABLE Dom0 with xen-kernel/xen-tools built from 
the ports tree (head)







 It seems there is an issue with xen pci devices, since booting from QCOW2 
images actually works (even on FreeBSD 11.0-RELEASE branch) except 
communication with /xen/vbd devices from the guest.



Yes, I'm seeing exactly the same. The QEMU process is killed with a

segmentation fault. Akshay, here is the full debug output:



Program terminated with signal 11, Segmentation fault.

[...]

#0  blk_handle_requests (blkdev=0x807463c00) at hw/block/xen_disk.c:862

862 rp = blkdev-rings.common.sring-req_prod;

[New Thread 8087f9000 (LWP 100947/unknown)]

[New Thread 807418800 (LWP 100945/unknown)]

[New Thread 807418300 (LWP 100944/unknown)]

[New Thread 807417e00 (LWP 100943/unknown)]

[New Thread 807417900 (LWP 100942/unknown)]

[New Thread 807417400 (LWP 100941/unknown)]

[New Thread 807416a00 (LWP 100940/unknown)]

[New Thread 807416500 (LWP 100939/unknown)]

[New Thread 807416000 (LWP 100091/unknown)]

(gdb) bt

#0  blk_handle_requests (blkdev=0x807463c00) at hw/block/xen_disk.c:862

#1  0x005f9dcd in blk_bh (opaque=0x807463c00) at hw/block/xen_disk.c:918

#2  0x0080ba69 in aio_bh_call (bh=0x80780d810) at async.c:87

#3  0x0080bb10 in aio_bh_poll (ctx=0x8074a0680) at async.c:115

#4  0x0081c099 in aio_dispatch (ctx=0x8074a0680) at aio-posix.c:303

#5  0x0080c2cd in aio_ctx_dispatch (source=0x8074a0680, callback=0, 
user_data=0x0)

at async.c:254

#6  0x000802e3903b in g_main_context_dispatch () from 
/usr/local/lib/libglib-2.0.so.0

#7  0x0081a34c in glib_pollfds_poll () at main-loop.c:259

#8  0x00819dc5 in os_host_main_loop_wait (timeout=0) at main-loop.c:306

#9  0x00819c29 in main_loop_wait (nonblocking=0) at main-loop.c:556

#10 0x00588ed7 in main_loop () at vl.c:1966

#11 0x00583b59 in main (argc=38, argv=0x7fffe750, 
envp=0x7fffe888) at vl.c:4684

Current language:  auto; currently minimal



It seems like the device is not properly mapping the grants, and QEMU gets a

SEGFAULT when trying to access the ring page.



Roger.





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

Re: Xen on FreeBSD 11: Cannot boot from QCOW2 properly (waiting for XENBUS, xenbusb_nop_confighook_cb)

[Akshay Jaggi]

Hi Alex and Roger,

Without the patch and FreeBSD 12, qcow2 doesn't actually work. We were
thinking of adding code to warn against this, but then thought gntdev
implementation is in process anyway.
With the patch, the crash needs to be investigated (because I did run one
of the gntdev based image, most probably qcow2, iirc).
Sadly, I'm still searching for housing in Dublin, and hence won't be able
to look at this immediately. Two weeks, to find and then move in, if I'm
lucky. Meanwhile, I'll start hunting for a development machine in office.

Regards,
Akshay

On Jan 24, 2017 16:56, Roger Pau Monné  wrote:

> On Tue, Jan 24, 2017 at 05:45:25PM +0300, Alexander Nusov wrote:
> > Yes, it was FreeBSD 11.0-STABLE Dom0 with xen-kernel/xen-tools built
> from the ports tree (head)
> >
> >
> >
> > It seems there is an issue with xen pci devices, since booting from
> QCOW2 images actually works (even on FreeBSD 11.0-RELEASE branch) except
> communication with /xen/vbd devices from the guest.
>
> Yes, I'm seeing exactly the same. The QEMU process is killed with a
> segmentation fault. Akshay, here is the full debug output:
>
> Program terminated with signal 11, Segmentation fault.
> [...]
> #0  blk_handle_requests (blkdev=0x807463c00) at hw/block/xen_disk.c:862
> 862 rp = blkdev->rings.common.sring->req_prod;
> [New Thread 8087f9000 (LWP 100947/)]
> [New Thread 807418800 (LWP 100945/)]
> [New Thread 807418300 (LWP 100944/)]
> [New Thread 807417e00 (LWP 100943/)]
> [New Thread 807417900 (LWP 100942/)]
> [New Thread 807417400 (LWP 100941/)]
> [New Thread 807416a00 (LWP 100940/)]
> [New Thread 807416500 (LWP 100939/)]
> [New Thread 807416000 (LWP 100091/)]
> (gdb) bt
> #0  blk_handle_requests (blkdev=0x807463c00) at hw/block/xen_disk.c:862
> #1  0x005f9dcd in blk_bh (opaque=0x807463c00) at
> hw/block/xen_disk.c:918
> #2  0x0080ba69 in aio_bh_call (bh=0x80780d810) at async.c:87
> #3  0x0080bb10 in aio_bh_poll (ctx=0x8074a0680) at async.c:115
> #4  0x0081c099 in aio_dispatch (ctx=0x8074a0680) at aio-posix.c:303
> #5  0x0080c2cd in aio_ctx_dispatch (source=0x8074a0680,
> callback=0, user_data=0x0)
> at async.c:254
> #6  0x000802e3903b in g_main_context_dispatch () from /usr/local/lib/
> libglib-2.0.so.0
> #7  0x0081a34c in glib_pollfds_poll () at main-loop.c:259
> #8  0x00819dc5 in os_host_main_loop_wait (timeout=0) at
> main-loop.c:306
> #9  0x00819c29 in main_loop_wait (nonblocking=0) at main-loop.c:556
> #10 0x00588ed7 in main_loop () at vl.c:1966
> #11 0x00583b59 in main (argc=38, argv=0x7fffe750,
> envp=0x7fffe888) at vl.c:4684
> Current language:  auto; currently minimal
>
> It seems like the device is not properly mapping the grants, and QEMU gets
> a
> SEGFAULT when trying to access the ring page.
>
> Roger.
>
___
freebsd-xen@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"

Re: Xen on FreeBSD 11: Cannot boot from QCOW2 properly (waiting for XENBUS, xenbusb_nop_confighook_cb)

[Roger Pau Monné]

On Tue, Jan 24, 2017 at 05:45:25PM +0300, Alexander Nusov wrote:
> Yes, it was FreeBSD 11.0-STABLE Dom0 with xen-kernel/xen-tools built from the 
> ports tree (head)
> 
> 
> 
> It seems there is an issue with xen pci devices, since booting from QCOW2 
> images actually works (even on FreeBSD 11.0-RELEASE branch) except 
> communication with /xen/vbd devices from the guest.

Yes, I'm seeing exactly the same. The QEMU process is killed with a
segmentation fault. Akshay, here is the full debug output:

Program terminated with signal 11, Segmentation fault.
[...]
#0  blk_handle_requests (blkdev=0x807463c00) at hw/block/xen_disk.c:862
862 rp = blkdev->rings.common.sring->req_prod;
[New Thread 8087f9000 (LWP 100947/)]
[New Thread 807418800 (LWP 100945/)]
[New Thread 807418300 (LWP 100944/)]
[New Thread 807417e00 (LWP 100943/)]
[New Thread 807417900 (LWP 100942/)]
[New Thread 807417400 (LWP 100941/)]
[New Thread 807416a00 (LWP 100940/)]
[New Thread 807416500 (LWP 100939/)]
[New Thread 807416000 (LWP 100091/)]
(gdb) bt
#0  blk_handle_requests (blkdev=0x807463c00) at hw/block/xen_disk.c:862
#1  0x005f9dcd in blk_bh (opaque=0x807463c00) at hw/block/xen_disk.c:918
#2  0x0080ba69 in aio_bh_call (bh=0x80780d810) at async.c:87
#3  0x0080bb10 in aio_bh_poll (ctx=0x8074a0680) at async.c:115
#4  0x0081c099 in aio_dispatch (ctx=0x8074a0680) at aio-posix.c:303
#5  0x0080c2cd in aio_ctx_dispatch (source=0x8074a0680, callback=0, 
user_data=0x0)
at async.c:254
#6  0x000802e3903b in g_main_context_dispatch () from 
/usr/local/lib/libglib-2.0.so.0
#7  0x0081a34c in glib_pollfds_poll () at main-loop.c:259
#8  0x00819dc5 in os_host_main_loop_wait (timeout=0) at main-loop.c:306
#9  0x00819c29 in main_loop_wait (nonblocking=0) at main-loop.c:556
#10 0x00588ed7 in main_loop () at vl.c:1966
#11 0x00583b59 in main (argc=38, argv=0x7fffe750, 
envp=0x7fffe888) at vl.c:4684
Current language:  auto; currently minimal

It seems like the device is not properly mapping the grants, and QEMU gets a
SEGFAULT when trying to access the ring page.

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

Re: Xen on FreeBSD 11: Cannot boot from QCOW2 properly (waiting for XENBUS, xenbusb_nop_confighook_cb)

[Alexander Nusov]

Yes, it was FreeBSD 11.0-STABLE Dom0 with xen-kernel/xen-tools built from the 
ports tree (head)



It seems there is an issue with xen pci devices, since booting from QCOW2 
images actually works (even on FreeBSD 11.0-RELEASE branch) except 
communication with /xen/vbd devices from the guest.


By the way, I installed FreeBSD 12-CURRENT r311461 snapshot and applied the 
patch for xen-utils and now things got worse,

qemu-system-i386 process started to crash at this point:

[1.162342] GHES: HEST is not enabled!

[1.166829] xen-platform-pci :00:02.0: PCI INT A - GSI 24 (level, 
low) - IRQ 24

[1.191301] Grant table initialized

[1.197758] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled

[1.238473] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A

[1.246103] init_memory_mapping: 2000-2800

[1.374895] 00:0a: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A

[1.381290] Linux agpgart interface v0.103

[1.387732] brd: module loaded

[1.392518] loop: module loaded

CRASH



root@current:~ # cat /var/log/xen/xl-vm.log 

Waiting for domain vm (domid 4) to die [pid 18070]

libxl: debug: libxl_event.c:636:libxl__ev_xswatch_register: watch w=0x80321c3e0 
wpath=@releaseDomain token=3/0: register slotnum=3

libxl: debug: libxl_event.c:573:watchfd_callback: watch w=0x80321c3e0 
wpath=@releaseDomain token=3/0: event epath=@releaseDomain

libxl: debug: libxl.c:1184:domain_death_xswatch_callback: [evg=0x803221aa0:4] 
nentries=1 rc=1 4..4

libxl: debug: libxl.c:1195:domain_death_xswatch_callback: [evg=0x803221aa0:4]   
got=domaininfos[0] got-domain=4

libxl: debug: libxl.c:1221:domain_death_xswatch_callback:  exists 
shutdown_reported=0 dominf.flags=0002

libxl: debug: libxl.c:1188:domain_death_xswatch_callback: [evg=0] all reported

libxl: debug: libxl.c:1250:domain_death_xswatch_callback: domain death search 
done



Then I did a xen-utils rollback and stuck with the same issue (Waiting for 
XENBUS), no crash though.



root@current:~ # cat vm.cfg 

builder = "hvm" 

memory = 512 

vcpus = 2 

name = "vm" 

disk = 
['format=qcow2,vdev=xvda,access=rw,backendtype=qdisk,target=/root/cirros-0.3.4-x86_64-disk.img']

boot = "c" 

vnc = 1 

vnclisten = "0.0.0.0" 

usbdevice = 'tablet' 

on_poweroff = 'destroy' 

on_reboot = 'restart' 

on_crash = 'restart' 

acpi = 1 

serial = 'pty'



root@current:~ # cat /boot/loader.conf 

hw.pci.mcfg=0

xen_kernel="/boot/xen"

xen_cmdline="dom0_mem=8192M dom0_max_vcpus=8 dom0pvh=1 com1=115200,8n1 
guest_loglvl=all loglvl=all"



root@current:~ # cat /etc/sysctl.conf 

vm.max_wired=-1



root@current:~ # xl -vvv create vm.cfg

Parsing config from vm.cfg

libxl: debug: libxl_create.c:1710:do_domain_create: ao 0x803247000: create: 
how=0x0 callback=0x0 poller=0x8032280a0

libxl: debug: libxl_device.c:347:libxl__device_disk_set_backend: Disk vdev=xvda 
spec.backend=qdisk

libxl: debug: libxl_create.c:970:initiate_domain_create: running bootloader

libxl: debug: libxl_bootloader.c:324:libxl__bootloader_run: not a PV domain, 
skipping bootloader

libxl: debug: libxl_event.c:686:libxl__ev_xswatch_deregister: watch 
w=0x80325dab8: deregister unregistered

domainbuilder: detail: xc_dom_allocate: cmdline="(null)", features="(null)"

domainbuilder: detail: xc_dom_kernel_file: 
filename="/usr/local/lib/xen/boot/hvmloader"

domainbuilder: detail: xc_dom_malloc_filemap: 329 kB

domainbuilder: detail: xc_dom_boot_xen_init: ver 4.7, caps xen-3.0-x86_64 
xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64 

domainbuilder: detail: xc_dom_parse_image: called

domainbuilder: detail: xc_dom_find_loader: trying ELF-generic loader ... 

domainbuilder: detail: loader probe failed

domainbuilder: detail: xc_dom_find_loader: trying Linux bzImage loader ... 

domainbuilder: detail: xc_dom_probe_bzimage_kernel: kernel is not a bzImage

domainbuilder: detail: loader probe failed

domainbuilder: detail: xc_dom_find_loader: trying HVM-generic loader ... 

domainbuilder: detail: loader probe OK

xc: detail: elf_parse_binary: phdr: paddr=0x10 memsz=0x5ad0c

xc: detail: elf_parse_binary: memory: 0x10 - 0x15ad0c

domainbuilder: detail: xc_dom_mem_init: mem 504 MB, pages 0x1f800 pages, 4k each

domainbuilder: detail: xc_dom_mem_init: 0x1f800 pages

domainbuilder: detail: xc_dom_boot_mem_init: called

domainbuilder: detail: xc_dom_malloc: 1008 kB

xc: detail: PHYSICAL MEMORY ALLOCATION:

xc: detail:   4KB PAGES: 0x0200

xc: detail:   2MB PAGES: 0x00fb

xc: detail:   1GB PAGES: 0x

domainbuilder: detail: xc_dom_build_image: called

domainbuilder: detail: xc_dom_pfn_to_ptr_retcount: domU mapping: pfn 0x100+0x5b 
at 0x8006d1000

domainbuilder: detail: xc_dom_alloc_segment:   kernel   : 0x10 - 
0x15b000  (pfn 0x100 + 0x5b pages)

xc: detail: elf_load_binary: phdr 0 at 0x80072c000 - 0x80077d2a8

domainbuilder: detail: alloc_pgtables_hvm: doing nothing

domainbuilder: detail: 

Re: Xen on FreeBSD 11: Cannot boot from QCOW2 properly (waiting for XENBUS, xenbusb_nop_confighook_cb)

[Roger Pau Monné]

On Mon, Jan 23, 2017 at 06:25:23PM +0300, Alexander Nusov wrote:
> Hello,
> Sorry for cross-posting, since it's related to Xen hypervisor I'm forwarding 
> this message to the freebsd-xen mailing list.
> 
> I'm trying to launch a HVM DomU guest from QCOW2 image by using PV driver on 
> FreeBSD 11 Dom0.
> The issue is that guest cannot connect to the device/vbd and requires to wait 
> for 4 minutes to proceed, it goes through the countdown and starts fine 
> (disk, networking)
> 
> [6.684115] XENBUS: Waiting for devices to initialise: 
> 25s...20s...15s...10s...5s...0s...235s...230s...225s...220s...215s...210s...205s...200s...195s...190s...185s...180s...175s...170s...165s...160s...155s...150s...145s...140s...135s...130s...125s...120s...115s...110s...105s...100s...95s...90s...85s...80s...75s...70s...65s...60s...55s...50s...45s...40s...35s...30s...25s...20s...15s...10s...5s...0s...
> [  271.591403] XENBUS: Timeout connecting to device: device/vbd/51712 (local 
> state 3, remote state 1)
> [  271.599963] XENBUS: Device with no driver: device/vkbd/0
> [  271.604249]   Magic number: 1:453:334
> ...
> login: 
> 
> 
> Unlike Linux It's impossible to boot FreeBSD 11 guests from QCOW2 
> (xenbusb_nop_confighook_cb timeout)
> 
> Steps to reproduce:
> 1. Download qcow2 cirros image (small linux) 
> http://secure-web.cisco.com/1RtWXk7FS6UyRxe5A9ejZVfU2VK9512Yeds80mlP_0LoLwQJLjbPBoILL2e4QyF2OaMyO8fbrQrYVmfOybSYvHgWH1sRz1gK4Zi5XDAzBDUluwhlU4NxVQ7S17tH6vSTrIJmBJ_NO-sdA1Ph_KfSOsNvMkw-swwuKHD9ophVFfqEe6Lnt_PIP4H-LhZfp-5_aCuqbPYciXtMyxWbF1Od65jiFe-_LfmPRt53aCscOk7cBRI_-o603sb7htpDHH06Y8-M4oG5Lt4s1jr1XcKTrIWhnD-Lhz55blWyc2FnCgvk/http%3A%2F%2Fdownload.cirros-cloud.net%2F0.3.4%2Fcirros-0.3.4-x86_64-disk.img
>  
> 
>  
> >
> # file cirros-0.3.4-x86_64-disk.img 
> cirros-0.3.4-x86_64-disk.img: QEMU QCOW Image (v2), 41126400 bytes
> 2. create DomU from config bellow xl create -c config.cfg
> 
> builder = "hvm"
> memory = 512
> vcpus = 2
> name = "cirros"
> disk = [ 'file:qcow2:/root/cirros-0.3.4-x86_64-disk.img,xvda,w' ]
> boot = "c" 
> vnc = 1
> vnclisten = "0.0.0.0"
> usbdevice = 'tablet'
> on_poweroff = 'destroy'
> on_reboot = 'restart'
> on_crash = 'restart'
> acpi = 1
> serial = 'pty'
> 
> I've also tried multiple configurations like tap:qcow2:. tap2:qcow2:, aio:, 
> switching from xen bus to ide. didn't work.
> The only driver that had no issues was PHY but it supports only RAW images.
> 
> Is that a bug or I'm missing something?
> 
> tested both STABLE snapshot and 11.0-RELEASE
> 
> # uname -a
> FreeBSD xen 11.0-STABLE FreeBSD 11.0-STABLE #0 r311441: Thu Jan  5 22:45:20 
> UTC 2017
> 
> # pkg info | grep xen
> xen-4.7.0_2Xen Hypervisor meta port
> xen-kernel-4.7.1_3 Hypervisor using a microkernel design
> xen-tools-4.7.1_1  Xen management tool, based on LibXenlight

So just that I understand this correctly, this is a FreeBSD 11.0-STABLE Dom0,
plus the Xen packages from pkg?

If that's the case, it's not going to work, FreeBSD 11.0 Dom0 doesn't yet
support qcow image format for HVM/PV guests, you will have to use FreeBSD 12
(HEAD) as your Dom0, or backport r308128 into STABLE (should be self contained,
so I don't expect any conflicts). You will also have to apply the following
patch to the xen-tools package and recompile:

https://lists.freebsd.org/pipermail/freebsd-xen/2016-August/002819.html

IIRC the right syntax to specify the disk device is:

'format=qcow2,vdev=xvda,access=rw,backendtype=qdisk,target=/root/cirros-0.3.4-x86_64-disk.img'

I'm also adding Akshay to the conversation, who did the gntdev implementation.

Roger.
___
freebsd-xen@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-xen
To 

Re: Xen networking problems in -current with xn driver?

[Roger Pau Monné]

On Wed, Aug 03, 2016 at 02:12:33AM +0800, Julian Elischer wrote:
> I upgraded my VPS machine to today's current, and on reboot I couldn't get
> into it by network.
> 
> A quick switch to the VNC console showed that it was up but that it couldn't
> get out.
> 
> 
> The xn interfaces said they were UP but attempts to get out were met with
> "network is down".
> 
> if I did 'tcpdump -n -i xn0' (and xn1) hten all was fine again.
> 
> tcpdump saw packets, and in fact ipfw saw some packets coming in even before
> that but it was not possible to send.
> 
> 
> Has anyone seen similar?

Hello,

I've tested current less than one week ago and didn't find any issues, I'm 
currently updating to see if it's something that has been introduced in the 
last few days. There have also been reports of it working fine on the
freebsd-xen mailing list, but I guess there's something different with your 
setup:

https://lists.freebsd.org/pipermail/freebsd-xen/2016-July/002779.html

> some relevant parts of the dmesg output.:
> 
> 
> T(vga): text 80x25
> XEN: Hypervisor version 3.4 detected.
> CPU: Intel(R) Xeon(R) CPU   E5620  @ 2.40GHz (2400.05-MHz 686-class
> CPU)
>   Origin="GenuineIntel"  Id=0x206c2  Family=0x6  Model=0x2c Stepping=2
> Features=0x1781fbff
> Features2=0x80982201
>   AMD Features=0x2010
>   AMD Features2=0x1
> Hypervisor: Origin = "XenVMMXenVMM"
> real memory  = 536870912 (512 MB)
> avail memory = 503783424 (480 MB)
> Event timer "LAPIC" quality 400
> ACPI APIC Table: 
> WARNING: L1 data cache covers less APIC IDs than a core
> 0 < 1
> WARNING: L2 data cache covers less APIC IDs than a core
> 0 < 1
> WARNING: L3 data cache covers less APIC IDs than a core
> 0 < 1
> 
> ipfw2 (+ipv6) initialized, divert loadable, nat enabled, default to deny,

You seem to be using ipfw, I guess you have firewall_enable="YES" on you 
rc.conf, are you also using IPv6? Anything else net related on your rc.conf?

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

Re: [Xen-devel] HEADS UP: Imported Xen 4.7: no blkback

[Wei Liu]

On Thu, Jun 09, 2016 at 10:03:43AM +0200, Roger Pau Monné wrote:
> On Thu, Jun 09, 2016 at 12:16:59AM +, Marcin Cieslak wrote:
> > On Fri, 3 Jun 2016, Roger Pau Monné wrote:
> > 
> > > One of the more relevant changes in 4.7 regarding FreeBSD is the support 
> > > for 
> > > block hotplug scripts. This means that we now have the option to use 
> > > backends different than simple block or regular files, provided that 
> > > someone 
> > > writes the proper hotplug scripts to attach them (I've heard there are 
> > > some 
> > > iSCSI hotplug scripts around). This however requires changes in blkback, 
> > > so 
> > > if you plan to use the Xen 4.7 port, please make sure that you are 
> > > running a 
> > > kernel that contains revision r301269 (or any later version). The same 
> > > also 
> > 
> > I am running it with r301685 and the HVM guests have some trouble with
> > block devices.
> > 
> > SeaBIOS does not find /dev/zvol/zroot/freebsd1,raw,xvda,w to boot FreeBSD
> > from, after chaging to "hda" I get up to the kernel mountroot prompt
> > (Xen block devices seem to be detected in dmesg).
> 
> Yes, this is intentional, see:
> 
> https://marc.info/?l=xen-devel=144482080812353
> 

Note that I reverted that change yesterday. 4.7 will behave as before.

Wei.
___
freebsd-xen@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"

Re: XEN DOM0 on C

[Roger Pau Monné]

On Fri, 8 Apr 2016, Ivan UAdm wrote:
> Hi there,
> 
> I start playing with FreeBSD DOM0 and receive message on boot with XEN
> kernel
> 
> elf_xen_addr_calc_check: ERROR: ELF start or entries are out of bounds
> Panic on CPU 0:
> Could not set up DOM0 guest OS
> 
> full screen https://yadi.sk/i/r8HXFTBjqqRyr
> 
> I use this manual http://wiki.xen.org/wiki/FreeBSD_Dom0 but I use ports and
> pkg.
> 
> $ uname -a: FreeBSD rnhv00 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r296485:
> Tue Mar  8 07:04:36 UTC 2016
> r...@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC
> amd64

Hello,

You need to use r297242 or later, see:

https://lists.freebsd.org/pipermail/freebsd-virtualization/2016-March/004243.html

For more information.

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

Re: Xen/dom0/FreeBSD + NAS4Free WebGUI.

[Wei Liu]

On Tue, Jan 12, 2016 at 02:23:39PM +0100, Roger Pau Monné wrote:
[...]
> I'm adding Wei to the Cc, he has been working on netfront improvements,
> so maybe he also wants to take a stab at netback ;).

It's on my radar but I don't have time for it in the near future. If
anyone else who is watching FreeBSD Xen implementation have the desire
to improve it I'm happy to help.

Wei.
___
freebsd-xen@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"

Re: Xen/dom0/FreeBSD + NAS4Free WebGUI.

[Daisuke Aoyama]

Hello,

--
From: "Roger Pau Monne" <roy...@freebsd.org>
Sent: Monday, December 28, 2015 10:20 PM
To: "Daisuke Aoyama" <aoy...@peach.ne.jp>; <freebsd-xen@freebsd.org>
Cc: <freebsd-curr...@freebsd.org>
Subject: Re: Xen/dom0/FreeBSD + NAS4Free WebGUI.


Hello,

El 26/12/15 a les 15.26, Daisuke Aoyama ha escrit:

Hi all,

I'm creating NAS4Free dom0 edition.
This is simple wrapper of Xen/dom0/FreeBSD.

You can upgrade by same way of NAS4Free.
You can manage HDD, ZFS, iSCSI target, NFS share by same way of NAS4Free.
You can manage DomU(VM) via WebGUI.

Japanese blog:
http://shell.peach.ne.jp/aoyama/archives/3149
http://shell.peach.ne.jp/aoyama/archives/3135

NAS4Free dom0 topic in English:
http://forums.nas4free.org/viewtopic.php?f=17=10028

Latest download:
http://www.peach.ne.jp/archives/nas4free/test/2244-dom0/

How to install:
1.Download LiveCD iso image.
2.Burn to CD/DVD-RW blank disc.
3.Boot from it.
(if your server don't have an optical drive, please use an external USB
optical drive)
4.Install to USB Flash drive (2GB or more) from menu #9.
5.Reboot the server after ejecting CD/DVD media.

How to upgrade:
1.Navigate to System|Firmware in global menu from web browser.
2.Click "Enable Firmware Update".
3.Select NAS4Free-dom0-embedded-*.img.xz. (don't decompress the image)
4.Click "Upgrade Firmware".


I forget to write. You should backup the config from System|Backup/Restore 
before upgrading.



Note:
At least you need a bridge interface before using.
Please create it from Network|Interface Management|Bridge.
You can change boot parameters from System|Advanced|loader.conf.
If you are interested in the xl.cfg, it is created in
/usr/local/etc/xen/vm-.cfg.


Thanks for doing this, I just gave it a try and it worked out of the
box, I was able to create and launch a Windows VM in less than 2min,
quite impressive :).


Thank you for trying.




Known issues:
uuid generation of ports/sysutils/xen-tools is broken. You cannot
control by UUID.
(quick hack patch is attached this mail)


I've given a look at the patch, but I have to admit I know very little
about UUID, yet it seems like you should not poke directly at the
internal uuid_t fields. I've created another patch which I *think*
should solve the UUID issues, could you test it please? It should apply
cleanly against Xen 4.5.

https://people.freebsd.org/~royger/uuid.patch


Your patch does not work as expected.
You can test it under normal FreeBSD. First create UUID by uuidgen(1):

# uuidgen
4c90eb5a-adee-11e5-a747-001b2157b424

Insert the UUID to your VM config (see also /usr/local/etc/xen/vm-.cfg):
uuid = "4c90eb5a-adee-11e5-a747-001b2157b424"

Run the VM:
# xl create name.cfg

Check by xl list:
# xl list -v
# xl list -l

Your patched result is here:
[root@nas4free-xen ~]# xl list -v
NameID   Mem VCPUs  State   Time(s)   UUID 
Reason-Code   Security Label
Domain-0 0  4096 4 r- 202.8 
------
nas4free 4  2048 2 -b  51.1 
------



xnb device performance is terrible.
(it eats 100% CPU on intr while transferring via bridged 10GbE)


I haven't seen this, but I'm not surprised (I also don't have a 10GbE
card at hand right now). There's a lot of fine tuning and bug fixing to
do regarding the backends. I plan to get with this once the PVH
implementation is stable.


I feel UUID is very small thing than performance 70% drop down via xnb.

Regards,
--
Daisuke Aoyama


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

Re: Xen dom0 crash

[Roger Pau Monné]

El 21/10/15 a les 11.02, Eggert, Lars ha escrit:
> On 2015-10-21, at 10:53, Roger Pau Monné  wrote:
>> hw.pci.mcfg=0
> 
> Thanks! That gets me a bit further, but it now crashes with:
> 
> ...
> SMP: AP CPU #7 Launched!
> SMP: AP CPU #14 Launched!
> SMP: AP CPU #11 Launched!
> SMP: AP CPU #21 Launched!
> SMP: AP CPU #30 Launched!
> SMP: AP CPU #4 Launched!
> SMP: AP CPU #20 Launched!
> panic: xen_pv_lapic_enable_pmc: not available in Xen PV port.
> cpuid = 0
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0x81fd5990
> vpanic() at vpanic+0x182/frame 0x81fd5a10
> panic() at panic+0x43/frame 0x81fd5a70
> xen_pv_lapic_enable_pmc() at xen_pv_lapic_enable_pmc+0x19/frame 
> 0x81fd5a80
> pmc_md_initialize() at pmc_md_initialize+0x3c/frame 0x81fd5aa0
> load() at load+0x41e/frame 0x81fd5af0
> syscall_module_handler() at syscall_module_handler+0x290/frame 
> 0x81fd5b20
> module_register_init() at module_register_init+0xfb/frame 0x81fd5b50
> mi_startup() at mi_startup+0x108/frame 0x81fd5b70
> xen_start() at xen_start+0x1f
> KDB: enter: panic
> [ thread pid 0 tid 10 ]
> Stopped at  kdb_enter+0x3b: movq$0,kdb_why
> db>

Hello,

Are you loading hwpmc by default? Performance monitor counters are not
yet implemented in the FreeBSD PVH port, so you should not load hwpmc. I
have to look at providing an error message here rather than panicking.

Roger.

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

Re: Xen dom0 crash

[Eggert, Lars]

On 2015-10-21, at 11:11, Roger Pau Monné  wrote:
> Are you loading hwpmc by default?

Yes.

> Performance monitor counters are not
> yet implemented in the FreeBSD PVH port, so you should not load hwpmc. I
> have to look at providing an error message here rather than panicking.

Strange, the same kernel config worked earlier. But without hwmpc, the it now 
boots.

Thanks!

Lars


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Xen dom0 crash

[Roger Pau Monné]

El 21/10/15 a les 11.51, Eggert, Lars ha escrit:
> On 2015-10-21, at 11:11, Roger Pau Monné  wrote:
>> Are you loading hwpmc by default?
> 
> Yes.
> 
>> Performance monitor counters are not
>> yet implemented in the FreeBSD PVH port, so you should not load hwpmc. I
>> have to look at providing an error message here rather than panicking.
> 
> Strange, the same kernel config worked earlier. But without hwmpc, the it now 
> boots.

It might well be that Xen is exposing different cpuid flags in 4.6 vs
4.5, and that makes hwpmc attach. All the cpuid stuff in PVH is still
in-flux.

Roger.

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

Re: Xen dom0 crash

[Roger Pau Monné]

El 20/10/15 a les 17.13, Eggert, Lars ha escrit:
> Hi,
> 
> with a recent -CURRENT and xen-4.6.0, I now see a different crash at boot on 
> the same box. Any ideas?
> 
> Thanks,
> Lars
> 
> 
> B2
>   __      _ _
>  |  | |  _ \ / |  __ \
>  | |___ _ __ ___  ___ | |_) | (___ | |  | |
>  |  ___| '__/ _ \/ _ \|  _ < \___ \| |  | |
>  | |   | | |  __/  __/| |_) |) | |__| |
>  | |   | | |||| |  |  |
>  Xen 4.6.0el/cc_vegas.ko size 0x3348 at 0x1403000`
> (XEN) Xen version 4.6.0 (r...@netapp.com) (gcc47 (FreeBSD Ports Collection) 
> 4.7.4) debug=n Wed Oct 14 18:50:20 CEST 2015g...el/cc_hd.ko size 0x2ea8 at 
> 0x13ff000o   .--` /y:`  +.
> (XEN) Latest ChangeSet: 'ertt' |  yo`:.:o  `+-
> (XEN) Bootloader: FreeBSD Loader   |   y/   -/`   -o/
> (XEN) Command line: guest_loglvl=all loglvl=al dom0_max_vcpus=32 
> dom0_mem=4096M dom0pvh=1 com1=115200,8n1 console=com13. [Esc]ape to loader 
> prompt   |  / `--  /
> (XEN) Video information:   | `:  :`
> (XEN)  VGA is text mode 80x25, font 8x16   | `:  :`
> (XEN)  VBE/DDC methods: none; EDID transfer time: 0 seconds  /
> (XEN)  EDID info not retrieved because no DDC retrieval method detected -.
> (XEN) Disc information:O]ptions... |   --  -.
> (XEN)  Found 1 MBR signatures  |`:`  `:`
> (XEN)  Found 1 EDD information structures  |  .-- `--.
> (XEN) Xen-e820 RAM map:| .---..
> (XEN)   - 0009ac00 (usable)
> (XEN)  0009ac00 - 000a (reserved)
> (XEN)  000e - 0010 (reserved)
> (XEN)  0010 - 7de19000 (usable)
> (XEN)  7de19000 - 7dea8000 (reserved)
> (XEN)  7dea8000 - 7dfb1000 (ACPI data)
> (XEN)  7dfb1000 - 7e1cb000 (ACPI NVS)
> (XEN)  7e1cb000 - 7f355000 (reserved)
> (XEN)  7f355000 - 7f80 (ACPI NVS)
> (XEN)  8000 - 9000 (reserved)
> (XEN)  fed1c000 - fed4 (reserved)
> (XEN)  ff00 - 0001 (reserved)
> (XEN)  0001 - 00208000 (usable)
> (XEN) ACPI: RSDP 000F04A0, 0024 (r2 SUPERM)
> (XEN) ACPI: XSDT 7DEDD088, 008C (r1 SUPERM SMCI--MB1 AMI 10013)
> (XEN) ACPI: FACP 7DEE80F8, 00F4 (r4 SUPERM SMCI--MB1 AMI 10013)
> (XEN) ACPI: DSDT 7DEDD1A0, AF53 (r2 SUPERM SMCI--MB0 INTL 20091112)
> (XEN) ACPI: FACS 7E1C2080, 0040
> (XEN) ACPI: APIC 7DEE81F0, 0224 (r31 AMI 10013)
> (XEN) ACPI: FPDT 7DEE8418, 0044 (r11 AMI 10013)
> (XEN) ACPI: HPET 7DEE8460, 0038 (r1 SUPERM SMCI--MB1 AMI.5)
> (XEN) ACPI: PRAD 7DEE8498, 00BE (r2 PRADID  PRADTID1 MSFT  400)
> (XEN) ACPI: SPMI 7DEE8558, 0040 (r5 A M I   OEMSPMI0 AMI.0)
> (XEN) ACPI: SSDT 7DEE8598, C7AE8 (r2  INTELCpuPm 4000 INTL 20091112)
> (XEN) ACPI: EINJ 7DFB0080, 0130 (r1AMI AMI EINJ0 0)
> (XEN) ACPI: ERST 7DFB01B0, 0230 (r1  AMIER AMI ERST0 0)
> (XEN) ACPI: HEST 7DFB03E0, 00A8 (r1AMI AMI HEST0 0)
> (XEN) ACPI: BERT 7DFB0488, 0030 (r1AMI AMI BERT0 0)
> (XEN) ACPI: DMAR 7DFB04B8, 0168 (r1 A M I   OEMDMAR1 INTL1)
> (XEN) ACPI: MCFG 7DFB0620, 003C (r1 SUPERM SMCI--MB1 MSFT   97)
> (XEN) System RAM: 131037MB (134182604kB)
> (XEN) Domain heap initialised
> (XEN) ACPI: 32/64X FACS address mismatch in FADT - 7e1c2080/, 
> using 32
> (XEN) Processor #0 6:13 APIC version 21
> (XEN) Processor #2 6:13 APIC version 21
> (XEN) Processor #4 6:13 APIC version 21
> (XEN) Processor #6 6:13 APIC version 21
> (XEN) Processor #8 6:13 APIC version 21
> (XEN) Processor #10 6:13 APIC version 21
> (XEN) Processor #12 6:13 APIC version 21
> (XEN) Processor #14 6:13 APIC version 21
> (XEN) Processor #32 6:13 APIC version 21
> (XEN) Processor #34 6:13 APIC version 21
> (XEN) Processor #36 6:13 APIC version 21
> (XEN) Processor #38 6:13 APIC version 21
> (XEN) Processor #40 6:13 APIC version 21
> (XEN) Processor #42 6:13 APIC version 21
> (XEN) Processor #44 6:13 APIC version 21
> (XEN) Processor #46 6:13 APIC version 21
> (XEN) Processor #1 6:13 APIC version 21
> (XEN) Processor #3 6:13 APIC version 21
> (XEN) Processor #5 6:13 APIC version 21
> (XEN) Processor #7 6:13 APIC version 21
> (XEN) Processor #9 6:13 APIC version 21
> (XEN) Processor #11 6:13 APIC version 21
> (XEN) Processor #13 6:13 APIC version 21
> (XEN) Processor #15 6:13 APIC version 21
> (XEN) Processor #33 6:13 APIC version 21
> (XEN) Processor 

Re: Xen dom0 crash

[Roger Pau Monné]

El 21/10/15 a les 10.33, Eggert, Lars ha escrit:
> On 2015-10-21, at 9:40, Roger Pau Monné  wrote:
>> Can you execute:
>>
>> # addr2line -e /boot/kernel/kernel 8097bf80
>>
>> In order to get the file and line where the failure happens?
> 
> I guess you meant kernel.debug? Then I get:
> 
> /usr/home/elars/src/sys/amd64/pci/pci_cfgreg.c:365
> 
> Which is the __asm line in case 1 in pciereg_cfgwrite().

Hello,

Yes, I knew about this, sorry, with Xen 4.6 you need to add:

hw.pci.mcfg=0

to your /boot/loader.conf. This is because Xen prevents us from writing
at the PCI-e memory mapped config and we need to switch back to using
the IO ports.

Roger.

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

Re: Xen dom0 crash

[Eggert, Lars]

On 2015-10-21, at 10:53, Roger Pau Monné  wrote:
> hw.pci.mcfg=0

Thanks! That gets me a bit further, but it now crashes with:

...
SMP: AP CPU #7 Launched!
SMP: AP CPU #14 Launched!
SMP: AP CPU #11 Launched!
SMP: AP CPU #21 Launched!
SMP: AP CPU #30 Launched!
SMP: AP CPU #4 Launched!
SMP: AP CPU #20 Launched!
panic: xen_pv_lapic_enable_pmc: not available in Xen PV port.
cpuid = 0
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0x81fd5990
vpanic() at vpanic+0x182/frame 0x81fd5a10
panic() at panic+0x43/frame 0x81fd5a70
xen_pv_lapic_enable_pmc() at xen_pv_lapic_enable_pmc+0x19/frame 
0x81fd5a80
pmc_md_initialize() at pmc_md_initialize+0x3c/frame 0x81fd5aa0
load() at load+0x41e/frame 0x81fd5af0
syscall_module_handler() at syscall_module_handler+0x290/frame 
0x81fd5b20
module_register_init() at module_register_init+0xfb/frame 0x81fd5b50
mi_startup() at mi_startup+0x108/frame 0x81fd5b70
xen_start() at xen_start+0x1f
KDB: enter: panic
[ thread pid 0 tid 10 ]
Stopped at  kdb_enter+0x3b: movq$0,kdb_why
db>

Lars


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Xen dom0 crash

[Eggert, Lars]

On 2015-10-20, at 17:13, Eggert, Lars  wrote:
> with a recent -CURRENT and xen-4.6.0, I now see a different crash at boot on 
> the same box. Any ideas?

Actually, it's a different box (Supermicro)

Lars

> 
> Thanks,
> Lars
> 
> 
>B2
>  __      _ _
> |  | |  _ \ / |  __ \
> | |___ _ __ ___  ___ | |_) | (___ | |  | |
> |  ___| '__/ _ \/ _ \|  _ < \___ \| |  | |
> | |   | | |  __/  __/| |_) |) | |__| |
> | |   | | |||| |  |  |
> Xen 4.6.0el/cc_vegas.ko size 0x3348 at 0x1403000`
> (XEN) Xen version 4.6.0 (r...@netapp.com) (gcc47 (FreeBSD Ports Collection) 
> 4.7.4) debug=n Wed Oct 14 18:50:20 CEST 2015g...el/cc_hd.ko size 0x2ea8 at 
> 0x13ff000o   .--` /y:`  +.
> (XEN) Latest ChangeSet: 'ertt' |  yo`:.:o  `+-
> (XEN) Bootloader: FreeBSD Loader   |   y/   -/`   -o/
> (XEN) Command line: guest_loglvl=all loglvl=al dom0_max_vcpus=32 
> dom0_mem=4096M dom0pvh=1 com1=115200,8n1 console=com13. [Esc]ape to loader 
> prompt   |  / `--  /
> (XEN) Video information:   | `:  :`
> (XEN)  VGA is text mode 80x25, font 8x16   | `:  :`
> (XEN)  VBE/DDC methods: none; EDID transfer time: 0 seconds  /
> (XEN)  EDID info not retrieved because no DDC retrieval method detected -.
> (XEN) Disc information:O]ptions... |   --  -.
> (XEN)  Found 1 MBR signatures  |`:`  `:`
> (XEN)  Found 1 EDD information structures  |  .-- `--.
> (XEN) Xen-e820 RAM map:| .---..
> (XEN)   - 0009ac00 (usable)
> (XEN)  0009ac00 - 000a (reserved)
> (XEN)  000e - 0010 (reserved)
> (XEN)  0010 - 7de19000 (usable)
> (XEN)  7de19000 - 7dea8000 (reserved)
> (XEN)  7dea8000 - 7dfb1000 (ACPI data)
> (XEN)  7dfb1000 - 7e1cb000 (ACPI NVS)
> (XEN)  7e1cb000 - 7f355000 (reserved)
> (XEN)  7f355000 - 7f80 (ACPI NVS)
> (XEN)  8000 - 9000 (reserved)
> (XEN)  fed1c000 - fed4 (reserved)
> (XEN)  ff00 - 0001 (reserved)
> (XEN)  0001 - 00208000 (usable)
> (XEN) ACPI: RSDP 000F04A0, 0024 (r2 SUPERM)
> (XEN) ACPI: XSDT 7DEDD088, 008C (r1 SUPERM SMCI--MB1 AMI 10013)
> (XEN) ACPI: FACP 7DEE80F8, 00F4 (r4 SUPERM SMCI--MB1 AMI 10013)
> (XEN) ACPI: DSDT 7DEDD1A0, AF53 (r2 SUPERM SMCI--MB0 INTL 20091112)
> (XEN) ACPI: FACS 7E1C2080, 0040
> (XEN) ACPI: APIC 7DEE81F0, 0224 (r31 AMI 10013)
> (XEN) ACPI: FPDT 7DEE8418, 0044 (r11 AMI 10013)
> (XEN) ACPI: HPET 7DEE8460, 0038 (r1 SUPERM SMCI--MB1 AMI.5)
> (XEN) ACPI: PRAD 7DEE8498, 00BE (r2 PRADID  PRADTID1 MSFT  400)
> (XEN) ACPI: SPMI 7DEE8558, 0040 (r5 A M I   OEMSPMI0 AMI.0)
> (XEN) ACPI: SSDT 7DEE8598, C7AE8 (r2  INTELCpuPm 4000 INTL 20091112)
> (XEN) ACPI: EINJ 7DFB0080, 0130 (r1AMI AMI EINJ0 0)
> (XEN) ACPI: ERST 7DFB01B0, 0230 (r1  AMIER AMI ERST0 0)
> (XEN) ACPI: HEST 7DFB03E0, 00A8 (r1AMI AMI HEST0 0)
> (XEN) ACPI: BERT 7DFB0488, 0030 (r1AMI AMI BERT0 0)
> (XEN) ACPI: DMAR 7DFB04B8, 0168 (r1 A M I   OEMDMAR1 INTL1)
> (XEN) ACPI: MCFG 7DFB0620, 003C (r1 SUPERM SMCI--MB1 MSFT   97)
> (XEN) System RAM: 131037MB (134182604kB)
> (XEN) Domain heap initialised
> (XEN) ACPI: 32/64X FACS address mismatch in FADT - 7e1c2080/, 
> using 32
> (XEN) Processor #0 6:13 APIC version 21
> (XEN) Processor #2 6:13 APIC version 21
> (XEN) Processor #4 6:13 APIC version 21
> (XEN) Processor #6 6:13 APIC version 21
> (XEN) Processor #8 6:13 APIC version 21
> (XEN) Processor #10 6:13 APIC version 21
> (XEN) Processor #12 6:13 APIC version 21
> (XEN) Processor #14 6:13 APIC version 21
> (XEN) Processor #32 6:13 APIC version 21
> (XEN) Processor #34 6:13 APIC version 21
> (XEN) Processor #36 6:13 APIC version 21
> (XEN) Processor #38 6:13 APIC version 21
> (XEN) Processor #40 6:13 APIC version 21
> (XEN) Processor #42 6:13 APIC version 21
> (XEN) Processor #44 6:13 APIC version 21
> (XEN) Processor #46 6:13 APIC version 21
> (XEN) Processor #1 6:13 APIC version 21
> (XEN) Processor #3 6:13 APIC version 21
> (XEN) Processor #5 6:13 APIC version 21
> (XEN) Processor #7 6:13 APIC version 21
> (XEN) Processor #9 6:13 APIC version 21
> (XEN) Processor #11 6:13 APIC version 21
> (XEN) Processor #13 6:13 APIC version 21
> (XEN) Processor #15 6:13 APIC version 21
> (XEN) 

Re: Xen dom0 crash

[Eggert, Lars]

Hi,

with a recent -CURRENT and xen-4.6.0, I now see a different crash at boot on 
the same box. Any ideas?

Thanks,
Lars


B2
  __      _ _
 |  | |  _ \ / |  __ \
 | |___ _ __ ___  ___ | |_) | (___ | |  | |
 |  ___| '__/ _ \/ _ \|  _ < \___ \| |  | |
 | |   | | |  __/  __/| |_) |) | |__| |
 | |   | | |||| |  |  |
 Xen 4.6.0el/cc_vegas.ko size 0x3348 at 0x1403000`
(XEN) Xen version 4.6.0 (r...@netapp.com) (gcc47 (FreeBSD Ports Collection) 
4.7.4) debug=n Wed Oct 14 18:50:20 CEST 2015g...el/cc_hd.ko size 0x2ea8 at 
0x13ff000o   .--` /y:`  +.
(XEN) Latest ChangeSet: 'ertt' |  yo`:.:o  `+-
(XEN) Bootloader: FreeBSD Loader   |   y/   -/`   -o/
(XEN) Command line: guest_loglvl=all loglvl=al dom0_max_vcpus=32 dom0_mem=4096M 
dom0pvh=1 com1=115200,8n1 console=com13. [Esc]ape to loader prompt   |  
/ `--  /
(XEN) Video information:   | `:  :`
(XEN)  VGA is text mode 80x25, font 8x16   | `:  :`
(XEN)  VBE/DDC methods: none; EDID transfer time: 0 seconds  /
(XEN)  EDID info not retrieved because no DDC retrieval method detected -.
(XEN) Disc information:O]ptions... |   --  -.
(XEN)  Found 1 MBR signatures  |`:`  `:`
(XEN)  Found 1 EDD information structures  |  .-- `--.
(XEN) Xen-e820 RAM map:| .---..
(XEN)   - 0009ac00 (usable)
(XEN)  0009ac00 - 000a (reserved)
(XEN)  000e - 0010 (reserved)
(XEN)  0010 - 7de19000 (usable)
(XEN)  7de19000 - 7dea8000 (reserved)
(XEN)  7dea8000 - 7dfb1000 (ACPI data)
(XEN)  7dfb1000 - 7e1cb000 (ACPI NVS)
(XEN)  7e1cb000 - 7f355000 (reserved)
(XEN)  7f355000 - 7f80 (ACPI NVS)
(XEN)  8000 - 9000 (reserved)
(XEN)  fed1c000 - fed4 (reserved)
(XEN)  ff00 - 0001 (reserved)
(XEN)  0001 - 00208000 (usable)
(XEN) ACPI: RSDP 000F04A0, 0024 (r2 SUPERM)
(XEN) ACPI: XSDT 7DEDD088, 008C (r1 SUPERM SMCI--MB1 AMI 10013)
(XEN) ACPI: FACP 7DEE80F8, 00F4 (r4 SUPERM SMCI--MB1 AMI 10013)
(XEN) ACPI: DSDT 7DEDD1A0, AF53 (r2 SUPERM SMCI--MB0 INTL 20091112)
(XEN) ACPI: FACS 7E1C2080, 0040
(XEN) ACPI: APIC 7DEE81F0, 0224 (r31 AMI 10013)
(XEN) ACPI: FPDT 7DEE8418, 0044 (r11 AMI 10013)
(XEN) ACPI: HPET 7DEE8460, 0038 (r1 SUPERM SMCI--MB1 AMI.5)
(XEN) ACPI: PRAD 7DEE8498, 00BE (r2 PRADID  PRADTID1 MSFT  400)
(XEN) ACPI: SPMI 7DEE8558, 0040 (r5 A M I   OEMSPMI0 AMI.0)
(XEN) ACPI: SSDT 7DEE8598, C7AE8 (r2  INTELCpuPm 4000 INTL 20091112)
(XEN) ACPI: EINJ 7DFB0080, 0130 (r1AMI AMI EINJ0 0)
(XEN) ACPI: ERST 7DFB01B0, 0230 (r1  AMIER AMI ERST0 0)
(XEN) ACPI: HEST 7DFB03E0, 00A8 (r1AMI AMI HEST0 0)
(XEN) ACPI: BERT 7DFB0488, 0030 (r1AMI AMI BERT0 0)
(XEN) ACPI: DMAR 7DFB04B8, 0168 (r1 A M I   OEMDMAR1 INTL1)
(XEN) ACPI: MCFG 7DFB0620, 003C (r1 SUPERM SMCI--MB1 MSFT   97)
(XEN) System RAM: 131037MB (134182604kB)
(XEN) Domain heap initialised
(XEN) ACPI: 32/64X FACS address mismatch in FADT - 7e1c2080/, 
using 32
(XEN) Processor #0 6:13 APIC version 21
(XEN) Processor #2 6:13 APIC version 21
(XEN) Processor #4 6:13 APIC version 21
(XEN) Processor #6 6:13 APIC version 21
(XEN) Processor #8 6:13 APIC version 21
(XEN) Processor #10 6:13 APIC version 21
(XEN) Processor #12 6:13 APIC version 21
(XEN) Processor #14 6:13 APIC version 21
(XEN) Processor #32 6:13 APIC version 21
(XEN) Processor #34 6:13 APIC version 21
(XEN) Processor #36 6:13 APIC version 21
(XEN) Processor #38 6:13 APIC version 21
(XEN) Processor #40 6:13 APIC version 21
(XEN) Processor #42 6:13 APIC version 21
(XEN) Processor #44 6:13 APIC version 21
(XEN) Processor #46 6:13 APIC version 21
(XEN) Processor #1 6:13 APIC version 21
(XEN) Processor #3 6:13 APIC version 21
(XEN) Processor #5 6:13 APIC version 21
(XEN) Processor #7 6:13 APIC version 21
(XEN) Processor #9 6:13 APIC version 21
(XEN) Processor #11 6:13 APIC version 21
(XEN) Processor #13 6:13 APIC version 21
(XEN) Processor #15 6:13 APIC version 21
(XEN) Processor #33 6:13 APIC version 21
(XEN) Processor #35 6:13 APIC version 21
(XEN) Processor #37 6:13 APIC version 21
(XEN) Processor #39 6:13 APIC version 21
(XEN) Processor #41 6:13 APIC version 21
(XEN) Processor #43 6:13 APIC version 21
(XEN) Processor #45 6:13 APIC version 21
(XEN) 

Re: Xen Kernel Won't Boot

[Roger Pau Monné]

Hello,

El 19/10/15 a les 17.31, Thomas Laus ha escrit:
> List:
> 
> I have a new installation of FreeBSD Current that won't boot the Xen kernel.
> I loaded the most recent snapshot and then ran 'svnup' to bring my source
> tree up to date on Saturday 10/17/2015.  I followed the instructions on the
> FreeBSD Wiki page on setting up Dom0 support.  I made the changes to
> sysconf.conf, /etc/ttys, /boot/loader.conf and generated a new
> /boot/menu.rc.local.  When the computer was rebooted, it would not load the
> Xen boot file and choked giving me the OK? prompt.
> 
> This is my dmesg output showing the CPU information: 
> 
> Oct 19 10:55:41 xenserver kernel: FreeBSD 11.0-CURRENT #0: Sun Oct 18 
> 04:21:24 EDT 2015
> Oct 19 10:55:41 xenserver kernel: 
> root@xenserver:/usr/obj/usr/src/sys/XENSERVER amd64
> Oct 19 10:55:41 xenserver kernel: FreeBSD clang version 3.7.0 
> (tags/RELEASE_370/final 246257) 20150906
> Oct 19 10:55:41 xenserver kernel: WARNING: WITNESS option enabled, expect 
> reduced performance.
> Oct 19 10:55:41 xenserver kernel: VT(efifb): resolution 1280x1024
> Oct 19 10:55:41 xenserver kernel: CPU: Intel(R) Celeron(R) CPU  J1900  @ 
> 1.99GHz (2000.05-MHz K8-class CPU)

AFAICT you won't be able to boot a FreeBSD/Xen Dom0 on this box because
FreeBSD Dom0 runs as a PVH guest and it requires an IOMMU (aka VT-d in
Intel speech), which your CPU doesn't seem to support.

A traditional Linux PV Dom0 will work fine, but FreeBSD doesn't support
traditional PV mode. Anyway, see the rest of reply below to figure out
why you weren't able to boot...

> Oct 19 10:55:41 xenserver kernel: Origin="GenuineIntel"  Id=0x30673  
> Family=0x6  Model=0x37  Stepping=3
> Oct 19 10:55:41 xenserver kernel: 
> Features=0xbfebfbff MOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
> Oct 19 10:55:41 xenserver kernel: 
> Features2=0x41d8e3bf TPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,TSCDLT,RDRAND>
> Oct 19 10:55:41 xenserver kernel: AMD 
> Features=0x28100800
> Oct 19 10:55:41 xenserver kernel: AMD Features2=0x101
> Oct 19 10:55:41 xenserver kernel: Structured Extended 
> Features=0x2282
> Oct 19 10:55:41 xenserver kernel: VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID
> Oct 19 10:55:41 xenserver kernel: TSC: P-state invariant, performance 
> statistics
> Oct 19 10:55:41 xenserver kernel: real memory  = 4294967296 (4096 MB)
> Oct 19 10:55:41 xenserver kernel: avail memory = 3997675520 (3812 MB)
> Oct 19 10:55:41 xenserver kernel: Event timer "LAPIC" quality 600
> Oct 19 10:55:41 xenserver kernel: ACPI APIC Table: 
> Oct 19 10:55:41 xenserver kernel: FreeBSD/SMP: Multiprocessor System 
> Detected: 4 CPUs
> Oct 19 10:55:41 xenserver kernel: FreeBSD/SMP: 1 package(s) x 4 core(s)
> Oct 19 10:55:41 xenserver kernel: cpu0 (BSP): APIC ID:  0
> Oct 19 10:55:41 xenserver kernel: cpu1 (AP): APIC ID:  2
> Oct 19 10:55:41 xenserver kernel: cpu2 (AP): APIC ID:  4
> Oct 19 10:55:41 xenserver kernel: cpu3 (AP): APIC ID:  6
> 
> Having a non-functioning entry in /boot/loader.conf is a tough one to recover
> and requires booting to a live filesystem.  Loading one of the working
> kernels still loads the same loader.conf.

FWIW, and I know it won't help much now, but you can use:

> unload
> unset xen_kernel
> boot ...

And the loader won't try to load the Xen kernel anymore.

> This motherboard uses UEFI and was
> installed with a UEFI kernel.  This computer was able to successfully load 
> the
> Citrix XenServer 6.5 and had all 'green' lights when I ran 'xl dmesg'.  I
> used another hard drive for the Citrix load.  It seemed to be happy with all
> of my CPU and hardware features.  I was able to make a DomU image from an
> OpenBSD 5.8 snapshot.  I have been running FreeBSD since version 4.11 and
> would prefer not to run the Citrix XenServer because of all of it's
> 'Linux-isms'.  Their filesystem uses Logical Volume Manager and I much prefer
> ZFS for disk management.
> 
> Is there any other information that should be sent to this list?

Booting a FreeBSD/Xen Dom0 using UEFI is not yet supported, if you want
to use this box as a FreeBSD/Xen Dom0 you will have to switch back to
BIOS boot I'm afraid (although as noted above I think your CPU is
missing a feature in order to run a FreeBSD/Xen Dom0).

Roger.

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

Re: [Xen-users] forcing HVM to specific network model with PV-aware FreeBSD DomU

[Roger Pau Monné]

Hello,

Adding the freebsd-xen mailing list since somebody might be able to
provide better advice than me regarding network stuff.

El 15/10/15 a les 12.31, Andreas Pflug ha escrit:
> Hi!
> 
> For quite a while, I've been running several pfSense firewall DomUs up
> to version 2.15 on Xen. Since the FreeBSD kernel 8.3 of pfSense wasn't
> xen-aware the model e1000 was used, and I had all networking features as
> expected though performance was degraded.
> 
> When the new pfSense 2.2 was introduced, the kernel changed to FreeBSD
> 10.1 which now (finally!) includes a xen netfront driver, promising a
> vastly improved performance. Unfortunately, its implementation is quite
> sketchy:
> - offloading issues, which can be worked around by disabling tx
> offloading using a custom vif-script

Is this related to the long-standing pf+TSO issues? There's a recent
commit that should solve it:

https://svnweb.freebsd.org/base?view=revision=289316

There seems to be plans to issue an EN for that one, so you might be
able to get it by just using freebsd-update (or whatever pfSense uses)
without having to wait for a new stable release.

> - VLANs are not supported. Can be achieved with multiple bridges in
> Dom0, if 8 are enough. If you need more, you're out of luck.
> - ALTQ not supported. No known workaround, preventing any traffic shaping.

Sadly I'm not aware of anyone working on this two items. Any pickers?

> On the FreeBSD side, it is said that the xn xen netfront driver can't be
> disabled at boot time, unless a custom kernel is built (certainly not
> desirable regarding security updates), so:
> 
> How can I disable xen-netback drivers for a specific HVM? It should
> respect the "model=e1000" setting (or maybe virtio?). I'm running Xen
> 4.4 on Debian.

I've recently committed a patch to HEAD in order to disable PV nics or
disks on request:

https://svnweb.freebsd.org/base?view=revision=286999

I will backport it to stable-10 soon to make sure it's on the next
stable release (FreeBSD 10.3). Apart from that, there's not much we can
do now.

Roger.

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

Re: Xen console on 10.1 DomU

[Jeroen van der Ham]

Hi,

 On 20 Jul 2015, at 18:04, Roger Pau Monné roger@citrix.com wrote:
 
 El 17/07/15 a les 21.02, Jeroen van der Ham ha escrit:
 Hi,
 
 What is the current way of getting a xen console on a FreeBSD 10.1 DomU?
 
 I’ve been searching on:
 * https://wiki.freebsd.org/FreeBSD/Xen (reasonably up to date, but has no 
 info on console)
 * http://wiki.xen.org (completely outdated, “official” documentation points 
 to installation of FreeBSD 7.2(!))
 
 I found instructions to add a line to /boot/loader.conf 
 (console=comconsole”)
 or a line to /etc/ttys (xc0 /usr/libexec/getty Pc vt100   on  
 secure)
 
 You shouldn't need to modify /etc/ttys at all unless you are using a
 FreeBSD PVH guest or Dom0.
 
 But in either case I am getting an error on the Linux Dom0:
 xenconsole: Could not read tty from store: No such file or directory
 
 Is it still possible to get a console from a Linux Dom0? How?
 What would be the best place to publish instructions for that?
 
 Which kind of guest are you trying to get the console from?
 
 If it's a HVM guest (I'm only guessing here), you need to add
 serial='pty' to your xl configuration file and then follow
 https://www.freebsd.org/doc/handbook/serialconsole-setup.html.

Thanks, that did the trick.
Now the question remains where to document this properly so that others will 
not be mislead by all the other advice out there?

Jeroen.

___
freebsd-xen@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to freebsd-xen-unsubscr...@freebsd.org

Re: Xen console on 10.1 DomU

[Roger Pau Monné]

El 17/07/15 a les 21.02, Jeroen van der Ham ha escrit:
 Hi,
 
 What is the current way of getting a xen console on a FreeBSD 10.1 DomU?
 
 I’ve been searching on:
 * https://wiki.freebsd.org/FreeBSD/Xen (reasonably up to date, but has no 
 info on console)
 * http://wiki.xen.org (completely outdated, “official” documentation points 
 to installation of FreeBSD 7.2(!))
 
 I found instructions to add a line to /boot/loader.conf (console=comconsole”)
 or a line to /etc/ttys (xc0 /usr/libexec/getty Pc vt100   on  
 secure)

You shouldn't need to modify /etc/ttys at all unless you are using a
FreeBSD PVH guest or Dom0.

 But in either case I am getting an error on the Linux Dom0:
 xenconsole: Could not read tty from store: No such file or directory
 
 Is it still possible to get a console from a Linux Dom0? How?
 What would be the best place to publish instructions for that?

Which kind of guest are you trying to get the console from?

If it's a HVM guest (I'm only guessing here), you need to add
serial='pty' to your xl configuration file and then follow
https://www.freebsd.org/doc/handbook/serialconsole-setup.html.

Roger.

___
freebsd-xen@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to freebsd-xen-unsubscr...@freebsd.org

Re: Xen dom0 crash

[Roger Pau Monné]

El 26/05/15 a les 9.30, Eggert, Lars ha escrit:
 On 2015-5-22, at 18:27, Roger Pau Monné roger@citrix.com wrote:

 The issue mentioned in this thread has been fixed in the xen-kernel port
 with the following commit:

 https://svnweb.freebsd.org/ports?view=revisionrevision=386935
 
 Will this make it into upstream Xen?

I hope so, I've already sent the patch and it has been acked by one of
the Intel VMX maintainers, so I guess it's not going to take long before
it's committed:

http://lists.xenproject.org/archives/html/xen-devel/2015-05/msg03068.html

Roger.

___
freebsd-xen@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to freebsd-xen-unsubscr...@freebsd.org

Re: Xen dom0 crash

[Eggert, Lars]

On 2015-5-22, at 18:27, Roger Pau Monné roger@citrix.com wrote:
 
 The issue mentioned in this thread has been fixed in the xen-kernel port
 with the following commit:
 
 https://svnweb.freebsd.org/ports?view=revisionrevision=386935

Will this make it into upstream Xen?

Lars


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Xen dom0 crash

[Roman Bogorodskiy]

  Roger Pau Monné wrote:

 El 18/05/15 a les 15.04, Eggert, Lars ha escrit:
  Hi,
  
  I'm trying to boot a Xen dom0 on another machine (Fujitsu RX308) and Xen 
  crashes when starting the kernel. Log below; any ideas?
  
  Thanks,
  Lars
  (XEN) [ Xen-4.6-unstable  x86_64  debug=y  Not tainted ]
  (XEN) CPU:0
  (XEN) RIP::[80854000]
  (XEN) RFLAGS: 0200   CONTEXT: hvm guest (d0v0)
  (XEN) rax:    rbx: 82d0802e8000   rcx: 82d0802eff80
  (XEN) rdx: 82d0801e1500   rsi:    rdi: 82d0801ed77c
  (XEN) rbp: 82d0801061d2   rsp: 81bb5000   r8:  83103ff0
  (XEN) r9:  82d08010623f   r10: 82d0802eff70   r11: 
  (XEN) r12: 82d0802eff50   r13: 831033ae7000   r14: 83103ff0
  (XEN) r15: 82d08018eae3   cr0: 8011   cr4: 0020
  (XEN) cr3: 01ba1000   cr2: 
  (XEN) ds:    es:    fs:    gs:    ss:    cs: 
  (XEN) Guest stack trace from rsp=81bb5000:
  (XEN)   Fault while accessing guest memory.
  (XEN) Hardware Dom0 crashed: rebooting machine in 5 seconds.
  (XEN) Resetting with ACPI MEMORY or I/O RESET_REG.
 
 Hello,
 
 This looks very similar to the crash reported at:
 
 https://lists.freebsd.org/pipermail/freebsd-xen/2015-April/002315.html
 
 Which was also reported at xen-devel, but nobody seems to have looked
 into it.
 
 Could you send a bug report to xen-devel with the following trace
 (please make sure to mention PVH in the subject line) CCing the Intel
 VT-X maintainers? (the emails are in the MAINTAINERS file in the Xen
 source tree).

H,

I'm observing a crash that looks similar to me:

(XEN) [ Xen-4.5.0  x86_64  debug=n  Not tainted ]
(XEN) CPU:0
(XEN) RIP:0020:[8034a2f3]
(XEN) RFLAGS: 00010246   CONTEXT: hvm guest
(XEN) rax: f800d887c1b0   rbx: f8000ed85100   rcx: 
(XEN) rdx: 81788560   rsi: 0008   rdi: f8000ed85100
(XEN) rbp: fe023956a850   rsp: fe023956a850   r8:  815056f8
(XEN) r9:  8178857c   r10: f8000ea9e0f0   r11: 81664200
(XEN) r12: 0004   r13: 80ee832b   r14: f8000ed85118
(XEN) r15: f8000ed85100   cr0: 8005003b   cr4: 000406e0
(XEN) cr3: 02cca000   cr2: 00080a8da140
(XEN) ds: 003b   es: 003b   fs: 0013   gs: 001b   ss: 0028   cs: 0020
(XEN) Guest stack trace from rsp=fe023956a850:
(XEN)   Fault while accessing guest memory.
(XEN) Domain 0 crashed: rebooting machine in 5 seconds.
(XEN) Resetting with ACPI MEMORY or I/O RESET_REG.

I'm wondering if it's related to the same issue?

It's triggered only when I try to reboot/poweroff the guest.

Roman Bogorodskiy



pgpMB7f3P5A43.pgp
Description: PGP signature

Re: Xen dom0 crash

[Roman Bogorodskiy]

  Roman Bogorodskiy wrote:

   Roger Pau Monné wrote:
 
  El 18/05/15 a les 15.04, Eggert, Lars ha escrit:
   Hi,
   
   I'm trying to boot a Xen dom0 on another machine (Fujitsu RX308) and Xen 
   crashes when starting the kernel. Log below; any ideas?
   
   Thanks,
   Lars
   (XEN) [ Xen-4.6-unstable  x86_64  debug=y  Not tainted ]
   (XEN) CPU:0
   (XEN) RIP::[80854000]
   (XEN) RFLAGS: 0200   CONTEXT: hvm guest (d0v0)
   (XEN) rax:    rbx: 82d0802e8000   rcx: 
   82d0802eff80
   (XEN) rdx: 82d0801e1500   rsi:    rdi: 
   82d0801ed77c
   (XEN) rbp: 82d0801061d2   rsp: 81bb5000   r8:  
   83103ff0
   (XEN) r9:  82d08010623f   r10: 82d0802eff70   r11: 
   
   (XEN) r12: 82d0802eff50   r13: 831033ae7000   r14: 
   83103ff0
   (XEN) r15: 82d08018eae3   cr0: 8011   cr4: 
   0020
   (XEN) cr3: 01ba1000   cr2: 
   (XEN) ds:    es:    fs:    gs:    ss:    cs: 
   (XEN) Guest stack trace from rsp=81bb5000:
   (XEN)   Fault while accessing guest memory.
   (XEN) Hardware Dom0 crashed: rebooting machine in 5 seconds.
   (XEN) Resetting with ACPI MEMORY or I/O RESET_REG.
  
  Hello,
  
  This looks very similar to the crash reported at:
  
  https://lists.freebsd.org/pipermail/freebsd-xen/2015-April/002315.html
  
  Which was also reported at xen-devel, but nobody seems to have looked
  into it.
  
  Could you send a bug report to xen-devel with the following trace
  (please make sure to mention PVH in the subject line) CCing the Intel
  VT-X maintainers? (the emails are in the MAINTAINERS file in the Xen
  source tree).
 
 H,
 
 I'm observing a crash that looks similar to me:
 
 (XEN) [ Xen-4.5.0  x86_64  debug=n  Not tainted ]
 (XEN) CPU:0
 (XEN) RIP:0020:[8034a2f3]
 (XEN) RFLAGS: 00010246   CONTEXT: hvm guest
 (XEN) rax: f800d887c1b0   rbx: f8000ed85100   rcx: 
 (XEN) rdx: 81788560   rsi: 0008   rdi: f8000ed85100
 (XEN) rbp: fe023956a850   rsp: fe023956a850   r8:  815056f8
 (XEN) r9:  8178857c   r10: f8000ea9e0f0   r11: 81664200
 (XEN) r12: 0004   r13: 80ee832b   r14: f8000ed85118
 (XEN) r15: f8000ed85100   cr0: 8005003b   cr4: 000406e0
 (XEN) cr3: 02cca000   cr2: 00080a8da140
 (XEN) ds: 003b   es: 003b   fs: 0013   gs: 001b   ss: 0028   cs: 0020
 (XEN) Guest stack trace from rsp=fe023956a850:
 (XEN)   Fault while accessing guest memory.
 (XEN) Domain 0 crashed: rebooting machine in 5 seconds.
 (XEN) Resetting with ACPI MEMORY or I/O RESET_REG.
 
 I'm wondering if it's related to the same issue?
 
 It's triggered only when I try to reboot/poweroff the guest.
 
 Roman Bogorodskiy

And the full log from guest start to crash:

https://dpaste.de/mWNu


Roman Bogorodskiy


pgpX3J5D6I0Rq.pgp
Description: PGP signature

Re: Xen dom0 crash

[Roger Pau Monné]

Hello,

El 22/05/15 a les 18.11, Roman Bogorodskiy ha escrit:
 H,
 
 I'm observing a crash that looks similar to me:
 
 (XEN) [ Xen-4.5.0  x86_64  debug=n  Not tainted ]
 (XEN) CPU:0
 (XEN) RIP:0020:[8034a2f3]
 (XEN) RFLAGS: 00010246   CONTEXT: hvm guest
 (XEN) rax: f800d887c1b0   rbx: f8000ed85100   rcx: 
 (XEN) rdx: 81788560   rsi: 0008   rdi: f8000ed85100
 (XEN) rbp: fe023956a850   rsp: fe023956a850   r8:  815056f8
 (XEN) r9:  8178857c   r10: f8000ea9e0f0   r11: 81664200
 (XEN) r12: 0004   r13: 80ee832b   r14: f8000ed85118
 (XEN) r15: f8000ed85100   cr0: 8005003b   cr4: 000406e0
 (XEN) cr3: 02cca000   cr2: 00080a8da140
 (XEN) ds: 003b   es: 003b   fs: 0013   gs: 001b   ss: 0028   cs: 0020
 (XEN) Guest stack trace from rsp=fe023956a850:
 (XEN)   Fault while accessing guest memory.
 (XEN) Domain 0 crashed: rebooting machine in 5 seconds.
 (XEN) Resetting with ACPI MEMORY or I/O RESET_REG.
 
 I'm wondering if it's related to the same issue?

The issue mentioned in this thread has been fixed in the xen-kernel port
with the following commit:

https://svnweb.freebsd.org/ports?view=revisionrevision=386935

Not sure if binary packages in pkg have been updated or not.

 It's triggered only when I try to reboot/poweroff the guest.

I'm not sure if it's the same issue.

In this case the crash happened when booting Dom0 (well even before
booting Dom0).

Can you please provide the full log (including Xen and FreeBSD boot
output)? With just this chunk it's impossible to guess what's going on.

Also, if I understand it correctly, the crash you are seeing happens
when trying to shutdown/reboot a running DomU?

Roger.
___
freebsd-xen@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to freebsd-xen-unsubscr...@freebsd.org

Re: Xen dom0 crash

[Roman Bogorodskiy]

  Roger Pau Monné wrote:

 El 22/05/15 a les 18.40, Roman Bogorodskiy ha escrit:
  No, the guest is:
  
  FreeBSD 10.0-RELEASE amd64.
  
  Here's dmesg.boot from dom0:
  
  https://dpaste.de/ey7Q
 
 I think I know what's going on, you are using a rather old kernel (from
 27/04/15) which doesn't contain r282634. Could you update your Dom0
 kernel to recent HEAD and try again?

That worked, thanks!

Roman Bogorodskiy


pgptElbXey3Lc.pgp
Description: PGP signature

Re: Xen dom0 interrupt storm detected on irq16:; throttling interrupt source

[Eggert, Lars]

On 2015-5-20, at 17:30, Roger Pau Monné roger@citrix.com wrote:
 
 Did you manage to get past this?
 
 TBH I don't know why Xen tries to build the tests, my build of tools
 doesn't even try to.

Yes, I think the issue was that I tried to build Xen 4.5-release. I'm now 
building master without problems.

Lars


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Xen dom0 interrupt storm detected on irq16:; throttling interrupt source

[Roger Pau Monné]

El 15/05/15 a les 14.06, Eggert, Lars ha escrit:
 On 2015-5-13, at 18:00, Eggert, Lars l...@netapp.com wrote:

 On 2015-5-13, at 16:46, Roger Pau Monné roger@citrix.com wrote:
 I guess migration-rdma gets compiled because Qemu detects that you have
 some library and assumes that you want it enabled. Did you install
 something new between your previous build of Xen and this one?

 Yes, this box has world built with OFED. I'll try on a more standard world 
 build Friday.
 
 Now building tools stops here:
 
 gmake[5]: Entering directory 
 '/usr/home/elars/src/xen/tools/tests/x86_emulator'
 [ -L x86_emulate ] || ln -sf 
 /usr/home/elars/src/xen/tools/tests/x86_emulator/../../../xen/arch/x86/x86_emulate
  .
 gcc47 -Wall -Werror -Wstrict-prototypes -O2 -fomit-frame-pointer 
 -fno-strict-aliasing -Wdeclaration-after-statement 
 -I/usr/home/elars/src/xen/tools/tests/x86_emulator/../../../tools/include -c 
 -g -o x86_emulate.o x86_emulate.c
 x86_emulate.c:17:0: error: __packed redefined [-Werror]
 In file included from /usr/include/assert.h:38:0,
  from x86_emulate.c:1:
 /usr/local/lib/gcc47/gcc/x86_64-portbld-freebsd11.0/4.7.4/include-fixed/sys/cdefs.h:244:0:
  note: this is the location of the previous definition
 cc1: all warnings being treated as errors
 Makefile:49: recipe for target 'x86_emulate.o' failed
 gmake[5]: *** [x86_emulate.o] Error 1
 gmake[5]: Leaving directory '/usr/home/elars/src/xen/tools/tests/x86_emulator'
 /usr/home/elars/src/xen/tools/tests/../../tools/Rules.mk:123: recipe for 
 target 'subdir-all-x86_emulator' failed
 gmake[4]: *** [subdir-all-x86_emulator] Error 2
 gmake[4]: Leaving directory '/usr/home/elars/src/xen/tools/tests'
 /usr/home/elars/src/xen/tools/tests/../../tools/Rules.mk:118: recipe for 
 target 'subdirs-all' failed
 gmake[3]: *** [subdirs-all] Error 2
 gmake[3]: Leaving directory '/usr/home/elars/src/xen/tools/tests'
 /usr/home/elars/src/xen/tools/../tools/Rules.mk:123: recipe for target 
 'subdir-all-tests' failed
 gmake[2]: *** [subdir-all-tests] Error 2
 gmake[2]: Leaving directory '/usr/home/elars/src/xen/tools'
 /usr/home/elars/src/xen/tools/../tools/Rules.mk:118: recipe for target 
 'subdirs-all' failed
 gmake[1]: *** [subdirs-all] Error 2
 gmake[1]: Leaving directory '/usr/home/elars/src/xen/tools'
 Makefile:53: recipe for target 'build-tools' failed
 gmake: *** [build-tools] Error 2

Did you manage to get past this?

TBH I don't know why Xen tries to build the tests, my build of tools
doesn't even try to.

Roger.

___
freebsd-xen@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to freebsd-xen-unsubscr...@freebsd.org

Re: Xen dom0 interrupt storm detected on irq16:; throttling interrupt source

[Eggert, Lars]

Unfortunately, the storm is still there with this patch.

On 2015-5-15, at 18:28, Roger Pau Monné roger@citrix.com wrote:
 
 El 15/05/15 a les 16.42, Eggert, Lars ha escrit:
 On 2015-5-15, at 16:35, Roger Pau Monné roger@citrix.com wrote:
 
 Yes, but I've realized that isci for example passes an uint32_t instead
 of an int, so it might be best to set it to 0.
 
 Here is what I see now:
 
 isci0: Intel(R) C600 Series Chipset SAS Controller (SATA mode) port 
 0x6000-0x60ff mem 0xde07c000-0xde07,0xddc0-0xddff irq 16 at 
 device 0.0 on pci10
 isci0: attempting to allocate 2 MSI-X vectors (2 supported)
 ISCI: isci-num_interrupts: 2 max_msix_messages: 2
 isci: 1:89 ISCI bus_alloc_resource failed
 
 The storm is still there.
 
 Yes, after looking at the code, isci really needs to check for the
 return value of pci_alloc_msix, because num_interrupts is not updated
 if the allocation fails. Following patch should hopefully fix it,
 please give it a try.
 
 Roger.
 ---
 diff --git a/sys/dev/isci/isci_interrupt.c b/sys/dev/isci/isci_interrupt.c
 index 52c64f7..f331f3c 100644
 --- a/sys/dev/isci/isci_interrupt.c
 +++ b/sys/dev/isci/isci_interrupt.c
 @@ -128,6 +128,7 @@ isci_interrupt_setup(struct isci_softc *isci)
   isci-controller_count;
   BOOL use_msix = FALSE;
   uint32_t force_legacy_interrupts = 0;
 + int rc;
 
   TUNABLE_INT_FETCH(hw.isci.force_legacy_interrupts,
   force_legacy_interrupts);
 @@ -136,8 +137,8 @@ isci_interrupt_setup(struct isci_softc *isci)
   pci_msix_count(isci-device) = max_msix_messages) {
 
   isci-num_interrupts = max_msix_messages;
 - pci_alloc_msix(isci-device, isci-num_interrupts);
 - if (isci-num_interrupts == max_msix_messages)
 + rc = pci_alloc_msix(isci-device, isci-num_interrupts);
 + if (rc == 0  isci-num_interrupts == max_msix_messages)
   use_msix = TRUE;
   }
 
 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Xen dom0 crash

[Roger Pau Monné]

El 18/05/15 a les 15.04, Eggert, Lars ha escrit:
 Hi,
 
 I'm trying to boot a Xen dom0 on another machine (Fujitsu RX308) and Xen 
 crashes when starting the kernel. Log below; any ideas?
 
 Thanks,
 Lars
 
 
 B2
   __      _ _
  |  | |  _ \ / |  __ \
  | |___ _ __ ___  ___ | |_) | (___ | |  | |
  |  ___| '__/ _ \/ _ \|  _  \___ \| |  | |
  | |   | | |  __/  __/| |_) |) | |__| |
  | |   | | |||| |  |
  |_|   |_|  \___|\___||/|_/|_/````
  s` `.---...--.```   -/
  +Welcome to FreeBSD   +4H+   .--` /y:`  +.
 /boot/kernel/cc_vegas.ko size 0x30d0 at 0x1068000:.:o  `+-
 Booting...el/cc_hd.ko size 0x2c00 at 0x106200   -/`   -o/
  Xen 4.6-unstabletcp.ko size 0x2f90 at 0x1065000  ::/sy+:.
 (XEN) Xen version 4.6-unstable (r...@netapp.com) (gcc47 (FreeBSD Ports 
 Collection) 4.7.4) debug=y Mon May 18 14:50:17 CEST 2015  
 :`
 (XEN) Latest ChangeSet:| `:  :`
 (XEN) Bootloader: FreeBSD Loader   |  /  /
 (XEN) Command line: dom0_mem=4096M dom0pvh=1 com1=115200,8n1 console=com1.
 (XEN) Video information:]ptions... |   --  -.
 (XEN)  VGA is text mode 80x25, font 8x16   |`:`  `:`
 (XEN)  VBE/DDC methods: none; EDID transfer time: 0 seconds   `--.
 (XEN)  EDID info not retrieved because no DDC retrieval method 
 detected=(XEN) Disc information:
 (XEN)  Found 0 MBR signatures
 (XEN)  Found 0 EDD information structures
 (XEN) Xen-e820 RAM map:+0x50db0 -
 (XEN)   - 0008b800 (usable)
 (XEN)  0008b800 - 000a (reserved)
 (XEN)  000e - 0010 (reserved)
 (XEN)  0010 - 7cb09000 (usable)
 (XEN)  7cb09000 - 7cb39000 (reserved)
 (XEN)  7cb39000 - 7cc52000 (ACPI data)
 (XEN)  7cc52000 - 7d4b (ACPI NVS)
 (XEN)  7d4b - 7eafb000 (reserved)
 (XEN)  7eafb000 - 7eafc000 (usable)
 (XEN)  7eafc000 - 7eb82000 (ACPI NVS)
 (XEN)  7eb82000 - 7f00 (usable)
 (XEN)  8000 - 9000 (reserved)
 (XEN)  fed1c000 - fed2 (reserved)
 (XEN)  ff00 - 0001 (reserved)
 (XEN)  0001 - 00208000 (usable)
 (XEN) ACPI: RSDP 000F04A0, 0024 (r2 FTS   )
 (XEN) ACPI: XSDT 7CB71090, 00A4 (r1 FTSD2939-B1  1072009 AMI 10013)
 (XEN) ACPI: FACP 7CB7FAA8, 010C (r5 FTSD2939-B1  1072009 AMI 10013)
 (XEN) ACPI: DSDT 7CB711C8, E8DD (r2 FTSD2939-B1  114 INTL 20091112)
 (XEN) ACPI: FACS 7D4A7080, 0040
 (XEN) ACPI: APIC 7CB7FBB8, 0294 (r3 FTSD2939-B1  1072009 AMI 10013)
 (XEN) ACPI: FPDT 7CB7FE50, 0044 (r1 FTSD2939-B1  1072009 AMI 10013)
 (XEN) ACPI: MCFG 7CB7FE98, 003C (r1 FTSOEMMCFG.  1072009 MSFT   97)
 (XEN) ACPI: SRAT 7CB7FED8, 0530 (r1 A M I  AMI SRAT1 AMI.0)
 (XEN) ACPI: SLIT 7CB80408, 0030 (r1 A M I  AMI SLIT0 AMI.0)
 (XEN) ACPI: HPET 7CB80438, 0038 (r1 FTSD2939-B1  1072009 AMI.5)
 (XEN) ACPI: PRAD 7CB80470, 00BE (r2 PRADID  PRADTID1 MSFT  301)
 (XEN) ACPI: SPMI 7CB80530, 0040 (r5 A M I   OEMSPMI0 AMI.0)
 (XEN) ACPI: SSDT 7CB80570, D0CB0 (r2  INTELCpuPm 4000 INTL 20051117)
 (XEN) ACPI: SPCR 7CC51220, 0050 (r1  A M I   APTIO4  1072009 AMI.5)
 (XEN) ACPI: EINJ 7CC51270, 0130 (r1AMI AMI EINJ0 0)
 (XEN) ACPI: ERST 7CC513A0, 0230 (r1  AMIER AMI ERST0 0)
 (XEN) ACPI: HEST 7CC515D0, 00A8 (r1AMI AMI HEST0 0)
 (XEN) ACPI: BERT 7CC51678, 0030 (r1AMI AMI BERT0 0)
 (XEN) ACPI: DMAR 7CC516A8, 0110 (r1 A M I   OEMDMAR1 INTL1)
 (XEN) System RAM: 131023MB (134167628kB)
 (XEN) SRAT: PXM 0 - APIC 0 - Node 0
 (XEN) SRAT: PXM 0 - APIC 1 - Node 0
 (XEN) SRAT: PXM 0 - APIC 2 - Node 0
 (XEN) SRAT: PXM 0 - APIC 3 - Node 0
 (XEN) SRAT: PXM 0 - APIC 4 - Node 0
 (XEN) SRAT: PXM 0 - APIC 5 - Node 0
 (XEN) SRAT: PXM 0 - APIC 6 - Node 0
 (XEN) SRAT: PXM 0 - APIC 7 - Node 0
 (XEN) SRAT: PXM 0 - APIC 8 - Node 0
 (XEN) SRAT: PXM 0 - APIC 9 - Node 0
 (XEN) SRAT: PXM 0 - APIC 16 - Node 0
 (XEN) SRAT: PXM 0 - APIC 17 - Node 0
 (XEN) SRAT: PXM 0 - APIC 18 - Node 0
 (XEN) SRAT: PXM 0 - APIC 19 - Node 0
 (XEN) SRAT: PXM 0 - APIC 20 - Node 0
 (XEN) SRAT: PXM 0 - APIC 21 - Node 0
 (XEN) SRAT: PXM 0 - APIC 22 - Node 0
 (XEN) SRAT: PXM 0 - APIC 23 - Node 0
 (XEN) SRAT: PXM 0 - APIC 24 - Node 0
 (XEN) SRAT: PXM 0 - APIC 25 - Node 0
 (XEN) SRAT: PXM 1 - APIC 32 - Node 1
 (XEN) SRAT: PXM 1 - APIC 33 - Node 

Re: Xen dom0 interrupt storm detected on irq16:; throttling interrupt source

[Roger Pau Monné]

El 18/05/15 a les 15.01, Eggert, Lars ha escrit:
 Unfortunately, the storm is still there with this patch.

I guess you will have to resort to using
hw.isci.force_legacy_interrupts=1 until I get around to implement MSI-X
support for Xen Dom0, sorry for the trouble.

Roger.

___
freebsd-xen@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to freebsd-xen-unsubscr...@freebsd.org

Re: Xen dom0 interrupt storm detected on irq16:; throttling interrupt source

[Eggert, Lars]

On 2015-5-18, at 15:39, Roger Pau Monné roger@citrix.com wrote:
 I guess you will have to resort to using
 hw.isci.force_legacy_interrupts=1 until I get around to implement MSI-X
 support for Xen Dom0, sorry for the trouble.

No worries, that's a fine workaround.

Thanks for all the help!

Lars


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Xen dom0 interrupt storm detected on irq16:; throttling interrupt source

[Eggert, Lars]

On 2015-5-13, at 18:00, Eggert, Lars l...@netapp.com wrote:
 
 On 2015-5-13, at 16:46, Roger Pau Monné roger@citrix.com wrote:
 I guess migration-rdma gets compiled because Qemu detects that you have
 some library and assumes that you want it enabled. Did you install
 something new between your previous build of Xen and this one?
 
 Yes, this box has world built with OFED. I'll try on a more standard world 
 build Friday.

Now building tools stops here:

gmake[5]: Entering directory '/usr/home/elars/src/xen/tools/tests/x86_emulator'
[ -L x86_emulate ] || ln -sf 
/usr/home/elars/src/xen/tools/tests/x86_emulator/../../../xen/arch/x86/x86_emulate
 .
gcc47 -Wall -Werror -Wstrict-prototypes -O2 -fomit-frame-pointer 
-fno-strict-aliasing -Wdeclaration-after-statement 
-I/usr/home/elars/src/xen/tools/tests/x86_emulator/../../../tools/include -c -g 
-o x86_emulate.o x86_emulate.c
x86_emulate.c:17:0: error: __packed redefined [-Werror]
In file included from /usr/include/assert.h:38:0,
 from x86_emulate.c:1:
/usr/local/lib/gcc47/gcc/x86_64-portbld-freebsd11.0/4.7.4/include-fixed/sys/cdefs.h:244:0:
 note: this is the location of the previous definition
cc1: all warnings being treated as errors
Makefile:49: recipe for target 'x86_emulate.o' failed
gmake[5]: *** [x86_emulate.o] Error 1
gmake[5]: Leaving directory '/usr/home/elars/src/xen/tools/tests/x86_emulator'
/usr/home/elars/src/xen/tools/tests/../../tools/Rules.mk:123: recipe for target 
'subdir-all-x86_emulator' failed
gmake[4]: *** [subdir-all-x86_emulator] Error 2
gmake[4]: Leaving directory '/usr/home/elars/src/xen/tools/tests'
/usr/home/elars/src/xen/tools/tests/../../tools/Rules.mk:118: recipe for target 
'subdirs-all' failed
gmake[3]: *** [subdirs-all] Error 2
gmake[3]: Leaving directory '/usr/home/elars/src/xen/tools/tests'
/usr/home/elars/src/xen/tools/../tools/Rules.mk:123: recipe for target 
'subdir-all-tests' failed
gmake[2]: *** [subdir-all-tests] Error 2
gmake[2]: Leaving directory '/usr/home/elars/src/xen/tools'
/usr/home/elars/src/xen/tools/../tools/Rules.mk:118: recipe for target 
'subdirs-all' failed
gmake[1]: *** [subdirs-all] Error 2
gmake[1]: Leaving directory '/usr/home/elars/src/xen/tools'
Makefile:53: recipe for target 'build-tools' failed
gmake: *** [build-tools] Error 2

Lars


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Xen dom0 interrupt storm detected on irq16:; throttling interrupt source

[Eggert, Lars]

On 2015-5-15, at 13:59, Roger Pau Monné roger@citrix.com wrote:
 Can you provide the bootlog with the patch applied?

Below.

 Also, can you try if there's any difference when setting:
 hw.isci.force_legacy_interrupts=1
 on /boot/loader.conf?

That seems to elimintate the storm. The isci line is now simply:

isci0: Intel(R) C600 Series Chipset SAS Controller (SATA mode) port 
0x6000-0x60ff mem 0xde07c000-0xde07,0xddc0-0xddff irq 16 at device 
0.0 on pci10

Lars



 B2
  __      _ _
 |  | |  _ \ / |  __ \
 | |___ _ __ ___  ___ | |_) | (___ | |  | |
 |  ___| '__/ _ \/ _ \|  _  \___ \| |  | |
 | |   | | |  __/  __/| |_) |) | |__| |
 | |   | | |||| |  |  |
 |_|   |_|  \___|\___||/|_/|_/````
 s` `.---...--.```   -/
 +Welcome to FreeBSD===+ +o   .--` /y:`  +.
 | |  yo`:.:o  `+-
/boot/kernel/cc_vegas.ko size 0x30d0 at 0x1062000   -/`   -o/
Booting...el/cc_hd.ko size 0x2c00 at 0x105c-  ::/sy+:.
 Xen 4.6-unstabletcp.ko size 0x2f90 at 0x105f   `--  /
(XEN) Xen version 4.6-unstable (el...@netapp.com) (gcc47 (FreeBSD Ports 
Collection) 4.7.4) debug=y Fri May 15 13:39:38 CEST 2015
(XEN) Latest ChangeSet:| `:  :`
(XEN) Bootloader: FreeBSD Loader   |  /  /
(XEN) Command line: dom0_mem=4096M dom0pvh=1 com1=115200,8n1 console=com1.
(XEN) Video information:]ptions... |   --  -.
(XEN)  VGA is text mode 80x25, font 8x16   |`:`  `:`
(XEN)  VBE/DDC methods: none; EDID transfer time: 0 seconds   `--.
(XEN)  EDID info not retrieved because no DDC retrieval method detected
(XEN) Disc information:+
(XEN)  Found 1 MBR signatures
(XEN)  Found 1 EDD information structures
(XEN) Xen-e820 RAM map:+0x50db0 -
(XEN)   - 0009ac00 (usable)
(XEN)  0009ac00 - 000a (reserved)
(XEN)  000e - 0010 (reserved)
(XEN)  0010 - 7de19000 (usable)
(XEN)  7de19000 - 7dea8000 (reserved)
(XEN)  7dea8000 - 7dfb1000 (ACPI data)
(XEN)  7dfb1000 - 7e1cb000 (ACPI NVS)
(XEN)  7e1cb000 - 7f355000 (reserved)
(XEN)  7f355000 - 7f80 (ACPI NVS)
(XEN)  8000 - 9000 (reserved)
(XEN)  fed1c000 - fed4 (reserved)
(XEN)  ff00 - 0001 (reserved)
(XEN)  0001 - 00208000 (usable)
(XEN) ACPI: RSDP 000F04A0, 0024 (r2 SUPERM)
(XEN) ACPI: XSDT 7DEDD090, 009C (r1 SUPERM SMCI--MB1 AMI 10013)
(XEN) ACPI: FACP 7DEE8110, 00F4 (r4 SUPERM SMCI--MB1 AMI 10013)
(XEN) ACPI: DSDT 7DEDD1B8, AF53 (r2 SUPERM SMCI--MB0 INTL 20091112)
(XEN) ACPI: FACS 7E1C2080, 0040
(XEN) ACPI: APIC 7DEE8208, 0224 (r31 AMI 10013)
(XEN) ACPI: FPDT 7DEE8430, 0044 (r11 AMI 10013)
(XEN) ACPI: SRAT 7DEE8478, 04B0 (r1 A M I  AMI SRAT1 AMI.0)
(XEN) ACPI: SLIT 7DEE8928, 0030 (r1 A M I  AMI SLIT0 AMI.0)
(XEN) ACPI: HPET 7DEE8958, 0038 (r1 SUPERM SMCI--MB1 AMI.5)
(XEN) ACPI: PRAD 7DEE8990, 00BE (r2 PRADID  PRADTID1 MSFT  400)
(XEN) ACPI: SPMI 7DEE8A50, 0040 (r5 A M I   OEMSPMI0 AMI.0)
(XEN) ACPI: SSDT 7DEE8A90, C7AE8 (r2  INTELCpuPm 4000 INTL 20091112)
(XEN) ACPI: EINJ 7DFB0578, 0130 (r1AMI AMI EINJ0 0)
(XEN) ACPI: ERST 7DFB06A8, 0230 (r1  AMIER AMI ERST0 0)
(XEN) ACPI: HEST 7DFB08D8, 00A8 (r1AMI AMI HEST0 0)
(XEN) ACPI: BERT 7DFB0980, 0030 (r1AMI AMI BERT0 0)
(XEN) ACPI: DMAR 7DFB09B0, 0168 (r1 A M I   OEMDMAR1 INTL1)
(XEN) ACPI: MCFG 7DFB0B18, 003C (r1 SUPERM SMCI--MB1 MSFT   97)
(XEN) System RAM: 131037MB (134182604kB)
(XEN) SRAT: PXM 0 - APIC 0 - Node 0
(XEN) SRAT: PXM 0 - APIC 1 - Node 0
(XEN) SRAT: PXM 0 - APIC 2 - Node 0
(XEN) SRAT: PXM 0 - APIC 3 - Node 0
(XEN) SRAT: PXM 0 - APIC 4 - Node 0
(XEN) SRAT: PXM 0 - APIC 5 - Node 0
(XEN) SRAT: PXM 0 - APIC 6 - Node 0
(XEN) SRAT: PXM 0 - APIC 7 - Node 0
(XEN) SRAT: PXM 0 - APIC 8 - Node 0
(XEN) SRAT: PXM 0 - APIC 9 - Node 0
(XEN) SRAT: PXM 0 - APIC 10 - Node 0
(XEN) SRAT: PXM 0 - APIC 11 - Node 0
(XEN) SRAT: PXM 0 - APIC 12 - Node 0
(XEN) SRAT: PXM 0 - APIC 13 - Node 0
(XEN) SRAT: PXM 0 - APIC 14 - Node 0
(XEN) SRAT: PXM 0 - APIC 15 - Node 0
(XEN) SRAT: PXM 1 - APIC 32 - Node 1
(XEN) SRAT: PXM 1 - APIC 33 - Node 1
(XEN) SRAT: PXM 1 - APIC 34 - Node 1
(XEN) SRAT: PXM 1 - APIC 35 - Node 1
(XEN) SRAT: 

Re: Xen dom0 interrupt storm detected on irq16:; throttling interrupt source

[Roger Pau Monné]

El 15/05/15 a les 13.53, Eggert, Lars ha escrit:
 On 2015-5-13, at 16:52, Roger Pau Monné roger@citrix.com wrote:
 I have a patch for FreeBSD which
 might solve it, however I don't have any similar box I can use to test
 it, would you mind giving it a spin?
 
 Unfortunately, the irq storm is still present with that patch applied.

Can you provide the bootlog with the patch applied?

Also, can you try if there's any difference when setting:

hw.isci.force_legacy_interrupts=1

on /boot/loader.conf?

Thanks, Roger.
___
freebsd-xen@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to freebsd-xen-unsubscr...@freebsd.org

Re: Xen dom0 interrupt storm detected on irq16:; throttling interrupt source

[Eggert, Lars]

On 2015-5-13, at 16:52, Roger Pau Monné roger@citrix.com wrote:
 I have a patch for FreeBSD which
 might solve it, however I don't have any similar box I can use to test
 it, would you mind giving it a spin?

Unfortunately, the irq storm is still present with that patch applied.

Lars


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Xen dom0 interrupt storm detected on irq16:; throttling interrupt source

[Eggert, Lars]

On 2015-5-15, at 16:42, Eggert, Lars l...@netapp.com wrote:
 
 Will now set hw.isci.force_legacy_interrupts=1 and check if the device then 
 works correctly.

That seems to be the case.

Lars


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Xen dom0 interrupt storm detected on irq16:; throttling interrupt source

[Roger Pau Monné]

El 15/05/15 a les 16.30, Eggert, Lars ha escrit:
 On 2015-5-15, at 16:14, Roger Pau Monné roger@citrix.com wrote:
 I've attached another patch that will force isci to print some
 messages, can you try that?
 
 Trying this now.
 
 +*irq = 0;
 
 FWIW, this was *irq = -1 in your previous patch...

Yes, but I've realized that isci for example passes an uint32_t instead
of an int, so it might be best to set it to 0.

Roger.

___
freebsd-xen@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to freebsd-xen-unsubscr...@freebsd.org

Re: Xen dom0 interrupt storm detected on irq16:; throttling interrupt source

[Eggert, Lars]

On 2015-5-15, at 16:14, Roger Pau Monné roger@citrix.com wrote:
 I've attached another patch that will force isci to print some
 messages, can you try that?

Trying this now.

 + *irq = 0;

FWIW, this was *irq = -1 in your previous patch...

Lars



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Xen dom0 interrupt storm detected on irq16:; throttling interrupt source

[Eggert, Lars]

On 2015-5-15, at 16:35, Roger Pau Monné roger@citrix.com wrote:
 
 Yes, but I've realized that isci for example passes an uint32_t instead
 of an int, so it might be best to set it to 0.

Here is what I see now:

isci0: Intel(R) C600 Series Chipset SAS Controller (SATA mode) port 
0x6000-0x60ff mem 0xde07c000-0xde07,0xddc0-0xddff irq 16 at device 
0.0 on pci10
isci0: attempting to allocate 2 MSI-X vectors (2 supported)
ISCI: isci-num_interrupts: 2 max_msix_messages: 2
isci: 1:89 ISCI bus_alloc_resource failed

The storm is still there.

Will now set hw.isci.force_legacy_interrupts=1 and check if the device then 
works correctly.

Lars


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Xen dom0 interrupt storm detected on irq16:; throttling interrupt source

[Roger Pau Monné]

El 15/05/15 a les 16.42, Eggert, Lars ha escrit:
 On 2015-5-15, at 16:35, Roger Pau Monné roger@citrix.com wrote:

 Yes, but I've realized that isci for example passes an uint32_t instead
 of an int, so it might be best to set it to 0.
 
 Here is what I see now:
 
 isci0: Intel(R) C600 Series Chipset SAS Controller (SATA mode) port 
 0x6000-0x60ff mem 0xde07c000-0xde07,0xddc0-0xddff irq 16 at 
 device 0.0 on pci10
 isci0: attempting to allocate 2 MSI-X vectors (2 supported)
 ISCI: isci-num_interrupts: 2 max_msix_messages: 2
 isci: 1:89 ISCI bus_alloc_resource failed
 
 The storm is still there.

Yes, after looking at the code, isci really needs to check for the 
return value of pci_alloc_msix, because num_interrupts is not updated 
if the allocation fails. Following patch should hopefully fix it, 
please give it a try.

Roger.
---
diff --git a/sys/dev/isci/isci_interrupt.c b/sys/dev/isci/isci_interrupt.c
index 52c64f7..f331f3c 100644
--- a/sys/dev/isci/isci_interrupt.c
+++ b/sys/dev/isci/isci_interrupt.c
@@ -128,6 +128,7 @@ isci_interrupt_setup(struct isci_softc *isci)
isci-controller_count;
BOOL use_msix = FALSE;
uint32_t force_legacy_interrupts = 0;
+   int rc;
 
TUNABLE_INT_FETCH(hw.isci.force_legacy_interrupts,
force_legacy_interrupts);
@@ -136,8 +137,8 @@ isci_interrupt_setup(struct isci_softc *isci)
pci_msix_count(isci-device) = max_msix_messages) {
 
isci-num_interrupts = max_msix_messages;
-   pci_alloc_msix(isci-device, isci-num_interrupts);
-   if (isci-num_interrupts == max_msix_messages)
+   rc = pci_alloc_msix(isci-device, isci-num_interrupts);
+   if (rc == 0  isci-num_interrupts == max_msix_messages)
use_msix = TRUE;
}
 

___
freebsd-xen@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to freebsd-xen-unsubscr...@freebsd.org

Re: Xen dom0 interrupt storm detected on irq16:; throttling interrupt source

[Roger Pau Monné]

Hello,

El 13/05/15 a les 10.20, Eggert, Lars ha escrit:
 Hi,
 
 with Xen from git and a recent -CURRENT, I get interrupt storm detected on 
 irq16:; throttling interrupt source messages on the dom0 console about 
 once a second. irq16 is used for ehci:
 
 # vmstat -i | grep irq16
 irq16: ehci0 1229805   6559
 
 Any ideas?

Can you post the full output of vmstat -i and the log of Xen and FreeBSD
booting (with boot_verbose=YES)? If you don't have a serial console
setup you can get the Xen boot log using xl dmesg.

Roger.
___
freebsd-xen@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to freebsd-xen-unsubscr...@freebsd.org

Re: Xen dom0 interrupt storm detected on irq16:; throttling interrupt source

[Roger Pau Monné]

Hello,

El 13/05/15 a les 16.40, Eggert, Lars ha escrit:
 Also, building the xen tools currently seems to fail with:
 
 gmake[3]: Entering directory '/usr/home/elars/xen/tools/qemu-xen-dir-remote'
   GEN   config-host.h
   GEN   trace/generated-tracers.h
   GEN   trace/generated-tcg-tracers.h
   GEN   trace/generated-helpers-wrappers.h
   GEN   trace/generated-helpers.h
   CCqapi-types.o
   CCqapi-visit.o
   CCqapi-event.o
   CCtrace/generated-events.o
   ARlibqemuutil.a
   ARlibqemustub.a
   LINK  qemu-nbd
   CCqemu-img.o
   LINK  qemu-img
   LINK  qemu-io
   CCmigration-rdma.o
 migration-rdma.c: In function 'qemu_rdma_broken_ipv6_kernel':
 migration-rdma.c:795:26: warning: unused variable 'port_attr' 
 [-Wunused-variable]
 migration-rdma.c: In function 'qemu_rdma_resolve_host':
 migration-rdma.c:912:5: warning: implicit declaration of function 
 'rdma_getaddrinfo' [-Wimplicit-function-declaration]
 migration-rdma.c:912:5: warning: nested extern declaration of 
 'rdma_getaddrinfo' [-Wnested-externs]
 migration-rdma.c:918:35: error: dereferencing pointer to incomplete type
 migration-rdma.c:919:20: error: dereferencing pointer to incomplete type
 migration-rdma.c:920:39: error: dereferencing pointer to incomplete type
 migration-rdma.c:923:53: error: dereferencing pointer to incomplete type
 migration-rdma.c:926:18: error: dereferencing pointer to incomplete type
 migration-rdma.c: In function 'qemu_rdma_dest_init':
 migration-rdma.c:2456:39: error: dereferencing pointer to incomplete type
 migration-rdma.c:2457:24: error: dereferencing pointer to incomplete type
 migration-rdma.c:2458:43: error: dereferencing pointer to incomplete type
 migration-rdma.c:2460:46: error: dereferencing pointer to incomplete type
 migration-rdma.c:2462:22: error: dereferencing pointer to incomplete type
 /usr/home/elars/xen/tools/qemu-xen-dir/rules.mak:57: recipe for target 
 'migration-rdma.o' failed
 gmake[3]: *** [migration-rdma.o] Error 1
 gmake[3]: Leaving directory '/usr/home/elars/xen/tools/qemu-xen-dir-remote'
 Makefile:201: recipe for target 'subdir-all-qemu-xen-dir' failed
 gmake[2]: *** [subdir-all-qemu-xen-dir] Error 2
 gmake[2]: Leaving directory '/usr/home/elars/xen/tools'
 /usr/home/elars/xen/tools/../tools/Rules.mk:111: recipe for target 
 'subdirs-install' failed
 gmake[1]: *** [subdirs-install] Error 2
 gmake[1]: Leaving directory '/usr/home/elars/xen/tools'
 Makefile:69: recipe for target 'install-tools' failed
 gmake: *** [install-tools] Error 2

I guess migration-rdma gets compiled because Qemu detects that you have
some library and assumes that you want it enabled. Did you install
something new between your previous build of Xen and this one?

Roger.

___
freebsd-xen@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to freebsd-xen-unsubscr...@freebsd.org

Re: Xen dom0 interrupt storm detected on irq16:; throttling interrupt source

[Roger Pau Monné]

El 13/05/15 a les 15.48, Eggert, Lars ha escrit:
 isci0: Intel(R) C600 Series Chipset SAS Controller (SATA mode) port 
 0x6000-0x60ff mem 0xde07c000-0xde07,0xddc0-0xddff irq 16 at 
 device 0.0 on pci10
 isci0: attempting to allocate 2 MSI-X vectors (2 supported)
 isci: 1:89 ISCI bus_alloc_resource failed

This device is sharing the same IRQ#16 with ehci0, and I have a feeling 
it's not properly setting up it's interrupt sources. First, FreeBSD 
Dom0 still doesn't support MSI-X (only MSI), but isci doesn't check the 
errors returned by pci_alloc_msix. I have a patch for FreeBSD which 
might solve it, however I don't have any similar box I can use to test 
it, would you mind giving it a spin?

Thanks, Roger.

---
diff --git a/sys/x86/xen/xen_msi.c b/sys/x86/xen/xen_msi.c
index 0f678b1..181b956 100644
--- a/sys/x86/xen/xen_msi.c
+++ b/sys/x86/xen/xen_msi.c
@@ -114,6 +114,7 @@ int
 xen_msix_alloc(device_t dev, int *irq)
 {
 
+   *irq = -1;
return (ENXIO);
 }
 

___
freebsd-xen@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to freebsd-xen-unsubscr...@freebsd.org

Re: Xen dom0 interrupt storm detected on irq16:; throttling interrupt source

[Eggert, Lars]

On 2015-5-13, at 10:54, Roger Pau Monné roger@citrix.com wrote:
 Can you post the full output of vmstat -i and the log of Xen and FreeBSD
 booting (with boot_verbose=YES)? If you don't have a serial console
 setup you can get the Xen boot log using xl dmesg.

Here you go:

Xen 4.6-unstabletcp.ko size 0x2f90 at 0xfc6``
(XEN) Xen version 4.6-unstable (el...@netapp.com) (gcc47 (FreeBSD Ports 
Collection) 4.7.4) debug=y Tue May 12 09:31:08 CEST 2015.el/cc_hd.ko size 
0x2c00 at 0xfc3o   .--` /y:`  +.
(XEN) Latest ChangeSet: Fri Apr 10 11:26:18 2015 -0400 git:123c779 `+-
(XEN) Bootloader: FreeBSD Loader   |   y/   -/`   -o/
(XEN) Command line: dom0_mem=4096M dom0pvh=1 com1=115200,8n1 console=com1.
(XEN) Video information:r prompt   |  / `--  /
(XEN)  VGA is text mode 80x25, font 8x16   | `:  :`
(XEN)  VBE/DDC methods: none; EDID transfer time: 0 seconds  :`
(XEN)  EDID info not retrieved because no DDC retrieval method detected  /
(XEN) Disc information: (1 of 2)   |  .--.
(XEN)  Found 1 MBR signaturesns... |   --  -.
(XEN)  Found 1 EDD information structures  |`:`  `:`
(XEN) Xen-e820 RAM map:|  .-- `--.
(XEN)   - 0009ac00 (usable)  .---..
(XEN)  0009ac00 - 000a (reserved)
(XEN)  000e - 0010 (reserved)
(XEN)  0010 - 7de19000 (usable)
(XEN)  7de19000 - 7dea8000 (reserved)
(XEN)  7dea8000 - 7dfb1000 (ACPI data)
(XEN)  7dfb1000 - 7e1cb000 (ACPI NVS)
(XEN)  7e1cb000 - 7f355000 (reserved)
(XEN)  7f355000 - 7f80 (ACPI NVS)
(XEN)  8000 - 9000 (reserved)
(XEN)  fed1c000 - fed4 (reserved)
(XEN)  ff00 - 0001 (reserved)
(XEN)  0001 - 00208000 (usable)
(XEN) ACPI: RSDP 000F04A0, 0024 (r2 SUPERM)
(XEN) ACPI: XSDT 7DEDD090, 009C (r1 SUPERM SMCI--MB1 AMI 10013)
(XEN) ACPI: FACP 7DEE8110, 00F4 (r4 SUPERM SMCI--MB1 AMI 10013)
(XEN) ACPI: DSDT 7DEDD1B8, AF53 (r2 SUPERM SMCI--MB0 INTL 20091112)
(XEN) ACPI: FACS 7E1C2080, 0040
(XEN) ACPI: APIC 7DEE8208, 0224 (r31 AMI 10013)
(XEN) ACPI: FPDT 7DEE8430, 0044 (r11 AMI 10013)
(XEN) ACPI: SRAT 7DEE8478, 04B0 (r1 A M I  AMI SRAT1 AMI.0)
(XEN) ACPI: SLIT 7DEE8928, 0030 (r1 A M I  AMI SLIT0 AMI.0)
(XEN) ACPI: HPET 7DEE8958, 0038 (r1 SUPERM SMCI--MB1 AMI.5)
(XEN) ACPI: PRAD 7DEE8990, 00BE (r2 PRADID  PRADTID1 MSFT  400)
(XEN) ACPI: SPMI 7DEE8A50, 0040 (r5 A M I   OEMSPMI0 AMI.0)
(XEN) ACPI: SSDT 7DEE8A90, C7AE8 (r2  INTELCpuPm 4000 INTL 20091112)
(XEN) ACPI: EINJ 7DFB0578, 0130 (r1AMI AMI EINJ0 0)
(XEN) ACPI: ERST 7DFB06A8, 0230 (r1  AMIER AMI ERST0 0)
(XEN) ACPI: HEST 7DFB08D8, 00A8 (r1AMI AMI HEST0 0)
(XEN) ACPI: BERT 7DFB0980, 0030 (r1AMI AMI BERT0 0)
(XEN) ACPI: DMAR 7DFB09B0, 0168 (r1 A M I   OEMDMAR1 INTL1)
(XEN) ACPI: MCFG 7DFB0B18, 003C (r1 SUPERM SMCI--MB1 MSFT   97)
(XEN) System RAM: 131037MB (134182604kB)
(XEN) SRAT: PXM 0 - APIC 0 - Node 0
(XEN) SRAT: PXM 0 - APIC 1 - Node 0
(XEN) SRAT: PXM 0 - APIC 2 - Node 0
(XEN) SRAT: PXM 0 - APIC 3 - Node 0
(XEN) SRAT: PXM 0 - APIC 4 - Node 0
(XEN) SRAT: PXM 0 - APIC 5 - Node 0
(XEN) SRAT: PXM 0 - APIC 6 - Node 0
(XEN) SRAT: PXM 0 - APIC 7 - Node 0
(XEN) SRAT: PXM 0 - APIC 8 - Node 0
(XEN) SRAT: PXM 0 - APIC 9 - Node 0
(XEN) SRAT: PXM 0 - APIC 10 - Node 0
(XEN) SRAT: PXM 0 - APIC 11 - Node 0
(XEN) SRAT: PXM 0 - APIC 12 - Node 0
(XEN) SRAT: PXM 0 - APIC 13 - Node 0
(XEN) SRAT: PXM 0 - APIC 14 - Node 0
(XEN) SRAT: PXM 0 - APIC 15 - Node 0
(XEN) SRAT: PXM 1 - APIC 32 - Node 1
(XEN) SRAT: PXM 1 - APIC 33 - Node 1
(XEN) SRAT: PXM 1 - APIC 34 - Node 1
(XEN) SRAT: PXM 1 - APIC 35 - Node 1
(XEN) SRAT: PXM 1 - APIC 36 - Node 1
(XEN) SRAT: PXM 1 - APIC 37 - Node 1
(XEN) SRAT: PXM 1 - APIC 38 - Node 1
(XEN) SRAT: PXM 1 - APIC 39 - Node 1
(XEN) SRAT: PXM 1 - APIC 40 - Node 1
(XEN) SRAT: PXM 1 - APIC 41 - Node 1
(XEN) SRAT: PXM 1 - APIC 42 - Node 1
(XEN) SRAT: PXM 1 - APIC 43 - Node 1
(XEN) SRAT: PXM 1 - APIC 44 - Node 1
(XEN) SRAT: PXM 1 - APIC 45 - Node 1
(XEN) SRAT: PXM 1 - APIC 46 - Node 1
(XEN) SRAT: PXM 1 - APIC 47 - Node 1
(XEN) SRAT: Node 0 PXM 0 0-8000
(XEN) SRAT: Node 0 PXM 0 1-108000
(XEN) SRAT: Node 1 PXM 1 108000-208000
(XEN) NUMA: Allocated memnodemap from 207f3d2000 - 207f3d3000
(XEN) NUMA: Using 19 for the hash shift.
(XEN) Domain heap initialised DMA width 32 bits
(XEN) found SMP MP-table at 000fdc30
(XEN) DMI 2.7 

Re: Xen dom0 interrupt storm detected on irq16:; throttling interrupt source

[Eggert, Lars]

I'll test Friday, thanks.

On 2015-5-13, at 16:52, Roger Pau Monné roger@citrix.com wrote:
 
 El 13/05/15 a les 15.48, Eggert, Lars ha escrit:
 isci0: Intel(R) C600 Series Chipset SAS Controller (SATA mode) port 
 0x6000-0x60ff mem 0xde07c000-0xde07,0xddc0-0xddff irq 16 at 
 device 0.0 on pci10
 isci0: attempting to allocate 2 MSI-X vectors (2 supported)
 isci: 1:89 ISCI bus_alloc_resource failed
 
 This device is sharing the same IRQ#16 with ehci0, and I have a feeling
 it's not properly setting up it's interrupt sources. First, FreeBSD
 Dom0 still doesn't support MSI-X (only MSI), but isci doesn't check the
 errors returned by pci_alloc_msix. I have a patch for FreeBSD which
 might solve it, however I don't have any similar box I can use to test
 it, would you mind giving it a spin?
 
 Thanks, Roger.
 
 ---
 diff --git a/sys/x86/xen/xen_msi.c b/sys/x86/xen/xen_msi.c
 index 0f678b1..181b956 100644
 --- a/sys/x86/xen/xen_msi.c
 +++ b/sys/x86/xen/xen_msi.c
 @@ -114,6 +114,7 @@ int
 xen_msix_alloc(device_t dev, int *irq)
 {
 
 + *irq = -1;
   return (ENXIO);
 }
 
 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Xen dom0 interrupt storm detected on irq16:; throttling interrupt source

[Eggert, Lars]

On 2015-5-13, at 16:46, Roger Pau Monné roger@citrix.com wrote:
 I guess migration-rdma gets compiled because Qemu detects that you have
 some library and assumes that you want it enabled. Did you install
 something new between your previous build of Xen and this one?

Yes, this box has world built with OFED. I'll try on a more standard world 
build Friday.

(I hadn't previously tried to build tools; was using the pkg but that caused 
errors, probably due to version incompatibility.)

Lars


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Xen dom0 interrupt storm detected on irq16:; throttling interrupt source

[Roger Pau Monné]

El 13/05/15 a les 18.00, Eggert, Lars ha escrit:
 On 2015-5-13, at 16:46, Roger Pau Monné roger@citrix.com wrote:
 I guess migration-rdma gets compiled because Qemu detects that you have
 some library and assumes that you want it enabled. Did you install
 something new between your previous build of Xen and this one?
 
 Yes, this box has world built with OFED. I'll try on a more standard world 
 build Friday.
 
 (I hadn't previously tried to build tools; was using the pkg but that caused 
 errors, probably due to version incompatibility.)

Yes, Xen kernel and tools need to be build with the same exact version.

Roger.

___
freebsd-xen@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to freebsd-xen-unsubscr...@freebsd.org

Re: Xen PV Networking issue - disable PV NIC in XENHVM FreeBSD?

[Douglas Haber]

I am running into similar issues routing traffic through a pfSense VM 
running FreeBSD 10.1. There has to be something with the xn driver or 
related causing it, as re worked flawlessly.


Put together a thread here..

https://forum.pfsense.org/index.php?topic=86827.0;all

--

Douglas Haber
Managing Member
Garden State Computing, LLC
Tel: (973) 636-7350
www.gardenstatecomputing.com
supp...@gardenstatecomputing.com

___
freebsd-xen@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to freebsd-xen-unsubscr...@freebsd.org

Re: Xen/HVM support in stable/9: GENERIC + xenhvm.ko

[Mark Felder]

On May 16, 2014, at 14:29, Colin Percival cperc...@freebsd.org wrote:

 Hi all,
 
 As of r266269, stable/9 can run in Xen/HVM environments using the GENERIC
 kernel configuration plus a new xenhvm.ko.  This will allow FreeBSD 9.3 to
 run in Xen using official release binaries as long as xenhvm_load=YES
 is placed in /boot/loader.conf.
 


This is FANTASTIC news! I will begin testing as time permits...

:-)

___
freebsd-xen@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to freebsd-xen-unsubscr...@freebsd.org

Re: Xen PV Networking issue - disable PV NIC in XENHVM FreeBSD?

[Karl Pielorz]

--On 17 February 2014 09:46 + Karl Pielorz kpielorz_...@tdx.co.uk 
wrote:



  ifconfig xnX -rxcsum -txcsum

Does actually fix the problem.


Sadly this doesn't. It seems my testing was flawed (unknownly from a VM on 
another XenServer - which never exhibited the problem).


Real users today noticed the issue (trying to connect out from VM's on the 
same XenServer as the default gateway FreeBSD VM).


As replacing that VM with a CentOS PV host fixes the issue, it must be a 
bug within the FreeBSD PV NIC code somewhere?


[I posted a followup post to xs-devel as well, incase anyone else stumbles 
into the issue and things the rxcsum thing will fix it].


-Karl
___
freebsd-xen@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to freebsd-xen-unsubscr...@freebsd.org