flight 101215 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101215/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 101209
test-amd64-i386-xl-qemuu-wi
flight 101217 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101217/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf dab62c5ec8a88def3ee99c04d644720cb201de08
baseline version:
ovmf 84bc72fb7ddaa26105bfe
Last part of the wiring necessary for allowing to
change the value of the ratelimit_us parameter online,
for Credit2 (like it is already for Credit1).
Signed-off-by: Dario Faggioli
Reviewed-by: George Dunlap
---
Cc: Ian Jackson
Cc: Wei Liu
---
docs/man/xl.pod.1.in |9
tools/libx
This is the remaining part of the plumbing (the libxl
one) necessary to be able to change the value of the
ratelimit_us parameter online, for Credit2 (like it is
already for Credit1).
Note that, so far, we were rejecting (for Credit1) a
new value of zero, despite it is a pretty nice way to
ask for
When a vcpu explicitly yields it is usually giving
us an advice of "let someone else run and come back
to me in a bit."
Credit2 isn't, so far, doing anything when a vcpu
yields, which means an yield is basically a NOP (well,
actually, it's pure overhead, as it causes the scheduler
kick in, but the
More specifically, the the error handling path is
made compliant with libxl's codying style.
No functional change intended.
Signed-off-by: Dario Faggioli
---
Cc: Ian Jackson
Cc: Wei Liu
Cc: George Dunlap
---
Changes from v1:
* new patch, containing only the coding style changes from what was
As far as {csched, csched2, rt}_schedule() are concerned,
an "empty" event, would already make it easier to read and
understand a trace.
But while there, add a few useful information, like
if the cpu that is going through the scheduler has
been tickled or not, if it is currently idle, etc
(they va
There are some scheduling related trace records that
are not being taken care of (and hence only dumped as
raw records).
Some of them are being introduced in this series, while
other were just neglected by previous patches.
Add support for them.
Signed-off-by: Dario Faggioli
Acked-by: George Du
The condition for a Credit2 scheduling epoch coming to an
end is that the vcpu at the front of the runqueue has negative
credits. However, it is possible, that runq_candidate() does
not actually return to the scheduler the first vcpu in the
runqueue (e.g., because such vcpu can't run on the cpu tha
Rate limiting has been primarily introduced to avoid too
heavy context switch rate due to interrupts, and, in
general, asynchronous events.
If a vcpu "voluntarily" yields, we really should let it
give up the cpu for a while.
In fact, it may be that it is yielding because it's about
to start spinn
If vcpu x has run for 200us, and sched_ratelimit_us is
1000us, continue running x _but_ return 1000us-200us as
the next time slice. This way, next scheduling point will
happen in 800us, i.e., exactly at the point when x crosses
the threshold, and can be descheduled (if appropriate).
Right now (wit
Right now, the following scenario can occurr:
- upon vcpu v wakeup, v itself is put in the runqueue,
and pcpu X is tickled;
- pcpu Y schedules (for whatever reason), sees v in
the runqueue and picks it up.
This may seem ok (or even a good thing), but it's not.
In fact, if runq_tickle() dec
Hey,
This is v2 of my Credit1 and Credit2 improvements series. First posting is
here:
https://lists.xen.org/archives/html/xen-devel/2016-08/msg02183.html
Now, couple of things:
- some of the patches have been applied already out of v1;
- I've reshuffled the remaining patches a bit, mostly upo
On Tue, 2016-09-13 at 12:28 +0100, George Dunlap wrote:
> On 17/08/16 18:18, Dario Faggioli wrote:
> >
> diff --git a/xen/common/sched_credit2.c
> > @@ -2233,7 +2241,8 @@ void __dump_execstate(void *unused);
> > static struct csched2_vcpu *
> > runq_candidate(struct csched2_runqueue_data *rqd,
>
Dumping timer info may run for a long time on the huge machine with
a lot of physical cpus. To avoid triggering NMI watchdog, add
process_pending_softirqs() in the loop of dumping timer info.
Signed-off-by: Lan Tianyu
---
xen/common/timer.c |1 +
1 files changed, 1 insertions(+), 0 deletions
Resend because the patchset seems to miss xen devel maillist.
This patchset is to fix triggering NMI watchdog during dump timer info
on the huge machine with a mount of physical cpus. Detail please see
change log of Patch 1.
Previous discussion:
https://patchwork.kernel.org/patch/9328449/
Lan T
Keyhandler may run for a long time in a timer handler on the large machine
with a lot of physical cpus(E,G keyhandler for dumping timer info) when serial
port driver works in the poll mode. When timer interrupt arrives, timer
subsystem
runs all timer handlers before programming next timer interrup
flight 101213 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101213/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101203
test-amd64-amd64-xl-rtds
On Mon, 2016-08-22 at 10:28 +0100, Ian Jackson wrote:
> Dario Faggioli writes ("[PATCH 14/24] libxl: allow to set the
> ratelimit value online for Credit2"):
> ...
> >
> > -rc = xc_sched_credit_params_set(ctx->xch, poolid, &sparam);
> > -if ( rc < 0 ) {
> > -LOGE(ERROR, "setting sc
flight 101209 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101209/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-rtds 9 debian-install fail blocked in 101182
test-amd64-i386-xl-qemut-wi
..calculating its value during runtime.
Signed-off-by: Daniel Kiper
Acked-by: Jan Beulich
---
xen/arch/x86/setup.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index eb674c8..f42bf7b 100644
--- a/xen/arch/x86/setup.c
+++ b
This way Xen can be loaded on EFI platforms using GRUB2 and
other boot loaders which support multiboot2 protocol.
Signed-off-by: Daniel Kiper
---
v9 - suggestions/fixes:
- use .L labels instead of numeric ones in multiboot2 data scanning loops
(suggested by Jan Beulich).
v8 - suggestions
Current early command line parser implementation in assembler
is very difficult to change to relocatable stuff using segment
registers. This requires a lot of changes in very weird and
fragile code. So, reimplement this functionality in C. This
way code will be relocatable out of the box (without p
Add multiboot2 protocol support for relocatable images. Only GRUB2 with
"multiboot2: Add support for relocatable images" patch understands
that feature. Older multiboot protocol (regardless of version)
compatible loaders ignore it and everything works as usual.
Signed-off-by: Daniel Kiper
---
v9
This way macro name better describes its function.
Currently it is used to calculate symbol offset in
relation to the beginning of Xen image mapping.
However, value returned by sym_offs() for a given
symbol is not always equal its physical address.
There is no functional change.
Suggested-by: Jan
Subsequent patches introducing relocatable early boot code play with
page tables using 2 MiB huge pages. If load address is not aligned at
2 MiB then code touching such page tables must have special cases for
start and end of Xen image memory region. So, let's make life easier
and move default load
Every multiboot protocol (regardless of version) compatible image must
specify its load address (in ELF or multiboot header). Multiboot protocol
compatible loader have to load image at specified address. However, there
is no guarantee that the requested memory region (in case of Xen it starts
at 2
..nor EFI platforms with runtime services enabled.
Suggested-by: Jan Beulich
Signed-off-by: Daniel Kiper
Acked-by: Jan Beulich
---
v6 - suggestions/fixes:
- move this commit behind "efi: create efi_enabled()" commit
(suggested by Jan Beulich).
v5 - suggestions/fixes:
- fix build err
This patch is prereq for "efi: build xen.gz with EFI code" patch which adds,
among others, xen/arch/x86/efi/relocs-dummy.S to xen.gz output. Below there
is a description why it is needed.
Currently xen ELF end of image address is calculated using first line from
"nm -nr xen/xen-syms" output. Howev
First of all we need to differentiate between legacy BIOS
and EFI platforms during runtime, not during build, because
one image will have legacy and EFI code and can be executed
on both platforms. Additionally, we need more fine grained
knowledge about EFI environment and check for EFI platform
and
Hi,
I am sending ninth version of multiboot2 protocol support for
legacy BIOS and EFI platforms. This patch series release contains
fixes for all known issues.
The final goal is xen.efi binary file which could be loaded by EFI
loader, multiboot (v1) protocol (only on legacy BIOS platforms) and
mu
Build xen.gz with EFI code. We need this to support multiboot2
protocol on EFI platforms.
If we wish to load non-ELF file using multiboot (v1) or multiboot2 then
it must contain "linear" (or "flat") representation of code and data.
This is requirement of both boot protocols. Currently, PE file con
There is a problem with place_string() which is used as early memory
allocator. It gets memory chunks starting from start symbol and goes
down. Sadly this does not work when Xen is loaded using multiboot2
protocol because then the start lives on 1 MiB address and we should
not allocate a memory fro
Add multiboot2 protocol support. Alter min memory limit handling as we
now may not find it from either multiboot (v1) or multiboot2.
This way we are laying the foundation for EFI + GRUB2 + Xen development.
Signed-off-by: Daniel Kiper
Reviewed-by: Jan Beulich
---
v9 - suggestions/fixes:
- use
On 28/09/16 09:18, Jan Beulich wrote:
> There's a new emulator return code being added to allow bypassing
> certain operations (see the code comment). Its handling in the epilogue
> code involves moving the raising of the single step trap until after
> registers were updated. This should probably h
On 28/09/16 09:19, Jan Beulich wrote:
> Especially for x86_insn_operand_ea() to return dependable segment
> information even when the caller didn't consider applicability, we
> shouldn't have ea.type start out as OP_MEM. Make it OP_NONE instead,
> and set it to OP_MEM when we actually encounter mem
On Thu, 2016-09-29 at 18:28 +0100, George Dunlap wrote:
> On 29/09/16 18:23, Dario Faggioli wrote:
> > In that case, knowing where a certain vcpu that we're asking to
> > burn
> > its credit is running, may mean going quite a bit up in the trace,
> > to
> > find its last context switch/runstate cha
flight 101212 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101212/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
On 28/09/16 09:18, Jan Beulich wrote:
> Sort the special case opcode 0f01 entries numerically, insert blank
> lines between each of the cases, and properly place opening braces.
>
> No functional change.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
_
On 28/09/16 09:17, Jan Beulich wrote:
> This is a prereq for switching PV privileged op emulation to the
> generic instruction emulator. Since handle_xsetbv() is already capable
> of dealing with all guest kinds, avoid introducing another hook here.
>
> Signed-off-by: Jan Beulich
Reviewed-by: And
On 28/09/16 09:16, Jan Beulich wrote:
> This is in preparation for using the generic emulator here.
>
> Signed-off-by: Jan Beulich
This looks like only code motion, so Reviewed-by: Andrew Cooper
There is some rather unhelpful behaviour with the cases where we
silently discard access to MSRs suc
On 28/09/16 09:15, Jan Beulich wrote:
> This is in preparation for using the generic emulator here.
>
> Some care is needed temporarily to not unduly alter guest register
> state: The local variable "res" can only go away once this code got
> fully switched over to using x86_emulate().
>
> Also swi
On 28/09/16 09:14, Jan Beulich wrote:
> This is in preparation for using the generic emulator here.
>
> Signed-off-by: Jan Beulich
>
> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -2255,6 +2255,107 @@ unsigned long guest_to_host_gpr_switch(u
>
> void (*pv_post_outb_hook)(unsigne
On 28/09/16 09:13, Jan Beulich wrote:
> @@ -3204,179 +3285,59 @@ static void emulate_gate_op(struct cpu_u
> return;
> }
>
> -op_bytes = op_default = ar & _SEGMENT_DB ? 4 : 2;
> -ad_default = ad_bytes = op_default;
> -opnd_sel = opnd_off = 0;
> -jump = -1;
> -for
Gerd Hoffmann writes:
> Hi,
>
>> > Hmm, I think the xen core needs better QOM support ...
>> >
>> > struct XenDevice should have a DeviceState element, so it can be used as
>> > device object directly instead of attaching a device object like
>> > this ...
>>
>> Hmm, interesting idea. The dev
On Thu, Sep 29, 2016 at 12:22:37PM -0700, Julien Grall wrote:
>
>
> On 29/09/2016 12:11, Julien Grall wrote:
> >Hi Jan,
> >
> >On 28/09/2016 23:04, Jan Beulich wrote:
> >On 28.09.16 at 21:42, wrote:
> >>>Hi Jan,
> >>>
> >>>On 28/09/2016 05:00, Jan Beulich wrote:
> For consumers not using
On 29/09/16 20:24, Andrew Cooper wrote:
>
>> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
>> @@ -5200,3 +5214,89 @@ x86_emulate(
>> #undef vex
>> #undef override_seg
>> #undef ea
>> +
>> +#ifdef __XEN__
>> +
>> +#include
>> +
>> +struct x86_emulat
On 28/09/16 09:13, Jan Beulich wrote:
> ... instead of custom handling. To facilitate this break out init code
> from _hvm_emulate_one() into the new hvm_emulate_init(), and make
> hvmemul_insn_fetch( globally available.
)
> int __get_instruction_length_from_list(struct vcpu *v,
> const
On 29/09/2016 12:11, Julien Grall wrote:
Hi Jan,
On 28/09/2016 23:04, Jan Beulich wrote:
On 28.09.16 at 21:42, wrote:
Hi Jan,
On 28/09/2016 05:00, Jan Beulich wrote:
For consumers not using (fully) C99-aware compilers, limit the number
of places where tweaking of the headers would be nece
flight 101211 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101211/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xtf 50b7556924ad173285f4116dc9e0937600bf5bee
baseline version:
xtf 962dd4b225c17ae48d36a9
Hi Jan,
On 28/09/2016 05:00, Jan Beulich wrote:
For consumers not using (fully) C99-aware compilers, limit the number
of places where tweaking of the headers would be necessary: Introduce
and use xen_mk_ullong(), allowing its helper macro to be overridden at
once.
For now don't touch public/io/
Hi Jan,
On 28/09/2016 23:04, Jan Beulich wrote:
On 28.09.16 at 21:42, wrote:
Hi Jan,
On 28/09/2016 05:00, Jan Beulich wrote:
For consumers not using (fully) C99-aware compilers, limit the number
of places where tweaking of the headers would be necessary: Introduce
and use xen_mk_ullong(), al
On Thu, Sep 29, 2016 at 07:08:10AM -0600, Jan Beulich wrote:
> Commit a3db233ede ("x86emul: use DstEax also for {,I}{MUL,DIV}") went
> a little too far: DstEax and SrcEax weren't really meant to be used
> together with ModRM - they assume modrm_reg remains zero by the time
> the destination / sourc
On Wed, 28 Sep 2016, Tamas K Lengyel wrote:
> The ARM SMC instructions are already configured to trap to Xen by default. In
> this patch we allow a user-space process in a privileged domain to receive
> notification of when such event happens through the vm_event subsystem by
> introducing the PRIV
On 29/09/16 14:08, Jan Beulich wrote:
> Commit a3db233ede ("x86emul: use DstEax also for {,I}{MUL,DIV}") went
> a little too far: DstEax and SrcEax weren't really meant to be used
> together with ModRM - they assume modrm_reg remains zero by the time
> the destination / source register pointer gets
Hi Kevin,
I agree with you, and if you would be so kind to send the patches, even
untested, they would be much appreciated. Anthony or I will make sure to
test them appropriately and fix them, if they turn out to be incomplete
or partially broken. Would that be OK?
Cheers,
Stefano
P.S.
FYI Xen
On 29/09/16 14:08, Jan Beulich wrote:
> There's no 1-byte operand size case to take care of here, and there's
> no point doing the first writeback using dst fields - we can read rBP
> and write rSP directly.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
__
On 29/09/16 18:23, Dario Faggioli wrote:
> On Tue, 2016-09-20 at 15:35 +0100, George Dunlap wrote:
>> On 17/08/16 18:18, Dario Faggioli wrote:
>>>
>>> In both Credit2's trace records relative to checking
>>> whether we want to preempt a vcpu (in runq_tickle()),
>>> and to credits being burn, make i
On Tue, 2016-09-20 at 15:35 +0100, George Dunlap wrote:
> On 17/08/16 18:18, Dario Faggioli wrote:
> >
> > In both Credit2's trace records relative to checking
> > whether we want to preempt a vcpu (in runq_tickle()),
> > and to credits being burn, make it explicit on which
> > pcpu the vcpu being
On Thu, Sep 29, 2016 at 10:12:12AM -0600, Jan Beulich wrote:
> >>> On 29.09.16 at 16:51, wrote:
> > On Thu, Sep 29, 2016 at 04:51:42AM -0600, Jan Beulich wrote:
> >> >>> On 27.09.16 at 17:57, wrote:
> >> > @@ -1383,15 +1382,25 @@ int __init construct_dom0(
> >> > nr_page
On Tue, 2016-09-20 at 14:32 +0100, George Dunlap wrote:
> On 17/08/16 18:18, Dario Faggioli wrote:
> > diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c
> > @@ -1771,9 +1771,18 @@ csched_schedule(
> > * cpu and steal it.
> > */
> >
> > -/* If we have schedule ra
Hi Stefano and all,
while working on some part of the QEMU block layer infrastructure that
requires going from a BlockBackend to the qdev DeviceState, I noticed
that xen_disk is still not qdevified after all the years. It's the last
device, and has been for a while, that is blocking the necessary
>>> On 29.09.16 at 17:11, wrote:
> On Thu, Sep 29, 2016 at 07:55:00AM -0600, Jan Beulich wrote:
>> >>> On 27.09.16 at 17:57, wrote:
>> > Instead of being tied to the presence of an IOMMU
>>
>> At the very least I'd expect the "why" aspect to get mentioned
>> here.
>
> TBH, it seems simpler to h
>>> On 29.09.16 at 16:51, wrote:
> On Thu, Sep 29, 2016 at 04:51:42AM -0600, Jan Beulich wrote:
>> >>> On 27.09.16 at 17:57, wrote:
>> > @@ -1383,15 +1382,25 @@ int __init construct_dom0(
>> > nr_pages);
>> > }
>> >
>> > -if ( is_pvh_domain(d) )
>> > -
>>> On 29.09.16 at 16:37, wrote:
> On Thu, Sep 29, 2016 at 04:43:07AM -0600, Jan Beulich wrote:
>> >>> On 27.09.16 at 17:56, wrote:
>> > --- a/xen/arch/x86/mm/hap/hap.c
>> > +++ b/xen/arch/x86/mm/hap/hap.c
>> > @@ -379,7 +379,9 @@ hap_set_allocation(struct domain *d, unsigned long
> pages, int *
>>> On 29.09.16 at 16:33, wrote:
> On Thu, Sep 29, 2016 at 04:39:02AM -0600, Jan Beulich wrote:
>> >>> On 27.09.16 at 17:56, wrote:
>> > Return should be an int, and the number of pages should be an unsigned
>> > long.
>>
>> I can see the former, but why the latter? Acting on 32-bit quantities
>>> On 29.09.16 at 16:17, wrote:
> On Wed, Sep 28, 2016 at 10:03:21AM -0600, Jan Beulich wrote:
>> >>> On 27.09.16 at 17:56, wrote:
>> > On PVHv2 guests we explicitly want to use native methods for routing
>> > interrupts.
>> >
>> > Introduce a new XEN_X86_EMU_USE_PIRQ to notify Xen whether a HV
On Tue, 2016-09-13 at 14:33 +0100, George Dunlap wrote:
> On 17/08/16 18:18, Dario Faggioli wrote:
> > Alternatively, we can actually _subtract_ some credits to a
> > yielding vcpu.
> > That will sort of make the effect of a call to yield last in time.
>
> But normally we want the yield to be temp
flight 101206 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101206/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 84bc72fb7ddaa26105bfe5bf36115099da1e60b1
baseline version:
ovmf edb0fda25ea9b2ef73db1
On Thu, Sep 29, 2016 at 07:47:22AM -0600, Jan Beulich wrote:
> >>> On 27.09.16 at 17:57, wrote:
> > So that it can also be used by the PVH-specific domain builder. This is just
> > code motion, it should not introduce any functional change.
> >
> > Signed-off-by: Roger Pau Monné
>
> Looks gener
flight 101203 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101203/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101186
test-amd64-amd64-xl-rtds
On Tue, 2016-09-13 at 12:13 +0100, George Dunlap wrote:
> On 05/09/16 14:47, Dario Faggioli wrote:
> > On Wed, 2016-08-31 at 18:10 +0100, anshul makkar wrote:
> > > > @@ -1273,6 +1280,7 @@ csched2_alloc_vdata(const struct
> > > > scheduler
> > > > *ops, struct vcpu *vc, void *dd)
> > > > else
Hi,
> > Hmm, I think the xen core needs better QOM support ...
> >
> > struct XenDevice should have a DeviceState element, so it can be used as
> > device object directly instead of attaching a device object like
> > this ...
>
> Hmm, interesting idea. The device object could even be added in
On Thu, Sep 29, 2016 at 07:55:00AM -0600, Jan Beulich wrote:
> >>> On 27.09.16 at 17:57, wrote:
> > Instead of being tied to the presence of an IOMMU
>
> At the very least I'd expect the "why" aspect to get mentioned
> here.
TBH, it seems simpler to have it there rather than conditional to the
flight 101202 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101202/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail REGR. vs. 101182
Regressions which
flight 101200 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101200/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass
test-armhf-armhf-libvirt-xsm 14 guest-sav
On Thu, Sep 29, 2016 at 04:51:42AM -0600, Jan Beulich wrote:
> >>> On 27.09.16 at 17:57, wrote:
> > @@ -1383,15 +1382,25 @@ int __init construct_dom0(
> > nr_pages);
> > }
> >
> > -if ( is_pvh_domain(d) )
> > -hap_set_alloc_for_pvh_dom0(d, dom0_paging_p
On 27/09/16 11:08, Gerd Hoffmann wrote:
> Hi,
>
>> struct usbback_info {
>> struct XenDevice xendev; /* must be first */
>> +char id[24];
>> +struct USBBACKDevice *dev;
>> USBBus bus;
>> void *urb_srin
On 27/09/16 11:00, Daniel P. Berrange wrote:
> On Mon, Sep 26, 2016 at 02:43:57PM +0200, Juergen Gross wrote:
>> In order to be able to specify to which pvusb controller a new pvusb
>> device should be added we need a qemu device for each pvusb controller
>> with an associated id.
>>
>> Add such a
On 27/09/16 10:53, Gerd Hoffmann wrote:
> On Mo, 2016-09-26 at 14:43 +0200, Juergen Gross wrote:
>> Add a bus for Xen backend devices in order to be able to establish a
>> dedicated device path for pluggable devices.
>
> Looks sane to me. Can take this through the usb queue if I get an ack
> from
On 27/09/16 10:51, Gerd Hoffmann wrote:
> On Mo, 2016-09-26 at 14:43 +0200, Juergen Gross wrote:
>> Trying to use pvUSB in a Xen guest with a qemu emulated USB controller
>> will crash qemu as it tries to attach a pvUSB device to the emulated
>> controller.
>
> Hmm. --verbose please.
>
> While t
On Thu, Sep 29, 2016 at 04:43:07AM -0600, Jan Beulich wrote:
> >>> On 27.09.16 at 17:56, wrote:
> > --- a/xen/arch/x86/mm/hap/hap.c
> > +++ b/xen/arch/x86/mm/hap/hap.c
> > @@ -379,7 +379,9 @@ hap_set_allocation(struct domain *d, unsigned long
> > pages, int *preempted)
> > break;
> >
On Thu, Sep 29, 2016 at 04:39:02AM -0600, Jan Beulich wrote:
> >>> On 27.09.16 at 17:56, wrote:
> > Return should be an int, and the number of pages should be an unsigned long.
>
> I can see the former, but why the latter? Acting on 32-bit quantities
> is a little cheaper after all.
This was req
>>> On 27.09.16 at 17:57, wrote:
> +static bool emulation_flags_ok(const struct domain *d, uint32_t emflags)
> +{
> +
> +if ( is_hvm_domain(d) )
> +{
> +if ( is_hardware_domain(d) &&
> + emflags !=
> (XEN_X86_EMU_PIT|XEN_X86_EMU_LAPIC|XEN_X86_EMU_IOAPIC))
> +
>>> On 27.09.16 at 17:57, wrote:
> The current code used by Intel VTd will only map RMRR regions for the
> hardware domain, but will fail to map RMRR regions for unprivileged domains
> unless the page tables are shared between EPT and IOMMU.
Okay, if that's the case it surely should get fixed.
>
On Wed, Sep 28, 2016 at 10:03:21AM -0600, Jan Beulich wrote:
> >>> On 27.09.16 at 17:56, wrote:
> > On PVHv2 guests we explicitly want to use native methods for routing
> > interrupts.
> >
> > Introduce a new XEN_X86_EMU_USE_PIRQ to notify Xen whether a HVM guest can
> > route physical interrupts
>>> On 27.09.16 at 17:57, wrote:
> Instead of being tied to the presence of an IOMMU
At the very least I'd expect the "why" aspect to get mentioned
here.
> --- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
> +++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
> @@ -219,7 +219,8 @@ int __init amd_i
As long as t_info_first_offset is calculated in uint32_t offsets we need to
multiply it by sizeof(uint32_t) in order to get the right number of pages
for trace metadata. Not doing that makes it impossible to read the trace
buffer correctly from userspace for some corner cases.
Signed-off-by: Igor
>>> On 27.09.16 at 17:57, wrote:
> So that it can also be used by the PVH-specific domain builder. This is just
> code motion, it should not introduce any functional change.
>
> Signed-off-by: Roger Pau Monné
Looks generally okay, but please do minor style corrections as you
move code:
> --- a
flight 101197 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101197/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 101076
test-amd64-i386-xl-qemuu
Hello,
My name is Jason Dickens and I'm a Research Scientist here at
GrammaTech. Some of our research involves securing hypervisors and we
have needed to add to and/or modify Xen. I have been successful in
modifying the source for various purposes, but my question now is about
devices. We hav
This run is configured for baseline tests only.
flight 67782 xen-4.6-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67782/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-multivcpu 6 xen-boot
There's no 1-byte operand size case to take care of here, and there's
no point doing the first writeback using dst fields - we can read rBP
and write rSP directly.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -3130,21 +31
Commit a3db233ede ("x86emul: use DstEax also for {,I}{MUL,DIV}") went
a little too far: DstEax and SrcEax weren't really meant to be used
together with ModRM - they assume modrm_reg remains zero by the time
the destination / source register pointer gets calculated. Don't fully
undo that commit thou
On Wed, Sep 28, 2016 at 09:35:21AM -0600, Jan Beulich wrote:
> >>> On 27.09.16 at 17:56, wrote:
> > This is also required for PVHv2 guests if they want to use real-mode, and
> > hvmloader is not executed for those kind of guests.
>
> While the intention is fine, I'm not convinced of consuming yet
flight 67783 distros-debian-wheezy real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67783/
Perfect :-)
All tests in this flight passed as required
baseline version:
flight 67745
jobs:
build-amd64 pass
build-armh
flight 101207 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101207/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
On Thu, Sep 29, 2016 at 10:08:30AM +0200, Daniel Kiper wrote:
> On Thu, Sep 29, 2016 at 01:40:44AM -0600, Jan Beulich wrote:
> > >>> On 29.09.16 at 00:51, wrote:
> > > v8 - suggestions/fixes:
> > >- disable whole ebmalloc machinery on ARM platforms,
> >
> > This is certainly not in line with m
>>> On 29.09.16 at 11:34, wrote:
On 29.09.16 at 11:11, wrote:
>> The commit a3db233 x86emul: use DstEax also for {,I}{MUL,DIV}
>> introduces an regression when doing SR-IOV passthrough.
>
> I'll see if I can repro,
Actually, I can see some variant of this (and without any SR-IOV), as
soon
On 17/08/16 18:19, Dario Faggioli wrote:
> For get_fallback_cpu(), by putting in place the "usual"
> two steps (soft affinity step and hard affinity step)
> loop. We just move the core logic of the function inside
> the body of the loop itself.
>
> For csched2_cpu_pick(), what is important is to f
1 - 100 of 129 matches
Mail list logo
