date:20190306

Re: [Xen-devel] [libvirt] domXML modeling question

2019-03-06 Thread Daniel P . Berrangé

On Mon, Mar 04, 2019 at 04:42:32PM -0700, Jim Fehlig wrote:
> Adding xen-devel to cc in case anyone there wants to comment on my latest
> proposal...
> 
> On 2/20/19 5:20 PM, Jim Fehlig wrote:
> > There have been a few requests [1][2] to support Xen's max_grant_frames
> > setting in libvirt domXML, but I'm not quite sure how to model it. The
> > documentation [3] on this setting states:
> > 
> > Specify the maximum number of grant frames the domain is allowed to have.  
> > This
> > value controls how many pages the domain is able to grant access to for 
> > other
> > domains, needed e.g. for the operation of paravirtualized devices.  The 
> > default
> > is settable via xl.conf(5).
> 
> I've sent a patch to introduce an analogous default in the libvirt libxl 
> driver
> 
> https://www.redhat.com/archives/libvir-list/2019-March/msg00123.html
> 
> > 
> > It smells of a  setting, e.g. the amount of memory a domain can
> > share, but doesn't map to any of the existing settings. A new subelement
> >  doesn't feel right. Does anyone suggest a better way of
> > modeling max_grant_frames?
> 
> After discussing the max_grant_frames setting a bit more with Juergen I had
> the idea to model it as IO buffer space (or DMA space) of a xenbus
> "controller". All PV devices in the guest connect to the xenbus controller
> and make use of the available I/O buffer space. Guests with more PV devices
> requiring more buffer can increase the space on the xenbus controller
> device.
> 
> One small wrinkle in this idea is that we currently don't model xenbus in
> libvirt. I'd need to add support for a new xenbus controller type and start
> implicitly creating it when creating guests with PV devices, similar to
> auto-creation of controllers in the qemu driver. Also, there is no existing
> controller setting for specifying buffer space. Perhaps a 'ram' attribute
> could be added, similar to specifying memory for  devices? E.g.
> 
>   
> 
> Any opinion on this approach? Or other ideas for modeling this setting
> in libvirt?

Regardless of max grant frames support I think modeling xenbus as a
 is a reasonable thing to want to do. I don't have a
preference on whether you call it "ram" or explicitly "maxGrantFrames"
as an attribute.


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] Can someone pls repair patchwork?

2019-03-06 Thread Oleksandr Andrushchenko


To whom it may concern

Since late 2017 the very useful Patchwork resource [1]
stopped working after (as I assume) Xen-devel list has changed
its address from xen-de...@lists.xen.org to the current one.
Patchwork is still configured to the old one, so recent
patches are not archived.
Could the respective owner from Xen community please take a look at [2]
and make Patchwork work again? In particular Patchwork is
very useful when you need a patch in mbox format without pain.

Thank you,
Oleksandr

[1] https://patchwork.kernel.org/project/xen-devel/list/
[2] https://patchwork.kernel.org/project/xen-devel/

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [xen-unstable-coverity test] 133615: all pass - PUSHED

2019-03-06 Thread osstest service owner

flight 133615 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133615/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 xen  eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3
baseline version:
 xen  f393b82fe5ba3ed9cfe2b306ffa53368e55b75af

Last test of basis   133557  2019-03-03 09:30:21 Z3 days
Testing same since   133615  2019-03-06 09:18:51 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  George Dunlap 
  Ian Jackson 
  Jan Beulich 
  Juergen Gross 
  Manuel Bouyer 
  Roger Pau Monné 
  Sergey Dyasli 
  Wei Liu 

jobs:
 coverity-amd64   pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   f393b82fe5..eeb31ee522  eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3 -> 
coverity-tested/smoke

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Xen ARM GPU passthrough without IOMMU

2019-03-06 Thread Andrii Anisov

Hello Jinch,

On 05.03.19 15:35, Jinch wrote:

Thank you for your reply,
Now I can set the disk and some basic devices to run Android domu to console,
The main issue is the display GUI of Android.

Here you should distinguish clearly display subsystem and 3D rendering engine.
Yet you need them both for your Android showing you something.
We have a quite generic PV DRM implementation, both FE and BE, which is called
to serve as a display subsystem.
But 3D rendering is really vendor specific, and no generic approach
implementation is known to me. Except software rendering for sure:)

You might look at the hwcomposer we are using in our setup [1], but it is
still IMG specific in terms of 3D.

I can use the drm PV drivers at https://github.com/xen-troops/displ_be to set
the drm driver,
Or the next step is to research how to set drm device passthrough.

Sorry I didn't get that clearly. Do you say that you managed to bringup PV DRM
for Android? Or it is your next step? And why do you say about DRM passthrough?

