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
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 !PAE modules may
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 the page
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 fix all the
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 paddr_t
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
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 libkvm
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
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 this
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
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
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 unacceptable
There are two ways
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 uint64_t
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 makes sense
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
15 matches
Mail list logo
