gmane.linux.kernel.virtualization

[PATCH 0/3] Fix hot-unplug race in virtio-blk

Asias He — 2012-05-25T02:34:46

This patch set fixes the race when hot-unplug stressed disk.

Asias He (3):
  virtio-blk: Call del_gendisk() before disable guest kick
  virtio-blk: Reset device after blk_cleanup_queue()
  virtio-blk: Use block layer provided spinlock

 drivers/block/virtio_blk.c |   25 ++++++-------------------
 1 file changed, 6 insertions(+), 19 deletions(-)

[PATCH] xen: do not disable netfront in dom0

Marek Marczykowski — 2012-05-20T11:45:10

Netfront driver can be also useful in dom0, eg when all NICs are assigned to
some domU (aka driver domain). Then using netback in domU and netfront in dom0
is the only way to get network access in dom0.

Signed-off-by: Marek Marczykowski <marmarek< at >invisiblethingslab.com>
---
 drivers/net/xen-netfront.c |    6 ------
 1 files changed, 0 insertions(+), 6 deletions(-)

diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 698b905..e31ebff 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
< at >< at > -1953,9 +1953,6 < at >< at > static int __init netif_init(void)
 if (!xen_domain())
 return -ENODEV;
 
-if (xen_initial_domain())
-return 0;
-
 printk(KERN_INFO "Initialising Xen virtual ethernet driver.\n");
 
 return xenbus_register_frontend(&netfront_driver);
< at >< at > -1965,9 +1962,6 < at >< at > module_init(netif_init);
 
 static void __exit netif_exit(void)
 {
-if (xen_initial_domain())
-return;
-
 xenbus_unregister_driver(&netfront_driver);
 }
 module_exit(netif_exit);

[PATCH] virtio: fix typo in comment

Chen Baozi — 2012-05-20T02:44:34

From: Chen Baozi <chenbaozi< at >gmail.com>

- Delete "< at >request_vqs" and "< at >free_vqs" comments, since
  they are no longer in struct virtio_config_ops.
- According to the macro below, "< at >val" should be "< at >v".

Signed-off-by: Chen Baozi <chenbaozi< at >gmail.com>
---
 include/linux/virtio_config.h |   11 +----------
 1 files changed, 1 insertions(+), 10 deletions(-)

diff --git a/include/linux/virtio_config.h b/include/linux/virtio_config.h
index 7323a33..fc457f4 100644
--- a/include/linux/virtio_config.h
+++ b/include/linux/virtio_config.h
< at >< at > -74,15 +74,6 < at >< at >
  * < at >set_status: write the status byte
  *vdev: the virtio_device
  *status: the new status byte
- * < at >request_vqs: request the specified number of virtqueues
- *vdev: the virtio_device
- *max_vqs: the max number of virtqueues we want
- *      If supplied, must call before any virtqueues are instantiated.
- *      To modify the max number of virtqueues after request_vqs has been
- *      called, call free_vqs and then request_vqs with a new value.
- * < at >free_vqs: cleanup resources allocated by request_vqs
- *vdev: the virtio_device
- *      If supplied, must call after all virtqueues have been deleted.
  * < at >reset: reset the device
  *vdev: the virtio device
  *After this, status and feature negotiation must be done again
