>>> On 05.11.12 at 03:19, Rusty Russell wrote:
> Jan Beulich writes:
>> @@ -54,6 +61,15 @@ struct pt_regs;
>> */
>> #ifndef __OPTIMIZE__
>> #define BUILD_BUG_ON(condition) ((void)sizeof(char[1 - 2*!!(condition)]))
>> +#elif __GNUC__ > 4 || (__GN
>>> On 02.11.12 at 20:19, Steven Rostedt wrote:
> @@ -1842,8 +1851,12 @@ nmi_swapgs:
> SWAPGS_UNSAFE_STACK
> nmi_restore:
> RESTORE_ALL 8
> +
> + /* Pop the extra iret frame */
> + addq $(5*8), %rsp
This could (for code efficiency) and should (for CFI annotation
correctness)
>>> On 02.11.12 at 22:32, Andrew Morton wrote:
> On Fri, 02 Nov 2012 14:44:08 +
> "Jan Beulich" wrote:
>
>> This is another step towards better standard conformance. Rather than
>> adding a local buffer to store the specified portion of the string
&
>>> On 02.11.12 at 18:30, "H. Peter Anvin" wrote:
> Aren't we actually talking just about PV here?
>
> If so the test is wrong.
No - this equally can affect "fully" virtualized guests (where the
CR0.TS accesses can involve VMEXIT-s).
Jan
> Jan Be
>>> On 25.07.12 at 18:57, "H. Peter Anvin" wrote:
> On 07/25/2012 12:59 AM, Jan Beulich wrote:
>>>
>>> should drop all phys_addr assignment in this function.
>>>
>>> x86_phys_bits should have all correct value?
>>
>> Is it cert
>>> On 26.07.12 at 17:33, Stefano Stabellini
>>> wrote:
> --- a/include/xen/interface/xen.h
> +++ b/include/xen/interface/xen.h
> @@ -10,7 +10,10 @@
> #define __XEN_PUBLIC_XEN_H__
>
> #include
> +#include
> +#ifdef CONFIG_X86
> #include
> +#endif
Rather than hacking around this, why not
>>> On 26.07.12 at 17:33, Stefano Stabellini
>>> wrote:
> --- a/drivers/xen/Makefile
> +++ b/drivers/xen/Makefile
> @@ -1,11 +1,15 @@
> -obj-y+= grant-table.o features.o events.o manage.o balloon.o
> +ifneq ($(CONFIG_ARM),y)
> +obj-y+= manage.o balloon.o
While I assume that this
>>> On 26.07.12 at 17:33, Stefano Stabellini
>>> wrote:
> In order for privcmd mmap to work correctly, xen_remap_domain_mfn_range
> needs to be implemented for HVM guests.
> If it is not, mmap is going to fail later on.
Somehow, for me at least, this description doesn't connect to the
actual cha
>>> On 26.07.12 at 22:43, Konrad Rzeszutek Wilk wrote:
> If we boot a 64-bit guest with more than 4GB memory, the SWIOTLB
> gets turned on:
> PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
> software IO TLB [mem 0xfb43d000-0xff43cfff] (64MB) mapped at
> [8800fb43d000-8800ff43cf
>>> On 26.07.12 at 22:47, Konrad Rzeszutek Wilk wrote:
> 2). Allocate a new array, copy the existing P2M into it,
> revector the P2M tree to use that, and return the old
> P2M to the memory allocate. This has the advantage that
> it sets the stage for using XEN_ELF_NOTE_INIT_P2M
>
>>> On 26.07.12 at 22:47, Konrad Rzeszutek Wilk wrote:
> After all, this is what it is there for.
>
> Signed-off-by: Konrad Rzeszutek Wilk
Acked-by: Jan Beulich
> ---
> arch/x86/xen/mmu.c | 13 ++---
> 1 files changed, 6 insertions(+), 7 deletions(-)
>
>>> On 27.07.12 at 12:00, Ian Campbell wrote:
> On Fri, 2012-07-27 at 08:34 +0100, Jan Beulich wrote:
>> >>> On 26.07.12 at 22:47, Konrad Rzeszutek Wilk
>> >>> wrote:
>> > 2). Allocate a new array, copy the existing P2M into it,
>> &g
>>> On 27.07.12 at 12:21, Ian Campbell wrote:
> I was actually think of the issue with 32 bit PV guests accessing MFN
> space > 160G, even if they are themselves small, which is a separate
> concern.
That can be made work if really needed, but not via the
mechanism we're talking about here. The q
>>> On 27.07.12 at 13:18, Stefano Stabellini
>>> wrote:
> On Thu, 26 Jul 2012, Konrad Rzeszutek Wilk wrote:
>> 1) All P2M lookups instead of using the __ka address would
>> use the __va address. This means we can safely erase from
>> __ka space the PMD pointers that point to the PFNs for
>>> On 27.07.12 at 19:54, Konrad Rzeszutek Wilk wrote:
> On Fri, Jul 27, 2012 at 08:27:39AM +0100, Jan Beulich wrote:
>> >>> On 26.07.12 at 22:43, Konrad Rzeszutek Wilk
>> >>> wrote:
>> > + /* Check if the user supplied the e820_hole parame
>>> On 27.07.12 at 19:34, Konrad Rzeszutek Wilk wrote:
> On Fri, Jul 27, 2012 at 12:47:47PM +0100, Jan Beulich wrote:
>> >>> On 27.07.12 at 13:18, Stefano Stabellini
>> >>>
> wrote:
>> > On Thu, 26 Jul 2012, Konrad Rzeszutek Wilk wrot
>>> On 31.07.12 at 18:15, Konrad Rzeszutek Wilk wrote:
> On Tue, Jul 31, 2012 at 08:49:21AM -0700, H. Peter Anvin wrote:
>> This means you're either abusing the brk allocator to do something
>> it is not meant to do... which may mean you can a failure in *other*
>> code, or you have a bug in your
>>> On 20.09.12 at 23:24, Konrad Rzeszutek Wilk wrote:
> On Thu, Sep 20, 2012 at 03:13:42PM +0100, Oliver Chick wrote:
>> On Thu, 2012-09-20 at 14:49 +0100, Konrad Rzeszutek Wilk wrote:
>> > On Thu, Sep 20, 2012 at 12:48:41PM +0100, Jan Beulich wrote:
>> > >
>>> On 21.09.12 at 10:41, Oliver Chick wrote:
> On Fri, 2012-09-21 at 08:18 +0100, Jan Beulich wrote:
>> >>> On 20.09.12 at 23:24, Konrad Rzeszutek Wilk
>> >>> wrote:
>> > On Thu, Sep 20, 2012 at 03:13:42PM +0100, Oliver Chick wrote:
>&g
>>> On 10.09.12 at 21:20, Suresh Siddha wrote:
> On Mon, 2012-09-10 at 13:37 +0100, Jan Beulich wrote:
>> 1: unify SSE-base xor-block routines
>> 2: improve XMM register spill/fill
>> 3: add alternative SSE implementation only prefetching once per 64-byte line
>
>>> On 21.09.12 at 17:52, Oliver Chick wrote:
> Changes since v1:
>
> * Maximum number of persistent grants per device now 64, rather than
>256, as this is the actual maxmimum request in a (1 page) ring.
As said previously, I don't see why this needs to have a separate
#define at all - it's
o not need to check for this a
second time.
Signed-off-by: Jan Beulich
---
drivers/xen/xen-pciback/pci_stub.c | 46 ++---
1 file changed, 23 insertions(+), 23 deletions(-)
--- 3.6-rc7/drivers/xen/xen-pciback/pci_stub.c
+++ 3.6-rc7-xen-pciback-find-error-paths/d
>>> On 26.09.12 at 08:15, Tao Guo wrote:
> gas in binutils(2.16.91) could not parse parentheses within macro
> parameters,
This description of yours contradicts the last hunk of the patch -
iirc the requirement for macro parameters in those old gas
versions is to be fully parenthesized if there's
>>> On 25.09.12 at 23:27, Konrad Rzeszutek Wilk wrote:
> We call 'pci_disable_device' which sets the bus_master to zero
> and it also disables the PCI_COMMAND. There is no need to
> do it outside the PCI library.
Not really - pci_disable_device() only does anything if enable_cnt
drops to zero, an
>>> On 26.09.12 at 10:28, Tao Guo wrote:
> gas in binutils(2.16.91) could not parse parentheses within macro
> parameters unless fully parenthesized, and this is a workaround to
> make old gas work without generating below errors:
> arch/x86/kernel/entry_64.S: Assembler messages:
> arch/x86/kernel
>>> On 26.09.12 at 13:16, Ingo Molnar wrote:
> * Jan Beulich wrote:
>
>> >>> On 26.09.12 at 10:28, Tao Guo wrote:
>> > gas in binutils(2.16.91) could not parse parentheses within macro
>> > parameters unless fully parenthesized, and this i
>>> On 30.10.12 at 16:47, Olaf Hering wrote:
> This is a respin of 00e37bdb0113a98408de42db85be002f21dbffd3
> ("xen PVonHVM: move shared_info to MMIO before kexec").
>
> Currently kexec in a PVonHVM guest fails with a triple fault because the
> new kernel overwrites the shared info page. The exac
>>> On 30.10.12 at 17:30, Olaf Hering wrote:
> On Tue, Oct 30, Jan Beulich wrote:
>
>> >>> On 30.10.12 at 16:47, Olaf Hering wrote:
>> > This is a respin of 00e37bdb0113a98408de42db85be002f21dbffd3
>> > ("xen PVonHVM: move shared_info to
>>> On 30.10.12 at 18:03, Olaf Hering wrote:
> On Tue, Oct 30, Jan Beulich wrote:
>
>> And iirc you're doing this relocation because otherwise the newly
>> booting kernel image may get overwritten at an (from its
>> perspective) arbitrary location. What
>>> On 30.10.12 at 16:44, Konrad Rzeszutek Wilk wrote:
> On Mon, Oct 29, 2012 at 10:08:17AM -0400, Konrad Rzeszutek Wilk wrote:
>> From: Jan Beulich
>>
>> While copying the argument structures in HYPERVISOR_event_channel_op()
>> and HYPERVISOR_phy
>>> On 27.08.13 at 01:42, "K. Y. Srinivasan" wrote:
> Hyper-V supports a mechanism for retrieving the local API frequency.
"APIC"?
> @@ -27,6 +27,13 @@
> #define HV_X64_MSR_VP_RUNTIME_AVAILABLE (1 << 0)
> /* Partition Reference Counter (HV_X64_MSR_TIME_REF_COUNT) available*/
> #d
>>> On 29.08.13 at 04:52, Zhenzhong Duan wrote:
> But in initial domain (aka priviliged guest), it's different.
> Driver init call graph under initial domain:
> driver_init->
> msix_capability_init->
> msix_program_entries->
> msix_mask_irq->
> entry->masked
>>> On 29.08.13 at 11:50, Zhenzhong Duan wrote:
> On 2013-08-29 15:23, Jan Beulich wrote:
>>>>> On 29.08.13 at 04:52, Zhenzhong Duan wrote:
>>> But in initial domain (aka priviliged guest), it's different.
>>> Driver ini
>>> On 09.07.13 at 02:26, Konrad Rzeszutek Wilk wrote:
> Could you explain to me please why the check in the scripts is superfluous?
This is not really the question - _any_ such check can only be
wrong. The boot loader has absolutely no business caring about
kernel internals, and the kernel shoul
>>> On 09.07.13 at 16:48, Konrad Rzeszutek Wilk wrote:
> Dom0 has been both - but there is nothing wrong with seperating these
> two labels. And therein I was thinking that the 'hardware backend domain'
> should be the introduced. I am not good with names so the best option
> seems CONFIG_XEN_PRIV
>>> On 03.09.13 at 20:30, "K. Y. Srinivasan" wrote:
> @@ -76,6 +80,26 @@ static void __init ms_hyperv_init_platform(void)
> printk(KERN_INFO "HyperV: features 0x%x, hints 0x%x\n",
> ms_hyperv.features, ms_hyperv.hints);
>
> + if (ms_hyperv.features & HV_X64_MSR_APIC_FREQUE
>>> On 06.09.13 at 16:00, Konrad Rzeszutek Wilk wrote:
> We have already exported 'get_phys_to_machine' and there are
> third-party drivers that depend on this other symbol. As such
> lets make this balanced and also export this symbol.
I tend to disagree: Allowing external modules read access to
>>> On 06.09.13 at 16:39, Konrad Rzeszutek Wilk wrote:
> On Fri, Sep 06, 2013 at 03:06:02PM +0100, Jan Beulich wrote:
>> >>> On 06.09.13 at 16:00, Konrad Rzeszutek Wilk
>> >>> wrote:
>> > We have already exported 'get_phys_to_machine
>>> On 10.09.13 at 15:42, Ingo Molnar wrote:
> * Peter Zijlstra wrote:
>
>> +.macro SAVE_ALL
>> +pushl_cfi %eax
>> +CFI_REL_OFFSET eax, 0
>> +pushl_cfi %ebp
>> +CFI_REL_OFFSET ebp, 0
>> +pushl_cfi %edi
>> +CFI_REL_OFFSET edi, 0
>> +pushl_cfi %esi
>> +CFI_REL_
>>> On 10.09.13 at 17:31, Boris Ostrovsky wrote:
> --- a/drivers/xen/Kconfig
> +++ b/drivers/xen/Kconfig
> @@ -242,4 +242,9 @@ config XEN_MCE_LOG
> config XEN_HAVE_PVMMU
> bool
>
> +config XEN_SYMS
> + bool "Xen symbols"
> + depends on XEN_DOM0 && XENFS && KALLSYMS
> +
>>> On 11.09.13 at 22:18, Kees Cook wrote:
> On Wed, Sep 11, 2013 at 1:06 PM, Joe Perches wrote:
>> On Wed, 2013-09-11 at 12:30 -0700, Kees Cook wrote:
>>> The %n format is not ignored, so remove the incorrect comment about it.
>>
>> I think it may be better to reimplement the ignoring.
>
> Yeah
>>> On 12.09.13 at 09:31, Kees Cook wrote:
> On Thu, Sep 12, 2013 at 12:03 AM, Jan Beulich wrote:
>>>>> On 11.09.13 at 22:18, Kees Cook wrote:
>>> On Wed, Sep 11, 2013 at 1:06 PM, Joe Perches wrote:
>>>> On Wed, 2013-09-11 at 12:30 -0700, Kees Co
>>> On 13.09.13 at 03:43, KY Srinivasan wrote:
>
>> -Original Message-
>> From: H. Peter Anvin [mailto:h...@zytor.com]
>> Sent: Thursday, September 12, 2013 5:28 PM
>> To: KY Srinivasan
>> Cc: x...@kernel.org; gre...@linuxfoundation.org;
>> linux-kernel@vger.kernel.org;
>> de...@linuxdr
>>> On 25.09.13 at 21:29, Konrad Rzeszutek Wilk wrote:
> Jan Beulich spotted that the PAT MSR settings in the Xen public
> document that "the first (PAT6) column was wrong across the
> board, and the column for PAT7 was missing altogether."
>
> This updates it
>>> On 06.09.12 at 15:15, Matt Fleming wrote:
> From: Matt Fleming
>
> Some firmware still needs a 1:1 (virt->phys) mapping even after we've
> called SetVirtualAddressMap(). So install the mapping alongside our
> existing kernel mapping whenever we make EFI calls in virtual mode.
>
> This bug w
.
Signed-off-by: Jan Beulich
---
arch/x86/Kconfig.cpu |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- 3.6-rc4/arch/x86/Kconfig.cpu
+++ 3.6-rc4-x86-minimum-cpu-family/arch/x86/Kconfig.cpu
@@ -409,9 +409,9 @@ config X86_CMOV
config X86_MINIMUM_CPU_FAMILY
int
to distinguish the case of the fine grained flushing being
disabled).
Signed-off-by: Jan Beulich
Cc: Alex Shi
---
arch/x86/mm/tlb.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- 3.6-rc4/arch/x86/mm/tlb.c
+++ 3.6-rc4-x86-tlb_flushall_shift-limits/arch/x86/mm/tlb.c
@@ -320,7 +
>>> On 07.09.12 at 07:37, Alex Shi wrote:
> @@ -1113,7 +1114,10 @@ const struct cpumask *uv_flush_tlb_others(const struct
> cpumask *cpumask,
>
> record_send_statistics(stat, locals, hubs, remotes, bau_desc);
>
> - bau_desc->payload.address = start;
> + if (!end)
So despite hav
>>> On 06.09.12 at 17:47, Matt Fleming wrote:
> On Thu, 2012-09-06 at 15:34 +0100, Jan Beulich wrote:
>> >>> On 06.09.12 at 15:15, Matt Fleming wrote:
>> > + __flush_tlb_all();
>>
>> Is it certain you will _never_ hit a global mapping (in which c
>>> On 07.09.12 at 09:16, "H. Peter Anvin" wrote:
> On 09/06/2012 11:48 PM, Jan Beulich wrote:
>>
>> --- 3.6-rc4/arch/x86/Kconfig.cpu
>> +++ 3.6-rc4-x86-minimum-cpu-family/arch/x86/Kconfig.cpu
>> @@ -409,9 +409,9 @@ config X86_CMOV
>> confi
>>> On 07.09.12 at 09:31, Jan Beulich wrote:
>>>> On 07.09.12 at 09:16, "H. Peter Anvin" wrote:
> > Erk, this isn't right either. We're not supposed to include
> > CPUID-enumerable features here, so X86_CMOV, X86_CMPXCHG64 and X86_TSC
>
>>> On 06.09.12 at 19:07, "H. Peter Anvin" wrote:
> Anyone care to refresh my memory why we can't use the "global"
> 1:1+kernel map, possibly with some improvements (which would benefit the
> users of those maps too)? With that I mean initial_page_map on i386 and
> trampoline_pgd on x86-64...
>>> On 06.09.12 at 17:47, Matt Fleming wrote:
> On Thu, 2012-09-06 at 15:34 +0100, Jan Beulich wrote:
>> >>> On 06.09.12 at 15:15, Matt Fleming wrote:
>> > +
>> > + pgd += i;
>> > + save[i] = *pgd;
>> > +
>>> On 07.09.12 at 13:40, Stefan Bader wrote:
> When writing unsupported flags into CR4 (for some time the
> xen_write_cr4 function would refuse to do anything at all)
> older Xen hypervisors (and patch can potentially be improved
> by finding out what older means in version numbers) would
> crash
>>> On 07.09.12 at 15:21, Stefan Bader wrote:
> On 07.09.2012 14:33, Jan Beulich wrote:
>>>>> On 07.09.12 at 13:40, Stefan Bader wrote:
>>> When writing unsupported flags into CR4 (for some time the
>>> xen_write_cr4 function would refuse to do an
>>> On 07.09.12 at 16:22, "Justin M. Forbes" wrote:
> On Fri, Sep 07, 2012 at 03:02:29PM +0100, Jan Beulich wrote:
>> >>> On 07.09.12 at 15:21, Stefan Bader wrote:
>> > On 07.09.2012 14:33, Jan Beulich wrote:
>> >>>>> On 07.0
>>> On 07.09.12 at 17:47, Stefan Bader wrote:
> On 07.09.2012 17:44, Jan Beulich wrote:
>> All of this still doesn't provide evidence that a plain upstream
>> kernel is actually having any problems in the first place. Further,
>> if you say EC2 has a crippl
The 64-bit special cases of the former two (the thrird one is 64-bit
only anyway) don't need to use "long" temporaries, as the result will
always fit in a 32-bit variable, and the functions return plain "int".
This avoids a few REX prefixes, i.e. minimally reduces code
have worse performance than BSF.
For the moment, only do this when the respective generic-CPU option is
selected (as there are no specific-CPU options covering the CPUs
supporting TZCNT), and don't do that when size optimization was
requested.
Signed-off-by: Jan Beulich
---
arch/x86/includ
make
...oldconfig" rather than keeping the previously invisible option
disabled.
There's a little bit of other trivial cleanup mixed in here.
Signed-off-by: Jan Beulich
---
arch/x86/Kconfig | 50 ++
arch/x86/Kconfig.cpu |5 +++-
el one.
Signed-off-by: Jan Beulich
Cc: Don Zickus
Cc: Peter Zijlstra
---
lib/Kconfig.debug |9 +
1 file changed, 5 insertions(+), 4 deletions(-)
--- 3.6-rc5/lib/Kconfig.debug
+++ 3.6-rc5-kconfig-cleanup-hardlockup/lib/Kconfig.debug
@@ -196,12 +196,13 @@ config LOCKUP_DETECTOR
space: Use "depends on" rather than directly setting the default from
the combined dependency values.
Signed-off-by: Jan Beulich
---
kernel/Kconfig.locks | 103 +++
1 file changed, 63 insertions(+), 40 deletions(-)
--- 3.6-rc5/kernel/Kco
Allow particularly do_xor_speed() to be discarded post-init.
Signed-off-by: Jan Beulich
---
crypto/xor.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- 3.6-rc5/crypto/xor.c
+++ 3.6-rc5-sections-xor/crypto/xor.c
@@ -56,11 +56,11 @@ xor_blocks(unsigned int src_count, unsig
Without ARCH_REQUIRE_GPIOLIB there's no reason to force this code, when
enabled, to always be built into the kernel, which requires only minor
Makefile and source code adjustments.
Signed-off-by: Jan Beulich
---
drivers/gpio/Kconfig |2 +-
drivers/gpio/Makefile |
1: unify SSE-base xor-block routines
2: improve XMM register spill/fill
3: add alternative SSE implementation only prefetching once per 64-byte line
4: make virtualization friendly
Signed-off-by: Jan Beulich
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" i
Besides folding duplicate code, this has the advantage of fixing
x86-64's failure to use proper (para-virtualizable) accessors for
dealing with CR0.TS.
Signed-off-by: Jan Beulich
---
arch/x86/include/asm/xor.h| 351 +-
arch/x86/include/asm/xor
Provided a new enough gcc is in use, we can avoid using the potentially
much slower MOVUPS by making sure stack frame and spilled to variables
are suitably aligned.
Signed-off-by: Jan Beulich
---
arch/x86/include/asm/xor.h | 56 -
1 file changed
On CPUs with 64-byte last level cache lines, the yields roughly 10%
better performance, independent of CPU vendor or specific model (as far
as I was able to test).
Signed-off-by: Jan Beulich
---
arch/x86/include/asm/xor.h| 176 ++
arch/x86/include
in that case.
For consistency, pull into the shared (32- and 64-bit) header not only
the inclusion of the generic code, but also that of the AVX variants.
Signed-off-by: Jan Beulich
Cc: Konrad Rzeszutek Wilk
---
arch/x86/include/asm/xor.h|8 +++-
arch/x86/include/asm/xor_32.h
>>> On 10.09.12 at 16:05, "H. Peter Anvin" wrote:
> On 09/10/2012 05:38 AM, Jan Beulich wrote:
>> +/*
>> + * By forcing the alignment beyond the default of 16 bytes, we make the
>> + * compiler guarantee the alignment. Passing -mincoming-stack-boundary=3
>>> "H. Peter Anvin" 10/05/12 6:28 PM >>>
>On 10/04/2012 11:39 PM, Jan Beulich wrote:
>>>
>>> We should have the check, but at least for Linux support we require
>>> P <= V-2.
>>
>> Not really imo - P <= V - 1 should be
entual further adjustments to the patch
we're discussing here.
Jan
>Jan Beulich wrote:
>
>>>On 10/04/2012 11:39 PM, Jan Beulich wrote:
>>I understand all that, but here we're talking about a true 1:1 mapping
>>(i.e. in the lower half of the virtual address space)
>>> On 03.12.12 at 20:32, Olaf Hering wrote:
> be->mode is obtained from xenbus_read, which does a kmalloc for the
> message body. The short string is never released, so do it on blkbk
> remove.
>
> Signed-off-by: Olaf Hering
> ---
>
> !! Not compile tested !!
>
> drivers/block/xen-blkback/xe
>>> On 04.12.12 at 19:21, Olaf Hering wrote:
> On Tue, Dec 04, Jan Beulich wrote:
>
>> This looks necessary but insufficient - there's nothing really
>> preventing backend_changed() from being called more than once
>> for a given device (is simply the hand
>>> On 05.12.12 at 11:01, Olaf Hering wrote:
> backend_changed might be called multiple times, which will leak
> be->mode. free the previous value before storing the current mode value.
As said before - this is one possible route to take. But did you
consider at all the alternative of preventing
>>> On 06.12.12 at 14:08, Dongxiao Xu wrote:
> While mapping sg buffers, checking to cross page DMA buffer is
> also needed. If the guest DMA buffer crosses page boundary, Xen
> should exchange contiguous memory for it.
>
> Besides, it is needed to backup the original page contents
> and copy it
>>> On 06.12.12 at 17:23, Olaf Hering wrote:
> On Wed, Dec 05, Jan Beulich wrote:
>
>> >>> On 05.12.12 at 11:01, Olaf Hering wrote:
>> > backend_changed might be called multiple times, which will leak
>> > be->mode. free the previous value be
>>> On 12.12.12 at 02:03, "Xu, Dongxiao" wrote:
>> From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
>> On Tue, Dec 11, 2012 at 06:39:35AM +, Xu, Dongxiao wrote:
>> > > From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
>> > > What if this check was done in the routines that
>>> On 11.12.12 at 21:50, Olaf Hering wrote:
> backend_changed might be called multiple times, which will leak
> be->mode. Make sure it will be called only once. Remove some unneeded
> checks. Also the be->mode string was leaked, release the memory on
> device shutdown.
So did I miss some discuss
>>> On 12.12.12 at 10:47, Olaf Hering wrote:
> On Wed, Dec 12, Jan Beulich wrote:
>
>> >>> On 11.12.12 at 21:50, Olaf Hering wrote:
>> > backend_changed might be called multiple times, which will leak
>> > be->mode. Make sure it will be calle
>>> On 13.11.12 at 05:39, Andrew Cooks wrote:
> config PCI_IOAPIC turned into a tristate in commit
> b95a7bd700466c10fda84acbd33f70cf66ec91ce, but no module license is specified.
> This adds the missing module license.
>
> Signed-off-by: Andrew Cooks
Acked-by: Jan Be
>>> On 15.11.12 at 03:19, Mukesh Rathor wrote:
> PVH: remove macro FEATURES_PVH and put PVH strings in the ELFNOTE line,
> because there's a null char before FEATURES_PVH and in the FEATURES_PVH
> strings since this is not C file
>
> Signed-off-by: Mukesh Rathor
> ---
> arch/x86/xen/xen-head.
>>> On 06.11.12 at 02:51, Rusty Russell wrote:
> Andrew Morton writes:
>
>> On Fri, 02 Nov 2012 14:47:40 +
>> "Jan Beulich" wrote:
>>
>>> This makes the resulting diagnostics quite a bit more useful.
>>
>> So asserts Jan, but
>>> On 07.11.12 at 02:03, Rusty Russell wrote:
> Jan Beulich writes:
>>>>> On 06.11.12 at 02:51, Rusty Russell wrote:
>>> Yeah, there are a lot of goodies here:
>>>
>>> _Static_assert:
>>> We could define __ASSERT_ST
>>> On 07.11.12 at 08:19, Ian Campbell wrote:
> On Tue, 2012-11-06 at 22:13 +, Konrad Rzeszutek Wilk wrote:
>> As there is no need for it (the fallback code is for older
>> hypervisors and they won't run under ARM),
>
> I think more specifically they won't run on anything other than x86.
>
>>> On 07.11.12 at 19:14, Matthew Fioravante
>>> wrote:
> On 11/07/2012 09:46 AM, Kent Yoder wrote:
>>> --- a/drivers/char/tpm/tpm.h
>>> +++ b/drivers/char/tpm/tpm.h
>>> @@ -130,6 +130,9 @@ struct tpm_chip {
>>>
>>> struct list_head list;
>>> void (*release) (struct device *);
>>> +#if CO
>>> Rik van Riel 12/27/12 4:01 PM >>>
>On 12/27/2012 09:27 AM, Eric Dumazet wrote:
>> So the hash sounds good to me, because the hash key could mix both lock
>> address and caller IP ( __builtin_return_address(1) in
>> ticket_spin_lock_wait())
>
>The lock acquisition time depends on the holder of
>>> On 27.12.12 at 20:09, Rik van Riel wrote:
> On 12/27/2012 01:41 PM, Jan Beulich wrote:
>>>>> Rik van Riel 12/27/12 4:01 PM >>>
>>> On 12/27/2012 09:27 AM, Eric Dumazet wrote:
>>>> So the hash sounds good to me, because th
>>> On 02.01.13 at 12:26, Andrew Cooper wrote:
> On 27/12/12 18:02, Eric W. Biederman wrote:
>> It probably make sense to split them apart a little even.
>
> Thinking about this split, there might be a way to simply it even more.
>
> /sbin/kexec can load the "Xen" crash kernel itself by issuing
>>> On 27.12.12 at 03:18, Daniel Kiper wrote:
> Some implementations (e.g. Xen PVOPS) could not use part of identity page
> table
> to construct transition page table. It means that they require separate
> PUDs,
> PMDs and PTEs for virtual and physical (identity) mapping. To satisfy that
> requi
>>> On 04.01.13 at 15:22, Daniel Kiper wrote:
> On Wed, Jan 02, 2013 at 11:26:43AM +, Andrew Cooper wrote:
>> /sbin/kexec can load the "Xen" crash kernel itself by issuing
>> hypercalls using /dev/xen/privcmd. This would remove the need for
>> the dom0 kernel to distinguish between loading a
>>> On 04.01.13 at 16:15, Daniel Kiper wrote:
> On Thu, Jan 03, 2013 at 09:34:55AM +, Jan Beulich wrote:
>> >>> On 27.12.12 at 03:18, Daniel Kiper wrote:
>> > Some implementations (e.g. Xen PVOPS) could not use part of identity page
> table
>> &
>>> On 17.12.12 at 18:15, "H. Peter Anvin" wrote:
> On 12/17/2012 09:03 AM, Jan Beulich wrote:
>>>>> On 17.12.12 at 17:39, "H. Peter Anvin" wrote:
>>> Right, I think you nailed this one. This patch copies PTEs from the
>>> kern
>>> On 20.12.12 at 02:23, "Xu, Dongxiao" wrote:
> Sorry, maybe I am still not describing this issue clearly.
No, at least I understood you the way you re-describe below.
> Take the libata case as an example, the static DMA buffer locates
> (dev->link->ap->sector_buf , here we use Data Structure
made it
desirable to slightly re-structure that function, so that the error
cleanup can be done in one place).
Reported-by: Olaf Hering
Signed-off-by: Jan Beulich
---
drivers/block/xen-blkback/xenbus.c | 49 ++---
1 file changed, 24 insertions(+), 25 deletions(-)
>>> On 20.11.12 at 16:04, Daniel Kiper wrote:
> Some implementations (e.g. Xen PVOPS) could not use part of identity page
> table
> to construct transition page table. It means that they require separate
> PUDs,
> PMDs and PTEs for virtual and physical (identity) mapping. To satisfy that
> requi
>>> On 17.04.13 at 12:16, "Michael S. Tsirkin" wrote:
> If the hypervisor says it's Hyper-V, that's because it wants
> guests to use Hyper-V. I don't see why is guest second-guessing
> this a good idea.
There are two reasons here: For one, when the hypervisor is not
Hyper-V, but is providing some
>>> On 17.04.13 at 15:20, KY Srinivasan wrote:
> If I recall correctly, the issue here was that Xen was enabling Hyper-V
> emulation un-conditionally even for Linux guests.
To make this a little more precise - Xen is doing so only when the
guest config tells it to.
Jan
--
To unsubscribe from t
>>> On 17.04.13 at 15:01, "Michael S. Tsirkin" wrote:
> On Wed, Apr 17, 2013 at 02:52:42PM +0100, Jan Beulich wrote:
>> >>> On 17.04.13 at 15:20, KY Srinivasan wrote:
>> > If I recall correctly, the issue here was that Xen was enabling Hyper-V
>>> On 17.04.13 at 17:31, KY Srinivasan wrote:
> If Xen were to change where it would not unconditionally emulate Hyper-V, I
> would not be opposed to taking
> this check out.
But it doesn't do this unconditionally, only upon admin request.
Jan
--
To unsubscribe from this list: send the line "
101 - 200 of 1374 matches
Mail list logo
