[PATCH] vhost: vsock: select CONFIG_VHOST

When building the new vsock code without vhost, we get a build error: drivers/built-in.o: In function `vhost_vsock_flush': :(.text+0x24d29c): undefined reference to `vhost_poll_flush' This adds an explicit 'select' like we have for the other vhost drivers. Signed-off-by: Arnd Bergmann

Re: [PATCH v1 2/2] dma-mapping-common: add DMA attribute - DMA_ATTR_IOMMU_BYPASS

On Tuesday 03 November 2015 07:13:28 Benjamin Herrenschmidt wrote: > On Mon, 2015-11-02 at 14:07 +0200, Shamir Rabinovitch wrote: > > On Mon, Nov 02, 2015 at 09:00:34PM +1100, Benjamin Herrenschmidt > > wrote: > > > > > > Chosing on a per-mapping basis *in the back end* might still make > > >

Re: [PATCH v1 2/2] dma-mapping-common: add DMA attribute - DMA_ATTR_IOMMU_BYPASS

On Saturday 31 October 2015 10:17:22 Benjamin Herrenschmidt wrote: > On Fri, 2015-10-30 at 11:32 +0100, Arnd Bergmann wrote: > > On Thursday 29 October 2015 10:10:46 Benjamin Herrenschmidt wrote: > > > > > > > Maybe we should at least coordinate IOMMU 'paran

Re: [PATCH v1 2/2] dma-mapping-common: add DMA attribute - DMA_ATTR_IOMMU_BYPASS

On Thursday 29 October 2015 10:10:46 Benjamin Herrenschmidt wrote: > > > Maybe we should at least coordinate IOMMU 'paranoid/fast' modes across > > architectures, and then the DMA_ATTR_IOMMU_BYPASS flag would have a > > sane meaning in the paranoid mode (and perhaps we'd want an ultra > >

Re: [PATCH v4 3/7] vfio: platform: introduce module_vfio_reset_handler macro

aro.org> > Reviewed-by: Arnd Bergmann <a...@arndb.de> -- 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 v4 2/7] vfio: platform: add capability to register a reset function

gister_reset. Those are not yet used in > this patch. > > Signed-off-by: Eric Auger <eric.au...@linaro.org> > > Reviewed-by: Arnd Bergmann <a...@arndb.de> -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to major

Re: [PATCH v3] VFIO: platform: reset: AMD xgbe reset module

lear auto-negotiation IRQ > - soft-reset the MAC > > Those tiny pieces of code are inherited from the native xgbe driver. > > Signed-off-by: Eric Auger <eric.au...@linaro.org> > Reviewed-by: Arnd Bergmann <a...@arndb.de> -- To unsubscribe from this list: send the li

Re: [PATCH v3 1/7] vfio: platform: introduce vfio-platform-base module

tead. > > Signed-off-by: Eric Auger <eric.au...@linaro.org> > Suggested-by: Arnd Bergmann <a...@arndb.de> > > Reviewed-by: Arnd Bergmann <a...@arndb.de> -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...

Re: [PATCH v3 6/7] vfio: platform: use list of registered reset function

s possible to add a new reset module > without needing to update the framework. This was suggested by Arnd. > > Signed-off-by: Eric Auger <eric.au...@linaro.org> > Reported-by: Arnd Bergmann <a...@arndb.de> > > Reviewed-by: Arnd Bergmann <a...@arndb.de> but doesn't

Re: [PATCH v3 3/7] vfio: platform: introduce module_vfio_reset_handler macro

On Friday 23 October 2015 14:37:11 Eric Auger wrote: > +static int __init reset ## _module_init(void) \ > +{ \ > + vfio_platform_register_reset(compat, reset);\ > + return 0;

Re: [PATCH v3 2/7] vfio: platform: add capability to register a reset function

