Re: CVS commit: src/sys/arch/x86/x86

hehehe - porn iterators - love it! On Fri, 15 Oct 2021, Jason Thorpe wrote: I demand this change be reverted. (/s) On Oct 15, 2021, at 11:12 AM, Jared D. McNeill wrote: Module Name:src Committed By: jmcneill Date: Fri Oct 15 18:12:48 UTC 2021 Modified Files:

Re: CVS commit: src/sys/arch/x86/x86

I demand this change be reverted. (/s) > On Oct 15, 2021, at 11:12 AM, Jared D. McNeill wrote: > > Module Name: src > Committed By: jmcneill > Date: Fri Oct 15 18:12:48 UTC 2021 > > Modified Files: > src/sys/arch/x86/x86: tsc.c > > Log Message: > Fix typo in comment:

Re: CVS commit: src/sys/arch/x86

> Module Name:src > Committed By: jdolecek > Date: Sat Aug 1 12:36:36 UTC 2020 > > Modified Files: > src/sys/arch/x86/pci: pci_intr_machdep.c > src/sys/arch/x86/x86: mainbus.c > > Log Message: > reorder includes to pull __HAVE_PCI_MSI_MSIX properly via > If

re: CVS commit: src/sys/arch/x86/x86

"Jaromir Dolecek" writes: > Module Name: src > Committed By: jdolecek > Date: Wed Jun 24 22:28:08 UTC 2020 > > Modified Files: > src/sys/arch/x86/x86: multiboot2.c > > Log Message: > don't try allocating 16KB of scratch space on stack > > it's too early for kmem_alloc(), so use

Re: CVS commit: src/sys/arch/x86/x86

On Wed, Jun 24, 2020 at 10:28:08PM +, Jaromir Dolecek wrote: > Module Name: src > Committed By: jdolecek > Date: Wed Jun 24 22:28:08 UTC 2020 > > Modified Files: > src/sys/arch/x86/x86: multiboot2.c > > Log Message: > don't try allocating 16KB of scratch space on stack > >

Re: CVS commit: src/sys/arch/x86/x86

In article <20200606135850.ge14...@pony.stderr.spb.ru>, Valery Ushakov wrote: >On Sat, Jun 06, 2020 at 11:25:19 +0200, Kamil Rytarowski wrote: > >> On 06.06.2020 09:42, Simon Burge wrote: >> > "Kamil Rytarowski" wrote: >> > >> >> Module Name: src >> >> Committed By: kamil >> >> Date:

Re: CVS commit: src/sys/arch/x86/x86

On Sat, Jun 06, 2020 at 11:25:19 +0200, Kamil Rytarowski wrote: > On 06.06.2020 09:42, Simon Burge wrote: > > "Kamil Rytarowski" wrote: > > > >> Module Name: src > >> Committed By: kamil > >> Date: Fri Jun 5 21:48:04 UTC 2020 > >> > >> Modified Files: > >> > >>

Re: CVS commit: src/sys/arch/x86/x86

On 06.06.2020 09:42, Simon Burge wrote: > "Kamil Rytarowski" wrote: > >> Module Name: src >> Committed By:kamil >> Date:Fri Jun 5 21:48:04 UTC 2020 >> >> Modified Files: >> >> src/sys/arch/x86/x86: cpu_rng.c >> >> Log Message: >> >> Change const unsigned to

Re: CVS commit: src/sys/arch/x86/x86

"Kamil Rytarowski" wrote: > Module Name: src > Committed By: kamil > Date: Fri Jun 5 21:48:04 UTC 2020 > > Modified Files: > > src/sys/arch/x86/x86: cpu_rng.c > > Log Message: > > Change const unsigned to preprocessor define > > Fixes GCC -O0 build with the stack protector.

Re: CVS commit: src/sys/arch/x86/x86

Hi, Hmm, but TSC drift is still observed on recent (high clock) CPUs. I will have researched and fix later. On 2020/04/03 12:05, Kengo NAKAHARA wrote: Module Name:src Committed By: knakahara Date: Fri Apr 3 03:05:39 UTC 2020 Modified Files: src/sys/arch/x86/x86: tsc.c

Re: CVS commit: src/sys/arch/x86/acpi

On Wed, Mar 18, 2020 at 09:44:03PM +0200, Yorick Hardy wrote: > Dear Andrew, > > On 2020-03-14, Andrew Doran wrote: > > Module Name:src > > Committed By: ad > > Date: Sat Mar 14 13:50:46 UTC 2020 > > > > Modified Files: > > src/sys/arch/x86/acpi: acpi_cpu_md.c > >

Re: CVS commit: src/sys/arch/x86/acpi