< at >< at > -156,7 +147,7 < at >< at > static inline bool virtio_has_feature(const struct virtio_device *vdev,
  * < at >vdev: the virtio device
  * < at >fbit: the feature bit
  * < at >offset: the type to search for.
- * < at >val: a pointer to the value to fill in.
+ * < at >v: a pointer to the value to fill in.
  *
  * The return value is -ENOENT if the feature doesn't exist.  Otherwise
  * the config value is copied into whatever is pointed to by v. */

[RFC PATCH 1/5] block: Introduce q->abort_queue_fn()

Asias He — 2012-05-21T09:08:29

When user hot-unplug a disk which is busy serving I/O, __blk_run_queue
might be unable to drain all the requests. As a result, the
blk_drain_queue() would loop forever and blk_cleanup_queue would not
return. So hot-unplug will fail.

This patch adds a callback in blk_drain_queue() for low lever driver to
abort requests.

Currently, this is useful for virtio-blk to do cleanup in hot-unplug.

Cc: Jens Axboe <axboe< at >kernel.dk>
Cc: Tejun Heo <tj< at >kernel.org>
Cc: linux-fsdevel< at >vger.kernel.org
Cc: Rusty Russell <rusty< at >rustcorp.com.au>
Cc: "Michael S. Tsirkin" <mst< at >redhat.com>
Cc: virtualization< at >lists.linux-foundation.org
Cc: kvm< at >vger.kernel.org
Signed-off-by: Asias He <asias< at >redhat.com>
---
 block/blk-core.c       |    3 +++
 block/blk-settings.c   |   12 ++++++++++++
 include/linux/blkdev.h |    3 +++
 3 files changed, 18 insertions(+)

diff --git a/block/blk-core.c b/block/blk-core.c
index 1f61b74..ca42fd7 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
< at >< at > -369,6 +369,9 < at >< at > void blk_drain_queue(struct request_queue *q, bool drain_all)
 if (drain_all)
 blk_throtl_drain(q);
 
+if (q->abort_queue_fn)
+q->abort_queue_fn(q);
+
 /*
  * This function might be called on a queue which failed
  * driver init after queue creation.  Some drivers
diff --git a/block/blk-settings.c b/block/blk-settings.c
index d3234fc..83ccb48 100644
--- a/block/blk-settings.c
+++ b/block/blk-settings.c
< at >< at > -100,6 +100,18 < at >< at > void blk_queue_lld_busy(struct request_queue *q, lld_busy_fn *fn)
 EXPORT_SYMBOL_GPL(blk_queue_lld_busy);
 
 /**
+ * blk_queue_abort_queue - set driver specific abort function
+ * < at >q:queue
+ * < at >mbfn:abort_queue_fn
+ */
+void blk_queue_abort_queue(struct request_queue *q, abort_queue_fn *afn)
+{
+q->abort_queue_fn = afn;
+}
+EXPORT_SYMBOL(blk_queue_abort_queue);
+
+
+/**
  * blk_set_default_limits - reset limits to default values
  * < at >lim:  the queue_limits structure to reset
  *
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index 2aa2466..e2d58bd 100644
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
< at >< at > -200,6 +200,7 < at >< at > struct request_pm_state
 
 typedef void (request_fn_proc) (struct request_queue *q);
 typedef void (make_request_fn) (struct request_queue *q, struct bio *bio);
+typedef void (abort_queue_fn) (struct request_queue *q);
 typedef int (prep_rq_fn) (struct request_queue *, struct request *);
 typedef void (unprep_rq_fn) (struct request_queue *, struct request *);
 
< at >< at > -282,6 +283,7 < at >< at > struct request_queue {
 
 request_fn_proc*request_fn;
 make_request_fn*make_request_fn;
+abort_queue_fn*abort_queue_fn;
 prep_rq_fn*prep_rq_fn;
 unprep_rq_fn*unprep_rq_fn;
 merge_bvec_fn*merge_bvec_fn;
< at >< at > -821,6 +823,7 < at >< at > extern struct request_queue *blk_init_allocated_queue(struct request_queue *,
       request_fn_proc *, spinlock_t *);
 extern void blk_cleanup_queue(struct request_queue *);
 extern void blk_queue_make_request(struct request_queue *, make_request_fn *);
+extern void blk_queue_abort_queue(struct request_queue *, abort_queue_fn *);
 extern void blk_queue_bounce_limit(struct request_queue *, u64);
 extern void blk_limits_max_hw_sectors(struct queue_limits *, unsigned int);
 extern void blk_queue_max_hw_sectors(struct request_queue *, unsigned int);

Call for Participation: ACM HPDC 2012 -- Early registration deadlineMay 25th

Ioan Raicu — 2012-05-19T13:47:00

    Call for Participation

http://www.hpdc.org/2012/

The organizing committee is delighted to invite you to *HPDC'12*, the 
/21st International ACM Symposium on High-Performance Parallel and 
Distributed Computing/, to be held in *Delft, the Netherlands*, which is 
a historic, picturesque city that is less than one hour away from 
Amsterdam-Schiphol airport.

HPDC <http://www.hpdc.org> is the premier annual conference on the 
design, the implementation, the evaluation, and the use of parallel and 
distributed systems for high-end computing. HPDC is sponsored by 
SIGARCH, the Special Interest Group on Computer Architecture 
<http://www.sigarch.org> of the Association for Computing Machinery 
<http://www.acm.org>.

*HPDC'12* will be held at Delft University of Technology 
<http://www.tudelft.nl>, with the main conference taking place on *June 
20-22* (Wednesday to Friday 1 PM), and with affiliated workshops on 
*June 18-19* (Monday and Tuesday).

Early registration closes on May 25th, so if you plan on attending, 
please register now at http://www.hpdc.org/2012/registration/.

*Some highlights of the conference:*

  * *Awards:*
      o Achievement Award - Ian Foster of the University of Chicago and
        Argonne National Laboratory, USA
  * *Keynote Speakers:*
      o Mihai Budiu of Microsoft Research, Mountain View, USA.
        Title: Putting "Big-data" to Good Use: Building Kinect
      o Ricardo Bianchini of Rutgers University, USA.
        Title: "Leveraging Renewable Energy in Data Centers: Present and
        Future"
  * *Accepted Papers:*
     1.       vSlicer: Latency-aware Virtual Machine Scheduling via
        Differentiated-frequency CPU Slicing, Cong Xu (Purdue
        University), Sahan Gamage (Purdue University), Pawan N. Rao
        (Purdue University), Ardalan Kangarlou (NetApp), Ramana Kompella
        (Purdue University), Dongyan Xu (Purdue University)
     2.       Singleton: System-wide Page Deduplication in Virtual
        Environments, Prateek Sharma, Purushottam Kulkarni (IIT Bombay)
     3.       Locality-aware Dynamic VM Reconfiguration on MapReduce
        Clouds, Jongse Park, Daewoo Lee, Bokyeong Kim, Jaehyuk Huh,
        Seungryoul Maeng (KAIST)
     4.       Achieving Application-Centric Performance Targets via
        Consolidation on Multicores: Myth or Reality?, Lydia Y. Chen
        Chen (IBM Research Zurich Lab), Danilo Ansaloni (University of
        Lugano), Evgenia Smirni (College of William and Mary), Akira
        Yokokawa (University of Lugano), Walter Binder (University of
        Lugano)
     5.       Enabling Event Tracing at Leadership-Class Scale through
        I/O Forwarding Middleware, Thomas Ilsche (Technische Universität
        Dresden), Joseph Schuchart (Technische Universität Dresden),
        Jason Cope (Argonne National Laboratory), Dries Kimpe (Argonne
        National Laboratory), Terry Jones (Oak Ridge National
        Laboratory), Andreas Knöpfer (Technische Universität Dresden),
        Kamil Iskra (Argonne National Laboratory), Robert Ross (Argonne
        National Laboratory), Wolfgang E. Nagel (Technische Universität
        Dresden), Stephen Poole (Oak Ridge National Laboratory)
     6.       ISOBAR Hybrid Compression-I/O Interleaving for Large-scale
        Parallel I/O Optimization, Eric R. Schendel (North Carolina
        State University), Saurabh V. Pendse (North Carolina State
        University), John Jenkins (North Carolina State University),
        David A. Boyuka (North Carolina State University), Zhenhuan Gong
        (North Carolina State University), Sriram Lakshminarasimhan
        (North Carolina State University), Qing Liu (Oak Ridge National
        Laboratory), Scott Klasky (Oak Ridge National Laboratory),
        Robert Ross (Argonne National Laboratory), Nagiza F. Samatova
        (North Carolina State University)
     7.       QBox: Guaranteeing I/O Performance on Black Box Storage
        Systems, Dimitris Skourtis, Shinpei Kato, Scott Brandt
        (University of California, Santa Cruz)
     8.       Towards Efficient Live Migration of I/O Intensive
        Workloads: A Transparent Storage Transfer Propo, Bogdan Nicolae
        (INRIA), Franck Cappello (INRIA/UIUC)
     9.       A Virtual Memory Based Runtime to Support Multi-tenancy in
        Clusters with GPUs, Michela Becchi (University of Missouri),
        Kittisak Sajjapongse (University of Missouri), Ian Graves
        (University of Missouri), Adam Procter (University of Missouri),
        Vignesh Ravi (Ohio State University), Srimat Chakradhar (NEC
        Laboratories America)
    10.       Interference-driven Scheduling and Resource Management for
        GPU-based Heterogeneous Clusters, Rajat Phull, Cheng-Hong Li,
        Kunal Rao, Hari Cadambi, Srimat Chakradhar (NEC Laboratories
        America)
    11.       Work Stealing and Persistence-based Load Balancers for
        Iterative Overdecomposed Applications, Jonathan Lifflander
        (UIUC), Sriram Krishnamoorthy (PNNL), Laxmikant V. Kale (UIUC)
    12.       Highly Scalable Graph Search for the Graph500 Benchmark,
        Koji Ueno (Tokyo Institute of Technology/JST CREST), Toyotaro
        Suzumura (Tokyo Institute of Technology/IBM Research Tokyo/JST
        CREST)
    13.       PonD : Dynamic Creation of HTC Pool on Demand Using a
        Decentralized Resource Discovery System, Kyungyong Lee
        (University of Florida), David Wolinsky (Yale University),
        Renato Figueiredo (University of Florida)
    14.       SpeQuloS: A QoS Service for BoT Applications Using Best
        Effort Distributed Computing Infrastructures, Simon Delamare
        (INRIA), Gilles Fedak (INRIA), Derrick Kondo (INRIA), Oleg
        Lodygensky (IN2P3)
    15.       Understanding the Effects and Implications of Compute Node
        Related Failures in Hadoop, Florin Dinu, T. S. Eugene Ng (Rice
        University)
    16.       Optimizing MapReduce for GPUs with Effective Shared Memory
        Usage, Linchuan Chen, Gagan Agrawal (The Ohio State University)
    17.       CAM: A Topology Aware Minimum Cost Flow Based Resource
        Manager for MapReduce Applications in the Cloud, Min Li
        (Virginia Tech), Dinesh Subhraveti (IBM Almaden Research
        Center), Ali Butt (Virginia Tech), Aleksandr Khasymski (Virginia
        Tech), Prasenjit Sarkar (IBM Almaden Research Center)
    18.       Distributed Approximate Spectral Clustering for
        Large-Scale Datasets, Fei Gao (Simon Fraser University), Wael
        Abd-Almageed (University of Maryland)
    19.       Exploring Cross-layer Power Management for PGAS
        Applications on the SCC Platform, Marc Gamell (Rutgers
        University), Ivan Rodero (Rutgers University), Manish Parashar
        (Rutgers University), Rajeev Muralidhar (Intel India)
    20.       Dynamic Adaptive Virtual Core Mapping to Improve Power,
        Energy, and Performance in Multi-socket Multicores, Chang Bae
        (Northwestern University), Lei Xia (Northwestern University),
        Peter Dinda (Northwestern University), John Lange (University of
        Pittsburgh)
    21.       VNET/P: Bridging the Cloud and High Performance Computing
        Through Fast Overlay Networking, Lei Xia (Northwestern
        University), Zheng Cui (University of New Mexico), John Lange
        (University of Pittsburgh), Yuan Tang (UESTC, China), Peter
        Dinda (Northwestern University), Patrick Bridges (University of
        New Mexico)
    22.       Massively-Parallel Stream Processing under QoS Constraints
        with Nephele, Björn Lohrmann, Daniel Warneke, Odej Kao
        (Technische Universität Berlin)
    23.       A Resiliency Model for High Performance Infrastructure
        Based on Logical Encapsulation, James Moore (The University of
        Southern California/EMC Corporation), Carl Kesselman (The
        University of Southern California)

  * *Workshops:*
      o Astro-HPC: Workshop on High-Performance Computing for Astronomy,
        Ana Lucia Varbanescu, Rob van Nieuwpoort, and Simon Portegies Zwart
      o ECMLS: 3rd Int'l Emerging Computational Methods for the Life
        Sciences Workshop, Carole Goble, Judy Qiu, and Ian Foster
      o ScienceCloud: 3rd Workshop on Scientific Cloud Computing, Yogesh
        Simmhan, Gabriel Antoniu, and Carole Goble
      o DIDC: Fifth Int'l Workshop on Data-Intensive Distributed
        Computing, Tevfik Kosar and Douglas Thain
      o MapReduce: The Third Int'l Workshop on MapReduce and its
        Applications, Gilles Fedak and Geoffrey Fox
      o VTDC: 6th Int'l Workshop on Virtualization Technologies in
        Distributed Computing, Frédéric Desprez and Adrien Lèbre

For more information on the full program, see 
http://www.hpdc.org/2012/program/conference-program/.

Looking forward to seeing you in Delft!

Regards,
Ioan Raicu

MBDS paper submission due in one month (The International Workshop onManagement of Big Data Systems)

Ming Zhao — 2012-05-19T00:44:40

CALL FOR PAPERS

International Workshop on Management of Big Data Systems (MBDS 2012)
http://www.cercs.gatech.edu/mbds12

In conjunction with ICAC 2012
http://icac2012.cs.fiu.edu

September 21, 2012, San Jose, CA

-----------------------------------------------------------------

IMPORTANT DATES

Paper submission due:  June 15, 2012
Author notification:   July 30, 2012
Workshop:              Sep 21, 2012

-----------------------------------------------------------------

OVERVIEW

Data is growing at an exponential rate and several systems have emerged 
to store and analyze such large amounts of data. These systems, termed 
Big data systems are fast evolving Examples include the NoSQL storage 
systems, Hadoop Map-Reduce, data analytics platforms, search and indexing 
platforms, and messaging infrastructures. These systems address needs for 
structured and unstructured data across a wide spectrum of domains such 
as web, social networks, enterprise, cloud, mobile, sensor networks, 
multimedia/streaming, cyberphysical and high performance systems, and 
for multiple application verticals such as biosciences, healthcare, 
transportation, public sector, energy utilities, oil & gas, and scientific 
computing. 

With increasing scale and complexity, managing these big data systems to 
cope with failures and performance problems is becoming non-trivial. 
New resource management and scheduling mechanisms are also needed for such 
systems, and so are mechanisms for tuning and support from platform layers. 
Several open source and proprietary solutions have been proposed to address 
these requirements, with extensive contributions from industry and academia. 
However, there remain substantial challenges, including those that pertain 
to such systems autonomic and self-management capabilities.

The objective of the MBDS workshop is to bring together researchers, 
practitioners, system administrators, system programmers, and others 
interested in sharing and presenting their perspectives on the effective 
management of big data systems. The focus of the workshop is on novel and 
practical, systems-oriented work. MBDS offers an opportunity for researchers 
and practitioners from industry, academia, and national labs to showcase the 
latest advances in this area and to also discuss and identify future directions 
and challenges in all aspects on autonomic management of big data systems.

Papers are solicited on all aspects of big data management. Specific topics 
of interest include, but are not limited, to the following:

* Autonomic and self-managing techniques

* Application-level resource management and scheduling mechanisms

* System tuning/auto-tuning and configuration management

* Performance management, fault management, and power management

* Scalability challenges

* Complexity challenges, as for composite, cross-tier systems with multiple control loops

* Unified management of data in motion and data at rest

* Dealing with both structured and unstructured data

* Monitoring, diagnosis, and automated behaviour detection

* System-level principles and support for resource management 

* Holistic management across hardware and software

* Implications of emerging hardware technologies such as non-volatile memory

* Domain specific challenges in web, cloud, social networks, mobile, sensor networks, 
  streaming analytics, cyber-physical systems

* System building and experience papers for specific industry verticals

-----------------------------------------------------------------

PAPER SUBMISSIONS

Full papers (a maximum of 6 pages in the two-column ACM proceedings 
format) are invited on a wide variety of topics relating to management of big
data systems. Submitted papers must be original work, and may not be under 
consideration for another conference or journal. Complete formatting and 
submission instructions can be found on the workshop web site. Accepted 
papers will appear in proceedings distributed at the conference and available 
electronically. 

-----------------------------------------------------------------

WORKSHOP ORGANIZERS

Karsten Schwan, Georgia Tech
Vanish Talwar, HP Labs

PUBLICITY CHAIR

Aravind Menon, Facebook

PROGRAM COMMITTEE

Amitanand Aiyer, Facebook
Adhyas Avasthi, Nokia Research
Milind Bhandarkar, Greenplum Labs, EMC
Randal Burns, John Hopkins University
Garth Gibson, Carnegie Mellon University and Panasas Inc.
Herodotos Herodotou, Duke University
Michael A Kozuch, Intel
Kai Li, Princeton University
Mohamed Mansour, Amazon
Aravind Menon, Facebook
Arif Merchant, Google
Beth Plale, Indiana University
Indrajit Roy, HP Labs
Gabor Szabo, Twitter
Craig Ulmer, Sandia National Lab
Kushagra Vaid, Microsoft
Weikuan Yu, Auburn University
Philip Zeyliger, Cloudera

[PULL] virtio: last minute fixes for 3.4

Michael S. Tsirkin — 2012-05-17T09:35:39

The following changes since commit 0e93b4b304ae052ba1bc73f6d34a68556fe93429:

  Merge git://git.kernel.org/pub/scm/virt/kvm/kvm (2012-05-16 14:30:51 -0700)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git for_linus

for you to fetch changes up to ec13ee80145ccb95b00e6e610044bbd94a170051:

  virtio_net: invoke softirqs after __napi_schedule (2012-05-17 12:16:38 +0300)

----------------------------------------------------------------
virtio: last minute fixes for 3.4

Here are a couple of last minute virtio fixes for 3.4.
Hope it's not too late yes - I might have tried too hard
to make sure the fix is well tested.

Fixes are by Amit and myself. One fixes module removal
and one suspend of a VM, the last one the handling of out
of memory condition.
They are thus very low risk as most people never hit these paths, but do fix
very annoying problems for people that do use the feature.

Signed-off-by: Michael S. Tsirkin <mst< at >redhat.com>

----------------------------------------------------------------
Amit Shah (2):
      virtio: console: tell host of open ports after resume from s3/s4
      virtio: balloon: let host know of updated balloon size before module removal

Michael S. Tsirkin (1):
      virtio_net: invoke softirqs after __napi_schedule

 drivers/char/virtio_console.c   |    7 +++++++
 drivers/net/virtio_net.c        |    2 ++
 drivers/virtio/virtio_balloon.c |    1 +
 3 files changed, 10 insertions(+), 0 deletions(-)

[vmw_vmci RFC 00/11] VMCI for Linux

Andrew Stiegmann (stieg — 2012-05-15T15:06:57

In an effort to improve the out-of-the-box experience with Linux
kernels for VMware users, VMware is working on readying the Virtual
Machine Communication Interface (vmw_vmci) and VMCI Sockets (vmw_vsock) kernel
modules for inclusion in the Linux kernel. The purpose of this post
is to acquire feedback on the vmw_vmci kernel module. The vmw_vsock
kernel module will be presented in a later post.

VMCI allows virtual machines to communicate with host kernel modules
and the VMware hypervisors. User level applications both in a virtual
machine and on the host can use vmw_vmci through VMCI Sockets, a socket
address family designed to be compatible with UDP and TCP at the
interface level. Today, VMCI and VMCI Sockets are used by the VMware
shared folders (HGFS) and various VMware Tools components inside the
guest for zero-config, network-less access to VMware host services. In
addition to this, VMware's users are using VMCI Sockets for various
applications, where network access of the virtual machine is
restricted or non-existent. Examples of this are VMs communicating
with device proxies for proprietary hardware running as host
applications and automated testing of applications running within
virtual machines.

In a virtual machine, VMCI is exposed as a regular PCI device. The
primary communication mechanisms supported are a point-to-point
bidirectional transport based on a pair of memory-mapped queues, and
asynchronous notifications in the form of datagrams and
doorbells. These features are available to kernel level components
such as HGFS and VMCI Sockets through the VMCI kernel API. In addition
to this, the VMCI kernel API provides support for receiving events
related to the state of the VMCI communication channels, and the
virtual machine itself.

Outside the virtual machine, the host side support of the VMCI kernel
module makes the same VMCI kernel API available to VMCI endpoints on
the host. In addition to this, the host side manages each VMCI device
in a virtual machine through a context object. This context object
serves to identify the virtual machine for communication, and to track
the resource consumption of the given VMCI device. Both operations
related to communication between the virtual machine and the host
kernel, and those related to the management of the VMCI device state
in the host kernel, are invoked by the user level component of the
hypervisor through a set of ioctls on the VMCI device node.  To
provide seamless support for nested virtualization, where a virtual
machine may use both a VMCI PCI device to talk to its hypervisor, and
the VMCI host side support to run nested virtual machines, the VMCI
host and virtual machine support are combined in a single kernel
module.

For additional information about the use of VMCI and in particular
VMCI Sockets, please refer to the VMCI Socket Programming Guide
available at https://www.vmware.com/support/developer/vmci-sdk/.

Andrew Stiegmann (stieg) (11):
  Apply VMCI context code
  Apply VMCI datagram code
  Apply VMCI doorbell code
  Apply VMCI driver code
  Apply VMCI event code
  Apply dynamic array code
  Apply VMCI hash table
  Apply VMCI queue pairs
  Apply VMCI resource code
  Apply vmci routing code
  Apply the header code to make VMCI build

 drivers/misc/Kconfig                      |    1 +
 drivers/misc/Makefile                     |    1 +
 drivers/misc/vmw_vmci/Kconfig             |   16 +
 drivers/misc/vmw_vmci/Makefile            |   43 +
 drivers/misc/vmw_vmci/vmci_common_int.h   |   72 +
 drivers/misc/vmw_vmci/vmci_context.c      | 1743 +++++++++++
 drivers/misc/vmw_vmci/vmci_context.h      |  150 +
 drivers/misc/vmw_vmci/vmci_datagram.c     |  760 +++++
 drivers/misc/vmw_vmci/vmci_datagram.h     |   57 +
 drivers/misc/vmw_vmci/vmci_doorbell.c     |  989 +++++++
 drivers/misc/vmw_vmci/vmci_doorbell.h     |   57 +
 drivers/misc/vmw_vmci/vmci_driver.c       | 2875 ++++++++++++++++++
 drivers/misc/vmw_vmci/vmci_driver.h       |   52 +
 drivers/misc/vmw_vmci/vmci_event.c        |  614 ++++
 drivers/misc/vmw_vmci/vmci_event.h        |   29 +
 drivers/misc/vmw_vmci/vmci_handle_array.c |  300 ++
 drivers/misc/vmw_vmci/vmci_handle_array.h |   50 +
 drivers/misc/vmw_vmci/vmci_hash_table.c   |  494 ++++
 drivers/misc/vmw_vmci/vmci_hash_table.h   |   56 +
 drivers/misc/vmw_vmci/vmci_queue_pair.c   | 4517 +++++++++++++++++++++++++++++
 drivers/misc/vmw_vmci/vmci_queue_pair.h   |  258 ++
 drivers/misc/vmw_vmci/vmci_resource.c     |  320 ++
 drivers/misc/vmw_vmci/vmci_resource.h     |   61 +
 drivers/misc/vmw_vmci/vmci_route.c        |  234 ++
 drivers/misc/vmw_vmci/vmci_route.h        |   34 +
 include/linux/vmw_vmci_api.h              |  103 +
 include/linux/vmw_vmci_defs.h             | 1003 +++++++
 27 files changed, 14889 insertions(+), 0 deletions(-)
 create mode 100644 drivers/misc/vmw_vmci/Kconfig
 create mode 100644 drivers/misc/vmw_vmci/Makefile
 create mode 100644 drivers/misc/vmw_vmci/vmci_common_int.h
 create mode 100644 drivers/misc/vmw_vmci/vmci_context.c
 create mode 100644 drivers/misc/vmw_vmci/vmci_context.h
 create mode 100644 drivers/misc/vmw_vmci/vmci_datagram.c
 create mode 100644 drivers/misc/vmw_vmci/vmci_datagram.h
 create mode 100644 drivers/misc/vmw_vmci/vmci_doorbell.c
 create mode 100644 drivers/misc/vmw_vmci/vmci_doorbell.h
 create mode 100644 drivers/misc/vmw_vmci/vmci_driver.c
 create mode 100644 drivers/misc/vmw_vmci/vmci_driver.h
 create mode 100644 drivers/misc/vmw_vmci/vmci_event.c
 create mode 100644 drivers/misc/vmw_vmci/vmci_event.h
 create mode 100644 drivers/misc/vmw_vmci/vmci_handle_array.c
 create mode 100644 drivers/misc/vmw_vmci/vmci_handle_array.h
 create mode 100644 drivers/misc/vmw_vmci/vmci_hash_table.c
 create mode 100644 drivers/misc/vmw_vmci/vmci_hash_table.h
 create mode 100644 drivers/misc/vmw_vmci/vmci_queue_pair.c
 create mode 100644 drivers/misc/vmw_vmci/vmci_queue_pair.h
 create mode 100644 drivers/misc/vmw_vmci/vmci_resource.c
 create mode 100644 drivers/misc/vmw_vmci/vmci_resource.h
 create mode 100644 drivers/misc/vmw_vmci/vmci_route.c
 create mode 100644 drivers/misc/vmw_vmci/vmci_route.h
 create mode 100644 include/linux/vmw_vmci_api.h
 create mode 100644 include/linux/vmw_vmci_defs.h

[PATCH] virtio_net: invoke softirqs after __napi_schedule

Michael S. Tsirkin — 2012-05-16T07:57:13

__napi_schedule might raise softirq but nothing
causes do_softirq to trigger, so it does not in fact
run. As a result,
the error message "NOHZ: local_softirq_pending 08"
sometimes occurs during boot of a KVM guest when the network service is
started and we are oom:

  ...
  Bringing up loopback interface:  [  OK  ]
  Bringing up interface eth0:
  Determining IP information for eth0...NOHZ: local_softirq_pending 08
   done.
  [  OK  ]
  ...

Further, receive queue processing might get delayed
indefinitely until some interrupt triggers:
virtio_net expected napi to be run immediately.

One way to cause do_softirq to be executed is by
invoking local_bh_enable(). As __napi_schedule is
normally called from bh or irq context, this
seems to make sense: disable bh before __napi_schedule
and enable afterwards.

Reported-by: Ulrich Obergfell <uobergfe< at >redhat.com>
Tested-by: Ulrich Obergfell <uobergfe< at >redhat.com>
Signed-off-by: Michael S. Tsirkin <mst< at >redhat.com>
---

To test, one can hack try_fill_recv to always report oom.
I'm not sure it's not too late for 3.4, but we can try.
Rusty, could you review ASAP pls?

 drivers/net/virtio_net.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index af8acc8..cbefe67 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
< at >< at > -492,7 +492,9 < at >< at > static void virtnet_napi_enable(struct virtnet_info *vi)
  * We synchronize against interrupts via NAPI_STATE_SCHED */
 if (napi_schedule_prep(&vi->napi)) {
 virtqueue_disable_cb(vi->rvq);
+local_bh_disable();
 __napi_schedule(&vi->napi);
+local_bh_enable();
 }
 }

