[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <EA929A9653AAE14F841771FB1DE5A1365FA6BFA040@rrsmsx501.amr.corp.intel.com>
Date: Mon, 30 Nov 2009 11:36:08 -0700
From: "Williams, Mitch A" <mitch.a.williams@...el.com>
To: Simon Horman <horms@...ge.net.au>
CC: Ben Hutchings <bhutchings@...arflare.com>,
"Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>,
"davem@...emloft.net" <davem@...emloft.net>,
"shemminger@...tta.com" <shemminger@...tta.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"gospo@...hat.com" <gospo@...hat.com>
Subject: RE: [RFC PATCH 1/4] net: Add support to netdev ops for changing
hardware queue MAC and VLAN filters
>From: Simon Horman [mailto:horms@...ge.net.au]
>Sent: Sunday, November 29, 2009 10:03 PM
>> The issue of which VF goes with which PF device can be deduced in
>> userspace via sysfs.
>
>Does this mean that the configuration of filtering for a VF needs
>to be done where the interface for the VF exists - e.g. in a KVM
>guest/Xen domU?
>
No, all of the configuration is done through the PF device. What I was saying was that, given a specific VF PCI device (which would be passed through to the VM), you can use sysfs to determine which PF owns it, and then run the ip command to tell the PF to configure the VF.
>In terms of dealing with interfaces and the way that tools such as ip work
>that makes a lot of sense. But I wonder if it actually makes more sense
>from an administrative point of view to have this configuration go through
>the PF - e.g. the KVM host/Xen domO.
>From a policy and security standpoint, you can't allow the VM to handle its own hardware configuration. The host/hypervisor/VM Manager/boss has to handle this or you lose many of the advantages of virtualization (i.e. isolation, security, stability, etc).
-Mitch
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists