* [PULL] virtio, vhost: fixes, cleanups, features
From: Michael S. Tsirkin @ 2018-02-08 16:13 UTC (permalink / raw)
To: Linus Torvalds
Cc: somlo, tgolembi, gomonovych, rdunlap, stefanha, kvm, ebiggers,
netdev, cohuck, linux-kernel, virtualization, zhangweiping,
jinli.zjl, mst, rfreire, vincent.legoll, arvind.yadav.cs, elfring,
peter.malone
The following changes since commit d8a5b80568a9cb66810e75b182018e9edb68e8ff:
Linux 4.15 (2018-01-28 13:20:33 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git tags/for_linus
for you to fetch changes up to d25cc43c6775bff6b8e3dad97c747954b805e421:
vhost: don't hold onto file pointer for VHOST_SET_LOG_FD (2018-02-01 16:26:47 +0200)
----------------------------------------------------------------
virtio, vhost: fixes, cleanups, features
This includes the disk/cache memory stats for for the virtio balloon,
as well as multiple fixes and cleanups.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
----------------------------------------------------------------
Arvind Yadav (1):
virtio: virtio_mmio: make of_device_ids const.
Eric Biggers (3):
vhost: don't hold onto file pointer for VHOST_SET_VRING_CALL
vhost: don't hold onto file pointer for VHOST_SET_VRING_ERR
vhost: don't hold onto file pointer for VHOST_SET_LOG_FD
Markus Elfring (1):
vhost/scsi: Improve a size determination in four functions
Michael S. Tsirkin (2):
virtio/ringtest: fix up need_event math
virtio/ringtest: virtio_ring: fix up need_event math
Peter Malone (1):
ringtest: ring.c malloc & memset to calloc
Stefan Hajnoczi (1):
virtio_blk: print capacity at probe time
Tomáš Golembiovský (1):
virtio_balloon: include disk/file caches memory statistics
Tonghao Zhang (1):
vhost: Remove the unused variable.
Vasyl Gomonovych (2):
virtio-mmio: Use PTR_ERR_OR_ZERO()
firmware: Use PTR_ERR_OR_ZERO()
Vincent Legoll (1):
virtio: make VIRTIO a menuconfig to ease disabling it all
weiping zhang (3):
virtio: split device_register into device_initialize and device_add
virtio_pci: don't kfree device on register failure
virtio_vop: don't kfree device on register failure
夷则(Caspar) (1):
vhost: remove unused lock check flag in vhost_dev_cleanup()
drivers/block/virtio_blk.c | 32 ++++++++--------
drivers/firmware/qemu_fw_cfg.c | 4 +-
drivers/misc/mic/vop/vop_main.c | 20 ++++++----
drivers/vhost/net.c | 2 +-
drivers/vhost/scsi.c | 11 +++---
drivers/vhost/test.c | 2 +-
drivers/vhost/vhost.c | 68 ++++++++-------------------------
drivers/vhost/vhost.h | 9 +----
drivers/vhost/vsock.c | 2 +-
drivers/virtio/Kconfig | 8 +++-
drivers/virtio/virtio.c | 18 +++++++--
drivers/virtio/virtio_balloon.c | 4 ++
drivers/virtio/virtio_mmio.c | 6 +--
drivers/virtio/virtio_pci_common.c | 8 +++-
include/uapi/linux/virtio_balloon.h | 3 +-
tools/virtio/ringtest/ring.c | 30 ++++++++-------
tools/virtio/ringtest/virtio_ring_0_9.c | 24 +++++++-----
17 files changed, 120 insertions(+), 131 deletions(-)
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH v4 3/3] qemu: add linkspeed and duplex settings to virtio-net
From: Michael S. Tsirkin @ 2018-02-08 16:39 UTC (permalink / raw)
To: Jason Baron; +Cc: virtio-dev, netdev, qemu-devel, virtualization, davem
In-Reply-To: <cb116634b45b4da0c437ca54cd979c703fc6b920.1515190612.git.jbaron@akamai.com>
On Fri, Jan 05, 2018 at 05:44:55PM -0500, Jason Baron wrote:
> Although linkspeed and duplex can be set in a linux guest via 'ethtool -s',
> this requires custom ethtool commands for virtio-net by default.
>
> Introduce a new feature flag, VIRTIO_NET_F_SPEED_DUPLEX, which allows
> the hypervisor to export a linkspeed and duplex setting. The user can
> subsequently overwrite it later if desired via: 'ethtool -s'.
>
> Linkspeed and duplex settings can be set as:
> '-device virtio-net,speed=10000,duplex=full'
>
> where speed is [-1...INT_MAX], and duplex is ["half"|"full"].
>
> Signed-off-by: Jason Baron <jbaron@akamai.com>
> Cc: "Michael S. Tsirkin" <mst@redhat.com>
> Cc: Jason Wang <jasowang@redhat.com>
> Cc: virtio-dev@lists.oasis-open.org
> ---
> hw/net/virtio-net.c | 32 +++++++++++++++++++++++++++++
> include/hw/virtio/virtio-net.h | 3 +++
> include/standard-headers/linux/virtio_net.h | 13 ++++++++++++
> 3 files changed, 48 insertions(+)
>
> diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
> index 54823af..cd63659 100644
> --- a/hw/net/virtio-net.c
> +++ b/hw/net/virtio-net.c
> @@ -40,6 +40,12 @@
> #define VIRTIO_NET_RX_QUEUE_MIN_SIZE VIRTIO_NET_RX_QUEUE_DEFAULT_SIZE
> #define VIRTIO_NET_TX_QUEUE_MIN_SIZE VIRTIO_NET_TX_QUEUE_DEFAULT_SIZE
>
> +/* duplex and speed */
> +#define DUPLEX_UNKNOWN 0xff
> +#define DUPLEX_HALF 0x00
> +#define DUPLEX_FULL 0x01
> +#define SPEED_UNKNOWN -1
> +
> /*
> * Calculate the number of bytes up to and including the given 'field' of
> * 'container'.
Please import ethtool.h with these macros from linux using scripts/update-linux-headers.sh
machinery.
> @@ -61,6 +67,8 @@ static VirtIOFeature feature_sizes[] = {
> .end = endof(struct virtio_net_config, max_virtqueue_pairs)},
> {.flags = 1ULL << VIRTIO_NET_F_MTU,
> .end = endof(struct virtio_net_config, mtu)},
> + {.flags = 1ULL << VIRTIO_NET_F_SPEED_DUPLEX,
> + .end = endof(struct virtio_net_config, duplex)},
> {}
> };
>
> @@ -89,6 +97,8 @@ static void virtio_net_get_config(VirtIODevice *vdev, uint8_t *config)
> virtio_stw_p(vdev, &netcfg.max_virtqueue_pairs, n->max_queues);
> virtio_stw_p(vdev, &netcfg.mtu, n->net_conf.mtu);
> memcpy(netcfg.mac, n->mac, ETH_ALEN);
> + virtio_stl_p(vdev, &netcfg.speed, n->net_conf.speed);
> + netcfg.duplex = n->net_conf.duplex;
> memcpy(config, &netcfg, n->config_size);
> }
>
> @@ -1941,6 +1951,26 @@ static void virtio_net_device_realize(DeviceState *dev, Error **errp)
> n->host_features |= (1ULL << VIRTIO_NET_F_MTU);
> }
>
> + if (n->net_conf.duplex_str) {
> + if (strncmp(n->net_conf.duplex_str, "half", 5) == 0) {
> + n->net_conf.duplex = DUPLEX_HALF;
> + } else if (strncmp(n->net_conf.duplex_str, "full", 5) == 0) {
> + n->net_conf.duplex = DUPLEX_FULL;
> + } else {
> + error_setg(errp, "'duplex' must be 'half' or 'full'");
> + }
> + n->host_features |= (1ULL << VIRTIO_NET_F_SPEED_DUPLEX);
> + } else {
> + n->net_conf.duplex = DUPLEX_UNKNOWN;
> + }
> +
> + if (n->net_conf.speed < SPEED_UNKNOWN) {
> + error_setg(errp, "'speed' must be between -1 (SPEED_UNKOWN) and "
> + "INT_MAX");
> + } else if (n->net_conf.speed >= 0) {
> + n->host_features |= (1ULL << VIRTIO_NET_F_SPEED_DUPLEX);
> + }
> +
> virtio_net_set_config_size(n, n->host_features);
> virtio_init(vdev, "virtio-net", VIRTIO_ID_NET, n->config_size);
>
> @@ -2161,6 +2191,8 @@ static Property virtio_net_properties[] = {
> DEFINE_PROP_UINT16("host_mtu", VirtIONet, net_conf.mtu, 0),
> DEFINE_PROP_BOOL("x-mtu-bypass-backend", VirtIONet, mtu_bypass_backend,
> true),
> + DEFINE_PROP_INT32("speed", VirtIONet, net_conf.speed, SPEED_UNKNOWN),
> + DEFINE_PROP_STRING("duplex", VirtIONet, net_conf.duplex_str),
> DEFINE_PROP_END_OF_LIST(),
> };
>
> diff --git a/include/hw/virtio/virtio-net.h b/include/hw/virtio/virtio-net.h
> index e7634c9..02484dc 100644
> --- a/include/hw/virtio/virtio-net.h
> +++ b/include/hw/virtio/virtio-net.h
> @@ -38,6 +38,9 @@ typedef struct virtio_net_conf
> uint16_t rx_queue_size;
> uint16_t tx_queue_size;
> uint16_t mtu;
> + int32_t speed;
> + char *duplex_str;
> + uint8_t duplex;
> } virtio_net_conf;
>
> /* Maximum packet size we can receive from tap device: header + 64k */
> diff --git a/include/standard-headers/linux/virtio_net.h b/include/standard-headers/linux/virtio_net.h
> index 30ff249..17c8531 100644
> --- a/include/standard-headers/linux/virtio_net.h
> +++ b/include/standard-headers/linux/virtio_net.h
> @@ -57,6 +57,8 @@
> * Steering */
> #define VIRTIO_NET_F_CTRL_MAC_ADDR 23 /* Set MAC address */
>
> +#define VIRTIO_NET_F_SPEED_DUPLEX 63 /* Device set linkspeed and duplex */
> +
> #ifndef VIRTIO_NET_NO_LEGACY
> #define VIRTIO_NET_F_GSO 6 /* Host handles pkts w/ any GSO type */
> #endif /* VIRTIO_NET_NO_LEGACY */
> @@ -76,6 +78,17 @@ struct virtio_net_config {
> uint16_t max_virtqueue_pairs;
> /* Default maximum transmit unit advice */
> uint16_t mtu;
> + /*
> + * speed, in units of 1Mb. All values 0 to INT_MAX are legal.
> + * Any other value stands for unknown.
> + */
> + uint32_t speed;
> + /*
> + * 0x00 - half duplex
> + * 0x01 - full duplex
> + * Any other value stands for unknown.
> + */
> + uint8_t duplex;
> } QEMU_PACKED;
>
> /*
This should be done as a separate patch by running the abovementioned
update script.
> diff --git a/pixman b/pixman
> new file mode 160000
> index 0000000..87eea99
> --- /dev/null
> +++ b/pixman
> @@ -0,0 +1 @@
> +Subproject commit 87eea99e443b389c978cf37efc52788bf03a0ee0
I don't think we need this part.
> --
> 2.6.1
^ permalink raw reply
* Re: [PATCH v28 4/4] virtio-balloon: VIRTIO_BALLOON_F_PAGE_POISON
From: Michael S. Tsirkin @ 2018-02-08 19:25 UTC (permalink / raw)
To: Wei Wang
Cc: yang.zhang.wz, virtio-dev, riel, quan.xu0, kvm, nilal,
liliang.opensource, linux-kernel, mhocko, linux-mm, huangzhichao,
pbonzini, akpm, virtualization
In-Reply-To: <1518083420-11108-5-git-send-email-wei.w.wang@intel.com>
On Thu, Feb 08, 2018 at 05:50:20PM +0800, Wei Wang wrote:
> The VIRTIO_BALLOON_F_PAGE_POISON feature bit is used to indicate if the
> guest is using page poisoning. Guest writes to the poison_val config
> field to tell host about the page poisoning value in use.
>
> Signed-off-by: Wei Wang <wei.w.wang@intel.com>
> Suggested-by: Michael S. Tsirkin <mst@redhat.com>
> Cc: Michael S. Tsirkin <mst@redhat.com>
> Cc: Michal Hocko <mhocko@suse.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> ---
> drivers/virtio/virtio_balloon.c | 13 +++++++++++++
> include/uapi/linux/virtio_balloon.h | 3 +++
> 2 files changed, 16 insertions(+)
>
> diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
> index 39ecce3..9fa7fcf 100644
> --- a/drivers/virtio/virtio_balloon.c
> +++ b/drivers/virtio/virtio_balloon.c
> @@ -685,6 +685,7 @@ static struct file_system_type balloon_fs = {
> static int virtballoon_probe(struct virtio_device *vdev)
> {
> struct virtio_balloon *vb;
> + __u32 poison_val;
> int err;
>
> if (!vdev->config->get) {
> @@ -728,6 +729,12 @@ static int virtballoon_probe(struct virtio_device *vdev)
> goto out_del_vqs;
> }
> INIT_WORK(&vb->report_free_page_work, report_free_page_func);
> + if (virtio_has_feature(vdev, VIRTIO_BALLOON_F_PAGE_POISON)) {
> + page_poison_val_get((u8 *)&poison_val);
> + memset(&poison_val, poison_val, sizeof(poison_val));
This will not DTRT on big-endian platforms.
Just use a local u8 variable.
> + virtio_cwrite(vb->vdev, struct virtio_balloon_config,
> + poison_val, &poison_val);
> + }
> }
>
> vb->nb.notifier_call = virtballoon_oom_notify;
> @@ -846,6 +853,11 @@ static int virtballoon_restore(struct virtio_device *vdev)
>
> static int virtballoon_validate(struct virtio_device *vdev)
> {
> + uint8_t unused;
> +
> + if (!page_poison_val_get(&unused))
> + __virtio_clear_bit(vdev, VIRTIO_BALLOON_F_PAGE_POISON);
> +
> __virtio_clear_bit(vdev, VIRTIO_F_IOMMU_PLATFORM);
> return 0;
> }
> @@ -855,6 +867,7 @@ static unsigned int features[] = {
> VIRTIO_BALLOON_F_STATS_VQ,
> VIRTIO_BALLOON_F_DEFLATE_ON_OOM,
> VIRTIO_BALLOON_F_FREE_PAGE_HINT,
> + VIRTIO_BALLOON_F_PAGE_POISON,
> };
>
> static struct virtio_driver virtio_balloon_driver = {
> diff --git a/include/uapi/linux/virtio_balloon.h b/include/uapi/linux/virtio_balloon.h
> index 0c654db..3f97067 100644
> --- a/include/uapi/linux/virtio_balloon.h
> +++ b/include/uapi/linux/virtio_balloon.h
> @@ -35,6 +35,7 @@
> #define VIRTIO_BALLOON_F_STATS_VQ 1 /* Memory Stats virtqueue */
> #define VIRTIO_BALLOON_F_DEFLATE_ON_OOM 2 /* Deflate balloon on OOM */
> #define VIRTIO_BALLOON_F_FREE_PAGE_HINT 3 /* VQ to report free pages */
> +#define VIRTIO_BALLOON_F_PAGE_POISON 4 /* Guest is using page poisoning */
>
> /* Size of a PFN in the balloon interface. */
> #define VIRTIO_BALLOON_PFN_SHIFT 12
> @@ -47,6 +48,8 @@ struct virtio_balloon_config {
> __u32 actual;
> /* Free page report command id, readonly by guest */
> __u32 free_page_report_cmd_id;
> + /* Stores PAGE_POISON if page poisoning is in use */
> + __u32 poison_val;
> };
>
> #define VIRTIO_BALLOON_S_SWAP_IN 0 /* Amount of memory swapped in */
> --
> 2.7.4
^ permalink raw reply
* Re: [PATCH v28 3/4] mm/page_poison: add a function to expose page poison val to kernel modules
From: Michael S. Tsirkin @ 2018-02-08 19:29 UTC (permalink / raw)
To: Wei Wang
Cc: yang.zhang.wz, virtio-dev, riel, quan.xu0, kvm, nilal,
liliang.opensource, linux-kernel, mhocko, linux-mm, huangzhichao,
pbonzini, akpm, virtualization
In-Reply-To: <1518083420-11108-4-git-send-email-wei.w.wang@intel.com>
On Thu, Feb 08, 2018 at 05:50:19PM +0800, Wei Wang wrote:
> Move the PAGE_POISON value to page_poison.c and add a function to enable
> callers from a kernel module to get the poison value if the page poisoning
> feature is in use. This also avoids callers directly checking PAGE_POISON
> regardless of whether the feature is enabled.
>
> Signed-off-by: Wei Wang <wei.w.wang@intel.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Michal Hocko <mhocko@kernel.org>
> Cc: Michael S. Tsirkin <mst@redhat.com>
> ---
> include/linux/mm.h | 2 ++
> include/linux/poison.h | 7 -------
> mm/page_poison.c | 24 ++++++++++++++++++++++++
> 3 files changed, 26 insertions(+), 7 deletions(-)
>
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 1c77d88..d95e5d3 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -2469,11 +2469,13 @@ extern int apply_to_page_range(struct mm_struct *mm, unsigned long address,
> extern bool page_poisoning_enabled(void);
> extern void kernel_poison_pages(struct page *page, int numpages, int enable);
> extern bool page_is_poisoned(struct page *page);
> +extern bool page_poison_val_get(u8 *val);
> #else
> static inline bool page_poisoning_enabled(void) { return false; }
> static inline void kernel_poison_pages(struct page *page, int numpages,
> int enable) { }
> static inline bool page_is_poisoned(struct page *page) { return false; }
> +static inline bool page_poison_val_get(u8 *val) { return false; };
> #endif
>
> #ifdef CONFIG_DEBUG_PAGEALLOC
Thinking more about it, page_poisoning_enabled already exists.
I would just add "u8 page_poison_val_get(void)" and don't add
a stub since compiler will drop the call with poisoning off.
> diff --git a/include/linux/poison.h b/include/linux/poison.h
> index 15927eb..348bf67 100644
> --- a/include/linux/poison.h
> +++ b/include/linux/poison.h
> @@ -30,13 +30,6 @@
> */
> #define TIMER_ENTRY_STATIC ((void *) 0x300 + POISON_POINTER_DELTA)
>
> -/********** mm/debug-pagealloc.c **********/
> -#ifdef CONFIG_PAGE_POISONING_ZERO
> -#define PAGE_POISON 0x00
> -#else
> -#define PAGE_POISON 0xaa
> -#endif
> -
> /********** mm/page_alloc.c ************/
>
I'd split this chunk out, this patchset is at v28 as it is.
> #define TAIL_MAPPING ((void *) 0x400 + POISON_POINTER_DELTA)
> diff --git a/mm/page_poison.c b/mm/page_poison.c
> index e83fd44..9a07973 100644
> --- a/mm/page_poison.c
> +++ b/mm/page_poison.c
> @@ -7,6 +7,13 @@
> #include <linux/poison.h>
> #include <linux/ratelimit.h>
>
> +/********** mm/debug-pagealloc.c **********/
This file no longer exists.
> +#ifdef CONFIG_PAGE_POISONING_ZERO
> +#define PAGE_POISON 0x00
> +#else
> +#define PAGE_POISON 0xaa
> +#endif
> +
> static bool want_page_poisoning __read_mostly;
>
> static int early_page_poison_param(char *buf)
> @@ -30,6 +37,23 @@ bool page_poisoning_enabled(void)
> debug_pagealloc_enabled()));
> }
>
> +/**
> + * page_poison_val_get - get the page poison value if page poisoning is enabled
> + * @val: the caller's memory to get the page poison value
> + *
> + * Return true with @val stores the poison value if page poisoning is enabled.
> + * Otherwise, return false with @val unchanged.
> + */
> +bool page_poison_val_get(u8 *val)
> +{
> + if (!page_poisoning_enabled())
> + return false;
> +
> + *val = PAGE_POISON;
> + return true;
> +}
> +EXPORT_SYMBOL_GPL(page_poison_val_get);
> +
> static void poison_page(struct page *page)
> {
> void *addr = kmap_atomic(page);
> --
> 2.7.4
^ permalink raw reply
* Re: [PATCH v28 4/4] virtio-balloon: VIRTIO_BALLOON_F_PAGE_POISON
From: Michael S. Tsirkin @ 2018-02-08 19:31 UTC (permalink / raw)
To: Wei Wang
Cc: yang.zhang.wz, virtio-dev, riel, quan.xu0, kvm, nilal,
liliang.opensource, linux-kernel, mhocko, linux-mm, huangzhichao,
pbonzini, akpm, virtualization
In-Reply-To: <1518083420-11108-5-git-send-email-wei.w.wang@intel.com>
On Thu, Feb 08, 2018 at 05:50:20PM +0800, Wei Wang wrote:
> The VIRTIO_BALLOON_F_PAGE_POISON feature bit is used to indicate if the
> guest is using page poisoning. Guest writes to the poison_val config
> field to tell host about the page poisoning value in use.
>
> Signed-off-by: Wei Wang <wei.w.wang@intel.com>
> Suggested-by: Michael S. Tsirkin <mst@redhat.com>
> Cc: Michael S. Tsirkin <mst@redhat.com>
> Cc: Michal Hocko <mhocko@suse.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
I'd reorder this before 2/4 this way host can always rely
on the poison feature being supported if free page
tracking is supported.
> ---
> drivers/virtio/virtio_balloon.c | 13 +++++++++++++
> include/uapi/linux/virtio_balloon.h | 3 +++
> 2 files changed, 16 insertions(+)
>
> diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
> index 39ecce3..9fa7fcf 100644
> --- a/drivers/virtio/virtio_balloon.c
> +++ b/drivers/virtio/virtio_balloon.c
> @@ -685,6 +685,7 @@ static struct file_system_type balloon_fs = {
> static int virtballoon_probe(struct virtio_device *vdev)
> {
> struct virtio_balloon *vb;
> + __u32 poison_val;
> int err;
>
> if (!vdev->config->get) {
> @@ -728,6 +729,12 @@ static int virtballoon_probe(struct virtio_device *vdev)
> goto out_del_vqs;
> }
> INIT_WORK(&vb->report_free_page_work, report_free_page_func);
> + if (virtio_has_feature(vdev, VIRTIO_BALLOON_F_PAGE_POISON)) {
> + page_poison_val_get((u8 *)&poison_val);
> + memset(&poison_val, poison_val, sizeof(poison_val));
> + virtio_cwrite(vb->vdev, struct virtio_balloon_config,
> + poison_val, &poison_val);
> + }
> }
>
> vb->nb.notifier_call = virtballoon_oom_notify;
> @@ -846,6 +853,11 @@ static int virtballoon_restore(struct virtio_device *vdev)
>
> static int virtballoon_validate(struct virtio_device *vdev)
> {
> + uint8_t unused;
> +
> + if (!page_poison_val_get(&unused))
> + __virtio_clear_bit(vdev, VIRTIO_BALLOON_F_PAGE_POISON);
> +
> __virtio_clear_bit(vdev, VIRTIO_F_IOMMU_PLATFORM);
> return 0;
> }
> @@ -855,6 +867,7 @@ static unsigned int features[] = {
> VIRTIO_BALLOON_F_STATS_VQ,
> VIRTIO_BALLOON_F_DEFLATE_ON_OOM,
> VIRTIO_BALLOON_F_FREE_PAGE_HINT,
> + VIRTIO_BALLOON_F_PAGE_POISON,
> };
>
> static struct virtio_driver virtio_balloon_driver = {
> diff --git a/include/uapi/linux/virtio_balloon.h b/include/uapi/linux/virtio_balloon.h
> index 0c654db..3f97067 100644
> --- a/include/uapi/linux/virtio_balloon.h
> +++ b/include/uapi/linux/virtio_balloon.h
> @@ -35,6 +35,7 @@
> #define VIRTIO_BALLOON_F_STATS_VQ 1 /* Memory Stats virtqueue */
> #define VIRTIO_BALLOON_F_DEFLATE_ON_OOM 2 /* Deflate balloon on OOM */
> #define VIRTIO_BALLOON_F_FREE_PAGE_HINT 3 /* VQ to report free pages */
> +#define VIRTIO_BALLOON_F_PAGE_POISON 4 /* Guest is using page poisoning */
>
> /* Size of a PFN in the balloon interface. */
> #define VIRTIO_BALLOON_PFN_SHIFT 12
> @@ -47,6 +48,8 @@ struct virtio_balloon_config {
> __u32 actual;
> /* Free page report command id, readonly by guest */
> __u32 free_page_report_cmd_id;
> + /* Stores PAGE_POISON if page poisoning is in use */
> + __u32 poison_val;
> };
>
> #define VIRTIO_BALLOON_S_SWAP_IN 0 /* Amount of memory swapped in */
> --
> 2.7.4
^ permalink raw reply
* Re: [PATCH v28 0/4] Virtio-balloon: support free page reporting
From: Michael S. Tsirkin @ 2018-02-08 19:55 UTC (permalink / raw)
To: Wei Wang
Cc: yang.zhang.wz, virtio-dev, riel, quan.xu0, kvm, nilal,
liliang.opensource, linux-kernel, mhocko, linux-mm, huangzhichao,
pbonzini, akpm, virtualization
In-Reply-To: <1518083420-11108-1-git-send-email-wei.w.wang@intel.com>
On Thu, Feb 08, 2018 at 05:50:16PM +0800, Wei Wang wrote:
> This patch series is separated from the previous "Virtio-balloon
> Enhancement" series. The new feature, VIRTIO_BALLOON_F_FREE_PAGE_HINT,
> implemented by this series enables the virtio-balloon driver to report
> hints of guest free pages to the host. It can be used to accelerate live
> migration of VMs. Here is an introduction of this usage:
>
> Live migration needs to transfer the VM's memory from the source machine
> to the destination round by round. For the 1st round, all the VM's memory
> is transferred. From the 2nd round, only the pieces of memory that were
> written by the guest (after the 1st round) are transferred. One method
> that is popularly used by the hypervisor to track which part of memory is
> written is to write-protect all the guest memory.
>
> This feature enables the optimization of the 1st round memory transfer -
> the hypervisor can skip the transfer of guest free pages in the 1st round.
> It is not concerned that the memory pages are used after they are given
> to the hypervisor as a hint of the free pages, because they will be
> tracked by the hypervisor and transferred in the next round if they are
> used and written.
At this point I think it's a good idea to focus on the qemu
side, that code is still not really ready yet.
> * Tests
> - Migration time improvement
> Result:
> Live migration time is reduced to 14% with this optimization.
> Details:
> Local live migration of 8GB idle guest, the legacy live migration takes
> ~1817ms. With this optimization, it takes ~254ms, which reduces the time
> to 14%.
> - Workload tests
> Results:
> Running this feature has no impact on the linux compilation workload
> running inside the guest.
I think you should try something memory intensive. Try asking
qemu migration guys for hints on a good test to run.
> Details:
> Set up a Ping-Pong local live migration, where the guest ceaselessy
> migrates between the source and destination. Linux compilation,
> i.e. make bzImage -j4, is performed during the Ping-Pong migration. The
> legacy case takes 5min14s to finish the compilation. With this
> optimization patched, it takes 5min12s.
How is migration time affected in this case?
> ChangeLog:
> v27->v28:
> - mm/page_poison: Move PAGE_POISON to page_poison.c and add a function
> to expose page poison val to kernel modules.
> v26->v27:
> - add a new patch to expose page_poisoning_enabled to kernel modules
> - virtio-balloon: set poison_val to 0xaaaaaaaa, instead of 0xaa
> v25->v26: virtio-balloon changes only
> - remove kicking free page vq since the host now polls the vq after
> initiating the reporting
> - report_free_page_func: detach all the used buffers after sending
> the stop cmd id. This avoids leaving the detaching burden (i.e.
> overhead) to the next cmd id. Detaching here isn't considered
> overhead since the stop cmd id has been sent, and host has already
> moved formard.
> v24->v25:
> - mm: change walk_free_mem_block to return 0 (instead of true) on
> completing the report, and return a non-zero value from the
> callabck, which stops the reporting.
> - virtio-balloon:
> - use enum instead of define for VIRTIO_BALLOON_VQ_INFLATE etc.
> - avoid __virtio_clear_bit when bailing out;
> - a new method to avoid reporting the some cmd id to host twice
> - destroy_workqueue can cancel free page work when the feature is
> negotiated;
> - fail probe when the free page vq size is less than 2.
> v23->v24:
> - change feature name VIRTIO_BALLOON_F_FREE_PAGE_VQ to
> VIRTIO_BALLOON_F_FREE_PAGE_HINT
> - kick when vq->num_free < half full, instead of "= half full"
> - replace BUG_ON with bailing out
> - check vb->balloon_wq in probe(), if null, bail out
> - add a new feature bit for page poisoning
> - solve the corner case that one cmd id being sent to host twice
> v22->v23:
> - change to kick the device when the vq is half-way full;
> - open-code batch_free_page_sg into add_one_sg;
> - change cmd_id from "uint32_t" to "__virtio32";
> - reserver one entry in the vq for the driver to send cmd_id, instead
> of busywaiting for an available entry;
> - add "stop_update" check before queue_work for prudence purpose for
> now, will have a separate patch to discuss this flag check later;
> - init_vqs: change to put some variables on stack to have simpler
> implementation;
> - add destroy_workqueue(vb->balloon_wq);
>
> v21->v22:
> - add_one_sg: some code and comment re-arrangement
> - send_cmd_id: handle a cornercase
>
> For previous ChangeLog, please reference
> https://lwn.net/Articles/743660/
>
> Wei Wang (4):
> mm: support reporting free page blocks
> virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_HINT
> mm/page_poison: add a function to expose page poison val to kernel
> modules
> virtio-balloon: VIRTIO_BALLOON_F_PAGE_POISON
>
> drivers/virtio/virtio_balloon.c | 258 +++++++++++++++++++++++++++++++-----
> include/linux/mm.h | 8 ++
> include/linux/poison.h | 7 -
> include/uapi/linux/virtio_balloon.h | 7 +
> mm/page_alloc.c | 96 ++++++++++++++
> mm/page_poison.c | 24 ++++
> 6 files changed, 357 insertions(+), 43 deletions(-)
>
> --
> 2.7.4
^ permalink raw reply
* Re: [PATCH v28 0/4] Virtio-balloon: support free page reporting
From: Wei Wang @ 2018-02-09 3:11 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: yang.zhang.wz, virtio-dev, riel, quan.xu0, kvm, nilal,
liliang.opensource, linux-kernel, mhocko, linux-mm, huangzhichao,
pbonzini, akpm, virtualization, dgilbert
In-Reply-To: <20180208215048-mutt-send-email-mst@kernel.org>
On 02/09/2018 03:55 AM, Michael S. Tsirkin wrote:
> On Thu, Feb 08, 2018 at 05:50:16PM +0800, Wei Wang wrote:
>
>> Details:
>> Set up a Ping-Pong local live migration, where the guest ceaselessy
>> migrates between the source and destination. Linux compilation,
>> i.e. make bzImage -j4, is performed during the Ping-Pong migration. The
>> legacy case takes 5min14s to finish the compilation. With this
>> optimization patched, it takes 5min12s.
> How is migration time affected in this case?
When the linux compilation workload runs, the migration time (both the
legacy and this optimization case) varies as the compilation goes on. It
seems not easy to give a static speedup number, some times the migration
time is reduced to 33%, sometimes to 50%, it varies, and depends on how
much free memory the system has at that moment. For example, at the
later stage of the compilation, I can observe 5GB memory being used as
page cache. But overall, I can observe obvious improvement of the
migration time.
Best,
Wei
^ permalink raw reply
* Re: [PATCH v28 0/4] Virtio-balloon: support free page reporting
From: Michael S. Tsirkin @ 2018-02-09 3:14 UTC (permalink / raw)
To: Wei Wang
Cc: yang.zhang.wz, virtio-dev, riel, quan.xu0, kvm, nilal,
liliang.opensource, linux-kernel, mhocko, linux-mm, huangzhichao,
pbonzini, akpm, virtualization, dgilbert
In-Reply-To: <5A7D116B.9070502@intel.com>
On Fri, Feb 09, 2018 at 11:11:39AM +0800, Wei Wang wrote:
> On 02/09/2018 03:55 AM, Michael S. Tsirkin wrote:
> > On Thu, Feb 08, 2018 at 05:50:16PM +0800, Wei Wang wrote:
> >
> > > Details:
> > > Set up a Ping-Pong local live migration, where the guest ceaselessy
> > > migrates between the source and destination. Linux compilation,
> > > i.e. make bzImage -j4, is performed during the Ping-Pong migration. The
> > > legacy case takes 5min14s to finish the compilation. With this
> > > optimization patched, it takes 5min12s.
> > How is migration time affected in this case?
>
>
> When the linux compilation workload runs, the migration time (both the
> legacy and this optimization case) varies as the compilation goes on. It
> seems not easy to give a static speedup number, some times the migration
> time is reduced to 33%, sometimes to 50%, it varies, and depends on how much
> free memory the system has at that moment. For example, at the later stage
> of the compilation, I can observe 5GB memory being used as page cache. But
> overall, I can observe obvious improvement of the migration time.
>
>
> Best,
> Wei
You can run multiple tests and give a best, worst and median numbers.
--
MST
^ permalink raw reply
* [PATCH] mm/page_poison: move PAGE_POISON to page_poison.c
From: Wei Wang @ 2018-02-09 8:08 UTC (permalink / raw)
To: linux-kernel, virtualization, linux-mm, mst, mhocko, akpm
The PAGE_POISON macro is used in page_poison.c only, so avoid exporting
it. Also remove the "mm/debug-pagealloc.c" related comment, which is
obsolete.
Signed-off-by: Wei Wang <wei.w.wang@intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Michael S. Tsirkin <mst@redhat.com>
---
include/linux/poison.h | 7 -------
mm/page_poison.c | 6 ++++++
2 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/include/linux/poison.h b/include/linux/poison.h
index 15927eb..348bf67 100644
--- a/include/linux/poison.h
+++ b/include/linux/poison.h
@@ -30,13 +30,6 @@
*/
#define TIMER_ENTRY_STATIC ((void *) 0x300 + POISON_POINTER_DELTA)
-/********** mm/debug-pagealloc.c **********/
-#ifdef CONFIG_PAGE_POISONING_ZERO
-#define PAGE_POISON 0x00
-#else
-#define PAGE_POISON 0xaa
-#endif
-
/********** mm/page_alloc.c ************/
#define TAIL_MAPPING ((void *) 0x400 + POISON_POINTER_DELTA)
diff --git a/mm/page_poison.c b/mm/page_poison.c
index e83fd44..8aaf076 100644
--- a/mm/page_poison.c
+++ b/mm/page_poison.c
@@ -7,6 +7,12 @@
#include <linux/poison.h>
#include <linux/ratelimit.h>
+#ifdef CONFIG_PAGE_POISONING_ZERO
+#define PAGE_POISON 0x00
+#else
+#define PAGE_POISON 0xaa
+#endif
+
static bool want_page_poisoning __read_mostly;
static int early_page_poison_param(char *buf)
--
2.7.4
^ permalink raw reply related
* hong_en@solenw.org
From: Solen win @ 2018-02-09 8:17 UTC (permalink / raw)
To: virtualization
[-- Attachment #1.1: Type: text/plain, Size: 1 bytes --]
[-- Attachment #1.2: Type: text/html, Size: 1 bytes --]
[-- Attachment #2: Type: text/plain, Size: 183 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH v3 1/2] drm/virtio: Add window server support
From: Tomeu Vizoso @ 2018-02-09 11:14 UTC (permalink / raw)
To: Gerd Hoffmann
Cc: Michael S. Tsirkin, David Airlie, linux-kernel, dri-devel,
virtualization, Zach Reizner, kernel
In-Reply-To: <04687943-847b-25a7-42ef-a21b4c7ef0cf@collabora.com>
Hi Gerd and Stefan,
can we reach agreement on whether vsock should be involved in this?
Thanks,
Tomeu
On 02/07/2018 10:49 AM, Tomeu Vizoso wrote:
> On 02/06/2018 03:23 PM, Gerd Hoffmann wrote:
>> Hi,
>>
>>>> Hmm? I'm assuming the wayland client (in the guest) talks to the
>>>> wayland proxy, using the wayland protocol, like it would talk to a
>>>> wayland display server. Buffers must be passed from client to
>>>> server/proxy somehow, probably using fd passing, so where is the
>>>> problem?
>>>>
>>>> Or did I misunderstand the role of the proxy?
>>>
>>> Hi Gerd,
>>>
>>> it's starting to look to me that we're talking a bit past the other, so I
>>> have pasted below a few words describing my current plan regarding the
>>> 3 key
>>> scenarios that I'm addressing.
>>
>> You are describing the details, but I'm missing the big picture ...
>>
>> So, virtualization aside, how do buffers work in wayland? As far I know
>> it goes like this:
>>
>> (a) software rendering: client allocates shared memory buffer, renders
>> into it, then passes a file handle for that shmem block together
>> with some meta data (size, format, ...) to the wayland server.
>>
>> (b) gpu rendering: client opens a render node, allocates a buffer,
>> asks the cpu to renders into it, exports the buffer as dma-buf
>> (DRM_IOCTL_PRIME_HANDLE_TO_FD), passes this to the wayland server
>> (again including meta data of course).
>>
>> Is that correct?
>
> Both are correct descriptions of typical behaviors. But it isn't spec'ed
> anywhere who has to do the buffer allocation.
>
> In practical terms, the buffer allocation happens in either the 2D GUI
> toolkit (gtk+, for example), or the EGL implementation. Someone using
> this in a real product would most probably be interested in avoiding any
> extra copies and make sure that both allocate buffers via virtio-gpu, for
> example.
>
> Depending on the use case, they could be also interested in supporting
> unmodified clients with an extra copy per buffer presentation.
>
> That's to say that if we cannot come up with a zero-copy solution for
> unmodified clients, we should at least support zero-copy for cooperative
> clients.
>
>> Now, with virtualization added to the mix it becomes a bit more
>> complicated. Client and server are unmodified. The client talks to the
>> guest proxy (wayland protocol). The guest proxy talks to the host proxy
>> (protocol to be defined). The host proxy talks to the server (wayland
>> protocol).
>>
>> Buffers must be managed along the way, and we want avoid copying around
>> the buffers. The host proxy could be implemented directly in qemu, or
>> as separate process which cooperates with qemu for buffer management.
>>
>> Fine so far?
>
> Yep.
>
>>> I really think that whatever we come up with needs to support 3D
>>> clients as
>>> well.
>>
>> Lets start with 3d clients, I think these are easier. They simply use
>> virtio-gpu for 3d rendering as usual. When they are done the rendered
>> buffer already lives in a host drm buffer (because virgl runs the actual
>> rendering on the host gpu). So the client passes the dma-buf to the
>> guest proxy, the guest proxy imports it to look up the resource-id,
>> passes the resource-id to the host proxy, the host proxy looks up the
>> drm buffer and exports it as dma-buf, then passes it to the server.
>> Done, without any extra data copies.
>
> Yep.
>
>>> Creation of shareable buffer by guest
>>> -------------------------------------------------
>>>
>>> 1. Client requests virtio driver to create a buffer suitable for sharing
>>> with host (DRM_VIRTGPU_RESOURCE_CREATE)
>>
>> client or guest proxy?
>
> As per the above, the GUI toolkit could have been modified so the client
> directly creates a shareable buffer, and renders directly to it without
> any extra copies.
>
> If clients cannot be modified, then it's the guest proxy what has to
> create the shareable buffer and keep it in sync with the client's
> non-shareable buffer at the right times, by intercepting
> wl_surface.commit messages and copying buffer contents.
>
>>> 4. QEMU maps that buffer to the guest's address space
>>> (KVM_SET_USER_MEMORY_REGION), passes the guest PFN to the virtio driver
>>
>> That part is problematic. The host can't simply allocate something in
>> the physical address space, because most physical address space
>> management is done by the guest. All pci bars are mapped by the guest
>> firmware for example (or by the guest OS in case of hotplug).
>
> How can KVM_SET_USER_MEMORY_REGION ever be safely used then? I would have
> expected that callers of that ioctl have enough knowledge to be able to
> choose a physical address that won't conflict with the guest's kernel.
>
> I see that the ivshmem device in QEMU registers the memory region in BAR
> 2 of a PCI device instead. Would that be better in your opinion?
>
>>> 4. QEMU pops data+buffers from the virtqueue, looks up shmem FD for each
>>> resource, sends data + FDs to the compositor with SCM_RIGHTS
>>
>> BTW: Is there a 1:1 relationship between buffers and shmem blocks? Or
>> does the wayland protocol allow for offsets in buffer meta data, so you
>> can place multiple buffers in a single shmem block?
>
> The latter:
> https://wayland.freedesktop.org/docs/html/apa.html#protocol-spec-wl_shm_pool
>
> Regards,
>
> Tomeu
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH] mm/page_poison: move PAGE_POISON to page_poison.c
From: Michael S. Tsirkin @ 2018-02-09 16:23 UTC (permalink / raw)
To: Wei Wang; +Cc: linux-mm, akpm, mhocko, linux-kernel, virtualization
In-Reply-To: <1518163694-27155-1-git-send-email-wei.w.wang@intel.com>
On Fri, Feb 09, 2018 at 04:08:14PM +0800, Wei Wang wrote:
> The PAGE_POISON macro is used in page_poison.c only, so avoid exporting
> it. Also remove the "mm/debug-pagealloc.c" related comment, which is
> obsolete.
>
> Signed-off-by: Wei Wang <wei.w.wang@intel.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Michal Hocko <mhocko@kernel.org>
> Cc: Michael S. Tsirkin <mst@redhat.com>
> ---
> include/linux/poison.h | 7 -------
> mm/page_poison.c | 6 ++++++
> 2 files changed, 6 insertions(+), 7 deletions(-)
>
> diff --git a/include/linux/poison.h b/include/linux/poison.h
> index 15927eb..348bf67 100644
> --- a/include/linux/poison.h
> +++ b/include/linux/poison.h
> @@ -30,13 +30,6 @@
> */
> #define TIMER_ENTRY_STATIC ((void *) 0x300 + POISON_POINTER_DELTA)
>
> -/********** mm/debug-pagealloc.c **********/
> -#ifdef CONFIG_PAGE_POISONING_ZERO
> -#define PAGE_POISON 0x00
> -#else
> -#define PAGE_POISON 0xaa
> -#endif
> -
> /********** mm/page_alloc.c ************/
>
> #define TAIL_MAPPING ((void *) 0x400 + POISON_POINTER_DELTA)
My question is, why are these macros kept in a single header.
Is it so it's easy to figure out source of a crash by
looking at the data and locating it in the file?
If so we should keep it in the header, but fix the comment.
If no there are more macros to move out, like flex array ones.
> diff --git a/mm/page_poison.c b/mm/page_poison.c
> index e83fd44..8aaf076 100644
> --- a/mm/page_poison.c
> +++ b/mm/page_poison.c
> @@ -7,6 +7,12 @@
> #include <linux/poison.h>
> #include <linux/ratelimit.h>
>
> +#ifdef CONFIG_PAGE_POISONING_ZERO
> +#define PAGE_POISON 0x00
> +#else
> +#define PAGE_POISON 0xaa
> +#endif
> +
> static bool want_page_poisoning __read_mostly;
>
> static int early_page_poison_param(char *buf)
> --
> 2.7.4
^ permalink raw reply
* [PATCH] headers: untangle kmemleak.h from mm.h
From: Randy Dunlap @ 2018-02-12 7:20 UTC (permalink / raw)
To: LKML, Linux MM, Andrew Morton, Fengguang Wu
Cc: linux-s390, John Johansen, netdev@vger.kernel.org, X86 ML,
linux-wireless, virtualization, iommu, Greg Kroah-Hartman,
sparclinux, linuxppc-dev
From: Randy Dunlap <rdunlap@infradead.org>
Currently <linux/slab.h> #includes <linux/kmemleak.h> for no obvious
reason. It looks like it's only a convenience, so remove kmemleak.h
from slab.h and add <linux/kmemleak.h> to any users of kmemleak_*
that don't already #include it.
Also remove <linux/kmemleak.h> from source files that do not use it.
This is tested on i386 allmodconfig and x86_64 allmodconfig. It
would be good to run it through the 0day bot for other $ARCHes.
I have neither the horsepower nor the storage space for the other
$ARCHes.
[slab.h is the second most used header file after module.h; kernel.h
is right there with slab.h. There could be some minor error in the
counting due to some #includes having comments after them and I
didn't combine all of those.]
This is Lingchi patch #1 (death by a thousand cuts, applied to kernel
header files).
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
---
Fengguang, can you have this patch run thru 0day builds, please?
arch/powerpc/sysdev/dart_iommu.c | 1 +
arch/powerpc/sysdev/msi_bitmap.c | 1 +
arch/s390/kernel/nmi.c | 2 +-
arch/s390/kernel/smp.c | 1 -
arch/sparc/kernel/irq_64.c | 1 -
arch/x86/kernel/pci-dma.c | 1 -
drivers/iommu/exynos-iommu.c | 1 +
drivers/iommu/mtk_iommu_v1.c | 1 -
drivers/net/ethernet/ti/cpsw.c | 1 +
drivers/net/wireless/realtek/rtlwifi/pci.c | 1 -
drivers/net/wireless/realtek/rtlwifi/rtl8192c/fw_common.c | 1 -
drivers/staging/rtl8188eu/hal/fw.c | 2 +-
drivers/staging/rtlwifi/pci.c | 1 -
drivers/virtio/virtio_ring.c | 1 -
include/linux/slab.h | 1 -
kernel/ucount.c | 1 +
mm/cma.c | 1 +
mm/memblock.c | 1 +
net/core/sysctl_net_core.c | 1 -
net/ipv4/route.c | 1 -
security/apparmor/lsm.c | 1 -
21 files changed, 9 insertions(+), 14 deletions(-)
--- lnx-416-rc1.orig/include/linux/slab.h
+++ lnx-416-rc1/include/linux/slab.h
@@ -125,7 +125,6 @@
#define ZERO_OR_NULL_PTR(x) ((unsigned long)(x) <= \
(unsigned long)ZERO_SIZE_PTR)
-#include <linux/kmemleak.h>
#include <linux/kasan.h>
struct mem_cgroup;
--- lnx-416-rc1.orig/kernel/ucount.c
+++ lnx-416-rc1/kernel/ucount.c
@@ -10,6 +10,7 @@
#include <linux/slab.h>
#include <linux/cred.h>
#include <linux/hash.h>
+#include <linux/kmemleak.h>
#include <linux/user_namespace.h>
#define UCOUNTS_HASHTABLE_BITS 10
--- lnx-416-rc1.orig/mm/memblock.c
+++ lnx-416-rc1/mm/memblock.c
@@ -17,6 +17,7 @@
#include <linux/poison.h>
#include <linux/pfn.h>
#include <linux/debugfs.h>
+#include <linux/kmemleak.h>
#include <linux/seq_file.h>
#include <linux/memblock.h>
--- lnx-416-rc1.orig/mm/cma.c
+++ lnx-416-rc1/mm/cma.c
@@ -35,6 +35,7 @@
#include <linux/cma.h>
#include <linux/highmem.h>
#include <linux/io.h>
+#include <linux/kmemleak.h>
#include <trace/events/cma.h>
#include "cma.h"
--- lnx-416-rc1.orig/drivers/staging/rtl8188eu/hal/fw.c
+++ lnx-416-rc1/drivers/staging/rtl8188eu/hal/fw.c
@@ -30,7 +30,7 @@
#include "rtl8188e_hal.h"
#include <linux/firmware.h>
-#include <linux/kmemleak.h>
+#include <linux/slab.h>
static void _rtl88e_enable_fw_download(struct adapter *adapt, bool enable)
{
--- lnx-416-rc1.orig/drivers/iommu/exynos-iommu.c
+++ lnx-416-rc1/drivers/iommu/exynos-iommu.c
@@ -17,6 +17,7 @@
#include <linux/io.h>
#include <linux/iommu.h>
#include <linux/interrupt.h>
+#include <linux/kmemleak.h>
#include <linux/list.h>
#include <linux/of.h>
#include <linux/of_iommu.h>
--- lnx-416-rc1.orig/arch/s390/kernel/nmi.c
+++ lnx-416-rc1/arch/s390/kernel/nmi.c
@@ -15,7 +15,7 @@
#include <linux/hardirq.h>
#include <linux/log2.h>
#include <linux/kprobes.h>
-#include <linux/slab.h>
+#include <linux/kmemleak.h>
#include <linux/time.h>
#include <linux/module.h>
#include <linux/sched/signal.h>
--- lnx-416-rc1.orig/arch/powerpc/sysdev/dart_iommu.c
+++ lnx-416-rc1/arch/powerpc/sysdev/dart_iommu.c
@@ -38,6 +38,7 @@
#include <linux/suspend.h>
#include <linux/memblock.h>
#include <linux/gfp.h>
+#include <linux/kmemleak.h>
#include <asm/io.h>
#include <asm/prom.h>
#include <asm/iommu.h>
--- lnx-416-rc1.orig/arch/powerpc/sysdev/msi_bitmap.c
+++ lnx-416-rc1/arch/powerpc/sysdev/msi_bitmap.c
@@ -10,6 +10,7 @@
#include <linux/slab.h>
#include <linux/kernel.h>
+#include <linux/kmemleak.h>
#include <linux/bitmap.h>
#include <linux/bootmem.h>
#include <asm/msi_bitmap.h>
--- lnx-416-rc1.orig/drivers/net/ethernet/ti/cpsw.c
+++ lnx-416-rc1/drivers/net/ethernet/ti/cpsw.c
@@ -35,6 +35,7 @@
#include <linux/of_net.h>
#include <linux/of_device.h>
#include <linux/if_vlan.h>
+#include <linux/kmemleak.h>
#include <linux/pinctrl/consumer.h>
--- lnx-416-rc1.orig/drivers/virtio/virtio_ring.c
+++ lnx-416-rc1/drivers/virtio/virtio_ring.c
@@ -23,7 +23,6 @@
#include <linux/slab.h>
#include <linux/module.h>
#include <linux/hrtimer.h>
-#include <linux/kmemleak.h>
#include <linux/dma-mapping.h>
#include <xen/xen.h>
--- lnx-416-rc1.orig/security/apparmor/lsm.c
+++ lnx-416-rc1/security/apparmor/lsm.c
@@ -23,7 +23,6 @@
#include <linux/sysctl.h>
#include <linux/audit.h>
#include <linux/user_namespace.h>
-#include <linux/kmemleak.h>
#include <net/sock.h>
#include "include/apparmor.h"
--- lnx-416-rc1.orig/drivers/iommu/mtk_iommu_v1.c
+++ lnx-416-rc1/drivers/iommu/mtk_iommu_v1.c
@@ -25,7 +25,6 @@
#include <linux/io.h>
#include <linux/iommu.h>
#include <linux/iopoll.h>
-#include <linux/kmemleak.h>
#include <linux/list.h>
#include <linux/of_address.h>
#include <linux/of_iommu.h>
--- lnx-416-rc1.orig/drivers/staging/rtlwifi/pci.c
+++ lnx-416-rc1/drivers/staging/rtlwifi/pci.c
@@ -31,7 +31,6 @@
#include "efuse.h"
#include <linux/interrupt.h>
#include <linux/export.h>
-#include <linux/kmemleak.h>
#include <linux/module.h>
MODULE_AUTHOR("lizhaoming <chaoming_li@realsil.com.cn>");
--- lnx-416-rc1.orig/drivers/net/wireless/realtek/rtlwifi/pci.c
+++ lnx-416-rc1/drivers/net/wireless/realtek/rtlwifi/pci.c
@@ -31,7 +31,6 @@
#include "efuse.h"
#include <linux/interrupt.h>
#include <linux/export.h>
-#include <linux/kmemleak.h>
#include <linux/module.h>
MODULE_AUTHOR("lizhaoming <chaoming_li@realsil.com.cn>");
--- lnx-416-rc1.orig/drivers/net/wireless/realtek/rtlwifi/rtl8192c/fw_common.c
+++ lnx-416-rc1/drivers/net/wireless/realtek/rtlwifi/rtl8192c/fw_common.c
@@ -32,7 +32,6 @@
#include "../rtl8192ce/def.h"
#include "fw_common.h"
#include <linux/export.h>
-#include <linux/kmemleak.h>
static void _rtl92c_enable_fw_download(struct ieee80211_hw *hw, bool enable)
{
--- lnx-416-rc1.orig/arch/s390/kernel/smp.c
+++ lnx-416-rc1/arch/s390/kernel/smp.c
@@ -27,7 +27,6 @@
#include <linux/err.h>
#include <linux/spinlock.h>
#include <linux/kernel_stat.h>
-#include <linux/kmemleak.h>
#include <linux/delay.h>
#include <linux/interrupt.h>
#include <linux/irqflags.h>
--- lnx-416-rc1.orig/arch/sparc/kernel/irq_64.c
+++ lnx-416-rc1/arch/sparc/kernel/irq_64.c
@@ -22,7 +22,6 @@
#include <linux/seq_file.h>
#include <linux/ftrace.h>
#include <linux/irq.h>
-#include <linux/kmemleak.h>
#include <asm/ptrace.h>
#include <asm/processor.h>
--- lnx-416-rc1.orig/arch/x86/kernel/pci-dma.c
+++ lnx-416-rc1/arch/x86/kernel/pci-dma.c
@@ -6,7 +6,6 @@
#include <linux/bootmem.h>
#include <linux/gfp.h>
#include <linux/pci.h>
-#include <linux/kmemleak.h>
#include <asm/proto.h>
#include <asm/dma.h>
--- lnx-416-rc1.orig/net/core/sysctl_net_core.c
+++ lnx-416-rc1/net/core/sysctl_net_core.c
@@ -15,7 +15,6 @@
#include <linux/vmalloc.h>
#include <linux/init.h>
#include <linux/slab.h>
-#include <linux/kmemleak.h>
#include <net/ip.h>
#include <net/sock.h>
--- lnx-416-rc1.orig/net/ipv4/route.c
+++ lnx-416-rc1/net/ipv4/route.c
@@ -108,7 +108,6 @@
#include <net/rtnetlink.h>
#ifdef CONFIG_SYSCTL
#include <linux/sysctl.h>
-#include <linux/kmemleak.h>
#endif
#include <net/secure_seq.h>
#include <net/ip_tunnels.h>
^ permalink raw reply
* Re: [PATCH] headers: untangle kmemleak.h from mm.h
From: Ingo Molnar @ 2018-02-12 7:27 UTC (permalink / raw)
To: Randy Dunlap
Cc: linux-s390, John Johansen, netdev@vger.kernel.org, X86 ML,
linux-wireless, LKML, virtualization, Linux MM, iommu,
Greg Kroah-Hartman, sparclinux, Andrew Morton, Fengguang Wu,
linuxppc-dev
In-Reply-To: <a4629db7-194d-3c7c-c8fd-24f61b220a70@infradead.org>
* Randy Dunlap <rdunlap@infradead.org> wrote:
> From: Randy Dunlap <rdunlap@infradead.org>
>
> Currently <linux/slab.h> #includes <linux/kmemleak.h> for no obvious
> reason. It looks like it's only a convenience, so remove kmemleak.h
> from slab.h and add <linux/kmemleak.h> to any users of kmemleak_*
> that don't already #include it.
> Also remove <linux/kmemleak.h> from source files that do not use it.
>
> This is tested on i386 allmodconfig and x86_64 allmodconfig. It
> would be good to run it through the 0day bot for other $ARCHes.
> I have neither the horsepower nor the storage space for the other
> $ARCHes.
>
> [slab.h is the second most used header file after module.h; kernel.h
> is right there with slab.h. There could be some minor error in the
> counting due to some #includes having comments after them and I
> didn't combine all of those.]
>
> This is Lingchi patch #1 (death by a thousand cuts, applied to kernel
> header files).
>
> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Nice find:
Reviewed-by: Ingo Molnar <mingo@kernel.org>
I agree that it needs to go through 0-day to find any hidden dependencies we might
have grown due to this.
Thanks,
Ingo
^ permalink raw reply
* Re: [PULL v2 1/1] virtio/s390: implement PM operations for virtio_ccw
From: Christian Borntraeger @ 2018-02-12 8:52 UTC (permalink / raw)
To: Cornelia Huck, mst; +Cc: linux-s390, kvm, virtualization
In-Reply-To: <20171218162123.963-2-cohuck@redhat.com>
Michael, Conny,
it seems that this patch did not make it into 4.16-rc1.
On 12/18/2017 05:21 PM, Cornelia Huck wrote:
> From: Christian Borntraeger <borntraeger@de.ibm.com>
>
> Suspend/Resume to/from disk currently fails. Let us wire
> up the necessary callbacks. This is mostly just forwarding
> the requests to the virtio drivers. The only thing that
> has to be done in virtio_ccw itself is to re-set the
> virtio revision.
>
> Suggested-by: Thomas Huth <thuth@redhat.com>
> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
> Message-Id: <20171207141102.70190-2-borntraeger@de.ibm.com>
> Reviewed-by: David Hildenbrand <david@redhat.com>
> [CH: merged <20171218083706.223836-1-borntraeger@de.ibm.com> to fix
> !CONFIG_PM configs]
> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
> ---
> drivers/s390/virtio/virtio_ccw.c | 29 +++++++++++++++++++++++++++++
> 1 file changed, 29 insertions(+)
>
> diff --git a/drivers/s390/virtio/virtio_ccw.c b/drivers/s390/virtio/virtio_ccw.c
> index b18fe2014cf2..985184ebda45 100644
> --- a/drivers/s390/virtio/virtio_ccw.c
> +++ b/drivers/s390/virtio/virtio_ccw.c
> @@ -1300,6 +1300,9 @@ static int virtio_ccw_cio_notify(struct ccw_device *cdev, int event)
> vcdev->device_lost = true;
> rc = NOTIFY_DONE;
> break;
> + case CIO_OPER:
> + rc = NOTIFY_OK;
> + break;
> default:
> rc = NOTIFY_DONE;
> break;
> @@ -1312,6 +1315,27 @@ static struct ccw_device_id virtio_ids[] = {
> {},
> };
>
> +#ifdef CONFIG_PM_SLEEP
> +static int virtio_ccw_freeze(struct ccw_device *cdev)
> +{
> + struct virtio_ccw_device *vcdev = dev_get_drvdata(&cdev->dev);
> +
> + return virtio_device_freeze(&vcdev->vdev);
> +}
> +
> +static int virtio_ccw_restore(struct ccw_device *cdev)
> +{
> + struct virtio_ccw_device *vcdev = dev_get_drvdata(&cdev->dev);
> + int ret;
> +
> + ret = virtio_ccw_set_transport_rev(vcdev);
> + if (ret)
> + return ret;
> +
> + return virtio_device_restore(&vcdev->vdev);
> +}
> +#endif
> +
> static struct ccw_driver virtio_ccw_driver = {
> .driver = {
> .owner = THIS_MODULE,
> @@ -1324,6 +1348,11 @@ static struct ccw_driver virtio_ccw_driver = {
> .set_online = virtio_ccw_online,
> .notify = virtio_ccw_cio_notify,
> .int_class = IRQIO_VIR,
> +#ifdef CONFIG_PM_SLEEP
> + .freeze = virtio_ccw_freeze,
> + .thaw = virtio_ccw_restore,
> + .restore = virtio_ccw_restore,
> +#endif
> };
>
> static int __init pure_hex(char **cp, unsigned int *val, int min_digit,
>
^ permalink raw reply
* Re: [PATCH v3 1/2] drm/virtio: Add window server support
From: Gerd Hoffmann @ 2018-02-12 11:45 UTC (permalink / raw)
To: Tomeu Vizoso
Cc: Michael S. Tsirkin, David Airlie, linux-kernel, dri-devel,
virtualization, Zach Reizner, kernel
In-Reply-To: <04687943-847b-25a7-42ef-a21b4c7ef0cf@collabora.com>
Hi,
> > (a) software rendering: client allocates shared memory buffer, renders
> > into it, then passes a file handle for that shmem block together
> > with some meta data (size, format, ...) to the wayland server.
> >
> > (b) gpu rendering: client opens a render node, allocates a buffer,
> > asks the cpu to renders into it, exports the buffer as dma-buf
> > (DRM_IOCTL_PRIME_HANDLE_TO_FD), passes this to the wayland server
> > (again including meta data of course).
> >
> > Is that correct?
>
> Both are correct descriptions of typical behaviors. But it isn't spec'ed
> anywhere who has to do the buffer allocation.
Well, according to Pekka's reply it is spec'ed that way, for the
existing buffer types. So for server allocated buffers you need
(a) a wayland protocol extension and (b) support for the extension
in the clients.
> That's to say that if we cannot come up with a zero-copy solution for
> unmodified clients, we should at least support zero-copy for cooperative
> clients.
"cooperative clients" == "client which has support for the wayland
protocol extension", correct?
> > > Creation of shareable buffer by guest
> > > -------------------------------------------------
> > >
> > > 1. Client requests virtio driver to create a buffer suitable for sharing
> > > with host (DRM_VIRTGPU_RESOURCE_CREATE)
> >
> > client or guest proxy?
>
> As per the above, the GUI toolkit could have been modified so the client
> directly creates a shareable buffer, and renders directly to it without any
> extra copies.
>
> If clients cannot be modified, then it's the guest proxy what has to create
> the shareable buffer and keep it in sync with the client's non-shareable
> buffer at the right times, by intercepting wl_surface.commit messages and
> copying buffer contents.
Ok.
> > > 4. QEMU maps that buffer to the guest's address space
> > > (KVM_SET_USER_MEMORY_REGION), passes the guest PFN to the virtio driver
> >
> > That part is problematic. The host can't simply allocate something in
> > the physical address space, because most physical address space
> > management is done by the guest. All pci bars are mapped by the guest
> > firmware for example (or by the guest OS in case of hotplug).
>
> How can KVM_SET_USER_MEMORY_REGION ever be safely used then? I would have
> expected that callers of that ioctl have enough knowledge to be able to
> choose a physical address that won't conflict with the guest's kernel.
Depends on the kind of region. Guest RAM is allocated and mapped by
qemu, guest firmware can query qemu about RAM mappings using a special
interface, then create a e820 memory map for the guest os. PCI device
bars are mapped according to the pci config space registers, which in
turn are initialized by the guest firmware, so it is basically in the
guests hand where they show up.
> I see that the ivshmem device in QEMU registers the memory region in BAR 2
> of a PCI device instead. Would that be better in your opinion?
Yes.
> > > 4. QEMU pops data+buffers from the virtqueue, looks up shmem FD for each
> > > resource, sends data + FDs to the compositor with SCM_RIGHTS
> >
> > BTW: Is there a 1:1 relationship between buffers and shmem blocks? Or
> > does the wayland protocol allow for offsets in buffer meta data, so you
> > can place multiple buffers in a single shmem block?
>
> The latter:
> https://wayland.freedesktop.org/docs/html/apa.html#protocol-spec-wl_shm_pool
Ah, good, that makes it alot easier.
So, yes, using ivshmem would be one option. Tricky part here is the
buffer management though. It's just a raw piece of memory. The guest
proxy could mmap the pci bar and manage it. But then it is again either
unmodified guest + copying the data, or modified client (which requests
buffers from guest proxy) for zero-copy.
Another idea would be extending stdvga. Basically qemu would have to
use shmem as backing storage for vga memory instead of anonymous memory,
so it would be very simliar to ivshmem on the host side. But on the
guest side we have a drm driver for it (bochs-drm). So clients can
allocate dumb drm buffers for software rendering, and the buffer would
already be backed by a host shmem segment. Given that wayland already
supports drm buffers for 3d rendering that could work without extending
the wayland protocol. The client proxy would have to translate the drm
buffer into an pci bar offset and pass it to the host side. The host
proxy could register the pci bar as wl_shm_pool, then just pass through
the offset to reference the individual buffers.
Drawback of both approaches would be that software rendering and gpu
rendering would use quite different code paths.
We also need a solution for the keymap shmem block. I guess the keymap
doesn't change all that often, so maybe it is easiest to just copy it
over (host proxy -> guest proxy) instead of trying to map the host shmem
into the guest?
cheers,
Gerd
^ permalink raw reply
* Re: [PATCH v3 1/2] drm/virtio: Add window server support
From: Gerd Hoffmann @ 2018-02-12 11:52 UTC (permalink / raw)
To: Tomeu Vizoso
Cc: Michael S. Tsirkin, David Airlie, linux-kernel, dri-devel,
virtualization, Zach Reizner, kernel
In-Reply-To: <38880e66-b676-1170-c2ca-5a5603c5b521@collabora.com>
Hi,
> can we reach agreement on whether vsock should be involved in this?
I think the best approach would be to have guest proxy and host proxy
use vsock for the wayland protocol. Use a wayland protocol extension to
reference the buffers in stdvga / ivshmem / virtio-gpu. Only the two
proxies need to understand the extension, the client <=> guest proxy and
host proxy <=> server communication would be standard wayland protocol.
cheers,
Gerd
^ permalink raw reply
* Re: [PATCH] headers: untangle kmemleak.h from mm.h
From: Michael Ellerman @ 2018-02-12 12:28 UTC (permalink / raw)
To: Randy Dunlap, LKML, Linux MM, Andrew Morton, Fengguang Wu
Cc: linux-s390, John Johansen, netdev@vger.kernel.org, X86 ML,
linux-wireless, virtualization, iommu, Greg Kroah-Hartman,
sparclinux, linuxppc-dev
In-Reply-To: <a4629db7-194d-3c7c-c8fd-24f61b220a70@infradead.org>
Randy Dunlap <rdunlap@infradead.org> writes:
> From: Randy Dunlap <rdunlap@infradead.org>
>
> Currently <linux/slab.h> #includes <linux/kmemleak.h> for no obvious
> reason. It looks like it's only a convenience, so remove kmemleak.h
> from slab.h and add <linux/kmemleak.h> to any users of kmemleak_*
> that don't already #include it.
> Also remove <linux/kmemleak.h> from source files that do not use it.
>
> This is tested on i386 allmodconfig and x86_64 allmodconfig. It
> would be good to run it through the 0day bot for other $ARCHes.
> I have neither the horsepower nor the storage space for the other
> $ARCHes.
>
> [slab.h is the second most used header file after module.h; kernel.h
> is right there with slab.h. There could be some minor error in the
> counting due to some #includes having comments after them and I
> didn't combine all of those.]
>
> This is Lingchi patch #1 (death by a thousand cuts, applied to kernel
> header files).
>
> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
I threw it at a random selection of configs and so far the only failures
I'm seeing are:
lib/test_firmware.c:134:2: error: implicit declaration of function 'vfree' [-Werror=implicit-function-declaration]
lib/test_firmware.c:620:25: error: implicit declaration of function 'vzalloc' [-Werror=implicit-function-declaration]
lib/test_firmware.c:620:2: error: implicit declaration of function 'vzalloc' [-Werror=implicit-function-declaration]
security/integrity/digsig.c:146:2: error: implicit declaration of function 'vfree' [-Werror=implicit-function-declaration]
Full results trickling in here, not all the failures there are caused by
this patch, ie. some configs are broken in mainline:
http://kisskb.ellerman.id.au/kisskb/head/13396/
cheers
^ permalink raw reply
* Re: [PATCH v3 1/2] drm/virtio: Add window server support
From: Tomeu Vizoso @ 2018-02-12 14:00 UTC (permalink / raw)
To: Gerd Hoffmann
Cc: Michael S. Tsirkin, David Airlie, linux-kernel, dri-devel,
virtualization, Zach Reizner, kernel
In-Reply-To: <20180212115242.z3qv5uejbnhgvd6o@sirius.home.kraxel.org>
On 02/12/2018 12:52 PM, Gerd Hoffmann wrote:
> Hi,
>
>> can we reach agreement on whether vsock should be involved in this?
>
> I think the best approach would be to have guest proxy and host proxy
> use vsock for the wayland protocol. Use a wayland protocol extension to
> reference the buffers in stdvga / ivshmem / virtio-gpu. Only the two
> proxies need to understand the extension, the client <=> guest proxy and
> host proxy <=> server communication would be standard wayland protocol.
Thanks for the ideas. What I haven't understood yet is how you see the
actual passing of buffers via vsock. Are you thinking of using ancillary
data to pass FDs, or something else?
Thanks,
Tomeu
^ permalink raw reply
* Re: [PATCH v3 1/2] drm/virtio: Add window server support
From: Gerd Hoffmann @ 2018-02-12 14:27 UTC (permalink / raw)
To: Tomeu Vizoso
Cc: Michael S. Tsirkin, David Airlie, linux-kernel, dri-devel,
virtualization, Zach Reizner, kernel
In-Reply-To: <eea72b9d-d180-6a57-81ce-4366dc0f2bcc@collabora.com>
On Mon, Feb 12, 2018 at 03:00:24PM +0100, Tomeu Vizoso wrote:
> On 02/12/2018 12:52 PM, Gerd Hoffmann wrote:
> > Hi,
> >
> > > can we reach agreement on whether vsock should be involved in this?
> >
> > I think the best approach would be to have guest proxy and host proxy
> > use vsock for the wayland protocol. Use a wayland protocol extension to
> > reference the buffers in stdvga / ivshmem / virtio-gpu. Only the two
> > proxies need to understand the extension, the client <=> guest proxy and
> > host proxy <=> server communication would be standard wayland protocol.
>
> Thanks for the ideas. What I haven't understood yet is how you see the
> actual passing of buffers via vsock. Are you thinking of using ancillary
> data to pass FDs, or something else?
I was more thinking about a struct containing enough info to allow the
proxy on the host side find the buffer, something like:
struct {
enum type { stdvga, virtio-cpu, ... }
pcislot device;
union {
int stdvga_pcibar_offset;
int virtio_gpu_resource_id;
}
}
So when the guest proxy gets a message with a fd referencing a buffer it
would have to figure where the buffer is, rewrite the message into the
struct above for the host proxy. The host proxy would rewrite the
message again for the server.
cheers,
Gerd
^ permalink raw reply
* Re: [PATCH v3 1/2] drm/virtio: Add window server support
From: Tomeu Vizoso @ 2018-02-12 14:42 UTC (permalink / raw)
To: Gerd Hoffmann
Cc: Michael S. Tsirkin, David Airlie, linux-kernel, dri-devel,
virtualization, Zach Reizner, kernel
In-Reply-To: <20180212142730.g2646v77qsvzd5ff@sirius.home.kraxel.org>
On 02/12/2018 03:27 PM, Gerd Hoffmann wrote:
> On Mon, Feb 12, 2018 at 03:00:24PM +0100, Tomeu Vizoso wrote:
>> On 02/12/2018 12:52 PM, Gerd Hoffmann wrote:
>>> Hi,
>>>
>>>> can we reach agreement on whether vsock should be involved in this?
>>>
>>> I think the best approach would be to have guest proxy and host proxy
>>> use vsock for the wayland protocol. Use a wayland protocol extension to
>>> reference the buffers in stdvga / ivshmem / virtio-gpu. Only the two
>>> proxies need to understand the extension, the client <=> guest proxy and
>>> host proxy <=> server communication would be standard wayland protocol.
>>
>> Thanks for the ideas. What I haven't understood yet is how you see the
>> actual passing of buffers via vsock. Are you thinking of using ancillary
>> data to pass FDs, or something else?
>
> I was more thinking about a struct containing enough info to allow the
> proxy on the host side find the buffer, something like:
>
> struct {
> enum type { stdvga, virtio-cpu, ... }
> pcislot device;
> union {
> int stdvga_pcibar_offset;
> int virtio_gpu_resource_id;
> }
> }
>
> So when the guest proxy gets a message with a fd referencing a buffer it
> would have to figure where the buffer is, rewrite the message into the
> struct above for the host proxy. The host proxy would rewrite the
> message again for the server.
What I don't understand yet is how we can keep the buffer descriptions
together with the protocol data that references them.
With SCM_RIGHTS, the FDs are placed in the ancillary data that "travels"
together with the protocol data that references them.
With the present series, the DRM_IOCTL_VIRTGPU_WINSRV_TX ioctl struct has
a field for the protocol data and an array of FDs.
How are you proposing to pass instances of that struct from above along
the protocol data that refers to them?
Thanks,
Tomeu
^ permalink raw reply
* Re: [PATCH v3 1/2] drm/virtio: Add window server support
From: Gerd Hoffmann @ 2018-02-12 15:29 UTC (permalink / raw)
To: Tomeu Vizoso
Cc: Michael S. Tsirkin, David Airlie, linux-kernel, dri-devel,
virtualization, Zach Reizner, kernel
In-Reply-To: <6cf0c06a-b884-3251-166b-6ff3dec3ebc7@collabora.com>
> > I was more thinking about a struct containing enough info to allow the
> > proxy on the host side find the buffer, something like:
> >
> > struct {
> > enum type { stdvga, virtio-cpu, ... }
> > pcislot device;
> > union {
> > int stdvga_pcibar_offset;
> > int virtio_gpu_resource_id;
> > }
> > }
> >
> > So when the guest proxy gets a message with a fd referencing a buffer it
> > would have to figure where the buffer is, rewrite the message into the
> > struct above for the host proxy. The host proxy would rewrite the
> > message again for the server.
>
> What I don't understand yet is how we can keep the buffer descriptions
> together with the protocol data that references them.
>
> With SCM_RIGHTS, the FDs are placed in the ancillary data that "travels"
> together with the protocol data that references them.
Place the buffer description into the wayland extension protocol messages?
i.e. have some wl_virt_proxy protocol extension. Then, for the stdvga case:
(1) client sends wl_drm/create_prime_buffer request to the guest proxy
(2) guest proxy rewrites this into wl_virt_proxy/create_buffer, or
maybe a create_stdvga_buffer request, carrying all the information
listed above, and sends it to the host proxy.
(3) host proxy rewrites it again into a wl_shm_pool/create_buffer and
forwards it to the server.
cheers,
Gerd
^ permalink raw reply
* Re: [PATCH] headers: untangle kmemleak.h from mm.h
From: Randy Dunlap @ 2018-02-12 19:40 UTC (permalink / raw)
To: Michael Ellerman, LKML, Linux MM, Andrew Morton, Fengguang Wu
Cc: linux-s390, John Johansen, netdev@vger.kernel.org, X86 ML,
linux-wireless, virtualization, iommu, Dmitry Kasatkin,
Greg Kroah-Hartman, sparclinux, linuxppc-dev
In-Reply-To: <87zi4ev1d2.fsf@concordia.ellerman.id.au>
On 02/12/2018 04:28 AM, Michael Ellerman wrote:
> Randy Dunlap <rdunlap@infradead.org> writes:
>
>> From: Randy Dunlap <rdunlap@infradead.org>
>>
>> Currently <linux/slab.h> #includes <linux/kmemleak.h> for no obvious
>> reason. It looks like it's only a convenience, so remove kmemleak.h
>> from slab.h and add <linux/kmemleak.h> to any users of kmemleak_*
>> that don't already #include it.
>> Also remove <linux/kmemleak.h> from source files that do not use it.
>>
>> This is tested on i386 allmodconfig and x86_64 allmodconfig. It
>> would be good to run it through the 0day bot for other $ARCHes.
>> I have neither the horsepower nor the storage space for the other
>> $ARCHes.
>>
>> [slab.h is the second most used header file after module.h; kernel.h
>> is right there with slab.h. There could be some minor error in the
>> counting due to some #includes having comments after them and I
>> didn't combine all of those.]
>>
>> This is Lingchi patch #1 (death by a thousand cuts, applied to kernel
>> header files).
>>
>> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
>
> I threw it at a random selection of configs and so far the only failures
> I'm seeing are:
>
> lib/test_firmware.c:134:2: error: implicit declaration of function 'vfree' [-Werror=implicit-function-declaration]
> lib/test_firmware.c:620:25: error: implicit declaration of function 'vzalloc' [-Werror=implicit-function-declaration]
> lib/test_firmware.c:620:2: error: implicit declaration of function 'vzalloc' [-Werror=implicit-function-declaration]
> security/integrity/digsig.c:146:2: error: implicit declaration of function 'vfree' [-Werror=implicit-function-declaration]
>
Both of those source files need to #include <linux/vmalloc.h>.
> Full results trickling in here, not all the failures there are caused by
> this patch, ie. some configs are broken in mainline:
>
> http://kisskb.ellerman.id.au/kisskb/head/13396/
>
> cheers
:)
--
~Randy
^ permalink raw reply
* Re: [PATCH] headers: untangle kmemleak.h from mm.h
From: Randy Dunlap @ 2018-02-12 21:16 UTC (permalink / raw)
To: Michael Ellerman, LKML, Linux MM, Andrew Morton, Fengguang Wu
Cc: linux-s390, John Johansen, netdev@vger.kernel.org, X86 ML,
linux-wireless, virtualization, iommu, Greg Kroah-Hartman,
sparclinux, linuxppc-dev
In-Reply-To: <87zi4ev1d2.fsf@concordia.ellerman.id.au>
On 02/12/2018 04:28 AM, Michael Ellerman wrote:
> Randy Dunlap <rdunlap@infradead.org> writes:
>
>> From: Randy Dunlap <rdunlap@infradead.org>
>>
>> Currently <linux/slab.h> #includes <linux/kmemleak.h> for no obvious
>> reason. It looks like it's only a convenience, so remove kmemleak.h
>> from slab.h and add <linux/kmemleak.h> to any users of kmemleak_*
>> that don't already #include it.
>> Also remove <linux/kmemleak.h> from source files that do not use it.
>>
>> This is tested on i386 allmodconfig and x86_64 allmodconfig. It
>> would be good to run it through the 0day bot for other $ARCHes.
>> I have neither the horsepower nor the storage space for the other
>> $ARCHes.
>>
>> [slab.h is the second most used header file after module.h; kernel.h
>> is right there with slab.h. There could be some minor error in the
>> counting due to some #includes having comments after them and I
>> didn't combine all of those.]
>>
>> This is Lingchi patch #1 (death by a thousand cuts, applied to kernel
>> header files).
>>
>> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
>
> I threw it at a random selection of configs and so far the only failures
> I'm seeing are:
>
> lib/test_firmware.c:134:2: error: implicit declaration of function 'vfree' [-Werror=implicit-function-declaration]
> lib/test_firmware.c:620:25: error: implicit declaration of function 'vzalloc' [-Werror=implicit-function-declaration]
> lib/test_firmware.c:620:2: error: implicit declaration of function 'vzalloc' [-Werror=implicit-function-declaration]
> security/integrity/digsig.c:146:2: error: implicit declaration of function 'vfree' [-Werror=implicit-function-declaration]
>
> Full results trickling in here, not all the failures there are caused by
> this patch, ie. some configs are broken in mainline:
>
> http://kisskb.ellerman.id.au/kisskb/head/13396/
That's very useful, thanks.
I'll send a few patches for those.
--
~Randy
^ permalink raw reply
* Re: [PATCH v3 1/2] drm/virtio: Add window server support
From: Pekka Paalanen @ 2018-02-13 7:41 UTC (permalink / raw)
To: Gerd Hoffmann
Cc: Tomeu Vizoso, Michael S. Tsirkin, David Airlie, linux-kernel,
dri-devel, virtualization, kernel
In-Reply-To: <20180212114540.iygbha554busy4ip@sirius.home.kraxel.org>
[-- Attachment #1.1: Type: text/plain, Size: 1849 bytes --]
On Mon, 12 Feb 2018 12:45:40 +0100
Gerd Hoffmann <kraxel@redhat.com> wrote:
> Hi,
>
> > > (a) software rendering: client allocates shared memory buffer, renders
> > > into it, then passes a file handle for that shmem block together
> > > with some meta data (size, format, ...) to the wayland server.
> > >
> > > (b) gpu rendering: client opens a render node, allocates a buffer,
> > > asks the cpu to renders into it, exports the buffer as dma-buf
> > > (DRM_IOCTL_PRIME_HANDLE_TO_FD), passes this to the wayland server
> > > (again including meta data of course).
> > >
> > > Is that correct?
> >
> > Both are correct descriptions of typical behaviors. But it isn't spec'ed
> > anywhere who has to do the buffer allocation.
>
> Well, according to Pekka's reply it is spec'ed that way, for the
> existing buffer types. So for server allocated buffers you need
> (a) a wayland protocol extension and (b) support for the extension
> in the clients.
Correct. Or simply a libEGL that uses such Wayland extension behind
everyone's back. I believe such things did at least exist, but are
probably not relevant for this discussion.
(If there is a standard library, like libEGL, loaded and used by both a
server and a client, that library can advertise custom private Wayland
protocol extensions and the client side can take advantage of them,
both without needing any code changes on either the server or the
client.)
> We also need a solution for the keymap shmem block. I guess the keymap
> doesn't change all that often, so maybe it is easiest to just copy it
> over (host proxy -> guest proxy) instead of trying to map the host shmem
> into the guest?
Yes, I believe that would be a perfectly valid solution for that
particular case.
Thanks,
pq
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 183 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox