Re: [Xen-devel] Re: More virtio users

Hi, Framebuffer is an interesting one. Virtio doesn't assume shared memory, so naively the fb you would just send outbufs describing changed memory. This would work, but describing rectangles is better. A helper might be the right approach here Rectangles work just fine for a framebuffer

Re: [PATCH RFC] add domain builder support for bzImage kernels

Hi, +if ( dom-parms.bsd_symtab ) +xc_dom_load_elf_symtab(dom, elf, 1); You can just drop that. The elf symtab stuff is used by BSD kernels only, it is never ever used with Linux and thus not required for the (linux-only) bzImage loader. cheers, Gerd

Re: Next steps with pv_ops for Xen

Stephen C. Tweedie wrote: Hi all, driver domains Looked at the gntdev (grant table mappings for user space) driver, noticed that one is not self-contained. It needs a hook for page unmapping: http://xenbits.xensource.com/xen-3.1-testing.hg?rev/7180d2e61f92 plus an

Re: [Xen-devel] Re: Next steps with pv_ops for Xen

Derek Murray wrote: I take the blame for that one. I added the hook because, if a process were to die whilst holding one or more grants, there were no hooks that would make it possible to carry out the grant-unmap. All existing hooks on either the device or the VMA were called *after* the PTEs

Re: [Xen-devel] Re: Next steps with pv_ops for Xen

Derek Murray wrote: Gerd Hoffmann wrote: Oh, for me it isn't robust at all, it crashes on the first munmap syscall. It is the Fedora 8 kernel. See attachment. Didn't try xensource 2.6.18 yet. My gut feeling is that something changed in mm between 2.6.18 and 2.6.21, but that seems like

Re: [Xen-devel] Re: Next steps with pv_ops for Xen

Stephen C. Tweedie wrote: Hi, On Tue, 2007-12-04 at 13:01 +0100, Gerd Hoffmann wrote: Who uses the gntdev device right now? Good question! I'm aware of it being used in a few research projects, and it seems to work for them (though I think it is mostly used with the linux-2.6.18-xen

Re: [Xen-devel] Re: Next steps with pv_ops for Xen

Alternatively, could we use the _PAGE_GNTTAB PTE flag that is used for debugging? Indeed, if we did this, could be obviate the need for the PTE-zapping hook, by instead catching the case where this flag is set, and unmapping the grant implicitly? Well, in the general case you don't have

Re: [Xen-devel] Re: Next steps with pv_ops for Xen

Hi, gntdev doesn't even try to handle forking. I wouldn't be surprised if that is a great way to kill Domain-0. The xen hypervisor will most likely not be amused to find a pte refering to a granted (but foreign) page which wasn't established using the grant table interface. Pinning the

Re: [Xen-devel] Re: Next steps with pv_ops for Xen

