>>> On 14.12.17 at 18:41, wrote:
> Certain memory resources associated with a guest are not necessarily
> present in the guest P2M.
>
> This patch adds the boilerplate for new memory op to allow such a resource
> to be priv-mapped directly, by either a PV or HVM tools domain.
>
> NOTE: Whilst th
> -Original Message-
> From: Chao Gao [mailto:chao@intel.com]
> Sent: 15 December 2017 00:50
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Stefano Stabellini
> ; George Dunlap ;
> Andrew Cooper ; Ian Jackson
> ; Tim (Xen.org)
> Subject: Re: [Xen-devel] [PATCH v15 04/11] x86
flight 117175 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117175/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-xsm broken
Tests which di
On Wed, Dec 13, 2017 at 03:01:51PM +, Anthony PERARD wrote:
> On Tue, Dec 12, 2017 at 02:10:44PM +, Daniel P. Berrange wrote:
> > Replace the scancode2linux table with an automatically
> > generated table. In doing so, the XenFB keyboard
> > handler is also converted to the modern InputEven
> -Original Message-
> From: Chao Gao [mailto:chao@intel.com]
> Sent: 15 December 2017 00:36
> To: Paul Durrant
> Cc: Stefano Stabellini ; Wei Liu
> ; Andrew Cooper ; Tim
> (Xen.org) ; George Dunlap ;
> xen-de...@lists.xen.org; Jan Beulich ; Ian Jackson
>
> Subject: Re: [RFC Patch v4
>>> On 20.10.17 at 10:28, wrote:
> --- a/xen/arch/x86/sysctl.c
> +++ b/xen/arch/x86/sysctl.c
> @@ -174,7 +174,7 @@ long arch_do_sysctl(
> case XEN_SYSCTL_psr_alloc:
> switch ( sysctl->u.psr_alloc.cmd )
> {
> -uint32_t data[PSR_INFO_ARRAY_SIZE];
> +uin
flight 117133 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117133/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 116965
test-armhf-armhf-libvirt 14 saveresto
...to allow the calling domain to prevent translation of specified l1e
value.
Despite what the comment in public/xen.h might imply, specifying a
command value of MMU_NORMAL_PT_UPDATE will not simply update an l1e with
the specified value. Instead, mod_l1_entry() tests whether foreign_dom
has PG_tr
This patch re-works much of the ioreq server initialization and teardown
code:
- The hvm_map/unmap_ioreq_gfn() functions are expanded to call through
to hvm_alloc/free_ioreq_gfn() rather than expecting them to be called
separately by outer functions.
- Several functions now test the validity o
This patch adjusts the ioreq server code to use type-safe gfn_t values
where possible. No functional change.
Signed-off-by: Paul Durrant
Reviewed-by: Roger Pau Monné
Reviewed-by: Wei Liu
Acked-by: Jan Beulich
---
Cc: Andrew Cooper
---
xen/arch/x86/hvm/ioreq.c | 44 +++
A subsequent patch will introduce a new scheme to allow an emulator to
map ioreq server pages directly from Xen rather than the guest P2M.
This patch lays the groundwork for that change by deferring mapping of
gfns until their values are requested by an emulator. To that end, the
pad field of the
A subsequent patch will remove the current implicit limitation on creation
of ioreq servers which is due to the allocation of gfns for the ioreq
structures and buffered ioreq ring.
It will therefore be necessary to introduce an explicit limit and, since
this limit should be small, it simplifies th
Certain memory resources associated with a guest are not necessarily
present in the guest P2M.
This patch adds the boilerplate for new memory op to allow such a resource
to be priv-mapped directly, by either a PV or HVM tools domain.
NOTE: Whilst the new op is not intrinsicly specific to the x86
This series introduces support for direct mapping of guest resources.
The resources are:
- IOREQ server pages
- Grant tables
v16:
- Fix default ioreq server code and verified with qemu trad
v15:
- Correct page ownership of ioreq pages
v14:
- Responded to more comments from Jan.
v13:
- Res
... XENMEM_resource_ioreq_server
This patch adds support for a new resource type that can be mapped using
the XENMEM_acquire_resource memory op.
If an emulator makes use of this resource type then, instead of mapping
gfns, the IOREQ server will allocate pages from the heap. These pages
will never
By using a static inline stub in private.h for OS where this functionality
is not implemented, the various duplicate stubs in the OS-specific source
modules can be avoided.
Signed-off-by: Paul Durrant
Reviewed-by: Roger Pau Monné
Acked-by: Wei Liu
---
Cc: Ian Jackson
v4:
- Removed extraneous
A previous patch introduced a new HYPERVISOR_memory_op to acquire guest
resources for direct priv-mapping.
This patch adds new functionality into libxenforeignmemory to make use
of a new privcmd ioctl [1] that uses the new memory op to make such
resources available via mmap(2).
[1]
http://xenbit
>>> On 18.10.17 at 13:40, wrote:
> So that MMCFG regions not present in the MCFG ACPI table can be added
> at run time by the hardware domain.
>
> Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xe
>>> On 18.10.17 at 13:40, wrote:
> +ret = pci_size_mem_bar(sbdf, idx, NULL, &pdev->vf_rlen[i],
> + PCI_BAR_VF |
> + (i == PCI_SRIOV_NUM_BARS - 1) ?
> + PCI_BAR_LAST : 0
This patch allows grant table frames to be mapped using the
XENMEM_acquire_resource memory op.
NOTE: This patch expands the on-stack mfn_list array in acquire_resource()
but it is still small enough to remain on-stack.
Signed-off-by: Paul Durrant
Reviewed-by: Jan Beulich
---
Cc: Andrew Co
A previous patch added support for priv-mapping guest resources directly
(rather than having to foreign-map, which requires P2M modification for
HVM guests).
This patch makes use of the new API to seed the guest grant table unless
the underlying infrastructure (i.e. privcmd) doesn't support it, in
flight 72830 distros-debian-jessie real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/72830/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvopsbroken
build-i38
On 15 December 2017 at 00:27, Stefano Stabellini wrote:
> The following changes since commit 0a0dc59d27527b78a195c2d838d28b7b49e5a639:
>
> Update version for v2.11.0 release (2017-12-13 14:31:09 +)
>
> are available in the git repository at:
>
> git://xenbits.xen.org/people/sstabellini/qem
flight 117131 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117131/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a
test-arm64-arm64-xl 1 build-check
>>> On 18.10.17 at 13:40, wrote:
> --- /dev/null
> +++ b/xen/drivers/vpci/header.c
> @@ -0,0 +1,518 @@
> +/*
> + * Generic functionality for handling accesses to the PCI header from the
> + * configuration space.
> + *
> + * Copyright (C) 2017 Citrix Systems R&D
> + *
> + * This program is free so
>>> On 18.10.17 at 13:40, wrote:
> Changes since v6:
>...
> - Prevent the guest from writing to the pending bits field, it's read
>only as defined in the spec.
I think we've been there before: Dom0 should be permitted whatever
it wants; DomU would need to be restricted (once supported, but a
On 12/12/17 23:51, Boris Ostrovsky wrote:
> Commit f5775e0b6116 ("x86/xen: discard RAM regions above the maximum
> reservation") left host memory not assigned to dom0 as available for
> memory hotplug.
>
> Unfortunately this also meant that those regions could be used by
> others. Specifically, co
flight 117178 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117178/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-xsm broken
Tests which di
flight 117134 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117134/
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
>> +
>> +hostmem_resource->start = max_addr;
>> +hostmem_resource->end = entry->addr + entry->size;
>> +for (; i < memmap.nr_entries; i++) {
>> +entry = &xen_e820_table->entries[i];
>> +if (entry->type == E820_TYPE_RAM)
> Shouldn't that be != ?
No, the idea her
On 15/12/17 15:24, Boris Ostrovsky wrote:
>
>>> +
>>> + hostmem_resource->start = max_addr;
>>> + hostmem_resource->end = entry->addr + entry->size;
>>> + for (; i < memmap.nr_entries; i++) {
>>> + entry = &xen_e820_table->entries[i];
>>> + if (entry->type == E820_TYPE_RA
On 14/12/17 14:13, Juergen Gross wrote:
> On 14/12/17 13:43, Julien Grall wrote:
>>
>>
>> On 14/12/17 11:38, Juergen Gross wrote:
>>> On 14/12/17 12:28, Julien Grall wrote:
On 14/12/17 07:56, Juergen Gross wrote:
> Hi all,
Hi Juergen,
I would recommend to CC c
On 12/15/2017 09:47 AM, Juergen Gross wrote:
> On 15/12/17 15:24, Boris Ostrovsky wrote:
+
+ hostmem_resource->start = max_addr;
+ hostmem_resource->end = entry->addr + entry->size;
+ for (; i < memmap.nr_entries; i++) {
+ entry = &xen_e820_table->entries[i];
>>
On 15/12/17 02:05, Michael.rosswood wrote:
Hello,
Hello Michael,
I'm trying to understand how Xen and each domain use RAM
on Aarch64 systems.
My understanding is that during Xen startup, Xen will copy
itself to upper physical memory, and continue to run from there,
correct?
Xen will copy
Hi all,
I have a question concerning a 'correct' Xen configuration to measure
performance, as I am currently experiencing a quite unexpected behavior.
My overall setup comprises a Skylake micro-architecture based system
with a Debian Buster and Linux kernel 4.13.16 running on top of Xen
v4.8. For
On 15/12/17 15:58, Boris Ostrovsky wrote:
> On 12/15/2017 09:47 AM, Juergen Gross wrote:
>> On 15/12/17 15:24, Boris Ostrovsky wrote:
> +
> + hostmem_resource->start = max_addr;
> + hostmem_resource->end = entry->addr + entry->size;
> + for (; i < memmap.nr_entries; i++) {
> +
On 12/12/17 15:15, Julien Grall wrote:
Hi Wei/Ian,
Hi,
I have tried this series on Arm64 hardware. I am able to boot and
install Debian on AMD Seattle (laxton{0,1}). But I don't get network
when using Cavium Thunder-X (rochester{0,1}) after reboot.
Looking into more details, the interfac
flight 117183 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117183/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-xsm broken
Tests which di
Thanks Bjorn and Christophfor your response. Please see below for my
comments.
On 12/13/2017 3:24 PM, Bjorn Helgaas wrote:
[+cc Christoph]
On Wed, Dec 13, 2017 at 02:46:57PM -0600, Govinda Tatti wrote:
-static bool pcie_has_flr(struct pci_dev *dev)
+bool pcie_has_flr(struct pci_dev *dev)
On 13/12/17 00:42, 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
Hi Boris,
I love your patch! Yet something to improve:
[auto build test ERROR on xen-tip/linux-next]
[also build test ERROR on v4.15-rc3 next-20171215]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux
On 12/15/2017 10:33 AM, Juergen Gross wrote:
> On 15/12/17 15:58, Boris Ostrovsky wrote:
>> On 12/15/2017 09:47 AM, Juergen Gross wrote:
>>> On 15/12/17 15:24, Boris Ostrovsky wrote:
>> +
>> +hostmem_resource->start = max_addr;
>> +hostmem_resource->end = entry->addr + e
This run is configured for baseline tests only.
flight 72837 linux-3.18 real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/72837/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64
On 12/15/2017 11:04 AM, kbuild test robot wrote:
> Hi Boris,
>
> I love your patch! Yet something to improve:
>
> [auto build test ERROR on xen-tip/linux-next]
> [also build test ERROR on v4.15-rc3 next-20171215]
> [if your patch is applied to the wrong git tree, please drop
flight 117138 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117138/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 116904
test-armhf-armhf-libvirt-xsm 14 sav
On 15/12/2017 16:55, Juergen Gross wrote:
> I'm fine with the general idea.
>
> I'm wondering whether you really want to require CONFIG_XEN for the
> KVM case, though.
>
> Wouldn't it be better to rename arch/x86/xen/enlighten_pvh.c to
> arch/x86/pvh.c and arch/x86/xen/xen-pvh.S to arch/x86/pvh-h
[+cc Russell, Sinan, Herbert, Srikanth, Derek, Satanand, Felix, Raghu]
On Fri, Dec 15, 2017 at 09:48:02AM -0600, Govinda Tatti wrote:
> On 12/13/2017 3:24 PM, Bjorn Helgaas wrote:
> >On Wed, Dec 13, 2017 at 02:46:57PM -0600, Govinda Tatti wrote:
> >>-static bool pcie_has_flr(struct pci_dev *d
flight 117187 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117187/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-xsm broken
Tests which di
flight 117141 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117141/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-1 49 xtf/test-hvm64-lbr-tsx-vmentry fail REGR. vs. 116665
Tests which are
Jan,
One quick update on pcie_flr() specific implementation. Please see below.
+static int pcistub_device_reset(struct pci_dev *dev)
+{
+ struct xen_pcibk_dev_data *dev_data;
+ bool slot = false, bus = false;
+ struct pcistub_args arg = {};
+
+ if (!dev)
+ r
Thanks Bjorn for your response. Please see below for my comments.
So, we should consider one of these options.
- set PCI_DEV_FLAGS_NO_FLR_RESET if it is not supported.
- pcie_flr() should return if it is not supported
If we modify pcie_flr() to return error codes, then we need to modify
all ex
flight 117193 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117193/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-xsm broken
Tests which di
This run is configured for baseline tests only.
flight 72853 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/72853/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64
On 12/5/2017 5:31 AM, Julien Grall wrote:
> Hi Sameer,
>
> On 05/12/17 03:59, Sameer Goel wrote:
>> For porting files from Linux it is useful to have a Linux API to Xen API
>> mapping header at a common location.
>> This file adds common API functions and other defines that are needed for
>> por
On 15/12/2017 22:32, Goel, Sameer wrote:
On 12/5/2017 5:31 AM, Julien Grall wrote:
Hi Sameer,
On 05/12/17 03:59, Sameer Goel wrote:
For porting files from Linux it is useful to have a Linux API to Xen API
mapping header at a common location.
This file adds common API functions and other de
On 12/5/2017 7:17 AM, Julien Grall wrote:
> Hello,
>
> On 05/12/17 03:59, Sameer Goel wrote:
>> This driver follows an approach similar to smmu driver. The intent here
>> is to reuse as much Linux code as possible.
>> - Glue code has been introduced in headers to bridge the API calls.
>> - Calle
flight 117200 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117200/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-xsm broken
Tests which di
flight 117201 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117201/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-xsm broken
Tests which di
flight 117143 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117143/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 7 xen-boot fail REGR. vs. 115643
test-amd64-amd64-li
flight 117144 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117144/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-xl-credit2 16 guest-start/debian.repeatfail like 116653
test-xtf-amd64-amd64-5 49 xt
flight 117203 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117203/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-xsm broken
Tests which di
On 12/5/2017 7:17 AM, Julien Grall wrote:
> Hello,
>
> On 05/12/17 03:59, Sameer Goel wrote:
>> This driver follows an approach similar to smmu driver. The intent here
>> is to reuse as much Linux code as possible.
>> - Glue code has been introduced in headers to bridge the API calls.
>> - Calle
62 matches
Mail list logo
