On Mon, Jul 19, 2010 at 12:39:08PM +, Quentin Garnier wrote:
> When the platform uses the APIC interrupt model, OSPM associates
> processors declared in the namespace with entries in the MADT. Prior to
> ACPI 3.0, this was accomplished using the processor object's ProcessorID
> and the ACPI Pr
> > FWIW, having a different module load path and choosing the right set
> > of modules is an incoming feature but i have no time line for it.
> >
> > i plan for it to be useful for ppc oea vs. 4xx, sparc32 vs sparc64
> > in 32 bitmode, and there was someone else wanting it too.
>
> IMHO, it mak
On 24.07.2010 20:47, matthew green wrote:
>> On 24.07.2010 09:50, Christoph Egger wrote:
>> Not necessarily, the kvm(3) API manipulates PA as u_long (see
>> _kvm_kvatop in kvm_i386.c). Changing the paddr_t will need a
>> modification of this API too, and basically, all ports will have to move
>> to
On 24.07.2010 21:00, matthew green wrote:
>> On 24.07.2010 17:54, Matthias Drochner wrote:
>>>
>>> c...@cubidou.net said:
Kernel modules, on the other hand...
>>>
>>> Hmm, didn't think of that. (using them myself only for testing)
>>>
a gaping ABI incompatibility is completely unacceptabl
> On 24.07.2010 17:54, Matthias Drochner wrote:
> >
> > c...@cubidou.net said:
> >> Kernel modules, on the other hand...
> >
> > Hmm, didn't think of that. (using them myself only for testing)
> >
> >> a gaping ABI incompatibility is completely unacceptable
> >
> > There are two ways to fix th
> On 24.07.2010 09:50, Christoph Egger wrote:
> >> XXX Mixing PAE and !PAE modules may lead to unwanted/unexpected results.
> >> This
> >> cannot be solved easily, and needs lots of thinking before being declared
> >> safe (paddr_t/bus_addr_t size handling, PD/PT macros abstractions).
> >
> > Ho
On Sat Jul 24 2010 at 19:05:54 +0200, Jean-Yves Migeon wrote:
> > Didn't anyone else read the mail from a week or so ago containing detailed
> > measurements of the overhead?
>
> It measures overhead of PAE, not turning paddr_t to 64 bits on !PAE i386.
Oh, right. Sun probably fried my brain toda
On 24.07.2010 18:40, Antti Kantee wrote:
> On Sat Jul 24 2010 at 15:23:50 +, Quentin Garnier wrote:
>>> PAE is a "bridge technology", interesting only for few systems.
>>> Users of low-end i386 systems would be penalized, and most users
>>> of boxes with >4G memory would gain nothing because th
On Sat, Jul 24, 2010 at 05:54:41PM +0200, Matthias Drochner wrote:
>
> c...@cubidou.net said:
> > Kernel modules, on the other hand...
>
> Hmm, didn't think of that. (using them myself only for testing)
>
> > a gaping ABI incompatibility is completely unacceptable
>
> There are two ways to fix
On Sat Jul 24 2010 at 15:23:50 +, Quentin Garnier wrote:
> > PAE is a "bridge technology", interesting only for few systems.
> > Users of low-end i386 systems would be penalized, and most users
> > of boxes with >4G memory would gain nothing because they run
> > a 64-bit system anyway.
> > So,
On 24.07.2010 17:54, Matthias Drochner wrote:
>
> c...@cubidou.net said:
>> Kernel modules, on the other hand...
>
> Hmm, didn't think of that. (using them myself only for testing)
>
>> a gaping ABI incompatibility is completely unacceptable
>
> There are two ways to fix this without the 64-bit
c...@cubidou.net said:
> Kernel modules, on the other hand...
Hmm, didn't think of that. (using them myself only for testing)
> a gaping ABI incompatibility is completely unacceptable
There are two ways to fix this without the 64-bit-paddr overhead,
a short-term and a long-term one.
The short-t
On Sat, Jul 24, 2010 at 04:49:28PM +0200, Matthias Drochner wrote:
>
> christoph_eg...@gmx.de said:
> > How about making paddr_t always 64bit? That makes it much easier to
> > deal with in libkvm.
>
> I don't think this is a good argument. The little gain of making
> a rarely used library like li
christoph_eg...@gmx.de said:
> How about making paddr_t always 64bit? That makes it much easier to
> deal with in libkvm.
I don't think this is a good argument. The little gain of making
a rarely used library like libkvm simpler can't justify adding
overhead to the kernel.
PAE is a "bridge techno
Manuel Bouyer wrote:
> On Sat, Jul 24, 2010 at 09:50:33AM +0200, Christoph Egger wrote:
>
> > How about making paddr_t always 64bit? That makes it much easier to deal
> > with in libkvm.
>
> The overhead would need to be evaluated first.
I don't have any figures handy, but when I first tried 64-
On 24.07.2010 09:50, Christoph Egger wrote:
>> XXX Mixing PAE and !PAE modules may lead to unwanted/unexpected results. This
>> cannot be solved easily, and needs lots of thinking before being declared
>> safe (paddr_t/bus_addr_t size handling, PD/PT macros abstractions).
>
> How about making padd
On Sat, Jul 24, 2010 at 02:03:14PM +0200, Jean-Yves Migeon wrote:
> On 24.07.2010 12:30, Manuel Bouyer wrote:
> >> How about making paddr_t always 64bit? That makes it much easier to deal
> >> with in libkvm.
> >
> > The overhead would need to be evaluated first.
> > Also, I'm not sure this would f
On 24.07.2010 12:30, Manuel Bouyer wrote:
>> How about making paddr_t always 64bit? That makes it much easier to deal
>> with in libkvm.
>
> The overhead would need to be evaluated first.
> Also, I'm not sure this would fix all the libkvm issues (the page table
> format is still different).
For th
On Sat, Jul 24, 2010 at 09:50:33AM +0200, Christoph Egger wrote:
> > XXX kvm(3) will be fixed in another patch to properly handle both PAE and
> > !PAE
> > kernel dumps (VA => PA macros are slightly different, and need proper 64
> > bits
> > PA support in kvm_i386).
> >
> > XXX Mixing PAE and !P
On 24.07.10 02:45, Jean-Yves Migeon wrote:
> Module Name: src
> Committed By: jym
> Date: Sat Jul 24 00:45:57 UTC 2010
>
> Modified Files:
> src/sys/arch/i386/conf: GENERIC
> src/sys/arch/i386/i386: bioscall.S kvm86call.S locore.S machdep.c
> mptramp.S multiboot.c
>
20 matches
Mail list logo