Dear Andrew, On 2020-03-14, Andrew Doran wrote: > Module Name: src > Committed By: ad > Date: Sat Mar 14 13:50:46 UTC 2020 > > Modified Files: > src/sys/arch/x86/acpi: acpi_cpu_md.c > > Log Message: > Put ACPI idle under ACPICPU_ENABLE_C3 until the wrinkles are ironed out. > This

Re: CVS commit: src/sys/arch/x86/x86

On Tue, Mar 17, 2020 at 10:38:14PM +, Andrew Doran wrote: > Log Message: > - Change some expensive checks DEBUG -> DIAGNOSTIC. That was meant to be the other way around, oops. Andrew

Re: CVS commit: src/sys/arch/x86

We should absolutely verify this under DEBUG. -- thorpej Sent from my iPhone. > On Jan 12, 2020, at 11:25 AM, Joerg Sonnenberger wrote: > > On Sun, Jan 12, 2020 at 01:01:12PM +, Andrew Doran wrote: >> Module Name:src >> Committed By:ad >> Date:Sun Jan 12 13:01:12 UTC 2020

Re: CVS commit: src/sys/arch/x86

On Sun, Jan 12, 2020 at 08:25:27PM +0100, Joerg Sonnenberger wrote: > On Sun, Jan 12, 2020 at 01:01:12PM +, Andrew Doran wrote: > > Module Name:src > > Committed By: ad > > Date: Sun Jan 12 13:01:12 UTC 2020 > > > > Modified Files: > > src/sys/arch/x86/include:

Re: CVS commit: src/sys/arch/x86

On Sun, Jan 12, 2020 at 01:01:12PM +, Andrew Doran wrote: > Module Name: src > Committed By: ad > Date: Sun Jan 12 13:01:12 UTC 2020 > > Modified Files: > src/sys/arch/x86/include: pmap.h pmap_pv.h > src/sys/arch/x86/x86: pmap.c vm_machdep.c x86_tlb.c > > Log Message: >

Re: CVS commit: src/sys/arch/x86/x86

On Tue, Dec 03, 2019 at 01:14:14PM +0100, Kamil Rytarowski wrote: > On 03.12.2019 12:50, Juergen Hannken-Illjes wrote: > > Module Name:src > > Committed By: hannken > > Date: Tue Dec 3 11:50:45 UTC 2019 > > > > Modified Files: > > src/sys/arch/x86/x86:

Re: CVS commit: src/sys/arch/x86/x86

On 03.12.2019 12:50, Juergen Hannken-Illjes wrote: > Module Name: src > Committed By: hannken > Date: Tue Dec 3 11:50:45 UTC 2019 > > Modified Files: > src/sys/arch/x86/x86: x86_machdep.c > > Log Message: > Make sure the assignment to "idepth" is done inside the loop to prevent >

Re: CVS commit: src/sys/arch/x86

Maxime Villard wrote: > Module Name: src > Committed By: maxv > Date: Wed Nov 27 06:24:33 UTC 2019 > > Modified Files: > src/sys/arch/x86/include: cpu.h fpu.h > src/sys/arch/x86/x86: cpu.c fpu.c > > Log Message: > Add a small API for in-kernel FPU operations. > >

Re: CVS commit: src/sys/arch/x86

Hi, On Tue, Nov 12, 2019 at 06:00:13PM +, Maxime Villard wrote: > Committed By: maxv > Date: Tue Nov 12 18:00:13 UTC 2019 > Modified Files: > src/sys/arch/x86/include: specialreg.h > src/sys/arch/x86/x86: spectre.c > Log Message: > Mitigation for CVE-2019-11135: TSX

Re: CVS commit: src/sys/arch/x86/pci

Hi, On 2019/08/19 14:25, Kengo NAKAHARA wrote: Module Name:src Committed By: knakahara Date: Mon Aug 19 05:25:38 UTC 2019 Modified Files: src/sys/arch/x86/pci: if_vmx.c Log Message: add vmx(4) basic statistics counters. Sorry, I have forgotten this TODO in r1.40

Re: CVS commit: src/sys/arch/x86/x86

On 2019/05/16 13:20, Jason Thorpe wrote: > > >> On May 15, 2019, at 9:19 PM, Maxime Villard wrote: >> >> Le 16/05/2019 à 04:36, SAITOH Masanobu a écrit : >>> Module Name:src >>> Committed By: msaitoh >>> Date: Thu May 16 02:36:30 UTC 2019 >>> Modified Files: >>>

Re: CVS commit: src/sys/arch/x86/x86

On 2019/05/16 13:19, Maxime Villard wrote: > Le 16/05/2019 à 04:36, SAITOH Masanobu a écrit : >> Module Name:    src >> Committed By:    msaitoh >> Date:    Thu May 16 02:36:30 UTC 2019 >> >> Modified Files: >> src/sys/arch/x86/x86: procfs_machdep.c >> >> Log Message: >>   Use

