Hi Julien,
On 3/20/19 2:19 PM, Julien Thierry wrote:
Hi Amit,
On 19/03/2019 08:30, Amit Daniel Kachhap wrote:
Currently hyp_symbol_addr is palced in kvm_mmu.h which is mostly
used by __hyp_this_cpu_ptr in kvm_asm.h but it cannot include
kvm_mmu.h directly as kvm_mmu.h uses kvm_ksym_ref which
On 20/03/2019 18:06, Julien Thierry wrote:
>
>
> On 20/03/2019 15:04, Kristina Martsenko wrote:
>> On 20/03/2019 13:37, Julien Thierry wrote:
>>> Hi Amit,
>>>
>>> On 19/03/2019 08:30, Amit Daniel Kachhap wrote:
This adds sections for KVM API extension for pointer authentication.
A
On 20/03/2019 15:04, Kristina Martsenko wrote:
> On 20/03/2019 13:37, Julien Thierry wrote:
>> Hi Amit,
>>
>> On 19/03/2019 08:30, Amit Daniel Kachhap wrote:
>>> This adds sections for KVM API extension for pointer authentication.
>>> A brief description about usage of pointer authentication
On Wed, 20 Mar 2019 22:18:13 +0800
Yue Haibing wrote:
> From: YueHaibing
>
> Fix sparse warnings:
>
> arch/arm64/kvm/../../../virt/kvm/arm/vgic/vgic-its.c:1732:5: warning:
> symbol 'vgic_its_has_attr_regs' was not declared. Should it be static?
>
On Wed, 20 Mar 2019 14:57:19 +
Suzuki K Poulose wrote:
> We rely on the mmu_notifier call backs to handle the split/merge
> of huge pages and thus we are guaranteed that, while creating a
> block mapping, either the entire block is unmapped at stage2 or it
> is missing permission.
>
>
On Wed, 20 Mar 2019 11:12:47 +
Suzuki K Poulose wrote:
> Marc,
>
> On 20/03/2019 10:35, Marc Zyngier wrote:
> > On Wed, 20 Mar 2019 10:23:39 +
> > Suzuki K Poulose wrote:
> >
> > Hi Suzuki,
> >
> >> Marc,
> >>
> >> On 20/03/2019 10:11, Marc Zyngier wrote:
> >>> On Wed, 20 Mar
On Tue, 19 Mar 2019 21:25:47 +0800
"Tangnianyao (ICT)" wrote:
> Hi, all
>
> Using gicv4, when guest is waiting for irq, it sends wfi and traps to kvm.
> When vlpi is forwarded to PE after its_vpe_deschedule, before halt_poll in
> kvm_vcpu_block, halt_poll may increase latency for this vlpi
On 20/03/2019 16:37, Jacob Pan wrote:
[...]
>> +struct iommu_inv_addr_info {
>> +#define IOMMU_INV_ADDR_FLAGS_PASID (1 << 0)
>> +#define IOMMU_INV_ADDR_FLAGS_ARCHID (1 << 1)
>> +#define IOMMU_INV_ADDR_FLAGS_LEAF (1 << 2)
>> +__u32 flags;
>> +__u32 archid;
>> +__u64 pasid;
>> +
From: YueHaibing
Fix sparse warnings:
arch/arm64/kvm/../../../virt/kvm/arm/vgic/vgic-its.c:1732:5: warning:
symbol 'vgic_its_has_attr_regs' was not declared. Should it be static?
arch/arm64/kvm/../../../virt/kvm/arm/vgic/vgic-its.c:1753:5: warning:
symbol 'vgic_its_attr_regs_access' was not
On Sun, 17 Mar 2019 18:22:15 +0100
Eric Auger wrote:
> From: "Liu, Yi L"
>
> In any virtualization use case, when the first translation stage
> is "owned" by the guest OS, the host IOMMU driver has no knowledge
> of caching structure updates unless the guest invalidation activities
> are
On 19/03/2019 14:39, Heyi Guo wrote:
> Hi Christoffer and Steve,
>
>
> On 2019/3/15 16:59, Christoffer Dall wrote:
>> Hi Steve,
>>
>> On Wed, Mar 13, 2019 at 10:11:30AM +, Steven Price wrote:
>>> Personally I think what we need is:
>>>
>>> * Either a patch like the one from Heyi Guo
On 20/03/2019 13:37, Julien Thierry wrote:
> Hi Amit,
>
> On 19/03/2019 08:30, Amit Daniel Kachhap wrote:
>> This adds sections for KVM API extension for pointer authentication.
>> A brief description about usage of pointer authentication for KVM guests
>> is added in the arm64 documentations.
We rely on the mmu_notifier call backs to handle the split/merge
of huge pages and thus we are guaranteed that, while creating a
block mapping, either the entire block is unmapped at stage2 or it
is missing permission.
However, we miss a case where the block mapping is split for dirty
logging
+cc Marc and Christoffer...
On 2019/3/19 21:25, Tangnianyao (ICT) wrote:
Hi, all
Using gicv4, when guest is waiting for irq, it sends wfi and traps to kvm.
When vlpi is forwarded to PE after its_vpe_deschedule, before halt_poll in
kvm_vcpu_block, halt_poll may increase latency for this vlpi
Hi Amit,
On 19/03/2019 08:30, Amit Daniel Kachhap wrote:
> This adds sections for KVM API extension for pointer authentication.
> A brief description about usage of pointer authentication for KVM guests
> is added in the arm64 documentations.
>
> Signed-off-by: Amit Daniel Kachhap
> Cc: Mark
On Tue, Mar 19, 2019 at 05:51:51PM +, Dave Martin wrote:
[...]
> Known issues:
>
> * This update requires modifications to kvmtool that are not published
>yet. I will reply to this cover letter with a link when those are
>available (hopefully within 24 hours of this posting).
>
>
Hi Amit,
On 19/03/2019 08:30, Amit Daniel Kachhap wrote:
> From: Mark Rutland
>
> When pointer authentication is supported, a guest may wish to use it.
> This patch adds the necessary KVM infrastructure for this to work, with
> a semi-lazy context switch of the pointer auth state.
>
> Pointer
In order to support use cases such as migration, it may be
important in some situations to restrict the set of SVE vector
lengths available to the guest. It can also be usefule to observe
the behaviour of guest OSes with different vector lengths.
To enable testing and experimentation for such
This patch adds an --sve command line option to allow the Scalable
Vector Extension to be enabled when creating a guest.
This requires use of the new KVM_ARM_VCPU_FINALIZE ioctl before the
vcpu is runnable, so a new hook kvm_cpu__configure_features() is
added to provide an appropiate place to do
This patch imports the necessary UAPI header definitions for
building the SVE extensions for kvmtool.
This commit should be replaced by a header import from upstream
Linux once the SVE kvm patches have been merged.
Signed-off-by: Dave Martin
---
arm/aarch64/include/asm/kvm.h | 22
This series, based on kvmtool master [1], contains development hacks
to accompany the recently posted v6 SVE guest support series for the
Linux kernel [2].
This series supersedes the previous posting [3], and is a clean(er)
rewrite of the minimal support required for SVE, without the debug/
Marc,
On 20/03/2019 10:35, Marc Zyngier wrote:
On Wed, 20 Mar 2019 10:23:39 +
Suzuki K Poulose wrote:
Hi Suzuki,
Marc,
On 20/03/2019 10:11, Marc Zyngier wrote:
On Wed, 20 Mar 2019 09:44:38 +
Suzuki K Poulose wrote:
Hi Marc,
On 20/03/2019 08:15, Marc Zyngier wrote:
Hi
On Wed, 20 Mar 2019 10:23:39 +
Suzuki K Poulose wrote:
Hi Suzuki,
> Marc,
>
> On 20/03/2019 10:11, Marc Zyngier wrote:
> > On Wed, 20 Mar 2019 09:44:38 +
> > Suzuki K Poulose wrote:
> >
> >> Hi Marc,
> >>
> >> On 20/03/2019 08:15, Marc Zyngier wrote:
> >>> Hi Suzuki,
> >>>
> >>>
Marc,
On 20/03/2019 10:11, Marc Zyngier wrote:
On Wed, 20 Mar 2019 09:44:38 +
Suzuki K Poulose wrote:
Hi Marc,
On 20/03/2019 08:15, Marc Zyngier wrote:
Hi Suzuki,
On Tue, 19 Mar 2019 14:11:08 +,
Suzuki K Poulose wrote:
We rely on the mmu_notifier call backs to handle the
On Wed, 20 Mar 2019 09:44:38 +
Suzuki K Poulose wrote:
> Hi Marc,
>
> On 20/03/2019 08:15, Marc Zyngier wrote:
> > Hi Suzuki,
> >
> > On Tue, 19 Mar 2019 14:11:08 +,
> > Suzuki K Poulose wrote:
> >>
> >> We rely on the mmu_notifier call backs to handle the split/merge
> >> of huge
Hi Marc,
On 20/03/2019 08:15, Marc Zyngier wrote:
Hi Suzuki,
On Tue, 19 Mar 2019 14:11:08 +,
Suzuki K Poulose wrote:
We rely on the mmu_notifier call backs to handle the split/merge
of huge pages and thus we are guaranteed that, while creating a
block mapping, either the entire block is
Hi Amit,
On 19/03/2019 08:30, Amit Daniel Kachhap wrote:
> Currently hyp_symbol_addr is palced in kvm_mmu.h which is mostly
> used by __hyp_this_cpu_ptr in kvm_asm.h but it cannot include
> kvm_mmu.h directly as kvm_mmu.h uses kvm_ksym_ref which is
> defined inside kvm_asm.h. Hence,
On Tue, Mar 19, 2019 at 09:33:58AM +0800, Leo Yan wrote:
[...]
> So far, it still cannot work well if I only set "sky2.disable_msi=1"
> for host kernel command line, with this config it runs with below flow
> and which cannot forward interrupt properly from host to guest:
>
> host
Hi Suzuki,
On Tue, 19 Mar 2019 14:11:08 +,
Suzuki K Poulose wrote:
>
> We rely on the mmu_notifier call backs to handle the split/merge
> of huge pages and thus we are guaranteed that, while creating a
> block mapping, either the entire block is unmapped at stage2 or it
> is missing
The PCI device INTx uses event fd 'unmask_fd' to signal the deassertion
of the line from guest to host; but this eventfd isn't released properly
when disable INTx.
This patch firstly adds field 'unmask_fd' in struct vfio_pci_device for
storing unmask eventfd and close it when disable INTx.
Since PCI forbids enabling INTx, MSI or MSIX at the same time, it's by
default to disable INTx mode when enable MSI/MSIX mode; but this logic is
easily broken if the guest PCI driver detects the MSI/MSIX cannot work as
expected and tries to rollback to use INTx mode. The INTx mode has been
When enable vfio-pci mode for NIC driver on Juno board, the IRQ is
failed to forward properly from host to guest, finally root caused this
issue is related with kvmtool cannot re-enable INTx mode properly.
So the basic working flow to reproduce this issue is as below:
Host Guest
Since INTx only uses 2 FDs, it's not particularly useful to reserve FDs
in function vfio_pci_enable_intx(); so this patch is to remove FDs
reservation in this function.
Signed-off-by: Leo Yan
---
vfio/pci.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/vfio/pci.c b/vfio/pci.c
index
33 matches
Mail list logo
