enumerating a pdo for pnpmem.sys to attach to

This may well be another dead end, but is the interface that pnpmem.sys
uses published anywhere? From what I can see, pnpmem.sys attaches to a
device with a deviceid of ACPI\PNP0C80 which is (I guess) enumerated by
ACPI when there is a hot plug memory module present.

Obviously if it’s an unpublished interface then I probably won’t be
spending any more time on it.

I’m looking for a way to get windows to add new memory when Xen says it
can have some more, and was wondering if this path might lead
somewhere…

Thanks

James

#if (NTDDI_VERSION >= NTDDI_WIN2K)
NTKERNELAPI
NTSTATUS
MmAddPhysicalMemory (
__in PPHYSICAL_ADDRESS StartAddress,
__inout PLARGE_INTEGER NumberOfBytes
);
#endif

ntddk.h

Or implement the bios interface for hotplug memory support - which
method has better xen than some PV driver hack.

Mark Roddy

On Sat, Jun 20, 2009 at 6:16 AM, James
Harper wrote:
> This may well be another dead end, but is the interface that pnpmem.sys
> uses published anywhere? From what I can see, pnpmem.sys attaches to a
> device with a deviceid of ACPI\PNP0C80 which is (I guess) enumerated by
> ACPI when there is a hot plug memory module present.
>
> Obviously if it’s an unpublished interface then I probably won’t be
> spending any more time on it.
>
> I’m looking for a way to get windows to add new memory when Xen says it
> can have some more, and was wondering if this path might lead
> somewhere…
>
> Thanks
>
> James
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>

>

#if (NTDDI_VERSION >= NTDDI_WIN2K)
NTKERNELAPI
NTSTATUS
MmAddPhysicalMemory (
__in PPHYSICAL_ADDRESS StartAddress,
__inout PLARGE_INTEGER NumberOfBytes
);
#endif

ntddk.h

I’m aware of MmAddPhysicalMemory (pnpmem.sys actually calls it, but you
probably knew that). MmAddPhysicalMemory is also not documented (well…
strictly speaking it is documented, and the documentation says “this is
a system function, don’t use it”). I was wondering if pnpmem.sys had a
documented interface and would be the better way forward.

Or implement the bios interface for hotplug memory support - which
method has better xen than some PV driver hack.

If by ‘bios interface’ you mean ACPI then yes, that is certainly one way
of doing it, and probably the correct way.

I did some testing, and enumerated a PDO with a DeviceID of
“ACPI\PNP0C80”, and injected a memory resource into its resource list,
and got a message in eventlog of:

“Failed to add memory range starting at 0x40000000 for 0x10000000 bytes.
This operation exceeded the maximum memory capacity of the operating
system or the server is not configured to support dynamic memory
operations.”

Presumably something (ACPI?) needs to specify that it is possible to add
more memory so that Windows reserves the correct amount of headroom etc
to support it.

Oh well. I don’t think I’ll be following this up any further.

Thanks

James

James, you probably need to add that physical address range to your SRAT
table so that the OS considers it a range which should be prepped at boot
for hot-plug. See the ACPI spec for more details.


Jake Oshins
Hyper-V I/O Architect
Windows Kernel Group

This post implies no warranties and confers no rights.


“James Harper” wrote in message
news:xxxxx@ntdev…
>>
>> #if (NTDDI_VERSION >= NTDDI_WIN2K)
>> NTKERNELAPI
>> NTSTATUS
>> MmAddPhysicalMemory (
>> in PPHYSICAL_ADDRESS StartAddress,
>>
inout PLARGE_INTEGER NumberOfBytes
>> );
>> #endif
>>
>> ntddk.h
>>
>
> I’m aware of MmAddPhysicalMemory (pnpmem.sys actually calls it, but you
> probably knew that). MmAddPhysicalMemory is also not documented (well…
> strictly speaking it is documented, and the documentation says “this is
> a system function, don’t use it”). I was wondering if pnpmem.sys had a
> documented interface and would be the better way forward.
>
>> Or implement the bios interface for hotplug memory support - which
>> method has better xen than some PV driver hack.
>>
> If by ‘bios interface’ you mean ACPI then yes, that is certainly one way
> of doing it, and probably the correct way.
>
> I did some testing, and enumerated a PDO with a DeviceID of
> “ACPI\PNP0C80”, and injected a memory resource into its resource list,
> and got a message in eventlog of:
>
> “Failed to add memory range starting at 0x40000000 for 0x10000000 bytes.
> This operation exceeded the maximum memory capacity of the operating
> system or the server is not configured to support dynamic memory
> operations.”
>
> Presumably something (ACPI?) needs to specify that it is possible to add
> more memory so that Windows reserves the correct amount of headroom etc
> to support it.
>
> Oh well. I don’t think I’ll be following this up any further.
>
> Thanks
>
> James
>
>

>

James, you probably need to add that physical address range to your
SRAT
table so that the OS considers it a range which should be prepped at
boot
for hot-plug. See the ACPI spec for more details.

I put an extra ‘reserved’ entry into the E820 table and then enumerated
my pdo with memory in the ‘reserved’ region, and this time got no error
message in the event logs, but windows reported no increase in memory.

As I’m just testing, there is actually no memory actually mapped there
at the moment by Xen, so I was expecting Windows to crash horribly. So
either it’s still not working, or windows is checking to see if there is
memory there (eg write some data and read it back in again), and is not
reporting errors if it discovers that there is no memory there…

Next I’ll add some hooks to Xen to see if writes are actually occurring
to that space…

James

That’s because you didn’t do what I suggested that you do. Please go read
the ACPI spec. Pay special attention to anything labeled “SRAT.”


Jake Oshins
Hyper-V I/O Architect
Windows Kernel Group

This post implies no warranties and confers no rights.


“James Harper” wrote in message
news:xxxxx@ntdev…
>>
>> James, you probably need to add that physical address range to your
> SRAT
>> table so that the OS considers it a range which should be prepped at
> boot
>> for hot-plug. See the ACPI spec for more details.
>>
>
> I put an extra ‘reserved’ entry into the E820 table and then enumerated
> my pdo with memory in the ‘reserved’ region, and this time got no error
> message in the event logs, but windows reported no increase in memory.
>
> As I’m just testing, there is actually no memory actually mapped there
> at the moment by Xen, so I was expecting Windows to crash horribly. So
> either it’s still not working, or windows is checking to see if there is
> memory there (eg write some data and read it back in again), and is not
> reporting errors if it discovers that there is no memory there…
>
> Next I’ll add some hooks to Xen to see if writes are actually occurring
> to that space…
>
> James
>

>

That’s because you didn’t do what I suggested that you do. Please go
read
the ACPI spec. Pay special attention to anything labeled “SRAT.”

Hmmm… I was sure I wrote “and next I’m going to look up the ACPI
spec”, but obviously I omitted that bit :frowning:

Thanks

James