Re: [PATCHv3 2/2] vhost_net: a kernel-level virtio server

On Sunday 16 August 2009, Michael S. Tsirkin wrote: On Fri, Aug 14, 2009 at 01:40:36PM +0200, Arnd Bergmann wrote: * most of the transports are sockets, tap uses a character device. This could be dealt with by having both a struct socket * in struct vhost_net *and* a struct file

Re: [PATCHv3 2/2] vhost_net: a kernel-level virtio server

On Wednesday 19 August 2009, Michael S. Tsirkin wrote: Maybe we could instead extend the 'splice' system call to work on a vhost_net file descriptor. If we do that, we can put the access back into a user thread (or two) that stays in splice indefinetely An issue with exposing internal

Re: [PATCHv3 2/2] vhost_net: a kernel-level virtio server

On Wednesday 19 August 2009, Michael S. Tsirkin wrote: On Wed, Aug 19, 2009 at 03:46:44PM +0200, Arnd Bergmann wrote: On Wednesday 19 August 2009, Michael S. Tsirkin wrote: Leaving that aside for now, you could replace VHOST_NET_SET_SOCKET, VHOST_SET_OWNER, VHOST_RESET_OWNER SET/RESET

Re: [PATCHv3 2/2] vhost_net: a kernel-level virtio server

On Thursday 20 August 2009, Michael S. Tsirkin wrote: On Wed, Aug 19, 2009 at 05:27:07PM +0200, Arnd Bergmann wrote: On Wednesday 19 August 2009, Michael S. Tsirkin wrote: On Wed, Aug 19, 2009 at 03:46:44PM +0200, Arnd Bergmann wrote: On Wednesday 19 August 2009, Michael S. Tsirkin wrote

Re: [PATCHv3 2/2] vhost_net: a kernel-level virtio server

On Thursday 20 August 2009, Michael S. Tsirkin wrote: On Thu, Aug 20, 2009 at 03:10:54PM +0200, Arnd Bergmann wrote: On Thursday 20 August 2009, Michael S. Tsirkin wrote: It doesn't matter that I don't want this: allowing 1 process corrupt another's memory is a security issue. Once you get

Re: [PATCHv3 2/2] vhost_net: a kernel-level virtio server

On Thursday 20 August 2009, Michael S. Tsirkin wrote: The errors from the socket (or chardev, as that was the start of the argument) should still fit into the categories that I mentioned, either they can be handled by the host kernel, or they are fatal. Hmm, are you sure? Imagine a

Re: [PATCHv3 3/4] qemu-kvm: vhost-net implementation

On Thursday 20 August 2009, Mark McLoughlin wrote: - I had expected this to be available as: -net raw,ifname=eth2 -net nic,model=virtio I'd prefer it this way, because it means you can use this mode even without vhost and it's ties in better with the way all other qemu

Re: vhost net: performance with ping benchmark

On Tuesday 25 August 2009, Avi Kivity wrote: On 08/25/2009 05:22 AM, Anthony Liguori wrote: I think 2.6.32 is pushing it. 2.6.32 is pushing it, but we need to push it. Agreed. I think some time is needed to flush out the userspace interface. In particular, I don't think Mark's

Re: [PATCHv4 2/2] vhost_net: a kernel-level virtio server

On Tuesday 25 August 2009, Michael S. Tsirkin wrote: I'd like to avoid that here, though it's kind of ugly. We'd need VHOST_GET_FEATURES (and ACK) to take a struct like: u32 feature_size; u32 features[]; Hmm, variable length ioctl arguments, I'd rather not go there. The

Re: [PATCHv5 3/3] vhost_net: a kernel-level virtio server

On Monday 31 August 2009, Xin, Xiaohui wrote: Hi, Michael That's a great job. We are now working on support VMDq on KVM, and since the VMDq hardware presents L2 sorting based on MAC addresses and VLAN tags, our target is to implement a zero copy solution using VMDq. I'm also interested

Re: [RFC] Bring in all the Linux headers we depend on in QEMU

On Sunday 03 May 2009, Anthony Liguori wrote: A classic example is linux/compiler.h and the broken usbdevice_fs.h header that depends on it. There are still distributions today that QEMU doesn't compile on because of this. Can you clarify this? I can't find any version of usbdevice_fs.h that

Re: [RFC] Bring in all the Linux headers we depend on in QEMU

On Monday 04 May 2009, Mark McLoughlin wrote: Right, but if you e.g. try to build a newer qemu-kvm on F10, you currently need newer kvm kernel headers - IMHO, we should use #ifdef to allow newer qemu-kvm build with older kvm headers. I think the kvm and virtio headers should just be shipped

Re: [RFC PATCH 1/3] add generic hypercall support

