***
(XEN) Panic on CPU 1:
(XEN) Assertion 'preemptible' failed at mm.c:2493
(XEN)
(XEN)
(XEN) Reboot in five seconds...
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
__
On Tue, Dec 18, 2018 at 11:19:04PM +0100, Manuel Bouyer wrote:
> Hello,
> I tried updating my NetBSD dom0 to 4.11.1 (from 4.11.0 with security patches),
> and on a 32bits PV domU shutdown I get (100% reproductible):
I get the same panic on 4.8.5. Also, I didn't mention it but there
s now wrong if the L2E points to another L2,
> which surely is the case when you see the assertion trigger.
Should we just change false to true here, or should the cases above be handled
differently ?
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
itial part of the
> necessary change - if you did just this, you'd end up hitting
> the ASSERT() right after the line above. There's quite a bit
> more to it, and it needs to be done pretty carefully.
OK, so I'll wait for a more complete patch :)
--
Manuel Bouyer
to it, and it needs to be done pretty carefully.
>
> Actually there was no reason to alter the free_l2_table() paths
> in the XSA-273 fixes: A switch to shadow mode can only occur
> when validating page tables. Therefore I think you could
d of poweroff gives the same result.
This happens with both 32bitsPAE and 64bits domU. This doens't seem to
happen with HVM domUs.
Attached are a cut-n-paste of the panic, and the output of xl demsg.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
tch below a try?
> (This may not be the final patch, as I'm afraid there may be some race
> here, but I'd have to work this out later.)
Yes, this works. thanks !
I'll now put this version on the NetBSD testbed I'm running.
This should put some pressure on it.
thanks !
--
On Wed, Apr 25, 2018 at 09:16:59AM +0100, Andrew Cooper wrote:
> Manuel: As a tangentially related question, does NetBSD ever try to page
> out its LDT?
AFAIK no, LDTs are allocated as kernel wired memory
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la
On Wed, Apr 25, 2018 at 12:42:42PM +0200, Manuel Bouyer wrote:
> > Without line numbers associated with at least the top stack trace entry
> > I can only guess what it might be - could you give the patch below a try?
> > (This may not be the final patch, as I'm afraid
On Wed, Apr 25, 2018 at 09:28:03AM -0600, Jan Beulich wrote:
> >>> On 25.04.18 at 16:42, wrote:
> > On Wed, Apr 25, 2018 at 12:42:42PM +0200, Manuel Bouyer wrote:
> >> > Without line numbers associated with at least the top stack trace entry
> >> > I c
TLB flush
> case. This is the issue Manual has run into with NetBSD.
Hello,
I tested this patch with NetBSD, it looks good.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
___
Xen-devel mailing list
On Mon, Apr 30, 2018 at 07:31:28AM -0600, Jan Beulich wrote:
> >>> On 25.04.18 at 16:42, wrote:
> > On Wed, Apr 25, 2018 at 12:42:42PM +0200, Manuel Bouyer wrote:
> >> > Without line numbers associated with at least the top stack trace entry
> >> > I c
but it didn't look difficult to fix it.
Now lets wait for some automated tests run to complete ...
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On Tue, Jul 03, 2018 at 06:17:28PM +0200, Manuel Bouyer wrote:
> > So instead of the debugging patch, could you give the one below
> > a try?
>
> Sure, the test server is now running with it.
> As I'm still using 4.11rc4 sources I had to adjust it a bit (the second ch
On Fri, Jul 06, 2018 at 04:26:38PM +0200, Manuel Bouyer wrote:
> On Tue, Jul 03, 2018 at 06:17:28PM +0200, Manuel Bouyer wrote:
> > > So instead of the debugging patch, could you give the one below
> > > a try?
> >
> > Sure, the test server is now running with i
4.11 packages for NetBSD, with the attached
patch. With this the hypervisor doens't panic ...
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
$NetBSD: patch-zz-bouyer,v 1.1 2018/07/24 13:40:11 bouyer Exp $
Dirty hack to avoid assert failure. This has
certain cases, there's a small
> debugging patch that I would hope could help prove this one or the
> other way (see below).
I applied this patch to 4.11rc4 a week ago, but the assert didn't fire so far.
t still panics with:
(XEN) Assertion 'oc > 0' failed at mm.c:681
f racing with scheduler actions, i.e. single atomic reads need to
> be used there. Obviously the non-init write sites then better also use
> atomic writes.
>
> Having to touch the descriptor table TLB flush code here anyway, take
> the opportunity and switch it to be at most one flu
.org/bsdweb.cgi/src/sys/arch/x86/x86/pmap.c
Some helper functions are in
http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/xen/x86/xen_pmap.c
Some #defines and inline are in
http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/xen/include/xenpmap.h
http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/i386/incl
On Sun, Jun 10, 2018 at 09:38:17AM -0600, Jan Beulich wrote:
> >>> Manuel Bouyer 06/10/18 1:30 PM >>>
> >When a new set of page tables is needed (this is pmap_create()), a pdp is
> >requested from a cache. If the cache is empty, pages are allocated in
> >
ering)?
> Otherwise I'm afraid I'm confused now, as the sharing by all CPUs of
> the former seems to contradict the per-context nature of the latter.
yes, sorry, it's referecened in the last entry of the "L3 slot 2" L2 page.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
s patch to 4.11rc4 (let's not change too much things at the
same time) and rebooted my test host. Hopefully I'll have some data to report
soon
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
___
Xen-devel
On Tue, Jun 12, 2018 at 01:39:05PM +0200, Manuel Bouyer wrote:
> I applied this patch to 4.11rc4 (let's not change too much things at the
> same time) and rebooted my test host. Hopefully I'll have some data to report
> soon
Got the first panic (still from a i386 domU):
login:
On Tue, Jun 12, 2018 at 04:54:30PM +0100, Andrew Cooper wrote:
> On 12/06/18 16:38, Manuel Bouyer wrote:
> > On Tue, Jun 12, 2018 at 01:39:05PM +0200, Manuel Bouyer wrote:
> >> I applied this patch to 4.11rc4 (let's not change too much things at the
> >> same
On Tue, Jun 12, 2018 at 05:38:45PM +0200, Manuel Bouyer wrote:
> On Tue, Jun 12, 2018 at 01:39:05PM +0200, Manuel Bouyer wrote:
> > I applied this patch to 4.11rc4 (let's not change too much things at the
> > same time) and rebooted my test host. Hopefully I'll have
m you (the first one is where the assert is). See attached.
> In any event, to take
> care of the other assertion you've hit below an updated debugging
> patch. I hope I didn't overlook any further (cascade) ones.
Will rebuild with it, I'll keep you informed.
--
Manuel Bo
t one, after you had said that it didn't
> trigger in a long time. It triggering with the other debugging patch is
> not unexpected. So please drop that patch at least for the time being.
OK, rebuilding Xen right now
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujour
ial console, in case you notice something.
I'll keep anita tests running in a loop overnight, in case it ends up
hitting an assert.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
xen_console.txt.gz
Description: application/gunzip
rom happening. I'm trying again with a large console
ring instead.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
dn't notice anything suspect, exept a few domU crashes (crashing in
Xen, the problem is not reported back to the domU). But as this is
running NetBSD-HEAD tests it can also be a bug in the domU, that has
been fixed since then.
It's possible that the printk changed timings in a way that pr
or HVM,
and PVH, but this is making slow progress). 32-bit PV is faster than 64-bit PV
so all my domUs are 32bits these days.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
___
Xen-devel mailing list
Xen-devel@l
vided selectors. NetBSD really does malfunction as a
>consequence (benignly now, but a VM DoS before the 2018 Xen selector fix).
What do you mean with «malfunction» ? A 64bits guest can run 32bit code
just fine, this is part of our daily regression tests.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
K this should not cause any issue. If I understand it properly,
SYSCALL in a 32bit context would not work in any case on Intel CPUs.
The patch just makes if fail on AMD cpus the same way it fails on Intel.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
}
the gdprintk() I added in the ( !page) case fires, so this is the
cause of the EINVAL.
Is it expected for a HVM domU ? If so, how should the dom0 code be
changed to get it working ? I failed to see where our code is different
from linux ...
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
pci=0x0)
at
/home/bouyer/pkgbuild/current/sysutils/xentools413/work/xen-4.13.0/tools/qemu-xen-traditional/hw/xen_machine_fv.c:405
#3 0x004a975b in main (argc=23, argv=0x7f7fff45fc78,
envp=)
at
/home/bouyer/pkgbuild/current/sysutils/xentools413/work/xen-4.13.0/tools/qemu-xen-t
ioreq_pfn
$2 = 0xfeff0
> and whether it matches up with the
> magic gfn range as reported by `xl create -vvv` for the guest?
I guess you mean
xl -vvv create
the output is attached
The kernel says it tries to map 0xfeff to virtual address 0x79656f951000.
--
Manuel Bouyer
Ne
On Sat, May 16, 2020 at 05:18:45PM +0100, Andrew Cooper wrote:
> On 15/05/2020 22:53, Manuel Bouyer wrote:
> > On Fri, May 15, 2020 at 10:38:13PM +0100, Andrew Cooper wrote:
> >>> [...]
> >>> Does it help ?
> >> Yes and no. This is collateral damage
gdprintk(XENLOG_ERR, "p2m_get_page_from_gfn2: %d is_ram %ld
is_paging %ld is_pod %ld\n", *t, p2m_is_ram(*t), p2m_is_paging(*t),
p2m_is_pod(*t) );
return NULL;
}
*t is 4, which translates to p2m_mmio_dm
it looks like p2m_get_page_from_gfn() is not ready to handle this case
for dom0.
On Sun, May 17, 2020 at 07:32:59PM +0200, Manuel Bouyer wrote:
> I've been looking a bit deeper in the Xen kernel.
> The mapping is failed in ./arch/x86/mm/p2m.c:p2m_get_page_from_gfn(),
> /* Error path: not a suitable GFN at all */
> if ( !p2m_is_ram(*t) &am
On Mon, May 18, 2020 at 08:36:24AM +0100, Paul Durrant wrote:
> > -Original Message-
> > From: Xen-devel On Behalf Of
> > Manuel Bouyer
> > Sent: 17 May 2020 18:56
> > To: Andrew Cooper
> > Cc: xen-devel@lists.xenproject.org
> > Subject:
On Tue, May 19, 2020 at 09:34:30AM +0200, Jan Beulich wrote:
> On 18.05.2020 19:31, Manuel Bouyer wrote:
> > From what I found it seems that all unallocated memory is tagged
> > p2m_mmio_dm,
> > is it right ?
>
> Yes. For many years there has been a plan t
s implies different code paths (the dom0
kernel has to map the foreing pages in its physical space, which PV
doesn't have to do (and can't do))
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
ot;. It is the first MSI-X device configured; the previous
ones are MSI only.
Is it a bug on the Xen side, or something missing on the NetBSD side ?
If the later, where can I find informations about it ?
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
On Thu, Nov 12, 2020 at 05:32:40PM +0100, Roger Pau Monné wrote:
> On Thu, Nov 12, 2020 at 04:57:15PM +0100, Manuel Bouyer wrote:
> > Hello,
> > I'm trying to add dom0 PVH support to NetBSD. I'm tesing with Xen 4.13
> > on a brand new Intel x86 server (Dell R440).
&g
ivered to the dom0 kernel. The conters stay at 0.
I get some ioapic interrupts though, as well as some Xen events.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
ivered
at some point in the setup process. Maybe something to do with mask/unmask ?
The problematc interrupt in identifed as "ioapic2 pin 2" by the NetBSD kernel,
so it's not MSI/MSI-X (not sure it matters though).
Maybe something related to mask/unmask ?
--
Manuel Bouyer
On Fri, Nov 13, 2020 at 03:33:49PM +0100, Roger Pau Monné wrote:
> On Fri, Nov 13, 2020 at 12:54:57PM +0100, Manuel Bouyer wrote:
> > On Thu, Nov 12, 2020 at 09:19:39PM +0100, Roger Pau Monné wrote:
> > > The following might be able to get you going, but I think I need to
> &
On Fri, Nov 13, 2020 at 03:35:13PM +0100, Roger Pau Monné wrote:
> Forgot to mention, it might also be helpful to boot Xen with
> iommu=debug, just in case.
I put the serial console log at
http://www-soc.lip6.fr/~bouyer/xen-log2.txt
in case it helps
--
Manuel Bouyer
NetBSD:
On Fri, Nov 13, 2020 at 04:14:28PM +0100, Manuel Bouyer wrote:
> I can try a kernel without this driver, to see if other devices reports
> interrupt.
This didn't change anything, I don't get more interrupts with this driver
commented out.
--
Manuel Bouyer
NetBSD: 26
x27;t show any pending or masked events, for any CPU.
The NetBSD interrupt counters show event channel 2's counter (the CPU0 clock)
stuck at 13, while others are happily increasing.
Any idea what to look at from here ?
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
e=com0 root=dk0 -vx
(yes, com2 for xen and com0 for netbsd, that's not a bug :)
You can enter the NetBSD debugger with
+
you can then enter commands, lile
sh ev /i
to see the interrupt counters
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
On Sun, Nov 15, 2020 at 06:49:38PM +0100, Manuel Bouyer wrote:
> Hello,
> I spent some more time debugging NetBSD as a PVH dom0 on Xen,
> With Roger's patch to avoid a Xen panic, the NetBSD kernel stalls
> configuring devices. At first I though it was an issue with hardware
>
On Sun, Nov 15, 2020 at 07:24:16PM +0100, Roger Pau Monné wrote:
> On Sun, Nov 15, 2020 at 06:49:38PM +0100, Manuel Bouyer wrote:
> > Hello,
> > I spent some more time debugging NetBSD as a PVH dom0 on Xen,
> > With Roger's patch to avoid a Xen panic, the NetBSD ker
On Sun, Nov 15, 2020 at 07:24:16PM +0100, Roger Pau Monné wrote:
> On Sun, Nov 15, 2020 at 06:49:38PM +0100, Manuel Bouyer wrote:
> > Hello,
> > I spent some more time debugging NetBSD as a PVH dom0 on Xen,
> > With Roger's patch to avoid a Xen panic, the NetBSD ker
On Tue, Nov 17, 2020 at 10:02:04AM +0100, Roger Pau Monné wrote:
> Great! So all interrupts are working as expected now?
No, I'm back at the problem where the PERC raid controller times out on
commands. I'm cleaing up my sources and will try to get more data
about this problem.
--
On Tue, Nov 17, 2020 at 10:45:34AM +0100, Roger Pau Monné wrote:
> On Tue, Nov 17, 2020 at 10:07:33AM +0100, Manuel Bouyer wrote:
> > On Tue, Nov 17, 2020 at 10:02:04AM +0100, Roger Pau Monné wrote:
> > > Great! So all interrupts are working as expected now?
> >
> &g
0 kenrel is back using synchronous console output.
Any idea what to look at from here ?
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
, I think it's OK (assuming I properly understood what
you mean too). Wouldn't it cause problems on real hardware too
if the vectors were not EOI'd ?
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
(XEN) IRQ information:
(XEN)IRQ: 0 v
On Wed, Nov 18, 2020 at 09:57:38AM +0100, Roger Pau Monné wrote:
> On Tue, Nov 17, 2020 at 05:40:33PM +0100, Manuel Bouyer wrote:
> > On Tue, Nov 17, 2020 at 04:58:07PM +0100, Roger Pau Monné wrote:
> > > [...]
> > >
> > > I have attached a patch below that
On Wed, Nov 18, 2020 at 10:16:17AM +0100, Jan Beulich wrote:
> On 17.11.2020 17:40, Manuel Bouyer wrote:
> > On Tue, Nov 17, 2020 at 04:58:07PM +0100, Roger Pau Monné wrote:
> >> [...]
> >>
> >> I have attached a patch below that will dump the vIO-APIC info as p
On Wed, Nov 18, 2020 at 10:43:27AM +0100, Jan Beulich wrote:
> On 18.11.2020 10:28, Manuel Bouyer wrote:
> > On Wed, Nov 18, 2020 at 10:16:17AM +0100, Jan Beulich wrote:
> >> On 17.11.2020 17:40, Manuel Bouyer wrote:
> >>> On Tue, Nov 17, 2020 at 04:58:07P
On Wed, Nov 18, 2020 at 11:00:25AM +0100, Roger Pau Monné wrote:
> On Wed, Nov 18, 2020 at 10:24:25AM +0100, Manuel Bouyer wrote:
> > On Wed, Nov 18, 2020 at 09:57:38AM +0100, Roger Pau Monné wrote:
> > > On Tue, Nov 17, 2020 at 05:40:33PM +0100, Manuel Bouyer wrote:
> >
er, or it also
> randomly freezes and requires further poking?
I let it run overnight, with some cron jobs firing and it didn't wedge.
I guess that once the kernel autoconf is done, the window in which
the interrupt is masked at the ioapic level is much shorter, making the
problem much less likely to happen.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
one, the console is indeed flooded, and the dom0 boots without
problem.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
On Thu, Nov 19, 2020 at 04:57:18PM +0100, Manuel Bouyer wrote:
> On Thu, Nov 19, 2020 at 03:19:15PM +0100, Roger Pau Monné wrote:
> > I've got two different debug patches for you to try. I'm attaching both
> > to this email but I think we should st
On Thu, Nov 19, 2020 at 05:57:34PM +0100, Manuel Bouyer wrote:
> On Thu, Nov 19, 2020 at 04:57:18PM +0100, Manuel Bouyer wrote:
> > On Thu, Nov 19, 2020 at 03:19:15PM +0100, Roger Pau Monné wrote:
> > > I've got two different debug patches for you to try. I'm attaching
to
> the Xen console caused one to be injected, and thus dom0 didn't had
> time to Ack it yet.
What does Xen consider to be an ACK from the dom0 ?
AFAIK we have EOI only for LAPIC interrupts.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
024M console=com2 com2=57600,8n1,,0 loglvl=all guest_loglvl=all
gnttab_max_nr_frames=64 dom0=pvh iommu=debug dom0_vcpus_pin sync_console
dom0_max_vcpus=1 watchdog=force
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
r is it something else (at the IOAPIC level) ?
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
On Fri, Nov 20, 2020 at 11:00:05AM +0100, Jan Beulich wrote:
> On 20.11.2020 10:27, Manuel Bouyer wrote:
> > On Fri, Nov 20, 2020 at 09:59:57AM +0100, Jan Beulich wrote:
> >> Well, anything coming through the LAPIC needs ack-ing (except for
> >> the spurious interrupt of
might actually be EOIing the wrong vector,
> and thus this would be a bug in NetBSD. I certainly don't know much of
> NetBSD interrupt model in order to know whether this second EOI is just
> not necessary or whether it could cause issues.
>
> Can you actually assert that disabling this second unneeded EOI does
> solve the problem?
I tried this, and it didn't change anything ...
I'm out of idea to try.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
or when Xen performs an EOI
> (either from a time out or when reacting to a guest one). I would
> expect at least the interrupt injection one to trigger together with
> the existing message.
It's quite verbose. I put the full log at
http://www-soc.lip6.fr/~bouyer/xen-log4.t
errupt
any more. The NetBSD counter shows only one interrupt for ioapic2 pin 2,
while I would have about 8 at the time of the hang.
So, now it looks like interrupts are blocked forever. At
http://www-soc.lip6.fr/~bouyer/xen-log5.txt
you'll find the output of the 'i' key.
--
Manue
t; with IRQs off for extended periods of time.
>
> Let's dump the physical lapic(s) IRR and ISR together with the
> IO-APIC state. Can you please apply the following patch and use the
> 'i' key again? (please keep the previous patch applied)
Done, you'll find
'i' key again? (please keep the previous patch applied)
> >
> > Done, you'll find the log at
> > http://www-soc.lip6.fr/~bouyer/xen-log6.txt
>
> Hmm, I can't spot respective output. Are you sure you did this with
> a hypervisor with Roger's
On Tue, Nov 24, 2020 at 03:52:25PM +0100, Jan Beulich wrote:
> On 24.11.2020 15:27, Manuel Bouyer wrote:
> > new log at
> > http://www-soc.lip6.fr/~bouyer/xen-log7.txt
> >
> > this one ends up in a panic, I hope you'll find what you expect here.
>
> Did you
m is, I don't have a different box with iommu to test it yet.
> but I would ask if you
> can keep the current box in order for us to continue debugging.
This systems isn't in production yet, and I can probably delay migrating the
domUs some more. I think we have 2 more weeks
On Tue, Nov 24, 2020 at 04:49:17PM +0100, Roger Pau Monné wrote:
> Could you also give a try with ioapic_ack=new on the Xen command line?
With this I still have the interrupt issue, but Xen doesn't panic on 'i'.
http://www-soc.lip6.fr/~bouyer/xen-log8.txt
--
Manuel Bouyer
On Fri, Jan 15, 2021 at 04:09:19PM +0100, Roger Pau Monné wrote:
> On Tue, Jan 12, 2021 at 07:12:22PM +0100, Manuel Bouyer wrote:
> > From: Manuel Bouyer
> >
> > On NetBSD the lock directory is in /var/run/
> >
> > Signed-off-by: Manuel Bouyer
>
>
On Sat, Jan 16, 2021 at 11:16:06AM +0100, Roger Pau Monné wrote:
> On Tue, Jan 12, 2021 at 07:12:37PM +0100, Manuel Bouyer wrote:
> > From: Manuel Bouyer
> >
> > Pass bridge name to qemu as command line option
> > When starting qemu, set an environnement variable XEN_D
On Mon, Jan 18, 2021 at 09:36:42AM +0100, Roger Pau Monné wrote:
> On Sat, Jan 16, 2021 at 12:25:02PM +0100, Manuel Bouyer wrote:
> > On Sat, Jan 16, 2021 at 11:16:06AM +0100, Roger Pau Monné wrote:
> > > On Tue, Jan 12, 2021 at 07:12:37PM +0100, Manuel Bouyer wrote:
> >
On Mon, Jan 18, 2021 at 10:07:22AM +0100, Roger Pau Monné wrote:
> On Mon, Jan 18, 2021 at 09:52:14AM +0100, Manuel Bouyer wrote:
> > On Mon, Jan 18, 2021 at 09:36:42AM +0100, Roger Pau Monné wrote:
> > > I also wonder why NetBSD needs to add the tap interface to the bridge
On Mon, Jan 18, 2021 at 06:31:45PM +, Andrew Cooper wrote:
> On 15/01/2021 15:31, Roger Pau Monné wrote:
> > On Tue, Jan 12, 2021 at 07:12:26PM +0100, Manuel Bouyer wrote:
> >> From: Manuel Bouyer
> >>
> >> NetBSD doens't need xenbackendd with xl too
On Mon, Jan 18, 2021 at 06:45:42PM +, Andrew Cooper wrote:
> On 18/01/2021 18:03, Roger Pau Monné wrote:
> > On Tue, Jan 12, 2021 at 07:12:28PM +0100, Manuel Bouyer wrote:
> >> From: Manuel Bouyer
> >>
> >> On NetBSD the privcmd interface node is /kern
On Mon, Jan 18, 2021 at 06:56:46PM +, Andrew Cooper wrote:
> On 12/01/2021 18:12, Manuel Bouyer wrote:
> > From: Manuel Bouyer
> >
> > On NetBSD, PTHREAD_STACK_MIN is not available.
> > Just use DEFAULT_THREAD_STACKSIZE if PTHREAD_STACK_MIN is not available.
&g
he questions later this week.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
On Wed, Jan 20, 2021 at 02:52:06PM +, Ian Jackson wrote:
> Roger Pau Monné writes ("Re: [PATCH] libs/light: make it build without
> setresuid()"):
> > On Tue, Jan 12, 2021 at 07:12:36PM +0100, Manuel Bouyer wrote:
> > > From: Manuel Bouyer
> > >
>
On Wed, Jan 20, 2021 at 03:13:22PM +, Ian Jackson wrote:
> Manuel Bouyer writes ("Re: [PATCH 05/24] Introduce locking functions for
> block device setup on NetBSD"):
> > On Tue, Dec 29, 2020 at 12:29:09PM +0100, Roger Pau Monné wrote:
> > > I think you want t
On Wed, Jan 20, 2021 at 03:32:29PM +, Ian Jackson wrote:
> Manuel Bouyer writes ("Re: [PATCH] libs/light: make it build without
> setresuid()"):
> > On Wed, Jan 20, 2021 at 02:52:06PM +, Ian Jackson wrote:
> > > I don't think setuid is safe - at
On Wed, Jan 20, 2021 at 04:12:29PM +, Ian Jackson wrote:
> Manuel Bouyer writes ("Re: [PATCH 05/24] Introduce locking functions for
> block device setup on NetBSD"):
> > Yes, at last the stat call will need to be patched.
> > But it seems to rely on a linux-spec
On Wed, Jan 20, 2021 at 05:10:36PM +, Ian Jackson wrote:
> Manuel Bouyer writes ("Re: [PATCH] libs/light: make it build without
> setresuid()"):
> > On Wed, Jan 20, 2021 at 03:32:29PM +, Ian Jackson wrote:
> > > Yes, the dm is qemu. If qemu restricti
On Fri, Jan 15, 2021 at 04:27:12PM +0100, Roger Pau Monné wrote:
> On Tue, Jan 12, 2021 at 07:12:24PM +0100, Manuel Bouyer wrote:
> > From: Manuel Bouyer
> >
> > When a domain is destroyed, xparams may not be available any more when
> > the block script is ca
On Fri, Jan 15, 2021 at 05:06:59PM +0100, Roger Pau Monné wrote:
> On Tue, Jan 12, 2021 at 07:12:25PM +0100, Manuel Bouyer wrote:
> > From: Manuel Bouyer
> >
> > Some Xen version didn't set the vifname in xenstore; just build one if
> > not present.
>
> I t
On Mon, Jan 18, 2021 at 06:54:11PM +0100, Roger Pau Monné wrote:
> On Tue, Jan 12, 2021 at 07:12:32PM +0100, Manuel Bouyer wrote:
> > From: Manuel Bouyer
> >
> > Implement gnttab interface on NetBSD.
> > The kernel interface is different from FreeBSD so we can&#x
On Thu, Jan 14, 2021 at 03:16:15PM +0100, Manuel Bouyer wrote:
> On Thu, Jan 14, 2021 at 02:25:05PM +0100, Jan Beulich wrote:
> > On 14.01.2021 13:29, Manuel Bouyer wrote:
> > > On Thu, Jan 14, 2021 at 11:53:20AM +0100, Jan Beulich wrote:
> > >> On 12.01.2
mU's config file, qemu-ifup is called with xenbr0 as bridge name.
I tried this:
vif = [ 'mac=00:16:3e:00:10:54, gatewaydev=wm0 type=ioemu, model=e1000' ]
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
Use unsigned char variable, or cast to (unsigned char), for
tolower()/islower() and friends. Fix compiler error
array subscript has type 'char' [-Werror=char-subscripts]
Signed-off-by: Manuel Bouyer
Reviewed-by: Ian Jackson
Release-Acked-by: Ian Jackson
---
tools/libs/light/libxl
On NetBSD, some block device configuration requires serialisation.
Introcuce locking functions (derived from the Linux version), and use them
in the block script where appropriate.
Signed-off-by: Manuel Bouyer
---
tools/hotplug/NetBSD/Makefile | 1 +
tools/hotplug/NetBSD/block | 5
Implement foreignmemory interface on NetBSD. The compat interface is now used
only on __sun__
Signed-off-by: Manuel Bouyer
---
tools/libs/foreignmemory/Makefile | 2 +-
tools/libs/foreignmemory/netbsd.c | 66 +-
tools/libs/foreignmemory/private.h | 6 +--
3 files
On NetBSD, d_name is larger than 256, so file_name[284] may not be large
enough (and gcc emits a format-truncation error).
Use asprintf() instead of snprintf() on a static on-stack buffer.
Signed-off-by: Manuel Bouyer
---
tools/xenpmd/xenpmd.c | 8
1 file changed, 4 insertions(+), 4
1 - 100 of 261 matches
Mail list logo