D.G. Murray wrote: Hi Mark, Maybe a change to the gntdev userspace API to allow batching of mapping requests? Something along the lines of the following? void *xc_gnttab_map_grant_refs(int xcg_handle, uint32_t count,

[PATCH 1/4] Add helper functions for paravirtual clocksources.

The helper functions are intended to be used by both xen and kvm paravirtual clock sources. Following patches of this series put them into use. They are based on the xen code. Cc: Jeremy Fitzhardinge [EMAIL PROTECTED] Signed-off-by: Gerd Hoffmann [EMAIL PROTECTED] --- arch/x86/Kconfig

[PATCH 0/4] paravirt clock series.

Respin of the paravirt clock patch series. On the host side the kvm paravirt clock is made compatible with the xen clock. On the guest side some xen code has been factored out into a separate source file shared by both kvm and xen clock implementations. This time it should work ok for kvm smp

[PATCH 2/4] Make xen use the generic paravirt clocksource code.

This patch switches the xen paravirt clock over to use the generic paravirt clock code. Cc: Jeremy Fitzhardinge [EMAIL PROTECTED] Signed-off-by: Gerd Hoffmann [EMAIL PROTECTED] --- arch/x86/xen/Kconfig |1 + arch/x86/xen/time.c | 110 +- 2

Re: [kvm-devel] [PATCH 3/4] kvm/host: fix paravirt clocksource to be compatible with xen.

Avi Kivity wrote: +struct timespec now,sys,boot; Add spaces. Done. +#if 0 +/* Hmm, getboottime() isn't exported to modules ... */ +getboottime(boot); +#else +now = current_kernel_time(); +ktime_get_ts(sys); +boot = ns_to_timespec(timespec_to_ns(now) -

[PATCH 2/4] Make xen use the generic paravirt clocksource code.

Signed-off-by: Gerd Hoffmann [EMAIL PROTECTED] --- arch/x86/xen/Kconfig |1 + arch/x86/xen/time.c | 110 +- 2 files changed, 12 insertions(+), 99 deletions(-) diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig index 2e641be..3a4f16a

[PATCH 0/4] paravirt clock source patches, #3

paravirt clock source patches, next round, with a bunch of changes in the host code according to Avi's review comments and some minor code tweaks. cheers, Gerd ___ Virtualization mailing list Virtualization@lists.linux-foundation.org

[PATCH 4/4] kvm/guest: fix paravirt clocksource to be compartible with xen.

Signed-off-by: Gerd Hoffmann [EMAIL PROTECTED] --- arch/x86/Kconfig |1 + arch/x86/kernel/kvmclock.c | 86 --- 2 files changed, 33 insertions(+), 54 deletions(-) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index deb3049..b749c85

[PATCH 1/4] Add helper functions for paravirtual clocksources.

Signed-off-by: Gerd Hoffmann [EMAIL PROTECTED] --- arch/x86/Kconfig |4 + arch/x86/kernel/Makefile |1 + arch/x86/kernel/pvclock.c | 148 + include/asm-x86/pvclock.h |6 ++ 4 files changed, 159 insertions(+), 0 deletions

kvm-lite, lguest64: status?

Hi, Just a quick question: What is the status of the two projects in $subject? Havn't heared anything for a while for both ... cheers, Gerd -- http://kraxel.fedorapeople.org/xenner/ ___ Virtualization mailing list

[PATCH 1/5] Add structs and functions for paravirt clocksource.

CONFIG_PARAVIRT_CLOCK. Subsequent patches of this series will put the code in use. Signed-off-by: Gerd Hoffmann [EMAIL PROTECTED] --- arch/x86/Kconfig |4 + arch/x86/kernel/Makefile |1 + arch/x86/kernel/pvclock.c | 141 + include/asm-x86/pvclock

[PATCH 2/5] Make xen use the paravirt clocksource structs and functions.

This patch updates the xen guest to use the pvclock structs and helper functions. Signed-off-by: Gerd Hoffmann [EMAIL PROTECTED] --- arch/x86/xen/Kconfig|1 + arch/x86/xen/time.c | 130 --- include/xen/interface/xen.h |5 +- 3

[PATCH 4/5] Make kvm guest use the paravirt clocksource structs and functions.

registering the physical address within the host. Signed-off-by: Gerd Hoffmann [EMAIL PROTECTED] --- arch/x86/Kconfig |1 + arch/x86/kernel/kvmclock.c | 91 --- 2 files changed, 35 insertions(+), 57 deletions(-) diff --git a/arch/x86/Kconfig b

[PATCH 5/5] Remove now unused structs from kvm_para.h

The kvm_* structs are obsoleted by the pvclock_* ones. Now all users have been switched over and the old structs can be dropped. Signed-off-by: Gerd Hoffmann [EMAIL PROTECTED] --- include/asm-x86/kvm_para.h | 18 -- 1 files changed, 0 insertions(+), 18 deletions(-) diff --git

[PATCH 0/5] paravirt clock source patches, #4

paravirt clock source patches, next round. There is now a pvclock-abi.h file with the structs and some longish comments in it and everybody is switched over to use the stuff in there. cheers, Gerd ___ Virtualization mailing list

[PATCH 3/5] Make kvm host use the paravirt clocksource structs.

This patch updates the kvm host code to use the pvclock structs. It also makes the paravirt clock compatible with Xen. Signed-off-by: Gerd Hoffmann [EMAIL PROTECTED] --- arch/x86/kvm/x86.c | 75 --- include/asm-x86/kvm_host.h |4 ++- 2 files

Re: [PATCH 0/5] paravirt clock source patches, #4

Jeremy Fitzhardinge wrote: Gerd Hoffmann wrote: paravirt clock source patches, next round. There is now a pvclock-abi.h file with the structs and some longish comments in it and everybody is switched over to use the stuff in there. This all looks pretty good. How do you want this to get

Re: [PATCH 0/5] paravirt clock source patches, #4

Jeremy Fitzhardinge wrote: Gerd Hoffmann wrote: paravirt clock source patches, next round. There is now a pvclock-abi.h file with the structs and some longish comments in it and everybody is switched over to use the stuff in there. This all looks pretty good. How do you want this to get

[PATCH 3/5] Make kvm host use the paravirt clocksource structs.

This patch updates the kvm host code to use the pvclock structs. It also makes the paravirt clock compatible with Xen. Signed-off-by: Gerd Hoffmann [EMAIL PROTECTED] --- arch/x86/kvm/x86.c | 75 --- include/asm-x86/kvm_host.h |4 ++- 2 files

[PATCH 5/5] Remove now unused structs from kvm_para.h

The kvm_* structs are obsoleted by the pvclock_* ones. Now all users have been switched over and the old structs can be dropped. Signed-off-by: Gerd Hoffmann [EMAIL PROTECTED] --- include/asm-x86/kvm_para.h | 18 -- 1 files changed, 0 insertions(+), 18 deletions(-) diff --git

[PATCH 2/5] Make xen use the paravirt clocksource structs and functions.

This patch updates the xen guest to use the pvclock structs and helper functions. Signed-off-by: Gerd Hoffmann [EMAIL PROTECTED] --- arch/x86/xen/Kconfig|1 + arch/x86/xen/time.c | 132 --- include/xen/interface/xen.h |7 +- 3

[PATCH 0/5] paravirt clock source patches, #5

paravirt clock source patches, next round. There is now a pvclock-abi.h file with the structs and some longish comments in it and everybody is switched over to use the stuff in there. Some minor tweaks after super-fast review by Jeremy. The queue is on top of the kvm git tree. The first two

[PATCH 1/5] Add structs and functions for paravirt clocksource.

CONFIG_PARAVIRT_CLOCK. Subsequent patches of this series will put the code in use. Signed-off-by: Gerd Hoffmann [EMAIL PROTECTED] --- arch/x86/Kconfig |4 + arch/x86/kernel/Makefile |1 + arch/x86/kernel/pvclock.c | 141 + include/asm-x86/pvclock

[PATCH 4/5] Make kvm guest use the paravirt clocksource structs and functions.

registering the physical address within the host. Signed-off-by: Gerd Hoffmann [EMAIL PROTECTED] --- arch/x86/Kconfig |1 + arch/x86/kernel/kvmclock.c | 91 --- 2 files changed, 35 insertions(+), 57 deletions(-) diff --git a/arch/x86/Kconfig b

Re: [PATCH 0/2] Paravirt loops per jiffy calculation

Hi, Turns out that only implementing a pv get_tsc_khz is not enough, since it will only do the right thing for cpu0, which is not what we desire. So we set preset_lpj. Recall this code is run before arch parameter setup, so if we pass lpj=xx in the command line, it'll still work. Hmm,

Re: Configuration vs. compat hints [was Re: [Qemu-devel] [PATCHv3 03/13] qemu: add routines to manage PCI capabilities]

Hi, Yes, the user build the machine using the command line and monitor (or, in 2017, the machine configuration file), Considering pbrook just posted a machine config for arm, I think it would be rather sad if pc wasn't converted to it by 2017... It shouldn't last until 2017, but the

Re: [Qemu-devel] Re: virtio-serial: An interface for host-guest communication

On 08/10/09 15:02, Anthony Liguori wrote: I think you're missing my fundamental point. Don't use the kernel as the guest interface. Introduce a userspace daemon that exposes a domain socket. Then we can have a proper protocol that uses reverse fqdns for identification. We need nothing but

Re: [Qemu-devel] Re: virtio-serial: An interface for host-guest communication

On 08/10/09 16:20, Anthony Liguori wrote: Gerd Hoffmann wrote: Do we really want design a daemon and a protocol for such a simple thing? Yes, because we also need (c) the ability to write cross platform software that targets vmchannel. So having a library interface is going to be extremely

Re: [Qemu-devel] Re: virtio-serial: An interface for host-guest communication

On 08/10/09 16:27, Anthony Liguori wrote: I think my fundamental argument boils down to two points. 1) we should not require new guest drivers unless we absolutely have to Allow guest drivers is fine though I guess? 2) we should always do things in userspace unless we absolutely have to do

