On 12/06/15 03:30, Luis R. Rodriguez wrote:
> On Fri, Jan 30, 2015 at 1:57 PM, Luis R. Rodriguez wrote:
>> On Fri, Jan 30, 2015 at 08:37:33PM +, Andrew Cooper wrote:
>>> The right thing to do is to fix the hypercall implementation, at which
>>> point the utility below is fine and xc_microcode_
On Fri, Jan 30, 2015 at 1:57 PM, Luis R. Rodriguez wrote:
> On Fri, Jan 30, 2015 at 08:37:33PM +, Andrew Cooper wrote:
>> The right thing to do is to fix the hypercall implementation, at which
>> point the utility below is fine and xc_microcode_update() can be a thing
>> wrapper around the hyp
On Fri, Jan 30, 2015 at 08:37:33PM +, Andrew Cooper wrote:
> On 30/01/15 19:51, Luis R. Rodriguez wrote:
> > On Fri, Jan 30, 2015 at 02:23:48PM +, Andrew Cooper wrote:
> >> On 30/01/15 01:14, Luis R. Rodriguez wrote:
> >>> From: "Luis R. Rodriguez"
> >>>
> >>> There are several ways that a
On 30/01/2015 21:24, Boris Ostrovsky wrote:
> On 01/30/2015 03:37 PM, Andrew Cooper wrote:
>
>>
>> The actions Xen needs to take are:
>>
>> - Copy the buffer into Xen.
>> - Scan the buffer for the correct patch
>
>
> Why not have the toolstack search for the right patch? Hypervisor will
> verify th
On Fri, Jan 30, 2015 at 1:14 PM, Boris Ostrovsky
wrote:
> But then I thought that Andrew is advocating having the hypervisor doing the
> pause.
A system wide well implemented quiesce with one simple return value
only if all were quiesced seems better for tools to deal with. Let's
wait for that th
On 01/30/2015 03:37 PM, Andrew Cooper wrote:
The actions Xen needs to take are:
- Copy the buffer into Xen.
- Scan the buffer for the correct patch
Why not have the toolstack search for the right patch? Hypervisor will
verify that it's appropriate but won't have to spend time scanning the
On 01/30/2015 03:05 PM, Luis R. Rodriguez wrote:
On Fri, Jan 30, 2015 at 09:44:56AM -0500, Boris Ostrovsky wrote:
On 01/29/2015 08:14 PM, Luis R. Rodriguez wrote:
From: "Luis R. Rodriguez"
+/*
+ * Do not pause already paused domains, and allow us to
+ * unpause only quiesced domains.
+ */
+sta
On 30/01/15 19:51, Luis R. Rodriguez wrote:
> On Fri, Jan 30, 2015 at 02:23:48PM +, Andrew Cooper wrote:
>> On 30/01/15 01:14, Luis R. Rodriguez wrote:
>>> From: "Luis R. Rodriguez"
>>>
>>> There are several ways that a Xen system can update the
>>> CPU microcode on a pvops kernel [0] now, the
On Fri, Jan 30, 2015 at 09:44:56AM -0500, Boris Ostrovsky wrote:
> On 01/29/2015 08:14 PM, Luis R. Rodriguez wrote:
>> From: "Luis R. Rodriguez"
>> +/*
>> + * Do not pause already paused domains, and allow us to
>> + * unpause only quiesced domains.
>> + */
>> +static int quiesce_all_domains(xc_in
On Fri, Jan 30, 2015 at 02:23:48PM +, Andrew Cooper wrote:
> On 30/01/15 01:14, Luis R. Rodriguez wrote:
> > From: "Luis R. Rodriguez"
> >
> > There are several ways that a Xen system can update the
> > CPU microcode on a pvops kernel [0] now, the preferred way
> > is through the early microco
On 01/29/2015 08:14 PM, Luis R. Rodriguez wrote:
From: "Luis R. Rodriguez"
There are several ways that a Xen system can update the
CPU microcode on a pvops kernel [0] now, the preferred way
is through the early microcode update mechanism. At run
time folks should use this new xenmicrocode tool
On 30/01/15 01:14, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez"
>
> There are several ways that a Xen system can update the
> CPU microcode on a pvops kernel [0] now, the preferred way
> is through the early microcode update mechanism. At run
> time folks should use this new xenmicrocode t
From: "Luis R. Rodriguez"
There are several ways that a Xen system can update the
CPU microcode on a pvops kernel [0] now, the preferred way
is through the early microcode update mechanism. At run
time folks should use this new xenmicrocode tool and use
the same CPU microcode file as present on /
13 matches
Mail list logo