Re: [Xen-devel] [PATCH RFC 13/18] xen: introduce and use 'dom0_rambase_pfn' setting for kernel Dom0

[Oleksandr Dmytryshyn]

On Fri, May 20, 2016 at 7:05 PM, Edgar E. Iglesias
 wrote:
> Hi,
>
> We have similar needs (not exactly the same) in some of our setups.
> We need to map certain OCMs (On Chip Memories) to dom0. Among other things,
> these are used to communicate with remote accelerators/CPUs that have
> "hardcoded" addresses to these RAMs.
>
> Our approach is more along the lines of Juliens second suggestion. We're
> trying to use the mmio-sram DTS bindings to bring in these memories into
> dom0.
>
> IIUC the Ducati FW issue correctly, you need to allocate a chunk of DDR.
>
> Another possible solution:
> I think you could reserve the memory area by simply not mentioning it
> in the main memory node (these nodes support multiple ranges so you can
> introduce gaps). Then you could for example create an mmio-sram node to
> get the memory explicitely mapped 1:1 into dom0.
>
> Just a moment ago, I posted an RFC for the mmio-sram support to the list.
Hi, Edgar.

How do You access to the mapped OCMs in dom0?
Are genalloc-related functions (gen_pool_get/_alloc/_virt_to_phys)
only way to work with mmio-sram memory?

> Cheers,
> Edgar
>
>
>>
>> Regards,
>>
>> [1]
>> http://lists.xenproject.org/archives/html/xen-devel/2016-05/msg01879.html
>> [2]
>> http://lists.xenproject.org/archives/html/xen-devel/2016-05/msg01894.html
>>
>> --
>> Julien Grall
>>
>> ___
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH RFC 13/18] xen: introduce and use 'dom0_rambase_pfn' setting for kernel Dom0

[Oleksandr Dmytryshyn]

Hi, Edgar.

On Fri, May 20, 2016 at 7:05 PM, Edgar E. Iglesias
 wrote:
> Hi,
>
> We have similar needs (not exactly the same) in some of our setups.
> We need to map certain OCMs (On Chip Memories) to dom0. Among other things,
> these are used to communicate with remote accelerators/CPUs that have
> "hardcoded" addresses to these RAMs.
>
> Our approach is more along the lines of Juliens second suggestion. We're
> trying to use the mmio-sram DTS bindings to bring in these memories into
> dom0.
>
> IIUC the Ducati FW issue correctly, you need to allocate a chunk of DDR.
>
> Another possible solution:
> I think you could reserve the memory area by simply not mentioning it
> in the main memory node (these nodes support multiple ranges so you can
> introduce gaps). Then you could for example create an mmio-sram node to
> get the memory explicitely mapped 1:1 into dom0.
>
> Just a moment ago, I posted an RFC for the mmio-sram support to the list.
Thank You for advice.
I'll try to use Your solution.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH RFC 13/18] xen: introduce and use 'dom0_rambase_pfn' setting for kernel Dom0

[Oleksandr Dmytryshyn]

On Fri, May 20, 2016 at 12:59 PM, Jan Beulich  wrote:
 On 20.05.16 at 10:45,  wrote:
>> On Thu, May 19, 2016 at 5:36 PM, Jan Beulich  wrote:
>> On 19.05.16 at 15:58,  wrote:
 Case 1: Dom0 is driver domain:
 There is a Ducati firmware which runs on dedicated M4 core and decodes
 video. This firmware uses hardcoded physical addresses for graphics
 buffers. Those addresses should be inside address-space of the driver
 domain (Dom0). Ducati firmware is proprietary and we have no ability
 to rework it. So Dom0 kernel should be placed to the configured
 address (to the DOM0 RAM bank with specific address).

 Case 2: Dom0 is Thin and DomD is driver domain.
 All is the same: Ducati firmware requires special (hardcoded) addresses.
>>>
>>> For both of these cases I would then wonder whether such
>>> environments are actually suitable for doing virtualization on.
>> Currently we use Jacinto 6 evaluation board with DRA74X processor.
>> We have both configurations (Thin Dom0 and Thich Dom0).
>
> Which says nothing about their suitability for virtualization.
Our solution is based on Jacinto 6 evaluation board with DRA74X
processor. We need video-playback. Ducati firmware decodes video and
it works only with hardcoded addresses so we need this patch.

> Jan
>

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH RFC 13/18] xen: introduce and use 'dom0_rambase_pfn' setting for kernel Dom0

[Oleksandr Dmytryshyn]

On Thu, May 19, 2016 at 5:36 PM, Jan Beulich  wrote:
 On 19.05.16 at 15:58,  wrote:
>> Case 1: Dom0 is driver domain:
>> There is a Ducati firmware which runs on dedicated M4 core and decodes
>> video. This firmware uses hardcoded physical addresses for graphics
>> buffers. Those addresses should be inside address-space of the driver
>> domain (Dom0). Ducati firmware is proprietary and we have no ability
>> to rework it. So Dom0 kernel should be placed to the configured
>> address (to the DOM0 RAM bank with specific address).
>>
>> Case 2: Dom0 is Thin and DomD is driver domain.
>> All is the same: Ducati firmware requires special (hardcoded) addresses.
>
> For both of these cases I would then wonder whether such
> environments are actually suitable for doing virtualization on.
Currently we use Jacinto 6 evaluation board with DRA74X processor.
We have both configurations (Thin Dom0 and Thich Dom0).

> Jan
>

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH RFC 13/18] xen: introduce and use 'dom0_rambase_pfn' setting for kernel Dom0

[Oleksandr Dmytryshyn]

Oleksandr Dmytryshyn | Product Engineering and Development
GlobalLogic
M +38.067.382.2525
www.globallogic.com

http://www.globallogic.com/email_disclaimer.txt


On Thu, May 19, 2016 at 5:34 PM, Julien Grall <julien.gr...@arm.com> wrote:
> Hello Oleksandr,
>
>
> On 19/05/16 14:58, Oleksandr Dmytryshyn wrote:
>>>
>>> Why would a user want to allocate DOM0 RAM bank to a specific address?
>>>
>>> If I understand correctly your patch, DOM0 will only able to allocate one
>>> bank of the given size at the specific address. You also add this
>>> possibility for guest domain (see patch #4) and try to control where the
>>> guest memory will be allocated. This will increase a lot the chance of the
>>> memory allocation to fail.
>>>
>>> For instance, the RAM region requested for DOM0 may have been used to
>>> allocate memory for Xen internal. So you need a way to reserve memory in
>>> order to avoid Xen using it.
>>>
>>> I expect most of the users who want to use direct memory mapped guest to
>>> know the number of guests which will use this feature.
>>>
>>> A such feature is only useful when pass-through a device to the guest on
>>> platfom without SMMU, so it is by default insecure.
>>>
>>> So I would suggest to create a new device-tree binding (or re-use an
>>> actual one) to reserve memory region to be used for direct memory mapped
>>> domain.
>>>
>>> Those regions could have an identifier to be used later during the
>>> allocation. This would avoid memory fragmentation, allow multiple RAM bank
>>> for DOM0,...
>>>
>>> Any opinions?
>>
>>
>> Case 1: Dom0 is driver domain:
>> There is a Ducati firmware which runs on dedicated M4 core and decodes
>> video. This firmware uses hardcoded physical addresses for graphics
>> buffers. Those addresses should be inside address-space of the driver
>> domain (Dom0). Ducati firmware is proprietary and we have no ability
>> to rework it. So Dom0 kernel should be placed to the configured
>> address (to the DOM0 RAM bank with specific address).
>>
>> Case 2: Dom0 is Thin and DomD is driver domain.
>> All is the same: Ducati firmware requires special (hardcoded) addresses.
>
>
> So if I understand correctly, patches #4, #13, #16 are only here to
> workaround a firmware which does not do the right thing?
>
> IHMO, modifying the memory allocator in Xen to make a firmware happy is just
> overkill. We need to explore all the possible solutions before going
> forward.
Yes, You are right. This patch written to make a firmware happy.

> From your description, it looks like to me that the device-tree does not
> correctly describe the platform. The graphic buffers should be reserved
> using /memreserve or via a specific binding.
>
> This would be used later by Xen to map the buffer into dom0 or allow dom0 to
> map it to a guest.
>
> Regards,
>
> --
> Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH RFC 13/18] xen: introduce and use 'dom0_rambase_pfn' setting for kernel Dom0

[Oleksandr Dmytryshyn]

> Why would a user want to allocate DOM0 RAM bank to a specific address?
>
> If I understand correctly your patch, DOM0 will only able to allocate one 
> bank of the given size at the specific address. You also add this possibility 
> for guest domain (see patch #4) and try to control where the guest memory 
> will be allocated. This will increase a lot the chance of the memory 
> allocation to fail.
>
> For instance, the RAM region requested for DOM0 may have been used to 
> allocate memory for Xen internal. So you need a way to reserve memory in 
> order to avoid Xen using it.
>
> I expect most of the users who want to use direct memory mapped guest to know 
> the number of guests which will use this feature.
>
> A such feature is only useful when pass-through a device to the guest on 
> platfom without SMMU, so it is by default insecure.
>
> So I would suggest to create a new device-tree binding (or re-use an actual 
> one) to reserve memory region to be used for direct memory mapped domain.
>
> Those regions could have an identifier to be used later during the 
> allocation. This would avoid memory fragmentation, allow multiple RAM bank 
> for DOM0,...
>
> Any opinions?

Case 1: Dom0 is driver domain:
There is a Ducati firmware which runs on dedicated M4 core and decodes
video. This firmware uses hardcoded physical addresses for graphics
buffers. Those addresses should be inside address-space of the driver
domain (Dom0). Ducati firmware is proprietary and we have no ability
to rework it. So Dom0 kernel should be placed to the configured
address (to the DOM0 RAM bank with specific address).

Case 2: Dom0 is Thin and DomD is driver domain.
All is the same: Ducati firmware requires special (hardcoded) addresses.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] Question about mapping between domains

[Oleksandr Dmytryshyn]

On Fri, Jul 17, 2015 at 11:59 AM, Ian Campbell ian.campb...@citrix.com wrote:
 Does this mean everything is working as you need, or is there a further
 issue which needs addressing?
All is working as needed. Thank You.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] Question about mapping between domains

[Oleksandr Dmytryshyn]

Hi, Ian. Thank You for tips.

On Mon, Jul 13, 2015 at 12:04 PM, Ian Campbell ian.campb...@citrix.com wrote:
 There is an additional quirk for a 1:1 mapped dom0 which is that we
 don't actually decrease reservation when ballooning, but keep the 1:1
 mfn in anticipation of ballooning it back in later.
Currently we have this quirk enabled in DomD (driver domain)

 If you can't arrange to use already ballooned buffers for your DMA
 buffer then you will need to manually balloon it out before and balloon
 it back in later.
I've tried this and all is working (I can map and then unmap memory in both
directions DomU - DomD, DomD - DomU)

 You may also want to extend the dom0 1:1 quirk described above to your
 1:1 mapped domD.
Currently this quirk is enabled in DomD. In this case I can map memory from
DomU to DomD (as it done in all PV drivers). But is this quirk is
enabled in DomU,
I can also map memory from DomD to DomU.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] Question about mapping between domains

[Oleksandr Dmytryshyn]

Hi, Ian. Thank You for the response.

 Look at how the balloon driver does it, the hypercalls you want are
 XENMEM_(increase|decrease)_reservation.
I'll try to use those hypercalls.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] Question about mapping between domains

[Oleksandr Dmytryshyn]

Hi, Ian. Thank You for the responce.

Currently have 3 kernels: Thin Dom0 (privileged), DomD (privileged
driver domain),
DomU (not privileged)

On Mon, Jul 13, 2015 at 12:04 PM, Ian Campbell ian.campb...@citrix.com wrote:
 The way we deal with this elsewhere in the kernel is that we only ever
 do grant mappings over ballooned out pages, which are allocated via
 gnttab_alloc_pages. That way when they are unmapped the page is expected
 to be entry and no backing mfn is lost. The page can then subsequently
 be ballooned back in as normal.
We can not use this case because our DRM driver has already allocated memory
which will be mapped later.

 There is an additional quirk for a 1:1 mapped dom0 which is that we
 don't actually decrease reservation when ballooning, but keep the 1:1
 mfn in anticipation of ballooning it back in later.
Could You please tell me a bit more information about this quirk. How this quirk
can be enabled?

 If you can't arrange to use already ballooned buffers for your DMA
 buffer then you will need to manually balloon it out before and balloon
 it back in later.
This is my case. I'll try to to this.

 You may also want to extend the dom0 1:1 quirk described above to your
 1:1 mapped domD.
Necessarily I will do this.

 If you have sufficient control over/knowledge of the domD IPA space then
 you could also try and arrange that the region used for these mappings
 does not correspond to any real RAM in the guest (i.e. stick it in an
 MMIO hole). That depends on you never needing to find an associated
 struct page though, which will depend on your use case.
Necessarily I will do this.

 Ian.


Oleksandr Dmytryshyn | Product Engineering and Development
GlobalLogic
M +38.067.382.2525
www.globallogic.com

http://www.globallogic.com/email_disclaimer.txt

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] Question about mapping between domains

[Oleksandr Dmytryshyn]

On Tue, Jul 14, 2015 at 6:31 PM, Oleksandr Dmytryshyn
oleksandr.dmytrys...@globallogic.com wrote:

 Hi, Ian. Thank You for the responce.

 Currently have 3 kernels: Thin Dom0 (privileged), DomD (privileged
 driver domain),
 DomU (not privileged)

 On Mon, Jul 13, 2015 at 12:04 PM, Ian Campbell ian.campb...@citrix.com 
 wrote:
  The way we deal with this elsewhere in the kernel is that we only ever
  do grant mappings over ballooned out pages, which are allocated via
  gnttab_alloc_pages. That way when they are unmapped the page is expected
  to be entry and no backing mfn is lost. The page can then subsequently
  be ballooned back in as normal.
 We can not use this case because our DRM driver has already allocated memory
 which will be mapped later.

  There is an additional quirk for a 1:1 mapped dom0 which is that we
  don't actually decrease reservation when ballooning, but keep the 1:1
  mfn in anticipation of ballooning it back in later.
 Could You please tell me a bit more information about this quirk. How this 
 quirk
 can be enabled?

  If you can't arrange to use already ballooned buffers for your DMA
  buffer then you will need to manually balloon it out before and balloon
  it back in later.
 This is my case. I'll try to to this.
Here is one question.
Could anybody tell me how to manually balloon a page in/out?

  You may also want to extend the dom0 1:1 quirk described above to your
  1:1 mapped domD.
 Necessarily I will do this.

  If you have sufficient control over/knowledge of the domD IPA space then
  you could also try and arrange that the region used for these mappings
  does not correspond to any real RAM in the guest (i.e. stick it in an
  MMIO hole). That depends on you never needing to find an associated
  struct page though, which will depend on your use case.
 Necessarily I will do this.

  Ian.
 

 Oleksandr Dmytryshyn | Product Engineering and Development
 GlobalLogic
 M +38.067.382.2525
 www.globallogic.com

 http://www.globallogic.com/email_disclaimer.txt

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] Question about mapping between domains

[Oleksandr Dmytryshyn]

Hi to all.

I'm trying to map and then unmap some memory from one domain to another.
For example from DomU to DomD. DomU - not privileged domain, DomD - privileged
(driver domain). And DomD is mapped 1:1. I use a typical way - allocate grant
references and claim forein access in the DomU and map by grant references in 
the 
DomD. Then I unmap mapped memory.

I want to map/unmap memory to existing buffer in DomD. And this map/unmap 
procedure
should be done a lot of times. I've used virtual block device (VBD) driver as
reference. But there is a difference in compare to the VBD driver. I use
a buffer which was allocated previously in another driver (in DRM driver).
I need to map a DRM dumb buffer from DomU to DomD. VBD backend driver uses
pages taken from __get_free_pages().

Here is my mapping code (in DomD):

/* map dumb fb */
paddr = cma_obj-paddr;
for (i = 0; i  n_mfns; i++) {
cur_pfn = __phys_to_pfn(paddr);
vaddr = (unsigned long)pfn_to_kaddr(cur_pfn);

pages_mfns[i] = pfn_to_page(cur_pfn);

gnttab_set_map_op(map_mfns[i], vaddr, GNTMAP_host_map,
gnt_mfns[i], args-fe_domid);

paddr += PAGE_SIZE;
}
ret = gnttab_map_refs(map_mfns, NULL, pages_mfns, n_mfns);
BUG_ON(ret);

Where 'cma_obj' is real object allocated in the DRM driver.

After mapping all works fine.

Here is my unmapping code (in DomD):

paddr = cma_obj-paddr;
cur_idx = 0;
for (i = 0; i  n_mfns; i++) {
if (handles_mfns[i] == DRMFRONT_INVALID_HANDLE) {
/* for now */
dev_err(dev-dev,
invalid handle[%d] -- could not use it\n, i);
continue;
}

gnttab_set_unmap_op(unmap_mfns[cur_idx],
(unsigned long)phys_to_virt(paddr),
GNTMAP_host_map,
handles_mfns[i]);

handles_mfns[i] = DRMFRONT_INVALID_HANDLE;

cur_idx++;
paddr += PAGE_SIZE;

if (cur_idx == MAX_MAP_OP_COUNT || i == n_mfns - 1) {
ret = gnttab_unmap_refs(unmap_mfns, NULL,
pages_mfns[i + 1 - cur_idx],
cur_idx);
BUG_ON(ret);

cur_idx = 0;
}
}


The next crash appeared after unmap (in DomD):