[PATCH] virtio-mmio: Devices parameter parsing

Pawel Moll — 2012-05-09T17:30:16

This patch adds an option to instantiate guest virtio-mmio devices
basing on a kernel command line (or module) parameter, for example:

virtio_mmio.devices=0x100< at >0x100b0000:48

Signed-off-by: Pawel Moll <pawel.moll< at >arm.com>
---

Hi Rusty,

As the param changes are in now, could you queue this
long-time-forgotten patch for 3.5?

Cheers!

Pawel

PS. Congratulations once again and see you in HK.

 Documentation/kernel-parameters.txt |   17 ++++
 drivers/virtio/Kconfig              |   11 +++
 drivers/virtio/virtio_mmio.c        |  163 +++++++++++++++++++++++++++++++++++
 3 files changed, 191 insertions(+), 0 deletions(-)

diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index c1601e5..8b35051 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
< at >< at > -110,6 +110,7 < at >< at > parameter is applicable:
 USBUSB support is enabled.
 USBHIDUSB Human Interface Device support is enabled.
 V4LVideo For Linux support is enabled.
+VMMIO   Driver for memory mapped virtio devices is enabled.
 VGAThe VGA console has been enabled.
 VTVirtual terminal support is enabled.
 WDTWatchdog support is enabled.