But the imxqxp board I use doesn’t have IOMMU, the GPU passthrough may have
some problems.

I guess you should ask your GPU vendor about their virtualization solution
first. That might give you a clue how can you provide your GPU access to other
VM address space.
On our side we requested hypervisor to translate IPA to PA [2], and then fed
those addresses to GPU from its driver. We do that for buggy silicon revision
where GPU's IOMMU does not work.
Yet it makes more boards available for development, rather than for production.

Do you have some tutorials about how to set display and GUI when running
Android as domu?

You might grab more information about PV DRM here [3].
XEN vdispl configuration you will find here [4].
Setting up Android display and GUI - you will not find any tutorials. You need
your hwcomposer and gralloc which are 3D vendor specific, so contact your
vendor.

[1]
https://github.com/xen-troops/android_external_drm_hwcomposer/commits/android-9.0.0_r3-xt0.2
[2] https://github.com/xen-troops/xen/blob/master/xen/arch/arm/mm.c#L1332
[3] https://lwn.net/Articles/750258/
[4] https://xenbits.xen.org/docs/unstable-staging/man/xl.cfg.5.html#Devices

--
Sincerely,
Andrii Anisov.

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Can someone pls repair patchwork?

2019-03-06 Thread Julien Grall


(+ Lars)

On 06/03/2019 10:04, Oleksandr Andrushchenko wrote:

To whom it may concern


Hi Oleksandr,



Since late 2017 the very useful Patchwork resource [1]
stopped working after (as I assume) Xen-devel list has changed
its address from xen-de...@lists.xen.org to the current one.
Patchwork is still configured to the old one, so recent
patches are not archived.
Could the respective owner from Xen community please take a look at [2]
and make Patchwork work again? In particular Patchwork is
very useful when you need a patch in mbox format without pain.


Patchwork is hosted by the kernel community. So it would be best if you contact 
them directly. [3].


Cheers,


[1] https://patchwork.kernel.org/project/xen-devel/list/
[2] https://patchwork.kernel.org/project/xen-devel/


[3] https://www.kernel.org/category/contact-us.html

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] Intel TXT maintainter update

2019-03-06 Thread Hawrylko, Lukasz

Due to personal changes at Intel, I am new TXT maintainer for XEN.
Adding patch that updates maintainers list.

Thanks,
Lukasz
diff --git a/MAINTAINERS b/MAINTAINERS
index a0cda4f7a1..4c47294706 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -237,7 +237,7 @@ F:	xen/arch/x86/debug.c
 F:	tools/debugger/gdbsx/
 
 INTEL(R) TRUSTED EXECUTION TECHNOLOGY (TXT)
-M:	Gang Wei 
+M:	Lukasz Hawrylko 
 M:	Shane Wang 
 S:	Supported
 F:	xen/arch/x86/tboot.c


smime.p7s
Description: S/MIME cryptographic signature


Intel Technology Poland sp. z o.o.
ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wydzial 
Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-316 | 
Kapital zakladowy 200.000 PLN.

Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata i 
moze zawierac informacje poufne. W razie przypadkowego otrzymania tej 
wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie; 
jakiekolwiek
przegladanie lub rozpowszechnianie jest zabronione.
This e-mail and any attachments may contain confidential material for the sole 
use of the intended recipient(s). If you are not the intended recipient, please 
contact the sender and delete all copies; any review or distribution by
others is strictly prohibited.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v3 8/9] viridian: add implementation of synthetic timers