Re: CVS commit: src/sys/arch/x86/x86

> On May 15, 2019, at 9:19 PM, Maxime Villard wrote: > > Le 16/05/2019 à 04:36, SAITOH Masanobu a écrit : >> Module Name: src >> Committed By:msaitoh >> Date:Thu May 16 02:36:30 UTC 2019 >> Modified Files: >> src/sys/arch/x86/x86: procfs_machdep.c >> Log Message:

Re: CVS commit: src/sys/arch/x86/x86

Le 16/05/2019 à 04:36, SAITOH Masanobu a écrit : Module Name:src Committed By: msaitoh Date: Thu May 16 02:36:30 UTC 2019 Modified Files: src/sys/arch/x86/x86: procfs_machdep.c Log Message: Use ci_feat_val[7] instead of directly getting cpuid 7 edx. To generate a

Re: CVS commit: src/sys/arch/x86/acpi

> On Mar 3, 2019, at 10:31 AM, m...@netbsd.org wrote: > > Maybe we can use the longer name to avoid the confusion? PG_WIRED > > (PG_W as writable exists in other archs, and there's precedence for > PG_WIRED too) Agreed, PG_WIRED is a better name for this. -- thorpej

Re: CVS commit: src/sys/arch/x86/acpi

On Sun, Mar 03, 2019 at 05:33:33PM +, Maxime Villard wrote: > Module Name: src > Committed By: maxv > Date: Sun Mar 3 17:33:33 UTC 2019 > > Modified Files: > src/sys/arch/x86/acpi: acpi_machdep.c > > Log Message: > Fix bug, PG_W is 'wired', not 'writable'. Maybe we can use

Re: CVS commit: src/sys/arch/x86

Le 13/02/2019 à 10:08, Cherry G.Mathew a écrit : (resent to source-changes-d@) "Maxime Villard" writes: - There is no recursive slot possible, so we can't use pmap_map_ptes(). Rather, we walk down the EPT trees via the direct map, and that's actually a lot simpler (and probably

Re: CVS commit: src/sys/arch/x86

(resent to source-changes-d@) "Maxime Villard" writes: [...] > > Contrary to AMD-SVM, Intel-VMX uses a different set of PTE bits from > native, and this has three important consequences: > > - We can't use the native PTE bits, so each time we want to modify the >page tables, we need to

Re: CVS commit: src/sys/arch/x86/x86

Maxime Villard writes: > Can we do something about it now? It's been more than a week, and the issue is > still there. NVMM still doesn't modload, same for procfs, and GENERIC_KASLR > doesn't work either. > > This needs to be fixed now, and we should not start adding random hacks all > over the

Re: CVS commit: src/sys/arch/x86/x86

Can we do something about it now? It's been more than a week, and the issue is still there. NVMM still doesn't modload, same for procfs, and GENERIC_KASLR doesn't work either. This needs to be fixed now, and we should not start adding random hacks all over the place (like the one below). Le

Re: CVS commit: src/sys/arch/x86

Le 07/12/2018 à 17:29, Jaromír Doleček a écrit : Maybe I missed something earlier - does KASLR being enabled by default mean that x86 now doesn't any more use the direct map to copy memory pages? No. The direct map is still there and still used, the only thing is that its location is

Re: CVS commit: src/sys/arch/x86

Maybe I missed something earlier - does KASLR being enabled by default mean that x86 now doesn't any more use the direct map to copy memory pages? Jaromir Le ven. 7 déc. 2018 à 16:47, Maxime Villard a écrit : > > Module Name:src > Committed By: maxv > Date: Fri Dec 7 15:47:11

re: CVS commit: src/sys/arch/x86/x86

Joerg Sonnenberger writes: > On Tue, Dec 04, 2018 at 07:27:22PM +, Cherry G. Mathew wrote: > > Module Name:src > > Committed By: cherry > > Date: Tue Dec 4 19:27:22 UTC 2018 > > > > Modified Files: > > src/sys/arch/x86/x86: cpu.c intr.c > > > > Log Message: >

Re: CVS commit: src/sys/arch/x86/x86

On Tue, Dec 04, 2018 at 07:27:22PM +, Cherry G. Mathew wrote: > Module Name: src > Committed By: cherry > Date: Tue Dec 4 19:27:22 UTC 2018 > > Modified Files: > src/sys/arch/x86/x86: cpu.c intr.c > > Log Message: > Hypothetically speaking, if one were to want to compile a >

Re: CVS commit: src/sys/arch/x86/pci

On Mon, Sep 10, 2018 at 02:49:23AM +, Cherry G. Mathew wrote: > Module Name: src > Committed By: cherry > Date: Mon Sep 10 02:49:23 UTC 2018 > > Modified Files: > src/sys/arch/x86/pci: pci_intr_machdep.c > > Log Message: > In the NIOAPIC case, we do not need to support

re: CVS commit: src/sys/arch/x86

"Maxime Villard" writes: > Module Name: src > Committed By: maxv > Date: Tue Aug 7 10:50:12 UTC 2018 > > Modified Files: > src/sys/arch/x86/include: specialreg.h > src/sys/arch/x86/x86: errata.c > > Log Message: > Add five errata for AMD Family 17h (Ryzen etc), tested by

Re: CVS commit: src/sys/arch/x86/include

On Sun, 15 Jul 2018, Paul Goyette wrote: Any chance that this will fix kern/52919? If not, can we do some additional re-arrangement of struct cpu_info to address the problem? And in any case, shouldn't this cause a bump in kernel version, since you've changed a structure that is shared

Re: CVS commit: src/sys/arch/x86/include

Any chance that this will fix kern/52919? If not, can we do some additional re-arrangement of struct cpu_info to address the problem? On Sun, 15 Jul 2018, Maxime Villard wrote: Module Name:src Committed By: maxv Date: Sun Jul 15 08:47:43 UTC 2018 Modified Files:

Re: CVS commit: src/sys/arch/x86/x86

On 08.07.2018 15:56, Christos Zoulas wrote: > In article <20180708092413.gb8...@mail.duskware.de>, > Martin Husemann wrote: >> On Sun, Jul 08, 2018 at 10:49:53AM +0200, Jaromír Dole?ek wrote: Module Name:src Committed By: kamil Date: Sat Jul 7 23:05:50 UTC 2018

Re: CVS commit: src/sys/arch/x86/x86

On 08.07.2018 10:49, Jaromír Doleček wrote: > Shouldn't this: > > memtop |= (uint16_t)mpbios_page[0x414] << 8; > > be actually << 16 to keep the same semantics? > No. This is a 2-byte (x86 word) variable. One byte has to be stored with the 8 bits shift. If it would be differently it would

Re: CVS commit: src/sys/arch/x86/x86

In article <20180708092413.gb8...@mail.duskware.de>, Martin Husemann wrote: >On Sun, Jul 08, 2018 at 10:49:53AM +0200, Jaromír Dole?ek wrote: >> > Module Name:src >> > Committed By: kamil >> > Date: Sat Jul 7 23:05:50 UTC 2018 >> > >> > Modified Files: >> >

Re: CVS commit: src/sys/arch/x86/x86

On Sun, Jul 08, 2018 at 10:49:53AM +0200, Jaromír Dole?ek wrote: > > Module Name:src > > Committed By: kamil > > Date: Sat Jul 7 23:05:50 UTC 2018 > > > > Modified Files: > > src/sys/arch/x86/x86: mpbios.c > > > > Log Message: > > Remove unaligned access to mpbios_page[] >

Re: CVS commit: src/sys/arch/x86/x86

Shouldn't this: memtop |= (uint16_t)mpbios_page[0x414] << 8; be actually << 16 to keep the same semantics? Jaromir Le dim. 8 juil. 2018 à 01:05, Kamil Rytarowski a écrit : > > Module Name:src > Committed By: kamil > Date: Sat Jul 7 23:05:50 UTC 2018 > > Modified Files: >

Re: CVS commit: src/sys/arch/x86/x86

Le 22/06/2018 à 03:40, matthew green a écrit : "Maxime Villard" writes: Module Name:src Committed By: maxv Date: Tue Jun 19 09:25:13 UTC 2018 Modified Files: src/sys/arch/x86/x86: fpu.c Log Message: When using EagerFPU, create the fpu state in execve at IPL_HIGH. why

re: CVS commit: src/sys/arch/x86/x86

"Maxime Villard" writes: > Module Name: src > Committed By: maxv > Date: Tue Jun 19 09:25:13 UTC 2018 > > Modified Files: > src/sys/arch/x86/x86: fpu.c > > Log Message: > When using EagerFPU, create the fpu state in execve at IPL_HIGH. why splhigh instead of kpreempt_disable()?

Re: CVS commit: src/sys/arch/x86/x86

> On Jun 7, 2018, at 7:59 AM, m...@netbsd.org wrote: > > You've changed a default and selectively fixed the one driver that > people noticed breaks from it. How do you know the rest aren't broken? As you know, there is very little certainty in this world. For example, how can I be certain

Re: CVS commit: src/sys/arch/x86/x86

You've changed a default and selectively fixed the one driver that people noticed breaks from it. How do you know the rest aren't broken? On Thu, Jun 07, 2018 at 01:35:31PM +, Jason R Thorpe wrote: > Module Name: src > Committed By: thorpej > Date: Thu Jun 7 13:35:31 UTC 2018 > >

Re: CVS commit: src/sys/arch/x86/x86

Le 07/02/2018 à 23:49, Maya Rashish a écrit : Module Name:src Committed By: maya Date: Wed Feb 7 22:49:32 UTC 2018 Modified Files: src/sys/arch/x86/x86: identcpu.c Log Message: stopgap fix: restrict XSAVEOPT to Intel CPUs The current code causes floating point

Re: CVS commit: src/sys/arch/x86/pci

On Thu, 25 Jan 2018, Patrick Welche wrote: Module Name:src Committed By: prlw1 Date: Thu Jan 25 15:01:05 UTC 2018 Modified Files: src/sys/arch/x86/pci: amdzentemp.c Log Message: Unused variable build fix. (now void *aux is unused) To generate a diff of this commit:

Re: CVS commit: src/sys/arch/x86/x86

On 2018/01/11 18:18, SAITOH Masanobu wrote: Module Name:src Committed By: msaitoh Date: Thu Jan 11 09:18:16 UTC 2018 Modified Files: src/sys/arch/x86/x86: cpu.c Log Message: Changing CR4 register may change cpuid values. For example, setting CR4_OSXSAVE sets

Re: CVS commit: src/sys/arch/x86/x86

This is really impressive and great work! On 21.10.2017 21:05, Alistair Crooks wrote: > Oh, nice! This is great :) > > Thank you for all your work on this, pkboot, kaslr and the pmap. > > Best, > Alistair > > On 21 October 2017 at 01:27, Maxime Villard wrote: >> Module Name:

Re: CVS commit: src/sys/arch/x86/x86

Oh, nice! This is great :) Thank you for all your work on this, pkboot, kaslr and the pmap. Best, Alistair On 21 October 2017 at 01:27, Maxime Villard wrote: > Module Name:src > Committed By: maxv > Date: Sat Oct 21 08:27:19 UTC 2017 > > Modified Files: >

