> > +/*
> > + * clamp_t - return a value clamped to a given range using a given
> > +type
> > + * @type: the type of variable to use
> > + * @val: current value
> > + * @lo: minimum allowable value
> > + * @hi: maximum allowable value
> > + *
> > + * This macro does no typechecking and uses tempora
On 07/24/2015 06:44 PM, Boris Ostrovsky wrote:
On 07/24/2015 12:39 PM, Juergen Gross wrote:
I don't say mangling cpuids can't solve the scheduling problem. It
surely can. But it can't solve the scheduling problem without hiding
information like number of sockets or cores which might be require
On 07/24/2015 06:40 PM, Boris Ostrovsky wrote:
On 07/24/2015 12:10 PM, Juergen Gross wrote:
If we can fiddle with the masks on boot, we could do it in a running
system, too. Another advantage with not relying on cpuid. :-)
I am trying to catch up with this thread so I may have missed it, but
flight 59965 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/59965/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-i386 12 guest-saverestore fail REGR. vs. 59059
test-amd64-i386-xl-
Xen's raw SYSCALL entries are much less weird than native. Rather
than fudging them to look like native entries, use the Xen-provided
stack frame directly.
This lets us eliminate entry_SYSCALL_64_after_swapgs and two uses
of the SWAPGS_UNSAFE_STACK paravirt hook.
Signed-off-by: Andy Lutomirski
Xen currently fudges RSP on SYSCALL to be compatible with the native
entries. This has the unfortunate side effect that there are extra
poorly-controlled places with user RSP. Add better entry points for
Xen to use instead.
This will add a couple of cycles of IRQ latency, but it avoids an
annoyi
Xen's SYSCALL hooks are overcomplicated and add unnecessary places
where RSP is user controlled. Simplify it and get rid of those user
RSP code paths under Xen.
Tested as an Intel KVM guest. Not tested under Xen or on AMD, both
of which are important.
Andy Lutomirski (2):
x86/entry/64: Rearra
On Sun, Jul 26, 2015 at 4:05 PM, Andrew Cooper
wrote:
> On 26/07/2015 23:08, Andy Lutomirski wrote:
>>
If so, can we just
enter later on:
pushq%r11/* pt_regs->flags */
pushq$__USER_CS/* pt_regs->cs */
pushq%rcx
On 26/07/2015 23:08, Andy Lutomirski wrote:
>
>>> If so, can we just
>>> enter later on:
>>>
>>> pushq%r11/* pt_regs->flags */
>>> pushq$__USER_CS/* pt_regs->cs */
>>> pushq%rcx/* pt_regs->ip */
>>>
>>> <-- Xen enters here
>>>
>>
On Sun, Jul 26, 2015 at 12:34 PM, Andrew Cooper
wrote:
> On 23/07/2015 17:49, Andy Lutomirski wrote:
>> Hi-
>
> Hi. Apologies for the delay. I have been out of the office for a few days.
>
>>
>> In entry_64.S, we have:
>>
>> ENTRY(entry_SYSCALL_64)
>> /*
>> * Interrupts are off on entry
On 26/07/2015 22:34, Wei Liu wrote:
> Originally there was only one counter to keep track of pages. It was
> used erroneously to keep track of how many pages were mapped and how
> many pages needed to be sent. In the end munmap(2) always had 0 as the
> length argument, which resulted in leaking the
Originally there was only one counter to keep track of pages. It was
used erroneously to keep track of how many pages were mapped and how
many pages needed to be sent. In the end munmap(2) always had 0 as the
length argument, which resulted in leaking the mapping.
This problem was discovered on 32
On 23/07/2015 17:49, Andy Lutomirski wrote:
> Hi-
Hi. Apologies for the delay. I have been out of the office for a few days.
>
> In entry_64.S, we have:
>
> ENTRY(entry_SYSCALL_64)
> /*
> * Interrupts are off on entry.
> * We do not frame this tiny irq-off block with TRACE_IRQS_OF
flight 59964 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/59964/
Perfect :-)
All tests in this flight passed
version targeted for testing:
ovmf 88656abf1b3a690969851880ba2b134e0d144625
baseline version:
ovmf 387e7c15f5e3a047de0a7a5edb5700e90a1
On 25/07/2015 17:57, Ting-Wei Lan wrote:
> When using Linux >= 3.19 (commit 47591df) as dom0 on some Intel Ironlake
> devices, It is possible to encounter graphics issues that make screen
> unreadable or crash the system. It was reported in freedesktop bugzilla:
>
> https://bugs.freedesktop.org/sho
On 24/07/2015 23:40, Wei Liu wrote:
> Originally there was only one counter to keep track of pages. It was
> used erroneously to keep track of how many pages were mapped and how
> many pages needed to be send. In the end munmap(2) always has 0 as the
> length argument, which resulted in leaking the
flight 59909 linux-4.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/59909/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-pair 21 guest-migrate/src_host/dst_host fail REGR. vs. 59393
test-amd64-i386-xl
flight 59871 qemu-upstream-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/59871/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 3 host-install(3) broken REGR.
vs. 58880
te
flight 59869 xen-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/59869/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 6 xen-boot fail REGR. vs. 59813
test-amd64-i386-x
flight 59868 linux-3.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/59868/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-win7-amd64 6 xen-boot fail REGR. vs. 30511
Tests which are failing
On Sat, 25 Jul 2015, Julien Grall wrote:
> +/*
> + * Events delivered via platform PCI interrupts are always
> + * routed to vcpu 0 and hence cannot be rebound.
> + */
> +#define xen_support_evtchn_rebind() \
> + (!xen_hvm_domain() || xen_have_vector_callback)
Make this an inline please.
Tha
flight 59947 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/59947/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 5 libvirt-build fail REGR. vs. 59254
build-amd64-pvops
flight 59948 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/59948/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-pvops 5 kernel-build fail REGR. vs. 59907
build-armhf-pvops
23 matches
Mail list logo
