On 01/27/2016 02:00 PM, Luis R. Rodriguez wrote:
On Wed, Jan 27, 2016 at 10:48 AM, Luis R. Rodriguez wrote:
Worth mentioning here also is hpa's clarification on when subarch type
PC (0) should be used: [it should be used if the hardware is]
"enumerable using standard PC mechanisms (PCI, ACPI)
On Wed, Jan 27, 2016 at 10:48 AM, Luis R. Rodriguez wrote:
>
> Worth mentioning here also is hpa's clarification on when subarch type
> PC (0) should be used: [it should be used if the hardware is]
> "enumerable using standard PC mechanisms (PCI, ACPI) and doesn't need
> a special boot flow" --
Bleh moving forward please use mcg...@kernel.org, that will be sent to
my employer and my personal address. More below.
On Wed, Jan 27, 2016 at 8:15 AM, Boris Ostrovsky
wrote:
> On 01/27/2016 10:29 AM, Konrad Rzeszutek Wilk wrote:
>> On Wed, Jan 27, 2016 at 10:17:56AM -0500, Boris Ostrovsky
On Wed, Jan 27, 2016 at 02:50:36PM +, David Vrabel wrote:
> Surely the interesting comparison here is how is (early) microcode
> loading disabled in KVM guests?
It isn't - kvm simply ignores the write to the microcode application
MSRs MSR_AMD64_PATCH_LOADER and MSR_IA32_UCODE_REV,
On 01/27/2016 10:29 AM, Konrad Rzeszutek Wilk wrote:
On Wed, Jan 27, 2016 at 10:17:56AM -0500, Boris Ostrovsky wrote:
On 01/27/2016 10:09 AM, David Vrabel wrote:
On 27/01/16 15:06, Boris Ostrovsky wrote:
On 01/27/2016 09:50 AM, David Vrabel wrote:
On 27/01/16 14:42, Konrad Rzeszutek Wilk
On 01/27/2016 10:09 AM, David Vrabel wrote:
On 27/01/16 15:06, Boris Ostrovsky wrote:
On 01/27/2016 09:50 AM, David Vrabel wrote:
On 27/01/16 14:42, Konrad Rzeszutek Wilk wrote:
On Tue, Jan 26, 2016 at 08:54:56PM -0800, Luis R. Rodriguez wrote:
On Jan 26, 2016 6:16 PM, "Luis R. Rodriguez"
On 27/01/16 15:06, Boris Ostrovsky wrote:
> On 01/27/2016 09:50 AM, David Vrabel wrote:
>> On 27/01/16 14:42, Konrad Rzeszutek Wilk wrote:
>>> On Tue, Jan 26, 2016 at 08:54:56PM -0800, Luis R. Rodriguez wrote:
On Jan 26, 2016 6:16 PM, "Luis R. Rodriguez" wrote:
> On Tue, Jan 26, 2016 at
On 01/27/2016 09:50 AM, David Vrabel wrote:
On 27/01/16 14:42, Konrad Rzeszutek Wilk wrote:
On Tue, Jan 26, 2016 at 08:54:56PM -0800, Luis R. Rodriguez wrote:
On Jan 26, 2016 6:16 PM, "Luis R. Rodriguez" wrote:
On Tue, Jan 26, 2016 at 4:04 PM, Luis R. Rodriguez
wrote:
You go:
On 27/01/16 14:42, Konrad Rzeszutek Wilk wrote:
> On Tue, Jan 26, 2016 at 08:54:56PM -0800, Luis R. Rodriguez wrote:
>> On Jan 26, 2016 6:16 PM, "Luis R. Rodriguez" wrote:
>>>
>>> On Tue, Jan 26, 2016 at 4:04 PM, Luis R. Rodriguez
>> wrote:
You go:
hvmlite_start_xen() -->
On 01/27/2016 02:00 PM, Luis R. Rodriguez wrote:
On Wed, Jan 27, 2016 at 10:48 AM, Luis R. Rodriguez wrote:
Worth mentioning here also is hpa's clarification on when subarch type
PC (0) should be used: [it should be used if the hardware is]
"enumerable using standard PC
On 01/27/2016 10:29 AM, Konrad Rzeszutek Wilk wrote:
On Wed, Jan 27, 2016 at 10:17:56AM -0500, Boris Ostrovsky wrote:
On 01/27/2016 10:09 AM, David Vrabel wrote:
On 27/01/16 15:06, Boris Ostrovsky wrote:
On 01/27/2016 09:50 AM, David Vrabel wrote:
On 27/01/16 14:42, Konrad Rzeszutek Wilk
On Wed, Jan 27, 2016 at 02:50:36PM +, David Vrabel wrote:
> Surely the interesting comparison here is how is (early) microcode
> loading disabled in KVM guests?
It isn't - kvm simply ignores the write to the microcode application
MSRs MSR_AMD64_PATCH_LOADER and MSR_IA32_UCODE_REV,
Bleh moving forward please use mcg...@kernel.org, that will be sent to
my employer and my personal address. More below.
On Wed, Jan 27, 2016 at 8:15 AM, Boris Ostrovsky
wrote:
> On 01/27/2016 10:29 AM, Konrad Rzeszutek Wilk wrote:
>> On Wed, Jan 27, 2016 at 10:17:56AM
On Wed, Jan 27, 2016 at 10:48 AM, Luis R. Rodriguez wrote:
>
> Worth mentioning here also is hpa's clarification on when subarch type
> PC (0) should be used: [it should be used if the hardware is]
> "enumerable using standard PC mechanisms (PCI, ACPI) and doesn't need
> a
On 27/01/16 14:42, Konrad Rzeszutek Wilk wrote:
> On Tue, Jan 26, 2016 at 08:54:56PM -0800, Luis R. Rodriguez wrote:
>> On Jan 26, 2016 6:16 PM, "Luis R. Rodriguez" wrote:
>>>
>>> On Tue, Jan 26, 2016 at 4:04 PM, Luis R. Rodriguez
>> wrote:
You go:
On 01/27/2016 09:50 AM, David Vrabel wrote:
On 27/01/16 14:42, Konrad Rzeszutek Wilk wrote:
On Tue, Jan 26, 2016 at 08:54:56PM -0800, Luis R. Rodriguez wrote:
On Jan 26, 2016 6:16 PM, "Luis R. Rodriguez" wrote:
On Tue, Jan 26, 2016 at 4:04 PM, Luis R. Rodriguez
On 27/01/16 15:06, Boris Ostrovsky wrote:
> On 01/27/2016 09:50 AM, David Vrabel wrote:
>> On 27/01/16 14:42, Konrad Rzeszutek Wilk wrote:
>>> On Tue, Jan 26, 2016 at 08:54:56PM -0800, Luis R. Rodriguez wrote:
On Jan 26, 2016 6:16 PM, "Luis R. Rodriguez" wrote:
> On Tue,
On 01/27/2016 10:09 AM, David Vrabel wrote:
On 27/01/16 15:06, Boris Ostrovsky wrote:
On 01/27/2016 09:50 AM, David Vrabel wrote:
On 27/01/16 14:42, Konrad Rzeszutek Wilk wrote:
On Tue, Jan 26, 2016 at 08:54:56PM -0800, Luis R. Rodriguez wrote:
On Jan 26, 2016 6:16 PM, "Luis R. Rodriguez"
On Tue, Jan 26, 2016 at 4:04 PM, Luis R. Rodriguez wrote:
> You go:
>
> hvmlite_start_xen() -->
> HVM stub
> startup_64() | (startup_32()
Hrm, does HVMlite work well with load_ucode_bsp(), note the patches to
rebrand pv_enabled() to pv_legacy() or whatever, this PV type will not
On Tue, Jan 26, 2016 at 04:51:38PM -0500, Boris Ostrovsky wrote:
> On 01/26/2016 03:30 PM, Luis R. Rodriguez wrote:
> hvmlite_start() is a 32-bit entry point [...]
>
> >4) hardware_subarch, hardware_subarch_data and future prospects
> >
> >Your patch relies on a *new* Linux entry point. Sure, we
On 01/26/2016 03:30 PM, Luis R. Rodriguez wrote:
What I'm proposing?
1) Lets see if we can put a proactive stop-gap to issues such as the cr4 shadow
bug and Kasan bugs from creeping in. This should not only help PV but perhaps
HVMLite. If you'd like to help with that refer to this thread:
On Mon, Jan 25, 2016 at 05:55:02PM -0500, Boris Ostrovsky wrote:
> On 01/25/2016 05:19 PM, Luis R. Rodriguez wrote:
> >On Sat, Jan 23, 2016 at 02:49:36PM +, Andrew Cooper wrote:
> >
> >
> >>it causes inappropriate linkage between the
> >>toolstack and the version of Linux wishing to be booted.
On Tue, Jan 26, 2016 at 11:00 AM, Boris Ostrovsky
wrote:
> On 01/26/2016 01:46 PM, Andy Lutomirski wrote:
>>
>> On Tue, Jan 26, 2016 at 10:34 AM, Luis R. Rodriguez
>> wrote:
>>>
>>> On Mon, Jan 25, 2016 at 05:28:08PM -0500, Boris Ostrovsky wrote:
On 01/25/2016 04:21 PM, H. Peter Anvin
>However, this stub belongs in Linux, not in the Xen toolstack. That
>way, when the Linux boot protocol is modified, both sides can be
>updated
>accordingly.
I would add that this idea is borrowed from the EFI stub code that Linux has
which also constructs the boot parameter structure when
>However, this stub belongs in Linux, not in the Xen toolstack. That
>way, when the Linux boot protocol is modified, both sides can be
>updated
>accordingly.
I would add that this idea is borrowed from the EFI stub code that Linux has
which also constructs the boot parameter structure when
On Tue, Jan 26, 2016 at 11:00 AM, Boris Ostrovsky
wrote:
> On 01/26/2016 01:46 PM, Andy Lutomirski wrote:
>>
>> On Tue, Jan 26, 2016 at 10:34 AM, Luis R. Rodriguez
>> wrote:
>>>
>>> On Mon, Jan 25, 2016 at 05:28:08PM -0500, Boris Ostrovsky wrote:
On Mon, Jan 25, 2016 at 05:55:02PM -0500, Boris Ostrovsky wrote:
> On 01/25/2016 05:19 PM, Luis R. Rodriguez wrote:
> >On Sat, Jan 23, 2016 at 02:49:36PM +, Andrew Cooper wrote:
> >
> >
> >>it causes inappropriate linkage between the
> >>toolstack and the version of Linux wishing to be booted.
On 01/26/2016 03:30 PM, Luis R. Rodriguez wrote:
What I'm proposing?
1) Lets see if we can put a proactive stop-gap to issues such as the cr4 shadow
bug and Kasan bugs from creeping in. This should not only help PV but perhaps
HVMLite. If you'd like to help with that refer to this thread:
On Tue, Jan 26, 2016 at 04:51:38PM -0500, Boris Ostrovsky wrote:
> On 01/26/2016 03:30 PM, Luis R. Rodriguez wrote:
> hvmlite_start() is a 32-bit entry point [...]
>
> >4) hardware_subarch, hardware_subarch_data and future prospects
> >
> >Your patch relies on a *new* Linux entry point. Sure, we
On Tue, Jan 26, 2016 at 4:04 PM, Luis R. Rodriguez wrote:
> You go:
>
> hvmlite_start_xen() -->
> HVM stub
> startup_64() | (startup_32()
Hrm, does HVMlite work well with load_ucode_bsp(), note the patches to
rebrand pv_enabled() to pv_legacy() or whatever, this
On 01/25/2016 05:19 PM, Luis R. Rodriguez wrote:
On Sat, Jan 23, 2016 at 02:49:36PM +, Andrew Cooper wrote:
it causes inappropriate linkage between the
toolstack and the version of Linux wishing to be booted.
There are ways to do it in such a way that it does not create dependency issues
On Sat, Jan 23, 2016 at 02:49:36PM +, Andrew Cooper wrote:
> On 23/01/2016 00:55, Luis R. Rodriguez wrote:
> > On Fri, Jan 22, 2016 at 4:30 PM, Andrew Cooper
> > wrote:
> >> the DMLite boot
> >> protocol is OS agnostic, and will be staying that way.
> > What's the DMLite boot protocol?
>
>
On 01/22/2016 07:30 PM, Andrew Cooper wrote:
On 22/01/2016 23:32, Luis R. Rodriguez wrote:
On Fri, Jan 22, 2016 at 04:35:50PM -0500, Boris Ostrovsky wrote:
+ /*
+* See Documentation/x86/boot.txt.
+*
+* Version 2.12 supports Xen entry point but we will use default
El 23/01/16 a les 17.12, Konrad Rzeszutek Wilk ha escrit:
> On January 23, 2016 11:01:06 AM EST, "H. Peter Anvin" wrote:
>> On January 23, 2016 7:34:33 AM PST, Konrad Rzeszutek Wilk
>> wrote:
>>>
However, this stub belongs in Linux, not in the Xen toolstack. That
way, when the Linux
On 01/22/2016 07:30 PM, Andrew Cooper wrote:
On 22/01/2016 23:32, Luis R. Rodriguez wrote:
On Fri, Jan 22, 2016 at 04:35:50PM -0500, Boris Ostrovsky wrote:
+ /*
+* See Documentation/x86/boot.txt.
+*
+* Version 2.12 supports Xen entry point but we will use default
On Sat, Jan 23, 2016 at 02:49:36PM +, Andrew Cooper wrote:
> On 23/01/2016 00:55, Luis R. Rodriguez wrote:
> > On Fri, Jan 22, 2016 at 4:30 PM, Andrew Cooper
> > wrote:
> >> the DMLite boot
> >> protocol is OS agnostic, and will be staying that way.
> > What's the
On 01/25/2016 05:19 PM, Luis R. Rodriguez wrote:
On Sat, Jan 23, 2016 at 02:49:36PM +, Andrew Cooper wrote:
it causes inappropriate linkage between the
toolstack and the version of Linux wishing to be booted.
There are ways to do it in such a way that it does not create dependency issues
El 23/01/16 a les 17.12, Konrad Rzeszutek Wilk ha escrit:
> On January 23, 2016 11:01:06 AM EST, "H. Peter Anvin" wrote:
>> On January 23, 2016 7:34:33 AM PST, Konrad Rzeszutek Wilk
>> wrote:
>>>
However, this stub belongs in Linux, not in the Xen
On January 23, 2016 8:12:23 AM PST, Konrad Rzeszutek Wilk
wrote:
>On January 23, 2016 11:01:06 AM EST, "H. Peter Anvin"
>wrote:
>>On January 23, 2016 7:34:33 AM PST, Konrad Rzeszutek Wilk
>> wrote:
>>>
However, this stub belongs in Linux, not in the Xen toolstack. That
way, when the
On January 23, 2016 11:01:06 AM EST, "H. Peter Anvin" wrote:
>On January 23, 2016 7:34:33 AM PST, Konrad Rzeszutek Wilk
> wrote:
>>
>>>However, this stub belongs in Linux, not in the Xen toolstack. That
>>>way, when the Linux boot protocol is modified, both sides can be
>>>updated
On January 23, 2016 7:34:33 AM PST, Konrad Rzeszutek Wilk
wrote:
>
>>However, this stub belongs in Linux, not in the Xen toolstack. That
>>way, when the Linux boot protocol is modified, both sides can be
>>updated
>>accordingly.
>
>I would add that this idea is borrowed from the EFI stub code
On 23/01/2016 00:55, Luis R. Rodriguez wrote:
> On Fri, Jan 22, 2016 at 4:30 PM, Andrew Cooper
> wrote:
>> the DMLite boot
>> protocol is OS agnostic, and will be staying that way.
> What's the DMLite boot protocol?
It is a statement of the initial state of a DMLite container.
> Is that the
On January 23, 2016 8:12:23 AM PST, Konrad Rzeszutek Wilk
wrote:
>On January 23, 2016 11:01:06 AM EST, "H. Peter Anvin"
>wrote:
>>On January 23, 2016 7:34:33 AM PST, Konrad Rzeszutek Wilk
>> wrote:
>>>
However, this stub
On 23/01/2016 00:55, Luis R. Rodriguez wrote:
> On Fri, Jan 22, 2016 at 4:30 PM, Andrew Cooper
> wrote:
>> the DMLite boot
>> protocol is OS agnostic, and will be staying that way.
> What's the DMLite boot protocol?
It is a statement of the initial state of a DMLite
On January 23, 2016 7:34:33 AM PST, Konrad Rzeszutek Wilk
wrote:
>
>>However, this stub belongs in Linux, not in the Xen toolstack. That
>>way, when the Linux boot protocol is modified, both sides can be
>>updated
>>accordingly.
>
>I would add that this idea is borrowed
On January 23, 2016 11:01:06 AM EST, "H. Peter Anvin" wrote:
>On January 23, 2016 7:34:33 AM PST, Konrad Rzeszutek Wilk
> wrote:
>>
>>>However, this stub belongs in Linux, not in the Xen toolstack. That
>>>way, when the Linux boot protocol is modified,
On Fri, Jan 22, 2016 at 4:30 PM, Andrew Cooper
wrote:
> the DMLite boot
> protocol is OS agnostic, and will be staying that way.
What's the DMLite boot protocol? Is that the protocol that is defined
by Xen to boot Xen guests and dom0? Is this well documented somewhere?
To be clear are you
On Fri, Jan 22, 2016 at 4:30 PM, Andrew Cooper
wrote:
> I would have though the correct way to do direct Linux support would be
> to have a very small init stub which constructs an appropriate zero
> page, and lets the native entry point get on with things.
As hpa noted recently in another
On 22/01/2016 23:32, Luis R. Rodriguez wrote:
> On Fri, Jan 22, 2016 at 04:35:50PM -0500, Boris Ostrovsky wrote:
>> +/*
>> + * See Documentation/x86/boot.txt.
>> + *
>> + * Version 2.12 supports Xen entry point but we will use default x86/PC
>> + * environment (i.e.
On Fri, Jan 22, 2016 at 4:30 PM, Andrew Cooper
wrote:
> I would have though the correct way to do direct Linux support would be
> to have a very small init stub which constructs an appropriate zero
> page, and lets the native entry point get on with things.
As hpa
On 22/01/2016 23:32, Luis R. Rodriguez wrote:
> On Fri, Jan 22, 2016 at 04:35:50PM -0500, Boris Ostrovsky wrote:
>> +/*
>> + * See Documentation/x86/boot.txt.
>> + *
>> + * Version 2.12 supports Xen entry point but we will use default x86/PC
>> + * environment (i.e.
On Fri, Jan 22, 2016 at 4:30 PM, Andrew Cooper
wrote:
> the DMLite boot
> protocol is OS agnostic, and will be staying that way.
What's the DMLite boot protocol? Is that the protocol that is defined
by Xen to boot Xen guests and dom0? Is this well documented somewhere?
52 matches
Mail list logo