> Module Name:src
> Committed By: jdolecek
> Date: Fri Apr 10 18:03:06 UTC 2020
>
> Modified Files:
> src/sys/arch/xen/xen: if_xennet_xenbus.c
>
> Log Message:
> convert to bus_dma(9), remove now not necessary XENPVHVM redefines
> [...]
> + KASSERT(req->rxreq
On Sat, May 16, 2020 at 02:51:43PM +1000, matthew green wrote:
> "Jaromir Dolecek" writes:
> > Module Name:src
> > Committed By: jdolecek
> > Date: Fri May 15 07:42:58 UTC 2020
> >
> > Modified Files:
> > src/sys/arch/xen/include: intr.h
> > src/sys/arch/xen/x86
"Jaromir Dolecek" writes:
> Module Name: src
> Committed By: jdolecek
> Date: Fri May 15 07:42:58 UTC 2020
>
> Modified Files:
> src/sys/arch/xen/include: intr.h
> src/sys/arch/xen/x86: pintr.c
>
> Log Message:
> use short for irq2port[] to save memory (4KB), it only needs to
On Mon, Apr 13, 2020 at 08:09:13PM +, Jaromir Dolecek wrote:
> Module Name: src
> Committed By: jdolecek
> Date: Mon Apr 13 20:09:13 UTC 2020
>
> Modified Files:
> src/sys/arch/xen/xen: xbd_xenbus.c
>
> Log Message:
> KASSERT() that requested I/O size is <= XBD_MAX_XFER - this
HI,
I am not sur whether it is the commit below, but 2 out 4 times my
xen-DOMU from today (20200409/9.99.55)
panics with following locking botch:
[ 29.9301379] panic: kernel diagnostic assertion "IFNET_LOCKED(ifp)"
failed: file "/usr/src/sys/arch/xen/xen/if_xennet_xenbus.c", line 1120
[ 2
On Sun, Apr 05, 2020 at 05:26:47PM +, Jaromir Dolecek wrote:
> Module Name: src
> Committed By: jdolecek
> Date: Sun Apr 5 17:26:47 UTC 2020
>
> Modified Files:
> src/sys/arch/xen/xen: if_xennet_xenbus.c xennetback_xenbus.c
>
> Log Message:
> remove support for legacy rx-flip
Le 17/02/2017 à 22:51, Robert Elz a écrit :
Module Name:src
Committed By: kre
Date: Fri Feb 17 21:51:47 UTC 2017
Modified Files:
src/sys/arch/xen/conf: files.xen
Log Message:
Copy maxv's files.i386 change to files.xen ... this might fix the i386
[...]
It is true that,
> XXX: The tradeoff is a (predicted) single word size comparison
> penalty, so perhaps a decision needs performance stats.
compared to a TLB shootdown? let's just move along and
try not to hear the noise this _may_ generate..
.mrg.
Le 08/08/2016 à 04:27, Cherry G. Mathew a écrit :
On 2 August 2016 at 19:51, Maxime Villard mailto:m...@netbsd.org>> wrote:
Module Name:src
Committed By: maxv
Date: Tue Aug 2 14:21:53 UTC 2016
Modified Files:
src/sys/arch/xen/x86: x86_xpmap.c
Lo
On 2 August 2016 at 19:51, Maxime Villard wrote:
> Module Name:src
> Committed By: maxv
> Date: Tue Aug 2 14:21:53 UTC 2016
>
> Modified Files:
> src/sys/arch/xen/x86: x86_xpmap.c
>
> Log Message:
> Map the kernel text, rodata and data+bss independently on Xen, with
> res
Le 10/10/2014 18:42, Maxime Villard a écrit :
Le 03/10/2014 22:56, Christos Zoulas a écrit :
Module Name:src
Committed By:christos
Date:Fri Oct 3 20:56:24 UTC 2014
Modified Files:
src/sys/arch/xen/xen: privcmd.c
Log Message:
correct error paths; still need to verify that
On Oct 17, 6:02pm, m...@m00nbsd.net (Maxime Villard) wrote:
-- Subject: Re: CVS commit: src/sys/arch/xen/xen
| > Don't you think that you should also revert r1.46 [1]? Now that
| > privcmd_map_obj() frees everything correctly...
Yes, I was going to and I forgot; done now.
christos
Le 03/10/2014 22:56, Christos Zoulas a écrit :
Module Name:src
Committed By: christos
Date: Fri Oct 3 20:56:24 UTC 2014
Modified Files:
src/sys/arch/xen/xen: privcmd.c
Log Message:
correct error paths; still need to verify that the "didn't give us back..."
case is corr
Le 27/09/2014 17:51, Christos Zoulas a écrit :
On Sep 27, 8:36am, m...@m00nbsd.net (Maxime Villard) wrote:
-- Subject: Re: CVS commit: src/sys/arch/xen/xen
| One however returns an error without freeing:
|
| if (newstart != start) {
| printf("uvm_map didn't give u
On Sep 27, 10:15pm, bou...@antioche.eu.org (Manuel Bouyer) wrote:
-- Subject: Re: CVS commit: src/sys/arch/xen/xen
| > if (newstart != start) {
| > printf("uvm_map didn't give us back our vm space\n");
| > + uvm_unmap1(map, news
On Sat, Sep 27, 2014 at 11:51:59AM -0400, Christos Zoulas wrote:
> On Sep 27, 8:36am, m...@m00nbsd.net (Maxime Villard) wrote:
> -- Subject: Re: CVS commit: src/sys/arch/xen/xen
>
> | One however returns an error without freeing:
> |
> | if (newstart != start) {
>
On Sep 27, 8:36am, m...@m00nbsd.net (Maxime Villard) wrote:
-- Subject: Re: CVS commit: src/sys/arch/xen/xen
| One however returns an error without freeing:
|
| if (newstart != start) {
| printf("uvm_map didn't give us back our vm space\n");
|
Le 21/09/2014 20:22, Christos Zoulas a écrit :
On Sep 21, 7:57pm, m...@m00nbsd.net (Maxime Villard) wrote:
-- Subject: Re: CVS commit: src/sys/arch/xen/xen
| Did you test this change? Verily I'm not sure it's a proper bug, but I
| kept it in my list so that someone (bouyer@?) could i
Did you test this change? Verily I'm not sure it's a proper bug, but I
kept it in my list so that someone (bouyer@?) could investigate.
Le 21/09/2014 18:56, Christos Zoulas a écrit :
>
> Module Name: src
> Committed By: christos
> Date: Sun Sep 21 16:56:44 UTC 2014
>
> Modified Files:
>
On Sep 21, 7:57pm, m...@m00nbsd.net (Maxime Villard) wrote:
-- Subject: Re: CVS commit: src/sys/arch/xen/xen
| Did you test this change? Verily I'm not sure it's a proper bug, but I
| kept it in my list so that someone (bouyer@?) could investigate.
This is why I committed the fix in
On Sun, Feb 02, 2014 at 08:24:08PM +, David Laight wrote:
> On Sun, Feb 02, 2014 at 08:41:29PM +0100, Manuel Bouyer wrote:
> > On Sun, Feb 02, 2014 at 06:53:55PM +, David Laight wrote:
> > > Something needs to set the TS (task switched) flag when a new cpu
> > > is added. Both amd64 and i38
On Sun, Feb 02, 2014 at 08:41:29PM +0100, Manuel Bouyer wrote:
> On Sun, Feb 02, 2014 at 06:53:55PM +, David Laight wrote:
> > Something needs to set the TS (task switched) flag when a new cpu
> > is added. Both amd64 and i386 'bare metal' have direct calls to
> > fpuinit() to do this.
> >
> >
On Sun, Feb 02, 2014 at 06:53:55PM +, David Laight wrote:
> > It's been a while since I looked at this and I don't remmeber the details,
> > but I don't think anything of fpuinit() is neeed for Xen. in netbsd-6
> > npxattach() doens't do anything either for Xen (only set i386_fpu_present to
> >
On Sun, Feb 02, 2014 at 01:27:45PM +0100, Manuel Bouyer wrote:
> On Sat, Feb 01, 2014 at 10:49:44PM +, David Laight wrote:
> > On Sat, Feb 01, 2014 at 08:07:07PM +, Manuel Bouyer wrote:
> > > Module Name: src
> > > Committed By: bouyer
> > > Date: Sat Feb 1 20:07:07 UT
On Sat, Feb 01, 2014 at 10:49:44PM +, David Laight wrote:
> On Sat, Feb 01, 2014 at 08:07:07PM +, Manuel Bouyer wrote:
> > Module Name:src
> > Committed By: bouyer
> > Date: Sat Feb 1 20:07:07 UTC 2014
> >
> > Modified Files:
> > src/sys/arch/xen/xen: hyper
On Sat, Feb 01, 2014 at 06:09:04PM -0800, John Nemeth wrote:
> }
> } XEN might need the bits of fpuinit() that don't play with cr0.
> } In particular a fninit and setting TS.
> } Although I'm not 100% sure the TS is needed on a single cpu system.
>
> Xen domU is SMP capable. NetBSD dom0 cur
On Feb 1, 10:49pm, David Laight wrote:
} On Sat, Feb 01, 2014 at 08:07:07PM +, Manuel Bouyer wrote:
} > Module Name:src
} > Committed By: bouyer
} > Date: Sat Feb 1 20:07:07 UTC 2014
} >
} > Modified Files:
} > src/sys/arch/xen/xen: hypervisor.c
} >
} > Log Me
On 2/1/14, 2:49 PM, David Laight wrote:
On Sat, Feb 01, 2014 at 08:07:07PM +, Manuel Bouyer wrote:
I can't say I've actuallly looked a xen.
Presumably we somewhere compile the hypervisor as part of a kernel?
The hypervisor is in pkgsrc - sysutils/xenkernel42 (and the accompanying
xento
On Sat, Feb 01, 2014 at 08:07:07PM +, Manuel Bouyer wrote:
> Module Name: src
> Committed By: bouyer
> Date: Sat Feb 1 20:07:07 UTC 2014
>
> Modified Files:
> src/sys/arch/xen/xen: hypervisor.c
>
> Log Message:
> Revert previous: calling fpuinit() leads to a panic, as a domU i
On Sat, Feb 01, 2014 at 05:48:04PM +, David Laight wrote:
> Module Name: src
> Committed By: dsl
> Date: Sat Feb 1 17:48:04 UTC 2014
>
> Modified Files:
> src/sys/arch/xen/xen: hypervisor.c
>
> Log Message:
> Add a direct call to fpuinit().
> I'm not sure this is architectural
On Tue, Dec 03, 2013 at 08:51:00PM +, Manuel Bouyer wrote:
> Module Name: src
> Committed By: bouyer
> Date: Tue Dec 3 20:51:00 UTC 2013
>
> Modified Files:
> src/sys/arch/xen/xen: evtchn.c
>
> Log Message:
> Remove the "evtchn_do_event: handler %p didn't lower ipl %d %d\n" pr
On 12/3/13 12:51 PM, Manuel Bouyer wrote:
Module Name:src
Committed By: bouyer
Date: Tue Dec 3 20:51:00 UTC 2013
Modified Files:
src/sys/arch/xen/xen: evtchn.c
Log Message:
Remove the "evtchn_do_event: handler %p didn't lower ipl %d %d\n" printf.
With help from Robert E
On Nov 11, 1:05pm, Jukka Ruohonen wrote:
} On Mon, Nov 11, 2013 at 02:52:30AM -0800, John Nemeth wrote:
} > My point is, if you want to know, go read the thread in port-xen@,
} > or the code. Also, what "trivial function for Xen"?
}
} The wrappers in cpufunc.S'es.
So that would be sys
Thanks for the explanation!
Btw, it was not criticism but a question.
- Jukka.
On Mon, Nov 11, 2013 at 12:31:19PM -0800, John Nemeth wrote:
> On Nov 11, 1:05pm, Jukka Ruohonen wrote:
> } On Mon, Nov 11, 2013 at 02:52:30AM -0800, John Nemeth wrote:
> } > My point is, if you want to know, g
On Nov 11, 12:30pm, Jukka Ruohonen wrote:
} On Sun, Nov 10, 2013 at 11:17:54AM -0800, John Nemeth wrote:
} > } x86_wbind()? Which however appears to be (icorrectly?) #ifndef'd for Xen.
} >
} > Uh, the function for Xen would be wbinvd(), which would create
} > a very nice infinite loop as all
On Mon, Nov 11, 2013 at 02:52:30AM -0800, John Nemeth wrote:
> My point is, if you want to know, go read the thread in port-xen@,
> or the code. Also, what "trivial function for Xen"?
The wrappers in cpufunc.S'es.
- Jukka.
On Sun, Nov 10, 2013 at 11:17:54AM -0800, John Nemeth wrote:
> } x86_wbind()? Which however appears to be (icorrectly?) #ifndef'd for Xen.
>
> Uh, the function for Xen would be wbinvd(), which would create
> a very nice infinite loop as all that function does is call
> xpq_flush_cache(). Thi
On Nov 10, 4:50pm, Jukka Ruohonen wrote:
} On Sun, Nov 10, 2013 at 01:19:13AM +, John Nemeth wrote:
} > Module Name:src
} > Committed By: jnemeth
} > Date: Sun Nov 10 01:19:13 UTC 2013
} >
} > Modified Files:
} > src/sys/arch/xen/x86: x86_xpmap.c
} >
} > Log M
On Sun, Nov 10, 2013 at 01:19:13AM +, John Nemeth wrote:
> Module Name: src
> Committed By: jnemeth
> Date: Sun Nov 10 01:19:13 UTC 2013
>
> Modified Files:
> src/sys/arch/xen/x86: x86_xpmap.c
>
> Log Message:
> Change xpq_flush_cache to just do WBINVD letting the hypervisor tr
On Sun, Jan 13, 2013 at 11:59:29AM +0530, Cherry G. Mathew wrote:
> Hi Manuel,
>
> On 13 January 2013 02:39, Manuel Bouyer wrote:
> > Module Name:src
> > Committed By: bouyer
> > Date: Sat Jan 12 21:09:10 UTC 2013
> >
> > Modified Files:
> > src/sys/arch/xen/include: hyper
Hi Manuel,
On 13 January 2013 02:39, Manuel Bouyer wrote:
> Module Name:src
> Committed By: bouyer
> Date: Sat Jan 12 21:09:10 UTC 2013
>
> Modified Files:
> src/sys/arch/xen/include: hypervisor.h
> src/sys/arch/xen/x86: hypervisor_machdep.c
> src/sys/arch/
On Tue, Aug 21, 2012 at 01:17:46AM +, Mindaugas Rasiukevicius wrote:
> Module Name: src
> Committed By: rmind
> Date: Tue Aug 21 01:17:46 UTC 2012
>
> Modified Files:
> src/sys/arch/xen/x86: x86_xpmap.c
>
> Log Message:
> Fix Xen build. Make xcpumask uint32_t, fits 32 CPUs (ca
On 24.06.2012 23:44, Christoph Egger wrote:
> On 24.06.12 20:31, Jean-Yves Migeon wrote:
>
>> Module Name:src
>> Committed By:jym
>> Date:Sun Jun 24 18:31:53 UTC 2012
>>
>> Modified Files:
>> src/sys/arch/xen/include: xenpmap.h
>> src/sys/arch/xen/x86: xen_pmap.c
>>
>> Log
On 24.06.12 20:31, Jean-Yves Migeon wrote:
Module Name:src
Committed By: jym
Date: Sun Jun 24 18:31:53 UTC 2012
Modified Files:
src/sys/arch/xen/include: xenpmap.h
src/sys/arch/xen/x86: xen_pmap.c
Log Message:
Enable the map/unmap recursive mapping functions for
On Thu, 7 Jun 2012 14:05:14 +
"Stephen Borrill" wrote:
> Module Name: src
> Committed By: sborrill
> Date: Thu Jun 7 14:05:14 UTC 2012
>
> Modified Files:
> src/sys/arch/xen/xenbus: xenbus_probe.c
>
> Log Message:
> Fix problem where devices with ID 0 were skipped as invalid
Hello,
It seems that this change makes the first vif of domU not recognized
when multiple vif's are assigned in config file.
For example, when config has
vif = [ 'mac=mac0, bridge=bridge0',
'mac=mac1, bridge=bridge1',
'mac=mac2, bridge=bridge2 ]
, you can see on domU
xennet0, who
On Tue, Feb 21, 2012 at 09:49:40AM +0100, J. Hannken-Illjes wrote:
> On Feb 21, 2012, at 2:47 AM, Jonathan A. Kollasch wrote:
>
> > Module Name:src
> > Committed By: jakllsch
> > Date: Tue Feb 21 01:47:50 UTC 2012
> >
> > Modified Files:
> > src/sys/arch/xen/xen: x
On Feb 21, 2012, at 2:47 AM, Jonathan A. Kollasch wrote:
> Module Name: src
> Committed By: jakllsch
> Date: Tue Feb 21 01:47:50 UTC 2012
>
> Modified Files:
> src/sys/arch/xen/xen: xbd_xenbus.c
>
> Log Message:
> Add and use xbdminphys() to handle transfer segmentation/size limit
On Thu, Dec 08, 2011 at 11:09:19AM +0100, Christoph Egger wrote:
> On 12/08/11 04:34, Cherry G. Mathew wrote:
> >Module Name: src
> >Committed By:cherry
> >Date:Thu Dec 8 03:34:48 UTC 2011
> >
> >Modified Files:
> > src/sys/arch/xen/xen: evtchn.c
> >
> >Log Message:
> >
On 12/08/11 04:34, Cherry G. Mathew wrote:
Module Name:src
Committed By: cherry
Date: Thu Dec 8 03:34:48 UTC 2011
Modified Files:
src/sys/arch/xen/xen: evtchn.c
Log Message:
kmem_free() the appropriate size.
Thanks cegger@
This is still not enough: In pirq_establish(
On 7 December 2011 19:19, Christoph Egger wrote:
> Module Name: src
> Committed By: cegger
> Date: Wed Dec 7 13:49:04 UTC 2011
>
> Modified Files:
> src/sys/arch/xen/xen: evtchn.c
>
> Log Message:
> build fix: add back . malloc(9) is still in use.
>
Hi, sorry about this, I
On 12/3/11 2:41 PM, Manuel Bouyer wrote:
Module Name:src
Committed By: bouyer
Date: Sat Dec 3 22:41:40 UTC 2011
Modified Files:
src/sys/arch/xen/x86: hypervisor_machdep.c
src/sys/arch/xen/xen: xenevt.c
Log Message:
hypervisor_unmask_event(): don't check/update e
On 29.08.2011 15:03, Cherry G. Mathew wrote:
> I'm a bit confused now - are we assuming that the pmap lock protects the
> (pte update op queue-push(es) + pmap_pte_flush()) as a single atomic
> operation (ie; no invlpg/tlbflush or out-of-band-read can occur between
> the update(s) and the pmap_pte_f
On Mon, Aug 29, 2011 at 03:03:37PM +0200, Cherry G. Mathew wrote:
> Hi Manuel,
>
> > "Manuel" == Manuel Bouyer writes:
>
>
> [...]
>
> >>
> >> Xen's TLB_FLUSH operation is synchronous, and doesn't require an
> >> IPI (within the domain), which makes the queue ordering even mor
Hi Manuel,
> "Manuel" == Manuel Bouyer writes:
[...]
>>
>> Xen's TLB_FLUSH operation is synchronous, and doesn't require an
>> IPI (within the domain), which makes the queue ordering even more
>> important (to make sure that stale ptes are not reloaded before
>> the pe
> "Cherry" == Cherry G Mathew writes:
[...]
Cherry> Xen's TLB_FLUSH operation is synchronous, and doesn't
I mean, Xen's TLB_FLUSH_MULTI operations. my current implementation of
tlb shootdown is therefore synchronous wrt TLB flushes on all cpus.
Cheers,
--
Cherry
On Mon, Aug 29, 2011 at 12:07:05PM +0200, Cherry G. Mathew wrote:
> JM> On Mon, 22 Aug 2011 12:47:40 +0200, Manuel Bouyer wrote:
> >>> This is slightly more complicated than it appears. Some of the
> >>> "ops" in a per-cpu queue may have ordering dependencies with
> >>> other cpu qu
Cc:ing tech-kern, to get wider feedback.
Thread started here:
http://mail-index.netbsd.org/source-changes-d/2011/08/21/msg003897.html
> "JM" == Jean-Yves Migeon writes:
JM> On Mon, 22 Aug 2011 12:47:40 +0200, Manuel Bouyer wrote:
>>> This is slightly more complicated than it appears
On Mon, 22 Aug 2011 12:47:40 +0200, Manuel Bouyer wrote:
This is slightly more complicated than it appears. Some of the "ops"
in
a per-cpu queue may have ordering dependencies with other cpu
queues,
and I think this would be hard to express trivially. (an example
would
be a pte update on one qu
On Sun, Aug 21, 2011 at 09:39:14PM +0200, Cherry G. Mathew wrote:
> JM> An alternative would be to have per-CPU xpq_queue[] also. This
> JM> is not completely stupid, xpq_queue is meant as a way to put
> JM> multiple MMU operations in a queue asynchronously before issuing
> JM> only
On Sun, Aug 21, 2011 at 12:38:06PM +0200, Jean-Yves Migeon wrote:
> On 21.08.2011 12:26, Jean-Yves Migeon wrote:
> > - second, the lock is not placed at the correct abstraction level IMHO,
> > it is way too high in the caller/callee hierarchy. It should remain
> > hidden from most consumers of the
On 21.08.2011 21:39, Cherry G. Mathew wrote:
> JM> An alternative would be to have per-CPU xpq_queue[] also. This
> JM> is not completely stupid, xpq_queue is meant as a way to put
> JM> multiple MMU operations in a queue asynchronously before issuing
> JM> only one hypercall to han
> "JM" == Jean-Yves Migeon writes:
JM> On 21.08.2011 12:26, Jean-Yves Migeon wrote:
>> - second, the lock is not placed at the correct abstraction level
>> IMHO, it is way too high in the caller/callee hierarchy. It
>> should remain hidden from most consumers of the xpq_queue
On 21.08.2011 12:26, Jean-Yves Migeon wrote:
> - second, the lock is not placed at the correct abstraction level IMHO,
> it is way too high in the caller/callee hierarchy. It should remain
> hidden from most consumers of the xpq_queue API, and should only be used
> to protect the xpq_queue array to
On 10.08.2011 11:50, Cherry G. Mathew wrote:
> Module Name: src
> Committed By: cherry
> Date: Wed Aug 10 09:50:37 UTC 2011
>
> Modified Files:
> src/sys/arch/xen/include: xenpmap.h
> src/sys/arch/xen/x86: x86_xpmap.c
>
> Log Message:
> Introduce locking primitives for Xen pt
On 15.05.2011 21:11, Mindaugas Rasiukevicius wrote:
> This is not correct. Atomic op might decrease the reference count to
> 1 while other thread executes xbdi_put() before xbdi_refcnt is fetched,
> thus decreasing it to 0. In such case, both threads would fetch 0.
>
> The following is a correct
Hello,
"Jean-Yves Migeon" wrote:
> Module Name: src
> Committed By: jym
> Date: Sun May 15 07:24:15 UTC 2011
>
> Modified Files:
> src/sys/arch/xen/xen: xbdback_xenbus.c
>
> Log Message:
> Use atomic_ops(3) for ref counting.
>
> + atomic_dec_uint(&(xbdip)->xbdi_refcnt);
Jean-Yves Migeon wrote:
> On 18.04.2011 10:35, Mindaugas Rasiukevicius wrote:
> > We used to check the return of big size allocations, when kmem(9) could
> > fail even with KM_SLEEP due to KVA starvation. However, pretty much all
> > kernel does not perform checks for smaller allocations and sinc
On Apr,Monday 18 2011, at 10:26 AM, Mindaugas Rasiukevicius wrote:
> "Cherry G. Mathew" wrote:
> On Mon, Apr 18, 2011 at 03:04:32AM +, Mindaugas Rasiukevicius
> wrote:
>> Module Name:src
>> Committed By: rmind
>> Date: Mon Apr 18 03:04:31 UTC 2
On 18.04.2011 10:35, Mindaugas Rasiukevicius wrote:
> We used to check the return of big size allocations, when kmem(9) could
> fail even with KM_SLEEP due to KVA starvation. However, pretty much all
> kernel does not perform checks for smaller allocations and since the bug
> was fixed - we are no
Jean-Yves Migeon wrote:
> On 18.04.2011 05:04, Mindaugas Rasiukevicius wrote:
> > Module Name:src
> > Committed By: rmind
> > Date: Mon Apr 18 03:04:31 UTC 2011
> >
> > Modified Files:
> > src/sys/arch/xen/xen: balloon.c
> >
> > Log Message:
> > balloon_xenbus_att
"Cherry G. Mathew" wrote:
> >>> On Mon, Apr 18, 2011 at 03:04:32AM +, Mindaugas Rasiukevicius
> >>> wrote:
> >>> > Module Name: src
> >>> > Committed By: rmind
> >>> > Date: Mon Apr 18 03:04:31 UTC 2011
> >>> >
> >>> > Modified Files:
> >>> > src/sys/arch/xen/xen
On 18.04.2011 05:04, Mindaugas Rasiukevicius wrote:
> Module Name: src
> Committed By: rmind
> Date: Mon Apr 18 03:04:31 UTC 2011
>
> Modified Files:
> src/sys/arch/xen/xen: balloon.c
>
> Log Message:
> balloon_xenbus_attach: use KM_SLEEP for allocation.
>
> Note: please do not us
On 18 April 2011 09:04, Jean-Yves Migeon wrote:
> On 18.04.2011 09:23, Cherry G. Mathew wrote:
>> On 18 April 2011 08:00, Cherry G. Mathew wrote:
>>> On 18 April 2011 04:21, Mindaugas Rasiukevicius wrote:
Masao Uebayashi wrote:
> On Mon, Apr 18, 2011 at 03:04:32AM +, Mindaugas Rasi
On 18.04.2011 09:23, Cherry G. Mathew wrote:
> On 18 April 2011 08:00, Cherry G. Mathew wrote:
>> On 18 April 2011 04:21, Mindaugas Rasiukevicius wrote:
>>> Masao Uebayashi wrote:
On Mon, Apr 18, 2011 at 03:04:32AM +, Mindaugas Rasiukevicius wrote:
> Module Name:src
> Co
On 18 April 2011 08:00, Cherry G. Mathew wrote:
> On 18 April 2011 04:21, Mindaugas Rasiukevicius wrote:
>> Masao Uebayashi wrote:
>>> On Mon, Apr 18, 2011 at 03:04:32AM +, Mindaugas Rasiukevicius wrote:
>>> > Module Name: src
>>> > Committed By: rmind
>>> > Date:
On 18 April 2011 04:21, Mindaugas Rasiukevicius wrote:
> Masao Uebayashi wrote:
>> On Mon, Apr 18, 2011 at 03:04:32AM +, Mindaugas Rasiukevicius wrote:
>> > Module Name: src
>> > Committed By: rmind
>> > Date: Mon Apr 18 03:04:31 UTC 2011
>> >
>> > Modified Files:
>
Masao Uebayashi wrote:
> On Mon, Apr 18, 2011 at 03:04:32AM +, Mindaugas Rasiukevicius wrote:
> > Module Name:src
> > Committed By: rmind
> > Date: Mon Apr 18 03:04:31 UTC 2011
> >
> > Modified Files:
> > src/sys/arch/xen/xen: balloon.c
> >
> > Log Message:
>
On Mon, Apr 18, 2011 at 03:04:32AM +, Mindaugas Rasiukevicius wrote:
> Module Name: src
> Committed By: rmind
> Date: Mon Apr 18 03:04:31 UTC 2011
>
> Modified Files:
> src/sys/arch/xen/xen: balloon.c
>
> Log Message:
> balloon_xenbus_attach: use KM_SLEEP for allocation.
>
> N
On 06.04.2011 20:01, Manuel Bouyer wrote:
> You could also use
> xvifxiy (e.g. xvif5i2, where i stands for 'index').
> or any other letter ...
Huh hmm indeed... I wonder why I did not think about this approach before...
--
Jean-Yves Migeon
jeanyves.mig...@free.fr
On Wed, Apr 06, 2011 at 05:41:37PM +0100, Jean-Yves Migeon wrote:
> Yep, but there are other places where this will get tricky. For
> example, rc.conf(5) is parsed as a classic shell script [1]. Given
> that someone has two possibilities to configure interfaces:
>
> /etc/ifconfig.xxx
> or
> ifconf
On Wed, 6 Apr 2011 16:29:22 +, Taylor R Campbell
wrote:
Date: Mon, 04 Apr 2011 23:46:19 +0200
From: Jean-Yves Migeon
The newer scripts for Xen read the interface value from the
vifname
entry in Xenstore, so changing the name is not that critical. But
this
should be stabilized
Date: Mon, 04 Apr 2011 23:46:19 +0200
From: Jean-Yves Migeon
The newer scripts for Xen read the interface value from the vifname
entry in Xenstore, so changing the name is not that critical. But this
should be stabilized sooner than later. Personally, I find '_' rather
ugly in a
On 04.04.2011 23:21, Taylor R Campbell wrote:
>Date: Sun, 3 Apr 2011 23:21:39 +
>From: "Jean-Yves Migeon"
>
>Now that pkgsrc-2011Q1 has arrived, and before -6 chimes in, change
>ifxname for xvif(4) from xvif%d.%d to xvif%d-%d. This is needed
>to avoid sysctl(9) EINVAL erro
Date: Sun, 3 Apr 2011 23:21:39 +
From: "Jean-Yves Migeon"
Now that pkgsrc-2011Q1 has arrived, and before -6 chimes in, change
ifxname for xvif(4) from xvif%d.%d to xvif%d-%d. This is needed
to avoid sysctl(9) EINVAL errors when creating interface nodes.
This change came awfull
On Wed, Mar 30, 2011 at 12:17:05AM +, Jean-Yves Migeon wrote:
> Module Name: src
> Committed By: jym
> Date: Wed Mar 30 00:17:04 UTC 2011
>
> Modified Files:
> src/sys/arch/xen/xen: if_xennet_xenbus.c
>
> Log Message:
> printf("xennet: ...") => aprint_error_ifnet()
It's silly,
On Thu, Mar 04, 2010 at 12:58:01AM +0900, Izumi Tsutsui wrote:
> They are in .
>
> >> #define howmany(x, y) (((x)+((y)-1))/(y))
> how many y-byte blocks are required to store x-bytes region?
>
> >> #define roundup(x, y) x)+((y)-1))/(y))*(y))
> >> #define rounddown(x,y) (((x)/(y))*(y))
>
> OT: these are a little unclear to me. Could someone outline what
>
> roundup
> roundup2
> rounddown
> howmany
They are in .
>> #define howmany(x, y) (((x)+((y)-1))/(y))
how many y-byte blocks are required to store x-bytes region?
>> #define roundup(x, y) x)+((y
On Wed, Mar 03, 2010 at 12:09:03AM +, Jean-Yves Migeon wrote:
> Module Name: src
> Committed By: jym
> Date: Wed Mar 3 00:09:03 UTC 2010
>
> Modified Files:
> src/sys/arch/xen/x86: cpu.c
>
> Log Message:
> Use roundup2() instead of hardcoding the CACHE_LINE_SIZE rounding
> ope
89 matches
Mail list logo
