On 05.09.2019 01:16, Boris Ostrovsky wrote:
> On 9/3/19 5:42 AM, Jan Beulich wrote:
>>
>> For TSC I see little point in making the intercepts dynamic, hence they
>> get established right when a VMCB/VMCS gets created.
>
> Why is this not treated in the same manner as rdtsc intercepts?
Oh, indeed
Hi Sergey,
On 15.08.19 12:17, Sergey Dyasli wrote:
Hi Juergen,
The latest round of testing revealed the following 3 Xen crashes:
1. vcpu_sleep_sync() <-- vlapic_init_sipi_action()
This was seen multiple times. It tends to happen on large Windows Server
VMs (>= 12 vCPUs).
https://paste.debian.n
Despite %.12s properly limiting the number of characters read from
ident[], gcc 9 (at least up to 9.2.0) warns about the strings not
being nul-terminated:
test-cpu-policy.c:64:18: error: '%.12s' directive argument is not a
nul-terminated string [-Werror=format-overflow=]
64 | fail(
flight 140999 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140999/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-examine 8 reboot fail REGR. vs. 133580
test-amd64-i386-lib
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, September 4, 2019 9:28 PM
>
> Use appropriate types. Drop unnecessary casts. Check for failures which
> can (at least in theory because of non-obvious breakage elsewhere)
> occur, instead of ones which really can't (map_domain_page(
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, September 4, 2019 9:28 PM
>
> The two uses of pci_get_pdev_by_domain() lack proper locking, but are
> also only used to get hold of a NUMA node ID. Calculate and store the
> node ID earlier on and remove the lookups (in lieu of fixi
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, September 4, 2019 9:27 PM
>
> Drop iommu_to_drhd() altogether - there's no need for a loop here, the
> corresponding DRHD is a field in struct intel_iommu.
>
> Constify drhd_to_rhsa()'s parameter and adjust style.
>
> Signed-off-b
> From: Roger Pau Monne [mailto:roger@citrix.com]
> Sent: Wednesday, September 4, 2019 10:20 PM
>
> So that the name implies the function is used to walk the page table
> pointer passed as parameter. Drop the parent_ prefix from the level
> parameter, since the level passed is the one matching
Agenda item: Domain name service for nested virt and disaggregation
(text based on draft by Daniel Smith, who will speak to this agenda item)
If a future, minimal "L0 Xen" hypervisor can be optimized for nested
virtualization in greenfield deployments (i.e. no requirement to maintain
existing
flight 141004 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141004/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
freebsd a3dbacfc31a3c2ef7d9d4d12d4e5108f044c0701
baseline version:
freebsd f2d1759c50f
On Wed, 4 Sep 2019 12:54:55 +0100
Andrew Cooper wrote:
> On 04/09/2019 12:45, Masami Hiramatsu wrote:
> > Hi,
> >
> > These patches allow x86 instruction decoder to decode
> > xen-cpuid which has XEN_EMULATE_PREFIX, and prohibit
> > kprobes to probe on it.
> >
> > Josh reported that the objtool c
On 9/3/19 5:42 AM, Jan Beulich wrote:
>
> For TSC I see little point in making the intercepts dynamic, hence they
> get established right when a VMCB/VMCS gets created.
Why is this not treated in the same manner as rdtsc intercepts?
-boris
___
Xen-deve
flight 141000 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141000/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf adb59b633c12eae334540295092da94736bffa33
baseline version:
ovmf 48d49ea507e571c5ace75
flight 141019 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141019/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
flight 140991 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140991/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 20 guest-start/debian.repeat fail in 140955 REGR.
vs. 139698
Tests which
flight 140996 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140996/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 140964
Tests which did not suc
flight 141012 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141012/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 140980
Tests which
> Unfortunately this would mean the type assertion would be pretty long as
> well:
> hvm := di.TypeUnion.(xenlight.DomainBuildInfoTypeUnionHvm)
> hvm.[element]
Made worse by the fact that you really should check the type assertion first:
hvm, ok := di.TypeUnion.(xenlight.DomainBuildInfoTypeUn
On 04/09/2019, 19:12, "Lars Kurth" wrote:
This series proposes a concrete version of the Xen Project
CoC based on v1.4 of the Contributor Covenant. See [1]
Apologies for the badly formatted patch. It seems the normal instructions do
not work when using it on virgin git repository
> Yes, I think that's really the only option. Poking around, it looks
> like a lot of different people have recommended it; and the fact that
> it's in use by gRPC means it can't be too terrible a solution.
Yeah, having worked with generated gRPC code I don't think it's too bad.
> The interface
Specific changes to the baseline:
* Replace list of positive behaviors with link to separate process
* Replace maintainers with project leadership
(except in our pledge where maintainers is more appropriate)
* Add 'of all sub-projects' to clarify scope of CoC
* Rename Enforcement
* Replace "proje
This series proposes a concrete version of the Xen Project
CoC based on v1.4 of the Contributor Covenant. See [1]
It also reflects the discussion in [2] and some private
discussions on IRC to identify initial members of the Xen
Project???s CoC team.
For convenence of review and in line with other
Signed-off-by: Lars Kurth
---
Cc: minios-de...@lists.xenproject.org
Cc: xen-...@lists.xenproject.org
Cc: win-pv-de...@lists.xenproject.org
Cc: mirageos-de...@lists.xenproject.org
Cc: committ...@xenproject.org
---
code-of-conduct.md | 76 ++
1 fi
AMD Pre-Fam17h CPUs "optimise" {F,}X{SAVE,RSTOR} by not saving/restoring
FOP/FIP/FDP if an x87 exception isn't pending. This causes an information
leak, CVE-2006-1056, and worked around by several OSes, including Xen. AMD
Fam17h CPUs no longer have this leak, and advertise so in a CPUID bit.
Int
flight 140989 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140989/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-credit1 7 xen-boot fail REGR. vs. 140282
test-amd64-amd64-
On Wed, Sep 4, 2019 at 12:12 PM Juergen Gross wrote:
>
> The stubdom gets an event channel to use for dom0 xenbstore connection
> via commandline parameter ("--event "). This needs to be used
> in the stubdom for setting up the communication path.
>
>
> Juergen
Hi Juergen,
Thanks for the quick r
On 9/4/19 5:52 PM, George Dunlap wrote:
> On 9/4/19 1:36 AM, Nicholas Rosbrook wrote:
>> George,
>>
>>> Are you up for taking a stab at something like `gengotypes.py`?
>>
>> I have was able to make a bit of progress on this over the weekend. I've
>> started
>> `gengotypes.py` in my branch[1]; the
On 9/4/19 1:36 AM, Nicholas Rosbrook wrote:
> George,
>
>> Are you up for taking a stab at something like `gengotypes.py`?
>
> I have was able to make a bit of progress on this over the weekend. I've
> started
> `gengotypes.py` in my branch[1]; the portion which generates
> `xenlight_types.go`
flight 140985 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140985/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 18 guest-localmigrate/x10 fail in 140960 REGR. vs.
139876
build-amd64
On 04.09.19 17:45, Daniel Smith wrote:
Greetings,
I am attempting to see if I can get xenstored to run within a Linux
stubdom for a variety of reasons. The way I have it constructed at
this point is that embedded within the initramfs of dom0 is the linux
stubdom image along with the init-xenstor
On 04.09.2019 17:45, Andrew Cooper wrote:
> On 04/09/2019 14:27, Jan Beulich wrote:
>> --- a/xen/drivers/passthrough/vtd/iommu.h
>> +++ b/xen/drivers/passthrough/vtd/iommu.h
>> @@ -530,6 +530,7 @@ struct intel_iommu {
>> struct ir_ctrl ir_ctrl;
>> struct iommu_flush flush;
>> struct
On 04/09/2019 14:27, Jan Beulich wrote:
> --- a/xen/drivers/passthrough/vtd/iommu.h
> +++ b/xen/drivers/passthrough/vtd/iommu.h
> @@ -530,6 +530,7 @@ struct intel_iommu {
> struct ir_ctrl ir_ctrl;
> struct iommu_flush flush;
> struct acpi_drhd_unit *drhd;
> +nodeid_t node;
> };
Greetings,
I am attempting to see if I can get xenstored to run within a Linux
stubdom for a variety of reasons. The way I have it constructed at
this point is that embedded within the initramfs of dom0 is the linux
stubdom image along with the init-xenstore-domain helper. The init
script within t
On 6/7/19 11:55 AM, Alexandru Stefan ISAILA wrote:
> The patch adds a new lib xc function (xc_altp2m_get_vcpu_p2m_idx) that
> uses a new hvmop (HVMOP_altp2m_get_p2m_idx) to get the active altp2m
> index from a given vcpu.
>
> Signed-off-by: Alexandru Isaila
This looks good to me. Sorry it took
Am Wed, 4 Sep 2019 16:22:37 +0200
schrieb Jan Beulich :
> First of all - does "the code" here mean master/staging, or any
> release branch? And then, yes, on release branches there will be
> EINVAL, but as said before kexec_crash_area.size will get/remain
> set nevertheless (as the error path does
On 09.08.2019 16:57, Juergen Gross wrote:
> --- a/xen/common/schedule.c
> +++ b/xen/common/schedule.c
> @@ -407,6 +407,8 @@ int sched_init_vcpu(struct vcpu *v, unsigned int
> processor)
> {
> get_sched_res(v->processor)->curr = unit;
> v->is_running = 1;
> +unit->is_
On 04.09.19 16:54, Jan Beulich wrote:
On 04.09.2019 16:41, Juergen Gross wrote:
On 04.09.19 16:02, Jan Beulich wrote:
On 09.08.2019 16:57, Juergen Gross wrote:
--- a/xen/common/schedule.c
+++ b/xen/common/schedule.c
@@ -250,7 +250,8 @@ static inline void vcpu_runstate_change(
void vcpu_
On 04.09.2019 16:41, Juergen Gross wrote:
> On 04.09.19 16:02, Jan Beulich wrote:
>> On 09.08.2019 16:57, Juergen Gross wrote:
>>> --- a/xen/common/schedule.c
>>> +++ b/xen/common/schedule.c
>>> @@ -250,7 +250,8 @@ static inline void vcpu_runstate_change(
>>>
>>> void vcpu_runstate_get(struct
On 09.08.2019 16:57, Juergen Gross wrote:
> Add the following helpers using a sched_unit as input instead of a
> vcpu:
>
> - is_idle_unit() similar to is_idle_vcpu()
> - is_unit_online() similar to is_vcpu_online()
> - unit_runnable() like vcpu_runnable()
Since for vCPU-s within a unit the return
On 04.09.19 16:02, Jan Beulich wrote:
On 09.08.2019 16:57, Juergen Gross wrote:
--- a/xen/common/schedule.c
+++ b/xen/common/schedule.c
@@ -250,7 +250,8 @@ static inline void vcpu_runstate_change(
void vcpu_runstate_get(struct vcpu *v, struct vcpu_runstate_info *runstate)
{
-spinlock
On 04.09.2019 16:14, Alexandru Stefan ISAILA wrote:
>
>
> On 04.09.2019 16:17, Jan Beulich wrote:
>> On 04.09.2019 15:04, Alexandru Stefan ISAILA wrote:
>>>
>>>
>>> On 04.09.2019 15:14, Jan Beulich wrote:
On 04.09.2019 13:51, Alexandru Stefan ISAILA wrote:
>
>
> On 03.09.2019 18:
On 04.09.19 15:53, Jan Beulich wrote:
On 04.09.2019 15:46, Juergen Gross wrote:
@@ -1281,14 +1280,14 @@ void debugtrace_printk(const char *fmt, ...)
{
if ( strcmp(buf, last_buf) )
{
-last_prd = debugtrace_prd;
+debugtrace_prd_last = debugtrace_pr
Hi all,
we started planning next year’s Developer Summit, which is due to be in Europe.
We have a venue in Bucharest, Romania secured but are still working through the
details. As we are early, we do have several date options: so I wanted to give
you a choice to vote, such that we end up with a
On 04.09.2019 16:13, Olaf Hering wrote:
> Am Wed, 4 Sep 2019 14:19:23 +0200
> schrieb Jan Beulich :
>
>> On 04.09.2019 11:37, Olaf Hering wrote:
>>> Maybe just the lack of b49225dc9df336405292dc08862b4c7c9d887bd6 in vendor
>>> binaries...
>> But this change was only to deal with the bogus log m
So that the name implies the function is used to walk the page table
pointer passed as parameter. Drop the parent_ prefix from the level
parameter, since the level passed is the one matching the EPT entry
passed in the mfn parameter.
While there also change bool_t to bool and add an assert to make
On 09.08.2019 16:57, Juergen Gross wrote:
> V2:
> - move affinity_broken back to struct vcpu (Jan Beulich)
But this alone won't work: Now a 2nd vCPU in a unit will clobber
what a 1st one may have set as an affinity override. I don't
think you can get away without a per-vCPU CPU mask, or a
combinat
On Wed, Sep 04, 2019 at 06:50:25AM +, Tian, Kevin wrote:
> > From: Roger Pau Monné [mailto:roger@citrix.com]
> > Sent: Thursday, August 29, 2019 6:26 PM
> >
> > On Tue, Aug 27, 2019 at 05:23:33PM +0200, Jan Beulich wrote:
> > > On 23.08.2019 07:58, Tian, Kevin wrote:
> > > > > From: Roge
On 04.09.2019 16:17, Jan Beulich wrote:
> On 04.09.2019 15:04, Alexandru Stefan ISAILA wrote:
>>
>>
>> On 04.09.2019 15:14, Jan Beulich wrote:
>>> On 04.09.2019 13:51, Alexandru Stefan ISAILA wrote:
On 03.09.2019 18:52, Jan Beulich wrote:
> On 02.09.2019 10:11, Alexandru Stefan
Am Wed, 4 Sep 2019 14:19:23 +0200
schrieb Jan Beulich :
> On 04.09.2019 11:37, Olaf Hering wrote:
> > Maybe just the lack of b49225dc9df336405292dc08862b4c7c9d887bd6 in vendor
> > binaries...
> But this change was only to deal with the bogus log message.
> The handling was still correct (and th
Hi all,
the proposed agenda is in
https://cryptpad.fr/pad/#/2/pad/edit/xwUTm6b5f5ijPTQcF9IFgkBg/ and you can edit
to add items
Alternatively, you can reply to this mail directly
Agenda items appreciated ASAP: please put your name besides items if you edit
the document
Apologies for dropping th
On 09.08.2019 16:57, Juergen Gross wrote:
> --- a/xen/common/schedule.c
> +++ b/xen/common/schedule.c
> @@ -250,7 +250,8 @@ static inline void vcpu_runstate_change(
>
> void vcpu_runstate_get(struct vcpu *v, struct vcpu_runstate_info *runstate)
> {
> -spinlock_t *lock = likely(v == current)
> -Original Message-
> From: Roger Pau Monne
> Sent: 04 September 2019 14:40
> To: Paul Durrant
> Cc: Andrew Cooper ;
> xen-devel@lists.xenproject.org; Jan Beulich
> ; Wei Liu
> Subject: Re: [PATCH v2 02/11] ioreq: terminate cf8 handling at hypervisor
> level
>
> On Wed, Sep 04, 2019
On 04.09.2019 15:46, Juergen Gross wrote:
> @@ -1281,14 +1280,14 @@ void debugtrace_printk(const char *fmt, ...)
> {
> if ( strcmp(buf, last_buf) )
> {
> -last_prd = debugtrace_prd;
> +debugtrace_prd_last = debugtrace_prd;
> last_count = +
On 09.08.2019 16:57, Juergen Gross wrote:
> This prepares support of larger scheduling granularities, e.g. core
> scheduling.
>
> While at it move sched_has_urgent_vcpu() from include/asm-x86/cpuidle.h
> into schedule.c removing the need for including sched-if.h in
> cpuidle.h and multiple other C
Instead of living in drivers/char/console.c move the debugtrace
related coding to a new file common/debugtrace.c
No functional change, code movement only.
Signed-off-by: Juergen Gross
Acked-by: Jan Beulich
---
xen/common/Makefile| 1 +
xen/common/debugtrace.c| 180 +++
As a preparation for per-cpu buffers do a little refactoring of the
debugtrace data: put the needed buffer admin data into the buffer as
it will be needed for each buffer.
While at it switch debugtrace_send_to_console and debugtrace_used to
bool and delete an empty line.
Signed-off-by: Juergen Gr
After dumping the debugtrace buffer it is cleared. This results in some
entries not being printed in case the buffer is dumped again before
having wrapped.
While at it remove the trailing zero byte in the buffer as it is no
longer needed. Commit b5e6e1ee8da59f introduced passing the number of
char
Another debugtrace enhancement I needed for core scheduling debugging,
plus some cleanup.
Changes in V4:
- replaced patch 1 (original one was committed, new one requested by
Jan Beulich)
- several comments by Jan addressed
Changes in V3:
- rebase to current staging
Changes in V2:
- added new p
debugtrace is normally writing trace entries into a single trace
buffer. There are cases where this is not optimal, e.g. when hunting
a bug which requires writing lots of trace entries and one cpu is
stuck. This will result in other cpus filling the trace buffer and
finally overwriting the interest
On Wed, Sep 04, 2019 at 11:46:24AM +0200, Paul Durrant wrote:
> > -Original Message-
> > From: Roger Pau Monne
> > Sent: 04 September 2019 08:49
> > To: Andrew Cooper
> > Cc: xen-devel@lists.xenproject.org; Paul Durrant ;
> > Jan Beulich
> > ; Wei Liu
> > Subject: Re: [PATCH v2 02/11] i
On 09.08.2019 16:57, Juergen Gross wrote:
> --- a/xen/include/xen/sched-if.h
> +++ b/xen/include/xen/sched-if.h
> @@ -36,7 +36,7 @@ extern int sched_ratelimit_us;
> struct schedule_data {
> spinlock_t *schedule_lock,
> _lock;
> -struct vcpu*curr;
On 09.08.2019 16:57, Juergen Gross wrote:
> --- a/xen/include/xen/sched-if.h
> +++ b/xen/include/xen/sched-if.h
> @@ -189,8 +189,8 @@ struct scheduler {
> struct task_slice (*do_schedule) (const struct scheduler *, s_time_t,
>bool_t tasklet_work_schedule
Use appropriate types. Drop unnecessary casts. Check for failures which
can (at least in theory because of non-obvious breakage elsewhere)
occur, instead of ones which really can't (map_domain_page() won't
return NULL).
Signed-off-by: Jan Beulich
--- a/xen/drivers/passthrough/vtd/x86/ats.c
+++ b
The two uses of pci_get_pdev_by_domain() lack proper locking, but are
also only used to get hold of a NUMA node ID. Calculate and store the
node ID earlier on and remove the lookups (in lieu of fixing the
locking).
While doing this it became apparent that iommu_alloc()'s use of
alloc_pgtable_maddr
Drop iommu_to_drhd() altogether - there's no need for a loop here, the
corresponding DRHD is a field in struct intel_iommu.
Constify drhd_to_rhsa()'s parameter and adjust style.
Signed-off-by: Jan Beulich
--- a/xen/drivers/passthrough/vtd/dmar.c
+++ b/xen/drivers/passthrough/vtd/dmar.c
@@ -128,
1: tidy _to_() functions
2: avoid PCI device lookup
3: ATS: tidy device_in_domain()
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 04.09.2019 15:04, Alexandru Stefan ISAILA wrote:
>
>
> On 04.09.2019 15:14, Jan Beulich wrote:
>> On 04.09.2019 13:51, Alexandru Stefan ISAILA wrote:
>>>
>>>
>>> On 03.09.2019 18:52, Jan Beulich wrote:
On 02.09.2019 10:11, Alexandru Stefan ISAILA wrote:
> @@ -1355,6 +1355,23 @@ void p
On 09.08.2019 16:57, Juergen Gross wrote:
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -273,11 +273,14 @@ struct vcpu
> struct arch_vcpu arch;
> };
>
> +struct sched_resource;
As mentioned elsewhere, I don't think you need this when the first
reference is ...
> st
On 04.09.2019 15:14, Jan Beulich wrote:
> On 04.09.2019 13:51, Alexandru Stefan ISAILA wrote:
>>
>>
>> On 03.09.2019 18:52, Jan Beulich wrote:
>>> On 02.09.2019 10:11, Alexandru Stefan ISAILA wrote:
@@ -1355,6 +1355,23 @@ void p2m_init_altp2m_ept(struct domain *d, unsigned
int i)
On 04/09/2019, 13:35, "Jan Beulich" wrote:
On 03.09.2019 20:37, Lars Kurth wrote:
> I have not gotten around to draft an agenda yet. Please reply to
> this thread with possible agenda items. I will reply to this
> thread with meeting invite and details as usual
Well, o
On 03.09.2019 20:37, Lars Kurth wrote:
> I have not gotten around to draft an agenda yet. Please reply to
> this thread with possible agenda items. I will reply to this
> thread with meeting invite and details as usual
Well, on one hand I would have two topics:
- the pending AMD maintainership ch
On 04.09.2019 11:37, Olaf Hering wrote:
> Am Wed, 4 Sep 2019 10:18:41 +0100
> schrieb Andrew Cooper :
>
>> That sounds like an accidental regression in parsing of crashkernel=,
>> rather than a deliberate action.
>
> Maybe just the lack of b49225dc9df336405292dc08862b4c7c9d887bd6 in vendor
> bin
On 04.09.2019 13:51, Alexandru Stefan ISAILA wrote:
>
>
> On 03.09.2019 18:52, Jan Beulich wrote:
>> On 02.09.2019 10:11, Alexandru Stefan ISAILA wrote:
>>> @@ -1355,6 +1355,23 @@ void p2m_init_altp2m_ept(struct domain *d, unsigned
>>> int i)
>>> ept = &p2m->ept;
>>> ept->mfn = paget
flight 140979 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140979/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 20 guest-start/debian.repeat fail REGR. vs. 139910
build-amd64-xsm
On 04.09.2019 13:36, Igor Druzhinin wrote:
> On 04/09/2019 10:08, Jan Beulich wrote:
>> On 04.09.2019 02:20, Igor Druzhinin wrote:
>>> If MCFG area is not reserved in E820, Xen by default will defer its usage
>>> until Dom0 registers it explicitly after ACPI parser recognizes it as
>>> a reserved r
On Wed, Sep 04, 2019 at 08:45:47PM +0900, Masami Hiramatsu wrote:
> Hi,
>
> These patches allow x86 instruction decoder to decode
> xen-cpuid which has XEN_EMULATE_PREFIX, and prohibit
> kprobes to probe on it.
>
> Josh reported that the objtool can not decode such special
> prefixed instructions
On 04.09.2019 13:28, Andrew Cooper wrote:
> On 04/09/2019 08:55, Jan Beulich wrote:
>> Commit 2634b997af ("x86/shadow: don't enable shadow mode with too small
>> a shadow allocation") was incomplete: The adjustment done there to
>> shadow_enable() is also needed in shadow_one_bit_enable(). The (new
On 04/09/2019 12:45, Masami Hiramatsu wrote:
> Hi,
>
> These patches allow x86 instruction decoder to decode
> xen-cpuid which has XEN_EMULATE_PREFIX, and prohibit
> kprobes to probe on it.
>
> Josh reported that the objtool can not decode such special
> prefixed instructions, and I found that we a
On 04.09.2019 12:19, Andrew Cooper wrote:
> On 03/09/2019 13:25, Jan Beulich wrote:
>> On 03.09.2019 12:28, Andrew Cooper wrote:
>>> On 03/09/2019 10:39, Jan Beulich wrote:
Note that SDM revision 070 doesn't specify exception behavior for
ModRM.mod != 0b11; assuming #UD here.
Si
On 03.09.2019 18:52, Jan Beulich wrote:
> On 02.09.2019 10:11, Alexandru Stefan ISAILA wrote:
>> @@ -1355,6 +1355,23 @@ void p2m_init_altp2m_ept(struct domain *d, unsigned
>> int i)
>> ept = &p2m->ept;
>> ept->mfn = pagetable_get_pfn(p2m_get_pagetable(p2m));
>> d->arch.altp2m_e
Hi,
These patches allow x86 instruction decoder to decode
xen-cpuid which has XEN_EMULATE_PREFIX, and prohibit
kprobes to probe on it.
Josh reported that the objtool can not decode such special
prefixed instructions, and I found that we also have to
prohibit kprobes to probe on such instruction.
Decode XEN_EMULATE_PREFIX prefix by x86 insn decoder.
This treats a special sequence of instructions of XEN_EMULATE_PREFIX
as a prefix bytes in x86 insn decoder. User can test whether the
instruction has the XEN_EMULATE_PREFIX or not by insn_is_xen_prefixed().
Note that this prefix is treated as ju
Prohibit probing on instruction which has XEN_EMULATE_PREFIX
(it must be cpuid.) Since that prefix is a marker for Xen,
if we modify the marker by kprobe's int3, that doesn't work
as expected.
Signed-off-by: Masami Hiramatsu
---
arch/x86/kernel/kprobes/core.c |4
1 file changed, 4 inser
On 04/09/2019 10:08, Jan Beulich wrote:
> On 04.09.2019 02:20, Igor Druzhinin wrote:
>> If MCFG area is not reserved in E820, Xen by default will defer its usage
>> until Dom0 registers it explicitly after ACPI parser recognizes it as
>> a reserved resource in DSDT. Having it reserved in E820 is no
Instead of using a hardcoded location, inherit the
location from $0
Signed-off-by: Lars Kurth
---
scripts/add_maintainers.pl | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/scripts/add_maintainers.pl b/scripts/add_maintainers.pl
index 09e9f66..5a6d0f6 100755
--- a/scripts
This change provides sufficient information to allow get_maintainer.pl /
add_maintainers.pl scripts to be run on xen sister repositories such as
mini-os.git, osstest.git, etc
A suggested template for sister repositories of Xen is
This file
Use-case: Allow using both scripts on xen repositories such as
mini-os.git, osstest.git,
Assumptions: the repository contains a MAINTAINERS file that
follows the same conventions as the file in xen.git
A suggested template for sister repositories of Xen
==
On 04/09/2019 08:55, Jan Beulich wrote:
> Commit 2634b997af ("x86/shadow: don't enable shadow mode with too small
> a shadow allocation") was incomplete: The adjustment done there to
> shadow_enable() is also needed in shadow_one_bit_enable(). The (new)
> problem report was (apparently) a failed PV
Specifically:
* Move check until after the MAINTAINERS file has been read
* Add get_xen_maintainers_file_version() for check
* Remove top_of_tree as not needed any more
* Fail with extended error message when used out of tree
Signed-off-by: Lars Kurth
---
scripts/get_maintainer.pl | 57 +
On 04.09.19 10:51, Jan Beulich wrote:
On 04.09.2019 10:47, Juergen Gross wrote:
On 04.09.19 10:40, Jan Beulich wrote:
On 04.09.2019 10:25, Juergen Gross wrote:
On 03.09.19 17:09, Jan Beulich wrote:
On 03.09.2019 17:03, Juergen Gross wrote:
On 03.09.19 16:53, Jan Beulich wrote:
On 29.08.2019
On 03/09/2019 13:25, Jan Beulich wrote:
> On 03.09.2019 12:28, Andrew Cooper wrote:
>> On 03/09/2019 10:39, Jan Beulich wrote:
>>> Note that SDM revision 070 doesn't specify exception behavior for
>>> ModRM.mod != 0b11; assuming #UD here.
>>>
>>> Signed-off-by: Jan Beulich
>> What are we going to
flight 141002 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141002/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen a342900d4835c127c1466c5abc1323a666e8cebd
baseline version:
xen b376
On 04.09.19 11:15, Andrew Cooper wrote:
On 04/09/2019 10:11, Juergen Gross wrote:
On 04.09.19 10:58, Andrew Cooper wrote:
On 04/09/2019 09:40, Jan Beulich wrote:
On 04.09.2019 10:25, Juergen Gross wrote:
On 03.09.19 17:09, Jan Beulich wrote:
On 03.09.2019 17:03, Juergen Gross wrote:
On 03.0
> -Original Message-
> From: Roger Pau Monne
> Sent: 04 September 2019 08:49
> To: Andrew Cooper
> Cc: xen-devel@lists.xenproject.org; Paul Durrant ;
> Jan Beulich
> ; Wei Liu
> Subject: Re: [PATCH v2 02/11] ioreq: terminate cf8 handling at hypervisor
> level
>
> On Tue, Sep 03, 2019
On 04/09/2019 10:26, Jan Beulich wrote:
> On 03.09.2019 14:34, Andrew Cooper wrote:
>>> --- a/xen/arch/x86/cpuid.c
>>> +++ b/xen/arch/x86/cpuid.c
>>> @@ -545,6 +545,11 @@ void recalculate_cpuid_policy(struct dom
>>>
>>> p->extd.maxlinaddr = p->extd.lm ? 48 : 32;
>>>
>>> +if ( p->extd.r
flight 140976 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140976/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 18 guest-localmigrate/x10 fail REGR. vs. 129313
build-armhf-pvops
Am Wed, 4 Sep 2019 10:18:41 +0100
schrieb Andrew Cooper :
> That sounds like an accidental regression in parsing of crashkernel=,
> rather than a deliberate action.
Maybe just the lack of b49225dc9df336405292dc08862b4c7c9d887bd6 in vendor
binaries...
It is likely broken since 4.10. I have not tr
On 03.09.2019 14:34, Andrew Cooper wrote:
>> --- a/xen/arch/x86/cpuid.c
>> +++ b/xen/arch/x86/cpuid.c
>> @@ -545,6 +545,11 @@ void recalculate_cpuid_policy(struct dom
>>
>> p->extd.maxlinaddr = p->extd.lm ? 48 : 32;
>>
>> +if ( p->extd.rdpru )
>> +p->extd.rdpru_max = min(p->ext
On 04/09/2019 10:14, Olaf Hering wrote:
> A plain crashkernel=size is apparently not supported by the code
> anymore. In case kdump ever worked like that, the code which removed
> support for this notation did not update the documentation.
>
> Signed-off-by: Olaf Hering
That sounds like an accide
A plain crashkernel=size is apparently not supported by the code
anymore. In case kdump ever worked like that, the code which removed
support for this notation did not update the documentation.
Signed-off-by: Olaf Hering
---
docs/misc/kexec_and_kdump.txt | 14 ++
1 file changed, 2 in
1 - 100 of 119 matches
Mail list logo
