On 08/07/2015 07:54 AM, Graeme Gregory wrote:
On Thu, Aug 06, 2015 at 05:33:10PM -0700, David Daney wrote:
From: David Daney
Find out which PHYs belong to which BGX instance in the ACPI way.
Set the MAC address of the device as provided by ACPI tables. This is
similar to the implementation
On Fri, Aug 7, 2015 at 9:10 AM, Nathan Lynch wrote:
> On 08/06/2015 05:52 PM, Andy Lutomirski wrote:
>> [adding lots of cc's]
>>
>> On Thu, Aug 6, 2015 at 2:45 PM, Andy Lutomirski wrote:
>>> From: Andy Lutomirski
>>>
>>> Some dynamic loaders may be slightly faster if a GNU hash is
>>>
>From the usb 3.1 spec available at http://www.usb.org/developers/docs/
table 10-7 (Hub Class Requests) specifies the values for SetHubDepth and
GetPortErrorCount as:
Request bmRequestType bRequest wValue wIndex wLength Data
SetHubDepth 0010B SET_HUB_DEPTH Hub Depth Zero Zero None
So ... what you're doing here is if somebody requests the last 512 bytes,
you're asking for the last page. That's going to work as long as the partition
is a multiple of PAGE_SIZE, but not if the partition happens to be misaligned.
It's an improvement, although I'd be tempted to do this as:
The previous versions of this patch contain spelling errors and cryptic
messages, please ignore them. The patch removes the check of the return value
of lzo1x_1_compress, since it returns always LZO_E_OK.
Salah Triki (1):
zram: Remove useless check
drivers/block/zram/zcomp_lzo.c | 3 +--
1
3.10.84-rt92-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Bogdan Purcareata
While converting the openpic emulation code to use a raw_spinlock_t enables
guests to run on RT, there's still a performance issue. For interrupts sent in
directed
3.10.84-rt92-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Steven Rostedt
Running a test on a large CPU count box with xfs, I hit a live lock
with the following backtraces on several CPUs:
Call Trace:
[] __const_udelay+0x28/0x30
[]
3.10.84-rt92-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Sebastian Andrzej Siewior
This approach is broken with SLAB_DESTROY_BY_RCU allocations.
Reported by Steven Rostedt and Koehrer Mathias.
Cc: stable...@vger.kernel.org
Signed-off-by:
On Fri, 2015-08-07 at 08:37 -0700, Joe Perches wrote:
> On Fri, 2015-08-07 at 09:01 -0600, Ross Zwisler wrote:
> > When running checkpatch.pl against my latest patch set, I hit what I think
> > are
> > two false positives. Here are the related lines:
> >
> > +static inline void
3.10.84-rt92-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Thomas Gleixner
Initializing a new slab can introduce rather large latencies because most
of the initialization runs always with interrupts disabled.
There is no point in doing so.
3.10.84-rt92-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Frederic Weisbecker
commit 3010279f0fc36f0388872203e63ca49912f648fd
From: Frederic Weisbecker
Date: Sat Aug 16 18:47:15 2014 +0200
x86: Tell irq work about self IPI support
x86
3.10.84-rt92-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: "Steven Rostedt (Red Hat)"
---
localversion-rt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/localversion-rt b/localversion-rt
index
On Fri, Aug 07, 2015 at 08:52:25PM +0300, Tal Shorer wrote:
> >From the usb 3.1 spec available at http://www.usb.org/developers/docs/
> table 10-7 (Hub Class Requests) specifies the values for SetHubDepth and
> GetPortErrorCount as:
>
> Request bmRequestType bRequest wValue wIndex wLength Data
>
Dear RT Folks,
This is the RT stable review cycle of patch 3.10.84-rt92-rc1.
Please scream at me if I messed something up. Please test the patches too.
The -rc release will be uploaded to kernel.org and will be deleted when
the final release is out. This is just a review release (or release
lzo1x_1_compress always returns LZO_E_OK that is equal to 0. Thus, the
check of the return value is useless.
Signed-off-by: Salah Triki
---
drivers/block/zram/zcomp_lzo.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/block/zram/zcomp_lzo.c
On Fri, Aug 07, 2015 at 08:52:25PM +0300, Tal Shorer wrote:
> >From the usb 3.1 spec available at http://www.usb.org/developers/docs/
> table 10-7 (Hub Class Requests) specifies the values for SetHubDepth and
> GetPortErrorCount as:
>
> Request bmRequestType bRequest wValue wIndex wLength Data
>
On Fri, Aug 07, 2015 at 11:50:04PM +0800, Feng Tang wrote:
> On Fri, Aug 07, 2015 at 04:48:28PM +0200, Michal Nazarewicz wrote:
> > On Fri, Aug 07 2015, Feng Tang wrote:
> > > As I described above, the dummy struct device is only needed for
> > > dma request, its lifetime is align with the
On Fri, Aug 07, 2015 at 12:45:53PM +0530, Sudip Mukherjee wrote:
> On Thu, Aug 06, 2015 at 07:28:12PM -0700, Greg Kroah-Hartman wrote:
> >
> >
> > On Sat, Aug 01, 2015 at 01:12:05PM +0800, kernel test robot wrote:
>
> > > [ 12.276231] RIP
> > > [ 12.276231] RIP []
* Russell King - ARM Linux | 2015-08-07 17:26:48 [+0100]:
>On Fri, Aug 07, 2015 at 05:36:05PM +0200, Sebastian Andrzej Siewior wrote:
>> +/*
>> + * We do not allow DMA_MEM_TO_DEV transfers to be paused.
>> + * According to RMK the OMAP hardware might prefetch
On Fri, Aug 07, 2015 at 10:41:57AM +0200, Sebastian Andrzej Siewior wrote:
> This DMA driver is used by 8250-omap on DRA7-evm. There is one
> requirement that is to pause a transfer. This is currently used on the RX
> side. It is possible that the UART HW aborted the RX (UART's RX-timeout)
> but
[Correcting the devicetree list address, which I typo'd in my original
reply]
[resending to _really_ correct the address, apologies for the spam]
> >> +static const char * const addr_propnames[] = {
> >> + "mac-address",
> >> + "local-mac-address",
> >> + "address",
> >> +};
> >
> > If these
On Fri, Aug 07, 2015 at 05:22:47PM +0800, Baolin Wang wrote:
> On 7 August 2015 at 17:07, Peter Chen wrote:
> >
> >> >> /**
> >> >> * struct usb_udc - describes one usb device controller @@ -127,12
> >> >> +128,45 @@ void usb_gadget_giveback_request(struct usb_ep *ep, }
> >> >>
>From the usb 3.1 spec available at http://www.usb.org/developers/docs/
table 10-7 (Hub Class Requests) specifies the values for SetHubDepth and
GetPortErrorCount as:
Request bmRequestType bRequest wValue wIndex wLength Data
SetHubDepth 0010B SET_HUB_DEPTH Hub Depth Zero Zero None
On Fri, Aug 07, 2015 at 04:19:40PM +0800, Baolin Wang wrote:
> On 7 August 2015 at 13:34, Peter Chen wrote:
> > On Thu, Aug 06, 2015 at 03:03:47PM +0800, Baolin Wang wrote:
> >> Currently the Linux kernel does not provide any standard integration of
> >> this
> >> feature that integrates the USB
[Correcting the devicetree list address, which I typo'd in my original
reply]
> >> +static const char * const addr_propnames[] = {
> >> + "mac-address",
> >> + "local-mac-address",
> >> + "address",
> >> +};
> >
> > If these are going to be generally necessary, then we should get them
> >
Thank you Matt for your help. I tried to find the cover letter
and patch 1, 2, 3 of the patch set. But I did not find them.
Probably the subject has typo? I appreciate that you re-post the
patch set to get more feed backs, I just wanted to be sure.
--
Jonathan (Zhixiong) Zhang
The Qualcomm
On Fri, Aug 07, 2015 at 01:23:20PM -0400, Peter Hurley wrote:
> The omap-serial driver which doesn't use dma is still the preferred
> stable driver for omap, for the moment.
>
> One of the main features of the 8250_omap integration was the addition
> of dma support. Without it, 8250_omap is ttyO
Thanks for the review, Ard. Comments inline below.
On 8/7/2015 2:00 AM, Ard Biesheuvel wrote:
On 6 August 2015 at 15:40, Jonathan (Zhixiong) Zhang
wrote:
From: "Jonathan (Zhixiong) Zhang"
Table 8 of UEFI 2.5 section 2.3.6.1 defines mappings from EFI
memory types to MAIR attribute encodings
On 08/07/2015 07:01 AM, Mark Rutland wrote:
On Fri, Aug 07, 2015 at 01:33:10AM +0100, David Daney wrote:
From: David Daney
Find out which PHYs belong to which BGX instance in the ACPI way.
Set the MAC address of the device as provided by ACPI tables. This is
similar to the implementation for
lzo1x_1_do_compress always returns LZO_E_OK. Thus, the check of the
return value is useless.
Signed-off-by: Salah Triki
---
drivers/base/regmap/regcache-lzo.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/base/regmap/regcache-lzo.c
On 08/07/2015 12:39 PM, Russell King - ARM Linux wrote:
> On Fri, Aug 07, 2015 at 05:44:03PM +0200, Sebastian Andrzej Siewior wrote:
>> On 08/07/2015 05:29 PM, Russell King - ARM Linux wrote:
>>> On Fri, Aug 07, 2015 at 11:08:48AM -0400, Peter Hurley wrote:
[ + Greg KH ]
On
The hypercall interface (as well as the toolstack) is always using 4KB
page granularity. When the toolstack is asking for mapping a series of
guest PFN in a batch, it expects to have the page map contiguously in
its virtual memory.
When Linux is using 64KB page granularity, the privcmd driver
All the ring (xenstore, and PV rings) are always based on the page
granularity of Xen.
Signed-off-by: Julien Grall
Reviewed-by: David Vrabel
Reviewed-by: Stefano Stabellini
---
Cc: Konrad Rzeszutek Wilk
Cc: Boris Ostrovsky
Changes in v3:
- Fix errors reported by checkpatch.pl
Only use the first 4KB of the page to store the events channel info. It
means that we will waste 60KB every time we allocate page for:
* control block: a page is allocating per CPU
* event array: a page is allocating everytime we need to expand it
I think we can reduce the memory waste
The PV block protocol is using 4KB page granularity. The goal of this
patch is to allow a Linux using 64KB page granularity behaving as a
block backend on a non-modified Xen.
It's only necessary to adapt the ring size and the number of request per
indirect frames. The rest of the code is relying
For ARM64 guests, Linux is able to support either 64K or 4K page
granularity. Although, the hypercall interface is always based on 4K
page granularity.
With 64K page granularity, a single page will be spread over multiple
Xen frame.
To avoid splitting the page into 4K frame, take advantage of
The hypercall interface is always using 4KB page granularity. This is
requiring to use xen page definition macro when we deal with hypercall.
Note that pfn_to_gfn is working with a Xen pfn (i.e 4KB). We may want to
rename pfn_gfn to make this explicit.
We also allocate a 64KB page for the shared
The PV block protocol is using 4KB page granularity. The goal of this
patch is to allow a Linux using 64KB page granularity using block
device on a non-modified Xen.
The block API is using segment which should at least be the size of a
Linux page. Therefore, the driver will have to break the page
The PV network protocol is using 4KB page granularity. The goal of this
patch is to allow a Linux using 64KB page granularity using network
device on a non-modified Xen.
It's only necessary to adapt the ring size and break skb data in small
chunk of 4KB. The rest of the code is relying on the
The console ring is always based on the page granularity of Xen.
Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
---
Cc: Greg Kroah-Hartman
Cc: Jiri Slaby
Cc: David Vrabel
Cc: Boris Ostrovsky
Cc: linuxppc-...@lists.ozlabs.org
Changes in v3:
- Some changes has been
The PV network protocol is using 4KB page granularity. The goal of this
patch is to allow a Linux using 64KB page granularity working as a
network backend on a non-modified Xen.
It's only necessary to adapt the ring size and break skb data in small
chunk of 4KB. The rest of the code is relying on
The Xen interface is using 4KB page granularity. This means that each
grant is 4KB.
The current implementation allocates a Linux page per grant. On Linux
using 64KB page granularity, only the first 4KB of the page will be
used.
We could decrease the memory wasted by sharing the page with
On Wednesday, August 05, 2015 11:31:15 PM Russell King - ARM Linux wrote:
> On Wed, Aug 05, 2015 at 08:44:11PM +0200, Matthias Brugger wrote:
> > On Tuesday, July 14, 2015 01:18:26 PM Yingjoe Chen wrote:
> > > This series add SMP brinup support for MediaTek SoCs. This is based
> > > on v4.2-rc1
On 07/08/15 17:46, Julien Grall wrote:
> Hi all,
>
> ARM64 Linux is supporting both 4KB and 64KB page granularity. Although, Xen
> hypercall interface and PV protocol are always based on 4KB page granularity.
>
> Any attempt to boot a Linux guest with 64KB pages enabled will result to a
> guest
The current semaphore code allows a potential use after free: in exit_sem we may
free the task's sem_undo_list while there is still another task looping through
the same semaphore set and cleaning the sem_undo list at freeary function (the
task called IPC_RMID for the same semaphore set).
For
On 08/07/2015 10:11 AM, Tomeu Vizoso wrote:
> On 6 August 2015 at 22:19, Rob Herring wrote:
>> On Thu, Aug 6, 2015 at 9:11 AM, Tomeu Vizoso
>> wrote:
>>> Delay matches of platform devices with OF nodes until late_initcall,
>>> when we are sure that all built-in drivers have been registered
Hello,
Alexander Duyck writes:
> On 08/07/2015 01:23 AM, Zang MingJie wrote:
>> IMO, the routing decision is determined, given a specific routing
>> table and local network the result MUST be determined, independence of
>> how/what order the routing entry is added.
>>
>> Now there are two ways
lzo1x_1_compress always returns LZO_E_OK that is equal to 0.
Signed-off-by: Salah Triki
---
drivers/block/zram/zcomp_lzo.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/block/zram/zcomp_lzo.c b/drivers/block/zram/zcomp_lzo.c
index da1bc47..3cf30c9 100644
---
On Thu, Aug 06, 2015 at 02:59:27PM -0600, Al Stone wrote:
> Now that we have introduced the bad_madt_entry() function, and that
> function is being invoked in acpi_table_parse_madt() for us, there
> is no longer any need to use the BAD_MADT_ENTRY macro, or in the case
> of arm64, the
This is v9 of the compile-time stack validation patch set, along with
proposed fixes for many of the warnings it found. It's based on the
tip/master branch.
The frame pointer macros have been renamed from FRAME/ENDFRAME to
FRAME_BEGIN/FRAME_END.
v8 can be found here:
Tell stackvalidate to skip validation of the following code:
- boot image
- vdso image
- kexec purgatory
- realmode
- efi libstub
They all run outside the kernel's normal mode of operation and they
don't affect runtime kernel stack traces, so they're free to skirt the
stackvalidate rules.
Add C versions of the frame pointer macros which can be used to create a
stack frame in inline assembly.
Signed-off-by: Josh Poimboeuf
---
arch/x86/include/asm/frame.h | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/frame.h
If a hypercall is inlined at the beginning of a function, gcc can insert
the call instruction before setting up a stack frame, which breaks frame
pointer convention if CONFIG_FRAME_POINTER is enabled and can result in
a bad stack trace.
Force a stack frame to be created if CONFIG_FRAME_POINTER is
A function created with the PV_CALLEE_SAVE_REGS_THUNK macro doesn't set
up a new stack frame before the call instruction, which breaks frame
pointer convention if CONFIG_FRAME_POINTER is enabled and can result in
a bad stack trace. Also, the thunk functions aren't annotated as ELF
callable
lzo1x_1_compress always LZO_E_OK that is equal to 0.
Signed-off-by: Salah Triki
---
drivers/block/zram/zcomp_lzo.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/block/zram/zcomp_lzo.c b/drivers/block/zram/zcomp_lzo.c
index da1bc47..3cf30c9 100644
---
swsusp_arch_suspend() and restore_registers() are callable non-leaf
functions which don't honor CONFIG_FRAME_POINTER, which can result in
bad stack traces. Also they aren't annotated as ELF callable functions
which can confuse tooling.
Create a stack frame for them when CONFIG_FRAME_POINTER is
rwsem.S has several callable non-leaf functions which don't honor
CONFIG_FRAME_POINTER, which can result in bad stack traces.
Create stack frames for them when CONFIG_FRAME_POINTER is enabled.
Signed-off-by: Josh Poimboeuf
---
arch/x86/lib/rwsem.S | 11 ++-
1 file changed, 10
stackvalidate reports the following warning:
stackvalidate: arch/x86/crypto/crc32c-pcl-intel-asm_64.o: crc_pcl()+0x11dd:
can't decode instruction
It gets confused when trying to decode jump_table data. Move jump_table
to the .rodata section which is a more appropriate home for read-only
do_suspend_lowlevel() is a callable non-leaf function which doesn't
honor CONFIG_FRAME_POINTER, which can result in bad stack traces.
Create a stack frame for it when CONFIG_FRAME_POINTER is enabled.
Signed-off-by: Josh Poimboeuf
Cc: "Rafael J. Wysocki"
Cc: Len Brown
Cc: Pavel Machek
---
stackvalidate reports the following false positive warnings:
stackvalidate: arch/x86/xen/enlighten.o: xen_cpuid()+0x41: can't find jump
dest instruction at .text+0x108
stackvalidate: arch/x86/xen/enlighten.o: xen_setup_gdt.constprop.23()+0x2e:
kernel entry/exit from callable instruction
efi_call() is a callable non-leaf function which doesn't honor
CONFIG_FRAME_POINTER, which can result in bad stack traces.
Create a stack frame for it when CONFIG_FRAME_POINTER is enabled.
Signed-off-by: Josh Poimboeuf
Cc: Matt Fleming
---
arch/x86/platform/efi/efi_stub_64.S | 3 +++
1 file
clmul_ghash_mul() and clmul_ghash_update() are callable non-leaf
functions which don't honor CONFIG_FRAME_POINTER, which can result in
bad stack traces.
Create stack frames for them when CONFIG_FRAME_POINTER is enabled.
Signed-off-by: Josh Poimboeuf
Cc: Herbert Xu
Cc: "David S. Miller"
---
stackvalidate reports the following warning:
stackvalidate: arch/x86/crypto/aesni-intel_asm.o: _aesni_inc_init(): can't
find starting instruction
stackvalidate gets confused when it tries to disassemble the following
data in the .text section:
.Lbswap_mask:
.byte 15, 14, 13, 12,
Thunk functions are callable non-leaf functions that don't honor
CONFIG_FRAME_POINTER, which can result in bad stack traces. Also they
aren't annotated as ELF callable functions which can confuse tooling.
Create stack frames for them when CONFIG_FRAME_POINTER is enabled and
add the ELF function
stackvalidate reports a false positive warning for the ljmp instruction
in machine_real_restart(). Normally, ljmp isn't allowed in a function,
but this is a special case where it's jumping into real mode.
Add the jumps to a whitelist which tells stackvalidate to ignore them.
Signed-off-by: Josh
If a PVOP call macro is inlined at the beginning of a function, gcc can
insert the call instruction before setting up a stack frame, which
breaks frame pointer convention if CONFIG_FRAME_POINTER is enabled and
can result in a bad stack trace.
Force a stack frame to be created if
The asm macros for setting up and restoring the frame pointer aren't
currently being used. However, they will be needed soon to help asm
functions to comply with stackvalidate.
Rename FRAME/ENDFRAME to FRAME_BEGIN/FRAME_END for more symmetry. Also
make the code more readable and improve the
This adds a CONFIG_STACK_VALIDATION option which enables a host tool
named stackvalidate which runs at compile time. It analyzes every .o
file and ensures the validity of its stack metadata. It enforces a set
of rules on asm code and C inline assembly code so that stack traces can
be reliable.
vide() is a callable function, but is missing the ELF function type,
which confuses tools like stackvalidate.
Properly annotate it to be a callable function. The generated code is
unchanged.
Signed-off-by: Josh Poimboeuf
---
arch/x86/kernel/cpu/amd.c | 5 -
1 file changed, 4
Add new stackvalidate ignore macros: STACKVALIDATE_IGNORE_INSN and
STACKVALIDATE_IGNORE_FUNC. These can be used to tell stackvalidate to
skip validation of an instruction or a function, respectively.
Signed-off-by: Josh Poimboeuf
---
arch/x86/include/asm/stackvalidate.h | 45
aesni-intel_asm.S has several callable non-leaf functions which don't
honor CONFIG_FRAME_POINTER, which can result in bad stack traces.
Create stack frames for them when CONFIG_FRAME_POINTER is enabled.
Signed-off-by: Josh Poimboeuf
Cc: Herbert Xu
Cc: "David S. Miller"
---
All the usage of the field pfn are done using the same idiom:
pfn_to_page(grant->pfn)
This will return always the same page. Store directly the page in the
grant to clean up the code.
Signed-off-by: Julien Grall
Acked-by: Roger Pau Monné
Reviewed-by: Stefano Stabellini
---
Cc: Konrad
The Xen hypercall interface is always using 4K page granularity on ARM
and x86 architecture.
With the incoming support of 64K page granularity for ARM64 guest, it
won't be possible to re-use the Linux page definition in Xen drivers.
Introduce Xen page definition helpers based on the Linux page
The skb doesn't change within the function. Therefore it's only
necessary to check if we need GSO once at the beginning.
Signed-off-by: Julien Grall
---
Cc: Ian Campbell
Cc: Wei Liu
Cc: net...@vger.kernel.org
Changes in v2:
- Patch added
---
drivers/net/xen-netback/netback.c |
Currently, a grant is always based on the Xen page granularity (i.e
4KB). When Linux is using a different page granularity, a single page
will be split between multiple grants.
The new helpers will be in charge to split the Linux page into grants and
call a function given by the caller on each
Hi all,
ARM64 Linux is supporting both 4KB and 64KB page granularity. Although, Xen
hypercall interface and PV protocol are always based on 4KB page granularity.
Any attempt to boot a Linux guest with 64KB pages enabled will result to a
guest crash.
This series is a first attempt to allow those
Currently, blkif_queue_request has 2 distinct execution path:
- Send a discard request
- Send a read/write request
The function is also allocating grants to use for generating the
request. Although, this is only used for read/write request.
Rather than having a function with 2 distinct
Prepare the code to support 64KB page granularity. The first
implementation will use a full Linux page per indirect and persistent
grant. When non-persistent grant is used, each page of a bio request
may be split in multiple grant.
Furthermore, the field page of the grant structure is only used
Many PV drivers contain the idiom:
pfn = page_to_gfn(...) /* Or similar */
gnttab_grant_foreign_access_ref
Replace it by a new helper. Note that when Linux is using a different
page granularity than Xen, the helper only gives access to the first 4KB
grant.
This is useful where drivers are
On ARM all dma-capable devices on a same platform may not be protected
by an IOMMU. The DMA requests have to use the BFN (i.e MFN on ARM) in
order to use correctly the device.
While the DOM0 memory is allocated in a 1:1 fashion (PFN == MFN), grant
mapping will screw this contiguous mapping.
When
They are not used in common code expect in one place in balloon.c which is
only compiled when Linux is using PV MMU. It's not the case on ARM.
Rather than worrying how to handle the 64KB case, drop them.
Signed-off-by: Julien Grall
---
Stefano Stabellini
Russell King
Changes in v3:
On Thu, Aug 6, 2015 at 10:43 AM, Ross Zwisler
wrote:
> Patch 5 adds support for the "read flush" _DSM flag, allowing us to change the
> ND BLK aperture mapping from write-combining to write-back via
> memremap_pmem().
>
> Patch 6 updates the DAX I/O path so that all operations that store data
On Fri, Aug 07, 2015 at 09:41:31AM -0700, Christoph Hellwig wrote:
> On Fri, Aug 07, 2015 at 01:14:15PM +0200, Peter Zijlstra wrote:
> > On that, we cannot convert completions to swait. Because swait wake_all
> > must not happen from IRQ context, and complete_all() typically is used
> > from just
On 08/07/2015 05:42 AM, Tomasz Nowicki wrote:
On 07.08.2015 13:56, Robert Richter wrote:
On 07.08.15 12:52:41, Tomasz Nowicki wrote:
[...]
I would not pollute bgx_probe() with acpi and dt specifics, and instead
keep bgx_init_phy(). The typical design pattern for this is:
static int
On Fri, Aug 07, 2015 at 01:14:15PM +0200, Peter Zijlstra wrote:
> On that, we cannot convert completions to swait. Because swait wake_all
> must not happen from IRQ context, and complete_all() typically is used
> from just that.
If swait queues aren't useable from IRQ context they will be fairly
HVM_PARAM_CONSOLE_PFN is used to retrieved the console PFN for HVM
guest. It returns a PFN (aka GFN) and not a MFN.
Furthermore, use directly virt_to_gfn for both PV and HVM domain rather
than doing a special case for each of the them.
Signed-off-by: Julien Grall
Reviewed-by: David Vrabel
---
The swiotlb is required when programming a DMA address on ARM when a
device is not protected by an IOMMU.
In this case, the DMA address should always be equal to the machine address.
For DOM0 memory, Xen ensure it by have an identity mapping between the
guest address and host address. However,
On Fri, Aug 07, 2015 at 05:44:03PM +0200, Sebastian Andrzej Siewior wrote:
> On 08/07/2015 05:29 PM, Russell King - ARM Linux wrote:
> > On Fri, Aug 07, 2015 at 11:08:48AM -0400, Peter Hurley wrote:
> >> [ + Greg KH ]
> >>
> >> On 08/07/2015 09:57 AM, Russell King - ARM Linux wrote:
> >>> As it is
The privcmd code is mixing the usage of GFN and MFN within the same
functions which make the code difficult to understand when you only work
with auto-translated guests.
The privcmd driver is only dealing with GFN so replace all the mention
of MFN into GFN.
The ioctl structure used to map
Hi all,
This patch series aims to use the memory terminologies described in
include/xen/mm.h [1] for Linux xen code.
The differences from v2 is minor but I resent it because my 64K series depends
on this series.
Linux is using mistakenly MFN when GFN is meant, I suspect this is because the
The variable xen_store_mfn is effectively storing a GFN and not an MFN.
Signed-off-by: Julien Grall
---
Cc: Konrad Rzeszutek Wilk
Cc: Boris Ostrovsky
Cc: David Vrabel
I think that the assignation of xen_start_info in
xenstored_local_init is pointless. Although I haven't drop it just
The PV driver xen-fbfront is only dealing with GFN and not MFN. Rename
all the occurence of MFN to GFN.
Also take the opportunity to replace to usage of pfn_to_gfn by
xen_page_to_gfn.
Signed-off-by: Julien Grall
Reviewed-by: David Vrabel
---
Cc: Jean-Christophe Plagniol-Villard
Cc: Tomi
Based on include/xen/mm.h [1], Linux is mistakenly using MFN when GFN
is meant, I suspect this is because the first support for Xen was for
PV. This resulted in some misimplementation of helpers on ARM and
confused developers about the expected behavior.
For instance, with pfn_to_mfn, we expect
ARM guests are always HVM. The current implementation is assuming a 1:1
mapping which is only true for DOM0 and may not be at all in the future.
Furthermore, all the helpers but arbitrary_virt_to_machine are used in
x86 specific code (or only compiled for).
The helper arbitrary_virt_to_machine
After the commit introducing convertion between DMA and guest addresses,
all the callers of pfn_to_mfn are expecting to get a GFN (Guest Frame
Number). On ARM, all the guests are auto-translated so the GFN is equal
to the Linux PFN (Pseudo-physical Frame Number).
The current implementation may
All the caller of xen_tmem_{get,put}_page have a struct page * in hand
and call pfn_to_gfn for the only benefits of these 2 functions.
Rather than passing the pfn in parameter, pass directly the page and use
directly xen_page_to_gfn.
Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
On Fri, Aug 07, 2015 at 06:20:44PM +0200, Sebastian Andrzej Siewior wrote:
> On 08/07/2015 06:07 PM, Peter Hurley wrote:
> >> If we look at what 8250-dma.c is doing:
> >>
> >> if (dma->rx_running) {
> >> dmaengine_pause(dma->rxchan);
> >>
> >> It's
On Fri, Aug 07, 2015 at 09:59:13AM +0200, Andrzej Hajda wrote:
> The patch was generated using fixed coccinelle semantic patch
> scripts/coccinelle/api/memdup.cocci [1].
>
> [1]: http://permalink.gmane.org/gmane.linux.kernel/2014320
I dropped this footnote from the commit message as it seems
On Fri, Aug 07, 2015 at 12:07:11PM -0400, Peter Hurley wrote:
> On 08/07/2015 11:29 AM, Russell King - ARM Linux wrote:
> > On Fri, Aug 07, 2015 at 11:08:48AM -0400, Peter Hurley wrote:
> >> [ + Greg KH ]
> >>
> >> On 08/07/2015 09:57 AM, Russell King - ARM Linux wrote:
> >>> As it is something
On Fri, Aug 7, 2015 at 9:18 AM, Srinivas Kandagatla
wrote:
> Thanks Kevin,
>
> On 07/08/15 17:13, Kevin Hilman wrote:
>>
>> Srinivas Kandagatla writes:
>>
>>> This patchset adds a new simple NVMEM framework to kernel, and it is
>>> tested
>>> with various drivers like "QCOM thermal sensors",
201 - 300 of 1784 matches
Mail list logo
