Santhosh Raju writes:
> On Mon, Dec 17, 2018 at 6:37 PM Cherry G.Mathew wrote:
>>
>> Sorry for the late reply:
>>
>> Santhosh Raju writes:
>>
>>
>> [...]
>>
>> > + * This macro was added to convert uvmexp.npages from int to psize_t
>> > + */
>>
>> I believe Matt's suggestion was to put the comm
Sorry for the late reply:
Santhosh Raju writes:
[...]
> + * This macro was added to convert uvmexp.npages from int to psize_t
> + */
I believe Matt's suggestion was to put the comment in the relevant
source header (not the test), unless I got that wrong.
--
~cherry
Martin Husemann writes:
> On Sun, Nov 18, 2018 at 04:19:50PM +0530, Cherry G.Mathew wrote:
>> Typo:
>> https://mail-index.netbsd.org/source-changes/2018/11/18/msg100702.html
>
> Ugh - can't you just modify
>
> CLKF_USERMODE(frame)
> CLKF_PC(frame)
> CLKF_INTR(frame)
>
> for xen making them ignore
Jason Thorpe writes:
>> On Nov 18, 2018, at 11:00 AM, Martin Husemann wrote:
>>
>> On Sun, Nov 18, 2018 at 04:19:50PM +0530, Cherry G.Mathew wrote:
>>> Typo:
>>> https://mail-index.netbsd.org/source-changes/2018/11/18/msg100702.html
>>
>> Ugh - can't you just modify
>>
>> CLKF_USERMODE(frame)
Martin Husemann writes:
> On Sun, Nov 18, 2018 at 04:19:50PM +0530, Cherry G.Mathew wrote:
>> Typo:
>> https://mail-index.netbsd.org/source-changes/2018/11/18/msg100702.html
>
> Ugh - can't you just modify
>
> CLKF_USERMODE(frame)
> CLKF_PC(frame)
> CLKF_INTR(frame)
>
> for xen making them ignore
Cherry G.Mathew writes:
[...]
> For now, I did a little arch specific (XEN) hack:
> https://mail-index.netbsd.org/source-changes/2018/11/18/msg100702.html~
Typo:
https://mail-index.netbsd.org/source-changes/2018/11/18/msg100702.html
--
~cherry
Cherry G.Mathew writes:
> matthew green writes:
>
> [...]
>
>>
>> what problem are you actually trying to solve?
>>
>
> Ok, so I think I now have enough info to compose everything into a
> coherent question.
>
> Motivation:
>
> Unifying XEN vector.S entry points with x86/ native ones.
>
> The ca
matthew green writes:
[...]
>
> what problem are you actually trying to solve?
>
Ok, so I think I now have enough info to compose everything into a
coherent question.
Motivation:
Unifying XEN vector.S entry points with x86/ native ones.
The catch here is that in PV mode, the interrupt entry
matthew green writes:
>> For eg: if a clock interrupt from userland got deferred as pending, even
>> if it came in from userland (is this possible ?), because the current
>> spl level was at, say, SPL_HIGH, it now seems to be the case that the
>> system accounts for the delayed execution by charg
"Cherry G. Mathew" writes:
> Hello,
>
> So recently I've been looking at the interrupt subsystem for NetBSD/Xen,
> which is a little unusual in that several interrupts can batch
> together before a virtual cpu that is scheduled can be woken up to
> handle them.
Hello,
So recently I've been looking at the interrupt subsystem for NetBSD/Xen,
which is a little unusual in that several interrupts can batch
together before a virtual cpu that is scheduled can be woken up to
handle them.
When this happens, a single callback handler is invoked, which
demultiple
Cherry G. Mathew writes:
> Cherry G. Mathew writes:
>
>> Hello Xen,
>>
>> I've been spending a little attention on our PV interrupt path with a
>> view to getting PVHVM etc. to work better.
>
> Hello - now that things have settled in nicely for 8.0, I&
Jaromír Doleček writes:
> ne 24. 6. 2018 v 12:13 odesílatel Cherry G.Mathew napsal:
>> Sometime tomorrow I'll send a first re-org patch (no functional changes)
>> followed by the actual meat later in the week.
>
> I have some small changes for x86/intr.c and xen/evtchn.c too. In
> intr.c pretty
Cherry G. Mathew writes:
> Hello Xen,
>
> I've been spending a little attention on our PV interrupt path with a
> view to getting PVHVM etc. to work better.
Hello - now that things have settled in nicely for 8.0, I'm going to
start rocking the boat again. The next set of p
On 6 November 2017 9:31:13 PM MYT, Manuel Bouyer wrote:
>On Mon, Nov 06, 2017 at 12:59:45AM +0530, Cherry G. Mathew wrote:
>> Hello,
>>
>> As threatened earlier [1], I checked in a bunch of preparatory
>commits
>> for the big one - to overhaul our PV interrupt cod
Manuel Bouyer writes:
> On Mon, Nov 06, 2017 at 12:59:45AM +0530, Cherry G. Mathew wrote:
>> Hello,
>>
>> As threatened earlier [1], I checked in a bunch of preparatory commits
>> for the big one - to overhaul our PV interrupt codepath and to unify it
>> with
Hello,
As threatened earlier [1], I checked in a bunch of preparatory commits
for the big one - to overhaul our PV interrupt codepath and to unify it
with the x86/intr.c paths.
This would help abstract out several things, as well as make it much
easier for PVHVM to happen sanely.
I really would
Roger Pau Monné writes:
> On Tue, Aug 22, 2017 at 06:01:42PM +0200, Manuel Bouyer wrote:
>> On Sat, Aug 19, 2017 at 01:31:09AM +0530, Cherry G. Mathew wrote:
>> > Hello,
>> >
>> > I'm trying to improve the semantics around x86 lapic vs. cpu, with a
>&
Martin Husemann writes:
> On Mon, Aug 21, 2017 at 12:50:32AM +0000, Cherry G. Mathew wrote:
>> In this case, the CPU is actually exported to the domU as a x86 cpu
>> as well as vcpu. This has nothing to do with baremetal cpu which is
>> invisible to HVM domain guests. So
On 21 August 2017 1:54:12 am IST, John Nemeth wrote:
>On Aug 19, 1:31am, "Cherry G. Mathew" wrote:
>}
>} I'm trying to improve the semantics around x86 lapic vs. cpu, with a
>} view to wedging in the concept of "vcpu"s.
>}
>} TLDR: please review this
Cherry G. Mathew writes:
..
>
> The situation for XEN is as follows:
>
> PV domU - only vcpu
> HVM domU - only cpu
> PVHVM domU - cpu:vcpu -> 1:1
> PVH dom0 - cpu:vcpu -> 1:1 (IIUC)
> PV dom0 - cpu:vcpu -> vcpu can be fewer than cpu
>
Just to clarify:
dom0
Hello,
I'm trying to improve the semantics around x86 lapic vs. cpu, with a
view to wedging in the concept of "vcpu"s.
TLDR: please review this patch:
http://ftp.netbsd.org/pub/NetBSD/misc/cherry/tmp/attach-cpu-with-lapic.diff
Essentially, the idea is that when the kernel runs under a hypervisor
> "tsutsui" == Izumi Tsutsui writes:
tsutsui> cherry@ wrote:
>> Please find below a patch to remove .avail_(start|end) from
>> struct vm_physseg
tsutsui> What's advantage of these changes?
tsutsui> Changing MD APIs could often cause botches on poor tierII
tsutsui> po
Hi Everyone,
Please find below a patch to remove .avail_(start|end) from
struct vm_physseg
I couldn't find a reason for them to be used redundantly, but I may be
wrong. Are there port specific uses for these ?
--
Cherry
diff -r 0b3902dbe274 sys/arch/acorn26/acorn26/pmap.c
--- a/sys/arch/acorn
Please don't assume that amd64 is Direct Mapped in all cases - it isn't for
XEN kernels
One of the boot time constraints for XEN PV is the amount of VA mapped in,
which is used to allocate KVA backing tables. If the number of entries in
NKL2_KIMG_ENTRIES causes backing page VA allocation to exceed
Hi Roger,
I've got two immediate thoughts:
On 9 January 2013 00:46, Roger Pau Monné wrote:
> This device works by passing a memory region previously allocated with
> mmap(NULL, size, prot, MAP_ANON | MAP_SHARED, -1, 0). This region is
i) wire down the mapping with MAP_WIRED
This will prevent
On 11 November 2012 18:21, Jean-Yves Migeon wrote:
> Le 10/11/12 19:15, Cherry G. Mathew a écrit :
>>>
>>> Some comments:
>>>
>>> - remove hypervisor_enable_ipl from headers, it does not seem to be used
>>> anymore.
>>> - if you are in
On 10 November 2012 12:15, Cherry G. Mathew wrote:
...
> On a second glance, I realised that Xspllower is called only via
> xen_inter.c:spllower()
.. and in the mutex_exit() stub
In any case, there are no asynchronous entry paths into Xspllower on Xen
--
~Cherry
On 20 December 2011 10:15, Jean-Yves Migeon wrote:
> On Tue, 20 Dec 2011 00:57:13 +0530, Cherry G. Mathew wrote:
>>
>> I've reworked the spl code in XEN to use a single entry point into C
>> code, and to optimise the pending event processing via spllower()
>>
>
> "Thor" == Thor Lancelot Simon writes:
Thor> On Mon, Jun 25, 2012 at 02:16:33PM +0100, Roger Pau Monne wrote:
>>
>> Yes, it doesn't hurt to zero memory if returning it to the
>> user. Who knows what might be there previously.
Thor> I'm sorry, I can't let this go.
Cheer
>>>>> "Martin" == Martin Husemann writes:
Martin> On Sun, Jun 17, 2012 at 07:13:01PM +0100, Cherry G. Mathew wrote:
>> - does the default atf source tree contain a generic rump build
>> that provides most/all api translations to userland
Hi Antti, tech-kern,
I'm trying to understand how/if it's possible to unit test a self-contained
api implementation within kernel source via rump.
For eg: let's say I'm going to write an api with a single function:
int add(int a, int b);
The implementation of this function is in a file, say:
sr
On 25 February 2012 15:22, Christoph Egger wrote:
> On 25.02.12 10:29, Sad Clouds wrote:
>> On Thu, 23 Feb 2012 20:58:45 +
>> Mindaugas Rasiukevicius wrote:
>>
>>> Brook Milligan wrote:
I understand that at least on the i386/amd64 ports CPUs are tracked
with a 32-bit mask and thus
Hi,
I've reworked the spl code in XEN to use a single entry point into C
code, and to optimise the pending event processing via spllower()
See:
ftp://ftp.netbsd.org/pub/NetBSD/misc/cherry/tmp/port-xen/spl.diff
I'd love for as much test reportage as possible with this patch.
dom0 is reported to
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
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 13 August 2011 11:45, Christos Zoulas wrote:
> In article
> ,
> Cherry G. Mathew wrote:
>>On 13 August 2011 11:26, Christos Zoulas wrote:
>>> In article <8762m4qlm8....@zyx.in>, Cherry G. Mathew wrote:
>>>>ftp://ftp.netbsd.org/pub/NetBSD
On 13 August 2011 11:26, Christos Zoulas wrote:
> In article <8762m4qlm8@zyx.in>, Cherry G. Mathew wrote:
>>ftp://ftp.netbsd.org/pub/NetBSD/misc/cherry/tmp/wrap_ipi.diff
>>
>>Hi,
>>
>>I'd like to ask peoples' opinions about the above patch.
On 11 August 2011 16:39, David Young wrote:
> On Thu, Aug 11, 2011 at 04:08:07PM +0530, Cherry G. Mathew wrote:
>> ftp://ftp.netbsd.org/pub/NetBSD/misc/cherry/tmp/wrap_ipi.diff
>
> This looks like a great way to get rid of those pesky #ifdef XENs.
>
Thanks Dave, committed.
--
~Cherry
ftp://ftp.netbsd.org/pub/NetBSD/misc/cherry/tmp/wrap_ipi.diff
Hi,
I'd like to ask peoples' opinions about the above patch. This would
remove a couple of #ifdef XEN/#endif pairs I had to introduce
lately.
Cheers,
--
Cherry
>>>>> "haad" == haad writes:
haad> Hi,
haad> On Sun, Aug 7, 2011 at 4:56 PM, Cherry G. Mathew
wrote:
>> Hi,
>>
>> I'd like to start merging in bits of the cherry-xenmp branch into
>> -current over th
Hi,
I'd like to start merging in bits of the cherry-xenmp branch into
-current over the coming week. The changes should be transparent, and
shouldn't change any behaviour of -current. These include a few cleanups
of MD code and some MP related changes (eg: to x86 pmap) that should be
agnostic to
On 17 November 2008 13:30, Alexander Shishkin
wrote:
> On Wed, Nov 12, 2008 at 03:47:56PM +, Mindaugas Rasiukevicius wrote:
>> Joerg Sonnenberger wrote:
>> > On Wed, Nov 05, 2008 at 12:10:28PM +, Mindaugas Rasiukevicius wrote:
>> > > Any concerns on this patch?
>> >
>> > Hooking this into
On 9 July 2010 20:27, Christoph Egger wrote:
> On Friday 09 July 2010 16:38:58 Jean-Yves Migeon wrote:
>> On 09.07.2010 10:18, Christoph Egger wrote:
>> > I get this:
>> >
>> > # sysctl kern.xen
>> > kern.xen.balloon.current = 131072
>> > kern.xen.balloon.target = 131072
>> >
>> > So for xentools,
Hi Christoph,
On 7 July 2010 14:30, Christoph Egger wrote:
[...]
>> > Though I have to report a bug:
>> >
>> > I have an amd64 Dom0 kernel w/o XEN_BALLOONING in the kernel config.
>> > Boot the xen kernel with dom0_mem=512m
>> >
>> > After login I do:
>> >
>> > # sysctl kern.xen
>> > kern.xen.b
On 7 July 2010 17:07, Thor Lancelot Simon wrote:
> On Wed, Jul 07, 2010 at 01:57:30PM +0530, Cherry G. Mathew wrote:
>> >
>> > How would you stop the domU being able to increase its memory size (e.g. on
>> > a hosted service, you wouldn't want the client taki
On 7 July 2010 17:03, Thor Lancelot Simon wrote:
> On Wed, Jul 07, 2010 at 08:34:31AM +0530, Cherry G. Mathew wrote:
>>
>> use 'xm mem-set' command as mentioned above.
>
> This overrides 'sysctl -w kern.xen.balloon.target=$newtargetinpages'
> from withi
On 7 July 2010 14:00, Christoph Egger wrote:
> On Tuesday 06 July 2010 17:02:08 Cherry G. Mathew wrote:
>> On 6 July 2010 09:19, Cherry G. Mathew wrote:
>> > jym@ and I made a few more changes to this.
>> > Have a look here:
>> > ftp://ftp.netbsd.org/pub/NetBS
On 7 July 2010 13:37, Stephen Borrill wrote:
> On Tue, 6 Jul 2010, Cherry G. Mathew wrote:
>>
>> Briefly, there are two methods to play with this now.
>>
>>> From dom0:
>>
>> # xm mem-set $domid $newmemsz
>>
>> or, from within the domU
>&
On 7 July 2010 00:02, Thor Lancelot Simon wrote:
> On Tue, Jul 06, 2010 at 10:56:22PM +0530, Cherry G. Mathew wrote:
>>
>> Briefly, there are two methods to play with this now.
>>
>> >From dom0:
>>
>> # xm mem-set $domid $newmemsz
>&g
Hi Eric,
On 6 July 2010 22:43, Eric Haszlakiewicz wrote:
> On Tue, Jul 06, 2010 at 09:19:57AM +0530, Cherry G. Mathew wrote:
>> On 28 June 2009 19:56, Cherry G. Mathew wrote:
>> > Hi,
>> >
>> > Quick note to say that I hacked up a little balloon driver from
On 6 July 2010 09:19, Cherry G. Mathew wrote:
> jym@ and I made a few more changes to this.
> Have a look here:
> ftp://ftp.netbsd.org/pub/NetBSD/misc/cherry/balloon/
>
> Any feedback would be much appreciated. If things go well, I'm hoping
> to commit this marked "E
On 28 June 2009 19:56, Cherry G. Mathew wrote:
> Hi,
>
> Quick note to say that I hacked up a little balloon driver from
> scratch for fun. It just about works on a XEN3 dom0 but that's it. I'm
> posting it here as an FYI as suggested by jym@
>
> Let me
54 matches
Mail list logo
