_OSI(Linux) == false

   This changeset was just brought to my attention:

h
ttp://www.kernel.org/hg/linux-2.6/rev/7f6bc8a8fb19

In short, newer upstream kernels will return True for
_OSI(Windows) and
False for _OSI(Linux).  This will cause Linux VT-i domains
to get
incorrectly identified as Windows guests and do bad things
with region 4
& 5 mapping.

   There is a DMI interface available that we could use to
automatically
enable _OSI(Linux), but I think that means we'd need to
generate a DMI
table for HVM domains.  Sounds like a pain, but maybe it's
not actually
that hard.  Any other thoughts on how we could continue to
detect the OS
on HVM domains for optimizations?  Thanks,

	Alex

-- 
Alex Williamson                             HP Open Source
& Linux Org.


_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devellists.xensource.com
http://list
s.xensource.com/xen-ia64-devel

>
>   This changeset was just brought to my attention:
>
>h
ttp://www.kernel.org/hg/linux-2.6/rev/7f6bc8a8fb19
>
>In short, newer upstream kernels will return True for
_OSI(Windows) and
>False for _OSI(Linux).  This will cause Linux VT-i
domains to get
>incorrectly identified as Windows guests and do bad
things with region
4
>& 5 mapping.

Does linux call _OSI(Windows)?
If not, it will not impact XEN.

Anthony


>
>   There is a DMI interface available that we could use
to
automatically
>enable _OSI(Linux), but I think that means we'd need to
generate a DMI
>table for HVM domains.  Sounds like a pain, but maybe
it's not actually
>that hard.  Any other thoughts on how we could continue
to detect the
OS
>on HVM domains for optimizations?  Thanks,
>
>	Alex
>
>--
>Alex Williamson                             HP Open
Source & Linux Org.

_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devellists.xensource.com
http://list
s.xensource.com/xen-ia64-devel

Alex,

Just talked with ACPI export, he said because the path for
linux is not fully tested, and they have been using windows
path, the _OSI(linux) will return false.

In this situation, we can't tell guest OS depending on
_OSI.
And he said, currently there is no other method to get Os
type.

In this situation,
Can you fall back to our old method?

Windows is using 8K preferred page size in region 7.
Linux is using 16M preferred page size in region 7.

I think these will change rarely, so we can depend on this.

Another difference is,
Windows enable VHPT in region 7,
While linux disable VHPT in region 7,
I think these will also change rarely.

I think both these methods work if we don't need to support
other OS.

What's your opinion?

Thanks,
Anthony


>-----Original Message-----
>From: Alex Williamson [mailto:alex.williamsonhp.com]
>Sent: 2007年8月17日 20:31
>To: Xu, Anthony
>Cc: xen-ia64-devel
>Subject: Re: [Xen-ia64-devel] RE: _OSI(Linux) == false
>
>On Fri, 2007-08-17 at 14:13 +0800, Xu, Anthony wrote:
>> >
>> >   This changeset was just brought to my
attention:
>> >
>> >h
ttp://www.kernel.org/hg/linux-2.6/rev/7f6bc8a8fb19
>> >
>> >In short, newer upstream kernels will return
True for _OSI(Windows) and
>> >False for _OSI(Linux).  This will cause Linux
VT-i domains to get
>> >incorrectly identified as Windows guests and do
bad things with region
>> 4
>> >& 5 mapping.
>>
>> Does linux call _OSI(Windows)?
>> If not, it will not impact XEN.
>
>   We added platform optimizations based on the
following assumption:
>
>        On Tue, 2007-05-08 at 10:55 +0800, Xu, Anthony
wrote:
>>         Run linux,
>>         Both __OSI(linux) and __OSI(windows) return
true.
>>
>>         Run windows,
>>         __OSI(linux) return false,
>>         __OSI(windows) return true.
>>
>>         So if guest FW checks linux first then
checks windows.
>>         Guest FW can tell which OS is running on
top of it.
>>         Then Guest FW can tell XEN which OS is
running.
>
>We can no longer identify Linux vs Windows in this
manner unless we can
>make Linux return True for _OSI(linux) when it's running
on Xen.  Is
>this not the way the code works?  I see the calls to
_OSI in the _INI
>method of the PCI0 device in the DSDT:
>
>
>147		If (CondRefOf(_OSI, Local0))
>148		{
>149			//Compare linux first. Because _OSI("Windows
2001") still
>150			//return true while linux running on guest
>151			If (_OSI("Linux"))
>152			{
>153				Store(0xB2, OST)
>154			}
>155			ElseIf (_OSI("Windows 2001.1"))
>156			{
>157				Store(0xB1, OST)
>158			}
>159			Else
>160			{
>161				Store(0xB0, OST)
>162			}
>163
>164			Store(0xB0, OST)
>165		}
>
>Thanks,
>
>	Alex
>
>--
>Alex Williamson                             HP Open
Source & Linux Org.

