On Wed, Jan 11, 2012 at 12:25 AM, Rusty Russell ru...@rustcorp.com.au wrote:
On Tue, 10 Jan 2012 19:03:36 +0200, Michael S. Tsirkin m...@redhat.com
wrote:
On Wed, Dec 21, 2011 at 11:03:25AM +1030, Rusty Russell wrote:
Yes. The idea that we can alter fields in the device-specific config
On Wed, 2012-01-11 at 08:47 +, Stefan Hajnoczi wrote:
This is also an opportunity to stop using CPU physical addresses in
the ring and instead perform DMA like a normal PCI device (use bus
addresses).
Euh why ?
That would mean in many cases adding a layer of iommu, which will slow
On Wed, Jan 11, 2012 at 10:55:52AM +1030, Rusty Russell wrote:
On Tue, 10 Jan 2012 19:03:36 +0200, Michael S. Tsirkin m...@redhat.com
wrote:
On Wed, Dec 21, 2011 at 11:03:25AM +1030, Rusty Russell wrote:
Yes. The idea that we can alter fields in the device-specific config
area is
On 01/10/2012 06:25 PM, Rusty Russell wrote:
On Tue, 10 Jan 2012 19:03:36 +0200, Michael S. Tsirkinm...@redhat.com
wrote:
On Wed, Dec 21, 2011 at 11:03:25AM +1030, Rusty Russell wrote:
Yes. The idea that we can alter fields in the device-specific config
area is flawed. There may be cases
On Wed, Jan 11, 2012 at 9:10 AM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
On Wed, 2012-01-11 at 08:47 +, Stefan Hajnoczi wrote:
This is also an opportunity to stop using CPU physical addresses in
the ring and instead perform DMA like a normal PCI device (use bus
addresses).
On Wed, Jan 11, 2012 at 07:30:34AM -0600, Anthony Liguori wrote:
On 01/10/2012 06:25 PM, Rusty Russell wrote:
On Tue, 10 Jan 2012 19:03:36 +0200, Michael S. Tsirkinm...@redhat.com
wrote:
On Wed, Dec 21, 2011 at 11:03:25AM +1030, Rusty Russell wrote:
Yes. The idea that we can alter fields
On 01/11/2012 09:12 AM, Michael S. Tsirkin wrote:
On Wed, Jan 11, 2012 at 07:30:34AM -0600, Anthony Liguori wrote:
On 01/10/2012 06:25 PM, Rusty Russell wrote:
On Tue, 10 Jan 2012 19:03:36 +0200, Michael S. Tsirkinm...@redhat.com
wrote:
On Wed, Dec 21, 2011 at 11:03:25AM +1030, Rusty
On Wed, Jan 11, 2012 at 09:15:49AM -0600, Anthony Liguori wrote:
On 01/11/2012 09:12 AM, Michael S. Tsirkin wrote:
On Wed, Jan 11, 2012 at 07:30:34AM -0600, Anthony Liguori wrote:
On 01/10/2012 06:25 PM, Rusty Russell wrote:
On Tue, 10 Jan 2012 19:03:36 +0200, Michael S. Tsirkinm...@redhat.com
On 01/11/2012 09:21 AM, Michael S. Tsirkin wrote:
On Wed, Jan 11, 2012 at 09:15:49AM -0600, Anthony Liguori wrote:
This is similar to what we have now. But it's still buggy: e.g. if guest
updates MAC byte by byte, we have no way to know when it's done doing
so.
This is no different than a
- Original Message -
On 01/10/2012 05:44 AM, Stefano Stabellini wrote:
On Mon, 9 Jan 2012, Andrew Jones wrote:
I guess if we did the s/XEN_DOM0/LOCAL_APIC IO_APIC ACPI/ in
arch/x86/pci/xen.c it would be pretty easy to review for
equivalence.
Then keep CONFIG_PRIVILIGED, but
On Wed, Jan 11, 2012 at 02:28:48PM +, Stefan Hajnoczi wrote:
On Wed, Jan 11, 2012 at 9:10 AM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
On Wed, 2012-01-11 at 08:47 +, Stefan Hajnoczi wrote:
This is also an opportunity to stop using CPU physical addresses in
the ring
On Wed, Jan 11, 2012 at 09:28:27AM -0600, Anthony Liguori wrote:
On 01/11/2012 09:21 AM, Michael S. Tsirkin wrote:
On Wed, Jan 11, 2012 at 09:15:49AM -0600, Anthony Liguori wrote:
This is similar to what we have now. But it's still buggy: e.g. if guest
updates MAC byte by byte, we have no way
- Original Message -
Describe dom0 support in the config menu and supply help text for it.
v2 adds 'if EXPERT' to keep it out of the standard menu.
Signed-off-by: Andrew Jones drjo...@redhat.com
---
arch/x86/xen/Kconfig |7 ++-
1 files changed, 6 insertions(+), 1
On 01/11/2012 09:45 AM, Michael S. Tsirkin wrote:
On Wed, Jan 11, 2012 at 09:28:27AM -0600, Anthony Liguori wrote:
On 01/11/2012 09:21 AM, Michael S. Tsirkin wrote:
On Wed, Jan 11, 2012 at 09:15:49AM -0600, Anthony Liguori wrote:
This is similar to what we have now. But it's still buggy: e.g.
On Mon, Jan 09, 2012 at 06:51:41PM +0100, Andrew Jones wrote:
PV-on-HVM guests may want to use the xen keyboard/mouse frontend, but
they don't use the xen frame buffer frontend. For this case it doesn't
Ok, but PV does?
make much sense for INPUT_XEN_KBDDEV_FRONTEND to depend on
If the root complaint is that customers think that anything set in
.config is a supported feature, then the solutions are to support
all
the features in .config, re-educate the customers that they're wrong,
or
maintain a local patch to do this stuff.
If only re-educating people was
- Original Message -
On Mon, Jan 09, 2012 at 06:51:41PM +0100, Andrew Jones wrote:
PV-on-HVM guests may want to use the xen keyboard/mouse frontend,
but
they don't use the xen frame buffer frontend. For this case it
doesn't
Ok, but PV does?
make much sense for
When XEN_XENBUS_FRONTEND gets selected as a module it can lead to
unbootable configs. If we need it, then we should just build it in.
Signed-off-by: Andrew Jones drjo...@redhat.com
---
drivers/xen/Kconfig |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git
PV-on-HVM guests may want to use the xen keyboard/mouse frontend, but
they don't use the xen frame buffer frontend. For this case it doesn't
make much sense for INPUT_XEN_KBDDEV_FRONTEND to depend on
XEN_FBDEV_FRONTEND. The opposite direction always makes more sense, i.e.
if you're using xenfb,
Describe dom0 support in the config menu and supply help text for it.
v2 adds 'if EXPERT' to keep it out of the standard menu.
Signed-off-by: Andrew Jones drjo...@redhat.com
---
arch/x86/xen/Kconfig |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git
Add a description to the config menu for xen tmem.
Signed-off-by: Andrew Jones drjo...@redhat.com
---
drivers/xen/Kconfig |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 1d24061..7e8d728 100644
--- a/drivers/xen/Kconfig
On Wed, 11 Jan 2012 15:43:42 +0800
Amos Kong kongjian...@gmail.com wrote:
On Wed, Jan 11, 2012 at 12:54 PM, Stephen Hemminger
shemmin...@vyatta.comwrote:
By adding the a module alias, programs (or users) won't have to explicitly
call modprobe. Vhost-net will always be available if built
On Wed, 11 Jan 2012 11:07:47 +0400
Michael Tokarev m...@tls.msk.ru wrote:
On 11.01.2012 08:54, Stephen Hemminger wrote:
By adding the a module alias, programs (or users) won't have to explicitly
call modprobe. Vhost-net will always be available if built into the kernel.
It does require
On Wed, Jan 11, 2012 at 10:02:51AM -0600, Anthony Liguori wrote:
On 01/11/2012 09:45 AM, Michael S. Tsirkin wrote:
On Wed, Jan 11, 2012 at 09:28:27AM -0600, Anthony Liguori wrote:
On 01/11/2012 09:21 AM, Michael S. Tsirkin wrote:
On Wed, Jan 11, 2012 at 09:15:49AM -0600, Anthony Liguori wrote:
On Wed, Jan 11, 2012 at 17:58, Stephen Hemminger shemmin...@vyatta.com wrote:
On Wed, 11 Jan 2012 11:07:47 +0400
Michael Tokarev m...@tls.msk.ru wrote:
On 11.01.2012 08:54, Stephen Hemminger wrote:
By adding the a module alias, programs (or users) won't have to explicitly
call modprobe.
By adding the correct module alias, programs won't have to explicitly
call modprobe. Vhost-net will always be available if built into the kernel.
It does require assigning a permanent minor number for depmod to work.
Choose one next to TUN since this driver is related to it.
Also, use C99 style
On Wed, Jan 11, 2012 at 3:39 PM, Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Jan 11, 2012 at 02:28:48PM +, Stefan Hajnoczi wrote:
On Wed, Jan 11, 2012 at 9:10 AM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
On Wed, 2012-01-11 at 08:47 +, Stefan Hajnoczi wrote:
On Wed, Jan 11, 2012 at 12:19:11PM -0400, Konrad Rzeszutek Wilk wrote:
If the root complaint is that customers think that anything set in
.config is a supported feature, then the solutions are to support
all
the features in .config, re-educate the customers that they're wrong,
or
On Wed, Jan 11, 2012 at 05:36:38PM +0100, Andrew Jones wrote:
When XEN_XENBUS_FRONTEND gets selected as a module it can lead to
unbootable configs. If we need it, then we should just build it in.
Hm, don't the frontends by themsevles load this module? So if you
do 'modprobe xen-pcifront' it
On Wed, Jan 11, 2012 at 05:36:39PM +0100, Andrew Jones wrote:
PV-on-HVM guests may want to use the xen keyboard/mouse frontend, but
they don't use the xen frame buffer frontend. For this case it doesn't
make much sense for INPUT_XEN_KBDDEV_FRONTEND to depend on
XEN_FBDEV_FRONTEND. The opposite
On Wed, Jan 11, 2012 at 05:21:53PM +, Stefan Hajnoczi wrote:
On Wed, Jan 11, 2012 at 3:39 PM, Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Jan 11, 2012 at 02:28:48PM +, Stefan Hajnoczi wrote:
On Wed, Jan 11, 2012 at 9:10 AM, Benjamin Herrenschmidt
b...@kernel.crashing.org
On Wed, Jan 11, 2012 at 09:16:53AM -0800, Stephen Hemminger wrote:
By adding the correct module alias, programs won't have to explicitly
call modprobe. Vhost-net will always be available if built into the kernel.
It does require assigning a permanent minor number for depmod to work.
Choose one
On 01/11/2012 11:08 AM, Michael S. Tsirkin wrote:
Not sure what you mean. Using VQ is DMA which is pretty common for PCI.
Do you know of a network device that obtains it's mac address via a DMA
transaction?
Regards,
Anthony Liguori
___
On Wed, Jan 11, 2012 at 08:54:26AM -0800, Stephen Hemminger wrote:
On Wed, 11 Jan 2012 15:43:42 +0800
Amos Kong kongjian...@gmail.com wrote:
On Wed, Jan 11, 2012 at 12:54 PM, Stephen Hemminger
shemmin...@vyatta.comwrote:
By adding the a module alias, programs (or users) won't have to
On Wed, Jan 11, 2012 at 01:42:39PM -0600, Anthony Liguori wrote:
On 01/11/2012 11:08 AM, Michael S. Tsirkin wrote:
Not sure what you mean. Using VQ is DMA which is pretty common for PCI.
Do you know of a network device that obtains it's mac address via a DMA
transaction?
Sure.
See
On Wed, 2012-01-11 at 14:28 +, Stefan Hajnoczi wrote:
On Wed, Jan 11, 2012 at 9:10 AM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
On Wed, 2012-01-11 at 08:47 +, Stefan Hajnoczi wrote:
This is also an opportunity to stop using CPU physical addresses in
the ring and
On Wed, 2012-01-11 at 17:12 +0200, Michael S. Tsirkin wrote:
This is similar to what we have now. But it's still buggy: e.g. if guest
updates MAC byte by byte, we have no way to know when it's done doing
so.
Do like real HW, there's plenty of options:
- (better) Have a command update MAC
On Wed, 2012-01-11 at 17:21 +0200, Michael S. Tsirkin wrote:
Possible but doesn't let us layer nicely to allow unchanged drivers
that work with all transports (new pci, old pci, non pci).
Something like a command VQ would be a generic transport
that can be hidden behind config-set(...).
I
On Wed, 2012-01-11 at 13:42 -0600, Anthony Liguori wrote:
On 01/11/2012 11:08 AM, Michael S. Tsirkin wrote:
Not sure what you mean. Using VQ is DMA which is pretty common for PCI.
Do you know of a network device that obtains it's mac address via a DMA
transaction?
I wouldn't be
On Wed, 2012-01-11 at 09:16 -0800, Stephen Hemminger wrote:
By adding the correct module alias, programs won't have to explicitly
call modprobe. Vhost-net will always be available if built into the kernel.
It does require assigning a permanent minor number for depmod to work.
Choose one next
On Wed, 2012-01-11 at 14:26 -0600, Anthony Liguori wrote:
I'd say that's a special case but I see what you're getting at here.
So what about keeping the config space read-only and using control
queues for
everything else?
Which is exactly what Rusty and I are proposing :-) I would go
On Wed, Jan 11, 2012 at 02:26:55PM -0600, Anthony Liguori wrote:
On 01/11/2012 02:14 PM, Michael S. Tsirkin wrote:
On Wed, Jan 11, 2012 at 01:42:39PM -0600, Anthony Liguori wrote:
On 01/11/2012 11:08 AM, Michael S. Tsirkin wrote:
Not sure what you mean. Using VQ is DMA which is pretty common
On Thu, Jan 12, 2012 at 08:02:06AM +1100, Benjamin Herrenschmidt wrote:
On Wed, 2012-01-11 at 14:26 -0600, Anthony Liguori wrote:
I'd say that's a special case but I see what you're getting at here.
So what about keeping the config space read-only and using control
queues for
On Thu, 2012-01-12 at 00:02 +0200, Michael S. Tsirkin wrote:
We could probably have a helper library for sending control messages
which could handle waiting for a ring slot to be free (practically
always the case on control queues), writing the message, sending it
and
waiting for a status
On Thu, 2012-01-12 at 00:13 +0200, Michael S. Tsirkin wrote:
We typically pre-populate the data rings with skb's for 1500 and 9000
bytes packets. Small packets come in immediately in the completion ring,
and large packets via the data ring.
Won't real workloads suffer from packet
On Thu, 2012-01-12 at 00:13 +0200, Michael S. Tsirkin wrote:
Well, I would argue that the network driver world has proven countless
times that those are good ideas :-)
Below you seem to suggest that separate rings like
virtio has now is better than a single ring like Rusty
suggested.
I
On Thu, Jan 12, 2012 at 1:16 AM, Stephen Hemminger
shemmin...@vyatta.com wrote:
By adding the correct module alias, programs won't have to explicitly
call modprobe. Vhost-net will always be available if built into the kernel.
It does require assigning a permanent minor number for depmod to
On Thu, 12 Jan 2012 00:02:33 +0200, Michael S. Tsirkin m...@redhat.com
wrote:
Look, we have a race currently. Let us not tie a bug fix to a huge
rewrite with unclear performance benefits, please.
In theory, yes. In practice, we bandaid it.
I think in the short term we change -get to get the
On Wed, 11 Jan 2012 07:30:34 -0600, Anthony Liguori anth...@codemonkey.ws
wrote:
I think the more important thing to do is require accesses to integers in the
config space to always be aligned and to use the appropriate accessor.
Non-integer fields should be restricted to byte access.
On Thu, 2012-01-12 at 12:31 +1030, Rusty Russell wrote:
Are we going to keep guest endian for e.g. virtio net header?
If yes the benefit of switching config space is not that big.
And changes in devices would affect non-PCI transports.
Yep. It would only make sense if we do it for
50 matches
Mail list logo
