On 14/04/18 21:15, Souptick Joarder wrote:
> Use new return type vm_fault_t for fault handler
> in struct vm_operations_struct.
>
> Signed-off-by: Souptick Joarder
> Reviewed-by: Matthew Wilcox
Pushed to xen/tip.git for-linus-4.18
Juergen
___
Xen-d
On 09/05/18 12:21, Roger Pau Monne wrote:
> There's no need to store the xenstore page or event channel in
> xen_start_info if they are locally initialized.
>
> This also fixes PVH local xenstore initialization due to the lack of
> xen_start_info in that case.
>
> Signed-off-by: Boris Ostrovsky
On 24/04/18 15:18, Luc Van Oostenryck wrote:
> The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
> which is a typedef for an enum type, but the implementation in this
> driver returns an 'int'.
>
> Fix this by returning 'netdev_tx_t' in this driver too.
>
> Signed-off-by: Luc
On 09/05/18 15:16, Paul Durrant wrote:
> My recent Xen patch series introduces a new HYPERVISOR_memory_op to
> support direct priv-mapping of certain guest resources (such as ioreq
> pages, used by emulators) by a tools domain, rather than having to access
> such resources via the guest P2M.
>
> T
On 05/17/2018 09:26 AM, Takashi Iwai wrote:
On Tue, 15 May 2018 08:02:08 +0200,
Oleksandr Andrushchenko wrote:
On 05/15/2018 09:01 AM, Takashi Iwai wrote:
On Tue, 15 May 2018 07:46:38 +0200,
Oleksandr Andrushchenko wrote:
On 05/14/2018 11:28 PM, Takashi Iwai wrote:
On Mon, 14 May 2018 08:27:4
Am Wed, 16 May 2018 16:53:28 +0200
schrieb Olaf Hering :
> Am Thu, 10 May 2018 11:40:18 +0100
> schrieb Anthony PERARD :
> > I did fix the bug in QEMU 2.11 (5d6c599fe1d69a1bf8c5c4d3c58be2b31cd625ad)
> > so Xen 4.11 does include it it the qemu-xen tree.
> Is this supposed to be called also for PV
On Tue, 15 May 2018 08:02:08 +0200,
Oleksandr Andrushchenko wrote:
>
> On 05/15/2018 09:01 AM, Takashi Iwai wrote:
> > On Tue, 15 May 2018 07:46:38 +0200,
> > Oleksandr Andrushchenko wrote:
> >> On 05/14/2018 11:28 PM, Takashi Iwai wrote:
> >>> On Mon, 14 May 2018 08:27:40 +0200,
> >>> Oleksandr A
On 05/17/2018 08:50 AM, Juergen Gross wrote:
On 17/05/18 07:45, Oleksandr Andrushchenko wrote:
Hi, Juergen!
This patch should go into 4.11 as it is needed for a related Linux
kernel patch and the risk is next to zero for Xen due to only adding
some macros not in use on Xen side.
Could you plea
On 17/05/18 07:45, Oleksandr Andrushchenko wrote:
> Hi, Juergen!
>
> This patch should go into 4.11 as it is needed for a related Linux
> kernel patch and the risk is next to zero for Xen due to only adding
> some macros not in use on Xen side.
>
> Could you please release ack this
Release-acked
On 05/17/2018 08:42 AM, Juergen Gross wrote:
On 17/05/18 07:29, Oleksandr Andrushchenko wrote:
On 05/17/2018 07:28 AM, Juergen Gross wrote:
On 16/05/18 06:59, Oleksandr Andrushchenko wrote:
On 05/11/2018 06:15 PM, Juergen Gross wrote:
On 11/05/18 15:38, Konrad Rzeszutek Wilk wrote:
On Fri, M
Hi, Juergen!
This patch should go into 4.11 as it is needed for a related Linux
kernel patch and the risk is next to zero for Xen due to only adding
some macros not in use on Xen side.
Could you please release ack this and apply?
Thank you,
Oleksandr
On 05/02/2018 05:49 PM, Oleksandr Andrushch
On 17/05/18 07:29, Oleksandr Andrushchenko wrote:
> On 05/17/2018 07:28 AM, Juergen Gross wrote:
>> On 16/05/18 06:59, Oleksandr Andrushchenko wrote:
>>> On 05/11/2018 06:15 PM, Juergen Gross wrote:
On 11/05/18 15:38, Konrad Rzeszutek Wilk wrote:
> On Fri, May 11, 2018 at 09:37:57AM -0400,
On 05/17/2018 12:08 AM, Dmitry Torokhov wrote:
On Wed, May 16, 2018 at 08:47:30PM +0300, Oleksandr Andrushchenko wrote:
On 05/16/2018 08:15 PM, Dmitry Torokhov wrote:
Hi Oleksandr,
On Mon, May 14, 2018 at 05:40:29PM +0300, Oleksandr Andrushchenko wrote:
@@ -211,93 +220,114 @@ static int xenkb
On 05/17/2018 07:28 AM, Juergen Gross wrote:
On 16/05/18 06:59, Oleksandr Andrushchenko wrote:
On 05/11/2018 06:15 PM, Juergen Gross wrote:
On 11/05/18 15:38, Konrad Rzeszutek Wilk wrote:
On Fri, May 11, 2018 at 09:37:57AM -0400, Konrad Rzeszutek Wilk wrote:
On Wed, May 02, 2018 at 05:49:18PM
On 16/05/18 06:59, Oleksandr Andrushchenko wrote:
> On 05/11/2018 06:15 PM, Juergen Gross wrote:
>> On 11/05/18 15:38, Konrad Rzeszutek Wilk wrote:
>>> On Fri, May 11, 2018 at 09:37:57AM -0400, Konrad Rzeszutek Wilk wrote:
On Wed, May 02, 2018 at 05:49:18PM +0300, Oleksandr Andrushchenko
On 17/05/18 01:57, osstest service owner wrote:
> flight 122804 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/122804/
>
> Failures and problems with tests :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-arm64-ar
flight 122804 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122804/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl broken in 122715
test-arm6
Hi,
As discussed some time ago, I'd like to help with adding tests for some
features we use in Qubes OS.
IMO the easiest thing to test is host suspend. You just need to execute
"rtcwake -s 30 -m mem", and see if the host is back to live after ~30s.
Right now I know it works on Xen 4.8, but suppos
On Wed, May 16, 2018 at 08:47:30PM +0300, Oleksandr Andrushchenko wrote:
> On 05/16/2018 08:15 PM, Dmitry Torokhov wrote:
> > Hi Oleksandr,
> >
> > On Mon, May 14, 2018 at 05:40:29PM +0300, Oleksandr Andrushchenko wrote:
> > > @@ -211,93 +220,114 @@ static int xenkbd_probe(struct xenbus_device *de
Friendly ping. I am hopeful one of the x86 and/or KVM maintainers has a
few cycles to spare to look this over.
And thanks to everyone who has helped thus far by providing valuable
feedback and reviewing.
https://lkml.org/lkml/2018/4/16/1002
Thanks,
-Maran
On 4/16/2018 4:09 PM, Maran Wils
flight 122796 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122796/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-saverestore fail REGR. vs. 122696
test-armhf-armhf-ex
flight 122888 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122888/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
flight 122879 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122879/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On 16/05/18 09:14, Jan Beulich wrote:
On 15.05.18 at 19:54, wrote:
>> Also, I don't see any link between the change and the commit message. With
>> the microcode installed, STIBP and IBPB are already visible to dom0.
> They reportedly weren't (and I was able to confirm that), and given this
On 05/16/2018 08:15 PM, Dmitry Torokhov wrote:
Hi Oleksandr,
On Mon, May 14, 2018 at 05:40:29PM +0300, Oleksandr Andrushchenko wrote:
@@ -211,93 +220,114 @@ static int xenkbd_probe(struct xenbus_device *dev,
if (!info->page)
goto error_nomem;
- /* Set input abs params
flight 122801 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122801/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 122561
test-armhf-armhf-libvirt-raw 13 saveresto
c/s f9616884e (a backport of c/s 0d703a701 "x86/feature: Definitions for
Indirect Branch Controls") missed a CPUID adjustment when calculating the raw
featureset. This impacts host administrator diagnostics.
Signed-off-by: Sergey Dyasli
c/s 62b187969 "x86: further CPUID handling adjustments" ma
Hi Oleksandr,
On Mon, May 14, 2018 at 05:40:29PM +0300, Oleksandr Andrushchenko wrote:
> @@ -211,93 +220,114 @@ static int xenkbd_probe(struct xenbus_device *dev,
> if (!info->page)
> goto error_nomem;
>
> - /* Set input abs params to match backend screen res */
> - a
flight 122797 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122797/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 122667
version targeted for testi
On Wed, May 16, 2018 at 5:01 PM, Jan Beulich wrote:
On 16.05.18 at 16:53, wrote:
>> On Wed, May 16, 2018 at 3:01 PM, Jan Beulich wrote:
>> On 16.05.18 at 15:18, wrote:
If the latter, I think the same argument applies: turning on XPTI is a
requirement for many people, and thus
George Dunlap writes ("Re: [PATCH v6] scripts/add_maintainers.pl: New script"):
> I've looked over the help and approve of the functionality, and tested
> it for my use case and it seems to work as advertised.
>
> On that basis:
>
> Acked-by: George Dunlap
Thanks, pushed.
Ian.
___
>>> On 16.05.18 at 16:53, wrote:
> On Wed, May 16, 2018 at 3:01 PM, Jan Beulich wrote:
> On 16.05.18 at 15:18, wrote:
>>> If the latter, I think the same argument applies: turning on XPTI is a
>>> requirement for many people, and thus represents a pretty hefty
>>> performance regression. Wh
>>> On 07.05.18 at 23:07, wrote:
> @@ -180,6 +185,293 @@ int svm_avic_init_vmcb(struct vcpu *v)
> }
>
> /*
> + * Note:
> + * This function handles the AVIC_INCOMP_IPI #vmexit when AVIC is enabled.
> + * The hardware generates this fault when an IPI could not be delivered
> + * to all targeted
On 16/05/18 16:29, Jan Beulich wrote:
On 07.05.18 at 23:07, wrote:
>> +s->avic_last_phy_id = avic_get_physical_id_entry(d,
>> GET_xAPIC_ID(apic_id));
> You don't appear to read this value outside of this function. Please store
> values in struct domain / struct vcpu only if you in f
>>> On 07.05.18 at 23:07, wrote:
> --- /dev/null
> +++ b/xen/arch/x86/hvm/svm/avic.c
> @@ -0,0 +1,190 @@
> +/*
> + * avic.c: implements AMD Advanced Virtual Interrupt Controller (AVIC)
> support
> + * Copyright (c) 2018, Advanced Micro Devices, Inc.
> + *
> + * This program is free software; you
On 05/16/2018 12:50 PM, Ian Jackson wrote:
> George Dunlap writes ("Re: [PATCH v6] scripts/add_maintainers.pl: New
> script"):
>>> Changes since v5:
>>> - Add mention of --get-maintainers, and its best use case, to --help
>>> output. (Move $get_maintainer up so that it can be used here.)
>>
>>
On 9 May 2018 at 07:18, Mauro Carvalho Chehab
wrote:
> As we move stuff around, some doc references are broken. Fix some of
> them via this script:
> ./scripts/documentation-file-ref-check --fix-rst
>
> Manually checked if the produced result is valid, removing a few
> false-positives.
>
>
Am Thu, 10 May 2018 11:40:18 +0100
schrieb Anthony PERARD :
> I did fix the bug in QEMU 2.11 (5d6c599fe1d69a1bf8c5c4d3c58be2b31cd625ad)
> so Xen 4.11 does include it it the qemu-xen tree.
Is this supposed to be called also for PV? In my testing
qmp_xen_save_devices_state shows up only on HVM.
O
flight 122877 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122877/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On Wed, May 16, 2018 at 3:01 PM, Jan Beulich wrote:
On 16.05.18 at 15:18, wrote:
>> On Wed, May 16, 2018 at 10:06 AM, Jan Beulich wrote:
>> On 26.04.18 at 13:33, wrote:
Juergen Gross (9):
x86/xpti: avoid copying L4 page table contents when possible
xen/x86: add a fun
>>> On 07.05.18 at 23:07, wrote:
> --- a/xen/include/asm-x86/hvm/vlapic.h
> +++ b/xen/include/asm-x86/hvm/vlapic.h
> @@ -137,6 +137,10 @@ void vlapic_ipi(struct vlapic *vlapic, uint32_t icr_low,
> uint32_t icr_high);
>
> int vlapic_apicv_write(struct vcpu *v, unsigned int offset);
>
> +void
>>> On 07.05.18 at 23:07, wrote:
> AMD AVIC code makes use of vlapic_reg_read() and vlapic_reg_write(). To
> do this make the functions non-static.
To be honest I'd prefer if each of the two functions was made non-static in
the patch actually needing this to be the case. This allows better judgme
>>> On 07.05.18 at 23:07, wrote:
> Rename vlapic_read_aligned() to vlapic_reg_read() to make it a pair of
> vlapic_reg_write().
>
> Signed-off-by: Janakarajan Natarajan
Acked-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xenproject.or
> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: 16 May 2018 15:31
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; qemu-bl...@nongnu.org; qemu-
> de...@nongnu.org; Stefano Stabellini
> Subject: Re: [PATCH v3 4/8] xen_backend: add an emulation
On Fri, May 04, 2018 at 08:26:03PM +0100, Paul Durrant wrote:
> Not all Xen environments support the xengnttab_grant_copy() operation.
> E.g. where the OS is FreeBSD or Xen is older than 4.8.0.
>
> This patch introduces an emulation of that operation using
> xengnttab_map_domain_grant_refs() and m
> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: 16 May 2018 15:14
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; qemu-bl...@nongnu.org; qemu-
> de...@nongnu.org; Stefano Stabellini ; Greg Kurz
> ; Paolo Bonzini ; Jason Wang
> ; Gerd Hoffmann
On Fri, May 04, 2018 at 08:26:02PM +0100, Paul Durrant wrote:
> Now that helpers are available in xen_backend, use them throughout all
> Xen PV backends.
>
> Signed-off-by: Paul Durrant
> ---
> diff --git a/hw/net/xen_nic.c b/hw/net/xen_nic.c
> index 20c43a6..73d6f1b 100644
> --- a/hw/net/xen_nic
On Fri, May 04, 2018 at 08:26:01PM +0100, Paul Durrant wrote:
> Now that helpers are present in xen_backend, this patch removes open-coded
> calls to libxengnttab from the xen_disk code.
>
> This patch also fixes one whitspace error in the assignment of the
> XenDevOps initialise method.
>
> Sign
On Wed, May 16, 2018 at 07:51:07AM -0600, Jan Beulich wrote:
> >>> On 16.05.18 at 15:41, wrote:
> > On Wed, May 16, 2018 at 06:01:00AM -0600, Jan Beulich wrote:
> >> @@ -729,6 +729,14 @@ static int hvm_load_mtrr_msr(struct doma
> >> if ( hvm_load_entry(MTRR, h, &hw_mtrr) != 0 )
> >>
>>> On 16.05.18 at 15:18, wrote:
> On Wed, May 16, 2018 at 10:06 AM, Jan Beulich wrote:
> On 26.04.18 at 13:33, wrote:
>>> Juergen Gross (9):
>>> x86/xpti: avoid copying L4 page table contents when possible
>>> xen/x86: add a function for modifying cr3
>>> xen/x86: support per-domain f
> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: 16 May 2018 14:50
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; qemu-bl...@nongnu.org; qemu-
> de...@nongnu.org; Stefano Stabellini
> Subject: Re: [PATCH v3 1/8] xen_backend: add grant table
flight 74720 distros-debian-squeeze real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74720/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-i386-squeeze-netboot-pygrub 10 debian-di-install fail like
74699
test-amd64-i386-i386
>>> On 16.05.18 at 15:41, wrote:
> On Wed, May 16, 2018 at 06:01:00AM -0600, Jan Beulich wrote:
>> --- unstable.orig/xen/arch/x86/hvm/mtrr.c
>> +++ unstable/xen/arch/x86/hvm/mtrr.c
>> @@ -676,22 +676,22 @@ int hvm_set_mem_pinned_cacheattr(struct
>>
>> static int hvm_save_mtrr_msr(struct domain
On Fri, May 04, 2018 at 08:26:00PM +0100, Paul Durrant wrote:
> This patch adds grant table helper functions to the xen_backend code to
> localize error reporting and use of xen_domid.
>
> The patch also defers the call to xengnttab_open() until just before the
> initialise method in XenDevOps is
>>> On 16.05.18 at 15:25, wrote:
> On 16/05/18 14:10, Jan Beulich wrote:
>>> +static int do_microcode_update(void *_info)
>>> +{
>>> +struct microcode_info *info = _info;
>>> +unsigned int cpu = smp_processor_id();
>>> +int ret;
>>> +
>>> +ret = wait_for_cpus(&info->cpu_in, MICROCO
On Wed, May 16, 2018 at 06:01:00AM -0600, Jan Beulich wrote:
> >>> On 16.05.18 at 13:53, wrote:
> > On Wed, May 16, 2018 at 02:39:26AM -0600, Jan Beulich wrote:
> >> >>> On 15.05.18 at 16:36, wrote:
> >> > +for ( i = 0; i < num_var_ranges; i++ )
> >>
> >> Following your v1 I had already
On 16/05/18 14:10, Jan Beulich wrote:
>> +static int do_microcode_update(void *_info)
>> +{
>> +struct microcode_info *info = _info;
>> +unsigned int cpu = smp_processor_id();
>> +int ret;
>> +
>> +ret = wait_for_cpus(&info->cpu_in, MICROCODE_DEFAULT_TIMEOUT);
>> +if ( ret )
>>
On Wed, May 16, 2018 at 10:06 AM, Jan Beulich wrote:
On 26.04.18 at 13:33, wrote:
>> Juergen Gross (9):
>> x86/xpti: avoid copying L4 page table contents when possible
>> xen/x86: add a function for modifying cr3
>> xen/x86: support per-domain flag for xpti
>> xen/x86: use invpcid fo
Am Thu, 10 May 2018 09:03:30 -0700 (PDT)
schrieb Stefano Stabellini :
> You could add a property to vmstate_xen_platform of xen_platform.c, but
> you need to pay attention to legacy compatibility. Inevitably, there
> will be older versions that do not have the new vmstate_xen_platform
> field or d
This run is configured for baseline tests only.
flight 74719 xen-4.6-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74719/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-521 xtf/test-hvm32-
On 16/05/18 14:46, Jan Beulich wrote:
On 15.05.18 at 16:10, wrote:
>> The current unbind loop on failure in vpci_msi_enable is wrong and
>> will only work correctly if the initial pirq is 0. Fix this by adding
>> a proper bound.
>>
>> Reported-by: Jan Beulich
>> Signed-off-by: Roger Pau Monn
>>> On 09.05.18 at 00:01, wrote:
> @@ -30,15 +31,21 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> +#include
>
> +#include
> #include
> #include
> #include
> #include
>
> +/* By default, wait for 3us */
> +#define MICROCODE_DEFAULT
flight 122785 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122785/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl broken in 122710
test-arm64-arm64-libvirt-xs
On 16/05/18 09:37, John Wang wrote:
>
> Hi:
>
> 64 bit PV guest can attack hypervisor by SP3
>
Yes.
> whether it still can attack others 64 bit PV guest by SP3?
>
Meltdown attacks only operate within a single address space. You can't
attack a separate address space with it.
That said, the VM =
>>> On 09.05.18 at 00:01, wrote:
> Mainly for the patch behind which relies on 'nr_phys_cpus' to estimate
> the time needed for microcode update in the worst case.
Leaving aside the aspect of "nr_phys_cpus" not being a suitable name
("nr_online_cores" would come closer imo) I'm not convinced usin
>>> On 15.05.18 at 16:10, wrote:
> Current update process of already bound MSI interrupts is wrong
> because unmap_domain_pirq calls pci_disable_msi, which disables MSI
> interrupts on the device. On the other hand map_domain_pirq doesn't
> enable MSI, so the current update process of already enab
>>> On 15.05.18 at 16:10, wrote:
> And put it in a separate update function. This is required in order to
> improve binding of MSI PIRQs when using vPCI.
>
> No functional change.
>
> Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulich
___
Xen
>>> On 15.05.18 at 16:10, wrote:
> The current unbind loop on failure in vpci_msi_enable is wrong and
> will only work correctly if the initial pirq is 0. Fix this by adding
> a proper bound.
>
> Reported-by: Jan Beulich
> Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulich
Jürgen,
any
flight 122868 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122868/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
>>> On 16.05.18 at 13:58, wrote:
> On Wed, May 16, 2018 at 02:47:39AM -0600, Jan Beulich wrote:
>> >>> On 15.05.18 at 16:36, wrote:
>> > --- a/xen/arch/x86/hvm/mtrr.c
>> > +++ b/xen/arch/x86/hvm/mtrr.c
>> > @@ -185,6 +185,30 @@ int hvm_vcpu_cacheattr_init(struct vcpu *v)
>> > ((uint64_t)
>>> On 16.05.18 at 13:53, wrote:
> On Wed, May 16, 2018 at 02:39:26AM -0600, Jan Beulich wrote:
>> >>> On 15.05.18 at 16:36, wrote:
>> > +for ( i = 0; i < num_var_ranges; i++ )
>>
>> Following your v1 I had already put together a patch to change just the
>> save and load functions here,
On Wed, May 16, 2018 at 02:47:39AM -0600, Jan Beulich wrote:
> >>> On 15.05.18 at 16:36, wrote:
> > --- a/xen/arch/x86/hvm/mtrr.c
> > +++ b/xen/arch/x86/hvm/mtrr.c
> > @@ -185,6 +185,30 @@ int hvm_vcpu_cacheattr_init(struct vcpu *v)
> > ((uint64_t)PAT_TYPE_UC_MINUS << 48) | /* PAT6:
On Wed, May 16, 2018 at 02:39:26AM -0600, Jan Beulich wrote:
> >>> On 15.05.18 at 16:36, wrote:
> > +for ( i = 0; i < num_var_ranges; i++ )
>
> Following your v1 I had already put together a patch to change just the
> save and load functions here, as the adjustments are necessary
> indepe
George Dunlap writes ("Re: [PATCH v6] scripts/add_maintainers.pl: New script"):
> > Changes since v5:
> > - Add mention of --get-maintainers, and its best use case, to --help
> > output. (Move $get_maintainer up so that it can be used here.)
>
> Do you actually want to check this massive change
On Wed, May 16, 2018 at 12:27:29PM +0100, Andrew Cooper wrote:
> On 14/05/18 16:48, Wei Liu wrote:
> > On Fri, May 11, 2018 at 11:38:14AM +0100, Andrew Cooper wrote:
> >> If Xen is virtualising MSR_SPEC_CTRL handling for guests, but using 0 as
> >> its
> >> own MSR_SPEC_CTRL value, spec_ctrl_{ente
On 14/05/18 16:48, Wei Liu wrote:
> On Fri, May 11, 2018 at 11:38:14AM +0100, Andrew Cooper wrote:
>> If Xen is virtualising MSR_SPEC_CTRL handling for guests, but using 0 as its
>> own MSR_SPEC_CTRL value, spec_ctrl_{enter,exit}_idle() need not write to the
>> MSR.
>>
>> Requested-by: Jan Beulich
On 05/15/2018 06:23 PM, Ian Jackson wrote:
> From: Lars Kurth
>
> This provides a much better workflow when using git format-patch and
> git send-email, with get_maintainer.pl.
>
> The tool covers step 2 of the following workflow
>
> Step 1: git format-patch ... -o ...
> Step 2: ./scripts/
On Wed, May 16, 2018 at 12:08:02PM +0100, Andrew Cooper wrote:
> On 14/05/18 16:52, Jan Beulich wrote:
> On 14.05.18 at 17:39, wrote:
> >> On Fri, May 11, 2018 at 11:38:11AM +0100, Andrew Cooper wrote:
> >>> @@ -417,6 +419,32 @@ void __init init_speculation_mitigations(void)
> >>> se
On 14/05/18 16:52, Jan Beulich wrote:
On 14.05.18 at 17:39, wrote:
>> On Fri, May 11, 2018 at 11:38:11AM +0100, Andrew Cooper wrote:
>>> @@ -417,6 +419,32 @@ void __init init_speculation_mitigations(void)
>>> setup_clear_cpu_cap(X86_FEATURE_NO_XPTI);
>>>
>>> print_details(thun
On 16/05/18 11:49, Jan Beulich wrote:
On 16.05.18 at 12:28, wrote:
>> On 16/05/18 07:38, Jan Beulich wrote:
>> On 15.05.18 at 21:52, wrote:
On 14/05/18 16:27, Jan Beulich wrote:
On 11.05.18 at 12:38, wrote:
>> --- a/xen/arch/x86/spec_ctrl.c
>> +++ b/xen/arch/x86/sp
Dear All,
I'm trying to rebuild the blktap module from xenserver. I'm getting
following compile errors, any help or direction would be appreciated.
make[2]: Entering directory
`/root/rpmbuild/BUILD/blktap-3.2.0.xs1086/drivers'
/bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I.
>>> On 16.05.18 at 12:28, wrote:
> On 16/05/18 07:38, Jan Beulich wrote:
> On 15.05.18 at 21:52, wrote:
>>> On 14/05/18 16:27, Jan Beulich wrote:
>>> On 11.05.18 at 12:38, wrote:
> --- a/xen/arch/x86/spec_ctrl.c
> +++ b/xen/arch/x86/spec_ctrl.c
> @@ -128,7 +128,8 @@ static vo
On Tue, May 15, 2018 at 03:36:16PM +0100, Roger Pau Monne wrote:
> And enable MTRR. This allows to provide a sane initial MTRR state for
> PVH DomUs. This will have to be expanded when pci-passthrough support
> is added to PVH guests, so that MMIO regions of devices are set as
> UC.
>
> Note that
flight 122867 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122867/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen b953322c5772dbc537421f9e2f97026a1c2fcb2e
baseline version:
xen 858d
On 16/05/18 07:38, Jan Beulich wrote:
On 15.05.18 at 21:52, wrote:
>> On 14/05/18 16:27, Jan Beulich wrote:
>> On 11.05.18 at 12:38, wrote:
--- a/xen/arch/x86/spec_ctrl.c
+++ b/xen/arch/x86/spec_ctrl.c
@@ -128,7 +128,8 @@ static void __init print_details(enum ind_thunk thu
On Thu, May 03, 2018 at 12:18:40PM +0100, Paul Durrant wrote:
> This patch removes the current hackery where IOREQ_TYPE_PCI_CONFIG
> reqyests are handled by faking PIO to 0xcf8 and 0xcfc and replaces it
> with direct calls to pci_host_config_read/write_common().
> Doing so necessitates mapping BDFs
On 12.05.2018 10:27, Weiwei Jia wrote:
> Dear all,
>
> Recently, we made a few improvements on effectively utilizing Pause
> Loop Exiting (PLE) support for higher throughput on virtualized
> systems. Basically, it solves two problems: 1) how to adjust
> PLE_Window; 2) how to select virtual CPUs to
Hi:
64 bit PV guest can attack hypervisor by SP3, whether it still can
attack others 64 bit PV guest by SP3 ? If yes, whether the xpti enable
on hypervisor can prevent vulnerability? if no, what operations need
to be done on 64 PV guest or hypervisor?
--
Thanks
APACII QA
John(XiaoGen Wan
On Wed, May 09, 2018 at 10:18:52AM -0300, Mauro Carvalho Chehab wrote:
> As we move stuff around, some doc references are broken. Fix some of
> them via this script:
> ./scripts/documentation-file-ref-check --fix-rst
>
> Manually checked if the produced result is valid, removing a few
> fals
flight 122771 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122771/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-credit2 broken in 122704
test-a
>>> On 26.04.18 at 13:33, wrote:
> Juergen Gross (9):
> x86/xpti: avoid copying L4 page table contents when possible
> xen/x86: add a function for modifying cr3
> xen/x86: support per-domain flag for xpti
> xen/x86: use invpcid for flushing the TLB
> xen/x86: disable global pages for dom
Anthony, Stefano,
Ping?
Paul
> -Original Message-
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: 03 May 2018 12:19
> To: xen-devel@lists.xenproject.org; qemu-de...@nongnu.org
> Cc: Paul Durrant ; Stefano Stabellini
> ; Anthony Perard ;
> Michael S. Tsirkin ; Marcel Apf
>>> On 15.05.18 at 16:36, wrote:
> --- a/xen/arch/x86/hvm/mtrr.c
> +++ b/xen/arch/x86/hvm/mtrr.c
> @@ -185,6 +185,30 @@ int hvm_vcpu_cacheattr_init(struct vcpu *v)
> ((uint64_t)PAT_TYPE_UC_MINUS << 48) | /* PAT6: UC- */
> ((uint64_t)PAT_TYPE_UNCACHABLE << 56); /* PAT7:
>>> On 15.05.18 at 16:36, wrote:
> --- a/xen/arch/x86/hvm/mtrr.c
> +++ b/xen/arch/x86/hvm/mtrr.c
> @@ -154,14 +154,26 @@ uint8_t pat_type_2_pte_flags(uint8_t pat_type)
> int hvm_vcpu_cacheattr_init(struct vcpu *v)
> {
> struct mtrr_state *m = &v->arch.hvm_vcpu.mtrr;
> +unsigned int num_
>>> On 15.05.18 at 16:36, wrote:
> @@ -478,7 +478,7 @@ bool_t mtrr_pat_not_equal(struct vcpu *vd, struct vcpu
> *vs)
> struct mtrr_state *md = &vd->arch.hvm_vcpu.mtrr;
> struct mtrr_state *ms = &vs->arch.hvm_vcpu.mtrr;
> int32_t res;
> -uint8_t num_var_ranges = (uint8_t)md->mtr
>>> On 15.05.18 at 16:36, wrote:
> Provided to both Dom0 and DomUs.
>
> Signed-off-by: Roger Pau Monné
> ---
> Cc: Andrew Cooper
> Cc: George Dunlap
> Cc: Ian Jackson
> Cc: Jan Beulich
> Cc: Julien Grall
> Cc: Konrad Rzeszutek Wilk
> Cc: Stefano Stabellini
> Cc: Tim Deegan
> Cc: Wei Liu
>>> On 15.05.18 at 19:54, wrote:
> Also, I don't see any link between the change and the commit message. With
> the microcode installed, STIBP and IBPB are already visible to dom0.
They reportedly weren't (and I was able to confirm that), and given this
original (prior to that change) code
On Fri, May 11, 2018 at 07:43:58PM -0300, Charles Gonçalves wrote:
> "That is, without (physical
> or virtual, depending on component) serial console you're often unlikely to
> actually observe any messages connected to the crash."
>
> I do not have any experience with serial console interaction o
98 matches
Mail list logo
