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-o
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
> > > some
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 '
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
> > -paranoi
gister_reset. Those are not yet used in
> this patch.
>
> Signed-off-by: Eric Auger
>
>
Reviewed-by: Arnd Bergmann
--
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
On Friday 23 October 2015 17:47:21 Eric Auger wrote:
> The module_vfio_reset_handler macro
> - define a module alias
> - implement module init/exit function which respectively registers
> and unregisters the reset function.
>
> Signed-off-by: Eric Auger
>
Reviewed-by:
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
>
Reviewed-by: Arnd Bergmann
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a mes
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
s possible to add a new reset module
> without needing to update the framework. This was suggested by Arnd.
>
> Signed-off-by: Eric Auger
> Reported-by: Arnd Bergmann
>
>
Reviewed-by: Arnd Bergmann
but doesn't this need to come before patch 4/7?
Arnd
--
To unsubscribe
igned-off-by: Eric Auger
>
>
Reviewed-by: Arnd Bergmann
--
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
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;
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(&driver_lock);
> + list_for_each_entry_safe(iter, temp, &reset_list, link) {
> +
e instead.
>
> Signed-off-by: Eric Auger
> Suggested-by: Arnd Bergmann
>
>
Reviewed-by: Arnd Bergmann
--
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
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
>
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 (vdev->
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-by: Eric Au
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
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 triggers
s possible to add a new reset module
> without needing to update the framework. This was suggested by Arnd.
>
> Signed-off-by: Eric Auger
> Reported-by: Arnd Bergmann
Looks good, just small style issues:
>
> - }
> + mutex_lock(&res
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 *vdev)
>
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
> vfio-plat
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, vfio_platform_register
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
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 o
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
> >>
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 major
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 wit
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
> +++ b/drivers
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 solu
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
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 a
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 05:38 PM,
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 (*r
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
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 = "
On Thursday 29 January 2015 16:23:42 Christoffer Dall wrote:
> On Wed, Jan 28, 2015 at 8:57 PM, Arnd Bergmann wrote:
>
> > 8<
> > Subject: [PATCH] ARM: KVM: avoid "HYP init code too big" error
> >
> > When building large kernels, the li
page, and that triggers the build error.
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 careful
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
On Monday 13 October 2014 02:50:08 Alex Williamson wrote:
>
> Why wouldn't we handle this with stubs for `get_cached_msi_msg' and
> `write_msi_msg'? We're really not talking about much code that might
> get removed by the compiler with this static branch and and it seems
> like a rather non-stand
nt to preserve the
existing behavior for compatibility reasons.
Signed-off-by: Arnd Bergmann
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_pc
On Wednesday 11 June 2014 12:33:30 Grant Likely wrote:
> On Tue, Jun 10, 2014 at 7:56 PM, Paolo Bonzini wrote:
> > Il 10/06/2014 20:08, Peter Maydell ha scritto:
> >
> >> On 10 June 2014 18:04, Christopher Covington wrote:
> >>>
> >>> On 06/10/2014 10:42 AM, Peter Maydell wrote:
>
> I j
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 wou
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 ordi
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 cr
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
diff --git a/drivers/vfio/Kconfig b/drivers/vfio/Kconfig
index 26b3d9d..af7b204 100644
--- a/drivers/vfio/Kconfig
+++ b/drivers/vfio/Kconfig
On Friday 28 February 2014 08:05:15 Alexander Graf wrote:
> > Am 28.02.2014 um 03:56 schrieb Arnd Bergmann :
> >> On Thursday 27 February 2014 22:24:13 Alexander Graf wrote:
>
> > When you have that, why do you still care about a
> > system specification?
>
>
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
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.
> > > >
>
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 ful
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
> gene
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 spe
ch has unmet direct dependencies (VIRTUALIZATION)
Cc: Christoffer Dall
Signed-off-by: Arnd Bergmann
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--
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 unsu
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 curren
On Thursday 16 May 2013, Michael S. Tsirkin wrote:
> @@ -178,7 +178,7 @@ do {
> \
> long __pu_err; \
> __typeof__(*(ptr)) __user *__pu_addr = (ptr); \
> if (!is
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 memo
The vfio drivers call kmalloc or kzalloc, but do not
include , which causes build errors on
ARM.
Signed-off-by: Arnd Bergmann
Cc: Alex Williamson
Cc: kvm@vger.kernel.org
---
Please apply for 3.9
drivers/vfio/pci/vfio_pci_config.c | 1 +
drivers/vfio/pci/vfio_pci_intrs.c | 1 +
2 files
use the generic instead.
>
> Should this perhaps instead be a #warning or #error that the facility is
> unsupported on this arch?
Just an empty file is fine by me, but an #error also sounds reasonable if
we want users to be able to write autoconf tests for it.
> Signed-off-by: David H
long word alignment and does endian conversion
> when 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
--
To unsub
On Monday 11 June 2012, Takuya Yoshikawa wrote:
> From: Takuya Yoshikawa
>
> 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
> Cc: Arnd Bergmann
I would recommend add
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));
> }
>
> /* Cl
ere,
where one version should be enough.
Both versions look fine to me though, so if you remove one of them:
Acked-by: Arnd Bergmann
--
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
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
>
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 o
generic/kvm_para.h | 14 ++
> 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 Acke
On Thursday 01 December 2011, Catalin Marinas wrote:
> On Thu, Dec 01, 2011 at 03:42:19PM +0000, 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
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 on
On Wednesday 30 November 2011, Ian Campbell wrote:
> On Wed, 2011-11-30 at 14:32 +0000, 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
On Wednesday 30 November 2011, Ian Campbell wrote:
> On Wed, 2011-11-30 at 13:03 +0000, 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
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
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 A
these
> ioctls only applies to block devices, while qemu also uses the ioctls on
> plain files.
>
> Signed-off-by: Johannes Stezenbach
Acked-by: Arnd Bergmann
> ---
> (resend with Cc: suggested by get_maintainer.pl)
>
> discussed in http://lkml.kernel.org/r/20110617090
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
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
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}
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;
Con
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 lin
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 update-li
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
co
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 hoo
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 nee
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
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
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
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 actuall
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
Acked-by: Arnd Ber
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
> - can
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
Can you split this into two patches?
We definitely want the part adding support for macvtap device mode
setting n
net...@vger.kernel.org
> Cc: Avi Kivity
> Cc: Marcelo Tosatti
> Cc: kvm@vger.kernel.org
Acked-by: Arnd Bergmann
--
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
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 t
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
> ---
>
> v2: Adjust alignment to help non-x86 hosts per Arnd's suggestion
Ok, looks good now. Thanks!
Arnd
--
To unsubscribe from t
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 stru
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. T
On Wednesday 06 October 2010 19:14:42 Krishna Kumar2 wrote:
> Arnd Bergmann 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 bi
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 dro
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 VLA
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;
> > > + }
> > > +
> > > +
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 g
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
> > > #nu
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 nu
1 - 100 of 207 matches
Mail list logo
