On Sun, 2025-03-30 at 09:42 -0400, Michael S. Tsirkin wrote:
> On Fri, Mar 28, 2025 at 05:40:41PM +0000, David Woodhouse wrote:
> > On Fri, 2025-03-21 at 18:42 +0000, David Woodhouse wrote:
> > > >
> > > > I don't mind as such (though I don't unders
On Tue, 2021-02-09 at 14:21 +0800, Claire Chang wrote:
> This series implements mitigations for lack of DMA access control on
> systems without an IOMMU, which could result in the DMA accessing the
> system memory at unexpected times and/or unexpected addresses, possibly
> leading to data leakage o
On Sun, 2025-03-30 at 17:48 -0400, Michael S. Tsirkin wrote:
> On Sun, Mar 30, 2025 at 10:27:58PM +0100, David Woodhouse wrote:
> > On 30 March 2025 18:06:47 BST, "Michael S. Tsirkin" wrote:
> > > > It's basically just allowing us to expose through PCI, what
On 30 March 2025 18:06:47 BST, "Michael S. Tsirkin" wrote:
>> It's basically just allowing us to expose through PCI, what I believe
>> we can already do for virtio in DT.
>
>I am not saying I am against this extension.
>The idea to restrict DMA has a lot of merit outside pkvm.
>For example, with a
On 30 March 2025 17:59:13 BST, "Michael S. Tsirkin" wrote:
>On Sun, Mar 30, 2025 at 04:07:56PM +0100, David Woodhouse wrote:
>> On Sun, 2025-03-30 at 09:42 -0400, Michael S. Tsirkin wrote:
>> > On Fri, Mar 28, 2025 at 05:40:41PM +, David Woodhouse wrote:
>&g
On Fri, 2025-03-21 at 18:42 +, David Woodhouse wrote:
> On Fri, 2025-03-21 at 14:32 -0400, Michael S. Tsirkin wrote:
> > On Fri, Mar 21, 2025 at 03:38:10PM +0000, David Woodhouse wrote:
> > > On Tue, 2021-02-09 at 14:21 +0800, Claire Chang wrote:
> > > > This ser
On Fri, 2025-03-21 at 14:32 -0400, Michael S. Tsirkin wrote:
> On Fri, Mar 21, 2025 at 03:38:10PM +0000, David Woodhouse wrote:
> > On Tue, 2021-02-09 at 14:21 +0800, Claire Chang wrote:
> > > This series implements mitigations for lack of DMA access control on
> > &g
On Fri, 2025-02-14 at 12:34 +0100, Thomas Gleixner wrote:
> > 2. In kernel, asking KVM to populate the vmclock structure much like
> > it does other pvclocks shared with the guest. KVM/x86 already uses
> > pvclock_gtod_register_notifier() to hook changes; should we expand
> > on that?
On Thu, 2025-02-06 at 11:59 +0100, Thomas Weißschuh wrote:
> On Thu, Feb 06, 2025 at 09:31:42AM +0000, David Woodhouse wrote:
> > On Tue, 2025-02-04 at 13:05 +0100, Thomas Weißschuh wrote:
> > > Currently each architecture defines the setup of the vDSO data page on
> > &
On Tue, 2025-02-04 at 13:05 +0100, Thomas Weißschuh wrote:
> Currently each architecture defines the setup of the vDSO data page on
> its own, mostly through copy-and-paste from some other architecture.
> Extend the existing generic vDSO implementation to also provide generic
> data storage.
> This
On Fri, 2025-01-03 at 09:53 +0100, Geert Uytterhoeven wrote:
>
> > The following points are also in the list of reasons:
> > - This driver has a maximum 54MBit/s as it supports only 802.11 b/g.
> > - Using this hardware is security wise not state of the art as WPA3 is
> > not supported.
>
> I
From: David Woodhouse
The xencons_connect_backend() function allocates a local interdomain
event channel with xenbus_alloc_evtchn(), then calls
bind_interdomain_evtchn_to_irq_lateeoi() to bind to that port# on the
*remote* domain.
That doesn't work very well:
(qemu) device_add xen-conso
From: David Woodhouse
On unplug of a Xen console, xencons_disconnect_backend() unconditionally
calls free_irq() via unbind_from_irqhandler(), causing a warning of
freeing an already-free IRQ:
(qemu) device_del con1
[ 32.050919] [ cut here ]
[ 32.050942] Trying to
y with its SMEP behaviour...
David Woodhouse (3):
hvc/xen: fix event channel handling for secondary consoles
hvc/xen: fix error path in xen_hvc_init() to always register frontend
driver
hvc/xen: fix console unplug
drivers/tty/hvc/hvc_xen.c | 39
From: David Woodhouse
The xen_hvc_init() function should always register the frontend driver,
even when there's no primary console — as there may be secondary consoles.
(Qemu can always add secondary consoles, but only the toolstack can add
the primary because it's special.)
Sig
On Fri, 2023-10-20 at 10:51 +0200, Juergen Gross wrote:
>
> > (qemu) device_del con1
> > [ 32.050919] [ cut here ]
> > [ 32.050942] Trying to free already-free IRQ 33
> > [ 32.050990] WARNING: CPU: 0 PID: 51 at kernel/irq/manage.c:1895
> > __free_irq+0x1d4/0x330
> >
From: David Woodhouse
The xencons_connect_backend() function allocates a local interdomain
event channel with xenbus_alloc_evtchn(), then calls
bind_interdomain_evtchn_to_irq_lateeoi() to bind to that port# on the
*remote* domain.
That doesn't work very well:
(qemu) device_add xen-conso
Failed to enable and set the admin interrupts
Side note: This is the first bug found, and first patch tested, by running
Xen guests under QEMU/KVM instead of running under actual Xen.
Fixes: 99f3d2797657 ("PCI/MSI: Reject MSI-X early")
Signed-off-by: David Woodhouse
---
arch/x86/pci/
On Fri, 2021-12-10 at 15:53 +0100, Paolo Bonzini wrote:
> On 12/10/21 13:25, David Woodhouse wrote:
> > On Thu, 2021-12-09 at 23:34 +0100, Paolo Bonzini wrote:
> > > Compared to the review it's missing this hunk:
> > >
> > > @@ -265,7 +265,7 @@ void k
On Thu, 2021-12-09 at 23:34 +0100, Paolo Bonzini wrote:
>
> Compared to the review it's missing this hunk:
>
> @@ -265,7 +265,7 @@ void kvm_gfn_to_pfn_cache_unmap(struct kvm *kvm, struct
> gfn_to_pfn_cache *gpc)
>
> gpc->valid = false;
>
> - old_khva = gpc->khva;
> + old
On Thu, 2021-12-09 at 23:34 +0100, Paolo Bonzini wrote:
> Compared to the review it's missing this hunk:
>
> @@ -265,7 +265,7 @@ void kvm_gfn_to_pfn_cache_unmap(struct kvm *kvm, struct
> gfn_to_pfn_cache *gpc)
>
> gpc->valid = false;
>
> - old_khva = gpc->khva;
> + old_khva
On Thu, 2021-12-09 at 19:34 +0100, Paolo Bonzini wrote:
> Sorry for the late review...
NP, very useful fixes. Thanks. Incremental patch looks like this. It
passes the xen_shinfo_test self-test; will test it with real Xen guests
tomorrow and repost based on your kvm/next tree once it shows up.
di
On Thu, 2021-12-09 at 19:34 +0100, Paolo Bonzini wrote:
> > As in the previous two rounds, the last patch (this time patch 12) is
> > included as illustration of how we*might* use this for fixing the UAF
> > bugs in nesting, but isn't intended to be applied as-is. Patches 1-11 are.
>
> Queued 1-7
On Tue, 2021-11-23 at 14:42 +0530, Anup Patel wrote:
> On Sun, Nov 21, 2021 at 6:25 PM David Woodhouse wrote:
>
> > From: David Woodhouse
> > Signed-off-by: David Woodhouse
>
> Looks good to me.
>
> For KVM RISC-V,
>
> Acked-by: Anup Patel
> Reviewed
From: David Woodhouse
This adds basic support for delivering 2 level event channels to a guest.
Initially, it only supports delivery via the IRQ routing table, triggered
by an eventfd. In order to do so, it has a kvm_xen_set_evtchn_fast()
function which will use the pre-mapped shared_info page
From: David Woodhouse
This is what evolved during the discussion at
https://lore.kernel.org/kvm/960e233f-ec0b-4fb5-ba2e-c8d2ccb38...@infradead.org/T/#m11d75fcfe2da357ec1dabba0d0e3abb91fd13665
As discussed, an alternative approach might be to augment
kvm_arch_memslots_updated() to raise
From: David Woodhouse
It's all fairly baroque but in the end, I don't think there's any reason
for $(KVM)/irqchip.o to have been handled differently, as they all end
up in $(kvm-y) in the end anyway, regardless of whether they get there
via $(common-objs-y) and the CPU-specif
From: David Woodhouse
Splitting kvm_main.c out into smaller and better-organized files is
slightly non-trivial when it involves editing a bunch of per-arch
KVM makefiles. Provide virt/kvm/Makefile.kvm for them to include.
Signed-off-by: David Woodhouse
Acked-by: Marc Zyngier
---
arch/x86/kvm
too.
Include the fix for the dirty ring vs. Xen shinfo oops reported
by butt3rflyh4ck .
As in the previous two rounds, the last patch (this time patch 12) is
included as illustration of how we *might* use this for fixing the UAF
bugs in nesting, but isn't intended to be applied as-
From: David Woodhouse
When dirty ring logging is enabled, any dirty logging without an active
vCPU context will cause a kernel oops. But we've already declared that
the shared_info page doesn't get dirty tracking anyway, since it would
be kind of insane to mark it dirty every time we
From: David Woodhouse
Use the newly reinstated gfn_to_pfn_cache to maintain a kernel mapping
of the Xen shared_info page so that it can be accessed in atomic context.
Note that we do not participate in dirty tracking for the shared info
page and we do not explicitly mark it dirty every single
From: David Woodhouse
I'd like to make the build include dirty_ring.c based on whether the
arch wants it or not. That's a whole lot simpler if there's a config
symbol instead of doing it implicitly on KVM_DIRTY_LOG_PAGE_OFFSET
being set to something non-zero.
Signed-off-by:
From: David Woodhouse
Signed-off-by: David Woodhouse
---
arch/mips/kvm/Makefile | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/mips/kvm/Makefile b/arch/mips/kvm/Makefile
index d3710959da55..21ff75bcdbc4 100644
--- a/arch/mips/kvm/Makefile
+++ b/arch/mips/kvm
From: David Woodhouse
Signed-off-by: David Woodhouse
---
arch/riscv/kvm/Makefile | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/arch/riscv/kvm/Makefile b/arch/riscv/kvm/Makefile
index 30cdd1df0098..300590225348 100644
--- a/arch/riscv/kvm/Makefile
+++ b/arch/riscv/kvm
From: David Woodhouse
Signed-off-by: David Woodhouse
Acked-by: Marc Zyngier
---
arch/arm64/kvm/Makefile | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/kvm/Makefile b/arch/arm64/kvm/Makefile
index 989bb5dad2c8..04a53f71a6b6 100644
--- a/arch/arm64/kvm
From: David Woodhouse
This can be used in two modes. There is an atomic mode where the cached
mapping is accessed while holding the rwlock, and a mode where the
physical address is used by a vCPU in guest mode.
For the latter case, an invalidation will wake the vCPU with the new
From: David Woodhouse
Signed-off-by: David Woodhouse
Reviewed-by: Christian Borntraeger
---
arch/s390/kvm/Makefile | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/s390/kvm/Makefile b/arch/s390/kvm/Makefile
index b3aaadc60ead..e4f50453cf7f 100644
--- a/arch/s390
From: David Woodhouse
When dirty ring logging is enabled, any dirty logging without an active
vCPU context will cause a kernel oops. But we've already declared that
the shared_info page doesn't get dirty tracking anyway, since it would
be kind of insane to mark it dirty every time we
On Sat, 2021-11-20 at 18:30 +0200, Mika Penttilä wrote:
>
> On 20.11.2021 18.21, David Woodhouse wrote:
> > On Sat, 2021-11-20 at 17:48 +0200, Mika Penttilä wrote:
> > > > @@ -9785,6 +9787,14 @@ static int vcpu_enter_guest(struct kvm_vcpu
> > > > *vcp
On Sat, 2021-11-20 at 17:48 +0200, Mika Penttilä wrote:
> > @@ -9785,6 +9787,14 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu)
> >local_irq_disable();
> >vcpu->mode = IN_GUEST_MODE;
> >
> > + /*
> > + * If the guest requires direct access to mapped L1 pages, chec
From: David Woodhouse
Splitting kvm_main.c out into smaller and better-organized files is
slightly non-trivial when it involves editing a bunch of per-arch
KVM makefiles. Provide virt/kvm/Makefile.kvm for them to include.
Signed-off-by: David Woodhouse
Acked-by: Marc Zyngier
---
arch/x86/kvm
Event channels, yeah. That really is where I started.
It was all so simple in Joao and Ankur's original version at
https://www.spinics.net/lists/kvm/msg182556.html — just a handful
of simple test_and_set_bit() calls on the mapped page.
When I posted v1 I didn't quite understand how steal time an
From: David Woodhouse
Signed-off-by: David Woodhouse
---
arch/riscv/kvm/Makefile | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/arch/riscv/kvm/Makefile b/arch/riscv/kvm/Makefile
index 30cdd1df0098..300590225348 100644
--- a/arch/riscv/kvm/Makefile
+++ b/arch/riscv/kvm
From: David Woodhouse
Use the newly reinstated gfn_to_pfn_cache to maintain a kernel mapping
of the Xen shared_info page so that it can be accessed in atomic context.
Note that we do not participate in dirty tracking for the shared info
page and we do not explicitly mark it dirty every single
From: David Woodhouse
This adds basic support for delivering 2 level event channels to a guest.
Initially, it only supports delivery via the IRQ routing table, triggered
by an eventfd. In order to do so, it has a kvm_xen_set_evtchn_fast()
function which will use the pre-mapped shared_info page
From: David Woodhouse
This is what evolved during the discussion at
https://lore.kernel.org/kvm/960e233f-ec0b-4fb5-ba2e-c8d2ccb38...@infradead.org/T/#m11d75fcfe2da357ec1dabba0d0e3abb91fd13665
As discussed, an alternative approach might be to augment
kvm_arch_memslots_updated() to raise
From: David Woodhouse
Signed-off-by: David Woodhouse
---
arch/mips/kvm/Makefile | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/mips/kvm/Makefile b/arch/mips/kvm/Makefile
index d3710959da55..21ff75bcdbc4 100644
--- a/arch/mips/kvm/Makefile
+++ b/arch/mips/kvm
From: David Woodhouse
It's all fairly baroque but in the end, I don't think there's any reason
for $(KVM)/irqchip.o to have been handled differently, as they all end
up in $(kvm-y) in the end anyway, regardless of whether they get there
via $(common-objs-y) and the CPU-specif
From: David Woodhouse
I'd like to make the build include dirty_ring.c based on whether the
arch wants it or not. That's a whole lot simpler if there's a config
symbol instead of doing it implicitly on KVM_DIRTY_LOG_PAGE_OFFSET
being set to something non-zero.
Signed-off-by:
From: David Woodhouse
Signed-off-by: David Woodhouse
Reviewed-by: Christian Borntraeger
---
arch/s390/kvm/Makefile | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/s390/kvm/Makefile b/arch/s390/kvm/Makefile
index b3aaadc60ead..e4f50453cf7f 100644
--- a/arch/s390
From: David Woodhouse
This can be used in two modes. There is an atomic mode where the cached
mapping is accessed while holding the rwlock, and a mode where the
physical address is used by a vCPU in guest mode.
For the latter case, an invalidation will wake the vCPU with the new
From: David Woodhouse
Signed-off-by: David Woodhouse
Acked-by: Marc Zyngier
---
arch/arm64/kvm/Makefile | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/kvm/Makefile b/arch/arm64/kvm/Makefile
index 989bb5dad2c8..04a53f71a6b6 100644
--- a/arch/arm64/kvm
On Thu, 2021-11-18 at 19:46 +, Sean Christopherson wrote:
> It is sufficient for the current physical CPU to have an active vCPU, which is
> generally guaranteed in the MMU code because, with a few exceptions,
> populating
> SPTEs is done in vCPU context.
>
> mmap() will never directly trigge
On 18 November 2021 18:50:55 GMT, Sean Christopherson wrote:
>On Thu, Nov 18, 2021, Sean Christopherson wrote:
>> On Thu, Nov 18, 2021, David Woodhouse wrote:
>> > That leaves the one in TDP MMU handle_changed_spte_dirty_log() which
>> > AFAICT can trigger the same
On Thu, 2021-11-18 at 13:04 +0100, Paolo Bonzini wrote:
> On 11/17/21 22:09, David Woodhouse wrote:
> > > {
> > > - struct kvm_vcpu *vcpu = kvm_get_running_vcpu();
> > > + struct kvm_vcpu *running_vcpu = kvm_get_running_vcpu();
> > >
> >
> From: David Woodhouse
>
> The kvm_dirty_ring_get() function uses kvm_get_running_vcpu() to work out
> which dirty ring to use, but there are some use cases where that doesn't
> work.
>
> There's one in setting the Xen shared info page, introduced in commi
On Wed, 2021-11-17 at 18:13 +, Marc Zyngier wrote:
> What's the base for this series? This patch fails to compile for me
> (at least on arm64), and the following patch doesn't apply on -rc1.
It's on top of kvm/master, and it's also at
https://git.infradead.org/users/dwmw2/linux.git/shortlog/re
On 17 November 2021 18:13:37 GMT, Marc Zyngier wrote:
>On Wed, 17 Nov 2021 17:39:59 +,
>David Woodhouse wrote:
>>
>> From: David Woodhouse
>>
>> The kvm_dirty_ring_get() function uses kvm_get_running_vcpu() to work out
>> which dirty ring to use, but
From: David Woodhouse
This adds basic support for delivering 2 level event channels to a guest.
Initially, it only supports delivery via the IRQ routing table, triggered
by an eventfd. In order to do so, it has a kvm_xen_set_evtchn_fast()
function which will use the pre-mapped shared_info page
From: David Woodhouse
This can be used in two modes. There is an atomic mode where the cached
mapping is accessed while holding the rwlock, and a mode where the
physical address is used by a vCPU in guest mode.
For the latter case, an invalidation will wake the vCPU with the new
ted proof of concept attempt at
fixing one such.
Since adding a C file in virt/kvm/ was somewhat more painful than it
really should have been, there is a small detour into all the arch
specific Makefiles to make them include a common one.
Intended for merging up to patch 11. Patch 12 is for
From: David Woodhouse
Signed-off-by: David Woodhouse
---
arch/arm64/kvm/Makefile | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/kvm/Makefile b/arch/arm64/kvm/Makefile
index 989bb5dad2c8..04a53f71a6b6 100644
--- a/arch/arm64/kvm/Makefile
+++ b/arch/arm64
From: David Woodhouse
Signed-off-by: David Woodhouse
---
arch/mips/kvm/Makefile | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/mips/kvm/Makefile b/arch/mips/kvm/Makefile
index d3710959da55..21ff75bcdbc4 100644
--- a/arch/mips/kvm/Makefile
+++ b/arch/mips/kvm
From: David Woodhouse
The kvm_dirty_ring_get() function uses kvm_get_running_vcpu() to work out
which dirty ring to use, but there are some use cases where that doesn't
work.
There's one in setting the Xen shared info page, introduced in commit
629b5348841a ("KVM: x86/xen: u
From: David Woodhouse
Signed-off-by: David Woodhouse
Reviewed-by: Christian Borntraeger
---
arch/s390/kvm/Makefile | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/s390/kvm/Makefile b/arch/s390/kvm/Makefile
index b3aaadc60ead..e4f50453cf7f 100644
--- a/arch/s390
From: David Woodhouse
Splitting kvm_main.c out into smaller and better-organized files is
slightly non-trivial when it involves editing a bunch of per-arch
KVM makefiles. Provide virt/kvm/Makefile.kvm for them to include.
Signed-off-by: David Woodhouse
---
arch/x86/kvm/Makefile | 7
From: David Woodhouse
It's all fairly baroque but in the end, I don't think there's any reason
for $(KVM)/irqchip.o to have been handled differently, as they all end
up in $(kvm-y) in the end anyway, regardless of whether they get there
via $(common-objs-y) and the CPU-specif
From: David Woodhouse
This is what evolved during the discussion at
https://lore.kernel.org/kvm/960e233f-ec0b-4fb5-ba2e-c8d2ccb38...@infradead.org/T/#m11d75fcfe2da357ec1dabba0d0e3abb91fd13665
As discussed, an alternative approach might be to augment
kvm_arch_memslots_updated() to raise
From: David Woodhouse
Signed-off-by: David Woodhouse
---
arch/riscv/kvm/Makefile | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/arch/riscv/kvm/Makefile b/arch/riscv/kvm/Makefile
index 30cdd1df0098..300590225348 100644
--- a/arch/riscv/kvm/Makefile
+++ b/arch/riscv/kvm
From: David Woodhouse
I'd like to make the build include dirty_ring.c based on whether the
arch wants it or not. That's a whole lot simpler if there's a config
symbol instead of doing it implicitly on KVM_DIRTY_LOG_PAGE_OFFSET
being set to something non-zero.
Signed-off-by:
From: David Woodhouse
Use the newly reinstated gfn_to_pfn_cache to maintain a kernel mapping
of the Xen shared_info page so that it can be accessed in atomic context.
Signed-off-by: David Woodhouse
---
arch/x86/include/asm/kvm_host.h | 2 +-
arch/x86/kvm/xen.c | 25
On Tue, 2021-11-16 at 18:43 +, Sean Christopherson wrote:
> On Tue, Nov 16, 2021, David Woodhouse wrote:
> > From: David Woodhouse
> >
> > It's all fairly baroque but in the end, I don't think there's any reason
> > for $(KVM)/irqchip.o to have
From: David Woodhouse
Signed-off-by: David Woodhouse
---
arch/mips/kvm/Makefile | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/mips/kvm/Makefile b/arch/mips/kvm/Makefile
index d3710959da55..21ff75bcdbc4 100644
--- a/arch/mips/kvm/Makefile
+++ b/arch/mips/kvm
From: David Woodhouse
Signed-off-by: David Woodhouse
---
arch/riscv/kvm/Makefile | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/arch/riscv/kvm/Makefile b/arch/riscv/kvm/Makefile
index 30cdd1df0098..300590225348 100644
--- a/arch/riscv/kvm/Makefile
+++ b/arch/riscv/kvm
From: David Woodhouse
Signed-off-by: David Woodhouse
---
arch/s390/kvm/Makefile | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/s390/kvm/Makefile b/arch/s390/kvm/Makefile
index b3aaadc60ead..e4f50453cf7f 100644
--- a/arch/s390/kvm/Makefile
+++ b/arch/s390/kvm
From: David Woodhouse
Signed-off-by: David Woodhouse
---
arch/arm64/kvm/Makefile | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/kvm/Makefile b/arch/arm64/kvm/Makefile
index 989bb5dad2c8..04a53f71a6b6 100644
--- a/arch/arm64/kvm/Makefile
+++ b/arch/arm64
From: David Woodhouse
Splitting kvm_main.c out into smaller and better-organized files is
slightly non-trivial when it involves editing a bunch of per-arch
KVM makefiles. Provide virt/kvm/Makefile.kvm for them to include.
Signed-off-by: David Woodhouse
---
arch/x86/kvm/Makefile | 7
From: David Woodhouse
It's all fairly baroque but in the end, I don't think there's any reason
for $(KVM)/irqchip.o to have been handled differently, as they all end
up in $(kvm-y) in the end anyway, regardless of whether they get there
via $(common-objs-y) and the CPU-specif
From: David Woodhouse
I'd like to make the build include dirty_ring.c based on whether the
arch wants it or not. That's a whole lot simpler if there's a config
symbol instead of doing it implicitly on KVM_DIRTY_LOG_PAGE_OFFSET
being set to something non-zero.
Signed-off-by:
non-static?
>
> Yes, I think sooner or later we also want all pfn stuff in one file
> (together with MMU notifiers) and all hva stuff in another; so for now
> you can create virt/kvm/hva_to_pfn.h, or virt/kvm/mm.h, or whatever
> color of the bikeshed you prefer.
OK... let
On Mon, 2018-08-20 at 23:14 -0700, Christoph Hellwig wrote:
> On Fri, Aug 17, 2018 at 12:26:30PM +0200, Arnd Bergmann wrote:
> > Hi Bjorn and others,
> >
> > Triggered by Christoph's patches, I had another go at converting
> > all of the remaining pci host bridge implementations to be based
> > on
Commit f719582435 ("PCI: Add pci_mmap_resource_range() and use it for
ARM64") added this generic function with the intent of using it
everywhere and ultimately killing the old arch-specific implementations.
Let's get on with that eradication...
Signed-off-by: David Woodhouse
--
On Wed, 2015-08-12 at 09:05 +0200, Christoph Hellwig wrote:
> Just remove a BUG_ON, the code handles them just fine as-is.
>
> Signed-off-by: Christoph Hellwig
Acked-by: David Woodhouse
--
David WoodhouseOpen Source Technology Centre
david.woodho...@
is just written in C, and the
compiler evidently trusts itself not to optimise that into a recursive
call. Is there a compiler switch which guarantees that, which we could
use without other unwanted side-effects?
--
David WoodhouseOpen Source Technology Centre
davi
On Mon, 2013-05-13 at 11:33 +0100, David Woodhouse wrote:
>
> On Mon, 2013-05-13 at 09:33 +0200, Gabriel Paubert wrote:
> > Actually, I'd swap the two mr instructions to never
> > have an instruction that uses the result from the
> > previous one.
>
> Bad GCC
iel Paubert wrote:
> Actually, I'd swap the two mr instructions to never
> have an instruction that uses the result from the
> previous one.
Bad GCC. No biscuit.
Should we file a PR?
--
David WoodhouseOpen Source Technology Centre
david.woodho...@inte
esting, but Al saw it on a Debian system.
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
smime.p7s
Description: S/MIME cryptographic signature
___
From: David Woodhouse
Some versions of GCC apparently expect this to be provided by libgcc.
Signed-off-by: David Woodhouse
---
Untested.
diff --git a/arch/powerpc/kernel/misc_32.S b/arch/powerpc/kernel/misc_32.S
index 19e096b..f077dc2 100644
--- a/arch/powerpc/kernel/misc_32.S
+++ b/arch
round.
Compiled-tested only. It gave a code size reduction of almost 4% for
ext2, and more like 2.5% for ext3/ext4.
Signed-off-by: David Woodhouse
Acked-by: H. Peter Anvin
---
arch/powerpc/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 95
On Tue, 2012-12-04 at 22:02 +1100, Stephen Rothwell wrote:
> > +config ARCH_USE_BUILTIN_BSWAP
> > + def_bool y
> > +
>
> This should be defined as bool in arch/Kconfig (probably in the previous
> patch) and then selected from appropriate architectures.
Thanks. Updated series at
git://git.
From: David Woodhouse
By using the compiler intrinsics instead of hand-crafted opaque inline
assembler for byte-swapping, we let the compiler see what's actually
happening and it gets to use lwbrx/stwbrx instructions instead of a
normal load/store coupled with a sequence of rlwimi instruc
From: David Woodhouse
Currently depends only on CONFIG_MATOM. This will change because big-core
CPUs are getting movbe too...
Signed-off-by: David Woodhouse
---
arch/x86/Kconfig.cpu | 4
arch/x86/Makefile| 1 +
2 files changed, 5 insertions(+)
diff --git a/arch/x86/Kconfig.cpu b
From: David Woodhouse
Since GCC 4.4, there have been __builtin_bswap32() and __builtin_bswap16()
intrinsics. A __builtin_bswap16() came a little later (4.6 for PowerPC,
48 for other platforms).
By using these instead of the inline assembler that most architectures
have in their __arch_swabXX
This series of patches enables the __builtin_bswapXX() series of functions
that have been supported since GCC 4.4. It allows GCC to emit load-and-swap
or store-and-swap instructions on architectures which support that.
--
David WoodhouseOpen Source Technology Centre
From: David Woodhouse
With -mmovbe enabled (implicit with -march=atom), this allows the
compiler to use the movbe instruction. This doesn't have a significant
effect on code size (unlike on PowerPC), because the movbe instruction
actually takes as many bytes to encode as a simple mov and a
On Tue, 2011-11-15 at 14:42 +, Jenkins, Clive wrote:
> This may be your (not so humble :-) opinion, and I happen to agree that
> a tab setting of 8 is best, usually. However, as Linus says in his
> coding style document "Coding style is very personal, and I won't _force_
> my views on anybody".
On Tue, 2011-11-15 at 11:26 +, Jenkins, Clive wrote:
> > fix whitespaces,tabs coding style issue and ...
>
> In my opinion this code was already correct, and would display correctly
> at any TAB setting. This patch changes it so that it displays
> incorrectly at all TAB settings other than 8.
On Mon, 2010-10-18 at 17:46 +0800, tiejun.chen wrote:
>
> >>> Looks you always iounmap(fsl_lbc_ctrl_dev->regs) on position 'err' but
> >>> here
> >>> of_iomap() is already failed you should skip iounmap()
> >>> fsl_lbc_ctrl_dev->regs
> >>> again. So you should improve that as the following on 'e
On Fri, 2009-08-21 at 09:58 -0700, geoffrey.lev...@am.sony.com wrote:
> The feature of "Install Other OS" was removed from the new
> "Slim" PS3 model to focus on delivering games and other
> entertainment content.
>
> Please be assured that SCE is committed to continue
> the support for previousl
can just drop the patch from the Fedora kernel and we can wait for
> either silence or bug reports :)
I'll dig out the machine and test. Some time next month would be the
current estimate.
--
David WoodhouseOpen Source Technology Centre
david.woodh
1 - 100 of 204 matches
Mail list logo
