On Tue, Jul 10, 2018 at 04:14:11AM -0600, Jan Beulich wrote:
> Having noticed that VMLOAD alone is about as fast as a single of the
> involved WRMSRs, I thought it might be a reasonable idea to also use it
> for PV. Measurements, however, have shown that an actual improvement can
> be achieved only
flight 125912 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125912/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-examine 4 memdisk-try-append fail REGR. vs. 125691
test-amd64-i386-xl
flight 126009 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126009/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 12 guest-start fail REGR. vs. 125923
Tests which
Hi Juergen,
As this was also addressed to -user I'm going to assume that you do
want user response as well.
On Thu, Aug 16, 2018 at 08:17:13AM +0200, Juergen Gross wrote:
> We'd like to evaluate whether anyone would see problems with:
>
> - deprecating 32-bit PV guest support in Xen, meaning tha
在 2018/8/16 18:42, Jan Beulich 写道:
On 16.08.18 at 11:30, wrote:
On 2018/8/16 17:13, Zhenzhong Duan wrote:
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1493,6 +1493,10 @@ void __init noreturn __start_xen(unsigned long
mbi_p)
generic_apic_probe();
+pt_pci_init();
+
+a
在 2018/8/16 18:37, Jan Beulich 写道:
On 16.08.18 at 11:13, wrote:
On 2018/8/16 15:10, Jan Beulich wrote:
Have you investigated the alternative of deferring acpi_dmar_init()
to a later point, or at least the part of it that needs to do PCI
config space accesses? I'm not currently convinced the de
flight 125913 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125913/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict broken
test-amd64-i
flight 126015 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126015/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 12 guest-start fail REGR. vs. 125923
Tests which
On Mon, 13 Aug 2018, Julien Grall wrote:
> Hi Stefano,
>
> OOI, on the previous version you said you will explore the CTRL-x N solution
> (where N is the domID console to switch too). What was the result here?
I meant I'll explore it as a follow-up to this series. I haven't looked
into it yet, bu
On 17/08/18 00:33, Andy Smith wrote:
> Hi Juergen,
>
> As this was also addressed to -user I'm going to assume that you do
> want user response as well.
Right. Thanks for responding.
>
> On Thu, Aug 16, 2018 at 08:17:13AM +0200, Juergen Gross wrote:
>> We'd like to evaluate whether anyone would
On 16/08/18 19:34, Stefano Stabellini wrote:
> On Thu, 16 Aug 2018, Juergen Gross wrote:
>> In the Xen x86 community call we have been discussing whether anyone
>> really is depending on 32-bit PV guests. We'd like to evaluate whether
>> anyone would see problems with:
>>
>> - deprecating 32-bit PV
commit b3681dd548d06deb2e1573890829dff4b15abf46 upstream.
This version applies to v4.9.
From Andy Lutomirski, original author:
error_entry and error_exit communicate the user vs kernel status of
the frame using %ebx. This is unnecessary -- the information is in
regs->cs. Just use regs->cs.
Th
On 08/16/2018 09:29 AM, Pu Wen wrote:
> On 2018/8/12 21:26, Boris Ostrovsky wrote:
>> On 08/12/2018 04:55 AM, Juergen Gross wrote:
>>> On 11/08/18 16:34, Boris Ostrovsky wrote:
On 08/11/2018 09:29 AM, Pu Wen wrote:
> bool pmu_msr_read(unsigned int msr, uint64_t *val, int *err)
> {
flight 126019 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126019/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 12 guest-start fail REGR. vs. 125923
Tests which
>>> On 27.07.18 at 16:20, wrote:
> In order to mostly eliminate abuse of what Xen leaves in the RSB by
> guest level attackers, fill the RSB with almost-NULL pointers right
> before entering guest context.
>
> The placement of the initialization code is intentional: If it was put
> in e.g. hvm_en
Restore symmetry between get_page_from_le(): pv_l1tf_check_le is
uniformly invoked from outside of them. They're no longer getting called
for non-present PTEs. This way the slightly odd three-way return value
meaning of the higher level ones can also be got rid of.
Introduce local variables holdin
I'm not really convinced of the change done in v3, even less so with
x86'es pv/domain.h not really having been suitable for inclusion in
spec-ctrl.c (needed an extra, seemingly unrelated adjustment), but
in the interest of getting this done, here you go.
1: x86: report use of PCID together with re
101 - 117 of 117 matches
Mail list logo