Re: [Qemu-devel] Re: virtio-serial: An interface for host-guest communication

On 08/14/09 10:15, Amit Shah wrote: The guest code sort-of ends up looking like this after merging virtio_console into virtio_serial. I think it should better go the other way around: add multichannel support to virtio-concole, probably guarded by a feature flag so old host+new guest and new

Re: [Qemu-devel] Re: virtio-serial: An interface for host-guest communication

On 08/20/09 09:31, Rusty Russell wrote: On Sat, 15 Aug 2009 01:55:32 am Anthony Liguori wrote: Gerd Hoffmann wrote: Also I still think passing a 'protocol' string for each port is a good idea, so you can stick that into a sysfs file for guests use. Or drops ports altogether and just use

Re: [Qemu-devel] Re: virtio-serial: An interface for host-guest communication

On 08/25/09 14:43, Rusty Russell wrote: On Thu, 20 Aug 2009 05:14:29 pm Gerd Hoffmann wrote: I think strings are better as numbers for identifying protocols as you can work without a central registry for the numbers then. Yep, all you need is a central registry for names :) There are schemes

Re: [PATCH] virtio_console: Add support for multiple ports for generic guest and host communication

On 09/15/09 14:57, Anthony Liguori wrote: That's probably not what we want. I imagine what we want is: /dev/ttyV0 /dev/ttyV1 /dev/ttyVN Yes. And then we want: /sys/class/virtio-console/ttyV0/name - org.qemu.clipboard Yes. Userspace can detect when new virtio-consoles appear via udev

