flight 131060 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131060/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 7 xen-boot fail REGR. vs.
130908
test-amd64-amd64
Add the hooks to current code needed for Xen PVH. They will be filled
with code later when the related functionality is being added.
loader/i386/linux.c needs to include machine/kernel.h now as it needs
to get GRUB_KERNEL_USE_RSDP_ADDR from there. This in turn requires to
add an empty kernel.h hea
On 06/12/2018 23:11, Paolo Bonzini wrote:
> On 06/12/18 07:04, Maran Wilson wrote:
>> +config PVH
>> +bool "Support for running PVH guests"
>> +---help---
>> + This option enables the PVH entry point for guest virtual machines
>> + as specified in the x86/HVM direct boot ABI.
>> +
flight 131061 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131061/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stopfail REGR. vs. 129676
Tests which di
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-qemuu-debianhvm-amd64
testid xen-boot
Tree: linux
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-
The xenstore 'ring-page-order' is used globally for each blkback queue and
therefore should be read from xenstore only once. However, it is obtained
in read_per_ring_refs() which might be called multiple times during the
initialization of each blkback queue.
If the blkfront is malicious and the 'r
On Tue, 4 Dec 2018, Julien Grall wrote:
> A follow-up patch will add support for preemption in p2m_cache_flush_range.
> Because of the complexity for the 2 loops, it would be necessary to add
> preemption in both of them.
>
> This can be avoided by merging the 2 loops together and still keeping
>
On 06/12/2018 23:30, Paolo Bonzini wrote:
> On 07/12/18 00:11, Boris Ostrovsky wrote:
>> On 12/6/18 5:49 PM, Paolo Bonzini wrote:
>>> On 06/12/18 23:34, Boris Ostrovsky wrote:
On 12/6/18 5:11 PM, Paolo Bonzini wrote:
> and also
>
> depends on !EFI
>
> because even th
On Tue, 4 Dec 2018, Julien Grall wrote:
> Set/Way operations are used to perform maintenance on a given cache.
> At the moment, Set/Way operations are not trapped and therefore a guest
> OS will directly act on the local cache. However, a vCPU may migrate to
> another pCPU in the middle of the proc
On Tue, 4 Dec 2018, Julien Grall wrote:
> p2m_cache_flush_range does not yet support preemption, this may be an
> issue as cleaning the cache can take a long time. While the current
> caller (XEN_DOMCTL_cacheflush) does not stricly require preemption, this
> will be necessary for new caller in a fo
On 07/12/18 00:11, Boris Ostrovsky wrote:
> On 12/6/18 5:49 PM, Paolo Bonzini wrote:
>> On 06/12/18 23:34, Boris Ostrovsky wrote:
>>> On 12/6/18 5:11 PM, Paolo Bonzini wrote:
>>>
and also
depends on !EFI
because even though in principle it would be possible to write a PV
On Tue, 4 Dec 2018, Julien Grall wrote:
> This will make changes in a follow-up patch easier.
>
> Signed-off-by: Julien Grall
Acked-by: Stefano Stabellini
> ---
> Changes in v2:
> - Patch added
> ---
> xen/arch/arm/domctl.c | 8
> 1 file changed, 4 insertions(+), 4 deleti
On 12/6/18 5:49 PM, Paolo Bonzini wrote:
> On 06/12/18 23:34, Boris Ostrovsky wrote:
>> On 12/6/18 5:11 PM, Paolo Bonzini wrote:
>>
>>> and also
>>>
>>> depends on !EFI
>>>
>>> because even though in principle it would be possible to write a PVH
>>> loader for UEFI, PVH's start info does not su
On Tue, 4 Dec 2018, Julien Grall wrote:
> The function leave_hypervisor_tail is called before each return to the
> guest vCPU. It has two main purposes:
> 1) Process physical CPU work (e.g rescheduling) if required
> 2) Prepare the physical CPU to run the guest vCPU
>
> 2) will always be d
On 06/12/18 23:34, Boris Ostrovsky wrote:
> On 12/6/18 5:11 PM, Paolo Bonzini wrote:
>> On 06/12/18 07:04, Maran Wilson wrote:
>>> +config PVH
>>> + bool "Support for running PVH guests"
>>> + ---help---
>>> + This option enables the PVH entry point for guest virtual machines
>>> + as s
On 12/6/18 5:11 PM, Paolo Bonzini wrote:
> On 06/12/18 07:04, Maran Wilson wrote:
>> +config PVH
>> +bool "Support for running PVH guests"
>> +---help---
>> + This option enables the PVH entry point for guest virtual machines
>> + as specified in the x86/HVM direct boot ABI.
>> +
On Tue, 4 Dec 2018, Julien Grall wrote:
> A follow-up patch will require to emulate some accesses to some
> co-processors registers trapped by HCR_EL2.TVM. When set, all NS EL1 writes
> to the virtual memory control registers will be trapped to the hypervisor.
>
> This patch adds the infrastructur
On Tue, 4 Dec 2018, Julien Grall wrote:
> Currently a Stage-2 translation fault could happen:
> 1) MMIO emulation
> 2) Another pCPU was modifying the P2M using Break-Before-Make
> 3) Guest Physical address is not mapped
>
> A follow-up patch will re-purpose the valid bit in an entry to
On Tue, 4 Dec 2018, Razvan Cojocaru wrote:
> On 12/4/18 10:26 PM, Julien Grall wrote:
> > With the recent changes, a P2M entry may be populated but may as not
> > valid. In some situation, it would be useful to know whether the entry
>
> I think you mean to say "may not be valid"?
>
> > has been
On 06/12/18 22:58, Boris Ostrovsky wrote:
> On 12/6/18 4:37 PM, Borislav Petkov wrote:
>> On Thu, Dec 06, 2018 at 10:21:12PM +0100, Paolo Bonzini wrote:
>>> Thanks! I should be able to post a Tested-by next Monday. Boris, are
>>> you going to pick it up for 4.21?
>> Boris me or Boris O.?
>>
>> :-
flight 131035 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131035/
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. 128858
test-amd64-i386-xl-q
On 06/12/18 07:04, Maran Wilson wrote:
> +config PVH
> + bool "Support for running PVH guests"
> + ---help---
> + This option enables the PVH entry point for guest virtual machines
> + as specified in the x86/HVM direct boot ABI.
> +
IIUC this breaks "normal" bzImage boot, so w
On 06/12/18 07:06, Maran Wilson wrote:
> +config KVM_GUEST_PVH
> + bool "Support for running as a KVM PVH guest"
> + depends on KVM_GUEST
> + select PVH
> + ---help---
> + This option enables starting KVM guests via the PVH entry point as
> + specified in the x86/HVM dir
On Wed, 5 Dec 2018, Julien Grall wrote:
> On 04/12/2018 23:59, Stefano Stabellini wrote:
> > On Tue, 4 Dec 2018, Julien Grall wrote:
> > > A follow-up patch will re-purpose the valid bit of LPAE entries to
> > > generate fault even on entry containing valid information.
> > >
> > > This means that
On Wed, 5 Dec 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 04/12/2018 23:50, Stefano Stabellini wrote:
> > On Tue, 4 Dec 2018, Julien Grall wrote:
> > > The LPAE format allows to store information in an entry even with the
> > > valid bit unset. In a follow-up patch, we will take advantage of th
On 12/6/18 4:37 PM, Borislav Petkov wrote:
> On Thu, Dec 06, 2018 at 10:21:12PM +0100, Paolo Bonzini wrote:
>> Thanks! I should be able to post a Tested-by next Monday. Boris, are
>> you going to pick it up for 4.21?
> Boris me or Boris O.?
>
> :-)
>
O. ;-)
There are some minor changes in non-x
On Thu, Dec 06, 2018 at 10:21:12PM +0100, Paolo Bonzini wrote:
> Thanks! I should be able to post a Tested-by next Monday. Boris, are
> you going to pick it up for 4.21?
Boris me or Boris O.?
:-)
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the repl
On 06/12/18 07:02, Maran Wilson wrote:
> For certain applications it is desirable to rapidly boot a KVM virtual
> machine. In cases where legacy hardware and software support within the
> guest is not needed, Qemu should be able to boot directly into the
> uncompressed Linux kernel binary without t
On Thu, 2018-12-06 at 10:49 -0800, Andy Lutomirski wrote:
> > On Dec 6, 2018, at 9:36 AM, Andrew Cooper wrote:
> > Basically - what is happening is that xen_load_tls() is invalidating the
> > %gs selector while %gs is still non-NUL.
> >
> > If this happens to intersect with a vcpu reschedule, %gs
On Wed, Dec 05, 2018 at 01:41:30AM -0700, Jan Beulich wrote:
> >>> On 04.12.18 at 22:35, wrote:
> > The other thing I don't get is why advertise virtualized SSBD when the
> > guest setting it does nothing? If ssbd_opt=true is set, as the code is
> > now, why even advertise it to the guest? I'd s
On Thu, Dec 06, 2018 at 06:46:51PM +, Andy Cooper wrote:
> On 06/12/2018 08:54, Jan Beulich wrote:
> On 05.12.18 at 18:05, wrote:
> >> On 05/12/2018 16:57, Jan Beulich wrote:
> >> On 03.12.18 at 17:18, wrote:
> --- a/xen/arch/x86/cpu/amd.c
> +++ b/xen/arch/x86/cpu/amd.c
> >
flight 131054 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131054/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 129475
build-i386
* Add "uint64_t raw" to seg_desc_t to remove the opencoded uint64_t casting
in this function.
* Rename the 'pa' parameter to 'gaddr', because it lives in GFN space rather
than physical address space.
* Use gfn_t and mfn_t rather than unsigned longs.
* Check the alignment and proposed new
On 06/12/2018 10:51, Jan Beulich wrote:
>
>> +unsigned int socket = c->phys_proc_id, core = c->cpu_core_id;
>> +struct ssbd_ls_cfg *cfg;
>> +uint64_t val;
>> +
>> +ASSERT(cpu_has_legacy_ssbd);
>> +
>> +/*
>> + * Update hardware lazily, as these MSRs are expensive. However,
> On Dec 6, 2018, at 9:36 AM, Andrew Cooper wrote:
>
>> On 06/12/2018 17:10, David Woodhouse wrote:
>> On Wed, 2018-11-28 at 08:44 -0800, Andy Lutomirski wrote:
Can we assume it's always from kernel? The Xen code definitely seems to
handle invoking this from both kernel and userspace con
On 06/12/2018 08:54, Jan Beulich wrote:
On 05.12.18 at 18:05, wrote:
>> On 05/12/2018 16:57, Jan Beulich wrote:
>> On 03.12.18 at 17:18, wrote:
--- a/xen/arch/x86/cpu/amd.c
+++ b/xen/arch/x86/cpu/amd.c
@@ -419,6 +419,97 @@ static void __init noinline
amd_probe_legacy
Convert to use vm_insert_range() to map range of kernel
memory to user vma.
Signed-off-by: Souptick Joarder
Reviewed-by: Matthew Wilcox
Reviewed-by: Boris Ostrovsky
---
drivers/xen/privcmd-buf.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/xen/privcmd-buf
Convert to use vm_insert_range() to map range of kernel
memory to user vma.
Signed-off-by: Souptick Joarder
Reviewed-by: Matthew Wilcox
Reviewed-by: Boris Ostrovsky
---
drivers/xen/gntdev.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/xen/gntdev.c b/d
Convert to use vm_insert_range() to map range of kernel
memory to user vma.
Signed-off-by: Souptick Joarder
Reviewed-by: Matthew Wilcox
Reviewed-by: Oleksandr Andrushchenko
---
drivers/gpu/drm/xen/xen_drm_front_gem.c | 20 ++--
1 file changed, 6 insertions(+), 14 deletions(-)
On 06/12/2018 08:49, Jan Beulich wrote:
+{"amd_stibp",0x8008, NA, CPUID_REG_EBX, 15, 1},
+{"amd_ssbd", 0x8008, NA, CPUID_REG_EBX, 24, 1},
+{"virt_sc_ssbd", 0x8008, NA, CPUID_REG_EBX, 25, 1},
+{"amd_ssb_no", 0x8008, NA,
Previouly drivers have their own way of mapping range of
kernel pages/memory into user vma and this was done by
invoking vm_insert_page() within a loop.
As this pattern is common across different drivers, it can
be generalized by creating a new function and use it across
the drivers.
vm_insert_ra
Previouly drivers have their own way of mapping range of
kernel pages/memory into user vma and this was done by
invoking vm_insert_page() within a loop.
As this pattern is common across different drivers, it can
be generalized by creating a new function and use it across
the drivers.
vm_insert_ra
The struct suffix is redundant in the name, and a future change will want to
turn it into a union, rather than a structure. As this represents a segment
descriptor, give it an appropriate typedef.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau
Andrew Cooper (2):
x86: Switch "struct desc_struct" to being seg_desc_t
x86/pv: Code improvements to do_update_descriptor()
xen/arch/x86/cpu/common.c | 4 ++--
xen/arch/x86/domain.c | 2 +-
xen/arch/x86/hvm/hvm.c | 4 ++--
xen/arch/x86/hvm/svm/svm.c
flight 131008 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131008/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail
REGR. vs. 125898
tes
On 06/12/2018 17:10, David Woodhouse wrote:
> On Wed, 2018-11-28 at 08:44 -0800, Andy Lutomirski wrote:
>>> Can we assume it's always from kernel? The Xen code definitely seems to
>>> handle invoking this from both kernel and userspace contexts.
>> I learned that my comment here was wrong shortly a
On Wed, 2018-11-28 at 08:44 -0800, Andy Lutomirski wrote:
> > Can we assume it's always from kernel? The Xen code definitely seems to
> > handle invoking this from both kernel and userspace contexts.
>
> I learned that my comment here was wrong shortly after the patch landed :(
Turns out the only
On Thu, Dec 06, 2018 at 04:09:14PM +, Anthony PERARD wrote:
> On Thu, Dec 06, 2018 at 03:46:22PM +, Wei Liu wrote:
> > Anyway, I'm not overly opposed to adding some easy to grep pointers, but
> > CODING_STYLE looks wrong to me. Maybe README.dev?
>
> To me, CODING_STYLE in libxl looks like
On Thu, Dec 06, 2018 at 03:46:22PM +, Wei Liu wrote:
> Anyway, I'm not overly opposed to adding some easy to grep pointers, but
> CODING_STYLE looks wrong to me. Maybe README.dev?
To me, CODING_STYLE in libxl looks like a combination of both
CODING_STYLE and HACKING that exist in qemu.git.
M
flight 131024 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131024/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install
fail REGR. vs. 129996
> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: 06 December 2018 15:24
> To: Paul Durrant
> Cc: qemu-bl...@nongnu.org; qemu-de...@nongnu.org; xen-
> de...@lists.xenproject.org; Stefano Stabellini
> Subject: Re: [PATCH 15/18] xen: add a mechanism to a
On Thu, Dec 06, 2018 at 02:57:33PM +, Anthony PERARD wrote:
> On Thu, Dec 06, 2018 at 12:16:40PM +, Wei Liu wrote:
> > On Thu, Dec 06, 2018 at 10:43:32AM +, Anthony PERARD wrote:
> > > +UPDATE OF DOMAIN CONFIGURATION
> > > +--
> > > +
> > > +Also known as "li
On 12/06/2018 10:40 AM, Daniel Kiper wrote:
> On Thu, Dec 06, 2018 at 10:37:43AM -0500, Ross Philipson wrote:
>> On 12/06/2018 08:40 AM, Daniel Kiper wrote:
>>> Xen fallout cleanup after commit ca0a4f689 (verifiers: File type for
>>> fine-grained signature-verification controlling).
>>>
>>> Signed-
On Thu, Dec 06, 2018 at 10:37:43AM -0500, Ross Philipson wrote:
> On 12/06/2018 08:40 AM, Daniel Kiper wrote:
> > Xen fallout cleanup after commit ca0a4f689 (verifiers: File type for
> > fine-grained signature-verification controlling).
> >
> > Signed-off-by: Daniel Kiper
> > ---
> > grub-core/lo
On 12/06/2018 08:40 AM, Daniel Kiper wrote:
> ARM Xen fallout cleanup after commit ca0a4f689 (verifiers: File type for
> fine-grained signature-verification controlling).
>
> Signed-off-by: Daniel Kiper
> ---
> grub-core/loader/arm64/xen_boot.c | 8
> include/grub/file.h |
On 12/06/2018 08:40 AM, Daniel Kiper wrote:
> Xen fallout cleanup after commit ca0a4f689 (verifiers: File type for
> fine-grained signature-verification controlling).
>
> Signed-off-by: Daniel Kiper
> ---
> grub-core/loader/i386/xen.c | 14 +++---
> 1 file changed, 7 insertions(+), 7 del
flight 131012 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131012/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install
fail REGR. vs. 130373
test
This patch removes any implicit flushing that occurs in the implementation
of map and unmap operations and adds new iommu_map/unmap() wrapper
functions. To maintain sematics of the iommu_legacy_map/unmap() wrapper
functions, these are modified to call the new wrapper functions and then
perform an e
A subsequent patch will add semantically different versions of
iommu_map/unmap() so, in advance of that change, this patch renames the
existing functions to iommu_legacy_map/unmap() and modifies all call-sites.
It also adjusts a comment that refers to iommu_map_page(), which was re-
named by a prev
Now that the iommu_map() and iommu_unmap() operations take an order
parameter and elide flushing there's no strong reason why modifying MMIO
ranges in the p2m should be restricted to a 4k granularity simply because
the IOMMU is enabled but shared page tables are not in operation.
Signed-off-by: Pa
The iommu_ops structure contains two methods for flushing: 'iotlb_flush' and
'iotlb_flush_all'. This patch adds implementations of these for AMD IOMMUs.
The iotlb_flush method takes a base DFN and a (4k) page count, but the
flush needs to be done by page order (i.e. 0, 9 or 18). Because a flush
op
Paul Durrant (4):
amd-iommu: add flush iommu_ops
iommu: rename wrapper functions
iommu: elide flushing for higher order map/unmap operations
x86/mm/p2m: stop checking for IOMMU shared page tables in mmio_order()
xen/arch/arm/p2m.c| 11 ++-
xen/arch/x86/mm.c
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 06 December 2018 15:08
> To: Paul Durrant
> Cc: Brian Woods ; Suravee Suthikulpanit
> ; Julien Grall ;
> Andrew Cooper ; Roger Pau Monne
> ; Wei Liu ; George Dunlap
> ; Ian Jackson ; Kevin
> Tian ; Stefano Stabelli
This is a purely cosmetic patch that purges remaining use of 'blk' and
'ioreq' in local function names, and then makes sure all functions are
prefixed with 'xen_block_'.
No functional change.
Signed-off-by: Paul Durrant
---
Cc: Stefano Stabellini
Cc: Anthony Perard
Cc: Stefan Hajnoczi
Cc: Kev
This patch adds the transformations necessary to get dataplane/xen-block.c
to build against the new XenBus/XenDevice framework. MAINTAINERS is also
updated due to the introduction of dataplane/xen-block.h.
NOTE: Existing data structure names are retained for the moment. These will
be modifie
This patch adds a creator function for XenBlockDevice-s so that they can
be created automatically when the Xen toolstack instantiates a new
PV backend. When the XenBlockDevice is created this way it is also
necessary to create a drive which matches the configuration that the Xen
toolstack has writt
I have made many significant contributions to the Xen code in QEMU,
particularly the recent patches introducing a new PV device framework.
I intend to make further significant contributions, porting other PV back-
ends to the new framework with the intent of eventually removing the
legacy code. It
This backend has now been replaced by the 'xen-qdisk' XenDevice.
Signed-off-by: Paul Durrant
---
Cc: Kevin Wolf
Cc: Max Reitz
Cc: Anthony Perard
Cc: Stefano Stabellini
---
hw/block/Makefile.objs |1 -
hw/block/xen_disk.c| 1011
2 files
This is a purely cosmetic patch that substitutes the old 'struct XenBlkDev'
name with 'XenBlockDataPlane' and 'blkdev' field/variable names with
'dataplane', and then does necessary fix-up to adhere to coding style.
No functional change.
Signed-off-by: Paul Durrant
Acked-by: Anthony Perard
---
...that maintains compatibility with existing Xen toolstacks.
Xen toolstacks instantiate PV backends by simply writing information into
xenstore and expecting a backend implementation to be watching for this.
This patch adds a new 'xen-backend' module to allow individual XenDevice
implementations
...and wire in the dataplane.
This patch adds the remaining code to make the xen-block XenDevice
functional. The parameters that a block frontend expects to find are
populated in the backend xenstore area, and the 'ring-ref' and
'event-channel' values specified in the frontend xenstore area are
ma
This is a purely cosmetic patch that purges the name 'ioreq' from struct,
variable and field names. (This name has been problematic for a long time
as 'ioreq' is the name used for generic I/O requests coming from Xen).
The patch replaces 'struct ioreq' with a new 'XenBlockRequest' type and
'ioreq'
On Wed, Nov 28, 2018 at 02:55:19PM +0100, Juergen Gross wrote:
> Add the hooks to current code needed for Xen PVH. They will be filled
> with code later when the related functionality is being added.
>
> loader/i386/linux.c needs to include machine/kernel.h now as it needs
> to get GRUB_KERNEL_USE_
On Thu, Dec 06, 2018 at 12:36:52PM +, Paul Durrant wrote:
> > -Original Message-
> > From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> > Sent: 04 December 2018 15:35
> >
> > On Wed, Nov 21, 2018 at 03:12:08PM +, Paul Durrant wrote:
> > > +xenbus->backend_watch =
> > > +
A Xen PV frontend communicates its state to the PV backend by writing to
the 'state' key in the frontend area in xenstore. It is therefore
necessary for a XenDevice implementation to be notified whenever the
value of this key changes.
This patch adds code to do this as follows:
- an 'fd handler'
This patch adds the basic boilerplate for a 'XenBus' object that will act
as a parent to 'XenDevice' PV backends.
A new 'XenBridge' object is also added to connect XenBus to the system bus.
The XenBus object is instantiated by a new xen_bus_init() function called
from the same sites as the legacy
...and xen_backend.h to xen-legacy-backend.h
Rather than attempting to convert the existing backend infrastructure to
be QOM compliant (which would be hard to do in an incremental fashion),
subsequent patches will introduce a completely new framework for Xen PV
backends. Hence it is necessary to r
The new xen-block XenDevice implementation requires the same core
dataplane as the legacy xen_disk implementation it will eventually replace.
This patch therefore copies the legacy xen_disk.c source module into a new
dataplane/xen-block.c source module as the basis for the new dataplane and
adjusts
This series introduces a new QOM compliant framework for Xen PV backends.
This is achieved by first moving the current non-compliant framework aside,
before building up a new framework incrementally.
This series was prompted by a thread [1] started by Kevin Wolf in response
to patches against xen_
This patch adds new XenDevice-s: 'xen-disk' and 'xen-cdrom', both derived
from a common 'xen-block' parent type. These will eventually replace the
'xen_disk' (note the underscore rather than hyphen) legacy PV backend but
it is illustrative to build up the implementation incrementally, along with
th
The legacy PV backend infrastructure provides functions to map, unmap and
copy pages granted by frontends. Similar functionality will be required
by XenDevice implementations so this patch adds the necessary support.
Signed-off-by: Paul Durrant
Reviewed-by: Anthony Perard
---
Cc: Stefano Stabell
This patch adds a new source module, xen-bus-helper.c, which builds on
basic libxenstore primitives to provide functions to create (setting
permissions appropriately) and destroy xenstore areas, and functions to
'printf' and 'scanf' nodes therein. The main xen-bus code then uses
these primitives [1
Not all of the code duplicated from xen_disk.c is required as the basis for
the new dataplane implementation so this patch removes extraneous code,
along with the legacy #includes and calls to the legacy xen_pv_printf()
function. Error messages are changed to be reported using error_report().
NOTE
The legacy PV backend infrastructure provides functions to bind, unbind
and send notifications to event channnels. Similar functionality will be
required by XenDevice implementations so this patch adds the necessary
support.
Signed-off-by: Paul Durrant
---
Cc: Stefano Stabellini
Cc: Anthony Pera
>>> On 05.12.18 at 12:29, wrote:
> --- a/xen/common/memory.c
> +++ b/xen/common/memory.c
> @@ -865,11 +865,15 @@ int xenmem_add_to_physmap(struct domain *d, struct
> xen_add_to_physmap *xatp,
>
> this_cpu(iommu_dont_flush_iotlb) = 0;
>
> -ret = iommu_flush(d, _dfn(xatp->idx -
On 06/12/2018 14:44, Jan Beulich wrote:
On 05.12.18 at 12:29, wrote:
>> A subsequent patch will add semantically different versions of
>> iommu_map/unmap() so, in advance of that change, this patch renames the
>> existing functions to iommu_legacy_map/unmap() and modifies all call-sites.
>> I
Signed-off-by: George Dunlap
---
CC: Ian Jackson
CC: Wei Liu
---
docs/designs/qemu-deprivilege.md | 40
1 file changed, 20 insertions(+), 20 deletions(-)
diff --git a/docs/designs/qemu-deprivilege.md b/docs/designs/qemu-deprivilege.md
index f7444a434d..81a5f5c0
The privcmd fd that a dm_restrict'ed QEMU has gives it permission to
one specific domain ID. This domain ID will probably eventually be
used again. It is therefore necessary to make absolutely sure that a
rogue QEMU process cannot hang around after its domain has exited.
Killing QEMU by pid is i
Using kill(-1) to killing an untrusted dm process with the real uid
equal to the dm_uid isn't guaranteed to succeed: the process in
question may be able to kill the reaper process after the setresuid()
and before the kill().
Instead, set the real uid to the QEMU user for domain 0
(QEMU_USER_RANGE_
Bring conventions more in line with libxl__xs_read_checked():
- If found, return 0 and set pointer to non-NULL
- If not found, return 0 and set pointer to NULL
- On error, return libxl-style error number.
Update documentation to match.
Use CODING_STYLE compliant `r` rather than `ret`.
On error,
QEMU_USER_BASE allows a user to specify the UID to use when running
the devicemodel for a specific domain number. Unfortunately, this is
not really practical: It requires nearly 32,000 entries in
/etc/passwd. QEMU_USER_RANGE_BASE is much more practical.
Remove support for QEMU_USER_BASE.
Signed
At the moment, we check for equivalence to literal "root" before
deciding whether to add the `runas` command-line option to QEMU. This
is unsatisfactory for several reasons.
First, just because the string doesn't match "root" doesn't mean the
final uid won't end up being zero; in particular, the
A number of subsequent patches rely on as-yet undefined behavior for
what the `device_model_user` parameter does. Rather than implement it
incorrectly (or randomly), or remove the feature, describe an expected
usage for the feature. Further patches will make decisions based on
this expected usage
Or at least, give it an asynchronous interface so that we can make it
actually asynchronous in subsequent patches.
Create state structures and callback function signatures. Add the
state structure to libxl__destroy_domid_state. Break
libxl__destroy_domid down into two functions.
No functional c
Removing the qmp connection is logically part of the device model
destruction; having the caller destroy it is a mild layering
violation.
Move libxl__qmp_cleanup() into libxl__destroy_device_model(). This
will make it easier when we make devicemodel destruction asynchronous.
Signed-off-by: Georg
To reliably kill an untrusted devicemodel, we need to know not only
its pid, but its uid. In preparation for this, move the userid
determination logic into a helper function.
Create a new field, `dm_runas`, in libxl__domain_build_state to store
the value during domain creation.
This change also
I've pulled this into the dma-mapping for-next tree, with the suggestion
from Robin that improves bisectability, and two unused variables found
by the build bot.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailm
On Thu, Dec 06, 2018 at 12:16:40PM +, Wei Liu wrote:
> On Thu, Dec 06, 2018 at 10:43:32AM +, Anthony PERARD wrote:
> > +UPDATE OF DOMAIN CONFIGURATION
> > +--
> > +
> > +Also known as "libxl-json" userdata or `libxl_domain_config'.
> > +
> > +Whenever a running d
>>> On 05.12.18 at 12:29, wrote:
> A subsequent patch will add semantically different versions of
> iommu_map/unmap() so, in advance of that change, this patch renames the
> existing functions to iommu_legacy_map/unmap() and modifies all call-sites.
> It also adjusts a comment that refers to iommu
flight 131076 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131076/
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
1 - 100 of 188 matches
Mail list logo
