Hello!
> 00:04:0 is VFIO passthrough, and i put everything to bus#0 by hands, for
> MSI-X to work. I
> could also leave devices at bus#2, just in
> this case i don't get MSI-X, and this, for example, makes vhost-net unable to
> use irqfds (or
> it cannot initialize at all, again, i
> already
Hello!
> > I don't remember the exact outcome. So, i decided to use addPCIeRoot
> > instead, and
> everything just worked.
>
> Except the extra stuff. The origin of the problem was in my overloading
> "addPCIeRoot" to indicate that the other two controllers should also be
> added. You only
On 12/08/2015 02:22 AM, Pavel Fedin wrote:
Hello!
For AARCH64, though... well, if you want to know why it's added for that
machinetype, I guess you'd need to talk to the person who turned on
addPCIeRoot for AARCH64 :-).
That was me, and i simply reused the existing code.
Yeah, I know
Hello!
> For AARCH64, though... well, if you want to know why it's added for that
> machinetype, I guess you'd need to talk to the person who turned on
> addPCIeRoot for AARCH64 :-).
That was me, and i simply reused the existing code. Actually, initially i
tried to use addPCIRoot first, but
On 12/07/2015 06:38 AM, Pavel Hrdina wrote:
> On Sun, Dec 06, 2015 at 09:46:56PM -0500, Cole Robinson wrote:
>> Hi all,
>
> [...]
>
>> Here are some possible solutions:
>>
>> * Drop the current behavior of adding a PCIe controller unconditionally, and
>> instead require apps to specify it in the
On Mon, Dec 07, 2015 at 10:37:38AM -0500, Cole Robinson wrote:
> On 12/07/2015 07:27 AM, Daniel P. Berrange wrote:
> > On Sun, Dec 06, 2015 at 09:46:56PM -0500, Cole Robinson wrote:
> >> Hi all,
> >>
> >> I'm trying to figure out how apps should request virtio-pci for libvirt +
> >> qemu
> >> +
On 12/07/2015 03:19 AM, Pavel Fedin wrote:
> Hello!
>
>> - The PCIe controller XML is:
>>
>>
>>
>> I have no idea if that's always going to be the expected XML, maybe it's not
>> wise to hardcode that in apps.
>
> Since we are discussing this, i have a question.
> Why do we
On 12/07/2015 07:27 AM, Daniel P. Berrange wrote:
> On Sun, Dec 06, 2015 at 09:46:56PM -0500, Cole Robinson wrote:
>> Hi all,
>>
>> I'm trying to figure out how apps should request virtio-pci for libvirt +
>> qemu
>> + arm/aarch64. Let me provide some background.
>>
>> qemu's arm/aarch64 original
On 12/07/2015 10:37 AM, Cole Robinson wrote:
On 12/07/2015 07:27 AM, Daniel P. Berrange wrote:
On Sun, Dec 06, 2015 at 09:46:56PM -0500, Cole Robinson wrote:
Hi all,
I'm trying to figure out how apps should request virtio-pci for libvirt + qemu
+ arm/aarch64. Let me provide some background.
On 12/07/2015 10:33 AM, Cole Robinson wrote:
On 12/07/2015 03:19 AM, Pavel Fedin wrote:
Hello!
- The PCIe controller XML is:
I have no idea if that's always going to be the expected XML, maybe it's not
wise to hardcode that in apps.
Since we are discussing this, i have
Hello!
> - The PCIe controller XML is:
>
>
>
> I have no idea if that's always going to be the expected XML, maybe it's not
> wise to hardcode that in apps.
Since we are discussing this, i have a question.
Why do we construct exactly this thing? What is "dmi-to-pci-bridge" and
On Sun, Dec 06, 2015 at 09:46:56PM -0500, Cole Robinson wrote:
> Hi all,
>
> I'm trying to figure out how apps should request virtio-pci for libvirt + qemu
> + arm/aarch64. Let me provide some background.
>
> qemu's arm/aarch64 original virtio support is via virtio-mmio, libvirt XML
> .
On Sun, Dec 06, 2015 at 09:46:56PM -0500, Cole Robinson wrote:
> Hi all,
[...]
> Here are some possible solutions:
>
> * Drop the current behavior of adding a PCIe controller unconditionally, and
> instead require apps to specify it in the XML. Then, if libvirt sees a PCIe
> controller in the
Hi all,
I'm trying to figure out how apps should request virtio-pci for libvirt + qemu
+ arm/aarch64. Let me provide some background.
qemu's arm/aarch64 original virtio support is via virtio-mmio, libvirt XML
. Currently this is what libvirt sets as the
address default for all arm/aarch64 virtio
14 matches
Mail list logo
