flight 139169 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139169/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-ws16-amd64 16 guest-localmigrate/x10 fail REGR. vs.
139032
Tests
flight 139158 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139158/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-xsm 16 guest-start/debian.repeat fail REGR. vs. 139100
Tests which did
On Fri, Jul 19, 2019 at 7:25 AM Jan Beulich wrote:
>
> All,
>
> the release is due in early August. Please point out backports you
> find missing from the respective staging branch, but which you
> consider relevant.
Please can the following be added to the branch:
480800c769
argo: warn sendv()
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-examine
testid reboot
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu
flight 139152 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139152/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops 6 kernel-build fail REGR. vs. 129313
Tests which are
Thanks for doing this, it's something I've been hoping someone would do
for a long time.
While I kinda wish we had performance data for each individual patch (at
least the behavior-changing ones), this does look like a good
improvement. That might, for instance, tell is a bit about how the
CCing relevant maintainers as well (sorry for not doing it first time around)
On Fri, Jul 19, 2019 at 12:31 PM Roman Shaposhnik wrote:
>
> Hi!
>
> we're using Xen on Advantech ARK-2250 Embedded Box PC:
>
>
On Wed, 26 Jun 2019, Stefano Stabellini wrote:
> On Wed, 26 Jun 2019, Juergen Gross wrote:
> > On 26.06.19 14:21, Chao Gao wrote:
> > > On Wed, Jun 26, 2019 at 08:17:50AM +0200, Juergen Gross wrote:
> > > > On 24.06.19 20:47, Stefano Stabellini wrote:
> > > > > + xen-devel
> > > > >
> > > > > On
The pull request you sent on Fri, 19 Jul 2019 08:09:25 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
> for-linus-5.3a-rc1-tag
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/b5d72dda8976e878be47415b94bca8465d1fa22d
Thank you!
--
Deet-doot-dot,
Hi!
we're using Xen on Advantech ARK-2250 Embedded Box PC:
https://www.elmark.com.pl/web/uploaded/karty_produktow/advantech/ark-2250l/ark-2250l_instrukcja-uzytkownika.pdf
After upgrading to Xen 4.12.0 from 4.11.0 we now have to utilize iommu=no-igfx
workaround as per:
On 19/07/2019 17:16, Jan Beulich wrote:
> On 19.07.2019 17:56, Andrew Cooper wrote:
>> On 16/07/2019 17:36, Jan Beulich wrote:
>>> At the same time restrict its scope to just the single source file
>>> actually using it, and abstract accesses by introducing a union of
>>> pointers. (A union of the
On Tue, Jul 16, 2019 at 04:41:21PM +, Jan Beulich wrote:
> When there are sufficiently many devices listed in the ACPI tables (no
> matter if they actually exist), output may take way longer than the
> watchdog would like.
>
> Signed-off-by: Jan Beulich
Acked-by: Brian Woods
> ---
> v3:
On Tue, Jul 16, 2019 at 04:40:33PM +, Jan Beulich wrote:
> In order for the CPUs to use x2APIC mode, the IOMMU(s) first need to be
> switched into suitable state.
>
> The post-AP-bringup IRQ affinity adjustment is done also for the non-
> x2APIC case, matching what VT-d does.
>
>
On Tue, Jul 16, 2019 at 04:39:58PM +, Jan Beulich wrote:
> In order to be able to express all possible destinations we need to make
> use of this non-MSI-capability based mechanism. The new IRQ controller
> structure can re-use certain MSI functions, though.
>
> For now general and PPR
On Tue, Jul 16, 2019 at 04:39:34PM +, Jan Beulich wrote:
> Early enabling (to enter x2APIC mode) requires deferring of the IRQ
> setup. Code to actually do that setup in the x2APIC case will get added
> subsequently.
>
> Signed-off-by: Jan Beulich
> Acked-by: Andrew Cooper
Acked-by: Brian
On Tue, Jul 16, 2019 at 04:39:10PM +, Jan Beulich wrote:
> Mapping the MMIO space and obtaining feature information needs to happen
> slightly earlier, such that for x2APIC support we can set XTEn prior to
> calling amd_iommu_update_ivrs_mapping_acpi() and
> amd_iommu_setup_ioapic_remapping().
On Tue, Jul 16, 2019 at 04:37:51PM +, Jan Beulich wrote:
> The functions will want to know IOMMU properties (specifically the IRTE
> size) subsequently.
>
> Rather than introducing a second error path bogusly returning -E... from
> amd_iommu_read_ioapic_from_ire(), also change the existing
On Tue, 2019-05-28 at 12:33 +0200, Juergen Gross wrote:
> Add a scheduling granularity enum ("cpu", "core", "socket") for
> specification of the scheduling granularity. Initially it is set to
> "cpu", this can be modified by the new boot parameter (x86 only)
> "sched-gran".
>
> According to the
flight 139157 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139157/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 296c908c6968910ea7c4496b94cfba1e52212de2
baseline version:
ovmf
On Tue, Jul 16, 2019 at 04:37:26PM +, Jan Beulich wrote:
> The function will want to know IOMMU properties (specifically the IRTE
> size) subsequently.
>
> Correct indentation of one of the call sites at this occasion.
>
> Signed-off-by: Jan Beulich
Acked-by: Brian Woods
> ---
> v3: New.
On Tue, Jul 16, 2019 at 04:37:04PM +, Jan Beulich wrote:
> Both users will want to know IOMMU properties (specifically the IRTE
> size) subsequently. Leverage this to avoid pointless calls to the
> callback when IVRS mapping table entries are unpopulated. To avoid
> leaking interrupt remapping
On Tue, Jul 16, 2019 at 04:36:34PM +, Jan Beulich wrote:
> At the same time restrict its scope to just the single source file
> actually using it, and abstract accesses by introducing a union of
> pointers. (A union of the actual table entries is not used to make it
> impossible to [wrongly,
On Tue, Jul 16, 2019 at 04:36:06PM +, Jan Beulich wrote:
> Also introduce a field in struct amd_iommu caching the most recently
> written control register. All writes should now happen exclusively from
> that cached value, such that it is guaranteed to be up to date.
>
> Take the opportunity
On Tue, Jul 16, 2019 at 04:35:08PM +, Jan Beulich wrote:
> The interrupt remapping in-use bitmaps were leaked in all cases. The
> ring buffers and the mapping of the MMIO space were leaked for any IOMMU
> that hadn't been enabled yet.
>
> Signed-off-by: Jan Beulich
Acked-by: Brian Woods
>
On Tue, 2019-05-28 at 12:32 +0200, Juergen Gross wrote:
> Instead of returning a physical cpu number let pick_cpu() return a
> scheduler resource instead. Rename pick_cpu() to pick_resource() to
> reflect that change.
>
> Signed-off-by: Juergen Gross
>
Reviewed-by: Dario Faggioli
with:
> ---
flight 139159 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139159/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
freebsd 37af220308d220ce946683e1a2e80b352fb9e856
baseline version:
freebsd
On 16/07/2019 17:41, Jan Beulich wrote:
> When there are sufficiently many devices listed in the ACPI tables (no
> matter if they actually exist), output may take way longer than the
> watchdog would like.
>
> Signed-off-by: Jan Beulich
> ---
> v3: New.
> ---
> TBD: Seeing the volume of output I
flight 139134 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139134/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR.
vs. 133580
On Tue, 2019-05-28 at 12:32 +0200, Juergen Gross wrote:
> Add a scheduling abstraction layer between physical processors and
> the
> schedulers by introducing a struct sched_resource. Each scheduler
> unit
> running is active on such a scheduler resource. For the time being
> there is one struct
On 16/07/2019 17:40, Jan Beulich wrote:
> Flushing didn't get done along the lines of what the specification says.
> Mark entries to be updated as not remapped (which will result in
> interrupt requests to get target aborted, but the interrupts should be
> masked anyway at that point in time),
On Tue, 2019-05-28 at 12:32 +0200, Juergen Gross wrote:
> Add a scheduling abstraction layer between physical processors and
> the
> schedulers by introducing a struct sched_resource. Each scheduler
> unit
> running is active on such a scheduler resource. For the time being
> there is one struct
On Fri, 2019-07-19 at 12:59 +, Jan Beulich wrote:
> On 19.07.2019 14:37, Paul Durrant wrote:
> > > From: Jan Beulich
> > > Sent: 19 July 2019 13:32
> > >
> > > On 19.07.2019 14:11, Paul Durrant wrote:
> > > > > -Original Message-
> > > > > From: Petre Ovidiu PIRCALABU
> > > > >
On 16/07/2019 17:40, Jan Beulich wrote:
> In order for the CPUs to use x2APIC mode, the IOMMU(s) first need to be
> switched into suitable state.
>
> The post-AP-bringup IRQ affinity adjustment is done also for the non-
> x2APIC case, matching what VT-d does.
>
> Signed-off-by: Jan Beulich
On 16/07/2019 17:39, Jan Beulich wrote:
> --- a/xen/include/asm-x86/hvm/svm/amd-iommu-defs.h
> +++ b/xen/include/asm-x86/hvm/svm/amd-iommu-defs.h
> @@ -416,6 +416,25 @@ union amd_iommu_ext_features {
> } flds;
> };
>
> +/* x2APIC Control Registers */
> +#define
On 16/07/2019 17:38, Jan Beulich wrote:
> This is in preparation of actually enabling x2APIC mode, which requires
> this wider IRTE format to be used.
>
> A specific remark regarding the first hunk changing
> amd_iommu_ioapic_update_ire(): This bypass was introduced for XSA-36,
> i.e. by
On Fri, 2019-07-19 at 07:07 +0200, Juergen Gross wrote:
> On 19.07.19 02:01, Dario Faggioli wrote:
> > On Tue, 2019-05-28 at 12:32 +0200, Juergen Gross wrote:
> > >
> > How about a ',' between domain and build?
>
> Okay.
> > "over all vcpus of a sched_unit" ?
>
> Oh, of course!
>
Thanks.
> >
On Fri, 2019-07-19 at 07:03 +0200, Juergen Gross wrote:
> On 19.07.19 00:52, Dario Faggioli wrote:
> > On Tue, 2019-05-28 at 12:32 +0200, Juergen Gross wrote:
> > > This prepares making the different schedulers vcpu agnostic.
>
> > But shouldn't then the struct be called csched2_unit, and cited
>
On Fri, 2019-07-19 at 06:56 +0200, Juergen Gross wrote:
> On 18.07.19 19:57, Dario Faggioli wrote:
> > On Tue, 2019-05-28 at 12:32 +0200, Juergen Gross wrote:
> > >
> > However, I don't see much value in not doing what's done here in
> > patch
> > 4 already (it's pretty much only line changed by
On Fri, 2019-07-19 at 06:49 +0200, Juergen Gross wrote:
> On 18.07.19 19:44, Dario Faggioli wrote:
> > On Tue, 2019-05-28 at 12:32 +0200, Juergen Gross wrote:
> > One thing that came to mind, is that the various function
> > parameters
> > and local variables called 'unit', could be called 'su'.
>
flight 139140 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139140/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-arndale broken in 139110
Tests
Hi Jan,
Jan Beulich writes:
> For easy spotting of struct/union/enum definitions we already commonly
> place the opening braces on the initial line of such a definition.
>
> We also often don't place the opening brace of an initializer on a
> separate line.
>
> And finally for compound literals
On 16/07/2019 17:37, Jan Beulich wrote:
> The functions will want to know IOMMU properties (specifically the IRTE
> size) subsequently.
>
> Rather than introducing a second error path bogusly returning -E... from
> amd_iommu_read_ioapic_from_ire(), also change the existing one to follow
> VT-d in
On Fri, Jul 05, 2019 at 02:21:13PM +0200, Laszlo Ersek wrote:
> The patches on the list are malformed. They have
>
> Content-Transfer-Encoding: quoted-printable
>
> which is fine, in itself; however, they have CR-CR-LF line terminators.
>
> For example, from the first patch:
>
> diff --git
On 16/07/2019 17:37, Jan Beulich wrote:
> The function will want to know IOMMU properties (specifically the IRTE
> size) subsequently.
>
> Correct indentation of one of the call sites at this occasion.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
On 16/07/2019 17:37, Jan Beulich wrote:
> Both users will want to know IOMMU properties (specifically the IRTE
> size) subsequently. Leverage this to avoid pointless calls to the
> callback when IVRS mapping table entries are unpopulated. To avoid
> leaking interrupt remapping tables (bogusly)
On 19.07.2019 18:23, Andrew Cooper wrote:
> On 16/07/2019 17:35, Jan Beulich wrote:
>> This also takes care of several of the shift values wrongly having been
>> specified as hex rather than dec.
>>
>> Take the opportunity and
>> - replace a readl() pair by a single readq(),
>> - add further
On 16/07/2019 17:35, Jan Beulich wrote:
> This also takes care of several of the shift values wrongly having been
> specified as hex rather than dec.
>
> Take the opportunity and
> - replace a readl() pair by a single readq(),
> - add further fields.
>
> Signed-off-by: Jan Beulich
CI is happy
On 8/25/18 1:22 AM, Dario Faggioli wrote:
> It is all the time that we call vcpu_deassing() that the vcpu _must_ be
> assigned to a pCPU, and hence that such pCPU can't be free.
>
> Therefore, move the ASSERT-s which check for these properties in that
> function, where they belong better.
> ---
>
On 19.07.2019 17:56, Andrew Cooper wrote:
> On 16/07/2019 17:36, Jan Beulich wrote:
>> At the same time restrict its scope to just the single source file
>> actually using it, and abstract accesses by introducing a union of
>> pointers. (A union of the actual table entries is not used to make it
flight 139173 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139173/
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
On 8/25/18 1:22 AM, Dario Faggioli wrote:
> When a vcpu that was offline, comes back online, we do want it to either
> be assigned to a pCPU, or go into the wait list.
>
> So let's do exactly that. Detecting that a vcpu is coming back online is
> a bit tricky. Basically, if the vcpu is waking up,
On 16/07/2019 17:36, Jan Beulich wrote:
> At the same time restrict its scope to just the single source file
> actually using it, and abstract accesses by introducing a union of
> pointers. (A union of the actual table entries is not used to make it
> impossible to [wrongly, once the 128-bit form
On Fri, Jul 19, 2019 at 03:41:52PM +0100, Andrew Cooper wrote:
> On 19/07/2019 15:33, Laszlo Ersek wrote:
> > On 07/19/19 12:20, Anthony PERARD wrote:
> >> On Fri, Jul 05, 2019 at 02:57:06PM +0100, Andrew Cooper wrote:
> >>> On 04/07/2019 15:42, Anthony PERARD wrote:
> diff --git
On Thu, 2019-07-18 at 14:09 +0100, George Dunlap wrote:
> On 7/17/19 7:39 PM, Dario Faggioli wrote:
> > Point is the work of removing such vCPU from any CPU and from the
> > wait
> > list has been done already, in null_vcpu_sleep(), while the vCPU
> > was
> > going offline. So, here, we only need
flight 139147 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139147/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-qcow2 15 guest-start/debian.repeat fail REGR. vs.
139037
Tests which did
On 16/07/2019 17:35, Jan Beulich wrote:
> The interrupt remapping in-use bitmaps were leaked in all cases. The
> ring buffers and the mapping of the MMIO space were leaked for any IOMMU
> that hadn't been enabled yet.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
On 03/07/2019 14:04, Jan Beulich wrote:
> From: Ross Lagerwall
>
> Signed-off-by: Ross Lagerwall
>
> Make handling in do_pm_op() more homogeneous: Before interpreting
> op->cpuid as such, handle all operations not acting on a particular
> CPU. Also expose the setting via xenpm.
>
>
On 03/07/2019 14:03, Jan Beulich wrote:
> From: Ross Lagerwall
>
> Allow limiting the max C-state sub-state by appending to the max_cstate
> command-line parameter. E.g. max_cstate=1,0
> The limit only applies to the highest legal C-state. For example:
> max_cstate = 1, max_csubstate = 0 ==>
On 03/07/2019 14:01, Jan Beulich wrote:
> At least for more recent CPUs, following what BKDG / PPR suggest for the
> BIOS to surface via ACPI we can make ourselves independent of Dom0
> uploading respective data.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
On 03/07/2019 13:59, Jan Beulich wrote:
> While the MWAIT idle driver already takes it to mean an actual C state,
> the ACPI idle driver so far used it as a list index. The list index,
> however, is an implementation detail of Xen and affected by firmware
> settings (i.e. not necessarily uniform
Hi Rich,
On 19/07/2019 14:50, Rich Persaud wrote:
On Jul 19, 2019, at 09:31, Julien Grall wrote:
On 19/07/2019 14:24, Julien Grall wrote:
Hi Tamas,
On 19/07/2019 14:14, Tamas K Lengyel wrote:
On Fri, Jul 19, 2019 at 7:11 AM Julien Grall wrote:
Hi Tamas,
On 19/07/2019 14:00, Tamas K
On 17/07/2019 17:02, Jan Beulich wrote:
> Array indexes used in the MSR read/write emulation functions as well as
> the direct VMX / APIC-V hook are derived from guest controlled values.
> Restrict their ranges to limit the side effects of speculative
> execution.
>
> Along these lines also
On 19/07/2019 15:33, Laszlo Ersek wrote:
> On 07/19/19 12:20, Anthony PERARD wrote:
>> On Fri, Jul 05, 2019 at 02:57:06PM +0100, Andrew Cooper wrote:
>>> On 04/07/2019 15:42, Anthony PERARD wrote:
diff --git a/OvmfPkg/XenResetVector/Ia16/ResetVectorVtf0.asm
On 07/19/19 12:20, Anthony PERARD wrote:
> On Fri, Jul 05, 2019 at 02:57:06PM +0100, Andrew Cooper wrote:
>> On 04/07/2019 15:42, Anthony PERARD wrote:
>>> diff --git a/OvmfPkg/XenResetVector/Ia16/ResetVectorVtf0.asm
>>> b/OvmfPkg/XenResetVector/Ia16/ResetVectorVtf0.asm
>>> new file mode 100644
All,
the release is due in early August. Please point out backports you
find missing from the respective staging branch, but which you
consider relevant. The one commit I've queued already on top of
what was just pushed is
ec2ab491b5 x86/ept: pass correct level to p2m_entry_modify
Jan
On 7/19/19 4:38 PM, Jan Beulich wrote:
On 19.07.2019 15:30, Razvan Cojocaru wrote:
On 7/19/19 4:18 PM, Jan Beulich wrote:
On 19.07.2019 14:34, Alexandru Stefan ISAILA wrote:
On 18.07.2019 15:58, Jan Beulich wrote:
On 03.07.2019 12:56, Alexandru Stefan ISAILA wrote:
A/D bit writes (on page
On 19/07/2019 14:53, Jan Beulich wrote:
> On 16.07.2019 14:27, Andrew Cooper wrote:
>> Bugfixes:
>>
>> 65c165d6595f - x86/xstate: Don't special case feature collection
>> 013896cb8b2f - x86/msr: Fix handling of
>> MSR_AMD_PATCHLEVEL/MSR_IA32_UCODE_REV
>> 7d161f653755 - x86/svm: Fix svm_vmcb_dump()
This reduces the number of parameters of the function to two, and
simplifies some of the calling sites.
While there convert {IGD/IOH}_DEV to be a pci_sbdf_t itself instead of
a device number.
Signed-off-by: Roger Pau Monné
Acked-by: Brian Woods
Reviewed-by: Kevin Tian
---
Cc: Jan Beulich
Cc:
This reduces the number of parameters of the function to two, and
simplifies some of the calling sites.
Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulich
Acked-by: Brian Woods
Reviewed-by: Kevin Tian
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
Cc: George Dunlap
Cc: Ian Jackson
This reduces the number of parameters of the function to two, and
simplifies some of the calling sites.
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
Cc: "Roger Pau Monné"
Cc: George Dunlap
Cc: Ian Jackson
Cc: Julien Grall
Cc: Konrad Rzeszutek Wilk
Cc:
Hello,
The following are the remaining patches from my 'expand usage of
pci_sbdf_t' previous series except for the one that introduces a custom
printf formatter for pci_sbdf_t.
I've also pushed them to my git tree at:
git://xenbits.xen.org/people/royger/xen.git pci_sbdf_t
Thanks, Roger.
Roger
This reduces the number of parameters of the function to two, and
simplifies some of the calling sites.
Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulich
Acked-by: Brian Woods
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
Cc: George Dunlap
Cc: Ian Jackson
Cc: Julien Grall
Cc:
This reduces the number of parameters of the function to two, and
simplifies some of the calling sites.
Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulich
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
Cc: George Dunlap
Cc: Ian Jackson
Cc: Julien Grall
Cc: Konrad Rzeszutek Wilk
This reduces the number of parameters of the function to two, and
simplifies some of the calling sites.
Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulich
Acked-by: Brian Woods
Reviewed-by: Kevin Tian
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
Cc: George Dunlap
Cc: Ian Jackson
On Mon, Jul 15, 2019 at 01:46:57PM +0200, Roger Pau Monné wrote:
> On Thu, Jul 04, 2019 at 03:42:04PM +0100, Anthony PERARD wrote:
> > diff --git a/OvmfPkg/XenResetVector/Ia16/ResetVectorVtf0.asm
> > b/OvmfPkg/XenResetVector/Ia16/ResetVectorVtf0.asm
> > new file mode 100644
> > index
On 18.07.19 17:14, Sergey Dyasli wrote:
On 18/07/2019 15:48, Juergen Gross wrote:
On 15.07.19 16:08, Sergey Dyasli wrote:
On 05/07/2019 14:56, Dario Faggioli wrote:
On Fri, 2019-07-05 at 14:17 +0100, Sergey Dyasli wrote:
1) This crash is quite likely to happen:
[2019-07-04 18:22:46 UTC]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory XSA-300
version 2
Linux: No grant table and foreign mapping limits
UPDATES IN VERSION 2
Drop inapplicable "Deployment during embargo"
On 16.07.2019 14:27, Andrew Cooper wrote:
> Bugfixes:
>
> 65c165d6595f - x86/xstate: Don't special case feature collection
> 013896cb8b2f - x86/msr: Fix handling of
> MSR_AMD_PATCHLEVEL/MSR_IA32_UCODE_REV
> 7d161f653755 - x86/svm: Fix svm_vmcb_dump() when used in current context
> 9b757bdc1794 -
On Fri, Jul 19, 2019 at 7:31 AM Julien Grall wrote:
>
>
>
> On 19/07/2019 14:24, Julien Grall wrote:
> > Hi Tamas,
> >
> > On 19/07/2019 14:14, Tamas K Lengyel wrote:
> >> On Fri, Jul 19, 2019 at 7:11 AM Julien Grall wrote:
> >>>
> >>> Hi Tamas,
> >>>
> >>> On 19/07/2019 14:00, Tamas K Lengyel
On Jul 19, 2019, at 09:31, Julien Grall wrote:
>> On 19/07/2019 14:24, Julien Grall wrote:
>> Hi Tamas,
>>> On 19/07/2019 14:14, Tamas K Lengyel wrote:
On Fri, Jul 19, 2019 at 7:11 AM Julien Grall wrote:
Hi Tamas,
> On 19/07/2019 14:00, Tamas K Lengyel wrote:
>> On
On 7/19/19 2:19 PM, Nicolas Belouin wrote:
>
>
> On 7/19/19 1:04 PM, George Dunlap wrote:
>> On 7/19/19 11:24 AM, Nicolas Belouin wrote:
>>>
>>> On 7/19/19 12:09 PM, George Dunlap wrote:
On 7/19/19 11:03 AM, Nicolas Belouin wrote:
> On 7/19/19 10:50 AM, George Dunlap wrote:
>>> On
On 19/07/2019 14:31, Jan Beulich wrote:
> On 19.07.2019 14:41, Andrew Cooper wrote:
>> On 19/07/2019 13:25, Paul Durrant wrote:
>>> When commit 3f8f1228 "x86/mm: add HYPERVISOR_memory_op to acquire guest
>>> resources" introduced the concept of directly mapping some guest resources,
>>> it was
On 19.07.2019 15:30, Razvan Cojocaru wrote:
> On 7/19/19 4:18 PM, Jan Beulich wrote:
>> On 19.07.2019 14:34, Alexandru Stefan ISAILA wrote:
>>> On 18.07.2019 15:58, Jan Beulich wrote:
On 03.07.2019 12:56, Alexandru Stefan ISAILA wrote:
> A/D bit writes (on page walks) can be considered
On Fri, Jul 19, 2019 at 7:34 AM Julien Grall wrote:
>
> Hi Tamas,
>
> On 19/07/2019 14:05, Tamas K Lengyel wrote:
> > On Fri, Jul 19, 2019 at 3:03 AM Julien Grall wrote:
> >>
> >> Hi,
> >>
> >> On 18/07/2019 19:34, Tamas K Lengyel wrote:
> >>> On Thu, Jul 18, 2019 at 11:59 AM Andrew Cooper
> >>>
On 16.07.19 17:45, Sergey Dyasli wrote:
On 05/07/2019 14:17, Sergey Dyasli wrote:
[2019-07-05 00:37:16 UTC] (XEN) [24907.482686] Watchdog timer detects that
CPU30 is stuck!
[2019-07-05 00:37:16 UTC] (XEN) [24907.514180] [ Xen-4.13.0-8.0.6-d x86_64
debug=y Not tainted ]
[2019-07-05
Hi Tamas,
On 19/07/2019 14:05, Tamas K Lengyel wrote:
On Fri, Jul 19, 2019 at 3:03 AM Julien Grall wrote:
Hi,
On 18/07/2019 19:34, Tamas K Lengyel wrote:
On Thu, Jul 18, 2019 at 11:59 AM Andrew Cooper
wrote:
On 18/07/2019 15:43, Tamas K Lengyel wrote:
diff --git a/CODING_STYLE
On 19.07.2019 14:41, Andrew Cooper wrote:
> On 19/07/2019 13:25, Paul Durrant wrote:
>> When commit 3f8f1228 "x86/mm: add HYPERVISOR_memory_op to acquire guest
>> resources" introduced the concept of directly mapping some guest resources,
>> it was envisaged that the memory for some resources
On 19/07/2019 14:24, Julien Grall wrote:
Hi Tamas,
On 19/07/2019 14:14, Tamas K Lengyel wrote:
On Fri, Jul 19, 2019 at 7:11 AM Julien Grall wrote:
Hi Tamas,
On 19/07/2019 14:00, Tamas K Lengyel wrote:
On Fri, Jul 19, 2019 at 2:43 AM Julien Grall wrote:
Hi Tamas,
On 18/07/2019 18:48,
On 7/19/19 4:18 PM, Jan Beulich wrote:
On 19.07.2019 14:34, Alexandru Stefan ISAILA wrote:
On 18.07.2019 15:58, Jan Beulich wrote:
On 03.07.2019 12:56, Alexandru Stefan ISAILA wrote:
A/D bit writes (on page walks) can be considered benign by an introspection
agent, so receiving vm_events for
On Fri, Jul 19, 2019 at 7:22 AM Jan Beulich wrote:
>
> On 19.07.2019 15:18, Tamas K Lengyel wrote:
> > On Fri, Jul 19, 2019 at 3:19 AM Jan Beulich wrote:
> >>
> >> Since the behavior of "diff -p" to use an unindented label as context
> >> identifier often makes it harder to review patches, make
On 16/07/2019 08:40, Jan Beulich wrote:
> In line with "x86/IRQ: desc->affinity should strictly represent the
> requested value" the internally used IRQ(s) also shouldn't be restricted
> to online ones. Make set_desc_affinity() (set_msi_affinity() then does
> by implication) cope with a NULL mask
> On Jul 18, 2019, at 10:43, Tamas K Lengyel wrote:
>
> Using astyle (http://astyle.sourceforge.net) can greatly reduce the overhead
> of
> manually checking and applying style-fixes to source-code. The included
> .astylerc is the closest approximation of the established Xen style (including
>
On 16/07/2019 08:38, Jan Beulich wrote:
> desc->arch.cpu_mask reflects the actual set of target CPUs. Don't ever
> fiddle with desc->affinity itself, except to store caller requested
> values. Note that assign_irq_vector() now takes a NULL incoming CPU mask
> to mean "all CPUs" now, rather than
Hi Tamas,
On 19/07/2019 14:14, Tamas K Lengyel wrote:
On Fri, Jul 19, 2019 at 7:11 AM Julien Grall wrote:
Hi Tamas,
On 19/07/2019 14:00, Tamas K Lengyel wrote:
On Fri, Jul 19, 2019 at 2:43 AM Julien Grall wrote:
Hi Tamas,
On 18/07/2019 18:48, Tamas K Lengyel wrote:
- Line 1025:
On 19.07.2019 15:18, Tamas K Lengyel wrote:
> On Fri, Jul 19, 2019 at 3:19 AM Jan Beulich wrote:
>>
>> Since the behavior of "diff -p" to use an unindented label as context
>> identifier often makes it harder to review patches, make explicit the
>> requirement for labels to be indented.
>>
>>
On 16/07/2019 08:37, Jan Beulich wrote:
> The flag being set may prevent affinity changes, as these often imply
> assignment of a new vector. When there's no possible destination left
> for the IRQ, the clearing of the flag needs to happen right from
> fixup_irqs().
>
> Additionally
On Fri, Jul 19, 2019 at 3:19 AM Jan Beulich wrote:
>
> Since the behavior of "diff -p" to use an unindented label as context
> identifier often makes it harder to review patches, make explicit the
> requirement for labels to be indented.
>
> Signed-off-by: Jan Beulich
This style requirement
On 7/19/19 1:04 PM, George Dunlap wrote:
> On 7/19/19 11:24 AM, Nicolas Belouin wrote:
>>
>> On 7/19/19 12:09 PM, George Dunlap wrote:
>>> On 7/19/19 11:03 AM, Nicolas Belouin wrote:
On 7/19/19 10:50 AM, George Dunlap wrote:
>> On Jul 19, 2019, at 9:47 AM, George Dunlap
>> wrote:
On 19.07.2019 14:34, Alexandru Stefan ISAILA wrote:
> On 18.07.2019 15:58, Jan Beulich wrote:
>> On 03.07.2019 12:56, Alexandru Stefan ISAILA wrote:
>>> A/D bit writes (on page walks) can be considered benign by an introspection
>>> agent, so receiving vm_events for them is a pessimization. We try
On Fri, Jul 19, 2019 at 7:11 AM Julien Grall wrote:
>
> Hi Tamas,
>
> On 19/07/2019 14:00, Tamas K Lengyel wrote:
> > On Fri, Jul 19, 2019 at 2:43 AM Julien Grall wrote:
> >>
> >> Hi Tamas,
> >>
> >> On 18/07/2019 18:48, Tamas K Lengyel wrote:
> - Line 1025: The tools needs to be able
1 - 100 of 156 matches
Mail list logo
