Hello!
> I liked the idea of adding all this
> if user supplies e.g.
IMHO there would be a usability problem with this:
a) Too much excessive typing.
b) It is not intuitively understood that you have to define the controller
explicitly. Especially
because if you run qemu by hands, this is not
On Tue, Aug 11, 2015 at 09:28:21AM +0100, Daniel P. Berrange wrote:
On Mon, Aug 10, 2015 at 12:08:02PM -0400, Laine Stump wrote:
On 08/10/2015 11:09 AM, Daniel P. Berrange wrote:
> On Thu, Aug 06, 2015 at 07:46:58PM +0200, Martin Kletzander wrote:
>> On Thu, Aug 06, 2015 at 06:37:41PM +0200, Mar
Hi!
> The only negative impact it would have is that
> if someone has old QEMU installed at define time and later upgrades to
> a QEMU with PCI support before starting the guest, they'll lack the
> PCI controller.
This won't actually happen, because together with the missing controller
he/she
On Mon, Aug 10, 2015 at 12:08:02PM -0400, Laine Stump wrote:
> On 08/10/2015 11:09 AM, Daniel P. Berrange wrote:
> > On Thu, Aug 06, 2015 at 07:46:58PM +0200, Martin Kletzander wrote:
> >> On Thu, Aug 06, 2015 at 06:37:41PM +0200, Martin Kletzander wrote:
> >>> On Fri, Jul 17, 2015 at 02:27:45PM +0
On Mon, Aug 10, 2015 at 07:23:07PM -0400, Cole Robinson wrote:
> On 08/10/2015 11:09 AM, Daniel P. Berrange wrote:
> > On Thu, Aug 06, 2015 at 07:46:58PM +0200, Martin Kletzander wrote:
> >> On Thu, Aug 06, 2015 at 06:37:41PM +0200, Martin Kletzander wrote:
> >>> On Fri, Jul 17, 2015 at 02:27:45PM
Hello!
> > I'd be inclined to go with option 2, and then if any PCI devices are
> > actually used with the guest, check the capability at start time when
> > we are doing auto-address assignment.
I am following the discussion, sorry for being a bit silent... Just didn't
have much to say. But
w
On 08/11/2015 01:23 AM, Martin Kletzander wrote:
> On Mon, Aug 10, 2015 at 07:23:07PM -0400, Cole Robinson wrote:
>> On 08/10/2015 11:09 AM, Daniel P. Berrange wrote:
>>> On Thu, Aug 06, 2015 at 07:46:58PM +0200, Martin Kletzander wrote:
On Thu, Aug 06, 2015 at 06:37:41PM +0200, Martin Kletzan
On Mon, Aug 10, 2015 at 07:23:07PM -0400, Cole Robinson wrote:
On 08/10/2015 11:09 AM, Daniel P. Berrange wrote:
On Thu, Aug 06, 2015 at 07:46:58PM +0200, Martin Kletzander wrote:
On Thu, Aug 06, 2015 at 06:37:41PM +0200, Martin Kletzander wrote:
On Fri, Jul 17, 2015 at 02:27:45PM +0300, Pavel
On 08/10/2015 11:09 AM, Daniel P. Berrange wrote:
> On Thu, Aug 06, 2015 at 07:46:58PM +0200, Martin Kletzander wrote:
>> On Thu, Aug 06, 2015 at 06:37:41PM +0200, Martin Kletzander wrote:
>>> On Fri, Jul 17, 2015 at 02:27:45PM +0300, Pavel Fedin wrote:
Here we assume that if qemu supports gen
On 08/10/2015 11:09 AM, Daniel P. Berrange wrote:
> On Thu, Aug 06, 2015 at 07:46:58PM +0200, Martin Kletzander wrote:
>> On Thu, Aug 06, 2015 at 06:37:41PM +0200, Martin Kletzander wrote:
>>> On Fri, Jul 17, 2015 at 02:27:45PM +0300, Pavel Fedin wrote:
Here we assume that if qemu supports gen
On Thu, Aug 06, 2015 at 07:46:58PM +0200, Martin Kletzander wrote:
> On Thu, Aug 06, 2015 at 06:37:41PM +0200, Martin Kletzander wrote:
> >On Fri, Jul 17, 2015 at 02:27:45PM +0300, Pavel Fedin wrote:
> >>Here we assume that if qemu supports generic PCI host controller,
> >>it is a part of virt mach
On Mon, Aug 10, 2015 at 05:12:26PM +0300, Pavel Fedin wrote:
Hello!
And that's the exact problem. I'm not saying "capabilities are not
made available when defining", but rather "there are no capabilities
when defining".
Stop stop stop... If we don't mess up with terminology...
OK, sorry fo
Hello!
> And that's the exact problem. I'm not saying "capabilities are not
> made available when defining", but rather "there are no capabilities
> when defining".
Stop stop stop... If we don't mess up with terminology...
The test case contains some hardcoded capabilities, needed by the te
On Mon, Aug 10, 2015 at 11:24:42AM +0300, Pavel Fedin wrote:
Hello!
Of course, because there are no capabilities when defining
XML,
And now we need them, because depending on them we now may want to add PCIe
root complex description.
Therefore i think we have to add this to qemu test suite.
Hello!
> Of course, because there are no capabilities when defining
> XML,
And now we need them, because depending on them we now may want to add PCIe
root complex description.
Therefore i think we have to add this to qemu test suite. I will take a look
at it after some time. It actually sh
On Fri, Aug 07, 2015 at 03:27:29PM +0300, Pavel Fedin wrote:
Hello!
The qemuxml2argvtest mocks the capability cache, so it must be
qemuxml2xmltest. And that one should do *nothing* with any
capabilities. Merely because whatever it does must work without any
qemu installed in the system.
Thi
Hello!
> The qemuxml2argvtest mocks the capability cache, so it must be
> qemuxml2xmltest. And that one should do *nothing* with any
> capabilities. Merely because whatever it does must work without any
> qemu installed in the system.
This is what happens if you remove the check:
--- cut ---
On Fri, Aug 07, 2015 at 09:32:56AM +0300, Pavel Fedin wrote:
Hello!
>So every ARM qemu with the "virt" machine type supports both PCI and
>multiqueue?
Every ARM qemu with "virt" machine AND pci-generic supports them.
How about those "virt-*" for which you check below. That
>might not be
Hello!
> >So every ARM qemu with the "virt" machine type supports both PCI and
> >multiqueue?
Every ARM qemu with "virt" machine AND pci-generic supports them.
>> How about those "virt-*" for which you check below. That
> >might not be related, I'm just curious.
Actually mainstream qemu doe
On Thu, Aug 06, 2015 at 06:37:41PM +0200, Martin Kletzander wrote:
On Fri, Jul 17, 2015 at 02:27:45PM +0300, Pavel Fedin wrote:
Here we assume that if qemu supports generic PCI host controller,
it is a part of virt machine and can be used for adding PCI devices.
In qemu this is actually a PCIe
On Fri, Jul 17, 2015 at 02:27:45PM +0300, Pavel Fedin wrote:
Here we assume that if qemu supports generic PCI host controller,
it is a part of virt machine and can be used for adding PCI devices.
In qemu this is actually a PCIe bus, so we also declare multibus
capability so that 0'th bus is spec
On 17.07.2015 13:27, Pavel Fedin wrote:
> Here we assume that if qemu supports generic PCI host controller,
> it is a part of virt machine and can be used for adding PCI devices.
>
> In qemu this is actually a PCIe bus, so we also declare multibus
> capability so that 0'th bus is specified to qemu
Here we assume that if qemu supports generic PCI host controller,
it is a part of virt machine and can be used for adding PCI devices.
In qemu this is actually a PCIe bus, so we also declare multibus
capability so that 0'th bus is specified to qemu correctly as 'pcie.0'
Signed-off-by: Pavel Fedin
23 matches
Mail list logo