_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devellists.xensource.com
http://list
s.xensource.com/xen-ia64-devel

On Sat, 2007-08-18 at 15:15 +0800, Xu, Anthony wrote:
> Alex,
> 
> Just talked with ACPI export, he said because the path
for linux is not fully tested, and they have been using
windows path, the _OSI(linux) will return false.
> 
> In this situation, we can't tell guest OS depending on
_OSI.
> And he said, currently there is no other method to get
Os type.
> 
> In this situation,
> Can you fall back to our old method?
> 
> Windows is using 8K preferred page size in region 7.
> Linux is using 16M preferred page size in region 7.
> 
> I think these will change rarely, so we can depend on
this.
> 
> Another difference is,
> Windows enable VHPT in region 7,
> While linux disable VHPT in region 7,
> I think these will also change rarely.
> 
> I think both these methods work if we don't need to
support other OS.
> 
> What's your opinion?

Hi Anthony,

   I was actually thinking of a different approach.  There
is a DMI
interface that would allow us to have Linux automatically
respond true
to _OSI(linux).  If we created a minimal SMBIOS table for
VTI domains,
it seems like this would be fairly easy enable.  What do you
think?
Thanks,

	Alex

-- 
Alex Williamson                             HP Open Source
& Linux Org.


_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devellists.xensource.com
http://list
s.xensource.com/xen-ia64-devel

>
>Hi Anthony,
>
>   I was actually thinking of a different approach. 
There is a DMI
>interface that would allow us to have Linux
automatically respond true
>to _OSI(linux).  If we created a minimal SMBIOS table
for VTI domains,
>it seems like this would be fairly easy enable.  What do
you think?
>Thanks,
>

	To be honest, I am not aware of DMI; I'll look at this
possibility.
No doubt, it is a elegant way to get Os type. I'll try this
way.

Thanks,
Anthony

_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devellists.xensource.com
http://list
s.xensource.com/xen-ia64-devel

Quoting "Xu, Anthony" <anthony.xuintel.com>:

> Alex,
>
> Just talked with ACPI export, he said because the path
for linux is not fully
> tested, and they have been using windows path, the
_OSI(linux) will return
> false.
>
> In this situation, we can't tell guest OS depending on
_OSI.
> And he said, currently there is no other method to get
Os type.
>
> In this situation,
> Can you fall back to our old method?
>
> Windows is using 8K preferred page size in region 7.
> Linux is using 16M preferred page size in region 7.
>
> I think these will change rarely, so we can depend on
this.
>
> Another difference is,
> Windows enable VHPT in region 7,
> While linux disable VHPT in region 7,
> I think these will also change rarely.
>
> I think both these methods work if we don't need to
support other OS.

That's the major issue.  There are at least half a dozen of
OS for ia64 and
we are not sure this method won't break another OS.

ACPI method is fine.  If it could't work, I'd prefer
explicit flag in xm
configuration file.

Tristan.

