On Mon, May 18, 2020 at 04:28:51PM +0100, Andrew Scull wrote:
> On Fri, May 15, 2020 at 11:58:34AM +0100, David Brazdil wrote:
> > +__kvm_nvhe_sve_load_state = sve_load_state;
> > +__kvm_nvhe_sve_save_state = sve_save_state;
>
> Building without CONFIG_ARM64_VHE leads to a linker error due to the
On Mon, May 18, 2020 at 04:55:53PM +0100, Andrew Scull wrote:
> On Fri, May 15, 2020 at 11:58:31AM +0100, David Brazdil wrote:
> > diff --git a/arch/arm64/kernel/image-vars.h b/arch/arm64/kernel/image-vars.h
> > index 7f06ad93fc95..13850134fc28 100644
> > --- a/arch/arm64/kernel/image-vars.h
> >
On Fri, May 15, 2020 at 11:58:31AM +0100, David Brazdil wrote:
> diff --git a/arch/arm64/kernel/image-vars.h b/arch/arm64/kernel/image-vars.h
> index 7f06ad93fc95..13850134fc28 100644
> --- a/arch/arm64/kernel/image-vars.h
> +++ b/arch/arm64/kernel/image-vars.h
> @@ -51,4 +51,16 @@
On Fri, May 15, 2020 at 11:58:34AM +0100, David Brazdil wrote:
> +__kvm_nvhe_sve_load_state = sve_load_state;
> +__kvm_nvhe_sve_save_state = sve_save_state;
Building without CONFIG_ARM64_VHE leads to a linker error due to the SVE
functions being referenced in this list. This is caused by
On Mon, 18 May 2020 18:09:34 +0100,
Will Deacon wrote:
>
> On Mon, May 18, 2020 at 05:59:59PM +0100, Will Deacon wrote:
> > On Wed, May 13, 2020 at 02:33:34PM +0530, Anshuman Khandual wrote:
> > > Currently there are multiple instances of parange feature width mask open
> > > encodings while
On Mon, May 18, 2020 at 05:59:59PM +0100, Will Deacon wrote:
> On Wed, May 13, 2020 at 02:33:34PM +0530, Anshuman Khandual wrote:
> > Currently there are multiple instances of parange feature width mask open
> > encodings while fetching it's value. Even the width mask value (0x7) itself
> > is not
On Wed, May 13, 2020 at 02:33:34PM +0530, Anshuman Khandual wrote:
> Currently there are multiple instances of parange feature width mask open
> encodings while fetching it's value. Even the width mask value (0x7) itself
> is not accurate. It should be (0xf) per ID_AA64MMFR0_EL1.PARange[3:0] as in
On Mon, 2020-05-18 at 13:51 +0200, Paolo Bonzini wrote:
> On 18/05/20 13:34, Maxim Levitsky wrote:
> > > In high-performance configurations, most of the time virtio devices are
> > > processed in another thread that polls on the virtio rings. In this
> > > setup, the rings are configured to not
On 18/05/20 13:34, Maxim Levitsky wrote:
>> In high-performance configurations, most of the time virtio devices are
>> processed in another thread that polls on the virtio rings. In this
>> setup, the rings are configured to not cause a vmexit at all; this has
>> much smaller latency than even a
On Mon, 2020-05-18 at 13:18 +0200, Paolo Bonzini wrote:
> On 18/05/20 10:45, Anastassios Nanos wrote:
> > Being in the kernel saves us from doing unneccessary mode switches.
> > Of course there are optimizations for handling I/O on QEMU/KVM VMs
> > (virtio/vhost), but essentially what happens is
On 18/05/20 10:45, Anastassios Nanos wrote:
> Being in the kernel saves us from doing unneccessary mode switches.
> Of course there are optimizations for handling I/O on QEMU/KVM VMs
> (virtio/vhost), but essentially what happens is removing mode-switches (and
> exits) for I/O operations -- is
On Fri, 24 Apr 2020 at 13:53, Davidlohr Bueso wrote:
>
> The use of any sort of waitqueue (simple or regular) for
> wait/waking vcpus has always been an overkill and semantically
> wrong. Because this is per-vcpu (which is blocked) there is
> only ever a single waiting vcpu, thus no need for any
Anastassios Nanos writes:
> Moreover, it doesn't involve *any* mode switch at all while printing
> out the result of the addition of these two registers -- which I
> guess for a simple use-case like this it isn't much.
> But if we were to scale this to a large number of exits (and their
>
to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Anastassios-Nanos/Expose-KVM-API-to-Linux-Kernel/20200518-150402
base:b9bbe6ed63b2b9f2c9ee5cbd0f2c946a2723f4ce
config: powerpc
Anastassios Nanos writes:
> On Mon, May 18, 2020 at 11:43 AM Thomas Gleixner wrote:
>>
>> And this shows clearly how simple the user space is which is required to
>> do that. So why on earth would we want to have all of that in the
>> kernel?
>>
> well, the main idea is that all this
to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Anastassios-Nanos/Expose-KVM-API-to-Linux-Kernel/20200518-150402
base:b9bbe6ed63b2b9f2c9ee5cbd0f2c946a2723f4ce
config: x86_64
to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Anastassios-Nanos/Expose-KVM-API-to-Linux-Kernel/20200518-150402
base:b9bbe6ed63b2b9f2c9ee5cbd0f2c946a2723f4ce
config: i386
Anastassios Nanos writes:
> To spawn KVM-enabled Virtual Machines on Linux systems, one has to use
> QEMU, or some other kind of VM monitor in user-space to host the vCPU
> threads, I/O threads and various other book-keeping/management mechanisms.
> This is perfectly fine for a large number of
On 2020-05-18 07:58, Anastassios Nanos wrote:
To spawn KVM-enabled Virtual Machines on Linux systems, one has to use
QEMU, or some other kind of VM monitor in user-space to host the vCPU
threads, I/O threads and various other book-keeping/management
mechanisms.
This is perfectly fine for a
On 2020-05-18 07:58, Anastassios Nanos wrote:
Expose a set of KVM functions to the kernel, in order to be
able to spawn a VM instance without assistance from user-space.
To handle a guest instance, the system needs access to the following
functions:
kvm_arch_vcpu_run_map_fp
Expose a set of KVM functions to the kernel, in order to be
able to spawn a VM instance without assistance from user-space.
To handle a guest instance, the system needs access to the following
functions:
kvm_arch_vcpu_run_map_fp
kvm_arch_vcpu_ioctl_get_regs
To run KVMM guests, we need to extend the KVM memory subsystem
to support kernel-allocated memory. To do this, we allow "vmalloced"
space to be used as KVM guest addresses.
Additionally, since current->mm is NULL when being in the Kernel, in
the context of kthreads, we check whether mm refers to
To spawn KVM-enabled Virtual Machines on Linux systems, one has to use
QEMU, or some other kind of VM monitor in user-space to host the vCPU
threads, I/O threads and various other book-keeping/management mechanisms.
This is perfectly fine for a large number of reasons and use cases: for
instance,
On Sun, May 17, 2020 at 06:09:00PM +0800, Jingyi Wang wrote:
> Triggers PPIs by setting up a 10msec timer and test the latency.
> For this test can be time consuming, we add time limit for loop_test
> to make sure each test should be done in a certain time(5 sec here).
Having a time limit for the
24 matches
Mail list logo
