flight 122516 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122516/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 16 guest-localmigrate/x10
fail REGR. vs. 122357
flight 122515 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122515/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl 1 build-check(1) blocked n/a
test-arm64-arm64-examine 1 build-check
On 30/04/2018 22:23, Natarajan, Janakarajan wrote:
>>> +static int avic_ldr_write(struct vcpu *v, u8 g_phy_id, u32 ldr,
>>> bool valid)
>>> +{
>>> + struct avic_logical_id_entry *entry, new_entry;
>>> + u32 dfr = vlapic_read_aligned(vcpu_vlapic(v), APIC_DFR);
>>> +
>>> + entry = avic_get_l
On 30/04/2018, 17:21, "Ian Jackson" wrote:
Lars Kurth writes ("Re: [PATCH for-4.11 v2 2/2] Add new add_maintainers.pl
script to optimise the workflow when using git format-patch with
get_maintainer.pl"):
> Given that git send-email reads CC's anywhere in the body of a *.patch
file,
flight 122512 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122512/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-xl-qemuu-debianhvm-amd64 16 guest-localmigrate/x10 fail in
122472 pass in 122512
test-amd64
Using RING_GET_RESPONSE() on a shared ring is easy to use incorrectly
(i.e., by not considering that the other end may alter the data in the
shared ring while it is being inspected). Safe usage of a response
generally requires taking a local copy.
Provide a RING_COPY_RESPONSE() macro to use inste
On 04/30/2018 05:27 PM, Marek Marczykowski-Górecki wrote:
> On Mon, Apr 30, 2018 at 05:25:52PM -0400, Boris Ostrovsky wrote:
>> Also, perhaps the two can be collapsed together, along the lines of
>>
>> #define RING_COPY_(action, _r, _idx, _msg) do { \
>> /* Use vola
This run is configured for baseline tests only.
flight 74651 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74651/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-qemuu-ws16-amd64 14 guest-localmigra
On Mon, Apr 30, 2018 at 05:25:52PM -0400, Boris Ostrovsky wrote:
> Also, perhaps the two can be collapsed together, along the lines of
>
> #define RING_COPY_(action, _r, _idx, _msg) do { \
> /* Use volatile to force the copy into _msg. */ \
>
On 4/13/2018 12:48 PM, Andrew Cooper wrote:
On 04/04/18 00:01, Janakarajan Natarajan wrote:
From: Suravee Suthikulpanit
AVIC introduces two new #vmexit handlers:
VMEXIT_INCOMP_IPI:
This occurs when an IPI could not be delivered to all targeted guest
virtual processors because at least one g
On 04/30/2018 05:01 PM, Marek Marczykowski-Górecki wrote:
> Using RING_GET_RESPONSE() on a shared ring is easy to use incorrectly
> (i.e., by not considering that the other end may alter the data in the
> shared ring while it is being inspected). Safe usage of a response
> generally requires takin
Patches in original Xen Security Advisory 155 cared only about backend drivers
while leaving frontend patches to be "developed and released (publicly) after
the embargo date". This is said series.
Marek Marczykowski-Górecki (6):
xen: Add RING_COPY_RESPONSE()
xen-netfront: copy response out of
Using RING_GET_RESPONSE() on a shared ring is easy to use incorrectly
(i.e., by not considering that the other end may alter the data in the
shared ring while it is being inspected). Safe usage of a response
generally requires taking a local copy.
Provide a RING_COPY_RESPONSE() macro to use inste
Backend may freely modify anything on shared page, so use data which was
supposed to be written there, instead of reading it back from the shared
page.
This is complementary to XSA155.
CC: sta...@vger.kernel.org
Signed-off-by: Marek Marczykowski-Górecki
---
drivers/net/xen-netfront.c | 9 +
Make local copy of the response, otherwise backend might modify it while
frontend is already processing it - leading to time of check / time of
use issue.
This is complementary to XSA155.
Cc: sta...@vger.kernel.org
Signed-off-by: Marek Marczykowski-Górecki
---
drivers/net/xen-netfront.c | 51 ++
Data on the shared page can be changed at any time by the backend. Make
a local copy, which is no longer controlled by the backend. And only
then access it.
This is complementary to XSA155.
CC: sta...@vger.kernel.org
Signed-off-by: Marek Marczykowski-Górecki
---
drivers/block/xen-blkfront.c | 3
Tx response ID is fetched from shared page, so make sure it is sane
before using it as an array index.
CC: sta...@vger.kernel.org
Signed-off-by: Marek Marczykowski-Górecki
---
drivers/net/xen-netfront.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/xen-netfront.c b/drivers/net/
Do not reuse data which theoretically might be already modified by the
backend. This is mostly about private copy of the request
(info->shadow[id].req) - make sure the request saved there is really the
one just filled.
This is complementary to XSA155.
CC: sta...@vger.kernel.org
Signed-off-by: Mar
flight 122508 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122508/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-xtf-amd64-amd64-3 50 xtf/test-hvm64-lbr-tsx-vmentry fail in 122466 pass
in 122508
test-xtf-amd64-amd64
flight 122543 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122543/
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, Apr 25, 2018 at 08:12:08AM +0200, Juergen Gross wrote:
> On 24/04/18 22:35, Dongwon Kim wrote:
> > Had a meeting with Daniel and talked about bringing out generic
> > part of hyper-dmabuf to the userspace, which means we most likely
> > reuse IOCTLs defined in xen-zcopy for our use-case if
correction:
On Mon, Apr 30, 2018 at 06:17:54PM +, Jason Cooper wrote:
> On Mon, Apr 30, 2018 at 05:38:55PM +0100, George Dunlap wrote:
> > On Mon, Apr 30, 2018 at 5:16 PM, Jason Cooper wrote:
> > > Hi Ian,
> > >
> > > On Mon, Apr 30, 2018 at 04:22:30PM +0100, Ian Jackson wrote:
> > >> Wei Liu
Hi George,
On Mon, Apr 30, 2018 at 05:38:55PM +0100, George Dunlap wrote:
> On Mon, Apr 30, 2018 at 5:16 PM, Jason Cooper wrote:
> > Hi Ian,
> >
> > On Mon, Apr 30, 2018 at 04:22:30PM +0100, Ian Jackson wrote:
> >> Wei Liu writes ("Re: [Xen-devel] reboot driver domain, vifX.Y =
> >> NO-CARRIER?"
On Mon, Apr 30, 2018 at 05:26:38PM +0100, Ian Jackson wrote:
> Jason Cooper writes ("Re: [Xen-devel] reboot driver domain, vifX.Y =
> NO-CARRIER?"):
> > On Mon, Apr 30, 2018 at 04:22:30PM +0100, Ian Jackson wrote:
...
> > Ok, so I'm new to the guts of Xen. The bug, at a high level, is that
> > "W
On 04/30/2018 12:57 PM, Roger Pau Monné wrote:
> On Mon, Apr 30, 2018 at 12:23:36PM -0400, Boris Ostrovsky wrote:
>> Latest binutils release (2.29.1) will no longer allow proper computation
>> of GDT entries on 32-bits, with warning:
>>
>> arch/x86/xen/xen-pvh.S: Assembler messages:
>> arch/x86/xen
On 04/30/2018 01:07 PM, Andrew Cooper wrote:
> On 30/04/18 12:37, Jan Beulich wrote:
>> While the main problem to be addressed here is the issue of what so far
>> was named "vmcb_in_sync" starting out with the wrong value (should have
>> been true instead of false, to prevent performing a VMSAVE wi
On Thu, Apr 26, 2018 at 11:47:41AM +0300, Oleksandr Andrushchenko wrote:
> On 04/26/2018 11:16 AM, Paul Durrant wrote:
> > > -Original Message-
> > > From: Oleksandr Andrushchenko [mailto:andr2...@gmail.com]
> > > Sent: 26 April 2018 07:00
> > > To: Paul Durrant ; 'Juergen Gross'
> > > ; xe
On 30/04/18 12:37, Jan Beulich wrote:
> While the main problem to be addressed here is the issue of what so far
> was named "vmcb_in_sync" starting out with the wrong value (should have
> been true instead of false, to prevent performing a VMSAVE without ever
> having VMLOADed the vCPU's state), go
On Mon, Apr 30, 2018 at 12:23:36PM -0400, Boris Ostrovsky wrote:
> Latest binutils release (2.29.1) will no longer allow proper computation
> of GDT entries on 32-bits, with warning:
>
> arch/x86/xen/xen-pvh.S: Assembler messages:
> arch/x86/xen/xen-pvh.S:150: Warning: shift count out of range (32
On Mon, Apr 30, 2018 at 5:16 PM, Jason Cooper wrote:
> Hi Ian,
>
> On Mon, Apr 30, 2018 at 04:22:30PM +0100, Ian Jackson wrote:
>> Wei Liu writes ("Re: [Xen-devel] reboot driver domain, vifX.Y =
>> NO-CARRIER?"):
>> > To implement reuse_domid in a sane way, either the toolstack needs to
>> > mana
Jason Cooper writes ("Re: [Xen-devel] reboot driver domain, vifX.Y =
NO-CARRIER?"):
> On Mon, Apr 30, 2018 at 04:22:30PM +0100, Ian Jackson wrote:
> > Wei Liu writes ("Re: [Xen-devel] reboot driver domain, vifX.Y =
> > NO-CARRIER?"):
> > > To implement reuse_domid in a sane way, either the toolst
Latest binutils release (2.29.1) will no longer allow proper computation
of GDT entries on 32-bits, with warning:
arch/x86/xen/xen-pvh.S: Assembler messages:
arch/x86/xen/xen-pvh.S:150: Warning: shift count out of range (32 is not
between 0 and 31)
arch/x86/xen/xen-pvh.S:150: Warning: shift count
Switching to new binutils release triggered the first bug.
Not sure if stack canary bug is related to the new tools as well
(haven't checked it with old tools, but they are really old, from
Fedora 13 days).
64-bit guests run fine even without adding the entry for GS but my
guess is that's because
Lars Kurth writes ("Re: [PATCH for-4.11 v2 2/2] Add new add_maintainers.pl
script to optimise the workflow when using git format-patch with
get_maintainer.pl"):
> Given that git send-email reads CC's anywhere in the body of a *.patch file,
> I am not sure why this is useful. Can you enlighten me
Signed-off-by: Boris Ostrovsky
Cc: sta...@vger.kernel.org
---
arch/x86/xen/xen-pvh.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/xen/xen-pvh.S b/arch/x86/xen/xen-pvh.S
index 934f7d4..373fef0 100644
--- a/arch/x86/xen/xen-pvh.S
+++ b/arch/x86/xen/xen-pvh.S
@@ -93,7
We are making calls to C code (e.g. xen_prepare_pvh()) which may use
stack canary (stored in GS segment).
Signed-off-by: Boris Ostrovsky
Cc: sta...@vger.kernel.org
---
arch/x86/xen/xen-pvh.S | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/x86/xen/xen-pvh.S b/arch/x86/xen/xen-pvh.
And without it we can't use _BOOT_XX macros any longer so define new ones.
Signed-off-by: Boris Ostrovsky
---
arch/x86/xen/xen-pvh.S | 23 +--
1 file changed, 13 insertions(+), 10 deletions(-)
diff --git a/arch/x86/xen/xen-pvh.S b/arch/x86/xen/xen-pvh.S
index 4eed586..30dd06
Hi Ian,
On Mon, Apr 30, 2018 at 04:22:30PM +0100, Ian Jackson wrote:
> Wei Liu writes ("Re: [Xen-devel] reboot driver domain, vifX.Y = NO-CARRIER?"):
> > To implement reuse_domid in a sane way, either the toolstack needs to
> > manage all domids and always sets domid when creating domain or the
>
Hi Mirela,
On 27/04/18 18:12, Mirela Simonovic wrote:
On boot, enabling errata workarounds will be triggered by the boot CPU
from start_xen(). On CPU hotplug (non-boot scenario) this would not be
done. This patch adds the code required to enable errata workarounds
for a CPU being hotplugged afte
On 30/04/2018, 15:36, "Ian Jackson" wrote:
> +if (! -e $get_maintainer) {
> +die "$tool: The tool requires $get_maintainer\n";
> +}
You may remember me saying I wanted a mode that simply transfers
maintainer information already provided in the patches. That is
>>> On 30.04.18 at 17:56, wrote:
> On 04/30/2018 11:50 AM, Jan Beulich wrote:
> On 30.04.18 at 17:30, wrote:
>>> On 04/30/2018 07:37 AM, Jan Beulich wrote:
@@ -1168,6 +1169,9 @@ static void noreturn svm_do_resume(struc
hvm_do_resume(v);
+if ( v->arch.hvm_
flight 122540 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122540/
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
Hi,
On 27/04/18 18:12, Mirela Simonovic wrote:
When a CPU is hot-unplugged timer interrupts have to be released
in order to free the memory that was allocated when the interrupts
were requested (using request_irq()). The request_irq is called
for each timer interrupt when the CPU gets hotplugged
On 04/30/2018 11:50 AM, Jan Beulich wrote:
On 30.04.18 at 17:30, wrote:
>> On 04/30/2018 07:37 AM, Jan Beulich wrote:
>>> @@ -1168,6 +1169,9 @@ static void noreturn svm_do_resume(struc
>>>
>>> hvm_do_resume(v);
>>>
>>> +if ( v->arch.hvm_svm.vmcb_sync_state == vmcb_needs_vmload )
>>> On 08.07.17 at 23:53, wrote:
> We need the POSIX time to properly fill the TimeDateStamp field in the PE
> header.
>
> Signed-off-by: Daniel Kiper
> ---
> xen/Makefile | 14 --
> xen/include/xen/compile.h.in |1 +
> 2 files changed, 9 insertions(+), 6 dele
Hi Mirela,
On 27/04/18 18:12, Mirela Simonovic wrote:
The memory allocated in setup_cpu_sibling_map() when a CPU is hotplugged
has to be freed when the CPU is hot-unplugged. This is done in
remove_cpu_sibling_map() and called when the CPU dies. The call to
remove_cpu_sibling_map() is made from a
>>> On 30.04.18 at 17:30, wrote:
> On 04/30/2018 07:37 AM, Jan Beulich wrote:
>> @@ -1168,6 +1169,9 @@ static void noreturn svm_do_resume(struc
>>
>> hvm_do_resume(v);
>>
>> +if ( v->arch.hvm_svm.vmcb_sync_state == vmcb_needs_vmload )
>> +svm_sync_vmcb(v, vmcb_needs_vmsave);
>
>>> On 22.03.18 at 12:32, wrote:
> The end goal of having VMX MSRs policy is to be able to manage
> L1 VMX features. This patch series is the first part of this work.
> There is no functional change to what L1 sees in VMX MSRs at this
> point. But each domain will have a policy object which allows
On Tue, Jan 16, 2018 at 02:12:29AM +0800, Luwei Kang wrote:
> This patch add Intel processor trace support
> for cpuid handling.
The 0x14 usage screams of wanting an #define.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenpro
On Tue, Jan 16, 2018 at 02:12:26AM +0800, Luwei Kang wrote:
> Hi All,
>
> Here is a patch-series which adding Processor Trace enabling in XEN guest.
> You can get It's software developer manuals from:
> https://software.intel.com/sites/default/files/managed/c5/15/architecture-instruction-set-exte
flight 122500 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122500/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-vhd broken
test-armhf-armhf-
> -Original Message-
> From: Roger Pau Monne
> Sent: 30 April 2018 16:28
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; qemu-bl...@nongnu.org; qemu-
> de...@nongnu.org; Anthony Perard ; Kevin
> Wolf ; Stefano Stabellini ; Max
> Reitz
> Subject: Re: [Xen-devel] [PATCH 2/4] block/
On Mon, Apr 30, 2018 at 04:16:52PM +0100, Paul Durrant wrote:
> > -Original Message-
> > From: Roger Pau Monne
> > Sent: 30 April 2018 16:12
> > To: Paul Durrant
> > Cc: xen-devel@lists.xenproject.org; qemu-bl...@nongnu.org; qemu-
> > de...@nongnu.org; Anthony Perard ; Kevin
> > Wolf ; Ste
On 04/30/2018 07:37 AM, Jan Beulich wrote:
> @@ -1168,6 +1169,9 @@ static void noreturn svm_do_resume(struc
>
> hvm_do_resume(v);
>
> +if ( v->arch.hvm_svm.vmcb_sync_state == vmcb_needs_vmload )
> +svm_sync_vmcb(v, vmcb_needs_vmsave);
Is it not possible (or advisable) to move
>>> On 25.04.18 at 13:46, wrote:
> @@ -281,24 +288,56 @@ static int microcode_update_cpu(const void *buf, size_t
> size)
> return err;
> }
>
> -static long do_microcode_update(void *_info)
> +/* Wait for all CPUs to rendezvous with a timeout (us) */
> +static int wait_for_cpus(atomic_t *c
Wei Liu writes ("Re: [Xen-devel] reboot driver domain, vifX.Y = NO-CARRIER?"):
> To implement reuse_domid in a sane way, either the toolstack needs to
> manage all domids and always sets domid when creating domain or the
> hypervisor needs to cooperate -- to have interface to reserve /
> pre-alloca
> -Original Message-
> From: Roger Pau Monne
> Sent: 30 April 2018 16:12
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; qemu-bl...@nongnu.org; qemu-
> de...@nongnu.org; Anthony Perard ; Kevin
> Wolf ; Stefano Stabellini ; Max
> Reitz
> Subject: Re: [Xen-devel] [PATCH 2/4] block/
On Mon, Apr 30, 2018 at 01:01:37PM +0100, Paul Durrant wrote:
> The grant copy operation was added to libxengnttab in Xen 4.8.0. If grant
> copy is available then data from the guest will be copied rather than
> mapped.
> The xen_disk source can be significantly simplified by removing this now
> re
Hi Mirela,
On 27/04/18 18:12, Mirela Simonovic wrote:
When a CPU is hot-unplugged the maintenance interrupt has to be
released in order to free the memory that was allocated when the CPU
was hotplugged and interrupt requested. The interrupt was requested
using request_irq() which is called from
Hi Mirela,
On 27/04/18 18:12, Mirela Simonovic wrote:
In existing code the virtual paging for non-boot CPUs is setup only on boot.
The setup is triggered from start_xen() after all CPUs are brought online.
In other words, the initialization of VTCR_EL2 register is done out of the
cpu_up/start_se
>>> On 30.04.18 at 16:41, wrote:
> Jan Beulich writes ("Re: [PATCH for-4.11 v2 0/2] Add Designated Reviewer (R:)
> to MAINTAINERS (plus a test case)"):
>> On 30.04.18 at 15:29, wrote:
>> > That is clearer: I copied the text from the Linux maintainers file.
>>
>> Ah, indeed. So far it wasn't re
Jan Beulich writes ("Re: [PATCH for-4.11 v2 0/2] Add Designated Reviewer (R:)
to MAINTAINERS (plus a test case)"):
> On 30.04.18 at 15:29, wrote:
> > That is clearer: I copied the text from the Linux maintainers file.
>
> Ah, indeed. So far it wasn't really clear to me whether "designated" impl
Lars Kurth writes ("Re: [PATCH for-4.11 v2 0/2] Add Designated Reviewer (R:) to
MAINTAINERS (plus a test case)"):
> On 30/04/2018, 14:39, "George Dunlap" wrote:
>
> I wouldn't object to someone checking it in now, however; I think all
> the committers have had a chance to object, and mos
Lars Kurth writes ("Re: [PATCH for-4.11 v2 1/2] Replace occurances of xen.org
with xenproject.org"):
> On 30/04/2018, 14:38, "Ian Jackson" wrote:
>
> Lars Kurth writes ("[PATCH for-4.11 v2 1/2] Replace occurances of xen.org
> with xenproject.org"):
> > This is a general clean-up activi
Thanks for this. It looks like it will be very useful. I have
reviewed your script in detail.
My review is quite picky, mainly about error handling.
Also I have a lot of style comments: where I say "so and so would be
more perlish" you should feel free to leave it as it is if you prefer.
(I wou
Hi Mirela,
On 27/04/18 18:12, Mirela Simonovic wrote:
During the system suspend to RAM non-boot CPUs will be hotplugged.
This will be triggered via disable_nonboot_cpus() call. When
hotplugged the CPU will end up in an infinite wfi loop in stop_cpu().
This patch adds PSCI CPU_OFF call to the EL3
Hi,
On 27/04/18 18:12, Mirela Simonovic wrote:
Guests attempt to write into these registers on resume (for example Linux).
Without this patch a data abort exception will be raised to the guest.
This patch handles the write access by ignoring it, but only if the value
to be written is zero. This
Hi,
On 28/04/18 10:08, Amit Singh Tomar wrote:
> While working on MVEBU uart driver, Julien pointed out that (uart->irq > 0)
> check is unnecessary during irq set up.if ever there is an invalid irq, driver
> initialization itself would be bailed out from platform_get_irq.
>
> This patch would rem
Hi,
On 30/04/18 09:19, Jan Beulich wrote:
On 28.04.18 at 11:08, wrote:
While working on MVEBU uart driver, Julien pointed out that (uart->irq > 0)
check is unnecessary during irq set up.if ever there is an invalid irq, driver
initialization itself would be bailed out from platform_get_irq.
Th
>>> On 25.04.18 at 11:51, wrote:
> --- a/xen/arch/x86/cpu/intel_cacheinfo.c
> +++ b/xen/arch/x86/cpu/intel_cacheinfo.c
> @@ -103,7 +103,7 @@ int cpuid4_cache_lookup(int index, struct cpuid4_info
> *this_leaf)
> return 0;
> }
>
> -static int find_num_cache_leaves(void)
> +int find_num_cac
On 30/04/2018, 14:38, "Ian Jackson" wrote:
Lars Kurth writes ("[PATCH for-4.11 v2 1/2] Replace occurances of xen.org
with xenproject.org"):
> This is a general clean-up activity. It also avoids mails being
> sent to xen-devel@lists.xenproject.org and xen-de...@lists.xen.org
>
On 30/04/2018, 14:39, "George Dunlap" wrote:
On 04/30/2018 02:23 PM, Ian Jackson wrote:
> Jan Beulich writes ("Re: [PATCH for-4.11 v2 0/2] Add Designated Reviewer
(R:) to MAINTAINERS (plus a test case)"):
>> On 30.04.18 at 10:21, wrote:
>>> On 30/04/2018, 08:57, "Jan Beulich"
On 04/30/2018 02:23 PM, Ian Jackson wrote:
> Jan Beulich writes ("Re: [PATCH for-4.11 v2 0/2] Add Designated Reviewer (R:)
> to MAINTAINERS (plus a test case)"):
>> On 30.04.18 at 10:21, wrote:
>>> On 30/04/2018, 08:57, "Jan Beulich" wrote:
> ...
>>> That is my fault: I got into trouble with gi
>>> On 30.04.18 at 15:29, wrote:
>
> On 30/04/2018, 14:23, "Ian Jackson" wrote:
>
> Jan Beulich writes ("Re: [PATCH for-4.11 v2 0/2] Add Designated Reviewer
> (R:) to MAINTAINERS (plus a test case)"):
> > On 30.04.18 at 10:21, wrote:
> > > On 30/04/2018, 08:57, "Jan Beulich" wr
On 04/30/2018 02:23 PM, Ian Jackson wrote:
> Jan Beulich writes ("Re: [PATCH for-4.11 v2 0/2] Add Designated Reviewer (R:)
> to MAINTAINERS (plus a test case)"):
>> On 30.04.18 at 10:21, wrote:
>>> On 30/04/2018, 08:57, "Jan Beulich" wrote:
> ...
>>> That is my fault: I got into trouble with gi
Lars Kurth writes ("[PATCH for-4.11 v2 1/2] Replace occurances of xen.org with
xenproject.org"):
> This is a general clean-up activity. It also avoids mails being
> sent to xen-devel@lists.xenproject.org and xen-de...@lists.xen.org
> when used with add_maintainers.pl/git send-email
Acked-by: Ian
On 30/04/2018, 14:23, "Ian Jackson" wrote:
Jan Beulich writes ("Re: [PATCH for-4.11 v2 0/2] Add Designated Reviewer
(R:) to MAINTAINERS (plus a test case)"):
> On 30.04.18 at 10:21, wrote:
> > On 30/04/2018, 08:57, "Jan Beulich" wrote:
...
> > That is my fault: I got int
>>> On 25.04.18 at 16:42, wrote:
> On Wed, Apr 25, 2018 at 12:42:42PM +0200, Manuel Bouyer wrote:
>> > Without line numbers associated with at least the top stack trace entry
>> > I can only guess what it might be - could you give the patch below a try?
>> > (This may not be the final patch, as I'
Juergen Gross writes ("Re: [PATCH] tools: prepend to PKG_CONFIG_PATH when
configuring qemu"):
> On 26/04/18 19:41, Stewart Hildebrand wrote:
> > A user may choose to set his/her own PKG_CONFIG_PATH, which is useful in the
> > case of cross-compiling. We don't want to completely override the
> > P
Jan Beulich writes ("Re: [PATCH for-4.11 v2 0/2] Add Designated Reviewer (R:)
to MAINTAINERS (plus a test case)"):
> On 30.04.18 at 10:21, wrote:
> > On 30/04/2018, 08:57, "Jan Beulich" wrote:
...
> > That is my fault: I got into trouble with git and must have done something
> > wrong. If it h
On 29/04/18 11:11, Minjun Hong wrote:
> Hi.
> I'm looking for a point where address translation (guest virtual
> address to machine address) occurs in Xen.
> Of course, I mean when TLB miss has occured.
This question makes me wonder whether you are more familiar with PowerPC
than x86. In x86, the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2018-10471 / XSA-259
version 3
x86: PV guest may crash Xen with XPTI
UPDATES IN VERSION 3
CVE assigned.
ISSUE DESCRIPTION
=
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2018-10472 / XSA-258
version 3
Information leak via crafted user-supplied CDROM
UPDATES IN VERSION 3
CVE assigned.
ISSUE DESCRIPTION
=
flight 74650 distros-debian-sid real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74650/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-i386-sid-netboot-pvgrub 10 debian-di-install fail like 74636
test-armhf-armhf-armhf-sid-n
The grant copy operation was added to libxengnttab in Xen 4.8.0 (released
nearly 18 months ago) but the xen_disk PV backend QEMU is still carrying
a significant amount of code purely to remain compatible with older
versions of Xen.
As can be inferred from the diff stats below, removing this suppor
The grant copy operation was added to libxengnttab in Xen 4.8.0. If grant
copy is available then persistent grants will not be used.
The xen_disk source can be siginificantly simplified by removing this now
redundant code.
Signed-off-by: Paul Durrant
---
Cc: Stefano Stabellini
Cc: Anthony Perard
Certain functions in xen_disk are called with a pointer to xendev
(struct XenDevice *). They then use continer_of() to acces the surrounding
blkdev (struct XenBlkDev) but then in various places use &blkdev->xendev
when use of the original xendev pointer is shorter to express and clearly
equivalent.
Since xen_disk now always copies data to and from a guest there is no need
to maintain a vector entry corresponding to every page of a request.
This means there is less per-request state to maintain so the ioreq
structure can shrink significantly.
Signed-off-by: Paul Durrant
---
Cc: Stefano Stabe
The grant copy operation was added to libxengnttab in Xen 4.8.0. If grant
copy is available then data from the guest will be copied rather than
mapped.
The xen_disk source can be significantly simplified by removing this now
redundant code.
Signed-off-by: Paul Durrant
---
Cc: Stefano Stabellini
On 30/04/18 12:37, Jan Beulich wrote:
> --- a/xen/arch/x86/hvm/svm/entry.S
> +++ b/xen/arch/x86/hvm/svm/entry.S
> @@ -61,24 +61,14 @@ UNLIKELY_START(ne, nsvm_hap)
> jmp .Lsvm_do_resume
> __UNLIKELY_END(nsvm_hap)
>
> -call svm_asid_handle_vmrun
> +mov %rsp, %rdi
> +
While the main problem to be addressed here is the issue of what so far
was named "vmcb_in_sync" starting out with the wrong value (should have
been true instead of false, to prevent performing a VMSAVE without ever
having VMLOADed the vCPU's state), go a step further and make the
sync-ed state a t
The register values copying doesn't need doing in assembly. The VMLOAD
invocation can also be further deferred (and centralized). Therefore
replace the svm_asid_handle_vmrun() invocation wiht one of the new
helper.
Similarly move the VM exit side register value copying into
svm_vmexit_handler().
This run is configured for baseline tests only.
flight 74649 xen-4.10-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74649/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-xl-xsm 6 xen-install fail
osstest service owner writes ("[xen-unstable test] 122451: regressions - FAIL"):
> flight 122451 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/122451/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> t
Only patch 1 is clearly meant for 4.11. The second patch, however, eliminates
a (theoretical) window the first patch still leaves, so should at least be
considered.
1: re-work VMCB sync-ing
2: introduce a VM entry helper
Signed-off-by: Jan Beulich
Hi Minjun,
On Mon, 30 Apr 2018 17:17:36 +0900
Minjun Hong wrote:
> On Mon, Apr 30, 2018 at 3:44 PM, Petr Tesarik wrote:
>
> > Hi Minjun,
> >
> > On Sun, 29 Apr 2018 19:11:30 +0900
> > Minjun Hong wrote:
> >
> > >[...]
> > > My question is,
> > >
> > > 1. Is it sure that the function will be
>>> On 30.04.18 at 10:21, wrote:
>
> On 30/04/2018, 08:57, "Jan Beulich" wrote:
>
> >>> On 27.04.18 at 20:01, wrote:
> > This follows up from a conversation after the April x86 community call,
> in
> > which I had
> > the following action: Lars to propose fixing CC issue in
On 04/30/2018 11:11 AM, Jan Beulich wrote:
On 28.04.18 at 08:13, wrote:
>> On 04/28/2018 12:30 AM, Tamas K Lengyel wrote:
>>> On Mon, Apr 23, 2018 at 2:00 AM, Alexandru Isaila
>>> wrote:
This patch is adding a way to enable/disable inguest pagefault
events. It introduces the xc_mon
On 30/04/2018, 08:57, "Jan Beulich" wrote:
>>> On 27.04.18 at 20:01, wrote:
> This follows up from a conversation after the April x86 community call,
in
> which I had
> the following action: Lars to propose fixing CC issue in
xen.git:MAINTAINERS
> copying
> the R
>>> On 28.04.18 at 11:08, wrote:
> While working on MVEBU uart driver, Julien pointed out that (uart->irq > 0)
> check is unnecessary during irq set up.if ever there is an invalid irq, driver
> initialization itself would be bailed out from platform_get_irq.
>
> This patch would remove similar ch
1 - 100 of 105 matches
Mail list logo