On Friday 23 October 2015 14:37:10 Eric Auger wrote: > + > +void vfio_platform_unregister_reset(const char *compat) > +{ > + struct vfio_platform_reset_node *iter, *temp; > + > + mutex_lock(_lock); > + list_for_each_entry_safe(iter, temp, _list, link) { > + if

Re: [PATCH v3 4/7] vfio: platform: reset: calxedaxgmac: add reset function registration

igned-off-by: Eric Auger <eric.au...@linaro.org> > > Reviewed-by: Arnd Bergmann <a...@arndb.de> -- 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] VFIO: platform: reset: AMD xgbe reset module

On Friday 23 October 2015 14:44:13 Eric Auger wrote: > This patch introduces a module that registers and implements a low-level > reset function for the AMD XGBE device. > > it performs the following actions: > - reset the PHY > - disable auto-negotiation > - disable & clear auto-negotiation IRQ

Re: [PATCH v3 6/7] vfio: platform: use list of registered reset function

On Friday 23 October 2015 16:11:08 Eric Auger wrote: > Hi Arnd, > On 10/23/2015 03:12 PM, Arnd Bergmann wrote: > > On Friday 23 October 2015 14:37:14 Eric Auger wrote: > >> Remove the static lookup table and use the dynamic list of registered > >> reset function

Re: [PATCH v2 6/6] vfio: platform: move get/put reset at open/release

On Thursday 22 October 2015 11:42:02 Eric Auger wrote: > Currently reset lookup is done on probe. This introduces a > race with new registration mechanism in the case where the > vfio-platform driver is bound to the device before its module > is loaded: on the load, the probe happens which

Re: [PATCH v2 6/6] vfio: platform: move get/put reset at open/release

On Thursday 22 October 2015 13:40:16 Eric Auger wrote: > On 10/22/2015 12:29 PM, Arnd Bergmann wrote: > > On Thursday 22 October 2015 11:42:02 Eric Auger wrote: > >> Currently reset lookup is done on probe. This introduces a > >> race with new registration mechanism in t

Re: [PATCH v2 3/6] vfio: platform: reset: calxedaxgmac: add reset function registration

On Thursday 22 October 2015 13:54:42 Eric Auger wrote: > On 10/22/2015 12:13 PM, Arnd Bergmann wrote: > > On Thursday 22 October 2015 11:41:59 Eric Auger wrote: > >> This patch adds the reset function registration/unregistration. > >> > >> Signed-off-b

Re: [PATCH v2 1/6] vfio: platform: add capability to register a reset function

On Thursday 22 October 2015 11:41:57 Eric Auger wrote: > In preparation for subsequent changes in reset function lookup, > lets introduce a dynamic list of reset combos (compat string, > reset module, reset function). The list can be populated/voided with > two new functions,

Re: [PATCH v2 2/6] vfio: platform: reset: add vfio_platform_reset_private.h

On Thursday 22 October 2015 11:41:58 Eric Auger wrote: > v2: creation > - this defines the module_vfio_reset_handler macro as suggested by Arnd > > Although Arnd suggested me to remove the vfio_platform_register_reset > symbol_get (since the module manager can handle the case where the >

Re: [PATCH v2 3/6] vfio: platform: reset: calxedaxgmac: add reset function registration

On Thursday 22 October 2015 11:41:59 Eric Auger wrote: > This patch adds the reset function registration/unregistration. > > Signed-off-by: Eric Auger Looks good, except one thing: > @@ -70,6 +69,8 @@ int vfio_platform_calxedaxgmac_reset(struct > vfio_platform_device

Re: [PATCH v2 5/6] vfio: platform: use list of registered reset function

s possible to add a new reset module > without needing to update the framework. This was suggested by Arnd. > > Signed-off-by: Eric Auger <eric.au...@linaro.org> > Reported-by: Arnd Bergmann <a...@arndb.de> Looks good, just small style issues: > > - }

Re: [PATCH v2 6/6] vfio: platform: move get/put reset at open/release

On Thursday 22 October 2015 15:26:55 Eric Auger wrote: > >> @@ -181,6 +182,8 @@ static int vfio_platform_open(void *device_data) > >> if (ret) > >> goto err_irq; > >> > >> + vfio_platform_get_reset(vdev); > >> + > >> if

Re: [GIT PULL 3/6] KVM: arm: use GIC support unconditionally

On Tuesday 20 October 2015 15:51:05 Paolo Bonzini wrote: > Should this be "select" or "depends on"? Not a blocker, can always be fixed > in 4.4. We have lots of 'select ARM_GIC' in the tree for platforms that use one, using 'depends on' will limit KVM support to being available only if at least

Re: [GIT PULL 3/6] KVM: arm: use GIC support unconditionally

On Wednesday 21 October 2015 15:58:44 Christoffer Dall wrote: > On Wed, Oct 21, 2015 at 03:45:20PM +0200, Arnd Bergmann wrote: > > On Tuesday 20 October 2015 15:51:05 Paolo Bonzini wrote: > > > Should this be "select" or "depends on"? Not a blocker, can alwa

Re: [PATCH 0/4] VFIO platform reset module rework

On Sunday 18 October 2015 18:00:11 Eric Auger wrote: > This series fixes the current implementation by getting rid of the > usage of __symbol_get which caused a compilation issue with > CONFIG_MODULES disabled. On top of this, the usage of MODULE_ALIAS makes > possible to add a new reset module

Re: [PATCH 1/4] vfio: platform: add capability to register a reset function

On Sunday 18 October 2015 18:00:12 Eric Auger wrote: > > +struct list_head reset_list; > +LIST_HEAD(reset_list); > These two should be marked 'static'. Arnd -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More

Re: [PATCH 2/4] vfio: platform: reset: calxedaxgmac: add reset function registration

On Sunday 18 October 2015 18:00:13 Eric Auger wrote: > diff --git a/drivers/vfio/platform/reset/vfio_platform_calxedaxgmac.c > b/drivers/vfio/platform/reset/vfio_platform_calxedaxgmac.c > index 619dc7d..4f76b17 100644 > --- a/drivers/vfio/platform/reset/vfio_platform_calxedaxgmac.c > +++

Re: [PATCH 2/4] vfio: platform: reset: calxedaxgmac: add reset function registration

On Monday 19 October 2015 15:17:30 Eric Auger wrote: > Hi Arnd, > On 10/19/2015 03:04 PM, Arnd Bergmann wrote: > > On Sunday 18 October 2015 18:00:13 Eric Auger wrote: > >> diff --git a/drivers/vfio/platform/reset/vfio_platform_calxedaxgmac.c > >>

Re: [PATCH] VFIO: platform: AMD xgbe reset module

On Friday 16 October 2015 15:06:45 Eric Auger wrote: > I've since forgotten his answer, but the fact that > > __symbol_get() is only defined for modules makes it moot, we either need > > to make symbol_get() work or define __symbol_get() for non-module > > builds. > I currently don't see any

Re: [PATCH] VFIO: platform: AMD xgbe reset module

On Thursday 15 October 2015 10:08:02 Eric Auger wrote: > Hi Arnd, > On 10/14/2015 05:38 PM, Arnd Bergmann wrote: > > On Wednesday 14 October 2015 15:33:12 Eric Auger wrote: > >> --- a/drivers/vfio/platform/vfio_platform_common.c > >> +++ b/drivers/vfio/platform/vfio_p

Re: [PATCH] VFIO: platform: AMD xgbe reset module

On Thursday 15 October 2015 17:03:21 Christoffer Dall wrote: > On Thu, Oct 15, 2015 at 04:55:13PM +0200, Arnd Bergmann wrote: > > On Thursday 15 October 2015 16:46:09 Eric Auger wrote: > > > > > > > > This is where we'd need a little more changes for this appro

Re: [PATCH] VFIO: platform: AMD xgbe reset module

On Thursday 15 October 2015 14:12:28 Christoffer Dall wrote: > > > > enum vfio_platform_op { > > VFIO_PLATFORM_BIND, > > VFIO_PLATFORM_UNBIND, > > VFIO_PLATFORM_RESET, > > }; > > > > struct platform_driver { > > int (*probe)(struct platform_device *); > > int

Re: [PATCH] VFIO: platform: AMD xgbe reset module

On Thursday 15 October 2015 16:46:09 Eric Auger wrote: > > > > This is where we'd need a little more changes for this approach. Instead > > of unbinding the device from its driver, the idea would be that the > > driver remains bound as far as the driver model is concerned, but > > it would be in

Re: [PATCH] VFIO: platform: AMD xgbe reset module

On Thursday 15 October 2015 16:20:46 Eric Auger wrote: > On 10/15/2015 02:12 PM, Christoffer Dall wrote: > > On Thu, Oct 15, 2015 at 01:21:55PM +0200, Arnd Bergmann wrote: > >> On Thursday 15 October 2015 10:08:02 Eric Auger wrote: > >>> On 10/14/2015

Re: [PATCH] VFIO: platform: AMD xgbe reset module

On Wednesday 14 October 2015 15:33:12 Eric Auger wrote: > --- a/drivers/vfio/platform/vfio_platform_common.c > +++ b/drivers/vfio/platform/vfio_platform_common.c > @@ -31,6 +31,11 @@ static const struct vfio_platform_reset_combo > reset_lookup_table[] = { > .reset_function_name =

Re: randconfig bug: ARM/KVM link error in hyp_idmap section

On Thursday 29 January 2015 16:23:42 Christoffer Dall wrote: On Wed, Jan 28, 2015 at 8:57 PM, Arnd Bergmann a...@arndb.de wrote: 8 Subject: [PATCH] ARM: KVM: avoid HYP init code too big error When building large kernels, the linker will emit lots of veneers into the .hyp.idmap.text

randconfig bug: ARM/KVM link error in hyp_idmap section

. This moves the section into .rodata instead, which avoids the veneers and is safe because the code is not executed directly but always copied into a separate page first. I am unsure if I wrote this the correct way though, so it needs to be reviewed carefully. Signed-off-by: Arnd Bergmann

Re: [PULL] uaccess: fix sparse warning on get/put_user for bitwise types

On Wednesday 14 January 2015 19:36:18 Michael S. Tsirkin wrote: As you asked, here's a pull request. This has been in linux-next apparently with no ill effects. The following changes since commit 99975cc6ada0d5f2675e83abecae05aba5f437d2: vhost/net: length miscalculation (2015-01-07

[PATCH] vfio/pci: make MSI handling optional

the existing behavior for compatibility reasons. Signed-off-by: Arnd Bergmann a...@arndb.de Fixes: b8f02af096b1 (vfio/pci: Restore MSIx message prior to enabling) --- Found using randconfig build testing on ARM. diff --git a/drivers/vfio/pci/vfio_pci_intrs.c b/drivers/vfio/pci/vfio_pci_intrs.c index

Re: [RFC v2] ARM VM System Specification

On Wednesday 11 June 2014 10:16:03 Paolo Bonzini wrote: If kernels actually do use the UEFI runtime services and have no need for direct access to an RTC when runing in a UEFI compliant system, then I agree with not specifying the hardware details. The RTC is not needed for ordinary

Re: [RFC v2] ARM VM System Specification

On Wednesday 11 June 2014 10:50:04 Stefano Stabellini wrote: Although not in the ARM VM System Specification, Xen is certainly going to support a fast boot path without UEFI firmware. I guess KVM will too. You'll have to rely on hypervisor specific mechanisms to achieve it. In fact I

Re: [RFC v2] ARM VM System Specification

On Wednesday 11 June 2014 12:33:30 Grant Likely wrote: On Tue, Jun 10, 2014 at 7:56 PM, Paolo Bonzini pbonz...@redhat.com wrote: Il 10/06/2014 20:08, Peter Maydell ha scritto: On 10 June 2014 18:04, Christopher Covington c...@codeaurora.org wrote: On 06/10/2014 10:42 AM, Peter Maydell

Re: [RFC v2] ARM VM System Specification

On Tuesday 10 June 2014 18:44:59 Claudio Fontana wrote: I just wanted to share with you guys how we are using virtualization on ARM64 over here for the OSv project. By skipping steps like UEFI, grub, firmware load, etc we strive to keep our application launch time low. Is this going to create

[PATCH] vfio: always select ANON_INODES

The vfio code cannot be built when CONFIG_ANON_INODES is disabled, so this enforces the symbol to be enabled through Kconfig. Signed-off-by: Arnd Bergmann a...@arndb.de diff --git a/drivers/vfio/Kconfig b/drivers/vfio/Kconfig index 26b3d9d..af7b204 100644 --- a/drivers/vfio/Kconfig +++ b/drivers

Re: [RFC] ARM VM System Sepcification

On Friday 28 February 2014 08:05:15 Alexander Graf wrote: Am 28.02.2014 um 03:56 schrieb Arnd Bergmann a...@arndb.de: On Thursday 27 February 2014 22:24:13 Alexander Graf wrote: When you have that, why do you still care about a system specification? Because I don't want to go back

Re: [RFC] ARM VM System Sepcification

On Thursday 27 February 2014 12:31:55 Stefano Stabellini wrote: On Wed, 26 Feb 2014, Leif Lindholm wrote: no FDT. In this case, the VM implementation must provide ACPI, and the OS must be able to locate the ACPI root pointer through the UEFI system table. For more

Re: [RFC] ARM VM System Sepcification

On Thursday 27 February 2014 22:24:13 Alexander Graf wrote: If you want to assign a platform device, you need to generate a respective hardware description (fdt/dsdt) chunk in the hypervisor. You can't take the host's description - it's too tightly coupled to the overall host layout. But at

Re: [RFC] ARM VM System Sepcification

On Wednesday 26 February 2014 10:34:54 Christoffer Dall wrote: ARM VM System Specification === Goal The goal of this spec is to allow suitably-built OS images to run on all ARM virtualization solutions, such as KVM or Xen. Recommendations in this spec are

Re: [RFC] ARM VM System Sepcification

On Wednesday 26 February 2014 12:05:37 Christoffer Dall wrote: On Wed, Feb 26, 2014 at 08:55:58PM +0100, Arnd Bergmann wrote: On Wednesday 26 February 2014 10:34:54 Christoffer Dall wrote: The most common response I've been getting so far is that people generally want their VMs to look

Re: [RFC] ARM VM System Sepcification

On Wednesday 26 February 2014, Christoffer Dall wrote: Personally I'm all for simplicity so I don't want to push any agenda for ACPI in VMs. Note that the spec does not mandate the use of ACPI, it just tells you how to do it if you wish to. But, we can change the spec to require full FDT

[PATCH] ARM: kvm: don't include drivers/virtio/Kconfig

(VIRTUALIZATION) Cc: Christoffer Dall cd...@cs.columbia.edu Signed-off-by: Arnd Bergmann a...@arndb.de diff --git a/arch/arm/kvm/Kconfig b/arch/arm/kvm/Kconfig index 370e1a8..017db7c 100644 --- a/arch/arm/kvm/Kconfig +++ b/arch/arm/kvm/Kconfig @@ -67,6 +67,4 @@ config KVM_ARM_TIMER ---help

Re: [PATCH v2 07/10] powerpc: uaccess s/might_sleep/might_fault/

On Friday 24 May 2013, Michael S. Tsirkin wrote: So this won't work, unless we add the is_kernel_addr check to might_fault. That will become possible on top of this patchset but let's consider this carefully, and make this a separate patchset, OK? Yes, makes sense. Arnd -- To

Re: [PATCH v2 00/10] uaccess: better might_sleep/might_fault behavior

On Thursday 16 May 2013, Michael S. Tsirkin wrote: This improves the might_fault annotations used by uaccess routines: 1. The only reason uaccess routines might sleep is if they fault. Make this explicit for all architectures. 2. Accesses (e.g through socket ops) to kernel memory

Re: [PATCH v2 07/10] powerpc: uaccess s/might_sleep/might_fault/

On Thursday 16 May 2013, Michael S. Tsirkin wrote: @@ -178,7 +178,7 @@ do { \ long __pu_err; \ __typeof__(*(ptr)) __user *__pu_addr = (ptr); \ if

Re: [PATCH v2 00/10] uaccess: better might_sleep/might_fault behavior

On Wednesday 22 May 2013, Russell King - ARM Linux wrote: On Wed, May 22, 2013 at 11:25:36AM +0200, Arnd Bergmann wrote: Given the most commonly used functions and a couple of architectures I'm familiar with, these are the ones that currently call might_fault() x86

[PATCH] vfio: include linux/slab.h for kmalloc

The vfio drivers call kmalloc or kzalloc, but do not include linux/slab.h, which causes build errors on ARM. Signed-off-by: Arnd Bergmann a...@arndb.de Cc: Alex Williamson alex.william...@redhat.com Cc: kvm@vger.kernel.org --- Please apply for 3.9 drivers/vfio/pci/vfio_pci_config.c | 1

Re: [PATCH 07/10] UAPI: Put a comment into uapi/asm-generic/kvm_para.h and use it from arches

Bergmann a...@arndb.de cc: Avi Kivity a...@redhat.com cc: Marcelo Tosatti mtosa...@redhat.com cc: kvm@vger.kernel.org Acked-by: Arnd Bergmann a...@arndb.de -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info

Re: [PATCH 1/4] drivers/net/ethernet/sfc: Add efx_ prefix to set_bit_le()

needed. Ah, I see. To be honest, I am a bit scared of changing drivers which I cannot test on real hardware. Ok, let's take your patches as they are then. With the change to add clear_bit_le: Acked-by: Arnd Bergmann a...@arndb.de -- To unsubscribe from this list: send the line unsubscribe

Re: [PATCH 1/4] drivers/net/ethernet/sfc: Add efx_ prefix to set_bit_le()

On Monday 11 June 2012, Takuya Yoshikawa wrote: /* Set bit in a little-endian bitfield */ -static inline void set_bit_le(unsigned nr, unsigned char *addr) +static inline void efx_set_bit_le(unsigned nr, unsigned char *addr) { addr[nr / 8] |= (1 (nr % 8)); } /* Clear bit in

Re: [PATCH 3/4] bitops: Introduce generic set_bit_le()

On Monday 11 June 2012, Takuya Yoshikawa wrote: From: Takuya Yoshikawa yoshikawa.tak...@oss.ntt.co.jp Needed to replace test_and_set_bit_le() in virt/kvm/kvm_main.c which is being used for this missing function. Signed-off-by: Takuya Yoshikawa yoshikawa.tak...@oss.ntt.co.jp Cc: Arnd

Re: [Qemu-devel] [RFC] Next gen kvm api

On Tuesday 07 February 2012, Alexander Graf wrote: On 07.02.2012, at 07:58, Michael Ellerman wrote: On Mon, 2012-02-06 at 13:46 -0600, Scott Wood wrote: You're exposing a large, complex kernel subsystem that does very low-level things with the hardware. It's a potential source of

Re: [Qemu-devel] [RFC] Next gen kvm api

On Tuesday 07 February 2012, Alexander Graf wrote: Not sure we'll ever get there. For PPC, it will probably take another 1-2 years until we get the 32-bit targets stabilized. By then we will have new 64-bit support though. And then the next gen will come out giving us even more new

Re: [Qemu-devel] [RFC] Next gen kvm api

On Tuesday 07 February 2012, Alexander Graf wrote: Not sure we'll ever get there. For PPC, it will probably take another 1-2 years until we get the 32-bit targets stabilized. By then we will have new 64-bit support though. And then the next gen will come out giving us even more new

Re: [PATCH 0/4 V7] Avoid soft lockup message when KVM is stopped by host

++ include/linux/kvm.h |2 ++ kernel/watchdog.c | 12 12 files changed, 107 insertions(+), 0 deletions(-) create mode 100644 include/asm-generic/kvm_para.h asm-generic changes Acked-by: Arnd Bergmann a...@arndb.de but please remove me

Re: [Android-virt] [Embeddedxen-devel] [Xen-devel] [ANNOUNCE] Xen port to Cortex-A15 / ARMv7 with virt extensions

On Thursday 01 December 2011, Catalin Marinas wrote: Given the way register banking is done on AArch64, issuing an HVC on a 32-bit guest OS doesn't require translation on a 64-bit hypervisor. We have a similar implementation at the SVC level (for 32-bit user apps on a 64-bit kernel), the only

Re: [Android-virt] [Embeddedxen-devel] [Xen-devel] [ANNOUNCE] Xen port to Cortex-A15 / ARMv7 with virt extensions

On Thursday 01 December 2011, Catalin Marinas wrote: On Thu, Dec 01, 2011 at 03:42:19PM +, Arnd Bergmann wrote: On Thursday 01 December 2011, Catalin Marinas wrote: How do you deal with signed integer arguments passed into SVC or HVC from a caller? If I understand the architecture

Re: [ANNOUNCE] Xen port to Cortex-A15 / ARMv7 with virt extensions

On Wednesday 30 November 2011, Stefano Stabellini wrote: On Tue, 29 Nov 2011, Arnd Bergmann wrote: On Tuesday 29 November 2011, Stefano Stabellini wrote: Do you have a pointer to the kernel sources for the Linux guest? We have very few changes to the Linux kernel at the moment (only 3

Re: [Xen-devel] [ANNOUNCE] Xen port to Cortex-A15 / ARMv7 with virt extensions

On Wednesday 30 November 2011, Ian Campbell wrote: On Wed, 2011-11-30 at 13:03 +, Arnd Bergmann wrote: On Wednesday 30 November 2011, Stefano Stabellini wrote: This is the same choice people have made for KVM, but it's not necessarily the best option in the long run. In particular

Re: [Xen-devel] [ANNOUNCE] Xen port to Cortex-A15 / ARMv7 with virt extensions

On Wednesday 30 November 2011, Ian Campbell wrote: On Wed, 2011-11-30 at 14:32 +, Arnd Bergmann wrote: On Wednesday 30 November 2011, Ian Campbell wrote: What I suggested to the KVM developers is to start out with the vexpress platform, but then generalize it to the point where it fits

Re: [ANNOUNCE] Xen port to Cortex-A15 / ARMv7 with virt extensions

On Tuesday 29 November 2011, Stefano Stabellini wrote: Hi all, a few weeks ago I (and a few others) started hacking on a proof-of-concept hypervisor port to Cortex-A15 which uses and requires ARMv7 virtualization extensions. The intention of this work was to find out how to best support ARM

Re: [PATCH resend] compat_ioctl: fix warning caused by qemu

on plain files. Signed-off-by: Johannes Stezenbach j...@sig21.net Acked-by: Arnd Bergmann a...@arndb.de --- (resend with Cc: suggested by get_maintainer.pl) discussed in http://lkml.kernel.org/r/20110617090424.ga19...@sig21.net Arnd, is this what you had in mind, or did you mean to move

Re: missing compat-ioctl for CDROM_DRIVE_STATUS + FDGETPRM

On Wednesday 29 June 2011, Johannes Stezenbach wrote: Sorry for very slow reply. I think qemu's use of these ioctls to probe if the device is a cdrom or floppy is valid, so instead of adding a stat() call to check for block device in qemu, I think it is better to silence the warning in the

Re: missing compat-ioctl for CDROM_DRIVE_STATUS + FDGETPRM

On Wednesday 29 June 2011, Johannes Stezenbach wrote: On Wed, Jun 29, 2011 at 02:51:17PM +0200, Johannes Stezenbach wrote: On Wed, Jun 29, 2011 at 02:30:42PM +0200, Arnd Bergmann wrote: On Wednesday 29 June 2011, Johannes Stezenbach wrote: Do I get it right that just adding two

Re: missing compat-ioctl for CDROM_DRIVE_STATUS + FDGETPRM

On Friday 17 June 2011 11:04:24 Johannes Stezenbach wrote: running even a simple qemu-img create -f qcow2 some.img 1G causes the following in dmesg on a Linux host with linux-2.6.39.1 x86_64 kernel and 32bit userspace: ioctl32(qemu-img:5296): Unknown cmd fd(3) cmd(5326){t:'S';sz:0}

Re: [PATCH] KVM: Add compat ioctl for KVM_SET_SIGNAL_MASK

On Tuesday 07 June 2011 22:25:15 Alexander Graf wrote: +static long kvm_vcpu_compat_ioctl(struct file *filp, + unsigned int ioctl, unsigned long arg) +{ + struct kvm_vcpu *vcpu = filp-private_data; + void __user *argp = (void __user *)arg;

Re: [PATCH] KVM: Add compat ioctl for KVM_SET_SIGNAL_MASK

On Tuesday 07 June 2011 22:25:15 Alexander Graf wrote: +static long kvm_vcpu_compat_ioctl(struct file *filp, + unsigned int ioctl, unsigned long arg) +{ + struct kvm_vcpu *vcpu = filp-private_data; + void __user *argp = (void __user *)arg;

Re: [RFC][PATCH] Import Linux headers for KVM and vhost

On Tuesday 03 May 2011, Jan Kiszka wrote: This helps reducing our build-time checks for feature support in the available Linux kernel headers. And it helps users that do not have sufficiently recent headers installed on their build machine. Header upstate is triggered via 'make

Re: [Qemu-devel] [PATCH v2] Import Linux headers for KVM and vhost

On Tuesday 03 May 2011 19:57:18 Scott Wood wrote: I agree, it doesn't feel quite right to bring in the headers. I don't have any alternative suggestions (besides better HOWTOs/Documentation) though. If you try to use the non-sanitized kernel headers, you'll get this warning from

Re: Does macvtap support host to guest communication?

On Tuesday 19 April 2011, Ashish Saxena wrote: @Arnd, I would like to initiate the dig into into macvtap driver. Could you please provide me some pointers/docs to start with. I dont' have any general recommendations. I'd suggest you start reading the macvlan.c and macvtap.c source code and

Re: Does macvtap support host to guest communication?

On Monday 18 April 2011, Asias He wrote: If you want a regular device to be able to send to a macvlan port, that would require at least these changes: * Add an option to put a plain device into macvlan-bridge mode * Add support for that option into iproute2 * Add a hook into

Re: Does macvtap support host to guest communication?

On Monday 18 April 2011, Asias He wrote: Hi, folks I am trying to use qemu/qemu-kvm with macvtap using following commands: # ip link add link eth0 name v0 type macvtap mode {vepa,bridge,private} # ip link set v0 address da:4e:17:88:42:b1 up # idx=`ip link show v0 | grep mtu| awk -F:

Re: Does macvtap support host to guest communication?

On Monday 18 April 2011, Asias He wrote: (1) Is it possible to add an interface to macvtap like /dev/net/tun, eg, /dev/net/macvtap. Currently, it is hard to use macvtap programmatically. I decided against having a multiplexor device because it makes permission handling rather hard. One chardev

Re: Does macvtap support host to guest communication?

On Monday 18 April 2011, Ingo Molnar wrote: Only in VEPA mode. Note that a similar restriction applies when using the bridge device, for the same technical reasons. Just to sum things up, our goal is to allow the tools/kvm/ unprivileged tool to provide TCP connectivity to Linux guests

Re: Does macvtap support host to guest communication?

On Monday 18 April 2011, Asias He wrote: We do need guest appearing on the same network as the host support as well. The reason I am considering using macvatp instead of tap plus brctl is that it simplifies the bridge configuration and it is more efficient. Right, you certainly don't need to

Re: [PATCH iproute2] Support 'mode' parameter when creating macvtap device

On Friday 29 October 2010, Sridhar Samudrala wrote: Add support for 'mode' parameter when creating a macvtap device. This allows a macvtap device to be created in bridge, private or the default vepa modes. Signed-off-by: Sridhar Samudrala s...@us.ibm.com Acked-by: Arnd Bergmann

Re: [PATCH] macvlan: Introduce 'passthru' mode to takeover the underlying device

On Friday 29 October 2010, Sridhar Samudrala wrote: With the current default 'vepa' mode, a KVM guest using virtio with macvtap backend has the following limitations. - cannot change/add a mac address on the guest virtio-net I believe this could be changed if there is a neeed, but I actually

Re: [PATCH iproute2] Add passthru mode and support 'mode' parameter with macvtap devices

On Wednesday 27 October 2010, Sridhar Samudrala wrote: Support a new 'passthru' mode with macvlan and 'mode' parameter with macvtap devices. Signed-off-by: Sridhar Samudrala s...@us.ibm.com Can you split this into two patches? We definitely want the part adding support for macvtap device

Re: [RFC PATCH] macvlan: Introduce a PASSTHRU mode to takeover the underlying device

On Wednesday 27 October 2010, Sridhar Samudrala wrote: With the current default macvtap mode, a KVM guest using virtio with macvtap backend has the following limitations. - cannot change/add a mac address on the guest virtio-net - cannot create a vlan device on the guest virtio-net - cannot

Re: [PATCH v2 02/22] bitops: rename generic little-endian bitops functions

...@oracle.com Cc: rds-de...@oss.oracle.com Cc: David S. Miller da...@davemloft.net Cc: net...@vger.kernel.org Cc: Avi Kivity a...@redhat.com Cc: Marcelo Tosatti mtosa...@redhat.com Cc: kvm@vger.kernel.org Acked-by: Arnd Bergmann a...@arndb.de -- To unsubscribe from this list: send the line

Re: TODO item: guest programmable mac/vlan filtering with macvtap

On Friday 15 October 2010, Michael S. Tsirkin wrote: On Thu, Oct 14, 2010 at 11:40:52PM +0200, Dragos Tatulea wrote: Hi, I'm starting a thread related to the TODO item mentioned in the subject. Currently still gathering info and trying to make kvm macvtap play nicely together. I

Re: [PATCH v2] pc: e820 qemu_cfg tables need to be packed

On Friday 15 October 2010, Alex Williamson wrote: We can't let the compiler define the alignment for qemu_cfg data. Signed-off-by: Alex Williamson alex.william...@redhat.com --- v2: Adjust alignment to help non-x86 hosts per Arnd's suggestion Ok, looks good now. Thanks! Arnd --

Re: [Qemu-devel] Re: [PATCH] pc: e820 qemu_cfg tables need to be packed

On Thursday 14 October 2010 21:58:08 Alex Williamson wrote: If it works anywhere (I assume it works on 32bit), then it's only because it happened to get the alignment right. This just makes 64bit hosts get it right too. I don't see any compatibility issues, non-packed + 64bit = broken.

Re: [Qemu-devel] Re: [PATCH] pc: e820 qemu_cfg tables need to be packed

On Thursday 14 October 2010 22:59:04 Alex Williamson wrote: The structs in question only contain 4 8 byte elements, so there shouldn't be any change on x86-32 using one-byte aligned packing. I'm talking about the alignment of the structure, not the members within the structure. The data

Re: [v2 RFC PATCH 0/4] Implement multiqueue virtio-net

On Tuesday 05 October 2010, Krishna Kumar2 wrote: After testing various combinations of #txqs, #vhosts, #netperf sessions, I think the drop for 1 stream is due to TX and RX for a flow being processed on different cpus. I did two more tests: 1. Pin vhosts to same CPU: - BW drop is

Re: [v2 RFC PATCH 0/4] Implement multiqueue virtio-net

On Wednesday 06 October 2010 19:14:42 Krishna Kumar2 wrote: Arnd Bergmann a...@arndb.de wrote on 10/06/2010 05:49:00 PM: I don't see any reasons mentioned above. However, for higher number of netperf sessions, I see a big increase in retransmissions

Re: [PATCH v11 13/17] Add mp(mediate passthru) device.

On Tuesday 28 September 2010, Michael S. Tsirkin wrote: + skb_reserve(skb, NET_IP_ALIGN); + skb_put(skb, len); + + if (skb_copy_datagram_from_iovec(skb, 0, iov, 0, len)) { + kfree_skb(skb); + return -EAGAIN; + } + + skb-protocol =

Re: [PATCH v11 13/17] Add mp(mediate passthru) device.

On Tuesday 28 September 2010, Michael S. Tsirkin wrote: On Tue, Sep 28, 2010 at 04:39:59PM +0200, Arnd Bergmann wrote: Can you be more specific what the problem is? Do you think it breaks when a guest sends VLAN tagged frames or when macvtap is connected to a VLAN interface that adds

Re: [RFC PATCH 2/2] macvtap: TX zero copy between guest and host kernel

On Tuesday 14 September 2010, Shirley Ma wrote: On Tue, 2010-09-14 at 11:12 +0200, Avi Kivity wrote: That's what io_submit() is for. Then io_getevents() tells you what a while actually was. This macvtap zero copy uses iov buffers from vhost ring, which is allocated from guest kernel.

Re: [RFC PATCH 0/4] Implement multiqueue virtio-net

On Wednesday 08 September 2010, Krishna Kumar2 wrote: On Wednesday 08 September 2010, Krishna Kumar2 wrote: The new guest and qemu code work with old vhost-net, just with reduced performance, yes? Yes, I have tested new guest/qemu with old vhost but using #numtxqs=1 (or not

Re: [RFC PATCH 0/4] Implement multiqueue virtio-net

On Wednesday 08 September 2010, Krishna Kumar2 wrote: The new guest and qemu code work with old vhost-net, just with reduced performance, yes? Yes, I have tested new guest/qemu with old vhost but using #numtxqs=1 (or not passing any arguments at all to qemu to enable MQ). Giving numtxqs

  1   2   3   >