< at >< at > -2847,6 +2848,22 < at >< at > bytes respectively. Such letter suffixes can also be entirely omitted.
 video=[FB] Frame buffer configuration
 See Documentation/fb/modedb.txt.
 
+virtio_mmio.device=
+[VMMIO] Memory mapped virtio (platform) device.
+
+<size>< at ><baseaddr>:<irq>[:<id>]
+where:
+<size>     := size (can use standard suffixes
+like K, M and G)
+<baseaddr> := physical base address
+<irq>      := interrupt number (as passed to
+request_irq())
+<id>       := (optional) platform device id
+example:
+virtio_mmio.device=1K< at >0x100b0000:48:7
+
+Can be used multiple times for multiple devices.
+
 vga=[BOOT,X86-32] Select a particular video mode
 See Documentation/x86/boot.txt and
 Documentation/svga.txt.
diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig
index 1a61939..f38b17a 100644
--- a/drivers/virtio/Kconfig
+++ b/drivers/virtio/Kconfig
< at >< at > -46,4 +46,15 < at >< at > config VIRTIO_BALLOON
 
   If unsure, say N.
 
+config VIRTIO_MMIO_CMDLINE_DEVICES
+bool "Memory mapped virtio devices parameter parsing"
+depends on VIRTIO_MMIO
+---help---
+ Allow virtio-mmio devices instantiation via the kernel command line
+ or module parameters. Be aware that using incorrect parameters (base
+ address in particular) can crash your system - you have been warned.
+ See Documentation/kernel-parameters.txt for details.
+
+ If unsure, say 'N'.
+
 endmenu
diff --git a/drivers/virtio/virtio_mmio.c b/drivers/virtio/virtio_mmio.c
index 01d6dc2..453db0c 100644
--- a/drivers/virtio/virtio_mmio.c
+++ b/drivers/virtio/virtio_mmio.c
< at >< at > -6,6 +6,50 < at >< at >
  * This module allows virtio devices to be used over a virtual, memory mapped
  * platform device.
  *
+ * The guest device(s) may be instantiated in one of three equivalent ways:
+ *
+ * 1. Static platform device in board's code, eg.:
+ *
+ *static struct platform_device v2m_virtio_device = {
+ *.name = "virtio-mmio",
+ *.id = -1,
+ *.num_resources = 2,
+ *.resource = (struct resource []) {
+ *{
+ *.start = 0x1001e000,
+ *.end = 0x1001e0ff,
+ *.flags = IORESOURCE_MEM,
+ *}, {
+ *.start = 42 + 32,
+ *.end = 42 + 32,
+ *.flags = IORESOURCE_IRQ,
+ *},
+ *}
+ *};
+ *
+ * 2. Device Tree node, eg.:
+ *
+ *virtio_block< at >1e000 {
+ *compatible = "virtio,mmio";
+ *reg = <0x1e000 0x100>;
+ *interrupts = <42>;
+ *}
+ *
+ * 3. Kernel module (or command line) parameter. Can be used more than once -
+ *    one device will be created for each one. Syntax:
+ *
+ *[virtio_mmio.]device=<size>< at ><baseaddr>:<irq>[:<id>]
+ *    where:
+ *<size>     := size (can use standard suffixes like K, M or G)
+ *<baseaddr> := physical base address
+ *<irq>      := interrupt number (as passed to request_irq())
+ *<id>       := (optional) platform device id
+ *    eg.:
+ *virtio_mmio.device=0x100< at >0x100b0000:48 \
+ *virtio_mmio.device=1K< at >0x1001e000:74
+ *
+ *
+ *
  * Registers layout (all 32-bit wide):
  *
  * offset d. name             description
< at >< at > -42,6 +86,8 < at >< at >
  * See the COPYING file in the top-level directory.
  */
 
+#define pr_fmt(fmt) "virtio-mmio: " fmt
+
 #include <linux/highmem.h>
 #include <linux/interrupt.h>
 #include <linux/io.h>
< at >< at > -449,6 +495,122 < at >< at > static int __devexit virtio_mmio_remove(struct platform_device *pdev)
 
 
 
