flight 112305 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112305/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 3b341e263da957b2c8896317f41cc32880c878b0
baseline version:
ovmf 1683ecec41a7c944783c5
flight 112290 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112290/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-credit2 4 host-install(4)broken REGR. vs. 111765
test-arm64-arm64-
flight 112286 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112286/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-arm64-arm64-xl-xsm 4 host-install(4) broken pass in 112274
test-arm64-arm64-xl-credit2 4
flight 112297 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112297/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
test-amd64-amd64-libvirt 13 mig
flight 112277 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112277/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-examine 7 reboot fail REGR. vs. 110515
test-amd64-amd64-xl
On 07/25/2017 03:21 PM, Konrad Rzeszutek Wilk wrote:
> Hi Jens,
>
> Please git pull in your branch "for-linus" the following
> branch which is based on 765e40b675a9566459ddcb8358ad16f3b8344bbe
> "blk-mq: map queues to all present CPUs":
>
> git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xe
Send PVCALLS_ACCEPT to the backend. Allocate a new active socket. Make
sure that only one accept command is executed at any given time by
setting PVCALLS_FLAG_ACCEPT_INFLIGHT and waiting on the
inflight_accept_req waitqueue.
sock->sk->sk_send_head is not used for ip sockets: reuse the field to
sto
Implement recvmsg by copying data from the "in" ring. If not enough data
is available and the recvmsg call is blocking, then wait on the
inflight_conn_req waitqueue. Take the active socket in_mutex so that
only one function can access the ring at any given time.
If not enough data is available on
For active sockets, check the indexes and use the inflight_conn_req
waitqueue to wait.
For passive sockets, send PVCALLS_POLL to the backend. Use the
inflight_accept_req waitqueue if an accept is outstanding. Otherwise use
the inflight_req waitqueue: inflight_req is awaken when a new response
is r
Introduce a xenbus frontend for the pvcalls protocol, as defined by
https://xenbits.xen.org/docs/unstable/misc/pvcalls.html.
This patch only adds the stubs, the code will be added by the following
patches.
Signed-off-by: Stefano Stabellini
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
---
Send PVCALLS_CONNECT to the backend. Allocate a new ring and evtchn for
the active socket.
Introduce a data structure to keep track of sockets. Introduce a
waitqueue to allow the frontend to wait on data coming from the backend
on the active socket (recvmsg command).
Two mutexes (one of reads and
Send PVCALLS_BIND to the backend. Introduce a new structure, part of
struct sock_mapping, to store information specific to passive sockets.
Introduce a status field to keep track of the status of the passive
socket.
Introduce a waitqueue for the "accept" command (see the accept command
implementa
Send PVCALLS_RELEASE to the backend and wait for a reply. Take both
in_mutex and out_mutex to avoid concurrent accesses. Then, free the
socket.
Signed-off-by: Stefano Stabellini
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
---
drivers/xen/pvcalls-front.c | 85 ++
Also add pvcalls-front to the Makefile.
Signed-off-by: Stefano Stabellini
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
---
drivers/xen/Kconfig | 9 +
drivers/xen/Makefile | 1 +
2 files changed, 10 insertions(+)
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 4545561
Send data to an active socket by copying data to the "out" ring. Take
the active socket out_mutex so that only one function can access the
ring at any given time.
If not enough room is available on the ring, rather than returning
immediately or sleep-waiting, spin for up to 5000 cycles. This small
Implement pvcalls frontend removal function. Go through the list of
active and passive sockets and free them all, one at a time.
Signed-off-by: Stefano Stabellini
Reviewed-by: Juergen Gross
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
---
drivers/xen/pvcalls-front.c | 28 +
Implement the probe function for the pvcalls frontend. Read the
supported versions, max-page-order and function-calls nodes from
xenstore.
Introduce a data structure named pvcalls_bedata. It contains pointers to
the command ring, the event channel, a list of active sockets and a list
of passive so
Send a PVCALLS_SOCKET command to the backend, use the masked
req_prod_pvt as req_id. This way, req_id is guaranteed to be between 0
and PVCALLS_NR_REQ_PER_RING. We already have a slot in the rsp array
ready for the response, and there cannot be two outstanding responses
with the same req_id.
Wait
Send PVCALLS_LISTEN to the backend.
Signed-off-by: Stefano Stabellini
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
---
drivers/xen/pvcalls-front.c | 48 +
drivers/xen/pvcalls-front.h | 1 +
2 files changed, 49 insertions(+)
diff --git a/drivers
Hi all,
this series introduces the frontend for the newly introduced PV Calls
procotol.
PV Calls is a paravirtualized protocol that allows the implementation of
a set of POSIX functions in a different domain. The PV Calls frontend
sends POSIX function calls to the backend, which implements them a
Hi Jens,
Please git pull in your branch "for-linus" the following
branch which is based on 765e40b675a9566459ddcb8358ad16f3b8344bbe
"blk-mq: map queues to all present CPUs":
git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
stable/for-jens-4.13
It has two bug-fixes for the xen-blkfr
On Mon, 24 Jul 2017, Juergen Gross wrote:
> On 22/07/17 02:12, Stefano Stabellini wrote:
> > Send PVCALLS_RELEASE to the backend and wait for a reply. Take both
> > in_mutex and out_mutex to avoid concurrent accesses. Then, free the
> > socket.
> >
> > Signed-off-by: Stefano Stabellini
> > CC: bo
On Mon, 24 Jul 2017, Juergen Gross wrote:
> On 22/07/17 02:12, Stefano Stabellini wrote:
> > For active sockets, check the indexes and use the inflight_conn_req
> > waitqueue to wait.
> >
> > For passive sockets, send PVCALLS_POLL to the backend. Use the
> > inflight_accept_req waitqueue if an acc
On Mon, 24 Jul 2017, Juergen Gross wrote:
> On 22/07/17 02:11, Stefano Stabellini wrote:
> > Send a PVCALLS_SOCKET command to the backend, use the masked
> > req_prod_pvt as req_id. This way, req_id is guaranteed to be between 0
> > and PVCALLS_NR_REQ_PER_RING. We already have a slot in the rsp arr
On Mon, 24 Jul 2017, Juergen Gross wrote:
> On 22/07/17 02:11, Stefano Stabellini wrote:
> > Implement the probe function for the pvcalls frontend. Read the
> > supported versions, max-page-order and function-calls nodes from
> > xenstore.
> >
> > Introduce a data structure named pvcalls_bedata. I
flight 112276 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112276/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 112201
test-armhf-armhf-libvirt-xsm 14 saveresto
We need to choose ACPI tables and ACPI IO port location
properly depending on the device model version we are running.
Previously, this decision was made by BIOS type specific
code in hvmloader, e.g. always load QEMU traditional specific
tables if it's ROMBIOS and always load QEMU Xen specific
tabl
> > Thanks---however, after re-reading xen-mapcache.c, dma needs to be false
> > for unlocked mappings.
>
> If there is a DMA operation already in progress, it means that we'll
> already have a locked mapping for it.
Yes, I only wanted to say that qemu_ram_ptr_length should pass dma=false
when c
4.12-stable review patch. If anyone has any objections, please let me know.
--
From: Bart Van Assche
commit 9f4ab18ac51dc87345a9cbd2527e6acf7a0a9335 upstream.
scsiback_release_cmd() must not dereference se_cmd->se_tmr_req
because that memory is freed by target_free_cmd_mem() b
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Bart Van Assche
commit 9f4ab18ac51dc87345a9cbd2527e6acf7a0a9335 upstream.
scsiback_release_cmd() must not dereference se_cmd->se_tmr_req
because that memory is freed by target_free_cmd_mem() be
On Tue, 25 Jul 2017, Julien Grall wrote:
> On 25/07/17 19:48, Stefano Stabellini wrote:
> > On Tue, 25 Jul 2017, Julien Grall wrote:
> > > On 25/07/17 07:47, Vijay Kilari wrote:
> > > > > > void numa_failed(void)
> > > > > > {
> > > > > > numa_off = true;
> > > > > > init_dt_numa_distan
On Tue, 25 Jul 2017, Paolo Bonzini wrote:
> - Original Message -
> > From: "Stefano Stabellini"
> > To: "Paolo Bonzini"
> > Cc: "Anthony PERARD" , "Stefano Stabellini"
> > ,
> > xen-devel@lists.xen.org, qemu-de...@nongnu.org
> > Sent: Tuesday, July 25, 2017 8:08:21 PM
> > Subject: Re: QE
c/s 0943a03037 added some extra protection for overflowing the emulation
instruction cache, but Coverity points out that boundary condition is off by
one when memcpy()'ing out of the buffer.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Paul Durrant
---
xen/arch/x86/hvm/emulate.c | 4 ++
On 07/25/2017 02:28 PM, Andrew Cooper wrote:
> Most SVM code already uses struct segment_register. Drop the typedef and
> adjust the definitions in struct vmcb_struct, and svm_dump_sel(). Introduce
> some build-time assertions that struct segment_register from the common
> emulation code is usabl
On 25/07/17 19:48, Stefano Stabellini wrote:
On Tue, 25 Jul 2017, Julien Grall wrote:
On 25/07/17 07:47, Vijay Kilari wrote:
void numa_failed(void)
{
numa_off = true;
init_dt_numa_distance();
node_distance_fn = NULL;
+init_cpu_to_node();
+}
+
+void __init numa_set_cpu_nod
On Tue, 25 Jul 2017, Julien Grall wrote:
> On 25/07/17 07:47, Vijay Kilari wrote:
> > > > void numa_failed(void)
> > > > {
> > > > numa_off = true;
> > > > init_dt_numa_distance();
> > > > node_distance_fn = NULL;
> > > > +init_cpu_to_node();
> > > > +}
> > > > +
> > > > +void
- Original Message -
> From: "Stefano Stabellini"
> To: "Paolo Bonzini"
> Cc: "Anthony PERARD" , "Stefano Stabellini"
> ,
> xen-devel@lists.xen.org, qemu-de...@nongnu.org
> Sent: Tuesday, July 25, 2017 8:08:21 PM
> Subject: Re: QEMU commit 04bf2526ce breaks use of xen-mapcache
>
> On
On 25/07/17 07:47, Vijay Kilari wrote:
void numa_failed(void)
{
numa_off = true;
init_dt_numa_distance();
node_distance_fn = NULL;
+init_cpu_to_node();
+}
+
+void __init numa_set_cpu_node(int cpu, unsigned int nid)
+{
+if ( !node_isset(nid, processor_nodes_parsed) || ni
This simplifies the logic by separating the x86_segment check from the type
check. No functional change.
Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
---
xen/arch/x86/hvm/domain.c | 43 +--
1 file changed, 29 insertions(+), 14 deletions(-)
diff
No functional change, but the source code is less verbose.
Andrew Cooper (3):
x86/svm: Drop svm_segment_register_t
x86/hvm: Rearange check_segment() to use a switch statement
x86/emul: Drop segment_attributes_t
tools/fuzz/x86_instruction_emulator/fuzz-emul.c | 10 +-
tools/tests/x86_emula
The amount of namespace resolution is unnecessarily large, as all code deals
in terms of struct segment_register. This removes the attr.fields part of all
references, and alters attr.bytes to just attr.
Three areas of code using initialisers for segment_register are tweaked to
compile with older
Most SVM code already uses struct segment_register. Drop the typedef and
adjust the definitions in struct vmcb_struct, and svm_dump_sel(). Introduce
some build-time assertions that struct segment_register from the common
emulation code is usable in struct vmcb_struct.
While making these adjustme
Anthony PERARD writes ("[OSSTEST PATCH v13 00/24] Have OpenStack tested on top
of xen's master and libvirt's master."):
> Now powered with subunit-to-substep engine.
>
> The Tempest test names reported via subunit are in the form:
> tempest.scenario.test_minimum_basic.TestMinimumBasicScenario.tes
Anthony PERARD writes ("[OSSTEST PATCH v13 18/24] TestSupport: Introduce
target_cmd_stashed"):
> This works like target_cmd, but takes a ref to a filename as argument
> and stash the output of the command then return a path to the stashed
> output.
...
> +# Like target_cmd, but stash cmd stdout an
Anthony PERARD writes ("[OSSTEST PATCH v13 22/24] New branch openstack-ocata"):
> Testing of the Ocata stable branch of OpenStack against Xen unstable.
>
> OpenStack have many different repo which should be in sync, so we should
> attempd to grab the revisions of the stable branch of every OpenSta
Anthony PERARD writes ("[OSSTEST PATCH v13 24/24] openstack tests: Don't run
them on arm*"):
> Signed-off-by: Anthony PERARD
Acked-by: Ian Jackson
You should probably mention the existence of this patch in the other
one's commit message...
Ian.
___
Anthony PERARD writes ("[OSSTEST PATCH v13 21/24] Create a flight to test
OpenStack with xen-unstable and libvirt"):
> This patch creates a flight "openstack*", with those jobs:
Do you mean it creates a "branch" ? But I don't think it does. I
predict no changes to the output of mg-list-all-bran
On Tue, 25 Jul 2017, Julien Grall wrote:
> On 25/07/17 18:52, Stefano Stabellini wrote:
> > On Tue, 25 Jul 2017, Andrii Anisov wrote:
> > > Hello Andrew,
> > >
> > >
> > > On 25.07.17 19:23, Andrew Cooper wrote:
> > > > As a general rule, Xen needs to be able to tolerate and cope with any
> > > >
On Tue, 25 Jul 2017, Paolo Bonzini wrote:
> > Hi,
> >
> > Commits 04bf2526ce (exec: use qemu_ram_ptr_length to access guest ram)
> > start using qemu_ram_ptr_length() instead of qemu_map_ram_ptr().
> > That result in calling xen_map_cache() with lock=true, but this mapping
> > is never invalidated
On 25/07/17 18:52, Stefano Stabellini wrote:
On Tue, 25 Jul 2017, Andrii Anisov wrote:
Hello Andrew,
On 25.07.17 19:23, Andrew Cooper wrote:
As a general rule, Xen needs to be able to tolerate and cope with any
quantity of crap described by the firmware. On the x86 side, we have
large quan
Anthony PERARD writes ("[OSSTEST PATCH v13 19/24] TestSupport: Implement
target_subunit_cmd a subunit stream parser into substeps"):
> target_subunit_cmd can be used like target_cmd, but the command would
> needs to output a subunit v1 stream, which will be parsed and turned
> into osstest substep
On Tue, 25 Jul 2017, Andrii Anisov wrote:
> Hello Andrew,
>
>
> On 25.07.17 19:23, Andrew Cooper wrote:
> > As a general rule, Xen needs to be able to tolerate and cope with any
> > quantity of crap described by the firmware. On the x86 side, we have
> > large quantities of workarounds for buggy
> Hi,
>
> Commits 04bf2526ce (exec: use qemu_ram_ptr_length to access guest ram)
> start using qemu_ram_ptr_length() instead of qemu_map_ram_ptr().
> That result in calling xen_map_cache() with lock=true, but this mapping
> is never invalidated.
> So QEMU use more and more RAM until it stop workin
On 25/07/17 17:40, Alexey G wrote:
> On Mon, 24 Jul 2017 21:39:08 +0100
> Igor Druzhinin wrote:
>>> But, the problem is that overall MMIO hole(s) requirements are not known
>>> exactly at the time the HVM domain being created. Some PCI devices will
>>> be emulated, some will be merely passed throu
Hi Bhupinder,
Thanks for trying, and I would have done the same thing as you did:
ifeq ($(CONFIG_SBSA_VUART_CONSOLE),y)
CONFIG_VUART_CONSOLE := y
endif
However, we don't want to introduce a dependency between "make tools"
and "make xen", meaning that one should be able to do "make tools"
success
Anthony PERARD writes ("[OSSTEST PATCH v13 10/24] ts-openstack-deploy: Increase
open fd limit for RabbitMQ"):
> Signed-off-by: Anthony PERARD
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On 07/18/2017 01:20 PM, Razvan Cojocaru wrote:
> On 07/18/2017 01:09 PM, Andrew Cooper wrote:
>> On 18/07/17 10:37, Petre Pircalabu wrote:
>>> If case of a vm_event with the emulate_flags set, if the instruction
>>> cannot be emulated, the monitor should be notified instead of directly
>>> injectin
On Tue, 25 Jul 2017, Julien Grall wrote:
> Hi Stefano,
>
> On 07/21/2017 08:44 PM, Stefano Stabellini wrote:
> > On Fri, 21 Jul 2017, Julien Grall wrote:
> > > Hi,
> > >
> > > On 18/07/17 21:07, Stefano Stabellini wrote:
> > > > On Mon, 17 Jul 2017, Bhupinder Thakur wrote:
> > > > > This patch fi
Hi,
On 18 July 2017 at 17:00, Wei Liu wrote:
> CC x86 maintainers
>
> On Tue, Jul 18, 2017 at 12:19:19PM +0100, Julien Grall wrote:
>> >
>> > ("arch_arm", Struct(None, [("gic_version", libxl_gic_version),
>> > + ("vuart", libxl_vuart_type),
>>
>> ... here it is
On Tue, 2017-07-25 at 17:52 +0100, George Dunlap wrote:
> On 07/25/2017 05:47 PM, Dario Faggioli wrote:
> >
> > All that being said, it probably would be good to add a performance
> > counter, and try to get a sense of how frequently we actually end
> > up in
> > this function as a fallback.
> >
On Tue, 2017-07-25 at 15:34 +0100, George Dunlap wrote:
> On 06/29/2017 11:09 AM, Dario Faggioli wrote:
> > E.g., if the vcpu is "greedy", and always tries to run, as soon as
> > it
> > has some budget, the difference between the two solution is _where_
> > we
> > put the "sitting period".
>
> Sor
From: Oleksandr Tyshchenko
Replace existing single-page stuff (IOMMU APIs and platform callbacks)
with the multi-page one followed by modifications of all related parts.
These new map_pages/unmap_pages APIs do almost the same thing
as old map_page/unmap_page ones except the formers have extra
or
From: Oleksandr Tyshchenko
The presence of this flag lets us know that the guest domain has statically
assigned devices which will most likely be used for passthrough
and as the result the IOMMU is expected to be used for this domain.
Taking into the account this hint when dealing with non-share
From: Oleksandr Tyshchenko
Reduce the scope of the TODO by squashing single-page stuff with
multi-page one. Next target is to use large pages whenever possible
in the case that hardware supports them.
Signed-off-by: Oleksandr Tyshchenko
CC: Jan Beulich
CC: Suravee Suthikulpanit
---
Change
From: Oleksandr Tyshchenko
Update IOMMU mapping if the IOMMU doesn't share page table with the CPU.
The best place to do so on ARM is __p2m_set_entry(). Use mfn as an indicator
of the required action. If mfn is valid call iommu_map_pages(),
otherwise - iommu_unmap_pages().
Signed-off-by: Oleksan
From: Oleksandr Tyshchenko
Not every integrated into ARM SoCs IOMMU can share page tables
with the CPU and as the result the iommu_use_hap_pt(d) mustn't
always be true.
Reuse x86's iommu_hap_pt_share flag to indicate whether the IOMMU
page table is shared or not.
As P2M table must always be shar
From: Oleksandr Tyshchenko
This flag is intended to let Xen know that the guest has devices
which will most likely be used for passthrough and as the result
the IOMMU is expected to be used for this domain.
The primary aim of this knowledge is to help the IOMMUs that don't
share page tables with
From: Oleksandr Tyshchenko
The helper has the same purpose as existing for x86 one.
It is used for choosing IOMMU mapping attribute according to
the memory type.
Signed-off-by: Oleksandr Tyshchenko
Reviewed-by: Julien Grall
---
Changes in v1:
- Add Julien's reviewed-by
Changes in
From: Oleksandr Tyshchenko
1. Add missing return in case if IOMMU ops have been already set.
2. Add check for shared IOMMU before returning an error.
Signed-off-by: Oleksandr Tyshchenko
CC: Julien Grall
---
Changes in V1:
-
Changes in V2:
-
---
xen/drivers/passthrough/arm/
From: Oleksandr Tyshchenko
The hardware domains require IOMMU to be used in the most cases and
a decision to use it is made at hardware domain construction time.
But, it is not the best moment for the non-shared IOMMUs due to
the necessity of retrieving all mapping which could happen in a period
From: Oleksandr Tyshchenko
Eliminate TODO by squashing single-page stuff with multi-page one.
Signed-off-by: Oleksandr Tyshchenko
CC: Julien Grall
---
Changes in v1:
-
Changes in v2:
-
---
xen/drivers/passthrough/arm/smmu.c | 48 +-
1 fi
From: Oleksandr Tyshchenko
We don't passthrough IOMMU device to DOM0 even if it is not used by
Xen. Therefore exposing the properties that describe relationship
between master devices and IOMMUs does not make any sense.
According to the:
1. Documentation/devicetree/bindings/iommu/iommu.txt
2. Do
From: Oleksandr Tyshchenko
Port Linux helper of_count_phandle_with_args for counting
number of phandles in a property.
Signed-off-by: Oleksandr Tyshchenko
Reviewed-by: Julien Grall
---
Changes in v1:
- Add Julien's reviewed-by
Changes in v2:
-
---
xen/common/device_tree.c
From: Oleksandr Tyshchenko
Reduce the scope of the TODO by squashing single-page stuff with
multi-page one. Next target is to use large pages whenever possible
in the case that hardware supports them.
Signed-off-by: Oleksandr Tyshchenko
CC: Jan Beulich
CC: Kevin Tian
---
Changes in v1:
From: Oleksandr Tyshchenko
Hi, all.
The purpose of this patch series is to create a base for porting
any "Non-shared" IOMMUs to Xen on ARM. Saying "Non-shared" IOMMU I mean
the IOMMU that can't share the page table with the CPU.
Primarily, we are interested in IPMMU-VMSA and I hope that it will
Hi,
Commits 04bf2526ce (exec: use qemu_ram_ptr_length to access guest ram)
start using qemu_ram_ptr_length() instead of qemu_map_ram_ptr().
That result in calling xen_map_cache() with lock=true, but this mapping
is never invalidated.
So QEMU use more and more RAM until it stop working for a reason
On 25/07/17 17:40, Alexey G wrote:
> On Mon, 24 Jul 2017 21:39:08 +0100
> Igor Druzhinin wrote:
>>> But, the problem is that overall MMIO hole(s) requirements are not known
>>> exactly at the time the HVM domain being created. Some PCI devices will
>>> be emulated, some will be merely passed throu
On 07/25/2017 05:47 PM, Dario Faggioli wrote:
> On Tue, 2017-07-25 at 17:17 +0100, George Dunlap wrote:
>> On 07/25/2017 05:00 PM, Dario Faggioli wrote:
>>> On Tue, 2017-07-25 at 11:19 +0100, George Dunlap wrote:
>>> Mmm.. I think you're right. In fact, in a properly configured
>>> system,
>>>
Hello Andrew,
On 25.07.17 19:23, Andrew Cooper wrote:
As a general rule, Xen needs to be able to tolerate and cope with any
quantity of crap described by the firmware. On the x86 side, we have
large quantities of workarounds for buggy ACPI/MP/SMBIOS tables.
That approach somehow covered with
On Tue, 25 Jul 2017 15:13:17 +0100
Igor Druzhinin wrote:
> >> The algorithm implemented in hvmloader for that is not complicated and
> >> can be moved to libxl easily. What we can do is to provision a hole big
> >> enough to include all the initially assigned PCI devices. We can also
> >> account
On Tue, 2017-07-25 at 17:17 +0100, George Dunlap wrote:
> On 07/25/2017 05:00 PM, Dario Faggioli wrote:
> > On Tue, 2017-07-25 at 11:19 +0100, George Dunlap wrote:
> > >
> > Mmm.. I think you're right. In fact, in a properly configured
> > system,
> > we'll never go past step 3 (from the comment a
On Mon, 24 Jul 2017 21:39:08 +0100
Igor Druzhinin wrote:
> > But, the problem is that overall MMIO hole(s) requirements are not known
> > exactly at the time the HVM domain being created. Some PCI devices will
> > be emulated, some will be merely passed through and yet there will be
> > some RMRR
Dear George,
On 19.07.17 12:42, George John wrote:
I want to bring up Android over Xen as Dom0 on Rcar-H3 salvator x
board. Can anybody please share the procedure to do so.?.
Once you have an Android for Salvator-X board, the procedure is not
really specific.
You have to have the ATF running u-
On 25/07/17 17:02, Andrii Anisov wrote:
> Hello Julien,
>
>
> On 25.07.17 18:44, Julien Grall wrote:
>> I have seen work on this board for the past year and it is the first
>> time I have seen a complain about memory overlap. So why this sudden
>> change?
> It just an approach change. I'm cleaning
On Tue, Jul 25, 2017 at 06:27:31PM +0300, Andrii Anisov wrote:
> On 25.07.17 17:23, Julien Grall wrote:
> >I think this is by chance rather than by design. The first
> >question to answer is why a Firmware would specify twice the same
> >memory banks? Is it valid from the specification?
> Yep, that
On 07/25/2017 05:00 PM, Dario Faggioli wrote:
> On Tue, 2017-07-25 at 11:19 +0100, George Dunlap wrote:
>> On 06/16/2017 03:13 PM, Dario Faggioli wrote:
>>>
>>> diff --git a/xen/common/sched_credit2.c
>>> b/xen/common/sched_credit2.c
>>> index c749d4e..54f6e21 100644
>>> --- a/xen/common/sched_cred
On 25/07/17 16:27, Tim Deegan wrote:
> At 16:00 +0100 on 25 Jul (1500998413), Andrew Cooper wrote:
>> The purpose of guest_walk_tables() is to match the behaviour of real
>> hardware.
>>
>> A PV guest can have 2M superpages in its pagetables, via the M2P and the
>> initial initrd mapping, even if
On Tue, 2017-07-25 at 16:15 +0100, George Dunlap wrote:
> On Thu, Jun 29, 2017 at 1:56 PM, Dario Faggioli
> wrote:
> > In line with what is there in all the other schedulers.
> >
> > Signed-off-by: Dario Faggioli
> > ---
> > George Dunlap
>
> FYI forgot the 'CC:' for this and patch 5. :-)
>
On Tue, Jul 25, 2017 at 04:27:00PM +0100, Tim Deegan wrote:
> At 16:00 +0100 on 25 Jul (1500998413), Andrew Cooper wrote:
> > The purpose of guest_walk_tables() is to match the behaviour of real
> > hardware.
> >
> > A PV guest can have 2M superpages in its pagetables, via the M2P and the
> > ini
On Tue, Jul 25, 2017 at 04:00:13PM +0100, Andrew Cooper wrote:
> The purpose of guest_walk_tables() is to match the behaviour of real hardware.
>
> A PV guest can have 2M superpages in its pagetables, via the M2P and the
> initial initrd mapping, even if it isn't permitted to create arbitrary 2M
>
On Tue, 2017-07-25 at 16:08 +0100, George Dunlap wrote:
> On 06/08/2017 01:08 PM, Dario Faggioli wrote:
> >
> Hmm, this needs to be rebased on the structure layout patches I
> checked
> in last week. :-)
>
Indeed it does. And of course, I'm up for it. :-)
The soft-affinity series is likely to ge
Hello Julien,
On 25.07.17 18:44, Julien Grall wrote:
I have seen work on this board for the past year and it is the first
time I have seen a complain about memory overlap. So why this sudden
change?
It just an approach change. I'm cleaning up nits for the board.
Is that a comment from the v
On Tue, 2017-07-25 at 11:19 +0100, George Dunlap wrote:
> On 06/16/2017 03:13 PM, Dario Faggioli wrote:
> >
> > diff --git a/xen/common/sched_credit2.c
> > b/xen/common/sched_credit2.c
> > index c749d4e..54f6e21 100644
> > --- a/xen/common/sched_credit2.c
> > +++ b/xen/common/sched_credit2.c
> > @
On Thu, Jun 29, 2017 at 1:56 PM, Dario Faggioli
wrote:
> The null scheduler does not really use hard-affinity for
> scheduling, it uses it for 'placement', i.e., for deciding
> to what pCPU to statically assign a vCPU.
>
> Let's use soft-affinity in the same way, of course with the
> difference th
On 25/07/17 16:27, Andrii Anisov wrote:
Hello Julien,
Hi Andrii,
On 25.07.17 17:23, Julien Grall wrote:
I think this is by chance rather than by design. The first question to
answer is why a Firmware would specify twice the same memory banks? Is
it valid from the specification?
Yep, that is
On Tue, Jul 25, 2017 at 04:18:52PM +0100, Ian Jackson wrote:
> Roger Pau Monne writes ("[PATCH v7 20/20] osstest: save/retrieve the last
> successfully tested FreeBSD build"):
> > And use it in order to install the hosts for the next FreeBSD flight.
> ...
> > +case "$branch" in
> > +freebsd-*)
> >
Hello Julien,
On 25.07.17 17:23, Julien Grall wrote:
I think this is by chance rather than by design. The first question to
answer is why a Firmware would specify twice the same memory banks? Is
it valid from the specification?
Yep, that is the question.
Regardless that, it looks like to me
At 16:00 +0100 on 25 Jul (1500998413), Andrew Cooper wrote:
> The purpose of guest_walk_tables() is to match the behaviour of real hardware.
>
> A PV guest can have 2M superpages in its pagetables, via the M2P and the
> initial initrd mapping, even if it isn't permitted to create arbitrary 2M
> su
On Thu, Jun 29, 2017 at 1:56 PM, Dario Faggioli
wrote:
> Whether or not there's pending tasklet work to do, it's
> something we know from the tasklet_work_scheduled parameter.
>
> Deal with that as soon as possible, like all other schedulers
> do.
>
> Signed-off-by: Dario Faggioli
Reviewed-by: G
Roger Pau Monne writes ("[PATCH v7 20/20] osstest: save/retrieve the last
successfully tested FreeBSD build"):
> And use it in order to install the hosts for the next FreeBSD flight.
...
> +case "$branch" in
> +freebsd-*)
> +IFS=$'\n'
That's quite brave, but I don't object. I would have pipe
1 - 100 of 197 matches
Mail list logo
