On Wed, Nov 09, 2011 at 02:36:43PM +0200, Pekka Enberg wrote:
On Wed, 9 Nov 2011, Sasha Levin wrote:
They don't exist in kernel code either, for same reason as above.
Nothing will break if we remove it since no one really used it, we were
probably the first and only implementation of the
On Mon, Jun 18, 2012 at 02:05:17PM +0200, Sasha Levin wrote:
On Mon, 2012-06-18 at 14:54 +0300, Michael S. Tsirkin wrote:
On Wed, Nov 09, 2011 at 02:36:43PM +0200, Pekka Enberg wrote:
On Wed, 9 Nov 2011, Sasha Levin wrote:
They don't exist in kernel code either, for same reason as above.
On Wed, 2011-11-09 at 10:20 +, Sasha Levin wrote:
I'm also wondering it it's ok to move virtio configuration out of virtio
space and into PCI space for archs that don't have PCI (such as ARM).
Just a note - ARM-based chips can by all means have PCI (grep -r PCI
arch/arm/ ;-). The fact
On 9 November 2011 11:06, Pawel Moll pawel.m...@arm.com wrote:
On Wed, 2011-11-09 at 10:55 +, Sasha Levin wrote:
On Wed, 2011-11-09 at 10:47 +, Pawel Moll wrote:
Yep, it's actually already in 3.2-rc1 (drivers/virtio/virtio_mmio.c) and
in the spec (see Appendix X). And actually the
On Wed, 9 Nov 2011, Michael S. Tsirkin wrote:
KVM tool actually has support for 64bit features, we can probably remove
that when Pekka isn't looking :)
It's not yet released so maybe it's not an issue yet.
If it's too late I can re-add them to legacy too.
Pekka, 64 features aren't yet used
On Wed, 9 Nov 2011, Sasha Levin wrote:
They don't exist in kernel code either, for same reason as above.
Nothing will break if we remove it since no one really used it, we were
probably the first and only implementation of the spec which considered
them :)
As long as we are able to run older
On Wed, 2011-11-09 at 14:38 +0200, Avi Kivity wrote:
On 11/09/2011 10:46 AM, Sasha Levin wrote:
Alternatively we can add new structures with new
structure IDs, pointed to from PCI configuration space.
As we don't yet have devices or drivers with 64 bit features,
I decided we don't
On Tue, 2011-11-08 at 23:40 +0200, Michael S. Tsirkin wrote:
Here's a spec change documenting what my C patch does
(almost - I tweaked the layout a bit, but the idea is the same).
Some more cleanups are needed but I thought I'd send it
for early flames/comments.
The idea is simple: we split
On Tue, 2011-11-08 at 23:40 +0200, Michael S. Tsirkin wrote:
Here's a spec change documenting what my C patch does
(almost - I tweaked the layout a bit, but the idea is the same).
Some more cleanups are needed but I thought I'd send it
for early flames/comments.
The idea is simple: we split
On Wed, Nov 09, 2011 at 11:55:02AM +0200, Sasha Levin wrote:
On Tue, 2011-11-08 at 23:40 +0200, Michael S. Tsirkin wrote:
Here's a spec change documenting what my C patch does
(almost - I tweaked the layout a bit, but the idea is the same).
Some more cleanups are needed but I thought I'd
On Wed, Nov 09, 2011 at 10:46:06AM +0200, Sasha Levin wrote:
On Tue, 2011-11-08 at 23:40 +0200, Michael S. Tsirkin wrote:
Here's a spec change documenting what my C patch does
(almost - I tweaked the layout a bit, but the idea is the same).
Some more cleanups are needed but I thought I'd
On Wed, 2011-11-09 at 12:18 +0200, Michael S. Tsirkin wrote:
On Wed, Nov 09, 2011 at 11:55:02AM +0200, Sasha Levin wrote:
On Tue, 2011-11-08 at 23:40 +0200, Michael S. Tsirkin wrote:
Here's a spec change documenting what my C patch does
(almost - I tweaked the layout a bit, but the idea
On 11/08/2011 11:41 PM, Michael S. Tsirkin wrote:
PDF will follow.
Attached for the lyx challenged :)
The diagrams are truncated.
Otherwise looks reasonable.
--
error compiling committee.c: too many arguments to function
___
Virtualization
On Wed, Nov 09, 2011 at 12:26:08PM +0200, Sasha Levin wrote:
On Wed, 2011-11-09 at 12:13 +0200, Michael S. Tsirkin wrote:
On Wed, Nov 09, 2011 at 10:46:06AM +0200, Sasha Levin wrote:
The device initialization sequence might use an update as well.
What is needed? Add an item where the
On Wed, 2011-11-09 at 14:25 +0200, Pekka Enberg wrote:
On Wed, 9 Nov 2011, Michael S. Tsirkin wrote:
KVM tool actually has support for 64bit features, we can probably remove
that when Pekka isn't looking :)
It's not yet released so maybe it's not an issue yet.
If it's too late I can
On 11/09/2011 10:46 AM, Sasha Levin wrote:
Alternatively we can add new structures with new
structure IDs, pointed to from PCI configuration space.
As we don't yet have devices or drivers with 64 bit features,
I decided we don't need high feature bits in legacy space.
This also frees
On Wed, 2011-11-09 at 14:38 +0200, Avi Kivity wrote:
On 11/09/2011 10:46 AM, Sasha Levin wrote:
Alternatively we can add new structures with new
structure IDs, pointed to from PCI configuration space.
As we don't yet have devices or drivers with 64 bit features,
I decided we don't
On Wed, Nov 09, 2011 at 02:36:43PM +0200, Pekka Enberg wrote:
On Wed, 9 Nov 2011, Sasha Levin wrote:
They don't exist in kernel code either, for same reason as above.
Nothing will break if we remove it since no one really used it, we were
probably the first and only implementation of the
On Wed, Nov 09, 2011 at 02:48:58PM +0200, Sasha Levin wrote:
On Wed, 2011-11-09 at 14:38 +0200, Avi Kivity wrote:
On 11/09/2011 10:46 AM, Sasha Levin wrote:
Alternatively we can add new structures with new
structure IDs, pointed to from PCI configuration space.
As we don't yet
19 matches
Mail list logo
