>>> On 07.03.18 at 20:12, wrote:
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -399,6 +399,9 @@ struct domain *domain_create(domid_t domid, unsigned int
> domcr_flags,
> return d;
>
> fail:
> +ASSERT(err < 0); /* Sanity check paths leading here. */
> +err = er
>>> On 07.03.18 at 21:52, wrote:
> When starting a guest with the 'xl create' command (non-verbose) i get
> this extra output on PVH guest types only:
>
> S3 disabled
> S4 disabled
> CONV disabled
>
>
> It seems libacpi/* only contains normal printf's, so for the other guest
> types i probably
>>> On 05.03.18 at 16:56, wrote:
> On 28/02/18 13:03, Jan Beulich wrote:
>> @@ -5178,18 +5202,33 @@ x86_emulate(
>> _regs.eflags |= X86_EFLAGS_AC;
>> break;
>>
>> -#ifdef __XEN__
>> -case 0xd1: /* xsetbv */
>> +case 0xd0: /* xgetbv */
>>
On Wed, 2018-03-07 at 12:04 -0800, Stefano Stabellini wrote:
> On Wed, 7 Mar 2018, Andrew Cooper wrote:
> > The OSSTest smoke tests reports:
> >
> > sched_credit2.c: In function 'csched2_alloc_domdata':
> > sched_credit2.c:3015:9: error: implicit declaration of function
> 'ERR_PTR' [-Werror=im
On 03/07/2018 07:41 PM, Andrew Cooper wrote:
> The OSSTest smoke tests reports:
>
> sched_credit2.c: In function 'csched2_alloc_domdata':
> sched_credit2.c:3015:9: error: implicit declaration of function 'ERR_PTR'
> [-Werror=implicit-function-declaration]
>return ERR_PTR(-ENOMEM);
flight 120342 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120342/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 120304
build-armhf
>>> On 02.03.18 at 09:14, wrote:
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -510,15 +510,19 @@ void make_cr3(struct vcpu *v, mfn_t mfn)
>
> void write_ptbase(struct vcpu *v)
> {
> -if ( this_cpu(root_pgt) && is_pv_vcpu(v) && !is_pv_32bit_vcpu(v) )
> +if ( is_pv_vcpu(v) &&
All uploaded PM data from non-dom0 CPUs takes the info from vCPU 0 and
changing only the acpi_id. For processors which P-state coordination type
is HW_ALL (0xFD) it is OK to upload bogus P-state dependency information
(_PSD), because Xen will ignore any cpufreq domains created for past CPUs.
Albei
Hello,
On 08/03/18 06:15, Peng Fan wrote:
Hi Stefano,
On Fri, Mar 02, 2018 at 11:05:54AM -0800, Stefano Stabellini wrote:
Hi all,
This series changes the initialization of two virtual registers to make
sure they match the value of the underlying physical cpu.
It also disables cpus different f
Travis reports:
sched_rt.c:241:30: error: unused function 'rt_dom' [-Werror,-Wunused-function]
static inline struct rt_dom *rt_dom(const struct domain *dom)
^
1 error generated.
when compiling with Clang. Drop the function.
Signed-off-by: Andrew Cooper
---
Instead of using RDMSR/WRMSR, on fsgsbase-capable systems use a double
SWAPGS combined with RDGSBASE/WRGSBASE. This halves execution time for
a shadow GS update alone on my Haswell (and we have indications of
good performance improvements by this on Skylake too), while the win is
even higher when e
On 08/03/18 11:15, Jan Beulich wrote:
> Instead of using RDMSR/WRMSR, on fsgsbase-capable systems use a double
> SWAPGS combined with RDGSBASE/WRGSBASE. This halves execution time for
> a shadow GS update alone on my Haswell (and we have indications of
> good performance improvements by this on Sky
On 08/03/18 11:17, Jan Beulich wrote:
On 02.03.18 at 09:14, wrote:
>> --- a/xen/arch/x86/mm.c
>> +++ b/xen/arch/x86/mm.c
>> @@ -510,15 +510,19 @@ void make_cr3(struct vcpu *v, mfn_t mfn)
>>
>> void write_ptbase(struct vcpu *v)
>> {
>> -if ( this_cpu(root_pgt) && is_pv_vcpu(v) && !is_p
Now that we zero all registers early on all entry paths, use that to
avoid a couple of immediates here.
Signed-off-by: Jan Beulich
---
We may want to consider eliminating a few more $0 this way. But
especially for byte ones I'm not sure it's worth it, due to the REX
prefix the use of %r12 would i
This exposes less code pieces and at the same time reduces the range
covered from slightly above 3 pages to a little below 2 of them.
The code being moved is entirely unchanged, except for the removal of
trailing blanks and a pointless q suffix from "retq".
A few more small pieces could be moved,
Hello.
Can I limit a user for make VM via Xen? For example, user can't create a VM
that have memory more than of 2GB RAM.
Thank you.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 05/03/18 17:43, Jan Beulich wrote:
On 02.03.18 at 09:13, wrote:
>> --- a/xen/arch/x86/mm.c
>> +++ b/xen/arch/x86/mm.c
>> @@ -509,6 +509,8 @@ void make_cr3(struct vcpu *v, mfn_t mfn)
>>
>> void write_ptbase(struct vcpu *v)
>> {
>> +get_cpu_info()->root_pgt_changed = this_cpu(root_pg
Jan Beulich writes ("Re: osstest planned outage consultation"):
> On 06.03.18 at 20:32, wrote:
> > How about 28th-30th March ? Bearing in mind staff availability.
>
> Fine with me, hoping there aren't any delays with the stable
> releases.
It turns out that another key member of staff is away t
flight 120283 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120283/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-i386-pvgrub broken
test-xtf-amd64-am
Ping?
On Tue, Feb 13, 2018 at 08:03:59PM +, Wei Liu wrote:
> Hello
>
> This series can be found at:
>https://xenbits.xen.org/git-http/people/liuw/xen.git wip.split-mm-v6.1
>
> Unfortunately there isn't any resemblance to v5 because a lot of things
> have changed since Sept last year. And
Ping?
Any more comment on this?
On Wed, Feb 21, 2018 at 09:46:51PM +, Wei Liu wrote:
> Hi all
>
> At some point I would like to make CONFIG_HVM and CONFIG_PV work. The
> passthrough code is one of the road blocks for that work.
>
> A short discussion on #xendevel made me think that having
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf Of
> Julien Grall
> Sent: 2018年3月8日 19:04
> To: Peng Fan ; Stefano Stabellini
>
> Cc: xen-de...@lists.xen.org
> Subject: Re: [Xen-devel] [PATCH v4 0/7] unsafe big.LITTLE support
>
> Hello,
>
Hi,
On 08/03/18 12:23, Peng Fan wrote:
-Original Message-
From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf Of
Julien Grall
Sent: 2018年3月8日 19:04
To: Peng Fan ; Stefano Stabellini
Cc: xen-de...@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v4 0/7] unsafe big.L
>>> On 08.03.18 at 13:17, wrote:
> Ping?
I'm sorry, but still no time to look over this.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
>>> On 08.03.18 at 13:18, wrote:
> Ping?
And I'm sorry again, even less so for any RFCs (there are about 100
older ones as well that want looking at).
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/
Hi,
On 06/03/18 13:49, Julien Grall wrote:
>
>
> On 05/03/18 17:08, Julien Grall wrote:
>> On 05/03/18 16:03, Andre Przywara wrote:
>>> Instead of hard coding the architected redistributor stride into the
>>> code, lets use a clear #define to the two values for GICv3 and GICv4 and
>>> clarify th
> -Original Message-
> From: Julien Grall [mailto:julien.gr...@arm.com]
> Sent: 2018年3月8日 20:30
> To: Peng Fan ; Peng Fan ;
> Stefano Stabellini
> Cc: xen-de...@lists.xen.org
> Subject: Re: [Xen-devel] [PATCH v4 0/7] unsafe big.LITTLE support
>
> Hi,
>
> On 08/03/18 12:23, Peng Fan wro
>>> On 08.03.18 at 12:59, wrote:
> On 05/03/18 17:43, Jan Beulich wrote:
> On 02.03.18 at 09:13, wrote:
>>> @@ -3704,18 +3706,22 @@ long do_mmu_update(
>>> break;
>>> rc = mod_l4_entry(va, l4e_from_intpte(req.val), mfn,
>>>
>>> On 08.03.18 at 12:30, wrote:
> On 08/03/18 11:17, Jan Beulich wrote:
> On 02.03.18 at 09:14, wrote:
>>> +static int parse_xpti(const char *s)
>>> +{
>>> +int rc = 0;
>>> +
>>> +switch ( parse_bool(s, NULL) )
>>> +{
>>> +case 0:
>>> +opt_xpti = XPTI_OFF;
>>> +
This should help to avoid problems with accessing the device after
migration/resume without PV drivers. Older systems will acquire
the new record when migrated which should not change their state for
worse.
Signed-off-by: Igor Druzhinin
---
hw/i386/xen/xen_pvdevice.c | 11 +++
1 file cha
> -Original Message-
> From: Igor Druzhinin [mailto:igor.druzhi...@citrix.com]
> Sent: 08 March 2018 12:53
> To: qemu-de...@nongnu.org; xen-devel@lists.xenproject.org
> Cc: sstabell...@kernel.org; Paul Durrant ; Anthony
> Perard ; m...@redhat.com;
> pbonz...@redhat.com; Igor Druzhinin
> Su
On 08/03/18 13:47, Jan Beulich wrote:
On 08.03.18 at 12:59, wrote:
>> On 05/03/18 17:43, Jan Beulich wrote:
>> On 02.03.18 at 09:13, wrote:
@@ -3704,18 +3706,22 @@ long do_mmu_update(
break;
rc = mod_l4_entry(va, l4e_from_intpt
On 08/03/18 13:49, Jan Beulich wrote:
On 08.03.18 at 12:30, wrote:
>> On 08/03/18 11:17, Jan Beulich wrote:
>> On 02.03.18 at 09:14, wrote:
+static int parse_xpti(const char *s)
+{
+int rc = 0;
+
+switch ( parse_bool(s, NULL) )
+{
+case
flight 120347 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120347/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
>>> On 02.03.18 at 09:14, wrote:
> Instead of flushing the TLB from global pages when switching address
> spaces with XPTI being active just disable global pages via %cr4
> completely when a domain subject to XPTI is active. This avoids the
> need for extra TLB flushes as loading %cr3 will remove
On 08/03/18 14:38, Jan Beulich wrote:
On 02.03.18 at 09:14, wrote:
>> Instead of flushing the TLB from global pages when switching address
>> spaces with XPTI being active just disable global pages via %cr4
>> completely when a domain subject to XPTI is active. This avoids the
>> need for ext
>>> On 02.03.18 at 09:14, wrote:
> This reduces the number of branches in interrupt handling and results
> in better performance (e.g. parallel make of the Xen hypervisor on my
> system was using about 3% less system time).
3% seems an awful lot for a single conditional branch on each of the
thre
On 08/03/18 15:24, Jan Beulich wrote:
On 02.03.18 at 09:14, wrote:
>> This reduces the number of branches in interrupt handling and results
>> in better performance (e.g. parallel make of the Xen hypervisor on my
>> system was using about 3% less system time).
>
> 3% seems an awful lot for a
On 06/03/18 11:10, Arvind Yadav wrote:
> Never directly free @dev after calling device_register(), even
> if it returned an error! Always use put_device() to give up the
> reference initialized.
>
> Signed-off-by: Arvind Yadav
Committed to xen/tip.git for-linus-4.16a
Juergen
_
>>> On 08.03.18 at 15:05, wrote:
> On 08/03/18 14:38, Jan Beulich wrote:
> On 02.03.18 at 09:14, wrote:
>>> Instead of flushing the TLB from global pages when switching address
>>> spaces with XPTI being active just disable global pages via %cr4
>>> completely when a domain subject to XPTI is
On 08/03/18 15:33, Jan Beulich wrote:
On 08.03.18 at 15:05, wrote:
>> On 08/03/18 14:38, Jan Beulich wrote:
>> On 02.03.18 at 09:14, wrote:
Instead of flushing the TLB from global pages when switching address
spaces with XPTI being active just disable global pages via %cr4
>>> On 02.03.18 at 09:14, wrote:
> @@ -123,22 +142,14 @@ unsigned int flush_area_local(const void *va, unsigned
> int flags)
> u32 t = pre_flush();
>
> if ( !cpu_has_invpcid )
> -{
> -unsigned long cr4 = read_cr4();
> -
> -wr
Hi,
On 08/03/18 12:43, Peng Fan wrote:
I am not sure whether this issue cause DomU big/Little not work.
Well, I would recommend to speak with NXP whether this errata affects
TLB flush for Hypervisor Page-Table or Stage-2 Page-Table.
I tried the following, but no help. Not sure my patch is co
flight 120289 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120289/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail REGR. vs. 115539
Tests which did not suc
From: Julien Grall
Xen is currently allowing to route/remove an interrupt from/to the
domain while it is running.
However, we never sync the virtual interrupt state to the physical
interrupt. This could lead to undesirable effect on the vGIC emulation
and potentially the hardware.
One solution
>>> On 02.03.18 at 09:14, wrote:
> Avoid flushing the complete TLB when switching %cr3 for mitigation of
> Meltdown by using the PCID feature if available.
>
> We are using 4 PCID values for a 64 bit pv domain subject to XPTI:
>
> - hypervisor active and guest in kernel mode
> - guest active and
On 08/03/18 12:40, Andre Przywara wrote:
Hi,
Hi,
On 06/03/18 13:49, Julien Grall wrote:
On 05/03/18 17:08, Julien Grall wrote:
On 05/03/18 16:03, Andre Przywara wrote:
Instead of hard coding the architected redistributor stride into the
code, lets use a clear #define to the two values
flight 120284 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120284/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 broken
build-amd64 4 host-
Hi Andre,
On 05/03/18 16:03, Andre Przywara wrote:
The active register handlers are shared between the v2 and v3 emulation,
so their implementation goes into vgic-mmio.c, to be easily referenced
from the v3 emulation as well later.
Since activation/deactivation of an interrupt may happen entirel
>>> On 07.03.18 at 16:51, wrote:
> @@ -175,18 +175,47 @@ void init_or_livepatch apply_alternatives(const struct
> alt_instr *start,
> * So be careful if you want to change the scan order to any other
> * order.
> */
> -for ( a = start; a < end; a++ )
> +for ( a = base =
On 05/03/18 16:03, Andre Przywara wrote:
The priority register handlers are shared between the v2 and v3 emulation,
so their implementation goes into vgic-mmio.c, to be easily referenced
from the v3 emulation as well later.
There is a corner case when we change the priority of a pending
interru
>>> On 07.03.18 at 16:51, wrote:
> --- a/xen/arch/x86/Rules.mk
> +++ b/xen/arch/x86/Rules.mk
> @@ -29,6 +29,10 @@ $(call as-option-add,CFLAGS,CC,"invpcid
> (%rax)$$(comma)%rax",-DHAVE_AS_INVPCID)
> $(call as-option-add,CFLAGS,CC,\
> ".if ((1 > 0) < 0); .error \"\";.endif",,-DHAVE_AS_NEGATIV
Hi Andre,
On 05/03/18 16:03, Andre Przywara wrote:
The config register handlers are shared between the v2 and v3 emulation,
so their implementation goes into vgic-mmio.c, to be easily referenced
from the v3 emulation as well later.
This is based on Linux commit 79717e4ac09c, written by Andre Pr
Hi Andre,
On 05/03/18 16:04, Andre Przywara wrote:
The target register handlers are v2 emulation specific, so their
implementation lives entirely in vgic-mmio-v2.c.
We copy the old VGIC behaviour of assigning an IRQ to the first VCPU
set in the target mask instead of making it possibly pending o
Hi Jens,
Please git pull the following branch for your for-linus branch:
git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
stable/for-jens-4.15
It has one simple fix for the multi-queue support not showing up after a block
device was detached/re-attached.
The patch was originally po
Hi,
On 08/03/18 15:48, Julien Grall wrote:
>
>
> On 05/03/18 16:03, Andre Przywara wrote:
>> The priority register handlers are shared between the v2 and v3
>> emulation,
>> so their implementation goes into vgic-mmio.c, to be easily referenced
>> from the v3 emulation as well later.
>> There is
On 08/03/18 16:21, Andre Przywara wrote:
Hi,
On 08/03/18 15:48, Julien Grall wrote:
On 05/03/18 16:03, Andre Przywara wrote:
The priority register handlers are shared between the v2 and v3
emulation,
so their implementation goes into vgic-mmio.c, to be easily referenced
from the v3 emulati
On 08/03/18 15:42, Jan Beulich wrote:
On 07.03.18 at 16:51, wrote:
>> @@ -175,18 +175,47 @@ void init_or_livepatch apply_alternatives(const struct
>> alt_instr *start,
>> * So be careful if you want to change the scan order to any other
>> * order.
>> */
>> -for ( a = s
Hi,
On 06/03/18 16:06, Julien Grall wrote:
> Hi Andre,
>
> On 05/03/18 16:03, Andre Przywara wrote:
>> So far our LR read/write functions do not handle the EOI bit and the
>> source CPUID bits in an LR, because the current VGIC implementation does
>> not use them.
>> Extend the gic_lr data struct
On 3/8/18 9:19 AM, Konrad Rzeszutek Wilk wrote:
> Hi Jens,
>
> Please git pull the following branch for your for-linus branch:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
> stable/for-jens-4.15
>
> It has one simple fix for the multi-queue support not showing up after a blo
Hi,
On 05/03/18 16:04, Andre Przywara wrote:
Triggering an IPI via this register is v2 specific, so the
implementation lives entirely in vgic-mmio-v2.c.
This is based on Linux commit 55cc01fb9004, written by Andre Przywara.
Signed-off-by: Andre Przywara
---
Changelog RFC ... v1:
- use symboli
Hi,
On 08/03/18 16:18, Julien Grall wrote:
> Hi Andre,
>
> On 05/03/18 16:04, Andre Przywara wrote:
>> The target register handlers are v2 emulation specific, so their
>> implementation lives entirely in vgic-mmio-v2.c.
>> We copy the old VGIC behaviour of assigning an IRQ to the first VCPU
>> se
Hi Andre,
On 05/03/18 16:04, Andre Przywara wrote:
As this register is v2 specific, its implementation lives entirely
in vgic-mmio-v2.c.
This register allows setting the source mask of an IPI.
This is based on Linux commit ed40213ef9b0, written by Andre Przywara.
Signed-off-by: Andre Przywara
Hi,
On 08/03/18 16:25, Andre Przywara wrote:
On 06/03/18 16:06, Julien Grall wrote:
On 05/03/18 16:03, Andre Przywara wrote:
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index 8fab458d7f..89a07ae6b4 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@
>>> On 08.03.18 at 11:26, wrote:
> Console output added (7x OK, 2x FAILED).
Thanks. You've chopped off some of the messages though. I think
I've spotted the issue nevertheless - would you please give the
patch below a try?
Jan
cpufreq/ondemand: fix race while offlining CPU
Offlining a CPU invo
On 08/03/18 15:53, Jan Beulich wrote:
On 07.03.18 at 16:51, wrote:
>> --- a/xen/arch/x86/Rules.mk
>> +++ b/xen/arch/x86/Rules.mk
>> @@ -29,6 +29,10 @@ $(call as-option-add,CFLAGS,CC,"invpcid
>> (%rax)$$(comma)%rax",-DHAVE_AS_INVPCID)
>> $(call as-option-add,CFLAGS,CC,\
>> ".if ((1 > 0)
>>> On 08.03.18 at 17:23, wrote:
> On 08/03/18 15:42, Jan Beulich wrote:
> On 07.03.18 at 16:51, wrote:
>>> @@ -175,18 +175,47 @@ void init_or_livepatch apply_alternatives(const
>>> struct alt_instr *start,
>>> * So be careful if you want to change the scan order to any other
>>>
On 08/03/18 16:49, Jan Beulich wrote:
On 08.03.18 at 17:23, wrote:
>> On 08/03/18 15:42, Jan Beulich wrote:
>> On 07.03.18 at 16:51, wrote:
@@ -175,18 +175,47 @@ void init_or_livepatch apply_alternatives(const
struct alt_instr *start,
* So be careful if you want to
>>> On 08.03.18 at 17:48, wrote:
> On 08/03/18 15:53, Jan Beulich wrote:
> On 07.03.18 at 16:51, wrote:
>>> --- a/xen/arch/x86/Rules.mk
>>> +++ b/xen/arch/x86/Rules.mk
>>> @@ -29,6 +29,10 @@ $(call as-option-add,CFLAGS,CC,"invpcid
>>> (%rax)$$(comma)%rax",-DHAVE_AS_INVPCID)
>>> $(call as-op
On 03/08/2018 11:12 AM, Andrew Cooper wrote:
> Travis reports:
>
> sched_rt.c:241:30: error: unused function 'rt_dom'
> [-Werror,-Wunused-function]
> static inline struct rt_dom *rt_dom(const struct domain *dom)
>^
> 1 error generated.
>
> when compiling wit
On 03/08/2018 04:41 PM, Julien Grall wrote:
Hi,
On 08/03/18 16:25, Andre Przywara wrote:
On 06/03/18 16:06, Julien Grall wrote:
On 05/03/18 16:03, Andre Przywara wrote:
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index 8fab458d7f..89a07ae6b4 100644
--- a/xen/include/a
>>> On 13.02.18 at 21:04, wrote:
> The two functions are only used by PV code paths because:
>
> 1. To allocate a PGT_l*_page_table type page, a DomU must explicitly
>request such types via PV MMU hypercall.
> 2. PV Dom0 builder explicitly asks for PGT_l*_page_table type pages,
>but it is
>>> On 13.02.18 at 21:04, wrote:
> The two functions are only used by PV code paths because:
>
> 1. To allocate a PGT_l*_page_table type page, a DomU must explicitly
>request such types via PV MMU hypercall.
> 2. PV Dom0 builder explicitly asks for PGT_l*_page_table type pages,
>but it is
x86/Emulated platform devices (QEMU):
- Aded PCI host bridge (as in xen.git:docs/misc/qemu-xen-security)
New: x86/Emulated Storage Image Formats
- Added raw, qcow, qcow2, vhd (as in xen.git:docs/misc/qemu-xen-security)
x86/Emulated graphics (QEMU)
- Fixed typo (stdvga)
- Added xenfb (as in xen.git:
From: Ross Lagerwall
Saving the current state to xenstore may fail when running restricted
(in particular, after a migration). Therefore, don't report the error or
exit when running restricted. Toolstacks that want to allow running
QEMU restricted should instead make use of QMP events to listen
This series provides necessary support for running qemu as a Xen
device model without power equivalent to root. In particular, it
makes -xen-domid-restrict effective.
I have taken into account all the comments from v5 (from October!) and
there are also two new patches from Ross Lagerwall.
m a
And insist that it works.
Drop individual use of xendevicemodel_restrict and
xenforeignmemory_restrict. These are not actually effective in this
version of qemu, because qemu has a large number of fds open onto
various Xen control devices.
The restriction arrangements are still not right, becaus
From: Ross Lagerwall
Xen unstable (to be in 4.11) has two new dmops, relocate_memory and
pin_memory_cacheattr. Use these to set up the VGA memory, replacing the
previous calls to libxc. This allows the VGA console to work properly
when QEMU is running restricted (-xen-domid-restrict).
Wrapper fu
From: Anthony PERARD
Xen libraries in 4.10 include a new xentoolcore library. This
contains the xentoolcore_restrict_all function which we are about to
want to use.
Signed-off-by: Ian Jackson
Acked-by: Stefano Stabellini
---
v5: More truthful commit message.
---
configure | 8 +---
1 fil
If you pass scripts/get_maintainer.pl the name of a FIFO or other
exciting object (/dev/stdin, for example), it would falsely print
"file not found". Instead: stat the object rather than using -f so
that we do not mind if the object is not a file; and print the errno
value in the error message.
S
We need to restrict *all* the control fds that qemu opens. Looking in
/proc/PID/fd shows there are many; their allocation seems scattered
throughout Xen support code in qemu.
We must postpone the restrict call until roughly the same time as qemu
changes its uid, chroots (if applicable), and so on
This allows the caller to specify a uid and gid to use, even if there
is no corresponding password entry. This will be useful in certain
Xen configurations.
We don't support just -runas because: (i) deprivileging without
calling setgroups would be ineffective (ii) given only a uid we don't
know
We are going to want to reuse this.
No functional change.
Signed-off-by: Ian Jackson
Reviewed-by: Anthony PERARD
Acked-by: Stefano Stabellini
---
hw/i386/xen/xen-hvm.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c
index
This makes it much easier to find a particular thing in config.log.
The information may be lacking in other shells, resulting in harmless
empty output. (This is why we don't use the proper ${FUNCNAME[*]}
array syntax - other shells will choke on that.)
The extra output is only printed if configu
We are going to want to use the dummy xendevicemodel_handle type in
new stub functions in the CONFIG_XEN_CTRL_INTERFACE_VERSION < 41000
section. So we need to provide that definition, or (as applicable)
include the appropriate header, earlier in the file.
(Ideally the newer compatibility layers w
xc_interface_open etc. is not going to work if we have dropped
privilege, but xendevicemodel_shutdown will if everything is new
enough.
xendevicemodel_shutdown is only availabe in Xen 4.10 and later, so
provide a stub for earlier versions.
Signed-off-by: Ian Jackson
Reviewed-by: Anthony PERARD
Lars Kurth writes ("[PATCH] Move missing items from docs/misc/qemu-xen-security
to SUPPORT.md"):
> x86/Emulated platform devices (QEMU):
> - Aded PCI host bridge (as in xen.git:docs/misc/qemu-xen-security)
> New: x86/Emulated Storage Image Formats
> - Added raw, qcow, qcow2, vhd (as in xen.git:doc
For reasons I still don't quite understand, this cover letter was not
sent to the whole CC list so I am doing that by hand now.
Ian Jackson writes ("[PATCH v6 00/11] xen: xen-domid-restrict improvements"):
> This series provides necessary support for running qemu as a Xen
> device model without po
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 1520530757-4477-1-git-send-email-ian.jack...@eu.citrix.com
Subject: [Qemu-devel] [PATCH v6 00/11] xen: xen-domid-restrict improvements
=== TEST SCRIPT BEGIN ===
#!/bin/bash
no-re...@patchew.org writes ("Re: [Qemu-devel] [PATCH v6 00/11] xen:
xen-domid-restrict improvements"):
> This series seems to have some coding style problems. See output below for
> more information:
Obviously I should have run checkpatch myself. I will send a v6.1.
Ian.
_
On 08/03/2018, 18:44, "Ian Jackson" wrote:
Lars Kurth writes ("[PATCH] Move missing items from
docs/misc/qemu-xen-security to SUPPORT.md"):
> x86/Emulated platform devices (QEMU):
> - Aded PCI host bridge (as in xen.git:docs/misc/qemu-xen-security)
> New: x86/Emulated Storage I
Hi,
This series failed build test on s390x host. Please find the details below.
Type: series
Message-id: 1520530757-4477-1-git-send-email-ian.jack...@eu.citrix.com
Subject: [Qemu-devel] [PATCH v6 00/11] xen: xen-domid-restrict improvements
=== TEST SCRIPT BEGIN ===
#!/bin/bash
# Testing script w
On Thu, Mar 8, 2018 at 6:12 AM, Andrew Cooper wrote:
>
> Travis reports:
>
> sched_rt.c:241:30: error: unused function 'rt_dom'
> [-Werror,-Wunused-function]
> static inline struct rt_dom *rt_dom(const struct domain *dom)
>^
> 1 error generated.
>
> when comp
This avoids checkpatch misparsing (as statements) long function
definitions or declarations, which sometimes start with constructs
like this:
static inline int xendevicemodel_relocate_memory(
xendevicemodel_handle *dmod, domid_t domid, ...
CC: Eric Blake
CC: Paolo Bonzini
CC: Daniel P.
And insist that it works.
Drop individual use of xendevicemodel_restrict and
xenforeignmemory_restrict. These are not actually effective in this
version of qemu, because qemu has a large number of fds open onto
various Xen control devices.
The restriction arrangements are still not right, becaus
From: Anthony PERARD
Xen libraries in 4.10 include a new xentoolcore library. This
contains the xentoolcore_restrict_all function which we are about to
want to use.
Signed-off-by: Ian Jackson
Acked-by: Stefano Stabellini
---
v5: More truthful commit message.
---
configure | 8 +---
1 fil
We are going to want to reuse this.
No functional change.
Signed-off-by: Ian Jackson
Reviewed-by: Anthony PERARD
Acked-by: Stefano Stabellini
---
hw/i386/xen/xen-hvm.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c
index
We need to restrict *all* the control fds that qemu opens. Looking in
/proc/PID/fd shows there are many; their allocation seems scattered
throughout Xen support code in qemu.
We must postpone the restrict call until roughly the same time as qemu
changes its uid, chroots (if applicable), and so on
We are going to want to use the dummy xendevicemodel_handle type in
new stub functions in the CONFIG_XEN_CTRL_INTERFACE_VERSION < 41000
section. So we need to provide that definition, or (as applicable)
include the appropriate header, earlier in the file.
(Ideally the newer compatibility layers w
From: Ross Lagerwall
Saving the current state to xenstore may fail when running restricted
(in particular, after a migration). Therefore, don't report the error or
exit when running restricted. Toolstacks that want to allow running
QEMU restricted should instead make use of QMP events to listen
1 - 100 of 119 matches
Mail list logo
