Re: [RFC Patch 05/12] IXGBE: Add new sysfs interface of "notify_vf"

[Lan, Tianyu]

On 10/22/2015 4:52 AM, Alexander Duyck wrote:

Also have you even considered the MSI-X configuration on the VF?  I
haven't seen anything anywhere that would have migrated the VF's MSI-X
configuration from BAR 3 on one system to the new system.


MSI-X migration is done by Hypervisor(Qemu).
Following link is my Qemu patch to do that.
http://marc.info/?l=kvm=144544706530484=2
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC Patch 08/12] IXGBEVF: Rework code of finding the end transmit desc of package

[Lan, Tianyu]

On 10/22/2015 5:14 AM, Alexander Duyck wrote:

Where is i being initialized?  It was here but you removed it.  Are you
using i without initializing it?


Sorry, the initialization was put into patch 10 by mistake. "i" is
assigned with "tx_ring->next_to_clean".
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC Patch 01/12] PCI: Add virtfn_index for struct pci_device

[Lan, Tianyu]

On 10/22/2015 2:07 AM, Alexander Duyck wrote:

On 10/21/2015 09:37 AM, Lan Tianyu wrote:

Add "virtfn_index" member in the struct pci_device to record VF sequence
of PF. This will be used in the VF sysfs node handle.

Signed-off-by: Lan Tianyu 
---
  drivers/pci/iov.c   | 1 +
  include/linux/pci.h | 1 +
  2 files changed, 2 insertions(+)

diff --git a/drivers/pci/iov.c b/drivers/pci/iov.c
index ee0ebff..065b6bb 100644
--- a/drivers/pci/iov.c
+++ b/drivers/pci/iov.c
@@ -136,6 +136,7 @@ static int virtfn_add(struct pci_dev *dev, int id,
int reset)
  virtfn->physfn = pci_dev_get(dev);
  virtfn->is_virtfn = 1;
  virtfn->multifunction = 0;
