On 9 July 2015 at 14:49, Paolo Bonzini pbonz...@redhat.com wrote:
On 09/07/2015 10:13, Leon Alrae wrote:
On 08/07/2015 16:22, Paolo Bonzini wrote:
On 08/07/2015 17:03, James Hogan wrote:
Hi Paolo,
On 24/04/15 11:26, James Hogan wrote:
A couple of small fixes for accessing 32-bit KVM
On Thu, 2015-07-09 at 14:28 +0200, Joerg Roedel wrote:
On Tue, Jul 07, 2015 at 11:17:48AM -0600, Alex Williamson wrote:
Hosting the bypass manager in kernel/irq seemed appropriate, but really
it could be anywhere. Does anyone have a different preference or
specifically want it under their
On 09/07/2015 16:13, Alex Williamson wrote:
On Thu, 2015-07-09 at 14:28 +0200, Joerg Roedel wrote:
On Tue, Jul 07, 2015 at 11:17:48AM -0600, Alex Williamson wrote:
Hosting the bypass manager in kernel/irq seemed appropriate, but really
it could be anywhere. Does anyone have a different
On Thu, Jul 09, 2015 at 02:24:06PM +0200, Christoffer Dall wrote:
On Thu, Jul 09, 2015 at 01:07:24PM +0100, Peter Maydell wrote:
On 9 July 2015 at 13:05, Christoffer Dall christoffer.d...@linaro.org
wrote:
As I understand it, the problem is that if we ever run a VCPU after
reading the
On 9 July 2015 at 15:17, Christoffer Dall christoffer.d...@linaro.org wrote:
On Thu, Jul 09, 2015 at 02:24:06PM +0200, Christoffer Dall wrote:
So I ran this through GDB, and this happens when the guest probes the
virtio devices, specifically the backtrace tells me that
On 09/07/2015 04:30, Xiao Guangrong wrote:
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 602b974a60a6..0f125c1860ec 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -1085,6 +1085,47 @@ static u64 svm_compute_tsc_offset(struct
kvm_vcpu *vcpu, u64 target_tsc)
Hi Pavel,
On 09/07/15 15:37, Pavel Fedin wrote:
Hello!
v1 - v2:
- user API changed:
x devid id passed in kvm_irq_routing_msi
x kept the new routing entry type: KVM_IRQ_ROUTING_EXTENDED_MSI
Andre, you never replied to my last comment to the previous series.
Oh dear, my draft
On 09/07/2015 10:13, Leon Alrae wrote:
On 08/07/2015 16:22, Paolo Bonzini wrote:
On 08/07/2015 17:03, James Hogan wrote:
Hi Paolo,
On 24/04/15 11:26, James Hogan wrote:
A couple of small fixes for accessing 32-bit KVM registers on
big endian, and to sign extend struct kvm_regs registers
On 9 July 2015 at 12:52, Leon Alrae leon.al...@imgtec.com wrote:
On 09/07/2015 10:17, James Hogan wrote:
These two patches fix build errors for the MIPS TCG backend and MIPS
KVM.
Please could they be applied for v2.4.
James Hogan (2):
tcg/mips: Fix build error from merged memop+mmu_idx
Hello!
v1 - v2:
- user API changed:
x devid id passed in kvm_irq_routing_msi
x kept the new routing entry type: KVM_IRQ_ROUTING_EXTENDED_MSI
Andre, you never replied to my last comment to the previous series. Are you
going to do the same
change in your MSI API? Otherwise:
1.
On 09/07/2015 16:00, Peter Maydell wrote:
I've actually just applied them to master as buildfixes :-)
No, wait, I'm confusing this set with a different 2-patch
set of MIPS fixes. Paolo, can you go ahead and take them through
the kvm tree?
Sure, I had already queued them in fact.
Paolo
On 9 July 2015 at 14:58, Peter Maydell peter.mayd...@linaro.org wrote:
On 9 July 2015 at 14:49, Paolo Bonzini pbonz...@redhat.com wrote:
It's the same---they can go in through any tree. In this case I've now
applied them and will send them out next week.
I've actually just applied them to
On Thu, Jul 09, 2015 at 04:38:41PM +0200, Paolo Bonzini wrote:
On Tue, Jul 07, 2015 at 11:17:48AM -0600, Alex Williamson wrote:
If we think that it's *only* a kvm-vfio interaction then we could add it
to virt/kvm/vfio.c. vfio could use symbol_get to avoid a module
dependency and
Hi!
3. KVM_SET_GSI_ROUTING - we use KVM_IRQ_ROUTING_EXTENDED_MSI plus devid
Here we already have a type field with some users, so lets piggy-back on
this.
We already have 'flags' there too.
Both ioctl extensions are coupled with a per-VM capability to let
userland know that it needs
On Thu, Jul 09, 2015 at 03:26:20PM +0100, Peter Maydell wrote:
On 9 July 2015 at 15:17, Christoffer Dall christoffer.d...@linaro.org wrote:
On Thu, Jul 09, 2015 at 02:24:06PM +0200, Christoffer Dall wrote:
So I ran this through GDB, and this happens when the guest probes the
virtio devices,
Hi Pavel, Andre,
On 07/09/2015 05:52 PM, Pavel Fedin wrote:
Hi!
3. KVM_SET_GSI_ROUTING - we use KVM_IRQ_ROUTING_EXTENDED_MSI plus devid
Here we already have a type field with some users, so lets piggy-back on
this.
We already have 'flags' there too.
Both ioctl extensions are coupled
On Thu, 2015-07-09 at 17:34 +0200, Joerg Roedel wrote:
On Thu, Jul 09, 2015 at 04:38:41PM +0200, Paolo Bonzini wrote:
On Tue, Jul 07, 2015 at 11:17:48AM -0600, Alex Williamson wrote:
If we think that it's *only* a kvm-vfio interaction then we could add it
to virt/kvm/vfio.c. vfio could
Paolo Bonzini pbonz...@redhat.com writes:
On 09/07/2015 08:43, Laszlo Ersek wrote:
On 07/09/15 08:09, Paolo Bonzini wrote:
On 09/07/2015 00:36, Bandan Das wrote:
Let userspace inquire the maximum physical address width
of the host processors; this can be used to identify maximum
memory
On 07/09/15 20:32, Bandan Das wrote:
Paolo Bonzini pbonz...@redhat.com writes:
On 09/07/2015 08:43, Laszlo Ersek wrote:
On 07/09/15 08:09, Paolo Bonzini wrote:
On 09/07/2015 00:36, Bandan Das wrote:
Let userspace inquire the maximum physical address width
of the host processors; this can
Well personally I prefer the type thing and I don't see much difference
at userspace level anyway. But I am not this kind of hyperspace
architect guy. So, since there is no consensus here, I would say let's
wait for formal reviews of our maintainers and I will align.
Hah, okay... Don't take
Laszlo Ersek ler...@redhat.com writes:
...
First, see my comments on the KVM patch.
Second, ram_size is not the right thing to compare. What should be
checked is whether the highest guest-physical address that maps to RAM
can be represented in the address width of the host processor (and
On Thu, 9 Jul 2015 16:07:47 +0300
Michael S. Tsirkin m...@redhat.com wrote:
On Thu, Jul 09, 2015 at 02:57:33PM +0200, Paolo Bonzini wrote:
On 09/07/2015 11:48, Laurent Vivier wrote:
On 09/07/2015 09:49, Thomas Huth wrote:
The option for supporting cross-endianness legacy
On Thu, 9 Jul 2015 16:07:47 +0300
Michael S. Tsirkin m...@redhat.com wrote:
On Thu, Jul 09, 2015 at 02:57:33PM +0200, Paolo Bonzini wrote:
On 09/07/2015 11:48, Laurent Vivier wrote:
On 09/07/2015 09:49, Thomas Huth wrote:
The option for supporting cross-endianness legacy
On Fri, 2015-07-10 at 11:00 +0800, Feng Wu wrote:
Add the following x86 specific routines for irqbypass manger:
- kvm_arch_irq_bypass_add_producer
- kvm_arch_irq_bypass_del_producer
- kvm_arch_irq_bypass_stop
- kvm_arch_irq_bypass_resume
- kvm_arch_irq_bypass_update
Signed-off-by: Feng
-Original Message-
From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On
Behalf Of Alex Williamson
Sent: Friday, July 10, 2015 11:26 AM
To: Wu, Feng
Cc: kvm@vger.kernel.org; pbonz...@redhat.com; j...@8bytes.org;
avi.kiv...@gmail.com; eric.au...@linaro.org
Subject:
Bandan Das b...@redhat.com writes:
Laszlo Ersek ler...@redhat.com writes:
...
Yes.
Without EPT, you don't
hit the processor limitation with your setup, but the user should
nevertheless
still be notified.
I disagree.
In fact, I think shadow paging code should also emulate
this
On 07/09/2015 11:18 PM, Paolo Bonzini wrote:
On 09/07/2015 04:30, Xiao Guangrong wrote:
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 602b974a60a6..0f125c1860ec 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -1085,6 +1085,47 @@ static u64
This patch adds the registration/unregistration of an
irq_bypass_producer for MSI/MSIx on vfio pci devices.
Signed-off-by: Feng Wu feng...@intel.com
---
drivers/vfio/pci/vfio_pci_intrs.c | 8 ++--
drivers/vfio/pci/vfio_pci_private.h | 2 ++
2 files changed, 8 insertions(+), 2 deletions(-)
Add reference to struct irq_bypass_produce so we can get the producer
information from the consumer side.
Signed-off-by: Feng Wu feng...@intel.com
---
include/linux/kvm_irqfd.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/kvm_irqfd.h b/include/linux/kvm_irqfd.h
index
Call update routine when updating irqfd, this can update the
IRTE for Intel posted-interrupts.
Signed-off-by: Feng Wu feng...@intel.com
---
virt/kvm/eventfd.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/virt/kvm/eventfd.c b/virt/kvm/eventfd.c
index a32cf6c..1226835
This patch adds the routine to update IRTE for posted-interrupts
when guest changes the interrupt configuration.
Signed-off-by: Feng Wu feng...@intel.com
---
arch/x86/kvm/x86.c | 73 ++
1 file changed, 73 insertions(+)
diff --git
Add the following x86 specific routines for irqbypass manger:
- kvm_arch_irq_bypass_add_producer
- kvm_arch_irq_bypass_del_producer
- kvm_arch_irq_bypass_stop
- kvm_arch_irq_bypass_resume
- kvm_arch_irq_bypass_update
Signed-off-by: Feng Wu feng...@intel.com
---
arch/x86/kvm/Kconfig | 1 +
This series is based on Alex and Eric's irq bypass manager framework. To
make things clear, I only send out the patches related to irq bypass
manager, the purpose here is to show how certain callbacks are used
in VT-d PI and help to improve the irqbypass manager itself.
Feng Wu (5):
vfio:
On Fri, 2015-07-10 at 11:00 +0800, Feng Wu wrote:
Call update routine when updating irqfd, this can update the
IRTE for Intel posted-interrupts.
Signed-off-by: Feng Wu feng...@intel.com
---
virt/kvm/eventfd.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git
The option for supporting cross-endianness legacy guests in
the vhost and tun code should only be available on systems
that support cross-endian guests.
Signed-off-by: Thomas Huth th...@redhat.com
---
arch/arm/kvm/Kconfig | 1 +
arch/arm64/kvm/Kconfig | 1 +
arch/powerpc/kvm/Kconfig | 1 +
On 08/07/2015 16:22, Paolo Bonzini wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 08/07/2015 17:03, James Hogan wrote:
Hi Paolo,
On 24/04/15 11:26, James Hogan wrote:
A couple of small fixes for accessing 32-bit KVM registers on
big endian, and to sign extend struct
On 9 July 2015 at 11:22, Christoffer Dall christoffer.d...@linaro.org wrote:
On Wed, Jul 08, 2015 at 08:13:59PM +0100, Peter Maydell wrote:
I suspect Jan is right and we really need to distinguish
the KVM_PUT_*_STATE levels in ARM QEMU. This probably
implies some kind of whitelist/override
On 2015-07-09 12:22, Christoffer Dall wrote:
Hi Peter and Marc,
[cc'ing Paolo for his input on x86 timekeeping]
On Wed, Jul 08, 2015 at 08:13:59PM +0100, Peter Maydell wrote:
On 8 July 2015 at 17:37, Marc Zyngier marc.zyng...@arm.com wrote:
On 08/07/15 17:06, Peter Maydell wrote:
I'd
On 07/09/15 08:09, Paolo Bonzini wrote:
On 09/07/2015 00:36, Bandan Das wrote:
Let userspace inquire the maximum physical address width
of the host processors; this can be used to identify maximum
memory that can be assigned to the guest.
Reported-by: Laszlo Ersek ler...@redhat.com
[ 68.196974] WARNING: CPU: 1 PID: 2140 at arch/x86/kvm/x86.c:3161
kvm_arch_vcpu_ioctl+0xe88/0x1340 [kvm]()
[ 68.196975] Modules linked in: snd_hda_codec_hdmi i915 rfcomm bnep bluetooth
i2c_algo_bit rfkill nfsd drm_kms_helper nfs_acl nfs drm lockd grace sunrpc
fscache snd_hda_codec_realtek
On 09/07/2015 00:36, Bandan Das wrote:
Let userspace inquire the maximum physical address width
of the host processors; this can be used to identify maximum
memory that can be assigned to the guest.
Reported-by: Laszlo Ersek ler...@redhat.com
Signed-off-by: Bandan Das b...@redhat.com
---
On 07/09/15 00:42, Bandan Das wrote:
If a Linux guest is assigned more memory than is supported
by the host processor, the guest is unable to boot. That
is expected, however, there's no message indicating the user
what went wrong. This change prints a message to stderr if
KVM has the
The option for supporting cross-endianness legacy guests in
the vhost and tun code should only be available on systems
that support cross-endian guests.
Signed-off-by: Thomas Huth th...@redhat.com
---
arch/arm/kvm/Kconfig | 1 +
arch/arm64/kvm/Kconfig | 1 +
arch/powerpc/kvm/Kconfig | 1 +
On 09/07/2015 00:42, Bandan Das wrote:
If a Linux guest is assigned more memory than is supported
by the host processor, the guest is unable to boot. That
is expected, however, there's no message indicating the user
what went wrong. This change prints a message to stderr if
KVM has the
On 07/09/15 09:59, Paolo Bonzini wrote:
On 09/07/2015 00:42, Bandan Das wrote:
If a Linux guest is assigned more memory than is supported
by the host processor, the guest is unable to boot. That
is expected, however, there's no message indicating the user
what went wrong. This change
On Mon, Jul 06, 2015 at 09:44:07AM +0100, Miguel Barbosa Gonçalves wrote:
I am building a KVM cluster that needs VM live migration.
My shared storage as well as the KVM hosts will be running
CentOS.
Because 10 Gbps Ethernet switches are very expensive at the
moment I will connect the KVM
These two patches fix build errors for the MIPS TCG backend and MIPS
KVM.
Please could they be applied for v2.4.
James Hogan (2):
tcg/mips: Fix build error from merged memop+mmu_idx parameter
mips/kvm: Sync with newer MIPS KVM headers
target-mips/kvm.c | 15 ++-
The KVM_REG_MIPS_COUNT_* definitions are now included in
linux-headers/asm-mips/kvm.h since commit b061808d39fa (linux-headers:
update linux headers to kvm/next), therefore the duplicate definitions
in target-mips/kvm.c can now be dropped (the definitions were tweaked
slightly in commit
Hi Mario,
On 09/07/15 02:29, Mario Smarduch wrote:
On 07/08/2015 09:19 AM, Marc Zyngier wrote:
In order to switch between host and guest, a VHE-enabled kernel
must use different accessors for certain system registers.
This patch uses runtime patching to use the right instruction
when
With the advent of GICv3 ITS in-kernel emulation, KVM GSI routing
appears to be requested. More specifically MSI routing is needed.
irqchip routing does not sound to be really useful on arm but usage of
MSI routing also mandates to integrate irqchip routing. The initial
implementation of irqfd on
Implement a default routing table made of flat irqchip routing
entries (gsi = irqchip.pin) covering the VGIC SPI indexes.
This routing table is overwritten by the first user-space call
to KVM_SET_GSI_ROUTING ioctl.
Signed-off-by: Eric Auger eric.au...@linaro.org
---
PATCH: creation
---
Extend kvm_kernel_irq_routing_entry to transport devid. This is
needed for ARM. Its validity depends on the routing type entry.
Signed-off-by: Eric Auger eric.au...@linaro.org
---
v1 - v2:
replace msi_msg field by a struct composed of msi_msg and devid
RFC - PATCH:
- reword the commit message
If the ITS modality is not available, let's simply support MSI
injection by transforming the MSI.data into an SPI ID.
This becomes possible to use KVM_SIGNAL_MSI ioctl for arm too.
Signed-off-by: Eric Auger eric.au...@linaro.org
---
v1 - v2:
- introduce vgic_v2m_inject_msi in vgic-v2-emul.c
Up to now, only irqchip routing entries could be set. This patch
adds the capability to insert MSI routing entries, with or without
device id. Although standard MSI entries can be set, their
injection still is not supported. For ARM64, let's also increase
KVM_MAX_IRQ_ROUTES to 4096: include SPI
on ARM, a devid field is populated in kvm_msi struct in case the
flag is set to KVM_MSI_VALID_DEVID. Let's populate the corresponding
kvm_kernel_irq_routing_entry devid field and set the msi type to
KVM_IRQ_ROUTING_EXTENDED_MSI.
Signed-off-by: Eric Auger eric.au...@linaro.org
---
This patch adds compilation and link against irqchip.
On ARM, irqchip routing is not really useful since there is
a single irqchip. However main motivation behind using irqchip
code is to enable MSI routing code. With the support of in-kernel
GICv3 ITS emulation, it now seems to be a MUST HAVE
On ARM, the MSI msg (address and data) comes along with
out-of-band device ID information. The device ID encodes the
device that writes the MSI msg. Let's convey the device id in
kvm_irq_routing_msi and use a new routing entry type to
indicate the devid is populated.
Signed-off-by: Eric Auger
On Tue, Jul 07, 2015 at 02:11:01PM +0300, Pavel Fedin wrote:
Allows to use KVM on hardware without vGIC. Interrupt controller has to be
emulated in userspace in this case.
Signed-off-by: Pavel Fedin p.fe...@samsung.com
---
arch/arm/kvm/arm.c | 19 ++-
1 file changed, 18
On 09/07/2015 10:17, James Hogan wrote:
These two patches fix build errors for the MIPS TCG backend and MIPS
KVM.
Please could they be applied for v2.4.
James Hogan (2):
tcg/mips: Fix build error from merged memop+mmu_idx parameter
mips/kvm: Sync with newer MIPS KVM headers
On Thu, 9 Jul 2015 09:49:05 +0200
Thomas Huth th...@redhat.com wrote:
The option for supporting cross-endianness legacy guests in
s/cross-endianness/cross-endian/ ?
the vhost and tun code should only be available on systems
that support cross-endian guests.
Signed-off-by: Thomas Huth
On Thu, 9 Jul 2015 09:49:05 +0200
Thomas Huth th...@redhat.com wrote:
The option for supporting cross-endianness legacy guests in
s/cross-endianness/cross-endian/ ?
the vhost and tun code should only be available on systems
that support cross-endian guests.
Signed-off-by: Thomas Huth
On Tue, Jul 07, 2015 at 11:17:48AM -0600, Alex Williamson wrote:
Hosting the bypass manager in kernel/irq seemed appropriate, but really
it could be anywhere. Does anyone have a different preference or
specifically want it under their scope? We had originally thought of
this as an IOMMU
On 9 July 2015 at 13:05, Christoffer Dall christoffer.d...@linaro.org wrote:
As I understand it, the problem is that if we ever run a VCPU after
reading the value, and write back the value afterwards, you potentially
make time go backwards and get inconsistent views of time from different
On Thu, Jul 09, 2015 at 01:07:24PM +0100, Peter Maydell wrote:
On 9 July 2015 at 13:05, Christoffer Dall christoffer.d...@linaro.org wrote:
As I understand it, the problem is that if we ever run a VCPU after
reading the value, and write back the value afterwards, you potentially
make time
On Tue, Jul 07, 2015 at 11:24:06AM +0100, Will Deacon wrote:
On Tue, Jul 07, 2015 at 11:06:57AM +0100, Zhichao Huang wrote:
Chazy and me are talking about how to reduce the saving/restoring
overhead for debug registers.
We want to add a state in hw_breakpoint.c to indicate whether the host
On Thu, Jul 09, 2015 at 11:38:40AM +0100, Peter Maydell wrote:
On 9 July 2015 at 11:22, Christoffer Dall christoffer.d...@linaro.org wrote:
On Wed, Jul 08, 2015 at 08:13:59PM +0100, Peter Maydell wrote:
I suspect Jan is right and we really need to distinguish
the KVM_PUT_*_STATE levels in
Hi Jan,
On Thu, Jul 09, 2015 at 12:40:39PM +0200, Jan Kiszka wrote:
On 2015-07-09 12:22, Christoffer Dall wrote:
Hi Peter and Marc,
[cc'ing Paolo for his input on x86 timekeeping]
On Wed, Jul 08, 2015 at 08:13:59PM +0100, Peter Maydell wrote:
On 8 July 2015 at 17:37, Marc Zyngier
Hi,
+static inline bool is_kernel_in_hyp_mode(void)
+{
+ u64 el;
+
+ asm(mrs %0, CurrentEL : =r (el));
+ return el == CurrentEL_EL2;
+}
If you can include cputype.h, I think this can be:
static inline bool is_kernel_in_hyp_mode(void)
{
return read_cpuid(CurrentEL) ==
On 09/07/2015 09:49, Thomas Huth wrote:
The option for supporting cross-endianness legacy guests in
the vhost and tun code should only be available on systems
that support cross-endian guests.
I'm sure I misunderstand something, but what happens if we use QEMU with
TCG instead of KVM, i.e. a
On Tue, Jul 07, 2015 at 05:29:52PM +0100, Alex Bennée wrote:
Here is V8 of the KVM Guest Debug support for arm64.
The diffstat between v7 and v8 is getting pretty small and as I
haven't re-based you can run:
git diff -u guest-debug/4.1-v7..guest-debug/4.1-v8
And the kernelci
On 09/07/15 10:48, Mark Rutland wrote:
On Wed, Jul 08, 2015 at 05:19:06PM +0100, Marc Zyngier wrote:
Add a new ARM64_HAS_VIRT_HOST_EXTN features to indicate that the
CPU has the ARMv8,1 VHE capability.
Nit: s/,/./
It's probably worth mentioning somewhere that we have to check CurrentEL
On Thu, Jul 09, 2015 at 09:49:05AM +0200, Thomas Huth wrote:
The option for supporting cross-endianness legacy guests in
the vhost and tun code should only be available on systems
that support cross-endian guests.
Signed-off-by: Thomas Huth th...@redhat.com
Acked-by: Christoffer Dall
On Thu, Jul 09, 2015 at 09:49:05AM +0200, Thomas Huth wrote:
The option for supporting cross-endianness legacy guests in
the vhost and tun code should only be available on systems
that support cross-endian guests.
Signed-off-by: Thomas Huth th...@redhat.com
Acked-by: Christoffer Dall
On Thu, 09 Jul 2015 09:02:38 +0200
Laszlo Ersek ler...@redhat.com wrote:
On 07/09/15 00:42, Bandan Das wrote:
If a Linux guest is assigned more memory than is supported
by the host processor, the guest is unable to boot. That
is expected, however, there's no message indicating the user
On Wed, Jul 08, 2015 at 05:19:06PM +0100, Marc Zyngier wrote:
Add a new ARM64_HAS_VIRT_HOST_EXTN features to indicate that the
CPU has the ARMv8,1 VHE capability.
Nit: s/,/./
It's probably worth mentioning somewhere that we have to check CurrentEL
rather than a feature register in case some
On 09/07/2015 09:49, Thomas Huth wrote:
The option for supporting cross-endianness legacy guests in
the vhost and tun code should only be available on systems
that support cross-endian guests.
I'm sure I misunderstand something, but what happens if we use QEMU with
TCG instead of KVM, i.e. a
On 07/09/15 11:27, Igor Mammedov wrote:
On Thu, 09 Jul 2015 09:02:38 +0200
Laszlo Ersek ler...@redhat.com wrote:
On 07/09/15 00:42, Bandan Das wrote:
If a Linux guest is assigned more memory than is supported
by the host processor, the guest is unable to boot. That
is expected, however,
On 09/07/15 10:42, Mark Rutland wrote:
Hi,
+static inline bool is_kernel_in_hyp_mode(void)
+{
+u64 el;
+
+asm(mrs %0, CurrentEL : =r (el));
+return el == CurrentEL_EL2;
+}
If you can include cputype.h, I think this can be:
static inline bool is_kernel_in_hyp_mode(void)
On Thu, Jul 09, 2015 at 11:05:34AM +0100, Marc Zyngier wrote:
On 09/07/15 10:42, Mark Rutland wrote:
Hi,
+static inline bool is_kernel_in_hyp_mode(void)
+{
+ u64 el;
+
+ asm(mrs %0, CurrentEL : =r (el));
+ return el == CurrentEL_EL2;
+}
If you can include cputype.h, I
Hi Peter and Marc,
[cc'ing Paolo for his input on x86 timekeeping]
On Wed, Jul 08, 2015 at 08:13:59PM +0100, Peter Maydell wrote:
On 8 July 2015 at 17:37, Marc Zyngier marc.zyng...@arm.com wrote:
On 08/07/15 17:06, Peter Maydell wrote:
I'd prefer it if somebody could investigate to see why
On Wed, 08 Jul 2015 18:42:01 -0400
Bandan Das b...@redhat.com wrote:
If a Linux guest is assigned more memory than is supported
by the host processor, the guest is unable to boot. That
is expected, however, there's no message indicating the user
what went wrong. This change prints a message
Hello!
why not report ENXIO as an error? If probing the vgic fails due to
being unable to request the irq or something similar, then surely your
system has and error and this should be reported.
It is reported by probe function itself.
-ENODEV here means there's no GIC at all. -ENXIO
On 09/07/2015 09:44, Wanpeng Li wrote:
[ 68.196974] WARNING: CPU: 1 PID: 2140 at arch/x86/kvm/x86.c:3161
kvm_arch_vcpu_ioctl+0xe88/0x1340 [kvm]()
[ 68.196975] Modules linked in: snd_hda_codec_hdmi i915 rfcomm bnep
bluetooth i2c_algo_bit rfkill nfsd drm_kms_helper nfs_acl nfs drm lockd
On July 9, 2015 1:08:55 AM GMT+08:00, Will Deacon will.dea...@arm.com wrote:
On Wed, Jul 08, 2015 at 11:50:22AM +0100, Zhichao Huang wrote:
Are you happy with this?:
You miss the reserved breakpoint, I think.
Sorry, I can't quite understand. What is the reserved breakpoint?
When
On Thu, Jul 09, 2015 at 02:57:33PM +0200, Paolo Bonzini wrote:
On 09/07/2015 11:48, Laurent Vivier wrote:
On 09/07/2015 09:49, Thomas Huth wrote:
The option for supporting cross-endianness legacy guests in
the vhost and tun code should only be available on systems
that support
The GICv2 and GICv3 architectures allow an active physical interrupt
to be forwarded to a guest, and the guest to indirectly perform the
deactivation of the interrupt by performing an EOI on the virtual
interrupt (see for example the GICv2 spec, 3.2.1).
This allows some substantial performance
On Thu, Jul 09, 2015 at 03:50:49PM +0300, Pavel Fedin wrote:
Hello!
why not report ENXIO as an error? If probing the vgic fails due to
being unable to request the irq or something similar, then surely your
system has and error and this should be reported.
It is reported by probe
On 09/07/2015 08:43, Laszlo Ersek wrote:
On 07/09/15 08:09, Paolo Bonzini wrote:
On 09/07/2015 00:36, Bandan Das wrote:
Let userspace inquire the maximum physical address width
of the host processors; this can be used to identify maximum
memory that can be assigned to the guest.
On 09/07/2015 11:48, Laurent Vivier wrote:
On 09/07/2015 09:49, Thomas Huth wrote:
The option for supporting cross-endianness legacy guests in
the vhost and tun code should only be available on systems
that support cross-endian guests.
I'm sure I misunderstand something, but what
On 09/07/2015 11:48, Laurent Vivier wrote:
On 09/07/2015 09:49, Thomas Huth wrote:
The option for supporting cross-endianness legacy guests in
the vhost and tun code should only be available on systems
that support cross-endian guests.
I'm sure I misunderstand something, but what
On 09/07/2015 10:26, Laszlo Ersek wrote:
Perhaps KVM could simply hide memory above the limit (i.e. treat it as
MMIO), and the BIOS could remove RAM above the limit from the e820
memory map?
I'd prefer to leave the guest firmware*s* out of this... :)
E820 is a legacy BIOS concept.
On Thu, Jul 09, 2015 at 02:57:33PM +0200, Paolo Bonzini wrote:
On 09/07/2015 11:48, Laurent Vivier wrote:
On 09/07/2015 09:49, Thomas Huth wrote:
The option for supporting cross-endianness legacy guests in
the vhost and tun code should only be available on systems
that support
Contrary to other GICv3 interrupts, LPIs do not have an active state
by virtue of being edge-triggered only (they only have a pending state).
Given this, there is no point trying to deactivate them, and we can
skip the ICC_DIR_EL1 entierely.
Signed-off-by: Marc Zyngier marc.zyng...@arm.com
---
So far, GICv2 has been used in with EOImode == 0. The effect of this
mode is to perform the priority drop and the deactivation of the
interrupt at the same time.
While this works perfectly for Linux (we only have a single priority),
it causes issues when an interrupt is forwarded to a guest, and
Commit 0a4377de3056 (genirq: Introduce irq_set_vcpu_affinity() to
target an interrupt to a VCPU) added just what we needed at the
lowest level to allow an interrupt to be deactivated by a guest.
When such a request reaches the GIC, it knows it doesn't need to
perform the deactivation anymore, and
Commit 0a4377de3056 (genirq: Introduce irq_set_vcpu_affinity() to
target an interrupt to a VCPU) added just what we needed at the
lowest level to allow an interrupt to be deactivated by a guest.
When such a request reaches the GIC, it knows it doesn't need to
perform the deactivation anymore, and
When used as a primary interrupt controller, the GIC driver uses
irq_data-chip_data to extract controller-specific information.
When used as a secondary interrupt controller, it uses handler_data
instead. As this difference is relatively pointless and only creates
confusion, change the secondary
So far, GICv3 has been used in with EOImode == 0. The effect of this
mode is to perform the priority drop and the deactivation of the
interrupt at the same time.
While this works perfectly for Linux (we only have a single priority),
it causes issues when an interrupt is forwarded to a guest, and
Hello!
I'd like to distinguish between the 'missing vgic' and 'something bad
happened when trying to initialize the vgic' cases, which I don't think
we do currently, because the ENXIO code is used in various situations.
It is done. Check, for example, vgic_v2_probe(). -ENXIO is returned
Paolo Bonzini pbonz...@redhat.com writes:
On 09/07/2015 10:26, Laszlo Ersek wrote:
Perhaps KVM could simply hide memory above the limit (i.e. treat it as
MMIO), and the BIOS could remove RAM above the limit from the e820
memory map?
I'd prefer to leave the guest firmware*s* out of
1 - 100 of 108 matches
Mail list logo