+/* Devices list parameter */
+
+#if defined(CONFIG_VIRTIO_MMIO_CMDLINE_DEVICES)
+
+static struct device vm_cmdline_parent = {
+.init_name = "virtio-mmio-cmdline",
+};
+
+static int vm_cmdline_parent_registered;
+static int vm_cmdline_id;
+
+static int vm_cmdline_set(const char *device,
+const struct kernel_param *kp)
+{
+int err;
+struct resource resources[2] = {};
+char *str;
+long long int base;
+int processed, consumed = 0;
+struct platform_device *pdev;
+
+resources[0].flags = IORESOURCE_MEM;
+resources[1].flags = IORESOURCE_IRQ;
+
+resources[0].end = memparse(device, &str) - 1;
+
+processed = sscanf(str, "< at >%lli:%u%n:%d%n",
+&base, &resources[1].start, &consumed,
+&vm_cmdline_id, &consumed);
+
+if (processed < 2 || processed > 3 || str[consumed])
+return -EINVAL;
+
+resources[0].start = base;
+resources[0].end += base;
+resources[1].end = resources[1].start;
+
+if (!vm_cmdline_parent_registered) {
+err = device_register(&vm_cmdline_parent);
+if (err) {
+pr_err("Failed to register parent device!\n");
+return err;
+}
+vm_cmdline_parent_registered = 1;
+}
+
+pr_info("Registering device virtio-mmio.%d at 0x%llx-0x%llx, IRQ %d.\n",
+       vm_cmdline_id,
+       (unsigned long long)resources[0].start,
+       (unsigned long long)resources[0].end,
+       (int)resources[1].start);
+
+pdev = platform_device_register_resndata(&vm_cmdline_parent,
+"virtio-mmio", vm_cmdline_id++,
+resources, ARRAY_SIZE(resources), NULL, 0);
+if (IS_ERR(pdev))
+return PTR_ERR(pdev);
+
+return 0;
+}
+
+static int vm_cmdline_get_device(struct device *dev, void *data)
+{
+char *buffer = data;
+unsigned int len = strlen(buffer);
+struct platform_device *pdev = to_platform_device(dev);
+
+snprintf(buffer + len, PAGE_SIZE - len, "0x%llx< at >0x%llx:%llu:%d\n",
+pdev->resource[0].end - pdev->resource[0].start + 1ULL,
+(unsigned long long)pdev->resource[0].start,
+(unsigned long long)pdev->resource[1].start,
+pdev->id);
+return 0;
+}
+
+static int vm_cmdline_get(char *buffer, const struct kernel_param *kp)
+{
+buffer[0] = '\0';
+device_for_each_child(&vm_cmdline_parent, buffer,
+vm_cmdline_get_device);
+return strlen(buffer) + 1;
+}
+
+static struct kernel_param_ops vm_cmdline_param_ops = {
+.set = vm_cmdline_set,
+.get = vm_cmdline_get,
+};
+
+device_param_cb(device, &vm_cmdline_param_ops, NULL, S_IRUSR);
+
+static int vm_unregister_cmdline_device(struct device *dev,
+void *data)
+{
+platform_device_unregister(to_platform_device(dev));
+
+return 0;
+}
+
+static void vm_unregister_cmdline_devices(void)
+{
+if (vm_cmdline_parent_registered) {
+device_for_each_child(&vm_cmdline_parent, NULL,
+vm_unregister_cmdline_device);
+device_unregister(&vm_cmdline_parent);
+vm_cmdline_parent_registered = 0;
+}
+}
+
+#else
+
+static void vm_unregister_cmdline_devices(void)
+{
+}
+
+#endif
+
 /* Platform driver */
 
 static struct of_device_id virtio_mmio_match[] = {
< at >< at > -475,6 +637,7 < at >< at > static int __init virtio_mmio_init(void)
 static void __exit virtio_mmio_exit(void)
 {
 platform_driver_unregister(&virtio_mmio_driver);
+vm_unregister_cmdline_devices();
 }
 
 module_init(virtio_mmio_init);

virtio 3.4 patches

Michael S. Tsirkin — 2012-05-07T05:30:21

Hi Rusty, please also pick two fixes from for_linus tag on my tree
I think they should be sent to Linus for 3.4:

http://git.kernel.org/?p=linux/kernel/git/mst/vhost.git;a=tag;h=refs/tags/for_linus

git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git refs/tags/for_linus

Submission Deadline Extension

VHPC 12 — 2012-05-06T17:32:30

we apologize if you receive multiple copies of this CFP

===================================================================

CALL FOR PAPERS

7th Workshop on

Virtualization in High-Performance Cloud Computing

VHPC '12

as part of Euro-Par 2012, Rhodes Island, Greece

===================================================================

Date: August 28, 2012

Workshop URL: http://vhpc.org

SUBMISSION DEADLINE:

June 11, 2012 - Full paper submission (extended)


SCOPE:

Virtualization has become a common abstraction layer in modern
data centers, enabling resource owners to manage complex
infrastructure independently of their applications. Conjointly,
virtualization is becoming a driving technology for a manifold of
industry grade IT services. The cloud concept includes the notion
of a separation between resource owners and users, adding  services
such as hosted application frameworks and queueing. Utilizing the
same infrastructure, clouds carry significant potential for use in
high-performance scientific computing. The ability of clouds to provide
for requests and releases of vast computing resources dynamically and
close to the marginal cost of providing the services is unprecedented in
the history of scientific and commercial computing.

Distributed computing concepts that leverage federated resource
access are popular within the grid community, but have not seen
previously desired deployed levels so far. Also, many of the scientific
data centers have not adopted virtualization or cloud concepts yet.

This workshop aims to bring together industrial providers with the
scientific community in order to foster discussion, collaboration
and mutual exchange of knowledge and experience.

The workshop will be one day in length, composed of 20 min
paper presentations, each followed by 10 min discussion sections.
Presentations may be accompanied by interactive demonstrations.


TOPICS

Topics of interest include, but are not limited to:

Higher-level cloud architectures, focusing on issues such as:
- Languages for describing highly-distributed compute jobs
- Workload characterization for VM-based environments
- Optimized communication libraries/protocols in the cloud
- Cross-layer optimization of numeric algorithms on VM infrastructure
- System and process/bytecode VM convergence
- Cloud frameworks and API sets
- Checkpointing/migration of large compute jobs
- Instrumentation interfaces and languages
- VMM performance (auto-)tuning on various load types
- Cloud reliability, fault-tolerance, and security
- Software as a Service (SaaS) architectures
- Research and education use cases
- Virtualization in cloud, cluster and grid environments
- Cross-layer VM optimizations
- Cloud use cases including optimizations
- VM-based cloud performance modelling
- Performance and cost modelling

Lower-level design challenges for Hypervisors, VM-aware I/O devices,
hardware accelerators or filesystems in VM environments, especially:
- Cloud, grid and distributed filesystems
- Hardware for I/O virtualization (storage/network/accelerators)
- Storage and network I/O subsystems in virtualized environments
- Novel software approaches to I/O virtualization
- Paravirtualized I/O subsystems for modified/unmodified guests
- Virtualization-aware cluster interconnects
- Direct device assignment
- NUMA-aware subsystems in virtualized environments
- Hardware Accelerators in virtualization (GPUs/FPGAs)
- Hardware extensions for virtualization
- VMMs/Hypervisors for embedded systems

Data Center management methods, including:
- QoS and and service levels
- VM cloud and cluster distribution algorithms
- VM load-balancing in Clouds
- Hypervisor extensions and tools for cluster and grid computing
- Fault tolerant VM environments
- Virtual machine monitor platforms
- Management, deployment and monitoring of VM-based environments
- Cluster provisioning in the Cloud


PAPER SUBMISSION

Papers submitted to the workshop will be reviewed by at least two
members of the program committee and external reviewers. Submissions
should include abstract, key words, the e-mail address of the
corresponding author, and must not exceed 10 pages, including tables
and figures at a main font size no smaller than 11 point. Submission
of a paper should be regarded as a commitment that, should the paper
be accepted, at least one of the authors will register and attend the
conference to present the work.

Accepted papers will be published in the Springer LNCS series - the
format must be according to the Springer LNCS Style. Initial
submissions are in PDF; authors of accepted papers will be requested
to provide source files.

Format Guidelines: http://www.springer.de/comp/lncs/authors.html
Style template:
ftp://ftp.springer.de/pub/tex/latex/llncs/latex2e/llncs2e.zip
Abstract Submission Link: http://edas.info/newPaper.php?c=11943


IMPORTANT DATES

Rolling abstract submission
June 11, 2012 - Full paper submission (extended)
June 29, 2012 - Acceptance notification
July 20, 2012 - Camera-ready version due
August 28, 2012 - Workshop Date


CHAIR

Michael Alexander (chair), TU Wien, Austria
Gianluigi Zanetti (co-chair), CRS4, Italy
Anastassios Nanos (co-chair), NTUA, Greece


PROGRAM COMMITTEE

Paolo Anedda, CRS4, Italy
Giovanni Busonera, CRS4, Italy
Brad Calder, Microsoft, USA
Roberto Canonico, University of Napoli Federico II, Italy
Tommaso Cucinotta, Alcatel-Lucent Bell Labs, Ireland
Werner Fischer, Thomas-Krenn AG, Germany
William Gardner, University of Guelph, USA
Marcus Hardt, Forschungszentrum Karlsruhe, Germany
Sverre Jarp, CERN, Switzerland
Shantenu Jha, Louisiana State University, USA
Xuxian Jiang, NC State, USA
Nectarios Koziris, National Technical University of Athens, Greece
Simone Leo, CRS4, Italy
Ignacio Llorente, Universidad Complutense de Madrid, Spain
Naoya Maruyama, Tokyo Institute of Technology, Japan
Jean-Marc Menaud, Ecole des Mines de Nantes, France
Dimitrios Nikolopoulos, Foundation for Research&Technology Hellas, Greece
Jose Renato Santos, HP Labs, USA
Walter Schwaiger, TU Wien, Austria
Yoshio Turner, HP Labs, USA
Kurt Tutschku, University of Vienna, Austria
Lizhe Wang, Indiana University, USA
Chao-Tung Yang, Tunghai University, Taiwan


DURATION: Workshop Duration is one day.


GENERAL INFORMATION

The workshop will be held as part of Euro-Par 2012.

Euro-Par 2012: http://europar2012.cti.gr/

[PATCH v3] virtio-blk: Fix hot-unplug race in remove method

Asias He — 2012-05-04T12:22:04

If we reset the virtio-blk device before the requests already dispatched
to the virtio-blk driver from the block layer are finised, we will stuck
in blk_cleanup_queue() and the remove will fail.

blk_cleanup_queue() calls blk_drain_queue() to drain all requests queued
before DEAD marking. However it will never success if the device is
already stopped. We'll have q->in_flight[] > 0, so the drain will not
finish.

How to reproduce the race:
1. hot-plug a virtio-blk device
2. keep reading/writing the device in guest
3. hot-unplug while the device is busy serving I/O

Test:
~1000 rounds of hot-plug/hot-unplug test passed with this patch.

Changes in v3:
- Drop blk_abort_queue and blk_abort_request
- Use __blk_end_request_all to complete request dispatched to driver

Changes in v2:
- Drop req_in_flight
- Use virtqueue_detach_unused_buf to get request dispatched to driver

Signed-off-by: Asias He <asias< at >redhat.com>
---
 drivers/block/virtio_blk.c |   11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
index 72fe55d..693187d 100644
--- a/drivers/block/virtio_blk.c
+++ b/drivers/block/virtio_blk.c
< at >< at > -576,6 +576,8 < at >< at > static void __devexit virtblk_remove(struct virtio_device *vdev)
 {
 struct virtio_blk *vblk = vdev->priv;
 int index = vblk->index;
+struct virtblk_req *vbr;
+unsigned long flags;
 
 /* Prevent config work handler from accessing the device. */
 mutex_lock(&vblk->config_lock);
< at >< at > -588,6 +590,15 < at >< at > static void __devexit virtblk_remove(struct virtio_device *vdev)
 flush_work(&vblk->config_work);
 
 del_gendisk(vblk->disk);
+
+/* Abort requests dispatched to driver. */
+spin_lock_irqsave(&vblk->lock, flags);
+while ((vbr = virtqueue_detach_unused_buf(vblk->vq))) {
+__blk_end_request_all(vbr->req, -EIO);
+mempool_free(vbr, vblk->pool);
+}
+spin_unlock_irqrestore(&vblk->lock, flags);
+
 blk_cleanup_queue(vblk->disk->queue);
 put_disk(vblk->disk);
 mempool_destroy(vblk->pool);

[PATCH v3] virtio-blk: Fix hot-unplug race in remove method

Asias He — 2012-05-04T08:39:49

If we reset the virtio-blk device before the requests already dispatched
to the virtio-blk driver from the block layer are finised, we will stuck
in blk_cleanup_queue() and the remove will fail.

blk_cleanup_queue() calls blk_drain_queue() to drain all requests queued
before DEAD marking. However it will never success if the device is
already stopped. We'll have q->in_flight[] > 0, so the drain will not
finish.

How to reproduce the race:
1. hot-plug a virtio-blk device
2. keep reading/writing the device in guest
3. hot-unplug while the device is busy serving I/O

Test:
~1000 rounds of hot-plug/hot-unplug test passed with this patch.

Changes in v3:
- Drop blk_abort_queue and blk_abort_request
- Use __blk_end_request_all to complete request dispatched to driver

Changes in v2:
- Drop req_in_flight
- Use virtqueue_detach_unused_buf to get request dispatched to driver

Signed-off-by: Asias He <asias< at >redhat.com>
---
 drivers/block/virtio_blk.c |   11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
index 72fe55d..693187d 100644
--- a/drivers/block/virtio_blk.c
+++ b/drivers/block/virtio_blk.c
< at >< at > -576,6 +576,8 < at >< at > static void __devexit virtblk_remove(struct virtio_device *vdev)
 {
 struct virtio_blk *vblk = vdev->priv;
 int index = vblk->index;
+struct virtblk_req *vbr;
+unsigned long flags;
 
 /* Prevent config work handler from accessing the device. */
 mutex_lock(&vblk->config_lock);
< at >< at > -588,6 +590,15 < at >< at > static void __devexit virtblk_remove(struct virtio_device *vdev)
 flush_work(&vblk->config_work);
 
 del_gendisk(vblk->disk);
+
+/* Abort requests dispatched to driver. */
+spin_lock_irqsave(&vblk->lock, flags);
+while ((vbr = virtqueue_detach_unused_buf(vblk->vq))) {
+__blk_end_request_all(vbr->req, -EIO);
+mempool_free(vbr, vblk->pool);
+}
+spin_unlock_irqrestore(&vblk->lock, flags);
+
 blk_cleanup_queue(vblk->disk->queue);
 put_disk(vblk->disk);
 mempool_destroy(vblk->pool);

[PATCH v2] virtio-blk: Fix hot-unplug race in remove method

Asias He — 2012-05-03T07:30:47

If we reset the virtio-blk device before the requests already dispatched
to the virtio-blk driver from the block layer are finised, we will stuck
in blk_cleanup_queue() and the remove will fail.

blk_cleanup_queue() calls blk_drain_queue() to drain all requests queued
before DEAD marking. However it will never success if the device is
already stopped. We'll have q->in_flight[] > 0, so the drain will not
finish.

How to reproduce the race:
1. hot-plug a virtio-blk device
2. keep reading/writing the device in guest
3. hot-unplug while the device is busy serving I/O

Changes in v2:
- Drop req_in_flight
- Use virtqueue_detach_unused_buf to get request dispatched to driver

Signed-off-by: Asias He <asias< at >redhat.com>
---
 drivers/block/virtio_blk.c |   16 +++++++++++++---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
index 72fe55d..670c28f 100644
--- a/drivers/block/virtio_blk.c
+++ b/drivers/block/virtio_blk.c
< at >< at > -443,7 +443,7 < at >< at > static int __devinit virtblk_probe(struct virtio_device *vdev)
 if (err)
 goto out_free_vblk;
 
-vblk->pool = mempool_create_kmalloc_pool(1,sizeof(struct virtblk_req));
+vblk->pool = mempool_create_kmalloc_pool(1, sizeof(struct virtblk_req));
 if (!vblk->pool) {
 err = -ENOMEM;
 goto out_free_vq;
< at >< at > -576,20 +576,30 < at >< at > static void __devexit virtblk_remove(struct virtio_device *vdev)
 {
 struct virtio_blk *vblk = vdev->priv;
 int index = vblk->index;
+struct virtblk_req *vbr;
 
 /* Prevent config work handler from accessing the device. */
 mutex_lock(&vblk->config_lock);
 vblk->config_enable = false;
 mutex_unlock(&vblk->config_lock);
 
+/* Abort all request on the queue. */
+blk_abort_queue(vblk->disk->queue);
+del_gendisk(vblk->disk);
+
 /* Stop all the virtqueues. */
 vdev->config->reset(vdev);
-
 flush_work(&vblk->config_work);
 
-del_gendisk(vblk->disk);
+/* Abort request dispatched to driver. */
+while ((vbr = virtqueue_detach_unused_buf(vblk->vq))) {
+blk_abort_request(vbr->req);
+mempool_free(vbr, vblk->pool);
+}
+
 blk_cleanup_queue(vblk->disk->queue);
 put_disk(vblk->disk);
+
 mempool_destroy(vblk->pool);
 vdev->config->del_vqs(vdev);
 kfree(vblk);

using cache for virtio allocations?

Michael S. Tsirkin — 2012-05-03T05:29:43

Sasha, didn't you have a patch to allocate
things using cache in virtio core?
What happened to it?

Thanks,
MST

[PATCH 2/2] virtio: Use ida to allocate virtio index

Asias He — 2012-05-03T02:20:51

Current index allocation in virtio is based on a monotonically
increasing variable "index". This means we'll run out of numbers
after a while. E.g. someone crazy doing this in host side.

while(1) {
hot-plug a virtio device
hot-unplug the virito devcie
}

Signed-off-by: Asias He <asias< at >redhat.com>
---
 drivers/virtio/virtio.c |   11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/virtio/virtio.c b/drivers/virtio/virtio.c
index 984c501..f355807 100644
--- a/drivers/virtio/virtio.c
+++ b/drivers/virtio/virtio.c
< at >< at > -2,9 +2,10 < at >< at >
 #include <linux/spinlock.h>
 #include <linux/virtio_config.h>
 #include <linux/module.h>
+#include <linux/idr.h>
 
 /* Unique numbering for virtio devices. */
-static unsigned int dev_index;
+static DEFINE_IDA(virtio_index_ida);
 
 static ssize_t device_show(struct device *_d,
    struct device_attribute *attr, char *buf)
< at >< at > -193,7 +194,11 < at >< at > int register_virtio_device(struct virtio_device *dev)
 dev->dev.bus = &virtio_bus;
 
 /* Assign a unique device index and hence name. */
-dev->index = dev_index++;
+err = ida_simple_get(&virtio_index_ida, 0, 0, GFP_KERNEL);
+if (err < 0)
+goto out;
+
+dev->index = err;
 dev_set_name(&dev->dev, "virtio%u", dev->index);
 
 /* We always start by resetting the device, in case a previous
< at >< at > -208,6 +213,7 < at >< at > int register_virtio_device(struct virtio_device *dev)
 /* device_register() causes the bus infrastructure to look for a
  * matching driver. */
 err = device_register(&dev->dev);
+out:
 if (err)
 add_status(dev, VIRTIO_CONFIG_S_FAILED);
 return err;
< at >< at > -217,6 +223,7 < at >< at > EXPORT_SYMBOL_GPL(register_virtio_device);
 void unregister_virtio_device(struct virtio_device *dev)
 {
 device_unregister(&dev->dev);
+ida_simple_remove(&virtio_index_ida, dev->index);
 }
 EXPORT_SYMBOL_GPL(unregister_virtio_device);

[PATCH 1/2] virtio-blk: Fix hot-unplug race in remove method

Asias He — 2012-05-03T02:19:52

If we reset the virtio-blk device before the requests already dispatched
to the virtio-blk driver from the block layer are finised, we will stuck
in blk_cleanup_queue() and the remove will fail.

blk_cleanup_queue() calls blk_drain_queue() to drain all requests queued
before DEAD marking. However it will never success if the device is
already stopped. We'll have q->in_flight[] > 0, so the drain will not
finish.

How to reproduce the race:
1. hot-plug a virtio-blk device
2. keep reading/writing the device in guest
3. hot-unplug while the device is busy serving I/O

Signed-off-by: Asias He <asias< at >redhat.com>
---
 drivers/block/virtio_blk.c |   26 ++++++++++++++++++++++----
 1 file changed, 22 insertions(+), 4 deletions(-)

diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
index 72fe55d..72b818b 100644
--- a/drivers/block/virtio_blk.c
+++ b/drivers/block/virtio_blk.c
< at >< at > -46,6 +46,9 < at >< at > struct virtio_blk
 /* Ida index - used to track minor number allocations. */
 int index;
 
+/* Number of pending requests dispatched to driver. */
+int req_in_flight;
+
 /* Scatterlist: can be too big for stack. */
 struct scatterlist sg[/*sg_elems*/];
 };
< at >< at > -95,6 +98,7 < at >< at > static void blk_done(struct virtqueue *vq)
 }
 
 __blk_end_request_all(vbr->req, error);
+vblk->req_in_flight--;
 mempool_free(vbr, vblk->pool);
 }
 /* In case queue is stopped waiting for more buffers. */
< at >< at > -190,6 +194,7 < at >< at > static void do_virtblk_request(struct request_queue *q)
 
 while ((req = blk_peek_request(q)) != NULL) {
 BUG_ON(req->nr_phys_segments + 2 > vblk->sg_elems);
+vblk->req_in_flight++;
 
 /* If this request fails, stop queue and wait for something to
    finish to restart it. */
< at >< at > -443,7 +448,7 < at >< at > static int __devinit virtblk_probe(struct virtio_device *vdev)
 if (err)
 goto out_free_vblk;
 
-vblk->pool = mempool_create_kmalloc_pool(1,sizeof(struct virtblk_req));
+vblk->pool = mempool_create_kmalloc_pool(1, sizeof(struct virtblk_req));
 if (!vblk->pool) {
 err = -ENOMEM;
 goto out_free_vq;
< at >< at > -466,6 +471,7 < at >< at > static int __devinit virtblk_probe(struct virtio_device *vdev)
 
 virtblk_name_format("vd", index, vblk->disk->disk_name, DISK_NAME_LEN);
 
+vblk->req_in_flight = 0;
 vblk->disk->major = major;
 vblk->disk->first_minor = index_to_minor(index);
 vblk->disk->private_data = vblk;
< at >< at > -576,22 +582,34 < at >< at > static void __devexit virtblk_remove(struct virtio_device *vdev)
 {
 struct virtio_blk *vblk = vdev->priv;
 int index = vblk->index;
+unsigned long flags;
+int req_in_flight;
 
 /* Prevent config work handler from accessing the device. */
 mutex_lock(&vblk->config_lock);
 vblk->config_enable = false;
 mutex_unlock(&vblk->config_lock);
 
+/* Abort all request on the queue. */
+blk_abort_queue(vblk->disk->queue);
+del_gendisk(vblk->disk);
+
 /* Stop all the virtqueues. */
 vdev->config->reset(vdev);
-
+vdev->config->del_vqs(vdev);
 flush_work(&vblk->config_work);
 
-del_gendisk(vblk->disk);
+/* Wait requests dispatched to device driver to finish. */
+do {
+spin_lock_irqsave(&vblk->lock, flags);
+req_in_flight = vblk->req_in_flight;
+spin_unlock_irqrestore(&vblk->lock, flags);
+} while (req_in_flight != 0);
+
 blk_cleanup_queue(vblk->disk->queue);
 put_disk(vblk->disk);
+
 mempool_destroy(vblk->pool);
-vdev->config->del_vqs(vdev);
 kfree(vblk);
 ida_simple_remove(&vd_index_ida, index);
 }

[PATCH RFC V8 0/17] Paravirtualized ticket spinlocks

Raghavendra K T — 2012-05-02T10:06:10

This series replaces the existing paravirtualized spinlock mechanism
with a paravirtualized ticketlock mechanism. The series provides
implementation for both Xen and KVM.(targeted for 3.5 window)

Note: This needs debugfs changes patch that should be in Xen / linux-next
   https://lkml.org/lkml/2012/3/30/687

Changes in V8:
 - Reabsed patches to 3.4-rc4
 - Combined the KVM changes with ticketlock + Xen changes (Ingo)
 - Removed CAP_PV_UNHALT since it is redundant (Avi). But note that we
    need newer qemu which uses KVM_GET_SUPPORTED_CPUID ioctl.
 - Rewrite GET_MP_STATE condition (Avi)
 - Make pv_unhalt = bool (Avi)
 - Move out reset pv_unhalt code to vcpu_run from vcpu_block (Gleb)
 - Documentation changes (Rob Landley)
 - Have a printk to recognize that paravirt spinlock is enabled (Nikunj)
 - Move out kick hypercall out of CONFIG_PARAVIRT_SPINLOCK now
   so that it can be used for other optimizations such as 
   flush_tlb_ipi_others etc. (Nikunj)

Ticket locks have an inherent problem in a virtualized case, because
the vCPUs are scheduled rather than running concurrently (ignoring
gang scheduled vCPUs).  This can result in catastrophic performance
collapses when the vCPU scheduler doesn't schedule the correct "next"
vCPU, and ends up scheduling a vCPU which burns its entire timeslice
spinning.  (Note that this is not the same problem as lock-holder
preemption, which this series also addresses; that's also a problem,
but not catastrophic).

(See Thomas Friebel's talk "Prevent Guests from Spinning Around"
http://www.xen.org/files/xensummitboston08/LHP.pdf for more details.)

Currently we deal with this by having PV spinlocks, which adds a layer
of indirection in front of all the spinlock functions, and defining a
completely new implementation for Xen (and for other pvops users, but
there are none at present).

PV ticketlocks keeps the existing ticketlock implemenentation
(fastpath) as-is, but adds a couple of pvops for the slow paths:

- If a CPU has been waiting for a spinlock for SPIN_THRESHOLD
  iterations, then call out to the __ticket_lock_spinning() pvop,
  which allows a backend to block the vCPU rather than spinning.  This
  pvop can set the lock into "slowpath state".

- When releasing a lock, if it is in "slowpath state", the call
  __ticket_unlock_kick() to kick the next vCPU in line awake.  If the
  lock is no longer in contention, it also clears the slowpath flag.

The "slowpath state" is stored in the LSB of the within the lock tail
ticket.  This has the effect of reducing the max number of CPUs by
half (so, a "small ticket" can deal with 128 CPUs, and "large ticket"
32768).

For KVM, one hypercall is introduced in hypervisor,that allows a vcpu to kick
another vcpu out of halt state.
The blocking of vcpu is done using halt() in (lock_spinning) slowpath.

Overall, it results in a large reduction in code, it makes the native
and virtualized cases closer, and it removes a layer of indirection
around all the spinlock functions.

The fast path (taking an uncontended lock which isn't in "slowpath"
state) is optimal, identical to the non-paravirtualized case.

The inner part of ticket lock code becomes:
inc = xadd(&lock->tickets, inc);
inc.tail &= ~TICKET_SLOWPATH_FLAG;

if (likely(inc.head == inc.tail))
goto out;
for (;;) {
unsigned count = SPIN_THRESHOLD;
do {
if (ACCESS_ONCE(lock->tickets.head) == inc.tail)
goto out;
cpu_relax();
} while (--count);
__ticket_lock_spinning(lock, inc.tail);
}
out:barrier();
which results in:
push   %rbp
mov    %rsp,%rbp

mov    $0x200,%eax
lock xadd %ax,(%rdi)
movzbl %ah,%edx
cmp    %al,%dl
jne    1f# Slowpath if lock in contention

pop    %rbp
retq   

### SLOWPATH START
1:and    $-2,%edx
movzbl %dl,%esi

2:mov    $0x800,%eax
jmp    4f

3:pause  
sub    $0x1,%eax
je     5f

4:movzbl (%rdi),%ecx
cmp    %cl,%dl
jne    3b

pop    %rbp
retq   

5:callq  *__ticket_lock_spinning
jmp    2b
### SLOWPATH END

with CONFIG_PARAVIRT_SPINLOCKS=n, the code has changed slightly, where
the fastpath case is straight through (taking the lock without
contention), and the spin loop is out of line:

push   %rbp
mov    %rsp,%rbp

mov    $0x100,%eax
lock xadd %ax,(%rdi)
movzbl %ah,%edx
cmp    %al,%dl
jne    1f

pop    %rbp
retq   

### SLOWPATH START
1:pause  
movzbl (%rdi),%eax
cmp    %dl,%al
jne    1b

pop    %rbp
retq   
### SLOWPATH END

The unlock code is complicated by the need to both add to the lock's
"head" and fetch the slowpath flag from "tail".  This version of the
patch uses a locked add to do this, followed by a test to see if the
slowflag is set.  The lock prefix acts as a full memory barrier, so we
can be sure that other CPUs will have seen the unlock before we read
the flag (without the barrier the read could be fetched from the
store queue before it hits memory, which could result in a deadlock).

This is is all unnecessary complication if you're not using PV ticket
locks, it also uses the jump-label machinery to use the standard
"add"-based unlock in the non-PV case.

if (TICKET_SLOWPATH_FLAG &&
     static_key_false(&paravirt_ticketlocks_enabled))) {
arch_spinlock_t prev;
prev = *lock;
add_smp(&lock->tickets.head, TICKET_LOCK_INC);

/* add_smp() is a full mb() */
if (unlikely(lock->tickets.tail & TICKET_SLOWPATH_FLAG))
__ticket_unlock_slowpath(lock, prev);
} else
__add(&lock->tickets.head, TICKET_LOCK_INC, UNLOCK_LOCK_PREFIX);
which generates:
push   %rbp
mov    %rsp,%rbp

nop5# replaced by 5-byte jmp 2f when PV enabled

# non-PV unlock
addb   $0x2,(%rdi)

1:pop    %rbp
retq   

### PV unlock ###
2:movzwl (%rdi),%esi# Fetch prev

lock addb $0x2,(%rdi)# Do unlock

testb  $0x1,0x1(%rdi)# Test flag
je     1b# Finished if not set

### Slow path ###
add    $2,%sil# Add "head" in old lock state
mov    %esi,%edx
and    $0xfe,%dh# clear slowflag for comparison
movzbl %dh,%eax
cmp    %dl,%al# If head == tail (uncontended)
je     4f# clear slowpath flag

# Kick next CPU waiting for lock
3:movzbl %sil,%esi
callq  *pv_lock_ops.kick

pop    %rbp
retq   

# Lock no longer contended - clear slowflag
4:mov    %esi,%eax
lock cmpxchg %dx,(%rdi)# cmpxchg to clear flag
cmp    %si,%ax
jne    3b# If clear failed, then kick

pop    %rbp
retq   

So when not using PV ticketlocks, the unlock sequence just has a
5-byte nop added to it, and the PV case is reasonable straightforward
aside from requiring a "lock add".

TODO: 1) Remove CONFIG_PARAVIRT_SPINLOCK ?
      2) Experiments on further optimization possibilities. (discussed in V6)
      3) Use kvm_irq_delivery_to_apic() in kvm hypercall (suggested by Gleb)
      4) Any cleanups for e.g. Xen/KVM common code for debugfs.