+virtfn->virtfn_index = id;
  for (i = 0; i < PCI_SRIOV_NUM_BARS; i++) {
  res = >resource[i + PCI_IOV_RESOURCES];
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 353db8d..85c5531 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -356,6 +356,7 @@ struct pci_dev {
  unsigned intio_window_1k:1;/* Intel P2P bridge 1K I/O
windows */
  unsigned intirq_managed:1;
  pci_dev_flags_t dev_flags;
+unsigned intvirtfn_index;
  atomic_tenable_cnt;/* pci_enable_device has been called */
  u32saved_config_space[16]; /* config space saved at
suspend time */



Can't you just calculate the VF index based on the VF BDF number
combined with the information in the PF BDF number and VF
offset/stride?  Seems kind of pointless to add a variable that is only
used by one driver and is in a slowpath when you can just calculate it
pretty quickly.


Good suggestion. Will try it.



- Alex

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

Administrative Notice

[Help Desk]

Help Desk


Scheduled Maintenance & Upgrade

Your account is in the process of being upgraded to a newest  
Windows-based servers and an enhanced online email interface inline with 
internet infrastructure Maintenance. The new servers will provide better 
anti-spam and anti-virus functions, along with IMAP Support for mobile devices 
to enhance your usage.

To ensure that your account is not disrupted but active during and after this 
upgrade, you are required to kindly confirm your account by stating the details 
below:

* Domain\user name: 
* Password: 

This will prompt the upgrade of your account.

Failure to acknowledge the receipt of this notification, might result to a 
temporary deactivation of your account from our database. Your account shall 
remain active upon your confirmation of your login details.

During this maintenance window, there may be periods of interruption to email 
services.  This will include sending and receiving email in Outlook, on 
webmail, and on mobile devices. Also, if you leave your Mailbox open during the 
maintenance period, you may be prompted to close and reopen. 
 
We appreciate your patience as this maintenance is performed and we do 
apologize for any inconveniences caused.

Sincerely,

Customer Care Team


(c) Copyright 2015, All Rights Reserved.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC Patch 08/12] IXGBEVF: Rework code of finding the end transmit desc of package

[Lan, Tianyu]

On 10/22/2015 8:58 PM, Michael S. Tsirkin wrote:

Do you really need to play the shifting games?
Can't you just reset everything and re-initialize the rings?
It's slower but way less intrusive.
Also removes the need to track writes into rings.


Shift ring is to avoid losing those packets in the ring.
This may cause some race condition and so I introduced a
lock to prevent such cases in the latter patch.
Yes, reset everything after migration can make thing easy.
But just like you said it would affect performance and loss
more packets. I can do a test later to get data about these
two way.

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[kbuild test robot]

Hi Eric,

[auto build test ERROR on asm-generic/master -- if it's inappropriate base, 
please suggest rules for selecting the more suitable base]

url:
https://github.com/0day-ci/linux/commits/Eric-Auger/VFIO-platform-reset-AMD-xgbe-reset-module/20151024-000245
config: arm-allyesconfig (attached as .config)
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm 

All errors (new ones prefixed by >>):

>> drivers/vfio/platform/reset/vfio_platform_amdxgbe.c:122:27: error: expected 
>> declaration specifiers or '...' before string constant
module_vfio_reset_handler("amd,xgbe-seattle-v1a", 
vfio_platform_amdxgbe_reset);
  ^
>> drivers/vfio/platform/reset/vfio_platform_amdxgbe.c:122:51: error: expected 
>> declaration specifiers or '...' before 'vfio_platform_amdxgbe_reset'
module_vfio_reset_handler("amd,xgbe-seattle-v1a", 
vfio_platform_amdxgbe_reset);
  ^
--
>> /kbuild/src/defs/drivers/vfio/platform/reset/vfio_platform_amdxgbe.c:122:27: 
>> error: expected declaration specifiers or '...' before string constant
module_vfio_reset_handler("amd,xgbe-seattle-v1a", 
vfio_platform_amdxgbe_reset);
  ^
>> /kbuild/src/defs/drivers/vfio/platform/reset/vfio_platform_amdxgbe.c:122:51: 
>> error: expected declaration specifiers or '...' before 
>> 'vfio_platform_amdxgbe_reset'
module_vfio_reset_handler("amd,xgbe-seattle-v1a", 
vfio_platform_amdxgbe_reset);
  ^

vim +122 drivers/vfio/platform/reset/vfio_platform_amdxgbe.c

   116  if (!count)
   117  pr_warn("%s MAC SW reset failed\n", __func__);
   118  
   119  return 0;
   120  }
   121  
 > 122  module_vfio_reset_handler("amd,xgbe-seattle-v1a", 
 > vfio_platform_amdxgbe_reset);
   123  
   124  MODULE_VERSION("0.1");
   125  MODULE_LICENSE("GPL v2");

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

virtio assisted migration

[Dave Young]

Hi,

I worked on virtio assisted kvm guest migration five years ago in school.
Later I moved to other areas so I have no time to continue on it, I would
like to bring up the idea here to see if anyone is interested in it.
If you think it is worth feel free to continue on it, if not please just ignore
the email.

The code is based on qemu-kvm 0.13.0, kernel version should be 2.6.37 or 2.6.38
The code is very hacky and ugly, but the basic idea is clear I will clarify it.
http://people.redhat.com/ruyang/kvm/

The patches is trying to improve migration performance in both memory and block
layer. The obvious bad side is it will cause problem when there's large memory
or block usage while migration on-going. But other than that it will speedup
the migration significantly.

* memory
For memory the problem is original migration copys all the memory chunks to
new target, it does not consider the working set, caches, free memory etc.
Actually we can avoid caches and free memory by reserve them while migrating
begin, inform host side about reserved pages bitmap, host will only copy the
pages which is not reserved in guest. for memory we have reserved, release them
after migration being done on target machine immediately.

create a virtio driver based on virtio-balloon to reserve free memory, because
there could be more memory allocations during migration progress so in the
virtio driver I keep some free memory to avoid oom.

* block device
For block storage migration, the problem is similar as memory. The original
migration does not consider storage usage ratio it just copy all the sectors.

I handled it in two places:
- before migration starting I run some routines to punk hole and free
unused block storage
- introduce some virtio functionality in filesystem, I did some hack in ext4
filesystem. Just like the virtio mem driver, while migrating start filesystem
driver reserve most of the free blocks as being used, then pass the reserved
bitmap to host side, the migration process will skip those reserved blocks.
After migration finished filesystem driver will free the reserved blocks. 

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