Unhandled fault: terminal exception (0x002) at 0xcdbfb000
Internal error: : 2 [#1] PREEMPT SMP ARM
CPU: 1 PID: 853 Comm: drmback Not tainted 
3.14.33-0-ivi-arm-rcar-m2-rt31-00060-g653c5ff-dirty #173
task: cfa9d800 ti: ce298000 task.ti: ce298000
PC is at __copy_from_user+0xcc/0x3b0
LR is at 0x6
pc : [c019e73c]lr : [0006]psr: 0013
sp : ce299ef4  ip : 001c  fp : ce299f44
r10: b652e9a4  r9 : ce298000  r8 : 0004
r7 : cdbfb000  r6 : cfaa3580  r5 : b652e9a4  r4 : 0004
r3 :   r2 : ffe4  r1 : b652e9a8  r0 : cdbfb000
Flags: nzcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
Control: 10c5307d  Table: 5e23806a  DAC: 0015
Process drmback (pid: 853, stack limit = 0xce298240)
Stack: (0xce299ef4 to 0xce29a000)
9ee0:  b652e9a4 cfaa3580 cdbfb000
9f00: 0004 cdbfb000 0004  0004 c01efdec ce299f78 ce228700
9f20: 0004 b652e9a4 ce299f78 0004 ce298000 b652e9a4 ce299f74 ce299f48
9f40: c00ca158 c01efd88 c00e339c c00e28d8   ce228700 ce228701
9f60: 0004 b652e9a4 ce299fa4 ce299f78 c00ca2cc c00ca094  
9f80: 00018208 0001 b652eb2c 0004 c000f944   ce299fa8
9fa0: c000f7c0 c00ca294 00018208 0001 0006 b652e9a4 0004 b652e9a4
9fc0: 00018208 0001 b652eb2c 0004 0002   b652e9bc
9fe0:  b652e998 b6ea0f94 b6ea0fa4 8010 0006 18140681 076136f5
Backtrace: 
[c01efd7c] (evtchn_write) from [c00ca158] (vfs_write+0xd0/0x17c)
 r10:b652e9a4 r9:ce298000 r8:0004 r7:ce299f78 r6:b652e9a4 r5:0004
 r4:ce228700 r3:ce299f78
[c00ca088] (vfs_write) from [c00ca2cc] (SyS_write+0x44/0x84)
 r10:b652e9a4 r8:0004 r7:ce228701 r6:ce228700 r5: r4:
[c00ca288] (SyS_write) from [c000f7c0] (ret_fast_syscall+0x0/0x30)
 r10: r8:c000f944 r7:0004 r6:b652eb2c r5:0001 r4:00018208
Code: e4803004 e4804004 e4805004 e4806004 (e4807004) 
---[ end trace 0002 ]---
[ cut here ]
Unhandled fault: terminal exception (0x002) at 0xcd7fc000
Internal error: : 2 [#2] PREEMPT SMP ARM
CPU: 1 PID: 852 Comm: drmback Tainted: G  D W
3.14.33-0-ivi-arm-rcar-m2-rt31-00060-g653c5ff-dirty #173

Re: [Xen-devel] [Embedded-pv-devel] [PATCH v6] sndif: add ABI for Para-virtual sound

[Oleksandr Dmytryshyn]

Hi, Stefano.

Currently we have this configuration:
Dom0, DomD (driver domain), DomU (Android).
Sound driver is inside DomD. Backend uses ALSA for playback/capture.

On Thu, Feb 5, 2015 at 9:47 PM, Stefano Panella
stefano.pane...@citrix.com wrote:
 Hi all,

 First of all I would like to say that:
 - I am happy that PV audio is finding its way into xen and there is active 
 development on it
 - Defining a flexible and future proof PV audio protocol is very hard and 
 will probably take a bit of trial and error in the beginning.
 - I hope I will be able to save some time in the trial and error process 
 sharing a bit of my xen audio related experiences.

 I had a look at the patches sent and even if I am sure they are solving in a 
 practical way a specific use case scenario, the protocol specified does not 
 look general enough in my opinion and it does many assumptions which might or 
 not be acceptable.

 Also I could not find any discussion around the actual design of the protocol 
 including motivations and scope.

 I would like to think one could break the design protocol of a PV driver in 
 different areas where different people can contribute at different levels 
 bringing their particular expertise.

 Anyway, first it would be good to start a discussion around some basic 
 questions and then we could go into more detail.

 - what is the aim of the protocol? Just pipe some sort of sound data from 
 guest and dom0 or expose the guest with a real xen PV soundcard?
The aim is to expose the guest with a real xen PV soundcard.

 - how general/granular/configurable should it be in term of the potentially 
 many and different sound devices present in dom0?
Each sound device in DomD has own name and it is mapped to the selected
sound device of the PV soundcard in the frontend. I'll little rework the stream
mappings description in this protocol in the next patch-set.

 - audio, differently from any other Xen PV driver, is a real-time thing, 
 should this be reflected in the protocol? Most sound driver API require to 
 know when a particular sound sample is played on the Speaker or how old is a 
 sample coming from a Mic (particularly useful for Acoustic Echo Cancellation)
I don't know exactly how reflect it in the protocol. My PV driver adds
additional latency which is comparable to the context switching.

 - Should the protocol allow the backend to publish many capabilities so the 
 frontend can chose how to best use them?
Yes, it should. Maybe this should be added a bit later to the protocol.
At first it will be simple version of the protocol description.

 - how easy/feasible would be to write frontend and backend drivers using the 
 protocol for different OSs?
It is feasible to write backend and frontend drivers.
The main work should be done:
1. Learn how use ALSA to play/capture data (if ALSA is used for backend driver)
2. Learn how to create and use an virtual soundcard in selected OS
(linux, unix, etc.)
3. Learn how use an event channel and shared memory.

 - would the protocol map well with the current major sound driver models and 
 API for the different guest Oss? (linux alsa driver, Windows WaveCiclic or 
 WaveRT etc..)
At least the protocol map would be well with the alsa-like drivers
(Linux, QNX). BTW we've written a test version of the PV sound frontend
which works on the QNX. Unfurtunatelly I don't know about Windows WaveCiclic


 I hope these questions will help moving the conversation in a constructive 
 and productive way for now :)

 Stefano

 -Original Message-
 From: Dario Faggioli [mailto:dario.faggi...@citrix.com]
 Sent: Monday, February 2, 2015 6:52 PM
 To: Oleksandr Dmytryshyn
 Cc: xen-devel@lists.xen.org; embedded-pv-de...@lists.xenproject.org; Iurii 
 Konovalenko; Keir (Xen.org); Ian Campbell; Tim (Xen.org); Ian Jackson; Jan 
 Beulich; Stefano Panella
 Subject: Re: [Embedded-pv-devel] [PATCH v6] sndif: add ABI for Para-virtual 
 sound

 On Thu, 2015-01-29 at 13:01 +0200, Oleksandr Dmytryshyn wrote:
 This is ABI for the two halves of a Para-virtual sound driver to
 communicate with each to other.

 I wonder whether Stefano (Cc-ed), which has a great deal of experience with 
 --real, virtual and paravirtual-- audio, could find a few minutes to have a 
 look and help us here, by saying what he thinks :-)

 Stefano, a bit of context (Oleksandr and Iurii, can add more, if needed, I'm 
 sure):

 http://marc.info/?l=xen-develm=142165575819173
 http://marc.info/?l=xen-develm=142194015107046

 Thanks and Regards,
 Dario

 --
 This happens because I choose it to happen! (Raistlin Majere)
 -
 Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software 
 Engineer, Citrix Systems RD Ltd., Cambridge (UK)


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH v7] sndif: add ABI for Para-virtual sound

[Oleksandr Dmytryshyn]

This is ABI for the two halves of a Para-virtual
sound driver to communicate with each to other.

Signed-off-by: Oleksandr Dmytryshyn oleksandr.dmytrys...@globallogic.com
Signed-off-by: Iurii Konovalenko iurii.konovale...@globallogic.com
---
Changes since v1:
 * removed __attribute__((__packed__)) from all structures definitions

Changes since v2:
 * removed all C structures
 * added protocol description between frontend and backend drivers

Changes since v3:
 * fixed some typos
 * renamed XENSND_PCM_FORMAT_FLOAT_** to XENSND_PCM_FORMAT_F32_**
 * renamed XENSND_PCM_FORMAT_FLOAT64_** to XENSND_PCM_FORMAT_F64_**
 * added 'id' field to the request and response packets
 * renamed 'stream_id' to 'stream' in the packets description
 * renamed 'pcm_data_rate' to 'pcm_rate' in the packets description
 * renamed 'pcm_stream_type' to 'pcm_type' in the packets description
 * removed 'stream_id' field from the response packets

Changes since v4:
 * renamed 'stream_id' back to the to 'stream' in the packets description
 * moved 'id' field to the upper position in the response packets

Changes since v5:
 * Slightly reworked request/response packets
 * Size of the request/response packet is changed to the 64 bytes
 * Now parameters for the XENSND_OP_SET_VOLUME/XENSND_OP_GET_VOLUME are
   passed via shared page
 * Added parameters for the XenBus nodes (now each stream can be mapped
   to the defined sound device in the backend using those parameters)
 * Added XenBus state diagrams description

Changes since v6:
 * Reworked streams description  in the Backend XenBus Nodes

 xen/include/public/io/sndif.h | 429 ++
 1 file changed, 429 insertions(+)
 create mode 100644 xen/include/public/io/sndif.h

diff --git a/xen/include/public/io/sndif.h b/xen/include/public/io/sndif.h
new file mode 100644
index 000..0118cab
--- /dev/null
+++ b/xen/include/public/io/sndif.h
@@ -0,0 +1,429 @@
+/**
+ * sndif.h
+ *
+ * Unified sound-device I/O interface for Xen guest OSes.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the Software), to
+ * deal in the Software without restriction, including without limitation the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Copyright (C) 2013-2015 GlobalLogic Inc.
+ */
+
+#ifndef __XEN_PUBLIC_IO_XENSND_H__
+#define __XEN_PUBLIC_IO_XENSND_H__
+
+/*
+ * Front-back notifications: When enqueuing a new request, sending a
+ * notification can be made conditional on req_event (i.e., the generic
+ * hold-off mechanism provided by the ring macros). Backends must set
+ * req_event appropriately (e.g., using RING_FINAL_CHECK_FOR_REQUESTS()).
+ *
+ * Back-front notifications: When enqueuing a new response, sending a
+ * notification can be made conditional on rsp_event (i.e., the generic
+ * hold-off mechanism provided by the ring macros). Frontends must set
+ * rsp_event appropriately (e.g., using RING_FINAL_CHECK_FOR_RESPONSES()).
+ */
+
+/*
+ * Feature and Parameter Negotiation
+ * =
+ * The two halves of a Para-virtual sound card driver utilize nodes within the
+ * XenStore to communicate capabilities and to negotiate operating parameters.
+ * This section enumerates these nodes which reside in the respective front and
+ * backend portions of the XenStore, following the XenBus convention.
+ *
+ * All data in the XenStore is stored as strings.  Nodes specifying numeric
+ * values are encoded in decimal.  Integer value ranges listed below are
+ * expressed as fixed sized integer types capable of storing the conversion
+ * of a properly formated node string, without loss of information.
+ *
+ *
+ *Backend XenBus Nodes
+ *
+ *
+ *- Backend Device parameters -
+ *
+ * devid
+ *  Values: uint32_t
+ *
+ *  Index of the soundcard which

[Xen-devel] [PATCH v6] sndif: add ABI for Para-virtual sound

[Oleksandr Dmytryshyn]

This is ABI for the two halves of a Para-virtual
sound driver to communicate with each to other.

Signed-off-by: Oleksandr Dmytryshyn oleksandr.dmytrys...@globallogic.com
Signed-off-by: Iurii Konovalenko iurii.konovale...@globallogic.com
---
Changes since v1:
 * removed __attribute__((__packed__)) from all structures definitions

Changes since v2:
 * removed all C structures
 * added protocol description between frontend and backend drivers

Changes since v3:
 * fixed some typos
 * renamed XENSND_PCM_FORMAT_FLOAT_** to XENSND_PCM_FORMAT_F32_**
 * renamed XENSND_PCM_FORMAT_FLOAT64_** to XENSND_PCM_FORMAT_F64_**
 * added 'id' field to the request and response packets
 * renamed 'stream_id' to 'stream' in the packets description
 * renamed 'pcm_data_rate' to 'pcm_rate' in the packets description
 * renamed 'pcm_stream_type' to 'pcm_type' in the packets description
 * removed 'stream_id' field from the response packets

Changes since v4:
 * renamed 'stream_id' back to the to 'stream' in the packets description
 * moved 'id' field to the upper position in the response packets

Changes since v5:
 * Slightly reworked request/response packets
 * Size of the request/response packet is changed to the 64 bytes
 * Now parameters for the XENSND_OP_SET_VOLUME/XENSND_OP_GET_VOLUME are
   passed via shared page
 * Added parameters for the XenBus nodes (now each stream can be mapped
   to the defined sound device in the backend using those parameters)
 * Added XenBus state diagrams description

 xen/include/public/io/sndif.h | 421 ++
 1 file changed, 421 insertions(+)
 create mode 100644 xen/include/public/io/sndif.h

diff --git a/xen/include/public/io/sndif.h b/xen/include/public/io/sndif.h
new file mode 100644
index 000..f2e080b
--- /dev/null
+++ b/xen/include/public/io/sndif.h
@@ -0,0 +1,421 @@
+/**
+ * sndif.h
+ *
+ * Unified sound-device I/O interface for Xen guest OSes.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the Software), to
+ * deal in the Software without restriction, including without limitation the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Copyright (C) 2013-2015 GlobalLogic Inc.
+ */
+
+#ifndef __XEN_PUBLIC_IO_XENSND_H__
+#define __XEN_PUBLIC_IO_XENSND_H__
+
+/*
+ * Front-back notifications: When enqueuing a new request, sending a
+ * notification can be made conditional on req_event (i.e., the generic
+ * hold-off mechanism provided by the ring macros). Backends must set
+ * req_event appropriately (e.g., using RING_FINAL_CHECK_FOR_REQUESTS()).
+ *
+ * Back-front notifications: When enqueuing a new response, sending a
+ * notification can be made conditional on rsp_event (i.e., the generic
+ * hold-off mechanism provided by the ring macros). Frontends must set
+ * rsp_event appropriately (e.g., using RING_FINAL_CHECK_FOR_RESPONSES()).
+ */
+
+/*
+ * Feature and Parameter Negotiation
+ * =
+ * The two halves of a Para-virtual sound card driver utilize nodes within the
+ * XenStore to communicate capabilities and to negotiate operating parameters.
+ * This section enumerates these nodes which reside in the respective front and
+ * backend portions of the XenStore, following the XenBus convention.
+ *
+ * All data in the XenStore is stored as strings.  Nodes specifying numeric
+ * values are encoded in decimal.  Integer value ranges listed below are
+ * expressed as fixed sized integer types capable of storing the conversion
+ * of a properly formated node string, without loss of information.
+ *
+ *
+ *Backend XenBus Nodes
+ *
+ *
+ *- Backend Device parameters -
+ *
+ * devid
+ *  Values: uint32_t
+ *
+ *  Index of the soundcard which will be created in the frontend. This
+ *  index is zero based.
+ *
+ * streams_cnt

Re: [Xen-devel] [PATCH v5] sndif: add ABI for Para-virtual sound

[Oleksandr Dmytryshyn]

On Thu, Jan 22, 2015 at 6:11 PM, Ian Jackson ian.jack...@eu.citrix.com wrote:
 Oleksandr Dmytryshyn writes (Re: [Xen-devel] [PATCH v5] sndif: add ABI for 
 Para-virtual sound):
 On Thu, Jan 22, 2015 at 5:56 PM, Ian Jackson ian.jack...@eu.citrix.com 
 wrote:
  Oleksandr Dmytryshyn writes (Re: [Xen-devel] [PATCH v5] sndif: add ABI 
  for Para-virtual sound):
  In my case this is about 3 packets per second with size about 16 KBytes.
 
  That would put a floor on the latency of about 300ms.  I suspect
  that's quite undesirable.

 This latency doesn't affect us because frontend and backend driver have
 an separate thread for each virtualized stream. And when frontend driver
 waits answer from the backend it just sleeps (in case Linux kernel it waits
 for the completion).

 Your seem to be answering a different question to the one I intended
 to ask.

 What I mean is this:

 Many people think it is important to reduce the latency of sound input
 and output.  So, they want to reduce (a) the time between a piece of
 software deciding to make a sound and (b) the time when that sound
 starts to appear.  And the same for input.  This is important for
 games, video conversations, and so on.

 When sound output is occurring continuously, any piece of new sound
 output needs to wait for the next packet to be sent.

 If you are sending only 3 packets per second then the latency might be
 as much as 1/3 second which I think is probably too much.
This latency is minimal.

Frontend side: the application wants to play sound.
It opens /dev/snd/pcmC0D0p file (for example) and issues some IOCTLs.
1. It sets the format and sound parameters (frontend sends request
to the backend to open a stream with this parameters).
2. It starts to send an PCM data usinf IOCTLs i. e. it writes an PCM
data to buffer which will be transfered from the frontend to the
backend. (frontend sends request to the backend to play an PCM stream)

So, the latency ((a) the time between a piece of software deciding
to make a sound and (b) the time when that sound starts to appear)
will be minimal - send 2 events to the backend and receive 2 responses
from the backend plus time for opening stream on the real sound device
in the backend side. This latency will be few milliseconds.

 Ian.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v5] sndif: add ABI for Para-virtual sound

[Oleksandr Dmytryshyn]

On Thu, Jan 22, 2015 at 6:07 PM, Ian Jackson ian.jack...@eu.citrix.com wrote:
 Oleksandr Dmytryshyn writes (Re: [PATCH v5] sndif: add ABI for Para-virtual 
 sound):
 On Thu, Jan 22, 2015 at 5:41 PM, Ian Jackson ian.jack...@eu.citrix.com 
 wrote:
  So for example, much real hardware will have a headphone output and
  also built-in speakers, and a mic input and built-in microphone.

  How is this to be exposed to the guest ?

 Every stream handled in the own thread in the frontend driver.
 Frontend sends command (read or write, etc) to the backend and
 this is blocking command (within current stream). So I just
 use different streams for playback and capture.

 Right, I gathered that.

 In case if we have
 headphone output and also built-in speakers, and a mic input and
 built-in microphone we will use one stream for the headphone output,
 one stream for the built-in speakers and one stream for the mic input.
 And in this time all devices will be able to work simultaneously.

 Perhaps I'm missing something but I don't see where the necessary
 information is passed in your protocol specification.

 Let us consider only output for now.  How does the guest choose which
 of the possibly-several output devices their stream goes to ?  Are
 these the multiple stream_id's ?  Are they identified solely by
 number ?  Is there a conventional mapping for these streams ?
For now we are using a simplified PV sound drivers.
Every streams can be opened for playback or capture.
And backend driver uses alsa and uses 'dmix' plugin for playback
and 'dsnoop' plugin for capture.
For now this protocol doesn't support mapping for streams and needs to be
reworked. I'll rework It in the next patch-set.
New nodes will be added to the xenstore with the stream mappings.
For now a single stream is virtualized but I think that whole sound card should
be virtualized by single frontend-backend connection. In this case we will be
able to pass the alsa device name (which is used by backend), virtual sound
card name and number, stream type (playback or capture) and stream number
for each stream inside the virtualized sound card.

Example of the configuration (which will be read from the xenstore):
Sound cart 'default', 'card number 2'
'mic' - 'captute', 'stream 5' - /dev/snd/pcmC2D5c
'headphones' - 'playback', 'stream 3' - /dev/snd/pcmC2D3p

Our backend uses ALSA and opens streams by name.

 Ian.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3] sndif: add ABI for Para-virtual sound

[Oleksandr Dmytryshyn]

On Thu, Jan 22, 2015 at 1:08 PM, Jan Beulich jbeul...@suse.com wrote:
 On 22.01.15 at 11:52, oleksandr.dmytrys...@globallogic.com wrote:
 On Thu, Jan 22, 2015 at 12:24 PM, Jan Beulich jbeul...@suse.com wrote:
 On 22.01.15 at 10:56, oleksandr.dmytrys...@globallogic.com wrote:
 + * Responce for all requests exept the XENSND_GET_VOLUME:
 + * 01 2 3 4 5 6 7  octet
 + * +-+-+-+-+-+-+-+-+
 + * |   stream_id   |   operation   |

 Is there a really need for echoing the operation, i.e. isn't the echoed
 ID sufficient? Because if you'd be able to drop this, request and
 response sizes would match up, avoiding wasted space on the
 shared page(s).
 In our implementation there is no matter if is echoed the operation or no.
 Frontend sends one request and waits a response. So I can simply remove
 the echoed operation. But in the future if this echoed the operation
 will be needed
 it can be simply restored.

 Question here is whether stream_id really means what its name
 says. If it does, you certainly need another field with a request ID,
 which then also need echoing (and then the question is whether
 stream_id need echoing too).
Our implementation doesn't use a request ID, but this field
may be added to the protocol and in addition this request ID will be echoed.
And stream_id didn't need be echoed.
I'll think how to do it better in the next-patch-set.

 Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v4] sndif: add ABI for Para-virtual sound

[Oleksandr Dmytryshyn]

On Thu, Jan 22, 2015 at 3:58 PM, Ian Jackson ian.jack...@eu.citrix.com wrote:
 Oleksandr Dmytryshyn writes ([PATCH v4] sndif: add ABI for Para-virtual 
 sound):
 This is ABI for the two halves of a Para-virtual
 sound driver to communicate with each to other.
 ...

 I think the unnecessary difference between request and response
 headers is undesirable.  I would put the id at the front of both.
I'll do this in the next patch-set.

 Where do the fixed packet size of 80 bytes and the fixed maximum
 channel of 15 come from ?  What if we want to change these later ?
 Is that likely ?  What's our extension plan ?
One of the possible ways - add an extended version of the SET/GET volume
which will be similar to read/write operation (using additional shared pages).
And in this case there will be 2 sets of commands SET/GET volume.

 Ian.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH v3] sndif: add ABI for Para-virtual sound

[Oleksandr Dmytryshyn]

This is ABI for the two halves of a Para-virtual
sound driver to communicate with each to other.

Signed-off-by: Oleksandr Dmytryshyn oleksandr.dmytrys...@globallogic.com
Signed-off-by: Iurii Konovalenko iurii.konovale...@globallogic.com
---
Changes since v1:
 * removed __attribute__((__packed__)) from all structures definitions

Changes since v2:
 * removed all C structures
 * added protocol description between frontend and backend drivers

 xen/include/public/io/sndif.h | 323 ++
 1 file changed, 323 insertions(+)
 create mode 100644 xen/include/public/io/sndif.h

diff --git a/xen/include/public/io/sndif.h b/xen/include/public/io/sndif.h
new file mode 100644
index 000..8a78501
--- /dev/null
+++ b/xen/include/public/io/sndif.h
@@ -0,0 +1,323 @@
+/**
+ * sndif.h
+ *
+ * Unified sound-device I/O interface for Xen guest OSes.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the Software), to
+ * deal in the Software without restriction, including without limitation the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Copyright (C) 2013-2015 GlobalLogic Inc.
+ */
+
+#ifndef __XEN_PUBLIC_IO_XENSND_H__
+#define __XEN_PUBLIC_IO_XENSND_H__
+
+/*
+ * Feature and Parameter Negotiation
+ * =
+ * The two halves of a Para-virtual sound driver utilize nodes within the
+ * XenStore to communicate capabilities and to negotiate operating parameters.
+ * This section enumerates these nodes which reside in the respective front and
+ * backend portions of the XenStore, following the XenBus convention.
+ *
+ * All data in the XenStore is stored as strings.  Nodes specifying numeric
+ * values are encoded in decimal.  Integer value ranges listed below are
+ * expressed as fixed sized integer types capable of storing the conversion
+ * of a properly formated node string, without loss of information.
+ *
+ * XenStore nodes in sections marked PRIVATE are solely for use by the
+ * driver side whose XenBus tree contains them.
+ *
+ *
+ *Backend XenBus Nodes
+ *
+ *
+ *-- Backend Device Identification (PRIVATE) --
+ *
+ * stream_id
+ *  Values: uint32_t
+ *
+ *  Each virtualized stream has own id starting from 0.
+ *  Within each frontend these ids must be unique.
+ *  Each stream can be opened only for playback or capture
+ *  at the same time.
+ *
+ * channels_cnt
+ *  Values: uint32_t
+ *
+ *  The maximum amount of channels that can be supported by this stream.
+ *
+ *
+ *Frontend XenBus Nodes
+ *
+ *
+ *--- Request Transport Parameters ---
+ *
+ * event-channel
+ *  Values: uint32_t
+ *
+ *  The identifier of the Xen event channel used to signal activity
+ *  in the ring buffer.
+ *
+ * ring-ref
+ *  Values: uint32_t
+ *
+ *  The Xen grant reference granting permission for the backend to map
+ *  the sole page in a single page sized ring buffer.
+ */
+
+/*
+ * PCM FORMATS
+ *
+ * XENSND_PCM_FORMAT_format[_endian]
+ *
+ * format: S/U/FLOAT[bits] or name
+ * S - signed, U - unsigned, FLOAT - float
+ * bits - 8, 16, 24, 32 or absent
+ * name - MU_LAW, GSM, etc.
+ *
+ * endian: LE/BE, may be absent
+ * LE - Little endian, BE - Big endian
+ */
+#define XENSND_PCM_FORMAT_S80
+#define XENSND_PCM_FORMAT_U81
+#define XENSND_PCM_FORMAT_S16_LE2
+#define XENSND_PCM_FORMAT_S16_BE3
+#define XENSND_PCM_FORMAT_U16_LE4
+#define XENSND_PCM_FORMAT_U16_BE5
+#define XENSND_PCM_FORMAT_S24_LE6
+#define XENSND_PCM_FORMAT_S24_BE

