Le 09/10/2015 06:49, Masanobu SAITOH a écrit :
> On 2015/10/06 6:10, Jean-Yves Migeon wrote:
>>> Log Message:
>>> kmem_free() the address returned by kmem_alloc(). found by Brainy.
>>> use the newly aligned location if we needed it. found by kre.
>>>
&g
found by Brainy.
> use the newly aligned location if we needed it. found by kre.
>
>
> To generate a diff of this commit:
> cvs rdiff -u -r1.8 -r1.9 src/sys/arch/x86/x86/cpu_ucode_intel.c
IMHO this should be pulled-up to -6 and -7.
Any argument against? If the old code worked, it's pure luck.
--
Jean-Yves Migeon
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
>>
Le 16/05/12 10:45, Christoph Egger a écrit :
On 05/13/12 13:24, Martin Husemann wrote:
On Sun, May 13, 2012 at 01:04:15PM +0200, Jean-Yves Migeon wrote:
Are you sure that moving to low priority xcalls is the way to go? You
can end up with CPUs not being updated because they are offline
Le 13/05/12 13:24, Martin Husemann a écrit :
On Sun, May 13, 2012 at 01:04:15PM +0200, Jean-Yves Migeon wrote:
Are you sure that moving to low priority xcalls is the way to go? You
can end up with CPUs not being updated because they are offline.
Curiously, while I could reproduce the crash
CPUs not being updated because they are offline.
--
Jean-Yves Migeon
jeanyves.mig...@free.fr
Le 05/05/12 17:08, Jean-Yves Migeon a écrit :
Module Name:src
Committed By: jym
Date: Sat May 5 15:08:29 UTC 2012
Modified Files:
src/sys/arch/x86/include: specialreg.h
Log Message:
Add latest CR4 bits:
[snip]
From Intel® 64 and IA-32 Architectures Software
On Mon, 23 Apr 2012 19:02:04 +0100, David Laight wrote:
On Mon, Apr 23, 2012 at 10:09:09AM +0200, Jean-Yves Migeon wrote:
>
> But, as has been pointed out before, code in libc will generate
> alignment traps - because it is faster that way.
I did not know -- care to give an exa
Le 23/04/12 09:48, Martin Husemann a écrit :
On Sun, Apr 22, 2012 at 08:25:11PM +, Christos Zoulas wrote:
There is no portable way to do this; sigbus according to ToG does not
define what si_addr contains.
I read it differently:
The header shall define the siginfo_t type as a structure,
Le 22/04/12 18:38, David Laight a écrit :
> On Sun, Apr 22, 2012 at 02:22:30PM +0100, Jean-Yves Migeon wrote:
>>
>> Hmm, siginfo(2) states the following:
>>
>> For SIGBUS and SIGSEGV the siginfo structure contains the
>> following additional members
igned data access, not the one
from the faulting instruction. SIGBUS is used, not SIGILL.
--
Jean-Yves Migeon
jeanyves.mig...@free.fr
Le 21/04/12 23:25, Christos Zoulas a écrit :
In article<4f930a8c.6040...@free.fr>,
Jean-Yves Migeon wrote:
Le 21/04/12 20:52, Christos Zoulas a écrit :
Module Name:src
Committed By: christos
Date: Sat Apr 21 18:52:37 UTC 2012
Modified Files:
src/sys/arch/amd64
Le 21/04/12 20:52, Christos Zoulas a écrit :
> Module Name: src
> Committed By: christos
> Date: Sat Apr 21 18:52:37 UTC 2012
>
> Modified Files:
>src/sys/arch/amd64/amd64: vector.S
>
> Log Message:
> Alignment fault traps push the error code automatically, so don't use
Le 21/04/12 19:47, Christoph Egger a écrit :
>> rip 0x0 and rsp 0x50202 look really abnormal to me. I'll have a look in
>> FreeBSD, that's probably a group of exceptions that have to be handled
>> differently.
>
> rip 0x0 often means that a function pointer has been called which is
NULL.
>
> Chr
Le 21/04/12 16:31, Jean-Yves Migeon a écrit :
Okay, thanks for the report. So this rules out Virtual Box, it seems to
happen on native amd64 too.
I am taking a look right now.
This seems to be a bug in the trap handling code. The signal is caught
correctly (it reaches T_ALIGNFLT|T_USER in
Le 21/04/12 14:50, Jean-Yves Migeon a écrit :
The machine did not drop into ddb, it simply rebooted. Unfortunately
it did not leave a core dump behind, so I don't have much to look at
just yet. When I get home later today, I will try to get more info.
BTW, this occurred while running th
scripts were written by Jean-Yves Migeon, heavily modified
Thanks for your work on this, riz. Heavily appreciated.
--
jym@
lurking in these recent changes, it could
be
considered to be a security vulnerability - non-priv user should not
be able to crash the box...
:)
Okay, thanks for the report. So this rules out Virtual Box, it seems to
happen on native amd64 too.
I am taking a look right now.
--
Jean-Y
kernel
- passes execution to init(1) and userland
- all userland code making direct syscalls, this raises a SIGILL each
time which gives a chance to the usermode kernel to handle the userland
syscalls.
Right? So how can you implement the MMAP_NOSYSCALLS step on other POSIXy
systems?
Merry Christmas to you (and everyone else too) :)
--
Jean-Yves Migeon
jeanyves.mig...@free.fr
ld return a EOPNOTSUPP or an EINVAL. Panicing is indeed far
too crude
and i'll change that.
Hope this answers most of your questions.
Waiting for mines :)
--
Jean-Yves Migeon
j...@netbsd.org
point about
emulation, and even more so about the alleged extra security where this
can be trivially bypassed. Return to libfoo and ROP are quite mainstream
techniques these days...
--
Jean-Yves Migeon
j...@netbsd.org
On 04.12.2011 21:07, Alan Barrett wrote:
On Sun, 04 Dec 2011, Jean-Yves Migeon wrote:
Log Message:
Implement the register/deregister/evaluation API for secmodel(9). It
allows registration of callbacks that can be used later for
cross-secmodel "safe" communication.
Where and whe
ps to reproduce:
- connect to a dom0 system
- try ballooning up or down, with:
sysctl -w machdep.xen.balloon.target=10
All newly created processes will then stay in tstile, and the sysctl
never returns, waiting on "rplq" wait channel.
Observed in QEMU, Virtualbox, and my amd64 spare host
a different rule applicable to man pages for
4-clause vs 2-clause BSD? I occasionally see new man pages written with
a 4-clause BSD, however, most newly written code is 2-clause.
--
Jean-Yves Migeon
jeanyves.mig...@free.fr
etter.
I always wondered whether i386_use_pae should be set for amd64.
Strictly speaking, PAE is enabled when we are running in long mode. I
set the sysctl(7) a while ago for NX regression tests in ATF, but not
the variable. Maybe I should.
--
Jean-Yves Migeon
jeanyves.mig...@free.fr
On 08.11.2011 14:53, Cherry G. Mathew wrote:
On 8 November 2011 15:20, Jean-Yves Migeon
wrote:
On Tue, 8 Nov 2011 08:49:22 +0530, Cherry G. Mathew wrote:
Please keep ci_pae_l3_pdir to a uint32_t and back out its
paddr_t type.
Unless you can convince me that your code will do the right
thing
S makes it a lot easier.
ok, will watchout for it - do you want to do this one yourself ?
Please do :)
--
Jean-Yves Migeon
jeanyves.mig...@free.fr
rpa[2]) | PG_V;
> +#endif /* PAE */
- are you sure that these have to be
"defined(PAE) || defined(__x86_64__)" ?
- please use "for (i = 0; i < PTP_LEVELS - 1; i++ ) { ... }". I will
have to identify these blocks later when GENERIC will include both PAE
and !PAE pmaps. PTP_LEVELS makes it a lot easier.
That's all for the first quick review :) Thanks for starting the merge
of your branch.
--
Jean-Yves Migeon
jeanyves.mig...@free.fr
based on a context; the old code does
not permit that, unless you build and store the string somewhere,
forcing the caller to *know* that it only keeps a pointer and does not
copy the content. This will get misused, sooner or later.
--
Jean-Yves Migeon
jeanyves.mig...@free.fr
means that the lock will block other LWPs from
running even when they do not need to allocate memory.
--
Jean-Yves Migeon
jeanyves.mig...@free.fr
ried to circumvent the invalidation
limitation (eg. not handling per-CPU pools, like x86 pmap_create
"try_again" loop).
--
Jean-Yves Migeon
jeanyves.mig...@free.fr
On 20.09.2011 02:12, Jean-Yves Migeon wrote:
Module Name:src
Committed By: jym
Date: Tue Sep 20 00:12:25 UTC 2011
Modified Files:
[snip]
Log Message:
Merge jym-xensuspend branch in -current. ok bouyer@.
Goal: save/restore support in NetBSD domUs, for i386, i386 PAE and amd64
y default DESTDIR),
so this went unnoticed during my tests as the correct /etc/defaults gets
parsed.
I'll add the required code to handle this; thanks for reporting!
--
Jean-Yves Migeon
jeanyves.mig...@free.fr
On 06.09.2011 12:54, Thomas Klausner wrote:
> On Mon, Aug 22, 2011 at 06:54:07PM +0000, Jean-Yves Migeon wrote:
>> Module Name: src
>> Committed By:jym
>> Date:Mon Aug 22 18:54:06 UTC 2011
>>
>> [snip]
>>
>> Log Message:
>>
t;
> Log Message:
> Add per-cpu mmu queues
Thanks for looking into it!
--
Jean-Yves Migeon
jeanyves.mig...@free.fr
On 29.08.2011 22:27, Manuel Bouyer wrote:
> On Mon, Aug 29, 2011 at 03:17:16PM +0100, Jean-Yves Migeon wrote:
>> Both; usually I am using the VGA-emulated display, but sometimes
>> (like I did lately) I switch to console, so I can keep a reasonable
>> amount of history of
#x27;t put a giant lock around xpq_queue. This doesn't make
any sense in a MP system, especially for operations that are frequently
called and still may take a while to complete. Just imagine: all CPUs
waiting for one to finish its TLB flush before they can edit their PD/PT
again... ouch.
--
Jean-Yves Migeon
jeanyves.mig...@free.fr
On Mon, 29 Aug 2011 15:25:03 +0200, Manuel Bouyer wrote:
On Mon, Aug 29, 2011 at 12:45:27PM +0100, Jean-Yves Migeon wrote:
Hmm, I'll have to cross-check that one this afternoon. IIRC, I am
also using the the default "break" command when I am running the
dom0 inside QEMU, and
On Mon, 29 Aug 2011 11:46:06 +0200, Manuel Bouyer wrote:
On Mon, Aug 29, 2011 at 09:01:47AM +0200, Jean-Yves Migeon wrote:
What kind of console is attaching for you in dom0? I can't see how
'+' would get wired in by default. At least when either started
from
bare
On 29.08.2011 06:30, Christoph Egger wrote:
> On 29.08.11 06:26, Christoph Egger wrote:
>> On 29.08.11 00:09, Jean-Yves Migeon wrote:
>>> Module Name:src
>>> Committed By: jym
>>> Date: Sun Aug 28 22:09:37 UTC 2011
>>>
>&g
On 27.08.2011 20:28, Joerg Sonnenberger wrote:
> On Sat, Aug 27, 2011 at 08:13:28PM +0200, Jean-Yves Migeon wrote:
>> On 27.08.2011 19:57, Reinoud Zandijk wrote:
>>> Fix copystring routines to NOT just copy all since not all space might be
>>> writable. This can be fixe
orward to add to common/, and I am more at
peace knowing that we have a "valid" strnlen() in kernel rather than a
bogus macro that may spread elsewhere...
--
Jean-Yves Migeon
jeanyves.mig...@free.fr
ow page
tables
you can't use a CAS to assure atomic operation with the hardware TLB,
as
this is, precisely, a shadow PT and not the one used by hardware.
--
Jean-Yves Migeon
jeanyves.mig...@free.fr
e; shadow page tables were mainly designed with Linux in
mind, and the way it manages virtual memory is completely different to
ours: it maps the entire physical memory in the kernel virtual space
(with tricks when there's more than 1GiB involved), while we use
recursive mappings. And Xen has problems validating these.
--
Jean-Yves Migeon
jeanyves.mig...@free.fr
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
e amount of cycles to complete, like TLB flushes). I'd expect all
Xen MMU hypercalls to be reentrant.
--
Jean-Yves Migeon
jeanyves.mig...@free.fr
rful" lockless
algorithms are, except in situation where the additional bus
locking/atomic ops involved did not really improve the situation in
highly concurrent systems (and could even make it worse).
--
Jean-Yves Migeon
jeanyves.mig...@free.fr
On Mon, 18 Jul 2011 07:41:30 +0100, David Laight wrote:
On Mon, Jul 18, 2011 at 02:18:54AM +0200, Jean-Yves Migeon wrote:
On 18.07.2011 02:00, David Young wrote:
>> Can we please use ansi function definitions in newly committed
code?
>
> This was tedious enough without conver
e to ANSI style), I
had to do it manually. It's even the opposite, spatch has issues when
parsing non-ANSI declarations, so you have to do the conversion all by
yourself first...
--
Jean-Yves Migeon
jeanyves.mig...@free.fr
d by the Perl scripts in openssl (byte
streams and the resulting ugliness are neither my own nor spz@).
I tend to steer away from manipulating code (particularly crypto) when I
don't have good knowledge of it. And this is far from being the case for
me with OpenSSL.
Anyway, I'll look into it next week for cleanup.
--
Jean-Yves Migeon
jeanyves.mig...@free.fr
he .byte streams are required for the inclusion of the AES NI
instructions, which are not supported with our current gcc version.
Should be fixed once we have stabilized gcc 4.5 (dunno about other
compilers though, especially pcc).
--
Jean-Yves Migeon
jeanyves.mig...@free.fr
eck (any executable that has kmem sgid rights is a
target), and there are other potential tools usable out there (lsof(1),
maybe?).
Isn't it something that rather fits the kauth(9) ACLs?
--
Jean-Yves Migeon
jeanyves.mig...@free.fr
change, but forgot about the possible concurrency regarding refcnt fetch
(not actually possible as port-xen is not MP, but will become soonish)
I'll remove the volatile declaration too, only xbdi_put/_get use the
refcnt for G/C anyway.
Thanks for pointing that out!
--
Jean-Yves Migeon
jeanyves.mig...@free.fr
xed - we are no longer checking for big ones as well.
>
> This applies to all allocators.
So, any thread sleeping for an allocation cannot be interrupted?
--
Jean-Yves Migeon
jeanyves.mig...@free.fr
ied for all available
memoryallocators(9) especially as the code behind can evolve (hey, Lars
:) ).
--
Jean-Yves Migeon
jeanyves.mig...@free.fr
mentioned in the thread above, ie;
Uho, I forgot to mention in my commit log that I fixed it. I am
allocating bpg_entries via pool_cache(9), and the constructor
bpge_ctor() will return an error if uvm(9) fails to find a free page. In
that case, the thread will just bail out and start waiting again.
--
Jean-Yves Migeon
jeanyves.mig...@free.fr
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, 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
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
>
ce not only "what to load", but
also, "what is the state" of a driver module. Module's loading can
change the state of devices, and rebooting/calling bootloader will _not_
reset that state.
--
Jean-Yves Migeon
jeanyves.mig...@free.fr
of a MONOLITHIC kernel irrelevant.
> So, one more time: the current issue is to define what people
consider
> as options that should be enabled by default, and what could stay
out
> (or as a third party module if you urgently need it back). One
example:
> accf_* is a questionable choice, whether its inside GENERIC (as a
> builtin), or enabled by default in MONOLITHIC.
I don't think that's the issue. Running GENERIC is supposed to make
all stable features and functionality available. The question at hand
is whether those features are compiled in (which would be
"monolithic") or loaded as modules (which would be "modular").
Exactly.
[1] http://en.wikipedia.org/wiki/Voting_paradox
--
Jean-Yves Migeon
jeanyves.mig...@free.fr
pport anymore).
So, one more time: the current issue is to define what people consider
as options that should be enabled by default, and what could stay out
(or as a third party module if you urgently need it back). One example:
accf_* is a questionable choice, whether its inside GENERIC (as a
builtin), or enabled by default in MONOLITHIC.
--
Jean-Yves Migeon
jeanyves.mig...@free.fr
kernel). Needs to be xchecked though.
Note that /stand also includes modules that cannot be included inside a
monolithic kernel, like zfs and solaris compat layer. And these makes up
for ~ half the size of /stand (5MiB).
--
Jean-Yves Migeon
jeanyves.mig...@free.fr
LITHIC (but still having modules as possibility), and that did
not seem to bother people.
So either way, it's fine; but please -- i386 and amd64 should share
common grounds. If some want a MONOLITHIC amd64, it's even possible,
although I can't see the point given the arguments ab
On 19.02.2011 10:27, Bernd Ernesti wrote:
> On Wed, Feb 16, 2011 at 03:16:58AM +0000, Jean-Yves Migeon wrote:
>> Module Name: src
>> Committed By:jym
>> Date:Wed Feb 16 03:16:58 UTC 2011
>>
>> Modified Files:
>> src/sys/arc
On 13.02.2011 17:02, Paul Goyette wrote:
> On Sun, 13 Feb 2011, Jean-Yves Migeon wrote:
>
>> ...
>> For order of preference, see module(7):
>>
>>The loader will look first for a built-in module with the specified
>>name that has not been disabl
On 13.02.2011 14:42, David Laight wrote:
> On Sun, Feb 13, 2011 at 04:37:21AM +0000, Jean-Yves Migeon wrote:
>> Module Name: src Committed By: jym Date: Sun Feb 13
>> 04:37:21 UTC
>> 2011
>>
>> Modified Files: src/sys/arch/i386/conf: GENERI
On 11.02.2011 07:30, Matthias Scheler wrote:
> On Fri, Feb 11, 2011 at 05:06:43AM +0100, Jean-Yves Migeon wrote:
>> Indeed, it would be good to have at least some exec formats and
>> file-systems builtin by default in GENERIC:
>>
>> EXEC_ELF32, _SCRIPT # obvious
>
s where kernel gets
replaced without its associated modules. IIRC, this is why MONOLITHIC
was brought back, due to the number of complaints where GENERIC fails
booting because ffs.kmod or exec_elf32.kmod could not be loaded.
This is what amd64 is approx. doing, but with most file-systems included
by default.
--
Jean-Yves Migeon
jeanyves.mig...@free.fr
On 10.02.2011 22:23, David Laight wrote:
> On Thu, Feb 10, 2011 at 04:49:19PM +0000, Jean-Yves Migeon wrote:
>> Module Name: src
>> Committed By:jym
>> Date:Thu Feb 10 16:49:19 UTC 2011
>>
>> Modified Files:
>> src/sys/arch/i386/
ed uses pmf(9)).
> FWIW, the sleep states that ACPI names are not sufficient even to
> describe all of the potential sleep states of ACPI hardware. I have a
> laptop that's perfectly capable of an "S3-like" sleep, but the ACPI BIOS
> doesn't support S3, and the HDD
On 31.12.2010 11:10, Jukka Ruohonen wrote:
> On Fri, Dec 31, 2010 at 11:01:08AM +0100, Jean-Yves Migeon wrote:
>> I am using machdep.sleep_state as node to put a domU into suspend mode.
>> Up to now, putting sleep_state under machdep allowed powerd(8)
>> sleep_button to be u
in the right direction
IMHO, will it be replaced by a MI interface to put a system into sleep,
as it is not a feature specific to ACPI?
--
Jean-Yves Migeon
jeanyves.mig...@free.fr
On 27.11.2010 18:38, Jean-Yves Migeon wrote:
> Module Name: src
> Committed By: jym
> Date: Sat Nov 27 17:38:49 UTC 2010
>
> Modified Files:
> src/sys/dev/mii: miidevs.h
>
> Log Message:
> Correct string for BCM6709S.
s/BCM6709S/BCM5709S/
--
Jean-Yves Migeon
j...@netbsd.org
anks; I was about to commit the fix.
Second time I got burned on that one :/
--
Jean-Yves Migeon
jeanyves.mig...@free.fr
On 06.10.2010 12:16, Manuel Bouyer wrote:
> On Tue, Oct 05, 2010 at 11:48:17PM +0000, Jean-Yves Migeon wrote:
>> [...]
>>
>> XXX Currently, savecore(8) will fail to dump a PAE kernel in a !PAE
>> environment (and reciprocally). So you need to sync and reboot
>&
r_t being 32 bits.
>
>
Thanks!
--
Jean-Yves Migeon
jeanyves.mig...@free.fr
recisely the "problem" here :)
> while maintaining binary compatibility.
I don't think so; modules that manipulates 32 bits bus_addr_t will likely
fail with PAE when you cross the 4GB boundary. I don't see how the union
could solve that.
--
Jean-Yves Migeon
jeanyves.mig...@free.fr
ernel paddr_t
will not automagically solve the "all PAs are unsigned long" assumption of
kvm(3).
--
Jean-Yves Migeon
jeanyves.mig...@free.fr
t message is not
very clear: the " Will be used by i386 kvm(3) to know the functions that
should [...]" sentence applies to i386_use_pae, not machdep.pae.
It is only there for convenience, eg. when someone wants to know easily if
its system is running under PAE.
--
Jean-Yves Migeon
jeanyves.mig...@free.fr
(u_long).
- i386 will use 64 bits paddr_t for kvm(3), so we will have to discuss on
how to make it work without too much fuzz with pre-64 bits i386 dumps.
- sparse dumps for memory above 4GB.
Eventually, PAE and !PAE kernels core files should be handled by kvm, if
that's what you are asking.
PAE does not affect program core files.
--
Jean-Yves Migeon
jeanyves.mig...@free.fr
r with the booted kernel, not very
practical...). Hence, the sysctl machdep.
> (why the extern in cpu.h? i doesn't seem necessary.)
Yes; I wanted to place it at the same level as i386_use_fxsave.
i386_use_pae may get use elsewhere eventually, so I added it to cpu.h.
--
Jean-Yves Migeon
jeanyves.mig...@free.fr
fixed with "pae_"
(~ some kind of namespace), and alias the relevant function with them in
_KERNEL when option PAE is enabled.
For kvm(3), both could be used; I could extract a value from a symbol
like "pae_enabled" out of a core file through kvm_nlist, then use the
relevant vatop functions.
--
Jean-Yves Migeon
jeanyves.mig...@free.fr
ght 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 for these platforms. But here, i386 and PAE are so
close in concept that it feels like a quirk (at least to me).
--
Jean-Yves Migeon
jeanyves.mig...@free.fr
idth, build.sh runs have
no more than 3% overhead with PAE. So, hmm, between one specific
measurement and real world use... there is quite a gap.
--
Jean-Yves Migeon
jeanyves.mig...@free.fr
hout breaking ABI, needs more
thought that I currently could put in my patch.
Cheers,
--
Jean-Yves Migeon
jeanyves.mig...@free.fr
Besides, I suspect that turning paddr_t to uint64_t will add overhead,
even if the upper 32 bits are always 0 in GENERIC.
> Pleaes fix the amd64 build error reported on current-us...@.
> The build error is related to rump.
Investigating. rumptest just finished for i386 and amd64, and no er
(pae_pl*_pi, pae_pd_entry_t, and so
on). It becomes a matter of calling the proper code within kvm(3), by
checking if PAE was enabled within the kernel dump (through kvm_nlist,
for example).
--
Jean-Yves Migeon
jeanyves.mig...@free.fr
that could be labeled as security-sensitive (not
exploitable directly though). Bumping revision makes it easier to say
"-current under rev 5.99.x is affected, 5.99.x+1 is not".
--
Jean-Yves Migeon
jeanyves.mig...@free.fr
Module Name:src
Committed By: jym
Date: Tue Mar 9 23:12:06 UTC 2010
Modified Files:
src/sys/arch/xen/x86: xen_bus_dma.c
Log Message:
Although Xen's documentation states that the address_bits field is not used
by XENMEM_decrease_reservation, it is checked by the hypervisor
Module Name:src
Committed By: jym
Date: Tue Mar 9 23:12:06 UTC 2010
Modified Files:
src/sys/arch/xen/x86: xen_bus_dma.c
Log Message:
Although Xen's documentation states that the address_bits field is not used
by XENMEM_decrease_reservation, it is checked by the hypervisor
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
operation.
To generate a diff of this commit:
cvs rdiff -u -r1.41 -r1.42 src/sy
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
operation.
To generate a diff of this commit:
cvs rdiff -u -r1.41 -r1.42 src/sy
Module Name:src
Committed By: jym
Date: Tue Mar 2 00:13:50 UTC 2010
Modified Files:
src/sys/arch/xen/x86: xen_bus_dma.c
Log Message:
Catch the return value from the XENMEM_decrease_reservation hypercall,
and not some error value stored earlier.
While here, fix a typo in
Module Name:src
Committed By: jym
Date: Tue Mar 2 00:13:50 UTC 2010
Modified Files:
src/sys/arch/xen/x86: xen_bus_dma.c
Log Message:
Catch the return value from the XENMEM_decrease_reservation hypercall,
and not some error value stored earlier.
While here, fix a typo in
Module Name:src
Committed By: jym
Date: Mon Mar 1 01:35:11 UTC 2010
Modified Files:
src/sys/arch/amd64/amd64: machdep.c
src/sys/arch/i386/i386: machdep.c
Log Message:
Do not forget that ptoa() casts the result to vaddr_t, which is bad
for paddr_t values under i386
Module Name:src
Committed By: jym
Date: Mon Mar 1 01:35:11 UTC 2010
Modified Files:
src/sys/arch/amd64/amd64: machdep.c
src/sys/arch/i386/i386: machdep.c
Log Message:
Do not forget that ptoa() casts the result to vaddr_t, which is bad
for paddr_t values under i386
Module Name:src
Committed By: jym
Date: Mon Mar 1 01:15:24 UTC 2010
Modified Files:
src/sys/arch/i386/i386: machdep.c rbus_machdep.c
src/sys/arch/i386/include: rbus_machdep.h
Log Message:
Change rbus_min_start_hint() semantic for i386. "ram" is now psize_t
(instea
Module Name:src
Committed By: jym
Date: Mon Mar 1 01:15:24 UTC 2010
Modified Files:
src/sys/arch/i386/i386: machdep.c rbus_machdep.c
src/sys/arch/i386/include: rbus_machdep.h
Log Message:
Change rbus_min_start_hint() semantic for i386. "ram" is now psize_t
(instea
Module Name:src
Committed By: jym
Date: Mon Mar 1 00:55:33 UTC 2010
Modified Files:
src/sys/arch/i386/include: pmap.h
Log Message:
Use PDP_SIZE for NTOPLEVEL_PDES (number of top level PDEs) instead of
#ifdef'ing PAE.
To generate a diff of this commit:
cvs rdiff -u -r1.1
1 - 100 of 122 matches
Mail list logo