Ken'ichi Ohmichi wrote:
Hello Dave,
Dave Anderson wrote:
>>I think that a new virtualization_init() function is a good idea.
>>
>>How about checking whether "Xen" exists in PT_NOTE section of an vmcore
>>at virtualization_init()? I feel that it is safer than reading a xen_start_info
>>pointer.
>>
>>$ readelf -n vmcore
>>Notes at offset 0x00000120 with length 0x00001388:
>> Owner Data size Description
>> CORE 0x00000150 NT_PRSTATUS (prstatus structure)
>> Xen 0x00000020 Unknown note type: (0x01000002) <----- HERE
>> CORE 0x00000150 NT_PRSTATUS (prstatus structure)
>> Xen 0x00000020 Unknown note type: (0x01000002) <----- HERE
>> Xen 0x00000050 Unknown note type: (0x01000001) <----- HERE
>> VMCOREINFO_XEN 0x00000fe4 Unknown note type: (0x00000000)
>>$
>
>Well there may be a couple issues with that approach. First, we need
>a way to handle/recognize it on live systems. And second, I believe we'll need
>a way to differentiate a pv_ops/xen kernel from a "dedicated" xen kernel.
>And my guess is that the vmcore notes will not differentiate between the
>two "flavors" of xen kernel (unless there's an entry in the
VMCOREINFO_XEN
>that will somehow differentiate the two).
Thank you for the good comment. I understand your plan, and I think it is
better than mine.
Yeah, the more I look into it, the more it appears that support for
pv_ops/xen (as well as the other pv_ops clients) are going to require
significant changes.
For now, only "traditional xen" will be supported, and when pv_ops/xen
comes online, we'll take a look at how to merge support for it.
Here's my initial update to your patch -- it simply recognizes pv_ops
kernels, and disallows the setting of the ARCH_XEN in that case.
Dave