On Fri, Jan 30, 2015 at 12:29:15AM +, Andrew Cooper wrote:
> On 29/01/2015 20:12, Konrad Rzeszutek Wilk wrote:
> > On Thu, Jan 29, 2015 at 06:34:23PM +, Andrew Cooper wrote:
> >>
> >> Getting this conversation back on topic.
> >>
> >> The current state of play in Xen is this:
> >>
> >> * B
On Thu, Jan 29, 2015 at 08:15:16PM +0100, Borislav Petkov wrote:
> On Thu, Jan 29, 2015 at 04:21:05AM +0100, Luis R. Rodriguez wrote:
> > How close?
>
> As close as we can get but not closer - see the thing about updating
> microcode on Intel hyperthreaded logical cores in the other mail.
>
> We
On 29/01/2015 20:12, Konrad Rzeszutek Wilk wrote:
> On Thu, Jan 29, 2015 at 06:34:23PM +, Andrew Cooper wrote:
>>
>> Getting this conversation back on topic.
>>
>> The current state of play in Xen is this:
>>
>> * Boot time microcode loading exists (by scanning uncompressed cpio
>> multiboot m
On Thu, Jan 29, 2015 at 06:34:23PM +, Andrew Cooper wrote:
>
> Getting this conversation back on topic.
>
> The current state of play in Xen is this:
>
> * Boot time microcode loading exists (by scanning uncompressed cpio
> multiboot modules) and should be safe to use.
Please note that it d
On Thu, Jan 29, 2015 at 04:21:05AM +0100, Luis R. Rodriguez wrote:
> How close?
As close as we can get but not closer - see the thing about updating
microcode on Intel hyperthreaded logical cores in the other mail.
We probably can do it in parallel if needed. But it hasn't been needed
until now.
Getting this conversation back on topic.
The current state of play in Xen is this:
* Boot time microcode loading exists (by scanning uncompressed cpio
multiboot modules) and should be safe to use.
* The facility for runtime microcode loading exists (via privileged
hypercall), but is unsafe to u
On Thu, Jan 29, 2015 at 03:01:22PM -0200, Henrique de Moraes Holschuh wrote:
> No, I have not. It was a direct observation based on the fact that
> there is a report of a system misbehaving because of mismatched AMD
> microcode in this very thread. Now, if someone from AMD did state that
> they a
On Thu, Jan 29, 2015, at 10:17, Borislav Petkov wrote:
> On Thu, Jan 29, 2015 at 09:36:49AM -0200, Henrique de Moraes Holschuh
> wrote:
> > But the fact that you cannot trust a system with mismatched microcode to
> > be stable is the hard truth: neither AMD nor Intel are really enforcing
> > that l
On Wed, Jan 28, 2015, at 06:39, Borislav Petkov wrote:
> On Wed, Jan 28, 2015 at 12:10:43AM +, Andrew Cooper wrote:
> > There was a thread on xen-devel but I cant currently find it in the
> > archives.
> >
> > To the best of my memory, it was a 4 core APU system where the BIOS had
> > updated
On Thu, Jan 29, 2015 at 09:36:49AM -0200, Henrique de Moraes Holschuh wrote:
> But the fact that you cannot trust a system with mismatched microcode to
> be stable is the hard truth: neither AMD nor Intel are really enforcing
> that late microcode updates will be always safe in all conditions.
How
On Wed, Jan 28, 2015 at 09:39:24AM +0100, Borislav Petkov wrote:
> On Wed, Jan 28, 2015 at 12:10:43AM +, Andrew Cooper wrote:
> > There was a thread on xen-devel but I cant currently find it in the
> > archives.
> >
> > To the best of my memory, it was a 4 core APU system where the BIOS had
>
On Wed, Jan 28, 2015 at 12:10:43AM +, Andrew Cooper wrote:
> There was a thread on xen-devel but I cant currently find it in the
> archives.
>
> To the best of my memory, it was a 4 core APU system where the BIOS had
> updated the microcode on cpu 0 but left 1-3 at a lower patch level.
> Eve
On 27/01/2015 23:17, Borislav Petkov wrote:
> On Tue, Jan 27, 2015 at 10:26:00PM +, Andrew Cooper wrote:
>> I am not convinced of the safely of permitting microcode updates at
>> runtime. We have seen in the past that having mismatched microcode on
>> different halfs of an AMD cluster causes s
On Tue, Jan 27, 2015 at 10:26:00PM +, Andrew Cooper wrote:
> I am not convinced of the safely of permitting microcode updates at
> runtime. We have seen in the past that having mismatched microcode on
> different halfs of an AMD cluster causes system crashes when non-root
What kind of CPU mix
On 27/01/2015 20:11, Luis R. Rodriguez wrote:
> From: Konrad Rzeszutek Wilk
>
> 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 xenmicroco
On Tue, Jan 27, 2015 at 04:25:09PM -0500, Boris Ostrovsky wrote:
> On 01/27/2015 03:11 PM, Luis R. Rodriguez wrote:
>> +fbuf = mmap(0, len, PROT_READ, MAP_PRIVATE, fd, 0);
>> +
>> +if ((xc_handle = xc_interface_open(0,0,0)) == 0)
>> +{
>> +fprintf(stderr, "Error opening xc inter
On 01/27/2015 03:11 PM, Luis R. Rodriguez wrote:
+fbuf = mmap(0, len, PROT_READ, MAP_PRIVATE, fd, 0);
+
+if ((xc_handle = xc_interface_open(0,0,0)) == 0)
+{
+fprintf(stderr, "Error opening xc interface: %d (%s)\n",
+errno, strerror(errno));
+return 1;
+
From: Konrad Rzeszutek Wilk
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
18 matches
Mail list logo