Re: CVS commit: src/sys/arch/x86/x86

In article <20171017054709.b160cf...@cvs.netbsd.org>, Maya Rashish wrote: >-=-=-=-=-=- > >Module Name: src >Committed By: maya >Date: Tue Oct 17 05:47:09 UTC 2017 > >Modified Files: > src/sys/arch/x86/x86: vmt.c > >Log Message: >Check that the host

Re: CVS commit: src/sys/arch/x86/x86

On Thu, Oct 05, 2017 at 02:52:55PM +0200, Kamil Rytarowski wrote: > An idea borrowed from the OpenBSD approach with wxneeded partition > (mount) property. I think that one pretty much completely misses the point. Joerg

Re: CVS commit: src/sys/arch/x86/x86

On 04.10.2017 08:35, Alexander Nasonov wrote: > Maxime Villard wrote: >> In the first mail, you said that it was better to have a all-or-nothing >> sysctl, which is *exactly* what I just committed. > > Yes, sysctl is better than giving rdtsc to root only. But "better" > alone isn't strong enough

Re: CVS commit: src/sys/arch/x86/x86

Maxime Villard wrote: > In the first mail, you said that it was better to have a all-or-nothing > sysctl, which is *exactly* what I just committed. Yes, sysctl is better than giving rdtsc to root only. But "better" alone isn't strong enough to count me as a supporter. > In the second one, as a

