The symbol was missing a KVM dependency.
Signed-off-by: Jan Beulich
---
virt/kvm/Kconfig |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- 4.3-rc6/virt/kvm/Kconfig
+++ 4.3-rc6-KVM_COMPAT-dependency/virt/kvm/Kconfig
@@ -46,4 +46,4 @@ config KVM_GENERIC_DIRTYLOG_READ_PROTECT
config
>>> On 02.02.15 at 22:06, wrote:
> I applied this to pci/msi for v3.20, thanks! I reworked the changelog as
> follows; let me know if it still doesn't make things clear:
Thanks, looks good to me now.
Jan
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message
>>> On 29.01.15 at 04:54, wrote:
> --- a/drivers/pci/msi.c
> +++ b/drivers/pci/msi.c
> @@ -694,11 +694,16 @@ static void __iomem *msix_map_region(struct pci_dev
> *dev, unsigned nr_entries)
> {
> resource_size_t phys_addr;
> u32 table_offset;
> + unsigned long flags;
> u8 b
>>> On 27.01.15 at 02:51, wrote:
Even if David told you this would be acceptable, I have to question
an abstract model of fixing issues on only 64-bit kernels - this may
be acceptable for distro purposes, but seems hardly the right
approach for upstream. If 32-bit ones are to become deliberately
>>> On 23.01.15 at 19:58, wrote:
> On Fri, Jan 23, 2015 at 11:45:06AM +, David Vrabel wrote:
>> On 23/01/15 00:29, Luis R. Rodriguez wrote:
>> > @@ -1243,6 +1247,25 @@ void xen_evtchn_do_upcall(struct pt_regs *regs)
>> >set_irq_regs(old_regs);
>> > }
>> >
>> > +/*
>> > + * CONFIG_PREEMP
>>> On 16.01.14 at 17:04, Julian Stecklina
>>> wrote:
> On 01/16/2014 04:04 PM, Jan Beulich wrote:
>> I don't think so - this would only be an issue if the conditions used
>> | instead of ||. || implies a sequence point between evaluating the
>> left
>>> On 16.01.14 at 15:13, Julian Stecklina
>>> wrote:
> The paravirtualized clock used in KVM and Xen uses a version field to
> allow the guest to see when the shared data structure is inconsistent.
> The code reads the version field twice (before and after the data
> structure is copied) and che
>>> 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 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 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 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 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 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: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
>>
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 07.05.12 at 19:25, Ingo Molnar wrote:
(apologies for the late reply, the mail just now made it to my inbox
via xen-devel)
> I'll hold off on the whole thing - frankly, we don't want this
> kind of Xen-only complexity. If KVM can make use of PLE then Xen
> ought to be able to do it as we
>>> On 28.09.11 at 17:38, Linus Torvalds wrote:
> On Tue, Sep 27, 2011 at 9:44 AM, Jeremy Fitzhardinge wrote:
>>
>> I guess it comes down to throwing myself on the efficiency of some kind
>> of fence instruction. I guess an lfence would be sufficient; is that
>> any more efficient than a full mf
17 matches
Mail list logo