On Wednesday 06 May 2009, Gregory Haskins wrote: Ok, so we would need to come up with these pio_calls for x86, and no other arch can use the infrastructure (but wait, PPC can use PCI too, so how does that work? It must be either MMIO emulation or its not supported? That puts us back to

Re: [RFC PATCH 0/3] generic hypercall support

On Thursday 07 May 2009, Gregory Haskins wrote: I guess technically mmio can just be a simple access of the page which would be problematic to trap locally without a PF.  However it seems that most mmio always passes through a ioread()/iowrite() call so this is perhaps the hook point.  If we

Re: [RFC PATCH 0/3] generic hypercall support

On Thursday 07 May 2009, Gregory Haskins wrote: Arnd Bergmann wrote: An mmio that goes through a PF is a bug, it's certainly broken on a number of platforms, so performance should not be an issue there. This may be my own ignorance, but I thought a VMEXIT of type PF was how MMIO

Re: [RFC PATCH 0/3] generic hypercall support

On Thursday 07 May 2009, Arnd Bergmann wrote: An easy way to deal with the pass-through case might be to actually use __raw_writel there. In guest-to-guest communication, the two sides are known to have the same endianess (I assume) and you can still add the appropriate smp_mb

Re: [RFC PATCH 0/3] generic hypercall support

On Thursday 07 May 2009, Gregory Haskins wrote: What I am not clear on is how you would know to flag the address to begin with. pci_iomap could look at the bus device that the PCI function sits on. If it detects a PCI bridge that has a certain property (config space setting, vendor/device ID,

Re: [RFC PATCH 0/3] generic hypercall support

On Thursday 07 May 2009, Chris Wright wrote: Chris, is that issue with the non ioread/iowrite access of a mangled pointer still an issue here?  I would think so, but I am a bit fuzzy on whether there is still an issue of non-wrapped MMIO ever occuring. Arnd was saying it's a bug for

Re: [RFC PATCH 0/3] generic hypercall support

On Saturday 09 May 2009, Benjamin Herrenschmidt wrote: This was shot down by a vast majority of people, with the outcome being an agreement that for IORESOURCE_MEM, pci_iomap and friends must return something that is strictly interchangeable with what ioremap would have returned. That means

Re: [PATCH] kvm: user: include arch specific headers from $(KERNELDIR)

On Wednesday 13 May 2009 08:32:21 Mark McLoughlin wrote: Currently we only include $(KERNELDIR)/include in CFLAGS, but we also have $(KERNELDIR)/arch/$(arch)/include or else we'll get mis-matched headers. I think this is fundamentally wrong. User files should never directly access kernel

Re: [PATCH] kvm: user: include arch specific headers from $(KERNELDIR)

-by: Arnd Bergmann a...@arndb.de diff --git a/kvm/user/configure b/kvm/user/configure index efb8705..858a519 100755 --- a/kvm/user/configure +++ b/kvm/user/configure @@ -1,7 +1,7 @@ #!/bin/bash prefix=/usr/local -kerneldir=/lib/modules/$(uname -r)/build +kerneldir=$(dirname $0)/../kernel cc=gcc

Re: [PATCH] kvm: user: include arch specific headers from $(KERNELDIR)

On Thursday 14 May 2009, Avi Kivity wrote: I usually add a readlink -f in there due to my innate fear of relative directories and cd. There is one already in the only place where this gets used: KERNELDIR=$(readlink -f $kerneldir) It also gets shown in the configure --help output, but I

Re: Network throughput limits for local VM - VM communication

On Tuesday 09 June 2009, Fischer, Anna wrote: I have tried using virtio and using the emulated QEMU virtual NICs. It does not make a difference. It seems as if there is an overflow somewhere when QEMU/virtio cannot cope with the network load any more, and then the virtual interfaces don't

Re: Network throughput limits for local VM - VM communication

On Wednesday 10 June 2009, Fischer, Anna wrote: Have you tried eliminating VLAN to simplify the setup? No - but there is a relating bug in the tun/tap interface (well, it is not really a bug but simply the way tun/tap works) that will cause packets to be replicated on all the tap interfaces

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: [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 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: [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: [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: [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: [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: 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: [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: [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: 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: 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

[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 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

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

[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: [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

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 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

[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 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

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

[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: [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

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: 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

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: [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: [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 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: [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 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 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] 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: [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 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 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

[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 4/4] kvmppc: convert wrteei to wrtee as kvm guest optimization

On Tuesday 19 August 2008, [EMAIL PROTECTED] wrote: Dependent on the already existing CONFIG_KVM_GUEST config option this patch changes wrteei to wrtee allowing the hypervisor to rewrite those to nontrapping instructions. Maybe we should split the kvm guest otpimizations in two parts one for

<    1   2   3   >