This patch is needed in order to have a different return error for invalid vcpu
and offline vcpu on the per vcpu king.
Signed-off-by: Alexandru Isaila
---
Changes since V1:
- Add conditional statement in order to have a difference between
per_vcpu and per_dom return error.
---
x
On Fri, Sep 21, 2018 at 10:30:30AM +0300, Alexandru Isaila wrote:
> This patch is needed in order to have a different return error for invalid
> vcpu
> and offline vcpu on the per vcpu king.
Sorry, I can't parse this sentence. What is "per vcpu king"?
>
> Signed-off-by: Alexandru Isaila
>
> -
On Fri, Sep 21, 2018 at 09:43:22AM +0100, Wei Liu wrote:
> On Fri, Sep 21, 2018 at 10:30:30AM +0300, Alexandru Isaila wrote:
> > This patch is needed in order to have a different return error for invalid
> > vcpu
> > and offline vcpu on the per vcpu king.
>
> Sorry, I can't parse this sentence. W
On Fri, Sep 21, 2018 at 07:23:23AM +0200, Juergen Gross wrote:
> On 20/09/18 18:06, Wei Liu wrote:
> > On Wed, Sep 19, 2018 at 07:58:50PM +0200, Juergen Gross wrote:
> >>
> >> Did you look into the patches, especially patch 10? The parameters set
> >> are all stored in domain config via libxl__arch
On Fri, 2018-09-21 at 09:44 +0100, Wei Liu wrote:
> On Fri, Sep 21, 2018 at 09:43:22AM +0100, Wei Liu wrote:
> > On Fri, Sep 21, 2018 at 10:30:30AM +0300, Alexandru Isaila wrote:
> > > This patch is needed in order to have a different return error
> > > for invalid vcpu
> > > and offline vcpu on th
On Fri, Sep 21, 2018 at 08:51:51AM +0200, Takashi Iwai wrote:
> On Fri, 21 Sep 2018 07:47:38 +0200,
> Nick Simonov wrote:
> >
> > snd_pcm_ops are not supposed to change. So mark the
> > non-const structs as const. Also, refine indentation
> > to increase readability.
> >
> > Signed-off-by: Nick S
flight 127824 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127824/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-i386 broken
test-amd64-amd64-xl-qemut-stubdom-debianh
On Fri, 21 Sep 2018 11:21:35 +0200,
Nick Simonov wrote:
>
> On Fri, Sep 21, 2018 at 08:51:51AM +0200, Takashi Iwai wrote:
> > On Fri, 21 Sep 2018 07:47:38 +0200,
> > Nick Simonov wrote:
> > >
> > > snd_pcm_ops are not supposed to change. So mark the
> > > non-const structs as const. Also, refine
Hello,
While doing my best to make sure what I understand to be George's
proposed changes for the altp2m series I've tried to boot Xen staging on
an AMD host, but it crashes in an unrelated place (I've tested this by
stashing my changes and booting a "vanilla" staging):
(XEN) Dom0 has maximum 16
>>> On 20.09.18 at 20:19, wrote:
> I've just encountered this problem, building with the master branch of
> OpenEmbedded and Yocto's poky, with compiler flags that include
> _FORTIFY_SOURCE=2 -msse3
> with gcc 8.2.0.
>
> Xen's x86_emulator header file does:
> #pragma GCC target("no-sse")
On Fri, Sep 21, 2018 at 12:45:18PM +0300, Razvan Cojocaru wrote:
> Hello,
>
> While doing my best to make sure what I understand to be George's
> proposed changes for the altp2m series I've tried to boot Xen staging on
> an AMD host, but it crashes in an unrelated place (I've tested this by
> stas
>>> On 20.09.18 at 16:11, wrote:
> Commit 43d1622b "vtd: add lookup_page method to iommu_ops" added a
> lookup method in to the VT-d IOMMU implementation.
With this not having gone in yet, is there any reason not to make the
adjustment right there?
Jan
flight 75261 distros-debian-jessie real [real]
http://osstest.xensource.com/osstest/logs/75261/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvopsbroken
build-i386
flight 127802 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127802/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-win7-amd64 broken
test-amd64-i386-xl-qemuu-win7-amd64
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 21 September 2018 11:17
> To: Paul Durrant
> Cc: Kevin Tian ; xen-devel de...@lists.xenproject.org>
> Subject: Re: [Xen-devel] [PATCH 6/7] vtd: change lookup_page failure
> semantics
>
> >>> On 20.09.18 at 16:11,
>>> On 21.09.18 at 12:18, wrote:
>> -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 21 September 2018 11:17
>> To: Paul Durrant
>> Cc: Kevin Tian ; xen-devel > de...@lists.xenproject.org>
>> Subject: Re: [Xen-devel] [PATCH 6/7] vtd: change lookup_page failure
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 21 September 2018 11:28
> To: Paul Durrant
> Cc: Kevin Tian ; xen-devel de...@lists.xenproject.org>
> Subject: RE: [Xen-devel] [PATCH 6/7] vtd: change lookup_page failure
> semantics
>
> >>> On 21.09.18 at 12:18,
>>> On 21.09.18 at 09:30, wrote:
> --- a/xen/arch/x86/hvm/save.c
> +++ b/xen/arch/x86/hvm/save.c
> @@ -165,7 +165,8 @@ int hvm_save_one(struct domain *d, unsigned int typecode,
> unsigned int instance,
> if ( (rv = hvm_sr_handlers[typecode].save(v, &ctxt)) != 0 )
> printk(XENLOG_G_E
>>> On 21.09.18 at 12:15, wrote:
> On Fri, Sep 21, 2018 at 12:45:18PM +0300, Razvan Cojocaru wrote:
>> While doing my best to make sure what I understand to be George's
>> proposed changes for the altp2m series I've tried to boot Xen staging on
>> an AMD host, but it crashes in an unrelated place
flight 127846 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127846/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm broken
build-i386-xsm4 host-install(4)
On 9/21/18 1:41 PM, Jan Beulich wrote:
On 21.09.18 at 12:15, wrote:
>> On Fri, Sep 21, 2018 at 12:45:18PM +0300, Razvan Cojocaru wrote:
>>> While doing my best to make sure what I understand to be George's
>>> proposed changes for the altp2m series I've tried to boot Xen staging on
>>> an AMD
On Tue, Sep 11, 2018 at 07:32:04AM -0600, Jan Beulich wrote:
> In a number of cases the targets of indirect calls get determined once
> at boot time. In such cases we can replace those calls with direct ones
> via our alternative instruction patching mechanism.
>
> Some of the targets (in particul
On Tue, Sep 11, 2018 at 07:32:55AM -0600, Jan Beulich wrote:
> This is intentionally not touching hooks used rarely (or not at all)
> during the lifetime of a VM, like {domain,vcpu}_initialise or cpu_up,
> as well as nested, VM event, and altp2m ones (they can all be done
> later, if so desired). V
On Tue, Sep 11, 2018 at 07:33:45AM -0600, Jan Beulich wrote:
> While not strictly necessary, change the VMX initialization logic to
> update the function table in start_vmx() from NULL rather than to NULL,
> to make more obvious that we won't ever change an already (explictly)
> initialized functio
On Tue, Sep 11, 2018 at 07:34:15AM -0600, Jan Beulich wrote:
> Signed-off-by: Jan Beulich
Reviewed-by: Wei Liu
> ---
> v2: Drop open-coded number from macro invocation.
>
> --- a/xen/arch/x86/cpu/common.c
> +++ b/xen/arch/x86/cpu/common.c
> @@ -184,7 +184,7 @@ void ctxt_switch_levelling(const
On Tue, Sep 11, 2018 at 07:35:04AM -0600, Jan Beulich wrote:
> Instead of loading a pointer at each use site, have a single runtime
> instance of struct genapic, copying into it from the individual
> instances. The individual instances can this way also be moved to .init
> (also adjust apic_probe[]
...in intel_iommu_unmap_page().
This patch also includes some non-functional modifications in
intel_iommu_map_page().
Signed-off-by: Paul Durrant
Acked-by: Kevin Tian
---
Cc: Wei Liu
Cc: Jan Beulich
Cc: George Dunlap
v8:
- New in v8. (Split from the next patch in the series as requested by
The name 'iommu_use_hap_pt' suggests that that P2M table is in use as the
domain's IOMMU pagetable which, prior to this patch, is not strictly true
since the macro did not test whether the domain actually has IOMMU
mappings.
Signed-off-by: Paul Durrant
Reviewed-by: Kevin Tian
---
Cc: Jun Nakajim
This patch adds a new method to the VT-d IOMMU implementation to find the
MFN currently mapped by the specified DFN along with a wrapper function
in generic IOMMU code to call the implementation if it exists.
NOTE: This patch only adds a Xen-internal interface. This will be used by
a subsequ
...for some uses of get_page_from_gfn().
There are many occurrences of the following pattern in the code:
q = ? P2M_ALLOC : P2M_UNSHARE;
page = get_page_from_gfn(d, gfn, &p2mt, q);
if ( p2m_is_paging(p2mt) )
{
if ( page )
put_page(page);
p2m_mem_pagi
...meaning 'device DMA frame number' i.e. a frame number mapped in the IOMMU
(rather than the MMU) and hence used for DMA address translation.
This patch is a largely cosmetic change that substitutes the terms 'gfn'
and 'gaddr' for 'dfn' and 'daddr' in all the places where the frame number
or addr
This patch removes the implicit domain_crash() from iommu_map(),
unmap_page() and iommu_iotlb_flush() and turns them into straightforward
wrappers that check the existence of the relevant iommu_op and call
through to it. This makes them usable by PV IOMMU code to be delivered in
future patches.
Thi
This patch modifies the declaration of the entry points to the IOMMU
sub-system to use dfn_t and mfn_t in place of unsigned long. A subsequent
patch will similarly modify the methods in the iommu_ops structure.
Signed-off-by: Paul Durrant
Reviewed-by: Wei Liu
Reviewed-by: Kevin Tian
Reviewed-by
This series contains pre-requisites and clean-up needed for paravirtual
IOMMU support.
I have separated these patches to avoid further delaying their application
whilst I re-work the implementation of paravirtual IOMMU after review of
v6 of the series. Several of them already have all necessary ac
The name 'need_iommu()' is a little confusing as it suggests a domain needs
to use the IOMMU but something might not be set up yet, when in fact it
represents a tri-state value (not a boolean as might be expected) where
-1 means 'IOMMU mappings being set up' and 1 means 'IOMMU mappings have
been fu
This patch modifies the methods in struct iommu_ops to use type-safe DFN
and MFN. This follows on from the prior patch that modified the functions
exported in xen/iommu.h.
Signed-off-by: Paul Durrant
Reviewed-by: Wei Liu
Reviewed-by: Kevin Tian
Reviewed-by: Roger Pau Monne
Acked-by: Jan Beulic
Instead return RAM_TYPE_UNKNOWN.
Reported-by: Razvan Cojocaru
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
Cc: Razvan Cojocaru
---
xen/arch/x86/mm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
>>> On 21.09.18 at 12:48, wrote:
> On 9/21/18 1:41 PM, Jan Beulich wrote:
> On 21.09.18 at 12:15, wrote:
>>> On Fri, Sep 21, 2018 at 12:45:18PM +0300, Razvan Cojocaru wrote:
While doing my best to make sure what I understand to be George's
proposed changes for the altp2m series I've
On Tue, Sep 11, 2018 at 07:35:33AM -0600, Jan Beulich wrote:
> For (I hope) obvious reasons only the ones used at runtime get
> converted.
>
> Signed-off-by: Jan Beulich
> ---
> v2: Drop open-coded numbers from macro invocations.
>
> --- a/xen/arch/x86/smp.c
> +++ b/xen/arch/x86/smp.c
> @@ -29,1
On Fri, Sep 21, 2018 at 05:00:54AM -0600, Jan Beulich wrote:
> >>> On 21.09.18 at 12:48, wrote:
> > On 9/21/18 1:41 PM, Jan Beulich wrote:
> > On 21.09.18 at 12:15, wrote:
> >>> On Fri, Sep 21, 2018 at 12:45:18PM +0300, Razvan Cojocaru wrote:
> While doing my best to make sure what I und
On Fri, Sep 21, 2018 at 01:05:42PM +0200, Roger Pau Monné wrote:
> On Fri, Sep 21, 2018 at 05:00:54AM -0600, Jan Beulich wrote:
> > >>> On 21.09.18 at 12:48, wrote:
> > > On 9/21/18 1:41 PM, Jan Beulich wrote:
> > > On 21.09.18 at 12:15, wrote:
> > >>> On Fri, Sep 21, 2018 at 12:45:18PM +0300
>>> On 21.09.18 at 12:49, wrote:
> On Tue, Sep 11, 2018 at 07:32:04AM -0600, Jan Beulich wrote:
>> @@ -218,6 +219,13 @@ void init_or_livepatch apply_alternative
>
> I think you need to fix the comment before this if statement. At the
> very least you're now using two ->priv to make decision on pa
On 9/21/18 2:18 PM, Roger Pau Monné wrote:
> On Fri, Sep 21, 2018 at 01:05:42PM +0200, Roger Pau Monné wrote:
>> On Fri, Sep 21, 2018 at 05:00:54AM -0600, Jan Beulich wrote:
>> On 21.09.18 at 12:48, wrote:
On 9/21/18 1:41 PM, Jan Beulich wrote:
On 21.09.18 at 12:15, wrote:
>
>>> On 21.09.18 at 13:03, wrote:
> On Tue, Sep 11, 2018 at 07:35:33AM -0600, Jan Beulich wrote:
>> --- a/xen/include/asm-x86/mach-generic/mach_apic.h
>> +++ b/xen/include/asm-x86/mach-generic/mach_apic.h
>> @@ -15,8 +15,18 @@
>> #define TARGET_CPUS ((const typeof(cpu_online_map) *)&cpu_online_map
>>> On 21.09.18 at 13:05, wrote:
> On Fri, Sep 21, 2018 at 05:00:54AM -0600, Jan Beulich wrote:
>> >>> On 21.09.18 at 12:48, wrote:
>> > On 9/21/18 1:41 PM, Jan Beulich wrote:
>> > On 21.09.18 at 12:15, wrote:
>> >>> On Fri, Sep 21, 2018 at 12:45:18PM +0300, Razvan Cojocaru wrote:
>> Wh
>>> On 21.09.18 at 13:18, wrote:
> On Fri, Sep 21, 2018 at 01:05:42PM +0200, Roger Pau Monné wrote:
>> On Fri, Sep 21, 2018 at 05:00:54AM -0600, Jan Beulich wrote:
>> > >>> On 21.09.18 at 12:48, wrote:
>> > > On 9/21/18 1:41 PM, Jan Beulich wrote:
>> > > On 21.09.18 at 12:15, wrote:
>> > >>>
>>> On 21.09.18 at 12:59, wrote:
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -465,7 +465,7 @@ unsigned int page_get_ram_type(mfn_t mfn)
> break;
>
> default:
> -ASSERT_UNREACHABLE();
> +type |= RAM_TYPE_UNKNOWN;
> }
> }
Th
On 9/20/18 3:50 PM, George Dunlap wrote:
> On 09/03/2018 04:48 PM, Adrian Pop wrote:
>> Signed-off-by: Adrian Pop
>> +++ b/xen/arch/x86/mm/mem_access.c
>> @@ -550,6 +550,51 @@ out:
>> return rc;
>> }
>>
>> +int p2m_get_suppress_ve(struct domain *d, gfn_t gfn, bool *suppress_ve,
>> +
On 9/21/18 4:16 PM, Razvan Cojocaru wrote:
> On 9/20/18 3:50 PM, George Dunlap wrote:
>> On 09/03/2018 04:48 PM, Adrian Pop wrote:
>>> Signed-off-by: Adrian Pop
>>> +++ b/xen/arch/x86/mm/mem_access.c
>>> @@ -550,6 +550,51 @@ out:
>>> return rc;
>>> }
>>>
>>> +int p2m_get_suppress_ve(struct
On Fri, Sep 21, 2018 at 06:04:31AM -0600, Jan Beulich wrote:
> >>> On 21.09.18 at 12:59, wrote:
> > --- a/xen/arch/x86/mm.c
> > +++ b/xen/arch/x86/mm.c
> > @@ -465,7 +465,7 @@ unsigned int page_get_ram_type(mfn_t mfn)
> > break;
> >
> > default:
> > -ASSERT_UNRE
On Fri, Sep 21, 2018 at 05:47:54AM -0600, Jan Beulich wrote:
> >>> On 21.09.18 at 12:49, wrote:
> > On Tue, Sep 11, 2018 at 07:32:04AM -0600, Jan Beulich wrote:
> >> @@ -218,6 +219,13 @@ void init_or_livepatch apply_alternative
> >
> > I think you need to fix the comment before this if statement.
On Tue, Sep 11, 2018 at 07:35:33AM -0600, Jan Beulich wrote:
> For (I hope) obvious reasons only the ones used at runtime get
> converted.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
h
On Tue, Sep 11, 2018 at 07:35:58AM -0600, Jan Beulich wrote:
> For now only the ones used during entering/exiting of idle states are
> converted. Additionally pm_idle{,_save} and lapic_timer_{on,off} can't
> be converted, as they may get established rather late (when Dom0 is
> already active).
>
>
On Tue, Sep 11, 2018 at 07:37:00AM -0600, Jan Beulich wrote:
> This reduces the post-init memory footprint, eliminates a pointless
> level of indirection at the use sites, and allows for subsequent
> alternatives call patching.
>
> Take the opportunity and also add a name to the PowerNow! instance
On Tue, Sep 11, 2018 at 07:37:37AM -0600, Jan Beulich wrote:
> This looks to be the only frequently executed hook; don't bother
> patching any other ones.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.
Hey,
yes, I can see prink's outputs on console and in xl dmesg. Also added
timestamps, here are the results (created and destroyed domU a few
times, just to get more values), this is from xl dmesg:
NULL SCHEDULER - Not stressed PetaLinux host domain.
(XEN) t=218000327743:End of a domain_destroy f
On Fri, 2018-09-21 at 04:34 -0600, Jan Beulich wrote:
> > > > On 21.09.18 at 09:30, wrote:
> >
> > --- a/xen/arch/x86/hvm/save.c
> > +++ b/xen/arch/x86/hvm/save.c
> > @@ -165,7 +165,8 @@ int hvm_save_one(struct domain *d, unsigned int
> > typecode, unsigned int instance,
> > if ( (rv = hvm_s
Firstly, add a reference to the documentation for the kconfig system.
Secondly, warn the user about the XEN_CONFIG_EXPERT problem.
CC: Doug Goldstein
CC: Wei Liu
CC: Jan Beulich
CC: Andrew Cooper
Signed-off-by: Ian Jackson
---
INSTALL | 20
1 file changed, 20 insertions
And just rely on arch_iommu_hwdom_init to setup the correct inclusive
mappings as it's done for Intel.
AMD has code in amd_iommu_hwdom_init to setup inclusive mappings up to
max_pdx, remove this since it's now a duplication of
arch_iommu_hwdom_init. Note that AMD mapped every page with a valid
mfn
>>> On 21.09.18 at 15:48, wrote:
> On Fri, Sep 21, 2018 at 05:47:54AM -0600, Jan Beulich wrote:
>> >>> On 21.09.18 at 12:49, wrote:
>> > On Tue, Sep 11, 2018 at 07:32:04AM -0600, Jan Beulich wrote:
>> >> @@ -218,6 +219,13 @@ void init_or_livepatch apply_alternative
>> >
>> > I think you need to
> -Original Message-
> From: Roger Pau Monne [mailto:roger@citrix.com]
> Sent: 21 September 2018 16:21
> To: xen-devel@lists.xenproject.org
> Cc: Roger Pau Monne ; Suravee Suthikulpanit
> ; Brian Woods ; Kevin
> Tian ; Jan Beulich ; Paul Durrant
>
> Subject: [PATCH] amd/iommu: remove h
flight 127881 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127881/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
>>> On 21.09.18 at 16:56, wrote:
> Firstly, add a reference to the documentation for the kconfig system.
>
> Secondly, warn the user about the XEN_CONFIG_EXPERT problem.
>
> CC: Doug Goldstein
> CC: Wei Liu
> CC: Jan Beulich
> CC: Andrew Cooper
> Signed-off-by: Ian Jackson
Fundamentally I'
On Fri, Sep 21, 2018 at 2:40 AM Arun KS wrote:
>
> When free pages are done with higher order, time spend on
> coalescing pages by buddy allocator can be reduced. With
> section size of 256MB, hot add latency of a single section
> shows improvement from 50-60 ms to less than 1 ms, hence
> improvin
On Fri, Sep 14, 2018 at 06:50:06AM -0600, Jan Beulich wrote:
> >>> On 13.09.18 at 18:38, wrote:
> > --- a/xen/arch/x86/domain.c
> > +++ b/xen/arch/x86/domain.c
> > @@ -1691,7 +1691,9 @@ void context_switch(struct vcpu *prev, struct vcpu
> > *next)
> > {
> > _update_runstate_area(pre
On Thu, Sep 13, 2018 at 10:50:45AM -0600, Tamas K Lengyel wrote:
> > @@ -483,12 +495,15 @@ int p2m_get_mem_access(struct domain *d, gfn_t gfn,
> > xenmem_access_t *access)
> >
> > void arch_p2m_set_access_required(struct domain *d, bool access_required)
> > {
> > +#ifdef CONFIG_HVM
> > unsi
On Fri, Sep 14, 2018 at 06:55:17AM -0600, Jan Beulich wrote:
> >>> On 13.09.18 at 18:38, wrote:
> > Signed-off-by: Wei Liu
> > ---
> > v4: remove a blank line
> > v3: longer text
> > v2: use tab to indent
> >
> > Haven't added a dependency on PV_SHIM_EXCLUSIVE because agreement is
> > not yet re
Going through the code, HAP, EPT, PoD and ALTP2M depend on HVM code.
Put these components under CONFIG_HVM. This further requires putting
one of the vm event under CONFIG_HVM.
Altp2m requires a bit more attention because its code is embedded in
generic x86 p2m code.
Also make hap_enabled evaluate
These functions are only useful for nested hvm, which isn't enabled
when CONFIG_HVM is false.
Enclose relevant code and fields in CONFIG_HVM.
Signed-off-by: Wei Liu
Acked-by: Jan Beulich
---
v5:
1. Provide stub for np2m_schedule
v4:
1. Introduce p2m_nestedp2m_init
---
xen/arch/x86/mm/p2m.c
This series goes through x86 code to make CONFIG_HVM work.
With this series, it is possible to build Xen with PV support only.
See cover letters from previous versions for more details.
Wei.
Wei Liu (5):
x86/mem_access: put p2m_{get/set}_suppress_ve under CONFIG_HVM
x86/p2m/pod: make it bui
Populate-on-demand is HVM only.
Provide a bunch of stubs for common p2m code and guard one invocation
of guest_physmap_mark_populate_on_demand with is_hvm_domain.
Put relevant fields in p2m_domain and code which touches those fields
under CONFIG_HVM.
Signed-off-by: Wei Liu
---
v5:
1. Introduce
Signed-off-by: Wei Liu
---
v5: change default to !PV_SHIM_EXCLUSIVE
v4: remove a blank line
v3: longer text
v2: use tab to indent
---
xen/arch/x86/Kconfig | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index ae1b707..54
They are used by HVM code only.
Signed-off-by: Wei Liu
---
v5: new
---
xen/arch/x86/mm/mem_access.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/xen/arch/x86/mm/mem_access.c b/xen/arch/x86/mm/mem_access.c
index 2217bda..826c35f 100644
--- a/xen/arch/x86/mm/mem_access.c
+++ b/xen/arch/x8
On 9/21/18 6:54 PM, Wei Liu wrote:
> They are used by HVM code only.
>
> Signed-off-by: Wei Liu
> ---
> v5: new
> ---
> xen/arch/x86/mm/mem_access.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/xen/arch/x86/mm/mem_access.c b/xen/arch/x86/mm/mem_access.c
> index 2217bda..826c35f 10
On Fri, Sep 14, 2018 at 06:41:49AM -0600, Jan Beulich wrote:
> >>> On 13.09.18 at 18:38, wrote:
> > --- a/xen/arch/x86/mm/p2m-pt.c
> > +++ b/xen/arch/x86/mm/p2m-pt.c
> > @@ -974,7 +974,9 @@ long p2m_pt_audit_p2m(struct p2m_domain *p2m)
> > unsigned long mfn, gfn, m2pfn;
> >
> > ASSERT(
On Fri, Sep 21, 2018 at 06:57:39PM +0300, Razvan Cojocaru wrote:
> On 9/21/18 6:54 PM, Wei Liu wrote:
> > They are used by HVM code only.
> >
> > Signed-off-by: Wei Liu
> > ---
> > v5: new
> > ---
> > xen/arch/x86/mm/mem_access.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/
When free pages are done with higher order, time spend on
coalescing pages by buddy allocator can be reduced. With
section size of 256MB, hot add latency of a single section
shows improvement from 50-60 ms to less than 1 ms, hence
improving the hot add latency by 60%.
Modify external providers of
flight 127876 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127876/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
freebsd d09bac9dfb4d2f09f4b9350f29b5bc177f798c96
baseline version:
freebsd fb80e9f8be0
This is required to retain affinity setting across save/restore and
migration.
Signed-off-by: Wei Liu
---
tools/libxl/libxl_domain.c | 46 ---
1 file changed, 43 insertions(+), 3 deletions(-)
diff --git a/tools/libxl/libxl_domain.c b/tools/libxl/libxl_domain.
On Thu, Sep 20, 2018 at 12:40:25PM +0200, Roger Pau Monne wrote:
> Fill the from_xenstore libxl_device_type hook for PCI devices so that
> libxl_retrieve_domain_configuration can properly retrieve PCI devices
> from xenstore.
>
> This fixes disappearing pci devices across domain reboots.
>
> Repo
[Adding Julien as well.
Julien, this seems related to the RCU issue we fought on ARM when using
Credit2, although this is null, but it's being even more weird...]
On Fri, 2018-09-21 at 16:14 +0200, Milan Boberic wrote:
> Hey,
> yes, I can see prink's outputs on console and in xl dmesg. Also added
On Fri, Sep 21, 2018 at 03:56:33PM +0100, Ian Jackson wrote:
> +
> +You can counter-override this behaviour by setting XEN_CONFIG_EXPERT=y
> +in your environment. However, doing this is not supported and the
> +resulting configurations do not receive security support. If you set
Err... but we se
On 9/21/18 7:03 PM, Wei Liu wrote:
> On Fri, Sep 21, 2018 at 06:57:39PM +0300, Razvan Cojocaru wrote:
>> On 9/21/18 6:54 PM, Wei Liu wrote:
>>> They are used by HVM code only.
>>>
>>> Signed-off-by: Wei Liu
>>> ---
>>> v5: new
>>> ---
>>> xen/arch/x86/mm/mem_access.c | 2 ++
>>> 1 file changed, 2
When dm_restrict is enabled, ask QEMU to chroot into an empty directory.
* Create /var/run/qemu/root-domid (deleting the old one if it's there)
* Pass the -chroot option to QEMU
Rather than running `rm -rf` on the directory before creating it
(since there is no library function to do this), simpl
Limit the ability of a potentially compromised QEMU to consume system
resources. Key limits:
- RLIMIT_FSIZE (file size): 256KiB
- RLIMIT_NPROC (after uid changes to a unique uid)
Probably unnecessary limits but why not:
- RLIMIT_CORE: 0
- RLIMIT_MSGQUEUE: 0
- RLIMIT_LOCKS: 0
- RLIMIT_MEMLOC
QEMU has a `sandbox` feature, wherein it will use seccomp2 to restrict
what system calls it is able to make.
Suggested-by: Ross Lagerwall
Signed-off-by: George Dunlap
---
This can't be checked in as-is, because `-sandbox` support may not have
been compiled in. We therefore need to either:
1. R
Add a tool to check whether the various process-level deprivileging
operations have actually taken place on the process.
The tool takes a domname or domid, and returns success or failure.
To begin with, only test the process/group it setting, since this is
the only restriction currently implement
QEMU running under Xen doesn't need mount or IPC functionality.
Create and enter separate namespaces for each of these before
executing QEMU, so that in the event that other restrictions fail, the
process won't be able to even name system mount points or exsting
non-file-based IPC descriptors to at
docs/qemu-deprivilege.txt had some basic instructions for using
dm_restrict, but it was incomplete, misleading, and stale.
Update the docs in a number of ways.
First, separate user-facing documentation and technical description
into docs/features and docs/design, respectively.
In the feature doc
flight 127869 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127869/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 123814
build-arm64-libvirt
flight 127816 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127816/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-shadow broken
test-amd64-amd64-xl-shadow4 host-inst
flight 127822 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127822/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvhv2-amd broken
Tests which are failin
On Wed, Sep 19, 2018 at 10:34:47AM +0100, Wei Liu wrote:
> Hi Daniel,
>
> I discovered an out of bounds access issue related to GRUB relocation
> code path when inspecting early boot code.
>
> 9589927e5b changed an EFI only path to work with GRUB. Yet the following
> two lines within an if conditio
Compiling with _FORTIFY_SOURCE or higher levels of optimization enabled
will always_inline several library fns (memset, memcpy, ...)
(with gcc 8.2.0 and glibc 2.28).
In fuzz and x86_emulator test, the compiler is instructed not
to generate SSE instructions via: #pragma GCC target("no-sse")
because
flight 127891 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127891/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
flight 127880 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127880/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 997731e796f51df57c113dfd966e818622c3d4aa
baseline version:
ovmf ae57950fc878618083bca
flight 127833 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127833/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-pairbroken
build-i386-xsm
flight 127892 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127892/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 123814
build-arm64-libvirt
flight 127877 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127877/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-pvshim12 guest-start fail never pass
test-arm64-arm64-xl-credit2 13 migrat
3.16.58-rc1 review patch. If anyone has any objections, please let me know.
--
From: Andy Lutomirski
commit b3681dd548d06deb2e1573890829dff4b15abf46 upstream.
error_entry and error_exit communicate the user vs. kernel status of
the frame using %ebx. This is unnecessary -- the
1 - 100 of 103 matches
Mail list logo
