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 same
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 should only
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.
Why not?
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 problem
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 lacking said
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 other
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 to agree that it
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 be
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 export
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 committee.c:
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 between a device tree
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, 2009 at
Avi Kivity a...@redhat.com writes:
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
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 possible 32 slots?
(adding cc)
On 06/15/2009 02:35 PM, Markus Armbruster wrote:
Not really. QEMU gives just the host bridge a fixed slot[*]. All the
other slots are available.
qemu needs to export these two bits of information: the first free slot
and the number of slots.
More generally, which slots are
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).
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, but
some
Avi Kivity a...@redhat.com writes:
(adding cc)
On 06/15/2009 02:35 PM, Markus Armbruster wrote:
Not really. QEMU gives just the host bridge a fixed slot[*]. All the
other slots are available.
qemu needs to export these two bits of information: the first free
slot and the number of
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.
and not be
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),
we're back to
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 said attribute, distinguish
Markus Armbruster wrote:
Avi Kivity a...@redhat.com writes:
Paul/Anthony, can we have -vga pci_addr=, -usb-controller pci_addr=,
and -drive pci_addr= (and later, -disk-controller)? Stalling while
waiting for the ultimate config file is only generating pain and
out-of-tree patches.
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
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 the PCI
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 long way in
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 machine
Anthony Liguori anth...@codemonkey.ws writes:
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
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
Why does the
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
(or, in 2017, the
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
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 the
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.
qemu
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=blah,index=0
-drive
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 support more
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 everything
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 single LUN per
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 how things map
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 passed in with the
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 attribute to the device tree and,
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 with
On Mon, Jun 15, 2009 at 6:43 AM, Avi Kivitya...@redhat.com wrote:
(I'd be quite happy constructing the entire machine config on the command
line, but I realize it's just me)
as a user-only (well, i'm a developer, but don't meddle in kernel
affairs since 0.99pl9); I also like that kvm is totally
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 back
to the
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 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
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 QEMU
Avi Kivity wrote:
(I'd be quite happy constructing the entire machine config on the
command line, but I realize it's just me)
It is not just you.
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
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.
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 another.
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 first,
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.
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 addressing, the
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 specific reason to
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 keep them
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 annoying
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 -drive
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. For ppcemb, I
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 keep
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
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
This patch adds basic Virtual Ethernet Port Aggregator (VEPA)
capabilities to the Linux kernel Ethernet bridging code.
A Virtual Ethernet Port Aggregator (VEPA) is a capability within
a physical end station that collaborates with an adjacent, external
bridge to provide distributed bridging
Under newer kernels the bridge configuration parameters
are located under /sys/class/net/$bridgename/bridge/$param,
while the current bridge-utils code is trying to access
them under /sys/class/net/$bridgename/$param. This patch
fixes this issue in the bridge-utils code and so allows
setting of
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 because
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 number
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 similar to a hardware
On 6/15/09, Avi Kivity a...@redhat.com 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
In the near future, the driver core is going to not allow direct access
to the driver_data pointer in struct device. Instead, the functions
dev_get_drvdata() and dev_set_drvdata() should be used. These functions
have been around since the beginning, so are backwards compatible with
all older
In the near future, the driver core is going to not allow direct access
to the driver_data pointer in struct device. Instead, the functions
dev_get_drvdata() and dev_set_drvdata() should be used. These functions
have been around since the beginning, so are backwards compatible with
all older
67 matches
Mail list logo