Re: [PATCH] virtio_console: Add support for multiple ports for generic guest and host communication

On 09/18/09 19:55, Anthony Liguori wrote: So you need break, parity ... no be serious please Sure, why not? In QEMU, we have the ability to hook our devices directly to a physical serial device and we pass through break, parity, and the other serial device properties. Yes for a emulated

Re: [Qemu-devel] [PATCH 2/4] megasas: LSI MegaRAID SAS HBA emulation

Hi, +/* The current Qemu infrastructure allows only for LUN 0 */ +if (lun == 0 target MAX_RAID_DEVS) + cmd-lun =s-luns[target]; One more thing which should be fixed in qemu instead of worked around in your driver. After all even good old parallel scsi knows multiple luns.

Re: [Qemu-devel] [PATCH 0/4] megaraid_sas HBA emulation

Hi, In order to support SCSI command emulation I had to update / patch up the existing SCSI disk support. This might be not to everyones taste, so I'm open to alternative suggestions. But I certainly do _not_ want to update the SCSI disk emulation, as this is really quite tied to the

Re: [Qemu-devel] [PATCH 0/4] megaraid_sas HBA emulation

On 10/29/09 05:37, Christoph Hellwig wrote: So something like - Get next request - Attach iovec/bounc-buffer - handle request (command/write/read) - complete request (callback) Btw, from some previuous attempts to sort out this code here are some thing that I think would be beneficial:

Re: [Qemu-devel] [PATCH 0/4] megaraid_sas HBA emulation

Hi, When they do, poke me and I'll make sure to process them quickly. Just sent. One of my short term goals is to get better at handling easy patches more quickly. Great. /me tests the new process ;) cheers, Gerd ___ Virtualization mailing

Re: [Qemu-devel] [PATCH 0/4] megaraid_sas HBA emulation

On 10/30/09 09:12, Hannes Reinecke wrote: Gerd Hoffmann wrote: http://repo.or.cz/w/qemu/kraxel.git?a=shortlog;h=refs/heads/scsi.v1 It is far from being completed, will continue tomorrow. Should give a idea of the direction I'm heading to though. Comments welcome. Yep, this looks good

Re: [PATCH 7/7] virtio: console: Return -EPIPE if port on the host isn't connected

On 03/23/10 12:09, Amit Shah wrote: I didn't really look at blocking / non-blocking support in write() because of the cpu_relax(), which will always block the app. Right, the spinning again ... When we kill this we really must care to implement blocking + non-blocking + poll + partial writes

Re: [PATCHv3] virtio-spec: 64 bit features, used/avail event, fixes

Hi, E.g. with 32 bridges, and 32 devices behind each one, the available 64K space gets us only 64 bytes per device. 15 bridges (with io window enabled) max, the smallest io window you can assign to a bridge is 4k, and you need some space for the devices on the root bus ... cheers,

Re: [PATCHv3] virtio-spec: 64 bit features, used/avail event, fixes

Hi, Hmm, wait, we could go 32 bit, then we are not limited to 32 bridges anymore, right? Does our bios support that? How you want go to 32bit? io space (not mmio) is fixed at 16bit in x86, isn't it? cheers, Gerd ___ Virtualization mailing

Re: [Qemu-devel] Using PCI config space to indicate config location

Hi, But I think we could solve this in a different way. I think we could just move the virtio configuration space to BAR1 by using a transport feature bit. Why hard-code stuff? I think it makes alot of sense to have a capability simliar to msi-x which simply specifies bar and offset of

Re: [Qemu-devel] Using PCI config space to indicate config location

