Re: [Qemu-devel] [PATCH RESEND v7 0/3] Red Hat PCI bridge resource reserve capability

On Thu, Sep 14, 2017 at 11:15:43AM +0300, Aleksandr Bezzubikov wrote: > 2017-09-10 22:40 GMT+03:00 Marcel Apfelbaum : > > On 10/09/2017 21:34, Aleksandr Bezzubikov wrote: > >> And what about this series? The matching QEMU series has been applied, > >> that's why there should be

Re: [Qemu-devel] [PATCH RESEND v7 0/3] Red Hat PCI bridge resource reserve capability

2017-09-10 22:40 GMT+03:00 Marcel Apfelbaum : > On 10/09/2017 21:34, Aleksandr Bezzubikov wrote: >> >> >> пт, 18 авг. 2017 г. в 2:33, Aleksandr Bezzubikov > >: >> >> >> Now PCI bridges get a bus range number on a system init,

Re: [Qemu-devel] [PATCH RESEND v7 0/3] Red Hat PCI bridge resource reserve capability

On 10/09/2017 21:34, Aleksandr Bezzubikov wrote: пт, 18 авг. 2017 г. в 2:33, Aleksandr Bezzubikov >: Now PCI bridges get a bus range number on a system init, basing on currently plugged devices. That's why when one wants to hotplug

Re: [Qemu-devel] [PATCH RESEND v7 0/3] Red Hat PCI bridge resource reserve capability

пт, 18 авг. 2017 г. в 2:33, Aleksandr Bezzubikov : > Now PCI bridges get a bus range number on a system init, > basing on currently plugged devices. That's why when one wants to hotplug > another bridge, > it needs his child bus, which the parent is unable to provide (speaking

[Qemu-devel] [PATCH RESEND v7 0/3] Red Hat PCI bridge resource reserve capability

Now PCI bridges get a bus range number on a system init, basing on currently plugged devices. That's why when one wants to hotplug another bridge, it needs his child bus, which the parent is unable to provide (speaking about virtual device). The suggested workaround is to have vendor-specific