Re: CVS commit: src/sys/arch/x86/x86

Le 03/10/2017 à 22:47, Alexander Nasonov a écrit : Maxime Villard wrote: In case you didn't notice, this sysctl results directly from the answers I got, and is not my original plan (about which I changed my mind as a consequence of the conversation). So now tell me exactly which point I didn't

Re: CVS commit: src/sys/arch/x86/x86

Maxime Villard wrote: > In case you didn't notice, this sysctl results directly from the answers I > got, and is not my original plan (about which I changed my mind as a > consequence of the conversation). So now tell me exactly which point I didn't > consider and which reply I ignored. The thread

Re: CVS commit: src/sys/arch/x86/x86

If pax mprotect is an example then maxv should just go around rm -rf'ing any parts of the tree he doesn't like without even checking that the kernel builds afterwards, since that's the way we do things around here. It was months until I could run meld again, even disabling it for just python was

Re: CVS commit: src/sys/arch/x86/x86

Le 03/10/2017 à 21:14, Joerg Sonnenberger a écrit : I'm not responding to this nonsensical thread anymore, everything got told months ago. The option is here, people don't need to give a damn about it unless they explicitly want to - which is still legitimate in some cases, including for kaslr,

Re: CVS commit: src/sys/arch/x86/x86

On Tue, Oct 03, 2017 at 06:54:52PM +0200, Maxime Villard wrote: > Just like disabling va0 or enabling PaX mprotect; if you feel like these are > no issues, then what's the fuss. You would be well served to read the "rdtsc > is still enabled by default" part of my email. Disabling va0 is low