_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devellists.xensource.com
http://list
s.xensource.com/xen-ia64-devel

 

>> I think both these methods work if we don't need to
support other OS.
>
>That's the major issue.  There are at least half a dozen
of OS 
>for ia64 and
>we are not sure this method won't break another OS.
>
>ACPI method is fine.  If it could't work, I'd prefer
explicit 
>flag in xm
>configuration file.
>
>Tristan.
>
I think SMBios table is better than explicit field in
configure file.
It's convenient to user if we make configure file thiner.
IMO, SMBios is not hard to implement. Actually I have
finished the code
in open GFW and Xen. I will debug it soon to make it run.
>_______________________________________________
>Xen-ia64-devel mailing list
>Xen-ia64-devellists.xensource.com
>http://list
s.xensource.com/xen-ia64-devel
>

_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devellists.xensource.com
http://list
s.xensource.com/xen-ia64-devel

>That's the major issue.  There are at least half a dozen
of OS for ia64 and
>we are not sure this method won't break another OS.
>

I only know linux, windows, BSD for ia64.
Can you help list OSes for IA64?

Thanks,



>From: tgingoldfree.fr [mailto:tgingoldfree.fr]
>Sent: 2007年8月21日 20:07
>To: Xu, Anthony
>Cc: Alex Williamson; xen-ia64-devel
>Subject: RE: [Xen-ia64-devel] RE: _OSI(Linux) == false
>
>Quoting "Xu, Anthony" <anthony.xuintel.com>:
>
>> Alex,
>>
>> Just talked with ACPI export, he said because the
path for linux is not fully
>> tested, and they have been using windows path, the
_OSI(linux) will return
>> false.
>>
>> In this situation, we can't tell guest OS depending
on _OSI.
>> And he said, currently there is no other method to
get Os type.
>>
>> In this situation,
>> Can you fall back to our old method?
>>
>> Windows is using 8K preferred page size in region
7.
>> Linux is using 16M preferred page size in region
7.
>>
>> I think these will change rarely, so we can depend
on this.
>>
>> Another difference is,
>> Windows enable VHPT in region 7,
>> While linux disable VHPT in region 7,
>> I think these will also change rarely.
>>
>> I think both these methods work if we don't need to
support other OS.
>
>That's the major issue.  There are at least half a dozen
of OS for ia64 and
>we are not sure this method won't break another OS.
>
>ACPI method is fine.  If it could't work, I'd prefer
explicit flag in xm
>configuration file.
>
>Tristan.

_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devellists.xensource.com
http://list
s.xensource.com/xen-ia64-devel

On Wed, 2007-08-22 at 09:22 +0800, Xu, Anthony wrote:
> >That's the major issue.  There are at least half a
dozen of OS for ia64 and
> >we are not sure this method won't break another
OS.
> >
> 
> I only know linux, windows, BSD for ia64.
> Can you help list OSes for IA64?

   HP has HPUX, OpenVMS, and NonStop.  There's also BS2000,
the
mainframe OS Fujitsu-Siemens now has PV support for.  From
wikipedia, it
looks like Bull also supports another mainframe OS, GCOS, on
ia64.
Probably a sampling of research OSes available as well.

	Alex

-- 
Alex Williamson                             HP Open Source
& Linux Org.


_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devellists.xensource.com
http://list
s.xensource.com/xen-ia64-devel

On Wed, 2007-08-22 at 09:22 +0800, Zhang, Xing Z wrote:
> >
> I think SMBios table is better than explicit field in
configure file.
> It's convenient to user if we make configure file
thiner.
> IMO, SMBios is not hard to implement. Actually I have
finished the code
> in open GFW and Xen. I will debug it soon to make it
run.

   Great, thanks for working on this.  I look forward to
seeing it.
Thanks,

	Alex

-- 
Alex Williamson                             HP Open Source
& Linux Org.


_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devellists.xensource.com
http://list
s.xensource.com/xen-ia64-devel