Signed-off-by: Gerd Hoffmann <[EMAIL PROTECTED]>
---
arch/x86/kvm/x86.c | 63 +++
1 files changed, 53 insertions(+), 10 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 979f983..6906d54 100644
--- a/arch/x86/kvm
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
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 gu
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/ti
This patch switches the kvm clocksource code over to use the
paravirt clock helpers, thereby making it compatible with xen.
Signed-off-by: Gerd Hoffmann <[EMAIL PROTECTED]>
---
arch/x86/Kconfig |1 +
arch/x86/kernel/kvmclock.c | 84
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_
Signed-off-by: Gerd Hoffmann <[EMAIL PROTECTED]>
---
arch/x86/kvm/x86.c | 71 ---
include/asm-x86/kvm_host.h |1 +
2 files changed, 60 insertions(+), 12 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index dab3d4f..7
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..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
https://lists.lin
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..b
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 del
Jeremy Fitzhardinge wrote:
>> +static unsigned pvclock_get_time_values(struct pvclock_shadow_time *dst,
>> +struct kvm_vcpu_time_info *src)
>>
>
> I think the kvm_* types should be renamed. xen_* would make some sense
> since the ABI originated with Xen, but something gene
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
Virtualization@lists.linux-foun
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/a
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
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/K
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(-)
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
Virtualization@lists.
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
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
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
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
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(-)
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
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 pat
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/a
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/K
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
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 th
On 08/10/09 08:55, Amit Shah wrote:
>> Bad example. Quite a lot of modern devices drivers are using dynamic
>> major/minor numbers because they have proven to be such a pain in the
>> butt. That's why we have more sophisticated mechanisms like udev for
>> userspace to make use of.
>
> Let me expl
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 b
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
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
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
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
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 fo
Jeremy Fitzhardinge wrote:
Eric W. Biederman wrote:
I have several ideas on how we can make this work but first I have to
ask what is it that you are trying to accomplish?
The requirements are:
1. the domain builder needs to get various information about the
guest kernel by inspectin
ation.
Checking video mode field only to see whenever SCREEN_INFO is
initialized is not enougth, in some cases it is zero although
a vga card is present. Lets additionally check cols and lines.
Signed-off-by: Gerd Hoffmann <[EMAIL PROTECTED]>
Cc: Rusty Russell <[EMAIL PROTECTED]>
Cc: A
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 c
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
__
Avi Kivity wrote:
>> You are
>> probably better off designing something that is PV specific instead of
>> shoehorning it in to fit a different model (at least for the things I
>> have in mind).
>
> Well, if we design our pv devices to look like hardware, they will fit
> quite well. Both to the
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 s/ptep_get_and_cle
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 P
Derek Murray wrote:
> If we let Linux zap the page tables before we unmap the grant reference,
> then it is not possible to unmap the grant reference. The
> unmap_grant_ref hypercall ultimately calls destroy_grant_pte_mapping in
> xen/arch/x86/mm.c, which ensures that the PTE does in fact point to
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
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
Stephen C. Tweedie wrote:
> I can't help wondering if this is a hint that now is the time to find a
> better API, which doesn't have the requirement (a) that seems to be
> causing such trouble? Are other PV guests --- *BSD, Solaris --- going
> to have the same problems with their VM layers if they
>> 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
Hi,
> Thanks for the repro details. I'll have a go at this later. One thing we
> haven't tested AFAIK is mapping grants in the same domain: could you
> check to see if the bug is the same if you attach a block device to a
> domain other than Dom0? Also, could you send any Xen console output, if
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
>
Geoffrey Lefebvre wrote:
> In order to unmap a grant, you need the grant handle obtained when the
> grant is mapped. That handle needs to be stored somewhere for the
> lifetime of the mapping. Where would the handle be stored (as Gerd
> proposed) in order to be able to unmap from ptep_get_and_clear
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,
>
> Which version of the Xen tools are you using? There was a bug in the
> version released with Xen 3.1, which should have been cleaned up in the
> subsequent minor versions. Try grabbing the patch to libxc at:
>
> http://xenbits.xensource.com/xen-3.1-testing.hg?raw-rev/135d5088909f
Probably it i
D.G. Murray wrote:
> Hi Mark,
> void *xc_gnttab_map_grant_refs(int xcg_handle,
>uint32_t count,
>uint32_t *domids,
>uint32_t *refs,
>int prot);
Fedora 8 has 3.1.2 packa
Hi,
> > There is also a direct and hard coded use in cirrus.c which according to
> > the comment is only necessary during resume. Let's just skip this as
> > for example s390 which doesn't have I/O port support also doesen't
> > support suspend/resume.
>
> I think we should consider making cir
help with a later removal. No functional changes.
>
> Signed-off-by: Thomas Zimmermann
Acked-by: Gerd Hoffmann
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
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
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
> h
Hi,
> diff --git a/net/vmw_vsock/Kconfig b/net/vmw_vsock/Kconfig
> new file mode 100644
> index 000..95e2568
> --- /dev/null
> +++ b/net/vmw_vsock/Kconfig
> @@ -0,0 +1,14 @@
> +#
> +# Vsock protocol
> +#
> +
> +config VMWARE_VSOCK
> + tristate "Virtual Socket protocol"
> + depends on
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 fi
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] net/vmw_vso
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. */
>
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
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 u
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_VSO
that? Peer closing the socket while sleeping? Other
>> thread closing the socket wile sleeping? Both?
>>
>> I think a state field in struct vsock_sock would be a better solution here.
>
> Hrm, lemme think about this one.
There is already vsock->sk.sk_state ...
cheers,
Gerd
On 02/07/13 01:23, Andy King wrote:
> + written = transport->stream_enqueue(
> + vsk, msg->msg_iov,
> + len - total_written);
Hmm, shouldn't we pass total_written to stream_enqueue here?
In case a blocking send(big-buffer) call g
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 a
On 02/18/13 18:07, Andy King wrote:
> Hi Gerd,
>
>>> + written = transport->stream_enqueue(
>>> + vsk, msg->msg_iov,
>>> + len - total_written);
>>
>> Hmm, shouldn't we pass total_written to stream_enqueue here?
>>
>> In case a blocking
On Sat, Oct 09, 2021 at 05:09:20PM +0800, Jing Xiangfeng wrote:
> virtio_gpu_user_framebuffer_create() misses to call drm_gem_object_put()
> in an error path. Add the missed function call to fix it.
Pushed to drm-misc-next.
thanks,
Gerd
___
Virtualiz
On Thu, Oct 21, 2021 at 09:44:45AM +0200, Maksym Wezdecki wrote:
> From: mwezdeck
>
> The idea behind the commit:
> 1. when resource is created, let user space decide
> if resource should be pinned or not
> 2. transfer_*_host needs pinned memory. If it is not
> pinned, then pin it.
On Thu, Oct 21, 2021 at 11:55:47AM +0200, Maksym Wezdecki wrote:
> I get your point. However, we need to make resource_create ioctl,
> in order to create corresponding resource on the host.
That used to be the case but isn't true any more with the new
blob resources. virglrenderer allows to creat
pu section of the
MAINTAINERS file, so scripts/get_maintainer.pl will Cc you on patches
submitted.
thanks,
Gerd
>
> Maksym
>
>
> On 10/22/21 10:44 AM, Maksym Wezdecki wrote:
>
> > Once again with all lists and receivers. I'm sorry for that.
> >
> > On 1
On Tue, Nov 02, 2021 at 12:31:39PM +0100, Maksym Wezdecki wrote:
> From: mwezdeck
>
> The idea behind the commit:
> 1. not pin the pages during resource_create ioctl
> 2. pin the pages on the first use during:
> - transfer_*_host ioctl
> - map ioctl
i.e. basically lazy pinning.
On Tue, Nov 02, 2021 at 08:58:55AM -0700, Chia-I Wu wrote:
> On Tue, Nov 2, 2021 at 6:07 AM Gerd Hoffmann wrote:
> >
> > On Tue, Nov 02, 2021 at 12:31:39PM +0100, Maksym Wezdecki wrote:
> > > From: mwezdeck
> > >
> > > The idea behind the c
On Tue, Nov 23, 2021 at 03:49:28PM +0800, Jason Wang wrote:
> On Tue, Nov 23, 2021 at 3:00 PM 苟浩 wrote:
> >
> > Hello,
> >
> > I use `xrandr -o left` to rotate the screen in the kvm virtual machine.
> > When configured as a Virtio graphics card, the screen will freeze after
> > rotating the scree
On Thu, Nov 25, 2021 at 08:43:55AM +, Wang, Wei W wrote:
> On Thursday, November 25, 2021 2:38 PM, Jason Wang wrote:
> > > We thought about virtio-mmio. There are some barriers:
> > > 1) It wasn't originally intended for x86 machines. The only machine
> > > type in QEMU that supports it (to run
On Wed, Dec 22, 2021 at 09:28:24AM +0100, Javier Martinez Canillas wrote:
> -static int __init bochs_init(void)
> -{
> - if (drm_firmware_drivers_only() && bochs_modeset == -1)
> - return -EINVAL;
Also cleanup bochs_modeset? I guess its not used any more after this
patch ...
take
On Mon, Dec 27, 2021 at 05:43:11PM +0100, Niklas Schnelle wrote:
> In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
> not being declared. We thus need to add HAS_IOPORT as dependency for
> those drivers using them. There is also a direct and hard coded use in
> cirrus.c which
On Mon, Dec 13, 2021 at 07:31:22PM +0100, Roberto Sassu wrote:
> If virtio_gpu_object_shmem_init() fails (e.g. due to fault injection, as it
> happened in the bug report by syzbot), virtio_gpu_array_put_free() could be
> called with objs equal to NULL.
>
> Ensure that objs is not NULL in virtio_gp
On Wed, Mar 23, 2022 at 09:45:13AM +, Robin Murphy wrote:
> On 2022-03-23 07:15, Christian König wrote:
> > Am 22.03.22 um 10:34 schrieb Cong Liu:
> > > qxl use ioremap to map ram_header and rom, in the arm64 implementation,
> > > the device is mapped as DEVICE_nGnRE, it can not support unalign
On Thu, Mar 24, 2022 at 10:20:40AM +0100, Christian König wrote:
> Hi Cong,
>
> when I understand Robin correctly all mapping (host, guest, kernel,
> userspace etc..) must have the same caching attributes unless you use the
> S2FWB feature introduced with Armv8.4.
>
> If you don't follow those ru
On Thu, Mar 24, 2022 at 06:34:02PM +0800, liuco...@kylinos.cn wrote:
>ok, thanks, a lot of our customer use qxl on x86 before, so it still need
>to supoort qxl on arm64.
Well, qxl isn't the best choice even on x86. The main advantage it
offers (2d acceleration) is basically useless today
On Tue, Oct 13, 2020 at 04:27:14PM +0300, Andy Shevchenko wrote:
> There is import_uuid() function which imports u8 array to the uuid_t.
> Use it instead of open coding variant.
>
> This allows to hide the uuid_t internals.
>
> Reviewed-by: David Stevens
> Signed-off-by: Andy Shevchenko
Pushed
On Thu, Oct 29, 2020 at 11:14:28AM +0100, Daniel Vetter wrote:
> These are leftovers from 13aff184ed9f ("drm/qxl: remove dead qxl fbdev
> emulation code").
Acked-by: Gerd Hoffmann
___
Virtualization mailing list
Virtualiza
Hi,
> - *ents = kmalloc_array(*nents, sizeof(struct virtio_gpu_mem_entry),
> - GFP_KERNEL);
> + *ents = kvmalloc_array(*nents,
> +sizeof(struct virtio_gpu_mem_entry),
> +GFP_KERNEL);
Shouldn't that be bala
On Thu, Nov 05, 2020 at 04:00:54PM +0900, Sergey Senozhatsky wrote:
> Hi,
>
> On (20/11/05 07:52), Gerd Hoffmann wrote:
> > > - *ents = kmalloc_array(*nents, sizeof(struct virtio_gpu_mem_entry),
> > > - GFP_KERNEL);
> >
On Fri, Nov 06, 2020 at 12:20:16AM +0530, Deepak R Varma wrote:
> idr_init() uses base 0 which is an invalid identifier for this driver.
> The idr_alloc for this driver uses 1 as start value for ID range. The
> new function idr_init_base allows IDR to set the ID lookup from base 1.
> This avoids al
On Fri, Oct 30, 2020 at 02:48:08PM +0300, Dan Carpenter wrote:
> This is freed both here and in the caller (virtio_gpu_vram_map()) so
> it's a double free. The correct place is only in the caller.
>
> Fixes: 16845c5d5409 ("drm/virtio: implement blob resources: implement vram
> object")
> Signed-
On Sat, Nov 14, 2020 at 03:16:13PM +0800, Zou Wei wrote:
> Fix the following sparse warning:
>
> ./virtgpu_prime.c:46:33: warning: symbol 'virtgpu_dmabuf_ops' was not
> declared. Should it be static?
Pushed to drm-misc-next.
thanks,
Gerd
___
Virtua
On Tue, Dec 01, 2020 at 11:35:26AM +0100, Thomas Zimmermann wrote:
> Using struct drm_device.pdev is deprecated. Convert bochs to struct
> drm_device.dev. No functional changes.
>
> Signed-off-by: Thomas Zimmermann
> Acked-by: Sam Ravnborg
> Cc: Gerd Hoffmann
Acked
On Tue, Dec 01, 2020 at 11:35:27AM +0100, Thomas Zimmermann wrote:
> Using struct drm_device.pdev is deprecated. Convert cirrus to struct
> drm_device.dev. No functional changes.
>
> Signed-off-by: Thomas Zimmermann
> Acked-by: Sam Ravnborg
> Cc: Gerd Hoffmann
Acked
On Tue, Dec 01, 2020 at 11:35:36AM +0100, Thomas Zimmermann wrote:
> Using struct drm_device.pdev is deprecated. Convert qxl to struct
> drm_device.dev. No functional changes.
>
> Signed-off-by: Thomas Zimmermann
> Acked-by: Sam Ravnborg
> Cc: Gerd Hoffmann
Acked
On Tue, Dec 01, 2020 at 11:35:40AM +0100, Thomas Zimmermann wrote:
> Using struct drm_device.pdev is deprecated. Convert virtgpu to struct
> drm_device.dev. No functional changes.
>
> Signed-off-by: Thomas Zimmermann
> Acked-by: Sam Ravnborg
> Cc: Gerd Hoffmann
Acked
On Fri, Dec 04, 2020 at 02:12:21PM +0100, Enrico Weigelt, metux IT consult
wrote:
> VIRTIO itself has no dependencies and therefore can easily be just
> select'ed, instead of depending on it. The current depends on causes
> any others trying to select VIRTIO to fail like this:
>
>drivers/gpu/
In case we have a shadow surface on shutdown release
it so it doesn't leak.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_display.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/qxl/qxl_display.c
b/drivers/gpu/drm/qxl/qxl_display.c
index 38d6b59
Signed-off-by: Gerd Hoffmann
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/qxl/qxl_display.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_display.c
b/drivers/gpu/drm/qxl/qxl_display.c
index 012bce0cdb65..38d6b596094d 100644
--- a/drivers/gpu
Balances the qxl_create_bo(..., pinned=true, ...);
call in qxl_release_bo_alloc().
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_release.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/qxl/qxl_release.c
b/drivers/gpu/drm/qxl/qxl_release.c
index 0fcfc952d5e9
qxl_primary_atomic_disable must check whenever the framebuffer bo has a
shadow surface and in case it has check the shadow primary status.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_display.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/qxl/qxl_display.c
Hi,
> > > > > + select TRACE_GPU_MEM
> > > > > +#ifdef CONFIG_TRACE_GPU_MEM
That doesn't make sense btw.
> > > > > +#ifdef CONFIG_TRACE_GPU_MEM
> > > > > +static inline void virtio_gpu_trace_total_mem(struct
> > > > > virtio_gpu_device *vgdev,
> > > > > +
1 - 100 of 1170 matches
Mail list logo