Re: CVS commit: src/sys/arch/x86/x86

On Mon, Oct 2, 2017 at 4:09 PM, Taylor R Campbell < campbell+netbsd-source-change...@mumble.net> wrote: > > Date: Mon, 2 Oct 2017 21:42:11 +0200 > > From: Joerg Sonnenberger > > > > On Mon, Oct 02, 2017 at 07:23:16PM +, Maxime Villard wrote: > > > Add a machdep.tsc_user_enable

Re: CVS commit: src/sys/arch/x86/x86

On Mon, Oct 2, 2017 at 4:43 PM, Joerg Sonnenberger wrote: > On Mon, Oct 02, 2017 at 04:25:34PM -0600, Warner Losh wrote: > > Even if you don't have the ability to change the defective hardware? > > The hardware is not defective. We are not talking about variable timing > for basic

Re: CVS commit: src/sys/arch/x86/x86

On Tue, Oct 03, 2017 at 06:54:52PM +0200, Maxime Villard wrote: > I'm not responding to this nonsensical thread anymore, The problem is, you keep acting unilaterally without having gathered a consensus, then ignoring the resulting objections and demanding to have everything your way and only

Re: CVS commit: src/sys/arch/x86/x86

Le 03/10/2017 à 13:26, Joerg Sonnenberger a écrit : At the same time, it has interesting interactions with power management and the instruction queue. The queue is flushed by a serializing instruction executed right before, which is the recommended use case; the interaction with power

Re: CVS commit: src/sys/arch/x86/x86

On Tue, Oct 03, 2017 at 08:17:27AM +0200, Maxime Villard wrote: > What is clear, however, is that the effort needed to perform accurate > measurements in software is much higher than that needed to invoke a hardware > instruction that will instantly give about the most accurate answer possible.

Re: CVS commit: src/sys/arch/x86/x86

On Mon, Oct 02, 2017 at 04:25:34PM -0600, Warner Losh wrote: > Even if you don't have the ability to change the defective hardware? The hardware is not defective. We are not talking about variable timing for basic arithmetic operations based on the operand value. Outside maybe division, that

Re: CVS commit: src/sys/arch/x86/x86

> Date: Mon, 2 Oct 2017 16:25:34 -0600 > From: Warner Losh > > Why should I provide an attacker a stop watch? I want him/her to build > their own that has the potential to be accurate enough, but is necessarily > less accurate than the one I'm denying them access to. There are

Re: CVS commit: src/sys/arch/x86/x86

> Date: Mon, 2 Oct 2017 21:42:11 +0200 > From: Joerg Sonnenberger > > On Mon, Oct 02, 2017 at 07:23:16PM +, Maxime Villard wrote: > > Add a machdep.tsc_user_enable sysctl, to enable/disable the rdtsc > > instruction in usermode. It defaults to enabled. > > Do we really need

Re: CVS commit: src/sys/arch/x86/x86

On Mon, Oct 02, 2017 at 07:23:16PM +, Maxime Villard wrote: > Module Name: src > Committed By: maxv > Date: Mon Oct 2 19:23:16 UTC 2017 > > Modified Files: > src/sys/arch/x86/x86: tsc.c tsc.h x86_machdep.c > > Log Message: > Add a machdep.tsc_user_enable sysctl, to

Re: CVS commit: src/sys/arch/x86/include

Le 29/09/2017 à 05:17, Ryota Ozaki a écrit : Module Name:src Committed By: ozaki-r Date: Fri Sep 29 03:17:18 UTC 2017 Modified Files: src/sys/arch/x86/include: pmap.h Log Message: Fix build sys/arch/x86/x86/cpu.c:920:20: error: 'pmap_largepages' undeclared (first use

Re: CVS commit: src/sys/arch/x86/x86

Hi maxv@n.o, On 2017/08/08 2:12, Maxime Villard wrote: > Le 07/08/2017 à 10:38, Kengo NAKAHARA a écrit : >> "intrctl affinity" in NetBSD-current causes panic. Here is the backtrace >> >> panic: kernel diagnostic assertion "mutex_owned(_lock) || !mp_online" >> failed: file

Re: CVS commit: src/sys/arch/x86/x86

Le 07/08/2017 à 10:38, Kengo NAKAHARA a écrit : Hi maxv@n.o, "intrctl affinity" in NetBSD-current causes panic. Here is the backtrace panic: kernel diagnostic assertion "mutex_owned(_lock) || !mp_online" failed: file

Re: CVS commit: src/sys/arch/x86/x86

Hi maxv@n.o, "intrctl affinity" in NetBSD-current causes panic. Here is the backtrace panic: kernel diagnostic assertion "mutex_owned(_lock) || !mp_online" failed: file "/disk4/home/k-nakahara/repos/netbsd-src/sys/arch/x86/x86/idt.c", line 122 fatal breakpoint trap in

Re: CVS commit: src/sys/arch/x86/x86

I've found this article: http://coypu.sdf.org/20170525-qemu-smp On 31.05.2017 08:51, Jaromír Doleček wrote: > You rock! Thank you. > > 2017-05-31 2:19 GMT+02:00 Maya Rashish >: > > Module Name:src > Committed By: maya > Date:

Re: CVS commit: src/sys/arch/x86/x86

You rock! Thank you. 2017-05-31 2:19 GMT+02:00 Maya Rashish : > Module Name:src > Committed By: maya > Date: Wed May 31 00:19:17 UTC 2017 > > Modified Files: > src/sys/arch/x86/x86: cpu.c > > Log Message: > Do not pause many times between testing if the

Re: CVS commit: src/sys/arch/x86/pci

> #define VMXNET3_CORE_LOCK_ASSERT(_sc)mutex_owned((_sc)->vmx_mtx) > > #define VMXNET3_RXQ_LOCK_ASSERT(_rxq)\ > mutex_owned((_rxq)->vxrxq_mtx) > #define VMXNET3_TXQ_LOCK_ASSERT(_txq)\ > mutex_owned((_txq)->vxtxq_mtx) These should probably

Re: CVS commit: src/sys/arch/x86

I see Robert added hack meanwhile, I'll look at proper fix tomorrow. Jaromir 2016-10-16 0:23 GMT+02:00 Joerg Sonnenberger : > On Sat, Oct 15, 2016 at 04:46:15PM +, Jaromir Dolecek wrote: >> Module Name: src >> Committed By: jdolecek >> Date: Sat Oct 15 16:46:14 UTC

Re: CVS commit: src/sys/arch/x86

Date:Sun, 16 Oct 2016 02:14:27 +0200 From:Joerg Sonnenberger Message-ID: <20161016001427.ga7...@britannica.bec.de> | > I haven't compile tested it yet, but I think it needs: | See second sentence :) Obviously I had ... I just didn't originally

Re: CVS commit: src/sys/arch/x86

On Sun, Oct 16, 2016 at 06:59:53AM +0700, Robert Elz wrote: > Date:Sun, 16 Oct 2016 00:23:20 +0200 > From:Joerg Sonnenberger > Message-ID: <20161015222320.ga4...@britannica.bec.de> > > | On Sat, Oct 15, 2016 at 04:46:15PM +, Jaromir Dolecek wrote:

Re: CVS commit: src/sys/arch/x86

Date:Sun, 16 Oct 2016 00:23:20 +0200 From:Joerg Sonnenberger Message-ID: <20161015222320.ga4...@britannica.bec.de> | On Sat, Oct 15, 2016 at 04:46:15PM +, Jaromir Dolecek wrote: | > Modified Files: | > src/sys/arch/x86/acpi: acpi_machdep.c

Re: CVS commit: src/sys/arch/x86

On Sat, Oct 15, 2016 at 04:46:15PM +, Jaromir Dolecek wrote: > Module Name: src > Committed By: jdolecek > Date: Sat Oct 15 16:46:14 UTC 2016 > > Modified Files: > src/sys/arch/x86/acpi: acpi_machdep.c > src/sys/arch/x86/include: isa_machdep.h >

Re: CVS commit: src/sys/arch/x86/x86

Le 20/07/2016 à 07:07, Takashi YAMAMOTO a écrit : On Wed, Jul 20, 2016 at 3:54 AM, Maxime Villard > wrote: Module Name:src Committed By: maxv Date: Tue Jul 19 18:54:45 UTC 2016 Modified Files:

Re: CVS commit: src/sys/arch/x86/x86

On Wed, Jul 20, 2016 at 3:54 AM, Maxime Villard wrote: > Module Name:src > Committed By: maxv > Date: Tue Jul 19 18:54:45 UTC 2016 > > Modified Files: > src/sys/arch/x86/x86: pmap.c > > Log Message: > This loop makes no sense at all. > - can you provide

Re: CVS commit: src/sys/arch/x86/x86

Hi, On 2016/07/12 0:21, David Holland wrote: > On Mon, Jul 11, 2016 at 09:42:20AM +, Kengo NAKAHARA wrote: > > Log Message: > > strncpy should use destination buf length instead of source buf length. > > > > pointed out by nonaka@n.o. > > this should almost certainly be strlcpy, not

Re: CVS commit: src/sys/arch/x86/x86

On Mon, Jul 11, 2016 at 09:42:20AM +, Kengo NAKAHARA wrote: > Log Message: > strncpy should use destination buf length instead of source buf length. > > pointed out by nonaka@n.o. this should almost certainly be strlcpy, not strncpy. -- David A. Holland dholl...@netbsd.org

Re: CVS commit: src/sys/arch/x86/x86

Le 01/07/2016 à 16:22, matthew green a écrit : We use only one L4 slot for the direct map, which means that we cannot map more than 512GB. Panic properly if this limit is reached. thanks for making the failure mode clear. it would be nice to remove this limitation, and support upto at least

Re: CVS commit: src/sys/arch/x86/x86

Le 01/07/2016 à 16:24, matthew green a écrit : Log Message: Surprisingly enough, the kernel expects the CPU to support large pages when creating the direct map on amd64. Therefore, the amd64 CPUs that do not support large pages basically don't work on NetBSD. It looks like it has always been

re: CVS commit: src/sys/arch/x86/x86

> Log Message: > Surprisingly enough, the kernel expects the CPU to support large pages > when creating the direct map on amd64. Therefore, the amd64 CPUs that do > not support large pages basically don't work on NetBSD. > > It looks like it has always been this way; add a KASSERT to panic >

re: CVS commit: src/sys/arch/x86/x86

> We use only one L4 slot for the direct map, which means that we cannot > map more than 512GB. Panic properly if this limit is reached. thanks for making the failure mode clear. it would be nice to remove this limitation, and support upto at least 16TB of ram. systems with well over 512GB are

Re: CVS commit: src/sys/arch/x86/x86

On Fri, Jul 01, 2016 at 11:44:05AM +, Maxime Villard wrote: > Log Message: > Use pmap_bootstrap_valloc and pmap_bootstrap_palloc under XEN at least > once, for these not to appear as unused functions (not tested, but I > guess). Maybe __used or ifndef XEN?

Re: CVS commit: src/sys/arch/x86/x86

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. >>> >>> >>> To generate a diff of this commit:

Re: CVS commit: src/sys/arch/x86/x86

On 2015/10/06 6:10, Jean-Yves Migeon wrote: Le 04/10/2015 19:52, matthew green a écrit : Module Name:src Committed By: mrg Date: Sun Oct 4 17:52:50 UTC 2015 Modified Files: src/sys/arch/x86/x86: cpu_ucode_intel.c Log Message: kmem_free() the address returned by

Re: CVS commit: src/sys/arch/x86/x86

Le 04/10/2015 19:52, matthew green a écrit : > Module Name: src > Committed By: mrg > Date: Sun Oct 4 17:52:50 UTC 2015 > > Modified Files: > src/sys/arch/x86/x86: cpu_ucode_intel.c > > Log Message: > kmem_free() the address returned by kmem_alloc(). found by Brainy. > use the

Re: CVS commit: src/sys/arch/x86/pci

On 2015/08/13 13:52, SAITOH Masanobu wrote: Module Name:src Committed By: msaitoh Date: Thu Aug 13 04:52:40 UTC 2015 Modified Files: src/sys/arch/x86/pci: msipic.c Log Message: Add workaround for PCI prefetchable bit in msipic_construct_msix_pic(). Some chips (e.g.

Re: CVS commit: src/sys/arch/x86/x86

On 2015/05/18 22:09, SAITOH Masanobu wrote: Module Name:src Committed By: msaitoh Date: Mon May 18 13:09:55 UTC 2015 Modified Files: src/sys/arch/x86/x86: cpu.c Log Message: PS. Revert previous. To generate a diff of this commit: cvs rdiff -u -r1.114 -r1.115

Re: CVS commit: src/sys/arch/x86/pci

On Sat, Oct 18, 2014 at 5:55 AM, Masao Uebayashi uebay...@netbsd.org wrote: Module Name:src Committed By: uebayasi Date: Fri Oct 17 20:55:21 UTC 2014 Modified Files: src/sys/arch/x86/pci: files.pci Log Message: Fix another indirect circular dependency (agp_* -

Re: CVS commit: src/sys/arch/x86/x86

On Tue, Oct 14, 2014 at 03:16:56AM +, John Nemeth wrote: Module Name: src Committed By: jnemeth Date: Tue Oct 14 03:16:56 UTC 2014 Modified Files: src/sys/arch/x86/x86: identcpu.c Log Message: Force x86_xsave_features to 0 when running under XEN for AMD processors.

Re: CVS commit: src/sys/arch/x86/acpi

On Thu, Apr 17, 2014 at 12:01:24PM -0400, Christos Zoulas wrote: Module Name: src Committed By: christos Date: Thu Apr 17 16:01:24 UTC 2014 Modified Files: src/sys/arch/x86/acpi: acpi_cpu_md.c Log Message: CID/1203191: Out of bounds read Oh, nasty. The code was pretty

  1   2   >