... to match the function's parameters. While reportedly commutative,
using the proper order allows for leveraging the instruction permitting
the source operand to be in memory.
Signed-off-by: Jan Beulich
Acked-by: Daniel Borkmann
Cc: Francesco Fusco
Cc: Thomas Graf
Cc: David S. M
- simplify switch statement
- add __init annotation to setup_arch_fast_hash()
Signed-off-by: Jan Beulich
Cc: Francesco Fusco
Cc: Daniel Borkmann
Cc: Thomas Graf
Cc: David S. Miller
---
arch/x86/lib/hash.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
--- 3.14-rc4-x86
>>> On 17.03.14 at 17:55, "H. Peter Anvin" wrote:
> On 03/17/2014 05:19 AM, George Dunlap wrote:
>> On Mon, Mar 17, 2014 at 3:33 AM, H. Peter Anvin wrote:
>>> No, the right thing is to unf*ck the Xen braindamage and use eagerfpu as a
> workaround for the legacy hypervisor versions.
>>
>> The in
1: fix build failure with older binutils
2: swap parameters of crc32_u32()
3: cleanup
Signed-off-by: Jan Beulich
Cc: Francesco Fusco
Cc: Daniel Borkmann
Cc: Thomas Graf
Cc: David S. Miller
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
1: fix build failure with older binutils
2: swap parameters of crc32_u32()
3: cleanup
Signed-off-by: Jan Beulich
Cc: Francesco Fusco
Cc: Daniel Borkmann
Cc: Thomas Graf
Cc: David S. Miller
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
... to match its two callers (i.e. the alternative would have been to
swap the arguments at the call sites).
Signed-off-by: Jan Beulich
Cc: Francesco Fusco
Cc: Daniel Borkmann
Cc: Thomas Graf
Cc: David S. Miller
---
arch/x86/lib/hash.c |2 +-
1 file changed, 1 insertion(+), 1 deletion
Just like for other ISA extension instruction uses we should check
whether the assembler actually supports them. The fallback here simply
is to encode an instruction with fixed operands (%eax and %ecx).
Signed-off-by: Jan Beulich
Cc: Francesco Fusco
Cc: Daniel Borkmann
Cc: Thomas Graf
Cc
- simplify switch statement
- add __init annotation to setup_arch_fast_hash()
Signed-off-by: Jan Beulich
Cc: Francesco Fusco
Cc: Daniel Borkmann
Cc: Thomas Graf
Cc: David S. Miller
---
arch/x86/lib/hash.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
--- 3.14-rc3-x86
>>> On 21.02.14 at 13:51, "H. Peter Anvin" wrote:
> How old?
2.16.91.0.5 (SLE10)
Jan
> On February 21, 2014 2:32:50 AM PST, Jan Beulich wrote:
>>Just like for other ISA extension instruction uses we should check
>>whether the assembler actually supports t
>>> On 31.12.13 at 15:51, Konrad Rzeszutek Wilk wrote:
> On Thu, Dec 05, 2013 at 07:34:05PM +0800, Yijing Wang wrote:
>> Use PCI standard marco dev_is_pci() instead of directly compare
>> pci_bus_type to check whether it is pci device.
>
> Jan, you OK with this?
Yes, sure - I simply wasn't aware
>>> On 25.11.13 at 23:13, Andrew Morton wrote:
> On Mon, 25 Nov 2013 16:22:31 + "Jan Beulich" wrote:
>
>> Commit fad1a86e ("procfs: call default get_unmapped_area on MMU-present
>> architectures"), as its title says, took care of only the
>>> On 27.11.13 at 15:03, Ingo Molnar wrote:
> * Jan Beulich wrote:
>
>> As discussed in the context of commits 3df7b41a ("x86: Unify
>> copy_from_user() size checking") and 7a3d9b0f ("x86: Unify
>> copy_to_user() and add size checking to it
>>> On 13.01.14 at 11:14, Olaf Hering wrote:
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -1634,37 +1634,22 @@ blkfront_closing(struct blkfront_info *info)
>
> static void blkfront_setup_discard(struct blkfront_info *info)
> {
> - int err;
> - char *ty
>>> On 13.01.14 at 13:01, Olaf Hering wrote:
> On Mon, Jan 13, Jan Beulich wrote:
>
>> You can't do this in one go - the first two and the last one may be
>> set independently (and are independent in their meaning), and
>> hence need to be queried independ
>>> On 13.01.14 at 14:00, Ian Campbell wrote:
> On Mon, 2014-01-13 at 12:34 +, Jan Beulich wrote:
>> >>> On 13.01.14 at 13:01, Olaf Hering wrote:
>> > On Mon, Jan 13, Jan Beulich wrote:
>> >
>> >> You can't do this in one go -
>>> On 13.01.14 at 14:45, David Vrabel wrote:
> On 13/01/14 13:16, Jan Beulich wrote:
>>>>> On 13.01.14 at 14:00, Ian Campbell wrote:
>>> On Mon, 2014-01-13 at 12:34 +, Jan Beulich wrote:
>>>>>>> On 13.01.14 at 13:01, Ol
"ret", being set to -1 early on, gets cleared by the first invocation
of lz4_decompress()/lz4_decompress_unknownoutputsize(), and hence
subsequent failures wouldn't be noticed by the caller without setting
it back to -1 right after those calls.
Reported-by: Matthew Daley
Sig
>>> On 11.11.13 at 03:49, Kyungsik Lee wrote:
> Hello Jan,
>
> Thanks for the patch.
>
> On Fri, Nov 08, 2013 at 09:27:09AM +, Jan Beulich wrote:
>> "ret", being set to -1 early on, gets cleared by the first invocation
>> of lz4_decompress()
>>> On 11.11.13 at 14:02, Kyungsik Lee wrote:
> On Mon, Nov 11, 2013 at 08:35:31AM +, Jan Beulich wrote:
>> >>> On 11.11.13 at 03:49, Kyungsik Lee wrote:
>> > Hello Jan,
>> >
>> > Thanks for the patch.
>> >
>> >
e.com/mmap-for-proc-vmcore-broken-since-3-12-rc1-td729326.html.
Signed-off-by: Jan Beulich
Cc: Andrew Morton
Cc: Alexey Dobriyan
---
fs/proc/inode.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
--- 3.12-rc5/fs/proc/inode.c
+++ 3.12-rc5-proc-get-unmapped-area/fs/proc/inode.c
GCC 4.6+") was really necessary,
and instead this should have been dealt with as is done here from the
beginning.
It also puzzles me that similar checking isn't done for copy_to_user():
While not resulting in (kernel) buffer overflows, size mistakes there
would still lead to information
We shouldn't be creating a corresponding platform device in that case.
Signed-off-by: Jan Beulich
---
arch/x86/kernel/rtc.c |5 +
1 file changed, 5 insertions(+)
--- 3.12-rc5/arch/x86/kernel/rtc.c
+++ 3.12-rc5-x86-ACPI-no-RTC/arch/x86/kernel/rtc.c
@@ -192,6 +192,11 @@ static _
it to the
correct internal header (instead of it being declared in one included
by [almost] everyone).
Signed-off-by: Jan Beulich
---
arch/x86/include/asm/fpu-internal.h |5 -
arch/x86/include/asm/processor.h|1 -
arch/x86/kernel/process.c |6 --
3 files
e on Intel CPUs (intel.c's
instance was lacking the sentinel with family being zero), so the
patch bumps that by one,
- c_models' vendor sub-field was unused (and anyway redundant with
the base structure's c_x86_vendor field), so the patch deletes it.
Signed-off-by: Jan Beulich
save operation could be another [F]XSAVE, but on all
systems I measured this on using FNSTENV turned out to be the faster
alternative.
Signed-off-by: Jan Beulich
---
arch/x86/include/asm/cpufeature.h |1
arch/x86/include/asm/fpu-internal.h | 77 +
arch/x86/include/asm/proces
>>> On 16.10.13 at 16:00, Arjan van de Ven wrote:
>> +static inline unsigned long __must_check copy_from_user(void *to,
>> + const void __user *from,
>> + unsigned long n)
>> +{
>> +int sz = __compiletime_object_size(to)
>>> On 16.10.13 at 17:19, Linus Torvalds wrote:
> On Wed, Oct 16, 2013 at 5:00 AM, Jan Beulich wrote:
>>
>> The basic idea here is to either use a priori information on the
>> intended state layout (in the case of 32-bit processes) or "sense" the
>>
>>> On 16.10.13 at 17:39, "H. Peter Anvin" wrote:
> On 10/16/2013 05:00 AM, Jan Beulich wrote:
>> Having had reports of certain Windows versions, when put in some
>> special driver verification mode, blue-screening due to the FPU state
>> having changed
>>> On 16.10.13 at 17:50, Linus Torvalds wrote:
> On Wed, Oct 16, 2013 at 8:36 AM, Jan Beulich wrote:
>>
>> In that case we use a 32-bit operand size [F]XRSTOR, and hence
>> the upper halves get treated as selectors, and the offsets get
>> zero-extended from t
>>> On 16.10.13 at 20:43, Linus Torvalds wrote:
> So having looked at this some more, I would *really* prefer a
> different solution. The overwriting of the rip/rdp data just really
> annoys me.
>
> Is there any reason to not just do it like the following instead:
>
> - get rid of the "word_siz
>>> On 16.10.13 at 22:40, Andrew Morton wrote:
> On Wed, 16 Oct 2013 12:32:40 +0100 "Jan Beulich" wrote:
>
>> Commit c4fe24485729fc2cbff324c111e67a1cc2f9adea ("sparc: fix PCI device
>> proc file mmap(2)"), while fixing one problem, introduced two n
>>> On 17.10.13 at 10:36, HATAYAMA Daisuke wrote:
> (2013/10/17 16:23), Jan Beulich wrote:
>>>>> On 16.10.13 at 22:40, Andrew Morton wrote:
>>> On Wed, 16 Oct 2013 12:32:40 +0100 "Jan Beulich" wrote:
>>>
>>>> Commit c4fe24485729
>>> On 17.10.13 at 11:27, Gleb Natapov wrote:
> On Wed, Oct 16, 2013 at 05:13:40PM +0100, Jan Beulich wrote:
>> > It preserves *less* state, because the upper 32 bits of rip are now
>> > corrupted. Any 64-bit application that actually looks at the FP
>> >
>>> On 16.10.13 at 19:05, Arjan van de Ven wrote:
>>> if you have found cases where this matters... maybe you found a new security
>>> issue...
>>
>> Iirc I could convince myself that in the cited cases the warnings
>> were there for no reason.
>
> can you pick one on a source level ?
> (and the
>>> On 17.10.13 at 11:41, Gleb Natapov wrote:
> On Thu, Oct 17, 2013 at 10:33:33AM +0100, Jan Beulich wrote:
>> >>> On 17.10.13 at 11:27, Gleb Natapov wrote:
>> > On Wed, Oct 16, 2013 at 05:13:40PM +0100, Jan Beulich wrote:
>> >> > It preserves
>>> On 17.10.13 at 12:23, Gleb Natapov wrote:
> On Thu, Oct 17, 2013 at 10:51:52AM +0100, Jan Beulich wrote:
>> >>> On 17.10.13 at 11:41, Gleb Natapov wrote:
>> > KVM obviously knows the complete state of virtual CPU. It can figure the
>> > situatio
>>> On 17.10.13 at 17:45, Arjan van de Ven wrote:
> for me, the value of the feature overall is this range checking, not the
> fixed size part.
> for fixed size... the chance of the programmer getting it wrong is near
> zero.
> the chance of getting one of the checks wrong is much higher
> (we'v
>>> On 17.10.13 at 18:04, Arjan van de Ven wrote:
>>
>> ... and the non-constant case be taken care of at run time.
>> That's precisely what the patch does.
>
> fair enough.
>
> I would like to see a comment above the code to describe this reasoning
> and the objective and what the desired beha
>>> On 18.10.13 at 08:29, Ingo Molnar wrote:
> * Jan Beulich wrote:
>
>> We shouldn't be creating a corresponding platform device in that case.
>
> There's a sad lack of context in the changelog, how was it found, does
> this address any problem/bu
>>> On 20.11.13 at 09:52, Bob Liu wrote:
> @@ -100,9 +100,6 @@ static inline int xen_tmem_op(u32 tmem_cmd, u32
> tmem_pool, struct tmem_oid oid,
> op.u.gen.oid[1] = oid.oid[1];
> op.u.gen.oid[2] = oid.oid[2];
> op.u.gen.index = index;
> - op.u.gen.tmem_offset = tmem_offset;
>>> On 20.11.13 at 10:22, Bob Liu wrote:
> On 11/20/2013 05:10 PM, Jan Beulich wrote:
>>>>> On 20.11.13 at 09:52, Bob Liu wrote:
>>> @@ -100,9 +100,6 @@ static inline int xen_tmem_op(u32 tmem_cmd, u32
> tmem_pool, struct tmem_oid oid,
>>> op.u
ing another model of copy_*_user() verification
we can't replace the global definition. Do it in the (only) header
needing the construct for now.
Signed-off-by: Jan Beulich
Cc: Arjan van de Ven
Cc: Guenter Roeck
---
arch/x86/include/asm/uaccess.h |6 ++
1 file changed, 6 insertions(
Commit fad1a86e ("procfs: call default get_unmapped_area on MMU-present
architectures"), as its title says, took care of only the MMU case,
leaving the !MMU side still in the regressed state (returning -EIO in
all cases where pde->proc_fops->get_unmapped_area is NULL).
Signed-off
>>> On 26.10.13 at 12:31, Ingo Molnar wrote:
> * Jan Beulich wrote:
>> I'd like to point out though that with __compiletime_object_size()
>> being restricted to gcc before 4.6, the whole construct is going to
>> become more and more pointless going forwar
>>> On 26.10.13 at 00:08, Bjorn Helgaas wrote:
> On Fri, Oct 25, 2013 at 9:03 AM, Konrad Rzeszutek Wilk
> wrote:
>> + unsigned long pfn, start, end, ok_pfns;
>> + char bus_addr[64];
>> + char *fmt;
>> +
>> + if (!pci_resource_len(pci_dev, i
>>> On 28.10.13 at 17:58, Konrad Rzeszutek Wilk wrote:
> On Fri, Oct 25, 2013 at 04:08:19PM -0600, Bjorn Helgaas wrote:
>> If you can look at PCI host bridge apertures instead of BARs, that
>> would solve both problems. Reassigning those apertures is
>> theoretically possible but is not even a gl
>>> On 28.10.13 at 19:01, Vladimir 'f-coder/phcoder'
>>> Serbinenko wrote:
Will a multiboot2 tag with whole EFI memory map solve your problem?
>>> I added such a tag in documentation and wrote a patch for it (attached).
>>> Awaiting for someone to test it to commit
>>
>> Great! I think from
>>> On 26.10.13 at 12:31, Ingo Molnar wrote:
> * Jan Beulich wrote:
>> I'd like to point out though that with __compiletime_object_size()
>> being restricted to gcc before 4.6, the whole construct is going to
>> become more and more pointless going forwar
>>> On 29.10.13 at 10:54, Ingo Molnar wrote:
> * Jan Beulich wrote:
>
>> >>> On 26.10.13 at 12:31, Ingo Molnar wrote:
>> > * Jan Beulich wrote:
>> >> I'd like to point out though that with __compiletime_object_size()
>> >>
>>> On 29.10.13 at 15:45, Konrad Rzeszutek Wilk wrote:
> On Tue, Oct 29, 2013 at 08:23:30AM +, Jan Beulich wrote:
>> >>> On 28.10.13 at 17:58, Konrad Rzeszutek Wilk
>> >>> wrote:
>> > On Fri, Oct 25, 2013 at 04:08:19PM -0600, Bjorn Helg
>>> On 29.10.13 at 16:11, Konrad Rzeszutek Wilk wrote:
> On Tue, Oct 29, 2013 at 02:55:13PM +, Jan Beulich wrote:
>> >>> On 29.10.13 at 15:45, Konrad Rzeszutek Wilk
>> >>> wrote:
>> > On Tue, Oct 29, 2013 at 08:23:30AM +, Jan Be
>>> On 30.10.13 at 01:50, Zoltan Kiss wrote:
> @@ -119,13 +126,22 @@ struct xenvif {
> pending_ring_idx_t pending_cons;
> u16 pending_ring[MAX_PENDING_REQS];
> struct pending_tx_info pending_tx_info[MAX_PENDING_REQS];
> + grant_handle_t grant_tx_handle[MAX_PENDING_REQS];
>
>>> On 30.10.13 at 01:50, Zoltan Kiss wrote:
> These became obsolate with grant mapping.
I didn't look at this in detail, but I'm surprised you can get away
without any copying: For one, the header part needs copying
anyway, so you'd pointlessly map and then copy it if it's small
enough. And seco
>>> On 03.12.13 at 12:05, Ian Campbell wrote:
> On Tue, 2013-12-03 at 11:57 +0100, Roger Pau Monne wrote:
>> Using __packed__ on the public interface is not correct, this
>> structures should be compiled using the native ABI, and __packed__
>> should only be used in the backend counterpart of thos
>>> On 03.12.13 at 11:57, Roger Pau Monne wrote:
> struct blkif_request_rw {
> uint8_tnr_segments; /* number of segments */
> blkif_vdev_t handle; /* only for read/write requests */
> -#ifdef CONFIG_X86_64
> - uint32_t _pad1;
>>> On 03.12.13 at 16:09, Julien Grall wrote:
> --- a/include/xen/interface/io/blkif.h
> +++ b/include/xen/interface/io/blkif.h
> @@ -146,7 +146,7 @@ struct blkif_request_segment_aligned {
> struct blkif_request_rw {
> uint8_tnr_segments; /* number of segments */
lacing found_psdev->dev.
> This will also make it easier in the patch:
> "xen/pciback: When reconfiguring an PCIe device, FLR it"
> and "xen/pciback: PCI reset slot or bus" to use it.
>
> Signed-off-by: Konrad Rzeszutek Wilk
Apart from the above,
Reviewed-by: J
nrad Rzeszutek Wilk
Reviewed-by: Jan Beulich
> ---
> drivers/xen/xen-pciback/pci_stub.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/xen/xen-pciback/pci_stub.c
> b/drivers/xen/xen-pciback/pci_stub.c
> index 5300a21..36dd4f3 100644
>
>>> On 13.12.13 at 17:09, Konrad Rzeszutek Wilk wrote:
> When the toolstack wants us to drop or add an PCI device it
> changes the XenBus state to Configuring - and as result of that
> we find out which devices we should still be exporting out and
> which ones not. For the ones we don't need anymo
>>> On 13.12.13 at 17:09, Konrad Rzeszutek Wilk wrote:
> +void pcistub_reset_pci_dev(struct pci_dev *dev)
> +{
> + /* This is OK - we are running from workqueue context
> + * and want to inhibit the user from fiddling with 'reset'
> + */
> +
> + dev_dbg(&dev->dev, "resetting (FLR
ild logic so that the bad dependency gets avoided.
Signed-off-by: Jan Beulich
Cc: Matt Fleming
Cc: Ingo Molnar
---
drivers/acpi/Kconfig |1 -
drivers/acpi/apei/Kconfig |1 -
drivers/firmware/Makefile |1 +
drivers/firmware/efi/Kconfig |6 +++---
drivers/firmware/
>>> On 17.12.13 at 00:04, "Luck, Tony" wrote:
>> Adjust Kconfig and build logic so that the bad dependency gets avoided.
>
> Has this been exposed to a randconfig test robot? Moving cper.c has already
> dropped a few e-mails into my mailbox ... I'm now wary about the corner
> cases.
No, it ha
>>> On 22.04.14 at 20:34, wrote:
> With this patch:
> [...]
> And with an HVM guest poking at the rest of VCPUOPs: VCPUOP_get_physid,
> VCPUOP_initialise, and VCPUOP_send_nmi - either before the CPU is up or
> when it is up - work.
>
> That is: the VCPUOP_get_physid would return -EINVAL; VCPUOP_
>>> On 31.07.14 at 15:16, wrote:
> Add a RESTRICT ioctl to /dev/xen/privcmd, which allows privileged commands
> file descriptor to be restricted to only working with a particular domain.
The "with" here has been quite confusing, and I realized that you
mean the subject domain rather than the acto
>>> On 17.09.14 at 16:07, wrote:
> On 17/09/14 05:12, Juergen Gross wrote:
>> +static void __init xen_cleanmfnmap(unsigned long vaddr)
>> +{
>> +unsigned long va = vaddr & PMD_MASK;
>> +unsigned long pa;
>> +pgd_t *pgd = pgd_offset_k(va);
>> +pud_t *pud_page = pud_offset(pgd, 0);
>
- don't include unneeded headers
- don't open-code PER_CPU_VAR()
- drop redundant entry point label
- complete unwind annotations
- use .L prefix on local label to not clutter the symbol table
Signed-off-by: Jan Beulich
---
arch/x86/lib/cmpxchg16b_em
- don't include unneeded headers
- drop redundant entry point label
- complete unwind annotations
- use .L prefix on local labels to not clutter the symbol table
Signed-off-by: Jan Beulich
---
arch/x86/lib/cmpxchg8b_emu.S | 20 +---
1 file changed, 9 insertions(+
Signed-off-by: Jan Beulich
---
arch/x86/lib/thunk_32.S | 21 +++--
1 file changed, 15 insertions(+), 6 deletions(-)
--- 3.17-rc6/arch/x86/lib/thunk_32.S
+++ 3.17-rc6-ix86-annotate-thunks/arch/x86/lib/thunk_32.S
@@ -6,22 +6,31 @@
*/
#include
#include
>>> On 29.09.14 at 06:32, wrote:
> On 09/26/2014 06:38 PM, Chen Gang wrote:
>> When failure occurs, after xenbus_dev_error(), need go to fail to let
>> upper caller know about it.
>>
>> Signed-off-by: Chen Gang
>> ---
>> drivers/xen/xen-scsiback.c | 4 +++-
>> 1 file changed, 3 insertions(+),
Andy
following e6577a7ce9 ("x86, vdso: Move the vvar area before the
vdso text") gcc 4.3.4 tells me
.../arch/x86/vdso/vdso2c.c: In function ‘main’:
.../arch/x86/vdso/vdso2c.h:118: warning: assuming signed overflow does not
occur when assuming that (X + c) < X is
always false
.../arch/x86/vdso/vd
/pci/irq.c:1259: error: implicit declaration of function
‘mp_should_keep_irq’
make[3]: *** [arch/x86/pci/irq.o] Error 1
Move them to better places.
Signed-off-by: Jan Beulich
Cc: Jiang Liu
---
arch/x86/include/asm/io_apic.h |2 --
arch/x86/include/asm/pci_x86.h |2 ++
arch/x86/k
>>> On 28.04.14 at 22:50, wrote:
>>> > There's a enable_pci_io_ecs() which enables ECS through the NB_CFG MSR
>>> > which is called as part of the notifier *and* there's a PCI write to
>>> > that same bit in pci_enable_pci_io_ecs() which iterates over all NBs.
>>> >
>>> > So, AFAICT, we do it twic
>>> On 16.05.14 at 22:41, wrote:
> @@ -457,6 +460,21 @@ void __init efi_free_boot_services(void)
> efi_unmap_memmap();
> }
>
> +static void __init __iomem *efi_early_ioremap(resource_size_t phys_addr,
> + unsigned long size)
> +{
> +
>>> On 16.05.14 at 22:41, wrote:
> --- a/drivers/xen/Kconfig
> +++ b/drivers/xen/Kconfig
> @@ -240,4 +240,7 @@ config XEN_MCE_LOG
> config XEN_HAVE_PVMMU
> bool
>
> +config XEN_EFI
> + def_bool X86_64 && EFI
Constructs like this are bogus - they needlessly add a line to .config
whe
1999-2002 Hewlett-Packard Co.
>> + * David Mosberger-Tang
>> + * Stephane Eranian
>> + * Copyright (C) 2005-2008 Intel Co.
>> + * Fenghua Yu
>> + * Bibo Mao
>> + * Chandramouli Narayanan
>> + * Huang Ying
>> + * Copyright (C) 2011 Novell C
>>> On 19.05.14 at 22:46, wrote:
> On Mon, May 19, 2014 at 02:30:45PM +0100, Jan Beulich wrote:
>> >>> On 16.05.14 at 22:41, wrote:
>> > @@ -457,6 +460,21 @@ void __init efi_free_boot_services(void)
>> >efi_unmap_memmap();
>> > }
&g
>>> On 20.05.14 at 13:29, wrote:
> On Tue, May 20, 2014 at 10:47:00AM +0100, David Vrabel wrote:
>> On 16/05/14 21:41, Daniel Kiper wrote:
>> > @@ -1714,6 +1725,21 @@ asmlinkage __visible void __init
>> > xen_start_kernel(void)
>> >
>> >xen_setup_runstate_info(0);
>> >
>> > + efi_systab_xen
>>> On 15.02.14 at 15:02, Petr Tesarik wrote:
> --- a/arch/x86/kernel/smpboot.c
> +++ b/arch/x86/kernel/smpboot.c
> @@ -1226,9 +1226,6 @@ __init void prefill_possible_map(void)
> #ifdef CONFIG_HOTPLUG_CPU
> if (setup_max_cpus)
> possible += disabled_cpus;
> -#e
>>> On 30.04.14 at 15:54, wrote:
> When the device is de-assigned from a guest (but still owned
> by xen-pciback) we would needlessly free all of its dynamic
> entries.
I wonder whether that isn't intentional - dynamic fields are only
being used for what comes through the "quirks" attribute.
> -
>>> On 08.04.14 at 19:25, wrote:
> + /* Only Xen 4.5 and higher supports this. */
> + if (HYPERVISOR_vcpu_op(VCPUOP_is_up, smp_processor_id(), NULL) ==
> -ENOSYS)
> + vcpuops = false;
Did you mean to say "for HVM guests" in the comment? And of
course the comment could quickly
>>> On 08.04.14 at 19:25, wrote:
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -3470,6 +3470,9 @@ static long hvm_vcpu_op(
> case VCPUOP_stop_singleshot_timer:
> case VCPUOP_register_vcpu_info:
> case VCPUOP_register_vcpu_time_memory_area:
> +case VCPUOP_dow
>>> On 09.04.14 at 12:15, wrote:
> On Apr 9, 2014 4:03 AM, Jan Beulich wrote:
>>
>> >>> On 08.04.14 at 19:25, wrote:
>> > + /* Only Xen 4.5 and higher supports this. */
>> > + if (HYPERVISOR_vcpu_op(VCPUOP_is_up, smp_processor_id(), NULL)
>>> On 09.04.14 at 16:06, wrote:
> --- a/arch/x86/xen/xen-asm_32.S
> +++ b/arch/x86/xen/xen-asm_32.S
> @@ -88,7 +88,11 @@ ENTRY(xen_iret)
>* avoid having to reload %fs
>*/
> #ifdef CONFIG_SMP
> + pushw %fs
> + movl $(__KERNEL_PERCPU), %eax
> + movl %eax, %fs
> GE
>>> On 09.04.14 at 16:41, wrote:
> The latter load however can easy fault; The arguments for %ds in
> XSA-42/ CVE-2013-0228 applies to %{e,f,g}s as well.
And it was only that latter operation that I pointed at.
> Furthermore, I am a little concerned about the performance impact of
> this. I wo
>>> On 09.04.14 at 17:27, wrote:
> On Wed, Apr 09, 2014 at 10:06:12AM +0100, Jan Beulich wrote:
>> >>> On 08.04.14 at 19:25, wrote:
>> > --- a/xen/arch/x86/hvm/hvm.c
>> > +++ b/xen/arch/x86/hvm/hvm.c
>> > @@ -3470,6 +3470,9 @@ static long hv
>>> On 09.04.14 at 17:38, wrote:
> On 04/09/2014 11:01 AM, Jan Beulich wrote:
>>>>> On 09.04.14 at 16:41, wrote:
>>> The latter load however can easy fault; The arguments for %ds in
>>> XSA-42/ CVE-2013-0228 applies to %{e,f,g}s as well.
>> And
>>> On 25.03.14 at 21:57, wrote:
> Export arch_tables variable. Xen init function calls efi_config_init()
> which takes it as an argument.
>
> Additionally, put __initdata in place suggested by include/linux/init.h.
Which isn't necessarily the most appropriate place.
> --- a/arch/x86/platform/e
>>> On 26.03.14 at 14:00, wrote:
> On Tue, 25 Mar, at 09:57:54PM, Daniel Kiper wrote:
>> Call efi_memblock_x86_reserve_range() on native EFI platform only.
>> This is not needed and even it should not be called on platforms
>> which wraps EFI infrastructure like Xen.
>>
>> Signed-off-by: Daniel K
>>> On 25.03.14 at 21:57, wrote:
> Define EFI related stuff for Xen.
>
> This patch is based on Jan Beulich and Tang Liang work.
And with this, ...
> Signed-off-by: Daniel Kiper
> Signed-off-by: Tang Liang
> Signed-off-by: Jan Beulich
... these should be in t
>>> On 26.03.14 at 14:12, wrote:
> On Tue, 25 Mar, at 09:57:56PM, Daniel Kiper wrote:
>> +static void __init efi_init_xen(void)
>> +{
>> +efi_char16_t vendor_c16[100];
>> +char vendor[ARRAY_SIZE(vendor_c16)];
>> +int ret, i;
>> +struct xen_platform_op op;
>> +union xenpf_efi_in
>>> On 26.03.14 at 14:31, wrote:
> On Wed, 26 Mar, at 01:22:49PM, Jan Beulich wrote:
>> >>> On 26.03.14 at 14:00, wrote:
>> >
>> > This could do with a little bit more explanation. Why is it not
>> > necessary to mark the EFI memory map that
>>> On 26.03.14 at 15:08, wrote:
> On Wed, Mar 26, 2014 at 01:21:19PM +, Jan Beulich wrote:
>> >>> On 25.03.14 at 21:57, wrote:
>> > Export arch_tables variable. Xen init function calls efi_config_init()
>> > which takes it as an argument.
&g
>>> On 26.03.14 at 15:58, wrote:
>> +struct xenpf_efi_runtime_call {
>> +uint32_t function;
>> +/*
>> + * This field is generally used for per sub-function flags (defined
>> + * below), except for the XEN_EFI_get_next_high_monotonic_count case,
>> + * where it holds the single
>>> On 12.04.14 at 07:56, wrote:
> --- a/arch/x86/kernel/i8259.c
> +++ b/arch/x86/kernel/i8259.c
> @@ -299,11 +299,30 @@ static void unmask_8259A(void)
> static void init_8259A(int auto_eoi)
> {
> unsigned long flags;
> + unsigned char probe_val = ~(1 << PIC_CASCADE_IR);
> + unsign
>>> On 18.06.14 at 15:52, wrote:
> EFI_PARAVIRT will be usable by architectures other than x86, correct? If
> your intention is for it only ever to be used by x86, then it should
> probably be EFI_ARCH_2.
I would expect ARM, once it gets UEFI support on the Xen side, to
be able to handle most of
>>> On 04.07.14 at 15:01, wrote:
>>>> On 04.07.14 at 08:12, Jan Beulich wrote:
> >>>> On 04.07.14 at 01:11, wrote:
> > > From: Greg Kroah-Hartman
> > >
> > > Jan points out that I forgot to make the needed fixes to the
> >
Certain ld versions (observed with 2.20.0) put an empty .rela.dyn
section into shared object files, breaking the assumption on the number
of sections to be copied to the final output. Simply discard any empty
SHT_REL and SHT_RELA sections to address this.
Signed-off-by: Jan Beulich
Cc: Andy
align_vdso_addr() causes the build to fail.
Signed-off-by: Jan Beulich
Cc: Andy Lutomirski
---
arch/x86/vdso/vma.c|4
1 file changed, 4 insertions(+)
--- 3.16-rc3/arch/x86/vdso/vma.c
+++ 3.16-rc3-x86-vdso-build/arch/x86/vdso/vma.c
@@ -62,6 +62,9 @@ struct linux_binprm;
Only
>>> On 03.07.14 at 17:34, wrote:
> On Thu, Jul 3, 2014 at 7:35 AM, Jan Beulich wrote:
>> Relying on static functions used just once to get inlined (and
>> subsequently have dead code paths eliminated) is wrong: Compilers are
>> free to decide whether they do th
>>> On 04.07.14 at 01:11, wrote:
> From: Greg Kroah-Hartman
>
> Jan points out that I forgot to make the needed fixes to the
> lz4_uncompress_unknownoutputsize() function to mirror the changes done
> in lz4_decompress() with regards to potential pointer overflows.
Except that meanwhile Don agre
801 - 900 of 1374 matches
Mail list logo
