> I'm going to experiment with moving a couple of my Qubes VMs over to the
Ubuntu install under KVM (using VM Manager app).

Nice, I've had the same thought with Fedora Silverblue, but Qube's qvm- etc 
tools make everything so much easier.

> The Qubes 4.1 tree appears to have Xen 4.13 and Linux 5.7, currently.

Indeed R4.1 is using Xen 4.13.1 
<https://github.com/xen-project/xen/commits/RELEASE-4.13.1> last commit was 
back on May 7th 2020, I can't seem to see any AMD/Ryzen specific commits 
that are newer than this date, I was looking at cherry picking Xen commits 
related to AMD/Ryzen however I can't find any.

Any and all AMD Related commits I can find were made in 2019 and are 
included in the current Xen 4.13.1

So perhaps this is actually a dom0/Linux Kernel issue? Surely if it were 
Xen they'd have something committed by now?
On Monday, August 10, 2020 at 8:21:05 PM UTC+10 Chris Laprise wrote:

> On 8/5/20 7:29 PM, Dylanger Daly wrote:
> > Hmm, wonder if I should try building a 4.1 ISO with a Linux 5.8 Kernel, 
> > it's interesting because Xen is able to write to the framebuffer just 
> > fine, I think it's dom0 that isn't able to remap it so it stays at an 
> > address Xen had it configured for, it almost smells like an IOMMU/Memory 
> > Mapping issue, not necessarily GPU.
>
> My Thinkpad T14 arrived and Qubes 4.0.3 installer behaves the same on 
> the T14 as what you reported.
>
> With Ubuntu upgraded to kernel 5.8.0 to fix broken suspend & brightness 
> and system running hot; now its great.... extremely fast, cool and 
> quiet. (Yes, I upgraded kernel bc the existing one had.)
>
> I'm going to experiment with moving a couple of my Qubes VMs over to the 
> Ubuntu install under KVM (using VM Manager app). I've already got an LVM 
> thin pool setup and re-provisioning OS root snapshots to specific VMs 
> before they boot as if they were templates.
>
> > 
> > There's UEFI Options for the UMA Framebuffer size of 512MB, 1GB and 2GB 
> > I've tried all variants unsuccessfully.
> > I don't think it's a Xen issue because I tried simply moving my current 
> > laptop's NVMe, when I entered my LUKs Password (Blind) I could see LEDs 
> > on the keyboard initialize so I think 4.0.3 does indeed work fine.
>
> FYI release notes for both Xen 4.13 and 4.14 mention additional support 
> for new AMD Epyc processors. I interpret this as a server-oriented way 
> of expressing support for certain generations of AMD processors, though 
> I don't know how close Ryzen and Epyc are in terms of operation.
>
> The Qubes 4.1 tree appears to have Xen 4.13 and Linux 5.7, currently.
>
> > 
> > I don't think there's a migration path for 4.0.3 - 4.1 (Backup & 
> > Restore) yet, I don't think the Qubes team have even signed any 4.1 ISOs 
> > yet either so I'd rather 4.0.3 but I'll take anything I can get at this 
> > point.
>
> I feel the same way. I would love to run Qubes on my T14 but I have a 
> feeling that Linux 5.7 won't cut it and I'm not experienced enough with 
> qubes builder to confidently upgrade either Linux or Xen. I did make a 
> sloppy attempt with ISO Master to replace the Qubes 4.0.3 installer ISO 
> kernel with the Ubuntu 5.8.0 kernel but due to my ignorance about the 
> format I couldn't get it to initiate the boot process.
>
> -- 
> Chris Laprise, tas...@posteo.net
> https://github.com/tasket
> https://twitter.com/ttaskett
> PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886
>

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/473120a6-96f5-4ad5-8f8f-20213f5d283an%40googlegroups.com.

Reply via email to