Re: [libvirt] [PATCH 3/4] virnetdevvportprofile: Changes to support portprofiles for hostdevs

2012-03-05 Thread Laine Stump 
I encountered two conflicts when I rebased this patch to upstream. Noted
in the comments.

On 03/04/2012 10:15 PM, Roopa Prabhu wrote:
 From: Roopa Prabhu ropra...@cisco.com

 This patch includes the following changes
 - removes some netlink functions which are now available in virnetdev.c
 - Adds a vf argument to all port profile functions

 For 802.1Qbh devices, the port profile calls can use a vf argument if
 passed by the caller. If the vf argument is -1 it will try to derive the vf
 if the device passed is a virtual function.

 For 802.1Qbg devices, This patch introduces a null check for the device
 argument because during port profile assignment on a hostdev, this argument
 can be null. Stefan CC'ed for comments

 Signed-off-by: Roopa Prabhu ropra...@cisco.com
 ---
  src/qemu/qemu_migration.c|2 
  src/util/virnetdevmacvlan.c  |6 +
  src/util/virnetdevvportprofile.c |  203 
 +-
  src/util/virnetdevvportprofile.h |8 +
  4 files changed, 42 insertions(+), 177 deletions(-)


 diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c
 index 7df2d4f..b80ed69 100644
 --- a/src/qemu/qemu_migration.c
 +++ b/src/qemu/qemu_migration.c
 @@ -2605,6 +2605,7 @@ qemuMigrationVPAssociatePortProfiles(virDomainDefPtr 
 def) {
 
 virDomainNetGetActualVirtPortProfile(net),
 net-mac,
 
 virDomainNetGetActualDirectDev(net),
 +   -1,
 def-uuid,
 
 VIR_NETDEV_VPORT_PROFILE_OP_MIGRATE_IN_FINISH)  0)
  goto err_exit;
 @@ -2622,6 +2623,7 @@ err_exit:
 
 virDomainNetGetActualVirtPortProfile(net),
 net-mac,
 
 virDomainNetGetActualDirectDev(net),
 +   -1,
 
 VIR_NETDEV_VPORT_PROFILE_OP_MIGRATE_IN_FINISH));
  }
  }
 diff --git a/src/util/virnetdevmacvlan.c b/src/util/virnetdevmacvlan.c
 index 25d0846..498a2a0 100644
 --- a/src/util/virnetdevmacvlan.c
 +++ b/src/util/virnetdevmacvlan.c
 @@ -486,6 +486,7 @@ int virNetDevMacVLanCreateWithVPortProfile(const char 
 *tgifname,
  uint32_t macvtapMode;
  const char *cr_ifname;
  int ret;
 +int vf = -1;
  
  macvtapMode = modeMap[mode];
  
 @@ -547,6 +548,7 @@ create_name:
 virtPortProfile,
 macaddress,
 linkdev,
 +   vf,
 vmuuid, vmOp)  0) {
  rc = -1;
  goto link_del_exit;
 @@ -597,6 +599,7 @@ disassociate_exit:
 virtPortProfile,
 macaddress,
 linkdev,
 +   vf,
 vmOp));
  
  link_del_exit:
 @@ -624,6 +627,8 @@ int virNetDevMacVLanDeleteWithVPortProfile(const char 
 *ifname,
 char *stateDir)
  {
  int ret = 0;
 +int vf = -1;
 +
  if (mode == VIR_NETDEV_MACVLAN_MODE_PASSTHRU) {
  ignore_value(virNetDevRestoreMacAddress(linkdev, stateDir));
  }
 @@ -633,6 +638,7 @@ int virNetDevMacVLanDeleteWithVPortProfile(const char 
 *ifname,
virtPortProfile,
macaddr,
linkdev,
 +  vf,

 VIR_NETDEV_VPORT_PROFILE_OP_DESTROY)  0)
  ret = -1;
  if (virNetDevMacVLanDelete(ifname)  0)
 diff --git a/src/util/virnetdevvportprofile.c 
 b/src/util/virnetdevvportprofile.c
 index 67fd7bc..8d9e906 100644
 --- a/src/util/virnetdevvportprofile.c
 +++ b/src/util/virnetdevvportprofile.c
 @@ -126,11 +126,6 @@ static struct nla_policy ifla_port_policy[IFLA_PORT_MAX 
 + 1] =
  {
[IFLA_PORT_RESPONSE]  = { .type = NLA_U16 },
  };
 -static struct nla_policy ifla_policy[IFLA_MAX + 1] =
 -{
 -  [IFLA_VF_PORTS] = { .type = NLA_NESTED },
 -};
 -
  
  static uint32_t
  virNetDevVPortProfileGetLldpadPid(void) {
 @@ -164,126 +159,6 @@ virNetDevVPortProfileGetLldpadPid(void) {
  return pid;
  }
  
 -
 -/**
 - * virNetDevVPortProfileLinkDump:
 - *
 - * @ifname: The name of the interface; only use if ifindex  0
 - * @ifindex: The interface index; may be  0 if

Re: [libvirt] [PATCH 3/4] virnetdevvportprofile: Changes to support portprofiles for hostdevs

2012-03-05 Thread Roopa Prabhu 



On 3/5/12 11:16 AM, Laine Stump la...@laine.org wrote:

 I encountered two conflicts when I rebased this patch to upstream. Noted
 in the comments.
 
 On 03/04/2012 10:15 PM, Roopa Prabhu wrote:
 From: Roopa Prabhu ropra...@cisco.com
 
 This patch includes the following changes
 - removes some netlink functions which are now available in virnetdev.c
 - Adds a vf argument to all port profile functions
 
 For 802.1Qbh devices, the port profile calls can use a vf argument if
 passed by the caller. If the vf argument is -1 it will try to derive the vf
 if the device passed is a virtual function.
 
 For 802.1Qbg devices, This patch introduces a null check for the device
 argument because during port profile assignment on a hostdev, this argument
 can be null. Stefan CC'ed for comments
 
 Signed-off-by: Roopa Prabhu ropra...@cisco.com
 ---
  src/qemu/qemu_migration.c|2
  src/util/virnetdevmacvlan.c  |6 +
  src/util/virnetdevvportprofile.c |  203
 +-
  src/util/virnetdevvportprofile.h |8 +
  4 files changed, 42 insertions(+), 177 deletions(-)
 
 
 diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c
 index 7df2d4f..b80ed69 100644
 --- a/src/qemu/qemu_migration.c
 +++ b/src/qemu/qemu_migration.c
 @@ -2605,6 +2605,7 @@ qemuMigrationVPAssociatePortProfiles(virDomainDefPtr
 def) {
 
 virDomainNetGetActualVirtPortProfile(net),
 net-mac,
 
 virDomainNetGetActualDirectDev(net),
 +   -1,
 def-uuid,
 
 VIR_NETDEV_VPORT_PROFILE_OP_MIGRATE_IN_FINISH)  0)
  goto err_exit;
 @@ -2622,6 +2623,7 @@ err_exit:
 
 virDomainNetGetActualVirtPortProfile(net),
 net-mac,
 
 virDomainNetGetActualDirectDev(net),
 +   -1,
 
 VIR_NETDEV_VPORT_PROFILE_OP_MIGRATE_IN_FINISH));
  }
  }
 diff --git a/src/util/virnetdevmacvlan.c b/src/util/virnetdevmacvlan.c
 index 25d0846..498a2a0 100644
 --- a/src/util/virnetdevmacvlan.c
 +++ b/src/util/virnetdevmacvlan.c
 @@ -486,6 +486,7 @@ int virNetDevMacVLanCreateWithVPortProfile(const char
 *tgifname,
  uint32_t macvtapMode;
  const char *cr_ifname;
  int ret;
 +int vf = -1;
  
  macvtapMode = modeMap[mode];
  
 @@ -547,6 +548,7 @@ create_name:
 virtPortProfile,
 macaddress,
 linkdev,
 +   vf,
 vmuuid, vmOp)  0) {
  rc = -1;
  goto link_del_exit;
 @@ -597,6 +599,7 @@ disassociate_exit:
 virtPortProfile,
 macaddress,
 linkdev,
 +   vf,
 vmOp));
  
  link_del_exit:
 @@ -624,6 +627,8 @@ int virNetDevMacVLanDeleteWithVPortProfile(const char
 *ifname,
 char *stateDir)
  {
  int ret = 0;
 +int vf = -1;
 +
  if (mode == VIR_NETDEV_MACVLAN_MODE_PASSTHRU) {
  ignore_value(virNetDevRestoreMacAddress(linkdev, stateDir));
  }
 @@ -633,6 +638,7 @@ int virNetDevMacVLanDeleteWithVPortProfile(const char
 *ifname,
virtPortProfile,
macaddr,
linkdev,
 +  vf,
 
 VIR_NETDEV_VPORT_PROFILE_OP_DESTROY)  0)
  ret = -1;
  if (virNetDevMacVLanDelete(ifname)  0)
 diff --git a/src/util/virnetdevvportprofile.c
 b/src/util/virnetdevvportprofile.c
 index 67fd7bc..8d9e906 100644
 --- a/src/util/virnetdevvportprofile.c
 +++ b/src/util/virnetdevvportprofile.c
 @@ -126,11 +126,6 @@ static struct nla_policy ifla_port_policy[IFLA_PORT_MAX
 + 1] =
  {
[IFLA_PORT_RESPONSE]  = { .type = NLA_U16 },
  };
 -static struct nla_policy ifla_policy[IFLA_MAX + 1] =
 -{
 -  [IFLA_VF_PORTS] = { .type = NLA_NESTED },
 -};
 -
  
  static uint32_t
  virNetDevVPortProfileGetLldpadPid(void) {
 @@ -164,126 +159,6 @@ virNetDevVPortProfileGetLldpadPid(void) {
  return pid;
  }
  
 -
 -/**
 - * virNetDevVPortProfileLinkDump:
 - *
 - * @ifname: The name of the interface; only use if ifindex  0
 - * @ifindex: The interface index; may be  0 if ifname is given
 - * @nltarget_kernel: whether to send the message to the kernel or another
 - *   process
 - * @nlattr: pointer to a pointer of netlink attributes that will contain
 - *

[libvirt] [PATCH 3/4] virnetdevvportprofile: Changes to support portprofiles for hostdevs

2012-03-04 Thread Roopa Prabhu 
From: Roopa Prabhu ropra...@cisco.com

This patch includes the following changes
- removes some netlink functions which are now available in virnetdev.c
- Adds a vf argument to all port profile functions

For 802.1Qbh devices, the port profile calls can use a vf argument if
passed by the caller. If the vf argument is -1 it will try to derive the vf
if the device passed is a virtual function.

For 802.1Qbg devices, This patch introduces a null check for the device
argument because during port profile assignment on a hostdev, this argument
can be null. Stefan CC'ed for comments

Signed-off-by: Roopa Prabhu ropra...@cisco.com
---
 src/qemu/qemu_migration.c|2 
 src/util/virnetdevmacvlan.c  |6 +
 src/util/virnetdevvportprofile.c |  203 +-
 src/util/virnetdevvportprofile.h |8 +
 4 files changed, 42 insertions(+), 177 deletions(-)


diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c
index 7df2d4f..b80ed69 100644
--- a/src/qemu/qemu_migration.c
+++ b/src/qemu/qemu_migration.c
@@ -2605,6 +2605,7 @@ qemuMigrationVPAssociatePortProfiles(virDomainDefPtr def) 
{

virDomainNetGetActualVirtPortProfile(net),
net-mac,

virDomainNetGetActualDirectDev(net),
+   -1,
def-uuid,

VIR_NETDEV_VPORT_PROFILE_OP_MIGRATE_IN_FINISH)  0)
 goto err_exit;
@@ -2622,6 +2623,7 @@ err_exit:

virDomainNetGetActualVirtPortProfile(net),
net-mac,

virDomainNetGetActualDirectDev(net),
+   -1,

VIR_NETDEV_VPORT_PROFILE_OP_MIGRATE_IN_FINISH));
 }
 }
diff --git a/src/util/virnetdevmacvlan.c b/src/util/virnetdevmacvlan.c
index 25d0846..498a2a0 100644
--- a/src/util/virnetdevmacvlan.c
+++ b/src/util/virnetdevmacvlan.c
@@ -486,6 +486,7 @@ int virNetDevMacVLanCreateWithVPortProfile(const char 
*tgifname,
 uint32_t macvtapMode;
 const char *cr_ifname;
 int ret;
+int vf = -1;
 
 macvtapMode = modeMap[mode];
 
@@ -547,6 +548,7 @@ create_name:
virtPortProfile,
macaddress,
linkdev,
+   vf,
vmuuid, vmOp)  0) {
 rc = -1;
 goto link_del_exit;
@@ -597,6 +599,7 @@ disassociate_exit:
virtPortProfile,
macaddress,
linkdev,
+   vf,
vmOp));
 
 link_del_exit:
@@ -624,6 +627,8 @@ int virNetDevMacVLanDeleteWithVPortProfile(const char 
*ifname,
char *stateDir)
 {
 int ret = 0;
+int vf = -1;
+
 if (mode == VIR_NETDEV_MACVLAN_MODE_PASSTHRU) {
 ignore_value(virNetDevRestoreMacAddress(linkdev, stateDir));
 }
@@ -633,6 +638,7 @@ int virNetDevMacVLanDeleteWithVPortProfile(const char 
*ifname,
   virtPortProfile,
   macaddr,
   linkdev,
+  vf,
   
VIR_NETDEV_VPORT_PROFILE_OP_DESTROY)  0)
 ret = -1;
 if (virNetDevMacVLanDelete(ifname)  0)
diff --git a/src/util/virnetdevvportprofile.c b/src/util/virnetdevvportprofile.c
index 67fd7bc..8d9e906 100644
--- a/src/util/virnetdevvportprofile.c
+++ b/src/util/virnetdevvportprofile.c
@@ -126,11 +126,6 @@ static struct nla_policy ifla_port_policy[IFLA_PORT_MAX + 
1] =
 {
   [IFLA_PORT_RESPONSE]  = { .type = NLA_U16 },
 };
-static struct nla_policy ifla_policy[IFLA_MAX + 1] =
-{
-  [IFLA_VF_PORTS] = { .type = NLA_NESTED },
-};
-
 
 static uint32_t
 virNetDevVPortProfileGetLldpadPid(void) {
@@ -164,126 +159,6 @@ virNetDevVPortProfileGetLldpadPid(void) {
 return pid;
 }
 
-
-/**
- * virNetDevVPortProfileLinkDump:
- *
- * @ifname: The name of the interface; only use if ifindex  0
- * @ifindex: The interface index; may be  0 if ifname is given
- * @nltarget_kernel: whether to send the message to the kernel or another
- *   process
- * @nlattr: pointer to a pointer of netlink attributes that will contain
- *  the results
- * @recvbuf: Pointer to the buffer holding

Re: [libvirt] [PATCH 3/4] virnetdevvportprofile: Changes to support portprofiles for hostdevs

2012-03-02 Thread Gerhard Stenzel 
On Thu, 2012-03-01 at 13:02 -0500, Laine Stump wrote:
 In the case of hostdev though, there is not necessarily any netdev
 driver at all in the host (and thus no linkdev to attach a macvtap
 to), certainly not after it's attached to the guest - control of the
 PCI
 device is given over to the guest.
 
 So is the problem here that 802.1QbX stuff can only work if there's an
 associated macvtap device? Although it might be possible to
 temporarily
 create a macvtap device and attach it to the PCI device's netdev
 driver
 prior to passing it through, that would only work if a netdev driver
 was
 bound to the PCI device (which isn't always the case, especially for
 SRIOV VFs), yet that netdev driver would then immediately need to be
 unbound prior to assigning the device to the guest, and most likely
 that
 would kill the macvtap device; even if the setup done using that
 macvtap
 device wasn't undone in the process, would it be possible to undo it
 later when the guest terminates (or the device is detached from the
 guest)? 

I wondered how the complete XML fragment for Qbh would look like and
came up with the following:

interface type='hostdev'
source dev='eth0' mode='private'/
mac address='52:54:00:8b:c9:51'
virtualport type='802.1Qbh'
parameters profileid='finance'/
/virtualport
/interface

Can someone confirm?

For Qbg, we would need then something like this:

interface type='hostdev'
source dev='eth0' mode='vepa'/
mac address='52:54:00:8b:c9:51'
virtualport type=802.1Qbg
parameters managerid=11 typeid=1193047 typeidversion=2 
instanceid=09b11c53-8b5c-4eeb-8f00-d84eaa0aaa4f vlanid=2/
/virtualport
/interface

to be of any use. Note the additional vlanid attribute. The semantic
would be that the host establishes a Qbg association for 
(managerid, typeid, typeidversion, instanceid, vlanid)
and that the VM would need to add the correct VLAN tag in order to be
able to communicate.

Does that make sense?

Best regards, 

Gerhard Stenzel, Hybrid Technologies, LTC
---
IBM Deutschland Research  Development GmbH
Vorsitzende des Aufsichtsrats: Martina Koederitz | Geschäftsführung:
Dirk Wittkopp
Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht
Stuttgart, HRB 243294




--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 3/4] virnetdevvportprofile: Changes to support portprofiles for hostdevs

2012-03-02 Thread Laine Stump 
On 03/02/2012 09:12 AM, Gerhard Stenzel wrote:
 On Thu, 2012-03-01 at 13:02 -0500, Laine Stump wrote:
 In the case of hostdev though, there is not necessarily any netdev
 driver at all in the host (and thus no linkdev to attach a macvtap
 to), certainly not after it's attached to the guest - control of the
 PCI
 device is given over to the guest.

 So is the problem here that 802.1QbX stuff can only work if there's an
 associated macvtap device? Although it might be possible to
 temporarily
 create a macvtap device and attach it to the PCI device's netdev
 driver
 prior to passing it through, that would only work if a netdev driver
 was
 bound to the PCI device (which isn't always the case, especially for
 SRIOV VFs), yet that netdev driver would then immediately need to be
 unbound prior to assigning the device to the guest, and most likely
 that
 would kill the macvtap device; even if the setup done using that
 macvtap
 device wasn't undone in the process, would it be possible to undo it
 later when the guest terminates (or the device is detached from the
 guest)? 
 I wondered how the complete XML fragment for Qbh would look like and
 came up with the following:

 interface type='hostdev'
 source dev='eth0' mode='private'/

1) Currently it requires a PCI address (although I plan to add the
ability to accept a netdev name and automatically convert it to a PCI
address):

   source
 address type='pci' domain='0' bus='0' slot='6' function='0'/
   /source

2) I guess I have been misunderestimating the level of symbiosis between
macvtap and 802.1QbX. I had thought that the private vs. vepa thing was
related to whether or not macvtap could (or couldn't) share the physical
device and (when sharing was allowed) whether or not it allowed multiple
macvtap devices connected to the same physical to see traffic from each
other. This assumption led me to believe that in the case of a PCI
passthrough device, where there is obviously no sharing (or macvtap
device), these different modes were irrelevant, and all that was needed
was the information in virtualport.

What I *think* I'm understanding from this discussion is that 1) in
order for a virtual port association to happen, a macvtap interface must
exist, and the association is done wrt that macvtap device *not* the
physical device, or even the VF, and 2) knowing the information in
virtualport (along with knowing that the physical device is not being
shared) is not enough information to properly perform an associate
operation.

Is this correct?

If that's the case, then there are some basic assumptions made here that
are incorrect, and we will need to either change the lower level code to
somehow accomplish a port associate without a macvtap interface, or we
will need to pull some kind of trickery, possibly adding a macvtap
interface to the PF to be used as a proxy to do the ASSOCIATE for the VF
(will that even work? In particular, will it work if multiple VFs need
to operate in one of the exclusive modes where no sharing of physical
device is permitted?)

Or maybe I'm still not understanding...


 mac address='52:54:00:8b:c9:51'
 virtualport type='802.1Qbh'
 parameters profileid='finance'/
 /virtualport
 /interface

 Can someone confirm?

 For Qbg, we would need then something like this:

 interface type='hostdev'
 source dev='eth0' mode='vepa'/
 mac address='52:54:00:8b:c9:51'
 virtualport type=802.1Qbg
 parameters managerid=11 typeid=1193047 typeidversion=2 
 instanceid=09b11c53-8b5c-4eeb-8f00-d84eaa0aaa4f vlanid=2/
 /virtualport
 /interface

 to be of any use.

Again, my knowledge is insufficient to understand - why was a vlanid not
necessary before when we were dealing with a hostside macvtap tied to a
guest-side emulated netdev, and why is it necessary now that we want to
just passthrough the PCI device to the guest?

  Note the additional vlanid attribute. The semantic
 would be that the host establishes a Qbg association for 
 (managerid, typeid, typeidversion, instanceid, vlanid)
 and that the VM would need to add the correct VLAN tag in order to be
 able to communicate.

So adding the VLAN tag has in the past been done by the macvtap
interface? Where did it learn the vlanid from?

Definitely if the packets need to leave the host with a VLAN tag, in PCI
passthrough mode that will need to be done by the guest OS, since the
host will be unable to get its hands on the packets. Once that's the
case, does it maybe make more sense to just leave *everything* up to the
guest OS - do a PCI passthrough of the device (maybe setting the MAC
address) and let the guest do the port associate etc. too? (Another way
of saying this - at this point, shouldn't we just admit that transparent
hostside support of VEPA (or any other protocol that requires data
packets to be modified) using PCI passthrough by definition is not
possible, and therefore isn't supported?)

Or am I just misunderstanding again?


 Does that make sense?

Re: [libvirt] [PATCH 3/4] virnetdevvportprofile: Changes to support portprofiles for hostdevs

2012-03-02 Thread Stefan Berger 

On 03/02/2012 10:52 AM, Laine Stump wrote:

On 03/02/2012 09:12 AM, Gerhard Stenzel wrote:

On Thu, 2012-03-01 at 13:02 -0500, Laine Stump wrote:

In the case of hostdev though, there is not necessarily any netdev
driver at all in the host (and thus no linkdev to attach a macvtap
to), certainly not after it's attached to the guest - control of the
PCI
device is given over to the guest.

So is the problem here that 802.1QbX stuff can only work if there's an
associated macvtap device? Although it might be possible to
temporarily
create a macvtap device and attach it to the PCI device's netdev
driver
prior to passing it through, that would only work if a netdev driver
was
bound to the PCI device (which isn't always the case, especially for
SRIOV VFs), yet that netdev driver would then immediately need to be
unbound prior to assigning the device to the guest, and most likely
that
would kill the macvtap device; even if the setup done using that
macvtap
device wasn't undone in the process, would it be possible to undo it
later when the guest terminates (or the device is detached from the
guest)?

I wondered how the complete XML fragment for Qbh would look like and
came up with the following:

interface type='hostdev'
 source dev='eth0' mode='private'/

1) Currently it requires a PCI address (although I plan to add the
ability to accept a netdev name and automatically convert it to a PCI
address):

source
  address type='pci' domain='0' bus='0' slot='6' function='0'/
/source

2) I guess I have been misunderestimating the level of symbiosis between
macvtap and 802.1QbX. I had thought that the private vs. vepa thing was
related to whether or not macvtap could (or couldn't) share the physical
device and (when sharing was allowed) whether or not it allowed multiple
macvtap devices connected to the same physical to see traffic from each
other. This assumption led me to believe that in the case of a PCI
passthrough device, where there is obviously no sharing (or macvtap
device), these different modes were irrelevant, and all that was needed
was the information invirtualport.

What I *think* I'm understanding from this discussion is that 1) in
order for a virtual port association to happen, a macvtap interface must
exist, and the association is done wrt that macvtap device *not* the
physical device, or even the VF, and 2) knowing the information in


Well, another aspect of 802.1Qbg versus Qbh is that 802.1Qbg needs an 
external daemon, lldpad, to setup the switch. 802.1Qbh presumably does 
'all it needs' by talking to the firmware on the ethernet card... The 
protocol between libvirt and lldpad currently requires the transfer of 
an interface. So this protocol would have to be extended to 'somehow' 
support a raw PIC bus/device/function.


   Stefan

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 3/4] virnetdevvportprofile: Changes to support portprofiles for hostdevs

2012-03-02 Thread Gerhard Stenzel 
On Fri, 2012-03-02 at 10:52 -0500, Laine Stump wrote:
 Again, my knowledge is insufficient to understand - why was a vlanid
 not
 necessary before when we were dealing with a hostside macvtap tied to
 a
 guest-side emulated netdev, and why is it necessary now that we want
 to
 just passthrough the PCI device to the guest?
 
   Note the additional vlanid attribute. The semantic
  would be that the host establishes a Qbg association for 
  (managerid, typeid, typeidversion, instanceid, vlanid)
  and that the VM would need to add the correct VLAN tag in order to
 be
  able to communicate.
 
 So adding the VLAN tag has in the past been done by the macvtap
 interface? Where did it learn the vlanid from?

(Many questions for which I will need some time ..)

Let me answer the simple ones first:

If you look here http://libvirt.org/formatdomain.html:

devices
interface type='direct'/
...
interface type='direct'
  source dev='eth0.2' mode='vepa'/
  virtualport type=802.1Qbg
parameters managerid=11 typeid=1193047 typeidversion=2
instanceid=09b11c53-8b5c-4eeb-8f00-d84eaa0aaa4f/
  /virtualport
/interface
  /devices
  ...

In this example, the macvtap interface will be created on top of the
VLAN interface 2 on top of eth0.

The Qbg switch needs this information:
(managerid, typeid, typeidversion, instanceid, vlanid)

macvtap/VEPA does not need the the VLAN to work, but Qbg does.

So for PCI passthrough, if the host does the association, it has to know
which VLANID to associate, but the guest has to add the VLAN tags.

 
 Definitely if the packets need to leave the host with a VLAN tag, in
 PCI
 passthrough mode that will need to be done by the guest OS, since the
 host will be unable to get its hands on the packets. Once that's the
 case, does it maybe make more sense to just leave *everything* up to
 the
 guest OS - do a PCI passthrough of the device (maybe setting the MAC
 address) and let the guest do the port associate etc. too? (Another
 way
 of saying this - at this point, shouldn't we just admit that
 transparent
 hostside support of VEPA (or any other protocol that requires data
 packets to be modified) using PCI passthrough by definition is not
 possible, and therefore isn't supported?) 

Letting the guest do the association is an option, which should work
already (even if noone probably tested it yet), but the question is
really how much control should the host have vs the guest. There are
definitely scenarios thinkable where the host should do the association.


Best regards, 

Gerhard Stenzel, Hybrid Technologies, LTC
---
IBM Deutschland Research  Development GmbH
Vorsitzende des Aufsichtsrats: Martina Koederitz | Geschäftsführung:
Dirk Wittkopp
Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht
Stuttgart, HRB 243294






--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 3/4] virnetdevvportprofile: Changes to support portprofiles for hostdevs

2012-03-02 Thread Stefan Berger 

On 03/02/2012 11:37 AM, Gerhard Stenzel wrote:


Letting the guest do the association is an option, which should work
already (even if noone probably tested it yet), but the question is
really how much control should the host have vs the guest. There are
definitely scenarios thinkable where the host should do the association.


I think an applicable scenario is where the infrastructure provider 
doesn't really know the guest user and needs to have 'mandatory access 
control' over the configuration of the infrastructure and yet wants to 
use the pass-through mode for better throughput.


   Stefan

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 3/4] virnetdevvportprofile: Changes to support portprofiles for hostdevs

2012-03-02 Thread Laine Stump 
On 03/02/2012 11:58 AM, Stefan Berger wrote:
 On 03/02/2012 11:37 AM, Gerhard Stenzel wrote:

 Letting the guest do the association is an option, which should work
 already (even if noone probably tested it yet), but the question is
 really how much control should the host have vs the guest. There are
 definitely scenarios thinkable where the host should do the association.

 I think an applicable scenario is where the infrastructure provider
 doesn't really know the guest user and needs to have 'mandatory access
 control' over the configuration of the infrastructure and yet wants to
 use the pass-through mode for better throughput.

And/or when the guest OS doesn't have the necessary smarts to do the
association (or maybe even vlan tagging) itself.

So, at the end of this, is there *any* 802.1QbX mode that can work using
PCI passthrough without at least one of the following things:

1) a macvtap interface on the host. (what about my idea of attaching a
macvtap interface to the PF? does that have any hint of practicality?)

2) extending the protocol for talking with lldpad to support using a raw
PCI device rather than a macvtap device.

3) the guest doing vlan tagging

4) the guest doing the full 802.1QbX associate/de-associate protocol
exchange itself?

Nobody has said it explicitly yet (I think), but I have the impression
that this problem unfortunately can't be solved by libvirt alone. If
that's the case, we should state that as soon as possible so that we can
table the virtualport part of these patches for the short term, and
separate the mac address part to get it pushed upstream (along with the
new low-level PCI utility functions), as that is very useful on its own.

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 3/4] virnetdevvportprofile: Changes to support portprofiles for hostdevs

2012-03-02 Thread Gerhard Stenzel 
On Fri, 2012-03-02 at 10:52 -0500, Laine Stump wrote:
 1) Currently it requires a PCI address (although I plan to add the
 ability to accept a netdev name and automatically convert it to a PCI
 address):
 
source
  address type='pci' domain='0' bus='0' slot='6' function='0'/
/source

This means the XML fragment look more like this for Qbh: 

interface type='hostdev'
source
   address type='pci' domain='0' bus='0' slot='6' function='0'/
/source
mac address='52:54:00:8b:c9:51'
virtualport type='802.1Qbh'
parameters profileid='finance'/
/virtualport
/interface

and for Qbg:

interface type='hostdev'
source
   address type='pci' domain='0' bus='0' slot='6' function='0'/
/source
mac address='52:54:00:8b:c9:51'
virtualport type=802.1Qbg
parameters managerid=11 typeid=1193047 typeidversion=2
instanceid=09b11c53-8b5c-4eeb-8f00-d84eaa0aaa4f vlanid=2/
/virtualport
/interface

 
 2) I guess I have been misunderestimating the level of symbiosis
 between
 macvtap and 802.1QbX. I had thought that the private vs. vepa thing
 was
 related to whether or not macvtap could (or couldn't) share the
 physical
 device and (when sharing was allowed) whether or not it allowed
 multiple
 macvtap devices connected to the same physical to see traffic from
 each
 other. This assumption led me to believe that in the case of a PCI
 passthrough device, where there is obviously no sharing (or macvtap
 device), these different modes were irrelevant, and all that was
 needed
 was the information in virtualport.
 
 What I *think* I'm understanding from this discussion is that 1) in
 order for a virtual port association to happen, a macvtap interface
 must
 exist, and the association is done wrt that macvtap device *not* the
 physical device, or even the VF, and 2) knowing the information in
 virtualport (along with knowing that the physical device is not
 being
 shared) is not enough information to properly perform an associate
 operation.
 
 Is this correct?

If I understand above correctly, your first assumption seems correct and
my XML examples have been misleading you.

 
 If that's the case, then there are some basic assumptions made here
 that
 are incorrect, and we will need to either change the lower level code
 to
 somehow accomplish a port associate without a macvtap interface, or we
 will need to pull some kind of trickery, possibly adding a macvtap
 interface to the PF to be used as a proxy to do the ASSOCIATE for the
 VF
 (will that even work? In particular, will it work if multiple VFs need
 to operate in one of the exclusive modes where no sharing of
 physical
 device is permitted?)
 
 

I do not know for Qbh, but for Qbg:

The switch knows nothing about macvtap devices or virtual functions,
what matters is the combination of 
(managerid, typeid, typeidversion, instanceid, vlanid)
to make an association.

Best regards, 

Gerhard Stenzel, Hybrid Technologies, LTC
---
IBM Deutschland Research  Development GmbH
Vorsitzende des Aufsichtsrats: Martina Koederitz | Geschäftsführung:
Dirk Wittkopp
Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht
Stuttgart, HRB 243294









--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 3/4] virnetdevvportprofile: Changes to support portprofiles for hostdevs

2012-03-02 Thread Roopa Prabhu 



On 3/2/12 11:27 AM, Laine Stump la...@laine.org wrote:

 On 03/02/2012 11:58 AM, Stefan Berger wrote:
 On 03/02/2012 11:37 AM, Gerhard Stenzel wrote:
 
 Letting the guest do the association is an option, which should work
 already (even if noone probably tested it yet), but the question is
 really how much control should the host have vs the guest. There are
 definitely scenarios thinkable where the host should do the association.
 
 I think an applicable scenario is where the infrastructure provider
 doesn't really know the guest user and needs to have 'mandatory access
 control' over the configuration of the infrastructure and yet wants to
 use the pass-through mode for better throughput.
 
 And/or when the guest OS doesn't have the necessary smarts to do the
 association (or maybe even vlan tagging) itself.
 
 So, at the end of this, is there *any* 802.1QbX mode that can work using
 PCI passthrough without at least one of the following things:
 
 1) a macvtap interface on the host. (what about my idea of attaching a
 macvtap interface to the PF? does that have any hint of practicality?)
 
 2) extending the protocol for talking with lldpad to support using a raw
 PCI device rather than a macvtap device.
 
 3) the guest doing vlan tagging
 
 4) the guest doing the full 802.1QbX associate/de-associate protocol
 exchange itself?
 
 Nobody has said it explicitly yet (I think), but I have the impression
 that this problem unfortunately can't be solved by libvirt alone. If
 that's the case, we should state that as soon as possible so that we can
 table the virtualport part of these patches for the short term, and
 separate the mac address part to get it pushed upstream (along with the
 new low-level PCI utility functions), as that is very useful on its own.
 
Laine, The patches I submitted for virtualport 802.1Qbh work just fine.
I submitted these patches mainly to get the virtualport working  for
802.1Qbh. Because we pass the port profile via the PF to fw and then to the
switch.  The driver in the guest just comes up on the VF and uses the
already associated VF.

We do the port profile association from the host because of security
reasons. Instead of giving control to the guest OS.

And as you can see in the patches, for 802.1Qbh port profile association on
the hostdev is not much different from port profile association in the
macvtap case.

Thanks,
Roopa



--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 3/4] virnetdevvportprofile: Changes to support portprofiles for hostdevs

2012-03-02 Thread Gerhard Stenzel 
On Fri, 2012-03-02 at 14:27 -0500, Laine Stump wrote:
 So, at the end of this, is there *any* 802.1QbX mode that can work
 using
 PCI passthrough without at least one of the following things:
 
 1) a macvtap interface on the host. (what about my idea of attaching a
 macvtap interface to the PF? does that have any hint of practicality?)
 
 2) extending the protocol for talking with lldpad to support using a
 raw
 PCI device rather than a macvtap device.

 3) the guest doing vlan tagging
 
 4) the guest doing the full 802.1QbX associate/de-associate protocol
 exchange itself?
 
 Nobody has said it explicitly yet (I think), but I have the impression
 that this problem unfortunately can't be solved by libvirt alone. If
 that's the case, we should state that as soon as possible so that we
 can
 table the virtualport part of these patches for the short term, and
 separate the mac address part to get it pushed upstream (along with
 the
 new low-level PCI utility functions), as that is very useful on its
 own.

I am not sure I can follow the conclusion that this can not be solved in
libvirt alone. 
Qbg:
For the macvtap case, the macvtap device is attached to the underlying
physical interface and this is where the association request is sent to,
via lldpad.
For the PCI passthrough case, the same must be possible, assuming the
physical interface can be concluded from the PCI device and the VLAN
information is provided.

Or do I miss something?

Best regards, 

Gerhard Stenzel, Hybrid Technologies, LTC
---
IBM Deutschland Research  Development GmbH
Vorsitzende des Aufsichtsrats: Martina Koederitz | Geschäftsführung:
Dirk Wittkopp
Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht
Stuttgart, HRB 243294

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 3/4] virnetdevvportprofile: Changes to support portprofiles for hostdevs

2012-03-02 Thread Roopa Prabhu 



On 3/2/12 9:21 AM, Gerhard Stenzel gsten...@linux.vnet.ibm.com wrote:

 On Fri, 2012-03-02 at 14:27 -0500, Laine Stump wrote:
 So, at the end of this, is there *any* 802.1QbX mode that can work
 using
 PCI passthrough without at least one of the following things:
 
 1) a macvtap interface on the host. (what about my idea of attaching a
 macvtap interface to the PF? does that have any hint of practicality?)
 
 2) extending the protocol for talking with lldpad to support using a
 raw
 PCI device rather than a macvtap device.
 
 3) the guest doing vlan tagging
 
 4) the guest doing the full 802.1QbX associate/de-associate protocol
 exchange itself?
 
 Nobody has said it explicitly yet (I think), but I have the impression
 that this problem unfortunately can't be solved by libvirt alone. If
 that's the case, we should state that as soon as possible so that we
 can
 table the virtualport part of these patches for the short term, and
 separate the mac address part to get it pushed upstream (along with
 the
 new low-level PCI utility functions), as that is very useful on its
 own.
 
 I am not sure I can follow the conclusion that this can not be solved in
 libvirt alone. 
 Qbg:
 For the macvtap case, the macvtap device is attached to the underlying
 physical interface and this is where the association request is sent to,
 via lldpad.
 For the PCI passthrough case, the same must be possible, assuming the
 physical interface can be concluded from the PCI device and the VLAN
 information is provided.
 
 Or do I miss something?
 
Wondering if we simplify this to only support sriov devices and
for 802.1Qbg all config can be done via the PF netdevice.

Am assuming the vlan info has to only reach lldpad daemon and you don't
really need a vlan device on host.

In which case, your new xml syntax with vlanid should work I think.
- we send the mac, vlan and port profile info to lldpad via the PF with vf
index using the current IFLA_VF_MAC and IFLA_VF_PORT. No ?

Thanks,
Roopa

 

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 3/4] virnetdevvportprofile: Changes to support portprofiles for hostdevs

2012-03-02 Thread Stefan Berger 

On 03/02/2012 12:05 PM, Gerhard Stenzel wrote:

On Fri, 2012-03-02 at 10:52 -0500, Laine Stump wrote:

1) Currently it requires a PCI address (although I plan to add the
ability to accept a netdev name and automatically convert it to a PCI
address):

source
  address type='pci' domain='0' bus='0' slot='6' function='0'/
/source

This means the XML fragment look more like this for Qbh:

interface type='hostdev'
 source
address type='pci' domain='0' bus='0' slot='6' function='0'/
 /source
 mac address='52:54:00:8b:c9:51'
 virtualport type='802.1Qbh'
 parameters profileid='finance'/
 /virtualport
/interface

and for Qbg:

interface type='hostdev'
 source
address type='pci' domain='0' bus='0' slot='6' function='0'/
 /source
 mac address='52:54:00:8b:c9:51'
 virtualport type=802.1Qbg
 parameters managerid=11 typeid=1193047 typeidversion=2
instanceid=09b11c53-8b5c-4eeb-8f00-d84eaa0aaa4f vlanid=2/
 /virtualport
/interface



So vlanid is the new part? In the case we have no macvtap device we 
would have to find the vlanid in the XML and could convey that to lldpad 
directly (rather than determining it by walking the stack of interfaces 
as we do now) along with an ifindex of '0' or '-1' (?). If lldpad never 
really looked at the ifindex or ifname we sent it via the netlink 
message then this shouldn't be a problem to support, apart from having 
to configure the guest to create a vlan interface of course. So I guess 
the other set of parameters were not applied to the VM's traffic to 
allow VM A using vlanid 2 to be distinguishable from VM B using vlanid 2 
as well on the same host? If this is all true, then at least the code 
path creating the association should be easy to adapt...


   Stefan

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 3/4] virnetdevvportprofile: Changes to support portprofiles for hostdevs

2012-03-02 Thread Laine Stump 
On 03/02/2012 03:16 PM, Roopa Prabhu wrote:
 On 3/2/12 11:27 AM, Laine Stump la...@laine.org wrote:
 On 03/02/2012 11:58 AM, Stefan Berger wrote:
 On 03/02/2012 11:37 AM, Gerhard Stenzel wrote:
 Letting the guest do the association is an option, which should work
 already (even if noone probably tested it yet), but the question is
 really how much control should the host have vs the guest. There are
 definitely scenarios thinkable where the host should do the association.
 I think an applicable scenario is where the infrastructure provider
 doesn't really know the guest user and needs to have 'mandatory access
 control' over the configuration of the infrastructure and yet wants to
 use the pass-through mode for better throughput.
 And/or when the guest OS doesn't have the necessary smarts to do the
 association (or maybe even vlan tagging) itself.

 So, at the end of this, is there *any* 802.1QbX mode that can work using
 PCI passthrough without at least one of the following things:

 1) a macvtap interface on the host. (what about my idea of attaching a
 macvtap interface to the PF? does that have any hint of practicality?)

 2) extending the protocol for talking with lldpad to support using a raw
 PCI device rather than a macvtap device.

 3) the guest doing vlan tagging

 4) the guest doing the full 802.1QbX associate/de-associate protocol
 exchange itself?

 Nobody has said it explicitly yet (I think), but I have the impression
 that this problem unfortunately can't be solved by libvirt alone. If
 that's the case, we should state that as soon as possible so that we can
 table the virtualport part of these patches for the short term, and
 separate the mac address part to get it pushed upstream (along with the
 new low-level PCI utility functions), as that is very useful on its own.

 Laine, The patches I submitted for virtualport 802.1Qbh work just fine.

Yeah, I'm not sure how I lost sight of the fact that you said your
testing had gone okay - I guess too little sleep. So I read too much
into the discussion, and it's just Qbg that has these restrictions.
Good! Pay no attention to my alarmism :-)


 I submitted these patches mainly to get the virtualport working  for
 802.1Qbh. Because we pass the port profile via the PF to fw and then to the
 switch.  The driver in the guest just comes up on the VF and uses the
 already associated VF.

Right. That's pretty much how I've always been assuming it worked for
all of these modes. I guess I should spend more time at lower levels.

 We do the port profile association from the host because of security
 reasons. Instead of giving control to the guest OS.

 And as you can see in the patches, for 802.1Qbh port profile association on
 the hostdev is not much different from port profile association in the
 macvtap case.


Okay, then in the end these patches will support 802.1Qbh virtualport
setting, as well as setting the MAC address (but only for SRIOV-capable
devices). And any future support for 802.1Qbg would require both some
extra support outside libvirt, as well as specifying the vlanid in the
config, and requiring the guest to setup VLAN tagging. Did I get it
right now?


--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 3/4] virnetdevvportprofile: Changes to support portprofiles for hostdevs

2012-03-02 Thread Roopa Prabhu 



On 3/2/12 12:45 PM, Laine Stump la...@laine.org wrote:

 On 03/02/2012 03:16 PM, Roopa Prabhu wrote:
 On 3/2/12 11:27 AM, Laine Stump la...@laine.org wrote:
 On 03/02/2012 11:58 AM, Stefan Berger wrote:
 On 03/02/2012 11:37 AM, Gerhard Stenzel wrote:
 Letting the guest do the association is an option, which should work
 already (even if noone probably tested it yet), but the question is
 really how much control should the host have vs the guest. There are
 definitely scenarios thinkable where the host should do the association.
 I think an applicable scenario is where the infrastructure provider
 doesn't really know the guest user and needs to have 'mandatory access
 control' over the configuration of the infrastructure and yet wants to
 use the pass-through mode for better throughput.
 And/or when the guest OS doesn't have the necessary smarts to do the
 association (or maybe even vlan tagging) itself.
 
 So, at the end of this, is there *any* 802.1QbX mode that can work using
 PCI passthrough without at least one of the following things:
 
 1) a macvtap interface on the host. (what about my idea of attaching a
 macvtap interface to the PF? does that have any hint of practicality?)
 
 2) extending the protocol for talking with lldpad to support using a raw
 PCI device rather than a macvtap device.
 
 3) the guest doing vlan tagging
 
 4) the guest doing the full 802.1QbX associate/de-associate protocol
 exchange itself?
 
 Nobody has said it explicitly yet (I think), but I have the impression
 that this problem unfortunately can't be solved by libvirt alone. If
 that's the case, we should state that as soon as possible so that we can
 table the virtualport part of these patches for the short term, and
 separate the mac address part to get it pushed upstream (along with the
 new low-level PCI utility functions), as that is very useful on its own.
 
 Laine, The patches I submitted for virtualport 802.1Qbh work just fine.
 
 Yeah, I'm not sure how I lost sight of the fact that you said your
 testing had gone okay - I guess too little sleep. So I read too much
 into the discussion, and it's just Qbg that has these restrictions.
 Good! Pay no attention to my alarmism :-)
 
 
No problem :)

 I submitted these patches mainly to get the virtualport working  for
 802.1Qbh. Because we pass the port profile via the PF to fw and then to the
 switch.  The driver in the guest just comes up on the VF and uses the
 already associated VF.
 
 Right. That's pretty much how I've always been assuming it worked for
 all of these modes. I guess I should spend more time at lower levels.
 
 We do the port profile association from the host because of security
 reasons. Instead of giving control to the guest OS.
 
 And as you can see in the patches, for 802.1Qbh port profile association on
 the hostdev is not much different from port profile association in the
 macvtap case.
 
 
 Okay, then in the end these patches will support 802.1Qbh virtualport
 setting, as well as setting the MAC address (but only for SRIOV-capable
 devices). And any future support for 802.1Qbg would require both some
 extra support outside libvirt,
 as well as specifying the vlanid in the
 config, and requiring the guest to setup VLAN tagging. Did I get it
 right now?
 
Yes that seems right. I think we don't need to call out the setup in the
guest. Its common for all modes. Host provisions the vlans (ie configures
the switch port with that vlan etc). This is the step that libvirt does. And
guest does his own setup for vlan devices if needed.

Thanks,
Roopa


--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 3/4] virnetdevvportprofile: Changes to support portprofiles for hostdevs

2012-03-02 Thread Gerhard Stenzel 
On Fri, 2012-03-02 at 15:45 -0500, Laine Stump wrote:
 Okay, then in the end these patches will support 802.1Qbh
 virtualport
 setting, as well as setting the MAC address (but only for
 SRIOV-capable
 devices). And any future support for 802.1Qbg would require both some
 extra support outside libvirt, as well as specifying the vlanid in the
 config, and requiring the guest to setup VLAN tagging. Did I get it
 right now?
 
Not sure, we need anything else for Qbg in addition to some changes in
libvirt and vlan tagging in the guest.
But, I think we are converging that the Qbh part looks okay and the Qbg
part can be added later, if necessary.

Best regards, 

Gerhard Stenzel, Hybrid Technologies, LTC
---
IBM Deutschland Research  Development GmbH
Vorsitzende des Aufsichtsrats: Martina Koederitz | Geschäftsführung:
Dirk Wittkopp
Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht
Stuttgart, HRB 243294



--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH 3/4] virnetdevvportprofile: Changes to support portprofiles for hostdevs

2012-03-01 Thread Roopa Prabhu 
From: Roopa Prabhu ropra...@cisco.com

This patch includes the following changes
- removes some netlink functions which are now available in virnetdev.c
- Adds a vf argument to all port profile functions

For 802.1Qbh devices, the port profile calls can use a vf argument if
passed by the caller. If the vf argument is -1 it will try to derive the vf
if the device passed is a virtual function.

For 802.1Qbg devices, This patch introduces a null check for the device
argument because during port profile assignment on a hostdev, this argument
can be null. Stefan CC'ed for comments

Signed-off-by: Roopa Prabhu ropra...@cisco.com
---
 src/qemu/qemu_migration.c|2 
 src/util/virnetdevmacvlan.c  |6 +
 src/util/virnetdevvportprofile.c |  203 +-
 src/util/virnetdevvportprofile.h |8 +
 4 files changed, 42 insertions(+), 177 deletions(-)


diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c
index 7df2d4f..b80ed69 100644
--- a/src/qemu/qemu_migration.c
+++ b/src/qemu/qemu_migration.c
@@ -2605,6 +2605,7 @@ qemuMigrationVPAssociatePortProfiles(virDomainDefPtr def) 
{

virDomainNetGetActualVirtPortProfile(net),
net-mac,

virDomainNetGetActualDirectDev(net),
+   -1,
def-uuid,

VIR_NETDEV_VPORT_PROFILE_OP_MIGRATE_IN_FINISH)  0)
 goto err_exit;
@@ -2622,6 +2623,7 @@ err_exit:

virDomainNetGetActualVirtPortProfile(net),
net-mac,

virDomainNetGetActualDirectDev(net),
+   -1,

VIR_NETDEV_VPORT_PROFILE_OP_MIGRATE_IN_FINISH));
 }
 }
diff --git a/src/util/virnetdevmacvlan.c b/src/util/virnetdevmacvlan.c
index 25d0846..498a2a0 100644
--- a/src/util/virnetdevmacvlan.c
+++ b/src/util/virnetdevmacvlan.c
@@ -486,6 +486,7 @@ int virNetDevMacVLanCreateWithVPortProfile(const char 
*tgifname,
 uint32_t macvtapMode;
 const char *cr_ifname;
 int ret;
+int vf = -1;
 
 macvtapMode = modeMap[mode];
 
@@ -547,6 +548,7 @@ create_name:
virtPortProfile,
macaddress,
linkdev,
+   vf,
vmuuid, vmOp)  0) {
 rc = -1;
 goto link_del_exit;
@@ -597,6 +599,7 @@ disassociate_exit:
virtPortProfile,
macaddress,
linkdev,
+   vf,
vmOp));
 
 link_del_exit:
@@ -624,6 +627,8 @@ int virNetDevMacVLanDeleteWithVPortProfile(const char 
*ifname,
char *stateDir)
 {
 int ret = 0;
+int vf = -1;
+
 if (mode == VIR_NETDEV_MACVLAN_MODE_PASSTHRU) {
 ignore_value(virNetDevRestoreMacAddress(linkdev, stateDir));
 }
@@ -633,6 +638,7 @@ int virNetDevMacVLanDeleteWithVPortProfile(const char 
*ifname,
   virtPortProfile,
   macaddr,
   linkdev,
+  vf,
   
VIR_NETDEV_VPORT_PROFILE_OP_DESTROY)  0)
 ret = -1;
 if (virNetDevMacVLanDelete(ifname)  0)
diff --git a/src/util/virnetdevvportprofile.c b/src/util/virnetdevvportprofile.c
index 67fd7bc..03c85dd 100644
--- a/src/util/virnetdevvportprofile.c
+++ b/src/util/virnetdevvportprofile.c
@@ -126,11 +126,6 @@ static struct nla_policy ifla_port_policy[IFLA_PORT_MAX + 
1] =
 {
   [IFLA_PORT_RESPONSE]  = { .type = NLA_U16 },
 };
-static struct nla_policy ifla_policy[IFLA_MAX + 1] =
-{
-  [IFLA_VF_PORTS] = { .type = NLA_NESTED },
-};
-
 
 static uint32_t
 virNetDevVPortProfileGetLldpadPid(void) {
@@ -164,126 +159,6 @@ virNetDevVPortProfileGetLldpadPid(void) {
 return pid;
 }
 
-
-/**
- * virNetDevVPortProfileLinkDump:
- *
- * @ifname: The name of the interface; only use if ifindex  0
- * @ifindex: The interface index; may be  0 if ifname is given
- * @nltarget_kernel: whether to send the message to the kernel or another
- *   process
- * @nlattr: pointer to a pointer of netlink attributes that will contain
- *  the results
- * @recvbuf: Pointer to the buffer holding

Re: [libvirt] [PATCH 3/4] virnetdevvportprofile: Changes to support portprofiles for hostdevs

2012-03-01 Thread Stefan Berger 

On 03/01/2012 04:02 AM, Roopa Prabhu wrote:

From: Roopa Prabhuropra...@cisco.com

This patch includes the following changes
- removes some netlink functions which are now available in virnetdev.c
- Adds a vf argument to all port profile functions

For 802.1Qbh devices, the port profile calls can use a vf argument if
passed by the caller. If the vf argument is -1 it will try to derive the vf
if the device passed is a virtual function.

For 802.1Qbg devices, This patch introduces a null check for the device
argument because during port profile assignment on a hostdev, this argument
can be null. Stefan CC'ed for comments


I agree to the change per se since entering the function with a NULL 
parameter would be fatal, though I am wondering under what condition 
this can occur. I don't see this happening in the Associate call path 
for example.


   Stefan

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 3/4] virnetdevvportprofile: Changes to support portprofiles for hostdevs

2012-03-01 Thread Roopa Prabhu 



On 3/1/12 4:39 AM, Stefan Berger stef...@linux.vnet.ibm.com wrote:

 On 03/01/2012 04:02 AM, Roopa Prabhu wrote:
 From: Roopa Prabhuropra...@cisco.com
 
 This patch includes the following changes
 - removes some netlink functions which are now available in virnetdev.c
 - Adds a vf argument to all port profile functions
 
 For 802.1Qbh devices, the port profile calls can use a vf argument if
 passed by the caller. If the vf argument is -1 it will try to derive the vf
 if the device passed is a virtual function.
 
 For 802.1Qbg devices, This patch introduces a null check for the device
 argument because during port profile assignment on a hostdev, this argument
 can be null. Stefan CC'ed for comments
 
 I agree to the change per se since entering the function with a NULL
 parameter would be fatal, though I am wondering under what condition
 this can occur. I don't see this happening in the Associate call path
 for example.

It happens in patch 4/4 where we call associate for a hostdev and there is
no macvtap available there.

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 3/4] virnetdevvportprofile: Changes to support portprofiles for hostdevs

2012-03-01 Thread Roopa Prabhu 



On 3/1/12 7:52 AM, Stefan Berger stef...@linux.vnet.ibm.com wrote:

 On 03/01/2012 10:32 AM, Roopa Prabhu wrote:
 
 
 On 3/1/12 4:39 AM, Stefan Bergerstef...@linux.vnet.ibm.com  wrote:
 
 On 03/01/2012 04:02 AM, Roopa Prabhu wrote:
 From: Roopa Prabhuropra...@cisco.com
 
 This patch includes the following changes
 - removes some netlink functions which are now available in virnetdev.c
 - Adds a vf argument to all port profile functions
 
 For 802.1Qbh devices, the port profile calls can use a vf argument if
 passed by the caller. If the vf argument is -1 it will try to derive the vf
 if the device passed is a virtual function.
 
 For 802.1Qbg devices, This patch introduces a null check for the device
 argument because during port profile assignment on a hostdev, this argument
 can be null. Stefan CC'ed for comments
 I agree to the change per se since entering the function with a NULL
 parameter would be fatal, though I am wondering under what condition
 this can occur. I don't see this happening in the Associate call path
 for example.
 It happens in patch 4/4 where we call associate for a hostdev and there is
 no macvtap available there.
 
 
 So this hostdev related code can only be used by 802.1Qbh because the
 type of device does not exist for 802.1Qbg?

Not really. The hostdev device is just a pci device. But looking at 802.1Qbg
port profile related code..i was not sure how it can be done when the device
is a hostdev. 


 I think that at least there
 should be an error message logging the fact that the function was called
 without an interface name.  Also the return error code should probably
 be -1 and not be overloaded with -E*.
Ok This can be done.

If possible (unless already done)
 the combination of hostdev and 802.1Qbg should probably even be
 prevented on the XML level.
This is not done yet. I think I will do it. And then if someone knows how to
do it for 802.1Qbg they can open this up.

Thanks stefan. 

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 3/4] virnetdevvportprofile: Changes to support portprofiles for hostdevs

2012-03-01 Thread Stefan Berger 

On 03/01/2012 10:32 AM, Roopa Prabhu wrote:



On 3/1/12 4:39 AM, Stefan Bergerstef...@linux.vnet.ibm.com  wrote:


On 03/01/2012 04:02 AM, Roopa Prabhu wrote:

From: Roopa Prabhuropra...@cisco.com

This patch includes the following changes
- removes some netlink functions which are now available in virnetdev.c
- Adds a vf argument to all port profile functions

For 802.1Qbh devices, the port profile calls can use a vf argument if
passed by the caller. If the vf argument is -1 it will try to derive the vf
if the device passed is a virtual function.

For 802.1Qbg devices, This patch introduces a null check for the device
argument because during port profile assignment on a hostdev, this argument
can be null. Stefan CC'ed for comments

I agree to the change per se since entering the function with a NULL
parameter would be fatal, though I am wondering under what condition
this can occur. I don't see this happening in the Associate call path
for example.

It happens in patch 4/4 where we call associate for a hostdev and there is
no macvtap available there.



So this hostdev related code can only be used by 802.1Qbh because the 
type of device does not exist for 802.1Qbg? I think that at least there 
should be an error message logging the fact that the function was called 
without an interface name.  Also the return error code should probably 
be -1 and not be overloaded with -E*. If possible (unless already done) 
the combination of hostdev and 802.1Qbg should probably even be 
prevented on the XML level.


Stefan

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 3/4] virnetdevvportprofile: Changes to support portprofiles for hostdevs

2012-03-01 Thread Stefan Berger 

On 03/01/2012 11:32 AM, Roopa Prabhu wrote:



On 3/1/12 7:52 AM, Stefan Bergerstef...@linux.vnet.ibm.com  wrote:


On 03/01/2012 10:32 AM, Roopa Prabhu wrote:


On 3/1/12 4:39 AM, Stefan Bergerstef...@linux.vnet.ibm.com   wrote:


On 03/01/2012 04:02 AM, Roopa Prabhu wrote:

From: Roopa Prabhuropra...@cisco.com

This patch includes the following changes
- removes some netlink functions which are now available in virnetdev.c
- Adds a vf argument to all port profile functions

For 802.1Qbh devices, the port profile calls can use a vf argument if
passed by the caller. If the vf argument is -1 it will try to derive the vf
if the device passed is a virtual function.

For 802.1Qbg devices, This patch introduces a null check for the device
argument because during port profile assignment on a hostdev, this argument
can be null. Stefan CC'ed for comments

I agree to the change per se since entering the function with a NULL
parameter would be fatal, though I am wondering under what condition
this can occur. I don't see this happening in the Associate call path
for example.

It happens in patch 4/4 where we call associate for a hostdev and there is
no macvtap available there.


So this hostdev related code can only be used by 802.1Qbh because the
type of device does not exist for 802.1Qbg?

Not really. The hostdev device is just a pci device. But looking at 802.1Qbg
port profile related code..i was not sure how it can be done when the device
is a hostdev.


My guess is that in the 802.1Qbg case we would have to build a macvtap 
device on top of the linkdev to have the macvtap_ifname parameter 
available. Well, maybe the point of intercept would be to check the type 
of profile in 4/4 and make sure it's a 802.1Qbh type and only then 
invoke the function -- like a switch() statement where 802.1Qbh type of 
profile is supported and 802.1Qbg is not (yet).





I think that at least there
should be an error message logging the fact that the function was called
without an interface name.  Also the return error code should probably
be -1 and not be overloaded with -E*.

Ok This can be done.


If possible (unless already done)
the combination of hostdev and 802.1Qbg should probably even be
prevented on the XML level.

This is not done yet. I think I will do it. And then if someone knows how to
do it for 802.1Qbg they can open this up.



   Stefan

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 3/4] virnetdevvportprofile: Changes to support portprofiles for hostdevs

2012-03-01 Thread Laine Stump 
On 03/01/2012 11:55 AM, Stefan Berger wrote:
 On 03/01/2012 11:32 AM, Roopa Prabhu wrote:


 On 3/1/12 7:52 AM, Stefan Bergerstef...@linux.vnet.ibm.com  wrote:

 On 03/01/2012 10:32 AM, Roopa Prabhu wrote:

 On 3/1/12 4:39 AM, Stefan Bergerstef...@linux.vnet.ibm.com  
 wrote:

 On 03/01/2012 04:02 AM, Roopa Prabhu wrote:
 From: Roopa Prabhuropra...@cisco.com

 This patch includes the following changes
 - removes some netlink functions which are now available in
 virnetdev.c
 - Adds a vf argument to all port profile functions

 For 802.1Qbh devices, the port profile calls can use a vf
 argument if
 passed by the caller. If the vf argument is -1 it will try to
 derive the vf
 if the device passed is a virtual function.

 For 802.1Qbg devices, This patch introduces a null check for the
 device
 argument because during port profile assignment on a hostdev,
 this argument
 can be null. Stefan CC'ed for comments
 I agree to the change per se since entering the function with a NULL
 parameter would be fatal, though I am wondering under what condition
 this can occur. I don't see this happening in the Associate call path
 for example.
 It happens in patch 4/4 where we call associate for a hostdev and
 there is
 no macvtap available there.

 So this hostdev related code can only be used by 802.1Qbh because the
 type of device does not exist for 802.1Qbg?
 Not really. The hostdev device is just a pci device. But looking at
 802.1Qbg
 port profile related code..i was not sure how it can be done when the
 device
 is a hostdev.

 My guess is that in the 802.1Qbg case we would have to build a macvtap
 device on top of the linkdev to have the macvtap_ifname parameter
 available. Well, maybe the point of intercept would be to check the
 type of profile in 4/4 and make sure it's a 802.1Qbh type and only
 then invoke the function -- like a switch() statement where 802.1Qbh
 type of profile is supported and 802.1Qbg is not (yet).

In the case of hostdev though, there is not necessarily any netdev
driver at all in the host (and thus no linkdev to attach a macvtap
to), certainly not after it's attached to the guest - control of the PCI
device is given over to the guest.

So is the problem here that 802.1QbX stuff can only work if there's an
associated macvtap device? Although it might be possible to temporarily
create a macvtap device and attach it to the PCI device's netdev driver
prior to passing it through, that would only work if a netdev driver was
bound to the PCI device (which isn't always the case, especially for
SRIOV VFs), yet that netdev driver would then immediately need to be
unbound prior to assigning the device to the guest, and most likely that
would kill the macvtap device; even if the setup done using that macvtap
device wasn't undone in the process, would it be possible to undo it
later when the guest terminates (or the device is detached from the guest)?



 I think that at least there
 should be an error message logging the fact that the function was
 called
 without an interface name.  Also the return error code should probably
 be -1 and not be overloaded with -E*.
 Ok This can be done.

 If possible (unless already done)
 the combination of hostdev and 802.1Qbg should probably even be
 prevented on the XML level.
 This is not done yet. I think I will do it. And then if someone knows
 how to
 do it for 802.1Qbg they can open this up.


Stefan



--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list