Hi all,
I will upgrade the Web Server Operating System upcoming Monday
(2015/10/19) around 11:00 CEST. During this time, the ReactOS Website
and related services will be temporarily offline.
As always, I will try to keep the downtime low :)
Cheers,
Colin
This is wrong, wrong, wrong.
1) The feature needs to be enabled on all processors, not just one. There's
a reason for that loop.
2) ValidKernelPte/Pde being marked global will make ALL kernel pages
global. This is probably not what you want.
Best regards,
Alex Ionescu
On Wed, Oct 14, 2015 at 12:33 PM, <sginsberg(a)svn.reactos.org> wrote:
> Author: sginsberg
> Date: Wed Oct 14 19:33:35 2015
> New Revision: 69528
>
> URL: http://svn.reactos.org/svn/reactos?rev=69528&view=rev
> Log:
> [NTOS]
> Add super-complicated handling of global pages to KeFlushCurrentTb (pretty
> much the same code which has been in HalpFlushTLB for the past ~6 years).
> This should be all that is required to make this feature work (everything
> else being in place already), and *seems* to work fine but is disabled
> under a switch until tested thoroughly.
>
> Global pages, an important optimization that allows for not flushing the
> whole x86 TLB every time CR3 is changed (typically on context switch to a
> new process, or during process attach/detach), relies on us doing extra
> work whenever we do alter a global page. This is likely where any bugs will
> have to be flushed out!
>
> Fixup Ki386EnableGlobalPage while we are at it -- disable/restore
> interrupts properly, and verify PGE-bit isn't set (nothing should have
> touched it before this routine, which is responsible for initializing it,
> so we shouldn't have to disable it). Fix, but disable, the CPU-sync spin as
> well as there should be no particular reason to do this for PGE-enabling
> during initialization (no other processor will be messing with PTEs at this
> stage, as compared to a call to KeFlushEntireTb).
>
> Everyone, repeat after me: Global pages are awesome!
>
> Modified:
> trunk/reactos/ntoskrnl/include/ntoskrnl.h
> trunk/reactos/ntoskrnl/ke/i386/cpu.c
> trunk/reactos/ntoskrnl/ke/i386/patpge.c
> trunk/reactos/ntoskrnl/mm/ARM3/i386/init.c
>
> Modified: trunk/reactos/ntoskrnl/include/ntoskrnl.h
> URL:
> http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/include/ntoskrnl.…
>
> ==============================================================================
> --- trunk/reactos/ntoskrnl/include/ntoskrnl.h [iso-8859-1] (original)
> +++ trunk/reactos/ntoskrnl/include/ntoskrnl.h [iso-8859-1] Wed Oct 14
> 19:33:35 2015
> @@ -98,6 +98,14 @@
> #define ASSERT NT_ASSERT
> #endif
>
> +
> +//
> +// Switch for enabling global page support
> +//
> +
> +//#define _GLOBAL_PAGES_ARE_AWESOME_
> +
> +
> /* Internal Headers */
> #include "internal/ntoskrnl.h"
> #include "config.h"
>
> Modified: trunk/reactos/ntoskrnl/ke/i386/cpu.c
> URL:
> http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ke/i386/cpu.c?rev…
>
> ==============================================================================
> --- trunk/reactos/ntoskrnl/ke/i386/cpu.c [iso-8859-1] (original)
> +++ trunk/reactos/ntoskrnl/ke/i386/cpu.c [iso-8859-1] Wed Oct 14
> 19:33:35 2015
> @@ -878,8 +878,37 @@
> NTAPI
> KeFlushCurrentTb(VOID)
> {
> +
> +#if !defined(_GLOBAL_PAGES_ARE_AWESOME_)
> +
> /* Flush the TLB by resetting CR3 */
> __writecr3(__readcr3());
> +
> +#else
> +
> + /* Check if global pages are enabled */
> + if (KeFeatureBits & KF_GLOBAL_PAGE)
> + {
> + ULONG Cr4;
> +
> + /* Disable PGE */
> + Cr4 = __readcr4() & ~CR4_PGE;
> + __writecr4(Cr4);
> +
> + /* Flush everything */
> + __writecr3(__readcr3());
> +
> + /* Re-enable PGE */
> + __writecr4(Cr4 | CR4_PGE);
> + }
> + else
> + {
> + /* No global pages, resetting CR3 is enough */
> + __writecr3(__readcr3());
> + }
> +
> +#endif
> +
> }
>
> VOID
>
> Modified: trunk/reactos/ntoskrnl/ke/i386/patpge.c
> URL:
> http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ke/i386/patpge.c?…
>
> ==============================================================================
> --- trunk/reactos/ntoskrnl/ke/i386/patpge.c [iso-8859-1] (original)
> +++ trunk/reactos/ntoskrnl/ke/i386/patpge.c [iso-8859-1] Wed Oct 14
> 19:33:35 2015
> @@ -17,40 +17,41 @@
>
> /* FUNCTIONS
> *****************************************************************/
>
> +INIT_SECTION
> ULONG_PTR
> NTAPI
> -INIT_FUNCTION
> Ki386EnableGlobalPage(IN ULONG_PTR Context)
> {
> - PLONG Count = (PLONG)Context;
> - ULONG Cr4, Cr3;
> + //PLONG Count;
> +#if defined(_GLOBAL_PAGES_ARE_AWESOME_)
> + ULONG Cr4;
> +#endif
> + BOOLEAN Enable;
>
> /* Disable interrupts */
> - _disable();
> -
> - /* Decrease CPU Count and loop until it's reached 0 */
> - do {InterlockedDecrement(Count);} while (!*Count);
> -
> - /* Now check if this is the Boot CPU */
> - if (!KeGetPcr()->Number)
> - {
> - /* It is.FIXME: Patch KeFlushCurrentTb */
> - }
> -
> - /* Now get CR4 and make sure PGE is masked out */
> + Enable = KeDisableInterrupts();
> +
> + /* Spin until other processors are ready */
> + //Count = (PLONG)Context;
> + //InterlockedDecrement(Count);
> + //while (*Count) YieldProcessor();
> +
> +#if defined(_GLOBAL_PAGES_ARE_AWESOME_)
> +
> + /* Get CR4 and ensure global pages are disabled */
> Cr4 = __readcr4();
> - __writecr4(Cr4 & ~CR4_PGE);
> -
> - /* Flush the TLB */
> - Cr3 = __readcr3();
> - __writecr3(Cr3);
> + ASSERT(!(Cr4 & CR4_PGE));
> +
> + /* Reset CR3 to flush the TLB */
> + __writecr3(__readcr3());
>
> /* Now enable PGE */
> - DPRINT("Global page support detected but not yet taken advantage
> of\n");
> - //__writecr4(Cr4 | CR4_PGE);
> -
> - /* Restore interrupts */
> - _enable();
> + __writecr4(Cr4 | CR4_PGE);
> +
> +#endif
> +
> + /* Restore interrupts and return */
> + KeRestoreInterrupts(Enable);
> return 0;
> }
>
>
> Modified: trunk/reactos/ntoskrnl/mm/ARM3/i386/init.c
> URL:
> http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/mm/ARM3/i386/init…
>
> ==============================================================================
> --- trunk/reactos/ntoskrnl/mm/ARM3/i386/init.c [iso-8859-1] (original)
> +++ trunk/reactos/ntoskrnl/mm/ARM3/i386/init.c [iso-8859-1] Wed Oct 14
> 19:33:35 2015
> @@ -249,15 +249,18 @@
> PMMPFN Pfn1;
> ULONG Flags;
>
> +#if defined(_GLOBAL_PAGES_ARE_AWESOME_)
> +
> /* Check for global bit */
> -#if 0
> if (KeFeatureBits & KF_GLOBAL_PAGE)
> {
> /* Set it on the template PTE and PDE */
> ValidKernelPte.u.Hard.Global = TRUE;
> ValidKernelPde.u.Hard.Global = TRUE;
> }
> +
> #endif
> +
> /* Now templates are ready */
> TempPte = ValidKernelPte;
> TempPde = ValidKernelPde;
>
>
>
This is checking for 8-byte alignment on x86, not 16-byte.
On Sun, Oct 11, 2015 at 2:51 PM, <pschweitzer(a)svn.reactos.org> wrote:
> if (!((ULONG_PTR)Buffers[i] & 0x2))
Best regards,
Alex Ionescu
Hi !
I don't think this commit constitutes a nice improvement for NTVDM at its
present status:
- having the precise list of the used headers in each .c file helped me in
knowing at a glance which functionalities a given .c needed,
- therefore enabling me to find better places where to put the functions and
possibly reduce the number of headers in the future (refactoring).
- This broke my numerous local changes regarding e.g. a modularization of
the CPU layer in NTVDM, video layer, ...
- Finally, stuffing indistinctively *all* the headers (including the private
ones like bios32p.h which purpose was to be used in the sources of one
module only) inside the PCH ntvdm.h, makes for example BIOS or DOS functions
visible inside hardware modules like ps2.h, which is completely illogical
when you try to modularize NTVDM at source level, by completely separating
hardware emulation from bios code and DOS emulation, etc... .
Therefore I will revert your commit tomorrow, while keeping a diff and put
it in a JIRA report.
Cheers,
Hermès.
________________________________________
[ros-diffs] [akhaldi] 69435: [NTVDM] Improve the PCH situation.
akhaldi at svn.reactos.org akhaldi at svn.reactos.org
Sat Oct 3 21:47:46 UTC 2015
Previous message: [ros-diffs] [spetreolle] 69434: [user32_apitest] 0x%lu
does not mean anything correct.
Next message: [ros-diffs] [spetreolle] 69436: [ROSTESTS] Fix 0x%lu
specifier. Add cmake file for notificationtest.
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
________________________________________
Author: akhaldi
Date: Sat Oct 3 21:47:46 2015
New Revision: 69435
URL: http://svn.reactos.org/svn/reactos?rev=69435&view=rev
Log:
[NTVDM] Improve the PCH situation.
On 28/09/2015 11:01, sginsberg(a)svn.reactos.org wrote:
> Author: sginsberg
> Date: Mon Sep 28 09:01:11 2015
> New Revision: 69393
>
> URL: http://svn.reactos.org/svn/reactos?rev=69393&view=rev
> Log:
> [NTOS] Fix the Ob wait system calls to only catch the exceptions that are expected to be raised by the Ke wait functions (and not potentially silently catching *any* exception and corrupting everything in the process). Also fixup some code logic. SEH Mega Fixup 1/???
>
> Modified:
> trunk/reactos/ntoskrnl/ob/obwait.c
>
> Modified: trunk/reactos/ntoskrnl/ob/obwait.c
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ob/obwait.c?rev=6…
> ==============================================================================
> --- trunk/reactos/ntoskrnl/ob/obwait.c [iso-8859-1] (original)
> +++ trunk/reactos/ntoskrnl/ob/obwait.c [iso-8859-1] Mon Sep 28 09:01:11 2015
> @@ -49,12 +49,12 @@
> IN BOOLEAN Alertable,
> IN PLARGE_INTEGER TimeOut OPTIONAL)
> {
> - PKWAIT_BLOCK WaitBlockArray = NULL;
> + PKWAIT_BLOCK WaitBlockArray;
> HANDLE Handles[MAXIMUM_WAIT_OBJECTS], KernelHandle;
> PVOID Objects[MAXIMUM_WAIT_OBJECTS];
> PVOID WaitObjects[MAXIMUM_WAIT_OBJECTS];
> - ULONG i = 0, ReferencedObjects = 0, j;
> - KPROCESSOR_MODE PreviousMode = ExGetPreviousMode();
> + ULONG i, ReferencedObjects, j;
> + KPROCESSOR_MODE PreviousMode;
> LARGE_INTEGER SafeTimeOut;
> BOOLEAN LockInUse;
> PHANDLE_TABLE_ENTRY HandleEntry;
> @@ -65,31 +65,26 @@
> NTSTATUS Status;
> PAGED_CODE();
>
> - /* Enter a critical region since we'll play with handles */
> - LockInUse = TRUE;
> - KeEnterCriticalRegion();
> -
> /* Check for valid Object Count */
> if ((ObjectCount > MAXIMUM_WAIT_OBJECTS) || !(ObjectCount))
> {
> /* Fail */
> - Status = STATUS_INVALID_PARAMETER_1;
> - goto Quickie;
> + return STATUS_INVALID_PARAMETER_1;
> }
>
> /* Check for valid Wait Type */
> if ((WaitType != WaitAll) && (WaitType != WaitAny))
> {
> /* Fail */
> - Status = STATUS_INVALID_PARAMETER_3;
> - goto Quickie;
> - }
> -
> - /* Enter SEH */
> - _SEH2_TRY
> - {
> - /* Check if the call came from user mode */
> - if (PreviousMode != KernelMode)
> + return STATUS_INVALID_PARAMETER_3;
> + }
> +
> + /* Enter SEH for user mode */
> + PreviousMode = ExGetPreviousMode();
> + if (PreviousMode != KernelMode)
> + {
> + /* Enter SEH */
> + _SEH2_TRY
No, this is plain wrong.
This is not because you're in kernel mode that the world is marvelous
and callers trustable.
A caller can pass you buggy address and you HAVE to wrap the
RtlCopyMemory in SEH to make sure that if a buggy address is passed, the
whole system isn't brought down (that's the whole purpose of the copy
after all!).
In case you have a doubt, just put some random:
Status = ZwWaitForMultipleObjects(2, (void **)0x42424242, WaitAll,
FALSE, NULL);
In a kernel component. In w2k3, you'll get Status = STATUS_ACCESS_VIOLATION
In ReactOS, with your changes: BSOD.
Please before doing random changes that you believe are right: do testing.
Alex already told you that.
Cheers,
--
Pierre Schweitzer <pierre at reactos.org>
System & Network Administrator
Senior Kernel Developer
ReactOS Deutschland e.V.
Hello,
Let me invite you to the monthly status meeting taking place last
Thursday of a month, 24th of September, 19:00 UTC, as usual.
IRC service will only be started shortly before the meeting. Your
participation passwords and server address will be emailed to you
shortly before the meeting starts, and they are going to be different
once again as they are not stored in any database. Hopefully it's not
much of inconvenience.
Please send agenda proposals to me before the meeting.
Regards,
Aleksey Bragin
ion(a)svn.reactos.org wrote:
> - Add correct MS-PL (Public) License. Not added to build/used, but I
> need some of the headers/data structures in here.
> - Source:
https://github.com/Microsoft/Windows-driver-samples/blob/master/filesys/cdfs
Yay! No more messing around with DDK licenses!
Someone should take the other samples there and replace our DDK-inspired
components (e.g. classpnp and disk) by these ones licensed under MS-PL.
Cheers,
Colin
hbelusca(a)svn.reactos.org wrote:
> +// FIXME! FIXME! Do it in a portable way!!
> typedef unsigned char BYTE;
> typedef unsigned short WORD;
> typedef unsigned long DWORD;
Try using our include/host/typedefs.h, which provides the most popular
Windows type definitions in a portable way.
- Colin
cwittich(a)svn.reactos.org wrote:
> Modified: trunk/reactos/base/applications/cmdutils/mode/mode.c
What is that tool for anyway?
Windows has a 16-bit "mode.com" for compatibility and I believe the
actual "mode" command is built-in into cmd.exe these days.
Cheers,
Colin
On 2015-09-04 03:14, hbelusca(a)svn.reactos.org wrote:
> Also I suggest we turn this file (and maybe also /lib/sdk/crt/except/i386/cpp.s) into a "msvc-thiscall.c" as it is already done in some other DLLs (like in ole32, riched20).
ole32 and riched20 don't export mangled names.
MSVC ignores redirects for them in the def file so it needs to be
assembly (or C++ code).
On 2015-08-22 13:16, bfreisen(a)svn.reactos.org wrote:
> [HHPCOMP]
> Improve functionality of Windows MSVC build. Based on a WIP patch by Michael Fritscher.
> See CORE-10019.
> +/* if O_BINARY is not defined, the system is probably not expecting any such flag */
> +#ifndef O_BINARY
> +#define O_BINARY 0
> +#endif
> - chm->fd = creat(filename, 0644);
> + chm->fd = open(filename, O_RDWR | O_CREAT | O_TRUNC | O_BINARY, 0644);
Hmm... fopen wouldn't have this problem ;)
On 2015-08-18 14:26, hbelusca(a)svn.reactos.org wrote:
> [NTVDM]: Initialize the PSP' memory control block owner name with the file name (without extension, and up to 8 chars) of the started program.
Shouldn't that use GetShortPathName to make sure the program can find
itself on disk? :p
Hi all,
First of all, let me thank everybody who could make it to Aachen for
Hackfest! Thanks also go to all the others on IRC, Twitter, etc. who
supported us during that time!
It was a pleasure to have you all here and simply a great week! :)
Now let's spread the word even more, so that everyone can get an idea of
our Hackfest:
Hackfest report
===============
Aleksey suggested (and volunteered!) to write a report about our
Hackfest for the website. He wants someone to help him though.
Victor, as you did a pretty great job at live streaming every day, would
you help Aleksey here?
If there are other volunteers, just raise your voice :)
Photos
======
I've created a folder "ReactOS Hackfest 2015" in the "Developers" file
section on IServ. You already find all my photos there (among them,
first group photos from Saturday).
Please share your photos as well, either by uploading through the
website or through SFTP (WinSCP is a great tool for this).
If you're not in the "Developers" section, but participated in the
Hackfest, please tell either Christoph, Pierre or me and we will add you.
Cheers,
Colin
Just wonder why no one has yet fixed the compiling errors you get if you
use visual studio.
All the errors are not code related but linking problem, so I wonder why no
body solve all the compiler errors.
Thanks,
Alberto Vaudagna
Hi everyone,
Some of you probably remember me. I was involved with trying to get
audio/sound implemented in ReactOS a few years ago.
To be honest, my progress was rather poor, I managed to write a few bits of
code but never really had a proper understanding of kernel/OS development or
CPU/system architectures. Additionally, whilst I could grasp how the
multimedia APIs (MME) in NT4 worked, and how they interacted with the
drivers (audio device X opens device Y and writes buffered data to it) for
Windows 2000 and later, Kernel Streaming was used which partly built on top
of the older implementation but added a load of new stuff.
This complicated matters as firstly, KS uses COM (which I still struggle to
wrap my head around) in kernel-mode, secondly there were multiple components
involved between the application and the hardware (wdmaud.drv -> wdmaud.sys
-> ks.sys -> portcls.sys -> driver as far as I remember), and finally I
really struggled to find example code and thorough documentation describing
how it all worked.
Ultimately I gave up with that and intended to move to another platform to
develop multimedia applications. Not much happened with that.
I remember there were complaints from application developers over Kernel
Streaming offering poor latency - instead developers would turn to other
technologies such as ASIO or DirectSound. So for recent versions of Windows
(Vista onwards?) Microsoft implemented a new, user-mode sound system
(WASAPI) which again uses COM but is pretty nicely documented, with code
samples.
Having done a little reading about this, it renewed my interest. It still
uses COM, and KS.SYS is still present (I assume for compatibility?) but as a
lot of this is implemented in user-space I suspect it'd be easier to
develop/test.
Aside from this, over the past few years I've also gained a better
understanding of topics I didn't know much about previously and I feel more
confident at being able to write lower-level stuff that works properly. I've
also developed more of a keen interest in how Windows works.
So basically I'm considering implementing the current Windows audio system
in ReactOS. I'd imagine we don't need to be too concerned about audio
drivers themselves (at least, initially) as vendors tend to offer these and
it's not like we need sound immediately post-install!
The only thing I really lack now is knowledge of how to implement COM
classes - at least, outside of using Visual Studio. Anyone got recommended
reading or example code for this?
Andrew