Hi, So we could have for virtio something like this: Capabilities: [??] virtio-regs: legacy: BAR=0 offset=0 virtio-pci: BAR=1 offset=1000 virtio-cfg: BAR=1 offset=1800 This would be a vendor specific PCI capability so lspci

Re: [Qemu-devel] Using PCI config space to indicate config location

Hi, Well, we also want to clean up the registers, so how about: BAR0: legacy, as is. If you access this, don't use the others. Ok. BAR1: new format virtio-pci layout. If you use this, don't use BAR0. BAR2: virtio-cfg. If you use this, don't use BAR0. Why use two bars for this? You

Re: [Qemu-devel] Using PCI config space to indicate config location

Hi, Why use two bars for this? You can put them into one mmio bar, together with the msi-x vector table and PBA. Of course a pci capability describing the location is helpful for that ;) You don't need a capability. You can also just add a config offset field to the register set and

Re: [Pv-drivers] [PATCH 0/6] VSOCK for Linux upstreaming

On 11/05/12 19:19, Andy King wrote: Hi David, The big and only question is whether anyone can actually use any of this stuff without your proprietary bits? Do you mean the VMCI calls? The VMCI driver is in the process of being upstreamed into the drivers/misc tree. Greg (cc'd on these

Re: [Pv-drivers] [PATCH 0/6] VSOCK for Linux upstreaming

On 01/09/13 03:22, Dmitry Torokhov wrote: On Tue, Jan 08, 2013 at 05:46:01PM -0800, David Miller wrote: I'd much rather see a hypervisor neutral solution than a hypervisor specific one which this certainly is. Objectively speaking neither solution is hypervisor neutral as there are

Re: [PATCH 1/1] VSOCK: Introduce VM Sockets

Hi, Likewise, I expect with the final version vmci_transport is a separate module (or moves into the vmci driver), correct? When you say final, do you mean something that we have to do before acceptance into mainline or something we can refine over time? IMHO refining in-tree is fine.

Re: [PATCH 0/1] VM Sockets for Linux upstreaming

Hi, Unlike previous submissions, where the new socket family was entirely reliant on VMware's VMCI PCI device (and thus VMware's hypervisor), VM Sockets is now *completely* separated out into two parts, each in its own module: Some separation still needs to be done: CC [M]

Re: [PATCH 1/1] VSOCK: Introduce VM Sockets

