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 c
[ 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 sn
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
---
arch/arm/kvm/Kconfig | 1 +
arch/arm64/kvm/Kconfig | 1 +
arch/powerpc/kvm/Kconfig | 1 +
drivers/net/Kcon
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 t
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
>> w
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 ext
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
---
virt/kvm/irqchip.c | 10 +-
1
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 req
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
--
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 a
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
---
PATCH: creation
---
virt/kvm/arm/vgic.c | 21
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
---
v1 -> v2:
replace msi_msg field by a struct composed of msi_msg and devid
RFC -> PATCH:
- reword the commit message after change in firs
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
---
v1 -> v2:
- introduce vgic_v2m_inject_msi in vgic-v2-emul.c following Andre's
adv
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 irq
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. Thi
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 th
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 ++-
tcg/mips/tcg
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 7a52ce8a1
On Thu, 09 Jul 2015 09:02:38 +0200
Laszlo Ersek 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
> > what
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(Curr
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 p
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.
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 kerne
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 Curr
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
Acked-by: Christoffer Dall
--
To unsubscribe
On 07/09/15 11:27, Igor Mammedov wrote:
> On Thu, 09 Jul 2015 09:02:38 +0200
> Laszlo Ersek 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, th
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_ke
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;
> >> +}
> >
> >
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 wrote:
> > On 08/07/15 17:06, Peter Maydell wrote:
> >> I'd prefer it if somebody could investigate to see why QEMU
> >> is ac
On 9 July 2015 at 11:22, Christoffer Dall 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 mechanism, since
>> by a
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 wrote:
>>> On 08/07/15 17:06, Peter Maydell wrote:
I'd prefer it
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
> ---
> arch/arm/kvm/arm.c | 19 ++-
> 1 file changed, 18 insertions(+),
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
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, Jul 09, 2015 at 11:38:40AM +0100, Peter Maydell wrote:
> On 9 July 2015 at 11:22, Christoffer Dall 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 proba
On 9 July 2015 at 13:05, Christoffer Dall 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
> VCPUs because they may have
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, M
On Thu, 9 Jul 2015 09:49:05 +0200
Thomas Huth 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
> ---
> arch/
On Thu, Jul 09, 2015 at 01:07:24PM +0100, Peter Maydell wrote:
> On 9 July 2015 at 13:05, Christoffer Dall 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 i
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 s
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 g
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 loc
On Wed, 08 Jul 2015 18:42:01 -0400
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
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 ha
On July 9, 2015 1:08:55 AM GMT+08:00, Will Deacon 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 arch_[iu]ninstall_hw_breakp
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
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 B
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
>
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
---
drivers/irqchip/irq-g
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 w
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 w
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, an
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, an
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
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 imp
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
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 w
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 k
On 9 July 2015 at 14:49, Paolo Bonzini 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 9 July 2015 at 12:52, Leon Alrae 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 paramete
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.
On 9 July 2015 at 14:58, Peter Maydell wrote:
> On 9 July 2015 at 14:49, Paolo Bonzini 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 master as buildfixes :-)
No, wait, I'm
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
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
> > wrote:
> > > As I understand it, the problem is that if we ever run a VCPU after
> > > reading the value, and write
On 9 July 2015 at 15:17, Christoffer Dall 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
>
> virtio_current_cpu_endian () at /root/src/qemu
On 09/07/15 14:59, Peter Maydell wrote:
> On 9 July 2015 at 12:52, Leon Alrae 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:
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. KVM_I
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 differ
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, u
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
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 e
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 n
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. v
On Thu, Jul 09, 2015 at 03:26:20PM +0100, Peter Maydell wrote:
> On 9 July 2015 at 15:17, Christoffer Dall 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 bac
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 extensi
> 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 ta
Paolo Bonzini 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
memor
On 07/09/15 20:32, Bandan Das wrote:
> Paolo Bonzini 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;
On Thu, 9 Jul 2015 16:07:47 +0300
"Michael S. Tsirkin" 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 leg
Laszlo Ersek 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 onl
Paolo Bonzini 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 this.
Igor Mammedov writes:
> On Wed, 08 Jul 2015 18:42:01 -0400
> 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
On 07/09/15 21:11, Bandan Das wrote:
> Laszlo Ersek 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 t
Laszlo Ersek 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 behavior if the gpa is out of range.
>
> I di
On 07/09/15 22:02, Bandan Das wrote:
> Laszlo Ersek 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
>>
On 2015-07-05 19:08, Mihai Donțu wrote:
> Allow a nested hypervisor to single step its guests.
>
> Signed-off-by: Mihai Donțu
>
> ---
>
> This patch applies on top of current linux-next.
> ---
> arch/x86/include/asm/vmx.h | 1 +
> arch/x86/include/uapi/asm/vmx.h | 2 ++
> arch/x86/kvm/v
On 07/09/2015 01:06 AM, Marc Zyngier wrote:
> 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
On Thu, 9 Jul 2015, Marc Zyngier wrote:
> 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 pointles
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 svm_compute_tsc_offset(stru
This patch adds the registration/unregistration of an
irq_bypass_producer for MSI/MSIx on vfio pci devices.
Signed-off-by: Feng Wu
---
drivers/vfio/pci/vfio_pci_intrs.c | 8 ++--
drivers/vfio/pci/vfio_pci_private.h | 2 ++
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/driv
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: Regist
Add reference to struct irq_bypass_produce so we can get the producer
information from the consumer side.
Signed-off-by: Feng Wu
---
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 3c0bd07..0c1de05 100644
-
Call update routine when updating irqfd, this can update the
IRTE for Intel posted-interrupts.
Signed-off-by: Feng Wu
---
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 100644
--- a/virt/kvm
This patch adds the routine to update IRTE for posted-interrupts
when guest changes the interrupt configuration.
Signed-off-by: Feng Wu
---
arch/x86/kvm/x86.c | 73 ++
1 file changed, 73 insertions(+)
diff --git a/arch/x86/kvm/x86.c b/arch/x86
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
---
arch/x86/kvm/Kconfig | 1 +
arch/x86/kvm/x86.c |
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
> ---
> virt/kvm/eventfd.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/virt/kvm/eventfd
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-b
Bandan Das writes:
> Laszlo Ersek 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 behavior
> -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
> S
platform_driver does not need to set an owner because
platform_driver_register() will set it.
Signed-off-by: Krzysztof Kozlowski
---
The coccinelle script which generated the patch was sent here:
http://www.spinics.net/lists/kernel/msg2029903.html
---
drivers/vfio/platform/vfio_platform.c | 1
100 matches
Mail list logo
