On Thu, 2008-03-27 at 10:26 +0100, Laurent Pinchart wrote:
> Ok. I'll submit a new patch as soon as we agree on a compatible name.
Did we?
--
dwmw2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
On Wed, 2008-04-23 at 00:16 +0400, Sergei Shtylyov wrote:
> David Woodhouse wrote:
>
> >>Ok. I'll submit a new patch as soon as we agree on a compatible name.
>
> > Did we?
>
> IIRC, The latest agreement was that we don't need the "compatible&quo
This hooks up the platform-specific [gs]et_rtc_time functions so that
kernels using CONFIG_RTC_CLASS have RTC support on most PowerPC
platforms.
Signed-off-by: David Woodhouse <[EMAIL PROTECTED]>
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 1e6715e..3e788b7 100644
--- a/d
On Thu, 2008-04-24 at 22:11 +1000, Paul Mackerras wrote:
> I have put the following patches in the powerpc.git repository on the
> master & powerpc-next branches (this includes some pulled from Kumar's
> tree). I plan to send a pull request to Linus tomorrow morning my
> time, so if there are any
On Sun, 2008-04-27 at 20:35 +0200, Christian Kujau wrote:
>
> /sys/devices/platform/pmu-battery.0/power_supply/PMU battery 0
> /sys/devices/platform/pmu-battery.0/power_supply/PMU battery 0/power
>
> Hm, OTOH /proc also does contain some elements with spaces in it (e.g.
> /proc/irq/47/GPIO1 ADB)
On Wed, 2008-05-07 at 12:27 +0200, Sascha Hauer wrote:
> memcpy_from/to_io() use word aligned accesses on the io side of memory.
> The MPC5200 local plus bus where our flashes are connected does not
> allow unaligned accesses, so we have to use the io versions of memcpy.
But this region of flash i
On Tue, 2008-07-15 at 20:05 +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2008-07-15 at 12:00 +0200, Gabriel Paubert wrote:
> > Hi,
> >
> > I just tried to boot 2.6.26 on a Pegasos and the kernel does not boot.
> > The last message I have is:
> > gunzip (0x <- some more hex digits
? Shouldn't the modifier come
first? What if we want to print a pointer immediately followed by a
capital S?
--
David WoodhouseOpen Source Technology Centre
[EMAIL PROTECTED] Intel Corporation
e much nicer. This looks good to me; I don't see
and reason why it can't be used across all architectures, off-hand.
--
David WoodhouseOpen Source Technology Centre
[EMAIL PROTECTED]
On Wed, 2008-08-13 at 11:27 +1000, Paul Mackerras wrote:
> The following series of patches implement support for a relocatable
> kernel by building it as a position-independent executable (PIE).
> When the linker is given the -pie flag, it creates an executable that
> contains dynamic relocations w
.isa_bridge_notify
c063a000 T _sinittext
c067c3bc T _einittext
c071fd80 d isa_bridge_notify
--
David WoodhouseOpen Source Technology Centre
[EMAIL PROTECTED] Intel Corporation
On Thu, 2008-08-28 at 15:23 +0100, David Woodhouse wrote:
> On Thu, 2008-08-28 at 00:38 +1000, Stephen Rothwell wrote:
> > Hi Arjan,
> >
> > On Thu, 28 Aug 2008 00:33:08 +1000 Stephen Rothwell <[EMAIL PROTECTED]>
> > wrote:
> > >
> > > The origi
design decision.
--
David WoodhouseOpen Source Technology Centre
[EMAIL PROTECTED] Intel Corporation
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
, along with $SUBJECT.
--
David WoodhouseOpen Source Technology Centre
[EMAIL PROTECTED] Intel Corporation
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
other lists so folks can jump in if they really care. Splitting it
> out doesn't help matters in the least, but unfortunately this is what
> seems to happen the most when subscribers only lists are involved.
Subscriber-only lists are broken. Just don't us
thing and cleanup the driver?
It would be possible, yes -- but it would be better to have the various
PPC platforms just register RTC-class devices _directly_, and ditch the
RTC bits from ppc_md altogether.
I think we're waiting until the RTC class works with NTP before we can
contempl
tuff to trigger at half-past the second could be kept as
a library function which most RTC devices would use, but they'd have the
option to use their own instead.
--
David WoodhouseOpen Source Technology Centre
[EMAIL PROTECTED]
On Wed, 2007-06-27 at 08:49 -0500, Josh Boyer wrote:
> + remain in bug-fix only mode until it's scheduled removal. Platforms
http://www.angryflower.com/itsits.gif
--
dwmw2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/
On Fri, 2007-06-29 at 10:13 -0500, Josh Boyer wrote:
> That's it? I'm scheduling the demise of an entire architecture
> sub-tree and the only comment you can make is about a superfluous
> apostrophe? ;)
Sorry, allow me to rephrase...
http://www.angryflower.com/itsits.gif
DIE arch/ppc DIE!
--
On Sat, 2007-06-30 at 17:58 +1000, Michael Ellerman wrote:
> On Fri, 2007-06-29 at 15:54 +0100, David Woodhouse wrote:
> > On Wed, 2007-06-27 at 08:49 -0500, Josh Boyer wrote:
> > > + remain in bug-fix only mode until it's scheduled removal.
> &
On Thu, 2007-07-05 at 16:55 -0500, Scott Wood wrote:
> To maintain compatibility with these versions, we could change the test
> in do_page_fault() to include VM_READ as well as VM_EXEC on targets that
> don't have a separate exec-bit in hardware (are there any powerpc mmus
> that do?).
64-bi
The MV64660 has reg-shift==2 for its otherwise 16550-compatible uarts.
While the bootwrapper copes with this, of_serial.c doesn't. (The udbg
code doesn't either, but I'll fix that later).
Signed-off-by: David Woodhouse <[EMAIL PROTECTED]>
diff --git a/drivers/serial/of_seri
On Sat, 2007-07-07 at 14:10 +0200, Arnd Bergmann wrote:
> On Saturday 07 July 2007, David Woodhouse wrote:
> >
> > The MV64660 has reg-shift==2 for its otherwise 16550-compatible uarts.
> > While the bootwrapper copes with this, of_serial.c doesn't. (The udbg
> > c
On Sat, 2007-07-07 at 14:10 +0200, Arnd Bergmann wrote:
> Given the existence of the boards, it looks correct to do this.
> However, I wonder if it was correct for the MV64660 to claim
> compatibily witn ns16550 if the programming model is not exactly
> the same. The official OF serial port binding
rated.
Also, reorder the match table to favour better modes if a device claims
compatibility with both 8250 and 16550, for example.
Signed-off-by: David Woodhouse <[EMAIL PROTECTED]>
diff --git a/drivers/serial/of_serial.c b/drivers/serial/of_serial.c
index 7ffdaea..6ae1b5e 100644
--- a/d
The bootwrapper already handles a 'reg-shift' property on serial ports
and does the right thing. However, these ports really shouldn't be
claiming to be compatible with 'ns16550'. Introduce a new 'sparse16550'
type for them instead.
Signed-off-by: David Woodhous
If you build a multiplatform kernel for iSeries and pSeries, with
ibmvscsic support, the resulting client doesn't work on iSeries.
This patch should fix that, using the appropriate low-level operations
for the machine detected at runtime.
Signed-off-by: David Woodhouse <[EMAIL P
On Thu, 2007-07-26 at 11:27 +1000, Michael Ellerman wrote:
> Nice that someone finally fixed this up.
>
> But I get:
>
> drivers/scsi/ibmvscsi/ibmvscsi.c:1651: error: 'FW_FEATURE_ISERIES' undeclared
> (first use in this function)
> drivers/scsi/ibmvscsi/ibmvscsi.c:1651: error: (Each undeclared i
If you build a multiplatform kernel for iSeries and pSeries, with
ibmvscsic support, the resulting client doesn't work on iSeries.
This patch should fix that, using the appropriate low-level operations
for the machine detected at runtime.
Signed-off-by: David Woodhouse <[EMAIL P
If you build a multiplatform kernel for iSeries and pSeries, with
ibmvscsic support, the resulting client doesn't work on iSeries.
This patch should fix that, using the appropriate low-level operations
for the machine detected at runtime.
Signed-off-by: David Woodhouse <[EMAIL P
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
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
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
---
arch/x86/kvm/Makefile | 7
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/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/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/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
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
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
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/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
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
---
arch/x86/kvm/Makefile | 7
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
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
---
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/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
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
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
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
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
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
> 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 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();
> > >
> >
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 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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/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
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.
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
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
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
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
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
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
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
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 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 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 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 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
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 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 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 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
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 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 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 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
101 - 200 of 204 matches
Mail list logo