2019-03-06 Thread Paul Durrant

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 25 February 2019 14:54
> To: Paul Durrant 
> Cc: Julien Grall ; Andrew Cooper 
> ; Roger Pau Monne
> ; Wei Liu ; George Dunlap 
> ; Ian
> Jackson ; Stefano Stabellini 
> ; xen-devel  de...@lists.xenproject.org>; Konrad Rzeszutek Wilk ; 
> Tim (Xen.org)
> 
> Subject: Re: [PATCH v3 8/9] viridian: add implementation of synthetic timers
> 
> >>> On 31.01.19 at 11:47,  wrote:
> > --- a/xen/arch/x86/hvm/viridian/synic.c
> > +++ b/xen/arch/x86/hvm/viridian/synic.c
> > @@ -329,7 +329,53 @@ void viridian_synic_domain_deinit(struct domain *d)
> >
> >  void viridian_synic_poll_messages(struct vcpu *v)
> >  {
> > -/* There are currently no message sources */
> > +viridian_time_poll_timers(v);
> > +}
> > +
> > +bool viridian_synic_deliver_timer_msg(struct vcpu *v, unsigned int sintx,
> > +  unsigned int index,
> > +  int64_t expiration, int64_t delivery)
> > +{
> > +const union viridian_sint_msr *vs = &v->arch.hvm.viridian->sint[sintx];
> > +HV_MESSAGE *msg = v->arch.hvm.viridian->simp.ptr;
> > +struct {
> > +uint32_t TimerIndex;
> > +uint32_t Reserved;
> > +uint64_t ExpirationTime;
> > +uint64_t DeliveryTime;
> > +} payload = {
> > +.TimerIndex = index,
> > +.ExpirationTime = expiration,
> > +.DeliveryTime = delivery,
> > +};
> > +
> > +if ( test_bit(sintx, &v->arch.hvm.viridian->msg_pending) )
> > +return false;
> > +
> > +BUILD_BUG_ON(sizeof(*msg) != HV_MESSAGE_SIZE);
> > +msg += sintx;
> > +
> > +/*
> > + * To avoid using an atomic test-and-set this function must be called
> > + * in context of the vcpu receiving the message.
> > + */
> > +ASSERT(v == current);
> > +if ( msg->Header.MessageType != HvMessageTypeNone )
> > +{
> > +msg->Header.MessageFlags.MessagePending = 1;
> > +set_bit(sintx, &v->arch.hvm.viridian->msg_pending);
> 
> As per the comment above this is always in context of the subject
> vCPU. It looks to me as if this was also the case for the two
> clear_bit() on the field in the prior patch. If so, all three could be
> the non-atomic variants instead.

The only slight subtlety I think is the one in the wrmsr function, which can be 
called in context of a domain restore. I think it's still ok for it to be 
non-atomic in this case but I'll assert (v = current || !v->running), which I 
think should cover it.

> 
> > +return false;
> > +}
> > +
> > +msg->Header.MessageType = HvMessageTimerExpired;
> > +msg->Header.MessageFlags.MessagePending = 0;
> > +msg->Header.PayloadSize = sizeof(payload);
> > +memcpy(msg->Payload, &payload, sizeof(payload));
> > +
> > +if ( !vs->fields.mask )
> > +vlapic_set_irq(vcpu_vlapic(v), vs->fields.vector, 0);
> 
> If this wasn't with v == current, I think you'd also need a barrier
> here. Could you extend the comment above to also mention this
> aspect?

Ok.

> 
> > @@ -118,14 +119,237 @@ static int64_t time_ref_count(struct domain *d)
> >  return raw_trc_val(d) + trc->off;
> >  }
> >
> > +static int64_t time_now(struct domain *d)
> 
> Why would this return a signed value? And can't the function
> parameter be const?

The function parameter can be const, but I think the result needs to be signed 
for the missed ticks logic in start_timer() to work correctly.

> 
> > +{
> > +const struct viridian_page *rt = &d->arch.hvm.viridian->reference_tsc;
> > +HV_REFERENCE_TSC_PAGE *p = rt->ptr;
> > +uint32_t start, end;
> > +__int128_t tsc;
> > +__int128_t scale;
> 
> I don't think you need both of them be 128 bits wide. I also don't
> see why either would want to be of a signed type.

The spec says (as in the comment below):

"The partition reference time is computed by the following formula:

ReferenceTime = ((VirtualTsc * TscScale) >> 64) + TscOffset

The multiplication is a 64 bit multiplication, which results in a 128 bit 
number which is then shifted 64 times to the right to obtain the high 64 
bits.TscScale"

Again, I'm using signed arithmetic as I think it's necessary for the missed 
ticks logic to work correctly in the event of an overflow.

> 
> > +int64_t offset;
> > +
> > +/*
> > + * If the reference TSC page is not enabled, or has been invalidated
> > + * fall back to the partition reference counter.
> > + */
> > +if ( !p || !p->TscSequence )
> > +return time_ref_count(d);
> > +
> > +/*
> > + * The following sampling algorithm for tsc, scale and offset is
> > + * documented in the specifiction.
> > + */
> > +start = p->TscSequence;
> > +
> > +do {
> > +tsc = rdtsc();
> > +scale = p->TscScale;
> > +offset = p->TscOffset;
> > +
> > +smp_mb();
> > +end = p->TscSequence;
> 
> Why is this a full barrier, rather than just

Re: [Xen-devel] [PATCH 0/6] iomem cacheability

2019-03-06 Thread Amit Tomer

Hi
> Thanks for testing! You might have found a real bug in the series. Could
> you please also attach the full device tree?

Please find the attached DTS and DTB file used for testing.

Thanks
-Amit


r8a7795-h3ulcb.dts
Description: audio/vnd.dts


r8a7795-h3ulcb.dtb
Description: Binary data
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

90 matches

Mail list logo