PS: TODOs are no blockers for the current series merge.

Results:
=======
various form of results based on V6 of the patch series are posted in following links
 
 https://lkml.org/lkml/2012/3/21/161
 https://lkml.org/lkml/2012/3/21/198

 kvm results:
 https://lkml.org/lkml/2012/3/23/50
 https://lkml.org/lkml/2012/4/5/73

Benchmarking on the current set of patches will be posted soon.

Thoughts? Comments? Suggestions?. It  would be nice to see
Acked-by/Reviewed-by/Tested-by for the patch series.
 
Jeremy Fitzhardinge (9):
  x86/spinlock: Replace pv spinlocks with pv ticketlocks
  x86/ticketlock: Collapse a layer of functions
  xen: Defer spinlock setup until boot CPU setup
  xen/pvticketlock: Xen implementation for PV ticket locks
  xen/pvticketlocks: Add xen_nopvspin parameter to disable xen pv
    ticketlocks
  x86/pvticketlock: Use callee-save for lock_spinning
  x86/pvticketlock: When paravirtualizing ticket locks, increment by 2
  x86/ticketlock: Add slowpath logic
  xen/pvticketlock: Allow interrupts to be enabled while blocking

Srivatsa Vaddagiri (3): 
  Add a hypercall to KVM hypervisor to support pv-ticketlocks
  Added configuration support to enable debug information for KVM Guests
  Paravirtual ticketlock support for linux guests running on KVM hypervisor

