25.01.2021 14:12, Arseny Krasnov пишет:
This adds receive loop for SEQPACKET. It looks like receive loop for
SEQPACKET,
^^^
You meant "STREAM"?
19.01.2021 20:40, Andy Lutomirski пишет:
The implementation was rather buggy. It unconditionally marked PTEs
read-only, even for VM_SHARED mappings. I'm not sure whether this is
actually a problem, but it certainly seems unwise. More importantly, it
released the mmap lock before flushing the T
15.01.2021 08:35, Arseny Krasnov пишет:
This patchset impelements support of SOCK_SEQPACKET for virtio
transport.
As SOCK_SEQPACKET guarantees to save record boundaries, so to
do it, new packet operation was added: it marks start of record (with
record length in header), such pack
03.01.2021 23:04, Arseny Krasnov пишет:
From: Arseniy Krasnov
---
net/vmw_vsock/af_vsock.c | 107 +--
1 file changed, 91 insertions(+), 16 deletions(-)
diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c
index 7ff00449a9a2..30caad9815f7 10064
Hi Arseny, thanks for your work on this!
I did a small review in a hope it helps.
Also it may be cool to have the driver feature
for that (so that the host can see if its supported).
But I guess this was already said by Michael. :)
03.01.2021 22:54, Arseny Krasnov пишет:
As SOCK_SEQPACK
03.01.2021 22:57, Arseny Krasnov пишет:
This extends rx loop for SOCK_SEQPACKET packets and implements
callback which user calls to copy data to its buffer.
Signed-off-by: Arseny Krasnov
---
include/linux/virtio_vsock.h| 7 +
include/net/af_vsock.h |
Hi Arseny!
03.01.2021 23:03, Arseny Krasnov пишет:
From: Arseniy Krasnov
For send, this patch adds:
1) Send of record begin marker with record length.
2) Return error if send of whole record is failed.
For receive, this patch adds another loop, it looks like
stream loop, but:
07.12.2020 17:34, Paolo Bonzini пишет:
> It is too late to change that aspect of the API, unfortunately. We
> don't know how various userspaces would behave.
Which means some sensible behaviour
already exists if I don't call KVM_SET_CPUID2.
So what is it, #UD on CPUID?
I wo
07.12.2020 17:09, Paolo Bonzini пишет:
Il lun 7 dic 2020, 15:04 stsp <mailto:st...@yandex.ru>> ha scritto:
Perhaps it would be good if guest cpuid to
have a default values of KVM_GET_SUPPORTED_CPUID,
so that the user doesn't have to do the needless
calls to
07.12.2020 16:35, Paolo Bonzini пишет:
Il lun 7 dic 2020, 12:47 stsp <mailto:st...@yandex.ru>> ha scritto:
So am I right that KVM_SET_CPUID only "lowers"
the supported bits? In which case I don't need to
call it at all, but instead just call KVM_GET_SUPPOR
07.12.2020 14:29, Paolo Bonzini пишет:
On 07/12/20 12:24, stsp wrote:
It tries to enable VME among other things.
qemu appears to disable VME by default,
unless you do "-cpu host". So we have a situation where
the host (which is qemu) doesn't have VME,
and guest (dosemu) is tryi
[re-send because of bad formatting]
09.10.2020 18:30, Sean Christopherson пишет:
The only other effect of setting VMXE was clearing VME. Which shouldn't
affect anything either, right?
Hmm, clearing VME would mean that exceptions/interrupts within the
guest would
trigger a switch out of v86 and
09.10.2020 18:30, Sean Christopherson пишет:
The only other effect of setting VMXE was clearing VME. Which shouldn't
affect anything either, right?
Hmm, clearing VME would mean that exceptions/interrupts within the guest would
trigger a switch out of v86 and into vanilla protected mode. v86 and
09.10.2020 18:30, Sean Christopherson пишет:
On Fri, Oct 09, 2020 at 05:11:51PM +0300, stsp wrote:
09.10.2020 07:04, Sean Christopherson пишет:
Hmm. But at least it was lying
similarly on AMD and Intel CPUs. :)
So I was able to reproduce the problems
myself.
Do you mean, any AMD tests are now
09.10.2020 16:31, Thomas Zimmermann пишет:
I can't say for sure. IIRC SDL2 can use DRM directly.
Yes, that was a great hint indeed,
thanks. It didn't work for me in the past
(a year ago or so), so I added SDL1
support. But now I re-tried, and it indeed
works!
And, as far as I can tell, the hangi
09.10.2020 07:04, Sean Christopherson пишет:
Hmm. But at least it was lying
similarly on AMD and Intel CPUs. :)
So I was able to reproduce the problems
myself.
Do you mean, any AMD tests are now useless, and we need to proceed with Intel
tests only?
For anything VMXE related, yes.
What would b
09.10.2020 15:58, Thomas Zimmermann пишет:
Hi
Am 09.10.20 um 14:16 schrieb stsp:
09.10.2020 14:59, Thomas Zimmermann пишет:
Fbdev exposes the video ram (or a shadow buffer of it) to all
applications. Only one can draw at the same time. It's a limitation of
the design. To fix this,
09.10.2020 14:59, Thomas Zimmermann пишет:
Fbdev exposes the video ram (or a shadow buffer of it) to all
applications. Only one can draw at the same time. It's a limitation of
the design. To fix this, your application has to stop drawing when you
switch consoles.
OK, thanks for info.
Quite a sad
Hi!
I am trying to run my sdl1-based app
under linux kms framebuffer (amdgpudrmfb
in my case).
The app itself works perfectly, but
console switching is not.
If I switch the console while the app
is drawing, then it will corrupt the
VC I switched to. It will just draw on
top of the VC's content.
08.10.2020 20:59, Sean Christopherson пишет:
On Thu, Oct 08, 2020 at 07:00:13PM +0300, stsp wrote:
07.10.2020 04:44, Sean Christopherson пишет:
Two bug fixes to handle KVM_SET_SREGS without a preceding KVM_SET_CPUID2.
Hi Sean & KVM devs.
I tested the patches, and wherever I
set VMXE in
07.10.2020 04:44, Sean Christopherson пишет:
Two bug fixes to handle KVM_SET_SREGS without a preceding KVM_SET_CPUID2.
Hi Sean & KVM devs.
I tested the patches, and wherever I
set VMXE in CR4, I now get
KVM: KVM_SET_SREGS: Invalid argument
Before the patch I was able (with many
problems, but st
21 matches
Mail list logo
