February 9, 2020 8:52 PM, "Marek Marczykowski-Górecki"
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On Sun, Feb 09, 2020 at 09:28:13AM -0800, brendan.h...@gmail.com wrote:
>> On Sunday, February 9, 2020 at 5:25:56 PM UTC, brend...@gmail.com wrote:
>>>
>>>
>>> Has anyone
Claudia:
>> marmarek:
>> For this particular case (microcode included in BIOS newer than in OS), I
>> see two options: make
>> BIOS (coreboot, right?) apply microcode update on resume too, or include
>> newer microcode in OS.
>
> I want to make one thing clear: I am **not** suggesting this
On Sunday, February 9, 2020 at 2:52:57 PM UTC-6, Marek Marczykowski-Górecki
wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On Sun, Feb 09, 2020 at 09:28:13AM -0800, brend...@gmail.com
> wrote:
> > On Sunday, February 9, 2020 at 5:25:56 PM UTC, brend...@gmail.com
> wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Sun, Feb 09, 2020 at 09:28:13AM -0800, brendan.h...@gmail.com wrote:
> On Sunday, February 9, 2020 at 5:25:56 PM UTC, brend...@gmail.com wrote:
> >
> >
> > Has anyone tried utilizing the xen command line options to mask bits in
> > the cpuid, in
On Sunday, February 9, 2020 at 5:25:56 PM UTC, brend...@gmail.com wrote:
>
>
> Has anyone tried utilizing the xen command line options to mask bits in
> the cpuid, in particular section 1.2.35 cpuid_mask_ecx)?
>
> The man page below says that "Settings applied here take effect globally,
>
On Sunday, February 9, 2020 at 3:19:34 PM UTC, Claudia wrote:
>
> > marmarek:
> > This is a very bad idea to "fix" it. Those missing/changed CPUID bits
> later on will cause issues.
> > And given most of the microcode updates recently are about speculative
> execution, missing those
> > features
> marmarek:
> This is a very bad idea to "fix" it. Those missing/changed CPUID bits later
> on will cause issues.
> And given most of the microcode updates recently are about speculative
> execution, missing those
> features will make the host vulnerable to those issues again. There are
>
On Sun, Feb 9, 2020 at 9:15 AM Claudia wrote:
> From linuxreviews.org:
> "There have been reports of RDRAND issues after resuming from suspend on
> some AMD family 15h and family 16h systems. [...] RDRAND support is
> indicated by CPUID Fn0001_ECX[30]. This bit can be reset by clearing
> MSR
February 9, 2020 9:52 AM, zachm1...@gmail.com wrote:
> On Sunday, February 9, 2020 at 3:29:26 AM UTC-6, zach...@gmail.com wrote:
>
>> On Saturday, February 8, 2020 at 8:09:05 PM UTC-6, Marek
>> Marczykowski-Górecki wrote:
>>> If that's about something else, then fixing it would require finding
On Sunday, February 9, 2020 at 3:29:26 AM UTC-6, zach...@gmail.com wrote:
>
> On Saturday, February 8, 2020 at 8:09:05 PM UTC-6, Marek
> Marczykowski-Górecki wrote:
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> On Fri, Feb 07, 2020 at 02:13:56PM -0800, brend...@gmail.com wrote:
On Saturday, February 8, 2020 at 8:09:05 PM UTC-6, Marek
Marczykowski-Górecki wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On Fri, Feb 07, 2020 at 02:13:56PM -0800, brend...@gmail.com
> wrote:
> > On Friday, February 7, 2020 at 9:35:25 PM UTC, zach...@gmail.com wrote:
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Fri, Feb 07, 2020 at 02:13:56PM -0800, brendan.h...@gmail.com wrote:
> On Friday, February 7, 2020 at 9:35:25 PM UTC, zach...@gmail.com wrote:
> >
> > I preemptively submitted this PR to see what the Qubes team thinks.
> >
On Friday, February 7, 2020 at 9:35:25 PM UTC, zach...@gmail.com wrote:
>
> I preemptively submitted this PR to see what the Qubes team thinks.
> https://github.com/QubesOS/qubes-vmm-xen/pull/70
>
> I agree it probably should be fixed upstream, although I've seen the Qubes
> team make exceptions
On Friday, February 7, 2020 at 3:15:38 PM UTC-6, Claudia wrote:
>
> February 7, 2020 8:10 PM, zach...@gmail.com wrote:
>
> > On Friday, February 7, 2020 at 2:07:34 PM UTC-6, zach...@gmail.com
> wrote:
> >
> >> On Friday, February 7, 2020 at 7:03:14 AM UTC-6, Claudia wrote:
> >>> February 7,
February 7, 2020 8:10 PM, zachm1...@gmail.com wrote:
> On Friday, February 7, 2020 at 2:07:34 PM UTC-6, zach...@gmail.com wrote:
>
>> On Friday, February 7, 2020 at 7:03:14 AM UTC-6, Claudia wrote:
>>> February 7, 2020 6:00 AM, zach...@gmail.com wrote:> I have a Thinkpad T495
>>> with an AMD
On Friday, February 7, 2020 at 2:07:34 PM UTC-6, zach...@gmail.com wrote:
>
> On Friday, February 7, 2020 at 7:03:14 AM UTC-6, Claudia wrote:
>>
>> February 7, 2020 6:00 AM, zach...@gmail.com wrote:
>>
>> > I have a Thinkpad T495 with an AMD Ryzen Pro 3700U and Vega 10
>> graphics. Everything
On Friday, February 7, 2020 at 7:03:14 AM UTC-6, Claudia wrote:
>
> February 7, 2020 6:00 AM, zach...@gmail.com wrote:
>
> > I have a Thinkpad T495 with an AMD Ryzen Pro 3700U and Vega 10 graphics.
> Everything seems to be
> > working besides suspend/resume which is crucial for me since I'm on
February 7, 2020 1:03 PM, "Claudia" wrote:
> February 7, 2020 6:00 AM, zachm1...@gmail.com wrote:
>
>> I have a Thinkpad T495 with an AMD Ryzen Pro 3700U and Vega 10 graphics.
>> Everything seems to be
>> working besides suspend/resume which is crucial for me since I'm on the go a
>> lot. I
February 7, 2020 6:00 AM, zachm1...@gmail.com wrote:
> I have a Thinkpad T495 with an AMD Ryzen Pro 3700U and Vega 10 graphics.
> Everything seems to be
> working besides suspend/resume which is crucial for me since I'm on the go a
> lot. I had to build my
> own Qubes R4.0 ISO to get the
I have a Thinkpad T495 with an AMD Ryzen Pro 3700U and Vega 10 graphics.
Everything seems to be working besides suspend/resume which is crucial for
me since I'm on the go a lot. I had to build my own Qubes R4.0 ISO to get
the installer to work due to it needing a 5.0+ kernel for the graphics
I haven't personally tried this but I am highly confident that Qubes will
definitely work on an ASRock X370 Taichi
https://www.asrock.com/mb/AMD/X370%20Taichi/
It's the motherboard out there that has aced being able to do GPU Passthrough
on a Windows Guest VM on a Linux Host so all in all it's
21 matches
Mail list logo