On 02/07/13 01:23, Andy King wrote: +struct vsock_transport_recv_notify_data { + u64 data1; /* Transport-defined. */ + u64 data2; /* Transport-defined. */ + bool notify_on_block; +}; + +struct vsock_transport_send_notify_data { + u64 data1; /* Transport-defined. */ +

Re: [PATCH 1/1] VSOCK: Introduce VM Sockets

On 02/07/13 01:23, Andy King wrote: Hi, +/* Option name for socket's service label. Use as the option name in + * setsockopt(3) or getsockopt(3) to set or get the service label for a socket. + * The service label is a C-style NUL-terminated string. Only available for + * hypervisor

Re: [PATCH 1/1] VSOCK: Introduce VM Sockets

On 02/12/13 16:21, Andy King wrote: Hi Gerd, +struct vsock_transport { ... Whoa. This has grown *alot*. Care to explain this please? Patch creating a Documentation/virtual/vsock.txt would be cool. Yes, it grew because of the notification stuff, which I'd forgotten about until I

Re: [PATCH 1/1] VSOCK: Introduce VM Sockets

On 02/07/13 01:23, Andy King wrote: +static int vsock_create(struct net *net, struct socket *sock, + int protocol, int kern) +{ + if (!sock) + return -EINVAL; + + if (protocol) + return -EPROTONOSUPPORT; + IMO protocol == PF_VSOCK

Re: [PATCH 1/1] VSOCK: Introduce VM Sockets

e085c81d3fc95a7e2e938deec65843ba7c00afe3 Mon Sep 17 00:00:00 2001 From: Gerd Hoffmann kra...@redhat.com Date: Wed, 13 Feb 2013 18:00:19 +0100 Subject: [PATCH 2/4] af_vsock: don't overwrite sock-state We set sock-state to SS_CONNECTING before calling the transport, no need to do that again afterwards, thereby overwriting any updates

Re: [PATCH 1/1] VSOCK: Introduce VM Sockets

On 02/07/13 01:23, Andy King wrote: +/* Use this as the destination CID in an address when referring to the + * hypervisor. VMCI relies on it being 0, but this would be useful for other + * transports too. + */ + +#define VMADDR_CID_HYPERVISOR 0 + +/* This CID is specific to VMCI and can

[PATCH 2/2] virtio-gpu/2d: add docs/specs/virtio-gpu.txt

Signed-off-by: Gerd Hoffmann kra...@redhat.com --- docs/specs/virtio-gpu.txt | 165 ++ 1 file changed, 165 insertions(+) create mode 100644 docs/specs/virtio-gpu.txt diff --git a/docs/specs/virtio-gpu.txt b/docs/specs/virtio-gpu.txt new file mode

[PATCH 1/2] virtio-gpu/2d: add hardware spec include file

This patch adds the header file with structs and defines for the virtio based gpu device. Covers 2d operations only. Signed-off-by: Gerd Hoffmann kra...@redhat.com --- include/hw/virtio/virtgpu_hw.h | 158 + 1 file changed, 158 insertions(+) create mode

[PATCH 0/2] virtio-gpu: hardware specification

to handle that best? Simply add both mine and Dave's signed-off-by to all virtio-gpu qemu patches? Is that fine with you Dave? Anyone has better ideas? please review, Gerd Hoffmann Gerd Hoffmann (2): virtio-gpu/2d: add hardware spec include file virtio-gpu/2d: add docs/specs/virtio-gpu.txt docs

Re: [Qemu-devel] [PATCH 1/2] virtio-gpu/2d: add hardware spec include file

On Do, 2014-09-11 at 16:20 +0100, Peter Maydell wrote: On 11 September 2014 16:09, Gerd Hoffmann kra...@redhat.com wrote: This patch adds the header file with structs and defines for the virtio based gpu device. Covers 2d operations only. Please don't cc subscriber only mailing lists

Re: [Qemu-devel] [PATCH 1/2] virtio-gpu/2d: add hardware spec include file

Hi, @@ -0,0 +1,158 @@ +#ifndef VIRTGPU_HW_H +#define VIRTGPU_HW_H Non-trivial file, deserves a copyright and license notice. Added. + +enum virtgpu_ctrl_type { +VIRTGPU_UNDEFINED = 0, + +/* 2d commands */ +VIRTGPU_CMD_GET_DISPLAY_INFO = 0x0100,

Re: [Qemu-devel] [PATCH 2/2] virtio-gpu/2d: add docs/specs/virtio-gpu.txt

Hi, +++ b/docs/specs/virtio-gpu.txt @@ -0,0 +1,165 @@ +virtio-gpu specification I know you are just following existing bad practice in this directory, but it would be nice to declare copyright and license on this file. Added copyright for now. Dunno about license, IIRC GPLv2 isn't

Re: [virtio-dev] [PATCH 2/2] virtio-gpu/2d: add docs/specs/virtio-gpu.txt

On Fr, 2014-09-12 at 10:10 +0100, Stefan Hajnoczi wrote: On Thu, Sep 11, 2014 at 05:09:33PM +0200, Gerd Hoffmann wrote: diff --git a/docs/specs/virtio-gpu.txt b/docs/specs/virtio-gpu.txt new file mode 100644 index 000..9455383 --- /dev/null +++ b/docs/specs/virtio-gpu.txt @@ -0,0

Re: [virtio-dev] [PATCH 2/2] virtio-gpu/2d: add docs/specs/virtio-gpu.txt

On Sa, 2014-09-13 at 07:14 +1000, Dave Airlie wrote: Can the host refuse due to lack of resources? Yes. virtgpu_ctrl_hdr.type in the response will be set to VIRTGPU_RESP_ERR_* then. Current implementation does that only on malloc() failure, there is no accounting (yet) to limit the

Re: [Qemu-devel] [PATCH 1/2] virtio-gpu/2d: add hardware spec include file

Hi, Why do you think that? We have several header files which use QEMU_BUILD_BUG_ON and I don't see any reason why it would have to be invoked from a .c file. Because Gerd wants to share this with linux uapi, and you can't use BUILD_BUG_ON in uapi headers on linux. Who owns the

Re: [PATCH 1/2] virtio-gpu/2d: add hardware spec include file

+ +enum virtgpu_ctrl_type { +VIRTGPU_UNDEFINED = 0, + +/* 2d commands */ +VIRTGPU_CMD_GET_DISPLAY_INFO = 0x0100, Please consider also adding: VIRTIO_GPU_ everywhere to make it consistent with other virtio headers? The names are already

Re: [PATCH] virtio-pci: also bind to Amazon PCI vendor ID

Hi, But this is independent of WHQL certification. My understanding is that Microsoft will only allow the owner of the PCI Vendor ID to WHQL drivers. As best as I know, this is not a publicly documented process. Do you have any examples of anyone else successfuling WHQL'ing drivers by

Re: [PATCH v4 18/42] virtio_blk: make serial attribute static

On Di, 2014-11-25 at 18:42 +0200, Michael S. Tsirkin wrote: It's never declared so no need to make it extern. Hmm, can't see patches 14 - 17 on the maling list (virtualization@lists.linux-foundation.org). Also no cover letter. Someone eating mails? cheers, Gerd

Re: [PATCH RESEND 06/14] drm/virtio: use drm_crtc_send_vblank_event()

On Mo, 2016-06-06 at 11:41 -0300, Gustavo Padovan wrote: > From: Gustavo Padovan > > Replace the legacy drm_send_vblank_event() with the new helper function. > > Signed-off-by: Gustavo Padovan > --- >

Re: [PATCH] virtio-gpu: use src not crtc

On Di, 2016-06-14 at 12:13 +0200, Marc-André Lureau wrote: > Hi > > On Tue, May 31, 2016 at 2:52 PM, Gerd Hoffmann <kra...@redhat.com> wrote: > > Pick up the correct source rectangle from framebuffer. > > Without this multihead setups are not working correctly.

Re: [PATCH v3 7/7] [wip] virtio-gpu: add page flip support

Hi, > > But I'll take you up on the implied offer to help out and test ;-) > > git://people.freedesktop.org/~danvet/drm stuff Tried that branch. > Would be really awesome if you could test this on virtio. Note that the > new nonblocking helpers require that your atomic backend gets the drm >

Re: [PATCH] Add virtio gpu driver.

Hi, > - add a small core function to registerr HOT_X/HOT_Y for a (cursor) plane, > e.g. drm_plane_register_hotspot(). That should allocate the properties > (if they don't exist yet) and then attach those props to the cursor. We > don't want those props everywhere, but only on drivers that

Re: [PATCH v3 7/7] [wip] virtio-gpu: add page flip support

Hi, > > Right now the virtual outputs are linked to drm_crtc. To apply any > > changes I need to lookup the crtc to figure which virtual output should > > be updated. > > So, setting active_only should make sure I have a valid crtc pointer on > > plane updates, right? It probably also skips

Re: [PATCH v3 7/7] [wip] virtio-gpu: add page flip support

Hi, > > https://lists.freedesktop.org/archives/dri-devel/2016-May/108772.html > > Hm, smells more like virtio isn't too happy with the default ordering of > the commit operation. The default is: > > - Disable any crtc/encoders that need to be disabled/change. > - Bash new plane setup into hw.

Re: [PATCH] Add virtio gpu driver.

Hi, > > Why attach the hotspot to the plane? Wouldn't it make more sense to > > make it a framebuffer property? > > We don't have properties on the framebuffer. I guess you /could/ just add > it internally to struct drm_framebuffer, and not bother exposing to > userspace. I guess that would

Re: [PATCH v3 7/7] [wip] virtio-gpu: add page flip support

On Mi, 2016-05-25 at 18:37 +0200, Daniel Vetter wrote: > On Fri, Oct 2, 2015 at 1:58 PM, Gerd Hoffmann <kra...@redhat.com> wrote: > > Signed-off-by: Gerd Hoffmann <kra...@redhat.com> > > So I entirely missed this, but this isn't really how to implement > page_flip

Re: [PATCH] Add virtio gpu driver.

ne for the most part, see attached draft. The only thing I'm wondering is how the hotspot is handled. drm_mode_cursor_universal doesn't even look at req->hot_{x,y}. /me looks confused. cheers, Gerd From fb1d0700a46d850ec9f931304a9e99854a3ce5e9 Mon Sep 17 00:00:00 2001 From: Gerd Hoffmann

[PATCH] virtio-gpu: use src not crtc

Pick up the correct source rectangle from framebuffer. Without this multihead setups are not working correctly. Signed-off-by: Gerd Hoffmann <kra...@redhat.com> --- drivers/gpu/drm/virtio/virtgpu_plane.c | 31 ++- 1 file changed, 18 insertions(+), 13 del

[PATCH 1/5] virtio-gpu: fix output lookup

Needed for multihead setups where we can have disabled outputs and therefore plane->crtc can be NULL. Signed-off-by: Gerd Hoffmann <kra...@redhat.com> --- drivers/gpu/drm/virtio/virtgpu_plane.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/d

[PATCH 3/5] virtio-gpu: switch to atomic cursor interfaces

Signed-off-by: Gerd Hoffmann <kra...@redhat.com> --- drivers/gpu/drm/virtio/virtgpu_display.c | 102 -- drivers/gpu/drm/virtio/virtgpu_drv.h | 1 + drivers/gpu/drm/virtio/virtgpu_plane.c | 105 --- 3 files changed, 109 inse

[PATCH 2/5] virtio-gpu: add atomic_commit function

Do modesets first, then call drm_atomic_helper_commit_planes with active_only = true. That way the outputs doesn't get disabled temporarly on atomic commits. Signed-off-by: Gerd Hoffmann <kra...@redhat.com> --- drivers/gpu/drm/virtio/virtgpu_display.c | 22 +- drive

[PATCH 5/5] virtio-gpu: pick up hotspot from framebuffer

Signed-off-by: Gerd Hoffmann <kra...@redhat.com> --- drivers/gpu/drm/virtio/virtgpu_plane.c | 20 +--- 1 file changed, 13 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/virtio/virtgpu_plane.c b/drivers/gpu/drm/virtio/virtgpu_plane.c index 4780354..b7778a7

Re: [RFC 1/5] drm/virtio: add virtio_gpu_alloc_fence()

Hi, > +struct virtio_gpu_fence *virtio_gpu_fence_alloc(struct virtio_gpu_device > *vgdev) > +{ > + struct virtio_gpu_fence_driver *drv = >fence_drv; > + struct virtio_gpu_fence *fence; > + unsigned long irq_flags; > + > + fence = kmalloc(sizeof(struct virtio_gpu_fence),

Re: [RFC v1 0/3] Add VIRTIO_F_IOMMU_PLATFORM support

Hi, > > I see that OVMF has the following virtio drivers, we need to update > > them > > all: > > > > VirtioBlkDxe > > VirtioGpuDxe > > VirtioNetDxe > > VirtioRngDxe > > VirtioScsiDxe > > > > I will wait for Laszlo and Jordan's initial feedback before > > changing > > other drivers. > > I'm

Re: [PATCH] drm: ttm: virtio-gpu: dma-buf: Constify ttm_place structures.

On Sun, 2017-07-02 at 13:11 +0530, Arvind Yadav wrote: > ttm_place are not supposed to change at runtime. All functions > working with ttm_place provided by work > with const ttm_place. So mark the non-const structs as const. > > File size before: >    text    data bss dec hex

Re: [PATCH 02/37] drm: Remove drm_device->virtdev

er also doesn't really need it, dev_to_virtio works > perfectly fine. Reviewed-by: Gerd Hoffmann <kra...@redhat.com> ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH] drm: qxl: ratelimit pr_info message, reduce log spamming

On Tue, 2017-09-12 at 17:09 +0300, Dan Carpenter wrote: > On Tue, Sep 12, 2017 at 03:02:04PM +0100, Emil Velikov wrote: > > That said, I'm not sure how useful the information is - perhaps > > it's > > better to drop it all together? > > Or a WARN_ONCE(). It's userspace calling into the driver

Re: [PATCH] drm/virtio: add create_handle support.

On Mon, Nov 13, 2017 at 02:19:29PM -0800, lepton wrote: > Ping. > > On Wed, Nov 8, 2017 at 10:42 AM, Lepton Wu wrote: > > Add create_handle support to virtio fb. Without this, screenshot tool > > in chromium OS can't work. Already queued up in drm-misc-next (the cirrus patch

Re: [PATCH v3 1/2] drm/virtio: Add window server support

Hi, Sorry for joining the party late. Had a broken finger and was offline for a bunch of weeks (and a buif backlog afterwards ...). > This is to allow clients running within VMs to be able to communicate > with a compositor in the host. Clients will use the communication > protocol that the

Re: [PATCH v3 1/2] drm/virtio: Add window server support

Hi, > > Why not use virtio-vsock to run the wayland protocol? I don't like > > the idea to duplicate something with very simliar functionality in > > virtio-gpu. > > The reason for abandoning that approach was the type of objects that > could be shared via virtio-vsock would be extremely

Re: [PATCH v3 1/2] drm/virtio: Add window server support

On Mon, Feb 05, 2018 at 03:46:17PM +0100, Tomeu Vizoso wrote: > On 02/05/2018 01:20 PM, Gerd Hoffmann wrote: > >Hi, > > > > > > Why not use virtio-vsock to run the wayland protocol? I don't like > > > > the idea to duplicate something with very siml

Re: [PATCH v3 1/2] drm/virtio: Add window server support

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

  1   2   3   4   5   6   7   8   9   10   >