[PATCH] arch/powerpc/kvm/e500: Additional module.h => export.h fixup
This file, like many others, needs to include . Signed-off-by: Kyle Moffett --- arch/powerpc/kvm/e500.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/kvm/e500.c b/arch/powerpc/kvm/e500.c index 26d2090..387c383 100644 --- a/arch/powerpc/kvm/e500.c +++ b/arch/powerpc/kvm/e500.c @@ -13,6 +13,7 @@ */ #include +#include #include #include -- 1.7.7.3 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 15/17] powerpc/e500: Fix up all remaining code uses of CONFIG_E500
The CONFIG_E500 config option is ambiguous and used incorrectly in many
places to refer to some combination of e500v1/v2, e500mc, and e5500.
Fix up each reference to use the correct combinations of the following
config options:
CONFIG_FSL_E500_V1_V2
CONFIG_FSL_E500MC
CONFIG_FSL_E5500
Signed-off-by: Kyle Moffett
---
arch/powerpc/Kconfig |2 +-
arch/powerpc/include/asm/reg_booke.h | 17 ++---
arch/powerpc/kernel/cputable.c |8
arch/powerpc/kernel/entry_32.S |8 +---
arch/powerpc/kvm/Kconfig |3 ++-
arch/powerpc/platforms/Kconfig.cputype | 22 ++
6 files changed, 32 insertions(+), 28 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index e3412a1..53c5acf 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -288,7 +288,7 @@ config HUGETLB_PAGE_SIZE_VARIABLE
config MATH_EMULATION
bool "Math emulation"
- depends on 4xx || 8xx || FSL_E200 || PPC_MPC832x || E500
+ depends on 4xx || 8xx || FSL_E200 || PPC_MPC832x || FSL_E500_V1_V2
---help---
Some PowerPC chips designed for embedded applications do not have
a floating-point unit and therefore do not implement the
diff --git a/arch/powerpc/include/asm/reg_booke.h
b/arch/powerpc/include/asm/reg_booke.h
index 81cd987..845a069 100644
--- a/arch/powerpc/include/asm/reg_booke.h
+++ b/arch/powerpc/include/asm/reg_booke.h
@@ -206,12 +206,10 @@
#define PPC47x_MCSR_FPR0x0080 /* FPR parity error */
#define PPC47x_MCSR_IPR0x0040 /* Imprecise Machine Check Exception
*/
-#ifdef CONFIG_E500
-/* All e500 */
-#define MCSR_MCP 0x8000UL /* Machine Check Input Pin */
-#define MCSR_ICPERR0x4000UL /* I-Cache Parity Error */
-
/* e500v1/v2 */
+#ifdef CONFIG_FSL_E500_V1_V2
+#define MCSR_MCP 0x8000UL /* Machine Check Input Pin */
+#define MCSR_ICPERR0x4000UL /* I-Cache Parity Error */
#define MCSR_DCP_PERR 0x2000UL /* D-Cache Push Parity Error */
#define MCSR_DCPERR0x1000UL /* D-Cache Parity Error */
#define MCSR_BUS_IAERR 0x0080UL /* Instruction Address Error */
@@ -222,8 +220,12 @@
#define MCSR_BUS_WBERR 0x0004UL /* Write Data Bus Error */
#define MCSR_BUS_IPERR 0x0002UL /* Instruction parity Error */
#define MCSR_BUS_RPERR 0x0001UL /* Read parity Error */
+#endif
-/* e500mc */
+/* e500mc/e5500 */
+#if defined(CONFIG_FSL_E500MC) || defined(CONFIG_FSL_E5500)
+#define MCSR_MCP 0x8000UL /* Machine Check Input Pin */
+#define MCSR_ICPERR0x4000UL /* I-Cache Parity Error */
#define MCSR_DCPERR_MC 0x2000UL /* D-Cache Parity Error */
#define MCSR_L2MMU_MHIT0x0400UL /* Hit on multiple TLB entries */
#define MCSR_NMI 0x0010UL /* Non-Maskable Interrupt */
@@ -250,7 +252,8 @@
#endif
/* Bit definitions for the HID1 */
-#ifdef CONFIG_E500
+#if defined(CONFIG_FSL_E500_V1_V2) || defined(CONFIG_FSL_E500MC) \
+ || defined(CONFIG_FSL_E5500)
/* e500v1/v2 */
#define HID1_PLL_CFG_MASK 0xfc00 /* PLL_CFG input pins */
#define HID1_RFXE 0x0002 /* Read fault exception enable */
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index a6f2544..3fd01ca 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -69,10 +69,10 @@ extern void __setup_cpu_power7(unsigned long offset, struct
cpu_spec* spec);
extern void __restore_cpu_power7(void);
extern void __restore_cpu_a2(void);
#endif /* CONFIG_PPC64 */
-#if defined(CONFIG_E500)
+#ifdef CONFIG_FSL_E5500
extern void __setup_cpu_e5500(unsigned long offset, struct cpu_spec* spec);
extern void __restore_cpu_e5500(void);
-#endif /* CONFIG_E500 */
+#endif /* CONFIG_FSL_E5500 */
/* This table only contains "desktop" CPUs, it need to be filled with embedded
* ones as well...
@@ -1975,7 +1975,7 @@ static struct cpu_spec __initdata cpu_specs[] = {
.platform = "ppce500mc",
},
#endif /* CONFIG_FSL_E500MC */
-#ifdef CONFIG_E500 /* FIXME */
+#ifdef CONFIG_FSL_E5500
{ /* e5500 */
.pvr_mask = 0x,
.pvr_value = 0x8024,
@@ -1994,7 +1994,7 @@ static struct cpu_spec __initdata cpu_specs[] = {
.machine_check = machine_check_e500mc,
.platform = "ppce5500",
},
-#endif /* CONFIG_E500 */
+#endif /* CONFIG_FSL_E5500 */
#ifdef CONFIG_PPC_A2
{ /* Standard A2 (>= DD2) + FPU core */
diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S
index 56212bc..373cdc4 100644
--- a/arch/powerpc/kernel/entry_32.S
+++ b/arch/powerpc/kernel/entry_32.S
@@ -178,14 +178,15 @@ transfer_to_handler:
cmplw r1,r9 /* if r
Re: [Alacrityvm-devel] [GIT PULL] AlacrityVM guest drivers for 2.6.33
On Wed, Dec 23, 2009 at 17:58, Anthony Liguori wrote: > On 12/23/2009 01:54 PM, Ira W. Snyder wrote: >> On Wed, Dec 23, 2009 at 09:09:21AM -0600, Anthony Liguori wrote: >>> But both virtio-lguest and virtio-s390 use in-band enumeration and >>> discovery since they do not have support for PCI on either platform. >> >> I'm interested in the same thing, just over PCI. The only PCI agent >> systems I've used are not capable of manipulating the PCI configuration >> space in such a way that virtio-pci is usable on them. > > virtio-pci is the wrong place to start if you want to use a PCI *device* as > the virtio bus. virtio-pci is meant to use the PCI bus as the virtio bus. > That's a very important requirement for us because it maintains the > relationship of each device looking like a normal PCI device. > >> This means >> creating your own enumeration mechanism. Which sucks. > > I don't think it sucks. The idea is that we don't want to unnecessarily > reinvent things. > > Of course, the key feature of virtio is that it makes it possible for you to > create your own enumeration mechanism if you're so inclined. See... the thing is... a lot of us random embedded board developers don't *want* to create our own enumeration mechanisms. I see a huge amount of value in vbus as a common zero-copy DMA-capable virtual-device interface, especially over miscellaneous non-PCI-bus interconnects. I mentioned my PCI-E boards earlier, but I would also personally be interested in using infiniband with RDMA as a virtual device bus. Basically, what it comes down to is vbus is practically useful as a generic way to provide a large number of hotpluggable virtual devices across an arbitrary interconnect. I agree that virtio works fine if you have some out-of-band enumeration and hotplug transport (like emulated PCI), but if you *don't* have that, it's pretty much faster to write your own set of paired network drivers than it is to write a whole enumeration and transport stack for virtio. On top of *that*, with the virtio approach I would need to write a whole bunch of tools to manage the set of virtual devices on my custom hardware. With vbus that management interface would be entirely common code across a potentially large number of virtualized physical transports. If vbus actually gets merged I will most likely be able to spend the time to get the PCI-E crosslinks on my boards talking vbus, otherwise it's liable to get completely shelved as "not worth the effort" to write all the glue to make virtio work. >> See my virtio-phys >> code (http://www.mmarray.org/~iws/virtio-phys/) for an example of how I >> did it. It was modeled on lguest. Help is appreciated. > > If it were me, I'd take a much different approach. I would use a very > simple device with a single transmit and receive queue. I'd create a > standard header, and the implement a command protocol on top of it. You'll > be able to support zero copy I/O (although you'll have a fixed number of > outstanding requests). You would need a single large ring. That's basically about as much work as writing entirely new network and serial drivers over PCI. Not only that, but I The beauty of vbus for me is that I could write a fairly simple logical-to-physical glue driver which lets vbus talk over my PCI-E or infiniband link and then I'm basically done. Not only that, but the tools for adding new virtual devices (ethernet, serial, block, etc) over vbus would be the same no matter what the underlying transport. > But then again, I have no idea what your requirements are. You could > probably get far treating the thing as a network device and just doing ATAoE > or something like that. Oh... yes... clearly the right solution is to forgo the whole zero-copy direct DMA of block writes and instead shuffle the whole thing into 16kB ATAoE packets. That would obviously be much faster on my little 1GHz PowerPC boards Sorry for the rant, but I really do think vbus is a valuable technology and it's a damn shame to see Gregory Haskins being put through this whole hassle. While most everybody else was griping about problems he sat down and wrote some very nice clean maintainable code to do what he needed. Not only that, but he designed a good enough model that it could be ported to run over almost everything from a single PCI-E link to an infiniband network. I personally would love to see vbus merged, into staging at the very least. I would definitely spend some time trying to make it work across PCI-E on my *very* *real* embedded boards. Look at vbus not as another virtualization ABI, but as a multiprotocol high-level device abstraction API that already has one well-implemented and high-performance user. Cheers, Kyle Moffett -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] AlacrityVM guest drivers for 2.6.33
On Tue, Dec 22, 2009 at 12:36, Gregory Haskins wrote: > On 12/22/09 2:57 AM, Ingo Molnar wrote: >> * Gregory Haskins wrote: >>> Actually, these patches have nothing to do with the KVM folks. [...] >> >> That claim is curious to me - the AlacrityVM host > > It's quite simple, really. These drivers support accessing vbus, and > vbus is hypervisor agnostic. In fact, vbus isn't necessarily even > hypervisor related. It may be used anywhere where a Linux kernel is the > "io backend", which includes hypervisors like AlacrityVM, but also > userspace apps, and interconnected physical systems as well. > > The vbus-core on the backend, and the drivers on the frontend operate > completely independent of the underlying hypervisor. A glue piece > called a "connector" ties them together, and any "hypervisor" specific > details are encapsulated in the connector module. In this case, the > connector surfaces to the guest side as a pci-bridge, so even that is > not hypervisor specific per se. It will work with any pci-bridge that > exposes a compatible ABI, which conceivably could be actual hardware. This is actually something that is of particular interest to me. I have a few prototype boards right now with programmable PCI-E host/device links on them; one of my long-term plans is to finagle vbus into providing multiple "virtual" devices across that single PCI-E interface. Specifically, I want to be able to provide virtual NIC(s), serial ports and serial consoles, virtual block storage, and possibly other kinds of interfaces. My big problem with existing virtio right now (although I would be happy to be proven wrong) is that it seems to need some sort of out-of-band communication channel for setting up devices, not to mention it seems to need one PCI device per virtual device. So I would love to be able to port something like vbus to my nify PCI hardware and write some backend drivers... then my PCI-E connected systems would dynamically provide a list of highly-efficient "virtual" devices to each other, with only one 4-lane PCI-E bus. Cheers, Kyle Moffett -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH -v2] Add MCE support to KVM
On Sun, Apr 19, 2009 at 9:19 PM, Huang Ying wrote: > On Sat, 2009-04-18 at 23:54 +0800, Anthony Liguori wrote: >> Huang Ying wrote: >> > The related MSRs are emulated. MCE capability is exported via >> > extension KVM_CAP_MCE and ioctl KVM_X86_GET_MCE_CAP_SUPPORTED. A new >> > vcpu ioctl command KVM_X86_SETUP_MCE is used to setup MCE emulation >> > such as the mcg_cap. MCE is injected via vcpu ioctl command >> > KVM_X86_SET_MCE. Extended machine-check state (MCG_EXT_P) and CMCI are >> > not simulated. >> > >> >> Maybe I'm missing something, but couldn't this be implemented entirely >> within userspace? There's nothing VT/SVM specific about this. If the >> issue is setting these MSRs from userspace via KVM_SET_MSRS isn't >> enough, perhaps we should add userspace MSR handling. >> >> Also, if you implement the MSR logic in userspace, it's pretty simple to >> make it work in the non-TCG case which will be a requirement for >> upstream merging. > > There is more logic than just KVM_SET_MSRS, such as BANK reporting > disabling, overwriting rules, triple fault for UC MCE during MCIP. > Although these logic can be implemented in user space, I think put them > in kernel space is easy to be understood. And the code is pretty short. IMO the main reason to put this in kernel-space would be to make it possible to automatically forward some MCE errors generated by the real hardware (RAM ECC errors for example) down into the VM. Right now I suppose you could do that with the patches to forward RAM-based hard MCEs to userspace using SIGSEGV and handling the SIGSEGV in userspace, but that seems more fragile to me. Cheers, Kyle Moffett -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
