On 12/17/19 1:43 PM, Daniel Henrique Barboza wrote:
I don't actually recall saying that :-). I haven't looked in the list
archives, but what I *can* imagine myself saying is that only devices
mentioned in the XML should be manipulated in any way by libvirt. So,
+1
for example, you
On Tue, 17 Dec 2019 13:43:14 -0300
Daniel Henrique Barboza wrote:
> On 12/17/19 1:32 PM, Alex Williamson wrote:
> > On Tue, 17 Dec 2019 11:25:38 -0500
> > Laine Stump wrote:
> >
> >> On 12/16/19 6:03 PM, Daniel Henrique Barboza wrote:
> >>> About breaking existing configurations, there is
On 12/17/19 1:32 PM, Alex Williamson wrote:
On Tue, 17 Dec 2019 11:25:38 -0500
Laine Stump wrote:
On 12/16/19 6:03 PM, Daniel Henrique Barboza wrote:
About breaking existing configurations, there is the possibility of not
going forward with patch 03, which is enforcing this rule of
On Tue, 17 Dec 2019 11:25:38 -0500
Laine Stump wrote:
> On 12/16/19 6:03 PM, Daniel Henrique Barboza wrote:
> >
> >
> > On 12/16/19 7:28 PM, Cole Robinson wrote:
> >> On 12/16/19 8:36 AM, Daniel Henrique Barboza wrote:
> >>> changes from version 3 [1]:
> >>> - removed last 2 patches that
On 12/16/19 6:03 PM, Daniel Henrique Barboza wrote:
On 12/16/19 7:28 PM, Cole Robinson wrote:
On 12/16/19 8:36 AM, Daniel Henrique Barboza wrote:
changes from version 3 [1]:
- removed last 2 patches that made function 0 of
PCI multifunction devices mandatory
- new patch: news.xml update
-
On 12/16/19 9:48 PM, Alex Williamson wrote:
On Mon, 16 Dec 2019 21:09:20 -0300
Yes, but libvirt should not assume that it can manipulate the bindings
of adjacent devices without being explicitly directed to do so. The
error may be a hindrance to you, but it might also prevent, for
example,
On Mon, 16 Dec 2019 21:09:20 -0300
Daniel Henrique Barboza wrote:
> On 12/16/19 8:43 PM, Alex Williamson wrote:
> > On Mon, 16 Dec 2019 20:24:56 -0300
> > Daniel Henrique Barboza wrote:
> >
> >>
> >> The code isn't forcing a device to be assigned to the guest. It is forcing
> >> all the
On 12/16/19 8:43 PM, Alex Williamson wrote:
On Mon, 16 Dec 2019 20:24:56 -0300
Daniel Henrique Barboza wrote:
The code isn't forcing a device to be assigned to the guest. It is forcing
all the IOMMU devices to be declared in the domain XML to be detached from
the host.
Detached from the
On Mon, 16 Dec 2019 20:24:56 -0300
Daniel Henrique Barboza wrote:
> On 12/16/19 8:06 PM, Alex Williamson wrote:
> > On Mon, 16 Dec 2019 17:28:28 -0500
> > Cole Robinson wrote:
> >
> >> On 12/16/19 8:36 AM, Daniel Henrique Barboza wrote:
> >>> changes from version 3 [1]:
> >
> > Thanks
On 12/16/19 8:06 PM, Alex Williamson wrote:
On Mon, 16 Dec 2019 17:28:28 -0500
Cole Robinson wrote:
On 12/16/19 8:36 AM, Daniel Henrique Barboza wrote:
changes from version 3 [1]:
Thanks for catching this! PCIe root ports or bridges being part of an
IOMMU group is part of the nature of
On 12/16/19 7:28 PM, Cole Robinson wrote:
On 12/16/19 8:36 AM, Daniel Henrique Barboza wrote:
I've attached the nodedev XML for the three devices with iommuGroup 1.
Only the two nvidia devices are assigned to my VM, but not the PCIe
controller device.
Just noticed the attached file. This
On Mon, 16 Dec 2019 17:28:28 -0500
Cole Robinson wrote:
> On 12/16/19 8:36 AM, Daniel Henrique Barboza wrote:
> > changes from version 3 [1]:
> > - removed last 2 patches that made function 0 of
> > PCI multifunction devices mandatory
> > - new patch: news.xml update
> > - changed 'since'
On 12/16/19 7:28 PM, Cole Robinson wrote:
On 12/16/19 8:36 AM, Daniel Henrique Barboza wrote:
changes from version 3 [1]:
- removed last 2 patches that made function 0 of
PCI multifunction devices mandatory
- new patch: news.xml update
- changed 'since' version to 6.0.0 in patch 4
-
On 12/16/19 8:36 AM, Daniel Henrique Barboza wrote:
> changes from version 3 [1]:
> - removed last 2 patches that made function 0 of
> PCI multifunction devices mandatory
> - new patch: news.xml update
> - changed 'since' version to 6.0.0 in patch 4
> - unassigned hostdevs are now getting qemu
14 matches
Mail list logo