Re: [Xen-devel] [PATCH v3 1/2] xen-sndfront: add sound frontend driver

[Oleksandr Dmytryshyn]

On Wed, Jan 21, 2015 at 5:14 PM, Stefano Stabellini
stefano.stabell...@eu.citrix.com wrote:
 On Tue, 20 Jan 2015, Oleksandr Dmytryshyn wrote:
 This is Para-virtual sound driver.

 Frontend driver registers an virtual sound card
 and sends an PCM streams to the backend driver.
 Backend driver is an user-space application and
 uses ALSA with dmix plugin to play audio.

 Signed-off-by: Oleksandr Dmytryshyn oleksandr.dmytrys...@globallogic.com
 Signed-off-by: Iurii Konovalenko iurii.konovale...@globallogic.com

 The code isn't bad but we still lack a document that describes how the
 protocol works.  It should have enough details in it to allow somebody
 to write a backend for it without looking at the frontend code.

 Without it, it is very difficult to tell if the frontend implementation
 is right.
I'll describe a protocol in the next patch-set. There will be some
description inside the file sndif.h.
The rest I'll describe additionally.


  include/xen/interface/io/sndif.h |  208 ++
  sound/drivers/Kconfig|   10 +
  sound/drivers/Makefile   |2 +
  sound/drivers/xen-sndfront.c | 1478 
 ++
  4 files changed, 1698 insertions(+)
  create mode 100644 include/xen/interface/io/sndif.h
  create mode 100644 sound/drivers/xen-sndfront.c

 diff --git a/include/xen/interface/io/sndif.h 
 b/include/xen/interface/io/sndif.h
 new file mode 100644
 index 000..99e6f8e
 --- /dev/null
 +++ b/include/xen/interface/io/sndif.h
 @@ -0,0 +1,208 @@
 +/**
 + * sndif.h
 + *
 + * Unified sound-device I/O interface for Xen guest OSes.
 + *
 + * Permission is hereby granted, free of charge, to any person obtaining a 
 copy
 + * of this software and associated documentation files (the Software), to
 + * deal in the Software without restriction, including without limitation 
 the
 + * rights to use, copy, modify, merge, publish, distribute, sublicense, 
 and/or
 + * sell copies of the Software, and to permit persons to whom the Software 
 is
 + * furnished to do so, subject to the following conditions:
 + *
 + * The above copyright notice and this permission notice shall be included 
 in
 + * all copies or substantial portions of the Software.
 + *
 + * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS 
 OR
 + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
 + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL 
 THE
 + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
 + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
 + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
 + * DEALINGS IN THE SOFTWARE.
 + *
 + * Copyright (C) 2013-2015 GlobalLogic Inc.
 + */
 +
 +#ifndef __XEN_PUBLIC_IO_SNDIF_H__
 +#define __XEN_PUBLIC_IO_SNDIF_H__
 +
 +#include xen/interface/io/ring.h
 +#include xen/interface/grant_table.h
 +
 +/*
 + * Feature and Parameter Negotiation
 + * =
 + * The two halves of a Xen vsnd driver utilize nodes within the XenStore to
 + * communicate capabilities and to negotiate operating parameters.  This
 + * section enumerates these nodes which reside in the respective front and
 + * backend portions of the XenStore, following the XenBus convention.
 + *
 + * All data in the XenStore is stored as strings.  Nodes specifying numeric
 + * values are encoded in decimal.  Integer value ranges listed below are
 + * expressed as fixed sized integer types capable of storing the conversion
 + * of a properly formated node string, without loss of information.
 + *
 + * Any specified default value is in effect if the corresponding XenBus node
 + * is not present in the XenStore.
 + *
 + * XenStore nodes in sections marked PRIVATE are solely for use by the
 + * driver side whose XenBus tree contains them.
 + *
 + 
 *
 + *Backend XenBus Nodes
 + 
 *
 + *
 + *-- Backend Device Identification (PRIVATE) 
 --
 + *
 + * stream_id
 + *  Values: uint32_t
 + *
 + *  Virtuelized stream number
 + *
 + 
 *
 + *Frontend XenBus Nodes
 + 
 *
 + *
 + *--- Request Transport Parameters 
 ---
 + *
 + * event-channel
 + *  Values: uint32_t
 + *
 + *  The identifier of the Xen event channel used to signal activity
 + *  in the ring buffer.
 + *
 + * ring-ref
 + *  Values: uint32_t
 + *  Notes:  6
 + *
 + *  The Xen grant reference granting permission for the backend

Re: [Xen-devel] [PATCH v3] sndif: add ABI for Para-virtual sound

[Oleksandr Dmytryshyn]

On Thu, Jan 22, 2015 at 12:24 PM, Jan Beulich jbeul...@suse.com wrote:
 On 22.01.15 at 10:56, oleksandr.dmytrys...@globallogic.com wrote:
 +/*
 + * PCM FORMATS
 + *
 + * XENSND_PCM_FORMAT_format[_endian]
 + *
 + * format: S/U/FLOAT[bits] or name
 + * S - signed, U - unsigned, FLOAT - float
 + * bits - 8, 16, 24, 32 or absent
 + * name - MU_LAW, GSM, etc.
 + *
 + * endian: LE/BE, may be absent
 + * LE - Little endian, BE - Big endian
 + */
 +#define XENSND_PCM_FORMAT_S80
 +#define XENSND_PCM_FORMAT_U81
 +#define XENSND_PCM_FORMAT_S16_LE2
 +#define XENSND_PCM_FORMAT_S16_BE3
 +#define XENSND_PCM_FORMAT_U16_LE4
 +#define XENSND_PCM_FORMAT_U16_BE5
 +#define XENSND_PCM_FORMAT_S24_LE6
 +#define XENSND_PCM_FORMAT_S24_BE7
 +#define XENSND_PCM_FORMAT_U24_LE8
 +#define XENSND_PCM_FORMAT_U24_BE9
 +#define XENSND_PCM_FORMAT_S32_LE10
 +#define XENSND_PCM_FORMAT_S32_BE11
 +#define XENSND_PCM_FORMAT_U32_LE12
 +#define XENSND_PCM_FORMAT_U32_BE13
 +#define XENSND_PCM_FORMAT_FLOAT_LE  14 /* 4-byte float, IEEE-754 
 32-bit, */
 +#define XENSND_PCM_FORMAT_FLOAT_BE  15 /* range -1.0 to 1.0 
  */

 I think these should carry 32 in their names. I also wonder why
 it needs to be FLOAT instead of just F.
I'll rename those defines in the next patch-set.

 + * Request open - open an pcm stream for playback or capture:
 + * 01 2 3 4 5 6 7  octet
 + * +-+-+-+-+-+-+-+-+
 + * |   operation   |   stream_id   |
 + * +-+-+-+-+-+-+-+-+
 + * |  pcm_format   |  pcm_channes  |

 pcm_channel(s)?
I'll fix this in the next patch-set

 + * All responce packets have the same length (76 bytes)

 response
I'll fix this in the next patch-set

 + * Responce for all requests exept the XENSND_GET_VOLUME:
 + * 01 2 3 4 5 6 7  octet
 + * +-+-+-+-+-+-+-+-+
 + * |   stream_id   |   operation   |

 Is there a really need for echoing the operation, i.e. isn't the echoed
 ID sufficient? Because if you'd be able to drop this, request and
 response sizes would match up, avoiding wasted space on the
 shared page(s).
In our implementation there is no matter if is echoed the operation or no.
Frontend sends one request and waits a response. So I can simply remove
the echoed operation. But in the future if this echoed the operation
will be needed
it can be simply restored.


 + * +-+-+-+-+-+-+-+-+
 Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v5] sndif: add ABI for Para-virtual sound

[Oleksandr Dmytryshyn]

On Thu, Jan 22, 2015 at 5:39 PM, Roger Pau Monné roger@citrix.com wrote:
 El 22/01/15 a les 16.19, Oleksandr Dmytryshyn ha escrit:
 [...]
 +/*
 + * Description of the protocol between the frontend and the backend driver.
 + *
 + * The two halves of a Para-virtual sound driver communicates with
 + * each to other using an shared page and event channel.
 + * Shared page contains a ring with request/response packets.
 + * All fields within the packet are always in little-endian byte order.
 + * Almost all fields within the packet are unsigned except
 + * the field 'status' in the responses packets, which is signed.
 + *
 + *
 + * All request packets have the same length (80 bytes)

 80bytes is kind of a weird size. I would rather use 64bytes, which
 aligns itself more nicely with cache lines.
I'll rework the protocol in the next patch-set.

 [...]
 + * Request read/write - used for read (for capture) or write (for playback):
 + * 01 2 3 4 5 6 7  octet
 + * +-+-+-+-+-+-+-+-+
 + * |  id   |
 + * +-+-+-+-+-+-+-+-+
 + * |   operation   |   stream_id   |
 + * +-+-+-+-+-+-+-+-+
 + * | length| gref0 |
 + * +-+-+-+-+-+-+-+-+
 + * | gref1 | gref2 |
 + * +-+-+-+-+-+-+-+-+
 + * +/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/+
 + * +-+-+-+-+-+-+-+-+
 + * | gref11|   reserved|
 + * +-+-+-+-+-+-+-+-+
 + * |   reserved|   reserved|
 + * +-+-+-+-+-+-+-+-+
 + *
 + * id - private guest value, echoed in resp
 + * operation - XENSND_OP_READ or XENSND_OP_WRITE
 + * stream_id - stream id, readed from the 'stream_id' XenBus node
 + * length - read or write data length
 + * gref0 - gref11 - references to a grant entries for used pages in 
 read/write
 + * request.

 I don't know much about sound, but I expect that you aim at having low
 latency rather than high throughput. Why do you leave the 3 last slots
 unused? Shouldn't they be gref12..14, even if they are not used by the
 current implementation?
I'll rework the protocol in the next patch-set (I'll reduce a packet size).

 Also, how often are the sound packets sent, and which size do they have?
 I'm mainly asking because I don't know if it would be more suitable to
 use the same strategy as we did with indirect descriptors in the block
 protocol from the start.
In my case this is about 3 packets per second with size about 16 KBytes.

 + *
 + *
 + * Request set volume - set channels volume in stream:
 + * 01 2 3 4 5 6 7  octet
 + * +-+-+-+-+-+-+-+-+
 + * |  id   |
 + * +-+-+-+-+-+-+-+-+
 + * |   operation   |   stream_id   |
 + * +-+-+-+-+-+-+-+-+
 + * |vol_ch0|vol_ch1|
 + * +-+-+-+-+-+-+-+-+
 + * |vol_ch2|vol_ch3|
 + * +-+-+-+-+-+-+-+-+
 + * |vol_ch4|vol_ch5|
 + * +-+-+-+-+-+-+-+-+
 + * +/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/+
 + * +-+-+-+-+-+-+-+-+
 + * |vol_ch14   |vol_ch15   |
 + * +-+-+-+-+-+-+-+-+
 + *
 + * id - private guest value, echoed in resp
 + * operation - XENSND_OP_SET_VOLUME
 + * stream_id - stream id, readed from the 'stream_id' XenBus node
 + * vol_ch0 - vol_ch15 - volume level for channel0 - channel15

 I would put all the vol_ch[0..15] inside of a grant page, this way we
 could add more channels without problems. A single grant page could
 allow for 1024 channels (4096 / 4 = 1024), which seems more than enough.
 This way the size of the request/response will also be smaller, because
 AFAICT this is the bigger request size.
I'll rework the protocol in the next patch-set.

 [...]
 + * Response for XENSND_OP_GET_VOLUME request:
 + * 01 2 3 4 5 6 7  octet
 + * +-+-+-+-+-+-+-+-+
 + * |  id   |
 + * +-+-+-+-+-+-+-+-+
 + * |   operation   | status|
 + * +-+-+-+-+-+-+-+-+
 + * |vol_ch0|vol_ch1|
 + * +-+-+-+-+-+-+-+-+
 + * |vol_ch2|vol_ch3

Re: [Xen-devel] [PATCH v5] sndif: add ABI for Para-virtual sound

[Oleksandr Dmytryshyn]

On Thu, Jan 22, 2015 at 5:41 PM, Ian Jackson ian.jack...@eu.citrix.com wrote:
 Oleksandr Dmytryshyn writes ([PATCH v5] sndif: add ABI for Para-virtual 
 sound):
 This is ABI for the two halves of a Para-virtual
 sound driver to communicate with each to other.
 ...
 + * Request open - open an pcm stream for playback or capture:

 So channels here is stereo, mono, etc.

 There doesn't seem to be anything in this interface that distinguishes
 different input/output devices.

 So for example, much real hardware will have a headphone output and
 also built-in speakers, and a mic input and built-in microphone.

 How is this to be exposed to the guest ?
Every stream handled in the own thread in the frontend driver.
Frontend sends command (read or write, etc) to the backend and
this is blocking command (within current stream). So I just
use different streams for playback and capture. In case if we have
headphone output and also built-in speakers, and a mic input and
built-in microphone we will use one stream for the headphone output,
one stream for the built-in speakers and one stream for the mic input.
And in this time all devices will be able to work simultaneously.


 Ian.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v5] sndif: add ABI for Para-virtual sound

[Oleksandr Dmytryshyn]

On Thu, Jan 22, 2015 at 5:56 PM, Ian Jackson ian.jack...@eu.citrix.com wrote:
 Oleksandr Dmytryshyn writes (Re: [Xen-devel] [PATCH v5] sndif: add ABI for 
 Para-virtual sound):
 On Thu, Jan 22, 2015 at 5:39 PM, Roger Pau Monné roger@citrix.com 
 wrote:
  Also, how often are the sound packets sent, and which size do they have?
  I'm mainly asking because I don't know if it would be more suitable to
  use the same strategy as we did with indirect descriptors in the block
  protocol from the start.
 ...
 In my case this is about 3 packets per second with size about 16 KBytes.

 That would put a floor on the latency of about 300ms.  I suspect
 that's quite undesirable.
This latency doesn't affect us because frontend and backend driver have
an separate thread for each virtualized stream. And when frontend driver
waits answer from the backend it just sleeps (in case Linux kernel it waits
for the completion).

 Ian.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH v2 1/2] xen-sndfront: add sound frontend driver

[Oleksandr Dmytryshyn]

This is Para-virtual sound driver.

Frontend driver registers an virtual sound card
and sends an PCM streams to the backend driver.
Backend driver is an user-space application and
uses ALSA with dmix plugin to play audio.

Signed-off-by: Oleksandr Dmytryshyn oleksandr.dmytrys...@globallogic.com
Signed-off-by: Iurii Konovalenko iurii.konovale...@globallogic.com
---
 include/xen/interface/io/sndif.h |  208 ++
 sound/drivers/Kconfig|   10 +
 sound/drivers/Makefile   |2 +
 sound/drivers/xen-sndfront.c | 1478 ++
 4 files changed, 1698 insertions(+)
 create mode 100644 include/xen/interface/io/sndif.h
 create mode 100644 sound/drivers/xen-sndfront.c

diff --git a/include/xen/interface/io/sndif.h b/include/xen/interface/io/sndif.h
new file mode 100644
index 000..38a5f1e
--- /dev/null
+++ b/include/xen/interface/io/sndif.h
@@ -0,0 +1,208 @@
+/**
+ * sndif.h
+ *
+ * Unified sound-device I/O interface for Xen guest OSes.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the Software), to
+ * deal in the Software without restriction, including without limitation the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Copyright (C) 2013-2015 GlobalLogic Inc.
+ */
+
+#ifndef __XEN_PUBLIC_IO_SNDIF_H__
+#define __XEN_PUBLIC_IO_SNDIF_H__
+
+#include xen/interface/io/ring.h
+#include xen/interface/grant_table.h
+
+/*
+ * Feature and Parameter Negotiation
+ * =
+ * The two halves of a Xen vsnd driver utilize nodes within the XenStore to
+ * communicate capabilities and to negotiate operating parameters.  This
+ * section enumerates these nodes which reside in the respective front and
+ * backend portions of the XenStore, following the XenBus convention.
+ *
+ * All data in the XenStore is stored as strings.  Nodes specifying numeric
+ * values are encoded in decimal.  Integer value ranges listed below are
+ * expressed as fixed sized integer types capable of storing the conversion
+ * of a properly formated node string, without loss of information.
+ *
+ * Any specified default value is in effect if the corresponding XenBus node
+ * is not present in the XenStore.
+ *
+ * XenStore nodes in sections marked PRIVATE are solely for use by the
+ * driver side whose XenBus tree contains them.
+ *
+ *
+ *Backend XenBus Nodes
+ *
+ *
+ *-- Backend Device Identification (PRIVATE) --
+ *
+ * stream_id
+ *  Values: uint32_t
+ *
+ *  Virtuelized stream number
+ *
+ *
+ *Frontend XenBus Nodes
+ *
+ *
+ *--- Request Transport Parameters ---
+ *
+ * event-channel
+ *  Values: uint32_t
+ *
+ *  The identifier of the Xen event channel used to signal activity
+ *  in the ring buffer.
+ *
+ * ring-ref
+ *  Values: uint32_t
+ *  Notes:  6
+ *
+ *  The Xen grant reference granting permission for the backend to map
+ *  the sole page in a single page sized ring buffer.
+ */
+
+/*
+ * PCM FORMATS.
+ */
+#define SNDIF_PCM_FORMAT_S8(0)
+#define SNDIF_PCM_FORMAT_U8(1)
+#define SNDIF_PCM_FORMAT_S16_LE(2)
+#define SNDIF_PCM_FORMAT_S16_BE(3)
+#define SNDIF_PCM_FORMAT_U16_LE(4)
+#define SNDIF_PCM_FORMAT_U16_BE(5)
+
+/* low three bytes */
+#define SNDIF_PCM_FORMAT_S24_LE(6)
+
+/* low three bytes */
+#define SNDIF_PCM_FORMAT_S24_BE(7)
+
+/* low three bytes */
+#define SNDIF_PCM_FORMAT_U24_LE(8)
+
+/* low three bytes */
+#define SNDIF_PCM_FORMAT_U24_BE(9

[Xen-devel] [PATCH v2 2/2] xen-sndfront: add capture support

[Oleksandr Dmytryshyn]

From: Iurii Konovalenko iurii.konovale...@globallogic.com

Now both play and capture is supported.

Signed-off-by: Iurii Konovalenko iurii.konovale...@globallogic.com
Signed-off-by: Oleksandr Dmytryshyn oleksandr.dmytrys...@globallogic.com
---
 sound/drivers/xen-sndfront.c | 193 ---
 1 file changed, 164 insertions(+), 29 deletions(-)

