* Re: [PATCH v2 1/7] powerpc/85xx: re-enable timebase sync disabled by KEXEC patch
From: Scott Wood @ 2011-11-18 18:01 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Zhao Chenhui
In-Reply-To: <54122A43-37D1-438B-A0DD-289B7AE2BA0B@kernel.crashing.org>
On Fri, Nov 18, 2011 at 08:35:02AM -0600, Kumar Gala wrote:
>
> On Nov 16, 2011, at 12:42 PM, Scott Wood wrote:
>
> > On 11/16/2011 03:55 AM, Zhao Chenhui wrote:
> >> From: Li Yang <leoli@freescale.com>
> >>
> >> The timebase sync is not only necessary when using KEXEC. It should also
> >> be used by normal boot up and cpu hotplug. Remove the ifdef added by
> >> the KEXEC patch.
> >
> > Again, no it should not be used by normal boot up (whether KEXEC support
> > is enabled or not). We should only do timebase sync when we actually
> > need to (when we've actually just reset a core), and we should do it the
> > way U-Boot does rather than with smp-tbsync.c.
>
>
> How can we do u-boot bases timebase sync after the system us up and
> running? For example would we losing some ticks of time in the case
> that one core is up and we bring a second core online?
Yes, we'll lose a small handful of ticks relative to wall clock time --
but it'll be the same loss on all cores. It's better than possibly
having the timebase be imperfectly synchronized, and should complete more
quickly.
This is only during intrusive events such as kexec or deep sleep (we only
need to reset the core for jog on mpc8536 which has only one core).
During deep sleep all cores' timebases will be stopped. Kexec is
resetting the kernel; it's not going to care what the old timebase was,
and should resync from RTC.
Even if we end up using this for some future power management mode where
we take down some CPUs to the point their timebase stops, but never take
down others, the time loss should be negligible (for comparison, what's
the error tolerance on the crystal frequency?) and acceptable for what is
still a fairly intrusive and rare event.
-Scott
^ permalink raw reply
* Re: [PATCH 2/2] powerpc/85xx: p1022ds: enable monitor switching via pixis indirect mode
From: Scott Wood @ 2011-11-18 18:06 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, kumar.gala
In-Reply-To: <4EC68F14.9020206@freescale.com>
On Fri, Nov 18, 2011 at 11:00:04AM -0600, Timur Tabi wrote:
> Scott Wood wrote:
> >> > How do I update the device tree from platform code?
>
> > prom_update_property()
>
> I assume this needs to be called after the DT has been unflattened,
> since it takes a device_node* as a parameter. Is there any way I can
> modify the tree before it's unflattened? I'd like to fixup the tree in
> an early_param() function.
What's wrong with doing it in setup_arch()?
Modifying a flat device tree is a more complicated task, and the kernel's
code is read-only. It's not worth bringing libfdt or similar complexity
in for this, when there are other alternatives.
If it really needs to be done early, consider doing it from U-Boot. The
bootwrapper would be a decent place as well, but we probably shouldn't
require its use just for this.
-Scott
^ permalink raw reply
* Re: [PATCH 2/2] powerpc/85xx: p1022ds: enable monitor switching via pixis indirect mode
From: Timur Tabi @ 2011-11-18 18:08 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, kumar.gala
In-Reply-To: <20111118180651.GC28562@schlenkerla.am.freescale.net>
Scott Wood wrote:
> What's wrong with doing it in setup_arch()?
Well, I was hoping to encapsulate everything into one function -- the early_param() callback function. But I guess that's not going to work.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [RFC PATCH 0/11] KVM: PPC: Update Book3S HV memory handling
From: Paul Mackerras @ 2011-11-18 21:54 UTC (permalink / raw)
To: Alexander Graf
Cc: linuxppc-dev, Marcelo Tosatti, Avi Kivity, kvm-ppc, kvm list
In-Reply-To: <AA9CC080-B96B-41C7-A054-8286CF8BC3FE@suse.de>
On Fri, Nov 18, 2011 at 02:57:11PM +0100, Alexander Graf wrote:
>
> This touches areas that I'm sure non-PPC people would want to see as
> well. Could you please CC kvm@vger too next time?
>
> Avi, Marcelo, mind to review some of the bits in this patch set? :)
I did cc the last patch (the one that adds barriers in the MMU
notifier sequence/count logic) to kvm@vger. Do you mean I should cc
the whole series? The only other thing touching generic code is the
addition of the KVM_MEMSLOT_IO flag in the first patch.
I'm hoping the extra barriers will be OK since they are no-ops on
x86. In fact I now think that the smp_wmbs I added to
kvm_mmu_notifier_invalidate_page and kvm_mmu_notifier_change_pte
aren't in fact necessary, since it's only necessary to ensure that the
sequence number increase is visible before the point where
kvm_unmap_hva or kvm_set_spte_hva unlock the bitlock on the first rmap
chain they look at, which will be ensured anyway by the barrier before
the unlock.
Paul.
^ permalink raw reply
* Re: [PATCH 2/2] powerpc/85xx: p1022ds: enable monitor switching via pixis indirect mode
From: Stephen Rothwell @ 2011-11-19 1:04 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, kumar.gala
In-Reply-To: <4EC5860D.5000606@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 4094 bytes --]
Hi Timur,
On Thu, 17 Nov 2011 16:09:17 -0600 Timur Tabi <timur@freescale.com> wrote:
>
> Stephen Rothwell wrote:
>
> >> + struct device_node *indirect_node = NULL;
> >> + struct ccsr_guts_85xx __iomem *guts = NULL;
> >> + u8 __iomem *lbc_lcs0_ba = NULL;
> >> + u8 __iomem *lbc_lcs1_ba = NULL;
> >
> > And if you had multiple error path labels, you could avoid these others
> > as well (and the NULL checks on the error path).
>
> But I don't want multiple error path labels. The error path could only
> happen if someone passed in a broken device tree (i.e. pretty much
> never), so I'm not keen on complicating my code just to optimize
> something that will never be used.
But you are already optimizing for the error path by doing the
assignments and NULL checks that are unneeded in the non error path.
What I am suggesting is adding a little more code that could end up doing
less at run time.
How about (not even compile tested):
static void p1022ds_set_monitor_port(enum fsl_diu_monitor_port port)
{
struct device_node *guts_node;
struct device_node *indirect_node;
struct ccsr_guts_85xx __iomem *guts;
u8 __iomem *lbc_lcs0_ba;
u8 __iomem *lbc_lcs1_ba;
u8 b;
/* Map the global utilities registers. */
guts_node = of_find_compatible_node(NULL, NULL, "fsl,p1022-guts");
if (!guts_node) {
pr_err("p1022ds: missing global utilties device node\n");
return;
}
guts = of_iomap(guts_node, 0);
of_node_put(guts_node);
if (!guts) {
pr_err("p1022ds: could not map global utilties device\n");
return;
}
indirect_node = of_find_compatible_node(NULL, NULL,
"fsl,p1022ds-indirect-pixis");
if (!indirect_node) {
pr_err("p1022ds: missing pixis indirect mode node\n");
goto exit_guts_iounmap;
}
lbc_lcs0_ba = of_iomap(indirect_node, 0);
if (!lbc_lcs0_ba) {
pr_err("p1022ds: could not map localbus chip select 0\n");
goto exit_indirect_node;
}
lbc_lcs1_ba = of_iomap(indirect_node, 1);
if (!lbc_lcs1_ba) {
pr_err("p1022ds: could not map localbus chip select 1\n");
goto exit_lcs0_iounmap;
}
/* Make sure we're in indirect mode first. */
if ((in_be32(&guts->pmuxcr) & PMUXCR_ELBCDIU_MASK) !=
PMUXCR_ELBCDIU_DIU) {
struct device_node *pixis_node;
void __iomem *pixis;
pixis_node =
of_find_compatible_node(NULL, NULL, "fsl,p1022ds-fpga");
if (!pixis_node) {
pr_err("p1022ds: missing pixis node\n");
goto exit_lcs1_iounmap;
}
pixis = of_iomap(pixis_node, 0);
of_node_put(pixis_node);
if (!pixis) {
pr_err("p1022ds: could not map pixis registers\n");
goto exit_lcs1_iounmap;
}
/* Enable indirect PIXIS mode. */
setbits8(pixis + PX_CTL, PX_CTL_ALTACC);
iounmap(pixis);
/* Switch the board mux to the DIU */
out_8(lbc_lcs0_ba, PX_BRDCFG0); /* BRDCFG0 */
b = in_8(lbc_lcs1_ba);
b |= PX_BRDCFG0_ELBC_DIU;
out_8(lbc_lcs1_ba, b);
/* Set the chip mux to DIU mode. */
clrsetbits_be32(&guts->pmuxcr, PMUXCR_ELBCDIU_MASK,
PMUXCR_ELBCDIU_DIU);
in_be32(&guts->pmuxcr);
}
switch (port) {
case FSL_DIU_PORT_DVI:
/* Enable the DVI port, disable the DFP and the backlight */
out_8(lbc_lcs0_ba, PX_BRDCFG1);
b = in_8(lbc_lcs1_ba);
b &= ~(PX_BRDCFG1_DFPEN | PX_BRDCFG1_BACKLIGHT);
b |= PX_BRDCFG1_DVIEN;
out_8(lbc_lcs1_ba, b);
break;
case FSL_DIU_PORT_LVDS:
/*
* LVDS also needs backlight enabled, otherwise the display
* will be blank.
*/
/* Enable the DFP port, disable the DVI and the backlight */
out_8(lbc_lcs0_ba, PX_BRDCFG1);
b = in_8(lbc_lcs1_ba);
b &= ~PX_BRDCFG1_DVIEN;
b |= PX_BRDCFG1_DFPEN | PX_BRDCFG1_BACKLIGHT;
out_8(lbc_lcs1_ba, b);
break;
default:
pr_err("p1022ds: unsupported monitor port %i\n", port);
}
exit_lcs1_iounmap:
iounmap(lbc_lcs1_ba);
exit_lcs0_iounmap:
iounmap(lbc_lcs0_ba);
exit_indirect_node:
of_node_put(indirect_node);
exit_guts_iounmap:
iounmap(guts);
}
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 01/11] KVM: PPC: Add memory-mapping support for PCI passthrough and emulation
From: Avi Kivity @ 2011-11-20 12:23 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Alexander Graf, kvm-ppc
In-Reply-To: <20111116225209.GB26985@bloggs.ozlabs.ibm.com>
On 11/17/2011 12:52 AM, Paul Mackerras wrote:
> From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>
> This adds support for adding PCI device I/O regions to the guest memory
> map, and for trapping guest accesses to emulated MMIO regions and
> delivering them to qemu for MMIO emulation. To trap guest accesses to
> emulated MMIO regions, we reserve key 31 for the hypervisor's use and
> set the VPM1 bit in LPCR, which sends all page faults to the host.
> Any page fault that is not a key fault gets reflected immediately to the
> guest. We set HPTEs for emulated MMIO regions to have key = 31, and
> don't allow the guest to create HPTEs with key = 31. Any page fault
> that is a key fault with key = 31 is then a candidate for MMIO
> emulation and thus gets sent up to qemu. We also load the instruction
> that caused the fault for use later when qemu has done the emulation.
>
> [paulus@samba.org: Cleaned up, moved kvmppc_book3s_hv_emulate_mmio()
> to book3s_64_mmu_hv.c]
>
>
> + /*
> + * XXX WARNING: We do not know for sure whether the instruction we just
> + * read from memory is the same that caused the fault in the first
> + * place. We don't have a problem with the guest shooting itself in
> + * the foot that way, however we must be careful that we enforce
> + * the write permission based on the instruction we are actually
> + * emulating, not based on dsisr. Unfortunately, the KVM code for
> + * instruction emulation isn't smart enough for that to work
> + * so right now we just do it badly and racily, but that will need
> + * fixing
> + */
> +
Ouch, I assume this will be fixed before merging?
> }
>
> int kvmppc_core_prepare_memory_region(struct kvm *kvm,
> - struct kvm_userspace_memory_region *mem)
> + struct kvm_memory_slot *memslot,
> + struct kvm_userspace_memory_region *mem)
> {
> unsigned long psize, porder;
> unsigned long i, npages, totalpages;
> unsigned long pg_ix;
> struct kvmppc_pginfo *pginfo;
> - unsigned long hva;
> struct kvmppc_rma_info *ri = NULL;
> + struct vm_area_struct *vma;
> struct page *page;
> + unsigned long hva;
> +
> + /*
> + * This could be an attempt at adding memory or it could be MMIO
> + * pass-through. We need to treat them differently but the only
> + * way for us to know what it is is to look at the VMA and play
> + * guess work so let's just do that
> + */
There is no "the VMA". There could be multiple VMAs, or none (with the
mmap() coming afterwards). You could do all the checks you want here,
only to have host userspace remap it under your feet. This needs to be
done on a per-page basis at fault time.
Please see the corresponding x86 code (warning: convoluted), which has a
similar problem (though I have no idea if you can use a similar solution).
> +
> + /*
> + * We require read & write permission as we cannot yet
> + * enforce guest read-only protection or no access.
> + */
> + if ((vma->vm_flags & (VM_READ | VM_WRITE)) !=
> + (VM_READ | VM_WRITE))
> + goto err_unlock;
This, too, must be done at get_user_pages() time.
What happens if mmu notifiers tell you to write protect a page?
> void kvm_arch_commit_memory_region(struct kvm *kvm,
> diff --git a/include/linux/kvm.h b/include/linux/kvm.h
> index c107fae..774b04d 100644
> --- a/include/linux/kvm.h
> +++ b/include/linux/kvm.h
> @@ -105,6 +105,9 @@ struct kvm_userspace_memory_region {
> #define KVM_MEM_LOG_DIRTY_PAGES 1UL
> #define KVM_MEMSLOT_INVALID (1UL << 1)
>
> +/* Kernel internal use */
> +#define KVM_MEMSLOT_IO (1UL << 31)
> +
Please define it internally then (and leave a comment so we don't
overlap it).
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: [RFC PATCH 10/11] KVM: PPC: Implement MMU notifiers
From: Avi Kivity @ 2011-11-20 12:38 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Alexander Graf, kvm-ppc
In-Reply-To: <20111116235220.GK26985@bloggs.ozlabs.ibm.com>
On 11/17/2011 01:52 AM, Paul Mackerras wrote:
> This implements the low-level functions called by the MMU notifiers in
> the generic KVM code, and defines KVM_ARCH_WANT_MMU_NOTIFIER if
> CONFIG_KVM_BOOK3S_64_HV so that the generic KVM MMU notifiers get
> included.
>
> That means we also have to take notice of when PTE invalidations are
> in progress, as indicated by mmu_notifier_retry(). In kvmppc_h_enter,
> if any invalidation is in progress we just install a non-present HPTE.
> In kvmppc_book3s_hv_page_fault, if an invalidation is in progress we
> just return without resolving the guest, causing it to encounter another
> page fault immediately. This is better than spinning inside
> kvmppc_book3s_hv_page_fault because this way the guest can get preempted
> by a hypervisor decrementer interrupt without us having to do any
> special checks.
>
> We currently maintain a referenced bit in the rmap array, and when we
> clear it, we make all the HPTEs that map the corresponding page be
> non-present, as if the page were invalidated. In future we could use
> the hardware reference bit in the guest HPT instead.
>
> The kvm_set_spte_hva function is implemented as kvm_unmap_hva. The
> former appears to be unused anyway.
This is mostly used for COW (after ksm, not fork). So if you want to
use ksm, this avoids an exit.
> This all means that on processors that support virtual partition
> memory (POWER7), we can claim support for the KVM_CAP_SYNC_MMU
> capability, and we no longer have to pin all the guest memory.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: [PATCH][v2] powerpc/p1023: set IRQ[4:6, 11] to active-high level sensitive for PCIe
From: Kumar Gala @ 2011-11-20 15:51 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1321506575-21730-1-git-send-email-galak@kernel.crashing.org>
On Nov 16, 2011, at 11:09 PM, Kumar Gala wrote:
> From: Roy Zang <tie-fei.zang@freescale.com>
>
> P1023 external IRQ[4:6, 11] are not pin out, but the interrupts are
> utilized by the PCIe controllers. As they are not exposed as pins we
> need to set them as active-high (internal to the SoC these interrupts
> are pulled down).
>
> IRQs[0:3,7:10] are pulled up on the board so we have them set as
> active-low.
>
> Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> ---
> v2:
> * cleaned up commit message & added comments to be clear about IRQ usage
applied to merge
- k
^ permalink raw reply
* Re: [PATCH] powerpc/p3060qds: Fix select of 'MPC8xxx_GPIO'
From: Kumar Gala @ 2011-11-20 15:53 UTC (permalink / raw)
To: Paul Bolle; +Cc: linux-kernel, Anatolij Gustschin, linuxppc-dev, Shengzhou Liu
In-Reply-To: <1321141830.20271.22.camel@x61.thuisdomein>
On Nov 12, 2011, at 5:50 PM, Paul Bolle wrote:
> The driver for the Freescale P3060 QDS got added by commit 96cc017c5b
> ("[...] Add support for P3060QDS board"). Its Kconfig entry selects
> MPC8xxx_GPIO. But at the time that driver got added MPC8xxx_GPIO was
> already renamed to GPIO_MPC8XXX, by commit c68308dd50c ("gpio: move
> mpc8xxx/512x gpio driver to drivers/gpio").
>
> So make this driver select GPIO_MPC8XXX.
>
> Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
> ---
> 0) Bravely untested: I haven't got the hardware nor the PPC toolchain
> needed to build this. And it seems this needs (build) testing anyhow.
>
> 1) Sent to the people who wrote the two patches mentioned in the commit
> explanation and CC'd the non-authors who signed-off these patches.
>
> 2) The config tools do not complain about selects that cannot be met
> because they concern a Kconfig symbol that doesn't even exist. Shouldn't
> they be made to complain in that case?
>
> arch/powerpc/platforms/85xx/Kconfig | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
applied to merge
- k
^ permalink raw reply
* [PATCH] powerpc/85xx: Fix compile error on p3060_qds.c
From: Kumar Gala @ 2011-11-20 15:59 UTC (permalink / raw)
To: linuxppc-dev
arch/powerpc/platforms/85xx/p3060_qds.c: In function '__machine_initcall_p3060_qds_declare_of_platform_devices':
arch/powerpc/platforms/85xx/p3060_qds.c:73:1: error: implicit declaration of function 'declare_of_platform_devices'
declare_of_platform_devices should have been corenet_ds_publish_devices.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
arch/powerpc/platforms/85xx/p3060_qds.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/p3060_qds.c b/arch/powerpc/platforms/85xx/p3060_qds.c
index 01dcf44..081cf4a 100644
--- a/arch/powerpc/platforms/85xx/p3060_qds.c
+++ b/arch/powerpc/platforms/85xx/p3060_qds.c
@@ -70,7 +70,7 @@ define_machine(p3060_qds) {
.power_save = e500_idle,
};
-machine_device_initcall(p3060_qds, declare_of_platform_devices);
+machine_device_initcall(p3060_qds, corenet_ds_publish_devices);
#ifdef CONFIG_SWIOTLB
machine_arch_initcall(p3060_qds, swiotlb_setup_bus_notifier);
--
1.7.3.4
^ permalink raw reply related
* Re: [PATCH 01/29] powerpc/85xx: Simplify P1020RDB CAMP dts using includes
From: Kumar Gala @ 2011-11-20 16:13 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1321514181-28897-1-git-send-email-galak@kernel.crashing.org>
On Nov 17, 2011, at 1:15 AM, Kumar Gala wrote:
> If we include the p1020rdb.dts instead of p1020si.dts we greatly =
reduce
> duplication and maintenance. We can just list which devices are
> disabled for the given core and mpic protected sources.
>=20
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> ---
> arch/powerpc/boot/dts/p1020rdb_camp_core0.dts | 154 =
+------------------------
> arch/powerpc/boot/dts/p1020rdb_camp_core1.dts | 11 +--
> 2 files changed, 4 insertions(+), 161 deletions(-)
applied 1-29, and v2 for p2041 & p1022 to 'next'
- k=
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: Fix compile error on p3060_qds.c
From: Kumar Gala @ 2011-11-20 16:13 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1321804775-15455-1-git-send-email-galak@kernel.crashing.org>
On Nov 20, 2011, at 9:59 AM, Kumar Gala wrote:
> arch/powerpc/platforms/85xx/p3060_qds.c: In function =
'__machine_initcall_p3060_qds_declare_of_platform_devices':
> arch/powerpc/platforms/85xx/p3060_qds.c:73:1: error: implicit =
declaration of function 'declare_of_platform_devices'
>=20
> declare_of_platform_devices should have been =
corenet_ds_publish_devices.
>=20
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> ---
> arch/powerpc/platforms/85xx/p3060_qds.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
applied to merge
- k=
^ permalink raw reply
* Re: [PATCH v2 1/7] powerpc/85xx: re-enable timebase sync disabled by KEXEC patch
From: Kumar Gala @ 2011-11-20 16:46 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Zhao Chenhui
In-Reply-To: <20111118180114.GB28562@schlenkerla.am.freescale.net>
On Nov 18, 2011, at 12:01 PM, Scott Wood wrote:
> On Fri, Nov 18, 2011 at 08:35:02AM -0600, Kumar Gala wrote:
>>=20
>> On Nov 16, 2011, at 12:42 PM, Scott Wood wrote:
>>=20
>>> On 11/16/2011 03:55 AM, Zhao Chenhui wrote:
>>>> From: Li Yang <leoli@freescale.com>
>>>>=20
>>>> The timebase sync is not only necessary when using KEXEC. It should =
also
>>>> be used by normal boot up and cpu hotplug. Remove the ifdef added =
by
>>>> the KEXEC patch.
>>>=20
>>> Again, no it should not be used by normal boot up (whether KEXEC =
support
>>> is enabled or not). We should only do timebase sync when we =
actually
>>> need to (when we've actually just reset a core), and we should do it =
the
>>> way U-Boot does rather than with smp-tbsync.c.
>>=20
>>=20
>> How can we do u-boot bases timebase sync after the system us up and
>> running? For example would we losing some ticks of time in the case
>> that one core is up and we bring a second core online?
>=20
> Yes, we'll lose a small handful of ticks relative to wall clock time =
--
> but it'll be the same loss on all cores. It's better than possibly
> having the timebase be imperfectly synchronized, and should complete =
more
> quickly.
Hmm, I wondering how many ticks it really is.
> This is only during intrusive events such as kexec or deep sleep (we =
only
> need to reset the core for jog on mpc8536 which has only one core).=20
> During deep sleep all cores' timebases will be stopped. Kexec is
> resetting the kernel; it's not going to care what the old timebase =
was,
> and should resync from RTC.
>=20
> Even if we end up using this for some future power management mode =
where
> we take down some CPUs to the point their timebase stops, but never =
take
> down others, the time loss should be negligible (for comparison, =
what's
> the error tolerance on the crystal frequency?) and acceptable for what =
is
> still a fairly intrusive and rare event.
I'm also concerned about how this ends up working for p4080 when we have =
to sync up to 8 cores or more in the future.
- k=
^ permalink raw reply
* Re: 3.2.0-rc1 panic on PowerPC
From: Christian Kujau @ 2011-11-20 23:31 UTC (permalink / raw)
To: LKML; +Cc: linuxppc-dev
In-Reply-To: <alpine.DEB.2.01.1111150035560.8000@trent.utfs.org>
On Tue, 15 Nov 2011 at 00:44, Christian Kujau wrote:
> I noticed a few crashes on this PowerBook G4 lately, starting somewhere in
> 3.2.0-rc1. The crashes are really rare and as I'm not on the system all
> the time I did not notice most of them. By the time I did, the screen was
> blank already and I had to hard-reset the box. But not this time:
>
> http://nerdbynature.de/bits/3.2.0-rc1/oops/
>
> When the crash occured, the system was failry loaded (CPU and disk I/O
> wise), so that may have triggered it. I tried to type off the stack trace,
> I hope there are not too many typos, see below.
>
> The machine is fairly old, so maybe it's "just" bad RAM or something, I
> wouldn't be suprised. But maybe not, the box us pretty stable most of the
> time and only now I notice these rare crashes.
Happened again with 3.2.0-rc2-00027-gff0ff78, this time with netconsole
enabled. But this time the machine just stopped, w/o any output on the
screen or on netconsole :(
Christian.
> If anyone could take a quick look...?
>
> Thank you,
> Christian.
>
> Instruction dump:
> 92c40008 68000001 0f000000 80040000 5400003c 90040000 817f000c 380bffff
> 901f000c 2f090000 81640018 81440014 <916a0004> 914b0000 92840014 92a49918
> Kernel panic - not syncing: Fatal exception in interrupt
> Call Trace:
> show_stack+0x70/0x1bc (unreliable)
> panic+0xc8/0x220
> die+0x2ac/0x2b8
> bad_page_fault+0xbc/0x104
> handle_page_fault+0x7c/0x80
> Exception: 300 at T.975+0x3f4/0x570
> LR = T.957+0x300/0x570
> kmem_cache_alloc+0x150/0x150
> __aloc_skb+0x50/0x148
> tcp_send_ack+0x35/0x138
> tcp_delay_timer+0x140/0x244
> run_timer_softirq+0x1a0/0x2ec
> __do_softirq+0xf4/0x1bc
> call_do_softirq+0x14/0x24
> do_softirq+0xfc/0x128
> irq_exit+0xa0/0xa4
> timer_interrupt+0x148/0x180
> ret_from_except+0x0/0x14
> cpu_idle+0xa0/0x118
> rest_init+0xf0/0x114
> start_kernel+0x2d0/0x2f0
> 0x3444
> Rebooting in 180 seconds..
>
> --
> BOFH excuse #184:
>
> loop found in loop in redundant loopback
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
BOFH excuse #387:
Your computer's union contract is set to expire at midnight.
^ permalink raw reply
* Re: 3.2.0-rc1 panic on PowerPC
From: Benjamin Herrenschmidt @ 2011-11-21 0:58 UTC (permalink / raw)
To: Christian Kujau; +Cc: linuxppc-dev, LKML
In-Reply-To: <alpine.DEB.2.01.1111201529070.8000@trent.utfs.org>
On Sun, 2011-11-20 at 15:31 -0800, Christian Kujau wrote:
> On Tue, 15 Nov 2011 at 00:44, Christian Kujau wrote:
> > I noticed a few crashes on this PowerBook G4 lately, starting somewhere in
> > 3.2.0-rc1. The crashes are really rare and as I'm not on the system all
> > the time I did not notice most of them. By the time I did, the screen was
> > blank already and I had to hard-reset the box. But not this time:
> >
> > http://nerdbynature.de/bits/3.2.0-rc1/oops/
> >
> > When the crash occured, the system was failry loaded (CPU and disk I/O
> > wise), so that may have triggered it. I tried to type off the stack trace,
> > I hope there are not too many typos, see below.
> >
> > The machine is fairly old, so maybe it's "just" bad RAM or something, I
> > wouldn't be suprised. But maybe not, the box us pretty stable most of the
> > time and only now I notice these rare crashes.
>
> Happened again with 3.2.0-rc2-00027-gff0ff78, this time with netconsole
> enabled. But this time the machine just stopped, w/o any output on the
> screen or on netconsole :(
I've seen something similar with 3.2-rc2 at cfcfc9ec, unfortunately I
couldn't capture the oops log at the time.
Looks like there's some kind of memory corruption happening. So far I
haven't been able to get a good target at what could be causing it.
Cheers,
Ben.
> Christian.
>
> > If anyone could take a quick look...?
> >
> > Thank you,
> > Christian.
> >
> > Instruction dump:
> > 92c40008 68000001 0f000000 80040000 5400003c 90040000 817f000c 380bffff
> > 901f000c 2f090000 81640018 81440014 <916a0004> 914b0000 92840014 92a49918
> > Kernel panic - not syncing: Fatal exception in interrupt
> > Call Trace:
> > show_stack+0x70/0x1bc (unreliable)
> > panic+0xc8/0x220
> > die+0x2ac/0x2b8
> > bad_page_fault+0xbc/0x104
> > handle_page_fault+0x7c/0x80
> > Exception: 300 at T.975+0x3f4/0x570
> > LR = T.957+0x300/0x570
> > kmem_cache_alloc+0x150/0x150
> > __aloc_skb+0x50/0x148
> > tcp_send_ack+0x35/0x138
> > tcp_delay_timer+0x140/0x244
> > run_timer_softirq+0x1a0/0x2ec
> > __do_softirq+0xf4/0x1bc
> > call_do_softirq+0x14/0x24
> > do_softirq+0xfc/0x128
> > irq_exit+0xa0/0xa4
> > timer_interrupt+0x148/0x180
> > ret_from_except+0x0/0x14
> > cpu_idle+0xa0/0x118
> > rest_init+0xf0/0x114
> > start_kernel+0x2d0/0x2f0
> > 0x3444
> > Rebooting in 180 seconds..
> >
> > --
> > BOFH excuse #184:
> >
> > loop found in loop in redundant loopback
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
> >
>
^ permalink raw reply
* Re: 3.2.0-rc1 panic on PowerPC
From: Christian Kujau @ 2011-11-21 1:17 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, LKML
In-Reply-To: <1321837101.13860.6.camel@pasglop>
On Mon, 21 Nov 2011 at 11:58, Benjamin Herrenschmidt wrote:
> I've seen something similar with 3.2-rc2 at cfcfc9ec, unfortunately I
> couldn't capture the oops log at the time.
It just happened again today, after heavy CPU & IO load (rsyncing from/to
external disks on dm-crypt). This time the oops was printed on the screen
but nothing on netconsole:
http://nerdbynature.de/bits/3.2.0-rc1/oops/oops3m.JPG
It looks like the oops I reported earlier (oops2m.JPG) so I doubt it's a
random corruption due to hardware issues...?
Any debug or boot options to set in my next kernel build?
Thanks,
Christian.
> Looks like there's some kind of memory corruption happening. So far I
> haven't been able to get a good target at what could be causing it.
--
BOFH excuse #90:
Budget cuts
^ permalink raw reply
* Re: 3.2.0-rc1 panic on PowerPC
From: Benjamin Herrenschmidt @ 2011-11-21 1:25 UTC (permalink / raw)
To: Christian Kujau; +Cc: linuxppc-dev, LKML
In-Reply-To: <alpine.DEB.2.01.1111201701000.8000@trent.utfs.org>
On Sun, 2011-11-20 at 17:17 -0800, Christian Kujau wrote:
> On Mon, 21 Nov 2011 at 11:58, Benjamin Herrenschmidt wrote:
> > I've seen something similar with 3.2-rc2 at cfcfc9ec, unfortunately I
> > couldn't capture the oops log at the time.
>
> It just happened again today, after heavy CPU & IO load (rsyncing from/to
> external disks on dm-crypt). This time the oops was printed on the screen
> but nothing on netconsole:
>
> http://nerdbynature.de/bits/3.2.0-rc1/oops/oops3m.JPG
>
> It looks like the oops I reported earlier (oops2m.JPG) so I doubt it's a
> random corruption due to hardware issues...?
Yeah it's starting to look like a pattern. Your latest oops looks a lot
like the one I had (though it was with tg3 on the g5), ie, vfs_read ->
driver -> allocator -> crash.
> Any debug or boot options to set in my next kernel build?
Well, you can turn everything on see whether that makes any difference
or finds something a bit more precisely
Cheers,
Ben.
> Thanks,
> Christian.
>
> > Looks like there's some kind of memory corruption happening. So far I
> > haven't been able to get a good target at what could be causing it.
>
^ permalink raw reply
* Re: 3.2.0-rc1 panic on PowerPC
From: Benjamin Herrenschmidt @ 2011-11-21 1:51 UTC (permalink / raw)
To: Christian Kujau; +Cc: linuxppc-dev, LKML
In-Reply-To: <1321838742.13860.8.camel@pasglop>
On Mon, 2011-11-21 at 12:25 +1100, Benjamin Herrenschmidt wrote:
> On Sun, 2011-11-20 at 17:17 -0800, Christian Kujau wrote:
> > On Mon, 21 Nov 2011 at 11:58, Benjamin Herrenschmidt wrote:
> > > I've seen something similar with 3.2-rc2 at cfcfc9ec, unfortunately I
> > > couldn't capture the oops log at the time.
> >
> > It just happened again today, after heavy CPU & IO load (rsyncing from/to
> > external disks on dm-crypt). This time the oops was printed on the screen
> > but nothing on netconsole:
> >
> > http://nerdbynature.de/bits/3.2.0-rc1/oops/oops3m.JPG
> >
> > It looks like the oops I reported earlier (oops2m.JPG) so I doubt it's a
> > random corruption due to hardware issues...?
>
> Yeah it's starting to look like a pattern. Your latest oops looks a lot
> like the one I had (though it was with tg3 on the g5), ie, vfs_read ->
> driver -> allocator -> crash.
>
> > Any debug or boot options to set in my next kernel build?
>
> Well, you can turn everything on see whether that makes any difference
> or finds something a bit more precisely
BTW. SLUB or SLAB ? Mine was SLUB with SLUB_DEBUG enabled (tho the debug
didn't seem to catch anything).
Cheers,
Ben.
^ permalink raw reply
* Re: 3.2.0-rc1 panic on PowerPC
From: Christian Kujau @ 2011-11-21 2:03 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, LKML
In-Reply-To: <1321840301.13860.9.camel@pasglop>
On Mon, 21 Nov 2011 at 12:51, Benjamin Herrenschmidt wrote:
> BTW. SLUB or SLAB ? Mine was SLUB with SLUB_DEBUG enabled (tho the debug
> didn't seem to catch anything).
SLUB, and SLUB_DEBUG=y (but w/o SLUB_DEBUG_ON and SLUB_STATS). Full config
here: http://nerdbynature.de/bits/3.2.0-rc1/oops/config.txt
I'm compiling today's git checkout (mainline) with more debug settings
enabled[0], let's see if this helps anything.
Christian.
[0] diff to old config
+CONFIG_RT_MUTEX_TESTER=y
+CONFIG_DEBUG_LOCKDEP=y
+CONFIG_DEBUG_HIGHMEM=y
+CONFIG_DEBUG_INFO=y
+CONFIG_DEBUG_VM=y
+CONFIG_DEBUG_WRITECOUNT=y
+CONFIG_DEBUG_LIST=y
+CONFIG_ATOMIC64_SELFTEST=y
+CONFIG_XMON=y
+CONFIG_XMON_DEFAULT=y
+CONFIG_XMON_DISASSEMBLY=y
+CONFIG_DEBUGGER=y
--
BOFH excuse #242:
Software uses US measurements, but the OS is in metric...
^ permalink raw reply
* Re: [PATCH v3 2/3] hvc_init(): Enforce one-time initialization.
From: Rusty Russell @ 2011-11-21 5:01 UTC (permalink / raw)
To: Miche Baker-Harvey
Cc: Stephen Rothwell, xen-devel, Konrad Rzeszutek Wilk,
Greg Kroah-Hartman, linux-kernel, virtualization, Anton Blanchard,
Amit Shah, Mike Waychison, ppc-dev, Eric Northrup
In-Reply-To: <CAB8RdapbaueyWLJuJDE_ZdvLkRNM4sQHTxgmgO=jrnXZ6YPSmA@mail.gmail.com>
On Thu, 17 Nov 2011 10:57:37 -0800, Miche Baker-Harvey <miche@google.com> wrote:
> Rusty, Michael, Stephen, et al,
>
> Thanks for your comments on these patches.
>
> For what I'm trying to do, all three patches are necessary, but maybe
> I'm going about it the wrong way. Your input would be appreciated.
> I'm in no way claiming that these patches are "right", just that it's
> working for me, and that what's in the current pool is not.
We have to *understand* the code. If we don't, we need to rewrite the
code so we *do* understand it, or make way for someone who does.
I'm looking at the kvm man page to try to figure out how to have virtio
console, and it's deeply unclear. What kvm commandline are you using?
I'll try to debug it here, and see what I learn about hvc_console.
Cheers,
Rusty.
^ permalink raw reply
* [PATCH] powerpc/85xx: Add lbc suspend support for PM
From: Jia Hongtao @ 2011-11-21 6:29 UTC (permalink / raw)
To: linuxppc-dev; +Cc: B11780, b38951
Power supply for LBC registers is off when system go to deep-sleep state.
We save the values of registers before suspend and restore to registers
after resume.
We removed the last two reservation arrays from struct fsl_lbc_regs for
allocating less memory and minimizing the memcpy size.
Signed-off-by: Jiang Yutang <b14898@freescale.com>
Signed-off-by: Jia Hongtao <B38951@freescale.com>
Signed-off-by: Li Yang <leoli@freescale.com>
---
arch/powerpc/include/asm/fsl_lbc.h | 7 +++++--
arch/powerpc/sysdev/fsl_lbc.c | 36 ++++++++++++++++++++++++++++++++++++
2 files changed, 41 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/fsl_lbc.h b/arch/powerpc/include/asm/fsl_lbc.h
index 8a0b5ec..420b453 100644
--- a/arch/powerpc/include/asm/fsl_lbc.h
+++ b/arch/powerpc/include/asm/fsl_lbc.h
@@ -238,8 +238,6 @@ struct fsl_lbc_regs {
#define FPAR_LP_CI_SHIFT 0
__be32 fbcr; /**< Flash Byte Count Register */
#define FBCR_BC 0x00000FFF
- u8 res11[0x8];
- u8 res8[0xF00];
};
/*
@@ -294,6 +292,11 @@ struct fsl_lbc_ctrl {
/* status read from LTESR by irq handler */
unsigned int irq_status;
+
+#ifdef CONFIG_SUSPEND
+ /* save regs when system go to deep-sleep */
+ struct fsl_lbc_regs *saved_regs;
+#endif
};
extern int fsl_upm_run_pattern(struct fsl_upm *upm, void __iomem *io_base,
diff --git a/arch/powerpc/sysdev/fsl_lbc.c b/arch/powerpc/sysdev/fsl_lbc.c
index d917573..9f33e40 100644
--- a/arch/powerpc/sysdev/fsl_lbc.c
+++ b/arch/powerpc/sysdev/fsl_lbc.c
@@ -330,6 +330,38 @@ err:
return ret;
}
+#ifdef CONFIG_SUSPEND
+
+/* save lbc registers */
+static int fsl_lbc_suspend(struct platform_device *pdev, pm_message_t state)
+{
+ struct fsl_lbc_ctrl *ctrl = dev_get_drvdata(&pdev->dev);
+ struct fsl_lbc_regs __iomem *lbc = ctrl->regs;
+
+ ctrl->saved_regs = kmalloc(sizeof(struct fsl_lbc_regs), GFP_KERNEL);
+ if (!ctrl->saved_regs)
+ return -ENOMEM;
+
+ _memcpy_fromio(ctrl->saved_regs, lbc, sizeof(struct fsl_lbc_regs));
+ return 0;
+}
+
+/* restore lbc registers */
+static int fsl_lbc_resume(struct platform_device *pdev)
+{
+ struct fsl_lbc_ctrl *ctrl = dev_get_drvdata(&pdev->dev);
+ struct fsl_lbc_regs __iomem *lbc = ctrl->regs;
+
+ if (ctrl->saved_regs) {
+ _memcpy_toio(lbc, ctrl->saved_regs,
+ sizeof(struct fsl_lbc_regs));
+ kfree(ctrl->saved_regs);
+ ctrl->saved_regs = NULL;
+ }
+ return 0;
+}
+#endif /* CONFIG_SUSPEND */
+
static const struct of_device_id fsl_lbc_match[] = {
{ .compatible = "fsl,elbc", },
{ .compatible = "fsl,pq3-localbus", },
@@ -344,6 +376,10 @@ static struct platform_driver fsl_lbc_ctrl_driver = {
.of_match_table = fsl_lbc_match,
},
.probe = fsl_lbc_ctrl_probe,
+#ifdef CONFIG_SUSPEND
+ .suspend = fsl_lbc_suspend,
+ .resume = fsl_lbc_resume,
+#endif
};
static int __init fsl_lbc_init(void)
--
1.7.5.1
^ permalink raw reply related
* Re: 3.2.0-rc1 panic on PowerPC
From: Markus Trippelsdorf @ 2011-11-21 8:08 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Christian Kujau, linuxppc-dev, LKML
In-Reply-To: <1321838742.13860.8.camel@pasglop>
On 2011.11.21 at 12:25 +1100, Benjamin Herrenschmidt wrote:
> On Sun, 2011-11-20 at 17:17 -0800, Christian Kujau wrote:
> > On Mon, 21 Nov 2011 at 11:58, Benjamin Herrenschmidt wrote:
> > > I've seen something similar with 3.2-rc2 at cfcfc9ec, unfortunately I
> > > couldn't capture the oops log at the time.
> >
> > It just happened again today, after heavy CPU & IO load (rsyncing from/to
> > external disks on dm-crypt). This time the oops was printed on the screen
> > but nothing on netconsole:
> >
> > http://nerdbynature.de/bits/3.2.0-rc1/oops/oops3m.JPG
> >
> > It looks like the oops I reported earlier (oops2m.JPG) so I doubt it's a
> > random corruption due to hardware issues...?
>
> Yeah it's starting to look like a pattern. Your latest oops looks a lot
> like the one I had (though it was with tg3 on the g5), ie, vfs_read ->
> driver -> allocator -> crash.
I might be seeing a similar issue on x86_64. See:
http://thread.gmane.org/gmane.linux.kernel.mm/70254
--
Markus
^ permalink raw reply
* Re: [PATCH 01/11] KVM: PPC: Add memory-mapping support for PCI passthrough and emulation
From: Paul Mackerras @ 2011-11-21 11:03 UTC (permalink / raw)
To: Avi Kivity; +Cc: linuxppc-dev, Alexander Graf, kvm-ppc
In-Reply-To: <4EC8F158.8010706@redhat.com>
On Sun, Nov 20, 2011 at 02:23:52PM +0200, Avi Kivity wrote:
>
> There is no "the VMA". There could be multiple VMAs, or none (with the
> mmap() coming afterwards). You could do all the checks you want here,
> only to have host userspace remap it under your feet. This needs to be
> done on a per-page basis at fault time.
OK, so that's a somewhat different mental model than I had in mind. I
can change the code to do almost everything on a per-page basis at
fault time on POWER7. There is one thing we can't do at fault time,
which is to tell the hardware the page size for the "virtual real mode
area" (VRMA), which is a mapping of the memory starting at guest
physical address zero. We can however work out that pagesize the
first time we run a vcpu. By that stage we must have some memory
mapped at gpa 0, otherwise the vcpu is not going to get very far. We
will need to look for the page size of whatever is mapped at gpa 0 at
that point and give it to the hardware.
On PPC970, which is a much older processor, we can't intercept the
page faults (at least not without running the whole guest in user mode
and emulating all the privileged instructions), so once we have given
the guest access to a page, we can't revoke it. We will have to take
and keep a reference to the page so it doesn't go away underneath us,
which of course doesn't guarantee that userland can continue to see
it, but does at least mean we won't corrupt memory.
> > + /*
> > + * We require read & write permission as we cannot yet
> > + * enforce guest read-only protection or no access.
> > + */
> > + if ((vma->vm_flags & (VM_READ | VM_WRITE)) !=
> > + (VM_READ | VM_WRITE))
> > + goto err_unlock;
>
> This, too, must be done at get_user_pages() time.
>
> What happens if mmu notifiers tell you to write protect a page?
On POWER7, we have to remove access to the page, and then when we get
a fault on the page, request write access when we do
get_user_pages_fast.
Paul.
^ permalink raw reply
* Re: [RFC PATCH v5 0/9] fadump: Firmware-assisted dump support for Powerpc.
From: Cong Wang @ 2011-11-21 12:03 UTC (permalink / raw)
To: Vivek Goyal
Cc: Mahesh J Salgaonkar, Kexec-ml, Linux Kernel, Milton Miller,
linuxppc-dev, Randy Dunlap, Eric W. Biederman, Anton Blanchard
In-Reply-To: <20111115151145.16533.16384.stgit@mars.in.ibm.com>
Vivek, could you please review this patchset?
Thanks.
^ permalink raw reply
* Re: [PATCH 01/11] KVM: PPC: Add memory-mapping support for PCI passthrough and emulation
From: Avi Kivity @ 2011-11-21 12:22 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Alexander Graf, kvm-ppc
In-Reply-To: <20111121110356.GA1516@bloggs.ozlabs.ibm.com>
On 11/21/2011 01:03 PM, Paul Mackerras wrote:
> On Sun, Nov 20, 2011 at 02:23:52PM +0200, Avi Kivity wrote:
> >
> > There is no "the VMA". There could be multiple VMAs, or none (with the
> > mmap() coming afterwards). You could do all the checks you want here,
> > only to have host userspace remap it under your feet. This needs to be
> > done on a per-page basis at fault time.
>
> OK, so that's a somewhat different mental model than I had in mind. I
> can change the code to do almost everything on a per-page basis at
> fault time on POWER7. There is one thing we can't do at fault time,
> which is to tell the hardware the page size for the "virtual real mode
> area" (VRMA), which is a mapping of the memory starting at guest
> physical address zero. We can however work out that pagesize the
> first time we run a vcpu. By that stage we must have some memory
> mapped at gpa 0, otherwise the vcpu is not going to get very far. We
> will need to look for the page size of whatever is mapped at gpa 0 at
> that point and give it to the hardware.
Ok. Do you need to check at fault time that your assumptions haven't
changed, then?
> On PPC970, which is a much older processor, we can't intercept the
> page faults (at least not without running the whole guest in user mode
> and emulating all the privileged instructions), so once we have given
> the guest access to a page, we can't revoke it. We will have to take
> and keep a reference to the page so it doesn't go away underneath us,
> which of course doesn't guarantee that userland can continue to see
> it, but does at least mean we won't corrupt memory.
Yes, this is similar to kvm/x86 before mmu notifiers were added.
>
> > > + /*
> > > + * We require read & write permission as we cannot yet
> > > + * enforce guest read-only protection or no access.
> > > + */
> > > + if ((vma->vm_flags & (VM_READ | VM_WRITE)) !=
> > > + (VM_READ | VM_WRITE))
> > > + goto err_unlock;
> >
> > This, too, must be done at get_user_pages() time.
> >
> > What happens if mmu notifiers tell you to write protect a page?
>
> On POWER7, we have to remove access to the page, and then when we get
> a fault on the page, request write access when we do
> get_user_pages_fast.
Ok, so no ksm for you. Does this apply to kvm-internal write
protection, like we do for the framebuffer and live migration? I guess
you don't care much about the framebuffer (and anyway it doesn't need
read-only access), but removing access for live migration is painful.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox