Re: [PATCH RFC] virtio-spec: flexible configuration layout
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 spec which considered them :) As long as we are able to run older versions of the KVM tool with newer kernels and vice versa, I see no reason why we can't drop 64-bit features from the KVM tool. Pekka So what happened? Did you guys do this? Need to know what to do to make progress. IIUC Rusty removed the new fields in 0.9.3. Does your tool still use them? Did any version of the tool released by distros do so? -- MST ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH RFC] virtio-spec: flexible configuration layout
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. 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 versions of the KVM tool with newer kernels and vice versa, I see no reason why we can't drop 64-bit features from the KVM tool. Pekka So what happened? Did you guys do this? Need to know what to do to make progress. IIUC Rusty removed the new fields in 0.9.3. Does your tool still use them? Did any version of the tool released by distros do so? Yup, they were removed quite a while ago. Thanks, that's nice. So we can reuse that bit if we need it and it won't break your code. -- MST ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH RFC] virtio-spec: flexible configuration layout
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 is that most of the SOCs available on the market don't have it, but this is slowly changing. The main architectural difference is that ARM doesn't provide separate I/O space so the PCI I/O space is usually remapped somewhere into normal address space (grep -r #define __io_address arch/arm/) Would it mean they get stuck with legacy configuration (and no new features)? Or is there an alternative for them? The change only affects the layout of virtio PCI. Arches that don't have PCI don't use virtio PCI, presumably? BTW, the spec only covers x86 ATM, this needs to be fixed. From what I see there is a WIP by Pawel Moll pawel.m...@arm.com to add virtio platform drivers which get virtio working on ARM for example, and by Peter Maydell peter.mayd...@linaro.org to modify the spec to support MMIO access (besides PCI). Yep, it's actually already in 3.2-rc1 (drivers/virtio/virtio_mmio.c) and in the spec (see Appendix X). And actually the control registers layout I used was originally based on the PCI legacy headers (slightly simplified), but evolved a bit since. My understanding is that the changes Michael is proposing affect the PCI device interface only so they shouldn't affect my interface. By the way, I vaguely remember Peter mentioning that he got the PCI device experimentally running some time ago on one of the PCI-enabled ARM platform models (realview or versatile)... Cheers! Pawel ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH RFC] virtio-spec: flexible configuration layout
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 control registers layout I used was originally based on the PCI legacy headers (slightly simplified), but evolved a bit since. My understanding is that the changes Michael is proposing affect the PCI device interface only so they shouldn't affect my interface. I didn't know it's in already, might be interesting adding support to it to x86 userspace tools. Do you mean the qemu or the (non-qemu) KVM tools I know nothing about? ;-) If qemu, Peter got it already running with virtio_mmio on ARM models (not upstream yet as far as I know), but I presume the code would we mostly non-ARM specific. The QEMU code is completely non-ARM-specific (apart from the line in the relevant ARM board models where we instantiate the devices). I haven't submitted it upstream yet though because really the virtio transport layer in QEMU needs to be refactored as a qdev bus first. -- PMM ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH RFC] virtio-spec: flexible configuration layout
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 and we are discussing changing the layout for that field. Mind taking it out of kvm tool for now? Sasha, why did we add 64-bit features to the KVM tool? Wasn't it part of the virtio spec? Does QEMU not use them? How badly will older versions of the KVM tool break if you drop 64-bit features? Pekka ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH RFC] virtio-spec: flexible configuration layout
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 versions of the KVM tool with newer kernels and vice versa, I see no reason why we can't drop 64-bit features from the KVM tool. Pekka ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH RFC] virtio-spec: flexible configuration layout
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 need high feature bits in legacy space. This also frees up feature bit 31 as we don't need it to enable high feature bits anymore. KVM tool actually has support for 64bit features, we can probably remove that when Pekka isn't looking :) What about the Windows drivers? Probably some small adjustments will be required, but I don't see any major problem here. Vadim. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH RFC] virtio-spec: flexible configuration layout
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 functionally unrelated register groups to independent structures, and let the device place is anywhere using a capability in PCI configuration space. It can then go into MMIO space which is cheaper than PIO. A legacy portion of the configuration is mirrored in the first BAR, to keep legacy drivers working. Any new fields can be added in existing structures at the end, so they won't affect legacy. If newer specs add more structures at the end of the config space, and use the same config space for legacy, that space now becomes device specific config space and not new-shiny-feature space, so we must remember to handle those cases. 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 up feature bit 31 as we don't need it to enable high feature bits anymore. KVM tool actually has support for 64bit features, we can probably remove that when Pekka isn't looking :) As this solves the dynamic placement of MSIX vectors and high feature bits, I thought it's easier to just reserve space for that programming than give it a separate structure. This can be changed by a patch on top. Note that data path is split from configuration. PDF will follow. The device initialization sequence might use an update as well. Maybe also a description of how device handles missing structure IDs. [snip] + +\begin_layout Standard + +\change_inserted 1986246365 1320781133 +These registers are specified using vendor-specific PCI capability located + on capability list in PCI configuration space of the device. + This virtio structure capability uses little-endian format; all bits are + read-only: +\end_layout + +\begin_layout Standard + +\change_inserted 1986246365 1320772579 +\begin_inset Tabular Just a note, these tables are way too wide to work properly in PDFs :) +lyxtabular version=3 rows=4 columns=34 +features tabularvalignment=middle +column alignment=center valignment=top width=0pt +column alignment=center valignment=top width=0 +column alignment=center valignment=top width=0 +column alignment=center valignment=top width=0 +column alignment=center valignment=top width=0 +column alignment=center valignment=top width=0 +column alignment=center valignment=top width=0 +column alignment=center valignment=top width=0 +column alignment=center valignment=top width=0 +column alignment=center valignment=top width=0 +column alignment=center valignment=top width=0 +column alignment=center valignment=top width=0 +column alignment=center valignment=top width=0 +column alignment=center valignment=top width=0 +column alignment=center valignment=top width=0 +column alignment=center valignment=top width=0 +column alignment=center valignment=top width=0 +column alignment=center valignment=top width=0 +column alignment=center valignment=top width=0 +column alignment=center valignment=top width=0 +column alignment=center valignment=top width=0 +column alignment=center valignment=top width=0 +column alignment=center valignment=top width=0 +column alignment=center valignment=top width=0 +column alignment=center valignment=top width=0 +column alignment=center valignment=top width=0 +column alignment=center valignment=top width=0 +column alignment=center valignment=top width=0 +column alignment=center valignment=top width=0 +column alignment=center valignment=top width=0 +column alignment=center valignment=top width=0 +column alignment=center valignment=top width=0 +column alignment=center valignment=top width=0 +column alignment=center valignment=top width=0pt +row [snip] + +\begin_layout Standard + +\change_inserted 1986246365 1320779667 +Purpose: +\end_layout + +\begin_layout Standard + +\change_inserted 1986246365 1320780912 + +\emph on +Capability ID +\emph default +, +\emph on +Next Capability Pointer +\emph default +, +\emph on +Capability Length +\emph default + - these fields are specified by PCI local bus specification, Rev 3.0 I'm not sure what capability length is, can't find it in the spec either. [snip] +\begin_layout Plain Layout +ie. + once you enable MSI-X on the device, the other fields move. + If you turn it off again, they move back! Is it still true? We're talking about the new layout here (there are several of this footnote, this one is located right *before* the section which talks about legacy config space. [snip] + +\change_deleted 1986246365 1320784929 +If more than 31 feature bits are supported, the device
Re: [PATCH RFC] virtio-spec: flexible configuration layout
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 functionally unrelated register groups to independent structures, and let the device place is anywhere using a capability in PCI configuration space. 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). Would it mean they get stuck with legacy configuration (and no new features)? Or is there an alternative for them? -- Sasha. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH RFC] virtio-spec: flexible configuration layout
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 send it for early flames/comments. The idea is simple: we split functionally unrelated register groups to independent structures, and let the device place is anywhere using a capability in PCI configuration space. 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). A bit of confusion here: no register is moved from memory into configuration space. Configuration space only gains a list of pointers into memory/pio space. Would it mean they get stuck with legacy configuration (and no new features)? Or is there an alternative for them? The change only affects the layout of virtio PCI. Arches that don't have PCI don't use virtio PCI, presumably? BTW, the spec only covers x86 ATM, this needs to be fixed. -- Sasha. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH RFC] virtio-spec: flexible configuration layout
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 send it for early flames/comments. The idea is simple: we split functionally unrelated register groups to independent structures, and let the device place is anywhere using a capability in PCI configuration space. It can then go into MMIO space which is cheaper than PIO. A legacy portion of the configuration is mirrored in the first BAR, to keep legacy drivers working. Any new fields can be added in existing structures at the end, so they won't affect legacy. If newer specs add more structures at the end of the config space, and use the same config space for legacy, that space now becomes device specific config space and not new-shiny-feature space, so we must remember to handle those cases. Yes. Devices should mirror virtio header and device structures in MMIO and point Structures there. It seems unavoidable for device structures (because legacy layout is dynamic and we don't want to keep doing that), so I thought it's not worth the trouble for virtio header either. Notification and ISR Structures can point into PIO. I'll add some more text to clarify that. 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 up feature bit 31 as we don't need it to enable high feature bits anymore. 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 and we are discussing changing the layout for that field. Mind taking it out of kvm tool for now? As this solves the dynamic placement of MSIX vectors and high feature bits, I thought it's easier to just reserve space for that programming than give it a separate structure. This can be changed by a patch on top. Note that data path is split from configuration. PDF will follow. The device initialization sequence might use an update as well. What is needed? Add an item where the driver scans the PCI capability list to detect the layout? Maybe also a description of how device handles missing structure IDs. [snip] Hmm. I just have 'Drivers should fall back on this legacy structure if a Virtio Structure capability is missing in the PCI capability list'. What else would be helpful? An example? + +\begin_layout Standard + +\change_inserted 1986246365 1320781133 +These registers are specified using vendor-specific PCI capability located + on capability list in PCI configuration space of the device. + This virtio structure capability uses little-endian format; all bits are + read-only: +\end_layout + +\begin_layout Standard + +\change_inserted 1986246365 1320772579 +\begin_inset Tabular Just a note, these tables are way too wide to work properly in PDFs :) True, looks like I need to abbreviate +lyxtabular version=3 rows=4 columns=34 +features tabularvalignment=middle +column alignment=center valignment=top width=0pt +column alignment=center valignment=top width=0 +column alignment=center valignment=top width=0 +column alignment=center valignment=top width=0 +column alignment=center valignment=top width=0 +column alignment=center valignment=top width=0 +column alignment=center valignment=top width=0 +column alignment=center valignment=top width=0 +column alignment=center valignment=top width=0 +column alignment=center valignment=top width=0 +column alignment=center valignment=top width=0 +column alignment=center valignment=top width=0 +column alignment=center valignment=top width=0 +column alignment=center valignment=top width=0 +column alignment=center valignment=top width=0 +column alignment=center valignment=top width=0 +column alignment=center valignment=top width=0 +column alignment=center valignment=top width=0 +column alignment=center valignment=top width=0 +column alignment=center valignment=top width=0 +column alignment=center valignment=top width=0 +column alignment=center valignment=top width=0 +column alignment=center valignment=top width=0 +column alignment=center valignment=top width=0 +column alignment=center valignment=top width=0 +column alignment=center valignment=top width=0 +column alignment=center valignment=top width=0 +column alignment=center valignment=top width=0 +column alignment=center valignment=top width=0 +column alignment=center valignment=top width=0 +column alignment=center
Re: [PATCH RFC] virtio-spec: flexible configuration layout
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 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 functionally unrelated register groups to independent structures, and let the device place is anywhere using a capability in PCI configuration space. 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). A bit of confusion here: no register is moved from memory into configuration space. Configuration space only gains a list of pointers into memory/pio space. The definition of the way the virtio configuration space looks is moved into PCI configuration space, it was constant before. Would it mean they get stuck with legacy configuration (and no new features)? Or is there an alternative for them? The change only affects the layout of virtio PCI. Arches that don't have PCI don't use virtio PCI, presumably? BTW, the spec only covers x86 ATM, this needs to be fixed. From what I see there is a WIP by Pawel Moll pawel.m...@arm.com to add virtio platform drivers which get virtio working on ARM for example, and by Peter Maydell peter.mayd...@linaro.org to modify the spec to support MMIO access (besides PCI). Maybe worth seeing if it works for them... -- Sasha. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH RFC] virtio-spec: flexible configuration layout
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 mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH RFC] virtio-spec: flexible configuration layout
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 driver scans the PCI capability list to detect the layout? Yup, something similar like that - just to make it obvious. Maybe also a description of how device handles missing structure IDs. [snip] Hmm. I just have 'Drivers should fall back on this legacy structure if a Virtio Structure capability is missing in the PCI capability list'. What else would be helpful? An example? I just remembered from your patch that you could define some structure IDs, but not necessarily all of them, if it's not longer the case then ignore me. If it is, then the scenario of a missing structure should be specified (For example, if the ISR structure wasn't defined, fall back to...). Yes, this was the intent of the text above. I'll make that explicit. I'm not sure what capability length is, can't find it in the spec either. [snip] It's the legth of the vendor specific capability structure in bytes. 'the byte immediately following the “Next” pointer in the capability structure is defined to be a length field' It's on page 330 in my copy. Right, I was looking only at the regular cap definition. -- Sasha. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH RFC] virtio-spec: flexible configuration layout
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 re-add them to legacy too. Pekka, 64 features aren't yet used and we are discussing changing the layout for that field. Mind taking it out of kvm tool for now? Sasha, why did we add 64-bit features to the KVM tool? Wasn't it part of the virtio spec? Does QEMU not use them? How badly will older versions of the KVM tool break if you drop 64-bit features? We added 64-bit features to the tool because it just got into the spec when we rewrote our virtio-pci handling - so we just implemented the updated spec. QEMU doesn't use them since while it did get into the spec, it was intended to future-proof the limited feature bits, so no one really needed them yet. 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 :) -- Sasha. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH RFC] virtio-spec: flexible configuration layout
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 up feature bit 31 as we don't need it to enable high feature bits anymore. KVM tool actually has support for 64bit features, we can probably remove that when Pekka isn't looking :) What about the Windows drivers? -- error compiling committee.c: too many arguments to function ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH RFC] virtio-spec: flexible configuration layout
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 need high feature bits in legacy space. This also frees up feature bit 31 as we don't need it to enable high feature bits anymore. KVM tool actually has support for 64bit features, we can probably remove that when Pekka isn't looking :) What about the Windows drivers? While 64-bit features were defined, there was no actual devices to use them. So even if Windows drivers had the ability to support 64-bit features, no device ever needed it therefore no device ever activated it. A potential issue might arise when we remap feature bit 31 to do something else, and when activated it would fool Windows drivers to think that 64-bit features are now activated, while they're not - but thats not something that should happen since legacy layout shouldn't have that field enabled as per the spec (no new features in legacy code). I was unable to check if it was actually implemented in the drivers because http://git.kernel.org/?p=virt/kvm/kvm-guest-drivers-windows.git;a=summary is not quite there (*cough*). -- Sasha. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH RFC] virtio-spec: flexible configuration layout
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 spec which considered them :) As long as we are able to run older versions of the KVM tool with newer kernels and vice versa, I see no reason why we can't drop 64-bit features from the KVM tool. Pekka What do these older versions do? Do they *set* bit 31 in the features register? -- MST ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH RFC] virtio-spec: flexible configuration layout
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 have devices or drivers with 64 bit features, I decided we don't need high feature bits in legacy space. This also frees up feature bit 31 as we don't need it to enable high feature bits anymore. KVM tool actually has support for 64bit features, we can probably remove that when Pekka isn't looking :) What about the Windows drivers? While 64-bit features were defined, there was no actual devices to use them. So even if Windows drivers had the ability to support 64-bit features, no device ever needed it therefore no device ever activated it. A potential issue might arise when we remap feature bit 31 to do something else, and when activated it would fool Windows drivers to think that 64-bit features are now activated, while they're not - but thats not something that should happen since legacy layout shouldn't have that field enabled as per the spec (no new features in legacy code). I was unable to check if it was actually implemented in the drivers because http://git.kernel.org/?p=virt/kvm/kvm-guest-drivers-windows.git;a=summary is not quite there (*cough*). I'm pretty sure windows drivers didn't yet get to it. This was out for a very short time. -- Sasha. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