Raghavendra K T (3):
  x86/ticketlock: Don't inline _spin_unlock when using paravirt
    spinlocks
  Fold pv_unhalt flag into GET_MP_STATE ioctl to aid migration
  Add documentation on Hypercalls and features used for PV spinlock

Andrew Jones (1):
  Split out rate limiting from jump_label.h

Stefano Stabellini (1):
 xen: Enable PV ticketlocks on HVM Xen
---
PS: Had to trim down recipient list because, LKML archive does not support
list > 20. Though many more people should have been in To/CC list.

Ticketlock links:
V7 : https://lkml.org/lkml/2012/4/19/335 
V6 : https://lkml.org/lkml/2012/3/21/161

KVM patch links:
 V6: https://lkml.org/lkml/2012/4/23/123

 V5 kernel changes:
 https://lkml.org/lkml/2012/3/23/50
 Qemu changes for V5:
 http://lists.gnu.org/archive/html/qemu-devel/2012-03/msg04455.html 

 V4 kernel changes:
 https://lkml.org/lkml/2012/1/14/66
 Qemu changes for V4:
 http://www.mail-archive.com/kvm< at >vger.kernel.org/msg66450.html

 V3 kernel Changes:
 https://lkml.org/lkml/2011/11/30/62
 Qemu patch for V3:
 http://lists.gnu.org/archive/html/qemu-devel/2011-12/msg00397.html

 V2 kernel changes : 
 https://lkml.org/lkml/2011/10/23/207

 Previous discussions : (posted by Srivatsa V).
 https://lkml.org/lkml/2010/7/26/24
 https://lkml.org/lkml/2011/1/19/212

