On 4 Apr 2017, at 20:37, Daimon Wang wrote:
Hi Graham, Windows crash after switch to virtio-disk because its
boot loader doesn't have driver for the disk.
^ this, and ...
Reinstall Windows with virtio-disk would fix the issue (you'll
need the virtio-disk driver during installation).
On 3 Apr 2017, at 10:21, globalgorri...@fastmail.fm wrote:
On 3 Apr 2017, at 10:19, Steven Walter wrote:
On Mon, Apr 3, 2017 at 1:08 PM, wrote:
On 2 Apr 2017, at 0:10, Joshua Hoblitt wrote:
I decided to go with an E6-1650 v4 / C612 based motherboard as I
wanted
both ECC memory and a BMC.
On 3 Apr 2017, at 10:19, Steven Walter wrote:
> On Mon, Apr 3, 2017 at 1:08 PM, wrote:
>> On 2 Apr 2017, at 0:10, Joshua Hoblitt wrote:
>>
>>> I decided to go with an E6-1650 v4 / C612 based motherboard as I wanted
>>> both ECC memory and a BMC.
>>
>>
>> I think something this is the best option
Might perform better.
Also, yes Hugepages might be helpful too.
Also, would you mind observing whether interrupts are posted when the
GPU is in use in pass-through?
watch -d cat /proc/interrupts
Look at the bottom for PIN (Posted-interrupt notification event) and PIW
(Posted-interrupt wa
On 2 Apr 2017, at 0:10, Joshua Hoblitt wrote:
I decided to go with an E6-1650 v4 / C612 based motherboard as I
wanted
both ECC memory and a BMC.
I think something this is the best option for the moment.
Posted-interrupts are only on E5 v4 and Xeon-D.
It makes a big difference with network c
I'd be interesting if they were detecting VMs for, or just the presence
of, clock jitter, skew and drift. I don't know much about CS:GO but I
wonder if it might adversely affect game play network data.
It might be interesting for you to track those in the VM and sync
tightly with NTP. Besides
Precisely. I am using libvirt and VFIO to assign SRIOV VFs to guests.
Interestingly, as per my Arch package bug report, using 4.8.X doesn't
trigger the bug for me, simply moving to kernel 4.9.5+ triggers it
(nothing else changed in other packages or guest domain XML).
I built a custom package of
Heads-up if you're using libvirt and Arch Linux and networking VFs and
kernel 4.9+.
https://bugs.archlinux.org/task/52778
___
vfio-users mailing list
vfio-users@redhat.com
https://www.redhat.com/mailman/listinfo/vfio-users
And done.
I just changed the machine type to the Q35 most recent available for me:
pc-q35-2.8
The default PCIE layout worked. Up and running with Wayland on the R9
290.
Thank you Alex! I hope someone else gets to enjoy a similar setup too!
On 24 Oct 2016, at 10:43, Alex Williamson wrote:
On 24 Oct 2016, at 10:23, Alex Williamson wrote:
On Mon, 24 Oct 2016 10:20:08 -0700
globalgorri...@fastmail.fm wrote:
Hi,
Pass-through works fine with the the same linux 4.8 VM and nouveau
and a
Quadro K2200.
Passing-through both a R7 260X and and a R9 290 I get the same kernel
oops:
IP:
Hi,
Pass-through works fine with the the same linux 4.8 VM and nouveau and a
Quadro K2200.
Passing-through both a R7 260X and and a R9 290 I get the same kernel
oops:
IP: [] drm_pcie_get_speed_cap_mask+0x39/0xf0 [drm]
More here:
http://pastebin.com/Waysyk2e
Both the AMD cards work fine if
Hi Alex,
The first time QEMU is run the display attached via DP comes out of
standby and then goes into power saving.
This is used to capture the SeaBIOS debug outputs:
No 00:02.0 (boots to grub from CD-ROM ISO):
https://pastebin.com/y0xtURW5
With 00:02.0 (hangs):
On Wed, Jul 27, 2016, at 06:04 PM, Alex Williamson wrote:
> Hmm, the kernel not exposing the VGA regions is really the only way we
> can fail here and the only two ways that the kernel won't expose VGA,
> given that enabled in the config, is if the device isn't VGA (which we
> can see by your clas
First, thank you for your blog posts and your work on vfio and in this
area.
On Wed, Jul 27, 2016, at 05:20 PM, Alex Williamson wrote:
> On Wed, 27 Jul 2016 17:01:21 -0700
> globalgorri...@fastmail.fm wrote:
>
> > Hello,
> >
> > Do you reckon this is what some bugzilla's find to be a motherboa
Hello,
Do you reckon this is what some bugzilla's find to be a motherboard
memory mapping issue or a chipset issue?
Any ideas on working around it besides opting the IGD out of MMIO?
Doing that prevents it from being used with vfio-pci and qemu.
---
i7-4790k, ASUS Z97-WS (BIOS 2403), kernel
Perhaps this is the answer:
According to their data sheets (volume 2) both Xeon D and E5 v4 have
posted_interrupts_support in vtd[0:1]_cap. E5 v3 does not.
On 12 Apr 2016, at 21:51, globalgorri...@fastmail.fm wrote:
Hello,
Are there any differences between posted interrupt support in the Xe
Hello,
Are there any differences between posted interrupt support in the Xeon
E5 v3, v4, and Xeon D? The latter two are Broadwell, but posted
(external) interrupts are touted with E5 v4 while (I think) VT-d posted
interrupts are already available in E5 v3.
Thanks
___
Even while I use SR-IOV interfaces passed through, I still find
openvswitch very useful.
In your scenario I might just use openvswitch and bind all the NICs.
Perhaps use DPDK if you're primarily doing networking with the device.
Also CoreOS might be nice if again you're building a dedicated
r
Still the same with 4.5-rc4 and AUR qemu-git.
On 23 Jan 2016, at 18:55, Dan Ziemba wrote:
> On Tue, 2016-01-19 at 16:52 +0100, Friedrich Oslage wrote:
>> I did some more testing and it turns out to be a kernel error,
>> introduced somewhere around linux 4.3.
>>
>> Short description of the error:
Hi Nicolas,
Would you be able to send the full IOMMU groups tree for both NUCs? It's
nice to see for the record. I was looking at using a Broadwell or
Haswell one myself.
Skylake was already out of real consideration for me as I was assuming
there would be the same lack of isolation as your're n
20 matches
Mail list logo
