>>> On 03.05.17 at 19:11, wrote:
>
> On 04/28/2017 02:52 AM, Tian, Kevin wrote:
>>> From: Tian, Kevin
>>> Sent: Friday, April 28, 2017 2:43 PM
>>>
From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com]
Sent: Thursday, April 27, 2017 11:18 PM
On 04/27/2017 11:05 AM, Jan Beu
>>> On 03.05.17 at 20:29, wrote:
> Irrespective of the history which lead to this point, the important
> question is whether we want to allow compiling x86 without CONFIG_COMPAT.
>
> If the eventual decision is yes, then new code should specifically be
> introduced as being CONFIG_COMPAT-clean, b
This run is configured for baseline tests only.
flight 71252 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71252/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 00324f3fce83b8d813ca3ec6b6eb663a88a8675e
baseline v
>>> On 03.05.17 at 20:58, wrote:
> On 03/05/17 16:42, Jan Beulich wrote:
> On 02.05.17 at 16:12, wrote:
>>> On 02/05/17 14:22, Jan Beulich wrote:
@@ -345,15 +344,20 @@ UNLIKELY_START(z, create_bounce_frame_ba
__UNLIKELY_END(create_bounce_frame_bad_bounce_ip)
movq %ra
flight 108183 xen-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/108183/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-xl-rtds 11 guest-start fail in 108141 pass in 108183
test-amd64-amd64-xl-qemuu-win
All,
it's been a (not very often, but anyway) recurring situation that in
order to get an ack on some patch I had to make adjustments which
I didn't agree with. Since all maintainers opinions are supposed to be
equal, it is not really clear to me whether in such cases it should
really be the revie
>>> On 03.05.17 at 19:51, wrote:
> In the presence of bugs such as XSA-214 where a 32bit PV guest can get its
> hands on a long mode segment, this change prevents register content leaking
> between domains.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
__
Hi All,
Here is configuration proposal with connector (surface) id:
1. Configuration file:
vdispl = [ 'backend=0, devId=0, beAlloc=1,
connectors=id0:800x600;id1:1024x768' ]
* backend - backend domain id or name (if different from dom 0);
* devId - device id (if different from 0);
* b
Hi,
On 02/05/17 14:23, Jan Beulich wrote:
The primary purpose is correcting a latent bug in __get_user_check()
(the macro has no active user at present): The access_ok() check should
be before the actual access, or else any PV guest could initiate MMIO
reads with side effects.
Clean up all four
The introspection agent can reply to a vm_event faster than
vmx_vmexit_handler() can complete in some cases, where it is then
not safe for vm_event_set_registers() to modify v->arch.user_regs.
In the test scenario, we were stepping over an INT3 breakpoint by
setting RIP += 1. The quick reply tended
Created arch/x86/hvm/vm_event.c and include/asm-x86/hvm/vm_event.h,
where HVM-specific vm_event-related code will live. This cleans up
hvm_do_resume() and ensures that the vm_event maintainers are
responsible for changes to that code.
Signed-off-by: Razvan Cojocaru
Acked-by: Tamas K Lengyel
---
This small series first creates hvm/vm_event.{h,c}, in order to bring
under vm_event maintainership the code that has previously lived in
hvm_do_resume(), and then fixes a __context_switch()-related race
condition when attempting to set registers via vm_event reply.
[PATCH V3 1/2] x86/vm_event: ad
See the code comment.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -480,6 +480,22 @@ struct page_info *get_page_from_gfn_p2m(
p2m_access_t _a;
p2m_type_t _t;
mfn_t mfn;
+#ifndef NDEBUG
+/*
+ * Temporary debugging code, added in the
>>> On 04.05.17 at 11:00, wrote:
> Created arch/x86/hvm/vm_event.c and include/asm-x86/hvm/vm_event.h,
> where HVM-specific vm_event-related code will live. This cleans up
> hvm_do_resume() and ensures that the vm_event maintainers are
> responsible for changes to that code.
>
> Signed-off-by: Ra
On 05/04/17 12:11, Jan Beulich wrote:
On 04.05.17 at 11:00, wrote:
>> Created arch/x86/hvm/vm_event.c and include/asm-x86/hvm/vm_event.h,
>> where HVM-specific vm_event-related code will live. This cleans up
>> hvm_do_resume() and ensures that the vm_event maintainers are
>> responsible for c
flight 108182 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/108182/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-winxpsp3 6 xen-boot fail REGR. vs. 108124
test-amd64-i386-xl-q
Jan Beulich writes ("differing opinions between maintainers vs patch acks"):
> When there's an odd number of maintainers for a given piece of
> code, it may be acceptable to pull in a 3rd maintainer to break ties,
> but pulling in a non-maintainer (e.g. some [other] committer) to
> help out seems n
>>> On 04.05.17 at 11:14, wrote:
> On 05/04/17 12:11, Jan Beulich wrote:
> On 04.05.17 at 11:00, wrote:
>>> Created arch/x86/hvm/vm_event.c and include/asm-x86/hvm/vm_event.h,
>>> where HVM-specific vm_event-related code will live. This cleans up
>>> hvm_do_resume() and ensures that the vm_ev
On 03.05.2017 20:02, Wei Liu wrote:
Can you give the following patch a try? This applies to 4.8.
Not sure if there is a better way to fix it though. Ian and Roger?
---8<---
From 8542a1d4f537cb5719ebd245872d0256df816670 Mon Sep 17 00:00:00 2001
From: Wei Liu
Date: Wed, 3 May 2017 17:55:42 +01
On 04/05/17 08:27, Jan Beulich wrote:
On 03.05.17 at 20:29, wrote:
>> Irrespective of the history which lead to this point, the important
>> question is whether we want to allow compiling x86 without CONFIG_COMPAT.
>>
>> If the eventual decision is yes, then new code should specifically be
>>
>>> On 04.05.17 at 11:21, wrote:
> Jan Beulich writes ("differing opinions between maintainers vs patch acks"):
>> When there's an odd number of maintainers for a given piece of
>> code, it may be acceptable to pull in a 3rd maintainer to break ties,
>> but pulling in a non-maintainer (e.g. some [
From: Andrii Anisov
Description of SCF specific device tree properties and SCF configuration
using device tree.
Signed-off-by: Andrii Anisov
---
Dear All,
I would like to present a concept of SCF [1] configuration using device tree.
The idea is that the framework configuration is too complex
>>> On 04.05.17 at 11:27, wrote:
> On 04/05/17 08:27, Jan Beulich wrote:
>> As said before, I don't view it as a reasonable setup to allow only
>> 64-bit HVM guests, so unless there is an intention to have a
>> configuration where only PVH guests are supported (i.e. neither
>> PV nor traditional H
On 04/05/17 10:09, Jan Beulich wrote:
> See the code comment.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
>
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -480,6 +480,22 @@ struct page_info *get_page_from_gfn_p2m(
> p2m_access_t _a;
> p2m_type_t _t;
>
Hi,
On 04/05/17 10:39, Andrew Cooper wrote:
On 04/05/17 10:09, Jan Beulich wrote:
See the code comment.
Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
Release-acked-by: Julien Grall
Cheers,
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -480,6 +480,22 @@ struct pag
>>> On 14.04.17 at 17:37, wrote:
> --- a/xen/common/page_alloc.c
> +++ b/xen/common/page_alloc.c
> @@ -919,11 +919,50 @@ static int reserve_offlined_page(struct page_info *head)
> return count;
> }
>
> +/* Returns new buddy head. */
> +static struct page_info *
> +merge_and_free_buddy(stru
Hi,
On 14/02/17 10:51, Jan Beulich wrote:
On 07.02.17 at 00:32, wrote:
Commit c7bdecae42 ("x86/apicv: fix RTC periodic timer and apicv issue") has
added a assertion that intack.vector is the highest priority vector. But
according to the osstest, the assertion failed sometimes. More discussion
Wei Liu writes ("Re: [Xen-devel] [BUG] xl devd segmentation fault on xl
block-detach"):
> Can you give the following patch a try? This applies to 4.8.
>
> Not sure if there is a better way to fix it though. Ian and Roger?
I find the logic here rather awkward. I do remember reviewing it and
beco
Jan Beulich writes ("Re: differing opinions between maintainers vs patch acks"):
> On 04.05.17 at 11:21, wrote:
> > I'm afraid I disagree. Someone with a fresh perspective is often
> > helpful, even if it involves a bit more explanation.
> >
> > And, the use of committers as referees in inter-ma
On 04/05/17 10:36, Jan Beulich wrote:
On 04.05.17 at 11:27, wrote:
>> On 04/05/17 08:27, Jan Beulich wrote:
>>> As said before, I don't view it as a reasonable setup to allow only
>>> 64-bit HVM guests, so unless there is an intention to have a
>>> configuration where only PVH guests are supp
This is more readable, maintainable, and livepatchable.
This involves declaring check_for_unexpected_msi(), untrusted_msi and
pv_hypercall() suitably for use by C. While making these changes,
untrusted_msi is switched over to being a C99 bool.
No behavioural change.
Signed-off-by: Andrew Cooper
Dear All,
During the topic implementation I faced a nasty issue with a DomU vgic
configuration.
Originally I planned that the partial device tree for DomU is being
passed to the
hypervisor from libxl__arch_domain_create, but it is too late to set
vgic configuration
at this time. The DomU’s vgi
On 04/05/17 11:01, Andrew Cooper wrote:
> This is more readable, maintainable, and livepatchable.
>
> This involves declaring check_for_unexpected_msi(), untrusted_msi and
> pv_hypercall() suitably for use by C. While making these changes,
> untrusted_msi is switched over to being a C99 bool.
>
>
>>> On 14.04.17 at 17:37, wrote:
> @@ -678,6 +680,20 @@ static void check_low_mem_virq(void)
> }
> }
>
> +/* Pages that need scrub are added to tail, otherwise to head. */
> +static void page_list_add_scrub(struct page_info *pg, unsigned int node,
> +unsigne
>>> On 04.05.17 at 11:47, wrote:
> On 14/02/17 10:51, Jan Beulich wrote:
> On 07.02.17 at 00:32, wrote:
>>> Commit c7bdecae42 ("x86/apicv: fix RTC periodic timer and apicv issue") has
>>> added a assertion that intack.vector is the highest priority vector. But
>>> according to the osstest, th
>>> On 04.05.17 at 12:01, wrote:
> This is more readable, maintainable, and livepatchable.
>
> This involves declaring check_for_unexpected_msi(), untrusted_msi and
> pv_hypercall() suitably for use by C. While making these changes,
> untrusted_msi is switched over to being a C99 bool.
>
> No b
On 04/05/2017 10:55, "Ian Jackson" wrote:
>Jan Beulich writes ("Re: differing opinions between maintainers vs patch
>acks"):
>> On 04.05.17 at 11:21, wrote:
>> > I'm afraid I disagree. Someone with a fresh perspective is often
>> > helpful, even if it involves a bit more explanation.
>> >
>>
>>> On 04.05.17 at 12:16, wrote:
> On 04/05/17 11:01, Andrew Cooper wrote:
> --- a/xen/arch/x86/x86_64/compat/entry.S
> +++ b/xen/arch/x86/x86_64/compat/entry.S
> @@ -21,6 +21,7 @@ ENTRY(entry_int82)
>
> mov %rsp, %rdi
> call do_entry_int82
> +jmp compat_test_all_e
On 04/05/17 11:03, Andrii Anisov wrote:
Dear All,
Hi Andrii,
During the topic implementation I faced a nasty issue with a DomU vgic
configuration.
Originally I planned that the partial device tree for DomU is being
passed to the
hypervisor from libxl__arch_domain_create, but it is too late
libxendevicemodel.so do depends on libxencall.so but the dependency was
missing at link time.
Signed-off-by: Anthony PERARD
---
tools/libs/devicemodel/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/libs/devicemodel/Makefile b/tools/libs/devicemodel/Makefile
in
Anthony PERARD writes ("[PATCH for-4.9] libs/devicemodel: Fix dependency with
libxencall"):
> libxendevicemodel.so do depends on libxencall.so but the dependency was
> missing at link time.
Acked-by: Ian Jackson
IMO this should indeed go into 4.9.
Ian.
On Wed, May 03, 2017 at 05:55:36PM +0100, Anthony PERARD wrote:
> > > --- a/tools/libs/devicemodel/Makefile
> > > +++ b/tools/libs/devicemodel/Makefile
> > > @@ -63,7 +63,7 @@ libxendevicemodel.so.$(MAJOR):
> > > libxendevicemodel.so.$(MAJOR).$(MINOR)
> > > $(SYMLINK_SHLIB) $< $@
> > >
>
On 04/05/17 11:28, Jan Beulich wrote:
On 04.05.17 at 12:16, wrote:
>> On 04/05/17 11:01, Andrew Cooper wrote:
>> --- a/xen/arch/x86/x86_64/compat/entry.S
>> +++ b/xen/arch/x86/x86_64/compat/entry.S
>> @@ -21,6 +21,7 @@ ENTRY(entry_int82)
>>
>> mov %rsp, %rdi
>> call do_
On 02/05/17 19:05, Andrew Cooper wrote:
> Various improvements based on observations while investigating and fixing the
> aformentioned XSAs. All are candidate patches for 4.9 at this point, with
> patches 2, 3 and 7 being the important ones from an attack-surface-mitigation
> point of view.
>
> T
flight 108185 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/108185/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-winxpsp3 16 guest-stop fail REGR. vs. 107900
test-amd64-amd64-x
'commit 1679e0df3df6 ("x86/ioreq server: asynchronously reset
outstanding p2m_ioreq_server entries")' will call
p2m_change_entry_type_global() which set entry.recalc=1. Then
the following get_entry(p2m_ioreq_server) will return
p2m_ram_rw type.
But 'commit 6d774a951696 ("x86/ioreq server: synchrono
Signed-off-by: Marc-André Lureau
Reviewed-by: Eric Blake
Reviewed-by: Philippe Mathieu-Daudé
---
hw/xen/xen-common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/xen/xen-common.c b/hw/xen/xen-common.c
index ae76150e8a..a9055e9eba 100644
--- a/hw/xen/xen-common.c
+++ b/
This is because that code, added by commit 997382b771 ("y86/vmx: dump
PIR and vIRR before ASSERT()"), was meant to be removed by the time we
finalize 4.9, but the root cause of the ASSERT() wrongly(?) triggering
still wasn't found.
Take the opportunity and also correct the format specifiers, which
>>> On 04.05.17 at 11:42, wrote:
> On 04/05/17 10:39, Andrew Cooper wrote:
>> On 04/05/17 10:09, Jan Beulich wrote:
>>> See the code comment.
>>>
>>> Signed-off-by: Jan Beulich
>>
>> Acked-by: Andrew Cooper
>
> Release-acked-by: Julien Grall
Thanks, but what about the patch this one is the fo
XP is really quite obsolete now.
From diffing standalone-generate-dump-flight-runvars output,
the tests that are dropped are:
test-amd64-amd64-xl-qemut-winxpsp3
test-amd64-amd64-xl-qemuu-winxpsp3
test-amd64-i386-xl-qemut-winxpsp3
test-amd64-i386-xl-qemut-winxpsp3-vcpus1
test-amd64-i386-x
On 04/05/17 08:59, Jan Beulich wrote:
> All,
>
> it's been a (not very often, but anyway) recurring situation that in
> order to get an ack on some patch I had to make adjustments which
> I didn't agree with. Since all maintainers opinions are supposed to be
> equal, it is not really clear to me wh
We call this function `do_hvm_win_2017_tests' because 2017 is the year
in which we are adding these tests and there isn't otherwise a good
common name. This is in the expectation we might want to retire them
at a similar point.
Do these new tests for all branches. If they fail on some old
branch
No functional change. (Verified with
standalone-generate-dump-flight-runvars.)
Don't bother messing with do_hvm_winxp_tests as 1. that uses testids
without the guest arch, so isn't compatible with this unless we make
it more general 2. we intend to abolish that for most branches
shortly.
Signed-
Unavoidable crashes in netfront_resume() and netback_changed() after a
previous fail in talk_to_netback() (e.g. when we fail to read MAC from
xenstore) were discovered. The failure path in talk_to_netback() does
unregister/free for netdev but we don't reset drvdata and we try accessing
it again aft
Hello Julien,
Thank you for your comments.
As you may have seen in the description of the option "device_tree",
it is complex to verify the partial device tree because of the libfdt
design. So without fully auditing libfdt and fixing the holes, this
suggestion would be a vector attack to the
Andrew Cooper writes ("Re: differing opinions between maintainers vs patch
acks"):
> Taking this example, as you have called it out, but without going into
> the details.
>
> I accept that the issues under debate do not have any impact on the
> technical correctness of the fix. Once compiled/ass
On 04/05/17 13:35, Andrii Anisov wrote:
Hello Julien,
Hi Andrii,
Thank you for your comments.
As you may have seen in the description of the option "device_tree",
it is complex to verify the partial device tree because of the libfdt
design. So without fully auditing libfdt and fixing the
On 04/05/2017 13:44, "Ian Jackson" wrote:
>Andrew Cooper writes ("Re: differing opinions between maintainers vs
>patch acks"):
>> Taking this example, as you have called it out, but without going into
>> the details.
>>
>> I accept that the issues under debate do not have any impact on the
>>
Hi Jan,
On 04/05/17 13:07, Jan Beulich wrote:
On 04.05.17 at 11:42, wrote:
On 04/05/17 10:39, Andrew Cooper wrote:
On 04/05/17 10:09, Jan Beulich wrote:
See the code comment.
Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
Release-acked-by: Julien Grall
Thanks, but what about th
Hi Andrew,
On 04/05/17 12:11, Andrew Cooper wrote:
On 02/05/17 19:05, Andrew Cooper wrote:
Various improvements based on observations while investigating and fixing the
aformentioned XSAs. All are candidate patches for 4.9 at this point, with
patches 2, 3 and 7 being the important ones from an
Hi Jan,
On 04/05/17 13:02, Jan Beulich wrote:
This is because that code, added by commit 997382b771 ("y86/vmx: dump
PIR and vIRR before ASSERT()"), was meant to be removed by the time we
finalize 4.9, but the root cause of the ASSERT() wrongly(?) triggering
still wasn't found.
Take the opportun
On 04/05/17 11:55, Ian Jackson wrote:
Anthony PERARD writes ("[PATCH for-4.9] libs/devicemodel: Fix dependency with
libxencall"):
libxendevicemodel.so do depends on libxencall.so but the dependency was
missing at link time.
Acked-by: Ian Jackson
IMO this should indeed go into 4.9.
Relea
To become a CNA (CVE Numbering Authority), which we would like to do,
we need to provide MITRE's CNA programme with a definition of the
scope of our CNA. That should be the scope of our general security
support, clearly.
At the moment we don't seem to have this written down in a single
clear docu
>>> On 04.05.17 at 14:44, wrote:
> Andrew Cooper writes ("Re: differing opinions between maintainers vs patch
> acks"):
>> Taking this example, as you have called it out, but without going into
>> the details.
>>
>> I accept that the issues under debate do not have any impact on the
>> technical
>>> On 04.05.17 at 14:53, wrote:
> To become a CNA (CVE Numbering Authority), which we would like to do,
> we need to provide MITRE's CNA programme with a definition of the
> scope of our CNA. That should be the scope of our general security
> support, clearly.
>
> At the moment we don't seem to
>>> On 04.05.17 at 14:20, wrote:
> XP is really quite obsolete now.
>
> From diffing standalone-generate-dump-flight-runvars output,
> the tests that are dropped are:
> test-amd64-amd64-xl-qemut-winxpsp3
> test-amd64-amd64-xl-qemuu-winxpsp3
> test-amd64-i386-xl-qemut-winxpsp3
> test-amd64
On 04/05/17 13:54, Jan Beulich wrote:
On 04.05.17 at 14:44, wrote:
>> Andrew Cooper writes ("Re: differing opinions between maintainers vs patch
>> acks"):
>>> Taking this example, as you have called it out, but without going into
>>> the details.
>>>
>>> I accept that the issues under debat
Commit d9b7ef209a7 ("x86: drop failsafe callback invocation from
assembly") didn't go quite far enough with the cleanup it did: The
changed maximum frame size should also have been reflected in the early
address range check (which has now been pointed out to have been wrong
anyway, using 60 instead
On 05/03/2017 05:35 PM, osstest service owner wrote:
> flight 108160 linux-linus real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/108160/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-amd64-xl-pvh-intel 6
Jan Beulich writes ("Re: differing opinions between maintainers vs patch acks"):
> On 04.05.17 at 14:44, wrote:
> > Well, at one level I agree with Andrew on at least the 1*1 and 0*8
> > question. These seem clearer to me as they state the programmer's
> > intent as well as merely the effect. I
>>> On 14.04.17 at 17:37, wrote:
> When allocating pages in alloc_heap_pages() first look for clean pages.
As expressed before, there are cases when we don't really need
scrubbed pages. Hence the local variable "use_unscrubbed" below
should really be some form of input to alloc_heap_pages().
> -
On 05/04/2017 06:17 AM, Jan Beulich wrote:
On 14.04.17 at 17:37, wrote:
>> @@ -678,6 +680,20 @@ static void check_low_mem_virq(void)
>> }
>> }
>>
>> +/* Pages that need scrub are added to tail, otherwise to head. */
>> +static void page_list_add_scrub(struct page_info *pg, unsigned in
On Thu, May 4, 2017 at 5:22 AM, Jan Beulich wrote:
On 04.05.17 at 11:14, wrote:
>> On 05/04/17 12:11, Jan Beulich wrote:
>> On 04.05.17 at 11:00, wrote:
Created arch/x86/hvm/vm_event.c and include/asm-x86/hvm/vm_event.h,
where HVM-specific vm_event-related code will live. This
flight 71255 distros-debian-wheezy real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71255/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
build-arm64 2 hosts-allocate broken never pass
build-arm64-pvops
>>> On 04.05.17 at 16:53, wrote:
> On 05/04/2017 06:17 AM, Jan Beulich wrote:
> On 14.04.17 at 17:37, wrote:
>>> @@ -678,6 +680,20 @@ static void check_low_mem_virq(void)
>>> }
>>> }
>>>
>>> +/* Pages that need scrub are added to tail, otherwise to head. */
>>> +static void page_list_
On Thu, May 04, 2017 at 01:53:00PM +0100, Julien Grall wrote:
>
>
> On 04/05/17 11:55, Ian Jackson wrote:
> > Anthony PERARD writes ("[PATCH for-4.9] libs/devicemodel: Fix dependency
> > with libxencall"):
> > > libxendevicemodel.so do depends on libxencall.so but the dependency was
> > > missin
On 05/04/2017 10:44 AM, Jan Beulich wrote:
On 14.04.17 at 17:37, wrote:
>> When allocating pages in alloc_heap_pages() first look for clean pages.
> As expressed before, there are cases when we don't really need
> scrubbed pages. Hence the local variable "use_unscrubbed" below
> should really
On 05/04/17 17:57, Tamas K Lengyel wrote:
> On Thu, May 4, 2017 at 5:22 AM, Jan Beulich wrote:
> On 04.05.17 at 11:14, wrote:
>>> On 05/04/17 12:11, Jan Beulich wrote:
>>> On 04.05.17 at 11:00, wrote:
> Created arch/x86/hvm/vm_event.c and include/asm-x86/hvm/vm_event.h,
> where H
From: Vitaly Kuznetsov
Date: Thu, 4 May 2017 14:23:04 +0200
> Unavoidable crashes in netfront_resume() and netback_changed() after a
> previous fail in talk_to_netback() (e.g. when we fail to read MAC from
> xenstore) were discovered. The failure path in talk_to_netback() does
> unregister/free
Introduce the proper locking sequence for the new pending_irq lock.
This takes the lock around multiple accesses to struct members,
also makes sure we observe the locking order (VGIC VCPU lock first,
then pending_irq lock).
Signed-off-by: Andre Przywara
---
xen/arch/arm/gic.c | 26 +
Currently we protect the pending_irq structure with the corresponding
VGIC VCPU lock. For future extensions this leads to problems (for
instance if an IRQ is migrating), so let's introduce a per-IRQ lock,
which protects the consistency of this structure independent from
any VCPU.
This patch just in
Currently we store the enable bit of an interrupt in the rank structure.
Remove it from there and let the MMIO emulation use the already existing
GIC_IRQ_GUEST_ENABLED in the status bits of struct pending_irq.
Signed-off-by: Andre Przywara
---
xen/arch/arm/vgic-v2.c | 38
Currently we store the interrupt type configuration (level or edge
triggered) in the rank structure. Move this value into struct pending_irq.
We just need one bit (edge or level), so use one of the status bits.
Signed-off-by: Andre Przywara
---
xen/arch/arm/vgic-v2.c | 29 ++-
So far there is always a statically allocated struct pending_irq for
each interrupt that we deal with.
To prepare for dynamically allocated LPIs, introduce a put/get wrapper
to get hold of a pending_irq pointer.
So far get() just returns the same pointer and put() is empty, but this
change allows t
Hi,
this is a sketch of the first step of some ARM VGIC rework.
While working more closely with the code during the ITS patch series, we
identified some shortcomings with the existing code which should be fixed.
This series addresses two, somewhat related, fields:
It introduces a per-IRQ lock to p
Currently gic_raise_inflight_irq() and gic_raise_guest_irq() are used
to queue interrupts to a VCPU, for which they are given a VCPU and an
interrupt number.
To allow proper locking and simplify further changes, change their prototypes
to take a struct pending_irq directly (since the callers have t
So far we kept the target VCPU for SPIs in the rank structure.
Move that information over into pending_irq.
This changes vgic_get_target_vcpu(), which now takes only a domain
and a struct pending_irq to get the target vCPU, in a way that does not
necessarily require the pending_irq lock to be held.
gic_route_irq_to_guest() and gic_remove_irq_from_guest() take the rank
lock, however never actually access the rank structure.
Avoid taking the lock in those two functions and remove some more
unneeded code on the way.
Signed-off-by: Andre Przywara
---
xen/arch/arm/gic.c | 28 ---
Currently we store the priority for newly triggered IRQs in the rank
structure. To get eventually rid of this structure, move this value
into the struct pending_irq. This one already contains a priority value,
but we have to keep the two apart, as the priority for guest visible
IRQs must not change
Now that every information formerly stored in the irq_rank has been
transferred over to struct pending_irq, we can get rid of all dead code
declaring and initializing the structure and all the support functions.
Signed-off-by: Andre Przywara
---
xen/arch/arm/vgic.c | 55
>>> On 14.04.17 at 17:37, wrote:
> --- a/xen/common/page_alloc.c
> +++ b/xen/common/page_alloc.c
> @@ -1035,16 +1035,82 @@ merge_and_free_buddy(struct page_info *pg, unsigned
> int node,
> return pg;
> }
>
> -static void scrub_free_pages(unsigned int node)
> +static nodemask_t node_scrubb
On Thu, May 4, 2017 at 11:17 AM, Razvan Cojocaru
wrote:
> On 05/04/17 17:57, Tamas K Lengyel wrote:
>> On Thu, May 4, 2017 at 5:22 AM, Jan Beulich wrote:
>> On 04.05.17 at 11:14, wrote:
On 05/04/17 12:11, Jan Beulich wrote:
On 04.05.17 at 11:00, wrote:
>> Created arch/x86/
>>> On 04.05.17 at 17:04, wrote:
> On 05/04/2017 10:44 AM, Jan Beulich wrote:
> On 14.04.17 at 17:37, wrote:
>>> When allocating pages in alloc_heap_pages() first look for clean pages.
>> As expressed before, there are cases when we don't really need
>> scrubbed pages. Hence the local variabl
>>> On 04.05.17 at 17:17, wrote:
> On 05/04/17 17:57, Tamas K Lengyel wrote:
>> On Thu, May 4, 2017 at 5:22 AM, Jan Beulich wrote:
>> On 04.05.17 at 11:14, wrote:
On 05/04/17 12:11, Jan Beulich wrote:
On 04.05.17 at 11:00, wrote:
>> Created arch/x86/hvm/vm_event.c and incl
>>> On 14.04.17 at 17:37, wrote:
> While scrubbing from idle loop, check for softirqs every 256 pages.
> If softirq is pending, don't scrub any further and merge the
> partially-scrubbed buddy back into heap by breaking the clean portion
> into smaller power-of-2 chunks. Then repeat the same proce
Julien,
What I would like to understand is what are the information that the
hypervisors as to know for sharing co-processor? So far I have:
- MMIOs
- Interrupts
Anything else?
IOMMU bindings.
This knowledge enough to get the physical coprocessor shared.
In order to spawn a virtual
flight 108232 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/108232/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
test-amd64-amd64-libvirt 12 mig
Hi Andre,
On 04/05/17 16:31, Andre Przywara wrote:
gic_route_irq_to_guest() and gic_remove_irq_from_guest() take the rank
lock, however never actually access the rank structure.
Avoid taking the lock in those two functions and remove some more
unneeded code on the way.
The rank is here to prot
Hey,
On Tue, May 02, 2017 at 03:06:24PM +0800, fu@linaro.org wrote:
> From: Fu Wei
>
> This patchset add xen_boot support into grup-mkconfig for
> generating xen boot entrances automatically
>
> Also update the docs/grub.texi for new xen_boot commands.
Slowly recovering after long weekend in
Recently, the tests of Windows XP SP3 that are run by osstest, as part
of the Xen Project's test suite, have started failing a lot more.
It is not clear what has caused this. The failures are causing
blockages: several of our `staging' branches are not gettting pushed
to the corresponding `stable
1 - 100 of 149 matches
Mail list logo
