On 02/17/2018 05:26 AM, WillyPillow wrote:
I did some timing, and for PVH, my Fedora 26 VMs take about 30s, while Debian 9
takes about 45s. For HVM, qrexec usually times out (did not bother to adjust
the timeout).
P.S.: I recall I had similar issues with HVM in 4.0rc1, cf.
https://github.com
Original Message
On 2018年2月17日 10:30, pixel fairy wrote:
On Friday, February 16, 2018 at 4:07:10 PM UTC-8, Marek Marczykowski-Górecki
wrote:
> Yes, there is "xpti=false" option for Xen command line (xen.gz option in
> grub, or options= line in xen.cfg for UEFI).
tried that by edi
On Sat, February 17, 2018 2:30 am, pixel fairy wrote:
> On Friday, February 16, 2018 at 4:07:10 PM UTC-8, Marek
> Marczykowski-Górecki wrote:
>
>
>> Yes, there is "xpti=false" option for Xen command line (xen.gz option
>> in grub, or options= line in xen.cfg for UEFI).
>
> tried that by editing the
On Friday, February 16, 2018 at 4:07:10 PM UTC-8, Marek Marczykowski-Górecki
wrote:
> Yes, there is "xpti=false" option for Xen command line (xen.gz option in
> grub, or options= line in xen.cfg for UEFI).
tried that by editing the multiboot /xen-4.8.3.gz line while booting. no
change. maybe it
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Fri, Feb 16, 2018 at 11:37:46AM -, 'awokd' via qubes-users wrote:
> On Thu, February 15, 2018 2:24 am, pixel fairy wrote:
>
> > at first i thought it was just the
> > performance hit from mitigating speculation vulnerabilities, but others
> >
On Thu, February 15, 2018 2:24 am, pixel fairy wrote:
> at first i thought it was just the
> performance hit from mitigating speculation vulnerabilities, but others
> were reporting better performance in rc4 than rc3.
Maybe they are on AMD. :)
To rule out mitigations, I know Linux has an option
On 02/15/2018 02:00 AM, pixel fairy wrote:
On Wednesday, February 14, 2018 at 4:58:06 PM UTC-8, pixel fairy wrote:
Fedora. just tried debian. 44.286s seconds.
Forgot the hardware.
i7-6700, 64gigs ddr4, supermicro c7z170-sq, onboard intel graphics.
Got 13s with pvh on a laptop last built in
I also noticed similar slowdowns. I have no experience with rc3 (upgraded
directly from 3.2), but your numbers seem to councide with my experience.
Hardware is also pretty similar, namely Z170/6700K.
--WillyPillow
--
https://blog.nerde.pw/
PGP fingerprint = 6CCF 3FC7 32AC 9D83 D154 217F
pvh. the hvm ones took even longer. looked at a couple systemd-analyze, one of
them had 10s for dkms and 40 for qubes-update-check, even though that one only
took 25s to boot, at least according to dom0. could whatever tells dom0 a guest
is up have run before that?
will play with this more and
On 02/14/2018 08:00 PM, pixel fairy wrote:
On Wednesday, February 14, 2018 at 4:58:06 PM UTC-8, pixel fairy wrote:
Fedora. just tried debian. 44.286s seconds.
Forgot the hardware.
i7-6700, 64gigs ddr4, supermicro c7z170-sq, onboard intel graphics.
What virt_mode is used? Default is pvh; Tr
On Wednesday, February 14, 2018 at 4:58:06 PM UTC-8, pixel fairy wrote:
> Fedora. just tried debian. 44.286s seconds.
Forgot the hardware.
i7-6700, 64gigs ddr4, supermicro c7z170-sq, onboard intel graphics.
--
You received this message because you are subscribed to the Google Groups
"qubes-us
Fedora. just tried debian. 44.286s seconds.
--
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 post to this group, send
On 02/14/2018 05:47 PM, pixel fairy wrote:
[user@dom0 ~]$ time qvm-start personal
real0m23.517s
user0m0.182s
sys 0m0.065s
[user@dom0 ~]$ time qvm-start alpha
real0m23.801s
user0m0.191s
sys 0m0.056s
[user@dom0 ~]$ time qvm-start alphax
real0m32.831s
user0m0.193s
[user@dom0 ~]$ time qvm-start personal
real0m23.517s
user0m0.182s
sys 0m0.065s
[user@dom0 ~]$ time qvm-start alpha
real0m23.801s
user0m0.191s
sys 0m0.056s
[user@dom0 ~]$ time qvm-start alphax
real0m32.831s
user0m0.193s
sys 0m0.059s
starting with debug turned
14 matches
Mail list logo