diff --git a/sound/drivers/xen-sndfront.c b/sound/drivers/xen-sndfront.c
index d0367c2..054e535 100644
--- a/sound/drivers/xen-sndfront.c
+++ b/sound/drivers/xen-sndfront.c
@@ -98,7 +98,6 @@ MODULE_PARM_DESC(model, Soundcard model.);
 #define MIXER_ADDR_LASTMIXER_ADDR_MASTER_OUT
 
 struct vsnd_card {
-   struct sndfront_info *fr_info;
unsigned int stream_id;
grant_ref_t grefs[SNDIF_MAX_PAGES_PER_REQUEST];
unsigned char *buf;
@@ -123,7 +122,13 @@ struct sndfront_info {
unsigned int evtchn, irq;
struct vsnd_card *vcard;
int bret_code;
+};
+
+struct vsnd_sndfront {
+   int count;
+   spinlock_t lock; /* protect 'count' member */
struct platform_device *card_dev;
+   struct sndfront_info *infos[2];
 };
 
 #define GRANT_INVALID_REF  0
@@ -160,7 +165,6 @@ struct snd_virtualcard {
spinlock_t mixer_lock;  /* protect mixer settings */
int mixer_volume[MIXER_ADDR_LAST+1][2];
int capture_source[MIXER_ADDR_LAST+1][2];
-   struct sndfront_info *fr_info;
struct stream_info streams[2];
 };
 
@@ -206,6 +210,8 @@ static struct snd_pcm_hardware virtualcard_pcm_hardware = {
.fifo_size =0,
 };
 
+static struct vsnd_sndfront snd_fronts;
+
 static inline
 struct stream_info *get_vcard_stream(struct snd_virtualcard *virtualcard,
 struct snd_pcm_substream *substream)
@@ -216,6 +222,22 @@ struct stream_info *get_vcard_stream(struct 
snd_virtualcard *virtualcard,
return virtualcard-streams[1];
 }
 
+static inline
+struct sndfront_info *get_sndfront_info(struct snd_pcm_substream *substream)
+{
+   struct sndfront_info *res = NULL;
+   int stream = substream-stream;
+
+   spin_lock_irq(snd_fronts.lock);
+   if ((stream == SNDRV_PCM_STREAM_PLAYBACK)  (snd_fronts.count  0))
+   res = snd_fronts.infos[0];
+   else if ((stream == SNDRV_PCM_STREAM_CAPTURE)  (snd_fronts.count  1))
+   res =  snd_fronts.infos[1];
+   spin_unlock_irq(snd_fronts.lock);
+
+   return res;
+}
+
 static unsigned long vmalloc_to_mfn(void *address)
 {
return pfn_to_mfn(vmalloc_to_pfn(address));
@@ -234,7 +256,8 @@ static inline void flush_requests(struct sndfront_info 
*info)
 static int sndif_queue_request_open(struct sndfront_info *info,
snd_pcm_format_t format,
unsigned int channels,
-   unsigned int rate)
+   unsigned int rate,
+   unsigned int stream)
 {
struct sndif_request *req;
 
@@ -248,6 +271,7 @@ static int sndif_queue_request_open(struct sndfront_info 
*info,
req-u.open.snd_params.format = format;
req-u.open.snd_params.channels = channels;
req-u.open.snd_params.rate = rate;
+   req-u.open.stream = stream;
info-ring.req_prod_pvt++;
 
flush_requests(info);
@@ -300,16 +324,48 @@ static int sndif_queue_request_write(struct sndfront_info 
*info,
return 0;
 }
 
+static int sndif_queue_request_read(struct sndfront_info *info,
+   unsigned int len)
+{
+   struct sndif_request *req;
+   grant_ref_t *gref;
+   int i;
+
+   if (unlikely(info-connected != SNDIF_STATE_CONNECTED))
+   return 1;
+
+   req = RING_GET_REQUEST(info-ring, info-ring.req_prod_pvt);
+
+   req-operation = SNDIF_OP_READ;
+   req-u.rw.id = info-vcard-stream_id;
+
+   req-u.rw.len = len;
+
+   gref = info-vcard-grefs;
+
+   for (i = 0; i  SNDIF_MAX_PAGES_PER_REQUEST; i++)
+   req-u.rw.gref[i] = gref[i];
+
+   info-ring.req_prod_pvt++;
+
+   flush_requests(info);
+   return 0;
+}
+
 static int alsa_pcm_open(struct sndfront_info *info,
 snd_pcm_format_t format,
 unsigned int channels,
-unsigned int rate)
+unsigned int rate,
+unsigned int stream)
 {
unsigned long answer_tout;
 
+   if (!info)
+   return -EFAULT;
+
reinit_completion(info-completion);
 
-   if (sndif_queue_request_open(info, format, channels, rate))
+   if (sndif_queue_request_open(info, format, channels, rate, stream))
return -EIO;
 
answer_tout = msecs_to_jiffies(VSND_WAIT_ANSWER_TOUT);
@@ -324,6 +380,9 @@ static int alsa_pcm_close(struct sndfront_info *info)
 {
unsigned

[Xen-devel] [PATCH v2 0/2] Add sound frontend driver

[Oleksandr Dmytryshyn]

Hi to all.

Next series of patches introduces Para-virtual sound driver

CONFIG_XEN_SND_FRONTEND should be selected to use this driver.

Frontend driver registers an virtual sound card and sends/receives
an PCM streams to/from the backend driver. Backend driver is an
user-space application which uses ALSA with dmix plugin to play/capture audio.

Changes since v1:
 * 2 first patches are squashed
 * ALSA specific structure is renamed
 * used fixed width types in sndif.h

Iurii Konovalenko (1):
  xen-sndfront: add capture support

Oleksandr Dmytryshyn (1):
  xen-sndfront: add sound frontend driver

 include/xen/interface/io/sndif.h |  208 +
 sound/drivers/Kconfig|   10 +
 sound/drivers/Makefile   |2 +
 sound/drivers/xen-sndfront.c | 1613 ++
 4 files changed, 1833 insertions(+)
 create mode 100644 include/xen/interface/io/sndif.h
 create mode 100644 sound/drivers/xen-sndfront.c

-- 
1.9.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH] sndif: add ABI for Para-virtual sound

[Oleksandr Dmytryshyn]

Frontend driver registers an virtual sound card
and sends an PCM streams to the backend driver.
Backend driver is an user-space application.

Signed-off-by: Oleksandr Dmytryshyn oleksandr.dmytrys...@globallogic.com
Signed-off-by: Iurii Konovalenko iurii.konovale...@globallogic.com
---
 xen/include/public/io/sndif.h | 205 ++
 1 file changed, 205 insertions(+)
 create mode 100644 xen/include/public/io/sndif.h

diff --git a/xen/include/public/io/sndif.h b/xen/include/public/io/sndif.h
new file mode 100644
index 000..6099e08
--- /dev/null
+++ b/xen/include/public/io/sndif.h
@@ -0,0 +1,205 @@
+/**
+ * sndif.h
+ *
+ * Unified sound-device I/O interface for Xen guest OSes.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the Software), to
+ * deal in the Software without restriction, including without limitation the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Copyright (C) 2013-2015 GlobalLogic Inc.
+ */
+
+#ifndef __XEN_PUBLIC_IO_SNDIF_H__
+#define __XEN_PUBLIC_IO_SNDIF_H__
+
+/*
+ * Feature and Parameter Negotiation
+ * =
+ * The two halves of a Xen vsnd driver utilize nodes within the XenStore to
+ * communicate capabilities and to negotiate operating parameters.  This
+ * section enumerates these nodes which reside in the respective front and
+ * backend portions of the XenStore, following the XenBus convention.
+ *
+ * All data in the XenStore is stored as strings.  Nodes specifying numeric
+ * values are encoded in decimal.  Integer value ranges listed below are
+ * expressed as fixed sized integer types capable of storing the conversion
+ * of a properly formated node string, without loss of information.
+ *
+ * Any specified default value is in effect if the corresponding XenBus node
+ * is not present in the XenStore.
+ *
+ * XenStore nodes in sections marked PRIVATE are solely for use by the
+ * driver side whose XenBus tree contains them.
+ *
+ *
+ *Backend XenBus Nodes
+ *
+ *
+ *-- Backend Device Identification (PRIVATE) --
+ *
+ * stream_id
+ *  Values: uint32_t
+ *
+ *  Virtuelized stream number
+ *
+ *
+ *Frontend XenBus Nodes
+ *
+ *
+ *--- Request Transport Parameters ---
+ *
+ * event-channel
+ *  Values: uint32_t
+ *
+ *  The identifier of the Xen event channel used to signal activity
+ *  in the ring buffer.
+ *
+ * ring-ref
+ *  Values: uint32_t
+ *  Notes:  6
+ *
+ *  The Xen grant reference granting permission for the backend to map
+ *  the sole page in a single page sized ring buffer.
+ */
+
+/*
+ * PCM FORMATS.
+ */
+#define SNDIF_PCM_FORMAT_S8 (0)
+#define SNDIF_PCM_FORMAT_U8 (1)
+#define SNDIF_PCM_FORMAT_S16_LE (2)
+#define SNDIF_PCM_FORMAT_S16_BE (3)
+#define SNDIF_PCM_FORMAT_U16_LE (4)
+#define SNDIF_PCM_FORMAT_U16_BE (5)
+
+/* low three bytes */
+#define SNDIF_PCM_FORMAT_S24_LE (6)
+
+/* low three bytes */
+#define SNDIF_PCM_FORMAT_S24_BE (7)
+
+/* low three bytes */
+#define SNDIF_PCM_FORMAT_U24_LE (8)
+
+/* low three bytes */
+#define SNDIF_PCM_FORMAT_U24_BE (9)
+
+#define SNDIF_PCM_FORMAT_S32_LE (10)
+#define SNDIF_PCM_FORMAT_S32_BE (11)
+#define SNDIF_PCM_FORMAT_U32_LE (12)
+#define SNDIF_PCM_FORMAT_U32_BE (13)
+
+/* 4-byte float, IEEE-754 32-bit, range -1.0 to 1.0 */
+#define SNDIF_PCM_FORMAT_FLOAT_LE   (14)
+
+/* 4-byte float, IEEE-754 32-bit, range -1.0 to 1.0 */
+#define SNDIF_PCM_FORMAT_FLOAT_BE   (15)
+
+/* 8-byte

[Xen-devel] [PATCH v3 1/2] xen-sndfront: add sound frontend driver

[Oleksandr Dmytryshyn]

This is Para-virtual sound driver.

Frontend driver registers an virtual sound card
and sends an PCM streams to the backend driver.
Backend driver is an user-space application and
uses ALSA with dmix plugin to play audio.

Signed-off-by: Oleksandr Dmytryshyn oleksandr.dmytrys...@globallogic.com
Signed-off-by: Iurii Konovalenko iurii.konovale...@globallogic.com
---
 include/xen/interface/io/sndif.h |  208 ++
 sound/drivers/Kconfig|   10 +
 sound/drivers/Makefile   |2 +
 sound/drivers/xen-sndfront.c | 1478 ++
 4 files changed, 1698 insertions(+)
 create mode 100644 include/xen/interface/io/sndif.h
 create mode 100644 sound/drivers/xen-sndfront.c

diff --git a/include/xen/interface/io/sndif.h b/include/xen/interface/io/sndif.h
new file mode 100644
index 000..99e6f8e
--- /dev/null
+++ b/include/xen/interface/io/sndif.h
@@ -0,0 +1,208 @@
+/**
+ * sndif.h
+ *
+ * Unified sound-device I/O interface for Xen guest OSes.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the Software), to
+ * deal in the Software without restriction, including without limitation the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Copyright (C) 2013-2015 GlobalLogic Inc.
+ */
+
+#ifndef __XEN_PUBLIC_IO_SNDIF_H__
+#define __XEN_PUBLIC_IO_SNDIF_H__
+
+#include xen/interface/io/ring.h
+#include xen/interface/grant_table.h
+
+/*
+ * Feature and Parameter Negotiation
+ * =
+ * The two halves of a Xen vsnd driver utilize nodes within the XenStore to
+ * communicate capabilities and to negotiate operating parameters.  This
+ * section enumerates these nodes which reside in the respective front and
+ * backend portions of the XenStore, following the XenBus convention.
+ *
+ * All data in the XenStore is stored as strings.  Nodes specifying numeric
+ * values are encoded in decimal.  Integer value ranges listed below are
+ * expressed as fixed sized integer types capable of storing the conversion
+ * of a properly formated node string, without loss of information.
+ *
+ * Any specified default value is in effect if the corresponding XenBus node
+ * is not present in the XenStore.
+ *
+ * XenStore nodes in sections marked PRIVATE are solely for use by the
+ * driver side whose XenBus tree contains them.
+ *
+ *
+ *Backend XenBus Nodes
+ *
+ *
+ *-- Backend Device Identification (PRIVATE) --
+ *
+ * stream_id
+ *  Values: uint32_t
+ *
+ *  Virtuelized stream number
+ *
+ *
+ *Frontend XenBus Nodes
+ *
+ *
+ *--- Request Transport Parameters ---
+ *
+ * event-channel
+ *  Values: uint32_t
+ *
+ *  The identifier of the Xen event channel used to signal activity
+ *  in the ring buffer.
+ *
+ * ring-ref
+ *  Values: uint32_t
+ *  Notes:  6
+ *
+ *  The Xen grant reference granting permission for the backend to map
+ *  the sole page in a single page sized ring buffer.
+ */
+
+/*
+ * PCM FORMATS.
+ */
+#define SNDIF_PCM_FORMAT_S8(0)
+#define SNDIF_PCM_FORMAT_U8(1)
+#define SNDIF_PCM_FORMAT_S16_LE(2)
+#define SNDIF_PCM_FORMAT_S16_BE(3)
+#define SNDIF_PCM_FORMAT_U16_LE(4)
+#define SNDIF_PCM_FORMAT_U16_BE(5)
+
+/* low three bytes */
+#define SNDIF_PCM_FORMAT_S24_LE(6)
+
+/* low three bytes */
+#define SNDIF_PCM_FORMAT_S24_BE(7)
+
+/* low three bytes */
+#define SNDIF_PCM_FORMAT_U24_LE(8)
+
+/* low three bytes */
+#define SNDIF_PCM_FORMAT_U24_BE(9

[Xen-devel] [PATCH v3 2/2] xen-sndfront: add capture support

[Oleksandr Dmytryshyn]

From: Iurii Konovalenko iurii.konovale...@globallogic.com

Now both play and capture is supported.

Signed-off-by: Iurii Konovalenko iurii.konovale...@globallogic.com
Signed-off-by: Oleksandr Dmytryshyn oleksandr.dmytrys...@globallogic.com
---
 sound/drivers/xen-sndfront.c | 193 ---
 1 file changed, 164 insertions(+), 29 deletions(-)

diff --git a/sound/drivers/xen-sndfront.c b/sound/drivers/xen-sndfront.c
index d0367c2..054e535 100644
--- a/sound/drivers/xen-sndfront.c
+++ b/sound/drivers/xen-sndfront.c
@@ -98,7 +98,6 @@ MODULE_PARM_DESC(model, Soundcard model.);
 #define MIXER_ADDR_LASTMIXER_ADDR_MASTER_OUT
 
 struct vsnd_card {
-   struct sndfront_info *fr_info;
unsigned int stream_id;
grant_ref_t grefs[SNDIF_MAX_PAGES_PER_REQUEST];
unsigned char *buf;
@@ -123,7 +122,13 @@ struct sndfront_info {
unsigned int evtchn, irq;
struct vsnd_card *vcard;
int bret_code;
+};
+
+struct vsnd_sndfront {
+   int count;
+   spinlock_t lock; /* protect 'count' member */
struct platform_device *card_dev;
+   struct sndfront_info *infos[2];
 };
 
 #define GRANT_INVALID_REF  0
@@ -160,7 +165,6 @@ struct snd_virtualcard {
spinlock_t mixer_lock;  /* protect mixer settings */
int mixer_volume[MIXER_ADDR_LAST+1][2];
int capture_source[MIXER_ADDR_LAST+1][2];
-   struct sndfront_info *fr_info;
struct stream_info streams[2];
 };
 
@@ -206,6 +210,8 @@ static struct snd_pcm_hardware virtualcard_pcm_hardware = {
.fifo_size =0,
 };
 
+static struct vsnd_sndfront snd_fronts;
+
 static inline
 struct stream_info *get_vcard_stream(struct snd_virtualcard *virtualcard,
 struct snd_pcm_substream *substream)
@@ -216,6 +222,22 @@ struct stream_info *get_vcard_stream(struct 
snd_virtualcard *virtualcard,
return virtualcard-streams[1];
 }
 
+static inline
+struct sndfront_info *get_sndfront_info(struct snd_pcm_substream *substream)
+{
+   struct sndfront_info *res = NULL;
+   int stream = substream-stream;
+
+   spin_lock_irq(snd_fronts.lock);
+   if ((stream == SNDRV_PCM_STREAM_PLAYBACK)  (snd_fronts.count  0))
+   res = snd_fronts.infos[0];
+   else if ((stream == SNDRV_PCM_STREAM_CAPTURE)  (snd_fronts.count  1))
+   res =  snd_fronts.infos[1];
+   spin_unlock_irq(snd_fronts.lock);
+
+   return res;
+}
+
 static unsigned long vmalloc_to_mfn(void *address)
 {
return pfn_to_mfn(vmalloc_to_pfn(address));
@@ -234,7 +256,8 @@ static inline void flush_requests(struct sndfront_info 
*info)
 static int sndif_queue_request_open(struct sndfront_info *info,
snd_pcm_format_t format,
unsigned int channels,
-   unsigned int rate)
+   unsigned int rate,
+   unsigned int stream)
 {
struct sndif_request *req;
 
@@ -248,6 +271,7 @@ static int sndif_queue_request_open(struct sndfront_info 
*info,
req-u.open.snd_params.format = format;
req-u.open.snd_params.channels = channels;
req-u.open.snd_params.rate = rate;
+   req-u.open.stream = stream;
info-ring.req_prod_pvt++;
 
flush_requests(info);
@@ -300,16 +324,48 @@ static int sndif_queue_request_write(struct sndfront_info 
*info,
return 0;
 }
 
+static int sndif_queue_request_read(struct sndfront_info *info,
+   unsigned int len)
+{
+   struct sndif_request *req;
+   grant_ref_t *gref;
+   int i;
+
+   if (unlikely(info-connected != SNDIF_STATE_CONNECTED))
+   return 1;
+
+   req = RING_GET_REQUEST(info-ring, info-ring.req_prod_pvt);
+
+   req-operation = SNDIF_OP_READ;
+   req-u.rw.id = info-vcard-stream_id;
+
+   req-u.rw.len = len;
+
+   gref = info-vcard-grefs;
+
+   for (i = 0; i  SNDIF_MAX_PAGES_PER_REQUEST; i++)
+   req-u.rw.gref[i] = gref[i];
+
+   info-ring.req_prod_pvt++;
+
+   flush_requests(info);
+   return 0;
+}
+
 static int alsa_pcm_open(struct sndfront_info *info,
 snd_pcm_format_t format,
 unsigned int channels,
-unsigned int rate)
+unsigned int rate,
+unsigned int stream)
 {
unsigned long answer_tout;
 
+   if (!info)
+   return -EFAULT;
+
reinit_completion(info-completion);
 
-   if (sndif_queue_request_open(info, format, channels, rate))
+   if (sndif_queue_request_open(info, format, channels, rate, stream))
return -EIO;
 
answer_tout = msecs_to_jiffies(VSND_WAIT_ANSWER_TOUT);
@@ -324,6 +380,9 @@ static int alsa_pcm_close(struct sndfront_info *info)
 {
unsigned

[Xen-devel] [PATCH v2] sndif: add ABI for Para-virtual sound

[Oleksandr Dmytryshyn]

Frontend driver registers an virtual sound card
and sends an PCM streams to the backend driver.
Backend driver is an user-space application.

Signed-off-by: Oleksandr Dmytryshyn oleksandr.dmytrys...@globallogic.com
Signed-off-by: Iurii Konovalenko iurii.konovale...@globallogic.com
---
Changes since v1:
 * removed __attribute__((__packed__)) from all structures definitions

 xen/include/public/io/sndif.h | 205 ++
 1 file changed, 205 insertions(+)
 create mode 100644 xen/include/public/io/sndif.h

diff --git a/xen/include/public/io/sndif.h b/xen/include/public/io/sndif.h
new file mode 100644
index 000..1b93520
--- /dev/null
+++ b/xen/include/public/io/sndif.h
@@ -0,0 +1,205 @@
+/**
+ * sndif.h
+ *
+ * Unified sound-device I/O interface for Xen guest OSes.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the Software), to
+ * deal in the Software without restriction, including without limitation the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Copyright (C) 2013-2015 GlobalLogic Inc.
+ */
+
+#ifndef __XEN_PUBLIC_IO_SNDIF_H__
+#define __XEN_PUBLIC_IO_SNDIF_H__
+
+/*
+ * Feature and Parameter Negotiation
+ * =
+ * The two halves of a Xen vsnd driver utilize nodes within the XenStore to
+ * communicate capabilities and to negotiate operating parameters.  This
+ * section enumerates these nodes which reside in the respective front and
+ * backend portions of the XenStore, following the XenBus convention.
+ *
+ * All data in the XenStore is stored as strings.  Nodes specifying numeric
+ * values are encoded in decimal.  Integer value ranges listed below are
+ * expressed as fixed sized integer types capable of storing the conversion
+ * of a properly formated node string, without loss of information.
+ *
+ * Any specified default value is in effect if the corresponding XenBus node
+ * is not present in the XenStore.
+ *
+ * XenStore nodes in sections marked PRIVATE are solely for use by the
+ * driver side whose XenBus tree contains them.
+ *
+ *
+ *Backend XenBus Nodes
+ *
+ *
+ *-- Backend Device Identification (PRIVATE) --
+ *
+ * stream_id
+ *  Values: uint32_t
+ *
+ *  Virtuelized stream number
+ *
+ *
+ *Frontend XenBus Nodes
+ *
+ *
+ *--- Request Transport Parameters ---
+ *
+ * event-channel
+ *  Values: uint32_t
+ *
+ *  The identifier of the Xen event channel used to signal activity
+ *  in the ring buffer.
+ *
+ * ring-ref
+ *  Values: uint32_t
+ *  Notes:  6
+ *
+ *  The Xen grant reference granting permission for the backend to map
+ *  the sole page in a single page sized ring buffer.
+ */
+
+/*
+ * PCM FORMATS.
+ */
+#define SNDIF_PCM_FORMAT_S8 (0)
+#define SNDIF_PCM_FORMAT_U8 (1)
+#define SNDIF_PCM_FORMAT_S16_LE (2)
+#define SNDIF_PCM_FORMAT_S16_BE (3)
+#define SNDIF_PCM_FORMAT_U16_LE (4)
+#define SNDIF_PCM_FORMAT_U16_BE (5)
+
+/* low three bytes */
+#define SNDIF_PCM_FORMAT_S24_LE (6)
+
+/* low three bytes */
+#define SNDIF_PCM_FORMAT_S24_BE (7)
+
+/* low three bytes */
+#define SNDIF_PCM_FORMAT_U24_LE (8)
+
+/* low three bytes */
+#define SNDIF_PCM_FORMAT_U24_BE (9)
+
+#define SNDIF_PCM_FORMAT_S32_LE (10)
+#define SNDIF_PCM_FORMAT_S32_BE (11)
+#define SNDIF_PCM_FORMAT_U32_LE (12)
+#define SNDIF_PCM_FORMAT_U32_BE (13)
+
+/* 4-byte float, IEEE-754 32-bit, range -1.0 to 1.0 */
+#define SNDIF_PCM_FORMAT_FLOAT_LE   (14)
+
+/* 4-byte float, IEEE-754

Re: [Xen-devel] [PATCH] sndif: add ABI for Para-virtual sound

[Oleksandr Dmytryshyn]

On Tue, Jan 20, 2015 at 11:55 AM, Paul Durrant paul.durr...@citrix.com wrote:
 -Original Message-
 From: xen-devel-boun...@lists.xen.org [mailto:xen-devel-
 boun...@lists.xen.org] On Behalf Of Oleksandr Dmytryshyn
 Sent: 20 January 2015 09:03
 To: xen-devel@lists.xen.org
 Cc: Keir (Xen.org); Ian Jackson; Ian Campbell; Jan Beulich; Tim (Xen.org)
 Subject: [Xen-devel] [PATCH] sndif: add ABI for Para-virtual sound

 Frontend driver registers an virtual sound card
 and sends an PCM streams to the backend driver.
 Backend driver is an user-space application.

 Signed-off-by: Oleksandr Dmytryshyn
 oleksandr.dmytrys...@globallogic.com
 Signed-off-by: Iurii Konovalenko iurii.konovale...@globallogic.com
 ---
  xen/include/public/io/sndif.h | 205
 ++
  1 file changed, 205 insertions(+)
  create mode 100644 xen/include/public/io/sndif.h

 diff --git a/xen/include/public/io/sndif.h b/xen/include/public/io/sndif.h
 new file mode 100644
 index 000..6099e08
 --- /dev/null
 +++ b/xen/include/public/io/sndif.h
 @@ -0,0 +1,205 @@
 +/*
 *
 + * sndif.h
 + *
 + * Unified sound-device I/O interface for Xen guest OSes.
 + *
 + * Permission is hereby granted, free of charge, to any person obtaining a
 copy
 + * of this software and associated documentation files (the Software), to
 + * deal in the Software without restriction, including without limitation 
 the
 + * rights to use, copy, modify, merge, publish, distribute, sublicense, 
 and/or
 + * sell copies of the Software, and to permit persons to whom the Software
 is
 + * furnished to do so, subject to the following conditions:
 + *
 + * The above copyright notice and this permission notice shall be included 
 in
 + * all copies or substantial portions of the Software.
 + *
 + * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND,
 EXPRESS OR
 + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
 MERCHANTABILITY,
 + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO
 EVENT SHALL THE
 + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES
 OR OTHER
 + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
 ARISING
 + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
 OTHER
 + * DEALINGS IN THE SOFTWARE.
 + *
 + * Copyright (C) 2013-2015 GlobalLogic Inc.
 + */
 +
 +#ifndef __XEN_PUBLIC_IO_SNDIF_H__
 +#define __XEN_PUBLIC_IO_SNDIF_H__
 +
 +/*
 + * Feature and Parameter Negotiation
 + * =
 + * The two halves of a Xen vsnd driver utilize nodes within the XenStore to
 + * communicate capabilities and to negotiate operating parameters.  This
 + * section enumerates these nodes which reside in the respective front and
 + * backend portions of the XenStore, following the XenBus convention.
 + *
 + * All data in the XenStore is stored as strings.  Nodes specifying numeric
 + * values are encoded in decimal.  Integer value ranges listed below are
 + * expressed as fixed sized integer types capable of storing the conversion
 + * of a properly formated node string, without loss of information.
 + *
 + * Any specified default value is in effect if the corresponding XenBus node
 + * is not present in the XenStore.
 + *
 + * XenStore nodes in sections marked PRIVATE are solely for use by the
 + * driver side whose XenBus tree contains them.
 + *
 +
 **
 ***
 + *Backend XenBus Nodes
 +
 **
 ***
 + *
 + *-- Backend Device Identification (PRIVATE) 
 --
 + *
 + * stream_id
 + *  Values: uint32_t
 + *
 + *  Virtuelized stream number
 + *
 +
 **
 ***
 + *Frontend XenBus Nodes
 +
 **
 ***
 + *
 + *--- Request Transport Parameters 
 ---
 + *
 + * event-channel
 + *  Values: uint32_t
 + *
 + *  The identifier of the Xen event channel used to signal activity
 + *  in the ring buffer.
 + *
 + * ring-ref
 + *  Values: uint32_t
 + *  Notes:  6
 + *
 + *  The Xen grant reference granting permission for the backend to map
 + *  the sole page in a single page sized ring buffer.
 + */
 +
 +/*
 + * PCM FORMATS.
 + */
 +#define SNDIF_PCM_FORMAT_S8 (0)
 +#define SNDIF_PCM_FORMAT_U8 (1)
 +#define SNDIF_PCM_FORMAT_S16_LE (2)
 +#define SNDIF_PCM_FORMAT_S16_BE (3)
 +#define SNDIF_PCM_FORMAT_U16_LE (4)
 +#define SNDIF_PCM_FORMAT_U16_BE (5)
 +
 +/* low three bytes */
 +#define SNDIF_PCM_FORMAT_S24_LE (6)
 +
 +/* low three bytes */
 +#define

Re: [Xen-devel] [PATCH] sndif: add ABI for Para-virtual sound

[Oleksandr Dmytryshyn]

On Tue, Jan 20, 2015 at 12:22 PM, Jan Beulich jbeul...@suse.com wrote:
 On 20.01.15 at 10:02, oleksandr.dmytrys...@globallogic.com wrote:
 Frontend driver registers an virtual sound card
 and sends an PCM streams to the backend driver.

 This seems backwards - a frontend driver may attach to a virtual sound
 card, but is unlikely to be the entity creating (i.. registering) it.
I'll correct the commit message in the next patch-set.

 Backend driver is an user-space application.

 This is irrelevant for the public interface.
I'll remove it in the next patch-set.

 + 
 *
 + *Frontend XenBus Nodes
 + 
 *
 + *
 + *--- Request Transport Parameters 
 ---
 + *
 + * event-channel
 + *  Values: uint32_t
 + *
 + *  The identifier of the Xen event channel used to signal activity
 + *  in the ring buffer.
 + *
 + * ring-ref
 + *  Values: uint32_t
 + *  Notes:  6

 Please don't blindly copy-and-paste from other headers. There's no note
 6 anywhere here, and even if it was the numbering should start at 1.
I'll fix it in the next patch-set.

 +/*
 + * PCM FORMATS.
 + */
 +#define SNDIF_PCM_FORMAT_S8 (0)
 +#define SNDIF_PCM_FORMAT_U8 (1)
 +#define SNDIF_PCM_FORMAT_S16_LE (2)
 +#define SNDIF_PCM_FORMAT_S16_BE (3)
 +#define SNDIF_PCM_FORMAT_U16_LE (4)
 +#define SNDIF_PCM_FORMAT_U16_BE (5)

 Pointless parentheses.
I'll remove all pointless parentheses in the next patch-set

 +/* low three bytes */
 +#define SNDIF_PCM_FORMAT_S24_LE (6)
 +
 +/* low three bytes */
 +#define SNDIF_PCM_FORMAT_S24_BE (7)
 +
 +/* low three bytes */
 +#define SNDIF_PCM_FORMAT_U24_LE (8)
 +
 +/* low three bytes */
 +#define SNDIF_PCM_FORMAT_U24_BE (9)

 What are these low three bytes comments to tell us? Please if
 you add comments, make them meaningful (and as this particular
 one appears to apply to three similarly named #define-s, just
 one instance of it will suffice). Furthermore the presence of a
 comment here implies to me that one is missing from the
 _[SU]16_[BL]E ones above as well as a few more below.
I'll remove those comments in the next patch-set.

 +/*
 + * STATUS RETURN CODES.
 + */
 + /* Operation failed for some unspecified reason (-EIO). */
 +#define SNDIF_RSP_ERROR   -1

 Missing parentheses.
A'll all parentheses in the next patch-set.

 +struct sndif_request {
 +uint8_t operation;  /* SNDIF_OP_??? */
 +union {

 Looks like you started from a Linux clone of blkif.h. This way of laying
 out things is just not suitable without the use of (forbidden) compiler
 extensions. Simply make the respective fields of this structure unions,
 rather than using this union of structures.
I'll try to do this in the next patch-set.

 +struct sndif_request_common common;
 +struct sndif_request_open open;
 +struct sndif_request_rw rw;
 +struct sndif_request_volume vol;
 +} u;
 +} __attribute__((__packed__));

 And do you btw realize that this together with there not being
 padding after operation yields all of the other structure fields
 unaligned? IOW, besides needing to drop the packing, you
 should also make all padding explicit, and that in a way that it
 fits both 32- and 64-bit consumers.
I'll remove all __attribute__((__packed__)) in the next patch-set
and I'll make all padding explicit in the next patch-set.

 +struct sndif_response {
 +uint64_t id;/* copied from request */
 +uint8_t operation;  /* copied from request */
 +int16_t status; /* SNDIF_RSP_???   */
 +};
 +
 +DEFINE_RING_TYPES(sndif, struct sndif_request, struct sndif_response);
 +
 +#endif /* __XEN_PUBLIC_IO_SNDIF_H__ */

 Also, overall - despite existing headers under io/ giving bad examples,
 please let's not add further public definitions without proper XEN_ or
 xen_ prefixes.
I'll try to do this in the next patch-set.

 Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH 3/3] xen-sndfront: add capture support

[Oleksandr Dmytryshyn]

From: Iurii Konovalenko iurii.konovale...@globallogic.com

Now both play and capture is supported.

Signed-off-by: Iurii Konovalenko iurii.konovale...@globallogic.com
Signed-off-by: Oleksandr Dmytryshyn oleksandr.dmytrys...@globallogic.com
---
 include/xen/interface/io/sndif.h |  93 +---
 sound/drivers/xen-sndfront.c | 222 ++-
 2 files changed, 252 insertions(+), 63 deletions(-)

diff --git a/include/xen/interface/io/sndif.h b/include/xen/interface/io/sndif.h
index 2fae4df..dafd90b 100644
--- a/include/xen/interface/io/sndif.h
+++ b/include/xen/interface/io/sndif.h
@@ -11,17 +11,70 @@
 #include xen/interface/grant_table.h
 
 /*
+ * PCM FORMATS.
+ */
+#define SNDIF_PCM_FORMAT_S8(0)
+#define SNDIF_PCM_FORMAT_U8(1)
+#define SNDIF_PCM_FORMAT_S16_LE(2)
+#define SNDIF_PCM_FORMAT_S16_BE(3)
+#define SNDIF_PCM_FORMAT_U16_LE(4)
+#define SNDIF_PCM_FORMAT_U16_BE(5)
+
+/* low three bytes */
+#define SNDIF_PCM_FORMAT_S24_LE(6)
+
+/* low three bytes */
+#define SNDIF_PCM_FORMAT_S24_BE(7)
+
+/* low three bytes */
+#define SNDIF_PCM_FORMAT_U24_LE(8)
+
+/* low three bytes */
+#define SNDIF_PCM_FORMAT_U24_BE(9)
+
+#define SNDIF_PCM_FORMAT_S32_LE(10)
+#define SNDIF_PCM_FORMAT_S32_BE(11)
+#define SNDIF_PCM_FORMAT_U32_LE(12)
+#define SNDIF_PCM_FORMAT_U32_BE(13)
+
+/* 4-byte float, IEEE-754 32-bit, range -1.0 to 1.0 */
+#define SNDIF_PCM_FORMAT_FLOAT_LE  (14)
+
+/* 4-byte float, IEEE-754 32-bit, range -1.0 to 1.0 */
+#define SNDIF_PCM_FORMAT_FLOAT_BE  (15)
+
+/* 8-byte float, IEEE-754 64-bit, range -1.0 to 1.0 */
+#define SNDIF_PCM_FORMAT_FLOAT64_LE(16)
+
+/* 8-byte float, IEEE-754 64-bit, range -1.0 to 1.0 */
+#define SNDIF_PCM_FORMAT_FLOAT64_BE(17)
+
+/* IEC-958 subframe, Little Endian */
+#define SNDIF_PCM_FORMAT_IEC958_SUBFRAME_LE (18)
+
+/* IEC-958 subframe, Big Endian */
+#define SNDIF_PCM_FORMAT_IEC958_SUBFRAME_BE (19)
+
+#define SNDIF_PCM_FORMAT_MU_LAW(20)
+#define SNDIF_PCM_FORMAT_A_LAW (21)
+#define SNDIF_PCM_FORMAT_IMA_ADPCM (22)
+#define SNDIF_PCM_FORMAT_MPEG  (23)
+#define SNDIF_PCM_FORMAT_GSM   (24)
+#define SNDIF_PCM_FORMAT_SPECIAL   (31)
+
+/*
  * REQUEST CODES.
  */
 #define SNDIF_OP_OPEN  0
 #define SNDIF_OP_CLOSE 1
 #define SNDIF_OP_READ  2
 #define SNDIF_OP_WRITE 3
-#define SNDIF_OP_IOCTL 4
+#define SNDIF_SET_VOLUME   4
+#define SNDIF_GET_VOLUME   5
 
 #define SNDIF_MAX_PAGES_PER_REQUEST10
 
-#define SNDIF_DEV_ID_CNT   5
+#define SNDIF_DEV_ID_CNT   2
 
 /*
  * STATUS RETURN CODES.
@@ -32,39 +85,47 @@
 #define SNDIF_RSP_OKAY 0
 
 struct alsa_hwparams {
-   snd_pcm_format_t format;
-   unsigned int channels;
-   unsigned int rate;
+   uint32_t format;
+   uint32_t channels;
+   uint32_t rate;
 };
 
+struct sndif_request_common {
+   uint64_t id;   /* private guest value, echoed in resp  */
+   struct alsa_hwparams _pad1;
+   uint32_t _pad2;
+   uint32_t _pad3;
+} __attribute__((__packed__));
+
 struct sndif_request_open {
-   struct alsa_hwparams hwparams;
-   unsigned int _pad1;
uint64_t id;   /* private guest value, echoed in resp  */
-   unsigned int _pad2;
+   struct alsa_hwparams hwparams;
+   uint32_t stream;
+   uint32_t _pad2;
 } __attribute__((__packed__));
 
 struct sndif_request_rw {
-   struct alsa_hwparams _pad1;
-   unsigned int _pad2;
uint64_t id;   /* private guest value, echoed in resp  */
-   unsigned int len;
+   struct alsa_hwparams _pad1;
+   uint32_t len;
+   uint32_t _pad2;
grant_ref_t gref[SNDIF_MAX_PAGES_PER_REQUEST];
 } __attribute__((__packed__));
 
-struct sndif_request_common {
-   struct alsa_hwparams _pad1;
-   unsigned int _pad2;
+struct sndif_request_volume {
uint64_t id;   /* private guest value, echoed in resp  */
-   unsigned int _pad3;
+   struct alsa_hwparams _pad1;
+   uint32_t left;
+   uint32_t right;
 } __attribute__((__packed__));
 
 struct sndif_request {
uint8_t operation;/* SNDIF_OP_??? */
union {
+   struct sndif_request_common common;
struct sndif_request_open open;
struct sndif_request_rw rw;
-   struct sndif_request_common common;
+   struct sndif_request_volume vol;
} u;
 } __attribute__((__packed__));
 
diff --git a/sound/drivers/xen-sndfront.c b/sound/drivers/xen-sndfront.c
index da048fc..4bb02ec 100644
--- a/sound/drivers/xen-sndfront.c
+++ b/sound/drivers/xen-sndfront.c
@@ -95,8 +95,7

[Xen-devel] [PATCH 2/3] xen-sndfront: switch to the v2 driver

[Oleksandr Dmytryshyn]

From: Iurii Konovalenko iurii.konovale...@globallogic.com

Now this driver registers an virtual sound card
and sends an PCM streams to the backend driver.
Backend driver is an user-space application and
uses ALSA with dmix plugin to play audio.

Signed-off-by: Iurii Konovalenko iurii.konovale...@globallogic.com
Signed-off-by: Oleksandr Dmytryshyn oleksandr.dmytrys...@globallogic.com
---
 include/xen/interface/io/sndif.h |   41 +-
 sound/drivers/Kconfig|3 +-
 sound/drivers/xen-sndfront.c | 1362 --
 3 files changed, 873 insertions(+), 533 deletions(-)

diff --git a/include/xen/interface/io/sndif.h b/include/xen/interface/io/sndif.h
index 9ef0c41..2fae4df 100644
--- a/include/xen/interface/io/sndif.h
+++ b/include/xen/interface/io/sndif.h
@@ -19,10 +19,6 @@
 #define SNDIF_OP_WRITE 3
 #define SNDIF_OP_IOCTL 4
 
-#define SNDIF_DEV_TYPE_CONTROL 0
-#define SNDIF_DEV_TYPE_STREAM_PLAY 1
-#define SNDIF_DEV_TYPE_STREAM_CAPTURE  2
-
 #define SNDIF_MAX_PAGES_PER_REQUEST10
 
 #define SNDIF_DEV_ID_CNT   5
@@ -35,53 +31,38 @@
  /* Operation completed successfully. */
 #define SNDIF_RSP_OKAY 0
 
+struct alsa_hwparams {
+   snd_pcm_format_t format;
+   unsigned int channels;
+   unsigned int rate;
+};
+
 struct sndif_request_open {
-   unsigned int dev_num;
-   unsigned int card_num;
-   unsigned int dev_type;
+   struct alsa_hwparams hwparams;
unsigned int _pad1;
uint64_t id;   /* private guest value, echoed in resp  */
unsigned int _pad2;
-   unsigned int _pad3;
-} __attribute__((__packed__));
-
-struct sndif_request_ioctl {
-   unsigned int dev_num;
-   unsigned int card_num;
-   unsigned int dev_type;
-   unsigned int cmd;
-   uint64_t id;   /* private guest value, echoed in resp  */
-   unsigned int add_len_to;
-   unsigned int add_len_from;
-   grant_ref_t gref[SNDIF_MAX_PAGES_PER_REQUEST];
 } __attribute__((__packed__));
 
 struct sndif_request_rw {
-   unsigned int dev_num;
-   unsigned int card_num;
-   unsigned int dev_type;
-   unsigned int _pad1;
+   struct alsa_hwparams _pad1;
+   unsigned int _pad2;
uint64_t id;   /* private guest value, echoed in resp  */
unsigned int len;
-   unsigned int is_write;
grant_ref_t gref[SNDIF_MAX_PAGES_PER_REQUEST];
 } __attribute__((__packed__));
 
 struct sndif_request_common {
-   unsigned int dev_num;
+   struct alsa_hwparams _pad1;
unsigned int _pad2;
-   unsigned int dev_type;
-   unsigned int _pad3;
uint64_t id;   /* private guest value, echoed in resp  */
-   unsigned int _pad4;
-   unsigned int _pad5;
+   unsigned int _pad3;
 } __attribute__((__packed__));
 
 struct sndif_request {
uint8_t operation;/* SNDIF_OP_??? */
union {
struct sndif_request_open open;
-   struct sndif_request_ioctl ioctl;
struct sndif_request_rw rw;
struct sndif_request_common common;
} u;
diff --git a/sound/drivers/Kconfig b/sound/drivers/Kconfig
index 7364679..cd3db5a 100644
--- a/sound/drivers/Kconfig
+++ b/sound/drivers/Kconfig
@@ -28,8 +28,9 @@ config XEN_SND_FRONTEND
tristate Xen virtual audio front-end driver support
depends on SND  XEN_DOMU
default n
+   select SND_PCM
help
- This driver implements the back-end of the Xen virtual
+ This driver implements the front-end of the Xen virtual
  audio driver.  It communicates with a back-end
  in another domain.
 
diff --git a/sound/drivers/xen-sndfront.c b/sound/drivers/xen-sndfront.c
index c7f8827..da048fc 100644
--- a/sound/drivers/xen-sndfront.c
+++ b/sound/drivers/xen-sndfront.c
@@ -23,16 +23,26 @@
  * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
  * IN THE SOFTWARE.
  */
+#include linux/init.h
+#include linux/err.h
+#include linux/platform_device.h
+#include linux/jiffies.h
+#include linux/slab.h
+#include linux/time.h
+#include linux/wait.h
+#include linux/hrtimer.h
+#include linux/math64.h
 #include linux/module.h
-#include linux/errno.h
-#include linux/cdev.h
-#include linux/fs.h
-#include linux/stddef.h
 #include linux/vmalloc.h
-#include linux/delay.h
-#include linux/uaccess.h
+#include sound/core.h
+#include sound/control.h
+#include sound/tlv.h
+#include sound/pcm.h
+#include sound/rawmidi.h
+#include sound/info.h
+#include sound/initval.h
 
-#include sound/asound.h
+#include linux/uaccess.h
 
 #include xen/xen.h
 #include xen/events.h
@@ -44,101 +54,168 @@
 #include xen/interface/io/protocols.h
 #include xen/interface/io/sndif.h
 
-#defineVSND_MAJOR  160
-#defineVSND_MINOR_CTRL 0
-#defineVSND_MINOR_STREAM   32
-
-#define

[Xen-devel] [PATCH 1/3] xen-sndfront: add sound frontend driver

[Oleksandr Dmytryshyn]

This is Para-virtual sound driver.

This driver creates sound files in /dev/snd/:
controlC0, pcmC0D0p, etc. Then it intercepts some
IOCTLs and redirects them to the backend driver.
Backend driver is build-in the kernel. It issues
those IOCTLs on the real sound files and returns
the result to the frontend driver.

Signed-off-by: Oleksandr Dmytryshyn oleksandr.dmytrys...@globallogic.com
---
 include/xen/interface/io/sndif.h |   98 
 sound/drivers/Kconfig|9 +
 sound/drivers/Makefile   |2 +
 sound/drivers/xen-sndfront.c | 1117 ++
 4 files changed, 1226 insertions(+)
 create mode 100644 include/xen/interface/io/sndif.h
 create mode 100644 sound/drivers/xen-sndfront.c

diff --git a/include/xen/interface/io/sndif.h b/include/xen/interface/io/sndif.h
new file mode 100644
index 000..9ef0c41
--- /dev/null
+++ b/include/xen/interface/io/sndif.h
@@ -0,0 +1,98 @@
+/**
+ * sndif.h
+ *
+ * Unified sound-device I/O interface for Xen guest OSes.
+ *
+ */
+#ifndef __XEN_PUBLIC_IO_SNDIF_H__
+#define __XEN_PUBLIC_IO_SNDIF_H__
+
+#include xen/interface/io/ring.h
+#include xen/interface/grant_table.h
+
+/*
+ * REQUEST CODES.
+ */
+#define SNDIF_OP_OPEN  0
+#define SNDIF_OP_CLOSE 1
+#define SNDIF_OP_READ  2
+#define SNDIF_OP_WRITE 3
+#define SNDIF_OP_IOCTL 4
+
+#define SNDIF_DEV_TYPE_CONTROL 0
+#define SNDIF_DEV_TYPE_STREAM_PLAY 1
+#define SNDIF_DEV_TYPE_STREAM_CAPTURE  2
+
+#define SNDIF_MAX_PAGES_PER_REQUEST10
+
+#define SNDIF_DEV_ID_CNT   5
+
+/*
+ * STATUS RETURN CODES.
+ */
+ /* Operation failed for some unspecified reason (-EIO). */
+#define SNDIF_RSP_ERROR   -1
+ /* Operation completed successfully. */
+#define SNDIF_RSP_OKAY 0
+
+struct sndif_request_open {
+   unsigned int dev_num;
+   unsigned int card_num;
+   unsigned int dev_type;
+   unsigned int _pad1;
+   uint64_t id;   /* private guest value, echoed in resp  */
+   unsigned int _pad2;
+   unsigned int _pad3;
+} __attribute__((__packed__));
+
+struct sndif_request_ioctl {
+   unsigned int dev_num;
+   unsigned int card_num;
+   unsigned int dev_type;
+   unsigned int cmd;
+   uint64_t id;   /* private guest value, echoed in resp  */
+   unsigned int add_len_to;
+   unsigned int add_len_from;
+   grant_ref_t gref[SNDIF_MAX_PAGES_PER_REQUEST];
+} __attribute__((__packed__));
+
+struct sndif_request_rw {
+   unsigned int dev_num;
+   unsigned int card_num;
+   unsigned int dev_type;
+   unsigned int _pad1;
+   uint64_t id;   /* private guest value, echoed in resp  */
+   unsigned int len;
+   unsigned int is_write;
+   grant_ref_t gref[SNDIF_MAX_PAGES_PER_REQUEST];
+} __attribute__((__packed__));
+
+struct sndif_request_common {
+   unsigned int dev_num;
+   unsigned int _pad2;
+   unsigned int dev_type;
+   unsigned int _pad3;
+   uint64_t id;   /* private guest value, echoed in resp  */
+   unsigned int _pad4;
+   unsigned int _pad5;
+} __attribute__((__packed__));
+
+struct sndif_request {
+   uint8_t operation;/* SNDIF_OP_??? */
+   union {
+   struct sndif_request_open open;
+   struct sndif_request_ioctl ioctl;
+   struct sndif_request_rw rw;
+   struct sndif_request_common common;
+   } u;
+} __attribute__((__packed__));
+
+struct sndif_response {
+   uint64_tid;  /* copied from request */
+   uint8_t operation;   /* copied from request */
+   int16_t status;  /* SNDIF_RSP_???   */
+};
+
+DEFINE_RING_TYPES(sndif, struct sndif_request, struct sndif_response);
+
+#endif /* __XEN_PUBLIC_IO_SNDIF_H__ */
diff --git a/sound/drivers/Kconfig b/sound/drivers/Kconfig
index 8545da9..7364679 100644
--- a/sound/drivers/Kconfig
+++ b/sound/drivers/Kconfig
@@ -24,6 +24,15 @@ config SND_AC97_CODEC
select AC97_BUS
select SND_VMASTER
 
+config XEN_SND_FRONTEND
+   tristate Xen virtual audio front-end driver support
+   depends on SND  XEN_DOMU
+   default n
+   help
+ This driver implements the back-end of the Xen virtual
+ audio driver.  It communicates with a back-end
+ in another domain.
+
 menuconfig SND_DRIVERS
bool Generic sound devices
default y
diff --git a/sound/drivers/Makefile b/sound/drivers/Makefile
index 1a8440c..f9f7e19 100644
--- a/sound/drivers/Makefile
+++ b/sound/drivers/Makefile
@@ -11,6 +11,7 @@ snd-portman2x4-objs := portman2x4.o
 snd-serial-u16550-objs := serial-u16550.o
 snd-virmidi-objs := virmidi.o
 snd-ml403-ac97cr-objs := ml403-ac97cr.o pcm-indirect2.o
+xen-sndfrontend-objs := xen-sndfront.o
 
 # Toplevel Module

[Xen-devel] [PATCH 0/3] Add sound frontend driver

[Oleksandr Dmytryshyn]

Hi to all.

Next series of patches introduces Para-virtual sound driver

CONFIG_XEN_SND_FRONTEND should be selected to use this driver.

Frontend driver registers an virtual sound card and sends/receives
an PCM streams to/from the backend driver. Backend driver is an
user-space application which uses ALSA with dmix plugin to play/capture audio.

Iurii Konovalenko (2):
  xen-sndfront: switch to the v2 driver
  xen-sndfront: add capture support

Oleksandr Dmytryshyn (1):
  xen-sndfront: add sound frontend driver

 include/xen/interface/io/sndif.h |  140 
 sound/drivers/Kconfig|   10 +
 sound/drivers/Makefile   |2 +
 sound/drivers/xen-sndfront.c | 1603 ++
 4 files changed, 1755 insertions(+)
 create mode 100644 include/xen/interface/io/sndif.h
 create mode 100644 sound/drivers/xen-sndfront.c

-- 
1.9.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 2/3] xen-sndfront: switch to the v2 driver

[Oleksandr Dmytryshyn]

On Mon, Jan 19, 2015 at 12:57 PM, David Vrabel david.vra...@citrix.com wrote:
 On 19/01/15 08:19, Oleksandr Dmytryshyn wrote:
 From: Iurii Konovalenko iurii.konovale...@globallogic.com

 Now this driver registers an virtual sound card
 and sends an PCM streams to the backend driver.
 Backend driver is an user-space application and
 uses ALSA with dmix plugin to play audio.

 [...]
  struct sndif_request_open {
 - unsigned int dev_num;
 - unsigned int card_num;
 - unsigned int dev_type;
 + struct alsa_hwparams hwparams;

 Don't put ALSA specific structures in the ABI.  The protocol needs to be
 suitable for frontend drivers that aren't ALSA.
This structure is defined upper in this file.
I'll rename this structure in the next patch-set.

 David

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 0/3] Add sound frontend driver

[Oleksandr Dmytryshyn]

On Mon, Jan 19, 2015 at 12:50 PM, David Vrabel david.vra...@citrix.com wrote:
 On 19/01/15 08:19, Oleksandr Dmytryshyn wrote:
 Hi to all.

 Next series of patches introduces Para-virtual sound driver

 CONFIG_XEN_SND_FRONTEND should be selected to use this driver.

 Frontend driver registers an virtual sound card and sends/receives
 an PCM streams to/from the backend driver. Backend driver is an
 user-space application which uses ALSA with dmix plugin to play/capture 
 audio.


 Iurii Konovalenko (2):
   xen-sndfront: switch to the v2 driver
   xen-sndfront: add capture support

 Oleksandr Dmytryshyn (1):
   xen-sndfront: add sound frontend driver

  include/xen/interface/io/sndif.h |  140 

 This ABI needs to be properly defined and documented and accepted into
 Xen before we can take any frontend drivers using it.
I'll push this ABI to xen.

 David


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 1/3] xen-sndfront: add sound frontend driver

[Oleksandr Dmytryshyn]

On Mon, Jan 19, 2015 at 12:55 PM, David Vrabel david.vra...@citrix.com wrote:
 On 19/01/15 08:19, Oleksandr Dmytryshyn wrote:
 +
 +struct sndif_request_open {
 + unsigned int dev_num;
 + unsigned int card_num;
 + unsigned int dev_type;
 + unsigned int _pad1;
 + uint64_t id;   /* private guest value, echoed in resp  */
 + unsigned int _pad2;
 + unsigned int _pad3;
 +} __attribute__((__packed__));

 Using types like unsigned int will break 32-bit guests talking to 64-bit
 backends.
I'll fix this in the next patch-set

 Always use fixed width types, naturally align them and use explicit
 padding.  The packed attribute will be unnecessary.

 David

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2] xen/serial: setup UART idle mode for OMAP

[Oleksandr Dmytryshyn]

On Tue, Dec 9, 2014 at 4:47 PM, Ian Campbell ian.campb...@citrix.com wrote:
 On Mon, 2014-12-08 at 15:51 +0200, Oleksandr Dmytryshyn wrote:
 UART is not able to receive bytes when idle mode is not
 configured properly. When we use Xen with old Linux
 Kernel (for example 3.8) this kernel configures hwmods
 for all devices even if the device tree nodes for those
 devices is absent in device tree. Thus UART idle mode
 is configured too. The fake node for the UART should
 be added to the device tree because the MMIO range
 is not mapped by Xen. So UART works normally in this
 case. But new Linux Kernel (3.12 and upper) doesn't
 configure idle mode for UART and UART can not work
 normally in this case.

 I think the focus is too much on the hack done with 3.8 to make this
 work rather than on the fix being made here itself. The hack is only
 really of peripheral/historic interest.

 How about instead:

 The UART is not able to receive bytes when idle mode is not
 configured properly, therefore setup the UART with autoidle and
 wakeup enabled.

 You could stop here or if you really want to cover the old hack you
 could go on to say:

 Older Linux kernels (for example 3.8) configures hwmods for all
 devices even if the device tree nodes for those devices is
 absent in device tree, thus UART idle mode is configured too.
 With such kernels we can workaround the issue by adding a fake
 node in the UART containing this MMIO range, which is therefore
 mapped by Xen to dom0, which reconfigures the UART, causing
 things to work normally.

 Newer Linux Kernels (3.12 and beyond) do not configure idle mode
 for UART and so this hack no longer works.

 If you are happy with the proposed wording (and indicate whether you
 want both bits or just the first) then, subject to Konrad giving a
 release Ack I'd be happy with this for 4.5 and I'll change the commit
 log as I go.
I'm fully happy with proposed wording (and want the both bits to be used)

 Konrad, this is a bug fix for a particular piece of hardware, it can't
 affect anything other than the OMAP ARM platform.


 Signed-off-by: Oleksandr Dmytryshyn oleksandr.dmytrys...@globallogic.com

 ---
 Changed since v1:
  * corrected commit message

  xen/drivers/char/omap-uart.c | 3 +++
  xen/include/xen/8250-uart.h  | 4 
  2 files changed, 7 insertions(+)

 diff --git a/xen/drivers/char/omap-uart.c b/xen/drivers/char/omap-uart.c
 index a798b8d..16d1454 100644
 --- a/xen/drivers/char/omap-uart.c
 +++ b/xen/drivers/char/omap-uart.c
 @@ -195,6 +195,9 @@ static void __init omap_uart_init_preirq(struct 
 serial_port *port)
  omap_write(uart, UART_MCR, UART_MCR_DTR|UART_MCR_RTS);

  omap_write(uart, UART_OMAP_MDR1, UART_OMAP_MDR1_16X_MODE);
 +
 +/* setup iddle mode */
 +omap_write(uart, UART_SYSC, OMAP_UART_SYSC_DEF_CONF);
  }

  static void __init omap_uart_init_postirq(struct serial_port *port)
 diff --git a/xen/include/xen/8250-uart.h b/xen/include/xen/8250-uart.h
 index a682bae..304b9dd 100644
 --- a/xen/include/xen/8250-uart.h
 +++ b/xen/include/xen/8250-uart.h
 @@ -32,6 +32,7 @@
  #define UART_MCR  0x04/* Modem control*/
  #define UART_LSR  0x05/* line status  */
  #define UART_MSR  0x06/* Modem status */
 +#define UART_SYSC 0x15/* System configuration register */
  #define UART_USR  0x1f/* Status register (DW) */
  #define UART_DLL  0x00/* divisor latch (ls) (DLAB=1) */
  #define UART_DLM  0x01/* divisor latch (ms) (DLAB=1) */
 @@ -145,6 +146,9 @@
  /* SCR register bitmasks */
  #define OMAP_UART_SCR_RX_TRIG_GRANU1_MASK (1  7)

 +/* System configuration register */
 +#define OMAP_UART_SYSC_DEF_CONF 0x0d /* autoidle mode, wakeup is enabled */
 +
  #endif /* __XEN_8250_UART_H__ */

  /*



___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] xen/serial: setup UART idle mode for OMAP

[Oleksandr Dmytryshyn]

In our case We've added an additional fake node to the device tree with
UART MMIO range for Xen and Xen mapped this MMIO range
for the Kernel 3.8. By default UART has wrong configuration in OMAP.

Oleksandr Dmytryshyn | Product Engineering and Development
GlobalLogic
M +38.067.382.2525
www.globallogic.com

http://www.globallogic.com/email_disclaimer.txt


On Fri, Dec 5, 2014 at 4:20 PM, Julien Grall julien.gr...@linaro.org wrote:
 Hi Oleksandr,

 On 05/12/14 13:46, Oleksandr Dmytryshyn wrote:
 UART is not able to receive bytes when idle mode is not
 configured properly. When we use Xen with old Linux
 Kernel (for example 3.8) this kernel configures UART
 idle mode even if the UART node in device tree is absent.

 I don't understand how the kernel can configure the UART as the MMIO
 range is not mapped. Is there another way to set the idle mode?

 Regards,

 --
 Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH] xen/serial: setup UART idle mode for OMAP

[Oleksandr Dmytryshyn]

UART is not able to receive bytes when idle mode is not
configured properly. When we use Xen with old Linux
Kernel (for example 3.8) this kernel configures UART
idle mode even if the UART node in device tree is absent.
So UART works normally in this case. But new Linux
Kernel (3.12 and upper) doesn't configure idle mode for
UART and UART can not work normally in this case.

Signed-off-by: Oleksandr Dmytryshyn oleksandr.dmytrys...@globallogic.com
---
 xen/drivers/char/omap-uart.c | 3 +++
 xen/include/xen/8250-uart.h  | 4 
 2 files changed, 7 insertions(+)

diff --git a/xen/drivers/char/omap-uart.c b/xen/drivers/char/omap-uart.c
index a798b8d..16d1454 100644
--- a/xen/drivers/char/omap-uart.c
+++ b/xen/drivers/char/omap-uart.c
@@ -195,6 +195,9 @@ static void __init omap_uart_init_preirq(struct serial_port 
*port)
 omap_write(uart, UART_MCR, UART_MCR_DTR|UART_MCR_RTS);
 
 omap_write(uart, UART_OMAP_MDR1, UART_OMAP_MDR1_16X_MODE);
+
+/* setup iddle mode */
+omap_write(uart, UART_SYSC, OMAP_UART_SYSC_DEF_CONF);
 }
 
 static void __init omap_uart_init_postirq(struct serial_port *port)
diff --git a/xen/include/xen/8250-uart.h b/xen/include/xen/8250-uart.h
index a682bae..304b9dd 100644
--- a/xen/include/xen/8250-uart.h
+++ b/xen/include/xen/8250-uart.h
@@ -32,6 +32,7 @@
 #define UART_MCR  0x04/* Modem control*/
 #define UART_LSR  0x05/* line status  */
 #define UART_MSR  0x06/* Modem status */
+#define UART_SYSC 0x15/* System configuration register */
 #define UART_USR  0x1f/* Status register (DW) */
 #define UART_DLL  0x00/* divisor latch (ls) (DLAB=1) */
 #define UART_DLM  0x01/* divisor latch (ms) (DLAB=1) */
@@ -145,6 +146,9 @@
 /* SCR register bitmasks */
 #define OMAP_UART_SCR_RX_TRIG_GRANU1_MASK (1  7)
 
+/* System configuration register */
+#define OMAP_UART_SYSC_DEF_CONF 0x0d /* autoidle mode, wakeup is enabled */
+
 #endif /* __XEN_8250_UART_H__ */
 
 /*
-- 
1.9.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [RFC PATCH v5 02/12] pm: move processor_perf.h file to the xen/include/xen location

[Oleksandr Dmytryshyn]

Cpufreq driver should be more generalizable (not ACPI-specific).
Thus this file should be placed to more convenient location.

Signed-off-by: Oleksandr Dmytryshyn oleksandr.dmytrys...@globallogic.com
---
 MAINTAINERS| 2 +-
 xen/arch/x86/platform_hypercall.c  | 2 +-
 xen/include/xen/cpufreq.h  | 2 +-
 xen/include/{acpi/cpufreq = xen}/processor_perf.h | 0
 4 files changed, 3 insertions(+), 3 deletions(-)
 rename xen/include/{acpi/cpufreq = xen}/processor_perf.h (100%)

diff --git a/MAINTAINERS b/MAINTAINERS
index 49f56a1..f4d916e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -234,8 +234,8 @@ F:  xen/arch/x86/acpi/
 X: xen/arch/x86/acpi/boot.c
 X: xen/arch/x86/acpi/lib.c
 F: xen/drivers/cpufreq/
-F: xen/include/acpi/cpufreq/
 F: xen/include/xen/cpufreq.h
+F: xen/include/xen/processor_perf.h
 
 QEMU-DM
 M: Ian Jackson ian.jack...@eu.citrix.com
diff --git a/xen/arch/x86/platform_hypercall.c 
b/xen/arch/x86/platform_hypercall.c
index 2162811..7ce8592 100644
--- a/xen/arch/x86/platform_hypercall.c
+++ b/xen/arch/x86/platform_hypercall.c
@@ -25,7 +25,7 @@
 #include xen/irq.h
 #include asm/current.h
 #include public/platform.h
-#include acpi/cpufreq/processor_perf.h
+#include xen/processor_perf.h
 #include asm/edd.h
 #include asm/mtrr.h
 #include asm/io_apic.h
diff --git a/xen/include/xen/cpufreq.h b/xen/include/xen/cpufreq.h
index fa653ef..82dc4dc 100644
--- a/xen/include/xen/cpufreq.h
+++ b/xen/include/xen/cpufreq.h
@@ -21,7 +21,7 @@
 #include xen/errno.h
 #include xen/cpumask.h
 
-#include acpi/cpufreq/processor_perf.h
+#include xen/processor_perf.h
 
 DECLARE_PER_CPU(spinlock_t, cpufreq_statistic_lock);
 
diff --git a/xen/include/acpi/cpufreq/processor_perf.h 
b/xen/include/xen/processor_perf.h
similarity index 100%
rename from xen/include/acpi/cpufreq/processor_perf.h
rename to xen/include/xen/processor_perf.h
-- 
1.9.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [RFC PATCH v5 11/12] cpufreq: add hwdom-cpufreq driver

[Oleksandr Dmytryshyn]

This driver uses hwdom to change frequencies on physical
CPUs.
Workflow:
 * cpufreq governor driver in Xen wants to change the
   frequency of the physical CPU
 * hwdom-cpufreq driver sets parameters in the shared
   memory
 * hwdom-cpufreq driver sends an event via event channel
   to notify the hardware domain
 * cpufreq driver in the hardware domain reads parameters
   from the shared memory, changes frequency and copies
   the result of the operation to the shared memory
 * cpufreq driver in the hwdom sends an event via event
   channel to notify the hwdom-cpufreq driver

Signed-off-by: Oleksandr Dmytryshyn oleksandr.dmytrys...@globallogic.com
---
 xen/Rules.mk|   1 +
 xen/common/sysctl.c |   8 +
 xen/drivers/cpufreq/Makefile|   1 +
 xen/drivers/cpufreq/hwdom-cpufreq.c | 422 
 xen/include/xen/cpufreq.h   |   2 +
 5 files changed, 434 insertions(+)
 create mode 100644 xen/drivers/cpufreq/hwdom-cpufreq.c

diff --git a/xen/Rules.mk b/xen/Rules.mk
index 3b0b89b..cccbc72 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -56,6 +56,7 @@ CFLAGS-$(perfc_arrays)  += -DPERF_ARRAYS
 CFLAGS-$(lock_profile)  += -DLOCK_PROFILE
 CFLAGS-$(HAS_ACPI)  += -DHAS_ACPI
 CFLAGS-$(HAS_CPUFREQ)   += -DHAS_CPUFREQ
+CFLAGS-$(HAS_HWDOM_CPUFREQ) += -DHAS_HWDOM_CPUFREQ
 CFLAGS-$(HAS_PM)+= -DHAS_PM
 CFLAGS-$(HAS_CPU_TURBO) += -DHAS_CPU_TURBO
 CFLAGS-$(HAS_GDBSX) += -DHAS_GDBSX
diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
index 0dcf06a..fd0cd0d 100644
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -27,6 +27,7 @@
 #include xsm/xsm.h
 #include xen/pmstat.h
 #include xen/gcov.h
+#include xen/cpufreq.h
 
 long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
 {
@@ -362,6 +363,13 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) 
u_sysctl)
 break;
 #endif
 
+#ifdef HAS_HWDOM_CPUFREQ
+case XEN_SYSCTL_cpufreq_op:
+ret = sysctl_cpufreq_op(op-u.cpufreq_op);
+copyback = 1;
+break;
+#endif
+
 default:
 ret = arch_do_sysctl(op, u_sysctl);
 copyback = 0;
diff --git a/xen/drivers/cpufreq/Makefile b/xen/drivers/cpufreq/Makefile
index b87d127..891997c 100644
--- a/xen/drivers/cpufreq/Makefile
+++ b/xen/drivers/cpufreq/Makefile
@@ -2,3 +2,4 @@ obj-y += cpufreq.o
 obj-y += cpufreq_ondemand.o
 obj-y += cpufreq_misc_governors.o
 obj-y += utility.o
+obj-$(HAS_HWDOM_CPUFREQ) += hwdom-cpufreq.o
diff --git a/xen/drivers/cpufreq/hwdom-cpufreq.c 
b/xen/drivers/cpufreq/hwdom-cpufreq.c
new file mode 100644
index 000..3932dca
--- /dev/null
+++ b/xen/drivers/cpufreq/hwdom-cpufreq.c
@@ -0,0 +1,422 @@
+/*
+ *  Copyright (C) 2001, 2002 Andy Grover andrew.gro...@intel.com
+ *  Copyright (C) 2001, 2002 Paul Diefenbaugh paul.s.diefenba...@intel.com
+ *  Copyright (C) 2002 - 2004 Dominik Brodowski li...@brodo.de
+ *  Copyright (C) 2006Denis Sadykov denis.m.sady...@intel.com
+ *
+ *  Feb 2008 - Liu Jinsong jinsong@intel.com
+ *  porting acpi-cpufreq.c from Linux 2.6.23 to Xen hypervisor
+ *
+ *  Copyright (C) 2014 GlobalLogic Inc.
+ *
+ * ~~
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or (at
+ *  your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful, but
+ *  WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ *  General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License along
+ *  with this program; if not, write to the Free Software Foundation, Inc.,
+ *  59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
+ *
+ * ~~
+ */
+#include xen/types.h
+#include xen/errno.h
+#include xen/sched.h
+#include xen/event.h
+#include xen/irq.h
+#include xen/spinlock.h
+#include xen/cpufreq.h
+#include xen/err.h
+#include xen/timer.h
+#include asm/shared.h
+#include asm/current.h
+#include asm/system.h
+
+#define WAIT_HWDOM_ANSWER_TOUT  (2000)  /* ms */
+
+struct hwdom_cpufreq_cpu_data {
+struct processor_performance *perf_data;
+struct cpufreq_frequency_table *freq_table;
+};
+
+struct hwdom_cpufreq {
+struct hwdom_cpufreq_cpu_data *cpu_data[NR_CPUS];
+struct domain *domain;
+spinlock_t drv_lock;
+spinlock_t hwdom_res_lock;
+bool_t is_timer_active;
+spinlock_t timer_lock;
+struct timer timer;
+uint32_t port;
+int32_t hwdom_res;
+};
+
+static struct hwdom_cpufreq hwdom_cpufreq;
+
+int cpufreq_cpu_init(unsigned int cpuid)
+{
+return cpufreq_add_cpu(cpuid);
+}
+
+/* Notify the hwdom (to do some command) */
+static void

[Xen-devel] [RFC PATCH v5 01/12] cpufreq: move cpufreq.h file to the xen/include/xen location

[Oleksandr Dmytryshyn]

Cpufreq driver should be more generalizable (not ACPI-specific).
Thus this file should be placed to more convenient location.

Signed-off-by: Oleksandr Dmytryshyn oleksandr.dmytrys...@globallogic.com
---
 MAINTAINERS  | 1 +
 xen/arch/x86/acpi/cpu_idle.c | 2 +-
 xen/arch/x86/acpi/cpufreq/cpufreq.c  | 2 +-
 xen/arch/x86/acpi/cpufreq/powernow.c | 2 +-
 xen/arch/x86/acpi/power.c| 2 +-
 xen/arch/x86/cpu/mwait-idle.c| 2 +-
 xen/drivers/acpi/pmstat.c| 2 +-
 xen/drivers/cpufreq/cpufreq.c| 2 +-
 xen/drivers/cpufreq/cpufreq_misc_governors.c | 2 +-
 xen/drivers/cpufreq/cpufreq_ondemand.c   | 4 ++--
 xen/drivers/cpufreq/utility.c| 2 +-
 xen/include/{acpi/cpufreq = xen}/cpufreq.h  | 7 +--
 12 files changed, 17 insertions(+), 13 deletions(-)
 rename xen/include/{acpi/cpufreq = xen}/cpufreq.h (98%)

diff --git a/MAINTAINERS b/MAINTAINERS
index 7757cdd..49f56a1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -235,6 +235,7 @@ X:  xen/arch/x86/acpi/boot.c
 X: xen/arch/x86/acpi/lib.c
 F: xen/drivers/cpufreq/
 F: xen/include/acpi/cpufreq/
+F: xen/include/xen/cpufreq.h
 
 QEMU-DM
 M: Ian Jackson ian.jack...@eu.citrix.com
diff --git a/xen/arch/x86/acpi/cpu_idle.c b/xen/arch/x86/acpi/cpu_idle.c
index 597befa..d773955 100644
--- a/xen/arch/x86/acpi/cpu_idle.c
+++ b/xen/arch/x86/acpi/cpu_idle.c
@@ -51,7 +51,7 @@
 #include xen/softirq.h
 #include public/platform.h
 #include public/sysctl.h
-#include acpi/cpufreq/cpufreq.h
+#include xen/cpufreq.h
 #include asm/apic.h
 #include asm/cpuidle.h
 #include asm/mwait.h
diff --git a/xen/arch/x86/acpi/cpufreq/cpufreq.c 
b/xen/arch/x86/acpi/cpufreq/cpufreq.c
index 4a6aeb3..5d22257 100644
--- a/xen/arch/x86/acpi/cpufreq/cpufreq.c
+++ b/xen/arch/x86/acpi/cpufreq/cpufreq.c
@@ -42,7 +42,7 @@
 #include asm/percpu.h
 #include asm/cpufeature.h
 #include acpi/acpi.h
-#include acpi/cpufreq/cpufreq.h
+#include xen/cpufreq.h
 
 enum {
 UNDEFINED_CAPABLE = 0,
diff --git a/xen/arch/x86/acpi/cpufreq/powernow.c 
b/xen/arch/x86/acpi/cpufreq/powernow.c
index 2c9fea2..4961d55 100644
--- a/xen/arch/x86/acpi/cpufreq/powernow.c
+++ b/xen/arch/x86/acpi/cpufreq/powernow.c
@@ -36,7 +36,7 @@
 #include asm/percpu.h
 #include asm/cpufeature.h
 #include acpi/acpi.h
-#include acpi/cpufreq/cpufreq.h
+#include xen/cpufreq.h
 
 #define CPUID_6_ECX_APERFMPERF_CAPABILITY   (0x1)
 #define CPUID_FREQ_VOLT_CAPABILITIES0x8007
diff --git a/xen/arch/x86/acpi/power.c b/xen/arch/x86/acpi/power.c
index f41f0de..f4a87e3 100644
--- a/xen/arch/x86/acpi/power.c
+++ b/xen/arch/x86/acpi/power.c
@@ -29,7 +29,7 @@
 #include asm/tboot.h
 #include asm/apic.h
 #include asm/io_apic.h
-#include acpi/cpufreq/cpufreq.h
+#include xen/cpufreq.h
 
 uint32_t system_reset_counter = 1;
 
diff --git a/xen/arch/x86/cpu/mwait-idle.c b/xen/arch/x86/cpu/mwait-idle.c
index 85179f2..c72219a 100644
--- a/xen/arch/x86/cpu/mwait-idle.c
+++ b/xen/arch/x86/cpu/mwait-idle.c
@@ -59,7 +59,7 @@
 #include asm/hpet.h
 #include asm/mwait.h
 #include asm/msr.h
-#include acpi/cpufreq/cpufreq.h
+#include xen/cpufreq.h
 
 #define MWAIT_IDLE_VERSION 0.4
 #undef PREFIX
diff --git a/xen/drivers/acpi/pmstat.c b/xen/drivers/acpi/pmstat.c
index daac2da..3486148 100644
--- a/xen/drivers/acpi/pmstat.c
+++ b/xen/drivers/acpi/pmstat.c
@@ -40,7 +40,7 @@
 #include xen/acpi.h
 
 #include public/sysctl.h
-#include acpi/cpufreq/cpufreq.h
+#include xen/cpufreq.h
 #include xen/pmstat.h
 
 DEFINE_PER_CPU_READ_MOSTLY(struct pm_px *, cpufreq_statistic_data);
diff --git a/xen/drivers/cpufreq/cpufreq.c b/xen/drivers/cpufreq/cpufreq.c
index ab66884..f5f4d75 100644
--- a/xen/drivers/cpufreq/cpufreq.c
+++ b/xen/drivers/cpufreq/cpufreq.c
@@ -44,7 +44,7 @@
 #include asm/processor.h
 #include asm/percpu.h
 #include acpi/acpi.h
-#include acpi/cpufreq/cpufreq.h
+#include xen/cpufreq.h
 
 static unsigned int __read_mostly usr_min_freq;
 static unsigned int __read_mostly usr_max_freq;
diff --git a/xen/drivers/cpufreq/cpufreq_misc_governors.c 
b/xen/drivers/cpufreq/cpufreq_misc_governors.c
index 746bbcd..4a5510c 100644
--- a/xen/drivers/cpufreq/cpufreq_misc_governors.c
+++ b/xen/drivers/cpufreq/cpufreq_misc_governors.c
@@ -18,7 +18,7 @@
 #include xen/init.h
 #include xen/percpu.h
 #include xen/sched.h
-#include acpi/cpufreq/cpufreq.h
+#include xen/cpufreq.h
 
 /*
  * cpufreq userspace governor
diff --git a/xen/drivers/cpufreq/cpufreq_ondemand.c 
b/xen/drivers/cpufreq/cpufreq_ondemand.c
index 7fdba03..d490c8a 100644
--- a/xen/drivers/cpufreq/cpufreq_ondemand.c
+++ b/xen/drivers/cpufreq/cpufreq_ondemand.c
@@ -1,5 +1,5 @@
 /*
- *  xen/arch/x86/acpi/cpufreq/cpufreq_ondemand.c
+ *  xen/drivers/cpufreq/cpufreq_ondemand.c
  *
  *  Copyright (C)  2001 Russell King
  *(C)  2003 Venkatesh Pallipadi venkatesh.pallip...@intel.com.
@@ -18,7 +18,7 @@
 #include xen/types.h
 #include xen/sched.h
 #include xen/timer.h

[Xen-devel] [RFC PATCH v5 02/10] xen/arm: add sysctl hypercall

[Oleksandr Dmytryshyn]

This hypercall will be used by xen-cpufreq driver
to get real number of physical CPUs.

Signed-off-by: Oleksandr Dmytryshyn oleksandr.dmytrys...@globallogic.com
CC: Keir Fraser k...@xen.org
---
 arch/arm/include/asm/xen/hypercall.h |  1 +
 arch/arm/include/asm/xen/interface.h |  2 +
 arch/arm/xen/enlighten.c |  1 +
 arch/arm/xen/hypercall.S |  1 +
 include/xen/interface/sysctl.h   | 79 
 include/xen/interface/xen.h  |  6 +++
 6 files changed, 90 insertions(+)
 create mode 100644 include/xen/interface/sysctl.h

diff --git a/arch/arm/include/asm/xen/hypercall.h 
b/arch/arm/include/asm/xen/hypercall.h
index c817c56..751869eb 100644
--- a/arch/arm/include/asm/xen/hypercall.h
+++ b/arch/arm/include/asm/xen/hypercall.h
@@ -48,6 +48,7 @@ int HYPERVISOR_memory_op(unsigned int cmd, void *arg);
 int HYPERVISOR_physdev_op(int cmd, void *arg);
 int HYPERVISOR_vcpu_op(int cmd, int vcpuid, void *extra_args);
 int HYPERVISOR_tmem_op(void *arg);
+int HYPERVISOR_sysctl(void *arg);
 
 static inline void
 MULTI_update_va_mapping(struct multicall_entry *mcl, unsigned long va,
diff --git a/arch/arm/include/asm/xen/interface.h 
b/arch/arm/include/asm/xen/interface.h
index 1151188..acf4b7a 100644
--- a/arch/arm/include/asm/xen/interface.h
+++ b/arch/arm/include/asm/xen/interface.h
@@ -19,6 +19,7 @@
__DEFINE_GUEST_HANDLE(name, struct name)
 #define DEFINE_GUEST_HANDLE(name) __DEFINE_GUEST_HANDLE(name, name)
 #define GUEST_HANDLE(name)__guest_handle_ ## name
+#define GUEST_HANDLE_64(name) GUEST_HANDLE(name)
 
 #define set_xen_guest_handle(hnd, val) \
do {\
@@ -48,6 +49,7 @@ DEFINE_GUEST_HANDLE(int);
 DEFINE_GUEST_HANDLE(void);
 DEFINE_GUEST_HANDLE(uint64_t);
 DEFINE_GUEST_HANDLE(uint32_t);
+DEFINE_GUEST_HANDLE(uint8_t);
 DEFINE_GUEST_HANDLE(xen_pfn_t);
 DEFINE_GUEST_HANDLE(xen_ulong_t);
 
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index eb0d851..675f17a 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -350,4 +350,5 @@ EXPORT_SYMBOL_GPL(HYPERVISOR_memory_op);
 EXPORT_SYMBOL_GPL(HYPERVISOR_physdev_op);
 EXPORT_SYMBOL_GPL(HYPERVISOR_vcpu_op);
 EXPORT_SYMBOL_GPL(HYPERVISOR_tmem_op);
+EXPORT_SYMBOL_GPL(HYPERVISOR_sysctl);
 EXPORT_SYMBOL_GPL(privcmd_call);
diff --git a/arch/arm/xen/hypercall.S b/arch/arm/xen/hypercall.S
index d1cf7b7..a1276df 100644
--- a/arch/arm/xen/hypercall.S
+++ b/arch/arm/xen/hypercall.S
@@ -89,6 +89,7 @@ HYPERCALL2(memory_op);
 HYPERCALL2(physdev_op);
 HYPERCALL3(vcpu_op);
 HYPERCALL1(tmem_op);
+HYPERCALL1(sysctl);
 
 ENTRY(privcmd_call)
stmdb sp!, {r4}
diff --git a/include/xen/interface/sysctl.h b/include/xen/interface/sysctl.h
new file mode 100644
index 000..97c91b0
--- /dev/null
+++ b/include/xen/interface/sysctl.h
@@ -0,0 +1,79 @@
+/**
+ * sysctl.h
+ *
+ * System management operations. For use by node control stack.
+ *
+ * Reused from xen: xen/include/public/sysctl.h
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the Software), to
+ * deal in the Software without restriction, including without limitation the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Copyright (c) 2002-2006, K Fraser
+ * Copyright (c) 2014, GlobalLogic Inc.
+ */
+
+#ifndef __XEN_PUBLIC_SYSCTL_H__
+#define __XEN_PUBLIC_SYSCTL_H__
+
+#include xen/interface/xen.h
+
+#define XEN_SYSCTL_INTERFACE_VERSION 0x000A
+
+/*
+ * Get physical information about the host machine
+ */
+/* XEN_SYSCTL_physinfo */
+ /* (x86) The platform supports HVM guests. */
+#define _XEN_SYSCTL_PHYSCAP_hvm  0
+#define XEN_SYSCTL_PHYSCAP_hvm   (1u_XEN_SYSCTL_PHYSCAP_hvm)
+ /* (x86) The platform supports HVM-guest direct access to I/O devices. */
+#define _XEN_SYSCTL_PHYSCAP_hvm_directio 1
+#define XEN_SYSCTL_PHYSCAP_hvm_directio  (1u_XEN_SYSCTL_PHYSCAP_hvm_directio)
+struct xen_sysctl_physinfo {
+   uint32_t threads_per_core;
+   uint32_t cores_per_socket

[Xen-devel] [RFC PATCH v5 07/10] cpufreq: make cpufreq low-level drivers visible for CPUFREQ_DRV_OPS config

[Oleksandr Dmytryshyn]

Low-level cpufreq drivers should depend from CPUFREQ_DRV_OPS
config instead of the CPU_FREQ config in case if we want
to use additional high-level cpufreq driver. This patch
is needed for implementation xen-based high-level cpufreq
driver.

Signed-off-by: Oleksandr Dmytryshyn oleksandr.dmytrys...@globallogic.com
---
 drivers/Makefile|  2 +-
 drivers/cpufreq/Kconfig | 16 
 2 files changed, 13 insertions(+), 5 deletions(-)

diff --git a/drivers/Makefile b/drivers/Makefile
index f8c79ae..58ef715 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -107,7 +107,7 @@ obj-$(CONFIG_ISDN)  += isdn/
 obj-$(CONFIG_EDAC) += edac/
 obj-$(CONFIG_EISA) += eisa/
 obj-y  += lguest/
-obj-$(CONFIG_CPU_FREQ) += cpufreq/
+obj-$(CONFIG_CPUFREQ_DRV_OPS)  += cpufreq/
 obj-$(CONFIG_CPU_IDLE) += cpuidle/
 obj-y  += mmc/
 obj-$(CONFIG_MEMSTICK) += memstick/
diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
index 42a1aed..f5a8f84 100644
--- a/drivers/cpufreq/Kconfig
+++ b/drivers/cpufreq/Kconfig
@@ -19,14 +19,11 @@ config CPU_FREQ
 
  If in doubt, say N.
 
-if CPU_FREQ
+if CPUFREQ_DRV_OPS
 
 config CPU_FREQ_TABLE
tristate
 
-config CPU_FREQ_GOV_COMMON
-   bool
-
 config CPU_FREQ_STAT
tristate CPU frequency translation statistics
select CPU_FREQ_TABLE
@@ -49,6 +46,13 @@ config CPU_FREQ_STAT_DETAILS
 
  If in doubt, say N.
 
+endif
+
+if CPU_FREQ
+
+config CPU_FREQ_GOV_COMMON
+   bool
+
 choice
prompt Default CPUFreq governor
default CPU_FREQ_DEFAULT_GOV_USERSPACE if CPU_FREQ_SA1100 || 
CPU_FREQ_SA1110
@@ -188,6 +192,10 @@ config CPU_FREQ_GOV_CONSERVATIVE
 
  If in doubt, say N.
 
+endif
+
+if CPUFREQ_DRV_OPS
+
 config GENERIC_CPUFREQ_CPU0
tristate Generic CPU0 cpufreq driver
depends on HAVE_CLK  REGULATOR  PM_OPP  OF
-- 
1.9.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [RFC PATCH v5 08/10] xen: arm: add cpufreq shared info definition

[Oleksandr Dmytryshyn]

This shared info will be used by xen-cpufreq driver
to receive commands from the cpufreq driver in xen.

Signed-off-by: Oleksandr Dmytryshyn oleksandr.dmytrys...@globallogic.com
---
 arch/arm/include/asm/xen/interface.h | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/xen/interface.h 
b/arch/arm/include/asm/xen/interface.h
index acf4b7a..e189977 100644
--- a/arch/arm/include/asm/xen/interface.h
+++ b/arch/arm/include/asm/xen/interface.h
@@ -56,8 +56,21 @@ DEFINE_GUEST_HANDLE(xen_ulong_t);
 /* Maximum number of virtual CPUs in multi-processor guests. */
 #define MAX_VIRT_CPUS 1
 
+#define CPUFREQ_CMD_idle   0
+#define CPUFREQ_CMD_change_freq1
+
+struct cpufreq_sh_info {
+   uint32_t cmd;   /* CPUFREQ_CMD_* */
+   uint32_t cpu;   /* Physical CPU number */
+   uint32_t freq;  /* Frequency in KHz */
+   uint32_t relation;  /* CPUFREQ_RELATION_L/H (0) or (1) */
+   int32_t result; /* Returned result of the operation */
+};
+
 struct arch_vcpu_info { };
-struct arch_shared_info { };
+struct arch_shared_info {
+   struct cpufreq_sh_info cpufreq;
+};
 
 /* TODO: Move pvclock definitions some place arch independent */
 struct pvclock_vcpu_time_info {
-- 
1.9.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [RFC PATCH v5 09/10] xen/arm: add XEN_SYSCTL_cpufreq_op definition

[Oleksandr Dmytryshyn]

Kernel uses this op to start/stop cpufreq notification
events sending.

Signed-off-by: Oleksandr Dmytryshyn oleksandr.dmytrys...@globallogic.com
---
 include/xen/interface/sysctl.h | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/include/xen/interface/sysctl.h b/include/xen/interface/sysctl.h
index 97c91b0..a4d52e5 100644
--- a/include/xen/interface/sysctl.h
+++ b/include/xen/interface/sysctl.h
@@ -63,14 +63,24 @@ struct xen_sysctl_physinfo {
 };
 DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_physinfo);
 
+#define XEN_SYSCTL_CPUFREQ_event_start 0
+#define XEN_SYSCTL_CPUFREQ_event_stop  1
+
+struct xen_sysctl_cpufreq_op {
+   uint32_t cmd; /* XEN_SYSCTL_CPUFREQ_* */
+   uint32_t port;/* OUT: event channel for notifications */
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_sysctl_cpufreq_op);
 
 
 struct xen_sysctl {
uint32_t cmd;
 #define XEN_SYSCTL_physinfo   3
+#define XEN_SYSCTL_cpufreq_op21
uint32_t interface_version; /* XEN_SYSCTL_INTERFACE_VERSION */
union {
struct xen_sysctl_physinfo  physinfo;
+   struct xen_sysctl_cpufreq_opcpufreq_op;
uint8_t pad[128];
} u;
 };
-- 
1.9.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [RFC PATCH v5 00/10] xen_cpufreq implementation in kernel

[Oleksandr Dmytryshyn]

Hi to all.

Next series of patches implements xen-cpufreq driver in kernel.

Cpufreq core and registered cpufreq governors are located in xen. Hwdom has CPU
driver which can only change frequency of the physical CPUs. In addition this
driver can change CPUs regulator voltage. At start time xen-cpufreq driver
in hwdom reads an information about physical CPUs number and uploads to Xen
information about those physical cpus. Then hwdon uses XEN_SYSCTL_cpufreq_op
operation to start events from hwdom-cpufreq ddriver in Xen.
Changing frequency workflow:
 * hwdom-cpufreq driver in Xen wants to change the
   frequency of the physical CPU
 * hwdom-cpufreq in Xen sets parameters in the shared
   memory
 * hwdom-cpufreq driver in Xen sends an event via event channel
   to notify the xen-cpufreq driver in hwdom
 * xen-cpufreq driver in hwdom reads parameters from the shared
   memory, changes frequency and copies the result of
   the operation to the shared memory
 * xen-cpufreq driver in hwdom sends an event via event channel
   to notify the cpufreq driver in Xen

Next configs should be enabled to use xen-cpufreq driver:
CONFIG_GENERIC_CPUFREQ_CPU0
CONFIG_XEN_CPUFREQ

Changed since v1:
 * added cpufreq_drv_ops which allows to use more than one high-level
   cpufreq driver
 * reworked xen-cpufreq and drivers so the same kernel is able to run
   on bare metal and within Xen.

Changed since v2:
 * used VIRQ_CPUFREQ with number 14 instead of the 13
 * slightly reworked xen-cpufreq driver

Changed since v3:
 * documented /hypervisor/pcpus/ node
 * added cpufreq shared info definition to receive commands from the
   Xen cpufreq driver
 * config CONFIG_CPUMASK_OFFSTACK now is checked in the Kconfig

Changed since v4:
 * implemented an event channel between Xen and hwdom
 * restored XEN_SYSCTL_cpufreq_op definition (start/stop hwdom-cpufreq
   driver events)
 * extended comments for some patches (adding hypercalls, adding xen-cpufreq
   driver)
 * removed VIRQ_CPUFREQ

Oleksandr Dmytryshyn (10):
  PM / OPP: make cpufreq functions dependent on CONFIG_CPU_FREQ_TABLE
  xen/arm: add sysctl hypercall
  xen/arm: add dom0_op hypercall
  docs: Xen ARM DT bindings: document pcpus property
  cpufreq: cpufreq-cpu0: change cpus data path in devtree for hwdom
kernel
  cpufreq: introduce cpufreq_drv_ops
  cpufreq: make cpufreq low-level drivers visible for CPUFREQ_DRV_OPS
config
  xen: arm: add cpufreq shared info definition
  xen/arm: add XEN_SYSCTL_cpufreq_op definition
  xen/arm: cpufreq: add xen-cpufreq driver

 Documentation/devicetree/bindings/arm/xen.txt |  20 +-
 arch/arm/include/asm/xen/hypercall.h  |   2 +
 arch/arm/include/asm/xen/interface.h  |  17 +-
 arch/arm/xen/enlighten.c  |   2 +
 arch/arm/xen/hypercall.S  |   2 +
 drivers/Makefile  |   2 +-
 drivers/base/power/opp.c  |   4 +-
 drivers/cpufreq/Kconfig   |  40 +-
 drivers/cpufreq/Makefile  |   2 +
 drivers/cpufreq/acpi-cpufreq.c|   5 +-
 drivers/cpufreq/cpufreq-cpu0.c|   8 +-
 drivers/cpufreq/cpufreq.c | 116 ++--
 drivers/cpufreq/cpufreq_drv_ops.c | 196 ++
 drivers/cpufreq/cpufreq_drv_ops.h |  54 ++
 drivers/cpufreq/cpufreq_governor.c|   4 +-
 drivers/cpufreq/xen-cpufreq.c | 917 ++
 include/linux/cpufreq.h   |   2 +-
 include/linux/opp.h   |   2 +-
 include/xen/interface/platform.h  |   1 +
 include/xen/interface/sysctl.h|  89 +++
 include/xen/interface/xen.h   |   6 +
 21 files changed, 1423 insertions(+), 68 deletions(-)
 create mode 100644 drivers/cpufreq/cpufreq_drv_ops.c
 create mode 100644 drivers/cpufreq/cpufreq_drv_ops.h
 create mode 100644 drivers/cpufreq/xen-cpufreq.c
 create mode 100644 include/xen/interface/sysctl.h

-- 
1.9.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [RFC PATCH v5 10/10] xen/arm: cpufreq: add xen-cpufreq driver

[Oleksandr Dmytryshyn]

Xen changes frequencies on physical CPUs using this
high-level cpufreq driver.
Workflow:
 * cpufreq governor driver in Xen wants to change the
   frequency of the physical CPU
 * cpufreq driver in Xen sets parameters in the shared
   memory
 * cpufreq driver in Xen sends an event via event channel
   to notify the xen-cpufreq driver
 * xen-cpufreq driver reads parameters from the shared
   memory, changes frequency and copies the result of
   the operation to the shared memory
 * xen-cpufreq driver sends an event via event channel
   to notify the cpufreq driver in Xen

Signed-off-by: Oleksandr Dmytryshyn oleksandr.dmytrys...@globallogic.com
---
 drivers/cpufreq/Kconfig   |  20 +
 drivers/cpufreq/Makefile  |   1 +
 drivers/cpufreq/cpufreq_drv_ops.c |  13 +-
 drivers/cpufreq/cpufreq_drv_ops.h |   4 +
 drivers/cpufreq/xen-cpufreq.c | 917 ++
 include/xen/interface/platform.h  |   1 +
 6 files changed, 954 insertions(+), 2 deletions(-)
 create mode 100644 drivers/cpufreq/xen-cpufreq.c

diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
index f5a8f84..4847d8a 100644
--- a/drivers/cpufreq/Kconfig
+++ b/drivers/cpufreq/Kconfig
@@ -19,6 +19,26 @@ config CPU_FREQ
 
  If in doubt, say N.
 
+config XEN_CPUFREQ
+   bool Xen Cpufreq driver
+   depends on XEN_DOM0
+   depends on !CPUMASK_OFFSTACK
+   default n
+   select CPUFREQ_DRV_OPS
+   help
+ This driver uploads Power Management information to the Xen
+ hypervisor and changes CPUs frequency using CPU Frequency scaling
+ drivers.
+
+ To do that the driver uses CPU Frequency scaling drivers to parse
+ the Power Management data and uploads said information to the Xen
+ hypervisor. Then the Xen hypervisor can select the proper Pxx states.
+
+ Then the Xen hypervisor can change CPUs frequency by giving commands
+ via this driver to the CPU Frequency scaling driver.
+
+ If in doubt, say N.
+
 if CPUFREQ_DRV_OPS
 
 config CPU_FREQ_TABLE
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index f12a0d3..c8d5037 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -1,5 +1,6 @@
 # CPUfreq core
 obj-$(CONFIG_CPU_FREQ) += cpufreq.o
+obj-$(CONFIG_XEN_CPUFREQ)  += xen-cpufreq.o
 obj-$(CONFIG_CPUFREQ_DRV_OPS)  += cpufreq_drv_ops.o
 # CPUfreq stats
 obj-$(CONFIG_CPU_FREQ_STAT) += cpufreq_stats.o
diff --git a/drivers/cpufreq/cpufreq_drv_ops.c 
b/drivers/cpufreq/cpufreq_drv_ops.c
index c971442..71c3357 100644
--- a/drivers/cpufreq/cpufreq_drv_ops.c
+++ b/drivers/cpufreq/cpufreq_drv_ops.c
@@ -18,6 +18,8 @@
 #include linux/init.h
 #include linux/export.h
 
+#include xen/xen.h
+
 static struct cpufreq_drv_ops *ops;
 
 struct kobject *get_cpufreq_global_kobject(void)
@@ -177,10 +179,17 @@ EXPORT_SYMBOL_GPL(cpufreq_unregister_driver);
 
 static int __init cpufreq_drv_ops_init(void)
 {
+   if (xen_initial_domain()) {
+#ifdef CONFIG_XEN_CPUFREQ
+   ops = xen_cpufreq_drv_ops;
+   pr_debug(using xen_cpufreq_drv_ops\n);
+#endif
+   } else {
 #ifdef CONFIG_CPU_FREQ
-   ops = kern_cpufreq_drv_ops;
-   pr_debug(using kern_cpufreq_drv_ops\n);
+   ops = kern_cpufreq_drv_ops;
+   pr_debug(using kern_cpufreq_drv_ops\n);
 #endif
+   }
 
return 0;
 }
diff --git a/drivers/cpufreq/cpufreq_drv_ops.h 
b/drivers/cpufreq/cpufreq_drv_ops.h
index 5cc8e05..d02d509 100644
--- a/drivers/cpufreq/cpufreq_drv_ops.h
+++ b/drivers/cpufreq/cpufreq_drv_ops.h
@@ -47,4 +47,8 @@ struct cpufreq_drv_ops {
 extern struct cpufreq_drv_ops kern_cpufreq_drv_ops;
 #endif
 
+#ifdef CONFIG_XEN_CPUFREQ
+extern struct cpufreq_drv_ops xen_cpufreq_drv_ops;
+#endif
+
 #endif /* _CPUFREQ_DRV_OPS_H */
diff --git a/drivers/cpufreq/xen-cpufreq.c b/drivers/cpufreq/xen-cpufreq.c
new file mode 100644
index 000..b19d726
--- /dev/null
+++ b/drivers/cpufreq/xen-cpufreq.c
@@ -0,0 +1,917 @@
+/*
+ *  Copyright (C) 2001 Russell King
+ *(C) 2002 - 2003 Dominik Brodowski li...@brodo.de
+ *
+ *  Oct 2005 - Ashok Raj ashok@intel.com
+ * Added handling for CPU hotplug
+ *  Feb 2006 - Jacob Shin jacob.s...@amd.com
+ * Fix handling for CPU hotplug -- affected CPUs
+ *
+ *   (C) 2014 GlobalLogic Inc.
+ *
+ * Based on drivers/cpufreq/cpufreq.c
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME :  fmt
+
+#include linux/kernel.h
+#include linux/module.h

[Xen-devel] [RFC PATCH v5 06/10] cpufreq: introduce cpufreq_drv_ops

[Oleksandr Dmytryshyn]

This patch allows to use more than one high-level
cpufreq driver. This patch is needed for implementation
xen-based high-level cpufreq driver.

Signed-off-by: Oleksandr Dmytryshyn oleksandr.dmytrys...@globallogic.com
---
 drivers/cpufreq/Kconfig|   4 +
 drivers/cpufreq/Makefile   |   1 +
 drivers/cpufreq/acpi-cpufreq.c |   5 +-
 drivers/cpufreq/cpufreq.c  | 116 ---
 drivers/cpufreq/cpufreq_drv_ops.c  | 187 +
 drivers/cpufreq/cpufreq_drv_ops.h  |  50 ++
 drivers/cpufreq/cpufreq_governor.c |   4 +-
 include/linux/cpufreq.h|   2 +-
 8 files changed, 312 insertions(+), 57 deletions(-)
 create mode 100644 drivers/cpufreq/cpufreq_drv_ops.c
 create mode 100644 drivers/cpufreq/cpufreq_drv_ops.h

diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
index cbcb21e..42a1aed 100644
--- a/drivers/cpufreq/Kconfig
+++ b/drivers/cpufreq/Kconfig
@@ -1,7 +1,11 @@
 menu CPU Frequency scaling
 
+config CPUFREQ_DRV_OPS
+   bool
+
 config CPU_FREQ
bool CPU Frequency scaling
+   select CPUFREQ_DRV_OPS
help
  CPU Frequency scaling allows you to change the clock speed of 
  CPUs on the fly. This is a nice method to save power, because 
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index fadc4d4..f12a0d3 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -1,5 +1,6 @@
 # CPUfreq core
 obj-$(CONFIG_CPU_FREQ) += cpufreq.o
+obj-$(CONFIG_CPUFREQ_DRV_OPS)  += cpufreq_drv_ops.o
 # CPUfreq stats
 obj-$(CONFIG_CPU_FREQ_STAT) += cpufreq_stats.o
 
diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
index 7b0d49d..2c2a33f 100644
--- a/drivers/cpufreq/acpi-cpufreq.c
+++ b/drivers/cpufreq/acpi-cpufreq.c
@@ -950,7 +950,8 @@ static void __init acpi_cpufreq_boost_init(void)
/* We create the boost file in any case, though for systems without
 * hardware support it will be read-only and hardwired to return 0.
 */
-   if (sysfs_create_file(cpufreq_global_kobject, (global_boost.attr)))
+   if (sysfs_create_file(get_cpufreq_global_kobject(),
+ (global_boost.attr)))
pr_warn(PFX could not register global boost sysfs file\n);
else
pr_debug(registered global boost sysfs file\n);
@@ -958,7 +959,7 @@ static void __init acpi_cpufreq_boost_init(void)
 
 static void __exit acpi_cpufreq_boost_exit(void)
 {
-   sysfs_remove_file(cpufreq_global_kobject, (global_boost.attr));
+   sysfs_remove_file(get_cpufreq_global_kobject(), (global_boost.attr));
 
if (msrs) {
unregister_cpu_notifier(boost_nb);
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 6ed3c13..1b24bc3e 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -33,6 +33,7 @@
 #include linux/syscore_ops.h
 
 #include trace/events/power.h
+#include cpufreq_drv_ops.h
 
 /**
  * The cpufreq driver - the arch- or hardware-dependent low
@@ -178,11 +179,10 @@ err_out:
return NULL;
 }
 
-struct cpufreq_policy *cpufreq_cpu_get(unsigned int cpu)
+struct cpufreq_policy *kern_cpufreq_cpu_get(unsigned int cpu)
 {
return __cpufreq_cpu_get(cpu, false);
 }
-EXPORT_SYMBOL_GPL(cpufreq_cpu_get);
 
 static struct cpufreq_policy *cpufreq_cpu_get_sysfs(unsigned int cpu)
 {
@@ -196,11 +196,10 @@ static void __cpufreq_cpu_put(struct cpufreq_policy 
*data, bool sysfs)
module_put(cpufreq_driver-owner);
 }
 
-void cpufreq_cpu_put(struct cpufreq_policy *data)
+void kern_cpufreq_cpu_put(struct cpufreq_policy *data)
 {
__cpufreq_cpu_put(data, false);
 }
-EXPORT_SYMBOL_GPL(cpufreq_cpu_put);
 
 static void cpufreq_cpu_put_sysfs(struct cpufreq_policy *data)
 {
@@ -258,7 +257,8 @@ static inline void adjust_jiffies(unsigned long val, struct 
cpufreq_freqs *ci)
  * function. It is called twice on all CPU frequency changes that have
  * external effects.
  */
-void cpufreq_notify_transition(struct cpufreq_freqs *freqs, unsigned int state)
+void kern_cpufreq_notify_transition(struct cpufreq_freqs *freqs,
+   unsigned int state)
 {
struct cpufreq_policy *policy;
 
@@ -303,9 +303,6 @@ void cpufreq_notify_transition(struct cpufreq_freqs *freqs, 
unsigned int state)
break;
}
 }
-EXPORT_SYMBOL_GPL(cpufreq_notify_transition);
-
-
 
 /*
  *  SYSFS INTERFACE  *
@@ -628,7 +625,10 @@ static struct attribute *default_attrs[] = {
 };
 
 struct kobject *cpufreq_global_kobject;
-EXPORT_SYMBOL(cpufreq_global_kobject);
+struct kobject *get_kern_cpufreq_global_kobject(void)
+{
+   return cpufreq_global_kobject;
+}
 
 #define to_policy(k) container_of(k, struct cpufreq_policy, kobj)
 #define to_attr(a) container_of(a, struct