Ticketlock change history:
Changes in V7:
 - Reabsed patches to 3.4-rc3
 - Added jumplabel split patch (originally from Andrew Jones rebased to
    3.4-rc3
 - jumplabel changes from Ingo and Jason taken and now using static_key_*
    instead of static_branch.
 - using UNINLINE_SPIN_UNLOCK (which was splitted as per suggestion from Linus)
 - This patch series is rebased on debugfs patch (that sould be already in
    Xen/linux-next https://lkml.org/lkml/2012/3/23/51)

Changes in V6 posting: (Raghavendra K T)
 - Rebased to linux-3.3-rc6.
 - used function+enum in place of macro (better type checking) 
 - use cmpxchg while resetting zero status for possible race
[suggested by Dave Hansen for KVM patches ]

KVM patch Change history:
Changes in V6:
- Rebased to 3.4-rc3
- Removed debugfs changes patch which should now be in Xen/linux-next.
  (https://lkml.org/lkml/2012/3/30/687)
- Removed PV_UNHALT_MSR since currently we don't need guest communication,
  and made pv_unhalt folded to GET_MP_STATE (Marcello, Avi[long back])
- Take jumplabel changes from Ingo/Jason into use (static_key_slow_inc usage)
- Added inline to spinlock_init in non PARAVIRT case
- Move arch specific code to arch/x86 and add stubs to other archs (Marcello)
- Added more comments on pv_unhalt usage etc (Marcello)

Changes in V5:
- rebased to 3.3-rc6
- added PV_UNHALT_MSR that would help in live migration (Avi)
- removed PV_LOCK_KICK vcpu request and pv_unhalt flag (re)added.
- Changed hypercall documentaion (Alex).
- mode_t changed to umode_t in debugfs.
- MSR related documentation added.
- rename PV_LOCK_KICK to PV_UNHALT. 
- host and guest patches not mixed. (Marcelo, Alex)
- kvm_kick_cpu now takes cpu so it can be used by flush_tlb_ipi_other 
   paravirtualization (Nikunj)
- coding style changes in variable declarion etc (Srikar)

Changes in V4:
- reabsed to 3.2.0 pre.
- use APIC ID for kicking the vcpu and use kvm_apic_match_dest for matching (Avi)
- fold vcpu->kicked flag into vcpu->requests (KVM_REQ_PVLOCK_KICK) and related 
  changes for UNHALT path to make pv ticket spinlock migration friendly(Avi, Marcello)
- Added Documentation for CPUID, Hypercall (KVM_HC_KICK_CPU)
  and capabilty (KVM_CAP_PVLOCK_KICK) (Avi)
- Remove unneeded kvm_arch_vcpu_ioctl_set_mpstate call. (Marcello)
- cumulative variable type changed (int ==> u32) in add_stat (Konrad)
- remove unneeded kvm_guest_init for !CONFIG_KVM_GUEST case

Changes in V3:
- rebased to 3.2-rc1
- use halt() instead of wait for kick hypercall.
- modify kick hyper call to do wakeup halted vcpu.
- hook kvm_spinlock_init to smp_prepare_cpus call (moved the call out of head##.c).
- fix the potential race when zero_stat is read.
- export debugfs_create_32 and add documentation to API.
- use static inline and enum instead of ADDSTAT macro. 
- add  barrier() in after setting kick_vcpu.
- empty static inline function for kvm_spinlock_init.
- combine the patches one and two readuce overhead.
- make KVM_DEBUGFS depends on DEBUGFS.
- include debugfs header unconditionally.

Changes in V2:
- rebased patchesto -rc9
- synchronization related changes based on Jeremy's changes 
 (Jeremy Fitzhardinge <jeremy.fitzhardinge< at >citrix.com>) pointed by 
 Stephan Diestelhorst <stephan.diestelhorst< at >amd.com>
- enabling 32 bit guests
- splitted patches into two more chunks

 Documentation/virtual/kvm/cpuid.txt      |    4 +
 Documentation/virtual/kvm/hypercalls.txt |   60 +++++
 arch/x86/Kconfig                         |   10 +
 arch/x86/include/asm/kvm_host.h          |    4 +
 arch/x86/include/asm/kvm_para.h          |   16 +-
 arch/x86/include/asm/paravirt.h          |   32 +--
 arch/x86/include/asm/paravirt_types.h    |   10 +-
 arch/x86/include/asm/spinlock.h          |  128 +++++++----
 arch/x86/include/asm/spinlock_types.h    |   16 +-
 arch/x86/kernel/kvm.c                    |  256 ++++++++++++++++++++
 arch/x86/kernel/paravirt-spinlocks.c     |   18 +-
 arch/x86/kvm/cpuid.c                     |    3 +-
 arch/x86/kvm/x86.c                       |   44 ++++-
 arch/x86/xen/smp.c                       |    3 +-
 arch/x86/xen/spinlock.c                  |  387 ++++++++++--------------------
 include/linux/jump_label.h               |   26 +--
 include/linux/jump_label_ratelimit.h     |   34 +++
 include/linux/kvm_para.h                 |    1 +
 include/linux/perf_event.h               |    1 +
 kernel/jump_label.c                      |    1 +
 20 files changed, 673 insertions(+), 381 deletions(-)

[PATCHv2] x86info: dump kvm cpuid's

Michael S. Tsirkin — 2012-04-30T14:38:35

The following makes 'x86info -r' dump hypervisor leaf cpu ids
(for kvm this is signature+features) when running in a vm.

On the guest we see the signature and the features:
eax in: 0x40000000, eax = 00000000 ebx = 4b4d564b ecx = 564b4d56 edx = 0000004d
eax in: 0x40000001, eax = 0100007b ebx = 00000000 ecx = 00000000 edx = 00000000

Hypervisor flag is checked to avoid output changes when not
running on a VM.

Signed-off-by: Michael S. Tsirkin <mst< at >redhat.com>

Changes from v1:
Make work on non KVM hypervisors (only KVM was tested).
Avi Kivity said kvm will in the future report
max HV leaf in eax. For now it reports eax = 0
        so add a work around for that.

---

diff --git a/identify.c b/identify.c
index 33f35de..a4a3763 100644
--- a/identify.c
+++ b/identify.c
< at >< at > -9,8 +9,8 < at >< at >
 
 void get_cpu_info_basics(struct cpudata *cpu)
 {
-unsigned int maxi, maxei, vendor, address_bits;
-unsigned int eax;
+unsigned int maxi, maxei, maxhv, vendor, address_bits;
+unsigned int eax, ebx, ecx;
 
 cpuid(cpu->number, 0, &maxi, &vendor, NULL, NULL);
 maxi &= 0xffff;/* The high-order word is non-zero on some Cyrix CPUs */
< at >< at > -19,7 +19,7 < at >< at > void get_cpu_info_basics(struct cpudata *cpu)
 return;
 
 /* Everything that supports cpuid supports these. */
-cpuid(cpu->number, 1, &eax, NULL, NULL, NULL);
+cpuid(cpu->number, 1, &eax, &ebx, &ecx, NULL);
 cpu->stepping = eax & 0xf;
 cpu->model = (eax >> 4) & 0xf;
 cpu->family = (eax >> 8) & 0xf;
< at >< at > -29,6 +29,19 < at >< at > void get_cpu_info_basics(struct cpudata *cpu)
 
 cpuid(cpu->number, 0xC0000000, &maxei, NULL, NULL, NULL);
 cpu->maxei2 = maxei;
+if (ecx & 0x80000000) {
+cpuid(cpu->number, 0x40000000, &maxhv, NULL, NULL, NULL);
+/*
+ * KVM up to linux 3.4 reports 0 as the max hypervisor leaf,
+ * where it really means 0x40000001.
+ * Most (all?) hypervisors have at least one CPUID besides
+ * the vendor ID so assume that.
+ */
+cpu->maxhv = maxhv ? maxhv : 0x40000001;
+} else {
+/* Suppress hypervisor cpuid unless running on a hypervisor */
+cpu->maxhv = 0;
+}
 
 cpuid(cpu->number, 0x80000008,&address_bits, NULL, NULL, NULL);
 cpu->phyaddr_bits = address_bits & 0xFF;
diff --git a/x86info.c b/x86info.c
index 22c4734..80cae36 100644
--- a/x86info.c
+++ b/x86info.c
< at >< at > -44,6 +44,10 < at >< at > static void display_detailed_info(struct cpudata *cpu)
 
 if (cpu->maxei2 >=0xC0000000)
 dump_raw_cpuid(cpu->number, 0xC0000000, cpu->maxei2);
+
+if (cpu->maxhv >= 0x40000000)
+dump_raw_cpuid(cpu->number, 0x40000000, cpu->maxhv);
+
 }
 
 if (show_cacheinfo) {
diff --git a/x86info.h b/x86info.h
index 7d2a455..c4f5d81 100644
--- a/x86info.h
+++ b/x86info.h
< at >< at > -84,7 +84,7 < at >< at > struct cpudata {
 unsigned int cachesize_trace;
 unsigned int phyaddr_bits;
 unsigned int viraddr_bits;
-unsigned int cpuid_level, maxei, maxei2;
+unsigned int cpuid_level, maxei, maxei2, maxhv;
 char name[CPU_NAME_LEN];
 enum connector connector;
 unsigned int flags_ecx;

[PATCH 0/3] virtio: balloon: cleanups and a fix

Amit Shah — 2012-04-26T19:15:54

Hello,

The main fix is to update the host with the current balloon value on
module removal after deflating the balloon.  Without the fix, the host
has the wrong idea of the ballooned memory in the guest.  This is
patch 2.

Patches 1 and 3 are cleanups with no effective code change.

Please apply,

Amit Shah (3):
  virtio: balloon: drop restore_common()
  virtio: balloon: let host know of updated balloon size before module
    removal
  virtio: balloon: separate out common code between remove and freeze
    functions

 drivers/virtio/virtio_balloon.c |   34 ++++++++++++++--------------------
 1 files changed, 14 insertions(+), 20 deletions(-)