Avi Kivity wrote:
> >If management apps need to hard-code which slots are available on
> >different targets and different qemu versions, or restrictions on which
> >devices can use which slots, or knowledge that some devices can be
> >multi-function, or ... anything like that is just lame.
> >
>
Avi Kivity wrote:
> On 06/16/2009 09:32 PM, Jamie Lokier wrote:
> >Avi Kivity wrote:
> >
> >>Another issue is enumeration. Guests will present their devices in the
> >>order they find them on the pci bus (of course enumeration is guest
> >>specific). So if I have 2 virtio controllers the only
On 06/17/2009 12:18 PM, Mark McLoughlin wrote:
> On Wed, 2009-06-17 at 12:03 +0300, Avi Kivity wrote:
>
>> On 06/17/2009 11:33 AM, Mark McLoughlin wrote:
>>
I particularly don't like the idea of arcane machine-dependent slot
allocation knowledge living in libvirt, because it nee
On Wed, 2009-06-17 at 12:03 +0300, Avi Kivity wrote:
> On 06/17/2009 11:33 AM, Mark McLoughlin wrote:
> >> I particularly don't like the idea of arcane machine-dependent slot
> >> allocation knowledge living in libvirt, because it needs to be in Qemu
> >> anyway for non-libvirt users. No point in
On 06/17/2009 11:33 AM, Mark McLoughlin wrote:
>> I particularly don't like the idea of arcane machine-dependent slot
>> allocation knowledge living in libvirt, because it needs to be in Qemu
>> anyway for non-libvirt users. No point in having two implementations
>> of something tricky and likely
On Tue, 2009-06-16 at 19:44 +0100, Jamie Lokier wrote:
> Mark McLoughlin wrote:
> > > Worst case we hardcode those numbers (gasp, faint).
> >
> > Maybe we can just add the open slots to the -help output. That'd be nice
> > and clean.
I was being sarcastic - libvirt currently must parse qemu -help
On 06/16/2009 09:32 PM, Jamie Lokier wrote:
> Avi Kivity wrote:
>
>> Another issue is enumeration. Guests will present their devices in the
>> order they find them on the pci bus (of course enumeration is guest
>> specific). So if I have 2 virtio controllers the only way I can
>> distinguish
Mark McLoughlin wrote:
> > Worst case we hardcode those numbers (gasp, faint).
>
> Maybe we can just add the open slots to the -help output. That'd be nice
> and clean.
Make them part of the machine configuration.
After all, they are part of the machine configuration, and ACPI, BIOS
etc. need to
Mark McLoughlin wrote:
> > After libvirt has done -drive file=foo... it should dump the machine
> > config and use that from then on.
>
> Right - libvirt then wouldn't be able to avoid the complexity of merging
> any future changes into the dumped machine config.
As long as qemu can accept a mac
Avi Kivity wrote:
> Another issue is enumeration. Guests will present their devices in the
> order they find them on the pci bus (of course enumeration is guest
> specific). So if I have 2 virtio controllers the only way I can
> distinguish between them is using their pci slots.
virtio contro
On 06/16/2009 03:39 PM, Mark McLoughlin wrote:
>> Worst case we hardcode those numbers (gasp, faint).
>>
>
> Maybe we can just add the open slots to the -help output. That'd be nice
> and clean.
>
Yeah, there's precedent too.
> Or:
>
>$ readlink /usr/share/qemu/machine-types/pc.dt
On Tue, 2009-06-16 at 15:28 +0300, Avi Kivity wrote:
> On 06/16/2009 03:14 PM, Mark McLoughlin wrote:
> > On Mon, 2009-06-15 at 13:12 -0500, Anthony Liguori wrote:
> >
> >> Mark McLoughlin wrote:
> >>
> >>> So long as the restrictions would be known to the management app via
> >>> some "w
On 06/16/2009 03:14 PM, Mark McLoughlin wrote:
> On Mon, 2009-06-15 at 13:12 -0500, Anthony Liguori wrote:
>
>> Mark McLoughlin wrote:
>>
>>> So long as the restrictions would be known to the management app via
>>> some "what slots are available" mechanism in qemu, that sounds fine.
>>>
>
On Mon, 2009-06-15 at 13:12 -0500, Anthony Liguori wrote:
> Mark McLoughlin wrote:
> > So long as the restrictions would be known to the management app via
> > some "what slots are available" mechanism in qemu, that sounds fine.
> >
>
> I'm not sure a "what slots are available" mechanism is as
On 06/15/2009 09:44 PM, Blue Swirl wrote:
>> pc-qemu-0.10?
>>
>
> pc-2009.06? Or given the hardware, should that be pc-1997?
>
pc-qemu-0.10 has the obvious benefit of allowing people to immediately
know what's the oldest version of qemu that supports it.
--
error compiling committee
On 6/15/09, Avi Kivity wrote:
> On 06/15/2009 09:12 PM, Anthony Liguori wrote:
>
> >
> > 2) Whenever the default machine type changes in a guest-visible way,
> introduce a new machine type
> >
>
> s/whenever/qemu stable release/
>
>
> > - Use explicit versions in name: pc-v1, pc-v2
> >
>
> pc-q
Avi Kivity wrote:
> On 06/15/2009 09:12 PM, Anthony Liguori wrote:
>>
>> 2) Whenever the default machine type changes in a guest-visible way,
>> introduce a new machine type
>
> s/whenever/qemu stable release/
>
>> - Use explicit versions in name: pc-v1, pc-v2
>
> pc-qemu-0.10?
>
> This is simila
On 06/15/2009 09:12 PM, Anthony Liguori wrote:
>
> 2) Whenever the default machine type changes in a guest-visible way,
> introduce a new machine type
s/whenever/qemu stable release/
> - Use explicit versions in name: pc-v1, pc-v2
pc-qemu-0.10?
This is similar to a hardware vendor's model num
Mark McLoughlin wrote:
> So long as the restrictions would be known to the management app via
> some "what slots are available" mechanism in qemu, that sounds fine.
>
I'm not sure a "what slots are available" mechanism is as straight
forward as has been claimed. It doesn't matter though becau
On 06/15/2009 07:27 PM, Mark McLoughlin wrote:
Providing end users with the *option* to choose PCI slots sounds like a
fine feature request for any management app.
Requiring all management apps to force end users to explicitly choose
PCI slots in order for slots to be stable is not so reasonabl
On 06/15/2009 07:27 PM, Mark McLoughlin wrote:
However this may end up, isn't it offtopic? Whatever we do we have to
support both pci_addr= and default placement, so we can push this
discussion to livirt-devel and bid them godspeed.
Presumably you're not proposing that qemu-devel complet
On Mon, 2009-06-15 at 18:12 +0300, Dor Laor wrote:
> > It doesn't want to. As Mark said, libvirt just wants to be able to ensure
> > a stable guest ABI, of which stable PCI addresses is one aspect. This does
> > not imply libvirt wants to allocate the PCI addresses, just that it wants
> > a way to
On Mon, 2009-06-15 at 18:05 +0300, Avi Kivity wrote:
> On 06/15/2009 05:24 PM, Anthony Liguori wrote:
> > Dor Laor wrote:
> >> Libvirt does not support r2d. I hope it won't start to support it.
> >
> > It supports mips, sparc, and ppc machines now. I don't see why it
> > wouldn't support r2d. Fo
On 06/15/2009 06:20 PM, Anthony Liguori wrote:
> Avi Kivity wrote:
>> I would prefer explicit names (pci_addr, lun, etc.) but would be okay
>> with generic names too.
>
> I think having a generic address has a lot of value in terms of code
> implementation. Otherwise, the valid options for -driv
Avi Kivity wrote:
> I would prefer explicit names (pci_addr, lun, etc.) but would be okay
> with generic names too.
I think having a generic address has a lot of value in terms of code
implementation. Otherwise, the valid options for -drive become
context-sensitive which is going to be annoyin
On 06/15/2009 06:12 PM, Dor Laor wrote:
>> It doesn't want to. As Mark said, libvirt just wants to be able to
>> ensure
>> a stable guest ABI, of which stable PCI addresses is one aspect. This
>> does
>> not imply libvirt wants to allocate the PCI addresses, just that it
>> wants
>> a way to kee
Daniel P. Berrange wrote:
> On Mon, Jun 15, 2009 at 10:03:22AM -0500, Anthony Liguori wrote:
>
>> Michael S. Tsirkin wrote:
>>
I'm not at all arguing against pci_addr. I'm arguing about how libvirt
should use it with respect to the "genesis" use-case where libvirt has
no
On 06/15/2009 06:07 PM, Anthony Liguori wrote:
> Avi Kivity wrote:
>>
>> I'd object to any implicit addressing rules. If we have to say
>> target=2,lun=7,street=8,city=9,state=99,zip=12345 instead of
>> index=8345345235 so be it.
>
> The next observation is that while we expand the SCSI addressi
Avi Kivity wrote:
> However this may end up, isn't it offtopic? Whatever we do we have to
> support both pci_addr= and default placement, so we can push this
> discussion to livirt-devel and bid them godspeed.
I'm not sure how we got here but yeah, let's table this part of the
discussion.
Reg
Michael S. Tsirkin wrote:
> And then pc-virtio-class-other-with-balloon-without-usb? Wouldn't it be
> more straightforward to have capability bits which can be switched on
> and off independently rather than trying to fit unrelated features into
> a machine type? IMO it only seems more work at fir
On Mon, Jun 15, 2009 at 10:03:22AM -0500, Anthony Liguori wrote:
> Michael S. Tsirkin wrote:
> >>I'm not at all arguing against pci_addr. I'm arguing about how libvirt
> >>should use it with respect to the "genesis" use-case where libvirt has
> >>no specific reason to choose one PCI slot over
Avi Kivity wrote:
>
> I'd object to any implicit addressing rules. If we have to say
> target=2,lun=7,street=8,city=9,state=99,zip=12345 instead of
> index=8345345235 so be it.
The next observation is that while we expand the SCSI addressing, the
current propose flattens the PCI hierarchy (i.e
Michael S. Tsirkin wrote:
>> I'm not at all arguing against pci_addr. I'm arguing about how libvirt
>> should use it with respect to the "genesis" use-case where libvirt has
>> no specific reason to choose one PCI slot over another. In that case,
>> I'm merely advocating that we want to let
On 06/15/2009 05:24 PM, Anthony Liguori wrote:
> Dor Laor wrote:
>> Libvirt does not support r2d. I hope it won't start to support it.
>
> It supports mips, sparc, and ppc machines now. I don't see why it
> wouldn't support r2d. For ppcemb, I expect this same problem to
> occur. This sort of r
On Mon, Jun 15, 2009 at 09:24:32AM -0500, Anthony Liguori wrote:
> Dor Laor wrote:
>> Libvirt does not support r2d. I hope it won't start to support it.
>
> It supports mips, sparc, and ppc machines now. I don't see why it
> wouldn't support r2d. For ppcemb, I expect this same problem to occur.
On Mon, Jun 15, 2009 at 09:20:00AM -0500, Anthony Liguori wrote:
> Mark McLoughlin wrote:
>> On Mon, 2009-06-15 at 07:48 -0500, Anthony Liguori wrote:
>>
Eventually the default configuration becomes increasingly unusable
and you need a new baseline. You must still be able to fall bac
Dor Laor wrote:
> Libvirt does not support r2d. I hope it won't start to support it.
It supports mips, sparc, and ppc machines now. I don't see why it
wouldn't support r2d. For ppcemb, I expect this same problem to occur.
This sort of restriction is going to be common with embedded boards.
>
Mark McLoughlin wrote:
> On Mon, 2009-06-15 at 07:48 -0500, Anthony Liguori wrote:
>
>>> Eventually the
>>> default configuration becomes increasingly unusable and you need a new
>>> baseline. You must still be able to fall back to the old baseline for
>>> older guests. I don't think games
On Mon, 2009-06-15 at 07:48 -0500, Anthony Liguori wrote:
> Avi Kivity wrote:
> > On 06/15/2009 12:09 PM, Mark McLoughlin wrote:
> > I think the point is that you don't need version numbers if you
> > have a
> > proper device tree.
> >
> >
> How do you add a new
Anthony Liguori wrote:
> Avi Kivity wrote:
>> On 06/15/2009 04:23 PM, Anthony Liguori wrote:
>>
>> How would qemu know which slots to optimize for?
>>
>> In practice, I don't see that as a real problem. We should (a) add
>> an ioapic and four more pci links (b) recommend that slots be
>> assigne
On 06/15/2009 04:45 PM, Anthony Liguori wrote:
> Avi Kivity wrote:
>> On 06/15/2009 04:20 PM, Anthony Liguori wrote:
>>> It's not at all that simple. SCSI has a hierarchical address
>>> mechanism with 0-7 targets but then potentially multiple LUNs per
>>> target. Today, we always emulate a sin
On 06/15/2009 04:23 PM, Anthony Liguori wrote:
> Avi Kivity wrote:
>> On 06/15/2009 03:52 PM, Anthony Liguori wrote:
>>> Avi Kivity wrote:
On 06/15/2009 03:41 PM, Michael S. Tsirkin wrote:
> We should just tell the user which slots are open.
> This might be tricky if the config is pa
On 06/15/2009 04:24 PM, Anthony Liguori wrote:
> Avi Kivity wrote:
>>
>> Certainly preferable to -baseline.
>>
>>> This is pretty easy to maintain with config files.
>>
>> Let's not tie the two together.
>
> I mentioned it because it suggests a good transition. We at least
> have to think through
Avi Kivity wrote:
> On 06/15/2009 04:23 PM, Anthony Liguori wrote:
>
> How would qemu know which slots to optimize for?
>
> In practice, I don't see that as a real problem. We should (a) add an
> ioapic and four more pci links (b) recommend that slots be assigned in
> ascending order, and everyt
Avi Kivity wrote:
> On 06/15/2009 04:20 PM, Anthony Liguori wrote:
>> It's not at all that simple. SCSI has a hierarchical address
>> mechanism with 0-7 targets but then potentially multiple LUNs per
>> target. Today, we always emulate a single LUN per target but if we
>> ever wanted to suppo
On 06/15/2009 04:20 PM, Anthony Liguori wrote:
>>
then turns on the power. Command line options are the parts lying
around when we start.
btw, -drive needs to be separated:
-controller type=lsi1234,pci_addr=foobar,name=blah
-drive file=foo.img,controller=bla
Avi Kivity wrote:
> On 06/15/2009 03:52 PM, Anthony Liguori wrote:
>> Avi Kivity wrote:
>>> On 06/15/2009 03:41 PM, Michael S. Tsirkin wrote:
We should just tell the user which slots are open.
This might be tricky if the config is passed in with the command
line
flags.
>>>
>>
Hi,
>> Yes, the user build the machine using the command line and monitor
>> (or, in 2017, the machine configuration file),
>
> Considering pbrook just posted a machine config for arm, I think it
> would be rather sad if pc wasn't converted to it by 2017...
It shouldn't last until 2017, but th
Avi Kivity wrote:
>
> Certainly preferable to -baseline.
>
>> This is pretty easy to maintain with config files.
>
> Let's not tie the two together.
I mentioned it because it suggests a good transition. We at least have
to think through how things map to the post-config file world regardless
of
Avi Kivity wrote:
> On 06/15/2009 03:45 PM, Anthony Liguori wrote:
This last option makes sense to me: in a real world the user has
control over where he places the device on the bus, so why
not with qemu?
>>>
>>> Yes, the user build the machine using the command line and monitor
>>
On 06/15/2009 03:52 PM, Anthony Liguori wrote:
> Avi Kivity wrote:
>> On 06/15/2009 03:41 PM, Michael S. Tsirkin wrote:
>>> We should just tell the user which slots are open.
>>> This might be tricky if the config is passed in with the command line
>>> flags.
>>
>> qemu -show-available-pci-slots
On 06/15/2009 03:48 PM, Anthony Liguori wrote:
> device tree lacking said attribute, distinguish between a device tree
> from an old version of qemu (i.e. use the old default) and a partial
> device tree from the VM manager (i.e. use the new default) ?
>
-baseline 0.10
>>>
>>>
On 06/15/2009 03:45 PM, Anthony Liguori wrote:
>>> This last option makes sense to me: in a real world the user has
>>> control over where he places the device on the bus, so why
>>> not with qemu?
>>
>> Yes, the user build the machine using the command line and monitor
>> (or, in 2017, the machin
On 06/15/2009 03:41 PM, Anthony Liguori wrote:
>>> Yep, most people seem to agree that it makes sense to allow this, but
>>> some believe it should only be via a machine description file, not the
>>> command line.
>>
>> I don't understand this opposition. It's clear a machine config file
>> is a
Avi Kivity wrote:
> On 06/15/2009 03:41 PM, Michael S. Tsirkin wrote:
>> We should just tell the user which slots are open.
>>
>> This might be tricky if the config is passed in with the command line
>> flags.
>>
>
> qemu -show-available-pci-slots
Why does the user care?
Let QEMU allocate
On 06/15/2009 03:41 PM, Michael S. Tsirkin wrote:
> We should just tell the user which slots are open.
>
>
> This might be tricky if the config is passed in with the command line
> flags.
>
qemu -show-available-pci-slots
(the qemu equivalent to KVM_CHECK_EXTENSION)
--
error compiling co
Avi Kivity wrote:
> On 06/15/2009 12:09 PM, Mark McLoughlin wrote:
> I think the point is that you don't need version numbers if you
> have a
> proper device tree.
>
>
How do you add a new attribute to the device tree and, when a supplied
device tree lacking
Avi Kivity wrote:
> On 06/14/2009 12:50 PM, Michael S. Tsirkin wrote:
>> On Fri, Jun 12, 2009 at 05:48:23PM +0100, Mark McLoughlin wrote:
>>
>>> However, in order to retain compat for that SCSI device (e.g. ensuring
>>> the PCI address doesn't change as other devices are added an removed),
>>> w
On Mon, Jun 15, 2009 at 02:56:42PM +0300, Avi Kivity wrote:
> On 06/15/2009 02:48 PM, Michael S. Tsirkin wrote:
>>> A slot needs to be configured in ACPI,
>>>
>>
>> Can we configure all possible 32 slots?
>>
>
> That's what we do. But one is always taken. In the future, perhaps more.
>
Avi Kivity wrote:
> On 06/15/2009 12:08 PM, Mark McLoughlin wrote:
>>> This last option makes sense to me: in a real world the user has
>>> control over where he places the device on the bus, so why
>>> not with qemu?
>>>
>>
>> Yep, most people seem to agree that it makes sense to allow this,
On 06/15/2009 02:48 PM, Michael S. Tsirkin wrote:
>> A slot needs to be configured in ACPI,
>>
>
> Can we configure all possible 32 slots?
>
That's what we do. But one is always taken. In the future, perhaps more.
>> and not be taken by onboard chips
>> (piix takes slot 0, for example
On Mon, Jun 15, 2009 at 02:27:14PM +0300, Avi Kivity wrote:
> On 06/15/2009 01:32 PM, Michael S. Tsirkin wrote:
>>> You do need to export available slot numbers from qemu.
>>>
>>
>> Why would a slot be unavailable?
>>
>
> A slot needs to be configured in ACPI,
Can we configure all possib
On Mon, Jun 15, 2009 at 02:14:15PM +0300, Gleb Natapov wrote:
> On Mon, Jun 15, 2009 at 02:07:53PM +0300, Michael S. Tsirkin wrote:
> > On Mon, Jun 15, 2009 at 01:52:13PM +0300, Gleb Natapov wrote:
> > > On Mon, Jun 15, 2009 at 01:46:53PM +0300, Michael S. Tsirkin wrote:
> > > > On Mon, Jun 15, 200
On 06/15/2009 12:09 PM, Mark McLoughlin wrote:
I think the point is that you don't need version numbers if you have a
proper device tree.
>>> How do you add a new attribute to the device tree and, when a supplied
>>> device tree lacking said attribute, distinguish betw
On 06/15/2009 01:32 PM, Michael S. Tsirkin wrote:
>> You do need to export available slot numbers from qemu.
>>
>
> Why would a slot be unavailable?
>
A slot needs to be configured in ACPI, and not be taken by onboard chips
(piix takes slot 0, for example).
--
error compiling committe
On Mon, Jun 15, 2009 at 02:07:53PM +0300, Michael S. Tsirkin wrote:
> On Mon, Jun 15, 2009 at 01:52:13PM +0300, Gleb Natapov wrote:
> > On Mon, Jun 15, 2009 at 01:46:53PM +0300, Michael S. Tsirkin wrote:
> > > On Mon, Jun 15, 2009 at 01:44:56PM +0300, Gleb Natapov wrote:
> > > > On Mon, Jun 15, 200
On Mon, Jun 15, 2009 at 01:52:13PM +0300, Gleb Natapov wrote:
> On Mon, Jun 15, 2009 at 01:46:53PM +0300, Michael S. Tsirkin wrote:
> > On Mon, Jun 15, 2009 at 01:44:56PM +0300, Gleb Natapov wrote:
> > > On Mon, Jun 15, 2009 at 01:32:49PM +0300, Michael S. Tsirkin wrote:
> > > > > You do need to ex
On Mon, Jun 15, 2009 at 01:46:53PM +0300, Michael S. Tsirkin wrote:
> On Mon, Jun 15, 2009 at 01:44:56PM +0300, Gleb Natapov wrote:
> > On Mon, Jun 15, 2009 at 01:32:49PM +0300, Michael S. Tsirkin wrote:
> > > > You do need to export available slot numbers from qemu.
> > >
> > > Why would a slot b
On Mon, Jun 15, 2009 at 01:44:56PM +0300, Gleb Natapov wrote:
> On Mon, Jun 15, 2009 at 01:32:49PM +0300, Michael S. Tsirkin wrote:
> > > You do need to export available slot numbers from qemu.
> >
> > Why would a slot be unavailable?
> >
> Because it does not exist?
We can create a slot with an
On Mon, Jun 15, 2009 at 01:32:49PM +0300, Michael S. Tsirkin wrote:
> > You do need to export available slot numbers from qemu.
>
> Why would a slot be unavailable?
>
Because it does not exist?
--
Gleb.
___
Virtualization mailin
On Mon, Jun 15, 2009 at 12:27:08PM +0300, Avi Kivity wrote:
> On 06/15/2009 12:08 PM, Mark McLoughlin wrote:
>>> This last option makes sense to me: in a real world the user has
>>> control over where he places the device on the bus, so why
>>> not with qemu?
>>>
>>
>> Yep, most people seem t
On Mon, Jun 15, 2009 at 12:43:48PM +0300, Avi Kivity wrote:
> On 06/14/2009 12:50 PM, Michael S. Tsirkin wrote:
>> On Fri, Jun 12, 2009 at 05:48:23PM +0100, Mark McLoughlin wrote:
>>
>>> However, in order to retain compat for that SCSI device (e.g. ensuring
>>> the PCI address doesn't change as
On Sun, 2009-06-14 at 10:58 +0300, Avi Kivity wrote:
> Mark McLoughlin wrote:
>
>
>
> >> I think the point is that you don't need version numbers if you have a
> >> proper device tree.
> >>
> >
> > How do you add a new attribute to the device tree and, when a supplied
> > device tree lac
On 06/14/2009 12:50 PM, Michael S. Tsirkin wrote:
> On Fri, Jun 12, 2009 at 05:48:23PM +0100, Mark McLoughlin wrote:
>
>> However, in order to retain compat for that SCSI device (e.g. ensuring
>> the PCI address doesn't change as other devices are added an removed),
>> we're back to the same pr
On 06/14/2009 12:47 PM, Michael S. Tsirkin wrote:
> Michael S. Tsirkin wrote:
>>> If we want to remove a device from under a running guest, you need
>>> hotplug. So we can't just remove several lines from the config and hope
>>> that it'll work simply because the PCI address is stable.
>>>
>>>
On 06/15/2009 12:08 PM, Mark McLoughlin wrote:
>> This last option makes sense to me: in a real world the user has
>> control over where he places the device on the bus, so why
>> not with qemu?
>>
>
> Yep, most people seem to agree that it makes sense to allow this, but
> some believe it sho
On Sun, 2009-06-14 at 12:50 +0300, Michael S. Tsirkin wrote:
> On Fri, Jun 12, 2009 at 05:48:23PM +0100, Mark McLoughlin wrote:
> > However, in order to retain compat for that SCSI device (e.g. ensuring
> > the PCI address doesn't change as other devices are added an removed),
> > we're back to the
On Sun, 2009-06-14 at 12:34 +0300, Michael S. Tsirkin wrote:
> On Fri, Jun 12, 2009 at 04:53:27PM +0100, Mark McLoughlin wrote:
> > The other obvious piece to add to it would be PCI addresses, so that
> > even if you remove a device, the addresses assigned to existing devices
> > don't change.
>
>
On Fri, Jun 12, 2009 at 05:48:23PM +0100, Mark McLoughlin wrote:
> However, in order to retain compat for that SCSI device (e.g. ensuring
> the PCI address doesn't change as other devices are added an removed),
> we're back to the same problem ... either:
>
> 1) Use '-drive file=foo.img,if=scsi,
On Sun, Jun 14, 2009 at 12:37:13PM +0300, Avi Kivity wrote:
> Michael S. Tsirkin wrote:
>>
>> If we want to remove a device from under a running guest, you need
>> hotplug. So we can't just remove several lines from the config and hope
>> that it'll work simply because the PCI address is stable.
>>
Michael S. Tsirkin wrote:
>
> If we want to remove a device from under a running guest, you need
> hotplug. So we can't just remove several lines from the config and hope
> that it'll work simply because the PCI address is stable.
>
Why not?
> OTOH, if you reboot the guest, it's ok for address
On Fri, Jun 12, 2009 at 04:53:27PM +0100, Mark McLoughlin wrote:
> On Fri, 2009-06-12 at 09:55 -0500, Anthony Liguori wrote:
> > Mark McLoughlin wrote:
> > > On Wed, 2009-06-10 at 20:27 +0100, Jamie Lokier wrote:
> > >
> > > = Solution - Separate configuration from compat hints =
> > >
> > > As
Mark McLoughlin wrote:
>> I think the point is that you don't need version numbers if you have a
>> proper device tree.
>>
>
> How do you add a new attribute to the device tree and, when a supplied
> device tree lacking said attribute, distinguish between a device tree
> from an old vers
Anthony Liguori wrote:
>
> What's the problem with parsing the device config and modifying it?
> Is it just complexity?
Two-way modification. Management wants to store the configuration in
their database and tell the hypervisor what the machine looks like. If
qemu also tells management what
On Fri, 2009-06-12 at 20:44 +0300, Blue Swirl wrote:
> If the device has different behavior or different properties from
> guest perspective compared to the old device, it should get a new
> device type so that you could specify in the device tree either the
> old device or the new one.
Yes, that
On 6/12/09, Mark McLoughlin wrote:
> On Fri, 2009-06-12 at 12:00 -0500, Anthony Liguori wrote:
> > Mark McLoughlin wrote:
> > > So, when libvirt creates a guest for the first time, it makes a copy of
> > > the device tree and continues to use that even if qemu is upgraded.
> > > That's enough
On Fri, 2009-06-12 at 12:00 -0500, Anthony Liguori wrote:
> Mark McLoughlin wrote:
> > So, when libvirt creates a guest for the first time, it makes a copy of
> > the device tree and continues to use that even if qemu is upgraded.
> > That's enough to ensure compat is retained for all built-in devi
Mark McLoughlin wrote:
> So, when libvirt creates a guest for the first time, it makes a copy of
> the device tree and continues to use that even if qemu is upgraded.
> That's enough to ensure compat is retained for all built-in devices.
>
> However, in order to retain compat for that SCSI device (
On Fri, 2009-06-12 at 11:12 -0500, Anthony Liguori wrote:
> Mark McLoughlin wrote:
> > On Fri, 2009-06-12 at 09:55 -0500, Anthony Liguori wrote:
> >
> >> Mark McLoughlin wrote:
> >>
> >>> On Wed, 2009-06-10 at 20:27 +0100, Jamie Lokier wrote:
> >>>
> >>> = Solution - Separate configurati
On Fri, 2009-06-12 at 11:11 -0500, Anthony Liguori wrote:
> Mark McLoughlin wrote:
> > On Fri, 2009-06-12 at 09:51 -0500, Anthony Liguori wrote:
> >
> >> Mark McLoughlin wrote:
> >>
> >>> On Wed, 2009-06-10 at 20:27 +0100, Jamie Lokier wrote:
> >>>
> >>>
> Michael S. Tsirkin
Mark McLoughlin wrote:
> On Fri, 2009-06-12 at 09:55 -0500, Anthony Liguori wrote:
>
>> Mark McLoughlin wrote:
>>
>>> On Wed, 2009-06-10 at 20:27 +0100, Jamie Lokier wrote:
>>>
>>> = Solution - Separate configuration from compat hints =
>>>
>>> As I suggested before:
>>>
>>> - Allow th
Mark McLoughlin wrote:
> On Fri, 2009-06-12 at 09:51 -0500, Anthony Liguori wrote:
>
>> Mark McLoughlin wrote:
>>
>>> On Wed, 2009-06-10 at 20:27 +0100, Jamie Lokier wrote:
>>>
>>>
Michael S. Tsirkin wrote:
>> I think the right long term answer to
On Fri, 2009-06-12 at 09:55 -0500, Anthony Liguori wrote:
> Mark McLoughlin wrote:
> > On Wed, 2009-06-10 at 20:27 +0100, Jamie Lokier wrote:
> >
> > = Solution - Separate configuration from compat hints =
> >
> > As I suggested before:
> >
> > - Allow the VM manager to dump compat hints; this
On Fri, 2009-06-12 at 09:51 -0500, Anthony Liguori wrote:
> Mark McLoughlin wrote:
> > On Wed, 2009-06-10 at 20:27 +0100, Jamie Lokier wrote:
> >
> >> Michael S. Tsirkin wrote:
> >>
> I think the right long term answer to all this is a way to get QEMU to
> dump it's current machin
Mark McLoughlin wrote:
> On Wed, 2009-06-10 at 20:27 +0100, Jamie Lokier wrote:
>
> = Solution - Separate configuration from compat hints =
>
> As I suggested before:
>
> - Allow the VM manager to dump compat hints; this would be an opaque
> file format, more like the savevm format than a
Mark McLoughlin wrote:
> On Wed, 2009-06-10 at 20:27 +0100, Jamie Lokier wrote:
>
>> Michael S. Tsirkin wrote:
>>
I think the right long term answer to all this is a way to get QEMU to
dump it's current machine configuration in glorious detail as a file
which can be reloaded
On Fri, 2009-06-12 at 16:59 +0300, Michael S. Tsirkin wrote:
> On Fri, Jun 12, 2009 at 09:43:29AM +0100, Mark McLoughlin wrote:
> > = Solution - Separate configuration from compat hints =
> >
> > As I suggested before:
> >
> > - Allow the VM manager to dump compat hints; this would be an opaque
On Fri, Jun 12, 2009 at 09:43:29AM +0100, Mark McLoughlin wrote:
> = Solution - Separate configuration from compat hints =
>
> As I suggested before:
>
> - Allow the VM manager to dump compat hints; this would be an opaque
> file format, more like the savevm format than a config file
Why
On Wed, 2009-06-10 at 20:27 +0100, Jamie Lokier wrote:
> Michael S. Tsirkin wrote:
> > > I think the right long term answer to all this is a way to get QEMU to
> > > dump it's current machine configuration in glorious detail as a file
> > > which can be reloaded as a machine configuration.
> >
> >
99 matches
Mail list logo