On Tue, 2019-10-01 at 16:44 +0200, Martin Kletzander wrote:
> On Mon, Sep 30, 2019 at 04:30:18PM +0100, Daniel P. Berrangé wrote:
> > Of course you could define everything via a set of structs in the
> > code, but its crazy to do that as you've now hardcoded everything
> > at build time,
On Mon, Sep 30, 2019 at 04:30:18PM +0100, Daniel P. Berrangé wrote:
On Mon, Sep 30, 2019 at 05:10:10PM +0200, Andrea Bolognani wrote:
On Mon, 2019-09-30 at 15:30 +0100, Daniel P. Berrangé wrote:
> - Having separated data from the code it is obviously possible to
>extend this without
On Mon, Sep 30, 2019 at 05:10:10PM +0200, Andrea Bolognani wrote:
> On Mon, 2019-09-30 at 15:30 +0100, Daniel P. Berrangé wrote:
> > On Mon, Sep 30, 2019 at 10:55:00AM +0200, Martin Kletzander wrote:
> > > Given the fact that most of these could just be virFileReadValueUint() it
> > > does
> > >
On Mon, 2019-09-30 at 15:30 +0100, Daniel P. Berrangé wrote:
> On Mon, Sep 30, 2019 at 10:55:00AM +0200, Martin Kletzander wrote:
> > Given the fact that most of these could just be virFileReadValueUint() it
> > does
> > not even make it easier to read or write the code.
>
> Errr,
On Mon, Sep 30, 2019 at 10:55:00AM +0200, Martin Kletzander wrote:
> On Fri, Sep 27, 2019 at 01:52:25PM +0100, Daniel P. Berrangé wrote:
> > Add a check reporting if any CPU vulnerabilities have not been mitigated
> > by the kernel. It further reports whether it is safe to use Intel SMT
> > for
On Fri, Sep 27, 2019 at 01:52:25PM +0100, Daniel P. Berrangé wrote:
Add a check reporting if any CPU vulnerabilities have not been mitigated
by the kernel. It further reports whether it is safe to use Intel SMT
for KVM guests or not, as several of the vulnerabilities are dangerous
when combined
