Am 26.06.2018 um 19:41 hat Markus Armbruster geschrieben:
> block_crypto_open_opts_init() and block_crypto_create_opts_init()
> contain a virtual visit of QCryptoBlockOptions and
> QCryptoBlockCreateOptions less member "format", respectively.
>
> Change their callers to put member "format" in the
On 29.06.2018 03:19, David Gibson wrote:
> On Thu, Jun 28, 2018 at 02:14:17PM +0200, David Hildenbrand wrote:
>> We can assign and verify the slot before realizing and trying to plug.
>> reading/writing the address property should never fail, so let's reduce
>> error handling a bit by using &error_
On Thu, Jun 28, 2018 at 09:04:19AM +0200, Markus Armbruster wrote:
> Eric Blake writes:
>
> > On 06/27/2018 07:07 AM, Peter Xu wrote:
> >
> Worse than that - broadcasting to all monitors is categorically broken.
> Different monitors make use the same "id" formatting scheme, so if you
>
This patch breaks record/replay.
I run execution recording of the WindowsXP machine with the following script:
./bin/qemu-system-i386 -d in_asm,exec -D xp_save.log -global
apic-common.vapic=off \
-icount shift=7,rr=record,rrfile=xp0.replay \
-drive file=./images/xp_sp2.qcow2,if=none,id=img-d
Am 28.06.2018 um 17:39 hat Kevin Wolf geschrieben:
> Kevin Wolf (3):
> qemu-iotests: Update 026.out.nocache reference output
> qcow2: Free allocated clusters on write error
> qemu-iotests: Test qcow2 not leaking clusters on write error
Thanks for the review, applied to the block branch.
Kev
Hi Michael,
On 06/20/2018 08:38 PM, Michael S. Tsirkin wrote:
On Mon, Jun 04, 2018 at 05:55:17PM +0800, guangrong.x...@gmail.com wrote:
From: Xiao Guangrong
(1)
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/kfifo.h
(2) http://dpdk.org/doc/api/rte_
Am 21.06.2018 um 19:19 hat Kevin Wolf geschrieben:
> This simplifies file-posix by implementing the coroutine variants of
> the discard and flush BlockDriver callbacks. These were the last
> remaining users of paio_submit(), which can be removed now.
>
> Signed-off-by: Kevin Wolf
Applied to the
On 06/29/2018 12:23 PM, Michael S. Tsirkin wrote:
On Thu, Jun 28, 2018 at 09:36:00PM +0800, Jason Wang wrote:
On 2018年06月04日 17:55, guangrong.x...@gmail.com wrote:
From: Xiao Guangrong
Memory barrier is omitted here, please refer to the comment in the code.
(1)https://git.kernel.org/p
On 06/29/2018 02:15 PM, Jason Wang wrote:
On 2018年06月29日 11:59, Xiao Guangrong wrote:
On 06/28/2018 09:36 PM, Jason Wang wrote:
On 2018年06月04日 17:55, guangrong.x...@gmail.com wrote:
From: Xiao Guangrong
It's the simple lockless ring buffer implement which supports both
single produce
Am 29.06.2018 um 08:03 hat Fam Zheng geschrieben:
> These are unfortunately more serious than the previous two fixes but the
> patches are not complicated.
Thanks, applied to the block branch.
Kevin
The capability is used for the background vmstate saving
using the migration infrastructure.
Background vmstate saving means that the majority of vmstate
(RAM) is saved in the background when VM's vCPUS are running.
This helps to reduce the VM downtime on VM snapshotting.
Signed-off-by: Denis Plot
On 28 June 2018 at 13:38, Daniel P. Berrangé wrote:
> The following changes since commit 00928a421d47f49691cace1207481b7aad31b1f1:
>
> Merge remote-tracking branch
> 'remotes/pmaydell/tags/pull-target-arm-20180626' into staging (2018-06-26
> 18:23:49 +0100)
>
> are available in the Git reposit
The patch enables to save vmstate to a migration thread
in the background: ram is being saved while vCPUs are running.
This is done to reduce downtime on vm snapshotting: the majority
of vmstate is ram, the rest of devices consumes only a few MB of
memory on a typical vm.
By this moment, there were
Is done with support of the KVM patch returning the faulting address.
Signed-off-by: Denis Plotnikov
---
target/i386/kvm.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/target/i386/kvm.c b/target/i386/kvm.c
index 3ac5302bc5..b87881a8f1 100644
--- a/target/i386/kvm.c
+++
Allows to define sigsegv handler temporary for all threads.
This is useful to implement copy-on-write logic while
linux usefaultfd doesn't support write-protected faults.
In the future, switch to using WP userfaultfd when it's
available.
It's going to be used on background snapshotting.
Signed-of
The patch allows qemu to be aware of how to read kvm failed memeory
access.
This is a temporary patch. It sould be removed on importing
the kvm failed memeory access exit from the linux branch.
Signed-off-by: Denis Plotnikov
---
linux-headers/linux/kvm.h | 5 +
1 file changed, 5 insertions(
1. test bit
2. test and set bit
Signed-off-by: Denis Plotnikov
---
include/qemu/bitops.h | 24
1 file changed, 24 insertions(+)
diff --git a/include/qemu/bitops.h b/include/qemu/bitops.h
index 3f0926cf40..7b1c8c7baf 100644
--- a/include/qemu/bitops.h
+++ b/include/qemu/
The patch set adds the ability to make external snapshots while VM is running.
The workflow to make a snapshot is the following:
1. Pause the vm
2. Make a snapshot of block devices using the scheme of your choice
3. Turn on background-snapshot migration capability
4. Start the migration using the
Am 28.06.2018 um 22:15 hat Eric Blake geschrieben:
> My quest continues. I spent some time pruning sector-based usage
> out of qcow as far as possible (and was dismayed at how long it
> took to prove no iotests regressions); so for the other drivers, I
> did the bare minimum to get rid of an inter
It allows to intercept VM's RAM access and write them into the
snapshot.
Signed-off-by: Denis Plotnikov
---
include/exec/ram_addr.h | 7 +
include/exec/ramlist.h | 4 +-
migration/migration.c | 2 +-
migration/ram.c | 333 ++--
migration/ram.h
On Thu, Jun 28, 2018 at 08:55:48AM +0200, Markus Armbruster wrote:
> Peter Xu writes:
>
> > On Wed, Jun 27, 2018 at 01:23:07PM +0200, Markus Armbruster wrote:
> >> Daniel P. Berrangé writes:
> >>
> >> > On Wed, Jun 27, 2018 at 10:41:38AM +0200, Markus Armbruster wrote:
> >> >> Markus Armbruster
On 25 June 2018 at 14:12, Gerd Hoffmann wrote:
> Currently, the HDA device tries to sync itself with the QEMU audio
> backend by waiting for the guest driver to handle buffer completion
> interrupts. This causes the backend to often read too much data from the
> device, as well as running out of d
On 29 June 2018 at 01:15, Richard Henderson
wrote:
> We already check for the same condition within the normal integer
> sdiv and sdiv64 helpers. Use a slightly different formation that
> does not require deducing the expression type.
>
> Fixes: f97cfd596ed
> Signed-off-by: Richard Henderson
> -
On 29 June 2018 at 01:15, Richard Henderson
wrote:
> Leave ARM_CP_SVE, removing ARM_CP_FPU; the sve_access_check
> produced by the flag already includes fp_access_check. If
> we also check ARM_CP_FPU the double fp_access_check asserts.
>
> Reported-by: Laurent Desnogues
> Signed-off-by: Richard
On 29 June 2018 at 01:15, Richard Henderson
wrote:
> There is no need to re-set these 9 features already
> implied by the call to aarch64_a57_initfn.
>
> Signed-off-by: Richard Henderson
> ---
> target/arm/cpu64.c | 9 -
> 1 file changed, 9 deletions(-)
>
Reviewed-by: Peter Maydell
th
On 29 June 2018 at 01:15, Richard Henderson
wrote:
> There is no need to re-set these 3 features already
> implied by the call to aarch64_a15_initfn.
>
> Signed-off-by: Richard Henderson
> ---
> target/arm/cpu.c | 3 ---
> 1 file changed, 3 deletions(-)
Reviewed-by: Peter Maydell
thanks
-- PMM
On 29 June 2018 at 01:15, Richard Henderson
wrote:
> This register was added to aa32 state by ARMv8.2.
>
> Signed-off-by: Richard Henderson
> ---
> target/arm/cpu.h| 1 +
> target/arm/cpu.c| 4
> target/arm/cpu64.c | 2 ++
> target/arm/helper.c | 5 ++---
> 4 files changed, 9 inser
On 29 June 2018 at 01:15, Richard Henderson
wrote:
> For the supported extensions, fill in the appropriate bits in
> ID_ISAR5, ID_ISAR6, ID_AA64ISAR0, ID_AA64ISAR1.
>
> Signed-off-by: Richard Henderson
> ---
This makes sense, but I'd rather have a bit of time to think
about how exactly we want t
Am 28.06.2018 um 21:07 hat Eric Blake geschrieben:
> Match our code to the spec change in the previous patch - there's
> no reason for the refcount table to allow larger offsets than the
> L1/L2 tables.
What about internal snapshots? And anyway, because of the metadata
overhead, the physical image
* Eduardo Habkost (ehabk...@redhat.com) wrote:
> On Thu, Jun 28, 2018 at 04:45:02PM +0100, Daniel P. Berrangé wrote:
> [...]
> > What if we can borrow the concept of versioning from machine types and apply
> > it to CPU models directly. For example, considering the history of "Haswell"
> > in QEMU,
On Thu, Jun 28, 2018 at 03:20:41PM +0200, Markus Armbruster wrote:
> Peter Xu writes:
>
> > On Wed, Jun 27, 2018 at 03:13:57PM +0200, Markus Armbruster wrote:
> >> Monitor behavior changes even when the client rejects capability "oob".
> >>
> >> Traditionally, the monitor reads, executes and res
Am 28.06.2018 um 21:07 hat Eric Blake geschrieben:
> When reading a compressed image, we were allocating s->cluster_data
> to 32*cluster_size + 512 (possibly over 64 megabytes, for an image
> with 2M clusters). Let's check out the history:
>
> Back when qcow2 was first written, we used s->cluster
On 29 June 2018 at 09:29, Peter Maydell wrote:
> On 29 June 2018 at 01:15, Richard Henderson
> wrote:
>> We already check for the same condition within the normal integer
>> sdiv and sdiv64 helpers. Use a slightly different formation that
>> does not require deducing the expression type.
>>
>> F
On Thu, Jun 28, 2018 at 01:06:25PM +0200, Juan Quintela wrote:
> Balamuruhan S wrote:
> > On Wed, Jun 27, 2018 at 02:56:04PM +0200, Juan Quintela wrote:
> >> From: Daniel P. Berrangé
>
>
>
> > Hi Juan,
> >
> > I tried to perform multifd enabled migration and from qemu monitor
> > enabled m
* Eric Blake (ebl...@redhat.com) wrote:
> On 06/27/2018 03:41 PM, Zhang Chen wrote:
> > From: Zhang Chen
> >
> > Suggested by Markus Armbruster rename COLO unknown mode to none mode.
> >
> > Signed-off-by: Zhang Chen
> > ---
> > migration/colo-failover.c | 2 +-
> > migration/colo.c
Hello,
On Fri, Jun 29, 2018 at 2:15 AM, Richard Henderson
wrote:
> Leave ARM_CP_SVE, removing ARM_CP_FPU; the sve_access_check
> produced by the flag already includes fp_access_check. If
> we also check ARM_CP_FPU the double fp_access_check asserts.
>
> Reported-by: Laurent Desnogues
> Signed-o
On 28 June 2018 at 21:04, Paolo Bonzini wrote:
> The following changes since commit 4a83bf2f339d4b63ecd5ef48b9816c3b7ee24553:
>
> Merge remote-tracking branch 'remotes/juanquintela/tags/migration/20180627'
> into staging (2018-06-28 15:31:42 +0100)
>
> are available in the git repository at:
>
On 28 June 2018 at 22:35, Philippe Mathieu-Daudé wrote:
> On 06/28/2018 01:52 PM, Peter Maydell wrote:
>> On 27 June 2018 at 18:44, Alistair Francis wrote:
>>> The following changes since commit 00928a421d47f49691cace1207481b7aad31b1f1:
>>>
>>> Merge remote-tracking branch
>>> 'remotes/pmaydel
* Xiao Guangrong (guangrong.x...@gmail.com) wrote:
>
> Hi Peter,
>
> Sorry for the delay as i was busy on other things.
>
> On 06/19/2018 03:30 PM, Peter Xu wrote:
> > On Mon, Jun 04, 2018 at 05:55:14PM +0800, guangrong.x...@gmail.com wrote:
> > > From: Xiao Guangrong
> > >
> > > Detecting zer
On Thu, Jun 28, 2018 at 11:29:30AM +0200, Markus Armbruster wrote:
> Peter Xu writes:
>
> > On Wed, Jun 27, 2018 at 10:35:15AM +0200, Markus Armbruster wrote:
> >> Markus Armbruster writes:
> >>
> >> > Another lose end: event COMMAND_DROPPED seems to lack test coverage.
> >>
> >> Hmm, dropping
On 29/06/2018 11:25, Peter Maydell wrote:
> Hi; this fails to link the i386 linux-user binaries
> (x86-64 Linux host, debug build):
>
> LINKi386-linux-user/qemu-i386
> target/i386/cpu.o: In function `x86_cpu_realizefn':
> /home/petmay01/linaro/qemu-for-merges/target/i386/cpu.c:4814:
> undefi
Since the recent cleanups to hide host configuration details from guests,
it isn't possible to start an older machine type with HV KVM [*]:
qemu-system-ppc64: KVM doesn't support for base page shift 34
This basically boils down to the fact that it isn't safe to call
the kvmppc_hpt_needs_host_cont
Now that we're checking our MMU configuration is supported by KVM,
rather than adjusting it to KVM, it doesn't really make sense to
have a fallback for kvm_get_smmu_info(). If KVM is too old or buggy
to provide the details, we should rather treat this as an error.
This patch thus adds error report
It is currently not possible to run a pseries-2.12 or older machine
with HV KVM. QEMU prints the following and exits right away.
qemu-system-ppc64: KVM doesn't support for base page shift 34
The "hpt-max-page-size" capability was recently added to spapr to hide
host configuration details from HPT
In a future patch the machine code will need to retrieve the MMU
information from KVM during machine initialization before the CPUs
are created.
Actually, KVM_PPC_GET_SMMU_INFO is a VM class ioctl, and thus, we
don't need to have a CPU object around. We just need for KVM to
be initialized and use
The following changes since commit 4a83bf2f339d4b63ecd5ef48b9816c3b7ee24553:
Merge remote-tracking branch 'remotes/juanquintela/tags/migration/20180627'
into staging (2018-06-28 15:31:42 +0100)
are available in the git repository at:
git://github.com/bonzini/qemu.git tags/for-upstream
for
From: "Michael S. Tsirkin"
When guest CPU PM is enabled, and with -cpu host, expose the host CPU
MWAIT leaf in the CPUID so guest can make good PM decisions.
Note: the result is 100% CPU utilization reported by host as host
no longer knows that the CPU is halted.
Signed-off-by: Michael S. Tsirk
* Daniel P. Berrangé (berra...@redhat.com) wrote:
> On Thu, Jun 28, 2018 at 05:12:39PM +0800, Xiao Guangrong wrote:
> >
> > Hi Peter,
> >
> > Sorry for the delay as i was busy on other things.
> >
> > On 06/19/2018 03:30 PM, Peter Xu wrote:
> > > On Mon, Jun 04, 2018 at 05:55:14PM +0800, guangro
On Thu, Jun 28, 2018 at 01:00:44PM +0100, Daniel P. Berrangé wrote:
> On Thu, Jun 28, 2018 at 10:31:42AM +0200, Markus Armbruster wrote:
> > Peter Xu writes:
> >
> > > On Tue, Jun 26, 2018 at 07:21:49PM +0200, Markus Armbruster wrote:
> > >> I fooled around a bit, and I think there are a few lose
Sorry for being late, here are some thoughts. Anyway, idea is good,
we've planned to do something like this, but you were the first)
21.06.2018 06:25, Eric Blake wrote:
In order to test that the NBD server is properly advertising
dirty bitmaps, we need a bare minimum client that can request
and
Am 19.06.2018 um 15:43 hat Ari Sundholm geschrieben:
> A block driver may need to know about the block configuration, most
> critically the sector sizes, of a block backend for alignment purposes
> or for some other reason.
It makes sense to me that you need to know alignment constraints of the
th
On Thu, Jun 28, 2018 at 02:15:14PM +0200, Markus Armbruster wrote:
> Kashyap Chamarthy writes:
[...]
> There's also getrandom(2).
>
> See random(7) for a comparison between getrandom(), /dev/urandom,
> /dev/random.
>
> As you wrote, Linux's /dev/random blocks when the kernel entropy pool
> has
On Thu, Jun 28, 2018 at 07:59:38PM +0100, Dr. David Alan Gilbert wrote:
> * Daniel P. Berrangé (berra...@redhat.com) wrote:
> > This post is to raise question about helping use of named CPU models with
> > KVM ie any case not using -cpu host.
> >
> > In the old days (ie before 2018), the world was
On Thu, Jun 28, 2018 at 04:52:27PM -0300, Eduardo Habkost wrote:
> On Thu, Jun 28, 2018 at 04:45:02PM +0100, Daniel P. Berrangé wrote:
> [...]
> > What if we can borrow the concept of versioning from machine types and apply
> > it to CPU models directly. For example, considering the history of "Has
On 28/06/2018 22:24, Eric Blake wrote:
> On 06/28/2018 02:57 PM, Paolo Bonzini wrote:
>> Let management know if there were any problems communicating with
>> qemu-pr-helper. The event is edge-triggered, and is sent every time
>> the connection status of the pr-manager-helper object changes.
>
> I
On Fri, Jun 29, 2018 at 09:53:53AM +0100, Dr. David Alan Gilbert wrote:
> * Eduardo Habkost (ehabk...@redhat.com) wrote:
> > On Thu, Jun 28, 2018 at 04:45:02PM +0100, Daniel P. Berrangé wrote:
> > [...]
> > > What if we can borrow the concept of versioning from machine types and
> > > apply
> > >
On Fri, 29 Jun 2018 15:18:22 +1000
David Gibson wrote:
> On Thu, Jun 28, 2018 at 12:15:33PM +0200, Greg Kurz wrote:
> > It is unsafe to rely on *_enabled() helpers before the accelerator has
> > been initialized, ie, accel_init_machine() has succeeded, because they
> > always return false. But it
It is unsafe to rely on *_enabled() helpers before the accelerator has
been initialized, ie, accel_init_machine() has succeeded, because they
always return false. But it is still possible to end up calling them
indirectly by inadvertance, and cause QEMU to misbehave.
This patch causes QEMU to abor
Hi
On Wed, Jun 27, 2018 at 7:26 AM, Markus Armbruster wrote:
>>> This is hardly a rigorous proof. Just enough to make me believe your
>>> code works.
>>>
>>> However, I suspect adding the inheritance feature at the entity level
>>> complicates the correctness argument without real need. Can we
On 29 June 2018 at 10:51, Paolo Bonzini wrote:
> The following changes since commit 4a83bf2f339d4b63ecd5ef48b9816c3b7ee24553:
>
> Merge remote-tracking branch 'remotes/juanquintela/tags/migration/20180627'
> into staging (2018-06-28 15:31:42 +0100)
>
> are available in the git repository at:
>
On 29/06/2018 12:30, Peter Maydell wrote:
>
> This still fails in the same way:
> LINKi386-linux-user/qemu-i386
> target/i386/cpu.o: In function `x86_cpu_realizefn':
> /home/petmay01/linaro/qemu-for-merges/target/i386/cpu.c:4815:
> undefined reference to `enable_cpu_pm
> '
> collect2: error:
* Wei Wang (wei.w.w...@intel.com) wrote:
> The ram save state notifier callback, for example the free page
> optimization offerred by virtio-balloon, may need to check if
> postcopy is in use, so move migrate_postcopy() to the outside header.
Reasonable,
Reviewed-by: Dr. David Alan Gilbert
> S
On 29/06/2018 12:29, Greg Kurz wrote:
> It is unsafe to rely on *_enabled() helpers before the accelerator has
> been initialized, ie, accel_init_machine() has succeeded, because they
> always return false. But it is still possible to end up calling them
> indirectly by inadvertance, and cause QEMU
On Fri, Jun 29, 2018 at 12:35:09PM +0200, Paolo Bonzini wrote:
> On 29/06/2018 12:29, Greg Kurz wrote:
> > It is unsafe to rely on *_enabled() helpers before the accelerator has
> > been initialized, ie, accel_init_machine() has succeeded, because they
> > always return false. But it is still possi
On 29/06/2018 12:39, Daniel P. Berrangé wrote:
>> Also asserting current_machine != NULL is not necessary, since you're
>> immediately dereferencing it.
> Is there a practical way to simply initialize the accelerators earlier
> in startup sequence, so we just remove or at least reduce, the liklihoo
On Fri, 29 Jun 2018 12:35:09 +0200
Paolo Bonzini wrote:
> On 29/06/2018 12:29, Greg Kurz wrote:
> > It is unsafe to rely on *_enabled() helpers before the accelerator has
> > been initialized, ie, accel_init_machine() has succeeded, because they
> > always return false. But it is still possible t
On 29 June 2018 at 11:31, Paolo Bonzini wrote:
> On 29/06/2018 12:30, Peter Maydell wrote:
>>
>> This still fails in the same way:
>> LINKi386-linux-user/qemu-i386
>> target/i386/cpu.o: In function `x86_cpu_realizefn':
>> /home/petmay01/linaro/qemu-for-merges/target/i386/cpu.c:4815:
>> undef
On Fri, 29 Jun 2018 12:40:40 +0200
Paolo Bonzini wrote:
> On 29/06/2018 12:39, Daniel P. Berrangé wrote:
> >> Also asserting current_machine != NULL is not necessary, since you're
> >> immediately dereferencing it.
> > Is there a practical way to simply initialize the accelerators earlier
> > i
On 29/06/2018 13:07, Greg Kurz wrote:
Also asserting current_machine != NULL is not necessary, since you're
immediately dereferencing it.
>>> Is there a practical way to simply initialize the accelerators earlier
>>> in startup sequence, so we just remove or at least reduce, the likliho
On 29/06/2018 13:02, Peter Maydell wrote:
>>> This still fails in the same way:
>>> LINKi386-linux-user/qemu-i386
>>> target/i386/cpu.o: In function `x86_cpu_realizefn':
>>> /home/petmay01/linaro/qemu-for-merges/target/i386/cpu.c:4815:
>>> undefined reference to `enable_cpu_pm
>>> '
>>> colle
From: "Michael S. Tsirkin"
When guest CPU PM is enabled, and with -cpu host, expose the host CPU
MWAIT leaf in the CPUID so guest can make good PM decisions.
Note: the result is 100% CPU utilization reported by host as host
no longer knows that the CPU is halted.
Signed-off-by: Michael S. Tsirk
The following changes since commit 4a83bf2f339d4b63ecd5ef48b9816c3b7ee24553:
Merge remote-tracking branch 'remotes/juanquintela/tags/migration/20180627'
into staging (2018-06-28 15:31:42 +0100)
are available in the git repository at:
git://github.com/bonzini/qemu.git tags/for-upstream
for
On Fri, Jun 29, 2018 at 01:08:38PM +0200, Paolo Bonzini wrote:
> On 29/06/2018 13:07, Greg Kurz wrote:
> Also asserting current_machine != NULL is not necessary, since you're
> immediately dereferencing it.
> >>> Is there a practical way to simply initialize the accelerators earlier
> >
The physical address space size for a VM (IPA size) on arm/arm64 is
limited to a static limit of 40bits. This series adds support for
using an IPA size specific to a VM, allowing to use a limit supported
by the host (based on the host kernel configuration and CPU support).
The default and the min
virtio-mmio with virtio-v1 uses a 32bit PFN for the queue.
If the queue pfn is too large to fit in 32bits, which
we could hit on arm64 systems with 52bit physical addresses
(even with 64K page size), we simply miss out a proper link
to the other side of the queue.
Add a check to validate the PFN,
On arm64, ID_AA64MMFR0_EL1.PARange encodes the maximum Physical
Address range supported by the CPU. Add a helper to decode this
to actual physical shift. If we hit an unallocated value, return
the maximum range supported by the kernel.
This is will be used by the KVM to set the VTCR_EL2.T0SZ, as it
Use the new helper for converting the parange to the physical shift.
Also, add the missing definitions for the VTCR_EL2 register fields
and use them instead of hard coding numbers.
Cc: Marc Zyngier
Cc: Christoffer Dall
Signed-off-by: Suzuki K Poulose
---
Changes since V2
- Part 2 of the split
On arm64 VTTBR_EL2:BADDR holds the base address for the stage2
translation table. The Arm ARM mandates that the bits BADDR[x-1:0]
should be 0, where 'x' is defined for a given IPA Size and the
number of levels for a translation granule size. It is defined
using some magical constants. This patch is
On a 4-level page table pgd entry can be empty, unlike a 3-level
page table. Remove the spurious WARN_ON() in stage_get_pud().
Cc: Marc Zyngier
Acked-by: Christoffer Dall
Signed-off-by: Suzuki K Poulose
---
virt/kvm/arm/mmu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/
Legacy PCI over virtio uses a 32bit PFN for the queue. If the
queue pfn is too large to fit in 32bits, which we could hit on
arm64 systems with 52bit physical addresses (even with 64K page
size), we simply miss out a proper link to the other side of
the queue.
Add a check to validate the PFN, rath
So far we have only supported 3 level page table with fixed IPA of 40bits.
Fix stage2_flush_memslot() to accommodate for 4 level tables.
Cc: Marc Zyngier
Acked-by: Christoffer Dall
Signed-off-by: Suzuki K Poulose
---
virt/kvm/arm/mmu.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
d
We load the stage2 context of a guest for different operations,
including running the guest and tlb maintenance on behalf of the
guest. As of now only the vttbr is private to the guest, but this
is about to change with IPA per VM. Add a helper to load the stage2
configuration for a VM, which could
VTCR_EL2 holds the following key stage2 translation table
parameters:
SL0 - Entry level in the page table lookup.
T0SZ - Denotes the size of the memory addressed by the table.
We have been using fixed values for the SL0 depending on the
page size as we have a fixed IPA size. But since we are
So far we had a static stage2 page table handling code, based on a
fixed IPA of 40bits. As we prepare for a configurable IPA size per
VM, make our stage2 page table code dynamic, to do the right thing
for a given VM. We ensure the existing condition is always true even
when we lift the limit on the
Right now the stage2 page table for a VM is hard coded, assuming
an IPA of 40bits. As we are about to add support for per VM IPA,
prepare the stage2 page table helpers to accept the kvm instance
to make the right decision for the VM. No functional changes.
Adds stage2_pgd_size(kvm) to replace S2_PG
Expose the maximum physical address size supported by the host
for a VM. This could be later used by the userspace to choose the
appropriate size for a given VM. The limit is determined as the
minimum of actual CPU limit, the kernel limit (i.e, either 48 or 52)
and the stage2 page table support lim
From: Kristina Martsenko
Add support for handling 52bit guest physical address to the
VGIC layer. So far we have limited the guest physical address
to 48bits, by explicitly masking the upper bits. This patch
removes the restriction. We do not have to check if the host
supports 52bit as the gpa is
Abstract the allocation of stage2 entry level tables for
given VM, so that later we can choose to fall back to the
normal page table levels (i.e, avoid entry level table
concatenation) on arm64.
Cc: Marc Zyngier
Cc: Christoffer Dall
Signed-off-by: Suzuki K Poulose
---
Changes since V2:
- New p
Allow specifying the physical address size for a new VM via
the kvm_type argument for KVM_CREATE_VM ioctl. This allows
us to finalise the stage2 page table format as early as possible
and hence perform the right checks on the memory slots without
complication. The size is encoded as Log2(PA_Size) i
Add support for handling the 52bit IPA. 52bit IPA
support needs changes to the following :
1) Page-table entries - We use kernel page table helpers for setting
up the stage2. Hence we don't explicit changes here
2) VTTBR:BADDR - This is already supported with :
commit 529c4b05a3cb2f324aa ("
We set VTCR_EL2 very early during the stage2 init and don't
touch it ever. This is fine as we had a fixed IPA size. This
patch changes the behavior to set the VTCR for a given VM,
depending on its stage2 table. The common configuration for
VTCR is still performed during the early init as we have to
We use concatenated entry level page tables (upto 16tables) for
stage2. If we don't have sufficient contiguous pages (e.g, 16 * 64K),
fallback to the normal page table format, by going one level
deeper if permitted.
Cc: Marc Zyngier
Cc: Christoffer Dall
Signed-off-by: Suzuki K Poulose
---
New i
Add an option to specify the physical address size used by this
VM.
Signed-off-by: Suzuki K Poulose
---
arm/aarch64/include/kvm/kvm-config-arch.h | 5 -
arm/include/arm-common/kvm-config-arch.h | 1 +
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/arm/aarch64/include/kvm/kvm-
Specify the physical size for the VM encoded in the vm type.
Signed-off-by: Suzuki K Poulose
---
arm/include/arm-common/kvm-arch.h | 6 +-
arm/kvm.c | 22 ++
2 files changed, 27 insertions(+), 1 deletion(-)
diff --git a/arm/include/arm-common/kvm
Now that we can manage the stage2 page table per VM, switch the
configuration details to per VM instance. We keep track of the
IPA bits, number of page table levels and the VTCR bits (which
depends on the IPA and the number of levels). While at it, remove
unused pgd_lock field from kvm_arch for arm
So far we have restricted the IPA size of the VM to the default
value (40bits). Now that we can manage the IPA size per VM and
support dynamic stage2 page tables, allow VMs to have larger IPA.
This is done by setting the IPA limit to the one supported by
the hardware and kernel. This patch also mov
The following changes since commit 609ef9f451759151d0bfe7c3843410ab94d68f18:
Merge remote-tracking branch 'remotes/berrange/tags/qio-next-pull-request'
into staging (2018-06-28 17:53:31 +0100)
are available in the Git repository at:
https://github.com/berrange/qemu tags/min-glib-pull-reques
Allow architectures to perform initialisation based on the
KVM device fd ioctls, even before the VM is created.
Signed-off-by: Suzuki K Poulose
---
include/kvm/kvm.h | 4
kvm.c | 2 ++
2 files changed, 6 insertions(+)
diff --git a/include/kvm/kvm.h b/include/kvm/kvm.h
index 904
If the guest wants to use a larger physical address space place
the RAM at upper half of the address space. Otherwise, it uses the
default layout.
Signed-off-by: Suzuki K Poulose
---
arm/aarch32/include/kvm/kvm-arch.h | 6 --
arm/aarch64/include/kvm/kvm-arch.h | 15 ---
arm/incl
Per supported platforms doc[1], the various min glib on relevant distros is:
RHEL-7: 2.50.3
Debian (Stretch): 2.50.3
Debian (Jessie): 2.42.1
OpenBSD (Ports): 2.54.3
FreeBSD (Ports): 2.50.3
OpenSUSE Leap 15: 2.54.3
SLE12-SP2: 2.48.2
Ubuntu (Xenial): 2.48.0
macOS (Homebrew): 2.56.0
1 - 100 of 521 matches
Mail list logo
